Summary

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

• pkg/fulcioroots comes from cosign's cmd/cosign/cli/fulcio/fulcioroots@2ccdb3, 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/tuf@2ccdb3 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

Recently, we (w/@dentrax @erkanzileli) added other key management system support to Kyverno while verifying image signatures.^1 Then, I tried this feature on GCP while using GCP KMS and GKE. To achieve this I took advantage of Workload Identity Federation^2. To enable this I've used the following commands:

🎗 Cross-ref: https://github.com/kyverno/website/pull/376

$ export PROJECT_ID=$(gcloud config get-value project)
$ export CLUSTER_NAME="gke-wif"
$ gcloud container clusters create $CLUSTER_NAME \
    --workload-pool=$PROJECT_ID.svc.id.goog --num-nodes=2
$ export GSA_NAME=kyverno-sa
$ gcloud iam service-accounts create $GSA_NAME
$ gcloud iam service-accounts add-iam-policy-binding \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:${PROJECT_ID}.svc.id.goog[kyverno/kyverno]" \
  ${GSA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com
$ gcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --role roles/cloudkms.admin \
  --member serviceAccount:${GSA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com
$ kubectl annotate serviceaccount \
  --namespace kyverno \
  kyverno \
  iam.gke.io/gcp-service-account=${GSA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com

Then, I tried it with Kyverno but it didn't work as I expected. So, I decided to do a small test together with the google/cloud-sdk:slim image. So, I ran a Pod with this image, everything worked fine.

kubectl run -it --rm \
  --image google/cloud-sdk:slim \
  --serviceaccount kyverno \
  --namespace kyverno \
  workload-identity-test

cc: @JimBugwadia @dlorenc @cpanato

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

TL;DR: I propose transferring the core crypto functions of cosign to project Sigstore.

Motivation

We aim to make sigstore more commonize for cryptographic functions. Cosign calls the all the crypto-specific functions (i.e., generating ECDSA, signing, validating, etc.) from the keys.go file. If we get rid of those ECDSA-related functions, we would easily import sigstore project and use those functions again in cosign; moreover, we would import them on other non-container-specific projects. For cosign, this work will likely legacy change for no discernible benefit. I think it should be better to handle these functions (like GenerateKeyPair(), LoadECDSAPrivateKey(), LoadPublicKey(), etc.) inside the Sigstore itself.

We could find neither an actively discussing issue nor a PR. It is a great opportunity to get used to Sigstore project.

Implementation

func GeneratePrivateKey() (*ecdsa.PrivateKey, error)

func GenerateKeyPair(options *GenerateKeyPairOptions) (*KeyPair, error)

func LoadPublicKey(options *PublicKeyOptions) (PublicKey, error)

func LoadPrivateKey(options *PrivateKeyOptions) (signature.ECDSASignerVerifier, error)

func KeyToPem(pub crypto.PublicKey) ([]byte, error)

func CertToPem(c *x509.Certificate) []byte

func PemToECDSAKey(raw []byte) (*ecdsa.PublicKey, error)

Example Usages:

package main

import (
	"github.com/sigstore/sigstore/pkg/signature"
)

func main() {
    s, _ := signature.GenerateKeyPair(&signature.GenerateKeyPairOptions{
        PassFunc := pf()
    })

    content := "foo"
    
    pub, _ := signature.LoadPublicKey(&signature.PublicKeyOptions{
        Path: "cosign.pub",
    })

    key, _ := signature.LoadPrivateKey(&signature.PrivateKeyOptions{
        Path: "cosign.key",
        Pass: []byte("foo"),
    })
    
    s1, s2, _ := key.Sign(context.TODO(), []byte(content))
    
    _ = pub.Verify(context.TODO(), []byte(content), s1)

    // ...
}

Description

The auth process in gitsign outputs a URL you should be able to open in the browser to get a verification code, but the oauth2 server redirects to localhost after logging in. In this case localhost is not accessible so the auth flow cannot complete.

$ git commit -m "foo"
error opening browser: exit status 3
Go to the following link in a browser:

         https://oauth2.sigstore.dev/auth/auth?access_type=online&client_id=sigstore&code_challenge=P69wZPuonUkCS2-LAp26XO-Ndw3GzeyATyuixsMRz7c&code_challenge_method=S256&nonce=xxx&redirect_uri=http%3A%2F%2Flocalhost%3A45077%2Fauth%2Fcallback&response_type=code&scope=openid+email&state=xxx
Enter verification code:

Version

gitsign v0.2.0

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?

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

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

This updates the "Sigstore Auth Successful" page to be visually consistent with https://sigstore.dev and include a few links. Closes #732

Release Note

Added styling and documentation links to Sigstore Auth Successful page.

Documentation

No documentation update required.

Bumps golang.org/x/oauth2 from 0.3.0 to 0.4.0.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

This changes the behavior of Initialize to always recreate the local TUF repo. NewFromEnv remains the same.

Ref: https://github.com/sigstore/public-good-instance/issues/1161

Signed-off-by: Hayden Blauzvern [email protected]

Summary

Release Note

Documentation

Description

I'd like to obtain the hash algorithm used by a signature.Signer. I have a use case where the caller passes me a signature.Signer and I need to generate a signature and then wrap it in a descriptor that includes the hash algorithm. The implementation currently ignores the value in the signature.Signer to get around the fact that this value isn't exposed (https://github.com/sylabs/sif/issues/249).

I appreciate that signature.Signer itself can't be extended without breaking v1 module compatibility, but I'm wondering whether concrete types that implement it such as ED25519Signer could expose the hash algorithm, by implementing crypto.SIgnerOpts or similar? If that would be acceptable, I'd be happy to submit a PR for that.

Thanks!

  Hi,

I would like to enquire if SigStore has any plans to facilitiate integrating technology partners to act as KMS service providers via the the KMIP standard.

I note Sigstore has integrations in custom way with KMS providers for key storage using proprietary vender specific integrations which are tightly coupled to Sigstore e.g. Azure Key Vault, Hashicorp Vault, AWS KMS, and GCP KMS. We would like to enquire and discover if Sigstore intend to support a more general integration for KMS providers by leveraging an open standard like KMIP to facilitate other providers instead of integrating new partners individually in bespoke way.

We feel it may be mutually beneficial as this opens up the possibility for more KMS services to connect with Sigstore service(s) using KMIP for services that store keys in a KMS service provider and are KMIP ready.

Thanks,

Dave

Originally posted by @daveroche-digi in https://github.com/sigstore/sigstore/discussions/776

reusable-release.yml defines a workflow with inputs key_ring and key_name. These inputs are not actually used in the workflow: the values are instead hardocded to "release-cosign" and "cosign" respectively. I think this only works since all users happen to use the same key?