Re: The state of peer connectivity

[Hendrik Visage]

Which reminds me:

‘cause of various operational issues and the time it needed to attend to them 
lately, the following servers have been stopped and aren’t operational anymore:

sks2.cryptokeys. co.za

sks1.cryptokeys.org.za 
sks2.cryptokeys.org.za 

sks1.inx.net.za 
sks2.inx.net.za 
sks3.inx.net.za 

[Sks-devel] ProxMox/Debian 10.1 gnupg2 notice:

[Hendrik Visage]

Thought it would be interesting to know this state:


apt-listchanges: News
-

gnupg2 (2.2.12-1+deb10u1) buster; urgency=medium

  In this version we adopt GnuPG's upstream approach of making keyserver
  access default to self-sigs-only.  This defends against receiving
  flooded OpenPGP certificates.  To revert to the previous behavior (not
  recommended!), add the following directive to ~/.gnupg/gpg.conf:

keyserver-options no-self-sigs-only

  We also adopt keys.openpgp.org as the default keyserver, since it avoids
  the associated bandwidth waste of fetching third-party certifications
  that will not be used.  To revert to the older SKS keyserver network (not
  recommended!), add the following directive to ~/.gnupg/dirmngr.conf:

keyserver hkps://hkps.pool.sks-keyservers.net

  Note: we do *not* adopt upstream's choice of import-clean for the
  keyserver default, since it can lead to data loss, see
  https://dev.gnupg.org/T4628 for more details.

 -- Daniel Kahn Gillmor   Wed, 21 Aug 2019 14:53:47 
-0400


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

Re: [Sks-devel] The pool is shrinking

[Hendrik Visage]

> On 16 Aug 2019, at 23:29 , 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?

The method to do that, is to have a valid period, and then before the valid 
period expires, the user can resign a new
key with the old key, or he/she/they/them/whatever could just let that expire.

The user that want that key to be removed, either doesn’t understand the 
principles/ideas of the need/use for the
PUBLICLY available public keys, or is hiding something that they shouldn’t have 
done in the first place.

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

Well, the   “bad” things, and the “sign” is a method to prosecute (with quite a 
high confidence level) the guilty party
to the point where the punishment should be a deterrent enough for future 
bullies to be fearful of.

The specifics is (a) an indication of a badly educated bully, and (b) a bad 
family structure of the victim (Personal points of views and beliefs)
that gets worsened by the facts that the guilty aren’t properly punished, (We 
have police states, but the criminals have more rights than the civilians
that can’t even protect themselves against the perpetrators with enough force 
to deter the perpetrators ;( )

Things like GDPR are nice “laws”, but a toothless setup other than a monetary 
slap on the wrists for the big guys.

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

The signature is a indication of who knows you, and SKS is a mechanism, not the 
only mechanism to setup a web of trusts

> They will for sure show you a stinking finger.

You aren’t forced to be part of, nor use, the SKS.

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

I may have an outer wall that get’s grafiti all the time… I can’t protect that 
every single minute of the day…
but I can proof it is my home given the fact that only I have a set of keys 
that will open the (full of grafiti) garage door!!

that public key’s “signing” is the perpetrator that acknowledges it’s my key, 
even if/when he/she/they/them/whatever
put horrible things on it, they are still the ones that can be shown as the 
ones that did it…

> May I ask why you SKS operators did not implemented GnuPG's
> feature the --no-modifiy flag? It is not a brand new feature …

Perhaps as it’s not running GnuPG/pgp inside the SKS key servers ;)
SKS is just a mechanism to share (decentralized) a blob of data with a random 
number ID


— Hendrik


signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] The pool is shrinking

[Hendrik Visage]

> On 16 Aug 2019, at 22:45 , Stefan Claas  wrote:
> 
> O.k. I understand your point, but what I like to say is that I or anybody
> else can download a dump without running a key server. While running a
> key server requires a dump, it would be really nice if dumps are only
> available to a (trusted) pool of operators, as long as the current SKS
> model is still available on the Internet.

Well… here you’ll have to define “trusted”… Am I (being a South African with 
SKS servers in South Africa, France, Canada &  Singapore) being trust worthy 
for a GDPR? Which of my servers may or may not peer with each other as a side 
note? Now if I load a dump in FRance, may I peer with my RSA server? or should 
I load the dump in RSA and peer with my France server? If I receive a GDPR take 
down, does it only apply to my server(s) in France, or what if my RSA servers 
are providing a VPN/TOR endpoint via a FRance server, is that also under the 
GDPR?

The fact that the dumps exist, ACROSS THE GLOBE, makes any GDPR related 
discussion IMHO a very mute point once the data have entered the SKS server 
network.

It’s like unseeing a naked photo of person… it’s just not “possible”.

I would echo what everybody should know and understand: a PUBLIC KEY is by 
definition *PUBLIC*, NOTHING PRIVATE about it… BY DEFINITION.

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

Hendrik





signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] The pool is shrinking

[Hendrik Visage]

