Re: Lying about Hockeypuck being SKS?

[Andrew Gallagher]

On 22/03/2021 22:02, Ryan Hunt wrote:


However I’d like to see some efforts made towards:
  - Rolling our SKS hacks back upstream with HP, initially this seems 
stupid but HP has already put in efforts to maintain compatibility with 
SKS peers.. I think a transitional SKS emulation mode that is easy to 
implement and maintain upstream is worthwhile, especially if we can come 
up with a plan to deprecate this nonsense down the road and its just to 
get us through the near future.


There is still a lot of traffic coming in to the pool, and it's become a 
running theme in the PGP space to have archaic software still in 
production use. However even when there were only three nodes in the 
pool earlier today, pgpkeys.eu didn't break a sweat serving its share.


There is a strong argument that it is better to break things entirely so 
that people still using old software don't have a false sense of 
security. But I really dislike the idea of breaking things without 
building the replacement first.


I’m thinking like a dedicated machine readable status/health 
API endpoint that the server can sign with its own key and the pool 
provider can verify its the server it claims to be, and make 
accommodations for blacklisted/removed keys/max key sizes/etc accounting 
for variations in key counts.


+1

TBH I think creating our own pool is likely our best option going 
forward, yeah it’ll take some time (ie years) before Distros and the 
various PGP clients come back.. but most of em that I used personally 
that came out the box w/the SKS pool no longer do so I think the damage 
has long been done.


I think the idea of a self-organising pool has some fundamental flaws. 
As was pointed out in another thread, it would be relatively easy for a 
malefactor to set up a few new pool nodes and then artificially inflate 
their key count in order to exclude honest operators. Even as an 
otherwise well-behaved member, it's possible for an operator to gather a 
log of IP addresses vs keys searched, in order to build a contacts graph 
(for the record, pgpkeys.eu permanently deletes its logs on a short 
cycle, currently <=48h and likely to decrease in the near future).


Tor is one way to address this, but it is not suitable for everyone. So 
running a keyserver comes with a requirement of trust and reputation, 
because privacy and security are not the same thing, and must sometimes 
be balanced.


My own view of the medium-term future is that there will be a diversity 
of keyserver operators that will not agree on everything (e.g. policy 
blacklists, data retention) and we have to find a way to coexist. The 
SKS pool structure is based on the assumption that there is one notional 
"complete" (if time-dependent) dataset, and all keyservers will tend to 
converge towards it. That was always a fragile assumption, and we should 
be working to make it unnecessary, so that individual operators can 
choose to what extent they wish to stay in sync with others.


Currently, we have a number of disconnected "big" keyserver operators 
(keys.openpgp.org, mailvelope, keybase, ubuntu...), but I don't believe 
it is user-friendly to expect non-experts to worry about which 
keyservers to publish to or fetch from. I hope to see them all back in 
communion with each other, even if only to distribute the bare minimum 
such as key revocations. This will by necessity have to be an open (and 
preferably well-defined) protocol, and it would be nice to have two or 
three independent implementations, but one step at a time.


So I suspect we'll end up with something more akin to DNS, where there 
are a smaller number of "root" servers, and then individual 
organisations can set up their own instances that field internal 
requests (thereby minimising behaviour leakage) but also sync with the 
roots. Individual users can choose to talk to whichever keyserver has 
the best reputation, rather than relying on a random pool member to be 
an honest one.


--
Andrew Gallagher



OpenPGP_signature
Description: OpenPGP digital signature

Re: Lying about Hockeypuck being SKS?

[Martin Dobrev]

I did this earlier for keyserver.dobrev.eu.

On 23/03/2021 09:37, Andrew Gallagher wrote:
> On 23/03/2021 09:19, Marcel Waldvogel wrote:
>> How about instead of claiming to be "SKS", Hockeypuck servers just
>> claim to be "Hockeypuck" (title case instead of lower case)? That
>> would be kind of a "white(list) lie". They will have a red cell, but
>> that will not preclude their
>
> Sounds good to me, will change that on pgpkeys.eu now.
>

