SKS and GnuPG related issues and possible workarounds

[Konstantin Boyandin via Gnupg-users]

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 has unlimited resources (to store signatures; 
to retrieve and process them - unlimited RAM/storage, unlimited network 
speed).


b. It is only a matter of time when other certificates are under attack. 
When the ones used by, say, Linux distributions to sign packages are 
affected, that will cause another wave of chaos. So the only valid 
option is to stop using current (the one written in OCaml) keyserver 
implementation and return to stone-age practice of manually sending 
them.


c. More or less valid approach would be to
- when exchanging with keyserver, only load/transmit signatures for 
certificates in the user's keyring. To withstand traffic and other 
resources waste, client should pass known certificates footprints first, 
to only get from a keyserver the relevant signature
- implement local black/white lists feature - to able to filter out the 
signatures while processing them


d. The above, or any other approach is hard to implement in foreseeable 
future, even harder to make a de facto standard.


Personally, I am mostly concerned with b. at the moment. And if approach 
"data came, data stay" remains in effect for keyservers, they will 
merrily be flooded with junk certificates/signatures. I can see no easy 
means to prevent that, without wasting resources of human users.


Am I wrong - perhaps there are brighter alternatives?

Thanks.

Sincerely,
Konstantin Boyandin

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Your Thoughts

[Mirimir via Gnupg-users]

On 07/02/2019 05:18 AM, Robert J. Hansen wrote:
>> Signal went the other way.  Build a verifiably secure communications 
>> platform so easy that literally anyone can figure it out.
> 
> I think this is a misunderstanding of Signal.



> Signal is, by its very nature, tightly tied to one specific
> communications platform -- that of the smartphone.  It's not likely to
> break out of its home.

And not only that, it's tied to one of the least privacy-friendly
aspects of smartphones: the phone number.[0]

| Requirements
|
| Signal uses your existing phone number.
|
| The number must be able to receive an SMS or phone call.

Sure, it's not necessarily the number of the phone that you're using
Signal on. But it's gotta be a number that you can use, and which others
can't use. So what do you do, to avoid geolocation?

You can't use one of those shared SMS services. So what, lease a SIM
from some SIM farm in wherever, and hope that they're honest?

There's also the issue of actually using Signal while preventing
geolocation. You can't just use Tor, which itself is nontrivial on
smartphones, because Signal needs UDP. So you're stuck with VPNs, where
you must trust providers.

It's frightening how popular Signal has become. Especially for people
whose lives are threatened by geolocation. If I were paranoid, I'd say
that it was a honeypot. But whatever. Something using Tor onion services
is probably the best option. Unless Tor is also a honeypot.



0)
https://support.signal.org/hc/en-us/articles/360007318691-Register-a-phone-number

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: keyserver-options: self-sigs-only, import-clean, import-minimal

[gnupg--- via Gnupg-users]

Ángel wrote:

> On 2019-07-02 at 12:24 +0200, Werner Koch via Gnupg-users wrote:
> > > My opinion: make "keyserver-options import-clean" the default and
> > make it internally never import any unknown signatures.
> > 
> > Sorry, this is a catch-22.  We need the key to verify the signature.
> 
> I don't think so. You can have the signing key in the keyring, even if
> that one was imported with only its own self-sigs.
> 
> Ultimately, I think the signatures should only be imported when they are
> cross-signed by the key owner.
> 
> This would require a migration step were people signed the signatures
> they already have on their key, but would otherwise allow them to keep
> their 'precious signatures' they already have.
> 
> Then there should probably be a new command that would have to be used
> to import the new signatures to your key that you are sent.
> 
> It won't fix the problem of a malicious keys being made with thousands
> of fake signatures, but it pretty much solves the spamming problem by
> only putting the owner in charge of accepting the signatures that can go
> on his key.
> 
> Cheers