> On 16 Aug 2019, at 18:01 , Andrew Gallagher  wrote:
> 
> Signed PGP part
> On 16/08/2019 16:13, Stefan Claas wrote:
>> It should tell users that SKS operators share no dumps with 3rd
>> parties for key analysis, i.e. social graph research etc. Those
>> who publish a warrant canary can stay in the pool, while others
>> who don't like to do so will be excluded from the pool.
> 
> That's an utterly worthless exercise, considering that keyserver
> operators can't vouch for any other keyserver operators, and any or all
> of them could be three-letter agencies in disguise. You don't need a
> warrant to scrape publicly-available data, and you don't need to be in
> the pool to sync with pool keyservers.

Not to mention that the latest dumps are publicly available for syncing 
purposes...



signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

[Sks-devel] Exploiting GDPR (Re: The pool is shrinking)

[Hendrik Visage]

And then reading Cryptogram this month:
https://www.schneier.com/blog/archives/2019/08/exploiting_gdpr.html 
<https://www.schneier.com/blog/archives/2019/08/exploiting_gdpr.html>

Exploiting GDPR to Get Private Information

[2019.08.13] A researcher abused the GDPR to get information on his fiancee:

It is one of the first tests of its kind to exploit the EU's General Data 
Protection Regulation (GDPR), which came into force in May 2018. The law 
shortened the time organisations had to respond to data requests, added new 
types of information they have to provide, and increased the potential penalty 
for non-compliance.

"Generally if it was an extremely large company -- especially tech ones -- they 
tended to do really well," he told the BBC.

"Small companies tended to ignore me.

"But the kind of mid-sized businesses that knew about GDPR, but maybe didn't 
have much of a specialised process [to handle requests], failed."

He declined to identify the organisations that had mishandled the requests, but 
said they had included:

a UK hotel chain that shared a complete record of his partner's overnight stays
two UK rail companies that provided records of all the journeys she had taken 
with them over several years
a US-based educational company that handed over her high school grades, 
mother's maiden name and the results of a criminal background check survey.


> On 15 Aug 2019, at 15:57 , Stefan Claas  wrote:
> 
> Robert J. Hansen wrote:
> 
>> I'm going to believe the privacy lawyer I pay $450 an hour to more than
>> I'm going to trust a sketchy website that's not even officially
>> affiliated with the EU.
> 
> Well, it was just one of many example sites, when one is googling
> for "has the US comply to the GDPR". If one does the same he will
> also find US sites giving US citizens advice.
> 
>> Quoting from it:
>> 
>> "You may be wondering how the European Union will enforce a law in
>> territory it does not control."
>> 
>> Yep.
>> 
>> "The fact is, foreign governments help other countries enforce their
>> laws through mutual assistance treaties and other mechanisms all the time."
>> 
>> Yep.  Except that in America, the government *can't* help enforce many
>> parts of the GDPR.  The courts prohibit them from doing it.  You walk
>> into an American court waving a GDPR writ and it doesn't matter how many
>> EU bureaucrats sign it: if it intrudes on an American citizen's freedom
>> of speech the government is prohibited from participating.  This is
>> bog-standard American Constitutional law.
> 
> 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?
> 
> 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.
> 
>> It does not apply to US companies, except those that have business units
>> in the EU or have extensive business ties with the EU.
> 
> Has an US SKS key server operator then not 'business' ties with EU
> citizens, when storing their personal data like name and email address?
> 
> And has Mr. Rude then the right to freely distribute this data, without
> protecting it, to the whole world? If that is the case then EU citizens
> having 'business' with the US can do the same with US citizens data.
> 
> Well, just my thoughts.
> 
> 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

---
Hendrik Visage
HeViS.Co Systems Pty Ltd
T/A Envisage Systems / Envisage Cloud Solutions
+27-84-612-5345 or +27-21-945-1192
hvis...@envisage.co.za





signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] The pool is shrinking

[Hendrik Visage]

> On 15 Aug 2019, at 00:29 , Stefan Claas  wrote:
> 
> https://gdpr.eu/compliance-checklist-us-companies/ 
> <https://gdpr.eu/compliance-checklist-us-companies/>

Interesting wordings, ie.

The law also includes the threat of large fines for non-compliance, which can 
reach 4% of global revenue or €20 million, depending on the severity and 
circumstances

We recommend

So far, the EU’s reach has not been tested,

can help avoid drawing scrutiny from EU regulatory authorities

---
Hendrik Visage




signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] The pool is shrinking

[Hendrik Visage]

Yakamo,

 Hmmm… please define/explain how servers hosted in the Republic of South Africa 
is subjected to GDPR? (We have our own/similar version, but NOT GDPR)



