Support GitHub and GitLab services for generate-key-pair #838
Labels
enhancement
New feature or request
Comments
|
I like it! |
|
+1 😄 |
gcbmykola
added a commit
to gcbmykola/cosign
that referenced
this issue
Jan 14, 2022
Current cosign github:// URI reference key generation feature is not using the repository public key for secrets encryption. The key reference is only added for Github secrets API request, the actual secret is provisioned in clear text, is not encrypted before it reaches the GitHub. As a result, when the secret is decrypted when used in a codespace (for example by Github Action) latter fails silently, and the resulting secret value is empty. Fix use libsodium sealed box to encrypt secrets before they reach GitHub as per API guidelines. Manual test: Before fix 1) $cosign generate-key-pair github://[OWNER]/[PROJECT_NAME] 2) Run action that uses COSIGN_PASSWORD, COSIGN_PRIVATE_KEY secrets Actual result Secret sizes are equal to 0 After fix 1) $cosign generate-key-pair github://[OWNER]/[PROJECT_NAME] 2) Run action that uses COSIGN_PASSWORD, COSIGN_PRIVATE_KEY secrets Actual result Secret sizes are as provisioned by cosign Fixes: sigstore#838 Signed-off-by: Mykola Kondratenko <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
Consider the following example:
What these providers going to do is that simply calling
secretAPI to create or update the generated private key in the secret variables. Something like:[UPSERT] /repos/:owner/:repo/actions/secretsinto$COSIGN_PRIVATE_KEYvariable.GitHub: https://docs.github.com/en/rest/reference/actions#secrets
GitLab: https://docs.gitlab.com/ee/api/project_level_variables.html
P.S: I am not so sure if we should call
GitHubandGitLabas a KMS provider. What about-gitflag?^ @developer-guy @erkanzileli 🤗
The text was updated successfully, but these errors were encountered: