From dashohoxha at gmail.com  Mon Apr  2 14:40:52 2018
From: dashohoxha at gmail.com (Dashamir Hoxha)
Date: Mon, 2 Apr 2018 14:40:52 +0200
Subject: GSoC project about improving EasyGnuPG
In-Reply-To: <CAMucfLz-XQvFJE047++6BKooVNCd4Q53f_1f1Tn2OMfTZJLEkA@mail.gmail.com>
References: <CAMucfLz-XQvFJE047++6BKooVNCd4Q53f_1f1Tn2OMfTZJLEkA@mail.gmail.com>
Message-ID: <CAMucfLyU6-tNZpkRXtPBUCiad9ZJHUZK=6V+PvN4jBipPLmJcw@mail.gmail.com>

On Sun, Mar 11, 2018 at 5:43 PM, Dashamir Hoxha <dashohoxha at gmail.com>
wrote:

> Hi,
>
> I have started a GSoC project about improving EasyGnuPG
> under the organizational umbrella of Debian:
> https://wiki.debian.org/SummerOfCode2018/Projects/EasyGnuPG
>
> So far there have been about 10 students interested in it.
> From interactions that I had with them (I give them small tasks
> to complete, etc.) I think that 2-3 of them are really promising.
>
> Actually I would like to support 2-3 students, if possible.
> They can work on different tasks, like:
>  - Rewrite EasyGnuPG (or parts of it) so that it is built with Python and
> GPGME
>  - Implement a GUI to EasyGnuPG (maybe with Python).
>  - Write a Debian package for installing EasyGnuPG. Extend EasyGnuPG with
> scripts/commands that automate other common usage scenarios (for example
> keeping the master key on a card).
>
> The problem is that for each student-proposal pair you also
> have to find at least a mentor, and a mentor is not allowed to be
> primary mentor for more than 2 projects. Meanwhile I have also
> proposed a couple of other projects and I am committed to them
> as well.
>
> So, I would like some help or support for mentoring these
> students. I can still be a co-mentor for each of the projects,
> and maybe I will do most of the interaction with the students
> (right now I am not working, so I have plenty of time). But
> I am not allowed to be a primary mentor for more than 2 projects.
>
> Besides this, I am not an expert on Python programming or
> making GUI applications (and even I am not an expert on GPG
> itself), so some help or support would be really useful.
>

Now the application period is over and it is time to select
the best students and to apply for GSoC slots.

About 20 students have been interested for this project
and 7 of them managed to make a final project proposal.
Most of them are interested in rewriting EasyGnuPG
with Python and GPGME. Another goal of the project
is to build a Python package and a Debian package
for the new EasyGnuPG, for easy installation.

I would like to request 3 GSoC slots, in order to support
3 different students. The problem is that we are currently
only 2 mentors for this project. With only 2 mentors we can
technically support only 2 applications.

If there were 3 mentors, it would be easier to get 3 slots
(the probability would be much higher). And also it would be
easier to manage the students. For example, if I suddenly get ill,
the internships would not be interrupted, because the other
mentors would take care of the administrative tasks: checking
students' reports (once a week), and giving a feedback
to GSoC about their progress (once a month).

Anybody would like to help and be a mentor?

You can also help with selecting the best students, if you wish.
I can share with you their project proposals and other details.

Best regards,
Dashamir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180402/7e45998f/attachment.html>

From kyle at iteratee.net  Mon Apr  2 20:38:19 2018
From: kyle at iteratee.net (Kyle Butt)
Date: Mon, 2 Apr 2018 12:38:19 -0600
Subject: Error after building gnupg head on Debian Buster at HEAD
Message-ID: <CAAODAY+xrGguLPhkgqR2Q5eikwinFrTBdMOGsZeO2wecXk1h0A@mail.gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

This is the error that I'm getting:

agent/gpg-agent: relocation error: agent/gpg-agent: symbol
assuan_sock_set_system_hooks version LIBASSUAN_1.0 not defined in file
libassuan.so.0 with link time reference

the libassuan is built from source and installed in prefix=$HOME

the configure is invoked as follows:
./configure --sysconfdir=/etc --enable-maintainer-mode
--with-libgcrypt-prefix=/home/kyle --with-libgpg-error-prefix=/home/kyle
--with-libassuan-prefix=/home/kyle --with-ksba-prefix=/home/kyle
--prefix=/home/kyle

The error occurs when I build from master with a clean repository.

I get the same error whether I build LIBASSUAN from source, or from the
latest HEAD.

Any pointers would be appreciated.

Kyle
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iKEEARMKAAYFAlrCeGYACgkQQWOJ0515Jd6KQAIHTCspndKkpJQ/hSRyAcP+8JJg
zAhCMGYRdU/l5SUOOKp7niJAizGQ1gepDrNWPNjmKtwA0fxrw5v1ojI3LF/k1f8C
CQEqtMKkRkaaDixFQGUnNXDRGCg/F5OvQv/AAkOWS+jOtZyz1SAKGQjBCi+Wpphb
mZ2Q+neBStDZshxqjsHsK9G/Xg==
=J3P1
-----END PGP SIGNATURE-----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180402/8b7aca5e/attachment-0001.html>

From kyle at iteratee.net  Mon Apr  2 20:42:21 2018
From: kyle at iteratee.net (Kyle Butt)
Date: Mon, 2 Apr 2018 12:42:21 -0600
Subject: Error after building gnupg head on Debian Buster at HEAD
In-Reply-To: <CAAODAY+xrGguLPhkgqR2Q5eikwinFrTBdMOGsZeO2wecXk1h0A@mail.gmail.com>
References: <CAAODAY+xrGguLPhkgqR2Q5eikwinFrTBdMOGsZeO2wecXk1h0A@mail.gmail.com>
Message-ID: <CAAODAYL8veUS6=4x7HqVokw9TYcZx=v+Sge5ggGXV9EXwnDPUQ@mail.gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Mon, Apr 2, 2018 at 12:38 PM, Kyle Butt <kyle at iteratee.net> wrote:
- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

This is the error that I'm getting:

agent/gpg-agent: relocation error: agent/gpg-agent: symbol
assuan_sock_set_system_hooks version LIBASSUAN_1.0 not defined in file
libassuan.so.0 with link time reference

the libassuan is built from source and installed in prefix=$HOME

the configure is invoked as follows:
./configure --sysconfdir=/etc --enable-maintainer-mode
--with-libgcrypt-prefix=/home/kyle --with-libgpg-error-prefix=/home/kyle
--with-libassuan-prefix=/home/kyle --with-ksba-prefix=/home/kyle
--prefix=/home/kyle

The error occurs when I build from master with a clean repository.

I get the same error whether I build LIBASSUAN from source, or from the
latest HEAD.

Any pointers would be appreciated.

Kyle
- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iKEEARMKAAYFAlrCeGYACgkQQWOJ0515Jd6KQAIHTCspndKkpJQ/hSRyAcP+8JJg
zAhCMGYRdU/l5SUOOKp7niJAizGQ1gepDrNWPNjmKtwA0fxrw5v1ojI3LF/k1f8C
CQEqtMKkRkaaDixFQGUnNXDRGCg/F5OvQv/AAkOWS+jOtZyz1SAKGQjBCi+Wpphb
mZ2Q+neBStDZshxqjsHsK9G/Xg==
=J3P1
- -----END PGP SIGNATURE-----


I should point out that this is on 32 bit Arm.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iKEEARMKAAYFAlrCeV0ACgkQQWOJ0515Jd4LtQIHXghS5pSlbJw44jNZe1MY3Z1H
AV0crjuGdbwTYcCoVOI4ywl7L5wL6OH0GpIL4dnKCT95kIeIezrd989lVigXXooC
CQHM0wkUcSrmtRXXoV8t9aCoOpoBPV2cpQe+gOvymVePd5Kwur33MfdHbfKVd2hu
mTKwnEkmhpKVCoWwRcb1MVYsTQ==
=1gUv
-----END PGP SIGNATURE-----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180402/e74ff698/attachment.html>

From kyle at iteratee.net  Mon Apr  2 19:39:48 2018
From: kyle at iteratee.net (Kyle Butt)
Date: Mon, 2 Apr 2018 11:39:48 -0600
Subject: Error after building gnupg head on Debian Buster at HEAD
Message-ID: <CAAODAYJTVC+sjRMk_nu7K_m7z_aBeJQeSMU_7hgMbhay5sOpHg@mail.gmail.com>

This is the error that I'm getting:

agent/gpg-agent: relocation error: agent/gpg-agent: symbol
assuan_sock_set_system_hooks version LIBASSUAN_1.0 not defined in file
libassuan.so.0 with link time reference

the libassuan is built from source and installed in prefix=$HOME

the configure is invoked as follows:
./configure --sysconfdir=/etc --enable-maintainer-mode
--with-libgcrypt-prefix=/home/kyle --with-libgpg-error-prefix=/home/kyle
--with-libassuan-prefix=/home/kyle --with-ksba-prefix=/home/kyle
--prefix=/home/kyle

The error occurs when I build from master with a clean repository.

I get the same error whether I build LIBASSUAN from source, or from the
latest HEAD.

Any pointers would be appreciated.

Kyle.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180402/741221f0/attachment.html>

From kyle at iteratee.net  Mon Apr  2 20:23:29 2018
From: kyle at iteratee.net (Kyle Butt)
Date: Mon, 2 Apr 2018 12:23:29 -0600
Subject: Error after building gnupg head on Debian Buster at HEAD
Message-ID: <CAAODAYKvFVW_ibtcUwHWn8VshUGDADTL_tirXdTugp4=QRrAOA@mail.gmail.com>

This is the error that I'm getting:

agent/gpg-agent: relocation error: agent/gpg-agent: symbol
assuan_sock_set_system_hooks version LIBASSUAN_1.0 not defined in file
libassuan.so.0 with link time reference

the libassuan is built from source and installed in prefix=$HOME

the configure is invoked as follows:
./configure --sysconfdir=/etc --enable-maintainer-mode
--with-libgcrypt-prefix=/home/kyle --with-libgpg-error-prefix=/home/kyle
--with-libassuan-prefix=/home/kyle --with-ksba-prefix=/home/kyle
--prefix=/home/kyle

The error occurs when I build from master with a clean repository.

I get the same error whether I build LIBASSUAN from source, or from the
latest HEAD.

Any pointers would be appreciated.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180402/0fe0ff6a/attachment.html>

From gniibe at fsij.org  Tue Apr  3 02:25:27 2018
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Tue, 03 Apr 2018 09:25:27 +0900
Subject: Error after building gnupg head on Debian Buster at HEAD
In-Reply-To: <CAAODAYL8veUS6=4x7HqVokw9TYcZx=v+Sge5ggGXV9EXwnDPUQ@mail.gmail.com>
References: <CAAODAY+xrGguLPhkgqR2Q5eikwinFrTBdMOGsZeO2wecXk1h0A@mail.gmail.com>
 <CAAODAYL8veUS6=4x7HqVokw9TYcZx=v+Sge5ggGXV9EXwnDPUQ@mail.gmail.com>
Message-ID: <87d0zhi1ag.fsf@iwagami.gniibe.org>

Hello,

New libassuan has new symbol (assuan_sock_set_system_hooks) whch is not
available in old libassuan.

Kyle Butt <kyle at iteratee.net> wrote:
> This is the error that I'm getting:
>
> agent/gpg-agent: relocation error: agent/gpg-agent: symbol
> assuan_sock_set_system_hooks version LIBASSUAN_1.0 not defined in file
> libassuan.so.0 with link time reference
>
> the libassuan is built from source and installed in prefix=$HOME

... but you didn't configure to use the library.  The library loaded by
agent/gpg-agent is the one of the system (old one), not the one you
installed, I suppose.

When you install shared libraries to some place where system is not
configured to load them, you need to set LD_LIBRARY_PATH.

Please see the manual of ld.so(8) for LD_LIBRARY_PATH.  Or, read this
section:

    Program Library HOWTO:
    http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN80

Happy Hacking,
-- 


From gnupg-devel at sambull.org  Tue Apr  3 13:02:17 2018
From: gnupg-devel at sambull.org (Sam Bull)
Date: Tue, 03 Apr 2018 12:02:17 +0100
Subject: Web Key Discovery
In-Reply-To: <1522068090.3927.5.camel@sambull.org>
References: <1521643465.4063.3.camel@sambull.org>
 <a51fa88c-8874-0a41-1028-874ca411115a@incenp.org>
 <1521676357.13709.9.camel@sambull.org>
 <87sh8sa8x7.fsf@wheatstone.g10code.de>
 <1522068090.3927.5.camel@sambull.org>
Message-ID: <1522753337.4009.5.camel@sambull.org>

On Mon, 2018-03-26 at 13:41 +0100, Sam Bull wrote:
> On Thu, 2018-03-22 at 08:03 +0100, Werner Koch wrote:
> > It maps a mail address to a key.??It is possible to map several mail
> > addresses to the same key but the key needs to carry a user ID for each
> > key.
> Right, but it seems to require mapping the key to the mail address as well,
> i.e. it must match in both directions.
> 
> If it was only matching an address to a key, then I could configure my server
> to map all email addresses to the key I am currently using. This is the
> correct key that people should use to contact me, but the user ID would not
> match, therefore doesn't work when you require the key to also map to the
> address.

Also note in the DANE RFC, it only says:

    One User ID Y, which SHOULD match?    'hugh at example.com'

