Permanent diff with pgp.srv.ualberta.ca

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

Permanent diff with pgp.srv.ualberta.ca

Marco Nenciarini

Watching my sks.recon.log i see many lines linke the following:

2005-08-21 07:40:18 Recon partner: <ADDR_INET 129.128.98.22:11370>
2005-08-21 07:40:18 Initiating reconciliation
2005-08-21 07:40:19 Reconciliation complete
2005-08-21 07:40:19 19 hashes recovered from <ADDR_INET 129.128.98.22:11371>
2005-08-21 07:40:20 Requesting 19 missing keys from <ADDR_INET 129.128.98.22:11371>, starting with 08AA24E2F387480CB210BDCB873941FB
2005-08-21 07:40:22 19 keys received

repeated many and many times.

The canonical name of 129.128.98.22 is pgp.srv.ualberta.ca (the
administrator is in CC).

The content of diff-129.128.98.22_11371.txt is unchanged for about a
week and is:

08AA24E2F387480CB210BDCB873941FB
13E37C592A17EA2A345ED114BEA5D281
14D0F46517A209FB45E99D561CF4416C
21CD2A0C412A5E822E9B0CC429B4D5BB
30F5C7DD658BD5168D1DF47B3FA25764
414C5C056C71CACAAF30B2778BDCA966
64959A13B6CC708AF132EDEE1EC52BA6
6BAE0BF0C03265DC2903AA63DD0B38EC
8644C5708FCCBAC8557D377B69A4D00D
8CB12BFECF3A176C187C0313114766E7
8FA7BECE01316DAD8F8A304053D11279
A9FF155F4570A9DD0929A1B454B0A91A
ABBE3124E9FC4C03E806BDE571A65835
BF291C42AE681A88EDC2EDAB06A0A3B9
CAE7CBB890F2941B2397DA2838D6C559
D2D924E26902BC4F25DCA201357D49F3
DD220AFE54B50E4B72D3A32CEC9E8E84
E6EDE5ED1B30E10092A140AEDBA89AC2
F77745FECCE6A3C8D0CB717504A7761F

Any idea on how to handle this problem?

Bye

--
---------------------------------------------------------------------
|    Marco Nenciarini    | Debian/GNU Linux Developer - Plug Member |
| [hidden email] | http://www.prato.linux.it/~mnencia       |
---------------------------------------------------------------------
Key fingerprint = FED9 69C7 9E67 21F5 7D95  5270 6864 730D F095 E5E4


_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Permanent diff with pgp.srv.ualberta.ca

Chris Kuethe-2
Not sure what's going on there...

Last reconciliation run was less than 10 minutes ago, and my keyserver
thinks it has all the keys that you have.

# ls -l diff-62.94.26.10_11371.txt
-rw-r--r--  1 sks  sks  0 Aug 21 09:08 diff-62.94.26.10_11371.txt

What if you remove the diff file? Does sks show the same keys after the
next reconciliation attempt?

CK

On Sun, 21 Aug 2005, Marco Nenciarini wrote:

>
> Watching my sks.recon.log i see many lines linke the following:
>
> 2005-08-21 07:40:18 Recon partner: <ADDR_INET 129.128.98.22:11370>
> 2005-08-21 07:40:18 Initiating reconciliation
> 2005-08-21 07:40:19 Reconciliation complete
> 2005-08-21 07:40:19 19 hashes recovered from <ADDR_INET 129.128.98.22:11371>
> 2005-08-21 07:40:20 Requesting 19 missing keys from <ADDR_INET 129.128.98.22:11371>, starting with 08AA24E2F387480CB210BDCB873941FB
> 2005-08-21 07:40:22 19 keys received
>
> repeated many and many times.
>
> The canonical name of 129.128.98.22 is pgp.srv.ualberta.ca (the
> administrator is in CC).
>
> The content of diff-129.128.98.22_11371.txt is unchanged for about a
> week and is:
>
> 08AA24E2F387480CB210BDCB873941FB
> 13E37C592A17EA2A345ED114BEA5D281
> 14D0F46517A209FB45E99D561CF4416C
> 21CD2A0C412A5E822E9B0CC429B4D5BB
> 30F5C7DD658BD5168D1DF47B3FA25764
> 414C5C056C71CACAAF30B2778BDCA966
> 64959A13B6CC708AF132EDEE1EC52BA6
> 6BAE0BF0C03265DC2903AA63DD0B38EC
> 8644C5708FCCBAC8557D377B69A4D00D
> 8CB12BFECF3A176C187C0313114766E7
> 8FA7BECE01316DAD8F8A304053D11279
> A9FF155F4570A9DD0929A1B454B0A91A
> ABBE3124E9FC4C03E806BDE571A65835
> BF291C42AE681A88EDC2EDAB06A0A3B9
> CAE7CBB890F2941B2397DA2838D6C559
> D2D924E26902BC4F25DCA201357D49F3
> DD220AFE54B50E4B72D3A32CEC9E8E84
> E6EDE5ED1B30E10092A140AEDBA89AC2
> F77745FECCE6A3C8D0CB717504A7761F
>
> Any idea on how to handle this problem?
>
> Bye
>
> --
> ---------------------------------------------------------------------
> |    Marco Nenciarini    | Debian/GNU Linux Developer - Plug Member |
> | [hidden email] | http://www.prato.linux.it/~mnencia       |
> ---------------------------------------------------------------------
> Key fingerprint = FED9 69C7 9E67 21F5 7D95  5270 6864 730D F095 E5E4
>
>