> On 13 Aug 2019, at 15:59 , st...@yakamo.org wrote:
> 
> They are!
> 
> Yakamo
> 
> On Tue, 13 Aug 2019 08:57:37 -0500
> Travis Megee  wrote:
> 
>> You're also assuming all admins are subject to GDPR.
>> 
>> Travis
>> 
>> On 8/13/2019 8:56 AM, st...@yakamo.org wrote:
>>> Also would like to point out that this is Kristian covering his own ass not 
>>> the admins!
>>> 
>>> Please read it again!
>>> 
>>> Yakamo
>>> 
>>> 
>>> On Tue, 13 Aug 2019 15:46:39 +0200
>>> Tobias Frei  wrote:
>>> 
>>>> Hi Yakamo,
>>>> 
>>>> Have you already seen these two messages?
>>>> 
>>>> https://lists.nongnu.org/archive/html/sks-devel/2019-02/msg00070.html
>>>> 
>>>> https://lists.nongnu.org/archive/html/sks-devel/2019-03/msg00026.html
>>>> 
>>>> Best regards
>>>> Tobias Frei
>>>> 
>>>> Am 13.08.19 um 15:41 schrieb st...@yakamo.org:
>>>>> Hi Boti,
>>>>> 
>>>>> SKS servers are breaking the GDPR in multiple ways, its just a matter of 
>>>>> time before something happens.
>>>>> 
>>>>> All it would take is one motivated person and things get serious real 
>>>>> quick.
>>>>> 
>>>>> Especially i would say right now for the admin of mattrude or any others 
>>>>> allowing the free distribution to any third party of the keys via dumps, 
>>>>> without user consent which doesnt work with the GDPR at all, this is sure 
>>>>> to turn to a nightmare real fast for those admins.
>>>>> 
>>>>> Yakamo
>>>>> 
>>>>> 
>>>>> On Tue, 13 Aug 2019 09:02:20 +0200
>>>>> b...@makacs.duf.hu wrote:
>>>>> 
>>>>>> In many country of EU there were a period of patience to let firms fully 
>>>>>> covers their GDPR implementation.
>>>>>> 
>>>>>> However we have GDPR in effect last two years but authorities still had 
>>>>>> a so called "soft" penalty or no penalty just warn practice which is 
>>>>>> nearly over.
>>>>>> 
>>>>>> In mid and longer term the penalty fees will be harmonized. Today every 
>>>>>> country has its own penalty fees and penalty practice.
>>>>>> 
>>>>>> There is no more exceptions anymore such as it is technically impossible 
>>>>>> to delete data, etc.
>>>>>> 
>>>>>> So will the blockchain illegal among with sks in EU if stored data has 
>>>>>> PI records?
>>>>>> 
>>>>>> Cheers,
>>>>>>Boti
>>>> ___
>>>> 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

---
Hendrik Visage
HeViS.Co Systems Pty Ltd
T/A Envisage Systems / Envisage Cloud Solutions
+27-84-612-5345 or +27-21-945-1192
hvis...@envisage.co.za





signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] The pool is shrinking

[Hendrik Visage]

> On 21 Jun 2019, at 15:14 , Kristian Fiskerstrand 
>  wrote:
> 
> Signed PGP part
> On 6/21/19 2:43 PM, Daniel Roesler wrote:
>> I'd love to keep my server in the pool consistently, but until
>> Issue #61 is resolved[1], my server will spike to 100% CPU for
>> several minutes and become unresponsive as it tries to deal with
>> the huge troll keys.
> 
> Sure, but this isn't an issue if you have multi-node cluster as the
> other servers will never recon at the same time, hence the requirement
> for hkps.
> 
>> Running a server in the pool is no longer
>> a hobby project, and you have to constantly be restarting or
>> reconfiguring your server to keep it running.
> 
> Not that much, but you need at least 8 GiB of RAM allocated for each
> node and sufficient swap or recon will often get OOM-killed.

The word “cluster” there is the “problem” for hobby setups: we now have to 
source at least 2x 8GB RAM VMs, where the previous single 2-4GB VMs were 
sufficient to keep going

> --
> 
> Kristian Fiskerstrand
> Blog: https://blog.sumptuouscapital.com
> Twitter: @krifisk
> 
> Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
> fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
> 
> Corruptissima re publica plurimæ leges
> The greater the degeneration of the republic, the more of its laws
> 
> 
> 

---
Hendrik Visage
HeViS.Co Systems Pty Ltd
T/A Envisage Systems / Envisage Cloud Solutions
+27-84-612-5345 or +27-21-945-1192
hvis...@envisage.co.za





signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] Key updates not propagating

[Hendrik Visage]

Yes,

 With the poison key issues that started last year, I have neglected the  
