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

[Kiss Gabor (Bitman)]

On Fri, 13 Jul 2018, Ryan Hunt wrote:

> Sooner or later you guys need
> start looking forward, if mistakes were made in the past ignoring them is not
> going to solve anything.

> Ignore the users, your the sysops.. Either SKS will die, or the entire thing
> is going to have to be scrapped and redesigned with something that can permit
> removal of keys, or drop all support for images and start validating key
> holders.. none are ideal, but one is pretty clearly better than the others to
> me.


My 2 cents.

The current infrastructure must be wiped out. It is a dead duck.

In the new era key owners have to proof their identity. Practically
speaking key servers accept only keys belonging to the strong set.
(At least in first step.)
Moreover key owners must add an UID with this text:

"I want this key to be provided by public databases.
I understand and I agree that it cannot be deleted any more."

And yes. Key servers have to do cryptographic operations.

Later, when we find a sophisticated algorithm, key deletion could be
triggered by adding another properly signed UID:

"I want this key to be deleted from public databases.
Thanks guys for your efforts. :-)"

Regards

Gabor

___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

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

[Robert J. Hansen]

> Does a user revolt even matter as the SKS pool is dismantled by
> continuous attacks?

"We had to burn the village in order to save it!", I see.

There are three questions:

1.  Can SKS be saved?
2.  If so, how?
3.  If not, what next?

I believe the answers are "no", "N/A", and "I don't know yet."

If you're pitching a "let's drop all photo IDs", you're in effect
answering them "no", "N/A", and "let's make sure dropping photo IDs are
part of the next spec".  Which may be a good idea, don't get me wrong,
but it's not part of a saving-SKS discussion.

___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

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

[Tom at FlowCrypt]

> Is it possible without facing a user revolt?  No.

SKS does do key parsing though, and we could surely figure out just how big
the photo-id is in bytes. I suggest to impose a limit. Does it really need
to be any bigger than 10kB? My suggestion:

- impose a 10kB image size limit
- max one image per key
- max 20 uids per key
- max 1kb length per uid



On Sat, Jul 14, 2018 at 3:37 AM, 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
> of the certificate.  Users already scream bloody murder about GnuPG and
> Enigmail dropping support for SE packets and those have been deprecated
> since 2003.  The idea of just waving a wand and getting rid of a
> non-deprecated part of a public key is just ... no.
>
> Is it technically possible?  Yes.  But it would require a significant
> amount of redesign: we'd have to parse out the key, recognize images,
> drop them, etc.  Right now SKS does *zero* cryptographic verification of
> the key data; we'd need to change SKS to introduce at least some crypto
> support.
>
> Is it possible without facing a user revolt?  No.
>
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel
>
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

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

[Ryan Hunt]

Does a user revolt even matter as the SKS pool is dismantled by continuous 
attacks?

I think a significant amount of redesign is required to save the SKS network at 
this point, the crusades against SKS have just been ratcheting up and they are 
winning IMO, I dropped my server from the pool eons ago because of how much 
time was required to keep my server alive and healthy, it was like having a 
toddler that never ever grew up.. Sooner or later you guys need start looking 
forward, if mistakes were made in the past ignoring them is not going to solve 
anything.

Over a decade ago we were all discussing what would happen if child pornography 
was uploaded to the pool, and here we are still with our heads stuck in the 
sand.. IMHO its about time we just nuked that issue from orbit. Ignore the 
users, your the sysops.. Either SKS will die, or the entire thing is going to 
have to be scrapped and redesigned with something that can permit removal of 
keys, or drop all support for images and start validating key holders.. none 
are ideal, but one is pretty clearly better than the others to me.

-Ryan

> On Jul 13, 2018, at 9:37 PM, 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
> of the certificate.  Users already scream bloody murder about GnuPG and
> Enigmail dropping support for SE packets and those have been deprecated
> since 2003.  The idea of just waving a wand and getting rid of a
> non-deprecated part of a public key is just ... no.
> 
> Is it technically possible?  Yes.  But it would require a significant
> amount of redesign: we'd have to parse out the key, recognize images,
> drop them, etc.  Right now SKS does *zero* cryptographic verification of
> the key data; we'd need to change SKS to introduce at least some crypto
> support.
> 
> Is it possible without facing a user revolt?  No.
> 
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel


___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

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

[Robert J. Hansen]

