From bts at square-r00t.net  Mon Nov  5 06:20:55 2018
From: bts at square-r00t.net (brent s.)
Date: Mon, 5 Nov 2018 00:20:55 -0500
Subject: python GPGME bindings and key signatures
Message-ID: <bc93c576-a508-8ed4-cdd3-b03f8b212e70@square-r00t.net>

i frequently do work with the GPGME bindings for python (is this still
referred to as "pyME" after the merge into mainline?), and i really must
start by saying thank you to whomever maintains it!

i do have a quick question as i'm not sure it's something expected or not.

it seems the signatures interface is obsolete[0].

it seems that the non-obsolete way of accessing this is in
gpgme_user_id_t's `signatures` member[1] (or
<key>.uids[<idx>].signatures per the bindings).

however, this is empty in python's bindings:

_________________________________________________________________
>>> import os
>>> os.environ['GNUPGHOME']
'/var/tmp/python_testing/gpg/homedir'
>>> import gpg
>>> ctx = gpg.Context()
>>> k = ctx.get_key('C548200C7F6AA9541F6EDFF65A6D013706B6BE26')
>>> k.uids[0].signatures
[]
>>>
_________________________________________________________________


whereas signatures most definitely do exist:


_________________________________________________________________
[bts at cylon gpg]$ echo $GNUPGHOME
/var/tmp/python_testing/gpg/homedir
[bts at cylon gpg]$ gpg --list-keys --with-sig-check
C548200C7F6AA9541F6EDFF65A6D013706B6BE26
pub   rsa4096 2012-10-30 [SC]
      C548200C7F6AA9541F6EDFF65A6D013706B6BE26
uid           [  full  ] A Test Key for Expiring, delete when done
(1351649839.474725) <test2 at test.com>
sig!3        5A6D013706B6BE26 2012-10-30  A Test Key for Expiring,
delete when done (1351649839.474725) <test2 at test.com>
sig!         33F7494F9AF6E3D1 2018-11-04  A Test Key (a comment)
<test at test.com>
sig!       2 33F7494F9AF6E3D1 2018-11-05  A Test Key (a comment)
<test at test.com>
sub   rsa4096 2012-10-30 [S]
sig!         5A6D013706B6BE26 2012-10-30  A Test Key for Expiring,
delete when done (1351649839.474725) <test2 at test.com>

gpg: 4 good signatures
_________________________________________________________________


is this intentional/known behaviour? did i do a goof?

if the former, is there an expected ETA on support for this?
if the latter, is there a certain constant that needs to be set for the
context first or something; how can i implement key signature listing?

thanks!


[0] https://gnupg.org/documentation/manuals/gpgme/Key-Signatures.html
[1]
https://www.gnupg.org/documentation/manuals/gpgme/Key-objects.html#index-gpgme_005fuser_005fid_005ft


-- 
brent saner
https://square-r00t.net/
GPG info: https://square-r00t.net/gpg-info

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

From muelli at cryptobitch.de  Mon Nov  5 12:14:45 2018
From: muelli at cryptobitch.de (Tobias Mueller)
Date: Mon, 05 Nov 2018 12:14:45 +0100
Subject: python GPGME bindings and key signatures
In-Reply-To: <bc93c576-a508-8ed4-cdd3-b03f8b212e70@square-r00t.net>
References: <bc93c576-a508-8ed4-cdd3-b03f8b212e70@square-r00t.net>
Message-ID: <d9350e9228cd2dcf9bc534d9086d2d05ff3d7cd9.camel@cryptobitch.de>

Hi,

On Mon, 2018-11-05 at 00:20 -0500, brent s. wrote:
> 
> however, this is empty in python's bindings:
> 
> _________________________________________________________________
> > > > import os
> > > > os.environ['GNUPGHOME']
> 
> '/var/tmp/python_testing/gpg/homedir'
> > > > import gpg
> > > > ctx = gpg.Context()
> > > > k = ctx.get_key('C548200C7F6AA9541F6EDFF65A6D013706B6BE26')
> > > > k.uids[0].signatures
> 
> []
> > > > 
> 
> _________________________________________________________________
> 
> 

yeah, this is one of the peculiarities of the gpgme interface.
You have to request the key list with signatures.
I'd link to the documentation, but as there is still no full HTML
version I cannot easily press Ctrl+F and search.

I have the following in my code:

    # *sigh* gpgme is killing me. With gpgme 1.8 we have to
    # set_keylist_mode before we can call keylist.  With gpgme 1.9
    # keylist takes a mode argument and overrides whatever has been
    # set before.  In order to come with something compatible with both
    # 1.8 and 1.9 we have to set_keylist_mode and NOT call ctx.keylist
    # but rather the bare op_keylist_all.  In 1.8 that requires two
    # arguments.
    mode = gpg.constants.keylist.mode.LOCAL | gpg.constants.keylist.mode.SIGS
    secret = False
    ctx.set_keylist_mode(mode)
    keys = list(ctx.op_keylist_all(key.fpr, secret))
    # With gpgme 1.9 we can simply do:
    # keys = list(ctx.keylist(key.fpr), mode=mode)


HTH,
  Tobi



From bts at square-r00t.net  Mon Nov  5 19:08:34 2018
From: bts at square-r00t.net (brent s.)
Date: Mon, 5 Nov 2018 13:08:34 -0500
Subject: python GPGME bindings and key signatures
In-Reply-To: <d9350e9228cd2dcf9bc534d9086d2d05ff3d7cd9.camel@cryptobitch.de>
References: <bc93c576-a508-8ed4-cdd3-b03f8b212e70@square-r00t.net>
 <d9350e9228cd2dcf9bc534d9086d2d05ff3d7cd9.camel@cryptobitch.de>
Message-ID: <1230b4eb-2ab2-9e7e-458e-81f2083b8421@square-r00t.net>

On 11/5/18 6:14 AM, Tobias Mueller wrote:
> yeah, this is one of the peculiarities of the gpgme interface.
> You have to request the key list with signatures.
> I'd link to the documentation, but as there is still no full HTML
> version I cannot easily press Ctrl+F and search.
> 
> I have the following in my code:
> 
>     # *sigh* gpgme is killing me. With gpgme 1.8 we have to
>     # set_keylist_mode before we can call keylist.  With gpgme 1.9
>     # keylist takes a mode argument and overrides whatever has been
>     # set before.  In order to come with something compatible with both
>     # 1.8 and 1.9 we have to set_keylist_mode and NOT call ctx.keylist
>     # but rather the bare op_keylist_all.  In 1.8 that requires two
>     # arguments.
>     mode = gpg.constants.keylist.mode.LOCAL | gpg.constants.keylist.mode.SIGS
>     secret = False
>     ctx.set_keylist_mode(mode)
>     keys = list(ctx.op_keylist_all(key.fpr, secret))
>     # With gpgme 1.9 we can simply do:
>     # keys = list(ctx.keylist(key.fpr), mode=mode)
> 
> 
> HTH,
>   Tobi
> 


Tobi -

This helps a TON. Thank you so much!

Something else I just ran into last night is it seems
gpg.constants.import is unusable due to the :

>>> import gpg
>>> gpg.constants.import.NEW
  File "<stdin>", line 1
    gpg.constants.import.NEW
                       ^
SyntaxError: invalid syntax
>>> sys.version
'3.7.1 (default, Oct 22 2018, 10:41:28) \n[GCC 8.2.1 20180831]'

I presume that's something I'll need a bug report for.

Thanks again, Tobi!

-- 
brent saner
https://square-r00t.net/
GPG info: https://square-r00t.net/gpg-info

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

From joeypabalinas at gmail.com  Tue Nov  6 04:11:49 2018
From: joeypabalinas at gmail.com (Joey Pabalinas)
Date: Mon,  5 Nov 2018 17:11:49 -1000
Subject: [PATCH] g10: fix segfault when using both --card-edit and
 --with-keygrip flags
Message-ID: <7bd077a0052b13d013ce388a9e86f9704e5c7d17.1541473387.git.joeypabalinas@gmail.com>

* g10/card-util.c (print_keygrip): Add NULL check.

Signed-off-by: Joey Pabalinas <joeypabalinas at gmail.com>
---
 g10/card-util.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/g10/card-util.c b/g10/card-util.c
