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

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=keys.openpgp.org=commits>
https://github.com/search?q=sks-keyservers+removed=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 >> <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
>>>>  
>>>> <https://github.com/apuls/hockeypuck/commit/34fbdfcf73b60e6001f3770b86d8750d1c8b5385>
>>> 
>>> Great, thanks! I just merged this. Now my Hockeypuck server appears in the 
>>> statistics.
>>> 
>>>> In my

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
>>  
>> <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: keyserver.dobrev.eu is back running Hockeypuck

[Ryan Hunt]

This is great, thank you for the effort you put into this. I pulled my 
keyserver out long ago and am building two news ones now that Hockeypuck 
finally looks ready to replace SKS

Are you going to try to merge this back upstream eventually?

-Ryan



> On Mar 21, 2021, at 12:38 PM, Martin Dobrev  wrote:
> 
> Thanks everyone that messaged me privately. I recon many others are wondering 
> how my cluster is being setup, so I prepared a small repository with sample 
> configuration available here: 
> https://github.com/mclueppers/sks-keyserver-clustering
> 
> I hope it helps.
> 
> On 21/03/2021 00:38, Martin Dobrev wrote:
>> Good afternoon,
>> 
>> I've spent last few weeks fiddling and trying to revive three of the SKS 
>> nodes from my cluster. It takes recently more time recovering from dumps 
>> than actually running the service so I decided to give Hockeypuck a proper 
>> go this time.
>> 
>> New cluster is dual node, running Hockeypuck 2.1.0 + some changes to pass 
>> SKS keyservers status checks available here: 
>> https://github.com/mclueppers/hockeypuck/tree/sks-compatability
>> 
>> 
>> Regards,
>> Martin
>> 
>> 
> 



signature.asc
Description: Message signed with OpenPGP

Re: [Sks-devel] The pool is shrinking

[Ryan Hunt]

Its quite simple really, you sign a revocation of the key and create a new
one, just like you'd do if you ever suspected your private key had been
compromised.

-R

On Fri, Aug 16, 2019 at 3:29 PM Stefan Claas  wrote:

> Hendrik Visage wrote:
>
> > SKS network contains *PUBLIC* keys. It’s purpose, is to PUBLICLY make
> your
> > communications, signed/etc. with the associated *private* key, by
> directed to
> > you and associated with you to proof that it was *you* that
> > signed/produced/etc. that piece of communication. That purpose would be
> to
> > know that the communication was not forged as you, and thus people can
> take
> > that piece of communications as being your words spoken and trusted as
> it was
> > not somebody else faked you. It is also a mechanism that you can receive
> > communications, meant only for your eyes (I meant *private* key :) )that
> > nobody else can decode (given they’ve not compromised your private key).
> >
> > The fact that the SKS network had been and probably will still be
> > abused/DoSed/etc. we can’t deny, but once people becomes silly, as I see
> this
> > whole GDPR discussions have been, I have but one set of advice: Either
> you
> > fix it, or you get out of the SKS server network… let those that run the
> SKS
> > servers have the pains/legal battles/etc. when they are attacked by the
> GDPR
> > enforcers, we’ll fight that battle, no need to make our lives worse off
> if
> > you can’t add positive value…
> >
> > Yours enjoying his pop-corn reading these debates
>
> O.k. let's forget for a moment the GDPR.
>
> Would you or any other SKS operator in 2019 agree that a person should
> have the right that his / her public key can be removed from the SKS
> network if he / she asks for?
>
> An example: You have children and you recommend as an privacy advocate
> and parent that your minors should use PGP.
>
> A nasty classmate signs your daughters pub key with bad things. Teenagers
> usually smarter than their parents may not handle such a situation well,
> like us old PGP farts.
>
> Please explain in 2019 to you friends, wishing to learn secure email
> communications, that they should use PGP, while everybody can sign
> their pub key with arbritary  (and illegal) data, thanks to SKS.
>
> They will for sure show you a stinking finger.
>
> A public key in 2019 does not mean that it can be used for nasty
> things, while a public key holder can not defend him  / her self!
>
> May I ask why you SKS operators did not implemented GnuPG's
> feature the --no-modifiy flag? It is not a brand new feature ...
>
> Regards
> Stefan
>
> --
> box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56
> GPG: C93E252DFB3B4DB7EAEB846AD8D464B35E12AB77 (avail. on Hagrid, WKD)
>
> ___
> 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] The pool is shrinking

[Ryan Hunt]

SKS is still resilient to anyone wiping out all references to my public key
and replacing with their own for a man in the middle attack, you can go
check multiple servers and compare keys against each other.. I can check
keys in my local keystore or transmitted via other means against whats in
SKS, its also resilient to keys being removed to prevent verifying data
signed long ago.. none of that has changed, you can attack the whole
network but its integrity is still intact when it comes back up..

Its role as a decentralized, tamper resistant key storage solution is still
vital, and I would love it if we had the development going on to address
the stability issues, but thats simply not the case at this point in time
and until the actual integrity of the data the SKS network serves is
compromised there is no need for its death.. yes there are alternatives,
but those wont force enforcement of your precious GDPR, I can host all the
same keys any way I want and ignore all your requests for removal just the
same so your argument attacking SKS specifically is moot.