> 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
of the certificate.  Users already scream bloody murder about GnuPG and
Enigmail dropping support for SE packets and those have been deprecated
since 2003.  The idea of just waving a wand and getting rid of a
non-deprecated part of a public key is just ... no.

Is it technically possible?  Yes.  But it would require a significant
amount of redesign: we'd have to parse out the key, recognize images,
drop them, etc.  Right now SKS does *zero* cryptographic verification of
the key data; we'd need to change SKS to introduce at least some crypto
support.

Is it possible without facing a user revolt?  No.

___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

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

[Ryan Hunt]

IMHO Photo-ID should be dropped entirely, I see no point and its just ripe for 
abuse like this.. We should not be relying on that w/cryptography.. If I’m 
going to sign your key and validate I know you then I should be validating your 
the holder of that private key with an exchange first (much like I am proposing 
with adding your key to SKS network).. then really what does it matter what 
image is stored with the public key after that since the private key holder 
could manipulate that. Honestly it was eons ago when I last went to a key 
signing, but the few I did go to back in my College days never required a photo 
in the public key.

-Ryan

> On Jul 13, 2018, at 9:01 PM, Tom at FlowCrypt  wrote:
> 
> > that would probably be an incomplete mitigation:
> 
> Sounds better than no solution!
> 
> > -people can use the photo id field instead
> 
> Size limit can be enforced.
> 
> > -people can use valid e-mail addresses under an own domain ("catch-all")
> 
> As long as it can validate, seems fine to me. Better than no verification.
> 
> > -your keyserver suddenly can be abused for email spamming
> 
> Any online service that allows registrations can be abused for email 
> spamming, if you consider registration emails an "email spam".
> 
> 
> 
> Another limitation: you cannot apply the email verification process to the 
> recon algo, because the user would get flooded with verification emails. That 
> means you could have a malicious SKS implementation flooding others with 
> non-verified emails. Again, not perfect, but a good start.
> 
> 
> 
> On Sat, Jul 14, 2018 at 2:50 AM, Tobias Frei  > wrote:
> Hi Ryan,
> 
> that would probably be an incomplete mitigation:
> 
> -people can use the photo id field instead
> -people can use valid e-mail addresses under an own domain ("catch-all")
> -your keyserver suddenly can be abused for email spamming
> 
> Best regards
> Tobias Frei
> 
> 
> 
> Am 14.07.2018 um 02:57 schrieb Ryan Hunt:
> Could this be mitigated by validating email addresses as they come in? Like 
> sending an encrypted mail to the said address with a return token, If the 
> token is not provided the key is never put into the SKS rotation?
> 
> I think a solution like this would be much more effective, and if there was 
> some desire to conform to GDPR at some point it would be pretty much required 
> first step because I cannot see how we could possibly remove keys without a 
> command signed by that key, and putting this in place would make that ‘no 
> more difficult to remove than it was to add’..
> 
> Regards,
> -Ryan Hunt
> 
> On Jul 13, 2018, at 11:20 AM, Phil Pennock  > wrote:
> 
> Signed PGP part
> Heads-up:
> 
> https://medium.com/@mdrahony/are-pgp-key-servers-breaking-the-law-under-the-gdpr-a81ddd709d3e
>  
> 
> https://github.com/yakamok/keyserver-fs 
> 
> https://lobste.rs/s/sle0o4/are_pgp_key_servers_breaking_law_under 
> 
> 
> This `keyserver-fs` is software to attack SKS, using it as a filesystem, in
> what appears to be a deliberate attack on the viability of continuing to
> run a keyserver.
> 
> The author is upset that there's no deletion, so is pissing in the pool.
> 
> -Phil
> 
> 
> 
> 
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org 
> https://lists.nongnu.org/mailman/listinfo/sks-devel 
> 
> 
> 
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org 
> https://lists.nongnu.org/mailman/listinfo/sks-devel 
> 
> 
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel

___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

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

[Tom at FlowCrypt]

> that would probably be an incomplete mitigation:

Sounds better than no solution!

> -people can use the photo id field instead

Size limit can be enforced.

> -people can use valid e-mail addresses under an own domain ("catch-all")

As long as it can validate, seems fine to me. Better than no verification.

> -your keyserver suddenly can be abused for email spamming

Any online service that allows registrations can be abused for email
spamming, if you consider registration emails an "email spam".



Another limitation: you cannot apply the email verification process to the
recon algo, because the user would get flooded with verification emails.
That means you could have a malicious SKS implementation flooding others
with non-verified emails. Again, not perfect, but a good start.



