Bug#1005376: kill(1) with negative PIDs kills the current process group
Package: procps Version: 2:3.3.17-5 Severity: serious Dear maintainer, calling kill(1) with negative PIDs always delivers the signal to the current process group, instead of the one with the specified PID. That is because the binary always calls kill(2) with 0 as first argument. This is known and has been fixed upstream: https://gitlab.com/procps-ng/procps/-/issues/211 https://gitlab.com/procps-ng/procps/-/commit/79097e55e4b08ec8c1de8332e32cf03c4be1d4ec This bug affects both Debian stable (Bullseye) and testing/unstable. Best, Felix
Bug#1004149: python3-pip: Build isolation breaks editable system-wide installs
Package: python3-pip Version: 20.3.4-4 Severity: normal Dear maintainers, consider the following minimal Python project with setuptools packaging and a "pyproject.toml" file (see PEP 518 and [1]): > tree myproject myproject |-- myproject | `-- __init__.py |-- pyproject.toml |-- setup.cfg `-- setup.py Performing an editable system-wide install of this (i.e. running `pip install -e` outside a venv) results in a successful pip invocation, but a non-importable module: > python3 >>> import myproject Traceback (most recent call last): File "", line 1, in ModuleNotFoundError: No module named 'myproject' Everything works fine when a venv *or* a non-editable install is used instead. The reason for this is that the target files end up in "/usr/lib/python3.9/site-packages", which is not part of the default Debian Python module paths [2]: > ls /usr/lib/python3.9/site-packages easy-install.pth myproject.egg-link Having a PEP 518 package enables pip build isolation by default, which appears to cause the issue. One can work around it by using `pip install --no-build-isolation -e`. In that case, the target files are created in "/usr/local/lib/python3.9/dist-packages" instead. Best, Felix [1] https://setuptools.pypa.io/en/latest/build_meta.html [2] https://salsa.debian.org/cpython-team/python3-defaults/-/blob/master/policy/interpreter.rst
Bug#951056: Please backport Prometheus for Buster
Package: prometheus Version: 2.7.1+ds-3+b11 Severity: wishlist Dear maintainers, due to the rapid upstream development, the Prometheus version in Buster is already quite outdated. Could you please backport the version from Bullseye? Thanks and Regards, Felix
Bug#810546: openssh-client: hostkey verification fails checking/matching HostKeyAlgorithm; misreports offending HostKey
I can confirm this for openssh-client 1:7.4p1-10+deb9u1 on Stretch. It also affects OpenSSH 7.4p1 on macOS, so I guess it really is an upstream issue. Furthermore, the ssh_config manpage says about `HostKeyAlgorithms`: >[...], >ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521, >ssh-ed25519,ssh-rsa > > If hostkeys are known for the destination host then this default is > modified to prefer their algorithms. Reading this strictly, I assume "this default" only refers to the default value stated before and the sentence does not apply with custom `HostKeyAlgorithms`. There appears to be no option to also get the described behavior in that case. Best regards, Felix
Bug#858798: Wrong debug line numbers from g++ with varargs function
Package: g++ Version: 4:6.3.0-1 Severity: normal Dear maintainers, I observed some unexpected behavior with g++ (4:6.3.0-1) and GDB (7.12-6) on Stretch: Please have a look at the attached source file, which is the minimal example I could come up with to demonstrate the issue. We compile it (I tested on AMD64 with and without `-m32`, which made no difference): g++ -std=c++11 -Wall -Wextra -Wno-unused-but-set-variable -Wno-unused-parameter -O0 -g -o demo demo.cc … and execute it with GDB. Now we set a breakpoint on `func()`: (gdb) b func Breakpoint 1 at 0xa63: file demo.cc, line 20. This already seems strange, as line 20 clearly is the `return` statement of `func()` and not its begin! But let's see what actually is at address 0xa63: (gdb) disassemble func Dump of assembler code for function func(int, ...): 0x0a00 <+0>: push %rbp 0x0a01 <+1>: mov%rsp,%rbp 0x0a04 <+4>: push %r13 0x0a06 <+6>: push %r12 0x0a08 <+8>: push %rbx 0x0a09 <+9>: sub$0x108,%rsp 0x0a10 <+16>: mov%edi,-0x114(%rbp) 0x0a16 <+22>: mov%rsi,-0xc8(%rbp) 0x0a1d <+29>: mov%rdx,-0xc0(%rbp) 0x0a24 <+36>: mov%rcx,-0xb8(%rbp) 0x0a2b <+43>: mov%r8,-0xb0(%rbp) 0x0a32 <+50>: mov%r9,-0xa8(%rbp) 0x0a39 <+57>: test %al,%al 0x0a3b <+59>: je 0xa63 0x0a3d <+61>: movaps %xmm0,-0xa0(%rbp) 0x0a44 <+68>: movaps %xmm1,-0x90(%rbp) 0x0a4b <+75>: movaps %xmm2,-0x80(%rbp) 0x0a4f <+79>: movaps %xmm3,-0x70(%rbp) 0x0a53 <+83>: movaps %xmm4,-0x60(%rbp) 0x0a57 <+87>: movaps %xmm5,-0x50(%rbp) 0x0a5b <+91>: movaps %xmm6,-0x40(%rbp) 0x0a5f <+95>: movaps %xmm7,-0x30(%rbp) 0x0a63 <+99>: mov%rsp,%rax 0x0a66 <+102>: mov%rax,%rbx This clearly is not the `return` statement from line 20, but the end of the prologue. So the breakpoint appears to be set at the right location and only displayed wrongly. Let's confirm: (gdb) r Starting program: /home/felix/demo Breakpoint 1, func (a=1) at demo.cc:20 20return 0; (gdb) p $pc $1 = (void (*)(void)) 0x4a63 (gdb) s 5 size_t arg_num = 2; (gdb) p $pc $2 = (void (*)(void)) 0x4a69 (gdb) s 7 int arg_vals[arg_num]; (gdb) finish Run till exit from #0 func (a=1) at demo.cc:7 a is: 1 main (argc=1, argv=0x7fffe348) at demo.cc:25 25} Value returned is $3 = 0 If I'd have to guess, I'd say the wrong line number ended up in the debug symbols. Note that this also happens when explicitly trying to set a breakpoint on the `return` statement: (gdb) b demo.cc:20 Breakpoint 1 at 0xa63: file demo.cc, line 20. (gdb) r Starting program: /home/felix/demo Breakpoint 1, func (a=1) at demo.cc:20 20return 0; (gdb) s 5 size_t arg_num = 2; (gdb) finish Run till exit from #0 func (a=1) at demo.cc:5 a is: 1 main (argc=1, argv=0x7fffe348) at demo.cc:25 25} Value returned is $1 = 0 I have also checked the behavior on Jessie with (g++ 4:4.9.2-2, GDB 7.7.1+dfsg-5) and everything seems alright there. However, if I copy the binary from Strech over to Jessie, the error still occurs, so I believe this is a bug in g++ rather than in GDB. Best regards, Felix demo.cc Description: Binary data
Bug#839184: zkCli.sh unusable as packaged
Tags: patch Hi, sorry, I broke this with the patch from #830222: In commit 8c69d33, I moved the "JAVA" environment variable to the init script, as it cannot not be used in the systemd unit file (that requires absolute executable paths). However, other ZooKeeper tools rely on it being set in zkEnv.sh, which is symlinked to /etc/zookeeper/conf/environment on Debian. This not only affects zkCli.sh, but also zkCleanup.sh and zkServer.sh. Another similar situation occurs for zkServer.sh, which relies on "$ZOOCFGDIR". Even though that script is not used by the init files from zookeeperd, it is still part of the zookeeper package and should probably be working as well. I think the easiest solution is to just re-add the variables to the environment file, the attached patch does that. An alternative would be changing the scripts to not use "$JAVA" and "$ZOOCFGDIR", but that would required patching the upstream files. Or remove the symlink and use another zkEnv.sh (like the one from upstream), but I can't comprehend the implications of that. Best regards, Felix java-env.patch Description: Binary data
Bug#831302: Vagrant box allows root login with insecure default key
On 14 Jul 2016, at 15:16, Emmanuel Kasper wrote: > A fix for this issue has been committed yesterday, see > http://anonscm.debian.org/cgit/cloud/debian-vm-templates.git/commit/ Whoa, that's good timing I guess. Thanks and regards, Felix
Bug#831302: Vagrant box allows root login with insecure default key
Package: cloud.debian.org Severity: normal Tags: security Dear Debian cloud maintainers, in the "jessie64" Vagrant box (and presumably the other Vagrant boxes as well), the insecure Vagrant default SSH key is installed as authorized key for the root user and root login using SSH keys is permitted. Since Vagrant 1.7, the insecure default key is not used anymore by default. Instead, a random key is generated for the "vagrant" user on `vagrant up`. [1] This increases security when Vagrant machines are exposed outside their host, see [2] for the complete motivation. The Debian boxes, however, still allow root login using the insecure default key. From my understanding of Vagrant box creation [3], root login is not actually required and sudo is used. Otherwise, I'd suggest to use the temporary key for root as well (if that's possible) or remove the insecure default key after initial provisioning. Best regards, Felix [1] https://github.com/mitchellh/vagrant/pull/4707 [2] https://github.com/mitchellh/vagrant/issues/2608 [3] https://www.vagrantup.com/docs/boxes/base.html#default-user-settings
Bug#830222: systemd unit file for zookeeperd
Package: zookeeperd Version: 3.4.8-1 Severity: normal Tags: patch Dear maintainers, the attached patches (in git-format-patch format) add a systemd unit file for ZooKeeper to the zookeeperd package. Due to the way systemd works and an issue with dh-systemd (#830208), some changes were necessary to package files (see the individual commit messages for details). I tried to keep them as clean and compatible as possible. If you have any questions or suggestions, please let me know. Best regards, Felix systemd.patch Description: Binary data
Bug#830216: Build depends on dh-python, but it is not in Build-Depends
Source: zookeeper Version: 3.4.8-1 Severity: minor Tags: patch Dear maintainers, the package build for zookeeper uses dh-python, but is not mentioned in the Build-Depends list of debian/control so far. The attached patch fixes that. Regards, Felix dh-python.patch Description: Binary data
Bug#830208: dh_systemd_enable and dh_installinit both install unit files
Package: dh-systemd Version: 1.36 Severity: normal Dear dh-systemd developers, at the moment, systemd unit files get installed by both dh_installinit and dh_systemd_enable. There is a comment in dh_systemd_enable regarding this: > XXX: This is duplicated in dh_installinit, which is unfortunate. We do need > the service files before running dh_installinit though, every other solution > makes things much worse for all the maintainers. However, I could not find a corresponding bug report, so I decided to open this one. If you see no way to improve the situation, feel free to close it. I just encountered a case where this behavior led to practical problems: In the particular package, dh_installinit is called using `-d`, so that the 'd' suffix gets stripped from the unit file name. dh-systemd does not do that (and also has no such option), so it installs the same file with the 'd' suffix and both unit files end up in /lib/systemd/system. In this case, I was able to fix the issue by switching to `--name`, which is supported by dh_systemd_enable as well. But the underlying issue that both programs install the same files with potentially different configurations remains. Best regards, Felix
Bug#827455: cups-browsed unit file requires CUPS, but it is not a package dependency
Package: cups-browsed Version: 1.9.0-1 Severity: important Dear maintainers, the cups-browsed.service unit file specifies 'Requires', 'After' and 'Wants' directives on cups.service. However, the CUPS daemon is not a dependency of the cups-browsed package. Including the same unit in both 'Requires' and 'Wants' is needless anyway, as 'Wants' is a "weaker version" of 'Requires': https://www.freedesktop.org/software/systemd/man/systemd.unit.html This seems related to #812326. Thanks and regards, Felix -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages cups-browsed depends on: ii init-system-helpers 1.34 ii libavahi-client3 0.6.32~rc+dfsg-1 ii libavahi-common3 0.6.32~rc+dfsg-1 ii libavahi-glib1 0.6.32~rc+dfsg-1 ii libc62.22-11 ii libcups2 2.1.3-6 ii libglib2.0-0 2.48.1-1 ii libldap-2.4-22.4.42+dfsg-2+b2 Versions of packages cups-browsed recommends: ii avahi-daemon 0.6.32~rc+dfsg-1 cups-browsed suggests no packages. -- no debconf information
Bug#758035: libapache2-mod-wsgi: WSGIDaemonProcess python-path and home fails
This appears to have been fixed upstream in 4.4.1: https://groups.google.com/d/msg/modwsgi/IDqLeoc_VXU/Fy3ijUJ8rYsJ Regards, Felix -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#672232: isc-dhcp-client: client requests (and applies) properties, though removed from the request int the config
I can confirm such behaviour, but I don’t think it’s a bug: The `request` setting really only specifies what options the client’s request contains. The server then replies with some arbitrary options, which may or may not match the requested. The client applies whatever options that response contains. I verified using Wireshark that the protocol is being followed and options missing from the config really aren’t requested. I don’t think „rogue DHCP server“ is part of the threat model at this point: The client just trusts the server and if it’s a rogue one, the network admin is supposed to get rid of it and in the meantime, you’re also in trouble for the options you actually requested. However, there appears to be no way to just ignore certain options from the request: You can use `supersede`, but it only allows to force a specific value and not to remove the option entirely. See my Unix & Linux Stack Exchange question [1] on that. I filed a feature request for that with ISC, but unfortunately, they don’t have a public bugtracker. Regards, Felix [1] http://unix.stackexchange.com/q/120009 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#736548: monkeysign: Reports "key is expired, cannot sign" on non-expired key
I can confirm this as well. However, in my case it looks like it’s the key I’m signing with (my key) which has the expired subkeys. On 2.x, the error message looks different, but the error appears to be the same: cannot sign: [GNUPG:] KEYEXPIRED Regards, Felix -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#738731: build_slides fails of two reasons
On 16 Feb 2014, at 03:34, Felix Dreissig wrote: > You should probably send stdout to '/dev/null' as well. Gna. I meant stderr, of course. Regards, Felix -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#738731: build_slides fails of two reasons
On 14 Feb 2014, at 17:13, Antoine Beaupré wrote: > i have added a predicate so this doesn't fail if rst2s5 is missing, can > you try the 2.x branch again? The approach generally works, however I still see a "rst2s5: command not found" error message. It now just doesn’t emerge from the actual slides build, but from the has_rst2s5() check. You should probably send stdout to '/dev/null' as well. Thanks for the quick fixes! Regards, Felix -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#738732: build_trans fails if called seperately
Package: monkeysign
Version: 2.x
Severity: minor
If the build_trans() function is not called during the normal build or
installation process, but via `setup.py build_trans`, it fails with:
> distutils.errors.DistutilsGetoptError: invalid short option 'po/': must a
> single character or None
This is because of:
> ('po-dir', 'po/', 'directory where .po files are stored, relative to the
> current directory’)
in ‘translation.py'. 'po/' is probably intended to be a default value here, but
that’s not how `user_options` works.
It looks like it really should be a short option token, see
http://ilostmynotes.blogspot.de/2009/04/python-distutils-installer-and.html.
Regards,
Felix
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#738731: build_slides fails of two reasons
Package: monkeysign Version: 2.x Severity: minor There are two minor issues with the build_slides() function, which attempts to build 'presentation.html' from 'presentation.rst': 1. It is always part of the build, but `rst2s5` might not always be present. Thus it should either be removed from the standard build, or 'python-docutils' may be listed as a dependency on the website and not only in 'debian/control'. 2. Even if `rst2s5` is available, the command fails because ‘presentation.rst' is not in the top directory. Simly changing `file=` to `doc/presentation.rst` in 'setup.cfg' unfortunately breaks the way the output path is determined, but that is probably easily fixable. Regards, Felix -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#738730: build_manpage only works because of PyGTK encoding changes
Package: monkeysign
Version: 2.x
Severity: normal
I wanted to build the manpage only for Monkeysign’s CLI version, so I removed
`monkeyscan:monkeysign.gtkui:MonkeysignScanUi.parser` from ‘setup.cfg' and ran
`setup.py build_manpage`.
That failed with:
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 55:
> ordinal not in range(128)
An encoding problem didn’t make any sense to me, so I tried to track the issue
down. Turns out it doesn’t occur when PyGTK is imported into the build process,
either directly through 'gtkui.py' or via 'msg_exception.py'.
The explanation for this behaviour is that PyGTK sets Python’s default encoding
to UTF-8. This is GNOME bug 132040 from back in 2004:
https://bugzilla.gnome.org/show_bug.cgi?id=132040
So what exactly causes the above error?
It is the accent in your surname, anarcat, that causes manpage writing to fail
with ASCII encoding ;-). The best way to fix this would in my opinion be using
an unicode string for `author` in 'setup.py', but Disutils seem not to respect
that.
I used the following patch, which works:
> --- a/monkeysign/documentation.py
> +++ b/monkeysign/documentation.py
> @@ -84,7 +84,7 @@ class build_manpage(Command):
> def _write_footer(self, parser):
> ret = []
> appname = self.distribution.get_name()
> -author = '%s <%s>' % (self.distribution.get_author(),
> +author = '%s <%s>' % (self.distribution.get_author().decode('utf-8'),
>self.distribution.get_author_email())
> ret.append(('.SH AUTHORS\n.B %s\nwas written by %s.\n'
> % (self._markup(appname), self._markup(author
> @@ -109,7 +109,7 @@ class build_manpage(Command):
> path = os.path.join(self.output, parser.prog + '.1')
> self.announce('writing man page to %s' % path, 2)
> stream = open(path, 'w')
> -stream.write(''.join(manpage))
> +stream.write(''.join(manpage).encode('utf-8'))
> stream.close()
It might, however, not be the most comprehensive way to deal with the issue:
The whole process of generating manpages uses a mixture of ordinary and unicode
strings and might need some review with respect to encoding issues.
Best regards,
Felix
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#706766: arpspoof doesn't work without specifying target
Package: dsniff Version: 2.4b1+debian-22 Severity: important If the '-t' argument is missing, arpspoof should, according to its manpage, posion "all hosts on the LAN". However, as of dsniff_2.4b1+debian-22, that does no longer work. arpspoof will start just fine, but never actually send out any ARP replies and also don't log anything to the console. Everything works alright with dsniff_2.4b1+debian-21.1. (I'm unable to find that version in the Debian archives, however it is available from archive.ubuntu.com.) This might be related to #650751, which was fixed in the respective version and concerns the target handling. Regards, Felix -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
