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>
This patch adds some status information so that we know what
authentication an access point is using.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
I altered 'showrequestfromcountry.dat', 'showrequestfromip.dat' and 'showrequestfromport.dat'
in the same manner as the 'Loggraphs'-Pages in commit
Each 'Details'-page got a unique title.
Furthermore, I added a 'Back'-Button to go back to the previous page. For this, I used
'back.png' from 'wio' (thanks Stephan! ;-) ) since I found no other appropriate image.
'ipinfo.cgi' got a centered 'Back'-Button, too.
Signed-off-by: Matthias Fischer <matthias.fischer@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
The status file was not updated when DNSSEC was disabled
before and has been enabled after which always caused
the webif to show that DNSSEC was disabled.
Fixes#11315
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>
This will break compatibility with old clients like
Windows XP, but these are too old now to be supported.
SHA1 is considered to be weak and should not be used any more
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Changelog:
http://humdi.net/vnstat/CHANGES
I had to add some 'configure'-lines to build this - nevertheless: its
working. ;-)
'vnstat.conf' needed some additional 'sed'-lines, too.
Please review, test and confirm.
Best,
Matthias
Signed-off-by: Matthias Fischer <matthias.fischer@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Fixed the 'details'-Button in 'firewalllogcountry.dat' by adding missing
translation string.
Each 'Loggraphs'-Page got a unique title and a new heading for the corresponding
diagram.
Just cosmetics...
Best,
Matthias
Signed-off-by: Matthias Fischer <matthias.fischer@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Hi,
this was triggered by unbound-users@unbound.net - it seems that the
'configure'-option '--with-libevent-support' is not enough:
***SNIP***
...
When building unbound with --with-libevent support, the make
install phase should also call make unbound-event-install or else
unbound-event.h does not get installed and the header file for
using the unbound event functionality is not available.
...
This install is triggered by the option --enable-event-api. Just
enabling --with-libevent does not trigger the install by itself.
Best regards,
Wouter
...
***SNAP***
I built 'unbound' this way - its running without any problems so far.
Best,
Matthias
Signed-off-by: Matthias Fischer <matthias.fischer@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
