Bug#1068594: gpg: 100% CPU endless loop after mkdir /etc/gnupg/gpg.conf
Package: gpg Version: 2.4.5-1 Severity: important X-Debbugs-Cc: debian-bug-re...@03.softkill.org Dear Maintainer, following creates an endless loop: sudo apt install gpg sudo mkdir -p /etc/gnupg/gpg.conf gpg --version Afterwards gpg becomes unusable system wide. To create the directory you usually need privileges, however my expectation is, that some empty directory like shown above should never do this type of harm! I mark this important, as this loop affects all gpg processes system wide and hence might be used to create a DoS if somebody somehow manages to create this file as a directory instead. Also the path /etc/gnupg/gpg.conf is not documented in man gpg. Undocumented paths should not be exploitable to create harm. Hence my expectation is that - this file should be documented - there should be a way to ignore this file such that gpg does not access this file - gpg should ignore errors this file if it is unreadable (like being a directory) I do not have any expectation about what happens when this is a file which includes errors. This should be part of the documentation. I tried to report this upstream, but failed, as I was unable to register. The bug affects stable, unstable and experimental and was tested on a VM. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-18-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gpg depends on: ii gpgconf 2.4.5-1 ii libassuan0 2.5.5-5 ii libbz2-1.0 1.0.8-5+b1 ii libc62.36-9+deb12u4 ii libgcrypt20 1.10.3-2 ii libgpg-error01.46-1 ii libnpth0t64 1.6-3.1 ii libreadline8t64 8.2-4 ii libsqlite3-0 3.40.1-2 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages gpg recommends: ii gnupg 2.4.5-1 gpg suggests no packages. -- no debconf information
Bug#840620: dkms still is mute in case of BUILD_EXCLUSIVE fails
Package: dkms Version: 2.3-2 Severity: important -- System Information: Debian Release: 9.9 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-8-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages dkms depends on: ii build-essential 12.3 ii coreutils8.26-3 ii dpkg-dev 1.18.25 ii gcc 4:6.3.0-4 ii kmod 23-2 ii make 4.1-9.1 ii patch2.7.5-1+deb9u2 Versions of packages dkms recommends: ii fakeroot 1.21-3.1 ii linux-headers-amd64 4.9+80+deb9u7 ii lsb-release 9.20161125 ii sudo 1.8.19p1-2.1 Versions of packages dkms suggests: ii menu2.1.47+b1 pn python3-apport -- no debconf information This bug was reported back in 2016 with a patch attached. The patch is fairly simple, highly effective and still applies cleanly (with some offset). stretch# cd /usr/sbin stretch# patch < /tmp/dkms.patch patching file dkms Hunk #1 succeeded at 1252 (offset 8 lines). buster# cd /usr/sbin buster# patch < /tmp/dkms.patch patching file dkms Hunk #1 succeeded at 1279 (offset 35 lines). Please merge or improve this! Thanks ;) - Motivation and why I marked it important: - This happened on my side when preparing Stretch for upgrade to Buster. I want to do this slowly, that is, first upgrade Stretch to the Buster kernel, let things settle a bit to rule out kernel issues, and then do the Buster upgrade of the base system. However this gave me following error: stretch# apt-get install linux-image-amd64/stretch-backports [..] Setting up linux-image-4.19.0-0.bpo.5-amd64 (4.19.37-4~bpo9+1) ... I: /vmlinuz.old is now a symlink to boot/vmlinuz-4.9.0-9-amd64 I: /initrd.img.old is now a symlink to boot/initrd.img-4.9.0-9-amd64 I: /vmlinuz is now a symlink to boot/vmlinuz-4.19.0-0.bpo.5-amd64 I: /initrd.img is now a symlink to boot/initrd.img-4.19.0-0.bpo.5-amd64 /etc/kernel/postinst.d/dkms: Error! The dkms.conf for this module includes a BUILD_EXCLUSIVE directive which does not match this kernel/arch. This indicates that it should not be built. /etc/kernel/postinst.d/initramfs-tools: update-initramfs: Generating /boot/initrd.img-4.19.0-0.bpo.5-amd64 [..] stretch# dkms autoinstall --kernelver 4.19.0-0.bpo.5-amd64 Error! The dkms.conf for this module includes a BUILD_EXCLUSIVE directive which does not match this kernel/arch. This indicates that it should not be built. But after the patch was manually applied: stretch# dkms autoinstall --kernelver 4.19.0-0.bpo.5-amd64 Error! The /var/lib/dkms/aufs/4.9+20161219/4.19.0-0.bpo.5-amd64/x86_64/dkms.conf for module aufs includes a BUILD_EXCLUSIVE directive which does not match this kernel/arch. This indicates that it should not be built. This is not perfect as the reported path does no more exist after the run: stretch# cat /var/lib/dkms/aufs/4.9+20161219/4.19.0-0.bpo.5-amd64/x86_64/dkms.conf cat: /var/lib/dkms/aufs/4.9+20161219/4.19.0-0.bpo.5-amd64/x86_64/dkms.conf: No such file or directory But it is quite better than to have no information at all: stretch# grep BUILD_EXCLUSIVE_KERNEL /var/lib/dkms/aufs/4.9+20161219/source/dkms.conf BUILD_EXCLUSIVE_KERNEL="^4.9.*" In my case this pinpoints the problem (for reference how to find yourself): stretch# ls -la /var/lib/dkms/aufs/4.9+20161219 total 16 drwxr-xr-x 4 root root 4096 Jul 31 10:53 . drwxr-xr-x 3 root root 4096 Jul 31 10:53 .. drwxr-xr-x 3 root root 4096 Oct 13 2018 4.9.0-8-amd64 drwxr-xr-x 3 root root 4096 Jul 31 10:50 4.9.0-9-amd64 lrwxrwxrwx 1 root root 26 Dec 17 2017 source -> /usr/src/aufs-4.9+20161219 stretch# dpkg -S /usr/src/aufs-4.9+20161219 aufs-dkms: /usr/src/aufs-4.9+20161219 stretch# apt-cache policy aufs-dkms aufs-dkms: Installed: 4.9+20161219-1 Candidate: 4.9+20161219-1 Version table: *** 4.9+20161219-1 500 500 http://httpredir.debian.org/debian stretch/main amd64 Packages 100 /var/lib/dpkg/status Which tells me that I have two choices: - Do not use the backports kernel and stay at Stretch for a while - Or update the base system to Buster now, including the kernel. (Note that the incompatibility of aufs to the backports kernel is no bug from my perspective, just some inconvenience.)
Bug#771529: laptop-mode-tools: Please half the height of /usr/sbin/lmt-config-gui to fit onto smaller screens of mobile computers
Package: laptop-mode-tools Version: 1.66-2 Severity: minor Dear Maintainer, the screen of my netbook is only 1024x600 (WSVGA), however there are linux driven minicomputers out there with a lot smaller screens, too. Running XFCE means, that some additional height is taken by the window titlebar and the system panel, too. In my case I can only access the buttons of the window when I remove the panel. Maximizing the window alone does not help. laptop-mode-tools are thought for machines with possibly much smaller screens, like netbooks and portable computers. Please make the tool fit on all those smaller screens. Note that I once had a Linux minicomputer with only 400 pixels screen height. If you ask me, all applications which are thought to run on mobile compters should fit into a 300x300 area to support all forms of smaller screens (portrait, landscape, etc.). As you can make them bigger, but not smaller. And if you ask me further, all applications can run on mobile computers, so fit to this premise ;) Thank you very much. I mask this bug minor, but apparently the tool is not usable on netbooks which are 3 years old. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (800, 'stable'), (700, 'testing-updates'), (700, 'stable-updates') Architecture: i386 (i686) Kernel: Linux 3.16.0-4-686-pae (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Shell: /bin/sh linked to /bin/dash Versions of packages laptop-mode-tools depends on: ii lsb-base4.1+Debian13+nmu1 ii psmisc 22.21-2 ii util-linux 2.25.2-3 Versions of packages laptop-mode-tools recommends: ii ethtool 1:3.16-1 ii hdparm 9.43-1.1 ii net-tools 1.60-26+b1 ii python-qt4 4.11.2+dfsg-1 ii sdparm 1.08-1 ii udev215-6 ii wireless-tools 30~pre9-8 Versions of packages laptop-mode-tools suggests: ii acpid 1:2.0.23-2 -- Configuration Files: /etc/laptop-mode/conf.d/usb-autosuspend.conf 732bf2223dc7dca51eb08b2e39b0a51f [Errno 2] No such file or directory: u'/etc/laptop-mode/conf.d/usb-autosuspend.conf 732bf2223dc7dca51eb08b2e39b0a51f' -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#741628: Perhaps the bug is outside rsync
FWIW I fist observed the problem today after upgrading from Ubuntu 13.10 to 14.04. The rsync based backup showed this error while processing a big VM image with largely unchanged portions (so delta was active). Thanks to this bug report, leaving away option -z (and doing compression on SSH level now) made it work again at my side. FYI: rsync remote data source is the (current) Ubuntu 14.04 with standard repos, local destination, which starts rsync via cron (and shows the error output), is my local backup host, a completely updated Wheezy (7.4), using ZFSonLinux BTW. ;) My speculations (I have no prove for anything): Ubuntu shares a good portion of Sid-code with Debian. Looks like 13.10 was unaffected so we have a good chance that 14.04 introduced the problem. Perhaps this allows to narrow down the search. Perhaps it is not directly a rsync based bug, but in a supporting library (libz?) or interoperability issue with the lib. But for me it looks more like an in-memory data corruption issue (off by one, optimization bug or similar). But that is only what my belly says. HTH (I do not need help, as there is a suitable workaround by leaving away -z). Sadly I have no time to look into it more deeply and cannot help further. There is no way to reproduce the problem at my side nor test if it vanished, as it already did. Thank you a lot, Debian, I owe you much. -- -Tino Valentin Hilbig; Am Sportfeld 5; 86482 Aystetten; Germany Tel. +49 821 4865787 http://valentin.hilbig.de/ http://permalink.de/tino/impressum
Bug#650851: Can confirm that it is fixed
The bug in the the archive apparently vanished a few seconds ago. curl -s http://security.debian.org/dists/lenny/updates/main/binary-i386/Packages.bz2 | bunzip2 | grep -q ^None && echo bug found curl -s http://security.debian.org/dists/lenny/updates/main/binary-i386/Packages.gz | gunzip | grep -q ^None && echo bug found Both do no more say "bug found" and more important: "apt-get update" with "deb http://security.debian.org/ lenny/updates" in /etc/apt/sources.list now works again. Thanks! -- -Tino Valentin Hilbig; Am Sportfeld 5; 86482 Aystetten; Germany Tel. +49 821 4865787 http://valentin.hilbig.de/ http://permalink.de/tino/impressum -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#642504: bash: file number exhaustion on certain redirections in loop: "Too many open files"
Package: bash
Version: 4.1-3
Severity: normal
Attached is bashbug.sh which shows a strange bug in bash - with workaround.
The problem seems to be that certain redirections are not closed in-time,
leading to a possible exhaustion of file descriptors when doing this
redirection in a loop.
The strange thing about this is, that the file descriptors are closed
later, when it is already too late.
There is a workaround, this is to close the redirection manually.
However technically this is wrong, as at the time of the close the
redirection is no more in effect.
Possibly this is an upstream problem, I did not test it.
-- System Information:
Debian Release: 6.0.2
APT prefers oldstable
APT policy: (500, 'oldstable'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.26-2-686 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
Versions of packages bash depends on:
ii base-files6.0squeeze2Debian base system miscellaneous f
ii dash 0.5.5.1-7.4POSIX-compliant shell
ii debianutils 3.4Miscellaneous utilities specific t
ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib
ii libncurses5 5.7+20100313-5 shared libraries for terminal hand
Versions of packages bash recommends:
pn bash-completion(no description available)
Versions of packages bash suggests:
pn bash-doc (no description available)
-- no debconf information
*** bashbug.sh
#!/bin/bash
#
# Out of file descriptors, because it forgets to close redirection
bug()
{
c=`ulimit -n`
let c+=100
while let c--
do
while read -ru3 x
do
echo -n :
done 3< <(echo x)
# Workaround:
# Explicite close of redirection
$1 || exec 3<&-
done
}
works()
{
c=`ulimit -n`
let c+=100
while let c--
do
while read -ru3 x
do
echo -n :
done 3<<<"x"
done
}
echo "triggering bug"
bug true
echo "run with bug workaround"
bug false
echo "different redirection"
works
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#437658: Typo correction
The sentence "So I consider it a bug as LimitExcept shall not affect access control of *other* HTTP methods." correctly should read "So I consider it a bug as LimitExcept shall not affect the *given* HTTP methods." And: My mother tongue is German, so please excuse my funny English. PS: Googlemail not yet knows my debian-bug-reply-Address. -- -Tino Valentin Hilbig; Am Sportfeld 5; 86482 Aystetten; Germany Tel. +49 821 4865787; USt-IdNr. DE219734816 http://valentin.hilbig.de/ http://permalink.de/tino/impressum -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#437658: apache: bad sideffects of Location+LimitExcept after upgrading Apache 1.3 from Sarge to Etch
Package: apache Version: 1.3.34-4.1 Severity: normal Hello, after upgrading from Sarge to Etch I found following apache configuration directives to have a bad sideffect: Order Allow,Deny Deny from all Satisfy all FYI this config was the last in my conf.d directory as suggested by http://httpd.apache.org/docs/1.3/sections.html The idea behind this directives is to globally disallow any request which is not POST, GET or HEAD. AFAIK this worked fine under Debian Sarge. Under Debian Etch this ignores all directives Order, Allow and Deny, even in .htaccess. This also affects access control using Oder, Allow and Deny in File-Sections which for instance disallow access to .htaccess files, such that .htaccess files get publicly accessible. After removing these config everything worked fine again. However Apache now answers all HTTP commands, not only GET, POST and HEAD, which can be considered a lowered security on my server. How to reproduce this problem (I did not test it on a fresh install): Use the default install of Debian Etch with mod_userdir active. Then as some user (non-root) do: mkdir public_html cd public_html cat >>.htaccess
Bug#299356: libapache-mod-php4: fsockopen no more relative to current directory on unix sockets
Package: libapache-mod-php4
Version: 4:4.3.10-8
Severity: normal
After upgrade to latest apache/php4 I noticed a different behavior of
fsockopen on unix domain sockets. Previously following worked:
[1] $fd = fsockopen("unixsocket",0);
Now you must replace this by
[2a]$pwd= getcwd();
[2b]$fd = fsockopen("$pwd/unixsocket",0);
to get the old behavior again where unixsocket was searched relative to
the path the script executed. I think the previous behavior shall be
desired one, as it's what you would expect that fsockopen does.
Please note that it makes no sense to me that now line [1] tries to open
/unixsocket (in fact it does this, I checked it) and the script has to
refer to/know it's CWD to get the desired behavior again.
If this is a safe mode issue, then the path shall be ignored alltogether
and the socket shall be caged into a safe mode directory (but I doubt
it has something to do with safe mode as the path works as expected).
I am not aware of any debian packages which rely on fsockopen with unix
sockets, but it broke one of my scripts (else I would not have come
across this issue) which ran on a variety of PHP installations before ..
Quick example to reproduce this bug:
Put script sock.php somewhere at your webbrowser's document root:
Call at a terminal:
umask 000; accept "http://www.scylla-charybdis.com/download/accept-2.0.0.tar.gz
# !!! Remember not to trust me, recompile accept yourself ;)
# I am not aware of other tools which are able to accept/connect to
# unix domain sockets (netcat etc. are only able to use TCP).
Now open sock.php from your webbrowser and notice the output of the
accept tool. How has the PHP script (which does not contain an absolute
path!) found the socket in /tmp ?
-Tino
PS: I checked the recent bugs and did not find fsockopen mentioned.
Sorry if this is a dupe. Thank you!
PPS: I was unable to reproduce this bug with the PHP4 CLI. CGI not
tested.
-- System Information:
Debian Release: 3.1
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.4.27
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages libapache-mod-php4 depends on:
ii apache-common 1.3.33-4 support files for all Apache webse
ii debconf [debconf-2.0] 1.4.30.11Debian configuration management sy
ii libbz2-1.0 1.0.2-5 high-quality block-sorting file co
ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an
ii libcomerr2 1.35-6 The Common Error Description libra
ii libdb4.24.2.52-18Berkeley v4.2 Database Libraries [
ii libexpat1 1.95.8-1 XML parsing C library - runtime li
ii libkrb531.3.6-1 MIT Kerberos runtime libraries
ii libmagic1 4.12-1 File type determination library us
ii libpcre34.5-1.1 Perl 5 Compatible Regular Expressi
ii libssl0.9.7 0.9.7e-2 SSL shared libraries
ii libzzip-0-120.12.83-4library providing read access on Z
ii mime-support3.28-1 MIME files 'mime.types' & 'mailcap
ii php4-common 4:4.3.10-8 Common files for packages built fr
ii zlib1g 1:1.2.2-3compression library - runtime
-- debconf information:
php4/update_apache_php_ini: true
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
