Devuan bug report logs - #891
devuan-keyring: New signing key needed?

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.devuan.org (full text, mbox, reply):

Package: devuan-keyring
Version: 2023.10.07
Severity: normal
X-Debbugs-Cc: Martin@Lichtvoll.de

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

Message #8 received at 891@bugs.devuan.org (full text, mbox, reply):

Martin,

Thanks for this.


On Mon, May 26, 2025 at 05:15:50PM +0200, Martin wrote:
> Package: devuan-keyring
> Version: 2023.10.07
> Severity: normal
> X-Debbugs-Cc: Martin@Lichtvoll.de
> 
> 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

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

Message #13 received at 891@bugs.devuan.org (full text, mbox, reply):

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.

Send a report that this bug log contains spam.