Regarding PGP key documentation

[yeikel]

Hi team,

We use Dependency Verification and I was unable to find any documentation stating which keys are safe

Could you please document the PGP keys that are used for your releases?

Here are some examples of other projects documenting what key they use to sign their artifacts.

https://github.com/qos-ch/slf4j/blob/master/SECURITY.md#verifying-contents
https://square.github.io/okhttp/security/security/#verifying-artifacts
https://downloads.apache.org/logging/KEYS

As an example, 2.13.4 was signed with 3D12CA2AC19F3181

With the following information:

pub    3D12CA2AC19F3181
uid    Tatu Saloranta (cowtowncoder) <[email protected]>

sub    575D6C921D84AC76
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: BCPG v1.68

If you have an existing documentation about this, please let me know :)

[yeikel]

@cowtowncoder Do you happen to know about this? As the key belongs to you supposedly

[cowtowncoder]

Maybe

https://github.com/FasterXML/jackson/blob/master/KEYS

?

[cowtowncoder]

TBH I had forgotten having added it myself, until someone else asked about it.

I think more should be done to link to it, would be open to PRs or suggestions of where/how to explain KEYS file further

[yeikel]

My understanding is that keys should not need to change between releases unless you decide to revoke a previous key. Some teams run with a single key such as square

In any case,KEYS or SECURITY.MD are good places to document this. The only challenge is that this should probably be propagated to the other repositories or at least have a SECURITY.MD file pointing to a central location. Otherwise, it will be a little challenging to find them with ease when consuming any of the individual modules.

Additionally, I think that a good practice would be to ensure that updating the keys is part of the release process/checklist so that when a new release is created, the keys are updated if needed

[cowtowncoder]

Keys have so far been re-generated because of expiration, not revoking for any other reason.

Agreed on SECURITY.MD, looks like the good place. And yes, with multiple repos it is challenging.

The challenge with key handling is that it is too infrequent so one would actually would get routine on how it's done (or remember), but frequent enough to always come up when you least expect it...
In general it makes sense not to create keys with unlimited or super long expiration time (while one can try revoking keys, doing that requires knowledge of problem like breach).

[cowtowncoder]

Ohhh. After talking to a friend I realized that I was wrong to assume that expired GPG keys are useless. Turns out one can indeed extend validity time of keys, even ones already expired:

https://superuser.com/questions/813421/can-you-extend-the-expiration-date-of-an-already-expired-gpg-key

So going forward I will try this, instead of generating new keys.

Aside from this, I am now adding links to the main KEYS file from other repos' SECURITY.md; I hope this helps validation.

[pjfanning]

extending the life span of the key is the correct way to go - the public key part will be slightly different after you extend the key so you will need to update your KEYS file