cryptokeys.(co|org|net).za instances ;(

I fear I need to reload DBs on them, which unfortunately takes human time and 
effort, and then the single threaded nature of the SKS software
then fails on the next problem key, pull down the service (running on not the 
fastest VPS instances), and we have again a “weakly connected” case… it’s not 
the connectedness that is the issue(s), but the SKS software that fails and 
needs lots of TLC to get going again.

No offense taken, though duly noted I need to schedule time and effort on them 
again ;(

> On 19 Jan. 2019, at 00:55 , Andrew Gallagher  wrote:
> 
> 
>> On 18 Jan 2019, at 17:47, Alain Wolf  wrote:
>> 
>> While sks1.cryptokeys.org.za is listing pgpkeys.urown.net as peer. It
>> is not cross-peered back by pgpkeys.urown.net.
> 
> Of course. Please don’t take anything I say as an accusation against either 
> yourself or any other particular keyserver operator. These things happen (I 
> was a less than exemplary pool member for several years!). The problem is not 
> that there are keyservers that don’t gossip efficiently with peers, but that 
> weakly connected keyservers can remain in the pool regardless.
> 
> A
> 
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel




---
Hendrik Visage
HeViS.Co Systems Pty Ltd
T/A Envisage Systems / Envisage Cloud Solutions
+27-84-612-5345 or +27-21-945-1192
hvis...@envisage.co.za





signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] Blacklisting on UID?

[Hendrik Visage]

Hi Thorsten,

 I believe the problem have been highlighted that the SKS keyservers are a very 
easily abused infrastructure with things like the photos etc.
not to mention big keys that caused other denial of service type attacks on the 
server infrastructure.

 The question perhaps, is:
 How critical is this SKS type infrastructure for whom?

 It’s not DNS nor BGP type critical for the internet, so who do feels this is 
critical?
And if it is critical for somebody, those somebodies might need to put up their 
hands and start to perhaps rethink the keys, the infrastructure,
consider what have been learned recently etc. and then we might have a way to 
go forward in a bit more “protected way.

Just these few months I’ve been “involved”, I noticed the following:

- the keys might need to be formally specified -> how do you chec that is 
acually a proper key??
-  size and format of userID etc.
- images might need to be dropped.
- filters for EU/etc. privacy specifications??

So yes, things like the magnet URIs might just be getting more prolific until 
we might need to be forced to shutdown ;(

> On 29 Aug 2018, at 18:52 , Thorsten Bro | openSUSE Heroes  
> wrote:
> 
> Hi all,
> 
> I read this just yesterday and checked it on our instance - and
> unfortunately - I found a lot of magnet URIs on our keyserver.
> 
> https://medium.com/@mdrahony/sks-keyservers-being-used-as-piracy-sites-59ce5144101f
> 
> This might be a copyright problem for organizations and companies
> running SKS keyservers and I have an evaluation ongoing if openSUSE can
> still provide an SKS keyserver if we face this issue.
> 
> Are there any plans for blacklisting or filtering specific GPG UIDs by
> pattern in the sks server or database?
> 
> Cheers,
> 
> --
> 
> Thorsten Bro 
> - Member of openSUSE Heroes -
> 
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel

---
Hendrik Visage
HeViS.Co Systems Pty Ltd
T/A Envisage Systems / Envisage Cloud Solutions
+27-84-612-5345 or +27-21-945-1192
hvis...@envisage.co.za





signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

[Sks-devel] 32bit UID spam/flood attack ?

[Hendrik Visage]

https://www.hactrn.net/blog/2018/06/11/32-bit-pgp-keyid-delenda-est/ 
<https://www.hactrn.net/blog/2018/06/11/32-bit-pgp-keyid-delenda-est/>

Anybody else seen/aware of this on the SKS servers?

---
Hendrik Visage
HeViS.Co Systems Pty Ltd
T/A Envisage Systems / Envisage Cloud Solutions
+27-84-612-5345 or +27-21-945-1192
hvis...@envisage.co.za





signature.asc
Description: Message signed with OpenPGP
___
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

[Hendrik Visage]

> On 14 Jul 2018, at 13:27 , Tom at FlowCrypt  wrote:
> 
> > How do you propose to validate the email address?
> 
> I'm using a library to parse the uid as email, name and a comment. For the 
> email, I'm using a very, very long regex. Of the 5M keys available in SKS 
> dumps, very few uids are miscategorized.
> 
> It may be hard to do with 100% accuracy, but it's unsurprisingly easy do well 
> enough.

The words “machine learning” comes to mind… wonder if somebody with 
Amazon/Google/Azure contacts might be able to reach out and ask for 
sponsorship???


---
Hendrik Visage
HeViS.Co Systems Pty Ltd
T/A Envisage Systems / Envisage Cloud Solutions
+27-84-612-5345 or +27-21-945-1192
hvis...@envisage.co.za





signature.asc
Description: Message signed with OpenPGP
___
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

[Hendrik Visage]

> On 14 Jul 2018, at 13:04 , Gabor Kiss  wrote:
> 
>>> Then let's drop keys that don't contain a valid email address in the key id.
>> 
>> How do you propose to validate the email address?
>> 
>> (Hint: this is a surprisingly hard problem.)
> 
> See also "web of trust" and "strong set".
> Addresses should/can be checked by humans worldwide who sign/certify the key.


I’ve been trying to get mine “signed” by Web-Of-Trust for years now… also not 
that “easy” ;(

---
Hendrik Visage
HeViS.Co Systems Pty Ltd
T/A Envisage Systems / Envisage Cloud Solutions
+27-84-612-5345 or +27-21-945-1192
hvis...@envisage.co.za





signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] Deployment question about non-public server with oneway feed

[Hendrik Visage]

> On 28 Jun 2018, at 11:14 , Steffen Kaiser  wrote:
> 
> On Wed, 27 Jun 2018, Steffen Kaiser wrote:
> > On Wed, 27 Jun 2018, Hendrik Grewe wrote:
> >
> >> This Setup reminds me of a recently asked question on this ML:
> >>
> >> http://lists.nongnu.org/archive/html/sks-devel/2018-06/msg00032.html
> >>
> >> hope this helps
> >
> > yes, http://lists.nongnu.org/archive/html/sks-devel/2018-06/msg00041.html
> > states that: "Unless recon is enabled in both directions, the key delta
> > will inevitably grow to the point that recon will fail."
> >
> > That means, recon / gossip is not possible and updates via email is the
> > only option left.
> 
> for the archive:
> 
> email updates don't work as well. I set up three systems with a SKS system
> each:
> 
> + system A and system B are configured to gossip with each other, thus,
> simulating the normal outside SKS peers / SKS cloud,
> + system C is my local installation, that must not talk to the outside,&
> + system B sync's via mail to system C (oneway).
> 
> If I upload a key to system B, it is sync'ed to C. If I upload a key to
> system A, it is sync'ed to B, but not forwared to C. So, mailsync is out
> as well.
> 

I also got the feeling that the mailsync was meant for when a  key is 
*directly* uploaded to a server, it is emailed out, not when it receives keys 
via the recon/whisper partners (Else every one will sent out emails with each 
and every sync, ie. >100mails/days…)

I think the (wish list) option to have a 1-way sync setting, ie. Any and all 
keys you receive, you forward in that direction, no matter whether that server 
have the key or not, ie. no-recon/whisper, just: “I’ve received this key, here 
it is”

---
Hendrik Visage
HeViS.Co Systems Pty Ltd
T/A Envisage Systems / Envisage Cloud Solutions
+27-84-612-5345 or +27-21-945-1192
hvis...@envisage.co.za





signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] keyserver1.computer42.org is dropping peers [but not keyserver2.computer42.org]

[Hendrik Visage]

 0x0007F724
> # keyserver.northernstandard.us.com  11370 #  David Clancy 
> 0x67DCE713
> # keyserver.linux.it 11370 # Marco Nenciarini 
>  0xF095E5E4
> # gpg.planetcyborg.de11370 # Moritz  Rudert 0x4941485B
> # keys-01.licoho.de  11370 # admin 
>  0xECB2FEC3
> # keys-02.licoho.de  11370 # admin 
>  0xECB2FEC3
> # keyserver.mesh.deuxpi.ca   11370 # Philippe Gauthier 0xD8E07AFA
> # sks.nimblesec.com  11370 # James Thomas 0xE600C820
> # key-server.nl  11370 # Wijnand Modderman-Lenstra 
>  0x294DF221
> # keyserver.sincer.us11370 # Petru Ghita Sherar 
>  0x7CF29D04
> # sks.ecks.ca11370 # Eric Benoit  
> 0x69E65D2C
> # keyserver.mpi-bremen.de11370 #   
> 0x8A485A10
> # sks.research.nxfifteen.me.uk   11370 # Stuart McCulloch Anderson 
>  A7EEB609
> # keyserver.nausch.org   11370   # Michael Nausch 
>  #0x2384C849
> # keys.s-l-c.biz 11370 # Simon Lange  
> 0xBDD503BE
> # pgp.jjim.de11370 # Joel Garske  
> 0xA921EB20
> # sks.rainydayz.org  11370 # Admin  
> 0xE20840AC
> # keyserver.ut.mephi.ru  11370 # NRNU MEPhI, Dmitry Yu Okunev
> # keys.jhcloos.com   11370 # James Cloos  
> 0xED7DAEA6
> # keyserver.skoopsmedia.net  11370 # Adam Lewicki 0xF3E88A9F
> # openpgp1.claruscomms.net   11370 # ClarusComms OpenPGP Services 
>  0x2D6ED5C0
> # keys.exosphere.de  11370 # Christoph Gebhardt 
>  0xE1C2E92C
> # sks.parafoil.net   11370 # Parke Bostrom 
>  0x74E84137
> # liberty.antagonism.org 11370 # Patrick R McDonald 0xA2D1E972
> # sks.fidocon.de 11370 # Dirk Astrath 0x8351e0af or 
> 0x2840c708
> # keyserver.adamas.ai11370 # Tyler Durden (Big Brother is 
> watching)  0x2A2CF11B
> # schluesselkasten.wertarbyte.de 11370 # Stefan Tomanek 0xAC2C9AAB
> # keys.internet-sicherheit.de11370 # Stefan Tomanek 0xAC2C9AAB
> # key1.dock23.de 11370 # Ramón Goeden 
>  0xb7c51fd6
> 
> 
> If you're sure that your server is stable and not affected by the malicious 
> key problem contact me for activating the peering again.
> 
> Best Regards,
> 
> H.-Dirk Schmitt
> 
> --
> 
> H.-Dirk Schmitt
> Dipl.Math.
> 
> eMail:dirk.schm...@computer42.org
> mobile:+49 177 616 8564
> phone: +49 2642 99 41 14
> fax: +49 2642 99 41 15
> Schillerstr. 42, D-53489 Sinzig
> 
> pgp: http://www.computer42.org/~dirk/OpenPGP-fingerprint.html
> 
> 
> 

