Bug#611661: Bundled plugins using Xinha allow malicious file uploads
On 13-May-12 21:25, Moritz Mühlenhoff wrote: On Sun, May 13, 2012 at 06:04:03PM +0100, Steve McIntyre wrote: On Tue, Mar 08, 2011 at 10:37:13PM +0100, Moritz Muehlenhoff wrote: Looking at other bugs and security tracker issues in serendipity, I'd be tempted to remove it from Debian anyway... I suggested the same some time ago and Thijs (added to CC) said that removing it from testing would be the first step (which we did back then). Thijs, what's your take on dropping s9y for Wheezy? Cheers, Moritz Hi, #611661 has been pending upload for a while. Yeah, maybe I should've pinged Thijs sooner. I am committing a fix for #650937 now. I'm currently trying to find out what to do to fix the latest one. BFN -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#595594: (no subject)
tags 595594 +pending thanks Ok, our own database functions now exit even more gracefully on failure. The previous fix (586759) seemed to address a similar issue but only when dbconfig itself was failing, not the DB behind. Greets, JM For reference, here's the link to the full discussion about this matter: https://secure.a-eskwadraat.nl/archive/phpbb-l/2010-September/000736.html -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564556: [pkg-lighttpd] Bug#564556: Bug#564556: lighttpd still unusable by default
On 30-Aug-10 18:51, Olaf van der Spek wrote: If you want, that your new build gets uploaded to Debian by a sponsor, you have to build and check your package+changes+diff and after that upload the whole to any space with the .dsc etc. A sponsor should not be necessary, as Lighttpd has three uploaders: Krzysztof Krzyżaniak (eloy) (u), Torsten Marek (u), Pierre Habouzit (u) Oh well, uploader != uploader [0] [1] [0] http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Uploaders [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=581011 Just my 2c. Greetings, -- JM -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#586759: fails to install
Technically, the failure is trigged by the set -e of the maintainer script, since dbc_go fails. This is by no means a failure of the phpbb3 package, only a consequence of the failure of dbconfig-common. As far as debconf is concerned, people use db_go || true -- I have seen no such call for dbc_go, however s9y uses an if-construct to achieve the same goal, I believe. However, in this case, I wonder why dbconfig-common failed -- there should be a question if it is supposed to be used at all for that package, which probably is what the bug reporter intended to (not) do, and if properly answered with No it would not have been used and therefore not have produced any errors -- not sure how piuparts handles the part of configuring the package for test. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#542695: cannot use crypto loop aes
Package: loop-aes-modules-2.6.26-2-686 Version: 2.6.26+3.2c-6+lenny1 Severity: grave Justification: renders package unusable # aptitude install loop-aes-modules-2.6.26-2-686 # modprobe loop-aes # lsmod | grep loop loop 55372 0 # dmesg | tail -3 [ 4457.015307] loop: module loaded [ 4521.947610] loop: AES key scrubbing enabled [ 4521.948506] loop: loaded (max 8 devices) # losetup -v -e aes /dev/loop0 /dev/md0 Password: 123123123123123123123123123123123123 ioctl: LOOP_SET_STATUS: Invalid argument # losetup -v -e AES256 /dev/loop0 /dev/md0 Password: 123123123123123123123123123123123123 ioctl: LOOP_SET_STATUS: Invalid argument # losetup -v -e aes-256 /dev/loop0 /dev/md0 Password: 123123123123123123123123123123123123 ioctl: LOOP_SET_STATUS: Invalid argument # losetup -v -e aes256 /dev/loop0 /dev/md0 Password: 123123123123123123123123123123123123 ioctl: LOOP_SET_STATUS: Invalid argument Additionally, the nomenclature for loop-aes is not sexy. (The others carry an underscore) /lib/modules/2.6.26-2-686/extra/loop-aes/loop_blowfish.ko /lib/modules/2.6.26-2-686/extra/loop-aes/loop_serpent.ko /lib/modules/2.6.26-2-686/extra/loop-aes/loop_twofish.ko /lib/modules/2.6.26-2-686/extra/loop-aes/loop-aes.ko I've tried the same thing with etchnhalf BTW, without success. In case someone is wondering about cryptoloop: # modprobe cryptoloop FATAL: Error inserting cryptoloop (/lib/modules/2.6.26-2-686/kernel/drivers/block/cryptoloop.ko): Unknown symbol in module, or unknown parameter (see dmesg) # dmesg | tail -2 [ 5144.988320] cryptoloop: disagrees about version of symbol loop_register_transfer [ 5144.988326] cryptoloop: Unknown symbol loop_register_transfer Please tell me I'm doing sth wrong and this is not all broken. -- System Information: Debian Release: 5.0.2 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-2-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages loop-aes-modules-2.6.26-2-686 depends on: ii linux-image-2.6.26-2-686 2.6.26-17lenny2 Linux 2.6.26 image on PPro/Celeron loop-aes-modules-2.6.26-2-686 recommends no packages. loop-aes-modules-2.6.26-2-686 suggests no packages. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541294: specter: Vanilla install segfaults
Package: specter
Version: 1.4-2+b1
Severity: grave
Justification: renders package unusable
strace start-stop-daemon --start --quiet --exec /usr/sbin/specter -- -d --uid
specter --gid specter
open(/etc/specter.conf, O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=3119, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7f8a000
read(3, #\n# Sample configuration file fo..., 4096) = 3119
_llseek(3, 0, [3119], SEEK_CUR) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Trial-and-error indicates that it does not seem to like --gid specter
(Yes, the group does exist):
# grep specter /etc/group
specter:x:124:
-- System Information:
Debian Release: 4.0
APT prefers oldstable
APT policy: (500, 'oldstable'), (200, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.24-etchnhalf.1-686
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages specter depends on:
ii adduser 3.102Add and remove users and groups
ii iptables1.3.6.0debian1-5 administration tools for packet fi
ii libc6 2.3.6.ds1-13etch9+b1 GNU C Library: Shared libraries
specter recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#479621: (no subject)
The following change, courtesy of the Ubuntu cacti-0.8.6i package,
fixes the problem:
/usr/share/cacti/include/config.php, line 86:
change:
if (!((is_file($_SERVER[SCRIPT_FILENAME])) (substr_count($_SERVER
[SCRIPT_FILENAME], $_SERVER[PHP_SELF] {
to:
if (!((is_file($_SERVER[SCRIPT_FILENAME])) (substr_count($_SERVER
[SCRIPT_FILENAME], basename($_SERVER[PHP_SELF]) {
Just make sure that if you fix the problem (again), that the fix is in
the spirit of the actual Cacti security advisory.
Currently, I am having a hard time seeing why exactly all these checks
are done. Maybe someone could elaborate? I only read something about XSS
and SQL injection. Why do these fixes prevent that?
Apparently, they have all not been written for the scenario where Cacti
is used via Aliases in Apache.
So instead of just doing something that makes the error disappear (and
potentially again creating security holes) please, someone who has the
insight, take a look.
Thanks for listening.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
