Subject: bug#891: devuan-keyring: New signing key needed?

From: Martin <[email-masked]>
Date: Mon, 26 May 2025 17:15:50 +0200

Package: devuan-keyring
Version: 2023.10.07
Severity: normal
X-Debbugs-Cc: [email-masked]

Dear Mark, dear Devuan development team.

In Devuan Ceres I keep getting a warning about policy rejecting signature
within a year which I got explained by Apt by using "--audit":

% LANG=C apt update --audit
Hit:1 http://deb.devuan.org/merged ceres InRelease
All packages are up to date.    
Warning: http://deb.devuan.org/merged/dists/ceres/InRelease: Policy will 
reject signature within a year, see --audit for details
Audit: http://deb.devuan.org/merged/dists/ceres/InRelease: Sub-process /
usr/bin/sqv returned an error code (1), error message is:
   Signing key on 72E3CB773315DFA2E464743D94532124541922FB is not bound:
              No binding signature at time 2025-05-25T14:45:30Z
     because: Policy rejected non-revocation signature 
(PositiveCertification) requiring second pre-image resistance
     because: SHA1 is not considered secure since 2026-02-01T00:00:00Z

So does that mean a new signing key is needed?

Reported a bug as suggested by you, Mark.

However: I have apt 3.1.0 from Debian experimental installed. I tried
downgrading to apt 3.0.0devuan1 as I think this version did not display
above warning and I wanted to verify that. But now I get:

Error: The method driver /usr/lib/apt/methods/sqv could not be found.
Notice: Is the package apt-transport-sqv installed?

This method is not referenced in any of the modernized deb822 sources.

I then removed the package "sgv". Now the output is without any error
message. So it seems this message is related to the switch of Apt to
use Rust based Sequoia GPG instead of the regular GnuPG 2.

Some additional package versions that may matter:

- apt 3.1.0 from Debian experimental
- sqv 1.3.0-2

As written I downgraded to apt 3.0.0devuan1 and removed sqv for now.

I bet once Devuan Apt fork switches to sqv you will see above key related
warning. Which means that Devuan Excalibur should not be affected, however
Devuan Ceres may be.

Best,
Martin

-- System Information:
Distributor ID:	Devuan
Description:	Devuan GNU/Linux 6 (excalibur/ceres)
Release:	6
Codename:	excalibur ceres
Architecture: x86_64

Kernel: Linux 6.15.0-rc7-t14g5 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de
Shell: /bin/sh linked to /usr/bin/dash
Init: runit (via /run/runit.stopit)
LSM: AppArmor: enabled

Versions of packages devuan-keyring depends on:
ii  gpgv  2.4.7-19

Versions of packages devuan-keyring recommends:
ii  gnupg  2.4.7-19

devuan-keyring suggests no packages.

-- Configuration Files:
/etc/apt/trusted.gpg.d/devuan-keyring-2016-archive.gpg [file not found]
/etc/apt/trusted.gpg.d/devuan-keyring-2022-archive.gpg [file not found]
/etc/apt/trusted.gpg.d/devuan-keyring-amprolla-2022-archive.gpg [file not 
found]
/etc/apt/trusted.gpg.d/devuan-keyring-daedalus-archive.gpg [file not 
found]
/etc/apt/trusted.gpg.d/devuan-keyring-excalibur-archive.gpg [file not 
found]
/etc/apt/trusted.gpg.d/devuan-keyring-freia-archive.gpg [file not found]

-- no debconf information

---

From: Mark Hindley <[email-masked]>
Date: Mon, 2 Jun 2025 17:03:56 +0100

Martin,

Thanks for this.

>      because: SHA1 is not considered secure since 2026-02-01T00:00:00Z

This looks as if sqv (the new rust-based key verifier) is going to be more picky
about SHA1.

At the moment, I think ceres and all of the unmerged repos
(pkgmaster.devuan.org/devuan) use a SHA1 key.

