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>
This reverts commit dc539daf88.
With "gdbm-Update to 1.13", 'php 5.3.27' failed to build.
Best,
Matthias
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Keeps older packages that have been linked
against this version of libevent2 working.
Best,
Matthias
Signed-off-by: Matthias Fischer <matthias.fischer@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Libvirt is build only on these arches and the bindings make only with
libvirt sense so we should build them only on these two arches too.
Signed-off-by: Jonatan Schlag <jonatan.schlag@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
This patch update the libvirt library to version 3.1.0
We can not update to the latest version in the moment because version
3.2.0 has a annoying bug.
Signed-off-by: Jonatan Schlag <jonatan.schlag@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
For details see:
https://ftp.isc.org/isc/bind9/9.11.0-P5/RELEASE-NOTES-bind-9.11.0-P5.html
"BIND 9.11.0-P5 addresses the security issues described in CVE-2017-3136,
CVE-2017-3137, and CVE-2017-3138, and updates the built-in trusted keys for the root zone.
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]
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]
Best,
Matthias
Signed-off-by: Matthias Fischer <matthias.fischer@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
The daemon locks up when starting up in avahi_log_info() and
probably the other logging functions, too.
Since avahi is not really used a lot in the distribution,
has been in testing for four years and has virtually no users
I am going to drop it instead of wasting time on fixing this.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
IPFire 2 does not have IPv6 connectivity with exception of a
few systems for testing where IPsec connections become a little
bit unstable when trying to connect over IPv6.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
