sigstore/sigstore-rs

An experimental Rust crate for sigstore

sigstore framework

sigstore/sigstore contains common Sigstore code: that is, code shared by infrastructure (e.g., Fulcio and Rekor) and Go language clients (e.g., Cosign and Gitsign).

This library currently provides:

• A signing interface (support for ecdsa, ed25519, rsa, DSSE (in-toto))
• OpenID Connect fulcio client code

The following KMS systems are available:

• AWS Key Management Service
• Azure Key Vault
• HashiCorp Vault
• Google Cloud Platform Key Management Service

For example code, look at the relevant test code for each main code file.

Fuzzing

The fuzzing tests are within https://github.com/sigstore/sigstore/tree/main/test/fuzz

Security

Should you discover any security issues, please refer to sigstores security process

For container signing, you want cosign

sigstore-rs's Issues

Better output for Rekor get_public_key

The formatting could be improved, and also it would be reasonable to have an option to output this to a file at a path chosen by the user.

Remove parsing of Rekor response once upstream issue is fixed

Remove or change parsing of Rekor response in src/rekor/apis/entries_api.rs once the upstream issue is fixed. Once upstream has a fix, we will be able to read this data in directly instead of cutting off the UUID that serves as the top-level key and stitching it back together with "uuid" as the top-level key instead.

Verify not working if the certificate annotation is present and there is no bundle annotation

Description

Both certificate and bundle are optional parameters when signing with cosign. If the certificate annotation is present and there is no bundle annotation, verification fails with the following error:

2022-09-29T14:56:46.298309Z  INFO sigstore::cosign::signature_layers: Skipping OCI layer because of error error=SigstoreRekorBundleNotFoundError
Image verification failed: No Signature Layer passed verification

This happens when providing a certificate when signing with cosign using a keypair and without enabling COSIGN_EXPERIMENTAL

How to reproduce it?

raulcabm/sigstore-test:1 was signed with cosign and pkcs11. dev.cosignproject.cosign/signature and dev.sigstore.cosign/certificate annotations are present, which is a valid scenario.

crane manifest $(cosign triangulate raulcabm/sigstore-test:1) | jq

{
  "schemaVersion": 2,
  "mediaType": "application/vnd.oci.image.manifest.v1+json",
  "config": {
    "mediaType": "application/vnd.oci.image.config.v1+json",
    "size": 248,
    "digest": "sha256:2d4f0c0130a23ca7ab0aa545aadb91674ba7eef0bb38ebada113b047d6508bad"
  },
  "layers": [
    {
      "mediaType": "application/vnd.dev.cosign.simplesigning.v1+json",
      "size": 254,
      "digest": "sha256:25fa425dace3302722778703a6b4387251af7c3a8513827f05010c0d0785d9f4",
      "annotations": {
        "dev.cosignproject.cosign/signature": "brAE3zRaN0Tcj7P9dcSe0yghHl0ToOqUMm8T2ll8uJLBJGmskDuyRtbZTNy8oNvHL6vvLpmX4SL29o+YGBk4GB+q8EPigvKLVgh3qD8u+7EiWltcDJyj8V/Re6LPdei6BDx5QtvHK4Dfq13Hc3JPlor7vOZkBvfr3LY3t/r9V2G+tE3ge8kvEj1XGPjhiJ5vYezuLZ0pxq1nqp18s+zzYLjTov6JqWflEltmQnZQAoNjfjGEH/4GAbpVZm3AyiBWfgmGqhsV0cdQzroJ6ruPRapIzlKJtg11n+KhtLsEViZE9BoA046E89XKWudKV7VJkcBz4wWlXhhDrQrVuaaqxw==",
        "dev.sigstore.cosign/certificate": "-----BEGIN CERTIFICATE-----\nMIIDETCCAfkCFAqyt8DGE5KXNAOHhfLMbY4bzTIIMA0GCSqGSIb3DQEBCwUAMEUx\nCzAJBgNVBAYTAkFVMRMwEQYDVQQIDApTb21lLVN0YXRlMSEwHwYDVQQKDBhJbnRl\ncm5ldCBXaWRnaXRzIFB0eSBMdGQwHhcNMjIwOTI5MTM1OTE4WhcNMzIwOTMwMTM1\nOTE4WjBFMQswCQYDVQQGEwJBVTETMBEGA1UECAwKU29tZS1TdGF0ZTEhMB8GA1UE\nCgwYSW50ZXJuZXQgV2lkZ2l0cyBQdHkgTHRkMIIBIjANBgkqhkiG9w0BAQEFAAOC\nAQ8AMIIBCgKCAQEA0LWSY//4shTayWKm8U0AOIN6sKh1Umh8eGIT31Wr4ULdWQjz\nraG0bd/tm1zUQjm8DIvzobIKPoZvKZxfN7cBiqCgHhCVwYKjs/4fIWq66dSHLRGD\nw1I6yEKpX+Fq8ZcmyhOmLIyfyh0p0BkRVjoOb0nQNPrNr1pIYd0uCn+GnQAL2dJZ\nAmhx+J5UEb0XF/3PMD7U8rNHj8Ah3NZnrosK51X5c05n8eIJUyEo/IMgmhbiylzO\nYM61yCSehZITCNSBKwEMpt3BENfaO4wGwBwQmou+Yjptdv4UvejrCCkApFmnyj6P\n/ko1Bl/MCF85IGrolKUX6NCGB6AgBSQp0GLYLwIDAQABMA0GCSqGSIb3DQEBCwUA\nA4IBAQAf1WTO1PnkRO1ZxOSLsU0UEXPp4oXQgU4nhC/mWf3Arn89KxB8LJawXKnc\nNWJQLIWGCwPPWMad0LK8yVUT0ZBFMVvOf5il9crmptpkkqLCilvi8mfLqR666pFk\nuFi28IMfz396qu5gSwd4lkJ7oaf9IyivibH+Zo/toXOyPFuaTKlPhS2q8hBtbDl1\nvbgIsC7dGFMQz59XPkqdWjoKsmUbpztIc709zOsvuOcmIwxGEpUc7rtWpdnwTK5f\nmjyRSrvnLQOJnlYBt6qqXTdz56r6rfs0eBi549IPIQ0fyurfzat+xG3TpAeT/f+K\nie75PIN1Zt+t59D6rGb4YPa+qSS6\n-----END CERTIFICATE-----\n"
      }
    }
  ]
}