Re: Lying about Hockeypuck being SKS?

[Andrew Gallagher]

On 23/03/2021 09:19, Marcel Waldvogel wrote:
How about instead of claiming to be "SKS", Hockeypuck servers just claim 
to be "Hockeypuck" (title case instead of lower case)? That would be 
kind of a "white(list) lie". They will have a red cell, but that will 
not preclude their


Sounds good to me, will change that on pgpkeys.eu now.

--
Andrew Gallagher



OpenPGP_signature
Description: OpenPGP digital signature

Re: Lying about Hockeypuck being SKS?

[Marcel Waldvogel]

pgpkeys.eu is in the pool, however, the "Software" table cell is red.
Further investigation showed that they spell "sks" in lower case,
unlike the real SKS.

Verifying against the source code [1], the server selection code is a
blacklist: "SKS" < 1.1.6, "GnuKS", and "hockeypuck" are blacklisted
(case-sensitive).

How about instead of claiming to be "SKS", Hockeypuck servers just
claim to be "Hockeypuck" (title case instead of lower case)? That would
be kind of a "white(list) lie". They will have a red cell, but that
will not preclude their

I have changed my Hockeypucks to return this version and will check in
30 minutes whether the theory can be corroborated.

Happy keyserving,
-Marcel

[1] 
https://git.sumptuouscapital.com/?p=sks-keyservers-pool.git;a=blob;f=sks-keyservers.net/status-srv/sks-status.inc.php;h=972bb5b56412ae54b8aade234ea02bb8c9545d45;hb=HEAD#l309

On Mon, 2021-03-22 at 21:13 +0100, Andreas Puls wrote:
> 
> 
> Am 22.03.2021 um 20:41 schrieb Marcel Waldvogel:
> > On Sun, 2021-03-21 at 22:56 +0100, Andreas Puls wrote:
> > > 
> > > I've created now a patch that just replaces in the json export
> > > contact
> > > with server_contact and Total with numkeys.
> > > https://github.com/apuls/hockeypuck/commit/34fbdfcf73b60e6001f3770b86d8750d1c8b5385
> > 
> > Great, thanks! I just merged this. Now my Hockeypuck server appears
> > in
> > the statistics.
> > 
> You're welcome!
> 
> > > In my hockeypuck configuration i've set Version to 1.1.6+ and
> > > Software
> > > to SKS
> > 
> Yeah, i've done it too. :)
> 
> > Hockeypuck is blacklisted in the sks-keyservers.net code, because
> > it
> > was not good enough to be incorporated into the pool when Kristian
> > wrote the code. Now, it seems to be in the same ballpark as SKS.
> > 
> > Asking Kristian to remove the Hockeypuck ban resulted in him
> > explaining
> > that he does not plan to change the code or accept changes;
> > instead, we
> > should set up our own fork of his code.
> > 
> > I think this leaves us with the following ways to progress:
> > 
> > a) We leave it as is, Hockeypuck is fine, but just not in the pool.
> > b) We create a second pool, where Hockeypuck is acceptable (and
> > probably SKS as well).
> > c) We agree that Hockeypuck lying to be SKS is accepted in the
> > pool,
> > and maybe even recommended.
> > 
> > I would favor (c), plus keeping the version number in the 2.x
> > range, so
> > that experts still can tell the difference.
> > 
> b would be great but i think this is a hell of work.
> 
> Since we haven't heard for a while from Kristian and the pool is
> working
> - ok more or less - i would go with option c too. Also with the
> Version
> string 2.x .
> > Opinions?
> We need to fix the peers field which will be reported via options=mr
> to
> meet the requirements from the pool skript.
> 
> > -Marcel
> Br
>    Andreas
> 

Re: Lying about Hockeypuck being SKS?

[Philihp Busby]

I think (c) is fine to keep the pool alive. This community has a devout 
adherence to a tradition of inaction.  I'm not holding my breath for 
(b), but I would be delighted if someone did more than just talk about 
it.


