[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

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
again, sometime later this year.
Regards,
-Phil, surrendering
_______________________________________________
Sks-devel mailing list
https://lists.nongnu.org/mailman/listinfo/sks-devel

[Robert J. Hansen]

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

Yes.

Post by Andrew Gallagher
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_

[Moritz Wirth]

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

Post by Robert J. Hansen

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

Yes.

Post by Andrew Gallagher
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
https://lists.nongnu.org/mailman/listinfo/sks-devel

[Andrew Gallagher]

Post by Moritz Wirth
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

[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
<http://ipsit.bu.edu/documents/ieee-it3-web.pdf>
- Practical Set Reconciliation
<http://ipsit.bu.edu/documents/BUTR2002-01.ps>


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.

Post by Andrew Gallagher

Post by Moritz Wirth
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
https://lists.nongnu.org/mailman/listinfo/sks-devel

[Moritz Wirth]

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

Post by Tom at FlowCrypt
I would have loved to write an alternative SKS implementation that
* Set Reconciliation with Nearly Optimal Communication Complexity
<http://ipsit.bu.edu/documents/ieee-it3-web.pdf>
* Practical Set Reconciliation
<http://ipsit.bu.edu/documents/BUTR2002-01.ps>
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

Post by Moritz Wirth
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
https://lists.nongnu.org/mailman/listinfo/sks-devel
<https://lists.nongnu.org/mailman/listinfo/sks-devel>

[Human at FlowCrypt]

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 mechanism where some
implementations could seamlessly choose not to import certain keys, I think
hockeypuck would be a great alternative. It may need to be forked.

Post by Moritz Wirth
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
I would have loved to write an alternative SKS implementation that
- Set Reconciliation with Nearly Optimal Communication Complexity
<http://ipsit.bu.edu/documents/ieee-it3-web.pdf>
- Practical Set Reconciliation
<http://ipsit.bu.edu/documents/BUTR2002-01.ps>
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.

Post by Andrew Gallagher

Post by Moritz Wirth
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
https://lists.nongnu.org/mailman/listinfo/sks-devel

[Human at FlowCrypt]

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.

Post by Human at FlowCrypt
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 mechanism where some
implementations could seamlessly choose not to import certain keys, I think
hockeypuck would be a great alternative. It may need to be forked.

Post by Moritz Wirth
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
I would have loved to write an alternative SKS implementation that
- Set Reconciliation with Nearly Optimal Communication Complexity
<http://ipsit.bu.edu/documents/ieee-it3-web.pdf>
- Practical Set Reconciliation
<http://ipsit.bu.edu/documents/BUTR2002-01.ps>
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.

Post by Andrew Gallagher

Post by Moritz Wirth
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
https://lists.nongnu.org/mailman/listinfo/sks-devel

[Human at FlowCrypt]

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.

Post by Human at FlowCrypt
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.

Post by Human at FlowCrypt
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 mechanism where some
implementations could seamlessly choose not to import certain keys, I think
hockeypuck would be a great alternative. It may need to be forked.

Post by Moritz Wirth
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
I would have loved to write an alternative SKS implementation that
- Set Reconciliation with Nearly Optimal Communication Complexity
<http://ipsit.bu.edu/documents/ieee-it3-web.pdf>
- Practical Set Reconciliation
<http://ipsit.bu.edu/documents/BUTR2002-01.ps>
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.

Post by Andrew Gallagher

Post by Moritz Wirth
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
https://lists.nongnu.org/mailman/listinfo/sks-devel

[Daniel Roesler]

Does anyone in the pool run hockeypuck? How compatible is its recon
with others running sks-keyserver?

Daniel

Post by Human at FlowCrypt
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.

Post by Human at FlowCrypt
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.

Post by Human at FlowCrypt
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 mechanism where some
implementations could seamlessly choose not to import certain keys, I think
hockeypuck would be a great alternative. It may need to be forked.

Post by Moritz Wirth
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
I would have loved to write an alternative SKS implementation that
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.

Post by Andrew Gallagher

Post by Moritz Wirth
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
https://lists.nongnu.org/mailman/listinfo/sks-devel

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

[Haw Loeung]

Post by Andrew Gallagher
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).

If it helps others, we have a patched SKS packaged to exclude the bad
key (one of them at least)[1]. A couple of others in my team did all
the work so I can't comment on the details.

There's also work being done to spin up a few SKS servers to trial
hockeypuck.


Regards,

Haw


[1]https://launchpad.net/~canonical-sysadmins/+archive/ubuntu/sks-public

[Haw Loeung]

Post by Haw Loeung

Post by Andrew Gallagher
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).