---
Hendrik Visage
HeViS.Co Systems Pty Ltd
T/A Envisage Systems / Envisage Cloud Solutions
+27-84-612-5345 or +27-21-945-1192
hvis...@envisage.co.za





signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] One Way replication (for test environments)

[Hendrik Visage]

Well, the idea would be for these “researchers” to play with, and at least have 
something “newish” where I have some ingress point that propagates to some 
others,

> On 17 Jun 2018, at 14:59 , Andrew Gallagher  wrote:
> 
> You can’t do it using recon, because any additions to the test server will 
> cause the key delta to diverge and recon will eventually fail.

Do you mean that the recon *needs* a similar from the destination? I don’t 
really care about it failing, it’ll then be a re-spin as you said below, but 
for example, the idea might be to inject problem keys into the tet environment, 
and the test environment’s problem keys not to “infest” the current public SKS 
keyservers.

> The easiest way might be a docker image that pulls the latest dump from one 
> of the public dump sources and spins up a fresh SKS instance from it. Then if 
> you want to update the key database, you just redeploy the docker image.


The type of troubles we saw, I read as something that was caused as the updates 
was being recon’s between servers, after the problem keys was already injected, 
thus the idea would be multiple servers to test against, having some ingres 
feeeds from the public servers, but no egress to the public side. Might be good 
for others to test there “test certs/keys” against before actual publication??

