Repository navigation
Error: Failed to remove private key #200
Description
Description:
When attempting to deploy to a maven repository following the configuration documentation [1] the deploy action is successful but the action fails consistently on the "Post" step with output:
Post job cleanup.
Removing private key from keychain
Error: Failed to remove private key
The setup-java code where the attempt to remove the key occurs here: https://github.com/actions/setup-java/blob/v2.0.0/src/cleanup-java.ts. Note that the error is swallowed, making it harder to know why the failure is occurring.
[1] https://github.com/actions/setup-java/blob/main/docs/advanced-usage.md#Publishing-using-Apache-Maven
Task version:
actions/setup-java@v2
Platform:
- Ubuntu
- macOS
- Windows
Runner type:
- Hosted
- Self-hosted
Repro steps:
A description with steps to reproduce the issue. If your have a public example or repo to share, please provide the link.
Github actions workflow: https://github.com/duracloud/duracloud-db/blob/4afd1ac05398ff95c6c3ee88734b0bfa2ad2614f/.github/workflows/deploy-snapshot.yml
An example of a failed run: https://github.com/duracloud/duracloud-db/runs/3205773250
Expected behavior:
A description of what you expected to happen.
The GPG key would be removed and the job would complete successfully.
Actual behavior:
A description of what is actually happening.
An error is printed and the step and job are failed.
Activity
dmitry-shibanov commentedon Aug 19, 2021
Hello @bbranan. Sorry for the long reply. Does it still reproduce for you ?
bbranan commentedon Aug 19, 2021
Hey @dmitry-shibanov, thanks for following up. I was able to resolve the issue by creating and using a new key. It's still not clear what about the old key kept it from being removed in the action, given that it worked for the code signing step. I would still recommend updating the
catch()in https://github.com/actions/setup-java/blob/main/src/cleanup-java.ts to print the error being caught, as that may provide additional information about the problem when/if this issue comes up for others.bjhargrave commentedon Sep 13, 2021
I also suffer from this problem because my project's GitHub repo has been provisioned with a
GPG_PRIVATE_KEYsecret which only contains a signing subkey without the primary private key. See https://wiki.debian.org/Subkeys especially the section where it discusses removing the primary private key. The issue then is that when the cleanup for thesetup-javaaction goes to delete the key, the--delete-secret-keyscommand fails for the fingerprint of the installedGPG_PRIVATE_KEYas there is no secret key with that fingerprint.Here is some example data showing the issue using a private key I created according to the Debian Subkeys article.
The imported key has the fingerprint
098A3F32AD9899B69806F5B88D6DB9DBDC161CF2.Notice the
sec#in the output which indicates the primary private key is not present.So when cleanup for the
setup-javaaction later attempts to--delete-secret-keys, it fails:Note that
--delete-keysworks fine and all the keys are now deleted.So the cleanup for the action needs to properly handle deleting a
GPG_PRIVATE_KEYwhich only contains a signing subkey without the primary private key. This could be accomplished by ignoring any error from the--delete-secret-keyscommand and proceeding to the--delete-keyscommand.cc: @mbarbero
bjhargrave commentedon Sep 13, 2021
Further reading led me to the option
--delete-secret-and-public-keywhich means both the secret key and public keys can be deleted in a single operation.~ gpg --batch --yes --delete-secret-and-public-key 098A3F32AD9899B69806F5B88D6DB9DBDC161CF2bbranan commentedon Sep 13, 2021
Good catch @bjhargrave! I can confirm that the key I was using initially (that failed) was a subkey. The new key I created (that works) is a primary key. Your explanation makes sense of the failure I was seeing and the reason why the new key would work.
JarvisCraft commentedon Sep 18, 2021
Having the same issue here: https://github.com/JarvisCraft/padla/runs/3640842927?check_suite_focus=true
While using the following configuration: https://github.com/JarvisCraft/padla/blob/development/.github/workflows/deploy-snapshot.yml
The suggested PR (#226) seems to be the fix for it.
dmitry-shibanov commentedon Sep 24, 2021
Hello @bbranan @bjhargrave. Thank you for contributions. We appreciate it.
Could you please confirm that everything works as expected for you ? Could you please for testing purpose specify
actions/setup-java@v2->actions/setup-java@main.JarvisCraft commentedon Sep 28, 2021
I can confirm that this fix works:
Successful run with
mainas the versionPrevious broken run with
v2.3.0as the versionNow just waiting for the fix to be released under a tag!
bjhargrave commentedon Sep 28, 2021
I can confirm that it works for me also. https://github.com/eclipse/transformer/actions/runs/1263929181
bbranan commentedon Sep 28, 2021
I'm no longer in a good position to test this as my environment has changed since submitting this ticket, but given the success reported by @bjhargrave and @JarvisCraft I can only conclude that this issue has been resolved by the combination of #220 and #226.
dmitry-shibanov commentedon Sep 29, 2021
Hello everyone. Thank you for all your responses ! We appreciate it. We released new version of the action.
For now I'm closing the issue. If you have any concerns feel free to ping us.
steventamm commentedon Nov 2, 2021
@dmitry-shibanov I'm still getting this error in salesforce/formula-engine, but I just started using it. Is there a way to get a better error message than this.
dmitry-shibanov commentedon Nov 3, 2021
Hello @steventamm. Actually we add error message to the
core.setFailedcommand in this pull request. I think it is full error message you can get in your case.Could please provide public repository to reproduce the issue and investigate it deeper ?
steventamm commentedon Nov 3, 2021
https://github.com/salesforce/formula-engine
dennisvang commentedon Jan 27, 2025
Not directly relevant for this issue, but may help others that end up here:
A similar error occurred in our case with
setup-java@v4:followed by
Here's the problem:
We copied the output of
gpg --armor --export-secret-keys <name>from terminal to password manager, then from password manager to github secrets. This apparently corrupted the value, probably because newlines were replaced by spaces.Copying the exact same output directly from terminal to github secrets fixed the issue.
(Alternatively, replacing the spaces by newlines again also worked.)
vhemery commentedon Mar 11, 2025
Same symptoms may appear when you have a github workflow using different composite actions which access the same gpg key.
Once a post-action removes the private key, the other post-action fails removing it.
The solution in this case is to make sure you use the private key only once, so you try removing only once.
In my own case, this was a custom
maven-settings-actionwhich was accessing the gpg private key from our secrets manager. So I removed it from theactions/setup-java@v4configuration, so only the custom maven-settings-action would use it and configure everything properly. ( https://github.com/bonitasoft/bonita-process-model/pull/74/files )