Considerations for storing gem signatures in rubygems.org

[rochlefebvre]

This ruby-sigstore prototype currently relies on Rekor to host the gem signature, in the form of a hashedrekord log entry. These log entries are retrieved using the SHA256 digest of the gem file as a lookup.

We propose that rubygems.org acquire a copy of the log entry (or log entries) and then serve it alongside the gem in the repository. This decouples rubygems from sigstore at gem installation time. Given that log entries can neither be deleted nor modified, copies may be served from anywhere. Gem clients only need the correct Rekor public key to verify the log entry's signature and thus prove its authenticity.

hashedrekord log entries

hashedrekord log entries contain:

• the digest of the signed gem (body.spec.data)
• the gem signature (body.spec.signature.content)
• the x509 signing certificate (body.spec.signature.publicKey.content)
  • identifier for the signer, e.g. an email address or some kind of profile identifier
  • public key to verify the gem signature
• the verified creation time of the log entry (integratedTime)
• a signature of the log entry itself (signedEntryTimestamp)
• a hash of the public key which should be used to verify the log entry signature (logID)

It may be sufficient to store the whole log entry in rubygems.org, as long as we don't need to record additional metadata. The log entry is virtually tamper-resistant by virtue of its signature.

If we do need to store more info in the repository bucket, I can think of two choices.

define a new Rekor log entry type

Rekor supports the definition of new log entries (docs), hashedrekord being the simplest one. A rubygem type, or a more generic library package type (for other ecosystem packages), could model the missing fields. Richer log entries would continue to be signed by Rekor, and be tamper-resistant as well. They would also take the form of a single, self-contained json file.

The principal consequence is that rubygems.org would have no input into the log entry, and the metadata would come from the gem signer at build time.

define a new signature file/archive format

If rubygems.org needs to retain control over the extra metadata beyond what goes into the Rekor log entry, it may insert the log entry json into a larger json record, or store the extra metadata in a separate file (or files). Any data that lives outside of the log entry may need to be signed as well, this time by rubygems.org. This brings classic key management problems between the repository and the gem clients. Yuck.