--
Chris Kuethe, GCIA: Secure Systems Specialist - U of A CNS
       office: 157 General Services Bldg.    +1.780.492.8135
               chris.kuethe@[pyxis.cns.]ualberta.ca

      GDB has a 'break' feature; why doesn't it have 'fix' too?



_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: Permanent diff with pgp.srv.ualberta.ca

Yaron Minsky
In reply to this post by Marco Nenciarini
If you want to debug this, try fetching the missing keys from the other server, and then try submitting them directly and see what happens. The SKS hash is enough to request the key, so that should give you a pretty good idea of what is going on.

Yaron

On 8/21/05, Marco Nenciarini <[hidden email]> wrote:

Watching my sks.recon.log i see many lines linke the following:

2005-08-21 07:40:18 Recon partner: <ADDR_INET 129.128.98.22:11370>
2005-08-21 07:40:18 Initiating reconciliation
2005-08-21 07:40:19 Reconciliation complete
2005-08-21 07:40:19 19 hashes recovered from <ADDR_INET 129.128.98.22:11371>
2005-08-21 07:40:20 Requesting 19 missing keys from <ADDR_INET 129.128.98.22:11371>, starting with 08AA24E2F387480CB210BDCB873941FB
2005-08-21 07:40:22 19 keys received

repeated many and many times.

The canonical name of 129.128.98.22 is pgp.srv.ualberta.ca (the
administrator is in CC).

The content of diff-129.128.98.22_11371.txt is unchanged for about a
week and is:

08AA24E2F387480CB210BDCB873941FB
13E37C592A17EA2A345ED114BEA5D281
14D0F46517A209FB45E99D561CF4416C
21CD2A0C412A5E822E9B0CC429B4D5BB
30F5C7DD658BD5168D1DF47B3FA25764
414C5C056C71CACAAF30B2778BDCA966
64959A13B6CC708AF132EDEE1EC52BA6
6BAE0BF0C03265DC2903AA63DD0B38EC
8644C5708FCCBAC8557D377B69A4D00D
8CB12BFECF3A176C187C0313114766E7
8FA7BECE01316DAD8F8A304053D11279
A9FF155F4570A9DD0929A1B454B0A91A
ABBE3124E9FC4C03E806BDE571A65835
BF291C42AE681A88EDC2EDAB06A0A3B9
CAE7CBB890F2941B2397DA2838D6C559
D2D924E26902BC4F25DCA201357D49F3
DD220AFE54B50E4B72D3A32CEC9E8E84
E6EDE5ED1B30E10092A140AEDBA89AC2
F77745FECCE6A3C8D0CB717504A7761F

Any idea on how to handle this problem?

Bye

--
---------------------------------------------------------------------
|    Marco Nenciarini    | Debian/GNU Linux Developer - Plug Member |
| [hidden email] | http://www.prato.linux.it/~mnencia        |
---------------------------------------------------------------------
Key fingerprint = FED9 69C7 9E67 21F5 7D95  5270 6864 730D F095 E5E4



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDCIG/aGRzDfCV5eQRArjGAJ9E6TuuRcogwIgb3GXbODU3jOYhtQCfS9Ul
uGVM8qHv5GKGy36AcpuFRcU=
=/35W
-----END PGP SIGNATURE-----


_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel




_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: Re: Permanent diff with pgp.srv.ualberta.ca

Jason Harris
In reply to this post by Chris Kuethe-2
On Sun, Aug 21, 2005 at 09:32:24AM -0600, Chris Kuethe wrote:

> Not sure what's going on there...
>
> Last reconciliation run was less than 10 minutes ago, and my keyserver
> thinks it has all the keys that you have.
>
> # ls -l diff-62.94.26.10_11371.txt
> -rw-r--r--  1 sks  sks  0 Aug 21 09:08 diff-62.94.26.10_11371.txt
>
> What if you remove the diff file? Does sks show the same keys after the
> next reconciliation attempt?
We've had this happen several times before.  Check the archives and
you should learn that you need to force a "sks cleandb" on your end,
Chris.

--
Jason Harris           |  NIC:  JH329, PGP:  This _is_ PGP-signed, isn't it?
[hidden email] _|_ web:  http://keyserver.kjsl.com/~jharris/
          Got photons?   (TM), (C) 2004

_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel

