Re: OpenPGP certificates with SHA-1 issues in Debian keyrings

[Guillem Jover]

Hi!

On Thu, 2025-03-20 at 22:00:04 +0100, Christoph Biedl wrote:
> Being one of those on the list, I'm even more confused than I'd be about
> this anyway.

Ok, let me try to clarify, then!

> So those people you listed:
> 
> * Did they something wrong (although certainly with best intentions)?

I don't think so, or at least if they did something explicitly,
probably not wrong at the time they did it.

> * Are they just victim of the circumstances (versions of the software,
>   unhandy configuration, ...)?

I think this is mostly due to GnuPG having had non-ideal defaults
in the past, that required for people to follow online guides to tune
their configurations to be able to generate safe keys at the time. And
it still having insecure defaults in some aspects right now.

> * Is this a problem if apparently everything went fine in the many past
>   years?

I think there's widespread agreement that using SHA-1 in a security
context is not wise at this point in time. The problem is that when
using GnuPG this is sometimes invisible unless asked for explicitly.

There's been collective efforts to remove that from usage. For example
dpkg-source and dpkg-buildpackage have considered SHA-1 and RIPEMD160
as weak digests in signatures since 1.21.0 (2021-12), apt had done the
same for repo signatures since 1.2.8 (2016-03) but I don't see it ever
passed --weak-digest to gpgv so I think the reported problems here
would have slipped in, but it should refuse them now that it has
switched to use sqv since 2.9.19 (2024-12), and the Debian archive
too for the .dsc and .changes signatures themselves since
,
and while I had the notion that we had SHA-1 usage in the keyring, I
assumed that was mostly for inactive people. I was surprised to realize
that the archive was still allowing uploads for these keys, that's why
I also filed #1100894 for ftp.debian.org, and #1100734 for debian-keyring.


But in any case, as I mentioned on my original mail, these should
already be problematic right now. For instance (and not meaning to pick
on you, just as a practical hopefully relatable example) when replying
to this email, your signatures failed to verify for me with mutt + sq
integration [M], with:

  ,---
  [-- PGP output follows (current time: Thu Mar 20 23:10:14 2025) --]
  
Error: 597308FBBDBA035D8C7C95DDC42C58EB591492FD is not valid according to 
the current policy, ignoring
  because: No binding signature at time 2025-03-20T22:10:14Z
  because: Policy rejected non-revocation signature (PositiveCertification) 
requiring second pre-image resistance
  because: SHA1 is not considered secure since 2023-02-01T00:00:00Z
  Signing key on 597308FBBDBA035D8C7C95DDC42C58EB591492FD is not bound:
  
Error: No binding signature at time 2025-03-20T21:00:00Z
  because: Policy rejected non-revocation signature (PositiveCertification) 
requiring second pre-image resistance
  because: SHA1 is not considered secure since 2023-02-01T00:00:00Z
  0 authenticated signatures, 1 bad key.
  
Error: Verification failed: could not authenticate any signatures
  [-- End of PGP output --]
  `---

[M] https://wiki.debian.org/OpenPGP/Sequoia#mutt

Or for a recent upload for src:file, the signatures for the source
package also fail to verify:

  ,---
  $ apt source --download-only file
  […]
  # With sq as OpenPGP backend
  $ dpkg-source --require-valid-signature -x file_5.46-2.dsc
 No acceptable signatures found
  dpkg-source: error: cannot verify inline signature for ./file_5.46-2.dsc: no 
acceptable signature found
  # With gpg-g10code as OpenPGP backend
  $ dpkg-source --require-valid-signature -x file_5.46-2.dsc
  gpg: Signature made Thu Mar 13 19:46:00 2025 UTC
  gpg:using RSA key 597308FBBDBA035D8C7C95DDC42C58EB591492FD
  gpg: Can't check signature: No public key
  dpkg-source: error: cannot verify inline signature for ./file_5.46-2.dsc: no 
acceptable signature found
  $ k=/usr/share/keyrings/debian-keyring.gpg
  $ gpgv-g10code --keyring $k file_5.46-2.dsc
  gpgv: Signature made Thu Mar 13 20:46:00 2025 CET
  gpgv:using RSA key 597308FBBDBA035D8C7C95DDC42C58EB591492FD
  gpgv: Good signature from "Christoph Biedl (Debian) 
"
  $ echo $?
  0
  $ gpgv-g10code --keyring $k --weak-digest SHA1 file_5.46-2.dsc
  gpgv: Signature made Thu Mar 13 20:46:00 2025 CET
  gpgv:using RSA key 597308FBBDBA035D8C7C95DDC42C58EB591492FD
  gpgv: Note: signatures using the SHA1 algorithm are rejected
  gpgv: Can't check signature: No public key
  $ echo $?
  2
  $ gpgv-sq --keyring $k file_5.46-2.dsc >/dev/null
  gpgv: Signature made Thu Mar 13 20:46:00 2025 +01:00
  gpgv:using RSA key 597308FBBDBA035D8C7C95DDC42C58EB591492FD
  gpgv: Can't check signature: Bad public key
  $ echo $?
  2
  `---

