APT-Signature rejected because of SHA1

[kimarite]

What steps will reproduce the problem?

LANG=C sudo apt-get update
[...]
Reading package lists... Done
W: https://josm.openstreetmap.de/apt/dists/alldist/InRelease: Policy will reject signature within a year, see --audit for details

LANG=C sudo apt update --audit
[...]
Warning: https://josm.openstreetmap.de/apt/dists/alldist/InRelease: Policy will reject signature within a year, see --audit for details
Audit: https://josm.openstreetmap.de/apt/dists/alldist/InRelease: Sub-process /usr/bin/sqv returned an error code (1), error message is:
   Signing key on 357FA575BC36BFB910E88579130A439C78FC0F87 is not bound:
              No binding signature at time 2025-08-07T01:31:31Z
     because: Policy rejected non-revocation signature (PositiveCertification) requiring second pre-image resistance
     because: SHA1 is not considered secure since 2026-02-01T00:00:00Z

sq inspect /usr/share/keyrings/josm-apt.gpg 
/usr/share/keyrings/josm-apt.gpg: OpenPGP Certificate.

      Fingerprint: 357FA575BC36BFB910E88579130A439C78FC0F87
                   Invalid: No binding signature at time 2025-08-17T12:55:49Z: Policy rejected non-revocation signature (PositiveCertification) requiring second pre-image resistance, because SHA1 is not considered secure since 2023-02-01T00:00:00Z
  Public-key algo: RSA
  Public-key size: 2048 bits
    Creation time: 2011-12-08 09:19:21 UTC

           Subkey: 0323C62CED0BE7ADB1E73B2956EC72051CE074AE
                   Invalid: Policy rejected non-revocation signature (SubkeyBinding) requiring second pre-image resistance
                   because: SHA1 is not considered secure since 2023-02-01T00:00:00Z
                   Invalid: primary key: No binding signature at time 2025-08-17T12:55:49Z, because Policy rejected non-revocation signature (PositiveCertification) requiring second pre-image resistance, because SHA1 is not considered secure since 2023-02-01T00:00:00Z
  Public-key algo: RSA
  Public-key size: 2048 bits
    Creation time: 2011-12-08 09:19:21 UTC

           UserID: JOSM developers (key for signing josm deb package repo) <josm-dev@openstreetmap.org>
                   Invalid: Policy rejected non-revocation signature (PositiveCertification) requiring second pre-image resistance
                   because: SHA1 is not considered secure since 2023-02-01T00:00:00Z

What is the expected result?

Fact: Debian 13 with Sequoia-PGP
​https://wiki.debian.org/DebianRepository/UseThirdParty#OpenPGP_certificate_handling

What happens instead?

I try „gpg dearmor”, and „sq packet dearmor” and try .list or sources format, the warning does not disappear

*.list

deb [signed-by=/usr/share/keyrings/josm-apt.gpg] https://josm.openstreetmap.de/apt/ alldist universe

*.sources

URIs: https://josm.openstreetmap.de/apt/
Suites: alldist
Architectures: amd64
Components: universe 
Types: deb
Signed-By: /usr/share/keyrings/josm-apt.gpg

Please provide any additional information below. Attach a screenshot if possible.

Relative:URL: ^/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2025-08-06 23:12:26 +0200 (Wed, 06 Aug 2025)
Revision:19434
Build-Date:2025-08-07 01:30:40
URL:https://josm.openstreetmap.de/svn/trunk

Identification: JOSM/1.5 (19434 hu) Linux Debian GNU/Linux 13 (trixie)
Memory Usage: 216 MB / 1954 MB (88 MB allocated, but free)
Java version: 21.0.8+9-Debian-1, Debian, OpenJDK 64-Bit Server VM
Look and Feel: javax.swing.plaf.metal.MetalLookAndFeel
Screen: :0.0 1280x1024x[Multi depth]@75Hz (scaling 1.00×1.00)
Maximum Screen Size: 1280×1024
Best cursor sizes: 16×16→16×16, 32×32→32×32
Environment variable LANG: hu_HU.UTF-8
System property file.encoding: UTF-8
System property sun.jnu.encoding: UTF-8
Locale info: hu_HU
Numbers with default locale: 1234567890 -> 1234567890
Desktop environment: MATE
Java package: openjdk-21-jre:amd64-21.0.8+9-1
Java ATK Wrapper package: libatk-wrapper-java:all-0.40.0-3
fonts-noto: fonts-noto:all-20201225-2
VM arguments: [--module-path=/usr/share/openjfx/lib, --add-modules=java.scripting,java.sql,javafx.controls,javafx.media,javafx.swing,javafx.web, -Djosm.restart=true, -Djosm.dir.name=JOSM-latest, -Djava.net.useSystemProxies=true, --add-exports=java.base/sun.security.action=ALL-UNNAMED, --add-exports=java.desktop/com.sun.imageio.plugins.jpeg=ALL-UNNAMED, --add-exports=java.desktop/com.sun.imageio.spi=ALL-UNNAMED]