Apologies in advance if this is a stupid comment (I don't know about gpg's
implementation or the precise reason why keys with many signatures is a
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
keyring handling code could be changed so that poisoned keys no longer
constitute a DoS.

For example, if the problem is overuse of resources such as memory, could
the keyring handling code be rewritten to use fewer resources? e.g. treat
the keyring like a database where not all of it can fit in memory at the
same time. If that were possible, these other changes wouldn't be needed.
But perhaps it already does that and it's not enough.

On the other hand, if the problem is that GPG is validating all of those
signatures when importing a key, perhaps there could be a limit to how many
signatures GPG will verify. Does it really have to verify every single one?
Limiting the number that will be verified (or the amount of time spent
verifying them) might prevent this situation becoming a DoS while still
giving confidence that the key being imported has been signed by at least
some members of your WoT.

Again, apologies if I'm completely misunderstanding the issue. Perhaps the
problem isn't limited to importing. I'm just thinking that being able to
cope with garbage is more robust than trying to come up with ways to avoid
garbage especially when you know that garbage happens.

cheers,
raf


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: keyserver-options: self-sigs-only, import-clean, import-minimal

[Ángel]

On 2019-07-02 at 12:24 +0200, Werner Koch via Gnupg-users wrote:
> > My opinion: make "keyserver-options import-clean" the default and
> make it internally never import any unknown signatures.
> 
> Sorry, this is a catch-22.  We need the key to verify the signature.

I don't think so. You can have the signing key in the keyring, even if
that one was imported with only its own self-sigs.

Ultimately, I think the signatures should only be imported when they are
cross-signed by the key owner.

This would require a migration step were people signed the signatures
they already have on their key, but would otherwise allow them to keep
their 'precious signatures' they already have.

Then there should probably be a new command that would have to be used
to import the new signatures to your key that you are sent.


It won't fix the problem of a malicious keys being made with thousands
of fake signatures, but it pretty much solves the spamming problem by
only putting the owner in charge of accepting the signatures that can go
on his key.

Cheers


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: distributing pubkeys: autocrypt, hagrid, WKD

[Wiktor Kwapisiewicz via Gnupg-users]

Hi Konstantin,

On 02.07.2019 21:40, Konstantin Ryabitsev wrote:
Most subkey changes that I am aware of are not due to people's old 
subkeys expiring, but because they add new ones for reasons like 
migrating between smartcard solutions or just being nerdy and picking a 
new ECC-based subkey.


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.


Do you mean something simpler than [0]:

gpg --auto-key-locate clear,wkd,nodefault --locate-key torva...@kernel.org

?

Trying key lookup over WKD if the subkey is missing locally (but primary 
key is present) would be a good idea. I've seen some really weird errors 
in that case [1].


If the primary key used short expiration [2] the refresh would be 
automatic but not many people like to prolong expirations every couple 
of months.


Kind regards,
Wiktor

[0]: https://dev.gnupg.org/T2917#115978

[1]:
https://www.reddit.com/r/tails/comments/9rchgi/tails_3101_error_cant_check_signature_no_public/

[2]: 
https://blogs.gentoo.org/mgorny/2018/08/13/openpgp-key-expiration-is-not-a-security-measure/


--
https://metacode.biz/@wiktor

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: distributing pubkeys: autocrypt, hagrid, WKD

[Konstantin Ryabitsev]

On Mon, Jul 01, 2019 at 06:41:41PM +0200, Werner Koch via Gnupg-users wrote:

On Mon,  1 Jul 2019 10:27, konstan...@linuxfoundation.org said:


- subkey changes


An expired key triggers a reload of the key via WKD or DANE.  Modulo the
problems I mentioned in the former mail.  For new subkeys we have a
problem unless we do a regular refresh similar to what should be done
for revocations.


Most subkey changes that I am aware of are not due to people's old 
subkeys expiring, but because they add new ones for reasons like 
migrating between smartcard solutions or just being nerdy and picking a 
new ECC-based subkey.


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 
scenario that I need to fix if we can't rely on the SKS network any 
more.


-K

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: RE: Some thoughts on the future of OpenPGP and GnuPG

[Robert J. Hansen]

> This is quite cool (I have mine set up the same way), but somewhat
> ironic considering, well... they're Facebook.  I mean of all the big
> dog internet companies out there that you'd expect to give you
> extreme measures protect in-transit personal user data... Facebook?!

Oh yes, absolutely so.

Facebook makes good money off your personal data.  If they allow other
people to obtain it, that's money they're losing.

You can rely on Facebook to zealously protect their bottom line.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Some thoughts on the future of OpenPGP and GnuPG

[Ángel]

On 2019-07-01 at 18:32 +0200, karel-v_g--- via Gnupg-users wrote:
> Hello!
> Just right now I have read about a security vulnerability in the PGP 
> keyservers,

Note: that's a problem with the keyservers and key distribution, not
with PGP itself.


(...)
> So my question as a user with a need for strong mail encryption is, whether 
> it is not a time to start over with an all new encryption standard replacing 
> OpenPGP and S/MIME completely. Something like the much praised Wireguard is 
> doing right now in the VPN-world.
> Implementing just one (or two if needed) standardized modern method for each 
> of the following basic components: s2k-function, hash algorithm, 
> authenticating symmetric crypto-algorithm, one ECC-based and one conventional 
> asymmetric crypto-algorithm. And somethin to ease the key distribution. 
> OPENPGPKEY and WKD might be suitable for that.
> Thats it. No backwards compatibility. All new lean and easy.

That won't solve *email* encryption.
In fact, you will again some old problems (that may not have been fixed
completely even after all these years, though).

A new shiny system could be made in a couple of days that worked in a
different way and required you to use a separate program.

Encrypted messages could be exchanged through email in the form of
attachments that you need to extract, then open with a special program
to decrypt.
(In fact, many people _currently_ use OpenPGP in that stony age way)

But none of those is really *email* encryption.
You could maybe even make that new program able to connect to your
existing email via IMAP (assuming it's supported!).

But then, it needs to work in Microsoft Outlook. Or in Lotus.
Or have it sent thorough a certain Exchange server which blocks the
encrypted mails sent using this PGP plugin but not this other one.
While the first one does a much better job for reading than the second
one. And you end up with the bizarre case of having one plugin that
works for reading and another for writing.

Let's not get started with being able to read it on the company
smartphone where only a single email client is allowed.
Or the Webmail you were provided.

Here we face the adoption problem. If everyone used OpenPGP, all email
clients would be expected to support it. And those creating the email
clients would dedicate resources so that their MUA works properly with
encrypted messages, rather than leaving that to third parties that often
need to loop through holes to support things.

(Also, many mail providers actually benefit from having access to users'
data, from virus/spam filters, to learning your preferences in order to
eg. show you more suited ads. Combined with little customer interest of
such feature, it's not that strange there hasn't been much interest on
going the route for OpenPGP adoption)


MUA support is the big problem IMHO. First of all for supporting
seamless reading and writing of encrypted emails, and then having the
right user interfaces.

A new system could improve some minor things in the wire format and
encryption options, but it's working pretty well there, and can be fixed
relatively painlessly on rfc4880 successor.

The big deal are email clients. And there you would have all the issues
that existing implementations have. Plus those they have fixed.
Unless you somehow get to have everyone moving to encrypted mails almost
at once, so it creates such pressure.



> In my experience there are so few people actually using OpenPGP and these 
> are crypto experienced so they should eysily adopt the modern proposal. 

That would be much more harder than you expect. But the big problem is
the above one. And rewriting everything won't solve that.


Regards


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: keyserver-options: self-sigs-only, import-clean, import-minimal

[Daniel Kahn Gillmor via Gnupg-users]

On Tue 2019-07-02 12:24:42 +0200, Werner Koch via Gnupg-users wrote:
> On Tue,  2 Jul 2019 10:23, gnupg-users@gnupg.org said:
>
>> Why not make "import-clean" and "import-minimal" strip key signatures
>> before importing a key? That would make "import-minimal" behave like
>
> Because that contradicts what import-clean is supposed to do:
>
>   After import, compact (remove all signatures except the
>   self-signature) any user IDs from the new key that are not usable.
>   Then, remove any signatures from the new key _that are not usable_.
>   This includes signatures that were issued by keys that are not present
>   on the keyring.
>
> To do this gpg needs to check whether the corresponding key exists and
> the verify the signature using that key.  In contrast self-sigs-only
> removes all signature which are not self-signature right away by just
> comparing a 64 bit integer.

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.

However, as Teemu points out, the order of operations is clearly the
cause of the problem here.

If you're saying that "clean-then-import" is technically difficult to
implemente, that is a different answer -- it would be good to understand
why it is difficult, so that we can consider how to fix it.

But "clean-then-import" is clearly a preferable approach to any of the
workarounds described so far.

>> My opinion: make "keyserver-options import-clean" the default and make
>> it internally never import any unknown signatures.
>
> Sorry, this is a catch-22.  We need the key to verify the signature.

Surely GnuPG could validate each certification without first storing the
certificate in the keyring.  "clean" means that the certificates already
stored in the keyring are used to validate incoming signatures.  right?
or am i misunderstanding something?

--dkg


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Some thoughts on the future of OpenPGP and GnuPG

[Stefan Claas via Gnupg-users]

Werner Koch via Gnupg-users wrote:

[snip]

> [1] https://gnupg.org/blog/20170904-financial-results-2016.html
> [2] https://gnupg.org/blog/data/g10code-bilanz-2017-pub.pdf

Thanks a lot for the detailed reply, much appreciated!

Also *much* success in the future!

Regards
Stefan


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Some thoughts on the future of OpenPGP and GnuPG

[Werner Koch via Gnupg-users]

On Tue,  2 Jul 2019 16:03, gnupg-users@gnupg.org said:

> With "big boys" I meaned the German Government, German BSI and Facebook.

I, or well my company g10 Code GmbH, has currently no contracts with the
German government or the BSI.  We had projects with the BSI but no
funding whatsoever.  These projects are the usual invitation for bid, a
bid by us (together with Intevation GmbH), and with luck the bid was
then accepted.  The last such project ended about 2 years ago.

Right now we are talking to companies and also institutions like the BSI
with the goal to sell support contracts (under the gnupg.com label);
that is a new effort Andre and me started this year.

Facebook and Stripe both donate 50k USD per year to support GnuPG
because they use it internally and with their customers and users.  They
are obviously interested to keep the software well maintained.

We also have recurring donations from individuals which are really
helpful and encouraging.  Thanks.

> I assume that 99.9 % of GnuPG /gpg4win users have not seen this before.

This is an old (2014) video showing the answer to a parliamentarian
question by MdB Christian Ströbele on why support for German crypto
[GnuPG] is such low.  The answer has some numbers on money spent via BSI
and BMWI for these purposes.  We tried to figure out how they get to
these numbers and it seems they lumped together different efforts over a
long period of time.

Anyway, it might have helped that new invitations for bids were sent out
by the BSI and Intevation and g10 Code where lucky enough to get
acceptance for our bids on 3 projects (Gpg4all, EasyGpg and Gpg4vs-nfd).
They worked quite well and for the first time we actually made some
profit form these projects.  See [1] for short article on g10 Code's
profits in 2016 and [2] for the balance sheet of 2017.

Unfortunately I have had not found the time to write about the year
2017, or even 2018, on how we are doing.  This lack of time of mine is
partly caused by the departure of 3 of our employers to move on to pEp
and hack on their projects over there.  Anyway, we are currently without
financial problems and are more troubled to find good developers who
have a professional working habit and, best, have some experience in our
field.


Shalom-Salam,

   Werner


[1] https://gnupg.org/blog/20170904-financial-results-2016.html
[2] https://gnupg.org/blog/data/g10code-bilanz-2017-pub.pdf

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

RE: Some thoughts on the future of OpenPGP and GnuPG

[Ryan McGinnis via Gnupg-users]

This is quite cool (I have mine set up the same way), but somewhat ironic 
considering, well... they're Facebook.  I mean of all the big dog internet 
companies out there that you'd expect to give you extreme measures protect 
in-transit personal user data... Facebook?!

-Ryan McGinnis 
https://bigstormpicture.com 
PGP fingerprint: 5C73 8727 EE58 786A 777C 4F1D B5AA 3FA3 486E D7AD
Sent with ProtonMail

-Original Message-
From: Gnupg-users  On Behalf Of Andrew Gallagher
Sent: Tuesday, July 2, 2019 9:28 AM
To: gnupg-users@gnupg.org
Subject: Re: Some thoughts on the future of OpenPGP and GnuPG

On 02/07/2019 15:03, Stefan Claas via Gnupg-users wrote:
> P.S. to me it is still unknown why exactly Facebook is an anual donor.

Facebook are a *serious* user of OpenPGP. Every email they send me is encrypted 
to my PGP key. In this respect they are decades ahead of 99.9% of the other big 
IT companies.

--
Andrew Gallagher

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users



publickey - ryan@digicana.com.asc.pgp
Description: application/pgp-key


signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Some thoughts on the future of OpenPGP and GnuPG

[Andrew Gallagher]

On 02/07/2019 15:03, Stefan Claas via Gnupg-users wrote:
> P.S. to me it is still unknown why exactly Facebook is an anual donor.

Facebook are a *serious* user of OpenPGP. Every email they send me is
encrypted to my PGP key. In this respect they are decades ahead of 99.9%
of the other big IT companies.

-- 
Andrew Gallagher



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Some thoughts on the future of OpenPGP and GnuPG

[Stefan Claas via Gnupg-users]

Robert J. Hansen wrote:

> > Seriously, ... . I'm going to exercise some restraint here and not write
> > anything else, because I can't find words to do it politely.
> 
> I could not agree more.
> 
> Stefan, that was out of bounds, inaccurate, and easy to refute.  If
> you'd just done a Google search before you hit 'Send' you would've
> discovered the truth.
> 
> I think you owe Werner an apology.

O.k. I should better have said "was* in or may still is in" the lucky
position.

With "big boys" I meaned the German Government, German BSI and Facebook.

Before I do any further replies I kindly request that some kind soul
here acts as Interpreter of the footage below, so that all you guys
and gals understand better what I meaned.

I assume that 99.9 % of GnuPG /gpg4win users have not seen this before.

https://www.youtube.com/watch?v=ZfbvNyy6vBE

P.S. to me it is still unknown why exactly Facebook is an anual donor.

Regards
Stefan




___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS Keyserver Network Under Attack

[Werner Koch via Gnupg-users]

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 existing keyservers has been properly tested on the major desktop
platform.

We track the case as https://dev.gnupg.org/T4597

> This BSI requirement was not known to me. While it would be preferable
> to stick

It is not a requirement but it is what has been evaluated.  Changing
anything crypto related requires discussion on whether this will affect
the approval.  It won't be a problem for GnuPG 2.3 because a lot of
things will change there anyway and a re-evaluation will be required.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Andrew Gallagher]

On 02/07/2019 13:06, Michał Górny via Gnupg-users wrote:
> In Gentoo we're using a CA-like model with a central service signing
> UIDs of all developers.  It is *convenient* for it to be able to inject
> those signatures into keys of the developers, and distribute them along
> with them.

It is convenient, but if it is covenient for you to attach one signature
to the keys of your developers and redistribute, then it is convenient
for an arbitrary person to attach a million sigs and gum up the system.
I think this is one case where convenience will have to be sacrificed no
matter what solution we adopt.

This could be a use case for the "preferred keyserver" extension. If you
ran your own keyserver and your developers set it as their preferred
keyserver, then they would be publicly stating "Allow Gentoo to attach
signatures without my explicit permisson, but distrust everyone else".
This would only have to be done once in advance, and it could be made
part of your new developer onboarding process.

-- 
Andrew Gallagher



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Your Thoughts

[Ryan McGinnis via Gnupg-users]

That is true that I am probably being unfair - my focus on GPG for email is 
more a nostalgic sadness that secure (beyond TLS transport) email never really 
became ubiquitous.  In the end the protocol of email itself couldn’t keep up 
with way people needed to communicate, so email is now a bit of a niche thing - 
 used for business and as a repository for “unimportant and lacking urgency, 
but still desired” types of communications.  As a run of the mill IT fire 
putter outer it seems nuts that I run across institutions still using fax 
machines (just regular old unencrypted data turned to audio over POTS lines) 
because they are somehow still compliant with data protection laws, and they 
see encrypted email as less viable as it much more expensive to set up with 
much more overhead.

But I also agree - it certainly does make sense to focus development on what 
the users primarily use it for.

Sent from ProtonMail Mobile

On Tue, Jul 2, 2019 at 07:18, Robert J. Hansen  wrote:

>> Signal went the other way. Build a verifiably secure communications platform 
>> so easy that literally anyone can figure it out.
>
> I think this is a misunderstanding of Signal.
>
> OpenPGP is, by its very nature, agnostic to ... well, just about
> everything. It was originally intended for email but spread to become
> just about everywhere. It's used for package verification mostly
> nowadays. That is the genuine 99% use case, and that's where our
> attention really should be focused on. Email is a niche, and even
> moreso nowadays as email _itself_ is becoming a niche. OpenPGP in email
> is a niche within a niche.
>
> Signal is, by its very nature, tightly tied to one specific
> communications platform -- that of the smartphone. It's not likely to
> break out of its home.
>
> It's true that Signal has had more impact than OpenPGP in email -- but I
> think that's an unfair statement to make, as you're cherrypicking the
> one niche where OpenPGP has had the *least* adoption. Anything looks
> like a failure if you only look at where it's failed.
>
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users-BEGIN PGP PUBLIC KEY BLOCK-
Version: Pmcrypto Golang 0.0.1 (ddacebe0)
Comment: https://protonmail.com

xsFNBFoywpoBEACGlCLzuIxPtuT60BWw+YnCEw5/GlXIx5X6l3NJgDiT/Qrv6m3C
X4NJEHcmUOruIhR/bI0WkvuWV4Rfxv0BKQjp7JnMWRDOY5NxIckvMJGplLThcyRj
KqAvixSruksxt3v3A5b77Kyw1eyB3+eC3Yo0g28yhhfln1gexzsUsuzSW+Fixxgz
S2KdJ26aZ8Sb3gjvfHLv/MKhXluSwYgXIDKMiUOib0iDVdWPfFXCpVbH3o18VnxT
dC3UI3vVmlJarR4O5xIp6FwdmQVtj73ZMHdgYnQceGYcwob8taO0dKfU+31/bjuu
MaOjy2uKnCx9leeK4H13JcbIyGSK7jrAeQRNwE58UzBJZUBs1IDcdYY7Yv1ob9iM
YcfkZhqzztDjK1QP3Ibe3AG02X+rUXLcvlh8EccDb/W50IA+ejDy7yFQb6SK+4Sp
IrZHGPjf1yD4xkkhzNFPJ2mYGN4hCCrnWrDg/hC3rxSwCpI3PExlZ8OF9jy9jTtq
IRx/zXSQKgJcADs4tsNHfzPrnEy41bsmcdI0NrncPcf25jFvaPTwBHACyHlmFX2z
/GuCheopaxmiVJFuVleqrtxeTBN4v79LhxBGtCUdYH9GrenFvzA9v8VMA6r9d7aW
Cb7l0JHL8wzDBOlDCbJMZvT7tDxyl2MIv11LQeIInRlI6JBxLCFZuhYPzwARAQAB
zSVyeWFuQGRpZ2ljYW5hLmNvbSA8cnlhbkBkaWdpY2FuYS5jb20+wsF1BBABCAAp
BQJaMsKgBgsJBwgDAgkQtao/o0hu160EFQgKAgMWAgECGQECGwMCHgEAAJyLD/0T
eGFbbuNyPflTosdmmKAC6ZyuDwJxLjvL3YnHAUPkTO/a6xTtEZ2B41/mOx2OTcyh
JhhwtB0/lsSN7r5rXHzUW4Ve6GSS8PEI3j1IyM/wecv3+gb38ffdFEJA1bUn9+f/
uyhQIFaLwFpq8UQGxDRJ91QXcXFrPzalsv9KKNct1tRClfVnQR77BzkhfIJs2gQi
yT1l+VFqzXAhViiuzRdlJMaTLb236UkeOx/eyNVEcivVYouy2BzL/dW28WDPPtdV
HOcVmV4KfaYJpH4mBHB/KP+JNQy5spVfMLMfC08r5a0EFE3Byeblt3ONPm+2ymzC
RotItz8T7scwu4xTmIw5WWRcIi3mbDW/mefo7whbX3o7NidPBC+ZqJsqLoNno/aD
PYXnpTzAbs4UTSqp6P49MHVWNF4/n/aXU3VhBvZx0h1NNNbO1PzR/8Sr7fedD9UC
niJNJgfaKht1i19Pc+BF5+sgnbRZeIfSxHWfXD+krIWGZmRBaBpGzR3Jr3AAwCcD
uJVeCXxIe17ZTHywqVZloXFXERJBTfmJ+ADn2+sFMjpdWBawsl5xX/9ffiOYf8i0
lGh6vkikBnGZznXIZxcv/IViHugbV73qpvKTiZb0NhX9awy2lbjqdqg4xPxn2RIo
phF9U3iblap4jJrY0Z66gMPHAoeUZUIkW+Z63OPIlM7BTQRaMsKaARAAiRnZm4uc
PKsFDPnMJ5VqEdxOKqTalk1D37712zj/Z7069ZFEzBv9RETqOjvaBCVTtLkZjUKu
At9AQwKJkqHMmzGTglTkyq8D3Fwp11yUhBmv3yOr+0V5MeE69HMuqitpO5gXmoM1
2CUAPDsqet8F8LstEJMbRhpxvOsgmMRWgFm5L74cyqOT44+Mo8+uLwevPH1pC7bE
/kLEPewcAE/60pQ0YgVP2Le6x2ht8CzDZ7p8cSHkXlBa9yHkXZREtU+L0WIIM+3o
F0rrxLxCirbcShN3ZExx+kLnM2zb3xmEQwY6bwlUtHknnoVpJkZXPc3mNJQKc084
+XGgIcPaq053vpIZkOwfQboovk6xpolZGfSnxsQSVsBLT7XYJGe2v4StLnKU3G1W
MIhy8N+s+P+PtOc+YEOl5/6rhbeI6RAlKmpr+/0hEXoe+FxQ+t679M/dGjmFc5bR
TYtoY6bZnhjGbvtuf4+zfPSnvaL8Qmwdcn6XHQ1VwBBaUYyjaLIL+NjmKJ7RXhkk
2yK4IMbd5X0YuL5fuZgMq99BSnEmgPtAHpAokr/lYutUo66hHPD99iAIL1aB9iNe
jjSAcub5A8P0CZabMMelvl9BtWDeGgGz+yEBiI7OL8wZ9Lg634E6Q65HRfAqAbSg
sJrFdGsKJ3snQtalbzS2AjWURvV9nShznWsAEQEAAcLBXwQYAQgAEwUCWjLCowkQ
tao/o0hu160CGwwAANjJD/41QNjdJD7W3YGDdF7zIyN1nE0OVLIlhhyXvx2NBS9E
8O338WWins3zLIe7Bzqr6HSJgPeLrDIIZ/+CoZIoZfnvpB6nYlmgP0O3uFnJsPc+
N5gsQ4p13dAxBWV1SAJbm07rguSES379itwOManIOJMSPNxDLr8aLKcjJWKj5dgN
o0LuyaXJ7H9M61c+3+TWnYucAjFCCk7I7+FWmXvv8H3TpAxAz+qObYJD4RP1Z/tR
7maRrANMjUYcIgyTvG9l41vdmcGMed3xm77U/XzOzfUClEDmaK39bmOG4Auc5R8y
62+2HII/xra9WeeiIOesqMEM50y6AcQERVp2t42f1nrWyiMJ2DzqS2RVp0vb5clD

Re: New keyserver at keys.openpgp.org - what's your take?

[Michał Górny via Gnupg-users]

On Fri, 2019-06-14 at 10:12 +0200, Oscar Carlsson via Gnupg-users wrote:
> I'm generally curious on your opinions on the latest new keyserver, this 
> time running a new software than the normal keyservers.
> 
> They seem to have a different model which minimize the amount of 
> information available, to be compliant with GDPR and friends. Do you 
> think there are any downsides to this?
> 

Others have already somewhat pointed this out but I believe it hasn't
been emphasized enough: in my opinion, stripping third-party signatures
entirely is a no-go.  I'd go ever as far as to say this key server is
harmful to OpenPGP users, and defeats the purpose of using OpenPGP.

I agree that WoT is nowhere near perfect, and that it is confusing to
a lot of simple users.  However, it's the best solution for validating
keys that we have right now.  With keys.openpgp.org implicitly stripping
third-party signatures on one hand, and explicitly requiring e-mail
verification on the other, it effectively shifts the security model into
trusting e-mail verification done by the server software.

I'm not saying that people running the server encourage that in any way.
I'm saying that it's going to happen to a larger degree than before
because users will be making the wrong assumptions.  In other words, if
users see that the particular key will be associated with the e-mail
address only once that address is verified, some of them will also
assume that if the e-mail address is present, then it is reliably
confirmed.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Your Thoughts

[Robert J. Hansen]

> Signal went the other way.  Build a verifiably secure communications platform 
> so easy that literally anyone can figure it out.

I think this is a misunderstanding of Signal.

OpenPGP is, by its very nature, agnostic to ... well, just about
everything.  It was originally intended for email but spread to become
just about everywhere.  It's used for package verification mostly
nowadays.  That is the genuine 99% use case, and that's where our
attention really should be focused on.  Email is a niche, and even
moreso nowadays as email _itself_ is becoming a niche.  OpenPGP in email
is a niche within a niche.

Signal is, by its very nature, tightly tied to one specific
communications platform -- that of the smartphone.  It's not likely to
break out of its home.

It's true that Signal has had more impact than OpenPGP in email -- but I
think that's an unfair statement to make, as you're cherrypicking the
one niche where OpenPGP has had the *least* adoption.  Anything looks
like a failure if you only look at where it's failed.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Michał Górny via Gnupg-users]

On Tue, 2019-06-25 at 16:30 +0200, Vincent Breitmoser via Gnupg-users
wrote:
> > Hi @ll.
> 
> Hi Dirk,
> 
> thanks for your thoughts!
> 
> > I don't think it's such a good idea to drop Signatures on keys.
> 
> As mentioned in our FAQ, the reason we don't support those is that with the 
> SKS
> model, anyone can attach arbitrary data to others' keys.  It's hard to 
> overstate
> how problematic that is. I can just add a megabyte or fifty of data to your 
> key.
> 
> There are solutions that still allow for some of the TPS-based use cases, but
> until there is at least some agreement on how to proceed, we decided against
> supporting them.
> 
> Free distribution of arbitrary TPSes is quite simply not a viable model for 
> any
> keyserver. The discussion shouldn't be about liking or disliking them, it 
> should
> be about what alternatives could be.
> 
> I see from your signing policy that you do a caff-style workflow. Have you
> considered the option to have keys cross-sign third party signatures for
> publication? It's a very slight switch in tooling if we assume a caff 
> workflow,
> but that way each key remains in control of the public version of itself.
> 

I honestly neither like the idea of requiring the 'first party' to
explicitly confirm all signatures, nor losing compatibility with
existing software in order to implement that.  The latter should be
quite obvious so I'll focus on the former.

In Gentoo we're using a CA-like model with a central service signing
UIDs of all developers.  It is *convenient* for it to be able to inject
those signatures into keys of the developers, and distribute them along
with them.  If we required developers to explicitly import
the signature, certify it and upload the key I'm pretty sure our
coverage would go down because people simply won't care.  The problem is
that this bites not developers who don't care much but users who lose
the ability to verify the key easily.

As an alternative: since keys.openpgp.org makes keys without verified e-
mail addresses practically useless, why not permit only those signatures
that were made using a key that's on keys.o.o and has at least single
verified e-mail address?  If you combine that with accepting only one
signature per certifying key (i.e. pruning old signatures), it should be
'good enough'.  That is, as long as attackers won't decide to create
and verify humongous number of e-mail addresses.

This could work fine alongside 'first-party attested blah blah' model,
or at least work as an interim solution until the latter is widely
deployed.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Fw: Re: Your Thoughts

[Ryan McGinnis via Gnupg-users]

By the way, I just *love* my iPhone’s desire to help me with words it thinks 
I’ve misspelled.  :)

