[Sks-devel] New turnup, looking for peers

Hey, all! First turnup of SKS I've done (publicly... I've turned up a private instance years ago) so please do confirm that everything's set up correctly, if you don't mind? If so, I welcome global peers. This is a private machine. MEMBER ENTRY: sks.mirror.square-r00t.net 11370 #

[Sks-devel] Dumps now being offered (sks.mirror.square-r00t.net)

Hey, all! I am now offering full dumps[0] via RSYNC and HTTP(S). If there's demand, I can implement FTP (plaintext and FTP/S) as well. Note that they are compressed currently with lrzip[1], but may in the future be compressed with XZ - I need to do some compression comparisons. Currently I only

Re: [Sks-devel] Emergency Maintenance: sks.mirror.square-r00t.net

On 12/10/2017 12:07 PM, brent s. wrote: > On 12/10/2017 12:03 PM, brent s. wrote: >> On 12/10/2017 11:41 AM, brent s. wrote: >>> Hey all- >>> >>> I will shortly (within the next 20 minutes) be bringing >>> sks.mirror.square-r00t.net down for

[Sks-devel] Emergency Maintenance: sks.mirror.square-r00t.net

Hey all- I will shortly (within the next 20 minutes) be bringing sks.mirror.square-r00t.net down for maintenance - expansion of storage space and increased RAM. I do not expect the outage to last more than an hour at conservative guess, more realistic estimate is ~15-20 minutes. -- brent saner

Re: [Sks-devel] Emergency Maintenance: sks.mirror.square-r00t.net

On 12/10/2017 12:03 PM, brent s. wrote: > On 12/10/2017 11:41 AM, brent s. wrote: >> Hey all- >> >> I will shortly (within the next 20 minutes) be bringing >> sks.mirror.square-r00t.net down for maintenance - expansion of storage >> space and increased RAM. >>

Re: [Sks-devel] Emergency Maintenance: sks.mirror.square-r00t.net

On 12/10/2017 11:41 AM, brent s. wrote: > Hey all- > > I will shortly (within the next 20 minutes) be bringing > sks.mirror.square-r00t.net down for maintenance - expansion of storage > space and increased RAM. > > I do not expect the outage to last more than an hour at

Re: [Sks-devel] Emergency Maintenance: sks.mirror.square-r00t.net

On 12/10/2017 05:26 PM, Kristian Fiskerstrand wrote: > > In that case I'm surprised the expansion of disk store didn't work, > which isn't a big problem for the general keyserver in the global > gossiping network, but it _could_ cause issues for stand-alone servers. > So definitely not good. > >

Re: [Sks-devel] Emergency Maintenance: sks.mirror.square-r00t.net

On 12/10/2017 12:50 PM, brent s. wrote: >> has anyone seen that "Fatal error: exception Keydb.Unsafe.No_db" before >> (esp. after growing a filesystem)? I don't seem to have any other >> inconsistent data on the filesystem from what i can tell >> > > Dec

Re: [Sks-devel] Emergency Maintenance: sks.mirror.square-r00t.net

On 12/10/2017 05:15 PM, Kristian Fiskerstrand wrote: > Good that things are restored, but to try to debug this more generally, > can you confirm you used fastbuild rather than a full build originally? full build has always been used, both in the original turnup and in this new turnup. > In that

Re: [Sks-devel] Dumps/importing & de-peering (WAS: Re: SKS apocalypse mitigation)

On 05/05/2018 08:30 AM, Andrew Gallagher wrote: > >> On 5 May 2018, at 11:31, brent s. <b...@square-r00t.net> wrote: >> >> it is SO IMPORTANT for both ends of the peering to have a relatively >> recent keyset. i don't see how we can "fix" this with

[Sks-devel] Dumps/importing & de-peering (WAS: Re: SKS apocalypse mitigation)

On 05/05/2018 03:48 AM, Phil Pennock wrote: > On 2018-05-04 at 17:13 +0100, Andrew Gallagher wrote: >> AFAICT, the limitation that SKS servers should only recon with known >> peers was introduced as a measure against abuse. But it's a pretty >> flimsy anti-abuse system considering that anyone can

Re: [Sks-devel] Dumps/importing & de-peering (WAS: Re: SKS apocalypse mitigation)

On 05/05/2018 10:22 AM, Andrew Gallagher wrote: > >> On 5 May 2018, at 15:00, brent s. <b...@square-r00t.net> wrote: >> >> (a) is taken care of by recon already (in a way), > > According to a list message from earlier today it is not. If the delta is > s

Re: [Sks-devel] Strange case

