From trevor at yubico.com  Tue Mar 12 14:50:08 2019
From: trevor at yubico.com (Trevor Bentley)
Date: Tue, 12 Mar 2019 14:50:08 +0100
Subject: Fingerprint mismatch for 384-bit ECDH keys generated on SmartCards
Message-ID: <11c33e8f-f11d-3903-4637-d0233532b17f@yubico.com>

Hi,

I discovered that GnuPG generates two mismatched fingerprints when 
generating 384-bit ECDH keys on SmartCards.  This applies to both 
secp384 and brainpool384 decryption keys (stored in slot 1).

When the key is generated, two fingerprints are created via different 
code paths.  One is stored in the fingerprint slot on the smartcard, and 
one is stored in the local keyring and in exported keys.

For ECDH keys, the last field hashed in the fingerprint is the "ECDH 
params", of which the last byte is the KEK algorithm identifier.  This 
is hardcoded in scd/app-openpgp.c:ecdh_params() to 0x08, and hardcoded 
in g10/ecdh.c:kek_params_table[] to 0x09.  The mismatched byte obviously 
results in a different SHA1 hash.

GnuPG itself appears to ignore the mismatch, and everything works as 
expected.  But OpenKeychain, the Android app, verifies that the 
fingerprints match when importing a key for a smartcard.  This obviously 
fails, and only for 384-bit ECDH keys.  It refuses to import the 
decryption subkey, so the user is unable to decrypt messages with their 
smartcard.

Since secp384 is one of the only two curves offered when generating a 
key without the `--expert` flag, this could be quite problematic for 
OpenKeychain users.

I would assume that the definition in ecdh.c should have been 
CIPHER_ALGO_AES192...  I did verify that changing it fixes the mismatch 
and allows importing into OpenKeychain.  But maybe changing it now 
breaks all existing keys?

Thanks,

-Trevor


From gniibe at fsij.org  Wed Mar 13 01:27:27 2019
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 13 Mar 2019 09:27:27 +0900
Subject: Fingerprint mismatch for 384-bit ECDH keys generated on SmartCards
In-Reply-To: <11c33e8f-f11d-3903-4637-d0233532b17f@yubico.com>
References: <11c33e8f-f11d-3903-4637-d0233532b17f@yubico.com>
Message-ID: <871s3bwrdc.fsf@iwagami.gniibe.org>

Trevor Bentley via Gnupg-devel <gnupg-devel at gnupg.org> wrote:
> I would assume that the definition in ecdh.c should have been 
> CIPHER_ALGO_AES192...

I agree.

In the Section 13 of RFC-6637, an implementation SHOULD use symmetric
key size 192 for ECC strength of 384.  It also says that (a stronger
hash algorithm or) a stronger symmetric key algorithm MAY be used, so,
use of CIPHER_ALGO_AES256 was not 100% wrong, and is considered OK (if
it matches the behavior on smartcard).

I fixed ecdh.c for master.

> I did verify that changing it fixes the mismatch and allows importing
> into OpenKeychain.  But maybe changing it now breaks all existing
> keys?

IIUC, kek_params_table is only used for key generation.  How does the
change break existing keys?  I wonder.
-- 


From wk at gnupg.org  Wed Mar 13 12:35:37 2019
From: wk at gnupg.org (Werner Koch)
Date: Wed, 13 Mar 2019 12:35:37 +0100
Subject: Fingerprint mismatch for 384-bit ECDH keys generated on SmartCards
In-Reply-To: <871s3bwrdc.fsf@iwagami.gniibe.org> (NIIBE Yutaka's message of
 "Wed, 13 Mar 2019 09:27:27 +0900")
References: <11c33e8f-f11d-3903-4637-d0233532b17f@yubico.com>
 <871s3bwrdc.fsf@iwagami.gniibe.org>
Message-ID: <87wol3ypkm.fsf@wheatstone.g10code.de>

On Wed, 13 Mar 2019 09:27, gniibe at fsij.org said:

> use of CIPHER_ALGO_AES256 was not 100% wrong, and is considered OK (if
> it matches the behavior on smartcard).

It is actually done on purpose to limit the set of required algorithms.
AES-192 has no real purpose and thus it should be avoided.

I would prefer to change this in app-openpgp.c instead.  In any case we
should use a shared code for the OpenPGP fingerprint computation.  I am
currently working on v5 keys and this will require more changes anyway.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- 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/20190313/769ec5c8/attachment.sig>

From dashohoxha at gmail.com  Sun Mar 17 18:13:32 2019
From: dashohoxha at gmail.com (Dashamir Hoxha)
Date: Sun, 17 Mar 2019 18:13:32 +0100
Subject: GSoC project idea
Message-ID: <CAMucfLw0y1JGcJhV8o-Da0-GAegfUCb4x1YM9cdLbTnTKJ7YgA@mail.gmail.com>

Hi,

Last year we discussed a request/proposal for improving the command line UI
of gnupg:
https://lists.gnupg.org/pipermail/gnupg-devel/2018-July/033857.html

We decided that making radical changes to the current UI of gnupg is a huge
task, risky, unfeasible, and in general not worth the trouble.

However I came up with a proposal for writing just a wrapper to the current
gpg command, that organizes the commands and options in a different way,
presumably more easy and intuitive. This wrapper will not affect in no way
the gpg command itself, it will be just like "syntactic sugar", and in the
end it will call the gpg command itself, with the proper arguments and
options.

This wrapper can be written in Bash, Python, Go, etc. It should be very
easy to develop such a wrapper, assuming that we already know all the
details about the commands and options of gnupg, and we have a clear idea
about the new system of commands and options that we want to build. This
new system of commands and options doesn't have to cover 100% of the
functionality of the gpg command; for the few things that may remain
unimplemented the user may use the gpg command directly.

I think this is suitable task for a GSoC project that can be developed in
2-3 months by a good student, with help and guidance from mentors. It can
be submitted to GNU, which acts as an ombrella organization on GSoC for all
the gnu projects:
https://www.gnu.org/software/soc-projects/ideas-2019.html
I think it is worth a try, there is nothing to risk or to loose.

Anybody interested or willing to be a mentor for this project? I might be a
mentor as well, if needed, since I do have some mentoring experience from
the last year GSoC.

Regards,
Dashamir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190317/fe7b1c2f/attachment.html>

From dashohoxha at gmail.com  Sun Mar 17 18:15:09 2019
From: dashohoxha at gmail.com (Dashamir Hoxha)
Date: Sun, 17 Mar 2019 18:15:09 +0100
Subject: GSoC project idea
In-Reply-To: <CAMucfLw0y1JGcJhV8o-Da0-GAegfUCb4x1YM9cdLbTnTKJ7YgA@mail.gmail.com>
References: <CAMucfLw0y1JGcJhV8o-Da0-GAegfUCb4x1YM9cdLbTnTKJ7YgA@mail.gmail.com>
Message-ID: <CAMucfLxpSjpETgWUBQnE_wZ214wrVAwovBqYM9r+JyU7rQ1GhA@mail.gmail.com>

Sorry, the proper link to the archived message is this one:
https://lists.gnupg.org/pipermail/gnupg-devel/2018-July/033854.html

On Sun, Mar 17, 2019 at 6:13 PM Dashamir Hoxha <dashohoxha at gmail.com> wrote:

> Hi,
>
> Last year we discussed a request/proposal for improving the command line
> UI of gnupg:
> https://lists.gnupg.org/pipermail/gnupg-devel/2018-July/033857.html
>
> We decided that making radical changes to the current UI of gnupg is a
> huge task, risky, unfeasible, and in general not worth the trouble.
>
> However I came up with a proposal for writing just a wrapper to the
> current gpg command, that organizes the commands and options in a different
> way, presumably more easy and intuitive. This wrapper will not affect in no
> way the gpg command itself, it will be just like "syntactic sugar", and in
> the end it will call the gpg command itself, with the proper arguments and
> options.
>
> This wrapper can be written in Bash, Python, Go, etc. It should be very
> easy to develop such a wrapper, assuming that we already know all the
> details about the commands and options of gnupg, and we have a clear idea
> about the new system of commands and options that we want to build. This
> new system of commands and options doesn't have to cover 100% of the
> functionality of the gpg command; for the few things that may remain
> unimplemented the user may use the gpg command directly.
>
> I think this is suitable task for a GSoC project that can be developed in
> 2-3 months by a good student, with help and guidance from mentors. It can
> be submitted to GNU, which acts as an ombrella organization on GSoC for all
> the gnu projects:
> https://www.gnu.org/software/soc-projects/ideas-2019.html
> I think it is worth a try, there is nothing to risk or to loose.
>
> Anybody interested or willing to be a mentor for this project? I might be
> a mentor as well, if needed, since I do have some mentoring experience from
> the last year GSoC.
>
> Regards,
> Dashamir
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190317/2e7affca/attachment.html>

From dashohoxha at gmail.com  Mon Mar 18 13:31:23 2019
From: dashohoxha at gmail.com (Dashamir Hoxha)
Date: Mon, 18 Mar 2019 13:31:23 +0100
Subject: GSoC project idea
In-Reply-To: <20190318112127.fyxhwpbkx2vkbtcn@NUC.doronbehar.com>
References: <CAMucfLw0y1JGcJhV8o-Da0-GAegfUCb4x1YM9cdLbTnTKJ7YgA@mail.gmail.com>
 <20190318112127.fyxhwpbkx2vkbtcn@NUC.doronbehar.com>
Message-ID: <CAMucfLxkeDh70JV7WKuV27OqchakNjZqKtu0yqLsu6O2tWyWhA@mail.gmail.com>

On Mon, Mar 18, 2019 at 12:21 PM Doron Behar <doron.behar at gmail.com> wrote:

> Hello Dashamir,
>
> Thanks for showing your interest in this idea. I thought more about it
> after I've sent the email to the mailing list and I reached the
> conclusion that it might be more efficient to _fork_ the existing
> code-base and use the same existing functions and only bind them to a
> different executable that will have a different use of argparse.
>

Do you preserve the existing commands and options of `gpg`, for backwards
compatibility? If yes, maybe there is some chance that your changes will be
merged some day to the main project. Otherwise I think that it is going
nowhere. Neither the developers nor the users will accept radical changes
to the CLI of `gpg`. I don't think your aim is to maintain it forever as an
alternative to `gpg` because this is a huge task.


> Actually, I've already created a prototype of this and the missing work
> to be done is connecting everything to the already existing functions
> available in the code-base.
>

It does not seem so easy to me because you may need some feedback from more
experienced people, although you may think that you have organized the
commands and their options properly.


>
> It is indeed a good project for a student. Only I'm not sure I'll be
> able to do it myself, although my motivation is rather high. I'm
> preparing myself for the 1st year of Computer Science studies in
> university these days so I don't have a lot of spare time.
>

You can be one of the mentors, which hopefully should not be very time
consuming.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190318/dc148844/attachment.html>

From doron.behar at gmail.com  Mon Mar 18 12:21:27 2019
From: doron.behar at gmail.com (Doron Behar)
Date: Mon, 18 Mar 2019 13:21:27 +0200
Subject: GSoC project idea
In-Reply-To: <CAMucfLw0y1JGcJhV8o-Da0-GAegfUCb4x1YM9cdLbTnTKJ7YgA@mail.gmail.com>
References: <CAMucfLw0y1JGcJhV8o-Da0-GAegfUCb4x1YM9cdLbTnTKJ7YgA@mail.gmail.com>
Message-ID: <20190318112127.fyxhwpbkx2vkbtcn@NUC.doronbehar.com>

Hello Dashamir,

Thanks for showing your interest in this idea. I thought more about it
after I've sent the email to the mailing list and I reached the
conclusion that it might be more efficient to _fork_ the existing
code-base and use the same existing functions and only bind them to a
different executable that will have a different use of argparse.
Actually, I've already created a prototype of this and the missing work
to be done is connecting everything to the already existing functions
available in the code-base.

It is indeed a good project for a student. Only I'm not sure I'll be
able to do it myself, although my motivation is rather high. I'm
preparing myself for the 1st year of Computer Science studies in
university these days so I don't have a lot of spare time.

On Sun, Mar 17, 2019 at 06:13:32PM +0100, Dashamir Hoxha wrote:
> Hi,
> 
> Last year we discussed a request/proposal for improving the command line UI
> of gnupg:
> https://lists.gnupg.org/pipermail/gnupg-devel/2018-July/033857.html
> 
> We decided that making radical changes to the current UI of gnupg is a huge
> task, risky, unfeasible, and in general not worth the trouble.
> 
> However I came up with a proposal for writing just a wrapper to the current
> gpg command, that organizes the commands and options in a different way,
> presumably more easy and intuitive. This wrapper will not affect in no way
> the gpg command itself, it will be just like "syntactic sugar", and in the
> end it will call the gpg command itself, with the proper arguments and
> options.
> 
> This wrapper can be written in Bash, Python, Go, etc. It should be very
> easy to develop such a wrapper, assuming that we already know all the
> details about the commands and options of gnupg, and we have a clear idea
> about the new system of commands and options that we want to build. This
> new system of commands and options doesn't have to cover 100% of the
> functionality of the gpg command; for the few things that may remain
> unimplemented the user may use the gpg command directly.
> 
> I think this is suitable task for a GSoC project that can be developed in
> 2-3 months by a good student, with help and guidance from mentors. It can
> be submitted to GNU, which acts as an ombrella organization on GSoC for all
> the gnu projects:
> https://www.gnu.org/software/soc-projects/ideas-2019.html
> I think it is worth a try, there is nothing to risk or to loose.
> 
> Anybody interested or willing to be a mentor for this project? I might be a
> mentor as well, if needed, since I do have some mentoring experience from
> the last year GSoC.
> 
> Regards,
> Dashamir


From doron.behar at gmail.com  Mon Mar 18 16:06:27 2019
From: doron.behar at gmail.com (Doron Behar)
Date: Mon, 18 Mar 2019 17:06:27 +0200
Subject: GSoC project idea
In-Reply-To: <CAMucfLxkeDh70JV7WKuV27OqchakNjZqKtu0yqLsu6O2tWyWhA@mail.gmail.com>
References: <CAMucfLw0y1JGcJhV8o-Da0-GAegfUCb4x1YM9cdLbTnTKJ7YgA@mail.gmail.com>
 <20190318112127.fyxhwpbkx2vkbtcn@NUC.doronbehar.com>
 <CAMucfLxkeDh70JV7WKuV27OqchakNjZqKtu0yqLsu6O2tWyWhA@mail.gmail.com>
Message-ID: <20190318150627.ejjydu3crfupnjfy@NUC.doronbehar.com>

On Mon, Mar 18, 2019 at 01:31:23PM +0100, Dashamir Hoxha wrote:
> On Mon, Mar 18, 2019 at 12:21 PM Doron Behar <doron.behar at gmail.com> wrote:
> 
> > Hello Dashamir,
> >
> > Thanks for showing your interest in this idea. I thought more about it
> > after I've sent the email to the mailing list and I reached the
> > conclusion that it might be more efficient to _fork_ the existing
> > code-base and use the same existing functions and only bind them to a
> > different executable that will have a different use of argparse.
> >
> 
> Do you preserve the existing commands and options of `gpg`, for backwards
> compatibility? If yes, maybe there is some chance that your changes will be
> merged some day to the main project. Otherwise I think that it is going
> nowhere. Neither the developers nor the users will accept radical changes
> to the CLI of `gpg`. I don't think your aim is to maintain it forever as an
> alternative to `gpg` because this is a huge task.

In my fork I didn't modify anything, only added. The idea is to add only
a directory named ipg (Acronym for improved privacy guard) and in it all
the code that will use the functions that already exist in the source
tree; So when a user builds my version from the git source (autoreconf
&& ./configure && make && make install), he will a get another
executable installed called `ipg` that will be equivalent to `gpg` in
it's use but will have a nicer CLI syntax.

Both executables (gpg & ipg) installed by my version will be equally
updated to use the latest version of the C code that implements the
actual encryption and decryption etc.

> 
> 
> > Actually, I've already created a prototype of this and the missing work
> > to be done is connecting everything to the already existing functions
> > available in the code-base.
> >
> 
> It does not seem so easy to me because you may need some feedback from more
> experienced people, although you may think that you have organized the
> commands and their options properly.

I think the only difficult part in this design (and please correct me if
you think I'm wrong) is making sure that when the upstream source is
updated and functions change their names etc., my fork updates the names
of the functions it calls.

Also, according to my design, almost every sub-command and it's optional
flags have their equivalent in the current syntax, strictly according to
the documentation. The only difference is that some sub-commands
naturally don't accept all options that may be accepted (but ignored!)
in the current syntax. Most importantly, this should also prove to be
more comfortable for shell completions to not overwhelm users with
options most of which are irrelevant for the current _action_ they want
to perform.

> 
> 
> >
> > It is indeed a good project for a student. Only I'm not sure I'll be
> > able to do it myself, although my motivation is rather high. I'm
> > preparing myself for the 1st year of Computer Science studies in
> > university these days so I don't have a lot of spare time.
> >
> 
> You can be one of the mentors, which hopefully should not be very time
> consuming.

As a mentor, am I not obliged to be an experienced C programmer? If so,
that could be an excellent idea.

> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel



From dashohoxha at gmail.com  Mon Mar 18 16:49:11 2019
From: dashohoxha at gmail.com (Dashamir Hoxha)
Date: Mon, 18 Mar 2019 16:49:11 +0100
Subject: GSoC project idea
In-Reply-To: <20190318150627.ejjydu3crfupnjfy@NUC.doronbehar.com>
References: <CAMucfLw0y1JGcJhV8o-Da0-GAegfUCb4x1YM9cdLbTnTKJ7YgA@mail.gmail.com>
 <20190318112127.fyxhwpbkx2vkbtcn@NUC.doronbehar.com>
 <CAMucfLxkeDh70JV7WKuV27OqchakNjZqKtu0yqLsu6O2tWyWhA@mail.gmail.com>
 <20190318150627.ejjydu3crfupnjfy@NUC.doronbehar.com>
Message-ID: <CAMucfLx=NkyRhBLG3yWz5=2Jn9ib+hiZAAgMT4AhXup3x6v2hQ@mail.gmail.com>

On Mon, Mar 18, 2019 at 4:07 PM Doron Behar <doron.behar at gmail.com> wrote:

>
> In my fork I didn't modify anything, only added. The idea is to add only
> a directory named ipg (Acronym for improved privacy guard) and in it all
> the code that will use the functions that already exist in the source
> tree; So when a user builds my version from the git source (autoreconf
> && ./configure && make && make install), he will a get another
> executable installed called `ipg` that will be equivalent to `gpg` in
> it's use but will have a nicer CLI syntax.
>
> Both executables (gpg & ipg) installed by my version will be equally
> updated to use the latest version of the C code that implements the
> actual encryption and decryption etc.
>

In my opinion, it might be better if there was a single executable (gpg)
that can accept both sets of CLI commands. If this is possible.

In any case, I think that the aim should be to finally submit a patch to
the mainstream code, and hopefully it gets accepted. Distributing it
separately as an improved version of gpg is not going to work for many
reasons.


>
> > It does not seem so easy to me because you may need some feedback from
> more
> > experienced people, although you may think that you have organized the
> > commands and their options properly.
>
> I think the only difficult part in this design (and please correct me if
> you think I'm wrong) is making sure that when the upstream source is
> updated and functions change their names etc., my fork updates the names
> of the functions it calls.
>
> Also, according to my design, almost every sub-command and it's optional
> flags have their equivalent in the current syntax, strictly according to
> the documentation. The only difference is that some sub-commands
> naturally don't accept all options that may be accepted (but ignored!)
> in the current syntax. Most importantly, this should also prove to be
> more comfortable for shell completions to not overwhelm users with
> options most of which are irrelevant for the current _action_ they want
> to perform.
>

I understand your design and its advantages, but I am not sure wheather you
understand all the details about `gpg` commands and options. Maybe you do,
myself I don't.

> You can be one of the mentors, which hopefully should not be very time
> > consuming.
>
> As a mentor, am I not obliged to be an experienced C programmer? If so,
> that could be an excellent idea.
>

If you are an experienced C programmer that's great. But you don't have to
be. You can also be an experienced `gpg` user. And anyway, the idea of
reorganizing the commands is yours and you know what you are aiming for
better than anyone. So, you can definitely be one of the mentors, if you
have time and if you want to be.

Dashamir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190318/e85a7b15/attachment.html>

From bernhard at intevation.de  Tue Mar 19 12:03:48 2019
From: bernhard at intevation.de (Bernhard Reiter)
Date: Tue, 19 Mar 2019 12:03:48 +0100
Subject: GnuPG 2.2 on elder Debian & Ubuntu distros
Message-ID: <201903191203.49127.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

again thanks for them!

Wanted to try the latest way to test for WKD support
  gpg-wks-client --supported 

Noticed that gpg-wkd-client is not packaged?

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/20190319/4183af4a/attachment.sig>

From manowar at altlinux.org  Tue Mar 19 10:40:20 2019
From: manowar at altlinux.org (Paul Wolneykien)
Date: Tue, 19 Mar 2019 12:40:20 +0300
Subject: GOST support in GnuPG
Message-ID: <707d2dbe-ddc7-b553-c960-a2ede333697e@altlinux.org>


  Hi!

  I'm working on adding the GOST (Russian EC crypto) support to GnuPG.
Currently I have a version where sign/verify and encrypt/decrypt
operations function properly (with some restrictions) in both PGP and
S/MIME modes. I want to know what is the official procedure to include
such a new functionality in GnuPG?

  My current set of patches are as follows:

    * GOST cases in g10, sm, common and the agent:
https://packages.altlinux.org/en/sisyphus/srpms/gnupg2/patches/gnupg2-2.2.10-gost-1.0.0.patch
    * workaround for multi-URL CRLs in dirmngr:
https://packages.altlinux.org/en/sisyphus/srpms/gnupg2/patches/gnupg2-2.2.10-issuers-1.0.0.patch
    * GOST VKO algorithm in Libgcrypt:
https://packages.altlinux.org/en/sisyphus/srpms/libgcrypt/patches/libgcrypt-1.8.3-vko-1.0.0.patch
    * GOST ASN.1 in Libksba:
https://packages.altlinux.org/en/sisyphus/srpms/libksba/patches/libksba-1.3.6-gost-1.0.0.patch


From bernhard at intevation.de  Tue Mar 19 12:45:15 2019
From: bernhard at intevation.de (Bernhard Reiter)
Date: Tue, 19 Mar 2019 12:45:15 +0100
Subject: [project idea] Improve the usability of GnuPG CLI
In-Reply-To: <CAMucfLyqdPc67wVpDFqmFqH6QZOm4H=gVEZEZU7_kzFSaRyxzA@mail.gmail.com>
References: <CAMucfLyqdPc67wVpDFqmFqH6QZOm4H=gVEZEZU7_kzFSaRyxzA@mail.gmail.com>
Message-ID: <201903191245.24498.bernhard@intevation.de>

Hi Dashamir,

Am Donnerstag 16 August 2018 01:01:10 schrieb Dashamir Hoxha:
> Since this GSoC term is almost over, I would like to share
> a few project ideas that might be used on future terms.

note that some people criticise the Google Summer of Code program
for 
a) mainly helping Google to recruit people
b) often creating results that are a one shot and are more a burden to the 
Free Software initiative they are trying to contribute to.

