PGP signature for releases

[dvzrv]

Hi! When packaging 0.6 for Arch Linux I noticed, that some of the tags are signed using the PGP key ID 7107840B4DC9C948076D6359795524F14F952B42.

Unfortunately this is a DSA 1024bit key, that predates even the SHA1 algorithm (see the below sq-keyring-linter output).

$ sq-keyring-linter <(gpg --export "7107840B4DC9C948076D6359795524F14F952B42")
Certificate 795524F14F952B42 is not valid under the standard policy + SHA-1: Policy rejected asymmetric algorithm
Examined 1 certificate.
  1 certificate is invalid and was not linted. (BAD)

The attached subkeys are self-signed using SHA1 (see the below hokey output):

$ gpg --export "7107840B4DC9C948076D6359795524F14F952B42" | hokey lint
hokey (hopenpgp-tools) 0.23.6
Copyright (C) 2012-2021  Clint Adams
hokey comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions.

Key has potential validity: good
Key has fingerprint: 7107 840B 4DC9 C948 076D  6359 7955 24F1 4F95 2B42
Checking to see if key is OpenPGPv4: V4
Checking the strength of your primary asymmetric key: DSA 1024
Checking user-ID- and user-attribute-related items:
  Robin Gareus <[email protected]>:
    Self-sig hash algorithms: [SHA-1]
    Preferred hash algorithms: [SHA-1, SHA-256, RIPEMD-160]
    Key expiration times: []
    Key usage flags: [[auth, sign-data, certify-keys]]
  Robin Gareus <[email protected]>:
    Self-sig hash algorithms: [SHA-1]
    Preferred hash algorithms: [RIPEMD-160, SHA-1]
    Key expiration times: []
    Key usage flags: []
  Robin Gareus <[email protected]>: [revoked]
    Revocation code: [UserIdInfoNoLongerValid]
    Revocation reason: []
  Robin Gareus <[email protected]>: [revoked]
    Revocation code: [UserIdInfoNoLongerValid]
    Revocation reason: []
  Robin Gareus <[email protected]>: [revoked]
    Revocation code: [UserIdInfoNoLongerValid]
    Revocation reason: []
  Robin Gareus <[email protected]>:
    Self-sig hash algorithms: [SHA-1]
    Preferred hash algorithms: [SHA-1, SHA-256, RIPEMD-160]
    Key expiration times: []
    Key usage flags: [[auth, sign-data, certify-keys]]
  Robin Gareus <[email protected]>: [revoked]
    Revocation code: [UserIdInfoNoLongerValid]
    Revocation reason: []
  Robin Gareus <[email protected]>:
    Self-sig hash algorithms: [SHA-1]
    Preferred hash algorithms: [SHA-256, SHA-1, SHA-384, SHA-512, SHA-224]
    Key expiration times: []
    Key usage flags: [[auth, sign-data, certify-keys]]
  Robin Gareus (Robin@Harrison) <[email protected]>:
    Self-sig hash algorithms: [SHA-1]
    Preferred hash algorithms: [SHA-256, SHA-1, SHA-384, SHA-512, SHA-224]
    Key expiration times: []
    Key usage flags: [[auth, sign-data, certify-keys]]
Checking subkeys:
  one of the subkeys is encryption-capable: True
  fpr: 0F58 F4DD 3EEE D7BC 9381  C76F 558F 56A3 5EE4 BC0A
    version: v4
    timestamp: 20011208-180314
    algo/size: Elgamal encrypt-only 2048
    binding sig hash algorithms: [SHA-1]
    usage flags: []
    embedded cross-cert: False
    cross-cert hash algorithms: [SHA-1]
  fpr: C1A9 3D91 DCD0 5317 C051  6CAA A090 BCE0 2CF5 7F04
    version: v4
    timestamp: 20120420-000921
    algo/size: RSA 4096
    binding sig hash algorithms: [SHA-1]
    usage flags: [[sign-data]]
    embedded cross-cert: True
    cross-cert hash algorithms: [SHA-1]
  fpr: 02F2 893F 8426 1CF0 0F6F  ED83 6B4C DD16 B4AE 8282
    version: v4
    timestamp: 20120420-001057
    algo/size: RSA 4096
    binding sig hash algorithms: [SHA-1]
    usage flags: [[encrypt-storage, encrypt-communications]]
    embedded cross-cert: False
    cross-cert hash algorithms: [SHA-1]

I'm writing all this, because for Arch Linux it is possible to use an upstream's PGP signed tag or commit and verify against that upstream's signature. This comes with a few strings attached though:

• the key is RSA >= 4096 or elliptic curve (e.g. ed25519)
• the key ideally does not self-sign using SHA1 (i.e. uses SHA256 or above)
• upstream ideally has a document in place that states which keys are used for release signing and establishes additions and/or removals by editing the document using a signed commit (using a given trusted key ID), or otherwise cross-signs all eligible keys. This allows downstreams to follow the chain of trust.

In case you intend to provide such a scenario, you would have to create a new key (and sign it with your current key).

[x42]

upstream ideally has a document in place that states which keys are used

https://gareus.org/www/contact links to my GPG key. It's still a 2001 DSA but there is a 4096 bit RSA subkey from 2012 which is used for signing.

[x42]

1. the key is RSA >= 4096 or elliptic curve (e.g. ed25519)

That is already the case, commits are signed with RSA4096 (sub key A090BCE02CF57F04)

2. the key ideally does not self-sign using SHA1 (i.e. uses SHA256 or above)

various signatures are available: http://pgp.mit.edu/pks/lookup?search=Robin+Gareus&op=vindex

3. upstream ideally has a document in place that states which keys are used

https://gareus.org/www/contact