On Tue, 2 Jul 2019 11:00, d...@fifthhorseman.net said:
> It sounds like you are saying that the order of operations --
> import-then-clean vs. clean-then-import is part of the API spec that
> GnuPG is committed to.
No. What I say is that if we want to clean the keys from bogus
signatures we nee
On Wed, 3 Jul 2019 12:35, gnupg-users@gnupg.org said:
> problem but I have read RJH's article). It sounds like SKS servers can
> handle these poisoned keys but GPG can't. That suggests that maybe GPG's
I think here is a misunderstanding. Sure, processing 150k signatures
takes quite some time an
On Tue, 2 Jul 2019 15:40, konstan...@linuxfoundation.org said:
> When this happens, a maintainer who tries to verify a signed pull
> request will have the operation fail, so they need to have a way to
> force-refresh the developer's key. I would say this is the #1 workflow
Agreed. A signature c
Werner Koch via Gnupg-users [2019-07-03 08:57:55+02:00] wrote:
> On Tue, 2 Jul 2019 11:00, d...@fifthhorseman.net said:
>> But "clean-then-import" is clearly a preferable approach to any of the
>> workarounds described so far.
>
> --import-options import-clean does exactly this.
Daniel basically
On 03/07/2019 05:46, Phil Pennock via Gnupg-users wrote:
> Beware: the HKP schema of paths is used with the keyserver in that
> field, in GnuPG at least.
OK, but what's the failure mode? If it's graceful, then we haven't lost
much. So long as key updates fall back to a keyserver somewhere it
shoul
> 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
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
On 03/07/2019 09:13, Werner Koch via Gnupg-users wrote:
> The current state is that we keep only self-signatures and then then
> import again with import-clean (which is then basically identical to
> import-minimal).
What is the difference in the end result between --keyserver-options
self-sigs-on
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
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 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 Wed, 3 Jul 2019 10:38, tliko...@iki.fi said:
>> import-clean does this:
>>
>>After import, compact (remove all signatures except the
>>self-signature)
>
> ...here you and the manual say that "first import [to local keyring]
> then clean".
>
> So there are conflicting messages. Which of
On 03/07/2019 11:59, Peter Lebbing wrote:
> What is the difference in the end result between --keyserver-options
> self-sigs-only and --import-options import-minimal?
Ah, based on a new message I just read the penny dropped. self-sigs-only
can be made a default because it only applies to keyserver
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
Werner Koch [2019-07-03 12:04:55+02:00] wrote:
> On Wed, 3 Jul 2019 10:38, tliko...@iki.fi said:
>> I think everyone would prefer that import-clean would do all the
>> checking and cleaning before importing certificates to the local
>> keyring. The same thing with import-minimal.
>
> It does this
On Wed, 3 Jul 2019 12:29, pe...@digitalbrains.com said:
> Ah, based on a new message I just read the penny dropped. self-sigs-only
> can be made a default because it only applies to keyservers.
> import-minimal cannot be made a default because it affects all other
Not quite. When importing from
Hello,
On 03/07/2019 13:17, Werner Koch wrote:
> --keyserver-options recognizes all import options in addition to
> keyserver specific options.
But then import-minimal could be modified so it includes the behaviour
currently planned for self-sigs-only, and import-minimal could be made
the default
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
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 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
On Wed, 3 Jul 2019 13:50, pe...@digitalbrains.com said:
> Is there a good use-case for the former? If the latter also filtered out
Yes, as I wrote: 0.2s compared to 50s.
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
signature.asc
Description: PGP s
On 03/07/2019 13:45, Kristian Fiskerstrand wrote:
> There are various ways this can be used for other
> attack vectors as well, so they are mostly just ignored.
Any of those attack vectors applicable to keyservers attempting to
refresh from it?
--
Andrew Gallagher
signature.asc
Description: O
On 03/07/2019 14:00, Roland wrote:
> 1/ Perhaps the fear of compromised communication (including
> distributed software, private messages) can be mitigated by
> practicing short feed back lines: confirmations. Like "did you get my
> communication, what did it say?"
If your communication pathway i
Hi,
On 03/07/2019 15:10, Werner Koch wrote:
> Yes, as I wrote: 0.2s compared to 50s.
I fear we're miscommunicating, so let me try to rephrase it again. Sorry
for my persistence, it's only because I think we're miscommunicating and
it would be good if that could be fixed.
If
--keyserver-options
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
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
Not sure why the phone number thing bothers people -- having a phone at all in
the first place means you are easily tracked. What Signal (and any encryption
system, really) does is try to prevent in-transit interception and surveillance
of the actual data content. It can't hide the metadata as
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
On 7/3/19 10:17 AM, Andrew Gallagher wrote:
> On 03/07/2019 05:46, Phil Pennock via Gnupg-users wrote:
>> Beware: the HKP schema of paths is used with the keyserver in that
>> field, in GnuPG at least.
> OK, but what's the failure mode? If it's graceful, then we haven't lost
> much. So long as key
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: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: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:06, Werner Koch wrote:
> Check that you do not have a keyserver entry in your gpg.conf or
> Enigmail is calling gpg with that options. The keyserver specified by
> gpg overrides whatever dirmngr has been configured to.
>
> debug ipc
> log-file /some/file
>
> in dirmngr.conf
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
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
Werner Koch via Gnupg-users wrote in <87lfxfsiz0@wheatstone.g10code.de>:
|On Tue, 2 Jul 2019 11:00, d...@fifthhorseman.net said:
...
|import-clean does this:
...
|[.]In contrast import-minimal
|does this
...
I (still user of GPG1, it is only your newer key which this cannot
do for me)
On 7/3/19 3:20 PM, Andrew Gallagher wrote:
> On 03/07/2019 13:45, Kristian Fiskerstrand wrote:
>> There are various ways this can be used for other
>> attack vectors as well, so they are mostly just ignored.
>
> Any of those attack vectors applicable to keyservers attempting to
> refresh from it?
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
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:13, Kristian Fiskerstrand wrote:
> potential DoS vector? (probably not the most efficient one, but...)
As in DoS amplification? I create a load of keys with a victim's URL in
the `keyserver` field and the pool does my dirty work? Interesting, but
so long as the keyservers' spiders
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
Steffen Nurpmeso [2019-07-03 17:08:32+02:00] wrote:
> My question: is there any better way than a shell script over
> --list-keys --with-colon | grep ^pub | ...etc... to "minimize" keys in
> my keyring (with gpg1)?
It seems that there is no better way than scripting it. My "--edit-key +
clean" sc
Teemu Likonen wrote in <87zhlvta73@iki.fi>:
|Steffen Nurpmeso [2019-07-03 17:08:32+02:00] wrote:
|
|> My question: is there any better way than a shell script over
|> --list-keys --with-colon | grep ^pub | ...etc... to "minimize" keys in
|> my keyring (with gpg1)?
|
|It seems that there
On Wed, 3 Jul 2019 15:42, pe...@digitalbrains.com said:
> --keyserver-options self-sigs-only,import-minimal
>
> as I propose, why would it take longer than 0.2 s?
Indeed, we could change the code for import-minimal so that it first
does the same what self-sigs-only does. Then it should be very
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.
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
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
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 Wed, 3 Jul 2019 17:08, stef...@sdaoden.eu said:
> I (still user of GPG1, it is only your newer key which this cannot
Just don't use it unless you need to decrypt very old mails. In
particular not with keyservers or cards. The next maintenance release
will anyway remove all keyserver and car
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
Alyssa Ross wrote:
Apologies for my late reply, I have overlooked your reply, sorry!
> For example, why isn't ask-cert-level a default? I'm guessing it's just
> because at some point it didn't exist, and the developers didn't want to
> make a backwards incompatible change. But it means that, out
> > For example, why isn't ask-cert-level a default?
>
> For an alternative view on ask-cert-level see also:
>
> https://debian-administration.org/users/dkg/weblog/98
Oh, interesting. Thank you for showing this to me. I had it in my head
that a "weak" signature would count as a marginal in the web
Alyssa Ross writes:
>> > For example, why isn't ask-cert-level a default?
>>
>> For an alternative view on ask-cert-level see also:
>>
>> https://debian-administration.org/users/dkg/weblog/98
>
> Oh, interesting. Thank you for showing this to me. I had it in my head
> that a "weak" signature would
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 20:30, Alyssa Ross wrote:
Oh, interesting. Thank you for showing this to me. I had it in my head
that a "weak" signature would count as a marginal in the web of trust,
but I suppose I was wrong about that.
In that case, I agree that ask-cert-level doesn't make sense as a
default.
Werner Koch via Gnupg-users wrote:
> On Wed, 3 Jul 2019 12:35, gnupg-users@gnupg.org said:
>
> > problem but I have read RJH's article). It sounds like SKS servers can
> > handle these poisoned keys but GPG can't. That suggests that maybe GPG's
>
> I think here is a misunderstanding. Sure, pro
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
On 2019-07-03 at 09:17 +0100, Andrew Gallagher wrote:
> I didn't even know it supported finger URLs - handy to know! Opening a
> finger port may be a step too far for the security-conscious though...
Depends upon the implementation. I'm biased here, I wrote my own in
Go back in 2016: https://go.
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
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
On 07/03/2019 07:16 AM, Ryan McGinnis via Gnupg-users wrote:
> Not sure why the phone number thing bothers people -- having a
> phone at all in the first place means you are easily tracked.
Well, that's why I only use phones (and not smartphones) for routine
meatspace stuff where I don't care abou
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
62 matches
Mail list logo
