Sks and mailsync

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

Sks and mailsync

Marco Nenciarini

I'm investigating why my sks send so little number of sync email.  

I'm not a good ocaml reader, but if I have correctly undestod the
code, sks send a sync email only when a _new_ key is submitted
directly to it via email or /pks/add web command.

It's correct?

If it's correct, i think it isn't a good behavior because we don't
propagate to pks network any key from hkp updates nor new keys from
other sks servers via recon process.

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: Sks and mailsync

Yaron Minsky
On 8/22/05, Marco Nenciarini <[hidden email]> wrote:

I'm investigating why my sks send so little number of sync email.

I'm not a good ocaml reader, but if I have correctly undestod the
code, sks send a sync email only when a _new_ key is submitted
directly to it via email or /pks/add web command.

This is by design.  SKS is designed to receive updates from PKS, not propogate them.  It seems to me that the PKS network should be responsible for its own replication.  And SKS requires very few incoming PKS connections, since any updates that come in to any SKS server will eventually be distributed everywhere by SKS's own distribution network.

New keys that arrive from the SKS recon process should _not_ be propagated to PKS.  That would create storms of traffic when an out-of-date server gets back up to date, so it would be bad for PKS.  The reason for forwarding new keys is simply to ensure that things submitted to SKS are also submitted to the PKS network, thus keeping the networks roughly in-sync.  That doesn't mean that it's appropriate to spam the PKS network every time an SKS server gets an update.

It's correct?

If it's correct, i think it isn't a good behavior because we don't
propagate to pks network any key from hkp updates nor new keys from
other sks servers via recon process.

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)

iD8DBQFDCe6kaGRzDfCV5eQRAo/LAJwKhiLCYJdqfhhdTwYbOCUbi/X3HQCffw1B
4Tw2Oucs+p3I45YGzYuNw+U=
=ukEe
-----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: Sks and mailsync

Marco Nenciarini
On Mon, Aug 22, 2005 at 12:41:40PM -0400, Yaron Minsky wrote:

> On 8/22/05, Marco Nenciarini <[hidden email]> wrote:
> >
> >
> > I'm investigating why my sks send so little number of sync email.
> >
> > I'm not a good ocaml reader, but if I have correctly undestod the
> > code, sks send a sync email only when a _new_ key is submitted
> > directly to it via email or /pks/add web command.
>
>
> This is by design. SKS is designed to receive updates from PKS, not
> propogate them. It seems to me that the PKS network should be responsible
> for its own replication. And SKS requires very few incoming PKS connections,
> since any updates that come in to any SKS server will eventually be
> distributed everywhere by SKS's own distribution network.
>
> New keys that arrive from the SKS recon process should _not_ be propagated
> to PKS. That would create storms of traffic when an out-of-date server gets
> back up to date, so it would be bad for PKS. The reason for forwarding new
> keys is simply to ensure that things submitted to SKS are also submitted to
> the PKS network, thus keeping the networks roughly in-sync. That doesn't
> mean that it's appropriate to spam the PKS network every time an SKS server
> gets an update.
>
> It's correct?
I partially agree this beavior, but i think we should send mail update
for _all_ key update other than recon process.

I think we must help pks network to remain in sync most as possible
(but without flooding it).

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
|

Debian/Ubuntu keyring maintainer issues (was: Re: Sks and mailsync)

Jason Harris
On Mon, Aug 22, 2005 at 08:39:28PM +0200, Marco Nenciarini wrote:

> I think we must help pks network to remain in sync most as possible
> (but without flooding it).

Last I checked, all (active) SKS servers were doing their part except
keyserver.ubuntu.com, which still doesn't send mailsyncs to any
onak/OpenPKSD/pks keyservers:

  http://keyserver.ubuntu.com:11371/pks/lookup?op=stats

Also, a Debian keyring:

  rsync://keyring.debian.org/keyrings/keyrings/debian-keyring.pgp

has the (in)famous problem (w/GPG 1.4.2):

  gpg: mpi larger than indicated length (2 bytes)
  gpg: keyring_get_keyblock: read error: invalid packet
  gpg: error reading keyblock: invalid keyring

and can't be (armored and) fed through keyserver(s) with the rest
of the Debian keyrings, as I occasionally do because it always turns
up new data.

Finally, pushing these keyrings through my SKS keyserver just now
resulted in 78 hash updates, meaning that despite ongoing _queries_
from keyring.debian.org (via lwp-trivial/1.41, to subkeys.pgp.net),
nobody is properly pushing these updates _to_ the well-synchronized
keyservers.

IIRC, the same person is responsible for all these issues.

--
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