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.

Sign up for GitHub

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

Jump to bottom

cosign cli doesn't recognize .../cryptoKeyVersions/$KEY_VERSION #2094

Closed
chuangw6 opened this issue Jul 22, 2022 · 7 comments
Closed

cosign cli doesn't recognize .../cryptoKeyVersions/$KEY_VERSION #2094

chuangw6 opened this issue Jul 22, 2022 · 7 comments
Labels
question Further information is requested

Comments

@chuangw6
Copy link

chuangw6 commented Jul 22, 2022 •
edited

I want to use cosign cli to verify a signature that was generated using sigstore pkg with a gcp kms ref gcpkms://projects/$PROJECT/locations/$LOCATION/keyRings/$KEYRING/cryptoKeys/$KEY/cryptoKeyVersions/$KEY_VERSION.

export KEY_REF=gcpkms://projects/chuangw-test/locations/global/keyRings/test/cryptoKeys/mykey/cryptoKeyVersions/1
cosign verify-blob --key $KEY_REF --signature signature signature

However, I got an error.

Error: verifying blob [signature]: loading public key: open gcpkms:/projects/chuangw-test/locations/global/keyRings/test/cryptoKeys/mykey/cryptoKeyVersions/1: no such file or directory
main.go:46: error during command execution: verifying blob [signature]: loading public key: open gcpkms:/projects/chuangw-test/locations/global/keyRings/test/cryptoKeys/mykey/cryptoKeyVersions/1: no such file or directory

If I changed the KEY_REF from .../cryptoKeyVersions/1 to .../versions/1, the cli verification works. If the version part /cryptoKeyVersions/1 is completely removed from the KEY_REF, the cli verification also works.

I am wondering if the verification with ../cryptoKeyVersions/$KEY_VERSION is intentionally not supported by cosign cli or it is a bug.
Thanks!
@chuangw6 chuangw6 added the question Further information is requested label Jul 22, 2022
@haydentherapper
Copy link
Contributor

I see in the error output it's prefixed with gcpkms:/ instead of gcpkms://. If you add an extra slash, do you still get the error?

@chuangw6
Copy link
Author

chuangw6 commented Aug 2, 2022

I see in the error output it's prefixed with gcpkms:/ instead of gcpkms://. If you add an extra slash, do you still get the error?

Hi @haydentherapper ,

The key ref in the cosign verify-blob --key starts with gcpkms:// rather than gcpkms:/. Don't know why in the error it complainsgcpkms:/.

@chuangw6
Copy link
Author

chuangw6 commented Aug 3, 2022 •
edited

To summarize working v.s. not-working key ref for signing & verification

For verification, cosign verify-blob --key $KEY_REF --signature ... is used.

  1. no version specified
    gcpkms://projects/$PROJECT/locations/$LOCATION/keyRings/$KEYRING/cryptoKeys/$KEY
    ✅ works for signing
    ✅ works for cosign verification

  2. version specified using cryptoKeyVersions
    gcpkms://projects/$PROJECT/locations/$LOCATION/keyRings/$KEYRING/cryptoKeys/$KEY/cryptoKeyVersions/$KEY_VERSION
    ✅ works for signing
    ❌ doesn't work for cosign verification (see the error in the issue description)

  3. version specified using versions
    gcpkms://projects/$PROJECT/locations/$LOCATION/keyRings/$KEYRING/cryptoKeys/$KEY/versions/$KEY_VERSION
    ✅ works for signing
    ✅ works for cosign verification

@haydentherapper
Copy link
Contributor

cc @cdris

@wlynch
Copy link
Member

wlynch commented Aug 18, 2022

@chuangw6 what version of cosign are you using?

I think sigstore/sigstore@21bce79 fixes this, and was added to cosign in v0.10.0

The gcpkms:/ behavior looks like cosign trying to interpret the string as a file path after the GCP KMS regex didn't match.

@znewman01 znewman01 mentioned this issue Sep 3, 2022
Merged
znewman01 added a commit to znewman01/cosign that referenced this issue Sep 3, 2022
@znewman01
Clarify error when KMS provider fails to load
9a39443 
Before:

    $ KEY_REF=gcpkms://projects/test/locations/global/keyRings/test/cryptoKeys/mykey/cryptoKeyVersions/1
    $ cosign verify-blob --key $KEY_REF --signature /dev/null /dev/null
    Error: verifying blob [/dev/null]: loading public key: loading URL: unrecognized scheme: gcpkms://
    main.go:62: error during command execution: verifying blob [/dev/null]: loading public key: loading URL: unrecognized scheme: gcpkms://