---
Hendrik Visage




signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

[Sks-devel] One Way replication (for test environments)

[Hendrik Visage]

I’m considering setting up some test environments for the “researchers” to test 
the SKS keyservers, but I was wondering about one way replication, ie. one 
server that will only sent out to the test server(s), but not receive from them.

What’s the easiest to set that up?

---
Hendrik Visage
HeViS.Co Systems Pty Ltd
T/A Envisage Systems / Envisage Cloud Solutions
+27-84-612-5345 or +27-21-945-1192
hvis...@envisage.co.za





signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] SKS apocalypse mitigation

[Hendrik Visage]

> On 26 Mar 2018, at 01:39 , Michael Jones <m...@mikejonesey.co.uk> wrote:
> 
> What if the approach was to either have a web of trust to whitelist users 
> able to upload images, or even more stringent strip all image data.
> 
> Is image data essential to operating?
> 

I’d make the case, that it might actually be not far in the future, that we’ll 
*need* to remove it to keep the database size(s) intact, and
looking at the current size, I’d argue we’d want to remove the images already.

> I hardly ever look at the images, and these images could be shared via other 
> means.
> 
Exactly, sent an email, look at an URL with the signed picture…
---
Hendrik Visage





signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] TLS 1.3 and HKPS pool

[Hendrik Visage]

> On 19 Mar 2018, at 23:14 , Kristian Fiskerstrand 
> <kristian.fiskerstr...@sumptuouscapital.com> wrote:
> 
> On 03/19/2018 10:08 PM, Phil Pennock wrote:
>> Do we care?
> 
> I'm tempted to say no..

> Now.. if anyone were to actually disable everything but 1.3, that'd be
> exclusion worthy from the pool, but lets do this manually if so.


I’ve not seen and TLS1.2 security issues yet (but then I might’ve missed it in 
the deluge of meltdown/spectre/memcached) so I don’t see the need/reason to 
disable TLS1.2

---
Hendrik Visage
HeViS.Co Systems Pty Ltd
T/A Envisage Systems / Envisage Cloud Solutions
+27-84-612-5345 or +27-21-945-1192
hvis...@envisage.co.za





signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] Operational question for all

[Hendrik Visage]

> On 14 Mar 2018, at 07:26 , Jeremy T. Bouse <jeremy.bo...@undergrid.net> wrote:
> 
> I've been running my SKS cluster under Docker for awhile now and my
> current Docker cluster is currently Tango Uniform it would appear (hence
> sks.undergrid.net being offline still). I've got an ECS (Docker-based)
> cluster already running and operational in AWS that I could move the
> service over to however the issue that has kept me from doing so is the
> operational difference it would incur. Looking to get some opinions and
> see if I'm overthinking it or if I'd be good to go.
> 
> First of all the cluster is in a private subnet with no direct
> internet so it gets NAT'd outbound from an IP address that would not
> match the inbound IP address to be used.

From what I’ve seen thus far, the gossipping/recon coming from an IP that’s not 
resolving
from those names in the membership file, gets ignored.

That might be a version 2 feature request: have peers authenticated not based 
on IP, but pub/private keys


---
Hendrik Visage
HeViS.Co Systems Pty Ltd
T/A Envisage Systems / Envisage Cloud Solutions
+27-84-612-5345 or +27-21-945-1192
hvis...@envisage.co.za





signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] seeking peers for pgp.securitytext.org

[Hendrik Visage]

> On 13 Mar 2018, at 07:54 , Alain Wolf  wrote:
> 
> Hello PGP Key Server Administrator
> 
> I don't think this setup will make it into the pool:
> 
> * pgp.securitytext.org points to a Cloudflare IP, which does not answer
>   to OpenPGP clients on TCP port 11371.

Yeah, that definitely won’t work for SKS

> * I can't connect to dualstack.pgp.securitytext.org, neither on TCP
>   port 11370 nor 11371

could you connect to the ipv4/ipv6 versions? they are but the separate IPs for 
dualstack.

> On 13.03.2018 05:51, PGP Key Server Administrator wrote:
>> Apologies for the incorrect member entries. Corrected ones below:
>> 
>> ipv4.pgp.securitytext.org  11370 # PGP Key 
>> Server Administrator > 
>> 0x169508A9
>> ipv6.pgp.securitytext.org  11370 # PGP Key 
>> Server Administrator > 
>> 0x169508A9
>> dualstack.pgp.securitytext.org  11370 
>> # PGP Key Server Administrator > > 0x169508A9

This will end up as three different servers in the SKS pool, even though they 
are the same server? rather just advertise the dualstack, en drop the 
CloudFlare as already pointed out ;)


>>I am looking for peers for a new SKS keyserver installation.
>> 
>>I am running SKS version 1.1.5, on pgp.securitytext.org 
>> .

This also won’t make it into the pool. I suspect it’s a Debian/Ubuntu setup? 
Get the 1.1.6 software that’s needed to make it into the pool.

See https://roll.urown.net/server/pgp-keyserver.html 
 for guides to setup SKS 
server.

>>We are a registry for security.txt files, which utilize OpenPGP keys.

Something to Google laterz when Ops issues resided :)




signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

[Sks-devel] sks?.inx.net.za peers please

[Hendrik Visage]

Good day,

Looking for peers for the following servers in South Africa:

sks1.inx.net.za 11370 # JNB: Hendrik Visage <hvis...@envisage.co.za> 
0x9c1384b1168fd423 / Nishal Goburdhan <nis...@inx.net.za> 0x97db45a1fcd1545f
sks2.inx.net.za 11370 # CTN: Hendrik Visage <hvis...@envisage.co.za> 
0x9c1384b1168fd423 / Nishal Goburdhan <nis...@inx.net.za> 0x97db45a1fcd1545f
sks3.inx.net.za 11370 # DBN: Hendrik Visage <hvis...@envisage.co.za> 
0x9c1384b1168fd423 / Nishal Goburdhan <nis...@inx.net.za> 0x97db45a1fcd1545f


---
Hendrik Visage
HeViS.Co Systems Pty Ltd
T/A Envisage Systems / Envisage Cloud Solutions
+27-84-612-5345 or +27-21-945-1192
hvis...@envisage.co.za





signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] pool for Africa?

[Hendrik Visage]

> On 06 Feb. 2018, at 18:53 , Andrew Gallagher <andr...@andrewg.com> wrote:
> 
> On 06/02/18 16:45, Hendrik Visage wrote:
>> Good day,
>> 
>>  As I’m busy setting up and deploying SKS servers at INX)ZA sites (three
>> at present) and some of the other African peering points, the question
>> arose: how many servers would be needed to make a sensible pool for Africa?
> 
> There is an inbuilt assumption here, which is that "Africa" is a
> meaningful division in the first place. In the world of network
> topology, many African countries - particularly in the north - are
> better connected to Europe than they are to their African neighbours…

Granted, for the North then the eu.pool would be more appropriate :)

Thus, perhaps I should then re-phrase: “A southern and  eastern Africa pool”
The group that I envisage to be part of that pool, have usually reasonable 
inter connections, and the deployments are to be at INXs, and at minimum 
intra-peering within these servers at the INXs.



signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

[Sks-devel] pool for Africa?

[Hendrik Visage]

Good day,

 As I’m busy setting up and deploying SKS servers at INX)ZA sites (three at 
present) and some of the other African peering points, the question arose: how 
many servers would be needed to make a sensible pool for Africa?

---
Hendrik Visage
HeViS.Co Systems Pty Ltd
T/A Envisage Systems / Envisage Cloud Solutions
+27-84-612-5345 or +27-21-945-1192
hvis...@envisage.co.za





signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

[Sks-devel] dump-only server (gossip but not public pool availability)

[Hendrik Visage]

Good day,

 As I can’t dump the SKS database while running, and the file snapshot setup 
not quite feasible for my setup(s) yet, I was wondering about a gossiping only 
server (and only gossiping to a limited set servers close peers) that isn’t 
connected/advertised to the SKS pool.
 This would then be a server I could easily take offline and dump keys every so 
often, not impacting the pool availability etc.

Which settings should I use to achieve the above, as it seems the moment I 
start the server, it starts to broadcast it’s availability to be included in 
the pool?