If it helps others, we have a patched SKS packaged to exclude the bad
key (one of them at least)[1]. A couple of others in my team did all
the work so I can't comment on the details.

I should also add, you'll then need to drop the key from the DB with:

$ sks drop 8C070D00D81E934B3C79247175E6B4BC


Regards,

Haw

[Tom at FlowCrypt]

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 pool because "SKS version < 1.1.6" as per
https://sks-keyservers.net/status/ks-status.php?server=keyserver.snt.utwente.nl

It does seem to be syncing well - key diff 1,385 looks great to me even
compared to servers that are in the pool.

I'm adding Robert in copy in case he's able to share his experience running
the Hockeypuck server. Robert, if this email can reach you, We'd be
interested to know how is the server coping with recent issues that were
affecting the SKS network? How stable do you find Hockeypuck overall, how
much dev-ops do you need to do?

Post by Haw Loeung

Post by Andrew Gallagher
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).

If it helps others, we have a patched SKS packaged to exclude the bad
key (one of them at least)[1]. A couple of others in my team did all
the work so I can't comment on the details.

$ sks drop 8C070D00D81E934B3C79247175E6B4BC
Regards,
Haw
_______________________________________________
Sks-devel mailing list
https://lists.nongnu.org/mailman/listinfo/sks-devel

[Moritz Wirth]

Hi Tom,

I spend the night on the keydump - keys.flanga.io is now also running
with hockeypuck (I did not test anything to be honest though ;)). I'll
see if it runs stable (not sure if it is pool compatible) - version is
1.1.6.

A short write-up for installing this thing is already done - I can send
the link if it works ;)

The server is only peering with my own instances right now - however it
looks like recon has a problem with the filters of sks (which should not
be a big deal)..

{filters do not match.\n\tlocal filters: [ yminsky.dedup yminsky.merge
]\n\tremote filters: [ yminsky.dedup  yminsky.merge ]} {remote rejected
configuration}]" label="serve :11370"

Best regards,

Moritz

Post by Daniel Roesler
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 pool because "SKS version < 1.1.6"
as
per https://sks-keyservers.net/status/ks-status.php?server=keyserver.snt.utwente.nl
It does seem to be syncing well - key diff 1,385 looks great to me
even compared to servers that are in the pool.
I'm adding Robert in copy in case he's able to share his experience
running the Hockeypuck server. Robert, if this email can reach you,
We'd be interested to know how is the server coping with recent issues
that were affecting the SKS network? How stable do you find Hockeypuck
overall, how much dev-ops do you need to do?

Post by Daniel Roesler

Post by Andrew Gallagher
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

Post by Daniel Roesler

Post by Andrew Gallagher
and revocations (no id packets, no third party sigs) is the

absolute

Post by Daniel Roesler

Post by Andrew Gallagher
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).

If it helps others, we have a patched SKS packaged to exclude

the bad

Post by Daniel Roesler
key (one of them at least)[1]. A couple of others in my team did all
the work so I can't comment on the details.

$ sks drop 8C070D00D81E934B3C79247175E6B4BC
Regards,
Haw
_______________________________________________
Sks-devel mailing list
https://lists.nongnu.org/mailman/listinfo/sks-devel
<https://lists.nongnu.org/mailman/listinfo/sks-devel>
_______________________________________________
Sks-devel mailing list
https://lists.nongnu.org/mailman/listinfo/sks-devel

[Shengjing Zhu]

Hi Haw,

Post by Haw Loeung

Post by Andrew Gallagher
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).

If it helps others, we have a patched SKS packaged to exclude the bad
key (one of them at least)[1]. A couple of others in my team did all
the work so I can't comment on the details.

Could you provide the patch on bitbucket[1], I'm not sure if Kristian
will accpet it or not.
But I'd like to see it in patch form and include it in my own build.

[1] https://bitbucket.org/skskeyserver/sks-keyserver/

[Tobias Frei]

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 avoid trying to fix symptoms. Go for the root
issue, even if it hurts. Don't deny that it does; the whole design of what
you have been taking for granted when you learned about PGP needs to be
fundamentally rewritten. Until that has happened, I personally believe that
every (!) key server administrator should shut down their keyservers, with
no exception.

Users, especially commercial ones, are very welcome to notice the impact of
the sudden lack of a convenient, free service provided as a voluntary
donation by people who are risking their freedom and risking going to jail,
on the users' daily work. Users are very welcome to finally notice the
problem as well, and users are very welcome to contribute suggestions and
code to the further fixing of the fundamentally flawed keyserver network
design.