I hold that switching to hkps://keys.openpgp.org is the path forward, 
and we should encourage key owners to verify with it.


On 2021-03-22T20:41:31+0100 Marcel Waldvogel 
 wrote 4.5K bytes:



On Sun, 2021-03-21 at 22:56 +0100, Andreas Puls wrote:


I've created now a patch that just replaces in the json export
contact
with server_contact and Total with numkeys.
https://github.com/apuls/hockeypuck/commit/34fbdfcf73b60e6001f3770b86d8750d1c8b5385


Great, thanks! I just merged this. Now my Hockeypuck server appears in
the statistics.


In my hockeypuck configuration i've set Version to 1.1.6+ and
Software
to SKS


Hockeypuck is blacklisted in the sks-keyservers.net code, because it
was not good enough to be incorporated into the pool when Kristian
wrote the code. Now, it seems to be in the same ballpark as SKS.

Asking Kristian to remove the Hockeypuck ban resulted in him explaining
that he does not plan to change the code or accept changes; instead, we
should set up our own fork of his code.

I think this leaves us with the following ways to progress:

a) We leave it as is, Hockeypuck is fine, but just not in the pool.
b) We create a second pool, where Hockeypuck is acceptable (and
probably SKS as well).
c) We agree that Hockeypuck lying to be SKS is accepted in the pool,
and maybe even recommended.

I would favor (c), plus keeping the version number in the 2.x range, so
that experts still can tell the difference.

Opinions?
-Marcel






signature.asc
Description: PGP signature

Re: Lying about Hockeypuck being SKS?

[Ryan Hunt]

In addition I’ve got an interesting story, last time I seen the SKS keyserver 
pool mentioned outside this group was recently when I got acquired by one of 
the Linux Distros and one of the first steps they wanted all of us to do was 
create PGP keys off our old corp email and submit em to the SKS pool so they 
could start sending us our credentials encrypted w/PGP.. which unfortunately 
the day we all did it the SKS pool was in terrible shape, so I helped the 
majority of my co-workers find a working server because there was like 1 node 
in the pool that day and it was struggling w/the load, it took a few attempts 
to get a key in if you were lucky.

This was only about 5 months ago.. and I knew then the SKS pool was doomed if 
nothing changed ASAP.. unfortunately the same event has made life really busy 
since and I’m only now getting some unallocated space in my head to think about 
this situation and what needs to be done about it.

-Ryan