On 05/19/2018 03:26 PM, Paul Fontela wrote: > Hello everyone, > I just saw that one of my sks servers is out of the list at > https://sks-keyservers.net/status/, the server is: > a.0.keysnode.ispfontela.es > > I have reviewed the logs, both the recon.log and the nginx / access.log > I have seen

[Sks-devel] Temporary outage - sks.mirror.square-r00t.net

Yeah, so my registrar canceled my auto-renew and, as a result, if you were peering me you may be noticing me failing. It's been rectified, but it of course hasn't propagated everywhere and their TTL for the SOA they replaced mine with (UGH.) is frustratingly high. Long story short: - services

Re: [Sks-devel] Implications of GDPR

On 05/03/2018 07:40 AM, Moritz Wirth wrote: > That does not help because you still Store european data which is still > affected by the GDPR. > > What about only accepting valid keys and removing all revoked or expired > keys from the database? If someone wants to have his data deleted he can >

[Sks-devel] dump sources (WAS: Re: Inclusion in membership file to peer)

On 01/09/2018 02:03 PM, Alain Wolf wrote: > On 09.01.2018 18:27, Moritz Wirth wrote: >> Hi, >> >> >> the pgp keyserver dump is outdated for about 100k keys - i created a new >> dump which you can use: https://cdn.fstatic.io/sksdump >> > > I removed pgp.key-server.io from the list of dumps in the

Re: [Sks-devel] Looking for peering partners for Mumbai SKS server

how many keys did you import so we know what your delta is?___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] dump-only server (gossip but not public pool availability)

On 02/04/2018 07:26 PM, Hendrik Visage wrote: > Good day, > >  As I can’t dump the SKS database while running, and the file snapshot > setup not quite feasible for my setup(s) yet, I was wondering about a > gossiping only server (and only gossiping to a limited set servers close > peers) that

Re: [Sks-devel] dump-only server (gossip but not public pool availability)

On 02/04/2018 07:45 PM, Chris Kuethe wrote: > you can spin up a second instance on the same host, perhaps bound to > 127.0.0.1:21370 and 127.0.0.1:21371 > . Have your public instance also peer with the > localhost-only instance, and the

[Sks-devel] Building on ocaml 4.06?

Hey, I filed this bug: https://bitbucket.org/skskeyserver/sks-keyserver/issues/55/unbound-module-nat-in-cryptokit-on-ocaml Can anyone on ocaml 4.06 see if they can reproduce? This is driving me crazy. -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info

[Sks-devel] python scripts/other tools you may find useful

Hey, all! For starters, if any of you happen to be on Arch, I've packaged[0] a patched version of SKS that will let you provide dumps of your database from the same box you serve keys from with no downtime. (All it is is a version of SKS with some filesystem paths changed and a differently-named

Re: [Sks-devel] SKS apocalypse mitigation

On 03/25/2018 07:39 AM, Andrew Gallagher wrote: > >> On 25 Mar 2018, at 03:37, Phil Pennock wrote: >> >> Disappearance of >> public keyservers would be a major inconvenience, but not a disaster. > > Considering that keyservers are currently the only resilient way to

Re: [Sks-devel] Another Poison Key?

On 1/14/19 9:35 AM, Simon Lange wrote: > Hi, > > i noticed a key, which, whenever one of my peers tries to send it to me, > is failing and causing unstable enlistment in the sks pool list. > > Jan 14 06:48:05 atlas sks[17917]: 2019-01-14 06:48:05 Requesting 100 > missing keys from , starting

Re: [Sks-devel] Another Poison Key?

On 1/14/19 10:06 AM, Yegor Timoshenko wrote: >> hrm.. yeah, looks malformatted. >> >> "Error handling request: 128-bit v3 fingerprints not >> implemented" >> >> https://bugs.launchpad.net/launchpad/+bug/144435 >> https://bugs.launchpad.net/launchpad/+bug/4746 > > Could you upload the key

Re: [Sks-devel] Unusual traffic for key 0x69D2EAD9 and 0xB33B4659

On 1/13/19 12:15 AM, Shengjing Zhu wrote: > Sorry for top replying. I'm using mobile phone. > > Requests are coming from different network, at least hundreds IP. > > And it seems my server(pgp.ustc.edu.cn ) is down > again... I'll check it when I got home. If it's caused

Re: [Sks-devel] Unusual traffic for key 0x69D2EAD9 and 0xB33B4659

On 1/13/19 1:49 AM, Gabor Kiss wrote: >> Request counted in 2h: >> >>178 0xB33B4659 >> 186 0x69D2EAD9 >> 290 0x2016349F5BC6F49340FCCAF99F9169F4B33B4659 >> 336 0x1013D73FECAC918A0A25823986CE877469D2EAD9 > > I checked my logs. 15% of the recent 18k requests were related to these

