GnuPG race causes misordered uids?

David Shaw dshaw at
Mon May 5 20:27:01 CEST 2003

Hash: SHA1

On Mon, May 05, 2003 at 06:16:52PM +0200, Marcus Brinkmann wrote:
> On Mon, May 05, 2003 at 09:50:23AM -0400, David Shaw wrote:
> > Just to make sure I understand the problem.  Given a key with more
> > than one uid, one of which is marked primary, if I do this:
> > 
> > gpg --fixed-list-mode --with-fingerprint --with-colons --list-keys (thekey)
> > 
> > over and over, sometimes the primary key is not first?
> I wish I could say that.  I did only see it in GPGME, not from the command
> line, although GPGME calls something like the above (it has
> --with-fingerprint twice, and uses a status fd of course).
> > Is the primary uid marked primary (i.e. a primary subpacket is in the
> > self-sig), or is the primary just the newest uid ?
> I don't know how to find that out.

Can you point me towards the sample file that showed the problem?

> I have an idea.  If it is the newest uid listed first, then can it be that
> it compares the time against the current time, and when it crosses a second
> then the second comparison is one second less than the first one (and if
> both are created at the same time, then the second is now earlier than the
> first)?  I should look in the code, but that is about the only type of race
> I can imagine being in effect here.

Hmm.  The function that sorts uids doesn't actually get the system
time - it just uses the timestamps inside the self-sigs.  It's
possible that you could get a given uid first, then after a while a
different uid first (say, if the first uid expired or something), but
if you get them to alternate, that's something strange.

Version: GnuPG v1.3.2-cvs (GNU/Linux)


More information about the Gnupg-devel mailing list