Bug#966846: Kernel panic (4.19.0-10): RIP __cgroup_bpf_run_filter_skb
Package: linux-source-4.19 Version: 4.19.132-1 Severity: important Hello, Since linux-image-4.19.0-10-amd64, I'm facing regular Kernel panics - "RIP: 0010:__cgroup_bpf_run_filter_skb+0x26d/0x3d0" - resulting in full (file) *server freeze*. The issue is pretty well described and summarized in https://forum.proxmox.com/threads/kernel-5-4-44-causes-system-freeze-on-hp-microserver-gen8.72050/page-2#post-323498 The "culprit" commit - "netprio_cgroup: Fix unlimited memory leak of v2 cgroups" - is indeed included in Debian kernel (4.19) since changelog entry 4.19.131-1 It *seems* there is already a patch proposed upstream (although here for kernel 4.9): https://lkml.org/lkml/2020/7/20/883 Best regards, Cédric -- Cédric Dufour
Bug#914511: Please enable the "virtio-rng" driver in "cloud" kernels
Workaround: have the hypervisor expose the 'rdrand' CPU feature to the VM (but this is in the hands of the hypervisor's provider, not the VM user)
Bug#914511: Please enable the "virtio-rng" driver in "cloud" kernels
Now that *u*random is blocking until considered properly initialized, the entropy starvation [1] issue becomes a real problem during the boot process; e.g. it takes several minutes until one gets SSH access to the box. [1] https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#entropy-starvation -- Cédric Dufour - Exoscale (Lausanne, Switzerland)
Bug#662960: ssmtp doesn't validate server TLS certificates
On 09/01/2019 16:44, Simon Deziel wrote: > On 2019-01-09 10:23 a.m., Cédric Dufour - Idiap Research Institute wrote: > ssmtp seems like abandonware. Have you tried msmtp(-mta)? It works in a > similar way, is well supported and does the right thing when you want TLS. Indeed. mstmp-mta works like a charm (just tested in Buster). Thanks for the tip. (I liked the extreme lightweight of ssmtp but so be it) PS: one might also look at esmtp(-run)
Bug#662960: ssmtp doesn't validate server TLS certificates
Any chance seeing this issue addressed or its severity lowered, so we can have the package in Buster ? Given its purpose - "extremely simple MTA [...]" - should this issue really be considered "serious" (and Release Critical) ? PS: ssmtp is extremely handy to forward machine-generated messages in large deployments, internally, iow. where TLS is not required
Bug#915381: Shouldn't nvidia-persistenced be daemonized (using Debian standard way to do so) ?
On 03/12/2018 11:58, Andreas Beckmann wrote:
> Patches welcome! (Or a pull request against the repo on salsa.)
Well, maybe even simpler than a patch:
sed 's/__USER__/nvpd/g' \
init/systemd/nvidia-persistenced.service.template \
> debian/nvidia-persistenced.service
sed 's/__USER__/nvpd/g' \
init/sysv/nvidia-persistenced.template \
> debian/nvidia-persistenced.init
cat << EOF > debian/nvidia-persistenced.postinst
#!/bin/sh
set -e
case "$1" in
'configure')
if ! getent passwd nvpd >/dev/null; then
# Create ad-hoc system user/group
adduser --system --group \
--home /var/run/nvpd/ \
--gecos 'nVidia Persistence daemon' \
--no-create-home \
nvpd
fi
;;
esac
#DEBHELPER#
EOF
PS: you picked my curiosity; I'll have a look at what "salsa" might be ;-)
> We will probably not "fix" this for stretch (but stretch-backports),
> unless someone gets this approved by the release team (but let's have
> this in sid first.)
Totally understand.
It'd be nice to have it in Buster though.
> And it should work with both systemd and legacy sysv.
Applied to latest (Unstable) 390.25 source package, this passes compilation
using pbuilder and produces a package with the ad-hoc /etc/init.d script
and /lib/systemd/system service file (debhelper >= 10 takes care of the
SysV/SystemD configuration; no need for dh-systemd build dependency).
And it installs and works OK on Stretch (SystemD).
I can't tell about SysV, though the nVidia init script looks simple
enough. Maybe an additional debian/nvidia-persistenced.default with a
"START={yes,no}" stanza might be needed (vs Debian Policy ?)
> Andreas
Thanks for your addressing this issue on such short notice.
Cédric
PS: In my effort to backport the latest upstream (410.78) drivers to Stretch
(we need CUDA 10 and serie 20** support), I personally used the (pre-compiled)
nvidia-persistenced available in the nVidia "*.run" package and included it
in my custom nvidia-graphics-driver source package
Bug#915381: Shouldn't nvidia-persistenced be daemonized (using Debian standard way to do so) ?
Package: nvidia-persistenced Version: 390.25-1 Hello, nVidia made it clear to us that nvidia-persistenced *really* should be running on (headless/no X server) CUDA nodes, because it does *more* than just keep the driver "up" (in particular, it fixes erroneous outputs from nvidia-smi; e.g. wrong GPU perf-state/load/memory accross multi-GPU setups). I see the current (Stretch) and latest (Unstable) Debian packaging of nvidia-persistenced does not enable the binary as a daemon (but merely provides example sysv/systemd/upstart scripts, in /usr/share/doc). Is there a reason the Debian package does not enable this binary as a (sysv+systemd) daemon, along creating the ad-hoc system user (e.g. "nvpd") for it ? If not, could this be looked into (I can provide input based on my own re-packaging of the daemon) ? Thanks for your work and best regards, Cédric -- Cédric Dufour @ Idiap Research Institute
Bug#772812: openvpn: No password prompt with pkcs11 (fix proposed)
Package: openvpn
Version: 2.4.6-1
Hello,
I managed to get OpenVPN 2.4.6 (backported to Debian/Stretch) to work along
PKCS#11 by:
- applying (attached) patch taken from
https://community.openvpn.net/openvpn/ticket/549
- applying (attached) patch inspired by
https://community.openvpn.net/openvpn/ticket/538 and taking into account Gert
Döring's comment
- *and* using patched/re-configured pkcs11-helper, as proposed in Debian bug
#907452: https://bugs.debian.org/907452
Since this issue has been around for years and no quick fix seems to be coming
from upstream, would you consider applying those patches as debian/patches ?
Thanks and best,
Cédric
--
Cédric Dufour @ Idiap Research Institute
Description: Fix for OpenVPN bug #538
---
Origin: upstream
Bug: https://community.openvpn.net/openvpn/ticket/538
Bug-Debian: https://bugs.debian.org/772812
Last-Update: 2018-08-28
--- openvpn-2.4.6.orig/src/openvpn/console.h
+++ openvpn-2.4.6/src/openvpn/console.h
@@ -83,7 +83,7 @@ bool query_user_exec_builtin(void);
*
* @return True if executing all the defined steps completed successfully
*/
-bool query_user_exec(void);
+bool query_user_exec(bool builtin);
#else /* ENABLE_SYSTEMD not defined*/
/**
@@ -92,7 +92,7 @@ bool query_user_exec(void);
*
*/
static bool
-query_user_exec(void)
+query_user_exec(bool builtin)
{
return query_user_exec_builtin();
}
@@ -109,11 +109,11 @@ query_user_exec(void)
static inline bool
query_user_SINGLE(char *prompt, size_t prompt_len,
char *resp, size_t resp_len,
- bool echo)
+ bool echo, bool builtin)
{
query_user_clear();
query_user_add(prompt, prompt_len, resp, resp_len, echo);
-return query_user_exec();
+return query_user_exec(builtin);
}
#endif /* ifndef CONSOLE_H */
--- openvpn-2.4.6.orig/src/openvpn/console_systemd.c
+++ openvpn-2.4.6/src/openvpn/console_systemd.c
@@ -95,13 +95,13 @@ get_console_input_systemd(const char *pr
*
*/
bool
-query_user_exec(void)
+query_user_exec(bool builtin)
{
bool ret = true; /* Presume everything goes okay */
int i;
/* If systemd is not available, use the default built-in mechanism */
-if (!check_systemd_running())
+if (builtin || !check_systemd_running())
{
return query_user_exec_builtin();
}
--- openvpn-2.4.6.orig/src/openvpn/misc.c
+++ openvpn-2.4.6/src/openvpn/misc.c
@@ -939,7 +939,9 @@ get_user_pass_cr(struct user_pass *up,
buf_printf(_prompt, "NEED-OK|%s|%s:", prefix, up->username);
if (!query_user_SINGLE(BSTR(_prompt), BLEN(_prompt),
- up->password, USER_PASS_LEN, false))
+ up->password, USER_PASS_LEN,
+ false,
+ BOOL_CAST(flags & GET_USER_PASS_FORCE_BUILTIN)))
{
msg(M_FATAL, "ERROR: could not read %s ok-confirmation from stdin", prefix);
}
@@ -1039,7 +1041,9 @@ get_user_pass_cr(struct user_pass *up,
buf_set_write(_resp, (uint8_t *)up->password, USER_PASS_LEN);
if (!query_user_SINGLE(BSTR(), BLEN(),
- response, USER_PASS_LEN, BOOL_CAST(ac->flags_ECHO)))
+ response, USER_PASS_LEN,
+ BOOL_CAST(ac->flags_ECHO),
+ BOOL_CAST(flags & GET_USER_PASS_FORCE_BUILTIN)))
{
msg(M_FATAL, "ERROR: could not read challenge response from stdin");
}
@@ -1073,7 +1077,7 @@ get_user_pass_cr(struct user_pass *up,
up->password, USER_PASS_LEN, false);
}
-if (!query_user_exec() )
+if (!query_user_exec(BOOL_CAST(flags & GET_USER_PASS_FORCE_BUILTIN)) )
{
msg(M_FATAL, "ERROR: Failed retrieving username or password");
}
@@ -1098,7 +1102,8 @@ get_user_pass_cr(struct user_pass *up,
if (!query_user_SINGLE(BSTR(), BLEN(),
response, USER_PASS_LEN,
- BOOL_CAST(flags & GET_USER_PASS_STATIC_CHALLENGE_ECHO)))
+ BOOL_CAST(flags & GET_USER_PASS_STATIC_CHALLENGE_ECHO),
+ BOOL_CAST(flags & GET_USER_PASS_FORCE_BUILTIN)))
{
msg(M_FATAL, "ERROR: could not retrieve static challenge response");
}
--- openvpn-2.4.6.orig/src/openvpn/misc.h
+++ openvpn-2.4.6/src/openvpn/misc.h
@@ -234,6 +234,8 @@ struct static_challenge_info {};
#define GET_USE
Bug#907452: OpenVPN deadlock when adding PKCS#11 provider (fix proposed)
Package: libpkcs11-helper1 Version: 1.24-1 Hello, In addition to OpenVPN deadlocking at PIN prompt as reported in debian bug #772812 (solved by adding a few patches): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=772812 OpenVPN will *also* deadlock when adding the PKCS#11 provider(s), before any PIN prompt attempt: https://lists.freedesktop.org/archives/p11-glue/2015-May/000555.html I managed to work around that issue in pkcs11-helper by: - including patch https://github.com/OpenSC/pkcs11-helper/commit/9b8debf331d7bd5eda1fa6feb322c0e31657e9b5 (incl. in version 1.25) - including patch https://github.com/OpenSC/pkcs11-helper/commit/4ea1afedec542b3f454dc6b02e86ef479d04a6ac (incl. in version 1.25.1) - *disabling* threading (--disable-threading and --disable-slotevent) Note that unless threading is disabled, OpenVPN will deadlock *even* when using the "management" interface, since the loading the PKCS#11 provider still happens during OpenVPN initialization (independently from the PIN prompt being offloaded to the management client): https://github.com/OpenSC/pkcs11-helper/issues/5 (alonbl's last comment before closing) I can't find back the reference to a comment stating that OpenVPN might be the only user, nowadays, of the pkcs11-helper. Based on my experience working with PKCS#11 along PAM, Kerberos, Firefox, Thunderbird and Chromium, I can tell only the OpenVPN package did pull the libpkcs11-helper-1 pakage as a dependency. The change proposed here should thus not affect too broad an audience. I know the culprit in all this seems to be OpenVPN but since this bug has been along for several years and nobody seems to be willing to address it, would you consider those changes nonetheless ? Thanks and best, Cédric -- Cédric Dufour @ Idiap Research Institute
Bug#897897: Kernel security fix (for CVE-2018-1108) -> AutoFS won't start
It seems this problem is adressed more globally as per bug #897599: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897599 Which led to fix for CVE-2018-1108 being reverted (temporarily ?), as per DSA 2018-4096: https://www.debian.org/security/2018/dsa-4196 -- Cédric Dufour @ Idiap Research Institute
Bug#897897: Kernel security fix (for CVE-2018-1108) -> AutoFS won't start
Package: autofs
Version: 5.1.2-1
Severity: important
Hello,
Following latest Debian/Stretch kernel (security) update - and the fix for
CVE-2018-1108 - autofs blocks until the kernel RNG reports its proper
initialization ("random: crng init done" in dmesg), which can take up to
*several minutes* in entropy-starving VMs.
Problem is the corresponding systemd unit is configured to timeout after 180
seconds. Past this timeout, AutoFS will be failed and won't start at all (until
manually restarted).
One can fix this issue by having entropy poured into the VMs using rng-tools
(along virtio-rng), haveged, etc.
I was wondering whether this might/ought not to be fixed in autofs itself ?
Best,
Cédric
PS: the (root) issue (kernel RNG blocking at boot) is already being discussed
on LKML: https://lkml.org/lkml/2018/4/29/121
--
Cédric Dufour @ Idiap Research Institute
Bug#895360: virsh cpu-stats -> cgroup CPUACCT controller is not mounted
Package: libvirt-daemon-system Version: 3.0.0-4+deb9u3 Hello, If one is to execute the following commands: 1. systemctl daemon-reload 2. service libvirtd restart (which are likely to happen as part of regular system updates) Subsequent virsh CPU statistics calls will fail with the following error messages: # virsh cpu-stats error: Failed to retrieve CPU statistics for domain '' error: Requested operation is not valid: cgroup CPUACCT controller is not mounted # virsh domstats --cpu-total Domain: '' [empty ouput] Netsearching around, I stumbled on: a. https://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/ b. https://github.com/moby/moby/pull/20633 (similar Docker-related issue) I can confirm the following workaround DOES solve the issue: cat << EOF > /etc/systemd/system/libvirtd.service.d/cgroup-delegation.conf [Service] Delegate=yes EOF Would you consider adding this setting to the stock (Debian) libvirtd unit file ? Thank you very much and best, Cédric Other ref: https://answers.launchpad.net/ubuntu/+question/665132 -- Cédric Dufour @ Idiap Research Institute
Bug#868501: tinyca2: Fails to retrieve/prefill country/organization/etc. for new certificates/requests
This issue prevents tinyca2 to retrieve the CA associated country/organization/etc. and prefill them as default for new certificates/requests. Thanks @ Rob for the patch, which I confirm fixes this issue. Any chance to have this patch included in Stable ? (it definitely should for Testing and following) Thanks and best Cédric
Bug#886985: Suggestion: make NSCD start "After=network.target" in systemd
package: nscd version: 2.24-11+deb9u1 severity: minor Hello, While troubleshooting my boot sequence with some custom SystemD units that rely on NSS LDAP user <-> UID resolutions, I found out that NSCD negative caching AND NSCD starting before the network is up was the cause of the failures of those units (even though they were startong after the network is up). In detail, as witnessed in Debian/Stretch: 1. NSCD starts before the network 2. an attempt for NSS LDAP user <-> uid resolution fails, since the network is not up (and LDAP is not available) 3. NSCD caches this negative result as per its "negative-time-to-live" configuration 4. network is up 5. further attenmpts for the same NSS LDAP user <-> uid resolution keep failing, because of NSCD negative cache, although LDAP is now fully available As could be expected, adding "After=network.target" to NSCD systemd service file solves the situation. Pros: - no negative caching of transient failures - all subsequent LDAP NSS calls are successful (and positively cached) Cons: - if many networked NSS queries are attempted by some service, the boot may be much delayed, according to /etc/ldap.conf NSS configuration (timeouts, retries, etc.) - BUT the service issuing those networked NSS queries ought to have its dependency fixed too (rather than using NSCD negative caching as a way to quickly bail out of failing networked NSS queries) Notes: except for the above "con", I don't see where adding this new network dependency may be a problem. NSS queries will still be carried out even if NSCD is not yet activated. Given we're speaking of the boot sequence, having NSCD not active until the network is up seems reasonable, given its main benenfit is to cache *networked* NSS queries (the slow ones). Just a suggestion, though. Thank you for your Debian work and best, Cédric -- Cédric Dufour @ Idiap Research Institute
Bug#884191: Please do not disable AppArmor silently and prevent its re-activation
Hello, On 16/12/17 10:02, Carsten Schoenert wrote: There is the AppArmor profile not re-enable? What let you came to that conclusion? As written before two commands are needed. $ sudo rm /etc/apparmor.d/disable/profile.name $ sudo apparmor_parser -r /etc/apparmor.d/profile.name It does work. Until the next update, where /etc/apparmor.d/disable/profile.name will re-appear (a deleted file in /etc in not considered a modified file by dpkg; hence the file will be re-installed from the package and AppArmor disabled again; that's what I tried to demonstrate with 'apt-get reinstall thunderbird') Or even better, help to smash down the count of currently open bugs about AppArmor issues in the Thunderbird profile! https://github.com/cedric-dufour/custom-conf/blob/master/generic/all/custom-conf-thunderbird/usr/share/custom-conf-thunderbird/config/etc/apparmor.d/usr.bin.thunderbird But it won't be of much help to most users. I really don't believe one can come up with a profile that satisfies the entire Debian users base and in the same time achieve what AppArmor is meant for. not so typical environment, most the users are not in that category. And all the big systems I know provide at least a configuration management and/or create own packages for their users and machines. I'll repackage thundebird and keep watching security updates closely to know when I must re-package it. When I do that for the 2900+ packages that makes our "Desktop" image, I'll launch my own distribution :-) But I'd rather stick and suport Debian for the time being (I even convinced my boss to donate to the Debian Project from time to time). I might not be a Debian Maintainer (I know I wouldn't be up to the task), but I do try to contribute constructively (by sending patches or attempting to document the source of problems as thoroughly as possible): https://duckduckgo.com/?q=%22cedric.dufour%22+site%3Abugs.debian.org You can close this bug. Regards, Cédric
Bug#884191: Please do not disable AppArmor silently and prevent its re-activation
Hello Carsten, On 12/12/17 21:38, Carsten Schoenert wrote: >>> I think we can implement this change by shipping a symlink to the >>> profile in /etc/apparmor.d/disable/. My understanding is that dpkg >>> will treat this removal of a conffile as a change worth preserving on >>> upgrades, i.e. it won't install the symlink again if it's >>> been deleted. >> >> I deleted the symlink and 'apt-get reinstall thunderbird' and the >> symlink is back, thus preventing re-activation of Thunderbird AppArmor >> profile. > > No need for a reinstallation the package, just remove the symlink and > let AppArmor parse the available profiles. > > $ sudo rm /etc/apparmor.d/disable/profile.name > $ sudo apparmor_parser -r /etc/apparmor.d/profile.name > What I meant is: as soon as the package gets updated again by the Debian Security Team, the AppArmor profile gets disabled again. Do you mean I have to keep watching security updates closely and run the formentionned hack on my 100+ affected hosts each time it needs to ? I'm sorry,m but this is not acceptable for entreprise system admnistration. >> Worse, this change affects even Jessie/OldStable, where AppArmor is >> silently disabled without sysadmin knowledge (I stumbled on this by >> mere chance). > > We do not make changes between releases normaly, only for things that are > really release depended like the GCC version. Well, this change did end up being pulled in by the Security Team. We enterprise sysadmins who stick to OldStable or Stable until we have carefully tested a new release before deploying it to several hundreds hosts were grown to be used to the fact that OldStable or Stable could be trusted. With the issue at hand (or others like: "chromium is no longer supported in OldStable" [sic]), there is a serious dent in that trust. >> As a solution to the issue at hand, I would suggest: >> - use debconf to prompt the user for AppArmor enable/disable > > The debconf mechanism is great for configuring basic *system* stuff but > a golden rule is to not bother "normal" users with questions he can't > really answer because they are simple users. So no, there will probably > never a be a debconf setting here. > >> - default to enable, since it is what makes sense if the apparmor >>package is installed and kernel-enabled (security=apparmor) > > That's the plan for the buster release, right now the current profile > isn't robust enough for most of the use cases. The profile needs to be > improved, there are no doubt about that. > >> - do the /etc/apparmor.d/disable symlink magic in postinst, based on >>the debconf choice > > That would require the existence if a debconf setup, that will not > happen as written above. > >> I hope this can be corrected back to Jessie, since this is serious >> security issue for those who enabled AppArmor knowingly. > > We wont change this behavior in the near future. As said, AppArmor can not be reliably re-enabled (without very dirty hacks monitoring the /etc/apparmor.d/disable symlinks does not re-appear). Please do consider changing your approach. If the debconf way is too complicated and you deem your AppArmor profile that broken, then another solution would be: 1. do NOT supply the profile in /etc/apparmor.d 2. provide a sample profile in /usr/share/doc/thunderbird/apparmor (along with a nice README) for those who know what they're up to Again, not being abale to re-enable AppArmor *reliably* (without dirty quirks) is really problematic for me. Thanks for considering again, Best, Cédric
Bug#884191: Please do not disable AppArmor silently and prevent its re-activation
Package: thunderbird Version: 1:52.5.0-1~deb8u1 severity: grave As stated as comment to the bug corresponding to the source of this issue (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882672): > I think we can implement this change by shipping a symlink to the > profile in /etc/apparmor.d/disable/. My understanding is that dpkg > will treat this removal of a conffile as a change worth preserving on > upgrades, i.e. it won't install the symlink again if it's > been deleted. I deleted the symlink and 'apt-get reinstall thunderbird' and the symlink is back, thus preventing re-activation of Thunderbird AppArmor profile. Worse, this change affects even Jessie/OldStable, where AppArmor is silently disabled without sysadmin knowledge (I stumbled on this by mere chance). This is very unfortunate, knowing my company relies on a carefully tuned - and working! - AppArmor profile for Thunderbird, as an important piece of its overall security setup. And we're very happy with it preventing who-knows-which binary to open who-knows-what-malware-ridden attachements! No longer now... I don't understand all the fuss about users complaining about AppArmor profiles not working. AppArmor is about *mandatory* access control, iow. explicitly specifying what actions are allowed. You can not expect to use AppArmor for what is intended for and ask for it to be OK with all possible use cases (in this latter case, you'd better not use AppArmor to start with, since it ends up to be nothing but security theater). As a solution to the issue at hand, I would suggest: - use debconf to prompt the user for AppArmor enable/disable - default to enable, since it is what makes sense if the apparmor package is installed and kernel-enabled (security=apparmor) - do the /etc/apparmor.d/disable symlink magic in postinst, based on the debconf choice I hope this can be corrected back to Jessie, since this is serious security issue for those who enabled AppArmor knowingly. Thanks and best, Cédric PS: I marked the severity as "grave" since it does "introduces a security hole allowing access to the accounts of users who use the package" for those who did rely on AppArmor to control Thunderbird bevahior along attachements. -- Cédric Dufour @ Idiap Research Institute
Bug#882672: thunderbird: Disable the AppArmor profile by default
Hello, > I think we can implement this change by shipping a symlink to the > profile in /etc/apparmor.d/disable/. My understanding is that dpkg > will treat this removal of a conffile as a change worth preserving on > upgrades, i.e. it won't install the symlink again if it's > been deleted. I deleted the symlink and 'apt-get reinstall thunderbird' and the symlink is back. Worse, this change affects even Jessie/OldStable, where AppArmor is silently disabled without sysadmin knowledge (I stumbled on this by mere chance). This is very unfortunate, knowing my company relies on a carefully tuned - and working! - AppArmor profile for Thunderbird, as an important piece of its overall security setup. And we're very happy with it preventing who-knows-which binary to open who-knows-what-malware-ridden attachements! No longer now... I don't understand all the fuss about users complaining about AppArmor profiles not working. AppArmor is about *mandatory* access control, iow. explicitly specifying what actions are allowed. You can not expect to use AppArmor for what is intended for and ask for it to be OK with all possible use cases (in this latter case, you'd better not use AppArmor to start with, since it ends up to be nothing but security theater). As a solution to the issue at hand, I would suggest: - use debconf to prompt the user for AppArmor enable/disable - default to enable, since it is what makes sense if the apparmor package is installed and kernel-enabled (security=apparmor) - do the /etc/apparmor.d/disable symlink magic in postinst, based on the debconf choice I hope this can be corrected back to Jessie, since this is serious security issue for those who enabled AppArmor knowingly. Thanks and best, Cédric -- Cédric Dufour @ Idiap Research Institute
Bug#852436: cups-browsed uses 100% CPU - SOLVED (patch attached)
On 09/08/17 10:02, Cédric Dufour - Idiap Research Institute wrote:
> I confirm this issue is still present is current Debian Stable/Stretch and
> renders CUPS unusable in network printing environments.
> I could backport the packages from testing or experimental, but then I would
> miss the updates from the Debian Security team (and looking at the updates
> history of CUPS filters/browsed in Debian OldStable/Jessie, it is not
> something I'm looking forwards to)
I tracked down the issue to a timeout when 'cups-browsed' interacts with the
local 'cups' server ("cupsDoFileRequest" call).
The 'cups-browsed' hard-coded timeout for such operations is 3 seconds.
This timeout is the cause of the witnessed "Unable to create/modify CUPS queue
(Success)!" error messages (and 'cups-browsed' looping infinitely in attempts
to add the failing printers/queues)
For large (fancy ?) PPDs, the local 'cups' server can take up to 8 (!) seconds
to process the addition of a remote printer queue based on the PPD retrieved
from the (BrowsePoll-ed) server (as witnessed on a 3.4GHz Intel I7-2600K test
host, during wich one CPU core is stuck at 100%).
The attached patch file - for cups-filters 1.11.6 (Debian/Stretch) - allows one
to configure the timeouts of both local and remote 'cups-browsed' HTTP
connections, thanks to the new "HttpLocalTimeout" and "HttpRemoteTimeout"
configuration settings. Setting the former to 10 seconds fixed the issue with
my troublesome PPDs/printers (INEO+ copiers).
Please note that this issue will still be present in 'cups-browsed' 1.16.0
along 'cups' 2.2.4, as backported from Testing and *verified* on Stretch.
(it should not be difficult to forward-port the attached patch, however)
I hope this patch can meet your approval for its addition in Debian patches
series and considered even for current Stable release (knowing that enterprise
environments with big printing beasts will be bound to stumble on the same
problem).
And do you have a privileged contact to propose this patch be included upstream
?
Best,
Cédric
diff -urN cups-filters-1.11.6.orig/utils/cups-browsed.c cups-filters-1.11.6/utils/cups-browsed.c
--- cups-filters-1.11.6.orig/utils/cups-browsed.c 2017-08-09 16:48:36.0 +0200
+++ cups-filters-1.11.6/utils/cups-browsed.c 2017-08-09 17:01:05.609442696 +0200
@@ -339,6 +339,8 @@
static guint update_netifs_sourceid = 0;
static char local_server_str[1024];
static char *DomainSocket = NULL;
+static unsigned int HttpLocalTimeout = 5;
+static unsigned int HttpRemoteTimeout = 10;
static ip_based_uris_t IPBasedDeviceURIs = IP_BASED_URIS_NO;
static unsigned int CreateRemoteRawPrinterQueues = 0;
static unsigned int CreateIPPPrinterQueues = 0;
@@ -579,6 +581,7 @@
int
http_timeout_cb(http_t *http, void *user_data)
{
+ debug_printf("HTTP timeout! (consider increasing HttpLocalTimeout/HttpRemoteTimeout value)\n");
return 0;
}
@@ -591,7 +594,7 @@
cupsEncryption());
}
if (local_conn)
-httpSetTimeout(local_conn, 3, http_timeout_cb, NULL);
+httpSetTimeout(local_conn, HttpLocalTimeout, http_timeout_cb, NULL);
else
debug_printf("cups-browsed: Failed creating http connection to local CUPS daemon: %s:%d\n", cupsServer(), ippPort());
@@ -2617,7 +2620,7 @@
p->port);
if (http) {
/* Check whether the printer is idle, processing, or disabled */
- httpSetTimeout(http, 2, http_timeout_cb, NULL);
+ httpSetTimeout(http, HttpRemoteTimeout, http_timeout_cb, NULL);
request = ippNewRequest(CUPS_GET_PRINTERS);
ippAddStrings(request, IPP_TAG_OPERATION, IPP_TAG_KEYWORD,
"requested-attributes",
@@ -3576,7 +3579,7 @@
p->timeout = current_time + TIMEOUT_RETRY;
break;
}
- httpSetTimeout(http, 3, http_timeout_cb, NULL);
+ httpSetTimeout(http, HttpLocalTimeout, http_timeout_cb, NULL);
/* Do not auto-save option settings due to the print queue creation
process */
@@ -3629,7 +3632,7 @@
p->no_autosave = 0;
break;
}
- httpSetTimeout(remote_http, 3, http_timeout_cb, NULL);
+ httpSetTimeout(remote_http, HttpRemoteTimeout, http_timeout_cb, NULL);
if ((loadedppd = cupsGetPPD2(remote_http, p->name)) == NULL &&
CreateRemoteRawPrinterQueues == 0) {
debug_printf("Unable to load PPD file for %s from the server %s:%d!\n",
@@ -5631,7 +5634,7 @@
return;
}
- httpSetTimeout(conn, 3, http_timeout_cb, NULL);
+ httpSetTimeout(conn, HttpRemoteTimeout, http_timeout_cb, NULL);
debug_printf ("cups-browsed [BrowsePoll %s:%d]: IPP-Cancel-Subscription\n",
context->server, context->port);
@@ -5772,7 +5775,7 @@
goto fail;
}
- httpSetTimeout(conn, 3, http_timeout_cb, NULL);
+ httpSetTimeout(conn, HttpRemoteTimeout, http_timeout_cb, NULL);
if (context->can_subscribe) {
if (context->subscription_
Bug#852436: cups-browsed uses 100% CPU (Stretch)
Hello, I confirm this issue is still present is current Debian Stable/Stretch and renders CUPS unusable in network printing environments. I could backport the packages from testing or experimental, but then I would miss the updates from the Debian Security team (and looking at the updates history of CUPS filters/browsed in Debian OldStable/Jessie, it is not something I'm looking forwards to) Can we hope in seeing this issue also fixed in Debian Stable/Stretch ? Thanks for your efforts, Cédric -- Cédric Dufour @ Idiap Research Institute
Bug#860225: bind9: CVE-2017-3137: A response packet can cause a resolver to terminate when processing an answer containing a CNAME or DNAME
Same here. Multi/redundant DNS servers do not help, the culprit recursive query being sent multiple times by client as each DNS server falls in turn. And multi- firewall/IPS doesn't help catching the faulty packets :-( I may state the obvious, but only workaround so far is (already saved the night a few times): $ cat /etc/cron.d/cve-2017-3137 # Make sure BIND9 has not crashed (cf. CVE-2017-3137) * * * * * root pgrep named >/dev/null || service bind9 restart (not so elegant however) Any hope Debian/Stable BIND gets patched ? (that's a pretty severe DoS vulnerability we have here) Thanks and sincerily, Cédric
Bug#808950: Broken ipvsadm init script (syncid) cont'd
I confirm this bug is still present in (now frozen) Stretch and prevents to setup a stateful redundant load-balancer (e.g. along corosync/pacemaker). Forementioned patch does solve the issue. It'd be nice if it could be considered for Stretch (and all upcoming releases): +1 ;-) Thanks and best, Cédric Dufour
Bug#827592: icedove: Cannot install add-on that requires restart (Unable to read add-on manifest / NS_ERROR_XPC_GS_RETURNED_FAILURE)
Package: icedove Version: 1:45.1.0-1~deb8u1 Severity: normal Dear Maintainer, Since Icedove 45, attempting to install an add-on that requires a browser restart fails with (at the time of restart): ERROR: Unable to read add-on manifest / NS_ERROR_XPC_GS_RETURNED_FAILURE The problem is exactly identical to that of Firefox 45 ESR -> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827591 The problem is known from upstream (for firefox) as: https://bugzilla.mozilla.org/show_bug.cgi?id=1277295 I can confirm that applying (to icedove) the patch mentioned at: https://bugzilla.mozilla.org/show_bug.cgi?id=1277295#c17 DOES solve the problem. I would be nice considering integrating this fix in Debian patches series. Thanks and best, Cédric -- System Information: Debian Release: 8.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64)
Bug#827591: firefox-esr: Cannot install add-on that requires restart (Unable to read add-on manifest / NS_ERROR_XPC_GS_RETURNED_FAILURE)
Package: firefox-esr Version: 45.2.0esr-1~deb8u1 Severity: normal Dear Maintainer, Since Firefox ESR 45, attempting to install an add-on that requires a browser restart fails with (at the time of restart): addons.xpi ERROR Unable to read add-on manifest from ~cdufour/.mozilla/firefox/cdufour.profile/extensions/staged/mousegesturessuite@lemon_juice.addons.mozilla.org: [Exception... "Component returned failure code: 0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE) [nsIJSCID.getService]" nsresult: "0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE)" location: "JS frame :: resource://gre/modules/XPCOMUtils.jsm :: XPCU_serviceLambda :: line 230" data: no] Stack trace: XPCU_serviceLambda()@resource://gre/modules/XPCOMUtils.jsm:230 XPCU_defineLazyGetter/<.get()@resource://gre/modules/XPCOMUtils.jsm:198 defineSyncGUID()@resource://gre/modules/addons/XPIProvider.jsm:1253 loadManifestFromDir<()@resource://gre/modules/addons/XPIProvider.jsm:1361 TaskImpl_run()@resource://gre/modules/Task.jsm:315 Handler.prototype.process()@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:933 this.PromiseWalker.walkerLoop()@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:812 this.PromiseWalker.scheduleWalkerLoop/<()@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:746 syncLoadManifestFromFile()@resource://gre/modules/addons/XPIProvider.jsm:1488 this.XPIProvider.processPendingFileChanges()@resource://gre/modules/addons/XPIProvider.jsm:3278 this.XPIProvider.checkForChanges()@resource://gre/modules/addons/XPIProvider.jsm:3566 this.XPIProvider.startup()@resource://gre/modules/addons/XPIProvider.jsm:2656 callProvider()@resource://gre/modules/AddonManager.jsm:227 _startProvider()@resource://gre/modules/AddonManager.jsm:833 AddonManagerInternal.startup()@resource://gre/modules/AddonManager.jsm:1016 this.AddonManagerPrivate.startup()@resource://gre/modules/AddonManager.jsm:2782 amManager.prototype.observe()@resource://gre/components/addonManager.js:58 The problem is known from upstream as: https://bugzilla.mozilla.org/show_bug.cgi?id=1277295 I can confirm that applying the patch mentioned at: https://bugzilla.mozilla.org/show_bug.cgi?id=1277295#c17 DOES solve the problem. It would be nice considering integrating this fix in Debian patches series. Thanks and best, Cédric -- Addons package information ii firefox-esr45.2.0esr-1~ amd64Mozilla Firefox web browser - Ext -- System Information: Debian Release: 8.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64)
Bug#814340: CUPS won't start at boot (systemd)
Hello Brian, Thank you for your follow up. There something I don't understand and maybe you can clarifiy it for me (see below) On 13/02/16 00:19, Brian Potkin wrote: > On Wed 10 Feb 2016 at 15:50:53 +0100, Cédric Dufour - Idiap Research > Institute wrote: > > >> I have found that CUPS will not start at boot if the /var/spool/cups >> directory contains no d* files (job files). >> This is the case for a brand new CUPS installation or if > A brand new CUPS installation has no need of a listening daemon. There > are no local print queues and cupsd listens only on localhost and the > socket file in /var/run/cups. If printing is attempted to either a > created or non-existent queue cups.service will be activated via > cups.socket. > Unless there is something that I miss entirely, listening on localhost:631 (the all LAN in my case; cf. campus print servers) implies a daemon (cupsd): * r...@cups01.idiap.ch:~ # netstat -tpan | fgrep :631 tcp0 0 0.0.0.0:631 0.0.0.0:* LISTEN 4560/cupsd tcp6 0 0 :::631 :::*LISTEN 4560/cupsd When I said CUPS won't start, maybe I should have said that it is not listening on port 631 after boot (because cupsd did not start during boot). Again, unless there is something that I miss entirely, no amount of trying to reach the CUPS server (cupsd) on port 631 (from the LAN) will make it start. So I'm afraid there IS a bug in there: the CUPS daemon (cupsd) must start at boot for a LAN (*:631) CUPS server to serve its purpose. Best regards, Cédric
Bug#814340: CUPS won't start at boot (systemd)
Hello again, The issue at hand does not occur on hosts where 'cups-browsed' is also installed (I guess the cups.service somehow gets "pulled in" by /etc/systemd/system/multi-user.target.wants/cups-browsed.service; I don't understand, however, how /etc/systemd/system/paths.target.wants/cups.path comes into play and prevent CUPS to start when 'cups-browsed' is missing, but not if it is installed). I've been witnessing it, so far, on all three CUPS servers I have at hand, where 'cups-browsed' is not installed. 'hope this can help, Best, Cédric
Bug#814340: CUPS won't start at boot (systemd)
Package: cups-daemon Version: 1.7.5-11+deb8u1 Hello, I have found that CUPS will not start at boot if the /var/spool/cups directory contains no d* files (job files). This is the case for a brand new CUPS installation or if "PreserveJobFiles" is set to "No" in /etc/cups/cupsd.conf (eg. for large campus print servers, where keeping job files would require a lot of storage and may be the source of privacy issues). The culprit appears to be /lib/systemd/system/cups.path. If one changes: PathExistsGlob=/var/spool/cups/d* To: PathExists=/var/spool/cups (possible workaround/hack: touch /var/sppol/cups/d) CUPS starts at boot as expected. Thank you for considering this report. Best regards, Cédric -- Cédric Dufour @ Idiap Research Institute
Bug#793027: Missing QuoVadis G3 Root CAs (in Wheezy)
Hello On 21/07/15 17:54, Michael Shuler wrote: On 07/21/2015 09:05 AM, Cédric Dufour - Idiap Research Institute wrote: Would you plan to push an updated/backported ca-certificates in wheezy-updates ? Would security updates - e.g. removal of a compromised CA - make it to it ? I'm thinking that an upload of the jessie version, ca-certificates_20141019, may be appropriate for wheezy-updates, or just a rebuild with the Mozilla CA bundle from that version, excluding the additional changes. I'm not sure, yet. There is a bit of hand waving at the removal of 1024-bit CAs by Mozilla in the latest CA bundle currently in Stretch, and I don't want to be that disruptive in wheezy-updates (or jessie-updates, for that matter..) I'm afraid I can't be of much help as to this decision and I would not presume to dictate Debian policy on this matter. My 1-penny for the (old)stable branch: - missing trustworthy root CAs ought to be added (that the reason I reported this bug), especially if backed by the optional so-called volatile repo (which sysadmins may choose to use or not) - actually compromised or untrustworthy root CAs ought to be removed (iow. those that corresponds to CVE advisories); shouldn't such updates actually come from security.debian.org ? - in-between should be left as is But I am aware that cherry-picking those changes is a tedious job (and a great responsibility). Doesn't/shouldn't Debian Security Team have a say in this ? Best regards, Cédric You can dig around git and look through debian/changelog in the stable release branches, as well as master (sid/testing), for the CAs that Mozilla has added/removed. http://anonscm.debian.org/cgit/collab-maint/ca-certificates.git Jessie changelog: http://anonscm.debian.org/cgit/collab-maint/ca-certificates.git/tree/debian/changelog?h=debian-jessie -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793027: Missing QuoVadis G3 Root CAs (in Wheezy)
Hello, On 20/07/15 17:30, Cedric Dufour wrote: On 07/20/2015 09:57 AM, Cédric Dufour - Idiap Research Institute wrote: In Debian/Wheezy (oldstable), QuoVadis three G3 Root CAs - https://www.quovadisglobal.ch/Repository/DownloadRootsAndCRL.aspx - are missing from the 'ca-certificates' package (while they are present in Debian/Jessie). Would it be possible to add them (as we now receive server certificates that trace back to such G3 root issuing CAs) ? Does installing the ca-certificates package from Jessie cause any issues for you? Typically, backports is for packages that need rebuilding, due to the newer package not being installable, due to newer dependencies, etc. I'm pretty sure in your case, this should Just Work installing the newer version. Let me know if the version from Jessie does not install cleanly. Jessie package does install cleanly. As we have our own local mirror of Debian APT repository, I can deploy it easily enought to all our Wheezy hosts (we have 300+ Linux/Debian hosts). The only problem I see with this approach is that I have to monitor Jessie security updates closely and make sure to import any updated package in our Wheezy repository. I'd rather not mess with the APT configuration of our Wheezy hosts and add Jessie repositories along preferences/priorities/pinning, unless you tell me this is the recommended course of action from Debian point of view. Thanks for your reply (and the good work on Debian, our favorite OS ) Best, Cédric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793027: Missing QuoVadis G3 Root CAs (in Wheezy)
On 21/07/15 15:45, Michael Shuler wrote: Do you have a wheezy-updates (previously known as 'volatile') apt line enabled in your sources.list by default? That repo has far less accidental upgrade surface than having jessie in sources.list. That might be the better spot for an updated package to be uploaded for wheezy users. Thanks for checking! We do have the wheezy-updates repository enabled: # rgrep wheezy-updates /etc/apt/sources.list* /etc/apt/sources.list.d/debian.list:deb http://daily-updated-local-mirror/debian.wheezy/ wheezy-updates main contrib non-free /etc/apt/sources.list.d/debian.list:#deb-src http://mirror.switch.ch/ftp/mirror/debian/ wheezy-updates main contrib non-free Would you plan to push an updated/backported ca-certificates in wheezy-updates ? Would security updates - e.g. removal of a compromised CA - make it to it ? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793027: Missing QuoVadis G3 Root CAs (in Wheezy)
Package: ca-certificates Version: 20130119+deb7u1 Hello, In Debian/Wheezy (oldstable), QuoVadis three G3 Root CAs - https://www.quovadisglobal.ch/Repository/DownloadRootsAndCRL.aspx - are missing from the 'ca-certificates' package (while they are present in Debian/Jessie). Would it be possible to add them (as we now receive server certificates that trace back to such G3 root issuing CAs) ? Thanks and best regards, Cédric -- Cédric Dufour @ Idiap Research Institute -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701704: Please add --enable-filter-aaaa to configure/build options
Package: bind9
Version: 1:9.7.3.dfsg-1~squeeze9
Severity: wishlist
Tags: patch ipv6
*** body.txt
Hello,
BIND9 version 9.7.3 and above allows to specify the '--enable-filter-'
configure/build option, which in turns enables the 'filter--on-v4' and
'filter-' named configuration options.
Those options are very handy to achieve some IPv6 migration scenario.
Please find attach a patch in this respect.
Please also note that this patch slightly modifies /etc/init.d/bind9
and /etc/default/bind9 files in order to better handle BIND9 chroot-ed
instance(s).
This in particular:
- fixes '/etc/init.d/bind9 status' to fail because of wrong PIDFILE
(because it keeps using its non chroot-ed path)
- allows to specify 'rndc' options, allowing to handle multiple
chroot-ed instances gracefully
I hope this proposal meets your approval.
Best regards,
Cédric Dufour
-- System Information:
Debian Release: 6.0.7
APT prefers stable
APT policy: (990, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-amd64 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages bind9 depends on:
ii adduser 3.112+nmu2 add and remove users and groups
ii bind9utils 1:9.7.3.dfsg-1~squeeze9ced1 Utilities for BIND
ii debconf [deb 1.5.36.1Debian configuration management sy
ii libbind9-60 1:9.7.3.dfsg-1~squeeze9ced1 BIND9 Shared Library used by BIND
ii libc62.11.3-4Embedded GNU C Library: Shared lib
ii libcap2 1:2.19-3support for getting/setting POSIX.
ii libdb4.6 4.6.21-16 Berkeley v4.6 Database Libraries [
ii libdns69 1:9.7.3.dfsg-1~squeeze9ced1 DNS Shared Library used by BIND
ii libgssapi-kr 1.8.3+dfsg-4squeeze6MIT Kerberos runtime libraries - k
ii libisc62 1:9.7.3.dfsg-1~squeeze9ced1 ISC Shared Library used by BIND
ii libisccc60 1:9.7.3.dfsg-1~squeeze9ced1 Command Channel Library used by BI
ii libisccfg62 1:9.7.3.dfsg-1~squeeze9ced1 Config File Handling Library used
ii libldap-2.4- 2.4.23-7.3 OpenLDAP libraries
ii liblwres60 1:9.7.3.dfsg-1~squeeze9ced1 Lightweight Resolver Library used
ii libssl0.9.8 0.9.8o-4squeeze14 SSL shared libraries
ii libxml2 2.7.8.dfsg-2+squeeze6 GNOME XML library
ii lsb-base 3.2-23.2squeeze1Linux Standard Base 3.2 init scrip
ii net-tools1.60-23 The NET-3 networking toolkit
ii netbase 4.45Basic TCP/IP networking system
bind9 recommends no packages.
Versions of packages bind9 suggests:
pn bind9-docnone (no description available)
ii dnsutils 1:9.7.3.dfsg-1~squeeze9ced1 Clients provided with BIND
pn resolvconf none (no description available)
pn ufw none (no description available)
-- Configuration Files:
/etc/bind/named.conf.local changed [not included]
/etc/bind/named.conf.options changed [not included]
/etc/init.d/bind9 changed [not included]
-- debconf information excluded
diff -urN bind9-9.7.3.dfsg.orig//debian/bind9.init bind9-9.7.3.dfsg/debian/bind9.init
--- bind9-9.7.3.dfsg.orig//debian/bind9.init 2013-02-26 12:13:39.0 +0100
+++ bind9-9.7.3.dfsg/debian/bind9.init 2013-02-26 12:49:34.0 +0100
@@ -18,14 +18,15 @@
# for a chrooted server: -u bind -t /var/lib/named
# Don't modify this line, change or create /etc/default/bind9.
OPTIONS=
+RNDCOPTIONS=
RESOLVCONF=no
+PIDFILE=/var/run/named/named.pid
test -f /etc/default/bind9 . /etc/default/bind9
test -x /usr/sbin/rndc || exit 0
. /lib/lsb/init-functions
-PIDFILE=/var/run/named/named.pid
check_network() {
if [ -x /usr/bin/uname ] [ X$(/usr/bin/uname -o) = XSolaris ]; then
@@ -82,7 +83,7 @@
if [ X$RESOLVCONF != Xno ] [ -x /sbin/resolvconf ] ; then
/sbin/resolvconf -d lo.named
fi
- pid=$(/usr/sbin/rndc stop -p | awk '/^pid:/ {print $2}') || true
+ pid=$(/usr/sbin/rndc ${RNDCOPTIONS} stop -p | awk '/^pid:/ {print $2}') || true
if [ -z $pid ]; then # no pid found, so either not running, or error
pid=$(pgrep -f ^/usr/sbin/named) || true
start-stop-daemon --stop --oknodo --quiet --exec /usr/sbin/named \
@@ -104,7 +105,7 @@
log_end_msg 1
fi
- /usr/sbin/rndc reload /dev/null log_end_msg 0 || log_end_msg 1
+ /usr/sbin/rndc ${RNDCOPTIONS} reload /dev/null log_end_msg 0 || log_end_msg 1
;;
restart)
diff -urN bind9-9.7.3.dfsg.orig//debian/bind9.postinst bind9-9.7.3.dfsg/debian/bind9.postinst
--- bind9-9.7.3.dfsg.orig//debian/bind9.postinst 2013-02-26 12:13:39.0 +0100
+++ bind9-9.7.3.dfsg/debian/bind9.postinst 2013-02-26 12:41:03.0 +0100
@@ -77,6 +77,14 @@
else
echo OPTIONS=\\ $config
fi
+
+echo '' $config
+echo '# PID file (update for chrooted
Bug#659174: back-sql segfaults on amd64, but not on i386
Package: slapd Version: 2.4.23-7.2 Severity: normal Hello, This bug also affects me. RedHat has a fix for version 2.4.23: https://bugzilla.redhat.com/show_bug.cgi?id=727533 adapted from fix committed for version 2.4.25 in openldap GIT: http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commitdiff;h=0a9f51f58d1e20f92ad2f6a21c70ca04304a7f93 Can you please consider applying this fix in Debian/Squeeze? Note: this bug leads to DoS of the LDAP server as soon as one issues a query involving the SQL backend. Thanks in best regards, Cédric Dufour -- System Information: Debian Release: 6.0.6 APT prefers stable APT policy: (990, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages slapd depends on: ii adduser3.112+nmu2add and remove users and groups ii coreutils 8.5-1 GNU core utilities ii debconf [debconf-2.0] 1.5.36.1 Debian configuration management sy ii libc6 2.11.3-4 Embedded GNU C Library: Shared lib ii libdb4.8 4.8.30-2 Berkeley v4.8 Database Libraries [ ii libgnutls262.8.6-1+squeeze2 the GNU TLS library - runtime libr ii libldap-2.4-2 2.4.23-7.2OpenLDAP libraries ii libltdl7 2.2.6b-2 A system independent dlopen wrappe ii libperl5.105.10.1-17squeeze3 shared Perl library ii libsasl2-2 2.1.23.dfsg1-7Cyrus SASL - authentication abstra ii libslp11.2.1-7.8 OpenSLP libraries ii libwrap0 7.6.q-19 Wietse Venema's TCP wrappers libra ii lsb-base 3.2-23.2squeeze1 Linux Standard Base 3.2 init scrip ii perl [libmime-base64-p 5.10.1-17squeeze3 Larry Wall's Practical Extraction ii psmisc 22.11-1 utilities that use the proc file s ii unixodbc 2.2.14p2-1ODBC tools libraries Versions of packages slapd recommends: ii libsasl2-modules 2.1.23.dfsg1-7 Cyrus SASL - pluggable authenticat Versions of packages slapd suggests: pn ldap-utilsnone (no description available) -- Configuration Files: /etc/default/slapd changed: SLAPD_USER=openldap SLAPD_GROUP=openldap SLAPD_PIDFILE= SLAPD_SERVICES=ldap:/// ldaps:/// SLAPD_OPTIONS= SLURPD_START=no SLURPD_OPTIONS= -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