> Also do you think its good Mr Hunt that data can be uploaded onto these
servers such as peoples personal information without consent? This has
happened to a lot of people. And yet no one is interested in addressing
this!
I've proposed solutions to simply add more sanity/validation checks to make
sure keys are actual valid keys and limiting the overall size of keys to
prevent abuse, but overall I'm not terribly concerned.. there's a billion
places to make information public on the internet that is entirely out of
reach of your local authorities, SKS is rather ineffective means of making
information public since practically nobody is looking at the dataset as a
whole and are only querying information directly, and almost always
automated.. You are basically Gaslighting at this point.

> And are you against the GDPR?
Correct, the GDPR would be ruled unconstitutional in a heartbeat if someone
tried to implement it here.

> Do you even know what the GDPR covers?
Yes, quite well.. I unfortunately work with many forms of Digital
Compliance in my industry.

> what has Australia got to do with this?
Just another example of the road to hell is paved with good intentions..
Its a slippery slope you guys are already sliding down.. I can only think
of one operator that was forced to shut down for being liable for data
others posted publicly, and that was an Australian operator.. long before
the GDPR was drafted.. and nothing was accomplished, the data they tried to
take out of the public sphere still exists.. again SKS worked as designed,
the government was unable to stop the distribution of that data.. and its
still accessible, even within Australia.

> and where are you from Mr Hunt? America?
Yes, Colorado to be precise if you need to figure out what court to waste
your time with.

> There's plenty why you claim none im not sure, maybe we should test this
theory of yours?
Go for it, I am completely willing to face any government and the resulting
consequences to protect the integrity and availability of public
cryptography, if my government were to ever insist on compromising it again
in the future I would make it my mission to distribute the tools and spread
awareness despite any legal ramifications or any moral perspective, yeah I
might be assisting terrorists, child abusers, and other boogiemen; but
thats the price of cryptographically secure communications. The EU can
bring it on for all I care, this is a hill I'm fully prepared to die on,
and have been for a while.. I advocated for and distributed the tools 30
years ago when strong crypto was illegal to export from the United States,
and eventually we won that battle of attrition.

-R



On Fri, Aug 16, 2019 at 10:12 AM  wrote:

> On Fri, 16 Aug 2019 09:12:30 -0600
> Ryan Hunt  wrote:
>
> > Yakamo,
> > it still does its job of ensuring published keys are not tampered with,
> it
> > was not designed to be resilient to denial attacks.. That does not
> > interfere with the trust of PGP, its why there are local keystores.. and
> > the SKS network is still around despite being unreliable/broken from a
> > maintenance standpoint.. your poisoned keys are not altering other
> > individuals keys in any way/shape/form, so its security has not been
> > compromised.. availability of keyservers is not critical to the use of
> PGP,
> > again by design.. there are many ways to distribute keys, it is resilient
> > factually despite your opinions.. over the decades the need has not been
> > lost.
> >
>
> That's correct its not designed to be resilient to denial attacks, making
> it unreliable as stated before! which means its not resilient to
> governments at all! This statement stands true. Now it barely fulfils its
> basic functions! the amount of posts littered over the internet about how
>

Re: [Sks-devel] The pool is shrinking

[Ryan Hunt]

One could argue the inverse, to me its very strange that administrators of
a scheme designed from the onset to be resilient to governmental scale
interference would widely open their arms to multinational scale
interference.

Its about pretty good privacy, not perfect privacy.. by design w/PGP and
SKS, public keys are designed to be public, and not private.. in order to
keep the private part secure, allowing people to arbitrary purge public
data entirely undermines the entire thing.

-Ryan

On Thu, Aug 15, 2019 at 6:39 PM Arnold  wrote:

> I thought SKS and PGP-keys is about one's ability to hide private data (by
> encryption). GDPR is also about one's ability to hide private data (by
> having
> private data, that can be used in correlations, removed from large
> databases). Yet,
> SKS administrators who apparently live outside the EU argue strongly that
> there is
> no need for them to support GDPR.
>
> To me, it is very strange to read one strongly supports one form of
> privacy, while
> totally ignoring other forms. In fact it seems to me these operators are
> not only
> ignoring other forms, but it seems they do not even acknowledge the fact
> that to
> *some* people in the world the other (GDPR) form may be very important as
> well.
> Remember, people in different parts of the world do have different values
> and
> different needs.
>
> Arnold
>
> On 15-08-2019 18:39, Robert J. Hansen wrote:
> >> Well, it was just one of many example sites...
> >
> > Again: I'm going to go with the real advice given to me by real lawyers.
> >
> >> So as an example, US SKS key server operators do not have to honor
> >> removal request (in this case shut-down the server) from EU citizens,
> >> when they receive a letter from a lawyer?
> >
> > Depends on the individual.  I rarely travel to Europe and have no
> > financial holdings there.  It gives me a great ability to say "no, I'm
> > not signatory to your treaty, go away."  Other Americans may have enough
> > ties to Europe to make it possible for EU courts to apply leverage.
> >
> >> I remember also that plenty of US sites (small and large), where I
> >> did business with, asked for my consent as EU citizen, when they
> >> changed their privacy policy once the GDPR took place.
> >
> > Some of them do business in Europe and are susceptible to pressure by
> > the EU.  Some of them were just jumping on the bandwagon.
> >
> >> Has an US SKS key server operator then not 'business' ties with EU
> >> citizens, when storing their personal data like name and email address?
> >
> > No.  Those are considered facts no different than tracking a name and
> > phone number.  Mere facts cannot be suppressed by the United States
> > government; citizens are allowed to share them to our heart's content.
> >
> >> And has Mr. Rude then the right to freely distribute this data, without
> >> protecting it, to the whole world?
> >
> > I don't know anything about him or where he lives or which laws he must
> > follow.
> >
> > ___
> > 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] The pool is shrinking