-Ryan McGinnis
https://bigstormpicture.com
PGP: 5C73 8727 EE58 786A 777C 4F1D B5AA 3FA3 486E D7AD
Sent with ProtonMail

‐‐‐ Original Message ‐‐‐
On Tuesday, July 2, 2019 7:10 AM, Ryan McGinnis  wrote:

> Right, I probably wasn’t being very clear with what I meant. What I’m saying 
> is that people who use PGP at the moment are rather tech savvy, lady over 
> from the legacy of the fact that for most of PGP’s existence a user had to be 
> tech savvy to even get PGP backed out of the metaphorical garage. Because of 
> this, applications that use PGP all seem designed to make that crowd happy. 
> But making that crowd happy necessarily excludes the much larger crowd that 
> would never need, consider, or even understand aid-gapping.
> 

> Signal went the other way. Build a verifiably secure communications platform 
> so easy that literally anyone can figure it out. Make it hard to impossible 
> to screw up. Most of the people who implemented secure whisper adopted this 
> philosophy. No, it’s not federated, but in terms of real-world impact it 
> actually has one because people actually use it to communicate.
> 

> -Ryan McGinnis
> https://bigstormpicture.com
> PGP: 5C73 8727 EE58 786A 777C 4F1D B5AA 3FA3 486E D7AD
> Sent with ProtonMail
> 

