Giters

cbeust / jcommander

Command line parsing framework for Java

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Please document your gpg keys

yeikel opened this issue · comments

commented

We use Dependency Verification and currently there is no documentation stating which keys are safe

Could you please document this?

For example,1.81 was signed using dcba03381ef6c89096acd985ac5ec74981f9cda6

But 1.82 was signed is using a 22E44AC0622B91C3

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

commented

Since we release 1.83 with a different signing key, is this issue still and issue?

commented

Since we release 1.83 with a different signing key, is this issue still and issue?

Is that expected key documented somewhere in the repo?

commented

Since we release 1.83 with a different signing key, is this issue still and issue?

Is that expected key documented somewhere in the repo?

No it is not. According to https://central.sonatype.org/publish/requirements/gpg/#distributing-your-public-key it should be found on a keyserver.

commented

Since we release 1.83 with a different signing key, is this issue still and issue?

Is that expected key documented somewhere in the repo?

No it is not. According to https://central.sonatype.org/publish/requirements/gpg/#distributing-your-public-key it should be found on a keyserver.

Yes, but there are multiple key servers and there should be a way to link it back to the project. Storing it without any documentation creates the original problem described above.

For example,1.81 was signed using dcba03381ef6c89096acd985ac5ec74981f9cda6

But 1.82 was signed is using a 22E44AC0622B91C3

We should be able to find in the documentation what the expected key is and raise an exception if any new unknown and undocumented key is found with a release as it could be a compromised release

The SECURITY.md file is a good place to document that back in the repository.

For example, see this : https://github.com/qos-ch/slf4j/blob/master/SECURITY.md#verifying-contents