Verification with cosign is successful, however sigstore-rs returns the SigstoreRekorBundleNotFoundError error. This can be tested with:

cargo run --example verify -- \
  --rekor-pub-key ~/.sigstore/root/targets/rekor.pub \
  --fulcio-cert fulcio.crt.pem  \
  -k pubkey.pem raulcabm/sigstore-test:1

Version

v0.4.0

This issue was raised in kubewarden/verify-image-signatures#20 (comment)

Add more detail to OIDC example

It would be helpful for someone running the example to know:

• what to do with the access token after receiving it
• should it be placed in a file at a certain location or in a certain format?
• does this work with the verify example?

Automate crates publish of releases

Perhaps we should utilise a GH action too cargo publish each release?

https://github.com/marketplace/actions/publish-crates

cc @flavio @cpanato

Fix error in Rekor get_log_info example

The current get log info example reports that it may return an error.

We should fix this bug so that it no longer returns an error. We can look to how the original Rekor handles this problem to fix it.

Original Rekor refs:
https://github.com/sigstore/rekor/blob/main/cmd/rekor-cli/app/log_info.go
https://github.com/sigstore/rekor/blob/7492834cfcf56c87ad80034099d337f0fb05181c/pkg/api/tlog.go#L40

Testing:
https://github.com/sigstore/rekor/blob/5cd02e717bae7298cc2d2c33ffdfc62c250c9a2c/pkg/client/rekor_client_test.go#L52
https://github.com/sigstore/rekor/blob/2081fbbf3372a00437b0eadc8ad53f2f17e035a8/tests/e2e_test.go#L214

Remove lines about timestamp in Rekor lib.rs

They are outdated.

sigstore-rs/src/rekor/lib.rs

Lines 82 to 83 in 371b22a

	//!- get_timestamp_cert_chain
	//!- get_timestamp_response

sigstore-rs/src/lib.rs

Lines 203 to 204 in 371b22a

	//!- get_timestamp_cert_chain
	//!- get_timestamp_response

Verification error: Not issued by a trusted root error

Description

Keyless verification is not working since the Fulcio Intermediate CA certificate was introduced, see sigstore/cosign#1774

This is the error I see:

INFO sigstore::cosign::signature_layers: Skipping OCI layer because of error error=CertificateValidityError("Not issued by a  trusted root")           

If the signature is stored in an OCI, the chain is stored in the annotation dev.sigstore.cosign/chain

Version

sigstore-rs v0.3.1

RUSTSEC-2020-0159: Potential segfault in `localtime_r` invocations

Potential segfault in localtime_r invocations

Details
Package	chrono
Version	0.4.19
URL	chronotope/chrono#499
Date	2020-11-10

Impact

Unix-like operating systems may segfault due to dereferencing a dangling pointer in specific circumstances. This requires an environment variable to be set in a different thread than the affected functions. This may occur without the user's knowledge, notably in a third-party library.

Workarounds

No workarounds are known.

References

• time-rs/time#293

See advisory page for additional details.

TUF: Target naming for usage

Description

In the next root-signing, we'll be migrating targets for fulcio under a fulcio subdirectory, and rekor under a rekor subdirectory (and keeping old targets for compatibility before we remove them).