[Ryan Hunt]

I don't believe anything you do in public has any expectation of privacy..
no moral qualms about it.

On Tue, Aug 13, 2019 at 10:09 AM Philihp Busby  wrote:

> You should respect their right to privacy, if not for legal ones, then
> moral.
>
> On Tue, Aug 13, 2019 at 16:04 Ryan Hunt  wrote:
>
>> EU Can write whatever it wants down on a piece of paper, but that dont
>> mean its anything more than a piece of paper to me... they have no
>> authority here, I don't recognize their authority and there is absolutely
>> nothing that they can do about it.. So it dont really matter if they say
>> its applicable to me, because its not.
>>
>> Argue semantics til your blue in the face, the end result is nobody doing
>> business with or within the EU has any obligation whatsoever to even
>> concern themselves with the GDPR.. and that's never going to change,
>> regardless what everyone's opinions are on the matter.
>>
>> -R
>>
>> On Tue, Aug 13, 2019 at 9:40 AM Tobias Mueller 
>> wrote:
>>
>>> Hi,
>>>
>>> On Tue, 2019-08-13 at 11:00 -0400, Robert J. Hansen wrote:
>>> > > They are!
>>> >
>>> > No, they're not.
>>> I think your assessment is wrong.
>>>
>>> >
>>> > There are (or at least were) a large number of US-based keyserver
>>> > operators who were immune to the GDPR.
>>>
>>> I fail to see how this is in accordance with the GDPR.
>>> Section 3.2 states¹:
>>>
>>> > This Regulation applies to the processing of personal data of data
>>> > subjects who are in the Union by a controller or processor not
>>> > established in the Union, where the processing activities are related
>>> > to:
>>> >
>>> > the offering of goods or services, irrespective of whether a
>>> > payment of the data subject is required, to such data subjects in the
>>> > Union
>>>
>>> This is exactly the case for OpenPGP Keyservers.
>>>
>>> Cheers,
>>>   Tobi
>>>
>>> 1: https://gdpr-info.eu/art-3-gdpr/
>>>
>>>
>>> ___
>>> 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] The pool is shrinking

[Ryan Hunt]

EU Can write whatever it wants down on a piece of paper, but that dont mean
its anything more than a piece of paper to me... they have no authority
here, I don't recognize their authority and there is absolutely nothing
that they can do about it.. So it dont really matter if they say its
applicable to me, because its not.

Argue semantics til your blue in the face, the end result is nobody doing
business with or within the EU has any obligation whatsoever to even
concern themselves with the GDPR.. and that's never going to change,
regardless what everyone's opinions are on the matter.

-R

On Tue, Aug 13, 2019 at 9:40 AM Tobias Mueller 
wrote:

> Hi,
>
> On Tue, 2019-08-13 at 11:00 -0400, Robert J. Hansen wrote:
> > > They are!
> >
> > No, they're not.
> I think your assessment is wrong.
>
> >
> > There are (or at least were) a large number of US-based keyserver
> > operators who were immune to the GDPR.
>
> I fail to see how this is in accordance with the GDPR.
> Section 3.2 states¹:
>
> > This Regulation applies to the processing of personal data of data
> > subjects who are in the Union by a controller or processor not
> > established in the Union, where the processing activities are related
> > to:
> >
> > the offering of goods or services, irrespective of whether a
> > payment of the data subject is required, to such data subjects in the
> > Union
>
> This is exactly the case for OpenPGP Keyservers.
>
> Cheers,
>   Tobi
>
> 1: https://gdpr-info.eu/art-3-gdpr/
>
>
> ___
> 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 - keys.flanga.io

[Ryan Hunt]

I’ve been contributing to those discussions and helping come up with those 
solutions your referencing, not beating on drums.. everyone here knows what the 
issues are and everyone has been honest about em, this entire mailer’s history 
is free to review and nobody has been hiding anything.. I just passed a decade 
subscribed to this mailing list.. Despite all the discussions that have taken 
place, you keep ringing the bell over and over with your cute little blog.

Right now I’m drafting up a replacement solution and might POC some code for a 
future proposal if I manage to find the time.. because I’ve got experience and 
solutions, just not a lot of free time to implement a project this complex.. so 
if everyone here is going to depend on me for development, well its not going 
to get very far.. but mebe I can get something off the ground in a modular 
framework that more people can work with than the existing codebase.

