GnuPG race causes misordered uids?
dshaw at jabberwocky.com
Sat May 10 06:12:01 CEST 2003
-----BEGIN PGP SIGNED MESSAGE-----
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
I don't know :(
I tried tens of thousands of --list-keys cycles and still couldn't
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the Gnupg-devel