The Problem

(See OpenPGP certificates with SHA-1 issues in Debian keyrings)

Using something like dpkg-source -x to unpack your Debian sources produces output like: 

Signing key on DEADBEEFEA75B335EEB6FB112345678902173 is not bound:
           No binding signature at time 2026-01-29T14:42:57Z
  because: Policy rejected non-revocation signature (PositiveCertification) requiring second pre-image resistance
  because: SHA1 is not considered secure since 2023-02-01T00:00:00Z
dpkg-source: warning: cannot verify inline signature for /my/src/package/something_2.1.5-1.dsc: no acceptable signature found

and maybe your package is rejected by the DFSG, Licensing & New Packages Team as a result.

The "binding signature" (the cryptographic proof that your signing subkey belongs to your master key) was created using SHA-1.

SHA-1 is 'digest algo 2' and you can see the issue is present in your key with either: 

$ sq cert lint --cert FINGERPRINT

or 

$ gpg --export <your-key-fingerprint> | gpg --list-packets | grep -B2 "digest algo 2"
:signature packet: algo 1, keyid ABCD12345678FEDC
        version 4, created 1316545496, md5len 0, sigclass 0x10
        digest algo 2, begin of digest 58 5b
--
:signature packet: algo 1, keyid 7654AFD07710DCF7
        version 4, created 1424956333, md5len 0, sigclass 0x13
        digest algo 2, begin of digest df a9
--
:signature packet: algo 1, keyid 7654AFD07710DCF7
        version 4, created 1424956333, md5len 0, sigclass 0x13
        digest algo 2, begin of digest 5b c3
--
:signature packet: algo 1, keyid FEEDBEE5DEADBEEF
        version 4, created 1440429650, md5len 0, sigclass 0x10
        digest algo 2, begin of digest 9f a3
--
:signature packet: algo 1, keyid 7654AFD07710DCF7
        version 4, created 1316282137, md5len 0, sigclass 0x18  digest algo 2, begin of digest de ad
        digest algo 2, begin of digest be ef
        digest algo 2, begin of digest fe ed
        digest algo 2, begin of digest be e5
        digest algo 2, begin of digest f0 0d

The Solution

You can fix your key with Sequoia-PGP by running: 

$ sq cert lint --cert FINGERPRINT --fix | gpg --import

Alternatively, you need to force GPG to re-sign the binding between your master key and your subkeys using a stronger hash (SHA-256 or SHA-512).

Edit your key: 

$ gpg --edit-key <your-key-fingerprint>

Update the preferences (Primary Key): This updates the primary key's self-signature.

At the gpg> prompt, type: 'setpref'

(If asked, accept the default options)

At the gpg> prompt, type: 'showpref' to verify SHA512/SHA256 are listed first

Type 'save' to save changes (writes the new self-signature).

Restart the edit: 

$ gpg --edit-key <your-key-fingerprint>

Update the Subkey Binding:

At the gpg> prompt, type 'list' (list keys to find the signing subkey index)

Select the subkey (e.g.): 'key 1'

""Important:""

Type: 'expire'

Set it to your preferred expiry.

Type: 'save'

Verify the fix:

If you have updated your key, and all sub-keys that were SHA 1 

$ gpg --export <fingerprint> | gpg --list-packets | grep -B2 "digest algo 2"

(should produce no output)

Once you have done this you should update your key in the Debian Keyring: 

$ gpg --keyserver keyring.debian.org --send-keys <fingerprint>

Additionally you may wish to upload your key to other keyrings: 

$ gpg --keyserver keys.openpgp.org --send-keys <fingerprint>
$ gpg --keyserver pgpkeys.eu --send-keys <fingerprint>
$ gpg --keyserver keyserver.ubuntu.com --send-keys <fingerprint>

Then re-sign and re-upload the package. You should soon see your package in the DFSG Team Dashboard again, ready to be reviewed.

You should also ping the original reviewer to explain that you have updated your key and they will need to re-fetch your key from the keyring in order for them to verify the problem is resolved.

Reference

You can find a reference for the digest algorithm and its ID in RFC9580: OpenPGP, 9.5. Hash Algorithms: 

ID      Algorithm               Text Name       V6 Signature Salt Size
0       Reserved
1       MD5 [RFC1321]           "MD5"           N/A
2       SHA-1 [FIPS180]         "SHA1"          N/A
3       RIPEMD-160 [RIPEMD-160] "RIPEMD160"     N/A
4       Reserved
5       Reserved
6       Reserved
7       Reserved
8       SHA2-256 [FIPS180]      "SHA256"        16
9       SHA2-384 [FIPS180]      "SHA384"        24
10      SHA2-512 [FIPS180]      "SHA512"        32
11      SHA2-224 [FIPS180]      "SHA224"        16
12      SHA3-256 [FIPS202]      "SHA3-256"      16
13      Reserved
14      SHA3-512 [FIPS202]      "SHA3-512"      32
100-110 Private or Experimental Use

[…]

Implementations MUST implement SHA2-256.
Implementations SHOULD implement SHA2-384 and SHA2-512.
Implementations MAY implement other algorithms.
Implementations SHOULD NOT create messages that require the use of SHA-1, with the exception of
computing version 4 key fingerprints for purposes of the MDC in version 1 Symmetrically Encrypted
and Integrity Protected Data packets.
Implementations MUST NOT generate signatures with MD5, SHA-1, or RIPEMD-160.
Implementations MUST NOT use MD5, SHA-1, or RIPEMD-160 as a hash function in an ECDH KDF.
Implementations MUST NOT generate packets using MD5, SHA-1, or RIPEMD-160 as a hash function in an S2K KDF.
Implementations MUST NOT decrypt a secret using MD5, SHA-1, or RIPEMD-160 as a hash function in an S2K KDF
in a version 6 (or later) packet.
Implementations MUST NOT validate any recent signature that depends on MD5, SHA-1, or RIPEMD-160.
Implementations SHOULD NOT validate any old signature that depends on MD5, SHA-1, or RIPEMD-160
unless the signature's creation date predates known weakness of the algorithm used, and the implementation
is confident that the message has been in the secure custody of the user the whole time.

CategoryOpenPGP CategoryDeveloper ?CategoryCommonDFSGReviewIssues