After:

    $ KEY_REF=gcpkms://projects/test/locations/global/keyRings/test/cryptoKeys/mykey/cryptoKeyVersions/1
    $ cosign verify-blob --key $KEY_REF --signature /dev/null /dev/null
    Error: verifying blob [/dev/null]: loading public key: new gcp kms client: google: could not find default credentials. See https://developers.google.com/accounts/docs/application-default-credentials for more information.
    main.go:62: error during command execution: verifying blob [/dev/null]: loading public key: new gcp kms client: google: could not find default credentials. See https://developers.google.com/accounts/docs/application-default-credentials for more information.

Addresses sigstore#2094; I'm not sure if this fixes it, but it'll give us more
information.

Signed-off-by: Zachary Newman <z@znewman.net>
@znewman01
Copy link
Contributor

I think this is a bad error message; see #2220

znewman01 added a commit to znewman01/cosign that referenced this issue Sep 3, 2022
@znewman01
Clarify error when KMS provider fails to load
cee72e1 
Before:

    $ KEY_REF=gcpkms://projects/test/locations/global/keyRings/test/cryptoKeys/mykey/cryptoKeyVersions/1
    $ cosign verify-blob --key $KEY_REF --signature /dev/null /dev/null
    Error: verifying blob [/dev/null]: loading public key: loading URL: unrecognized scheme: gcpkms://
    main.go:62: error during command execution: verifying blob [/dev/null]: loading public key: loading URL: unrecognized scheme: gcpkms://

After:

    $ KEY_REF=gcpkms://projects/test/locations/global/keyRings/test/cryptoKeys/mykey/cryptoKeyVersions/1
    $ cosign verify-blob --key $KEY_REF --signature /dev/null /dev/null
    Error: verifying blob [/dev/null]: loading public key: new gcp kms client: google: could not find default credentials. See https://developers.google.com/accounts/docs/application-default-credentials for more information.
    main.go:62: error during command execution: verifying blob [/dev/null]: loading public key: new gcp kms client: google: could not find default credentials. See https://developers.google.com/accounts/docs/application-default-credentials for more information.

Addresses sigstore#2094; I'm not sure if this fixes it, but it'll give us more
information.

Signed-off-by: Zachary Newman <z@znewman.net>
dlorenc pushed a commit that referenced this issue Sep 4, 2022
@znewman01
Clarify error when KMS provider fails to load (#2220)
9d3101b 
Before:

    $ KEY_REF=gcpkms://projects/test/locations/global/keyRings/test/cryptoKeys/mykey/cryptoKeyVersions/1
    $ cosign verify-blob --key $KEY_REF --signature /dev/null /dev/null
    Error: verifying blob [/dev/null]: loading public key: loading URL: unrecognized scheme: gcpkms://
    main.go:62: error during command execution: verifying blob [/dev/null]: loading public key: loading URL: unrecognized scheme: gcpkms://

After:

    $ KEY_REF=gcpkms://projects/test/locations/global/keyRings/test/cryptoKeys/mykey/cryptoKeyVersions/1
    $ cosign verify-blob --key $KEY_REF --signature /dev/null /dev/null
    Error: verifying blob [/dev/null]: loading public key: new gcp kms client: google: could not find default credentials. See https://developers.google.com/accounts/docs/application-default-credentials for more information.
    main.go:62: error during command execution: verifying blob [/dev/null]: loading public key: new gcp kms client: google: could not find default credentials. See https://developers.google.com/accounts/docs/application-default-credentials for more information.

Addresses #2094; I'm not sure if this fixes it, but it'll give us more
information.

Signed-off-by: Zachary Newman <z@znewman.net>

Signed-off-by: Zachary Newman <z@znewman.net>
@znewman01
Copy link
Contributor

I'm closing this, as I believe between #2220 (better error message) and sigstore/sigstore#359 the issue is resolved. Please reopen if you're seeing this again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
question Further information is requested
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@znewman01 @wlynch @haydentherapper @chuangw6