I believe this list is web accessible to non-subscribers, so being subscribed
here or not subscribed here doesn’t mean much. Just that if you post here
someone who is willing to do this attack (maybe not even the original someone -
this is an attack literally anyone can do) is reading what you
On 06/07/2019 12:50, Ryan McGinnis via Gnupg-users wrote:
> Someone brought it to my attention that my key is now one of the
> affected keys; I think from this we can probably surmise that whoever(s)
> is doing this probably reads this list as this email address doesn’t see
> heavy circulation.
If
Since the list archives can be read by anyone, it's obvious the possible
wrongdoers are monitoring the list closely, and can take any and all
suggestions into account, to adapt further goals.
Sincerely,
Konstantin Boyandin
Ryan McGinnis via Gnupg-users wrote 2019-07-06 18:50:
Someone brought
Someone brought it to my attention that my key is now one of the affected keys;
I think from this we can probably surmise that whoever(s) is doing this
probably reads this list as this email address doesn’t see heavy circulation.
-Ryan McGinnis
https://bigstormpicture.com
PGP: 5C73 8727 EE58 786
Konstantin Boyandin via Gnupg-users [2019-07-05T20:45:59-04:00] wrote:
> ATM, none of systems I use GnuPG in has been hit with the signature
> flood disaster. If I might miss that point - is it possible to get,
> somehow, the list of flooded keys IDs (if anyone keeps the stats)?
I don't maintain
Hello,
Thanks to everyone who expressed their opinions (I read the thread, even
if I don't reply often). I didn't expect the discussion would become so
red-hot, however.
There's a Russian saying with closest English translation "two movings
are as devastating as one fire". I assume that transitio
Wiktor Kwapisiewicz wrote:
> On 03.07.2019 17:33, Stefan Claas via Gnupg-users wrote:
> > Regarding my keybase presence, I can immediately close down my account
> > and my data and the data from my followers is removed, cool eh?
>
> I did a small experiment and it seems that your data is permanen
On 05.07.2019 11:26, Peter Lebbing wrote:
PS: Before you blame archive.org: they respect robots exclusions and
wishes from individual site owners. It was keybase.io which allowed it
in the first place, although it may or may not have been a conscious
decision on their part.
To be honest I'd con
On 05/07/2019 11:15, Wiktor Kwapisiewicz via Gnupg-users wrote:
> I did a small experiment and it seems that your data is permanently
> preserved in sigchains of all people that follow you. Even if you
> delete your account.
Plus, the data is preserved in different places such as archive.org,
whic
On 03.07.2019 17:33, Stefan Claas via Gnupg-users wrote:
Regarding my keybase presence, I can immediately close down my account
and my data and the data from my followers is removed, cool eh?
I did a small experiment and it seems that your data is permanently
preserved in sigchains of all peop
To be fair, that bookshelf got pointed out like a decade ago. It’s just that
resources to build a new one never materialized.
While pointing out a problem by doing a targeted demonstration attack is about
as aggressively black hat as it gets, it’s hard to not expect it. Even big
white hat boys
To be fair, that bookshelf got pointed out like a decade ago. It’s just that
resources to build a new one never materialized.
While pointing out a problem by doing a targeted demonstration attack is about
as aggressively black hat as it gets, it’s hard to not expect it. Even big
white h
On 03/07/2019 18:37, Stefan Claas via Gnupg-users wrote:
> Why so upset?
>
> I think I am allowed here to post my opinion and I do no "force"
> people.
You just said that if only you had the time and money, you would try to
take down the SKS network using a legal procedure. A procedure meant to
o
Peter Lebbing wrote:
> On 03/07/2019 17:33, Stefan Claas via Gnupg-users wrote:
> > Mmmhhh...Peter, if I should do this it should serve as help guideline
> > for users wishing to do the same.
> >
> > Why?
>
> Pfah. Stop rationalising. If this is your concern, create a website
> where your offer
On 03/07/2019 17:33, Stefan Claas via Gnupg-users wrote:
> Mmmhhh...Peter, if I should do this it should serve as help guideline
> for users wishing to do the same.
>
> Why?
Pfah. Stop rationalising. If this is your concern, create a website
where your offer your services to people wishing to do
Stefan Claas via Gnupg-users wrote:
> Regarding my keybase presence, I can immediately close down my account
> and my data and the data from my followers is removed, cool eh?
One more thing... You uploaded your keys with friends signatures to
an SKS server and you are activists in one area. Becau
Peter Lebbing wrote:
> On 03/07/2019 16:00, Stefan Claas via Gnupg-users wrote:
> > If I had time and money I would hire a lawyer, would formulate a letter
> > for SKS operators stating that I request the removal of my pub key data
> > and would as EU citizen refer in this letter to our GDPR.
On 03/07/2019 16:59, Stefan Claas via Gnupg-users wrote:
> Or do SKS key servers dictate how GnuPG's submission / receiving
> protocol must work?
It's in the reconsiliation protocol and the very foundation of the
assumptions of the synchronizing keyserver network. GnuPG doesn't come
anywhere near
On 03/07/2019 15:59, Stefan Claas via Gnupg-users wrote:
> Now, you awake my interest. You said it is the protocol, so let's
> say when Werner and his hackers has fixed the issue in GnuPG and
> for a protocol you usually have to sides, to work with, could that
> not mean then when Werner does x,y,z
On 03/07/2019 16:00, Stefan Claas via Gnupg-users wrote:
> If I had time and money I would hire a lawyer, would formulate a letter
> for SKS operators stating that I request the removal of my pub key data
> and would as EU citizen refer in this letter to our GDPR.
Do you object to your data being
Stefan Claas via Gnupg-users wrote:
> O.k. but as understood it is in active development and I thought,
> even if it is the protocol, that it would be easier to fix issues
> in hockeypuck than in SKS, due to the fact that Golang is more
> modern and has a bigger programmers community.
Now, you aw
On 03/07/2019 15:41, Stefan Claas via Gnupg-users wrote:
> O.k. but as understood it is in active development and I thought,
> even if it is the protocol, that it would be easier to fix issues
> in hockeypuck than in SKS, due to the fact that Golang is more
> modern and has a bigger programmers com
Andrew Gallagher wrote:
> On 03/07/2019 15:27, Stefan Claas via Gnupg-users wrote:
> > Sure, of course. Meanwhile SKS operators may check out hockeypuck (written
> > in Golang :-)), if that helps.
>
> It's the protocol that's broken, not the software. Migrating from SKS to
> hockeypuck doesn't (i
On 03/07/2019 15:27, Stefan Claas via Gnupg-users wrote:
> Sure, of course. Meanwhile SKS operators may check out hockeypuck (written
> in Golang :-)), if that helps.
It's the protocol that's broken, not the software. Migrating from SKS to
hockeypuck doesn't (in itself) fix the problems.
--
Andr
Andrew Gallagher wrote:
> On 03/07/2019 15:00, Stefan Claas via Gnupg-users wrote:
> > If I had time and money I would hire a lawyer, would formulate a letter
> > for SKS operators stating that I request the removal of my pub key data
> > and would as EU citizen refer in this letter to our GDPR.
On 03/07/2019 15:00, Stefan Claas via Gnupg-users wrote:
> If I had time and money I would hire a lawyer, would formulate a letter
> for SKS operators stating that I request the removal of my pub key data
> and would as EU citizen refer in this letter to our GDPR.
>
> Maybe, if time allows, I may
Vincent Breitmoser via Gnupg-users wrote:
>
> Friendly reminder: There are no developers working on SKS right now. Zero. No
> actual work has been done on SKS in years.
>
> - V
Correct. If I would be an SKS operator I would switch to your Hadgrid,
to support the PGP / GnuPG community.
If I ha
On Wed, 2019-07-03 at 03:01 -0700, Mirimir via Gnupg-users wrote:
> On 07/02/2019 11:42 PM, Michał Górny wrote:
> > Then, they may decide to start mass poisoning other keys just to
> > prove this is not the right solution.
>
> If what I propose is workable, attackers can poison as many keys as th
On 03.07.2019 11:06, Robert J. Hansen wrote:
Those two account for literally 99% of all use cases. The vast majority
of OpenPGP is to verify package signatures; for the small fraction that
use it for email, Enigmail is the most dominant choice, with GpgOL a
close second.
Yes. It seems distros
On 07/02/2019 11:42 PM, Michał Górny wrote:
> Dnia July 3, 2019 6:23:37 AM UTC, Mirimir via Gnupg-users
> napisał(a):
>> I don't think that it's necessary to stop using SKS keyservers. And I
>> suspect that doing so would be nontrivial. Given that requests to them
>> are likely hard-coded, or
On Wed, 3 Jul 2019 05:06, r...@sixdemonbag.org said:
> As I understand it the current list of targeted keys is myself, dkg,
> Werner, Patrick, and Kristian. It is clear the attacker's goal is to
I am not yet affected except for these few thousand old xmas fun
signatures.
> Werner will no doubt
Friendly reminder: There are no developers working on SKS right now. Zero. No
actual work has been done on SKS in years.
- V
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
> a. The entire SKS keyservers design and interaction has a fundamental
> design flaw named "unlimited resources assumption". I.e., it is assumed
> every server, every client has unlimited resources (to store signatures;
> to retrieve and process them - unlimited RAM/storage, unlimited network
> sp
Dnia July 3, 2019 6:23:37 AM UTC, Mirimir via Gnupg-users
napisał(a):
>On 07/02/2019 08:28 PM, Konstantin Boyandin via Gnupg-users wrote:
>> Hello All,
>>
>> After having read the recent multitude of messages related to SKS
>> keyservers related issue, I figured out that
>>
>> a. The entire SKS
On 07/02/2019 08:28 PM, Konstantin Boyandin via Gnupg-users wrote:
> Hello All,
>
> After having read the recent multitude of messages related to SKS
> keyservers related issue, I figured out that
>
> a. The entire SKS keyservers design and interaction has a fundamental
> design flaw named "unlim
Hello All,
After having read the recent multitude of messages related to SKS
keyservers related issue, I figured out that
a. The entire SKS keyservers design and interaction has a fundamental
design flaw named "unlimited resources assumption". I.e., it is assumed
every server, every client h
36 matches
Mail list logo