Bug#396204: xsupplicant: Vulnerable to remote root exploit (fixed by new upstream version)
Package: xsupplicant Version: 1.2.4.dfsg.1-2 Severity: critical Tags: security Justification: root security hole Hi, The upstream website mentions a new version which fixes a remote root exploit possibility: http://open1x.sourceforge.net/ Regards, Robbert -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-2-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages xsupplicant depends on: ii libc62.3.6.ds1-4 GNU C Library: Shared libraries ii libiw28 28-1Wireless tools - library ii libssl0.9.8 0.9.8c-3SSL shared libraries xsupplicant recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#389579: libapache-mod-auth-mysql: FTBFS against apache 2.2
Hi Roel, > Invalid command 'AuthUserFile', perhaps misspelled or defined by a > module > not included > in the server configuration This looks like a different issue. I don't think the AuthUserFile statement is needed for mysql authentication. I would think the message is caused by the fact that you didn't include the 'authn_file' module (which enables you to use 'AuthUserFile' statements in your Apache config). This is breakage from the apache2 -> apache2.2 upgrade. Can you try if a 'a2enmod authn_file' (and an apache restart) helps? Regards, Robbert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#339429: udev requires unix sockets when starting.
Package: udev Version: 0.074-3 Severity: critical Justification: breaks the whole system udev uses unix sockets. if those not available the system end in a state where the dev directory is empty and nothing works rebooting to single usermode with init=/bin/bash and adding the following line as first in the startup part of the init.d script solves this problem. ## fixes the unix socket problem modprobe unix ofcourse this doesn't help when there are no unix sockets available and the is no module. The startup script should check for those conditions before mounting an empty /dev partition in place. regards Robbert -- Package-specific info: -- /etc/udev/rules.d/: /etc/udev/rules.d/: total 0 lrwxr-xr-x 1 root root 20 Jul 27 10:23 020_permissions.rules -> ../permissions.rules lrwxrwxrwx 1 root root 19 Oct 19 15:32 025_libgphoto2.rules -> ../libgphoto2.rules lrwxrwxrwx 1 root root 16 Nov 11 09:08 025_libsane.rules -> ../libsane.rules lrwxr-xr-x 1 root root 19 Jul 27 10:23 cd-aliases.rules -> ../cd-aliases.rules lrwxr-xr-x 1 root root 13 Jul 27 10:23 udev.rules -> ../udev.rules lrwxrwxrwx 1 root root 19 Sep 7 15:29 z20_persistent.rules -> ../persistent.rules lrwxrwxrwx 1 root root 12 Jul 28 12:48 z50_run.rules -> ../run.rules lrwxrwxrwx 1 root root 16 Oct 19 15:41 z55_hotplug.rules -> ../hotplug.rules lrwxrwxrwx 1 root root 15 Sep 22 15:00 z60_hdparm.rules -> ../hdparm.rules lrwxrwxrwx 1 root root 17 Jul 28 12:48 z70_hotplugd.rules -> ../hotplugd.rules -- /sys/: /sys/block/hda/dev /sys/block/hda/hda1/dev /sys/block/hda/hda2/dev /sys/block/hda/hda3/dev /sys/block/hda/hda5/dev /sys/block/hdb/dev /sys/class/input/event0/dev /sys/class/input/event1/dev /sys/class/input/event2/dev /sys/class/input/event3/dev /sys/class/input/mice/dev /sys/class/input/mouse0/dev /sys/class/input/mouse1/dev /sys/class/misc/agpgart/dev /sys/class/misc/device-mapper/dev /sys/class/misc/hpet/dev /sys/class/misc/psaux/dev /sys/class/misc/rtc/dev /sys/class/printer/lp0/dev /sys/class/sound/adsp/dev /sys/class/sound/audio/dev /sys/class/sound/controlC0/dev /sys/class/sound/dsp/dev /sys/class/sound/mixer/dev /sys/class/sound/pcmC0D0c/dev /sys/class/sound/pcmC0D0p/dev /sys/class/sound/pcmC0D1c/dev /sys/class/sound/timer/dev /sys/class/usb_device/usbdev1.1/dev /sys/class/usb_device/usbdev2.1/dev /sys/class/usb_device/usbdev2.3/dev /sys/class/usb_device/usbdev3.1/dev /sys/class/usb_device/usbdev4.1/dev -- Kernel configuration: -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14.1-pundit.13 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages udev depends on: ii initscripts 2.86.ds1-5 Standard scripts needed for bootin ii libc6 2.3.5-8GNU C Library: Shared libraries an ii libselinux1 1.26-1 SELinux shared libraries ii libsepol1 1.8-1 Security Enhanced Linux policy lib ii lsb-base 3.0-11 Linux Standard Base 3.0 init scrip ii makedev 2.3.1-79 creates device files in /dev ii sed 4.1.4-4The GNU sed stream editor udev recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#394097: libapache2-mod-auth-pam: doesnt work with Apache > 2.1
> Since the auth mechanisms were changed in Apache 2.1 this module does > not work any more. It probably should be replaced by mod_authn_pam > available at http://mod-auth.sourceforge.net/docs/mod_authn_pam/ It works for me. Can you be more specific? I am going to lower this to 'important' as I am still able to use the package with apache 2.2.3-2, and would not like it to disappear while there's no mod_authn_pam package yet. Regards, Robbert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#388386: [patch]
Hi Eduard, I am a LUFS user too, so a few comments on this. Eduard Bloch wrote: > Stupid question: why do you need LUFS? I consider requesting its > removal > because almost everything has moved to FUSE or can be used with > lufis, > the fuse/lufs bridge. There is no lufis Debian package :( > Does curlftp do what you need? See > http://frank.thomas-alfeld.de/download/debian/curlftpfs/ Curlftpfs is buggy itself (see bts). I find it freezing now and then, while LUFS has worked perfectly for a long time. It would be nice if LUFS can stay, at least until there is a working substitute in Debian. Regards, Robbert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#522698: Exclude kfreebsd architecture from openntpd build?
Hi, For a while, noone seems to care about this grave openntpd bug on the kfreebsd platform. Because of this, the package was eventually removed from testing. For people running on different architectures than kfreebsd this is very unfortunate, because they did not suffer from this grave bug. Can't we just exclude kfreebsd-* from the Architecture field in debian/control so that we don't build the package for kfreebsd (pending the kfreebsd bug getting fixed)? Regards, Robbert -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#522698: Exclude kfreebsd architecture from openntpd build?
Hi Dererk, I'm afraid it's not yet so easy to debug on kfreebsd-* flavors, as the port lack most common (unless for me) debugging tools, therefore, you might understand it's not a matter like " noone cares". Ok, so I understand you are having problems debugging on kfreebsd for reasons that are beyond you. I would say this is even more reason to exclude kfreebsd from the build until the situation gets better. On the other hand, against what common sense could tell you, openntpd doesn't adjust the system's clock rate (it uses adjtime()), although Its something you take for granted when you install a software like this, it really ends up being more painful than useful for end-users that "just want their sandboxes clocked" (#306106). I understand that there may be other problems with the openntpd package, but I do not see them tagged 'grave' at this point. Therefore I do not think that bringing them into discussion here will change anything w.r.t. to this bug. Unfortunately, the only patch I could manage to get running on replacing adjtime() with adjtimex() didn't work as expected. [ OT for this bug ] Do you mean this patch? http://dtucker.freeshell.org/openntpd/patches/openntpd-3.6.1p1-linux-adjtimex.patch What is the problem with it? Regards, Robbert -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
