Page MenuHome GnuPG
Create Task
Maniphest T994

Batch mode doesn't select subkeys properly in some cases
Closed, ResolvedPublic
Actions

Description

I have a key with several expired subkeys and two valid ones - one for signing
and one for encryption. When I try to encrypt to that user, it works *unless* I
use batch mode. There is only one valid encryption subkey, so gnupg should have
no problem selecting the subkey to use:

pub  2048R/553C5D65  created: 2006-03-17  expires: never       usage: SC  
                     trust: unknown       validity: unknown
sub  1600R/DDA71F97  created: 2006-03-17  expired: 2008-03-16  usage: S   
sub  2048g/BB63B574  created: 2006-03-17  expired: 2007-03-17  usage: E   
sub  2048g/A01686AC  created: 2007-03-09  expired: 2008-03-08  usage: E   
sub  2048g/65DCC6A8  created: 2008-03-08  expires: 2010-03-08  usage: E   
sub  1600R/24938ED4  created: 2008-03-08  expires: 2010-03-08  usage: S

This works:

gpg -e -r 553C5D65 /tmp/test

But this doesn't:

gpg --batch --yes -e -r 553C5D65 /tmp/test

and fails with:

gpg: /tmp/test: encryption failed: unusable public key

Clearly the encryption key is not unusable, so this appears to be a bug.

The users' pubkey is attached.

Event Timeline

jaymzh added projects: gnupg, Bug Report.Feb 2 2009, 8:59 PM
jaymzh added a subscriber: jaymzh.

203_pubkey.asc22 KBDownload

jaymzh added a comment.Feb 2 2009, 11:58 PM

It's worth noting that --always-trust enables this to work... however,
--always-trust isn't required on other keys that don't seem to be built like this.

So perhaps that this doesn't work isn't a bug and that others work is the actual
bug?

I'm fine either way - but the behavior should be consistent.

jaymzh closed this task as Resolved.Feb 3 2009, 12:34 AM
jaymzh claimed this task.

::sigh:: OK, this was my software that's wrapping gpg. It was getting several
[GNUPG:] KEYEXPIRED responses and reporting the error before noticing that the
encryption actually succeeded. On other keys this wasn't a problem... but in
this cause the behavior is consistent (--always-trust was in fact on).

Sorry for the noise, I'm closing the bug.