Notice that dpkg-source already fails to verify (and it does
regardless of the OpenPGP backend it will use, as it has passed
--weak-d

Bug#1101194: ITP: libopengl-glfw-perl -- Perl bindings for the GLFW library

[Ed J]

Package: wnpp
Owner: Ed J 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: libopengl-glfw-perl
  Version : 0.04
  Upstream Author : Chris Marshall 
* URL : https://metacpan.org/release/OpenGL-GLFW
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Perl bindings for the GLFW library

OpenGL::GLFW provides perl5 bindings to the GLFW library for OpenGL
applications development. The implementation is a direct translation of the
GLFW C interface to perl. You can use the official GLFW documentation at
http://www.glfw.org/documentation.html for the specifics of the GLFW API.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1101193: ITP: libopengl-modern-perl -- Perl extension to Modern OpenGL API up to 4.5

[Ed J]

Package: wnpp
Owner: Ed J 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: libopengl-modern-perl
  Version : 0.04
  Upstream Author : Chris Marshall 
* URL : https://metacpan.org/release/OpenGL-Modern
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Perl extension to Modern OpenGL API up to 4.5

OpenGL::Modern provides perl bindings to the OpenGL graphics APIs using
the OpenGL Extension Wrangler (GLEW) library.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1101136: ITP: android-udev-rules -- udev rules for Android tools

[Andrea Pappacoda]

Package: wnpp
X-Debbugs-Cc: debian-devel@lists.debian.org
Owner: Andrea Pappacoda 
Severity: wishlist

* Package name: android-udev-rules
 Version : 0~20250314-1
 Upstream Contact: https://github.com/M0Rf30/android-udev-rules/issues
* URL : https://github.com/M0Rf30/android-udev-rules
* License : GPL-3.0+
 Description : udev rules for Android tools

This package provides udev rules enabling the Android SDK tools adb and 
fastboot to work without root access to the host machine.


These udev rules have historically been shipped by the 
android-sdk-platform-tools-common package, part of the Android SDK. In 
, though, I've proposed splitting the 
rules into a standalone package. Please see the bug for the full 
context, but the benefits would be, in short:


- The udev rules have a different upstream than the Android SDK
- These rules get updated more frequently than the SDK, to add support 
 for new devices; a standalone package can be updated more easily
- It becomes possible to only install the udev rules, without bits from 
 the SDK (which is often installed separately from Google's website, 
 sadly)


As the `/usr/lib/udev/rules.d/51-android.rules` file would need to be 
moved from android-sdk-platform-tools-common to the (new) 
android-udev-rules package, I'd greatly appreciate if somebody could 
suggest me the correct set of Breaks/Conflicts/Replaces that I have to 
put in the control file. I always get them wrong :)


Bye!


signature.asc
Description: PGP signature

Re: Documentation for Package Maintainers regarding Translations (was: General Questions about Translations and what a package maintainer has to do)

[Helge Kreutzmann]

Hello Marc,
Am Mon, Mar 24, 2025 at 05:49:40PM +0100 schrieb Marc Haber:
> On Sat, Mar 22, 2025 at 06:32:54PM +, Helge Kreutzmann wrote:
> > Am Wed, Mar 19, 2025 at 09:44:47AM +0100 schrieb Marc Haber:
> > If you have any questions on my changes it is probably best to discuss
> > this on list. Please keep me (or -i18n) in CC, as I'm not subscribed
> > to -devel.
> 
> I think the only matter that needs discussion is whether and when to commit
> updated PO files:
> 
> Me:
> It is currently not clear how to make sure that a package maintainer does
> not forget these updates without creating lots of useless commits with new
> PO files that only differ in line number and date stamp comments.
> 
> You:
> Using no line numbers reduced this problem. Updated time stamps are no worry
> for translators (they seldomly look at them). And they do not care for
> commits - they look at master or similar or on the web pages mentioned above
> and take what they find. So the most important part is to keep this current.
> If you need this for your VCS, you can add code in your build system to
> discard po(t) file updates which only change in the date stamp.
> 
> My questions:
> "Using no line numbers" => invoke msgmerge with --no-location?

Yes.

> "Web pages mentioned above" => I don't see web pages being mentioned. That
> needs a name or a link

I meant the references to the Debian status pages, the link I inserted
further above: https://www.debian.org/international/l10n/

Please reword this to make it more clear.

> "Add code in your build system to discard po(t) that only change in the date
> stamp" => that would mak ethe source package and the tag in the VCS diverge.
> I don't like that at all.

This I don't understand.

At some stage you update the POT files. Then you run a (git) commit,
to place the updated files in your repository.

In manpages-l10n Tobias added code to detect, if only the time stamp
changed. If so, the time stamp is reverted to the previous value, and
a "git commit" is a noop. Then also the po files are left alone.

This "only" saves you a commit in this corner case. 

It is not meant to diverge version, because in the end the po(t) files
in your package should match the po(t) files in the repository.

Greetings

   Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Re: The apt tool chain doesn't seem to sanitize it's environment

[Aaron Rainbolt]

