When using the Passbolt CLI, I try to authenticate with passbolt auth login -p mypassword, and am then presented with a dialog to input my password:
┌────────────────────────────────────────────────────────────────┐
│ Please enter the passphrase to unlock the OpenPGP secret key: │
│ “Me my@email.com” │
│ 2048-bit RSA key, ID 12345, │
│ created 2019-09-25 (main key ID 12345). │
│ │
│ │
│ Passphrase: __________________________________________________ │
│ │
│ │
└────────────────────────────────────────────────────────────────┘
If I cancel out of that, I am not authenticated. This is a problem for using Passbolt as part of a Jenkins pipeline. I’m not sure what to do to troubleshoot this, short of dissecting the source code to see what’s going on.
This is dialog presented by Gnupg pinentry that is available by default with gnupg v2.
To “solve the problem”, you need to enable loopback pinentry mode. Add this to ~/.gnupg/gpg.conf:
use-agent
pinentry-mode loopback
And add this to ~/.gnupg/gpg-agent.conf, creating the file if it doesn’t already exist:
allow-loopback-pinentry
Then restart the agent with:
echo RELOADAGENT | gpg-connect-agent
and you should be good to go!
I’m writing “to solve the problem” in quotes, because this approach has some security implications, which creates other problem, since the passphrase becomes obviously readable in your user context.
In practice you would manually input the passphase when starting up/rebooting the service, by running a passbolt auth for example, so that it get cached and is not available in clear in further use.
Thank you @remy ! This worked beautifully. It’s for use in a transient Docker container in a Jenkins pipeline, where the password will be retrieved from the Jenkins credentials store. I’m not too concerned about the security implications you mentioned for this particular use case, but thanks for pointing it out.