Hacker News Reader

Comment by rdxm | Hacker News Reader

In this day and age, it's arguably irresponsible to publish any tooling that does not organically integrate a requirement to use Sigstore for all packages allowed to be uploaded.

The very first things you should be talking about on your service is provenance mechanisms and security.

I don't believe I saw anything related to thos topics on your site. Did I miss it?

View on HN

WAPM already has a mechanism for signed packages (although not through Sigstore, first time I'm hearing of it but thanks for the reference!)

You can read more about it here: https://medium.com/wasmer/securing-wapm-packages-with-packag...

IMO just signing packages is a weak form of trust. Even without potentially using Sigstore, does WAPM now let you lock based both on the versions of dependencies, as well as the hash of their contents? I didn't see any mention of lock files with hashes anywhere.

In fairness, Sigstore is a pretty new technology. Existing package managers haven't integrated it yet, though are working towards it. For example, I've been working with colleagues on proposing a design for RubyGems[0]. And as far as I know we're about as far ahead as anyone has gotten.

There's an informal group of software repo folks meeting with some assistance from the OpenSSF. WAPM folks, please feel free to hit me up at my work email (in profile).

[0] https://github.com/rubygems/rfcs/pull/37

Sure, but "existing package managers haven't integrated it yet" because of a burden of legacy and wanting to ensure a smooth transition for the ecosystem; not because it's hard to integrate. It should be extremely simple for a greenfield package-ecosystem, that isn't replacing any other mechanism with Sigstore, to adopt it.

From what I've seen in a few minutes looking at Sigstore, it seems they require packages to be stored in a OCI-compliant store... which it differs on how package managers are storing packages. So it might be not as trivial.

Or perhaps I'm missing something?

https://github.com/sigstore/cosign

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...

Reply on news.ycombinator.com