Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ctfe public key default name breaks cosign #873

Open
federico-falconieri-form3 opened this issue Nov 29, 2023 · 7 comments
Open

ctfe public key default name breaks cosign #873

federico-falconieri-form3 opened this issue Nov 29, 2023 · 7 comments
Labels
bug Something isn't working

Comments

@federico-falconieri-form3

Description

I am not sure if this is a bug or a documentation problem. I'm leaving this here as I imagine that anyone deploying these days probably has the same issue.
I deployed scaffold 0.6.36, including tuf and got stuck with the following error with cosign v2.2.0 when performing signing

**Warning** Missing fallback target ctfe.pub, skipping
Error: getting ctlog public keys: no matching targets by custom metadata, fallbacks not found: ctfe.pub
main.go:74: error during command execution: getting ctlog public keys: no matching targets by custom metadata, fallbacks not found: ctfe.pub
Error: Process completed with exit code 1.

I also noticed that I don't have ctfe.pub in my root targets... I have ctlog_pubkey.

cosign initialize --root redacted/root.json --mirror redacted
Root status: 
 {
        "local": "redacted.../.sigstore/root",
        "remote": "redacted",
        "metadata": {
                "root.json": {
                        "version": 1,
                        "len": redacted,
                        "expiration": "redacted",
                        "error": ""
                },
                "snapshot.json": {
                        "version": 1,
                        "len": redacted,
                        "expiration": "redacted",
                        "error": ""
                },
                "targets.json": {
                        "version": 1,
                        "len": redacted,
                        "expiration": "redacted",
                        "error": ""
                },
                "timestamp.json": {
                        "version": 1,
                        "len": redacted,
                        "expiration": "redacted",
                        "error": ""
                }
        },
        "targets": [
                "rekor-pubkey",
                "ctlog-pubkey",
                "fulcio-cert"
        ]
}

This is different from what I can find in all guides online to deploy sigstore, for instance https://blog.stephane-robert.info/post/devops-cosign-rekor-private/ (it's in french, sorry, scroll down to the cosign -d initialize --root root.json --mirror https://tuf.robert.local)
Cosign does not seem to allow to override the filename, as it is hardcoded in https://github.com/sigstore/cosign/blob/878b6c766e17d59d5624c802a1e196e8e8d47f56/pkg/cosign/ctlog.go#L28.
In the end I was able to resolve this through the env variable SIGSTORE_CT_LOG_PUBLIC_KEY_FILE. But that is annoying because it requires to manually inspect the kubernetes secret to copy the public key...

PS is there a way to fetch that public key like there is for rekor api/v1/log/publicKey?

I do not understand currently if this is caused by configuration of tuf, ctlog, fulcio or the copysecrets jobs

Version

  • cosign: v2.2.0
  • scaffold: 0.6.36
@bobcallaway
Copy link
Member

@sabre1041
Copy link
Contributor

@federico-falconieri-form3 can you share your values file or the items unique to your deployment?

@federico-falconieri-form3
Copy link
Author

@sabre1041

Sure, however I cannot share the fulcio OIDC issuer configuration:

trillian:
  enabled: true
  namespace:
    create: true
  mysql:
    persistence:
      enabled: true

ctlog:
  enabled: true
  namespace:
    create: true

rekor:
  enabled: true
  namespace:
    create: true
  server:
    ingress:
      http:
        enabled: false # I create the ingress manually elsewhere 
    attestation_storage:
      enabled: false

fulcio:
  enabled: true
  namespace:
    create: true
  server:
    args:
      certificateAuthority: fileca
    ingress:
      http:
        enabled: false # I create the ingress manually elsewhere

tuf:
  enabled: true
  namespace:
    create: true
  ingress:
    enabled: false # I create the ingress manually elsewhere

copySecretJob:
  enabled: true

tsa:
  enabled: false

@sabre1041
Copy link
Contributor

sabre1041 commented Nov 30, 2023

@federico-falconieri-form3 if you want to add the following, it should solve the issues that you are facing

tuf:
  secrets:
    fulcio:
      path: fulcio_v1.crt.pem
    rekor:
      path: rekor.pub
    ctlog:
      path: ctfe.pub

These will be the default values moving forward

@kommendorkapten
Copy link
Member

Can you share the tuf targets.json config? It seems you are missing the metadata for ctlog-pubkey? Looking at Sigstore's metadata, it looks like this:

...
			"ctfe.pub": {
				"length": 177,
				"hashes": {
					"sha256": "7fcb94a5d0ed541260473b990b99a6c39864c1fb16f3f3e594a5a3cebbfe138a",
					"sha512": "4b20747d1afe2544238ad38cc0cc3010921b177d60ac743767e0ef675b915489bd01a36606c0ff83c06448622d7160f0d866c83d20f0c0f44653dcc3f9aa0bd4"
				},
				"custom": {
					"sigstore": {
						"status": "Active",
						"uri": "https://ctfe.sigstore.dev/test",
						"usage": "CTFE"
					}
				}
			},
...

So the usage attribute is what is being used to search for the correct public key.

@haydentherapper
Copy link
Contributor

haydentherapper commented Dec 4, 2023

@kommendorkapten One issue is I think this is lagging behind some of the updates to the expected Sigstore TUF metadata, it's not setting custom. sigstore/helm-charts#673 should fix this because it uses the fallback names, but a long-term fix is to set the custom metadata too.

@kommendorkapten
Copy link
Member

@haydentherapper ah, got it. I'm not very familiar with the scaffolding project and how the TUF repository is configured.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

5 participants