This is the reason why Werner stated 2017-12 that he will not support it.
(https://lists.gnupg.org/pipermail/gnupg-devel/2017-December/033306.html)

> This project idea originates from this discussion:
> https://lists.gnupg.org/pipermail/gnupg-devel/2018-July/033852.html
>
> The idea is to write a CLI wrapper for the `gpg` command
> (in Bash, or Python, or something else) that improves the usability
> of `gpg` by trying to imitate the style of the `git` command.
>
> Basically it should do something like this:
> - Clearly separate the commands from the options and arguments.
> - Use bash autocomplete whenever possible.
> - Create a separate man page for each command.
> - Give contextual help when user seems to be lost.
> - Etc.

Agreeably the command line interface of gpg is not as good as it could be,
especially if you consider modern complex command line interfaces.
In principle all research to improve GnuPG is welcome.

Once a project is proposed, it should be asked if  itis worth the efforts
and if it should be done compared to what else could be done in the same time 
by the same people.

From my perspective the idea of improving the interactive command line 
interface of gpg in a more radical way is doubtful. 

For once the current command line interface is historically grown and 
(unfortunately) used in a number of scripts. There would be high learning and 
changing costs if it would become incompatible or even extended by many 
commands. So the old interface will have to be preserved. It does not seem 
feasable to maintain two interfaces in the long run. So we probably are stuck 
with the pros and cons of the current interface style.

As second point I don't think that the gains are on the top of the list of 
making gpg better. Many people will use gpg just as engine and not directly 
because gpg is about emails and files. Those are handled best in file 
browsers and email clients. File handling is done a lot on the command line, 
so the interactive interface can be used there of course. Many other command 
use a style comparable to gpg, and gpg is a complex application so there is 
some learning necessary anyhow. If people have time there are much better 
places to improve the user experience: like help email clients to make use of 
the first steps of WKD.

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/20190319/76a3508a/attachment-0001.sig>

From bernhard at intevation.de  Tue Mar 19 12:53:35 2019
From: bernhard at intevation.de (Bernhard Reiter)
Date: Tue, 19 Mar 2019 12:53:35 +0100
Subject: GSoC project idea
In-Reply-To: <CAMucfLw0y1JGcJhV8o-Da0-GAegfUCb4x1YM9cdLbTnTKJ7YgA@mail.gmail.com>
References: <CAMucfLw0y1JGcJhV8o-Da0-GAegfUCb4x1YM9cdLbTnTKJ7YgA@mail.gmail.com>
Message-ID: <201903191253.35501.bernhard@intevation.de>

Hi,

Am Sonntag 17 M?rz 2019 18:13:32 schrieb Dashamir Hoxha:
> However I came up with a proposal for writing just a wrapper to the current
> gpg command, that organizes the commands and options in a different way,
> presumably more easy and intuitive.

to document it, I've just written a reply to one of the threads last year
writing about technical drawbacks and the problems that some perceive with 
GSoC.

The main problems I see with the idea:
a) How long and by whom would this wrapper be maintained?
   It is hard enough to maintain the current gpg as it is.
   If the perspective is only up to three years, then we cannot really
   recommand anyone to learn the new interface as it is likely to go away
   after that time and the original gpg will stay. It would be just for
   experimentation.

b) There are many better ideas how to help end to end encryption with GnuPG
   to provide a better user experience. For example implementing automatic
   encryption after a WKD request in more email clients. Writing instructions
   how to set up simple WKD on the server.

> I think this is suitable task for a GSoC project that can be developed in
> 2-3 months by a good student, with help and guidance from mentors.

If it would be clear what each option would do, the implementation time would 
be enough, but the assumptions of the current interactive command line 
interface and all its bells and whistles are many and interact in a complex 
way, so to me it is doubtful that a student can handle this in 3 months. 

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/20190319/dc1e9ecb/attachment.sig>

From wk at gnupg.org  Tue Mar 19 12:28:25 2019
From: wk at gnupg.org (Werner Koch)
Date: Tue, 19 Mar 2019 12:28:25 +0100
Subject: [Announce] GnuPG 2.2.14 released
Message-ID: <87bm273xye.fsf@wheatstone.g10code.de>

Hello!

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


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