attachment0 (322 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Re: Permanent diff with pgp.srv.ualberta.ca

Chris Kuethe-2
On Sun, 21 Aug 2005, Jason Harris wrote:

> On Sun, Aug 21, 2005 at 09:32:24AM -0600, Chris Kuethe wrote:
>
>> Not sure what's going on there...
>>
>> Last reconciliation run was less than 10 minutes ago, and my keyserver
>> thinks it has all the keys that you have.
>>
>> # ls -l diff-62.94.26.10_11371.txt
>> -rw-r--r--  1 sks  sks  0 Aug 21 09:08 diff-62.94.26.10_11371.txt
>>
>> What if you remove the diff file? Does sks show the same keys after the
>> next reconciliation attempt?
>
> We've had this happen several times before.  Check the archives and
> you should learn that you need to force a "sks cleandb" on your end,
> Chris.

Okie dokie. I just ran cleandb, though I ran it immediately after loading
my keys but before bringing the keyserver up.

CK

--
Chris Kuethe, GCIA: Secure Systems Specialist - U of A CNS
       office: 157 General Services Bldg.    +1.780.492.8135
               chris.kuethe@[pyxis.cns.]ualberta.ca

      GDB has a 'break' feature; why doesn't it have 'fix' too?



_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: Re: Permanent diff with pgp.srv.ualberta.ca

Yaron Minsky
You can also use "sks drop" to delete keys that you know are bad.  "sks drop" requires the "sks db" process to be running.

y

On 8/21/05, Chris Kuethe <[hidden email]> wrote:
On Sun, 21 Aug 2005, Jason Harris wrote:

> On Sun, Aug 21, 2005 at 09:32:24AM -0600, Chris Kuethe wrote:
>
>> Not sure what's going on there...
>>
>> Last reconciliation run was less than 10 minutes ago, and my keyserver
>> thinks it has all the keys that you have.
>>
>> # ls -l diff-62.94.26.10_11371.txt
>> -rw-r--r--  1 sks  sks  0 Aug 21 09:08 diff-62.94.26.10_11371.txt
>>
>> What if you remove the diff file? Does sks show the same keys after the
>> next reconciliation attempt?
>
> We've had this happen several times before.  Check the archives and
> you should learn that you need to force a "sks cleandb" on your end,
> Chris.

Okie dokie. I just ran cleandb, though I ran it immediately after loading
my keys but before bringing the keyserver up.

CK

--
Chris Kuethe, GCIA: Secure Systems Specialist - U of A CNS
       office: 157 General Services Bldg.    +1.780.492.8135
               chris.kuethe@[pyxis.cns.]ualberta.ca

      GDB has a 'break' feature; why doesn't it have 'fix' too?



_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel


_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: Re: Permanent diff with pgp.srv.ualberta.ca

Jason Harris
On Sun, Aug 21, 2005 at 09:01:40PM -0400, Yaron Minsky wrote:

> You can also use "sks drop" to delete keys that you know are bad. "sks drop"
> requires the "sks db" process to be running.

Not for unparseable keys, which these were.  Again, check the archives.

--
Jason Harris           |  NIC:  JH329, PGP:  This _is_ PGP-signed, isn't it?
[hidden email] _|_ web:  http://keyserver.kjsl.com/~jharris/
          Got photons?   (TM), (C) 2004

_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel

attachment0 (322 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Permanent diff with pgp.srv.ualberta.ca

Marco Nenciarini
In reply to this post by Yaron Minsky

Acions done:

1) on keyserver.linux.it (my server)
rm -f KDB/meta; sks cleandb; sks pbuild -cache 20 -ptree_cache 70

2) pgp.srv.ualberta.ca (Chris Kuethe's server) was dumped (Aug 22,
around 1900h GMT) and completely reloaded.

but:

$ls -l diff-129.128.98.22_11371.txt
-rw-r--r--  1 debian-sks debian-sks 627 2005-08-26 11:02 diff-129.128.98.22_11371.txt
$cat diff-129.128.98.22_11371.txt
08AA24E2F387480CB210BDCB873941FB
13E37C592A17EA2A345ED114BEA5D281
14D0F46517A209FB45E99D561CF4416C
21CD2A0C412A5E822E9B0CC429B4D5BB
30F5C7DD658BD5168D1DF47B3FA25764
414C5C056C71CACAAF30B2778BDCA966
64959A13B6CC708AF132EDEE1EC52BA6
6BAE0BF0C03265DC2903AA63DD0B38EC
8644C5708FCCBAC8557D377B69A4D00D
8CB12BFECF3A176C187C0313114766E7
8FA7BECE01316DAD8F8A304053D11279
A9FF155F4570A9DD0929A1B454B0A91A
ABBE3124E9FC4C03E806BDE571A65835
BF291C42AE681A88EDC2EDAB06A0A3B9
CAE7CBB890F2941B2397DA2838D6C559
D2D924E26902BC4F25DCA201357D49F3
DD220AFE54B50E4B72D3A32CEC9E8E84
E6EDE5ED1B30E10092A140AEDBA89AC2
F77745FECCE6A3C8D0CB717504A7761F

Tests done:

If I try to get these hashes form any keyserver I obtain
"Error handling request: Requested hash not found" response.

If I try to get these hashes from pgp.srv.ualberta.ca I obtain
"Error handling request. Exception raised: KeyMerge.Unparseable_packet_sequence"