> ‐‐‐ Original Message ‐‐‐
> On Tuesday, July 2, 2019 3:06 AM, Peter Lebbing pe...@digitalbrains.com wrote:
> 

> > On 01/07/2019 23:55, Ryan McGinnis via Gnupg-users wrote:
> > 

> > > Null modem transfer of your messages? Yikes. To me that’s the issue
> > > with PGP in general as it relates to secure communications
> > 

> > None of any of the alternatives to OpenPGP you mention solve the issue
> > that a secure offline system sets out to solve. They are orthogonal
> > issues.
> > Alternatives to OpenPGP have the same need or lack of need of a secure
> > offline system as OpenPGP itself. The only difference I can think of
> > would be in the number of messages disclosed or the range of signatures
> > that could be faked by a compromise, not the base premise of disclosure
> > and impersonation.
> > You might well reasonably object to the UX of OpenPGP. Just not on the
> > ground that there are people who think about offline secure systems,
> > that makes no sense to me. The two are unrelated. The only relation I
> > can think of is that people who think about deploying offline secure
> > systems probably aren't quickly scared off by an overly complicated
> > system ;-).
> > Cheers,
> > Peter.
> > 

> > I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
> > You can send me encrypted mail if you want some privacy.
> > My key is available at http://digitalbrains.com/2012/openpgp-key-peter



