Please document artifact signing keys

[iay]

I'm doing due diligence for a project with a dependency on Guava. The latest release of Guava has a more modern version of j2objc-annotations as a dependency than before, and the new one is signed by a different PGP/GPG key than previously.

I'd like to establish that the new key 0xEE92349AD86DE446 is an official signing key for the project. On its face, it appears to represent @tomball so that's plausible, but I haven't been able to find anything substantiating that (it's only self-signed, so meaningless in isolation) or documenting the relationship between that specific key and the project.

Ideally, there would be something on the project's web site, or in a KEYS file in the repository, listing the keys we can expect published artifacts (e.g., in Maven Central) to be signed with. gpg --list-sigs format is fine.

(Updated for cut-and-paste error)

[tomball]

Is the key used by the Guava jars acceptable? Since it's also a Google project, we can follow the steps that team took to create that key to create our own. They'd also know how to navigate the maze of internal security measures our company has in place to guard new keys.

We hadn't paid much attention to this issue since our jar has no executable code in it, just simple annotations. But I understand that security procedures need to be carefully adhered to, even for situations where there's no actual risk.

[iay]

It looks like Guava are still signing artifacts with the same key they have been using for some years; it was grandfathered into our verification system in 2021 (as indeed was your old one B801E2F8EF035068EC1139CC29579F18FA8FD93B). So we'd probably make the same request of the Guava team the next time they change to a new key, unless they already document their setup somewhere.

You'll gather that I'm not really trying to get a handle on how you created the key that your artifacts are signed with; there's a limit to how much due diligence makes sense for one party to perform (and I have no idea what, if any, procedure the Guava team used; we have three keys grandfathered in for that project). All I really need here is something that convinces me that I should add the EB1B3DE71713C9EC2E87CC26EE92349AD86DE446 key to the list we regard as authoritative for the com.google.j2objc group. A list of fingerprints or encoded key blocks is usual and fairly simple to do. You might, of course, want to get deeper into process issues if you want to move to a new key again (a lot of people end up doing that if they move to new CI or release systems) but that's for another day.

[tomball]

Sorry to be a bit dense this morning, but I'm not clear exactly what change you'd like done to our project site. Just a new section at the bottom of our README.md? Please draft what text you'd like, and I'll add it right away.

[iay]

If you wanted to add something to the repository's README.md, it could look like this:

Artifact Signatures

This project publishes some artifacts through Maven Central with a groupId of com.google.j2objc.
These artifacts are currently signed with the following PGP/GPG key:

pub   rsa2048 2023-01-10 [SC] [expires: 2025-01-09]
      EB1B3DE71713C9EC2E87CC26EE92349AD86DE446
uid           [ unknown] Thomas Ball <tball@google.com>
sub   rsa2048 2023-01-10 [E] [expires: 2025-01-09]

Older artifacts are signed with the following PGP/GPG key:

pub   rsa2048 2015-09-25 [SC]
      B801E2F8EF035068EC1139CC29579F18FA8FD93B
uid           [ unknown] Tom Ball <tball724@gmail.com>
sub   rsa2048 2015-09-25 [E]

[yogurtearl]

Some examples of other libs publishing their signing keys:

https://square.github.io/okhttp/security/security/#verifying-artifacts

https://github.com/eclipse/jetty.project/blob/jetty-10.0.x/KEYS.txt
https://downloads.apache.org/commons/KEYS
https://downloads.apache.org/logging/KEYS

Looks like com.google.j2objc:j2objc-annotations:2.8 was signed with this key:

https://keyserver.ubuntu.com/pks/lookup?search=EE92349AD86DE446&fingerprint=on&op=index

[yogurtearl]

We hadn't paid much attention to this issue since our jar has no executable code in it, just simple annotations.

That might be true of the legit version but may NOT be true of a version signed with the wrong key. :)