withdrawal of service: sks.spodhuis.org

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

withdrawal of service: sks.spodhuis.org

Phil Pennock-17
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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc (1015 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/sks-devel


_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: withdrawal of service: sks.spodhuis.org

Robert J. Hansen-3
> 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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: withdrawal of service: sks.spodhuis.org

Moritz Wirth-2
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
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/sks-devel


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

signature.asc (876 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: withdrawal of service: sks.spodhuis.org

Andrew Gallagher

> On 13 Jul 2018, at 22:43, Moritz Wirth <[hidden email]> 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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: 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:
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 <[hidden email]> wrote:

> On 13 Jul 2018, at 22:43, Moritz Wirth <[hidden email]> 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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel


_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: withdrawal of service: sks.spodhuis.org

Moritz Wirth-2

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 would have loved to write an alternative SKS implementation that addresses the issues we were seeing recently. However, this:
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 <[hidden email]> wrote:

> On 13 Jul 2018, at 22:43, Moritz Wirth <[hidden email]> 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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel



_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: withdrawal of service: sks.spodhuis.org

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. 


On Sat, Jul 14, 2018, 19:33 Moritz Wirth <[hidden email]> wrote:

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 would have loved to write an alternative SKS implementation that addresses the issues we were seeing recently. However, this:
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 <[hidden email]> wrote:

> On 13 Jul 2018, at 22:43, Moritz Wirth <[hidden email]> 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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel



_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: withdrawal of service: sks.spodhuis.org

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. 

On Sat, Jul 14, 2018, 20:16 Human at FlowCrypt <[hidden email]> wrote:
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. 


On Sat, Jul 14, 2018, 19:33 Moritz Wirth <[hidden email]> wrote:

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 would have loved to write an alternative SKS implementation that addresses the issues we were seeing recently. However, this:
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 <[hidden email]> wrote:

> On 13 Jul 2018, at 22:43, Moritz Wirth <[hidden email]> 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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel



_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: withdrawal of service: sks.spodhuis.org

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.

On Sat, Jul 14, 2018 at 12:19 PM, Human at FlowCrypt <[hidden email]> wrote:
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 <[hidden email]> wrote:
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. 


On Sat, Jul 14, 2018, 19:33 Moritz Wirth <[hidden email]> wrote:

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 would have loved to write an alternative SKS implementation that addresses the issues we were seeing recently. However, this:
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 <[hidden email]> wrote:

> On 13 Jul 2018, at 22:43, Moritz Wirth <[hidden email]> 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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel




_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: withdrawal of service: sks.spodhuis.org

Daniel Roesler
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 <[hidden email]> wrote:

> 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, Jul 14, 2018 at 12:19 PM, Human at FlowCrypt <[hidden email]>
> wrote:
>>
>> 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 <[hidden email]>
>> wrote:
>>>
>>> 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.
>>>
>>>
>>> On Sat, Jul 14, 2018, 19:33 Moritz Wirth <[hidden email]> wrote:
>>>>
>>>> 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 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 <[hidden email]>
>>>> wrote:
>>>>>
>>>>>
>>>>> > On 13 Jul 2018, at 22:43, Moritz Wirth <[hidden email]> 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
>>>>> [hidden email]
>>>>> https://lists.nongnu.org/mailman/listinfo/sks-devel
>>>>
>>>>
>>>>
>
>
> _______________________________________________
> Sks-devel mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/sks-devel
>

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: withdrawal of service: sks.spodhuis.org

Haw Loeung
In reply to this post by Andrew Gallagher
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 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

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

signature.asc (235 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: withdrawal of service: sks.spodhuis.org

Haw Loeung
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 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

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

signature.asc (235 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: withdrawal of service: sks.spodhuis.org

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



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?




On Sun, Jul 15, 2018 at 1:21 AM, Haw Loeung <[hidden email]> wrote:
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 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

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



_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: withdrawal of service: sks.spodhuis.org

Shengjing Zhu
In reply to this post by Haw Loeung
Hi Haw,

On Sun, Jul 15, 2018 at 9:17 AM Haw Loeung <[hidden email]> 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 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/


--
Regards,
Shengjing Zhu

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: withdrawal of service: sks.spodhuis.org

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

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: withdrawal of service: sks.spodhuis.org

Moritz Wirth-2
In reply to this post by Tom at FlowCrypt

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


Am 15.07.18 um 04:31 schrieb Tom at FlowCrypt:
> Does anyone in the pool run hockeypuck? How compatible is its recon with others running sks-keyserver?



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?




On Sun, Jul 15, 2018 at 1:21 AM, Haw Loeung <[hidden email]> wrote:
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 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

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




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


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

signature.asc (876 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: withdrawal of service: sks.spodhuis.org

Haw Loeung
In reply to this post by Shengjing Zhu
On Sun, Jul 15, 2018 at 11:37:05AM +0800, Shengjing Zhu wrote:
> 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

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

signature.asc (235 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

sks patch to refuse poison key

Shengjing Zhu
On Sun, Jul 15, 2018 at 06:28:24PM +1000, Haw Loeung wrote:
> 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.

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

--
Best regards,
Shengjing Zhu

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

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

withdrawal of service: sks.boo.tc / sks.bootc.eu

Chris Boot-2
In reply to this post by Phil Pennock-17
On 13/07/18 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.

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

--
Chris Boot
[hidden email]


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

signature.asc (981 bytes) Download Attachment
12