Your other projects do not address the role of the SKS network, there is a need 
for a distributed list of keys.. for example a friend I grew up with now 
maintains architectural software builds for a popular Linux distribution, he 
needs to validate signatures of keys completely automated and in high volume 
coming from disperse projects and upstream sources.. We run a key server just 
for this task so he’s not hammering and abusing other key keyservers.. he needs 
to federate with a decentralized dataset or all that automation starts 
breaking… He also dont have any need to concern him self with GDPR or 
nonsensical keys or copyrighted material since its only his build environments 
that is accessing them. 

-Ryan

> On Nov 15, 2018, at 7:07 PM, stuff  wrote:
> 
> I think at least a warning should be given to the admins so they understand 
> the full legal risks of running a keyserver.
> 
> as far as solutions once again ive actually pointed out that people in the 
> comminity have already come up with solutions so i dont see the need to 
> iterate over the same ideas, i actually link to one post in one of my 
> articles about solutions on here. ive also reeferenced other projects. so i 
> have contributed some solutions and pointed out better ones by others.
> 
> i also dont think its needed to be insulting in a debate, its not 
> constructive.
> 
> What have you done to try and change things Ryan?
> 
> On Thu, 15 Nov 2018 18:53:30 -0700
> Ryan Hunt mailto:ad...@nayr.net>> wrote:
> 
>> 
>> 
>>> On Nov 15, 2018, at 6:25 PM, Mike  wrote:
>>> 
>>> So you are angry that i and a few others have reported several bugs, to a 
>>> system that we would like to see continue to exist?
>>> 
>>> If there is no dev team, then maybe its time to call it a day instead of 
>>> pretending everything is ok?
>>> 
>> 
>> You’d make an excellent politician with this superb ability to speak out 
>> both ends, all while being incapable even coming up with solutions, let 
>> alone implementing them.
>> 
>> No one here has been pretending its okay, were just not willing to pack it 
>> up and call it a day because of you say we should.. there’s literally no 
>> chance someone’s going to read your articles and decide to volunteer the 
>> time and energy to implementing a solution.. so really everything you’ve 
>> done and all your doing is to the detriment of the key server network.. and 
>> yet your surprised at the hostility you’ve found here? 
>> 
>> -Ryan
>> 
>>> On Thu, 15 Nov 2018 18:12:14 -0700
>>> Ryan Hunt mailto:ad...@nayr.net> <mailto:ad...@nayr.net 
>>> <mailto:ad...@nayr.net>>> wrote:
>>> 
>>>> Wait, you have the skillset to code attacks and spew articles yet, no 
>>>> capability for solutions? Smells like ignorance is your forte.
>>>> 
>>>> You seem to be under the impression that SKS has active developers working 
>>>> on it, the reason the “dev team” is quiet as per your “articles” is there 
>>>> is no friggin dev team, just some maintainers pushing merge requests from 
>>>> people hacking it a bit here and there to fix major problems that can be 
>>>> fixed and keep it compiling on modern systems.
>>>> 
>>>> There is nobody actively interested in the development required to 
>>>> re-archectect the SKS backend and infrastructure that had been running 
>>>> fine for a few decades now.. until you came along and made a big stink.. 
>>>> If you have a proposal for a new way of doing things, we’re all dying to 
>>>> hear it.
>>>> 
>>>> -Ryan
>>>> 
>>>> 
>>>>> On Nov 15, 2018, at 

Re: [Sks-devel] Withdrawal of Service - keys.flanga.io

[Ryan Hunt]

> On Nov 15, 2018, at 6:25 PM, Mike  wrote:
> 
> So you are angry that i and a few others have reported several bugs, to a 
> system that we would like to see continue to exist?
> 
> If there is no dev team, then maybe its time to call it a day instead of 
> pretending everything is ok?
> 

You’d make an excellent politician with this superb ability to speak out both 
ends, all while being incapable even coming up with solutions, let alone 
implementing them.

No one here has been pretending its okay, were just not willing to pack it up 
and call it a day because of you say we should.. there’s literally no chance 
someone’s going to read your articles and decide to volunteer the time and 
energy to implementing a solution.. so really everything you’ve done and all 
your doing is to the detriment of the key server network.. and yet your 
surprised at the hostility you’ve found here? 

-Ryan