The GNU Privacy Guard (GnuPG, GPG) is a complete and free implementation
of the OpenPGP and S/MIME standards.

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.  The separate library GPGME provides
a uniform API to use the GnuPG engine by software written in common
programming languages.  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.14
====================================

  * gpg: Allow import of PGP desktop exported secret keys.  Also avoid
   importing secret keys if the secret keyblock is not valid.  [#4392]

  * gpg: Do not error out on version 5 keys in the local keyring.

  * gpg: Make invalid primary key algo obvious in key listings.

  * sm: Do not mark a certificate in a key listing as de-vs compliant
    if its use for a signature will not be possible.

  * sm: Fix certificate creation with key on card.

  * sm: Create rsa3072 bit certificates by default.

  * sm: Print Yubikey attestation extensions with --dump-cert.

  * agent: Fix cancellation handling for scdaemon.

  * agent: Support --mode=ssh option for CLEAR_PASSPHRASE.  [#4340]

  * scd: Fix flushing of the CA-FPR DOs in app-openpgp.

  * scd: Avoid a conflict error with the "undefined" app.

  * dirmngr: Add CSRF protection exception for protonmail.

  * dirmngr: Fix build problems with gcc 9 in libdns.

  * gpgconf: New option --show-socket for use wity --launch.

  * gpgtar: Make option -C work for archive creation.

  Release-info: https://dev.gnupg.org/T4412


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

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

GnuPG 2.2.14 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.14.tar.bz2 (6550k)
 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.14.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.14_20190319.exe (4077k)
 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.14_20190319.exe.sig

The source used to build the Windows installer can be found in the same
directory with a ".tar.xz" suffix.


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.14.tar.bz2 you would use this command:

     gpg --verify gnupg-2.2.14.tar.bz2.sig gnupg-2.2.14.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.14.tar.bz2, you run the command like this:

     sha1sum gnupg-2.2.14.tar.bz2

   and check that the output matches the next line:

f349c20e7498af88299b0d42a961e0364e5c37e7  gnupg-2.2.14.tar.bz2
d88b15f7625dcaa5d6991222bcf2c69be2b5a987  gnupg-w32-2.2.14_20190319.tar.xz
a8f74358cab09b737b2f69c096072428e5ae2d9d  gnupg-w32-2.2.14_20190319.exe


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

This version of GnuPG has support for 26 languages with Chinese
(traditional and simplified), 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 available 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.

In case of build problems specific to this release please first check
https://dev.gnupg.org/T4412 for updated information.

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 two full-time developers and one
contractor.  They all work exclusively on GnuPG and closely related
software like Libgcrypt, GPGME and Gpg4win.

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 to 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.

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- 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/20190319/9363525c/attachment.sig>
-------------- next part --------------
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce

From ilf at zeromail.org  Tue Mar 19 12:50:36 2019
From: ilf at zeromail.org (ilf)
Date: Tue, 19 Mar 2019 12:50:36 +0100
Subject: GOST support in GnuPG
In-Reply-To: <707d2dbe-ddc7-b553-c960-a2ede333697e@altlinux.org>
References: <707d2dbe-ddc7-b553-c960-a2ede333697e@altlinux.org>
Message-ID: <20190319115036.GE28444@zeromail.org>

Paul Wolneykien:
> I'm working on adding the GOST (Russian EC crypto) support to GnuPG.

This one? 
https://en.wikipedia.org/wiki/GOST_(block_cipher)#Cryptanalysis_of_GOST

-- 
ilf

If you upload your address book to "the cloud", I don't want to be in it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190319/ec3b0b3c/attachment.sig>

From manowar at altlinux.org  Tue Mar 19 17:13:20 2019
From: manowar at altlinux.org (Paul Wolneykien)
Date: Tue, 19 Mar 2019 19:13:20 +0300
Subject: GOST support in GnuPG
In-Reply-To: <20190319115036.GE28444@zeromail.org>
References: <707d2dbe-ddc7-b553-c960-a2ede333697e@altlinux.org>
 <20190319115036.GE28444@zeromail.org>
Message-ID: <f8a3c810-5d56-65e0-ac8a-c719abf8413e@altlinux.org>

19.03.2019 14:50, ilf ?????:
> Paul Wolneykien:
>> I'm working on adding the GOST (Russian EC crypto) support to GnuPG.
> 
> This one?
> https://en.wikipedia.org/wiki/GOST_(block_cipher)#Cryptanalysis_of_GOST

  And these ones too:

  * https://en.wikipedia.org/wiki/GOST_(hash_function) ;
  * https://tools.ietf.org/html/rfc5832 .
  * https://tools.ietf.org/html/rfc4357 .

  Note, that some of them are already in Libgcrypt:

    *
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=blob;f=cipher/gost28147.c
;
    *
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=blob;f=cipher/gostr3411-94.c
;
    *
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=blob;f=cipher/ecc-gost.c
.

  I've added VKO (rfc4357) and modified gpg and gpgsm to support all of
that (for instance, the GOST R 3410 algorithm is already in Libgcrypt
but there was no way to sign a message with it due to lack of support
from gpg itself).


From dkg at fifthhorseman.net  Tue Mar 19 17:32:22 2019
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 19 Mar 2019 12:32:22 -0400
Subject: Git release tagging best practices
Message-ID: <87r2b2u8o9.fsf@fifthhorseman.net>

Hi GnuPG folks--

I was just reviewing the cryptographically-signed git tags that
represent releases of GnuPG, thanks to the 2.2.14 release, which i'm
aiming to upload into debian experimental later today.  I enjoy the
commentary and media recommendations included in the git tag messages,
but i think they aren't currently very useful for downstream verifiers.

I recommend making a standardized message for each future release tag,
starting with a single line "GnuPG version $version".  This allows any
downstream to defend against a possible obscure attack against any other
repositories of software that you might also sign.  (and it would defend
GnuPG against impersonation attacks from any other such project as well)

So, rather than doing:

    git tag -s -m 'Just another boring release' gnupg-2.2.15

Instead, please do:

    git tag -s -m 'GnuPG version 2.2.15' gnupg-2.2.15

The issue is that the thing that is being tagged is not clearly
recognizable as GnuPG -- it's just something signed, by OpenPGP
certificate 0xD8692123C4065DEA5E0F3AB5249B39D24F25E3B6.  People might
evaluate it as a a GnuPG release because of where they happen to find
the git repository (e.g. the URL they chose), but the same git
repository can be replicated to some other location, and the signed tag
will show up there as well.

By ensuring that your git tag messages are specific to the project that
you're signing, and that they include the release information that you
are trying to convey, someone verifying your signed tag on *any*
repository can defend against this attack by ensuring not only your
signature, but also that the signing message is related to the project
that they care about.

If you want to include reading recommendations and other interesting
commentary, you can still do that by adding additional -m options (git
will concatenate them with blank lines between).  As long as you reserve
the first line as a standardized and unambiguous form, then that gives
automated downstream checks something to concretely verify, rather than
having them guess that this is actually the right new tag, based on
non-verifiable features like tag name, repository location, etc.

I'm recommending these as best practices, while acknowledging that very
few projects follow them yet.  I'm hoping that GnuPG can help to lead
the way in establishing this sort of convention, so that i can encourage
downstream tools to verify meaningful signatures, rather than just
"something that Werner or gniibe signed".

All the best,

          --dkg

PS Note that the *name* of the tag itself is not covered by the
   cryptographic signature (it is possible to rename tags without
   modifying their cryptographic validity).  This is why I recommend
   using the tag message to contain this information rather than the tag
   name itself.
-------------- 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/20190319/24951379/attachment-0001.sig>

From peter at digitalbrains.com  Tue Mar 19 19:09:25 2019
From: peter at digitalbrains.com (Peter Lebbing)
Date: Tue, 19 Mar 2019 19:09:25 +0100
Subject: Git release tagging best practices
In-Reply-To: <87r2b2u8o9.fsf@fifthhorseman.net>
References: <87r2b2u8o9.fsf@fifthhorseman.net>
Message-ID: <2d2be3d5-17cd-ee71-f5e5-9f17ca4db8e2@digitalbrains.com>

On 19/03/2019 17:32, Daniel Kahn Gillmor wrote:
> PS Note that the *name* of the tag itself is not covered by the
>    cryptographic signature (it is possible to rename tags without
>    modifying their cryptographic validity).  This is why I recommend
>    using the tag message to contain this information rather than the tag
>    name itself.

Are you sure? I looked at what the exact data that is signed is, and it
seems to me it does include the name:

--8<---------------cut here---------------start------------->8---
$ cat .git/refs/tags/gnupg-2.2.13
baae95e8359ab45ff64414a8e8387997bb828a1b
$ git cat-file tag baae95e8359ab45ff64414a8e8387997bb828a1b
object 7922e2dd1c7eee48a8a2cf4799827942489ddd0f
type commit
tag gnupg-2.2.13
tagger Werner Koch <wk at gnupg.org> 1549985965 +0100

You may want to watch the Ellsberg/Chomsky discussion
at <https://riseuptimes.org/2018/04/25/daniel-ellsberg-and-noam-chomsky-discuss-nuclear-war/>
or at <https://theintercept.com/chomsky-ellsberg/>
-----BEGIN PGP SIGNATURE-----

iQEzBAABCAAdFiEE2GkhI8QGXepeDzq1JJs50k8l47YFAlxi6SwACgkQJJs50k8l
47Zczwf/XGMMUCWnWsD+nVzmAYaBPp76/CBkG6qeZkvAVyFbhv9RGs4SRxp4rK1r
NT9tnjHyETIh/Yoc0uDgIdt2neaicc2LKrVgzMpsOKutFyKrH5hNsfCrMAu/NEC8
6AEFcRlS0WWgQTehiwVjCRf/hALYW1KjeL6HR2J1b58VAlABa78H+tY8Z+wFqFcf
XJgQ8gR1QtkMuLnGqlN/6sLjN0BKsBqMZvt/T9aljpH6RJuzTyIUjln1uDl43htj
sDGa7BZtmf7XiEjcX62NS6yDfuOyw0guDFkOvsIt3IBqtDWAxY7qc5do0CQjOU8t
BdrTflO5D1a9ZISgA+6wO/nJAIvFwA==
=F3BP
-----END PGP SIGNATURE-----
--8<---------------cut here---------------end--------------->8---

So let's split that into:

the-tag.txt:
--8<---------------cut here---------------start------------->8---
object 7922e2dd1c7eee48a8a2cf4799827942489ddd0f
type commit
tag gnupg-2.2.13
tagger Werner Koch <wk at gnupg.org> 1549985965 +0100

You may want to watch the Ellsberg/Chomsky discussion
at <https://riseuptimes.org/2018/04/25/daniel-ellsberg-and-noam-chomsky-discuss-nuclear-war/>
or at <https://theintercept.com/chomsky-ellsberg/>
--8<---------------cut here---------------end--------------->8---

the-tag.sig:
--8<---------------cut here---------------start------------->8---
-----BEGIN PGP SIGNATURE-----

iQEzBAABCAAdFiEE2GkhI8QGXepeDzq1JJs50k8l47YFAlxi6SwACgkQJJs50k8l
47Zczwf/XGMMUCWnWsD+nVzmAYaBPp76/CBkG6qeZkvAVyFbhv9RGs4SRxp4rK1r
NT9tnjHyETIh/Yoc0uDgIdt2neaicc2LKrVgzMpsOKutFyKrH5hNsfCrMAu/NEC8
6AEFcRlS0WWgQTehiwVjCRf/hALYW1KjeL6HR2J1b58VAlABa78H+tY8Z+wFqFcf
XJgQ8gR1QtkMuLnGqlN/6sLjN0BKsBqMZvt/T9aljpH6RJuzTyIUjln1uDl43htj
sDGa7BZtmf7XiEjcX62NS6yDfuOyw0guDFkOvsIt3IBqtDWAxY7qc5do0CQjOU8t
BdrTflO5D1a9ZISgA+6wO/nJAIvFwA==
=F3BP
-----END PGP SIGNATURE-----
--8<---------------cut here---------------end--------------->8---

And presto:

--8<---------------cut here---------------start------------->8---
$ gpg --verify the-tag.{sig,txt}
gpg: Signature made Tue 12 Feb 2019 16:41:32 CET
gpg:                using RSA key D8692123C4065DEA5E0F3AB5249B39D24F25E3B6
gpg: Good signature from "Werner Koch (dist sig)" [full]
gpg: werner koch (dist sig): Verified [REDACTED]
--8<---------------cut here---------------end--------------->8---

Note that the third line of the signed data reads "tag gnupg-2.2.13". So
is there some loophole that means this is not useful?

I'm not saying that the first line of tag messages shouldn't be
standardized as you propose, I'm just debating the correctness of the
quoted assertion.

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/20190319/813b633c/attachment.sig>

From cloehle at posteo.de  Tue Mar 19 20:16:00 2019
From: cloehle at posteo.de (Christian Loehle)
Date: Tue, 19 Mar 2019 19:16:00 +0000
Subject: [PATCH gpa] fix bees typo
In-Reply-To: <2082bdbd-d3b9-f702-b0e3-2e52ab7ccf5b@posteo.de>
References: <2082bdbd-d3b9-f702-b0e3-2e52ab7ccf5b@posteo.de>
Message-ID: <afdcb6f6-8eba-555c-a887-b9a41a98dad3@posteo.de>

>From bb88517370a0a7395e00bdcf9ee12b6f9855bd67 Mon Sep 17 00:00:00 2001
From: Christian Loehle <cloehle at posteo.de>
Date: Fri, 22 Feb 2019 21:49:46 +0100
Subject: [PATCH] fix bees typo

---
 po/ar.po              | 2 +-
 po/cs.po              | 2 +-
 po/es.po              | 2 +-
 po/fr.po              | 2 +-
 po/ja.po              | 2 +-
 po/nl.po              | 2 +-
 po/pl.po              | 2 +-
 po/pt_BR.po           | 2 +-
 po/ru.po              | 2 +-
 po/sv.po              | 2 +-
 po/tr.po              | 2 +-
 po/zh_CN.po           | 2 +-
 po/zh_TW.po           | 2 +-
 src/gpaexportclipop.c | 2 +-
 14 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/po/ar.po b/po/ar.po
index 40bdeb6..ce0af68 100644
--- a/po/ar.po
+++ b/po/ar.po
@@ -408,7 +408,7 @@ msgid "The private key has been copied to the clipboard."
 msgstr "?? ??? ???????? ??? ???????."
 
 #, fuzzy
-msgid "The key has bees copied to the clipboard."
+msgid "The key has been copied to the clipboard."
 msgstr "?? ??? ???????? ??? ???????."
 
 msgid "The keys have been copied to the clipboard."
diff --git a/po/cs.po b/po/cs.po
index 769b2bf..1ca640f 100644
--- a/po/cs.po
+++ b/po/cs.po
@@ -381,7 +381,7 @@ msgid "The private key has been copied to the clipboard."
 msgstr "Kl??e byly zkop?rov?ny do schr?nky."
 
 #, fuzzy
-msgid "The key has bees copied to the clipboard."
+msgid "The key has been copied to the clipboard."
 msgstr "Kl??e byly zkop?rov?ny do schr?nky."
 
 msgid "The keys have been copied to the clipboard."
diff --git a/po/es.po b/po/es.po
index b738865..709ee07 100644
--- a/po/es.po
+++ b/po/es.po
@@ -411,7 +411,7 @@ msgid "The private key has been copied to the clipboard."
 msgstr "Las claves se han copiado al portapapeles."
 
 #, fuzzy
-msgid "The key has bees copied to the clipboard."
+msgid "The key has been copied to the clipboard."
 msgstr "Las claves se han copiado al portapapeles."
 
 msgid "The keys have been copied to the clipboard."
diff --git a/po/fr.po b/po/fr.po
index 27a53fb..88da866 100644
--- a/po/fr.po
+++ b/po/fr.po
@@ -393,7 +393,7 @@ msgid "The private key has been copied to the clipboard."
 msgstr "Les clefs ont ?t? copi?es dans le presse-papiers."
 
 #, fuzzy
-msgid "The key has bees copied to the clipboard."
+msgid "The key has been copied to the clipboard."
 msgstr "Les clefs ont ?t? copi?es dans le presse-papiers."
 
 msgid "The keys have been copied to the clipboard."
diff --git a/po/ja.po b/po/ja.po
index 17d54b4..59ed682 100644
--- a/po/ja.po
+++ b/po/ja.po
@@ -430,7 +430,7 @@ msgid "The private key has been copied to the clipboard."
 msgstr "?????????????????????????"
 
 #, fuzzy
-msgid "The key has bees copied to the clipboard."
+msgid "The key has been copied to the clipboard."
 msgstr "?????????????????????????"
 
 msgid "The keys have been copied to the clipboard."
diff --git a/po/nl.po b/po/nl.po
index f85c2da..d811e57 100644
--- a/po/nl.po
+++ b/po/nl.po
@@ -426,7 +426,7 @@ msgid "The private key has been copied to the clipboard."
 msgstr "De sleutels werden naar het klembord gekopieerd."
 
 #, fuzzy
-msgid "The key has bees copied to the clipboard."
+msgid "The key has been copied to the clipboard."
 msgstr "De sleutels werden naar het klembord gekopieerd."
 
 msgid "The keys have been copied to the clipboard."
diff --git a/po/pl.po b/po/pl.po
index e389a12..2288fcc 100644
--- a/po/pl.po
+++ b/po/pl.po
@@ -422,7 +422,7 @@ msgid "The private key has been copied to the clipboard."
 msgstr "Klucze zosta?y skopiowane do schowka."
 
 #, fuzzy
-msgid "The key has bees copied to the clipboard."
+msgid "The key has been copied to the clipboard."
 msgstr "Klucze zosta?y skopiowane do schowka."
 
 msgid "The keys have been copied to the clipboard."
diff --git a/po/pt_BR.po b/po/pt_BR.po
index 6b7a2fd..583d43a 100644
--- a/po/pt_BR.po
+++ b/po/pt_BR.po
@@ -425,7 +425,7 @@ msgid "The private key has been copied to the clipboard."
 msgstr ""
 
 #, fuzzy
-msgid "The key has bees copied to the clipboard."
+msgid "The key has been copied to the clipboard."
 msgstr "Esta chave expirou! Imposs?vel assinar."
 
 msgid "The keys have been copied to the clipboard."
diff --git a/po/ru.po b/po/ru.po
index 3e80c0f..3fd73a3 100644
--- a/po/ru.po
+++ b/po/ru.po
@@ -385,7 +385,7 @@ msgid "The private key has been copied to the clipboard."
 msgstr "????? ??????????? ? ?????."
 
 #, fuzzy
-msgid "The key has bees copied to the clipboard."
+msgid "The key has been copied to the clipboard."
 msgstr "????? ??????????? ? ?????."
 
 msgid "The keys have been copied to the clipboard."
diff --git a/po/sv.po b/po/sv.po
index b27141b..2532f12 100644
--- a/po/sv.po
+++ b/po/sv.po
@@ -386,7 +386,7 @@ msgid "The private key has been copied to the clipboard."
 msgstr "Nycklarna har kopierats till urklipp."
 
 #, fuzzy
-msgid "The key has bees copied to the clipboard."
+msgid "The key has been copied to the clipboard."
 msgstr "Nycklarna har kopierats till urklipp."
 
 msgid "The keys have been copied to the clipboard."
diff --git a/po/tr.po b/po/tr.po
index 216e122..08f2b94 100644
--- a/po/tr.po
+++ b/po/tr.po
@@ -421,7 +421,7 @@ msgid "The private key has been copied to the clipboard."
 msgstr "Anahtarlar panoya kopyaland?"
 
 #, fuzzy
-msgid "The key has bees copied to the clipboard."
+msgid "The key has been copied to the clipboard."
 msgstr "Anahtarlar panoya kopyaland?"
 
 msgid "The keys have been copied to the clipboard."
diff --git a/po/zh_CN.po b/po/zh_CN.po
index 8dec479..f35f716 100644
--- a/po/zh_CN.po
+++ b/po/zh_CN.po
@@ -382,7 +382,7 @@ msgid "The private key has been copied to the clipboard."
 msgstr "???????????"
 
 #, fuzzy
-msgid "The key has bees copied to the clipboard."
+msgid "The key has been copied to the clipboard."
 msgstr "???????????"
 
 msgid "The keys have been copied to the clipboard."
diff --git a/po/zh_TW.po b/po/zh_TW.po
index ef82cbf..c6313b5 100644
--- a/po/zh_TW.po
+++ b/po/zh_TW.po
@@ -420,7 +420,7 @@ msgid "The private key has been copied to the clipboard."
 msgstr "???_?w?????K???."
 
 #, fuzzy
-msgid "The key has bees copied to the clipboard."
+msgid "The key has been copied to the clipboard."
 msgstr "???_?w?????K???."
 
 msgid "The keys have been copied to the clipboard."
diff --git a/src/gpaexportclipop.c b/src/gpaexportclipop.c
index b3f9acf..1759434 100644
--- a/src/gpaexportclipop.c
+++ b/src/gpaexportclipop.c
@@ -145,7 +145,7 @@ gpa_export_clipboard_operation_complete_export (GpaExportOperation *operation)
     gpa_show_info
       (GPA_OPERATION (op)->window,
        is_secret? _("The private key has been copied to the clipboard.") :
-       nkeys==1 ? _("The key has bees copied to the clipboard.") :
+       nkeys==1 ? _("The key has been copied to the clipboard.") :
        /* */      _("The keys have been copied to the clipboard."));
 }
 


From bernhard at intevation.de  Wed Mar 20 10:28:13 2019
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 20 Mar 2019 10:28:13 +0100
Subject: Improving product summary in announcement (Re: [Announce] GnuPG
 2.2.14 released)
In-Reply-To: <87bm273xye.fsf@wheatstone.g10code.de>
References: <87bm273xye.fsf@wheatstone.g10code.de>
Message-ID: <201903201028.19394.bernhard@intevation.de>

Hello,

first: Congratulations on the new release!

Am Dienstag 19 M?rz 2019 12:28:25 schrieb Werner Koch:
> The GNU Privacy Guard (GnuPG, GPG) is a complete and free implementation
> of the OpenPGP and S/MIME standards.

Noticed that "S/MIME" also includes the email part, 
which I don't think GnuPG fully provides.

Cryptography is complicated enough, so we should try to be as clear as we can.
To suggest something better is hard, some thoughts and ideas: 
Mentioning "S/MIME" is good as this is a well known keyword for the open 
standard (beside OpenPGP) that GnuPG is used for. While "Cryptographic 
Message Syntax (CMS)" would be technical more on a similiar level like 
OpenPGP, it is less known and such harder to understand.

What about
"The GNU Privacy Guard (GnuPG, GPG) provides a complete and free engine
 to implement email and file cryptography by OpenPGP and S/MIME standards."

Or maybe
"The GNU Privacy Guard (GnuPG, GPG) is a complete and free implementation
 of the OpenPGP and CMS standards needed for OpenPGP/- or S/MIME mails."

or
"The GNU Privacy Guard (GnuPG, GPG) is a complete and free implementation
 of the OpenPGP and CMS standards. CMS is needed for S/MIME mails."

Best Regards,
Bernhard
ps.: Sendign this to -devel@ because I think it is a concern for people 
producing GnuPG.


-- 
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/20190320/e9fda96a/attachment.sig>

From dkg at fifthhorseman.net  Wed Mar 20 12:22:11 2019
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 20 Mar 2019 07:22:11 -0400
Subject: GnuPG 2.2 on elder Debian & Ubuntu distros
In-Reply-To: <201903191203.49127.bernhard@intevation.de>
References: <201903191203.49127.bernhard@intevation.de>
Message-ID: <87ftrhu6xo.fsf@fifthhorseman.net>

On Tue 2019-03-19 12:03:48 +0100, Bernhard Reiter wrote:
> Wanted to try the latest way to test for WKD support
>   gpg-wks-client --supported 
>
> Noticed that gpg-wkd-client is not packaged?

What is gpg-wkd-client?  do you mean gpg-wks-client?

I note that gpg-wks-client is available in stretch-backports, thanks to
work by Roger Shimizu (in cc here).

     --dkg


From dkg at fifthhorseman.net  Wed Mar 20 13:28:33 2019
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 20 Mar 2019 08:28:33 -0400
Subject: Git release tagging best practices
In-Reply-To: <2d2be3d5-17cd-ee71-f5e5-9f17ca4db8e2@digitalbrains.com>
References: <87r2b2u8o9.fsf@fifthhorseman.net>
 <2d2be3d5-17cd-ee71-f5e5-9f17ca4db8e2@digitalbrains.com>
Message-ID: <874l7xu3v2.fsf@fifthhorseman.net>

On Tue 2019-03-19 19:09:25 +0100, Peter Lebbing wrote:
> On 19/03/2019 17:32, Daniel Kahn Gillmor wrote:
>> PS Note that the *name* of the tag itself is not covered by the
>>    cryptographic signature (it is possible to rename tags without
>>    modifying their cryptographic validity).  This is why I recommend
>>    using the tag message to contain this information rather than the tag
>>    name itself.
>
> Are you sure? I looked at what the exact data that is signed is, and it
> seems to me it does include the name:

That's interesting, thanks for pointing it out.  There are two places
for the name of the tag, and i think you're right that the signatures
made by modern git tags do seem to include the tag name (gnupg is ahead
of the game here, fwiw: many projects don't include the project name in
their tag name, and just go with tags like v2.2.13, which leave the same
issue open).  I didn't think that they used to do that, but maybe they
did and i just never noticed.

> Note that the third line of the signed data reads "tag gnupg-2.2.13". So
> is there some loophole that means this is not useful?

To test that, i've just pushed https://gitlab.com/dkg/renaming-demo.git,
where I've just re-named a different tag issued by Werner.

If you were to clone that repository, you'll note that "git tag -v
gnupg-2.2.13" returns success, even though the contents of the message
don't say "tag gnupg-2.2.13".  

So i suppose it depends on how you think people are verifying that tag.
I'd imagine most folks (if they verify the tag at all) just check that
git tag -v $tagname returns 0 (and maybe they check that the tag was
made by a key that they associate with the project).

I wonder whether we "git tag -v" should raise an error if the tag name
within the signature doesn't match the tag name being verified.  I've
just sent message-id: <875zsdu41d.fsf at fifthhorseman.net> to
git at vger.kernel.org to ask about improving the situation there (maybe i
need to subscribe to convince them to let my mail through, though, i
don't know).

> I'm not saying that the first line of tag messages shouldn't be
> standardized as you propose, I'm just debating the correctness of the
> quoted assertion.

Thanks for the clarifying question, and for pointing this out!

Regards,

        --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/20190320/9f89d6a4/attachment.sig>

From aheinecke at gnupg.org  Wed Mar 20 16:12:46 2019
From: aheinecke at gnupg.org (Andre Heinecke)
Date: Wed, 20 Mar 2019 16:12:46 +0100
Subject: Improving product summary in announcement (Re: [Announce] GnuPG
 2.2.14 released)
In-Reply-To: <201903201028.19394.bernhard@intevation.de>
References: <87bm273xye.fsf@wheatstone.g10code.de>
 <201903201028.19394.bernhard@intevation.de>
Message-ID: <6502004.a1Hr7B418x@esus>

Hi,

Thank you for your input. But:

On Wednesday 20 March 2019 10:28:13 CET Bernhard Reiter wrote:
> Am Dienstag 19 M?rz 2019 12:28:25 schrieb Werner Koch:
> > The GNU Privacy Guard (GnuPG, GPG) is a complete and free implementation
> > of the OpenPGP and S/MIME standards.
> 
> Noticed that "S/MIME" also includes the email part, 
> which I don't think GnuPG fully provides.
> 
> Cryptography is complicated enough, so we should try to be as clear as we 
can.

For this reason I _never_ mention CMS in any user visible string. Even x509 
Certificates are "S/MIME Certificates". Users do "OpenPGP" or they do "S/MIME" 
they have "OpenPGP Keys" or "S/MIME Certificates". I try in my work to reduce 
the distinction in the wording between Keys and Certificates.

> What about
> "The GNU Privacy Guard (GnuPG, GPG) provides a complete and free engine
>  to implement email and file cryptography by OpenPGP and S/MIME standards."

But you say above that you do not want to complicate things?

>  Or maybe
> "The GNU Privacy Guard (GnuPG, GPG) is a complete and free implementation
>  of the OpenPGP and CMS standards needed for OpenPGP/- or S/MIME mails."

CMS is for developers. In my experience users do not know it and should not be 
exposed to it, ever. Personally I've used GnuPG for S/MIME and OpenPGP for 
years before I even knew what CMS meant.

Yep it's all not technically correct but we want to provide a good user 
experience and that is not helped by adding confusing "technically correct" 
terms.

Best Regards,
Andre

-- 
GnuPG.com - a brand of g10 Code, the GnuPG experts.

g10 Code GmbH, Erkrath/Germany, AG Wuppertal HRB14459
GF Werner Koch, USt-Id DE215605608, www.g10code.com.

GnuPG e.V., Rochusstr. 44, D-40479 D?sseldorf.  VR 11482 D?sseldorf
Vorstand: W.Koch, M.Gollowitzer, A.Heinecke.    Mail: board at gnupg.org
Finanzamt D-Altstadt, St-Nr: 103/5923/1779.   Tel: +49-2104-4938799
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190320/99361b7f/attachment.sig>

From dashohoxha at gmail.com  Wed Mar 20 16:17:37 2019
From: dashohoxha at gmail.com (Dashamir Hoxha)
Date: Wed, 20 Mar 2019 16:17:37 +0100
Subject: GSoC project idea
In-Reply-To: <201903191253.35501.bernhard@intevation.de>
References: <CAMucfLw0y1JGcJhV8o-Da0-GAegfUCb4x1YM9cdLbTnTKJ7YgA@mail.gmail.com>
 <201903191253.35501.bernhard@intevation.de>
Message-ID: <CAMucfLxS=cnz+4xPp2CrLbs4xjs6AQuXueZ3Hc-hcwDpDsOPAQ@mail.gmail.com>

On Tue, Mar 19, 2019 at 12:53 PM Bernhard Reiter <bernhard at intevation.de>
wrote:

>
> The main problems I see with the idea:
> a) How long and by whom would this wrapper be maintained?
>    It is hard enough to maintain the current gpg as it is.
>    If the perspective is only up to three years, then we cannot really
>    recommand anyone to learn the new interface as it is likely to go away
>    after that time and the original gpg will stay. It would be just for
>    experimentation.
>

Is it more acceptable to submit a patch that adds the new functionality,
rather than building a wrapper? Of course you don't have to accept it
unless it is done properly.
I think that experimentation is worthy too. A wrapper might be easier and
more flexible if we want to experiment just to get a better feeling about
the new interface. However Donor has already started working on the C code
and it might be a bit easier to just continue in that direction.


>
> b) There are many better ideas how to help end to end encryption with GnuPG
>    to provide a better user experience. For example implementing automatic
>    encryption after a WKD request in more email clients. Writing
> instructions
>    how to set up simple WKD on the server.
>

I agree but I don't have any idea about how to recruit new developers for
these tasks.
By the way, Google Season of Docs is around the corner:
https://developers.google.com/season-of-docs/
Maybe this can be a good opportunity to improve the docs (about WKD etc.)
The best part of GSoD is that it is not limited to the students, so
hopefully the quality of the resulting work will be better.


>
> > I think this is suitable task for a GSoC project that can be developed in
> > 2-3 months by a good student, with help and guidance from mentors.
>
> If it would be clear what each option would do, the implementation time
> would
> be enough, but the assumptions of the current interactive command line
> interface and all its bells and whistles are many and interact in a
> complex
> way, so to me it is doubtful that a student can handle this in 3 months.
>

That's why the mentors are needed. This may also be a good reason for
considering the new interface as experimental, which may initially change
frequently.

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

From trevor at yubico.com  Wed Mar 20 18:29:34 2019
From: trevor at yubico.com (Trevor Bentley)
Date: Wed, 20 Mar 2019 18:29:34 +0100
Subject: Invalid keys when switching smartcard from ed25519 to other curves
Message-ID: <1272a787-1830-5cd7-8a89-d28da3456d37@yubico.com>

Hi again,