> On Mar 22, 2021, at 4:16 PM, Martin Dobrev  wrote:
> 
> 
> On 22/03/2021 22:02, Ryan Hunt wrote:
>> I concur with the rest of the sentiment, I think its time to start accepting 
>> HP as a replacement for SKS.. If the sks-pool will not recognize the value 
>> of HP servers I suppose our only recourse is to fake it for the time being.
>> 
>> However I’d like to see some efforts made towards:
>>  - Rolling our SKS hacks back upstream with HP, initially this seems stupid 
>> but HP has already put in efforts to maintain compatibility with SKS peers.. 
>> I think a transitional SKS emulation mode that is easy to implement and 
>> maintain upstream is worthwhile, especially if we can come up with a plan to 
>> deprecate this nonsense down the road and its just to get us through the 
>> near future.
> I stand by this idea. We need to keep the pool running until an improved 
> version gets rolled out.
>>  - Continued pressure to extend the sks-keyserver pools to include HP out 
>> the box, this is the only way we’re going to save it. In its current state 
>> its already being mass purged from the clients.. Lying to the pool to save 
>> the pool seems totally defeating.
> Where are they going? If all major software and OS vendors start running 
> their own keyservers then finding a key becomes harder.
>>  - If it becomes clear the sks-keyserver pool is never going to accept 
>> patches, contributions, whatever it takes to get HP Servers included then 
>> its time to declare it dead, we can’t plan on lying to it until the end of 
>> time and SKS operators are dropping off like flies, and those that are 
>> sticking around struggle to maintain service.
>>  - Start a new pool service, designed to be extensible and start asking the 
>> few clients remaining on the sks-pool to start migrating off.. Technology 
>> stacks have changed quite a bit over the years and this may be less effort 
>> than it seems with standard libraries to interact with cloud DNS services 
>> pretty widespread. HP stats can be machine readable w/JSON, and we’ve got 
>> the opportunity to extend HP specifically to make joining pools more robust, 
>> trusted, and less fragile since I think there’s far more of us here capable 
>> of contributing GoLang over OCaml upstream.. I’m thinking like a dedicated 
>> machine readable status/health API endpoint that the server can sign with 
>> its own key and the pool provider can verify its the server it claims to be, 
>> and make accommodations for blacklisted/removed keys/max key sizes/etc 
>> accounting for variations in key counts.
>> 
>> TBH I think creating our own pool is likely our best option going forward, 
>> yeah it’ll take some time (ie years) before Distros and the various PGP 
>> clients come back.. but most of em that I used personally that came out the 
>> box w/the SKS pool no longer do so I think the damage has long been done.
>> 
> +1
>> I’ve been playing with the Cloudflare DNS API’s of recent and they seem like 
>> they would be well suited to hosting us a Hockeypuck pool, and Cloudflare 
>> has such a favorable stance for internet protection/security I would be 
>> astonished If they pulled the plug on a free account doing Keyserver 
>> pooling.. its more likely the’d be willing to donate some premium features 
>> to the cause than anything if needed.
>> 
>> 
>> Best Regards,
>> -Ryan Hunt
>> 
>>> On Mar 22, 2021, at 1:41 PM, Marcel Waldvogel >> > wrote:
>>> 
>>> On Sun, 2021-03-21 at 22:56 +0100, Andreas Puls wrote:
 
 I've created now a patch that just replaces in the json export contact
 with server_contact and Total with numkeys.
 https://github.com/apuls/hockeypuck/commit/34fbdfcf73b60e6001f3770b86d8750d1c8b5385
  
 
>>> 
>>> Great, thanks! I just merged this. Now my Hockeypuck server appears in the 
>>> statistics.
>>> 
 In my hockeypuck configuration i've set Version to 1.1.6+ and 

Re: Lying about Hockeypuck being SKS?

[Ryan Hunt]

On my Mac here the GPG Keychain app now defaults to hkps://keys.openpgp.org 
, Ubuntu is using their own HP servers now that are 
not joining the pool, and these searches on Github is a bit depressing, lots of 
commits setting the same server as default and/or removing the SKS pool:
https://github.com/search?q=keys.openpgp.org=commits 

https://github.com/search?q=sks-keyservers+removed=commits 