> On Thu, 15 Nov 2018 18:12:14 -0700
> Ryan Hunt mailto:ad...@nayr.net>> wrote:
> 
>> Wait, you have the skillset to code attacks and spew articles yet, no 
>> capability for solutions? Smells like ignorance is your forte.
>> 
>> You seem to be under the impression that SKS has active developers working 
>> on it, the reason the “dev team” is quiet as per your “articles” is there is 
>> no friggin dev team, just some maintainers pushing merge requests from 
>> people hacking it a bit here and there to fix major problems that can be 
>> fixed and keep it compiling on modern systems.
>> 
>> There is nobody actively interested in the development required to 
>> re-archectect the SKS backend and infrastructure that had been running fine 
>> for a few decades now.. until you came along and made a big stink.. If you 
>> have a proposal for a new way of doing things, we’re all dying to hear it.
>> 
>> -Ryan
>> 
>> 
>>> On Nov 15, 2018, at 6:01 PM, Mike  wrote:
>>> 
>>> If i had the skill set needed to submit patches i would, but i don't.
>>> But i do have a voice and that can be used to spur on change.
>>> 
>>> I wrote the articles because there is a clear ignorance here that your 
>>> displaying really well, which is preventing things from getting fixed. Your 
>>> clearly angry and not interested in resolving this issue through 
>>> discussion. That ignorance is going to harm admins as Moritz Wirth and 
>>> Fabian points out.
>>> 
>>> Can you say there's no risk to admins financially and legally, because of 
>>> the poor design of the servers or do they work just fine and they have 
>>> nothing to worry about?
>>> 
>>> If performing as designed means: 
>>> failing to deal with oversized keys and chewing up bandwidth and CPU cycles 
>>> and causing servers to stop responding or the web interface to freeze or 
>>> spit out garbage is a feature then ok.
>>> or network instability then ok.
>>> 
>>> Mike :)
>>> 
>>> and if calling people children and being generally insulting is your thing 
>>> your not really being constructive with this!
>>> 
>>> 
>>> On Fri, 16 Nov 2018 08:45:06 +0800
>>> Matthew Walster mailto:dotwaf...@gmail.com> 
>>> <mailto:dotwaf...@gmail.com <mailto:dotwaf...@gmail.com>>> wrote:
>>> 
>>>> On Fri, 16 Nov 2018, 08:36 Mike >>> <mailto:st...@yakamo.org> wrote:
>>>> 
>>>>> Your welcome to blame others for the servers issues.
>>>>> 
>>>>> I and others have pointed out many times over the issues and no one has
>>>>> fixed them.
>>>>> Rather than blame me, take responsibility for the servers failings, for
>>>>> the developers failings.
>>>>> 
>>>> 
>>>> You are more than welcome to submit patches (or even ideas for patches) if
>>>> you want to help improve things. Screaming blue murder helps no-one.
>>>> 
>>>> Decent and good developers take bugs and fix them and ensure the ongoing
>>>>> survival of their software, not blame them on the people who found them 
>>>>> and
>>>>> exposed them!
>>>>> 
>>>> 
>>>> The software is not broken. It is performing as designed. The same
>>>> side-effects are present in Bitcoin but I don't see you making deranged
>>>> comments about that...
>>>> 
>>>> Your basicly saying we should be able to have weak software and bad people
>>>>> shouldnt do bad things, thats not how the world works. Take some
&g

Re: [Sks-devel] Withdrawal of Service - keys.flanga.io

[Ryan Hunt]

Wait, you have the skillset to code attacks and spew articles yet, no 
capability for solutions? Smells like ignorance is your forte.

You seem to be under the impression that SKS has active developers working on 
it, the reason the “dev team” is quiet as per your “articles” is there is no 
friggin dev team, just some maintainers pushing merge requests from people 
hacking it a bit here and there to fix major problems that can be fixed and 
keep it compiling on modern systems.

There is nobody actively interested in the development required to 
re-archectect the SKS backend and infrastructure that had been running fine for 
a few decades now.. until you came along and made a big stink.. If you have a 
proposal for a new way of doing things, we’re all dying to hear it.

-Ryan


> On Nov 15, 2018, at 6:01 PM, Mike  wrote:
> 
> If i had the skill set needed to submit patches i would, but i don't.
> But i do have a voice and that can be used to spur on change.
> 
> I wrote the articles because there is a clear ignorance here that your 
> displaying really well, which is preventing things from getting fixed. Your 
> clearly angry and not interested in resolving this issue through discussion. 
> That ignorance is going to harm admins as Moritz Wirth and Fabian points out.
> 
> Can you say there's no risk to admins financially and legally, because of the 
> poor design of the servers or do they work just fine and they have nothing to 
> worry about?
> 
> If performing as designed means: 
> failing to deal with oversized keys and chewing up bandwidth and CPU cycles 
> and causing servers to stop responding or the web interface to freeze or spit 
> out garbage is a feature then ok.
> or network instability then ok.
> 
> Mike :)
> 
> and if calling people children and being generally insulting is your thing 
> your not really being constructive with this!
> 
> 
> On Fri, 16 Nov 2018 08:45:06 +0800
> Matthew Walster mailto:dotwaf...@gmail.com>> wrote:
> 
>> On Fri, 16 Nov 2018, 08:36 Mike > 
>>> Your welcome to blame others for the servers issues.
>>> 
>>> I and others have pointed out many times over the issues and no one has
>>> fixed them.
>>> Rather than blame me, take responsibility for the servers failings, for
>>> the developers failings.
>>> 
>> 
>> You are more than welcome to submit patches (or even ideas for patches) if
>> you want to help improve things. Screaming blue murder helps no-one.
>> 
>> Decent and good developers take bugs and fix them and ensure the ongoing
>>> survival of their software, not blame them on the people who found them and
>>> exposed them!
>>> 
>> 
>> The software is not broken. It is performing as designed. The same
>> side-effects are present in Bitcoin but I don't see you making deranged
>> comments about that...
>> 
>> Your basicly saying we should be able to have weak software and bad people
>>> shouldnt do bad things, thats not how the world works. Take some
>>> responsibility!!!
>>> 
>> 
>> That's not what anyone is saying. What are you, 12 years old?
>> 
>> And im not a journalist!
>>> 
>> 
>> You wrote an article.
>> 
>> M
>> 
>>> 
> 
> 
> -- 
> me mailto:st...@yakamo.org>>
> 
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org 
> https://lists.nongnu.org/mailman/listinfo/sks-devel 
> 
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

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

