[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: indirectly recommends a proprietary service

From: Werner Koch
Subject: Re: indirectly recommends a proprietary service through a new Enigmail defaults
Date: Thu, 18 Jul 2019 12:09:20 +0200
User-agent: Gnus/5.13 (Gnus v5.13)

On Wed, 17 Jul 2019 14:37, said:

> And I did not. ;-) I called a proprietary *service*,
> not a proprietary server [software].  I. e. a service, that has an
> owner = proprietor, who solely controls it.


>> This keyserver is not more proprietary than any other key servers.
> Yes, but it’s a part (as of now, the only part) of a proprietary
> network — just like, say, Facebook.  While SKS is a distributed
> network — like Usenet.

Nope.  To use the distributed (actually replicated) SKS you need to get
onto Kristian's list.  Kristian has certain rules on what servers he
puts on the list.  This currently means you need to have several SKS
instances running behind a loadbalancer.  For year now this had the
effect that there are only two persons running SKS keyservers.  There
are other pools he also manages - but those are using plain HTTP and not
HTTPS and re rarely used.

>> A problem is the single-point-of-validation (done via mail
>> confirmation) which puts them in a position like X.509 CAs.
> That is, mister Brunschwig is willing to add other keyservers on a par
> with  Who will be an auditor (like

I don't understand.  The thing is that Patrick decided to switch away
from the GnuPG default (hkps:// to a single
keyserver which is controlled by Vincent Breitmoser (
and which can't work like the SKS pool due to their requirement for mail
verification of all keys.  Vincent is one of the authors of
OpenKeychain, a widely used free OpenPGP implementation for Android.

> And Enigmail is like a software that encourages any user to get a
> CAcert certificate ‘in two clicks’, not even informing him, that they

How is that different from software uploading to SKS.  In fact, has some advantages for some user and those who do not
understand the goal of the GDPR: They can request the removal of their

Enigmail has its own policy and I do not like some of them (e.g. the
MemoryHole crap) but in that regard it is not different from GnuPG or
any other free software, they all have defaults which are set to best
serve their users.  One might have different opinions about this, but I
am sure that Enigmail's tries its best to further end-to-end encryption
without neglecting the 4 freedoms.

> Unless you mean an entity that controls root DNS of the Internet, for
> sure, DNS of SKS *network* is _not_ under control of a single person.

Nope, it is.  The network is DNS and certificate based and there is one
person controlling it.  I pretty sure everyone in the community trusts
Kristian to do the Right Thing as most users also trust Patrick, me, or
any other GNU author.

> With SKS, when the default entry point is down, I can simply choose
> the other one, and if I am paranoid I can command GPG to check several
> keyservers — results must be identical, am I right?

You can do the very same in Enigmail.

> And even if it has none.  How a credibility of the owner of
> round-robin DNS that randomly chooses a node in distributed network
> pool can be compared to a credibility required from a single owner of
> the whole network?

As I noted, for more than a year we have only two persons running
actualy used SKS keyservers with one person having the enire control
over it.  How is that different from or gnupg?

> He’s in fact in a halfway of doing that.  Enigmail 2.1 (for
> Thunderbird 68, now in beta) primarily advertising itself not as a
> GPG-frontend or an OpenPGP-compatible tool, but as a PEP [2] software.

pEp now is a very different story than keyservers and I am with you that
it is not a good descision of Patrick to make that highly proprietary
pEp that visible.  Despite of the well intention of its founder, the pEp
conglomerate has only one goal: Burst its market value and sell itself
at the peak.

> Yes, by elimination, the second one, despite that it does not even
> mention neither GPG nor OpenPGP!

Surely they don't want to use copyleft because that makes it harder to
seel the company.

> Back to our topic now: what’s about keyserver?  Suppose, you did not
> get rid of PEP (cannot find out how, or even do not want), how do you
> switch an outcoming keyserver?  My answer is: no idea!  I did not find

In theory by editing dirmngr.conf; unfortunately Enigmail does not use
outr default API but calls gpg with a keyserver and even worse implemens
parts of GnuPG itself.  I have not looked at the latest Enigmail and
can't tell whether the gnupg configure options have been removed.  That
would, in contrast to the default, indeed be a problem.

> Now you apparently would like to try the innovative PEP-enhanced
> Enigmail 2.1 by yourself to see all these fancy things with your own
> eyes, so I must warn you: *it mangles ~/.gnupg/gpg.conf and
> ~/.gnupg/gpg-agent.conf*, so take precautions.

That is okay, all frontends can do that and we even provide an interface
to do this.  There are other choices for a MUA for example Kmail, where
my associate Andre is deeply involved in the crypto.

> May I finally propose a small thought experiment: what would you do
> under the circumstances: disabled lookup on SKS servers until the
> installed GPG had been updated, or took the situation as a ideal
> opportunity to aggressively promote a competing private service among
> all you users?  Or something else?

Assuming you mean pEp: I won't be able to give a neutral answer here
because the folks who wrote the Hagrid software, which is used by, used to be my employees, learned everything about
OpenPGP and things, and left me in favor of working for pEp.  Patrick of
Enigmail is not associated with pEp, though.

Note that is not run any of them but as a private
project of Vicent who is also not associated with pEp but runs along
with a partner a small company to fister delopment of OpenKeychain.



Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]