publickey - ryan@digicana.com - 0x5C738727.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Your Thoughts

[Ryan McGinnis via Gnupg-users]

Right, I probably wasn’t being very clear with what I meant.  What I’m saying 
is that people who use PGP at the moment are rather tech savvy, lady over from 
the legacy of the fact that for most of PGP’s existence a user *had* to be tech 
savvy to even get PGP backed out of the metaphorical garage.  Because of this, 
applications that use PGP all seem designed to make that crowd happy.  But 
making that crowd happy necessarily excludes the much larger crowd that would 
never need, consider, or even understand aid-gapping.

Signal went the other way.  Build a verifiably secure communications platform 
so easy that literally anyone can figure it out.  Make it hard to impossible to 
screw up.  Most of the people who implemented secure whisper adopted this 
philosophy.  No, it’s not federated, but in terms of real-world impact it 
actually has one because people actually use it to communicate.

-Ryan McGinnis
https://bigstormpicture.com
PGP: 5C73 8727 EE58 786A 777C 4F1D B5AA 3FA3 486E D7AD
Sent with ProtonMail

‐‐‐ Original Message ‐‐‐
On Tuesday, July 2, 2019 3:06 AM, Peter Lebbing  wrote:

> On 01/07/2019 23:55, Ryan McGinnis via Gnupg-users wrote:
> 

> > Null modem transfer of your messages? Yikes. To me that’s the issue
> > with PGP in general as it relates to secure communications
> 

> None of any of the alternatives to OpenPGP you mention solve the issue
> that a secure offline system sets out to solve. They are orthogonal
> issues.
> 

> Alternatives to OpenPGP have the same need or lack of need of a secure
> offline system as OpenPGP itself. The only difference I can think of
> would be in the number of messages disclosed or the range of signatures
> that could be faked by a compromise, not the base premise of disclosure
> and impersonation.
> 

> You might well reasonably object to the UX of OpenPGP. Just not on the
> ground that there are people who think about offline secure systems,
> that makes no sense to me. The two are unrelated. The only relation I
> can think of is that people who think about deploying offline secure
> systems probably aren't quickly scared off by an overly complicated
> system ;-).
> 

> Cheers,
> 

> Peter.
> 

> --
> 

> I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
> You can send me encrypted mail if you want some privacy.
> My key is available at http://digitalbrains.com/2012/openpgp-key-peter



publickey - ryan@digicana.com - 0x5C738727.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Some thoughts on the future of OpenPGP and GnuPG

[Robert J. Hansen]

> Seriously, ... . I'm going to exercise some restraint here and not write
> anything else, because I can't find words to do it politely.

I could not agree more.

Stefan, that was out of bounds, inaccurate, and easy to refute.  If
you'd just done a Google search before you hit 'Send' you would've
discovered the truth.

I think you owe Werner an apology.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS Keyserver Network Under Attack

[Vincent Breitmoser via Gnupg-users]

> 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...@keys.openpgp.org, or filed an issue on Hagrid.

> Even with the fear of padding oracles on CBC and old as well as a forthcoming
> attack, the restriction of the server to use only GCM based cipher modes is
> not helpful.

This BSI requirement was not known to me. While it would be preferable to stick
with AEAD ciphersuites, I would of course add another ciphersuite if you say you
consider this a worthwhile tradeoff.

It would be good to sort out the policy issue at some point as well, but
I understand that won't happen overnight.

 - V

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS Keyserver Network Under Attack

[Werner Koch via Gnupg-users]

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 cipher suites.  Thus the majority of
GnuPG encryption users are out of luck.

On Windows we use the ntbtls library which has not yet support for the
GCM mode and we hesitate to add this to 2.2 because GCM has not been
approved for the use of GnuPG in restricted communication (VS-NfD).  It
is not a technical problem but a policy one which we first need to sort
out.  Even with the fear of padding oracles on CBC and old as well as a
forthcoming attack, the restriction of the server to use only GCM based
cipher modes is not helpful.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: keyserver-options: self-sigs-only, import-clean, import-minimal

[Werner Koch via Gnupg-users]

On Tue,  2 Jul 2019 10:23, gnupg-users@gnupg.org said:

