rfcs

Point 2 (Rubygems does not support package signing) is not true. Rubygems has supported package signing (`gem help cert`) since very early on, and it has an install flag `--trust-policy` which can be used to verify various things, including certs (https://github.com/rubygems/rubygems/blob/96e5cff3df491c4d94...). The experience in using it, however, sucks on every level. No one can really use the `High Security` policy level, because most gems aren’t signed. Most gems aren’t signed because there’s no clear benefit and it’s non-trivial to have shared certificates that can be used by multiple people authorized to release a particular gem. Most gems aren’t signed because there’s nowhere that public gem certs are published (there used to be with rubyforge), and you have to track down each cert you want to verify and download it separately. I u

It's an understandable confusion. The key components are Fulcio, a certificate authority, and Rekor, a transparency log. Fulcio generates short-lived public certificates for (approximately) each signature. Rekor stores the certificate and signature. In the case of cosign, this is done for container images and the signature is then made available via the OCI registry API. But it needn't be; for RubyGems we envisage storing log extracts side-by-side with .gem files. We anticipate other package systems will do similarly. One of our discussions has been whether we can converge on a shared format for those extracts. This section of the RubyGems signing RFC might help: https://github.com/Shopify/rfcs/blob/new-signing-mechanism/t...