It appears that once the signature or authentication slot of a smartcard 
has been set to ed25519, if you change it to a different curve and 
generate a key it produces an invalid public key.  The only way to 
recover is to bounce the slot key-attr to RSA and back.

This seems to stem from ask_card_keyattr() in card-util.c.  When coming 
from RSA, it sets `algo` specifically to ECDH or ECDSA, and then calls 
ask_curve() which corrects ECDSA to EDDSA if the curve is ed25519. 
However, if the slot was already EC, it just sets `algo` to whatever it 
already was.  ask_curve() does not correct EDDSA back to ECDSA, so the 
slot permanently reports itself as EDDSA.

When this algo is passed on to scdaemon, it eventually ends up in 
ecc_read_pubkey() in app-openpgp.c.  This function incorrectly thinks 
the ECDSA public key is EDDSA, so it prepends an 0x40 byte on the front. 
  I didn't trace all the way to where it fails, but eventually something 
treats it as ECDSA again and fails.

Thanks,

Trevor


From gnupg-devel at spodhuis.org  Wed Mar 20 17:21:46 2019
From: gnupg-devel at spodhuis.org (Phil Pennock)
Date: Wed, 20 Mar 2019 12:21:46 -0400
Subject: GnuPG 2.2 on elder Debian & Ubuntu distros
In-Reply-To: <201903191203.49127.bernhard@intevation.de>
References: <201903191203.49127.bernhard@intevation.de>
Message-ID: <20190320162145.GA4970@osmium.pennocktech.home.arpa>

On 2019-03-19 at 12:03 +0100, Bernhard Reiter wrote:
> > Thus at <https://public-packages.pennock.tech/> I have packages

> Wanted to try the latest way to test for WKD support
>   gpg-wks-client --supported 
> 
> Noticed that gpg-wkd-client is not packaged?

GnuPG places this into `libexec` rather than `bin` or `sbin`.  I don't
mess with those relative paths.  I preserve the upstream package's idea
of where things should go, rather than distribution guidelines.  Using
an `/opt/` namespace makes this something I'm willing to defend: I
package the upstream with as few changes as possible.

Thus:  /opt/gnupg/libexec/gpg-wks-client

-Phil


From bernhard at intevation.de  Thu Mar 21 09:17:47 2019
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 21 Mar 2019 09:17:47 +0100
Subject: GnuPG 2.2 on elder Debian & Ubuntu distros
In-Reply-To: <20190320162145.GA4970@osmium.pennocktech.home.arpa>
References: <201903191203.49127.bernhard@intevation.de>
 <20190320162145.GA4970@osmium.pennocktech.home.arpa>
Message-ID: <201903210917.51908.bernhard@intevation.de>

Am Mittwoch 20 M?rz 2019 12:22:11 schrieb Daniel Kahn Gillmor:
> What is gpg-wkd-client?  do you mean gpg-wks-client?

Yes, sorry!

Am Mittwoch 20 M?rz 2019 17:21:46 schrieb Phil Pennock:
> GnuPG places this into `libexec` rather than `bin` or `sbin`.  

Werner, is this still the best place? Given that many other binaries are also 
quite low level?

> Thus:  /opt/gnupg/libexec/gpg-wks-client

Thanks for the pointer, I did search for it in the packages, but obviously 
made a mistake!

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/20190321/147e4a89/attachment.sig>

From bernhard at intevation.de  Thu Mar 21 09:31:52 2019
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 21 Mar 2019 09:31:52 +0100
Subject: Improving product summary in announcement (Re: [Announce] GnuPG
 2.2.14 released)
In-Reply-To: <6502004.a1Hr7B418x@esus>
References: <87bm273xye.fsf@wheatstone.g10code.de>
 <201903201028.19394.bernhard@intevation.de> <6502004.a1Hr7B418x@esus>
Message-ID: <201903210931.56872.bernhard@intevation.de>

Hi Andre,

Am Mittwoch 20 M?rz 2019 16:12:46 schrieb Andre Heinecke:
> For this reason I _never_ mention CMS in any user visible string. Even x509
> Certificates are "S/MIME Certificates". Users do "OpenPGP" or they do
> "S/MIME" they have "OpenPGP Keys" or "S/MIME Certificates". I try in my
> work to reduce the distinction in the wording between Keys and
> Certificates.

those are different occasions to me.
If users are exposed to name a technical format, it should be named precisely.
For the rare case that a user wants to dig deeper, the structure can shine 
through, if it must be seen anway.

To me GnuPG is for technicians, as it is - at the essence - a crypto engine.
So in the GnuPG announcement I believe it is good to show the technical 
precision of the product and its crew.

> > What about
> > "The GNU Privacy Guard (GnuPG, GPG) provides a complete and free engine
> >  to implement email and file cryptography by OpenPGP and S/MIME
> > standards."
>
> But you say above that you do not want to complicate things?

A list of more specific words usually make something easier to understand.
 * "implementation" -> "engine" is more specific towards GnuPG
 * "email" and "file" are also more specific and easier to understand.
In this variant there is no "complete implementation" of S/MIME claimed,
only that GnuPG is an engine for S/MIME, so the mention of S/MIME can
be kept.

> Yep it's all not technically correct but we want to provide a good user
> experience and that is not helped by adding confusing "technically correct"
> terms.

If people read the annoucement's first sentence and want to understand it, 
I'll consider it helpful to be correct and clarifying and the same time. My 
hope was that the suggested first variant above, which did not add another 
term, maybe an improvement.

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/20190321/5d444d19/attachment.sig>

From bernhard at intevation.de  Thu Mar 21 09:55:37 2019
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 21 Mar 2019 09:55:37 +0100
Subject: Drawbacks of CLI GUI experimentations and GSoC/D mentoring (was: GSoC
 project idea)
In-Reply-To: <CAMucfLxS=cnz+4xPp2CrLbs4xjs6AQuXueZ3Hc-hcwDpDsOPAQ@mail.gmail.com>
References: <CAMucfLw0y1JGcJhV8o-Da0-GAegfUCb4x1YM9cdLbTnTKJ7YgA@mail.gmail.com>
 <201903191253.35501.bernhard@intevation.de>
 <CAMucfLxS=cnz+4xPp2CrLbs4xjs6AQuXueZ3Hc-hcwDpDsOPAQ@mail.gmail.com>
Message-ID: <201903210955.40796.bernhard@intevation.de>

Hi Dashamir,

Am Mittwoch 20 M?rz 2019 16:17:37 schrieb Dashamir Hoxha:
> On Tue, Mar 19, 2019 at 12:53 PM Bernhard Reiter <bernhard at intevation.de>
> > The main problems I see with the idea:
> > a) How long and by whom would this wrapper be maintained?

> I think that experimentation is worthy too. A wrapper might be easier and
> more flexible if we want to experiment just to get a better feeling about
> the new interface. 

asking the question in isolation I'll personally think a wrapper is better for 
experimentation. And yes, there is value in experimentation. However 
experimenting with something that is unlikely so be ever stable or 
recommendable (because of the unlikeliness of upstream adoption and missing 
long term maintenance perspective) should be very clear to all participants.
To me there is only a small chance that this experiment will lead to useful 
knowledge. There maybe some knowledge gain, but without good chance to get an 
implementation done that actually helps users.

Note that this is just my perspective I don't know how the main GnuPG devs 
think about this.

> By the way, Google Season of Docs is around the corner:
> https://developers.google.com/season-of-docs/
> Maybe this can be a good opportunity to improve the docs (about WKD etc.)
> The best part of GSoD is that it is not limited to the students, so
> hopefully the quality of the resulting work will be better.

Given that it is quite hard to write good documentation, it is almost like 
software engineering, I'll expect the same problems as with GSoC.

> > so to me it is doubtful that a student can handle this in 3 months.

> That's why the mentors are needed. 

The time a well qualified mentor may need to help a student produce a usable 
result can be higher than the time that she would need to implement or write 
the result by herselfs. So Werner could possibly implement what two students 
can do in the time he would need to teach and afterwards correct one students 
work. The justification for this mentor would be to either learn something 
themselfs or to hope that a student sticks around and repays the investment.
Both is not the best path. If you want to learn something else than teaching 
you could again implement this yourself and if we want to find new 
developers, we should seek for people that have a long term interest.

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/20190321/c869e320/attachment.sig>

From bernhard at intevation.de  Thu Mar 21 10:07:23 2019
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 21 Mar 2019 10:07:23 +0100
Subject: Git release tagging best practices
In-Reply-To: <874l7xu3v2.fsf@fifthhorseman.net>
References: <87r2b2u8o9.fsf@fifthhorseman.net>
 <2d2be3d5-17cd-ee71-f5e5-9f17ca4db8e2@digitalbrains.com>
 <874l7xu3v2.fsf@fifthhorseman.net>
Message-ID: <201903211007.38703.bernhard@intevation.de>

Am Mittwoch 20 M?rz 2019 13:28:33 schrieb Daniel Kahn Gillmor:
> I wonder whether we "git tag -v" should raise an error if the tag name
> within the signature doesn't match the tag name being verified.

Here is an interesting writeup, which also compared git and Monotone SCM 
signing features:
 https://www.mercurial-scm.org/wiki/CommitSigningPlan

As I understand it: hg can sign a specific state of the repository, but
this has other drawbacks. It is good to have some competition on distributed 
SCMs. >:)

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/20190321/a9bb42c8/attachment.sig>

From wk at gnupg.org  Thu Mar 21 13:38:16 2019
From: wk at gnupg.org (Werner Koch)
Date: Thu, 21 Mar 2019 13:38:16 +0100
Subject: [PATCH gpa] fix bees typo
In-Reply-To: <afdcb6f6-8eba-555c-a887-b9a41a98dad3@posteo.de> (Christian
 Loehle's message of "Tue, 19 Mar 2019 19:16:00 +0000")
References: <2082bdbd-d3b9-f702-b0e3-2e52ab7ccf5b@posteo.de>
 <afdcb6f6-8eba-555c-a887-b9a41a98dad3@posteo.de>
Message-ID: <87woksz9l3.fsf@wheatstone.g10code.de>

Hi!

Thanks for the fix.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- 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/20190321/88bad7be/attachment.sig>

From aheinecke at gnupg.org  Thu Mar 21 14:47:57 2019
From: aheinecke at gnupg.org (Andre Heinecke)
Date: Thu, 21 Mar 2019 14:47:57 +0100
Subject: Improving product summary in announcement (Re: [Announce] GnuPG
 2.2.14 released)
In-Reply-To: <201903210931.56872.bernhard@intevation.de>
References: <87bm273xye.fsf@wheatstone.g10code.de> <6502004.a1Hr7B418x@esus>
 <201903210931.56872.bernhard@intevation.de>
Message-ID: <1716159.GI4jv1yTzt@esus>

Hi,

On Thursday 21 March 2019 09:31:52 CET Bernhard Reiter wrote:
> Am Mittwoch 20 M?rz 2019 16:12:46 schrieb Andre Heinecke:
> > For this reason I _never_ mention CMS in any user visible string. Even 
x509
> > Certificates are "S/MIME Certificates". Users do "OpenPGP" or they do
> > "S/MIME" they have "OpenPGP Keys" or "S/MIME Certificates". I try in my
> > work to reduce the distinction in the wording between Keys and
> > Certificates.
> 
> those are different occasions to me.
> If users are exposed to name a technical format, it should be named 
precisely.

I disagree with that statement. S/MIME and OpenPGP are the relevant encryption 
standards. No one talks about CMS. This is something implementors know about 
but even the most expert users do not know that "CMS" is a thing.

> For the rare case that a user wants to dig deeper, the structure can shine 
> through, if it must be seen anway.

I think you can dig deeper into how S/MIME works and find out about the 
Cryptographic Message Syntax.

> To me GnuPG is for technicians, as it is - at the essence - a crypto engine.
> So in the GnuPG announcement I believe it is good to show the technical 
> precision of the product and its crew.

I have a strong opinion about the fact that CMS should not be used anywhere 
user visible. Sorry that we disagree here but CMS is just so arbitrary.
To me using CMS is like saying:
I sent you an OpenPGP Message Syntax RFC 2440 combined with MIME Security with 
OpenPGP RFC 3156 to securely send you a mail instead of saying: "I sent you a 
PGP Mail."

> > > What about
> > > "The GNU Privacy Guard (GnuPG, GPG) provides a complete and free engine
> > >  to implement email and file cryptography by OpenPGP and S/MIME
> > > standards."
> >
> > But you say above that you do not want to complicate things?
> 
> A list of more specific words usually make something easier to understand.
>  * "implementation" -> "engine" is more specific towards GnuPG

I respectfully disagree with that. Ok Implementation is not a good word but I 
find engine even worse. I would rather just use "software"

>  * "email" and "file" are also more specific and easier to understand.
> In this variant there is no "complete implementation" of S/MIME claimed,
> only that GnuPG is an engine for S/MIME, so the mention of S/MIME can
> be kept.
> 
> > Yep it's all not technically correct but we want to provide a good user
> > experience and that is not helped by adding confusing "technically 
correct"
> > terms.
> 
> If people read the annoucement's first sentence and want to understand it, 
> I'll consider it helpful to be correct and clarifying and the same time. My 
> hope was that the suggested first variant above, which did not add another 
> term, maybe an improvement.

I also disagree here. GnuPG is very often times used to encrypt just 
"Messages" e.g. if you want as an American to buy Medicine for a reasonable 
price. You do not use GnuPG for email or files you just use it. Why be specific 
if we are just a general crypto engine?

On the back of our T-Shirts we have "The universal crypto engine" In my 
opinion this would be the best caption but this is then too unspecifc.

Best Regards,
Andre

-- 
GnuPG.com - a brand of g10 Code, the GnuPG experts.

g10 Code GmbH, Erkrath/Germany, AG Wuppertal HRB14459
GF Werner Koch, USt-Id DE215605608, www.g10code.com.

GnuPG e.V., Rochusstr. 44, D-40479 D?sseldorf.  VR 11482 D?sseldorf
Vorstand: W.Koch, M.Gollowitzer, A.Heinecke.    Mail: board at gnupg.org
Finanzamt D-Altstadt, St-Nr: 103/5923/1779.   Tel: +49-2104-4938799
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190321/df94f717/attachment-0001.sig>

From aheinecke at gnupg.org  Thu Mar 21 14:52:32 2019
From: aheinecke at gnupg.org (Andre Heinecke)
Date: Thu, 21 Mar 2019 14:52:32 +0100
Subject: GnuPG 2.2 on elder Debian & Ubuntu distros
In-Reply-To: <201903210917.51908.bernhard@intevation.de>
References: <201903191203.49127.bernhard@intevation.de>
 <20190320162145.GA4970@osmium.pennocktech.home.arpa>
 <201903210917.51908.bernhard@intevation.de>
Message-ID: <3329586.M4MoNDqPDm@esus>

Hi,

On Thursday 21 March 2019 09:17:47 CET Bernhard Reiter wrote:
> Werner, is this still the best place? Given that many other binaries are 
also 
> quite low level?

Uhm the libexec thing is on me.
gpg-wks-client and gpg-wks-server were very low level at first and only 
intended to be used by higher level applications. So I found libexec to be the 
right place.

gpg-wks-client gained more usefulness. So I now think that we should install 
it to /usr/bin. I guess we will change that in master for GnuPG 2.3.

On Windows the gpg-wks-client is already installed under bin and in the PATH.


Regards,
Andre

-- 
GnuPG.com - a brand of g10 Code, the GnuPG experts.

g10 Code GmbH, Erkrath/Germany, AG Wuppertal HRB14459
GF Werner Koch, USt-Id DE215605608, www.g10code.com.

GnuPG e.V., Rochusstr. 44, D-40479 D?sseldorf.  VR 11482 D?sseldorf
Vorstand: W.Koch, M.Gollowitzer, A.Heinecke.    Mail: board at gnupg.org
Finanzamt D-Altstadt, St-Nr: 103/5923/1779.   Tel: +49-2104-4938799
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190321/765e3ecc/attachment.sig>

From wk at gnupg.org  Thu Mar 21 19:50:36 2019
From: wk at gnupg.org (Werner Koch)
Date: Thu, 21 Mar 2019 19:50:36 +0100
Subject: Git release tagging best practices
In-Reply-To: <87r2b2u8o9.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message
 of "Tue, 19 Mar 2019 12:32:22 -0400")
References: <87r2b2u8o9.fsf@fifthhorseman.net>
Message-ID: <87lg18yscj.fsf@wheatstone.g10code.de>

On Tue, 19 Mar 2019 12:32, dkg at fifthhorseman.net said:

> commentary and media recommendations included in the git tag messages,
> but i think they aren't currently very useful for downstream verifiers.

:-)

Frankly, I do not know what to write into the tag message because it
does not make sense to me to repeat what we have in NEWS, which is in
the commit named "Release x.y.z".  Maybe I should also change that
commit to read "GnuPG release x.y.z".

>     git tag -s -m 'GnuPG version 2.2.15' gnupg-2.2.15

Will do - and maybe add a fortune(1) to the next line.

> I'm recommending these as best practices, while acknowledging that very
> few projects follow them yet.  I'm hoping that GnuPG can help to lead

I would also wihs that more commits are signed.  With an on-disk key it
does not take any noticeable time, which it does neither when using a
GnuK with an ed25519 key.  You just need to have something like

[user]
      name = "Alica H. Acker"
      email = "ah at example.dev"
      signingkey = C1D34B69219E4AEEC0BA1C21E3FDFF218E45B72B

in ~/.gitconfig and when doing tag signing with a different key you can
resort to

  git tag -u OTHERKEYID -m 'FOO version 1.2.3' foo-1.2.3


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- 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/20190321/b825e638/attachment.sig>

From wk at gnupg.org  Thu Mar 21 19:53:40 2019
From: wk at gnupg.org (Werner Koch)
Date: Thu, 21 Mar 2019 19:53:40 +0100
Subject: Git release tagging best practices
In-Reply-To: <201903211007.38703.bernhard@intevation.de> (Bernhard Reiter's
 message of "Thu, 21 Mar 2019 10:07:23 +0100")
References: <87r2b2u8o9.fsf@fifthhorseman.net>
 <2d2be3d5-17cd-ee71-f5e5-9f17ca4db8e2@digitalbrains.com>
 <874l7xu3v2.fsf@fifthhorseman.net>
 <201903211007.38703.bernhard@intevation.de>
Message-ID: <87h8bwys7f.fsf@wheatstone.g10code.de>

On Thu, 21 Mar 2019 10:07, bernhard at intevation.de said:

> As I understand it: hg can sign a specific state of the repository, but

git can sign all commits (see signingkey keyword for .gitconfig) which
is a signature of the current state.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- 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/20190321/0f849e9d/attachment.sig>

From wk at gnupg.org  Thu Mar 21 20:00:23 2019
From: wk at gnupg.org (Werner Koch)
Date: Thu, 21 Mar 2019 20:00:23 +0100
Subject: Improving product summary in announcement (Re: [Announce] GnuPG
 2.2.14 released)
