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

[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


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?
>
> 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?
>
>
>
>
> On Sun, Jul 15, 2018 at 1:21 AM, Haw Loeung  > 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
> 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



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

[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
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

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

[Shengjing Zhu]

Hi Haw,

On Sun, Jul 15, 2018 at 9:17 AM Haw Loeung  wrote:
>
> On Fri, Jul 13, 2018 at 07:53:01PM +0100, Andrew Gallagher wrote:
> > I am still willing to help with possible upgrades and/or
> > replacements for the SKS network. At this point I have come to
> > believe that a minimal network 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
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] 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?

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?




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

[Haw Loeung]

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


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

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

___
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

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

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

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

[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


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
> mailto:andr...@andrewg.com>> 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

[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

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

[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