From aneesh at idspage.com  Thu Feb  1 05:03:20 2018
From: aneesh at idspage.com (Aneesh Varghese)
Date: Thu, 1 Feb 2018 04:03:20 +0000
Subject: How to avoid Passphrase prompt
In-Reply-To: <efe80bc9-0635-0c9b-5daf-bd98574e06ec@digitalbrains.com>
References: <c02ef08eb7a84e6082a0308b5ecabb59@idspage.com>
 <536b4678-dd6f-e574-06cf-ab6cda3f377b@digitalbrains.com>
 <c924075c0afd48349c0b6dd294901918@idspage.com>
 <47037cbe-106d-5cfb-f76e-7cb5b403e5ae@digitalbrains.com>
 <69cd8517e2c24e9593d8dc4a8fa87150@idspage.com>,
 <efe80bc9-0635-0c9b-5daf-bd98574e06ec@digitalbrains.com>
Message-ID: <f766e22bf6b34614a184d437aa5ecdf4@idspage.com>

Hi Peter,
We need passphrase, but passphrase should be enter via code not from windows popup prompt.

Thanks & Regards

Aneesh Varghese

________________________________________
From: Peter Lebbing <peter at digitalbrains.com>
Sent: Wednesday, January 31, 2018 6:42 PM
To: Aneesh Varghese; gnupg-users at gnupg.org
Subject: Re: How to avoid Passphrase prompt

On 31/01/18 13:19, Aneesh Varghese wrote:
> is it possible to avoid the windows popup for entering the passphrase?

The simplest way to avoid the popup is to remove the passphrase from the
private key.

The private key is stored on your hard disk. If there is no passphrase
on the private key, anybody with access to your hard disk can decrypt
files. They can also do anything else with your key.

So you need to make sure that only you have access to the hard disk.

Is this acceptable?

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>



From dashohoxha at gmail.com  Thu Feb  1 09:32:39 2018
From: dashohoxha at gmail.com (Dashamir Hoxha)
Date: Thu, 1 Feb 2018 09:32:39 +0100
Subject: Lightning Talk at FOSDEM about EasyGnuPG
Message-ID: <CAMucfLwj_CFFVo0MYNaAU6XKNczCOpauPkb63GBYc9PzyTbN0Q@mail.gmail.com>

Hi,

I am going to have a lightning talk at FOSDEM about EasyGnuPG:
 - https://fosdem.org/2018/schedule/event/easy_gnupg/
 - https://slides.com/dashohoxha/easy-gnupg

In case somebody will be at FOSDEM, I invite you to participate.

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

From Cathy.Smith at pnnl.gov  Fri Feb  2 00:42:55 2018
From: Cathy.Smith at pnnl.gov (Smith, Cathy)
Date: Thu, 1 Feb 2018 23:42:55 +0000
Subject: How to avoid Passphrase prompt
In-Reply-To: <f766e22bf6b34614a184d437aa5ecdf4@idspage.com>
References: <c02ef08eb7a84e6082a0308b5ecabb59@idspage.com>
 <536b4678-dd6f-e574-06cf-ab6cda3f377b@digitalbrains.com>
 <c924075c0afd48349c0b6dd294901918@idspage.com>
 <47037cbe-106d-5cfb-f76e-7cb5b403e5ae@digitalbrains.com>
 <69cd8517e2c24e9593d8dc4a8fa87150@idspage.com>,
 <efe80bc9-0635-0c9b-5daf-bd98574e06ec@digitalbrains.com>
 <f766e22bf6b34614a184d437aa5ecdf4@idspage.com>
Message-ID: <270838A78E5A5342BB9669898FB4CF20198670D5@EX10MBOX01.pnnl.gov>

My experience is that gpg 2.2 seems to be more suited for the desktop environment than for a server environment or a remotely administered site.  We've been using gpg 1.4 (yes I know it is old) in batch mode for many years in a Red Hat environment.  Our server environment has grown increasingly restricted.  The gpg 2.2 windows pop up prompt is a real pain.  Another group that I used to do work for, just quit using gpg because they could not find a way around the pop up prompt in remote, batch installations.
 
Regards.


Cathy

--?
Cathy L. Smith
IT Engineer

Pacific Northwest National Laboratory
Operated by Battelle for the?
U.S. Department of Energy

Phone: 509.375.2687
Fax: ? ? ? 509.375.4399
Email: cathy.smith at pnnl.gov


-----Original Message-----
From: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] On Behalf Of Aneesh Varghese
Sent: Wednesday, January 31, 2018 8:03 PM
To: Peter Lebbing <peter at digitalbrains.com>; gnupg-users at gnupg.org
Subject: Re: How to avoid Passphrase prompt

Hi Peter,
We need passphrase, but passphrase should be enter via code not from windows popup prompt.

Thanks & Regards

Aneesh Varghese

________________________________________
From: Peter Lebbing <peter at digitalbrains.com>
Sent: Wednesday, January 31, 2018 6:42 PM
To: Aneesh Varghese; gnupg-users at gnupg.org
Subject: Re: How to avoid Passphrase prompt

On 31/01/18 13:19, Aneesh Varghese wrote:
> is it possible to avoid the windows popup for entering the passphrase?

The simplest way to avoid the popup is to remove the passphrase from the private key.

The private key is stored on your hard disk. If there is no passphrase on the private key, anybody with access to your hard disk can decrypt files. They can also do anything else with your key.

So you need to make sure that only you have access to the hard disk.

Is this acceptable?

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>


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


From dashohoxha at gmail.com  Fri Feb  2 04:45:52 2018
From: dashohoxha at gmail.com (Dashamir Hoxha)
Date: Fri, 2 Feb 2018 04:45:52 +0100
Subject: How to avoid Passphrase prompt
In-Reply-To: <270838A78E5A5342BB9669898FB4CF20198670D5@EX10MBOX01.pnnl.gov>
References: <c02ef08eb7a84e6082a0308b5ecabb59@idspage.com>
 <536b4678-dd6f-e574-06cf-ab6cda3f377b@digitalbrains.com>
 <c924075c0afd48349c0b6dd294901918@idspage.com>
 <47037cbe-106d-5cfb-f76e-7cb5b403e5ae@digitalbrains.com>
 <69cd8517e2c24e9593d8dc4a8fa87150@idspage.com>
 <efe80bc9-0635-0c9b-5daf-bd98574e06ec@digitalbrains.com>
 <f766e22bf6b34614a184d437aa5ecdf4@idspage.com>
 <270838A78E5A5342BB9669898FB4CF20198670D5@EX10MBOX01.pnnl.gov>
Message-ID: <CAMucfLxs6h3z0bc-hTTH1OXibTxbZoJ+4usd9EaLFaZEbsBbAg@mail.gmail.com>

On Fri, Feb 2, 2018 at 12:42 AM, Smith, Cathy <Cathy.Smith at pnnl.gov> wrote:

> My experience is that gpg 2.2 seems to be more suited for the desktop
> environment than for a server environment or a remotely administered site.
> We've been using gpg 1.4 (yes I know it is old) in batch mode for many
> years in a Red Hat environment.  Our server environment has grown
> increasingly restricted.  The gpg 2.2 windows pop up prompt is a real
> pain.  Another group that I used to do work for, just quit using gpg
> because they could not find a way around the pop up prompt in remote, batch
> installations.
>

There is always a solution or workaround, but it is a pain even for experts
to find it out.
It was a pain for me too (although I am not an expert). And I would not
remember it
if it was not for this piece of script:
https://github.com/dashohoxha/egpg/blob/gnupg-2.1/tests/setup.sh#L63-L69

So, the solution is to edit $GNUPGHOME/gpg-agent.conf and to change
'pinentry-program'
Then restart gpg-agent. You can set it to '/usr/bin/pinentry-tty' like this:
https://github.com/dashohoxha/egpg/blob/gnupg-2.1/src/cmd/init.sh#L25
In Debian/Ubuntu you have to install the package 'pinentry-tty'.

I have tried these on gpg2.1, but it should be the same for gpg2.

Regards,
Dashamir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180202/1706de0e/attachment.html>

From peter at digitalbrains.com  Fri Feb  2 12:23:37 2018
From: peter at digitalbrains.com (Peter Lebbing)
Date: Fri, 2 Feb 2018 12:23:37 +0100
Subject: How to avoid Passphrase prompt
In-Reply-To: <f766e22bf6b34614a184d437aa5ecdf4@idspage.com>
References: <c02ef08eb7a84e6082a0308b5ecabb59@idspage.com>
 <536b4678-dd6f-e574-06cf-ab6cda3f377b@digitalbrains.com>
 <c924075c0afd48349c0b6dd294901918@idspage.com>
 <47037cbe-106d-5cfb-f76e-7cb5b403e5ae@digitalbrains.com>
 <69cd8517e2c24e9593d8dc4a8fa87150@idspage.com>
 <efe80bc9-0635-0c9b-5daf-bd98574e06ec@digitalbrains.com>
 <f766e22bf6b34614a184d437aa5ecdf4@idspage.com>
Message-ID: <09361633-618a-96b2-e838-46861f72bed0@digitalbrains.com>

On 01/02/18 05:03, Aneesh Varghese wrote:
> Hi Peter,
> We need passphrase, but passphrase should be enter via code not from windows popup prompt.

Hah, now I understand! :-)

There are two methods: gpg-preset-passphrase and pinentry loopback.

gpg-preset-passphrase:

GNUPGHOME/gpg-agent.conf:
--8<---------------cut here---------------start------------->8---
allow-preset-passphrase
max-cache-ttl 2147483647
--8<---------------cut here---------------end--------------->8---

gpg --with-keygrip -K
--8<---------------cut here---------------start------------->8---
sec   rsa1024 2012-03-17 [SC] [expires: 2018-02-07]
      825472F37172B95ADC7349BE98B67DE4DCDFDFA4
      Keygrip = 2F677680CA15F6F7B963AF35822E8EC01FBF840A
uid           [  full  ] Test Teststra (Koning van Wezel) <test at example.invalid>
uid           [  full  ] Test Teststra <test at work.invalid>
ssb   rsa1024 2012-03-17 [E]
      Keygrip = 15CB764B81D542CF921978CA89910C69D53F4E2D
ssb   rsa2048 2016-01-12 [A]
      Keygrip = 3D88DC9D60F791821AF8D537EEAC3C8DF7720D63
--8<---------------cut here---------------end--------------->8---

Note keygrip for [E] subkey.

Do this every time after starting the server/starting gpg-agent, to unlock 
the key:

gpg-preset-passphrase --preset 15CB764B81D542CF921978CA89910C69D53F4E2D

(Type in the password. Currently no pinentry support.)

Done!

Second method: pinentry loopback.

This method has a problem. Your code supplies the passphrase. Where is 
the passphrase stored? If it is simply stored on the hard disk, the 
passphrase is probably useless. An attacker can just read the 
passphrase. What are you protecting against?

It is simple, though:

echo passphrase | gpg --batch --pinentry-mode loopback --passphrase-fd 0 -d test.gpg

(Use code to pass the passphrase on some FD, don't actually use echo).

All this was tried out on Linux. I don't have Windows, or the necessary 
knowledge. I think it should work on Windows.

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/20180202/407263df/attachment.sig>

From peter at digitalbrains.com  Fri Feb  2 12:52:02 2018
From: peter at digitalbrains.com (Peter Lebbing)
Date: Fri, 2 Feb 2018 12:52:02 +0100
Subject: Workaround for missing pinentry support in gpg-preset-passphrase?
 (was: How to avoid Passphrase prompt)
In-Reply-To: <09361633-618a-96b2-e838-46861f72bed0@digitalbrains.com>
References: <c02ef08eb7a84e6082a0308b5ecabb59@idspage.com>
 <536b4678-dd6f-e574-06cf-ab6cda3f377b@digitalbrains.com>
 <c924075c0afd48349c0b6dd294901918@idspage.com>
 <47037cbe-106d-5cfb-f76e-7cb5b403e5ae@digitalbrains.com>
 <69cd8517e2c24e9593d8dc4a8fa87150@idspage.com>
 <efe80bc9-0635-0c9b-5daf-bd98574e06ec@digitalbrains.com>
 <f766e22bf6b34614a184d437aa5ecdf4@idspage.com>
 <09361633-618a-96b2-e838-46861f72bed0@digitalbrains.com>
Message-ID: <a5e5a5e5-790d-84f4-0c56-28395c3d7925@digitalbrains.com>

On 02/02/18 12:23, Peter Lebbing wrote:
> Do this every time after starting the server/starting gpg-agent, to unlock 
> the key:
> 
> gpg-preset-passphrase --preset 15CB764B81D542CF921978CA89910C69D53F4E2D
> 
> (Type in the password. Currently no pinentry support.)

It is a pity gpg-preset-passphrase currently has no pinentry support.

While doing the dishes, I thought: can't we work around that for a bit? 
:-)

I'd like to know what people think of this hack:

--8<---------------cut here---------------start------------->8---
gpg-connect-agent -q '/datafile -' 'get_passphrase --data workaround:pass + Enter+passphrase: +' 'clear_passphrase workaround:pass' /bye | /usr/lib/gnupg2/gpg-preset-passphrase --preset 15CB764B81D542CF921978CA89910C69D53F4E2D
--8<---------------cut here---------------end--------------->8---

As far as I can tell, the first part neatly echoes a pinentry-obtained 
passphrase on stdout. This is then passed to gpg-preset-passphrase.

A neat work-around? Or an ugly hack that leads to system compromise, 
uncontrolled nuclear fusion in the processor and a new world war?

(By the way, I didn't know how to pass an empty string, and all the 
prompts are not optional despite what "help" says. So I passed single 
spaces for the text.)

Cheers,

Peter.

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

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

From aneesh at idspage.com  Fri Feb  2 12:32:46 2018
From: aneesh at idspage.com (Aneesh Varghese)
Date: Fri, 2 Feb 2018 11:32:46 +0000
Subject: How to avoid Passphrase prompt
In-Reply-To: <09361633-618a-96b2-e838-46861f72bed0@digitalbrains.com>
References: <c02ef08eb7a84e6082a0308b5ecabb59@idspage.com>
 <536b4678-dd6f-e574-06cf-ab6cda3f377b@digitalbrains.com>
 <c924075c0afd48349c0b6dd294901918@idspage.com>
 <47037cbe-106d-5cfb-f76e-7cb5b403e5ae@digitalbrains.com>
 <69cd8517e2c24e9593d8dc4a8fa87150@idspage.com>
 <efe80bc9-0635-0c9b-5daf-bd98574e06ec@digitalbrains.com>
 <f766e22bf6b34614a184d437aa5ecdf4@idspage.com>,
 <09361633-618a-96b2-e838-46861f72bed0@digitalbrains.com>
Message-ID: <f83ff3ae64f84ea98bb0c70925362adf@idspage.com>

Thanks Peter...

Thanks & Regards

Aneesh Varghese

________________________________________
From: Peter Lebbing <peter at digitalbrains.com>
Sent: Friday, February 2, 2018 4:53 PM
To: Aneesh Varghese; gnupg-users at gnupg.org
Subject: Re: How to avoid Passphrase prompt

On 01/02/18 05:03, Aneesh Varghese wrote:
> Hi Peter,
> We need passphrase, but passphrase should be enter via code not from windows popup prompt.

Hah, now I understand! :-)

There are two methods: gpg-preset-passphrase and pinentry loopback.

gpg-preset-passphrase:

GNUPGHOME/gpg-agent.conf:
--8<---------------cut here---------------start------------->8---
allow-preset-passphrase
max-cache-ttl 2147483647
--8<---------------cut here---------------end--------------->8---

gpg --with-keygrip -K
--8<---------------cut here---------------start------------->8---
sec   rsa1024 2012-03-17 [SC] [expires: 2018-02-07]
      825472F37172B95ADC7349BE98B67DE4DCDFDFA4
      Keygrip = 2F677680CA15F6F7B963AF35822E8EC01FBF840A
uid           [  full  ] Test Teststra (Koning van Wezel) <test at example.invalid>
uid           [  full  ] Test Teststra <test at work.invalid>
ssb   rsa1024 2012-03-17 [E]
      Keygrip = 15CB764B81D542CF921978CA89910C69D53F4E2D
ssb   rsa2048 2016-01-12 [A]
      Keygrip = 3D88DC9D60F791821AF8D537EEAC3C8DF7720D63
--8<---------------cut here---------------end--------------->8---

Note keygrip for [E] subkey.

Do this every time after starting the server/starting gpg-agent, to unlock
the key:

gpg-preset-passphrase --preset 15CB764B81D542CF921978CA89910C69D53F4E2D

(Type in the password. Currently no pinentry support.)

Done!

Second method: pinentry loopback.

This method has a problem. Your code supplies the passphrase. Where is
the passphrase stored? If it is simply stored on the hard disk, the
passphrase is probably useless. An attacker can just read the
passphrase. What are you protecting against?

It is simple, though:

echo passphrase | gpg --batch --pinentry-mode loopback --passphrase-fd 0 -d test.gpg

(Use code to pass the passphrase on some FD, don't actually use echo).

All this was tried out on Linux. I don't have Windows, or the necessary
knowledge. I think it should work on Windows.

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>



From syl-gnupg at sylops.com  Fri Feb  2 17:31:06 2018
From: syl-gnupg at sylops.com (Syl)
Date: Fri, 2 Feb 2018 17:31:06 +0100
Subject: [Poldi] PAM authentication error "failed to verify challenge"
Message-ID: <7b7c14aa-89bc-7a31-3877-ae2d2fccf099@sylops.com>

Hi there,

I'm the proud owner of a Nitrokey Pro OpenPGP card that works fine for
encryption and SSH authentication. I'd love to use it for sudo/login
operations as well, but I've had no luck so far in setting up Poldi for
PAM authentication.

Would you please let me know what I missed, or maybe how I could further
investigate?

Here is what I did:

  * My card contains 4096 bit encryption, signing and authentication
    subkeys.
  * I'm using GnuPG v2.1.15 on a regular Ubuntu 17.10 desktop.
  * Poldi was installed via the Ubuntu 17.10 "libpam-poldi" package.
  * I've associated the card Application ID with my system username
    within "/etc/poldi/localdb/users".
  * I've exported my public authentication subkey in a file named after
    the card Application ID within "/etc/poldi/localdb/keys/". Since
    "poldi-ctrl" is no longer available, and 'gpg-connect-agent
    "/datafile <app_id>" "SCD READKEY --advanced OPENPGP.3" "/bye"'
    would only yield "ERR 100663414 Invalid ID <SCD>", I've been using
    "gpg --export | openpgp2ssh <auth_subkey_fp> | ssh-conv | sexp-conv
    --syntax=hex" to produce the appropriate format, i.e. "(public-key
    (rsa-pkcs1-sha1 (n #00e2 ... 7#) (e #010001#)))".
  * I've replaced "@include common-auth" with "auth sufficient
    pam_poldi.so" in "/etc/pam.d/sudo".

And this is where I stand:

  * "sudo ls" is unsuccessful, though the card LED lights up (and the
    PIN is correct):
    Insert authentication card for user `syl'
    Trying authentication as user `syl'...
    Please enter the PIN
    Sorry, try again.
    Insert authentication card for user `syl'
    Trying authentication as user `syl'...
    Sorry, try again.
    Insert authentication card for user `syl'
    Trying authentication as user `syl'...
    sudo: 3 incorrect password attempts
  * "/var/log/poldi.log" doesn't give much details (card serial number
    edited by me):
    Poldi 2018-02-02 17:19:53 [23950] debug: using authentication method
    `localdb'
    Poldi 2018-02-02 17:19:54 [23950] debug: got scdaemon socket name
    from gpg-agent, connected to socket '/run/user/1000/gnupg/S.scdaemon'
    Poldi 2018-02-02 17:19:56 [23950] debug: Waiting for card for user
    `syl'...
    Poldi 2018-02-02 17:19:58 [23950] debug: connected to card; serial
    number is: D...0
    Poldi 2018-02-02 17:19:58 [23950] debug: Trying authentication as
    user `syl'...
    Poldi 2018-02-02 17:20:06 [23950] error: failed to verify challenge
    Poldi 2018-02-02 17:20:06 [23950] error: authentication failed:
    General error
    Poldi 2018-02-02 17:20:06 [23950] debug: using authentication method
    `localdb'
    Poldi 2018-02-02 17:20:06 [23950] debug: got scdaemon socket name
    from gpg-agent, connected to socket '/run/user/1000/gnupg/S.scdaemon'
    Poldi 2018-02-02 17:20:06 [23950] debug: Waiting for card for user
    `syl'...
    Poldi 2018-02-02 17:20:06 [23950] debug: connected to card; serial
    number is: D...0
    Poldi 2018-02-02 17:20:06 [23950] debug: Trying authentication as
    user `syl'...
    Poldi 2018-02-02 17:20:10 [23950] error: failed to verify challenge
    Poldi 2018-02-02 17:20:10 [23950] error: authentication failed:
    General error
    Poldi 2018-02-02 17:20:10 [23950] debug: using authentication method
    `localdb'
    Poldi 2018-02-02 17:20:10 [23950] debug: got scdaemon socket name
    from gpg-agent, connected to socket '/run/user/1000/gnupg/S.scdaemon'
    Poldi 2018-02-02 17:20:10 [23950] debug: Waiting for card for user
    `syl'...
    Poldi 2018-02-02 17:20:10 [23950] debug: connected to card; serial
    number is: D...0
    Poldi 2018-02-02 17:20:10 [23950] debug: Trying authentication as
    user `syl'...
    Poldi 2018-02-02 17:20:13 [23950] error: failed to verify challenge
    Poldi 2018-02-02 17:20:13 [23950] error: authentication failed:
    General error
  * For the record, "/etc/poldi/poldi.conf" reads as follows:
    auth-method localdb
    log-file /var/log/poldi.log
    debug

Thanks in advance for your help, best regards,

--Syl

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

From fuzzy_drawrings at protonmail.com  Sat Feb  3 06:25:05 2018
From: fuzzy_drawrings at protonmail.com (FuzzyDrawrings)
Date: Sat, 03 Feb 2018 00:25:05 -0500
Subject: draft-ietf-openpgp-rfc4880bis-04
Message-ID: <5sqhZYgAJfgRAcXAZkAfqU-D7bKvhlrgn50v3Y0xJMcHSAIK35ZL0GkURbMR8K2WwgbqtSD16CZRXMdxYttObWALX_omY4qzztA_23SGd9U=@protonmail.com>

I don't know if this is an error in the documentation, but I cannot obtain the sha256 result here:

| A.2.  Sample EdDSA signature
| 
|    The signature is created using the sample key over the input data
|    "OpenPGP" on 2015-09-16 12:24:53 and thus the input to the hash
|    function is:
| 
|    m: 4f70656e504750040016080006050255f95f9504ff0000000c
| 
|    Using the SHA2-256 hash algorithm yields the digest:
| 
|    d: f6220a3f757814f4c2176ffbb68b00249cd4ccdc059c4b34ad871f30b1740280

I can obtain m, no problem. But fail to obtain d as m's sha256 digest.

Instead I repeatedly get:
d: 30d3de39f655d86b516058ae8c483f1a2cc10f0048882794655d4ce910abb7d6

Can anyone check if they are able to get the result shown in the documentation? And if so, is there anything else in addition to m that is input for the sha256 hash?


From tapio.sokura at iki.fi  Sat Feb  3 16:05:13 2018
From: tapio.sokura at iki.fi (Tapio Sokura)
Date: Sat, 3 Feb 2018 17:05:13 +0200
Subject: draft-ietf-openpgp-rfc4880bis-04
In-Reply-To: <5sqhZYgAJfgRAcXAZkAfqU-D7bKvhlrgn50v3Y0xJMcHSAIK35ZL0GkURbMR8K2WwgbqtSD16CZRXMdxYttObWALX_omY4qzztA_23SGd9U=@protonmail.com>
References: <5sqhZYgAJfgRAcXAZkAfqU-D7bKvhlrgn50v3Y0xJMcHSAIK35ZL0GkURbMR8K2WwgbqtSD16CZRXMdxYttObWALX_omY4qzztA_23SGd9U=@protonmail.com>
Message-ID: <787fc105-d18a-a5bf-7f21-d6f7b7915840@iki.fi>

Hello,

On 3.2.2018 7:25, FuzzyDrawrings via Gnupg-users wrote:
> |    m: 4f70656e504750040016080006050255f95f9504ff0000000c
> |
> |    Using the SHA2-256 hash algorithm yields the digest:
> |
> |    d: f6220a3f757814f4c2176ffbb68b00249cd4ccdc059c4b34ad871f30b1740280
> 
> I can obtain m, no problem. But fail to obtain d as m's sha256 digest.
> 
> Instead I repeatedly get:
> d: 30d3de39f655d86b516058ae8c483f1a2cc10f0048882794655d4ce910abb7d6
> 
> Can anyone check if they are able to get the result shown in the documentation? And if so, is there anything else in addition to m that is input for the sha256 hash?

I haven't read the context of the draft, so I don't know whether the 
sample 'm' is formed correctly, but this is what I get with the 'm' 
listed above being in file testvec:

$ od -t x1 testvec
0000000 4f 70 65 6e 50 47 50 04 00 16 08 00 06 05 02 55
0000020 f9 5f 95 04 ff 00 00 00 0c
0000031
$ sha256sum testvec
f6220a3f757814f4c2176ffbb68b00249cd4ccdc059c4b34ad871f30b1740280  testvec

So it matches with the document. Are you sure the 'm' you end up is 
exactly the same as in the draft?

   Tapio


From pijus.kar at gmail.com  Sat Feb  3 16:15:30 2018
From: pijus.kar at gmail.com (Pijus Kar)
Date: Sat, 3 Feb 2018 09:15:30 -0600
Subject: Can't import public key
Message-ID: <CAMk6Qq=ZmFCcmX_pcmxMBAOj77x-h_xmRJg5Bw5wiLn8Xn=KEA@mail.gmail.com>

Hi,

We are using GnuPG 1.2.1 on AIX. We are trying to import a public key
received from others which is generated on GnuPG v2.
Will there be any problem importing the public key. While importing we are
getting below error -

gpg: key 1D75115C: invalid self-signature on user id xxx xxx xxx
gpg: key 1D75115C: invalid subkey binding
gpg: key 1D75115C: no valid user IDs
gpg: this may be caused by a missing self-signature

Is it something for the version incompatibility or in the key?


Regards,
Pijus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180203/4d755b6f/attachment.html>

From dirk.gottschalk1980 at googlemail.com  Sat Feb  3 23:55:40 2018
From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk)
Date: Sat, 03 Feb 2018 23:55:40 +0100
Subject: Can't import public key
In-Reply-To: <CAMk6Qq=ZmFCcmX_pcmxMBAOj77x-h_xmRJg5Bw5wiLn8Xn=KEA@mail.gmail.com>
References: <CAMk6Qq=ZmFCcmX_pcmxMBAOj77x-h_xmRJg5Bw5wiLn8Xn=KEA@mail.gmail.com>
Message-ID: <1517698540.9614.1.camel@googlemail.com>

Hi.

Are you sure it is a RSA key and noit an ECC key?

AFAIK is gpg < 2.X not capable of working with ECC keys.

Regards,
Dirk


Am Samstag, den 03.02.2018, 09:15 -0600 schrieb Pijus Kar:
> Hi,
> 
> We are using GnuPG 1.2.1 on AIX. We are trying to import a public key
> received from others which is generated on GnuPG v2.
> Will there be any problem importing the public key. While importing
> we are
> getting below error -
> 
> gpg: key 1D75115C: invalid self-signature on user id xxx xxx xxx
> gpg: key 1D75115C: invalid subkey binding
> gpg: key 1D75115C: no valid user IDs
> gpg: this may be caused by a missing self-signature
> 
> Is it something for the version incompatibility or in the key?
> 
> 
> Regards,
> Pijus
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
-- 
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/20180203/f9e6ce5a/attachment.sig>

From dkg at fifthhorseman.net  Sun Feb  4 03:23:12 2018
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Sat, 03 Feb 2018 21:23:12 -0500
Subject: Can't import public key
In-Reply-To: <CAMk6Qq=ZmFCcmX_pcmxMBAOj77x-h_xmRJg5Bw5wiLn8Xn=KEA@mail.gmail.com>
References: <CAMk6Qq=ZmFCcmX_pcmxMBAOj77x-h_xmRJg5Bw5wiLn8Xn=KEA@mail.gmail.com>
Message-ID: <87wozt333j.fsf@fifthhorseman.net>

On Sat 2018-02-03 09:15:30 -0600, Pijus Kar wrote:

> We are using GnuPG 1.2.1 on AIX. We are trying to import a public key
> received from others which is generated on GnuPG v2.
> Will there be any problem importing the public key. While importing we are
> getting below error -

gnupg 1.2.1 is positively ancient (over 15 years old) with many many
known problems.  please upgrade to a newer version of GnuPG.

Regards,

        --dkg


From g1363333 at icloud.com  Sun Feb  4 05:35:23 2018
From: g1363333 at icloud.com (=?utf-8?B?6YOt5bCP6I+y?=)
Date: Sun, 04 Feb 2018 12:35:23 +0800
Subject: =?utf-8?B?6YOt5bCP6I+y?=
Message-ID: <0B4A3490-B526-423B-87D4-8DCC880CE544@icloud.com>



???

From g1363333 at icloud.com  Sun Feb  4 05:34:15 2018
From: g1363333 at icloud.com (=?utf-8?B?6YOt5bCP6I+y?=)
Date: Sun, 04 Feb 2018 12:34:15 +0800
Subject: =?utf-8?B?6YOt5bCP6I+y?=
Message-ID: <938B8875-47FE-4B7D-A674-7DA3911D63CA@icloud.com>




???

From edgar at pettijohn-web.com  Sun Feb  4 08:44:36 2018
From: edgar at pettijohn-web.com (Edgar Pettijohn)
Date: Sun, 4 Feb 2018 01:44:36 -0600
Subject: entropy gathering daemon
Message-ID: <f06df1b1-cf8a-506b-9f1b-fe14cffe584b@pettijohn-web.com>

Is it no longer possible to use egd? Most of the info I can find seems 
rather old, and so far I haven't been able to find a way to make it 
work. If it is still possible how do I do it.

Thanks in advance,


Edgar



From rjh at sixdemonbag.org  Sun Feb  4 11:43:46 2018
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Sun, 4 Feb 2018 05:43:46 -0500
Subject: Can't import public key
In-Reply-To: <CAMk6Qq=ZmFCcmX_pcmxMBAOj77x-h_xmRJg5Bw5wiLn8Xn=KEA@mail.gmail.com>
References: <CAMk6Qq=ZmFCcmX_pcmxMBAOj77x-h_xmRJg5Bw5wiLn8Xn=KEA@mail.gmail.com>
Message-ID: <837b7886-86a3-c531-76e7-f459e384a136@sixdemonbag.org>

> We are using GnuPG 1.2.1 on AIX.

Please don't.  GnuPG 1.2.1 dates back to *October 2002*.  It's fifteen
years old and was EOLed ages ago.  There are many known problems with
it.  Please upgrade.

> Will there be any problem importing the public key. While importing we
> are getting below error -

You'll find few people here will be able to help you, I'm afraid.  :(


From kristian.fiskerstrand at sumptuouscapital.com  Mon Feb  5 11:38:42 2018
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Mon, 5 Feb 2018 11:38:42 +0100
Subject: Can't import public key
In-Reply-To: <CAMk6Qq=ZmFCcmX_pcmxMBAOj77x-h_xmRJg5Bw5wiLn8Xn=KEA@mail.gmail.com>
References: <CAMk6Qq=ZmFCcmX_pcmxMBAOj77x-h_xmRJg5Bw5wiLn8Xn=KEA@mail.gmail.com>
Message-ID: <4e8d15b3-0336-0379-434c-61856f21b622@sumptuouscapital.com>

On 02/03/2018 04:15 PM, Pijus Kar wrote:
> Is it something for the version incompatibility or in the key?

As far as I can see the keyblock referenced is DSA2, which is specified
in FIPS-186-3 from 2009, and you're using a gnupg version from 2002.

-- 
----------------------------
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
----------------------------
"Knowing is not enough; we must apply. Willing is not enough; we must do."
(Johann Wolfgang von Goethe)

-------------- 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/20180205/fd6bac32/attachment.sig>

From JLightner at dsservices.com  Mon Feb  5 16:41:41 2018
From: JLightner at dsservices.com (Lightner, Jeffrey)
Date: Mon, 5 Feb 2018 15:41:41 +0000
Subject: gpg: do_plaintext(): wrote 1210414045 bytes but expected 822504068
 bytes
Message-ID: <BN6PR07MB3073C150C221166C3FD98F7CC1FE0@BN6PR07MB3073.namprd07.prod.outlook.com>

Basic questions:
1) Is the above message in fact an "error"?
2) What exactly does it mean?
3) Why does it appear to be backwards? (i.e. Why is the first number it says it "wrote" larger than what it says it "expected"?
4) How can I detect when this occurs as an "error" to prevent the encryption so re-encryption can be re-attempted?

DETAILS:
We create an ascii armored (encrypted) file using GPG via a script we run via cron once a week (which has been running for years). The file is then uploaded to a bank partner.

It was reported by our cash team that a file uploaded  a few weekends ago  (Dec 31st) had a variance of some 1.3 Million records when they tried to reconcile it.  It is normal to have some variance but this was extreme.

On reviewing the log then I saw the following message which appears to have come from the actual encryption of the original file:

gpg: do_plaintext(): wrote 1210414045 bytes but expected 822504068 bytes

That appeared to me to be an error but it didn't prevent the ascii armored (encrypted) file from being created (and subsequently uploaded).

The original unencrypted file has nearly the same byte count (1210414056) as the first number (1210414045) in above message. A difference of 11 bytes.

The encrypted file it created was 331941767 bytes.

When I re-encrypted the original file the new encrypted file was:
331941796 bytes. (I did that a couple of times and got the same size.) I did NOT see the above message on my re-encryption runs.

There seems to be almost no information about this do_plaintext message. Most of what I found online including this list is a repeat of the same question copied to various other sites. The discussion on that question seems to blithely ignore the actual error but instead goes into other commands (tar, time, etc...) in that user's command line (pipeline).

I reviewed the man page for gpg and found this tantalizing information:
"--exit-on-status-write-error
This option will cause write errors on the status FD to immedi-
ately terminate the process. That should in fact be the default
but it never worked this way and thus we need an option to
enable this, so that the change won't break applications which
close their end of a status fd connected pipe too early. Using
this option along with --enable-progress-filter may be used to
cleanly cancel long running gpg operations."

That seemed to explain why it didn't actually cause our script to error out. On adding the above flag to my encryption it created a slightly different size file of 331941792 bytes.

Looking back in our log I saw we'd occasionally had similar message in the past (most recently before this particular event at end of December was back in October) but in those earlier runs the difference between first and second number was significantly smaller. This may have led to it appearing to be normal variance in records during reconciliation so no one questioned it.

I added the above flag in hopes it would force the encryption to error out.   The next 2 weekends the message did not recur.   However, on the past 2 weekends I've again seen small variances so it appears adding the flag didn't have the desired effect as in both cases it still encrypted the file and our script sent it to the bank.   The 2 most recent events show the small variance I'd seen in events prior to the January one:
January 28th:  gpg: do_plaintext(): wrote 1211934615 bytes but expected 1211934604 bytes
February 4th:  gpg: do_plaintext(): wrote 1212698432 bytes but expected 1212698421 bytes

Answers to questions some will ask:
1) The original file size we encrypt is always extremely large so it is not the size that caused this issue.  As noted I re-ran the encryption manually several times for the original large file successfully so if size were an issue I'd expect one of those runs to have failed similarly yet none did.

2) We did NOT run out of space on the filesystem (or on any other filesystem such as /tmp) during the encryption. There is plenty of space.

3) The command line we used to do the encryption without the new flag was:
/usr/bin/gpg --always-trust --armor --recipient <RECIPIENT> -o <BASEFILENAME.dat.asc> --encrypt <BASEFILENAME.dat.txfr>
Where <BASEFILENAME.dat.asc> is the encrypted file and <BASEFILENAME.dat.txfr> is the original unencrypted file.

4) The command line with the new flag:
/usr/bin/gpg --exit-on-status-write-error --always-trust --armor --recipient <RECIPIENT BANK ID> -o <BASEFILENAME.dat.asc> --encrypt <BASEFILENAME.dat.txfr>

5) I can't decrypt the file created because the recipient uses the bank's public key so only the bank can decrypt it with their private key.

6) Linux distro/version is RHEL6.9

7) gpg --version outputs:
gpg (GnuPG) 2.0.14
libgcrypt 1.4.5
Copyright (C) 2009 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.
Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA
Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128,
CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

8) The full RHEL6 version package is gnupg2-2.0.14-8.el6.x86_64.   There is no newer version of gnupg2 in the RHEL 6 repositories.

Please do not suggest installing newer upstream version unless you can point me to a change log that shows it specifically addresses the do_plaintext issue I'm seeing.   RedHat backports bug and security fixes into their version so it is not exactly the same as the upstream version reported by the --version flag above.    If there is such a bug fix I'd like to open a case with RedHat to see why it hasn't been backported into their version.


CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you




From edgar at pettijohn-web.com  Tue Feb  6 06:25:41 2018
From: edgar at pettijohn-web.com (Edgar Pettijohn)
Date: Mon, 5 Feb 2018 23:25:41 -0600
Subject: [patches] add support for arc4random_buf()
Message-ID: <82c9df41-d71b-a601-193f-df0c1d098a15@pettijohn-web.com>

Please see attached patches to add support for arc4random_buf() as an 
alternate to /dev/{u}random. I tried to be as unobtrusive as possible 
and maintain style. It should also allow the user to still define 
RANDOM_CONF_ONLY_URANDOM if they would prefer to use /dev/urandom. This 
will allow gpg to be used on filesystems mounted nodev while providing 
quick, quality randomness.


Thanks,


Edgar Pettijohn

-------------- next part --------------
A non-text attachment was scrubbed...
Name: configure.ac.patch
Type: text/x-patch
Size: 431 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180205/0b284e22/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rndlinux.c.patch
Type: text/x-patch
Size: 873 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180205/0b284e22/attachment-0001.bin>

From guru at unixarea.de  Tue Feb  6 06:47:23 2018
From: guru at unixarea.de (Matthias Apitz)
Date: Tue, 6 Feb 2018 06:47:23 +0100
Subject: OpenPGP card && exporting secret keys
Message-ID: <20180206054723.GA2626@c720-r314251>



Hello,

I'm using an OpenPGP card and gnupg 2.1.19 on my FreeBSD workstations
and my Ubuntu mobile device to store crypted passwords (tool: password-store),
to lock/unlock desktop sessions and to sign emails. This is all working
fine and without any hick-ups.

What makes me worry, is that single point of failure: the OpenPGP card.

While I do backups of alls the encrypted password files, they would be
all useless in case of lost/teft of the token or hardware fault of the SIM
card.

What I do at the moment is something like:

$ find ~/.password-store -name '*.gpg' -exec printf "%s:\n" {} \;
  -and -exec gpg2 -d {} 2> /dev/null \; 
  -and -exec echo \; > /tmp/clear-password-store.txt

$ GNUPGHOME=...
$ gpg -ea /tmp/clear-password-store.txt
$ mv /tmp/clear-password-store.txt.asc $GNUPGHOME
$ rm -P /tmp/clear-password-store.txt

where the other GNUPGHOME contains secret and pub-keys created for this
special purpose and living outside (i.e. without) the OpenPGP card.
ANd in case of lost/teft of the token I could recover at least all
passwords again...

Is there any way to export the secret keys from the OpenPGP card to use
them directly (with a passphrase) and without the OpenPGP card?

Thanks

	matthias


-- 
Matthias Apitz, ? guru at unixarea.de, ? http://www.unixarea.de/  ? +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

Thanks to the Soviet Army for the Victory in Stalingrad! -- ?????? ? ?????????????? ?????!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180206/f40e2a91/attachment.sig>

From Roman.Fiedler at ait.ac.at  Tue Feb  6 10:24:34 2018
From: Roman.Fiedler at ait.ac.at (Fiedler Roman)
Date: Tue, 6 Feb 2018 09:24:34 +0000
Subject: PGP-compatible USB-crypto-token with biometry support
Message-ID: <2ECE9D9EEF1F524185270138AE23265955B46656@S0MSMAIL112.arc.local>

Hello List,

Is there anyone having experience with crypto-tokens to be unlocked by biometry using a match-on-chip scheme?

If so, which matchers are supported by hardware or is it possible to install them by yourself, e.g. for iris-scan if native hw-matcher does not support it or should be replaced by a better, newer implementation.

Thanks for any feedback,
Roman

ROMAN FIEDLER
Scientist
Information Management
Center for Digital Safety & Security

AIT Austrian Institute of Technology GmbH
Reininghausstra?e 13/1 | 8020 Graz | Austria
T +43 50550-2957 | M +43 664 8561599 | F +43 50550-2950
roman.fiedler at ait.ac.at | https://www.ait.ac.at

View my researcher profile: https://www.ait.ac.at/profile/detail/Fiedler-Roman/

FN: 115980 i HG Wien | UID: ATU14703506
www.ait.ac.at/Email-Disclaimer


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4814 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180206/bd539b8f/attachment-0001.bin>

From pete at heypete.com  Tue Feb  6 09:18:44 2018
From: pete at heypete.com (Pete Stephenson)
Date: Tue, 6 Feb 2018 09:18:44 +0100
Subject: OpenPGP card && exporting secret keys
In-Reply-To: <20180206054723.GA2626@c720-r314251>
References: <20180206054723.GA2626@c720-r314251>
Message-ID: <5A7964E4.6080504@heypete.com>

On 2/6/2018 6:47 AM, Matthias Apitz wrote:
> Is there any way to export the secret keys from the OpenPGP card to use
> them directly (with a passphrase) and without the OpenPGP card?

Short answer: No.

Longer answer: The OpenPGP card does not permit the export of keys it
stores. That's the whole point of using the card.

If you generate new keys on the card itself, there's never any way of
exporting them. If the card is lost or damaged, so are the keys.

However, if you generate new keys on a computer, you can make a backup
of the keys before you import them onto the card. If you haven't already
done this before importing them onto the card, you're out of luck.

Cheers!
-Pete

-- 
Pete Stephenson


From peter at digitalbrains.com  Tue Feb  6 10:51:30 2018
From: peter at digitalbrains.com (Peter Lebbing)
Date: Tue, 6 Feb 2018 10:51:30 +0100
Subject: gpg: do_plaintext(): wrote 1210414045 bytes but expected
 822504068 bytes
In-Reply-To: <BN6PR07MB3073C150C221166C3FD98F7CC1FE0@BN6PR07MB3073.namprd07.prod.outlook.com>
References: <BN6PR07MB3073C150C221166C3FD98F7CC1FE0@BN6PR07MB3073.namprd07.prod.outlook.com>
Message-ID: <1122f72e-dd5f-b197-7c3f-fde7438344ea@digitalbrains.com>

On 05/02/18 16:41, Lightner, Jeffrey wrote:
> 3) The command line we used to do the encryption without the new flag was:
> /usr/bin/gpg --always-trust --armor --recipient <RECIPIENT> -o <BASEFILENAME.dat.asc> --encrypt <BASEFILENAME.dat.txfr>
> Where <BASEFILENAME.dat.asc> is the encrypted file and <BASEFILENAME.dat.txfr> is the original unencrypted file.
> 
> 4) The command line with the new flag:
> /usr/bin/gpg --exit-on-status-write-error --always-trust --armor --recipient <RECIPIENT BANK ID> -o <BASEFILENAME.dat.asc> --encrypt <BASEFILENAME.dat.txfr>

While you are waiting for someone who knows what's going on to answer, I
think you should try to add --batch to the command line. Any
non-interactive use of the gpg binary always needs to have --batch. The
same pretty much goes for --with-colons, I don't know whether or how you
interpret output from gpg, but --with-colons gives you the
machine-readable form.

It's possible that it behaves a bit more pleasantly for this problem
with --batch, as it now understands that it's being used as such.

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/20180206/62ae368c/attachment.sig>

From peter at digitalbrains.com  Tue Feb  6 11:03:19 2018
From: peter at digitalbrains.com (Peter Lebbing)
Date: Tue, 6 Feb 2018 11:03:19 +0100
Subject: OpenPGP card && exporting secret keys
In-Reply-To: <20180206054723.GA2626@c720-r314251>
References: <20180206054723.GA2626@c720-r314251>
Message-ID: <0f037d22-2d03-b660-7e66-f331857bdf2d@digitalbrains.com>

On 06/02/18 06:47, Matthias Apitz wrote:
> Is there any way to export the secret keys from the OpenPGP card to use
> them directly (with a passphrase) and without the OpenPGP card?

You need to do it the other way around: you need to create on-disk keys
and export them to a card. It is explicitly not possible to get a secret
key /from/ an OpenPGP card.

If you chose to have a backup of your encryption key while generating
card keys, this is what actually happens for the encryption key, but in
a streamlined process. The backup file that is created in that way can
be used to populate a new OpenPGP card once your current one breaks, but
only for the encryption subkey. It contains the actual private key material.

I think it will generate signature and authentication keys on the card;
I don't use this mode because I have more trust in GnuPG's random number
generator than any RNG on a smartcard. So I always just create an
on-disk key, back that up, and subsequently move the keys to the card.
Obviously you need to think about data left on disk after removal of
files; I'm just giving a quick outline. Hint: I don't have a hard disk
plugged into the system I'm using to do this.

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/20180206/9d2db04f/attachment.sig>

From andrewg at andrewg.com  Tue Feb  6 11:16:07 2018
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Tue, 6 Feb 2018 10:16:07 +0000
Subject: OpenPGP card && exporting secret keys
In-Reply-To: <0f037d22-2d03-b660-7e66-f331857bdf2d@digitalbrains.com>
References: <20180206054723.GA2626@c720-r314251>
 <0f037d22-2d03-b660-7e66-f331857bdf2d@digitalbrains.com>
Message-ID: <00916c71-8ea4-cf96-08dc-2501de564d27@andrewg.com>

On 06/02/18 10:03, Peter Lebbing wrote:
> So I always just create an
> on-disk key, back that up, and subsequently move the keys to the card.
> Obviously you need to think about data left on disk after removal of
> files; I'm just giving a quick outline. Hint: I don't have a hard disk
> plugged into the system I'm using to do this.

I recommend using an offline system to do this; then you don't need to
worry about leaving traces behind. Tails is a good solution, as it
provides an encrypted persistent partition and comes with a recent gnupg
preinstalled.

-- 
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/20180206/1f773bf9/attachment.sig>

From ndk.clanbo at gmail.com  Tue Feb  6 10:12:14 2018
From: ndk.clanbo at gmail.com (NdK)
Date: Tue, 6 Feb 2018 10:12:14 +0100
Subject: OpenPGP card && exporting secret keys
In-Reply-To: <20180206054723.GA2626@c720-r314251>
References: <20180206054723.GA2626@c720-r314251>
Message-ID: <8ba422c7-637d-093f-06fa-609572712a86@gmail.com>

Il 06/02/2018 06:47, Matthias Apitz ha scritto:

> Is there any way to export the secret keys from the OpenPGP card to use
> them directly (with a passphrase) and without the OpenPGP card?
Not possible by design.

What you can do is generate the key on the machine, then copy (not move)
it to the card. But if you already generated it on-card you're toast.
A possible workaround could be encrypting the password store to multiple
"recipients" instead on only one (the GPGcard). Those multiple recipents
can be everything you want: GPGcards, keys on disk, other people...

BYtE,
 Diego



From wk at gnupg.org  Tue Feb  6 13:35:02 2018
From: wk at gnupg.org (Werner Koch)
Date: Tue, 06 Feb 2018 13:35:02 +0100
Subject: [patches] add support for arc4random_buf()
In-Reply-To: <82c9df41-d71b-a601-193f-df0c1d098a15@pettijohn-web.com> (Edgar
 Pettijohn's message of "Mon, 5 Feb 2018 23:25:41 -0600")
References: <82c9df41-d71b-a601-193f-df0c1d098a15@pettijohn-web.com>
Message-ID: <87607axpmx.fsf@wheatstone.g10code.de>

On Tue,  6 Feb 2018 06:25, edgar at pettijohn-web.com said:
> Please see attached patches to add support for arc4random_buf() as an
> alternate to /dev/{u}random. I tried to be as unobtrusive as possible
> and maintain style. It should also allow the user to still define
> RANDOM_CONF_ONLY_URANDOM if they would prefer to use
> /dev/urandom. This will allow gpg to be used on filesystems mounted
> nodev while providing quick, quality randomness.

Please describe what arc4random_buf is and where it is used.

I also redirect this to the libgcrypt mailing list.


Salam-Shalom,

   Werner

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

From wk at gnupg.org  Tue Feb  6 13:31:36 2018
From: wk at gnupg.org (Werner Koch)
Date: Tue, 06 Feb 2018 13:31:36 +0100
Subject: gpg: do_plaintext(): wrote 1210414045 bytes but expected
 822504068 bytes
In-Reply-To: <BN6PR07MB3073C150C221166C3FD98F7CC1FE0@BN6PR07MB3073.namprd07.prod.outlook.com>
 (Jeffrey Lightner's message of "Mon, 5 Feb 2018 15:41:41 +0000")
References: <BN6PR07MB3073C150C221166C3FD98F7CC1FE0@BN6PR07MB3073.namprd07.prod.outlook.com>
Message-ID: <87a7wmxpsn.fsf@wheatstone.g10code.de>

On Mon,  5 Feb 2018 16:41, JLightner at dsservices.com said:
> Basic questions:
> 1) Is the above message in fact an "error"?

Yes.  It may either indicate an internal error in gpg or a wrong usage
(see next).

> 2) What exactly does it mean?

When starting the encryption and if possible gpg records the lengths of
the input file.  During encryption the actually read and written bytes
are counted and compared to the size recorded at the start of the
encryption.

This is only done if the input is a regular file and its size is less
than about 4 GiB (due to the OpenPGP specs).

Are you sure that no other process is writing to the file whilst gpg is
encrypting it?  Recall that a file may already be unlinked but a process
may still write to the inode.

> 3) Why does it appear to be backwards? (i.e. Why is the first number it says it "wrote" larger than what it says it "expected"?

See above.

> 4) How can I detect when this occurs as an "error" to prevent the
> encryption so re-encryption can be re-attempted?

Pipe the data to gog and you won't get that error messages.  However, it
might be slower that working directly on a file.  That depends on a lot
of factors.

> "--exit-on-status-write-error

> That seemed to explain why it didn't actually cause our script to
> error out. On adding the above flag to my encryption it created a

You don't use the --status-fd option and thus this option does not make
a difference.  Diagnostics like the one you see won't necessary
terminate the operation immediate but set a flag to finally return a
failure exit code.

> 1) The original file size we encrypt is always extremely large so it
> is not the size that caused this issue.  As noted I re-ran the
> encryption manually severa

Weel, it is less than 4 GiB.  You should not see that diagnostic for a
file of 4 GiB or larger.  If my guess on the error is right, you won't
catch the incorrect use of gpg in this case.

> 3) The command line we used to do the encryption without the new flag was:
> /usr/bin/gpg --always-trust --armor --recipient <RECIPIENT> -o <BASEFILENAME.dat.asc> --encrypt <BASEFILENAME.dat.txfr>
> Where <BASEFILENAME.dat.asc> is the encrypted file and <BASEFILENAME.dat.txfr> is the original unencrypted file.

I have two suggestions independent of the problem

 - Use the option "--batch" to make sure that gpg will never ask the
   user. 

 - If you know that the file is already compressed you should use the
   option "-z 0" to disable gpg's internal compression.  Without that
   option gpg will guess whether to compress or not.

> 5) I can't decrypt the file created because the recipient uses the bank's public key so only the bank can decrypt it with their private key.

If you need you can encrypt to a second key by adding

  --recipient MYOWNKEY

> 7) gpg --version outputs:
> gpg (GnuPG) 2.0.14

That is pretty old (from 2009) and I hope that Redhat patched it to fix
a few security problems.  The current version is 2.0.31 but the 2.0
branch reach edn-of-life a month ago.  A quick look at the code didn't
reveal any bug fix which could be relevant to you problem, though.

> do_plaintext issue I'm seeing.  RedHat backports bug and security
> fixes into their version so it is not exactly the same as the upstream

I know that.  Thanks for answering possible questions in advance.


Shalom-Salam,

   Werner

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

From wk at gnupg.org  Tue Feb  6 13:38:58 2018
From: wk at gnupg.org (Werner Koch)
Date: Tue, 06 Feb 2018 13:38:58 +0100
Subject: draft-ietf-openpgp-rfc4880bis-04
In-Reply-To: <5sqhZYgAJfgRAcXAZkAfqU-D7bKvhlrgn50v3Y0xJMcHSAIK35ZL0GkURbMR8K2WwgbqtSD16CZRXMdxYttObWALX_omY4qzztA_23SGd9U=@protonmail.com>
 (FuzzyDrawrings via Gnupg-users's message of "Sat, 03 Feb 2018
 00:25:05 -0500")
References: <5sqhZYgAJfgRAcXAZkAfqU-D7bKvhlrgn50v3Y0xJMcHSAIK35ZL0GkURbMR8K2WwgbqtSD16CZRXMdxYttObWALX_omY4qzztA_23SGd9U=@protonmail.com>
Message-ID: <871shyxpgd.fsf@wheatstone.g10code.de>

On Sat,  3 Feb 2018 06:25, gnupg-users at gnupg.org said:
> I don't know if this is an error in the documentation, but I cannot obtain the sha256 result here:

Using the gpg option 

   --debug hashing

will create files with the hashed material.  This is often very helful.


Shalom-Salam,

   Werner

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

From edgar at pettijohn-web.com  Tue Feb  6 16:09:54 2018
From: edgar at pettijohn-web.com (edgar at pettijohn-web.com)
Date: Tue, 06 Feb 2018 09:09:54 -0600
Subject: [patches] add support for arc4random_buf()
Message-ID: <mailman.4.1517929821.30378.gnupg-users@gnupg.org>


On Feb 6, 2018 6:35 AM, Werner Koch <wk at gnupg.org> wrote:
>
> On Tue,? 6 Feb 2018 06:25, edgar at pettijohn-web.com said:
> > Please see attached patches to add support for arc4random_buf() as an
> > alternate to /dev/{u}random. I tried to be as unobtrusive as possible
> > and maintain style. It should also allow the user to still define
> > RANDOM_CONF_ONLY_URANDOM if they would prefer to use
> > /dev/urandom. This will allow gpg to be used on filesystems mounted
> > nodev while providing quick, quality randomness.
>
> Please describe what arc4random_buf is and where it is used.

The manual is probably the best source of information.

http://man.openbsd.org/arc4random

However, the tldr.

arc4random_buf() fills the buffer with nbytes of random data using the ChaCha20 cipher. It is thread safe. Every call stirs it more adding to it's randomness.

Thanks,

Edgar
>
> I also redirect this to the libgcrypt mailing list.
>
>
> Salam-Shalom,
>
> ?? Werner
>
> -- 
> Die Gedanken sind frei.? Ausnahmen regelt ein Bundesgesetz.

From MarshallAbrams at alumni.cmu.edu  Wed Feb  7 23:59:43 2018
From: MarshallAbrams at alumni.cmu.edu (Marshall D Abrams)
Date: Wed, 07 Feb 2018 17:59:43 -0500
Subject: Not enough information to check signature validity
Message-ID: <mailman.5.1518087043.30378.gnupg-users@gnupg.org>

A friends had to re-install gpg4win as a result of a hard disk 
failure. Since then, all encrypted files received from her come with 
a warning "Not enough information to check signature validity." What 
can I or she, do to eliminate this message?


Sincerely,
    Marshall D. Abrams

This e-mail is a natural product. The slight variations in spelling 
and grammar enhance its individual character and beauty and in no way 
are considered flaws or defects.

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

From fuzzy_drawrings at protonmail.com  Fri Feb  9 03:18:56 2018
From: fuzzy_drawrings at protonmail.com (FuzzyDrawrings)
Date: Thu, 08 Feb 2018 21:18:56 -0500
Subject: draft-ietf-openpgp-rfc4880bis-04
In-Reply-To: <871shyxpgd.fsf@wheatstone.g10code.de>
References: <5sqhZYgAJfgRAcXAZkAfqU-D7bKvhlrgn50v3Y0xJMcHSAIK35ZL0GkURbMR8K2WwgbqtSD16CZRXMdxYttObWALX_omY4qzztA_23SGd9U=@protonmail.com>
 <871shyxpgd.fsf@wheatstone.g10code.de>
Message-ID: <006Xx6eGf6U3Y0jk4v2FzYmvZJ94Ax4rnLxBBztvxP8WP3tL7IaYfwNvJCG85nHYkNAhqgsMSgWaIPuQThSqoq9ZIaX9iI4US75aRoL43pQ=@protonmail.com>


It is definitely my error in the m value I was hashing, which I failed to notice was not the same given in the documentation. I somehow repeatedly overlooked the fact that my obtained m value was different and only noticed that d (the hash) mismatch. Oops. 

Looking more carefully, I see did not in fact get the same value for m and am missing its trailing six octets 04ff0000000c.

Mystery solved. :)

But another more involved problem presents itself:

The value m is obtained as explained under "5.2.3.  {5.2.3} Version 4 Signature Packet Format"

| The concatenation of the data being signed and the signature data
| from the version number through the hashed subpacket data (inclusive)
| is hashed.

I can account for every part of that through the hashed subpacket data in the value m, but not in m's last six octets: 04ff0000000c

m: 4f70656e504750040016080006050255f95f9504ff0000000c
'4f70656e504750' is the text "OpenPGP" being signed.
'04' is the signature version
'00' is the signature type (Signature of a binary document)
'16' is the public-key algorithm (EdDSA)
'08' is the hash algorithm (SHA256)
'0006' is the length of following hashed subpackets (6 octets)
'05' is the length of the first hashed subpacket (5 octets)
'02' is the first hashed subpacket tag (Signature Creation Time)
'55f95f95' is the first hashed subpacket data (2014-08-19 14:28:27)

...and that's the end of hashed subpackets. That should be all that is hashed for the signature, yet there is the remaining octets in m:

 04ff0000000c

 I cannot figure out what information is contained in 04ff0000000c.  I'm sure the answer is some hilarious oversight on my part, but I'm stumped. :/


From ambrevar at gmail.com  Fri Feb  9 14:25:00 2018
From: ambrevar at gmail.com (Pierre Neidhardt)
Date: Fri, 09 Feb 2018 14:25:00 +0100
Subject: Use the same passphrase for PGP and SSH keys and get prompted only
 once by gpg-agent
Message-ID: <874lmqs3bn.fsf@gmail.com>


I use gpg-agent as my SSH agent.

I've successfully set it up, now whenever I restart gpg-agent (e.g. on
reboot), it will ask for the passphrase twice, once for the GPG keys,
once for the SSH keys, even though they are the same passphrases.

First setup: I called ssh-add to add existing SSH keys to GPG.
gpg-agent asked for a passphrase to encrypt the keys, so I presume the
passphrase must be different from the one I use for my GPG keys.  Isn't
it possible to tell GPG to "store the keys together" or to encrypt with
my GPG key?

Second setup: I created an authentication subkey which I use as an SSH
key. It works, but again, gpg-agent asks for my passphrase twice, while
this time the SSH key is obviously encrypted with the same passphrase as
my GPG key, since it's part of it.  Any clue why gpg-agent keeps asking?

-- 
Pierre Neidhardt

The universe is made of stories, not of atoms.
		-- Muriel Rukeyser
-------------- 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/20180209/31afebdb/attachment.sig>

From fishkits at hotmail.com  Fri Feb  9 16:35:13 2018
From: fishkits at hotmail.com (Anna Kitces and Seth Fishman)
Date: Fri, 9 Feb 2018 15:35:13 +0000
Subject: Solaris 11 install libgcrypt make install hangs
Message-ID: <BLUPR14MB0162C469C90CB899D6BAFE95DEF20@BLUPR14MB0162.namprd14.prod.outlook.com>

Hi

I ran ./configure, make, make check and entered make install over an hour ago

the make check was clean

If I hit ctrl-C, how do I proceed?

I am installing all the latest.

Trying to get GnuPG installed and these are pre-reqs

I am not a developer so not sure the impact of cancelling a make install. do I need to do an uninstall?

Sorry but kind of at a loss on what to do.

Thanks,

Seth Fishman

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

From fishkits at hotmail.com  Fri Feb  9 17:03:01 2018
From: fishkits at hotmail.com (Anna Kitces and Seth Fishman)
Date: Fri, 9 Feb 2018 16:03:01 +0000
Subject: Solaris 11 install libgpg-error make install hangs
In-Reply-To: <BLUPR14MB0162C469C90CB899D6BAFE95DEF20@BLUPR14MB0162.namprd14.prod.outlook.com>
References: <BLUPR14MB0162C469C90CB899D6BAFE95DEF20@BLUPR14MB0162.namprd14.prod.outlook.com>
Message-ID: <BLUPR14MB0162A701AF174C1B40E6AAE7DEF20@BLUPR14MB0162.namprd14.prod.outlook.com>

Correction. it is in libgpg-error this is happening


________________________________
From: Anna Kitces and Seth Fishman <fishkits at hotmail.com>
Sent: Friday, February 9, 2018 10:35 AM
To: gnupg-users at gnupg.org
Subject: Solaris 11 install libgcrypt make install hangs


Hi

I ran ./configure, make, make check and entered make install over an hour ago

the make check was clean

If I hit ctrl-C, how do I proceed?

I am installing all the latest.

Trying to get GnuPG installed and these are pre-reqs

I am not a developer so not sure the impact of cancelling a make install. do I need to do an uninstall?

Sorry but kind of at a loss on what to do.

Thanks,

Seth Fishman

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

From guru at unixarea.de  Sun Feb 11 09:29:58 2018
From: guru at unixarea.de (Matthias Apitz)
Date: Sun, 11 Feb 2018 09:29:58 +0100
Subject: problems sending to the list
Message-ID: <20180211082958.GA2158@c720-r314251>


Hello,

Sometimes I do SSH into my server of my ISP and send email to the list
from there. This always failes with the message below.

Can some list admin please check, why? Thanks

	matthias

----- Forwarded message from Mail Delivery System <Mailer-Daemon at sh4-5.1blu.de> -----

Date: Fri, 09 Feb 2018 11:14:13 +0100
From: Mail Delivery System <Mailer-Daemon at sh4-5.1blu.de>
To: ftp51246-2575596 at sh4-5.1blu.de
Subject: Mail delivery failed: returning message to sender

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  gnupg-users at gnupg.org
    host kerckhoffs.g10code.com [217.69.77.222]
    SMTP error from remote mail server after RCPT TO:<gnupg-users at gnupg.org>:
    451 Could not complete sender verify callout:
    retry timeout exceeded

Reporting-MTA: dns; sh4-5.1blu.de

Action: failed
Final-Recipient: rfc822;gnupg-users at gnupg.org
Status: 5.0.0
Remote-MTA: dns; kerckhoffs.g10code.com
Diagnostic-Code: smtp; 451 Could not complete sender verify callout: retry timeout exceeded

Date: Mon, 5 Feb 2018 11:12:12 +0100
From: Matthias Apitz <guru at unixarea.de>
To: gnupg-users at gnupg.org
Subject: OpenPGP card && exporting secret keys


Hello,

I'm using an OpenPGP card and gnupg 2.1.19 on my FreeBSD workstations
and my Ubuntu mobile device to store crypted passwords (tool: password-store),
to lock/unlock desktop sessions and to sign emails. This is all working
fine and without any hick-ups.

What makes me worry, is that single point of failure: the OpenPGP card.

While I do backups of alls the encrypted password files, they would be
all useless in case of lost/teft of the token or hardware fault of the SIM
card.

What I do at the moment is something like:

$ find ~/.password-store -name '*.gpg' -exec printf "%s:\n" {} \;
  -and -exec gpg2 -d {} 2> /dev/null \; 
  -and -exec echo \; > /tmp/clear-password-store.txt

$ GNUPGHOME=...
$ gpg -ea /tmp/clear-password-store.txt
$ mv /tmp/clear-password-store.txt.asc $GNUPGHOME
$ rm -P /tmp/clear-password-store.txt

where the other GNUPGHOME contains secret and pub-keys created for this
special purpose and living outside (i.e. without) the OpenPGP card.
ANd in case of lost/teft of the token I could recover at least all
passwords again...

Is there any way to export the secret keys from the OpenPGP card to use
them directly (with a passphrase) and without the OpenPGP card?

Thanks

	matthias

----- End forwarded message -----

-- 
Matthias Apitz, ? guru at unixarea.de, ? http://www.unixarea.de/  ? +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

Thanks to the Soviet Army for the Victory in Stalingrad! -- ?????? ? ?????????????? ?????!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180211/157d9093/attachment.sig>

From peter at digitalbrains.com  Sun Feb 11 12:56:40 2018
From: peter at digitalbrains.com (Peter Lebbing)
Date: Sun, 11 Feb 2018 12:56:40 +0100
Subject: problems sending to the list
In-Reply-To: <20180211082958.GA2158@c720-r314251>
References: <20180211082958.GA2158@c720-r314251>
Message-ID: <8dba7364-0e54-459c-9dc8-2286aedd53cc@digitalbrains.com>

On 11/02/18 09:29, Matthias Apitz wrote:
> ----- Forwarded message from Mail Delivery System <Mailer-Daemon at sh4-5.1blu.de> -----
> 
> Date: Fri, 09 Feb 2018 11:14:13 +0100
> From: Mail Delivery System <Mailer-Daemon at sh4-5.1blu.de>
> To: ftp51246-2575596 at sh4-5.1blu.de

I think you're not setting the "envelope from" correctly. While the
e-mail itself has your normal e-mail address, the bounce is going to the
address I quoted above, so apparently that is the envelope sender.

E-mail delivery works with the addresses in the envelope, and actually
the "From:" in the headers of the mail are not related to that. It would
appear that your ISP's server ends up delivering the mail somewhat like
this:

MAIL FROM:<ftp51246-2575596 at sh4-5.1blu.de>
RCPT TO:<gnupg-users at gnupg.org>
DATA
...
From: Matthias Apitz <guru at unixarea.de>
...
.

That envelope sender is causing problems further down the road, leading
to a bounce.

If you tell me off-list what MUA you're using to send the mail I might
be able to help configure it correctly.

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/20180211/9a6639dc/attachment.sig>

From guru at unixarea.de  Sun Feb 11 18:31:02 2018
From: guru at unixarea.de (Matthias Apitz)
Date: Sun, 11 Feb 2018 18:31:02 +0100
Subject: problems sending to the list
In-Reply-To: <8dba7364-0e54-459c-9dc8-2286aedd53cc@digitalbrains.com>
References: <20180211082958.GA2158@c720-r314251>
 <8dba7364-0e54-459c-9dc8-2286aedd53cc@digitalbrains.com>
Message-ID: <20180211173102.GB7112@c720-r314251>

El d?a domingo, febrero 11, 2018 a las 12:56:40p. m. +0100, Peter Lebbing escribi?:

> I think you're not setting the "envelope from" correctly. While the
> e-mail itself has your normal e-mail address, the bounce is going to the
> address I quoted above, so apparently that is the envelope sender.

Yes. This was the issue. The MUA in question is mutt which uses sendmail to send the
mail. There was (I don't know why) the -f ... missing.

	matthias

-- 
Matthias Apitz, ? guru at unixarea.de, ? http://www.unixarea.de/  ? +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

Thanks to the Soviet Army for the Victory in Stalingrad! -- ?????? ? ?????????????? ?????!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180211/61637ff8/attachment.sig>

From wk at gnupg.org  Tue Feb 13 14:02:37 2018
From: wk at gnupg.org (Werner Koch)
Date: Tue, 13 Feb 2018 14:02:37 +0100
Subject: draft-ietf-openpgp-rfc4880bis-04
In-Reply-To: <006Xx6eGf6U3Y0jk4v2FzYmvZJ94Ax4rnLxBBztvxP8WP3tL7IaYfwNvJCG85nHYkNAhqgsMSgWaIPuQThSqoq9ZIaX9iI4US75aRoL43pQ=@protonmail.com>
 (FuzzyDrawrings via Gnupg-users's message of "Thu, 08 Feb 2018
 21:18:56 -0500")
References: <5sqhZYgAJfgRAcXAZkAfqU-D7bKvhlrgn50v3Y0xJMcHSAIK35ZL0GkURbMR8K2WwgbqtSD16CZRXMdxYttObWALX_omY4qzztA_23SGd9U=@protonmail.com>
 <871shyxpgd.fsf@wheatstone.g10code.de>
 <006Xx6eGf6U3Y0jk4v2FzYmvZJ94Ax4rnLxBBztvxP8WP3tL7IaYfwNvJCG85nHYkNAhqgsMSgWaIPuQThSqoq9ZIaX9iI4US75aRoL43pQ=@protonmail.com>
Message-ID: <87eflpxcsy.fsf@wheatstone.g10code.de>

On Fri,  9 Feb 2018 03:18, gnupg-users at gnupg.org said:

> ...and that's the end of hashed subpackets. That should be all that is hashed for the signature, yet there is the remaining octets in m:
>
>  04ff0000000c

See 5.2.4, Computing Signatures:

| V4 signatures also hash in a final trailer of six octets: the version
| of the Signature packet, i.e., 0x04; 0xFF; and a four-octet,
| big-endian number that is the length of the hashed data from the
| Signature packet (note that this number does not include these final
| six octets).
| 
| V5 signatures instead hash in a ten-octet trailer: the version of the
| Signature packet, i.e., 0x05; 0xFF; and an eight-octet, big-endian
| number that is the length of the hashed data from the Signature packet
| (note that this number does not include these final ten octets).



Salam-Shalom,

   Werner

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

From wk at gnupg.org  Tue Feb 13 14:12:04 2018
From: wk at gnupg.org (Werner Koch)
Date: Tue, 13 Feb 2018 14:12:04 +0100
Subject: Use the same passphrase for PGP and SSH keys and get prompted
 only once by gpg-agent
In-Reply-To: <874lmqs3bn.fsf@gmail.com> (Pierre Neidhardt's message of "Fri,
 09 Feb 2018 14:25:00 +0100")
References: <874lmqs3bn.fsf@gmail.com>
Message-ID: <87a7wdxcd7.fsf@wheatstone.g10code.de>

On Fri,  9 Feb 2018 14:25, ambrevar at gmail.com said:

> this time the SSH key is obviously encrypted with the same passphrase as
> my GPG key, since it's part of it.  Any clue why gpg-agent keeps asking?

gpg (or correct gpg-agent) can't know which passphrase is used for each
key or subkey.  Passphrases are cached on a per subkey base and thus you
will see a passphrase query for each new subkey.

You may now wonder why this does not happen when you decrypt a mail,
reply to it and sign the reply.  Two subkeys (or the primary and the
encryption subkey) are involved in this workflow.  Because this is so
common, gpg-agent knows about it and tries the last passphrase used for
any of the the subkeys of a key.  It does not do this for an
authentication subkey, though.  Thus you have to enter it again for ssh.

Note that we can't do trial decryption using several remembered
passphrases because that would take noticeably long for the user.  For
security reasons each passphrase decryption takes about 100ms.


Shalom-Salam,

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

From ambrevar at gmail.com  Tue Feb 13 15:03:11 2018
From: ambrevar at gmail.com (Pierre Neidhardt)
Date: Tue, 13 Feb 2018 15:03:11 +0100
Subject: Use the same passphrase for PGP and SSH keys and get prompted
 only once by gpg-agent
In-Reply-To: <87a7wdxcd7.fsf@wheatstone.g10code.de>
References: <874lmqs3bn.fsf@gmail.com> <87a7wdxcd7.fsf@wheatstone.g10code.de>
Message-ID: <87o9ktm1gg.fsf@gmail.com>


Werner Koch <wk at gnupg.org> writes:

> You may now wonder why this does not happen when you decrypt a mail,
> reply to it and sign the reply.  Two subkeys (or the primary and the
> encryption subkey) are involved in this workflow.  Because this is so
> common, gpg-agent knows about it and tries the last passphrase used for
> any of the the subkeys of a key.  It does not do this for an
> authentication subkey, though.  Thus you have to enter it again for ssh.

Thanks for the detailed answer.  But why not doing it for SSH then?
Just because it's less common?  Would there be any way to configure this?

-- 
Pierre Neidhardt

War spares not the brave, but the cowardly.
		-- Anacreon
-------------- 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/20180213/de457d3f/attachment.sig>

From wk at gnupg.org  Tue Feb 13 16:55:19 2018
From: wk at gnupg.org (Werner Koch)
Date: Tue, 13 Feb 2018 16:55:19 +0100
Subject: Use the same passphrase for PGP and SSH keys and get prompted
 only once by gpg-agent
In-Reply-To: <87o9ktm1gg.fsf@gmail.com> (Pierre Neidhardt's message of "Tue,
 13 Feb 2018 15:03:11 +0100")
References: <874lmqs3bn.fsf@gmail.com> <87a7wdxcd7.fsf@wheatstone.g10code.de>
 <87o9ktm1gg.fsf@gmail.com>
Message-ID: <87r2pox4t4.fsf@wheatstone.g10code.de>

On Tue, 13 Feb 2018 15:03, ambrevar at gmail.com said:

> Thanks for the detailed answer.  But why not doing it for SSH then?

I like to see when an ssh key is used the first time.  Note that the
maximum caching time for ssh keys can be configured independent from the
caching time of other keys.

> Just because it's less common?  Would there be any way to configure this?

No, there is no way to configure an extra hack to also test a passphrase
for an ssh key.


Salam-Shalom,

   Werner

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

From sandunwd at gmail.com  Tue Feb 13 17:07:30 2018
From: sandunwd at gmail.com (Sandun Weerawardane)
Date: Tue, 13 Feb 2018 21:37:30 +0530
Subject: Using GPGAgent as SSHAgent on Windows with cygwin/mingw
Message-ID: <CAKW5_B9qsmOCzwbexQ9xRfe5z2-q-QmE7xb=4w9qXoOE7Ne2HA@mail.gmail.com>

Hi, Did you able to connect SSH using gpg-agent?
I'm having the same issue here:
https://superuser.com/questions/1293725/gpg-agent-under-windows-as-ssh-agent-for-git-bash
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180213/0c2f5f18/attachment.html>

From gpg at mdsresource.net  Wed Feb 14 21:20:10 2018
From: gpg at mdsresource.net (helices)
Date: Wed, 14 Feb 2018 14:20:10 -0600
Subject: How can we utilize latest GPG from RPM repository?
Message-ID: <CACNUArDNPfA3f+T+ztp-s2e4A6ewb+vovjHZYXESkf0cz1-OPQ@mail.gmail.com>

CentOS 7 uses gnupg2 v2.0.22. EPEL doesn't have anything newer.

We want to move to v2.2.x, and stay current, but we don't want to download
source and compile for dozens of systems.

We want all users to be using the same version all of the time.

Please, advise. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180214/717db8ee/attachment.html>

From dkg at fifthhorseman.net  Wed Feb 14 23:30:41 2018
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 14 Feb 2018 17:30:41 -0500
Subject: How can we utilize latest GPG from RPM repository?
In-Reply-To: <CACNUArDNPfA3f+T+ztp-s2e4A6ewb+vovjHZYXESkf0cz1-OPQ@mail.gmail.com>
References: <CACNUArDNPfA3f+T+ztp-s2e4A6ewb+vovjHZYXESkf0cz1-OPQ@mail.gmail.com>
Message-ID: <87fu63p5ke.fsf@fifthhorseman.net>

On Wed 2018-02-14 14:20:10 -0600, helices wrote:
> CentOS 7 uses gnupg2 v2.0.22. EPEL doesn't have anything newer.
>
> We want to move to v2.2.x, and stay current, but we don't want to download
> source and compile for dozens of systems.
>
> We want all users to be using the same version all of the time.

This sounds like a problem for your operating system and/or package
manager.  GnuPG has a chain of build dependencies which often makes it
difficult to just import directly from a single RPM.

If you were running a more recent operating system, you'd likely get
something from the GnuPG "modern" branch as well anyway.

Perhaps you want to ask your operating system vendor what their
recommendation is for "backports" of specific packages?

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

From wangtianjiao.wang959 at gmail.com  Thu Feb 15 03:36:28 2018
From: wangtianjiao.wang959 at gmail.com (Genghuang Wang)
Date: Thu, 15 Feb 2018 10:36:28 +0800
Subject: Huawei manual about Gnupg
Message-ID: <CAL57ndEGawmQOixXk9KeenTZ==04pQWxrfvsNH-+eDR8zQ5qQg@mail.gmail.com>

Hello, everybody as the Gnupg user

I download the Huawei manual about Gnupg from
http://support.huawei.com/enterprise/en/tool/software-digital-signature-validation-tool-(pgp-verify)-TL1000000054/TV1000000016

The English version is the OpenPGP_Signature_Verification_Guide.pdf

Could you please take a look at it and make some suggestions to
Huawei to improve it. Thank you!

http://www.huawei.com/en/contact-us

Disclaimer: I am not a member of Huawei, I am just as a public viewer as you.


From dirk.gottschalk1980 at googlemail.com  Thu Feb 15 14:16:12 2018
From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk)
Date: Thu, 15 Feb 2018 14:16:12 +0100
Subject: How can we utilize latest GPG from RPM repository?
In-Reply-To: <CACNUArDNPfA3f+T+ztp-s2e4A6ewb+vovjHZYXESkf0cz1-OPQ@mail.gmail.com>
References: <CACNUArDNPfA3f+T+ztp-s2e4A6ewb+vovjHZYXESkf0cz1-OPQ@mail.gmail.com>
Message-ID: <1518700572.4116.3.camel@googlemail.com>

Hi.
Am Mittwoch, den 14.02.2018, 14:20 -0600 schrieb helices:
> CentOS 7 uses gnupg2 v2.0.22. EPEL doesn't have anything newer.

> We want to move to v2.2.x, and stay current, but we don't want to
> download
> source and compile for dozens of systems.

> We want all users to be using the same version all of the time.

> Please, advise. Thank you.

You could try to use the packages from Fedora. Actually they distribute
Version 2.2.4 for Fedora 27. In doubt it should be possible to rebuild
the source packages for CentOS.

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/20180215/8a2e08b2/attachment.sig>

From gpg at mdsresource.net  Thu Feb 15 15:10:07 2018
From: gpg at mdsresource.net (helices)
Date: Thu, 15 Feb 2018 08:10:07 -0600
Subject: How can we utilize latest GPG from RPM repository?
In-Reply-To: <BN6PR07MB307307D3CC65F598C974D1C3C1F40@BN6PR07MB3073.namprd07.prod.outlook.com>
References: <CACNUArDNPfA3f+T+ztp-s2e4A6ewb+vovjHZYXESkf0cz1-OPQ@mail.gmail.com>
 <87fu63p5ke.fsf@fifthhorseman.net>
 <BN6PR07MB307307D3CC65F598C974D1C3C1F40@BN6PR07MB3073.namprd07.prod.outlook.com>
Message-ID: <CACNUArCA7HEviQkGNXa5KyO0oCsP9tG1p5g-BiqBKf5F0qL+6Q@mail.gmail.com>

Yes, I know that.

In general, that scheme works well.

However, in another case, rsyslog, a certain function has been broken for
many years, and the only fix is to track the developers' most recent
versions. In that case, the developers maintain their own repository:
http://rpms.adiscon.com ; which is easy to incorporate into:
/etc/yum.repos.d/rsyslog.repo

We are hoping something similar is available for gnupg. I have not found
that; which is the reason for my posts here.

What am I missing?

Please, advise. Thank you.



On Thu, Feb 15, 2018 at 7:56 AM, Lightner, Jeffrey <JLightner at dsservices.com
> wrote:

> CentOS isn't a vendor.   It is a project that does binary compiles of RHEL
> sources.
>
> RedHat is the vendor that creates RHEL and its source is used to make
> CentOS.   RHEL is supported by RedHat if you have a subscription.  CentOS
> has no direct support though RedHat hosts the project nowadays.
>
> RHEL (and therefore CentOS) major versions such as 7 start with base
> upstream versions of packages.   RedHat modifies that base upstream package
> to backport bug and security fixes from later upstream packages if relevant
> to the original base.   They then add extended versioning to the RPM name.
>
> For example on a test system I just looked at  "yum list gnupg2" shows:
> Installed Packages
> gnupg2.x86_64                  2.0.22-3.el7                   @anaconda/7.0
> Available Packages
> gnupg2.x86_64                  2.0.22-4.el7
>  rhel-7-server-rpms
>
> Notice the base upstream for both the installed and the available is
> 2.0.22 but the extended versioning is different (3.el7 vs 4.el7).   You'd
> have to examine the errata to see what is different about the latter.
>
> In general unless there is a specific feature in upstream you need that is
> not in the RHEL/CentOS provided version you should use the RHEL/CentOS
> version on your RHEL/CentOS system.
>
> If you really want the latest of everything you should use Fedora instead
> of CentOS.   Just be aware that Fedora is bleeding edge and releases a new
> version twice a year.   Generally that means you HAVE to do a full upgrade
> at least once a year as they won't offer updated packages for more than two
> major versions at a time.   For a Production environment that pace of
> upgrade is usually not desirable which is why people use RHEL/CentOS
> instead.
>
> -----Original Message-----
> From: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] On Behalf Of
> Daniel Kahn Gillmor
> Sent: Wednesday, February 14, 2018 5:31 PM
> To: helices; gnupg-users at gnupg.org
> Subject: Re: How can we utilize latest GPG from RPM repository?
>
> On Wed 2018-02-14 14:20:10 -0600, helices wrote:
> > CentOS 7 uses gnupg2 v2.0.22. EPEL doesn't have anything newer.
> >
> > We want to move to v2.2.x, and stay current, but we don't want to
> > download source and compile for dozens of systems.
> >
> > We want all users to be using the same version all of the time.
>
> This sounds like a problem for your operating system and/or package
> manager.  GnuPG has a chain of build dependencies which often makes it
> difficult to just import directly from a single RPM.
>
> If you were running a more recent operating system, you'd likely get
> something from the GnuPG "modern" branch as well anyway.
>
> Perhaps you want to ask your operating system vendor what their
> recommendation is for "backports" of specific packages?
>
>           --dkg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180215/54e718cb/attachment-0001.html>

From JLightner at dsservices.com  Thu Feb 15 16:06:00 2018
From: JLightner at dsservices.com (Lightner, Jeffrey)
Date: Thu, 15 Feb 2018 15:06:00 +0000
Subject: How can we utilize latest GPG from RPM repository?
In-Reply-To: <CACNUArCA7HEviQkGNXa5KyO0oCsP9tG1p5g-BiqBKf5F0qL+6Q@mail.gmail.com>
References: <CACNUArDNPfA3f+T+ztp-s2e4A6ewb+vovjHZYXESkf0cz1-OPQ@mail.gmail.com>
 <87fu63p5ke.fsf@fifthhorseman.net>
 <BN6PR07MB307307D3CC65F598C974D1C3C1F40@BN6PR07MB3073.namprd07.prod.outlook.com>
 <CACNUArCA7HEviQkGNXa5KyO0oCsP9tG1p5g-BiqBKf5F0qL+6Q@mail.gmail.com>
Message-ID: <BN6PR07MB3073E0F019E1932D87BE70A0C1F40@BN6PR07MB3073.namprd07.prod.outlook.com>

What you?re missing is WHY you want a later upstream version.   Is there a specific feature you?re needing that isn?t in the one that comes with your distro?

You can?t have it both ways:  You want to stay on a stable distro/version which is the raison d?etre for RHEL/CentOS but want to have the latest package.    As I noted in my prior post you can get the latest of everything by abandoning CentOS in favor of Fedora at the expense of stability.    Your choice of distro is based on many factors.   Some people even build their own packages all from scratch because they don?t like any of the distros.

Not all packages have people that build rpm?s for them.   Many FOSS projects seem to prefer building for Debian or something else and MAY package it for whatever distro they like but some don?t package it for anything and expect you to do the legwork yourself.

In general if it isn?t in RHEL/CentOS I look for it in the EPEL.  If it isn?t there I almost always download the source then configure/compile it.   This isn?t really a difficult process for most packages.

There ARE other locations that MAY provide a package you want.   Have you looked at rpmfind?  rpmbone?

And of course YOU could create the rpm and share it on EPEL yourself so others will have it.


From: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] On Behalf Of helices
Sent: Thursday, February 15, 2018 9:10 AM
To: gnupg-users at gnupg.org
Subject: Re: How can we utilize latest GPG from RPM repository?

Yes, I know that.
In general, that scheme works well.
However, in another case, rsyslog, a certain function has been broken for many years, and the only fix is to track the developers' most recent versions. In that case, the developers maintain their own repository: http://rpms.adiscon.com ; which is easy to incorporate into: /etc/yum.repos.d/rsyslog.repo
We are hoping something similar is available for gnupg. I have not found that; which is the reason for my posts here.
What am I missing?
Please, advise. Thank you.


On Thu, Feb 15, 2018 at 7:56 AM, Lightner, Jeffrey <JLightner at dsservices.com<mailto:JLightner at dsservices.com>> wrote:
CentOS isn't a vendor.   It is a project that does binary compiles of RHEL sources.

RedHat is the vendor that creates RHEL and its source is used to make CentOS.   RHEL is supported by RedHat if you have a subscription.  CentOS has no direct support though RedHat hosts the project nowadays.

RHEL (and therefore CentOS) major versions such as 7 start with base upstream versions of packages.   RedHat modifies that base upstream package to backport bug and security fixes from later upstream packages if relevant to the original base.   They then add extended versioning to the RPM name.

For example on a test system I just looked at  "yum list gnupg2" shows:
Installed Packages
gnupg2.x86_64                  2.0.22-3.el7                   @anaconda/7.0
Available Packages
gnupg2.x86_64                  2.0.22-4.el7                   rhel-7-server-rpms

Notice the base upstream for both the installed and the available is 2.0.22 but the extended versioning is different (3.el7 vs 4.el7).   You'd have to examine the errata to see what is different about the latter.

In general unless there is a specific feature in upstream you need that is not in the RHEL/CentOS provided version you should use the RHEL/CentOS version on your RHEL/CentOS system.

If you really want the latest of everything you should use Fedora instead of CentOS.   Just be aware that Fedora is bleeding edge and releases a new version twice a year.   Generally that means you HAVE to do a full upgrade at least once a year as they won't offer updated packages for more than two major versions at a time.   For a Production environment that pace of upgrade is usually not desirable which is why people use RHEL/CentOS instead.

-----Original Message-----
From: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org<mailto:gnupg-users-bounces at gnupg.org>] On Behalf Of Daniel Kahn Gillmor
Sent: Wednesday, February 14, 2018 5:31 PM
To: helices; gnupg-users at gnupg.org<mailto:gnupg-users at gnupg.org>
Subject: Re: How can we utilize latest GPG from RPM repository?

On Wed 2018-02-14 14:20:10 -0600, helices wrote:
> CentOS 7 uses gnupg2 v2.0.22. EPEL doesn't have anything newer.
>
> We want to move to v2.2.x, and stay current, but we don't want to
> download source and compile for dozens of systems.
>
> We want all users to be using the same version all of the time.

This sounds like a problem for your operating system and/or package manager.  GnuPG has a chain of build dependencies which often makes it difficult to just import directly from a single RPM.

If you were running a more recent operating system, you'd likely get something from the GnuPG "modern" branch as well anyway.

Perhaps you want to ask your operating system vendor what their recommendation is for "backports" of specific packages?

          --dkg

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

From gpg at mdsresource.net  Thu Feb 15 16:32:16 2018
From: gpg at mdsresource.net (helices)
Date: Thu, 15 Feb 2018 09:32:16 -0600
Subject: How can we utilize latest GPG from RPM repository?
In-Reply-To: <BN6PR07MB3073E0F019E1932D87BE70A0C1F40@BN6PR07MB3073.namprd07.prod.outlook.com>
References: <CACNUArDNPfA3f+T+ztp-s2e4A6ewb+vovjHZYXESkf0cz1-OPQ@mail.gmail.com>
 <87fu63p5ke.fsf@fifthhorseman.net>
 <BN6PR07MB307307D3CC65F598C974D1C3C1F40@BN6PR07MB3073.namprd07.prod.outlook.com>
 <CACNUArCA7HEviQkGNXa5KyO0oCsP9tG1p5g-BiqBKf5F0qL+6Q@mail.gmail.com>
 <BN6PR07MB3073E0F019E1932D87BE70A0C1F40@BN6PR07MB3073.namprd07.prod.outlook.com>
Message-ID: <CACNUArDbZt_CiZ1ijwn20r4GmwO-mZxn7y_B4roBd99ZWcS_VQ@mail.gmail.com>

Jeffrey, please, your ad hominem accusations are not helpful.

You said, "What you?re missing is WHY you want a later upstream version."

How do you know that I'm missing that? That "why" is not at all relevant to
my question.

You said, "You can?t have it both ways:  You want to stay on a stable
distro/version which is the raison d?etre for RHEL/CentOS but want to have
the latest package."

As you know, CentOS contains thousands of files, and I have given one
example of a need to deviate from the default distribution for rsyslog.
Suffice it to say, we want to do the same with gnupg.

If there is no gnupg solution similar to our rsyslog solution, then we will
do something else.

Simply because I have not found a gnupg solution similar to our rsyslog
solution, does NOT mean that such a solution does not exist.

Hence, my original post here yesterday.

Actually answering my subject question would be helpful. You have not done
that.

Thank you.


On Thu, Feb 15, 2018 at 9:06 AM, Lightner, Jeffrey <JLightner at dsservices.com
> wrote:

> What you?re missing is WHY you want a later upstream version.   Is there a
> specific feature you?re needing that isn?t in the one that comes with your
> distro?
>
>
>
> You can?t have it both ways:  You want to stay on a stable distro/version
> which is the raison d?etre for RHEL/CentOS but want to have the latest
> package.    As I noted in my prior post you can get the latest of
> everything by abandoning CentOS in favor of Fedora at the expense of
> stability.    Your choice of distro is based on many factors.   Some people
> even build their own packages all from scratch because they don?t like any
> of the distros.
>
>
>
> Not all packages have people that build rpm?s for them.   Many FOSS
> projects seem to prefer building for Debian or something else and MAY
> package it for whatever distro they like but some don?t package it for
> anything and expect you to do the legwork yourself.
>
>
>
> In general if it isn?t in RHEL/CentOS I look for it in the EPEL.  If it
> isn?t there I almost always download the source then configure/compile
> it.   This isn?t really a difficult process for most packages.
>
>
>
> There ARE other locations that MAY provide a package you want.   Have you
> looked at rpmfind?  rpmbone?
>
>
>
> And of course YOU could create the rpm and share it on EPEL yourself so
> others will have it.
>
>
>
>
>
> *From:* Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] *On Behalf Of *
> helices
> *Sent:* Thursday, February 15, 2018 9:10 AM
> *To:* gnupg-users at gnupg.org
>
> *Subject:* Re: How can we utilize latest GPG from RPM repository?
>
>
>
> Yes, I know that.
>
> In general, that scheme works well.
>
> However, in another case, rsyslog, a certain function has been broken for
> many years, and the only fix is to track the developers' most recent
> versions. In that case, the developers maintain their own repository:
> http://rpms.adiscon.com ; which is easy to incorporate into:
> /etc/yum.repos.d/rsyslog.repo
>
> We are hoping something similar is available for gnupg. I have not found
> that; which is the reason for my posts here.
>
> What am I missing?
>
> Please, advise. Thank you.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180215/ec45d4b1/attachment-0001.html>

From edgar at pettijohn-web.com  Thu Feb 15 16:47:21 2018
From: edgar at pettijohn-web.com (edgar at pettijohn-web.com)
Date: Thu, 15 Feb 2018 09:47:21 -0600
Subject: How can we utilize latest GPG from RPM repository?
Message-ID: <mailman.6.1518709655.30378.gnupg-users@gnupg.org>


On Feb 15, 2018 9:06 AM, "Lightner, Jeffrey" <JLightner at dsservices.com> wrote:
>
> What you?re missing is WHY you want a later upstream version.?? Is there a specific feature you?re needing that isn?t in the one that comes with your distro?
>
> ?
>
> You can?t have it both ways:? You want to stay on a stable distro/version which is the raison d?etre for RHEL/CentOS but want to have the latest package.??? As I noted in my prior post you can get the latest of everything by abandoning CentOS in favor of Fedora at the expense of stability. ???Your choice of distro is based on many factors.?? Some people even build their own packages all from scratch because they don?t like any of the distros.??
>

Just to add a little extra. Say you have 12 machines. Use one as your build box and just build and install to a fake root tar it up and untar it on the rest of the machines. Make a few simple scripts to keep track of what files are associated with each "package" so you can easily delete them later. Most distros packaging systems are too difficult in my humble opinion. Plus you will get the software you want built to your needs.

> ?
>
> Not all packages have people that build rpm?s for them.?? Many FOSS projects seem to prefer building for Debian or something else and MAY package it for whatever distro they like but some don?t package it for anything and expect you to do the legwork yourself.
>
> ?
>
> In general if it isn?t in RHEL/CentOS I look for it in the EPEL.? If it isn?t there I almost always download the source then configure/compile it.?? This isn?t really a difficult process for most packages.??
>
> ?
>
> There ARE other locations that MAY provide a package you want.?? Have you looked at rpmfind?? rpmbone?
>
> ?
>
> And of course YOU could create the rpm and share it on EPEL yourself so others will have it.
>
> ?
>
> ?
>
> From: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] On Behalf Of helices
> Sent: Thursday, February 15, 2018 9:10 AM
> To: gnupg-users at gnupg.org
> Subject: Re: How can we utilize latest GPG from RPM repository?
>
> ?
>
> Yes, I know that.
>
> In general, that scheme works well.
>
> However, in another case, rsyslog, a certain function has been broken for many years, and the only fix is to track the developers' most recent versions. In that case, the developers maintain their own repository: http://rpms.adiscon.com ; which is easy to incorporate into: /etc/yum.repos.d/rsyslog.repo
>
> We are hoping something similar is available for gnupg. I have not found that; which is the reason for my posts here.
>
> What am I missing?
>
> Please, advise. Thank you.
>
> ?
>
> ?
>
> On Thu, Feb 15, 2018 at 7:56 AM, Lightner, Jeffrey <JLightner at dsservices.com> wrote:
>
> CentOS isn't a vendor.? ?It is a project that does binary compiles of RHEL sources.
>
> RedHat is the vendor that creates RHEL and its source is used to make CentOS.? ?RHEL is supported by RedHat if you have a subscription.? CentOS has no direct support though RedHat hosts the project nowadays.
>
> RHEL (and therefore CentOS) major versions such as 7 start with base upstream versions of packages.? ?RedHat modifies that base upstream package to backport bug and security fixes from later upstream packages if relevant to the original base.? ?They then add extended versioning to the RPM name.
>
> For example on a test system I just looked at? "yum list gnupg2" shows:
> Installed Packages
> gnupg2.x86_64? ? ? ? ? ? ? ? ? 2.0.22-3.el7? ? ? ? ? ? ? ? ? ?@anaconda/7.0
> Available Packages
> gnupg2.x86_64? ? ? ? ? ? ? ? ? 2.0.22-4.el7? ? ? ? ? ? ? ? ? ?rhel-7-server-rpms
>
> Notice the base upstream for both the installed and the available is 2.0.22 but the extended versioning is different (3.el7 vs 4.el7).? ?You'd have to examine the errata to see what is different about the latter.
>
> In general unless there is a specific feature in upstream you need that is not in the RHEL/CentOS provided version you should use the RHEL/CentOS version on your RHEL/CentOS system.
>
> If you really want the latest of everything you should use Fedora instead of CentOS.? ?Just be aware that Fedora is bleeding edge and releases a new version twice a year.? ?Generally that means you HAVE to do a full upgrade at least once a year as they won't offer updated packages for more than two major versions at a time.? ?For a Production environment that pace of upgrade is usually not desirable which is why people use RHEL/CentOS instead.
>
>
> -----Original Message-----
> From: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] On Behalf Of Daniel Kahn Gillmor
> Sent: Wednesday, February 14, 2018 5:31 PM
> To: helices; gnupg-users at gnupg.org
> Subject: Re: How can we utilize latest GPG from RPM repository?
>
> On Wed 2018-02-14 14:20:10 -0600, helices wrote:
> > CentOS 7 uses gnupg2 v2.0.22. EPEL doesn't have anything newer.
> >
> > We want to move to v2.2.x, and stay current, but we don't want to
> > download source and compile for dozens of systems.
> >
> > We want all users to be using the same version all of the time.
>
> This sounds like a problem for your operating system and/or package manager.? GnuPG has a chain of build dependencies which often makes it difficult to just import directly from a single RPM.
>
> If you were running a more recent operating system, you'd likely get something from the GnuPG "modern" branch as well anyway.
>
> Perhaps you want to ask your operating system vendor what their recommendation is for "backports" of specific packages?
>
> ? ? ? ? ? --dkg
>
> ?

From rjh at sixdemonbag.org  Thu Feb 15 16:56:53 2018
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Thu, 15 Feb 2018 10:56:53 -0500
Subject: Huawei manual about Gnupg
In-Reply-To: <CAL57ndEGawmQOixXk9KeenTZ==04pQWxrfvsNH-+eDR8zQ5qQg@mail.gmail.com>
References: <CAL57ndEGawmQOixXk9KeenTZ==04pQWxrfvsNH-+eDR8zQ5qQg@mail.gmail.com>
Message-ID: <95f546c5-ef65-acd1-9f74-90e73a945411@sixdemonbag.org>

> Could you please take a look at it and make some suggestions to
> Huawei to improve it. Thank you!

The documentation we create is free for the world to use for any
purpose.  If Huawei wants to use it, they can, so long as they respect
the license.  But so long as Huawei is selling proprietary stuff, why
should we volunteer our time and labor to help them sell more
proprietary stuff?


From JLightner at dsservices.com  Thu Feb 15 14:56:18 2018
From: JLightner at dsservices.com (Lightner, Jeffrey)
Date: Thu, 15 Feb 2018 13:56:18 +0000
Subject: How can we utilize latest GPG from RPM repository?
In-Reply-To: <87fu63p5ke.fsf@fifthhorseman.net>
References: <CACNUArDNPfA3f+T+ztp-s2e4A6ewb+vovjHZYXESkf0cz1-OPQ@mail.gmail.com>
 <87fu63p5ke.fsf@fifthhorseman.net>
Message-ID: <BN6PR07MB307307D3CC65F598C974D1C3C1F40@BN6PR07MB3073.namprd07.prod.outlook.com>

CentOS isn't a vendor.   It is a project that does binary compiles of RHEL sources.

RedHat is the vendor that creates RHEL and its source is used to make CentOS.   RHEL is supported by RedHat if you have a subscription.  CentOS has no direct support though RedHat hosts the project nowadays.

RHEL (and therefore CentOS) major versions such as 7 start with base upstream versions of packages.   RedHat modifies that base upstream package to backport bug and security fixes from later upstream packages if relevant to the original base.   They then add extended versioning to the RPM name.   

For example on a test system I just looked at  "yum list gnupg2" shows:
Installed Packages
gnupg2.x86_64                  2.0.22-3.el7                   @anaconda/7.0
Available Packages
gnupg2.x86_64                  2.0.22-4.el7                   rhel-7-server-rpms

Notice the base upstream for both the installed and the available is 2.0.22 but the extended versioning is different (3.el7 vs 4.el7).   You'd have to examine the errata to see what is different about the latter.

In general unless there is a specific feature in upstream you need that is not in the RHEL/CentOS provided version you should use the RHEL/CentOS version on your RHEL/CentOS system.   

If you really want the latest of everything you should use Fedora instead of CentOS.   Just be aware that Fedora is bleeding edge and releases a new version twice a year.   Generally that means you HAVE to do a full upgrade at least once a year as they won't offer updated packages for more than two major versions at a time.   For a Production environment that pace of upgrade is usually not desirable which is why people use RHEL/CentOS instead.

-----Original Message-----
From: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] On Behalf Of Daniel Kahn Gillmor
Sent: Wednesday, February 14, 2018 5:31 PM
To: helices; gnupg-users at gnupg.org
Subject: Re: How can we utilize latest GPG from RPM repository?

On Wed 2018-02-14 14:20:10 -0600, helices wrote:
> CentOS 7 uses gnupg2 v2.0.22. EPEL doesn't have anything newer.
>
> We want to move to v2.2.x, and stay current, but we don't want to 
> download source and compile for dozens of systems.
>
> We want all users to be using the same version all of the time.

This sounds like a problem for your operating system and/or package manager.  GnuPG has a chain of build dependencies which often makes it difficult to just import directly from a single RPM.

If you were running a more recent operating system, you'd likely get something from the GnuPG "modern" branch as well anyway.

Perhaps you want to ask your operating system vendor what their recommendation is for "backports" of specific packages?

          --dkg


From jc.gnupg18a at unser.net  Thu Feb 15 21:33:05 2018
From: jc.gnupg18a at unser.net (Juergen Christoffel)
Date: Thu, 15 Feb 2018 21:33:05 +0100
Subject: Configuration for offline usage - best practice tips?
Message-ID: <20180215203305.GA21779@unser.net>

Hi folks,

I'm looking for best practice tips for offline usage of GnuPG. What Do I
mean by offline usage? I plan to encrypt backups or files on my machines
with GnuPG and generate weekly or monthly keys for that purpose so backups
for example can run unattended and simply encrypt with today's public key.
As the backups need to be compatible with my software only, I could
possibly choose different configuration options than for my "online" usage.

While I can find a number of configuration hints for compatibility between
implementations and standards or strong encryption in general, I expect
that a configuration for offline usage might be different from one for
general purpose encrypted communication.

Regards, JC

-- 
  Doctorow's Law: Anytime someone puts a lock on something you own, against
  your wishes, and doesn't give you the key, they're not doing it for your
  benefit.


From konstantin at linuxfoundation.org  Thu Feb 15 23:20:14 2018
From: konstantin at linuxfoundation.org (Konstantin Ryabitsev)
Date: Thu, 15 Feb 2018 17:20:14 -0500
Subject: Expected behaviour setting TOFU policy
Message-ID: <20180215222014.GA1115@work>

Hi, all:

I am not sure if what I am experiencing is expected TOFU behaviour or 
not, and I'm hoping someone can help me figure that out. I'll show on a 
live example (skipping irrelevant output).
This is gnupg-2.2.4 on Fedora 26.

  [user at disp1132 ~]$ export GNUPGHOME=$(mktemp -d)
  [user at disp1132 ~]$ gpg2 --locate-keys gregkh at kernel.org
  [user at disp1132 ~]$ curl -O https://www.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.15.3
  [user at disp1132 ~]$ curl -O https://www.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.15.3.sign
  [user at disp1132 ~]$ gpg2 --verify ChangeLog-4.15.3.sign
  gpg: assuming signed data in 'ChangeLog-4.15.3'
  gpg: Signature made Mon Feb 12 01:07:40 2018 EST
  gpg:                using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
  gpg: Good signature from "Greg Kroah-Hartman <gregkh at kernel.org>" [unknown]
  gpg: WARNING: This key is not certified with a trusted signature!
  gpg:          There is no indication that the signature belongs to the owner.
  Primary key fingerprint: 647F 2865 4894 E3BD 4571  99BE 38DB BDC8 6092 693E

Since there is no exiting TOFU db, that's expected output, right? The trust
model guesser decides we're using the PGP model. So, let's create tofu.db by
setting tofu-policy to good on Greg's key:

  [user at disp1132 ~]$ gpg2 --tofu-policy good 647F28654894E3BD457199BE38DBBDC86092693E
  gpg: Setting TOFU trust policy for new binding <key: 647F28654894E3BD457199BE38DBBDC86092693E, user id: Greg Kroah-Hartman <gregkh at kernel.org>> to good.
  [user at disp1132 ~]$ gpg2 --check-trustdb
  gpg: no ultimately trusted keys found

Here is where I get unexpected result rerunning the --verify command, 
which I expected to return a different result:

  [user at disp1132 ~]$ gpg2 --verify ChangeLog-4.15.3.sign 
  gpg: assuming signed data in 'ChangeLog-4.15.3'
  gpg: Signature made Mon Feb 12 01:07:40 2018 EST
  gpg:                using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
  gpg: Good signature from "Greg Kroah-Hartman <gregkh at kernel.org>" [unknown]
  gpg: WARNING: This key is not certified with a trusted signature!
  gpg:          There is no indication that the signature belongs to the owner.
  Primary key fingerprint: 647F 2865 4894 E3BD 4571  99BE 38DB BDC8 6092 693E

Same as before. Since I have tofu.db now, the trust-model should have
switched to tofu+pgp, no?

  [user at disp1132 ~]$ ls $GNUPGHOME
  crls.d  private-keys-v1.d  pubring.kbx  pubring.kbx~  tofu.db  trustdb.gpg

At least, if I set trust-model on the command line, I get the TOFU output I
expect:

  [user at disp1132 ~]$ gpg2 --trust-model tofu+pgp --verify ChangeLog-4.15.3.sign 
  gpg: assuming signed data in 'ChangeLog-4.15.3'
  gpg: Signature made Mon Feb 12 01:07:40 2018 EST
  gpg:                using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
  gpg: checking the trustdb
  gpg: no ultimately trusted keys found
  gpg: Good signature from "Greg Kroah-Hartman <gregkh at kernel.org>" [full]
  gpg: gregkh at kernel.org: Verified 1 signature in the past 0 seconds.  Encrypted
	   0 messages.

But wait, now I can omit --trust-model from the command line and I get the same
TOFU-based result, implying that trust-model tofu+pgp now sticks, even though
I've modified no config files:

  [user at disp1132 ~]$ gpg2 --verify ChangeLog-4.15.3.sign 
  gpg: assuming signed data in 'ChangeLog-4.15.3'
  gpg: Signature made Mon Feb 12 01:07:40 2018 EST
  gpg:                using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
  gpg: Good signature from "Greg Kroah-Hartman <gregkh at kernel.org>" [full]
  gpg: gregkh at kernel.org: Verified 1 signature in the past 58 seconds.  Encrypted
	   0 messages.

I'm guessing this is not exactly the expected behaviour?

Best,
Konstantin



From wk at gnupg.org  Fri Feb 16 08:56:24 2018
From: wk at gnupg.org (Werner Koch)
Date: Fri, 16 Feb 2018 08:56:24 +0100
Subject: Configuration for offline usage - best practice tips?
In-Reply-To: <20180215203305.GA21779@unser.net> (Juergen Christoffel's message
 of "Thu, 15 Feb 2018 21:33:05 +0100")
References: <20180215203305.GA21779@unser.net>
Message-ID: <87o9kps6zb.fsf@wheatstone.g10code.de>

On Thu, 15 Feb 2018 21:33, jc.gnupg18a at unser.net said:

> implementations and standards or strong encryption in general, I expect
> that a configuration for offline usage might be different from one for
> general purpose encrypted communication.

If you never want to use any online resource, you can simply uninstall
dirmngr.  All network access goes via this daemon.

For a case-by-case configuration you can add

  --disable-dirmngr

to the gpg or gpgsm invocation (or conf file).


Shalom-Salam,

   Werner

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

From konstantin at linuxfoundation.org  Fri Feb 16 14:38:56 2018
From: konstantin at linuxfoundation.org (Konstantin Ryabitsev)
Date: Fri, 16 Feb 2018 08:38:56 -0500
Subject: How can we utilize latest GPG from RPM repository?
In-Reply-To: <CACNUArDNPfA3f+T+ztp-s2e4A6ewb+vovjHZYXESkf0cz1-OPQ@mail.gmail.com>
References: <CACNUArDNPfA3f+T+ztp-s2e4A6ewb+vovjHZYXESkf0cz1-OPQ@mail.gmail.com>
Message-ID: <3eb4621b-e960-ad79-8908-3a964a417c4a@linuxfoundation.org>

On 02/14/18 15:20, gpg at mdsresource.net (helices) wrote:
> CentOS 7 uses gnupg2 v2.0.22. EPEL doesn't have anything newer.
> 
> We want to move to v2.2.x, and stay current, but we don't want to download
> source and compile for dozens of systems.

I had a similar need (because my users started to use ECC keys).
Unfortunately, there are no simple answers to this -- to upgrade GnuPG
you would need to upgrade the libraries it depends on (such as
libgcrypt, libassuan, etc), and this cascades to a lot of other things.

I suggest you build gnupg-2.2 without shared libraries and make it
available under /opt/gnupg22:

make build-aux/speedo.mk native INSTALL_DIR=/opt/gnupg22 LDFLAGS=-static

(if someone can recommend a better way that only statically links
gnupg's own libraries like libassuan and libgpg-error, but uses shared
objects for other system libraries, please let me know, as I didn't find
any quickie ways to do it!)

You will need to install at least glibc-static for this, alongside all
other compilation tools. Alternatively, you can build and RPM that does
the same thing -- with the bonus that you don't need to build it
statically if you set it up to correctly handle LD_LIBRARY_PATH bits.

> We want all users to be using the same version all of the time.

Is that for documentation purposes, or because you need features from
gnupg-2.2 that aren't in gnupg-2.0?

Best,
-- 
Konstantin Ryabitsev
Director, IT Infrastructure Security
The Linux Foundation

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

From neal at walfield.org  Fri Feb 16 20:52:35 2018
From: neal at walfield.org (Neal H. Walfield)
Date: Fri, 16 Feb 2018 20:52:35 +0100
Subject: Expected behaviour setting TOFU policy
In-Reply-To: <20180215222014.GA1115@work>
References: <20180215222014.GA1115@work>
Message-ID: <873720r9to.wl-neal@walfield.org>

Hi,

At Thu, 15 Feb 2018 17:20:14 -0500,
Konstantin Ryabitsev wrote:
> But wait, now I can omit --trust-model from the command line and I get the same
> TOFU-based result, implying that trust-model tofu+pgp now sticks, even though
> I've modified no config files:

If you don't explicitly set the trust model, then gpg uses the trust
model that is saved in the trust db.  Using --tofu-policy doesn't use
the trust db (it only updates tofu.db), but --verify does.  Hence
after calling --tofu-policy, the trust mode is not saved, but after
calling --verify it is.

In general, it is better to set the trust-model in your gpg.conf file
and never set it on the command line if only because rebuilding the
trust db is very expensive for large key rings.

I suspect that there are other bugs of this sort, and I'm not sure it
is worth fixing.

:) Neal


From gpg at mdsresource.net  Sun Feb 18 00:06:54 2018
From: gpg at mdsresource.net (helices)
Date: Sat, 17 Feb 2018 17:06:54 -0600
Subject: How can we utilize latest GPG from RPM repository?
In-Reply-To: <CACNUArDNPfA3f+T+ztp-s2e4A6ewb+vovjHZYXESkf0cz1-OPQ@mail.gmail.com>
References: <CACNUArDNPfA3f+T+ztp-s2e4A6ewb+vovjHZYXESkf0cz1-OPQ@mail.gmail.com>
Message-ID: <CACNUArDKDhyxFHhA3bq2B+o1p8Yzbo9Xst=60-N6WHpi8wK86Q@mail.gmail.com>

I will probably never understand why wanting to run the most current
version of gnupg on a plethora of servers is controversial.

Nevertheless, the two (2) greatest reasons are:

   1. PCI DSS v3.2
   2. PCI DSS compliance audits

Being able to demonstrate that we are using the latest, greatest encryption
available on every one of our hosts, simplifies that portion of the audit
equation more than you probably believe.

Furthermore, following feature not availabe in 2.0.22 are more than
nice-to-haves:

   - The file secring.gpg is not used to store the secret keys anymore.
   - All support for PGP-2 keys has been removed for security reasons.
   - The standard key generation interface is now much leaner.
   - Commands to create and sign keys from the command line without any
   extra prompts are now available.
   - There is no more need to manually start the gpg-agent.
   - A new format for locally storing the public keys is now used.
   - Revocation certificates are now created by default.
   - The format of the key listing has been changed to better identify the
   properties of a key.


Apparently, there is no current solution to our problem similar to that we
found for our rsyslog example. That is too bad. We will get over our
disappointment.

However, let it be said here and now, if the gnupg community wants the use
of gnupg to spread far further than a clique of geeks, making its use
easier for non-geeks is probably the simplest and most direct way.

Yes, that is my opinion, humble or otherwise.

YMMV

Are there any other questions before I get a direct answer to my original
subject question?

Thank you.


On Wed, Feb 14, 2018 at 2:20 PM, helices <gpg at mdsresource.net> wrote:

> CentOS 7 uses gnupg2 v2.0.22. EPEL doesn't have anything newer.
>
> We want to move to v2.2.x, and stay current, but we don't want to download
> source and compile for dozens of systems.
>
> We want all users to be using the same version all of the time.
>
> Please, advise. Thank you.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180217/e7ec682f/attachment.html>

From edgar at pettijohn-web.com  Sun Feb 18 03:36:52 2018
From: edgar at pettijohn-web.com (Edgar Pettijohn)
Date: Sat, 17 Feb 2018 20:36:52 -0600
Subject: How can we utilize latest GPG from RPM repository?
In-Reply-To: <CACNUArDKDhyxFHhA3bq2B+o1p8Yzbo9Xst=60-N6WHpi8wK86Q@mail.gmail.com>
References: <CACNUArDNPfA3f+T+ztp-s2e4A6ewb+vovjHZYXESkf0cz1-OPQ@mail.gmail.com>
 <CACNUArDKDhyxFHhA3bq2B+o1p8Yzbo9Xst=60-N6WHpi8wK86Q@mail.gmail.com>
Message-ID: <a5bb4fc7-4844-4825-6c57-c03b57a9b75c@pettijohn-web.com>



On 02/17/18 17:06, helices wrote:
> I will probably never understand why wanting to run the most current 
> version of gnupg on a plethora of servers is controversial.
>
> Nevertheless, the two (2) greatest reasons are:
>
>  1. PCI DSS v3.2
>  2. PCI DSS compliance audits
>
> Being able to demonstrate that we are using the latest, greatest 
> encryption available on every one of our hosts, simplifies that 
> portion of the audit equation more than you probably believe.
>
> Furthermore, following feature not availabe in 2.0.22 are more than 
> nice-to-haves:
>
>   * The file secring.gpg is not used to store the secret keys anymore.
>   * All support for PGP-2 keys has been removed for security reasons.
>   * The standard key generation interface is now much leaner.
>   * Commands to create and sign keys from the command line without any
>     extra prompts are now available.
>   * There is no more need to manually start the gpg-agent.
>   * A new format for locally storing the public keys is now used.
>   * Revocation certificates are now created by default.
>   * The format of the key listing has been changed to better identify
>     the properties of a key.
>
>
> Apparently, there is no current solution to our problem similar to 
> that we found for our rsyslog example. That is too bad. We will get 
> over our disappointment.
>
> However, let it be said here and now, if the gnupg community wants the 
> use of gnupg to spread far further than a clique of geeks, making its 
> use easier for non-geeks is probably the simplest and most direct way.
>
> Yes, that is my opinion, humble or otherwise.
>
> YMMV
>
> Are there any other questions before I get a direct answer to my 
> original subject question?
>
> Thank you.
>
>
> On Wed, Feb 14, 2018 at 2:20 PM, helices <gpg at mdsresource.net 
> <mailto:gpg at mdsresource.net>> wrote:
>
>     CentOS 7 uses gnupg2 v2.0.22. EPEL doesn't have anything newer.
>
>     We want to move to v2.2.x, and stay current, but we don't want to
>     download source and compile for dozens of systems.
>
>     We want all users to be using the same version all of the time.
>
>     Please, advise. Thank you.
>
>
Pay someone to package it for you.
>
>
> _______________________________________________
> 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/20180217/3b9534e1/attachment-0001.html>

From dkg at fifthhorseman.net  Sun Feb 18 05:15:57 2018
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Sat, 17 Feb 2018 23:15:57 -0500
Subject: Configuration for offline usage - best practice tips?
In-Reply-To: <20180215203305.GA21779@unser.net>
References: <20180215203305.GA21779@unser.net>
Message-ID: <87d113lypu.fsf@fifthhorseman.net>

On Thu 2018-02-15 21:33:05 +0100, Juergen Christoffel wrote:

> I'm looking for best practice tips for offline usage of GnuPG. What Do I
> mean by offline usage? I plan to encrypt backups or files on my machines
> with GnuPG and generate weekly or monthly keys for that purpose so backups
> for example can run unattended and simply encrypt with today's public key.
> As the backups need to be compatible with my software only, I could
> possibly choose different configuration options than for my "online" usage.

GnuPG's defaults should be fine for the common, simple backup case.

However, i note that you're talking about "today's public key" -- that
suggests that you're imagining a regularly-updated key that your backup
tooling will know about.  This is in some sense antithetical to "offline
usage" -- how will the backup scripts learn about the new keys if they
can't go online to fetch them?

It sounds like you're proposing an OpenPGP primary key that has a series
of relatively short-lived, expiring encryption-capable subkeys.  Is that
correct?

For further clarity, it'd be useful to understand what you see as the
goal of key rotation here.  Do you plan on deleting older secret
subkeys?  if so, how will you recover backups that were encrypted to the
destroyed secrets?

In an e-mail or messaging context, you can decrypt messages as they
arrive, caching either the cleartext or the session keys; this allows
you to rotate the asymmetric keys, destroying the old asymmetric secrets
as they expire, which provides something approximating "forward
secrecy".  (see the recent improvements in version 0.26 of the notmuch
mail user agent as an example of first steps on the way to implementing
this strategy).

But for backups, this is a slightly more complicated story.  It
certainly can be useful if you want to be able to robustly *destroy*
backups that might be stored on servers that you don't have full control
over.  That is: encrypt the backup to public key X, send the encrypted
copy to "the cloud", and then when you're sure you don't need it any
more, delete the secret key corresponding to X to ensure that it's not
recoverable.  But most people have a hard time just getting their
backups to happen on a reasonable schedule, and don't have a reliable
schedule for backup destruction.  Do you have such a plan?  Or do you
envision some other reason for the proposed key rotation?

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

From ben at adversary.org  Sun Feb 18 10:39:46 2018
From: ben at adversary.org (Ben McGinnes)
Date: Sun, 18 Feb 2018 20:39:46 +1100
Subject: Huawei manual about Gnupg
In-Reply-To: <CAL57ndEGawmQOixXk9KeenTZ==04pQWxrfvsNH-+eDR8zQ5qQg@mail.gmail.com>
References: <CAL57ndEGawmQOixXk9KeenTZ==04pQWxrfvsNH-+eDR8zQ5qQg@mail.gmail.com>
Message-ID: <20180218093946.yq77pv7ulgjxw2le@adversary.org>

On Thu, Feb 15, 2018 at 10:36:28AM +0800, Genghuang Wang wrote:
> Hello, everybody as the Gnupg user

Well, Robert made an excellent point in his response and, indeed, it
is a point of view I share.

However, I felt in need of a laugh, so I at least had a look at this
thing and I certainly did get to laugh ...

> I download the Huawei manual about Gnupg from
> http://support.huawei.com/enterprise/en/tool/software-digital-signature-validation-tool-(pgp-verify)-TL1000000054/TV1000000016
> 
> The English version is the OpenPGP_Signature_Verification_Guide.pdf

Yeah, there's some kind of special in there ... and so many things wrong.

Robert mentioned licensing issues in his post and I can confirm that
there's no concerns regarding any licensing breach in relation to
GnuPG.  Nor is there any use of GnuPG documentation in that file.

> Could you please take a look at it and make some suggestions to
> Huawei to improve it. Thank you!

I could ... but I won't because they're not paying me anywhere near
enough to fix that.

> http://www.huawei.com/en/contact-us

LOL, no ...

For everyone else, though, it's really quite easy to avoid licensing
conflicts if you compile your custom thing against the OpenSSL library
instead of any of the GnuPG ones.  How useful such theing might be
when dealing with OpenPGP compliant data can be left as an exercise t
for others.


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

From ben at adversary.org  Sun Feb 18 10:55:52 2018
From: ben at adversary.org (Ben McGinnes)
Date: Sun, 18 Feb 2018 20:55:52 +1100
Subject: Modernizing Web-of-trust for Organizations
In-Reply-To: <f7c84f6f-0d68-9233-bd3a-71e22fa4dc61@gmail.com>
References: <fcda1d3d-686f-7c34-9545-9673be7f4a11@gmail.com>
 <12300523.20180104004058@my_localhost_LG>
 <d1782a47-7888-aa88-ab35-a6a8e0e17110@gmail.com>
 <20180104222818.dolhf4py76c7qchl@adversary.org>
 <f7c84f6f-0d68-9233-bd3a-71e22fa4dc61@gmail.com>
Message-ID: <20180218095552.xuzi54vemu3ul5gz@adversary.org>

On Fri, Jan 05, 2018 at 08:47:29AM -0800, Lou Wynn wrote:
> On 01/04/2018 02:28 PM, Ben McGinnes wrote:
> > It seems to me, though, that the idea was to provide a means for the
> > company to repudiate an employee's key even if the employee was no
> > longer available.
> 
> This is just one of the benefits enabled by my goals which I stated at
> the beginning, and it is most related to central management of keys.

I see ...

> There are systems that have attempted to solve one or two of them with
> the cost of sacrificing others. My take is doing them all with the new
> trust model and its supporting mechanisms.

So you took a system built from the outset on a security model founded
entirely on public key exchanges between distributed and federated
(both self-determining and self-governing) nodes ... and then spent a
considerable amount of time and effort making that system centralised
in order to meet certain types of common business use cases ...

... with a software package which ships with a complete implementation
of S/MIME as well ...

...

...

Hmm ...

Okay, I just have one question:

*Why?!*


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

From peter at digitalbrains.com  Sun Feb 18 11:33:10 2018
From: peter at digitalbrains.com (Peter Lebbing)
Date: Sun, 18 Feb 2018 11:33:10 +0100
Subject: How can we utilize latest GPG from RPM repository?
In-Reply-To: <CACNUArDKDhyxFHhA3bq2B+o1p8Yzbo9Xst=60-N6WHpi8wK86Q@mail.gmail.com>
References: <CACNUArDNPfA3f+T+ztp-s2e4A6ewb+vovjHZYXESkf0cz1-OPQ@mail.gmail.com>
 <CACNUArDKDhyxFHhA3bq2B+o1p8Yzbo9Xst=60-N6WHpi8wK86Q@mail.gmail.com>
Message-ID: <7b659ddc-67bf-2b95-919e-84309f94ffc3@digitalbrains.com>

On 18/02/18 00:06, helices wrote:
> I will probably never understand why wanting to run the most current
> version of gnupg on a plethora of servers is controversial.

I don't think it is. I'm sorry your question didn't get answered
satisfactorily; that's just how things can go on community mailing lists.

I appreciate your well-formulated arguments for running GnuPG v.2.2.

> However, let it be said here and now, if the gnupg community wants the
> use of gnupg to spread far further than a clique of geeks, making its
> use easier for non-geeks is probably the simplest and most direct way.

I really don't think that it is the task for any upstream to provide
packages for distributions. That truly is what the distributions
themselves are for. For some upstreams it might make sense to provide
their own packages for certain distributions, but I think it's more the
exception that the norm.

> Are there any other questions before I get a direct answer to my
> original subject question?

Since nobody answered with "Oh yeah I happen to package it myself, if
you trust me, you can get it here" or "Oh yeah I know of this person who
packages them", etcetera, my guess is that nobody knows of such a
packaging effort. It's hard to answer affirmatively if you don't know
the affirmative answer :-).

Can I point out that even though you did not like Jeffrey Lightner's
response, Dirk Gottschalk and Konstantin Ryabitsev also replied? If you
could indeed just recompile the Fedora packages, that seems like a
pretty direct route. You do become responsible for updates and "security
support" yourself (in what sense is it still support if you do it
yourself, but hey).

And I wonder if perhaps your interpretation of Jeffrey Lightner's words
was a bit more abrasive than he intended them to be when he wrote those
words, but that is something only Jeffrey Lightner himself can
definitively answer.

Back to the matter at hand. Is it possible for CentOS to provide newer
packages than RHEL? I surmise RHEL will probably not listen to you
unless you get a paid support contract. If CentOS cannot significantly
deviate from RHEL, there doesn't seem to be a gratis way to influence
package versions for CentOS, right? You're dependent on someone
providing packages outside of the distribution proper.

Note, by the way, that interoperability between GnuPG 1.4 and 2.1/2.2 is
not that great, and that often distributions rely on GnuPG in their
internals, meaning there might not be a way to remove GnuPG 1.4 from a
system. It's why Debian deprecated 1.4 before packaging 2.1, so people
would not usually have a system where both are installed. If CentOS 7
relies on GnuPG 1.4, you will need to be careful with 2.1/2.2. Their
keyrings can get out-of-sync.

I'm sorry I don't have a ready answer; if I did, I'd have offered it
days ago...

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/20180218/32cb746b/attachment.sig>

From raysatiro at yahoo.com  Sun Feb 18 20:45:14 2018
From: raysatiro at yahoo.com (Ray Satiro)
Date: Sun, 18 Feb 2018 14:45:14 -0500
Subject: --verify with foo.gpg file does not assume signed data in foo?
Message-ID: <27577671-b6b4-ee8f-9ad5-41757b50fb4b@yahoo.com>

I downloaded an Ubuntu preview ISO [1] recently along with its hash and
signature, SHA256SUMS and SHA256SUMS.gpg. I expected to be able to do this:

gpg --verify SHA256SUMS.gpg
gpg: no signed data
gpg: can't hash datafile: No data

Instead I have to do this:

gpg --verify SHA256SUMS.gpg SHA256SUMS

My question is why is that necessary with gpg files? I know for xxx.sig
files it would strip that extension and then "gpg: assuming signed data
in xxx"

[1]: http://cdimage.ubuntu.com/ubuntu/daily-live/current/



From peter at digitalbrains.com  Sun Feb 18 22:37:59 2018
From: peter at digitalbrains.com (Peter Lebbing)
Date: Sun, 18 Feb 2018 22:37:59 +0100
Subject: --verify with foo.gpg file does not assume signed data in foo?
In-Reply-To: <27577671-b6b4-ee8f-9ad5-41757b50fb4b@yahoo.com>
References: <27577671-b6b4-ee8f-9ad5-41757b50fb4b@yahoo.com>
Message-ID: <1abe8caa-bd40-bbdf-ba8e-e5bb06fdad69@digitalbrains.com>

On 18/02/18 20:45, Ray Satiro via Gnupg-users wrote:
> I know for xxx.sig
> files it would strip that extension and then "gpg: assuming signed data
> in xxx"

I'd like to suggest you shouldn't do it anyway. If somebody supplies you a
non-detached signed file with just a subtly different name, the only difference
will be this line "assuming..." is missing, it will still report a valid
signature. If you're human, like me, you won't notice, but just think "ha, a
valid signature" and continue to use the non-verified file. At this point, your
attacker has already managed to serve you the wrong .sig file, they also
probably supplied you the wrong file it was supposed to have signed.

I'm saying "a subtly different name" because otherwise GnuPG will still warn you:
gpg: WARNING: not a detached signature; file 'xxx' was NOT verified!

But it can't catch those cases where look-alike characters are used, and Unicode
is a vast collection of sometimes similar shapes.

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/20180218/00bce860/attachment.sig>

From wk at gnupg.org  Mon Feb 19 10:53:12 2018
From: wk at gnupg.org (Werner Koch)
Date: Mon, 19 Feb 2018 10:53:12 +0100
Subject: How can we utilize latest GPG from RPM repository?
In-Reply-To: <3eb4621b-e960-ad79-8908-3a964a417c4a@linuxfoundation.org>
 (Konstantin Ryabitsev's message of "Fri, 16 Feb 2018 08:38:56 -0500")
References: <CACNUArDNPfA3f+T+ztp-s2e4A6ewb+vovjHZYXESkf0cz1-OPQ@mail.gmail.com>
 <3eb4621b-e960-ad79-8908-3a964a417c4a@linuxfoundation.org>
Message-ID: <87tvudqp9z.fsf@wheatstone.g10code.de>

On Fri, 16 Feb 2018 14:38, konstantin at linuxfoundation.org said:

> (if someone can recommend a better way that only statically links
> gnupg's own libraries like libassuan and libgpg-error, but uses shared
> objects for other system libraries, please let me know, as I didn't find
> any quickie ways to do it!)

With 2.2.5 you will be able to do that:

     make -f build-aux/speedo.mk STATIC=1 SELFCHECK=0 \
         INSTALL_PREFIX=/somewhere/gnupg22  native
    
    The SELFCHECK=0 is only needed to build from a non-released version.
    You don't need it with a released tarball.

Thanks for your idea.


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/20180219/1bd82a5e/attachment-0001.sig>

From konstantin at linuxfoundation.org  Mon Feb 19 14:41:21 2018
From: konstantin at linuxfoundation.org (Konstantin Ryabitsev)
Date: Mon, 19 Feb 2018 08:41:21 -0500
Subject: How can we utilize latest GPG from RPM repository?
In-Reply-To: <87tvudqp9z.fsf@wheatstone.g10code.de>
References: <CACNUArDNPfA3f+T+ztp-s2e4A6ewb+vovjHZYXESkf0cz1-OPQ@mail.gmail.com>
 <3eb4621b-e960-ad79-8908-3a964a417c4a@linuxfoundation.org>
 <87tvudqp9z.fsf@wheatstone.g10code.de>
Message-ID: <ccf09780-5116-39a8-eee5-ae64c6c294ba@linuxfoundation.org>

On 02/19/18 04:53, Werner Koch wrote:
> On Fri, 16 Feb 2018 14:38, konstantin at linuxfoundation.org said:
> 
>> (if someone can recommend a better way that only statically links
>> gnupg's own libraries like libassuan and libgpg-error, but uses shared
>> objects for other system libraries, please let me know, as I didn't find
>> any quickie ways to do it!)
> 
> With 2.2.5 you will be able to do that:
> 
>      make -f build-aux/speedo.mk STATIC=1 SELFCHECK=0 \
>          INSTALL_PREFIX=/somewhere/gnupg22  native
>     
>     The SELFCHECK=0 is only needed to build from a non-released version.
>     You don't need it with a released tarball.

Oh, nice, thanks for putting that in!

Best,
-- 
Konstantin Ryabitsev
Director, IT Infrastructure Security
The Linux Foundation

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

From dkg at fifthhorseman.net  Mon Feb 19 19:45:52 2018
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 19 Feb 2018 10:45:52 -0800
Subject: Why Operating Systems don't always upgrade GnuPG [was: Re: How can we
 utilize latest GPG from RPM repository?]
In-Reply-To: <CACNUArDKDhyxFHhA3bq2B+o1p8Yzbo9Xst=60-N6WHpi8wK86Q@mail.gmail.com>
References: <CACNUArDNPfA3f+T+ztp-s2e4A6ewb+vovjHZYXESkf0cz1-OPQ@mail.gmail.com>
 <CACNUArDKDhyxFHhA3bq2B+o1p8Yzbo9Xst=60-N6WHpi8wK86Q@mail.gmail.com>
Message-ID: <87606slswv.fsf@fifthhorseman.net>

On Sat 2018-02-17 17:06:54 -0600, helices wrote:
> I will probably never understand why wanting to run the most current
> version of gnupg on a plethora of servers is controversial.

Here's one last try to explain the situation.

GnuPG (and the libraries it depends on) are used by (aka "depended on
by") other libraries and tools, both those integrated into the operating
system itself, and those that might be externally installed.  Some of
these dependencies are "brittle".

Brittle software dependencies
-----------------------------

GnuPG is under active development, and it has never had a fully-featured
stable API (Application Programming Interface).  What i mean is, there
are some capabilities that are only available from the user interface
(UI), and are not in the stable API.  GnuPG's UI has been constantly
improving; sometimes that means that older (worse) UI gets deprecated,
removed, or has its semantics change.

For historical reasons, there are a number of tools that were built
around some element of the GnuPG UI that was current at the time the
tool was built.  Even worse, there are a number of tools that assume
certain behaviors and features of GnuPG's internal storage (e.g. what
goes on in ~/.gnupg/), which has never been explicitly part of its API
(confusingly, there are some exceptions where GnuPG upstream *has*
encouraged other tools to programmatically interact with some elements
within its internal storage).  Newer versions of GnuPG do different
things with its internal storage (and as users we get benefits from
those improvements).

Simply upgrading GnuPG to the latest available version on a server that
also ships other complex software is likely to lead to breakage
elsewhere in the OS because of these brittle assumptions and
dependencies around GnuPG's UI and internal storage.

A case study
------------

For example, the current stable version of the Debian operating system
is Debian 9 ("stretch"), and it ships a version of the "modern" branch
of GnuPG.

As one of the GnuPG maintainers for Debian, i was hoping at one point to
backport the "modern" version of GnuPG to the previous version of Debian
(Debian 8, "jessie"), which some people still run on servers.  I found
that such an upgrade would break at least a half-dozen other packages in
Debian jessie *that i knew of* [0] -- and their breakage would in turn
likely affect some number of other packages.  This was not an exhaustive
survey of all possible bugs, just the most visible ones. :/

I have personally given up on the project of backporting modern GnuPG to
"jessie", because i think what time i can devote to GnuPG maintenance is
better-spent elsewhere.  I don't have the bandwidth to cope with the
resultant bug reports in other packages that such a backport would
produce.  Generally, i encourage users of "jessie" to uprade their
entire OS to the current version of debian stable, and to take advantage
of the improvements to GnuPG that way.

What can we do?
---------------

The problems described above point to problems in the ecosystem *around*
GnuPG, but it also points to concerns about GnuPG's presentation of its
capabilities *to* the rest of the ecosystem.  To the extent that GnuPG
offers features that other tools might want to use, when those features
are not part of an explicit, documented API, the ecosystem apparently
*does* try to manipulate them anyway, with all the attendant brittleness
that you can imagine.

How can GnuPG contribute to fixing this problem?  The traditional way
that many other projects have taken is to define their core programmatic
functionality into a library with a strict interface guarantees, and
have explicitly deprecated other use.  The closest that GnuPG comes to
this technique is GPGME, which is not feature-complete (as compared to
the gpg executable), and has its own history of both difficult upgrades
and unclear/surprising semantics.  It also doesn't have bindings in many
popular programming languages.  When programmers in those language want
to use GnuPG, their shortest path to "something that works" often
involves shelling out to gpg, rather than binding to GPGME. :/ 

Another thing that would help would be to explicitly and succinctly
document the preferred ways of interacting with GnuPG in ways that other
developers find useful.  Perhaps GnuPG could also itself try to detect
when it is being used programmatically in an unstable way and produce
warnings?

Yet another complementary approach might be to aggressively police the
ecosystem by finding other software that deends on GnuPG in any of the
aforementioned brittle ways, and either ask those developers to stop
using GnuPG entirely, or to provide them with stable, well-supported
ways to do what they're looking to do.

I welcome discussion/suggestions on how we can improve this situation,
and i *definitely* welcome help in doing the kind of
ecosystem-perspective work necessary to make it easier to maintain an
up-to-date branch of GnuPG.

But shrugging and suggesting it's uncontroversial to upgrade arbitrary
machines to the latest version of GnuPG doesn't appreciate the scope of
the problem involved with software maintenance in an active and
interdependent ecosystem.

Regards,

        --dkg

[0] examples of breakage:
  https://bugs.debian.org/834281
  https://bugs.debian.org/835075
  https://bugs.debian.org/835592
  https://bugs.debian.org/835465
  https://bugs.debian.org/834514
  https://bugs.debian.org/834600
  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180219/efbac9df/attachment.sig>

From Ian.Green at cartesian.com  Mon Feb 19 14:30:06 2018
From: Ian.Green at cartesian.com (Green, Ian)
Date: Mon, 19 Feb 2018 13:30:06 +0000
Subject: GPG encryption and decryption takes excessive time.
Message-ID: <CY4PR06MB23913C76C3AA36658F075598F2C80@CY4PR06MB2391.namprd06.prod.outlook.com>

Hi
Firstly, my knowledge of GPG is very weak and I am not a UNIX administrator, so my access and knowledge are rather limited.

I have been asked to set up file encryption / decryption of files transferred between our SUN OS servers and two customer's servers.
One customer is using a basic 2048 size key, the other a 3072 key.
GPG has been installed and I have created my keys per the requirements of the clients and imported their keys without issues.
I can encrypt files for them Ok and can decrypt the files they send me.

However, the time taken to encrypt and decrypt each file is colossal - between 6 (2048 key files) and 15 seconds (3072 key files)  per file.

I have set this up on two different local servers (same OS) and get the same results.

The server details are:  SunOS ioponnet-kn-t1 5.10 Generic_142909-17 sun4v sparc sun4v

I have tried recreating the keys locally, but no change.
The other party says that encryption / decryption at their end takes in the order of 50ms per file.

Can anyone suggest anything to help reduce the time to something more viable?

Thanks
Ian




______________________________________________________________________________________________________________________

This message and any attachments are private and confidential. If you have received this message in error, please notify us and remove it from your system without copying or distributing.

Cartesian Limited is registered in England and Wales with number 3230513. Registered office: Descartes House, 8 Gate Street, London, WC2A 3HP.

www.cartesian.com<http://www.cartesian.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180219/54ac6433/attachment.html>

From dashohoxha at gmail.com  Mon Feb 19 21:06:20 2018
From: dashohoxha at gmail.com (Dashamir Hoxha)
Date: Mon, 19 Feb 2018 21:06:20 +0100
Subject: GPG encryption and decryption takes excessive time.
In-Reply-To: <CY4PR06MB23913C76C3AA36658F075598F2C80@CY4PR06MB2391.namprd06.prod.outlook.com>
References: <CY4PR06MB23913C76C3AA36658F075598F2C80@CY4PR06MB2391.namprd06.prod.outlook.com>
Message-ID: <CAMucfLyAZSJhHfhJ-wbYFN7vNLV+VY_0Uzeee8+SDP8ie_F+eQ@mail.gmail.com>

On Mon, Feb 19, 2018 at 2:30 PM, Green, Ian <Ian.Green at cartesian.com> wrote:

>
> Can anyone suggest anything to help reduce the time to something more
> viable?
>

Try symmetric encryption / decryption.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180219/63de66c9/attachment-0001.html>

From edgar at pettijohn-web.com  Mon Feb 19 21:51:08 2018
From: edgar at pettijohn-web.com (edgar at pettijohn-web.com)
Date: Mon, 19 Feb 2018 14:51:08 -0600
Subject: Why Operating Systems don't always upgrade GnuPG [was: Re: How
 can we utilize latest GPG from RPM repository?]
Message-ID: <mailman.7.1519073484.30378.gnupg-users@gnupg.org>


On Feb 19, 2018 12:45 PM, Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:
>
> On Sat 2018-02-17 17:06:54 -0600, helices wrote:
> > I will probably never understand why wanting to run the most current
> > version of gnupg on a plethora of servers is controversial.
>
> Here's one last try to explain the situation.
>
> GnuPG (and the libraries it depends on) are used by (aka "depended on
> by") other libraries and tools, both those integrated into the operating
> system itself, and those that might be externally installed.? Some of
> these dependencies are "brittle".
>
> Brittle software dependencies
> -----------------------------
>
> GnuPG is under active development, and it has never had a fully-featured
> stable API (Application Programming Interface).? What i mean is, there
> are some capabilities that are only available from the user interface
> (UI), and are not in the stable API.? GnuPG's UI has been constantly
> improving; sometimes that means that older (worse) UI gets deprecated,
> removed, or has its semantics change.
>
> For historical reasons, there are a number of tools that were built
> around some element of the GnuPG UI that was current at the time the
> tool was built.? Even worse, there are a number of tools that assume
> certain behaviors and features of GnuPG's internal storage (e.g. what
> goes on in ~/.gnupg/), which has never been explicitly part of its API
> (confusingly, there are some exceptions where GnuPG upstream *has*
> encouraged other tools to programmatically interact with some elements
> within its internal storage).? Newer versions of GnuPG do different
> things with its internal storage (and as users we get benefits from
> those improvements).
>
> Simply upgrading GnuPG to the latest available version on a server that
> also ships other complex software is likely to lead to breakage
> elsewhere in the OS because of these brittle assumptions and
> dependencies around GnuPG's UI and internal storage.
>
> A case study
> ------------
>
> For example, the current stable version of the Debian operating system
> is Debian 9 ("stretch"), and it ships a version of the "modern" branch
> of GnuPG.
>
> As one of the GnuPG maintainers for Debian, i was hoping at one point to
> backport the "modern" version of GnuPG to the previous version of Debian
> (Debian 8, "jessie"), which some people still run on servers.? I found
> that such an upgrade would break at least a half-dozen other packages in
> Debian jessie *that i knew of* [0] -- and their breakage would in turn
> likely affect some number of other packages.? This was not an exhaustive
> survey of all possible bugs, just the most visible ones. :/
>
> I have personally given up on the project of backporting modern GnuPG to
> "jessie", because i think what time i can devote to GnuPG maintenance is
> better-spent elsewhere.? I don't have the bandwidth to cope with the
> resultant bug reports in other packages that such a backport would
> produce.? Generally, i encourage users of "jessie" to uprade their
> entire OS to the current version of debian stable, and to take advantage
> of the improvements to GnuPG that way.
>
> What can we do?
> ---------------
>
> The problems described above point to problems in the ecosystem *around*
> GnuPG, but it also points to concerns about GnuPG's presentation of its
> capabilities *to* the rest of the ecosystem.? To the extent that GnuPG
> offers features that other tools might want to use, when those features
> are not part of an explicit, documented API, the ecosystem apparently
> *does* try to manipulate them anyway, with all the attendant brittleness
> that you can imagine.
>
> How can GnuPG contribute to fixing this problem?? The traditional way
> that many other projects have taken is to define their core programmatic
> functionality into a library with a strict interface guarantees, and
> have explicitly deprecated other use.? The closest that GnuPG comes to
> this technique is GPGME, which is not feature-complete (as compared to
> the gpg executable), and has its own history of both difficult upgrades
> and unclear/surprising semantics.? It also doesn't have bindings in many
> popular programming languages.? When programmers in those language want
> to use GnuPG, their shortest path to "something that works" often
> involves shelling out to gpg, rather than binding to GPGME. :/ 

That doesn't sound secure. Probably shouldn't use such programs on a server. Gpgme looks to do everything that it needs to do. Can you specify a function it is missing? 

>
> Another thing that would help would be to explicitly and succinctly
> document the preferred ways of interacting with GnuPG in ways that other
> developers find useful.? Perhaps GnuPG could also itself try to detect
> when it is being used programmatically in an unstable way and produce
> warnings?
>
> Yet another complementary approach might be to aggressively police the
> ecosystem by finding other software that deends on GnuPG in any of the
> aforementioned brittle ways, and either ask those developers to stop
> using GnuPG entirely, or to provide them with stable, well-supported
> ways to do what they're looking to do.

I think gpgme is the answer here as well. If you mean specifically a python interface to gpgme then it's probably up to a python developer to get that rolling.

>
> I welcome discussion/suggestions on how we can improve this situation,
> and i *definitely* welcome help in doing the kind of
> ecosystem-perspective work necessary to make it easier to maintain an
> up-to-date branch of GnuPG.
>
> But shrugging and suggesting it's uncontroversial to upgrade arbitrary
> machines to the latest version of GnuPG doesn't appreciate the scope of
> the problem involved with software maintenance in an active and
> interdependent ecosystem.
>
> Regards,
>
> ??????? --dkg
>
> [0] examples of breakage:
> ? https://bugs.debian.org/834281
> ? https://bugs.debian.org/835075
> ? https://bugs.debian.org/835592
> ? https://bugs.debian.org/835465
> ? https://bugs.debian.org/834514
> ? https://bugs.debian.org/834600
> ? 
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users

From peter at digitalbrains.com  Mon Feb 19 21:54:35 2018
From: peter at digitalbrains.com (Peter Lebbing)
Date: Mon, 19 Feb 2018 21:54:35 +0100
Subject: GPG encryption and decryption takes excessive time.
In-Reply-To: <CAMucfLyAZSJhHfhJ-wbYFN7vNLV+VY_0Uzeee8+SDP8ie_F+eQ@mail.gmail.com>
References: <CY4PR06MB23913C76C3AA36658F075598F2C80@CY4PR06MB2391.namprd06.prod.outlook.com>
 <CAMucfLyAZSJhHfhJ-wbYFN7vNLV+VY_0Uzeee8+SDP8ie_F+eQ@mail.gmail.com>
Message-ID: <ce81437c-d960-5ae4-113b-6ddccc3018de@digitalbrains.com>

On 19/02/18 21:06, Dashamir Hoxha wrote:
> Try symmetric encryption / decryption.?

GnuPG uses hybrid encryption. Content is already encrypted with
symmetric encryption, and only the randomly generated symmetric key, 16
or 32 bytes large usually, is encrypted asymmetrically to the recipient,
possibly twice as OP mentioned two customers.

Since symmetric mode of GnuPG uses passphrase stretching, I doubt that
would be faster anyway, though I haven't tried this.

The problem appears to be somewhere else. However, I think the OP should
provide more details. File sizes, specifications of the computers it
runs on, software versions...

My first instinct is: there is insufficient randomness, and GnuPG is
blocking waiting for more to become available before it can do any work.

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/20180219/de0d13e0/attachment.sig>

From peter at digitalbrains.com  Mon Feb 19 21:56:21 2018
From: peter at digitalbrains.com (Peter Lebbing)
Date: Mon, 19 Feb 2018 21:56:21 +0100
Subject: GPG encryption and decryption takes excessive time.
In-Reply-To: <ce81437c-d960-5ae4-113b-6ddccc3018de@digitalbrains.com>
References: <CY4PR06MB23913C76C3AA36658F075598F2C80@CY4PR06MB2391.namprd06.prod.outlook.com>
 <CAMucfLyAZSJhHfhJ-wbYFN7vNLV+VY_0Uzeee8+SDP8ie_F+eQ@mail.gmail.com>
 <ce81437c-d960-5ae4-113b-6ddccc3018de@digitalbrains.com>
Message-ID: <d9a8d0b0-ca32-347e-57ad-478cf18647b1@digitalbrains.com>

On 19/02/18 21:54, Peter Lebbing wrote:
> Since symmetric mode of GnuPG uses passphrase stretching, [...]

Obviously I meant key stretching.

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/20180219/9c5c7bf1/attachment.sig>

From 2017-r3sgs86x8e-lists-groups at riseup.net  Tue Feb 20 01:19:50 2018
From: 2017-r3sgs86x8e-lists-groups at riseup.net (MFPA)
Date: Tue, 20 Feb 2018 00:19:50 +0000
Subject: Why Operating Systems don't always upgrade GnuPG [was: Re: How
 can we utilize latest GPG from RPM repository?]
Message-ID: <489596862.20180220001950@my_localhost_LG>

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

Hi


On Monday 19 February 2018 at 8:51:08 PM, in a message with no id,
edgar at pettijohn-web.com wrote:-


> I think gpgme is the answer here as well. If you mean
> specifically
> a python interface to gpgme then it's probably up to
> a python developer to get that rolling.

Python bindings are among those maintained within the GPGME
repository.

See https://wiki.gnupg.org/APIs



- --
Best regards

MFPA                  <mailto:2017-r3sgs86x8e-lists-groups at riseup.net>

After all is said and done, a lot more will be said than done.
-----BEGIN PGP SIGNATURE-----

iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCWotpwF8UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw
Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju
+rFDAP9aIDxhmkvC8xFKh2TI/JWefO9UNIDUh+0iYom167DTKQD+OQ/iUn5MW6fu
PfJfdRiAMR5fMB7NpFvzcrRbkoXzQQCJApMEAQEKAH0WIQRSX6konxd5jbM7JygT
DfUWES/A/wUCWotpwF8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMw
REY1MTYxMTJGQzBGRgAKCRATDfUWES/A/0IVD/0ZWM6fz12is1z2FrZq9S9RX/dE
pz4UedrGjWcufMzv39R2V8TS03u0dx+vAzRo8KT05DGtvIna+3FhosnXSRBu3JSZ
jfT3pfA8hIPY2p2lJK0s2haeL98S2Yu3wJ2Yt+KgS9MmyFOSL/022fVDvYFwi+9Y
/oJlQaE5BXBXvS3n/0WsMrZzDcY3nLf5S0eSK9MSd9rM/M4z09KxS2dngj1Sifgv
GIiBYD7MwnZaaIi8WLGYTj6YeXSVMtlHzXa83fNiZtNOmLRI6p8VkMQUTh5Tjt3F
qlDd+zTSkn801IGiivEYfaOQcRylfTqORhSEFZqIUXI4W/uzJ6NL165SMNgfUa9m
UAinMeKWuC8SdJwKU3BcaqhqhdwoI5HjNq4RQm5K833dkjvn8XoBZ/Tk+Xy918oW
5UCsF3w+AZ9pCG1li0ZnCRkyK7BL0LE8qmotRfknyd9pbGkmljbQYYrxBFKtQdjx
QFvV5OymnxeJcFLqa/cWv7Mz2jPNkA5dSIdPEp0Gsq1Of9hfwS8sddJ6Z/bFONa9
WfSam337dgrZv9aa6I7sO9AP28gkKbB+W9TRVi5WW1m3tHqTm9WOXv30HKLuuyeO
f+K9v0NbKbhoUu1KzYPmXbzBzqeRlYgtGac85I/UvVWV4XzN80G8sxoHsg/fPyd5
sMEr+A2cUaWR7F0DUQ==
=VNMJ
-----END PGP SIGNATURE-----



From peter at digitalbrains.com  Tue Feb 20 11:30:44 2018
From: peter at digitalbrains.com (Peter Lebbing)
Date: Tue, 20 Feb 2018 11:30:44 +0100
Subject: Why Operating Systems don't always upgrade GnuPG
In-Reply-To: <87606slswv.fsf@fifthhorseman.net>
References: <CACNUArDNPfA3f+T+ztp-s2e4A6ewb+vovjHZYXESkf0cz1-OPQ@mail.gmail.com>
 <CACNUArDKDhyxFHhA3bq2B+o1p8Yzbo9Xst=60-N6WHpi8wK86Q@mail.gmail.com>
 <87606slswv.fsf@fifthhorseman.net>
Message-ID: <cd5fabc7-0898-ff1a-c62d-918d2880a507@digitalbrains.com>

On 19/02/18 19:45, Daniel Kahn Gillmor wrote:
> But shrugging and suggesting it's uncontroversial to upgrade arbitrary
> machines to the latest version of GnuPG doesn't appreciate the scope of
> the problem involved with software maintenance in an active and
> interdependent ecosystem.

You are right and I feel stupid for suggesting it is uncontroversial.
Hell, you'd think running Debian stretch/stable (with its 2.1.18) on a
plethora of servers would be uncontroversial, but even that isn't
totally free of controversy. There are people having problems with
adjusting their process to use GnuPG 2.1+.

I am very grateful for all the work you put in to not only fix programs
in Debian depending on /usr/bin/gpg2 being 2.0, but also fix programs
depending on /usr/bin/gpg being 1.4. Because even though
co-installability was considered while designing 2.1, in practice 1.4
and 2.1+ don't mix well.

Thank you.

If done with care and attention, there are still situations where
installing GnuPG 2.2 on what is the most recent version of CentOS/RHEL
is a good thing to do. You have to carefully consider which software
will be using GnuPG, though.

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/20180220/c78633f6/attachment-0001.sig>

From dashohoxha at gmail.com  Tue Feb 20 13:18:40 2018
From: dashohoxha at gmail.com (Dashamir Hoxha)
Date: Tue, 20 Feb 2018 13:18:40 +0100
Subject: Why Operating Systems don't always upgrade GnuPG [was: Re: How
 can we utilize latest GPG from RPM repository?]
In-Reply-To: <87606slswv.fsf@fifthhorseman.net>
References: <CACNUArDNPfA3f+T+ztp-s2e4A6ewb+vovjHZYXESkf0cz1-OPQ@mail.gmail.com>
 <CACNUArDKDhyxFHhA3bq2B+o1p8Yzbo9Xst=60-N6WHpi8wK86Q@mail.gmail.com>
 <87606slswv.fsf@fifthhorseman.net>
Message-ID: <CAMucfLx5DRTM70dt6XB4YaQ9g29=y5r2_TtCvGnf1cu0-rFu=A@mail.gmail.com>

On Mon, Feb 19, 2018 at 7:45 PM, Daniel Kahn Gillmor <dkg at fifthhorseman.net>
wrote:

> On Sat 2018-02-17 17:06:54 -0600, helices wrote:
> > I will probably never understand why wanting to run the most current
> > version of gnupg on a plethora of servers is controversial.
>
> Here's one last try to explain the situation.
>
> GnuPG (and the libraries it depends on) are used by (aka "depended on
> by") other libraries and tools, both those integrated into the operating
> system itself, and those that might be externally installed.  Some of
> these dependencies are "brittle".
>

One solution to this situation may be to install the latest GnuPG
in a Docker container, where it can have all the required libraries
and dependencies that it needs, without disturbing the host OS.

But I am aware that this may present some challenges for  normal
usage and may not be suitable except for testing.

Another solution may be to use a "snap", which is a kind of new
software packaging invented by Ubuntu:
 - https://snapcraft.io/
 - https://docs.snapcraft.io/snaps/intro
The idea is that a software is shipped with all the dependencies,
so it does not matter in which OS it is installed, it will always work.

I don't know the details of snaps. Since it is a "containerized software
package" maybe it is not much different from the docker solution
above and maybe has the same challenges/problems.

If anybody is willing to give a try to any of these solutions I would like
to help.

Regards,
Dashamir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180220/4520994c/attachment.html>

From kristian.fiskerstrand at sumptuouscapital.com  Tue Feb 20 13:43:54 2018
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Tue, 20 Feb 2018 13:43:54 +0100
Subject: Why Operating Systems don't always upgrade GnuPG [was: Re: How
 can we utilize latest GPG from RPM repository?]
In-Reply-To: <CAMucfLx5DRTM70dt6XB4YaQ9g29=y5r2_TtCvGnf1cu0-rFu=A@mail.gmail.com>
References: <CACNUArDNPfA3f+T+ztp-s2e4A6ewb+vovjHZYXESkf0cz1-OPQ@mail.gmail.com>
 <CACNUArDKDhyxFHhA3bq2B+o1p8Yzbo9Xst=60-N6WHpi8wK86Q@mail.gmail.com>
 <87606slswv.fsf@fifthhorseman.net>
 <CAMucfLx5DRTM70dt6XB4YaQ9g29=y5r2_TtCvGnf1cu0-rFu=A@mail.gmail.com>
Message-ID: <cbab27d6-b1e5-ba9e-545d-097e67db4ae9@sumptuouscapital.com>

On 02/20/2018 01:18 PM, Dashamir Hoxha wrote:
> If anybody is willing to give a try to any of these solutions I would
> like to help.

I would be generally cautious for both approaches without proper support
in the surrounding infrastructure. In particular an upgrade to a
depending library would need to automatically cause a rebuild of the
container in the case of a security upgrade when such embedding happens,
which is generally a bad thing unless you have a large scale deployment
and defined QA processes for terminating and replacing containers with
new deployments regularly.

-- 
----------------------------
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
----------------------------
Manus manum lavat
One hand washes the other

-------------- 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/20180220/5320e845/attachment.sig>

From ben at adversary.org  Tue Feb 20 13:59:14 2018
From: ben at adversary.org (Ben McGinnes)
Date: Tue, 20 Feb 2018 23:59:14 +1100
Subject: GPG encryption and decryption takes excessive time.
In-Reply-To: <CY4PR06MB23913C76C3AA36658F075598F2C80@CY4PR06MB2391.namprd06.prod.outlook.com>
References: <CY4PR06MB23913C76C3AA36658F075598F2C80@CY4PR06MB2391.namprd06.prod.outlook.com>
Message-ID: <20180220125914.p3n5yac72eojimwc@adversary.org>

On Mon, Feb 19, 2018 at 01:30:06PM +0000, Green, Ian wrote:
> Hi
> Firstly, my knowledge of GPG is very weak and I am not a UNIX administrator, so my access and knowledge are rather limited.
> 
> I have been asked to set up file encryption / decryption of files
> transferred between our SUN OS servers and two customer's servers.

What are the customers running?  More SunOSand/or Solaris or something
else?

> One customer is using a basic 2048 size key, the other a 3072 key.
> GPG has been installed and I have created my keys per the
> requirements of the clients and imported their keys without issues.
>
> I can encrypt files for them Ok and can decrypt the files they send me.
> 
> However, the time taken to encrypt and decrypt each file is colossal
> - between 6 (2048 key files) and 15 seconds (3072 key files) per
> file.

How big are the files and what kind of files (as in file type rather
than business use case)?

> I have set this up on two different local servers (same OS) and get
> the same results.
> 
> The server details are: SunOS ioponnet-kn-t1 5.10 Generic_142909-17
> sun4v sparc sun4v

It's actually SPARC?  Not UltraSPARC?  That hostname is hinting
towards a T1.  Is it really or is it something else?

Also, which filesystem(s) are you running?  ZFS or something ancient?

Are you trying to do this across NFS?  Are there also either a SAN or
NAS involved, if so, which (and did it come tith the Sun kit or was it
hooked in separately.

Well, may as well try the easy bit first ... run this as root:

    iostat -En

Check the drives for collisions, if two of them are reporting massive
numbers of collisions then one is dead and the other is on the same
bus and is getting overloaded by the redirected traffic (which will
slow the rest of the array down).

That's the usual problem, but if it's not then we'll see.  Still
Solaris 10 has lots of nifty diagnostics tools to narrow things down
beyond that.

> Can anyone suggest anything to help reduce the time to something
> more viable?

Plenty, but I need to know what the system specs are before I can
determine what's actually feasible with that model.

The Solaris patch version indicates it's several years old as it is
and I'm guessing they're out of the warranty period.  Or maybe not, it
could just be that now that Oracle have fired all the old Sun
engineers there's no one there who can help ... and the fact that the
E25Ks and the M9000s are truly doomed is such a damned waste, but I
digress.

Don't be too disheartened if the model was produced prior to Oracle's
acquisition of Sun either, most of those systems were still well ahead
of any of what we called "x-boxes" (i.e. the X-series or anything with
an x86-64 architecture; IIRC they were all AMDs).  Besides, if it's
pre-2009, then I'll have at least a decent portion of the old SunSolve
handbook for the model in archive.  Yes, that is the massive trove of
Sun documentation that Oracle took offline in the first 3 months or
so; and no, it's not the whole thing (which was *huge*), just the
portable version).


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

From wk at gnupg.org  Tue Feb 20 16:08:35 2018
From: wk at gnupg.org (Werner Koch)
Date: Tue, 20 Feb 2018 16:08:35 +0100
Subject: Why Operating Systems don't always upgrade GnuPG
In-Reply-To: <87606slswv.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message
 of "Mon, 19 Feb 2018 10:45:52 -0800")
References: <CACNUArDNPfA3f+T+ztp-s2e4A6ewb+vovjHZYXESkf0cz1-OPQ@mail.gmail.com>
 <CACNUArDKDhyxFHhA3bq2B+o1p8Yzbo9Xst=60-N6WHpi8wK86Q@mail.gmail.com>
 <87606slswv.fsf@fifthhorseman.net>
Message-ID: <874lmbpuks.fsf@wheatstone.g10code.de>

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

> GnuPG is under active development, and it has never had a fully-featured
> stable API (Application Programming Interface).  What i mean is, there
> are some capabilities that are only available from the user interface
> (UI), and are not in the stable API.  GnuPG's UI has been constantly

You probably expected that I need to dissent: Modulo a few bugs there
has always been a stable API in GnuPG and we have taken great caution to
not break it.  Granted some parts of the API are not easy to use but
nevertheless, they are stable.  For example the --edit-key interactor
requires the use a state machine to stay compatible with future versions
of GnuPG.  This has been remarked over and over in the last ~20 years.
Unfortunately some folks reject to read manuals, examples and
description on proper use and just go ahead and do what seems to work.
Actually this is not just a gpg thing: I have seen too many scripts and
programs which neglect to use LC_ALL=C and break as soon as they are
running under a different locale.

To avoid such breakage but keeping friendly to the command line user,
gpg provide a machine interface (--with-colons, --batch, --command-fd)
to make automation easy.

> improving; sometimes that means that older (worse) UI gets deprecated,
> removed, or has its semantics change.

Deprecated, okay.  But I am not aware of semantic changes except for
rare corner cases.

> certain behaviors and features of GnuPG's internal storage (e.g. what
> goes on in ~/.gnupg/), which has never been explicitly part of its API
> (confusingly, there are some exceptions where GnuPG upstream *has*
> encouraged other tools to programmatically interact with some elements

I can't count how often I wrote that the only defined way to access the
content of keyrings are my means of the --export and --import commands.  

Please give examples.

> Simply upgrading GnuPG to the latest available version on a server that
> also ships other complex software is likely to lead to breakage
> elsewhere in the OS because of these brittle assumptions and
> dependencies around GnuPG's UI and internal storage.

Right.  However, this is not due to changing APIs of GnuPG but due to
the wrong use of the API.  Much like we have seen that grep and sed
started to fail on localized systems.

And even today, we see hackers who are breaking working integration of
gpg by replacing the (correct) use of the machine interface by the
supposed easier to use human interface of gpg.  And then encountering
problems with newer versions of gpg.  :-(

> are not part of an explicit, documented API, the ecosystem apparently
> *does* try to manipulate them anyway, with all the attendant brittleness
> that you can imagine.

Right.  That is a bad idea and that is why it took many years to get a
modern version in widespread use.

> that many other projects have taken is to define their core programmatic
> functionality into a library with a strict interface guarantees, and

Library interfaces are as much abused as command line interfaces.  This
is not really the point.  A library may have the advantage that it
exposes only a smaller set of interfaces and thus lessens the risk of
wrong usage.

> have explicitly deprecated other use.  The closest that GnuPG comes to
> this technique is GPGME, which is not feature-complete (as compared to

That is on purpose; see above.

> developers find useful.  Perhaps GnuPG could also itself try to detect
> when it is being used programmatically in an unstable way and produce

Those tools won't notice these warnings because they hide away the
actual output of gpg. 

> Yet another complementary approach might be to aggressively police the
> ecosystem by finding other software that deends on GnuPG in any of the
> aforementioned brittle ways, and either ask those developers to stop

That is what our plan for the time after 2.2 was.  Unfortunately, this
seems to be a boring job for some hackers and thus some of them opted to
leave gnupg to work on cool new stuff instead.  Nevertheless, this is
still high on my task list.

> machines to the latest version of GnuPG doesn't appreciate the scope of
> the problem involved with software maintenance in an active and
> interdependent ecosystem.

Well said.


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/20180220/7a806cff/attachment.sig>

From neal at walfield.org  Tue Feb 20 20:36:32 2018
From: neal at walfield.org (Neal H. Walfield)
Date: Tue, 20 Feb 2018 20:36:32 +0100
Subject: Why Operating Systems don't always upgrade GnuPG
In-Reply-To: <874lmbpuks.fsf@wheatstone.g10code.de>
References: <CACNUArDNPfA3f+T+ztp-s2e4A6ewb+vovjHZYXESkf0cz1-OPQ@mail.gmail.com>
 <CACNUArDKDhyxFHhA3bq2B+o1p8Yzbo9Xst=60-N6WHpi8wK86Q@mail.gmail.com>
 <87606slswv.fsf@fifthhorseman.net>
 <874lmbpuks.fsf@wheatstone.g10code.de>
Message-ID: <87woz7pi67.wl-neal@walfield.org>

At Tue, 20 Feb 2018 16:08:35 +0100,
Werner Koch wrote:
> > Yet another complementary approach might be to aggressively police the
> > ecosystem by finding other software that deends on GnuPG in any of the
> > aforementioned brittle ways, and either ask those developers to stop
> 
> That is what our plan for the time after 2.2 was.  Unfortunately, this
> seems to be a boring job for some hackers and thus some of them opted to
> leave gnupg to work on cool new stuff instead.  Nevertheless, this is
> still high on my task list.

I'd rather not air dirty laundry, but I feel it necessary to correct
misinformation.  I did not leave g10code, because working on gpg was
"uncool".  I left because we (Werner and I) could not work well
together.  This is the same reason that Justus, Kai and Marcus left.


From ben at adversary.org  Wed Feb 21 04:05:30 2018
From: ben at adversary.org (Ben McGinnes)
Date: Wed, 21 Feb 2018 14:05:30 +1100
Subject: Solaris 11 install libgpg-error/libgcrypt make install hangs
In-Reply-To: <BLUPR14MB0162C469C90CB899D6BAFE95DEF20@BLUPR14MB0162.namprd14.prod.outlook.com>
References: <BLUPR14MB0162C469C90CB899D6BAFE95DEF20@BLUPR14MB0162.namprd14.prod.outlook.com>
Message-ID: <20180221030530.bvnaghb4weflvywx@adversary.org>

On Fri, Feb 09, 2018 at 03:35:13PM +0000, Anna Kitces and Seth Fishman wrote:
> Hi
> 
> I ran ./configure, make, make check and entered make install over an
> hour ago

That seems a bit long.

> the make check was clean

Cool.

> If I hit ctrl-C, how do I proceed?
> 
> I am installing all the latest.
>
> Trying to get GnuPG installed and these are pre-reqs
> 
> I am not a developer so not sure the impact of cancelling a make
> install. do I need to do an uninstall?

Nope.

> Sorry but kind of at a loss on what to do.

Yeah, fair enough.  Since the make check was clean you can just try
running make install again (presumably you are doing that part as
root) and seeing if it completes.  If it does, great; if it doesn't
and just seems to hang then either post any reported errors here or
try moving on to the next library.  Eventually there will be a package
that has it as a dependency and if this install didn't actually work
you'll find out during the configure stage of the one to have it as a
dependency.

There's a reasonable chance it has actually installed, but done
something silly in reporting that fact during the installation.
Proceeding won't really hurt because the worst case scenario is just
going back to this point in the installation process and doing it
again.  It doesn't matter if binaries and libs are copied over during
a subsequent installation attempt since that's precisely how upgrades
occur anyway.


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

From ben at adversary.org  Wed Feb 21 04:38:40 2018
From: ben at adversary.org (Ben McGinnes)
Date: Wed, 21 Feb 2018 14:38:40 +1100
Subject: Why Operating Systems don't always upgrade GnuPG [was: Re: How
 can we utilize latest GPG from RPM repository?]
In-Reply-To: <87606slswv.fsf@fifthhorseman.net>
References: <CACNUArDNPfA3f+T+ztp-s2e4A6ewb+vovjHZYXESkf0cz1-OPQ@mail.gmail.com>
 <CACNUArDKDhyxFHhA3bq2B+o1p8Yzbo9Xst=60-N6WHpi8wK86Q@mail.gmail.com>
 <87606slswv.fsf@fifthhorseman.net>
Message-ID: <20180221033840.idnv3x3vy7jnbxmz@adversary.org>

On Mon, Feb 19, 2018 at 10:45:52AM -0800, Daniel Kahn Gillmor wrote:
> 
> How can GnuPG contribute to fixing this problem?  The traditional way
> that many other projects have taken is to define their core programmatic
> functionality into a library with a strict interface guarantees, and
> have explicitly deprecated other use.  The closest that GnuPG comes to
> this technique is GPGME, which is not feature-complete (as compared to
> the gpg executable), and has its own history of both difficult upgrades
> and unclear/surprising semantics.

True, but what it does have available still covers a *lot* of what
people do mainly want to access programmatically.  My trusty key
counter is now done that way (it takes a while to run, but that's due
to the size of the keybox, not due to GPGME).

> It also doesn't have bindings in many popular programming languages.

There is a cunning plan which may provide a bridge to at least in part
address that.

> When programmers in those language want to use GnuPG, their shortest
> path to "something that works" often involves shelling out to gpg,
> rather than binding to GPGME. :/

Yes....

> Another thing that would help would be to explicitly and succinctly
> document the preferred ways of interacting with GnuPG in ways that other
> developers find useful.

That would be brilliant, but it requires convincing developers to not
simply document their work, but to actually step back from their
focussed POV and abstract what they're intending to do so we can
determine what will actually be useful to procide all developers.
Otherwise we'll just end up with a bunch of feature requests specific
to the problem each developer happens to be working on at the time
they notify us.

If you can work out a way to get engineers to understand why that's
important ... you'll become very rich shortly thereafter.  ;)

> Perhaps GnuPG could also itself try to detect when it is being used
> programmatically in an unstable way and produce warnings?

Most of the worst of those examples are in bash, how're you going to
tell the difference between that and a user?

> Yet another complementary approach might be to aggressively police
> the ecosystem by finding other software that deends on GnuPG in any
> of the aforementioned brittle ways, and either ask those developers
> to stop using GnuPG entirely, or to provide them with stable,
> well-supported ways to do what they're looking to do.

And people accuse me of being combative!  Wow ... you're brave ...

Moreseriously, though, let's besure we've got an alternative method to
replace whatever their pet project's method is first.

Arguably gpgme-tool might already do that, but we'll see.

> I welcome discussion/suggestions on how we can improve this situation,
> and i *definitely* welcome help in doing the kind of
> ecosystem-perspective work necessary to make it easier to maintain an
> up-to-date branch of GnuPG.

I'm already laying the groundwork on the API side of things, as well
as working on doumentation.

> But shrugging and suggesting it's uncontroversial to upgrade arbitrary
> machines to the latest version of GnuPG doesn't appreciate the scope of
> the problem involved with software maintenance in an active and
> interdependent ecosystem.

Indeed.  I didn't check your buglist ... but I did recall that one of
the dependencies of GMIME is GPGME.  Pretty sure that'll affect a few
packages and libgcrypt & libgpg-error are a dependencies for lots things.

It's exactly this sort of thing which led to the popularity of
installing things the users wanted in /usr/local or /opt or wherever
specifically to prevent the end user use case adversely affecting the
system's use case.


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

From dkg at fifthhorseman.net  Wed Feb 21 04:53:57 2018
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 20 Feb 2018 19:53:57 -0800
Subject: Why Operating Systems don't always upgrade GnuPG [was: Re: How
 can we utilize latest GPG from RPM repository?]
In-Reply-To: <CAMucfLx5DRTM70dt6XB4YaQ9g29=y5r2_TtCvGnf1cu0-rFu=A@mail.gmail.com>
References: <CACNUArDNPfA3f+T+ztp-s2e4A6ewb+vovjHZYXESkf0cz1-OPQ@mail.gmail.com>
 <CACNUArDKDhyxFHhA3bq2B+o1p8Yzbo9Xst=60-N6WHpi8wK86Q@mail.gmail.com>
 <87606slswv.fsf@fifthhorseman.net>
 <CAMucfLx5DRTM70dt6XB4YaQ9g29=y5r2_TtCvGnf1cu0-rFu=A@mail.gmail.com>
Message-ID: <87o9kjj8ve.fsf@fifthhorseman.net>

On Tue 2018-02-20 13:18:40 +0100, Dashamir Hoxha wrote:
> One solution to this situation may be to install the latest GnuPG
> in a Docker container, where it can have all the required libraries
> and dependencies that it needs, without disturbing the host OS.

I think this misses the point that it's not just *what does gnupg depend
on* but it's also *what depends on gnupg*.  The dependencies work in
both directions.

> Another solution may be to use a "snap", which is a kind of new
> software packaging invented by Ubuntu:

The basic idea behind "snap" and "flatpak" and other similar tools is
what many people call "bundling" or "vendoring" -- you ship the program
together with all its dependencies, regardless of what dependencies are
on the host system.  it's not a new idea at all, and is quite common on
many platforms, including in some flavors of cowboy web development.

As with docker containsers, this approach doesn't address the other
direction of the dependency graph.  In addition, all of these approaches
have maintenance costs and open questions about responsibility.  if
every app ships with its own bundled copy of libfoo, and a flaw is found
in libfoo, then it needs to be fixed.  can you be sure you've found and
fixed all copies?  Who is responsible for fixing each specific copy?  Do
those maintainers have enough time/attention/living expenses to make
sure vulerabilities and software flaws get patched in all of their
dependencies?  are they willing to re-ship the entire bundle/snap/docker
image for each dependency that needs an upgrade?

I recently heard bundling/vendoring/snaps/docker containers
characterized in the following way, which resonated with me:

    Hm, maintaining a complex operating system is hard.  I know, we can
    fix that by trying to maintain 100 complex operating systems
    instead!

To be clear, i believe that there are contexts where bundling is
actually the right approach.  But it is not an obvious win to me in most
cases.

Regards,

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

From dkg at fifthhorseman.net  Wed Feb 21 06:35:12 2018
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 20 Feb 2018 21:35:12 -0800
Subject: Why Operating Systems don't always upgrade GnuPG
In-Reply-To: <874lmbpuks.fsf@wheatstone.g10code.de>
References: <CACNUArDNPfA3f+T+ztp-s2e4A6ewb+vovjHZYXESkf0cz1-OPQ@mail.gmail.com>
 <CACNUArDKDhyxFHhA3bq2B+o1p8Yzbo9Xst=60-N6WHpi8wK86Q@mail.gmail.com>
 <87606slswv.fsf@fifthhorseman.net> <874lmbpuks.fsf@wheatstone.g10code.de>
Message-ID: <87lgfmkir3.fsf@fifthhorseman.net>

On Tue 2018-02-20 16:08:35 +0100, Werner Koch wrote:
> On Mon, 19 Feb 2018 19:45, dkg at fifthhorseman.net said:
>
>> GnuPG is under active development, and it has never had a fully-featured
>> stable API (Application Programming Interface).  What i mean is, there
>> are some capabilities that are only available from the user interface
>> (UI), and are not in the stable API.  GnuPG's UI has been constantly
>
> You probably expected that I need to dissent: Modulo a few bugs there
> has always been a stable API in GnuPG and we have taken great caution to
> not break it.

We're not in disagreement, actually :) I explicitly said that what was
has been lacking was a "*fully-featured* stable API".  I didn't say that
the API was not stable.  But the UI has features that the API does not,
and this results in people using the UI as though it was an API, or
mucking about with the innards of the local storage.  As one example, I
know this because i've been through that when working on early versions
of monkeysphere; i was using bash around GnuPG and yeah, in a few cases
i ended up stuffing a pipeline of "commands" into a gpg invocation
because it was there and seemed to do roughly what i wanted. 

The GnuPG stable API is much more fully-featured today (thank you for
the --quick-* commands!), but that has not been the case historically.
And we're paying the cost for that with legacy applications that have
ossified around wrong assumptions about how to interact with GnuPG :/

> Granted some parts of the API are not easy to use but
> nevertheless, they are stable.  For example the --edit-key interactor
> requires the use a state machine to stay compatible with future versions
> of GnuPG.  This has been remarked over and over in the last ~20 years.

Sorry, but building a state machine in external code to model the
internal state of a tool is not a functional API that we can
realistically expect developers to use.  If a module has state, it needs
to express that state to the user and make the transitions clear and
functional, with comprehensible and easily-handlable error cases.  To
wit:

> Unfortunately some folks reject to read manuals, examples and
> description on proper use and just go ahead and do what seems to work.

Even the folks like me, who read manuals and examples and descriptions
of proper use will eventually just go ahead and do what seems to work :/
The goal of using someone else's code is to *relieve* yourself of
needing to know exactly how that code works.  I know that there are some
people that end up sending patches upstream for every project they
touch.  But most developers don't have time or energy for that, and they
need simple, clear interfaces.

This is why (for example) i've argued in the past for making the return
code for gpgv simple and closely aligned with the boolean tests what
people are likely to want (https://dev.gnupg.org/T1537#100523).  Not
everyone wants to write a parser for a text stream to find out if a
signature is valid.  Some folks just want to know whether a signature is
valid, and are happy to punt on the details.

And even if everyone *did* want to write a parser, how many different
parser implementations do you think would need to be created?  how many
of them would be bug-free?  checking a return code is much harder to get
wrong.

> Actually this is not just a gpg thing: I have seen too many scripts and
> programs which neglect to use LC_ALL=C and break as soon as they are
> running under a different locale.

very true.  it's quite difficult to write robust programs, even when
interfaces are simple and clear and don't have sneaky side-effects or
behavioral changes due to rarely-changed environment variables.  And
even if you test with LC_ALL=C, did you test with LC_ALL=C.UTF-8 ? :P

> To avoid such breakage but keeping friendly to the command line user,
> gpg provide a machine interface (--with-colons, --batch, --command-fd)
> to make automation easy.

yes, these are great things!  thank you for them!

> I can't count how often I wrote that the only defined way to access the
> content of keyrings are my means of the --export and --import commands.  

I know.  I can't count how many times i've said it either.  It's pretty
frustrating!  I think it's aggravated further by the fact that we don't
have a clear rule like "do not touch anything inside ~/.gnupg" -- those
kinds of rules end up riddled with caveats like "well, except for
sshcontrol and gpg.conf" or "oh, you want to do custom subkey
management? let me tell you how to poke around in private-keys-v1.d/" :/

> Please give examples.

did you look at the bug reports i already cited?  Those are definitely
examples of overly-brittle wrappers around GnuPG.  You might also be
interested in Request-Tracker's brittle bindings
(https://bugs.debian.org/832829), or pretty much anything in debian that
explicitly Depends: gnupg1 today.

I'd be game to cc you every time i hold a project's hand through some
tricky problem if you'd like.  I've even succeeded at convincing some
developers to post their problems to this mailing list, or to open
reports on https://dev.gnupg.org, though i've also sometimes seen people
discouraged by responses that come across as "the thing that bothers you
is intended to bother you, deal with it".  Those folks generally don't
come back to ask more questions, and just figure if they can make it
"seem to work" that's good enough. :(

Anyway, here's one concrete example (hinted at above) of a programmatic
gap that is much easier to achieve by mucking around with the internal
state rather than by the programmatic interface:

 * I want to introduce a new signing-capable subkey, and i want to
   distribute it widely, but i don't want to start signing with it just
   yet.  Maybe the subkey needs some time to "burn in", or it needs to
   be reviewed before importing into the debian keyring, or maybe it's a
   new algorithm that i don't think all of my correspondents can verify
   yet.  I'm willing to start using it at some specified future date D,
   but i need it to exist and be distributed *today* so that i can be
   confident that everyone will have a copy of it by the day D rolls
   around.

Here are the options i see:

 * the programmatic approach:
    a) export the secret key to a temporary staging ground
    b) generate the subkey
    c) export the new, augmented secret key to a "future backup" file
    d) delete the secret key entirely (leaving the public part)
    e) re-import the temporarily staged secret key
    f) at date D, re-import the "future backup" file
   
 (note that there's a point in this workflow (between d and e) where i
  actually don't have access to *any* of my secret keys!  what side
  effects will happen there if my key is also in use by other
  tools/processes in the background?  if the transition fail at that
  point (for whatever reason), what happens to me then?)

 (note also that i haven't even tried to write down how i would attempt
  to do this programmatically)

 (note also that if i'm doing this with multiple keys concurrently
  (e.g. today i add a new signing-capable subkey; tomorrow i add an
  authentication-capable subkey), then maybe i've introduced a
  collision.  have i?  and before the "modern" branch of GnuPG, it
  wasn't even possible to merge secret keys, so to be compatible there,
  i'd need to add a step between e and f where i delete the entire
  secret key again.  now we definitely have opportunities for
  collisions!)

 * the "bad" approach (mucking about with the local data store):
   1) generate the subkey, learning its $keygrip
   2) mv ~/.gnupg/private-keys-v1.d/$keygrip.key{,.restore-at-D}
   3) at date D, mv ~/.gnupg/private-keys-v1.d/$keygrip.key{.restore-at-D,}

Guess which approach i'm going to be tempted to take if i write a tool
that attempts to automates sensible secret key management with GnuPG?
And i'm someone who knows better!

Alternately, i might try to use the "disable" subcommand within
--edit-key, but gpg(1) says this controls the "entire key", and it
appears to refer specifically to "encryption", but i'm interested in
sigining.  so that probably isn't right.

What i'd really like is a way to programmatically, privately mark a
secret key as "do not use before date D".  As far as i know, this
interface doesn't exist.  And I'm not asking for it yet because i know
that developer time is limited, and there are so many other outstanding
API improvements (e.g. the gpgv return code example mentioned above)
that i don't want to distract from :/

> And even today, we see hackers who are breaking working integration of
> gpg by replacing the (correct) use of the machine interface by the
> supposed easier to use human interface of gpg.  And then encountering
> problems with newer versions of gpg.  :-(

Right.  they're using the UI as though it was an API, because we have
failed to effectively communicate what the API is actually capable of,
presented in a way that was appealing for developers to adopt :(

>> are not part of an explicit, documented API, the ecosystem apparently
>> *does* try to manipulate them anyway, with all the attendant brittleness
>> that you can imagine.
>
> Right.  That is a bad idea and that is why it took many years to get a
> modern version in widespread use.

yep :/  We're getting there, though! :)

> Library interfaces are as much abused as command line interfaces.  This
> is not really the point.  A library may have the advantage that it
> exposes only a smaller set of interfaces and thus lessens the risk of
> wrong usage.

It's definitely possible to write bad library interfaces, or a library
interface that makes it easy for the developer to make mistakes.  Good
library API design is an art, and not a settled one at that.

I like many of the suggestions made by the libabc developers:

   https://git.kernel.org/cgit/linux/kernel/git/kay/libabc.git/plain/README

I disagree with some of them too :) But they do present a predictable,
orderly approach that lessens the cognitive load on the developer, and
lets the developer "encapsulate" the behavior of the library in their
mind.

One example of a terrible library interface is the classic OpenSSL
interface.  We have many concrete examples in the free software
ecosystem of people who finally "just got it working" in OpenSSL and
then have refused to ever touch that part of the code again, despite the
fact that they actually didn't manage to communicate their actual
programmatic intent to the library properly.

To their credit, the OpenSSL team has made significant improvements in
the interface that they encourage developers to use over the last few
years, and are now in a position to actively deprecate many of their
older mistakes.  It's still going to take us years to rip out the old
cruft from the ecosystem and replace it with "good" use of OpenSSL, or
other TLS implementations, though.  These things have a long shelf life.

The point is, usable programmatic interface design that encourages
stable/sane use (and actually guides developers into doing the right
thing) is a non-trivial task.  It is also potentially exacerbated when
the programmatic use is quite close to other common ways of interacting
with a tool (e.g. a UI).  In that case, developers have a tempting
"quick fix" of just pretending the UI is an API.  Do we really expect
them not to reach for that cookie, when it's just sitting there on the
shelf next to their head?

>> Yet another complementary approach might be to aggressively police the
>> ecosystem by finding other software that deends on GnuPG in any of the
>> aforementioned brittle ways, and either ask those developers to stop
>
>  [ ... ] this is still high on my task list.

Some of us have been doing this kind of work for a few years now, even
before the 2.2 release.  If you'd like to collaborate or strategize
about how we can do that better, i'd be happy to continue to work on it
with you.

Regards,

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

From ben at adversary.org  Wed Feb 21 07:16:10 2018
From: ben at adversary.org (Ben McGinnes)
Date: Wed, 21 Feb 2018 17:16:10 +1100
Subject: How can we utilize latest GPG from RPM repository?
In-Reply-To: <CACNUArDKDhyxFHhA3bq2B+o1p8Yzbo9Xst=60-N6WHpi8wK86Q@mail.gmail.com>
References: <CACNUArDNPfA3f+T+ztp-s2e4A6ewb+vovjHZYXESkf0cz1-OPQ@mail.gmail.com>
 <CACNUArDKDhyxFHhA3bq2B+o1p8Yzbo9Xst=60-N6WHpi8wK86Q@mail.gmail.com>
Message-ID: <20180221061610.qwn3kkhkl6k356lp@adversary.org>

On Sat, Feb 17, 2018 at 05:06:54PM -0600, helices wrote:
> I will probably never understand why wanting to run the most current
> version of gnupg on a plethora of servers is controversial.
> 
> Nevertheless, the two (2) greatest reasons are:
> 
>    1. PCI DSS v3.2
>    2. PCI DSS compliance audits

Ah, now *this* is a pertinent fact that would've helped at the
beginning of the thread and the fact that it wasn't is a clear
demonstration of a tangential point I made further along about getting
people to step back from their drilled in focus so we can identify the
actual needs.

Because these two lines explain *precisely* why you need something like
RHEL or CentOS (certified systems to go with the auditing) *and*
updated crypto.

> Being able to demonstrate that we are using the latest, greatest
> encryption available on every one of our hosts, simplifies that
> portion of the audit equation more than you probably believe.

That's funny ... I'll leave it alone since there have been gaps in my
posting recently.  In future, though, maybe double-check LinkedIn
before making assumptions about everyone here, or anyone.

Some of us have dealt with things a good deal more rigorously
scrutinised than mere PCI-DSS.

> Are there any other questions before I get a direct answer to my
> original subject question?

Not for RPM, not without compiling it yourself, but you said you
didn't want to do that.

As far as I'm aware there's nothing like FreeBSD's port system or pkg
system (or like MacPorts) in addition to rpm with any of the current
distros by default.  They all pick their preferred package manager and
that's their salient feature (along with the current "systemd vs
lol-no-never-in-hell" debate) and point of differentiation.

Although another part of this thread gave Werner an idea for an
addition to 2.2.5 to improve the static-vs-shared libs issue with
GnuPG and the rest of the system.  That might in future improve the
ability for package managers to have independent system libs and user
accessable libs and more recent versions to meet both user and system
requirements more readily.

Precompiled binaries are always going to be architecture dependent or
packed full of extra code to support a broader architecture.  Plus for
auditing purposes you are actually better off using a compiled version
using certified compilers and glibc (which RHEL brings to the
situation).  There's a lot of focus here on Debian and those
distributions it spawned, due to overlapping involvement for some team
members, but even with that hasn't resulted in "official Debian
packages" or whatever.

There are binaries for some system types for which prior releases were
sporadic (early OS X builds, non GPG4Win win32 executables, that sort
of thing), but nothing like you described and specific to a
distribution which is known to remain on much older versions of
everything and backport security fixes to those versions.

In which case, perhaps it is better to simply bite the bullet and
manage a local repo where everything therein meets those requirements.

If it does, I can think of one way to make it pay for itself and it
runs along the lines of subscriber only access to a repo explicitly
intended for PCI-DSS compliance, though it may require more frequent
audits of that part.


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

From ben at adversary.org  Wed Feb 21 07:27:34 2018
From: ben at adversary.org (Ben McGinnes)
Date: Wed, 21 Feb 2018 17:27:34 +1100
Subject: Use the same passphrase for PGP and SSH keys and get prompted
 only once by gpg-agent
In-Reply-To: <87r2pox4t4.fsf@wheatstone.g10code.de>
References: <874lmqs3bn.fsf@gmail.com> <87a7wdxcd7.fsf@wheatstone.g10code.de>
 <87o9ktm1gg.fsf@gmail.com> <87r2pox4t4.fsf@wheatstone.g10code.de>
Message-ID: <20180221062734.4riam3btaqgpkrl5@adversary.org>

On Tue, Feb 13, 2018 at 04:55:19PM +0100, Werner Koch wrote:
> On Tue, 13 Feb 2018 15:03, ambrevar at gmail.com said:
> 
> > Thanks for the detailed answer.  But why not doing it for SSH then?
> 
> I like to see when an ssh key is used the first time.  Note that the
> maximum caching time for ssh keys can be configured independent from the
> caching time of other keys.

Probably wise.

> > Just because it's less common?  Would there be any way to configure this?
> 
> No, there is no way to configure an extra hack to also test a passphrase
> for an ssh key.

Wanna bet?

I thought of one way, but really is a hack and it's predicated on the
standard key access being invoked first.  If SSH always comes first
then it won't work.


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

From dkg at fifthhorseman.net  Wed Feb 21 07:04:18 2018
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 20 Feb 2018 22:04:18 -0800
Subject: Solaris 11 install libgpg-error make install hangs
In-Reply-To: <BLUPR14MB0162A701AF174C1B40E6AAE7DEF20@BLUPR14MB0162.namprd14.prod.outlook.com>
References: <BLUPR14MB0162C469C90CB899D6BAFE95DEF20@BLUPR14MB0162.namprd14.prod.outlook.com>
 <BLUPR14MB0162A701AF174C1B40E6AAE7DEF20@BLUPR14MB0162.namprd14.prod.outlook.com>
Message-ID: <87eflekhel.fsf@fifthhorseman.net>

On Fri 2018-02-09 16:03:01 +0000, Anna Kitces and Seth Fishman wrote:
> Correction. it is in libgpg-error this is happening

You can see logs of an example build on the Debian OS for gpg-error
here:

   https://buildd.debian.org/status/logs.php?arch=&pkg=libgpg-error

Your build is likely to differ in the details (compiler flags, etc), but
perhaps you could identify similar stages and give feedback about where
the build process seems to be hanging?

or, you could post your build log to a pastebin like
https://paste.debian.net/ and point the list to it, so we could compare
it and try to see where it might be hanging.

Please persist!  we'll get it working eventually. :)

Regards,

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

From nbsd4ever at gmail.com  Wed Feb 21 10:37:40 2018
From: nbsd4ever at gmail.com (Henry)
Date: Wed, 21 Feb 2018 18:37:40 +0900
Subject: having trouble checking the signature of a downloaded file
Message-ID: <CAKP-rwGkrJGbp-jx4658MXy23gZM3cqJBnSrspq-FeHLH=jLeA@mail.gmail.com>

I downloaded a tarball ***6.4.tar.gz, it's signature file
***6.4.tar.gz.sig, and the author's public key ******.pgp from a
well-known site.

I imported the public key: `gpg --import ******.pgp`.
For some reason, two keys were "skipped":
   gpg: key 0C0B590E80CA15A7: 2 signatures not checked due to missing keys
   gpg: key 0C0B590E80CA15A7: "Author's Name <author at xxxxxx.org>
   gpg: Total number processed: 3
   gpg:     skipped PGP-2 keys: 2
   gpg:              unchanged: 1

I tried to verify the downloaded file, but the check failed:
`gpg --verify ***6.4.tar.gz.sig ***6.4.tar.gz`
   gpg: Signature made Tue May  4 23:03:11 2004 JST
   gpg:                using RSA key DC80F2A6D5327CB9
   gpg: Can't check signature: No public key

This is the first time for this to happen, so I have no idea what I
might be doing
wrong.  Any help or suggestions much appreciated.  TIA

Henry


From wk at gnupg.org  Wed Feb 21 09:39:03 2018
From: wk at gnupg.org (Werner Koch)
Date: Wed, 21 Feb 2018 09:39:03 +0100
Subject: Why Operating Systems don't always upgrade GnuPG
In-Reply-To: <87woz7pi67.wl-neal@walfield.org> (Neal H. Walfield's message of
 "Tue, 20 Feb 2018 20:36:32 +0100")
References: <CACNUArDNPfA3f+T+ztp-s2e4A6ewb+vovjHZYXESkf0cz1-OPQ@mail.gmail.com>
 <CACNUArDKDhyxFHhA3bq2B+o1p8Yzbo9Xst=60-N6WHpi8wK86Q@mail.gmail.com>
 <87606slswv.fsf@fifthhorseman.net>
 <874lmbpuks.fsf@wheatstone.g10code.de>
 <87woz7pi67.wl-neal@walfield.org>
Message-ID: <87k1v6ohy0.fsf@wheatstone.g10code.de>

On Tue, 20 Feb 2018 20:36, neal at walfield.org said:

> "uncool".  I left because we (Werner and I) could not work well
> together.  This is the same reason that Justus, Kai and Marcus left.

Okay, you raised it and now my Lavamat wants to reply on this: Secret
negotiations with other companies, promising them things without
consulting with me, working on your own schedule, throwing in large
blobs of code after silently working on them for months, not adhering to
milestones, ignoring requests to write documentation, leaving almost all
of the project work to me, spending half a person year on preparing a
campaign, kind of blackmailing me to re-write GnuPG in Rust, refusing to
prepare the agreed-upon training material.

My take away of that story is that not all hackers are able value the
liberties granted to them.  Too bad.


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/20180221/0726e783/attachment.sig>

From kristian.fiskerstrand at sumptuouscapital.com  Wed Feb 21 10:48:12 2018
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Wed, 21 Feb 2018 10:48:12 +0100
Subject: having trouble checking the signature of a downloaded file
In-Reply-To: <CAKP-rwGkrJGbp-jx4658MXy23gZM3cqJBnSrspq-FeHLH=jLeA@mail.gmail.com>
References: <CAKP-rwGkrJGbp-jx4658MXy23gZM3cqJBnSrspq-FeHLH=jLeA@mail.gmail.com>
Message-ID: <261fa63d-430f-d32c-05c4-7d8936161577@sumptuouscapital.com>

On 02/21/2018 10:37 AM, Henry wrote:
> I downloaded a tarball ***6.4.tar.gz, it's signature file
> ***6.4.tar.gz.sig, and the author's public key ******.pgp from a
> well-known site.
> 
> I imported the public key: `gpg --import ******.pgp`.
> For some reason, two keys were "skipped":
>    gpg: key 0C0B590E80CA15A7: 2 signatures not checked due to missing keys
>    gpg: key 0C0B590E80CA15A7: "Author's Name <author at xxxxxx.org>
>    gpg: Total number processed: 3
>    gpg:     skipped PGP-2 keys: 2
              ^^^^^^^^^^^^^^^^^^^^^
	      note this and see below

>    gpg:              unchanged: 1
> 
> I tried to verify the downloaded file, but the check failed:
> `gpg --verify ***6.4.tar.gz.sig ***6.4.tar.gz`
>    gpg: Signature made Tue May  4 23:03:11 2004 JST
>    gpg:                using RSA key DC80F2A6D5327CB9
>    gpg: Can't check signature: No public key
> 

The above RSA key is in v3 format which is not supported in GnuPG >=2.1
for security reasons, hence not imported, and hence the output you see.

> This is the first time for this to happen, so I have no idea what I
> might be doing
> wrong.  Any help or suggestions much appreciated.  TIA

The author should sign the package using a more modern and secure keyblock.

-- 
----------------------------
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
----------------------------
Aut disce aut discede
Either learn or leave

-------------- 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/20180221/ff820143/attachment.sig>

From peter at digitalbrains.com  Wed Feb 21 11:53:56 2018
From: peter at digitalbrains.com (Peter Lebbing)
Date: Wed, 21 Feb 2018 11:53:56 +0100
Subject: having trouble checking the signature of a downloaded file
In-Reply-To: <261fa63d-430f-d32c-05c4-7d8936161577@sumptuouscapital.com>
References: <CAKP-rwGkrJGbp-jx4658MXy23gZM3cqJBnSrspq-FeHLH=jLeA@mail.gmail.com>
 <261fa63d-430f-d32c-05c4-7d8936161577@sumptuouscapital.com>
Message-ID: <cf9aaf43-74d2-f9c4-b5d4-80119871a8f9@digitalbrains.com>

On 21/02/18 10:48, Kristian Fiskerstrand wrote:
>>    gpg: Signature made Tue May  4 23:03:11 2004 JST
> [...]
> 
> The author should sign the package using a more modern and secure keyblock.

Note that not the key, but the /signature/ is made 14 years ago. So
we're talking about verifying the integrity of a really old file. The
author might not be available anymore or willing to expend any effort.

GnuPG 1.4 is kept around to verify such old files. So perhaps the OP
could use GnuPG 1.4 to verify the file; without further information
about the system he is using it is hard to explain how exactly to do
this. However, I get the feeling his OS is NetBSD :-). So if somebody
knows how GnuPG is installed there... (I don't)

This all comes with a major caveat. The reason you can't do it with
modern GnuPG is that the security of PGP-2 keys and signatures is no
longer at a sufficient level. So while it gives some confidence when the
signature verifies positively, a well-equipped attacker might have faked
it anyway!

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/20180221/f66c10a0/attachment.sig>

From peter at digitalbrains.com  Wed Feb 21 12:07:48 2018
From: peter at digitalbrains.com (Peter Lebbing)
Date: Wed, 21 Feb 2018 12:07:48 +0100
Subject: having trouble checking the signature of a downloaded file
In-Reply-To: <cf9aaf43-74d2-f9c4-b5d4-80119871a8f9@digitalbrains.com>
References: <CAKP-rwGkrJGbp-jx4658MXy23gZM3cqJBnSrspq-FeHLH=jLeA@mail.gmail.com>
 <261fa63d-430f-d32c-05c4-7d8936161577@sumptuouscapital.com>
 <cf9aaf43-74d2-f9c4-b5d4-80119871a8f9@digitalbrains.com>
Message-ID: <55b6626e-1c6f-42f0-3b0b-02baac0c0f85@digitalbrains.com>

On 21/02/18 11:53, Peter Lebbing wrote:
> The
> author might not be available anymore or willing to expend any effort.

(Or the author might not have a more authentic copy of the file anymore
either. This is not the reason I'm self-replying though).

> This all comes with a major caveat.

Make that two. The OP writes:

On 21/02/18 10:37, Henry wrote:
> I downloaded a tarball ***6.4.tar.gz, it's signature file
> ***6.4.tar.gz.sig, and the author's public key ******.pgp from a
> well-known site.

This sounds like there is no more assurance that the downloaded key is
authentic than that the downloaded file is authentic. When to decide
that a key is authentic is one of the more difficult problems of
practical cryptography use. Some people take confidence from downloading
identical copies of the key from multiple HTTPS websites. There are
still ways for an attacker to serve you the wrong one each time, but
it's better than nothing... The best is direct personal contact with the
owner of the key, but it seems a long shot.

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/20180221/44f20522/attachment-0001.sig>

From kristian.fiskerstrand at sumptuouscapital.com  Wed Feb 21 12:56:03 2018
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Wed, 21 Feb 2018 12:56:03 +0100
Subject: having trouble checking the signature of a downloaded file
In-Reply-To: <cf9aaf43-74d2-f9c4-b5d4-80119871a8f9@digitalbrains.com>
References: <CAKP-rwGkrJGbp-jx4658MXy23gZM3cqJBnSrspq-FeHLH=jLeA@mail.gmail.com>
 <261fa63d-430f-d32c-05c4-7d8936161577@sumptuouscapital.com>
 <cf9aaf43-74d2-f9c4-b5d4-80119871a8f9@digitalbrains.com>
Message-ID: <7d94e7e8-8816-e429-72d0-3df4183f910d@sumptuouscapital.com>

On 02/21/2018 11:53 AM, Peter Lebbing wrote:
> On 21/02/18 10:48, Kristian Fiskerstrand wrote:
>>>    gpg: Signature made Tue May  4 23:03:11 2004 JST
>> [...]
>>
>> The author should sign the package using a more modern and secure keyblock.
> Note that not the key, but the /signature/ is made 14 years ago. So
> we're talking about verifying the integrity of a really old file. The
> author might not be available anymore or willing to expend any effort.

Touch? :) Indeed, didn't notice it was an old file/signature , then
gnupg 1.4 is the recommended official suggestion presuming established
validity of key material etc etc.

-- 
----------------------------
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
----------------------------
Dura necessitas
Necessity is harsh

-------------- 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/20180221/97631710/attachment.sig>

From konstantin at linuxfoundation.org  Wed Feb 21 15:59:01 2018
From: konstantin at linuxfoundation.org (Konstantin Ryabitsev)
Date: Wed, 21 Feb 2018 09:59:01 -0500
Subject: wotmate: simple grapher for your keyring
Message-ID: <3332dd0d-f131-223b-82e4-3f84e4a0f706@linuxfoundation.org>

Hi, all:

I've been maintaining the kernel.org web of trust for the past 5+ years,
and I wrote a number of tools to help me visualize trust paths between
fully trusted keys and those belonging to newer developers.

I finally got a chance to clean up the code, and I hope it's useful to
others:

https://github.com/mricon/wotmate

If you think this is very similar to the PGP Pathfinder tool on
https://pgp.cs.uu.nl, then you are right, but there is an important
distinction. Wotmate does not require that a key is in the "strong set"
before you can track paths to it, and you also don't have to wait for
days before new signatures are reflected in the wotsap file.

Example usage (assuming you have Linus Torvalds' key in your keyring):

./make-sqlitedb.py
./graph-paths.py torvalds
eog graph.png

Best,
-- 
Konstantin Ryabitsev
Director, IT Infrastructure Security
The Linux Foundation

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

From tlikonen at iki.fi  Wed Feb 21 17:22:19 2018
From: tlikonen at iki.fi (Teemu Likonen)
Date: Wed, 21 Feb 2018 18:22:19 +0200
Subject: Why Operating Systems don't always upgrade GnuPG
In-Reply-To: <87lgfmkir3.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message
 of "Tue, 20 Feb 2018 21:35:12 -0800")
References: <CACNUArDNPfA3f+T+ztp-s2e4A6ewb+vovjHZYXESkf0cz1-OPQ@mail.gmail.com>
 <CACNUArDKDhyxFHhA3bq2B+o1p8Yzbo9Xst=60-N6WHpi8wK86Q@mail.gmail.com>
 <87606slswv.fsf@fifthhorseman.net>
 <874lmbpuks.fsf@wheatstone.g10code.de>
 <87lgfmkir3.fsf@fifthhorseman.net>
Message-ID: <87woz671ok.fsf@iki.fi>

Daniel Kahn Gillmor [2018-02-20 21:35:12-08] wrote:

> Anyway, here's one concrete example (hinted at above) of a
> programmatic gap that is much easier to achieve by mucking around with
> the internal state rather than by the programmatic interface:
>
>  * I want to introduce a new signing-capable subkey, and i want to
>    distribute it widely, but i don't want to start signing with it just
>    yet.

It seems to me that there is an easy gpg.conf solution:

    default-key FINGERPRINT!

See the ! character which forces exactly that (sub)key for signing. Use
that option to select your old signing (sub)key.

-- 
/// 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/20180221/534bfc4b/attachment.sig>

From dank at kegel.com  Wed Feb 21 16:36:08 2018
From: dank at kegel.com (Dan Kegel)
Date: Wed, 21 Feb 2018 07:36:08 -0800
Subject: How can we utilize latest GPG from RPM repository?
In-Reply-To: <20180221061610.qwn3kkhkl6k356lp@adversary.org>
References: <CACNUArDNPfA3f+T+ztp-s2e4A6ewb+vovjHZYXESkf0cz1-OPQ@mail.gmail.com>
 <CACNUArDKDhyxFHhA3bq2B+o1p8Yzbo9Xst=60-N6WHpi8wK86Q@mail.gmail.com>
 <20180221061610.qwn3kkhkl6k356lp@adversary.org>
Message-ID: <CAPF-yOYHfV3WORm-79mMJo-r4=qXicbphH_GhUHrcW_kjtB6nQ@mail.gmail.com>

On Tue, Feb 20, 2018 at 10:16 PM, Ben McGinnes <ben at adversary.org> wrote:
> On Sat, Feb 17, 2018 at 05:06:54PM -0600, helices wrote:
>> I will probably never understand why wanting to run the most current
>> version of gnupg on a plethora of servers is controversial.
>>
>> Nevertheless, the two (2) greatest reasons are:
>>
>>    1. PCI DSS v3.2
>>    2. PCI DSS compliance audits
>
> Ah, now *this* is a pertinent fact that would've helped at the
> beginning of the thread and the fact that it wasn't is a clear
> demonstration of a tangential point I made further along about getting
> people to step back from their drilled in focus so we can identify the
> actual needs.
>
> Because these two lines explain *precisely* why you need something like
> RHEL or CentOS (certified systems to go with the auditing) *and*
> updated crypto.

And when you're on those certified, curated systems, you have
access to tools like
https://www.open-scap.org/resources/documentation/make-a-rhel7-server-compliant-with-pci-dss/
to help make sure you're in compliance, I think.

I suspect that kind of approach would make passing audits a lot easier
than building the latest gnupg release yourself...
and is less likely to break things.
- Dan


From peter at digitalbrains.com  Wed Feb 21 17:55:13 2018
From: peter at digitalbrains.com (Peter Lebbing)
Date: Wed, 21 Feb 2018 17:55:13 +0100
Subject: Why Operating Systems don't always upgrade GnuPG
In-Reply-To: <87woz671ok.fsf@iki.fi>
References: <CACNUArDNPfA3f+T+ztp-s2e4A6ewb+vovjHZYXESkf0cz1-OPQ@mail.gmail.com>
 <CACNUArDKDhyxFHhA3bq2B+o1p8Yzbo9Xst=60-N6WHpi8wK86Q@mail.gmail.com>
 <87606slswv.fsf@fifthhorseman.net> <874lmbpuks.fsf@wheatstone.g10code.de>
 <87lgfmkir3.fsf@fifthhorseman.net> <87woz671ok.fsf@iki.fi>
Message-ID: <9c431e28-381c-3ddc-34f3-06b69e1888f8@digitalbrains.com>

On 21/02/18 17:22, Teemu Likonen wrote:
>     default-key FINGERPRINT!

That would help for command-line usage for a user with only one private
key. But anything else might not use the default key.

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/20180221/fe5722d3/attachment.sig>

From ben at adversary.org  Thu Feb 22 07:03:51 2018
From: ben at adversary.org (Ben McGinnes)
Date: Thu, 22 Feb 2018 17:03:51 +1100
Subject: wotmate: simple grapher for your keyring
In-Reply-To: <3332dd0d-f131-223b-82e4-3f84e4a0f706@linuxfoundation.org>
References: <3332dd0d-f131-223b-82e4-3f84e4a0f706@linuxfoundation.org>
Message-ID: <20180222060351.rrlywcx247va4yyt@adversary.org>

On Wed, Feb 21, 2018 at 09:59:01AM -0500, Konstantin Ryabitsev wrote:
> Hi, all:
> 
> I've been maintaining the kernel.org web of trust for the past 5+ years,
> and I wrote a number of tools to help me visualize trust paths between
> fully trusted keys and those belonging to newer developers.
> 
> I finally got a chance to clean up the code, and I hope it's useful to
> others:
> 
> https://github.com/mricon/wotmate

Oh, that's very cute.  :)

Also nice to see it's py3 and so I've already forked it.  At some
point in the not too distant future I'll tweak it to try for gpgme
first and import all the keys that way, then revert back to your code
once the db is built from that.  At the very least it'll make for a
nice demonstration to compare the CLI with colons vs API methods of
doing the same thing (key counting doesn't really achieve that too
well since it's about three lines of code).


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

From frase at frase.id.au  Thu Feb 22 05:33:05 2018
From: frase at frase.id.au (Fraser Tweedale)
Date: Thu, 22 Feb 2018 14:33:05 +1000
Subject: wotmate: simple grapher for your keyring
In-Reply-To: <3332dd0d-f131-223b-82e4-3f84e4a0f706@linuxfoundation.org>
References: <3332dd0d-f131-223b-82e4-3f84e4a0f706@linuxfoundation.org>
Message-ID: <20180222043304.GS1365@bacardi.hollandpark.frase.id.au>

u wot m8

http://knowyourmeme.com/memes/u-wot-m8

Nice tool; thanks for sharing!

Cheers,
Fraser

On Wed, Feb 21, 2018 at 09:59:01AM -0500, Konstantin Ryabitsev wrote:
> Hi, all:
> 
> I've been maintaining the kernel.org web of trust for the past 5+ years,
> and I wrote a number of tools to help me visualize trust paths between
> fully trusted keys and those belonging to newer developers.
> 
> I finally got a chance to clean up the code, and I hope it's useful to
> others:
> 
> https://github.com/mricon/wotmate
> 
> If you think this is very similar to the PGP Pathfinder tool on
> https://pgp.cs.uu.nl, then you are right, but there is an important
> distinction. Wotmate does not require that a key is in the "strong set"
> before you can track paths to it, and you also don't have to wait for
> days before new signatures are reflected in the wotsap file.
> 
> Example usage (assuming you have Linus Torvalds' key in your keyring):
> 
> ./make-sqlitedb.py
> ./graph-paths.py torvalds
> eog graph.png
> 
> Best,
> -- 
> Konstantin Ryabitsev
> Director, IT Infrastructure Security
> The Linux Foundation
> 




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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180222/91783a7c/attachment-0001.sig>

From ben at adversary.org  Thu Feb 22 07:22:45 2018
From: ben at adversary.org (Ben McGinnes)
Date: Thu, 22 Feb 2018 17:22:45 +1100
Subject: How can we utilize latest GPG from RPM repository?
In-Reply-To: <CAPF-yOYHfV3WORm-79mMJo-r4=qXicbphH_GhUHrcW_kjtB6nQ@mail.gmail.com>
References: <CACNUArDNPfA3f+T+ztp-s2e4A6ewb+vovjHZYXESkf0cz1-OPQ@mail.gmail.com>
 <CACNUArDKDhyxFHhA3bq2B+o1p8Yzbo9Xst=60-N6WHpi8wK86Q@mail.gmail.com>
 <20180221061610.qwn3kkhkl6k356lp@adversary.org>
 <CAPF-yOYHfV3WORm-79mMJo-r4=qXicbphH_GhUHrcW_kjtB6nQ@mail.gmail.com>
Message-ID: <20180222062245.dn5ecl3vmii5y67k@adversary.org>

On Wed, Feb 21, 2018 at 07:36:08AM -0800, Dan Kegel wrote:
> On Tue, Feb 20, 2018 at 10:16 PM, Ben McGinnes <ben at adversary.org> wrote:
>>
>> Because these two lines explain *precisely* why you need something
>> like RHEL or CentOS (certified systems to go with the auditing)
>> *and* updated crypto.
> 
> And when you're on those certified, curated systems, you have
> access to tools like
> https://www.open-scap.org/resources/documentation/make-a-rhel7-server-compliant-with-pci-dss/
> to help make sure you're in compliance, I think.
> 
> I suspect that kind of approach would make passing audits a lot
> easier than building the latest gnupg release yourself...
> and is less likely to break things.

In all likelihood, yes ... however open-scap.org is a RedHat service
and most likely only supplied to RHEL customers seeking PCI-DSS
compliance along with direct support via their service contract.

If, however, this particular case actually deals with CentOS systems
and not RHEL, then the OP has elected to forego that type of
professional service contract from the vendor in order to do it
themselves.

Which brings us either back to this thread, or a business decision at
their end regarding whether or not bring their systems back to RHEL
(it requires changing two files, IIRC, assuming they haven't massively
modified things) and paying RedHat whatever it takes to get the job
done.  I cannot predict which they will choose, nor am I willing to
make a recommendation solely on what's been presented here.

Still, the OP wanted options and now they've been provided.  :)


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

From bereska at hotmail.com  Thu Feb 22 11:04:34 2018
From: bereska at hotmail.com (Dmitry Gudkov)
Date: Thu, 22 Feb 2018 10:04:34 +0000
Subject: enigmail with pgp 2.2.4
In-Reply-To: <20180222043304.GS1365@bacardi.hollandpark.frase.id.au>
References: <3332dd0d-f131-223b-82e4-3f84e4a0f706@linuxfoundation.org>
 <20180222043304.GS1365@bacardi.hollandpark.frase.id.au>
Message-ID: <DM5PR01MB22364C6DFEA7F5980D2A264BA6CD0@DM5PR01MB2236.prod.exchangelabs.com>

dear all,

when trying to use enigmail with latest gpg 2.2.4 I get the following error:

Error - key extraction command failed
/usr/bin/gpg2 --charset utf-8 --display-charset utf-8 --use-agent
--batch --no-tty --status-fd 2 -a --export 0xFB417E72
gpg: skipped packet of type 12 in keybox
gpg: skipped packet of type 12 in keybox
gpg: skipped packet of type 12 in keybox
gpg: skipped packet of type 12 in keybox

any help is appreciated

thank you


On 22.02.2018 07:33, Fraser Tweedale wrote:
> u wot m8
>
> https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fknowyourmeme.com%2Fmemes%2Fu-wot-m8&data=02%7C01%7C%7C6e6006dedf1d43931dcb08d579babd99%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636548765303114275&sdata=%2FHaCzuQYPCD3rYFtY4Yf7%2FQYf9zVDwMnvecHLMQjS20%3D&reserved=0
>
> Nice tool; thanks for sharing!
>
> Cheers,
> Fraser
>
> On Wed, Feb 21, 2018 at 09:59:01AM -0500, Konstantin Ryabitsev wrote:
>> Hi, all:
>>
>> I've been maintaining the kernel.org web of trust for the past 5+ years,
>> and I wrote a number of tools to help me visualize trust paths between
>> fully trusted keys and those belonging to newer developers.
>>
>> I finally got a chance to clean up the code, and I hope it's useful to
>> others:
>>
>> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmricon%2Fwotmate&data=02%7C01%7C%7C6e6006dedf1d43931dcb08d579babd99%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636548765303114275&sdata=tWao8vfy5bJfoB40KWD3js4pJnprbIANN4mtimfuEz4%3D&reserved=0
>>
>> If you think this is very similar to the PGP Pathfinder tool on
>> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpgp.cs.uu.nl&data=02%7C01%7C%7C6e6006dedf1d43931dcb08d579babd99%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636548765303114275&sdata=S1AnXI5SbhU9HJOr2g4bgfSM8XY%2BazoDX2DkY7gnCRo%3D&reserved=0, then you are right, but there is an important
>> distinction. Wotmate does not require that a key is in the "strong set"
>> before you can track paths to it, and you also don't have to wait for
>> days before new signatures are reflected in the wotsap file.
>>
>> Example usage (assuming you have Linus Torvalds' key in your keyring):
>>
>> ./make-sqlitedb.py
>> ./graph-paths.py torvalds
>> eog graph.png
>>
>> Best,
>> -- 
>> Konstantin Ryabitsev
>> Director, IT Infrastructure Security
>> The Linux Foundation
>>
>
>
>
>> _______________________________________________
>> Gnupg-users mailing list
>> Gnupg-users at gnupg.org
>> https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.gnupg.org%2Fmailman%2Flistinfo%2Fgnupg-users&data=02%7C01%7C%7C6e6006dedf1d43931dcb08d579babd99%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636548765303114275&sdata=DrCK2mXWv4ME77UQava0%2BKM%2BEPVKm1KUUMx1WmwFtwI%3D&reserved=0
>
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.gnupg.org%2Fmailman%2Flistinfo%2Fgnupg-users&data=02%7C01%7C%7C6e6006dedf1d43931dcb08d579babd99%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636548765303114275&sdata=DrCK2mXWv4ME77UQava0%2BKM%2BEPVKm1KUUMx1WmwFtwI%3D&reserved=0

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180222/c53ac734/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180222/c53ac734/attachment.sig>

From wk at gnupg.org  Thu Feb 22 14:19:14 2018
From: wk at gnupg.org (Werner Koch)
Date: Thu, 22 Feb 2018 14:19:14 +0100
Subject: enigmail with pgp 2.2.4
In-Reply-To: <DM5PR01MB22364C6DFEA7F5980D2A264BA6CD0@DM5PR01MB2236.prod.exchangelabs.com>
 (Dmitry Gudkov's message of "Thu, 22 Feb 2018 10:04:34 +0000")
References: <3332dd0d-f131-223b-82e4-3f84e4a0f706@linuxfoundation.org>
 <20180222043304.GS1365@bacardi.hollandpark.frase.id.au>
 <DM5PR01MB22364C6DFEA7F5980D2A264BA6CD0@DM5PR01MB2236.prod.exchangelabs.com>
Message-ID: <87tvu988ml.fsf@wheatstone.g10code.de>

Hi!

On Thu, 22 Feb 2018 11:04, bereska at hotmail.com said:

> gpg: skipped packet of type 12 in keybox

Are you sure this if gpg 2.2.4 ?  The error looks more like this is a
gpg version < 2.1.20.

Type 12 are ring trust packets which are used internally by gpg.  The
code which shows this error is 

      /* Filter allowed packets.  */
      switch (pkt->pkttype)
        {
        case PKT_PUBLIC_KEY:
        case PKT_PUBLIC_SUBKEY:
        case PKT_SECRET_KEY:
        case PKT_SECRET_SUBKEY:
        case PKT_USER_ID:
        case PKT_ATTRIBUTE:
        case PKT_SIGNATURE:
===>    case PKT_RING_TRUST:
          break; /* Allowed per RFC.  */

        default:
          /* Note that can't allow ring trust packets here and some of
             the other GPG specific packets don't make sense either.  */
          log_error ("skipped packet of type %d in keybox\n",
                     (int)pkt->pkttype);
          free_packet(pkt, &parsectx);
          init_packet(pkt);
          continue;
        }

Thus a ring trust packet can't show this error.  Note that the comment
in the default case is misleading.


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/20180222/32c25fff/attachment.sig>

From gpg at mdsresource.net  Thu Feb 22 15:18:37 2018
From: gpg at mdsresource.net (helices)
Date: Thu, 22 Feb 2018 08:18:37 -0600
Subject: How can we utilize latest GPG from RPM repository?
In-Reply-To: <20180222062245.dn5ecl3vmii5y67k@adversary.org>
References: <CACNUArDNPfA3f+T+ztp-s2e4A6ewb+vovjHZYXESkf0cz1-OPQ@mail.gmail.com>
 <CACNUArDKDhyxFHhA3bq2B+o1p8Yzbo9Xst=60-N6WHpi8wK86Q@mail.gmail.com>
 <20180221061610.qwn3kkhkl6k356lp@adversary.org>
 <CAPF-yOYHfV3WORm-79mMJo-r4=qXicbphH_GhUHrcW_kjtB6nQ@mail.gmail.com>
 <20180222062245.dn5ecl3vmii5y67k@adversary.org>
Message-ID: <CACNUArB6YxJd+XTszoxJQrNPxQ4hMN3BCdQmwpzOSXLJ2nPDOw@mail.gmail.com>

Let's cut through these ill-informed suppositions once and for all: If host
compliance was our problem, I would not have posted here at all.

Also, nowhere in this thread have I stated any inability to compile myself.
Having been doing such for 40+ years, that is not our problem either.

Defending processes and systems to egregiously non-technical auditors is a
challenge that grows year by year. If you have not qualified for PCI DSS
Level 1, then you probably have only a cursory understanding of this
situation. Based on previous questions I've posted here in last several
years, it's clear to me that none of the experts here have such experience.

Sometimes, a question is just a question. Overthinking the environment in
which that question was asked adds nothing to the discussion. Now that my
question has been directly answered - thank you, Ben - and indirectly
answered - thank you, to those who did not answer directly - we can move
forward in my enterprise architecture endeavor.

Thank you, Daniel, for describing the complexity of the gnupg problem.

Our new environment will continue with gnupg v2.0.22, because that is the
security level supported by stable and secure Linux operating systems.
Please, do not debate me on this. Yes, we could do otherwise, but that will
incur PCI DSS v3.2 challenges unnecessary to us.

Thank you.

~ helices




On Thu, Feb 22, 2018 at 12:22 AM, Ben McGinnes <ben at adversary.org> wrote:

> On Wed, Feb 21, 2018 at 07:36:08AM -0800, Dan Kegel wrote:
> > On Tue, Feb 20, 2018 at 10:16 PM, Ben McGinnes <ben at adversary.org>
> wrote:
> >>
> >> Because these two lines explain *precisely* why you need something
> >> like RHEL or CentOS (certified systems to go with the auditing)
> >> *and* updated crypto.
> >
> > And when you're on those certified, curated systems, you have
> > access to tools like
> > https://www.open-scap.org/resources/documentation/make-
> a-rhel7-server-compliant-with-pci-dss/
> > to help make sure you're in compliance, I think.
> >
> > I suspect that kind of approach would make passing audits a lot
> > easier than building the latest gnupg release yourself...
> > and is less likely to break things.
>
> In all likelihood, yes ... however open-scap.org is a RedHat service
> and most likely only supplied to RHEL customers seeking PCI-DSS
> compliance along with direct support via their service contract.
>
> If, however, this particular case actually deals with CentOS systems
> and not RHEL, then the OP has elected to forego that type of
> professional service contract from the vendor in order to do it
> themselves.
>
> Which brings us either back to this thread, or a business decision at
> their end regarding whether or not bring their systems back to RHEL
> (it requires changing two files, IIRC, assuming they haven't massively
> modified things) and paying RedHat whatever it takes to get the job
> done.  I cannot predict which they will choose, nor am I willing to
> make a recommendation solely on what's been presented here.
>
> Still, the OP wanted options and now they've been provided.  :)
>
>
> Regards,
> Ben
>
> _______________________________________________
> 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/20180222/f2d9262d/attachment-0001.html>

From peter at digitalbrains.com  Thu Feb 22 16:05:57 2018
From: peter at digitalbrains.com (Peter Lebbing)
Date: Thu, 22 Feb 2018 16:05:57 +0100
Subject: Being civil costs you nothing (was: How can we utilize latest GPG
 from RPM repository?)
In-Reply-To: <CACNUArB6YxJd+XTszoxJQrNPxQ4hMN3BCdQmwpzOSXLJ2nPDOw@mail.gmail.com>
References: <CACNUArDNPfA3f+T+ztp-s2e4A6ewb+vovjHZYXESkf0cz1-OPQ@mail.gmail.com>
 <CACNUArDKDhyxFHhA3bq2B+o1p8Yzbo9Xst=60-N6WHpi8wK86Q@mail.gmail.com>
 <20180221061610.qwn3kkhkl6k356lp@adversary.org>
 <CAPF-yOYHfV3WORm-79mMJo-r4=qXicbphH_GhUHrcW_kjtB6nQ@mail.gmail.com>
 <20180222062245.dn5ecl3vmii5y67k@adversary.org>
 <CACNUArB6YxJd+XTszoxJQrNPxQ4hMN3BCdQmwpzOSXLJ2nPDOw@mail.gmail.com>
Message-ID: <2401862d-1a00-39c5-79c4-a26851173942@digitalbrains.com>

On 22/02/18 15:18, helices wrote:
> Let's cut through these ill-informed suppositions once and for all
You are rapidly squandering good will here. Your hostile tone will not
motivate anyone to help you any further. You are asking people to spend
their spare time on your issues, you should not deride them. None of the
posters here spent their spare time on your questions without the intent
to help you. You are insulting them.

> Defending processes and systems to egregiously non-technical auditors is
> a challenge that grows year by year. If you have not qualified for PCI
> DSS Level 1, then you probably have only a cursory understanding of this
> situation. Based on previous questions I've posted here in last several
> years, it's clear to me that none of the experts here have such experience.

I almost get the impression half of the mails don't come through,
because I just read Ben McGinnes state the complete opposite.

Also, and more importantly, if you're so worried about the competences
of the people you ask questions, you should hire experts, not post on a
community mailing list.

> Sometimes, a question is just a question.

And sometimes it is an insult thinly disguised as one.

> Our new environment will continue with gnupg v2.0.22, because that is
> the security level supported by stable and secure Linux operating
> systems. Please, do not debate me on this.

I agree: I don't wish to debate you on this. I /will/ state my dissent
with the statement before. I consider Debian stretch/stable a "stable
and secure Linux operating system", and that carries GnuPG v2.1.18 (with
backported fixes of course).

Goodbye,

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/20180222/964ed381/attachment.sig>

From bereska at hotmail.com  Thu Feb 22 15:21:53 2018
From: bereska at hotmail.com (Dmitry Gudkov)
Date: Thu, 22 Feb 2018 14:21:53 +0000
Subject: enigmail with pgp 2.2.4
In-Reply-To: <87tvu988ml.fsf@wheatstone.g10code.de>
References: <3332dd0d-f131-223b-82e4-3f84e4a0f706@linuxfoundation.org>
 <20180222043304.GS1365@bacardi.hollandpark.frase.id.au>
 <DM5PR01MB22364C6DFEA7F5980D2A264BA6CD0@DM5PR01MB2236.prod.exchangelabs.com>
 <87tvu988ml.fsf@wheatstone.g10code.de>
Message-ID: <DM5PR01MB223696A8038DB561ECECC86CA6CD0@DM5PR01MB2236.prod.exchangelabs.com>

Hi Werner,

yes, i am.

*I just manually compiled it on the fresh install of ubuntu 16.04 per
the below script:*

cd ~/Downloads
version=gnupg-2.2.4
wget https://gnupg.org/ftp/gcrypt/gnupg/$version.tar.bz2
wget https://gnupg.org/ftp/gcrypt/gnupg/$version.tar.bz2.sig
tar xf $version.tar.bz2
cd $version
sudo apt-get update
sudo apt-get install -y libldap2-dev
sudo apt-get install -y gtk+-2
sudo apt-get install -y rng-tools
sudo apt-get install -y libbz2-dev
sudo apt-get install -y zlib1g-dev
sudo apt-get install -y libgmp-dev
sudo apt-get install -y nettle-dev
sudo apt-get install -y libgnutls28-dev
sudo apt-get install -y libsqlite3-dev
sudo apt-get install -y adns-tools
sudo apt-get install -y libreadline-dev
sudo apt-get install -y qtbase5-dev
sudo apt-get install -y pinentry-gtk2
sudo apt-get install -y pcscd scdaemon
sudo make -f build-aux/speedo.mk INSTALL_PREFIX=/usr/local
speedo_pkg_gnupg_configure='--enable-g13 --enable-wks-tools' native
sudo ldconfig

# use nano to create a configuration file: nano ~/.gnupg/gpg-agent.conf
# add the line: pinentry-program /usr/bin/pinentry-gtk-2
# chmod 600 ~/.gnupg/gpg-agent.conf

*the result is the following:*

bereska at bereska-VPCZ21AGX:~/.gnupg$ gpg --version
gpg (GnuPG) 2.2.4
libgcrypt 1.8.2
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/bereska/.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

*then I imported my existing keys for the other machine*

*and all works fine in terminal*

however after installing Enigmail I get this error when I try to attach
my public key to the message

thank you for your time to this matter

Dmitry




On 22.02.2018 16:19, Werner Koch wrote:
> Hi!
>
> On Thu, 22 Feb 2018 11:04, bereska at hotmail.com said:
>
>> gpg: skipped packet of type 12 in keybox
> Are you sure this if gpg 2.2.4 ?  The error looks more like this is a
> gpg version < 2.1.20.
>
> Type 12 are ring trust packets which are used internally by gpg.  The
> code which shows this error is 
>
>       /* Filter allowed packets.  */
>       switch (pkt->pkttype)
>         {
>         case PKT_PUBLIC_KEY:
>         case PKT_PUBLIC_SUBKEY:
>         case PKT_SECRET_KEY:
>         case PKT_SECRET_SUBKEY:
>         case PKT_USER_ID:
>         case PKT_ATTRIBUTE:
>         case PKT_SIGNATURE:
> ===>    case PKT_RING_TRUST:
>           break; /* Allowed per RFC.  */
>
>         default:
>           /* Note that can't allow ring trust packets here and some of
>              the other GPG specific packets don't make sense either.  */
>           log_error ("skipped packet of type %d in keybox\n",
>                      (int)pkt->pkttype);
>           free_packet(pkt, &parsectx);
>           init_packet(pkt);
>           continue;
>         }
>
> Thus a ring trust packet can't show this error.  Note that the comment
> in the default case is misleading.
>
>
> Shalom-Salam,
>
>    Werner
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180222/c13b2642/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180222/c13b2642/attachment.sig>

From dank at kegel.com  Thu Feb 22 17:09:31 2018
From: dank at kegel.com (Dan Kegel)
Date: Thu, 22 Feb 2018 08:09:31 -0800
Subject: How can we utilize latest GPG from RPM repository?
In-Reply-To: <20180222062245.dn5ecl3vmii5y67k@adversary.org>
References: <CACNUArDNPfA3f+T+ztp-s2e4A6ewb+vovjHZYXESkf0cz1-OPQ@mail.gmail.com>
 <CACNUArDKDhyxFHhA3bq2B+o1p8Yzbo9Xst=60-N6WHpi8wK86Q@mail.gmail.com>
 <20180221061610.qwn3kkhkl6k356lp@adversary.org>
 <CAPF-yOYHfV3WORm-79mMJo-r4=qXicbphH_GhUHrcW_kjtB6nQ@mail.gmail.com>
 <20180222062245.dn5ecl3vmii5y67k@adversary.org>
Message-ID: <CAPF-yObWPV+FL-tAG2ABAw-2UN62XtNZML7t0mGAy0eZ_nNb7Q@mail.gmail.com>

On Wed, Feb 21, 2018 at 10:22 PM, Ben McGinnes <ben at adversary.org> wrote:
>> And when you're on those certified, curated systems, you have
>> access to tools like
>> https://www.open-scap.org/resources/documentation/make-a-rhel7-server-compliant-with-pci-dss/
>> to help make sure you're in compliance, I think.
>
> open-scap.org is a RedHat service
> and most likely only supplied to RHEL customers seeking PCI-DSS
> compliance along with direct support via their service contract.

https://www.open-scap.org/download/ shows they provide an
open source tool which is in repositories for four redhat-ish distros and
two debian-ish distros; on Ubuntu, I was able to walk down the
path of using it a bit, looks a bit rusty, but see
https://github.com/OpenSCAP/scap-security-guide
So it doesn't seem to be RHEL-only.  (They have a value-added tool
that is, of course.)
- Dan


From peter at digitalbrains.com  Thu Feb 22 17:13:51 2018
From: peter at digitalbrains.com (Peter Lebbing)
Date: Thu, 22 Feb 2018 17:13:51 +0100
Subject: enigmail with pgp 2.2.4
In-Reply-To: <DM5PR01MB223696A8038DB561ECECC86CA6CD0@DM5PR01MB2236.prod.exchangelabs.com>
References: <3332dd0d-f131-223b-82e4-3f84e4a0f706@linuxfoundation.org>
 <20180222043304.GS1365@bacardi.hollandpark.frase.id.au>
 <DM5PR01MB22364C6DFEA7F5980D2A264BA6CD0@DM5PR01MB2236.prod.exchangelabs.com>
 <87tvu988ml.fsf@wheatstone.g10code.de>
 <DM5PR01MB223696A8038DB561ECECC86CA6CD0@DM5PR01MB2236.prod.exchangelabs.com>
Message-ID: <70b9df3e-b0bd-a48f-1d6c-fa4ad0418ee5@digitalbrains.com>

On 22/02/18 15:21, Dmitry Gudkov wrote:
> sudo make -f build-aux/speedo.mk INSTALL_PREFIX=/usr/local

That would mean that GnuPG is in /usr/local/bin/gpg

Yet:

On 22/02/18 11:04, Dmitry Gudkov wrote:
> Error - key extraction command failed
> /usr/bin/gpg2 --charset utf-8 --display-charset utf-8 --use-agent --batch
> --no-tty --status-fd 2 -a --export 0xFB417E72

So probably /usr/bin/gpg2 is the distribution-provided older version, hence your
issues.

You should probably configure all your GnuPG-using software to use
/usr/local/bin/gpg. Also, it might make sense to explicitly configure all those
tools to use a non-default GNUPGHOME. That way, should one of your tools
accidentally pick /usr/bin/gpg2, it will hopefully also pick the default
homedir, and not interfere with all your correctly-configured tools. This is
just an idea that occured to me and is completely untested. Then again, mixing
these versions with identical homedirs is tested and has failed the test, so I'm
hoping for a net improvement ;-).

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/20180222/c49d8b91/attachment-0001.sig>

From dgouttegattat at incenp.org  Thu Feb 22 17:14:53 2018
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Thu, 22 Feb 2018 16:14:53 +0000
Subject: enigmail with pgp 2.2.4
In-Reply-To: <DM5PR01MB223696A8038DB561ECECC86CA6CD0@DM5PR01MB2236.prod.exchangelabs.com>
References: <3332dd0d-f131-223b-82e4-3f84e4a0f706@linuxfoundation.org>
 <20180222043304.GS1365@bacardi.hollandpark.frase.id.au>
 <DM5PR01MB22364C6DFEA7F5980D2A264BA6CD0@DM5PR01MB2236.prod.exchangelabs.com>
 <87tvu988ml.fsf@wheatstone.g10code.de>
 <DM5PR01MB223696A8038DB561ECECC86CA6CD0@DM5PR01MB2236.prod.exchangelabs.com>
Message-ID: <2e8e3c16-daa7-6bf5-391d-8454f01deca8@incenp.org>

Hi,

On 02/22/2018 02:21 PM, Dmitry Gudkov wrote:
> sudo make -f build-aux/speedo.mk INSTALL_PREFIX=/usr/local
> [...]
> *and all works fine in terminal*
> 
> however after installing Enigmail I get this error

You installed GnuPG 2.2.4 in /usr/local, but you still have an older 
version in /usr.

Everything works fine in the terminal because your shell finds the newer 
/usr/local/bin/gpg, but Enigmail is still using /usr/bin/gpg2 (as you 
can see in the error message, which includes the exact command used to 
invoke gpg).

You must configure Enigmail to use /usr/local/bin/gpg (in the 
"Preferences" dialog, "Basic" tab, override the default setting).

-------------- 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/20180222/c43752e4/attachment.sig>

From bereska at hotmail.com  Thu Feb 22 18:10:53 2018
From: bereska at hotmail.com (Dmitry Gudkov)
Date: Thu, 22 Feb 2018 17:10:53 +0000
Subject: enigmail with pgp 2.2.4
In-Reply-To: <2e8e3c16-daa7-6bf5-391d-8454f01deca8@incenp.org>
References: <3332dd0d-f131-223b-82e4-3f84e4a0f706@linuxfoundation.org>
 <20180222043304.GS1365@bacardi.hollandpark.frase.id.au>
 <DM5PR01MB22364C6DFEA7F5980D2A264BA6CD0@DM5PR01MB2236.prod.exchangelabs.com>
 <87tvu988ml.fsf@wheatstone.g10code.de>
 <DM5PR01MB223696A8038DB561ECECC86CA6CD0@DM5PR01MB2236.prod.exchangelabs.com>
 <2e8e3c16-daa7-6bf5-391d-8454f01deca8@incenp.org>
Message-ID: <DM5PR01MB2236778A4AE60D166D02366FA6CD0@DM5PR01MB2236.prod.exchangelabs.com>

dear all,

thank you for your time and help

problem solved by configuring Enigmail to use the new gnupg location in
/usr/local/bin/gpg (in the "Preferences" dialog, "Basic" tab, override
the default setting /usr/bin/gpg2)

?Dmitry

On 22.02.2018 19:14, Damien Goutte-Gattat wrote:
> Hi,
>
> On 02/22/2018 02:21 PM, Dmitry Gudkov wrote:
>> sudo make -f build-aux/speedo.mk INSTALL_PREFIX=/usr/local
>> [...]
>> *and all works fine in terminal*
>>
>> however after installing Enigmail I get this error
>
> You installed GnuPG 2.2.4 in /usr/local, but you still have an older
> version in /usr.
>
> Everything works fine in the terminal because your shell finds the
> newer /usr/local/bin/gpg, but Enigmail is still using /usr/bin/gpg2
> (as you can see in the error message, which includes the exact command
> used to invoke gpg).
>
> You must configure Enigmail to use /usr/local/bin/gpg (in the
> "Preferences" dialog, "Basic" tab, override the default setting).
>


-------------- 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/20180222/92c96c62/attachment.sig>

From wk at gnupg.org  Thu Feb 22 17:27:26 2018
From: wk at gnupg.org (Werner Koch)
Date: Thu, 22 Feb 2018 17:27:26 +0100
Subject: [Announce] GnuPG 2.2.5 released
Message-ID: <878tbl7zwx.fsf@wheatstone.g10code.de>

Hello!

We are is pleased to announce the availability of a new GnuPG release:
version 2.2.5.  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.5
===================================

  * gpg: Allow the use of the "cv25519" and "ed25519" short names in
    addition to the canonical curve names in --batch --gen-key.

  * gpg: Make sure to print all secret keys with option --list-only
    and --decrypt.  [#3718]

  * gpg: Fix the use of future-default with --quick-add-key for
    signing keys.  [#3747]

  * gpg: Select a secret key by checking availability under gpg-agent.
    [#1967]

  * gpg: Fix reversed prompt texts for --only-sign-text-ids.  [#3787]

  * gpg,gpgsm: Fix detection of bogus keybox blobs on 32 bit systems.
    [#3770]

  * gpgsm: Fix regression since 2.1 in --export-secret-key-raw which
    got $d mod (q-1)$ wrong.  Note that most tools automatically fixup
    that parameter anyway.

  * ssh: Fix a regression in getting the client'd PID on *BSD and
    macOS.

  * scd: Support the KDF Data Object of the OpenPGP card 3.3.  [#3152]

  * scd: Fix a regression in the internal CCID driver for certain card
    readers.  [#3508]

  * scd: Fix a problem on NetBSD killing scdaemon on gpg-agent
    shutdown.  [#3778]

  * dirmngr: Improve returned error description on failure of DNS
    resolving.  [#3756]

  * wks: Implement command --install-key for gpg-wks-server.

  * Add option STATIC=1 to the Speedo build system to allow a build
    with statically linked versions of the core GnuPG libraries.  Also
    use --enable-wks-tools by default by Speedo builds for Unix.


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

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

GnuPG 2.2.5 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.5.tar.bz2 (6430k)
 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.5.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.5_20180222.exe (3819k)
 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.5_20180222.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 3.0 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.5.tar.bz2 you would use this command:

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

     sha1sum gnupg-2.2.5.tar.bz2

   and check that the output matches the next line:

9dec110397e460b3950943e18f5873a4f277f216  gnupg-2.2.5.tar.bz2
080f801e833c7a9e0441d55cd19d4bdb5bb261f9  gnupg-w32-2.2.5_20180222.exe
0ff74deb747531663b5876788c271c94c20dd605  gnupg-w32-2.2.5_20180222.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/20180222/5749321e/attachment.sig>
-------------- next part --------------
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce

From peter at digitalbrains.com  Thu Feb 22 21:17:50 2018
From: peter at digitalbrains.com (Peter Lebbing)
Date: Thu, 22 Feb 2018 21:17:50 +0100
Subject: enigmail with pgp 2.2.4
In-Reply-To: <DM5PR01MB2236778A4AE60D166D02366FA6CD0@DM5PR01MB2236.prod.exchangelabs.com>
References: <3332dd0d-f131-223b-82e4-3f84e4a0f706@linuxfoundation.org>
 <20180222043304.GS1365@bacardi.hollandpark.frase.id.au>
 <DM5PR01MB22364C6DFEA7F5980D2A264BA6CD0@DM5PR01MB2236.prod.exchangelabs.com>
 <87tvu988ml.fsf@wheatstone.g10code.de>
 <DM5PR01MB223696A8038DB561ECECC86CA6CD0@DM5PR01MB2236.prod.exchangelabs.com>
 <2e8e3c16-daa7-6bf5-391d-8454f01deca8@incenp.org>
 <DM5PR01MB2236778A4AE60D166D02366FA6CD0@DM5PR01MB2236.prod.exchangelabs.com>
Message-ID: <6c301663-6a88-740a-957c-5030437349f1@digitalbrains.com>

On 22/02/18 18:10, Dmitry Gudkov wrote:
> problem solved by configuring Enigmail to use the new gnupg location in
> /usr/local/bin/gpg (in the "Preferences" dialog, "Basic" tab, override
> the default setting /usr/bin/gpg2)

While my mind was idly mulling this over, I suddenly wondered if what
you are doing is even supposed to work at all. I think perhaps you just
haven't discovered the dire consequences of it yet.

GnuPG 1.4 and 2.0 are co-installable, and will happily work installed on
the same system.

GnuPG 1.4 and 2.1+ are in the basis co-installable, but still can
present you with issues like keyrings going out of sync or requiring
careful crafting of configuration files, off the top of my head.

But 2.0 and 2.1+ are definitely not co-installable. You can't have them
both on the same system. Right now you put GnuPG 2.2 and its
dependencies in /usr/local, but GnuPG 2.0 and its dependencies are still
in /usr. Their dependencies might start to mingle.

The only way in which this might work is if I misinterpreted "not
co-installable", and 2.0 in /usr and 2.1+ in /usr/local is not actually
an instance of "co-installation". But I don't think that's the case. It
might also work by pure chance and break horribly on the next update.

A solution, where GnuPG 2.1+ is statically linked against its
dependencies, was discussed here:
<https://lists.gnupg.org/pipermail/gnupg-users/2018-February/059969.html>

Werner introduced the partial static linking in the just released 2.2.5.


Oh, and by the way, a little housekeeping information... You started
your thread on the mailing list by replying to a completely unrelated
thread (wotmate: simple grapher for your keyring). Could you please
start a new thread the next time? Just address a message to
<gnupg-users at gnupg.org> instead of replying to an existing message.
Those of us with a threading view of the mailing list now see it as
somehow being a part of the "wotmate: simple grapher for your keyring"
thread, but they bare no relation whatsoever.

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/20180222/306ee5a4/attachment-0001.sig>

From peter at digitalbrains.com  Thu Feb 22 21:29:55 2018
From: peter at digitalbrains.com (Peter Lebbing)
Date: Thu, 22 Feb 2018 21:29:55 +0100
Subject: enigmail with pgp 2.2.4
In-Reply-To: <6c301663-6a88-740a-957c-5030437349f1@digitalbrains.com>
References: <3332dd0d-f131-223b-82e4-3f84e4a0f706@linuxfoundation.org>
 <20180222043304.GS1365@bacardi.hollandpark.frase.id.au>
 <DM5PR01MB22364C6DFEA7F5980D2A264BA6CD0@DM5PR01MB2236.prod.exchangelabs.com>
 <87tvu988ml.fsf@wheatstone.g10code.de>
 <DM5PR01MB223696A8038DB561ECECC86CA6CD0@DM5PR01MB2236.prod.exchangelabs.com>
 <2e8e3c16-daa7-6bf5-391d-8454f01deca8@incenp.org>
 <DM5PR01MB2236778A4AE60D166D02366FA6CD0@DM5PR01MB2236.prod.exchangelabs.com>
 <6c301663-6a88-740a-957c-5030437349f1@digitalbrains.com>
Message-ID: <dbf3b385-632d-69ae-7928-a5c9b14d6a03@digitalbrains.com>

On 22/02/18 21:17, Peter Lebbing wrote:
> The only way in which this might work is if I misinterpreted "not
> co-installable", and 2.0 in /usr and 2.1+ in /usr/local is not actually
> an instance of "co-installation". But I don't think that's the case. It
> might also work by pure chance and break horribly on the next update.

I think I might be a bit dense, as this cropped up in the other thread
as well yet I again forgot to account for it.

See
<https://lists.gnupg.org/pipermail/gnupg-users/2018-February/059981.html>

Other programs on your system might pick up your /usr/local/bin/gpg and
start using it as if it were /usr/bin/gpg at version 1.4. This will
expose wrong assumptions in those programs, causing them to malfunction.
The thing about the partially statically linked version mentioned in

> <https://lists.gnupg.org/pipermail/gnupg-users/2018-February/059969.html>

is that it is in /opt, where your system will not use it unless very
explicitly configured to do so. In fact, I wouldn't even add it to your
own $PATH, because some other program you invoke might use it as well.

I notice that often when someone asks "I do this and it goes wrong, what
am I doing wrong", I will think "oh, this and that is what is going
wrong, do it like this" instead of "Wait, should you even be doing
that?" :-).

I don't think there is a fool-proof way to install GnuPG 2.1+ on a Linux
distribution that ships 1.4 and/or 2.0. It will always require being
cautious and knowing exactly what is using what. Luckily, if we as
end-users have a bit more patience, I think in the end all our
distributions will have done the hard work of fixing all of this for
you. I count myself lucky to be running Debian stable. For once, that
means I'm running a newer version than others! :-D

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/20180222/6025fe8f/attachment.sig>

From bereska at hotmail.com  Thu Feb 22 21:50:01 2018
From: bereska at hotmail.com (Dmitry Gudkov)
Date: Thu, 22 Feb 2018 20:50:01 +0000
Subject: enigmail with pgp 2.2.4
In-Reply-To: <6c301663-6a88-740a-957c-5030437349f1@digitalbrains.com>
References: <3332dd0d-f131-223b-82e4-3f84e4a0f706@linuxfoundation.org>
 <20180222043304.GS1365@bacardi.hollandpark.frase.id.au>
 <DM5PR01MB22364C6DFEA7F5980D2A264BA6CD0@DM5PR01MB2236.prod.exchangelabs.com>
 <87tvu988ml.fsf@wheatstone.g10code.de>
 <DM5PR01MB223696A8038DB561ECECC86CA6CD0@DM5PR01MB2236.prod.exchangelabs.com>
 <2e8e3c16-daa7-6bf5-391d-8454f01deca8@incenp.org>
 <DM5PR01MB2236778A4AE60D166D02366FA6CD0@DM5PR01MB2236.prod.exchangelabs.com>
 <6c301663-6a88-740a-957c-5030437349f1@digitalbrains.com>
Message-ID: <DM5PR01MB223671FDE24F7590B9184E83A6CD0@DM5PR01MB2236.prod.exchangelabs.com>

Hi Peter,

thank for your attention to this smallest problem of mine which I
wouldn't even hope to have your attention for to begin with)

my bad, I should have started a new thread, well noted

on the other hand that's probably why I suddenly had all the big gnupg
minds helping me)

what a rewarding side effect of unwittingly breaking the housekeeping rules)

seriously now ...

it was a fresh ubuntu 16.04 install

it came with gnupg 1.4.20 and 2.1.11

i compiled gnupg 2.2.4

it worked just fine in terminal and after configuring Enigmail with the
new gpg location works there as well

do you think i still have a problem?


thank you

Dmitry



On 22.02.2018 23:17, Peter Lebbing wrote:
> On 22/02/18 18:10, Dmitry Gudkov wrote:
>> problem solved by configuring Enigmail to use the new gnupg location in
>> /usr/local/bin/gpg (in the "Preferences" dialog, "Basic" tab, override
>> the default setting /usr/bin/gpg2)
> While my mind was idly mulling this over, I suddenly wondered if what
> you are doing is even supposed to work at all. I think perhaps you just
> haven't discovered the dire consequences of it yet.
>
> GnuPG 1.4 and 2.0 are co-installable, and will happily work installed on
> the same system.
>
> GnuPG 1.4 and 2.1+ are in the basis co-installable, but still can
> present you with issues like keyrings going out of sync or requiring
> careful crafting of configuration files, off the top of my head.
>
> But 2.0 and 2.1+ are definitely not co-installable. You can't have them
> both on the same system. Right now you put GnuPG 2.2 and its
> dependencies in /usr/local, but GnuPG 2.0 and its dependencies are still
> in /usr. Their dependencies might start to mingle.
>
> The only way in which this might work is if I misinterpreted "not
> co-installable", and 2.0 in /usr and 2.1+ in /usr/local is not actually
> an instance of "co-installation". But I don't think that's the case. It
> might also work by pure chance and break horribly on the next update.
>
> A solution, where GnuPG 2.1+ is statically linked against its
> dependencies, was discussed here:
> <https://lists.gnupg.org/pipermail/gnupg-users/2018-February/059969.html>
>
> Werner introduced the partial static linking in the just released 2.2.5.
>
>
> Oh, and by the way, a little housekeeping information... You started
> your thread on the mailing list by replying to a completely unrelated
> thread (wotmate: simple grapher for your keyring). Could you please
> start a new thread the next time? Just address a message to
> <gnupg-users at gnupg.org> instead of replying to an existing message.
> Those of us with a threading view of the mailing list now see it as
> somehow being a part of the "wotmate: simple grapher for your keyring"
> thread, but they bare no relation whatsoever.
>
> HTH,
>
> 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/20180222/6b3cf828/attachment.sig>

From nbsd4ever at gmail.com  Thu Feb 22 23:03:54 2018
From: nbsd4ever at gmail.com (Henry)
Date: Fri, 23 Feb 2018 07:03:54 +0900
Subject: having trouble checking the signature of a downloaded file
In-Reply-To: <7d94e7e8-8816-e429-72d0-3df4183f910d@sumptuouscapital.com>
References: <CAKP-rwGkrJGbp-jx4658MXy23gZM3cqJBnSrspq-FeHLH=jLeA@mail.gmail.com>
 <261fa63d-430f-d32c-05c4-7d8936161577@sumptuouscapital.com>
 <cf9aaf43-74d2-f9c4-b5d4-80119871a8f9@digitalbrains.com>
 <7d94e7e8-8816-e429-72d0-3df4183f910d@sumptuouscapital.com>
Message-ID: <CAKP-rwFD7j_73+as9yTnwMM4QEGsYjsE=4OMnbrC6870rA1=wg@mail.gmail.com>

2018-02-21 20:56 GMT+09:00 Kristian Fiskerstrand
<kristian.fiskerstrand at sumptuouscapital.com>:
> On 02/21/2018 11:53 AM, Peter Lebbing wrote:
> Touch? :) Indeed, didn't notice it was an old file/signature , then
> gnupg 1.4 is the recommended official suggestion presuming established
> validity of key material etc etc.

gpg (GnuPG) 1.4.22 does give more information, but no success; see
below.  May I assume that nothing
can be done other than to request the author to remedy the situation?
Thanks all.

Henry

result of using gnupg 1.4:
% gpg1 --import D5327CB9.key
gpg: key D5327CB9: "author <author at xxx.org>" not changed
gpg: Note: signatures using the MD5 algorithm are rejected
gpg: key D5327CB9: no valid user IDs
gpg: this may be caused by a missing self-signature
gpg: Total number processed: 2
gpg:           w/o user IDs: 1
gpg:              unchanged: 1

% gpg1 --verify ***6.4.tar.gz.sig ***6.4.tar.gz
gpg: Signature made Tue May  4 23:03:11 2004 JST using RSA key ID D5327CB9
gpg: Can't check signature: public key not found


From kristian.fiskerstrand at sumptuouscapital.com  Thu Feb 22 23:13:42 2018
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Thu, 22 Feb 2018 23:13:42 +0100
Subject: having trouble checking the signature of a downloaded file
In-Reply-To: <CAKP-rwFD7j_73+as9yTnwMM4QEGsYjsE=4OMnbrC6870rA1=wg@mail.gmail.com>
References: <CAKP-rwGkrJGbp-jx4658MXy23gZM3cqJBnSrspq-FeHLH=jLeA@mail.gmail.com>
 <261fa63d-430f-d32c-05c4-7d8936161577@sumptuouscapital.com>
 <cf9aaf43-74d2-f9c4-b5d4-80119871a8f9@digitalbrains.com>
 <7d94e7e8-8816-e429-72d0-3df4183f910d@sumptuouscapital.com>
 <CAKP-rwFD7j_73+as9yTnwMM4QEGsYjsE=4OMnbrC6870rA1=wg@mail.gmail.com>
Message-ID: <244b7db7-5d24-dea3-64b3-5a70619bb78a@sumptuouscapital.com>

On 02/22/2018 11:03 PM, Henry wrote:
> 2018-02-21 20:56 GMT+09:00 Kristian Fiskerstrand
> <kristian.fiskerstrand at sumptuouscapital.com>:
>> On 02/21/2018 11:53 AM, Peter Lebbing wrote:
>> Touch? :) Indeed, didn't notice it was an old file/signature , then
>> gnupg 1.4 is the recommended official suggestion presuming established
>> validity of key material etc etc.
> 
> gpg (GnuPG) 1.4.22 does give more information, but no success; see
> below.  May I assume that nothing
> can be done other than to request the author to remedy the situation?
> Thanks all.
> 

--allow-weak-digest-algos
Signatures made with known-weak digest algorithms are normally
allows the verification of signatures made with such weak algorithms.
MD5 is the only digest algorithm considered weak by default.

> Henry
> 
> result of using gnupg 1.4:
> % gpg1 --import D5327CB9.key
> gpg: key D5327CB9: "author <author at xxx.org>" not changed
> gpg: Note: signatures using the MD5 algorithm are rejected
> gpg: key D5327CB9: no valid user IDs
> gpg: this may be caused by a missing self-signature
> gpg: Total number processed: 2
> gpg:           w/o user IDs: 1
> gpg:              unchanged: 1
> 
> % gpg1 --verify ***6.4.tar.gz.sig ***6.4.tar.gz
> gpg: Signature made Tue May  4 23:03:11 2004 JST using RSA key ID D5327CB9
> gpg: Can't check signature: public key not found
> 


-- 
----------------------------
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
----------------------------
"The laws of Australia prevail in Australia, I can assure you of that.
The laws of mathematics are very commendable, but the only laws that
applies in Australia is the law of Australia."
(Malcolm Turnbull, Prime Minister of Australia).

-------------- 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/20180222/5da66587/attachment-0001.sig>

From kristian.fiskerstrand at sumptuouscapital.com  Thu Feb 22 23:44:29 2018
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Thu, 22 Feb 2018 23:44:29 +0100
Subject: having trouble checking the signature of a downloaded file
In-Reply-To: <244b7db7-5d24-dea3-64b3-5a70619bb78a@sumptuouscapital.com>
References: <CAKP-rwGkrJGbp-jx4658MXy23gZM3cqJBnSrspq-FeHLH=jLeA@mail.gmail.com>
 <261fa63d-430f-d32c-05c4-7d8936161577@sumptuouscapital.com>
 <cf9aaf43-74d2-f9c4-b5d4-80119871a8f9@digitalbrains.com>
 <7d94e7e8-8816-e429-72d0-3df4183f910d@sumptuouscapital.com>
 <CAKP-rwFD7j_73+as9yTnwMM4QEGsYjsE=4OMnbrC6870rA1=wg@mail.gmail.com>
 <244b7db7-5d24-dea3-64b3-5a70619bb78a@sumptuouscapital.com>
Message-ID: <4f63909d-6a8f-8a50-4d89-03041e2494b2@sumptuouscapital.com>

On 02/22/2018 11:13 PM, Kristian Fiskerstrand wrote:
> On 02/22/2018 11:03 PM, Henry wrote:
>> 2018-02-21 20:56 GMT+09:00 Kristian Fiskerstrand
>> <kristian.fiskerstrand at sumptuouscapital.com>:
>>> On 02/21/2018 11:53 AM, Peter Lebbing wrote:
>>> Touch? :) Indeed, didn't notice it was an old file/signature , then
>>> gnupg 1.4 is the recommended official suggestion presuming established
>>> validity of key material etc etc.
>> gpg (GnuPG) 1.4.22 does give more information, but no success; see
>> below.  May I assume that nothing
>> can be done other than to request the author to remedy the situation?
>> Thanks all.
>>
> --allow-weak-digest-algos
> Signatures made with known-weak digest algorithms are normally
> allows the verification of signatures made with such weak algorithms.
> MD5 is the only digest algorithm considered weak by default.
> 

That was truncated;

.B  --allow-weak-digest-algos
Signatures made with known-weak digest algorithms are normally
rejected with an ``invalid digest algorithm'' message.  This option
allows the verification of signatures made with such weak algorithms.
MD5 is the only digest algorithm considered weak by default.  See also
\fB--weak-digest\fR to reject other digest algorithms.


-- 
----------------------------
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
----------------------------
Varitatio delectat
Change pleases

-------------- 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/20180222/52886488/attachment.sig>

From thomas.jarosch at intra2net.com  Fri Feb 23 15:51:25 2018
From: thomas.jarosch at intra2net.com (Thomas Jarosch)
Date: Fri, 23 Feb 2018 15:51:25 +0100
Subject: [How-to] Use multiple smartcards simultaneously
Message-ID: <2357728.RzT4jpDWu9@storm.m.i2n>

Hello,

here's a quick howto for using multiple smartcards
at the same time on Fedora 26 with gnupg 2.2.4.

To access multiple card readers simultaneously,
the internal CCID driver of gnupg must be used.

Steps:

1. Allow normal users to access the card readers:

Create a "hwdb" file in /etc/udev/hwdb.d/99-smartcard-reader.hwdb

This file contains a list of USB IDs of the card readers.

########
usb:v04E6pE003*
usb:v046Ap003E*
usb:v0C4Bp0504*
    ID_SMARTCARD_READER=1
########

Adapt the USB device IDs to your card reader, some IDs are found here:
https://wiki.gnupg.org/CardReader/PinpadInput

The 'ID_SMARTCARD_READER' tag will trigger an udev rule
in /usr/lib/udev/rules.d/70-uaccess.rules that adds the "uaccess" tag for the reader.
This allows to access the card reader as normal user while you are logged in.


2. Update systemd's hwdb:

   systemd-hwdb update

   This re-generates the file /etc/udev/hwdb.bin


3. Prevent pcscd from starting

   pcscd can prevent gnupg from accessing the card reader using
   the internal CCID driver.

   Therefore you can mask (=disable) pcscd via systemd:

   systemctl mask --now pcscd.socket
   systemctl daemon-reload


4. Log out and log in again. All smartcards should now
   be listed when running "gnupg2 --card-status all"

   You can modify individual smartcards by using
   "gnupg2 --card-edit SERIALNO"


*** Debug tips'n'tricks ***
- Use "udevadm monitor --environment" to see how
  udev detects a card reader when plugged in.

  Example output:
    UDEV  [10155.134146] add      /devices/pci0000:00/0000:00:01.1/0000:01:00.0/usb1/1-3 (usb)
    ACTION=add
    BUSNUM=001
    DEVNAME=/dev/bus/usb/001/015
    DEVNUM=015
    DEVPATH=/devices/pci0000:00/0000:00:01.1/0000:01:00.0/usb1/1-3
    DEVTYPE=usb_device
    DRIVER=usb
    ID_BUS=usb
    ID_FOR_SEAT=usb-pci-0000_01_00_0-usb-0_3
    ID_MODEL=SPRx32_USB_Smart_Card_Reader
    ID_MODEL_ENC=SPRx32\x20USB\x20Smart\x20Card\x20Reader
    ID_MODEL_FROM_DATABASE=SPR532 PinPad SmartCard Reader
    ID_MODEL_ID=e003
    ID_PATH=pci-0000:01:00.0-usb-0:3
    ID_PATH_TAG=pci-0000_01_00_0-usb-0_3
    ID_REVISION=0601
    ID_SERIAL=SCM_Microsystems_Inc._SPRx32_USB_Smart_Card_Reader_xxxxx
    ID_SERIAL_SHORT=xxxxx
    ID_SMARTCARD_READER=1
    ID_USB_INTERFACES=:ff0000:
    ID_VENDOR=SCM_Microsystems_Inc.
    ID_VENDOR_ENC=SCM\x20Microsystems\x20Inc.
    ID_VENDOR_FROM_DATABASE=SCM Microsystems, Inc.
    ID_VENDOR_ID=04e6
    MAJOR=189
    MINOR=14
    PRODUCT=4e6/e003/601
    SEQNUM=4699
    SUBSYSTEM=usb
    SYSTEMD_WANTS=smartcard.target
    TAGS=:seat:systemd:uaccess:
    TYPE=0/0/0
    USEC_INITIALIZED=10155130754


Notice the "uaccess" tag in the output.
It also contains the USB device path in DEVNAME=,
in this case /dev/bus/usb/001/015.


- Inspect the user ACL on the USB device file via "getfacl"

getfacl /dev/bus/usb/001/015

    # getfacl /dev/bus/usb/001/015
    # file: dev/bus/usb/001/015
    # owner: root
    # group: root
    user::rw-
    user:alice:rw-
    group::rw-
    mask::rw-
    other::r--

-> there's an extra read/write ACL for username "alice" in there.


- enable scdaemon debug output in ~/.gnupg/scdaemon.conf

  When inspecting the log file, make sure there are no messages like
  "ccid open error: skip"

  If that's the case, try masking pcscd like above.
  Otherwise gnupg will fall back to pcscd mode which currently
  does not support multiple smartcards. See also:
  https://dev.gnupg.org/T1621#110805


Hopefully this short guide is useful to someone else
when setting up multiple card readers.

In fact it can even be helpful when using just one card reader,
since setting up the device permissions using udev's uaccess
system is tricky and sparely documented:
https://github.com/systemd/systemd/issues/4288


Cheers,
Thomas





From phylliswalters1983 at gmail.com  Fri Feb 23 18:53:58 2018
From: phylliswalters1983 at gmail.com (CORY WALTERS)
Date: Fri, 23 Feb 2018 12:53:58 -0500
Subject: Nano
Message-ID: <FB4603FB-244E-44C7-99DB-F4B5198287A2@gmail.com>



Sent from my iPhone


From jc.gnupg18a at unser.net  Fri Feb 23 23:08:20 2018
From: jc.gnupg18a at unser.net (Juergen Christoffel)
Date: Fri, 23 Feb 2018 23:08:20 +0100
Subject: Configuration for offline usage - best practice tips?
In-Reply-To: <87d113lypu.fsf@fifthhorseman.net>
References: <20180215203305.GA21779@unser.net>
 <87d113lypu.fsf@fifthhorseman.net>
Message-ID: <20180223220820.GA28155@unser.net>

On Sat, Feb 17, 2018 at 11:15:57PM -0500, Daniel Kahn Gillmor wrote:
>On Thu 2018-02-15 21:33:05 +0100, Juergen Christoffel wrote:
>
>> I'm looking for best practice tips for offline usage of GnuPG. [...]
>GnuPG's defaults should be fine for the common, simple backup case.
>
>However, i note that you're talking about "today's public key" -- that
>suggests that you're imagining a regularly-updated key that your backup
>tooling will know about.  This is in some sense antithetical to "offline
>usage" -- how will the backup scripts learn about the new keys if they
>can't go online to fetch them?

Thanks for the feedback and sorry for the delayed answer, I've been on a
business trip.

>It sounds like you're proposing an OpenPGP primary key that has a series
>of relatively short-lived, expiring encryption-capable subkeys.  Is that
>correct?

Yes, that's what I plan to do, generate a subkey for each month in advance
and use this to encrypt my backups.

And it seems that I shouldn't have used the term "offline usage" without a
better spec what I ment. So: GnuPG tips for communications use state that I
should do this or don't configure that in order to keep my keys compatible
with potential recipients. That's what I consider "online" use, while I use
"offline" to say that I don't intend to share encrypted stuff with external
parties, so I have no need for potential limitations

>For further clarity, it'd be useful to understand what you see as the
>goal of key rotation here.  Do you plan on deleting older secret
>subkeys?  if so, how will you recover backups that were encrypted to the
>destroyed secrets?

Backups are done from a rented root server to a rented storage server in
"the cloud" and I want to lessen the impact of a potential compromise of
these keys. That is, if I have to restore certain files from a backup, and
the machine where the decryption happens might be compromised, I don't want
all backups to be compromised in a single step. 

>But for backups, this is a slightly more complicated story.  It
>certainly can be useful if you want to be able to robustly *destroy*
>backups that might be stored on servers that you don't have full control
>over.  That is: encrypt the backup to public key X, send the encrypted
>copy to "the cloud", and then when you're sure you don't need it any
>more, delete the secret key corresponding to X to ensure that it's not
>recoverable.  But most people have a hard time just getting their
>backups to happen on a reasonable schedule, and don't have a reliable
>schedule for backup destruction.  Do you have such a plan?  Or do you
>envision some other reason for the proposed key rotation?

The backup plan is in place and uses rotating backups, so older backups
expire anyway after some time.

Thanks for your detailed suggestions, I'll rethink my plans with them in
mind.

Regards, JC


-- 
  Doctorow's Law: Anytime someone puts a lock on something you own, against
  your wishes, and doesn't give you the key, they're not doing it for your
  benefit.


From jym at NetBSD.org  Fri Feb 23 19:21:49 2018
From: jym at NetBSD.org (Jean-Yves Migeon)
Date: Fri, 23 Feb 2018 19:21:49 +0100
Subject: Issuing non self-signed certificate without having the private key in
 gpgsm keyring
Message-ID: <51c8af636fb2e1202ca1f03d445376dd@free.fr>

Hi everyone,

(please CC on reply, as I am not yet subscribed)

I am currently using gpgsm as somekind of PKI CA. It allows me to keep 
the CA private key stored on a smartcard, and create/sign different 
X.509 end-entity certs through the --gen-key --batch mode.

ATM (with gpgsm (GnuPG) 2.2.4) , due to [1], gpgsm cannot sign 
certificate for which a public key has been imported but without an 
associated private key to it (disregarding the self-signing situation):

[--gen-key --batch]
gpgsm: line 1: error getting key by keygrip 'D3513A1E...48E0BDB6D35': No 
such file or directory
gpgsm: error creating certificate request: No such file or directory 
<GPG Agent>
unable to load certificate

Typical X.509 PKI setups do not require the CA to have access to the 
entity private key for issuing a corresponding X.509 certificate. I 
still manage to fake that around by creating a corresponding private key 
file with the correct keygrip under private-keys-v1.d/ , but this is at 
best a really dirty hack.

Would it make sense to relax the test in [1] and allow certificate 
creation when we are not issuing a self-sign cert?

Thanks,

[1] https://github.com/gpg/gnupg/blob/master/sm/certreqgen.c#L712

-- 
Jean-Yves Migeon


From jerry at seibercom.net  Sat Feb 24 13:20:32 2018
From: jerry at seibercom.net (Jerry)
Date: Sat, 24 Feb 2018 07:20:32 -0500
Subject: Removing expired keys
Message-ID: <20180224072005.0000670e@seibercom.net>

Kleopatra Version 3.0.2-gpg4win-3.0.3

Running the command from Kleopatra <Tools> <Refresh OpenPGP Certificates> on a
Windows 10 PRO amd64 machine, displays numerous expired certificates. The
complete output is available here: https://seibercom.net/GPG-Expired-Keys.txt

Is there any command that I can run from either Kleopatra or the Windows'
command line that will remove all of these expired certificates? I would
really love to clean up system and removed expired or revoked certificates.
Also, how do I deal with "signatures not checked due to missing keys" warnings?

Thanks!

-- 
Jerry


From yanfiz at gmail.com  Sun Feb 25 00:30:14 2018
From: yanfiz at gmail.com (Yan Fiz)
Date: Sun, 25 Feb 2018 02:30:14 +0300
Subject: Subkey Usage, Expire Date and Preferences problem
Message-ID: <CAL=Q3eOC1dJvB_evdckHuNB4tfwXt4bQOTjh1kmrYE2dpVDe0A@mail.gmail.com>

Hello,

When I create unattended key with cv25519 or ed25519 as subkeys, GnuPG
doesn't apply 'encrypt' usage, expire date and preferences. There is no
problem with RSA.

Regards.

(PS : My example key numbers were padded with X and Y)

$ gpg --batch --gen-key
Key-Type: ecdsa
Key-Curve: ed25519
Key-Usage: sign auth
Subkey-Type: ecdh
Subkey-Curve: cv25519
Subkey-Usage: encrypt
Passphrase:
Name-Real: Yan Fiz
Expire-Date: 1y
Preferences: twofish sha512 zlib

$ gpg --edit-key XXXXXXXXXXXXXXXX showpref quit
gpg (GnuPG) 2.2.5; Copyright (C) 2018 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

gpg: key XXXXXXXXXXXXXXXX: 2 bad signatures
gpg: key XXXXXXXXXXXXXXXX: Warning: errors found and only checked
self-signatures, run 'check' to check all signatures.
Secret key is available.

sec  ed25519/XXXXXXXXXXXXXXXX
     created: 2018-02-24  expires: never       usage: SCA
     trust: ultimate      validity: ultimate
ssb  cv25519/YYYYYYYYYYYYYYYY
     created: 2018-02-24  expires: never       usage:
[ultimate] (1). Yan Fiz

[ultimate] (1). Yan Fiz
     Cipher: 3DES
     Digest: SHA1
     Compression: ZIP, Uncompressed
     Features: Keyserver no-modify
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180225/c74c7582/attachment-0001.html>

From yanfiz at gmail.com  Sun Feb 25 00:16:16 2018
From: yanfiz at gmail.com (Yan Fiz)
Date: Sun, 25 Feb 2018 02:16:16 +0300
Subject: Subkey Usage, Expire Date and Preferences problem
Message-ID: <CAL=Q3eM=DzQNq5pw+-XkB-fVNSwB=4sz20Qft237bw0F2P0mpQ@mail.gmail.com>

Hello,

When I create unattended key with cv25519 or ed25519 as subkeys, GnuPG
doesn't apply 'encrypt' usage, expire date and preferences. There is no
problem with RSA.

Regards.

(PS : My example key numbers were padded with X and Y)

$ gpg --batch --gen-key
Key-Type: ecdsa
Key-Curve: ed25519
Key-Usage: sign auth
Subkey-Type: ecdh
Subkey-Curve: cv25519
Subkey-Usage: encrypt
Passphrase:
Name-Real: Yan Fiz
Expire-Date: 1y
Preferences: twofish sha512 zlib

$ gpg --edit-key XXXXXXXXXXXXXXXX showpref quit
gpg (GnuPG) 2.2.5; Copyright (C) 2018 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

gpg: key XXXXXXXXXXXXXXXX: 2 bad signatures
gpg: key XXXXXXXXXXXXXXXX: Warning: errors found and only checked
self-signatures, run 'check' to check all signatures.
Secret key is available.

sec  ed25519/XXXXXXXXXXXXXXXX
     created: 2018-02-24  expires: never       usage: SCA
     trust: ultimate      validity: ultimate
ssb  cv25519/YYYYYYYYYYYYYYYY
     created: 2018-02-24  expires: never       usage:
[ultimate] (1). Yan Fiz

[ultimate] (1). Yan Fiz
     Cipher: 3DES
     Digest: SHA1
     Compression: ZIP, Uncompressed
     Features: Keyserver no-modify
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180225/1f2d949c/attachment.html>

From peter at digitalbrains.com  Sun Feb 25 13:24:57 2018
From: peter at digitalbrains.com (Peter Lebbing)
Date: Sun, 25 Feb 2018 13:24:57 +0100
Subject: enigmail with pgp 2.2.4
In-Reply-To: <DM5PR01MB223671FDE24F7590B9184E83A6CD0@DM5PR01MB2236.prod.exchangelabs.com>
References: <3332dd0d-f131-223b-82e4-3f84e4a0f706@linuxfoundation.org>
 <20180222043304.GS1365@bacardi.hollandpark.frase.id.au>
 <DM5PR01MB22364C6DFEA7F5980D2A264BA6CD0@DM5PR01MB2236.prod.exchangelabs.com>
 <87tvu988ml.fsf@wheatstone.g10code.de>
 <DM5PR01MB223696A8038DB561ECECC86CA6CD0@DM5PR01MB2236.prod.exchangelabs.com>
 <2e8e3c16-daa7-6bf5-391d-8454f01deca8@incenp.org>
 <DM5PR01MB2236778A4AE60D166D02366FA6CD0@DM5PR01MB2236.prod.exchangelabs.com>
 <6c301663-6a88-740a-957c-5030437349f1@digitalbrains.com>
 <DM5PR01MB223671FDE24F7590B9184E83A6CD0@DM5PR01MB2236.prod.exchangelabs.com>
Message-ID: <db30bf83-b148-8f9d-9b63-7b98f38329e1@digitalbrains.com>

On 22/02/18 21:50, Dmitry Gudkov wrote:
> my bad, I should have started a new thread, well noted
> 
> on the other hand that's probably why I suddenly had all the big gnupg
> minds helping me)

Hehe, I think this is all just pure chance, it depends who has the time
to read and respond. I don't think it's related to threading. What does
make a difference, possibly a large one, by the way, is when the
question is accompanied by much useful contextual information. If I'm
reading a mail here and can already get a long way towards the solution
by all the information in a question, I'm more inclined to respond then
when my response would still be asking a lot of questions back. But this
is just some general musing on my part. And it is also unrelated to your
specific mail, it's a general observation.

And by the way, my knowledge of GnuPG is not exceptional, I'm not a
developer, just an enthousiast who has made it a hobby to try and help
people here on the list :-).

> seriously now ...

Yes, let's :-).

> it was a fresh ubuntu 16.04 install
> 
> it came with gnupg 1.4.20 and 2.1.11
> 
> i compiled gnupg 2.2.4

Ah! I see. I didn't know or had forgotten that Ubuntu 16.04 forked
Debian at a time when the gnupg2 package was a 2.1. AFAICT, looking at
.deb files, /usr/bin/gpg is GnuPG 1.4 from the gnupg package and
/usr/bin/gpg2 is 2.1 from the gnupg2 package in Ubuntu, which
corresponds to what you say.

Now let's list problems and solutions:

- Programs invoking "gpg" (or explicitly /usr/bin/gpg) expect it to be a
1.4 installation.

This should be fixed by having your locally installed GnuPG 2.2.5
provide a "gpg2" binary, not a "gpg" binary:

./configure --enable-gpg-is-gpg2

(include whatever other configure options you want, but also include
that one).

Since it requires recompilation, let's pick the latest and greatest
2.2.5 :-).

Since in Ubuntu 16.04, anything invoking "gpg2" or "/usr/bin/gpg2" is
either working with a 2.1 version or is not working as shipped by the
distribution, you won't create more breakage (anything working with 2.1
should work with 2.2).

- You have a GnuPG 2.1.11 in /usr/bin/gpg2 and a 2.2.4 in
/usr/local/bin/gpg2. A similar situation occurs with any locally
compiled libraries and stuff.

The best solution would be to create Debian packages yourself, based on
the Ubuntu packaging but utilising the latest GnuPG 2.2 instead of the
2.1.11 of Ubuntu that was last updated 2 years ago (on 8 April 2016, to
be precise) and contains known bugs.

That is some work, but doable. It requires looking at how Ubuntu
packaged it, and create something equal but using a vanilla 2.2.5
instead of a 2.1.11 with backported fixes. Well, with a 2.1.11 that had
backported fixes 2 years ago. I think it's unfortunate they stopped
backporting fixes once they released 16.04.

I'm not 100% sure about other good solutions. I think it's not a good
idea to have 2.1.11 in /usr and 2.2.5 in /usr/local. But if it works for
you, you could see if it keeps working for you. I'll come back to this.

Another solution is installing the stuff in /usr/local like you did, but
with some additional actions:

Make sure everything has /usr/local/bin in its PATH and ld.so is looking
for libraries in /usr/local/lib. On Debian, I think this is already in
place.

And then replace the gnupg2 package, the gpg-agent package and all the
others for which you just installed a /usr/local package by an equivs
package. Just have a look at each file you installed in /usr/local with
your local compile, and do something like:

You see:
/usr/local/bin/gpg2

You inquire:
dpkg -S /usr/bin/gpg2

And dpkg tells you it is part of package gnupg2, so you need to build an
equivs for that. Etcetera.

Install the "equivs" package. Read its manual, and create packages named
"gnupg2" etcetera. Replace all real Ubuntu packages by these dummy
equivs package.

What did I just propose doing?

I don't like the situation where there is a full real GnuPG in /usr and
another one in /usr/local. The one in /usr might interfere with what you
intend with the one in /usr/local. But you can't just deinstall the
Ubuntu packages, because stuff depends on it. It would force
deinstallation of all packages depending upon gnupg2, gpg-agent etcetera.

With equivs, you can build an empty package. It doesn't install anything
in /usr, so there will no longer be a /usr/bin/gpg2 at all. But any
package that depends on "gnupg2" will see the empty equivs package named
"gnupg2" and be happy that it is installed.

I have done this myself with other packages, but never with GnuPG.

> it worked just fine in terminal and after configuring Enigmail with the
> new gpg location works there as well

You could just see if it gives you any issues. I'm slightly worried
about silent issues, though, where you think everything is working fine
but it is failing in some subtle but nefarious way. I'm also slightly
worried about the 2.1.11 Ubuntu 16.04 users have installed, which hasn't
seen any maintenance since Ubuntu 16.04 was released two years ago.

> do you think i still have a problem?

It is your decision how thorough you wish to be. IMO, a true locally
built Debian package is the epitome of thoroughness ;-).

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/20180225/23ae3cc5/attachment.sig>

From dirk.gottschalk1980 at googlemail.com  Sun Feb 25 14:48:23 2018
From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk)
Date: Sun, 25 Feb 2018 14:48:23 +0100
Subject: Removing expired keys
In-Reply-To: <20180224072005.0000670e@seibercom.net>
References: <20180224072005.0000670e@seibercom.net>
Message-ID: <1519566503.2417.3.camel@googlemail.com>

Hello.

Am Samstag, den 24.02.2018, 07:20 -0500 schrieb Jerry:
> Kleopatra Version 3.0.2-gpg4win-3.0.3
> 
> Running the command from Kleopatra <Tools> <Refresh OpenPGP
> Certificates> on a
> Windows 10 PRO amd64 machine, displays numerous expired certificates.
> The
> complete output is available here: https://seibercom.net/GPG-Expired-
> Keys.txt
> 
> Is there any command that I can run from either Kleopatra or the
> Windows'
> command line that will remove all of these expired certificates? I
> would
> really love to clean up system and removed expired or revoked
> certificates.

I run under Linux and have a shell script for this. AFAIK there is no
way to do this automatically from gpg itself.


> Also, how do I deal with "signatures not checked due to missing keys"
> warnings?

You could turn on automatic key retieval in gog.conf. add the following
to the keyserver-options parameter:

auto-key-retrieve

This will automatically download missing keys when you try to verify a
signature.

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/20180225/e3b47b4c/attachment.sig>

From yanfiz at gmail.com  Sun Feb 25 15:18:40 2018
From: yanfiz at gmail.com (Yan Fiz)
Date: Sun, 25 Feb 2018 17:18:40 +0300
Subject: Subkey Usage, Expire Date and Preferences problem
In-Reply-To: <CAL=Q3eM=DzQNq5pw+-XkB-fVNSwB=4sz20Qft237bw0F2P0mpQ@mail.gmail.com>
References: <CAL=Q3eM=DzQNq5pw+-XkB-fVNSwB=4sz20Qft237bw0F2P0mpQ@mail.gmail.com>
Message-ID: <CAL=Q3eM9gjiVfg_pqdO8izw4Jb5cNRj=xxhupWQ8bttNHpzTUQ@mail.gmail.com>

Oh, sorry. I made a mistake in 'Key-Type:' line. Right one :

Key-Type: eddsa

On Sun, Feb 25, 2018 at 2:16 AM, Yan Fiz <yanfiz at gmail.com> wrote:

> Hello,
>
> When I create unattended key with cv25519 or ed25519 as subkeys, GnuPG
> doesn't apply 'encrypt' usage, expire date and preferences. There is no
> problem with RSA.
>
> Regards.
>
> (PS : My example key numbers were padded with X and Y)
>
> $ gpg --batch --gen-key
> Key-Type: ecdsa
> Key-Curve: ed25519
> Key-Usage: sign auth
> Subkey-Type: ecdh
> Subkey-Curve: cv25519
> Subkey-Usage: encrypt
> Passphrase:
> Name-Real: Yan Fiz
> Expire-Date: 1y
> Preferences: twofish sha512 zlib
>
> $ gpg --edit-key XXXXXXXXXXXXXXXX showpref quit
> gpg (GnuPG) 2.2.5; Copyright (C) 2018 Free Software Foundation, Inc.
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
>
> gpg: key XXXXXXXXXXXXXXXX: 2 bad signatures
> gpg: key XXXXXXXXXXXXXXXX: Warning: errors found and only checked
> self-signatures, run 'check' to check all signatures.
> Secret key is available.
>
> sec  ed25519/XXXXXXXXXXXXXXXX
>      created: 2018-02-24  expires: never       usage: SCA
>      trust: ultimate      validity: ultimate
> ssb  cv25519/YYYYYYYYYYYYYYYY
>      created: 2018-02-24  expires: never       usage:
> [ultimate] (1). Yan Fiz
>
> [ultimate] (1). Yan Fiz
>      Cipher: 3DES
>      Digest: SHA1
>      Compression: ZIP, Uncompressed
>      Features: Keyserver no-modify
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180225/84d85737/attachment-0001.html>

From bereska at hotmail.com  Sun Feb 25 15:45:38 2018
From: bereska at hotmail.com (Dmitry Gudkov)
Date: Sun, 25 Feb 2018 14:45:38 +0000
Subject: enigmail with pgp 2.2.4
In-Reply-To: <db30bf83-b148-8f9d-9b63-7b98f38329e1@digitalbrains.com>
References: <3332dd0d-f131-223b-82e4-3f84e4a0f706@linuxfoundation.org>
 <20180222043304.GS1365@bacardi.hollandpark.frase.id.au>
 <DM5PR01MB22364C6DFEA7F5980D2A264BA6CD0@DM5PR01MB2236.prod.exchangelabs.com>
 <87tvu988ml.fsf@wheatstone.g10code.de>
 <DM5PR01MB223696A8038DB561ECECC86CA6CD0@DM5PR01MB2236.prod.exchangelabs.com>
 <2e8e3c16-daa7-6bf5-391d-8454f01deca8@incenp.org>
 <DM5PR01MB2236778A4AE60D166D02366FA6CD0@DM5PR01MB2236.prod.exchangelabs.com>
 <6c301663-6a88-740a-957c-5030437349f1@digitalbrains.com>
 <DM5PR01MB223671FDE24F7590B9184E83A6CD0@DM5PR01MB2236.prod.exchangelabs.com>
 <db30bf83-b148-8f9d-9b63-7b98f38329e1@digitalbrains.com>
Message-ID: <DM5PR01MB22363A85A50995E5988FCA62A6C20@DM5PR01MB2236.prod.exchangelabs.com>

Hi Peter,

i thought you forgot about me)
thank you for your very detailed response

I have a confession to make, too. Not only I'm not a developer, but I'm
a fresh convert from os to linux). And it all started last year when I
stumbled upon gnupg just looking for a proper way to encrypt a flash drive)

Correct me if I'm wrong but the best conclusion I could make for your
letter is that unless I locally build a Debian package myself (the
epitome of thoroughness!), I can't be 100% sure everything works as it
should.

If that's the case. I do want to give it a shot but I doubt I can do it
without step-by-step guide without breaking something). I guess it must
be boring for you to dedicate more of your time on this, but I can't
help but asking to provide one for me in hope that there are some more
inexperienced GNU/Linux users on this mailing list who might be very
much interested in building the epitome of thoroughness themselves but
just too shy to ask for guidance)

respectfully,
Dmitry

On 25.02.2018 15:24, Peter Lebbing wrote:
> On 22/02/18 21:50, Dmitry Gudkov wrote:
>> my bad, I should have started a new thread, well noted
>>
>> on the other hand that's probably why I suddenly had all the big gnupg
>> minds helping me)
> Hehe, I think this is all just pure chance, it depends who has the time
> to read and respond. I don't think it's related to threading. What does
> make a difference, possibly a large one, by the way, is when the
> question is accompanied by much useful contextual information. If I'm
> reading a mail here and can already get a long way towards the solution
> by all the information in a question, I'm more inclined to respond then
> when my response would still be asking a lot of questions back. But this
> is just some general musing on my part. And it is also unrelated to your
> specific mail, it's a general observation.
>
> And by the way, my knowledge of GnuPG is not exceptional, I'm not a
> developer, just an enthousiast who has made it a hobby to try and help
> people here on the list :-).
>
>> seriously now ...
> Yes, let's :-).
>
>> it was a fresh ubuntu 16.04 install
>>
>> it came with gnupg 1.4.20 and 2.1.11
>>
>> i compiled gnupg 2.2.4
> Ah! I see. I didn't know or had forgotten that Ubuntu 16.04 forked
> Debian at a time when the gnupg2 package was a 2.1. AFAICT, looking at
> .deb files, /usr/bin/gpg is GnuPG 1.4 from the gnupg package and
> /usr/bin/gpg2 is 2.1 from the gnupg2 package in Ubuntu, which
> corresponds to what you say.
>
> Now let's list problems and solutions:
>
> - Programs invoking "gpg" (or explicitly /usr/bin/gpg) expect it to be a
> 1.4 installation.
>
> This should be fixed by having your locally installed GnuPG 2.2.5
> provide a "gpg2" binary, not a "gpg" binary:
>
> ./configure --enable-gpg-is-gpg2
>
> (include whatever other configure options you want, but also include
> that one).
>
> Since it requires recompilation, let's pick the latest and greatest
> 2.2.5 :-).
>
> Since in Ubuntu 16.04, anything invoking "gpg2" or "/usr/bin/gpg2" is
> either working with a 2.1 version or is not working as shipped by the
> distribution, you won't create more breakage (anything working with 2.1
> should work with 2.2).
>
> - You have a GnuPG 2.1.11 in /usr/bin/gpg2 and a 2.2.4 in
> /usr/local/bin/gpg2. A similar situation occurs with any locally
> compiled libraries and stuff.
>
> The best solution would be to create Debian packages yourself, based on
> the Ubuntu packaging but utilising the latest GnuPG 2.2 instead of the
> 2.1.11 of Ubuntu that was last updated 2 years ago (on 8 April 2016, to
> be precise) and contains known bugs.
>
> That is some work, but doable. It requires looking at how Ubuntu
> packaged it, and create something equal but using a vanilla 2.2.5
> instead of a 2.1.11 with backported fixes. Well, with a 2.1.11 that had
> backported fixes 2 years ago. I think it's unfortunate they stopped
> backporting fixes once they released 16.04.
>
> I'm not 100% sure about other good solutions. I think it's not a good
> idea to have 2.1.11 in /usr and 2.2.5 in /usr/local. But if it works for
> you, you could see if it keeps working for you. I'll come back to this.
>
> Another solution is installing the stuff in /usr/local like you did, but
> with some additional actions:
>
> Make sure everything has /usr/local/bin in its PATH and ld.so is looking
> for libraries in /usr/local/lib. On Debian, I think this is already in
> place.
>
> And then replace the gnupg2 package, the gpg-agent package and all the
> others for which you just installed a /usr/local package by an equivs
> package. Just have a look at each file you installed in /usr/local with
> your local compile, and do something like:
>
> You see:
> /usr/local/bin/gpg2
>
> You inquire:
> dpkg -S /usr/bin/gpg2
>
> And dpkg tells you it is part of package gnupg2, so you need to build an
> equivs for that. Etcetera.
>
> Install the "equivs" package. Read its manual, and create packages named
> "gnupg2" etcetera. Replace all real Ubuntu packages by these dummy
> equivs package.
>
> What did I just propose doing?
>
> I don't like the situation where there is a full real GnuPG in /usr and
> another one in /usr/local. The one in /usr might interfere with what you
> intend with the one in /usr/local. But you can't just deinstall the
> Ubuntu packages, because stuff depends on it. It would force
> deinstallation of all packages depending upon gnupg2, gpg-agent etcetera.
>
> With equivs, you can build an empty package. It doesn't install anything
> in /usr, so there will no longer be a /usr/bin/gpg2 at all. But any
> package that depends on "gnupg2" will see the empty equivs package named
> "gnupg2" and be happy that it is installed.
>
> I have done this myself with other packages, but never with GnuPG.
>
>> it worked just fine in terminal and after configuring Enigmail with the
>> new gpg location works there as well
> You could just see if it gives you any issues. I'm slightly worried
> about silent issues, though, where you think everything is working fine
> but it is failing in some subtle but nefarious way. I'm also slightly
> worried about the 2.1.11 Ubuntu 16.04 users have installed, which hasn't
> seen any maintenance since Ubuntu 16.04 was released two years ago.
>
>> do you think i still have a problem?
> It is your decision how thorough you wish to be. IMO, a true locally
> built Debian package is the epitome of thoroughness ;-).
>
> HTH,
>
> 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/20180225/7cd0ddb3/attachment.sig>

From jerry at seibercom.net  Sun Feb 25 18:41:38 2018
From: jerry at seibercom.net (Jerry)
Date: Sun, 25 Feb 2018 12:41:38 -0500
Subject: Removing expired keys
In-Reply-To: <1519566503.2417.3.camel@googlemail.com>
References: <20180224072005.0000670e@seibercom.net>
 <1519566503.2417.3.camel@googlemail.com>
Message-ID: <20180225124138.00003ad5@seibercom.net>

On Sun, 25 Feb 2018 14:48:23 +0100, Dirk Gottschalk via Gnupg-users stated:

>Hello.
>
>Am Samstag, den 24.02.2018, 07:20 -0500 schrieb Jerry:
>> Kleopatra Version 3.0.2-gpg4win-3.0.3
>> 
>> Running the command from Kleopatra <Tools> <Refresh OpenPGP  
>> Certificates> on a  
>> Windows 10 PRO amd64 machine, displays numerous expired certificates.
>> The
>> complete output is available here: https://seibercom.net/GPG-Expired-
>> Keys.txt
>> 
>> Is there any command that I can run from either Kleopatra or the
>> Windows'
>> command line that will remove all of these expired certificates? I
>> would
>> really love to clean up system and removed expired or revoked
>> certificates.  
>
>I run under Linux and have a shell script for this. AFAIK there is no
>way to do this automatically from gpg itself.
>
>
>> Also, how do I deal with "signatures not checked due to missing keys"
>> warnings?  
>
>You could turn on automatic key retieval in gog.conf. add the following
>to the keyserver-options parameter:
>
>auto-key-retrieve

It is already there.

>This will automatically download missing keys when you try to verify a
>signature.
>
>Regards,
>Dirk




From ben at adversary.org  Sun Feb 25 19:22:58 2018
From: ben at adversary.org (Ben McGinnes)
Date: Mon, 26 Feb 2018 05:22:58 +1100
Subject: How can we utilize latest GPG from RPM repository?
In-Reply-To: <CAPF-yObWPV+FL-tAG2ABAw-2UN62XtNZML7t0mGAy0eZ_nNb7Q@mail.gmail.com>
References: <CACNUArDNPfA3f+T+ztp-s2e4A6ewb+vovjHZYXESkf0cz1-OPQ@mail.gmail.com>
 <CACNUArDKDhyxFHhA3bq2B+o1p8Yzbo9Xst=60-N6WHpi8wK86Q@mail.gmail.com>
 <20180221061610.qwn3kkhkl6k356lp@adversary.org>
 <CAPF-yOYHfV3WORm-79mMJo-r4=qXicbphH_GhUHrcW_kjtB6nQ@mail.gmail.com>
 <20180222062245.dn5ecl3vmii5y67k@adversary.org>
 <CAPF-yObWPV+FL-tAG2ABAw-2UN62XtNZML7t0mGAy0eZ_nNb7Q@mail.gmail.com>
Message-ID: <20180225182258.mlwjupglavbz6cpd@adversary.org>

On Thu, Feb 22, 2018 at 08:09:31AM -0800, Dan Kegel wrote:
> 
> https://www.open-scap.org/download/ shows they provide an
> open source tool which is in repositories for four redhat-ish distros and
> two debian-ish distros; on Ubuntu, I was able to walk down the
> path of using it a bit, looks a bit rusty, but see
> https://github.com/OpenSCAP/scap-security-guide
> So it doesn't seem to be RHEL-only.  (They have a value-added tool
> that is, of course.)

Interesting and good to know if I'm ever in the unfortunate position
of needing to deal with it directly again.


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

From emz at norma.perm.ru  Mon Feb 26 05:40:30 2018
From: emz at norma.perm.ru (Eugene M. Zheganin)
Date: Mon, 26 Feb 2018 09:40:30 +0500
Subject: generate key using specific cipher
Message-ID: <f34a430f-b948-1955-f448-d8df671aabd5@norma.perm.ru>

Hi,

I'm trying to learn how to use gpg/libgcrypt with GOST cryptography 
(actually I'm moving from openssl, where GOST is deprecated due to poor 
code quality to the gpg/libgcrypt software, where GOST is present since 
1.7.0), and since the entire crypoto subsystem is (from my point of 
view) is overcomplicated, I'm lacking some simple skills - for instance, 
how do I generate an x509 csr/key with GOST (is it even possible) ? In 
openssl I would do something like "openssl req -newkey gost2001 -pkeyopt 
paramset:A -keyout foo -out bar" and this would do the trick. In 
gnupg.... well, I'm looking at the documentation right now but just 
cannot find the clue.

Thanks.

Eugene.



From wk at gnupg.org  Mon Feb 26 09:29:02 2018
From: wk at gnupg.org (Werner Koch)
Date: Mon, 26 Feb 2018 09:29:02 +0100
Subject: generate key using specific cipher
In-Reply-To: <f34a430f-b948-1955-f448-d8df671aabd5@norma.perm.ru> (Eugene
 M. Zheganin's message of "Mon, 26 Feb 2018 09:40:30 +0500")
References: <f34a430f-b948-1955-f448-d8df671aabd5@norma.perm.ru>
Message-ID: <87muzw40j5.fsf@wheatstone.g10code.de>

On Mon, 26 Feb 2018 05:40, emz at norma.perm.ru said:

> I'm trying to learn how to use gpg/libgcrypt with GOST cryptography
> (actually I'm moving from openssl, where GOST is deprecated due to
> poor code quality to the gpg/libgcrypt software, where GOST is present
> since 1.7.0), and since the entire crypoto subsystem is (from my point

You can't use GOST with gpg becuase OpenPGP does not specify it.  For
gpgsm it would be possible to add support for GOST but we can do that
only if there is an RFC for adding GOST to PKIX _and_ if we are able to
test against an established certificate infrastructure.  The latter is
even problematic for DSA and ECC.


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/20180226/27259862/attachment.sig>

From eugene at zhegan.in  Sun Feb 25 19:39:52 2018
From: eugene at zhegan.in (Eugene M. Zheganin)
Date: Sun, 25 Feb 2018 23:39:52 +0500
Subject: generate key using specific cipher
Message-ID: <6f38d012-acc6-fe04-4985-0e767824b6b3@zhegan.in>

Hi,

I'm trying to learn how to use gpg/libgcrypt with GOST cryptography 
(actually I'm moving from openssl, where GOST is deprecated due to poor 
code quality to the gpg/libgcrypt software, where GOST is present since 
1.7.0), and since the entire crypoto subsystem is (from my point of 
view) is overcomplicated, I'm lacking some simple skills - for instance, 
how do I generate an x509 csr/key with GOST (is it even possible) ? In 
openssl I would do something like "openssl req -newkey gost2001 -pkeyopt 
paramset:A -keyout foo -out bar" and this would do the trick. In 
gnupg.... well, I'm looking at the documentation right now but just 
cannot find the clue.

Thanks.

Eugene.



From tookmund at gmail.com  Mon Feb 26 21:33:29 2018
From: tookmund at gmail.com (Jacob Adams)
Date: Mon, 26 Feb 2018 15:33:29 -0500
Subject: PGP Clean Room GSoC Mentoring
Message-ID: <CACvmPucbqrDAd6hv2qT_8r899f_TVxPOxP2eHiYVwx5of5YhpQ@mail.gmail.com>

Hello all,

I'm a prospective student for Debian's Google Summer of Code 2018 and
I am interested in working on a project that may be of interest to
those on this mailing list and that requires at least one more
co-mentor to move forward.

The biggest hurdle I faced when setting up my GPG key was creating and
storing it offline. Many live cds like TAILS can be manipulated for
this purpose, but are not designed for it and require quite a bit of
space for what is otherwise a relatively small amount of information.
I am looking to create a proper interface for a PGP Clean Room Live CD
that walks a user through setting up a set of USB flash drives or sd
cards as a raid disk, generating new GPG keys, storing them there, and
then exporting subkeys either on a separate USB stick or a security
key like a Yubikey. I'd also like to add the ability to do things like
revoke keys or extend expiration dates for them through the
application. You can see more of the ideas behind the project here:
https://wiki.debian.org/SummerOfCode2018/Projects/CleanRoomForPGPKeyManagement

Daniel Pocock has already agreed to be the primary mentor for this
project, but he will most likely be involved in at least one other
GSoC project. I've sent out a few emails in Debian but have received
no reply as yet so I'm reaching out to the wider open source
community.
You can find the Mentor Guide here: https://google.github.io/gsocguides/mentor/

Someone with experience in python, especially python's GPGME bindings,
would be much appreciated.

Thanks,
Jacob


From kr at glsys.de  Tue Feb 27 01:04:27 2018
From: kr at glsys.de (=?utf-8?Q?Klaus_R=C3=B6mer?=)
Date: Tue, 27 Feb 2018 01:04:27 +0100
Subject: Fwd: gnupg SmartCard V3.3
References: <8885CA3E-2148-4171-A181-F5C762FE5DDB@glsys.de>
Message-ID: <59F022CF-521C-4A8B-9DA5-F0D5158BB312@glsys.de>


Hello,
i bought two V3.3 cards, but can`t get them to work ?
the keytocard command does not move the key but copy it and further on the gpg2 --card-status -> fetch 
followed by gpg2 --card-status does not create the stub keys, so gpg2 --list-secret-keys does not show any keys ...
I have the same (rsa4096) sub-key loaded to each slot 1,2,3 eg SEA and card-status does show them ? 
gpg2 --version is 2.1.11


I did further tests by calling gpg2 ?card-edit -> generate with keylength 2048 and 4096 which fail with ?card-error? 

Tried gpg (GnuPG/MacGPG2) 2.2.3
on a completely different machine (mac)

Tried the other card (i bought two with consecutive serial numbers)

Tried three different card-reader:
- Cherry GmbH SmartBoard XX44
-  KOBIL EMV CAP - SecOVID Reader III
- Alcor Micro AU9540 00 00

Can anybody help?

Kind Regards,
Klaus


From lewisurn at gmail.com  Tue Feb 27 12:59:40 2018
From: lewisurn at gmail.com (Lou Wynn)
Date: Tue, 27 Feb 2018 19:59:40 +0800
Subject: Modernizing Web-of-trust for Organizations
In-Reply-To: <20180218095552.xuzi54vemu3ul5gz@adversary.org>
References: <fcda1d3d-686f-7c34-9545-9673be7f4a11@gmail.com>
 <12300523.20180104004058@my_localhost_LG>
 <d1782a47-7888-aa88-ab35-a6a8e0e17110@gmail.com>
 <20180104222818.dolhf4py76c7qchl@adversary.org>
 <f7c84f6f-0d68-9233-bd3a-71e22fa4dc61@gmail.com>
 <20180218095552.xuzi54vemu3ul5gz@adversary.org>
Message-ID: <e92f7dda-234d-b3e7-e678-b89bda8b5a35@gmail.com>

On 02/18/2018 05:55 PM, Ben McGinnes wrote:
> So you took a system built from the outset on a security model founded
> entirely on public key exchanges between distributed and federated
> (both self-determining and self-governing) nodes ... and then spent a
> considerable amount of time and effort making that system centralised
> in order to meet certain types of common business use cases ...
>
> ... with a software package which ships with a complete implementation
> of S/MIME as well ...
No, there is no S/MIME implementation because the PKI model it relies on
is inherently precarious for enterprise usage because of using
third-party certificates. Once a 3rd party CA is trusted, all users it
certified becomes trusted while those users have no business
relationship with the enterprise.

> Hmm ...
>
> Okay, I just have one question:
>
> *Why?!*
The short answer is that neither S/MIME's PKI or OpenPGP's web-of-trust
is suitable for organizational uses in term of defining trusted people
for the organization. In addition, current clients of both require
considerable efforts at the end-user side to configure and use. For a
longer analysis, here is a white paper:
https://www.cs.utah.edu/~luzhao/pub/doc/autonomous-certificate-authority.pdf


Thanks,
Lou

>
>
> Regards,
> Ben



From thomas.jarosch at intra2net.com  Wed Feb 28 10:56:05 2018
From: thomas.jarosch at intra2net.com (Thomas Jarosch)
Date: Wed, 28 Feb 2018 10:56:05 +0100
Subject: gpgsm --gen-key with key on smartcard
Message-ID: <1784563.ycYbank3zz@storm.m.i2n>

Hello together,

gpgsm can be used to create X.509 certificates
for existing secret keys on a openpgp smartcard.


"gpg2 --card-status" looks like this:
*********************************************
..
Signature key ....: E642 8DAC 275A 3247 5B59  A16F A3E9 1268 663A 9918
      created ....: 2018-02-27 23:04:28
Encryption key....: 7BD4 D616 869A DABA 40EE  92CE 0B7C A078 D0C4 D69E
      created ....: 2018-02-27 23:04:28
Authentication key: 7DA6 B4FD 7E63 CA74 4BDC  CE17 A006 6D00 9AD9 3260
      created ....: 2018-02-27 23:04:28
sec>  rsa2048/A3E91268663A9918  created: 2018-02-27  expires: never
                                card-no: 0005 00003E6D
ssb>  rsa2048/A0066D009AD93260  created: 2018-02-27  expires: never
                                card-no: 0005 00003E6D
ssb>  rsa2048/0B7CA078D0C4D69E  created: 2018-02-27  expires: never
                                card-no: 0005 00003E6
*********************************************


When invoking

    gpgsm --armor --output public.pem --gen-key

one can choose (3) to use an existing key on a smartcard.

The next menu present is this:

*********************************************
Available keys:
   (1) C9CD95DDF9B6430274F55168DE39877474DA66EE OPENPGP.1
   (2) 9D81DD6BD19C9C13F9B03915344BCC6BBDFB8428 OPENPGP.2
   (3) 24983DADCC9C49692D6BB30675967DD4B003957D OPENPGP.3
*********************************************

To me it seems it shows the 'keygrip' instead of the smartcard key IDs?


Debug output from gpgsm before the "available keys" prompt:
*********************************************
gpgsm: DBG: chan_5 <- S KEY-FPR 1 E6428DAC275A32475B59A16FA3E91268663A9918
gpgsm: DBG: chan_5 <- S KEY-FPR 2 7BD4D616869ADABA40EE92CE0B7CA078D0C4D69E
gpgsm: DBG: chan_5 <- S KEY-FPR 3 7DA6B4FD7E63CA744BDCCE17A0066D009AD93260
gpgsm: DBG: chan_5 <- S KEY-TIME 1 1519772668
gpgsm: DBG: chan_5 <- S KEY-TIME 2 1519772668
gpgsm: DBG: chan_5 <- S KEY-TIME 3 1519772668
gpgsm: DBG: chan_5 <- S CHV-STATUS +0+32+32+32+3+0+3
gpgsm: DBG: chan_5 <- S SIG-COUNTER 4
gpgsm: DBG: chan_5 <- S KEYPAIRINFO C9CD95DDF9B6430274F55168DE39877474DA66EE OPENPGP.1
gpgsm: DBG: chan_5 <- S KEYPAIRINFO 9D81DD6BD19C9C13F9B03915344BCC6BBDFB8428 OPENPGP.2
gpgsm: DBG: chan_5 <- S KEYPAIRINFO 24983DADCC9C49692D6BB30675967DD4B003957D OPENPGP.3
gpgsm: DBG: chan_5 <- OK
*********************************************

I guessed which key is the correct one from the gnupg 2.2.4 debug output.


When using a smartcard, what about showing the openpgp key IDs
in the "Available keys" menu?

Cheers,
Thomas





From dirk.gottschalk1980 at googlemail.com  Wed Feb 28 12:55:48 2018
From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk)
Date: Wed, 28 Feb 2018 12:55:48 +0100
Subject: gpgsm --gen-key with key on smartcard
In-Reply-To: <1784563.ycYbank3zz@storm.m.i2n>
References: <1784563.ycYbank3zz@storm.m.i2n>
Message-ID: <1519818948.14927.2.camel@googlemail.com>

Hi.

Am Mittwoch, den 28.02.2018, 10:56 +0100 schrieb Thomas Jarosch:
> To me it seems it shows the 'keygrip' instead of the smartcard key
> IDs?

Yes, that's correct.


> When using a smartcard, what about showing the openpgp key IDs
> in the "Available keys" menu?

I think this is not neccessary, since you can see the keygrip using
"gpg2 -K --with-Keygrip".

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/20180228/c6557398/attachment.sig>

From peter at digitalbrains.com  Wed Feb 28 13:22:23 2018
From: peter at digitalbrains.com (Peter Lebbing)
Date: Wed, 28 Feb 2018 13:22:23 +0100
Subject: gpgsm --gen-key with key on smartcard
In-Reply-To: <1784563.ycYbank3zz@storm.m.i2n>
References: <1784563.ycYbank3zz@storm.m.i2n>
Message-ID: <45726baf-95ea-3a4a-75d9-c7d5a5cc3170@digitalbrains.com>

On 28/02/18 10:56, Thomas Jarosch wrote:
> When using a smartcard, what about showing the openpgp key IDs
> in the "Available keys" menu?

I don't think that's possible: keygrips are "protocol" agnostic, but key
IDs are not. So while the keygrip is the same for S/MIME and OpenPGP,
key ID's are inherently an OpenPGP thing. It doesn't make sense to
select a "key ID" for an S/MIME key. That's what I mean by protocol here.

My suggestion would be that

$ gpg --with-keygrip --card-status

would include keygrips in the output (it doesn't do that currently).

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/20180228/eda53688/attachment.sig>

From wk at gnupg.org  Wed Feb 28 14:50:39 2018
From: wk at gnupg.org (Werner Koch)
Date: Wed, 28 Feb 2018 14:50:39 +0100
Subject: gpgsm --gen-key with key on smartcard
In-Reply-To: <1784563.ycYbank3zz@storm.m.i2n> (Thomas Jarosch's message of
 "Wed, 28 Feb 2018 10:56:05 +0100")
References: <1784563.ycYbank3zz@storm.m.i2n>
Message-ID: <87tvu1te8g.fsf@wheatstone.g10code.de>

On Wed, 28 Feb 2018 10:56, thomas.jarosch at intra2net.com said:

> When using a smartcard, what about showing the openpgp key IDs
> in the "Available keys" menu?

gpgsm does and shall not know anything about OpenPGP.  Thus it can't
display OpenPGP information.  In theory we could display the fingerprint
of the OpenPGP card because they are stored along with the key on the
OpenPGP card - however, that would only work for the OpenPGP card and
not for any other card which is supported by gpgsm.

If you need this information a small tool to present an enhanced menu
could be written.  That tool would then utilize gpgsm and gpg.  GPA
might be a candidate to implement this.


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/20180228/a58ef48d/attachment-0001.sig>

From wk at gnupg.org  Wed Feb 28 15:02:58 2018
From: wk at gnupg.org (Werner Koch)
Date: Wed, 28 Feb 2018 15:02:58 +0100
Subject: Use the same passphrase for PGP and SSH keys and get prompted
 only once by gpg-agent
In-Reply-To: <20180221062734.4riam3btaqgpkrl5@adversary.org> (Ben McGinnes's
 message of "Wed, 21 Feb 2018 17:27:34 +1100")
References: <874lmqs3bn.fsf@gmail.com> <87a7wdxcd7.fsf@wheatstone.g10code.de>
 <87o9ktm1gg.fsf@gmail.com> <87r2pox4t4.fsf@wheatstone.g10code.de>
 <20180221062734.4riam3btaqgpkrl5@adversary.org>
Message-ID: <87po4ptdnx.fsf@wheatstone.g10code.de>

On Wed, 21 Feb 2018 07:27, ben at adversary.org said:

>> No, there is no way to configure an extra hack to also test a passphrase
>> for an ssh key.
>
> Wanna bet?

Oh no, I don't want to promote create solutions of our complex API ;-)


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/20180228/9e2f695b/attachment.sig>

From wk at gnupg.org  Wed Feb 28 15:06:40 2018
From: wk at gnupg.org (Werner Koch)
Date: Wed, 28 Feb 2018 15:06:40 +0100
Subject: initramfs - gpg decryption failed invalid IPC response
In-Reply-To: <8c08b400-b2c6-9459-2dc2-a7e0c2dc9691@davidlasek.eu> (D.'s
 message of "Wed, 31 Jan 2018 22:25:50 +0100")
References: <8c08b400-b2c6-9459-2dc2-a7e0c2dc9691@davidlasek.eu>
Message-ID: <87lgfdtdhr.fsf@wheatstone.g10code.de>

On Wed, 31 Jan 2018 22:25, mail at davidlasek.eu said:

> ??? gpg (GnuPG) 2.2.4
> ??? libgcrypt 1.8.2
> And prints:
>
>    gpg: encrypted with <bit-length> RSA key, ID <key id>. created
>    <date> <owner name + email>
>
>    gpg: public key decryption failed: Invalid IPC response
>
>    gpg: decryption failed: No secret key

Can you please add 

  --verbose --debug=ipc

to the gpg invocation?  This will show the IPC and thus the invalid IPC
response.


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/20180228/9fa0298c/attachment.sig>

From wk at gnupg.org  Wed Feb 28 15:22:47 2018
From: wk at gnupg.org (Werner Koch)
Date: Wed, 28 Feb 2018 15:22:47 +0100
Subject: entropy gathering daemon
In-Reply-To: <f06df1b1-cf8a-506b-9f1b-fe14cffe584b@pettijohn-web.com> (Edgar
 Pettijohn's message of "Sun, 4 Feb 2018 01:44:36 -0600")
References: <f06df1b1-cf8a-506b-9f1b-fe14cffe584b@pettijohn-web.com>
Message-ID: <87h8q1tcqw.fsf@wheatstone.g10code.de>

On Sun,  4 Feb 2018 08:44, edgar at pettijohn-web.com said:

> Is it no longer possible to use egd? Most of the info I can find seems

If Libgcrypt has been configured with EGD support this should still
work.  I have not tested it for more than a decade, though.

Why do you want to use it?  Which OS does not support /dev/random and
why don't you want to use the fallback rndunix driver in Libgcrypt.


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/20180228/2b968d28/attachment.sig>

From wk at gnupg.org  Wed Feb 28 15:27:18 2018
From: wk at gnupg.org (Werner Koch)
Date: Wed, 28 Feb 2018 15:27:18 +0100
Subject: Not enough information to check signature validity
In-Reply-To: <E1ek88Y-0005hD-8j@wheatstone.g10code.de> (Marshall D. Abrams's
 message of "Wed, 07 Feb 2018 17:59:43 -0500")
References: <E1ek88Y-0005hD-8j@wheatstone.g10code.de>
Message-ID: <87d10ptcjd.fsf@wheatstone.g10code.de>

On Wed,  7 Feb 2018 23:59, MarshallAbrams at alumni.cmu.edu said:
> A friends had to re-install gpg4win as a result of a hard disk
> failure. Since then, all encrypted files received from her come with a
> warning "Not enough information to check signature validity." What can

You don't have her public key to to verify the signature of the data.
It is common for OpenPGP to first sign the data and then encrypt this
signed data.  If gpg can't verify the signature after decryption your
frontend (Kleopatra, I guess) shows this message.

> I or she, do to eliminate this message?

You need to import her public key - that is commonly the same key you
use to encrypt data to her.


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/20180228/2316a6de/attachment.sig>

From wk at gnupg.org  Wed Feb 28 15:35:28 2018
From: wk at gnupg.org (Werner Koch)
Date: Wed, 28 Feb 2018 15:35:28 +0100
Subject: Issuing non self-signed certificate without having the private
 key in gpgsm keyring
In-Reply-To: <51c8af636fb2e1202ca1f03d445376dd@free.fr> (Jean-Yves Migeon's
 message of "Fri, 23 Feb 2018 19:21:49 +0100")
References: <51c8af636fb2e1202ca1f03d445376dd@free.fr>
Message-ID: <87606htc5r.fsf@wheatstone.g10code.de>

On Fri, 23 Feb 2018 19:21, jym at NetBSD.org said:

> ATM (with gpgsm (GnuPG) 2.2.4) , due to [1], gpgsm cannot sign
> certificate for which a public key has been imported but without an
> associated private key to it (disregarding the self-signing

What you here is to create CSR (Certifciate Signing Request) for a new
certificate.  This involves a signature done with the private key for
the public key in that CSR.

> gpgsm: line 1: error getting key by keygrip 'D3513A1E...48E0BDB6D35':
> No such file or directory
> gpgsm: error creating certificate request: No such file or directory

You simply don't have that key.  What you enter there is the key grip
For example:

$ gpgsm --with-keygrip -K 0x05B0DC50
           ID: 0x05B0DC50
          S/N: 2A821ECCEBFE1AFF
       Issuer: /CN=The STEED Self-Signing Nonthority
      Subject: /CN=John Steed
          aka: steed at itv.example.org.uk
     validity: 2011-12-06 20:30:46 through 2063-04-05 17:00:00
     key type: 1024 bit RSA
  fingerprint: EC:6E:9C:33:24:6A:6F:04:FC:98:89:9A:5A:25:73:9E:05:B0:DC:50
      keygrip: 254C073ED986EE4EA5F8059A753DAC1FFD245999

If you enter the value in the last line at the prompt, the very same key
would be used for a new certificate.

> Would it make sense to relax the test in [1] and allow certificate
> creation when we are not issuing a self-sign cert?

That would violate the standard for creating a CSR.


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/20180228/d46ad02c/attachment.sig>

From edgar at pettijohn-web.com  Wed Feb 28 15:53:47 2018
From: edgar at pettijohn-web.com (edgar at pettijohn-web.com)
Date: Wed, 28 Feb 2018 08:53:47 -0600
Subject: entropy gathering daemon
Message-ID: <mailman.8.1519829652.30378.gnupg-users@gnupg.org>


On Feb 28, 2018 8:22 AM, Werner Koch <wk at gnupg.org> wrote:
>
> On Sun,? 4 Feb 2018 08:44, edgar at pettijohn-web.com said:
>
> > Is it no longer possible to use egd? Most of the info I can find seems
>
> If Libgcrypt has been configured with EGD support this should still
> work.? I have not tested it for more than a decade, though.
>
> Why do you want to use it?? Which OS does not support /dev/random and
> why don't you want to use the fallback rndunix driver in Libgcrypt.
>
>
> Shalom-Salam,
>
> ?? Werner
>

I overlooked the configure switches. Got it working. The use case is for chroot'd programs that need it on a filesystem mounted nodev. I sent some patches awhile back to add arc4random_buf as the entropy gathering 'device'. Which I've been using with no problems since. And it's a little faster than going through the egd.

Thanks,

Edgar
>
> -- 
> #? Please read:? Daniel Ellsberg - The Doomsday Machine? #
> Die Gedanken sind frei.? Ausnahmen regelt ein Bundesgesetz.

From thomas.jarosch at intra2net.com  Wed Feb 28 15:54:16 2018
From: thomas.jarosch at intra2net.com (Thomas Jarosch)
Date: Wed, 28 Feb 2018 15:54:16 +0100
Subject: gnupg SmartCard V3.3
In-Reply-To: <59F022CF-521C-4A8B-9DA5-F0D5158BB312@glsys.de>
References: <8885CA3E-2148-4171-A181-F5C762FE5DDB@glsys.de>
 <59F022CF-521C-4A8B-9DA5-F0D5158BB312@glsys.de>
Message-ID: <126657395.ZGOMOKWQeO@storm.m.i2n>

Hello Klaus,

On Tuesday, 27 February 2018 01:04:27 CET Klaus R?mer wrote:
> i bought two V3.3 cards, but can`t get them to work ?
> the keytocard command does not move the key but copy it and further on the
> gpg2 --card-status -> fetch followed by gpg2 --card-status does not create
> the stub keys, so gpg2 --list-secret-keys does not show any keys ... I have
> the same (rsa4096) sub-key loaded to each slot 1,2,3 eg SEA and card-status
> does show them ? gpg2 --version is 2.1.11
> 
> 
> I did further tests by calling gpg2 ?card-edit -> generate with keylength
> 2048 and 4096 which fail with ?card-error?
> 
> Tried gpg (GnuPG/MacGPG2) 2.2.3
> on a completely different machine (mac)
> 
> Tried the other card (i bought two with consecutive serial numbers)
> 
> Tried three different card-reader:
> - Cherry GmbH SmartBoard XX44
> -  KOBIL EMV CAP - SecOVID Reader III
> - Alcor Micro AU9540 00 00
> 
> Can anybody help?

I just tested an openpgp card V3.3 with a Cherry ST-2000 card reader
and a Reiner cyberJack Go. It successfully created keys on the card
and after a "factory-reset" command it also moved an existing key
to the card just fine. Signing and decryption worked, too.

Same thing with a V2.1 openpgp card.

All tests have been done on a Fedora 27 live USB stick
using gnupg 2.2.4.

May be try on a non-Mac computer to see if this is the issue?


If you want to give the Fedora 27 live CD a try, it might be good
to update the included gnupg 2.2.0 to 2.2.4 before starting:

  dnf update -y gnupg2 libassuan libgcrypt libgpg-error


Optionally: If you want "paperbackup" on the live system:

  dnf install -y git python3 python3-pillow PyX python3-qrencode enscript ghostscript zbar
  git clone https://github.com/intra2net/paperbackup.git

  See https://github.com/intra2net/paperbackup


With the Fedora live CD, all operations are done on a ramdisk.
Just remember to unplug the network cable once
you start the key generation process :)

HTH,
Thomas

--
Don't send emails here: jefferson at intra2net.com





From wk at gnupg.org  Wed Feb 28 15:49:44 2018
From: wk at gnupg.org (Werner Koch)
Date: Wed, 28 Feb 2018 15:49:44 +0100
Subject: Configuration for offline usage - best practice tips?
In-Reply-To: <20180223220820.GA28155@unser.net> (Juergen Christoffel's message
 of "Fri, 23 Feb 2018 23:08:20 +0100")
References: <20180215203305.GA21779@unser.net>
 <87d113lypu.fsf@fifthhorseman.net> <20180223220820.GA28155@unser.net>
Message-ID: <871sh5tbhz.fsf@wheatstone.g10code.de>

On Fri, 23 Feb 2018 23:08, jc.gnupg18a at unser.net said:

> Yes, that's what I plan to do, generate a subkey for each month in advance
> and use this to encrypt my backups.

That raises the question for us whether it will make sense to change

  --quick-add-key fpr [algo [usage [expire]]]

to add new parameter "creationdate" to make it easier to create keys for
future periods.  The parameter controlled batch key generation already
allows for this.

Background: gpg will not consider a future encryption subkey so that
keys for the next period can instantly be distributed.

> these keys. That is, if I have to restore certain files from a backup, and
> the machine where the decryption happens might be compromised, I don't want
> all backups to be compromised in a single step. 

You may also want to look into gpg-agent remote feature which is
designed to protect your private key during restore operations.  Here is
an older description:

<https://blog.flameeyes.eu/2016/10/gnupg-agent-forwarding-with-openpgp-cards/>

You don't need to use smartcards and the extra socket is meanwhile by
default configured.


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/20180228/2cf98413/attachment.sig>

From wk at gnupg.org  Wed Feb 28 15:56:47 2018
From: wk at gnupg.org (Werner Koch)
Date: Wed, 28 Feb 2018 15:56:47 +0100
Subject: Fwd: gnupg SmartCard V3.3
In-Reply-To: <59F022CF-521C-4A8B-9DA5-F0D5158BB312@glsys.de> ("Klaus
 =?utf-8?Q?R=C3=B6mer=22's?=
 message of "Tue, 27 Feb 2018 01:04:27 +0100")
References: <8885CA3E-2148-4171-A181-F5C762FE5DDB@glsys.de>
 <59F022CF-521C-4A8B-9DA5-F0D5158BB312@glsys.de>
Message-ID: <87woyxrwls.fsf@wheatstone.g10code.de>

On Tue, 27 Feb 2018 01:04, kr at glsys.de said:

> gpg2 --version is 2.1.11

That is a pretty old an somewhat buggy version which will likely have
problems with newer smartcards.

> Tried gpg (GnuPG/MacGPG2) 2.2.3
> on a completely different machine (mac)

That version is recent enough and as long as macOS is properly
configured for the card it will work.  You maywant to ask over at
gpgtools.org, though.

> Tried three different card-reader:
> - Cherry GmbH SmartBoard XX44

IIRC that is the old Omnikey reader based keyboard.  I have one myself.
It does not work with 2048 bit keys unless you use their Windows driver.

> -  KOBIL EMV CAP - SecOVID Reader III

I am not sure which reader this is, I had to dump my Kobil reader a logn
time ago wehn I moved to 2048 bit keys.  The problem is slightly
different than with Omnicard keys but I can't remember the details.

> - Alcor Micro AU9540 00 00

I am not sure about them.  Quite some time ago they simply did not worked.

@gniibe: Do you have any more up to date information on macOS and
smartcard readers?


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/20180228/e7fa42da/attachment-0001.sig>

From wk at gnupg.org  Wed Feb 28 16:14:42 2018
From: wk at gnupg.org (Werner Koch)
Date: Wed, 28 Feb 2018 16:14:42 +0100
Subject: entropy gathering daemon
In-Reply-To: <E1er38O-0008UR-MR@wheatstone.g10code.de>
 (edgar@pettijohn-web.com's message of "Wed, 28 Feb 2018 08:53:47
 -0600")
References: <E1er38O-0008UR-MR@wheatstone.g10code.de>
Message-ID: <87sh9lrvrx.fsf@wheatstone.g10code.de>

On Wed, 28 Feb 2018 15:53, edgar at pettijohn-web.com said:

> for chroot'd programs that need it on a filesystem mounted nodev. I
> sent some patches awhile back to add arc4random_buf as the entropy
> gathering 'device'. Which I've been using with no problems since. And

In case you have a problem with scarce entropy you may want to add

only-urandom

to /etc/gcrypt/random.conf - in almost all cases this okay for all
libgcrypt users.


Salam-Shalom,

   Werner

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

From thomas.jarosch at intra2net.com  Wed Feb 28 16:30:13 2018
From: thomas.jarosch at intra2net.com (Thomas Jarosch)
Date: Wed, 28 Feb 2018 16:30:13 +0100
Subject: gpgsm --gen-key with key on smartcard
In-Reply-To: <87tvu1te8g.fsf@wheatstone.g10code.de>
References: <1784563.ycYbank3zz@storm.m.i2n>
 <87tvu1te8g.fsf@wheatstone.g10code.de>
Message-ID: <3184488.u4he08tPDS@storm.m.i2n>

On Wednesday, 28 February 2018 14:50:39 CET Werner Koch wrote:
> If you need this information a small tool to present an enhanced menu
> could be written.  That tool would then utilize gpgsm and gpg.  GPA
> might be a candidate to implement this.

what do you think about Peter's idea:

$ gpg --with-keygrip --card-status


to show key ID -> keygrip mapping?

Or is that not easily possible protocol wise?
(I have zero knowledge about the keygrip stuff)

Cheers,
Thomas





From andrewg at andrewg.com  Wed Feb 28 18:57:36 2018
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Wed, 28 Feb 2018 17:57:36 +0000
Subject: gpgsm as a CA
Message-ID: <b69b8854-0cfa-69a0-c7b2-8b6870e15a73@andrewg.com>

Hi, all.

Is there any support for using gpgsm as a certificate authority?

-- 
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/20180228/a68a3db7/attachment.sig>

From wk at gnupg.org  Wed Feb 28 20:59:59 2018
From: wk at gnupg.org (Werner Koch)
Date: Wed, 28 Feb 2018 20:59:59 +0100
Subject: gpgsm --gen-key with key on smartcard
In-Reply-To: <3184488.u4he08tPDS@storm.m.i2n> (Thomas Jarosch's message of
 "Wed, 28 Feb 2018 16:30:13 +0100")
References: <1784563.ycYbank3zz@storm.m.i2n>
 <87tvu1te8g.fsf@wheatstone.g10code.de>
 <3184488.u4he08tPDS@storm.m.i2n>
Message-ID: <87o9k8q400.fsf@wheatstone.g10code.de>

On Wed, 28 Feb 2018 16:30, thomas.jarosch at intra2net.com said:

> what do you think about Peter's idea:
>
> $ gpg --with-keygrip --card-status

If you use that with --with-colons you can also script this.

But that is about gpg and not about gpgsm.  gpgsm has no external card
interface because the expected use case is that pre-presonalized cards
are used for X.509.


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/20180228/c1b59967/attachment.sig>

From jym at NetBSD.org  Wed Feb 28 21:10:45 2018
From: jym at NetBSD.org (Jean-Yves Migeon)
Date: Wed, 28 Feb 2018 21:10:45 +0100
Subject: gpgsm as a CA
In-Reply-To: <b69b8854-0cfa-69a0-c7b2-8b6870e15a73@andrewg.com>
References: <b69b8854-0cfa-69a0-c7b2-8b6870e15a73@andrewg.com>
Message-ID: <b6b85bbe-902d-bcb5-3093-9274879fe1c6@NetBSD.org>

> Hi, all.
> 
> Is there any support for using gpgsm as a certificate authority?

Hi,

FWIW I have put up a guide recently on how I achieved this with gpgsm +
an OpenPGP card for private key handling. You can drop the card thing if
you don't intend using and keep the private key instead.

https://github.com/jymigeon/gpgsm-as-ca

It is still a bit rough, I expect to expand it a bit in a few days.

All certificates I issue through this method work with the openssl
stacks we have around, so it is working from my PoV.

Did not investigate how to handle the CRL part though, and the X.509
extensions need a bit more work to be user-friendly, but you can safely
figure this out via openssl asn1parse.

-- 
Jean-Yves Migeon



From jym at NetBSD.org  Wed Feb 28 18:05:05 2018
From: jym at NetBSD.org (Jean-Yves Migeon)
Date: Wed, 28 Feb 2018 18:05:05 +0100
Subject: Issuing non self-signed certificate without having the private
 key in gpgsm keyring
In-Reply-To: <87606htc5r.fsf@wheatstone.g10code.de>
References: <51c8af636fb2e1202ca1f03d445376dd@free.fr>
 <87606htc5r.fsf@wheatstone.g10code.de>
Message-ID: <3abd8bab15bb8dacbb889d84ba96dcf2@NetBSD.org>

Le 2018-02-28 15:35, Werner Koch a ?crit?:
> On Fri, 23 Feb 2018 19:21, jym at NetBSD.org said:
> 
>> ATM (with gpgsm (GnuPG) 2.2.4) , due to [1], gpgsm cannot sign
>> certificate for which a public key has been imported but without an
>> associated private key to it (disregarding the self-signing
> 
> What you here is to create CSR (Certifciate Signing Request) for a new
> certificate.  This involves a signature done with the private key for
> the public key in that CSR.
> 
>> gpgsm: line 1: error getting key by keygrip 'D3513A1E...48E0BDB6D35':
>> No such file or directory
>> gpgsm: error creating certificate request: No such file or directory
> 
> You simply don't have that key.  What you enter there is the key grip
> For example:
> 
> [snip]
> 
> If you enter the value in the last line at the prompt, the very same 
> key
> would be used for a new certificate.

Hi Werner,

Thanks for taking the time to answer.

>> Would it make sense to relax the test in [1] and allow certificate
>> creation when we are not issuing a self-sign cert?
> 
> That would violate the standard for creating a CSR.

Indeed. But that is not what I am asking.

I am actually attempting to have the CSR <> certificate issuance done in 
two different steps.

In some PKI setups, the CSR gets signed by the requesting entity and 
sent over to the CA. The CA then performs all kind of checks, including 
signature (through the pub provided in the CSR), then CA issues a 
certificate signed with its own private key which is then sent back to 
the requesting entity.

ATM --gen-key can issue CSR and issue self-signing certificates, but in 
addition it can generate non self-signed cert in batch mode when 
"Key-Grip" and "Signing-Key" are different (Key-Grip corresponding to 
the entity, whereas Signing-Key is the key-grip of the CA).

However the check performed in [1] does not offer this possibility 
trivially because it will check the presence of the "Key-Grip" entity 
private key, which is technically not needed there and may be absent. 
The CSR can have been generated elsewhere, and only the entity public 
key has been imported inside keyring (via a PEM file for example).

Thanks,

-- 
Jean-Yves Migeon


From wk at gnupg.org  Wed Feb 28 21:08:18 2018
From: wk at gnupg.org (Werner Koch)
Date: Wed, 28 Feb 2018 21:08:18 +0100
Subject: gpgsm as a CA
In-Reply-To: <b69b8854-0cfa-69a0-c7b2-8b6870e15a73@andrewg.com> (Andrew
 Gallagher's message of "Wed, 28 Feb 2018 17:57:36 +0000")
References: <b69b8854-0cfa-69a0-c7b2-8b6870e15a73@andrewg.com>
Message-ID: <87k1uwq3m5.fsf@wheatstone.g10code.de>

On Wed, 28 Feb 2018 18:57, andrewg at andrewg.com said:

> Is there any support for using gpgsm as a certificate authority?

There is some basic support to create certificates:

   The format of the parameter file is described in the manual under
   "Unattended Usage".

   [...]

   This parameter file was used to create the STEED CA:
     Key-Type: RSA
     Key-Length: 1024
     Key-Grip: 68A638998DFABAC510EA645CE34F9686B2EDF7EA
     Key-Usage: cert
     Serial: 1
     Name-DN: CN=The STEED Self-Signing Nonthority
     Not-Before: 2011-11-11
     Not-After: 2106-02-06
     Subject-Key-Id: 68A638998DFABAC510EA645CE34F9686B2EDF7EA
     Extension: 2.5.29.19 c 30060101ff020101
     Extension: 1.3.6.1.4.1.11591.2.2.2 n 0101ff
     Signing-Key: 68A638998DFABAC510EA645CE34F9686B2EDF7EA
     %commit

Here a Root CA certificate is created.  However, the Signing-Key
parameter is a generic feature and thus it can also be used to let this
CA sign another key.  What's missing in gpgsm are a parser for the CSR
and code to filter the values of a CSR into a new certificate.  The
parser can be quite easily added the other stuff needs some thinking.


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/20180228/b2b0d877/attachment.sig>