sks-devel
[Top][All Lists]
Advanced

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

Re: [Sks-devel] Configuring the reverse proxy to support large keys - HT


From: Jeremy T. Bouse
Subject: Re: [Sks-devel] Configuring the reverse proxy to support large keys - HTTP error 413
Date: Mon, 28 Apr 2014 13:32:37 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10

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?

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

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
> 


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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