[Ryan Hunt]

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

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

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

-Ryan

> On Jul 13, 2018, at 9:37 PM, Robert J. Hansen  wrote:
> 
>> IMHO Photo-ID should be dropped entirely, I see no point and its just
>> ripe for abuse like this..
> 
> Unfortunately, we really can't.  They've been part of OpenPGP
> certificates for just about twenty years now.  They are an expected part
> of the certificate.  Users already scream bloody murder about GnuPG and
> Enigmail dropping support for SE packets and those have been deprecated
> since 2003.  The idea of just waving a wand and getting rid of a
> non-deprecated part of a public key is just ... no.
> 
> Is it technically possible?  Yes.  But it would require a significant
> amount of redesign: we'd have to parse out the key, recognize images,
> drop them, etc.  Right now SKS does *zero* cryptographic verification of
> the key data; we'd need to change SKS to introduce at least some crypto
> support.
> 
> Is it possible without facing a user revolt?  No.
> 
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel


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

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

[Ryan Hunt]

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

-Ryan

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

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

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

[Ryan Hunt]

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

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

Regards,
-Ryan Hunt

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


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

Re: [Sks-devel] SKS RAM usage gone haywire

[Ryan Hunt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I don't know what is wrong with my system, I rebuilt the DB from my old
dump.. brought it online and got updated from my peers... and then get
stuck in a new loop trying to get new keys.

I have disabled rcon at the moment to keep from hurting my peers.

Any ideas? I have verified all permissions, created a new database. It
got ~14k keys from my peers when I brought the new db online and all
those keys seem to be in the database.

Here are the last 10mins worth of rcon.log:

2009-02-16 10:28:35 Requesting 3 missing keys from ADDR_INET
72.190.107.50:11371, starting with 24930CB60AA1C6C4B1226B120EA8DE56
2009-02-16 10:28:35 3 keys received
2009-02-16 10:29:31 recon as client error in callback.:
Sys_error(Connection reset by peer)
2009-02-16 10:30:35 Hashes recovered from ADDR_INET 114.31.78.196:11371
2009-02-16 10:30:35 24930CB60AA1C6C4B1226B120EA8DE56
2009-02-16 10:30:35 38DA1F141DF06D9533038B5AEC83
2009-02-16 10:30:35 4F87D632F4FFC77E1A58593CF9D5C62D
2009-02-16 10:30:35 6B8DBCBF72AFBC8B72ABEB727E941036
2009-02-16 10:30:36 Requesting 4 missing keys from ADDR_INET
114.31.78.196:11371, starting with 24930CB60AA1C6C4B1226B120EA8DE56
2009-02-16 10:30:37 4 keys received
2009-02-16 10:30:37 Added 2 hash-updates. Caught up to 1234805437.493819
2009-02-16 10:31:21 Hashes recovered from ADDR_INET 131.215.176.75:11371
2009-02-16 10:31:21 24930CB60AA1C6C4B1226B120EA8DE56
2009-02-16 10:31:21 38DA1F141DF06D9533038B5AEC83
2009-02-16 10:31:21 4F87D632F4FFC77E1A58593CF9D5C62D
2009-02-16 10:31:31 Requesting 3 missing keys from ADDR_INET
131.215.176.75:11371, starting with 24930CB60AA1C6C4B1226B120EA8DE56
2009-02-16 10:31:31 3 keys received
2009-02-16 10:32:20 Hashes recovered from ADDR_INET 84.16.235.61:11371
2009-02-16 10:32:20 24930CB60AA1C6C4B1226B120EA8DE56
2009-02-16 10:32:20 2B3BC55DD351B9B2381355C16016BC81
2009-02-16 10:32:20 38DA1F141DF06D9533038B5AEC83
2009-02-16 10:32:20 4F87D632F4FFC77E1A58593CF9D5C62D
2009-02-16 10:32:20 6D12458590911F13DDC6DBAC60E37E1C
2009-02-16 10:32:20 AD6C2B2CE9D7AAC71F1EC5C671D260BC
2009-02-16 10:32:22 Requesting 6 missing keys from ADDR_INET
84.16.235.61:11371, starting with 24930CB60AA1C6C4B1226B120EA8DE56
2009-02-16 10:32:23 6 keys received
2009-02-16 10:32:23 Added 3 hash-updates. Caught up to 1234805543.172267
2009-02-16 10:33:16 Hashes recovered from ADDR_INET 195.111.98.30:11371
2009-02-16 10:33:16 24930CB60AA1C6C4B1226B120EA8DE56
2009-02-16 10:33:16 38DA1F141DF06D9533038B5AEC83
2009-02-16 10:33:16 4F87D632F4FFC77E1A58593CF9D5C62D
2009-02-16 10:33:26 Requesting 3 missing keys from ADDR_INET
195.111.98.30:11371, starting with 24930CB60AA1C6C4B1226B120EA8DE56
2009-02-16 10:33:26 3 keys received
2009-02-16 10:34:15 Hashes recovered from ADDR_INET 195.111.98.30:11371
2009-02-16 10:34:15 24930CB60AA1C6C4B1226B120EA8DE56
2009-02-16 10:34:15 38DA1F141DF06D9533038B5AEC83
2009-02-16 10:34:15 4F87D632F4FFC77E1A58593CF9D5C62D
2009-02-16 10:34:25 Requesting 3 missing keys from ADDR_INET
195.111.98.30:11371, starting with 24930CB60AA1C6C4B1226B120EA8DE56
2009-02-16 10:34:26 3 keys received
2009-02-16 10:35:21 Hashes recovered from ADDR_INET 72.190.107.50:11371
2009-02-16 10:35:21 24930CB60AA1C6C4B1226B120EA8DE56
2009-02-16 10:35:21 38DA1F141DF06D9533038B5AEC83
2009-02-16 10:35:21 4F87D632F4FFC77E1A58593CF9D5C62D
2009-02-16 10:35:21 Requesting 3 missing keys from ADDR_INET
72.190.107.50:11371, starting with 24930CB60AA1C6C4B1226B120EA8DE56
2009-02-16 10:35:21 3 keys received
2009-02-16 10:36:20 Hashes recovered from ADDR_INET 195.111.98.30:11371
2009-02-16 10:36:20 24930CB60AA1C6C4B1226B120EA8DE56
2009-02-16 10:36:20 38DA1F141DF06D9533038B5AEC83
2009-02-16 10:36:20 4F87D632F4FFC77E1A58593CF9D5C62D
2009-02-16 10:36:20 944A73D73698FFBFBA74B159838DC9B3
2009-02-16 10:36:21 Requesting 4 missing keys from ADDR_INET
195.111.98.30:11371, starting with 24930CB60AA1C6C4B1226B120EA8DE56
2009-02-16 10:36:22 4 keys received
2009-02-16 10:36:22 Added 1 hash-updates. Caught up to 1234805782.306689
2009-02-16 10:37:23 recon as client error in callback.:
Sys_error(Connection reset by peer)
2009-02-16 10:38:25 recon as client error in callback.: Unix error:
Connection refused - connect()
2009-02-16 10:39:23 recon as client error in callback.:
Sys_error(Connection reset by peer)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkmZptUACgkQIcAiq3SnceEp4ACfXqDsiKAJNaOxCkNJQ0rrIec7
ktEAn0R0v77NoSDWfcEYOvR5qE5sM/wP
=Aw8Q
-END PGP SIGNATURE-


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

Re: [Sks-devel] Re: keys.nayr.net status

[Ryan Hunt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Thanks, that made my life easier.

IPv6  SSL are online, Im back to being fully operational.. well as far
as the KeyServer is concerned.. :-\  Could of been much worse, on the
bright side I installed a Intel nic and my response times have
plummeted. The onboard broadcom gigabit nic was dropping packets :-(

I am going to schedule about 30mins of downtime sometime next week to
install a backup drive and bump the server up to 8GB ram.. Didn't want
to blow that 200+ day uptime before all this, meh.

Cheers,
- -R

John Clizbe wrote:
 Ryan wrote:
 My membership file was lost and the backup is kind of dated, If your  
 peered with me (or would like to be) please check that I have you on  
 my list  and let me know if you are not (see 
 http://keys.nayr.net/pks/lookup?op=stats 
 
 Glad your back up, Ryan.
 
 Wait an hour and check http://sks-keyservers.net/status/info/keys.nayr.net  
 It'll
 show all the cross-peerings. The next poll is 11:50 US/Central (18:50 Central 
 European)
 
 - From checking the metadata of the other servers, here's a list of those 
 peered with
 you:
 ice.mudshark.org
 keys.keysigning.org
 keys.nayr.net
 keys.niif.hu
 keyserver.gingerbear.net
 keyserver.kim-minh.com
 keyserver.pki.scientia.net
 keyserver.pramberger.at
 keyserver.sparcs.net
 pgp.ugcs.caltech.edu
 sks.pkqs.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkmV6l4ACgkQIcAiq3SnceGRggCgl4TdC7Xs5KRBL1c7KIDQqORk
bpEAnRlvlYLmgWIoNiHQvQe/AML1pYr+
=fg8n
-END PGP SIGNATURE-


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

Re: [Sks-devel] Re: IPv6 SKS Pool

[Ryan Hunt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Unfortunately there are alot of servers that have  records but are
not listening on IPv6...  I went through the hosts currently in your
pool and all the following were not IPv6 capable

[EMAIL PROTECTED]:~$ telnet 2001:41d0:1:e812:1c:c0ff:fe65:2cd4 11371
Trying 2001:41d0:1:e812:1c:c0ff:fe65:2cd4...
telnet: Unable to connect to remote host: Connection refused

[EMAIL PROTECTED]:~$ telnet 2a01:198:200:20a::2 11371
Trying 2a01:198:200:20a::2...
telnet: Unable to connect to remote host: Connection refused

[EMAIL PROTECTED]:~$ telnet 2001:610:1108:5011:230:48ff:fe12:2794 11371
Trying 2001:610:1108:5011:230:48ff:fe12:2794...
telnet: Unable to connect to remote host: Connection refused

[EMAIL PROTECTED]:~$ telnet 2001:748:100:1::32 11371
Trying 2001:748:100:1::32...
telnet: Unable to connect to remote host: Connection refused

- -Ryan


Kristian Fiskerstrand wrote:
 Ryan Hunt wrote, On 10/17/2008 07:50 AM:
 First, thanks to everyone who peered w/me, had no idea I'd get as many
 responses and so quickly. Neat community here.
 
 Anyhow, I dug through all the SKS servers I could find and found a total
 of 5 (including myself) Syncing KeyServers that support IPv6. I put all
 those servers into a pool and setup my monitoring software to keep an
 eye on them encase a server disappears, allowing me to ensure the pool
 only contains active hosts.
 
 the address for this IPv6 only pool is: x-hks://pool.ipv6.keys.nayr.net
 
 pool.ipv6.keys.nayr.net has IPv6 address 2001:470:1f05:429:420:420:420:420
 pool.ipv6.keys.nayr.net has IPv6 address 2001:5c0:8a8a:40::51
 pool.ipv6.keys.nayr.net has IPv6 address 2001:638:204:10::2:1
 pool.ipv6.keys.nayr.net has IPv6 address 2001:738:0:1:209:6bff:fe8c:845a
 pool.ipv6.keys.nayr.net has IPv6 address 2001:1418:1d7:1::1
 
 I'll check every few months to see if any new IPv6 supported keyservers
 pop up and add them to the list, feel free to use this pool if you find
 it useful.
 
 If you want your server added or removed from this list shoot me an email.
 
 
 This is actually not too bad an idea, so I implemented ipv6 to
 sks-keyservers.net as well.
 
 the pool is available at x-hkp://ipv6.pool.sks-keyservers.net and uses
 the same data as for the original synchronization test, just checks if
 the same servers have  records.
 
 in theory this could result in a situation where server responds to ipv4
 requests and not ipv6 requests, but for now that seems like an unlikely
 issue, which I'll rather counter with blacklist if it happens.
 
 Status is currently BETA on ipv6, so please come with comments. IPv6
 support will be added to keys.kfwebs.net and possibly keys2.kfwebs.net
 over the next couple of weeks as well.
 

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

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkkDR+MACgkQIcAiq3SnceGxXgCcCZssCQ99YcatrkH/9pLfR4J/
vkwAniQpU/Bs4bYmhNpXjsCl8YYzArX3
=jKno
-END PGP SIGNATURE-


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

[Sks-devel] Seeking Gossip Partners

[Ryan Hunt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I am looking for some gossip partners, please reply directly to:
[EMAIL PROTECTED] (xmpp/email)

host: keys.nayr.net
listening on ports: 11371, 443 (ssl), and 80

server info:
dual 2.0ghz Opteron w/4GB ram  64GB Solid State Drive running Debian
Etch (64Bit) on 100Mbit Internap connection just outside Denver Colorado

Thanks,
Ryan Hunt
Admin - |nayr|NETworks|
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFI9oQSIcAiq3SnceERAvcvAKCzcwGD9KMDf93XoYpXPEASkqJYcACdFTww
h+girRXdmCLSoMKYVumQeLQ=
=2O2+
-END PGP SIGNATURE-


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

[Sks-devel] IPv6 SKS Pool

[Ryan Hunt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

First, thanks to everyone who peered w/me, had no idea I'd get as many
responses and so quickly. Neat community here.

Anyhow, I dug through all the SKS servers I could find and found a total
of 5 (including myself) Syncing KeyServers that support IPv6. I put all
those servers into a pool and setup my monitoring software to keep an
eye on them encase a server disappears, allowing me to ensure the pool
only contains active hosts.

the address for this IPv6 only pool is: x-hks://pool.ipv6.keys.nayr.net

pool.ipv6.keys.nayr.net has IPv6 address 2001:470:1f05:429:420:420:420:420
pool.ipv6.keys.nayr.net has IPv6 address 2001:5c0:8a8a:40::51
pool.ipv6.keys.nayr.net has IPv6 address 2001:638:204:10::2:1
pool.ipv6.keys.nayr.net has IPv6 address 2001:738:0:1:209:6bff:fe8c:845a
pool.ipv6.keys.nayr.net has IPv6 address 2001:1418:1d7:1::1

I'll check every few months to see if any new IPv6 supported keyservers
pop up and add them to the list, feel free to use this pool if you find
it useful.

If you want your server added or removed from this list shoot me an email.

Cheers,
Ryan Hunt
|nayr|NETworks|
http://keys.nayr.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFI+CeIIcAiq3SnceERAl71AJwN0uX/axy6WIsa2zcV5VRTqeeAzQCgl6z4
u09EMdx+2hgIu2NmtyEmE5Y=
=50mG
-END PGP SIGNATURE-


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