> On Mar 22, 2021, at 4:16 PM, Martin Dobrev  wrote:
> 
> 
> On 22/03/2021 22:02, Ryan Hunt wrote:
>> I concur with the rest of the sentiment, I think its time to start accepting 
>> HP as a replacement for SKS.. If the sks-pool will not recognize the value 
>> of HP servers I suppose our only recourse is to fake it for the time being.
>> 
>> However I’d like to see some efforts made towards:
>>  - Rolling our SKS hacks back upstream with HP, initially this seems stupid 
>> but HP has already put in efforts to maintain compatibility with SKS peers.. 
>> I think a transitional SKS emulation mode that is easy to implement and 
>> maintain upstream is worthwhile, especially if we can come up with a plan to 
>> deprecate this nonsense down the road and its just to get us through the 
>> near future.
> I stand by this idea. We need to keep the pool running until an improved 
> version gets rolled out.
>>  - Continued pressure to extend the sks-keyserver pools to include HP out 
>> the box, this is the only way we’re going to save it. In its current state 
>> its already being mass purged from the clients.. Lying to the pool to save 
>> the pool seems totally defeating.
> Where are they going? If all major software and OS vendors start running 
> their own keyservers then finding a key becomes harder.
>>  - If it becomes clear the sks-keyserver pool is never going to accept 
>> patches, contributions, whatever it takes to get HP Servers included then 
>> its time to declare it dead, we can’t plan on lying to it until the end of 
>> time and SKS operators are dropping off like flies, and those that are 
>> sticking around struggle to maintain service.
>>  - Start a new pool service, designed to be extensible and start asking the 
>> few clients remaining on the sks-pool to start migrating off.. Technology 
>> stacks have changed quite a bit over the years and this may be less effort 
>> than it seems with standard libraries to interact with cloud DNS services 
>> pretty widespread. HP stats can be machine readable w/JSON, and we’ve got 
>> the opportunity to extend HP specifically to make joining pools more robust, 
>> trusted, and less fragile since I think there’s far more of us here capable 
>> of contributing GoLang over OCaml upstream.. I’m thinking like a dedicated 
>> machine readable status/health API endpoint that the server can sign with 
>> its own key and the pool provider can verify its the server it claims to be, 
>> and make accommodations for blacklisted/removed keys/max key sizes/etc 
>> accounting for variations in key counts.
>> 
>> TBH I think creating our own pool is likely our best option going forward, 
>> yeah it’ll take some time (ie years) before Distros and the various PGP 
>> clients come back.. but most of em that I used personally that came out the 
>> box w/the SKS pool no longer do so I think the damage has long been done.
>> 
> +1
>> I’ve been playing with the Cloudflare DNS API’s of recent and they seem like 
>> they would be well suited to hosting us a Hockeypuck pool, and Cloudflare 
>> has such a favorable stance for internet protection/security I would be 
>> astonished If they pulled the plug on a free account doing Keyserver 
>> pooling.. its more likely the’d be willing to donate some premium features 
>> to the cause than anything if needed.
>> 
>> 
>> Best Regards,
>> -Ryan Hunt
>> 
>>> On Mar 22, 2021, at 1:41 PM, Marcel Waldvogel >> > wrote:
>>> 
>>> On Sun, 2021-03-21 at 22:56 +0100, Andreas Puls wrote:
 
 I've created now a patch that just replaces in the json export contact
 with server_contact and Total with numkeys.
 https://github.com/apuls/hockeypuck/commit/34fbdfcf73b60e6001f3770b86d8750d1c8b5385
  
 
>>> 
>>> Great, thanks! I just merged this. Now my Hockeypuck server appears in the 
>>> statistics.
>>> 
 In my hockeypuck configuration i've set Version to 1.1.6+ and Software
 to SKS
>>> 
>>> Hockeypuck is blacklisted in the sks-keyservers.net 
>>>  code, because it was not good enough to be 
>>> incorporated into the pool when Kristian wrote the code. Now, it seems to 
>>> be in the same ballpark as SKS.
>>> 
>>> Asking Kristian to remove the Hockeypuck ban resulted in him explaining 
>>> that he does not plan to change the code or accept changes; instead, we 
>>> should 

Re: Lying about Hockeypuck being SKS?

[Martin Dobrev]

On 22/03/2021 22:02, Ryan Hunt wrote:
I concur with the rest of the sentiment, I think its time to start 
accepting HP as a replacement for SKS.. If the sks-pool will not 
recognize the value of HP servers I suppose our only recourse is to 
fake it for the time being.


However I’d like to see some efforts made towards:
 - Rolling our SKS hacks back upstream with HP, initially this seems 
stupid but HP has already put in efforts to maintain compatibility 
with SKS peers.. I think a transitional SKS emulation mode that is 
easy to implement and maintain upstream is worthwhile, especially if 
we can come up with a plan to deprecate this nonsense down the road 
and its just to get us through the near future.
I stand by this idea. We need to keep the pool running until an improved 
version gets rolled out.
 - Continued pressure to extend the sks-keyserver pools to include HP 
out the box, this is the only way we’re going to save it. In its 
current state its already being mass purged from the clients.. Lying 
to the pool to save the pool seems totally defeating.
Where are they going? If all major software and OS vendors start running 
their own keyservers then finding a key becomes harder.
 - If it becomes clear the sks-keyserver pool is never going to accept 
