TLS 1.0 and 1.1 are still enabled by default in apache2

The following bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943415 was submitted in 2019 to request that TLS 1.0 and 1.1 be disabled by default, as already done for OpenSSL. But there is still no reaction from the Apache maintainers. Note also that TLS 1.0 and 1.1 were deprecated in RF

Re: /usr/games usage (Re: FTBFS when /bin is before /usr/bin in PATH?)

On 2025-05-09 17:26:25 +, Holger Levsen wrote: > On Fri, May 09, 2025 at 07:15:03PM +0200, Vincent Lefevre wrote: > > > jas@kaka:~$ ls /usr/games/|wc -l > > > 21 > > Indeed. I thought that there were a lot more in /usr/games. > > $ apt-file search /usr/game

Re: FTBFS when /bin is before /usr/bin in PATH?

On 2025-05-08 03:08:17 +0200, Simon Josefsson wrote: > I challenge that may be pre-mature optimization: > > jas@kaka:~$ ls /usr/bin/|wc -l > 4675 > jas@kaka:~$ ls /usr/games/|wc -l > 21 > jas@kaka:~$ Indeed. I thought that there were a lot more in /usr/games. -- Vincent Lefèvre - Web:

Re: FTBFS when /bin is before /usr/bin in PATH?

On 2025-05-07 18:18:25 +0200, Simon Josefsson wrote: > Vincent Lefevre writes: > > > On 2025-05-07 14:40:01 +0200, Simon Josefsson wrote: > >> I think a reasonable conservative system policy is PATH=/usr/bin and > >> anything beyond that is something the user or sys

Re: status of packages shipping sysv-init script without systemd unit

On 2025-05-07 17:45:51 +0200, Michael Biebl wrote: > Am 07.05.25 um 15:28 schrieb Vincent Lefevre: > > On 2025-05-07 12:37:35 +0200, Chris Hofstaedtler wrote: > > > * Vincent Lefevre [250507 11:06]: > > > > I can see in journalctl output: > > > >

Re: status of packages shipping sysv-init script without systemd unit

On 2025-05-07 15:03:40 +, Holger Levsen wrote: > On Wed, May 07, 2025 at 03:28:42PM +0200, Vincent Lefevre wrote: > > Yes, but then, shouldn't the severity be raised (as without > > a fix, they will no longer work in Trixie)? > > https://bugs.debian.org/cgi-

Re: FTBFS when /bin is before /usr/bin in PATH?

On 2025-05-07 14:02:15 +0200, Matthias Urlichs wrote: > That's not a problem, because today's default (according to my > /etc/login.defs) is "/usr/local/bin:/usr/bin:/bin" (plus /sbin for root, > plus …/games for non-root), i.e. with the symlinks last. Note that commands may be run via other ways

Re: FTBFS when /bin is before /usr/bin in PATH?

On 2025-05-07 14:40:01 +0200, Simon Josefsson wrote: > I think a reasonable conservative system policy is PATH=/usr/bin and > anything beyond that is something the user or system administrator have > to add. I think we should give up on /usr/games and move those > executables to /usr/bin, renaming

Re: status of packages shipping sysv-init script without systemd unit

On 2025-05-07 12:37:35 +0200, Chris Hofstaedtler wrote: > * Vincent Lefevre [250507 11:06]: > > I can see in journalctl output: > > > > May 07 10:25:13 qaa systemd-sysv-generator[1476564]: SysV service > > '/etc/init.d/dictd' lacks a native systemd unit

status of packages shipping sysv-init script without systemd unit

Hi, I can see in journalctl output: May 07 10:25:13 qaa systemd-sysv-generator[1476564]: SysV service '/etc/init.d/dictd' lacks a native systemd unit file, automatically generating a unit file for compatibility. May 07 10:25:13 qaa systemd-sysv-generator[1476564]: Please update package to incl

Re: FTBFS when /bin is before /usr/bin in PATH?

On 2025-05-06 12:31:08 +0100, Ahmad Khalifa wrote: > On 06/05/2025 10:34, Simon Josefsson wrote: > > podman run -it --rm debian:trixie > > apt-get update > > apt-get install -y --no-install-recommends gradle > > PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin > > gradle > > /bin/g

"ftp:" URLs in debian/copyright files

Hi, I've noticed lots of "ftp:" URLs in debian/copyright files. Isn't the "ftp:" URL scheme obsolete? At least it is no longer recognized by Firefox, which does a search on Google instead. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog:

Re: Misconfigured bookworm upgrades

