Since the new toolchain the flags are not compiled into the
binaries any more which causes paxctl to fail.
On top of that, PaX and grsecurity won't be available freely
any more which requires us to remove it from the distribution.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
The build fails with various reasons and a full bootstrap
always succeeds. This takes a very long time so we try to
avoid it where ever possible.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
The build environment is using a number of variables which
occasionally conflicted with some other build systems.
This patch cleans that up by renaming some variables and
later unexporting them in the lfs files.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
GCC does not need to be bootstrapped in the second pass
any more since the toolchain is not built hardened
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
The toolchain will be built without hardening which makes
the entire bootstrapping process way more complicated than
necessary and sometimes fail on some host distribution.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
For details see:
https://ftp.isc.org/isc/bind9/9.11.1/RELEASE-NOTES-bind-9.11.1.html
"Security Fixes
rndc "" could trigger an assertion failure in named. This flaw is disclosed
in (CVE-2017-3138). [RT #44924]
Some chaining (i.e., type CNAME or DNAME) responses to upstream queries could
trigger assertion failures. This flaw is disclosed in CVE-2017-3137. [RT #44734]
dns64 with break-dnssec yes; can result in an assertion failure. This flaw is
disclosed in CVE-2017-3136. [RT #44653]
If a server is configured with a response policy zone (RPZ) that rewrites an
answer with local data, and is also configured for DNS64 address mapping, a NULL
pointer can be read triggering a server crash. This flaw is disclosed in
CVE-2017-3135. [RT #44434]
A coding error in the nxdomain-redirect feature could lead to an assertion failure
if the redirection namespace was served from a local authoritative data source such
as a local zone or a DLZ instead of via recursive lookup. This flaw is disclosed in
CVE-2016-9778. [RT #43837]
named could mishandle authority sections with missing RRSIGs, triggering an
assertion failure. This flaw is disclosed in CVE-2016-9444. [RT #43632]
named mishandled some responses where covering RRSIG records were returned without
the requested data, resulting in an assertion failure. This flaw is disclosed in
CVE-2016-9147. [RT #43548]
named incorrectly tried to cache TKEY records which could trigger an assertion failure
when there was a class mismatch. This flaw is disclosed in CVE-2016-9131. [RT #43522]
It was possible to trigger assertions when processing responses containing answers of
type DNAME. This flaw is disclosed in CVE-2016-8864. [RT #43465]
Added the ability to specify the maximum number of records permitted in a zone
(max-records #;). This provides a mechanism to block overly large zone transfers, which
is a potential risk with slave zones from other parties, as described in CVE-2016-6170.
[RT #42143]
Bug Fixes
A synthesized CNAME record appearing in a response before the associated DNAME could be
cached, when it should not have been. This was a regression introduced while addressing
CVE-2016-8864. [RT #44318]
named could deadlock if multiple changes to NSEC/NSEC3 parameters for the same zone were
being processed at the same time. [RT #42770]
named could trigger an assertion when sending NOTIFY messages. [RT #44019]
Referencing a nonexistent zone in a response-policy statement could cause an assertion
failure during configuration. [RT #43787]
rndc addzone could cause a crash when attempting to add a zone with a type other than
master or slave. Such zones are now rejected. [RT #43665]
named could hang when encountering log file names with large apparent gaps in version
number (for example, when files exist called "logfile.0", "logfile.1", and
"logfile.1482954169"). This is now handled correctly. [RT #38688]
If a zone was updated while named was processing a query for nonexistent data, it could
return out-of-sync NSEC3 records causing potential DNSSEC validation failure. [RT #43247]"
Best,
Matthias
Signed-off-by: Matthias Fischer <matthias.fischer@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