In-Reply-To: <6502004.a1Hr7B418x@esus> (Andre Heinecke's message of "Wed, 20
 Mar 2019 16:12:46 +0100")
References: <87bm273xye.fsf@wheatstone.g10code.de>
 <201903201028.19394.bernhard@intevation.de> <6502004.a1Hr7B418x@esus>
Message-ID: <87d0mkyrw8.fsf@wheatstone.g10code.de>

On Wed, 20 Mar 2019 16:12, aheinecke at gnupg.org said:

> CMS is for developers. In my experience users do not know it and should not be 

Right and many even don't known the terms, maybe they know pkcs#8 but
the common term is S/MIME.  When I changed the announcement I really
thought what to write and concluded that well known terms are better
than technical abbreviations in a short summary.



Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- 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/20190321/4f8f1a78/attachment.sig>

From James.Bottomley at HansenPartnership.com  Thu Mar 21 22:50:56 2019
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Thu, 21 Mar 2019 14:50:56 -0700
Subject: Git release tagging best practices
In-Reply-To: <874l7xu3v2.fsf@fifthhorseman.net>
References: <87r2b2u8o9.fsf@fifthhorseman.net>
 <2d2be3d5-17cd-ee71-f5e5-9f17ca4db8e2@digitalbrains.com>
 <874l7xu3v2.fsf@fifthhorseman.net>
Message-ID: <1553205056.24235.15.camel@HansenPartnership.com>

On Wed, 2019-03-20 at 08:28 -0400, Daniel Kahn Gillmor wrote:
> On Tue 2019-03-19 19:09:25 +0100, Peter Lebbing wrote:
> > On 19/03/2019 17:32, Daniel Kahn Gillmor wrote:
> > > PS Note that the *name* of the tag itself is not covered by the
> > >    cryptographic signature (it is possible to rename tags without
> > >    modifying their cryptographic validity).  This is why I
> > > recommend
> > >    using the tag message to contain this information rather than
> > > the tag
> > >    name itself.
> > 
> > Are you sure? I looked at what the exact data that is signed is,
> > and it seems to me it does include the name:

It can't.  Remember the name of the tag is metadata which is held in
the git refs file not in the tag itself.  The signature of the tag is
over the contents (including header contents like date and parent)
which doesn't include the name.

This means the name of the tag can be changed by changing the refs file
and actually you can erase the tag with no adverse consequences to the
tree.  What you can't do is move it to a different parent because that
will cause a verification failure.

> That's interesting, thanks for pointing it out.  There are two places
> for the name of the tag, and i think you're right that the signatures
> made by modern git tags do seem to include the tag name (gnupg is
> ahead of the game here, fwiw: many projects don't include the project
> name in their tag name, and just go with tags like v2.2.13, which
> leave the same issue open).  I didn't think that they used to do
> that, but maybe they did and i just never noticed.
> 
> > Note that the third line of the signed data reads "tag gnupg-
> > 2.2.13". So is there some loophole that means this is not useful?
> 
> To test that, i've just pushed https://gitlab.com/dkg/renaming-
> demo.git, where I've just re-named a different tag issued by Werner.
> 
> If you were to clone that repository, you'll note that "git tag -v
> gnupg-2.2.13" returns success, even though the contents of the
> message don't say "tag gnupg-2.2.13".  
> 
> So i suppose it depends on how you think people are verifying that
> tag. I'd imagine most folks (if they verify the tag at all) just
> check that git tag -v $tagname returns 0 (and maybe they check that
> the tag was made by a key that they associate with the project).
> 
> I wonder whether we "git tag -v" should raise an error if the tag
> name within the signature doesn't match the tag name being verified.

Absolutely not, at least not globally.  Remember the design use case
for signed tags is cryptographically verified pull requests, in which
case there is no name and the tag is discarded after the pull.

>   I've just sent message-id: <875zsdu41d.fsf at fifthhorseman.net> to gi
> t at vger.kernel.org to ask about improving the situation there (maybe i
> need to subscribe to convince them to let my mail through, though, i
> don't know).

What you might ask for, if the project locally wanted to add the tag to
the commit and verify it was present, is the same pre- post- -msg hooks
we have for a commit which would allow you to customize on a per-
project basis.

James


> > I'm not saying that the first line of tag messages shouldn't be
> > standardized as you propose, I'm just debating the correctness of
> > the
> > quoted assertion.
> 
> Thanks for the clarifying question, and for pointing this out!
> 
> Regards,
> 
>         --dkg
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190321/62d1c2b0/attachment.sig>

From peter at digitalbrains.com  Fri Mar 22 11:37:49 2019
From: peter at digitalbrains.com (Peter Lebbing)
Date: Fri, 22 Mar 2019 11:37:49 +0100
Subject: Git release tagging best practices
In-Reply-To: <1553205056.24235.15.camel@HansenPartnership.com>
References: <87r2b2u8o9.fsf@fifthhorseman.net>
 <2d2be3d5-17cd-ee71-f5e5-9f17ca4db8e2@digitalbrains.com>
 <874l7xu3v2.fsf@fifthhorseman.net>
 <1553205056.24235.15.camel@HansenPartnership.com>
Message-ID: <a5a130ae-f69d-ec00-8b96-d47f442cb26d@digitalbrains.com>

On 21/03/2019 22:50, James Bottomley wrote:
> It can't.  Remember the name of the tag is metadata which is held in
> the git refs file not in the tag itself.  The signature of the tag is
> over the contents (including header contents like date and parent)
> which doesn't include the name.

The third line of the signed data in the real-life example I
demonstrated reads "tag gnupg-2.2.13". That very much looks like the
name of the tag to me! Did you overlook it or do you think it's
something else?

> This means the name of the tag can be changed by changing the refs file
> and actually you can erase the tag with no adverse consequences to the
> tree.  What you can't do is move it to a different parent because that
> will cause a verification failure.

But Git could check that the name of the file in .git/refs/tags matches
the name in the signed data.

> Absolutely not, at least not globally.  Remember the design use case
> for signed tags is cryptographically verified pull requests, in which
> case there is no name and the tag is discarded after the pull.

I'd rather say "a use case" than "the use case", but okay.

It could easily support both. I don't recognise the use case you
describe, but I presume when you say "there is no name", that the tag is
used through its object hash. Git could skip verifying the name when the
tag is specified through its object hash rather than its name.  And if
this is not what you meant, Git could gain a command line option to have
it enforce the name is original, or an option to indicate the name
should not be verified.

Discarding is not a problem.

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/20190322/cd803b4f/attachment-0001.sig>

From peter at digitalbrains.com  Fri Mar 22 11:49:30 2019
From: peter at digitalbrains.com (Peter Lebbing)
Date: Fri, 22 Mar 2019 11:49:30 +0100
Subject: Git release tagging best practices
In-Reply-To: <a5a130ae-f69d-ec00-8b96-d47f442cb26d@digitalbrains.com>
References: <87r2b2u8o9.fsf@fifthhorseman.net>
 <2d2be3d5-17cd-ee71-f5e5-9f17ca4db8e2@digitalbrains.com>
 <874l7xu3v2.fsf@fifthhorseman.net>
 <1553205056.24235.15.camel@HansenPartnership.com>
 <a5a130ae-f69d-ec00-8b96-d47f442cb26d@digitalbrains.com>
Message-ID: <6cefaf25-e6c0-bf1c-c8cd-2d28f7d80c68@digitalbrains.com>

I just found the thread on git at vger.kernel.org, I couldn't before (that
user interface at marc.info is not one I like, I just tried
spinics.net).

It seems to cover the subject quite well, I propose we don't do a weak
substitute here.

I should have done this the other way round: decide that is the better
place, and then not answer as I did just now.

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/20190322/7a1bc008/attachment.sig>

From dashohoxha at gmail.com  Fri Mar 22 13:54:24 2019
From: dashohoxha at gmail.com (Dashamir Hoxha)
Date: Fri, 22 Mar 2019 13:54:24 +0100
Subject: Drawbacks of CLI GUI experimentations and GSoC/D mentoring (was:
 GSoC project idea)
In-Reply-To: <201903210955.40796.bernhard@intevation.de>
References: <CAMucfLw0y1JGcJhV8o-Da0-GAegfUCb4x1YM9cdLbTnTKJ7YgA@mail.gmail.com>
 <201903191253.35501.bernhard@intevation.de>
 <CAMucfLxS=cnz+4xPp2CrLbs4xjs6AQuXueZ3Hc-hcwDpDsOPAQ@mail.gmail.com>
 <201903210955.40796.bernhard@intevation.de>
Message-ID: <CAMucfLyvEf46P=T6cFDcnte6yh=4rFh-B=H_vepC-wpw8-ytEA@mail.gmail.com>

On Thu, Mar 21, 2019 at 9:56 AM Bernhard Reiter <bernhard at intevation.de>
wrote:

> Hi Dashamir,
>
> Am Mittwoch 20 M?rz 2019 16:17:37 schrieb Dashamir Hoxha:
> > On Tue, Mar 19, 2019 at 12:53 PM Bernhard Reiter <bernhard at intevation.de
> >
> > > The main problems I see with the idea:
> > > a) How long and by whom would this wrapper be maintained?
>
> > I think that experimentation is worthy too. A wrapper might be easier and
> > more flexible if we want to experiment just to get a better feeling about
> > the new interface.
>
> asking the question in isolation I'll personally think a wrapper is better
> for
> experimentation. And yes, there is value in experimentation. However
> experimenting with something that is unlikely so be ever stable or
> recommendable (because of the unlikeliness of upstream adoption and
> missing
> long term maintenance perspective) should be very clear to all
> participants.
>

I agree.


> To me there is only a small chance that this experiment will lead to
> useful
> knowledge. There maybe some knowledge gain, but without good chance to get
> an
> implementation done that actually helps users.
>

I still think it is worth to give it try as a GSoC project, provided there
are interested mentors and at least one interested student. The mentors
don't have to be developers, they can also be experienced gpg users. The
work done by the student during GSoC does not have to be integrated to the
main project, it is completely fine to throw it away even if the summer
project itself is considered successful.


>
> Note that this is just my perspective I don't know how the main GnuPG devs
> think about this.
>
> > By the way, Google Season of Docs is around the corner:
> > https://developers.google.com/season-of-docs/
> > Maybe this can be a good opportunity to improve the docs (about WKD etc.)
> > The best part of GSoD is that it is not limited to the students, so
> > hopefully the quality of the resulting work will be better.
>
> Given that it is quite hard to write good documentation, it is almost like
> software engineering, I'll expect the same problems as with GSoC.
>

The difference is that the people that you select for the GSoD project do
not have to be students, they can actually be software engineers. It is
like you are hiring a contractor for 3 months but the bill is payed by
Google (if you are satisfied with his job). You can also hire people from
the community who are already working voluntarily on that (documentation)
project.


>
> > > so to me it is doubtful that a student can handle this in 3 months.
>
> > That's why the mentors are needed.
>
> The time a well qualified mentor may need to help a student produce a
> usable
> result can be higher than the time that she would need to implement or
> write
> the result by herselfs. So Werner could possibly implement what two
> students
> can do in the time he would need to teach and afterwards correct one
> students
> work. The justification for this mentor would be to either learn something
> themselfs or to hope that a student sticks around and repays the
> investment.
> Both is not the best path. If you want to learn something else than
> teaching
> you could again implement this yourself and if we want to find new
> developers, we should seek for people that have a long term interest.
>

That is completely true. Only a long term interest may make the effort
worthy for a mentor.
But as I mentioned above, the mentor does not have to be Werner, and there
could be more than one mentors (per project). Actually there should be more
than one mentor, it is a recommended practice, and some organizations even
require that there are at least two mentors per project (for obvious
reasons).

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

From James.Bottomley at HansenPartnership.com  Fri Mar 22 17:50:08 2019
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Fri, 22 Mar 2019 09:50:08 -0700
Subject: Git release tagging best practices
In-Reply-To: <a5a130ae-f69d-ec00-8b96-d47f442cb26d@digitalbrains.com>
References: <87r2b2u8o9.fsf@fifthhorseman.net>
 <2d2be3d5-17cd-ee71-f5e5-9f17ca4db8e2@digitalbrains.com>
 <874l7xu3v2.fsf@fifthhorseman.net>
 <1553205056.24235.15.camel@HansenPartnership.com>
 <a5a130ae-f69d-ec00-8b96-d47f442cb26d@digitalbrains.com>
Message-ID: <1553273408.2799.50.camel@HansenPartnership.com>

On Fri, 2019-03-22 at 11:37 +0100, Peter Lebbing wrote:
> On 21/03/2019 22:50, James Bottomley wrote:
> > It can't.  Remember the name of the tag is metadata which is held
> > in the git refs file not in the tag itself.  The signature of the
> > tag is over the contents (including header contents like date and
> > parent) which doesn't include the name.
> 
> The third line of the signed data in the real-life example I
> demonstrated reads "tag gnupg-2.2.13". That very much looks like the
> name of the tag to me! Did you overlook it or do you think it's
> something else?

Ah, actually, I hadn't noticed that was in there.

> > This means the name of the tag can be changed by changing the refs
> > file and actually you can erase the tag with no adverse
> > consequences to the tree.  What you can't do is move it to a
> > different parent because that will cause a verification failure.
> 
> But Git could check that the name of the file in .git/refs/tags
> matches the name in the signed data.

So that's related to use case, see below.

> > Absolutely not, at least not globally.  Remember the design use
> > case for signed tags is cryptographically verified pull requests,
> > in which case there is no name and the tag is discarded after the
> > pull.
> 
> I'd rather say "a use case" than "the use case", but okay.

The point is it's the use case signed tags were designed for.  It's
what all the cryptographic validation thought around signed tags went
into.

> It could easily support both. I don't recognise the use case you
> describe, but I presume when you say "there is no name", that the tag
> is used through its object hash. Git could skip verifying the name
> when the tag is specified through its object hash rather than its
> name.

When you do git pull remote-tree remote-tag

Git will validate the remote-tag cryptographically and its attachment
point but, because the tag will be discarded after the merge, it
doesn't validate the remote-tag matches the tag name.  It's how Linus
ensures cryptographically that what he pulls is what I pushed.

in this workflow the references file is on the remote tree, and the tag
won't become part of the local tree.  You could validate that remote-
tag, which will be taken from the remote tree references, matches the
tag name in the signed object but it has no value because the signed
part of the tag is merged into the commit object wholesale, so the
signature can still be verified, but the actual tag itself doesn't
become part of the local tree and is effectively discarded.

You can see this if you do a git log <sha> on a merge pull in the
kernel vs a git cat-file commit <sha>.

>   And if this is not what you meant, Git could gain a command line
> option to have it enforce the name is original, or an option to
> indicate the name should not be verified.

OK, but verify for what?  git-log <tag> probably.  git-archive <tag>
definitely but you need to identify the other commands and use cases. 
Cryptographic verification of every tag on all operations would be way
too expensive.

James


> Discarding is not a problem.
> 
> Cheers,
> 
> Peter.
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190322/be8fae56/attachment.sig>

From dkg at fifthhorseman.net  Fri Mar 22 04:12:07 2019
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 21 Mar 2019 23:12:07 -0400
Subject: Git release tagging best practices
In-Reply-To: <1553205056.24235.15.camel@HansenPartnership.com>
References: <87r2b2u8o9.fsf@fifthhorseman.net>
 <2d2be3d5-17cd-ee71-f5e5-9f17ca4db8e2@digitalbrains.com>
 <874l7xu3v2.fsf@fifthhorseman.net>
 <1553205056.24235.15.camel@HansenPartnership.com>
Message-ID: <87o963mwl4.fsf@fifthhorseman.net>

On Thu 2019-03-21 14:50:56 -0700, James Bottomley wrote:
> It can't.  Remember the name of the tag is metadata which is held in
> the git refs file not in the tag itself.  The signature of the tag is
> over the contents (including header contents like date and parent)
> which doesn't include the name.

Did you look at Peter's message?  Werner's signature over git tag
gnupg-2.2.15 does indeed include "tag gnupg-2.2.15".

> Absolutely not, at least not globally.  Remember the design use case
> for signed tags is cryptographically verified pull requests, in which
> case there is no name and the tag is discarded after the pull.

That sounds more like "push certificates" than signed tags to me, but
i'm not up on the details of push certificates, so i might be wrong
about that.

      --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/20190321/b353797d/attachment-0001.sig>

From tmz at pobox.com  Fri Mar 22 17:19:41 2019
From: tmz at pobox.com (Todd Zullinger)
Date: Fri, 22 Mar 2019 12:19:41 -0400
Subject: Git release tagging best practices
In-Reply-To: <6cefaf25-e6c0-bf1c-c8cd-2d28f7d80c68@digitalbrains.com>
References: <87r2b2u8o9.fsf@fifthhorseman.net>
 <2d2be3d5-17cd-ee71-f5e5-9f17ca4db8e2@digitalbrains.com>
 <874l7xu3v2.fsf@fifthhorseman.net>
 <1553205056.24235.15.camel@HansenPartnership.com>
 <a5a130ae-f69d-ec00-8b96-d47f442cb26d@digitalbrains.com>
 <6cefaf25-e6c0-bf1c-c8cd-2d28f7d80c68@digitalbrains.com>
Message-ID: <20190322161941.GH4047@pobox.com>

Hi,

Peter Lebbing wrote:
> I just found the thread on git at vger.kernel.org, I couldn't before (that
> user interface at marc.info is not one I like, I just tried
> spinics.net).

Another alternative is https://public-inbox.org/git/ which
is recommended in the git README.md.

