Summary

This moves these packages from sigstore/cosign into sigstore/sigstore.

• pkg/fulcioroots comes from cosign's cmd/cosign/cli/fulcio/[email protected], and drops that package's behavior when the SIGSTORE_ROOT_FILE env var is set -- this will remain in sigstore/cosign.
• pkg/tuf comes from cosign's pkg/cosign/[email protected] and is otherwise largely unchanged. Some methods were unexported that aren't used outside of this package.

Part of https://github.com/sigstore/cosign/issues/1865

Release Note

pkg/fulcioroots and pkg/tuf are moved from cosign repo

Description

I am opening this to ask if there's a contributor ladder defined for sigstore. How do I become an org member?

I would be happy to help do PR's reviews here, hoping to work towards maintainership.

previous contributions - mainly fuzzing sigstore and integrating with oss-fuzz

PR's in sigstore

1. https://github.com/sigstore/sigstore/pull/214
2. https://github.com/sigstore/sigstore/pull/213
3. https://github.com/sigstore/sigstore/pull/212
4. https://github.com/sigstore/sigstore/pull/197
5. https://github.com/sigstore/sigstore/pull/178
6. https://github.com/sigstore/sigstore/pull/177
7. https://github.com/sigstore/sigstore/pull/173
8. https://github.com/sigstore/sigstore/pull/170
9. https://github.com/sigstore/sigstore/pull/169
10. https://github.com/sigstore/sigstore/pull/168
11. https://github.com/sigstore/sigstore/pull/165
12. https://github.com/sigstore/sigstore/pull/164
13. https://github.com/sigstore/sigstore/pull/160
14. https://github.com/sigstore/sigstore/pull/158
15. https://github.com/sigstore/sigstore/pull/157
16. https://github.com/sigstore/sigstore/pull/148
17. https://github.com/sigstore/sigstore/pull/146
18. https://github.com/sigstore/sigstore/pull/127

oss-fuzz and actively maintaining the oss-fuzz issues

1. https://github.com/google/oss-fuzz/pull/6890
2. https://github.com/google/oss-fuzz/pull/6927
3. https://github.com/google/oss-fuzz/pull/6964

Issues in sigstore

https://github.com/sigstore/sigstore/issues?q=is%3Aissue+author%3Anaveensrinivasan

PR's in cosign

1. https://github.com/sigstore/cosign/pull/1141
2. https://github.com/sigstore/cosign/pull/1020
3. https://github.com/sigstore/cosign/pull/1001
4. https://github.com/sigstore/cosign/pull/971
5. https://github.com/sigstore/cosign/pull/968
6. https://github.com/sigstore/cosign/pull/944
7. https://github.com/sigstore/cosign/pull/124
8. https://github.com/sigstore/cosign/pull/121
9. https://github.com/sigstore/cosign/pull/120
10. https://github.com/sigstore/cosign/pull/119

Issues in cosign

https://github.com/sigstore/cosign/issues?q=is%3Aissue+author%3Anaveensrinivasan+

PR's rekor

https://github.com/sigstore/rekor/pulls?q=author%3Anaveensrinivasan

Issues in rekor

https://github.com/sigstore/rekor/issues?q=author%3Anaveensrinivasan

cc @lukehinds @dlorenc @bobcallaway

Folks,

There are a bunch of MPL libraries here: https://github.com/sigstore/sigstore/blob/main/go.mod#L58-L75

CNCF only allows a handful of MPL'ed libraries from hashicorp: https://github.com/cncf/foundation/blob/main/license-exceptions/cncf-exceptions-2019-11-01.json#L23-L46

the CNCF policy is written down here: https://github.com/cncf/foundation/tree/main/license-exceptions

Question is ... what do we do next?

Description

There's an interesting forgery for ECDSA where it's possible to forge a valid signature over a random value for a fixed public key. To defend against this, it's necessary to first hash a message before signing or verifying it. For ED25519, this is handled via a pre-hash, while for ECDSA, it's standard practice to first hash the message.

However, for the hashedrekord type, it's a requirement that we verify against a digest without hashing again. This is why we support WithDigest. This makes WithDigest unsafe. We can help defend against this if there is a check beforehand that the digest look like a digest, so a random value isn't accepted. For example, Rekor checks that the digest matches a SHA256 regex.

This is not a full proof approach, as it is still possible that a random value look like a digest, it's just hard to find such a value for this forgery (I think this is true, but I'd need someone more well-versed in elliptic curve crypto to verify this).

We should add a) warnings in comments about the dangers of verifying with a digest, and b) move the rekor checks into here to enforce that a digest looks like a digest.

The goal is it as easy as possible to put the business logic in pkg, re-use pkg across project within sigstore, and allow third parties to build on top of these libraries (e.g. to implement CI plugins)

TODOs:

• refactor existing libs in sigstore and cosign
• implement TPM signer

Signed-off-by: Jake Sanders [email protected]

Suggestion: Adding interactive flows for each specific identity provider, allowing users to skip the main idp selection page. I think one less click can improve the UX a bit. Further UX improvement is gained when browser uses a default idp account the user does may not need to interactively intervene at all. Such psodo-auto flow may also be valuable in automation uses cases, for example a git hook signing SLSA provenance.