I think we found a bug :(

Ciao

On Sun, Aug 21, 2005 at 01:03:20PM -0400, Yaron Minsky wrote:
> If you want to debug this, try fetching the missing keys from the other
> server, and then try submitting them directly and see what happens. The SKS
> hash is enough to request the key, so that should give you a pretty good
> idea of what is going on.
>
> Yaron
>
> On 8/21/05, Marco Nenciarini <[hidden email]> wrote:
> >
[snip]

> >
> > The content of diff-129.128.98.22_11371.txt is unchanged for about a
> > week and is:
> >
> > 08AA24E2F387480CB210BDCB873941FB
> > 13E37C592A17EA2A345ED114BEA5D281
> > 14D0F46517A209FB45E99D561CF4416C
> > 21CD2A0C412A5E822E9B0CC429B4D5BB
> > 30F5C7DD658BD5168D1DF47B3FA25764
> > 414C5C056C71CACAAF30B2778BDCA966
> > 64959A13B6CC708AF132EDEE1EC52BA6
> > 6BAE0BF0C03265DC2903AA63DD0B38EC
> > 8644C5708FCCBAC8557D377B69A4D00D
> > 8CB12BFECF3A176C187C0313114766E7
> > 8FA7BECE01316DAD8F8A304053D11279
> > A9FF155F4570A9DD0929A1B454B0A91A
> > ABBE3124E9FC4C03E806BDE571A65835
> > BF291C42AE681A88EDC2EDAB06A0A3B9
> > CAE7CBB890F2941B2397DA2838D6C559
> > D2D924E26902BC4F25DCA201357D49F3
> > DD220AFE54B50E4B72D3A32CEC9E8E84
> > E6EDE5ED1B30E10092A140AEDBA89AC2
> > F77745FECCE6A3C8D0CB717504A7761F
> >
> > Any idea on how to handle this problem?
> >
--
---------------------------------------------------------------------
|    Marco Nenciarini    | Debian/GNU Linux Developer - Plug Member |
| [hidden email] | http://www.prato.linux.it/~mnencia       |
---------------------------------------------------------------------
Key fingerprint = FED9 69C7 9E67 21F5 7D95  5270 6864 730D F095 E5E4


_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Permanent diff with pgp.srv.ualberta.ca

Jason Harris
On Fri, Aug 26, 2005 at 11:17:06AM +0200, Marco Nenciarini wrote:
 
> Acions done:
>
> 1) on keyserver.linux.it (my server)
> rm -f KDB/meta; sks cleandb; sks pbuild -cache 20 -ptree_cache 70
>
> 2) pgp.srv.ualberta.ca (Chris Kuethe's server) was dumped (Aug 22,
> around 1900h GMT) and completely reloaded.

#2 is doubtful.  Google for the hosed hashes and you should find all 19
of them in messages _to this list_ titled "keyserver.noreply.org always
19 keys short" and "v3 keys w/(v4) subkeys still afflicting SKS."

Chris needs to shutdown SKS and run:

  %rm -f KDB/meta
  %sks cleandb

on pgp.srv.ualberta.ca, posting clean.log in case the problem persists.

--
Jason Harris           |  NIC:  JH329, PGP:  This _is_ PGP-signed, isn't it?
[hidden email] _|_ web:  http://keyserver.kjsl.com/~jharris/
          Got photons?   (TM), (C) 2004

_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel

attachment0 (322 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Permanent diff with pgp.srv.ualberta.ca

Chris Kuethe-2
In reply to this post by Marco Nenciarini
On Fri, 26 Aug 2005, Marco Nenciarini wrote:

>
> Acions done:
>
> 1) on keyserver.linux.it (my server)
> rm -f KDB/meta; sks cleandb; sks pbuild -cache 20 -ptree_cache 70
>
> 2) pgp.srv.ualberta.ca (Chris Kuethe's server) was dumped (Aug 22,
> around 1900h GMT) and completely reloaded.
>...

And I ran sks cleandb after each keyfile I loaded in. Over 220 cleandb
invokations. There were no errors from merge or build complaining about
unparseable packet sequences.

CK

--
Chris Kuethe, GCIA: Secure Systems Specialist - U of A CNS
       office: 157 General Services Bldg.    +1.780.492.8135
               chris.kuethe@[pyxis.cns.]ualberta.ca

      GDB has a 'break' feature; why doesn't it have 'fix' too?



_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: Permanent diff with pgp.srv.ualberta.ca

Marco Nenciarini
On Fri, Aug 26, 2005 at 07:40:58AM -0600, Chris Kuethe wrote:

> On Fri, 26 Aug 2005, Marco Nenciarini wrote:
>
> >
> >Acions done:
> >
> >1) on keyserver.linux.it (my server)
> >rm -f KDB/meta; sks cleandb; sks pbuild -cache 20 -ptree_cache 70
> >
> >2) pgp.srv.ualberta.ca (Chris Kuethe's server) was dumped (Aug 22,
> >around 1900h GMT) and completely reloaded.
> >...
>
> And I ran sks cleandb after each keyfile I loaded in. Over 220 cleandb
> invokations. There were no errors from merge or build complaining about
> unparseable packet sequences.
>
That's the point!

