Mailing List Archive

On Freitag, 3. M?rz 2023 13:09:09 CET efeizbudak via Gnupg-users wrote:
> So I'm trying to use gpg-preset-passphrase but for some reason I keep
> having to enter the passphrase all the same. I run
>
> /usr/libexec/gpg-preset-passphrase --preset $KEYGRIP

Works for me (with the current development version). I did the following
(after adding `allow-preset-passphrase` to gpg-agent.conf and restarting
gpg-agent):

$ gpg -K --with-keygrip A151BC5817C228CF
sec ed25519 2021-02-26 [SC]
69C701A436FDD496FAE5580AA151BC5817C228CF
Keygrip = 382BC7C2C4E13EF7D40870B7EB9CDE4AE0232B4E
uid [ultimate] foo@example.net
ssb cv25519 2021-02-26 [E]
Keygrip = B9386D3E742597E532C6BD0978192517A09B41C3

$ echo bla | gpg --armor --encrypt -r A151BC5817C228CF | gpg --decrypt
-> pinentry pops up; I click Cancel
gpg: encrypted with cv25519 key, ID 14AC6E5C812B91E1, created 2021-02-26
"foo@example.net"
gpg: public key decryption failed: Operation cancelled
gpg: decryption failed: Operation cancelled

$ /opt/gnupg/master/libexec/gpg-preset-passphrase --preset \
B9386D3E742597E532C6BD0978192517A09B41C3
test

$ echo bla | gpg --armor --encrypt -r A151BC5817C228CF | gpg --decrypt
-> no pinentry pops up
gpg: encrypted with cv25519 key, ID 14AC6E5C812B91E1, created 2021-02-26
"foo@example.net"
bla

Are you sure that you used the keygrip of the encryption subkey and not its
fingerprint? Does caching work if you enter the passphrase in pinentry? (I'm
asking because I'm wondering whether your max-cache-ttl could be the problem.)

Regards,
Ingo

On 23/03/03 03:09PM, Ingo Kl?cker wrote:
> On Freitag, 3. M?rz 2023 13:09:09 CET efeizbudak via Gnupg-users wrote:
> > So I'm trying to use gpg-preset-passphrase but for some reason I keep
> > having to enter the passphrase all the same. I run
> >
> > /usr/libexec/gpg-preset-passphrase --preset $KEYGRIP
>
> Works for me (with the current development version). I did the following
> (after adding `allow-preset-passphrase` to gpg-agent.conf and restarting
> gpg-agent):
>
> $ gpg -K --with-keygrip A151BC5817C228CF
> sec ed25519 2021-02-26 [SC]
> 69C701A436FDD496FAE5580AA151BC5817C228CF
> Keygrip = 382BC7C2C4E13EF7D40870B7EB9CDE4AE0232B4E
> uid [ultimate] foo@example.net
> ssb cv25519 2021-02-26 [E]
> Keygrip = B9386D3E742597E532C6BD0978192517A09B41C3
>
> $ echo bla | gpg --armor --encrypt -r A151BC5817C228CF | gpg --decrypt
> -> pinentry pops up; I click Cancel
> gpg: encrypted with cv25519 key, ID 14AC6E5C812B91E1, created 2021-02-26
> "foo@example.net"
> gpg: public key decryption failed: Operation cancelled
> gpg: decryption failed: Operation cancelled
>
> $ /opt/gnupg/master/libexec/gpg-preset-passphrase --preset \
> B9386D3E742597E532C6BD0978192517A09B41C3
> test
>
> $ echo bla | gpg --armor --encrypt -r A151BC5817C228CF | gpg --decrypt
> -> no pinentry pops up
> gpg: encrypted with cv25519 key, ID 14AC6E5C812B91E1, created 2021-02-26
> "foo@example.net"
> bla
>
> Are you sure that you used the keygrip of the encryption subkey and not its
> fingerprint? Does caching work if you enter the passphrase in pinentry? (I'm
> asking because I'm wondering whether your max-cache-ttl could be the problem.)
>
> Regards,
> Ingo

After seeing your example, I thought, why don't I test this with a
simpler password and it turns out that the problem was with my very
complicated auto-generated password which I believe have contained some
characters that were "illegal." Everything works fine with the simpler
password. Thank you for spending time on this. Sorry for not noticing it
earlier.

--
All the best,
Efe

The funny quote of this email is trivial and left as an exercise.