[kimarite]

If it helps, a similar bug report (and the solution may also be interesting — they are working on it).
​https://github.com/CISOfy/lynis/issues/1658

[stoecker]

I thought a bit about this. I don't think switching the signing key completely is a good idea. I think I'll rather only switch for newer distributions.

According to this ​https://discourse.ubuntu.com/t/new-requirements-for-apt-repository-signing-in-24-04/42854 dual signing should be possible.

But I don't know how. Seems reprepro only supports one signing key.

[kimarite]

Replying to stoecker:

I thought a bit about this. I don't think switching the signing key completely is a good idea. I think I'll rather only switch for newer distributions.

According to this ​https://discourse.ubuntu.com/t/new-requirements-for-apt-repository-signing-in-24-04/42854 dual signing should be possible.

But I don't know how. Seems reprepro only supports one signing key.

Presumably, only the RSA1 algorithm needs to be replaced with a more secure one in that single key in order for this to disappear

"because: SHA1 is not considered secure since 2023-02-01T00:00:00Z"

and this will also disappear with the update.

"Invalid: Policy rejected non-revocation signature (PositiveCertification) requiring second pre-image resistance"

I looked at several external package solutions on the system, two examples of which are (marked with an asterisk: *)

* first

sq inspect /usr/share/keyrings/*.gpg 
/usr/share/keyrings/*.gpg: OpenPGP Certificate.

      Fingerprint: *
  Public-key algo: RSA
  Public-key size: 4096 bits
    Creation time: 2025-03-24 04:11:21 UTC
        Key flags: certification, signing

           Subkey: *
  Public-key algo: RSA
  Public-key size: 4096 bits
    Creation time: 2025-03-24 04:11:21 UTC
        Key flags: transport encryption, data-at-rest encryption

           UserID: *

* second

sq inspect /usr/share/keyrings/*.gpg 
/usr/share/keyrings/*.gpg: OpenPGP Certificate.

      Fingerprint: *
  Public-key algo: RSA
  Public-key size: 3072 bits
    Creation time: 2025-03-03 06:41:27 UTC
  Expiration time: 2027-03-03 06:41:27 UTC (creation time + 1year 11months 29days 21h 50m 24s)
        Key flags: certification, signing

           Subkey: *
  Public-key algo: RSA
  Public-key size: 3072 bits
    Creation time: 2025-03-03 06:42:16 UTC
  Expiration time: 2027-03-03 06:42:16 UTC (creation time + 1year 11months 29days 21h 50m 24s)
        Key flags: transport encryption, data-at-rest encryption

           UserID: *

The Debian system has no problems with these (and others) when using OpenPGP. So, presumably (tip), there is no need for the Sequoia PGP solution mentioned here yet.

​https://www.redhat.com/en/blog/updating-gpg-keys-for-fedora-and-rhel

The gpg --dearmor may still be useful:

APT used to be unable to handle ASCII-Armored OpenPGP certificates. And thus as indicated above, you MUST NOT use ASCII-Armored certificates. If you have such a certificate, you should convert it to binary form with something like this with Sequoia-PGP:

​https://wiki.debian.org/DebianRepository/UseThirdParty#OpenPGP_certificate_handling

How do you generate the *.key file that can be downloaded/used? Just because the apt-key package has been removed from Debian.

Could the same public key be made available (also) in josm-apt.key.asc format?

[stoecker]

Tried many ways. Can't get rid of SHA1.

​https://blog.bmarwell.de/2020/11/21/fixing-old-sha1-infested-openpgp-keys.html

[stoecker]

Milestone renamed

[kimarite]

Replying to kimarite:

If it helps, a similar bug report (and the solution may also be interesting — they are working on it).
​https://github.com/CISOfy/lynis/issues/1658

Resolved at the above location. About this (OSM):

Thanks for confirming that all is working as expected.

It is indeed a big challenge and that's why it took longer than expected.

When fiddling with the settings, the public key changes. For Red Hat based repositories this seems not to be a problem, as they can update it fairly easy. For Debian I think you can't skip in having to download the (new) public key again.

I thought about documenting it, but don't have the time now to do that properly. It involves a lot of testing to make it foolproof..

My tip for those with the same issue: ​contact me personally or simply create a new GPG key set and endure the pain once that people have to re-import the public key.

Will close this ticket now that things are working as expected.

[stoecker]

It is no (big) issue to create and use a totally new key. What failed is to redo the old key without SHA1.

A new key means every user needs to download and install it again.

I could restrict the new key to Debian and upcomming Ubuntus though. But a clean break is probably better.

[stoecker]

Oh. It seems I can simply sign with two keys. That will ease transition.

[kimarite]

Replying to stoecker:

Oh. It seems I can simply sign with two keys. That will ease transition.

We talked about this earlier.

... reprepro only supports one signing key.

I remember that with the lynis package, there were two keys (try)... okay, I had them, but the SHA1 phenomenon still exists.

I am a proponent of rationalization and simplification, so I would not complicate the solution (which could be a source of new and further problems), and in practice (with the removal of apt-key), the new key has to be downloaded anyway... . So I would create a single key.

[stoecker]

Replying to kimarite:

Replying to stoecker:

Oh. It seems I can simply sign with two keys. That will ease transition.

We talked about this earlier.

... reprepro only supports one signing key.

Aaah. Should have read the own ticket as well. Had a look in the web yesterday and there it was indicated it works (with reprepro).

I am a proponent of rationalization and simplification, so I would not complicate the solution (which could be a source of new and further problems), and in practice (with the removal of apt-key), the new key has to be downloaded anyway... . So I would create a single key.

Probably the only working solution... Tss.

[stoecker]

Here somebody says he's using two keys: ​https://groups.google.com/g/aptly-discuss/c/1I9Xem_BNwo

[kimarite]

Replying to stoecker:

Here somebody says he's using two keys: ​https://groups.google.com/g/aptly-discuss/c/1I9Xem_BNwo

It's possible, but it's not customary.
​Debian Repository Format Sygned By

On the other hand, InRelease's behavior should also be checked... whether you like it or not.

LANG=C sudo apt update --audit
[...]
Warning: https://josm.openstreetmap.de/apt/dists/alldist/InRelease: Policy will reject signature within a year, see --audit for details
Audit: https://josm.openstreetmap.de/apt/dists/alldist/InRelease: Sub-process /usr/bin/sqv returned an error code (1), error message is:
   Signing key on 357FA575BC36BFB910E88579130A439C78FC0F87 is not bound:
              No binding signature at time 2025-08-07T01:31:31Z
     because: Policy rejected non-revocation signature (PositiveCertification) requiring second pre-image resistance
     because: SHA1 is not considered secure since 2026-02-01T00:00:00Z

But anyway, that's how it works at Lynis, now:

sq inspect /usr/share/keyrings/*.gpg
/usr/share/keyrings/*.gpg: OpenPGP Certificate.

      Fingerprint: *82
  Public-key algo: RSA
  Public-key size: 4096 bits
    Creation time: 2021-*
  Expiration time: 2030-*
        Key flags: certification, signing

           Subkey: *D3
  Public-key algo: RSA
  Public-key size: 4096 bits
    Creation time: 2025-*
  Expiration time: 2030-*
        Key flags: signing

           Subkey: *C2
  Public-key algo: RSA
  Public-key size: 4096 bits
    Creation time: 2021-*
  Expiration time: 2030-*
        Key flags: transport encryption, data-at-rest encryption

Of course, there's tar* over there too...

:::::

Probably the only working solution... Tss.

Something like this SHA1 output happens once in a century, if at all.

Have a nice day!

[kimarite]

And of course, I will test the new key once you have made it available to me. I can do this on a Debian Trixie system.