When you invoke sks cleandb the first time it creates the file
KDB/meta where is written that KDB database is clean. Any subsequent
invocation of sks cleandb return immediately without doing any
work.
Only deleting KDB/meta you can force another cleandb cycle.

Bye

--
---------------------------------------------------------------------
|    Marco Nenciarini    | Debian/GNU Linux Developer - Plug Member |
| [hidden email] | http://www.prato.linux.it/~mnencia       |
---------------------------------------------------------------------
Key fingerprint = FED9 69C7 9E67 21F5 7D95  5270 6864 730D F095 E5E4


_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Permanent diff with pgp.srv.ualberta.ca

Jason Harris
On Fri, Aug 26, 2005 at 04:42:02PM +0200, Marco Nenciarini wrote:
> On Fri, Aug 26, 2005 at 07:40:58AM -0600, Chris Kuethe wrote:

> > And I ran sks cleandb after each keyfile I loaded in. Over 220 cleandb
> > invokations. There were no errors from merge or build complaining about
> > unparseable packet sequences.
> >
>
> That's the point!
>
> When you invoke sks cleandb the first time it creates the file
> KDB/meta where is written that KDB database is clean. Any subsequent
> invocation of sks cleandb return immediately without doing any
> work.
> Only deleting KDB/meta you can force another cleandb cycle.
Indeed, and I never liked this EVIL(TM) misfeature.  :)  So, finally,
here's a quick patch:

