4 ms·

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 allow

by rdxm 5y ago

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?

syrusakbary 5y ago
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-package-signing-3cf0d12f32f3 https://medium.com/wasmer/securing-wapm-packages-with-packag...
- no_circuit 5y ago
  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.
jacques_chester 5y ago
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 https://github.com/rubygems/rfcs/pull/37
- derefr 5y ago
  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.
  - syrusakbary 5y ago
    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 https://github.com/sigstore/cosign
    - jacques_chester 5y ago
      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/text/0000-introduce-a-new-signing-mechanism.md#background-concepts https://github.com/Shopify/rfcs/blob/new-signing-mechanism/t...

by rdxm 5y ago

syrusakbary 5y ago

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-package-signing-3cf0d12f32f3 https://medium.com/wasmer/securing-wapm-packages-with-packag...

no_circuit 5y ago
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.

jacques_chester 5y ago

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 https://github.com/rubygems/rfcs/pull/37

derefr 5y ago
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.
- syrusakbary 5y ago
  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 https://github.com/sigstore/cosign
  - jacques_chester 5y ago
    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/text/0000-introduce-a-new-signing-mechanism.md#background-concepts https://github.com/Shopify/rfcs/blob/new-signing-mechanism/t...