Re: [Sks-devel] Configuring the reverse proxy to support large keys - HTTP error 413

[Kristian Fiskerstrand]

On Apr 28, 2014 7:36 PM, "Jeremy T. Bouse" <address@hidden> wrote:
>
> I don't know about the others on the list but my configuration follows
> the recommendations from
> https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Peering which has
> never stated anything about this issue as long as I've been following
> it. Do we need to make changes to the documentation that's already out
> there?

Yes, we should once we determine an answer to your next question

>
> As to the key you selected to test with it's no surprising it's a large
> upload given that it's weasel's old 1024D Debian key with over 3K
> signatures and one of the strong set keys as he stays high in the WoT.

Yup, Peter was the original source for investigating this issue

> His new 4096R key (62AF4031C82E0039) already have over 1K signatures on
> it. In that case where do we set a sane upper bound as it will only
> continue to grow on keys that make it into the strong set with thousands
> of signatures?

This is indeed THE question, and the answer will potentially vary over time. Atm it needs to be at least 2MiB but an optimal size will require more analysis.

>
> On 04/28/2014 12:25 PM, Kristian Fiskerstrand wrote:
> > I've received reports that uploading some (large) keys to some of the
> > keyservers in the pool (my test shows failure on 30 servers after
> > trying to run against 115: These are listed in [A]) results in a
> > gpgkeys: HTTP post error 22: The requested URL returned error: 413
> > Request Entity Too Large
> >
> > In this case the Content-Length is 1377406, seemingly exceeding the
> > default nginx configuration. The fix for nginx is to set
> > client_max_body_size 2m; (or larger) in the http context of nginx.conf.
> >
> > I have not yet implemented an automated check for this in the pool
> > (and a bit unsure how I'd do it without actually sending large amount
> > of data to the server during the check, something I generally want to
> > avoid), but might run a semi-manual / scripted check and add affected
> > servers to the blacklist if the issue persists after some time.
> >
> > gpg2 --send-key DE7AAF6E94C09C7F can be used to test.
> >
> > Please consider re-configuring the servers accordingly.
> >
> > [A] non-exhaustive list of servers affected
> > sks.spodhuis.org
> > zimmermann.mayfirst.org
> > vm-keyserver.spline.inf.fu-berlin.de
> > keyserver.mesh.deuxpi.ca
> > sks.fidocon.de
> > keys.exosphere.de
> > keys.sflc.info
> > pgpkeys.mallos.nl
> > keyserver.uz.sns.it
> > openpgp.andrew.kvalhe.im
> > pgp.gmu.edu
> > keyserver.compbiol.bio.tu-darmstadt.de
> > keys2.alderwick.co.uk
> > keys.alderwick.co.uk
> > keyserver.advmapper.com
> > sks.undergrid.net
> > keys.jhcloos.com
> > sks.alpha-labs.net
> > pgpkey.org
> > keys.indymedia.org
> > pgp.freiwuppertal.de
> > keyserver.linuxpro.nl
> > keyserver.secure-u.de
> > sks.stsisp.ro
> > key.ip6.li
> > keys-01.licoho.de
> > key.adeti.org
> > keys-02.licoho.de
> > keyserver.durcheinandertal.ch
> > keyserver.blupill.com
> >
> >
> >
> > _______________________________________________
> > Sks-devel mailing list
> > address@hidden
> > https://lists.nongnu.org/mailman/listinfo/sks-devel
> >
>
>
>
> _______________________________________________
> Sks-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/sks-devel
>