Re: [Sks-devel] exchange of ideas

On 3/22/19 9:44 PM, brent s. wrote: (SNIP) > As you can see, the binary format is approximately 70% the size on-disk > of the ASCII-armored version. This scales pretty well; generally > speaking, the binary format of any given signature, including signatures > or not, regardless

Re: [Sks-devel] exchange of ideas

Whoops, sent a direct reply instead of to the list. Pasted below.On Mar 22, 2019 23:20, fuat wrote:I thought it was more comprehensive. Let me explain. A text file, html file, and .asc file are not dangerous to the server. Which is what I assert in my first reply, yes.The attacker cannot harm the

Re: [Sks-devel] exchange of ideas

On 3/22/19 4:50 PM, fuat wrote: > Hi everybody, > > Is it a security threat to keep public keys in the sks database in the > directory as an .asc file? > > Can it be done? Why can not be done? > > What are the advantages and disadvantages? > > I'd appreciate it if you sent me your ideas. > A

Re: [Sks-devel] exchange of ideas

On 3/22/19 9:16 PM, brent s. wrote: > On 3/22/19 4:50 PM, fuat wrote: >> Hi everybody, >> >> Is it a security threat to keep public keys in the sks database in the >> directory as an .asc file? >> >> Can it be done? Why can not be done? >> >> W

Re: [Sks-devel] No dumps

On 3/15/19 3:54 PM, Gabor Kiss wrote: >> I have loaded key dumps from http://stueve.us/keydump. >> I see 5.450.511 keys loaded. > (SNIP) > We lack fresh and fast reachable dumps, folks. > (Keys.niif.hu - the server operated by me - was the one of > the last three dump sources but it is also dead

Re: [Sks-devel] Unusual traffic for key 0x69D2EAD9 and 0xB33B4659

On 3/20/19 4:44 PM, Jeremy T. Bouse wrote:> > I don't speak for all SKS server operators, but I do have a > configuration block in my NGINX configuration that specifically > identifies those keys and simply returns a 444 status code. > > I've been trying to get a handle on the

Re: [Sks-devel] GDPR (equine corpse) (WAS: Re: The pool is shrinking)

On 8/17/19 8:08 AM, Stefan Claas wrote: > brent s. wrote: > >> 4.) *Real* identifiable personal information is by *no means* a >> requirement for the creation of a key, nor making it available on a >> keyserver. Granted, you're going to face some challenges at a >>

Re: [Sks-devel] GDPR (equine corpse)

On 8/17/19 11:46 AM, Stefan Claas wrote: > Anonymity is a very important point when one likes to communicate securely > and anonymously! > > For that purpose Anonymous Remailers with a Nym account are in service > for many years. It requires on the users side that he / she is familiar > with GPG,

[Sks-devel] GDPR (equine corpse) (WAS: Re: The pool is shrinking)

SO for starters, please keep this off the "pool is shrinking" thread. I'd like to see that thread relevant to resolving resiliency issues of the SKS network, given that's the actual purpose behind starting that thread. GDPR is off-topic to that thread and, quite frankly, it's getting *extremely*

Re: [Sks-devel] GDPR (equine corpse)

On 8/17/19 4:44 PM, Tobias Frei wrote: > > > On Aug 17, 2019 19:11, Stefan Claas wrote: > > Interesting! If understood correctly the advantage then would be no > changes > > in the SKS code and simply using a front-end key parser, with a > defined rule > set, right? > >

Re: [Sks-devel] GDPR (equine corpse) (WAS: Re: The pool is shrinking)

On 8/20/19 6:05 AM, Tobias Mueller wrote: (SNIP) >> This means not only are keydumps allowed for research (§2), but the >> SKS in general (ESPECIALLY US servers and operators, which I'll get to >> in a moment) is exempt - we provide "...archiving purposes in the >> public interest" (§3). Frankly

Re: 6 million

On 4/14/20 15:17, Stefan Claas wrote: > brent s. wrote: > >> On 4/14/20 11:00, Stefan Claas wrote: >>> >>> Why still focusing on a dead project like SKS and not convining the other >>> guys from Mailvelope or Hagrid to add peering capabilities? >>

Re: 6 million

On 4/14/20 11:00, Stefan Claas wrote: > > Why still focusing on a dead project like SKS and not convining the other > guys from Mailvelope or Hagrid to add peering capabilities? > You do realize one can do both, right? > What benefits do you have as an SKS operator, to still support such > old