index 5205798b6a9ac486ff..1f2919fc2bb0091549 100644
--- a/g10/card-util.c
+++ b/g10/card-util.c
@@ -270,10 +270,12 @@ print_shax_fpr_colon (estream_t fp,
 static void
 print_keygrip (estream_t fp, const unsigned char *grp)
 {
   int i;
 
+  if (!fp)
+    return;
   if (opt.with_keygrip)
     {
       tty_fprintf (fp, "      keygrip ....: ");
       for (i=0; i < 20 ; i++, grp++)
         es_fprintf (fp, "%02X", *grp);
-- 
Cheers,
Joey Pabalinas



From gniibe at fsij.org  Tue Nov  6 07:39:10 2018
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Tue, 06 Nov 2018 15:39:10 +0900
Subject: [PATCH] g10: fix segfault when using both --card-edit and
 --with-keygrip flags
In-Reply-To: <7bd077a0052b13d013ce388a9e86f9704e5c7d17.1541473387.git.joeypabalinas@gmail.com>
References: <7bd077a0052b13d013ce388a9e86f9704e5c7d17.1541473387.git.joeypabalinas@gmail.com>
Message-ID: <87ftwe1zht.fsf@fsij.org>

Hello,

Joey Pabalinas <joeypabalinas at gmail.com> wrote:
> * g10/card-util.c (print_keygrip): Add NULL check.

Thanks for your report.  Actually, we can print out the keygrip
information by using tty_fprint.

I pushed that change to both of master and 2.2 branch.
-- 


From joeypabalinas at gmail.com  Tue Nov  6 07:48:34 2018
From: joeypabalinas at gmail.com (Joey Pabalinas)
Date: Mon, 5 Nov 2018 20:48:34 -1000
Subject: [PATCH] g10: fix segfault when using both --card-edit and
 --with-keygrip flags
In-Reply-To: <87ftwe1zht.fsf@fsij.org>
References: <7bd077a0052b13d013ce388a9e86f9704e5c7d17.1541473387.git.joeypabalinas@gmail.com>
 <87ftwe1zht.fsf@fsij.org>
Message-ID: <20181106064834.cznzeh3ixmvyaabg@gmail.com>

On Tue, Nov 06, 2018 at 03:39:10PM +0900, NIIBE Yutaka wrote:
> Thanks for your report.  Actually, we can print out the keygrip
> information by using tty_fprint.
> 
> I pushed that change to both of master and 2.2 branch.

Yes, this fixes it on my end as well, thanks.

-- 
Cheers,
Joey Pabalinas
-------------- 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/20181105/8d2db389/attachment.sig>

From wk at gnupg.org  Tue Nov  6 12:34:40 2018
From: wk at gnupg.org (Werner Koch)
Date: Tue, 06 Nov 2018 12:34:40 +0100
Subject: [Announce] GnuPG 2.2.11 released
Message-ID: <87va5a5tin.fsf@wheatstone.g10code.de>

Hello!

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


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

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

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

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


Noteworthy changes in version 2.2.11
====================================

  * gpgsm: Fix CRL loading when intermediate certicates are not yet
    trusted.

  * gpgsm: Fix an error message about the digest algo.  [#4219]

  * gpg: Fix a wrong warning due to new sign usage check introduced
    with 2.2.9.  [#4014]

  * gpg: Print the "data source" even for an unsuccessful keyserver
    query.

  * gpg: Do not store the TOFU trust model in the trustdb.  This
    allows to enable or disable a TOFO model without triggering a
    trustdb rebuild.  [#4134]

  * scd: Fix cases of "Bad PIN" after using "forcesig".  [#4177]

  * agent: Fix possible hang in the ssh handler.  [#4221]

  * dirmngr: Tack the unmodified mail address to a WKD request.  See
    commit a2bd4a64e5b057f291a60a9499f881dd47745e2f for details.

  * dirmngr: Tweak diagnostic about missing LDAP server file.

  * dirmngr: In verbose mode print the OCSP responder id.

  * dirmngr: Fix parsing of the LDAP port.  [#4230]

  * wks: Add option --directory/-C to the server.  Always build the
    server on Unix systems.

  * wks: Add option --with-colons to the client.  Support sites which
    use the policy file instead of the submission-address file.

  * Fix EBADF when gpg et al. are called by broken CGI scripts.

  * Fix some minor memory leaks and bugs.

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


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

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

GnuPG 2.2.11 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.11.tar.bz2 (6496k)
 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.11.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.11_20181106.exe (3928k)
 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.11_20181106.exe.sig

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


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

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

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

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

     sha1sum gnupg-2.2.11.tar.bz2

   and check that the output matches the next line:

c762d300c6c5616c14abff1cfaa099baa5fcbd2c  gnupg-2.2.11.tar.bz2
e6c64cae60ced795046fd381e39ed207e94b53d2  gnupg-w32-2.2.11_20181106.tar.xz
d1b1ba1bcf433cd1accf22772600f8a5186e156c  gnupg-w32-2.2.11_20181106.exe


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

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


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

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

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

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

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

or can be downloaded as PDF at

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

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

In case of build problems specific to this release please first check
https://dev.gnupg.org/T4233 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 one full-time developer and two
contractors.  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-users'at'gnupg.org mailing list.

p.p.s
List of Release Signing Keys:
--8<---------------cut here---------------start------------->8---
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.
--8<---------------cut here---------------end--------------->8---

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

From andrewg at andrewg.com  Tue Nov  6 19:34:49 2018
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Tue, 6 Nov 2018 18:34:49 +0000
Subject: [Sks-devel] [openpgp-email] Keyservers and GDPR
In-Reply-To: <20181106165742.qul5hoxrr3fhm7ut@pep-project.org>
References: <20180522194409.tmrteipcsoorisns@calamity>
 <8f9b3617-5e52-e880-8a62-c2a2bcede122@enigmail.net>
 <B43B89C3-86BF-4636-B0A2-647329E227A2@datenreisen.de>
 <20181106165742.qul5hoxrr3fhm7ut@pep-project.org>
Message-ID: <C039F325-F64D-4958-AB5B-76226A217B63@andrewg.com>


> On 6 Nov 2018, at 16:57, Volker Birk <vb at pep-project.org> wrote:
> 
> I'm not of the opinion that key servers are a good idea at all. It's
> a pity that people still follow this wrong idea.

There are other methods for discovery that don?t suffer from the same weaknesses, but there is no equally resilient method of distributing revocations.

A


From nick.papadonis.ml at gmail.com  Wed Nov  7 07:53:56 2018
From: nick.papadonis.ml at gmail.com (Nicholas Papadonis)
Date: Wed, 7 Nov 2018 01:53:56 -0500
Subject: Support for RSA keys > 4096 bits
In-Reply-To: <CAKD0t1KN2nMdytuApzAFxq0MV_YwxM7qJrcb0V0Qxq58=o01Gg@mail.gmail.com>
References: <CAKD0t1KN2nMdytuApzAFxq0MV_YwxM7qJrcb0V0Qxq58=o01Gg@mail.gmail.com>
Message-ID: <CAKD0t1K0Qg4FYhRVCzemoYoC4d3xu3k=G8HWrxCWp5mQB7EifQ@mail.gmail.com>

For those interested, link to the NIST document:

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf

On Wed, Nov 7, 2018 at 1:50 AM Nicholas Papadonis <
nick.papadonis.ml at gmail.com> wrote:

> I read in NIST 800-57 Part 1 Rev. 4 pg 53 that RSA keys length of 15360
> bits is equivalent to a 256 bit AES symmetric key.  I also read in other
> documentation that NIST recommends such key lengths to protect data beyond
> 2030.  As email may be retained for many years it would seem appropriate to
> secure such communications with a larger key.
>
> Does this data agree with security experts?  Is there a reason why GnuPG
> limits RSA key length to 4096 bits?
>
> Thank you,
> Nicholas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20181107/dc584d2c/attachment.html>

From nick.papadonis.ml at gmail.com  Wed Nov  7 07:50:03 2018
From: nick.papadonis.ml at gmail.com (Nicholas Papadonis)
Date: Wed, 7 Nov 2018 01:50:03 -0500
Subject: Support for RSA keys > 4096 bits
Message-ID: <CAKD0t1KN2nMdytuApzAFxq0MV_YwxM7qJrcb0V0Qxq58=o01Gg@mail.gmail.com>

I read in NIST 800-57 Part 1 Rev. 4 pg 53 that RSA keys length of 15360
bits is equivalent to a 256 bit AES symmetric key.  I also read in other
documentation that NIST recommends such key lengths to protect data beyond
2030.  As email may be retained for many years it would seem appropriate to
secure such communications with a larger key.

Does this data agree with security experts?  Is there a reason why GnuPG
limits RSA key length to 4096 bits?

Thank you,
Nicholas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20181107/f7770aca/attachment.html>

From wiktor at metacode.biz  Wed Nov  7 08:14:14 2018
From: wiktor at metacode.biz (Wiktor Kwapisiewicz)
Date: Wed, 7 Nov 2018 08:14:14 +0100
Subject: Support for RSA keys > 4096 bits
In-Reply-To: <CAKD0t1K0Qg4FYhRVCzemoYoC4d3xu3k=G8HWrxCWp5mQB7EifQ@mail.gmail.com>
References: <CAKD0t1KN2nMdytuApzAFxq0MV_YwxM7qJrcb0V0Qxq58=o01Gg@mail.gmail.com>
 <CAKD0t1K0Qg4FYhRVCzemoYoC4d3xu3k=G8HWrxCWp5mQB7EifQ@mail.gmail.com>
Message-ID: <83d2deb1-ac77-4ba9-6eae-bcdc974d18d2@metacode.biz>

Hi Nicolas,

There is also this site that may be of interest:

https://www.keylength.com/

As for your question, actually that was answered in GnuPG FAQ:

https://www.gnupg.org/faq/gnupg-faq.html#default_rsa2048

Kind regards,
Wiktor

On 07.11.2018 07:53, Nicholas Papadonis wrote:
> For those interested, link to the NIST document:
> 
> https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf
> 
> On Wed, Nov 7, 2018 at 1:50 AM Nicholas Papadonis
> <nick.papadonis.ml at gmail.com <mailto:nick.papadonis.ml at gmail.com>> wrote:
> 
>     I read in NIST?800-57 Part 1 Rev. 4 pg 53 that RSA keys length of
>     15360 bits is equivalent to a 256 bit AES symmetric key.? I also
>     read in other documentation that NIST recommends such key lengths to
>     protect data beyond 2030.? As email may be retained for many years
>     it would seem appropriate to secure such communications with a
>     larger key.
> 
>     Does this data agree with security experts?? Is there a reason why
>     GnuPG limits RSA key length to 4096 bits?
> 
>     Thank you,
>     Nicholas
> 
> 
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
> 


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


From wk at gnupg.org  Wed Nov  7 10:08:19 2018
From: wk at gnupg.org (Werner Koch)
Date: Wed, 07 Nov 2018 10:08:19 +0100
Subject: [openpgp-email] Keyservers and GDPR
In-Reply-To: <20181106165742.qul5hoxrr3fhm7ut@pep-project.org> (Volker Birk's
 message of "Tue, 6 Nov 2018 17:57:42 +0100")
References: <20180522194409.tmrteipcsoorisns@calamity>
 <8f9b3617-5e52-e880-8a62-c2a2bcede122@enigmail.net>
 <B43B89C3-86BF-4636-B0A2-647329E227A2@datenreisen.de>
 <20181106165742.qul5hoxrr3fhm7ut@pep-project.org>
Message-ID: <87in1945mk.fsf@wheatstone.g10code.de>

On Tue,  6 Nov 2018 17:57, vb at pep-project.org said:

> I'm not of the opinion that key servers are a good idea at all. It's
> a pity that people still follow this wrong idea.

Keyservers are used for several purposes:

1. Search for keys based on the fingerprint ("gpg --recv-key FPR")
2. Search for key recovations ("gpg --refresh-key")
3. Search for keys based on the user id.  (e.g. "gpg --search-key")
4. As a distribution medium for key signatures.
5. As a distributed and searchable storage.

The first two purposes are quite useful because they allow to verify
signatures made by yet unknown keys. Retrieving the keys is no data
privacy problem because by signing and sending a mail the sender has
already provided all these information.  There is nothing which can
replace these purposes because a key does not necessary need to have a
mail address and even if so, any mail address based lookup can fail
after the mail address is not longer in use, the account has been
disabled, etc.  Fingerprints are are globally unique and need not be
associated with a mail address.

Purpose 3 is what we call key discovery and indeed keyservers are the
wrong way to do this.  In most cases we want to map a mail address to a
key and have some kind of reliable mapping.  Keyservers which are just a
pile of keys don't allow for this.  Back then when encryption was young
and the internet was a friendly place search for keys worked in most
cases.  But the times have changed and the bona fide search is useless.

Purpose 4, distribution of key signatures, worked as long as people
didn't used the key listings of the server or tools for more or less
funny messages.  Uploading key signature should be possible only by the
holder of the key.  However, to enforce this the keyservers need to
employ real crypto and won't be a lean service anymore.  I think the
distribution of keyservers, for those who still want to use the WoT,
can be replaced by sending the signed keys only back to owner.  In fact
tools like caff suggest this use case.

Purpose 5 is not relevant for OpenPGP key distribution and actually the
reason why the keyserver network has more or less broken down.

My suggestion is limit the keyservers to the purposes 1 and 2.  This
can in practice easily be done by removing the search by user-id
interface form the keyservers and, on the client site, by discovering
keys using other methods (e.g. Web Key Directory).  Having no searchable
interface to the keyservers make them less attractive for abuse (as in
purpose 5) and avoid some privacy issues (white pages without user
consent).

It is likely that gpg will eventually change its --search-key command to
do the equivalent of --locate-key but without checking the local
keyring.


Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20181107/6fbdbe1d/attachment.sig>

From wk at gnupg.org  Wed Nov  7 10:13:06 2018
From: wk at gnupg.org (Werner Koch)
Date: Wed, 07 Nov 2018 10:13:06 +0100
Subject: [openpgp-email] Keyservers and GDPR
In-Reply-To: <B43B89C3-86BF-4636-B0A2-647329E227A2@datenreisen.de> (Andy
 Mueller-Maguhn's message of "Tue, 6 Nov 2018 17:27:14 +0100")
References: <20180522194409.tmrteipcsoorisns@calamity>
 <8f9b3617-5e52-e880-8a62-c2a2bcede122@enigmail.net>
 <B43B89C3-86BF-4636-B0A2-647329E227A2@datenreisen.de>
Message-ID: <87efbx45el.fsf@wheatstone.g10code.de>

On Tue,  6 Nov 2018 17:27, amm at datenreisen.de said:

> I do roughly recal that such a verification process has been discussed for
> the SKS keyservers at one of the pgp-summit before, but i wonder what
> happened to the idea. However, if it that is ?good enough? to be compliant

This requires that there are no rogue keyservers in the network and that
in turn means that they are under the control of a single entity.  Or
in short, let Google take care of it.

Such verification will be a single point of failure and it would be
trivial for governments or corporations to take down a key.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20181107/38eed729/attachment-0001.sig>

From andrewg at andrewg.com  Wed Nov  7 11:50:07 2018
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Wed, 7 Nov 2018 10:50:07 +0000
Subject: [Sks-devel] [openpgp-email] Keyservers and GDPR
In-Reply-To: <PiVBHC26BgSv4UCot6DeanJAfeALwS3zd4aId4pM22d9@mailpile>
References: <87in1945mk.fsf@wheatstone.g10code.de>
 <PiVBHC26BgSv4UCot6DeanJAfeALwS3zd4aId4pM22d9@mailpile>
Message-ID: <FA078626-353E-46A0-986F-070DA6839662@andrewg.com>


> On 7 Nov 2018, at 10:16, Yegor Timoshenko <yegortimoshenko at riseup.net> wrote:
> 
> World-writable storage is problematic even if there is no search.
> Proof of work and some operator-controllable data removal
> mechanism (like opt-in key blacklists) can help limit this attack
> vector.
> 
> Storing immutable data, distributed recon, proof of work, that
> sounds like something a blockchain should do to me.

More evidence that blockchain is a solution in search of a problem! :-)

Proof of work verification provides little benefit over cryptographic verification. If you have already generated a valid signature, that is in itself a proof of work. The only reason you would also use hashcash is if you wanted to increase the difficulty of the work beyond what the cryptography itself provides. But hashcash only works if it is possible to find a difficulty level that impedes abuse while not significantly affecting legitimate use. It may stop people uploading warez but it can?t prevent cheap vandalism. 

A


From wiktor at metacode.biz  Wed Nov  7 12:33:00 2018
From: wiktor at metacode.biz (Wiktor Kwapisiewicz)
Date: Wed, 7 Nov 2018 12:33:00 +0100
Subject: [Sks-devel] [openpgp-email] Keyservers and GDPR
In-Reply-To: <FA078626-353E-46A0-986F-070DA6839662@andrewg.com>
References: <87in1945mk.fsf@wheatstone.g10code.de>
 <PiVBHC26BgSv4UCot6DeanJAfeALwS3zd4aId4pM22d9@mailpile>
 <FA078626-353E-46A0-986F-070DA6839662@andrewg.com>
Message-ID: <a839b888-b969-623d-477b-99edd61c34e5@metacode.biz>

On 07.11.2018 11:50, Andrew Gallagher wrote:
> 
>> On 7 Nov 2018, at 10:16, Yegor Timoshenko <yegortimoshenko at riseup.net> wrote:
>>
>> World-writable storage is problematic even if there is no search.
>> Proof of work and some operator-controllable data removal
>> mechanism (like opt-in key blacklists) can help limit this attack
>> vector.
>>
>> Storing immutable data, distributed recon, proof of work, that
>> sounds like something a blockchain should do to me.
> 
> More evidence that blockchain is a solution in search of a problem! :-)
> 
> Proof of work verification provides little benefit over cryptographic verification. If you have already generated a valid signature, that is in itself a proof of work. The only reason you would also use hashcash is if you wanted to increase the difficulty of the work beyond what the cryptography itself provides. But hashcash only works if it is possible to find a difficulty level that impedes abuse while not significantly affecting legitimate use. It may stop people uploading warez but it can?t prevent cheap vandalism. 

Blockchain can be used to timestamp data in a way that is evident to a
broad audience. If cryptographic verification was enough for X.509 there
wouldn't be Certificate Transparency (that uses similar primitives) and
CT is required for all issued "SSL certificates" today [0].

For OpenPGP that would mean keeping the keyservers accountable: not
letting them return different responses for different people, or
omitting some data (e.g. revocations).

There are already projects that tackle this very problem:
  - https://coniks.cs.princeton.edu/about.html
  -
https://security.googleblog.com/2017/01/security-through-transparency.html
  -
https://blog.okturtles.org/2017/02/coniks-vs-key-transparency-vs-certificate-transparency-vs-blockchains/

(For the record I'm not advocating for using blockchain, but even a
buzzword tech should be evaluated purely on its merits)

Kind regards,
Wiktor

[0]:
https://www.thesslstore.com/blog/certificate-transparency-april-30-2018/

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


From wk at gnupg.org  Wed Nov  7 17:34:44 2018
From: wk at gnupg.org (Werner Koch)
Date: Wed, 07 Nov 2018 17:34:44 +0100
Subject: [Sks-devel] [openpgp-email] Keyservers and GDPR
In-Reply-To: <FA078626-353E-46A0-986F-070DA6839662@andrewg.com> (Andrew
 Gallagher's message of "Wed, 7 Nov 2018 10:50:07 +0000")
References: <87in1945mk.fsf@wheatstone.g10code.de>
 <PiVBHC26BgSv4UCot6DeanJAfeALwS3zd4aId4pM22d9@mailpile>
 <FA078626-353E-46A0-986F-070DA6839662@andrewg.com>
Message-ID: <87h8gs26e3.fsf@wheatstone.g10code.de>

On Wed,  7 Nov 2018 11:50, andrewg at andrewg.com said:

> significantly affecting legitimate use. It may stop people uploading
> warez but it can?t prevent cheap vandalism.

Free storage to upload arbitrary data is easily available (e.g. p2p,
free mail accounts).  Having a searchable index to that data is more
challenging.  Thus removing the search capability from the keyservers
will render its free-as-in-beer storage feature mostly useless.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20181107/549e18e2/attachment.sig>

From andrewg at andrewg.com  Wed Nov  7 17:51:23 2018
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Wed, 7 Nov 2018 16:51:23 +0000
Subject: [Sks-devel] [openpgp-email] Keyservers and GDPR
In-Reply-To: <Kf9PbwCcBrRYbC5P9knEdGe6XTENEgqqKEnJsZv922d9@mailpile>
References: <87h8gs26e3.fsf@wheatstone.g10code.de>
 <Kf9PbwCcBrRYbC5P9knEdGe6XTENEgqqKEnJsZv922d9@mailpile>
Message-ID: <D102A90A-52C5-4751-B914-41BFDA8F4921@andrewg.com>


> On 7 Nov 2018, at 16:43, Yegor Timoshenko <yegortimoshenko at riseup.net> wrote:
> 
> It's not just storage, it's also immutable and distributed.

In the keyservers, removing immutable content is a Very Hard Problem, but it is theoretically possible. 

With blockchain, it is impossible by design. 

A


From muelli at cryptobitch.de  Wed Nov  7 18:07:07 2018
From: muelli at cryptobitch.de (Tobias Mueller)
Date: Wed, 07 Nov 2018 18:07:07 +0100
Subject: [Autocrypt] [Sks-devel] [openpgp-email] Keyservers and GDPR
In-Reply-To: <87h8gs26e3.fsf@wheatstone.g10code.de>
References: <87in1945mk.fsf@wheatstone.g10code.de>
 <PiVBHC26BgSv4UCot6DeanJAfeALwS3zd4aId4pM22d9@mailpile>
 <FA078626-353E-46A0-986F-070DA6839662@andrewg.com>
 <87h8gs26e3.fsf@wheatstone.g10code.de>
Message-ID: <c5d6c9e112858b56a6d70872ff6aadf51c8c3084.camel@cryptobitch.de>

On Wed, 2018-11-07 at 17:34 +0100, Werner Koch wrote:
> Thus removing the search capability from the keyservers
> will render its free-as-in-beer storage feature mostly useless.
Only if you assume that nobody creates such an index.

Cheers,
  Tobi



From muelli at cryptobitch.de  Wed Nov  7 18:07:48 2018
From: muelli at cryptobitch.de (Tobias Mueller)
Date: Wed, 07 Nov 2018 18:07:48 +0100
Subject: [Autocrypt] [openpgp-email] Keyservers and GDPR
In-Reply-To: <87efbx45el.fsf@wheatstone.g10code.de>
References: <20180522194409.tmrteipcsoorisns@calamity>
 <8f9b3617-5e52-e880-8a62-c2a2bcede122@enigmail.net>
 <B43B89C3-86BF-4636-B0A2-647329E227A2@datenreisen.de>
 <87efbx45el.fsf@wheatstone.g10code.de>
Message-ID: <b6c967359c831dfa6c2903f6145e5a7b70ee35bc.camel@cryptobitch.de>

Hi,

On Wed, 2018-11-07 at 10:13 +0100, Werner Koch wrote:
> This requires that there are no rogue keyservers in the network and
> that
> in turn means that they are under the control of a single entity.
It depends on your use case, but you might be happy enough if you have a
proof of who introduced the malicious data.

That said, you might as well establish a network adhering to certain
rules run by people who are trusted enough by its users. That may not
necessarily be Google, but the EFF, the CCC, or the DPAs of the EU
member states.

Cheers,
  Tobi



From muelli at cryptobitch.de  Wed Nov  7 18:17:25 2018
From: muelli at cryptobitch.de (Tobias Mueller)
Date: Wed, 07 Nov 2018 18:17:25 +0100
Subject: [Autocrypt] [Sks-devel] [openpgp-email] Keyservers and GDPR
In-Reply-To: <a839b888-b969-623d-477b-99edd61c34e5@metacode.biz>
References: <87in1945mk.fsf@wheatstone.g10code.de>
 <PiVBHC26BgSv4UCot6DeanJAfeALwS3zd4aId4pM22d9@mailpile>
 <FA078626-353E-46A0-986F-070DA6839662@andrewg.com>
 <a839b888-b969-623d-477b-99edd61c34e5@metacode.biz>
Message-ID: <690a23b50bc357b584dd9e585cba1c46bc3550c3.camel@cryptobitch.de>

Hi,

On Wed, 2018-11-07 at 12:33 +0100, Wiktor Kwapisiewicz via Autocrypt
wrote:
> If cryptographic verification was enough for X.509 there
> wouldn't be Certificate Transparency
CT solves a slightly different set of problems related to
the centralised trust model that we don't necessarily have.

That said, I think we can store revocations in the CT logs s.t. we can
at least have integrity protection and non-equivocation for those. Both
properties which we currently do not have when fetching them from the
key server.


Cheers,
  Tobi



From wiktor at metacode.biz  Wed Nov  7 18:30:33 2018
From: wiktor at metacode.biz (Wiktor Kwapisiewicz)
Date: Wed, 7 Nov 2018 18:30:33 +0100
Subject: [Autocrypt] [Sks-devel] [openpgp-email] Keyservers and GDPR
In-Reply-To: <690a23b50bc357b584dd9e585cba1c46bc3550c3.camel@cryptobitch.de>
References: <87in1945mk.fsf@wheatstone.g10code.de>
 <PiVBHC26BgSv4UCot6DeanJAfeALwS3zd4aId4pM22d9@mailpile>
 <FA078626-353E-46A0-986F-070DA6839662@andrewg.com>
 <a839b888-b969-623d-477b-99edd61c34e5@metacode.biz>
 <690a23b50bc357b584dd9e585cba1c46bc3550c3.camel@cryptobitch.de>
Message-ID: <84d3b677-668f-fc47-3db2-3393a5785bce@metacode.biz>

Hello,

On 07.11.2018 18:17, Tobias Mueller wrote:
> That said, I think we can store revocations in the CT logs s.t. we can
> at least have integrity protection and non-equivocation for those. Both
> properties which we currently do not have when fetching them from the
> key server.

Mozilla experimented with storing release hashes of Firefox in CT logs:
https://wiki.mozilla.org/Security/Binary_Transparency

They used Merkle tree so the amount of data stored is small (just the
tree head) compared to the OpenPGP revocation.

Kind regards,
Wiktor

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


From jussi.kivilinna at iki.fi  Wed Nov  7 18:38:44 2018
From: jussi.kivilinna at iki.fi (Jussi Kivilinna)
Date: Wed, 7 Nov 2018 19:38:44 +0200
Subject: [PATCH 1/8] g10/decrypt-data: use fill_buffer in more places
In-Reply-To: <87efc8j27s.fsf@wheatstone.g10code.de>
References: <154067434467.18498.15345072060569568612.stgit@localhost.localdomain>
 <87efc8j27s.fsf@wheatstone.g10code.de>
Message-ID: <54830753-1826-03d9-6e16-6e42bb822e5c@iki.fi>

Hello,

On 29.10.2018 15.45, Werner Koch wrote:
> Hi!
> 
> All patches look fine to me.  After applying we should however run
> extensive tests against another implementation to see whether we have
> any breakage.  With the current code this has been with the help of
> the www.rnpgp.com folks.

Should I push this patch set to new branch in gnupg repo?

I've also looked at disabling extra hash contexts when decrypting
non-signed files. Could those contexts be disabled when any AEAD or
MDC encrypted packet is seen? Such patch would look something this:

diff --git a/g10/mainproc.c b/g10/mainproc.c
index 5b7bc9555..4309b52ac 100644
--- a/g10/mainproc.c
+++ b/g10/mainproc.c
@@ -91,6 +91,8 @@ struct mainproc_context
                                      has been seen. */
     unsigned int data:1;          /* Any data packet seen */
     unsigned int uncompress_failed:1;
+    unsigned int seen_encrypted_mdc:1; /* Any PKT_ENCRYPTED_MDC packet seen */
+    unsigned int seen_encrypted_aead:1; /* Any PKT_ENCRYPTED_AEAD packet seen */
   } any;
 };
 
@@ -536,6 +538,9 @@ proc_encrypted (CTX c, PACKET *pkt)
   int result = 0;
   int early_plaintext = literals_seen;
 
+  c->any.seen_encrypted_mdc |= (pkt->pkttype == PKT_ENCRYPTED_MDC);
+  c->any.seen_encrypted_aead |= (pkt->pkttype == PKT_ENCRYPTED_AEAD);
+
   if (early_plaintext)
     {
       log_info (_("WARNING: multiple plaintexts seen\n"));

@@ -874,7 +878,8 @@ proc_plaintext( CTX c, PACKET *pkt )
         }
     }
 
-  if (!any && !opt.skip_verify)
+  if (!any && !opt.skip_verify && !c->any.seen_encrypted_mdc &&
+      !c->any.seen_encrypted_aead)
     {
       /* This is for the old GPG LITERAL+SIG case.  It's not legal
          according to 2440, so hopefully it won't come up that often.


-Jussi


From wk at gnupg.org  Wed Nov  7 20:49:29 2018
From: wk at gnupg.org (Werner Koch)
Date: Wed, 07 Nov 2018 20:49:29 +0100
Subject: [PATCH 1/8] g10/decrypt-data: use fill_buffer in more places
In-Reply-To: <54830753-1826-03d9-6e16-6e42bb822e5c@iki.fi> (Jussi Kivilinna's
 message of "Wed, 7 Nov 2018 19:38:44 +0200")
References: <154067434467.18498.15345072060569568612.stgit@localhost.localdomain>
 <87efc8j27s.fsf@wheatstone.g10code.de>
 <54830753-1826-03d9-6e16-6e42bb822e5c@iki.fi>
Message-ID: <87k1lozn06.fsf@wheatstone.g10code.de>

On Wed,  7 Nov 2018 18:38, jussi.kivilinna at iki.fi said:

> Should I push this patch set to new branch in gnupg repo?

Just go ahead and push it directly to master.

> I've also looked at disabling extra hash contexts when decrypting
> non-signed files. Could those contexts be disabled when any AEAD or
> MDC encrypted packet is seen? Such patch would look something this:

While looking at your patches I was reminded to check whether we have
some useless hash context running. 

> +    unsigned int seen_encrypted_mdc:1; /* Any PKT_ENCRYPTED_MDC packet seen */
> +    unsigned int seen_encrypted_aead:1; /* Any PKT_ENCRYPTED_AEAD packet seen */

There is either one MDC packet or one AEAD packet.

> -  if (!any && !opt.skip_verify)
> +  if (!any && !opt.skip_verify && !c->any.seen_encrypted_mdc &&
> +      !c->any.seen_encrypted_aead)
>      {
>        /* This is for the old GPG LITERAL+SIG case.  It's not legal
>           according to 2440, so hopefully it won't come up that often.

For sure this is not possible with AEAD.  With MDC it is unlikely but I
think we should not touch that case given that the goal is to fade out
the use of MDC.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20181107/d3bac5bf/attachment.sig>

From wk at gnupg.org  Wed Nov  7 20:52:35 2018
From: wk at gnupg.org (Werner Koch)
Date: Wed, 07 Nov 2018 20:52:35 +0100
Subject: [Autocrypt] [Sks-devel] [openpgp-email] Keyservers and GDPR
In-Reply-To: <c5d6c9e112858b56a6d70872ff6aadf51c8c3084.camel@cryptobitch.de>
 (Tobias Mueller's message of "Wed, 07 Nov 2018 18:07:07 +0100")
References: <87in1945mk.fsf@wheatstone.g10code.de>
 <PiVBHC26BgSv4UCot6DeanJAfeALwS3zd4aId4pM22d9@mailpile>
 <FA078626-353E-46A0-986F-070DA6839662@andrewg.com>
 <87h8gs26e3.fsf@wheatstone.g10code.de>
 <c5d6c9e112858b56a6d70872ff6aadf51c8c3084.camel@cryptobitch.de>
Message-ID: <87ftwczmv0.fsf@wheatstone.g10code.de>

On Wed,  7 Nov 2018 18:07, muelli at cryptobitch.de said:

> Only if you assume that nobody creates such an index.

But then it is not a problem for keyserver operators (except for load
issues).


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20181107/43238ca5/attachment.sig>

From ingvar at redpill-linpro.com  Thu Nov  8 09:44:09 2018
From: ingvar at redpill-linpro.com (Ingvar Hagelund)
Date: Thu, 8 Nov 2018 09:44:09 +0100
Subject: [PATCH] Fix for simple typo in the Norwegian translation
Message-ID: <ba7e44f1-0188-3836-cba8-4da641c2af1e@redpill-linpro.com>

Here's a fix for a simple typo in the Norwegian translation.

br,
Ingvar Hagelund



GnuPG Developer's Certificate of Origin.  Version 1.0
=====================================================

By making a contribution to the GnuPG project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the free software license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the
    best of my knowledge, is covered under an appropriate free
    software license and I have the right under that license to
    submit that work with modifications, whether created in whole
    or in part by me, under the same free software license
    (unless I am permitted to submit under a different license),
    as indicated in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including
    all personal information I submit with it, including my
    sign-off) is maintained indefinitely and may be redistributed
    consistent with this project or the free software license(s)
    involved.

Signed-off-by: Ingvar Hagelund <ingvar at redpill-linpro.com>



commit bc77d3b173507bc7b43429ce62bcae849e62caa4 (HEAD -> fix_nb)
Author: Ingvar Hagelund <ingvar at redpill-linpro.com>
Date:   Thu Nov 8 09:33:46 2018 +0100

    Correcting a simple typo in the Norwegian translation

diff --git a/po/nb.po b/po/nb.po
index c6694e7e5..c040c44e8 100644
--- a/po/nb.po
+++ b/po/nb.po
@@ -3180,7 +3180,7 @@ msgid "Really sign all text user IDs? (y/N) "
 msgstr "Er du sikker p? at du vil signerere alle bruker-id-er? (j/N) "

 msgid "Really sign all user IDs? (y/N) "
-msgstr "Er du sikekr p? at du vil signerere alle bruker-id-er? (j/N) "
+msgstr "Er du sikker p? at du vil signerere alle bruker-id-er? (j/N) "

 msgid "Hint: Select the user IDs to sign\n"
 msgstr "Tips: Velg bruker-id-en(e) du vil signere\n"

-------------- 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/20181108/b46241c0/attachment.sig>

From jussi.kivilinna at iki.fi  Thu Nov  8 19:38:47 2018
From: jussi.kivilinna at iki.fi (Jussi Kivilinna)
Date: Thu, 8 Nov 2018 20:38:47 +0200
Subject: [PATCH 1/8] g10/decrypt-data: use fill_buffer in more places
In-Reply-To: <87k1lozn06.fsf@wheatstone.g10code.de>
References: <154067434467.18498.15345072060569568612.stgit@localhost.localdomain>
 <87efc8j27s.fsf@wheatstone.g10code.de>
 <54830753-1826-03d9-6e16-6e42bb822e5c@iki.fi>
 <87k1lozn06.fsf@wheatstone.g10code.de>
Message-ID: <c15e9837-5138-a204-8a53-98eb58c369d4@iki.fi>

On 7.11.2018 21.49, Werner Koch wrote:
> On Wed,  7 Nov 2018 18:38, jussi.kivilinna at iki.fi said:
> 
>> Should I push this patch set to new branch in gnupg repo?
> 
> Just go ahead and push it directly to master.
> 
>> I've also looked at disabling extra hash contexts when decrypting
>> non-signed files. Could those contexts be disabled when any AEAD or
>> MDC encrypted packet is seen? Such patch would look something this:
> 
> While looking at your patches I was reminded to check whether we have
> some useless hash context running. 
> 
>> +    unsigned int seen_encrypted_mdc:1; /* Any PKT_ENCRYPTED_MDC packet seen */
>> +    unsigned int seen_encrypted_aead:1; /* Any PKT_ENCRYPTED_AEAD packet seen */
> 
> There is either one MDC packet or one AEAD packet.
> 
>> -  if (!any && !opt.skip_verify)
>> +  if (!any && !opt.skip_verify && !c->any.seen_encrypted_mdc &&
>> +      !c->any.seen_encrypted_aead)
>>      {
>>        /* This is for the old GPG LITERAL+SIG case.  It's not legal
>>           according to 2440, so hopefully it won't come up that often.
> 
> For sure this is not possible with AEAD.  With MDC it is unlikely but I
> think we should not touch that case given that the goal is to fade out
> the use of MDC.
> 

Ok, I'll make patch AEAD only. For CFB/MDC, user can of course use 
--skip-verify if they know that input does not have signature and want
to get highest performance.

Here's results that I've seen with patch/--skip-verify for different types
of input on my machine (2GiB input file from ramfs):

decrypting MDC encrypted, signed (AES128+SHA1(mdc)+SHA512(sign)):
 user 5.2s, 364 MB/s
decrypting MDC encrypted, not signed (AES128+2xSHA1(mdc+extra)+RMD160(extra)):
 user 9.6s, 206 MB/s
decrypting MDC encrypted, not signed --skip-verify (AES128+SHA1(mdc)):
 user 3.0s, 575 MB/s

decrypting MDC symmetric encrypted, not signed (AES128+SHA1(mdc+extra)+RMD160(extra)):
 user 9.7s, 205 MB/s
decrypting MDC symmetric encrypted, not signed --skip-verify (AES128+SHA1(mdc)):
 user 3.1s, 556 MB/s

decrypting AEAD encrypted, signed (AES128_OCB+SHA512(sign)):
 user 4.7s, 387 MB/s
decrypting AEAD encrypted, not signed (AES128_OCB+SHA1(extra)+RMD160(extra)):
 user 7.6s, 258 MB/s
decrypting AEAD encrypted, not signed --skip-verify or patched (AES128_OCB):
 user 0.95s, 1.2 GB/s

decrypting AEAD symmetric encrypted, not signed (AES128_OCB+SHA1(extra)+RMD160(extra)):
 user 7.6s, 256 MB/s
decrypting AEAD symmetric encrypted, not signed --skip-verify or patched (AES128_OCB):
 user 1.1s, 1.1 GB/s

I also noticed that --skip-verify does not affect decryption speed of
signed input. Selected digest algorithm gets enabled regardless of 
--skip-verify in proc_plaintext(). Should this be fixed?

-Jussi

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

From jussi.kivilinna at iki.fi  Thu Nov  8 21:19:15 2018
From: jussi.kivilinna at iki.fi (Jussi Kivilinna)
Date: Thu,  8 Nov 2018 22:19:15 +0200
Subject: [PATCH] g10/mainproc: avoid extra hash contexts when decrypting AEAD
 input
Message-ID: <154170835500.7973.17202438053527160722.stgit@localhost.localdomain>

* g10/mainproc.c (mainproc_context): New member
'seen_pkt_encrypted_aead'.
(release_list): Clear 'seen_pkt_encrypted_aead'.
(proc_encrypted): Set 'seen_pkt_encrypted_aead'.
(have_seen_pkt_encrypted_aead): New.
(proc_plaintext): Do not enable extra hash contexts when decryption
AEAD input.
--

Signed-off-by: Jussi Kivilinna <jussi.kivilinna at iki.fi>
---
 0 files changed

diff --git a/g10/mainproc.c b/g10/mainproc.c
index 5b7bc9555..7eceb7e0b 100644
--- a/g10/mainproc.c
+++ b/g10/mainproc.c
@@ -86,6 +86,7 @@ struct mainproc_context
   int trustletter;  /* Temporary usage in list_node. */
   ulong symkeys;    /* Number of symmetrically encrypted session keys.  */
   struct pubkey_enc_list *pkenc_list; /* List of encryption packets. */
+  int seen_pkt_encrypted_aead; /* PKT_ENCRYPTED_AEAD packet seen. */
   struct {
     unsigned int sig_seen:1;      /* Set to true if a signature packet
                                      has been seen. */
@@ -137,6 +138,7 @@ release_list( CTX c )
   c->any.data = 0;
   c->any.uncompress_failed = 0;
   c->last_was_session_key = 0;
+  c->seen_pkt_encrypted_aead = 0;
   xfree (c->dek);
   c->dek = NULL;
 }
@@ -536,6 +538,9 @@ proc_encrypted (CTX c, PACKET *pkt)
   int result = 0;
   int early_plaintext = literals_seen;
 
+  if (pkt->pkttype == PKT_ENCRYPTED_AEAD)
+    c->seen_pkt_encrypted_aead = 1;
+
   if (early_plaintext)
     {
       log_info (_("WARNING: multiple plaintexts seen\n"));
@@ -704,7 +709,6 @@ proc_encrypted (CTX c, PACKET *pkt)
 
     }
 
-
   if (!result)
     result = decrypt_data (c->ctrl, c, pkt->pkt.encrypted, c->dek );
 
@@ -804,6 +808,21 @@ proc_encrypted (CTX c, PACKET *pkt)
 }
 
 
+static int
+have_seen_pkt_encrypted_aead( CTX c )
+{
+  CTX cc;
+
+  for (cc = c; cc; cc = cc->anchor)
+    {
+      if (cc->seen_pkt_encrypted_aead)
+	return 1;
+    }
+
+  return 0;
+}
+
+
 static void
 proc_plaintext( CTX c, PACKET *pkt )
 {
@@ -874,7 +893,7 @@ proc_plaintext( CTX c, PACKET *pkt )
         }
     }
 
-  if (!any && !opt.skip_verify)
+  if (!any && !opt.skip_verify && !have_seen_pkt_encrypted_aead(c))
     {
       /* This is for the old GPG LITERAL+SIG case.  It's not legal
          according to 2440, so hopefully it won't come up that often.



From wk at gnupg.org  Fri Nov  9 14:46:18 2018
From: wk at gnupg.org (Werner Koch)
Date: Fri, 09 Nov 2018 14:46:18 +0100
Subject: [PATCH] g10/mainproc: avoid extra hash contexts when decrypting
 AEAD input
In-Reply-To: <154170835500.7973.17202438053527160722.stgit@localhost.localdomain>
 (Jussi Kivilinna's message of "Thu, 8 Nov 2018 22:19:15 +0200")
References: <154170835500.7973.17202438053527160722.stgit@localhost.localdomain>
Message-ID: <87zhuitlcl.fsf@wheatstone.g10code.de>

Hi!

Looks good to me.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20181109/0d44c6bb/attachment.sig>

From jussi.kivilinna at iki.fi  Fri Nov  9 17:48:07 2018
From: jussi.kivilinna at iki.fi (Jussi Kivilinna)
Date: Fri,  9 Nov 2018 18:48:07 +0200
Subject: [PATCH 1/2] common/mischelp: use memset for wipememory
Message-ID: <154178208738.8762.5265325772335861348.stgit@localhost.localdomain>

* common/mischelp.h (wipememory2): Replace macro with function
prototype.
* common/mischelp.c (wipememory2): New.
--

In new wipememory2 function, memset is called through volatile
function pointer to so that compiler won't optimize away the call.

Signed-off-by: Jussi Kivilinna <jussi.kivilinna at iki.fi>
---
 common/mischelp.c |   10 ++++++++++
 common/mischelp.h |   12 ++++--------
 2 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/common/mischelp.c b/common/mischelp.c
index 75ba60714..008aaab55 100644
--- a/common/mischelp.c
+++ b/common/mischelp.c
@@ -49,6 +49,16 @@
 #include "mischelp.h"
 
 
+void
+wipememory2 (void *ptr, int set, size_t len)
+{
+  /* Prevent compiler from optimizing away the call to memset by accessing
+     memset through volatile pointer. */
+  static void *(*volatile memset_ptr)(void *, int, size_t) = (void *)memset;
+  memset_ptr (ptr, set, len);
+}
+
+
 /* Check whether the files NAME1 and NAME2 are identical.  This is for
    example achieved by comparing the inode numbers of the files.  */
 int
diff --git a/common/mischelp.h b/common/mischelp.h
index 18ec96edf..2554c2160 100644
--- a/common/mischelp.h
+++ b/common/mischelp.h
@@ -47,14 +47,10 @@ time_t timegm (struct tm *tm);
 #define DIM(v)		     (sizeof(v)/sizeof((v)[0]))
 #define DIMof(type,member)   DIM(((type *)0)->member)
 
-/* To avoid that a compiler optimizes certain memset calls away, these
-   macros may be used instead. */
-#define wipememory2(_ptr,_set,_len) do { \
-              volatile char *_vptr=(volatile char *)(_ptr); \
-              size_t _vlen=(_len); \
-              while(_vlen) { *_vptr=(_set); _vptr++; _vlen--; } \
-                  } while(0)
-#define wipememory(_ptr,_len) wipememory2(_ptr,0,_len)
+/* To avoid that a compiler optimizes certain memset calls away,
+   wipememory function and macro may be used instead.  */
+void wipememory2(void *ptr, int set, size_t len);
+#define wipememory(_ptr,_len) wipememory2((_ptr),0,(_len))
 
 
 /* Include hacks which are mainly required for Slowaris.  */



From jussi.kivilinna at iki.fi  Fri Nov  9 17:48:12 2018
From: jussi.kivilinna at iki.fi (Jussi Kivilinna)
Date: Fri,  9 Nov 2018 18:48:12 +0200
Subject: [PATCH 2/2] common/iobuf: fix memory wiping in iobuf_copy
In-Reply-To: <154178208738.8762.5265325772335861348.stgit@localhost.localdomain>
References: <154178208738.8762.5265325772335861348.stgit@localhost.localdomain>
Message-ID: <154178209257.8762.530409850587515562.stgit@localhost.localdomain>

* common/iobuf.c (iobuf_copy): Wipe used area of buffer instead of
first sizeof(char*) bytes.
--

Signed-off-by: Jussi Kivilinna <jussi.kivilinna at iki.fi>
---
 common/iobuf.c |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/common/iobuf.c b/common/iobuf.c
index 5eeba8fe6..05944255f 100644
--- a/common/iobuf.c
+++ b/common/iobuf.c
@@ -2262,6 +2262,7 @@ iobuf_copy (iobuf_t dest, iobuf_t source)
 
   size_t nread;
   size_t nwrote = 0;
+  size_t max_read = 0;
   int err;
 
   assert (source->use == IOBUF_INPUT || source->use == IOBUF_INPUT_TEMP);
@@ -2278,6 +2279,9 @@ iobuf_copy (iobuf_t dest, iobuf_t source)
         /* EOF.  */
         break;
 
+      if (nread > max_read)
+        max_read = nread;
+
       err = iobuf_write (dest, temp, nread);
       if (err)
         break;
@@ -2285,7 +2289,8 @@ iobuf_copy (iobuf_t dest, iobuf_t source)
     }
 
   /* Burn the buffer.  */
-  wipememory (temp, sizeof (temp));
+  if (max_read)
+    wipememory (temp, max_read);
   xfree (temp);
 
   return nwrote;



From albrecht.dress at arcor.de  Fri Nov  9 19:23:43 2018
From: albrecht.dress at arcor.de (Albrecht =?iso-8859-1?b?RHJl3w==?=)
Date: Fri, 09 Nov 2018 19:23:43 +0100
Subject: Minimum GPG version for export options?
Message-ID: <HEX6PGBQ.AYEXSJVY.CL67SSXV@XEDWJYOJ.EZGT4JOY.PTUOTHJA>

Hi all,

does a documentation exist which ?--export-options? and ?--export-filter? attributes are supported by which gpg version?

In particular, I am interested in the minimum gpg version for a minimal, Autocrypt-compliant export of existing keys, using the following options:
* --export-options export-minimal,no-export-attributes
* --export-filter keep-uid=?
* --export-filter drop-subkey=?

Thanks in advance,
Albrecht.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20181109/b8bccef0/attachment.sig>

From dkg at fifthhorseman.net  Mon Nov 12 08:20:13 2018
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 12 Nov 2018 02:20:13 -0500
Subject: Minimum GPG version for export options?
In-Reply-To: <HEX6PGBQ.AYEXSJVY.CL67SSXV@XEDWJYOJ.EZGT4JOY.PTUOTHJA>
References: <HEX6PGBQ.AYEXSJVY.CL67SSXV@XEDWJYOJ.EZGT4JOY.PTUOTHJA>
Message-ID: <87efbqbw42.fsf@fifthhorseman.net>

On Fri 2018-11-09 19:23:43 +0100, Albrecht Dre? wrote:
> Hi all,
>
> does a documentation exist which ?--export-options? and ?--export-filter? attributes are supported by which gpg version?
>
> In particular, I am interested in the minimum gpg version for a minimal, Autocrypt-compliant export of existing keys, using the following options:
> * --export-options export-minimal,no-export-attributes
> * --export-filter keep-uid=?
> * --export-filter drop-subkey=?

According to then NEWS file, --export-filter (and --import-filter) was
added in 2.1.14.

Note that the possible matches used for drop-subkey= have grown over
time.  most recently, 2.2.9 added a "usage" property as a matcher for
drop-subkey.

export-minimal and export-attributes have been in GnuPG for ages
(they're in the 1.4 branch), but i note that the implementation of
export-minimal has gotten tighter in version 2.2.9 (see
https://dev.gnupg.org/T3622).

Note that in the Debian operating system, I've backported several of
these changes to the version supported in debian stable (aka "debian
stretch" or "debian 9").  So while its version says "2.1.18", it does
include some fixed behavior, mainly to support modern versions of
Enigmail (see https://bugs.debian.org/909000 for more discussion).

Regareds,

        --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/20181112/36992cb5/attachment.sig>

From albrecht.dress at arcor.de  Mon Nov 12 19:31:05 2018
From: albrecht.dress at arcor.de (Albrecht =?iso-8859-1?b?RHJl3w==?=)
Date: Mon, 12 Nov 2018 19:31:05 +0100
Subject: Minimum GPG version for export options?
In-Reply-To: <87efbqbw42.fsf@fifthhorseman.net> (from dkg@fifthhorseman.net on
 Mon Nov 12 08:20:13 2018)
Message-ID: <NFI4J6TN.AGHMMGSZ.EKG2LC4O@ZBSJQIHJ.ZOVSU5DE.UONBDG2U>

Thanks a lot for your help!

Am 12.11.18 08:20 schrieb(en) Daniel Kahn Gillmor:
> According to then NEWS file, --export-filter (and --import-filter) was added in 2.1.14.
> 
> Note that the possible matches used for drop-subkey= have grown over time.  most recently, 2.2.9 added a "usage" property as a matcher for drop-subkey.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20181112/193f680c/attachment.sig>

From wk at gnupg.org  Tue Nov 13 15:40:38 2018
From: wk at gnupg.org (Werner Koch)
Date: Tue, 13 Nov 2018 15:40:38 +0100
Subject: FYI: [openpgp] Web Key Directory I-D -07
Message-ID: <87pnv9niqh.fsf@wheatstone.g10code.de>

[Copy of mail to the OpenPGP WG. ]

-------------- next part --------------
An embedded message was scrubbed...
From: Werner Koch <wk at gnupg.org>
Subject: [openpgp] Web Key Directory I-D -07
Date: Tue, 13 Nov 2018 15:02:04 +0100
Size: 9416
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20181113/af9237d3/attachment-0001.mht>
-------------- next part --------------

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20181113/af9237d3/attachment-0001.sig>

From alon.barlev at gmail.com  Tue Nov 13 16:06:55 2018
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Tue, 13 Nov 2018 17:06:55 +0200
Subject: [PATCH Libgpg-error] gpg-error.m4: support pkg-config
In-Reply-To: <87d0rqod6v.fsf@fsij.org>
References: <20181011182720.11991-1-alon.barlev@gmail.com>
 <871s8vptg1.fsf@wheatstone.g10code.de>
 <CAOazyz3F2E0KphGwc41rKFdfhoNxjNW8f8mLoAUyWzhHodCQjg@mail.gmail.com>
 <87efcokjn6.fsf@wheatstone.g10code.de>
 <CAOazyz2Wo62ax_+kn7F+UvJZUnnRavw35bePKZAmPPaKO_gzeg@mail.gmail.com>
 <CAOazyz0Q6m6gbtThu2G8LLyQQ3mnLn_Uexpi+=BxwWKeRUmBQw@mail.gmail.com>
 <8736snt3kn.fsf@fsij.org>
 <CAOazyz3jgK5efBZL1BvFWAGnXRgtr22tRNq3-=WLiGMNk0+JFQ@mail.gmail.com>
 <87d0rqod6v.fsf@fsij.org>
Message-ID: <CAOazyz1qPw021tq+FNbtLQCQj_oNvDwSnOaPb6=UkByxFLgaNA@mail.gmail.com>

Hello Werner,
Please don't let this thread die.
I will appreciate if we can come up with some solution that will be acceptable.
Thanks!
Alon

On Wed, Oct 31, 2018 at 8:14 AM NIIBE Yutaka <gniibe at fsij.org> wrote:
>
> Alon Bar-Lev <alon.barlev at gmail.com> wrote:
> > This thread is about modifying the build so that it will have an
> > option to use pkg-config instead of config scripts if downstream
> > maintainer chooses to.
>
> I know.
>
> I don't argue this point.
>
> I pointed out that the important technical things (no use of
> --with-*-prefix/SYSROOT with *-config scripts, to build GnuPG and its
> related libraries) can be already achieved with no new dependency to
> pkg-config.  (I mean, gnupg in master.  It's not yet applied
> to stable branch.)
>
> My point is, people don't need to use libraries' *-config scripts any
> more, but only a single gpgrt-config script now.
>
> In the past, there are *-config script from libraries, and for some
> build environment, there are even prefixed versions for supported hosts,
> like i686-linux-gnu-gpg-error-config and sh4-linux-gnu-libassuan-config.
> Now, we only have a gpgrt-config.
>
> Still *-config script in each library is not removed, so that it can
> still support existing software, but it's no need any more when we build
> gnupg master.
> --


From wk at gnupg.org  Tue Nov 13 16:20:20 2018
From: wk at gnupg.org (Werner Koch)
Date: Tue, 13 Nov 2018 16:20:20 +0100
Subject: [PATCH 1/2] common/mischelp: use memset for wipememory
In-Reply-To: <154178208738.8762.5265325772335861348.stgit@localhost.localdomain>
 (Jussi Kivilinna's message of "Fri, 9 Nov 2018 18:48:07 +0200")
References: <154178208738.8762.5265325772335861348.stgit@localhost.localdomain>
Message-ID: <8736s5ngwb.fsf@wheatstone.g10code.de>

On Fri,  9 Nov 2018 17:48, jussi.kivilinna at iki.fi said:

> In new wipememory2 function, memset is called through volatile
> function pointer to so that compiler won't optimize away the call.

<rant>Are you sure that none of those braindead compilers removes that call
for example when inlined?  They may find yet another interpreation why
it is allowed.  But anyway, the old code would or is already target to
such new dis-optimization.</>


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20181113/aa1c4478/attachment.sig>

From wk at gnupg.org  Tue Nov 13 16:33:42 2018
From: wk at gnupg.org (Werner Koch)
Date: Tue, 13 Nov 2018 16:33:42 +0100
Subject: [PATCH 1/8] g10/decrypt-data: use fill_buffer in more places
In-Reply-To: <c15e9837-5138-a204-8a53-98eb58c369d4@iki.fi> (Jussi Kivilinna's
 message of "Thu, 8 Nov 2018 20:38:47 +0200")
References: <154067434467.18498.15345072060569568612.stgit@localhost.localdomain>
 <87efc8j27s.fsf@wheatstone.g10code.de>
 <54830753-1826-03d9-6e16-6e42bb822e5c@iki.fi>
 <87k1lozn06.fsf@wheatstone.g10code.de>
 <c15e9837-5138-a204-8a53-98eb58c369d4@iki.fi>
Message-ID: <87y39xm1pl.fsf@wheatstone.g10code.de>

On Thu,  8 Nov 2018 19:38, jussi.kivilinna at iki.fi said:

> Ok, I'll make patch AEAD only. For CFB/MDC, user can of course use 
> --skip-verify if they know that input does not have signature and want
> to get highest performance.

We should add this to the FAQ under a new section how to speed up
operations.

> decrypting MDC encrypted, not signed (AES128+2xSHA1(mdc+extra)+RMD160(extra)):
>  user 9.6s, 206 MB/s
> decrypting MDC encrypted, not signed --skip-verify (AES128+SHA1(mdc)):
>  user 3.0s, 575 MB/s

The RMD160 is really really slow.

> decrypting AEAD encrypted, not signed (AES128_OCB+SHA1(extra)+RMD160(extra)):
>  user 7.6s, 258 MB/s
> decrypting AEAD encrypted, not signed --skip-verify or patched (AES128_OCB):
>  user 0.95s, 1.2 GB/s

Yeah, that is a speedup.

> I also noticed that --skip-verify does not affect decryption speed of
> signed input. Selected digest algorithm gets enabled regardless of 
> --skip-verify in proc_plaintext(). Should this be fixed?

Yes, please.  Performance was not an issue back in April 98 when I
implemented --skip-verify.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20181113/6cbbd7d2/attachment.sig>

From jussi.kivilinna at iki.fi  Tue Nov 13 18:24:13 2018
From: jussi.kivilinna at iki.fi (Jussi Kivilinna)
Date: Tue, 13 Nov 2018 19:24:13 +0200
Subject: [PATCH 1/2] common/mischelp: use memset for wipememory
In-Reply-To: <8736s5ngwb.fsf@wheatstone.g10code.de>
References: <154178208738.8762.5265325772335861348.stgit@localhost.localdomain>
 <8736s5ngwb.fsf@wheatstone.g10code.de>
Message-ID: <5d6d128a-e618-3e4d-7bca-80ba686dff5a@iki.fi>

On 13.11.2018 17.20, Werner Koch wrote:
> On Fri,  9 Nov 2018 17:48, jussi.kivilinna at iki.fi said:
> 
>> In new wipememory2 function, memset is called through volatile
>> function pointer to so that compiler won't optimize away the call.
> 
> <rant>Are you sure that none of those braindead compilers removes that call
> for example when inlined?  They may find yet another interpreation why
> it is allowed.  But anyway, the old code would or is already target to
> such new dis-optimization.</>

Well, sufficiently braindead compiler might check if value read from volatile
function pointer is for 'memset' and do dead store elimination. In practice,
this does not happen. Access to memset through volatile pointer is discussed
here:
 http://www.daemonology.net/blog/2014-09-04-how-to-zero-a-buffer.html
 http://www.daemonology.net/blog/2014-09-05-erratum.html

Best way to perform memory wipe would be through platform provided functions,
such as explicit_bzero, or memset_s. I'll add support those and leave 
volatile function pointer approach as backup.

-Jussi

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

From jussi.kivilinna at iki.fi  Tue Nov 13 21:25:00 2018
From: jussi.kivilinna at iki.fi (Jussi Kivilinna)
Date: Tue, 13 Nov 2018 22:25:00 +0200
Subject: [PATCH] g10/mainproc: disable hash contexts when --skip-verify is used
Message-ID: <154214070028.21401.1033176360857425189.stgit@localhost.localdomain>

* g10/mainproc.c (proc_plaintext): Do not enable hash contexts when
opt.skip_verify is set.
--

Signed-off-by: Jussi Kivilinna <jussi.kivilinna at iki.fi>
---
 0 files changed

diff --git a/g10/mainproc.c b/g10/mainproc.c
index 7eceb7e0b..dce3f3799 100644
--- a/g10/mainproc.c
+++ b/g10/mainproc.c
@@ -862,7 +862,10 @@ proc_plaintext( CTX c, PACKET *pkt )
           /* The onepass signature case. */
           if (n->pkt->pkt.onepass_sig->digest_algo)
             {
-              gcry_md_enable (c->mfx.md, n->pkt->pkt.onepass_sig->digest_algo);
+              if (!opt.skip_verify)
+                gcry_md_enable (c->mfx.md,
+                                n->pkt->pkt.onepass_sig->digest_algo);
+
               any = 1;
             }
         }
@@ -880,7 +883,8 @@ proc_plaintext( CTX c, PACKET *pkt )
            * documents.  */
           clearsig = (*data == 0x01);
           for (data++, datalen--; datalen; datalen--, data++)
-            gcry_md_enable (c->mfx.md, *data);
+            if (!opt.skip_verify)
+              gcry_md_enable (c->mfx.md, *data);
           any = 1;
           break;  /* Stop here as one-pass signature packets are not
                      expected.  */
@@ -888,7 +892,8 @@ proc_plaintext( CTX c, PACKET *pkt )
       else if (n->pkt->pkttype == PKT_SIGNATURE)
         {
           /* The SIG+LITERAL case that PGP used to use.  */
-          gcry_md_enable ( c->mfx.md, n->pkt->pkt.signature->digest_algo );
+          if (!opt.skip_verify)
+            gcry_md_enable (c->mfx.md, n->pkt->pkt.signature->digest_algo);
           any = 1;
         }
     }



From jussi.kivilinna at iki.fi  Tue Nov 13 21:31:28 2018
From: jussi.kivilinna at iki.fi (Jussi Kivilinna)
Date: Tue, 13 Nov 2018 22:31:28 +0200
Subject: [PATCH] common/mischelp: use platform memory zeroing function for
 wipememory
In-Reply-To: <5d6d128a-e618-3e4d-7bca-80ba686dff5a@iki.fi>
References: <5d6d128a-e618-3e4d-7bca-80ba686dff5a@iki.fi>
Message-ID: <154214108786.28716.2991800022134310580.stgit@localhost.localdomain>

* common/mischelp.h (wipememory): Replace macro with function
prototype.
(wipememory2): Remove.
* common/mischelp.c (wipememory): New.
* configure.ac (AC_CHECK_FUNCS): Check for 'explicit_bzero'.
--

In new wipememory function, memory is cleared through platform
provided secure memory zeroing function, SecureZeroMemory
or explicit_bzero.

If none of these is available, memset is called through
volatile function pointer to so that compiler won't optimize
away the call.

Signed-off-by: Jussi Kivilinna <jussi.kivilinna at iki.fi>
---
 0 files changed

diff --git a/common/mischelp.c b/common/mischelp.c
index 75ba60714..81dd501f8 100644
--- a/common/mischelp.c
+++ b/common/mischelp.c
@@ -49,6 +49,22 @@
 #include "mischelp.h"
 
 
+void
+wipememory (void *ptr, size_t len)
+{
+#if defined(HAVE_W32_SYSTEM) && defined(SecureZeroMemory)
+  SecureZeroMemory (ptr, len);
+#elif defined(HAVE_EXPLICIT_BZERO)
+  explicit_bzero (ptr, len);
+#else
+  /* Prevent compiler from optimizing away the call to memset by accessing
+     memset through volatile pointer. */
+  static void *(*volatile memset_ptr)(void *, int, size_t) = (void *)memset;
+  memset_ptr (ptr, 0, len);
+#endif
+}
+
+
 /* Check whether the files NAME1 and NAME2 are identical.  This is for
    example achieved by comparing the inode numbers of the files.  */
 int
diff --git a/common/mischelp.h b/common/mischelp.h
index 18ec96edf..bdee5a443 100644
--- a/common/mischelp.h
+++ b/common/mischelp.h
@@ -47,15 +47,9 @@ time_t timegm (struct tm *tm);
 #define DIM(v)		     (sizeof(v)/sizeof((v)[0]))
 #define DIMof(type,member)   DIM(((type *)0)->member)
 
-/* To avoid that a compiler optimizes certain memset calls away, these
-   macros may be used instead. */
-#define wipememory2(_ptr,_set,_len) do { \
-              volatile char *_vptr=(volatile char *)(_ptr); \
-              size_t _vlen=(_len); \
-              while(_vlen) { *_vptr=(_set); _vptr++; _vlen--; } \
-                  } while(0)
-#define wipememory(_ptr,_len) wipememory2(_ptr,0,_len)
-
+/* To avoid that a compiler optimizes certain memset calls away,
+   wipememory function may be used instead.  */
+void wipememory(void *ptr, size_t len);
 
 /* Include hacks which are mainly required for Slowaris.  */
 #ifdef GNUPG_COMMON_NEED_AFLOCAL
diff --git a/configure.ac b/configure.ac
index 795daa400..f961adbde 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1400,16 +1400,16 @@ AC_FUNC_FSEEKO
 AC_FUNC_VPRINTF
 AC_FUNC_FORK
 AC_CHECK_FUNCS([atexit canonicalize_file_name clock_gettime ctermid  \
-                fcntl flockfile fsync ftello ftruncate funlockfile   \
-                getaddrinfo getenv getpagesize getpwnam getpwuid     \
-                getrlimit getrusage gettimeofday gmtime_r            \
-                inet_ntop inet_pton isascii lstat                    \
-                memicmp memmove memrchr mmap nl_langinfo pipe        \
-                raise rand setenv setlocale setrlimit sigaction      \
-                sigprocmask stat stpcpy strcasecmp strerror strftime \
-                stricmp strlwr strncasecmp strpbrk strsep            \
-                strtol strtoul strtoull tcgetattr timegm times       \
-                ttyname unsetenv wait4 waitpid ])
+                explicit_bzero fcntl flockfile fsync ftello          \
+                ftruncate funlockfile getaddrinfo getenv getpagesize \
+                getpwnam getpwuid getrlimit getrusage gettimeofday   \
+                gmtime_r inet_ntop inet_pton isascii lstat memicmp   \
+                memmove memrchr mmap nl_langinfo pipe raise rand     \
+                setenv setlocale setrlimit sigaction sigprocmask     \
+                stat stpcpy strcasecmp strerror strftime stricmp     \
+                strlwr strncasecmp strpbrk strsep strtol strtoul     \
+                strtoull tcgetattr timegm times ttyname unsetenv     \
+                wait4 waitpid ])
 
 # On some systems (e.g. Solaris) nanosleep requires linking to librl.
 # Given that we use nanosleep only as an optimization over a select



From bela at becker.rocks  Wed Nov 14 02:44:34 2018
From: bela at becker.rocks (=?UTF-8?q?B=C3=A9la=20Becker?=)
Date: Wed, 14 Nov 2018 02:44:34 +0100
Subject: [PATCH] poldi: fail immediately when PIN input is too short
Message-ID: <20181114014434.22676-1-bela@becker.rocks>

When poldi detects a PIN that is too short, it repeatedly asked for a new one.
This might work in a CLI, but entering a short (or empty) PIN using the
KDE greeter will lock it up permanently.

By failing immediately, the login program can determine the proper
course of action.
---
 src/pam/auth-support/getpin-cb.c | 38 ++++++++++++--------------------
 1 file changed, 14 insertions(+), 24 deletions(-)

diff --git a/src/pam/auth-support/getpin-cb.c b/src/pam/auth-support/getpin-cb.c
index d06c50f..773f1b6 100644
--- a/src/pam/auth-support/getpin-cb.c
+++ b/src/pam/auth-support/getpin-cb.c
@@ -45,7 +45,6 @@
 
 #include "getpin-cb.h"
 
-
 /* Query the user through PAM for his PIN.  Display INFO to the user.
    Store the retrieved pin in PIN, which is of size PIN_SIZE.  If it
    does not fit, return error. */
@@ -56,41 +55,32 @@ query_user (poldi_ctx_t ctx, const char *info, char *pin, size_t pin_size)
   int rc;
 
   buffer = NULL;
-  rc = 0;
 
-  while (1)			/* Loop until well-formed PIN retrieved. */
-    {
-      /* Retrieve PIN through PAM.  */
-      rc = conv_ask (ctx->conv, 1, &buffer, info);
-      if (rc)
-	goto out;
+  /* Retrieve PIN through PAM.  */
+  rc = conv_ask (ctx->conv, 1, &buffer, info);
+  if (rc)
+    return rc;
 
-      /* Do some basic checks on the entered PIN. FIXME: hard-coded
-	 values! Is this really the correct place for these checks?
-	 Shouldn't they be done in scdaemon itself?  -mo */
+  /* Do some basic checks on the entered PIN. FIXME: hard-coded
+     values! Is this really the correct place for these checks?
+     Shouldn't they be done in scdaemon itself?  -mo */
 
-      if (strlen (buffer) < 6)	/* FIXME? is it really minimum of 6 bytes? */
-	{
-	  log_msg_error (ctx->loghandle, "PIN too short");
-	  conv_tell (ctx->conv, "%s", _("PIN too short"));
-	}
-      else
-	break;
+  if (strlen (buffer) < 6)	/* FIXME? is it really minimum of 6 bytes? */
+    {
+      log_msg_error (ctx->loghandle, "PIN too short");
+      conv_tell (ctx->conv, "%s", _("PIN too short"));
+      return gpg_error (GPG_ERR_INV_DATA);
     }
 
   if (strlen (buffer) >= pin_size)
     {
       log_msg_error (ctx->loghandle, "PIN too long for buffer!");
-      rc = gpg_error (GPG_ERR_INV_DATA); /* ? */
-      goto out;
+      return gpg_error (GPG_ERR_INV_DATA);
     }
 
   strncpy (pin, buffer, pin_size - 1);
   pin[pin_size-1] = 0;
-
- out:
-
-  return rc;
+  return 0;
 }
 
 /* Pop up a message window similar to the confirm one but keep it open
-- 
2.19.1



From dgouttegattat at incenp.org  Fri Nov 16 02:27:38 2018
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Fri, 16 Nov 2018 01:27:38 +0000
Subject: [PATCH libksba 2/2] Support multi-valued signatures in CSRs.
In-Reply-To: <20181116012738.23296-1-dgouttegattat@incenp.org>
References: <20181116012738.23296-1-dgouttegattat@incenp.org>
Message-ID: <20181116012738.23296-3-dgouttegattat@incenp.org>

* src/certreq.c (ksba_certreq_set_sig_val): Support signatures
made of several values.
--

The current implementation of ksba_certreq_set_sig_val takes
only the first MPI value in the provided S-expression to build
the CSR signature. This is enough for RSA, but not for ECDSA
since a ECDSA signature is made of two values.

This patch makes sure all values are taken into account. It
also partially replaces some of the ad-hoc parsing code by
the helper functions defined in sexp-parse.h.

GnuPG-bug-id: 4092
Signed-off-by: Damien Goutte-Gattat <dgouttegattat at incenp.org>
---
 src/certreq.c | 148 +++++++++++++++++++++++++++++++++++++++-------------------
 1 file changed, 100 insertions(+), 48 deletions(-)

diff --git a/src/certreq.c b/src/certreq.c
index 46fca44..5c730a7 100644
--- a/src/certreq.c
+++ b/src/certreq.c
@@ -42,6 +42,7 @@
 #include "keyinfo.h"
 #include "der-encoder.h"
 #include "ber-help.h"
+#include "sexp-parse.h"
 #include "certreq.h"
 
 static const char oidstr_subjectAltName[] = "2.5.29.17";
@@ -406,8 +407,10 @@ ksba_certreq_add_extension (ksba_certreq_t cr,
 gpg_error_t
 ksba_certreq_set_sig_val (ksba_certreq_t cr, ksba_const_sexp_t sigval)
 {
-  const char *s, *endp;
-  unsigned long n;
+  const unsigned char *s, *saved;
+  char *buf = NULL;
+  unsigned long n, len;
+  int pass, nparam;
 
   if (!cr)
     return gpg_error (GPG_ERR_INV_VALUE);
@@ -417,24 +420,17 @@ ksba_certreq_set_sig_val (ksba_certreq_t cr, ksba_const_sexp_t sigval)
     return gpg_error (GPG_ERR_INV_SEXP);
   s++;
 
-  n = strtoul (s, (char**)&endp, 10);
-  s = endp;
-  if (!n || *s!=':')
-    return gpg_error (GPG_ERR_INV_SEXP); /* we don't allow empty lengths */
-  s++;
-  if (n != 7 || memcmp (s, "sig-val", 7))
+  if (!(n = snext (&s)))
+    return gpg_error (GPG_ERR_INV_SEXP);
+  if (!smatch (&s, 7, "sig-val"))
     return gpg_error (GPG_ERR_UNKNOWN_SEXP);
-  s += 7;
   if (*s != '(')
     return gpg_error (digitp (s)? GPG_ERR_UNKNOWN_SEXP : GPG_ERR_INV_SEXP);
   s++;
 
   /* break out the algorithm ID */
-  n = strtoul (s, (char**)&endp, 10);
-  s = endp;
-  if (!n || *s != ':')
-    return gpg_error (GPG_ERR_INV_SEXP); /* we don't allow empty lengths */
-  s++;
+  if (!(n = snext (&s)))
+    return gpg_error (GPG_ERR_INV_SEXP);
   xfree (cr->sig_val.algo);
   if (n==3 && s[0] == 'r' && s[1] == 's' && s[2] == 'a')
     { /* kludge to allow "rsa" to be passed as algorithm name */
@@ -452,42 +448,98 @@ ksba_certreq_set_sig_val (ksba_certreq_t cr, ksba_const_sexp_t sigval)
     }
   s += n;
 
-  /* And now the values - FIXME: For now we only support one */
-  /* fixme: start loop */
-  if (*s != '(')
-    return gpg_error (digitp (s)? GPG_ERR_UNKNOWN_SEXP : GPG_ERR_INV_SEXP);
-  s++;
-  n = strtoul (s, (char**)&endp, 10);
-  s = endp;
-  if (!n || *s != ':')
-    return gpg_error (GPG_ERR_INV_SEXP);
-  s++;
-  s += n; /* ignore the name of the parameter */
+  /* And now the values.
+   *
+   * If there is only one value, the signature is simply
+   * that value. Otherwise, the signature is a DER-encoded
+   * SEQUENCE of INTEGERs representing the different values.
+   *
+   * We need three passes over the values:
+   * - first pass is to get the number of values (nparam);
+   * - second pass is to compute the total length (len);
+   * - third pass is to build the final signature. */
+  for (pass = 1, nparam = len = 0, saved = s; pass < 4; pass++)
+    {
+      s = saved;
 
-  if (!digitp(s))
-    return gpg_error (GPG_ERR_UNKNOWN_SEXP); /* but may also be an invalid one */
-  n = strtoul (s, (char**)&endp, 10);
-  s = endp;
-  if (!n || *s != ':')
-    return gpg_error (GPG_ERR_INV_SEXP);
-  s++;
-  if (n > 1 && !*s)
-    { /* We might have a leading zero due to the way we encode
-         MPIs - this zero should not go into the BIT STRING.  */
-      s++;
-      n--;
+      if (pass == 3)
+        {
+          size_t needed = len;
+          if (nparam > 1)
+            needed += _ksba_ber_count_tl (TYPE_SEQUENCE, CLASS_UNIVERSAL, 1, len);
+
+          xfree (cr->sig_val.value);
+          cr->sig_val.value = xtrymalloc (needed);
+          if (!cr->sig_val.value)
+            return gpg_error (GPG_ERR_ENOMEM);
+          cr->sig_val.valuelen = needed;
+          buf = cr->sig_val.value;
+
+          if (nparam > 1)
+            buf += _ksba_ber_encode_tl (buf, TYPE_SEQUENCE,
+                                        CLASS_UNIVERSAL, 1, len);
+        }
+
+      while (*s != ')')
+        {
+          if (*s != '(')
+            return gpg_error (digitp (s)? GPG_ERR_UNKNOWN_SEXP : GPG_ERR_INV_SEXP);
+          s++;
+          if (!(n = snext (&s)))
+            return gpg_error (GPG_ERR_INV_SEXP);
+          s += n; /* Ignore the name of the parameter. */
+
+          if (!digitp (s))
+            return gpg_error (GPG_ERR_UNKNOWN_SEXP);
+          if (!(n = snext (&s)))
+            return gpg_error (GPG_ERR_INV_SEXP);
+
+          if (pass == 1)
+            nparam++;
+          else if (pass == 2)
+            {
+              if (nparam > 1)
+                len += _ksba_ber_count_tl (TYPE_INTEGER, CLASS_UNIVERSAL, 0,
+                                           *s >= 0x80? n + 1 : n)
+                       + (*s >= 0x80? n + 1 : n);
+              else
+                len += (n > 1 && !*s)? n - 1 : n;
+            }
+          else if (pass == 3)
+            {
+              if (nparam > 1)
+                {
+                  if (*s >= 0x80)
+                    { /* Add leading zero byte. */
+                      buf += _ksba_ber_encode_tl (buf, TYPE_INTEGER,
+                                                  CLASS_UNIVERSAL, 0, n + 1);
+                      *buf++ = 0;
+                    }
+                  else
+                    buf += _ksba_ber_encode_tl (buf, TYPE_INTEGER,
+                                                CLASS_UNIVERSAL, 0, n);
+                  memcpy (buf, s, n);
+                  buf += n;
+                }
+              else
+                {
+                  if (n > 1 && !*s)
+                    { /* Remove leading zero byte, which must not be
+                         included in the bitstring. */
+                      s++;
+                      n--;
+                    }
+                  memcpy (buf, s, n);
+                  buf += n;
+                }
+            }
+
+          s += n;
+          if (*s != ')')
+            return gpg_error (GPG_ERR_UNKNOWN_SEXP);
+          s++;
+        }
     }
-  xfree (cr->sig_val.value);
-  cr->sig_val.value = xtrymalloc (n);
-  if (!cr->sig_val.value)
-    return gpg_error (GPG_ERR_ENOMEM);
-  memcpy (cr->sig_val.value, s, n);
-  cr->sig_val.valuelen = n;
-  s += n;
-  if ( *s != ')')
-    return gpg_error (GPG_ERR_UNKNOWN_SEXP); /* but may also be an invalid one */
-  s++;
-  /* fixme: end loop over parameters */
 
   /* we need 2 closing parenthesis */
   if ( *s != ')' || s[1] != ')')
-- 
2.14.5



From dgouttegattat at incenp.org  Fri Nov 16 02:27:37 2018
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Fri, 16 Nov 2018 01:27:37 +0000
Subject: [PATCH gnupg 1/2] sm: Support generation of card-based ECDSA CSR.
In-Reply-To: <20181116012738.23296-1-dgouttegattat@incenp.org>
References: <20181116012738.23296-1-dgouttegattat@incenp.org>
Message-ID: <20181116012738.23296-2-dgouttegattat@incenp.org>

* sm/call-agent.c (gpgsm_scd_pksign): Identify type of signing key
and format resulting S-expression accordingly.
* sm/misc.c (transform_sigval): Support ECDSA signatures.
--

Current GpgSM implementation assumes card-based keys are RSA keys.
This patch introduces support for ECDSA keys.

By itself this patch is not sufficient, we also need support
from libksba.

GnuPG-bug-id: 4092
Signed-off-by: Damien Goutte-Gattat <dgouttegattat at incenp.org>
---
 sm/call-agent.c | 57 +++++++++++++++++++++++++++++++------------
 sm/misc.c       | 75 +++++++++++++++++++++++++++++++++++++++++++--------------
 2 files changed, 98 insertions(+), 34 deletions(-)

diff --git a/sm/call-agent.c b/sm/call-agent.c
index 20d879fa4..6ac715fab 100644
--- a/sm/call-agent.c
+++ b/sm/call-agent.c
@@ -334,7 +334,7 @@ gpgsm_scd_pksign (ctrl_t ctrl, const char *keyid, const char *desc,
                   unsigned char *digest, size_t digestlen, int digestalgo,
                   unsigned char **r_buf, size_t *r_buflen )
 {
-  int rc, i;
+  int rc, i, pkalgo;
   char *p, line[ASSUAN_LINELENGTH];
   membuf_t data;
   size_t len;
@@ -342,6 +342,7 @@ gpgsm_scd_pksign (ctrl_t ctrl, const char *keyid, const char *desc,
   unsigned char *sigbuf;
   size_t sigbuflen;
   struct default_inq_parm_s inq_parm;
+  gcry_sexp_t sig;
 
   (void)desc;
 
@@ -366,6 +367,23 @@ gpgsm_scd_pksign (ctrl_t ctrl, const char *keyid, const char *desc,
   if (digestlen*2 + 50 > DIM(line))
     return gpg_error (GPG_ERR_GENERAL);
 
+  /* Get the key type from the scdaemon. */
+  snprintf (line, DIM(line), "SCD READKEY %s", keyid);
+  init_membuf (&data, 1024);
+  rc = assuan_transact (agent_ctx, line,
+                        put_membuf_cb, &data, NULL, NULL, NULL, NULL);
+  if (rc)
+    {
+      xfree (get_membuf (&data, &len));
+      return rc;
+    }
+
+  p = get_membuf (&data, &len);
+  pkalgo = get_pk_algo_from_canon_sexp (p, len);
+  xfree (p);
+  if (!pkalgo)
+    return gpg_error (GPG_ERR_WRONG_PUBKEY_ALGO);
+
   p = stpcpy (line, "SCD SETDATA " );
   for (i=0; i < digestlen ; i++, p += 2 )
     sprintf (p, "%02X", digest[i]);
@@ -386,24 +404,31 @@ gpgsm_scd_pksign (ctrl_t ctrl, const char *keyid, const char *desc,
     }
   sigbuf = get_membuf (&data, &sigbuflen);
 
-  /* Create an S-expression from it which is formatted like this:
-     "(7:sig-val(3:rsa(1:sSIGBUFLEN:SIGBUF)))" Fixme: If a card ever
-     creates non-RSA keys we need to change things. */
-  *r_buflen = 21 + 11 + sigbuflen + 4;
-  p = xtrymalloc (*r_buflen);
-  *r_buf = (unsigned char*)p;
-  if (!p)
+  switch(pkalgo)
     {
-      xfree (sigbuf);
-      return 0;
+    case GCRY_PK_RSA:
+      rc = gcry_sexp_build (&sig, NULL, "(sig-val(rsa(s%b)))",
+                            sigbuflen, sigbuf);
+      break;
+
+    case GCRY_PK_ECC:
+      rc = gcry_sexp_build (&sig, NULL, "(sig-val(ecdsa(r%b)(s%b)))",
+                            sigbuflen/2, sigbuf,
+                            sigbuflen/2, sigbuf + sigbuflen/2);
+      break;
+
+    default:
+      rc = gpg_error (GPG_ERR_WRONG_PUBKEY_ALGO);
+      break;
     }
-  p = stpcpy (p, "(7:sig-val(3:rsa(1:s" );
-  sprintf (p, "%u:", (unsigned int)sigbuflen);
-  p += strlen (p);
-  memcpy (p, sigbuf, sigbuflen);
-  p += sigbuflen;
-  strcpy (p, ")))");
   xfree (sigbuf);
+  if (rc)
+    return rc;
+
+  rc = make_canon_sexp (sig, r_buf, r_buflen);
+  gcry_sexp_release (sig);
+  if (rc)
+    return rc;
 
   assert (gcry_sexp_canon_len (*r_buf, *r_buflen, NULL, NULL));
   return  0;
diff --git a/sm/misc.c b/sm/misc.c
index 6d047763b..9bf528513 100644
--- a/sm/misc.c
+++ b/sm/misc.c
@@ -109,13 +109,16 @@ transform_sigval (const unsigned char *sigval, size_t sigvallen, int mdalgo,
   gpg_error_t err;
   const unsigned char *buf, *tok;
   size_t buflen, toklen;
-  int depth, last_depth1, last_depth2;
+  int depth, last_depth1, last_depth2, pkalgo;
   int is_pubkey = 0;
-  const unsigned char *rsa_s = NULL;
-  size_t rsa_s_len = 0;
+  const unsigned char *rsa_s, *ecc_r, *ecc_s;
+  size_t rsa_s_len, ecc_r_len, ecc_s_len;
   const char *oid;
   gcry_sexp_t sexp;
 
+  rsa_s = ecc_r = ecc_s = NULL;
+  rsa_s_len = ecc_r_len = ecc_s_len = 0;
+
   *r_newsigval = NULL;
   if (r_newsigvallen)
     *r_newsigvallen = 0;
@@ -137,7 +140,13 @@ transform_sigval (const unsigned char *sigval, size_t sigvallen, int mdalgo,
     return err;
   if ((err = parse_sexp (&buf, &buflen, &depth, &tok, &toklen)))
     return err;
-  if (!tok || toklen != 3 || memcmp ("rsa", tok, toklen))
+  if (!tok)
+    return gpg_error (GPG_ERR_WRONG_PUBKEY_ALGO);
+  if (toklen == 3 && !memcmp ("rsa", tok, 3))
+    pkalgo = GCRY_PK_RSA;
+  else if (toklen == 5 && !memcmp ("ecdsa", tok, 5))
+    pkalgo = GCRY_PK_ECC;
+  else
     return gpg_error (GPG_ERR_WRONG_PUBKEY_ALGO);
 
   last_depth1 = depth;
@@ -150,16 +159,27 @@ transform_sigval (const unsigned char *sigval, size_t sigvallen, int mdalgo,
         return err;
       if (tok && toklen == 1)
         {
-          const unsigned char **mpi;
-          size_t *mpi_len;
+          const unsigned char **mpi = NULL;
+          size_t *mpi_len = NULL;
 
           switch (*tok)
             {
-            case 's': mpi = &rsa_s; mpi_len = &rsa_s_len; break;
+            case 's':
+              if (pkalgo == GCRY_PK_RSA)
+                {
+                  mpi = &rsa_s;
+                  mpi_len = &rsa_s_len;
+                }
+              else if (pkalgo == GCRY_PK_ECC)
+                {
+                  mpi = &ecc_s;
+                  mpi_len = &ecc_s_len;
+                }
+              break;
+
+            case 'r': mpi = &ecc_r; mpi_len = &ecc_r_len; break;
             default:  mpi = NULL;   mpi_len = NULL; break;
             }
-          if (mpi && *mpi)
-            return gpg_error (GPG_ERR_DUP_VALUE);
 
           if ((err = parse_sexp (&buf, &buflen, &depth, &tok, &toklen)))
             return err;
@@ -182,33 +202,52 @@ transform_sigval (const unsigned char *sigval, size_t sigvallen, int mdalgo,
     return err;
 
   /* Map the hash algorithm to an OID.  */
-  switch (mdalgo)
+  switch (mdalgo | (pkalgo << 8))
     {
-    case GCRY_MD_SHA1:
+    case GCRY_MD_SHA1 | (GCRY_PK_RSA << 8):
       oid = "1.2.840.113549.1.1.5";  /* sha1WithRSAEncryption */
       break;
 
-    case GCRY_MD_SHA256:
+    case GCRY_MD_SHA256 | (GCRY_PK_RSA << 8):
       oid = "1.2.840.113549.1.1.11"; /* sha256WithRSAEncryption */
       break;
 
-    case GCRY_MD_SHA384:
+    case GCRY_MD_SHA384 | (GCRY_PK_RSA << 8):
       oid = "1.2.840.113549.1.1.12"; /* sha384WithRSAEncryption */
       break;
 
-    case GCRY_MD_SHA512:
+    case GCRY_MD_SHA512 | (GCRY_PK_RSA << 8):
       oid = "1.2.840.113549.1.1.13"; /* sha512WithRSAEncryption */
       break;
 
+    case GCRY_MD_SHA224 | (GCRY_PK_ECC << 8):
+      oid = "1.2.840.10045.4.3.1"; /* ecdsa-with-sha224 */
+      break;
+
+    case GCRY_MD_SHA256 | (GCRY_PK_ECC << 8):
+      oid = "1.2.840.10045.4.3.2"; /* ecdsa-with-sha256 */
+      break;
+
+    case GCRY_MD_SHA384 | (GCRY_PK_ECC << 8):
+      oid = "1.2.840.10045.4.3.3"; /* ecdsa-with-sha384 */
+      break;
+
+    case GCRY_MD_SHA512 | (GCRY_PK_ECC << 8):
+      oid = "1.2.840.10045.4.3.4"; /* ecdsa-with-sha512 */
+      break;
+
     default:
       return gpg_error (GPG_ERR_DIGEST_ALGO);
     }
 
-  if (rsa_s && !is_pubkey)
-    err = gcry_sexp_build (&sexp, NULL, "(sig-val(%s(s%b)))",
-                           oid, (int)rsa_s_len, rsa_s);
-  else
+  if (is_pubkey)
     err = gcry_sexp_build (&sexp, NULL, "(sig-val(%s))", oid);
+  else if (pkalgo == GCRY_PK_RSA)
+    err = gcry_sexp_build (&sexp, NULL, "(sig-val(%s(s%b)))", oid,
+                           (int)rsa_s_len, rsa_s);
+  else if (pkalgo == GCRY_PK_ECC)
+    err = gcry_sexp_build (&sexp, NULL, "(sig-val(%s(r%b)(s%b)))", oid,
+                           (int)ecc_r_len, ecc_r, (int)ecc_s_len, ecc_s);
   if (err)
     return err;
   err = make_canon_sexp (sexp, r_newsigval, r_newsigvallen);
-- 
2.14.5



From dgouttegattat at incenp.org  Fri Nov 16 02:27:36 2018
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Fri, 16 Nov 2018 01:27:36 +0000
Subject: [PATCH gnupg+libksba 0/2] Fix CSR generation from card-based ECDSA
 keys.
Message-ID: <20181116012738.23296-1-dgouttegattat@incenp.org>

Hi GnuPG folks,

The following patchset intends to fix the generation of CSR from a
card-based ECDSA key (e.g., a key stored on a Gnuk token, or any
other device compliant with version 3+ of the OpenPGP Card
specification).

Currently, when generating a CSR GpgSM assumes a card-based key
can only be a RSA key, and the resulting CSR therefore has an
improper signature value [1].

The first patch (against gnupg) makes GpgSM build a 'sig-val'
S-expression corresponding to the actual type of the signature.

The second patch (against libksba) ensures that libksba can
generate a CSR whose signature comprises several values (as is the
case for ECDSA signatures).

(Ultimately the goal would be to make Scute support EdDSA certificates
for client authentication; this is currently not possible [2] but
supporting ECDSA in GpgSM is a first step.)

Comments welcome.

Cheers,

Damien


[1] https://dev.gnupg.org/T4092
[2] https://dev.gnupg.org/T4013


From dctucker at github.com  Sat Nov 17 01:28:42 2018
From: dctucker at github.com (Casey Tucker)
Date: Fri, 16 Nov 2018 16:28:42 -0800
Subject: DCO for dctucker
Message-ID: <CADAEM8r6aeNC1wjxhB+_2hFm-zTrLzhK5ccUfd=Tsp8WuE371Q@mail.gmail.com>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20181116/4061428c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: message.sig
Type: application/octet-stream
Size: 1004 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20181116/4061428c/attachment-0001.obj>

From dctucker at github.com  Sat Nov 17 01:57:13 2018
From: dctucker at github.com (Casey Tucker)
Date: Fri, 16 Nov 2018 16:57:13 -0800
Subject: patch: minimize calls to close() in spawn by calling poll()
Message-ID: <CADAEM8pcWPJAzOYqBOBEoJCHT7YSuqv9zsrzfdcq_EQ686=9kg@mail.gmail.com>

Hello,

Posting this patch to the mailing list per jeroen's instructions.

# Problem Statement
When running GPGME within Docker, the maximum number of FDs may be set
higher than a sane and reasonable values for its specific use-case, causing
many close calls to be issued, introducing a major slowdown in performance
of any calls to the `gpg` binary.

# Proposed Solution
This PR attempts to mitigate the problem by calling `poll` on the entire
range of file descriptors before issuing `close` calls to each file
descriptor. This limits the number of close calls made to the number of
active file descriptors in the current process. It also includes a minor
FIXME.

## Performance before and after

This graph shows the performance of an application signing and then
decrypting a few kilobytes of data.
https://user-images.githubusercontent.com/772810/48650469-0ce7d700-e9ab-11e8-84fd-5e3f6b619220.png

# The patch

https://patch-diff.githubusercontent.com/raw/gpg/gpgme/pull/1.patch
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20181116/abb7dd98/attachment.html>

From wk at gnupg.org  Sun Nov 18 12:42:38 2018
From: wk at gnupg.org (Werner Koch)
Date: Sun, 18 Nov 2018 12:42:38 +0100
Subject: patch: minimize calls to close() in spawn by calling poll()
In-Reply-To: <CADAEM8pcWPJAzOYqBOBEoJCHT7YSuqv9zsrzfdcq_EQ686=9kg@mail.gmail.com>
 (Casey Tucker's message of "Fri, 16 Nov 2018 16:57:13 -0800")
References: <CADAEM8pcWPJAzOYqBOBEoJCHT7YSuqv9zsrzfdcq_EQ686=9kg@mail.gmail.com>
Message-ID: <87a7m6ehn5.fsf@wheatstone.g10code.de>

On Sat, 17 Nov 2018 01:57, dctucker at github.com said:

> When running GPGME within Docker, the maximum number of FDs may be set
> higher than a sane and reasonable values for its specific use-case, causing
> many close calls to be issued, introducing a major slowdown in performance

Have you investigated why get_max_fd does not work for you.  On Linux
that function is is used to detect the highest used file descriptor by
reading /proc/self/fd/.  Or is your application really using that many
fds?

Is is guaranteed that poll(3) does not allocate memory or other things
which may take a lock?

Minor nitpicks: The code assumes that poll is available.  It should also
not used TRACE because that may allocate memory and thus can lead to a
deadlock.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20181118/5d1d9f55/attachment.sig>

From jwilk at jwilk.net  Sun Nov 18 13:51:35 2018
From: jwilk at jwilk.net (Jakub Wilk)
Date: Sun, 18 Nov 2018 13:51:35 +0100
Subject: patch: minimize calls to close() in spawn by calling poll()
In-Reply-To: <87a7m6ehn5.fsf@wheatstone.g10code.de>
References: <CADAEM8pcWPJAzOYqBOBEoJCHT7YSuqv9zsrzfdcq_EQ686=9kg@mail.gmail.com>
 <87a7m6ehn5.fsf@wheatstone.g10code.de>
Message-ID: <20181118125135.xzhtwduvhnzal6sf@jwilk.net>

* Werner Koch <wk at gnupg.org>, 2018-11-18, 12:42:
>On Sat, 17 Nov 2018 01:57, dctucker at github.com said:
>>When running GPGME within Docker, the maximum number of FDs may be set 
>>higher than a sane and reasonable values for its specific use-case, 
>>causing many close calls to be issued, introducing a major slowdown in 
>>performance
>
>Have you investigated why get_max_fd does not work for you.  On Linux 
>that function is is used to detect the highest used file descriptor by 
>reading /proc/self/fd/.  Or is your application really using that many 
>fds?

FWIW, the parent of Casey's commit is fff2049c1bc7 (from 2014...), which 
didn't have this /proc/self/fd thing. Huh?

>Is is guaranteed that poll(3) does not allocate memory or other things 
>which may take a lock?

Yes, poll() is async-singal-safe.

-- 
Jakub Wilk


From dctucker at github.com  Sun Nov 18 20:49:01 2018
From: dctucker at github.com (Casey Tucker)
Date: Sun, 18 Nov 2018 11:49:01 -0800
Subject: patch: minimize calls to close() in spawn by calling poll()
In-Reply-To: <20181118125135.xzhtwduvhnzal6sf@jwilk.net>
References: <CADAEM8pcWPJAzOYqBOBEoJCHT7YSuqv9zsrzfdcq_EQ686=9kg@mail.gmail.com>
 <87a7m6ehn5.fsf@wheatstone.g10code.de>
 <20181118125135.xzhtwduvhnzal6sf@jwilk.net>
Message-ID: <CADAEM8rvmPbx1PLfN0evj7iObFcwS9wq_qCtPW05wup4R3UK6Q@mail.gmail.com>

> FWIW, the parent of Casey's commit is fff2049c1bc7 (from 2014...), which
> didn't have this /proc/self/fd thing. Huh?

Thank you for pointing this out. Since the default branch on the
github mirror is set to `bjk/master`, I erroneously assumed it was the
latest and greatest. I'll target `master` in the next patch.

> Have you investigated why get_max_fd does not work for you.  On Linux
> that function is is used to detect the highest used file descriptor by
> reading /proc/self/fd/.  Or is your application really using that many
> fds?

In our application, we are using an older version of GPGME, version
1.9 by way of ueno/ruby-gpgme. I will attempt to backport the newer
`get_max_fds` code to improve performance. We did verify that the
application is not generating a high number of file descriptors by
running perf against GPGME tests, ruby-gpgme tests, and our
applicaton's tests, and seeing a similarly high number of close calls
running.

> Minor nitpicks: The code assumes that poll is available.  It should also
> not used TRACE because that may allocate memory and thus can lead to a
> deadlock.

poll() is available since Linux 2.1.23; what is the preferred macro to
determine whether to use poll(); should we include linux/version.h if
available and check `LINUX_VERSION_CODE >= KERNEL_VERSION(2,1,23)`?
I can remove the TRACE.


From wk at gnupg.org  Mon Nov 19 08:56:50 2018
From: wk at gnupg.org (Werner Koch)
Date: Mon, 19 Nov 2018 08:56:50 +0100
Subject: patch: minimize calls to close() in spawn by calling poll()
In-Reply-To: <CADAEM8rvmPbx1PLfN0evj7iObFcwS9wq_qCtPW05wup4R3UK6Q@mail.gmail.com>
 (Casey Tucker's message of "Sun, 18 Nov 2018 11:49:01 -0800")
References: <CADAEM8pcWPJAzOYqBOBEoJCHT7YSuqv9zsrzfdcq_EQ686=9kg@mail.gmail.com>
 <87a7m6ehn5.fsf@wheatstone.g10code.de>
 <20181118125135.xzhtwduvhnzal6sf@jwilk.net>
 <CADAEM8rvmPbx1PLfN0evj7iObFcwS9wq_qCtPW05wup4R3UK6Q@mail.gmail.com>
Message-ID: <87in0tcxfh.fsf@wheatstone.g10code.de>

On Sun, 18 Nov 2018 20:49, dctucker at github.com said:

> Thank you for pointing this out. Since the default branch on the
> github mirror is set to `bjk/master`, I erroneously assumed it was the
> latest and greatest. I'll target `master` in the next patch.

Please do no use an arbitrary mirror but use git.gnupg.org or our own
mirror at dev.gnupg.org.

> poll() is available since Linux 2.1.23; what is the preferred macro to

GPGME is not Linux specific but needs to be build on all POSIX platforms
as well as Windows Vista and newer.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20181119/e408c5d2/attachment.sig>

From bela at becker.rocks  Thu Nov 22 17:09:58 2018
From: bela at becker.rocks (Becker =?ISO-8859-1?Q?B=E9la?=)
Date: Thu, 22 Nov 2018 17:09:58 +0100
Subject: [PATCH] poldi: fail immediately when PIN input is too short
In-Reply-To: <20181114014434.22676-1-bela@becker.rocks>
References: <20181114014434.22676-1-bela@becker.rocks>
Message-ID: <1760501.LXJhRv8uoP@longitude>

Is this interesting to anyone? I've been using poldi with this patch for the past weeks with only minor unrelated annoyances, but without this patch the computer can easily become unusable.

Would someone using poldi with a display manager that is not sddm give this patch a try?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20181122/6a23a50e/attachment.sig>

From ben at adversary.org  Thu Nov 22 20:12:09 2018
From: ben at adversary.org (Ben McGinnes)
Date: Fri, 23 Nov 2018 06:12:09 +1100
Subject: python GPGME bindings and key signatures
In-Reply-To: <d9350e9228cd2dcf9bc534d9086d2d05ff3d7cd9.camel@cryptobitch.de>
References: <bc93c576-a508-8ed4-cdd3-b03f8b212e70@square-r00t.net>
 <d9350e9228cd2dcf9bc534d9086d2d05ff3d7cd9.camel@cryptobitch.de>
Message-ID: <20181122191209.wror2fokmqdfgz45@adversary.org>

On Mon, Nov 05, 2018 at 12:14:45PM +0100, Tobias Mueller wrote:
> Hi,
> 
>     # With gpgme 1.9 we can simply do:
>     # keys = list(ctx.keylist(key.fpr), mode=mode)

A minor correction of a typo here, that last line should be:

keys = list(ctx.keylist(key.fpr, mode=mode))

Then the signature data will be in accessible via things like this:

for key in keys:
    for uid in key.uids:
        for sig in uid.signatures:
            print(sig.keyid, sig.uid, sig.timestamp)

And so on.

Also, this needs more documentation, soI'll add it to the HOWTO,
thanks for the reminder.


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

From albrecht.dress at arcor.de  Sun Nov 25 19:36:07 2018
From: albrecht.dress at arcor.de (Albrecht =?iso-8859-1?b?RHJl3w==?=)
Date: Sun, 25 Nov 2018 19:36:07 +0100
Subject: git.gnupg.org certificate expired
Message-ID: <SUSPXOTL.BLSDAVSX.BAE6GEH5@SCUKSX4A.M4UW445T.L6OC2ZQ6>

?just to let you know?

---8<--------------------------------------------------------
git.gnupg.org verwendet ein ung?ltiges Sicherheitszertifikat.

Das Zertifikat ist am 24. November 2018, 07:14:09 GMT+1
abgelaufen. Die aktuelle Zeit ist 25. November 2018, 19:31.

Fehlercode: SEC_ERROR_EXPIRED_CERTIFICATE
---8<--------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20181125/78f0dbc4/attachment-0001.sig>

From alon.barlev at gmail.com  Sun Nov 25 19:45:36 2018
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Sun, 25 Nov 2018 20:45:36 +0200
Subject: [PATCH Libgpg-error] gpg-error.m4: support pkg-config
In-Reply-To: <CAOazyz1qPw021tq+FNbtLQCQj_oNvDwSnOaPb6=UkByxFLgaNA@mail.gmail.com>
References: <20181011182720.11991-1-alon.barlev@gmail.com>
 <871s8vptg1.fsf@wheatstone.g10code.de>
 <CAOazyz3F2E0KphGwc41rKFdfhoNxjNW8f8mLoAUyWzhHodCQjg@mail.gmail.com>
 <87efcokjn6.fsf@wheatstone.g10code.de>
 <CAOazyz2Wo62ax_+kn7F+UvJZUnnRavw35bePKZAmPPaKO_gzeg@mail.gmail.com>
 <CAOazyz0Q6m6gbtThu2G8LLyQQ3mnLn_Uexpi+=BxwWKeRUmBQw@mail.gmail.com>
 <8736snt3kn.fsf@fsij.org>
 <CAOazyz3jgK5efBZL1BvFWAGnXRgtr22tRNq3-=WLiGMNk0+JFQ@mail.gmail.com>
 <87d0rqod6v.fsf@fsij.org>
 <CAOazyz1qPw021tq+FNbtLQCQj_oNvDwSnOaPb6=UkByxFLgaNA@mail.gmail.com>
Message-ID: <CAOazyz19XD7CJm_BTO3HgWiGHB8FhtGOrf1yo+-acNCQ-dmVYw@mail.gmail.com>

I am declaring this thread as MIA [Missing in action].
I am very sad that we cannot even properly discuss this.

On Tue, Nov 13, 2018 at 5:06 PM Alon Bar-Lev <alon.barlev at gmail.com> wrote:
>
> Hello Werner,
> Please don't let this thread die.
> I will appreciate if we can come up with some solution that will be acceptable.
> Thanks!
> Alon
>
> On Wed, Oct 31, 2018 at 8:14 AM NIIBE Yutaka <gniibe at fsij.org> wrote:
> >
> > Alon Bar-Lev <alon.barlev at gmail.com> wrote:
> > > This thread is about modifying the build so that it will have an
> > > option to use pkg-config instead of config scripts if downstream
> > > maintainer chooses to.
> >
> > I know.
> >
> > I don't argue this point.
> >
> > I pointed out that the important technical things (no use of
> > --with-*-prefix/SYSROOT with *-config scripts, to build GnuPG and its
> > related libraries) can be already achieved with no new dependency to
> > pkg-config.  (I mean, gnupg in master.  It's not yet applied
> > to stable branch.)
> >
> > My point is, people don't need to use libraries' *-config scripts any
> > more, but only a single gpgrt-config script now.
> >
> > In the past, there are *-config script from libraries, and for some
> > build environment, there are even prefixed versions for supported hosts,
> > like i686-linux-gnu-gpg-error-config and sh4-linux-gnu-libassuan-config.
> > Now, we only have a gpgrt-config.
> >
> > Still *-config script in each library is not removed, so that it can
> > still support existing software, but it's no need any more when we build
> > gnupg master.
> > --


From gniibe at fsij.org  Tue Nov 27 05:01:41 2018
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Tue, 27 Nov 2018 13:01:41 +0900
Subject: [PATCH] poldi: fail immediately when PIN input is too short
In-Reply-To: <1760501.LXJhRv8uoP@longitude>
References: <20181114014434.22676-1-bela@becker.rocks>
 <1760501.LXJhRv8uoP@longitude>
Message-ID: <87a7lvp3ru.fsf@iwagami.gniibe.org>

Becker B?la <bela at becker.rocks> wrote:
> without this patch the computer can easily become unusable.

In my opinion, it is SDDM which should be fixed.  It seems that SDDM
doesn't support pam_conv(3), that is considered simply wrong (for Poldi,
at least).

> poldi with a display manager that is not sddm give this patch a try?

I don't use Poldi usually, but I tried your patch.  I'm using lightdm.

With your patch, it doesn't display "PIN too short" message (since
it returns an error).  This is severe regression, I suppose.
-- 


From dkg at fifthhorseman.net  Wed Nov 28 07:25:25 2018
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 28 Nov 2018 01:25:25 -0500
Subject: [GPGME PATCH] python: simplify Context.decrypt()
Message-ID: <20181128062525.5649-1-dkg@fifthhorseman.net>

In the course of trying to address https://dev.gnupg.org/T4271, i
discovered that gpg.Context.decrypt() has a bit of superfluous code.
This changeset is intended to simplify the code without making any
functional changes.

Signed-off-by: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
---
 lang/python/src/core.py | 29 ++---------------------------
 1 file changed, 2 insertions(+), 27 deletions(-)

diff --git a/lang/python/src/core.py b/lang/python/src/core.py
index 6e925925..f7e843f1 100644
--- a/lang/python/src/core.py
+++ b/lang/python/src/core.py
@@ -386,13 +386,9 @@ class Context(GpgmeWrapper):
                     if verify is False:
                         verify = True
                         sink_result = True
-                    else:
-                        pass
                 elif isinstance(verify, list) is True:
                     if len(verify) > 0:
                         verify_sigs = True
-                    else:
-                        pass
                 else:
                     verify = True
                 self.op_decrypt_verify(ciphertext, plaintext)
@@ -447,29 +443,8 @@ class Context(GpgmeWrapper):
                 if not ok:
                     missing.append(key)
             if missing:
-                try:
-                    raise errors.MissingSignatures(verify_result, missing,
-                                                   results=results)
-                except errors.MissingSignatures as e:
-                    raise e
-                    # mse = e
-                    # mserr = "gpg.errors.MissingSignatures:"
-                    # print(mserr, miss_e, "\n")
-                    # # The full details can then be found in mse.results,
-                    # # mse.result, mse.missing if necessary.
-                    # mse_list = []
-                    # msp = "Missing signatures from: \n".format()
-                    # print(msp)
-                    # for key in mse.missing:
-                    #     mse_list.append(key.fpr)
-                    #     msl = []
-                    #     msl.append(key.fpr)
-                    #     for user in key.uids:
-                    #         msl.append(user.name)
-                    #         msl.append(user.email)
-                    #         # msl.append(user.uid)
-                    #     print(" ".join(msl))
-                    # raise mse
+                raise errors.MissingSignatures(verify_result, missing,
+                                               results=results)
 
         return results
 
-- 
2.19.2