Hope this helps . mikey strauss

Summary

Clients who want to enable specific kms implementations can import (or underscore-import) specific KMS impls they want, and otherwise don't have to depend on them.

Release Note

Specific kms implementations that are needed must be explicitly imported for init-time setup.

Summary

This patch removes the requirement of having the environment variables AZURE_TENANT_ID, AZURE_CLIENT_ID and AZURE_CLIENT_SECRET set to use the Azure KMS (KeyVault).

By removing the requirement, we enable usage of MSI (Managed Service Identity) through the NewAuthorizerFromEnvironment() and we at the same time add support for the NewAuthorizerFromCLI().

By splitting the function of calculating what method to use to it's own function , getAuthenticationMethod(), it's possible to test the logic separately.

We also introduce the new environment variable AZURE_AUTH_METHOD which if set to environment will use FromEnvironment() (may be useful for the MSI case) and if set to cli will use FromCLI().

If nothing is defined, FromEnvironment() will be tested first and then FromCLI(). :^)

Ticket Link

Fixes #223

Release Note

Add support for more Azure KMS authentication methods.

Enabling fuzzing for sigstore.

The first steps into fuzzing Sigstore. The goal is to integrate this into oss-fuzz using libfuzzer https://google.github.io/oss-fuzz/getting-started/new-project-guide/go-lang/ and https://security.googleblog.com/2021/11/clusterfuzzlite-continuous-fuzzing-for.html

Signed-off-by: naveen [email protected]

This is the first step of several to try to have signature library that can be used across all of sigstore's golang projects.

1. Have all non-KMS implementations implement crypto.Signer interface
2. Support hash algorithms other than SHA256
3. Replaces calls of fmt.Print(f|ln) to log.Printf()
4. Adds public key caching support for KMS providers
5. Use correct hashing algorithm per KMS provider response

There's an issue with the hashivault provider that I haven't quite been able to pin down yet. I noticed it while testing https://github.com/sigstore/cosign/pull/278, so the bug may not actually be here.

The existing PR works when you sign/verify with the provider API itself, but does not work when you verify against the exported public key. That is:

cosign sign -key hashivault://foo followed by cosign verify -key hashivault://foo works

but

cosign sign -key hashivault://foo followed by cosign public-key -key hashivault://foo > hk.pub && cosign verify -key hk.pub does not work.

Signed-off-by: Asra Ali [email protected]

Summary

• Adds a wrapper method to get rekor public keys, to use in cosign

I expect that with this method, we can now set sign/verify opts to include RekorPubKeys, so that people can define this themselves when they cosign as a library. This is how the fulcio roots works as well.

Ticket Link

Fixes

Release Note

Summary

Merge 'cosign/pkg/providers' into sigstore/sigstore.

This upstream's cosign's provider packages into sigstore/sigstore so that other tools like gitsign can use them without needing to depend on cosign. These packages are generic enough that they seem like a good fit here to be shared across sigstore projects.

This was intentionally done as a merge so that commit history is preserved for both the sigstore repo and the commits that are coming from cosign.

That said, we could also do this as a rebase on top of sigstore (would rewrite all commit times for cosign commits) or a single squash commit (all changes attributed to 1 commit). Let me know if you have thoughts on this.

Ticket Link

Part of https://github.com/sigstore/gitsign/issues/62

Release Note

cosign's OAuth provider packages are now available in sigstore/sigstore.

Description

I was looking at the permissions needed by the ClusterImagePolicy -> ConfigMap reconciler to deal with KMS, and it seems to require cloudkms.cryptoKeys.get, where I'd expect it to only need cloudkms.cryptoKeyVersions.viewPublicKey.

I can understand the signing path requiring more capabilities, but for things like the admission controller and cosign verify flows, it should be doable by folks that only have public key access.

cc @dekkagaijin @imjasonh

Followups from https://github.com/sigstore/sigstore/pull/435

• [x] remove panic in fulcioroots.Get()
• [ ] add doc comments for un-doc-commented exported methods (or unexport them if appropriate)
• [x] drop dependency on GCS and just make regular HTTP calls directly https://github.com/sigstore/cosign/pull/1967
• [ ] bump version: 3 in root.json (https://github.com/sigstore/sigstore/pull/435#discussion_r874926503)

/assign @haydentherapper

Description

Currently, when you successfully get through an OAuth flow, you're met with this page:

Good stuff:

• it's small and simple
• it's fast to load
• it's clear about what to do next

Bad stuff:

• it's black Times New Roman on white background (not Sigstore branding)

I think we have an opportunity to make this page feel really cohesive with the rest of the Sigstore brand. We shouldn't take this as an opportunity to load the page down with a bunch of CSS/JS/images, but I think there's improvements we could make, like:

• add a Sigstore logo
• use Sigstore's font/coloring
• ~~add a button to close, or maybe even "press space to close" -- JS won't let you close a window without some user action, but I think keyboard event should work.~~ edit: browsers no longer allow this

After https://github.com/sigstore/sigstore/pull/425 we'll only have one copy of this HTML, here:

https://github.com/sigstore/sigstore/blob/9a39e97a01521211a31ecc8c29ecf4545be3a73f/pkg/oauth/interactive.go#L19-L25