===================================================================
RCS file: clean_keydb.ml,v
retrieving revision 1.1
diff -u -r1.1 clean_keydb.ml
--- clean_keydb.ml 2005/08/26 18:52:57 1.1
+++ clean_keydb.ml 2005/08/26 19:06:54
@@ -325,7 +325,7 @@
   let run applied_filters =
 
     (* only do canonicalize if it's necessary *)
-    if not (List.mem "yminsky.dedup" applied_filters) then (
+    if (true) then (
       perror "Deduping keys in database";
       canonicalize ();
       Keydb.set_meta ~key:"filters" ~data:"yminsky.dedup";
@@ -334,8 +334,7 @@
 
 
     (* note: if dedup was done, merge should be done again *)
-    if not (List.mem "yminsky.dedup" applied_filters)
-      || not (List.mem "yminsky.merge" applied_filters)
+    if (true)
     then (
       perror "Merging keys in database";
       merge ();

--
Jason Harris           |  NIC:  JH329, PGP:  This _is_ PGP-signed, isn't it?
[hidden email] _|_ web:  http://keyserver.kjsl.com/~jharris/
          Got photons?   (TM), (C) 2004

_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel

attachment0 (322 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Permanent diff with pgp.srv.ualberta.ca

Chris Kuethe-2
In reply to this post by Jason Harris
On Fri, 26 Aug 2005, Jason Harris wrote:

>> 2) pgp.srv.ualberta.ca (Chris Kuethe's server) was dumped (Aug 22,
>> around 1900h GMT) and completely reloaded.
>
> #2 is doubtful.  Google for the hosed hashes and you should find all 19
> of them in messages _to this list_ titled "keyserver.noreply.org always
> 19 keys short" and "v3 keys w/(v4) subkeys still afflicting SKS."

Well that's when I shut down sks, dumped and started the reload.

> Chris needs to shutdown SKS and run:
>
>  %rm -f KDB/meta
>  %sks cleandb
>
> on pgp.srv.ualberta.ca, posting clean.log in case the problem persists.

done around 0900 MDT today. the clean log was empty save for "opening log"

CK

--
Chris Kuethe, GCIA: Secure Systems Specialist - U of A CNS
       office: 157 General Services Bldg.    +1.780.492.8135
               chris.kuethe@[pyxis.cns.]ualberta.ca

      GDB has a 'break' feature; why doesn't it have 'fix' too?



_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: Permanent diff with pgp.srv.ualberta.ca

Jason Harris
On Fri, Aug 26, 2005 at 01:27:39PM -0600, Chris Kuethe wrote:
> On Fri, 26 Aug 2005, Jason Harris wrote:
 

> >>2) pgp.srv.ualberta.ca (Chris Kuethe's server) was dumped (Aug 22,
> >>around 1900h GMT) and completely reloaded.
> >
> >#2 is doubtful.  Google for the hosed hashes and you should find all 19
> >of them in messages _to this list_ titled "keyserver.noreply.org always
> >19 keys short" and "v3 keys w/(v4) subkeys still afflicting SKS."
>
> Well that's when I shut down sks, dumped and started the reload.
>
> >Chris needs to shutdown SKS and run:
> >
> > %rm -f KDB/meta
> > %sks cleandb
> >
> >on pgp.srv.ualberta.ca, posting clean.log in case the problem persists.
>
> done around 0900 MDT today. the clean log was empty save for "opening log"
If it refused to do a cleanup, it should have looked like this:

  2005-08-26 15:04:19 0.520183 Opening log
  2005-08-26 15:04:19 0.520804 Opening KeyDB database
  2005-08-26 15:04:19 0.540364 Keydb opened
  2005-08-26 15:04:19 0.540745 Database already deduped
  2005-08-26 15:04:19 0.540810 Database already merged

An actual cleanup (on a pks keydump+fastbuild db) starts like this:

  2005-08-26 15:07:01 0.148892 Opening log
  2005-08-26 15:07:01 0.149522 Opening KeyDB database
  2005-08-26 15:07:01 0.169242 Keydb opened
  2005-08-26 15:07:01 0.169680 Deduping keys in database
  2005-08-26 15:07:01 0.169915 Starting indirect canonicalization
  2005-08-26 15:07:01 0.169974 Starting keydump 0
  2005-08-26 15:07:02 0.661497 10 thousand steps processed
  2005-08-26 15:07:04 0.053281 20 thousand steps processed
  2005-08-26 15:07:05 0.462640 30 thousand steps processed
  2005-08-26 15:07:06 0.764762 Key to be deleted: 9DE61DE934726E8DF22080806382347E
  2005-08-26 15:07:06 0.823418 Key to be deleted: A17DCB31077CB269206D6F0B5828E4C9
  2005-08-26 15:07:06 0.827094 40 thousand steps processed
  2005-08-26 15:07:08 0.313844 50 thousand steps processed

and ends like this:

  2005-08-26 15:19:59 0.013181 2220 thousand steps processed
  2005-08-26 15:19:59 0.048437 Multiple keys found with same ID.  merge_from_hashes called
  2005-08-26 15:19:59 0.048878 Hash: 5BDC703C635488A6E449D626E4B783B2
  2005-08-26 15:19:59 0.049079 Hash: BD582C386E381B241339D65A21E69628
  2005-08-26 15:19:59 0.074983 Completed key merge

--
Jason Harris           |  NIC:  JH329, PGP:  This _is_ PGP-signed, isn't it?
[hidden email] _|_ web:  http://keyserver.kjsl.com/~jharris/
          Got photons?   (TM), (C) 2004

_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel

attachment0 (322 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Permanent diff with pgp.srv.ualberta.ca

Marco Nenciarini
In reply to this post by Jason Harris
On Fri, Aug 26, 2005 at 03:25:18PM -0400, Jason Harris wrote:

> On Fri, Aug 26, 2005 at 04:42:02PM +0200, Marco Nenciarini wrote:
> > On Fri, Aug 26, 2005 at 07:40:58AM -0600, Chris Kuethe wrote:
>
> > > And I ran sks cleandb after each keyfile I loaded in. Over 220 cleandb
> > > invokations. There were no errors from merge or build complaining about
> > > unparseable packet sequences.
> > >
> >
> > That's the point!
> >
> > When you invoke sks cleandb the first time it creates the file
> > KDB/meta where is written that KDB database is clean. Any subsequent
> > invocation of sks cleandb return immediately without doing any
> > work.
> > Only deleting KDB/meta you can force another cleandb cycle.
>
> Indeed, and I never liked this EVIL(TM) misfeature.  :)  So, finally,
> here's a quick patch:
>
[snip patch]

I made this more "politically correct" patch (attached).

With this patch, you don't need to delete KDB/meta, but only specify
-force_cleaning on command line.

Bye

--
---------------------------------------------------------------------
|    Marco Nenciarini    | Debian/GNU Linux Developer - Plug Member |
| [hidden email] | http://www.prato.linux.it/~mnencia       |
---------------------------------------------------------------------
Key fingerprint = FED9 69C7 9E67 21F5 7D95  5270 6864 730D F095 E5E4


_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel

force_cleaning.patch (1K) Download Attachment
signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Permanent diff with pgp.srv.ualberta.ca

Jason Harris
On Sat, Aug 27, 2005 at 02:20:37PM +0200, Marco Nenciarini wrote:
> On Fri, Aug 26, 2005 at 03:25:18PM -0400, Jason Harris wrote:

> > > When you invoke sks cleandb the first time it creates the file
> > > KDB/meta where is written that KDB database is clean. Any subsequent
> > > invocation of sks cleandb return immediately without doing any
> > > work.
> > > Only deleting KDB/meta you can force another cleandb cycle.
> >
> > Indeed, and I never liked this EVIL(TM) misfeature.  :)  So, finally,
> > here's a quick patch:
> >
> [snip patch]
>
> I made this more "politically correct" patch (attached).
>
> With this patch, you don't need to delete KDB/meta, but only specify
> -force_cleaning on command line.
This just overcomplicates things.  When you need to run cleandb, you
want it to just run.  It isn't like build/fastbuild or pbuild, which
actually protect you from destroying existing dbs.  Even worse, and
I've said this before on this list, "sks merge" doesn't filter,
making cleandb necessary after merging.

So, what are you (first Yaron, and now Marco) protecting against?

--
Jason Harris           |  NIC:  JH329, PGP:  This _is_ PGP-signed, isn't it?
[hidden email] _|_ web:  http://keyserver.kjsl.com/~jharris/
          Got photons?   (TM), (C) 2004

_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel

attachment0 (322 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Permanent diff with pgp.srv.ualberta.ca

Marco Nenciarini
On Sat, Aug 27, 2005 at 03:11:31PM -0400, Jason Harris wrote:

> On Sat, Aug 27, 2005 at 02:20:37PM +0200, Marco Nenciarini wrote:
> > On Fri, Aug 26, 2005 at 03:25:18PM -0400, Jason Harris wrote:
>
> > > > When you invoke sks cleandb the first time it creates the file
> > > > KDB/meta where is written that KDB database is clean. Any subsequent
> > > > invocation of sks cleandb return immediately without doing any
> > > > work.
> > > > Only deleting KDB/meta you can force another cleandb cycle.
> > >
> > > Indeed, and I never liked this EVIL(TM) misfeature.  :)  So, finally,
> > > here's a quick patch:
> > >
> > [snip patch]
> >
> > I made this more "politically correct" patch (attached).
> >
> > With this patch, you don't need to delete KDB/meta, but only specify
> > -force_cleaning on command line.
>
> This just overcomplicates things.  When you need to run cleandb, you
> want it to just run.  It isn't like build/fastbuild or pbuild, which
> actually protect you from destroying existing dbs.  Even worse, and
> I've said this before on this list, "sks merge" doesn't filter,
> making cleandb necessary after merging.
This is a bad thing. If sks merge leave the KDB in an unclean state, I
think it should reset all filters stored in KDB/meta.

>
> So, what are you (first Yaron, and now Marco) protecting against?
>

Ok, I think you are right. ATM if an user run sks cleandb, it should
do its work.

Yaron, what do you think about?

Ciao

--
---------------------------------------------------------------------
|    Marco Nenciarini    | Debian/GNU Linux Developer - Plug Member |
| [hidden email] | http://www.prato.linux.it/~mnencia       |
---------------------------------------------------------------------
Key fingerprint = FED9 69C7 9E67 21F5 7D95  5270 6864 730D F095 E5E4


_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Permanent diff with pgp.srv.ualberta.ca

Yaron Minsky
On 8/28/05, Marco Nenciarini <[hidden email]> wrote:
On Sat, Aug 27, 2005 at 03:11:31PM -0400, Jason Harris wrote:
> On Sat, Aug 27, 2005 at 02:20:37PM +0200, Marco Nenciarini wrote:
> > On Fri, Aug 26, 2005 at 03:25:18PM -0400, Jason Harris wrote:
>
> > > > When you invoke sks cleandb the first time it creates the file
> > > > KDB/meta where is written that KDB database is clean. Any subsequent
> > > > invocation of sks cleandb return immediately without doing any
> > > > work.
> > > > Only deleting KDB/meta you can force another cleandb cycle.
> > >
> > > Indeed, and I never liked this EVIL(TM) misfeature.  :)  So, finally,
> > > here's a quick patch:

> > >
> > [snip patch]
> >
> > I made this more "politically correct" patch (attached).
> >
> > With this patch, you don't need to delete KDB/meta, but only specify
> > -force_cleaning on command line.
>
> This just overcomplicates things.  When you need to run cleandb, you
> want it to just run.  It isn't like build/fastbuild or pbuild, which
> actually protect you from destroying existing dbs.  Even worse, and
> I've said this before on this list, "sks merge" doesn't filter,
> making cleandb necessary after merging.

This is a bad thing. If sks merge leave the KDB in an unclean state, I
think it should reset all filters stored in KDB/meta.

Yeah, "sks merge" is generally a hack, and not well supported.  I think Jason's idea of simply always reapplying all cleaners when doing cleandb, is a good one, as is invalidating the meta flags.  I'd accept patches for btoh.

>
> So, what are you (first Yaron, and now Marco) protecting against?
>

Ok, I think you are right. ATM if an user run sks cleandb, it should
do its work.

Yaron, what do you think about?

Ciao

--
---------------------------------------------------------------------
|    Marco Nenciarini    | Debian/GNU Linux Developer - Plug Member |
| [hidden email] | http://www.prato.linux.it/~mnencia        |
---------------------------------------------------------------------
Key fingerprint = FED9 69C7 9E67 21F5 7D95  5270 6864 730D F095 E5E4



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDEYeQaGRzDfCV5eQRAqNlAJ9sroqhrt/nbVSUBogW7DjmrRrP0ACghVOw
iBjCGT2gbDViamXkKyCL/YA=
=f8E5
-----END PGP SIGNATURE-----


_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel




_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: Permanent diff with pgp.srv.ualberta.ca

Dinko Korunic
In reply to this post by Jason Harris
On Sat, Aug 27, 2005 at 03:11:31PM -0400, Jason Harris wrote:
> I've said this before on this list, "sks merge" doesn't filter,
> making cleandb necessary after merging.

I've noticed something strange trying to cleandb databases at pks.aaiedu.hr:
long time ago I've built them with sks merge on a recent keydump and cleaned
them afterwards. Inspired with recent discussions, I've deleted KDB/meta and
did a cleandb run. And again, several days after. And again, several days after
- resulting with same errors every time in a clean.log. Somehow this doesn't
look as cleandb really fixes those issues:

2005-09-01 01:58:08 Direct canonicalization complete
2005-09-01 01:58:08 Merging keys in database
2005-09-01 01:58:08 Starting key merge
2005-09-01 01:58:08 Multiple keys found with same ID.  merge_from_hashes called
2005-09-01 01:58:08 Hash: 4A890E696081B0D3B747143BFB881E79
2005-09-01 01:58:08 Hash: 600066ED625D84CE88211E0252A675D7
2005-09-01 01:58:08 Multiple keys found with same ID.  merge_from_hashes called
2005-09-01 01:58:08 Hash: 0D18FBFDD73B9C77298F0872A0FD5FB4
2005-09-01 01:58:08 Hash: AAC4EE9160676C62F1BEDF8B74108154
2005-09-01 01:58:09 Multiple keys found with same ID.  merge_from_hashes called
2005-09-01 01:58:09 Hash: 6A0F6639D1B70ECA6D8205F7A86D792C
2005-09-01 01:58:09 Hash: A01F53A7B4FB435470BFCBBF0E07160C
2005-09-01 01:58:09 Multiple keys found with same ID.  merge_from_hashes called
2005-09-01 01:58:09 Hash: 046717A4D63BB8EDBB5F5B27BF15F690
2005-09-01 01:58:09 Hash: B7111EA459B6FECC4C90C2CD9DCED497
2005-09-01 01:58:09 Multiple keys found with same ID.  merge_from_hashes called
2005-09-01 01:58:09 Hash: 9E650A41E846F2C48F70FCEA9342CF6D
2005-09-01 01:58:09 Hash: DFC2D000CF185241719239B6F4A8A9B9
2005-09-01 01:58:09 10 thousand steps processed
...
2005-09-01 02:02:56 Multiple keys found with same ID.  merge_from_hashes called
2005-09-01 02:02:56 Hash: 5BDC703C635488A6E449D626E4B783B2
2005-09-01 02:02:56 Hash: BD582C386E381B241339D65A21E69628
2005-09-01 02:02:56 Completed key merge

palunko% egrep -e '2005-09-01.*Multiple keys found' clean.log | wc -l
    1078

Is this normal?

--
NAME:Dinko.kreator.Korunic    NOTE:Standard.disclaimer.applies
URL:http://dkorunic.net  IRC:kre  ICQ:16965294  PGP:0xea160d0b


_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

duplicate (pubkey-only) key IDs (was: Re: Permanent diff with pgp.srv.ualberta.ca)

Jason Harris
On Thu, Sep 01, 2005 at 01:24:09PM +0200, Dinko Korunic wrote:

> I've noticed something strange trying to cleandb databases at pks.aaiedu.hr:
> long time ago I've built them with sks merge on a recent keydump and cleaned
> them afterwards. Inspired with recent discussions, I've deleted KDB/meta and
> did a cleandb run. And again, several days after. And again, several days after
> - resulting with same errors every time in a clean.log. Somehow this doesn't
> look as cleandb really fixes those issues:
>
> 2005-09-01 01:58:08 Direct canonicalization complete
> 2005-09-01 01:58:08 Merging keys in database
> 2005-09-01 01:58:08 Starting key merge
> 2005-09-01 01:58:08 Multiple keys found with same ID.  merge_from_hashes called
> 2005-09-01 01:58:08 Hash: 4A890E696081B0D3B747143BFB881E79
> 2005-09-01 01:58:08 Hash: 600066ED625D84CE88211E0252A675D7
These are keys with the same (short) keyid:

  http://pks.aaiedu.hr:11371/pks/lookup?op=index&fingerprint=on&search=0x00000001&hash=on

  pub  1024R/00000001 1996-06-08 Jo Schueth, Bonn
           Hash=4A890E696081B0D3B747143BFB881E79
           Fingerprint=8B 43 A9 4A 40 E1 3E 92  3E 37 9D 74 BD 86 10 40
  pub  1025R/00000001 1997-01-11 Rocke Verser
           Hash=600066ED625D84CE88211E0252A675D7
           Fingerprint=EE 73 A9 78 60 9C BA CA  DF FC 68 37 CD 73 F3 96

(The long key IDs are 145DCD7A00000001 and 723B4CA500000001, respectively.)

As you may know, there are plenty of such keys:

  http://keyserver.kjsl.com/~jharris/duplicate_keyids.html

> palunko% egrep -e '2005-09-01.*Multiple keys found' clean.log | wc -l
>     1078
>
> Is this normal?

Currently, looking at pubkey-only key IDs:

  %db_stat-4.3 -d KDB/keyid
  ...
  2223152 Number of unique keys in the tree
  2224235 Number of data items in the tree
  ...

  %expr 2224235 - 2223152
  1083

So, no, it looks like you're missing a few.

--
Jason Harris           |  NIC:  JH329, PGP:  This _is_ PGP-signed, isn't it?
[hidden email] _|_ web:  http://keyserver.kjsl.com/~jharris/
          Got photons?   (TM), (C) 2004

_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel

attachment0 (322 bytes) Download Attachment