My personal suggestion: Complete pool shutdown until the underlying problem
is completely fixed. If it can't be fixed, keep the pool offline. It has
been a good, happy time, and one of the next steps can (doesn't have to!)
be realizing that it has irrevocably reached its end.

PGP works without keyservers, by the way. It can't be bad for users to
finally learn how.

Best regards
Tobias Frei

[Haw Loeung]

Post by Shengjing Zhu
Could you provide the patch on bitbucket[1], I'm not sure if Kristian
will accpet it or not.
But I'd like to see it in patch form and include it in my own build.

I don't think these patches should land in SKS. It's to work around
one key and doesn't scale very well. Instead, I think more work should
be done adding the ability to not accept and send keys of a certain
size as well as options to exclude specific list of keys. I'm not sure
if there's another mailing list used by SKS developers to discuss
this.

If you're interested in the patches, you should be able to download
the *.debian.tar.xz file from the link below:

| https://launchpad.net/~canonical-sysadmins/+archive/ubuntu/sks-public/+packages

Extract that and the series of patches to-date are:

| 0012-poison-key.patch
| poison-key-id-update
| 0014-poison-key-output-fix
| 0091-pjdc-compare-short-keyid.patch


Regards,

Haw

[Shengjing Zhu]

Post by Haw Loeung
I don't think these patches should land in SKS. It's to work around
one key and doesn't scale very well. Instead, I think more work should
be done adding the ability to not accept and send keys of a certain
size as well as options to exclude specific list of keys. I'm not sure
if there's another mailing list used by SKS developers to discuss
this.

Thanks, I see the patches hard code key id, so I think it shouldn't land in
upstream too.

Post by Haw Loeung
If you're interested in the patches, you should be able to download
| https://launchpad.net/~canonical-sysadmins/+archive/ubuntu/sks-public/+packages
| 0012-poison-key.patch
| poison-key-id-update
| 0014-poison-key-output-fix
| 0091-pjdc-compare-short-keyid.patch

I don't know ocaml, but these patches are in a mess, shouldn't it be
simplified to,

diff --git a/keydb.ml b/keydb.ml
index 949a1f4..7ff976a 100644
--- a/keydb.ml
+++ b/keydb.ml
@@ -1166,6 +1166,11 @@ struct
try
if has_hash hash then [] else
let keyid = Fingerprint.keyid_from_key ~short:true key in
+ let keyid_long = Fingerprint.keyid_to_string ~short:false (Fingerprint.keyid_from_key ~short:false key) in
+
+ (* Blacklist poison key - RT#112669 *)
+ plerror 4 "considering keyid %s" keyid_long;
+ if List.mem keyid_long ["E41ED3A107A7DBC7"] then [] else
let potential_merges = List.filter ~f:(fun x -> x <> key)
(get_by_short_keyid keyid)
in

[Chris Boot]

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

My server is down today for reasons unrelated to SKS and it has dropped
out of the SKS pool as a result. I can't bring my server back for
several hours and I will not be bringing SKS back up at all.

Given the recent queries around GDPR and the significant technical
issues with abuse of the SKS ecosystem, I can't keep on. My server and
Internet connection have been run into the ground with the recent abuse
issues and I've been uncomfortable with the potential legal implications
surrounding GDPR, so it's time to pull out.

Once these issues have been ironed out then I will certainly be
interested in contributing resources towards a keyserver effort, but I
can't help but think that SKS is no longer a viable solution to the problem.

Cheers,
Chris

[Pete Stephenson]

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

Hi all,

I'm afraid I must also follow in Phil's footsteps and shut down my
server, ams.sks.heypete.com, effective immediately.

Like Phil, I'm happy to fight jurisdictional overreach and provide
service to the community at large, even in the face of large CPU and
bandwidth demands.

However, the one resource that is a limited commodity on my server is
storage and while I'm perfectly willing to shoulder that cost for the
keyserver-using community, even in the face of some attacks, the recent
storage-wasting attacks are consuming all of my server's storage
capacity (including the extra space I've allocated to compensate). The
excessive consumption of storage is disrupting the server's other
services, which is problematic.

Unfortunately, this is not sustainable for me from a financial or
administrative standpoint and so it is with great regret I must shut
down the server.

I ask that anyone peering with my server (I've BCC'ed the admins of the
servers that peer with my server in this email) please de-peer with my
server.

That said, I will remain subscribed to the list and will be happy to
contribute in any way I can, including being willing to operate a public
server again once things can be made more robust.

Cheers!
-Pete