sks-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Sks-devel] Re: Broken reconciliation


From: Yaron M. Minsky
Subject: [Sks-devel] Re: Broken reconciliation
Date: Sun, 11 Apr 2004 00:19:06 -0400

Alright.  Here's the deal, as far as I can tell.  It looks like the key
in question does not conform to the PGP standard.  In particular, it is
a V3 key, and yet it has subkeys.  That's not actually allowed, and SKS
knows it and rejects it accordingly.

And yet, somehow, one of the keyservers has already accepted this key. 
Maybe the test wasn't implemented right in some previous version. 
Anyway, that's why there is a persistent difference between the
keyservers.  One system tries to add the key, but the add fails.  

There are two possible solutions:

1) rely on the database cleaner ("sks cleandb").  I need to look to see
whether it would fix it as it stands, or whether a modification to that
would be needed.  Thus, the offending key would be thrown out on any
keyserver that ran the cleaner.  The keyservers with good versions of
the key would end up distributing those, and all would be well.

2) Make the SKS key parsing rules more lenient, allowing V3 keys to have
subkeys, like V4 keys.

Any thoughts on which of these options is preferable?

y

On Fri, 2004-03-26 at 06:40, Peter Palfrader wrote:
> On Thu, 25 Mar 2004, Yaron M. Minsky wrote:
> 
> > I haven't been following the discussion about the broken keys as closely
> > as I should have, but I'll try to make up for it now.  Let me tell you
> > what I have gathered and what thoughts I have about it.
> 
> > Do you have any insights?  Maybe you could email me the list of missing
> > hashes, and I can try to look into the question of where the differences
> > came from.
> 
> It seems to have to do mostly with v3 keys with subkeys.
> 
> On keyserver.noreply.org I have the following hash in diff-<ks-old>:
> F77745FECCE6A3C8D0CB717504A7761F
> 
> When you look at ks-old, you will find a v3 key with subkeys:
> http://keyserver-old.noreply.org:11371/pks/lookup?op=hget&search=F77745FECCE6A3C8D0CB717504A7761F
> 
> Pasting that output into gpg, gives:
> pub  1024R/7BC93C61 2000-03-10 Andreas Ferber <address@hidden>
> sub  1024D/CFC240FF 2000-07-04 
> sub  1024g/D1C63397 2000-07-04 
> 
> Now if you search for the keyid on the servers, both keyserver and
> ks-old will tell you they only have 0x7BC93C61, but without any subkeys,
> and claim its hash is: FA10EE7EF298F6EDE3E58C963D479F92
> 
> Both servers have the same key under FA10EE7EF298F6EDE3E58C963D479F92.
> 
> F77745FECCE6A3C8D0CB717504A7761F does not only appear on ks-old, it also
> appears on pyxis.cns.ualberta.ca, and the second instance of SKS on
> keyserver.noreply.org.
> 
> 
> 
> 
> 
> Another example is 21CD2A0C412A5E822E9B0CC429B4D5BB.  It appears on
> pyxis.cns.ualberta.ca, pgp.hpc.unm.edu, the other sks on
> keyserver.noreply.org (available at :21371 btw), ks-old, and 5 more
> keyservers.
> 
> Pasting the output of
> http://keyserver-old.noreply.org:11371/pks/lookup?op=hget&search=21CD2A0C412A5E822E9B0CC429B4D5BB
> into gpg yields:
> pub  1024R/81DFF155 1997-12-01 Ewald Beekman <address@hidden>
> uid                            Ewald H. Beekman <address@hidden>
> uid                            Ewald Beekman <address@hidden>
> sub  1024D/05816A41 2000-05-30
> 
> 
> http://keyserver.noreply.org:11371/pks/lookup?search=E.H.Beekman%40amc.uva.nl&fingerprint=on&hash=on&op=index
> http://keyserver.noreply.org:11371/pks/lookup?search=0x81DFF155&fingerprint=on&hash=on&op=index
> both give a 'key not found'
> 
> http://pgp.hpc.unm.edu:11371/pks/lookup?search=E.H.Beekman%40amc.uva.nl&fingerprint=on&hash=on&op=index
> http://keyserver-old.noreply.org:11371/pks/lookup?search=0x81DFF155&fingerprint=on&hash=on&op=index
> both give an empty reply, only showing the column heads, nothing else:
> | $ lynx -dump 
> 'http://keyserver-old.noreply.org:11371/pks/lookup?search=0x81DFF155&fingerprint=on&hash=on&op=index'
> | 
> |                         Search results for '0x81dff155'
> | 
> | Type bits/keyID    Date       User ID
> | $ 
> 
> 
> So v3 keys with subkeys appear to be in the recon database, but cannot
> be synced via gossip.  I think they might come from merges, (fast)build.
> 
> 
> Peter
-- 
|--------/            Yaron M. Minsky              \--------|
|--------\ http://www.cs.cornell.edu/home/yminsky/ /--------|

Open PGP --- KeyID B1FFD916
Fingerprint: 5BF6 83E1 0CE3 1043 95D8 F8D5 9F12 B3A9 B1FF D916






reply via email to

[Prev in Thread] Current Thread [Next in Thread]