On Sat, Jul 14, 2018 at 2:50 AM, Tobias Frei 
wrote:

> Hi Ryan,
>
> that would probably be an incomplete mitigation:
>
> -people can use the photo id field instead
> -people can use valid e-mail addresses under an own domain ("catch-all")
> -your keyserver suddenly can be abused for email spamming
>
> Best regards
> Tobias Frei
>
>
>
> Am 14.07.2018 um 02:57 schrieb Ryan Hunt:
>
>> Could this be mitigated by validating email addresses as they come in?
>> Like sending an encrypted mail to the said address with a return token, If
>> the token is not provided the key is never put into the SKS rotation?
>>
>> I think a solution like this would be much more effective, and if there
>> was some desire to conform to GDPR at some point it would be pretty much
>> required first step because I cannot see how we could possibly remove keys
>> without a command signed by that key, and putting this in place would make
>> that ‘no more difficult to remove than it was to add’..
>>
>> Regards,
>> -Ryan Hunt
>>
>> On Jul 13, 2018, at 11:20 AM, Phil Pennock 
>>> wrote:
>>>
>>> Signed PGP part
>>> Heads-up:
>>>
>>> https://medium.com/@mdrahony/are-pgp-key-servers-breaking-th
>>> e-law-under-the-gdpr-a81ddd709d3e
>>> https://github.com/yakamok/keyserver-fs
>>> https://lobste.rs/s/sle0o4/are_pgp_key_servers_breaking_law_under
>>>
>>> This `keyserver-fs` is software to attack SKS, using it as a filesystem,
>>> in
>>> what appears to be a deliberate attack on the viability of continuing to
>>> run a keyserver.
>>>
>>> The author is upset that there's no deletion, so is pissing in the pool.
>>>
>>> -Phil
>>>
>>>
>>>
>>
>> ___
>> Sks-devel mailing list
>> Sks-devel@nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/sks-devel
>>
>>
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel
>
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

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

[Tobias Frei]

Hi Ryan,

that would probably be an incomplete mitigation:

-people can use the photo id field instead
-people can use valid e-mail addresses under an own domain ("catch-all")
-your keyserver suddenly can be abused for email spamming

Best regards
Tobias Frei


Am 14.07.2018 um 02:57 schrieb Ryan Hunt:

Could this be mitigated by validating email addresses as they come in? Like 
sending an encrypted mail to the said address with a return token, If the token 
is not provided the key is never put into the SKS rotation?

I think a solution like this would be much more effective, and if there was 
some desire to conform to GDPR at some point it would be pretty much required 
first step because I cannot see how we could possibly remove keys without a 
command signed by that key, and putting this in place would make that ‘no more 
difficult to remove than it was to add’..

Regards,
-Ryan Hunt


On Jul 13, 2018, at 11:20 AM, Phil Pennock  wrote:

Signed PGP part
Heads-up:

https://medium.com/@mdrahony/are-pgp-key-servers-breaking-the-law-under-the-gdpr-a81ddd709d3e
https://github.com/yakamok/keyserver-fs
https://lobste.rs/s/sle0o4/are_pgp_key_servers_breaking_law_under

This `keyserver-fs` is software to attack SKS, using it as a filesystem, in
what appears to be a deliberate attack on the viability of continuing to
run a keyserver.

The author is upset that there's no deletion, so is pissing in the pool.

-Phil





___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel



___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

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

[Ryan Hunt]

Could this be mitigated by validating email addresses as they come in? Like 
sending an encrypted mail to the said address with a return token, If the token 
is not provided the key is never put into the SKS rotation?

I think a solution like this would be much more effective, and if there was 
some desire to conform to GDPR at some point it would be pretty much required 
first step because I cannot see how we could possibly remove keys without a 
command signed by that key, and putting this in place would make that ‘no more 
difficult to remove than it was to add’..

Regards,
-Ryan Hunt

> On Jul 13, 2018, at 11:20 AM, Phil Pennock  
> wrote:
> 
> Signed PGP part
> Heads-up:
> 
> https://medium.com/@mdrahony/are-pgp-key-servers-breaking-the-law-under-the-gdpr-a81ddd709d3e
> https://github.com/yakamok/keyserver-fs
> https://lobste.rs/s/sle0o4/are_pgp_key_servers_breaking_law_under
> 
> This `keyserver-fs` is software to attack SKS, using it as a filesystem, in
> what appears to be a deliberate attack on the viability of continuing to
> run a keyserver.
> 
> The author is upset that there's no deletion, so is pissing in the pool.
> 
> -Phil
> 
> 


