gpg-preset-passphrase installation and usage

[Peter Lebbing]

Hello!

On 13/04/2019 12:42, Walia, Gaurav (333G) via Gnupg-users wrote:
>   * gpg --version
>       o gpg (GnuPG) 2.0.22

This version is a full six years old. Not only is 2.0.22 unsupported,
the whole 2.0 branch has been end-of-life for a good bit more than a
year now.

How come you're using something ancient that upstream doesn't support
and which has known defects? Is this a distribution-supported version?
If there is no security support from any party, I think you should
switch to a supported version.

>   * Setup gpg-preset-passphrase
>       o gpg-preset-passphrase --preset 8910891089108910891089108910891089108910
>   * Now when you login to that key and enter the passphrase It should cache it until you issue the following command to remove it.
>       o gpg-preset-passphrase —forget 8910891089108910891089108910891089108910

No, that's not how gpg-preset-passphrase works. You supply the
passphrase on the invocation of gpg-preset-passphrase. And you use the
keygrip, not the fingerprint. You can find the keygrip with the
--with-keygrip option when listing the key.

You would supply the passphrase on stdin of gpg-preset-passphrase,
probably from some utility that got it from the operator. Or with the -P
command line option directly, but this makes it visible for any user on
the system through the process list.

There is no feedback if either keygrip or passphrase is wrong. The net
result is simply you'll get a pinentry pop up when you try to use the
key.

And it will only cache it up to max-cache-ttl as mentioned in the man
page for gpg-preset-passphrase, so you probably want to not remove that
option from gpg-agent.conf.

Alternatively, you could just set default-cache-ttl to whatever value
you desire and completely forego gpg-preset-passphrase. Because it
sounds like you are okay with just supplying the passphrase on the first
invocation, it seems?

gpgconf tells us that the data type of the TTL options is uint32, so you
can make a TTL of 136 years. I notice you use a NASA e-mail address.
This TTL might be a problem on an unmanned spacecraft, but somehow I'll
expect your use case is covered ;-). (Plus, max-cache-ttl always limits
it to the 136 years anyway)

If you did not use gpg-preset-passphrase to preset the passphrase, you
can't use gpg-preset-passphrase --forget to clear it again. Either
reload the agent (this will make it forget all passphrases), or issue:

$ gpg-connect-agent 'clear_passphrase --mode=normal KEYGRIP' /bye

I'm not sure whether that last method is future-proof or might change in
some new version. In other words, I don't know if it's part of the API
or an implementation detail.

I did these things on the distribution-provided GnuPG on Debian
stretch/stable. So it's possible that it works differently on different
versions.

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190413/6f7b8228/attachment.sig>