GnuPG race causes misordered uids?

David Shaw dshaw at
Sat May 10 06:12:01 CEST 2003

Hash: SHA1

On Tue, May 06, 2003 at 02:04:57PM +0200, Marcus Brinkmann wrote:
> On Mon, May 05, 2003 at 11:23:08PM -0400, David Shaw wrote:
> > Okay, I looked at this and what seems to be the problem is that some
> > of the user IDs were generated in the same second.  That foils the
> > current user ID sorting algorithm.
> But why are the results non-deterministic on a sequence of read-only
> operations?

I don't know :(

I tried tens of thousands of --list-keys cycles and still couldn't
duplicate it.

Could it somehow be a weird buffering thing between gpg and gpgme?

> > That may explain the problem you saw, but I think this isn't good
> > behavior in general for GnuPG.  If the "first uid is primary" behavior
> > is going to be depended on by other programs, then we must guarantee
> > that this is always true.  It doesn't really matter what is used as
> > the secondary sorting key, so long as it is reliable.  I'm tempted to
> > use the raw signature packet data - it's easily accessible, and is
> > absurdly unlikely to collide.
> The one-second resolution is a common problem in timestamping.
> I don't really care what the end result will be, as long as the users are
> happy and the output is deterministic :)

It is deterministic, though I can't imagine how often this is going to
be needed.  It covers either (multiple uids all created within the
same second, and all either with the primary flag, or all without it),
or (multiple uids, none of which are self signed).

Neither case is particularly common.

Version: GnuPG v1.2.2 (GNU/Linux)


More information about the Gnupg-devel mailing list