The public-inbox.org git list archives there are clonable
via git too (not that you'd want or need to do that for a
simpler search, but it's a nice feature).

-- 
Todd


From peter at digitalbrains.com  Fri Mar 22 20:37:35 2019
From: peter at digitalbrains.com (Peter Lebbing)
Date: Fri, 22 Mar 2019 20:37:35 +0100
Subject: Git release tagging best practices
In-Reply-To: <1553273408.2799.50.camel@HansenPartnership.com>
References: <87r2b2u8o9.fsf@fifthhorseman.net>
 <2d2be3d5-17cd-ee71-f5e5-9f17ca4db8e2@digitalbrains.com>
 <874l7xu3v2.fsf@fifthhorseman.net>
 <1553205056.24235.15.camel@HansenPartnership.com>
 <a5a130ae-f69d-ec00-8b96-d47f442cb26d@digitalbrains.com>
 <1553273408.2799.50.camel@HansenPartnership.com>
Message-ID: <356138cf-bb11-10d6-9d9b-449bbc410b5c@digitalbrains.com>

Hello James,

I really think that the git at vger.kernel.org list is the better place to
provide useful input, given that this discussion is also running there
currently. Holding a parallel discussion here is highly inefficient.

Personally, I don't have anything worthwhile to add to that discussion
over there. I see multiple viewpoints expressed, but all of them are
pretty well informed, nothing I can currently think of would enlighten
the minds there.

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/20190322/89b96f93/attachment.sig>

From dkg at fifthhorseman.net  Sat Mar 23 23:13:30 2019
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Sat, 23 Mar 2019 23:13:30 +0100
Subject: [openpgp] Deprecating compression support
In-Reply-To: <20190323170723.GC1497@zeromail.org>
References: <CAKUk3bvBWoh9jz+T6t5yGs-P-P4cSg8AnSo_md3OFnzqVN-3=A@mail.gmail.com>
 <871s3475dy.fsf@europa.jade-hamburg.de>
 <96055353-B0EB-4E25-95CC-B25D9C5A0BA8@icloud.com>
 <2RAT852LYMAQD.3U70IQJPU0VPO@my.amazin.horse>
 <0092256D-94EB-4FE5-9560-FEB0B8E3769E@icloud.com>
 <20190323170723.GC1497@zeromail.org>
Message-ID: <87imw9jl2t.fsf@fifthhorseman.net>

On Sat 2019-03-23 18:07:23 +0100, ilf wrote:
> So can we change GnuPG to default-preference Uncompressed?

[ switching this implementation-specific message to
  gnupg-devel at gnupg.org, please respect Mail-Followup-To: ]

The current implementation of GnuPG creates OpenPGP certificates with
this preference listing:

     Compression: ZLIB, BZIP2, ZIP, Uncompressed

Are you suggesting that we change it to:

     Compression: Uncompressed, ZLIB, BZIP2, ZIP

or to:

     Compression: Uncompressed

?

Setting aside the question of defaults, for your own OpenPGP certificate
right now you can do this with any modern version of GnuPG, if you're
willing to poke at the command line with some arcana:

For the less severe change:

    gpg --edit-key $FINGERPRINT showpref 'setpref S9 S8 S7 S2 H10 H9 H8 H11 H2 Z0 Z2 Z3 Z1'  save

For the more severe change:

    gpg --edit-key $FINGERPRINT showpref 'setpref S9 S8 S7 S2 H10 H9 H8 H11 H2 Z0' save

then of course you'll need to re-publish the cert via whatever your
standard publication mechanism is (keyservers, WKD, keybase, etc).

        --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/20190323/4fa9602e/attachment.sig>

From ilf at zeromail.org  Sun Mar 24 17:20:58 2019
From: ilf at zeromail.org (ilf)
Date: Sun, 24 Mar 2019 17:20:58 +0100
Subject: [openpgp] Deprecating compression support
In-Reply-To: <87imw9jl2t.fsf@fifthhorseman.net>
References: <CAKUk3bvBWoh9jz+T6t5yGs-P-P4cSg8AnSo_md3OFnzqVN-3=A@mail.gmail.com>
 <871s3475dy.fsf@europa.jade-hamburg.de>
 <96055353-B0EB-4E25-95CC-B25D9C5A0BA8@icloud.com>
 <2RAT852LYMAQD.3U70IQJPU0VPO@my.amazin.horse>
 <0092256D-94EB-4FE5-9560-FEB0B8E3769E@icloud.com>
 <20190323170723.GC1497@zeromail.org>
 <87imw9jl2t.fsf@fifthhorseman.net>
Message-ID: <20190324162058.GA1238@zeromail.org>

Daniel Kahn Gillmor:
> Are you suggesting that we change it to:
>     Compression: Uncompressed, ZLIB, BZIP2, ZIP 
> or to:
>     Compression: Uncompressed 
> ?

There seems to be rough consensus on openpgp at ietf.org to phase out 
compression, except for backwards compatibility reasons - so proposal #1 
should be fine with everyone.

Proposal #2 is more in line with the original proposal by Justus, 
Vincent an Neal - and the counter-arguments were not against changing 
the defaults for new keys but having to keep compression in 
implementations.

So GnuPG development comunity: Would you be fine in changing the default 
for new keys to "Compression: Uncompressed"?

-- 
ilf

If you upload your address book to "the cloud", I don't want to be in it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190324/4d801b78/attachment.sig>

From lechten at wi.uni-muenster.de  Mon Mar 25 10:42:52 2019
From: lechten at wi.uni-muenster.de (Jens Lechtenboerger)
Date: Mon, 25 Mar 2019 10:42:52 +0100
Subject: gpgsm: Cannot decrypt with expired certificate for CRL
Message-ID: <87sgvbmgrn.fsf@wi.uni-muenster.de>

Hi there,

I?m using gpgsm (GnuPG) 2.2.13.  For some reason, a CRL obtained by
dirmngr is signed with an expired certificate.  This prevents me
from using my certificate.  Here is what happens when I try to decrypt:

$ gpgsm -d mail.p7m
gpgsm: Note: non-critical certificate policy not allowed
gpgsm: certificate #1C7CAD9DED77429D3CA98D1D/1.2.840.113549.1.9.1=#636140756E692D6D75656E737465722E6465,CN=Zertifizierungsstelle Universitaet Muenster - G02,O=Universitaet Muenster,C=DE
gpgsm: checking the CRL failed: Certificate expired
gpgsm: can't sign using '5E:A8:6C:19:99:8E:43:CC:CF:BB:1C:0E:35:07:FF:F6:F2:BA:3C:26': Certificate expired
gpgsm: Note: non-critical certificate policy not allowed
gpgsm: certificate #1C7CAD9DED77429D3CA98D1D/1.2.840.113549.1.9.1=#636140756E692D6D75656E737465722E6465,CN=Zertifizierungsstelle Universitaet Muenster - G02,O=Universitaet Muenster,C=DE
gpgsm: checking the CRL failed: Certificate expired
gpgsm: Note: won't be able to encrypt to '5E:A8:6C:19:99:8E:43:CC:CF:BB:1C:0E:35:07:FF:F6:F2:BA:3C:26': Certificate expired

Yes, CRLs should not be signed with expired certificates.  However,
is the fact that gpgsm prevents me from using my certificate a bug
or a feature?

As workaround I now have disable-crl-checks in my gpgsm.conf.

Should I file a bug report?

Best wishes
Jens


From lechten at wi.uni-muenster.de  Mon Mar 25 14:30:23 2019
From: lechten at wi.uni-muenster.de (Jens Lechtenboerger)
Date: Mon, 25 Mar 2019 14:30:23 +0100
Subject: gpgsm: Cannot decrypt with expired certificate for CRL
In-Reply-To: <87sgvbmgrn.fsf@wi.uni-muenster.de> (Jens Lechtenboerger's
 message of "Mon, 25 Mar 2019 10:42:52 +0100")
References: <87sgvbmgrn.fsf@wi.uni-muenster.de>
Message-ID: <87k1gnm68g.fsf@wi.uni-muenster.de>

On 2019-03-25, Jens Lechtenboerger wrote:

> Hi there,
>
> I?m using gpgsm (GnuPG) 2.2.13.  For some reason, a CRL obtained by
> dirmngr is signed with an expired certificate.

I need to correct myself after feedback from our Certificate
Authority: The CRL was not signed with an expired certificate but
with a valid certificate that happens to share the keygrip (Subject
Key Identifier) with an expired one.  The lookup by dirmngr lead to
the expired certificate, while also a valid certificate exists.

> [...]
> Yes, CRLs should not be signed with expired certificates.  However,
> is the fact that gpgsm prevents me from using my certificate a bug
> or a feature?
>
> As workaround I now have disable-crl-checks in my gpgsm.conf.
>
> Should I file a bug report?

Best wishes
Jens


From trevor at yubico.com  Mon Mar 25 15:19:47 2019
From: trevor at yubico.com (Trevor Bentley)
Date: Mon, 25 Mar 2019 15:19:47 +0100
Subject: Invalid keys when switching smartcard from ed25519 to other curves
In-Reply-To: <1272a787-1830-5cd7-8a89-d28da3456d37@yubico.com>
References: <1272a787-1830-5cd7-8a89-d28da3456d37@yubico.com>
Message-ID: <2de68052-5392-8e7d-cbc4-2a6eca46082d@yubico.com>

Just want to follow up on this again and see if anybody has any 
opinions.  I have included a small patch to fix it:


-- >8 --
Subject: [PATCH] gpg: Don't use EdDSA algo ID for ECDSA curves.

* g10/keygen.c (ask_curve): Change algo ID to ECDSA if it changed from
an EdDSA curve.
---

Fixes a bug that causes a slot to get stuck reporting itself as EdDSA
when the curve has changed to ECDSA.  If a smartcard did not override
the algo that gpg sent it, gpg would get confused about an ECDSA curve
with an EdDSA algo ID, and would generate invalid public keys.
---
  g10/keygen.c | 25 ++++++++++++++++++-------
  1 file changed, 18 insertions(+), 7 deletions(-)

diff --git a/g10/keygen.c b/g10/keygen.c
index 64fefd231..943b40110 100644
--- a/g10/keygen.c
+++ b/g10/keygen.c
@@ -2507,14 +2507,25 @@ ask_curve (int *algo, int *subkey_algo, const 
char *current)
        else
          {
            /* If the user selected a signing algorithm and Curve25519
-             we need to set the algo to EdDSA and update the curve name. */
-          if ((*algo == PUBKEY_ALGO_ECDSA || *algo == PUBKEY_ALGO_EDDSA)
-              && curves[idx].eddsa_curve)
+             we need to set the algo to EdDSA and update the curve name.
+             If switching away from EdDSA, we need to set the algo back
+             to ECDSA. */
+          if (*algo == PUBKEY_ALGO_ECDSA || *algo == PUBKEY_ALGO_EDDSA)
              {
-              if (subkey_algo && *subkey_algo == PUBKEY_ALGO_ECDSA)
-                *subkey_algo = PUBKEY_ALGO_EDDSA;
-              *algo = PUBKEY_ALGO_EDDSA;
-              result = curves[idx].eddsa_curve;
+              if (curves[idx].eddsa_curve)
+                {
+                  if (subkey_algo && *subkey_algo == PUBKEY_ALGO_ECDSA)
+                    *subkey_algo = PUBKEY_ALGO_EDDSA;
+                  *algo = PUBKEY_ALGO_EDDSA;
+                  result = curves[idx].eddsa_curve;
+                }
+              else
+                {
+                  if (subkey_algo && *subkey_algo == PUBKEY_ALGO_EDDSA)
+                    *subkey_algo = PUBKEY_ALGO_ECDSA;
+                  *algo = PUBKEY_ALGO_ECDSA;
+                  result = curves[idx].name;
+                }
              }
            else
              result = curves[idx].name;
--
2.20.1


From rainer.perske at uni-muenster.de  Mon Mar 25 16:41:01 2019
From: rainer.perske at uni-muenster.de (Rainer Perske)
Date: Mon, 25 Mar 2019 16:41:01 +0100 (CET)
Subject: gpgsm: Cannot decrypt with expired certificate for CRL
In-Reply-To: <87k1gnm68g.fsf@wi.uni-muenster.de>
Message-ID: <permail-2019032515410105be2aed0000594b-perske@message-id.uni-muenster.de>

Hello, everyone,

the problem reported by Jens Lechtenboerger is solved:

In this special case my patch that was added to GnuPG 2.2.2, see 
<https://dev.gnupg.org/T1644>, did not help because his keyring 
contained only the old, revoked certificate and not the new, unrevoked 
one. So my patch could not select the newer certificate.

The specific problem with multiple CA certificates with the same key in 
the "old" DFN PKI "Global" hierarchy will disappear on July 9th 23:59 
UTC because then the root certificate expires.

The general problem that GnuPG has problems handling multiple 
certificates with the same key persists (see T1644) , but fixing this 
would require a major effort for a quite rare edge case.

Best greetings
-- 
Rainer Perske
Abteilung Systembetrieb und Leiter der Zertifizierungsstelle (WWUCA)
Zentrum f?r Informationsverarbeitung (Universit?tsrechenzentrum)

Westf?lische Wilhelms-Universit?t
Zentrum f?r Informationsverarbeitung
Rainer Perske
R?ntgenstra?e 7-13
48149 M?nster

Tel.: +49 251 83-31582
Fax.: +49 251 83-31555
E-Mail: rainer.perske at uni-muenster.de
WWW: https://www.uni-muenster.de/ZIV/Mitarbeiter/RainerPerske.shtml
B?ro: Raum 006, R?ntgenstra?e 11
Lageplan: http://wwwuv2.uni-muenster.de/uniplan/?action=spot&gebnr=7474

Zertifizierungsstelle der Universit?t M?nster (WWUCA):
Tel.: +49 251 83-31590
Fax.: +49 251 83-31555
E-Mail: ca at uni-muenster.de
WWW: https://www.uni-muenster.de/WWUCA/

Zentrum f?r Informationsverarbeitung (ZIV):
Tel.: +49 251 83-31600 (Mo-Fr 7:30-17:30 Uhr)
Fax.: +49 251 83-31555
E-Mail: ziv at uni-muenster.de
WWW: https://www.uni-muenster.de/ZIV/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6807 bytes
Desc: S/MIME cryptographic signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190325/e2e9634f/attachment.bin>

From peter at digitalbrains.com  Mon Mar 25 19:25:44 2019
From: peter at digitalbrains.com (Peter Lebbing)
Date: Mon, 25 Mar 2019 19:25:44 +0100
Subject: gpgsm: Cannot decrypt with expired certificate for CRL
In-Reply-To: <permail-2019032515410105be2aed0000594b-perske@message-id.uni-muenster.de>
References: <permail-2019032515410105be2aed0000594b-perske@message-id.uni-muenster.de>
Message-ID: <04b61bb4-5e0a-d1c1-46be-a8e257d433a5@digitalbrains.com>

On 25/03/2019 16:41, Rainer Perske wrote:
> the problem reported by Jens Lechtenboerger is solved:

But... shouldn't it always be possible to /decrypt/, no matter the
revocation status or expiry or whatnot?

I can understand a certificate being skipped to /encrypt/ to, but it
seems rather drastical to prevent reading any mail encrypted to that key
and stuff like that.

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/20190325/5960b630/attachment.sig>

From aheinecke at gnupg.org  Tue Mar 26 07:52:02 2019
From: aheinecke at gnupg.org (Andre Heinecke)
Date: Tue, 26 Mar 2019 07:52:02 +0100
Subject: gpgsm: Cannot decrypt with expired certificate for CRL
In-Reply-To: <87sgvbmgrn.fsf@wi.uni-muenster.de>
References: <87sgvbmgrn.fsf@wi.uni-muenster.de>
Message-ID: <9196712.fDa3IXLbjv@esus>

Hi,

On Monday 25 March 2019 10:42:52 CET Jens Lechtenboerger wrote:
> Yes, CRLs should not be signed with expired certificates.  However,
> is the fact that gpgsm prevents me from using my certificate a bug
> or a feature?

For decrypt I would say: It's a bug. You should always be able to decrypt 
something for which you have the secret key IMO.

> As workaround I now have disable-crl-checks in my gpgsm.conf.
> 
> Should I file a bug report?

Yes please. Ideally with an example certificate chain + test cert attached :-)

Thanks,
Andre

-- 
GnuPG.com - a brand of g10 Code, the GnuPG experts.

g10 Code GmbH, Erkrath/Germany, AG Wuppertal HRB14459
GF Werner Koch, USt-Id DE215605608, www.g10code.com.

GnuPG e.V., Rochusstr. 44, D-40479 D?sseldorf.  VR 11482 D?sseldorf
Vorstand: W.Koch, M.Gollowitzer, A.Heinecke.    Mail: board at gnupg.org
Finanzamt D-Altstadt, St-Nr: 103/5923/1779.   Tel: +49-2104-4938799
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190326/64d2a408/attachment.sig>

From gniibe at fsij.org  Tue Mar 26 08:37:40 2019
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Tue, 26 Mar 2019 16:37:40 +0900
Subject: Invalid keys when switching smartcard from ed25519 to other curves
In-Reply-To: <2de68052-5392-8e7d-cbc4-2a6eca46082d@yubico.com>
References: <1272a787-1830-5cd7-8a89-d28da3456d37@yubico.com>
 <2de68052-5392-8e7d-cbc4-2a6eca46082d@yubico.com>
Message-ID: <87h8bq13y3.fsf@c720>

Trevor Bentley wrote:
> Just want to follow up on this again and see if anybody has any 
> opinions.  I have included a small patch to fix it:

I see the problem.  I think that it is the call of ask_curve from
ask_card_keyattr in card-util.c.  Isn't it?

(Looking your patch with the context of keygen.c, I didn't understand
why ask_curve matters.)

I'll apply your patch.
-- 


From trevor at yubico.com  Tue Mar 26 09:05:36 2019
From: trevor at yubico.com (Trevor Bentley)
Date: Tue, 26 Mar 2019 09:05:36 +0100
Subject: Invalid keys when switching smartcard from ed25519 to other curves
In-Reply-To: <87h8bq13y3.fsf@c720>
References: <1272a787-1830-5cd7-8a89-d28da3456d37@yubico.com>
 <2de68052-5392-8e7d-cbc4-2a6eca46082d@yubico.com> <87h8bq13y3.fsf@c720>
Message-ID: <cd788592-c15e-e937-5ae8-77f0eb8b221f@yubico.com>

> I see the problem.  I think that it is the call of ask_curve from
> ask_card_keyattr in card-util.c.  Isn't it?
> 
> (Looking your patch with the context of keygen.c, I didn't understand
> why ask_curve matters.)

Yes, exactly, it's the call in ask_card_keyattr() that is a problem.  It 
gets 'stuck' on the EdDSA algo ID when it passes in the current curve 
parameters.

Thanks,

Trevor


From wk at gnupg.org  Tue Mar 26 09:28:19 2019
From: wk at gnupg.org (Werner Koch)
Date: Tue, 26 Mar 2019 09:28:19 +0100
Subject: [openpgp] Deprecating compression support
In-Reply-To: <20190324162058.GA1238@zeromail.org> (ilf's message of "Sun, 24
 Mar 2019 17:20:58 +0100")
References: <CAKUk3bvBWoh9jz+T6t5yGs-P-P4cSg8AnSo_md3OFnzqVN-3=A@mail.gmail.com>
 <871s3475dy.fsf@europa.jade-hamburg.de>
 <96055353-B0EB-4E25-95CC-B25D9C5A0BA8@icloud.com>
 <2RAT852LYMAQD.3U70IQJPU0VPO@my.amazin.horse>
 <0092256D-94EB-4FE5-9560-FEB0B8E3769E@icloud.com>
 <20190323170723.GC1497@zeromail.org>
 <87imw9jl2t.fsf@fifthhorseman.net>
 <20190324162058.GA1238@zeromail.org>
Message-ID: <87o95yujj0.fsf@wheatstone.g10code.de>

On Sun, 24 Mar 2019 17:20, ilf at zeromail.org said:

> So GnuPG development comunity: Would you be fine in changing the
> default for new keys to "Compression: Uncompressed"?

That is easy to answer: No.

Removing that feature would break major use cases and deployed
infrastructure.  The build in compression support in OpenPGP is actually
a selling point over S/MIME.  This can also not be done with a switch to
a new key or key format because key management is independent from
actual use.  Please remember that OpenPGP is not only used for mail.

As indicated in the WG I am in favor of fading out bzip2 support on the
ground that its introduction was controversial from the eginnging.  Its
presense has been used to try to get xz in, and that the benefits for
plain text compression (e.g. for xml) with bzip2 over zlib is not that
big when considering overall resource use.

Those who do not want to have compression, please specify that in your
keys.  MUA authors may pass "-z0" or GPGME_ENCRYPT_NO_COMPRESS to
disable encryption.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- 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/20190326/4cc5c950/attachment.sig>

From wk at gnupg.org  Tue Mar 26 09:42:57 2019
From: wk at gnupg.org (Werner Koch)
Date: Tue, 26 Mar 2019 09:42:57 +0100
Subject: Git release tagging best practices
In-Reply-To: <87o963mwl4.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message
 of "Thu, 21 Mar 2019 23:12:07 -0400")
References: <87r2b2u8o9.fsf@fifthhorseman.net>
 <2d2be3d5-17cd-ee71-f5e5-9f17ca4db8e2@digitalbrains.com>
 <874l7xu3v2.fsf@fifthhorseman.net>
 <1553205056.24235.15.camel@HansenPartnership.com>
 <87o963mwl4.fsf@fifthhorseman.net>
Message-ID: <87k1gmuium.fsf@wheatstone.g10code.de>

On Thu, 21 Mar 2019 23:12, dkg at fifthhorseman.net said:

> Did you look at Peter's message?  Werner's signature over git tag
> gnupg-2.2.15 does indeed include "tag gnupg-2.2.15".

Being curious, I also checked this:

--8<---------------cut here---------------start------------->8---
$ git tag -v gnupg-2.2.14
object 813de13e73b01409fabff9859f24c4f23b808796
type commit
tag gnupg-2.2.14
tagger Werner Koch <wk at gnupg.org> 1552991853 +0100

Just another boring release
[...]
gpg: enabled debug flags: hashing
gpg: Signature made Tue Mar 19 11:37:33 2019 CET
gpg:                using RSA key D8692123C4065DEA5E0F3AB5249B39D24F25E3B6
gpg: Good signature from "Werner Koch (dist sig)" [ultimate]
--8<---------------cut here---------------end--------------->8---

And here is the actual hashed data:

--8<---------------cut here---------------start------------->8---
00000000  6f 62 6a 65 63 74 20 38  31 33 64 65 31 33 65 37  |object 813de13e7|
00000010  33 62 30 31 34 30 39 66  61 62 66 66 39 38 35 39  |3b01409fabff9859|
00000020  66 32 34 63 34 66 32 33  62 38 30 38 37 39 36 0a  |f24c4f23b808796.|
00000030  74 79 70 65 20 63 6f 6d  6d 69 74 0a 74 61 67 20  |type commit.tag |
00000040  67 6e 75 70 67 2d 32 2e  32 2e 31 34 0a 74 61 67  |gnupg-2.2.14.tag|
00000050  67 65 72 20 57 65 72 6e  65 72 20 4b 6f 63 68 20  |ger Werner Koch |
00000060  3c 77 6b 40 67 6e 75 70  67 2e 6f 72 67 3e 20 31  |<wk at gnupg.org> 1|
00000070  35 35 32 39 39 31 38 35  33 20 2b 30 31 30 30 0a  |552991853 +0100.|
00000080  0a 4a 75 73 74 20 61 6e  6f 74 68 65 72 20 62 6f  |.Just another bo|
00000090  72 69 6e 67 20 72 65 6c  65 61 73 65 0a 04 00 01  |ring release....|
000000a0  08 00 1d 16 21 04 d8 69  21 23 c4 06 5d ea 5e 0f  |....!..i!#..].^.|
000000b0  3a b5 24 9b 39 d2 4f 25  e3 b6 05 02 5c 90 c6 6d  |:.$.9.O%....\..m|
000000c0  04 ff 00 00 00 23                                 |.....#|
--8<---------------cut here---------------end--------------->8---

which shows that the tag is actual part of the signed data.  There is no
warning if the tag has been renamed because the same data is hashed, we
would expect that from a symlink too and I consider this to be okay. 


Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- 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/20190326/d42c1a65/attachment.sig>

From lechten at wi.uni-muenster.de  Tue Mar 26 12:57:52 2019
From: lechten at wi.uni-muenster.de (Jens Lechtenboerger)
Date: Tue, 26 Mar 2019 12:57:52 +0100
Subject: gpgsm: Cannot decrypt with expired certificate for CRL
In-Reply-To: <9196712.fDa3IXLbjv@esus> (Andre Heinecke's message of "Tue, 26
 Mar 2019 07:52:02 +0100")
References: <87sgvbmgrn.fsf@wi.uni-muenster.de> <9196712.fDa3IXLbjv@esus>
Message-ID: <87o95xonjz.fsf@wi.uni-muenster.de>

On 2019-03-26, Andre Heinecke wrote:

> On Monday 25 March 2019 10:42:52 CET Jens Lechtenboerger wrote:
>> Yes, CRLs should not be signed with expired certificates.  However,
>> is the fact that gpgsm prevents me from using my certificate a bug
>> or a feature?
>
> For decrypt I would say: It's a bug. You should always be able to decrypt
> something for which you have the secret key IMO.
>
>> As workaround I now have disable-crl-checks in my gpgsm.conf.
>>
>> Should I file a bug report?
>
> Yes please. Ideally with an example certificate chain + test cert attached :-)

For the record: Deleting the expired CA certificate from my keyring
is another workaround.

I filed a bug: https://dev.gnupg.org/T4431

Creating an example for this seems complicated: A CA with two
certificates using the same key, one expired, one valid.  Then, a
CSR signed by that CA.  Then, a certificate signed by the CA, with
private key for decryption attempt.  I do not want to provide my
private key ;)

