Re: [Sks-devel] withdrawal of service: sks.spodhuis.org

Just saying... ...the person who created that key has finally started a long overdue process. They are likely reading this as well, so: Thank you. This could otherwise have ended much worse. To the other readers, but only to those of them who do not agree with the following sentences: Please avoi

[Sks-devel] Berkley DB Logs

Hi sks-Guys, I know, there are already discussions about getting rid of the many Berkley DB logs. Furthermore, I would like to ask you all for the best practise or YOUR best practise for standard maintance jobs (cronjobs etc.) during operating of sks keyservers. Best Regards Fabian 'otih' pgp

Re: [Sks-devel] withdrawal of service: sks.spodhuis.org

Hi Haw, On Sun, Jul 15, 2018 at 9:17 AM Haw Loeung wrote: > > On Fri, Jul 13, 2018 at 07:53:01PM +0100, Andrew Gallagher wrote: > > I am still willing to help with possible upgrades and/or > > replacements for the SKS network. At this point I have come to > > believe that a minimal network contai

Re: [Sks-devel] withdrawal of service: sks.spodhuis.org

> Does anyone in the pool run hockeypuck? How compatible is its recon with others running sks-keyserver? Yes, here is one: http://keyserver.snt.utwente.nl (see https://sks-keyservers.net/status/ and http://keyserver.snt.utwente.nl:11371/pks/lookup?op=stats ) However, it was kicked out of the poo

Re: [Sks-devel] withdrawal of service: sks.spodhuis.org

On Sun, Jul 15, 2018 at 11:17:20AM +1000, Haw Loeung wrote: > On Fri, Jul 13, 2018 at 07:53:01PM +0100, Andrew Gallagher wrote: > > I am still willing to help with possible upgrades and/or > > replacements for the SKS network. At this point I have come to > > believe that a minimal network containi

Re: [Sks-devel] withdrawal of service: sks.spodhuis.org

On Fri, Jul 13, 2018 at 07:53:01PM +0100, Andrew Gallagher wrote: > I am still willing to help with possible upgrades and/or > replacements for the SKS network. At this point I have come to > believe that a minimal network containing only key material, SBINDs > and revocations (no id packets, no th

Re: [Sks-devel] withdrawal of service: sks.spodhuis.org

Does anyone in the pool run hockeypuck? How compatible is its recon with others running sks-keyserver? Daniel On Sat, Jul 14, 2018 at 5:52 AM, Human at FlowCrypt wrote: > One more apology - there does seem to be recent activity when you look at > the repo owner: https://github.com/hockeypuck > >

Re: [Sks-devel] heads-up: another attack tool, using SKS as FS

On 7/14/2018 9:42 AM, Hendrik Visage wrote: > > >> On 14 Jul 2018, at 13:04 , Gabor Kiss > > wrote: >> Then let's drop keys that don't contain a valid email address in the key id. >>> >>> How do you propose to validate the email address? >>> >>> (Hint: this is

Re: [Sks-devel] heads-up: another attack tool, using SKS as FS

> On 14 Jul 2018, at 13:27 , Tom at FlowCrypt wrote: > > > How do you propose to validate the email address? > > I'm using a library to parse the uid as email, name and a comment. For the > email, I'm using a very, very long regex. Of the 5M keys available in SKS > dumps, very few uids are m

Re: [Sks-devel] heads-up: another attack tool, using SKS as FS

> On 14 Jul 2018, at 13:04 , Gabor Kiss wrote: > >>> Then let's drop keys that don't contain a valid email address in the key id. >> >> How do you propose to validate the email address? >> >> (Hint: this is a surprisingly hard problem.) > > See also "web of trust" and "strong set". > Address

Re: [Sks-devel] withdrawal of service: sks.spodhuis.org

One more apology - there does seem to be recent activity when you look at the repo owner: https://github.com/hockeypuck Though not loads of activity, still more code contributions than the SKS repo: https://bitbucket.org/skskeyserver/sks-keyserver/commits/all It may be worth considering. On Sat,

Re: [Sks-devel] withdrawal of service: sks.spodhuis.org

Sorry, I hadn't noticed that you linked specifically the conflux (reconciliation code). That is indeed a good start if someone wanted to take the time to understand it. On Sat, Jul 14, 2018, 20:16 Human at FlowCrypt wrote: > Hockeypuck has not had any commits in years, if I saw correctly. > > It

Re: [Sks-devel] withdrawal of service: sks.spodhuis.org

Hockeypuck has not had any commits in years, if I saw correctly. It cannot process some of the keys (maybe for a good reason, but it will clog the recon mechanism nevertheless, I suppose). I think it was a great effort, but apparently not maintained. If the recon process could be updated with me

Re: [Sks-devel] heads-up: another attack tool, using SKS as FS

Thanks Andrew for pointing it out. We could grandfather such keys if their uid length fits within a limit (256 bytes?). But do not return such keys in search results, except when searched directly by fingerprint or longid. Newly uploaded keys without valid uid email address would not be accepted.

Re: [Sks-devel] withdrawal of service: sks.spodhuis.org

Though I am not sure, https://github.com/hockeypuck/conflux may be worth a look. If somebody has a short How-To for installing hockeypuck (and importing a keydump..), I am happy to test if it is more stable than sks :) Best regards, Moritz Am 14.07.18 um 02:50 schrieb Tom at FlowCrypt: > I wou

Re: [Sks-devel] heads-up: another attack tool, using SKS as FS

> On 14 Jul 2018, at 09:34, Human at FlowCrypt wrote: > > > > Could this be mitigated by validating email addresses as they come in? > > > No, because ID fields are not required to be email addresses. > > Then let's drop keys that don't contain a valid email address in the key id. You do re

Re: [Sks-devel] heads-up: another attack tool, using SKS as FS

> How do you propose to validate the email address? I'm using a library to parse the uid as email, name and a comment. For the email, I'm using a very, very long regex. Of the 5M keys available in SKS dumps, very few uids are miscategorized. It may be hard to do with 100% accuracy, but it's unsur

Re: [Sks-devel] heads-up: another attack tool, using SKS as FS

> > Then let's drop keys that don't contain a valid email address in the key id. > > How do you propose to validate the email address? > > (Hint: this is a surprisingly hard problem.) See also "web of trust" and "strong set". Addresses should/can be checked by humans worldwide who sign/certify t

Re: [Sks-devel] heads-up: another attack tool, using SKS as FS

> Then let's drop keys that don't contain a valid email address in the key id. How do you propose to validate the email address? (Hint: this is a surprisingly hard problem.) ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailm

Re: [Sks-devel] heads-up: another attack tool, using SKS as FS

> > Could this be mitigated by validating email addresses as they come in? > No, because ID fields are not required to be email addresses. Then let's drop keys that don't contain a valid email address in the key id. We should want to solve this, not stick our heads in the sand. On Sat, Jul 14,

Re: [Sks-devel] heads-up: another attack tool, using SKS as FS

> I think the time has come where we have to re-evaluate what the > keyservers are *for*. Once we answer that, we answer what should be > done about it. I agree, although I think maybe you're not taking it far enough. What threats should we be defending against? The original idea of a keyserver

Re: [Sks-devel] heads-up: another attack tool, using SKS as FS

On 14 Jul 2018, at 04:37, Robert J. Hansen wrote: >> IMHO Photo-ID should be dropped entirely, I see no point and its just >> ripe for abuse like this.. > > Unfortunately, we really can't. They've been part of OpenPGP > certificates for just about twenty years now. They are an expected part >