[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sks-devel] v3 keys w/(v4) subkeys still afflicting SKS
From: |
Yaron Minsky |
Subject: |
Re: [Sks-devel] v3 keys w/(v4) subkeys still afflicting SKS |
Date: |
Fri, 18 Jun 2004 10:10:46 -0400 |
My memory is a bit hazy on this, but as I recall, this can be a
problem for you even if you are running a very recent version of SKS.
I think that what happens is that your database could have been messed
up by some bug in the distant past, and upgrading to a new version of
SKS doesn't actually fix the database. I do believe that "sks drop"
will do the job, as Jason says.
One thing that might be useful would be for someone to do a survery of
which machines actually have these keys, at which point we could bug
the guys who have those keys in their machines to drop them out.
y
On Fri, 18 Jun 2004 10:01:29 -0400, Jason Harris <address@hidden> wrote:
>
>
> (Yes, I am running a _test_ SKS server.)
>
> Again, v3 keys with (v4) subkeys seem to be handled differently by
> different (versions of(?)) SKS servers. The 19 such keys that had
> infiltrated the SKS network at last count never seem to have left:
>
> Date: Mon, 22 Mar 2004 19:40:33 +0100
> From: Peter Palfrader <peter palfrader org>
> To: SKS list <sks-devel nongnu org>
> Message-ID: <address@hidden>
> Subject: [Sks-devel] keyserver.noreply.org always 19 keys short.
>
> When reconciling databases between servers with different populations/
> versions of these keys, these differences perpetually show up in the
> diff-<IP address>.txt files and the logfiles, skew the number of keys
> that are actually reconcilable and reconciled, and generally just bloat
> the logfiles. Until all SKS servers (are upgraded(?) and) treat such
> keys in a consistent way, I think the best solution is for every SKS
> admin to "sks drop <hash>" each of these hashes:
>
> 08AA24E2F387480CB210BDCB873941FB \
> 13E37C592A17EA2A345ED114BEA5D281 \
> 14D0F46517A209FB45E99D561CF4416C \
> 21CD2A0C412A5E822E9B0CC429B4D5BB \
> 30F5C7DD658BD5168D1DF47B3FA25764 \
> 414C5C056C71CACAAF30B2778BDCA966 \
> 64959A13B6CC708AF132EDEE1EC52BA6 \
> 6BAE0BF0C03265DC2903AA63DD0B38EC \
> 8644C5708FCCBAC8557D377B69A4D00D \
> 8CB12BFECF3A176C187C0313114766E7 \
> 8FA7BECE01316DAD8F8A304053D11279 \
> A9FF155F4570A9DD0929A1B454B0A91A \
> ABBE3124E9FC4C03E806BDE571A65835 \
> BF291C42AE681A88EDC2EDAB06A0A3B9 \
> CAE7CBB890F2941B2397DA2838D6C559 \
> D2D924E26902BC4F25DCA201357D49F3 \
> DD220AFE54B50E4B72D3A32CEC9E8E84 \
> E6EDE5ED1B30E10092A140AEDBA89AC2 \
> F77745FECCE6A3C8D0CB717504A7761F
>
> and any more that show up.
>
> These v3 keys should be available without their (v4) subkeys on servers
> that only ever ran newer SKS software, IINM, and even seem to be available,
> when searched for by keyid, both with and without subkeys on some servers.
> Therefore, they should quickly show up sans subkeys on a server once their
> subkey-laden versions are dropped.
>
> To check to see if a server carries the subkey and/or non-subkey version
> of each key, use the keyids GPG reports when all 19 keys are fetched by
> hash from a fully-affected server:
>
> pub 1024R/E195D461 1996-01-07 [revoked]
> Key fingerprint = 24 3A 58 C4 67 B8 C7 7C D6 9D 76 36 39 51 9F 74
> sub 2048g/6E849BB2 1998-02-19
> pub 1024R/07E5F045 1998-08-24 Cyril Bellot <>
> Key fingerprint = CD 29 4A 75 E4 5C C0 27 F6 DA 61 75 A5 21 2F 3D
> sub 1024D/214710DB 2002-11-21
> pub 1024R/71FEFFE9 1997-09-08 Volker Mueller <>
> Key fingerprint = D6 BA D0 D4 88 DA 1C 7D 04 13 2E D7 98 4D 16 2A
> sub 1024D/69763503 2003-03-15
> sub 2048g/3736AE3F 2003-03-15
> pub 1024R/81DFF155 1997-12-01 Ewald H. Beekman <>
> Key fingerprint = 00 21 E4 70 2F 14 C9 A0 85 1B AE A2 4E A2 A7 93
> sub 1024D/05816A41 2000-05-30
> pub 1024R/73B84281 1996-06-03 FUKUSHIMA Osamu <>
> Key fingerprint = C0 84 20 0E 04 09 41 85 D3 4E BC 8E 15 43 8E 98
> sub 1024D/BF4FC31F 2002-12-22
> sub 1024g/53207AE2 2002-12-22
> pub 1024R/F7440E3D 1999-02-25 Torsten Werner <>
> Key fingerprint = 01 80 9C 2A 00 DD E7 1A 5A 9F 69 23 7A 9C BC 34
> sub 1024G/942CA6F2 2000-02-06
> sub 1024D/001C7430 2000-05-30
> sub 1024g/8BF44EF7 2000-05-30
> pub 1024R/CB4483E5 1997-12-27 Oezguer Kesim <>
> Key fingerprint = 9A 71 05 2F 06 21 A5 E6 6E 43 9A 17 1C 77 0D C1
> sub 1024D/3AA9F4A7 2001-06-04
> pub 1024R/ED9D77D5 1997-12-08 Barry A. Warsaw <>
> Key fingerprint = D3 34 F2 5F D7 14 E0 90 62 03 EF 2D 7E 4A A5 98
> sub 1024D/BB3C3203 2000-07-07
> sub 1024g/4CC9779E 2000-07-07
> sub 1024g/8DF91D04 2000-11-29
> pub 1024R/C149DC41 1996-07-24 Sven Rudolph <>
> Key fingerprint = 81 CF 4C 5E 6A 0D CA FA EA D9 D2 0A 07 E4 77 6F
> sub 1024D/515D0CA2 2002-09-17
> pub 8192R/0612475F 2001-05-03 Anders Nor Berle <>
> Key fingerprint = BD 09 E1 56 87 EA D3 AC 61 81 5C F7 51 14 A0 9D
> sub 1024g/FC0947DA 2001-05-04
> pub 768R/A4661171 1996-07-25 Hilmar Preusse <>
> Key fingerprint = 2B FB 5C 0D 62 16 21 13 4E FF E7 BE 5A D4 19 14
> sub 1024G/4443BCF3 2000-06-10
> pub 768R/6C740201 1997-05-06 Jean-Pierre Morant <>
> Key fingerprint = B2 E4 89 B2 6C E0 96 B5 BF E7 21 C9 4F C7 50 1C
> sub 2048g/6FC52472 1998-09-10
> pub 1024R/C9B74359 1998-11-25 Michal Jezek, HKP <>
> Key fingerprint = 7A 6A AB 55 9C 2E 33 96 40 BA 8B BC 6C 66 FE FF
> sub 4096G/48241798 2000-11-16
> pub 2048R/450BB175 2001-05-26 test <>
> Key fingerprint = 68 E3 B2 73 D1 66 FF 15 09 9E 2E 42 4F 38 D8 04
> sub 2048g/061713E3 2001-05-26
> pub 1024R/AD29B051 1994-10-29 Ira Abramov <>
> Key fingerprint = 8C A2 1F A5 BC 29 E1 63 6C B0 61 0E 55 AF 00 99
> sub 3072g/177B9FE9 2002-01-01
> pub 1024R/562C07B1 1995-09-18 Keith E. O'Hara <>
> Key fingerprint = 7C FC 18 A9 B0 DA E6 85 FE A5 BF DE 5A E7 4B 94
> sub 1024D/5E26E37F 2002-03-11
> sub 1024g/E4CFBF7C 2002-03-11
> pub 1024R/A662F029 1998-10-18 Weisshuhn & Weisshuhn DNS Administration
> (Hostmaster) <>
> Key fingerprint = ED 0F AE 5A 35 0E 45 8D 7A FB 4C 21 C4 1C 55 FD
> sub 1024G/3AC1D4D4 2000-04-04
> pub 1024R/8BC99881 2000-07-17 Cyrille Lefevre <>
> Key fingerprint = 78 6A 5F A6 33 18 F6 80 F1 F4 23 C4 D5 1C 17 AB
> sub 1024D/9ACCB926 2001-03-25
> sub 1024g/C5FF9425 2001-03-25
> sub 1024G/3B86B0B1 2001-03-25
> pub 1024R/7BC93C61 2000-03-10 Andreas Ferber <>
> Key fingerprint = 54 97 38 E2 53 DF 66 BA CC E1 17 CA 18 55 C8 E0
> sub 1024D/CFC240FF 2000-07-04
> sub 1024g/D1C63397 2000-07-04
>
> --
> Jason Harris | NIC: JH329, PGP: This _is_ PGP-signed, isn't it?
> address@hidden _|_ web: http://keyserver.kjsl.com/~jharris/
> Got photons? (TM), (C) 2004
>
>
>
> noname - 1K
> noname - 1K Download
>
- [Sks-devel] v3 keys w/(v4) subkeys still afflicting SKS, Jason Harris, 2004/06/18
- Re: [Sks-devel] v3 keys w/(v4) subkeys still afflicting SKS,
Yaron Minsky <=
- Re: [Sks-devel] v3 keys w/(v4) subkeys still afflicting SKS, Peter Palfrader, 2004/06/18
- Re: [Sks-devel] v3 keys w/(v4) subkeys still afflicting SKS, Peter Palfrader, 2004/06/18
- Re: [Sks-devel] v3 keys w/(v4) subkeys still afflicting SKS, Daniel Johnson, 2004/06/18
- Re: [Sks-devel] v3 keys w/(v4) subkeys still afflicting SKS, Chris Kuethe, 2004/06/18
- Re: [Sks-devel] v3 keys w/(v4) subkeys still afflicting SKS, Daniel Johnson, 2004/06/19
- Re: [Sks-devel] v3 keys w/(v4) subkeys still afflicting SKS, Yaron Minsky, 2004/06/19
- Re: [Sks-devel] v3 keys w/(v4) subkeys still afflicting SKS, Yaron Minsky, 2004/06/19
- Re: [Sks-devel] v3 keys w/(v4) subkeys still afflicting SKS, Daniel Johnson, 2004/06/19
- Re: [Sks-devel] v3 keys w/(v4) subkeys still afflicting SKS, Thomas Sjögren, 2004/06/19
- Re: [Sks-devel] v3 keys w/(v4) subkeys still afflicting SKS, Chris Kuethe, 2004/06/19