On 2025-02-28 20:24:27 +0900, Simon Richter wrote: > Hi, > > On 2/28/25 19:57, Colin Watson wrote: > > > But seeing two users who seem to have their systems configured this way > > makes me wonder what's going on.  Does anyone know of documentation > > somewhere that recommends configuring stable

Re: Misconfigured bookworm upgrades

On 2025-02-28 16:52:57 +0100, Michael Biebl wrote: > unattended-upgrades uses this default configuration: > > > // "origin=Debian,codename=${distro_codename}-updates"; > > // "origin=Debian,codename=${distro_codename}-proposed-updates"; > > "origin=Debian,codename=${distro_codena

Re: Change the expectation that emails should wrap at 80 characters

On 2025-02-27 19:01:04 +0800, Blair Noctis wrote: > It's kinda funny how in this world in 2025, where and when all > computers possess processing power several magnitudes higher than > Apollo Guidance Computer, some still believe that text should be > pre-formatted to a fixed length no matter what,

Re: Change the expectation that emails should wrap at 80 characters

On 2025-02-26 18:38:41 +, Jeremy Stanley wrote: > Mutt's default configuration handles non-wrapped long lines fairly > gracefully, wrapping them at the last identifiable space character > before the terminal's margin, or at the last character if it's an > unbroken "word" longer than the termina

Debian Policy 4.7.1.0 and program names

Hi, On 2025-02-20 17:51:40 +0800, Sean Whitton wrote: > I just pushed version 4.7.1.0 of the Debian Policy Manual and related > documents to the binary-NEW queue for sid. > Below you will find the significant normative changes from the > previously-announced release of Policy (4.7.0.0). [...] > 10

Re: Y2038-safe replacements for utmp/wtmp and lastlog

On 2024-05-31 01:05:51 +0800, Jun MO wrote: > And if I understood correctly, wtmpdb require program use PAM to update > wtmpdb, thus program not use PAM will still write /var/log/wtmp. For > example, tmux write /var/log/wtmp via libutempter0 and I do not see tmux > depends on pam. GNU Screen and x

Re: Bug#1068017: Y2038-safe replacements for utmp/wtmp and lastlog