Best wishes
Jens


From lechten at wi.uni-muenster.de  Tue Mar 26 13:43:47 2019
From: lechten at wi.uni-muenster.de (Jens Lechtenboerger)
Date: Tue, 26 Mar 2019 13:43:47 +0100
Subject: gpgsm: Cannot decrypt with expired certificate for CRL
In-Reply-To: <87o95xonjz.fsf@wi.uni-muenster.de> (Jens Lechtenboerger's
 message of "Tue, 26 Mar 2019 12:57:52 +0100")
References: <87sgvbmgrn.fsf@wi.uni-muenster.de> <9196712.fDa3IXLbjv@esus>
 <87o95xonjz.fsf@wi.uni-muenster.de>
Message-ID: <877eclolfg.fsf@wi.uni-muenster.de>

On 2019-03-26, Jens Lechtenboerger wrote:

> On 2019-03-26, Andre Heinecke wrote:
>
>> On Monday 25 March 2019 10:42:52 CET Jens Lechtenboerger wrote:
>>> Yes, CRLs should not be signed with expired certificates.  However,
>>> is the fact that gpgsm prevents me from using my certificate a bug
>>> or a feature?
>>
>> For decrypt I would say: It's a bug. You should always be able to decrypt
>> something for which you have the secret key IMO.
>>
>>> As workaround I now have disable-crl-checks in my gpgsm.conf.
>>>
>>> Should I file a bug report?
>>
>> Yes please. Ideally with an example certificate chain + test cert attached :-)
>
> For the record: Deleting the expired CA certificate from my keyring
> is another workaround.

That was too fast.  The presence or absence of the expired
certificate in my keyring does not matter.  The check by dirmngr
fails regardless.

Along the way I also executed this:
$ gpgsm -k --with-validation

This populated ~/.gnupg/crls.d/ with CRLs, which I did not realize.
I guessed that removing the expired certificate solved the problem,
while really those cached CRLs were used.  With those present, the
expired certificate can be on the keyring as well.

Best wishes
Jens


From doron.behar at gmail.com  Tue Mar 26 08:57:56 2019
From: doron.behar at gmail.com (Doron Behar)
Date: Tue, 26 Mar 2019 09:57:56 +0200
Subject: GSoC project idea
In-Reply-To: <CAMucfLx=NkyRhBLG3yWz5=2Jn9ib+hiZAAgMT4AhXup3x6v2hQ@mail.gmail.com>
References: <CAMucfLw0y1JGcJhV8o-Da0-GAegfUCb4x1YM9cdLbTnTKJ7YgA@mail.gmail.com>
 <20190318112127.fyxhwpbkx2vkbtcn@NUC.doronbehar.com>
 <CAMucfLxkeDh70JV7WKuV27OqchakNjZqKtu0yqLsu6O2tWyWhA@mail.gmail.com>
 <20190318150627.ejjydu3crfupnjfy@NUC.doronbehar.com>
 <CAMucfLx=NkyRhBLG3yWz5=2Jn9ib+hiZAAgMT4AhXup3x6v2hQ@mail.gmail.com>
Message-ID: <20190326075756.enkeatyp5byhp7gd@NUC.doronbehar.com>

On Mon, Mar 18, 2019 at 04:49:11PM +0100, Dashamir Hoxha wrote:
> On Mon, Mar 18, 2019 at 4:07 PM Doron Behar <doron.behar at gmail.com> wrote:
> 
> >
> > In my fork I didn't modify anything, only added. The idea is to add only
> > a directory named ipg (Acronym for improved privacy guard) and in it all
> > the code that will use the functions that already exist in the source
> > tree; So when a user builds my version from the git source (autoreconf
> > && ./configure && make && make install), he will a get another
> > executable installed called `ipg` that will be equivalent to `gpg` in
> > it's use but will have a nicer CLI syntax.
> >
> > Both executables (gpg & ipg) installed by my version will be equally
> > updated to use the latest version of the C code that implements the
> > actual encryption and decryption etc.
> >
> 
> In my opinion, it might be better if there was a single executable (gpg)
> that can accept both sets of CLI commands. If this is possible.
> 
> In any case, I think that the aim should be to finally submit a patch to
> the mainstream code, and hopefully it gets accepted. Distributing it
> separately as an improved version of gpg is not going to work for many
> reasons.

I agree but say that building a single executable that will accept both
CLI syntaxes won't be easy to implement, even submitting a patch to the
mainstream code with the additional `ipg` executable would be a good as
well right?