Generating and using a new key is not too problematic, but getting it
distributed is more so. You end up in a chicken and egg cycle with the new key
being used but apt refusing to update the devuan-keyring package because it
can't verify the key.

Does anybody have a good idea how to resolve that? We will have lots of unhappy
users if they can no longer apt update|upgrade|install.

Mark

---

From: [email-masked]
Date: Mon, 02 Jun 2025 16:03:32 -0300

Hello:

On 2 Jun 2025 at 17:03, Mark Hindley wrote:

> ... end up in a chicken and egg cycle with the new key being used
> but apt refusing to update the devuan-keyring package because it
> can't verify the key.
> 
> ... good idea how to resolve that?

Just thinking out loud, not to be taken *too* seriously.

I live in a building with 10 stories and 66 flats.
When someone loses their keys to the front door, the lock is changed 
asap and 66 new keys are made and distributed.

When someone without a new key wants to get into the building, they 
are met with a sign saying that they should contact the building's 
admin and ask for their key. 

In a loosely analogous manner, a *sleeper* devuan-keyring metapackage 
could be used.

I would be pushed out to everyone updating and once installed it 
would lie waiting to detect when / if the user wanting to update / 
upgrade or install anything is unable to do so because of the old 
key.

At that point, it would inform them of the situation and instruct 
them to extract [c]sleeper.sh[/c] from the metapackage.

[c]sleeper.sh[/c] would unpackage, install the new key and ask the 
user to try their update / upgrade again.

If the update / upgrade or installation went ahead as expected, the 
*sleeper* devuan-keyring metapackage would then rm itself.

Just an idea.
I am aware that this may potentially have some security issues.

Best,

A.

---

From: Mark Hindley <[email-masked]>
Date: Sun, 27 Jul 2025 18:36:03 +0100

> >      because: SHA1 is not considered secure since 2026-02-01T00:00:00Z

So, the SHA1 541922FB key is used: by

 - all current /devuan suites, but the sqv failure looks only to be relevant for
   freia, ceres and experimental

 - daedalus and ceres for /merged, but only ceres is relevant

My suggestion to manage this is to change the 4 affected suites to be signed by

pub   rsa4096 2017-09-04 [SC]
      E032601B7CA10BC3EA53FA81BB23C00C61FC752C
uid                      Devuan Repository (Amprolla3 on Nemesis) <[email-masked]>
sub   rsa4096 2017-09-04 [E]

which is already in the distributed keyring.

It isn't perfect, but is the best I can imagine. Does anybody have any
improvements? What have I missed?

Mark

---

From: "Devuan bug Tracking System" <[email-masked]>
Date: Mon, 18 Aug 2025 09:14:02 +0000

This is an automatic notification regarding your bug report
which was filed against the devuan-keyring package:

#891: devuan-keyring: New signing key needed?

It has been closed by Mark Hindley <[email-masked]>.

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Mark Hindley <[email-masked]> by
replying to this email.

-- 
891: https://bugs.devuan.org/cgi/bugreport.cgi?bug=891
Devuan Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#891: devuan-keyring: New signing key needed?
From: Mark Hindley <[email-masked]>
To: Martin <[email-masked]>, [email-masked]
Date: Mon, 18 Aug 2025 10:12:33 +0100

We have reworked the keysigning for ceres. I believe this should be resolved.

Closing.

Mark

Subject: devuan-keyring: New signing key needed?
From: Martin <[email-masked]>
To: Devuan Bug Tracking System <[email-masked]>
Date: Mon, 26 May 2025 17:15:50 +0200

Package: devuan-keyring
Version: 2023.10.07
Severity: normal

Best,
Martin

-- System Information:
Distributor ID:	Devuan

-- Configuration Files:

---

From: Martin Steigerwald <[email-masked]>
Date: Mon, 18 Aug 2025 11:15:58 +0200

HI Mark.

> We have reworked the keysigning for ceres. I believe this should be

Thank you!

Best,
-- 
Martin