i.e. If the user ID doesn't match, it won't cause a validation error (it's a recommendation, rather than a requirement). Why can't the web key discovery take the same approach?

> > > Of course, supporting a wildcard in the user ID would also solve this
> > > issue.
> > I am not sure what you mean by wildcard.
> Well, for example, the email I am using for this mailing list is
> gnupg-devel at sambull.org. So, each unique email is a full email under my
> personal domain. So by wildcard, I mean something like "*@sambull.org"
> matching any valid address under my domain name.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180403/199403a5/attachment-0001.sig>

From bernhard at intevation.de  Thu Apr  5 12:02:52 2018
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 5 Apr 2018 12:02:52 +0200
Subject: WKD v05: DNS problem when requesting pubkey
Message-ID: <201804051202.57012.bernhard@intevation.de>

Dear GnuPG-people,

just a brief note that yesterday I've discovered that the current v05 spec of 
WKD has an implementation problem:

When requesting a pubkey a client MUST do a DNS query to an SRV record 
The reason this was added by Wener is that some email providers do not have 
access to the webserver on the domain they are serving emails for.

However according to my research, code running inside  a webbrowser - either 
from a webpage or as extension - **cannot do a DNS request** on its own. 
Webbrowser upstreams have so far declined to implement RFC 2782 for HTTP and 
probably won't ever implement it. There is also no API to do such a DNS 
request or a way to do UDP or TCP to implement it in javascript within the 
browser.

Usually if a webclient software needs a request like this, they'd work around 
this limitation by either using a service on a server. They could implement a 
native code extension via Native Messaging. Both ways do not work well for a 
webclient that wants to do a WKD request because using a service degrades the 
security of the request as it gets to be attacked by the service provider.
A native messaging solution is less usable because it would need support on 
the operating system level to render the extension workable, which 
complicates the installation a lot.

Pondering other solutions: from Thomas Obernd?rfer I've got the idea that we 
could use the mandatory policy file to allow a "redirect". This may be easier 
than doing a real redirect on the webserver or an internal proxying from the 
webserver to the email providers WKD webserver.

I appreciate comments!
Does someone see another possibility to implement
a DNS SRV request in the browser?
Any other ideas how to solve the problem?

Best Regards,
Bernhard

https://wiki.gnupg.org/EasyGpg2016/PubkeyDistributionConcept
links the current WKD spec and mentions other details.


-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180405/180bc3cd/attachment.sig>

From wk at gnupg.org  Thu Apr  5 12:50:57 2018
From: wk at gnupg.org (Werner Koch)
Date: Thu, 05 Apr 2018 12:50:57 +0200
Subject: WKD v05: DNS problem when requesting pubkey
In-Reply-To: <201804051202.57012.bernhard@intevation.de> (Bernhard Reiter's
 message of "Thu, 5 Apr 2018 12:02:52 +0200")
References: <201804051202.57012.bernhard@intevation.de>
Message-ID: <871sfu0vvy.fsf@wheatstone.g10code.de>

On Thu,  5 Apr 2018 12:02, bernhard at intevation.de said:

> However according to my research, code running inside  a webbrowser - either 
> from a webpage or as extension - **cannot do a DNS request** on its own. 

Which also means they can't do proper keyserver lookups.  Or implement
XMPP or any other protocol with mandatory SRV record.  SRV records are
in use for more than 18 years:

  2782 A DNS RR for specifying the location of services (DNS SRV). A.
       Gulbrandsen, P. Vixie, L. Esibov. February 2000. (Format: TXT=24013
       bytes) (Obsoletes RFC2052) (Updated by RFC6335) (Status: PROPOSED
       STANDARD) (DOI: 10.17487/RFC2782) 

And RFC-2052 dates back to 1996.

> Pondering other solutions: from Thomas Obernd?rfer I've got the idea that we 
> could use the mandatory policy file to allow a "redirect". This may be easier 

This does not work.  The policy file has the same well-known URL prefix
and thus the SRV record should have already been consulted.  In general
a SRV record is not required and I expect that most Web key directories
won't use that anyway.  Thus the failure rate would be quite low and can
maybe mitigated by a fixed list of domains which redirect to a sub
directory.  If you want to test the SRV record, use my address which uses
a SRV record just for testing.


Salam-Shalom,

   Werner

-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180405/beec9b60/attachment.sig>

From peter at digitalbrains.com  Thu Apr  5 13:35:42 2018
From: peter at digitalbrains.com (Peter Lebbing)
Date: Thu, 5 Apr 2018 13:35:42 +0200
Subject: WKD v05: DNS problem when requesting pubkey
In-Reply-To: <871sfu0vvy.fsf@wheatstone.g10code.de>
References: <201804051202.57012.bernhard@intevation.de>
 <871sfu0vvy.fsf@wheatstone.g10code.de>
Message-ID: <b8f71893-18bf-d5d0-01a2-3d3586c22f81@digitalbrains.com>

On 05/04/18 12:50, Werner Koch wrote:
> Which also means they can't do proper keyserver lookups.  Or implement
> XMPP or any other protocol with mandatory SRV record.  SRV records are
> in use for more than 18 years:

My guess is all these use cases have so far been covered by helper
routines (or complete clients) running on a server.

Which Bernhard regards as:

On 05/04/18 12:02, Bernhard Reiter wrote:
> [...] using a service degrades the
> security of the request as it gets to be attacked by the service provider.

I'm not convinced this is the case. If the service runs on the same
server as the one hosting the web client, that server can already inject
any code in the web client itself. They could rip out the "secure"
client-side library handling WKD and replace it by a piece of code that
does their bidding. Whether the code runs on the server or is provided
to the client by the same server doesn't impact the trustworthiness of
the code *itself*, only of the environment it runs in. And if the
trustworthiness of the server is compromised, you're lost already.

Is it really that black and white or am I missing a scenario?

The thing that remains is the place of the burden. To lessen the burden
on people who need an SRV record for their service, we're burdening all
implementations with jumping through hoops to obtain the SRV record.
Then again, other specifications have the same drawback: XMPP,
keyservers, off the top of my head I think SIP (VoIP etc.) is another
one. Maybe it's just part of life for a web client developer.

I understand your resistance to complaints about support of what Should
Just Work(TM), which also relates to the place of the burden. Consumers
of DNS should get their act together, this is not bleeding edge tech.
But another fix would be to allow a special host record (A, AAAA or
CNAME) with something like _wkd.example.com. I'm not saying that should
be its form, it's the general idea.

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>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180405/83648164/attachment.sig>

From bernhard at intevation.de  Fri Apr  6 09:44:30 2018
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 6 Apr 2018 09:44:30 +0200
Subject: WKD v05: DNS problem when requesting pubkey
In-Reply-To: <b8f71893-18bf-d5d0-01a2-3d3586c22f81@digitalbrains.com>
References: <201804051202.57012.bernhard@intevation.de>
 <871sfu0vvy.fsf@wheatstone.g10code.de>
 <b8f71893-18bf-d5d0-01a2-3d3586c22f81@digitalbrains.com>
Message-ID: <201804060944.42869.bernhard@intevation.de>

Am Donnerstag 05 April 2018 13:35:42 schrieb Peter Lebbing:
> On 05/04/18 12:50, Werner Koch wrote:
> > Which also means they can't do proper keyserver lookups.  Or implement
> > XMPP or any other protocol with mandatory SRV record.  SRV records are
> > in use for more than 18 years:
>
> My guess is all these use cases have so far been covered by helper
> routines (or complete clients) running on a server.

I did inspect one XMPP implementation offering for the webbrowser
(randomly found by using duckduckgo) to verify that thought and found they 
were indeed using a server component (based on php in this case).
In addition I saw problem reports of the webbrowser makers for http many years 
old that still recently got a won't fix. Browser makers claim:
 * for http is is a performance penalty
 * if it to be implemented in http it had to be agreed in an 
   (upcoming) standard for http
For understandable reasons the do not implement general networking
as it would violate their security model around the same origin policy.

> On 05/04/18 12:02, Bernhard Reiter wrote:
> > [...] using a service degrades the
> > security of the request as it gets to be attacked by the service
> > provider.
>
> I'm not convinced this is the case. If the service runs on the same
> server as the one hosting the web client, that server can already inject
> any code in the web client itself. [..]

> Is it really that black and white or am I missing a scenario?

A web-extension is code that runs locally in the browser, is bound to the API 
limitations (with some exceptions like "Native Messaging"). Thus it can do 
WKD requests based on HTTPS only independently of the server.
(For context see https://github.com/mailvelope/mailvelope/wiki/mw2018 where 
want to improve the Web-Extention Mailvelope, which triggered these 
thoughts.)


> But another fix would be to allow a special host record (A, AAAA or
> CNAME) with something like _wkd.example.com. I'm not saying that should
> be its form, it's the general idea.

Thanks for this additional idea and the feedback!

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180406/623d3174/attachment.sig>

From bernhard at intevation.de  Fri Apr  6 09:58:23 2018
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 6 Apr 2018 09:58:23 +0200
Subject: WKD v05: DNS problem when requesting pubkey
In-Reply-To: <871sfu0vvy.fsf@wheatstone.g10code.de>
References: <201804051202.57012.bernhard@intevation.de>
 <871sfu0vvy.fsf@wheatstone.g10code.de>
Message-ID: <201804060958.27556.bernhard@intevation.de>

Am Donnerstag 05 April 2018 12:50:57 schrieb Werner Koch:
> On Thu,  5 Apr 2018 12:02, bernhard at intevation.de said:
> > However according to my research, code running inside  a webbrowser -
> > either from a webpage or as extension - **cannot do a DNS request** on
> > its own.
>
> Which also means they can't do proper keyserver lookups.  Or implement
> XMPP or any other protocol with mandatory SRV record.  SRV records are
> in use for more than 18 years

It seems we have to accept this, whether we like it or not. :/
(At least so far everything I saw supports the statement above.)

> > Pondering other solutions: from Thomas Obernd?rfer I've got the idea that
> > we could use the mandatory policy file to allow a "redirect". This may be
> > easier
>
> This does not work.  The policy file has the same well-known URL prefix
> and thus the SRV record should have already been consulted.  

My suggestion is to remove the SRV record requirement again, because otherwise 
we may exclude a significant number of users. Thus I'm thinking about better, 
but different solutions to the problem that the SRV record lookup tried to 
solve.

Another class of solutions is to but some burden on the webserver for an email 
domain in case email and web are handled by two different service provider:
And as the policy file has to be fetched by all WKD clients already, it is not 
another requesting technology, no extra request and could still do a 
redirect. Placing a fixed file on the webserver could be an easier 
requirement than configurating a redirect. However it has the drawback that 
email provider cannot controll the policy file directly. Okay, so maybe a 
https redirect is easier?

> In general 
> a SRV record is not required and I expect that most Web key directories
> won't use that anyway.  Thus the failure rate would be quite low

If this really is an edge case and it can be ignored, I'd would not handle it 
at all and remove the requirement of the SRV lookup completely to keep the 
protocal simple.

> and can maybe mitigated by a fixed list of domains which redirect to a sub
> directory.

That is another idea, thanks for bringing it up.
Thinking about it: It would mean that SRV would only work for big providers 
that register this with each Web-Extension. (You don't want to introduce a 
central fixed list, wouldn't you. ;) )

We are talking large email providers in Germany and Mailvelope having many 
users, so affected users would be hundered of thousands I guess. That is an 
motivation to put some effort in the design.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180406/b89db440/attachment.sig>

From bernhard at intevation.de  Fri Apr  6 10:08:57 2018
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 6 Apr 2018 10:08:57 +0200
Subject: Web Key Discovery
In-Reply-To: <1522753337.4009.5.camel@sambull.org>
References: <1521643465.4063.3.camel@sambull.org>
 <1522068090.3927.5.camel@sambull.org> <1522753337.4009.5.camel@sambull.org>
Message-ID: <201804061009.13165.bernhard@intevation.de>

Am Dienstag 03 April 2018 13:02:17 schrieb Sam Bull:
> Why can't the web key discovery take the same approach?

Because we want to defend to some extend against an email provider 
manipulating the pubkeys it hands out for their users. Otherwise we are less 
end-to-end. Therefore we essentially assume that one email address is one 
identity.

In your case you want to controll all emails to one email domain, but have 
them pose as different identities. So to me its fine that WKD makes this a 
bit harder. (I don't know well enough, which problem you are trying to solve 
with this.)  

My suggestion is: As you are the only user on the server and completely 
controlling it: Add a new identity each time you create a new email alias
automatically on a server. If you want more security use a hardware token.
Note that someone how gets to control your server, could just create a new 
email aliases and a completely new keypair they control and divert emails 
send to you, so you cannot defend against all of these attacks anymay.

Best,
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180406/7500b4e1/attachment-0001.sig>

From peter at digitalbrains.com  Fri Apr  6 11:12:24 2018
From: peter at digitalbrains.com (Peter Lebbing)
Date: Fri, 6 Apr 2018 11:12:24 +0200
Subject: Web Key Discovery
In-Reply-To: <1522753337.4009.5.camel@sambull.org>
References: <1521643465.4063.3.camel@sambull.org>
 <a51fa88c-8874-0a41-1028-874ca411115a@incenp.org>
 <1521676357.13709.9.camel@sambull.org> <87sh8sa8x7.fsf@wheatstone.g10code.de>
 <1522068090.3927.5.camel@sambull.org> <1522753337.4009.5.camel@sambull.org>
Message-ID: <cbfe9e3b-ae6b-5775-2771-4334f47b3cda@digitalbrains.com>

In addition to the security concerns of allowing a WKD key lookup to
introduce keys with User ID's not matching said lookup:

I think WKD is used for key discovery and validity (to a certain
extent), but not key binding: it doesn't instruct your client to use a
certain key for a certain e-mail address.

On 03/04/18 13:02, Sam Bull wrote:
> Also note in the DANE RFC, it only says:
> 
>     One User ID Y, which SHOULD match?    'hugh at example.com'
> 
> i.e. If the user ID doesn't match, it won't cause a validation error (it's a recommendation, rather than a requirement).

Have you actually tried this and does it produce a meaningful result?
Even though it might be spec conformant, it might not be meaningful. I
don't know what GnuPG does in this case. Suppose GnuPG doesn't filter
this out immediately and adds the key for name at example.org to its
keyring and assigns it some validity, even though it requested the key
for alias at example.org. If it subsequently tries to encrypt to
alias at example.org, it comes to the odd conclusion that it doesn't have a
key for alias at example.org even though it literally just requested one
and got an answer. I suspect that it simply would not produce a
meaningful result.

Also note that even though you say "it won't cause a validation error",
I don't expect the spec forbids implementations to disregard the result
to their own discretion. GnuPG might simply ignore the result anyway and
be fully conformant.

HTH,

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>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180406/a55f086b/attachment.sig>

From gnupg-devel at sambull.org  Fri Apr  6 15:48:25 2018
From: gnupg-devel at sambull.org (Sam Bull)
Date: Fri, 06 Apr 2018 14:48:25 +0100
Subject: Web Key Discovery
In-Reply-To: <cbfe9e3b-ae6b-5775-2771-4334f47b3cda@digitalbrains.com>
References: <1521643465.4063.3.camel@sambull.org>
 <a51fa88c-8874-0a41-1028-874ca411115a@incenp.org>
 <1521676357.13709.9.camel@sambull.org>
 <87sh8sa8x7.fsf@wheatstone.g10code.de>
 <1522068090.3927.5.camel@sambull.org> <1522753337.4009.5.camel@sambull.org>
 <cbfe9e3b-ae6b-5775-2771-4334f47b3cda@digitalbrains.com>
Message-ID: <1523022505.3615.21.camel@sambull.org>

On Fri, 2018-04-06 at 11:12 +0200, Peter Lebbing wrote:
> I think WKD is used for key discovery and validity (to a certain
> extent), but not key binding: it doesn't instruct your client to use a
> certain key for a certain e-mail address.

> If it subsequently tries to encrypt to
> alias at example.org, it comes to the odd conclusion that it doesn't have a
> key for alias at example.org even though it literally just requested one
> and got an answer. I suspect that it simply would not produce a
> meaningful result.

I hadn't thought of it that way. I was under the impression that the email
client would do a WKD lookup to find a key, and then use that.

In fact, I thought I read somewhere that there was a requirement for the email
client using this system to not change the user's keyring.

And, if that is how it is implemented, surely that conflicts with other systems.
e.g. When I read an email in Evolution, it will automatically fetch any attached
key from the keyservers.
There is already no requirement for a user ID to match the email address it was
sent from (which could be faked anyway without DMARC validation). Therefore, if
somebody sends me an email with a a completely different user ID, and then
Evolution were to start behaving as you described, I could easily be sending
encrypted emails to the wrong keys.

So, if you are expecting this system to only be used for discovery, and then
encryption is done by searching the user's keyring, you have a whole bunch of
other security issues caused by other discovery systems already in use.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180406/7dcb7ee7/attachment.sig>

From peter at digitalbrains.com  Fri Apr  6 16:19:31 2018
From: peter at digitalbrains.com (Peter Lebbing)
Date: Fri, 6 Apr 2018 16:19:31 +0200
Subject: Web Key Discovery
In-Reply-To: <1523022505.3615.21.camel@sambull.org>
References: <1521643465.4063.3.camel@sambull.org>
 <a51fa88c-8874-0a41-1028-874ca411115a@incenp.org>
 <1521676357.13709.9.camel@sambull.org> <87sh8sa8x7.fsf@wheatstone.g10code.de>
 <1522068090.3927.5.camel@sambull.org> <1522753337.4009.5.camel@sambull.org>
 <cbfe9e3b-ae6b-5775-2771-4334f47b3cda@digitalbrains.com>
 <1523022505.3615.21.camel@sambull.org>
Message-ID: <c2283235-bf7b-2f27-6414-472f5a30cfce@digitalbrains.com>

On 06/04/18 15:48, Sam Bull wrote:
> In fact, I thought I read somewhere that there was a requirement for
> the email client using this system to not change the user's keyring.

The gpg command-line client itself can use this lookup method. GnuPG
only uses the keyring. Hence, the keyring is changed. I'd personally
prefer my e-mail client to have the same view of my keyring as my other
clients. I just read both the WKD wiki and the draft RFC this morning,
though in the latter I quickly skimmed through submission since I wasn't
interested in that before answering your mail. I did not see such a
requirement.

Finally, it's rather cumbersome to use keys not on the keyring, I
haven't personally experienced any clients that ever try to do this.

I think you are mistaken, but I'm not sure.

> And, if that is how it is implemented, surely that conflicts with
> other systems. e.g. When I read an email in Evolution, it will
> automatically fetch any attached key from the keyservers.

It does? That's a metadata leak. Some people might not mind, others would.

Does it do this to refresh the attached key?

Anyway, the mere presence of a key in the keyring does not make it
valid, like a WKD or DANE lookup might. I haven't looked at the
mechanism for validity through WKD and DANE; I just use TOFU and WoT
myself to establish validity. I will experiment with the others once I
get round to it. I think a WKD or DANE lookup combined with an
encryption action together establish First Use in the TOFU trust model,
but I'm not sure.

> There is already no requirement for a user ID to match the email
> address it was sent from (which could be faked anyway without DMARC
> validation). Therefore, if somebody sends me an email with a a
> completely different user ID, and then Evolution were to start
> behaving as you described, I could easily be sending encrypted emails
> to the wrong keys.

There should be some mechanism to establish validity. If Evolution
assigns validity based on reception of an unsigned e-mail, you should
probably file that as a security bug in Evolution. I don't use Evolution
for e-mail, I don't know anything about what it does with OpenPGP keys.

TOFU will tentatively assign validity to the key when it sees a
signature (and the UID matches), and will complain loudly once it sees a
different uid<->key binding at some later time. That's the whole point
of TOFU: Trust On First Use. This is First Use. (I'm no fan of the word
"Trust" in this monicker, it should be "validity" in OpenPGP terms)

> So, if you are expecting this system to only be used for discovery,
> and then encryption is done by searching the user's keyring, you have
> a whole bunch of other security issues caused by other discovery
> systems already in use.

You're missing one vital precondition: encryption is done by searching
the user's keyring for a *valid* key.

If WKD (or TOFU) does not meet your demands with regard to threat
models, you should use a more strict validity mechanism.

HTH,

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>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180406/76245829/attachment.sig>

From wk at gnupg.org  Fri Apr  6 16:16:11 2018
From: wk at gnupg.org (Werner Koch)
Date: Fri, 06 Apr 2018 16:16:11 +0200
Subject: WKD v05: DNS problem when requesting pubkey
In-Reply-To: <201804060944.42869.bernhard@intevation.de> (Bernhard Reiter's
 message of "Fri, 6 Apr 2018 09:44:30 +0200")
References: <201804051202.57012.bernhard@intevation.de>
 <871sfu0vvy.fsf@wheatstone.g10code.de>
 <b8f71893-18bf-d5d0-01a2-3d3586c22f81@digitalbrains.com>
 <201804060944.42869.bernhard@intevation.de>
Message-ID: <87in94xvx0.fsf@wheatstone.g10code.de>

On Fri,  6 Apr 2018 09:44, bernhard at intevation.de said:

>  * for http is is a performance penalty

Nobody says that you need to do a SRV query for all http requests.

>  * if it to be implemented in http it had to be agreed in an 
>    (upcoming) standard for http

SRV records have nothing to do with http but are required for certain
other services.  Web browser do all kind of stuff meanwhile and thus I
see no reason not to allow access - for extension - to do a bit more
than AAAA and CNAME queries.

> For understandable reasons the do not implement general networking
> as it would violate their security model around the same origin policy.

Now, that is a pretty lame excuse.


Salam-Shalom,

   Werner

-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180406/b82a6c3a/attachment.sig>

From wk at gnupg.org  Fri Apr  6 16:21:32 2018
From: wk at gnupg.org (Werner Koch)
Date: Fri, 06 Apr 2018 16:21:32 +0200
Subject: WKD v05: DNS problem when requesting pubkey
In-Reply-To: <201804060958.27556.bernhard@intevation.de> (Bernhard Reiter's
 message of "Fri, 6 Apr 2018 09:58:23 +0200")
References: <201804051202.57012.bernhard@intevation.de>
 <871sfu0vvy.fsf@wheatstone.g10code.de>
 <201804060958.27556.bernhard@intevation.de>
Message-ID: <87efjsxvo3.fsf@wheatstone.g10code.de>

On Fri,  6 Apr 2018 09:58, bernhard at intevation.de said:

> My suggestion is to remove the SRV record requirement again, because otherwise 
> we may exclude a significant number of users. Thus I'm thinking about better, 

NACK.  It is there for a reason.

> email provider cannot controll the policy file directly. Okay, so maybe a 
> https redirect is easier?

In general this is true.  But as I explained to you on the phone, there
are large mail providers who do not have a legal way to control the web
part but can change the DNS with the exception of the A, AAAA and CNAME
records used for the web service.

> That is another idea, thanks for bringing it up.
> Thinking about it: It would mean that SRV would only work for big providers 
> that register this with each Web-Extension. (You don't want to introduce a 
> central fixed list, wouldn't you. ;) )

That is how browser stuff works these days - too many things are already
centralized and thus adding another thing does not harm.


Shalom-Salam,

   Werner


-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180406/c700a792/attachment.sig>

From wk at gnupg.org  Fri Apr  6 16:26:00 2018
From: wk at gnupg.org (Werner Koch)
Date: Fri, 06 Apr 2018 16:26:00 +0200
Subject: Error after building gnupg head on Debian Buster at HEAD
In-Reply-To: <87d0zhi1ag.fsf@iwagami.gniibe.org> (NIIBE Yutaka's message of
 "Tue, 03 Apr 2018 09:25:27 +0900")
References: <CAAODAY+xrGguLPhkgqR2Q5eikwinFrTBdMOGsZeO2wecXk1h0A@mail.gmail.com>
 <CAAODAYL8veUS6=4x7HqVokw9TYcZx=v+Sge5ggGXV9EXwnDPUQ@mail.gmail.com>
 <87d0zhi1ag.fsf@iwagami.gniibe.org>
Message-ID: <87a7ugxvgn.fsf@wheatstone.g10code.de>

On Tue,  3 Apr 2018 02:25, gniibe at fsij.org said:

> New libassuan has new symbol (assuan_sock_set_system_hooks) whch is not
> available in old libassuan.

Let me add that we add new SO numbers only at release time and not
during development.  The reason for this is that we can easily
experiment with new APIs by adding them or removing them.  Obviously
this means that you need to use the latest libraries iff you want to use
the current master development branch.

Better to annoy a few people working on the bleeding edge code than to
annoy regular users.


Salam-Shalom,

   Werner

-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180406/8c6ebae4/attachment-0001.sig>

From gnupg-devel at sambull.org  Fri Apr  6 16:55:39 2018
From: gnupg-devel at sambull.org (Sam Bull)
Date: Fri, 06 Apr 2018 15:55:39 +0100
Subject: Web Key Discovery
In-Reply-To: <c2283235-bf7b-2f27-6414-472f5a30cfce@digitalbrains.com>
References: <1521643465.4063.3.camel@sambull.org>
 <a51fa88c-8874-0a41-1028-874ca411115a@incenp.org>
 <1521676357.13709.9.camel@sambull.org>
 <87sh8sa8x7.fsf@wheatstone.g10code.de>
 <1522068090.3927.5.camel@sambull.org> <1522753337.4009.5.camel@sambull.org>
 <cbfe9e3b-ae6b-5775-2771-4334f47b3cda@digitalbrains.com>
 <1523022505.3615.21.camel@sambull.org>
 <c2283235-bf7b-2f27-6414-472f5a30cfce@digitalbrains.com>
Message-ID: <1523026539.3615.54.camel@sambull.org>

On Fri, 2018-04-06 at 16:19 +0200, Peter Lebbing wrote:
> > And, if that is how it is implemented, surely that conflicts with
> > other systems. e.g. When I read an email in Evolution, it will
> > automatically fetch any attached key from the keyservers.
> It does? That's a metadata leak. Some people might not mind, others would.

So, Evolution just uses GnuPG directly, and I've added to the GnuPG config:

keyserver-options auto-key-retrieve

So, in actual fact, it is not Evolution performing this action itself, nor is it
the default behaviour.

> Anyway, the mere presence of a key in the keyring does not make it
> valid, like a WKD or DANE lookup might.

Right, but likewise, what if WKD decides a key is valid, but it has multiple
user IDs, then once again I could receive a "valid" key with a user ID that
doesn't belong to them and have the same issue.

The only way for this to work correctly, is if the email address the key has
been validated for is stored in addition to the key itself. At this point, there
is no advantage to the user ID matching the address, as you are individually
storing the addresses you have validated the key for.

> > There is already no requirement for a user ID to match the email
> > address it was sent from (which could be faked anyway without DMARC
> > validation). Therefore, if somebody sends me an email with a a
> > completely different user ID, and then Evolution were to start
> > behaving as you described, I could easily be sending encrypted emails
> > to the wrong keys.
> There should be some mechanism to establish validity. If Evolution
> assigns validity based on reception of an unsigned e-mail, you should
> probably file that as a security bug in Evolution. I don't use Evolution
> for e-mail, I don't know anything about what it does with OpenPGP keys.

I believe if you send a new message, it would never encrypt by default. The only
time it automatically encrypts (if you've enabled the settings) is when replying
to a message with a PGP signature. At that point you can be sure that you are
encrypting a reply to the person who sent you the message (regardless of the
email address).

I don't believe that it would automatically encrypt anything based on an email
address, and that is exactly why the WKD is here, to add that kind of feature.

I could be wrong on that though.

> > So, if you are expecting this system to only be used for discovery,
> > and then encryption is done by searching the user's keyring, you have
> > a whole bunch of other security issues caused by other discovery
> > systems already in use.
> You're missing one vital precondition: encryption is done by searching
> the user's keyring for a *valid* key.

Again, unless you have managed to validate every user ID, then it requires not
simply searching the keyring. But searching for a key that has been validated
against a specific address, in which case there is no reason to require the user
IDs to match, seeing as you've validated the key for an address regardless of
the user ID.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180406/88257525/attachment.sig>

From gnupg-devel at sambull.org  Fri Apr  6 17:22:18 2018
From: gnupg-devel at sambull.org (Sam Bull)
Date: Fri, 06 Apr 2018 16:22:18 +0100
Subject: Web Key Discovery
In-Reply-To: <201804061009.13165.bernhard@intevation.de>
References: <1521643465.4063.3.camel@sambull.org>
 <1522068090.3927.5.camel@sambull.org> <1522753337.4009.5.camel@sambull.org>
 <201804061009.13165.bernhard@intevation.de>
Message-ID: <1523028138.3615.72.camel@sambull.org>

Sorry if duplicate messages get sent, I've already replied to this, but can't
find the email in my sent items or on the mailing list... Not sure what's going
on.

On Fri, 2018-04-06 at 10:08 +0200, Bernhard Reiter wrote:
> Am Dienstag 03 April 2018 13:02:17 schrieb Sam Bull:
> > Why can't the web key discovery take the same approach?
> Because we want to defend to some extend against an email provider?
> manipulating the pubkeys it hands out for their users. Otherwise we are less?
> end-to-end. Therefore we essentially assume that one email address is one?
> identity.

I'm still not understanding how this adds any security at all. Surely, if an
email provider is manipulating the pubkeys, it would just create keys with
matching user IDs. What is the proposed attack that a matching user ID is
protecting against?

> My suggestion is: As you are the only user on the server and completely?
> controlling it: Add a new identity each time you create a new email alias
> automatically on a server. If you want more security use a hardware token.

Wouldn't the server need to have the private key in order to add additional user
IDs? That would obviously be a big drop in security. I already have 1000+
addresses, so it also seems a bit extreme sending a PGP key with 1000s of user
IDs.

> Note that someone how gets to control your server, could just create a new?
> email aliases and a completely new keypair they control and divert emails?
> send to you, so you cannot defend against all of these attacks anymay.

If the private key is on there, then they would also be able to secretly monitor
all my communications.

Also, I am assuming because WKD is done with HTTP requests, that I can run the
WKD on my personal server, while email is handled by my email provider.
Therefore, actually, they could not divert emails sent to me, without also
compromising my email provider or DNS.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180406/2b92b47f/attachment.sig>

From peter at digitalbrains.com  Fri Apr  6 18:05:16 2018
From: peter at digitalbrains.com (Peter Lebbing)
Date: Fri, 6 Apr 2018 18:05:16 +0200
Subject: Web Key Discovery
In-Reply-To: <1523026539.3615.54.camel@sambull.org>
References: <1521643465.4063.3.camel@sambull.org>
 <a51fa88c-8874-0a41-1028-874ca411115a@incenp.org>
 <1521676357.13709.9.camel@sambull.org> <87sh8sa8x7.fsf@wheatstone.g10code.de>
 <1522068090.3927.5.camel@sambull.org> <1522753337.4009.5.camel@sambull.org>
 <cbfe9e3b-ae6b-5775-2771-4334f47b3cda@digitalbrains.com>
 <1523022505.3615.21.camel@sambull.org>
 <c2283235-bf7b-2f27-6414-472f5a30cfce@digitalbrains.com>
 <1523026539.3615.54.camel@sambull.org>
Message-ID: <c21b5afc-1913-6354-55dd-b6a78f63a09a@digitalbrains.com>

On 06/04/18 16:55, Sam Bull wrote:
> Right, but likewise, what if WKD decides a key is valid, but it has
> multiple user IDs, then once again I could receive a "valid" key with
> a user ID that doesn't belong to them and have the same issue.

1) WKD should offer a key with a single UID.
2) Validity refers to UID's, not to complete certificates. Even if there
is some other UID on the certificate, TOFU would only validate the UID
that it has seen a mapping for.

> At this point, there is no advantage to the user ID matching the
> address, as you are individually storing the addresses you have
> validated the key for.

You validate a relation between an e-mail address in a UID and a key. If
you change the e-mail address, there is no UID to validate, there is no
relation, nothing.

HTH,

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>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180406/6abfc53c/attachment.sig>

From kyle at iteratee.net  Fri Apr  6 18:25:11 2018
From: kyle at iteratee.net (Kyle Butt)
Date: Fri, 6 Apr 2018 10:25:11 -0600
Subject: Error after building gnupg head on Debian Buster at HEAD
In-Reply-To: <87a7ugxvgn.fsf@wheatstone.g10code.de>
References: <CAAODAY+xrGguLPhkgqR2Q5eikwinFrTBdMOGsZeO2wecXk1h0A@mail.gmail.com>
 <CAAODAYL8veUS6=4x7HqVokw9TYcZx=v+Sge5ggGXV9EXwnDPUQ@mail.gmail.com>
 <87d0zhi1ag.fsf@iwagami.gniibe.org> <87a7ugxvgn.fsf@wheatstone.g10code.de>
Message-ID: <CAAODAYLX_m_zhhkf_3bQfgki7-Y7r4Dg03fju-6AHkRPaQ=A=w@mail.gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Just wanted to thank NIIBE,
That was in fact the problem. I had an older .so in /usr/local/lib and that
was in my LD_LIBRARY_PATH.
I had even tried rpath, but LD_LIBRARY_PATH gets searched first.

Thank you.
Kyle.
-----BEGIN PGP SIGNATURE-----

iLgEARMKAB0WIQRPZNYqHHHDubRyuhU9MXMrIXMZowUCWsefTQAKCRA9MXMrIXMZ
o3x7AgkBDOlmX71lDIx81UWcI4AxPD0bnKCBXAeowjxRdRd/LWVQ+5Gy3ns8J4wB
xIDh8hlHk4kndLGBH58UPu3veo07KtgCCPSo9pl4yYCWPqjDngxnkFe2T19anGKb
AFpw4BhVSYfAvyV+0M7MG2B0XTJXpBRMU7ZEXhcnfkjyxVBScczrG8ro
=2lmN
-----END PGP SIGNATURE-----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180406/91e1b763/attachment.html>

From ben at adversary.org  Fri Apr  6 21:49:22 2018
From: ben at adversary.org (Ben McGinnes)
Date: Sat, 7 Apr 2018 05:49:22 +1000
Subject: WKD v05: DNS problem when requesting pubkey
In-Reply-To: <201804051202.57012.bernhard@intevation.de>
References: <201804051202.57012.bernhard@intevation.de>
Message-ID: <20180406194922.7euetvhkn63yjlcm@adversary.org>

On Thu, Apr 05, 2018 at 12:02:52PM +0200, Bernhard Reiter wrote:
> 
> However according to my research, code running inside  a webbrowser - either 
> from a webpage or as extension - **cannot do a DNS request** on its own. 

Correct.

This is because JavaScript wouldn't know a networking stack if it
tripped over it.

JS is comnpletely oblivious to even the concept of what a network is
and any code you've see that suggests otherwise is solely reflecting
the mindset of the author, not the implementation of the scripting
language.

This is why it's always deployed on something else that does the heavy
lifting with regards to transport; usually web servers and browsers.

The only way around it will be both some kind of kludge and a means by
which the browser's sandboxing will need to be circumvented, either in
whole or in part.  When JavaScript is involved it's simply a matter of
picking the least worst work-around.  There are no best solutions.

Why do you think systems and networks admins hate the damned thing and
have a tendency to sneer at web developers?  This right here, is
scratching the surface of why.

Anyway, probably the most portable way would be to find a means of
tricking the browser into doing the work, then it'd (usually) palm the
task off to the OS natively.  The means may vary between browsers and
some of those may be of reduced effectiveness on other devices.


Regards,
Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180407/3cd55b13/attachment.sig>

From john at skopis.com  Sat Apr  7 12:14:40 2018
From: john at skopis.com (John Skopis)
Date: Sat, 7 Apr 2018 11:14:40 +0100
Subject: zstd compression
Message-ID: <CAJMjcEMRM7hA2okfV0LvSUSydDiP1dKzC=GJLPL80_qJg++szA@mail.gmail.com>

Hi there,

Long time user, first time caller.

I wrote this a few months ago fully intending on a) actually using it and
b) writing some tests . I've done neither. It works, superficially, though.

I've never used zstd or gnupg before this so if it is something you'd like
to merge maybe tap someone with experience there.

I guess the openpgp spec should be updated to include zstd as a compression
method.

Also, the compression api in gnupg is not exactly pluggable. I doubt anyone
cares (how often do you implement a new compression method?) but I wanted
to note it in case there's a backlog.

https://github.com/johnskopis/gnupg/tree/zstd

Cheers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180407/fc202023/attachment-0001.html>

From astieger at suse.com  Sat Apr  7 17:53:19 2018
From: astieger at suse.com (Andreas Stieger)
Date: Sat, 7 Apr 2018 17:53:19 +0200
Subject: zstd compression
In-Reply-To: <CAJMjcEMRM7hA2okfV0LvSUSydDiP1dKzC=GJLPL80_qJg++szA@mail.gmail.com>
References: <CAJMjcEMRM7hA2okfV0LvSUSydDiP1dKzC=GJLPL80_qJg++szA@mail.gmail.com>
Message-ID: <c5525197-c685-ef64-cd28-74f56089137d@suse.com>

Hello John,

On 04/07/2018 12:14 PM, John Skopis wrote:
> I guess the openpgp spec should be updated to include zstd as a
> compression method.

Current definition is in RFC 4880:
https://tools.ietf.org/html/rfc4880#section-9.3

So a reasonable in-development implementation will obviously use the
100..110 range for a "Private/Experimental algorithm" while this is
being added to the spec instead of just picking a number.

https://github.com/johnskopis/gnupg/commit/09fbe8880da1331121e43a49525eee08122f8825#diff-0e0f8c8faddc9631c4c0f020836f7587R195

+    COMPRESS_ALGO_ZSTD      =  4,

No wait I think you just did.

Andreas

-- 
Andreas Stieger <astieger at suse.com>
Project Manager Security
SUSE Linux GmbH, GF: Felix Imend?rffer, Jane Smithard, Graham Norton,
HRB 21284 (AG N?rnberg)


From wk at gnupg.org  Sun Apr  8 11:33:39 2018
From: wk at gnupg.org (Werner Koch)
Date: Sun, 08 Apr 2018 11:33:39 +0200
Subject: zstd compression
In-Reply-To: <CAJMjcEMRM7hA2okfV0LvSUSydDiP1dKzC=GJLPL80_qJg++szA@mail.gmail.com>
 (John Skopis's message of "Sat, 7 Apr 2018 11:14:40 +0100")
References: <CAJMjcEMRM7hA2okfV0LvSUSydDiP1dKzC=GJLPL80_qJg++szA@mail.gmail.com>
Message-ID: <87efjqvy8c.fsf@wheatstone.g10code.de>

On Sat,  7 Apr 2018 12:14, john at skopis.com said:

> I guess the openpgp spec should be updated to include zstd as a compression
> method.

It is very unlikely that new compression algorithms will be added to
OpenPGP.  Even the addition bzip2 algorithm was highly controversial and
later requests for other algorithms were all turned down.

You may use the experimental range of algorithms for zstd but that is
really experimental and should not be used for any messages which need
to be processed again in the future.


Salam-Shalom,

   Werner

-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180408/a79fd311/attachment.sig>

From john at skopis.com  Sun Apr  8 17:02:48 2018
From: john at skopis.com (John Skopis)
Date: Sun, 8 Apr 2018 16:02:48 +0100
Subject: zstd compression
In-Reply-To: <87efjqvy8c.fsf@wheatstone.g10code.de>
References: <CAJMjcEMRM7hA2okfV0LvSUSydDiP1dKzC=GJLPL80_qJg++szA@mail.gmail.com>
 <87efjqvy8c.fsf@wheatstone.g10code.de>
Message-ID: <CAJMjcEPHtgz29zRtW+0GcqR3t_wkSWmXe8hmmtzx7C8UMZ0hUA@mail.gmail.com>

I am admittedly unfamiliar with the history here. Can I ask what made bzip2
controversial?

>From my uniformed vantage point, it seems that a better algorithm is
available so we should be using it.

I would like to understand why what we have now is "good enough". Is there
some other reason we can't use a different library?

I am not interested in fighting with an IETF WG but I would like to
understand their viewpoint.

Thanks,
John

On Sun, Apr 8, 2018 at 10:33 AM, Werner Koch <wk at gnupg.org> wrote:

> On Sat,  7 Apr 2018 12:14, john at skopis.com said:
>
> > I guess the openpgp spec should be updated to include zstd as a
> compression
> > method.
>
> It is very unlikely that new compression algorithms will be added to
> OpenPGP.  Even the addition bzip2 algorithm was highly controversial and
> later requests for other algorithms were all turned down.
>
> You may use the experimental range of algorithms for zstd but that is
> really experimental and should not be used for any messages which need
> to be processed again in the future.
>
>
> Salam-Shalom,
>
>    Werner
>
> --
> #  Please read:  Daniel Ellsberg - The Doomsday Machine  #
> Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180408/bf8c3734/attachment.html>

From rjh at sixdemonbag.org  Sun Apr  8 19:41:23 2018
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Sun, 8 Apr 2018 13:41:23 -0400
Subject: zstd compression
In-Reply-To: <CAJMjcEPHtgz29zRtW+0GcqR3t_wkSWmXe8hmmtzx7C8UMZ0hUA@mail.gmail.com>
References: <CAJMjcEMRM7hA2okfV0LvSUSydDiP1dKzC=GJLPL80_qJg++szA@mail.gmail.com>
 <87efjqvy8c.fsf@wheatstone.g10code.de>
 <CAJMjcEPHtgz29zRtW+0GcqR3t_wkSWmXe8hmmtzx7C8UMZ0hUA@mail.gmail.com>
Message-ID: <faedd3da-1878-7604-ad3d-b59e0c2dc805@sixdemonbag.org>

> I am admittedly unfamiliar with the history here. Can I ask what made
> bzip2 controversial?

Werner knows this history better than I do; forgive me for skipping
this, please.

> From my uniformed vantage point, it seems that a better algorithm is
> available so we should be using it.

"It's a better algorithm" is rarely a good reason to do anything with a
mature standard that has a nontrivial user base.  New features should be
driven by the changing needs of users, not just because something
marginally better is available.

If you can find ten people for whom the lack of this feature
significantly impacts their use of OpenPGP, then sure: user needs have
changed and we should change with them.  But if you can't find ten users
who have a critical need for this feature, then ... why do we need to
add it?


From bernhard at intevation.de  Mon Apr  9 09:20:38 2018
From: bernhard at intevation.de (Bernhard Reiter)
Date: Mon, 9 Apr 2018 09:20:38 +0200
Subject: WKD v05: DNS problem when requesting pubkey
In-Reply-To: <87in94xvx0.fsf@wheatstone.g10code.de>
References: <201804051202.57012.bernhard@intevation.de>
 <201804060944.42869.bernhard@intevation.de>
 <87in94xvx0.fsf@wheatstone.g10code.de>
Message-ID: <201804090920.42844.bernhard@intevation.de>

Am Freitag 06 April 2018 16:16:11 schrieb Werner Koch:
> SRV records have nothing to do with http but are required for certain
> other services. ?Web browser do all kind of stuff meanwhile and thus I
> see no reason not to allow access - for extension - to do a bit more
> than AAAA and CNAME queries.

Well, yes, they could do that and offer an API.
But right now they do not and reading up on their issue trackers: 
it is unlikely they'll do so in the foreseeable future.

> > For understandable reasons the do not implement general networking
> > as it would violate their security model around the same origin policy.
>
> Now, that is a pretty lame excuse.

To be fair, that was my understanding of the situation why browsers do not 
allow direct access to a TCP or UDP connection and subsequently a reason why 
someone cannot just go and implement a DNS resolver in javascript to be used 
in the browser. 

Best,
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180409/3f5ce349/attachment.sig>

From bernhard at intevation.de  Mon Apr  9 09:30:21 2018
From: bernhard at intevation.de (Bernhard Reiter)
Date: Mon, 9 Apr 2018 09:30:21 +0200
Subject: javascript,
 networking and browsers (Re: WKD v05: DNS problem when requesting
 pubkey)
In-Reply-To: <20180406194922.7euetvhkn63yjlcm@adversary.org>
References: <201804051202.57012.bernhard@intevation.de>
 <20180406194922.7euetvhkn63yjlcm@adversary.org>
Message-ID: <201804090930.21652.bernhard@intevation.de>

Am Freitag 06 April 2018 21:49:22 schrieb Ben McGinnes:
> On Thu, Apr 05, 2018 at 12:02:52PM +0200, Bernhard Reiter wrote:
> > However according to my research, code running inside  a webbrowser -
> > either from a webpage or as extension - **cannot do a DNS request** on
> > its own.
>
> Correct.

Thanks for confirming.

> JS is comnpletely oblivious to even the concept of what a network is
> and any code you've see that suggests otherwise is solely reflecting
> the mindset of the author, not the implementation of the scripting
> language.

To be fair: Almost all programming languages know nothing about what a network 
is, usually it is in their standard libaries. The standard libraries for 
server side and native javascript is just growing, just look at the 
development of nodejs. Of of course there are many libraries that know about 
networks.

> The only way around it will be both some kind of kludge and a means by
> which the browser's sandboxing will need to be circumvented, either in
> whole or in part.  When JavaScript is involved it's simply a matter of
> picking the least worst work-around.  There are no best solutions.
>
> Why do you think systems and networks admins hate the damned thing and
> have a tendency to sneer at web developers?  This right here, is
> scratching the surface of why.

*sigh* There are advantages and disadvantages to Javascript and how it is 
deployed, and there are better and worse engineers. But there is no reason to 
generally believe one way or group of persons is generally superior to 
another. 

As I've outlined in my other post: To me it makes some sense to not allow 
general networking code in browsers. (I cannot claim that know if this is a 
sufficiently good decision but at least I can see that some serious 
engineering had been done.)

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180409/f26a7fda/attachment.sig>

From bernhard at intevation.de  Mon Apr  9 10:14:58 2018
From: bernhard at intevation.de (Bernhard Reiter)
Date: Mon, 9 Apr 2018 10:14:58 +0200
Subject: Web Key Discovery
In-Reply-To: <1523028138.3615.72.camel@sambull.org>
References: <1521643465.4063.3.camel@sambull.org>
 <201804061009.13165.bernhard@intevation.de>
 <1523028138.3615.72.camel@sambull.org>
Message-ID: <201804091015.04414.bernhard@intevation.de>

Am Freitag 06 April 2018 17:22:18 schrieb Sam Bull:
> > Because we want to defend to some extend against an email provider?
> > manipulating the pubkeys it hands out for their users. Otherwise we are
> > less? end-to-end. Therefore we essentially assume that one email address
> > is one identity.
>
> I'm still not understanding how this adds any security at all. Surely, if
> an email provider is manipulating the pubkeys, it would just create keys
> with matching user IDs. What is the proposed attack that a matching user ID
> is protecting against?

Against someone, including the email provider, that wants to give their pubkey 
to be used instead and do not want to be noticed. Against accidental use of a 
wrong pubkey for whatever reasons. (The defense happens like Peter explained, 
ideally we also look at the history.)

> > My suggestion is: As you are the only user on the server and completely?
> > controlling it: Add a new identity each time you create a new email alias
> > automatically on a server. If you want more security use a hardware
> > token.
>
> Wouldn't the server need to have the private key in order to add additional
> user IDs? That would obviously be a big drop in security. 

Yes, and no (as I've outlined).

> I already have 1000+ addresses, so it also seems a bit extreme sending a
> PGP key with 1000s of user IDs.

You could create a copy each time, each with only one user ID on it.

> > Note that someone how gets to control your server, could just create a
> > new? email aliases and a completely new keypair they control and divert
> > emails send to you, so you cannot defend against all of these attacks
> > anymay.
>
> If the private key is on there, then they would also be able to secretly
> monitor all my communications.

Yes, but if it is not on there, they would just use their own private key
and act as a man in the middle.

> Also, I am assuming because WKD is done with HTTP requests, that I can run
> the WKD on my personal server, while email is handled by my email provider.

Yes, WKD can be run on the webserver of the email-domain, which can be under 
different control than the email server.

> Therefore, actually, they could not divert emails sent to me, without also
> compromising my email provider or DNS.

Correct.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180409/37124262/attachment-0001.sig>

From bernhard at intevation.de  Mon Apr  9 10:23:19 2018
From: bernhard at intevation.de (Bernhard Reiter)
Date: Mon, 9 Apr 2018 10:23:19 +0200
Subject: WKD v05: DNS problem when requesting pubkey
In-Reply-To: <87efjsxvo3.fsf@wheatstone.g10code.de>
References: <201804051202.57012.bernhard@intevation.de>
 <201804060958.27556.bernhard@intevation.de>
 <87efjsxvo3.fsf@wheatstone.g10code.de>
Message-ID: <201804091023.20192.bernhard@intevation.de>

Am Freitag 06 April 2018 16:21:32 schrieb Werner Koch:
> In general this is true. ?But as I explained to you on the phone, there
> are large mail providers who do not have a legal way to control the web
> part but can change the DNS with the exception of the A, AAAA and CNAME
> records used for the web service.

I know. Still using a DNS SRV record is a significant problem, because of the 
number of webmail users and I'd rather have a better solution.
As you've written that the lookup is optional, a rudimentary step forward 
would be to declare the lookup option. This way providers know that they'll 
be excluded from some clients if they rely on the SRV record "hack".

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180409/ab6a88c4/attachment.sig>

From gnupg-devel at sambull.org  Mon Apr  9 15:00:06 2018
From: gnupg-devel at sambull.org (Sam Bull)
Date: Mon, 09 Apr 2018 14:00:06 +0100
Subject: Web Key Discovery
In-Reply-To: <201804091015.04414.bernhard@intevation.de>
References: <1521643465.4063.3.camel@sambull.org>
 <201804061009.13165.bernhard@intevation.de>
 <1523028138.3615.72.camel@sambull.org>
 <201804091015.04414.bernhard@intevation.de>
Message-ID: <1523278806.3976.12.camel@sambull.org>

On Mon, 2018-04-09 at 10:14 +0200, Bernhard Reiter wrote:
> Am Freitag 06 April 2018 17:22:18 schrieb Sam Bull:
> > > My suggestion is: As you are the only user on the server and completely?
> > > controlling it: Add a new identity each time you create a new email alias
> > > automatically on a server. If you want more security use a hardware
> > > token.
> > Wouldn't the server need to have the private key in order to add additional
> > user IDs? That would obviously be a big drop in security.?
> Yes, and no (as I've outlined).

Outlined where? I'm still not sure I understand how you would add a new ID
without a private key?

> > I already have 1000+ addresses, so it also seems a bit extreme sending a
> > PGP key with 1000s of user IDs.
> You could create a copy each time, each with only one user ID on it.

That sounds like an interesting idea.

Am I right in thinking that user IDs and the key itself, are essentially
separate things. So, if someone receives a key with user ID A, and I later
encrypt/sign with the same key but with user ID B, it won't cause any issues?
	Or would I need to add the matching user ID to the key before I
sign/encrypt?

> > > Note that someone how gets to control your server, could just create a
> > > new? email aliases and a completely new keypair they control and divert
> > > emails send to you, so you cannot defend against all of these attacks
> > > anymay.
> > If the private key is on there, then they would also be able to secretly
> > monitor all my communications.
> Yes, but if it is not on there, they would just use their own private key
> and act as a man in the middle.

Sure, but that's much easier to detect. e.g. Failing DMARC validation in both
directions all the time (if they don't have access to my email provider or DNS).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180409/d508a809/attachment.sig>

From bernhard at intevation.de  Mon Apr  9 15:29:38 2018
From: bernhard at intevation.de (Bernhard Reiter)
Date: Mon, 9 Apr 2018 15:29:38 +0200
Subject: Web Key Discovery
In-Reply-To: <1523278806.3976.12.camel@sambull.org>
References: <1521643465.4063.3.camel@sambull.org>
 <201804091015.04414.bernhard@intevation.de>
 <1523278806.3976.12.camel@sambull.org>
Message-ID: <201804091529.43499.bernhard@intevation.de>

Am Montag 09 April 2018 15:00:06 schrieb Sam Bull:
> Outlined where? I'm still not sure I understand how you would add a new ID
> without a private key?

In my first response I've outlined that having your private key on your server 
does not constitute a "major drop" in security.

> So, if someone receives a key with user ID A, and I later
> encrypt/sign with the same key but with user ID B, it won't cause any
> issues? 

Correct, you don't need to see a specific user ID to be able to encrypt to it.
However many email clients put up a warning, which is good.
If you receive cipher text, you can decrypt it, independently from the user ID 
that your pubkey had when it was encrypted to it.

> > Yes, but if it is not on there, they would just use their own private key
> > and act as a man in the middle.
>
> Sure, but that's much easier to detect. e.g. Failing DMARC validation in
> both directions all the time (if they don't have access to my email
> provider or DNS).

Maybe (I don't know, because my knowledge of DMARC is limited, if an attacker 
controls your email server, aren't they the legitimate transport MTA?)

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180409/1bf314b3/attachment.sig>

From gnupg-devel at sambull.org  Mon Apr  9 15:55:21 2018
From: gnupg-devel at sambull.org (Sam Bull)
Date: Mon, 09 Apr 2018 14:55:21 +0100
Subject: Web Key Discovery
In-Reply-To: <201804091529.43499.bernhard@intevation.de>
References: <1521643465.4063.3.camel@sambull.org>
 <201804091015.04414.bernhard@intevation.de>
 <1523278806.3976.12.camel@sambull.org>
 <201804091529.43499.bernhard@intevation.de>
Message-ID: <1523282121.3976.21.camel@sambull.org>

On Mon, 2018-04-09 at 15:29 +0200, Bernhard Reiter wrote:
> Am Montag 09 April 2018 15:00:06 schrieb Sam Bull:
> > Outlined where? I'm still not sure I understand how you would add a new ID
> > without a private key?
> In my first response I've outlined that having your private key on your server
> does not constitute a "major drop" in security.

OK, I misunderstood what you meant.

But, as I mentioned earlier, my email provider would be separate from my WKD
server. So, compromising my server with a private key causes a large break in my
security (potentially without my knowledge). Whereas, without a private key, if
they don't also have access to my email provider or DNS, they would find it
difficult to do anything more than be a nuisance.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180409/94b31f44/attachment.sig>

From peter at digitalbrains.com  Mon Apr  9 16:16:34 2018
From: peter at digitalbrains.com (Peter Lebbing)
Date: Mon, 9 Apr 2018 16:16:34 +0200
Subject: Web Key Discovery
In-Reply-To: <1523026539.3615.54.camel@sambull.org>
References: <1521643465.4063.3.camel@sambull.org>
 <a51fa88c-8874-0a41-1028-874ca411115a@incenp.org>
 <1521676357.13709.9.camel@sambull.org> <87sh8sa8x7.fsf@wheatstone.g10code.de>
 <1522068090.3927.5.camel@sambull.org> <1522753337.4009.5.camel@sambull.org>
 <cbfe9e3b-ae6b-5775-2771-4334f47b3cda@digitalbrains.com>
 <1523022505.3615.21.camel@sambull.org>
 <c2283235-bf7b-2f27-6414-472f5a30cfce@digitalbrains.com>
 <1523026539.3615.54.camel@sambull.org>
Message-ID: <77c49fa2-3ac2-d249-037a-e7fa76ba3b30@digitalbrains.com>

On 06/04/18 16:55, Sam Bull wrote:
> The only way for this to work correctly, is if the email address the key has
> been validated for is stored in addition to the key itself. At this point, there
> is no advantage to the user ID matching the address, as you are individually
> storing the addresses you have validated the key for.

WKD and TOFU work on two "problems": discovery and validation. They
specify how to find a key and they give a mechanism to assign a level of
validity to UID's.

What they do not work on is key binding. They do not change how OpenPGP
binds e-mail addresses to keys. OpenPGP does this binding by having UIDs
on keys. The validity of this UID will then still need to be determined;
an invalid UID also does not bind.

What you are proposing is a different mechanism of key binding. While
this is perfectly valid, it is not WKD or TOFU as it is currently
designed, as I understand it. Rather, it is a new design to tackle the
"problem" of key binding.

A good design is more than just noting that "there is no advantage" to
elements of an existing different design and tossing it out. Especially
when there are adversaries involved like in cryptography, you need to
think well about the implications. Preferably you should consider all
aspects well during the design phase, rather than reshape an existing
design that never accounted for the way you will use it now. The history
of cryptography has quite some "D'oh!" moments because people thought
they could bend existing algorithms to perform new tasks. If it was just
Homer Simpson embarassing himself it wouldn't be that bad, unfortunately
the stakes are higher.

HTH,

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>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180409/0c4a2b13/attachment.sig>

From wk at gnupg.org  Mon Apr  9 18:53:53 2018
From: wk at gnupg.org (Werner Koch)
Date: Mon, 09 Apr 2018 18:53:53 +0200
Subject: cv25519 scalar byte order
In-Reply-To: <87bmglkkvs.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message
 of "Mon, 19 Feb 2018 08:24:39 -0800")
References: <20180211120549.GA23215@calamity>
 <87o9ktxdbz.fsf@wheatstone.g10code.de>
 <20180213220358.GA31022@calamity> <87r2pop9sz.fsf@iwagami.gniibe.org>
 <878tbw5f2b.fsf@fsij.org> <87po51oy7l.fsf@wheatstone.g10code.de>
 <87bmglkkvs.fsf@fifthhorseman.net>
Message-ID: <87woxgtj6m.fsf@wheatstone.g10code.de>

On Mon, 19 Feb 2018 17:24, dkg at fifthhorseman.net said:

>> That would be incorrect.  The prefix (e.g. 0x40) indicates a _point_
>> format and not the format of a scalar.  Thus skey[3] MAY not have this
>> prefix.
>
> what does this "MAY NOT" mean?  if this is an attempt at RFC 2119
> language, i don't understand it.  Do you mean "MUST NOT" ?

I was thinking SHOULD NOT but indeed it MUST be MUST NOT.

> What steps are needed to clarify the documentation here so that we can
> have interoperable implementations?

I can't remember an open issue regaring this in the WG.  Should be
handled there anyway,


Salam-Shalom,

   Werner


-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180409/a024d288/attachment-0001.sig>

From wk at gnupg.org  Mon Apr  9 18:25:06 2018
From: wk at gnupg.org (Werner Koch)
Date: Mon, 09 Apr 2018 18:25:06 +0200
Subject: zstd compression
In-Reply-To: <CAJMjcEPHtgz29zRtW+0GcqR3t_wkSWmXe8hmmtzx7C8UMZ0hUA@mail.gmail.com>
 (John Skopis's message of "Sun, 8 Apr 2018 16:02:48 +0100")
References: <CAJMjcEMRM7hA2okfV0LvSUSydDiP1dKzC=GJLPL80_qJg++szA@mail.gmail.com>
 <87efjqvy8c.fsf@wheatstone.g10code.de>
 <CAJMjcEPHtgz29zRtW+0GcqR3t_wkSWmXe8hmmtzx7C8UMZ0hUA@mail.gmail.com>
Message-ID: <87a7ucuz31.fsf@wheatstone.g10code.de>

On Sun,  8 Apr 2018 17:02, john at skopis.com said:

>>From my uniformed vantage point, it seems that a better algorithm is
> available so we should be using it.

Simply that it is yet another algorithm We already had implemented to
variants of gzip and bzip does not gain much except for complicated the
test matrix a lot.  OpenPGP is not an online protocol but we need to
make sure that OpenPGP encrypted data can be processed in the decades to
come.  Each new algorithm makes that harder.  In the OpenPGP WG we
really try to keep the number of algorithms low and add new ones only if
there is a real benefit or maybe a political reason (e.g. Camellia)

> I would like to understand why what we have now is "good enough". Is there
> some other reason we can't use a different library?

It is not about a library but about a standard.  There are
cryptographers out there who think that a single algorithm is the best
thing to have.  And they do have a point.

> I am not interested in fighting with an IETF WG but I would like to

The IETF as referenced here are the folks who work on a standard and
they all have different opinions.  From my 20 years in the OpenPGP WG I
_assume_ that the majority of the folks won't like the idea.  But feel
free to write to the WG mailing list (search tools.ietf.org for the
address).


Shalom-Salam,

   Werner

-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180409/1e40e64b/attachment.sig>

From dkg at fifthhorseman.net  Mon Apr  9 20:51:03 2018
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 09 Apr 2018 14:51:03 -0400
Subject: cv25519 scalar byte order
In-Reply-To: <87woxgtj6m.fsf@wheatstone.g10code.de>
References: <20180211120549.GA23215@calamity>
 <87o9ktxdbz.fsf@wheatstone.g10code.de> <20180213220358.GA31022@calamity>
 <87r2pop9sz.fsf@iwagami.gniibe.org> <878tbw5f2b.fsf@fsij.org>
 <87po51oy7l.fsf@wheatstone.g10code.de> <87bmglkkvs.fsf@fifthhorseman.net>
 <87woxgtj6m.fsf@wheatstone.g10code.de>
Message-ID: <87lgdwxlgo.fsf@fifthhorseman.net>

Over in
https://lists.gnupg.org/pipermail/gnupg-devel/2018-February/033437.html,
a discussion was started about scalar byte order for OpenPGP curve 25519
keys:

On Mon 2018-04-09 18:53:53 +0200, Werner Koch wrote:
> On Mon, 19 Feb 2018 17:24, dkg at fifthhorseman.net said:
> [ gniibe wrote: ]
>>> That would be incorrect.  The prefix (e.g. 0x40) indicates a _point_
>>> format and not the format of a scalar.  Thus skey[3] MAY not have this
>>> prefix.
>>
>> what does this "MAY NOT" mean?  if this is an attempt at RFC 2119
>> language, i don't understand it.  Do you mean "MUST NOT" ?
>
> I was thinking SHOULD NOT but indeed it MUST be MUST NOT.
>
>> What steps are needed to clarify the documentation here so that we can
>> have interoperable implementations?
>
> I can't remember an open issue regaring this in the WG.  Should be
> handled there anyway,

I'm moving this discussion to the WG :)

    --dkg


From dkg at fifthhorseman.net  Tue Apr 10 01:17:02 2018
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 09 Apr 2018 19:17:02 -0400
Subject: 2.2.6 tarball signature?
Message-ID: <87tvskvukx.fsf@fifthhorseman.net>

Hey folks--

I see that:

   https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.6.tar.bz2

is out, but there is no corresponding:

   https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.6.tar.bz2.sig

I see that the gnupg-2.2.6 git tag has been signed (by
D8692123C4065DEA5E0F3AB5249B39D24F25E3B6), so i want to believe the
release is official, but i don't see the tarball signature yet.

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180409/51eee25c/attachment.sig>

From wk at gnupg.org  Tue Apr 10 08:15:53 2018
From: wk at gnupg.org (Werner Koch)
Date: Tue, 10 Apr 2018 08:15:53 +0200
Subject: 2.2.6 tarball signature?
In-Reply-To: <87tvskvukx.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message
 of "Mon, 09 Apr 2018 19:17:02 -0400")
References: <87tvskvukx.fsf@fifthhorseman.net>
Message-ID: <87muybtwme.fsf@wheatstone.g10code.de>

On Tue, 10 Apr 2018 01:17, dkg at fifthhorseman.net said:

> is out, but there is no corresponding:
>
>    https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.6.tar.bz2.sig

Just uploaded.  The upload process is manual and if you get the {,.sig}
pattern wrong one of the files won't gte uploaded.  I should really
automate the whole release process ;-)


Salam-Shalom,

   Werner

-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180410/9f769b90/attachment.sig>

From bernhard at intevation.de  Tue Apr 10 12:29:38 2018
From: bernhard at intevation.de (Bernhard Reiter)
Date: Tue, 10 Apr 2018 12:29:38 +0200
Subject: Web Key Discovery
In-Reply-To: <1523282121.3976.21.camel@sambull.org>
References: <1521643465.4063.3.camel@sambull.org>
 <201804091529.43499.bernhard@intevation.de>
 <1523282121.3976.21.camel@sambull.org>
Message-ID: <201804101229.39187.bernhard@intevation.de>

> But, as I mentioned earlier, my email provider would be separate from my
> WKD server.

Then you could have your private key on your WKD server and create the new 
signatures with the new user IDs for the private key there.


-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180410/d7d82ae8/attachment.sig>

From wk at gnupg.org  Tue Apr 10 19:47:19 2018
From: wk at gnupg.org (Werner Koch)
Date: Tue, 10 Apr 2018 19:47:19 +0200
Subject: [Announce] GnuPG 2.2.6 released
Message-ID: <877epfrm1k.fsf@wheatstone.g10code.de>

Hello!

We are is pleased to announce the availability of a new GnuPG release:
version 2.2.6.  This is a maintenance release; see below for a list of
fixed bugs.


About GnuPG
===========

The GNU Privacy Guard (GnuPG) is a complete and free implementation
of the OpenPGP standard which is commonly abbreviated as PGP.

GnuPG allows to encrypt and sign data and communication, features a
versatile key management system as well as access modules for public key
directories.  GnuPG itself is a command line tool with features for easy
integration with other applications.  A wealth of frontend applications
and libraries making use of GnuPG are available.  As an Universal Crypto
Engine GnuPG provides support for S/MIME and Secure Shell in addition to
OpenPGP.

GnuPG is Free Software (meaning that it respects your freedom).  It can
be freely used, modified and distributed under the terms of the GNU
General Public License.


Noteworthy changes in version 2.2.6
===================================

  * gpg,gpgsm: New option --request-origin to pretend requests coming
    from a browser or a remote site.

  * gpg: Fix race condition on trustdb.gpg updates due to too early
    released lock.  [#3839]

  * gpg: Emit FAILURE status lines in almost all cases.  [#3872]

  * gpg: Implement --dry-run for --passwd to make checking a key's
    passphrase straightforward.

  * gpg: Make sure to only accept a certification capable key for key
    signatures.  [#3844]

  * gpg: Better user interaction in --card-edit for the factory-reset
    sub-command.

  * gpg: Improve changing key attributes in --card-edit by adding an
    explicit "key-attr" sub-command.  [#3781]

  * gpg: Print the keygrips in the --card-status.

  * scd: Support KDF DO setup.  [#3823]

  * scd: Fix some issues with PC/SC on Windows.  [#3825]

  * scd: Fix suspend/resume handling in the CCID driver.

  * agent: Evict cached passphrases also via a timer.  [#3829]

  * agent: Use separate passphrase caches depending on the request
    origin.  [#3858]

  * ssh: Support signature flags.  [#3880]

  * dirmngr: Handle failures related to missing IPv6 support
    gracefully.  [#3331]

  * Fix corner cases related to specified home directory with
    drive letter on Windows.  [#3720]

  * Allow the use of UNC directory names as homedir.  [#3818]


Getting the Software
====================

Please follow the instructions found at <https://gnupg.org/download/> or
read on:

GnuPG 2.2.6 may be downloaded from one of the GnuPG mirror sites or
direct from its primary FTP server.  The list of mirrors can be found at
<https://gnupg.org/download/mirrors.html>.  Note that GnuPG is not
available at ftp.gnu.org.

The GnuPG source code compressed using BZIP2 and its OpenPGP signature
are available here:

 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.6.tar.bz2 (6430k)
 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.6.tar.bz2.sig

An installer for Windows without any graphical frontend except for a
very minimal Pinentry tool is available here:

 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.6_20180409.exe (3819k)
 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.6_20180409.exe.sig

The source used to build the Windows installer can be found in the same
directory with a ".tar.xz" suffix.  A new Gpg4win installer featuring
this version of GnuPG will be available soon.


Checking the Integrity
======================

In order to check that the version of GnuPG which you are going to
install is an original and unmodified one, you can do it in one of
the following ways:

 * If you already have a version of GnuPG installed, you can simply
   verify the supplied signature.  For example to verify the signature
   of the file gnupg-2.2.6.tar.bz2 you would use this command:

     gpg --verify gnupg-2.2.6.tar.bz2.sig gnupg-2.2.6.tar.bz2

   This checks whether the signature file matches the source file.
   You should see a message indicating that the signature is good and
   made by one or more of the release signing keys.  Make sure that
   this is a valid key, either by matching the shown fingerprint
   against a trustworthy list of valid release signing keys or by
   checking that the key has been signed by trustworthy other keys.
   See the end of this mail for information on the signing keys.

 * If you are not able to use an existing version of GnuPG, you have
   to verify the SHA-1 checksum.  On Unix systems the command to do
   this is either "sha1sum" or "shasum".  Assuming you downloaded the
   file gnupg-2.2.6.tar.bz2, you run the command like this:

     sha1sum gnupg-2.2.6.tar.bz2

   and check that the output matches the next line:

295298debcc2c12f02a2f2fdf04aecb6d6aae396  gnupg-2.2.6.tar.bz2
c9fe66788ea40bc57a189aa13e7c83add9baec40  gnupg-w32-2.2.6_20180409.exe
caff25b6576a8a2d63db844bb343c8d5455286d4  gnupg-w32-2.2.6_20180409.tar.xz


Internationalization
====================

This version of GnuPG has support for 26 languages with Chinese, Czech,
French, German, Japanese, Norwegian, Russian, and Ukrainian being almost
completely translated.


Documentation and Support
=========================

If you used GnuPG in the past you should read the description of
changes and new features at doc/whats-new-in-2.1.txt or online at

  https://gnupg.org/faq/whats-new-in-2.1.html

The file gnupg.info has the complete reference manual of the system.
Separate man pages are included as well but they miss some of the
details availabale only in thee manual.  The manual is also available
online at

  https://gnupg.org/documentation/manuals/gnupg/

or can be downloaded as PDF at

  https://gnupg.org/documentation/manuals/gnupg.pdf .

The chapters on gpg-agent, gpg and gpgsm include information on how to
set up the whole thing.  You may also want to search the GnuPG mailing
list archives or ask on the gnupg-users mailing list for advise on how
to solve problems.  Most of the new features are around for several
years and thus enough public experience is available.

Please consult the archive of the gnupg-users mailing list before
reporting a bug: <https://gnupg.org/documentation/mailing-lists.html>.
We suggest to send bug reports for a new release to this list in favor
of filing a bug at <https://bugs.gnupg.org>.  If you need commercial
support check out <https://gnupg.org/service.html>.

If you are a developer and you need a certain feature for your project,
please do not hesitate to bring it to the gnupg-devel mailing list for
discussion.


Thanks
======

Maintenance and development of GnuPG is mostly financed by donations.
The GnuPG project currently employs one full-time developer and one
contractor.  Both work exclusively on GnuPG and closely related software
like Libgcrypt, GPGME, and GPA.  We are planning to extend our team
again and to help developers to improve integration of crypto in their
applications.

We have to thank all the people who helped the GnuPG project, be it
testing, coding, translating, suggesting, auditing, administering the
servers, spreading the word, and answering questions on the mailing
lists.

Many thanks to our numerous financial supporters, both corporate and
individuals.  Without you it would not be possible to keep GnuPG in a
good shape and address all the small and larger requests made by our
users.  Thanks.


Happy hacking,

   Your GnuPG hackers



p.s.
This is an announcement only mailing list.  Please send replies only to
the gnupg-users'at'gnupg.org mailing list.

p.p.s
List of Release Signing Keys:

To guarantee that a downloaded GnuPG version has not been tampered by
malicious entities we provide signature files for all tarballs and
binary versions.  The keys are also signed by the long term keys of
their respective owners.  Current releases are signed by one or more
of these four keys:

  rsa2048 2011-01-12 [expires: 2019-12-31]
  Key fingerprint = D869 2123 C406 5DEA 5E0F  3AB5 249B 39D2 4F25 E3B6
  Werner Koch (dist sig)

  rsa2048 2014-10-29 [expires: 2019-12-31]
  Key fingerprint = 46CC 7308 65BB 5C78 EBAB  ADCF 0437 6F3E E085 6959
  David Shaw (GnuPG Release Signing Key) <dshaw 'at' jabberwocky.com>

  rsa2048 2014-10-29 [expires: 2020-10-30]
  Key fingerprint = 031E C253 6E58 0D8E A286  A9F2 2071 B08A 33BD 3F06
  NIIBE Yutaka (GnuPG Release Key) <gniibe 'at' fsij.org>

  rsa3072 2017-03-17 [expires: 2027-03-15]
  Key fingerprint = 5B80 C575 4298 F0CB 55D8  ED6A BCEF 7E29 4B09 2E28
  Andre Heinecke (Release Signing Key)

The keys are available at <https://gnupg.org/signature_key.html> and
in any recently released GnuPG tarball in the file g10/distsigkey.gpg .
Note that this mail has been signed by a different key.

-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180410/d895986c/attachment.sig>
-------------- next part --------------
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce

From dgouttegattat at incenp.org  Wed Apr 11 17:06:01 2018
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Wed, 11 Apr 2018 16:06:01 +0100
Subject: [PATCH libgpg-error] build: Make sure version.texi is generated in
 time.
Message-ID: <20180411150601.12242-1-dgouttegattat@incenp.org>

* doc/Makefile.am (yat2m-stamp): Depend on version.texi.
--

When building from a cloned Git repository and with `make -j 3`
(or higher), the version.texi file may not have been generated
yet when yat2m is called to generate the man page, resulting in
a build failure.

Signed-off-by: Damien Goutte-Gattat <dgouttegattat at incenp.org>
---
 doc/Makefile.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/Makefile.am b/doc/Makefile.am
index d5eb886..7439a49 100644
--- a/doc/Makefile.am
+++ b/doc/Makefile.am
@@ -54,7 +54,7 @@ YAT2M_DEP = yat2m
 endif
 endif
 
-yat2m-stamp: $(myman_sources)
+yat2m-stamp: $(myman_sources) $(srcdir)/version.texi
 	@rm -f yat2m-stamp.tmp
 	@touch yat2m-stamp.tmp
 	for file in $(myman_sources) ; do \
-- 
2.14.1


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180411/2ab1fe4c/attachment-0001.sig>

From wk at gnupg.org  Wed Apr 11 20:55:36 2018
From: wk at gnupg.org (Werner Koch)
Date: Wed, 11 Apr 2018 20:55:36 +0200
Subject: [PATCH libgpg-error] build: Make sure version.texi is generated
 in time.
In-Reply-To: <20180411150601.12242-1-dgouttegattat@incenp.org> (Damien
 Goutte-Gattat via Gnupg-devel's message of "Wed, 11 Apr 2018 16:06:01
 +0100")
References: <20180411150601.12242-1-dgouttegattat@incenp.org>
Message-ID: <87efjlr2s7.fsf@wheatstone.g10code.de>

On Wed, 11 Apr 2018 17:06, gnupg-devel at gnupg.org said:

> When building from a cloned Git repository and with `make -j 3`
> (or higher), the version.texi file may not have been generated
> yet when yat2m is called to generate the man page, resulting in

Pushed.  Thanks.


Salam-Shalom,

   Werner

-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180411/f0a389e0/attachment.sig>

From patrick at enigmail.net  Sat Apr 14 10:56:36 2018
From: patrick at enigmail.net (Patrick Brunschwig)
Date: Sat, 14 Apr 2018 10:56:36 +0200
Subject: javascript, networking and browsers (Re: WKD v05: DNS problem
 when requesting pubkey)
In-Reply-To: <201804090930.21652.bernhard@intevation.de>
References: <201804051202.57012.bernhard@intevation.de>
 <20180406194922.7euetvhkn63yjlcm@adversary.org>
 <201804090930.21652.bernhard@intevation.de>
Message-ID: <4058e5b9-7654-6163-712d-fb2f48ca5f00@enigmail.net>

On 09.04.18 09:30, Bernhard Reiter wrote:
> Am Freitag 06 April 2018 21:49:22 schrieb Ben McGinnes:
>> On Thu, Apr 05, 2018 at 12:02:52PM +0200, Bernhard Reiter wrote:
>>> However according to my research, code running inside  a webbrowser -
>>> either from a webpage or as extension - **cannot do a DNS request** on
>>> its own.
>>
>> Correct.
> 
> Thanks for confirming.
> 
>> JS is comnpletely oblivious to even the concept of what a network is
>> and any code you've see that suggests otherwise is solely reflecting
>> the mindset of the author, not the implementation of the scripting
>> language.
> 
> To be fair: Almost all programming languages know nothing about what a network 
> is, usually it is in their standard libaries. The standard libraries for 
> server side and native javascript is just growing, just look at the 
> development of nodejs. Of of course there are many libraries that know about 
> networks.

I'm sorry for jumping in a bit late. I can only agree to Bernhard. For
example in Enigmail, I can use a DNS service class provided by the
Mozilla platform, but that class would not allow me to query specific
DNS record types. All I can do is simple name resolving.

I decided to implement WKD lookup in Enigmail and not use the function
offered by GnuPG because a) Enigmail is likely to still support GnuPG
2.0.x for many years - at least on Linux distributions like RedHad, and
b) for performance reasons. By specifying SRV record lookups mandatory,
you ensure that Enigmail will violate the specification.

-Patrick


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180414/9f1d67d1/attachment.sig>

From look at my.amazin.horse  Sat Apr 14 13:20:56 2018
From: look at my.amazin.horse (Vincent Breitmoser)
Date: Sat, 14 Apr 2018 13:20:56 +0200
Subject: WKD v05: DNS problem when requesting pubkey
In-Reply-To: <87efjsxvo3.fsf@wheatstone.g10code.de>
References: <201804051202.57012.bernhard@intevation.de>
 <871sfu0vvy.fsf@wheatstone.g10code.de>
 <201804060958.27556.bernhard@intevation.de>
 <87efjsxvo3.fsf@wheatstone.g10code.de>
Message-ID: <20180414112056.czjjlhiil2o3cmqw@calamity>

> In general a SRV record is not required and I expect that most Web key
> directories won't use that anyway.  Thus the failure rate would be quite low

...

> But as I explained to you on the phone, there are large mail providers who do
> not have a legal way to control the web part but can change the DNS with the
> exception of the A, AAAA and CNAME records used for the web service.

Those two pieces don't seem to fit. It's not required, most web key directories
won't use them, so you expect a low failure rate except for a bunch of large
mail providers?

 - V



From wk at gnupg.org  Mon Apr 16 09:19:35 2018
From: wk at gnupg.org (Werner Koch)
Date: Mon, 16 Apr 2018 09:19:35 +0200
Subject: [PATCH gpa] Load the secret keyring before the public one.
In-Reply-To: <20180329125257.1671-1-dgouttegattat@incenp.org> (Damien
 Goutte-Gattat's message of "Thu, 29 Mar 2018 13:52:57 +0100")
References: <20180219095946.5307-1-dgouttegattat@incenp.org>
 <20180329125257.1671-1-dgouttegattat@incenp.org>
Message-ID: <87bmejmxdk.fsf@wheatstone.g10code.de>

On Thu, 29 Mar 2018 14:52, dgouttegattat at incenp.org said:

> I sent the patch below a few weeks ago to tentatively fix bug 3748,
> which affects GPA when using a TOFU trust model.
>
> Any follow-up on this?

Thanks for the reminder.  I just pushed it.


Shalom-Salam,

   Werner

-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180416/4ea459d7/attachment.sig>

From bernhard at intevation.de  Mon Apr 16 10:17:55 2018
From: bernhard at intevation.de (Bernhard Reiter)
Date: Mon, 16 Apr 2018 10:17:55 +0200
Subject: GnuPG 2.2 on elder Debian & Ubuntu distros
In-Reply-To: <20171027162445.GA17617@breadbox.private.spodhuis.org>
References: <201710271606.59244.bernhard@intevation.de>
 <20171027162445.GA17617@breadbox.private.spodhuis.org>
Message-ID: <201804161018.03695.bernhard@intevation.de>

Phil,

Am Freitag 27 Oktober 2017 18:24:45 schrieb Phil Pennock:
> Thus at <https://public-packages.pennock.tech/> I have packages

thanks again for those packages, I'll use them for test sometimes!

Just noticed that with Package: optgnupg-gnupg Version: 2.2.6-pt1
gpg and gpg-connect-agent somehow start the old gpg-agent.

My $PATH is
/opt/gnupg/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

pkill -5 gpg-agent
gpg --version | head -1
# gpg (GnuPG) 2.2.6
gpg-connect-agent --version | head -1
# gpg-connect-agent (GnuPG) 2.2.6
 echo "getinfo version" | gpg-connect-agent -v
D 2.1.18

should be 2.2.6.

Best Regards,
Bernhard
ps.: I've used the email address given in the package for testing. ;)

-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180416/cf84422d/attachment.sig>

From gnupg-devel at spodhuis.org  Mon Apr 16 18:28:48 2018
From: gnupg-devel at spodhuis.org (Phil Pennock)
Date: Mon, 16 Apr 2018 12:28:48 -0400
Subject: GnuPG 2.2 on elder Debian & Ubuntu distros
In-Reply-To: <201804161018.03695.bernhard@intevation.de>
References: <201710271606.59244.bernhard@intevation.de>
 <20171027162445.GA17617@breadbox.private.spodhuis.org>
 <201804161018.03695.bernhard@intevation.de>
Message-ID: <20180416162848.GA24051@tower.spodhuis.org>

On 2018-04-16 at 10:17 +0200, Bernhard Reiter wrote:
> Just noticed that with Package: optgnupg-gnupg Version: 2.2.6-pt1
> gpg and gpg-connect-agent somehow start the old gpg-agent.

Following up to list: systemd is configured to start specific instances
of gpg-agent.

Text added to <https://public-packages.pennock.tech/>:

  Users of systemd will have to weigh their options carefully, and
  consider editing /usr/lib/systemd/user/gpg-agent.service to change the
  paths to the binaries, then run systemctl daemon-reload and log out
  and back in again, otherwise gpg will launch the wrong gpg-agent.

-Phil


From dkg at fifthhorseman.net  Tue Apr 17 00:42:13 2018
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 16 Apr 2018 15:42:13 -0700
Subject: GnuPG 2.2 on elder Debian & Ubuntu distros
In-Reply-To: <20180416162848.GA24051@tower.spodhuis.org>
References: <201710271606.59244.bernhard@intevation.de>
 <20171027162445.GA17617@breadbox.private.spodhuis.org>
 <201804161018.03695.bernhard@intevation.de>
 <20180416162848.GA24051@tower.spodhuis.org>
Message-ID: <87a7u2rcxm.fsf@fifthhorseman.net>

On Mon 2018-04-16 12:28:48 -0400, Phil Pennock wrote:
> On 2018-04-16 at 10:17 +0200, Bernhard Reiter wrote:
>> Just noticed that with Package: optgnupg-gnupg Version: 2.2.6-pt1
>> gpg and gpg-connect-agent somehow start the old gpg-agent.
>
> Following up to list: systemd is configured to start specific instances
> of gpg-agent.
>
> Text added to <https://public-packages.pennock.tech/>:
>
>   Users of systemd will have to weigh their options carefully, and
>   consider editing /usr/lib/systemd/user/gpg-agent.service to change the
>   paths to the binaries, then run systemctl daemon-reload and log out
>   and back in again, otherwise gpg will launch the wrong gpg-agent.

please don't encourage anyone to edit /usr/lib/systemd/user/* by hand.
use the override mechanism as described in the "Example 2. Overriding
vendor settings" section in systemd.unit(5), or in the "edit" section of
systemctl(1).

        --dkg


From bernhard at intevation.de  Tue Apr 17 09:25:28 2018
From: bernhard at intevation.de (Bernhard Reiter)
Date: Tue, 17 Apr 2018 09:25:28 +0200
Subject: GnuPG 2.2 on elder Debian & Ubuntu distros
In-Reply-To: <87a7u2rcxm.fsf@fifthhorseman.net>
References: <201710271606.59244.bernhard@intevation.de>
 <20180416162848.GA24051@tower.spodhuis.org>
 <87a7u2rcxm.fsf@fifthhorseman.net>
Message-ID: <201804170925.32361.bernhard@intevation.de>

Am Dienstag 17 April 2018 00:42:13 schrieb Daniel Kahn Gillmor:
> On Mon 2018-04-16 12:28:48 -0400, Phil Pennock wrote:
> > Text added to <https://public-packages.pennock.tech/>:
> >
> >   Users of systemd will have to weigh their options carefully, and
> >   consider editing /usr/lib/systemd/user/gpg-agent.service to change the
> >   paths to the binaries, then run systemctl daemon-reload and log out
> >   and back in again, otherwise gpg will launch the wrong gpg-agent.

Phil,
thanks for analysis and improvement of instructions. Works here.

> please don't encourage anyone to edit /usr/lib/systemd/user/* by hand.
> use the override mechanism as described in the "Example 2. Overriding
> vendor settings" section in systemd.unit(5), or in the "edit" section of
> systemctl(1).

Daniel,
thanks for the pointer. Is there a way to override this systemd
setting as user? As least systemd starts something for a users and this user 
may want to have this changed. 

Otherwise someone who wants to run a different GnuPG will have to build their 
own packages and patch them to use a different socket under user control.
(This would be the solution for packages like Phil's I guess.)

And it seems to be a bug in the original Debian package 2.1.18-8~deb9u1 (as 
'--agent-program FILE' is not honored anymore (which stands in contrast to the 
documentation in info gnupg).

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180417/3ea4d01f/attachment.sig>

From gnupg-devel at spodhuis.org  Tue Apr 17 19:32:00 2018
From: gnupg-devel at spodhuis.org (Phil Pennock)
Date: Tue, 17 Apr 2018 13:32:00 -0400
Subject: GnuPG 2.2 on elder Debian & Ubuntu distros
In-Reply-To: <201804170925.32361.bernhard@intevation.de>
References: <201710271606.59244.bernhard@intevation.de>
 <20180416162848.GA24051@tower.spodhuis.org>
 <87a7u2rcxm.fsf@fifthhorseman.net>
 <201804170925.32361.bernhard@intevation.de>
Message-ID: <20180417173159.GA41394@tower.spodhuis.org>

On 2018-04-17 at 09:25 +0200, Bernhard Reiter wrote:
> Am Dienstag 17 April 2018 00:42:13 schrieb Daniel Kahn Gillmor:
> > please don't encourage anyone to edit /usr/lib/systemd/user/* by hand.
> > use the override mechanism as described in the "Example 2. Overriding
> > vendor settings" section in systemd.unit(5), or in the "edit" section of
> > systemctl(1).
> 
> Daniel,
> thanks for the pointer. Is there a way to override this systemd
> setting as user? As least systemd starts something for a users and this user 
> may want to have this changed.

Yes, that's exactly what is described in the documentation which Daniel
linked to.

> And it seems to be a bug in the original Debian package 2.1.18-8~deb9u1 (as 
> '--agent-program FILE' is not honored anymore (which stands in contrast to the 
> documentation in info gnupg).

It's more of a problem of the interaction between systemd socket
activation and GnuPG configuration: two things trying to achieve the
same ends, via different methods.  Handling this better would require
more extensive surgery of GnuPG and I don't think it's reasonable to
expect Daniel as the OS package maintainer, to do such work.  He's got
enough moving pieces to take care of already.

Daniel, I'm sorry, I didn't intend to create support burden for you by
making my own packages publicly available.  I do appreciate the
feedback: I should have remembered that systemd has overlay files etc.

Bernhard: the documentation on the website for my packages now has
correct information for safely overriding these settings, both for all
users and for one particular user.  I've tested both approaches on
Debian Stretch in a VM, they work for me.

-Phil


From gnupg-devel at spodhuis.org  Tue Apr 17 18:52:41 2018
From: gnupg-devel at spodhuis.org (Phil Pennock)
Date: Tue, 17 Apr 2018 12:52:41 -0400
Subject: GnuPG 2.2 on elder Debian & Ubuntu distros
In-Reply-To: <87a7u2rcxm.fsf@fifthhorseman.net>
References: <201710271606.59244.bernhard@intevation.de>
 <20171027162445.GA17617@breadbox.private.spodhuis.org>
 <201804161018.03695.bernhard@intevation.de>
 <20180416162848.GA24051@tower.spodhuis.org>
 <87a7u2rcxm.fsf@fifthhorseman.net>
Message-ID: <20180417165241.GA40752@tower.spodhuis.org>

On 2018-04-16 at 15:42 -0700, Daniel Kahn Gillmor wrote:
> please don't encourage anyone to edit /usr/lib/systemd/user/* by hand.
> use the override mechanism as described in the "Example 2. Overriding
> vendor settings" section in systemd.unit(5), or in the "edit" section of
> systemctl(1).

Noted.  Will review those sources and edit.

I'm primarily a FreeBSD user and strictly limit how much I go near
taking anything systemd away from upstream-maintained defaults.

Thanks,
-Phil


From bernhard at intevation.de  Tue Apr 17 21:04:26 2018
From: bernhard at intevation.de (Bernhard Reiter)
Date: Tue, 17 Apr 2018 21:04:26 +0200
Subject: GnuPG 2.2 on elder Debian & Ubuntu distros
In-Reply-To: <20180417173159.GA41394@tower.spodhuis.org>
References: <201710271606.59244.bernhard@intevation.de>
 <201804170925.32361.bernhard@intevation.de>
 <20180417173159.GA41394@tower.spodhuis.org>
Message-ID: <2218793.CxgWa6mB86@kymo.gruen>

Am Dienstag, 17. April 2018, 19:32:00 CEST schrieb Phil Pennock:
> > thanks for the pointer. Is there a way to override this systemd
> > setting as user?

> Yes, that's exactly what is described in the documentation which Daniel
> linked to.

I skimmed the sections he mentioned and 
had missed the part referring to the paths. 
 
> > And it seems to be a bug in the original Debian package 2.1.18-8~deb9u1
> > (as
> > '--agent-program FILE' is not honored anymore (which stands in contrast to
> > the documentation in info gnupg).
> 
> It's more of a problem of the interaction between systemd socket
> activation and GnuPG configuration: two things trying to achieve the
> same ends, via different methods. 

The defect is in the original package (indepentently to Phil's opt-gnupg). 
What advantage has starting via  systemd socket, as gpg also starts an agent, 
if necessary?

> Bernhard: the documentation on the website for my packages now has
> correct information for safely overriding these settings

I've tried configurating this for one user and it worked, thanks again.
Best,
Bernhard

-- 
www.intevation.de/~bernhard (CEO)    www.fsfe.org (Founding GA Member)
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180417/af964ab9/attachment.sig>

From wk at gnupg.org  Wed Apr 18 20:37:36 2018
From: wk at gnupg.org (Werner Koch)
Date: Wed, 18 Apr 2018 20:37:36 +0200
Subject: [Announce] GnuPG Made Easy (GPGME) 1.11.1 released
Message-ID: <87d0ywjr7z.fsf@wheatstone.g10code.de>

Hello!

We are pleased to announce version 1.11.0 of GPGME.

GnuPG Made Easy (GPGME) is a C language library that allows to add
support for cryptography to a program.  It is designed to make access to
public key crypto engines like gpg and gpgsm easier for applications.
GPGME provides a high-level crypto API for encryption, decryption,
signing, signature verification, and key management.  GPGME comes with
language bindings for Common Lisp, C++, QT, Python 2 and 3.

See https://gnupg.org/software/gpgme for more.


Noteworthy changes in version 1.11.0
====================================

 * New encryption API to support direct key specification including
   hidden recipients option and taking keys from a file.  This also
   allows to enforce the use of a subkey.

 * New encryption flag for the new API to enforce the use of plain
   mail addresses (addr-spec).

 * The import API can now tell whether v3 keys are skipped.  These old
   and basically broken keys are not anymore supported by GnuPG 2.1.

 * The decrypt and verify API will now return the MIME flag as
   specified by RFC-4880bis.

 * The offline mode now has an effect on gpg by disabling all network
   access.  [#3831]

 * A failed OpenPGP verification how returns the fingerprint of the
   intended key if a recent gpg version was used for signature
   creation.

 * New tool gpgme-json as native messaging server for web browsers.
   As of now public key encryption and decryption is supported.
   Requires Libgpg-error 1.29.

 * New context flag "request-origin" which has an effect when used
   with GnuPG 2.2.6 or later.

 * New context flag "no-symkey-cache" which has an effect when used
   with GnuPG 2.2.7 or later.

 * New convenience constant GPGME_KEYLIST_MODE_LOCATE.

 * Improved the Python documentation.

 * Fixed a potential regression with GnuPG 2.2.6 or later.

 * Fixed a crash in the Python bindings on 32 bit platforms.  [#3892]

 * Various minor fixes.


Download
========

You may download this library and its OpenPGP signature from:

  https://gnupg.org/ftp/gcrypt/gpgme/gpgme-1.11.0.tar.bz2 (1382k)
  https://gnupg.org/ftp/gcrypt/gpgme/gpgme-1.11.0.tar.bz2.sig

or from ftp.gnupg.org.  The SHA-1 checksum is

  17772bf86eef70ab0c77cbb6df0b90f002af0030  gpgme-1.11.0.tar.bz2

but you better check the integrity using the provided signature. See
<https://gnupg.org/download/integrity_check.html> for details.


Thanks
======

Maintenance and development of GnuPG is mostly financed by donations.
The GnuPG project currently employs one full-time developer and two
contractors.  Both work exclusivly on GnuPG and closely related software
like Libgcrypt, GPGME and GPA.

We have to thank all the people who helped the GnuPG project, be it
testing, coding, translating, suggesting, auditing, administering the
servers, spreading the word, answering questions on the mailing lists
and with financial support.


Happy hacking,

  Your GnuPG hackers



p.s.
This is an announcement only mailing list.  Please send replies only to
the gnupg-devel 'at' gnupg.org mailing list.

p.p.s 
List of Release Signing Keys:

To guarantee that a downloaded GnuPG version has not been tampered by
malicious entities we provide signature files for all tarballs and
binary versions.  The keys are also signed by the long term keys of
their respective owners.  Current releases are signed by one or more
of these four keys:

  rsa2048 2011-01-12 [expires: 2019-12-31]
  Key fingerprint = D869 2123 C406 5DEA 5E0F  3AB5 249B 39D2 4F25 E3B6
  Werner Koch (dist sig)

  rsa2048 2014-10-29 [expires: 2019-12-31]
  Key fingerprint = 46CC 7308 65BB 5C78 EBAB  ADCF 0437 6F3E E085 6959
  David Shaw (GnuPG Release Signing Key) <dshaw 'at' jabberwocky.com>

  rsa2048 2014-10-29 [expires: 2020-10-30]
  Key fingerprint = 031E C253 6E58 0D8E A286  A9F2 2071 B08A 33BD 3F06
  NIIBE Yutaka (GnuPG Release Key) <gniibe 'at' fsij.org>

  rsa3072 2017-03-17 [expires: 2027-03-15]
  Key fingerprint = 5B80 C575 4298 F0CB 55D8  ED6A BCEF 7E29 4B09 2E28
  Andre Heinecke (Release Signing Key)

The keys are available at <https://gnupg.org/signature_key.html> and
in any recently released GnuPG tarball in the file g10/distsigkey.gpg .
Note that this mail has been signed by a different key.

-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180418/8a174b60/attachment.sig>
-------------- next part --------------
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce

From alon.barlev at gmail.com  Wed Apr 18 22:12:03 2018
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Wed, 18 Apr 2018 23:12:03 +0300
Subject: [Announce] GnuPG Made Easy (GPGME) 1.11.1 released
In-Reply-To: <87d0ywjr7z.fsf@wheatstone.g10code.de>
References: <87d0ywjr7z.fsf@wheatstone.g10code.de>
Message-ID: <CAOazyz20yi8FqXcoFjr+KbjyTeGOJFFxw6LEffpM1RBMpguPFw@mail.gmail.com>

On Wed, Apr 18, 2018 at 9:37 PM, Werner Koch <wk at gnupg.org> wrote:
>
> Hello!
>
> We are pleased to announce version 1.11.0 of GPGME.
>

Thanks!

I get:
---
t-verify:130:sig-1: Unexpected fingerprint: F91C98F049D4204C
FAIL: t-verify
---

Any clue?


From alon.barlev at gmail.com  Wed Apr 18 22:55:56 2018
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Wed, 18 Apr 2018 23:55:56 +0300
Subject: [PATCH] build: gpgme-json: install properly
Message-ID: <20180418205556.16163-1-alon.barlev@gmail.com>

not installing properly using libtool result in:

 * QA Notice: The following files contain insecure RUNPATHs
 *  Please file a bug about this at https://bugs.gentoo.org/
 *  with the maintainer of the package.
 *   /var/tmp/portage/app-crypt/gpgme-1.11.0/image/usr/bin/gpgme-json
 *     RPATH: /var/tmp/portage/app-crypt/gpgme-1.11.0/work/b/src/.libs
---
 src/Makefile.am | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/src/Makefile.am b/src/Makefile.am
index c2d4a843..3d638b23 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -103,9 +103,7 @@ gpgme_tool_SOURCES = gpgme-tool.c argparse.c argparse.h
 gpgme_tool_LDADD = libgpgme.la @LIBASSUAN_LIBS@
 
 gpgme_json_SOURCES = gpgme-json.c cJSON.c cJSON.h
-gpgme_json_LDADD = -lm libgpgme.la $(GPG_ERROR_LIBS)
-# We use -no-install temporary during development.
-gpgme_json_LDFLAGS = -no-install
+gpgme_json_LDADD = -lm libgpgme.la @GPG_ERROR_LIBS@
 
 
 if HAVE_W32_SYSTEM
-- 
2.16.1



From alon.barlev at gmail.com  Wed Apr 18 22:58:06 2018
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Wed, 18 Apr 2018 23:58:06 +0300
Subject: [PATCH GPGME] build: gpgme-json: install properly
In-Reply-To: <20180418205556.16163-1-alon.barlev@gmail.com>
References: <20180418205556.16163-1-alon.barlev@gmail.com>
Message-ID: <20180418205806.16450-1-alon.barlev@gmail.com>

not installing properly using libtool result in:

 * QA Notice: The following files contain insecure RUNPATHs
 *  Please file a bug about this at https://bugs.gentoo.org/
 *  with the maintainer of the package.
 *   /var/tmp/portage/app-crypt/gpgme-1.11.0/image/usr/bin/gpgme-json
 *     RPATH: /var/tmp/portage/app-crypt/gpgme-1.11.0/work/b/src/.libs
---
 src/Makefile.am | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/src/Makefile.am b/src/Makefile.am
index c2d4a843..3d638b23 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -103,9 +103,7 @@ gpgme_tool_SOURCES = gpgme-tool.c argparse.c argparse.h
 gpgme_tool_LDADD = libgpgme.la @LIBASSUAN_LIBS@
 
 gpgme_json_SOURCES = gpgme-json.c cJSON.c cJSON.h
-gpgme_json_LDADD = -lm libgpgme.la $(GPG_ERROR_LIBS)
-# We use -no-install temporary during development.
-gpgme_json_LDFLAGS = -no-install
+gpgme_json_LDADD = -lm libgpgme.la @GPG_ERROR_LIBS@
 
 
 if HAVE_W32_SYSTEM
-- 
2.16.1



From sergi at calcurco.cat  Thu Apr 19 10:33:14 2018
From: sergi at calcurco.cat (=?UTF-8?Q?Sergi_Blanch-Torn=c3=a9?=)
Date: Thu, 19 Apr 2018 10:33:14 +0200
Subject: [Announce] GnuPG Made Easy (GPGME) 1.11.1 released
In-Reply-To: <87d0ywjr7z.fsf@wheatstone.g10code.de>
References: <87d0ywjr7z.fsf@wheatstone.g10code.de>
Message-ID: <4da6be6a-d4a0-84b4-a8ce-eb2939265ced@calcurco.cat>

Hi,

I didn't realise about newer releases of libgpg-error and I've first try
to compile gpgme with libgpg-error 1.27 with a compilation error.

The configure checks this library version but seems outdated:
> checking for GPG Error - version >= 1.24... yes (1.27)
Once updated to 1.29 it works. Also works with 1.28, but I've seen some
unused params warning for 'gpgme-json.c' that is not present later on 1.29.

The other dependency with libassuan, I was using 2.5.1 that, if I'm not
wrong is the last release.

I hope this helps.

/Sergi.

Ps: the compilation error
./.libs/libgpgme.so: undefined reference to `gpgrt_log_debug'
with some previous warning about an implicit declaration of this
function in 'decrypt.c' and 'verify.c'


On 04/18/18 20:37, Werner Koch wrote:
> Hello!
> 
> We are pleased to announce version 1.11.0 of GPGME.
> 
> GnuPG Made Easy (GPGME) is a C language library that allows to add
> support for cryptography to a program.  It is designed to make access to
> public key crypto engines like gpg and gpgsm easier for applications.
> GPGME provides a high-level crypto API for encryption, decryption,
> signing, signature verification, and key management.  GPGME comes with
> language bindings for Common Lisp, C++, QT, Python 2 and 3.
> 
> See https://gnupg.org/software/gpgme for more.
> 
> 
> Noteworthy changes in version 1.11.0
> ====================================
> 
>  * New encryption API to support direct key specification including
>    hidden recipients option and taking keys from a file.  This also
>    allows to enforce the use of a subkey.
> 
>  * New encryption flag for the new API to enforce the use of plain
>    mail addresses (addr-spec).
> 
>  * The import API can now tell whether v3 keys are skipped.  These old
>    and basically broken keys are not anymore supported by GnuPG 2.1.
> 
>  * The decrypt and verify API will now return the MIME flag as
>    specified by RFC-4880bis.
> 
>  * The offline mode now has an effect on gpg by disabling all network
>    access.  [#3831]
> 
>  * A failed OpenPGP verification how returns the fingerprint of the
>    intended key if a recent gpg version was used for signature
>    creation.
> 
>  * New tool gpgme-json as native messaging server for web browsers.
>    As of now public key encryption and decryption is supported.
>    Requires Libgpg-error 1.29.
> 
>  * New context flag "request-origin" which has an effect when used
>    with GnuPG 2.2.6 or later.
> 
>  * New context flag "no-symkey-cache" which has an effect when used
>    with GnuPG 2.2.7 or later.
> 
>  * New convenience constant GPGME_KEYLIST_MODE_LOCATE.
> 
>  * Improved the Python documentation.
> 
>  * Fixed a potential regression with GnuPG 2.2.6 or later.
> 
>  * Fixed a crash in the Python bindings on 32 bit platforms.  [#3892]
> 
>  * Various minor fixes.
> 
> 
> Download
> ========
> 
> You may download this library and its OpenPGP signature from:
> 
>   https://gnupg.org/ftp/gcrypt/gpgme/gpgme-1.11.0.tar.bz2 (1382k)
>   https://gnupg.org/ftp/gcrypt/gpgme/gpgme-1.11.0.tar.bz2.sig
> 
> or from ftp.gnupg.org.  The SHA-1 checksum is
> 
>   17772bf86eef70ab0c77cbb6df0b90f002af0030  gpgme-1.11.0.tar.bz2
> 
> but you better check the integrity using the provided signature. See
> <https://gnupg.org/download/integrity_check.html> for details.
> 
> 
> Thanks
> ======
> 
> Maintenance and development of GnuPG is mostly financed by donations.
> The GnuPG project currently employs one full-time developer and two
> contractors.  Both work exclusivly on GnuPG and closely related software
> like Libgcrypt, GPGME and GPA.
> 
> We have to thank all the people who helped the GnuPG project, be it
> testing, coding, translating, suggesting, auditing, administering the
> servers, spreading the word, answering questions on the mailing lists
> and with financial support.
> 
> 
> Happy hacking,
> 
>   Your GnuPG hackers
> 
> 
> 
> p.s.
> This is an announcement only mailing list.  Please send replies only to
> the gnupg-devel 'at' gnupg.org mailing list.
> 
> p.p.s 
> List of Release Signing Keys:
> 
> To guarantee that a downloaded GnuPG version has not been tampered by
> malicious entities we provide signature files for all tarballs and
> binary versions.  The keys are also signed by the long term keys of
> their respective owners.  Current releases are signed by one or more
> of these four keys:
> 
>   rsa2048 2011-01-12 [expires: 2019-12-31]
>   Key fingerprint = D869 2123 C406 5DEA 5E0F  3AB5 249B 39D2 4F25 E3B6
>   Werner Koch (dist sig)
> 
>   rsa2048 2014-10-29 [expires: 2019-12-31]
>   Key fingerprint = 46CC 7308 65BB 5C78 EBAB  ADCF 0437 6F3E E085 6959
>   David Shaw (GnuPG Release Signing Key) <dshaw 'at' jabberwocky.com>
> 
>   rsa2048 2014-10-29 [expires: 2020-10-30]
>   Key fingerprint = 031E C253 6E58 0D8E A286  A9F2 2071 B08A 33BD 3F06
>   NIIBE Yutaka (GnuPG Release Key) <gniibe 'at' fsij.org>
> 
>   rsa3072 2017-03-17 [expires: 2027-03-15]
>   Key fingerprint = 5B80 C575 4298 F0CB 55D8  ED6A BCEF 7E29 4B09 2E28
>   Andre Heinecke (Release Signing Key)
> 
> The keys are available at <https://gnupg.org/signature_key.html> and
> in any recently released GnuPG tarball in the file g10/distsigkey.gpg .
> Note that this mail has been signed by a different key.
> 
> 
> 
> _______________________________________________
> Gnupg-announce mailing list
> Gnupg-announce at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-announce
> 

-- 
Sergi Blanch-Torn?
C797 490A C93E DB00 0615  680A FC1C 1CB6 8079 85E6

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180419/a8a25a57/attachment.sig>

From astieger at suse.com  Thu Apr 19 12:25:04 2018
From: astieger at suse.com (Andreas Stieger)
Date: Thu, 19 Apr 2018 12:25:04 +0200
Subject: t-verify:130:sig-1: Unexpected fingerprint: F91C98F049D4204C
In-Reply-To: <CAOazyz20yi8FqXcoFjr+KbjyTeGOJFFxw6LEffpM1RBMpguPFw@mail.gmail.com>
References: <87d0ywjr7z.fsf@wheatstone.g10code.de>
 <CAOazyz20yi8FqXcoFjr+KbjyTeGOJFFxw6LEffpM1RBMpguPFw@mail.gmail.com>
Message-ID: <e122fa75-d47e-6ddb-248f-c78b63b7e026@suse.com>



On 04/18/2018 10:12 PM, Alon Bar-Lev wrote:
> ---
> t-verify:130:sig-1: Unexpected fingerprint: F91C98F049D4204C
> FAIL: t-verify
> ---

https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=commit;h=3d8e5c07511938a0b30b4626530822338abd9ec0

Andreas

-- 

Andreas Stieger <astieger at suse.com>
Project Manager Security
SUSE Linux GmbH, GF: Felix Imend?rffer, Jane Smithard, Graham Norton,
HRB 21284 (AG N?rnberg)



From wk at gnupg.org  Thu Apr 19 16:14:10 2018
From: wk at gnupg.org (Werner Koch)
Date: Thu, 19 Apr 2018 16:14:10 +0200
Subject: [Announce] GnuPG Made Easy (GPGME) 1.11.1 released
In-Reply-To: <4da6be6a-d4a0-84b4-a8ce-eb2939265ced@calcurco.cat> ("Sergi
 =?utf-8?Q?Blanch-Torn=C3=A9=22's?= message of "Thu, 19 Apr 2018 10:33:14
 +0200")
References: <87d0ywjr7z.fsf@wheatstone.g10code.de>
 <4da6be6a-d4a0-84b4-a8ce-eb2939265ced@calcurco.cat>
Message-ID: <874lk7i8r1.fsf@wheatstone.g10code.de>

On Thu, 19 Apr 2018 10:33, sergi at calcurco.cat said:

> ./.libs/libgpgme.so: undefined reference to `gpgrt_log_debug'
> with some previous warning about an implicit declaration of this

Sorry for this.  Testing agains several versions is not part of the
"make distcheck".  Would be not easy to implement anyway.  But:

commit b52a91f5a6818db6b3dd7ce86c01b5d5f6700d0d (HEAD -> refs/heads/wk-master)
Author: Werner Koch <wk at gnupg.org>
Date:   Thu Apr 19 10:34:32 2018 +0200

    core: Remove leftover debug output.
    
    * src/verify.c (_gpgme_verify_status_handler): Remove debug output.
    --
    
    Actually this is a real bug because it uses a debug function available
    only in the new libgpg-error versions.  Time to call Jenkins back from
    vacation; there are rumors that he has been seen in the city looking
    for a new Ryzen tail coat.
    
I guess a new release needs to be done tomorrow or so.



Shalom-Salam,

   Werner

-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180419/f7180a13/attachment.sig>

From wk at gnupg.org  Thu Apr 19 16:16:59 2018
From: wk at gnupg.org (Werner Koch)
Date: Thu, 19 Apr 2018 16:16:59 +0200
Subject: [PATCH] build: gpgme-json: install properly
In-Reply-To: <20180418205556.16163-1-alon.barlev@gmail.com> (Alon Bar-Lev's
 message of "Wed, 18 Apr 2018 23:55:56 +0300")
References: <20180418205556.16163-1-alon.barlev@gmail.com>
Message-ID: <87zi1zgu1w.fsf@wheatstone.g10code.de>

On Wed, 18 Apr 2018 22:55, alon.barlev at gmail.com said:

> -# We use -no-install temporary during development.
> -gpgme_json_LDFLAGS = -no-install
> +gpgme_json_LDADD = -lm libgpgme.la @GPG_ERROR_LIBS@

Thanks. Yet another reason to let a 1.11.1 follow sooninsh.  Maybe I
should stop hacking while being hampered by hay fever.

Thanks.


Salam-Shalom,

   Werner

-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180419/eab774df/attachment.sig>

From dkg at fifthhorseman.net  Thu Apr 19 20:42:44 2018
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 19 Apr 2018 11:42:44 -0700
Subject: [RFC v2 0/5] TPM support for gpg
In-Reply-To: <1520866873.4522.7.camel@HansenPartnership.com>
References: <1520277125.5312.35.camel@HansenPartnership.com>
 <87muzggmsf.fsf@wheatstone.g10code.de>
 <1520722200.4495.27.camel@HansenPartnership.com>
 <87a7vdhbph.fsf@wheatstone.g10code.de>
 <1520866873.4522.7.camel@HansenPartnership.com>
Message-ID: <87o9ifqbq3.fsf@fifthhorseman.net>

On Mon 2018-03-12 08:01:13 -0700, James Bottomley wrote:
> I had a brief look at what it would take, and it looks simple enough
> except that there's a lot of daemon code in call-scd.c that should be
> reused, so it looks like the project would have two stages:?
>
>    1. Separate generic daemon code out of call-scd for reuse
>    2. build the tpm handling daemon based on the generic code
>
> I'm guessing you'll have strong opinions on the framework in 1. ...

what's the status of this work?  how close are we to getting TPM support
in some version of GnuPG?

   --dkg


From wk at gnupg.org  Fri Apr 20 11:02:20 2018
From: wk at gnupg.org (Werner Koch)
Date: Fri, 20 Apr 2018 11:02:20 +0200
Subject: [Announce] GnuPG Made Easy (GPGME) 1.11.1 released
References: <87d0ywjr7z.fsf@wheatstone.g10code.de>
Message-ID: <877ep2gqw7.fsf@wheatstone.g10code.de>

Hello!

The GPGME 1.11.0 release we did on Wednesday had a number of problems
when not build against the latest support libraries.  Thus we release
GPGME 1.11.1 to fix them.

GnuPG Made Easy (GPGME) is a C language library that allows to add
support for cryptography to a program.  It is designed to make access to
public key crypto engines like gpg and gpgsm easier for applications.
GPGME provides a high-level crypto API for encryption, decryption,
signing, signature verification, and key management.  GPGME comes with
language bindings for Common Lisp, C++, QT, Python 2 and 3.

See https://gnupg.org/software/gpgme for more.


Noteworthy changes in version 1.11.1
====================================

 * Fixed build problems in the 1.11.0 release.

 * Added C++ interfaces which were planned for 1.11.0.

 The 1.11.0 release came with these changes:

 * New encryption API to support direct key specification including
   hidden recipients option and taking keys from a file.  This also
   allows to enforce the use of a subkey.

 * New encryption flag for the new API to enforce the use of plain
   mail addresses (addr-spec).

 * The import API can now tell whether v3 keys are skipped.  These old
   and basically broken keys are not anymore supported by GnuPG 2.1.

 * The decrypt and verify API will now return the MIME flag as
   specified by RFC-4880bis.

 * The offline mode now has an effect on gpg by disabling all network
   access.  [#3831]

 * A failed OpenPGP verification how returns the fingerprint of the
   intended key if a recent gpg version was used for signature
   creation.

 * New tool gpgme-json as native messaging server for web browsers.
   As of now public key encryption and decryption is supported.
   Requires Libgpg-error 1.29.

 * New context flag "request-origin" which has an effect when used
   with GnuPG 2.2.6 or later.

 * New context flag "no-symkey-cache" which has an effect when used
   with GnuPG 2.2.7 or later.

 * New convenience constant GPGME_KEYLIST_MODE_LOCATE.

 * Improved the Python documentation.

 * Fixed a potential regression with GnuPG 2.2.6 or later.

 * Fixed a crash in the Python bindings on 32 bit platforms.  [#3892]

 * Various minor fixes.


Download
========

You may download this library and its OpenPGP signature from:

  https://gnupg.org/ftp/gcrypt/gpgme/gpgme-1.11.1.tar.bz2 (1385k)
  https://gnupg.org/ftp/gcrypt/gpgme/gpgme-1.11.1.tar.bz2.sig

or from ftp.gnupg.org.  The SHA-1 checksum is

95b1fc427871ca8d30d6d3b1985c816fe0b5077b  gpgme-1.11.1.tar.bz2

but you better check the integrity using the provided signature. See
<https://gnupg.org/download/integrity_check.html> for details.


Thanks
======

Maintenance and development of GnuPG is mostly financed by donations.
The GnuPG project currently employs one full-time developer and two
contractors.  Both work exclusivly on GnuPG and closely related software
like Libgcrypt, GPGME and GPA.

We have to thank all the people who helped the GnuPG project, be it
testing, coding, translating, suggesting, auditing, administering the
servers, spreading the word, answering questions on the mailing lists
and with financial support.


Happy hacking,

  Your GnuPG hackers



p.s.
This is an announcement only mailing list.  Please send replies only to
the gnupg-devel 'at' gnupg.org mailing list.

p.p.s 
List of Release Signing Keys:

To guarantee that a downloaded GnuPG version has not been tampered by
malicious entities we provide signature files for all tarballs and
binary versions.  The keys are also signed by the long term keys of
their respective owners.  Current releases are signed by one or more
of these four keys:

  rsa2048 2011-01-12 [expires: 2019-12-31]
  Key fingerprint = D869 2123 C406 5DEA 5E0F  3AB5 249B 39D2 4F25 E3B6
  Werner Koch (dist sig)

  rsa2048 2014-10-29 [expires: 2019-12-31]
  Key fingerprint = 46CC 7308 65BB 5C78 EBAB  ADCF 0437 6F3E E085 6959
  David Shaw (GnuPG Release Signing Key) <dshaw 'at' jabberwocky.com>

  rsa2048 2014-10-29 [expires: 2020-10-30]
  Key fingerprint = 031E C253 6E58 0D8E A286  A9F2 2071 B08A 33BD 3F06
  NIIBE Yutaka (GnuPG Release Key) <gniibe 'at' fsij.org>

  rsa3072 2017-03-17 [expires: 2027-03-15]
  Key fingerprint = 5B80 C575 4298 F0CB 55D8  ED6A BCEF 7E29 4B09 2E28
  Andre Heinecke (Release Signing Key)

The keys are available at <https://gnupg.org/signature_key.html> and
in any recently released GnuPG tarball in the file g10/distsigkey.gpg .
Note that this mail has been signed by a different key.

-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180420/b1bf1bb5/attachment.sig>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180420/b1bf1bb5/attachment-0001.sig>
-------------- next part --------------
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce

From bernhard at intevation.de  Wed Apr 25 08:49:54 2018
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 25 Apr 2018 08:49:54 +0200
Subject: WKD vs VV and VVV
Message-ID: <201804250849.59378.bernhard@intevation.de>

Since 2-3 years there is a struggle about distributing public keys
to enable a better user experience with end-to-end crypto.

As you may know, https://wiki.gnupg.org/WKD
is the approach that g10code and Intevation have chosen May 2016
and which is fully implemented in GnuPG 2.2.

I've briefly looked at two other initiatives in Germany, which basically ran 
in parallel or a little later than the contract that resulted in WKD.

Best Regards,
Bernhard

== Details

  https://www.keys4all.de/aktuelles.php
  https://www.keys4all.de/gi-2017.php

link to a number of papers describing the approaches and results
of https://volksverschluesselung.de/ (VV)
and Vertrauensw?rdige Verteilung von Verschl?sselungsschl?sseln (VVV).
All in German.

* [VV] is a central distribution of pubkeys and wants to strongly associate
  pubkey to person, thus does not have anonymity on its goals.

* VVV papers criticise that a DNS record per email-address
  would not scale with DNS.
  That aligns with one of our arguments against using DNS.

* VVV uses DNS SRV records to point to a special HKP server
  for each email provider. [BVVV] put forth arguments against WKD/WKS,
  remarks to some:
  ** inconsistency because pubkey management via policy file HTTPS and later
     SMTP but lookup with HTTPS
     They did not comment on the rationale that this management
     way may possibly be more easily implemented with email clients and fit
     an asynchronus email workflow better.

  ** No revoke, no requirements for keys like length, 
     no anti-brute-force-strategy specified.
     Comment: WKD was aimed for being a "lean" spec, where the main problem
     is solved first, and less important ones refined later with more
     experience in the wild. I'm not sure what they would want the
     "anti-brute-force-strategy" for as WKD is not "walkable" and you need to
     know the email-address before you request a pubkey.

  ** no distribution of old pubkeys for old signatures.
     This may be a valid use case once the main use cases are solved.

  ** Email provider needs "full control" about the webserver of the same 
     domain. 
     We point out this problem as well, though WKD does not need "full" access
     as an internal proxing or a https redirect also works. (Right now this is
     a point of discussion about evolving WKD as v05 offers DNS SRV records
     that some clients cannot easily implement. My personal stand is to use 
     HTTPS and one of the redirection methods if necessary until this is
     a broader consensus.)

  ** No definition of how the HTTPS service is secured.
     For larger email providers, they have a valid interest to keep their
     domain secured, so that is not worth mentioning. But for people with
     their own webside or smaller prodivers without weblogin on the email
     domain this could be an addition to WKD to give some hints about how to
     secure the main domain.

  ** Because no authentication is needed when submitting a pubkey via SMTP,
     it shall be possible to use this management servive as
     email-address-dossier.
     This is something I don't understand as WKD is not walkable.

* The VVV procedure requires DNS records, and thus cannot be implemented by
  modern Webbrowser Javascript in the page or an extension. It would need
  an external helper, either on the operating system side with native
  messaging or on the server. This is an implementation drawback.
  Anotherone is that many folks do not have access or are very conservative
  about their DNS records. And that use DNSSEC cannot be reliable checked
  from a client.
  Those implementation difficulties lead us to using HTTPS for the lookup
  in WKD.

* A legal paper [R] makes a point that a service handing out public keys 
  with some metadata like the name is like a phone book service and thus
  would be subject to data privacy directives that would require the
  user to be informed and thoroughly asked before publishing something.
  Of course this goes against the goal of doing encryption mostly in the 
  background and it a major hurdle for designing a good user experience
  for VVV.

  The WKD style of only allowing the email address to be present as metadata
  in the pubkey has the advantage that (in my very limited legal
  understanding) it is not a personal data record in a phone book like
  service, as you already have to know the email address before you can
  ask a WKD service of the provider for the pubkey. So there is no 
  "publication" of personal data going on and if really necessary
  email providers could put a remark in their terms of service.
  Overall WKD should allow to implement a better user experience in the
  setup phase.

* I haven't easily found source code for the prototype implementation
  of [VVV] on the webpage. GnuPG 2.2 is out there, KMail, Enigmail, GpgOL
  implement a good part of WKD with still more user experience work on
  the way.


  
== Literature
   
[BVVV] Beschreibung der VVV-L?sung
Peter Fischer, Ulrich Waldmann, Jan 2017
https://www.keys4all.de/media/beschreibung-vvv-loesung.pdf

[R] Rechtliche Problemstellungen der Ende-zu-Ende-Verschl?sselung: 
Anforderungen des k?nftigen europ?ischen Datenschutzrechts an die 
vertrauensw?rdige Verteilung von Verschl?sselungsschl?sseln
Stephan Blazy, Susan Gonscherowski, Annika Selzer, Sept 2017

[VVV] Verfahren zur vertrauensw?rdigen Verteilung von 
Verschl?sselungsschl?sseln
Peter Fischer, Thomas Kunz, Katharina Lorenz, Ulrich Waldmann, July 2017 
https://www.keys4all.de/media/Fischer-et-al.pdf

[VV] Die Volksverschl?sselung: F?rderung vertrauensw?rdiger 
Ende-zu-Ende-Verschl?sselung durch benutzerfreundliches Schl?ssel- und 
Zertifikatsmanagement
Dominik Spychalski, Levona Eckstein, Michael Herfert, Daniel Trick, Tatjana 
Rubinstein, Jun 2017
https://www.keys4all.de/media/Spychalski-et-al.pdf


-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180425/1dc46efa/attachment.sig>

From look at my.amazin.horse  Wed Apr 25 13:17:16 2018
From: look at my.amazin.horse (Vincent Breitmoser)
Date: Wed, 25 Apr 2018 13:17:16 +0200
Subject: WKD vs VV and VVV
In-Reply-To: <201804250849.59378.bernhard@intevation.de>
References: <201804250849.59378.bernhard@intevation.de>
Message-ID: <20180425111716.6d2ttzeqjjdjci7s@calamity>

> as WKD is not "walkable"

E-Mail addresses are fairly walkable. If you consider a namespace like gmail,
you'd likely be able to find a lot of valid addresses (and their keys) with
a simple dictionary attack that combines names and numbers in the typical ways
they are used in email addresses. This has been discussed to death in the DANE
IETF working group, iirc, though I don't remember what the takeaway was.

> https://www.keys4all.de/media/Spychalski-et-al.pdf

Moneyquote: "Dennoch verschlusseln nach einer Umfrage des Digitalverbandes
BITKOM nur etwa 15% der Nutzer in Deutschland ihre E-Mails". (Roughly: A BITKOM
survey found that only 15% of users in Germany encrypt their E-Mails).

 - V

PS: I would like to point out to the international audience that even for German
speakers, both "Volksverschl?sselung" and "Verfahren zur Verteilung von
Verschl?sselungsschl?sseln" sound a little funny.


From bernhard at intevation.de  Wed Apr 25 13:36:46 2018
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 25 Apr 2018 13:36:46 +0200
Subject: WKD vs VV and VVV
In-Reply-To: <20180425111716.6d2ttzeqjjdjci7s@calamity>
References: <201804250849.59378.bernhard@intevation.de>
 <20180425111716.6d2ttzeqjjdjci7s@calamity>
Message-ID: <201804251336.50083.bernhard@intevation.de>

Am Mittwoch 25 April 2018 13:17:16 schrieb Vincent Breitmoser:
> > as WKD is not "walkable"
>
> E-Mail addresses are fairly walkable. If you consider a namespace like
> gmail, you'd likely be able to find a lot of valid addresses (and their
> keys) with a simple dictionary attack that combines names and numbers in
> the typical ways they are used in email addresses. 

I agree, of course. You can try the email provider's SMTP by use of a 
distributed bot-net for each address and you'd certainly find all of them 
with overseeable effort.

In more detail, my point is that WKD is not by concept "walkable" like a phone 
book or and it is not brute-forceable like a list of hashes on disk.
There are tactics defending against trying all email addresses via wkd, e.g. 
you could deliver fake pubkeys for each email-address, block pattern requests 
from certain network AS or just delay online requests. In the end this is 
nothing a well-funded and equipped attacker couldn't overcome, but still it 
raises the costs a little bit which I believe is important to many. 
(Otherwise it wouldn't be listed in a number of security goals declarations.)

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180425/ff1bf4b2/attachment.sig>

From wk at gnupg.org  Wed Apr 25 17:41:52 2018
From: wk at gnupg.org (Werner Koch)
Date: Wed, 25 Apr 2018 17:41:52 +0200
Subject: WKD vs VV and VVV
In-Reply-To: <201804250849.59378.bernhard@intevation.de> (Bernhard Reiter's
 message of "Wed, 25 Apr 2018 08:49:54 +0200")
References: <201804250849.59378.bernhard@intevation.de>
Message-ID: <87d0yncmyn.fsf@wheatstone.g10code.de>

On Wed, 25 Apr 2018 08:49, bernhard at intevation.de said:

>   ** no distribution of old pubkeys for old signatures.
>      This may be a valid use case once the main use cases are solved.

That is why we suggest to also upload keys to a keyserver.  Signatures
carry the full fingerprint and thus the key can easily be retrieved from
any keyserver.  The Web Key Directory is mainly for the _initial_ key
discovery.

>   ** Because no authentication is needed when submitting a pubkey via SMTP,
>      it shall be possible to use this management servive as
>      email-address-dossier.
>      This is something I don't understand as WKD is not walkable.

Wrong.  The mail provider sends the mail back to the legitimate owner of
the address and not to the sender.  That is the whole point of all mail
verification systems.


Shalom-Salam,

   Werner

-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180425/4c90ad91/attachment-0001.sig>

From bernhard at intevation.de  Thu Apr 26 09:05:55 2018
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 26 Apr 2018 09:05:55 +0200
Subject: WKD vs VV and VVV
In-Reply-To: <87d0yncmyn.fsf@wheatstone.g10code.de>
References: <201804250849.59378.bernhard@intevation.de>
 <87d0yncmyn.fsf@wheatstone.g10code.de>
Message-ID: <201804260905.55683.bernhard@intevation.de>

Am Mittwoch 25 April 2018 17:41:52 schrieb Werner Koch:
> On Wed, 25 Apr 2018 08:49, bernhard at intevation.de said:
> >   ** no distribution of old pubkeys for old signatures.
> >      This may be a valid use case once the main use cases are solved.
>
> That is why we suggest to also upload keys to a keyserver.  Signatures
> carry the full fingerprint and thus the key can easily be retrieved from
> any keyserver.  The Web Key Directory is mainly for the _initial_ key
> discovery.

It seems that many people see value in the security goal of not publishing 
their email address to something like an open public keyserver.
I guess your position is that this has no value. From my point of view it has 
some value, though just a little bit. Thus is why I think ideally there 
should not be a default upload to public keyserver if we have WKD from the 
email provider. We should be able to get by without it. Anyways, this is not 
the major use case to solve, as you correctly point out.

> >   ** Because no authentication is needed when submitting a pubkey via
> > SMTP, it shall be possible to use this management servive as
> >      email-address-dossier.
> >      This is something I don't understand as WKD is not walkable.
>
> Wrong.  The mail provider sends the mail back to the legitimate owner of
> the address and not to the sender.  That is the whole point of all mail
> verification systems.

Yes, this is why I did not understand the point given in their description.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180426/53283dc5/attachment.sig>