___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

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

[Tom at FlowCrypt]

I would have loved to write an alternative SKS implementation that
addresses the issues we were seeing recently. However, this:

   - Set Reconciliation with Nearly Optimal Communication Complexity
   
   - Practical Set Reconciliation
   


is preventing me from doing so. I'm a software engineer, not a
mathematician, and I have little willingness to attempt implementing an
algorithm nobody understands.

I wish the title said "simple" and "resilient" rather than "with nearly
optimal communication complexity", and the contents matched the title.

The pool of engineers willing and able to get us out of this mess would be
much larger.

On Fri, Jul 13, 2018 at 11:23 PM, Andrew Gallagher 
wrote:

>
> > On 13 Jul 2018, at 22:43, Moritz Wirth  wrote:
> >
> > FWIW, has anybody even started working on a fix for any of the bugs?
>
> There has been a fair bit of discussion, but no consensus has been
> reached, apart from a general agreement that major changes to the recon
> model will be required, and that these will be necessarily
> backwards-incompatible. That’s generally where the discussion dries up.
>
> I get the impression that everyone is holding fire until there is some
> sign that one particular form of breakage will be more broadly acceptable
> than the others.
>
> A
>
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel
>
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

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

[Andrew Gallagher]

> On 13 Jul 2018, at 22:43, Moritz Wirth  wrote:
> 
> FWIW, has anybody even started working on a fix for any of the bugs?

There has been a fair bit of discussion, but no consensus has been reached, 
apart from a general agreement that major changes to the recon model will be 
required, and that these will be necessarily backwards-incompatible. That’s 
generally where the discussion dries up. 

I get the impression that everyone is holding fire until there is some sign 
that one particular form of breakage will be more broadly acceptable than the 
others.

A

___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

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

[Moritz Wirth]

FWIW, has anybody even started working on a fix for any of the bugs?


Am 13.07.18 um 21:52 schrieb Robert J. Hansen:
>> Sad but not surprised. Thanks for all your time and effort. It has been much 
>> appreciated. 
> Yes.
>
>> I am reluctant to declare defeat, but this calls for a tactical retreat and 
>> regroup. 
> Yes.
>
> There's a certain dark lesson to be learned here.  The keyserver network
> was designed in the anticipation that governments and/or intelligence
> agencies were the principal threat.
>
> The principal threat is actually our own users.  And that's a hell of a
> demoralizing thing for a volunteer network.
>
> "And I lift my glass to the Awful Truth,
>  Which cannot be revealed to the ears of youth
>  Except to say it isn't worth a dime."
>
>   -- Leonard Cohen, _Closing Time_
>
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel




signature.asc
Description: OpenPGP digital signature
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

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

[Robert J. Hansen]

> Sad but not surprised. Thanks for all your time and effort. It has been much 
> appreciated. 

Yes.

> I am reluctant to declare defeat, but this calls for a tactical retreat and 
> regroup. 

Yes.

There's a certain dark lesson to be learned here.  The keyserver network
was designed in the anticipation that governments and/or intelligence
agencies were the principal threat.

The principal threat is actually our own users.  And that's a hell of a
demoralizing thing for a volunteer network.

"And I lift my glass to the Awful Truth,
 Which cannot be revealed to the ears of youth
 Except to say it isn't worth a dime."

-- Leonard Cohen, _Closing Time_

___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

[Sks-devel] dump_new_only and modified keys

[William Hay]

Does the -dump_new_only option dump keys that are in an existing keydump
file but have changed (eg new sigs since it was dumped the first time)?

Thanks in advance

Bill 


signature.asc
Description: PGP signature
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

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

[Andrew Gallagher]

Phil,

Sad but not surprised. Thanks for all your time and effort. It has been much 
appreciated. 

For myself, whippet.andrewg.com has been broken for several weeks now and I’m 
not sure I have the heart to go to the effort of restoring it only for it to be 
clobbered again. I am reluctant to declare defeat, but this calls for a 
tactical retreat and regroup. 

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 third 
party sigs) is the absolute maximum functionality we can hope to sustain in the 
long term. And for this to be bulletproof, all such material must be 
cryptographically verified (otherwise people could just create “random” key 
material containing arbitrary data).