On 2024-05-30 18:41:51 +0200, Chris Hofstaedtler wrote: > wtmpdb takes over the "last" name. Unfortunately without support for > reading the old files. Nobody wrote tooling to import them or so. In the new versions of the package, "last" could have been installed under another name (e.g. last-lega

Re: Y2038-safe replacements for utmp/wtmp and lastlog

On 2024-05-08 16:53:53 +0800, Jun MO wrote: > For last(1) my concern is that it will be helped to keep the original > last(1) for back-compatibility to read old wtmp files. I agree, this may be useful. Unfortunately, the current status is that one cannot have both: installing wtmpdb forces the upg

Re: salsa web server broken?

On 2024-05-24 11:51:15 +0200, Alexander Wirt wrote: > Am Fri, May 24, 2024 at 11:23:44AM +0200 schrieb Vincent Lefevre: > > Is the salsa web server broken? > > > > The display of https://salsa.debian.org/python-team/packages/fail2ban > > is completely wrong, and https:/

salsa web server broken?

Is the salsa web server broken? The display of https://salsa.debian.org/python-team/packages/fail2ban is completely wrong, and https://salsa.debian.org/ gives an error 500 "We're sorry. Something went wrong on our end.". -- Vincent Lefèvre - Web: 100% accessible valida

Re: Policy: should libraries depend on services (daemons) that they can speak to?

On 2024-03-06 06:29:24 +0100, Jonas Smedegaard wrote: > Quoting Arnaud Rebillout (2024-03-06 02:26:00) > > However it's true that some packages are installed before that, at the > > debootstrap stage, and I guess debootstrap doesn't honor "Recommends:"? > > Correct. This is tracked as bug#742977

Re: Policy: should libraries depend on services (daemons) that they can speak to?

On 2024-01-15 11:15:32 -0500, Theodore Ts'o wrote: > For example, when I implemented libuuid, if you want to create a huge > number of UUID's very quickly, because you're a large enterprise > resource planning application, the the uuidd daemon will allow > multiple processes to request "chunks" of

Re: On merging bin and sbin

On 2024-02-28 12:25:13 +0100, Ansgar 🙀 wrote: > I totally agree: we should aim at moving all service binaries such as > daemons which are not directly invoked by users out of PATH to > /usr/lib{,exec} or similar to make shell completion more helpful. I disagree. The goal should not be to make shel

possible issues with downgrading and *.md5sums (was: Bug#1065022: libglib2.0-0t64: t64 transition breaks the systems)

[to debian-devel only] On 2024-03-01 10:13:18 +0100, Helmut Grohne wrote: > On Thu, Feb 29, 2024 at 06:53:56AM +0100, Paul Gevers wrote: > > Well, officially downgrading isn't supported (although it typically works) > > *and* losing files is one of the problems of our merged-/usr solution (see > >

Re: usrmerge breaks POSIX

On 2024-02-15 16:30:25 -0800, Russ Allbery wrote: > I was only able to find this discussion of why pkexec checks $SHELL, and > it doesn't support my assumption that it was an intentional security > measure, so I may well be wrong in that part of my analysis. Apologies > for that; I clearly should

Re: usrmerge breaks POSIX

On 2024-02-15 16:17:58 -0800, Russ Allbery wrote: > Vincent Lefevre writes: > > On 2024-02-15 14:14:46 -0800, Russ Allbery wrote: > > >> and pkexec is essentially a type of sudo and should be unavailable to > >> anyone who is using a restricted shell. > >

Re: usrmerge breaks POSIX

On 2024-02-15 14:14:46 -0800, Russ Allbery wrote: > Thorsten Glaser writes: > > > Right… and why does pkexec check against /etc/shells? > > pkexec checks against /etc/shells because this is the traditional way to > determine whether the user is in a restricted shell, Could you explain? This see

Re: usrmerge breaks POSIX

On 2024-02-15 17:18:43 +, Thorsten Glaser wrote: > Russ Allbery dixit: > > >3. Something else that I don't yet understand happened that caused pkexec > > to detect the shell as /usr/bin/mksh instead of /bin/mksh. I'm not > > What sets $SHELL for the reporter’s case? Fix that instead. $SHE

Re: usrmerge breaks POSIX

On 2024-02-15 09:00:57 -0800, Russ Allbery wrote: > I think the obvious solution is to ensure that both the /bin and /usr/bin > paths for mksh are registered in /etc/shells. In other words, I think we > have a missing usrmerge-related transition here that we should just fix. > I'm copying Thorsten

Re: usrmerge breaks POSIX

On 2024-02-15 16:59:28 +, Holger Levsen wrote: > On Thu, Feb 15, 2024 at 10:08:11AM +0100, Vincent Lefevre wrote: > > Not for mksh. > > so the subject should be "mksh is broken with usrmerge"? No, because my bug report about mksh was closed because it is not

Re: usrmerge breaks POSIX

On 2024-02-15 09:39:51 +0100, Marc Haber wrote: > On Thu, 15 Feb 2024 00:05:36 +0100, Vincent Lefevre > wrote: > >This is invalid. See > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817168 > > That doesnt answer the question asked, it is a bug from 20

Re: usrmerge breaks POSIX

On 2024-02-14 17:16:23 -0800, Russ Allbery wrote: > I have literally no idea what you're talking about. It would be really > helpful if you would describe what program rejected your setting and what > you expected to happen instead. Quoting https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817168

Re: usrmerge breaks POSIX

On 2024-02-14 10:41:44 -0800, Russ Allbery wrote: > Vincent Lefevre writes: > > > POSIX says: > > > SHELL This variable shall represent a pathname of the user's > > preferred command language interpreter. If this interpreter > >

Re: usrmerge breaks POSIX

On 2024-02-14 19:46:58 +0100, Ansgar 🙀 wrote: > Hi Vincent, > > On Wed, 2024-02-14 at 18:20 +0100, Vincent Lefevre wrote: > > POSIX says: > > > >   SHELL   This variable shall represent a pathname of the user's > >   preferred command lan

usrmerge breaks POSIX

POSIX says: SHELL This variable shall represent a pathname of the user's preferred command language interpreter. If this interpreter does not conform to the Shell Command Language in XCU Chapter 2 (on page 2345), utilities may behave differently from tho

mutt removed from testing while the bug was closed (fixed)

Hi, I've seen on https://tracker.debian.org/pkg/mutt that mutt was removed from testing on 2023-10-25, with a link to https://tracker.debian.org/news/1473564/mutt-removed-from-testing/ which says: -- FYI: The status of the mutt s

Re: mutt removed from testing while the bug was closed (fixed)

On 2023-10-26 02:03:49 +0200, Vincent Lefevre wrote: > Hi, > > I've seen on https://tracker.debian.org/pkg/mutt that mutt was > removed from testing on 2023-10-25, with a link to > > https://tracker.debian.org/news/1473564/mutt-removed-from-t

Re: Potential MBF: packages failing to build twice in a row

On 2023-08-15 09:38:32 +0200, Lucas Nussbaum wrote: > On 15/08/23 at 01:29 -0400, Michael Stone wrote: > > we don't know, since the test was "regenerate source"--a thing very few > > people care about--rather than "build twice" which is the thing people do > > seem to care about. It seems likely th

Re: Potential MBF: packages failing to build twice in a row

On 2023-08-13 16:32:03 -0500, John Goerzen wrote: > - Upstream wants to ship things that may get modified during build. Ie, > autoconf/automake replaces files they ship because they want it to > work "out of the box" in some fashion. Another example is > documentation; upstream may ship bui

nvidia-graphics-drivers-legacy-390xx uploaded 8 days ago but not yet installed

Hi, Bug 1042892 in nvidia-legacy-390xx-kernel-dkms was fixed on 2 August, and the packages for amd64 and i386 were built 8 days ago, but they are still in the "Uploaded" state (contrary to armhf): https://buildd.debian.org/status/package.php?p=nvidia-graphics-drivers-legacy-390xx What happens?

Bug#1021750: general: the nodelalloc mount option should be used by default for ext4 in /etc/fstab

On 2022-10-14 12:44:25 +0200, Marco d'Itri wrote: > On Oct 14, Vincent Lefevre wrote: > > > This is not "the Debian FAQ" but "the DPKG FAQ", which has been known to > > > recommend awful things in the past. > > But it is still considered

Bug#1021750: general: the nodelalloc mount option should be used by default for ext4 in /etc/fstab

On 2022-10-14 11:59:09 +0200, Marco d'Itri wrote: > On Oct 14, Vincent Lefevre wrote: > > > The /etc/fstab file is created using by default ext4 with just > > the errors=remount-ro option. However, the Debian FAQ recommends > > the nodelalloc mount option to avoi

Bug#1021750: general: the nodelalloc mount option should be used by default for ext4 in /etc/fstab

Package: general Severity: normal The /etc/fstab file is created using by default ext4 with just the errors=remount-ro option. However, the Debian FAQ recommends the nodelalloc mount option to avoid performance degradation and preserve data safety: https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Why_is

Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

On 2022-09-08 17:58:25 +0200, Dylan Aïssi wrote: > We cannot talk about PipeWire without mentioning its session manager. > Thus, this change should go along the switch of the default session manager, > i.e. from the deprecated pipewire-media-session to WirePlumber. > We still use pipewire-media-ses

Re: transition announcement: gsfonts + gsfonts-x11 -> fonts-urw-base35

Hi, On 2022-08-28 16:55:04 +0200, Fabian Greffrath wrote: [...] > A preliminary package fonts-urw-base35_20200910-3 to enable the > transition can be found in experimental, So, in case anyone want to > check how the transition works out, any help will be appreciated [5]. [...] > PS: Please keep me

Re: use of Recommends by vlc to force users to use pipewire

On 2022-05-31 14:55:44 +0500, Andrey Rahmatullin wrote: > On Tue, May 31, 2022 at 11:43:06AM +0200, Vincent Lefevre wrote: > > Indeed, this is what happened with pipewire 0.3.39-1, as I can see > > in my dpkg logs and the changelog: > > > > * Change priority order bet

Re: use of Recommends by vlc to force users to use pipewire

On 2022-05-31 11:43:06 +0200, Vincent Lefevre wrote: > Anyway, when I upgraded the vlc package two weeks ago, this had the > effect that PulseAudio was no longer used as the sound server (for > both vlc and ogg123), though pipewire was already installed (due to > a Recommends from lib

Re: use of Recommends by vlc to force users to use pipewire

On 2022-05-31 14:04:18 +0500, Andrey Rahmatullin wrote: > On Tue, May 31, 2022 at 10:55:55AM +0200, Vincent Lefevre wrote: > > > > a) pipewire package enables pipewire service by default > > > > > > Indeed, but pipewire service doesn't take control of audi

Re: use of Recommends by vlc to force users to use pipewire

On 2022-05-30 14:30:38 +0200, Dylan Aïssi wrote: > Le lun. 30 mai 2022 à 12:55, Jonas Smedegaard a écrit : > > a) pipewire package enables pipewire service by default > > Indeed, but pipewire service doesn't take control of audio over > pulseaudio. Only pipewire-pulse does that. This is incorre

Re: use of Recommends by vlc to force users to use pipewire

On 2022-05-28 10:41:34 +0200, Sebastian Ramacher wrote: > On 2022-05-28 01:27:13 +0200, Vincent Lefevre wrote: > > On 2022-05-27 12:34:26 +0100, Simon McVittie wrote: [...] > > > That's needed for Bluetooth audio, *if* you are using Pipewire for audio, > > > whic

Re: use of Recommends by vlc to force users to use pipewire

On 2022-05-27 12:34:26 +0100, Simon McVittie wrote: > If vlc-plugin-pipewire is prioritized higher than other audio backends, > then I can see how that could happen. It's probably premature for > vlc-plugin-pipewire to be prioritized higher than PulseAudio or ALSA in > Debian. > > The dependency g

Re: use of Recommends by vlc to force users to use pipewire

On 2022-05-26 23:55:02 +, Alberto Garcia wrote: > On Fri, May 27, 2022 at 01:03:57AM +0200, Jonas Smedegaard wrote: > > > It was actually due to a problem in Evolution that we made WebKitGTK > > > depend on xdg-desktop-portal (later downgraded to a recommendation): > > > > > > https://bugzilla

Re: use of Recommends by vlc to force users to use pipewire

On 2022-05-26 20:08:22 +0100, Simon McVittie wrote: > On Thu, 26 May 2022 at 17:21:27 +0200, Vincent Lefevre wrote: > > Here, this could be > > > > Recommends: pipewire | pulseaudio > > Those are not interchangeable. > > pipewire started as a multiplexer

Re: use of Recommends by vlc to force users to use pipewire

On 2022-05-17 08:54:59 -0400, Marvin Renich wrote: > There is, unfortunately, a catch here. In order for any of the > applications that require a sound server to work, one of them must be > installed. For example, mpd links with libasound, libpipewire, and > libpulse. If each of these libs simpl

Re: use of Recommends by vlc to force users to use pipewire

On 2022-05-16 16:14:02 +, Bill Allombert wrote: > On Mon, May 16, 2022 at 12:56:03AM +0200, Sebastian Ramacher wrote: > > And for the record: you get pipewire installed because libpipewire-0.3-0 > > recommends it. > > For a similar situation, I advocated to add a apt option so that apt > only

Re: use of Recommends by vlc to force users to use pipewire

On 2022-05-16 00:56:03 +0200, Sebastian Ramacher wrote: > On 2022-05-16 00:40:25 +0200, Vincent Lefevre wrote: > > The vlc package now uses a Recommends (vlc-plugin-pipewire) to force > > users to use pipewire instead of pulseaudio (which broke the use of > > VLC, but also a

use of Recommends by vlc to force users to use pipewire

The vlc package now uses a Recommends (vlc-plugin-pipewire) to force users to use pipewire instead of pulseaudio (which broke the use of VLC, but also apparently ogg123 with the alsa device). IMHO, this is a bad use of Recommends. It is not up to applications to choose what sound server to use, eve

Re: rebuild of rpcbind (and other packages?) due to old debhelper bug 993316

On 2022-04-08 18:55:14 +0500, Andrey Rahmatullin wrote: > On Fri, Apr 08, 2022 at 03:22:07PM +0200, Vincent Lefevre wrote: > > Bug 993316 was fixed on 23 September 2021. Any reason why rpcbind > > hasn't been rebuilt yet? > Was anything done for that to happen? Because

rebuild of rpcbind (and other packages?) due to old debhelper bug 993316

Hi, Due to the old bug 993316 in debhelper[*], rpcbind is still buggy as it hasn't been rebuilt yet: rpcbind_1.2.6-2_amd64.deb contains -rw-r--r-- root/root 626 2021-08-17 17:31:36 ./usr/lib/systemd/system/rpcbind.service -rw-r--r-- root/root 325 2021-08-17 17:31:36 ./usr/lib/system

Re: build-depend on autoconf-archive and rm convenience copy in orig.tar.gz?

On 2022-01-19 11:03:15 -0800, Russ Allbery wrote: > Jonas Smedegaard writes: > > > Thanks for elaborating. > > > The concern is not licensing, but maintenance. It is covered in Debian > > Policy § 4.13: > > https://www.debian.org/doc/debian-policy/ch-source.html#embedded-code-copies > >

Re: BTS not archiving Bcc: mails? [was: Re: inconsistent mailgraph settings]G

On 2021-08-23 07:43:07 +0100, Tim Woodall wrote: > On Mon, 23 Aug 2021, Holger Wansing wrote: > > Am 23. August 2021 07:19:26 MESZ schrieb Tomas Pospisek > > : > > > > > > The thing is, if you close a bug report via `Bcc: > > > -cl...@bugs.debian.org` then the mail that arrives at the

Re: inconsistent mailgraph settings

On 2021-08-21 10:36:04 +0200, Tomas Pospisek wrote: > In particular it *seems* to work for him and he doesn't have access to your > system where things apparently went wrong so it could be really hard for him > to know. So what you can do is to try to debug *yourself* why the upgrade > went wrong a

Re: BTS not archiving Bcc: mails? [was: Re: inconsistent mailgraph settings]

On 2021-08-22 23:32:15 +0500, Andrey Rahmatullin wrote: > On Sun, Aug 22, 2021 at 08:25:41PM +0200, Tomas Pospisek wrote: > > Wouldn't the Bcc'ed email that arrived to the BTS be visible in the bug's > > log/archive (on the bug's page (https://bugs.debian.org/989734))? > It's visible: https://bugs.

Re: Q: Use https for {deb,security}.debian.org by default

On 2021-08-20 12:11:30 -0700, Russ Allbery wrote: > The most naive attempt to mess with the update channel (intercepting the > http connection and replacing a package with a malicious one) will fail > immediately with both http or https. The primary difference in that case > with https is that the

inconsistent mailgraph settings

My bug report https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989734 has been closed again, with no explanations. While mailgraph was started on boot in the past, this stopped working with the upgrade to Debian 10, and I had to enable it again. So issues with the upgrade to Debian 11, but the ma

Re: Proposal: plocate as standard for bookworm

On 2021-02-09 22:12:31 +0100, Ansgar wrote: > "Steinar H. Gunderson" writes: > > On Sat, Feb 06, 2021 at 10:16:29PM -0800, Josh Triplett wrote: > >> Furthermore, any mechanism they use to configure one of them > >> (e.g. for privacy or performance reasons) will not control the other, > >> and again

Re: Mass bug filing: dependencies on GTK 2

On 2020-04-29 18:37:50 +0100, Simon McVittie wrote: > Given GTK 2's lack of feature development (for things like HiDPI) it > seems higher-severity than "a problem which doesn't affect the package's > usefulness", and it's certainly not "presumably trivial to fix" in > many cases. Note that missing

Bug#930908: general: incorrect rules for %s in /etc/mailcap yielding potentially unquoted metacharacters

On 2019-06-22 10:51:35 +0200, Vincent Lefevre wrote: > The /etc/mailcap file contains many rules with '%s' instead of %s, > for instance: > > text/*; less '%s'; needsterminal > audio/ogg; ogginfo '%s'; copiousoutput > > This is incorrect.

Bug#930908: general: incorrect rules for %s in /etc/mailcap yielding potentially unquoted metacharacters

On 2019-06-22 10:51:35 +0200, Vincent Lefevre wrote: > execve("/home/vinc17/bin/sh.screen", ["sh", "-c", "less > ''/var/tmp/_.txt''"], 0x564ffe666f40 /* 132 vars */) = 0 > > i.e. the filename is eventually not quoted! &

Bug#930908: general: incorrect rules for %s in /etc/mailcap yielding potentially unquoted metacharacters

On 2019-06-22 10:51:35 +0200, Vincent Lefevre wrote: [...] > as seen in strace output: > > execve("/home/vinc17/bin/sh.screen", ["sh", "-c", "less > ''/var/tmp/_.txt''"], 0x564ffe666f40 /* 132 vars */) = 0 FYI, the sh.

Bug#930908: general: incorrect rules for %s in /etc/mailcap yielding potentially unquoted metacharacters

Package: general Severity: grave Tags: security Justification: user security hole Affects: mutt The /etc/mailcap file contains many rules with '%s' instead of %s, for instance: text/*; less '%s'; needsterminal audio/ogg; ogginfo '%s'; copiousoutput This is incorrect. For instance, Mutt quotes th

Re: Debian, so ugly and unwieldy!

On 2019-06-07 17:24:17 +0200, Adam Borowski wrote: > * CSD is still a thing. No, your special program shouldn't get to ignore > system theme, put controls in wrong order, miss some controls, not respond > to minimize/etc if it's currently busy, etc. Consistency not one-off > designs. > >

Re: Potentially insecure Perl scripts

[resent with group-reply, sorry] On 2019-01-25 10:36:42 +, Dominic Hargreaves wrote: > Also, I think it's worth trying to identify what the worst extent > of the issue is. Whilst I don't agree with some who say that this isn't > a security issue at all, I don't know of any real-world cases whe

Re: Potentially insecure Perl scripts

On 2019-01-25 10:36:42 +, Dominic Hargreaves wrote: > Also, I think it's worth trying to identify what the worst extent > of the issue is. Whilst I don't agree with some who say that this isn't > a security issue at all, I don't know of any real-world cases where > it would be exploitable for r

Re: Potentially insecure Perl scripts

On 2019-01-25 13:55:47 +, Ian Jackson wrote: > The easiest way to sanitise a string to make it safe for 2-argument > open involves: > * prepending ./ if the string does not start with / > * appending \0 (a nul byte) > The result is also a valid operand for 3-argument open. However, the null

Re: Potentially insecure Perl scripts

On 2019-01-24 15:18:40 +, Ian Jackson wrote: > Ian Jackson writes ("Re: Potentially insecure Perl scripts"): > > The right answer is to fix the behaviour to be secure and sane by > > default. We can arrange for an environment variable for people who > > want to turn the crazy back on. > > To

Re: Potentially insecure Perl scripts

On 2019-01-24 11:18:06 +0100, Adam Borowski wrote: > On Thu, Jan 24, 2019 at 04:41:29AM +, Ben Hutchings wrote: > > On Wed, 2019-01-23 at 09:07 -0800, Russ Allbery wrote: > > > Ian Jackson writes: > > > > Apparently this has been klnown about for EIGHTEEN YEARS > > > > https://rt.perl.org/Pu

Re: Potentially insecure Perl scripts

On 2019-01-24 09:46:56 +0100, Ansgar wrote: > But "<>" isn't the only problem, there are way too many uses of the > two-argument form of Perl's "open" too... Perhaps, but at least "open" had correctly been documented since the beginning, and I quickly learnt to preprend "<" to the filename in the

Re: Potentially insecure Perl scripts

On 2019-01-24 11:12:43 +0100, Alex Mestiashvili wrote: > On 1/24/19 2:40 AM, Vincent Lefevre wrote: > But I disagree that a language can be considered insecure, just because Note: just a feature, not the language itself. > it lets you shoot in the foot. > The first thing I learned wh

Re: Potentially insecure Perl scripts

On 2019-01-23 17:23:10 +0100, Alex Mestiashvili wrote: > On 1/23/19 4:44 PM, Vincent Lefevre wrote: > > On 2019-01-23 15:32:00 +, Ian Jackson wrote: > >> This is completely mad and IMO the bug is in perl, not in all of the > >> millions of perl scripts that used &l

Re: Potentially insecure Perl scripts

On 2019-01-23 15:32:00 +, Ian Jackson wrote: > This is completely mad and IMO the bug is in perl, not in all of the > millions of perl scripts that used <> thinking it was a sensible thing > to write. I agree that it would be better to drop this "feature" of Perl. It is probably never used, an

Potentially insecure Perl scripts

Hi, I've just reported https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=920269 against gropdf (also reported upstream to bug-groff), about the use of the insecure null filehandle "<>" in Perl, which can lead to arbitrary command execution, e.g. when using wildcards. I've noticed that some ot

Re: no{thing} build profiles

On 2018-10-24 10:33:30 +0100, Jonathan Dowland wrote: > That is sort-of what is happening for neomutt (20171215+dfsg.1-1) > at least, it reports > >sh: 1: gpg: not found > > There's room for improvement there. mutt (1.9.2-1) is worse > >Error: verification failed: Unsupported protocol >

Re: no{thing} build profiles

On 2018-10-23 17:01:04 +0200, Wouter Verhelst wrote: > On Mon, Oct 22, 2018 at 11:12:57PM +0200, Adam Borowski wrote: > > That would be a bad idea -- we don't want gratuitous dependencies > > all around. Just because I use xfce doesn't mean I want a daemon > > for some old kinds of iApple iJunk >

Re: no{thing} build profiles

On 2018-10-23 16:55:00 +0200, Wouter Verhelst wrote: > On Sun, Oct 21, 2018 at 12:13:27PM -0400, Marvin Renich wrote: > > * Sune Vuorela [181021 06:05]: > > > On 2018-10-21, Jonas Smedegaard wrote: > > > > I disagree that libgpgme11 should depend/recommend/suggest gnupg at > > > > all: > > > >

Re: no{thing} build profiles

On 2018-10-22 10:47:05 +0100, Jonathan Dowland wrote: > On Sun, Oct 21, 2018 at 10:00:43PM +, Ivan Shmakov wrote: > > It can be argued that libgpgme11 does not “provide a significant > > amount of functionality” (7.2) without gnupg. > > It won't function at all without gnupg. That's pointless

Re: Removing packages perhaps too aggressively?

On 2018-05-29 15:35:24 +0200, Steve Cotton wrote: > On Tue, May 29, 2018 at 03:03:11PM +0200, Vincent Lefevre wrote: > > On 2018-05-23 09:46:09 +0800, Paul Wise wrote: > > > Depends on obsolete WebKit version (fixed in experimental): > > > > > > https://tracke

Re: Removing packages perhaps too aggressively?

On 2018-05-23 09:46:09 +0800, Paul Wise wrote: > On Tue, May 22, 2018 at 5:43 PM, Heinz Repp wrote: > > > GnuCash removed from testing in August 2017 > > Depends on obsolete WebKit version (fixed in experimental): > > https://tracker.debian.org/pkg/gnucash > https://tracker.debian.org/news/85989

Re: Removing packages perhaps too aggressively?

On 2018-05-22 15:19:50 +0500, Andrey Rahmatullin wrote: > On Tue, May 22, 2018 at 11:43:31AM +0200, Heinz Repp wrote: > > Just stumbled over some removals: > > > > GnuCash removed from testing in August 2017 > > FreeCad removed from testing in October 2017 > > > > no sign of any effort to readd t

Re: gnucash status

On 2018-05-16 01:21:01 +, Anthony DeRobertis wrote: > It appears to be fixed in experimental, which has 3.0. Presumably > that'll hit unstable when the maintainer feels it's ready. > > It appears the the BTS's version tracking may not have fully > realized what was going on, explaining why it'

gnucash status

Though the following bug was closed several months ago, gnucash from sid still depends on libwebkitgtk-1.0-0. What is the current status? Shouldn't this bug have remained open until sid got a fixed version? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790204 -- Vincent Lefèvre - Web:

Re: Automatic way to install dbgsym packages for a process?

On 2017-08-08 15:53:34 +0200, Stefan Fritsch wrote: > Now, where to put it? Into devscripts? The disadvantage is that devscripts > already pulls in quite a few other packages via recommends. But I don't > have a better idea. Unless we want to include it in reportbug or something > like that? Th

Re: OpenSSL disables TLS 1.0 and 1.1

On 2017-08-08 13:26:52 +0200, Stephan Seitz wrote: > On Mo, Aug 07, 2017 at 11:18:38 -0500, Michael Lustfield wrote: > > Is there an actual need for the removal of TLS v1.{0,1}? Are either > > considered broken or unsupported by upstream? If not, I'd be much more > > That’s I like to know as well.

Re: Bug in https://release.debian.org/transitions/ page?

On 2017-08-08 14:13:31 +0200, Mattia Rizzolo wrote: > Trying to guess what your actual question is... > > On Tue, Aug 08, 2017 at 01:05:03PM +0200, Vincent Lefevre wrote: > > The https://release.debian.org/transitions/ lists in > > "Ongoing transitions": > >

Re: DocBook 5 for Debian

Hi, On 2017-08-01 23:24:20 -0700, Paul Hardy wrote: > Therefore, I propose filing ITPs for packages "docbook5", "docbook5-xsl", > and "docbook5-xml". The packages initially would be based on DocBook 5.1, > unless DocBook 5.2 is finalized in the meantime. FYI, docbook5-xml has existed for years,

Bug in https://release.debian.org/transitions/ page?

The https://release.debian.org/transitions/ lists in "Ongoing transitions": auto-golang-goleveldb (100%) auto-libratbag (100%) which are actually finished. And in "(almost) Finished transitions", one can see: auto-libevent (5%) which has 3 packages in "good", 2 packages in "partial", and

Re: systemd, ntp, kernel and hwclock

On 2017-03-05 03:52:33 +, Ben Hutchings wrote: > I would also expect that users running command-line tools to set the > time, such as ntpdate, have enough technical understanding to > distinguish the system clock and RTC. And what's worse is that by default, ntpdate is run automatically from /

Re: systemd, ntp, kernel and hwclock

On 2017-02-28 20:01:52 +0100, Carsten Leonhardt wrote: > Daniel Pocock writes: > > > On 27/02/17 21:26, Ben Hutchings wrote: > >> But ntpd is also known to have a large amount of code written > >> without as much regard for security as one would hope. It seems > >> like an unnecessary risk for m

  1   2   3   4   5   >