From gniibe at fsij.org  Mon Apr  2 02:10:39 2018
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Mon, 02 Apr 2018 09:10:39 +0900
Subject: Again: Writing DER certificates to ZeitControl Cards
In-Reply-To: <1522509170.6124.4.camel@googlemail.com>
References: <1522509170.6124.4.camel@googlemail.com>
Message-ID: <87in9afoxs.fsf@iwagami.gniibe.org>

Dirk Gottschalk via Gnupg-users <gnupg-users at gnupg.org> wrote:
> I asked this Question a while ago, but unfortunately didn't get any
> response. So, I ask again and I'm in hope that somebody here knows any
> Answer to this. I just want to know if the cards do not support it, or
> is somebething wrong with my setup?

Most likely, the length of certificate matters.  If you can minimize
your certificate, please try.  I don't know the limitation for the card.
In case of my own implementation, I can only support data less than
2048-byte.

> Are these cards not capable of getting certs written on, or am I
> missing something?

FWIW, let me explain my opinion.  This might be irrelevant to the
implementation on ZeitControl Card, though.

The feature is one of the most difficult parts for an implementer of
OpenPGP card.  For my own implementation, I cannot implement it fully,
because of the possibility of larger size.  So, users of Gnuk Token have
to use special tool to write certificate, while reading is OK.

Since the feature is questionable for me (no real good use case), I even
put a compile time option for Gnuk to disable it, and that's the
default now.
-- 


From dirk.gottschalk1980 at googlemail.com  Mon Apr  2 04:10:12 2018
From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk)
Date: Mon, 02 Apr 2018 04:10:12 +0200
Subject: Feature wishlist. ;)
Message-ID: <1522635012.20997.8.camel@googlemail.com>

Hi.

Here comes my list of "nice to have" functions for future versions.

- Full CA functionality in GPGsm, incl. CRLs and extended attributes
  for signed certificates

- A free cup of coffee, every time GPG tells a function may take a
  while

- A Medal of honor after 1.000 signatures.

- And, last, but not least, a complete manual.

Okay, only the first and the last ones are realistic. But, don't take
me all of my dreams. :-D

Regards,
Dirk

-- 
Dirk Gottschalk
Paulusstrasse 6-8
52064 Aachen
Tel.: +49 1573 1152350
-------------- 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-users/attachments/20180402/10b71b28/attachment.sig>

From lacoste_bo at yahoo.it  Mon Apr  2 12:00:43 2018
From: lacoste_bo at yahoo.it (Silvio Arnone)
Date: Mon, 2 Apr 2018 10:00:43 +0000 (UTC)
Subject: Please, I can't open a gpg folder
References: <950750952.477778.1522663243882.ref@mail.yahoo.com>
Message-ID: <950750952.477778.1522663243882@mail.yahoo.com>

Good morning,
Please, I have a serious problem with a folder encrypted using "gpg" on Linux Mint 18.3 amd64: I have been encrypting a folder and changed the name adding the date:
- Original name = .Bilancio.tar.gz.gpg
- New name = 31.12.2017.Bilancio.tar.gz.gpg
Today gone to get it on a fresh install of Linux Mint, started the process after renaming the file to the original name but can't get it, comes out an empty file named " ?S- (invalid encoding) ".
Please, do I have any hope to get my file back?

Thank you for reading
Silvio Arnone
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180402/b0c7216c/attachment.html>

From dgouttegattat at incenp.org  Mon Apr  2 14:43:52 2018
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Mon, 2 Apr 2018 13:43:52 +0100
Subject: Again: Writing DER certificates to ZeitControl Cards
In-Reply-To: <87in9afoxs.fsf@iwagami.gniibe.org>
References: <1522509170.6124.4.camel@googlemail.com>
 <87in9afoxs.fsf@iwagami.gniibe.org>
Message-ID: <1be606eb-0176-75b6-c38c-8bd375f7ddf0@incenp.org>

On 04/02/2018 01:10 AM, NIIBE Yutaka wrote:
> Most likely, the length of certificate matters.  If you can minimize
> your certificate, please try.  I don't know the limitation for the card.

I don't know for the v3.3 card, but v2.1 cards allow for a 2048 bytes 
certificate (at least mine does, but maybe this has changed between 
different production runs?).

One way of finding the max allowed size is the following command (here 
tested with a Yubikey NEO):

$ gpg-connect-agent 'SCD LEARN --force' /bye | grep '^S EXTCAP'
S EXTCAP gc=1+ki=1+fc=1+pd=0+mcl3=1216+aac=0+sm=2+si=0+dec=0+bt=0

The value you are interested in is "mcl3". In this example, it says that 
the Yubikey NEO allows for a 1216-bytes certificate.


Damien

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

From dirk.gottschalk1980 at googlemail.com  Tue Apr  3 00:47:18 2018
From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk)
Date: Tue, 03 Apr 2018 00:47:18 +0200
Subject: Again: Writing DER certificates to ZeitControl Cards
In-Reply-To: <1be606eb-0176-75b6-c38c-8bd375f7ddf0@incenp.org>
References: <1522509170.6124.4.camel@googlemail.com>
 <87in9afoxs.fsf@iwagami.gniibe.org>
 <1be606eb-0176-75b6-c38c-8bd375f7ddf0@incenp.org>
Message-ID: <1522709238.3633.8.camel@googlemail.com>

HI.

Am Montag, den 02.04.2018, 13:43 +0100 schrieb Damien Goutte-Gattat via
Gnupg-users:

> $ gpg-connect-agent 'SCD LEARN --force' /bye | grep '^S EXTCAP'
> S EXTCAP gc=1+ki=1+fc=1+pd=0+mcl3=1216+aac=0+sm=2+si=0+dec=0+bt=0

> The value you are interested in is "mcl3". In this example, it says
> that 
> the Yubikey NEO allows for a 1216-bytes certificate.

Thanks for your advice. The Output of the command for my card tells
that a cert can have up to 2048 bytes which is 2kB. The file I want to
store is about 1.8kB so this seems not to be the problem.

By the way, I am using a ReinerSCT CyberJack RFID Standard via PCSCd.
Perhaps this is the source of my problems. Unfortunately I didn't get
the internal CCID driver to work with this reader. I have to check if
it is compiled in in my distributions package and if it even would work
with my reader.

Regards,
Dirk


-- 
Dirk Gottschalk
Paulusstrasse 6-8
52064 Aachen
Tel.: +49 1573 1152350
-------------- 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-users/attachments/20180403/df8eefce/attachment-0001.sig>

From jukka.kakko at pohydnil.fi  Tue Apr  3 13:33:18 2018
From: jukka.kakko at pohydnil.fi (Jukka Kakko)
Date: Tue, 3 Apr 2018 14:33:18 +0300
Subject: Installation error with libgpg-error-1.28
Message-ID: <0a0491fe-c679-1165-9b84-fb47f02989da@pohydnil.fi>

Hello,

I am trying to upgrade my old GnuPG (version 2.0.14) in order to
use Enigmail with my current Thunderbird.

My system:
[root at llappari goose]# lscpu
Architecture:          i686
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                4
On-line CPU(s) list:   0-3
Thread(s) per core:    2
Core(s) per socket:    2
Socket(s):             1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 37
Model name:            Intel(R) Core(TM) i3 CPU       M 350  @ 2.27GHz
Stepping:              2
CPU MHz:               2266.000
BogoMIPS:              4522.11
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              3072K
[root at llappari goose]#

I tried installing libgpg-error-1.28 but i am not sure it installed
correctly:
[root at llappari libgpg-error-1.28]# ./configure |tee mylog.txt

ended as:
---->
config.status: creating po/POTFILES
config.status: creating po/Makefile

        libgpg-error v1.28 has been configured as follows:

        Revision: e323423  (58147)
        Platform: i686-pc-linux-gnu

[root at llappari libgpg-error-1.28]#
<----

[root at llappari libgpg-error-1.28]# make |tee -a mylog.txt

ended as:
---->
make[3]: Nothing to be done for `all-am'.
make[3]: Leaving directory
`/home/goose/MyInst/libgpg-error/libgpg-error-1.28/lang'
make[2]: Leaving directory
`/home/goose/MyInst/libgpg-error/libgpg-error-1.28/lang'
make[2]: Entering directory
`/home/goose/MyInst/libgpg-error/libgpg-error-1.28'
make[2]: Leaving directory
`/home/goose/MyInst/libgpg-error/libgpg-error-1.28'
make[1]: Leaving directory
`/home/goose/MyInst/libgpg-error/libgpg-error-1.28'
[root at llappari libgpg-error-1.28]# make |tee -a mylog.txt
<----
There are 4 "Nothing to be done"-messages in all. Is that normal?

[root at llappari libgpg-error-1.28]# make install|tee -a mylog.txt

ended as:
---->
make[3]: Entering directory
`/home/goose/MyInst/libgpg-error/libgpg-error-1.28'
make[3]: Nothing to be done for `install-data-hook'.
make[3]: Leaving directory
`/home/goose/MyInst/libgpg-error/libgpg-error-1.28'
make[2]: Leaving directory
`/home/goose/MyInst/libgpg-error/libgpg-error-1.28'
make[1]: Leaving directory
`/home/goose/MyInst/libgpg-error/libgpg-error-1.28'
[root at llappari libgpg-error-1.28]#
<----
That makes now 13 "Nothing to be done"-messages in all.

I get errors from the second phase when i try to install
libcrypt:

[root at llappari libgcrypt-1.8.2]# ./configure |tee -a mylog.txt

Ends with following message:
---->
checking whether a -O flag munging is requested... yes
checking whether to enable AMD64 as(1) feature detection... yes
checking for gpg-error-config... no
checking for GPG Error - version >= 1.25... no
configure: error: libgpg-error is needed.
                See ftp://ftp.gnupg.org/gcrypt/libgpg-error/ .
[root at llappari libgcrypt-1.8.2]#
<----

What should i do?

Any help is appreciated.
I am not an expert.

Kind Regards,
Jukka


From dkg at fifthhorseman.net  Tue Apr  3 18:21:57 2018
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 03 Apr 2018 12:21:57 -0400
Subject: Installation error with libgpg-error-1.28
In-Reply-To: <0a0491fe-c679-1165-9b84-fb47f02989da@pohydnil.fi>
References: <0a0491fe-c679-1165-9b84-fb47f02989da@pohydnil.fi>
Message-ID: <87h8osz2e2.fsf@fifthhorseman.net>

Hi Jukka--

On Tue 2018-04-03 14:33:18 +0300, Jukka Kakko wrote:
>
> I am trying to upgrade my old GnuPG (version 2.0.14) in order to
> use Enigmail with my current Thunderbird.

what operating system are you using?

> [root at llappari libgcrypt-1.8.2]# ./configure |tee -a mylog.txt

I suspect you want to explicitly pass this ./configure invocation a
--with-libgpg-error-prefix argument that matches your libgpg-error
installation prefix.

but really, if you're not an expert i recommend using pre-packaged
versions of all of these tools, if sensible versions are available from
your operating system vendor.

Regards,

             --dkg


From jukka.kakko at pohydnil.fi  Thu Apr  5 01:00:35 2018
From: jukka.kakko at pohydnil.fi (Jukka Kakko)
Date: Thu, 5 Apr 2018 02:00:35 +0300
Subject: Installation error with libgpg-error-1.28
In-Reply-To: <87h8osz2e2.fsf@fifthhorseman.net>
References: <0a0491fe-c679-1165-9b84-fb47f02989da@pohydnil.fi>
 <87h8osz2e2.fsf@fifthhorseman.net>
Message-ID: <3bfa631e-adbf-10a0-0ff2-5ac3696465a1@pohydnil.fi>

Thank you for your time.

On 04/03/2018 07:21 PM, Daniel Kahn Gillmor wrote:
> Hi Jukka--
> 
> On Tue 2018-04-03 14:33:18 +0300, Jukka Kakko wrote:
>>
>> I am trying to upgrade my old GnuPG (version 2.0.14) in order to
>> use Enigmail with my current Thunderbird.
> 
> what operating system are you using?

Linux Centos 6.9 Final, 32b (quite old, i know).

> 
>> [root at llappari libgcrypt-1.8.2]# ./configure |tee -a mylog.txt
> 
> I suspect you want to explicitly pass this ./configure invocation a
> --with-libgpg-error-prefix argument that matches your libgpg-error
> installation prefix.
> 
> but really, if you're not an expert i recommend using pre-packaged
> versions of all of these tools, if sensible versions are available from
> your operating system vendor.

I tried to find more current rpm-file but i could not find any. That's
the reason i tried to install it myself.
Anyways, the updated Enigmail made the problem go away. I was impatient.
I am also soon upgrading my Linux version soon...

Regards,
Jukka


From wk at gnupg.org  Thu Apr  5 17:07:40 2018
From: wk at gnupg.org (Werner Koch)
Date: Thu, 05 Apr 2018 17:07:40 +0200
Subject: Again: Writing DER certificates to ZeitControl Cards
In-Reply-To: <1522709238.3633.8.camel@googlemail.com> (Dirk Gottschalk via
 Gnupg-users's message of "Tue, 03 Apr 2018 00:47:18 +0200")
References: <1522509170.6124.4.camel@googlemail.com>
 <87in9afoxs.fsf@iwagami.gniibe.org>
 <1be606eb-0176-75b6-c38c-8bd375f7ddf0@incenp.org>
 <1522709238.3633.8.camel@googlemail.com>
Message-ID: <87k1tlzo77.fsf@wheatstone.g10code.de>

On Tue,  3 Apr 2018 00:47, gnupg-users at gnupg.org said:

> By the way, I am using a ReinerSCT CyberJack RFID Standard via PCSCd.
> Perhaps this is the source of my problems. Unfortunately I didn't get

Reiner readers are a problem.  That company does not provide any
documentation for their readers, uses lots of proprietary extensions and
relies on their own proprietary drivers.  Further some of their readers
have way to much functionality to act as a simple interface a card to a
computer and thus offers much more attack surfaces than other "dumper"
readers.  Save your time and get another reader.


Salam-Shalom,

   Werner


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

From kenchou0731 at gmail.com  Thu Apr  5 10:50:32 2018
From: kenchou0731 at gmail.com (=?UTF-8?B?5ZGo6Kmu5YSS?=)
Date: Thu, 5 Apr 2018 16:50:32 +0800
Subject: GnuPG usage for automatic remote decryption
Message-ID: <CAGLgBvnzj20fwLYz42xekEDi2cTkoGFHJcT+HZ_K9u+ttJXWhQ@mail.gmail.com>

Hi,

The situation is that there is a machine on remote. And I want to send an
encrypted file to that remote machine and let the machine decrypt the file
automatically. So I'm facing the problem that:

 * To encrypt the file by a public key:

     Which means I have to put a secret key on the remote machine. But it
is not an ideal solution. Since a secret key needs a passphrase to use.
Further more, a secret key on a remote machine isn't under enough
protection. That may have some security issue.

 * To encrypt the file by a secret key:

     This can meet my needs. But it seems that GnuPG doesn't support the
feature for encryption by secret key.

Any suggestion on this situation?

regards,
Ken
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180405/0889a262/attachment.html>

From gnupg-users.dirk at o.banes.ch  Thu Apr  5 21:46:25 2018
From: gnupg-users.dirk at o.banes.ch (gnupg-users.dirk at o.banes.ch)
Date: Thu, 5 Apr 2018 21:46:25 +0200
Subject: GnuPG usage for automatic remote decryption
In-Reply-To: <CAGLgBvnzj20fwLYz42xekEDi2cTkoGFHJcT+HZ_K9u+ttJXWhQ@mail.gmail.com>
References: <CAGLgBvnzj20fwLYz42xekEDi2cTkoGFHJcT+HZ_K9u+ttJXWhQ@mail.gmail.com>
Message-ID: <33867392-d2cf-f08b-ce8b-16df2c30290b@o.banes.ch>

Hello Ken,

basically what you trying to archive is difficult.
I can only comment on " * To encrypt the file by a public key" since
frankly I think the second option does not exist unless you are talking
about symetrical crypto.

Two points:
??? A) You could try to automatically ssh into the remote machine to
trigger decryption and passphrase entry.
??? B) You can secure the private key on the remote machine by using a
Secure Element. OpenPGP Card, Yubikey......
??????? Since the key resides only on the Secure Element and can not be
exported it is save from virtual theft - obviously someone still can
steal the key and machine if he has physical access.
??????? However still an attacker can use the passphrase to use the
Secure Element on this machine if he gets hold of the passpharse.

regards Dirk



??



On 05.04.2018 10:50, ??? wrote:
> Hi,
>
> The situation is that there is a machine on remote. And I want to send
> an encrypted file to that remote machine and let the machine decrypt
> the file automatically. So I'm facing the problem that:
>
> ?* To encrypt the file by a public key:
>
> ? ? ?Which means I have to put a secret key on the remote machine. But
> it is not an ideal solution. Since a secret key needs a passphrase to
> use. Further more, a secret key on a remote machine isn't under enough
> protection. That may have some security issue.
>
> ?* To encrypt the file by a secret key:
>
> ? ? ?This can meet my needs. But it seems that GnuPG doesn't support
> the feature for encryption by secret key.
>
> Any suggestion on this situation?
>
> regards,
> Ken
>
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users




From aheinecke at intevation.de  Fri Apr  6 11:04:47 2018
From: aheinecke at intevation.de (Andre Heinecke)
Date: Fri, 06 Apr 2018 11:04:47 +0200
Subject: GnuPG usage for automatic remote decryption
In-Reply-To: <33867392-d2cf-f08b-ce8b-16df2c30290b@o.banes.ch>
References: <CAGLgBvnzj20fwLYz42xekEDi2cTkoGFHJcT+HZ_K9u+ttJXWhQ@mail.gmail.com>
 <33867392-d2cf-f08b-ce8b-16df2c30290b@o.banes.ch>
Message-ID: <2788187.YP8PS2pntf@esus>

Hi,

On Thursday, April 5, 2018 9:46:25 PM CEST gnupg-users.dirk at o.banes.ch wrote:
> Two points:
>     A) You could try to automatically ssh into the remote machine to
> trigger decryption and passphrase entry.

For this usecase I'm using AgentForwarding ( https://wiki.gnupg.org/
AgentForwarding ). The GnuPG on the remote machine connects to a local Gpg-
Agent. This allows me to SSH to a remote machine, do crypto there with secret 
keys that live on my local machine / security tokens. And I only need to enter 
the passphrase on the local machine.


Best Regards,
Andre

-- 
Andre Heinecke |  ++49-541-335083-262  | http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180406/f5d1a284/attachment-0001.sig>

From peter at digitalbrains.com  Fri Apr  6 11:27:58 2018
From: peter at digitalbrains.com (Peter Lebbing)
Date: Fri, 6 Apr 2018 11:27:58 +0200
Subject: GnuPG usage for automatic remote decryption
In-Reply-To: <CAGLgBvnzj20fwLYz42xekEDi2cTkoGFHJcT+HZ_K9u+ttJXWhQ@mail.gmail.com>
References: <CAGLgBvnzj20fwLYz42xekEDi2cTkoGFHJcT+HZ_K9u+ttJXWhQ@mail.gmail.com>
Message-ID: <a2f2502a-5e4a-8056-0765-eeb58a4f93a2@digitalbrains.com>

On 05/04/18 10:50, ??? wrote:
> Since a secret key needs a passphrase to
> use.

Let me clarify because it is not obvious: this is not the case. It is
perfectly valid to have a secret key without a passphrase. The drawback
is anyone with file access to the on-disk copy of the secret key has
full possession of it.

> Further more, a secret key on a remote machine isn't under enough
> protection. That may have some security issue.

Try to work this thought out in detail for yourself: it depends on your
threat model. Try to think of ways an attacker can access the file with
the secret key. Think what that attacker could do with that level of
access, even if the secret key were not available to them. Could they
perhaps still fully compromise the process? If so, does it still matter
that they can also access the private key?

It might be wise to exclude the file containing the private key from
backups, though. That avoids a whole different class of access to cold
storage. I don't backup my SSH on-disk private keys. Should one of my
systems crash and need to be restored from backup, I would generate new
SSH keys and distribute them. Perhaps in your case it would also be
better to just bite the bullet and generate new keys whenever the system
is unrecoverable.

> ?* To encrypt the file by a secret key:
> 
> ? ? ?This can meet my needs.

I don't think this makes sense.

A public key is inherently designed to be disseminated to anybody. The
system is designed like that, it expects public data to be non-secret.
Encrypting to the public key, if it were possible, means you intend for
anybody to be able to decrypt it. That's not encryption.

If you want to be sure that something originated from a person holding a
private key, sign it with that private key. That proves that the data
was not modified from what they intended to sign.

HTH,

Peter.

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

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

From mangocats at gmail.com  Sat Apr  7 01:08:30 2018
From: mangocats at gmail.com (Mike Inman)
Date: Fri, 6 Apr 2018 19:08:30 -0400
Subject: GnuPG usage for automatic remote decryption
Message-ID: <CAAqEqK0Ks2n2PHWFek=AuYs71M-SRYMYFgQqhwi=M8Looy2Snw@mail.gmail.com>

Hi Dirk & Ken,

I'm working on a similar problem... automated decryption "in the field" and
what I have come to is this:

Encrypt the message with a symmetric algorithm, adding salt and a
hash/checksum to ensure validity.  Then, taking that result and signing
with a private key.

In the field - the signature is validated with the matching public key,
then the symmetric algorithm decrypts the message.  While it is possible
that an attacker might unravel the shared keys used in the symmetric
encryption, this is not so much our concern as is the authenticity of the
message when received.  The combination of private key signature plus hash
checksum should do that.

Our solution needs to be "hands off" automated, which basically precludes
the idea of using passphrases (which would not stay secure in our
organization anyway.)  A determined attacker could get into the source code
and tease out the symmetric key, but that would only show them the contents
of the message, which, if they have the hardware, they can get anyway by
copying the hard drive after the message is decrypted - and as stated
above, this is of much less concern than a spoofed message getting
automatically accepted.

When I studied cryptography at Uni in the 1980s, they taught that
private/public key encryption was a more or less interchangeable affair -
the only difference between a private key and a public key is the manner in
which they are handled.  As such, I am a little disappointed in the GnuPGP
implementation that doesn't allow encryption with the private key to serve
as authentication and obscurity of the message - our private key will be
obscured, but obviously not secured since attackers may have control of the
standard computer system it is contained in.  As things are, I am left to
use a layer of symmetric encryption to obscure the message, no more secure
in the end than using the private key to encrypt (since the symmetric key
is in the devices in the wild), but much more hassle.

Unless I'm missing something?

Also, thus far I have decided that it's easier to do symmetric encryption
with libgcrypt rather than mess with pgp... next week I'll be looking into
how to implement the signature with the private key - maybe that's also
practical to do in libgcrypt instead of gpgme?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180406/f0b8f7c5/attachment.html>

From lpapp at kde.org  Tue Apr 10 14:03:36 2018
From: lpapp at kde.org (Laszlo Papp)
Date: Tue, 10 Apr 2018 13:03:36 +0100
Subject: dirmngr timeout
Message-ID: <CAOMwXhMEgAzd5Htw-0DZfTCvRsYXyvLnc+iQVa43EWwpzHBwAA@mail.gmail.com>

Dear gnupg developers,

I keep getting a timeout for "gpg -v --keyserver hkp://
p80.pool.sks-keyservers.net:80 --recv-key 702353E0F7E48EDB" as follows:

tail -F /home/lpapp/dirmngr.log
2018-04-10 11:58:03 dirmngr[11735.6] DBG: chan_6 -> ERR 167805060
Connection timed out <Dirmngr>
2018-04-10 11:58:03 dirmngr[11735.6] DBG: chan_6 <- BYE
2018-04-10 11:58:03 dirmngr[11735.6] DBG: chan_6 -> OK closing connection
2018-04-10 11:58:03 dirmngr[11735.6] handler for fd 6 terminated
2018-04-10 12:08:04 dirmngr[11735.0] running scheduled tasks
2018-04-10 12:18:04 dirmngr[11735.0] running scheduled tasks
2018-04-10 12:28:04 dirmngr[11735.0] running scheduled tasks
2018-04-10 12:38:05 dirmngr[11735.0] running scheduled tasks
2018-04-10 12:47:30 dirmngr[11735.0] SIGTERM received - shutting down ...
2018-04-10 12:47:31 dirmngr[11735.0] dirmngr (GnuPG) 2.2.5 stopped



2018-04-10 12:48:15 dirmngr[14734.0] permanently loaded certificates: 136
2018-04-10 12:48:15 dirmngr[14734.0]     runtime cached certificates: 0
2018-04-10 12:48:15 dirmngr[14734.0]            trusted certificates: 136
(135,0,0,1)
2018-04-10 12:48:15 dirmngr[14734.6] handler for fd 6 started
2018-04-10 12:48:15 dirmngr[14734.6] DBG: chan_6 -> # Home:
/home/lpapp/.gnupg
2018-04-10 12:48:15 dirmngr[14734.6] DBG: chan_6 -> # Config:
/home/lpapp/.gnupg/dirmngr.conf
2018-04-10 12:48:15 dirmngr[14734.6] DBG: chan_6 -> OK Dirmngr 2.2.5 at
your service
2018-04-10 12:48:15 dirmngr[14734.6] connection from process 14733
(1000:1000)
2018-04-10 12:48:15 dirmngr[14734.6] DBG: chan_6 <- GETINFO version
2018-04-10 12:48:15 dirmngr[14734.6] DBG: chan_6 -> D 2.2.5
2018-04-10 12:48:15 dirmngr[14734.6] DBG: chan_6 -> OK
2018-04-10 12:48:15 dirmngr[14734.6] DBG: chan_6 <- KEYSERVER --clear hkp://
p80.pool.sks-keyservers.net:80
2018-04-10 12:48:15 dirmngr[14734.6] DBG: chan_6 -> OK
2018-04-10 12:48:15 dirmngr[14734.6] DBG: chan_6 <- KS_GET --
0x702353E0F7E48EDB
2018-04-10 12:48:15 dirmngr[14734.6] DBG: dns: libdns initialized


2018-04-10 12:48:25 dirmngr[14734.6] DBG: dns: resolve_dns_name(
p80.pool.sks-keyservers.net): Success
2018-04-10 12:48:25 dirmngr[14734.6] DBG: dns: resolve_dns_addr(): Success
2018-04-10 12:48:25 dirmngr[14734.6] resolve_dns_addr for '
p80.pool.sks-keyservers.net': '212.51.156.40'
2018-04-10 12:48:25 dirmngr[14734.6] DBG: dns: resolve_dns_addr(): Success
2018-04-10 12:48:25 dirmngr[14734.6] resolve_dns_addr for '
p80.pool.sks-keyservers.net': '212.47.242.101'
2018-04-10 12:48:25 dirmngr[14734.6] DBG: dns: resolve_dns_addr(): Success
2018-04-10 12:48:25 dirmngr[14734.6] resolve_dns_addr for '
p80.pool.sks-keyservers.net': '192.167.206.241'
2018-04-10 12:48:25 dirmngr[14734.6] DBG: dns: resolve_dns_addr(): Success
2018-04-10 12:48:25 dirmngr[14734.6] resolve_dns_addr for '
p80.pool.sks-keyservers.net': '192.94.109.73'
2018-04-10 12:48:25 dirmngr[14734.6] DBG: dns: resolve_dns_addr(): Success
2018-04-10 12:48:25 dirmngr[14734.6] resolve_dns_addr for '
p80.pool.sks-keyservers.net': '185.95.216.79'
2018-04-10 12:48:25 dirmngr[14734.6] DBG: dns: resolve_dns_addr(): Success
2018-04-10 12:48:25 dirmngr[14734.6] resolve_dns_addr for '
p80.pool.sks-keyservers.net': '85.25.235.230'
2018-04-10 12:48:25 dirmngr[14734.6] DBG: dns: resolve_dns_addr(): Success
2018-04-10 12:48:25 dirmngr[14734.6] resolve_dns_addr for '
p80.pool.sks-keyservers.net': '80.108.201.53'
2018-04-10 12:48:25 dirmngr[14734.6] DBG: dns: resolve_dns_addr(): Success
2018-04-10 12:48:25 dirmngr[14734.6] resolve_dns_addr for '
p80.pool.sks-keyservers.net': '69.164.220.134'
2018-04-10 12:48:25 dirmngr[14734.6] DBG: dns: resolve_dns_addr(): Success
2018-04-10 12:48:25 dirmngr[14734.6] resolve_dns_addr for '
p80.pool.sks-keyservers.net': '24.134.103.65'
2018-04-10 12:48:25 dirmngr[14734.6] DBG: dns: resolve_dns_addr(): Success
2018-04-10 12:48:25 dirmngr[14734.6] resolve_dns_addr for '
p80.pool.sks-keyservers.net': '18.9.60.141'
2018-04-10 12:48:25 dirmngr[14734.6] number of system provided CAs: 153
2018-04-10 12:48:25 dirmngr[14734.6] DBG: http.c:connect_server: trying
name='24.134.103.65' port=80
2018-04-10 12:48:25 dirmngr[14734.6] DBG: dns:
resolve_dns_name(24.134.103.65): Success



2018-04-10 12:50:37 dirmngr[14734.6] can't connect to '24.134.103.65':
Connection timed out
2018-04-10 12:50:37 dirmngr[14734.6] error connecting to '
http://24.134.103.65:80': Connection timed out
2018-04-10 12:50:37 dirmngr[14734.6] selecting a different host due to a
timeout
2018-04-10 12:50:37 dirmngr[14734.6] DBG: http.c:connect_server: trying
name='80.108.201.53' port=80
2018-04-10 12:50:37 dirmngr[14734.6] DBG: dns:
resolve_dns_name(80.108.201.53): Success
2018-04-10 12:52:48 dirmngr[14734.6] can't connect to '80.108.201.53':
Connection timed out
2018-04-10 12:52:48 dirmngr[14734.6] error connecting to '
http://80.108.201.53:80': Connection timed out
2018-04-10 12:52:48 dirmngr[14734.6] selecting a different host due to a
timeout
2018-04-10 12:52:48 dirmngr[14734.6] DBG: http.c:connect_server: trying
name='185.95.216.79' port=80
2018-04-10 12:52:48 dirmngr[14734.6] DBG: dns:
resolve_dns_name(185.95.216.79): Success
2018-04-10 12:54:59 dirmngr[14734.6] can't connect to '185.95.216.79':
Connection timed out
2018-04-10 12:54:59 dirmngr[14734.6] error connecting to '
http://185.95.216.79:80': Connection timed out
2018-04-10 12:54:59 dirmngr[14734.6] selecting a different host due to a
timeout
2018-04-10 12:54:59 dirmngr[14734.6] DBG: http.c:connect_server: trying
name='80.108.201.53' port=80
2018-04-10 12:54:59 dirmngr[14734.6] DBG: dns:
resolve_dns_name(80.108.201.53): Success
2018-04-10 12:57:10 dirmngr[14734.6] can't connect to '80.108.201.53':
Connection timed out
2018-04-10 12:57:10 dirmngr[14734.6] error connecting to '
http://80.108.201.53:80': Connection timed out
2018-04-10 12:57:10 dirmngr[14734.6] command 'KS_GET' failed: Connection
timed out
2018-04-10 12:57:10 dirmngr[14734.6] DBG: chan_6 -> ERR 167805060
Connection timed out <Dirmngr>
2018-04-10 12:57:10 dirmngr[14734.6] DBG: chan_6 <- BYE
2018-04-10 12:57:10 dirmngr[14734.6] DBG: chan_6 -> OK closing connection
2018-04-10 12:57:10 dirmngr[14734.6] handler for fd 6 terminated

However, when I try to run wget via those ip addresses, they seem to
communicate ok as follows:

wget -4 -v -O/dev/null http://24.134.103.65:80
--2018-04-10 12:49:10--  http://24.134.103.65/
...
Proxy request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ?/dev/null?

/dev/null                                                       [ <=>

                                                     ]   1.27K  --.-KB/s
in 0s

2018-04-10 12:49:11 (95.7 MB/s) - ?/dev/null? saved [1304]

wget -4 -v -O/dev/null http://80.108.201.53:80
--2018-04-10 13:00:37--  http://80.108.201.53/
...
Proxy request sent, awaiting response... 200 OK
Length: 17 [text/html]
Saving to: ?/dev/null?

/dev/null
 100%[==========================================================================================================================================>]
    17  --.-KB/s    in 0s

2018-04-10 13:00:38 (1.98 MB/s) - ?/dev/null? saved [17/17]

wget -4 -v -O/dev/null http://185.95.216.79:80
--2018-04-10 13:00:49--  http://185.95.216.79/
...
Proxy request sent, awaiting response... 200 OK
Length: 5004 (4.9K) [text/html]
Saving to: ?/dev/null?

/dev/null
 100%[==========================================================================================================================================>]
 4.89K  --.-KB/s    in 0.001s

2018-04-10 13:00:49 (4.98 MB/s) - ?/dev/null? saved [5004/5004]

Yes, I do have a corporate proxy, however, the environment variables are
set up properly. Other applications work. Having said that, port 80 is used
here for simple verification.

I will provide some more information that you might find useful:

dirmngr (GnuPG) 2.2.5
gpg (GnuPG) 2.2.5
cat ~/.gnupg/dirmngr.conf
debug ipc,dns,network
verbose
log-file /home/lpapp/dirmngr.log
disable-ipv6
connect-timeout 0

Could you please advise me how to get dirmngr working?

Best regards,
Laszlo Papp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180410/e63454b3/attachment-0001.html>

From lpapp at kde.org  Tue Apr 10 14:29:00 2018
From: lpapp at kde.org (Laszlo Papp)
Date: Tue, 10 Apr 2018 13:29:00 +0100
Subject: dirmngr timeout
Message-ID: <CAOMwXhPzQzQ-ykGURXRaBXaBQWtuqn9D1QKFZa6Jc=QO0CDhcw@mail.gmail.com>

Dear gnupg developers,

I keep getting a timeout for "gpg -v --keyserver hkp://
p80.pool.sks-keyservers.net:80 --recv-key 702353E0F7E48EDB" as follows:

tail -F /home/lpapp/dirmngr.log
2018-04-10 11:58:03 dirmngr[11735.6] DBG: chan_6 -> ERR 167805060
Connection timed out <Dirmngr>
2018-04-10 11:58:03 dirmngr[11735.6] DBG: chan_6 <- BYE
2018-04-10 11:58:03 dirmngr[11735.6] DBG: chan_6 -> OK closing connection
2018-04-10 11:58:03 dirmngr[11735.6] handler for fd 6 terminated
2018-04-10 12:08:04 dirmngr[11735.0] running scheduled tasks
2018-04-10 12:18:04 dirmngr[11735.0] running scheduled tasks
2018-04-10 12:28:04 dirmngr[11735.0] running scheduled tasks
2018-04-10 12:38:05 dirmngr[11735.0] running scheduled tasks
2018-04-10 12:47:30 dirmngr[11735.0] SIGTERM received - shutting down ...
2018-04-10 12:47:31 dirmngr[11735.0] dirmngr (GnuPG) 2.2.5 stopped

2018-04-10 12:48:15 dirmngr[14734.0] permanently loaded certificates: 136
2018-04-10 12:48:15 dirmngr[14734.0]     runtime cached certificates: 0
2018-04-10 12:48:15 dirmngr[14734.0]            trusted certificates: 136
(135,0,0,1)
2018-04-10 12:48:15 dirmngr[14734.6] handler for fd 6 started
2018-04-10 12:48:15 dirmngr[14734.6] DBG: chan_6 -> # Home:
/home/lpapp/.gnupg
2018-04-10 12:48:15 dirmngr[14734.6] DBG: chan_6 -> # Config:
/home/lpapp/.gnupg/dirmngr.conf
2018-04-10 12:48:15 dirmngr[14734.6] DBG: chan_6 -> OK Dirmngr 2.2.5 at
your service
2018-04-10 12:48:15 dirmngr[14734.6] connection from process 14733
(1000:1000)
2018-04-10 12:48:15 dirmngr[14734.6] DBG: chan_6 <- GETINFO version
2018-04-10 12:48:15 dirmngr[14734.6] DBG: chan_6 -> D 2.2.5
2018-04-10 12:48:15 dirmngr[14734.6] DBG: chan_6 -> OK
2018-04-10 12:48:15 dirmngr[14734.6] DBG: chan_6 <- KEYSERVER --clear hkp://
p80.pool.sks-keyservers.net:80
2018-04-10 12:48:15 dirmngr[14734.6] DBG: chan_6 -> OK
2018-04-10 12:48:15 dirmngr[14734.6] DBG: chan_6 <- KS_GET --
0x702353E0F7E48EDB
2018-04-10 12:48:15 dirmngr[14734.6] DBG: dns: libdns initialized

2018-04-10 12:48:25 dirmngr[14734.6] DBG: dns: resolve_dns_name(
p80.pool.sks-keyservers.net): Success
2018-04-10 12:48:25 dirmngr[14734.6] DBG: dns: resolve_dns_addr(): Success
2018-04-10 12:48:25 dirmngr[14734.6] resolve_dns_addr for '
p80.pool.sks-keyservers.net': '212.51.156.40'
2018-04-10 12:48:25 dirmngr[14734.6] DBG: dns: resolve_dns_addr(): Success
2018-04-10 12:48:25 dirmngr[14734.6] resolve_dns_addr for '
p80.pool.sks-keyservers.net': '212.47.242.101'
2018-04-10 12:48:25 dirmngr[14734.6] DBG: dns: resolve_dns_addr(): Success
2018-04-10 12:48:25 dirmngr[14734.6] resolve_dns_addr for '
p80.pool.sks-keyservers.net': '192.167.206.241'
2018-04-10 12:48:25 dirmngr[14734.6] DBG: dns: resolve_dns_addr(): Success
2018-04-10 12:48:25 dirmngr[14734.6] resolve_dns_addr for '
p80.pool.sks-keyservers.net': '192.94.109.73'
2018-04-10 12:48:25 dirmngr[14734.6] DBG: dns: resolve_dns_addr(): Success
2018-04-10 12:48:25 dirmngr[14734.6] resolve_dns_addr for '
p80.pool.sks-keyservers.net': '185.95.216.79'
2018-04-10 12:48:25 dirmngr[14734.6] DBG: dns: resolve_dns_addr(): Success
2018-04-10 12:48:25 dirmngr[14734.6] resolve_dns_addr for '
p80.pool.sks-keyservers.net': '85.25.235.230'
2018-04-10 12:48:25 dirmngr[14734.6] DBG: dns: resolve_dns_addr(): Success
2018-04-10 12:48:25 dirmngr[14734.6] resolve_dns_addr for '
p80.pool.sks-keyservers.net': '80.108.201.53'
2018-04-10 12:48:25 dirmngr[14734.6] DBG: dns: resolve_dns_addr(): Success
2018-04-10 12:48:25 dirmngr[14734.6] resolve_dns_addr for '
p80.pool.sks-keyservers.net': '69.164.220.134'
2018-04-10 12:48:25 dirmngr[14734.6] DBG: dns: resolve_dns_addr(): Success
2018-04-10 12:48:25 dirmngr[14734.6] resolve_dns_addr for '
p80.pool.sks-keyservers.net': '24.134.103.65'
2018-04-10 12:48:25 dirmngr[14734.6] DBG: dns: resolve_dns_addr(): Success
2018-04-10 12:48:25 dirmngr[14734.6] resolve_dns_addr for '
p80.pool.sks-keyservers.net': '18.9.60.141'
2018-04-10 12:48:25 dirmngr[14734.6] number of system provided CAs: 153
2018-04-10 12:48:25 dirmngr[14734.6] DBG: http.c:connect_server: trying
name='24.134.103.65' port=80
2018-04-10 12:48:25 dirmngr[14734.6] DBG: dns:
resolve_dns_name(24.134.103.65): Success

2018-04-10 12:50:37 dirmngr[14734.6] can't connect to '24.134.103.65':
Connection timed out
2018-04-10 12:50:37 dirmngr[14734.6] error connecting to '
http://24.134.103.65:80': Connection timed out
2018-04-10 12:50:37 dirmngr[14734.6] selecting a different host due to a
timeout
2018-04-10 12:50:37 dirmngr[14734.6] DBG: http.c:connect_server: trying
name='80.108.201.53' port=80
2018-04-10 12:50:37 dirmngr[14734.6] DBG: dns:
resolve_dns_name(80.108.201.53): Success
2018-04-10 12:52:48 dirmngr[14734.6] can't connect to '80.108.201.53':
Connection timed out
2018-04-10 12:52:48 dirmngr[14734.6] error connecting to '
http://80.108.201.53:80': Connection timed out
2018-04-10 12:52:48 dirmngr[14734.6] selecting a different host due to a
timeout
2018-04-10 12:52:48 dirmngr[14734.6] DBG: http.c:connect_server: trying
name='185.95.216.79' port=80
2018-04-10 12:52:48 dirmngr[14734.6] DBG: dns:
resolve_dns_name(185.95.216.79): Success
2018-04-10 12:54:59 dirmngr[14734.6] can't connect to '185.95.216.79':
Connection timed out
2018-04-10 12:54:59 dirmngr[14734.6] error connecting to '
http://185.95.216.79:80': Connection timed out
2018-04-10 12:54:59 dirmngr[14734.6] selecting a different host due to a
timeout
2018-04-10 12:54:59 dirmngr[14734.6] DBG: http.c:connect_server: trying
name='80.108.201.53' port=80
2018-04-10 12:54:59 dirmngr[14734.6] DBG: dns:
resolve_dns_name(80.108.201.53): Success
2018-04-10 12:57:10 dirmngr[14734.6] can't connect to '80.108.201.53':
Connection timed out
2018-04-10 12:57:10 dirmngr[14734.6] error connecting to '
http://80.108.201.53:80': Connection timed out
2018-04-10 12:57:10 dirmngr[14734.6] command 'KS_GET' failed: Connection
timed out
2018-04-10 12:57:10 dirmngr[14734.6] DBG: chan_6 -> ERR 167805060
Connection timed out <Dirmngr>
2018-04-10 12:57:10 dirmngr[14734.6] DBG: chan_6 <- BYE
2018-04-10 12:57:10 dirmngr[14734.6] DBG: chan_6 -> OK closing connection
2018-04-10 12:57:10 dirmngr[14734.6] handler for fd 6 terminated

However, when I try to run wget via those ip addresses, they seem to
communicate ok as follows:

wget -4 -v -O/dev/null http://24.134.103.65:80
--2018-04-10 12:49:10--  http://24.134.103.65/
...
Proxy request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ?/dev/null?

/dev/null                                                       [ <=>

                                                     ]   1.27K  --.-KB/s
in 0s

2018-04-10 12:49:11 (95.7 MB/s) - ?/dev/null? saved [1304]

wget -4 -v -O/dev/null http://80.108.201.53:80
--2018-04-10 13:00:37--  http://80.108.201.53/
...
Proxy request sent, awaiting response... 200 OK
Length: 17 [text/html]
Saving to: ?/dev/null?

/dev/null
 100%[==========================================================================================================================================>]
    17  --.-KB/s    in 0s

2018-04-10 13:00:38 (1.98 MB/s) - ?/dev/null? saved [17/17]

wget -4 -v -O/dev/null http://185.95.216.79:80
--2018-04-10 13:00:49--  http://185.95.216.79/
...
Proxy request sent, awaiting response... 200 OK
Length: 5004 (4.9K) [text/html]
Saving to: ?/dev/null?

/dev/null
 100%[==========================================================================================================================================>]
 4.89K  --.-KB/s    in 0.001s

2018-04-10 13:00:49 (4.98 MB/s) - ?/dev/null? saved [5004/5004]

Yes, I do have a corporate proxy, however, the environment variables are
set up properly. Other applications work. Having said that, port 80 is used
here for simple verification.

I will provide some more information that you might find useful:

dirmngr (GnuPG) 2.2.5
gpg (GnuPG) 2.2.5
cat ~/.gnupg/dirmngr.conf
debug ipc,dns,network
verbose
log-file /home/lpapp/dirmngr.log
disable-ipv6
connect-timeout 0

Could you please advise me how to get dirmngr working?

Best regards,
Laszlo Papp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180410/990bb84b/attachment.html>

From wk at gnupg.org  Tue Apr 10 16:29:42 2018
From: wk at gnupg.org (Werner Koch)
Date: Tue, 10 Apr 2018 16:29:42 +0200
Subject: dirmngr timeout
In-Reply-To: <CAOMwXhPzQzQ-ykGURXRaBXaBQWtuqn9D1QKFZa6Jc=QO0CDhcw@mail.gmail.com>
 (Laszlo Papp's message of "Tue, 10 Apr 2018 13:29:00 +0100")
References: <CAOMwXhPzQzQ-ykGURXRaBXaBQWtuqn9D1QKFZa6Jc=QO0CDhcw@mail.gmail.com>
Message-ID: <87sh83rv6x.fsf@wheatstone.g10code.de>

On Tue, 10 Apr 2018 14:29, lpapp at kde.org said:

> wget -4 -v -O/dev/null http://80.108.201.53:80

Please try this also:

 wget -vOx 'http://80.108.201.53:80/pks/lookup?op=get&options=mr&search=0x702353E0F7E48EDB'

This is the actual request dirmngr does.  'x' has the key then; please
check.

> Yes, I do have a corporate proxy, however, the environment variables are
> set up properly. Other applications work. Having said that, port 80 is used

A simple proxy or one of those application firewalls?  


Salam-Shalom,

   Werner

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

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

Hello!

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


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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

  * ssh: Support signature flags.  [#3880]

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

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

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


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

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

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

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

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

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

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

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


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

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

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

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

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

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

     sha1sum gnupg-2.2.6.tar.bz2

   and check that the output matches the next line:

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


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

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


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

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

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

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

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

or can be downloaded as PDF at

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

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

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

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


Thanks
======

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

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

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


Happy hacking,

   Your GnuPG hackers



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

p.p.s
List of Release Signing Keys:

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

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

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

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

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

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

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

From lpapp at kde.org  Tue Apr 10 17:19:58 2018
From: lpapp at kde.org (Laszlo Papp)
Date: Tue, 10 Apr 2018 16:19:58 +0100
Subject: dirmngr timeout
In-Reply-To: <87sh83rv6x.fsf@wheatstone.g10code.de>
References: <CAOMwXhPzQzQ-ykGURXRaBXaBQWtuqn9D1QKFZa6Jc=QO0CDhcw@mail.gmail.com>
 <87sh83rv6x.fsf@wheatstone.g10code.de>
Message-ID: <CAOMwXhPjMcF0fmyPKr2b5d8xtDQJuGWugkf+Y7P-TP48gRRr2w@mail.gmail.com>

On Tue, Apr 10, 2018 at 3:29 PM, Werner Koch <wk at gnupg.org> wrote:

> On Tue, 10 Apr 2018 14:29, lpapp at kde.org said:
>
> > wget -4 -v -O/dev/null http://80.108.201.53:80
>
> Please try this also:
>
>  wget -vOx 'http://80.108.201.53:80/pks/lookup?op=get&options=mr&
> search=0x702353E0F7E48EDB'
>
> This is the actual request dirmngr does.  'x' has the key then; please
> check.
>

wget -vOx '
http://80.108.201.53:80/pks/lookup?op=get&options=mr&search=0x702353E0F7E48EDB
'
--2018-04-10 16:10:08--
http://80.108.201.53/pks/lookup?op=get&options=mr&search=0x702353E0F7E48EDB
...
Proxy request sent, awaiting response... 200 OK
Length: 58162 (57K) [application/pgp-keys]
Saving to: ?x?

x
 100%[==========================================================================================================================================>]
56.80K  --.-KB/s    in 0.01s

2018-04-10 16:10:08 (4.29 MB/s) - ?x? saved [58162/58162]

cat x
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: SKS 1.1.6
Comment: Hostname: keyserver.miniskipper.at

mQGiBD/4r7IRBADFuacEqf9fye+NQSm7xjNP705aq75VrUd2hJyPmSiFUIyQEfc44GQXGdFg
+/Apq4iq/50/8pR8YXOKwP5OE69emEp7IxjST41orGUk5ZwcnlSkaruNWLTe/lN3e0oOIVbY
ig1lUbU5IxZu03KfNg2DZ9JiZdNBlzlqx1+oFlWFLwCg3awgEfOUfbe4kVxNrsnxaCJYJ38E
AMRVyUOfhkm9l0YuiC4ebOHrdmn9jFVW+XZPZDeb8DcyTBNrgvVTnEmrNzVJgOyZIW+uraBV
itak+No1kwXvC/i0kZEzYqfG87EdJSfeOV7axIRisiTrcbZdRJ3CBDtGvLqJ9OuGFHPQmntn
ZfhiwJTR79hepndEQYyV5eQboQ+aA/0bI+/odyRDefc9HF1EhOcz8E76QP+VlvUfIDUJrmwv
/3gLZ968HACOe0DE+bcUockLJxoNwQFwCQPjm5S2+Ba2uY4hRhOA+MResZWlPouoosay2ADf
iU7pdBCxnbcLAuezgnZg4jcXvLl1QiAihxaEI2jqgZBnnierWzqRzRZM4LQrVGhvbWFzIERp
Y2tleSA8ZGlja2V5QGludmlzaWJsZS1pc2xhbmQubmV0PohGBBARAgAGBQJCkMV3AAoJEIvY
Lm8wuUtcwrsAn2Nb0qwppoWfwQUVOKNDEwpdM1d9AJ9WAeZcDap/wfnxevVm49edWnWJgYhG
BBMRAgAGBQJWd8sPAAoJEF3fj7dojjGmdGwAn1QhYfhswwjV5md0XJgyoycVu7+GAJ9AKQoI
kvLWQtl9mTrPOFsCQSBe74heBBMRAgAeBQI/+K+yAhsDBgsJCAcDAgMVAgMDFgIBAh4BAheA
AAoJEHAjU+D35I7bejEAnRYLqlswwk+F+pWcppXLnsskhTfSAKCrg23hTwzaaW9mlbmDavid
+QQu3YheBBMRAgAeBQI/+K+yAhsDBgsJCAcDAgMVAgMDFgIBAh4BAheAAAoJEHAjU+D35I7b
ejEAnimR6EoAAiEJPea1nn80i1C3KY8aAJ41XrfHtf9Yp3cE/8Aw5zmww3zNlIkBIQQQAQIA
DAUCTTs5qAUDABJ1AAAKCRCXELibyletfPqjB/dFnhX6ap/V+z0b/NxBhOiYGofwJ1aLRpGt
vcRfUp2c28MOd1dhf27fA/+2Byrk4sfaPajUY25uWHH0qhDMU026BPrLaNoc6Eak/9fkpMZ1
2YU5/rncJULBzlTWyRzXiTFDoMe7mxesJq7zSxB3l8vTnVrBE5B6vwHIRD5Y2h6qp0GIe9n/
AJMj3t2CoBVm/3+qEDN38CRsAD+TXLrFRN6V8dkCLB5UX2w/j8Uvaj5PrGtePR0wI5z77jjN
VR0sG5cqqo0xbH6tiG8a7GuxEV9Nsn7KpiNstaazYxCVxFoeXy5RKYt2+6G9taBwGHGLEnxM
qbBWTRwCyLs/BILho9KJASIEEAECAAwFAkJG55MFAwASdQAACgkQlxC4m8pXrXwhzQgAkSBD
CXpkVz1PnO/k4pO5or0WtjDIN8mzajHcMTrLSZf1dGp5B1741V09gM5a5+xxCp1N0Sr2szJQ
3oxdRYoFKQpgGbeoivx69t/1fQzheyC7kxdDkfacsiInb7yeyfvPfNDT9/UCeL7FinjMup7g
PzPbz5imAVE8gTXrHE86l7yMRU/RisoMNjkCMxJJk/0TkmMPlgsnWKpW0tDODXfQ+p9nAnSM
FcTDZj1bcgr9qFE94hE/nB4imGy7Y2Pyy2hkrUVhIary1P/nziWpP6pKW85SSMW/8u/jor/1
ryImrzzUSFMFaLHwpPq1VNwEbxDUDazJH2j8PfMXpStMLsWZXYkBIgQQAQIADAUCQlgonwUD
ABJ1AAAKCRCXELibyletfIS6CADDeXZws1WjpoGLCBTgL18Qf8BtitA4WmhAbk9BHoU+gH3i
CaXZfxjPXib722M8lw2BrZ+UGW9NShu4D1dmUmKOcEnKw+polbcIXED9ab2UoSQL3SnlBa6s
png2AWXL71WFAzdu/FXpIiAyj04MiwOyYqNL9TfaHji5tkutMkMOCXks+pgUP2hfhWNeWTUH
gEr/q+/DGJI95THFeMJbDlxlAMYBfHoy5UfdVBCwVzQX2vxXTgSOUdxHO3GiV/x3llODip6l
v02tptlkboimb4L0KobAVAt3eZNeB2AhSqja6srqs4GiqzmuVBalV6qpGfKWk+wI6IimiK0E
Z0nxAFjXiQEiBBABAgAMBQJCafbnBQMAEnUAAAoJEJcQuJvKV618S9kH/1P69nxrz2M1pSxg
BinLCulwCDk964eoglsH8/MvgzKiyQLnEGiaKJGfJJaaACSO5ehEUUab1pzz80cr8LGIgXuu
GiDrLKdLrvF1Y0KMdN+qz/6ABQ9a//9HshZaSprBPwB0qt6OcVDzgNHwh1VhSK+2WfuX4ajb
AXLimU8meEoYJ6tBMERD4ci78HhVPvaXxwZjCLMJP6ncJHW+1k7X7jMHdClPiMubmhW9+zyc
zojTzj1H1ZnokGNYe0TzpVfqxGQaayRICeUym1yLZGSUAIO2V9FyfmAb3oAY56UFKjUpArnY
icz29/Wqzw/aYcnztPH4CzhdfsAWb08TzTzQM4GJASIEEAECAAwFAkJ8bXcFAwASdQAACgkQ
lxC4m8pXrXwHCgf/V4aLbchOUCv2QpCJwoeXHoGCZve15inevBeDjXovItHCe+uRlWEwKuj6
3YNRP4wiuwUlMspTjtBrg3gIXoai3MtXJGjuyGJbY7kSZfIywK+Dcea7pwuCj8pMU1lbe7uj
w7ZJPFegAKosiqusVhN7IqB3g2/PaKF8nyaTvpqo+kCgVhJZ5v71dGlxJlV2k8rgiQHV4Kvu
PvBOVlcSvYDHGOtZ33F4oCv2b0xwMse8Z17FXj2LT2RZaRHmVj1cVq/VZJhYkHzypztC0orh
aasGxH8sjkHaswS23li0qUKTlIy7JxqpgCvPCC++/5nXrVVuuy3cXpK+sGaUYqqNQNhxeYkB
IgQQAQIADAUCQo2T6AUDABJ1AAAKCRCXELibyletfOEgB/sHQJOBMyMZOmj738i4+WT2aIaF
9y0eOhMCnYd4PPTWbV11u4SoG4aivRzWyAdKk5E7Q4HieOrbGCa0PyhFdLFoPOS8r37wWrmj
o9MpfRSYXUTvbx3v6mI5XdxSZZRKjy72K8UECr2ksXFsIiBnZRRG70h0XWWvqHElzRUVDPMG
ZtoGddHIUY6Egif7hmB23QRGpuJucTRCVfPQC9i5YJVxlLQ1Vbe+Y53vfO920ph4XEyRQCGQ
Rb2rRLbrEtOH2UteCijmQsL6AWp/VOS7PiFg16Q1n9/Bnzk/cWQpuihOULEMIJm5hIHG6KVF
5KyN2SZtOWtisrmzDKynf5GUxYQsiQEiBBABAgAMBQJCn2FpBQMAEnUAAAoJEJcQuJvKV618
5joIAKFMlfN/fn9UTOF59VsycoyzBMVBSkJTiHzgVEPnkhsc75q5j9XFU0Zi7+mgp9Mbcyt+
CB1z43tDz4S0FG3uHFAXAzL3MkVYey7TiDXXLVtKJVX7XodkOeiFjmFb278hBG85S2t2piG2
kcY/G/26/xQ14nDAG9knoRtUHDEUOmjWDZ+hWpYJ8svgU6YqMP06r/ryqr7yOSr2O998Ba7x
jNKwek9A4PolJ9+6GnLs+NqS3FU7LCpIXkjZFBPGQTWniU5J2PKG1xn8r90+cFYJhvNb7QOp
22bz79IZ3UuRyAvIRyy/bfKYaif9mvRVHgdyicn/bLWSxcOBR9MIcG5MTlOJASIEEAECAAwF
AkKyjVMFAwASdQAACgkQlxC4m8pXrXxVBAf8C71P1kPCiHDqNDeViNqj0tVeefyFjKjYl0eq
1dGsXMe/M2+8cmw0SRpMWkaJzVMsT6KOHVDxJhRSjXBf34CPARjlKm5onlZDF8rp/YYySLpi
iE8i6rnMRXG/kq7bkrv0m6gu7ssOiGheUNcJQQOoJiye1/8+SysDlNVGJ/1EQbBkn+sU4P7S
/KvYkauKinGJGDXrvmGjAYveQwwIE/tKjFTlW6ecGNAN9b6pxXIjcDpv2A2V4NQGq5hylGKH
mMGy79XL4FTass+zZvWKkM4h9uhh2p2jBEoW3fvSj2Pc5fEWJocijoBYhjsxrW9JXcxAcwMC
fl94urJXcSzG1UjLqokBIgQQAQIADAUCQrSIaQUDABJ1AAAKCRCXELibyletfLOOB/9cKPfa
ox1RZ7TEQhVRVNL56KHfvka+wLxa60cGEDPmAcjhavRBMq0WdMCwLd2ifsCSmj1SV4vkan+K
DnGq5uHjLntyUSrQBIN7h1oF3QDSh4E364Z805leOBjrLw3UjkNN55kWGhT7OqnwcabYdeDG
Yi7J+cCP3rzfNBLor+euqpmeLwg6ShTyYxhnVisPoYPTdFYEhazKLy0XNd3fKpsOlyfmOpWG
aDaXMuVbvLgaRf54UluIt0bhhXqQHAx6QfgWXfp02FsLRtkfcTEBDgMHlaQ6p4Kzi+Bs89xP
RfCWMC43+Zvd1Hxe9WJs19JqyTfz+9lAmeKdhwxZWWkJ+bULiQEiBBABAgAMBQJCty5jBQMA
EnUAAAoJEJcQuJvKV618TxsIAIYz9tDH23V/SKQjvx0QV567vp8mz60gSooq9HMerk543RQd
28P6PVJpNFN8mAO8ro6urD8Nl7XgJDbW3H4kjEP1aTFJn+4JMWhwR2Y1ASSphOsIMTRJbYll
4gq806xNm7u5P7wYjql5+Nyl45r9PV/o1oGCVz78OtbTFp8e+dn8lM9XI9fiqeFg5ORrYSuU
CrA5caZpagwFadzmhbMlZxdf4ceFN45STjdYyXUs5XCPE4QY4SUVYWSmM0YWJ1sId/yr3Ubx
gf9H/R83vGjRys5Po1deGf9iBID4DZQJ82h3wXjlVZei7oqH2zBYbloM17JwCZ/jM7szuIzH
hUPPPDeJASIEEAECAAwFAkLRx94FAwASdQAACgkQlxC4m8pXrXzQ7gf/QarcdS+MboQRpRr+
MfeF3vHib12hHRB4CJhgkShYP9ZvikPAfjlJ2Rv/yZxCjpduRqpW6WmYRKTYyve1y7sQGDVZ
4nyVGSKIfhMOaORMDoymqywYFBGUbTMiEz7MFy2+AXA28VUonHHGTBTd5RDyKaTFd+QhtTLG
DNngOPG+oXWOsC4Hd239C6Jx25Y7pZVsn2/O6NBZTTlhewk9OSpHcvK636vZ2fESOicStbkQ
rxcIr6hKmLHeqbA8oJrk45oe/Bd4hx3fGL2SZtYjyKA78sUtfkxuLHGUbJsLIBMvngVQXDOR
NTMejEiuAZBi+NOCfrBqTWwUyEQrpbLh3OA7WYkBIgQQAQIADAUCQuP37gUDABJ1AAAKCRCX
ELibyletfOSIB/4rDdlbNvon/1NP2j/kAKImmXOIduFNQ2Kw5ZbPm6HjI9Pw6U2LT2r78ws7
N7ZNAgsFnEOudCxczzITsuN3xwK06nGPQssnVyNntX5K6Qsf1+5IP1nnN8AfvD1GBuZ+j9Bv
C0/gVqNoaeSTIjcXkwf4a3x/xzldEWbq3S5vUjISgcLzcXSzGsZ+/OMiUsxktzQaLSzqRKDj
9F/T0IuiF8/U9KyoI3a1100us3iPNaEV08xYR0aEqCsUj10f6xQ8B3r/kcyjfT7hmmzGfyMJ
lD8dmiLJzfNzwAHPtb/Wr04vHSPjphxB7ZwOjChnYmAKoSxU5U7upBw4K1clp+VTCkf7iQEi
BBABAgAMBQJC6T+QBQMAEnUAAAoJEJcQuJvKV618d0wH/0PRhlSiEAVYFlPxMTtfYq310V0M
CDckOiWu6Q4SORJNTrwqSnxbibyIwUrZr9XBInT6WOUdfYgLaVzqhql5yfHlyfFSGrl7kEcK
phyyjf0BMawXr2U/ATRd1XMmklG+kmolyW70AC24tXJg/8PRfqvnx/Ze1eXnG+T7Dxe1TZIt
u1sBpbEocUkhEZoBRQvogBflIfHqcf8yahEc3l4WGx7re1jeanHpde8RXZPnYE6arPA3/zz0
h7jnoYjeaucQXwtslLDg5gSd4Elqpn3PzLC1hdhrt9UY8J62SC2E1Moy46x8UkxtA4FtFKTZ
r66Z6Z4C/lIBM+hYOcHzf8bfJZWJASIEEAECAAwFAkLtNBcFAwASdQAACgkQlxC4m8pXrXzJ
mgf+M/NfSydofqE33eVw0KUjaifQnxo2IspvQ2J2gO2P7rGgUrafJH91j/mAGB6hKWVeZPp9
e7u2zjD2yDextDwwzWGKTVeMNfvU9alZkv0py7R1/UAjhbbQOc9tBtAekAAFjtICYls59x2h
dwr16+iHPSTqskrPBaFDnkEcC93XYZ07tT5GqQgNhaLe9fPHphISHlKhSi9o7t9wX+c8cDDp
dsK+aoFsmOELZb9JPLAwsxwKUm2b2+1D9avb16hx4p17eGdqd5VCg+sybU3446OfC7B14qVr
tD5DcJ+umKh9mABe7DPwqVZrCGtM67woYsAdRPwerEBS170X8UEwrB99rYkBIgQQAQIADAUC
QwcLNQUDABJ1AAAKCRCXELibyletfFAlCAC0cd48hADic1RyB1u7gbSBbfiUNnq07h7X5F/g
BnCVI0V5ZU0ir/PP2wFEN9pXE2LMTa6lHd6TQXTIMZWcxkXvbmCo8Eofwnb/aSTzyPvVMxdn
2m6m+3vTevlIXFY7/XRK6ccPuStNwZ1ELJVYYPleDzX43TZP9yjMv04Rknj9hNuNxth5LGvP
qOJEDB8CDryWDpFvUEffUcUe1Y5RQCaoXA6i7v+4QyOkIgwyxA5++U000pOhuP77LoC1QltV
ru57/VMFxQ2f9rAUvbaJWsGNfd3t/RzbCMm7D7BnPeoBpacUJloy0zzlNvqZPkq9zcb4XcJ5
vXywh1mU/QxTaJBLiQEiBBABAgAMBQJDCF5HBQMAEnUAAAoJEJcQuJvKV618eJQIAJ9wuanL
ILWzv64mEOcR7zyJph9N/CGGs9zIQGYs8DuJzbzXRAxGMEzjUbFHY9SKaiSXDCgksixVyuzh
l9pOdmAtPS/7BKwkD2jfXWJMGDBIT3WAGR2jmQzdm6LzuWILJwsmxmm413rwIoHmZA4/rV8x
HdR5m/b4Yii2zP2vrJMIM0v0g6iaqbZnlm+7Yz3WaYhKkBvSEA3aT+QXwbrOBY0NFcWrr6Q+
iV40hA9oA8cCUTw1zwohIOdS+o8f8BW741NXXSnnDCSW2/INxLRyYSysd63nNeixdLKPe2/H
fAismR+Y5TaouirexSuPovzalsr/Toi1Sz3tEPLZIYUyl02JASIEEAECAAwFAkMQ79MFAwAS
dQAACgkQlxC4m8pXrXyo3AgAj8t+J5TGTJV+7+VYQp1DCYLLRlSIKyhdVPaO9D0cdmByuriZ
bcZKDwbib7Tv0IILdvHcr86HRFF733XD9CIP+ib8Pr5vX2+bNAwxjI+Luek2paqyw3KQWYGt
fK59Wjb6KCRL2ypAHJ+OQiLhYqHeJwd4NNASIQs6tt2F0k23AKB9QarRVeRMOhAymeJQf43F
pUkJ+/0rVpvDxY0mSRdAZeGzo126/3pMGHJ+yYe6xPWFddi45OyJGx06cxQH9JfitnR7Z0bX
FVvRRcIOEeIvymooNIb7uxgFpYi4awButoHIsziuiLT69xHpbEBzcDgbxQzUp2mrqBoZiwak
KZU6tokBIgQQAQIADAUCQxJArAUDABJ1AAAKCRCXELibyletfAfRB/4hp9Q+o6qksYCtSXAk
sOxy4KRCcJLIpcmyQB9Hn/Hy0IvPvz4zzXsuIAN0P//Ai4/cr1c4JNMfOzVFsM+zp7dvRoSU
4FTrAYbmLQ/LD/PG50huNxfVt5LrXXExpi6/1kj4Qti/eBfOQmR+EeM9x6GLzAaeii23LUob
yleimESTJW7q6Fs+s1dVeNQi7pZX9zvvsJRy9eY47BZwsSV/Pw6pk8BV2Hf1JTKdSSaLHpOc
iMPYjwpIE3uq2fFvoJZ5TWwjstIDfnP0govoFpx84d2tHlZHUILMDDLUyRh+N/HwUDozxKoL
u8pm3pAm0tvLEcTJDkCNwHJXvuD/BpGVE84/iQEiBBABAgAMBQJDFD8BBQMAEnUAAAoJEJcQ
uJvKV618S8sH/3WjnClUuDWzPHZaMD6zHe05O1+IHCgGIoWdz1ZFvVGXJm8Yhw9y1Dkv6aSG
dasA19/zYn9VGEybsu074AkIUlmJgrDi2V36tzbMpYwrTl0M5kpI4atnvjp7fVBY0SMH4SyR
24w2K01CTymbSkrWcbOpUunXjlivlhzSyNHHaXHbkejhdjbw0fy/meT728dqHXwbv6L0YCwE
JBn+JMM+9aVwclqYvDfv8l+L8TfVoCFcpXbPbyt4DkNK3c9Z6ampd/M8lz0WdUUrM7zSHIgE
nqCFabn6WFLBFnQuiWrxd5FCTgT05OsADNqRQqbFzJxhF04SOdVwaFkMpXohNDWn1FSJASIE
EAECAAwFAkVFtokFAwASdQAACgkQlxC4m8pXrXy5vwgAw5MXUO/8ZZPs1oExyWvwOlXTmeQu
C3YNSTHgEm5g78lLSR0qkSIX2/Fz3EaHO4AQnz8IqqzLMPbH9n5sX1TS9+E7QXDoQ3/mO5lP
lEaedFb1q9B04hPNfrHldOor3bxSKqhTdltfH4sLecIu/O6eie0B9e10Z5oVVrZvKWvFrApy
KDIb5aOnEHROprtm5YN5/up3E0NT8LyXOPbTc++YRgYLqC7PmF/gzxFW8xgdYnYl38xLWAJ2
YsBQH6YK9Ph1OdQy0FF10SEv4s6NzPdG/u+W/KAbMaqOVypX2qCl70B7ocIM71LuytLEzw8P
OLuNvLaUi/zxO50XGMCyAKYrIIkBIgQQAQIADAUCRWkcuQUDABJ1AAAKCRCXELibyletfNZ1
CAC38Fbsrkz++FBVh/LHFGaOZbB1ZeeFsDoXaI94K+pvYOg6ehblGlvbgDO7mNuCJOi37x2D
sJFWIGnfxCluyohO05ACUqsSAxaQ7LvKvssa2+8C5UXjYncKwHaLYXMkNlgdBhBr+G3nzk7/
xnaIK8OrK9wM4kJZFSmqN3SL6TS2JuJuxEiQ67j+H0IU+ct2YYVEWUUu7XNe0Xri1xwhuA0i
B7bcZ7l2LxWuTTgpkriyfg3J3Civcf32585NFYBF0xhkHHqijfC1ENB8rHPxwYbmOGJFmnxW
IBD86aQb4QWluH34VscAhV/K6cZcyt8C6IWOP0GqLNBnP/w2TNoG0LxUiQEiBBABAgAMBQJF
clFhBQMAEnUAAAoJEJcQuJvKV618mvAH/3O6z4uj+G+Teq8hrIOv5pNRolmovtDnMOSK/BAL
Vf4QRWmaUghDu2LG7A2QiU5xdxi5OwbeXX86AGmIn/5AGUFMGNn2g1O5AmmJExT+t5KOtqnp
XlJunAws2H8nUXG8UF/5xqt2v6Gi1L88jGfL9uCb4lBwcF8TAPRh7YZnodirn8P504t6ln6d
6AKOmGS0lVggvCMqtWNDeg/IrrlgK8OsSZfIqmyq0k1PZlpNwFwd5EA/tP7jMxoHgUKf1hvY
/Wde/YklBnslmP/dKVpavRAKuFmLckXBvMzB5838AailH+P+eagNXW+6qea1Nry13+46hDaJ
q2XqXrZ1hrxppJyJASIEEAECAAwFAkWDrwUFAwASdQAACgkQlxC4m8pXrXw9cQgAyeRIVh0s
OAFKBfCFpFxl03oX2kl083GbUnCHxLA5B+UhiHUi/syPL7dgkkXGudVGihOYlr4iWdaOq8Qp
Lue5d4z3p6gmiaT6BlPoyUGSEU2EWTmMbCjPfIni+XuMJLvoMc/RE/2hHDxCkTHKvhKJeqUc
e59g+6rNb/5StnyBwKu3hP/qw/Kqo6uL1/oTbckJmNIQ4flw3JEzVjWfbMGqEWGmJJjEu30K
Q95zhAPx2/mk7wXkYDu9W2Q8GPx6U06kL7RGnbzMKY+gzhJq2JTq5MSPBacEOidHUbB+4I8L
CTECJmHEvHHpliNje+QoKStPvu/RO0+QFlSW85c7JmT3w4kBIgQQAQIADAUCRZV4QQUDABJ1
AAAKCRCXELibyletfJnZB/4+nYQPhMSRvsVk2WKv58gIY9e46zwfD40Nn9eKBVbnK5oFVDl0
pzvKqGI8cxrUAC7ssVejI2MceOTUotYOy3SpWDuP5GRF6mtDPZ7wMS+tg4ekyceIausHtC1I
qlooTqQE65nUm5Ne9SlMEvD3uJzZXv2aRXW5dP/TVTFzY0jlT8JEeKPrjYv9eK7q6Gh3HKhP
BWKnoZhJKKXvWpMAglvc9qIS1oAPaxGPAr8ooeq2piw51Ix+0+LKTJyNn4azfGToXoteNoiu
UQvhJ/QXFiybCdkxjDrhkSxgRgGTI6soJCw7E/dRB21Ho5pgD4cIeC6PKYVQSG4N0iseKI/9
kc+PiQEiBBABAgAMBQJF/vFTBQMAEnUAAAoJEJcQuJvKV618fHUIAL+Fdcn4ghjUgnRa9VPy
ZVlGgLjKBqIQ0BWX8p21HBsQQzj5tlJljBNHdm9Sm5TofuWCKwB5n15VjNcbOgZdZ+3USoBa
tcsj3Hj0gEjZ3A4DhboAAr+VlC4qugorgyklQnqMIxONGPVqOym6Pxu7pAYT11bgkXA3otRv
5Tz/7X2Qg1ycC7UV1lSoB1wLhPVS9ob3NLfv7b/rDszd4nTi4biGvOZ0wXlsCdVsFtgnLpHA
uwFjBgC6nGeaj10lJY5haH/nModF0PRDjjxLU3FzKk2W7N+6yQ4NSGpiNPn8f17bE2cnuqU6
s18aDsYFvuxTc6ENc+7l1WJOoLREYFwn7/yJASIEEAECAAwFAkb4E9IFAwASdQAACgkQlxC4
m8pXrXzSFAf/TR1074fmr5wD0kX6koTK199NM1AuItjKjTYfzJyp6I60vFURfx5tJ/7lci3v
DSnhdVRJ7u7WZKOs067neBgR2QK8PyZArwcUspUA7itisC74BqqyZtjKX6PULPKylpgPLGxy
Z2lmMTYZZnjw2CcopEWofPojcqtekvpzTqS1i/H6LwCjf6q59lTGmQ+Du04/MgcgjCpbhJL/
r2WqxdDAsLOLZiIV2cHPtUYJ3s/EBd2kay1eH6xsWJZad4IVQ24jfuci9kK/Vs6ot39+BmN8
Xz1c8sjfYgcm3lU/1vXudBywA5YtcvltiH+hBs3vat/szqATmYsp2gYspu/fyi3YTIkBIgQQ
AQIADAUCR3ZLbQUDABJ1AAAKCRCXELibyletfFXUB/48hJ/zSmsl8RvHHlBm93KvBzSv0NuU
Q8CxCRunbn6QbpceX48nUQ63GxwbiERZbtReXFnUmG7rHAu+geUbUyEJ+1X28Os1L0ki1UXP
ibQKiRvz/oJetBb2J7AcwwWKN0BdvIvwJbl/K8Rb+WUdfWl+PqKR7MgBJKFBM0pEfJ+Viu4i
kmMJy0MfrqokJj4VBVnsk+k3qM6OpJ3oM0I67pYrvMZI3aEoyCDNnTwh+SxF9pBctbaoL4x5
6PY84fGLiSlRAcghyNpL0sbuxIbChUO633xRIgn7Z4pT2pfqTRJnLV1rBYAUKvrhaheuTXFT
nDvhQY89rLw3mZm+0Yd0EGqtiQEiBBABAgAMBQJJnxtjBQMAEnUAAAoJEJcQuJvKV6184wwH
/0SI/ZUNOLMkocQ14Rqkl0mkV6pw0O7XVb8TVNylCwZoluivgPfTdCjDivQQbIcP7feyhn3X
YQGpRkprXVyNXPIS2t/3TqVtONuM9+w8a2XF5WizVud7TGJpw2pdNBH+A7y5UmdEaNzYCaOU
M92mrY1eeH+UNa5Zqzw6bwCFbSBE4YzLlwHBRzoANhdCkQriIBnwVg+tekkFhnSegRO16vdX
eP2BX/xJbKRYGEnp7I9xLjYISevYhsyMZyOvwUnlevdRDzkjAkuR44N8mAo+UvywK1JENBUB
ACYQkDDUqxIIAMs+rmBlMJ6OlkMNBvwuVvgtIsq2TQNA7fyz824XL7uJASIEEAECAAwFAkoy
p9sFAwASdQAACgkQlxC4m8pXrXyzBAgAxqfnKh0o6TepLtCO/uhS8aqbQTpBu1L8NKqBVN9H
CCJSZCUYsj01thT2/34Ff7tSW3RGlj1leAnBC3tDfvfEA15LooUYdgq+Irfba74BU3F9A0W2
2fXytgLnbHuD+UGWtiWWBGvgL0f1V8xjxQR/qheLHIbXpdOGBVljukcGD2NTJBSJo6TUMvZp
OmVvr6NKy7D2DFi+p3N1lw/w79MtFnfJu05gbDLh2U6lKUTLNwDAXhz8IWp1kmqwMKcfEEC2
R06Q0QlZ09xpu/Oc77KHWU5rUF+hUh1Y3Unc10iGRuDs4iANujehrBBo7vn8N0m6w+TIiRqq
7vtKlxDZDfAxTokBIgQQAQIADAUCSkPL1QUDABJ1AAAKCRCXELibyletfDTNB/99VuCUzvff
kvyYI9X2/lQtYDVNP1v7qYKIXH0Sis1GMD7bldoemZYeAMmAcGYlKlq3O7ZU/3JhEHHUMxhZ
BED6JgtCeRnCMJc/bzGsqZ2UeIH5K9jjwpEUHI2Vx/DXTgPhQ08U6R4HNvQlEboOXKBWE1B7
ssQEy8KYkeZNho6/SZsP3TKbv80Hd0pMrTHk+YuGZC/7atBCYL62mBCtrkDvE0Zwl001534/
zv0kjqIUP4h+lL4KsgVAoGNIymuuF8jfwC6zlTwO4/1PHH6mRsjEiH5rKyMpVhzQ2tHjiQvp
oxvSaU9Xq3zHgopdJIFFDAXaJrXuz2gCg5yR7r1kTBuJiQEiBBABAgAMBQJKVZe9BQMAEnUA
AAoJEJcQuJvKV618Y6sIAIWP91MHjQAFUwUzqma5kapz8MqlaTfDJQI36m8kQaZXZql/hV4G
CbWKj8A+cFuwebjgIhfEBLuCEt7fKh62Wzl4C84t6YMJuLSDi6PiDsiO8xT32ITKHWxDOp0h
jmuGL9mizsI5HhQmXmHr+OxwI5DwwLMwY/S5Sgh2SPWqSUWThGDahQcY71UtL+YYHj0PwiK3
CfiQrGilTuOX2XTTvW0x0DOu2q4+u4cFJcYNBe0OYBZfv+BgulWSvSn20i+RlkrXoRCVxKip
ATousz700b0a96sGmv1anCLJ40YeNwmOF24hG3oqfWvIPGsW4xJsH3FklzBmwv+3S0w3pvk9
03iJASIEEAECAAwFAkpmu84FAwASdQAACgkQlxC4m8pXrXyOqgf+NKUChH5NB+igziNAHweB
pEy+M1VNsWBYQBNaL1qNIfuJeoq/ixTeBQtkd3hyEzHhPEmfr4DQHSEa74gORWYVQ2SH9M+A
bA44vOZe4jwfLdJJksFCH5Q6f02/xSHfZ49OUGbSJpQfCqqS7aFCsuBFsqp7Fixk0M/t2G9Z
yCSYRtSswVHOMSGN9Efz3twry9pLInIcp/6dTdz1jMkzBJ3fuMaMjY00Hp5sdnMkWfHIWqju
50S5RxqnCS+e//BjDqwZ0z9xduOv80+063LDgi40oJ4LMltLNYldVU0tEXyT7oXpzBRbR1WZ
I3ZuS7YjmxEFbunJvHIBCuaV7kcQ9rFar4kBIgQQAQIADAUCSniIRgUDABJ1AAAKCRCXELib
yletfKcgB/9lXze4YEYnO2SPPSpKUoz3Fb7/jmX15Ho0G2LSzRAqueivyoDVzAaFcz2Xrt6U
6EUFNokLUGyfBgkPqsIpq9Qx5Wumy9cgS31vEePBCIn5XEeS1JqSV2zyQAagjyAoiVGiT1Js
6RGR2vt66hV1k/1OCecp5XcAeW4zBkuK2TleHVf065RFyfJmopTkASeDJeHai2no1Um2/rKZ
+zW4PJa+k6dr0ED6ZVG3DOHouh0rqOoqV8FzmzhPNBI6NX9f6K/t5JoZvO45hL5xTZQCGn0N
cWxglEnz41KMapihiRIIElJnJjSKio3n8XTyqLXnBzMR/szqAYrKzU7Bs3ZKuP98iQEiBBAB
AgAMBQJKilNKBQMAEnUAAAoJEJcQuJvKV618fSgH/3MY7I8XsbiNRD0XDkt+vpqkhpDr32x0
qZUhTOeHMSftLJUHqHRQ6onBy7QaO/Ay3AdN5zYbqg0GepNZl3JuA8lnc2EDrvULgtTiyJi9
x1oWKuKL22LHbvtX6e9RxF3gOUwh1R9AzKQYlbAZ5XkwohSGFdNDCFxcLMiQi1URUzZD+Zf3
L2CqKS9i3QqLgKzGR2O7u+737NIce011H3v/H0k1q5XWPstAyMuZDYjE8eoijfL0RVkxJ/PO
1C0ccdGYLJcza4CrCavxiMgsSaIkPbP1e7OHSqmTEeK2moW+L9ZU74ZcdnKLT3w94wj8oQKf
69v/U6swZmo3lhCTvzxQ50iJASIEEAECAAwFAkqcH5QFAwASdQAACgkQlxC4m8pXrXzWmwf/
d84z76cCEHfQ2aqtZ7T9Zbj5wpsQ2OJiTzI0QttH2980f4xKecPme1zRw5Fp/Q8PQtvak83h
pt3Ngek/LreYpakis9LH1Yolcrz69u0iHxkQDMZp1m1k/yqUS5a5+yQbsewIhfcP3edhjL28
EyznSSQnPvYm4ZdaOOTp8sab6MCiIGQlzA6j9GE3u+iHZ4BlHiMYTWarpXqTYhrl/AS8Vlqt
FgsHTT7POe9Nww7nQXkehlHT2d4SWrv66fszjsTkSbUMQ4O88jf6QGhVkQioI757l19KNQOG
5mBmTJMcR+/o9X4hBC9FiaatJCZO3/+vR+GPzyFqV4uWkucW9q0MAokBIgQQAQIADAUCSq3q
FwUDABJ1AAAKCRCXELibyletfDgRB/sHu7986hjpiMemUcz0y3OMml5qNjIZX995fxITHExL
zW3L9GEkLBZ9hwFsP0H1lJlA2H1+eBLcibMdHmPZObtnIEBbt6aHeQID5sR7HkIbIujSpg4I
BwYjpKB6BaCiDRcCSSs8gv/78csDCCZ75RZDKO0BGYDBKrXncLyQCbI7pGdaG6uB/xWODktX
QEJzSB1UdKoD5sPicX0WX+Fdb2lLU0puNFOMD/ZpMCWk0qELktjtFpbgmbGDz0wOFY/BkUSg
8w/LLNPzPhGr5WOgW/nYqRMH3UIWmDQ6zZyUCIKSrNxceky+k9VHvsEacTwMl5/YcPKyTsCW
W5G4D0J98RsViQEiBBABAgAMBQJKvw8iBQMAEnUAAAoJEJcQuJvKV6189aMIAMbPN823Wq9x
PyRzkWc+EeXqKYXmOQLdSyZ1DpE5mV44y3AKpM9rdjvPrr8clKawfxYdUB7XzkO2fkd6jGnV
UEwcf+MRc53JH3AhN8qUbMQUZKbkNn7AyaSdZPzJAF6hjxAeD8mpv90vf07rqpkGwyRh3sbY
n6n+JTxI54/CjeUnva5CBO3gJM5ICuyHqf00xKC9m76DNhoIo27TeMDYr0/XRYmogFIDHw3y
gbfhjcP+GU2PmL29GoA7CxgisLCdb5fgVTdYoktWQBDSHum8xFqEsKVTUehFKKibUWze70XH
6ELfgSqrEWiVW7hfgdzxQUjxmHErl6RbuukPw0JqGLeJASIEEAECAAwFAkrh//wFAwASdQAA
CgkQlxC4m8pXrXxHIQgArne086ezVic6BKT6+a2xGe40ZXUCDGE1RnbKskQBk5mrwS+nklUk
2Xk9p0iSztP+JAY0nm/dUKYN+kCpxzCvrqlDigN29acBe5LpCdVGScLTCikhUqhL8uUQ2eku
zWHlnQtHWiyCiTD4TIkyl4a3xvwu8b1xzS1gGijEpMJHn409goHmd4ja4KXM9LQg8/qQxc+S
5eGR8nP7yBdkHhM18qDKXh5MNg9CBEw+ucjb/y8J4uMk/LWpOOuwKsZTQrl3DvYdc/3Ic7NQ
giBs8bRaz1trJo4jH5uMfwzRxGjWD1K5lglqPXdkL6YCCKqyqs5aIBS6WACSrVSUpF0cv94j
vYkBIgQQAQIADAUCSwJ2wgUDABJ1AAAKCRCXELibyletfCuZB/4hw1k+Ef7405x/Y9wXoY//
7VNzMkA6dgywDHKL5gpPhLcKTZCxYCVhB+cUQl0slm794XhnelgE3O4ZzgI67CGiAlsC8+1i
QvD7ZkeQe+YeEbCGAEGSO+fNf+Mgc8qtYW/aDj0Zj7XoCoqRNhvTXmh0tmbW0ZtFiJ6etgKx
lWvOtyPKvKT8wvxSSBNYp1TPsJzEJSqdCeM2Fw9fnaCm7jGcc+g69gcfmNsxXo/FCSl3XU6d
5YHiDGzf2IFpQYA7aSg4UcTF8lvFw65Gxwk9ZwgP6vYBN+g2l+SVoZVCJ8MC+x/QtLK7fiHi
u/Bf7ArgcmYua5Rc83SWrtQzOoCNGIzziQEiBBABAgAMBQJLFCfGBQMAEnUAAAoJEJcQuJvK
V618m0EIAJCgIKNm/pjBVuVHiAsOhsTbX9oWuj4xmD/NhuDoGHaQMRDcmv7JpP/PmffIDcgg
JRzgR+dzaR6OY04sEkLosppKb8aAHfJ6ubsfs6QyFCEKlQh7jPbe6QvdvQ7SA4TX1s1ovn2C
fQwQFbDDUoYNtSrAqsGTz4ND7Eiz++RV1l/+N1omW3RoVfdvBhh4eFenfAWXm0QB7Mvx0Dgi
aCN82MBI27v8HdJI9yNisBQncz7tE+Yv/pCLa5PyoS4if4h2vlnwfiWpH3W7uhOot3MDSYeo
98TFlMfZDbzCC+5qUSPncP8Curn22Mk7rnlMclyO5kFSrDnLa0T9Pfzbjuc3ikmJASIEEAEC
AAwFAksl8+AFAwASdQAACgkQlxC4m8pXrXzXpAf/VLo0ZDWBwb2I4Bb2w5GNtQHMO7Dp15ng
zJwb3G7OgdVMVF9hjME0r49tRDYraiHsuiVsTUgc+4odJdpoI9A65fCcpiMCCBPa0X2GgbqL
4tPGBMV99fhEmFVm4dpzRc255hQ6SPElzYkKQLRz4Bikt/S++k49DdNTx380+wTxy/T2VWB8
FigbY+IkC8W30YFyCoMhBB9mlPy4oTpFG11h4qytn73S8vEjnoy3/6+jzMZT1tZXvhn3mZCW
XEgULXM3x3l5RUi1QVAkB/uaTU8ekmHfskRbmADsJQgy990ll2t39HPqxguiSossjm3IZPfU
nKoULVfqupoWLZ/KFxbGbYkBIgQQAQIADAUCSze/pwUDABJ1AAAKCRCXELibyletfBblB/46
tYBgV5KtXsYoRbjpfyY115hWmdft8TIYaw/kdh2/iHIp9FESsvGNllUHnAuwQfNemB1vvXQ+
Fdi6hou3h7tHEaxEexhLL60F3FduICkKgRGSVv8l9lgKaNhw6Urgo8WKd82i6A/fMMPRLFla
AHudrbeb3ncBF69qWcTxBaMJ7vp9nDCKmie/JCaBjRovT2qes/PGR93z48OHOp9yMd41I7bp
XuV94V7m5Kqxl8kSJojwY6X7X+K/fFrCKRFyIi1Z1xF/GQSOxTjOUHe2ySEVeSh3lZ3HFjAr
9bsXVviScIWy+l5na6qFzcM2CbaefRVhs9szrG5/9sXox0jOYz8QiQEiBBABAgAMBQJLSYnU
BQMAEnUAAAoJEJcQuJvKV6184NoH/00fFmM6g5Y3u46FNrtcI2UlgViM/v9tdVH5PgZKkgnh
74ecn5amaCIVZnAbp15iHdYfeLHlpZIBBlDBSfm6w9ThiBjARKv30mRUkg+qm4uHHmFSRl4/
zUDK3/eplx0g1zGnM267JztE3kSA7GKaUtfrlBV4WZW1/IRohoUeg4v5usLv2+KOPQC2skI2
1RHrdPUT/VZN6AMtqLnL11BLj4FVBSUeatwvFScRz9cqtmEAbSNxR8sWl0kCWDe8Vkr4o7Qh
8O/thWKnJc2anLEUGU9VlQfV3uXvH7pbiMWlgSvMZ12VfOvYfzQpA+lSgGJ8M3qp9ZwXjNzo
CgWkyDzfymCJASIEEAECAAwFAktarXYFAwASdQAACgkQlxC4m8pXrXy3lwf+OmX7aU8i9OqA
LReheHxiffVcG5J1VupYiuMXTIjAuvwhYZasTmXxjWb4fqa7tNRyaJn/SGzFL/Ouyt6kfonq
hKu6ElpGsKMw6TsDyc2EpTN5Fw96ZQgrsHNOz4SyxmxmjmyMSpLh5HeSOFLJmVDUSSQW235Q
AMlHPhFU/xqXdJximzu0iLyHBAnGe+krtF0g1LD9+SwLTNsIbxrlt6karX7rLwPDoJqKodCp
IS1q0hVNIrwgLx6wBeJDhj4Y5bWQSgAxoLdtwCZzfUg2JuuFJg5jhb9hSro1FiLJVzQrfxSC
de9VY4t/4cD2i8soDim1XE/hHyQ2jEXTlcaoskIdOYkBIgQQAQIADAUCS2x43gUDABJ1AAAK
CRCXELibyletfPDECACG3Ne6Pl16tro2C7AWKpWTyrzlglaWTgCOgCrNH9MRf2qZqOZGQmsM
MkAAmRfmeO1QO2H4+aT0fqGBQXESIC6P+a6hpwkpRkIIGyqnfQURvu76ViRvUnxRZwW+Bx3X
sQ79plV+hBjfQSm0+AA2UZv16vxjPERbm5FpyHwUxLpkDBo46YQ9RWkqbFU3YEwwCAOE3t0Z
0PArwOlXDlNE3netocnhFnyUnSyqIpiq45ljgeoKLehOReI2CaHxS+tfcAKLHNokiFa2D66H
obzL9h1QlcqbXDj/FjUabdYaDrPynXUMp85pLRQr15D2phALtTWM07kyiw8zEmnREMZyj/8e
iQEiBBABAgAMBQJLfkUZBQMAEnUAAAoJEJcQuJvKV618KWQH/3qAqVtKvOqmkkm7SpRA9ud2
HOyEGSWQEbpbr8FOamqv2pfy887ZlMACP5bULFJAFYH5iTV4YDjfAT9jE21fBe9he3kgdzTG
4r1Px63OH1daZuYlPePKbjRm3aABLs22sWjEhbLzyW/6C6g548YmEZ767G0FFvjWcLcLrHqF
LlZ9yx7MxQN+hM83bp8+GweuQftrVJdOciqU7c4Hm2Q54WPIOhZLe5uGT+lBVUcp8I/XE3UJ
Zd+pwBW1LvN/eEASQ9NscOYnWCdMhzDS60f7S9uI/IRmfNaz5CSnGWeVttos9bBfhXTyk/Ry
7ArHj9Bc3EFrnQ1sjy+Juq42bKiaW6OJASIEEAECAAwFAkuPal8FAwASdQAACgkQlxC4m8pX
rXwBfggAghizhHjICpHT1oYNVDdn9/IHX62CUKtuER3n7cXejM1TldcCn2EtIyoMtsz+wl5Y
Dg1ws6HGtch5gQxm/+QDTFinZgcCDojOgfO0ZLNPp5FYQAOoaa+WING/2eBjxWg00hAVndss
h/ay0ZSsD3wHTClcdSnpUvBswhAzaCbzRekcYh56pQTjxcKNqSdycn7khG5cxmdVoIpyza8D
OFnt2EOH8RNnrXinhDU29SOxibiA/miLCUQIFaqzsVWbN9+rtX3fR3aKGiPYOlH119lTZFfM
YIrnjGr/s0z3TTfPQGTpkJMZefNcUR8u0vu5G4d+SWAMoBNDvDrZ6IA/eXvlX4kBIgQQAQIA
DAUCS6EpfwUDABJ1AAAKCRCXELibyletfDKTB/4hHynuMN4J9fbAkByIjUtkQNb8G684Aevi
dwIfOXwSRiWaP2LSzjsr8mrvA53aBFr1Vcv37UTJ73cqkPdFWsV753st8HLgqF34qkiB467A
Ak5EJGpZHgQXa4M7nYivh3WBLkYgQ2FLiCd1GfN8ed7wgELAqucl3SWPorToHQXOWs32uP1N
sa8MWtzlzDtSCgbnVCa6/DlAVP3F6VoJdyHmSoB4INcTlQDJzmTeqmCI6Nwhocz7P4BSQmoZ
sFXSDBsImpFWr0qq/rwMFo7A58QDk8sDREsbMwyGj/QI+124q4MAzyvt9vs4Ztwmz/Xrr15Q
oLU4l9G3KOuLaTiSEUHniQEiBBABAgAMBQJLsvWqBQMAEnUAAAoJEJcQuJvKV618RB0H/RHY
NWOWavLg4/sKAwUyLCQOs76pcQnI2FQuBRQz1owldhc7CHyDtGVcaepEMpV+csiyEl9T0Ib2
OPdNhOY1sQyp3ze18koaHfIRMcfMawAZxU94T1DYhB9Oc5D8ZdgzUsIz5rgU1aOdpQIf2/Lq
QIpPSTw61ujsQSElpD01x4h5qY89rFezeBxJVDx+w6uTFKh+7saE/U/XgtSfmQCX1y7cAbYR
JwUG0CQQm2uNiJCywxS8I9WXwSvupvlyFjT5+dsbrv1eg9ET3erx4WQl4c7djLlUhiNEaVbc
u+w6uJYY045CqybEAOt2oxhATjGza6VRl71B7c/zHARR9a5JLbKJASIEEAECAAwFAkvEwOsF
AwASdQAACgkQlxC4m8pXrXxTMAgAt6QBQRowSwtro++slwiayMsvKayAuOX1tuMayGGQmuZC
PNOgej3+JHkINu5YscWcWWtveZLw7vRilt2Wj868rqT2lLalyBsSITz1+btgK9LYAdlE36mW
PA2gRBjefTCnBBICinskNbvvCyqd9J4Vy1/CKYGkwZdUdMa8oH0qpprJCfBaDxsV1Tmn/mPS
mhqefWgsL4LYB+nH7XDpiNPP1Mot/vmZALdUuKbAydsD+HYcwmcXigk6ohuSAYmMK2qQfJWn
j9s7Am2+ug7x13Er17GdrGHXK/ZJqJ7INkN920SvJqyG6xUyNQODZaGB7hORj4hkaFxxPtnW
6CStSviVF4kBIgQQAQIADAUCS9Xk1AUDABJ1AAAKCRCXELibyletfJh7B/9R61Dn/g0U5HUu
1bPDw0mUow2TVhGMLjN2i95yIt1dYXmdBV0Fk1jK9WWbfzfPaGKaaVdlhhvg8cd5ko0KKWat
e2m1/de1qWLwni6ptBdXaYnSwNPjTW720ys2pzPQyAxu63JIcMN2tZVXHXH5pvFWBbgKz5WY
eUSSZP4T/KT2s31TTh6IuXvDd39V9X7VroQpodTNSnZizL2TsOBBQ1sgVGtdfTY+khuvROcD
6FU99oG0St5HhizI9t8uqQYHSjl7v2tToGQgwI35BTthThpHEOD1ln/NhZQ4CgMMyqkNPoBX
LLXao9xYh+sYb4lfZEZ/XP2Kpias24+Oub/4UnSEiQEiBBABAgAMBQJL3/aCBQMAEnUAAAoJ
EJcQuJvKV618IuoH/2oIN423kdC14KUgMp5ej1sCTOvwkkuOc8S2qpgQ6HNiUusSgLKEelhm
qR1HEwSAT8+B8WdlZ+NGpnmpn+rcChdYQpuPFTOrYjjPXQbsK+zEsii8gOT/9mB/3d/ociwR
S2dnZKAvXKJMqNucrw4F4Fja88PBKMXFZEQLe1sUikSUGxoEpoI6FOWmACKmdFFsiSfIx6gr
YvJdGLVEbKuwnHcDT9TFSBsguiNXC1cKh1xXR46p5Lx8fNCCNu//OFpujk3lP0ooFthLqydb
7+XR/L5T53yMkd6yENcQO9tXoDfWmwyuh/+bW4Q3rq8QYs61v8WUi3D0D9F4Zd6KSGdug72J
ASIEEAECAAwFAkvxlE4FAwASdQAACgkQlxC4m8pXrXzaGQgAuSKKR6mYfPdl7bs9cVXyFWoa
8VEygjo3ooYOpduqOaDoy3xZnDGpEk+2pQXY48xK9BImxx04jVidOEmBsU4DZjmvzwR+1hKI
X/S7EzHdraQC0OmoHQIz4zuesvTjHoyfNKkoADNV+CfEvE1sKB1kBsuvF18pz/lPykceg9IG
U+Cz/0ndsp8pV86knW/K9xMdj6/4WuZLXvtfkRz/2mp1yFfv/kQcvzcZsKoUDVMKJaMtQ7F5
eVBVSp4/RcCJJ0mhqXHp2gdOUdQyQWifNn62eAXtGLuadlz+oVbIQBjeuXw3yiQnQCvqk4Ek
vVD5mRxORbmZfVw/zQ8d9ExMRKo0IIkBIgQQAQIADAUCTBUtdgUDABJ1AAAKCRCXELibylet
fA1cCACCuuGuHFCdYsIvxGYgJuWV5kW2TQBkRbX2YNCoWKeBcYuxfV4Ogj9RE+BD4K4Qji3h
XOuYm5xdrZlbMpol7Tz1XCN91mlXYEODkmsj/5iB+FKPCnoqo5JmSwMQmNZvMjJty3s2NYP6
0lzWx02586HhS832n3dWO7O8GoqDuQL8LJ5uWRC4YfuorgVQqEu51+FPHIch2k3Q83yWArNu
bxg1UDj0fFlDtbvDYtavBJVCL6UUYOGP/BZfBnlhH/+uxTLgO5jg49NoOs7yF2OsQ7iIiOL2
NUJVQ5HcMtEneprx0rQjtNWdFjXRgc6RaiGxEkYZeGqu3bqT8dJowsyXV0l1iQEiBBABAgAM
BQJMJlFYBQMAEnUAAAoJEJcQuJvKV618iJAH/A9KSFYjn/cP5v3fdnKTYPFe8ljkHP/9JAa7
b+yOPG1sKuqC5VAZHB9iqZJNx56dNzC2ke+JsjC75Arvos6R9tLyW0NRFiX8c7r6Z8PpXFmH
XurXL9panrojH+Y7i3reFBFsmTA+tORj26fNNzFWpJ1NP1fYBYiT9FFeGX2L5DLfSKSRBGm3
k0Sb+tWF/c8s2l6sLnTLgtciwfvfYC/7IU0y0hczQw5sXAkuPdUPwvE74F8ipvfyz2SXydT9
NeferWlq1lEgdEzA1luL5RJSU7d/cti3rqs0fy1n4x1Egc5ZyM3YpGeVlaj8PNFiJ6wYr2P2
2W6zzmsQuXDpzNUiMFuJASIEEAECAAwFAkw4G3kFAwASdQAACgkQlxC4m8pXrXzfmAgAovVx
zTqARQAYuSqMobCt9uSnJlnCI5uzE7i00laixYRDJ6bSffZjhBMqBYEUPFcSLgJSmIN1Uah6
fHdaZaBDCl18UgEdtaUVZp2cSGJNAwNweri98vYPN1w0CjqALo7OOuozEeI6z8CiI69yDQuz
ROLUK25z44AVyw2GULGOZ76hECioFTv0CtV4+pUazmwMCXuCXoyLDTIF0jQ7SG0qD0T19J8V
Gf6Y3fXE0ADKfvyK8w9Ud03kqN8GAdE5VqW++oSV2bnyAg9nLdjYn/NcJJnodMMAARvjdmrv
WjLcodBZf6tcSQlwi9DUhNJITJuBkVrmK58S4hl9feYXKn71ZIkBIgQQAQIADAUCTElBTgUD
ABJ1AAAKCRCXELibyletfOULCACp5MjEohyouUzj1/yeUNPXcV1neJt+vnJ4ISgXMhqv7OjV
m9693v2FyxSpzeOEZLxl6RpNS0gI5k6YMiSLSVp0bVVhe8ueZpoYkcsy60HvLepIVhJs1ht4
EArb1AXfgE2tJs3C6SNeiR/espW6NwZQjxfYI46F9qDf4Rudb8fXQoHTfv/FvHz6OVfTMYsY
DTdX+/Bqk0bGvgw5LmR/wQIrGvUgbj0ySJdmK6ozsL92FLXc5/pOrKxGUowDHibkEqfh58UZ
PDVrglQ/s5q7BWeKG2FtMa1d0NlOv3q3YU0I8lZ/L/2eYOL7bRLjtvyBpP99xE+u6XWtZqmu
DqH3iuwYiQEiBBABAgAMBQJMWw3EBQMAEnUAAAoJEJcQuJvKV618RKgH/iA3teXYD9bysypQ
MTqKogV6NwzaUCui1yqdtjOOhlOFUas/RxioHzHf38uvz4F76FY6eLG1jq/cWetSWmeffXKs
qHQkIhwxHOth0FF0g945pom9Iwd8/HouNh7MOKUCbnBbZR5f4r0Rzf0P0X5uKqMtwkCw4mxQ
VRUBWcYm70Kh+z1wMpE1EGhqRKSsDnK7d/JG6oc1eEfQAtDalnoC7OzDpcjtZogrrXB6BI8M
eNbRq3FNFVsH37baIplFw+DaRauyUpPco07VE2Hxmzo5jl1oXdZuo/0dPF53FFulh/wr2x7l
caZpywCDom5UyeEcXZMsM8Ig7deRNMsvHj6Ua2+JASIEEAECAAwFAkxs2UcFAwASdQAACgkQ
lxC4m8pXrXynDQgAu+QB72FsRI0hSFiJ3/US3i+0vB1jlP9ibur8c/6Ji3Jm+5uYGqI2yv6u
fFYYXFXZ5Pv4FCvWeYD+kxaU2MYpw1+37odVxElMOzrXboFSvEfKqP4eox71k6SbxvKUTMPy
/DuDVNwOChet4hX/Z0fllTjglPZb6G5HJzH04G0hikY8SznCJLimbLopj3+kqIHLvFca3iXa
gcRPKEkz7Lv4at4H6vi8ei5cUwtlO1cBvbXHMJpW8DZGazDAvNeLIvn6FmOHm6+L9wqPsFCS
aT/bFLBaz2nlNGjFATr0KFyEgf/FZiKOroWhL50X6vrHScYEUOas0ZOmPlUonGGAzW3CgokB
IgQQAQIADAUCTH6lxAUDABJ1AAAKCRCXELibyletfO+bB/0QhLinOKVQT5puNDzWJfsZ1VKQ
a+MVmUl/5Lbkc4WzVok4kkwB3DNbtj1cw0TtEjeGBBMcDzhdPPzZTzbLhoZ2kWXea+nPVgWq
FfeCOKHTCi11AXq38Zg85EycLREfvuO0WPdvhgwQRCoEu+oHbzvtpJCSsq3hejdhktOFllwh
3mlrS/vUwNSngrwRrGbjPESjboHY+QUAQ75ucTETcH1J6TfHce8tMl4WGUohvcKRytrXljMz
Alj/hrQhbl2VYXZAx7eIfbD7xXnRmEzaywYOn573FLenDUCk2pEuxVpy+nt6iozv8pJLIXqp
992QN179pBvj82Kygn6AdqF65cZ8iQEiBBABAgAMBQJMkHGZBQMAEnUAAAoJEJcQuJvKV618
8DYIAKEkxDy7cfHlh2lKoa1Q0OingHAlHbPiDtwteAX4+5xLRG6EjzultOB6A242/Nju/Iew
MJJCV0XSMOiNut3n95Mivl6mm3zcDRK7L82qxxIkDCJHIzMT0ioeOQu89KMoO0YxEWbdbGHz
kK7UhUUdazzS4CDetjqQEYakX5MW7iGdiP9intxqyzQWlvSzVmJr+sdDxJ/riYye7P1J89g5
/NESq7UfESLZc+PSwNVORtWqLAkUYohAyw4CC+o6/7YI20KpHxFcqwF6MwxZRitjgvdZq7AW
hG+Uk9/uhxJ1lwleLkfO4OIKVfcn/2n6xUvfjzOs2O1R+5ByeRRpKzknTQyJASIEEAECAAwF
AkyiPbwFAwASdQAACgkQlxC4m8pXrXwYDAf+LLsTvCbMI0NRNtIIC70b6uxpVwZUnTBNuNBf
SMhEv9FhgE5G6CsZPh3CnznQeFBG8BISX/KcD9as1c3pswtmZDByNd06qlNEwHYWtnrRnYYR
Oc//ByFDjvt/0YxXLPl4qwnFXiSoA+T7iOSQid6irF2t3bmDWEgii4JBj1iFZcvM/T7nzgLZ
G4ndO6xQrbDOr/PS+yoU7+Nz20qQ3rSQZGqsg0fHeYqTZzkf0A0rO70PDicEUwmi2IMTxdS+
OJpaGZ5f2lv9jUYeENvSSS6EK5T+JQJplpFSXTMdTe9bVIAS2R05IFy3khEJB5ZAGr4wPFJP
odTvyHXqCsAf8VgPjYkBIgQQAQIADAUCTLQKzwUDABJ1AAAKCRCXELibyletfPuRB/94e1or
4ueFk4Fkf+8JR2F2Q7gIyAlKjOPa753PIOsd5wuMfEtafAXAJ9mSkibCgovMjsERIVyg80L8
NREeeFUGsgekvsX0NxRHS0yhA2uyYSBBMpKYjHbFe4wbwTfm3h4eS+W9tjPfAAxxtMRxmYdD
oLLDCzh2VKaPwtdo1nOl1C+gCFEoBZ9JF/EbpVDnRcVD1giv7KjPCqcdsg7xqA5Ehdpc3fdY
b+d0h6OmEcCAYygPdCAiTMdscltmmtNhdKhEB+/oGpR01b8IvenuepnGots21yoAclJj5Pl2
YuFiF8yOHL6LH+93LzFwBs3bqFAdH4YzBI+Xr7GbSzwxDfLciQEiBBABAgAMBQJMwKQkBQMA
EnUAAAoJEJcQuJvKV618NXwH/RtLqZhwQP9SFiIxyFSAv1HOlQsDTz//9W4GzuEfmljihkNq
QLcVZT2d8qQ61AjTRYaLkSFJ4tkRCZpE1sMR0QyaEOUfQ8xwO56MPBKg7/GKXgPnG9DHd5Eg
vNIhBFyAni8prtB2uyRQVfecrO23ONGFW9sX/7zPoT/PNmp1sgSb5skZYPT/Zl28hILfSZhQ
AGJQBV78muN1wWW1PrBjpKBfoKOjDq3VCiodiQLP2KFZ5nOLg6UEy2KtZNOyqAZEAvqE5Qu0
Uy96eS6v2iYIFeuozItun4Axy3hMXrgTe4WBxb7kp2nn59rkKgYURFxgRMui4FOK+4pTLF8M
Zx+brBGJASIEEAECAAwFAkzSXZ8FAwASdQAACgkQlxC4m8pXrXz94wgAlQJ6maFsss4IVsBr
tYkKr8si37sRrU1/EeG5hmoQAqyf1a2yDlH18oOJ5n2ipWo2Ekwfq2ZrTUKDAjDfh4JTgviw
UFtHEzJbAnGAcxjmWwCjC2KZBSktZQqmNhcu/tsleVP9KV3YntdPS9g67DVgqCDWRfIGtFIb
v9TxgVOy0drT1M4VrJfiBr9zgIsdroqYShcfobIZjYEoBqdY5yK5iUvzLOAGUikJCVjcBctx
btUgJgmIELlhheDOOJRg3bp/F+5JwHYyHA9LkgfGYMbM7USpyizr6Mq/Dr2i+Vaq1/a3Gnt2
5a4jGbFV5tRKlzxp7BlCc46DvKCrUJza+R7F+4kBIgQQAQIADAUCTOOPfAUDABJ1AAAKCRCX
ELibyletfJaLB/9GErOFucKqYaJprFSqrsgZaHry6/V8QjRS5jh6wTRW8Mn1ng3KrBzmFSqG
RcBgDNkEzU+A8sH0WKpFwLfTaSLym9kXIR0/ALost6O+hBsZHpi5Zs3vCGGlCJOIo7SkSGvh
E8f1BeCmVXNRzdD8JEU5S7v+Yqbwd9+QlBvGn7hviCfw7gPtl+fkCoSTnGLQjjTpr4RjmjpJ
Fm2d3mOW2Tz5W4cxvFLVZ0n9DkMFgbLcSYeCr692W1zfQ79fNmgkLgBzIvGmHHNW2kx/NVpQ
LlTwXXGlcWBdK0Jt3mWHkkQcY7R7FkmSAFsS3lF5THA2lRjPkWqpa1ZW1KmERNEkpGC1iQEi
BBABAgAMBQJM9VsIBQMAEnUAAAoJEJcQuJvKV618/WwIAMVdn7ZtdNmOEQPFzZJQgnTsc2YD
4bSYDSFq+CoSuBAfc50f6fgC4vANjD7aBqHxES8XKuQvYKCFXM96LKperK2HIcLBoHceXhBq
HDwjQ7NnUfBgUTOQ8VFnvVNGdRUNoEpM3py3tbyxTNgfS6bxB9lnfI4uf4clnj7txZZ9HLYF
x2OHcheC1ji5QveRfLbPC8o7eXMn8Y6rqYLFqDShHZ/hnERiOGXBWByuoEbAcZg4vkFbwlrv
CftbfDnC0PJeTU67iGQSaZAZd/OSJEQ4fhf3vdwutsmvIiD/WYpPukPg9nO8XNiGP5MUMKQI
jYtJMo54rnbn4eGDH9LJjkQObguJASIEEAECAAwFAk0GfokFAwASdQAACgkQlxC4m8pXrXyO
kggAnnvCQV0HKHvXGQlsbjX2XoEoLnzlfoFFtCT0JYXl1ErACEoLFtNeee6V8g7oby7ZhKEx
ZheyfDFenCMeJjSOs4sSrySxx8G7kMrR2xLbN6mbb1/vlBBK2qH71g2NcOVdlhEsajgTQF0+
yqwHXJXmmHS4jhaLKB1m5WckvjeSjl6WC96rRk5Zb82UF78UR1SBUMdJqdq/4Ztxubqr9D40
sdwfDAPY6Oo4dQTrkgE5p4fJ4DpKJyMN1wjwHsKG/7NgZwSsCp4NZ9QmejuQC/GphA13oikv
mJwuA779ZeGj/0eSYOadSUKnPAllJu75XEwDyx2YTvcOVqPTf8i36oe9eokBIgQQAQIADAUC
TRhKKwUDABJ1AAAKCRCXELibyletfO+tB/wONdv4RM3Y/UR9kMwq+FkZuu58d/v7IuVK+ihi
72v4dHMibGuQSGhU7L1kFEJg9GPSxcTraHLaI/6iEC0A8aCh3hHH2BEhjjfnZAOz7RCeDGDx
kh5gJOXV9CFRqzjVlzHUJT8y4EwYiGQ9nGYTdbyVVOsAG34xjMCA/hIOcPBL+ha3Ox/MoHmb
Gb4cApuynNf1eZn5e1cspk2tIFQYhBi1Hrt3LdHKgQnoyvibw0FkmvybaB+d+5DWc9ApLNw5
/qoljK7ynfqXUlREL/9cJyGXrLd4OxdHU3GPJMDu0OE1LmLkblZSYbmb9oMrKymEuNqydZ2m
AtT2srul9gYjf4vQiQEiBBABAgAMBQJNKW4fBQMAEnUAAAoJEJcQuJvKV618SRIH/iOWyn5b
kCeu6B5/PR1wJMV+zN6MhTiHK32l1Ic0beKfJO3npUPB/k60FGM0CJiVluifGwkTrUKFAgza
HDL3qoDcb2QNmLijsWziFlnVrdByUJQvflHGU4GDS3kr+cutjMVkPLh0/2ZJcKB0XZyP6D1H
ZSB4nVIOYpLO/CwTzCppVPLS276y+U8cjtRnMLuhY0zmoTKGl6Qj7bX7qYYdhNmG/f+hpKQY
i8fBsT08NjHsm5aeMkiY6+7r+A7jnglR9dvWWHuD1L6kYJMZqEXNXVNNhaN7JWzTDjZIKSIo
BeTuGxbQdBD6AzOStXdBkf8x/7V7AnBalX6I8NpzRtMhIEGJASIEEAECAAwFAk1MXZoFAwAS
dQAACgkQlxC4m8pXrXw+gwf+LnUqU37JNpOajjyR585YI4poSC0+lLHw3iUZp7+Wui20KyLe
UPSdl7sOchSeCAnCQQDncUoTlPCeliVaXF1Z/8uWwmQsMlhCshfbHzxVRYTa4U4pqHXFXMaa
CxlBYR3JVytcGKwfIo1kAAzbu7DzvEs/sC8G3gJcCjMDNJWjV64jkzxQYPdd6RTjdeRWOSJL
ukj/pmmWF5zFa6E/9c657WK+Jy1rdeFGJ6Ktjgk4MRIjnaRZKBG2dWfwrfXBMbUuXWemw96S
TBq1y2PwF5rLKQqscuL3Z7EOCNQpvxUiPP29ZYky4qSDtHDT9G/C8zPQH+exMlDvs+HAtdXR
ofK4eokBIgQQAQIADAUCTV2BXAUDABJ1AAAKCRCXELibyletfEudB/4yyAX5zicpsiIIAjia
d2W8e0c1CDxlmG/r0opOeFf6Z8tjifFH9DZosR5lbxewvd8xgdzvmewxGs2e6N0IiEZOs6q/
rr5/fe4GlyLDrqxF4Ew+CJdgKkWPbDv0Tohro3lYPwAy4b7dv6/V+K02ScSuoxHwOvJIdfmG
U8BouxHLjZwQDU5Bdt/Xh7hloluQYwquDiTisVo18TI7aQAYzWusa4ucBc0ZWboti2/AUR7N
WH9wbuhuwC3KZD8tVTwwEIT6p28hZkUICgf20VhxpEUdlfwBEL1qSvGaEgJwpzaZkEfmT+u8
pukS59Gwlo2hZjTF3P5xq/JoArfymDInHnNwiQEiBBABAgAMBQJNbqjLBQMAEnUAAAoJEJcQ
uJvKV6185QIH/iOTbDh7E89U7qFKoIRSzrZAB9nb6N3SbeQOoHFyKPpFB0eiCAR/XbfDJwhn
hbQIlefoMXNK1Aoy+qXqZetFclK9HDyAGwhzRB66flCibhTm79NQyCTEvKDiJDDIUWNDQlW8
iEUmXKuxIiXUO/dX+YpWrx0bnMwQiQWpx3SICmuowh5HhvbB6Xak4uhj1B5w5jlHxTGCeDfl
sM8/8/OW+6D2Tnz5O1zqylvfj0HroydPNfjYHqGfdt1laRrGwV+TcznS81NTMTvXObiOONuB
+IUKkgqoSD/W8AeXR6W1IHFaH83gzm6Ibl0wUUbTfXqMOUQXZ0ACpyvsRaw0i/7szIyJASIE
EAECAAwFAk2AZ+MFAwASdQAACgkQlxC4m8pXrXwDwwf/R4izCXEd4483xBR6HCltIhUpBfs+
gfujAI4/8JGKyWJi4r4C9ZwofotivM2uJh+8rG9jLqeTOtNYrJGM+Ca9NRyyR42G6oX6CXrC
OrqVtIRxufmI34Yp37n8dbQM0ZEIFhZxisSaAXucF+GmHQzu/K9YF8QXfhZlzKu8e4yfmQno
2YMXnM60Tc13X0VVRUpTCIY7p2Ep+McE6jBwYlRll08hm8f9+6F8yMLs/rHw4/FDEURE67Jl
GexsaZ4e+uuaiL2WTxUpWVg8R3taO7Mv8uU4nKMtkE8GvPNwDX3l2HmzwOn/cfSt7UuZ3xmv
yxN6gZxMiXK5qL9WEsrmYKoQM4kBIgQQAQIADAUCTZIzDwUDABJ1AAAKCRCXELibyletfE6a
CADEhzbary4tsX+sfjRkLtnieztlpdbdfebSP0g5/yyutNNrqoXnXVFKjoxfzRgWg6SZCmnF
umgXw+1XKjJflakJqbLRdNQjq3FJz44C5MLk2duzrLJRxRba0yFF0Gr/JStX392y59l60gI6
uaP3u6LL9+HasQzZEcdsJZUMh/gJOCx4bcnuSnHX6u6UqilCKiEszDsJ0z4Spl5d1VvbJ3Gy
WIUfFDWXEU5DYbsqeYyQ5CSOH0DgQTTDia1gOwawfGh3FLFlRHVlZQKY2oK4J/QMKv3Y1O3E
XlWOK4RcjZZdVP3i2jURKWKr/K93m2D+2FtrMZ+iGbV2Ofrbj6CzSocyiQEiBBABAgAMBQJN
ntBlBQMAEnUAAAoJEJcQuJvKV618sqsH+wRUuysKMVPB69uApLOALAt/oSGSJ+S2UUHDv/if
0OjWfv8umCN0wfTpgP1GN9Jqni128SIenOSlS0Ia7OQZz+7ipMx2dY2AWGGgcuGNWHi7vYH8
22WCukMQOufVue5mnNbGu7i4MkZKAvTSNXlveR/U/Tt5BqC4wLpV67MWa6S/wuIMWFlwKXj3
acxnHPu9JGBKLwJ7785zhD5dNaYXlkwp3nE0uMF2PY/M4AEeYM/VoDvmCtjfS9VWI8m975bS
HsDc8/0a66A0OSqZ0K9PFh4yqIXpW2/X380RbiMi+Y3sYs4GjkXhFhwT0W/iVXTFeV+ljAKp
juIDH2PJeAJspfGJASIEEAECAAwFAk2whZ4FAwASdQAACgkQlxC4m8pXrXz0jwf/ZvDlhh+w
oRcwyR0HYWSyLfak+/9Y+bo/6N9PLxHAhcJq9el0WpGVHHU8dgDqLy8OThIA0tAF35BltJE4
mhQb5kZclmBlXOipKBWZwodGhplgSJ0ivWsCIn5zizeKCHk8Jt9kqgZW/rZfiZKCHzjLf1Uw
R2Qj9I3ezw7XaTY/gMJQ6g0U8fihsBIo4NvJNvzeV4fcfuRKETjZkV/yjEntEPLTPERyePzj
dYqc8+1jDcrZt3X4Qo7hFNipxo1E3K+YVIozqMq6v/fjmT1hd45WkJcMeSA9sOXFHD60gdNO
j0xcw9sSkIYjixljT9y/YmBJ3XBGBgIep7cp1j8WB9M2W4kBIgQQAQIADAUCTcJTTAUDABJ1
AAAKCRCXELibyletfJurB/9dNO0Ydeb3qbBNkIMr2VHW5sQ7pu8l0N+qgltNyoS+RLDt641v
H8s7mKQmitzRJ0m0dyhMCdZxT2/ch3Tci9gNCd4GGL9y3jxtGiszKN11uCnKrN4GRB8rSQ3H
On1x3Gtd3Qi7auPzikCPz/dQnAcoElycV0/ZjMY32ZF88zcfvzTPt2ak6zgcgIQRNmqqWa0f
gyewMYD1udY/8BNNqiHVlH1J9RTXyDZej9Ru/Lr0c1z+Q3KZQO5ucBCmOPg8lGQCW93K+FHK
cTcIkvHaiOXzhoAlXYFLSO1LJMZskrIrDwDnYSlFAIaFonqIygRP3xbfeXviVAUKClvAXYLv
tPCZiQEiBBABAgAMBQJN1BrWBQMAEnUAAAoJEJcQuJvKV618DxcH/2YxzGYg7OevcGU9i30M
voX9w7OKG9J4jJa7Pzwh1mfWY8Q8Jv+G1GvD5i4tcAjJ0aaJl/ojsGFjM6uZs86IQ3UoCmwW
tOxmQLENHUSHb0V1iUUfzhWv9yrJK62v/gya04R9+v/tjMG07NQv6dtXACpWDDxF6CW81LlW
WgcTHsDodwE/0O1aySysh8ReRWhbcY4St1VhfED/T+l6t4xeKJlqTys1HhckTDhSnuuoOPct
lurWEaF0gGB9t6mqlk7Xzbqc/+pGs4XtIctomvx2LqLTbj4Cs5Hcco5Yj5DPpvLl6HL5Jt94
tRvTN1xlPFykOn2CuLkl7/W8d38uxSyJJ7yJASIEEAECAAwFAk3l6hcFAwASdQAACgkQlxC4
m8pXrXwsjgf+M0CJPvwsdK/3sJ2qMivQyhxjnRO//x1kQgFwZjoJSPNooEWvwFQWZQg1f9bc
iOSCx3Vezu+0ocfKeBe5D7o6eUizhplI4cDAhqzmNggYi8gDELlfas6KOSF5zFy3Zm+s6Ce4
Ot1u9MPrStij5cTTQnCh56fyaw/hFi655uN0yhcsHmNro/KzewZtUijB3rh9enK+BdxDpuqf
519thejY4UHL266J+o4AN09xtJWHartdOFSMwAtsY68yWeStsKHhSklTP1IsFTdOdP33M5d9
5+QN+dO9ze6hOF/qA+y3pKAG0FWX7oOnL3m9KjGfjTBPbAs+bdLMBTJOWT23Q0zf8YkBIgQQ
AQIADAUCTgmEfQUDABJ1AAAKCRCXELibyletfETwB/4sY1yEzce5S1s1XRKcWt6Fs3PLUy9x
62VWuyN0lm4JVrBzF9BkRKCrL04pz7g5dWt/OnombFq977fDwJpIZuM5iyUTdrh9uBzoRG82
qDZCJzVugIeIT5u8+YS9mSOiRuUYIvJlC7S3k0X8faKOnJOij8Ky7au9uw/eke5fa3tOXA+d
tfuDM5tvNbluDlRf2swCq49NfbWbp4lcH9GMdLgJ9TWk3etMaVN98g/DJiusVPTbLxPrGXI8
g5SVm9gk9CxRNEYyoaxeqJs5588rslbQO5oSfw7Bsyvxvem7CDNEiUEvOFCy+/tc+RhnGzI9
14RP7eYeEDS9s5M0jTNW7gVQiQEiBBABAgAMBQJOG1A6BQMAEnUAAAoJEJcQuJvKV618i6wH
/33yGTvJ3n2ONHR8kIhCn75qBvIhWlli9p4MH9WIofbghf6hJe47OHh9mBCj4ADUc6dt4bBK
OyV/WnG9zSFQdSgWOUj+jaXu3tMH46F5MSavV8yFLSifMy7bblqAyk50yBjlQzwg1oXD4fFs
+y+b++9guAY8eFx7qOaotwqYKH7KJqv6g+aJW5Uf4legR/j1AaX2MnJzN4jFjlgVAHRdLf7s
h/uqaE5BY0KcgWOpYsnsO9j+oYaw9KElmzCcFCBdAcs4UqVYKzV5RooEDfQE/2AKR8EPEhL+
Is8g7tRkaAEsIqn6Nw1Rzi5DeGhB5MQxcILnN3bOFZpfhO2C9P1Vpb6JASIEEAECAAwFAk4t
GuIFAwASdQAACgkQlxC4m8pXrXyE0Af/YIjCZDb5A529ivTO/rPyJmnAVYE5PsTCdMyfa7Jo
8h0oZzIZpRZLBRc1A8rSIWpnUQoTUO4HLjIyX2uZ6Lkla2HwonfkhBqL8fzhUGJ6/HMliDzX
Tovvk+sKzeNLHsi1E2rXlJ2HsVdt6tp6cz7aAY5hZUZdYJKKK0gsNPFzkLRPGEO8UCXzN+Z+
D8FhiirEgqNY/fCy2WlB5tDEBOEo1P8IP4QDGiX7kzD3Xow9eE6AlBiVr5kz5J+5cbt7UJKN
tNq9dRYgjqj4HaXvPwB3g22LV8ZaatdipsXmNUCTAK1SxefbLzZ7m5SWS1xZa2NX48DRPVf4
MCRUjtT8G/GiNIkBIgQQAQIADAUCTj7mVwUDABJ1AAAKCRCXELibyletfLYmCACl0kuT4Ayx
OMS8qNpWuaUoVD8cOZ3U7HUwTTiOh+pSsgjn4O9dhxMBAgkZMB/W56nagmieh5QpaXXxatOb
v8QNiu+6Xv+CwAp+H56nbI3k45i858SsGiAwfAoeA45jnRqNkdm596YIPKBMT7pK4iHzKjLR
gsypc3mE0PMWtX/q6502tWr48tHzk6cBcrxs9xY1P6UAP1pMstR535Y4v7kRcYhDMvmZkxgE
xOMJgRveljCZPmHYkbdqIJN2SfPocf3dD4CFgzG3oQzOhJd6+16eAphT3wUTegGNo0ZDO1Fx
hi3qdTD0jRtsYohepckEkd93qRyoQsREhRW5rgmJ6hVtiQEiBBABAgAMBQJOULHQBQMAEnUA
AAoJEJcQuJvKV618ZREIALDIQYyKglrlnC5s36Mscz4HtYI81OfcNEtnzKtZ7XM47uXkkBxJ
a9whTxznToR5ehXOvN3B9W+HsIL0eiIjD5vrY0/9PgXyOq1LgJgfQScQn4IH8k2+Fh878ldo
PgUsfXintgkeNZwUJSqBAp+2dqEZe0CRQQn+WUlF2DPnobnWvCYKAu74bBPk+J1HVQ6wauWC
fR77xG/g1ii6sonuWDauS2Y11rDe/2ZeU06gp594j9dwl3tGwveBFLFiBsnVTaOtYxJNZO2W
XyVF2/2j3FdrXQC4dpmm4glVFj+dg56Y2U6DF6jxa1ICBhW7UQENyAj0/UvkE9XT04wn+Weq
wDaJASIEEAECAAwFAk5ifQsFAwASdQAACgkQlxC4m8pXrXwJkwf+KXQ0Yir1GD+X8Ibzumog
gNNqwc/ey9qKCL4K24eaCajB6qSDGsIaN24pjpmkDMhk5+rOe1iugjmBuGduRlsCbJiQApCO
ewkUTtZHnXMdWKCXyBcMFSK20ZAY28MKJ8WtR2QPb9nnv+9e8+1qro8ZcP/le4Ixqy+VyDQG
RRERk4KjqbIEUlwR5DfFUQabwfZg2TLLfCBUHss8EtbtGeNLEXJeL7vne6SLP0DS/utFgPqz
gVDxv1u11Ri7A5pH/qJKJTq65EGOyAjoRfo8XTfETDhkBGUOf9/tyzR54/8XtmALOVdJ5pDY
FPIp4E9Ae2FsVZTdDK9BzOvTBg94uqJGJ4kBIgQQAQIADAUCTnOhOgUDABJ1AAAKCRCXELib
yletfKxoCACFaRUr1BYE0n+dOmvzNE7JkuY1N0UTtXsUMoASiZuxBWlxAlWbeGTZDn8M7iu0
/d5AtpUj9N9pqkpsVWa7kZMR5HIfm/2YtLj3QvBxSVLsRtL0AYLWVjsaKBUB+4qPAUfIWTKZ
lKNDC2nwSnrtQHKufUEH3Zrxbw6eg9IxGGd7nLl2e9NQDJ64T8V1QK0bPXmW06qxeThV5T0J
ftFYMnPflNA5zepoq9HSb84exfxN8lDR9Oyp9OTjuhUyMC1NvDBrWkDyOPCS+AXDGVtMZqgo
uswY8d2ovaFM5CDgwIoVAGVYGJ3Bc8jBlhWFXHgarzWpLOOhqY4+m3hmbH2pujguiQEiBBAB
AgAMBQJOkfPEBQMAEnUAAAoJEJcQuJvKV618hLgH/37mvEkI8zMPNusC3JgfETYZf0zhTyxD
9deCRt799nta0jefWhEnKlDij5xkvse9ycLvFUFAkLD7JqafKhNvS44w//8yppXsjbEszGzV
3Uw4H8V7IxWuVUIvPhLbg3c3MGhyHRmF6fjOch7wO1fel68uO+LijDf32aGd5z5oMJMwfa/6
EWPH5RiYJ2a6ZKPvYRjzzuiyHq6tyzCZ7EEinHNPMqGM5MONn4alkQl4ZL1FUwFbBNi9ea8w
9muOWYA4YCg1LuCPCJ95PXchXNbKSZawFLKq44/znSHXvlJ15eVGM0Yq/Rn0nj+iuzGCYKF/
YHAtiRofW9zxBQPYiACd3yaJASIEEAECAAwFAk6jwHIFAwASdQAACgkQlxC4m8pXrXyCrwf8
DSUg1s8wFvdOOpc7E2ZJwUOwH3LcoXjhXusMhp1A6B7PDsKnsHVPl/MuQobiT7ej0+c9Ezlx
irj5ak8lnpVUH+6DLHcF25XItUPF0MmTqZmYpJOkcrunTvdpclogEK4S7DfjOZ1vAxvk4fQ4
7ayGC1x3bTJX/+L9OM594AgteDQKq1MRkIk00bGBDBqS11vfgOOCObMCK8c7jABzvrDxIlO0
0MTVDQjajN62TY8VPqJqg4K/B7hNR2qilxex3eED0TL8DtY7/2ES259lW7ULvVukm4NoM4Ao
rKShor9lJuqCzzfVe7R6BSDxnrgFA6G6lH8DvNzcRI4knHglkX5Se4kBIgQQAQIADAUCTrWK
/wUDABJ1AAAKCRCXELibyletfMymB/43AMAWeFdxuc0PbfnoZcT0LYaje/0T0p7vHQnfKJ8G
sDPSyN/rcaemECoSo4CObHr0PRp4GkIkgoBg+d75Q/0yjUHQhU7DEgnk7ZsdV0VGRXBxb7/e
fXb/i+R9yiaJgvEOB0Ofn8o/d/TFzw6LSyV0a3Eq+/MJOZGL8a7VMXxACoAfc0UBhqhtjzAq
JcxAa8+96/iyYE0+DLXmLYZh+AyBqcLFkk23HgNSGR3IjK/nqn69dB64lhTbeZM/z5coR8FG
Bi/lSdzyyb5albeLMngfSuCLK1oDft/moS43D7GsgM9/5uzEgwH7BiOrRtPEE8QdSeg2NTyq
r41Bf407HygSiQEiBBABAgAMBQJOxr6gBQMAEnUAAAoJEJcQuJvKV618aWYH/j4vwTfCYUO8
VsQJcKVJMjjMmnM1AzWnUkXMMyhidd71k5CJN3o23foXHFtyjj2XhkRTER9JocGXofHJ0tX8
2B2vVaZTNqz3vfMvMXwTC/yIAaZGAXG08MCiWfi057xRiqfq6GDwrmYhaFCAt3YJ9hCKcgY0
14mAyTCFagNjqYtOAAb/Z0bbLJfjoBnGh9zWh+7ZrnGXs+qDTdM+ahdZq48BngtRy7umZysX
kkLuX2crwMcWL4MjrqzziLXngagCa5w4ostyWSF6I/08I7fgE8X2hk/r0xj+9i3UsAzXEsM1
Y6GgPpJHnnwYZacDe802GptNBT//xsgZwI8H8Nam5AqJASIEEAECAAwFAk77eqgFAwASdQAA
CgkQlxC4m8pXrXy6dAf8DFrpatqvfvmk3e+bpUDDuQr6SI4XsRZFZT7WgqkSixzhMX6zQpjg
A0UlXggE2JKw54jHOAhJSOP0gTfCj4yG6nIK0/GqhGt22sJELFfFcL+CE/X9RxuDUxwfA6wS
RZqT/4NreZIfC9q13I4SrSmK3/pOH4FIzAfhBiH2hjzBEYEFG+9NW68IpjkiiG7+fSW96E9A
wF7oI19rFSKtq1PYu5BQRgrEK6nA0kI4yK+dK2t8OWCarWwFAUr8LzVYEv7IdwSBUl51v2Ah
uQLMFH94Jpj+KlQiXfvyUCOgD7dJDG+d8s0I/NPYEdrkTHwc29dhhFzRvllBeyDCxVLnTEgH
UIkBIgQQAQIADAUCTw1IlwUDABJ1AAAKCRCXELibyletfBM2CACIaZsC8vFW+u7XydxU/nsY
zQZvMgvMvrDQWTgGM+y1x2/j1z9ubq+zZEK/VMHKdwkfyn/MYXby/WOZntqNeKCeshZrgsuG
ndtuBaDAd5HPtzU+EQj5T6/HHPNB+SqjUZmdH1M+sD7qPZMu/AWu48bpZ8k0Iy6iKJqvgvfV
KdBlkNLB9Pvq8HzZe9iIUBx2sKydFlov2IRx5ogUXThMcWepRY/hwhCPPxV7JbYwuCiRz1sf
ReiD+Ebt5o/p9mT8O7pw2gjTbVTSI2JIfDnJNICdGR9dq/zaFksUNXGcGIQEB9HCeTprXNzt
/UVgk5a/iaBtB9JLZR2iDypNmObBb1hJiQEiBBABAgAMBQJPHw+3BQMAEnUAAAoJEJcQuJvK
V618HVMH/i06h6nFOchdQIZGbRsQtoDBAyrs/SPRhd7PhOzxlaSpWibHFsqZ7RSnM4Wb0SKT
BH/k7NqSrwx6P3va+27wC1T99JCSC5+yrLRihohdMLXgx/OzU+T8pWFEQvye2fs5c0NfMTRm
ls9AUzJVqXV1XvzYCty94FiQjwrZephM8/IBD7RUtmXrgtDSPw3s5Jlkep5EabQ8YwhrlQP2
/mnKDkQ9O/XxVwa/Gejsv9eXe1bEUNdisv6ez5bCnRi+lr8mkUWPwYx3ad+GBbzPNaTRm7uK
G6Af+r4kNSPOt58HPrVRh7WUV6FYnrQbUhAj35ORT1M+0d9lqWKJgnlYsDWdUQCJASIEEAEC
AAwFAk8wOTQFAwASdQAACgkQlxC4m8pXrXxbmgf+PeqNIQi/WRzdxf2qxaVWzU55YGb+AsV6
a+mkh19MFsrGJw3VW8gb6v1x7OgNHVvc8uRW+BpvdJ8QXs9MoJu8SuISi62HQt/FbBgfZ+Yy
Wcfx1KLGPhAWEhneptbonXRNQx325lopoPKiIOSFxE7h1OMqSuBwi45pHUEewYX6aD+SqwPq
zLP8tVb3wYLpNbPSqdXosjn8N+lHSVgSkRqfXnOwatx11MpsvqMqRe3smdTtldamwMZyB/WL
WGRoZDygtx1wgwVl2a8SPRxAaSQlhYMjFaps5xq5Xw2ovpQItWsxnHnq9L3jG1sOua3hfeOh
zKeGD2U2vCpOsYIWn+xrG4kBIgQQAQIADAUCT0IA2gUDABJ1AAAKCRCXELibyletfPXRB/0Y
kyuwWpX5SqP3csdias5hGReKt4iqbdNqEaZ2xuWSZYQ3OX7z5m57jUhSa9xWQfpkyojuGgfW
2jNE0TgDcf33DZpDyBfekTpAeH8JQTRh+KSJDN03jEHLN1UQ0oss1N6t5dPtgs9duiiZeEHH
S8rLhnb9TCpHSaob8sq3VofyL0MtaToSWQVJ9oD17xEfJEhUWNzhXxmM8PtG57P59ih5x/sE
UaIHqsxk7moPI3vWKq0ROMKSB28syXYP5+U4cr222GMfaknBi/+SrFxls1QJ4oVaI+dzuWW8
3mc5rdnSF0kY6lX9q+4j74jjrppvXBToUwEmvy2pbaT/JpyJDR2xiQEiBBABAgAMBQJPUyYp
BQMAEnUAAAoJEJcQuJvKV618UmEIAKGgh+2/p+eSEnyev+VFBbMvzjEaJaYzwemhvsWeRIIR
oV7th22uGPXOW3XHEtbG8Vm8x6viTx250O81E5gNVQQKzOkNkvrGkTT0/2h93ubeP5E2Cdij
BG/mWB2GxgmhXGpKTr7hzFHGevgot+TSqxAgV2b1y4AdCsMTZON6uE1XD8+NCi4jGkOtguk5
aVJjhv2sRufxXWHfxbMX5rxLQYk8PKaKX4+xvArHUNX2hBjDqzx3DTjaFUMx2VMAWBq4MlYO
lHA8LLRDRsJIzSh1B9OjDSgqt1hTaoE0ePZiwjO6EsGSfGTuAzroFx5wedbDxGNUCY3KnQNj
QRUZpYY3GF2JASIEEAECAAwFAk9fRmoFAwASdQAACgkQlxC4m8pXrXxYmwgAqqacdN/idIJi
lLwfcdIV8yqQX99ltfDCHZHX0JtF4zDJ/2z7htmsvn8BygT5fttvqQDrsd+Cp/owuIpjMqYP
xEFHTX17E1eBVCRVUqwEhGx38gERbUX/QkFdJkFfmTVVnaUu2yDWAEwRAxLMXaElBnQi7wbj
RphdfDsPM1TywVyGFw5HdUn64JZ3OYqH3z/T8FI0xS5nhzogwHJuea+NVfAXgeeTMALc1LMT
5FTELhe9XQFkwrPkR8t6IvtM+K6pELynA0hio0dTotZDMD8CZa36ugTkIaP00rn+NRHmcoyH
GITgOUcXCXlHpS6sOpS+OadSHeaxeU/WWT1+jF7KcYkBIgQQAQIADAUCT3DDFwUDABJ1AAAK
CRCXELibyletfGXQB/4/UNd/GkZqOIajt5O0kvf8swM29FEsZKhOrgvSqgl+yy+lP2w6DAUr
bu/Eu4WBXLF0GzBuBn7InFogZWL3nT8vN1l63pEukzqH3QlhKHQDrpvAmKXJFKkrhoQN9PBq
6/gB3uODCjYb6xaQRFxYsQyQiWsyebWpvWpBDS5fwl5l3N4WtXVBShIik68t4gkabN29YbBI
Ls0jZvx4ERjVHZaV9QPOn+w+hNuhQzHo4kLVv6mMXlh3qAZwEM879hWSYmrQTZpWH4qXS0+b
RVH/Thts7euIRceVOo5AZ6rEvHk5iBaMTcfrDVd66BV37VyGZ1eFi5jkQQCISG5DaKLClXRo
iQEiBBABAgAMBQJPgo4xBQMAEnUAAAoJEJcQuJvKV618gngH/jA8W6iyxqNW0GN/ghI9k2/5
WP9UAbkp0PtFzHmh0H+ZAjYBleYUWZb29IfEwIM4sWUUHOMVcA3WrJrZ3okSaRWjS5sTDJoY
sgVyHuloZSXDZKnROY2YQbv4noTh3GEoPzuJTDkQakoavJ0u8uOJNWrA3xatuZ/xKUbZsDG5
siidfB9VrulzzUW17BFmIPIcw1A+sHne3Y5w1BSf+JYRG71h+C2io4eMYlD2J1eJv5b69W9/
erFtlIgxgJISEnByrAS+LIuVj6q1lmVXNuO0XWIPB6ZJ3a0EKJrKSRCiaxvwXy6b5P2KHgod
+kQ5nIVGUof3SQEdkGLJ1CXzbRiKFpGJASIEEAECAAwFAk+Tsk4FAwASdQAACgkQlxC4m8pX
rXzJvwf+K1OP7xSI/mLITy3UNncqQlmaYqAwYagShQ9GflD/wIYlJ/PD57dRZ1UkMv36VDV1
4TJEjDXYdO6NuIjM4NYFDT9btlfbSid3oM2HGKLrLUhkEtZJRYyfDA+A9/RWXbSY1rVekfrv
wRRdIxdeyOi3VDAlVcbKFw7PJSN4xbCb55kRhQc0KeJNb80V/VkLgxPaT7C5naGXQfCFWkST
jmyHJ9JU4xXDQHhRFrQfqIhZ4pNBUSN6eougccpw0T8ZUlPuUQVjHLMPC4rlIFXA/LkbOQXU
zy/gwcEBUCNOL3p4rzJr1Qe98GoWjd0U6mKgfQ/7wI4cJvCy/kqCptaPDpnOkYkBIgQQAQIA
DAUCT6V+MAUDABJ1AAAKCRCXELibyletfFc2CACGtYZjLd/FtX1S7ZGOqW06Wzm4iEeVwdhm
eKyMxuNCHQhBGKk4/CptgC/z69/76Vt8raEYhqOrhk2HgLtcC84UeejdhVEJJFuSFHuVuqsm
aV31+lk3cGqSxUfyAr52/vkv0moOL3dKDY2r6fwmsbIIzNWCxn5OKTgqIXxCE9FSPrOssUHD
+rDWVs9NOBSW7QHGRrbXY/Fk7/qUXnBCR0a3Tp5xh2QJQhMiv2xGi5GVZSzfIJCopS94+VV1
yAZ8ta+y00h22xvA/OCCUPgw0DzALMsmbhr0VRjPJnJlXl04u/ttkyWn7eVKCzOMpelbWgVi
9JjTKB1frGs1YAlCd9CxiQEiBBABAgAMBQJPt0yVBQMAEnUAAAoJEJcQuJvKV618+3sH/iLX
nSAvOLztBschaPwbpbH6X9eq6WQ/1mccbRMkUjATKQVIlaSb1Q9kgXQleRVNi7yNZlSZmBLo
i4+DsRxQEI3w9dHuklwCdIfJ6Ws28govv9V7HVGsj5MBxO07zXywxl0TOiFN4v4DIsatQrJy
H9AZ6riHcMscgM4+mXcLuRM1UYvJWiKAFSxioKHjkaPjMRX5l3eWnoZvnGtYrne3MHuS4jo0
9pszL0PbaAFQ3vs2wxtkFchRFxN+eMiigaTUL0QknUtEFDHh+qlN3gTjD99uShohiS1li1DK
0iBXrEX8Qkv/VmXM/slf3LEw6Py6jd6LhHnUCTPqnYuqB+U4aj2JASIEEAECAAwFAk/JGAsF
AwASdQAACgkQlxC4m8pXrXwU/QgAo71jotsPBE3Aojierpa714ww13HFCtuRu1lKvo/zfTus
pOEb9V+1Cq9s9I+E7gsUJQUpJKoY2pEOzs5HYEC32FfJKp9D1Qqa8YIxL28Oz56TC5Gl86Is
TX2MXIQvVvbXU4Va+vhWqhzFpUEAq40r/rODPG61pmx2A+faCjrJhIZMCxjLrKEx2cnjt6Fk
kvQRUFFIZY12t0Lu28B+4aEHAFQ65OWPOiVwcVH+xcGMY11I36oowd3kwGrXHeyjHdxme8vl
YjWZGbnGgnQnFJhEraKsxkUHmezvP8FepNAJUu15qa3LLQBYwJy2A40M4j3Qdy2p3jdX3pKu
lyx96SojaIkBIgQQAQIADAUCT9ricwUDABJ1AAAKCRCXELibyletfGz0B/9TlZnKX/LF5gWj
cJUG1fDATBV7zbgCPLbZTY61bcx5kKG7AqIY0H8X5gHIkcDPmswGXP/E8JrxrRUEqSnu3q73
H9N1DNZ6vn69MdMf2NHL+h8lz4lx+qin6TN2TYSGslE404CLI3FkYd3ckigIwzpOV+Sdjgi7
BjVdUHEFfhE0rz3kBwd25QW2w1wLx3eEr0SZnmIfA3iSmbVH+G0/IRuciXEYxhmiaSzqY4Ob
MzCpaZjeoR+chVReU/RiT6pg6xOhxjSwK9nccqYjwZ1kpxhTdl3Os11UNaVF+WKTcasiarZL
EiKfGvO8fGLnnFR+e3DgqmdmilOTvX46xpZgfoFEiQEiBBABAgAMBQJP7KuLBQMAEnUAAAoJ
EJcQuJvKV618GDUH/3efOvXhQB/gt1tH/1yVzcAyigPW07hCnN9CIv0Bfb584TTpXBiWN5mD
zjP9Ca8SOwGaVA4E8gRsf6Nb8b28NrL4Lw1qtWl5PJXTzXDfJ8QqHHmT83PuE34wcr5sN+sE
aent+GovvA/5uDAvLb2+cDZ6wNwRO6BzJKU73rEo/7pyWA0V47gDHFrI7Vk+tDDdiOjQeSFO
1CU5pY8AlMe36NGLhh+mTjN3NTLxxX1bAzxeaPABfCcmezJ7cABu+cmlQ7y+twYB3P1kBZLU
UtKabOCYgL2GqPmPAhnDAaKiHJn+6eoqUZPYLZyCb4N2ZCthwfLKf6xmJ6AZVQKAl0foJ9OJ
ASIEEAECAAwFAk/91BcFAwASdQAACgkQlxC4m8pXrXx85AgAhX8L9z8oXWq/PFQl3UmsXqKV
3C9G/pEzWfLXXKNHkSeF+0vflDYcDCpiCvttXsnjdffL+3z71PFv0DxSEvqubtEV66sNecWh
UfRVE/xMDFTOTnOM2WmW4bCraSZlpSKGYZBM7P36hpUnfD/2MfAMro8KOMIcSjf7sj0BX021
OwbC4YKkw/uorxH1ExYxPWWdnfYyiH7LtrCb8NyELQ2Evx5MlIRyZ59+lnBFtFwijZBKBY9U
ILE1d/YMOmcuJEJ0j2D94wds+cCOWHImZUuQFXaovCMtEFfCjSbR5mzO2H4Y+/T28NLtFjei
TSwULOdaIwmmC9jK85lgOP14nzds94kBIgQQAQIADAUCUA+iZwUDABJ1AAAKCRCXELibylet
fAUhB/wNwzVde6Np3eUSXNzs0hO+BgQR3U9pQ5OouOK3n/bwam4H+XxtFKM8QGPcDDwoSLrR
r7CjAyVjj2CujXapTmfAMPSbp1nNJo69erY/bhAWpdya62s9bNjwp2AOndQEUoq8WPJ1fcs0
vQ6GWZTeX9xC+OnIG3Y/cQNBlymKdcLxLSyn+78w/YfJw1KWTHBAEEI1rZYCyWIktgozoNda
KHAwtLOudDJEUysGotSnR9t4mgZQbKZwQVOpF/4MN2+GmMazbu7SSrOj6j0VBYtvIaUuwZAc
UzRqZ2CU0YEb8EY03o5UmeHHCjmMCu3whx6Mk2VrYTwpRN7Q1v3/x1T1Q5IFiQEiBBABAgAM
BQJSeAU3BQMAEnUAAAoJEJcQuJvKV618wc0IAIxGpxdRnvZHGnkiRKw2rGThY+WcrtVVcbPS
zoyd9opLWFOBD78Zk+Y8vDILcd6BtHUja5mEqRwqJNKpKJHkFyvi/c1J2IHRCy+kQqSOluWK
qC8o2Ig7kxkM4ivmlW767ZPjvjwyTmYMg4WEly4xLeDhg9Fmq4+saAyvE9Wsu5TDGbZnXGV6
rzVqieqZWd//iUIWy5ybpocVXSkI4j7FQMHwfGqH2PRRDoVKFLvlZNHahfPDN4/lWAfGjvQR
tvsZ/nKduGdv04AatdVFuGa/jkgwEdYySqFguHj8OhFUZfyMJmYYuwL/CG4iwDG5PBB3frt+
5ZDbzuC7zM7SkUOGt+2JASIEEAECAAwFAlKJ0kMFAwASdQAACgkQlxC4m8pXrXzHOAf+JPBj
W3eocLVHRC7RRw+ywNszrv7+HMKpTmMs18GD/gEnl138wdzgIql0qN7zSk9UXRWevh8mQ2tj
SLq1CjCOLgV3Xmlpsv7mF4TOigYZajD4Z+jrgGCoExtqB4CuomiZec18/wrFWHEdMGWU4rTK
cZkkpOyc95dD/cZq3y13H+5cPBoPpvxOpdf5qOIR5AnKd4zZ6RTNgqr+TnR3bFbQ0uKvcuSX
gQfc3Bi754RpdEfhejtFkCUDMsniWMD2llHy7dTB2L3S1urQOLzhZJ46248hHdaCeZCrWw+w
0G0Ko0cRCu5cplPreGWN4mRSaaREVmNQZgFRbJ4jdLixjWmQK4kBIgQQAQIADAUCVFyGiAUD
ABJ1AAAKCRCXELibyletfIuPCAC35NI9v6YT9SSluzpRDQ5LXHOLMtv200jFNu8MjU4aHhFS
RNy4yvZvOQD2qOuvu3dcWm9as2ALJzpQFTMW82cwMJnmGYcxuaYB8uZgGO53icoJ3EzfXpvR
ZUQa7d1LJs+VxT0iN0GMHntHY3kSoMhefh41ndSf1cAh/V+rlHlaZAcukg/riWzWxbR7V8p8
pcm+E2bmP+GBHCeOvBK9S4lUpFSS3+5AMpJLtZ/KBkyIQQGljUTLxmZzhS8yQIA1Ct2o5HAN
by2hUVTViTcwtrRH3Tx44/kuaZrGAKK3+EnTNERW9gx1phbLHI/yDNxEPggxGXRIRlogyBOK
QDxgeZrViQEiBBABAgAMBQJVKXMMBQMAEnUAAAoJEJcQuJvKV618HTAIAInqyWUET/QPI3iQ
a1FIV5vvAL+DtCtbwbvhwiPndj28P02iUJAv4X+6LpRzVe6Y/5rCWHwkTU1+H8uiPIDDu0Oh
Jlz1SomQdUmOn1cTiqdvdN/4YRHLY3bt8jkI43RSaGWLWLtsR/VVvUwaLrxWa9wDBHYMlEwz
4wcumJpQh1mdV7d0XmbcsYqD8kjJ7TN9n0sTc6U2333eI6Tn8Fm0ftu8Vr2gZRZpOdnTuWtR
FtCPaJNY53L27fDFgRxC61NzE8EQhCz6IrrENu/xs+otv8vAT1sbfmac70naVy7eQvF+9shi
RZxZQeudeZkld69YibrvMPW00+HfAkLR04g8DEGJASIEEAECAAwFAlYJmN8FAwASdQAACgkQ
lxC4m8pXrXxDMAgAokCa9kYlxg5YE//dn97P+u7/TkNj8h42TM7qqRM7+PPvKbtv1ecBXFyj
TkVBDskfEmQsmsBvRsH7kHT6cBxCnd1jInU5ZTVLZ3mVgjS7stQf+sH3L6Qep7rrF+SWlXfI
xgebKrgFdaCuAvwKWT/vtMkg5F90LorVb/c0D4JtXNCzhz9QNW1CHa/4vQgMozqjBcXih4g6
Z8x63/bUtqXR9dOSyhwMZAj6uG+SoyM5Gr7eVjPDQ1G0uzB/SMLRVeVnhkFMWPToqx+5/LTb
ZiHfg6l62ubJro9VgIErz6cfMiCnHgKrh5+oTbdR0293pFrrwOp1A9Nl75caDS8Pa1oWookB
IgQQAQIADAUCVi0sgwUDABJ1AAAKCRCXELibyletfIi2B/4goSDwttSDbWU3YfSFX9dkW4Ue
BJUdST36pXerAwzRk3vYhz2dDMv638CKFw/fpOaHa8YEh3AHiNjTQL46w63vaDzTzivczxwX
gEaYl31d5/Wtoqjr8C2Uas6zyhFqH2DPbc6+bYt7/KgayVAZw+JKJLhNfHxpWg7TUCVd7xIe
MtJ7t5gILsc3OKT3JSBlr5fpL+EF4rqqv49gmPwKy4N8mk5zjnGGpbp7iFunqkQJ0WyDGH+A
mdWyLk/TlkG1i6W439WpLfCbDFrTHe0otb9DstY4G2Sz4TGjtB5aPXyJzlavguOOeVbYZqyh
DlIu+i6UKlVoTiCLRmM+H5KEKJ+KiQEiBBABAgAMBQJWkhVfBQMAEnUAAAoJEJcQuJvKV618
GWYH/AqTqTOf3RHB+2uHL2bDEfqxq/Wnn5c9DnVC4RmNZdoe/uY7jquRaD1aJ6skOk6tJ9um
EwmUheymyGy2URmd4i+ZHTiOxYFCN1HAssxaTNRscwmeIWRJxjrSmmF1aZOwi2GmmzqqQkNw
VyN7eudsM6VdTrxD9nmcKl8WywdOmGIsUg7/FKTDnuECWwH48PPLHfOppXmRwnxfvN/8vmdB
0kE/jr3p0rqiLzAtDU9J21svpiPOuGiN3BFETK51rZaveh7/zKZxU6CspbnJdQzhrdWr67Fx
QjzWD8QzeZbBoQSEiNsLGUWDpPxg/pRQCaTBpdnEnU0ngenIg29XC2VeDe+JASIEEAECAAwF
AlajOhQFAwASdQAACgkQlxC4m8pXrXzV9gf/Yrg/PQA7buY779NhdpUjK4/FSbNiSuXGDeDL
dSm0fj5lUC/6rgDSiDopj2VT2PhaydVJDp7NeIN11RN+/Jg4g1tsh7fhCYSgyjvU74DjT8Kh
HwQA2NBnldxAwuwe8z9VqMz3FlFLTo6+B67YzOuBVNHjFSKDxkGqpl4m2nM9tqioEmNQV2QQ
WyUxgykCeUx92Qitz6plbPL5boyh/swqRp2lRsBoQYp11gS2jzX+ueNpWbaW7ja4+7zONQEJ
Zb6xCLJgWbQng4JyxFzuc0S0yBYueVnUSmUAi3wEXcHiRJsW+ehgUOzDmun4QqkLbLgHGdbY
1abtfPFO2sf2m+fIAIkBIgQQAQIADAUCVsbTyQUDABJ1AAAKCRCXELibyletfJrEB/0S0Ovi
+YHf8cZ8TYKp2UXsJFKo9idOxnON4UD6/bIsuGEjSqzFQD+kYtthkbNAOrydUkWz5zG8JDqd
BMEAGo8jw9cAF3t+dm7ve8FhOH0cdTi3I8UOHxvTvN4KWaIflzYFrtzqxQR/zUkOVLq/N+Y7
iyAObTIhd1kI57sV1ofeWj8oeQ89mfowHdICtwm9OyuKg6yL/2DFMmm54bGysP3efXZTYdxD
HPmr0I+W5wU4d2oP00Cypl8FITyVnghsk297tMBqbFJzIoKLxjccTFcrKW/rMEXFRRITgFFO
gnHYZCmJrY1PBGrRGX7vqugYUFjcP+r//5FTF2N0VH32zXcGiQEiBBABAgAMBQJW2J4IBQMA
EnUAAAoJEJcQuJvKV618YeQIAMEZnLdm48S93mdoCQuP3FWrMjiQK3laxHrDzWIU0La/E2PY
i3oim0m4khCXRE8p6eHjAjm4ORG5HkcahVbNWkg4WQOUZcz0izh6TgTR5FDWgZMQjWTs7rGE
I/gOD+VUJs7byY8SLtW/p6baPJqs8qn10Y+sRyC/jlyUT5kzHRMwdnAh8PIegXqAYktdblSO
2+bbmyqqdVpf7iVmvQh4Ihr2UGiv76n+ALONjXQtdGnscZ0ARO4Gd17g6hIYn1bwRs/zxFLW
d7D4OuXBre6mHObUQ4FPE2C+t9YWrXfx4t569cbwaK8RakEnHAk34FpRld6xPDtoavGtmK8e
B/AhR5mJASIEEAECAAwFAlb7f7wFAwASdQAACgkQlxC4m8pXrXzJwggAwAv7wb7OHvbw2f7M
isoTeO7wyu3VjasQyNE4w/KsIu2KFmxPTQsQ6X5q5LWnlsG3ohkgbj0M91yaQX+eWkxfc6Vr
GKIyr5x4nJZrws2qcukTZ7wrEIJ/wRLiJgvlJsZh5RzJWfhF3WZ75uEcDAWCVyfppi/BUvJI
rgCj1s/uUY2e4fWtA//1jj5ifNCEOo2Tgzid4FvNDXW8l6zvQSuN6oDbj9s6SZ3f30BgxjTB
O1RRlm7VDHvVThiYfFrfLzMW53iEUpNjERrOK/g2dAPOBhdBRgkVuUOtAv1oEnjPurB/n6ZD
U2kQkQPr4/dAWTQrOgSo23jQ9KLJuhkZ4/oH0okBIgQQAQIADAUCVw1MyQUDABJ1AAAKCRCX
ELibyletfGi1CADEnwTHTRvA9DvIa/LxaPxODXFST0PbvP3+V7JMHQwmdkf4LZWkp6J/lUUk
RoE2CwTK+rKKaWzUsmkE86S3njg2oJCW05uXQsT6vtsXnxznGIHiqshCd9Wx9ThZH7m1Y4rZ
wh95n0lblANIlOE4CK3rLiywKvhDuso4uZ29+I+JuKfTH7UckOzI5mfTQ6XfAIxQ10m49aqb
ech13ezb3Lpm1LnAQ6emSZyk+x2S9nSabH0zsHJLd1xouFI/j5BwTioogu3jlt0gXq0ez5AH
r9IaNKrt9iVsjwRnXSd5oedXf+MDD5NS8O6n4CcFFjPTFK3Y0hGlTIIM2RBR+erUG7WEiQEi
BBABAgAMBQJXHxlVBQMAEnUAAAoJEJcQuJvKV618lq8H/A6pyj97VlDOvih0uxNjclBqTfwO
LefgxD9dbJY8fJ+/U9YaPqKijNWFpiCM2rNSjXYksySg2ROQW7Y8kSUVlPmx0lcx9z/5wRS1
IDJNmGImnXL3LX5d30af00pErT36bFWDbwkfcgrxrE9QVbYZrClaiK4lIfePgbyfntRUbbTM
4bmGuVJK1PimAIbMRph9nXXRrlNjn+S6EOeDFUdfgi5b4tvcHioALCz79/YyP1/uvJlf0gSj
1onWsDbKX601b+mfBzHRclJ2W1LINUrLliZB36Jn11coWycU0jp13YiLjPbgyrIAOeijpwhK
rnv6fpWNvrK6zOPB2Dqxth5JN9aJASIEEAECAAwFAlc8LikFAwASdQAACgkQlxC4m8pXrXyo
Pgf9EQxpyRaUaOraFDon9gih/lchz2AQjHZwj+bG26ELMfLsIKKsW8MXQSEU99PSmoVcYOVa
MB4tvU6QsT3jh1pj27F9vWC+UMaDsyrT9Y3gJ9b53gtcSv61tbGkDE3o4mIlt/HQaXw0s2ay
K2RLxC8kLBIFiPwZix8t6P8Bh6V2k2LMvjLBbNFaIrjlDJO7XHEKF71GAXaF1Ckek9okJ2cV
aEcFGlH2/YV8vMoxmTYsl+Bye41OcrrjMLYw2S8ZPgYRmGauVfW4wax5lHcT7q9kr1fmnELp
c85iraJLqjpcMsnmKvq7X/NtDt3tmxPBLC5gImdo6+lIm64s7c4kGH2+h4kBIgQQAQIADAUC
V019SQUDABJ1AAAKCRCXELibyletfFUWB/0QYAJgmu/fYTPb5LV4wUDmu3U37+OrYei7x8NC
hXAo6K9wmiKdx/UIUTvh6dnIIScEp6DQQI6rQS6rQ7OTkPL0Mtun9S6OpGG2+b7jsCrRnmTa
NMieIEoFpqkWbyyLlCl6mxn+Nq41hi3uM2dcP63ujtjp3YmWV76C0cD2gkAogBFXo64deMGw
m6t6AF9vyNY42Jcx1gP8iXufZVIfZR5O6MnuJEpH437nG55FEOm06fm06hmaqiMHw0Y6dWVm
ATMKkE0QzPW/0bMyzp1pq+J68fsOrkuIoBXqi2SM2pAuk7mtyV4+UZktRhF7UkgK2HD6Gz3L
8ZPgNwWzIamTmzjqiQEiBBABAgAMBQJXXqDxBQMAEnUAAAoJEJcQuJvKV618kFEH/AuKtgxV
Z/u+pU6W5uHqSWg/dlzN9cZosgc/6UDV6KT9NCx9u3kzr8aWady6jtNLOGvc63V3Mo4nAzYH
T1NUE4goo91ximoHXu8ox3FioaJG0OCbSJZxdWZZgLOASuQ38zohLv4godRQ7qbwwR+PrE5K
qembtNUCCc13JJ3m7pqq2VQ4qZgrhT4mR27YTRN7tSUrjXmglS6MM0tpZSFZYX35pqHlQwRx
x8fqueE+Av2dtpu6WQKs0j4bWzk9Z2scKbptsVgSVugffoyAkeyUg0jkWIZJpt5iifmK2ws7
AXUz/036s+KUYHmEbxPxX/9nM64Kyi9VKwUxDzsKUxd5i4eJASIEEAECAAwFAle2TicFAwAS
dQAACgkQlxC4m8pXrXzujQf/dh0P3VRafKB9nCLqGyiFJP8xaVwcB9KOOTOvprB1vHwnYj3p
JZAttul/nBhhcEw+OZ4qLiVCXVqCxkkqg2C/z4m/U1PW/pfR35mmd46FJQO4xPZFWmJLrStb
50FWhPRYwo1pe13L/KMrBV8HcwEnLKAdUq0h5MFTM/hUybwPzyV6d+PzqatB3W5Tijicb5Bo
JB6pO1MOkMkYLKE04BuyELOzNuGsqXJSQufgqI6K7lPCxMzxTgNT4z3HmB7pB0+eBtG4lSFS
hmAWUTJJw9+U2pfhCFMI9hCyBmmTLKoxYxnMD/6LWsd3pwSdDqY9LIaHZAUzTEUVuUZ0i4mi
p94m44kBIgQQAQIADAUCV9k8jgUDABJ1AAAKCRCXELibyletfB1pB/4vgQMVHKNXVxUkoirU
y7gtKLsAmtKwAsz9sFuVEBOK/I1X7uqGPaicbdSmYmXewq6Rt8qocwola8XGVYA1/ab9zdue
Pm/zeGir6b+jxt3DQUplxvgG/sWIVUblLLa0PqPctRi1txqQNm6pmUFH/pLSdX8X06E91cuO
/SFM5lmgUxHUCrIq0ELNJDZX+CvsRGCWlXVMVc/ToY/VZ5LT7mZLSQYI19o5k1gLgdL83f6X
LuQ2+bcVxFct/LTTroiu79fsVFS6FsGzHjZ40nt1tJBGc2M7SHcNjv24LgRPg8ZWN3bUVqE9
TZV0qlEmwV8pOPglQ13jwvq/RvJoAA8cYAvUiQEiBBABAgAMBQJX/Cx6BQMAEnUAAAoJEJcQ
uJvKV618mcAIAIDNaal1nG4csxVgyjIxdkv4ScaQyuH99xGimCShmxGH9L6CfwyqB+pJP4N/
hr3jU1iaDEOqdN8Tthmppmd/HqRtV4oOc93urRmejxqajuWGeLy/uTZUHq6dd0mXISzXUDmu
QmoFFBl2u7HhRKXFAzT6ZRCQtmg+RaP/Flw3nGtgOTuRVqvu/7D6p9P2URpWjzyNysoFlMed
KmDlxEBDsTGM8L0qqlL1cLaLG9fHwm9h7FOz6fObeyhQo/67dSg5xbHs7XXTrnX/PfNixmrT
BGB9q/nseCyFflxsrl2aTqq9WX68AstWIzmXww47IFw5/Kr8uTlG3HdlLD1RtpVXKIeJASIE
EAECAAwFAlgN+GwFAwASdQAACgkQlxC4m8pXrXxSFwf/YbcoTahtuKkozNN7ITCj0Nu3h94d
+Psug+4Q5Z+8g7dIoXttiard0EWKyAKGj44A0nz6vU61Xnha2FcZPckk2pAA7p0COXyOa7oF
hcjK9XsJjTQrT0KzFwVZwj7tjkoLsgaD7oSNJPnNt3LzEWP8XogEytdDenhqnb4z7jsrTtSp
SpV4EgZQKGCDkL0M+gEEsoifI7gDHdGQqy1kwk0SJM7ZdxG9MggkZqDf8avhvM1PQRcca84A
O6eJwYbgV0UuTylU114c+/q8KVR/9lV8fUOKNl591eU47my8mPegvKEpwpj7uD03e7sVrvEY
fyc0yxjGOJPlGAriZ+4+CgKViYkBIgQQAQIADAUCWB3VEgUDABJ1AAAKCRCXELibyletfHpk
CAC71dsYDE5RBk0UY/OIoBi8Wl70qdhMhIUS++dopa3cFTH3Be3C+eHfqhDBP6OERjcV5A8t
tDq6jd8w27esD5oQkndhw8OzUbGM/xlwvmesl37NPKJNDng+H+7vUX7w7+NEAiZbW8+poo4e
/ol7PzMXQpoH1J1CVXUWvA1URukuBKMuhTd71TXvhvf5xmxhOTaAQkQZgMSOlghmAZVSI1ji
LGIo7LfIlX2U2QP8n8LgvOwgC9d+/J/3d11KoQUJkN6krbs50JTLEx3k6KkGzdpZ3udx1DhA
rD7NELtQPNW4Og1Qnm4uLC+oGPRrA95QZzrxKHKX4YObPT9yyrH5PXNaiQEiBBABAgAMBQJY
L5b8BQMAEnUAAAoJEJcQuJvKV618HdsIAKUzQ/Ls3e2MAsblQ6AwfabELTtziUg5XBJ9gYrR
H3z8520gsDqVBr2BFKbQFARCR6kFRsFmW0pT1+AR2RzyJC8wW43QNyRLYcfYoArVoZn6Oal1
ptYns+VgWHHkn+aExmeL5emOcFXr8GPMuOpDrQHmw5RRDAuNOJOFPA0dLy3oZ9xLiYsOPHnt
18ONxlE7Kp8X+oWtfdafLi3UsdFwnZc3Hpu+f3beHIyee+w6Uits6QkKB5jgbOUE/Mh8tZXt
G4UwfdFxJjxulCVn+co/xlnJq1+0K/wlGI/zVLU31+gTKOL+ytom2JabcAU0BxBn8Anwvv1P
bFQjzQDK9naB9OyJASIEEAECAAwFAlhAu98FAwASdQAACgkQlxC4m8pXrXznaAf+JaTKg4J7
0acZWp0V88W0PCS4I50ZM0xnCST75yuzzqG3eEYiMogHTe/4LYucZDy06/n90BXAgi8E1JzN
pVnJHlnl/SYtQGeg0xVr8ilSQJbmA3EgBPa3dNHSRS/rwFeYZ0zgEPj6xVKJPwLRxtT61XIU
jqc9mqfXmRLOfmxE9M9QD1I/emVw2m9ok9OObm+spok/hNScWMT71wisOL7HQ9KAnwW4KXhF
/tj5QZLsCHK+MnbF/doTu6yvIDvrRwxQhMBe2yruLGekIjQQcE3FfZmJPrQtCwuBtEDVFkFu
hb8Z52FYvWApqH22+1dVZtjLdke8eAWt1RowdRyp4cjyQIkBIgQQAQIADAUCWFHfvAUDABJ1
AAAKCRCXELibyletfKrBB/9VOPqCg6+E0KvkhJEg9dphUFVeaixONq+AUtiuCpAxEwiJyj+3
WO2fzqoOhUHJuA4Bpqpb26Zgsh5YxBNqEXAcXRWkKDciBvUm90XmUVdD4jR7cmEYUO7HhopS
Zs3MHIj0cYeIu4HBFqcuijJNZvggeG1LtKXwao9+wB28QVW2MLWb6vYXuAmLyoY+fNM0ILXG
BZG4rl7JqV+q8aJ6HqLSuyFyeQNdk+KhUCcmBKV1ZjZ8A/U79ZFVaLUw9YQSgqBgqwIJTHN/
k6lzSkCJ4hqOMcrqujPClDgpG0u5g5qgCY079MsSO1YbqBQXi3kICI51gR6amTFJ/oaeIIe7
sl77iQEiBBABAgAMBQJYY6rzBQMAEnUAAAoJEJcQuJvKV618sUMIALBIL5vAPkJuK/8ltssI
sHnqpYKyDiSZygYDTuDRfBzDKi5TmOrdkTbW0ydOpdvQYChJlPSsVQ6YZ/loS8hhaAXs/R5D
nAFATblfQX8UqLfDJxkhZcZlOvShccClAkGxEdmJ+TikEmznNNHt9HttwRNap7hac2BE6oRx
Ai0v6knIND8/vKU2s0JmlLT/hbS/cSz81OM9BFAYIXrlrjZGJNkQdwai36x4aXQMd8P2Sznc
WcSbRh2Nm5qiEjbYAEBLYRztJ36YNuYGTmemy3JZuJbVuzqOuVMnS1TqTcxzeEblDNddPyTy
RMOv+wIyixxJe9wDcd3vS12oTVTGC0zJZ4qJASIEEAECAAwFAlh30SIFAwASdQAACgkQlxC4
m8pXrXymKwf/avn7NjwJeRswxDqcGQQVwbSvUCYE9Qwl4r6DanxHzb6oC0bksZ5PRoV1QK8P
H9n/B5d5kbYNjUZUACb+3wzxKO6/N9MuksvsyAjx+JFto0tpxappvZujgITUGyZpJ+EhcolI
t9C/Fae33sAhk9ep+l7g/SjfUDia2NIv374cIexctJYzX/Tzs4tt0EYM8bjAxrYMzfjOitA9
DwJ8mwNFojXJ8LVpQxIC5l9a744FZFCsG7PhtncXK4zZt/TV+edO6J8cZzXGqk2YJzA1hIfv
D3jJuFkI0jv5d7EvdN/kqF3/b6XlOaxaJIfNbTifpJk4Z0m7u+AtQ2eFsGe6PjLIBokBIgQQ
AQIADAUCWIk8TQUDABJ1AAAKCRCXELibyletfLSdCACaTmW2NSvL9Ys+FOd1jGymTYRpxauH
Gtxnk/BbsJP5yHGNtwbUITYjPU8raG9vHc8dG8odyLkKYKQieS4IwSZcVq7cO/aSG0EBy93d
0oQ0ircS3S5Slq93TPlgCoUU6MTUmLnYHfZJK+YSRmf3EdLlIVgCaW2w/vLiUglkjlu2VYc4
lQLSIbAry4X+AqsNw4GBEF5kYGBP2jAL0dlDk1MZMS1UBivmm46jQ3zVgHC8fuysteRXWGqv
qcU4sT5ZYwHqd/rcCxnZ42VfYPmIKHpqxype6CQrpG/KTd/f9wZb3ivDCTg8oWBhHQpp90Ip
scNmp/TC73W3L4C8h9vVXV4OiQEiBBABAgAMBQJYml/bBQMAEnUAAAoJEJcQuJvKV6181I8H
/2fFUd557EOiyd7LkQI5MKDLFJ6XiFB8Kj6teFQM6m2XAyEWQ31jxGIOv8S0oBtkC45H+7fY
kZZAD5KtAC9m7LYC88TMsR93lb6AV66jirBy2BU4SMKAEdmsqC6HiOGqUoVnBtqC8BJyeIYk
ip0G81rNsj1rjiZevdTZy7jCv/DKl6pfdVyd4m3ghHttIUQJ+0jtE8eCNBVtrUUVKUKm3LEz
wju1NP+W4gApfPjin7/4BWAb/UWmEodMdSi/J3EJdgRu8VH8r69nIwexm29lGaDgDDEI+1Gl
qvRyOQAHH+/Mq6LQ3CVifL56A73ee4R5E116kOEVyfy7POgniuoTNH+JASIEEAECAAwFAlir
g2YFAwASdQAACgkQlxC4m8pXrXyycAgAv3HwOUXlpMs/5/nvu8hyHMdKPtJ0WGysTyAJV3Zb
9huvIInF+E4a5+Y+x8wB0TQTtAQSyTMZGVue0N6JQXdYKgglq5IIGAdyaqdn7v0qZV/W5LvH
qZv7FiJQ+rwQ32JB9/xQ0s5SDZmwW/JbzNprL+iJMLe7fvnOE29M72SvNRwu2lbQMz9Ox/q+
/kztZ+E9KFY7ke/GbkFXdNSqGI5faIrdpW1huvKt8RGQnN8Fum4LRs4gmcUc+1wMvJhIVoNq
7z6l9JdXi9oUB9uJH0Y1eZV2bnXMCCIzukAv0JCFO7B3DbpgZEg/9J595/it0fixQvDTMBBC
+hk+ZpOjvo7ErIkCHAQQAQIABgUCSTQ5GwAKCRD1eh9wCCR23PesD/9j+6yoN+3UL+YV3F+/
YSyEtHyuJLV0ThFlYYoII0IZ9xDvK44FWsKOrnhmFSF+X64xW/2lUwBaTAugtcwFYh39spyX
kwe5NpDXjVz6yHklFryqoJN92P6jZt/X5LTi0HWN0LGdTGDUQ6TVeL0Syecej0lUThYFGZBz
Cv0xKDpfDlBXXoKZgDYk4CoYZX8IiKbFUvct8FGdI0QecfRSbKT2VbX//FbS5vdNtJsBnHcu
YBL0Xrr+QxdRv93MU2Y3caofTH1Fy1f+5G70CL2srLEkenH0nfL88WDBxcbm5f/b0oa/xDoP
UeBf2hh9N6SYGIdEc9/Bv9LyeP1K9wOjPBxdDaub6L83CByGe1p4Aj5+GVTg325G9aSIEUY4
SM4+WxIBeyvOxvJZ8M9aDIHqya/BzeveN4HaoD4tDHYt6NUF/MhWSVaRDPF1EL8A1fKvORVA
i6Ft/7NmQffx1qeLDoHiUq85TxShTjHROdDYmRRbsyF5Hg3bjISO8Tt5gNicc4fJwq3pSF5Q
rEggbc3IVQO+QNFHrgMoMdLi5HfGQA6GqOxtuk0zjvwik4JX6aYjYAbGINI//DVWArpintEa
ug3U3QaLV1QqK/C5OFfnHJEBhzKcldxd7SlEOHaLoOGiZV0+ws/59bxcAsVbSxzyUGYByYKf
UJfP3vVHEfGMn1XPyYkCHAQQAQgABgUCV3gRxwAKCRAgaSw69MXd8RI3D/4oD1DLrHT4U2mO
BuqL6qRSaNtLHUnXfF8MrEgqPFOCiQ6lOdp8sGv+N9q02IKkXBWqcWFVzS6jUEduedoz0tQe
LZf6TwjeJD7mN0bdhLfzIuCRo+XexvwpEdPOPkE70KBqoPUtbnydtimXH5fixw35MrHc3nzi
u/DhnNhZ6UavlL9tk/GHW+tsdwKLKBssbQ5kJDMx+wes6PUiJE60GnzVjafiumDjMDGzRv7/
FXA7WRsdXOC/UN4Mrr1BevznmzQ0UmrHXxkr1I33GIyJgRZv/iS0vaTSAeEeA1iSyHleUwvg
/MCGvaV5kFajNhwAiZfPJM+oAilfeC+/S668q0nZq2oqxNpVXe78Zdnk89HJbbk/ftqiwYin
qy8qefr72KkIforGAIHtv5AEhnKizzKkg4sHwFHvRIa+vn2D9Zluh09oqz+Qlwzyt+WAPNyE
C/NPjcdx9sRgn1Xs4o0+ddtaK8WeKjapM6pNiA1HET+nHGxRoSGyoMb12ToZy2QXt7fQzbSm
JaDZVtEkKDRIhFp6cNwD/+CEMp7MBxaZXGsZexuayjtjvmz7E/LxCXN4OqmebYQDO8ImTBfq
tK6d8P5OVSax+ERn3xX1axfV/YZmEjVRnClGYZHk7C45cCKiAk2eV/Jym8V89YASkyhcb5ru
b7yXe4FP/lVMgRwJ0w+55okCHAQQAQgABgUCWDdApAAKCRBfA8dnwkek1Sp3EAC0sh+12s1Q
4P7Q6VbzKaoP/H9xy1rXk+Kdov+w+ethHxKBYEWHWfL6Job7VM/TKEiN65az1m32xv2m4Jy3
G81dpa3yENNKwM6mN5NbIClcz5SntWFNuU6DYS22ElOs0Y5neAGhwL4kzh+C1P9HwlbmPvCX
SVpcDreItz7yVIK9LCCkky6A5vmDvl+9uxUQRgwyg1kT/blavh6eis0wDa6cNkehjC0/Ep1U
vv1zKoBLpC6HstqSeINcD2Cx2RvAysHqyujGZW8cLu64MxImqpUYHkxOavrFfbfOz/YY9zkl
5MtiD8ExcibYOJFPJgnqJxtqXp+Xe9vvmbMJO17lDcE5mzjx5gDS8FONcbakle+4HATur9z/
eolUsepNzkP/azFOY0eGqr1d+rpeKlc2c/Fk1WoLq7tcs1IbEkVqqvin8iAUtWXWKxGT7BT8
9tTgItXDWWJnSoVlvnDs+FsiiEDFcDE9AbHor3q3TghxWfaok13SpKrDpp/U8aLWmvdETSZI
CZ9dsmBA8WWzYnDJH7BbHxyypYjpItGlQUqkGcpGdWF0bImS4wKo2FWLUwrTiNTjuf/Kk+1a
vbj9b+pkW227lXSvx1VJDIDBB4NOvQ27zuow+SmJQ0Mo5lSZa5CSweSNoagc931omJcWJShr
pNKJRFt+msJLfru1NQqYSsjmeLkBDQQ/+K+0EAQAjTl1EeUt5EUq8tiGBq+KtFo3TxIdJKBt
VFQ4btETdF23dkZ1o1642GmF7JJgn6PKUcJDUlHhUO4IEcpHABAiU4HweoWh8yT/yaA9AXqR
KcJpMQ5bEGoooHBIg0Uh8ahG6Q1cHzgsGOaOK9YzFSvSIRXryMlrh1oITzvwEkXRfOcAAwcD
/iRaNtGYaS05FwaaVvm0Eexhhw2JzSaRP6PY3r/BGmgPVG9Uk9huk+Yk/pdW9Pa3KRj37ANK
2svfwHx9A077Ma9GoupZ/rjP01WO0ur8tzC7KsqCep9m33K9kdAeJZ0Ud+AwsnAEy/Q1XZin
/jUU5L1lzko010LXY9CqdrmCXhaqiEkEGBECAAkFAj/4r7QCGwwACgkQcCNT4PfkjtuungCg
2es41JEYaarCcT+gFpyM0WCqAU8An3L0pkO4wtZ8SejpHa7WSR9M54xd
=Nbc4
-----END PGP PUBLIC KEY BLOCK-----



> > Yes, I do have a corporate proxy, however, the environment variables are
> > set up properly. Other applications work. Having said that, port 80 is
> used
>
> A simple proxy or one of those application firewalls?
>

I actually do not know, but "simple proxy" may be a bit oxymoron in my
case. I will see if I can figure this out.

Other applications, like wget, curl, docker, etc, work fine with
http_proxy, https_proxy, etc. But I do not know whether that is helpful
information to this question.

Best regards,
Laszlo Papp


> Salam-Shalom,
>
>    Werner
>
> --
> #  Please read:  Daniel Ellsberg - The Doomsday Machine  #
> Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180410/32507ba8/attachment-0001.html>

From thomas.jarosch at intra2net.com  Wed Apr 11 10:03:42 2018
From: thomas.jarosch at intra2net.com (Thomas Jarosch)
Date: Wed, 11 Apr 2018 10:03:42 +0200
Subject: gpgme_op_verify regression with gnupg 2.2.6?
In-Reply-To: <877epfrm1k.fsf@wheatstone.g10code.de>
References: <877epfrm1k.fsf@wheatstone.g10code.de>
Message-ID: <2330784.t0GSNhEKWu@storm.m.i2n>

Hello together,

after updating from gnupg 2.2.5 to 2.2.6, I'm facing a possible regression.

We use the gpgme 1.8.0 library to verify the integrity of our update packages.
Two valid signatures need to be present on the checked file.

One unit test checks a file that is signed by two
known keys + unknown (future) key.

Error output from gpgme_op_verify():

gpgme_op_verify error: General error


Code that produced this:

    gpg_err = gpgme_op_verify (gpg_context.get(), gpg_data.get(), NULL, NULL);
    if(gpg_err != GPG_ERR_NO_ERROR)
        throw runtime_error("gpgme_op_verify error: " + string(gpgme_strerror(gpg_err)));


Having a file signed with xx known keys and y unknown
keys worked fine in gnupg 2.1.17 and 2.2.5.

Another unit test that just checks a file signed with one unknown key
fails in the same manner.

I'll try to upgrade to gpgme 1.10.0 and see if that helps with gnupg 2.2.6.

Anyway: Thanks for the new gnupg 2.2.6 release!

Cheers,
Thomas





From cgf9suexkm at contradiction.e4ward.com  Wed Apr 11 00:00:01 2018
From: cgf9suexkm at contradiction.e4ward.com (Email)
Date: Tue, 10 Apr 2018 18:00:01 -0400
Subject: gpgme_op_createkey errors
Message-ID: <BL7W_gN-HpI3XP1hjRSwsbrizDWCcAEDowf-BOYVMC18TBB9U6nMwFg50sBK-L93TVopq5L6fTRbzHQE9NsX0YKo3KEkUNjyMzoGXNpkEGE=@protonmail.com>

when writing C code using the GPG Made Easy library, the function "gpgme_op_createkey" is always throwing the error "Not supported" and I can't find any solution to resolve this.

1) Does anyone know why this error is being thrown, or what common causes are for this error?
2) Does anyone know of sample C code that can use this function without throwing this error?

When looking through the source code, I noticed that in the "tests" directory there is a file called "run-genkey.c" but when compiled it also throws the same error.

Thank you in advance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180410/f6c4f289/attachment.html>

From mangocats at gmail.com  Wed Apr 11 14:51:57 2018
From: mangocats at gmail.com (Mike Inman)
Date: Wed, 11 Apr 2018 08:51:57 -0400
Subject: GnuPG usage for automatic remote decryption
Message-ID: <CAAqEqK3nL3gsaQvGyVXY0JV0-t3AKb5vNdT4SGCXidJNOR-q4g@mail.gmail.com>

*** Correcting one, somewhat important, word ***

Hi Dirk & Ken,

I'm working on a similar problem... automated decryption "in the field" and
what I have come to is this:

Encrypt the message with a symmetric algorithm, adding salt and a
hash/checksum to ensure validity.  Then, taking that result and signing
with a private key.

In the field - the signature is validated with the matching public key,
then the symmetric algorithm decrypts the message.  While it is possible
that an attacker might unravel the shared keys used in the symmetric
encryption, this is not so much our concern as is the authenticity of the
message when received.  The combination of private key signature plus hash
checksum should do that.

Our solution needs to be "hands off" automated, which basically precludes
the idea of using passphrases (which would not stay secure in our
organization anyway.)  A determined attacker could get into the source code
and tease out the symmetric key, but that would only show them the contents
of the message, which, if they have the hardware, they can get anyway by
copying the hard drive after the message is decrypted - and as stated
above, this is of much less concern than a spoofed message getting
automatically accepted.

When I studied cryptography at Uni in the 1980s, they taught that
private/public key encryption was a more or less interchangeable affair -
the only difference between a private key and a public key is the manner in
which they are handled.  As such, I am a little disappointed in the GnuPGP
implementation that doesn't allow encryption with the private key to serve
as authentication and obscurity of the message - our
*** not private, but public *** key will be
obscured, but obviously not secured since attackers may have control of the
standard computer system it is contained in.  As things are, I am left to
use a layer of symmetric encryption to obscure the message, no more secure
in the end than using the private key to encrypt (since the symmetric key
is in the devices in the wild), but much more hassle.

Unless I'm missing something?

Also, thus far I have decided that it's easier to do symmetric encryption
with libgcrypt rather than mess with pgp... next week I'll be looking into
how to implement the signature with the private key - maybe that's also
practical to do in libgcrypt instead of gpgme?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180411/cbda1bbb/attachment.html>

From peter at digitalbrains.com  Wed Apr 11 16:29:19 2018
From: peter at digitalbrains.com (Peter Lebbing)
Date: Wed, 11 Apr 2018 16:29:19 +0200
Subject: GnuPG usage for automatic remote decryption
In-Reply-To: <CAAqEqK3nL3gsaQvGyVXY0JV0-t3AKb5vNdT4SGCXidJNOR-q4g@mail.gmail.com>
References: <CAAqEqK3nL3gsaQvGyVXY0JV0-t3AKb5vNdT4SGCXidJNOR-q4g@mail.gmail.com>
Message-ID: <b0c84010-1979-813f-14bc-9b644e7f7d38@digitalbrains.com>

On 11/04/18 14:51, Mike Inman wrote:
> Encrypt the message with a symmetric algorithm, adding salt and a
> hash/checksum to ensure validity.

I'm not sure what you're salting exactly, but anyway, this is not the focal
point of my reply. By the way, there are many ways to do what you describe in
such a way that the hash is utterly pointless and not authentication. For a
sweet example, check the use of CRC inside a stream cipher in WEP, the original
encryption layer of wireless LANs :-). Stream cipher + CRC = major D'oh!

> When I studied cryptography at Uni in the 1980s, they taught that
> private/public key encryption was a more or less interchangeable affair -
> the only difference between a private key and a public key is the manner in
> which they are handled.

This is only true for some algorithms and not for others, and even then only to
some extent.

For example, with RSA, encryption is: encrypt message with random key,
RSA-encrypt this random key to the private key of the intended recipient.

RSA signatures is the opposite, where a hash matching the signed data is
RSA-"encrypted" to the public key. Only the private key can "encrypt" to the
public key, so when anybody uses the public key to "decrypt" it, they can verify
the hash matches and was produced by the holder of the private key.

So for encryption, you choose the number and send it to the private key.

In signing, you obtain the number by hashing and send it to the public key.

They are mathematically equivalent. But note that the public and private key are
not interchangeable. The public exponent usually has a very low Hamming weight
while the private exponent is derived after fixing the public exponent. Simply
exchanging public and private variables would not give an equivalent keypair,
although mathematically they'd still work.

> As such, I am a little disappointed in the GnuPGP
> implementation that doesn't allow encryption with the private key to serve
> as authentication and obscurity of the message - our?
> *** not private, but public *** key will be
> obscured, but obviously not secured since attackers may have control of the
> standard computer system it is contained in.

Obscurity can be obtained by many low-complexity methods and is not a goal of
OpenPGP. There is no O in PGP :-). (Oh, and the GnuPG implementation wouldn't
usually add such a major deviation from the OpenPGP standard.)

And how do you see this as authentication? The way you describe it, I'm thinking
you simply reverse the roles of the public and private key, and you are thus
encrypting the session key to the public key with your private key instead of
the other way around. What does this achieve? As you'd then be sharing the
symmetric encryption key with the world, anybody could re-encrypt their
malicious data to that symmetric key, tag the so-called "encrypted" asymmetric
algorithm output that only the private key can produce on and presto,
"authenticated" data. If this is what you meant, well, I've just explained it's
not authentication. If this is not what you meant, please elaborate.

Okay, that was a wall of words with way too long sentences. So let me combine it
with an example.

1 - We will use an RSA keypair with modulus n, public exponent e and private
exponent d

2 - Choose symmetric key: sk = 0x2dfe0af9eeb3352c390791f4710a63da

3 - Encrypt "Transfer $ 1000 to Mike" using AES and the symmetric key sk from 2.
Let's call this result "BONAFIDEDATA"

4 - Compute s = sk^d mod n
This is "encrypting" the symmetric key sk to the public key. It is equal to what
PKCS#1 would consider the signature primitive RSASP1, mathematically equivalent
to the decryption primitive RSADP.

5 - Send s + "BONAFIDEDATA" to recipient

6 - Recipient computes sk = s^e mod n
This is "decrypting" the symmetric key sk using the public key. It is equal to
what PKCS#1 would consider the verification primitive RSAVP1, mathematically
equivalent to the encryption primitive RSAEP.

7 - Recipient decrypts "BONAFIDEDATA" using the correct sk, yielding "Transfer $
1000 to Mike".

8 - Mike has spending money.

Now I come along.

1 - Intercept or observe on the network s + "BONAFIDEDATA". Preventing reception
is optional.

2 - I compute sk = s^e mod n
This is public data.

3 - Encrypt "Transfer $ 10,000 to Peter" using AES and sk, which we correctly
determined to be 0x2dfe0af9eeb3352c390791f4710a63da. Let's call the result
"FAKEDDATA"

4 - Send s + "FAKEDDATA" to recipient

5 - Recipient computes sk = s^e mod n
This is "decrypting" the symmetric key sk using the public key. It is equal to
what PKCS#1 would consider the verification primitive RSAVP1, mathematically
equivalent to the encryption primitive RSAEP.

6 - Recipient decrypts "FAKEDDATA" using the correct sk, yielding "Transfer
$ 10,000 to Peter".

7 - Peter has spending money, and then some.

> Unless I'm missing something?

If you were to use OpenPGP encryption instead of a shared symmetric key, key
management and access revocation becomes much simpler. Additionally, you'd be
encrypting much less data with the same symmetric key. So there are some more
gotcha's with a static symmetric key: don't choose a symmetric algorithm with a
64-bit block size, etcetera. That's the thing about inventing your own crypto,
even at such a high level. It seems much simpler to me to use a private key that
is stored in plaintext on your recipient machine. Or TLS with the same, which by
the way is an extremely common setup, much more so than a passphrase-less
OpenPGP private key, even though they are the same principle.

HTH,

Peter.

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

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

From mangocats at gmail.com  Wed Apr 11 20:35:22 2018
From: mangocats at gmail.com (Mike Inman)
Date: Wed, 11 Apr 2018 14:35:22 -0400
Subject: GnuPG usage for automatic remote decryption
In-Reply-To: <b0c84010-1979-813f-14bc-9b644e7f7d38@digitalbrains.com>
References: <CAAqEqK3nL3gsaQvGyVXY0JV0-t3AKb5vNdT4SGCXidJNOR-q4g@mail.gmail.com>
 <b0c84010-1979-813f-14bc-9b644e7f7d38@digitalbrains.com>
Message-ID: <CAAqEqK3fozBGgzDj7yr6ZM_yJWW+Ti+gBoxko4cH_1=35mZ5LA@mail.gmail.com>

Peter,

Thanks for engaging, and walls of words with way too long sentences are all
too easy to create - I'm also bad at occasionally using the wrong word
(public vs private, for instance) which can render the whole wall confused.

So, my main challenge is that I have to "code and release" this system to a
bunch of users who aren't going to be lifting a finger for security, but
want security anyway.  The basic topology is: many machines sold to various
customers around the world, with occasional data exchanged between machines
and occasional software updates sent out.  (Occasional meaning: 0 or more.)

In the (less important) description of my symmetric "obscurity" code,
background may help.  These are files generated by machines in the field,
for consumption by other machines in the field with no opportunity for key
exchange.  The reason I call it obscurity is because, eventually someone
may discover the algorithm and key - at which point the files can be
decrypted, modified, re-encrypted, etc.  There's nothing of inherent value
in these files, just option settings which anyone with physical access can
change anyway - but, we want reasonable assurance that "hackers" won't be
toying with the machines by playing with these files.

To achieve this "obscurity/security" machine to machine, I have embedded a
key in the executable code (I know, I know, but is there a better way that
does not rely on user actions?)  The "salt" in the algorithm is a block of
random data that becomes the first encrypted block.  The settings data is
then encrypted, and the hash of the salt+settings data is encrypted,
hopefully achieving the goals of:

a) settings are not stored in plaintext to prevent "easy hacking"

b) identical settings files will appear different when encrypted due to the
salt, even though the key and iv do not change, making one route to
discovery of the key a little harder, and

c) if anything is changed without knowledge of the key, iv and algorithm,
the hash of the decrypted settings will not match the hash traveling with
the encrypted file, preventing randomly tampered files from being accepted
as valid.

Since these machines are "released to the wild" and must occasionally
communicate with each other this way, with essentially no guarantee of
opportunity for updates after release, I don't see a more secure
alternative?


The more important function is distribution of updates, and this is the one
that I want to employ public/private key encryption since the update files
are generated in a controlled location where we have the opportunity to at
least attempt to keep the private key confidential.  TLS would be nice, but
our update files may also arrive via USB stick, aka sneakernet...  All the
other limitations still apply - machines are sent into the wild and may not
have the opportunity for updates for years, if ever, but when we do send an
update we want the machine to be as certain as possible that it is an
intact authorized update.  Additionally, it is desired (but not critical)
for the contents of the update to be opaque to anyone who may examine the
file.

Thanks for the refresher on practical usage of RSA - my last "under the
hood" work with it was in the 1980s... Would this example be a correct
usage?

1 - We will use an RSA keypair with modulus n, public exponent e and
private exponent d, public exponent pre-programmed on the machines when
manufactured, private exponent held at the company.

2 - The message we want to send securely is: "Software updater from 1.0 to
1.1" compute a secure hash SH of the message say using SHA-3-512

3 - Compute SHe = sk^d mod n

4 - Obscure the composite message SHe+"Software updater from 1.0 to 1.1"
using a pre-shared symmetric key and algorithm (perhaps as described above)

5 - Recipient machine de-obscures the composite message using the
pre-shared symmetric key

6 - Recipient machine decrypts SH = SHe^e mod n and then can be certain
that the message is valid because only the factory knows d

Unfortunately, my hands are somewhat tied with respect to key lifecycle.  I
might be able to update some keys on some machines, but there is always the
(high likelihood) that a machine with just the original key will be out
there needing an update.  I'm starting to see the attraction of gpgme for
managing a list of keys, and possibly invalidating older keys with new
updates, but does it provide a mechanism for multiple authentications on a
single message?  ( Like: SHe1+SHe2...+SHeN+"Authenticated message" ? )

Thanks,

Mike


On Wed, Apr 11, 2018 at 10:29 AM, Peter Lebbing <peter at digitalbrains.com>
wrote:

> On 11/04/18 14:51, Mike Inman wrote:
> > Encrypt the message with a symmetric algorithm, adding salt and a
> > hash/checksum to ensure validity.
>
> I'm not sure what you're salting exactly, but anyway, this is not the focal
> point of my reply. By the way, there are many ways to do what you describe
> in
> such a way that the hash is utterly pointless and not authentication. For a
> sweet example, check the use of CRC inside a stream cipher in WEP, the
> original
> encryption layer of wireless LANs :-). Stream cipher + CRC = major D'oh!
>
> > When I studied cryptography at Uni in the 1980s, they taught that
> > private/public key encryption was a more or less interchangeable affair -
> > the only difference between a private key and a public key is the manner
> in
> > which they are handled.
>
> This is only true for some algorithms and not for others, and even then
> only to
> some extent.
>
> For example, with RSA, encryption is: encrypt message with random key,
> RSA-encrypt this random key to the private key of the intended recipient.
>
> RSA signatures is the opposite, where a hash matching the signed data is
> RSA-"encrypted" to the public key. Only the private key can "encrypt" to
> the
> public key, so when anybody uses the public key to "decrypt" it, they can
> verify
> the hash matches and was produced by the holder of the private key.
>
> So for encryption, you choose the number and send it to the private key.
>
> In signing, you obtain the number by hashing and send it to the public key.
>
> They are mathematically equivalent. But note that the public and private
> key are
> not interchangeable. The public exponent usually has a very low Hamming
> weight
> while the private exponent is derived after fixing the public exponent.
> Simply
> exchanging public and private variables would not give an equivalent
> keypair,
> although mathematically they'd still work.
>
> > As such, I am a little disappointed in the GnuPGP
> > implementation that doesn't allow encryption with the private key to
> serve
> > as authentication and obscurity of the message - our
> > *** not private, but public *** key will be
> > obscured, but obviously not secured since attackers may have control of
> the
> > standard computer system it is contained in.
>
> Obscurity can be obtained by many low-complexity methods and is not a goal
> of
> OpenPGP. There is no O in PGP :-). (Oh, and the GnuPG implementation
> wouldn't
> usually add such a major deviation from the OpenPGP standard.)
>
> And how do you see this as authentication? The way you describe it, I'm
> thinking
> you simply reverse the roles of the public and private key, and you are
> thus
> encrypting the session key to the public key with your private key instead
> of
> the other way around. What does this achieve? As you'd then be sharing the
> symmetric encryption key with the world, anybody could re-encrypt their
> malicious data to that symmetric key, tag the so-called "encrypted"
> asymmetric
> algorithm output that only the private key can produce on and presto,
> "authenticated" data. If this is what you meant, well, I've just explained
> it's
> not authentication. If this is not what you meant, please elaborate.
>
> Okay, that was a wall of words with way too long sentences. So let me
> combine it
> with an example.
>
> 1 - We will use an RSA keypair with modulus n, public exponent e and
> private
> exponent d
>
> 2 - Choose symmetric key: sk = 0x2dfe0af9eeb3352c390791f4710a63da
>
> 3 - Encrypt "Transfer $ 1000 to Mike" using AES and the symmetric key sk
> from 2.
> Let's call this result "BONAFIDEDATA"
>
> 4 - Compute s = sk^d mod n
> This is "encrypting" the symmetric key sk to the public key. It is equal
> to what
> PKCS#1 would consider the signature primitive RSASP1, mathematically
> equivalent
> to the decryption primitive RSADP.
>
> 5 - Send s + "BONAFIDEDATA" to recipient
>
> 6 - Recipient computes sk = s^e mod n
> This is "decrypting" the symmetric key sk using the public key. It is
> equal to
> what PKCS#1 would consider the verification primitive RSAVP1,
> mathematically
> equivalent to the encryption primitive RSAEP.
>
> 7 - Recipient decrypts "BONAFIDEDATA" using the correct sk, yielding
> "Transfer $
> 1000 to Mike".
>
> 8 - Mike has spending money.
>
> Now I come along.
>
> 1 - Intercept or observe on the network s + "BONAFIDEDATA". Preventing
> reception
> is optional.
>
> 2 - I compute sk = s^e mod n
> This is public data.
>
> 3 - Encrypt "Transfer $ 10,000 to Peter" using AES and sk, which we
> correctly
> determined to be 0x2dfe0af9eeb3352c390791f4710a63da. Let's call the result
> "FAKEDDATA"
>
> 4 - Send s + "FAKEDDATA" to recipient
>
> 5 - Recipient computes sk = s^e mod n
> This is "decrypting" the symmetric key sk using the public key. It is
> equal to
> what PKCS#1 would consider the verification primitive RSAVP1,
> mathematically
> equivalent to the encryption primitive RSAEP.
>
> 6 - Recipient decrypts "FAKEDDATA" using the correct sk, yielding "Transfer
> $ 10,000 to Peter".
>
> 7 - Peter has spending money, and then some.
>
> > Unless I'm missing something?
>
> If you were to use OpenPGP encryption instead of a shared symmetric key,
> key
> management and access revocation becomes much simpler. Additionally, you'd
> be
> encrypting much less data with the same symmetric key. So there are some
> more
> gotcha's with a static symmetric key: don't choose a symmetric algorithm
> with a
> 64-bit block size, etcetera. That's the thing about inventing your own
> crypto,
> even at such a high level. It seems much simpler to me to use a private
> key that
> is stored in plaintext on your recipient machine. Or TLS with the same,
> which by
> the way is an extremely common setup, much more so than a passphrase-less
> OpenPGP private key, even though they are the same principle.
>
> HTH,
>
> Peter.
>
> --
> I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
> You can send me encrypted mail if you want some privacy.
> My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180411/829f55b8/attachment.html>

From mangocats at gmail.com  Wed Apr 11 20:41:36 2018
From: mangocats at gmail.com (Mike Inman)
Date: Wed, 11 Apr 2018 14:41:36 -0400
Subject: GnuPG usage for automatic remote decryption
In-Reply-To: <CAAqEqK3fozBGgzDj7yr6ZM_yJWW+Ti+gBoxko4cH_1=35mZ5LA@mail.gmail.com>
References: <CAAqEqK3nL3gsaQvGyVXY0JV0-t3AKb5vNdT4SGCXidJNOR-q4g@mail.gmail.com>
 <b0c84010-1979-813f-14bc-9b644e7f7d38@digitalbrains.com>
 <CAAqEqK3fozBGgzDj7yr6ZM_yJWW+Ti+gBoxko4cH_1=35mZ5LA@mail.gmail.com>
Message-ID: <CAAqEqK0HtNMc0kEgYpfXhGNP+6zSSkSrEBE-Cpw7gSDuPU2qwA@mail.gmail.com>

Errata,

3 - Compute SHe = sk^d mod n

of course really meant:

3 - Compute SHe = SH^d mod n

Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180411/7c1ad3b2/attachment-0001.html>

From wk at gnupg.org  Wed Apr 11 21:02:13 2018
From: wk at gnupg.org (Werner Koch)
Date: Wed, 11 Apr 2018 21:02:13 +0200
Subject: gpgme_op_createkey errors
In-Reply-To: <BL7W_gN-HpI3XP1hjRSwsbrizDWCcAEDowf-BOYVMC18TBB9U6nMwFg50sBK-L93TVopq5L6fTRbzHQE9NsX0YKo3KEkUNjyMzoGXNpkEGE=@protonmail.com>
 (Email via Gnupg-users's message of "Tue, 10 Apr 2018 18:00:01 -0400")
References: <BL7W_gN-HpI3XP1hjRSwsbrizDWCcAEDowf-BOYVMC18TBB9U6nMwFg50sBK-L93TVopq5L6fTRbzHQE9NsX0YKo3KEkUNjyMzoGXNpkEGE=@protonmail.com>
Message-ID: <87a7u9r2h6.fsf@wheatstone.g10code.de>

On Wed, 11 Apr 2018 00:00, gnupg-users at gnupg.org said:
> when writing C code using the GPG Made Easy library, the function "gpgme_op_createkey" is always throwing the error "Not supported" and I can't find any solution to resolve this.

I would suggest to run this with GPGME_DEBUG set.  For example

 GPGME_DEBUG=9:gpgme.log: ./yourprogranm

gpgme.log will then contain a pretty verbose log including all output
From gpg.  If you can't figure out the problem, please post that file
here - it should not be very long - if it is too long please create a
file on dev.gnupg.org.


Shalom-Salam,

   Werner

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

From wk at gnupg.org  Wed Apr 11 21:09:03 2018
From: wk at gnupg.org (Werner Koch)
Date: Wed, 11 Apr 2018 21:09:03 +0200
Subject: dirmngr timeout
In-Reply-To: <CAOMwXhPjMcF0fmyPKr2b5d8xtDQJuGWugkf+Y7P-TP48gRRr2w@mail.gmail.com>
 (Laszlo Papp's message of "Tue, 10 Apr 2018 16:19:58 +0100")
References: <CAOMwXhPzQzQ-ykGURXRaBXaBQWtuqn9D1QKFZa6Jc=QO0CDhcw@mail.gmail.com>
 <87sh83rv6x.fsf@wheatstone.g10code.de>
 <CAOMwXhPjMcF0fmyPKr2b5d8xtDQJuGWugkf+Y7P-TP48gRRr2w@mail.gmail.com>
Message-ID: <87604xr25s.fsf@wheatstone.g10code.de>

On Tue, 10 Apr 2018 17:19, lpapp at kde.org said:

> Proxy request sent, awaiting response... 200 OK
> Length: 58162 (57K) [application/pgp-keys]

Okay that works.  Now we need to see why dirmngr has a different idea.
When we first talked on IRC, someone else reported that he had no
problems with that configuration - but it might not be fully the same.
Thus I need to try replicating the problem myself - will take some time,
though.

Do you have the envvar http_proxy set?  If so you also need to have

honor-http-proxy

in your dirmngr.conf.


Salam-Shalom,

   Werner

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

From edgar at pettijohn-web.com  Thu Apr 12 05:29:14 2018
From: edgar at pettijohn-web.com (Edgar Pettijohn)
Date: Wed, 11 Apr 2018 22:29:14 -0500
Subject: packet syntax
Message-ID: <ff3204ac-a93f-fc28-104f-0f3844ffa0b1@pettijohn-web.com>

I'm trying to learn the pgp packet syntax. I created a new key with gpg2 
--gen-key and then gpg2 --export > pubkey.key and then gpg2 --dearmor 
pubkey.key. Which left me with a pubkey.key.gpg file. I then did a 
hexdump of the file and the first word is `99' which in binary would be 
`10011001'. I was expecting to encounter `11000110'.? I'm thinking that 
perhaps I have missed something simple and just need a nudge in the 
right direction.

Thanks in advance,


Edgar



From thomas.jarosch at intra2net.com  Thu Apr 12 10:17:39 2018
From: thomas.jarosch at intra2net.com (Thomas Jarosch)
Date: Thu, 12 Apr 2018 10:17:39 +0200
Subject: gpgme_op_verify regression with gnupg 2.2.6?
In-Reply-To: <2330784.t0GSNhEKWu@storm.m.i2n>
References: <877epfrm1k.fsf@wheatstone.g10code.de>
 <2330784.t0GSNhEKWu@storm.m.i2n>
Message-ID: <6775193.m7x5xYRXLg@storm.m.i2n>

On Wednesday, 11 April 2018 10:03:42 CEST Thomas Jarosch wrote:
> Error output from gpgme_op_verify():
> 
> gpgme_op_verify error: General error

thanks to Werner's hint with GPGME_DEBUG in another gpgme related thread,
I was able to generate a short log file for gnupg 2.2.5 and gnupg 2.2.6.

Here's the relevant part:

*** gnupg 2.2.5 ***
_gpgme_io_read: enter: fd=0x5, buffer=0x9fab6b8, count=1024
_gpgme_io_read: check: 5b474e5550473a5d 2056455249464943 [GNUPG:] VERIFIC
_gpgme_io_read: check: 4154494f4e5f434f 4d504c49414e4345 ATION_COMPLIANCE
_gpgme_io_read: check: 5f4d4f4445203233 0a5b474e5550473a _MODE 23.[GNUPG:
_gpgme_io_read: check: 5d204e4557534947 0a5b474e5550473a ] NEWSIG.[GNUPG:
_gpgme_io_read: check: 5d20455252534947 2035313245454444 ] ERRSIG 512EEDD
_gpgme_io_read: check: 3535393830434335 4220312038203030 55980CC5B 1 8 00
_gpgme_io_read: check: 2031343838393836 35313020390a5b47  1488986510 9.[G
_gpgme_io_read: check: 4e5550473a5d204e 4f5f5055424b4559 NUPG:] NO_PUBKEY
_gpgme_io_read: check: 2035313245454444 3535393830434335  512EEDD55980CC5
_gpgme_io_read: check: 420a                              B.
_gpgme_io_read: leave: result=146
_gpgme_io_select: enter: fds=0x9fac1a8, nfds=10, nonblock=0
_gpgme_io_select: check: fds=0x09fac1a8, select on [ r0x5 ]
_gpgme_io_select: check: fds=0x09fac1a8, select OK [ r0x5 ]
_gpgme_io_select: leave: result=1
_gpgme_run_io_cb: call: item=0x9fac190, need to check
_gpgme_io_select: enter: fds=0xbfca2504, nfds=1, nonblock=1
_gpgme_io_select: check: fds=0xbfca2504, select on [ r0x5 ]
_gpgme_io_select: check: fds=0xbfca2504, select OK [ r0x5 ]
_gpgme_io_select: leave: result=1
_gpgme_run_io_cb: call: item=0x9fac190, handler (0x9faa8e8, 5)
_gpgme_io_read: enter: fd=0x5, buffer=0x9fab6b8, count=1024
_gpgme_io_read: leave: result=0
_gpgme_io_close: enter: fd=0x5
_gpgme_io_close: check: fd=0x5, invoking close handler 0xb76790a0/0x9faa8e8
  _gpgme_remove_io_cb: call: data=0x9fac180, setting fd 0x5 (item=0x9fac190) done
_gpgme_io_close: leave: result=0
gpgme:gpg_io_event: call: gpg=0x9faa8e8, event 0xb7665150, type 1, type_data 0xbfca2574
GPGME 2018-04-12 10:03:58 <0x02d6>  gpgme_op_verify: leave
GPGME 2018-04-12 10:03:58 <0x02d6>  gpgme_op_verify_result: enter: ctx=0x9faaf60
GPGME 2018-04-12 10:03:58 <0x02d6>  gpgme_op_verify_result: check: ctx=0x9faaf60, sig[0] = fpr A93971254B380E6EE4CDF80F32064F2D0D3C2EB1, summary 0x3, status Success


*** gnupg 2.2.6 ***
_gpgme_io_read: enter: fd=0x5, buffer=0x8ebe6b8, count=1024
_gpgme_io_read: check: 5b474e5550473a5d 2054525553545f55 [GNUPG:] TRUST_U
_gpgme_io_read: check: 4c54494d41544520 30207067700a5b47 LTIMATE 0 pgp.[G
_gpgme_io_read: check: 4e5550473a5d2056 4552494649434154 NUPG:] VERIFICAT
_gpgme_io_read: check: 494f4e5f434f4d50 4c49414e43455f4d ION_COMPLIANCE_M
_gpgme_io_read: check: 4f44452032330a5b 474e5550473a5d20 ODE 23.[GNUPG:] 
_gpgme_io_read: check: 4e45575349470a5b 474e5550473a5d20 NEWSIG.[GNUPG:] 
_gpgme_io_read: check: 4552525349472035 3132454544443535 ERRSIG 512EEDD55
_gpgme_io_read: check: 3938304343354220 3120382030302031 980CC5B 1 8 00 1
_gpgme_io_read: check: 3438383938363531 3020390a5b474e55 488986510 9.[GNU
_gpgme_io_read: check: 50473a5d204e4f5f 5055424b45592035 PG:] NO_PUBKEY 5
_gpgme_io_read: check: 3132454544443535 393830434335420a 12EEDD55980CC5B.
_gpgme_io_read: check: 5b474e5550473a5d 204641494c555245 [GNUPG:] FAILURE
_gpgme_io_read: check: 206770672d657869 7420333335353434  gpg-exit 335544
_gpgme_io_read: check: 33330a                            33.
_gpgme_io_read: leave: result=211
_gpgme_io_select: enter: fds=0x8ebf1a8, nfds=10, nonblock=0
_gpgme_io_select: check: fds=0x08ebf1a8, select on [ r0x5 ]
_gpgme_io_select: check: fds=0x08ebf1a8, select OK [ r0x5 ]
_gpgme_io_select: leave: result=1
_gpgme_run_io_cb: call: item=0x8ebf190, need to check
_gpgme_io_select: enter: fds=0xbfd548b4, nfds=1, nonblock=1
_gpgme_io_select: check: fds=0xbfd548b4, select on [ r0x5 ]
_gpgme_io_select: check: fds=0xbfd548b4, select OK [ r0x5 ]
_gpgme_io_select: leave: result=1
_gpgme_run_io_cb: call: item=0x8ebf190, handler (0x8ebd8e8, 5)
_gpgme_io_read: enter: fd=0x5, buffer=0x8ebe6b8, count=1024
_gpgme_io_read: leave: result=0
_gpgme_cancel_with_err: enter: ctx=0x8ebdf60, ctx_err=33554433, op_err=0
  _gpgme_io_close: enter: fd=0x5
  _gpgme_io_close: check: fd=0x5, invoking close handler 0xb76e80a0/0x8ebd8e8
    _gpgme_remove_io_cb: call: data=0x8ebf180, setting fd 0x5 (item=0x8ebf190) done
  _gpgme_io_close: leave: result=0
  gpgme:gpg_io_event: call: gpg=0x8ebd8e8, event 0xb76d4150, type 1, type_data 0xbfd548c8
_gpgme_cancel_with_err: leave
gpgme_op_verify:1176: error: General error <GnuPG>


-> to me it seems gnupg 2.2.6 exits with failure
once it encounters an unknown public key.

Is this behavior to be expected or considered a regression?


>From the 2.2.6 changelog it sounds like this change:

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


Versions used for the test:

gnupg-2.2.6
gpgme-1.8.0 (also tried 1.10.0)
libassuan-2.5.1
libgcrypt-1.8.1
libgpg-error-1.25

Cheers,
Thomas





From lpapp at kde.org  Thu Apr 12 10:30:11 2018
From: lpapp at kde.org (Laszlo Papp)
Date: Thu, 12 Apr 2018 09:30:11 +0100
Subject: dirmngr timeout
In-Reply-To: <87604xr25s.fsf@wheatstone.g10code.de>
References: <CAOMwXhPzQzQ-ykGURXRaBXaBQWtuqn9D1QKFZa6Jc=QO0CDhcw@mail.gmail.com>
 <87sh83rv6x.fsf@wheatstone.g10code.de>
 <CAOMwXhPjMcF0fmyPKr2b5d8xtDQJuGWugkf+Y7P-TP48gRRr2w@mail.gmail.com>
 <87604xr25s.fsf@wheatstone.g10code.de>
Message-ID: <CAOMwXhM=9O2rPA=1A669nP9-Yv4kER4wP+J91FbBsnJi5Wm+LQ@mail.gmail.com>

On Wed, Apr 11, 2018 at 8:09 PM, Werner Koch <wk at gnupg.org> wrote:

> On Tue, 10 Apr 2018 17:19, lpapp at kde.org said:
>
> > Proxy request sent, awaiting response... 200 OK
> > Length: 58162 (57K) [application/pgp-keys]
>
> Okay that works.  Now we need to see why dirmngr has a different idea.
> When we first talked on IRC, someone else reported that he had no
> problems with that configuration - but it might not be fully the same.
> Thus I need to try replicating the problem myself - will take some time,
> though.
>
> Do you have the envvar http_proxy set?  If so you also need to have
>
> honor-http-proxy
>
> in your dirmngr.conf.
>

That is an interesting idea as one would think that the environment
variables would be respected by default rather than opting in.

honor-http-proxy did not work, but --http-proxy host[:port] did. Thank you
for pointing me to this direction.

This makes me think that dirmngr does not understand the environment
variable by default, given that it does not work "by default" and when I
try to reinforce this with honor-http-proxy. Is this information lost when
gpg launches dirmngr? If so, should it not be retained?

Is there a command line option for gpg, like for sudo (-E) and similar
software applications, to pass on all the environment variables properly if
this is the issue?

gpg is also used in my docker build process, so the best would be to
respect the environment variable by default. Are there any objections to
that? If so, what exactly?



> Salam-Shalom,
>
>    Werner
>
> --
> #  Please read:  Daniel Ellsberg - The Doomsday Machine  #
> Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180412/92f7d1e9/attachment.html>

From wk at gnupg.org  Thu Apr 12 10:29:30 2018
From: wk at gnupg.org (Werner Koch)
Date: Thu, 12 Apr 2018 10:29:30 +0200
Subject: gpgme_op_verify regression with gnupg 2.2.6?
In-Reply-To: <6775193.m7x5xYRXLg@storm.m.i2n> (Thomas Jarosch's message of
 "Thu, 12 Apr 2018 10:17:39 +0200")
References: <877epfrm1k.fsf@wheatstone.g10code.de>
 <2330784.t0GSNhEKWu@storm.m.i2n> <6775193.m7x5xYRXLg@storm.m.i2n>
Message-ID: <87lgdsq13p.fsf@wheatstone.g10code.de>

On Thu, 12 Apr 2018 10:17, thomas.jarosch at intra2net.com said:

> -> to me it seems gnupg 2.2.6 exits with failure
> once it encounters an unknown public key.
>
> Is this behavior to be expected or considered a regression?

Good question.  I implemented the

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

to help Enigmail but they are also parsed by gpgme in a way that make
gpgme fail.  So yes, this is clearly a regression.  The question is
whetrhe to fix it: 

 a) In GPGME
 b) In GnuPG
    - either send FAILURE status lines only in severe situations
      (e.g. bad option argument)
    - or figure out why the NO_PUBKEY also used log_error which causes
      an exit code != 0 and thus the FAILURE status line.

I need to think about - I considere this a severe problem.
 

Salam-Shalom,

   Werner

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

From wk at gnupg.org  Thu Apr 12 10:39:17 2018
From: wk at gnupg.org (Werner Koch)
Date: Thu, 12 Apr 2018 10:39:17 +0200
Subject: packet syntax
In-Reply-To: <ff3204ac-a93f-fc28-104f-0f3844ffa0b1@pettijohn-web.com> (Edgar
 Pettijohn's message of "Wed, 11 Apr 2018 22:29:14 -0500")
References: <ff3204ac-a93f-fc28-104f-0f3844ffa0b1@pettijohn-web.com>
Message-ID: <87h8ogq0ne.fsf@wheatstone.g10code.de>

On Thu, 12 Apr 2018 05:29, edgar at pettijohn-web.com said:

> did a hexdump of the file and the first word is `99' which in binary
> would be `10011001'. I was expecting to encounter `11000110'.? I'm

OpenPGP (RFC-4880) has several ways to encode a packet header.  This
first byte is called the CTB and reads:

  0x10011001 
     !^^^^##-  0x01  = 2 length bytes follow.
     !!------- 0x06  = Public key
     !-------- Clear = Old style CTB
  0x11000110  
     !^^^^^^
     !!------- 0x06 = Public Key
     !-------- Set  = New style CTB

For a new style CTB the length bytes are Hufmann like encoded.  Bit 7 is
always set.  A basic parser can be found in gpgme/src/data-identify.c


Shalom-Salam,

   Werner

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

From fuzzy_drawrings at protonmail.com  Thu Apr 12 09:30:45 2018
From: fuzzy_drawrings at protonmail.com (FuzzyDrawrings)
Date: Thu, 12 Apr 2018 03:30:45 -0400
Subject: packet syntax
Message-ID: <HUDUgUvsNpbcL8cCErWAEjgfFwZiR422YgSoykT3jXSTZsWpB9vmWB9vokVbfZIuT7XAhUQLeylqcr6gu1FO95lUlJq2aM2sbPVnLxKjqPA=@protonmail.com>

Edgar Pettijohn wrote:

> the first word is `99' which in binary would be 
> `10011001'. I was expecting to encounter `11000110'.

You were expecting the packet header to be written in the "new" format, but it is actually written in the "old" format (indicated by it beginning with "10" vs "11"). See RFC-4880 section 4.2.

Public key packets have a Tag ID of 6, and the "new" format isn't required unless the packet has a Tag ID greater than 15. 

-fuzzy


From wk at gnupg.org  Thu Apr 12 11:53:33 2018
From: wk at gnupg.org (Werner Koch)
Date: Thu, 12 Apr 2018 11:53:33 +0200
Subject: gpgme_op_verify regression with gnupg 2.2.6?
In-Reply-To: <87lgdsq13p.fsf@wheatstone.g10code.de> (Werner Koch's message of
 "Thu, 12 Apr 2018 10:29:30 +0200")
References: <877epfrm1k.fsf@wheatstone.g10code.de>
 <2330784.t0GSNhEKWu@storm.m.i2n> <6775193.m7x5xYRXLg@storm.m.i2n>
 <87lgdsq13p.fsf@wheatstone.g10code.de>
Message-ID: <87bmeopx7m.fsf@wheatstone.g10code.de>

Hi,

I think I will fix it in GnuPG.  Attached is an already pushed fix.


Salam-Shalom,

   Werner

-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-gpg-Relax-printing-of-STATUS_FAILURE.patch
Type: text/x-diff
Size: 1380 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180412/c5ecf393/attachment.patch>
-------------- 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-users/attachments/20180412/c5ecf393/attachment.sig>

From thomas.jarosch at intra2net.com  Thu Apr 12 12:56:30 2018
From: thomas.jarosch at intra2net.com (Thomas Jarosch)
Date: Thu, 12 Apr 2018 12:56:30 +0200
Subject: gpgme_op_verify regression with gnupg 2.2.6?
In-Reply-To: <87bmeopx7m.fsf@wheatstone.g10code.de>
References: <877epfrm1k.fsf@wheatstone.g10code.de>
 <87lgdsq13p.fsf@wheatstone.g10code.de> <87bmeopx7m.fsf@wheatstone.g10code.de>
Message-ID: <3450890.sTJIORrvAJ@storm.m.i2n>

Hi Werner,

On Thursday, 12 April 2018 11:53:33 CEST Werner Koch wrote:
> I think I will fix it in GnuPG.  Attached is an already pushed fix.

with that fix applied on top of gnupg 2.2.6 vanilla,
one gpgme 1.10.0 unit test fails:

t-verify.c:239: GnuPG: General error
FAIL: t-verify

Sorry for raining on your parade :)

Cheers,
Thomas





From thomas.jarosch at intra2net.com  Thu Apr 12 12:58:52 2018
From: thomas.jarosch at intra2net.com (Thomas Jarosch)
Date: Thu, 12 Apr 2018 12:58:52 +0200
Subject: gpgme_op_verify regression with gnupg 2.2.6?
In-Reply-To: <3450890.sTJIORrvAJ@storm.m.i2n>
References: <877epfrm1k.fsf@wheatstone.g10code.de>
 <87bmeopx7m.fsf@wheatstone.g10code.de> <3450890.sTJIORrvAJ@storm.m.i2n>
Message-ID: <1830764.0g0lOWHsn9@storm.m.i2n>

On Thursday, 12 April 2018 12:56:30 CEST Thomas Jarosch wrote:
> Hi Werner,
> 
> On Thursday, 12 April 2018 11:53:33 CEST Werner Koch wrote:
> > I think I will fix it in GnuPG.  Attached is an already pushed fix.
> 
> with that fix applied on top of gnupg 2.2.6 vanilla,
> one gpgme 1.10.0 unit test fails:
> 
> t-verify.c:239: GnuPG: General error
> FAIL: t-verify

forgot to mention: The test doesn't fail when the patch is not applied.

Cheers,
Thomas





From edgar at pettijohn-web.com  Thu Apr 12 13:59:56 2018
From: edgar at pettijohn-web.com (edgar at pettijohn-web.com)
Date: Thu, 12 Apr 2018 06:59:56 -0500
Subject: packet syntax
Message-ID: <mailman.10.1523534405.30378.gnupg-users@gnupg.org>


On Apr 12, 2018 2:30 AM, FuzzyDrawrings via Gnupg-users <gnupg-users at gnupg.org> wrote:
>
> Edgar Pettijohn wrote:
>
> > the first word is `99' which in binary would be 
> > `10011001'. I was expecting to encounter `11000110'.
>
> You were expecting the packet header to be written in the "new" format, but it is actually written in the "old" format (indicated by it beginning with "10" vs "11"). See RFC-4880 section 4.2.

This is what I thought I was seeing, but thought I read somewhere that gpg creates version 4 packets.  Thanks.
>
> Public key packets have a Tag ID of 6, and the "new" format isn't required unless the packet has a Tag ID greater than 15. 
>
> -fuzzy
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users

From edgar at pettijohn-web.com  Thu Apr 12 14:01:18 2018
From: edgar at pettijohn-web.com (edgar at pettijohn-web.com)
Date: Thu, 12 Apr 2018 07:01:18 -0500
Subject: packet syntax
Message-ID: <mailman.11.1523534483.30378.gnupg-users@gnupg.org>


On Apr 12, 2018 3:39 AM, Werner Koch <wk at gnupg.org> wrote:
>
> On Thu, 12 Apr 2018 05:29, edgar at pettijohn-web.com said:
>
> > did a hexdump of the file and the first word is `99' which in binary
> > would be `10011001'. I was expecting to encounter `11000110'.? I'm
>
> OpenPGP (RFC-4880) has several ways to encode a packet header.? This
> first byte is called the CTB and reads:
>
> ? 0x10011001 
> ???? !^^^^##-? 0x01? = 2 length bytes follow.
> ???? !!------- 0x06? = Public key
> ???? !-------- Clear = Old style CTB
> ? 0x11000110? 
> ???? !^^^^^^
> ???? !!------- 0x06 = Public Key
> ???? !-------- Set? = New style CTB
>
> For a new style CTB the length bytes are Hufmann like encoded.? Bit 7 is
> always set.? A basic parser can be found in gpgme/src/data-identify.c
>

Cool. I'll check that out.

Thanks
>
> Shalom-Salam,
>
> ?? Werner
>
> -- 
> #? Please read:? Daniel Ellsberg - The Doomsday Machine? #
> Die Gedanken sind frei.? Ausnahmen regelt ein Bundesgesetz.

From wk at gnupg.org  Thu Apr 12 15:26:45 2018
From: wk at gnupg.org (Werner Koch)
Date: Thu, 12 Apr 2018 15:26:45 +0200
Subject: gpgme_op_verify regression with gnupg 2.2.6?
In-Reply-To: <3450890.sTJIORrvAJ@storm.m.i2n> (Thomas Jarosch's message of
 "Thu, 12 Apr 2018 12:56:30 +0200")
References: <877epfrm1k.fsf@wheatstone.g10code.de>
 <87lgdsq13p.fsf@wheatstone.g10code.de>
 <87bmeopx7m.fsf@wheatstone.g10code.de>
 <3450890.sTJIORrvAJ@storm.m.i2n>
Message-ID: <87604wpnca.fsf@wheatstone.g10code.de>

On Thu, 12 Apr 2018 12:56, thomas.jarosch at intra2net.com said:

> t-verify.c:239: GnuPG: General error
> FAIL: t-verify

That turns out to be more complicated than on first sight.  This error
is from checking that BAD signature - in this case gpg emits a BADSIG
status line and calls exit with failure; in trun a STATUS_FAILURE is
triggred.  

Now that could be fixed GnuPG but at quite some pales.  Not the right
solution.  I need to apply fixes to GPGME as well.  And that should also
be backported to a 1.10.1 (actually I planned to release 1.11.0 this
week).

Please stay tuned for a GPGME fix.  I hope that you can test it too.

> Sorry for raining on your parade :)

Bug fixing introduces delays ;-)


Shalom-Salam,

   Werner

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

From lpapp at kde.org  Thu Apr 12 15:45:40 2018
From: lpapp at kde.org (Laszlo Papp)
Date: Thu, 12 Apr 2018 14:45:40 +0100
Subject: dirmngr timeout
In-Reply-To: <CAOMwXhM=9O2rPA=1A669nP9-Yv4kER4wP+J91FbBsnJi5Wm+LQ@mail.gmail.com>
References: <CAOMwXhPzQzQ-ykGURXRaBXaBQWtuqn9D1QKFZa6Jc=QO0CDhcw@mail.gmail.com>
 <87sh83rv6x.fsf@wheatstone.g10code.de>
 <CAOMwXhPjMcF0fmyPKr2b5d8xtDQJuGWugkf+Y7P-TP48gRRr2w@mail.gmail.com>
 <87604xr25s.fsf@wheatstone.g10code.de>
 <CAOMwXhM=9O2rPA=1A669nP9-Yv4kER4wP+J91FbBsnJi5Wm+LQ@mail.gmail.com>
Message-ID: <CAOMwXhN6H=L=09mwukdUad7RE5o5=BkgXza8KuZgZdGPhdSxQg@mail.gmail.com>

On Thu, Apr 12, 2018 at 9:30 AM, Laszlo Papp <lpapp at kde.org> wrote:

>
>
> On Wed, Apr 11, 2018 at 8:09 PM, Werner Koch <wk at gnupg.org> wrote:
>
>> On Tue, 10 Apr 2018 17:19, lpapp at kde.org said:
>>
>> > Proxy request sent, awaiting response... 200 OK
>> > Length: 58162 (57K) [application/pgp-keys]
>>
>> Okay that works.  Now we need to see why dirmngr has a different idea.
>> When we first talked on IRC, someone else reported that he had no
>> problems with that configuration - but it might not be fully the same.
>> Thus I need to try replicating the problem myself - will take some time,
>> though.
>>
>> Do you have the envvar http_proxy set?  If so you also need to have
>>
>> honor-http-proxy
>>
>> in your dirmngr.conf.
>>
>
> That is an interesting idea as one would think that the environment
> variables would be respected by default rather than opting in.
>
> honor-http-proxy did not work, but --http-proxy host[:port] did. Thank you
> for pointing me to this direction.
>
> This makes me think that dirmngr does not understand the environment
> variable by default, given that it does not work "by default" and when I
> try to reinforce this with honor-http-proxy. Is this information lost when
> gpg launches dirmngr? If so, should it not be retained?
>
> Is there a command line option for gpg, like for sudo (-E) and similar
> software applications, to pass on all the environment variables properly if
> this is the issue?
>
> gpg is also used in my docker build process, so the best would be to
> respect the environment variable by default. Are there any objections to
> that? If so, what exactly?
>

It looks like if I run dirmngr manually, as follows, with honor-http-proxy,
gpg works:

dirmngr --daemon

But when it is run as dirmngr --supervised, gpg does not seem to work until
the http-proxy is specified in the config explicitly.



>  Salam-Shalom,
>
>>
>>    Werner
>>
>> --
>> #  Please read:  Daniel Ellsberg - The Doomsday Machine  #
>> Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
>>
>> _______________________________________________
>> Gnupg-users mailing list
>> Gnupg-users at gnupg.org
>> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180412/7b75c29f/attachment-0001.html>

From dirk.gottschalk1980 at googlemail.com  Thu Apr 12 17:16:24 2018
From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk)
Date: Thu, 12 Apr 2018 17:16:24 +0200
Subject: Errors while creating an g13 encrypted container.
Message-ID: <1523546184.9629.2.camel@googlemail.com>

Hello,

we are trying to exchange files in encrypted containers. But when I
create such a container, g13 throws the following errors:

$ g13 -r 764C2156D8AC31D0 --create container.g13 
g13: DBG: used keyblob size is 61
g13: running '/usr/bin/encfs' in the background
g13: DBG: starting runner thread
g13: got prompt 'create_root_dir'
g13: DBG: sending command  -->y<--
g13: got prompt 'create_mount_point'
g13: DBG: sending command  -->y<--
g13: got prompt 'config_option'
g13: DBG: sending command  --><--
g13: got prompt 'new_passwd'
g13: got status 'fuse_main_start'
g13: DBG: runner thread noticed cancel flag
g13: DBG: runner thread closed status fp
g13: DBG: runner thread waiting ...
g13: Fehler bei Ausf?hrung von `encfs-1': beendet
g13: running 'encfs-1' failed (exitcode=-1): Allgemeiner Fehler
g13: DBG: runner thread waiting finished
g13: DBG: runner thread releasing runner ...
g13: failed to remove mount with rid 1 from mtab: Nicht gefunden
g13: DBG: runner thread runner released
g13: g13 (GnuPG) 2.2.5 angehalten

Am I doing something wrong in the creation command?

Regards,
Dirk


-- 
Dirk Gottschalk
Paulusstrasse 6-8
52064 Aachen
Tel.: +49 1573 1152350
-------------- 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-users/attachments/20180412/56286048/attachment.sig>

From wk at gnupg.org  Thu Apr 12 21:08:39 2018
From: wk at gnupg.org (Werner Koch)
Date: Thu, 12 Apr 2018 21:08:39 +0200
Subject: Errors while creating an g13 encrypted container.
In-Reply-To: <1523546184.9629.2.camel@googlemail.com> (Dirk Gottschalk via
 Gnupg-users's message of "Thu, 12 Apr 2018 17:16:24 +0200")
References: <1523546184.9629.2.camel@googlemail.com>
Message-ID: <87sh80nsy0.fsf@wheatstone.g10code.de>

On Thu, 12 Apr 2018 17:16, gnupg-users at gnupg.org said:

> g13: running '/usr/bin/encfs' in the background

IIRC, the author of encfs said that it should not anymore be used.
Given that, I have not tested encfs based container in a long time.  I
use dm-crypt containers instead.

> g13: running 'encfs-1' failed (exitcode=-1): Allgemeiner Fehler

Did encfs remove dthe patch I once got upstream?  That could be a reason
for this.  For quick debugging, I would suggest to employ strace.


Salam-Shalom,

   Werner

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

From dirk.gottschalk1980 at googlemail.com  Fri Apr 13 03:49:17 2018
From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk)
Date: Fri, 13 Apr 2018 03:49:17 +0200
Subject: Errors while creating an g13 encrypted container.
In-Reply-To: <87sh80nsy0.fsf@wheatstone.g10code.de>
References: <1523546184.9629.2.camel@googlemail.com>
 <87sh80nsy0.fsf@wheatstone.g10code.de>
Message-ID: <1523584157.9664.11.camel@googlemail.com>

Hi.

Am Donnerstag, den 12.04.2018, 21:08 +0200 schrieb Werner Koch:
> On Thu, 12 Apr 2018 17:16, gnupg-users at gnupg.org said:

> > g13: running '/usr/bin/encfs' in the background

> IIRC, the author of encfs said that it should not anymore be used.
> Given that, I have not tested encfs based container in a long
> time.  I
> use dm-crypt containers instead.

Oh, good to know.

So I tested it with dm-crypt and got another error:

---
$ g13 -r 764C2156D8AC31D0 --type dm-crypt --create container.g13 
g13: can't connect to 'g13-syshelp': IPC "connect" Aufruf
fehlgeschlagen G13
g13: (is userv and its gnupg-g13-syshelp script installed?)
g13: error creating a new container: IPC "connect" Aufruf
fehlgeschlagen <G13>
---

GnuPG 2 is installed with all dependencies. Installed versions:

---
# dnf list "gnupg2*"
Installierte Pakete
gnupg2.x86_64  2.2.5-1.fc27  
gnupg2-smime.x86_64 2.2.5-1.fc27
---

There is neither a command or package named userv, nor a script called
'gnupg-g13-syshelp' in the repositories. The binary g13-syshelp is
available.

Has anybody some suggestions? or should I file a bug report against the
RPM package?

Thanks.

Regards,
Dirk



-- 
Dirk Gottschalk
Paulusstrasse 6-8
52064 Aachen
Tel.: +49 1573 1152350
-------------- 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-users/attachments/20180413/e749282b/attachment.sig>

From wk at gnupg.org  Fri Apr 13 11:40:52 2018
From: wk at gnupg.org (Werner Koch)
Date: Fri, 13 Apr 2018 11:40:52 +0200
Subject: Errors while creating an g13 encrypted container.
In-Reply-To: <1523584157.9664.11.camel@googlemail.com> (Dirk Gottschalk via
 Gnupg-users's message of "Fri, 13 Apr 2018 03:49:17 +0200")
References: <1523546184.9629.2.camel@googlemail.com>
 <87sh80nsy0.fsf@wheatstone.g10code.de>
 <1523584157.9664.11.camel@googlemail.com>
Message-ID: <87in8vo34r.fsf@wheatstone.g10code.de>

On Fri, 13 Apr 2018 03:49, gnupg-users at gnupg.org said:

> There is neither a command or package named userv, nor a script called
> 'gnupg-g13-syshelp' in the repositories. The binary g13-syshelp is
> available.

  apt-get install userv

Frankly, I wonder why that immense useful tool is not part of the base
distribution.


Salam-Shalom,

   Werner

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

From wk at gnupg.org  Fri Apr 13 11:46:40 2018
From: wk at gnupg.org (Werner Koch)
Date: Fri, 13 Apr 2018 11:46:40 +0200
Subject: dirmngr timeout
In-Reply-To: <CAOMwXhN6H=L=09mwukdUad7RE5o5=BkgXza8KuZgZdGPhdSxQg@mail.gmail.com>
 (Laszlo Papp's message of "Thu, 12 Apr 2018 14:45:40 +0100")
References: <CAOMwXhPzQzQ-ykGURXRaBXaBQWtuqn9D1QKFZa6Jc=QO0CDhcw@mail.gmail.com>
 <87sh83rv6x.fsf@wheatstone.g10code.de>
 <CAOMwXhPjMcF0fmyPKr2b5d8xtDQJuGWugkf+Y7P-TP48gRRr2w@mail.gmail.com>
 <87604xr25s.fsf@wheatstone.g10code.de>
 <CAOMwXhM=9O2rPA=1A669nP9-Yv4kER4wP+J91FbBsnJi5Wm+LQ@mail.gmail.com>
 <CAOMwXhN6H=L=09mwukdUad7RE5o5=BkgXza8KuZgZdGPhdSxQg@mail.gmail.com>
Message-ID: <87bmeno2v3.fsf@wheatstone.g10code.de>

On Thu, 12 Apr 2018 15:45, lpapp at kde.org said:

[Full quote trimmed]
> It looks like if I run dirmngr manually, as follows, with honor-http-proxy,
> gpg works:
>
> dirmngr --daemon

It will also work if dirnmnr is automatically started by gpg or via
gpgconf --launch dirmngr.

> But when it is run as dirmngr --supervised, gpg does not seem to work until
> the http-proxy is specified in the config explicitly.

It seems that systemd has a different view on the envvars and thus your
somewhere set http_proxy=foo:port is not inherited by dirmngr.
According to IRC there are ways to set envvars for specific systemd
actions.  If can find them out it would be nice if you can document that
in a reply.


Shalom-Salam,

   Werner


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

From lpapp at kde.org  Fri Apr 13 12:00:59 2018
From: lpapp at kde.org (Laszlo Papp)
Date: Fri, 13 Apr 2018 11:00:59 +0100
Subject: dirmngr timeout
In-Reply-To: <87bmeno2v3.fsf@wheatstone.g10code.de>
References: <CAOMwXhPzQzQ-ykGURXRaBXaBQWtuqn9D1QKFZa6Jc=QO0CDhcw@mail.gmail.com>
 <87sh83rv6x.fsf@wheatstone.g10code.de>
 <CAOMwXhPjMcF0fmyPKr2b5d8xtDQJuGWugkf+Y7P-TP48gRRr2w@mail.gmail.com>
 <87604xr25s.fsf@wheatstone.g10code.de>
 <CAOMwXhM=9O2rPA=1A669nP9-Yv4kER4wP+J91FbBsnJi5Wm+LQ@mail.gmail.com>
 <CAOMwXhN6H=L=09mwukdUad7RE5o5=BkgXza8KuZgZdGPhdSxQg@mail.gmail.com>
 <87bmeno2v3.fsf@wheatstone.g10code.de>
Message-ID: <CAOMwXhNRv+tLUk-sv=jJn9-O9isqrc1ZD5=wOkWAj=gjs151zQ@mail.gmail.com>

On Fri, Apr 13, 2018 at 10:46 AM, Werner Koch <wk at gnupg.org> wrote:

> On Thu, 12 Apr 2018 15:45, lpapp at kde.org said:
>
> [Full quote trimmed]
> > It looks like if I run dirmngr manually, as follows, with
> honor-http-proxy,
> > gpg works:
> >
> > dirmngr --daemon
>
> It will also work if dirnmnr is automatically started by gpg or via
> gpgconf --launch dirmngr.
>
> > But when it is run as dirmngr --supervised, gpg does not seem to work
> until
> > the http-proxy is specified in the config explicitly.
>
> It seems that systemd has a different view on the envvars and thus your
> somewhere set http_proxy=foo:port is not inherited by dirmngr.
> According to IRC there are ways to set envvars for specific systemd
> actions.  If can find them out it would be nice if you can document that
> in a reply.
>

Yes, I meant to reply yesterday after solving this.

systemd --user import-environment http_proxy

is what I used.


>
>
> Shalom-Salam,
>
>    Werner
>
>
> --
> #  Please read:  Daniel Ellsberg - The Doomsday Machine  #
> Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180413/84b114b1/attachment.html>

From wk at gnupg.org  Fri Apr 13 12:16:22 2018
From: wk at gnupg.org (Werner Koch)
Date: Fri, 13 Apr 2018 12:16:22 +0200
Subject: gpgme_op_verify regression with gnupg 2.2.6?
In-Reply-To: <87604wpnca.fsf@wheatstone.g10code.de> (Werner Koch's message of
 "Thu, 12 Apr 2018 15:26:45 +0200")
References: <877epfrm1k.fsf@wheatstone.g10code.de>
 <87lgdsq13p.fsf@wheatstone.g10code.de>
 <87bmeopx7m.fsf@wheatstone.g10code.de>
 <3450890.sTJIORrvAJ@storm.m.i2n>
 <87604wpnca.fsf@wheatstone.g10code.de>
Message-ID: <87604vo1hl.fsf@wheatstone.g10code.de>

On Thu, 12 Apr 2018 15:26, wk at gnupg.org said:

> Please stay tuned for a GPGME fix.  I hope that you can test it too.

I pushed a fix as weel as a new test to the master branch.  I may also
release a 1.10.1 to fix this.  The attached pacth should apply to 1.10.0
and maybe also to 1.9.


Salam-Shalom,

   Werner

-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-core-Tweak-STATUS_FAILURE-handling.patch
Type: text/x-diff
Size: 1399 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180413/e2c8e5d5/attachment-0001.patch>
-------------- 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-users/attachments/20180413/e2c8e5d5/attachment-0001.sig>

From lpapp at kde.org  Fri Apr 13 16:29:50 2018
From: lpapp at kde.org (Laszlo Papp)
Date: Fri, 13 Apr 2018 15:29:50 +0100
Subject: dirmngr timeout
In-Reply-To: <CAOMwXhNRv+tLUk-sv=jJn9-O9isqrc1ZD5=wOkWAj=gjs151zQ@mail.gmail.com>
References: <CAOMwXhPzQzQ-ykGURXRaBXaBQWtuqn9D1QKFZa6Jc=QO0CDhcw@mail.gmail.com>
 <87sh83rv6x.fsf@wheatstone.g10code.de>
 <CAOMwXhPjMcF0fmyPKr2b5d8xtDQJuGWugkf+Y7P-TP48gRRr2w@mail.gmail.com>
 <87604xr25s.fsf@wheatstone.g10code.de>
 <CAOMwXhM=9O2rPA=1A669nP9-Yv4kER4wP+J91FbBsnJi5Wm+LQ@mail.gmail.com>
 <CAOMwXhN6H=L=09mwukdUad7RE5o5=BkgXza8KuZgZdGPhdSxQg@mail.gmail.com>
 <87bmeno2v3.fsf@wheatstone.g10code.de>
 <CAOMwXhNRv+tLUk-sv=jJn9-O9isqrc1ZD5=wOkWAj=gjs151zQ@mail.gmail.com>
Message-ID: <CAOMwXhMxN7PP_JgX9px7ZX08Fgj4VsQr3-o9nuEM82e-r-jurg@mail.gmail.com>

Unfortunately, I am seeing the following issue in docker, still. What would
be the solution to this? I am using 2.2.6.

Step 12/46 : RUN dirmngr < /dev/null && echo "honor_http_proxy" >
/home/nic/.gnupg/dirmngr.conf && touch ~/.gnupg/dirmngr_ldapservers.conf &&
ls -ld ~/.gnupg &&  gpg --keyserver hkp://p80.pool.sks-keyservers.net:80
--recv-key 702353E0F7E48EDB; cd ~ && git clone
https://aur.archlinux.org/lib32-ncurses5-compat-libs.git
lib32-ncurses5-compat-libs && cd lib32-ncurses5-compat-libs && makepkg -f
--noconfirm
 ---> Running in 698013ee8936
dirmngr[8]: error opening '/home/nic/.gnupg/dirmngr_ldapservers.conf': No
such file or directory
dirmngr[8.0]: permanently loaded certificates: 136
dirmngr[8.0]:     runtime cached certificates: 0
dirmngr[8.0]:            trusted certificates: 136 (135,0,0,1)
dirmngr[8.0]: failed to open cache dir file
'/home/nic/.gnupg/crls.d/DIR.txt': No such file or directory
dirmngr[8.0]: creating directory '/home/nic/.gnupg'
dirmngr[8.0]: creating directory '/home/nic/.gnupg/crls.d'
dirmngr[8.0]: new cache dir file '/home/nic/.gnupg/crls.d/DIR.txt' created
# Home: /home/nic/.gnupg
# Config: [none]
OK Dirmngr 2.2.6 at your service
drwx------ 3 nic admin 4096 Apr 13 13:45 /home/nic/.gnupg
gpg: keybox '/home/nic/.gnupg/pubring.kbx' created
gpg: connecting dirmngr at '/home/nic/.gnupg/S.dirmngr' failed: IPC connect
call failed
gpg: keyserver receive failed: No dirmngr
Cloning into 'lib32-ncurses5-compat-libs'...
==> Making package: lib32-ncurses5-compat-libs 6.1-1 (Fri Apr 13 13:46:14
UTC 2018)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Downloading ncurses-6.1.tar.gz...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time
Current
                                 Dload  Upload   Total   Spent    Left
Speed
100 3286k  100 3286k    0     0   221k      0  0:00:14  0:00:14 --:--:--
765k
  -> Downloading ncurses-6.1.tar.gz.sig...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time
Current
                                 Dload  Upload   Total   Spent    Left
Speed
100    72  100    72    0     0      5      0  0:00:14  0:00:12  0:00:02
21
==> Validating source files with md5sums...
    ncurses-6.1.tar.gz ... Passed
    ncurses-6.1.tar.gz.sig ... Skipped
==> Verifying source file signatures with gpg...
    ncurses-6.1.tar.gz ... FAILED (unknown public key 702353E0F7E48EDB)
==> ERROR: One or more PGP signatures could not be verified!
The command '/bin/sh -c dirmngr < /dev/null && echo "honor_http_proxy" >
/home/nic/.gnupg/dirmngr.conf && touch ~/.gnupg/dirmngr_ldapservers.conf &&
ls -ld ~/.gnupg &&  gpg --keyserver hkp://p80.pool.sks-keyservers.net:80
--recv-key 702353E0F7E48EDB; cd ~ && git clone
https://aur.archlinux.org/lib32-ncurses5-compat-libs.git
lib32-ncurses5-compat-libs && cd lib32-ncurses5-compat-libs && makepkg -f
--noconfirm' returned a non-zero code: 1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180413/fffcd596/attachment.html>

From dirk.gottschalk1980 at googlemail.com  Fri Apr 13 16:36:28 2018
From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk)
Date: Fri, 13 Apr 2018 16:36:28 +0200
Subject: Errors while creating an g13 encrypted container.
In-Reply-To: <87in8vo34r.fsf@wheatstone.g10code.de>
References: <1523546184.9629.2.camel@googlemail.com>
 <87sh80nsy0.fsf@wheatstone.g10code.de>
 <1523584157.9664.11.camel@googlemail.com>
 <87in8vo34r.fsf@wheatstone.g10code.de>
Message-ID: <1523630188.4928.4.camel@googlemail.com>

Am Freitag, den 13.04.2018, 11:40 +0200 schrieb Werner Koch:
> On Fri, 13 Apr 2018 03:49, gnupg-users at gnupg.org said:
> 
> > There is neither a command or package named userv, nor a script
> > called
> > 'gnupg-g13-syshelp' in the repositories. The binary g13-syshelp is
> > available.

>   apt-get install userv

In my case it is dnf, but this tool is not available at all in the
repos.


> Frankly, I wonder why that immense useful tool is not part of the
> base
> distribution.

I think it should be available and a dependency for gnupg2 in this
case. Okay, then I'll search for userv and built it myself. And I'll
file a bug report against the gnupg2 rpm package for the not working
feature.

Thanks for your Help.

Regards,
Dirk


-- 
Dirk Gottschalk
Paulusstrasse 6-8
52064 Aachen
Tel.: +49 1573 1152350
-------------- 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-users/attachments/20180413/c18c38d9/attachment.sig>

From tmz at pobox.com  Fri Apr 13 19:04:46 2018
From: tmz at pobox.com (Todd Zullinger)
Date: Fri, 13 Apr 2018 13:04:46 -0400
Subject: Errors while creating an g13 encrypted container.
In-Reply-To: <1523630188.4928.4.camel@googlemail.com>
References: <1523546184.9629.2.camel@googlemail.com>
 <87sh80nsy0.fsf@wheatstone.g10code.de>
 <1523584157.9664.11.camel@googlemail.com>
 <87in8vo34r.fsf@wheatstone.g10code.de>
 <1523630188.4928.4.camel@googlemail.com>
Message-ID: <20180413170446.GY29680@zaya.teonanacatl.net>

Dirk Gottschalk via Gnupg-users wrote:
> Am Freitag, den 13.04.2018, 11:40 +0200 schrieb Werner Koch:
>> On Fri, 13 Apr 2018 03:49, gnupg-users at gnupg.org said:
>> 
>>> There is neither a command or package named userv, nor a script
>>> called
>>> 'gnupg-g13-syshelp' in the repositories. The binary g13-syshelp is
>>> available.
> 
>>   apt-get install userv
> 
> In my case it is dnf, but this tool is not available at all in the
> repos.

I don't see userv available for Arch, Gentoo, openSUSE, or
Slackware either.  It's a very old tool (not that this makes
it bad in any way) which hasn't seen updates in a decade or
so, it appears.

Has userv ever been widely packaged outside of Debian?

-- 
Todd
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
There are no differences but differences of degree between different
degrees of difference and no difference.
    -- William James, under nitrous oxide; 1882

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 543 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180413/14f0f06c/attachment.sig>

From fuzzy_drawrings at protonmail.com  Sat Apr 14 06:14:23 2018
From: fuzzy_drawrings at protonmail.com (FuzzyDrawrings)
Date: Sat, 14 Apr 2018 00:14:23 -0400
Subject: packet syntax
Message-ID: <YvkY9KuUaHGQHIJgudtQHNm1s-q4Pqu86iWFSdp17UFHG_1jNp3C3643CI87moPrO2RfeXWBRA8wu22uJFm4wEV_yW7F9SPC9MfMgGXX8ZI=@protonmail.com>


Edgar Pettijohn wrote:

>  thought I read somewhere that gpg creates version 4 packets.

True. But the version 4 public-key packet specification only tells you what information will be contained in the packet, not the format used for the packet header.

- fuzzy


From thomas.jarosch at intra2net.com  Mon Apr 16 11:44:12 2018
From: thomas.jarosch at intra2net.com (Thomas Jarosch)
Date: Mon, 16 Apr 2018 11:44:12 +0200
Subject: gpgme_op_verify regression with gnupg 2.2.6?
In-Reply-To: <87604vo1hl.fsf@wheatstone.g10code.de>
References: <877epfrm1k.fsf@wheatstone.g10code.de>
 <87604wpnca.fsf@wheatstone.g10code.de> <87604vo1hl.fsf@wheatstone.g10code.de>
Message-ID: <1976901.0Qj8yB0n6C@storm.m.i2n>

Hello Werner,

On Friday, 13 April 2018 12:16:22 CEST Werner Koch wrote:
> On Thu, 12 Apr 2018 15:26, wk at gnupg.org said:
> > Please stay tuned for a GPGME fix.  I hope that you can test it too.
> 
> I pushed a fix as weel as a new test to the master branch.  I may also
> release a 1.10.1 to fix this.  The attached pacth should apply to 1.10.0
> and maybe also to 1.9.

all tests pass fine with the additional fix for gpgme. Thanks!

I'm wondering how to prevent other people from running into this issue.

Could gnupg 2.2.7 detect if gpgme is installed at all and if it is,
make sure it's at least version 1.10.1 / 1.11.0?

Cheers,
Thomas





From wk at gnupg.org  Mon Apr 16 14:14:46 2018
From: wk at gnupg.org (Werner Koch)
Date: Mon, 16 Apr 2018 14:14:46 +0200
Subject: gpgme_op_verify regression with gnupg 2.2.6?
In-Reply-To: <1976901.0Qj8yB0n6C@storm.m.i2n> (Thomas Jarosch's message of
 "Mon, 16 Apr 2018 11:44:12 +0200")
References: <877epfrm1k.fsf@wheatstone.g10code.de>
 <87604wpnca.fsf@wheatstone.g10code.de>
 <87604vo1hl.fsf@wheatstone.g10code.de>
 <1976901.0Qj8yB0n6C@storm.m.i2n>
Message-ID: <87k1t7l555.fsf@wheatstone.g10code.de>

On Mon, 16 Apr 2018 11:44, thomas.jarosch at intra2net.com said:

> I'm wondering how to prevent other people from running into this issue.

I wondered whether I should send out a notice to the announce list but I
doubt that those with problems will read it.  I will add a pointer to
the NEWS entry at gnupg.org with the patch because I assume that will
fast show up in searches.

Given that 1.11.0 is close to a release we decided this morning not to
release a 1.10.1.  GnuPG 2.2.6 is  new enough so that it will be used
only be folks who would also built GPGME from source and thus either the
patch or the forthcoming 1.11.0 should be okay.

> Could gnupg 2.2.7 detect if gpgme is installed at all and if it is,
> make sure it's at least version 1.10.1 / 1.11.0?

:-) - No.


Shalom-Salam,

   Werner

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

From paul.hentze at posteo.de  Mon Apr 16 18:10:03 2018
From: paul.hentze at posteo.de (Paul H. Hentze)
Date: Mon, 16 Apr 2018 18:10:03 +0200
Subject: test
Message-ID: <e7f9a392-8a5a-802a-2bf1-23b743c5ff17@posteo.de>

test

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180416/f64f7726/attachment.html>

From aarcane at aarcane.org  Mon Apr 16 21:02:37 2018
From: aarcane at aarcane.org (Schlacta, Christopher)
Date: Mon, 16 Apr 2018 12:02:37 -0700
Subject: test
In-Reply-To: <e7f9a392-8a5a-802a-2bf1-23b743c5ff17@posteo.de>
References: <e7f9a392-8a5a-802a-2bf1-23b743c5ff17@posteo.de>
Message-ID: <CACpWn9Qd5tAocmKVeJBzqOeMMofGXbo3eoqv+DekLhYVpc53ew@mail.gmail.com>

Error:  Test failure:  Testing protocol disengaged.

On Mon, Apr 16, 2018 at 9:10 AM, Paul H. Hentze <paul.hentze at posteo.de> wrote:
> test
>
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>


From paul.hentze at posteo.de  Tue Apr 17 00:04:11 2018
From: paul.hentze at posteo.de (Paul H. Hentze)
Date: Tue, 17 Apr 2018 00:04:11 +0200
Subject: pinentry problems
Message-ID: <9e948146-eed6-cd3a-ca61-1c9dfb72d76d@posteo.de>

Hey folks,

I'm kinda stuck here with a problem with pinentry and could use some help.
I described the hole problem in detail here:
https://sourceforge.net/p/enigmail/forum/support/thread/eedabe49/

For all who don't like links, I will copy it down below.
Patrick Brunschwig already asked some questions and I tried some more
stuff, which is all documented under the link above, but nothing helped.

Has anybody any idea what to do?

Best wishes


Paul





- - - - - - - - - - - - - - -

Hi folks,

I'm having some problems with GPG right know and hope you can help me.
Debian 9, Thunderbird 52.7.0 (64-bit), Enigmail 2.0.2, GnuPG 2.1.18

I had a harddrive crash recently and had to set up the whole system from
scratch. Because I couldn't do it properly I saved the .gnupg folder und
now copied the whole thing to my new system at the same place. Since
then, I can't use Mailencryption.
I started with the faq page:
https://www.enigmail.net/index.php/en/faq?view=topic&id=14#faqLink_2
Under 'How to analyze' I tried debugging and get
> parseErrorOutputWith: status message:
> gpg: WARNING: unsafe permissions on homedir '/home/giraffenhorde/.gnupg'

So I fixed that with

> chown -R "$USER:$(id -gn)" ~/.gnupg
> chmod 700 ~/.gnupg
> chmod 600 ~/.gnupg/*

from here: https://superuser.com/a/954639


Now my secret keys are all gone.
gpg --list-secret-keys gives no output and in enigmail this doesn't work
either.
When I want to put them in enigmail again, the system can't see them.

I tried gpg --gen-key and got even more

>  gpg: agent_genkey failed: Kein Pinentry
> Key generation failed: Kein Pinentry

I went back to the enigmail Troubleshooting advises above under 'How to
fix it' and tried further, so

1. is good
2. is good, I made this symlink thing, didn't help
3. is good, in my case it's
pinentry-program /usr/bin/pinentry-qt4
4. is good, the gnupg versions are matching
5. I don't need this one, because 4 was good they say
6. here is where I get
ERR 67108949 Kein Pinentry <GPG Agent>
7. when I type in
killall gpg-agent
 gpg-agent --debug-level expert --use-standard-socket --daemon /bin/sh
I get

> gpg-agent --debug-level expert --use-standard-socket --daemon /bin/sh
> gpg-agent[9469]: WARNING: "--use-standard-socket" is an obsolete
option - it has no effect
> gpg-agent[9469]: enabled debug flags: cache ipc
> gpg-agent[9469]: DBG: chan_4 <- OK Pleased to meet you, process 9469
> gpg-agent[9469]: DBG: chan_4 -> BYE
> gpg-agent: a gpg-agent is already running - not starting a new one
> gpg-agent: secmem usage: 0/65536 bytes in 0 blocks

I tried it without all unnecessary code above:
gpg-agent --debug-level expert /bin/sh
and I get

> gpg-agent[9477]: enabled debug flags: cache ipc
> gpg-agent[9477]: DBG: chan_3 <- OK Pleased to meet you, process 9477
> gpg-agent[9477]: gpg-agent running and available
> gpg-agent[9477]: DBG: chan_3 -> BYE
> gpg-agent[9477]: secmem usage: 0/65536 bytes in 0 blocks

So this debugging doesn't work somehow and there is no other terminal
window which opens as they say.

Have you got any idea what to do?
I could really use some help. Thanks in advance.


From dkg at fifthhorseman.net  Tue Apr 17 00:49:21 2018
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 16 Apr 2018 15:49:21 -0700
Subject: pinentry problems
In-Reply-To: <9e948146-eed6-cd3a-ca61-1c9dfb72d76d@posteo.de>
References: <9e948146-eed6-cd3a-ca61-1c9dfb72d76d@posteo.de>
Message-ID: <877ep6rclq.fsf@fifthhorseman.net>

On Tue 2018-04-17 00:04:11 +0200, Paul H. Hentze wrote:
>> gpg: WARNING: unsafe permissions on homedir '/home/giraffenhorde/.gnupg'
>
> So I fixed that with
>
>> chown -R "$USER:$(id -gn)" ~/.gnupg
>> chmod 700 ~/.gnupg
>> chmod 600 ~/.gnupg/*
>
> from here: https://superuser.com/a/954639

this doesn't look right to me.

in particular, it's going to remove the "execute/traverse" permission on
~/.gnupg/private-keys-v1.d/, which means that gpg-agent isn't going to
be able to get a list of all available secret keys.

Probably, you want to do the following (as your normal user account):

    find ~/.gnupg -type d -exec chown 0700 '{}' ';'
    find ~/.gnupg -type f -exec chown 0600 '{}' ';'

if you do that, then you should be able to see some files whose names
end in ".key" in ~/.gnupg/private-keys-v1.d/, like so:

    ls -l ~/.gnupg/private-keys-v1.d/*.key

if that's the case, then i recommend you ask your running gpg-agent to
shut down because it's probably confused:

   gpgconf --kill gpg-agent

a new gpg-agent should start up again afterward as soon as you need it.
you can also try to see which secret keys are available like this:

   gpg --with-keygrip --list-secret-keys

You should see that the keygrips listed match the files found in the
"ls" output above.

If that doesn't work for you, please report back and we'll try to debug
further :)

        --dkg


From paul.hentze at posteo.de  Tue Apr 17 10:52:24 2018
From: paul.hentze at posteo.de (Paul H. Hentze)
Date: Tue, 17 Apr 2018 10:52:24 +0200
Subject: pinentry problems
In-Reply-To: <877ep6rclq.fsf@fifthhorseman.net>
References: <9e948146-eed6-cd3a-ca61-1c9dfb72d76d@posteo.de>
 <877ep6rclq.fsf@fifthhorseman.net>
Message-ID: <83ea5b64-e2bd-ac8d-8631-991685c9afac@posteo.de>



On 17.04.2018 00:49, Daniel Kahn Gillmor wrote:
> On Tue 2018-04-17 00:04:11 +0200, Paul H. Hentze wrote:
>>> gpg: WARNING: unsafe permissions on homedir '/home/giraffenhorde/.gnupg'
>>
>> So I fixed that with
>>
>>> chown -R "$USER:$(id -gn)" ~/.gnupg
>>> chmod 700 ~/.gnupg
>>> chmod 600 ~/.gnupg/*
>>
>> from here: https://superuser.com/a/954639
> 
> this doesn't look right to me.
> 
> in particular, it's going to remove the "execute/traverse" permission on
> ~/.gnupg/private-keys-v1.d/, which means that gpg-agent isn't going to
> be able to get a list of all available secret keys.
> 
> Probably, you want to do the following (as your normal user account):
> 
>     find ~/.gnupg -type d -exec chown 0700 '{}' ';'
>     find ~/.gnupg -type f -exec chown 0600 '{}' ';'
> 
> if you do that, then you should be able to see some files whose names
> end in ".key" in ~/.gnupg/private-keys-v1.d/, like so:
> 
>     ls -l ~/.gnupg/private-keys-v1.d/*.key
> 
> if that's the case, then i recommend you ask your running gpg-agent to
> shut down because it's probably confused:
> 
>    gpgconf --kill gpg-agent
> 
> a new gpg-agent should start up again afterward as soon as you need it.
> you can also try to see which secret keys are available like this:
> 
>    gpg --with-keygrip --list-secret-keys
> 
> You should see that the keygrips listed match the files found in the
> "ls" output above.
> 
> If that doesn't work for you, please report back and we'll try to debug
> further :)
> 
>         --dkg
> 

Actually those commands
>     find ~/.gnupg -type d -exec chown 0700 '{}' ';'
>     find ~/.gnupg -type f -exec chown 0600 '{}' ';'

didn't work.
The terminal responded: "chown: The owner of data XXX is going to be
changed. This is not allowed." and it did that with every file in that
folder.

The rest of the commands are finde and I see the secret keys and the
matching keygrips.

Paul


From kristian.fiskerstrand at sumptuouscapital.com  Tue Apr 17 11:11:22 2018
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Tue, 17 Apr 2018 11:11:22 +0200
Subject: pinentry problems
In-Reply-To: <83ea5b64-e2bd-ac8d-8631-991685c9afac@posteo.de>
References: <9e948146-eed6-cd3a-ca61-1c9dfb72d76d@posteo.de>
 <877ep6rclq.fsf@fifthhorseman.net>
 <83ea5b64-e2bd-ac8d-8631-991685c9afac@posteo.de>
Message-ID: <a370c6cf-c2bc-02d1-625e-170b3b771e2b@sumptuouscapital.com>

On 04/17/2018 10:52 AM, Paul H. Hentze wrote:
> Actually those commands
>>     find ~/.gnupg -type d -exec chown 0700 '{}' ';'
>>     find ~/.gnupg -type f -exec chown 0600 '{}' ';'
> didn't work.
> The terminal responded: "chown: The owner of data XXX is going to be
> changed. This is not allowed." and it did that with every file in that
> folder.

Seems like a mixup of chmod and chown there, although make sure the user
is correct as well.

-- 
----------------------------
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
----------------------------
Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
----------------------------
"History repeats itself; historians repeat each other"
(Philip Guedalla)

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

From yuki.mururu at gmail.com  Tue Apr 17 10:55:26 2018
From: yuki.mururu at gmail.com (Yuki Ito)
Date: Tue, 17 Apr 2018 17:55:26 +0900
Subject: Speedo build error on GnuPG 2.2.6
Message-ID: <CAFN=DctxkTYazjQfp_TSNYcdw8gmPxzd5BOOMtz3uuXAju0WtA@mail.gmail.com>

Hi,

I've tried speedo build on GnuPG 2.2.6, but I've got an error like this:

$ make -f build-aux/speedo.mk native
make -f /gnupg-2.2.6/build-aux/speedo.mk UPD_SWDB=1 TARGETOS=native
WHAT=release WITH_GUI=0 all
make[1]: Entering directory '/gnupg-2.2.6'
gpgv: Signature made Fri Apr 13 08:47:30 2018 UTC using RSA key ID ---
gpgv: Good signature from "---"
GnuPG 2.1 version missing in swdb.lst!
/gnupg-2.2.6/build-aux/speedo.mk:278: *** Error getting GnuPG software
version database.  Stop.
make[1]: Leaving directory '/gnupg-2.2.6'
build-aux/speedo.mk:73: recipe for target 'native' failed
make: *** [native] Error 2

The build script verifies GnuPG version based on gnupg21_ver in swdb.lst:
https://dev.gnupg.org/source/gnupg/browse/master/build-aux/getswdb.sh;
6fbe2ddbaf5123ae444c95fdf8da67840f794c76$178

But gnupg21_ver seems to be deleted by this commit:
https://dev.gnupg.org/rD2094fc1631aca2659732e0b28e03012e2dc67127

Regards,
Yuki
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180417/50e1e029/attachment.html>

From yuki.mururu at gmail.com  Tue Apr 17 10:45:33 2018
From: yuki.mururu at gmail.com (Yuki Ito)
Date: Tue, 17 Apr 2018 17:45:33 +0900
Subject: speedo build error on 2.2.6
Message-ID: <CAFN=DcsZ3_4MVbqoX0_TK55nRwTMbeYgzzyV_vQ-00Bt_Vb_yQ@mail.gmail.com>

Hi,

I've tried speedo build on GnuPG 2.2.6, but I've got an error like this:

$ make -f build-aux/speedo.mk native
make -f /gnupg-2.2.6/build-aux/speedo.mk UPD_SWDB=1 TARGETOS=native
WHAT=release WITH_GUI=0 all
make[1]: Entering directory '/gnupg-2.2.6'
gpgv: Signature made Fri Apr 13 08:47:30 2018 UTC using RSA key ID ---
gpgv: Good signature from "---"
GnuPG 2.1 version missing in swdb.lst!
/gnupg-2.2.6/build-aux/speedo.mk:278: *** Error getting GnuPG software
version database.  Stop.
make[1]: Leaving directory '/gnupg-2.2.6'
build-aux/speedo.mk:73: recipe for target 'native' failed
make: *** [native] Error 2

The build script verifies GnuPG version based on gnupg21_ver in swdb.lst:
https://dev.gnupg.org/source/gnupg/browse/master/build-aux/getswdb.sh;6fbe2ddbaf5123ae444c95fdf8da67840f794c76$178

But gnupg21_ver seems to be deleted by this commit:
https://dev.gnupg.org/rD2094fc1631aca2659732e0b28e03012e2dc67127

Regards,
Yuki
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180417/29297400/attachment.html>

From aheinecke at intevation.de  Tue Apr 17 14:19:51 2018
From: aheinecke at intevation.de (Andre Heinecke)
Date: Tue, 17 Apr 2018 14:19:51 +0200
Subject: Speedo build error on GnuPG 2.2.6
In-Reply-To: <CAFN=DctxkTYazjQfp_TSNYcdw8gmPxzd5BOOMtz3uuXAju0WtA@mail.gmail.com>
References: <CAFN=DctxkTYazjQfp_TSNYcdw8gmPxzd5BOOMtz3uuXAju0WtA@mail.gmail.com>
Message-ID: <8638195.zoAjWW0RRb@esus>

Hi,

thanks for trying out up to date GnuPG :-)

On Tuesday, April 17, 2018 5:55:26 PM CEST Yuki Ito wrote:
> The build script verifies GnuPG version based on gnupg21_ver in swdb.lst:
> https://dev.gnupg.org/source/gnupg/browse/master/build-aux/getswdb.sh;
> 6fbe2ddbaf5123ae444c95fdf8da67840f794c76$178
> 
> But gnupg21_ver seems to be deleted by this commit:
> https://dev.gnupg.org/rD2094fc1631aca2659732e0b28e03012e2dc67127

I noticed that, too and fixed it in the stable branch (should be merged into 
master soon) 

https://dev.gnupg.org/rG327fece0aed2c9974659c72304f9fd1f461d460c

Can you try to cherry pick that commit and see if it works?

When building from GIT I also use SELFCHECK=0 to avoid version problems.

What works for me is:

	 /usr/bin/make -f build-aux/speedo.mk native \
		 INSTALL_PREFIX=/opt/gnupg SELFCHECK=0

That works for me.

Best Regards,
Andre

-- 
Andre Heinecke |  ++49-541-335083-262  | http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180417/9758bcba/attachment.sig>

From yuki.mururu at gmail.com  Tue Apr 17 15:14:33 2018
From: yuki.mururu at gmail.com (Yuki Ito)
Date: Tue, 17 Apr 2018 22:14:33 +0900
Subject: Speedo build error on GnuPG 2.2.6
In-Reply-To: <8638195.zoAjWW0RRb@esus>
References: <CAFN=DctxkTYazjQfp_TSNYcdw8gmPxzd5BOOMtz3uuXAju0WtA@mail.gmail.com>
 <8638195.zoAjWW0RRb@esus>
Message-ID: <CAFN=DcvH+oR9N1MwnMZu9pFcctTtN8b2cEqkf4QqFqAm4FB--g@mail.gmail.com>

Hi Andre,

Great, the commit works well. And as far as I see the source code, SELFCHECK=0
seems better for my case this time. I would use it as a workaround.
I look forward to new version release fixing this issue.

Thanks,
Yuki

2018-04-17 21:19 GMT+09:00 Andre Heinecke <aheinecke at intevation.de>:

> Hi,
>
> thanks for trying out up to date GnuPG :-)
>
> On Tuesday, April 17, 2018 5:55:26 PM CEST Yuki Ito wrote:
> > The build script verifies GnuPG version based on gnupg21_ver in swdb.lst:
> > https://dev.gnupg.org/source/gnupg/browse/master/build-aux/getswdb.sh;
> > 6fbe2ddbaf5123ae444c95fdf8da67840f794c76$178
> >
> > But gnupg21_ver seems to be deleted by this commit:
> > https://dev.gnupg.org/rD2094fc1631aca2659732e0b28e03012e2dc67127
>
> I noticed that, too and fixed it in the stable branch (should be merged
> into
> master soon)
>
> https://dev.gnupg.org/rG327fece0aed2c9974659c72304f9fd1f461d460c
>
> Can you try to cherry pick that commit and see if it works?
>
> When building from GIT I also use SELFCHECK=0 to avoid version problems.
>
> What works for me is:
>
>          /usr/bin/make -f build-aux/speedo.mk native \
>                  INSTALL_PREFIX=/opt/gnupg SELFCHECK=0
>
> That works for me.
>
> Best Regards,
> Andre
>
> --
> Andre Heinecke |  ++49-541-335083-262  | http://www.intevation.de/
> Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B
> 18998
> Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner




-- 
Yuki Ito
yuki.mururu at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180417/37ccc208/attachment.html>

From dkg at fifthhorseman.net  Tue Apr 17 17:48:57 2018
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 17 Apr 2018 08:48:57 -0700
Subject: pinentry problems
In-Reply-To: <a370c6cf-c2bc-02d1-625e-170b3b771e2b@sumptuouscapital.com>
References: <9e948146-eed6-cd3a-ca61-1c9dfb72d76d@posteo.de>
 <877ep6rclq.fsf@fifthhorseman.net>
 <83ea5b64-e2bd-ac8d-8631-991685c9afac@posteo.de>
 <a370c6cf-c2bc-02d1-625e-170b3b771e2b@sumptuouscapital.com>
Message-ID: <87fu3tq1ee.fsf@fifthhorseman.net>

On Tue 2018-04-17 11:11:22 +0200, Kristian Fiskerstrand wrote:
> On 04/17/2018 10:52 AM, Paul H. Hentze wrote:
>> Actually those commands
>>>     find ~/.gnupg -type d -exec chown 0700 '{}' ';'
>>>     find ~/.gnupg -type f -exec chown 0600 '{}' ';'
>> didn't work.
>> The terminal responded: "chown: The owner of data XXX is going to be
>> changed. This is not allowed." and it did that with every file in that
>> folder.
>
> Seems like a mixup of chmod and chown there, although make sure the user
> is correct as well.

yep, sorry, that should have been "chmod", not "chown" -- my mistake!

     --dkg


From kristian.fiskerstrand at sumptuouscapital.com  Tue Apr 17 19:34:43 2018
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Tue, 17 Apr 2018 19:34:43 +0200
Subject: gpgme_op_verify regression with gnupg 2.2.6?
In-Reply-To: <87k1t7l555.fsf@wheatstone.g10code.de>
References: <877epfrm1k.fsf@wheatstone.g10code.de>
 <87604wpnca.fsf@wheatstone.g10code.de> <87604vo1hl.fsf@wheatstone.g10code.de>
 <1976901.0Qj8yB0n6C@storm.m.i2n> <87k1t7l555.fsf@wheatstone.g10code.de>
Message-ID: <7ac1badc-8cd2-fa1e-2d78-52b6d24e0d44@sumptuouscapital.com>

On 04/16/2018 02:14 PM, Werner Koch wrote:
>> Could gnupg 2.2.7 detect if gpgme is installed at all and if it is,
>> make sure it's at least version 1.10.1 / 1.11.0?
> :-) - No.

Speaking for Gentoo we can do this on distribution level by adding a
blocker on the lower version if needed.

-- 
----------------------------
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
----------------------------
Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
----------------------------
"History doesn't repeat itself, but it does rhyme."
(Mark Twain)

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

From paul.hentze at posteo.de  Tue Apr 17 22:48:57 2018
From: paul.hentze at posteo.de (Paul H. Hentze)
Date: Tue, 17 Apr 2018 22:48:57 +0200
Subject: pinentry problems
In-Reply-To: <87fu3tq1ee.fsf@fifthhorseman.net>
References: <9e948146-eed6-cd3a-ca61-1c9dfb72d76d@posteo.de>
 <877ep6rclq.fsf@fifthhorseman.net>
 <83ea5b64-e2bd-ac8d-8631-991685c9afac@posteo.de>
 <a370c6cf-c2bc-02d1-625e-170b3b771e2b@sumptuouscapital.com>
 <87fu3tq1ee.fsf@fifthhorseman.net>
Message-ID: <685e236c-744a-5278-f840-098ca1eef2e4@posteo.de>



On 17.04.2018 17:48, Daniel Kahn Gillmor wrote:
> On Tue 2018-04-17 11:11:22 +0200, Kristian Fiskerstrand wrote:
>> On 04/17/2018 10:52 AM, Paul H. Hentze wrote:
>>> Actually those commands
>>>>     find ~/.gnupg -type d -exec chown 0700 '{}' ';'
>>>>     find ~/.gnupg -type f -exec chown 0600 '{}' ';'
>>> didn't work.
>>> The terminal responded: "chown: The owner of data XXX is going to be
>>> changed. This is not allowed." and it did that with every file in that
>>> folder.
>>
>> Seems like a mixup of chmod and chown there, although make sure the user
>> is correct as well.
> 
> yep, sorry, that should have been "chmod", not "chown" -- my mistake!
> 
>      --dkg
> 
Ok, it did work with the chmod command.
Have you got any further ideas?

Paul


From paul.hentze at posteo.de  Tue Apr 17 22:50:04 2018
From: paul.hentze at posteo.de (Paul H. Hentze)
Date: Tue, 17 Apr 2018 22:50:04 +0200
Subject: pinentry problems
In-Reply-To: <87fu3tq1ee.fsf@fifthhorseman.net>
References: <9e948146-eed6-cd3a-ca61-1c9dfb72d76d@posteo.de>
 <877ep6rclq.fsf@fifthhorseman.net>
 <83ea5b64-e2bd-ac8d-8631-991685c9afac@posteo.de>
 <a370c6cf-c2bc-02d1-625e-170b3b771e2b@sumptuouscapital.com>
 <87fu3tq1ee.fsf@fifthhorseman.net>
Message-ID: <6070cb27-7dc4-61b0-7de0-6a0894f6d1dd@posteo.de>


On 17.04.2018 17:48, Daniel Kahn Gillmor wrote:
> On Tue 2018-04-17 11:11:22 +0200, Kristian Fiskerstrand wrote:
>> On 04/17/2018 10:52 AM, Paul H. Hentze wrote:
>>> Actually those commands
>>>>     find ~/.gnupg -type d -exec chown 0700 '{}' ';'
>>>>     find ~/.gnupg -type f -exec chown 0600 '{}' ';'
>>> didn't work.
>>> The terminal responded: "chown: The owner of data XXX is going to be
>>> changed. This is not allowed." and it did that with every file in that
>>> folder.
>>
>> Seems like a mixup of chmod and chown there, although make sure the user
>> is correct as well.
> 
> yep, sorry, that should have been "chmod", not "chown" -- my mistake!
> 
>      --dkg
> 
Ok, it did work with the chmod command.
Have you got any further ideas?

Paul



From kristian.fiskerstrand at sumptuouscapital.com  Tue Apr 17 22:50:53 2018
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Tue, 17 Apr 2018 22:50:53 +0200
Subject: pinentry problems
In-Reply-To: <685e236c-744a-5278-f840-098ca1eef2e4@posteo.de>
References: <9e948146-eed6-cd3a-ca61-1c9dfb72d76d@posteo.de>
 <877ep6rclq.fsf@fifthhorseman.net>
 <83ea5b64-e2bd-ac8d-8631-991685c9afac@posteo.de>
 <a370c6cf-c2bc-02d1-625e-170b3b771e2b@sumptuouscapital.com>
 <87fu3tq1ee.fsf@fifthhorseman.net>
 <685e236c-744a-5278-f840-098ca1eef2e4@posteo.de>
Message-ID: <abf63198-5c14-5cab-a1f0-d149c03ec4d0@sumptuouscapital.com>

On 04/17/2018 10:48 PM, Paul H. Hentze wrote:
> 
> 
> On 17.04.2018 17:48, Daniel Kahn Gillmor wrote:
>> On Tue 2018-04-17 11:11:22 +0200, Kristian Fiskerstrand wrote:
>>> On 04/17/2018 10:52 AM, Paul H. Hentze wrote:
>>>> Actually those commands
>>>>>     find ~/.gnupg -type d -exec chown 0700 '{}' ';'
>>>>>     find ~/.gnupg -type f -exec chown 0600 '{}' ';'
>>>> didn't work.
>>>> The terminal responded: "chown: The owner of data XXX is going to be
>>>> changed. This is not allowed." and it did that with every file in that
>>>> folder.
>>>
>>> Seems like a mixup of chmod and chown there, although make sure the user
>>> is correct as well.
>>
>> yep, sorry, that should have been "chmod", not "chown" -- my mistake!
>>
>>      --dkg
>>
> Ok, it did work with the chmod command.
> Have you got any further ideas?

remember to restart gpg-agent after doing that, gpgconf --kill gpg-agent


-- 
----------------------------
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
----------------------------
Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
----------------------------
Acta est fabula
So ends the story

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

From paul.hentze at posteo.de  Tue Apr 17 23:05:44 2018
From: paul.hentze at posteo.de (Paul H. Hentze)
Date: Tue, 17 Apr 2018 23:05:44 +0200
Subject: pinentry problems
In-Reply-To: <abf63198-5c14-5cab-a1f0-d149c03ec4d0@sumptuouscapital.com>
References: <9e948146-eed6-cd3a-ca61-1c9dfb72d76d@posteo.de>
 <877ep6rclq.fsf@fifthhorseman.net>
 <83ea5b64-e2bd-ac8d-8631-991685c9afac@posteo.de>
 <a370c6cf-c2bc-02d1-625e-170b3b771e2b@sumptuouscapital.com>
 <87fu3tq1ee.fsf@fifthhorseman.net>
 <685e236c-744a-5278-f840-098ca1eef2e4@posteo.de>
 <abf63198-5c14-5cab-a1f0-d149c03ec4d0@sumptuouscapital.com>
Message-ID: <3ec54717-794a-02e8-8432-678cf8bde5bf@posteo.de>



On 17.04.2018 22:50, Kristian Fiskerstrand wrote:
> On 04/17/2018 10:48 PM, Paul H. Hentze wrote:
>>
>>
>> On 17.04.2018 17:48, Daniel Kahn Gillmor wrote:
>>> On Tue 2018-04-17 11:11:22 +0200, Kristian Fiskerstrand wrote:
>>>> On 04/17/2018 10:52 AM, Paul H. Hentze wrote:
>>>>> Actually those commands
>>>>>>     find ~/.gnupg -type d -exec chown 0700 '{}' ';'
>>>>>>     find ~/.gnupg -type f -exec chown 0600 '{}' ';'
>>>>> didn't work.
>>>>> The terminal responded: "chown: The owner of data XXX is going to be
>>>>> changed. This is not allowed." and it did that with every file in that
>>>>> folder.
>>>>
>>>> Seems like a mixup of chmod and chown there, although make sure the user
>>>> is correct as well.
>>>
>>> yep, sorry, that should have been "chmod", not "chown" -- my mistake!
>>>
>>>      --dkg
>>>
>> Ok, it did work with the chmod command.
>> Have you got any further ideas?
> 
> remember to restart gpg-agent after doing that, gpgconf --kill gpg-agent
> 
> 
I did. This works fine as I asses that.
Now I'm still stuck with the pinentry problem.


From lpapp at kde.org  Wed Apr 18 10:36:12 2018
From: lpapp at kde.org (Laszlo Papp)
Date: Wed, 18 Apr 2018 09:36:12 +0100
Subject: dirmngr timeout
In-Reply-To: <CAOMwXhMxN7PP_JgX9px7ZX08Fgj4VsQr3-o9nuEM82e-r-jurg@mail.gmail.com>
References: <CAOMwXhPzQzQ-ykGURXRaBXaBQWtuqn9D1QKFZa6Jc=QO0CDhcw@mail.gmail.com>
 <87sh83rv6x.fsf@wheatstone.g10code.de>
 <CAOMwXhPjMcF0fmyPKr2b5d8xtDQJuGWugkf+Y7P-TP48gRRr2w@mail.gmail.com>
 <87604xr25s.fsf@wheatstone.g10code.de>
 <CAOMwXhM=9O2rPA=1A669nP9-Yv4kER4wP+J91FbBsnJi5Wm+LQ@mail.gmail.com>
 <CAOMwXhN6H=L=09mwukdUad7RE5o5=BkgXza8KuZgZdGPhdSxQg@mail.gmail.com>
 <87bmeno2v3.fsf@wheatstone.g10code.de>
 <CAOMwXhNRv+tLUk-sv=jJn9-O9isqrc1ZD5=wOkWAj=gjs151zQ@mail.gmail.com>
 <CAOMwXhMxN7PP_JgX9px7ZX08Fgj4VsQr3-o9nuEM82e-r-jurg@mail.gmail.com>
Message-ID: <CAOMwXhOy29vgT-Q1cp7ppRCFHHn7RiV_V0i-WuZKOpCz5C0Znw@mail.gmail.com>

I still have not managed to solve this. Does anyone have an idea?

On Fri, Apr 13, 2018 at 3:29 PM, Laszlo Papp <lpapp at kde.org> wrote:

> Unfortunately, I am seeing the following issue in docker, still. What
> would be the solution to this? I am using 2.2.6.
>
> Step 12/46 : RUN dirmngr < /dev/null && echo "honor_http_proxy" >
> /home/nic/.gnupg/dirmngr.conf && touch ~/.gnupg/dirmngr_ldapservers.conf
> && ls -ld ~/.gnupg &&  gpg --keyserver hkp://p80.pool.sks-keyservers.
> net:80 --recv-key 702353E0F7E48EDB; cd ~ && git clone
> https://aur.archlinux.org/lib32-ncurses5-compat-libs.git
> lib32-ncurses5-compat-libs && cd lib32-ncurses5-compat-libs && makepkg -f
> --noconfirm
>  ---> Running in 698013ee8936
> dirmngr[8]: error opening '/home/nic/.gnupg/dirmngr_ldapservers.conf': No
> such file or directory
> dirmngr[8.0]: permanently loaded certificates: 136
> dirmngr[8.0]:     runtime cached certificates: 0
> dirmngr[8.0]:            trusted certificates: 136 (135,0,0,1)
> dirmngr[8.0]: failed to open cache dir file '/home/nic/.gnupg/crls.d/DIR.txt':
> No such file or directory
> dirmngr[8.0]: creating directory '/home/nic/.gnupg'
> dirmngr[8.0]: creating directory '/home/nic/.gnupg/crls.d'
> dirmngr[8.0]: new cache dir file '/home/nic/.gnupg/crls.d/DIR.txt' created
> # Home: /home/nic/.gnupg
> # Config: [none]
> OK Dirmngr 2.2.6 at your service
> drwx------ 3 nic admin 4096 Apr 13 13:45 /home/nic/.gnupg
> gpg: keybox '/home/nic/.gnupg/pubring.kbx' created
> gpg: connecting dirmngr at '/home/nic/.gnupg/S.dirmngr' failed: IPC
> connect call failed
> gpg: keyserver receive failed: No dirmngr
> Cloning into 'lib32-ncurses5-compat-libs'...
> ==> Making package: lib32-ncurses5-compat-libs 6.1-1 (Fri Apr 13 13:46:14
> UTC 2018)
> ==> Checking runtime dependencies...
> ==> Checking buildtime dependencies...
> ==> Retrieving sources...
>   -> Downloading ncurses-6.1.tar.gz...
>   % Total    % Received % Xferd  Average Speed   Time    Time     Time
> Current
>                                  Dload  Upload   Total   Spent    Left
> Speed
> 100 3286k  100 3286k    0     0   221k      0  0:00:14  0:00:14 --:--:--
> 765k
>   -> Downloading ncurses-6.1.tar.gz.sig...
>   % Total    % Received % Xferd  Average Speed   Time    Time     Time
> Current
>                                  Dload  Upload   Total   Spent    Left
> Speed
> 100    72  100    72    0     0      5      0  0:00:14  0:00:12  0:00:02
>   21
> ==> Validating source files with md5sums...
>     ncurses-6.1.tar.gz ... Passed
>     ncurses-6.1.tar.gz.sig ... Skipped
> ==> Verifying source file signatures with gpg...
>     ncurses-6.1.tar.gz ... FAILED (unknown public key 702353E0F7E48EDB)
> ==> ERROR: One or more PGP signatures could not be verified!
> The command '/bin/sh -c dirmngr < /dev/null && echo "honor_http_proxy" >
> /home/nic/.gnupg/dirmngr.conf && touch ~/.gnupg/dirmngr_ldapservers.conf
> && ls -ld ~/.gnupg &&  gpg --keyserver hkp://p80.pool.sks-keyservers.
> net:80 --recv-key 702353E0F7E48EDB; cd ~ && git clone
> https://aur.archlinux.org/lib32-ncurses5-compat-libs.git
> lib32-ncurses5-compat-libs && cd lib32-ncurses5-compat-libs && makepkg -f
> --noconfirm' returned a non-zero code: 1
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180418/c8a4c0ab/attachment.html>

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

Hello!

We are pleased to announce version 1.11.0 of GPGME.

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

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


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

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

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

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

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

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

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

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

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

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

 * New convenience constant GPGME_KEYLIST_MODE_LOCATE.

 * Improved the Python documentation.

 * Fixed a potential regression with GnuPG 2.2.6 or later.

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

 * Various minor fixes.


Download
========

You may download this library and its OpenPGP signature from:

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

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

  17772bf86eef70ab0c77cbb6df0b90f002af0030  gpgme-1.11.0.tar.bz2

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


Thanks
======

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

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


Happy hacking,

  Your GnuPG hackers



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

p.p.s 
List of Release Signing Keys:

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

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

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

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

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

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

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

From sgarlick at gmail.com  Wed Apr 18 15:46:36 2018
From: sgarlick at gmail.com (sgarlick at gmail.com)
Date: Wed, 18 Apr 2018 23:16:36 +0930
Subject: [Announce] GnuPG 2.2.6 released
In-Reply-To: <877epfrm1k.fsf@wheatstone.g10code.de>
References: <877epfrm1k.fsf@wheatstone.g10code.de>
Message-ID: <CAKKxzKd11RNUp-+cRBPvhtzdJ3Pd5_vUdM1mjPUaWCvVd0UgLw@mail.gmail.com>

unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180418/0f86e331/attachment-0001.html>

From dkg at fifthhorseman.net  Wed Apr 18 21:28:13 2018
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 18 Apr 2018 12:28:13 -0700
Subject: dirmngr timeout
In-Reply-To: <CAOMwXhNRv+tLUk-sv=jJn9-O9isqrc1ZD5=wOkWAj=gjs151zQ@mail.gmail.com>
References: <CAOMwXhPzQzQ-ykGURXRaBXaBQWtuqn9D1QKFZa6Jc=QO0CDhcw@mail.gmail.com>
 <87sh83rv6x.fsf@wheatstone.g10code.de>
 <CAOMwXhPjMcF0fmyPKr2b5d8xtDQJuGWugkf+Y7P-TP48gRRr2w@mail.gmail.com>
 <87604xr25s.fsf@wheatstone.g10code.de>
 <CAOMwXhM=9O2rPA=1A669nP9-Yv4kER4wP+J91FbBsnJi5Wm+LQ@mail.gmail.com>
 <CAOMwXhN6H=L=09mwukdUad7RE5o5=BkgXza8KuZgZdGPhdSxQg@mail.gmail.com>
 <87bmeno2v3.fsf@wheatstone.g10code.de>
 <CAOMwXhNRv+tLUk-sv=jJn9-O9isqrc1ZD5=wOkWAj=gjs151zQ@mail.gmail.com>
Message-ID: <87efjcnwky.fsf@fifthhorseman.net>

On Fri 2018-04-13 11:00:59 +0100, Laszlo Papp wrote:
> Yes, I meant to reply yesterday after solving this.
>
> systemd --user import-environment http_proxy
>
> is what I used.

i think you mean:

    systemctl --user import-environment http_proxy

Please read the "Environment Commands" section of systemctl(1) for more
details.

Another alternative is to add an Environment= directive to
dirmngr.service -- you can do this with:

    systemctl --user edit dirmngr.service

or simply by putting the following two lines in
~/.config/systemd/user/dirmngr.service.d/proxy.conf :

    [Service]
    Environment=http_proxy=http://192.0.2.8:3128


hth,

        --dkg


From dkg at fifthhorseman.net  Wed Apr 18 22:02:19 2018
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 18 Apr 2018 13:02:19 -0700
Subject: dirmngr timeout
In-Reply-To: <CAOMwXhMxN7PP_JgX9px7ZX08Fgj4VsQr3-o9nuEM82e-r-jurg@mail.gmail.com>
References: <CAOMwXhPzQzQ-ykGURXRaBXaBQWtuqn9D1QKFZa6Jc=QO0CDhcw@mail.gmail.com>
 <87sh83rv6x.fsf@wheatstone.g10code.de>
 <CAOMwXhPjMcF0fmyPKr2b5d8xtDQJuGWugkf+Y7P-TP48gRRr2w@mail.gmail.com>
 <87604xr25s.fsf@wheatstone.g10code.de>
 <CAOMwXhM=9O2rPA=1A669nP9-Yv4kER4wP+J91FbBsnJi5Wm+LQ@mail.gmail.com>
 <CAOMwXhN6H=L=09mwukdUad7RE5o5=BkgXza8KuZgZdGPhdSxQg@mail.gmail.com>
 <87bmeno2v3.fsf@wheatstone.g10code.de>
 <CAOMwXhNRv+tLUk-sv=jJn9-O9isqrc1ZD5=wOkWAj=gjs151zQ@mail.gmail.com>
 <CAOMwXhMxN7PP_JgX9px7ZX08Fgj4VsQr3-o9nuEM82e-r-jurg@mail.gmail.com>
Message-ID: <87bmegnv04.fsf@fifthhorseman.net>

Hi Laszlo--

I'm afraid we don't know the details of how your docker instance is set
up; which versions of which packages you have installed inside docker
vs. outside of docker, what's bind-mounted, what the networking
constraints are in place.  this makes debugging remotely a bit more
difficult.

On Fri 2018-04-13 15:29:50 +0100, Laszlo Papp wrote:
> gpg: connecting dirmngr at '/home/nic/.gnupg/S.dirmngr' failed: IPC connect call failed
> gpg: keyserver receive failed: No dirmngr

if a standard user runtime dir is mounted on /run/user/$UID , the
dirmngr socket could be mounted there.  It sounds like that is probably
not mounted, so gpg is falling back to the socket location in the home
directory.

but if no dirmngr is running listening on the expected socket, then gpg
normally tries to launch it itself.

for example, i'd expect to see the following:

    gpg-connect-agent: no running Dirmngr - starting '/usr/bin/dirmngr'
    gpg-connect-agent: waiting for the dirmngr to come up ... (5s)
    gpg-connect-agent: waiting for the dirmngr to come up ... (4s)
    gpg-connect-agent: connection to dirmngr established

But i don't see that in your logs.  What version of GnuPG is installed?

how did dirmnger get installed on this docker system?  how did gpg
itself get installed?

what is the output of:

     gpgconf --list-dirs

(within the docker instance, that is)

hth,

        --dkg


From dkg at fifthhorseman.net  Wed Apr 18 22:09:50 2018
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 18 Apr 2018 13:09:50 -0700
Subject: pinentry problems
In-Reply-To: <3ec54717-794a-02e8-8432-678cf8bde5bf@posteo.de>
References: <9e948146-eed6-cd3a-ca61-1c9dfb72d76d@posteo.de>
 <877ep6rclq.fsf@fifthhorseman.net>
 <83ea5b64-e2bd-ac8d-8631-991685c9afac@posteo.de>
 <a370c6cf-c2bc-02d1-625e-170b3b771e2b@sumptuouscapital.com>
 <87fu3tq1ee.fsf@fifthhorseman.net>
 <685e236c-744a-5278-f840-098ca1eef2e4@posteo.de>
 <abf63198-5c14-5cab-a1f0-d149c03ec4d0@sumptuouscapital.com>
 <3ec54717-794a-02e8-8432-678cf8bde5bf@posteo.de>
Message-ID: <878t9knunl.fsf@fifthhorseman.net>

On Tue 2018-04-17 23:05:44 +0200, Paul H. Hentze wrote:
> I did. This works fine as I asses that.

I'm glad it's working now.

> Now I'm still stuck with the pinentry problem.

can you explain the pinentry problem you're seeing?  I'm afraid the bad
ownership of your files was distracting from any other problems you were
reporting.

One simple way to test pinentry (without gpg or gpg-agent in the mix)
is:

     echo getpin | pinentry

that should show you a dialog box that prompts you for a password.  you
can put in whatever you like, and it should be emitted on the console
where you ran the above command.

      --dkg


From evan at eklitzke.org  Thu Apr 19 04:12:39 2018
From: evan at eklitzke.org (Evan Klitzke)
Date: Wed, 18 Apr 2018 19:12:39 -0700
Subject: Semantics of WOT and Subkeys
Message-ID: <87lgdkhrl4.fsf@eklitzke.org>

I am trying to understand the semantics of how GnuPG's WOT model 
interacts with subkeys. This is a pretty basic question, so feel free to 
direct me to existing resources if there are any; there must be 
something written on this topic already, but I failed to find anything.

Suppose Alice and Bob want to start using PGP, so they both install GPG 
and create keypairs. At this point in time they both sign each other's 
keys, meaning that they sign each other's master/certification key.

Later Alice learns about subkeys, so she creates a new signing subkey 
for signing her mail/git commits/whatever. How does this work when Bob 
sees the new subkey? Does Bob/GPG treat the signing subkey to be just as 
trusted as Alice's master key? Or is it somehow treated as less trusted, 
since it's one step away from the master key?

Similarly, let's say Carol also starts using PGP, and Alice signs 
Carol's key. From Bob's point of view, is there a difference which key 
(the master key or the subkey) Alice used when signing Carol's key?

--
Evan Klitzke                      pgp: 0x157EFCACBC648422
e: evan at eklitzke.org              w: https://eklitzke.org


From dgouttegattat at incenp.org  Thu Apr 19 10:16:46 2018
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Thu, 19 Apr 2018 09:16:46 +0100
Subject: Semantics of WOT and Subkeys
In-Reply-To: <87lgdkhrl4.fsf@eklitzke.org>
References: <87lgdkhrl4.fsf@eklitzke.org>
Message-ID: <677f5417-3527-c4c9-bb03-cb79ab88cdc6@incenp.org>

Hi,

On 04/19/2018 03:12 AM, Evan Klitzke wrote:
> Later Alice learns about subkeys, so she creates a new signing subkey 
> for signing her mail/git commits/whatever. How does this work when Bob 
> sees the new subkey?

For most purposes, the use of subkeys is "transparent" from the user's 
point of view. Users only need to be concerned about their 
correspondants' master (or primary) key.

In particular :

> Does Bob/GPG treat the signing subkey to be just as trusted as Alice's master key?

Yes [1].


> From Bob's point of view, is there a difference which key 
> (the master key or the subkey) Alice used when signing Carol's key?

Unless Alice played with GnuPG's source code, she can only use her 
master key to sign Carol's key.

Signing a key ("certify", to use the proper term), in OpenPGP, is a 
special form of signing which requires a key with the "Certify" 
capability instead of the "Signing" capability. Only the master key has 
that capability. As far as I know it is not possible to generate a 
certification-capable subkey.

Hope that helps,

Damien


[1] Assuming the subkey is correctly bound (with correct signatures) to 
Alice's master key. But this is something that not even Alice should 
have to care about, this is all taken care of by GnuPG when she 
generates her new subkey.

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

From lpapp at kde.org  Thu Apr 19 12:04:47 2018
From: lpapp at kde.org (Laszlo Papp)
Date: Thu, 19 Apr 2018 11:04:47 +0100
Subject: dirmngr timeout
In-Reply-To: <CAOMwXhO1X77dXuVXSD7nUbzrVXVmgCatDMUnFeXDcNF3p6u2ng@mail.gmail.com>
References: <CAOMwXhPzQzQ-ykGURXRaBXaBQWtuqn9D1QKFZa6Jc=QO0CDhcw@mail.gmail.com>
 <87sh83rv6x.fsf@wheatstone.g10code.de>
 <CAOMwXhPjMcF0fmyPKr2b5d8xtDQJuGWugkf+Y7P-TP48gRRr2w@mail.gmail.com>
 <87604xr25s.fsf@wheatstone.g10code.de>
 <CAOMwXhM=9O2rPA=1A669nP9-Yv4kER4wP+J91FbBsnJi5Wm+LQ@mail.gmail.com>
 <CAOMwXhN6H=L=09mwukdUad7RE5o5=BkgXza8KuZgZdGPhdSxQg@mail.gmail.com>
 <87bmeno2v3.fsf@wheatstone.g10code.de>
 <CAOMwXhNRv+tLUk-sv=jJn9-O9isqrc1ZD5=wOkWAj=gjs151zQ@mail.gmail.com>
 <CAOMwXhMxN7PP_JgX9px7ZX08Fgj4VsQr3-o9nuEM82e-r-jurg@mail.gmail.com>
 <87bmegnv04.fsf@fifthhorseman.net>
 <CAOMwXhO1X77dXuVXSD7nUbzrVXVmgCatDMUnFeXDcNF3p6u2ng@mail.gmail.com>
Message-ID: <CAOMwXhMQ3bayJD+5U67Y6NcZyiBP1Ru0tOW0wzY18+qG3SoFwA@mail.gmail.com>

Adding the list back.

On Thu, Apr 19, 2018 at 9:31 AM, Laszlo Papp <lpapp at kde.org> wrote:

>
>
> On Wed, Apr 18, 2018 at 9:02 PM, Daniel Kahn Gillmor <
> dkg at fifthhorseman.net> wrote:
>
>> Hi Laszlo--
>>
>> I'm afraid we don't know the details of how your docker instance is set
>> up; which versions of which packages you have installed inside docker
>> vs. outside of docker, what's bind-mounted, what the networking
>> constraints are in place.  this makes debugging remotely a bit more
>> difficult.
>>
>
> OK; I am happy to share this. Thank you for following up with your
> difficulties.
>
> It is bleeding edge Archlinux both inside and outside. gpg and dirmngr are
> at the latest release, 2.2.6.
>
> Nothing is bind-mounted.
>
> There are no networking constraints in place as far as I am aware.
>
> Hope this makes debugging remotely a bit easier.
>
>
>> On Fri 2018-04-13 15:29:50 +0100, Laszlo Papp wrote:
>> > gpg: connecting dirmngr at '/home/nic/.gnupg/S.dirmngr' failed: IPC
>> connect call failed
>> > gpg: keyserver receive failed: No dirmngr
>>
>> if a standard user runtime dir is mounted on /run/user/$UID , the
>> dirmngr socket could be mounted there.  It sounds like that is probably
>> not mounted, so gpg is falling back to the socket location in the home
>> directory.
>>
>
> That is right.
>
>
>> but if no dirmngr is running listening on the expected socket, then gpg
>> normally tries to launch it itself.
>>
>
> Correct.
>
>
>> for example, i'd expect to see the following:
>>
>>     gpg-connect-agent: no running Dirmngr - starting '/usr/bin/dirmngr'
>>     gpg-connect-agent: waiting for the dirmngr to come up ... (5s)
>>     gpg-connect-agent: waiting for the dirmngr to come up ... (4s)
>>     gpg-connect-agent: connection to dirmngr established
>>
>
>> But i don't see that in your logs.  What version of GnuPG is installed?
>>
>
> 2.2.6
>
>
>> how did dirmnger get installed on this docker system?  how did gpg
>> itself get installed?
>>
>
> pacman (Archlinux package manager).
>
>
>>
>> what is the output of:
>>
>>      gpgconf --list-dirs
>>
>> (within the docker instance, that is)
>>
>
> sysconfdir:/etc/gnupg
> bindir:/usr/bin
> libexecdir:/usr/lib/gnupg
> libdir:/usr/lib/gnupg
> datadir:/usr/share/gnupg
> localedir:/usr/share/locale
> socketdir:/home/nic/.gnupg
> dirmngr-socket:/home/nic/.gnupg/S.dirmngr
> agent-ssh-socket:/home/nic/.gnupg/S.gpg-agent.ssh
> agent-extra-socket:/home/nic/.gnupg/S.gpg-agent.extra
> agent-browser-socket:/home/nic/.gnupg/S.gpg-agent.browser
> agent-socket:/home/nic/.gnupg/S.gpg-agent
> homedir:/home/nic/.gnupg
>
> Yes, I meant "systemctl --user import-environment http_proxy". That was a
> typo; sorry about that.
>
> I am looking forward to resolving this. Hopefully, the information above
> helps. What should I try next?
>
> Best regards, L.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180419/bde06446/attachment-0001.html>

From lpapp at kde.org  Thu Apr 19 15:21:32 2018
From: lpapp at kde.org (Laszlo Papp)
Date: Thu, 19 Apr 2018 14:21:32 +0100
Subject: dirmngr timeout
In-Reply-To: <CAOMwXhMQ3bayJD+5U67Y6NcZyiBP1Ru0tOW0wzY18+qG3SoFwA@mail.gmail.com>
References: <CAOMwXhPzQzQ-ykGURXRaBXaBQWtuqn9D1QKFZa6Jc=QO0CDhcw@mail.gmail.com>
 <87sh83rv6x.fsf@wheatstone.g10code.de>
 <CAOMwXhPjMcF0fmyPKr2b5d8xtDQJuGWugkf+Y7P-TP48gRRr2w@mail.gmail.com>
 <87604xr25s.fsf@wheatstone.g10code.de>
 <CAOMwXhM=9O2rPA=1A669nP9-Yv4kER4wP+J91FbBsnJi5Wm+LQ@mail.gmail.com>
 <CAOMwXhN6H=L=09mwukdUad7RE5o5=BkgXza8KuZgZdGPhdSxQg@mail.gmail.com>
 <87bmeno2v3.fsf@wheatstone.g10code.de>
 <CAOMwXhNRv+tLUk-sv=jJn9-O9isqrc1ZD5=wOkWAj=gjs151zQ@mail.gmail.com>
 <CAOMwXhMxN7PP_JgX9px7ZX08Fgj4VsQr3-o9nuEM82e-r-jurg@mail.gmail.com>
 <87bmegnv04.fsf@fifthhorseman.net>
 <CAOMwXhO1X77dXuVXSD7nUbzrVXVmgCatDMUnFeXDcNF3p6u2ng@mail.gmail.com>
 <CAOMwXhMQ3bayJD+5U67Y6NcZyiBP1Ru0tOW0wzY18+qG3SoFwA@mail.gmail.com>
Message-ID: <CAOMwXhNbUy3qhC-xg8dQfmJZ5BZ0Ek6SmCMp7rPYyr=c8D1cDg@mail.gmail.com>

OK, so I have now solved this issue by running the following commands in
docker prior to running gpg:

install -dm700 ~/.gnupg; echo honor-http-proxy > ~/.gnupg/dirmngr.conf

On Thu, Apr 19, 2018 at 11:04 AM, Laszlo Papp <lpapp at kde.org> wrote:

> Adding the list back.
>
> On Thu, Apr 19, 2018 at 9:31 AM, Laszlo Papp <lpapp at kde.org> wrote:
>
>>
>>
>> On Wed, Apr 18, 2018 at 9:02 PM, Daniel Kahn Gillmor <
>> dkg at fifthhorseman.net> wrote:
>>
>>> Hi Laszlo--
>>>
>>> I'm afraid we don't know the details of how your docker instance is set
>>> up; which versions of which packages you have installed inside docker
>>> vs. outside of docker, what's bind-mounted, what the networking
>>> constraints are in place.  this makes debugging remotely a bit more
>>> difficult.
>>>
>>
>> OK; I am happy to share this. Thank you for following up with your
>> difficulties.
>>
>> It is bleeding edge Archlinux both inside and outside. gpg and dirmngr
>> are at the latest release, 2.2.6.
>>
>> Nothing is bind-mounted.
>>
>> There are no networking constraints in place as far as I am aware.
>>
>> Hope this makes debugging remotely a bit easier.
>>
>>
>>> On Fri 2018-04-13 15:29:50 +0100, Laszlo Papp wrote:
>>> > gpg: connecting dirmngr at '/home/nic/.gnupg/S.dirmngr' failed: IPC
>>> connect call failed
>>> > gpg: keyserver receive failed: No dirmngr
>>>
>>> if a standard user runtime dir is mounted on /run/user/$UID , the
>>> dirmngr socket could be mounted there.  It sounds like that is probably
>>> not mounted, so gpg is falling back to the socket location in the home
>>> directory.
>>>
>>
>> That is right.
>>
>>
>>> but if no dirmngr is running listening on the expected socket, then gpg
>>> normally tries to launch it itself.
>>>
>>
>> Correct.
>>
>>
>>> for example, i'd expect to see the following:
>>>
>>>     gpg-connect-agent: no running Dirmngr - starting '/usr/bin/dirmngr'
>>>     gpg-connect-agent: waiting for the dirmngr to come up ... (5s)
>>>     gpg-connect-agent: waiting for the dirmngr to come up ... (4s)
>>>     gpg-connect-agent: connection to dirmngr established
>>>
>>
>>> But i don't see that in your logs.  What version of GnuPG is installed?
>>>
>>
>> 2.2.6
>>
>>
>>> how did dirmnger get installed on this docker system?  how did gpg
>>> itself get installed?
>>>
>>
>> pacman (Archlinux package manager).
>>
>>
>>>
>>> what is the output of:
>>>
>>>      gpgconf --list-dirs
>>>
>>> (within the docker instance, that is)
>>>
>>
>> sysconfdir:/etc/gnupg
>> bindir:/usr/bin
>> libexecdir:/usr/lib/gnupg
>> libdir:/usr/lib/gnupg
>> datadir:/usr/share/gnupg
>> localedir:/usr/share/locale
>> socketdir:/home/nic/.gnupg
>> dirmngr-socket:/home/nic/.gnupg/S.dirmngr
>> agent-ssh-socket:/home/nic/.gnupg/S.gpg-agent.ssh
>> agent-extra-socket:/home/nic/.gnupg/S.gpg-agent.extra
>> agent-browser-socket:/home/nic/.gnupg/S.gpg-agent.browser
>> agent-socket:/home/nic/.gnupg/S.gpg-agent
>> homedir:/home/nic/.gnupg
>>
>> Yes, I meant "systemctl --user import-environment http_proxy". That was a
>> typo; sorry about that.
>>
>> I am looking forward to resolving this. Hopefully, the information above
>> helps. What should I try next?
>>
>> Best regards, L.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180419/d2779826/attachment.html>

From paul.hentze at posteo.de  Thu Apr 19 16:28:21 2018
From: paul.hentze at posteo.de (Paul H. Hentze)
Date: Thu, 19 Apr 2018 16:28:21 +0200
Subject: pinentry problems
In-Reply-To: <878t9knunl.fsf@fifthhorseman.net>
References: <9e948146-eed6-cd3a-ca61-1c9dfb72d76d@posteo.de>
 <877ep6rclq.fsf@fifthhorseman.net>
 <83ea5b64-e2bd-ac8d-8631-991685c9afac@posteo.de>
 <a370c6cf-c2bc-02d1-625e-170b3b771e2b@sumptuouscapital.com>
 <87fu3tq1ee.fsf@fifthhorseman.net>
 <685e236c-744a-5278-f840-098ca1eef2e4@posteo.de>
 <abf63198-5c14-5cab-a1f0-d149c03ec4d0@sumptuouscapital.com>
 <3ec54717-794a-02e8-8432-678cf8bde5bf@posteo.de>
 <878t9knunl.fsf@fifthhorseman.net>
Message-ID: <30d090a6-867f-1db6-ad46-4a260b3367b6@posteo.de>


On 18.04.2018 22:09, Daniel Kahn Gillmor wrote:
> can you explain the pinentry problem you're seeing?  I'm afraid the bad
> ownership of your files was distracting from any other problems you were
> reporting.
>
> One simple way to test pinentry (without gpg or gpg-agent in the mix)
> is:
>
>      echo getpin | pinentry
>
> that should show you a dialog box that prompts you for a password.  you
> can put in whatever you like, and it should be emitted on the console
> where you ran the above command.
>
>       --dkg

Okay. I tried your echo and that was fine.
I just copy what I wrote in the emails before, cause this is still the
same problem:

> I tried gpg --gen-key and got even more
>
>>  gpg: agent_genkey failed: Kein Pinentry
>> Key generation failed: Kein Pinentry
> I went back to the enigmail Troubleshooting advises above under 'How to
> fix it' and tried further, so
>
> 1. is good
> 2. is good, I made this symlink thing, didn't help
> 3. is good, in my case it's
> pinentry-program /usr/bin/pinentry-qt4
> 4. is good, the gnupg versions are matching
> 5. I don't need this one, because 4 was good, they say
> 6. here is where I get
> ERR 67108949 Kein Pinentry <GPG Agent>
> 7. when I use the normal user and type in
> killall gpg-agent
>  gpg-agent --debug-level expert --use-standard-socket --daemon /bin/sh
> I get
>
>> gpg-agent --debug-level expert --use-standard-socket --daemon /bin/sh
>> gpg-agent[9469]: WARNING: "--use-standard-socket" is an obsolete
> option - it has no effect
>> gpg-agent[9469]: enabled debug flags: cache ipc
>> gpg-agent[9469]: DBG: chan_4 <- OK Pleased to meet you, process 9469
>> gpg-agent[9469]: DBG: chan_4 -> BYE
>> gpg-agent: a gpg-agent is already running - not starting a new one
>> gpg-agent: secmem usage: 0/65536 bytes in 0 blocks
> I tried it without all unnecessary code above:
> gpg-agent --debug-level expert /bin/sh
> and I get
>
>> gpg-agent[9477]: enabled debug flags: cache ipc
>> gpg-agent[9477]: DBG: chan_3 <- OK Pleased to meet you, process 9477
>> gpg-agent[9477]: gpg-agent running and available
>> gpg-agent[9477]: DBG: chan_3 -> BYE
>> gpg-agent[9477]: secmem usage: 0/65536 bytes in 0 blocks
> So this debugging doesn't work somehow and there is no other terminal
> window which opens as they say.
> It doesn't work in root either.

So basically, I can activate pinentry, the echo command Daniel send and
the other one from the enigmail site worked well. All graphical windows
are opening when I force it remotely via terminal, BUT I always get this
strange problem that I can't generate keys and I can't decrypt mails.

I didn't attach the graphical message I always get when I want to open a
encrypted message, cause it's too big for this list.
It says "GnuPG can't ask for your passphrase with Pinentry.
This is a failure of the system installation or a configuration mistake,
this is why enigmail doesn't work.
This problem can't be solved automatically."


This is the problem I am still stuck with.

Paul


From wk at gnupg.org  Thu Apr 19 17:23:42 2018
From: wk at gnupg.org (Werner Koch)
Date: Thu, 19 Apr 2018 17:23:42 +0200
Subject: Importing existing key as subkey
In-Reply-To: <20180331005427.hpthmdxmxsxixq3u@tumbleweed> (Chris Coutinho's
 message of "Sat, 31 Mar 2018 02:54:27 +0200")
References: <20180331005427.hpthmdxmxsxixq3u@tumbleweed>
Message-ID: <87sh7rgqyp.fsf@wheatstone.g10code.de>

On Sat, 31 Mar 2018 02:54, chrisbcoutinho at gmail.com said:
> Hello,
>
> I'm trying to consolidate my various master keys into a single master
> with subkeys. On my 'old' computer with gpg2.0 (openSUSE 42.3) I was
> able to export the secret key and split it up with `gpgsplit`.  On my
> new machine (openSUSE Tumbleweed), the `gpgsplit` command is
> unavailable, and I'm curious if that functionality has been removed or

gpgsplit is part of all GnuPG versions and all versions should work for
you.  Thus you may download a gpg 1.4 version, unpack and build it but
do not install it:

  tar xzf gnupg-1.4.22.tar.gz
  cd gnupg-1.4.22
  ./configure && make

Then you should find a

  tools/gpgsplit
  
which can be used for that task.  I have not read the HOWTO so I won't
comment on this.  However, I created a freature request to make this
easier:

  https://dev.gnupg.org/T3921


Shalom-Salam,

   Werner

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

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

Hello!

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

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

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


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

 * Fixed build problems in the 1.11.0 release.

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

 The 1.11.0 release came with these changes:

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

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

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

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

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

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

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

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

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

 * New convenience constant GPGME_KEYLIST_MODE_LOCATE.

 * Improved the Python documentation.

 * Fixed a potential regression with GnuPG 2.2.6 or later.

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

 * Various minor fixes.


Download
========

You may download this library and its OpenPGP signature from:

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

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

95b1fc427871ca8d30d6d3b1985c816fe0b5077b  gpgme-1.11.1.tar.bz2

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


Thanks
======

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

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


Happy hacking,

  Your GnuPG hackers



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

p.p.s 
List of Release Signing Keys:

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

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

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

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

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

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

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

From wink at saville.com  Sat Apr 21 18:32:18 2018
From: wink at saville.com (Wink Saville)
Date: Sat, 21 Apr 2018 09:32:18 -0700
Subject: Backup .gnupg using git
Message-ID: <CAKk8iso_cr=pDHMFy-zH1Cb00i8J2B_wAiz1RzMCAD9o47PnZQ@mail.gmail.com>

I created a master key and three subkeys following instructions at [1].

I've backed up the secret keys using paperbackup with a modification
to add the sequence count to the backed up data so as to identify any qr-codes
that don't get decoded properly [2] and deleted the master secret key.

I then transferred the secret subkeys to a yubikey as per [3].

Finally I backed up .gnupg to github [4].

Then to restore the I clone the repo and change permissions to 700:

$ git clone git at github.com:winksaville/.gnupg ~/.gnupg
$ chmod 700 ~/.gnupg

And then insert the yubikey and get the card-status to retrieve the
stub secret keys have gpg functional.

$ gpg --card-status


Comments on the security of what I'm doing?


[1]: https://blog.eleven-labs.com/en/openpgp-almost-perfect-key-pair-part-1/
[2]: https://github.com/winksaville/paperbackup
[3]: https://blog.eleven-labs.com/en/openpgp-secret-keys-yubikey-part-2/
[4]: https://github.com/winksaville/.gnupg


From stefan.claas at posteo.de  Sun Apr 22 20:26:03 2018
From: stefan.claas at posteo.de (Stefan Claas)
Date: Sun, 22 Apr 2018 20:26:03 +0200
Subject: gpgsm --verify
Message-ID: <8be13dfe-d0a9-65e2-0123-377e1df44266@posteo.de>

Hi all,

i was wondering when receiving an S/MIME
message created with Thunderbird, how do
i properly verify the message with gpgsm?

As an example i sign now this message
and would appreciate any tips!

P.S. when i do a verify on a Thunderbird
S/MIME message i always get:

gpgsm: enabled debug flags: ipc
gpgsm: ksba_cms_parse failed: Dateiende
secmem usage: 0/16384 bytes in 0 blocks

Best regards
Stefan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3852 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180422/4b2b98af/attachment.bin>

From stefan.claas at posteo.de  Sun Apr 22 20:36:19 2018
From: stefan.claas at posteo.de (Stefan Claas)
Date: Sun, 22 Apr 2018 20:36:19 +0200
Subject: gpgsm --verify
In-Reply-To: <8be13dfe-d0a9-65e2-0123-377e1df44266@posteo.de>
References: <8be13dfe-d0a9-65e2-0123-377e1df44266@posteo.de>
Message-ID: <0f07a59f-5760-3e2a-58f4-4808f66b6f13@posteo.de>

Am 22.04.18 um 20:26 schrieb Stefan Claas:
> Hi all,
>
> i was wondering when receiving an S/MIME
> message created with Thunderbird, how do
> i properly verify the message with gpgsm?
>
> As an example i sign now this message
> and would appreciate any tips!
>
> P.S. when i do a verify on a Thunderbird
> S/MIME message i always get:
>
> gpgsm: enabled debug flags: ipc
> gpgsm: ksba_cms_parse failed: Dateiende
> secmem usage: 0/16384 bytes in 0 blocks
Mmmhh. My send folder in Thunderbird
shows that the message is signed and the
posting in the Mailing List does not show
the little envelope with the red dot in
Thunderbird*. :-(

*Yeah, it's a GnuPG Mailing List... :-P

Regards
Stefan



From paul.hentze at posteo.de  Sun Apr 22 18:41:33 2018
From: paul.hentze at posteo.de (Paul H. Hentze)
Date: Sun, 22 Apr 2018 18:41:33 +0200
Subject: problems with pinentry
Message-ID: <0432c466-4309-4f42-73ad-fa305576cda6@posteo.de>

Hey folks,

Debian 9, Thunderbird 52.7.0 (64-bit), Enigmail 2.0.2, GnuPG 2.1.18

I have a pinentry problem with GPG.
I tried to debug that, but it didn't work out.

I followed the 'How to fix it' advises, from enigmail:
https://www.enigmail.net/index.php/en/faq?view=topic&id=14#faqLink_2


1. is good
2. is good, I made this symlink thing, didn't help
3. is good, I'm using
pinentry-program /usr/local/bin/pinentry-qt
4. is good, the gnupg versions are matching
5. is good, already in there
6. here is where I get
> ERR 67108949 Kein Pinentry <GPG Agent="">
7. I tried this and get that some of the code is not necessary, so in
short, it is
gpg-agent --debug-level expert /bin/sh

> gpg-agent[9477]: enabled debug flags: cache ipc
> gpg-agent[9477]: DBG: chan_3 <- OK Pleased to meet you, process 9477
> gpg-agent[9477]: gpg-agent running and available
> gpg-agent[9477]: DBG: chan_3 -> BYE
> gpg-agent[9477]: secmem usage: 0/65536 bytes in 0 blocks

equally I can't use
gpg --gen-key

the return is
> gpg: agent_genkey failed: Kein Pinentry
> Key generation failed: Kein Pinentry

I attached the log-data from enigmail, where I reproduced the problem.
Maybe you can find something in there I didn't.

Has somebody any idea what to do?


Best wishes


Paul
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: logdata_enigmail
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180422/32ee6b75/attachment-0001.ksh>

From dgouttegattat at incenp.org  Sun Apr 22 22:27:17 2018
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Sun, 22 Apr 2018 21:27:17 +0100
Subject: Backup .gnupg using git
In-Reply-To: <CAKk8iso_cr=pDHMFy-zH1Cb00i8J2B_wAiz1RzMCAD9o47PnZQ@mail.gmail.com>
References: <CAKk8iso_cr=pDHMFy-zH1Cb00i8J2B_wAiz1RzMCAD9o47PnZQ@mail.gmail.com>
Message-ID: <3c974ad9-4965-7d00-cdba-80586378490b@incenp.org>

On 04/21/2018 05:32 PM, Wink Saville wrote:
> Comments on the security of what I'm doing?

Can't really tell anything without knowing your adversary (is it Mossad 
or not-Mossad? [1]), but here are a few remarks.

You do not say which version of GnuPG you are using. Assuming you are 
using the latest available version on your system (which you should), 
most of the options you put in your gpg.conf and dirmngr.conf are 
useless, as they are already in the default settings (something many 
authors of those "create a perfect keypair" howtos seem to ignore).

Also, your gpg.conf contains the following:

   # Avoid information leaked
   [...]
   export-options export-minimal

If the goal here is to avoid revealing who signed your key (this option 
tells GnuPG to remove all third-party signatures on your key), then this 
is completely defeated by the fact that you upload your entire public 
keyring to a world-readable Github repository!

Combined with the trust database that you *also* upload, this is a 
pretty serious information leak IMO, as anyone can learn not only who 
signed your key, but also which keys you collected over time, which keys 
you signed (even if you only signed them locally), and how much you 
trust the owners of all those keys. Are you fine with that, or didn't 
you realize the implications of uploading those files?

Finally and as a general rule, if you are not sure of what you are 
doing, I am strongly of favour of following only those two advices:

* Use the latest GnuPG version available on your system. In particular, 
if you invoke `gpg`, make sure this is GnuPG >= 2.1 and *not* GnuPG 1.x.
* Use the default settings.


Damien


[1] https://lists.gnupg.org/pipermail/gnupg-users/2017-April/058046.html

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

From wk at gnupg.org  Mon Apr 23 08:36:10 2018
From: wk at gnupg.org (Werner Koch)
Date: Mon, 23 Apr 2018 08:36:10 +0200
Subject: gpgsm --verify
In-Reply-To: <8be13dfe-d0a9-65e2-0123-377e1df44266@posteo.de> (Stefan Claas's
 message of "Sun, 22 Apr 2018 20:26:03 +0200")
References: <8be13dfe-d0a9-65e2-0123-377e1df44266@posteo.de>
Message-ID: <87zi1uctut.fsf@wheatstone.g10code.de>

On Sun, 22 Apr 2018 20:26, stefan.claas at posteo.de said:

> i was wondering when receiving an S/MIME
> message created with Thunderbird, how do
> i properly verify the message with gpgsm?

You need to de-compose the S/MIME message to get the CMS objects.
Despit ethe name, gpgsm does not known about S/MIME (or MIME at all) and
thus can't parse it.  That is actually the same as with PGP/MIME which
can't be handled directly by gpg [1].

In gnupg/tools/ you can find a basic MIME parser but it is not well
documented and only used for manual testing.


Salam-Shalom,

   Werner



[1] Actually encrypted PGP/MIME messages can be directly decrypted gpg
due to a pecularity of the PGP/MIME format.

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

From stefan.claas at posteo.de  Mon Apr 23 08:50:42 2018
From: stefan.claas at posteo.de (Stefan Claas)
Date: Mon, 23 Apr 2018 08:50:42 +0200
Subject: gpgsm --verify
In-Reply-To: <87zi1uctut.fsf@wheatstone.g10code.de>
References: <8be13dfe-d0a9-65e2-0123-377e1df44266@posteo.de>
 <87zi1uctut.fsf@wheatstone.g10code.de>
Message-ID: <6ea51451-8d60-ec7a-d9a8-d2470c02e9ca@posteo.de>

Am 23.04.18 um 08:36 schrieb Werner Koch:
> On Sun, 22 Apr 2018 20:26, stefan.claas at posteo.de said:
>
>> i was wondering when receiving an S/MIME
>> message created with Thunderbird, how do
>> i properly verify the message with gpgsm?
> You need to de-compose the S/MIME message to get the CMS objects.
> Despit ethe name, gpgsm does not known about S/MIME (or MIME at all) and
> thus can't parse it.  That is actually the same as with PGP/MIME which
> can't be handled directly by gpg [1].
>
> In gnupg/tools/ you can find a basic MIME parser but it is not well
> documented and only used for manual testing.
>
Thank you very much for the information!

I will check out the MIME parser.

Regards
Stefan



From wink at saville.com  Mon Apr 23 21:54:30 2018
From: wink at saville.com (Wink Saville)
Date: Mon, 23 Apr 2018 12:54:30 -0700
Subject: Backup .gnupg using git
In-Reply-To: <3c974ad9-4965-7d00-cdba-80586378490b@incenp.org>
References: <CAKk8iso_cr=pDHMFy-zH1Cb00i8J2B_wAiz1RzMCAD9o47PnZQ@mail.gmail.com>
 <3c974ad9-4965-7d00-cdba-80586378490b@incenp.org>
Message-ID: <CAKk8ispDRHpETJDXg9sh2+uj7bj2zkV1tW8roT6REafAyoNaeA@mail.gmail.com>

On Sun, Apr 22, 2018 at 1:27 PM, Damien Goutte-Gattat
<dgouttegattat at incenp.org> wrote:
> On 04/21/2018 05:32 PM, Wink Saville wrote:
>>
>> Comments on the security of what I'm doing?
>
>
> Can't really tell anything without knowing your adversary (is it Mossad or
> not-Mossad? [1]), but here are a few remarks.

Not-Mossad, it seems if its Mossad it doesn't matter. My goal is to have
as good a security as possible while make it relatively easy to use. Using
the smart card seemed to increase the security by not having any secret
keys directly on my computer, hence that choice.

>
> You do not say which version of GnuPG you are using.

$ gpg --version
gpg (GnuPG) 2.2.6
libgcrypt 1.8.2
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: /home/wink/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
        CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

> Assuming you are using
> the latest available version on your system (which you should), most of the
> options you put in your gpg.conf and dirmngr.conf are useless, as they are
> already in the default settings (something many authors of those "create a
> perfect keypair" howtos seem to ignore).
>
> Also, your gpg.conf contains the following:
>
>   # Avoid information leaked
>   [...]
>   export-options export-minimal
>
> If the goal here is to avoid revealing who signed your key (this option
> tells GnuPG to remove all third-party signatures on your key), then this is
> completely defeated by the fact that you upload your entire public keyring
> to a world-readable Github repository!
>
> Combined with the trust database that you *also* upload, this is a pretty
> serious information leak IMO, as anyone can learn not only who signed your
> key, but also which keys you collected over time, which keys you signed
> (even if you only signed them locally), and how much you trust the owners of
> all those keys. Are you fine with that, or didn't you realize the
> implications of uploading those files?

I'm ignorant and didn't realize what I did :)

At the moment I've not signed any keys nor have I had any signed so nothing
lost so far (I think). On the other hand, I haven't run across any
information that
would allow me to control what information other people might leak.

Also, it would seem if you're using "Public Key Encryption" you have to assume
all "Public" information is already leaked, correct?

>
> Finally and as a general rule, if you are not sure of what you are doing, I
> am strongly of favour of following only those two advices:

Definitely me.

>
> * Use the latest GnuPG version available on your system. In particular, if
> you invoke `gpg`, make sure this is GnuPG >= 2.1 and *not* GnuPG 1.x.
> * Use the default settings.

I'm using 2.2.6 on Arch Linux systems which I update about once a week,
so hopefully keeping up to date and I'm now "just using the defaults".

>
> Damien
>
>
> [1] https://lists.gnupg.org/pipermail/gnupg-users/2017-April/058046.html
>

TXS, Wink


From dirk.gottschalk1980 at googlemail.com  Tue Apr 24 22:58:34 2018
From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk)
Date: Tue, 24 Apr 2018 22:58:34 +0200
Subject: Wrong Keygrip (gpg2 --card-status --with-keygrip)
Message-ID: <1524603514.4991.3.camel@googlemail.com>

Hi,

gpg outputs the wrhon keygrip with --card-edit --with-keygrip. The
output is:

Signature key ....: DDCB AF8E 0132 AA54 20AB  B864 4081 0B18 1ED8 E838
      created ....: 2018-03-01 13:46:51
      keygrip ....: 5707164106D237EB453D5359F9D319955BAA33A2
Encryption key....: 092D 9CEB 9D34 B154 E0FC  5761 CAE0 7B25 1AE3 F69E
      created ....: 2018-03-01 13:46:51
      keygrip ....: A3B4BF3DA9F46E9BCC5687A7E59680A8B008DA8E
Authentication key: B982 A7AC F65C FBBB 1E7B  2B05 774B 4700 4B02 B274
      created ....: 2018-03-01 13:47:25
      keygrip ....: A3B4BF3DA9F46E9BCC5687A7E59680A8B008DA8E

As you see, it returns the same grip for enc. and auth. key. This is
wrong and "gpg2 -K --with-keygrip" returns the correct Keygrips.

My gpg version is 2.2.6

Regards,
Dirk

-- 
Dirk Gottschalk
Paulusstrasse 6-8
52064 Aachen
Tel.: +49 1573 1152350
-------------- 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-users/attachments/20180424/c5beed76/attachment.sig>

From gniibe at fsij.org  Wed Apr 25 02:43:57 2018
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 25 Apr 2018 09:43:57 +0900
Subject: Wrong Keygrip (gpg2 --card-status --with-keygrip)
In-Reply-To: <1524603514.4991.3.camel@googlemail.com>
References: <1524603514.4991.3.camel@googlemail.com>
Message-ID: <87k1sw2jzm.fsf@fsij.org>

Hello,

Thanks for your report.

Dirk Gottschalk via Gnupg-users <gnupg-users at gnupg.org> wrote:
> gpg outputs the wrhon keygrip with --card-edit --with-keygrip. The
> output is:
[...]
> As you see, it returns the same grip for enc. and auth. key. This is
> wrong and "gpg2 -K --with-keygrip" returns the correct Keygrips.
>
> My gpg version is 2.2.6

It's a new feature introduced in 2.2.6, and I did not review the patch
well.

Just fixed and pushed in 71903eee8.
-- 


From andrewg at andrewg.com  Thu Apr 26 11:05:59 2018
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Thu, 26 Apr 2018 10:05:59 +0100
Subject: Quick commands documentation
Message-ID: <6d6ea158-b0d0-ab8e-c38d-e2b768d3184a@andrewg.com>

Hi, all.

There's a suspiciously empty documentation page on the main site:

https://www.gnupg.org/documentation/manuals/gnupg/The-quick-key-manipulation-interface.html

Is this still WIP, or just an update/sync error?

-- 
Andrew Gallagher

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 862 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180426/23c84651/attachment-0001.sig>

From afenkart at gmail.com  Thu Apr 26 10:59:49 2018
From: afenkart at gmail.com (Andreas Fenkart)
Date: Thu, 26 Apr 2018 10:59:49 +0200
Subject: gpgsm/cms: int_rsa_verify:wrong signature length
Message-ID: <CALtMJED_eviqotEw56BfVNa1YUvOnacyWnTB1uzDm5uL_+Kvvw@mail.gmail.com>

Hi,

I'm using GnuPG to sign 'swupdate' update images. They are verified on the
target using openssl:

  gpgsm -o sw-description.sig -sb sw-description

swupdate links against the openssl, but the equivalent cmd line is:

  openssl cms -verify -in sw-description.sig -inform DER -content
sw-description \
                -CAfile mycert.cert.pem -binary

This works for quite a while with no problem, just suddenly I see this error
when verifying

  140250102395072:error:04091077:rsa routines:int_rsa_verify:wrong
signature length:../crypto/rsa/rsa_sign.c:132:
  140250102395072:error:2E09809E:CMS
routines:CMS_SignerInfo_verify:verification
failure:../crypto/cms/cms_sd.c:738:

gpgsm verfication though works.

Comparing the asn1parse output of working/non-working signatures, I can see
that the non-working signature block is 1-byte shorter then the working version

$ diff /tmp/works /tmp/broken
76,77c76,77
<   929:d=3  hl=4 l= 561 cons: SET
<   933:d=4  hl=4 l= 557 cons: SEQUENCE
---
>   929:d=3  hl=4 l= 559 cons: SET
>   933:d=4  hl=4 l= 555 cons: SEQUENCE
105c105
<  1234:d=5  hl=4 l= 256 prim: OCTET STRING      [HEX
DUMP]:EF4378D3F5AFDE79974518722EA1B12F7DE7C71239B03676378A9B2AC7F5BB76AF91DFE05B004AA0C68CAD8CE54021C61CD49943BA513888D29A6B5AD41942FC57BCBFE1A1B68607EC875434119A28DC6C3463CE4C9B0C948E89C93CB18B7FFDBCDAB6467501E15CD5B603CAA8693DBF27B70B624F15E2BE0A1BD02EB26E619D2EC6A8A939BAB6CA169ABB6A0A76319AD9208728AE566312B63281D03B77B0A38A46FB63FFF5741D4484B14CBF46D092B42D3878AA333CA6CDF6A2412B4DA4DB2AD2DE401506D9B7C24B6CEC18160BC1CBF30426217C27C4CCFDB3B444BBE9C2C9A95D12925A77FA6E6795DE4FFE223C943F15823BC642483F0244A7551052AE
<  1494:d=3  hl=2 l=   0 prim: EOC
<  1496:d=2  hl=2 l=   0 prim: EOC
<  1498:d=1  hl=2 l=   0 prim: EOC
---
>  1234:d=5  hl=3 l= 255 prim: OCTET STRING      [HEX DUMP]:AE0DAC25E87228FF787FD632BC056BC26601E5077537435AD5F653F52B1D13C5194E1B2E35DBD09C059EE55092575CBB7F9AD5B23F5599CC7009BB494FD96CD2C1D4CD5BC0EE674713ADCA41322BCEF25EC1EDB25EAE308E668E30298C88660917775AA76CCF1E60FA8941181B6F1E7D96600A8B9116ABFDDA7A3AFB4D17B15CC8B761EDE09D6E3B6A257B2F1E129A1BE1F192B8E684B872ACA72BDEC7F482D568ABF482EBB97F5A24D0D14281AD8AF169204A395071C96BF2F4BB780EBD3ABD640D373CA8F0EB7AE46CA37E8A8D5E2DB575354DF79F46E004B700E0FC50F06AD8670FD6855B62B7F1279C2A0640794485A824760ED681C4BF9E2742A0698D
>  1492:d=3  hl=2 l=   0 prim: EOC
>  1494:d=2  hl=2 l=   0 prim: EOC
>  1496:d=1  hl=2 l=   0 prim: EOC

This is my gpgsm version, I did not upgrade to the latest version yet

  $ gpgsm --version
  gpgsm (GnuPG) 2.1.7-unknown
  libgcrypt 1.6.3
  libksba 1.3.3-unknown
  Copyright (C) 2015 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.

I also sent an email to openssl mailing list:
https://mta.openssl.org/pipermail/openssl-users/2018-April/007913.html

The suggestion was that it might be lacking zero-padding. Might this be
the problem here? I will update the gpgsm version to latest of course. But
since I observed the problem only once I wonder if this is a known issue and
has been fixed in upstream version.

kind regards,
Andi


From lfalchetti at pc-fcu.org  Thu Apr 26 22:36:59 2018
From: lfalchetti at pc-fcu.org (Liana Falchetti)
Date: Thu, 26 Apr 2018 16:36:59 -0400
Subject: Can not decrypt and verify CD's
Message-ID: <!&!AAAAAAAAAAAuAAAAAAAAALxb/E6kIQdCsVwhK70oWSgBAMO2jhD3dRHOtM0AqgC7tuYAAAAAAA4AABAAAAAYZAISpSGCSIn82yAxPFm5AQAAAAA=@pc-fcu.org>

I work at a credit union that gets CD's with archived information on them
that upon arrival need to be Decrypted and verified by the GnuPG software. 

I have to say that I have never used GnuPG software for anything except
Decrypting and verifying these particular CD's. This past week I went to 

Tyr and decrypt one of the Cd's and now I can't get the Passphrase box to
pop up in order the download the contents. I have tried absolutely

Everything and anything I can think of including googling the error messages
I am getting.  I have no idea what I did to get this to not work properly.

We are actually on a Data center network or like a cloud environment, if you
will, with our data processor and the first time the Kleopatra software

Needed to be re-installed if what installed on the terminal server but I can
not run CD's on the DCN and therefore, it was then put on my desktop.

This is what it looks like, which looks normal to me.

 



 

But when I tried to Decrypt and verify the CD I always get this. I have
tried to Certify and Import the keys and nothing is working.

 



 

Every time I try to Import keys:

 

Could Not Determine the Certificate type of C:Program
File/GNU/GnuPG/Kleopatra.exe.

Below is where Kleopatra file is actually located.

 



 

I also have the private key, as well as, the passphrase. I did change the
passphrase today to see if that would help but of course it didn't.

 

I know this is probably a long shot but if anyone there could help I would
be eternally grateful.

 

Thank you,

 

Liana Falchetti

Operations Manager

Parkview Community

Federal Credit Union

2100 Eden Park Blvd.

McKeesport, PA 15132

(412) 678-9564, Ext. 29

 <mailto:lfalchetti at pc-fcu.org> lfalchetti at pc-fcu.org

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180426/c0d526c3/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 37415 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180426/c0d526c3/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 20681 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180426/c0d526c3/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 84904 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180426/c0d526c3/attachment-0005.png>

From tlikonen at iki.fi  Sat Apr 28 18:04:26 2018
From: tlikonen at iki.fi (Teemu Likonen)
Date: Sat, 28 Apr 2018 19:04:26 +0300
Subject: Practical use of gpgsm for verifying emails
Message-ID: <87d0yj9v1x.fsf@iki.fi>

I read email with Gnus (Emacs) and from time to time someone has signed
his mail with S/MIME (X.509) system. My Gnus tries to verify signatures
automatically and it works nicely with PGP/MIME but S/MIME is more
difficult.

When verifying an S/MIME message gpgsm (I think) asks whether I
ultimately trust some certificate authority to certify others and then
asks me to verify that a displayed fingerprint belongs to the authority.
How do I know? (So far I have pressed the "Cancel" button.)

I went to the certificate authority's web page but couldn't find
fingerprints. That's not how CA system usually works anyway. Usually we
are not supposed to go searching the internet. Usually some experts have
taught web browsers or operating systems to automatically trust certain
authorities. So signature verification is transparent.

Any suggestions or information for practically managing S/MIME messages?

-- 
/// Teemu Likonen   - .-..   <https://keybase.io/tlikonen> //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180428/c1cd9ab7/attachment.sig>

From fuzzy_drawrings at protonmail.com  Sun Apr 29 22:18:55 2018
From: fuzzy_drawrings at protonmail.com (FuzzyDrawrings)
Date: Sun, 29 Apr 2018 16:18:55 -0400
Subject: Can not decrypt and verify CD's
Message-ID: <TfE2Umpb6bihG5GiZh6wSo8GAOz1XNnSFSoGesdLIBZ31Cjshe33KYrct35XjPgJHZRtUuF0gcLrwUXmBJ37GJSXYmhSS-MMxtQs2KHVawU=@protonmail.com>

Have you tried changing the certificate's Owner Trust? Since you imported the private key (as opposed to generating it), the trust is unknown. Owner trust should probably be set to "full".


From m-guelker at phoenixmail.de  Sun Apr 29 22:27:42 2018
From: m-guelker at phoenixmail.de (Marvin =?utf-8?Q?G=C3=BClker?=)
Date: Sun, 29 Apr 2018 22:27:42 +0200
Subject: CRL server error with gpgsm
Message-ID: <20180429202742.smkuoh2w2nflrveo@hades>

Hi everyone,

I'm trying to set up S/MIME signing with mutt using gpgsm on Debian
Stable (Stretch). I've successfully imported the PKCS#12
certificate/private key bundle into gpgsm, but it won't let me sign
anything. It fails with an error message as shown below:

    $ gpgsm --output sign.bin --sign test.txt
    gpgsm: Note: non-critical certificate policy not allowed
    gpgsm: certificate #1EF41DD8EB16AE2D8B50B8E3/CN=DFN-Verein Global Issuing CA,OU=DFN-PKI,O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V.,C=DE
    gpgsm: checking the CRL failed: Server indicated a failure
    gpgsm: error creating signature: Server indicated a failure <Dirmngr>

The certificate is valid and not revoked. I can perfectly sign with
this certificate using gpgsm under Gentoo Linux using the exact same
command with the same certificate. When I expressly pass the
--disable-crl-checks option, it also works:

    $ gpgsm --output sign.bin --disable-crl-checks --sign test.txt
    gpgsm: Note: non-critical certificate policy not allowed
    gpgsm: Note: non-critical certificate policy not allowed
    gpgsm: Note: non-critical certificate policy not allowed
    gpgsm: CRLs not checked due to --disable-crl-checks option
    gpgsm: DBG: adding certificates at level -2
    gpgsm: signature created

The certificate chain is completely available as evidenced by $ gpgsm
--list-chain, so that shouldn't be the problem.

Any idea how I should approach this error? Is it a bug, as it doesn't
happen on Gentoo?

gpgsm version I use on the Debian system:

    $ gpgsm --version
    gpgsm (GnuPG) 2.1.18
    libgcrypt 1.7.6-beta
    libksba 1.3.5-unknown
    Copyright (C) 2017 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law.
    
    Home: /home/quintus/.gnupg
    Supported algorithms:
    Cipher: 3DES, AES128, AES192, AES256, SERPENT128, SERPENT192, SERPENT256, SEED, CAMELLIA128, CAMELLIA192, CAMELLIA256
    Pubkey: RSA, ECC
    Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224, WHIRLPOOL

gpgsm version on the Gentoo system:

    $ gpgsm --version
    gpgsm (GnuPG) 2.2.4
    libgcrypt 1.8.1
    libksba 1.3.5
    Copyright (C) 2017 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law.
    
    Home: /home/quintus/.gnupg
    Unterst?tzte Verfahren:
    Cipher: 3DES, AES128, AES192, AES256, SERPENT128, SERPENT192, SERPENT256, SEED, CAMELLIA128, CAMELLIA192, CAMELLIA256
    Pubkey: RSA, ECC
    Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224, WHIRLPOOL

Marvin

-- 
Blog: https://mg.guelker.eu
PGP/GPG ID: F1D8799FBCC8BC4F


From lechten at wi.uni-muenster.de  Mon Apr 30 08:19:39 2018
From: lechten at wi.uni-muenster.de (Jens Lechtenboerger)
Date: Mon, 30 Apr 2018 08:19:39 +0200
Subject: Practical use of gpgsm for verifying emails
In-Reply-To: <87d0yj9v1x.fsf__31441.510647028$1524936843$gmane$org@iki.fi>
 (Teemu Likonen's message of "Sat, 28 Apr 2018 19:04:26 +0300")
References: <87d0yj9v1x.fsf__31441.510647028$1524936843$gmane$org@iki.fi>
Message-ID: <8736zd43no.fsf@wi.uni-muenster.de>

On 2018-04-28, Teemu Likonen wrote:

> When verifying an S/MIME message gpgsm (I think) asks whether I
> ultimately trust some certificate authority to certify others and then
> asks me to verify that a displayed fingerprint belongs to the authority.
> How do I know? (So far I have pressed the "Cancel" button.)

You don?t.  You should not trust them if you don?t know anything
about them.

> I went to the certificate authority's web page but couldn't find
> fingerprints.

That?s odd.  Maybe they publish their certificates over HTTPS,
from which you could extract the fingerprint.

> That's not how CA system usually works anyway. Usually we are not
> supposed to go searching the internet. Usually some experts have
> taught web browsers or operating systems to automatically trust
> certain authorities. So signature verification is transparent.

They added ?trust,? not trust.  See [1] for my biased point of view
(still pretty accurate despite its age; nowadays, I would add a
pointer to Certificate Transparency [2]).

> Any suggestions or information for practically managing S/MIME messages?

Personally, I try to verify CAs? fingerprints.  Afterwards, I
express my ?trust? in other people?s choices of CAs when verifying
their signatures (so, pretend ?Yes? when asked about trust) but
prefer OpenPGP over S/MIME whenever possible.

Best wishes
Jens

[1] https://blogs.fsfe.org/jens.lechtenboerger/2013/12/23/openpgp-and-smime/
[2] https://www.certificate-transparency.org/


From aheinecke at intevation.de  Mon Apr 30 16:28:47 2018
From: aheinecke at intevation.de (Andre Heinecke)
Date: Mon, 30 Apr 2018 16:28:47 +0200
Subject: Can not decrypt and verify CD's
In-Reply-To: <!&!AAAAAAAAAAAuAAAAAAAAALxb/E6kIQdCsVwhK70oWSgBAMO2jhD3dRHOtM0AqgC7tuYAAAAAAA4AABAAAAAYZAISpSGCSIn82yAxPFm5AQAAAAA=@pc-fcu.org>
References: <!&!AAAAAAAAAAAuAAAAAAAAALxb/E6kIQdCsVwhK70oWSgBAMO2jhD3dRHOtM0AqgC7tuYAAAAAAA4AABAAAAAYZAISpSGCSIn82yAxPFm5AQAAAAA=@pc-fcu.org>
Message-ID: <5691560.YEykSjarKi@esus>

Hi,

On Thursday, April 26, 2018 4:36:59 PM CEST Liana Falchetti wrote:
> I work at a credit union that gets CD's with archived information on them
> that upon arrival need to be Decrypted and verified by the GnuPG software. 
> 
> I have to say that I have never used GnuPG software for anything except
> Decrypting and verifying these particular CD's. This past week I went to 
> 
> Tyr and decrypt one of the Cd's and now I can't get the Passphrase box to
> pop up in order the download the contents. I have tried absolutely
> 
> Everything and anything I can think of including googling the error messages
> I am getting.  I have no idea what I did to get this to not work properly.
> 
> We are actually on a Data center network or like a cloud environment, if you
> will, with our data processor and the first time the Kleopatra software
> 
> Needed to be re-installed if what installed on the terminal server but I can
> not run CD's on the DCN and therefore, it was then put on my desktop.
> 
> This is what it looks like, which looks normal to me.

Normal but outdated ;-) 

> But when I tried to Decrypt and verify the CD I always get this. I have
> tried to Certify and Import the keys and nothing is working.

This says (badly) that this file is not encrypted to the private key you have.
 
> Every time I try to Import keys:
> Could Not Determine the Certificate type of C:Program
> File/GNU/GnuPG/Kleopatra.exe.

Please update to Gpg4win-3.1.0 it's much better at detecting / importing 
certificates and allows you to import certificates by double click.

> I also have the private key, as well as, the passphrase. I did change the
> passphrase today to see if that would help but of course it didn't.

No, the error is that the file is not encrypted to your private key. Changing 
the passphrase won't help.

Kleopatra 3.1.0 should show an improved error and show you to which keys it is 
actually encrypted.

Alternatively you can open the command line (cmd.exe) and call
 "gpg --decrypt <thefile>" this will definetly show to which keys it is 
encrypted.


Best Regards,
Andre Heinecke


-- 
Andre Heinecke |  ++49-541-335083-262  | http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180430/4d60bca7/attachment.sig>

From tlikonen at iki.fi  Mon Apr 30 20:30:01 2018
From: tlikonen at iki.fi (Teemu Likonen)
Date: Mon, 30 Apr 2018 21:30:01 +0300
Subject: Practical use of gpgsm for verifying emails
In-Reply-To: <8736zd43no.fsf@wi.uni-muenster.de> (Jens Lechtenboerger's
 message of "Mon, 30 Apr 2018 08:19:39 +0200")
References: <87d0yj9v1x.fsf__31441.510647028$1524936843$gmane$org@iki.fi>
 <8736zd43no.fsf@wi.uni-muenster.de>
Message-ID: <87h8nspmxi.fsf@iki.fi>

Jens Lechtenboerger [2018-04-30 08:19:39+02] wrote:

> You don?t. You should not trust them if you don?t know anything about
> them.

> Personally, I try to verify CAs? fingerprints. Afterwards, I express
> my ?trust? in other people?s choices of CAs when verifying their
> signatures (so, pretend ?Yes? when asked about trust) but prefer
> OpenPGP over S/MIME whenever possible.

As I requested a practical discussion I thought that there is some sort
of "practical trust" when verifying S/MIME messages like there usually
is for the web. For example I can point my web browser to my bank's web
site or your blog at fsfe.org and there is a friendly green lock symbol
in the browser. We normal people think that "this web site is safe"
without checking any fingerprints. Some people even know that the
browser automatically trusts certain authorities to make valid
certificates so that it's really my bank or fsfe.org. Somebody chose
that trust for us because we normal people can't judge.

So I thought that gpgsm would be the same: some root CA's would be
automatically valid and trusted to certify others and gpgsm would just
work like web browsers. I guess not. It forces me to judge and since I
can't judge CA's gpgsm is probably quite useless. I'm not complaining
about gpgsm. It's just that for a moment I thought it would be like web
browsers but for email.

OpenPGP is probably better for email because it's easier to track and
judge individuals separately with TOFU or web of trust model and assign
ownertrust.

-- 
/// Teemu Likonen   - .-..   <https://keybase.io/tlikonen> //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180430/3eb8b534/attachment.sig>