patches, contributions, whatever it takes to get HP Servers included 
then its time to declare it dead, we can’t plan on lying to it until 
the end of time and SKS operators are dropping off like flies, and 
those that are sticking around struggle to maintain service.
 - Start a new pool service, designed to be extensible and start 
asking the few clients remaining on the sks-pool to start migrating 
off.. Technology stacks have changed quite a bit over the years and 
this may be less effort than it seems with standard libraries to 
interact with cloud DNS services pretty widespread. HP stats can be 
machine readable w/JSON, and we’ve got the opportunity to extend HP 
specifically to make joining pools more robust, trusted, and less 
fragile since I think there’s far more of us here capable of 
contributing GoLang over OCaml upstream.. I’m thinking like a 
dedicated machine readable status/health API endpoint that the server 
can sign with its own key and the pool provider can verify its the 
server it claims to be, and make accommodations for 
blacklisted/removed keys/max key sizes/etc accounting for variations 
in key counts.


TBH I think creating our own pool is likely our best option going 
forward, yeah it’ll take some time (ie years) before Distros and the 
various PGP clients come back.. but most of em that I used personally 
that came out the box w/the SKS pool no longer do so I think the 
damage has long been done.



+1
I’ve been playing with the Cloudflare DNS API’s of recent and they 
seem like they would be well suited to hosting us a Hockeypuck pool, 
and Cloudflare has such a favorable stance for internet 
protection/security I would be astonished If they pulled the plug on a 
free account doing Keyserver pooling.. its more likely the’d be 
willing to donate some premium features to the cause than anything if 
needed.



Best Regards,
-Ryan Hunt

On Mar 22, 2021, at 1:41 PM, Marcel Waldvogel 
mailto:marcel.waldvo...@trifence.ch>> 
wrote:


On Sun, 2021-03-21 at 22:56 +0100, Andreas Puls wrote:


I've created now a patch that just replaces in the json export contact
with server_contact and Total with numkeys.
https://github.com/apuls/hockeypuck/commit/34fbdfcf73b60e6001f3770b86d8750d1c8b5385 



Great, thanks! I just merged this. Now my Hockeypuck server appears 
in the statistics.



In my hockeypuck configuration i've set Version to 1.1.6+ and Software
to SKS


Hockeypuck is blacklisted in the sks-keyservers.net 
 code, because it was not good enough to 
be incorporated into the pool when Kristian wrote the code. Now, it 
seems to be in the same ballpark as SKS.


Asking Kristian to remove the Hockeypuck ban resulted in him 
explaining that he does not plan to change the code or accept 
changes; instead, we should set up our own fork of his code.


I think this leaves us with the following ways to progress:

a) We leave it as is, Hockeypuck is fine, but just not in the pool.
b) We create a second pool, where Hockeypuck is acceptable (and 
probably SKS as well).
c) We agree that Hockeypuck lying to be SKS is accepted in the pool, 
and maybe even recommended.


I would favor (c), plus keeping the version number in the 2.x range, 
so that experts still can tell the difference.


Opinions?
-Marcel




OpenPGP_0xCAAAE2B8C198C9AE.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Re: Lying about Hockeypuck being SKS?

[Ryan Hunt]

I concur with the rest of the sentiment, I think its time to start accepting HP 
as a replacement for SKS.. If the sks-pool will not recognize the value of HP 
servers I suppose our only recourse is to fake it for the time being.

However I’d like to see some efforts made towards:
 - Rolling our SKS hacks back upstream with HP, initially this seems stupid but 
HP has already put in efforts to maintain compatibility with SKS peers.. I 
think a transitional SKS emulation mode that is easy to implement and maintain 
upstream is worthwhile, especially if we can come up with a plan to deprecate 
this nonsense down the road and its just to get us through the near future.
 - Continued pressure to extend the sks-keyserver pools to include HP out the 
box, this is the only way we’re going to save it. In its current state its 
already being mass purged from the clients.. Lying to the pool to save the pool 
seems totally defeating.
 - If it becomes clear the sks-keyserver pool is never going to accept patches, 
