> On 4 Jul 2019, at 03:23, Ángel wrote:
>
> A point I don't like about the design of hagrid is that verification is
> performed by the server itself.
> Thus, it seems that if there were a reconciliation protocol between
> them, either entering into one of them would lead to all of them blindly
>
On 07/03/2019 10:19 PM, Mirimir wrote:
> Moved by Roland's requests, I've broken Enigmail in a fresh VM. And I'd
> appreciate some advice about how to fix it.
>
> I installed Thunderbird and Enigmail in a Debian 9.5 x64 VM with Gnome.
> Using Enigmail Key Management, I tried to get rjh's 1DCBDC
Moved by Roland's requests, I've broken Enigmail in a fresh VM. And I'd
appreciate some advice about how to fix it.
I installed Thunderbird and Enigmail in a Debian 9.5 x64 VM with Gnome.
Using Enigmail Key Management, I tried to get rjh's 1DCBDC01B44427C7
from pool.sks-keyservers.net, but that ju
On 2019-07-02 at 10:01 +0200, Wiktor Kwapisiewicz wrote:
> > It is a real shame that a decentralized Hagrid isn't really
> >possible, though, at least to my understanding. It's quite the
> >limitation for GnuPG.
>
> Decentralized non-identity information hagrid could still be
> possible.
> It's j
Hello Roland,
On 03/07/2019 15:00, Roland wrote:
> And for Enigmail: your suggestion or In the terminal, to edit
> ~/.gnupg/dirmngr.conf so as to say "keyserver
> hkps://keys.openpgp.org/" or, if that file does not exist to create it
> as per your suggestion.
I don't think Enigmail respects dirmn
On Wed, 3 Jul 2019 12:58, pe...@digitalbrains.com said:
> reached its intended goal: dirmngr said "re-reading config". It just
> didn't have an effect for some odd reason. For people thinking about
Check that you do not have a keyserver entry in your gpg.conf or
Enigmail is calling gpg with that
Thanks, Peter, for this confirmation.
You give further detail to what I had guessed in the course of playing
with the settings of GPA and Kleopatra.
I conclude that there are at least two possible actions for those who
want to protect there systems:
In the GUIs of GPA or Kleopatra to fiddle t
Hello Roland,
> Hansen's and DKG's blog are only partly helpful. For example my Linux
> system seems to *not* have a ~/.gnupg/dirmngr.conf file at all (one
> of those files recommended for editing). I.e. Nautilus cannot find it.
The usual case on Linux systems is that if a configuration file wou
On Tue, 2 Jul 2019 13:47, look@my.amazin.horse said:
> Huh, that's interesting. I was not aware of this issue, and wish you had
> reached
> out to me, or to supp...@keys.openpgp.org, or filed an issue on Hagrid.
I assumed that newly launched server software with the goal to take over
all existi
> Unless you are on Windows where the server can't be accessed because it
> uses a pretty limited set of TLS cipher suites. Thus the majority of
> GnuPG encryption users are out of luck.
Huh, that's interesting. I was not aware of this issue, and wish you had reached
out to me, or to supp...@ke
On Tue, 2 Jul 2019 10:01, gnupg-users@gnupg.org said:
> No such issues on keys.openpgp.org, gpg --send-key and the new updated
> key is immediately available with no time outs or delays.
Unless you are on Windows where the server can't be accessed because it
uses a pretty limited set of TLS ciph
Dear Forum,
GNUPG Users Digest is nearly flooding my mailbox with exchanges about
the WoT and keyserver issues.
A simple user (me) needs to know how one could make adaptations in the
settings of GPA or Kleopatra. I would expect instructions here:
https://kde.org/applications/utilities/org.kd
pg.org
You can reach the person managing the list at
gnupg-users-ow...@gnupg.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Gnupg-users digest..."
Today's Topics:
1. Re: Your Thoughts (Stefan Claas)
2. Re: SKS Keyserver
pg.org
You can reach the person managing the list at
gnupg-users-ow...@gnupg.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Gnupg-users digest..."
Today's Topics:
1. Re: Your Thoughts (Stefan Claas)
2. Re: SKS Keyserver
Hi Alyssa,
On 02.07.2019 00:43, Alyssa Ross wrote:
The impression I got was that they're very optimistic about their
ability to handle traffic to their server -- they were happy to have a
distro make the switch, and will be changing the defaults in Enigmail
and OpenKeychain very soon, as I under
> And yes, hkps://keys.openpgp.org would fall over and die if too many
> users started using it. So cert poisoning will be an issue until there's
> a secure alternative.
Just as a point of interest, I've talked to the people running
keys.openpgp.org about their capacity in #hagrid, when we were ex
Mirimir via Gnupg-users writes:
>>- Embeds a hardcoded list of already-disrupted keys for which packets
>> should be filtered-out when serving them
>
> That's what I meant. Plus some mechanism for testing keys, so poisoned
> ones are blocked, as soon as possible.
>
> It'd also be useful f
On 01/07/2019 10:54, Robert J. Hansen wrote:
>> I think not.
> Thankfully we live in free societies where dissent is allowed: on good
> days, even tolerated and encouraged. You're wrong, of course, but
> please understand I encourage you to be wrong. :)
>
> Also, if it isn't clear: although I emp
> Third-party signatures from locally unknown certificates are arguably
> not so useful, so how about using ?--keyserver-options import-clean??
> (Or even making it the default behavior?) Of course it's not perfect as
> it still clutters network traffic and gpg(1) needs to clean up the mess
> clie
On 01/07/2019 11:54, Robert J. Hansen wrote:
> [...]
I think this mail sums up the most important points about this whole
ordeal very well. I completely, wholeheartedly agree. I encourage
everyone to re-read it and internalise it.
The only point not touched upon in this specific mail, I think, is
> I think not.
Thankfully we live in free societies where dissent is allowed: on good
days, even tolerated and encouraged. You're wrong, of course, but
please understand I encourage you to be wrong. :)
Also, if it isn't clear: although I emphatically disagree with you, this
is not a personal di
On 30/06/2019 13:44, Robert J. Hansen wrote:
> This has all the hallmarks of a child playing with matches and
> clapping with glee as the house catches fire.
I think not.
You yourself say that the SKS system has had known problems for well
over a decade and yet nothing has been done about it. In
> I must have missed the memo
> describing the exact nature of the problem.
https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
> OK, that's great news. And I get from the HN thread that repository keys
> are updated via signed packages, with no calls to SKS keyservers. So I'm
> no longer freaking about that level of damage.
Eh. Yes. No. Hard to say. The problem is that many of these distros
allow third parties to run
On 06/30/2019 10:37 AM, Leo Gaspard via Gnupg-users wrote:
>> 1. We would have to ensure that all keyservers block the same
>> uploads. One permissive keyserver is a backdoor into the entire
>> system. We can’t block bad keys at reconciliation time for the same
>> reasons that have been hashed to d
On 06/30/2019 08:55 AM, Andrew Gallagher wrote:
>
>> On 30 Jun 2019, at 15:07, Erich Eckner via Gnupg-users
>> wrote:
>>
>> maybe I don't get the original idea - but I thought, it was to block
>> *uploads/updates* which would poisson a certificate - not to blackhole them
>> after they got pois
On 06/30/2019 08:33 AM, Peter Lebbing wrote:
>> "Look, this one guy who just got mugged? [...]
>
> I had to read it twice to distill what I think Mirimir meant, but I
> think they meant that if you blacklist/blackhole all affected
> certificates, you remove the incentive for the attackers to poiso
On 06/30/2019 07:33 AM, Robert J. Hansen wrote:
>> Your third point is actually why I suggested this. Maybe I'm just
>> twisted, but what if some dickhead goes after certs that would break
>> stuff for millions of people? One might, for example, block Linux kernel
>> maintenance and development. Ma
On Sun, 30 Jun 2019 at 22:23:11 +, Alyssa Ross wrote:
>> Third-party signatures from locally unknown certificates are arguably
>> not so useful, so how about using ?--keyserver-options import-clean??
>> (Or even making it the default behavior?) Of course it's not perfect as
>> it still clutter
On Sun, 30 Jun 2019 at 00:36:19 -0700, Mirimir via Gnupg-users wrote:
> | High-risk users should stop using the keyserver network immediately.
>
> So OK, I can purge requests to SKS keyservers from my machines. But what
> about upstream impacts? As I understand it, GnuPG authentication is
> pervas
> 1. We would have to ensure that all keyservers block the same
> uploads. One permissive keyserver is a backdoor into the entire
> system. We can’t block bad keys at reconciliation time for the same
> reasons that have been hashed to death already.
One way to do that, though it would mean officia
On Sun, Jun 30, 2019 at 03:49:55AM -0700, Mirimir via Gnupg-users wrote:
c) what happens when they go after more certificates?
If you're willing to blackhole two certs, great. Where does it stop?
How many certs can the strong set stand to lose?
Your third point is actually why I suggested thi
> On 30 Jun 2019, at 15:07, Erich Eckner via Gnupg-users
> wrote:
>
> maybe I don't get the original idea - but I thought, it was to block
> *uploads/updates* which would poisson a certificate - not to blackhole them
> after they got poissoned?
Hm, that’s not how I read it, although I could
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Sun, 30 Jun 2019, Andrew Gallagher wrote:
On 2019/06/30 11:49, Mirimir via Gnupg-users wrote:
It would stop when certs can no longer be poisoned. And I don't see the
downside. I mean, what good does it do to have people downloading keys
that b
> "Look, this one guy who just got mugged? [...]
I had to read it twice to distill what I think Mirimir meant, but I
think they meant that if you blacklist/blackhole all affected
certificates, you remove the incentive for the attackers to poison more
certificates since the poison can't spread to t
On Sun, 30 Jun 2019 08:44:43 -0400, Robert J. Hansen stated:
>> What would have prevented a state level actor from activating this
>> exploit on a wide level during a time when it would have been most
>> effective for them?
>
>A nation-state with a professional intelligence service probably isn't
I can’t speak for others, but I wasn’t suggesting you were personally
responsible for where things are right now, only making observations about the
utility of continuing to use the product going forward, and what the targeted
end users likely expect from the software.
-Ryan McGinnis
http://big
> Your third point is actually why I suggested this. Maybe I'm just
> twisted, but what if some dickhead goes after certs that would break
> stuff for millions of people? One might, for example, block Linux kernel
> maintenance and development. Maybe just before using some 0-day.
For whatever it's
On 2019/06/30 11:49, Mirimir via Gnupg-users wrote:
> It would stop when certs can no longer be poisoned. And I don't see the
> downside. I mean, what good does it do to have people downloading keys
> that break their stuff?
>
> I don't see that as "doing the bad guys’ work for them". I see it as
> I guess that’s one way to look at it, but if your end users are
> dissidents and journalists communicating in happy fun places or
> developers signing critical software, then surely you’d want the
> product to be resilient against 10 year old trivial attacks from your
> users’ adversaries.
I fee
I guess that’s one way to look at it, but if your end users are dissidents and
journalists communicating in happy fun places or developers signing critical
software, then surely you’d want the product to be resilient against 10 year
old trivial attacks from your users’ adversaries. I do underst
> What would have prevented a state level actor from activating this
> exploit on a wide level during a time when it would have been most
> effective for them?
A nation-state with a professional intelligence service probably isn't
very interested in taking down the keyserver network. Why should t
What would have prevented a state level actor from activating this exploit on a
wide level during a time when it would have been most effective for them? I
have to believe that the fine folks who can put an APT in your air-gapped
computer’s video card bios have been aware of this attack for qui
On 30/06/2019 09:19, Robert J. Hansen wrote:
> Right now only three certificates are known to be affected: mine, dkg's,
> and Kristian's.
I must have missed the memo describing the exact nature of the problem.
Could you please provide a link to something (email message, web page)
that explains wh
On 06/30/2019 03:10 AM, Robert J. Hansen wrote:
>> Because a) it’s enumerating badness [1] but more importantly b) it’s
>> punishing the victim. Protecting the ecosystem by banning RJH and DKG’s
>> keys from the keyservers entirely is doing the bad guys’ work for them.
Currently, we know that thre
> Because a) it’s enumerating badness [1] but more importantly b) it’s
> punishing the victim. Protecting the ecosystem by banning RJH and DKG’s
> keys from the keyservers entirely is doing the bad guys’ work for them.
There's an important c):
c) what happens when they go after more certificates?
> On 30 Jun 2019, at 11:01, Vincent Breitmoser wrote:
>
> The single biggest issue is
> importing keys that don't have identity info on them. I submitted a patch to
> GnuPG to fix this issue, but for some reason that is beyond me there seems to
> be
> resistance to merging it:
Unfortunately ev
> On 30 Jun 2019, at 10:21, Mirimir via Gnupg-users
> wrote:
>
> This is undoubtedly a naive question. But anyway, would it be feasible
> to test keys by importing them, and seeing which ones break OpenPGP?
> Maybe do it in minimal Docker containers? And then somehow block access
> to those key
> 3. interoperability. The replacement service would need to be fully compatible
> with all existing clients.
Depending on what you mean by "fully compatible". The single biggest issue is
importing keys that don't have identity info on them. I submitted a patch to
GnuPG to fix this issue, but fo
Robert J. Hansen wrote:
> > Can someone please explain to me why the GnuPG flag for key servers
> > --no-modify is in GnuPG and why the authors of key server software
> > did not implemented this feature?
>
> It's pretty unreasonable to think a piece of software from 2003, meant
> as a drop-in re
> Can someone please explain to me why the GnuPG flag for key servers
> --no-modify is in GnuPG and why the authors of key server software
> did not implemented this feature?
It's pretty unreasonable to think a piece of software from 2003, meant
as a drop-in replacement for software written in 199
Andrew Gallagher wrote:
>
> > On 30 Jun 2019, at 09:19, Robert J. Hansen wrote:
> >
> > The next version of Enigmail will no longer use the SKS network by
> > default. Great! But what about existing Enigmail users? They'll see a
> > signature, click "Import Key", and ... bam. They're likely
On 06/30/2019 01:34 AM, Andrew Gallagher wrote:
>
>> On 30 Jun 2019, at 09:19, Robert J. Hansen wrote:
>>
>> The next version of Enigmail will no longer use the SKS network by
>> default. Great! But what about existing Enigmail users? They'll see a
>> signature, click "Import Key", and ... bam
> Thankfully there is a practical - if drastic - solution for all
> OpenPGP users everywhere. Point pool.sks-keyservers.net (and its
> various aliases) somewhere else. The question is where to and how
> soon.
(I am certain Andrew has already considered this: I am making explicit
what I think Andre
>> Thankfully there is a practical - if drastic - solution for all
>> OpenPGP users everywhere. Point pool.sks-keyservers.net (and its
>> various aliases) somewhere else. The question is where to and how
>> soon.
>
> (I am certain Andrew has already considered this: I am making explicit
> what I
> On 30 Jun 2019, at 09:19, Robert J. Hansen wrote:
>
> The next version of Enigmail will no longer use the SKS network by
> default. Great! But what about existing Enigmail users? They'll see a
> signature, click "Import Key", and ... bam. They're likely not going to
> think that someone's
> How bad could this get?
(I am sputteringly angry over this entire thing: please understand this
and give a charitable read to what I write. I appreciate it.)
Hard to say.
One of the big problems we have is the size of the existing codebase.
Once people have GnuPG installed people overwhelming
On 06/29/2019 11:26 PM, Robert J. Hansen wrote:
>> https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f
>
> I stand by what I wrote.
>
> As usual, don't read the comments unless you want to despair for humanity.
It sounds like SKS is dead meat. And hagrid is coming. And you advise:
> https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f
I stand by what I wrote.
As usual, don't read the comments unless you want to despair for humanity.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/li
Interesting discussion thread on this over at HN:
https://news.ycombinator.com/item?id=20312826
-Ryan McGinnis
http://bigstormpicture.com
PGP: 486ED7AD
Sent with ProtonMail Secure Email
On Sat, Jun 29, 2019 at 12:51, Ryan McGinnis wrote:
> https://gist.github.com/rjhansen/67ab921ffb4084c865b36
Ryan McGinnis via Gnupg-users wrote:
> https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f
>
> -Ryan McGinnis
> http://bigstormpicture.com
> PGP: 486ED7AD
> Sent with ProtonMail Secure Email
No problen, we now have super modern GDPR compliant hagrid, WKD, keybase
and good old pgp.c
https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f
-Ryan McGinnis
http://bigstormpicture.com
PGP: 486ED7AD
Sent with ProtonMail Secure Email___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-us
62 matches
Mail list logo