This change was due to the fact that we had created delegations that were allowed to sign off on any path, but we actually only intend on certain delegations to add/update targets for a certain usage type (e.g. a delegation managing rekor rotations should only sign on the rekor/** space).

When we do this, fulcio targets will now be found on fulcio/* and rekor targets will be found on rekor/*. This may simplify some of the expressions for target matching SIGSTORE_FULCIO_CERT_TARGET_REGEX and SIGSTORE_REKOR_PUB_KEY_TARGET, since now their regex are simply fulcio/* or rekor/*. Old clients may continue to use this for a few months, given that we will continue supporting the top-level targets at their given paths, but we'd like clients to start moving towards retrieving fulcio certs by retrieving all targets under fulcio/*.

A few questions:

1. Does this targets() func retrieve delegated targets? Or just top-level targets? One way to find out is if you find a revocation.list returned in the current root. That is a delegated target not listed in the top-level targets.
2. When we totally remove the top-level original paths (rekor.pub and fulcio*.crt.pem) in favor of nesting them under subdirectories, will you need to continue to support old clients?

Propose Xynnn007 as maintainer

@Xynnn007 has done some solid work in sigstore-rs around implementing and refining the key interfaces and plans more work around an OCI interface.

I would like to propose we promote Xynnn007 to maintainer (codeowner)

@Xynnn007 please ack if you would like the role

Other maintainers please vote +1 / -1 or abstain

cc @flavio @viccuad @arsa

RUSTSEC-2018-0017: `tempdir` crate has been deprecated; use `tempfile` instead

tempdir crate has been deprecated; use tempfile instead

Details
Status	unmaintained
Package	tempdir
Version	0.3.7
URL	rust-lang-deprecated/tempdir#46
Date	2018-02-13

The tempdir crate has been deprecated
and the functionality is merged into tempfile.

See advisory page for additional details.

Verify local blobs

From @lukehinds

Currently sigstore-rs verifies a cosign signature stashed in an OCI registy, but we might also want to attest blobs locally (exist in rekor and signed with an ODIC account or pub key that we provide). We would likely want a client to perform this, but we expose the ABI in sigstore-rs to allow them to so so

Add examples for each of the cosign verification mechanisms

The README specifies that we can:

• Verify using a given key
• Verify bundle produced by transparency log (Rekor)
• Verify signature produced in keyless mode, using Fulcio Web-PKI

However, the current documented example is for verifying using a given key only. We should add two more examples.

Provide pure async variants for OIDC flows.

Current implementation of the OIDC flows requires blocking tasks.

This is limiting when applications are otherwise using awc which leads to using actix_rt for async executors.

Providing async_http_client variants for auth_url() and redirect_listener() would remove this limitation.

note this issue provided for tracking on a PR I'm opening.

import rekor crate

Import rekor-rs to this repository.

ToDo:

• import code (obviously) to src/rekor/
• implement CI job to verify fresh / latest code-gen from openapi (this might need some thinking about, how do we insure code is update?)
• verify docs look correct
• cut a release

cc @jyotsna-penumaka / @flavio

Key generation and signer interface

Much like the go counterpart in sigstore/sigstore, implement key generation and a signer interface. This should provide the following:

1. Generate of a key pair using a provided alg (rsa, ecdsa)
2. public key derive from private key
3. Signing interface
4. Serialisation (handle PEM / DER en/decode etc).

Online verification with Rekor

Description

Hi! First big thanks to @flavio for leading so much here :)

Is the intent of this crate to allow online verification with Rekor as well? Without a rust rekor client, it would have to be an HTTP client and a lot of overhead in request/response forming and parsing. We were curious about this from the sget side -- right now we can re-use the code here for offline verification using the bundle.

@jyotsna-penumaka @lkatalin

Are we using OpenAPI?

Quick question about our rekor submodule... a lot of the files (example here) have a header stating they are generated by OpenAPI, meaning they should not be edited manually. But I don't see any .yaml files included at all. Are we meant to have an openapi.yaml file somewhere to do this? Or are we intending to edit these files manually, and the header was left in by mistake?

Integration testing

We should introduce some level of integration / e2e testing.

Move Rekor module's lib.rs to mod.rs

This module has both a lib.rs file and a mod.rs file. According to Rust convention, all of this should be combined into mod.rs as this is a submodule.

Also, because of this anomaly, the Rekor module's doc tests are not being run when calling cargo test --doc.

Use right fulcio certificate when verifying bundles

Description

Fulcio has updated its certificate. Right now, inside of Sigstore's TUF repository there are 2 certificates:

• fulcio.crt.pem
• fulcio_v1.crt.pem

Keyless signatures produced some months ago have been signed with fulcio.crt.pem, while more recent ones have been signed with fulcio_v1.crt.pem.

Right now the cosign::Client uses just one certificate, which causes some signatures to fail verification.

Apparently the cosign client isn't affected by this issue. We should understand how the upstream client handles that, and replicate the behaviour here.

Fail on verify() if image has no signatures

Description

Right now, if one uses verify() against an image that doesn't contain signatures, it will return Ok(), with an empty Vec<SimpleSigning>
See:

sigstore-rs/src/cosign/mod.rs

Lines 276 to 282 in cc9fe80

	let verified_signatures = self.find_simple_signing_objects_satisfying_constraints(
	&signature_layers,
	source_image_digest,
	verification_key.as_ref(),
	&annotations.unwrap_or_default(),
	);
	Ok(verified_signatures)

As a user, I want to be sure that unsigned images don't slip through. Hence, I would prefer if verify() returns an Err when there are no signatures to be verified.

This way, I can delegate the responsibility to the library, and I don't need to check on my own if an image has signatures prior to calling verify() on it.

Double check intended tree size in Rekor

The original Rekor uses tree sizes equivalent to Rust's i64. Rekor-rs mixes i32 and i64. Instead it should use only i64 unless there is a good reason to do otherwise.

I would suggest going through the src/rekor code to find all instances of a tree size (this is usually a field in other structs) and making sure they are all i64, perhaps adding a tree_size type somewhere that is an alias to i64 and making sure it is used throughout.

Refs from golang Rekor:
https://github.com/sigstore/rekor/blob/547eb3cef9690bc97e73e35eb3bf1f40b18a3504/cmd/rekor-cli/app/log_info.go#L46
https://github.com/sigstore/rekor/blob/547eb3cef9690bc97e73e35eb3bf1f40b18a3504/pkg/sharding/ranges.go#L42

Fulcio client support

Provide a Fulcio client capable of creating and exchanging keys for certificates.

Inbound PR shortly.

verify example is confusing

https://github.com/sigstore/sigstore-rs/tree/main/examples/verify

I don''t understand why someone would provide a a cert email, fuclio cert and rekor pub key to verify the signing made with a cosign generated key. There is no trust relation between the cosign.pub key and the others.

I would have thought this would be more relevant:

cargo run --example verify -- -k cosign.pub registry-testing.svc.lan/busybox

or for keyless:

cargo run --example verify -- \
  --rekor-pub-key ~/.sigstore/root/targets/rekor.pub \
  --fulcio-crt fulcio.crt.pem \
  registry-testing.svc.lan/busybox

`filter_signature_layers()` is insufficient to verify images, and may provide false positives

Description

Current sigstore::cosign::filter_signature_layers() returns a list of signatures passing the constraints. This is not enough to verify if all the constraints have been satisfied; a constraint could make several layers pass at once, as applying constraints is a non-injective function (for example filtering with AnnotationVerifier will give us several layers that have passed verification).
For the other verifiers, we didn't realize, as they verify certs and pub keys, and normally there aren't duplicated signatureLayers with those.

We don't gain much information from filter_signature_layers() returning a vector of verified layers. We can calculate the unverified layers from that vector, but none of those 2 vectors give us information on satisfied or unsatisfied constraints.

Solution

Change cosign::filter_signature_layers() to return unsatisfied constraints.

What we really care about is filtering the constraints into those that got satisfied, and those that not. Consumers then can know that an image failed verification if there are unsatisfied constraints, or the image passed verification if all constraints were satisfied.

Also, information on why an image didn't pass verification can only be obtained from the list of unsatisfied constraints. I expect consumers to have verifiers that implement VerificationConstraint and std::fmt:Display, for example, to print to users those unsatisfied constraints.

Implement fulcio ODIC backed signing functionality

Introduce the ability to request an ODIC Token grant and certificate to sign artefacts with an ephemeral signing certificate.

Example code using the openidconnect crate: https://github.com/lukehinds/openidconnect-rs

Provide way to download rekor public key from Sigstore TUF repository

Currently library end users have to provide the Rekor public key when creating a Cosign Client. This is required to verify the cosign bundles.

Having to specify the Rekor public key is needed when the default public Rekor instance is not used (e.g. for testing, air-gapped environments,...), however this is not what the majority of people will do.

It would be of great help to provide a some method that downloads the official Rekor public key from Sigstore's TUF repository. This is what cosign does behind the scenes.

Add ability to verify signatures with a user provided certificate

Description

cosign allows users to sign objects using a certificate that has been issued by a user-managed root CA.

Consider the following scenario:

Company Acme Inc. runs its own PKI. An intermediate CA is used to issue certificates to its employees.
Employees rely on these certificates to sign their container images using cosign.

In this scenario, as a sigstore-rs consumer, I would like to be able to verify a container image by using the following input data:

• user certificate
• certificate chain
• name of the object to be verified

Audit for unwraps and replace with more descriptive error handling

Find examples of unwrap() and replace with more descriptive error handling.

Implement ambient credential detection for OIDC.

As per cosign and the sigstore-python library, implement ambient credential detection.

sigstore/sigstore-python#31

https://dlorenc.medium.com/a-bit-of-ambiance-comes-to-sigstore-f80d1d6b1c30

Implement verification of `dev.sigstore.cosign/certificate`

Description

The verification code should be extended to verify the contents of the dev.sigstore.cosign/certificate annotation.

This annotation is produced by cosign when signing in keyless mode:

COSIGN_EXPERIMENTAL=1 cosign sign registry-testing.svc.lan/kubewarden/disallow-service-nodeport

This will produce a manifest like that:

{
  "schemaVersion": 2,
  "config": {
    "mediaType": "application/vnd.oci.image.config.v1+json",
    "size": 233,
    "digest": "sha256:58a221cb6acea000c4a38491f6f1a2533c095a39a37f0af9275554a46fe69653"
  },
  "layers": [
    {
      "mediaType": "application/vnd.dev.cosign.simplesigning.v1+json",
      "size": 277,
      "digest": "sha256:e7801de935512e22b237c7b57e42ca4d20e2134bdf1b98f976c8f55d9cfe4067",
      "annotations": {
        "dev.cosignproject.cosign/signature": "MEUCIGqWScz7s9aP2sGXNFKeqivw3B6kPRs56AITIHnvd5igAiEA1kzbaV2Y5yPE81EN92NUFOl31LLJSvwsjFQ07m2XqaA=",
        "dev.sigstore.cosign/bundle": "{\"SignedEntryTimestamp\":\"MEUCIDBGJijj2FqU25yRWzlEWHqE64XKwUvychBs1bSM1PaKAiEAwcR2u81c42TLBk3lWJqhtB7SnM7Lh0OYEl6Bfa7ZA4s=\",\"Payload\":{\"body\":\"eyJhcGlWZXJzaW9uIjoiMC4wLjEiLCJraW5kIjoicmVrb3JkIiwic3BlYyI6eyJkYXRhIjp7Imhhc2giOnsiYWxnb3JpdGhtIjoic2hhMjU2IiwidmFsdWUiOiJlNzgwMWRlOTM1NTEyZTIyYjIzN2M3YjU3ZTQyY2E0ZDIwZTIxMzRiZGYxYjk4Zjk3NmM4ZjU1ZDljZmU0MDY3In19LCJzaWduYXR1cmUiOnsiY29udGVudCI6Ik1FVUNJR3FXU2N6N3M5YVAyc0dYTkZLZXFpdnczQjZrUFJzNTZBSVRJSG52ZDVpZ0FpRUExa3piYVYyWTV5UEU4MUVOOTJOVUZPbDMxTExKU3Z3c2pGUTA3bTJYcWFBPSIsImZvcm1hdCI6Ing1MDkiLCJwdWJsaWNLZXkiOnsiY29udGVudCI6IkxTMHRMUzFDUlVkSlRpQkRSVkpVU1VaSlEwRlVSUzB0TFMwdENrMUpTVU5rZWtORFFXWjVaMEYzU1VKQlowbFVRU3RRYzJGTGFtRkZXbkZ1TjBsWk9UUmlNV1V2YWtwdWFYcEJTMEpuWjNGb2EycFBVRkZSUkVGNlFYRUtUVkpWZDBWM1dVUldVVkZMUlhkNGVtRlhaSHBrUnpsNVdsTTFhMXBZV1hoRlZFRlFRbWRPVmtKQlRWUkRTRTV3V2pOT01HSXpTbXhOUWpSWVJGUkplQXBOVkVGNVRVUkJNMDFxVlhoT2JHOVlSRlJKZUUxVVFYbE5SRUV6VGtSVmVFNVdiM2RCUkVKYVRVSk5SMEo1Y1VkVFRUUTVRV2RGUjBORGNVZFRUVFE1Q2tGM1JVaEJNRWxCUWtsT1pYZFJRbE14WmpSQmJVNUpSVTVrVEN0VkwwaEtiM1JOVTAwM1drNXVhMVJ1V1dWbWVIZFdPVlJGY25CMmJrRmFNQ3RFZWt3S2VXWkJRVlpoWlVwMFMycEdkbUpQVkdJNFJqRjVhRXBHVlRCWVdTdFNhV3BuWjBWd1RVbEpRa3BVUVU5Q1owNVdTRkU0UWtGbU9FVkNRVTFEUWpSQmR3cEZkMWxFVmxJd2JFSkJkM2REWjFsSlMzZFpRa0pSVlVoQmQwMTNSRUZaUkZaU01GUkJVVWd2UWtGSmQwRkVRV1JDWjA1V1NGRTBSVVpuVVZWTlpqRlNDazFOYzNGT1JrSnlWMko0T0cxU1RtUjRUMnRGUlZsemQwaDNXVVJXVWpCcVFrSm5kMFp2UVZWNVRWVmtRVVZIWVVwRGEzbFZVMVJ5UkdFMVN6ZFZiMGNLTUN0M2QyZFpNRWREUTNOSFFWRlZSa0ozUlVKQ1NVZEJUVWcwZDJaQldVbExkMWxDUWxGVlNFMUJTMGRqUjJnd1pFaEJOa3g1T1hkamJXd3lXVmhTYkFwWk1rVjBXVEk1ZFdSSFZuVmtRekF5VFVST2JWcFVaR3hPZVRCM1RVUkJkMHhVU1hsTmFtTjBXVzFaTTA1VE1XMU9SMWt4V2xSbmQxcEVTVFZPVkZGMUNtTXpVblpqYlVadVdsTTFibUl5T1c1aVIxWm9ZMGRzZWt4dFRuWmlVemxxV1ZSTk1sbFVSbXhQVkZsNVRrUkthVTlYV21wWmFrVXdUbWs1YWxsVE5Xb0tZMjVSZDBsQldVUldVakJTUVZGSUwwSkNXWGRHU1VWVFdtMTRhR1J0YkhaUlIwNW9Zek5TYkdKSGVIQk1iVEZzVFVGdlIwTkRjVWRUVFRRNVFrRk5SQXBCTW10QlRVZFpRMDFSUXpOWk1uVnNVRlJ6VUcxT1V6UmplbUZMWldwbE1FSnVUMUZJZWpWbE5rNUNXREJDY1hnNVdHTmhLM1F5YTA5cE1UZHpiM0JqQ2k5MkwzaElNWGhNZFZCdlEwMVJSRXRPUkRSWGFraG1TM0ZZV0U5bFZYWmFPVUU1TmtSeGNrVjNSMkZ4UjAxMGJrbDFUalJLZWxwWllWVk1Xbko0T1djS2IxaHhjVzh2UXpsUmJrOUlWSFJ2UFFvdExTMHRMVVZPUkNCRFJWSlVTVVpKUTBGVVJTMHRMUzB0Q2c9PSJ9fX19\",\"integratedTime\":1634714717,\"logIndex\":783607,\"logID\":\"c0d23d6ad406973f9559f3ba2d1ca01f84147d8ffc5b8445c224f98b9591801d\"}}",
        "dev.sigstore.cosign/certificate": "-----BEGIN CERTIFICATE-----\nMIICdzCCAfygAwIBAgITA+PsaKjaEZqn7IY94b1e/jJnizAKBggqhkjOPQQDAzAq\nMRUwEwYDVQQKEwxzaWdzdG9yZS5kZXYxETAPBgNVBAMTCHNpZ3N0b3JlMB4XDTIx\nMTAyMDA3MjUxNloXDTIxMTAyMDA3NDUxNVowADBZMBMGByqGSM49AgEGCCqGSM49\nAwEHA0IABINewQBS1f4AmNIENdL+U/HJotMSM7ZNnkTnYefxwV9TErpvnAZ0+DzL\nyfAAVaeJtKjFvbOTb8F1yhJFU0XY+RijggEpMIIBJTAOBgNVHQ8BAf8EBAMCB4Aw\nEwYDVR0lBAwwCgYIKwYBBQUHAwMwDAYDVR0TAQH/BAIwADAdBgNVHQ4EFgQUMf1R\nMMsqNFBrWbx8mRNdxOkEEYswHwYDVR0jBBgwFoAUyMUdAEGaJCkyUSTrDa5K7UoG\n0+wwgY0GCCsGAQUFBwEBBIGAMH4wfAYIKwYBBQUHMAKGcGh0dHA6Ly9wcml2YXRl\nY2EtY29udGVudC02MDNmZTdlNy0wMDAwLTIyMjctYmY3NS1mNGY1ZTgwZDI5NTQu\nc3RvcmFnZS5nb29nbGVhcGlzLmNvbS9jYTM2YTFlOTYyNDJiOWZjYjE0Ni9jYS5j\ncnQwIAYDVR0RAQH/BBYwFIESZmxhdmlvQGNhc3RlbGxpLm1lMAoGCCqGSM49BAMD\nA2kAMGYCMQC3Y2ulPTsPmNS4czaKeje0BnOQHz5e6NBX0Bqx9Xca+t2kOi17sopc\n/v/xH1xLuPoCMQDKND4WjHfKqXXOeUvZ9A96DqrEwGaqGMtnIuN4JzZYaULZrx9g\noXqqo/C9QnOHTto=\n-----END CERTIFICATE-----\n",
        "dev.sigstore.cosign/chain": "\n-----BEGIN CERTIFICATE-----\nMIIB+DCCAX6gAwIBAgITNVkDZoCiofPDsy7dfm6geLbuhzAKBggqhkjOPQQDAzAq\nMRUwEwYDVQQKEwxzaWdzdG9yZS5kZXYxETAPBgNVBAMTCHNpZ3N0b3JlMB4XDTIx\nMDMwNzAzMjAyOVoXDTMxMDIyMzAzMjAyOVowKjEVMBMGA1UEChMMc2lnc3RvcmUu\nZGV2MREwDwYDVQQDEwhzaWdzdG9yZTB2MBAGByqGSM49AgEGBSuBBAAiA2IABLSy\nA7Ii5k+pNO8ZEWY0ylemWDowOkNa3kL+GZE5Z5GWehL9/A9bRNA3RbrsZ5i0Jcas\ntaRL7Sp5fp/jD5dxqc/UdTVnlvS16an+2Yfswe/QuLolRUCrcOE2+2iA5+tzd6Nm\nMGQwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQEwHQYDVR0OBBYE\nFMjFHQBBmiQpMlEk6w2uSu1KBtPsMB8GA1UdIwQYMBaAFMjFHQBBmiQpMlEk6w2u\nSu1KBtPsMAoGCCqGSM49BAMDA2gAMGUCMH8liWJfMui6vXXBhjDgY4MwslmN/TJx\nVe/83WrFomwmNf056y1X48F9c4m3a3ozXAIxAKjRay5/aj/jsKKGIkmQatjI8uup\nHr/+CxFvaJWmpYqNkLDGRU+9orzh5hI2RrcuaQ==\n-----END CERTIFICATE-----"
      }
    }
  ]
}

The purpose of this issue is to implement the same checks cosign performs when looking at this dev.sigstore.cosign/certificate

Add Víctor Cuadrado Juan to the list of maintainers

Description

I would like @viccuad to become one of the maintainers of sigstore-rs. Lately he has been helping a lot with code reviews, plus he already contributed code fixes and enhancements.

Improve UI for key-based verification by having defaults for rekor pubkey and fulcio cert

Description

Key-based verification uses the TUF root and therefore requires knowing the location of the Rekor pub key and Fulcio cert files (these are generated with cosign init and live in ~/.sigstore/root/targets/ by default). The original cosign does not require the user to input these values. It may be worth emulating the original cosign's design here and having a sane default that the user does not need to provide.

Making fulcio and rekor clients independent of reqwest

I'm interested in package signing support in crates.io + cargo using Sigstore. After looking through some of the earlier discussions from @lukehinds and others, it seems to me that the main obstacle is that crates.io and cargo teams have little time to work on this and/or review. In order to push things forward, I'm exploring an approach that could be used as basis for an RFC, with little changes to the existing crates.io and cargo code bases to reduce friction in adding the support and migrating existing infrastructure.

One of the things I've found is that cargo currently uses the curl (+ curl-sys) crate for HTTP, and does not support async Rust. I think it's going to be hard to justify changing a big chunk of cargo dependencies for this, so I'd like to hear others think.

Could it make sense to modify the fulcio and rekor clients, or alternatively create a set of clients with a lower level API, that could be re-used in places like cargo?

Add ability to parse Rekor LogEntry

The LogEntry.body for example should not just be a String, but a typed struct where you can access subfields and extract data.

remove API for Rekor_Version endpoint

Description

sigstore/rekor#1022 proposes that the /api/v1/version endpoint be removed from rekor, so opening this tracking issue to remove it from this client library.

Fix cosign tests failing due to certs "not issued by a trusted root"

Description

Cosign tests are failing. See original comment.
Tests output here

Version

Latest

Implement verification of `dev.sigstore.cosign/bundle` - no fulcio integration

Description

The verification code should be extended to verify the contents of the dev.sigstore.cosign/bundle annotation.

To keep this issue smaller, we are not going to cover the case of a signature produced in keyless mode.

The signature can be produced in this way:

COSIGN_EXPERIMENTAL=1 cosign sign -key cosign.key registry-testing.svc.lan/busybox:latest

This will produce a manifest like the following one:

{
  "schemaVersion": 2,
  "config": {
    "mediaType": "application/vnd.oci.image.config.v1+json",
    "size": 233,
    "digest": "sha256:6be03ee91610ddcd1b1c5b664bb2ef319a85b4ca9ebee1d64d87729c5fd83a91"
  },
  "layers": [
    {
      "mediaType": "application/vnd.dev.cosign.simplesigning.v1+json",
      "size": 248,
      "digest": "sha256:3af4414d20c9e1cb76ccc72aae8b242166dabe6af531a4a790db8e2f0e5ee7c9",
      "annotations": {
        "dev.cosignproject.cosign/signature": "MEYCIQDWWxPQa3XFUsPbyTY+n+bZu/6Pwhg5WwyYDQtEfQho9wIhAPkKW7eub8b7BX+YbbRac8TwwIrK5KxvdtQ6NuoD+ivW",
        "dev.sigstore.cosign/bundle": "{\"SignedEntryTimestamp\":\"MEUCIDx9M+yRpD0O47/Mzm8NAPCbtqy4uiTkLWWexW0bo4jZAiEA1wwueIW8XzJWNkut5y9snYj7UOfbMmUXp7fH3CzJmWg=\",\"Payload\":{\"body\":\"eyJhcGlWZXJzaW9uIjoiMC4wLjEiLCJraW5kIjoicmVrb3JkIiwic3BlYyI6eyJkYXRhIjp7Imhhc2giOnsiYWxnb3JpdGhtIjoic2hhMjU2IiwidmFsdWUiOiIzYWY0NDE0ZDIwYzllMWNiNzZjY2M3MmFhZThiMjQyMTY2ZGFiZTZhZjUzMWE0YTc5MGRiOGUyZjBlNWVlN2M5In19LCJzaWduYXR1cmUiOnsiY29udGVudCI6Ik1FWUNJUURXV3hQUWEzWEZVc1BieVRZK24rYlp1LzZQd2hnNVd3eVlEUXRFZlFobzl3SWhBUGtLVzdldWI4YjdCWCtZYmJSYWM4VHd3SXJLNUt4dmR0UTZOdW9EK2l2VyIsImZvcm1hdCI6Ing1MDkiLCJwdWJsaWNLZXkiOnsiY29udGVudCI6IkxTMHRMUzFDUlVkSlRpQlFWVUpNU1VNZ1MwVlpMUzB0TFMwS1RVWnJkMFYzV1VoTGIxcEplbW93UTBGUldVbExiMXBKZW1vd1JFRlJZMFJSWjBGRlRFdG9SRGRHTlU5TGVUYzNXalU0TWxrMmFEQjFNVW96UjA1Qkt3cHJkbFZ6YURSbFMzQmtNV3gzYTBSQmVtWkdSSE0zZVZoRlJYaHpSV3RRVUhWcFVVcENaV3hFVkRZNGJqZFFSRWxYUWk5UlJWazNiWEpCUFQwS0xTMHRMUzFGVGtRZ1VGVkNURWxESUV0RldTMHRMUzB0Q2c9PSJ9fX19\",\"integratedTime\":1634714179,\"logIndex\":783606,\"logID\":\"c0d23d6ad406973f9559f3ba2d1ca01f84147d8ffc5b8445c224f98b9591801d\"}}"
      }
    }
  ]
}

The purpose of this issue is to implement the same checks cosign performs when looking at this dev.sigstore.cosign/bundle

Security Policy violation Branch Protection

This issue was automatically created by Allstar.

Security Policy Violation
Dismiss stale reviews not configured for branch main
Block force push not configured for branch main

---

This issue will auto resolve when the policy is in compliance.

Issue created by Allstar. See https://github.com/ossf/allstar/ for more information. For questions specific to the repository, please contact the owner or maintainer.

Take an oauth2 token source for Rekor api

Here is the reference.

Add conformance testing

Hello sigstore-rs devs!

Description

This is a tracking issue for conformance testing between this client implementation and other Sigstore clients, similar to sigstore/sigstore-java#236 and sigstore/sigstore-python#297.

The rough idea here:

• Implement a small "driver" for this Sigstore client, one that adheres to the CLI protocol for the conformance suite
• Add a new conformance.yml workflow that applies the trailofbits/sigstore-conformance action via the driver

@tetsuo-cpp and I are happy to take a stab at the work here, whenever you feel it's appropriate!

cc @di

Fix error in create_log_entry example

The current example reports that it may return an error.

We should change the example to (by default) create fresh entry data (this requires either a new test file or a new signing key or both, I don't remember offhand but it can be tested), upload this data to Rekor, and then clean up after itself.

Add OCI container image signing

Description

Like the counterpart in sigstore/cosign, implement OCI container image signing.

Add more detail to key based verification example

It would be helpful to have more explanation on:

• downloading cosign separately from this repo
• possibly, how to use the example with some other signed container of choice (including setting up PAT for ghcr or similar)
• how to fill out the values for the rekor pub key and fulcio cert and/or set their locations

Switch to Fulcio V2 API

Description

The Fulcio V1 API will be turned down in the coming months.

https://github.com/sigstore/sigstore-rs/blob/main/src/fulcio/mod.rs#L20 will need to be updated to https://github.com/sigstore/fulcio/blob/main/fulcio.proto#L65. Fulcio V2 supports either gRPC or HTTP.

Update generation of models from OpenAPI to protobuf

Here is the issue to align how models in the various repos are generated: sigstore/protobuf-specs#3
Also, more detailed discussion here.

Better error message when OCI artifact doesn't have a sigstore manifest

The error message returned when an OCI artifact doesn't have a sigstore manifest should be improved.

How to reproduce

Attempt the verification of a container image that has not been signed with cosign:

cargo run --example verify -- --rekor-pub-key ~/.sigstore/root/targets/rekor.pub --fulcio-crt fulcio.crt.pem registry-testing.svc.lan/kubewarden/secure-pod-images --cert-email '[email protected]'

The verification will fail because the registry-testing.svc.lan/kubewarden/secure-pod-images:<cosign triangulation result> does not exist.

However the error message is not clear:

Image verification failed: Cannot pull manifest for image registry-testing.svc.lan/kubewarden/secure-pod-images:sha256-72b4569c3daee67abeaa64192fb53895d0edb2d44fa6e1d9d4c5d3f8ece09f6e.sig: OCI API error: manifest unknown on https://registry-testing.svc.lan/v2/kubewarden/secure-pod-images/manifests/sha256-72b4569c3daee67abeaa64192fb53895d0edb2d44fa6e1d9d4c5d3f8ece09f6e.sig

A better error message could be:

Image verification filed: the image hasn't been signed with cosign. The <registry/image:triangulation> OCI object could not be found

RUSTSEC-2020-0071: Potential segfault in the time crate

Potential segfault in the time crate

Details
Package	time
Version	0.1.43
URL	time-rs/time#293
Date	2020-11-18
Patched versions	>=0.2.23
Unaffected versions	=0.2.0,=0.2.1,=0.2.2,=0.2.3,=0.2.4,=0.2.5,=0.2.6

Impact

Unix-like operating systems may segfault due to dereferencing a dangling pointer in specific circumstances. This requires an environment variable to be set in a different thread than the affected functions. This may occur without the user's knowledge, notably in a third-party library.

The affected functions from time 0.2.7 through 0.2.22 are:

• time::UtcOffset::local_offset_at
• time::UtcOffset::try_local_offset_at
• time::UtcOffset::current_local_offset
• time::UtcOffset::try_current_local_offset
• time::OffsetDateTime::now_local
• time::OffsetDateTime::try_now_local

The affected functions in time 0.1 (all versions) are:

• at
• at_utc
• now

Non-Unix targets (including Windows and wasm) are unaffected.

Patches

Pending a proper fix, the internal method that determines the local offset has been modified to always return None on the affected operating systems. This has the effect of returning an Err on the try_* methods and UTC on the non-try_* methods.

Users and library authors with time in their dependency tree should perform cargo update, which will pull in the updated, unaffected code.

Users of time 0.1 do not have a patch and should upgrade to an unaffected version: time 0.2.23 or greater or the 0.3 series.

Workarounds

No workarounds are known.

References

time-rs/time#293

See advisory page for additional details.