On Mon, 24 Mar 2025 13:59:00 -0700
John Darrah  wrote:

> I encountered the following error while upgrading a 'testing/trixie'
> install.
> 
> Setting up network-manager (1.52.0-5) ...
> Insecure $ENV{CDPATH} while running with -T switch at
> /usr/share/perl5/Debian/AdduserLogging.pm line 157.
> dpkg: error processing package network-manager (--configure):
>  installed network-manager package post-installation script
> subprocess returned error exit status 25
> 
> I unset CDPATH, then reinstalled and it completed without an error. I
> would think the apt toolchain should not allow the root interactive
> environment to be exposed while installing packages.

This isn't really the fault of apt. apt may legitimately need to
change its behavior in response to environment variables, and there are
packages (at least outside of the Debian archive, and maybe inside as
well) that change their behavior depending on the environment they're
called with. Kicksecure's packages are an example of this, and they
very much benefit from the environment propagating like this.

The program that should be sanitizing your environment is whatever
privilege escalation tool you're using (usually sudo). If it's not
sanitizing your environment properly, you may want to check your
sudoers configuration and change it so it does sanitize things
properly. Alternatively, if you're logging in as root and then running
apt, you can use "env -i" to sanitize the environment before calling
apt.

--
Aaron

> -- john


pgp_fgLRk36QQ.pgp
Description: OpenPGP digital signature

The apt tool chain doesn't seem to sanitize it's environment

[John Darrah]

I encountered the following error while upgrading a 'testing/trixie' install.

Setting up network-manager (1.52.0-5) ...
Insecure $ENV{CDPATH} while running with -T switch at
/usr/share/perl5/Debian/AdduserLogging.pm line 157.
dpkg: error processing package network-manager (--configure):
 installed network-manager package post-installation script
subprocess returned error exit status 25

I unset CDPATH, then reinstalled and it completed without an error. I
would think the apt toolchain should not allow the root interactive
environment to be exposed while installing packages.

-- john

Re: fluster add epoch

[Carsten Schoenert]

Hello Christopher,

Am 23.03.25 um 22:52 schrieb Christopher Obbard:


I guess eventually upstream will release 1.0.1 but I don't think it
will be for a long while.
They had a few issues with their github release pipeline last year,
but all seems to be OK now.


if you don't have statement from upstream about there future release 
plannings it's just pure guessing what can happen.
Looking at the releases over time I don't have the impression it will 
soon come to a release 1.x.


...

I am happy to do that rather than add an epoch; does anyone else have
any opinions ?
> I thought an epoch would be cleaner here personally, but I don't
have any actual upstream Debian packaging experience with epochs.
When developing custom distros with custom (not suitable for Debian) 
packages we added them fairly frequently when bootstrapping things

and upstream changing things. But it seems like adding epochs in
Debian is a much more conservative decision? It'd be interesting to 
hear more about this, I possibly need some history lesson for real-

world case where adding epoch is dangerous ;-).


Yeah, epochs are for ever, and they confuse the "normal" users often as 
they don't understand why they are in the version string.


So maybe another option is to introduce a new src and binary package 
that can replace the existing package over time.


Looking at PyPi and into the pyproject.toml file the package seems to 
have the real name 'fluster-conformance'.


https://pypi.org/project/fluster-conformance/
https://github.com/fluendo/fluster/blob/master/pyproject.toml#L6

So you could create a new src package with the name 
'fluster-conformance' that is providing 'python3-fluster' and uses 
Breaks/Replace and optional Provides for fluster.
Once you want to keep the binary name this all will not work because the 
version issue plus package name is still the same then!


There is a wiki page existing about how to do some transitions of packages.
https://wiki.debian.org/PackageTransition

I haven't looked at all details so maybe my suggestion is also not 
sufficient in the end and using an epoch is still the best solution.


--
Regards
Carsten

Re: Should uncoordinated NMUs unilaterally choose Salsa as the VCS for a package?

[Jonathan Dowland]

Have you had any contact with the NMUer? How has that gone?

From what I can see this is clearly an overstep and I don't think adding 
any more words anywhere would make a difference. They didn't honour the 
words we already have. (I note the package version is also wrong for an 
NMU)


That said we all make mistakes, the NMUer is a valued member of our 
community, as you are, and hopefully this can be resolved amicably.


--
Please do not CC me for listmail.

👱🏻  Jonathan Dowland
✎j...@debian.org
🔗   https://jmtd.net

Bug#1101181: ITP: ytmusicapi -- Unofficial API for youtube music

[Salvo 'LtWorf' Tomaselli]

Package: wnpp
Severity: wishlist
Owner: Salvo 'LtWorf' Tomaselli 
X-Debbugs-Cc: debian-devel@lists.debian.org, tipos...@tiscali.it

* Package name: ytmusicapi
  Version : 1.10.2
  Upstream Contact: sigma67 
* URL : https://github.com/sigma67/ytmusicapi
* License : MIT
  Programming Lang: Python
  Description : Unofficial API for youtube music

I am packaging this because it is a dependency of audiotube.

I intend to place it within the python team.