> 
> 
> >
> > > It does not seem so easy to me because you may need some feedback from
> > more
> > > experienced people, although you may think that you have organized the
> > > commands and their options properly.
> >
> > I think the only difficult part in this design (and please correct me if
> > you think I'm wrong) is making sure that when the upstream source is
> > updated and functions change their names etc., my fork updates the names
> > of the functions it calls.
> >
> > Also, according to my design, almost every sub-command and it's optional
> > flags have their equivalent in the current syntax, strictly according to
> > the documentation. The only difference is that some sub-commands
> > naturally don't accept all options that may be accepted (but ignored!)
> > in the current syntax. Most importantly, this should also prove to be
> > more comfortable for shell completions to not overwhelm users with
> > options most of which are irrelevant for the current _action_ they want
> > to perform.
> >
> 
> I understand your design and its advantages, but I am not sure wheather you
> understand all the details about `gpg` commands and options. Maybe you do,
> myself I don't.
> 
> > You can be one of the mentors, which hopefully should not be very time
> > > consuming.
> >
> > As a mentor, am I not obliged to be an experienced C programmer? If so,
> > that could be an excellent idea.
> >
> 
> If you are an experienced C programmer that's great. But you don't have to
> be. You can also be an experienced `gpg` user. And anyway, the idea of
> reorganizing the commands is yours and you know what you are aiming for
> better than anyone. So, you can definitely be one of the mentors, if you
> have time and if you want to be.

I just wanted to notify you that today I've found out that I won't be
able to submit this project to the next GSOC since I'm not a student yet
and therefor I don't have a proof of enrollment. I wonder whether I can
register as a mentor without being a student, if so it's probably not
possible only yet.

> 
> Dashamir

> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel



From wk at gnupg.org  Tue Mar 26 15:20:40 2019
From: wk at gnupg.org (Werner Koch)
Date: Tue, 26 Mar 2019 15:20:40 +0100
Subject: [Announce] GnuPG 2.2.15 released
Message-ID: <87y351u37r.fsf@wheatstone.g10code.de>

Hello!

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


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

The GNU Privacy Guard (GnuPG, GPG) is a complete and free implementation
of the OpenPGP and S/MIME standards.

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.  The separate library GPGME provides
a uniform API to use the GnuPG engine by software written in common
programming languages.  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.15
====================================

  * sm: Fix --logger-fd and --status-fd on Windows for non-standard
    file descriptors.

  * sm: Allow decryption even if expired keys are configured.  [#4431]

  * agent: Change command KEYINFO to print ssh fingerprints with other
    hash algos.

  * dirmngr: Fix build problems on Solaris due to the use of reserved
    symbol names.  [#4420]

  * wkd: New commands --print-wkd-hash and --print-wkd-url for
    gpg-wks-client.

  Release-info: https://dev.gnupg.org/T4434


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

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

GnuPG 2.2.15 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.15.tar.bz2 (6548k)
 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.15.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.15_20190326.exe (4078k)
 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.15_20190326.exe.sig

The source used to build the Windows installer can be found in the same
directory with a ".tar.xz" suffix.


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.15.tar.bz2 you would use this command:

     gpg --verify gnupg-2.2.15.tar.bz2.sig gnupg-2.2.15.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.15.tar.bz2, you run the command like this:

     sha1sum gnupg-2.2.15.tar.bz2

   and check that the output matches the next line:

1909afdad3cf29583126c471298da290399270f4  gnupg-2.2.15.tar.bz2
540abc655dbed525bb216c62e5e43a88f952193c  gnupg-w32-2.2.15_20190326.tar.xz
f5f7eeadfdf6ad971b5313f045083b4f95ace07b  gnupg-w32-2.2.15_20190326.exe


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

This version of GnuPG has support for 26 languages with Chinese
(traditional and simplified), 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 available 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.

In case of build problems specific to this release please first check
https://dev.gnupg.org/T4434 for updated information.

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 two full-time developers and one
contractor.  They all work exclusively on GnuPG and closely related
software like Libgcrypt, GPGME and Gpg4win.

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 to 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.

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- 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/20190326/c68a2379/attachment-0001.sig>
-------------- next part --------------
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce

From dashohoxha at gmail.com  Tue Mar 26 15:42:20 2019
From: dashohoxha at gmail.com (Dashamir Hoxha)
Date: Tue, 26 Mar 2019 15:42:20 +0100
Subject: GSoC project idea
In-Reply-To: <20190326075756.enkeatyp5byhp7gd@NUC.doronbehar.com>
References: <CAMucfLw0y1JGcJhV8o-Da0-GAegfUCb4x1YM9cdLbTnTKJ7YgA@mail.gmail.com>
 <20190318112127.fyxhwpbkx2vkbtcn@NUC.doronbehar.com>
 <CAMucfLxkeDh70JV7WKuV27OqchakNjZqKtu0yqLsu6O2tWyWhA@mail.gmail.com>
 <20190318150627.ejjydu3crfupnjfy@NUC.doronbehar.com>
 <CAMucfLx=NkyRhBLG3yWz5=2Jn9ib+hiZAAgMT4AhXup3x6v2hQ@mail.gmail.com>
 <20190326075756.enkeatyp5byhp7gd@NUC.doronbehar.com>
Message-ID: <CAMucfLwZ6mhAEMPKOu7=wzV3_RqnNm9DpdNRNUEDMXt9GoO9yw@mail.gmail.com>

On Tue, Mar 26, 2019 at 3:00 PM Doron Behar <doron.behar at gmail.com> wrote:

>
> > In my opinion, it might be better if there was a single executable (gpg)
> > that can accept both sets of CLI commands. If this is possible.
> >
> > In any case, I think that the aim should be to finally submit a patch to
> > the mainstream code, and hopefully it gets accepted. Distributing it
> > separately as an improved version of gpg is not going to work for many
> > reasons.
>
> I agree but say that building a single executable that will accept both
> CLI syntaxes won't be easy to implement, even submitting a patch to the
> mainstream code with the additional `ipg` executable would be a good as
> well right?
>

I would say this is acceptable, especially if we view this GSoC project as
an experimentation. The code produced by a GSoC project is not required to
be accepted by the main project, even if the GSoC project is successfull
(meets its objectives etc.)
However I am not a gnupg developer and I have no saying on this matter. If
the developers are firmly against the idea of this GSoC project, let them
speak and put an end to this story.

> If you are an experienced C programmer that's great. But you don't have to
> > be. You can also be an experienced `gpg` user. And anyway, the idea of
> > reorganizing the commands is yours and you know what you are aiming for
> > better than anyone. So, you can definitely be one of the mentors, if you
> > have time and if you want to be.
>
> I just wanted to notify you that today I've found out that I won't be
> able to submit this project to the next GSOC since I'm not a student yet
> and therefor I don't have a proof of enrollment. I wonder whether I can
> register as a mentor without being a student, if so it's probably not
> possible only yet.
>

According to the GSoC rules, there are no special requirements about the
mentors. It is the organization admins that decide whether you can be a
mentor of a project or not. In this case the organization is GNU. I don't
think they will refuse to make you a mentor, unless there is some oposition
from gnupg developers. This page has more details:
https://www.gnu.org/software/soc-projects/guidelines.html

However the period that students submit project proposals has already
started, and this project idea is not published yet anywhere. Even if it is
published now, I wonder if any students will notice it and apply for it. If
you know some student that could work on this project you can let them know
personally. Then either you or the student can mail the project idea to:
summer-of-code at gnu.org Maybe you should hurry up a bit because on April 9
is the student application deadline (
https://developers.google.com/open-source/gsoc/timeline). I would be
willing to advice you, if nothing else, at least about the rules and
requirements of GSoC.

Dashamir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190326/24866916/attachment.html>

From dkg at fifthhorseman.net  Tue Mar 26 17:11:57 2019
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 26 Mar 2019 17:11:57 +0100
Subject: [openpgp] Deprecating compression support
In-Reply-To: <87o95yujj0.fsf@wheatstone.g10code.de>
References: <CAKUk3bvBWoh9jz+T6t5yGs-P-P4cSg8AnSo_md3OFnzqVN-3=A@mail.gmail.com>
 <871s3475dy.fsf@europa.jade-hamburg.de>
 <96055353-B0EB-4E25-95CC-B25D9C5A0BA8@icloud.com>
 <2RAT852LYMAQD.3U70IQJPU0VPO@my.amazin.horse>
 <0092256D-94EB-4FE5-9560-FEB0B8E3769E@icloud.com>
 <20190323170723.GC1497@zeromail.org> <87imw9jl2t.fsf@fifthhorseman.net>
 <20190324162058.GA1238@zeromail.org> <87o95yujj0.fsf@wheatstone.g10code.de>
Message-ID: <87imw5haya.fsf@fifthhorseman.net>

On Tue 2019-03-26 09:28:19 +0100, Werner Koch wrote:
> On Sun, 24 Mar 2019 17:20, ilf at zeromail.org said:
>
>> So GnuPG development comunity: Would you be fine in changing the
>> default for new keys to "Compression: Uncompressed"?
>
> That is easy to answer: No.
>
> Removing that feature would break major use cases and deployed
> infrastructure.  The build in compression support in OpenPGP is actually
> a selling point over S/MIME.

ilf is asking about a change to the advertised preferences included in
an OpenPGP certificate generated by default with GnuPG.

Someone who wants to use the compression feature because they know
that's what they want needs only to issue a "setpref" command to
indicate that they *do* want it (if it is a "selling feature" that they
consciously care about).

This is not breakage exactly -- it's a question of where we want to push
the ecosystem.

> This can also not be done with a switch to a new key or key format
> because key management is independent from actual use.

If we were to say that v5 keys do not support in-protocol compression by
definition, then it seems like we could well do it with a switch to a
new key format.  What did you mean here?

> Please remember that OpenPGP is not only used for mail.

can you elaborate on this?  In contexts where OpenPGP is not only used
for e-mail, it's not competing with S/MIME, and it seems likely that a
simple pipeline with gzip or xz or whatever can meet the use case.

> Those who do not want to have compression, please specify that in your
> keys.  MUA authors may pass "-z0" or GPGME_ENCRYPT_NO_COMPRESS to
> disable encryption.

itym "disable compression" :)

     --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/20190326/4a205f65/attachment.sig>

From wk at gnupg.org  Tue Mar 26 18:50:42 2019
From: wk at gnupg.org (Werner Koch)
Date: Tue, 26 Mar 2019 18:50:42 +0100
Subject: [Announce] GnuPG Made Easy (GPGME) 1.13.0 released
Message-ID: <87pnqdtthp.fsf@wheatstone.g10code.de>

Hello!

We are pleased to announce version 1.13.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.13.0
====================================

 * Support GPGME_AUDITLOG_DIAG for gpgsm.  [#4426]

 * New context flag "trust-model".

 * Removed support for WindowsCE and Windows ME.

 * Aligned the gpgrt-config code with our other libaries.

 * Auto-check for all installed Python versions.  [#3354]

 * Fixed generating card key in the C++ bindings.  [#4428]

 * Fixed a segv due to bad parameters in genkey.  [#4192]

 * Fixed crash if the plaintext is ignored in a CMS verify.

 * Fixed memleak on Windows.  [T4238]

 * Tweaked the Windows I/O code.

 * Fixed random crashes on Windows due to closing an arbitrary
   handle.  [#4237]

 * Fixed a segv on Windows.  [#4369]

 * Fixed test suite problems related to dtags.  [#4298]

 * Fixed bunch of python bugs.  [#4242,commit 9de1c96ac3cf]

 * Several fixes to the Common Lisp bindings.

 * Fixed minor bugs in gpgme-json.  [#4331,#4341,#4342,#4343

 * Require trace level 8 to dump all I/O data.

 * The compiler must now support variadic macros.

 * Interface changes relative to the 1.12.0 release:
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 gpgme_set_ctx_flag               EXTENDED: New flag 'trust-model'.
 cpp: Context::create                       NEW.
 cpp: Key::isBad                            NEW.
 cpp: Subkey::isBad                         NEW.
 cpp: UserID::isBad                         NEW.
 cpp: UserID::Signature::isBad              NEW.
 cpp: GenCardKeyInteractor::setAlgo         NEW.
 [c=C33/A22/R0 cpp=C15/A9/R0 qt=C10/A3/R3]

 Release-info: https://dev.gnupg.org/T4376


Download
========

You may download this library and its OpenPGP signature from:

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

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

4653b273fd2820ba4d5f382474b3e79a9367beb9  gpgme-1.13.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 two full-time developer and one
contractor.  All work exclusively on GnuPG and closely related software
like Libgcrypt and GPGME.

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

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- 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/20190326/e9b22335/attachment.sig>
-------------- next part --------------
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce

From wk at gnupg.org  Tue Mar 26 22:36:43 2019
From: wk at gnupg.org (Werner Koch)
Date: Tue, 26 Mar 2019 22:36:43 +0100
Subject: [openpgp] Deprecating compression support
In-Reply-To: <87imw5haya.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message
 of "Tue, 26 Mar 2019 17:11:57 +0100")
References: <CAKUk3bvBWoh9jz+T6t5yGs-P-P4cSg8AnSo_md3OFnzqVN-3=A@mail.gmail.com>
 <871s3475dy.fsf@europa.jade-hamburg.de>
 <96055353-B0EB-4E25-95CC-B25D9C5A0BA8@icloud.com>
 <2RAT852LYMAQD.3U70IQJPU0VPO@my.amazin.horse>
 <0092256D-94EB-4FE5-9560-FEB0B8E3769E@icloud.com>
 <20190323170723.GC1497@zeromail.org>
 <87imw9jl2t.fsf@fifthhorseman.net>
 <20190324162058.GA1238@zeromail.org>
 <87o95yujj0.fsf@wheatstone.g10code.de>
 <87imw5haya.fsf@fifthhorseman.net>
Message-ID: <87d0mdtj10.fsf@wheatstone.g10code.de>

On Tue, 26 Mar 2019 17:11, dkg at fifthhorseman.net said:

> ilf is asking about a change to the advertised preferences included in
> an OpenPGP certificate generated by default with GnuPG.

I got that.

> Someone who wants to use the compression feature because they know
> that's what they want needs only to issue a "setpref" command to

Just using setpref instead of using the defaults is not easy but may
require new organizational procedures and training.

> This is not breakage exactly -- it's a question of where we want to push
> the ecosystem.

I see no reason to drop compression form OpenPGP. It has been there
forever and is a part of it.  Those folks who are trying to get severe
last minute changes into a revision of a standard may be better off to
start their protocol from scratch.

> definition, then it seems like we could well do it with a switch to a
> new key format.  What did you mean here?

At some point new keys will be generated in v5 format and it will be
hard enough to get systems adopted to the longer fingerprint.  Forcing
people to change their entire processing by adding another tool into a
list of steps to encrypt and convey data is everything else than user
friendly.

> can you elaborate on this?  In contexts where OpenPGP is not only used
> for e-mail, it's not competing with S/MIME, and it seems likely that a
> simple pipeline with gzip or xz or whatever can meet the use case.

You need to change established procedures, test the new setup, fix the
bugs, have meetings with your peers to agree on the changes, and so on.
It is basically a the deployment of a new product.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- 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/20190326/71543217/attachment-0001.sig>

From gniibe at fsij.org  Wed Mar 27 03:12:25 2019
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 27 Mar 2019 11:12:25 +0900
Subject: Invalid keys when switching smartcard from ed25519 to other curves
In-Reply-To: <cd788592-c15e-e937-5ae8-77f0eb8b221f@yubico.com>
References: <1272a787-1830-5cd7-8a89-d28da3456d37@yubico.com>
 <2de68052-5392-8e7d-cbc4-2a6eca46082d@yubico.com> <87h8bq13y3.fsf@c720>
 <cd788592-c15e-e937-5ae8-77f0eb8b221f@yubico.com>
Message-ID: <87r2at12wm.fsf@iwagami.gniibe.org>

Trevor Bentley <trevor at yubico.com> wrote:
> Yes, exactly, it's the call in ask_card_keyattr() that is a problem.  It 
> gets 'stuck' on the EdDSA algo ID when it passes in the current curve 
> parameters.

Thanks, applied (STABLE-BRANCH-2-2 and master).
-- 


From trevor at yubico.com  Wed Mar 27 10:29:15 2019
From: trevor at yubico.com (Trevor Bentley)
Date: Wed, 27 Mar 2019 10:29:15 +0100
Subject: Invalid keys when switching smartcard from ed25519 to other curves
In-Reply-To: <87r2at12wm.fsf@iwagami.gniibe.org>
References: <1272a787-1830-5cd7-8a89-d28da3456d37@yubico.com>
 <2de68052-5392-8e7d-cbc4-2a6eca46082d@yubico.com> <87h8bq13y3.fsf@c720>
 <cd788592-c15e-e937-5ae8-77f0eb8b221f@yubico.com>
 <87r2at12wm.fsf@iwagami.gniibe.org>
Message-ID: <ee94478f-eb6f-39fb-5e01-e5caf2dd6fbb@yubico.com>

> Thanks, applied (STABLE-BRANCH-2-2 and master).

Thanks!  What is the master->stable branch process like?  Should git 
commit af3efd149f555d36a455cb2ea311ff81caf5124c also have gone into a 
stable branch, or will it be moved over eventually?  That commit is 
arguably more important, as their is no workaround.

-Trevor


From aheinecke at gnupg.org  Wed Mar 27 11:17:55 2019
From: aheinecke at gnupg.org (Andre Heinecke)
Date: Wed, 27 Mar 2019 11:17:55 +0100
Subject: gpgsm: Cannot decrypt with expired certificate for CRL
In-Reply-To: <04b61bb4-5e0a-d1c1-46be-a8e257d433a5@digitalbrains.com>
References: <permail-2019032515410105be2aed0000594b-perske@message-id.uni-muenster.de>
 <04b61bb4-5e0a-d1c1-46be-a8e257d433a5@digitalbrains.com>
Message-ID: <4600404.Pz1CW3TaVh@esus>

Hi,

On Monday 25 March 2019 19:25:44 CET Peter Lebbing wrote:
> But... shouldn't it always be possible to /decrypt/, no matter the
> revocation status or expiry or whatnot?

Just for the record, the issue was reported by Jens in a ticket and has been 
fixed now: https://dev.gnupg.org/T4431

Regards,
Andre


-- 
GnuPG.com - a brand of g10 Code, the GnuPG experts.

g10 Code GmbH, Erkrath/Germany, AG Wuppertal HRB14459
GF Werner Koch, USt-Id DE215605608, www.g10code.com.

GnuPG e.V., Rochusstr. 44, D-40479 D?sseldorf.  VR 11482 D?sseldorf
Vorstand: W.Koch, M.Gollowitzer, A.Heinecke.    Mail: board at gnupg.org
Finanzamt D-Altstadt, St-Nr: 103/5923/1779.   Tel: +49-2104-4938799
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190327/259e2600/attachment.sig>

From wk at gnupg.org  Wed Mar 27 12:34:16 2019
From: wk at gnupg.org (Werner Koch)
Date: Wed, 27 Mar 2019 12:34:16 +0100
Subject: Invalid keys when switching smartcard from ed25519 to other curves
In-Reply-To: <ee94478f-eb6f-39fb-5e01-e5caf2dd6fbb@yubico.com> (Trevor Bentley
 via Gnupg-devel's message of "Wed, 27 Mar 2019 10:29:15 +0100")
References: <1272a787-1830-5cd7-8a89-d28da3456d37@yubico.com>
 <2de68052-5392-8e7d-cbc4-2a6eca46082d@yubico.com>
 <87h8bq13y3.fsf@c720>
 <cd788592-c15e-e937-5ae8-77f0eb8b221f@yubico.com>
 <87r2at12wm.fsf@iwagami.gniibe.org>
 <ee94478f-eb6f-39fb-5e01-e5caf2dd6fbb@yubico.com>
Message-ID: <87va04sg93.fsf@wheatstone.g10code.de>

On Wed, 27 Mar 2019 10:29, gnupg-devel at gnupg.org said:

> Thanks!  What is the master->stable branch process like?  Should git

We cherry-pick bug fixes and some other useful commits from master.  Bug
fixes are usually psuhed to 2.2 soon after the master.  Others backports
are selected before we do a new 2.2 release.

> commit af3efd149f555d36a455cb2ea311ff81caf5124c also have gone into a

Unfortunately this one was forgotten.  I just pushed it but it has to
wait for the 2.2.16 release.  


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- 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/20190327/ab1d2a34/attachment.sig>

From wiktor at metacode.biz  Thu Mar 28 20:57:21 2019
From: wiktor at metacode.biz (Wiktor Kwapisiewicz)
Date: Thu, 28 Mar 2019 20:57:21 +0100
Subject: Debugging dirmngr (gpg --locate-key)
Message-ID: <5bc55beb-cee5-b4cc-8f12-0de4b3e31f05@metacode.biz>

Hello,

I'm trying to debug why the following doesn't fetch the key via WKD:

$ gpg --locate-key torvalds at kernel.org
gpg: error retrieving 'torvalds at kernel.org' via WKD: No data
gpg: error reading key: No data

While naive curl for the WKD URL works:

$ curl -sSL 
https://kernel.org/.well-known/openpgpkey/hu/pf113mfnx1f3eb1yiwhsipa91xfc7o4x 
| gpg --import
gpg: key 79BE3E4300411886: public key "Linus Torvalds 
<torvalds at kernel.org>" imported

I tried debug lookup flags but it doesn't print any useful info:

$ gpg --debug lookup -vvv --locate-key torvalds at kernel.org
gpg: using character set 'utf-8'
gpg: enabled debug flags: lookup
gpg: using pgp trust model
gpg: DBG: keydb_search: 1 search descriptions:
gpg: DBG: keydb_search   0: SUBSTR: 'torvalds at kernel.org'
gpg: DBG: keydb_search: searching keybox (resource 0 of 1)
gpg: DBG: keydb_search: searched keybox (resource 0 of 1) => EOF
gpg: error retrieving 'torvalds at kernel.org' via Local: No public key
gpg: error retrieving 'torvalds at kernel.org' via WKD: No data
gpg: error reading key: No data
gpg: secmem usage: 0/32768 bytes in 0 blocks

Are there any other flags or config options that can be enabled to see 
the lookup step by step and check why this fails?

(For the record locating my own key via my e-mail address works but as I 
don't control kernel.org I can't check what URLs is GPG trying to access).

I tried this with GnuPG 2.2.12 and 2.2.14.

Thank you in advance!

Kind regards,
Wiktor

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


From aheinecke at gnupg.org  Fri Mar 29 09:30:10 2019
From: aheinecke at gnupg.org (Andre Heinecke)
Date: Fri, 29 Mar 2019 09:30:10 +0100
Subject: Debugging dirmngr (gpg --locate-key)
In-Reply-To: <5bc55beb-cee5-b4cc-8f12-0de4b3e31f05@metacode.biz>
References: <5bc55beb-cee5-b4cc-8f12-0de4b3e31f05@metacode.biz>
Message-ID: <4136397.NSyCGfFzxI@esus>

Hi,

On Thursday 28 March 2019 20:57:21 CET Wiktor Kwapisiewicz via Gnupg-devel 
wrote:
> I'm trying to debug why the following doesn't fetch the key via WKD:

The debugging for WKD happens with dirmngr.

I have the following in my dirmngr.conf:

  debug-level guru
  log-file /tmp/dirmngr.log

Then after the locate key (kill dirmngr after changing the config)
I see in that log:

2019-03-29 09:18:06 dirmngr[6907.6] URL 'https://kernel.org/.well-known/
openpgpkey/policy' redirected to 'https://www.kernel.org/.well-known/
openpgpkey/policy' (301)
2019-03-29 09:18:06 dirmngr[6907.6] redirection changed to 'https://
www.kernel.org/.well-known/openpgpkey/policy'
2019-03-29 09:18:06 dirmngr[6907.6] DBG: http.c:request:
2019-03-29 09:18:06 dirmngr[6907.6] DBG: >> GET /.well-known/openpgpkey/policy 
HTTP/1.0\r\n
2019-03-29 09:18:06 dirmngr[6907.6] DBG: >> Host: www.kernel.org\r\n
2019-03-29 09:18:06 dirmngr[6907.6] DBG: http.c:request-header:
2019-03-29 09:18:06 dirmngr[6907.6] DBG: >> \r\n
2019-03-29 09:18:06 dirmngr[6907.6] DBG: http.c:response:
2019-03-29 09:18:06 dirmngr[6907.6] DBG: >> HTTP/1.1 404 Not Found\r\n
2019-03-29 09:18:06 dirmngr[6907.6] http.c:RESP: 'Server: nginx'
2019-03-29 09:18:06 dirmngr[6907.6] http.c:RESP: 'Date: Fri, 29 Mar 2019 
08:18:06 GMT'
2019-03-29 09:18:06 dirmngr[6907.6] http.c:RESP: 'Content-Type: text/html'
2019-03-29 09:18:06 dirmngr[6907.6] http.c:RESP: 'Content-Length: 162'
2019-03-29 09:18:06 dirmngr[6907.6] http.c:RESP: 'Connection: close'
2019-03-29 09:18:06 dirmngr[6907.6] http.c:RESP: ''
2019-03-29 09:18:06 dirmngr[6907.6] error accessing 'https://
www.kernel.org/.well-known/openpgpkey/policy': http status 404

And if I directly force dirmngr to fetch anyway via:

  gpg-connect-agent --dirmngr
  > WKD_GET torvalds at kernel.org

I get:

2019-03-29 09:24:12 dirmngr[31781.6] URL 'https://kernel.org/.well-known/
openpgpkey/hu/pf113mfnx1f3eb1yiwhsipa91xfc7o4x?l=torvalds' redirected to 
'https://mirrors.edge.kernel.org/pub/.well-known/openpgpkey/hu/
pf113mfnx1f3eb1yiwhsipa91xfc7o4x?l=torvalds' (302)
2019-03-29 09:24:12 dirmngr[31781.6] redirection changed to 'https://
mirrors.edge.kernel.org/.well-known/openpgpkey/hu/
pf113mfnx1f3eb1yiwhsipa91xfc7o4x?l=torvalds'
2019-03-29 09:24:13 dirmngr[31781.6] DBG: http.c:request:
2019-03-29 09:24:13 dirmngr[31781.6] DBG: >> GET /.well-known/openpgpkey/hu/
pf113mfnx1f3eb1yiwhsipa91xfc7o4x?l=torvalds HTTP/1.0\r\n
2019-03-29 09:24:13 dirmngr[31781.6] DBG: >> Host: mirrors.edge.kernel.org\r\n
2019-03-29 09:24:13 dirmngr[31781.6] DBG: http.c:request-header:
2019-03-29 09:24:13 dirmngr[31781.6] DBG: >> \r\n
2019-03-29 09:24:13 dirmngr[31781.6] DBG: http.c:response:
2019-03-29 09:24:13 dirmngr[31781.6] DBG: >> HTTP/1.1 404 Not Found\r\n
2019-03-29 09:24:13 dirmngr[31781.6] http.c:RESP: 'Server: nginx'
2019-03-29 09:24:13 dirmngr[31781.6] http.c:RESP: 'Date: Fri, 29 Mar 2019 
08:24:13 GMT'
2019-03-29 09:24:13 dirmngr[31781.6] http.c:RESP: 'Content-Type: text/html'
2019-03-29 09:24:13 dirmngr[31781.6] http.c:RESP: 'Content-Length: 311'
2019-03-29 09:24:13 dirmngr[31781.6] http.c:RESP: 'Connection: close'
2019-03-29 09:24:13 dirmngr[31781.6] http.c:RESP: ''
2019-03-29 09:24:13 dirmngr[31781.6] error accessing 'https://
mirrors.edge.kernel.org/.well-known/openpgpkey/hu/
pf113mfnx1f3eb1yiwhsipa91xfc7o4x?l=torvalds': http status 404
2019-03-29 09:24:13 dirmngr[31781.6] command 'WKD_GET' failed: No data


So it is missing a policy file and the redirect goes to:

https://mirrors.edge.kernel.org/pub/.well-known/openpgpkey/hu/
pf113mfnx1f3eb1yiwhsipa91xfc7o4x?torvalds

While dirmngr after the redirect queries:
https://mirrors.edge.kernel.org/.well-known/openpgpkey/hu/
pf113mfnx1f3eb1yiwhsipa91xfc7o4x?l=torvalds

Without the "pub". This is why curl / wget work but not dirmngr.

Best Regards,
Andre
-- 
GnuPG.com - a brand of g10 Code, the GnuPG experts.

g10 Code GmbH, Erkrath/Germany, AG Wuppertal HRB14459
GF Werner Koch, USt-Id DE215605608, www.g10code.com.

GnuPG e.V., Rochusstr. 44, D-40479 D?sseldorf.  VR 11482 D?sseldorf
Vorstand: W.Koch, M.Gollowitzer, A.Heinecke.    Mail: board at gnupg.org
Finanzamt D-Altstadt, St-Nr: 103/5923/1779.   Tel: +49-2104-4938799
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190329/075e0668/attachment-0001.sig>

From wiktor at metacode.biz  Fri Mar 29 10:07:54 2019
From: wiktor at metacode.biz (Wiktor Kwapisiewicz)
Date: Fri, 29 Mar 2019 10:07:54 +0100
Subject: Debugging dirmngr (gpg --locate-key)
In-Reply-To: <4136397.NSyCGfFzxI@esus>
References: <5bc55beb-cee5-b4cc-8f12-0de4b3e31f05@metacode.biz>
 <4136397.NSyCGfFzxI@esus>
Message-ID: <e2161500-4a74-4d33-843f-b2e44fa0d54a@metacode.biz>

On 29.03.2019 09:30, Andre Heinecke wrote:
> (...)
> Without the "pub". This is why curl / wget work but not dirmngr.

Wow, excellent analysis Andre, as usual, thank you! I'll bookmark your 
instructions as I bet they'll come in handy in the future...

As far as I know this change, that requires strict path match was done 
to avoid a specific vulnerability.

Do you think it would be reasonable to put that requirement in the Web 
Key Directory [0] spec? This way other implementations can also be 
adjusted so that WKD works consistently across different software.

Kind regards,
Wiktor

[0]: https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service/

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

-------------- 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/20190329/bee31a50/attachment.sig>

From wk at gnupg.org  Fri Mar 29 13:04:00 2019
From: wk at gnupg.org (Werner Koch)
Date: Fri, 29 Mar 2019 13:04:00 +0100
Subject: Debugging dirmngr (gpg --locate-key)
In-Reply-To: <e2161500-4a74-4d33-843f-b2e44fa0d54a@metacode.biz> (Wiktor
 Kwapisiewicz via Gnupg-devel's message of "Fri, 29 Mar 2019 10:07:54
 +0100")
References: <5bc55beb-cee5-b4cc-8f12-0de4b3e31f05@metacode.biz>
 <4136397.NSyCGfFzxI@esus>
 <e2161500-4a74-4d33-843f-b2e44fa0d54a@metacode.biz>
Message-ID: <874l7ldgzz.fsf@wheatstone.g10code.de>

On Fri, 29 Mar 2019 10:07, gnupg-devel at gnupg.org said:

> As far as I know this change, that requires strict path match was done
> to avoid a specific vulnerability.

Cross site request forgery.  The fear is that if you are on a site which
uses only IP based authentication to access internal services of your
site (e.g. a dedicated host to control the lightning of your building)
an attacker can control that internal service by sending you a redirect
to that host.  Your dirmngr would than contact that internal host and
access will be granted because the request comes from inside your own
network.

I consider this quite far fetched but we better protect against this.  See
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000858

> Do you think it would be reasonable to put that requirement in the Web
> Key Directory [0] spec? This way other implementations can also be
> adjusted so that WKD works consistently across different software.

Yes, I think this is useful.

However, there is a second problem with kernel.org: They do not provide
the (possible empty) policy file.  This is a problem for two reasons:

If dirmngr looks up a key for one domain and does not find one, it will
test for the presence of the policy file.  If no policy file is found
either, further WKD request to this domain are not performed until a
restart of dirmnngr or until the domain is kicked out of dirmngr's hash
table with domain names [1].

Testing for domains supporting the web key directory does not work
because it is based on the presence of the policy file.

  $ gpg-wks-client --with-colons --supported gnupg.org posteo.de kernel.org
  gnupg.org:1:1::0:0:0:
  posteo.de:1:1::0:1:1:
  kernel.org:0:0::
             ! !- Submitting keys supported
             !--- Lookup supported



Shalom-Salam,

   Werner



[1] We still need to add time based removal of domains.

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- 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/20190329/f9742731/attachment.sig>