> Why not make "import-clean" and "import-minimal" strip key signatures
> before importing a key? That would make "import-minimal" behave like

Because that contradicts what import-clean is supposed to do:

  After import, compact (remove all signatures except the
  self-signature) any user IDs from the new key that are not usable.
  Then, remove any signatures from the new key _that are not usable_.
  This includes signatures that were issued by keys that are not present
  on the keyring.

To do this gpg needs to check whether the corresponding key exists and
the verify the signature using that key.  In contrast self-sigs-only
removes all signature which are not self-signature right away by just
comparing a 64 bit integer.

> My opinion: make "keyserver-options import-clean" the default and make
> it internally never import any unknown signatures.

Sorry, this is a catch-22.  We need the key to verify the signature.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[David]

On 02/07/2019 03:44, Mirimir via Gnupg-users wrote:
> On 07/01/2019 07:29 AM, David wrote:
> 
> 
> 
>> My take on all this is that I have had to disable Enigmail because it's
>> screwed - I was not able to send mail and all the settings in enigmail
>> were lots of  so I have been infected :(
>>
>> David
> 
> Damn. But all is likely not lost.
> 
> If you can open Enigmail Preferences, go to the Keyserver tab, and
> specify only keys.openpgp.org as the keyserver. That way, if you manage
> to fix gpg, Enigmail won't break it again. Also see "100% CPU usage
> endles loop of gpg --list-keys"  for
> background.
> 
> About hardening and fixing gpg, see
>  at
> Mitigations and Repairs. Also see
> .
> 
> You'll very likely need to use gpg in terminal. I suspect that GPA may
> be just as wedged as Enigmail.
> 
> Maybe someone could post a step-by-step guide for fixing gpg. For people
> who don't commonly use it in terminal. I suppose that I could import one
> of the poisoned keys in a fresh VM, and explore how to fix it. But I'm
> sure that someone reading this could just dash it out.
> 
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
> 

My "fix" was simple - I already have a linux laptop - saved all my keys
and my secret key on a usb stick. Whilst reading the thread - I changed
all the key servers from sks - but then I got screwed as sks key servers
refreshed my keys! WTF!!! Having installed everything to the new laptop
I just copied the folder onto my or this working laptop and all is fine.
But as key servers share data - (???) maybe the infected keys will
circulate???

My public key has only one confirmed signing - it had two - but really I
am not that tempted to download from any key server. Not all here attach
their public key - and do not upload to a key server - and well no one
will ever upload to a key server again!!! Ha!

Every key server is at risk. It has been done once - and can be done
again - there is some very sophisticated malware out there. This is a
great shock and a wake up call to tighten security - on all key servers
- and to have a standardised platform - that takes money and developers.

I'm still in shock and very very wary!!!

David


-- 
People Should Not Be Afraid Of Their Government - Their Government
Should Be Afraid Of The People - When Injustice Becomes Law, REBELLION
Becomes A DUTY! Join the Rebellion Today! https://gbenet.com


0x5C6EE7FBAAD8C47D.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Some thoughts on the future of OpenPGP and GnuPG

[Andrew Gallagher]

On 2019/07/01 17:32, karel-v_g--- via Gnupg-users wrote:

> So my question as a user with a need for strong mail encryption is,
> whether it is not a time to start over with an all new encryption
> standard replacing OpenPGP and S/MIME completely.

The main problem with OpenPGP isn't that its guts are old and slightly
klunky. Many other things that the internet relies on are old and
slightly klunky, but they still do the job. Where it does fall down
often is in ease of use, both for end users and developers. And this is
where most mature software projects end up putting most of their time,
because "fit for use" is an order of magnitude more difficult than "fit
for purpose". [1]

The problem is that a) there's no revenue model for email security, so
the big companies are reluctant to work on it for profit, and b) it's
not sexy, so the talented youngsters aren't willing to work on it for
fun. That will be true of any replacement, which is why despite people
suggesting a modern replacement for over a decade, nobody has actually
made one. And while starting from scratch may look tempting because it
gets rid of all the technical debt, it also gets rid of all the
technical assets.

Yes, there are sexy new things like Signal, but they got to where they
are by doing one (relatively straightforward) thing and doing it well.
OpenPGP is a generalist tool, which explains both why it has ended up
quietly embedded in so many other things, and why it is so difficult to
upgrade or replace.

> To propagate the distribution of this
> hypothetical new format it might be useful to get some of the major
> mailproviders, business software companies and mail software vendors
> might be useful

And this is the crux of the problem. If the big mail providers took
email security seriously, we would never have got here in the first
place. But the nature of email is that nobody owns it, therefore it is
nobody's job to fix it. And the people who care have real jobs and
mortgages.

[1]
https://www.quora.com/What-is-the-service-utility-and-warranty-in-ITIL-v3

-- 
Andrew Gallagher



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Wiktor Kwapisiewicz via Gnupg-users]

On 01.07.2019 14:36, Andrew Gallagher wrote:

OpenPGP already has the "keyserver" field which is rarely used. It is
supposedly a hint to clients to tell them to prefer a particular
keyserver, but it could also be used as a hint to the keyservers
themselves, to tell them where the master copy of any public key can be
sourced.


This sounds like a really good idea.

This way only one place would have to be updated by the user and 
keyservers would automatically refresh key data themselves.


I did suggest something like that but using WKD for Hagrid:

https://gitlab.com/hagrid-keyserver/hagrid/issues/55#note_181162712

but your suggestion Andrew is more generic (key can be put on any HTTP 
host anywhere).


Kind regards,
Wiktor

--
https://metacode.biz/@wiktor



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Local solutions: SKS Keyserver Network Under Attack [edited]

