Control: reassign 846953 gnupg-agent Control: retitle 846953 gnupg-agent cannot deal with extremely large passphrase-encrypted keys Control: forwarded 846953 https://bugs.gnupg.org/gnupg/issue2857
On Mon 2016-12-05 11:24:08 -0500, Daniel Kahn Gillmor wrote:
> on to the rest of it...
>
> do you have
> ~/.gnupg/private-keys-v1.d/DFE35C37A3C37A72BEE31A2E55252BA2A1EB0A2C.key
> ?
>
> is it (in)appropriately large compared to the other, smaller secret key
> material?
>
> (that path is derived from --with-keyrip, fwiw)
>
> can you try turning up the logging for gpg-agent (log-file and
> debug-level in ~/.gnupg/gpg-agent.conf, followed by restarting the
> agent) and see if it reports anything differently?
>
> Also, how did you generate such a large key? gpg usually limits key
> generation to sane lengths.
OK, i'm now able to replicate the problem by making such a large key and
trying to use it with gpg-agent. the key works fine as long as it has
no passphrase attached, but once i add a passphrase and try to use it,
gpg-agent crashes with:
2016-12-05 11:30:11 gpg-agent[24311] Fatal: out of core in secure memory while
allocating 640 bytes
2016-12-05 11:30:11 gpg-agent[24311] socket file has been removed - shutting
down
It'd be better to fail gracefully instead.
I'm attaching an encryption-capable 10240-bit RSA secret key (in OpenPGP
transferable secret key format, with passphrase "abc123") for use by
anyone who wants to test. In a new GNUPGHOME, do:
gpg --batch --yes --import test-hugekey.key
echo test | gpg -r 861A97D02D4EE690A125DCC156CC9789743D4A89 --encrypt
--armor --trust-model=always --batch --yes --output data.gpg
gpg --decrypt data.gpg
you'll note that the agent dies when doing that :/
I'm reassigning and retitling the bug to gnupg-agent, since that seems
to be where the problem lies.
I also noticed that upstream's https://bugs.gnupg.org/gnupg/issue2857 is
quite similar, so i'm marking this as "forwarded" there.
--dkg
test-hugekey.key
Description: application/pgp-keys
signature.asc
Description: PGP signature