contributions, whatever it takes to get HP Servers included then its time to 
declare it dead, we can’t plan on lying to it until the end of time and SKS 
operators are dropping off like flies, and those that are sticking around 
struggle to maintain service.
 - Start a new pool service, designed to be extensible and start asking the few 
clients remaining on the sks-pool to start migrating off.. Technology stacks 
have changed quite a bit over the years and this may be less effort than it 
seems with standard libraries to interact with cloud DNS services pretty 
widespread. HP stats can be machine readable w/JSON, and we’ve got the 
opportunity to extend HP specifically to make joining pools more robust, 
trusted, and less fragile since I think there’s far more of us here capable of 
contributing GoLang over OCaml upstream.. I’m thinking like a dedicated machine 
readable status/health API endpoint that the server can sign with its own key 
and the pool provider can verify its the server it claims to be, and make 
accommodations for blacklisted/removed keys/max key sizes/etc accounting for 
variations in key counts.

TBH I think creating our own pool is likely our best option going forward, yeah 
it’ll take some time (ie years) before Distros and the various PGP clients come 
back.. but most of em that I used personally that came out the box w/the SKS 
pool no longer do so I think the damage has long been done.

I’ve been playing with the Cloudflare DNS API’s of recent and they seem like 
they would be well suited to hosting us a Hockeypuck pool, and Cloudflare has 
such a favorable stance for internet protection/security I would be astonished 
If they pulled the plug on a free account doing Keyserver pooling.. its more 
likely the’d be willing to donate some premium features to the cause than 
anything if needed.


Best Regards,
-Ryan Hunt

> On Mar 22, 2021, at 1:41 PM, Marcel Waldvogel  
> wrote:
> 
> On Sun, 2021-03-21 at 22:56 +0100, Andreas Puls wrote:
>> 
>> I've created now a patch that just replaces in the json export contact
>> with server_contact and Total with numkeys.
>> https://github.com/apuls/hockeypuck/commit/34fbdfcf73b60e6001f3770b86d8750d1c8b5385
>>  
>> 
> 
> Great, thanks! I just merged this. Now my Hockeypuck server appears in the 
> statistics.
> 
>> In my hockeypuck configuration i've set Version to 1.1.6+ and Software
>> to SKS
> 
> Hockeypuck is blacklisted in the sks-keyservers.net code, because it was not 
> good enough to be incorporated into the pool when Kristian wrote the code. 
> Now, it seems to be in the same ballpark as SKS.
> 
> Asking Kristian to remove the Hockeypuck ban resulted in him explaining that 
> he does not plan to change the code or accept changes; instead, we should set 
> up our own fork of his code.
> 
> I think this leaves us with the following ways to progress:
> 
> a) We leave it as is, Hockeypuck is fine, but just not in the pool.
> b) We create a second pool, where Hockeypuck is acceptable (and probably SKS 
> as well).
> c) We agree that Hockeypuck lying to be SKS is accepted in the pool, and 
> maybe even recommended.
> 
> I would favor (c), plus keeping the version number in the 2.x range, so that 
> experts still can tell the difference.
> 
> Opinions?
> -Marcel



signature.asc
Description: Message signed with OpenPGP

Re: Lying about Hockeypuck being SKS?

[Andrew Gallagher]

On 22/03/2021 20:10, Martin Dobrev wrote:
c) We agree that Hockeypuck lying to be SKS is accepted in the pool, 
and maybe even recommended.


I would favor (c), plus keeping the version number in the 2.x range, 
so that experts still can tell the difference.


I'm already doing c) if I want to help the network run and minimize the 
administrative effort to get rid of poisoned keys, aka recover from dumps.


I intend to do this also, as soon as I get pgpkeys.eu's hockeypuck into 
a more highly-available state.


--
Andrew Gallagher



OpenPGP_signature
Description: OpenPGP digital signature

Re: Lying about Hockeypuck being SKS?

[Andreas Puls]