---
Hendrik Visage
HeViS.Co Systems Pty Ltd
T/A Envisage Systems / Envisage Cloud Solutions
+27-84-612-5345 or +27-21-945-1192
hvis...@envisage.co.za





signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

[Sks-devel] Descriptive error meesages

[Hendrik Visage]

Good day,

 I guess this is the point where I’ll have to start adding some extra digits to 
my body to count another programming language:

==> recon.log <==
2018-01-29 18:05:16  error in callback.: Sys_error("Connection 
reset by peer")

I’m seeing these type of error messages, which is great to know that it 
happened, but it begs the question: Who/what was the peer that reset the 
connection?
The reverse side (As I’m having the two separate servers talking) is then also: 
“Which client did I refuse, and ‘cause of what reasons?”

So let’s ask it this way: (1) advised OCAML reference & tutorial guides?
(2) Where should I start looking for these errors messages to help enhance them?

---
Hendrik Visage
HeViS.Co Systems Pty Ltd
T/A Envisage Systems / Envisage Cloud Solutions
+27-84-612-5345 or +27-21-945-1192
hvis...@envisage.co.za





signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

[Sks-devel] SKS behind NAT firewall

[Hendrik Visage]

Hi there,

 Anybody else running a SKS behind a NAT firewall?
Could you perhaps share any advice on the recon/hkp settings? (I’ll be setting 
up/running nginx reverse proxy for HKP)

 Or should I rather have the outside IP bound to a virtual/loopback interface, 
and then route it directly via the firewall to the SKS server?

Reason I’m asking: I’m not quite clear in understanding the recon settings, and 
I’d rather ask experience before I chase down the wrong alley.

---
Hendrik Visage
HeViS.Co Systems Pty Ltd
T/A Envisage Systems / Envisage Cloud Solutions
+27-84-612-5345 or +27-21-945-1192
hvis...@envisage.co.za





signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] Debian asks package and default paths

[Hendrik Visage]

Thanks for the explanation Daniel

> On 23 Jan. 2018, at 18:18 , Daniel Kahn Gillmor  
> wrote:
> 
> On Tue 2018-01-23 10:51:54 +0100, Alain Wolf wrote:
>> I would try to change desired filepaths in
>> debian/patches/0001-use-debian-fhs.patch
> 
> Hi there--
> 
> I'm one of the current maintainers of the debian package.
> 
> this patch is intended to put sks in compliance with the filesystem
> hierarchy.
> 
> however, i'm not convinced that the patches in the debian package are
> the right thing for debian today, since they basically hardcode a single
> path (and make it difficult to run two instances of sks on the same
> machine, for example).  I'd welcome any proposals people have that:
> 
> a) retain the default filesystem placement to stay in line with the
>filesystem hierarchy standard (FHS)

Well… FHS makes sense…. up to the point that I’m deploying each service in
it’s own set of mountpoints (ala old-style unix when disks was small, like in 
VMs
today with OS disk separate from the data disks)

> b) enables running multiple keyservers on a given host

That is what base_dir: is suppose to achieve, isn’t it?

> c) people can upgrade their existing installations without too much
>pain

Yes, that’s the part that always becomes a problem  in special setups...

> d) (optional) can be merged upstream so that we don't carry patches :)
> 
> If i had more time, i'd experiment with dropping the patch completely,
> and setting up a symlink approach in /etc/sks/ but i'm not sure whether
> that would work; or if it works, if it would horrify anyone.

I’d personally rather prefer a configuration file/settings I could modify/tweak
w.r.t. those files/etc., then it’ll be much easier to have multiple SKS 
services on the
same server/VM.

> Anyway, i'm just saying that just because it's this way today, it
> doesn't have to be this way forever.  feedback welcome :)

As it’ll be a recompile/repackage to achieve my goals (other than symlinks all 
over the show)
I’ll have a look as see what I can contribute back.


signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] Debian asks package and default paths

[Hendrik Visage]

> On 23 Jan. 2018, at 11:51 , Alain Wolf  wrote:
>> 
>> strings does show that /var/log/sks/db.log is in the Debian packaged
>> /usr/sbin/sks file.
>> 
> 
> I would try to change desired filepaths in
> debian/patches/0001-use-debian-fhs.patch


Okay, that implies recompiling/packaging ;)

Thanks!



signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

[Sks-devel] Debian asks package and default paths

[Hendrik Visage]

Good day,

 Busy setting up a SKS keyserver, and wants to have a separate /sks filesystem, 
and before I start to add symlinks
all over the place, or re-compile SKS, I was wondering how/where to override 
the defaults in the configuration files.

I’ve already set base_dir: /sks2/sks/db, but then I still get this:
Fatal error: exception Sys_error("/sks2/sks/db//var/log/sks/db.log: No such 
file or directory”)

strings does show that /var/log/sks/db.log is in the Debian packaged 
/usr/sbin/sks file.

---
Hendrik Visage
HeViS.Co Systems Pty Ltd
T/A Envisage Systems / Envisage Cloud Solutions
+27-84-612-5345 or +27-21-945-1192
hvis...@envisage.co.za





signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel