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