Am 22.03.2021 um 20:41 schrieb Marcel Waldvogel:

On Sun, 2021-03-21 at 22:56 +0100, Andreas Puls wrote:


I've created now a patch that just replaces in the json export
contact
with server_contact and Total with numkeys.
https://github.com/apuls/hockeypuck/commit/34fbdfcf73b60e6001f3770b86d8750d1c8b5385


Great, thanks! I just merged this. Now my Hockeypuck server appears in
the statistics.


You're welcome!


In my hockeypuck configuration i've set Version to 1.1.6+ and
Software
to SKS



Yeah, i've done it too. :)


Hockeypuck is blacklisted in the sks-keyservers.net code, because it
was not good enough to be incorporated into the pool when Kristian
wrote the code. Now, it seems to be in the same ballpark as SKS.

Asking Kristian to remove the Hockeypuck ban resulted in him explaining
that he does not plan to change the code or accept changes; instead, we
should set up our own fork of his code.

I think this leaves us with the following ways to progress:

a) We leave it as is, Hockeypuck is fine, but just not in the pool.
b) We create a second pool, where Hockeypuck is acceptable (and
probably SKS as well).
c) We agree that Hockeypuck lying to be SKS is accepted in the pool,
and maybe even recommended.

I would favor (c), plus keeping the version number in the 2.x range, so
that experts still can tell the difference.


b would be great but i think this is a hell of work.

Since we haven't heard for a while from Kristian and the pool is working
- ok more or less - i would go with option c too. Also with the Version
string 2.x .

Opinions?

We need to fix the peers field which will be reported via options=mr to
meet the requirements from the pool skript.


-Marcel

Br
  Andreas

Re: Lying about Hockeypuck being SKS?

[Martin Dobrev]

On 22/03/2021 19:41, Marcel Waldvogel wrote:

On Sun, 2021-03-21 at 22:56 +0100, Andreas Puls wrote:


I've created now a patch that just replaces in the json export contact
with server_contact and Total with numkeys.
https://github.com/apuls/hockeypuck/commit/34fbdfcf73b60e6001f3770b86d8750d1c8b5385 



Great, thanks! I just merged this. Now my Hockeypuck server appears in 
the statistics.



In my hockeypuck configuration i've set Version to 1.1.6+ and Software
to SKS


Hockeypuck is blacklisted in the sks-keyservers.net code, because it 
was not good enough to be incorporated into the pool when Kristian 
wrote the code. Now, it seems to be in the same ballpark as SKS.


Asking Kristian to remove the Hockeypuck ban resulted in him 
explaining that he does not plan to change the code or accept changes; 
instead, we should set up our own fork of his code.


I think this leaves us with the following ways to progress:

a) We leave it as is, Hockeypuck is fine, but just not in the pool.
b) We create a second pool, where Hockeypuck is acceptable (and 
probably SKS as well).
c) We agree that Hockeypuck lying to be SKS is accepted in the pool, 
and maybe even recommended.


I would favor (c), plus keeping the version number in the 2.x range, 
so that experts still can tell the difference.


I'm already doing c) if I want to help the network run and minimize the 
administrative effort to get rid of poisoned keys, aka recover from dumps.

Opinions?
-Marcel


OpenPGP_0xCAAAE2B8C198C9AE.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Re: Lying about Hockeypuck being SKS?

[Gabor Kiss]

On Mon, 22 Mar 2021, Marcel Waldvogel wrote:

> a) We leave it as is, Hockeypuck is fine, but just not in the pool.
> b) We create a second pool, where Hockeypuck is acceptable (and
> probably SKS as well).
> c) We agree that Hockeypuck lying to be SKS is accepted in the pool,
> and maybe even recommended.
> 
> I would favor (c), plus keeping the version number in the 2.x range, so
> that experts still can tell the difference.
> 
> Opinions?

b) would be theroretically better a bit but unfortunately getting
wide acceptance by clients needs long time.
So even if b) would allow to fix some problems of actual monitoring
system I vote c).

Gabor