[Roland]

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.kde.kleopatra
www.gnupg.org/related_software/gpa/
or perhaps here:
www.gpg4win.org/index.html
www.enigmail.net/index.php/en/
*There are not.*

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.
So, I did adapt gpg.conf by outcommenting (#) any line starting with 
keyserver, but was not able to adapt the dirmngr.conf.
Upon inspection, thereafter, my GPA and Kleopatra were NOT correctly 
configured.


Trying to figure out how GPA and Kleopatra could be adapted, I found, 
for GPA: Menu > Edit > Backend preferences > Network > Configuration for 
Keyservers > Use custom value > adapt to hkps://keys.openpgp.org
For Kleopatra: Menu > Settings > Configure Kleopatra > Directory 
Services > Open PGP Keyserver > adapt to hkps://keys.openpgp.org
(I would have included an inline screenshot, but this list is allergic 
to html)


Apparently these GUI manipulations generated the ~/.gnupg/dirmngr.conf 
file! (Only hereafter they existed). And that file indeed showed the new 
keyserver.


GPG4Win and Enigmail need further research. (This is a suggestion. I 
cannot do it).


And further, I would have expected a program update that sets the 
defaults to the ones suggested by Hansen and DKG. Or is the matter still 
under consideration, or is it not that important? (I personally cannot 
judge it).


The only hint that I can give: The WoT nor keyservers are not very 
important in my case. I use GnuPG inside a small group of people who 
(for identity verification) can talk to each other, at least by 
telephone. I do not use Enigmail (since limited to few mail clients and 
not accepted by sufficient of my recipients), but just send encrypted 
messages as attachments.


Best regards

Roland



___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Local solutions: SKS Keyserver Network Under Attack

[Roland]

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.kde.kleopatra
www.gnupg.org/related_software/gpa/
or perhaps here:
www.gpg4win.org/index.html
www.enigmail.net/index.php/en/
*There are not.*

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.
So, I did adapt gpg.conf by outcommenting (#) any line starting with 
keyserver, but was not able to adapt the dirmngr.conf.
Upon inspection, thereafter, my GPA and Kleopatra were NOT correctly 
configured.


Trying to figure out how GPA and Kleopatra could be adapted, I found, 
for GPA: Menu > Edit > Backend preferences > Network > Configuration for 
Keyservers > Use custom value > adapt to hkps://keys.openpgp.org
For Kleopatra: Menu > Settings > Configure Kleopatra > Directory 
Services > Open PGP Keyserver > adapt to hkps://keys.openpgp.org
(I would have included an inline screenshot, but this list is allergic 
to html)


GPG4Win and Enigmail need further research. (This is a suggestion. I 
cannot do it).


And further, I would have expected a program update that sets the 
defaults to the ones suggested by Hansen and DKG. Or is the matter still 
under consideration, or is it not that important? (I personally cannot 
judge it).


The only hint that I can give: The WoT nor keyservers are not very 
important in my case. I use GnuPG inside a small group of people who 
(for identity verification) can talk to each other, at least by 
telephone. I do not use Enigmail (since limited to few mail clients and 
not accepted by sufficient of my recipients), but just send encrypted 
messages as attachments.


Best regards

Roland


On 02/07/2019 05:48, gnupg-users-requ...@gnupg.org wrote:

Send Gnupg-users mailing list submissions to
gnupg-users@gnupg.org

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.gnupg.org/mailman/listinfo/gnupg-users
or, via email, send a message with subject or body 'help' to
gnupg-users-requ...@gnupg.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 Network Under Attack (Alyssa Ross)
3. Re: Your Thoughts (Alyssa Ross)
4. Re: New keyserver at keys.openpgp.org - what's your take?
   (Mirimir)
5. Re: Your Thoughts (Robert J. Hansen)


--

Message: 1
Date: Tue, 2 Jul 2019 00:09:47 +0200
From: Stefan Claas 
To: gnupg-users@gnupg.org
Subject: Re: Your Thoughts
Message-ID: 
Content-Type: text/plain; charset=utf-8

Ryan McGinnis via Gnupg-users wrote:


Null modem transfer of your messages?  Yikes.  To me that?s the issue with
PGP in general as it relates to secure communications - the nerds and the
criminals and the spies know how to work it, but your average end user
doesn?t need their step one to be ?go to a Goodwill in a city you don?t live
in wearing a disguise and buy a laptop with cash?, they need PGP to almost be
automatic.  Think of how easy it is to bootstrap Signal and how hard you?d
have to try to accidentally send something cleartext over that application.
Linking your key to a new device is as easy as scanning QR code. Perfect
forward secrecy, rich media, voice and video synchronous communications
upgrades, you name it.  And my grandma could probably set it up without
help.  I guarantee most big data scooping intelligence services are a lot
more worried about OpenWhisper protocol than PGP because *people actually use
it*.  Just being caught with WhatApp in China can get you sent to a camp,
depending on your ethnicity.

Not to be off-topic, but you gave me the keyword "China" ...

I just recently found this and was wondering what purpose it
serves? Are people in China also allowed to use GnuPG?

pgp.ustc.edu.cn/

Regards
Stefan



--

Message: 2
Date: Mon, 1 Jul 2019 22:43:18 +
From: Alyssa Ross 
To: Mirimir 
Cc: gnupg-users@gnupg.org
Subject: Re: SKS Keyserver Network Under Attack
Message-ID: <20190701224317.x3mffnm63klnx...@x220.qyliss.net>
Content-Type: text/plain; charset="us-ascii"


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 exploring
whether to change the default keyserver in Nixpkgs' GnuPG[1] (which we

Local solutions: SKS Keyserver Network Under Attack

[Roland]

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.kde.kleopatra
www.gnupg.org/related_software/gpa/
or perhaps here:
www.gpg4win.org/index.html
www.enigmail.net/index.php/en/
*There are not.*

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.
So, I did adapt gpg.conf by outcommenting (#) any line starting with 
keyserver, but was not able to adapt the dirmngr.conf.
Upon inspection, thereafter, my GPA and Kleopatra were NOT correctly 
configured.


Trying to figure out how GPA and Kleopatra could be adapted, I found, 
for GPA: Menu > Edit > Backend preferences > Network > Configuration for 
Keyservers > Use custom value > adapt to hkps://keys.openpgp.org
For Kleopatra: Menu > Settings > Configure Kleopatra > Directory 
Services > Open PGP Keyserver > adapt to hkps://keys.openpgp.org
(I would have included an inline screenshot, but this list is allergic 
to html)


GPG4Win and Enigmail need further research. (This is a suggestion. I 
cannot do it).


And further, I would have expected a program update that sets the 
defaults to the ones suggested by Hansen and DKG. Or is the matter still 
under consideration, or is it not that important? (I personally cannot 
judge it).


The only hint that I can give: The WoT nor keyservers are not very 
important in my case. I use GnuPG inside a small group of people who 
(for identity verification) can talk to each other, at least by 
telephone. I do not use Enigmail (since limited to few mail clients and 
not accepted by sufficient of my recipients), but just send encrypted 
messages as attachments.


Best regards

Roland


On 02/07/2019 05:48, gnupg-users-requ...@gnupg.org wrote:

Send Gnupg-users mailing list submissions to
gnupg-users@gnupg.org

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.gnupg.org/mailman/listinfo/gnupg-users
or, via email, send a message with subject or body 'help' to
gnupg-users-requ...@gnupg.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 Network Under Attack (Alyssa Ross)
3. Re: Your Thoughts (Alyssa Ross)
4. Re: New keyserver at keys.openpgp.org - what's your take?
   (Mirimir)
5. Re: Your Thoughts (Robert J. Hansen)


--

Message: 1
Date: Tue, 2 Jul 2019 00:09:47 +0200
From: Stefan Claas 
To: gnupg-users@gnupg.org
Subject: Re: Your Thoughts
Message-ID: 
Content-Type: text/plain; charset=utf-8

Ryan McGinnis via Gnupg-users wrote:


Null modem transfer of your messages?  Yikes.  To me that?s the issue with
PGP in general as it relates to secure communications - the nerds and the
criminals and the spies know how to work it, but your average end user
doesn?t need their step one to be ?go to a Goodwill in a city you don?t live
in wearing a disguise and buy a laptop with cash?, they need PGP to almost be
automatic.  Think of how easy it is to bootstrap Signal and how hard you?d
have to try to accidentally send something cleartext over that application.
Linking your key to a new device is as easy as scanning QR code. Perfect
forward secrecy, rich media, voice and video synchronous communications
upgrades, you name it.  And my grandma could probably set it up without
help.  I guarantee most big data scooping intelligence services are a lot
more worried about OpenWhisper protocol than PGP because *people actually use
it*.  Just being caught with WhatApp in China can get you sent to a camp,
depending on your ethnicity.

Not to be off-topic, but you gave me the keyword "China" ...

I just recently found this and was wondering what purpose it
serves? Are people in China also allowed to use GnuPG?

pgp.ustc.edu.cn/

Regards
Stefan



--

Message: 2
Date: Mon, 1 Jul 2019 22:43:18 +
From: Alyssa Ross 
To: Mirimir 
Cc: gnupg-users@gnupg.org
Subject: Re: SKS Keyserver Network Under Attack
Message-ID: <20190701224317.x3mffnm63klnx...@x220.qyliss.net>
Content-Type: text/plain; charset="us-ascii"


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 exploring
whether to change the default keyserver in Nixpkgs' GnuPG[1] (which we

Re: Your Thoughts

[Wiktor Kwapisiewicz via Gnupg-users]

On 01.07.2019 23:08, Juergen Bruckner via Gnupg-users wrote:

Well that not pretty "in the wild" but its pretty new:
The Austrian Parliament and some parts of the Austria Government have
released a website [1] where the PGP-Keys of Members of the Parliament
and other people in the government are collected on one place.

[1] https://gvkeys.at/


That's interesting.

All keys have the same comment in User ID field (random key):

$ gpg -k D81FE9F91ED6AA9F
pub   rsa4096 2018-03-26 [SCEA] [expires: 2023-03-25]
  B5601EA2ABE3CDD51765B6F9D81FE9F91ED6AA9F
uid   [marginal] Nikolaus Berlakovich (Offizieller Schlüssel der 
REPUBLIK ÖSTERREICH https://gvkeys.at) 



And they all are just one primary key (no subkeys) with all capabilities.

Email addresses use the same domain "parlament.gv.at" so it would be a 
perfect place to deploy WKD for these keys :)


Kind regards,
Wiktor

--
https://metacode.biz/@wiktor

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Some thoughts on the future of OpenPGP and GnuPG

[Peter Lebbing]

On 01/07/2019 23:36, Stefan Claas via Gnupg-users wrote:
> I think *flame on* Werner does not need to change anything,
> because he is in the lucky position do get financed by
> the big boys, so I see no need for him to start doing something
> new like many others (with no financial support) do.

Oh, for the love of...

https://www.propublica.org/article/the-worlds-email-encryption-software-relies-on-one-guy-who-is-going-broke

Seriously, ... . I'm going to exercise some restraint here and not write
anything else, because I can't find words to do it politely.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Your Thoughts

[Wiktor Kwapisiewicz via Gnupg-users]

On 02.07.2019 00:58, Alyssa Ross wrote:

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

I do agree that no two people use gpg in the same way.

Kind regards,
Wiktor

--
https://metacode.biz/@wiktor



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Your Thoughts

[Peter Lebbing]

On 01/07/2019 23:55, Ryan McGinnis via Gnupg-users wrote:
> Null modem transfer of your messages?  Yikes.  To me that’s the issue
> with PGP in general as it relates to secure communications

None of any of the alternatives to OpenPGP you mention solve the issue
that a secure offline system sets out to solve. They are orthogonal
issues.

Alternatives to OpenPGP have the same need or lack of need of a secure
offline system as OpenPGP itself. The only difference I can think of
would be in the number of messages disclosed or the range of signatures
that could be faked by a compromise, not the base premise of disclosure
and impersonation.

You might well reasonably object to the UX of OpenPGP. Just not on the
ground that there are people who think about offline secure systems,
that makes no sense to me. The two are unrelated. The only relation I
can think of is that people who think about deploying offline secure
systems probably aren't quickly scared off by an overly complicated
system ;-).

Cheers,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS Keyserver Network Under Attack

[Wiktor Kwapisiewicz via Gnupg-users]

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


I did work on one scheme that uses OpenPGP and I did some extensive 
tests even before keys.openpgp.org was announced and in terms of 
reliability it's day vs night compared to SKS.


Hagrid, as far as understand it, serves keys from static files so it by 
design has good performance. SKS on the other hand requires caches in 
front of the server and, in my tests, it was frequent that an old 
version persisted in the cache long after I updated a key.


No such issues on keys.openpgp.org, gpg --send-key and the new updated 
key is immediately available with no time outs or delays.



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 just a question over which protocol to synchronize this kind of data.


Kind regards,
Wiktor

--
https://metacode.biz/@wiktor



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

A usable crypto experience with GnuPG (Re: Your Thoughts)

[Bernhard Reiter]

Am Dienstag 02 Juli 2019 00:58:32 schrieb Alyssa Ross:
> A large part of what makes alternative encryption software like Signal
> successful is its simplicity.

Though at some points it is too simple to use (from my point of view).
My main point of critic are the central server architecture, the lack of a 
stable business interest, mandory need of a mobil phone number and the only 
use of the Google services to notifications.

> I don't have to worry about the 3000 
> different setting combinations available to me, because there's design
> work been put into it to set me up for success out of the box. 

With WKD and the related "automatic encryption" concept, there is an outline 
since 2 years how a much better crypto experience can be done with GnuPG as a 
crypto engine. Modern clients like GpgOL already implement a large part of 
this, you type in an email address and even if this is the first time, you 
get an encrypted
email.

One main challenge is to get mail service prodiders and mail clients to 
implement the modern concepts. 

For details see:
https://wiki.gnupg.org/WKD
https://wiki.gnupg.org/AutomatedEncryption
(some elder view of the design process 
https://wiki.gnupg.org/EasyGpg2016/VisionAndStories)

Best Regards,
Bernhard
-- 
www.intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner


signature.asc
Description: This is a digitally signed message part.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

GnuPG funding (was: Your Thoughts)

[Bernhard Reiter]

Am Dienstag 02 Juli 2019 05:47:56 schrieb Robert J. Hansen:
> Remember that for about fifteen years GnuPG received basically nil for
> funding.

In the last 20 years there has been significant cross-funding through
contracts that the companies g10 code, KDAB, some other companies and 
Intevation (which I co-own) have been received from German government tenders
leading to contracts. g10 code used the part of the profit from these 
contracts to invest it in GnuPG, so did other companeis. The German Federal 
Agency of IT-Security (BSI) has been a major source of funding for GnuPG 
development by doing so, before it there was the German Ministry of Economics
and some other organisation over the years.

(This has all been published, for example see the "Contracts" section of
https://wiki.gnupg.org/Gpg4win )

This funding (from my perspective) was not sufficient to meet the challenges
posed by maintaining and build a crypto engine and applications around it. 
Each donation and volunteer payments was very helpful. (We've reported a 
couple of times how we did spend that money, e.g. for Gpg4win donations. 
Thanks again!)

Best Regards,
Bernhard
-- 
www.intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner


signature.asc
Description: This is a digitally signed message part.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

keyserver-options: self-sigs-only, import-clean, import-minimal

[Teemu Likonen via Gnupg-users]

Werner Koch [2019-07-01 18:26:20+02:00] wrote:

> As stop-gap solution the next gpg release sports a --keyserver-options
> self-sigs-only to allow importing of spammed keys.

Why not make "import-clean" and "import-minimal" strip key signatures
before importing a key? That would make "import-minimal" behave like
this new "self-sigs-only" and there would be no need for yet another
option. Who needs both "import-minimal" and "self-sigs-only"?

My opinion: make "keyserver-options import-clean" the default and make
it internally never import any unknown signatures.

-- 
/// Teemu Likonen    //
// PGP: 4E1055DC84E9DFF613D78557719D69D324539450 ///


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

WKD refreshing (was: distributing pubkeys: autocrypt, hagrid, WKD)

[Bernhard Reiter]

Am Montag 01 Juli 2019 18:33:41 schrieb Werner Koch via Gnupg-users:
> I consider to change this so that gpg always tries to update
> an expired key via the WKD.

To add to this:
The idea for WKD was to be able to improve the algorithm when a new search is 
done. It is just obvious that the extreme cases to always retrieve a pubkey
when using it and to never again retrieve a pubkey are not suitable.
There is a lot in between, which could also depend on the client and users 
idea of their security compromises. So it is a normal situation with WKD that 
the client algorithm when to refresh will be adapted like Werner is 
mentioning above.

Regards,
Bernhard


-- 
www.intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner


signature.asc
Description: This is a digitally signed message part.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Your Thoughts

[Werner Koch via Gnupg-users]

On Mon,  1 Jul 2019 23:47, r...@sixdemonbag.org said:

> for development.  My donation capped at $500.  For several of those
> years, I was one of the largest individual contributors to GnuPG.

Right, your donation encouraged me to keep on working on this set of
tool which is used at many more places than people expect.  Thank you
and also all the other folks who continue to help financing us.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Your Thoughts

[Werner Koch via Gnupg-users]

On Mon,  1 Jul 2019 22:58, h...@alyssa.is said:

> 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

Because we have good defaults and options to chnage them in the config.
We do not want to expose all options to standard users and annoy them
with useless questions.  Some lobbied for such an interactive option
anyway and thus we added it 1.3.6:

* New --ask-cert-level/--no-ask-cert-level option to turn on and
  off the prompt for signature level when signing a key.  Defaults
  to off.

The interactive prompts are designed in a way that new prompts can be
added without breaking anything.  We have introduced new prompts a lot
without much fear about compatibility problems.


Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users