Providing search by uid appears to be a lost cause. DNS, WKD and proprietary 
services like keybase are probably the only way this can be done without 
opening pandora’s box. 

Andrew Gallagher

> On 13 Jul 2018, at 18:34, Phil Pennock  wrote:
> 
> Folks, with immediate effect, I am withdrawing sks.spodhuis.org from
> service and it will not be returning in its current form.
> 
> I am about to disable the DNS in spodhuis.org, while leaving the SKS
> service itself running, so that clients using pools will not be
> adversely impacted.  I'll give it a few hours for pools to update and
> caches to expire, before turning off SKS itself.
> 
> I have already disabled SKS recon.
> 
> It's been an educational ride.
> 
> I'm willing to fight jurisdictional overreach, but with Yet Another
> Attack Tool to abuse the resources which I provide out of my pocket,
> combined with large chunks of the traffic appearing to be to support
> operational incompetence by certain software publishers, I don't see
> that I'm successfully spending my money to good effect, supporting a
> community of users who care about verifiable integrity and some privacy.
> 
> With the latest attack tool providing for generic filesystem storage
> such that attaching a file doesn't even require understanding how to use
> a user-attribute packet, the threat of KP upload has just increased by
> an order of magnitude.  I'm not willing to be part of that.
> 
> My key remains available at the URL in the OpenPGP: header of all my
> emails, and via finger: (for my name @ my domain).  I'll explore WKD
> again, sometime later this year.
> 
> Regards,
> -Phil, surrendering
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel


___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

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

[Matthew Walster]

This is why we can't have nice things.

M

On Fri, 13 Jul 2018, 19:20 Phil Pennock, 
wrote:

> Heads-up:
>
>
> https://medium.com/@mdrahony/are-pgp-key-servers-breaking-the-law-under-the-gdpr-a81ddd709d3e
>  https://github.com/yakamok/keyserver-fs
>  https://lobste.rs/s/sle0o4/are_pgp_key_servers_breaking_law_under
>
> This `keyserver-fs` is software to attack SKS, using it as a filesystem, in
> what appears to be a deliberate attack on the viability of continuing to
> run a keyserver.
>
> The author is upset that there's no deletion, so is pissing in the pool.
>
> -Phil
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel
>
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

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

[Phil Pennock]

Folks, with immediate effect, I am withdrawing sks.spodhuis.org from
service and it will not be returning in its current form.

I am about to disable the DNS in spodhuis.org, while leaving the SKS
service itself running, so that clients using pools will not be
adversely impacted.  I'll give it a few hours for pools to update and
caches to expire, before turning off SKS itself.

I have already disabled SKS recon.

It's been an educational ride.

I'm willing to fight jurisdictional overreach, but with Yet Another
Attack Tool to abuse the resources which I provide out of my pocket,
combined with large chunks of the traffic appearing to be to support
operational incompetence by certain software publishers, I don't see
that I'm successfully spending my money to good effect, supporting a
community of users who care about verifiable integrity and some privacy.

With the latest attack tool providing for generic filesystem storage
such that attaching a file doesn't even require understanding how to use
a user-attribute packet, the threat of KP upload has just increased by
an order of magnitude.  I'm not willing to be part of that.

My key remains available at the URL in the OpenPGP: header of all my
emails, and via finger: (for my name @ my domain).  I'll explore WKD
again, sometime later this year.

Regards,
-Phil, surrendering


signature.asc
Description: Digital signature
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

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

[Phil Pennock]

Heads-up:

 
https://medium.com/@mdrahony/are-pgp-key-servers-breaking-the-law-under-the-gdpr-a81ddd709d3e
 https://github.com/yakamok/keyserver-fs
 https://lobste.rs/s/sle0o4/are_pgp_key_servers_breaking_law_under

This `keyserver-fs` is software to attack SKS, using it as a filesystem, in
what appears to be a deliberate attack on the viability of continuing to
run a keyserver.

The author is upset that there's no deletion, so is pissing in the pool.

-Phil


signature.asc
Description: Digital signature
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] broken node

[Michael Jones]

Hi,

I was away on work, came back to one of nodes I host ran out of disk space.

Users of the service would not have been effected as this node doesn't
serve web traffic other than the default key stats page.

And keys would have continued to sync via a backup node.

Node is back in and fixed.

(this is for the service at sks.mj2.uk)

Kind Regards,
Mike


___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel