From wk at gnupg.org  Fri Nov  1 11:19:30 2019
From: wk at gnupg.org (Werner Koch)
Date: Fri, 01 Nov 2019 11:19:30 +0100
Subject: Question about symmetric AES cipher in GnuPG
In-Reply-To: <0b687218-2c60-c9a3-09d4-8677a7ca405d@minton.name> (Brian
 Minton's message of "Wed, 30 Oct 2019 17:19:51 -0400")
References: <20191027202510.000077ee.sac@300baud.de>
 <0b687218-2c60-c9a3-09d4-8677a7ca405d@minton.name>
Message-ID: <877e4j99vx.fsf@wheatstone.g10code.de>

On Wed, 30 Oct 2019 17:19, Brian Minton said:

> My guess is, the gpg one also is doing MDC, so you'd have to add the
> equivalent HMAC code to openssl, but that's just a complete guess.??

The OpenPGP MDC is a SHA-1 hash appended to the plaintext and then
encrypted along with the data.  The usual OpenPGP packet structure is
used; details are in RFC-4880. Further OpenPGP's symmetric encryption
uses a random session key and encrypts that session key using the
passphrase as key.  This allows to have several independent passphrases
or public keys for the same data.

You can't easily implement that with OpenSSL in a script.


Shalom-Salam,

   Werner

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

From mgorny at gentoo.org  Fri Nov  1 19:50:13 2019
From: mgorny at gentoo.org (=?UTF-8?Q?Micha=C5=82_G=C3=B3rny?=)
Date: Fri, 01 Nov 2019 19:50:13 +0100
Subject: Is replacing a revoked signature valid?
Message-ID: <458420cc455ba408a12756c29a1e208cc0376331.camel@gentoo.org>

Hi,

Gentoo recently started signing UIDs on the keys of our developers.
As part of the system, we revoke signatures of developers who resign. 
However, some eventually return and if they return with the same key,
we have a problem.

When I try to sign the key (again), I get the following error:

"[redacted] <xxx at gentoo.org>" was already signed by key XXXX
Nothing to sign with key XXX
gpg: Key not changed so no update needed.


However, the original signature was revoked, so it's obviously no longer
valid.  Now, I am able to work around this by deleting the old
signatures from local copy of the key, and signing it afterwards.  After
refreshing to get the old signature back along with its revocation, GPG
seems to still consider the key valid (wrt new signature).

My question: is the end result correct?  That is, is it portable to have
two signatures made using the same key, with one of them revoked
and the other not?  Is GnuPG refusing to make a new signature when
the old one is revoked a bug?

-- 
Best regards,
Micha? G?rny

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 618 bytes
Desc: This is a digitally signed message part
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20191101/16f1dc60/attachment.sig>

From noreply at informadb.pt  Fri Nov  1 11:43:19 2019
From: noreply at informadb.pt (Informa D&B)
Date: Fri, 1 Nov 2019 10:43:19 +0000 (GMT)
Subject: Question about symmetric AES cipher in GnuPG [
 ref:_00D58dJQM._5004Ius4eD:ref ]
Message-ID: <1xcbS000000000000000000000000000000000000000000000Q0ADS700fEbVCTYdQ52TRWpawTPr2w@sfdc.net>

Exmos. Senhores,

Recebemos a informa??o que tiveram hoje a amabilidade de nos transmitir e que muito agradecemos.

Vamos imediatamente analisar o caso e responderemos com a m?xima brevidade poss?vel ao vosso pedido. Assim que for poss?vel, o Servi?o de Apoio ao Cliente entrar? em contacto convosco.

No entanto, caso o vosso contacto esteja relacionado com a necessidade de atualizar os dados da vossa empresa na nossa base de dados, notem que poder?o faz?-lo diretamente e sem demoras.

De facto, as entidades empresariais cujos dados constem da nossa base de dados podem consultar, acrescentar e modificar on-line as informa??es que lhes digam respeito, sendo para tal apenas necess?rio que disponham de uma senha de acesso exclusivo a uma zona reservada do nosso site.

Sublinhamos que este acesso para atualiza??o on-line ? totalmente gratuito e muito f?cil, bastando entrar em www.informadb.pt e selecionar, em Feed?Back , " Para consultar atualizar os dados de uma empresa diretamente na nossa base de dados".

Se necessitarem de mais esclarecimentos sobre o Feed?Back ? Servi?o de Atualiza??o de Dados, estaremos inteiramente dispon?veis para os prestar.

Atenciosamente,

Servi?o de Apoio ao Cliente

(+351) 213 500 389 - Fax: (+351) 213 151 658
vipclientes at informadb.pt
www.informadb.pt

CONFIDENCIAL. Esta mensagem destina-se a uso exclusivo do(s) destinat?rio(s) e poder? conter informa??o privada ou confidencial. A leitura, reten??o, divulga??o, c?pia, distribui??o ou reencaminhamento s?o pro?bidas. Caso a receba por engano, solicitamos que nos comunique por e-mail e elimine a mensagem do seu sistema sem a reproduzir. Os dados pessoais constantes do presente e-mail est?o ou ser?o adicionados ? lista de contactos da INFORMA D&B, respons?vel pelo tratamento de dados, para o podermos contactar sempre que necess?rio . O direito de acesso, retifica??o, oposi??o e apagamento, dever? ser exercido atrav?s do e-mail: protecaodedados at informadb.pt. Consulte o nosso compromisso de privacidade em www.informadb.pt.

CONFIDENTIAL. This message is intended for the exclusive use of the named addressee(s) and it may contain private or confidential information. Any reading, retention, disclosure, copying, distribution or redirection is prohibited. If you are not the intended recipient, please notify us by e-mail and delete this message from your system without retaining a copy. The personal data included in this e-mail is or will be added to the contact list of INFORMA D&B, acting as data controller, to contact you whenever necessary. You have the right of access and the rights to rectification, to object and to erasure through the e-mail: protecaodedados at informadb.pt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20191101/6fcd6307/attachment-0001.html>

From codeguro at gmail.com  Fri Nov  1 20:42:26 2019
From: codeguro at gmail.com (Tony Lane)
Date: Fri, 1 Nov 2019 15:42:26 -0400
Subject: How to improve our GUIs (was: We have GOT TO make things simpler)
In-Reply-To: <20191030003331.stgm7magl7kpjwul@raf.org>
References: <20191030003331.stgm7magl7kpjwul@raf.org>
Message-ID: <c2fcc25d-7e83-f2bd-b1ac-48e5959c3877@gmail.com>

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

On 10/29/19 8:33 PM, raf via Gnupg-users wrote:
> Hi,
> 
> Sorry if this was mentioned before but I've just come
> across a novel approach to email encryption that
> doesn't do end-to-end encryption, but rather it
> encrypts email upon receipt so that an individual can
> encrypt the email that is stored in their IMAP account
> as it arrives without the need for every sender to
> encrypt and without the need for any service provider's
> involvement

That doesn't sound very safe. My interpretation of the
goals of GPG is two server two purposes:
1) To transmit data securely over an insecure medium in
a way such that it can protect itself against some
eavesdropper or man-in-the-middle listening, or...
(2) Provide a means to create digital signatures on data
such that you can be assured that some message was sent
only by someone who possesses the private key who's
public key you've added.

Your proposal doesn't seem to address the MITM attacks.
It doesn't seem deal with signatures either.
It seems only to encrypt things only on receipt. What
does that protect against, exactly? Maybe I'm missing
something here...
-----BEGIN PGP SIGNATURE-----

iLgEARMKAB0WIQQWZv6JZKxO310TWtXo8fj9gx4T0wUCXbyKogAKCRDo8fj9gx4T
06a/AgjETQjTvlCkOeKWIqOrkcHQmNhbWtV1RYM3IbOoj6wddB3KPClw8aglVXMg
BEockH7nPuYT1rxxDhG8+llq9uXiEgIJAUsF0cCZbxparDbfzkTCb32opFdCIqb6
X95rfCCbaE/luNCTUR9B0+VVNdfUn4dcNkTSx8W6svJvjNB6RSwGm1wg
=MZCl
-----END PGP SIGNATURE-----


From codeguro at gmail.com  Fri Nov  1 20:53:31 2019
From: codeguro at gmail.com (Tony Lane)
Date: Fri, 1 Nov 2019 15:53:31 -0400
Subject: Is replacing a revoked signature valid?
In-Reply-To: <458420cc455ba408a12756c29a1e208cc0376331.camel@gentoo.org>
References: <458420cc455ba408a12756c29a1e208cc0376331.camel@gentoo.org>
Message-ID: <866360b3-2f65-c2fd-f38f-2318dbaeab6d@gmail.com>

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

On 11/1/19 2:50 PM, Micha? G?rny via Gnupg-users wrote:
> However, the original signature was revoked, so it's obviously no longer
> valid.  Now, I am able to work around this by deleting the old
> signatures from local copy of the key, and signing it afterwards.  After
> refreshing to get the old signature back along with its revocation, GPG
> seems to still consider the key valid (wrt new signature).
> 
> My question: is the end result correct?  That is, is it portable to have
> two signatures made using the same key, with one of them revoked
> and the other not?  Is GnuPG refusing to make a new signature when
> the old one is revoked a bug?

The result is correct. When you revoke a signature, your exported signatures
will have the revocation of that key/signature. So it makes no sense to
sign it twice. You are better off instead cleaning your key such that the
the revoked key(s) and any other IDs no longer usable (expired, for instance)
are removed entirely. This will allow you to sign them "afresh" again.
See https://gnupg.org/documentation/manuals/gnupg/OpenPGP-Key-Management.html#index-keyedit_003aclean
-----BEGIN PGP SIGNATURE-----

iLcEARMKAB0WIQQWZv6JZKxO310TWtXo8fj9gx4T0wUCXbyNOwAKCRDo8fj9gx4T
03IcAgjyNu7eUJmqzxqJITp0vPf3mxPJ2OFU7J1zYUoiL+P3/dCaIbG8RL2JPkXG
6JDknzfJa6f3x+Jq/nwTNiMxS+q6DQIIhCthVJWCFW7wqwZ6jU3D1YxXW3QyqxSa
970UJrUYquhH/ZBGEZcJybUWEGKl3J8x5qYhlc5rzzSMR6D4jawNJI4=
=o9wv
-----END PGP SIGNATURE-----


From sheogorath at shivering-isles.com  Fri Nov  1 22:06:12 2019
From: sheogorath at shivering-isles.com (Sheogorath)
Date: Fri, 01 Nov 2019 22:06:12 +0100
Subject: How to improve our GUIs (was: We have GOT TO make things simpler)
In-Reply-To: <c2fcc25d-7e83-f2bd-b1ac-48e5959c3877@gmail.com>
References: <20191030003331.stgm7magl7kpjwul@raf.org>
 <c2fcc25d-7e83-f2bd-b1ac-48e5959c3877@gmail.com>
Message-ID: <d41cec42efd94cf68e7112bc6f4cbe7c2e240fdc.camel@shivering-isles.com>

On Fri, 2019-11-01 at 15:42 -0400, Tony Lane via Gnupg-users wrote:
> On 10/29/19 8:33 PM, raf via Gnupg-users wrote:
> > Hi,
> > 
> > Sorry if this was mentioned before but I've just come
> > across a novel approach to email encryption that
> > doesn't do end-to-end encryption, but rather it
> > encrypts email upon receipt so that an individual can
> > encrypt the email that is stored in their IMAP account
> > as it arrives without the need for every sender to
> > encrypt and without the need for any service provider's
> > involvement
> 
> That doesn't sound very safe. My interpretation of the
> goals of GPG is two server two purposes:
> 1) To transmit data securely over an insecure medium in
> a way such that it can protect itself against some
> eavesdropper or man-in-the-middle listening, or...
> (2) Provide a means to create digital signatures on data
> such that you can be assured that some message was sent
> only by someone who possesses the private key who's
> public key you've added.
> 
> Your proposal doesn't seem to address the MITM attacks.
> It doesn't seem deal with signatures either.
> It seems only to encrypt things only on receipt. What
> does that protect against, exactly? Maybe I'm missing
> something here...
> 

TL;DR: It's about damage control.

This idea considers the email provider as an entity that the user
trusts in the perspective of not being an intentional eavesdropper. But
it counts in the possiblity that an email provider might gets
compromised and mail content is extracted or existing mails might be
searched. And that's what it tries to protect from.

All this can be achieved by proper rolled out OpenPGP, but we see that
we are not there (yet?). Something quite positive about the idea is the
fact that re-encryption of the emails happens which is something we
might should consider to simplify with gnupg as well.

When there is one problem with OpenPGP encrypted emails, then it's the
fact that we don't re-encrypt them on a regular basis (at least I don't
hear anyone talking about this). Cryptographic functions (or at least
their parameters) are aging rather bad, which means my 10 year old
mails might be easy to crack in 5 years because of whatever found
problem in the algorithm (or parameters used for it) from 10 years ago.

It's a cold storage problem that this approach seems to try to solve,
which is a rather refreshing idea, even when I agree that it has its
own set of problems.

-- 
Signed
Sheogorath

OpenPGP: https://shivering-isles.com/openpgp/0xFCB98C2A3EC6F601.txt
-------------- 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/20191101/cda5e09f/attachment.sig>

From 400thecat at gmx.ch  Sat Nov  2 15:35:06 2019
From: 400thecat at gmx.ch (Fourhundred Thecat)
Date: Sat, 2 Nov 2019 15:35:06 +0100
Subject: encrypt file in batch mode
Message-ID: <9962aeca-c896-7c64-03ef-a61ead1a9ba0@gmx.ch>

Hello,

how can I simply encrypt a file in "batch mode", ie in a script, without
user interaction, without need for the user to type password, without
gpg agent?

Below are the errors that I get when running:

$ gpg --lock-never -e -s -r user at domain.com --output zz zz.gpg

What is the reason why simple operations should not be possible without
gpg-agent ?

gpg: starting migration from earlier GnuPG versions
gpg: failed to start agent '/usr/bin/gpg-agent': No such file or directory
gpg: can't connect to the agent: No such file or directory
gpg: error: GnuPG agent unusable. Please check that a GnuPG agent can be
started.
gpg: migration aborted
gpg: failed to start agent '/usr/bin/gpg-agent': No such file or directory
gpg: can't connect to the agent: No such file or directory
gpg: failed to start agent '/usr/bin/gpg-agent': No such file or directory
gpg: can't connect to the agent: No such file or directory
gpg: keydb_search failed: No agent running
gpg: no default secret key: No agent running
gpg: gpg.conf.gpg: sign+encrypt failed: No agent running

my version: gpg (GnuPG) 2.2.12

thanks,



From codeguro at gmail.com  Sat Nov  2 16:51:36 2019
From: codeguro at gmail.com (Tony Lane)
Date: Sat, 2 Nov 2019 11:51:36 -0400
Subject: encrypt file in batch mode
In-Reply-To: <9962aeca-c896-7c64-03ef-a61ead1a9ba0@gmx.ch>
References: <9962aeca-c896-7c64-03ef-a61ead1a9ba0@gmx.ch>
Message-ID: <18bc863a-b5eb-8f63-7ccf-f104e68b9980@gmail.com>

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

On 11/2/19 10:35 AM, Fourhundred Thecat wrote:
> Hello,
> 
> how can I simply encrypt a file in "batch mode", ie in a script, without
> user interaction, without need for the user to type password, without
> gpg agent?

Assuming you're using gpg 2.2.7 or above...
gpg --batch --yes --passphrase="pw" --pinentry-mode loopback -o zz -esr user at domain.com zz.gpg
This can only be used if only one passphrase is supplied. Obviously, this
is of very questionable security on a multi-user system. Don't use this
option if you can avoid it. Also, unless you add yourself to the list of
recipients, you won't be able to decrypt the file even if you possess
the original unless you hold the private key for user at domain.com
-----BEGIN PGP SIGNATURE-----

iLgEARMKAB0WIQQWZv6JZKxO310TWtXo8fj9gx4T0wUCXb2mCAAKCRDo8fj9gx4T
0/bBAgkBu6q04gPAfuVKNM8aEA3PG67cDV1tBWhv7hLjI0envbtUFdk/s9MCL9/q
Nm7541e7VccYbvhwlY6MneswZPRoA2wCAwewuGZpXfSfc1QZOVr0y6PFLT2jmyvs
bZRLF60efew2LW74tlqZBlOKTcMYsq8vOv8rD8VdDAH2DyaZvZIUFM0q
=gQUz
-----END PGP SIGNATURE-----


From 400thecat at gmx.ch  Sat Nov  2 18:14:53 2019
From: 400thecat at gmx.ch (Fourhundred Thecat)
Date: Sat, 2 Nov 2019 18:14:53 +0100
Subject: encrypt file in batch mode
In-Reply-To: <18bc863a-b5eb-8f63-7ccf-f104e68b9980@gmail.com>
References: <9962aeca-c896-7c64-03ef-a61ead1a9ba0@gmx.ch>
 <18bc863a-b5eb-8f63-7ccf-f104e68b9980@gmail.com>
Message-ID: <451a1aff-d9a4-9baf-f786-db1e3d85ab3d@gmx.ch>

On 02/11/2019 16.51, Tony Lane via Gnupg-users wrote:
> On 11/2/19 10:35 AM, Fourhundred Thecat wrote:
>
>> how can I simply encrypt a file in "batch mode", ie in a script, without
>> user interaction, without need for the user to type password, without
>> gpg agent?
>
> gpg --batch --yes --passphrase="pw" --pinentry-mode loopback -o zz -esr user at domain.com zz.gpg

Unfortunately, this does not work. I get same error as before (pasted
below).

Also, what is the purpose of --passphrase="pw", when I want to encrypt
using public key ?


$ gpg --batch --yes --passphrase="pw" --pinentry-mode loopback -o zz.gpg
-esr user at domain.com zz

gpg: starting migration from earlier GnuPG versions
gpg: failed to start agent '/usr/bin/gpg-agent': No such file or directory
gpg: can't connect to the agent: No such file or directory
gpg: error: GnuPG agent unusable. Please check that a GnuPG agent can be
started.
gpg: migration aborted
gpg: failed to start agent '/usr/bin/gpg-agent': No such file or directory
gpg: can't connect to the agent: No such file or directory
gpg: failed to start agent '/usr/bin/gpg-agent': No such file or directory
gpg: can't connect to the agent: No such file or directory
gpg: keydb_search failed: No agent running
gpg: no default secret key: No agent running
gpg: zz: sign+encrypt failed: No agent running


From mhw at netris.org  Sat Nov  2 18:32:32 2019
From: mhw at netris.org (Mark H Weaver)
Date: Sat, 02 Nov 2019 13:32:32 -0400
Subject: How to decrypt a message while preserving the signature?
Message-ID: <87tv7mp4j8.fsf@netris.org>

Hello,

Does GnuPG provide a mechanism to decrypt an encrypted-and-signed
message in such a way that preserves the original signature, such that
the original signature can be independently verified by an arbitrary
third-party?

     Thanks,
       Mark


From brianc1969 at gmail.com  Sat Nov  2 22:52:14 2019
From: brianc1969 at gmail.com (Brian C)
Date: Sat, 2 Nov 2019 15:52:14 -0600
Subject: encrypt file in batch mode
In-Reply-To: <451a1aff-d9a4-9baf-f786-db1e3d85ab3d@gmx.ch>
References: <9962aeca-c896-7c64-03ef-a61ead1a9ba0@gmx.ch>
 <18bc863a-b5eb-8f63-7ccf-f104e68b9980@gmail.com>
 <451a1aff-d9a4-9baf-f786-db1e3d85ab3d@gmx.ch>
Message-ID: <c7c71a8f-a7d0-7c18-a90a-c060e5384e84@gmail.com>

I can answer why the passphrase is needed: You are using the -s option
which tells gpg to sign the file, which requires your private key.

Brian

On 11/2/19 11:14 AM, Fourhundred Thecat wrote:
> On 02/11/2019 16.51, Tony Lane via Gnupg-users wrote:
>> On 11/2/19 10:35 AM, Fourhundred Thecat wrote:
>>
>>> how can I simply encrypt a file in "batch mode", ie in a script, without
>>> user interaction, without need for the user to type password, without
>>> gpg agent?
>>
>> gpg --batch --yes --passphrase="pw" --pinentry-mode loopback -o zz -esr user at domain.com zz.gpg
> 
> Unfortunately, this does not work. I get same error as before (pasted
> below).
> 
> Also, what is the purpose of --passphrase="pw", when I want to encrypt
> using public key ?
> 
> 
> $ gpg --batch --yes --passphrase="pw" --pinentry-mode loopback -o zz.gpg
> -esr user at domain.com zz
> 
> gpg: starting migration from earlier GnuPG versions
> gpg: failed to start agent '/usr/bin/gpg-agent': No such file or directory
> gpg: can't connect to the agent: No such file or directory
> gpg: error: GnuPG agent unusable. Please check that a GnuPG agent can be
> started.
> gpg: migration aborted
> gpg: failed to start agent '/usr/bin/gpg-agent': No such file or directory
> gpg: can't connect to the agent: No such file or directory
> gpg: failed to start agent '/usr/bin/gpg-agent': No such file or directory
> gpg: can't connect to the agent: No such file or directory
> gpg: keydb_search failed: No agent running
> gpg: no default secret key: No agent running
> gpg: zz: sign+encrypt failed: No agent running
> 
> _______________________________________________
> 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: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20191102/d52bfa4e/attachment.sig>

From noreply at informadb.pt  Fri Nov  1 20:07:06 2019
From: noreply at informadb.pt (Informa D&B)
Date: Fri, 1 Nov 2019 19:07:06 +0000 (GMT)
Subject: Is replacing a revoked signature valid? [
 ref:_00D58dJQM._5004IusDJx:ref ]
Message-ID: <ZUFL0000000000000000000000000000000000000000000000Q0B13U00pj9e3f6eRqajS-ULFZTo9Q@sfdc.net>

Exmos. Senhores,

Recebemos a informa??o que tiveram hoje a amabilidade de nos transmitir e que muito agradecemos.

Vamos imediatamente analisar o caso e responderemos com a m?xima brevidade poss?vel ao vosso pedido. Assim que for poss?vel, o Servi?o de Apoio ao Cliente entrar? em contacto convosco.

No entanto, caso o vosso contacto esteja relacionado com a necessidade de atualizar os dados da vossa empresa na nossa base de dados, notem que poder?o faz?-lo diretamente e sem demoras.

De facto, as entidades empresariais cujos dados constem da nossa base de dados podem consultar, acrescentar e modificar on-line as informa??es que lhes digam respeito, sendo para tal apenas necess?rio que disponham de uma senha de acesso exclusivo a uma zona reservada do nosso site.

Sublinhamos que este acesso para atualiza??o on-line ? totalmente gratuito e muito f?cil, bastando entrar em www.informadb.pt e selecionar, em Feed?Back , " Para consultar atualizar os dados de uma empresa diretamente na nossa base de dados".

Se necessitarem de mais esclarecimentos sobre o Feed?Back ? Servi?o de Atualiza??o de Dados, estaremos inteiramente dispon?veis para os prestar.

Atenciosamente,

Servi?o de Apoio ao Cliente

(+351) 213 500 389 - Fax: (+351) 213 151 658
vipclientes at informadb.pt
www.informadb.pt

CONFIDENCIAL. Esta mensagem destina-se a uso exclusivo do(s) destinat?rio(s) e poder? conter informa??o privada ou confidencial. A leitura, reten??o, divulga??o, c?pia, distribui??o ou reencaminhamento s?o pro?bidas. Caso a receba por engano, solicitamos que nos comunique por e-mail e elimine a mensagem do seu sistema sem a reproduzir. Os dados pessoais constantes do presente e-mail est?o ou ser?o adicionados ? lista de contactos da INFORMA D&B, respons?vel pelo tratamento de dados, para o podermos contactar sempre que necess?rio . O direito de acesso, retifica??o, oposi??o e apagamento, dever? ser exercido atrav?s do e-mail: protecaodedados at informadb.pt. Consulte o nosso compromisso de privacidade em www.informadb.pt.

CONFIDENTIAL. This message is intended for the exclusive use of the named addressee(s) and it may contain private or confidential information. Any reading, retention, disclosure, copying, distribution or redirection is prohibited. If you are not the intended recipient, please notify us by e-mail and delete this message from your system without retaining a copy. The personal data included in this e-mail is or will be added to the contact list of INFORMA D&B, acting as data controller, to contact you whenever necessary. You have the right of access and the rights to rectification, to object and to erasure through the e-mail: protecaodedados at informadb.pt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20191101/9a209959/attachment-0001.html>

From noreply at informadb.pt  Fri Nov  1 20:59:15 2019
From: noreply at informadb.pt (Informa D&B)
Date: Fri, 1 Nov 2019 19:59:15 +0000 (GMT)
Subject: Is replacing a revoked signature valid? [
 ref:_00D58dJQM._5004IusDyM:ref ]
Message-ID: <O_q7E000000000000000000000000000000000000000000000Q0B3IR000RMbexfkQgWE-RyZIYQxzA@sfdc.net>

Exmos. Senhores,

Recebemos a informa??o que tiveram hoje a amabilidade de nos transmitir e que muito agradecemos.

Vamos imediatamente analisar o caso e responderemos com a m?xima brevidade poss?vel ao vosso pedido. Assim que for poss?vel, o Servi?o de Apoio ao Cliente entrar? em contacto convosco.

No entanto, caso o vosso contacto esteja relacionado com a necessidade de atualizar os dados da vossa empresa na nossa base de dados, notem que poder?o faz?-lo diretamente e sem demoras.

De facto, as entidades empresariais cujos dados constem da nossa base de dados podem consultar, acrescentar e modificar on-line as informa??es que lhes digam respeito, sendo para tal apenas necess?rio que disponham de uma senha de acesso exclusivo a uma zona reservada do nosso site.

Sublinhamos que este acesso para atualiza??o on-line ? totalmente gratuito e muito f?cil, bastando entrar em www.informadb.pt e selecionar, em Feed?Back , " Para consultar atualizar os dados de uma empresa diretamente na nossa base de dados".

Se necessitarem de mais esclarecimentos sobre o Feed?Back ? Servi?o de Atualiza??o de Dados, estaremos inteiramente dispon?veis para os prestar.

Atenciosamente,

Servi?o de Apoio ao Cliente

(+351) 213 500 389 - Fax: (+351) 213 151 658
vipclientes at informadb.pt
www.informadb.pt

CONFIDENCIAL. Esta mensagem destina-se a uso exclusivo do(s) destinat?rio(s) e poder? conter informa??o privada ou confidencial. A leitura, reten??o, divulga??o, c?pia, distribui??o ou reencaminhamento s?o pro?bidas. Caso a receba por engano, solicitamos que nos comunique por e-mail e elimine a mensagem do seu sistema sem a reproduzir. Os dados pessoais constantes do presente e-mail est?o ou ser?o adicionados ? lista de contactos da INFORMA D&B, respons?vel pelo tratamento de dados, para o podermos contactar sempre que necess?rio . O direito de acesso, retifica??o, oposi??o e apagamento, dever? ser exercido atrav?s do e-mail: protecaodedados at informadb.pt. Consulte o nosso compromisso de privacidade em www.informadb.pt.

CONFIDENTIAL. This message is intended for the exclusive use of the named addressee(s) and it may contain private or confidential information. Any reading, retention, disclosure, copying, distribution or redirection is prohibited. If you are not the intended recipient, please notify us by e-mail and delete this message from your system without retaining a copy. The personal data included in this e-mail is or will be added to the contact list of INFORMA D&B, acting as data controller, to contact you whenever necessary. You have the right of access and the rights to rectification, to object and to erasure through the e-mail: protecaodedados at informadb.pt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20191101/466b175f/attachment-0001.html>

From noreply at informadb.pt  Fri Nov  1 20:49:01 2019
From: noreply at informadb.pt (Informa D&B)
Date: Fri, 1 Nov 2019 19:49:01 +0000 (GMT)
Subject: How to improve our GUIs (was: We have GOT TO make things
 simpler) [ ref:_00D58dJQM._5004IusDq8:ref ]
Message-ID: <RLMW5000000000000000000000000000000000000000000000Q0B31P00b__drC0ISFm1WFGl2xgYYg@sfdc.net>

Exmos. Senhores,

Recebemos a informa??o que tiveram hoje a amabilidade de nos transmitir e que muito agradecemos.

Vamos imediatamente analisar o caso e responderemos com a m?xima brevidade poss?vel ao vosso pedido. Assim que for poss?vel, o Servi?o de Apoio ao Cliente entrar? em contacto convosco.

No entanto, caso o vosso contacto esteja relacionado com a necessidade de atualizar os dados da vossa empresa na nossa base de dados, notem que poder?o faz?-lo diretamente e sem demoras.

De facto, as entidades empresariais cujos dados constem da nossa base de dados podem consultar, acrescentar e modificar on-line as informa??es que lhes digam respeito, sendo para tal apenas necess?rio que disponham de uma senha de acesso exclusivo a uma zona reservada do nosso site.

Sublinhamos que este acesso para atualiza??o on-line ? totalmente gratuito e muito f?cil, bastando entrar em www.informadb.pt e selecionar, em Feed?Back , " Para consultar atualizar os dados de uma empresa diretamente na nossa base de dados".

Se necessitarem de mais esclarecimentos sobre o Feed?Back ? Servi?o de Atualiza??o de Dados, estaremos inteiramente dispon?veis para os prestar.

Atenciosamente,

Servi?o de Apoio ao Cliente

(+351) 213 500 389 - Fax: (+351) 213 151 658
vipclientes at informadb.pt
www.informadb.pt

CONFIDENCIAL. Esta mensagem destina-se a uso exclusivo do(s) destinat?rio(s) e poder? conter informa??o privada ou confidencial. A leitura, reten??o, divulga??o, c?pia, distribui??o ou reencaminhamento s?o pro?bidas. Caso a receba por engano, solicitamos que nos comunique por e-mail e elimine a mensagem do seu sistema sem a reproduzir. Os dados pessoais constantes do presente e-mail est?o ou ser?o adicionados ? lista de contactos da INFORMA D&B, respons?vel pelo tratamento de dados, para o podermos contactar sempre que necess?rio . O direito de acesso, retifica??o, oposi??o e apagamento, dever? ser exercido atrav?s do e-mail: protecaodedados at informadb.pt. Consulte o nosso compromisso de privacidade em www.informadb.pt.

CONFIDENTIAL. This message is intended for the exclusive use of the named addressee(s) and it may contain private or confidential information. Any reading, retention, disclosure, copying, distribution or redirection is prohibited. If you are not the intended recipient, please notify us by e-mail and delete this message from your system without retaining a copy. The personal data included in this e-mail is or will be added to the contact list of INFORMA D&B, acting as data controller, to contact you whenever necessary. You have the right of access and the rights to rectification, to object and to erasure through the e-mail: protecaodedados at informadb.pt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20191101/8930aef9/attachment-0001.html>

From noreply at informadb.pt  Fri Nov  1 22:11:57 2019
From: noreply at informadb.pt (Informa D&B)
Date: Fri, 1 Nov 2019 21:11:57 +0000 (GMT)
Subject: How to improve our GUIs (was: We have GOT TO make things
 simpler) [ ref:_00D58dJQM._5004IusEku:ref ]
Message-ID: <f1jKm000000000000000000000000000000000000000000000Q0B6VX001DIXug-rQyaWYo5xshnhhg@sfdc.net>

Exmos. Senhores,

Recebemos a informa??o que tiveram hoje a amabilidade de nos transmitir e que muito agradecemos.

Vamos imediatamente analisar o caso e responderemos com a m?xima brevidade poss?vel ao vosso pedido. Assim que for poss?vel, o Servi?o de Apoio ao Cliente entrar? em contacto convosco.

No entanto, caso o vosso contacto esteja relacionado com a necessidade de atualizar os dados da vossa empresa na nossa base de dados, notem que poder?o faz?-lo diretamente e sem demoras.

De facto, as entidades empresariais cujos dados constem da nossa base de dados podem consultar, acrescentar e modificar on-line as informa??es que lhes digam respeito, sendo para tal apenas necess?rio que disponham de uma senha de acesso exclusivo a uma zona reservada do nosso site.

Sublinhamos que este acesso para atualiza??o on-line ? totalmente gratuito e muito f?cil, bastando entrar em www.informadb.pt e selecionar, em Feed?Back , " Para consultar atualizar os dados de uma empresa diretamente na nossa base de dados".

Se necessitarem de mais esclarecimentos sobre o Feed?Back ? Servi?o de Atualiza??o de Dados, estaremos inteiramente dispon?veis para os prestar.

Atenciosamente,

Servi?o de Apoio ao Cliente

(+351) 213 500 389 - Fax: (+351) 213 151 658
vipclientes at informadb.pt
www.informadb.pt

CONFIDENCIAL. Esta mensagem destina-se a uso exclusivo do(s) destinat?rio(s) e poder? conter informa??o privada ou confidencial. A leitura, reten??o, divulga??o, c?pia, distribui??o ou reencaminhamento s?o pro?bidas. Caso a receba por engano, solicitamos que nos comunique por e-mail e elimine a mensagem do seu sistema sem a reproduzir. Os dados pessoais constantes do presente e-mail est?o ou ser?o adicionados ? lista de contactos da INFORMA D&B, respons?vel pelo tratamento de dados, para o podermos contactar sempre que necess?rio . O direito de acesso, retifica??o, oposi??o e apagamento, dever? ser exercido atrav?s do e-mail: protecaodedados at informadb.pt. Consulte o nosso compromisso de privacidade em www.informadb.pt.

CONFIDENTIAL. This message is intended for the exclusive use of the named addressee(s) and it may contain private or confidential information. Any reading, retention, disclosure, copying, distribution or redirection is prohibited. If you are not the intended recipient, please notify us by e-mail and delete this message from your system without retaining a copy. The personal data included in this e-mail is or will be added to the contact list of INFORMA D&B, acting as data controller, to contact you whenever necessary. You have the right of access and the rights to rectification, to object and to erasure through the e-mail: protecaodedados at informadb.pt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20191101/6abbd742/attachment-0001.html>

From noreply at informadb.pt  Sat Nov  2 16:58:35 2019
From: noreply at informadb.pt (Informa D&B)
Date: Sat, 2 Nov 2019 15:58:35 +0000 (GMT)
Subject: encrypt file in batch mode [ ref:_00D58dJQM._5004IusLVX:ref ]
Message-ID: <fY36F000000000000000000000000000000000000000000000Q0CN1N00ZNx6Q8zkRna1gwaP4zupYA@sfdc.net>

Exmos. Senhores,

Recebemos a informa??o que tiveram hoje a amabilidade de nos transmitir e que muito agradecemos.

Vamos imediatamente analisar o caso e responderemos com a m?xima brevidade poss?vel ao vosso pedido. Assim que for poss?vel, o Servi?o de Apoio ao Cliente entrar? em contacto convosco.

No entanto, caso o vosso contacto esteja relacionado com a necessidade de atualizar os dados da vossa empresa na nossa base de dados, notem que poder?o faz?-lo diretamente e sem demoras.

De facto, as entidades empresariais cujos dados constem da nossa base de dados podem consultar, acrescentar e modificar on-line as informa??es que lhes digam respeito, sendo para tal apenas necess?rio que disponham de uma senha de acesso exclusivo a uma zona reservada do nosso site.

Sublinhamos que este acesso para atualiza??o on-line ? totalmente gratuito e muito f?cil, bastando entrar em www.informadb.pt e selecionar, em Feed?Back , " Para consultar atualizar os dados de uma empresa diretamente na nossa base de dados".

Se necessitarem de mais esclarecimentos sobre o Feed?Back ? Servi?o de Atualiza??o de Dados, estaremos inteiramente dispon?veis para os prestar.

Atenciosamente,

Servi?o de Apoio ao Cliente

(+351) 213 500 389 - Fax: (+351) 213 151 658
vipclientes at informadb.pt
www.informadb.pt

CONFIDENCIAL. Esta mensagem destina-se a uso exclusivo do(s) destinat?rio(s) e poder? conter informa??o privada ou confidencial. A leitura, reten??o, divulga??o, c?pia, distribui??o ou reencaminhamento s?o pro?bidas. Caso a receba por engano, solicitamos que nos comunique por e-mail e elimine a mensagem do seu sistema sem a reproduzir. Os dados pessoais constantes do presente e-mail est?o ou ser?o adicionados ? lista de contactos da INFORMA D&B, respons?vel pelo tratamento de dados, para o podermos contactar sempre que necess?rio . O direito de acesso, retifica??o, oposi??o e apagamento, dever? ser exercido atrav?s do e-mail: protecaodedados at informadb.pt. Consulte o nosso compromisso de privacidade em www.informadb.pt.

CONFIDENTIAL. This message is intended for the exclusive use of the named addressee(s) and it may contain private or confidential information. Any reading, retention, disclosure, copying, distribution or redirection is prohibited. If you are not the intended recipient, please notify us by e-mail and delete this message from your system without retaining a copy. The personal data included in this e-mail is or will be added to the contact list of INFORMA D&B, acting as data controller, to contact you whenever necessary. You have the right of access and the rights to rectification, to object and to erasure through the e-mail: protecaodedados at informadb.pt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20191102/8537160b/attachment-0001.html>

From Horst at skat-foundation.de  Sat Nov  2 12:20:07 2019
From: Horst at skat-foundation.de (Horst Skatmus)
Date: Sat, 2 Nov 2019 12:20:07 +0100
Subject: gpg-agent only checks for smartcard not for local keys
Message-ID: <!&!AAAAAAAAAAAuAAAAAAAAAA5smRXHsmVElvboTNge148BAMO2jhD3dRHOtM0AqgC7tuYAAAAAAA4AABAAAAA1pjs8gCUES4JsO11aqjZrAQAAAAA=@skat-foundation.de>

I have installed GnuPG Windows on a Windows 10 machine and I'd like to use
it with Putty as key based ssh authentication together with a smartcard. I
got everything working fine.

The only problem I have is that the gpg-agent always checks for the
smartcard even when keys are not stored on a smartcard.

 

gpg-connect-agent "keyinfo --list" /bye

 

S KEYINFO 16F96695784023BBD32BE7D9F8320568156CB76A D - - - P - - -

S KEYINFO 3D3DE2508675ECE9856242056D8A5956E35B056E D - - - P - - -

S KEYINFO C8316A470CEB466B4565C55B7FB8A98BA10BB558 D - - - P - - -

S KEYINFO C9376FD06A963284ADC1EF46861EC611C5D780B7 D - - - P - - -

 

This shows that all keys are located on the disk (column with the "D") but
the gpg-agent log shows that the agent get a request from putty via the
"Pageant" options and he checks for a SC via the scdaemon.

 

2019-11-01 19:44:18 gpg-agent[6304] DBG: ssh map file
'PageantRequest00003d68'
2019-11-01 19:44:18 gpg-agent[6304] DBG: ssh map handle 0x00000338
2019-11-01 19:44:18 gpg-agent[6304] DBG:           my sid:
'S-1-5-21-2710969852-3158981170-84828875-1001'
2019-11-01 19:44:18 gpg-agent[6304] DBG: ssh map file sid:
'S-1-5-21-2710969852-3158981170-84828875-1001'
2019-11-01 19:44:18 gpg-agent[6304] DBG: ssh IPC buffer at 0x00670000
2019-11-01 19:44:18 gpg-agent[6304] ssh request handler for
request_identities (11) started
2019-11-01 19:44:18 gpg-agent[6304] new connection to SCdaemon established
(reusing)
2019-11-01 19:44:18 gpg-agent[6304] DBG: chan_0x00000314 -> SERIALNO
2019-11-01 19:44:18 gpg-agent[6304] DBG: chan_0x00000314 <- ERR 100696144 No
such device <SCD>
2019-11-01 19:44:18 gpg-agent[6304] ssh request handler for
request_identities (11) ready
2019-11-01 19:44:18 gpg-agent[6304] DBG: chan_0x00000314 -> RESTART
2019-11-01 19:44:18 gpg-agent[6304] DBG: chan_0x00000314 <- OK

 

I do not understand how the gpg-agent determines where to look for the
private key (disk or smartcard) and where this is configured. I can switch
off the scdaemon via --disable-scdaemon but this has no effect.

When I copy the secret key to the smartcard via keytocard in gpg everything
works fine.

 

 

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

From codeguro at gmail.com  Sun Nov  3 05:46:51 2019
From: codeguro at gmail.com (Tony Lane)
Date: Sun, 3 Nov 2019 00:46:51 -0400
Subject: How to decrypt a message while preserving the signature?
In-Reply-To: <87tv7mp4j8.fsf@netris.org>
References: <87tv7mp4j8.fsf@netris.org>
Message-ID: <c429fba9-b63f-a6c0-20ba-3a5053f8274e@gmail.com>

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


> Does GnuPG provide a mechanism to decrypt an encrypted-and-signed
> message in such a way that preserves the original signature, such that
> the original signature can be independently verified by an arbitrary
> third-party?

The term you're looking for is a detached signature.
You can create a detached signature (or any signature, really) only if
you possess the private key.
-----BEGIN PGP SIGNATURE-----

iLgEARMKAB0WIQQWZv6JZKxO310TWtXo8fj9gx4T0wUCXb5buwAKCRDo8fj9gx4T
0wcxAgkBsJUtcuXCPr6k/ed0eb7K4ep8vhVQlhKn1p7ropq87baL3hN0+Fg62Kef
naqh7InflnAzBJh/wcpaPa9yhjfVro8CB0XiF/JQUTZqOwbM9vHkgVSrSvDdRiAo
Sfz2Qjro2pIGs5Brgi9lYx0FdoyG44IadJTgd7MJvBhDJJJ5l4nD+l4Y
=hETr
-----END PGP SIGNATURE-----


From mhw at netris.org  Sun Nov  3 06:55:03 2019
From: mhw at netris.org (Mark H Weaver)
Date: Sun, 03 Nov 2019 01:55:03 -0400
Subject: How to decrypt a message while preserving the signature?
In-Reply-To: <c429fba9-b63f-a6c0-20ba-3a5053f8274e@gmail.com>
References: <c429fba9-b63f-a6c0-20ba-3a5053f8274e@gmail.com>
 <c429fba9-b63f-a6c0-20ba-3a5053f8274e@gmail.com>
Message-ID: <87v9s1o65p.fsf@netris.org>

Tony Lane wrote:

>> Does GnuPG provide a mechanism to decrypt an encrypted-and-signed
>> message in such a way that preserves the original signature, such that
>> the original signature can be independently verified by an arbitrary
>> third-party?
>
> The term you're looking for is a detached signature.
> You can create a detached signature (or any signature, really) only if
> you possess the private key.

I know what a detached signature is.  You misunderstood what I'm asking
for.

In simple terms, my understanding is that when you sign-and-encrypt a
message, it is first signed, resulting in a signed message (a message
plus signature), and then the signed message (message plus signature) is
encrypted.  The details are likely more complicated, but at a high level
of abstraction, that's my understanding of what's going on.  Please
correct me if I'm wrong.

I'm asking if there's a way to decrypt the message while preserving the
existing signed message.  Of course, this requires the private
decryption key, but it should *not* require the private signing key.

I can study the details and implement this myself if necessary, but to
save myself precious time and energy, I'm asking if GnuPG already
provides a mechanism to do this.  More generally, does there exist free
software to do this?

      Thanks,
        Mark


From 400thecat at gmx.ch  Sun Nov  3 07:24:13 2019
From: 400thecat at gmx.ch (Fourhundred Thecat)
Date: Sun, 3 Nov 2019 07:24:13 +0100
Subject: encrypt file in batch mode
In-Reply-To: <c7c71a8f-a7d0-7c18-a90a-c060e5384e84@gmail.com>
References: <9962aeca-c896-7c64-03ef-a61ead1a9ba0@gmx.ch>
 <18bc863a-b5eb-8f63-7ccf-f104e68b9980@gmail.com>
 <451a1aff-d9a4-9baf-f786-db1e3d85ab3d@gmx.ch>
 <c7c71a8f-a7d0-7c18-a90a-c060e5384e84@gmail.com>
Message-ID: <b633bf0f-6de5-28c0-1134-0045781e89ba@gmx.ch>

On 02/11/2019 22.52, Brian C via Gnupg-users wrote:
> I can answer why the passphrase is needed: You are using the -s option
> which tells gpg to sign the file, which requires your private key.

You are right. It works when I remove "-s".

But it makes no sense. This particular private key has no passphrase. So
shouldn't signing work in batch mode as well ?

Also, I still get an error when trustdb.gpg is not writable.

I am specifically using "--no-auto-check-trustdb" and "--lock-never",
but these options do not seem to have any effect.

Here is full syntax I am using now:

gpg --no-auto-check-trustdb --lock-never --no-verbose --batch --yes
--pinentry-mode loopback -e -r user at domain.com -o zz.gpg zz

The above works, if trustdb.gpg is writable. It fails if it is not:

gpg: Fatal: can't open '/var/lib/asterisk/.gnupg/trustdb.gpg': Operation
not permitted

Why does gpg need trustdb.gpg to be writable? I am not asking to change
any trust settings. I just need simply to encrypt file.

thanks,


From codeguro at gmail.com  Sun Nov  3 07:28:43 2019
From: codeguro at gmail.com (Tony Lane)
Date: Sun, 3 Nov 2019 01:28:43 -0500
Subject: How to decrypt a message while preserving the signature?
In-Reply-To: <87v9s1o65p.fsf@netris.org>
References: <c429fba9-b63f-a6c0-20ba-3a5053f8274e@gmail.com>
 <c429fba9-b63f-a6c0-20ba-3a5053f8274e@gmail.com> <87v9s1o65p.fsf@netris.org>
Message-ID: <f2db1380-6eec-47d7-3e24-e2d765d21f29@gmail.com>

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

On 11/3/19 1:55 AM, Mark H Weaver wrote:
> I'm asking if there's a way to decrypt the message while preserving the
> existing signed message.  Of course, this requires the private
> decryption key, but it should *not* require the private signing key.

I do not think there is a way to do this. When both '-s' and '-r' options
are used for some given file, the decryption operation atomically decrypts
and verifies the file. Actually, I don't think it goes through PGP in two
"passes" like you might think. You are probably best off having the signer
encrypt and sign distinctly, like so:

gpg -s <infile | gpg -er gpg at example.com -o outfile.sig.gpg

That way, you can extract the encryption layer to get to the signed file.
I think your request to "extract" the atomic sign-encrypt layer is at odds
with itself. The signed file is intended for the recipient only, so it
only makes sense that it can be decrypted/verified only by the recipient
as well.
-----BEGIN PGP SIGNATURE-----

iLkEARMKAB0WIQQWZv6JZKxO310TWtXo8fj9gx4T0wUCXb5zmgAKCRDo8fj9gx4T
05+9AgkBDfZ6XViQknKe1r70ipE8kbPQChaXu935oY5PVBw4ziQUUDsBVOQ31vJZ
mpUSHHZQ5WFqDbiwsn3vBJAs8wv8NzYCCQGEkmDntQ603IEIiN2CyOrFmiYHS/A1
dk3AuWRkIOlu6UYArY98CZT/5sY/9wkOCMRxlbjP5L+CASFllnPquu8C6w==
=CAwQ
-----END PGP SIGNATURE-----


From codeguro at gmail.com  Sun Nov  3 07:52:50 2019
From: codeguro at gmail.com (Tony Lane)
Date: Sun, 3 Nov 2019 01:52:50 -0500
Subject: encrypt file in batch mode
In-Reply-To: <b633bf0f-6de5-28c0-1134-0045781e89ba@gmx.ch>
References: <9962aeca-c896-7c64-03ef-a61ead1a9ba0@gmx.ch>
 <18bc863a-b5eb-8f63-7ccf-f104e68b9980@gmail.com>
 <451a1aff-d9a4-9baf-f786-db1e3d85ab3d@gmx.ch>
 <c7c71a8f-a7d0-7c18-a90a-c060e5384e84@gmail.com>
 <b633bf0f-6de5-28c0-1134-0045781e89ba@gmx.ch>
Message-ID: <187da16e-f28d-dfb3-bb2f-cd661411b36e@gmail.com>

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

On 11/3/19 1:24 AM, Fourhundred Thecat wrote:

> But it makes no sense. This particular private key has no passphrase. So
> shouldn't signing work in batch mode as well ?
Are you sure? Try to --edit-key and select that key (not the cert key).
Then passwd, for the empty passphrase. Don't forget to save.

> Also, I still get an error when trustdb.gpg is not writable.
> --lock-never
Be careful with that option. The docs say this:
> This option should be used only in very special environments
> Improper usage of this option may lead to data and key corruption.
Is there a chance that's what's happening here?
-----BEGIN PGP SIGNATURE-----

iLcEARMKAB0WIQQWZv6JZKxO310TWtXo8fj9gx4T0wUCXb55QgAKCRDo8fj9gx4T
0wIGAgUReI7Epg4xygz0BxRkl+TSUwSW6K7q98D6AlkbjLbHUZBEG2RfmRu9IINe
UF3BFVddL1XqxV593DR81PPfU/gF+QIIrlMAvOW0kl/45S1cUrsrG9UkDMIRuM7i
NniVfZ9Snj5RZSVIdZNHw9wwdKKkY1MujkqfdF9UL4mtzIl1RQ8EFo0=
=dO9l
-----END PGP SIGNATURE-----


From mhw at netris.org  Sun Nov  3 08:06:13 2019
From: mhw at netris.org (Mark H Weaver)
Date: Sun, 03 Nov 2019 02:06:13 -0500
Subject: How to decrypt a message while preserving the signature?
In-Reply-To: <87v9s1o65p.fsf@netris.org>
References: <c429fba9-b63f-a6c0-20ba-3a5053f8274e@gmail.com>
 <c429fba9-b63f-a6c0-20ba-3a5053f8274e@gmail.com>
 <87v9s1o65p.fsf@netris.org>
Message-ID: <87r22po2v3.fsf@netris.org>

Tony Lane wrote:

> On 11/3/19 1:55 AM, Mark H Weaver wrote:
>> I'm asking if there's a way to decrypt the message while preserving the
>> existing signed message.  Of course, this requires the private
>> decryption key, but it should *not* require the private signing key.
>
> I do not think there is a way to do this. When both '-s' and '-r' options
> are used for some given file, the decryption operation atomically decrypts
> and verifies the file.

"Atomically", really?  I'm aware that the high-level user interface
makes it *appear* to be atomic, but if you actually believe it's atomic,
I think you are demonstrating that your knowledge of cryptography and
OpenPGP formats is even more superficial than my own.

Incidentally, I one of the first developers hired by PGP, Inc, and one
of the authors of PGP 5.x.  I worked with Phil Zimmermann quite closely,
and also with Hal Finney, RIP.  It was the last nonfree software I
worked on, back in the late 1990s.  Obviously, I did not work on the
actual cryptographic operations--my areas were the key management code,
cross-platform layer, API design, and design and production of the
scannable printed source code books that allowed PGP to be legally
exported to Europe for the first time.  Please do not mistake me for a
noob.

I'm reading RFC 4880 now, to get my own answers.  Still, I would be
grateful if someone with deeper knowledge would answer my question.

     Thanks,
       Mark


From mhw at netris.org  Sun Nov  3 08:15:40 2019
From: mhw at netris.org (Mark H Weaver)
Date: Sun, 03 Nov 2019 02:15:40 -0500
Subject: How to decrypt a message while preserving the signature?
In-Reply-To: <87r22po2v3.fsf@netris.org>
References: <c429fba9-b63f-a6c0-20ba-3a5053f8274e@gmail.com>
 <c429fba9-b63f-a6c0-20ba-3a5053f8274e@gmail.com>
 <87r22po2v3.fsf@netris.org>
Message-ID: <87muddo2fc.fsf@netris.org>

I wrote:
> I'm reading RFC 4880 now, to get my own answers.  Still, I would be
> grateful if someone with deeper knowledge would answer my question.

Quoting the last paragraph of section 2.1 of RFC 4880:

   Both digital signature and confidentiality services may be applied to
   the same message.  First, a signature is generated for the message
   and attached to the message.  Then the message plus signature is
   encrypted using a symmetric session key.  Finally, the session key is
   encrypted using public-key encryption and prefixed to the encrypted
   block.

Exactly as I said.  So what I'm asking for can certainly be done.

      Mark


From 400thecat at gmx.ch  Sun Nov  3 08:31:10 2019
From: 400thecat at gmx.ch (Fourhundred Thecat)
Date: Sun, 3 Nov 2019 08:31:10 +0100
Subject: encrypt file in batch mode
In-Reply-To: <187da16e-f28d-dfb3-bb2f-cd661411b36e@gmail.com>
References: <9962aeca-c896-7c64-03ef-a61ead1a9ba0@gmx.ch>
 <18bc863a-b5eb-8f63-7ccf-f104e68b9980@gmail.com>
 <451a1aff-d9a4-9baf-f786-db1e3d85ab3d@gmx.ch>
 <c7c71a8f-a7d0-7c18-a90a-c060e5384e84@gmail.com>
 <b633bf0f-6de5-28c0-1134-0045781e89ba@gmx.ch>
 <187da16e-f28d-dfb3-bb2f-cd661411b36e@gmail.com>
Message-ID: <b8cd2eff-907a-28b7-ecc7-0297cd05e4c5@gmx.ch>

On 03/11/2019 07.52, Tony Lane via Gnupg-users wrote:
> On 11/3/19 1:24 AM, Fourhundred Thecat wrote:
>
>> But it makes no sense. This particular private key has no passphrase. So
>> shouldn't signing work in batch mode as well ?
> Are you sure? Try to --edit-key and select that key (not the cert key).
> Then passwd, for the empty passphrase. Don't forget to save.

I am sure the private key has no passphrase. Everything worked fine with
same private key on gpg 1.4.12

But now, I cannot even list keys from secring.gpg

$ gpg --list-secret-keys
gpg: can't connect to the agent: No such file or directory
gpg: failed to start agent '/usr/bin/gpg-agent': No such file or directory

Same error when I try "--edit-key"

  failed to start agent '/usr/bin/gpg-agent': No such file or directory


The only thing that works is "gpg --list-packets secring.gpg"

$ gpg --list-packets secring.gpg | grep protect

I believe this shows that secret key is not password protected

If it was, it would have:
  protect count:
  protect IV:

>> Also, I still get an error when trustdb.gpg is not writable.
>> --lock-never
> Be careful with that option. The docs say this:
>> This option should be used only in very special environments
>> Improper usage of this option may lead to data and key corruption.
> Is there a chance that's what's happening here?

well, if trustdb.gpg is not writable, how could it lead to corruption.
That's the whole point. I want read-only access to trustdb.gpg, because
I don't want to make any changes.



From peter at digitalbrains.com  Sun Nov  3 10:15:49 2019
From: peter at digitalbrains.com (Peter Lebbing)
Date: Sun, 3 Nov 2019 10:15:49 +0100
Subject: How to decrypt a message while preserving the signature?
In-Reply-To: <87muddo2fc.fsf@netris.org>
References: <c429fba9-b63f-a6c0-20ba-3a5053f8274e@gmail.com>
 <c429fba9-b63f-a6c0-20ba-3a5053f8274e@gmail.com> <87r22po2v3.fsf@netris.org>
 <87muddo2fc.fsf@netris.org>
Message-ID: <965c0a4b-34be-c7fe-67cb-9de5f4748135@digitalbrains.com>

Werner recently mentioned an undocumented command for this.[1]

On 27/08/2019 11:30, Werner Koch via Gnupg-users wrote: 
> You can extra the signature from the encrypted+signed data:
> 
>   gpg --unwrap -d -o SIG <ENC+SIG
> 
> and then run
> 
>   gpgv -o SIGNEDFILE SIG && echo verified!
> 
> --unwrap is not documented and has the minor problem that it also keeps the
> compression layer.  However, gpgv groks that compression layer and works
> as with a standard signature.  The signature is on SIGNEDFILE which gpgv
> outputs for you.

HTH,

Peter.

[1] https://lists.gnupg.org/pipermail/gnupg-users/2019-August/062619.html

-- 
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/20191103/44c60c62/attachment.sig>

From noreply at informadb.pt  Sat Nov  2 23:00:12 2019
From: noreply at informadb.pt (Informa D&B)
Date: Sat, 2 Nov 2019 22:00:12 +0000 (GMT)
Subject: encrypt file in batch mode [ ref:_00D58dJQM._5004IusOTU:ref ]
Message-ID: <mfa7b000000000000000000000000000000000000000000000Q0D3SC00dwWJ-uLwSauookV4HS3zrA@sfdc.net>

Exmos. Senhores,

Recebemos a informa??o que tiveram hoje a amabilidade de nos transmitir e que muito agradecemos.

Vamos imediatamente analisar o caso e responderemos com a m?xima brevidade poss?vel ao vosso pedido. Assim que for poss?vel, o Servi?o de Apoio ao Cliente entrar? em contacto convosco.

No entanto, caso o vosso contacto esteja relacionado com a necessidade de atualizar os dados da vossa empresa na nossa base de dados, notem que poder?o faz?-lo diretamente e sem demoras.

De facto, as entidades empresariais cujos dados constem da nossa base de dados podem consultar, acrescentar e modificar on-line as informa??es que lhes digam respeito, sendo para tal apenas necess?rio que disponham de uma senha de acesso exclusivo a uma zona reservada do nosso site.

Sublinhamos que este acesso para atualiza??o on-line ? totalmente gratuito e muito f?cil, bastando entrar em www.informadb.pt e selecionar, em Feed?Back , " Para consultar atualizar os dados de uma empresa diretamente na nossa base de dados".

Se necessitarem de mais esclarecimentos sobre o Feed?Back ? Servi?o de Atualiza??o de Dados, estaremos inteiramente dispon?veis para os prestar.

Atenciosamente,

Servi?o de Apoio ao Cliente

(+351) 213 500 389 - Fax: (+351) 213 151 658
vipclientes at informadb.pt
www.informadb.pt

CONFIDENCIAL. Esta mensagem destina-se a uso exclusivo do(s) destinat?rio(s) e poder? conter informa??o privada ou confidencial. A leitura, reten??o, divulga??o, c?pia, distribui??o ou reencaminhamento s?o pro?bidas. Caso a receba por engano, solicitamos que nos comunique por e-mail e elimine a mensagem do seu sistema sem a reproduzir. Os dados pessoais constantes do presente e-mail est?o ou ser?o adicionados ? lista de contactos da INFORMA D&B, respons?vel pelo tratamento de dados, para o podermos contactar sempre que necess?rio . O direito de acesso, retifica??o, oposi??o e apagamento, dever? ser exercido atrav?s do e-mail: protecaodedados at informadb.pt. Consulte o nosso compromisso de privacidade em www.informadb.pt.

CONFIDENTIAL. This message is intended for the exclusive use of the named addressee(s) and it may contain private or confidential information. Any reading, retention, disclosure, copying, distribution or redirection is prohibited. If you are not the intended recipient, please notify us by e-mail and delete this message from your system without retaining a copy. The personal data included in this e-mail is or will be added to the contact list of INFORMA D&B, acting as data controller, to contact you whenever necessary. You have the right of access and the rights to rectification, to object and to erasure through the e-mail: protecaodedados at informadb.pt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20191102/69254318/attachment-0001.html>

From noreply at informadb.pt  Sun Nov  3 05:58:44 2019
From: noreply at informadb.pt (Informa D&B)
Date: Sun, 3 Nov 2019 04:58:44 +0000 (GMT)
Subject: How to decrypt a message while preserving the signature? [
 ref:_00D58dJQM._5004IusPCe:ref ]
Message-ID: <H1ZzK000000000000000000000000000000000000000000000Q0DN5W00vwGc6Oo4SA6LD78UaUyHiw@sfdc.net>

Exmos. Senhores,

Recebemos a informa??o que tiveram hoje a amabilidade de nos transmitir e que muito agradecemos.

Vamos imediatamente analisar o caso e responderemos com a m?xima brevidade poss?vel ao vosso pedido. Assim que for poss?vel, o Servi?o de Apoio ao Cliente entrar? em contacto convosco.

No entanto, caso o vosso contacto esteja relacionado com a necessidade de atualizar os dados da vossa empresa na nossa base de dados, notem que poder?o faz?-lo diretamente e sem demoras.

De facto, as entidades empresariais cujos dados constem da nossa base de dados podem consultar, acrescentar e modificar on-line as informa??es que lhes digam respeito, sendo para tal apenas necess?rio que disponham de uma senha de acesso exclusivo a uma zona reservada do nosso site.

Sublinhamos que este acesso para atualiza??o on-line ? totalmente gratuito e muito f?cil, bastando entrar em www.informadb.pt e selecionar, em Feed?Back , " Para consultar atualizar os dados de uma empresa diretamente na nossa base de dados".

Se necessitarem de mais esclarecimentos sobre o Feed?Back ? Servi?o de Atualiza??o de Dados, estaremos inteiramente dispon?veis para os prestar.

Atenciosamente,

Servi?o de Apoio ao Cliente

(+351) 213 500 389 - Fax: (+351) 213 151 658
vipclientes at informadb.pt
www.informadb.pt

CONFIDENCIAL. Esta mensagem destina-se a uso exclusivo do(s) destinat?rio(s) e poder? conter informa??o privada ou confidencial. A leitura, reten??o, divulga??o, c?pia, distribui??o ou reencaminhamento s?o pro?bidas. Caso a receba por engano, solicitamos que nos comunique por e-mail e elimine a mensagem do seu sistema sem a reproduzir. Os dados pessoais constantes do presente e-mail est?o ou ser?o adicionados ? lista de contactos da INFORMA D&B, respons?vel pelo tratamento de dados, para o podermos contactar sempre que necess?rio . O direito de acesso, retifica??o, oposi??o e apagamento, dever? ser exercido atrav?s do e-mail: protecaodedados at informadb.pt. Consulte o nosso compromisso de privacidade em www.informadb.pt.

CONFIDENTIAL. This message is intended for the exclusive use of the named addressee(s) and it may contain private or confidential information. Any reading, retention, disclosure, copying, distribution or redirection is prohibited. If you are not the intended recipient, please notify us by e-mail and delete this message from your system without retaining a copy. The personal data included in this e-mail is or will be added to the contact list of INFORMA D&B, acting as data controller, to contact you whenever necessary. You have the right of access and the rights to rectification, to object and to erasure through the e-mail: protecaodedados at informadb.pt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20191103/59f61e5a/attachment-0001.html>

From noreply at informadb.pt  Sun Nov  3 07:58:53 2019
From: noreply at informadb.pt (Informa D&B)
Date: Sun, 3 Nov 2019 06:58:53 +0000 (GMT)
Subject: encrypt file in batch mode [ ref:_00D58dJQM._5004IusPVR:ref ]
Message-ID: <vuWvw000000000000000000000000000000000000000000000Q0DSQ500Z_AFapehQcq6z1B_J5ZXdA@sfdc.net>

Exmos. Senhores,

Recebemos a informa??o que tiveram hoje a amabilidade de nos transmitir e que muito agradecemos.

Vamos imediatamente analisar o caso e responderemos com a m?xima brevidade poss?vel ao vosso pedido. Assim que for poss?vel, o Servi?o de Apoio ao Cliente entrar? em contacto convosco.

No entanto, caso o vosso contacto esteja relacionado com a necessidade de atualizar os dados da vossa empresa na nossa base de dados, notem que poder?o faz?-lo diretamente e sem demoras.

De facto, as entidades empresariais cujos dados constem da nossa base de dados podem consultar, acrescentar e modificar on-line as informa??es que lhes digam respeito, sendo para tal apenas necess?rio que disponham de uma senha de acesso exclusivo a uma zona reservada do nosso site.

Sublinhamos que este acesso para atualiza??o on-line ? totalmente gratuito e muito f?cil, bastando entrar em www.informadb.pt e selecionar, em Feed?Back , " Para consultar atualizar os dados de uma empresa diretamente na nossa base de dados".

Se necessitarem de mais esclarecimentos sobre o Feed?Back ? Servi?o de Atualiza??o de Dados, estaremos inteiramente dispon?veis para os prestar.

Atenciosamente,

Servi?o de Apoio ao Cliente

(+351) 213 500 389 - Fax: (+351) 213 151 658
vipclientes at informadb.pt
www.informadb.pt

CONFIDENCIAL. Esta mensagem destina-se a uso exclusivo do(s) destinat?rio(s) e poder? conter informa??o privada ou confidencial. A leitura, reten??o, divulga??o, c?pia, distribui??o ou reencaminhamento s?o pro?bidas. Caso a receba por engano, solicitamos que nos comunique por e-mail e elimine a mensagem do seu sistema sem a reproduzir. Os dados pessoais constantes do presente e-mail est?o ou ser?o adicionados ? lista de contactos da INFORMA D&B, respons?vel pelo tratamento de dados, para o podermos contactar sempre que necess?rio . O direito de acesso, retifica??o, oposi??o e apagamento, dever? ser exercido atrav?s do e-mail: protecaodedados at informadb.pt. Consulte o nosso compromisso de privacidade em www.informadb.pt.

CONFIDENTIAL. This message is intended for the exclusive use of the named addressee(s) and it may contain private or confidential information. Any reading, retention, disclosure, copying, distribution or redirection is prohibited. If you are not the intended recipient, please notify us by e-mail and delete this message from your system without retaining a copy. The personal data included in this e-mail is or will be added to the contact list of INFORMA D&B, acting as data controller, to contact you whenever necessary. You have the right of access and the rights to rectification, to object and to erasure through the e-mail: protecaodedados at informadb.pt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20191103/bfd84cbf/attachment-0001.html>

From noreply at informadb.pt  Sun Nov  3 07:34:27 2019
From: noreply at informadb.pt (Informa D&B)
Date: Sun, 3 Nov 2019 06:34:27 +0000 (GMT)
Subject: How to decrypt a message while preserving the signature? [
 ref:_00D58dJQM._5004IusPUT:ref ]
Message-ID: <7xVdS000000000000000000000000000000000000000000000Q0DRLF00h93ktmjlQo2Yp8JcqWNZTg@sfdc.net>

Exmos. Senhores,

Recebemos a informa??o que tiveram hoje a amabilidade de nos transmitir e que muito agradecemos.

Vamos imediatamente analisar o caso e responderemos com a m?xima brevidade poss?vel ao vosso pedido. Assim que for poss?vel, o Servi?o de Apoio ao Cliente entrar? em contacto convosco.

No entanto, caso o vosso contacto esteja relacionado com a necessidade de atualizar os dados da vossa empresa na nossa base de dados, notem que poder?o faz?-lo diretamente e sem demoras.

De facto, as entidades empresariais cujos dados constem da nossa base de dados podem consultar, acrescentar e modificar on-line as informa??es que lhes digam respeito, sendo para tal apenas necess?rio que disponham de uma senha de acesso exclusivo a uma zona reservada do nosso site.

Sublinhamos que este acesso para atualiza??o on-line ? totalmente gratuito e muito f?cil, bastando entrar em www.informadb.pt e selecionar, em Feed?Back , " Para consultar atualizar os dados de uma empresa diretamente na nossa base de dados".

Se necessitarem de mais esclarecimentos sobre o Feed?Back ? Servi?o de Atualiza??o de Dados, estaremos inteiramente dispon?veis para os prestar.

Atenciosamente,

Servi?o de Apoio ao Cliente

(+351) 213 500 389 - Fax: (+351) 213 151 658
vipclientes at informadb.pt
www.informadb.pt

CONFIDENCIAL. Esta mensagem destina-se a uso exclusivo do(s) destinat?rio(s) e poder? conter informa??o privada ou confidencial. A leitura, reten??o, divulga??o, c?pia, distribui??o ou reencaminhamento s?o pro?bidas. Caso a receba por engano, solicitamos que nos comunique por e-mail e elimine a mensagem do seu sistema sem a reproduzir. Os dados pessoais constantes do presente e-mail est?o ou ser?o adicionados ? lista de contactos da INFORMA D&B, respons?vel pelo tratamento de dados, para o podermos contactar sempre que necess?rio . O direito de acesso, retifica??o, oposi??o e apagamento, dever? ser exercido atrav?s do e-mail: protecaodedados at informadb.pt. Consulte o nosso compromisso de privacidade em www.informadb.pt.

CONFIDENTIAL. This message is intended for the exclusive use of the named addressee(s) and it may contain private or confidential information. Any reading, retention, disclosure, copying, distribution or redirection is prohibited. If you are not the intended recipient, please notify us by e-mail and delete this message from your system without retaining a copy. The personal data included in this e-mail is or will be added to the contact list of INFORMA D&B, acting as data controller, to contact you whenever necessary. You have the right of access and the rights to rectification, to object and to erasure through the e-mail: protecaodedados at informadb.pt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20191103/26ac7608/attachment-0001.html>

From andrewg at andrewg.com  Sun Nov  3 13:45:37 2019
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Sun, 3 Nov 2019 12:45:37 +0000
Subject: How to decrypt a message while preserving the signature? [
 ref:_00D58dJQM._5004IusPCe:ref ]
In-Reply-To: <H1ZzK000000000000000000000000000000000000000000000Q0DN5W00vwGc6Oo4SA6LD78UaUyHiw@sfdc.net>
References: <H1ZzK000000000000000000000000000000000000000000000Q0DN5W00vwGc6Oo4SA6LD78UaUyHiw@sfdc.net>
Message-ID: <AFACF762-830E-4F75-8D11-5D4DB682F9AF@andrewg.com>

Can one of the admins please unsubscribe or mute this recipient? It?s getting silly now. Thanks.

Andrew Gallagher

> On 3 Nov 2019, at 12:20, Informa D&B via Gnupg-users <gnupg-users at gnupg.org> wrote:
> 
> ? Exmos. Senhores,
> 
> Recebemos a informa??o que tiveram hoje a amabilidade de nos transmitir e que muito agradecemos.
>  
> Vamos imediatamente analisar o caso e responderemos com a m?xima brevidade poss?vel ao vosso pedido. Assim que for poss?vel, o Servi?o de Apoio ao Cliente entrar? em contacto convosco.
>  
> No entanto, caso o vosso contacto esteja relacionado com a necessidade de atualizar os dados da vossa empresa na nossa base de dados, notem que poder?o faz?-lo diretamente e sem demoras.
>  
> De facto, as entidades empresariais cujos dados constem da nossa base de dados podem consultar, acrescentar e modificar on-line as informa??es que lhes digam respeito, sendo para tal apenas necess?rio que disponham de uma senha de acesso exclusivo a uma zona reservada do nosso site.
>  
> Sublinhamos que este acesso para atualiza??o on-line ? totalmente gratuito e muito f?cil, bastando entrar em www.informadb.pt e selecionar, em Feed?Back , " Para consultar atualizar os dados de uma empresa diretamente na nossa base de dados".
> 
> Se necessitarem de mais esclarecimentos sobre o Feed?Back ? Servi?o de Atualiza??o de Dados, estaremos inteiramente dispon?veis para os prestar.
>  
> Atenciosamente,
> 
> Servi?o de Apoio ao Cliente
> 
> (+351) 213 500 389 - Fax: (+351) 213 151 658
> vipclientes at informadb.pt
> www.informadb.pt
> 
> CONFIDENCIAL. Esta mensagem destina-se a uso exclusivo do(s) destinat?rio(s) e poder? conter informa??o privada ou confidencial. A leitura, reten??o, divulga??o, c?pia, distribui??o ou reencaminhamento s?o pro?bidas. Caso a receba por engano, solicitamos que nos comunique por e-mail e elimine a mensagem do seu sistema sem a reproduzir. Os dados pessoais constantes do presente e-mail est?o ou ser?o adicionados ? lista de contactos da INFORMA D&B, respons?vel pelo tratamento de dados, para o podermos contactar sempre que necess?rio . O direito de acesso, retifica??o, oposi??o e apagamento, dever? ser exercido atrav?s do e-mail: protecaodedados at informadb.pt. Consulte o nosso compromisso de privacidade em www.informadb.pt.
> 
> CONFIDENTIAL. This message is intended for the exclusive use of the named addressee(s) and it may contain private or confidential information. Any reading, retention, disclosure, copying, distribution or redirection is prohibited. If you are not the intended recipient, please notify us by e-mail and delete this message from your system without retaining a copy. The personal data included in this e-mail is or will be added to the contact list of INFORMA D&B, acting as data controller, to contact you whenever necessary. You have the right of access and the rights to rectification, to object and to erasure through the e-mail: protecaodedados at informadb.pt  _______________________________________________
> 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/20191103/a35cc888/attachment.html>

From mhw at netris.org  Sun Nov  3 15:25:49 2019
From: mhw at netris.org (Mark H Weaver)
Date: Sun, 03 Nov 2019 09:25:49 -0500
Subject: How to decrypt a message while preserving the signature?
In-Reply-To: <965c0a4b-34be-c7fe-67cb-9de5f4748135@digitalbrains.com>
References: <c429fba9-b63f-a6c0-20ba-3a5053f8274e@gmail.com>
 <c429fba9-b63f-a6c0-20ba-3a5053f8274e@gmail.com>
 <87r22po2v3.fsf@netris.org> <87muddo2fc.fsf@netris.org>
 <965c0a4b-34be-c7fe-67cb-9de5f4748135@digitalbrains.com>
Message-ID: <87imo1niif.fsf@netris.org>

Hi Peter,

Peter Lebbing <peter at digitalbrains.com> wrote:
> Werner recently mentioned an undocumented command for this.[1]
>
> On 27/08/2019 11:30, Werner Koch via Gnupg-users wrote:
>> You can extra the signature from the encrypted+signed data:
>>
>>   gpg --unwrap -d -o SIG <ENC+SIG
>>
>> and then run
>>
>>   gpgv -o SIGNEDFILE SIG && echo verified!
>>
>> --unwrap is not documented and has the minor problem that it also keeps the
>> compression layer.  However, gpgv groks that compression layer and works
>> as with a standard signature.  The signature is on SIGNEDFILE which gpgv
>> outputs for you.
[...]
> [1] https://lists.gnupg.org/pipermail/gnupg-users/2019-August/062619.html

Thanks very much Peter, this is what I was looking for.  I'm grateful.

     Regards,
       Mark


From abbot at monksofcool.net  Sun Nov  3 22:05:01 2019
From: abbot at monksofcool.net (Ralph Seichter)
Date: Sun, 03 Nov 2019 22:05:01 +0100
Subject: How to decrypt a message while preserving the signature? [
 ref:_00D58dJQM._5004IusPCe:ref ]
In-Reply-To: <AFACF762-830E-4F75-8D11-5D4DB682F9AF@andrewg.com>
References: <H1ZzK000000000000000000000000000000000000000000000Q0DN5W00vwGc6Oo4SA6LD78UaUyHiw@sfdc.net>
 <AFACF762-830E-4F75-8D11-5D4DB682F9AF@andrewg.com>
Message-ID: <87sgn4wu0y.fsf@wedjat.horus-it.com>

* Andrew Gallagher:

> Can one of the admins please unsubscribe or mute this recipient? It?s
> getting silly now. Thanks.

Hooray for email killfiles. ;-) But yeah, unsubscribing would be nice.

-Ralph


From markr at signal100.com  Mon Nov  4 03:12:14 2019
From: markr at signal100.com (Mark Rousell)
Date: Mon, 4 Nov 2019 02:12:14 +0000
Subject: How to decrypt a message while preserving the signature? [
 ref:_00D58dJQM._5004IusPCe:ref ]
In-Reply-To: <AFACF762-830E-4F75-8D11-5D4DB682F9AF@andrewg.com>
References: <H1ZzK000000000000000000000000000000000000000000000Q0DN5W00vwGc6Oo4SA6LD78UaUyHiw@sfdc.net>
 <AFACF762-830E-4F75-8D11-5D4DB682F9AF@andrewg.com>
Message-ID: <5DBF88FE.6000505@signal100.com>

On 03/11/2019 12:45, Andrew Gallagher wrote:
> Can one of the admins please unsubscribe or mute this recipient? It?s
> getting silly now. Thanks.
>
> Andrew Gallagher
>
>> On 3 Nov 2019, at 12:20, Informa D&B via Gnupg-users
>> <gnupg-users at gnupg.org> wrote:
>>
>> ? Exmos. Senhores,

The same thing is happening on the mozilla.general mail list at the
moment although with a company called 'TheFork'. It has also happened in
the past on mozilla.general with a wholesale cut flowers supplier called
Avas Flowers.

What happens is that the genuine email helpdesks of these genuine
companies somehow get subscribed the respective mail list. It isn't
clear how this subscription happens although it looks like prank-like
foul play (or a low level DoS) by third parties to me.

Back when this first happened on mozilla.general, I attempted to engage
with the Avas Flowers helpdesk staff but they seemed utterly confused. I
am pretty sure that they had not knowingly subscribed to
mozilla.general. In general, the helpdesk staff of these companies seem
confused as to what to do and don't seem to be able to unsubscribe
themselves. And, at least in the case of Avas Flowers on
mozilla.general, when they were finally unsubscribed they seem to be
unwillingly re-subscribed soon after.

(N.B. Mozilla.general isn't just accessible as a newsgroup; it's also
accessible as a mail list).

-- 
Mark Rousell

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

From markr at signal100.com  Mon Nov  4 03:22:51 2019
From: markr at signal100.com (Mark Rousell)
Date: Mon, 4 Nov 2019 02:22:51 +0000
Subject: How to decrypt a message while preserving the signature? [
 ref:_00D58dJQM._5004IusPCe:ref ]
In-Reply-To: <5DBF88FE.6000505@signal100.com>
References: <H1ZzK000000000000000000000000000000000000000000000Q0DN5W00vwGc6Oo4SA6LD78UaUyHiw@sfdc.net>
 <AFACF762-830E-4F75-8D11-5D4DB682F9AF@andrewg.com>
 <5DBF88FE.6000505@signal100.com>
Message-ID: <5DBF8B7B.6000203@signal100.com>

On 04/11/2019 02:12, Mark Rousell wrote:
> The same thing is happening on the mozilla.general mail list at the
> moment although with a company called 'TheFork'. It has also happened
> in the past on mozilla.general with a wholesale cut flowers supplier
> called Avas Flowers.
>
> What happens is that the genuine email helpdesks of these genuine
> companies somehow get subscribed the respective mail list. It isn't
> clear how this subscription happens although it looks like prank-like
> foul play (or a low level DoS) by third parties to me.
>
> Back when this first happened on mozilla.general, I attempted to
> engage with the Avas Flowers helpdesk staff but they seemed utterly
> confused. I am pretty sure that they had not knowingly subscribed to
> mozilla.general. In general, the helpdesk staff of these companies
> seem confused as to what to do and don't seem to be able to
> unsubscribe themselves. And, at least in the case of Avas Flowers on
> mozilla.general, when they were finally unsubscribed they seem to be
> unwillingly re-subscribed soon after.

For what it's worth, I note that both Informa D&B here on this list and
TheFork (on mozilla.general) are using Salesforce-hosted helpdesks.

(Avas Flowers on mozilla.general (last year) were not on Salesforce, as
I recall. I think they hosted their own CRM/helpdesk software).

-- 
Mark Rousell

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

From gnupg at raf.org  Mon Nov  4 05:38:36 2019
From: gnupg at raf.org (raf)
Date: Mon, 4 Nov 2019 15:38:36 +1100
Subject: How to improve our GUIs (was: We have GOT TO make things simpler)
In-Reply-To: <bf14fc9c-cc6b-950f-f255-038104a0f124@digicana.com>
References: <20191030003331.stgm7magl7kpjwul@raf.org>
 <bf14fc9c-cc6b-950f-f255-038104a0f124@digicana.com>
Message-ID: <20191104043836.6tnz7x5tiagmak4p@raf.org>

Ryan McGinnis via Gnupg-users wrote:

> I might be missing something really obvious here but... what is this
> trying to protect against?

What they say they are trying to protect against, I suppose.
I summarised my understanding of it by saying:

> > It might not address all threats but it certainly seems
> > to solve some very real threats, mainly the threat of
> > someone hacking into your IMAP account and accessing
> > every email you ever received.

> ...Your service provider can
> certainly (and probably does certainly) retain archive or backup copies
> of all emails that enter into and exit your account...

I'm sure they have better things to waste their storage on.
Most IMAP service providers are not the NSA after all. :-)

> ... so encrypting them
> after reception only means that the copy you are accessing is encrypted
> and non-accessible to the provider, but the copy that they archived or
> backed up is just as plaintext as always (or is, more likely, encrypted
> with a key that only they know).?

The point is that it's not accessible to whoever hacks
into your IMAP account. They make it very clear that
that is the problem that they are trying to solve.

> ... E2E is really the only solution that keeps your email provably
> private from all parties concerned other than the recipients.?

Like anything else, E2E is only an actual solution if
it is actually used.

Since E2E for email is demonstrably too hard to achieve
for most people, it doesn't happen except in rare
cases. You can obviously send encrypted emails to all
your correspondents who have accessible keys. E3 allows
you to encrypt the emails that you receive that weren't
sent by senders who are able or willing to encrypt what
they send. The creators of E3 are not pretending that
E3 is an alternative to E2E for the problems that E2E
solves. It complements it (in the sense that it can
encrypt all the emails that weren't encrypted
end-to-end). It's just a tool that solves a particular
privacy problem in an accessible way. It seems like a
good thing.

Of course, making E2E just as accessible must be
possible too but it hasn't happened yet and we've been
waiting a long time. How hard would it be for all email
clients to automatically create a key pair and publish
the public key when you first run it if it can't find
an existing keypair? Pretty soon everyone would have
keypairs. Multiple devices would complicate things,
though.

I expect it would require Google and Microsoft to make
it happen automatically but Microsoft decided to charge
money to encrypt email and Google decided to make money
by analysing email content to improve advertising
effectiveness so I can't see them doing it any time
soon.

cheers,
raf

> On 10/29/2019 7:33 PM, raf via Gnupg-users wrote:
> > Hi,
> >
> > Sorry if this was mentioned before but I've just come
> > across a novel approach to email encryption that
> > doesn't do end-to-end encryption, but rather it
> > encrypts email upon receipt so that an individual can
> > encrypt the email that is stored in their IMAP account
> > as it arrives without the need for every sender to
> > encrypt and without the need for any service provider's
> > involvement (you just need an IMAP account), and it
> > supports reading email from multiple devices, each with
> > their own local private key. Most importantly, it
> > doesn't require the user to know anything about
> > encryption except that they want some.
> >
> > It might not address all threats but it certainly seems
> > to solve some very real threats, mainly the threat of
> > someone hacking into your IMAP account and accessing
> > every email you ever received.
> >
> >   Making It Easier to Encrypt Your Emails
> >   Authors: John S. Koh, Steven M. Bellovin, and Jason Nieh
> >   https://www.usenix.org/publications/login/fall2019/koh [paywall, usenix]
> >
> >   Why Joanie Can Encrypt: Easy Email Encryption with Easy Key Management
> >   EuroSys '19 Proceedings of the Fourteenth EuroSys Conference 2019
> >   Authors: John S. Koh, Steven M. Bellovin, Jason Nieh
> >   https://doi.org/10.1145/3302424.3303980 [paywall, acm]
> >   http://nieh.net/pubs/eurosys2019_e3.pdf [free]
> >
> >   Easy Email Encryption with Easy Key Management
> >   Authors: John S. Koh, Steven M. Bellovin, Jason Nieh
> >   https://mice.cs.columbia.edu/getTechreport.php?techreportID=1639 [free]
> >
> >   Automatically and invisibly encrypt email as soon as it is received on any trusted device
> >   https://www.helpnetsecurity.com/2019/04/01/easy-email-encryption/ [free]
> >
> > I know this doesn't help with the discussion of
> > improving GUIs to make it easier to encrypt emails that
> > you want to send, but it looks like a promising
> > improvement in privacy that could help many more people
> > than just those that want to encrypt emails that they
> > send. And it's still relevant. I expect that those that
> > want to encrypt any emails that they send might also
> > like all the emails that they receive to be encrypted
> > as well.
> >
> > cheers,
> > raf
> -- 
> -Ryan McGinnis
> https://bigstormpicture.com
> Sent via ProtonMail


From codeguro at gmail.com  Mon Nov  4 06:15:58 2019
From: codeguro at gmail.com (Tony Lane)
Date: Mon, 4 Nov 2019 00:15:58 -0500
Subject: How to decrypt a message while preserving the signature?
In-Reply-To: <965c0a4b-34be-c7fe-67cb-9de5f4748135@digitalbrains.com>
References: <c429fba9-b63f-a6c0-20ba-3a5053f8274e@gmail.com>
 <c429fba9-b63f-a6c0-20ba-3a5053f8274e@gmail.com> <87r22po2v3.fsf@netris.org>
 <87muddo2fc.fsf@netris.org>
 <965c0a4b-34be-c7fe-67cb-9de5f4748135@digitalbrains.com>
Message-ID: <4af8aaf3-9ea7-11bb-f295-08c05956eb2b@gmail.com>

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

On 11/3/19 4:15 AM, Peter Lebbing wrote:
> Werner recently mentioned an undocumented command for this.[1]
> 
> On 27/08/2019 11:30, Werner Koch via Gnupg-users wrote: 
>> You can extra the signature from the encrypted+signed data:
>>
>>   gpg --unwrap -d -o SIG <ENC+SIG
>>
>> and then run
>>
>>   gpgv -o SIGNEDFILE SIG && echo verified!
>>

The '--unwrap' option alone seems to work for me. Thanks for sharing this.

> --unwrap is not documented and has the minor problem that it also keeps the
compression layer

Why is keeping the compression layer a problem? Also what other undocumented options are out there?
Can they be documented somewhere?
-----BEGIN PGP SIGNATURE-----

iLgEARMKAB0WIQQWZv6JZKxO310TWtXo8fj9gx4T0wUCXb+0DgAKCRDo8fj9gx4T
0ymVAgkBa9tE9xyhk1sk3Tx+//yoawVxZmAQB3vy1u0QIShHqOPirYHwyQODH/Xw
NLYDpBZK9NthXLN5oq/FbmmBzqXm7H0CB1ditfCuvGdtslwzljGqzs6lbYCSp6N+
9pNGwHPPT5nduCKZSERfvgQRq7nJW/b+2bLU4CwvA28GiLr1LCj0cVqw
=B1yd
-----END PGP SIGNATURE-----


From gniibe at fsij.org  Mon Nov  4 11:15:29 2019
From: gniibe at fsij.org (Niibe Yutaka)
Date: Mon, 04 Nov 2019 19:15:29 +0900
Subject: gpg-agent only checks for smartcard not for local keys
In-Reply-To: <!&!AAAAAAAAAAAuAAAAAAAAAA5smRXHsmVElvboTNge148BAMO2jhD3dRHOtM0AqgC7tuYAAAAAAA4AABAAAAA1pjs8gCUES4JsO11aqjZrAQAAAAA=@skat-foundation.de>
References: <!&!AAAAAAAAAAAuAAAAAAAAAA5smRXHsmVElvboTNge148BAMO2jhD3dRHOtM0AqgC7tuYAAAAAAA4AABAAAAA1pjs8gCUES4JsO11aqjZrAQAAAAA=@skat-foundation.de>
Message-ID: <87lfswosla.fsf@jumper.gniibe.org>

Hello,

Horst Skatmus wrote:
> The only problem I have is that the gpg-agent always checks for the
> smartcard even when keys are not stored on a smartcard.

When gpg-agent works as ssh-agent, it always checks (possible)
authentication key on smartcard, so that the authenticaiton key (when
available) can be used.

Specifically, SSH client askes ssh-agent about available keys by
REQUEST_IDENTITIES command.  When gpg-agent (as ssh-agent) gets
REQUEST_IDENTITIES command, it checks scdaemon about possible
authentication keys.  Let's call those key(s) "active smartcard key(s)".
There are also keys recorded under ~/.gnupg/private-keys-v1.d/.  Let's
call those keys "recorded keys".  Those "recorded keys" can be private
keys on disk, or keys on smartcard (reference to smartcard, not private
key secret).  For response to REQUEST_IDENTITIES command, gpg-agent
answers SSH "active smartcard key(s)" + "recorded keys".
(Here, "recorded keys" may include "active smartcard key(s)".)

After that, SSH server + client negotiate about keys and select a key.
Then, SSH client asks gpg-agent (as ssh-agent) a challenge-response
authentication by signing with SIGN_REQUEST command.


> I can switch off the scdaemon via --disable-scdaemon but this has no
> effect.

With --disable-scdaemon, gpg-agent should stop accessing scdaemon.
Do you reload setting (gpgconf --reload gpg-agent) after changing
your gpg-agent.conf?
--


From noreply at informadb.pt  Mon Nov  4 05:46:08 2019
From: noreply at informadb.pt (Informa D&B)
Date: Mon, 4 Nov 2019 04:46:08 +0000 (GMT)
Subject: How to improve our GUIs (was: We have GOT TO make things
 simpler) [ ref:_00D58dJQM._5004IusXQj:ref ]
Message-ID: <FxS8m000000000000000000000000000000000000000000000Q0FH8W00PmlEWq3CR8mPLSk18zbbzA@sfdc.net>

Exmos. Senhores,

Recebemos a informa??o que tiveram hoje a amabilidade de nos transmitir e que muito agradecemos.

Vamos imediatamente analisar o caso e responderemos com a m?xima brevidade poss?vel ao vosso pedido. Assim que for poss?vel, o Servi?o de Apoio ao Cliente entrar? em contacto convosco.

No entanto, caso o vosso contacto esteja relacionado com a necessidade de atualizar os dados da vossa empresa na nossa base de dados, notem que poder?o faz?-lo diretamente e sem demoras.

De facto, as entidades empresariais cujos dados constem da nossa base de dados podem consultar, acrescentar e modificar on-line as informa??es que lhes digam respeito, sendo para tal apenas necess?rio que disponham de uma senha de acesso exclusivo a uma zona reservada do nosso site.

Sublinhamos que este acesso para atualiza??o on-line ? totalmente gratuito e muito f?cil, bastando entrar em www.informadb.pt e selecionar, em Feed?Back , " Para consultar atualizar os dados de uma empresa diretamente na nossa base de dados".

Se necessitarem de mais esclarecimentos sobre o Feed?Back ? Servi?o de Atualiza??o de Dados, estaremos inteiramente dispon?veis para os prestar.

Atenciosamente,

Servi?o de Apoio ao Cliente

(+351) 213 500 389 - Fax: (+351) 213 151 658
vipclientes at informadb.pt
www.informadb.pt

CONFIDENCIAL. Esta mensagem destina-se a uso exclusivo do(s) destinat?rio(s) e poder? conter informa??o privada ou confidencial. A leitura, reten??o, divulga??o, c?pia, distribui??o ou reencaminhamento s?o pro?bidas. Caso a receba por engano, solicitamos que nos comunique por e-mail e elimine a mensagem do seu sistema sem a reproduzir. Os dados pessoais constantes do presente e-mail est?o ou ser?o adicionados ? lista de contactos da INFORMA D&B, respons?vel pelo tratamento de dados, para o podermos contactar sempre que necess?rio . O direito de acesso, retifica??o, oposi??o e apagamento, dever? ser exercido atrav?s do e-mail: protecaodedados at informadb.pt. Consulte o nosso compromisso de privacidade em www.informadb.pt.

CONFIDENTIAL. This message is intended for the exclusive use of the named addressee(s) and it may contain private or confidential information. Any reading, retention, disclosure, copying, distribution or redirection is prohibited. If you are not the intended recipient, please notify us by e-mail and delete this message from your system without retaining a copy. The personal data included in this e-mail is or will be added to the contact list of INFORMA D&B, acting as data controller, to contact you whenever necessary. You have the right of access and the rights to rectification, to object and to erasure through the e-mail: protecaodedados at informadb.pt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20191104/d96fb77a/attachment-0001.html>

From noreply at informadb.pt  Mon Nov  4 06:44:27 2019
From: noreply at informadb.pt (Informa D&B)
Date: Mon, 4 Nov 2019 05:44:27 +0000 (GMT)
Subject: How to decrypt a message while preserving the signature? [
 ref:_00D58dJQM._5004IusXat:ref ]
Message-ID: <TR1RU000000000000000000000000000000000000000000000Q0FJY300QlTxa01bS0q4VRxpdURxTA@sfdc.net>

Exmos. Senhores,

Recebemos a informa??o que tiveram hoje a amabilidade de nos transmitir e que muito agradecemos.

Vamos imediatamente analisar o caso e responderemos com a m?xima brevidade poss?vel ao vosso pedido. Assim que for poss?vel, o Servi?o de Apoio ao Cliente entrar? em contacto convosco.

No entanto, caso o vosso contacto esteja relacionado com a necessidade de atualizar os dados da vossa empresa na nossa base de dados, notem que poder?o faz?-lo diretamente e sem demoras.

De facto, as entidades empresariais cujos dados constem da nossa base de dados podem consultar, acrescentar e modificar on-line as informa??es que lhes digam respeito, sendo para tal apenas necess?rio que disponham de uma senha de acesso exclusivo a uma zona reservada do nosso site.

Sublinhamos que este acesso para atualiza??o on-line ? totalmente gratuito e muito f?cil, bastando entrar em www.informadb.pt e selecionar, em Feed?Back , " Para consultar atualizar os dados de uma empresa diretamente na nossa base de dados".

Se necessitarem de mais esclarecimentos sobre o Feed?Back ? Servi?o de Atualiza??o de Dados, estaremos inteiramente dispon?veis para os prestar.

Atenciosamente,

Servi?o de Apoio ao Cliente

(+351) 213 500 389 - Fax: (+351) 213 151 658
vipclientes at informadb.pt
www.informadb.pt

CONFIDENCIAL. Esta mensagem destina-se a uso exclusivo do(s) destinat?rio(s) e poder? conter informa??o privada ou confidencial. A leitura, reten??o, divulga??o, c?pia, distribui??o ou reencaminhamento s?o pro?bidas. Caso a receba por engano, solicitamos que nos comunique por e-mail e elimine a mensagem do seu sistema sem a reproduzir. Os dados pessoais constantes do presente e-mail est?o ou ser?o adicionados ? lista de contactos da INFORMA D&B, respons?vel pelo tratamento de dados, para o podermos contactar sempre que necess?rio . O direito de acesso, retifica??o, oposi??o e apagamento, dever? ser exercido atrav?s do e-mail: protecaodedados at informadb.pt. Consulte o nosso compromisso de privacidade em www.informadb.pt.

CONFIDENTIAL. This message is intended for the exclusive use of the named addressee(s) and it may contain private or confidential information. Any reading, retention, disclosure, copying, distribution or redirection is prohibited. If you are not the intended recipient, please notify us by e-mail and delete this message from your system without retaining a copy. The personal data included in this e-mail is or will be added to the contact list of INFORMA D&B, acting as data controller, to contact you whenever necessary. You have the right of access and the rights to rectification, to object and to erasure through the e-mail: protecaodedados at informadb.pt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20191104/231fb596/attachment-0001.html>

From karel-v_g at tutanota.com  Mon Nov  4 08:58:19 2019
From: karel-v_g at tutanota.com (karel-v_g at tutanota.com)
Date: Mon, 4 Nov 2019 08:58:19 +0100 (CET)
Subject: BSI withdraws approval of GnuPG (revisited after 3 month)
Message-ID: <LsBvNQY--3-1@tutanota.com>

Hello!
In May 2019 the German Federal Office for Information security (Bundesamt f?r Sicherheit in der Informationstechnik, BSI [1]) approved GnuPG for securing data of the lowest security classification (VS Nur f?r den Dienstgebrauch, comparable to NATO Restricted). [2]
This approval was withdrawn for an unknown reason somewhen before July 21st 2019. Heise-Online reported this on August 6th 2019. According to them the BSI said it hopes to reissue the approval soon, but further inquiries remained unanswered. [3]
In a message to this list on August 8th Werner Koch said he is permanent contact with BSI and the reason for the withdrawal is in the OpenPGP part of GnuPG. Once again no further details were provided. [4]
Since then there is silence on the topic for the past three month.
As 90 days is the period we all know from Googles notorious Project Zero I would like to come back on the problem now.
Are there any news?
Should we consider our data protected by GnuPG insecure as german authorities obviously do?
Can or must we take any steps to eliminate or at least mitigate the problem in the current modern (2.2.17) and classic 1.4.23) versions of GnuPG (e.g. avoid compatibility options like ?openpgp)?
Is it a problem only with GnuPG or with OpenPGP in general? Are other implementations affected as well?
When can we expect further information?
Thanks
Karel

[1] www.bsi.de
[2] heise.de/~4416766
[3] heise.de/~4489547 (06.08)
[4]?lists.gnupg.org/pipermail/gnupg-users/2019-August/062520.html (09.08.)


From wk at gnupg.org  Mon Nov  4 12:28:41 2019
From: wk at gnupg.org (Werner Koch)
Date: Mon, 04 Nov 2019 12:28:41 +0100
Subject: How to decrypt a message while preserving the signature?
In-Reply-To: <965c0a4b-34be-c7fe-67cb-9de5f4748135@digitalbrains.com> (Peter
 Lebbing's message of "Sun, 3 Nov 2019 10:15:49 +0100")
References: <c429fba9-b63f-a6c0-20ba-3a5053f8274e@gmail.com>
 <c429fba9-b63f-a6c0-20ba-3a5053f8274e@gmail.com>
 <87r22po2v3.fsf@netris.org> <87muddo2fc.fsf@netris.org>
 <965c0a4b-34be-c7fe-67cb-9de5f4748135@digitalbrains.com>
Message-ID: <87k18f7udy.fsf@wheatstone.g10code.de>

On Sun,  3 Nov 2019 10:15, Peter Lebbing said:

>> --unwrap is not documented and has the minor problem that it also keeps the
>> compression layer.  However, gpgv groks that compression layer and works

I'll document it for future releases.


Salam-Shalom,

   Werner

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

From wk at gnupg.org  Mon Nov  4 12:46:03 2019
From: wk at gnupg.org (Werner Koch)
Date: Mon, 04 Nov 2019 12:46:03 +0100
Subject: gpg-agent only checks for smartcard not for local keys
In-Reply-To: <!&!AAAAAAAAAAAuAAAAAAAAAA5smRXHsmVElvboTNge148BAMO2jhD3dRHOtM0AqgC7tuYAAAAAAA4AABAAAAA1pjs8gCUES4JsO11aqjZrAQAAAAA=@skat-foundation.de>
 (Horst Skatmus's message of "Sat, 2 Nov 2019 12:20:07 +0100")
References: <!&!AAAAAAAAAAAuAAAAAAAAAA5smRXHsmVElvboTNge148BAMO2jhD3dRHOtM0AqgC7tuYAAAAAAA4AABAAAAA1pjs8gCUES4JsO11aqjZrAQAAAAA=@skat-foundation.de>
Message-ID: <87tv7jq2ys.fsf@wheatstone.g10code.de>

On Sat,  2 Nov 2019 12:20, Horst Skatmus said:

> I do not understand how the gpg-agent determines where to look for the
> private key (disk or smartcard) and where this is configured. I can switch
> off the scdaemon via --disable-scdaemon but this has no effect.

At the time you use ssh-add (putty has a similar feature iirc) the key
is copied to GnuPG's private key store and added to the file sshcontrol
in GnuPG home directory ("gpgconf --list-dirs" shows this).

You can add the key also manuualy to the file.  An entry there looks
like:

  # Ed25519 key added on: 2016-11-29 10:28:00
  # MD5 Fingerprint:  b5:f9:23:5f:b2:8c:b2:58:7d:b3:1e:f4:7e:26:33:7c
  1934563577D9EDA59D3CC74B0CF9C630EA3F302D 0

The header of the sshcontrol file has comments on the syntax.
In short you put the keygrip (as show in the KEYINFO lines or in
"gpg -k --with-keygrip") followed by the TTL for the cache
(0 for the default).

gpg-agend access the smartcard because the authenticstion key of an
inserted card is implicitly enabled for ssh.  Which key this is depends
on the card and gpg-agent knows how to query this.


Salam-Shalom,

   Werner

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

From wk at gnupg.org  Mon Nov  4 12:34:59 2019
From: wk at gnupg.org (Werner Koch)
Date: Mon, 04 Nov 2019 12:34:59 +0100
Subject: encrypt file in batch mode
In-Reply-To: <b8cd2eff-907a-28b7-ecc7-0297cd05e4c5@gmx.ch> (Fourhundred
 Thecat's message of "Sun, 3 Nov 2019 08:31:10 +0100")
References: <9962aeca-c896-7c64-03ef-a61ead1a9ba0@gmx.ch>
 <18bc863a-b5eb-8f63-7ccf-f104e68b9980@gmail.com>
 <451a1aff-d9a4-9baf-f786-db1e3d85ab3d@gmx.ch>
 <c7c71a8f-a7d0-7c18-a90a-c060e5384e84@gmail.com>
 <b633bf0f-6de5-28c0-1134-0045781e89ba@gmx.ch>
 <187da16e-f28d-dfb3-bb2f-cd661411b36e@gmail.com>
 <b8cd2eff-907a-28b7-ecc7-0297cd05e4c5@gmx.ch>
Message-ID: <87y2wvq3h8.fsf@wheatstone.g10code.de>

On Sun,  3 Nov 2019 08:31, Fourhundred Thecat said:

> $ gpg --list-secret-keys
> gpg: can't connect to the agent: No such file or directory
> gpg: failed to start agent '/usr/bin/gpg-agent': No such file or directory

Your system is not properly installed.  It is missing the gpg-agent
which is a mandatory part of GnuPG.  Except for some esoteric commands
there is no way to use gpg without gpg-agent.  The gpg-agent is used for
private keys as well as to provide a couple of other information like a
useful iteration count for the S2K mechanism.


Shalom-Salam,

   Werner

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

From silva at danwin1210.me  Mon Nov  4 13:39:00 2019
From: silva at danwin1210.me (Art Silva)
Date: Mon, 04 Nov 2019 12:39:00 +0000
Subject: BSI withdraws approval of GnuPG (revisited after 3 month)
In-Reply-To: <LsBvNQY--3-1@tutanota.com>
References: <LsBvNQY--3-1@tutanota.com>
Message-ID: <871ad1bf-f205-b8fd-8138-ec289281a7b8@danwin1210.me>

karel-v_g--- via Gnupg-users:
> In May 2019 the German Federal Office for Information security (Bundesamt f?r Sicherheit in der Informationstechnik, BSI [1]) approved GnuPG for securing data of the lowest security classification (VS Nur f?r den Dienstgebrauch, comparable to NATO Restricted). [2]

What do they approve for securing data of higher security classifications?


From v.cocaud at gmail.com  Mon Nov  4 15:16:26 2019
From: v.cocaud at gmail.com (Valentin Cocaud)
Date: Mon, 4 Nov 2019 07:16:26 -0700 (MST)
Subject: Yubikey keytocard: "Bad secret key"
In-Reply-To: <5db47951-9500-6fdc-f083-3542bbfbed6e@digitalbrains.com>
References: <81ffafa24469e91bc6164ddd431674b1@farhan.codes>
 <279DEE80-FF7A-47CE-9A11-083C9D5D08A5@andrewg.com>
 <b6b7129edd75f32706dce28a8d2b586a@farhan.codes>
 <5db47951-9500-6fdc-f083-3542bbfbed6e@digitalbrains.com>
Message-ID: <1572876986896-0.post@n7.nabble.com>

On Feb 18, 2019; 12:09pm, Peter Lebbing wrote:
> Maybe it has stopped doing that now,
> and you need to do:
>
> $ gpg --card-edit
> [...]
> gpg> key-attr
> 
> to select the desired key length before keytocard.
>
> At the moment, I don't have a version with key-attr at hand to quickly
> test myself.

Hi,

I have tested this for you with my Yubikey 5 NFC.
It worked like a charme. I can now move my 4096 RSA keys to my Yubikey
without any problem.

You have to enter in admin to enable `key-attr` command in the gpg console:

$ gpg --edit-card
gpg/card> admin
gpg/card> key-attr

Perhaps a more explicit error message could be a good thing.

Valentin.



--
Sent from: http://gnupg.10057.n7.nabble.com/GnuPG-User-f3.html


From v.cocaud at gmail.com  Mon Nov  4 15:36:35 2019
From: v.cocaud at gmail.com (Valentin Cocaud)
Date: Mon, 4 Nov 2019 07:36:35 -0700 (MST)
Subject: Yubikey keytocard: "Bad secret key"
In-Reply-To: <5db47951-9500-6fdc-f083-3542bbfbed6e@digitalbrains.com>
References: <81ffafa24469e91bc6164ddd431674b1@farhan.codes>
 <279DEE80-FF7A-47CE-9A11-083C9D5D08A5@andrewg.com>
 <b6b7129edd75f32706dce28a8d2b586a@farhan.codes>
 <5db47951-9500-6fdc-f083-3542bbfbed6e@digitalbrains.com>
Message-ID: <1572878195901-0.post@n7.nabble.com>

On Feb 18, 2019; 12:09pm, Peter Lebbing wrote:
> Maybe it has stopped doing that now,
> and you need to do:
>
> $ gpg --card-edit
> [...]
> gpg> key-attr
>
> to select the desired key length before keytocard.
>
> At the moment, I don't have a version with key-attr at hand to quickly
> test myself.

Hi,

I have tested this for you with my Yubikey 5 NFC.
It worked like a charme. I can now move my 4096 RSA keys to my Yubikey
without any problem.

You have to enter in admin to enable `key-attr` command in the gpg console:

$ gpg --edit-card
gpg/card> admin
gpg/card> key-attr

Perhaps a more explicit error message could be a good thing.

Valentin.



--
Sent from: http://gnupg.10057.n7.nabble.com/GnuPG-User-f3.html


From v.cocaud at gmail.com  Mon Nov  4 15:27:51 2019
From: v.cocaud at gmail.com (Valentin Cocaud)
Date: Mon, 4 Nov 2019 07:27:51 -0700 (MST)
Subject: Yubikey keytocard: "Bad secret key"
In-Reply-To: <5db47951-9500-6fdc-f083-3542bbfbed6e@digitalbrains.com>
References: <81ffafa24469e91bc6164ddd431674b1@farhan.codes>
 <279DEE80-FF7A-47CE-9A11-083C9D5D08A5@andrewg.com>
 <b6b7129edd75f32706dce28a8d2b586a@farhan.codes>
 <5db47951-9500-6fdc-f083-3542bbfbed6e@digitalbrains.com>
Message-ID: <1572877671727-0.post@n7.nabble.com>

On Feb 18, 2019; 12:09pm, Peter Lebbing wrote:
> Maybe it has stopped doing that now,
> and you need to do:
>
> $ gpg --card-edit
> [...]
> gpg> key-attr
>
> to select the desired key length before keytocard.
>
> At the moment, I don't have a version with key-attr at hand to quickly
> test myself.

Hi,

I have tested this for you with my Yubikey 5 NFC.
It worked like a charme. I can now move my 4096 RSA keys to my Yubikey
without any problem.

You have to enter in admin to enable `key-attr` command in the gpg console:

$ gpg --edit-card
gpg/card> admin
gpg/card> key-attr

Perhaps a more explicit error message could be a good thing.

Valentin.



--
Sent from: http://gnupg.10057.n7.nabble.com/GnuPG-User-f3.html


From 400thecat at gmx.ch  Mon Nov  4 16:49:01 2019
From: 400thecat at gmx.ch (Fourhundred Thecat)
Date: Mon, 4 Nov 2019 16:49:01 +0100
Subject: encrypt file in batch mode
In-Reply-To: <87y2wvq3h8.fsf@wheatstone.g10code.de>
References: <9962aeca-c896-7c64-03ef-a61ead1a9ba0@gmx.ch>
 <18bc863a-b5eb-8f63-7ccf-f104e68b9980@gmail.com>
 <451a1aff-d9a4-9baf-f786-db1e3d85ab3d@gmx.ch>
 <c7c71a8f-a7d0-7c18-a90a-c060e5384e84@gmail.com>
 <b633bf0f-6de5-28c0-1134-0045781e89ba@gmx.ch>
 <187da16e-f28d-dfb3-bb2f-cd661411b36e@gmail.com>
 <b8cd2eff-907a-28b7-ecc7-0297cd05e4c5@gmx.ch>
 <87y2wvq3h8.fsf@wheatstone.g10code.de>
Message-ID: <d22b312c-6e2c-9db0-144a-934a96fe3eb2@gmx.ch>

On 04/11/2019 12.34, Werner Koch wrote:
> On Sun,  3 Nov 2019 08:31, Fourhundred Thecat said:
>
>> $ gpg --list-secret-keys
>> gpg: can't connect to the agent: No such file or directory
>> gpg: failed to start agent '/usr/bin/gpg-agent': No such file or directory
>
> Your system is not properly installed.  It is missing the gpg-agent
> which is a mandatory part of GnuPG.  Except for some esoteric commands
> there is no way to use gpg without gpg-agent.  The gpg-agent is used for
> private keys as well as to provide a couple of other information like a
> useful iteration count for the S2K mechanism.

Yes, that is exactly the problem. Why should simple operations require
gpg agent ?

Imagine the authors of "cat" or "ls" decided that these utilities no
longer work without cat-agent or ls-agent.

What will be next? gpg will not work without gnome desktop ?







From wk at gnupg.org  Mon Nov  4 17:12:05 2019
From: wk at gnupg.org (Werner Koch)
Date: Mon, 04 Nov 2019 17:12:05 +0100
Subject: encrypt file in batch mode
In-Reply-To: <d22b312c-6e2c-9db0-144a-934a96fe3eb2@gmx.ch> (Fourhundred
 Thecat's message of "Mon, 4 Nov 2019 16:49:01 +0100")
References: <9962aeca-c896-7c64-03ef-a61ead1a9ba0@gmx.ch>
 <18bc863a-b5eb-8f63-7ccf-f104e68b9980@gmail.com>
 <451a1aff-d9a4-9baf-f786-db1e3d85ab3d@gmx.ch>
 <c7c71a8f-a7d0-7c18-a90a-c060e5384e84@gmail.com>
 <b633bf0f-6de5-28c0-1134-0045781e89ba@gmx.ch>
 <187da16e-f28d-dfb3-bb2f-cd661411b36e@gmail.com>
 <b8cd2eff-907a-28b7-ecc7-0297cd05e4c5@gmx.ch>
 <87y2wvq3h8.fsf@wheatstone.g10code.de>
 <d22b312c-6e2c-9db0-144a-934a96fe3eb2@gmx.ch>
Message-ID: <87pni7pqne.fsf@wheatstone.g10code.de>

On Mon,  4 Nov 2019 16:49, Fourhundred Thecat said:

> Yes, that is exactly the problem. Why should simple operations require
> gpg agent ?

The manual has a chapter on the architecture, please read it to
understand the design goals and how it was implemented nearly 20 years
ago.

> Imagine the authors of "cat" or "ls" decided that these utilities no

Separation of duties is an important part of the Unix philosophy.  Thus
we use gpg-agent to handle the operations which require private keys and
also for some minor things which benefit from being implemented in a
daemon.


Salam-Shalom,

   Werner


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

From wk at gnupg.org  Mon Nov  4 17:38:47 2019
From: wk at gnupg.org (Werner Koch)
Date: Mon, 04 Nov 2019 17:38:47 +0100
Subject: BSI withdraws approval of GnuPG (revisited after 3 month)
In-Reply-To: <LsBvNQY--3-1@tutanota.com> (karel-v's message of "Mon, 4 Nov
 2019 08:58:19 +0100 (CET)")
References: <LsBvNQY--3-1@tutanota.com>
Message-ID: <87lfsvppew.fsf@wheatstone.g10code.de>

On Mon,  4 Nov 2019 08:58, karel-v_g--- said:

> In a message to this list on August 8th Werner Koch said he is
> permanent contact with BSI and the reason for the withdrawal is in the
> OpenPGP part of GnuPG. Once again no further details were
> provided. [4]

We received a new approval BSI-VS-10400 dated Sep 9.  We have not yet
announced this widely except for a short notice at gnupg.com.  The
reason for this that we are still waiting for the promised
"Freigabeempfehlung" for the OpenPGP part.  That is a kind of approval
which allows to use OpenPGP without a smartcard.  Without such a
Freigabeempfehlung the public might have get the false idea that
the OpenPGP part is not secure.  But now, that you asked I better
explain what I know.

There seem to be different opinions at the BSI on whether a smartcard
should be mandatory for use with VS-NfD.  The whole thing is not a
technical issue but a pure political/organizational thing.  In fact the
current software used for VS-NfD (Chiasmus) does not use any smartcards
but a plain old proprietary 64 bit block length symmetric algorithms.
Users of VS-NfD are eagerly waiting for an easy migration path from that
legacy software to GnuPG (Gpg4win/Gpg4KDE).

> Should we consider our data protected by GnuPG insecure as german
> authorities obviously do?

No they don't.  They even use Gpg4win and GnuPG in house.

> Can or must we take any steps to eliminate or at least mitigate the
> problem in the current modern (2.2.17) and classic 1.4.23) versions of
> GnuPG (e.g. avoid compatibility options like ?openpgp)?

Nope.  All is fine and Gpg4win may be used for VS-Nfd if the SecOPs are
followed (e.g a Telesec NetKey 3.0 card is used for the S/MIME keys)

> Is it a problem only with GnuPG or with OpenPGP in general? Are other
> implementations affected as well?

No, there is no bug or issue except for the slow grinding bureaucratic
mills to get an approval for the OpenPGP and S/MIME without a smartcard.



Shalom-Salam,

   Werner


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

From rjh at sixdemonbag.org  Mon Nov  4 17:40:45 2019
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Mon, 4 Nov 2019 11:40:45 -0500
Subject: BSI withdraws approval of GnuPG (revisited after 3 month)
In-Reply-To: <LsBvNQY--3-1@tutanota.com>
References: <LsBvNQY--3-1@tutanota.com>
Message-ID: <23d180f7-be7c-15e1-13c3-54fe3d9cab41@sixdemonbag.org>

> Should we consider our data protected by GnuPG insecure as german authorities obviously do?

Whoa there, chief.  You're taking some *wild* leaps.  There is
absolutely no indication BSI believes OpenPGP is insecure.  It's just
that BSI believes OpenPGP doesn't meet their particular application
requirements.  This could be as simple as, "we prohibit the use of 3DES,
but OpenPGP lists it as a MUST algorithm".


From wk at gnupg.org  Mon Nov  4 17:40:44 2019
From: wk at gnupg.org (Werner Koch)
Date: Mon, 04 Nov 2019 17:40:44 +0100
Subject: BSI withdraws approval of GnuPG (revisited after 3 month)
In-Reply-To: <871ad1bf-f205-b8fd-8138-ec289281a7b8@danwin1210.me> (Art Silva
 via Gnupg-users's message of "Mon, 04 Nov 2019 12:39:00 +0000")
References: <LsBvNQY--3-1@tutanota.com>
 <871ad1bf-f205-b8fd-8138-ec289281a7b8@danwin1210.me>
Message-ID: <87h83jppbn.fsf@wheatstone.g10code.de>

On Mon,  4 Nov 2019 12:39, Art Silva said:

> What do they approve for securing data of higher security classifications?

There is a public list at:

<https://www.bsi.bund.de/DE/Themen/Sicherheitsberatung/ZugelasseneProdukte/Liste_Produkte/Liste_Produkte_node.html>


Salam-Shalom,

   Werner

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

From 400thecat at gmx.ch  Mon Nov  4 18:16:32 2019
From: 400thecat at gmx.ch (Fourhundred Thecat)
Date: Mon, 4 Nov 2019 18:16:32 +0100
Subject: encrypt file in batch mode
In-Reply-To: <87pni7pqne.fsf@wheatstone.g10code.de>
References: <9962aeca-c896-7c64-03ef-a61ead1a9ba0@gmx.ch>
 <18bc863a-b5eb-8f63-7ccf-f104e68b9980@gmail.com>
 <451a1aff-d9a4-9baf-f786-db1e3d85ab3d@gmx.ch>
 <c7c71a8f-a7d0-7c18-a90a-c060e5384e84@gmail.com>
 <b633bf0f-6de5-28c0-1134-0045781e89ba@gmx.ch>
 <187da16e-f28d-dfb3-bb2f-cd661411b36e@gmail.com>
 <b8cd2eff-907a-28b7-ecc7-0297cd05e4c5@gmx.ch>
 <87y2wvq3h8.fsf@wheatstone.g10code.de>
 <d22b312c-6e2c-9db0-144a-934a96fe3eb2@gmx.ch>
 <87pni7pqne.fsf@wheatstone.g10code.de>
Message-ID: <8dd9ff88-5c0d-2ab5-d807-1e45202d365f@gmx.ch>

On 04/11/2019 17.12, Werner Koch wrote:
> On Mon,  4 Nov 2019 16:49, Fourhundred Thecat said:
>> Imagine the authors of "cat" or "ls" decided that these utilities no
>
> Separation of duties is an important part of the Unix philosophy.  Thus
> we use gpg-agent to handle the operations which require private keys and
> also for some minor things which benefit from being implemented in a
> daemon.

Excuse me, but taking a core system utility and making it dependent on a
daemon running at all times is not Unix philosophy.



From wk at gnupg.org  Mon Nov  4 18:16:27 2019
From: wk at gnupg.org (Werner Koch)
Date: Mon, 04 Nov 2019 18:16:27 +0100
Subject: BSI withdraws approval of GnuPG (revisited after 3 month)
In-Reply-To: <23d180f7-be7c-15e1-13c3-54fe3d9cab41@sixdemonbag.org> (Robert
 J. Hansen's message of "Mon, 4 Nov 2019 11:40:45 -0500")
References: <LsBvNQY--3-1@tutanota.com>
 <23d180f7-be7c-15e1-13c3-54fe3d9cab41@sixdemonbag.org>
Message-ID: <87d0e7pno4.fsf@wheatstone.g10code.de>

On Mon,  4 Nov 2019 11:40, Robert J. Hansen said:

> requirements.  This could be as simple as, "we prohibit the use of 3DES,
> but OpenPGP lists it as a MUST algorithm".

It is even less technical see my other mail.

FWIW, GnuPG knows all allowed algorithms for the VS-NfD use case and can
be switched into a mode where this is enforced (for creating message) or
indicated with a warning (for reading a message).

  $ gpg --compliance=help
  gpg: valid values for option '--compliance':
  gpg:   gnupg
  gpg:   openpgp
  gpg:   rfc4880bis
  gpg:   rfc4880
  gpg:   rfc2440
  gpg:   pgp6
  gpg:   pgp7
  gpg:   pgp8
  gpg:   de-vs
  
Thus when VS-NfD is required the admin will configure gpg and gpgsm with
--compliance=de-vs.  Actually Kleopatra and GpgOL have GUI elements to
enable/show that mode.  One thing which sets us apart from other VS-NfD
products is that the very same software can be used for regular mail and
VS-NfD processing without switching.  The user experience is thus better
aligned to the real world use.


Shalom-Salam,

   Werner

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

From noreply at informadb.pt  Mon Nov  4 13:05:20 2019
From: noreply at informadb.pt (Informa D&B)
Date: Mon, 4 Nov 2019 12:05:20 +0000 (GMT)
Subject: BSI withdraws approval of GnuPG (revisited after 3 month) [
 ref:_00D58dJQM._5004IuseLG:ref ]
Message-ID: <l1pD-000000000000000000000000000000000000000000000Q0G1KW00G3dQfsoUR0WjhoaZ8NpfVg@sfdc.net>

Exmos. Senhores,

Recebemos a informa??o que tiveram hoje a amabilidade de nos transmitir e que muito agradecemos.

Vamos imediatamente analisar o caso e responderemos com a m?xima brevidade poss?vel ao vosso pedido. Assim que for poss?vel, o Servi?o de Apoio ao Cliente entrar? em contacto convosco.

No entanto, caso o vosso contacto esteja relacionado com a necessidade de atualizar os dados da vossa empresa na nossa base de dados, notem que poder?o faz?-lo diretamente e sem demoras.

De facto, as entidades empresariais cujos dados constem da nossa base de dados podem consultar, acrescentar e modificar on-line as informa??es que lhes digam respeito, sendo para tal apenas necess?rio que disponham de uma senha de acesso exclusivo a uma zona reservada do nosso site.

Sublinhamos que este acesso para atualiza??o on-line ? totalmente gratuito e muito f?cil, bastando entrar em www.informadb.pt e selecionar, em Feed?Back , " Para consultar atualizar os dados de uma empresa diretamente na nossa base de dados".

Se necessitarem de mais esclarecimentos sobre o Feed?Back ? Servi?o de Atualiza??o de Dados, estaremos inteiramente dispon?veis para os prestar.

Atenciosamente,

Servi?o de Apoio ao Cliente

(+351) 213 500 389 - Fax: (+351) 213 151 658
vipclientes at informadb.pt
www.informadb.pt

CONFIDENCIAL. Esta mensagem destina-se a uso exclusivo do(s) destinat?rio(s) e poder? conter informa??o privada ou confidencial. A leitura, reten??o, divulga??o, c?pia, distribui??o ou reencaminhamento s?o pro?bidas. Caso a receba por engano, solicitamos que nos comunique por e-mail e elimine a mensagem do seu sistema sem a reproduzir. Os dados pessoais constantes do presente e-mail est?o ou ser?o adicionados ? lista de contactos da INFORMA D&B, respons?vel pelo tratamento de dados, para o podermos contactar sempre que necess?rio . O direito de acesso, retifica??o, oposi??o e apagamento, dever? ser exercido atrav?s do e-mail: protecaodedados at informadb.pt. Consulte o nosso compromisso de privacidade em www.informadb.pt.

CONFIDENTIAL. This message is intended for the exclusive use of the named addressee(s) and it may contain private or confidential information. Any reading, retention, disclosure, copying, distribution or redirection is prohibited. If you are not the intended recipient, please notify us by e-mail and delete this message from your system without retaining a copy. The personal data included in this e-mail is or will be added to the contact list of INFORMA D&B, acting as data controller, to contact you whenever necessary. You have the right of access and the rights to rectification, to object and to erasure through the e-mail: protecaodedados at informadb.pt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20191104/f793a886/attachment-0001.html>

From noreply at informadb.pt  Mon Nov  4 14:02:36 2019
From: noreply at informadb.pt (Informa D&B)
Date: Mon, 4 Nov 2019 13:02:36 +0000 (GMT)
Subject: gpg-agent only checks for smartcard not for local keys [
 ref:_00D58dJQM._5004IusfwI:ref ]
Message-ID: <GPFbq000000000000000000000000000000000000000000000Q0G48C00V04et_DsSnOv2kc3NyqpCw@sfdc.net>

Exmos. Senhores,

Recebemos a informa??o que tiveram hoje a amabilidade de nos transmitir e que muito agradecemos.

Vamos imediatamente analisar o caso e responderemos com a m?xima brevidade poss?vel ao vosso pedido. Assim que for poss?vel, o Servi?o de Apoio ao Cliente entrar? em contacto convosco.

No entanto, caso o vosso contacto esteja relacionado com a necessidade de atualizar os dados da vossa empresa na nossa base de dados, notem que poder?o faz?-lo diretamente e sem demoras.

De facto, as entidades empresariais cujos dados constem da nossa base de dados podem consultar, acrescentar e modificar on-line as informa??es que lhes digam respeito, sendo para tal apenas necess?rio que disponham de uma senha de acesso exclusivo a uma zona reservada do nosso site.

Sublinhamos que este acesso para atualiza??o on-line ? totalmente gratuito e muito f?cil, bastando entrar em www.informadb.pt e selecionar, em Feed?Back , " Para consultar atualizar os dados de uma empresa diretamente na nossa base de dados".

Se necessitarem de mais esclarecimentos sobre o Feed?Back ? Servi?o de Atualiza??o de Dados, estaremos inteiramente dispon?veis para os prestar.

Atenciosamente,

Servi?o de Apoio ao Cliente

(+351) 213 500 389 - Fax: (+351) 213 151 658
vipclientes at informadb.pt
www.informadb.pt

CONFIDENCIAL. Esta mensagem destina-se a uso exclusivo do(s) destinat?rio(s) e poder? conter informa??o privada ou confidencial. A leitura, reten??o, divulga??o, c?pia, distribui??o ou reencaminhamento s?o pro?bidas. Caso a receba por engano, solicitamos que nos comunique por e-mail e elimine a mensagem do seu sistema sem a reproduzir. Os dados pessoais constantes do presente e-mail est?o ou ser?o adicionados ? lista de contactos da INFORMA D&B, respons?vel pelo tratamento de dados, para o podermos contactar sempre que necess?rio . O direito de acesso, retifica??o, oposi??o e apagamento, dever? ser exercido atrav?s do e-mail: protecaodedados at informadb.pt. Consulte o nosso compromisso de privacidade em www.informadb.pt.

CONFIDENTIAL. This message is intended for the exclusive use of the named addressee(s) and it may contain private or confidential information. Any reading, retention, disclosure, copying, distribution or redirection is prohibited. If you are not the intended recipient, please notify us by e-mail and delete this message from your system without retaining a copy. The personal data included in this e-mail is or will be added to the contact list of INFORMA D&B, acting as data controller, to contact you whenever necessary. You have the right of access and the rights to rectification, to object and to erasure through the e-mail: protecaodedados at informadb.pt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20191104/151d3686/attachment-0001.html>

From noreply at informadb.pt  Mon Nov  4 14:02:35 2019
From: noreply at informadb.pt (Informa D&B)
Date: Mon, 4 Nov 2019 13:02:35 +0000 (GMT)
Subject: How to decrypt a message while preserving the signature? [
 ref:_00D58dJQM._5004Iusfw8:ref ]
Message-ID: <L5i40000000000000000000000000000000000000000000000Q0G48B00jqe0lc6KS-qZ0IkaYMSlBg@sfdc.net>

Exmos. Senhores,

Recebemos a informa??o que tiveram hoje a amabilidade de nos transmitir e que muito agradecemos.

Vamos imediatamente analisar o caso e responderemos com a m?xima brevidade poss?vel ao vosso pedido. Assim que for poss?vel, o Servi?o de Apoio ao Cliente entrar? em contacto convosco.

No entanto, caso o vosso contacto esteja relacionado com a necessidade de atualizar os dados da vossa empresa na nossa base de dados, notem que poder?o faz?-lo diretamente e sem demoras.

De facto, as entidades empresariais cujos dados constem da nossa base de dados podem consultar, acrescentar e modificar on-line as informa??es que lhes digam respeito, sendo para tal apenas necess?rio que disponham de uma senha de acesso exclusivo a uma zona reservada do nosso site.

Sublinhamos que este acesso para atualiza??o on-line ? totalmente gratuito e muito f?cil, bastando entrar em www.informadb.pt e selecionar, em Feed?Back , " Para consultar atualizar os dados de uma empresa diretamente na nossa base de dados".

Se necessitarem de mais esclarecimentos sobre o Feed?Back ? Servi?o de Atualiza??o de Dados, estaremos inteiramente dispon?veis para os prestar.

Atenciosamente,

Servi?o de Apoio ao Cliente

(+351) 213 500 389 - Fax: (+351) 213 151 658
vipclientes at informadb.pt
www.informadb.pt

CONFIDENCIAL. Esta mensagem destina-se a uso exclusivo do(s) destinat?rio(s) e poder? conter informa??o privada ou confidencial. A leitura, reten??o, divulga??o, c?pia, distribui??o ou reencaminhamento s?o pro?bidas. Caso a receba por engano, solicitamos que nos comunique por e-mail e elimine a mensagem do seu sistema sem a reproduzir. Os dados pessoais constantes do presente e-mail est?o ou ser?o adicionados ? lista de contactos da INFORMA D&B, respons?vel pelo tratamento de dados, para o podermos contactar sempre que necess?rio . O direito de acesso, retifica??o, oposi??o e apagamento, dever? ser exercido atrav?s do e-mail: protecaodedados at informadb.pt. Consulte o nosso compromisso de privacidade em www.informadb.pt.

CONFIDENTIAL. This message is intended for the exclusive use of the named addressee(s) and it may contain private or confidential information. Any reading, retention, disclosure, copying, distribution or redirection is prohibited. If you are not the intended recipient, please notify us by e-mail and delete this message from your system without retaining a copy. The personal data included in this e-mail is or will be added to the contact list of INFORMA D&B, acting as data controller, to contact you whenever necessary. You have the right of access and the rights to rectification, to object and to erasure through the e-mail: protecaodedados at informadb.pt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20191104/3596eb1d/attachment-0001.html>

From noreply at informadb.pt  Mon Nov  4 14:02:32 2019
From: noreply at informadb.pt (Informa D&B)
Date: Mon, 4 Nov 2019 13:02:32 +0000 (GMT)
Subject: encrypt file in batch mode [ ref:_00D58dJQM._5004Iusfvy:ref ]
Message-ID: <bnfbp000000000000000000000000000000000000000000000Q0G48800WIpStxCzSw6kTQvVUG4Awg@sfdc.net>

Exmos. Senhores,

Recebemos a informa??o que tiveram hoje a amabilidade de nos transmitir e que muito agradecemos.

Vamos imediatamente analisar o caso e responderemos com a m?xima brevidade poss?vel ao vosso pedido. Assim que for poss?vel, o Servi?o de Apoio ao Cliente entrar? em contacto convosco.

No entanto, caso o vosso contacto esteja relacionado com a necessidade de atualizar os dados da vossa empresa na nossa base de dados, notem que poder?o faz?-lo diretamente e sem demoras.

De facto, as entidades empresariais cujos dados constem da nossa base de dados podem consultar, acrescentar e modificar on-line as informa??es que lhes digam respeito, sendo para tal apenas necess?rio que disponham de uma senha de acesso exclusivo a uma zona reservada do nosso site.

Sublinhamos que este acesso para atualiza??o on-line ? totalmente gratuito e muito f?cil, bastando entrar em www.informadb.pt e selecionar, em Feed?Back , " Para consultar atualizar os dados de uma empresa diretamente na nossa base de dados".

Se necessitarem de mais esclarecimentos sobre o Feed?Back ? Servi?o de Atualiza??o de Dados, estaremos inteiramente dispon?veis para os prestar.

Atenciosamente,

Servi?o de Apoio ao Cliente

(+351) 213 500 389 - Fax: (+351) 213 151 658
vipclientes at informadb.pt
www.informadb.pt

CONFIDENCIAL. Esta mensagem destina-se a uso exclusivo do(s) destinat?rio(s) e poder? conter informa??o privada ou confidencial. A leitura, reten??o, divulga??o, c?pia, distribui??o ou reencaminhamento s?o pro?bidas. Caso a receba por engano, solicitamos que nos comunique por e-mail e elimine a mensagem do seu sistema sem a reproduzir. Os dados pessoais constantes do presente e-mail est?o ou ser?o adicionados ? lista de contactos da INFORMA D&B, respons?vel pelo tratamento de dados, para o podermos contactar sempre que necess?rio . O direito de acesso, retifica??o, oposi??o e apagamento, dever? ser exercido atrav?s do e-mail: protecaodedados at informadb.pt. Consulte o nosso compromisso de privacidade em www.informadb.pt.

CONFIDENTIAL. This message is intended for the exclusive use of the named addressee(s) and it may contain private or confidential information. Any reading, retention, disclosure, copying, distribution or redirection is prohibited. If you are not the intended recipient, please notify us by e-mail and delete this message from your system without retaining a copy. The personal data included in this e-mail is or will be added to the contact list of INFORMA D&B, acting as data controller, to contact you whenever necessary. You have the right of access and the rights to rectification, to object and to erasure through the e-mail: protecaodedados at informadb.pt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20191104/3292815b/attachment-0001.html>

From noreply at informadb.pt  Mon Nov  4 15:48:13 2019
From: noreply at informadb.pt (Informa D&B)
Date: Mon, 4 Nov 2019 14:48:13 +0000 (GMT)
Subject: BSI withdraws approval of GnuPG (revisited after 3 month) [
 ref:_00D58dJQM._5004Iusj1u:ref ]
Message-ID: <QElBE000000000000000000000000000000000000000000000Q0G94D00byRZvj_wQTy4eAVwUqlieg@sfdc.net>

Exmos. Senhores,

Recebemos a informa??o que tiveram hoje a amabilidade de nos transmitir e que muito agradecemos.

Vamos imediatamente analisar o caso e responderemos com a m?xima brevidade poss?vel ao vosso pedido. Assim que for poss?vel, o Servi?o de Apoio ao Cliente entrar? em contacto convosco.

No entanto, caso o vosso contacto esteja relacionado com a necessidade de atualizar os dados da vossa empresa na nossa base de dados, notem que poder?o faz?-lo diretamente e sem demoras.

De facto, as entidades empresariais cujos dados constem da nossa base de dados podem consultar, acrescentar e modificar on-line as informa??es que lhes digam respeito, sendo para tal apenas necess?rio que disponham de uma senha de acesso exclusivo a uma zona reservada do nosso site.

Sublinhamos que este acesso para atualiza??o on-line ? totalmente gratuito e muito f?cil, bastando entrar em www.informadb.pt e selecionar, em Feed?Back , " Para consultar atualizar os dados de uma empresa diretamente na nossa base de dados".

Se necessitarem de mais esclarecimentos sobre o Feed?Back ? Servi?o de Atualiza??o de Dados, estaremos inteiramente dispon?veis para os prestar.

Atenciosamente,

Servi?o de Apoio ao Cliente

(+351) 213 500 389 - Fax: (+351) 213 151 658
vipclientes at informadb.pt
www.informadb.pt

CONFIDENCIAL. Esta mensagem destina-se a uso exclusivo do(s) destinat?rio(s) e poder? conter informa??o privada ou confidencial. A leitura, reten??o, divulga??o, c?pia, distribui??o ou reencaminhamento s?o pro?bidas. Caso a receba por engano, solicitamos que nos comunique por e-mail e elimine a mensagem do seu sistema sem a reproduzir. Os dados pessoais constantes do presente e-mail est?o ou ser?o adicionados ? lista de contactos da INFORMA D&B, respons?vel pelo tratamento de dados, para o podermos contactar sempre que necess?rio . O direito de acesso, retifica??o, oposi??o e apagamento, dever? ser exercido atrav?s do e-mail: protecaodedados at informadb.pt. Consulte o nosso compromisso de privacidade em www.informadb.pt.

CONFIDENTIAL. This message is intended for the exclusive use of the named addressee(s) and it may contain private or confidential information. Any reading, retention, disclosure, copying, distribution or redirection is prohibited. If you are not the intended recipient, please notify us by e-mail and delete this message from your system without retaining a copy. The personal data included in this e-mail is or will be added to the contact list of INFORMA D&B, acting as data controller, to contact you whenever necessary. You have the right of access and the rights to rectification, to object and to erasure through the e-mail: protecaodedados at informadb.pt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20191104/c1221b18/attachment-0001.html>

From noreply at informadb.pt  Mon Nov  4 16:29:11 2019
From: noreply at informadb.pt (Informa D&B)
Date: Mon, 4 Nov 2019 15:29:11 +0000 (GMT)
Subject: Yubikey keytocard: "Bad secret key" [
 ref:_00D58dJQM._5004Iusk9k:ref ]
Message-ID: <qerxF000000000000000000000000000000000000000000000Q0GB0N001_7kONXnRa-Y1e9jsaiAFA@sfdc.net>

Exmos. Senhores,

Recebemos a informa??o que tiveram hoje a amabilidade de nos transmitir e que muito agradecemos.

Vamos imediatamente analisar o caso e responderemos com a m?xima brevidade poss?vel ao vosso pedido. Assim que for poss?vel, o Servi?o de Apoio ao Cliente entrar? em contacto convosco.

No entanto, caso o vosso contacto esteja relacionado com a necessidade de atualizar os dados da vossa empresa na nossa base de dados, notem que poder?o faz?-lo diretamente e sem demoras.

De facto, as entidades empresariais cujos dados constem da nossa base de dados podem consultar, acrescentar e modificar on-line as informa??es que lhes digam respeito, sendo para tal apenas necess?rio que disponham de uma senha de acesso exclusivo a uma zona reservada do nosso site.

Sublinhamos que este acesso para atualiza??o on-line ? totalmente gratuito e muito f?cil, bastando entrar em www.informadb.pt e selecionar, em Feed?Back , " Para consultar atualizar os dados de uma empresa diretamente na nossa base de dados".

Se necessitarem de mais esclarecimentos sobre o Feed?Back ? Servi?o de Atualiza??o de Dados, estaremos inteiramente dispon?veis para os prestar.

Atenciosamente,

Servi?o de Apoio ao Cliente

(+351) 213 500 389 - Fax: (+351) 213 151 658
vipclientes at informadb.pt
www.informadb.pt

CONFIDENCIAL. Esta mensagem destina-se a uso exclusivo do(s) destinat?rio(s) e poder? conter informa??o privada ou confidencial. A leitura, reten??o, divulga??o, c?pia, distribui??o ou reencaminhamento s?o pro?bidas. Caso a receba por engano, solicitamos que nos comunique por e-mail e elimine a mensagem do seu sistema sem a reproduzir. Os dados pessoais constantes do presente e-mail est?o ou ser?o adicionados ? lista de contactos da INFORMA D&B, respons?vel pelo tratamento de dados, para o podermos contactar sempre que necess?rio . O direito de acesso, retifica??o, oposi??o e apagamento, dever? ser exercido atrav?s do e-mail: protecaodedados at informadb.pt. Consulte o nosso compromisso de privacidade em www.informadb.pt.

CONFIDENTIAL. This message is intended for the exclusive use of the named addressee(s) and it may contain private or confidential information. Any reading, retention, disclosure, copying, distribution or redirection is prohibited. If you are not the intended recipient, please notify us by e-mail and delete this message from your system without retaining a copy. The personal data included in this e-mail is or will be added to the contact list of INFORMA D&B, acting as data controller, to contact you whenever necessary. You have the right of access and the rights to rectification, to object and to erasure through the e-mail: protecaodedados at informadb.pt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20191104/fc06a0b7/attachment-0001.html>

From noreply at informadb.pt  Mon Nov  4 16:42:10 2019
From: noreply at informadb.pt (Informa D&B)
Date: Mon, 4 Nov 2019 15:42:10 +0000 (GMT)
Subject: Yubikey keytocard: "Bad secret key" [
 ref:_00D58dJQM._5004IuskUi:ref ]
Message-ID: <4KL1g000000000000000000000000000000000000000000000Q0GBMA0060uAA4CBQOK6XMYUSKQR4g@sfdc.net>

Exmos. Senhores,

Recebemos a informa??o que tiveram hoje a amabilidade de nos transmitir e que muito agradecemos.

Vamos imediatamente analisar o caso e responderemos com a m?xima brevidade poss?vel ao vosso pedido. Assim que for poss?vel, o Servi?o de Apoio ao Cliente entrar? em contacto convosco.

No entanto, caso o vosso contacto esteja relacionado com a necessidade de atualizar os dados da vossa empresa na nossa base de dados, notem que poder?o faz?-lo diretamente e sem demoras.

De facto, as entidades empresariais cujos dados constem da nossa base de dados podem consultar, acrescentar e modificar on-line as informa??es que lhes digam respeito, sendo para tal apenas necess?rio que disponham de uma senha de acesso exclusivo a uma zona reservada do nosso site.

Sublinhamos que este acesso para atualiza??o on-line ? totalmente gratuito e muito f?cil, bastando entrar em www.informadb.pt e selecionar, em Feed?Back , " Para consultar atualizar os dados de uma empresa diretamente na nossa base de dados".

Se necessitarem de mais esclarecimentos sobre o Feed?Back ? Servi?o de Atualiza??o de Dados, estaremos inteiramente dispon?veis para os prestar.

Atenciosamente,

Servi?o de Apoio ao Cliente

(+351) 213 500 389 - Fax: (+351) 213 151 658
vipclientes at informadb.pt
www.informadb.pt

CONFIDENCIAL. Esta mensagem destina-se a uso exclusivo do(s) destinat?rio(s) e poder? conter informa??o privada ou confidencial. A leitura, reten??o, divulga??o, c?pia, distribui??o ou reencaminhamento s?o pro?bidas. Caso a receba por engano, solicitamos que nos comunique por e-mail e elimine a mensagem do seu sistema sem a reproduzir. Os dados pessoais constantes do presente e-mail est?o ou ser?o adicionados ? lista de contactos da INFORMA D&B, respons?vel pelo tratamento de dados, para o podermos contactar sempre que necess?rio . O direito de acesso, retifica??o, oposi??o e apagamento, dever? ser exercido atrav?s do e-mail: protecaodedados at informadb.pt. Consulte o nosso compromisso de privacidade em www.informadb.pt.

CONFIDENTIAL. This message is intended for the exclusive use of the named addressee(s) and it may contain private or confidential information. Any reading, retention, disclosure, copying, distribution or redirection is prohibited. If you are not the intended recipient, please notify us by e-mail and delete this message from your system without retaining a copy. The personal data included in this e-mail is or will be added to the contact list of INFORMA D&B, acting as data controller, to contact you whenever necessary. You have the right of access and the rights to rectification, to object and to erasure through the e-mail: protecaodedados at informadb.pt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20191104/ca3bfb6b/attachment-0001.html>

From noreply at informadb.pt  Mon Nov  4 16:38:16 2019
From: noreply at informadb.pt (Informa D&B)
Date: Mon, 4 Nov 2019 15:38:16 +0000 (GMT)
Subject: Yubikey keytocard: "Bad secret key" [
 ref:_00D58dJQM._5004IuskP9:ref ]
Message-ID: <N2yGw000000000000000000000000000000000000000000000Q0GBFS00PZ1hfr_eQe2J-LakBArf_A@sfdc.net>

Exmos. Senhores,

Recebemos a informa??o que tiveram hoje a amabilidade de nos transmitir e que muito agradecemos.

Vamos imediatamente analisar o caso e responderemos com a m?xima brevidade poss?vel ao vosso pedido. Assim que for poss?vel, o Servi?o de Apoio ao Cliente entrar? em contacto convosco.

No entanto, caso o vosso contacto esteja relacionado com a necessidade de atualizar os dados da vossa empresa na nossa base de dados, notem que poder?o faz?-lo diretamente e sem demoras.

De facto, as entidades empresariais cujos dados constem da nossa base de dados podem consultar, acrescentar e modificar on-line as informa??es que lhes digam respeito, sendo para tal apenas necess?rio que disponham de uma senha de acesso exclusivo a uma zona reservada do nosso site.

Sublinhamos que este acesso para atualiza??o on-line ? totalmente gratuito e muito f?cil, bastando entrar em www.informadb.pt e selecionar, em Feed?Back , " Para consultar atualizar os dados de uma empresa diretamente na nossa base de dados".

Se necessitarem de mais esclarecimentos sobre o Feed?Back ? Servi?o de Atualiza??o de Dados, estaremos inteiramente dispon?veis para os prestar.

Atenciosamente,

Servi?o de Apoio ao Cliente

(+351) 213 500 389 - Fax: (+351) 213 151 658
vipclientes at informadb.pt
www.informadb.pt

CONFIDENCIAL. Esta mensagem destina-se a uso exclusivo do(s) destinat?rio(s) e poder? conter informa??o privada ou confidencial. A leitura, reten??o, divulga??o, c?pia, distribui??o ou reencaminhamento s?o pro?bidas. Caso a receba por engano, solicitamos que nos comunique por e-mail e elimine a mensagem do seu sistema sem a reproduzir. Os dados pessoais constantes do presente e-mail est?o ou ser?o adicionados ? lista de contactos da INFORMA D&B, respons?vel pelo tratamento de dados, para o podermos contactar sempre que necess?rio . O direito de acesso, retifica??o, oposi??o e apagamento, dever? ser exercido atrav?s do e-mail: protecaodedados at informadb.pt. Consulte o nosso compromisso de privacidade em www.informadb.pt.

CONFIDENTIAL. This message is intended for the exclusive use of the named addressee(s) and it may contain private or confidential information. Any reading, retention, disclosure, copying, distribution or redirection is prohibited. If you are not the intended recipient, please notify us by e-mail and delete this message from your system without retaining a copy. The personal data included in this e-mail is or will be added to the contact list of INFORMA D&B, acting as data controller, to contact you whenever necessary. You have the right of access and the rights to rectification, to object and to erasure through the e-mail: protecaodedados at informadb.pt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20191104/854a7a82/attachment-0001.html>

From noreply at informadb.pt  Mon Nov  4 17:23:17 2019
From: noreply at informadb.pt (Informa D&B)
Date: Mon, 4 Nov 2019 16:23:17 +0000 (GMT)
Subject: encrypt file in batch mode [ ref:_00D58dJQM._5004IuslU0:ref ]
Message-ID: <d6GY1000000000000000000000000000000000000000000000Q0GDIT00hHEMTMyiSSWKdzsMTqfOJw@sfdc.net>

Exmos. Senhores,

Recebemos a informa??o que tiveram hoje a amabilidade de nos transmitir e que muito agradecemos.

Vamos imediatamente analisar o caso e responderemos com a m?xima brevidade poss?vel ao vosso pedido. Assim que for poss?vel, o Servi?o de Apoio ao Cliente entrar? em contacto convosco.

No entanto, caso o vosso contacto esteja relacionado com a necessidade de atualizar os dados da vossa empresa na nossa base de dados, notem que poder?o faz?-lo diretamente e sem demoras.

De facto, as entidades empresariais cujos dados constem da nossa base de dados podem consultar, acrescentar e modificar on-line as informa??es que lhes digam respeito, sendo para tal apenas necess?rio que disponham de uma senha de acesso exclusivo a uma zona reservada do nosso site.

Sublinhamos que este acesso para atualiza??o on-line ? totalmente gratuito e muito f?cil, bastando entrar em www.informadb.pt e selecionar, em Feed?Back , " Para consultar atualizar os dados de uma empresa diretamente na nossa base de dados".

Se necessitarem de mais esclarecimentos sobre o Feed?Back ? Servi?o de Atualiza??o de Dados, estaremos inteiramente dispon?veis para os prestar.

Atenciosamente,

Servi?o de Apoio ao Cliente

(+351) 213 500 389 - Fax: (+351) 213 151 658
vipclientes at informadb.pt
www.informadb.pt

CONFIDENCIAL. Esta mensagem destina-se a uso exclusivo do(s) destinat?rio(s) e poder? conter informa??o privada ou confidencial. A leitura, reten??o, divulga??o, c?pia, distribui??o ou reencaminhamento s?o pro?bidas. Caso a receba por engano, solicitamos que nos comunique por e-mail e elimine a mensagem do seu sistema sem a reproduzir. Os dados pessoais constantes do presente e-mail est?o ou ser?o adicionados ? lista de contactos da INFORMA D&B, respons?vel pelo tratamento de dados, para o podermos contactar sempre que necess?rio . O direito de acesso, retifica??o, oposi??o e apagamento, dever? ser exercido atrav?s do e-mail: protecaodedados at informadb.pt. Consulte o nosso compromisso de privacidade em www.informadb.pt.

CONFIDENTIAL. This message is intended for the exclusive use of the named addressee(s) and it may contain private or confidential information. Any reading, retention, disclosure, copying, distribution or redirection is prohibited. If you are not the intended recipient, please notify us by e-mail and delete this message from your system without retaining a copy. The personal data included in this e-mail is or will be added to the contact list of INFORMA D&B, acting as data controller, to contact you whenever necessary. You have the right of access and the rights to rectification, to object and to erasure through the e-mail: protecaodedados at informadb.pt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20191104/3b2daf05/attachment-0001.html>

From noreply at informadb.pt  Mon Nov  4 17:45:01 2019
From: noreply at informadb.pt (Informa D&B)
Date: Mon, 4 Nov 2019 16:45:01 +0000 (GMT)
Subject: BSI withdraws approval of GnuPG (revisited after 3 month) [
 ref:_00D58dJQM._5004IuslwT:ref ]
Message-ID: <MqSpM000000000000000000000000000000000000000000000Q0GEJ1001_IvKBLcToupgAWAr80QJw@sfdc.net>

Exmos. Senhores,

Recebemos a informa??o que tiveram hoje a amabilidade de nos transmitir e que muito agradecemos.

Vamos imediatamente analisar o caso e responderemos com a m?xima brevidade poss?vel ao vosso pedido. Assim que for poss?vel, o Servi?o de Apoio ao Cliente entrar? em contacto convosco.

No entanto, caso o vosso contacto esteja relacionado com a necessidade de atualizar os dados da vossa empresa na nossa base de dados, notem que poder?o faz?-lo diretamente e sem demoras.

De facto, as entidades empresariais cujos dados constem da nossa base de dados podem consultar, acrescentar e modificar on-line as informa??es que lhes digam respeito, sendo para tal apenas necess?rio que disponham de uma senha de acesso exclusivo a uma zona reservada do nosso site.

Sublinhamos que este acesso para atualiza??o on-line ? totalmente gratuito e muito f?cil, bastando entrar em www.informadb.pt e selecionar, em Feed?Back , " Para consultar atualizar os dados de uma empresa diretamente na nossa base de dados".

Se necessitarem de mais esclarecimentos sobre o Feed?Back ? Servi?o de Atualiza??o de Dados, estaremos inteiramente dispon?veis para os prestar.

Atenciosamente,

Servi?o de Apoio ao Cliente

(+351) 213 500 389 - Fax: (+351) 213 151 658
vipclientes at informadb.pt
www.informadb.pt

CONFIDENCIAL. Esta mensagem destina-se a uso exclusivo do(s) destinat?rio(s) e poder? conter informa??o privada ou confidencial. A leitura, reten??o, divulga??o, c?pia, distribui??o ou reencaminhamento s?o pro?bidas. Caso a receba por engano, solicitamos que nos comunique por e-mail e elimine a mensagem do seu sistema sem a reproduzir. Os dados pessoais constantes do presente e-mail est?o ou ser?o adicionados ? lista de contactos da INFORMA D&B, respons?vel pelo tratamento de dados, para o podermos contactar sempre que necess?rio . O direito de acesso, retifica??o, oposi??o e apagamento, dever? ser exercido atrav?s do e-mail: protecaodedados at informadb.pt. Consulte o nosso compromisso de privacidade em www.informadb.pt.

CONFIDENTIAL. This message is intended for the exclusive use of the named addressee(s) and it may contain private or confidential information. Any reading, retention, disclosure, copying, distribution or redirection is prohibited. If you are not the intended recipient, please notify us by e-mail and delete this message from your system without retaining a copy. The personal data included in this e-mail is or will be added to the contact list of INFORMA D&B, acting as data controller, to contact you whenever necessary. You have the right of access and the rights to rectification, to object and to erasure through the e-mail: protecaodedados at informadb.pt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20191104/617b6fd3/attachment-0001.html>

From noreply at informadb.pt  Mon Nov  4 17:46:35 2019
From: noreply at informadb.pt (Informa D&B)
Date: Mon, 4 Nov 2019 16:46:35 +0000 (GMT)
Subject: BSI withdraws approval of GnuPG (revisited after 3 month) [
 ref:_00D58dJQM._5004IuslyU:ref ]
Message-ID: <P3UaK000000000000000000000000000000000000000000000Q0GELN00EAXL3x2FR7eiOVGZJG_DMA@sfdc.net>

Exmos. Senhores,

Recebemos a informa??o que tiveram hoje a amabilidade de nos transmitir e que muito agradecemos.

Vamos imediatamente analisar o caso e responderemos com a m?xima brevidade poss?vel ao vosso pedido. Assim que for poss?vel, o Servi?o de Apoio ao Cliente entrar? em contacto convosco.

No entanto, caso o vosso contacto esteja relacionado com a necessidade de atualizar os dados da vossa empresa na nossa base de dados, notem que poder?o faz?-lo diretamente e sem demoras.

De facto, as entidades empresariais cujos dados constem da nossa base de dados podem consultar, acrescentar e modificar on-line as informa??es que lhes digam respeito, sendo para tal apenas necess?rio que disponham de uma senha de acesso exclusivo a uma zona reservada do nosso site.

Sublinhamos que este acesso para atualiza??o on-line ? totalmente gratuito e muito f?cil, bastando entrar em www.informadb.pt e selecionar, em Feed?Back , " Para consultar atualizar os dados de uma empresa diretamente na nossa base de dados".

Se necessitarem de mais esclarecimentos sobre o Feed?Back ? Servi?o de Atualiza??o de Dados, estaremos inteiramente dispon?veis para os prestar.

Atenciosamente,

Servi?o de Apoio ao Cliente

(+351) 213 500 389 - Fax: (+351) 213 151 658
vipclientes at informadb.pt
www.informadb.pt

CONFIDENCIAL. Esta mensagem destina-se a uso exclusivo do(s) destinat?rio(s) e poder? conter informa??o privada ou confidencial. A leitura, reten??o, divulga??o, c?pia, distribui??o ou reencaminhamento s?o pro?bidas. Caso a receba por engano, solicitamos que nos comunique por e-mail e elimine a mensagem do seu sistema sem a reproduzir. Os dados pessoais constantes do presente e-mail est?o ou ser?o adicionados ? lista de contactos da INFORMA D&B, respons?vel pelo tratamento de dados, para o podermos contactar sempre que necess?rio . O direito de acesso, retifica??o, oposi??o e apagamento, dever? ser exercido atrav?s do e-mail: protecaodedados at informadb.pt. Consulte o nosso compromisso de privacidade em www.informadb.pt.

CONFIDENTIAL. This message is intended for the exclusive use of the named addressee(s) and it may contain private or confidential information. Any reading, retention, disclosure, copying, distribution or redirection is prohibited. If you are not the intended recipient, please notify us by e-mail and delete this message from your system without retaining a copy. The personal data included in this e-mail is or will be added to the contact list of INFORMA D&B, acting as data controller, to contact you whenever necessary. You have the right of access and the rights to rectification, to object and to erasure through the e-mail: protecaodedados at informadb.pt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20191104/ee34197c/attachment.html>

From noreply at informadb.pt  Mon Nov  4 18:30:32 2019
From: noreply at informadb.pt (Informa D&B)
Date: Mon, 4 Nov 2019 17:30:32 +0000 (GMT)
Subject: BSI withdraws approval of GnuPG (revisited after 3 month) [
 ref:_00D58dJQM._5004IusmqH:ref ]
Message-ID: <DfzCU000000000000000000000000000000000000000000000Q0GGMW00N9XteJFGS0K9XRH3WxIUQQ@sfdc.net>

Exmos. Senhores,

Recebemos a informa??o que tiveram hoje a amabilidade de nos transmitir e que muito agradecemos.

Vamos imediatamente analisar o caso e responderemos com a m?xima brevidade poss?vel ao vosso pedido. Assim que for poss?vel, o Servi?o de Apoio ao Cliente entrar? em contacto convosco.

No entanto, caso o vosso contacto esteja relacionado com a necessidade de atualizar os dados da vossa empresa na nossa base de dados, notem que poder?o faz?-lo diretamente e sem demoras.

De facto, as entidades empresariais cujos dados constem da nossa base de dados podem consultar, acrescentar e modificar on-line as informa??es que lhes digam respeito, sendo para tal apenas necess?rio que disponham de uma senha de acesso exclusivo a uma zona reservada do nosso site.

Sublinhamos que este acesso para atualiza??o on-line ? totalmente gratuito e muito f?cil, bastando entrar em www.informadb.pt e selecionar, em Feed?Back , " Para consultar atualizar os dados de uma empresa diretamente na nossa base de dados".

Se necessitarem de mais esclarecimentos sobre o Feed?Back ? Servi?o de Atualiza??o de Dados, estaremos inteiramente dispon?veis para os prestar.

Atenciosamente,

Servi?o de Apoio ao Cliente

(+351) 213 500 389 - Fax: (+351) 213 151 658
vipclientes at informadb.pt
www.informadb.pt

CONFIDENCIAL. Esta mensagem destina-se a uso exclusivo do(s) destinat?rio(s) e poder? conter informa??o privada ou confidencial. A leitura, reten??o, divulga??o, c?pia, distribui??o ou reencaminhamento s?o pro?bidas. Caso a receba por engano, solicitamos que nos comunique por e-mail e elimine a mensagem do seu sistema sem a reproduzir. Os dados pessoais constantes do presente e-mail est?o ou ser?o adicionados ? lista de contactos da INFORMA D&B, respons?vel pelo tratamento de dados, para o podermos contactar sempre que necess?rio . O direito de acesso, retifica??o, oposi??o e apagamento, dever? ser exercido atrav?s do e-mail: protecaodedados at informadb.pt. Consulte o nosso compromisso de privacidade em www.informadb.pt.

CONFIDENTIAL. This message is intended for the exclusive use of the named addressee(s) and it may contain private or confidential information. Any reading, retention, disclosure, copying, distribution or redirection is prohibited. If you are not the intended recipient, please notify us by e-mail and delete this message from your system without retaining a copy. The personal data included in this e-mail is or will be added to the contact list of INFORMA D&B, acting as data controller, to contact you whenever necessary. You have the right of access and the rights to rectification, to object and to erasure through the e-mail: protecaodedados at informadb.pt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20191104/673c03e2/attachment.html>

From sac at 300baud.de  Mon Nov  4 23:54:21 2019
From: sac at 300baud.de (Stefan Claas)
Date: Mon, 4 Nov 2019 23:54:21 +0100
Subject: Now we can comment and chat at gnupg.org, so to speak ...
Message-ID: <20191104235421.0000776b.sac@300baud.de>

Hi all,

I just discovered Dissenter:

https://dissenter.com/

and it allows us, once we have installed the Browser extension
and have registered, to leave a message and replies ... :-)

Regards
Stefan

-- 
box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56
  certified OpenPGP key blocks available on keybase.io/stefan_claas
           


From codeguro at gmail.com  Tue Nov  5 00:10:21 2019
From: codeguro at gmail.com (Tony Lane)
Date: Mon, 4 Nov 2019 18:10:21 -0500
Subject: encrypt file in batch mode
In-Reply-To: <87pni7pqne.fsf@wheatstone.g10code.de>
References: <9962aeca-c896-7c64-03ef-a61ead1a9ba0@gmx.ch>
 <18bc863a-b5eb-8f63-7ccf-f104e68b9980@gmail.com>
 <451a1aff-d9a4-9baf-f786-db1e3d85ab3d@gmx.ch>
 <c7c71a8f-a7d0-7c18-a90a-c060e5384e84@gmail.com>
 <b633bf0f-6de5-28c0-1134-0045781e89ba@gmx.ch>
 <187da16e-f28d-dfb3-bb2f-cd661411b36e@gmail.com>
 <b8cd2eff-907a-28b7-ecc7-0297cd05e4c5@gmx.ch>
 <87y2wvq3h8.fsf@wheatstone.g10code.de>
 <d22b312c-6e2c-9db0-144a-934a96fe3eb2@gmx.ch>
 <87pni7pqne.fsf@wheatstone.g10code.de>
Message-ID: <00d56c9e-e2a2-c7d6-04d9-0ca5116d4955@gmail.com>

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

On 11/4/19 11:12 AM, Werner Koch via Gnupg-users wrote:
> Separation of duties is an important part of the Unix philosophy.  Thus
> we use gpg-agent to handle the operations which require private keys and
> also for some minor things which benefit from being implemented in a
> daemon.

I must disagree here. GPG is modular, and it's monolithic. A piece of software is modular if it is decomposable into distinct functional units such that each unit addresses a specific concern. This- the gpg-agent seems to do very well.
A piece of software is monolithic if its components (if it has any at all) are tightly coupled--that is, components logically depend on one another to the point where using them in different contexts requires re-implementing the missing ones. The point is, despite the fact that gpg-agent (and tools) is comprised of multiple binaries, the hierarchical logical coupling between them means that it is more accurate to think of them parts of the same program as a unit that just happens to run in separate address spaces. They are not truly independent, composable programs.
I do not think that it was the intent to develop gpg-agent as an interface that could be replaced by some other agent but instead to be run, as you said, as a daemon that provides helper functions in the background. For this reason I think it was a mistake to decouple the gpg-agent from the gpg core in this way, and to say that this agent was made with the unix philosophy in mind. Perhaps it would've been better to write the gpg-agent as a shared library to be called by the core instead. Well, we're probably too far down down the rabbit hole to change that now.

Oh, wait, it's free software. We _can_ change it. And redistribute those changes.
God I love free software. So, any volunteers?
-----BEGIN PGP SIGNATURE-----

iLgEARMKAB0WIQQWZv6JZKxO310TWtXo8fj9gx4T0wUCXcCv3QAKCRDo8fj9gx4T
0wkfAgi2GmWiK9QQYSPex3lsOMF3zXZfu6n7127S5WSD3aHoUbPPYN8N+i2oLrlc
jQN6qcMEPE05GUfTw3RjXHH7Bu7z0AIJASPN2So5cfFHwaaVkIgGByouWelr4yup
zqagTyVwGDagDqBiZhYxZEzIxWeAWFGkotZkClopwV8V1aLKPWjWhMEE
=+l7e
-----END PGP SIGNATURE-----


From wk at gnupg.org  Tue Nov  5 08:57:23 2019
From: wk at gnupg.org (Werner Koch)
Date: Tue, 05 Nov 2019 08:57:23 +0100
Subject: encrypt file in batch mode
In-Reply-To: <00d56c9e-e2a2-c7d6-04d9-0ca5116d4955@gmail.com> (Tony Lane via
 Gnupg-users's message of "Mon, 4 Nov 2019 18:10:21 -0500")
References: <9962aeca-c896-7c64-03ef-a61ead1a9ba0@gmx.ch>
 <18bc863a-b5eb-8f63-7ccf-f104e68b9980@gmail.com>
 <451a1aff-d9a4-9baf-f786-db1e3d85ab3d@gmx.ch>
 <c7c71a8f-a7d0-7c18-a90a-c060e5384e84@gmail.com>
 <b633bf0f-6de5-28c0-1134-0045781e89ba@gmx.ch>
 <187da16e-f28d-dfb3-bb2f-cd661411b36e@gmail.com>
 <b8cd2eff-907a-28b7-ecc7-0297cd05e4c5@gmx.ch>
 <87y2wvq3h8.fsf@wheatstone.g10code.de>
 <d22b312c-6e2c-9db0-144a-934a96fe3eb2@gmx.ch>
 <87pni7pqne.fsf@wheatstone.g10code.de>
 <00d56c9e-e2a2-c7d6-04d9-0ca5116d4955@gmail.com>
Message-ID: <87r22moivw.fsf@wheatstone.g10code.de>

On Mon,  4 Nov 2019 18:10, Tony Lane said:

> was made with the unix philosophy in mind. Perhaps it would've been
> better to write the gpg-agent as a shared library to be called by the
> core instead. Well, we're probably too far down down the rabbit hole

The process boundary has security advantages and is one of the reasons
why this is not just a shared library.  Or why gpg is not a shared
library itself.  By splitting GnuPG into an OpenPGP part (gpg) and a
private key handling part (gpg-agent) we have a couple of benefits:

- We reduce the amount of code and of linked other shared libraries which
  come in touch with the sensitive private key material.
- The gpg-agent does not need to care about the complicated OpenPGP
  protocol (or gpgsm not about the more complicated CMS/X.509 protocol).
- No user interface required.
- Exploitable bugs in gpg must not immediately compromise private keys.
- We can can store/cache data in memory and do not need to load and
  process it each time.  A shared library won't allow this.  The cache
  is even encrypted so that we could extend it to store that encryption
  key in some kind of secure element to limit the expose of that key and
  thus the cache.
- Auditing the code and reasoning about the operation it is much easier
  given the well defined interface between the modules.
- Using SELinux or similar systems allows to run the gpg-agent in a mode
  where only gpg-agent may access the files storing the private keys.
- The gpg-agent could be run under a different uid and this way take
  advantage of the even stronger uid separation of most OSes.
- The gpg-agent can be run on an entirely different machine and thus
  work similar to a HSM.


Shalom-Salam,

   Werner

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

From sebastian at karotte.org  Tue Nov  5 17:49:53 2019
From: sebastian at karotte.org (Sebastian Wiesinger)
Date: Tue, 5 Nov 2019 17:49:53 +0100
Subject: gpg-agent SSH agent returned incorrect signature type
Message-ID: <20191105164953.frwyrhoepj7twwg3@danton.fire-world.de>

Hi,

I'm using gpg-agent with the key stored on a Yubikey for ssh pubkey
authentication. Since upgrading server systems to Debian 10 I get the following
error when logging in:

agent key RSA SHA256:[keyhash] returned incorrect signature type

Login succeeds but the error is displayed on every new connection.

There is not much information about this, except that it seems the error is
caused by the agent signing the key with a different hash algorithm:

debug1: Server accepts key: cardno:000233441461 RSA SHA256:[keyhash] agent
debug3: sign_and_send_pubkey: RSA SHA256:[keyhash]
debug3: sign_and_send_pubkey: signing using rsa-sha2-512
agent key RSA SHA256:[keyhash] returned incorrect signature type
debug3: sign_and_send_pubkey: signing using ssh-rsa


My question is, is this a problem with gpg-agent or is the Yubikey just not
able to sign the key with the requested sha2-512 algo?

Regards

Sebastian

-- 
GPG Key: 0x58A2D94A93A0B9CE (F4F6 B1A3 866B 26E9 450A  9D82 58A2 D94A 93A0 B9CE)
'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE.
            -- Terry Pratchett, The Fifth Elephant


From wk at gnupg.org  Tue Nov  5 20:53:41 2019
From: wk at gnupg.org (Werner Koch)
Date: Tue, 05 Nov 2019 20:53:41 +0100
Subject: gpg-agent SSH agent returned incorrect signature type
In-Reply-To: <20191105164953.frwyrhoepj7twwg3@danton.fire-world.de> (Sebastian
 Wiesinger via Gnupg-users's message of "Tue, 5 Nov 2019 17:49:53
 +0100")
References: <20191105164953.frwyrhoepj7twwg3@danton.fire-world.de>
Message-ID: <87v9rym75m.fsf@wheatstone.g10code.de>

On Tue,  5 Nov 2019 17:49, Sebastian Wiesinger said:

> debug3: sign_and_send_pubkey: signing using rsa-sha2-512

AFAICS that method is not supported.  We support "ssh-rsa" and
"ssh-rsa-cert-v01 at openssh.com" but not this method.  However, I do not
have the debug out of gpg-agent so I can't tell for sure.  Please put

--8<---------------cut here---------------start------------->8---
log-file /somewhere/gpg-agent.log
verbose
--8<---------------cut here---------------end--------------->8---


into ~/.gnupg/gpg-agent.conf and "gpgconf --kill gpg-agent".  In case
this reveals nothing it may be nessary to add a line "debug crypto" but
that would reveal key material if not only used with the Yubikey.

Anyway, I would suggest to use an EC algorithm; they are much faster.
The Yubikey only supports the NIST curves and thus ecdsa-sha2-nistp256
or ecdsa-sha2-nistp521 would be approriate.


Salam-Shalom,

   Werner


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

From al-gnupg_users at none.at  Tue Nov  5 21:33:53 2019
From: al-gnupg_users at none.at (Aleksandar Lazic)
Date: Tue, 5 Nov 2019 21:33:53 +0100
Subject: encrypt file in batch mode
In-Reply-To: <9962aeca-c896-7c64-03ef-a61ead1a9ba0@gmx.ch>
References: <9962aeca-c896-7c64-03ef-a61ead1a9ba0@gmx.ch>
Message-ID: <12310164-0ad4-9585-eca7-53c07a7c4168@none.at>

Hi.

Am 02.11.2019 um 15:35 schrieb Fourhundred Thecat:
> Hello,
> 
> how can I simply encrypt a file in "batch mode", ie in a script, without
> user interaction, without need for the user to type password, without
> gpg agent?

Maybe you can try https://github.com/jedisct1/encpipe for such a simple usecase?

> Below are the errors that I get when running:
> 
> $ gpg --lock-never -e -s -r user at domain.com --output zz zz.gpg
> 
> What is the reason why simple operations should not be possible without
> gpg-agent ?
> 
> gpg: starting migration from earlier GnuPG versions
> gpg: failed to start agent '/usr/bin/gpg-agent': No such file or directory
> gpg: can't connect to the agent: No such file or directory
> gpg: error: GnuPG agent unusable. Please check that a GnuPG agent can be
> started.
> gpg: migration aborted
> gpg: failed to start agent '/usr/bin/gpg-agent': No such file or directory
> gpg: can't connect to the agent: No such file or directory
> gpg: failed to start agent '/usr/bin/gpg-agent': No such file or directory
> gpg: can't connect to the agent: No such file or directory
> gpg: keydb_search failed: No agent running
> gpg: no default secret key: No agent running
> gpg: gpg.conf.gpg: sign+encrypt failed: No agent running
> 
> my version: gpg (GnuPG) 2.2.12
> 
> thanks,
> 
> 
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
> 



From sebastian at karotte.org  Wed Nov  6 10:30:56 2019
From: sebastian at karotte.org (Sebastian Wiesinger)
Date: Wed, 6 Nov 2019 10:30:56 +0100
Subject: gpg-agent SSH agent returned incorrect signature type
In-Reply-To: <87v9rym75m.fsf@wheatstone.g10code.de>
References: <20191105164953.frwyrhoepj7twwg3@danton.fire-world.de>
 <87v9rym75m.fsf@wheatstone.g10code.de>
Message-ID: <20191106093056.7zsp43ca56oamewa@danton.fire-world.de>

* GnuPG Users <gnupg-users at gnupg.org> [2019-11-05 20:56]:
> On Tue,  5 Nov 2019 17:49, Sebastian Wiesinger said:
> 
> > debug3: sign_and_send_pubkey: signing using rsa-sha2-512
> 
> AFAICS that method is not supported.  We support "ssh-rsa" and
> "ssh-rsa-cert-v01 at openssh.com" but not this method.  However, I do not
> have the debug out of gpg-agent so I can't tell for sure.  Please put
[..]
> Anyway, I would suggest to use an EC algorithm; they are much faster.
> The Yubikey only supports the NIST curves and thus ecdsa-sha2-nistp256
> or ecdsa-sha2-nistp521 would be approriate.

Hi Werner,

I've attached a redacted version of the log to this mail. If you need
something in the clear let me know.

In regard to the algorithm, I'm not sure where I would change that.
This seems to be something SSH does on its own...

Regards

Sebastian

-- 
GPG Key: 0x58A2D94A93A0B9CE (F4F6 B1A3 866B 26E9 450A  9D82 58A2 D94A 93A0 B9CE)
'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE.
            -- Terry Pratchett, The Fifth Elephant
-------------- next part --------------
2019-11-06 09:28:15 gpg-agent[6246] ssh handler 0x7f4a71188700 for fd 10 started
2019-11-06 09:28:15 gpg-agent[6246] ssh request handler for request_identities (11) started
2019-11-06 09:28:15 gpg-agent[6246] new connection to SCdaemon established (reusing)
2019-11-06 09:28:15 gpg-agent[6246] ssh request handler for request_identities (11) ready
2019-11-06 09:28:15 gpg-agent[6246] ssh request handler for sign_request (13) started
2019-11-06 09:28:15 gpg-agent[6246] DBG: detected card with S/N DXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
2019-11-06 09:28:15 gpg-agent[6246] DBG: encoded hash: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
2019-11-06 09:28:16 gpg-agent[6246] DBG: PKCS#1 block type 1 encoded data:+xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                                   xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                                   xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                                   xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                                   xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                                   xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                                   xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                                   xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                                   xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                                   xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                                   xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                                   xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                                   xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                                   xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                                   xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                                   xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
2019-11-06 09:28:16 gpg-agent[6246] DBG: rsa_verify data:+xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
2019-11-06 09:28:16 gpg-agent[6246] DBG: rsa_verify  sig:+xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
2019-11-06 09:28:16 gpg-agent[6246] DBG: rsa_verify    n:+xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
2019-11-06 09:28:16 gpg-agent[6246] DBG: rsa_verify    e:+xxxxxx
2019-11-06 09:28:16 gpg-agent[6246] DBG: rsa_verify  cmp:+xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:16 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
2019-11-06 09:28:16 gpg-agent[6246] DBG: rsa_verify    => Good
2019-11-06 09:28:16 gpg-agent[6246] ssh request handler for sign_request (13) ready
2019-11-06 09:28:16 gpg-agent[6246] ssh request handler for sign_request (13) started
2019-11-06 09:28:16 gpg-agent[6246] DBG: detected card with S/N DXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
2019-11-06 09:28:16 gpg-agent[6246] DBG: encoded hash: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
2019-11-06 09:28:17 gpg-agent[6246] DBG: PKCS#1 block type 1 encoded data:+xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                                   xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                                   xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                                   xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                                   xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                                   xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                                   xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                                   xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                                   xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                                   xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                                   xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                                   xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                                   xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                                   xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                                   xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                                   xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
2019-11-06 09:28:17 gpg-agent[6246] DBG: rsa_verify data:+xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
2019-11-06 09:28:17 gpg-agent[6246] DBG: rsa_verify  sig:+xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
2019-11-06 09:28:17 gpg-agent[6246] DBG: rsa_verify    n:+xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
2019-11-06 09:28:17 gpg-agent[6246] DBG: rsa_verify    e:+xxxxxx
2019-11-06 09:28:17 gpg-agent[6246] DBG: rsa_verify  cmp:+xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
2019-11-06 09:28:17 gpg-agent[6246] DBG:                  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
2019-11-06 09:28:17 gpg-agent[6246] DBG: rsa_verify    => Good
2019-11-06 09:28:17 gpg-agent[6246] ssh request handler for sign_request (13) ready
2019-11-06 09:28:17 gpg-agent[6246] ssh handler 0x7f4a70987700 for fd 13 started
2019-11-06 09:28:17 gpg-agent[6246] ssh handler 0x7f4a70987700 for fd 13 terminated
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 959 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20191106/ac1b549d/attachment-0001.sig>

From 400thecat at gmx.ch  Sat Nov  9 07:01:28 2019
From: 400thecat at gmx.ch (Fourhundred Thecat)
Date: Sat, 9 Nov 2019 07:01:28 +0100
Subject: decrypt file in batch mode
Message-ID: <d1abe816-5e0e-dd9d-2ba0-73dea421c22c@gmx.ch>

Hello,

I have a file which has been encrypted with a symmetric cipher (using a
passphrase).

How can I decrypt this file in batch mode, without gpg-agent ?

$ gpg --lock-never --no-verbose --batch --yes -d zz.gpg

gpg: AES256 encrypted data
gpg: failed to start agent '/usr/bin/gpg-agent': No such file or directory
gpg: can't connect to the agent: No such file or directory
gpg: problem with the agent: No agent running
gpg: encrypted with 1 passphrase
gpg: decryption failed: No secret key

Why does gpg look for secret key ?
This is symmetric encryption. What does it need secret key for ?

Any way to circumvent this ?

thanks,



From bobbyric at cisco.com  Sat Nov  9 01:42:47 2019
From: bobbyric at cisco.com (Bobby Richardson (bobbyric))
Date: Sat, 9 Nov 2019 00:42:47 +0000
Subject: decryption failed: secret key not available
Message-ID: <MWHPR11MB1248BB806CE65FEF3FED5A1FCC7A0@MWHPR11MB1248.namprd11.prod.outlook.com>

Hello:

I need a help in my gpg decryption with crontab.
Recently my gpg decryption with crontab started failing.
If I do gpg decryption without crontab, it works fine.

Here is my background information:
Platform: Centos 7
gpg version: 2.0.22

# When I use crontab with my decryption script in perl, I get following result:
PGP Decryption Begins.
Found:  [JW11072019_8559.OUT.pgp] to decrypt.
gpg: encrypted with ELG key, ID 636A4204
gpg: decryption failed: No secret key

# In my login credential profile, I have following configuration:
chmod 666 `tty`

# GPG Decrytion
in my perl script.
# $PGPpwd has a passphrase string.
`echo $PGPpwd | gpg2 --batch --passphrase-fd 0 --decrypt $PGPFile > $ZIPFile`;

I searched for any helpful resources and advices from internet and did not find any.
Does anyone have any suggestion that I can try?

Thank you.
Bobby
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20191109/220a34a1/attachment.html>

From kloecker at kde.org  Sat Nov  9 18:29:03 2019
From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=)
Date: Sat, 09 Nov 2019 18:29:03 +0100
Subject: decryption failed: secret key not available
In-Reply-To: <MWHPR11MB1248BB806CE65FEF3FED5A1FCC7A0@MWHPR11MB1248.namprd11.prod.outlook.com>
References: <MWHPR11MB1248BB806CE65FEF3FED5A1FCC7A0@MWHPR11MB1248.namprd11.prod.outlook.com>
Message-ID: <7464300.1Ajlaicy7j@thufir>

On Samstag, 9. November 2019 01:42:47 CET Bobby Richardson (bobbyric) wrote:
> Hello:
> 
> I need a help in my gpg decryption with crontab.
> Recently my gpg decryption with crontab started failing.

What did you change recently?

> If I do gpg decryption without crontab, it works fine.

cron provides a minimal environment to the jobs it runs. Maybe some 
environment variables are missing if your script is run by cron.

> Here is my background information:
> Platform: Centos 7
> gpg version: 2.0.22
> 
> # When I use crontab with my decryption script in perl, I get following
> result: PGP Decryption Begins.
> Found:  [JW11072019_8559.OUT.pgp] to decrypt.
> gpg: encrypted with ELG key, ID 636A4204
> gpg: decryption failed: No secret key
> 
> # In my login credential profile, I have following configuration:
> chmod 666 `tty`
> 
> # GPG Decrytion
> in my perl script.
> # $PGPpwd has a passphrase string.
> `echo $PGPpwd | gpg2 --batch --passphrase-fd 0 --decrypt $PGPFile >
> $ZIPFile`;

I suggest removing the passphrase from your secret key. Securing your secret 
key with a passphrase and then putting this passphrase in cleartext into a 
script makes batch decryption much more complicated without providing any 
security benefits.

If that does help increase the verbosity of gpg and enable debug logging.

Regards,
Ingo





From dkg at fifthhorseman.net  Sat Nov  9 21:39:15 2019
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Sat, 09 Nov 2019 15:39:15 -0500
Subject: A place for discussing WKD spec clarifications?
In-Reply-To: <87r234meqy.fsf@fifthhorseman.net>
References: <878spk7dce.fsf@fifthhorseman.net>
 <fPLrfIsFcV7GmjRwkPiAaWSXPn5bgtSvnctiSyCr2385@mailpile>
 <87r234meqy.fsf@fifthhorseman.net>
Message-ID: <87sgmwlr7w.fsf@fifthhorseman.net>

On Tue 2019-10-22 21:28:53 -0400, Daniel Kahn Gillmor via Gnupg-users wrote:
> On Thu 2019-10-17 11:08:46 +0000, Bjarni Runar Einarsson wrote:
>> Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:
>>> I'd be happy to set up such a tracker at (say)
>>> https://gitlab.com/openpgp-wg/web-key-directory/issues if folks
>>> are OK with it.
>>> 
>>> Werner, does that sound OK to you?
>>
>> This sounds good to me, but I agree it's important Werner is
>> onboard.
>
> Werner, can you give some indication of whether this sounds reasonable
> to you?  This is an important spec, and i'd like to have a place where
> we can keep track of implementer concerns.

I spoke with Werner about this last week, and he agreed that gitlab was
a reasonable place for the discussion.

I've just set up https://gitlab.com/openpgp-wg/webkey-directory for this
purpose -- it has an issue tracker and a proposed git repo (though it is
of course up to Werner whether he wants to use that git repo or keep
with the gnupg-docs repo for this draft).

I'll follow up with more details on openpgp at ietf.org, because i think
this draft is important for the entire OpenPGP ecosystem, not just
gnupg-users.

        --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/20191109/e8364f72/attachment.sig>

From abbot at monksofcool.net  Tue Nov 12 18:32:39 2019
From: abbot at monksofcool.net (Ralph Seichter)
Date: Tue, 12 Nov 2019 18:32:39 +0100
Subject: gpg-agent, pinentry and Emacs
Message-ID: <87mud1j8zs.fsf@wedjat.horus-it.com>

I asked about the following on the Notmuch mailing list first, and
Daniel Kahn Gillmor offered some advice, but the issue is not yet
resolved. I'm hoping for additional input from the GnuPG community.

I use Dovecot with a Maildir-based message store, allowing me to access
my mail using various IMAP based clients. I also use Notmuch[1] with
Emacs as a MUA, and for that, I login using SSH and a terminal, which of
course means no graphics beyond Ncurses.

  [1] https://notmuchmail.org/

This works fine until I encounter signed or encrypted mail (GPG and/or
S/MIME). Emacs attempts to prompt me for my password, or to ask me
whether I trust signator XYZ, but crams that prompt into the last two
lines of the Emacs window, so I cannot really see what is expected of
me.

I use gpg-agent and have tried both pinentry-tty and pinentry-curses. I
tried with and without 'allow-emacs-pinentry' in gpg-agent.conf. I tried
'epa-pinentry-mode' with values 'nil' and 'loopback'. All this did not
resolve the issue.

Daniel suggested "running gpg-agent in a dedicated terminal window, and
handling the gpg-agent prompts from that window". I tried to achieve
that by setting GPG_TTY to a fixed value like /dev/pts/1, and running
Emacs in /dev/pts/2. This works for a single time only. When prompting
me the next time, parts of my input are echoed on the screen, and when I
press return, the shell in pts/1 attempts to execute my pass phrase. It
looks like pinentry died halfway, so my input ends up in the shell.

I you have suggestions about how to solve this, I'd be grateful.

-Ralph


From gnupg at raf.org  Wed Nov 13 00:34:11 2019
From: gnupg at raf.org (raf)
Date: Wed, 13 Nov 2019 10:34:11 +1100
Subject: gpg-agent, pinentry and Emacs
In-Reply-To: <87mud1j8zs.fsf@wedjat.horus-it.com>
References: <87mud1j8zs.fsf@wedjat.horus-it.com>
Message-ID: <20191112233411.fpoiij236nz7nm63@raf.org>

Ralph Seichter wrote:

> I asked about the following on the Notmuch mailing list first, and
> Daniel Kahn Gillmor offered some advice, but the issue is not yet
> resolved. I'm hoping for additional input from the GnuPG community.
> 
> I use Dovecot with a Maildir-based message store, allowing me to access
> my mail using various IMAP based clients. I also use Notmuch[1] with
> Emacs as a MUA, and for that, I login using SSH and a terminal, which of
> course means no graphics beyond Ncurses.
> 
>   [1] https://notmuchmail.org/
> 
> This works fine until I encounter signed or encrypted mail (GPG and/or
> S/MIME). Emacs attempts to prompt me for my password, or to ask me
> whether I trust signator XYZ, but crams that prompt into the last two
> lines of the Emacs window, so I cannot really see what is expected of
> me.
> 
> I use gpg-agent and have tried both pinentry-tty and pinentry-curses. I
> tried with and without 'allow-emacs-pinentry' in gpg-agent.conf. I tried
> 'epa-pinentry-mode' with values 'nil' and 'loopback'. All this did not
> resolve the issue.
> 
> Daniel suggested "running gpg-agent in a dedicated terminal window, and
> handling the gpg-agent prompts from that window". I tried to achieve
> that by setting GPG_TTY to a fixed value like /dev/pts/1, and running
> Emacs in /dev/pts/2. This works for a single time only. When prompting
> me the next time, parts of my input are echoed on the screen, and when I
> press return, the shell in pts/1 attempts to execute my pass phrase. It
> looks like pinentry died halfway, so my input ends up in the shell.
> 
> I you have suggestions about how to solve this, I'd be grateful.
> 
> -Ralph

Does "--pinentry-mode loopback" make any difference?
Is it any different to epa-pinentry-mode?

cheers,
raf



From fgunbin at fastmail.fm  Wed Nov 13 02:34:53 2019
From: fgunbin at fastmail.fm (Filipp Gunbin)
Date: Wed, 13 Nov 2019 04:34:53 +0300
Subject: gpg-agent, pinentry and Emacs
In-Reply-To: <87mud1j8zs.fsf@wedjat.horus-it.com> (Ralph Seichter's message of
 "Tue, 12 Nov 2019 18:32:39 +0100")
References: <87mud1j8zs.fsf@wedjat.horus-it.com>
Message-ID: <m2h8388soy.fsf@fastmail.fm>

Which version of GnuPG are you using?  I have 2.2.17 and it works with
empty gpg-agent.conf and just this line in .emacs:

(setq epg-pinentry-mode 'loopback)

Filipp


From abbot at monksofcool.net  Wed Nov 13 17:48:23 2019
From: abbot at monksofcool.net (Ralph Seichter)
Date: Wed, 13 Nov 2019 17:48:23 +0100
Subject: gpg-agent, pinentry and Emacs
In-Reply-To: <20191112233411.fpoiij236nz7nm63@raf.org>
References: <87mud1j8zs.fsf@wedjat.horus-it.com>
 <20191112233411.fpoiij236nz7nm63@raf.org>
Message-ID: <871rubvi20.fsf@wedjat.horus-it.com>

* raf via Gnupg-users:

> Does "--pinentry-mode loopback" make any difference?

Where exactly do you suggest I add this option?

-Ralph


From abbot at monksofcool.net  Wed Nov 13 17:58:08 2019
From: abbot at monksofcool.net (Ralph Seichter)
Date: Wed, 13 Nov 2019 17:58:08 +0100
Subject: gpg-agent, pinentry and Emacs
In-Reply-To: <m2h8388soy.fsf@fastmail.fm>
References: <87mud1j8zs.fsf@wedjat.horus-it.com> <m2h8388soy.fsf@fastmail.fm>
Message-ID: <87muczzpb3.fsf@wedjat.horus-it.com>

* Filipp Gunbin via Gnupg-users:

> I have 2.2.17 and it works with empty gpg-agent.conf and just this
> line in .emacs:
> (setq epg-pinentry-mode 'loopback)

I use the same GnuPG version, but the Emacs variable setting you
suggested makes no difference for me. That's Emacs version 26.3,
which I should have mentioned earlier.

-Ralph


From gnupg at raf.org  Wed Nov 13 23:29:20 2019
From: gnupg at raf.org (raf)
Date: Thu, 14 Nov 2019 09:29:20 +1100
Subject: gpg-agent, pinentry and Emacs
In-Reply-To: <871rubvi20.fsf@wedjat.horus-it.com>
References: <87mud1j8zs.fsf@wedjat.horus-it.com>
 <20191112233411.fpoiij236nz7nm63@raf.org>
 <871rubvi20.fsf@wedjat.horus-it.com>
Message-ID: <20191113222920.bvg3is4estk3o2cu@raf.org>

Ralph Seichter wrote:

> * raf via Gnupg-users:
> 
> > Does "--pinentry-mode loopback" make any difference?
> 
> Where exactly do you suggest I add this option?
> 
> -Ralph

Wherever it needs to be to get added to the gpg command line
when invoked from within emacs.

Or as a setting in gpg's config file (but then it would take
effect always which you probably wouldn't want). 



From abbot at monksofcool.net  Thu Nov 14 00:47:37 2019
From: abbot at monksofcool.net (Ralph Seichter)
Date: Thu, 14 Nov 2019 00:47:37 +0100
Subject: gpg-agent, pinentry and Emacs
In-Reply-To: <20191113222920.bvg3is4estk3o2cu@raf.org>
References: <87mud1j8zs.fsf@wedjat.horus-it.com>
 <20191112233411.fpoiij236nz7nm63@raf.org>
 <871rubvi20.fsf@wedjat.horus-it.com>
 <20191113222920.bvg3is4estk3o2cu@raf.org>
Message-ID: <878sojxrs6.fsf@wedjat.horus-it.com>

* raf via Gnupg-users:

> Wherever it needs to be to get added to the gpg command line when
> invoked from within emacs.

As far as I can tell, that's what epa-pinentry-mode is used for (which I
tried unsuccessfully, as stated in my OP). I think I have tried every
EasyPG trick and workaround that I could find searching the Net, but
still no dice.

> Or as a setting in gpg's config file (but then it would take effect
> always which you probably wouldn't want).

I just tried that as well. Adding "pinentry-mode loopback" to gpg.conf
unfortunately causes Emacs to no longer attempt to decrypt messages.

/me scratches head.

-Ralph


From wk at gnupg.org  Thu Nov 14 10:08:00 2019
From: wk at gnupg.org (Werner Koch)
Date: Thu, 14 Nov 2019 10:08:00 +0100
Subject: gpg-agent, pinentry and Emacs
In-Reply-To: <87muczzpb3.fsf@wedjat.horus-it.com> (Ralph Seichter's message of
 "Wed, 13 Nov 2019 17:58:08 +0100")
References: <87mud1j8zs.fsf@wedjat.horus-it.com> <m2h8388soy.fsf@fastmail.fm>
 <87muczzpb3.fsf@wedjat.horus-it.com>
Message-ID: <87o8xebzbj.fsf@wheatstone.g10code.de>

On Wed, 13 Nov 2019 17:58, Ralph Seichter said:

> I use the same GnuPG version, but the Emacs variable setting you
> suggested makes no difference for me. That's Emacs version 26.3,
> which I should have mentioned earlier.

Yet another regression in Emacs?  I am still cursing over 26.
Fortunately I always use xterms so the regular GUI pinentry works
nicely.  I only briefly tested the Emacs pinentry features we once
introduced for epg.

The socket used by pinentry-emacs is

  ${TMPDIR-/tmp}/emacs$(id -u)/pinentry

does this exist?  If you insert a pinentry wrapper, can you see the
INSIDE_EMACS envvar?  Has pinentry been build with emacs support?

Some of these questions are unfortunately not easy to answer.  I will
add information on the availibility of the emacs support to the pinentry
status output.  Adding "debug-pinentry" to gpg-agent.conf may help a
bit, though.



Salam-Shalom,

   Werner

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

From fgunbin at fastmail.fm  Thu Nov 14 13:32:32 2019
From: fgunbin at fastmail.fm (Filipp Gunbin)
Date: Thu, 14 Nov 2019 15:32:32 +0300
Subject: gpg-agent, pinentry and Emacs
In-Reply-To: <87muczzpb3.fsf@wedjat.horus-it.com> (Ralph Seichter's message of
 "Wed, 13 Nov 2019 17:58:08 +0100")
References: <87mud1j8zs.fsf@wedjat.horus-it.com> <m2h8388soy.fsf@fastmail.fm>
 <87muczzpb3.fsf@wedjat.horus-it.com>
Message-ID: <m2lfsi63kv.fsf@fastmail.fm>

On 13/11/2019 17:58 +0100, Ralph Seichter wrote:

> * Filipp Gunbin via Gnupg-users:
>
>> I have 2.2.17 and it works with empty gpg-agent.conf and just this
>> line in .emacs:
>> (setq epg-pinentry-mode 'loopback)
>
> I use the same GnuPG version, but the Emacs variable setting you
> suggested makes no difference for me. That's Emacs version 26.3,
> which I should have mentioned earlier.

Hm, I see this in NEWS for 27.1 (unreleased master):

*** 'epa-pinentry-mode' is renamed to 'epg-pinentry-mode'.
It now applies to epg functions as well as epa functions.

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


From fgunbin at fastmail.fm  Thu Nov 14 13:34:06 2019
From: fgunbin at fastmail.fm (Filipp Gunbin)
Date: Thu, 14 Nov 2019 15:34:06 +0300
Subject: gpg-agent, pinentry and Emacs
In-Reply-To: <87muczzpb3.fsf@wedjat.horus-it.com> (Ralph Seichter's message of
 "Wed, 13 Nov 2019 17:58:08 +0100")
References: <87mud1j8zs.fsf@wedjat.horus-it.com> <m2h8388soy.fsf@fastmail.fm>
 <87muczzpb3.fsf@wedjat.horus-it.com>
Message-ID: <m2eeya63i9.fsf@fastmail.fm>

Sorry, previous message went unfinished.

On 13/11/2019 17:58 +0100, Ralph Seichter wrote:

> I use the same GnuPG version, but the Emacs variable setting you
> suggested makes no difference for me. That's Emacs version 26.3,
> which I should have mentioned earlier.

I see this in NEWS for Emacs 27.1 (unreleased master).

--8<---------------cut here---------------start------------->8---
*** 'epa-pinentry-mode' is renamed to 'epg-pinentry-mode'.
It now applies to epg functions as well as epa functions.
--8<---------------cut here---------------end--------------->8---

So maybe try epa-pinentry-mode instead?

Filipp


From abbot at monksofcool.net  Thu Nov 14 19:54:07 2019
From: abbot at monksofcool.net (Ralph Seichter)
Date: Thu, 14 Nov 2019 19:54:07 +0100
Subject: gpg-agent, pinentry and Emacs
In-Reply-To: <87o8xebzbj.fsf@wheatstone.g10code.de>
References: <87mud1j8zs.fsf@wedjat.horus-it.com> <m2h8388soy.fsf@fastmail.fm>
 <87muczzpb3.fsf@wedjat.horus-it.com> <87o8xebzbj.fsf@wheatstone.g10code.de>
Message-ID: <87eeya2ss0.fsf@wedjat.horus-it.com>

* Werner Koch via Gnupg-users:

> ${TMPDIR-/tmp}/emacs$(id -u)/pinentry

The socket exists and the permissions look OK (read/write access for my
Linux user).

> If you insert a pinentry wrapper, can you see the INSIDE_EMACS envvar?

I just tried the following wrapper script:

  #!/usr/bin/env bash
  echo "INSIDE_EMACS is '$INSIDE_EMACS'" >> /tmp/$(basename $0).log
  /usr/bin/pinentry-tty

When opening an encrypted message, the result is as follows:

  $ cat /tmp/pinentry-wrapper.log
  INSIDE_EMACS is ''

> Has pinentry been build with emacs support?

Looking at the local build settings, I believe so. Is there a way to
figure this out with no room for doubt with pinentry version 1.1.0?

> Adding "debug-pinentry" to gpg-agent.conf may help a bit, though.

I did that, but I cannot seem to locate the debug output. Where is it
written?

-Ralph


From abbot at monksofcool.net  Thu Nov 14 19:56:15 2019
From: abbot at monksofcool.net (Ralph Seichter)
Date: Thu, 14 Nov 2019 19:56:15 +0100
Subject: gpg-agent, pinentry and Emacs
In-Reply-To: <m2eeya63i9.fsf@fastmail.fm>
References: <87mud1j8zs.fsf@wedjat.horus-it.com> <m2h8388soy.fsf@fastmail.fm>
 <87muczzpb3.fsf@wedjat.horus-it.com> <m2eeya63i9.fsf@fastmail.fm>
Message-ID: <87blte2sog.fsf@wedjat.horus-it.com>

* Filipp Gunbin via Gnupg-users:

> I see this in NEWS for Emacs 27.1 (unreleased master).
>
> --8<---------------cut here---------------start------------->8---
> *** 'epa-pinentry-mode' is renamed to 'epg-pinentry-mode'.
> It now applies to epg functions as well as epa functions.

I tried both epa-pinentry-mode and epg-pinentry-mode, with no noticeable
difference in the outcome. I did not really expect any difference, what
with this being an upcoming change in a future Emacs version.

-Ralph


From wk at gnupg.org  Fri Nov 15 08:35:12 2019
From: wk at gnupg.org (Werner Koch)
Date: Fri, 15 Nov 2019 08:35:12 +0100
Subject: gpg-agent, pinentry and Emacs
In-Reply-To: <87eeya2ss0.fsf@wedjat.horus-it.com> (Ralph Seichter's message of
 "Thu, 14 Nov 2019 19:54:07 +0100")
References: <87mud1j8zs.fsf@wedjat.horus-it.com> <m2h8388soy.fsf@fastmail.fm>
 <87muczzpb3.fsf@wedjat.horus-it.com>
 <87o8xebzbj.fsf@wheatstone.g10code.de>
 <87eeya2ss0.fsf@wedjat.horus-it.com>
Message-ID: <87y2wha8y7.fsf@wheatstone.g10code.de>

On Thu, 14 Nov 2019 19:54, Ralph Seichter said:

>   $ cat /tmp/pinentry-wrapper.log
>   INSIDE_EMACS is ''

Pinentry consideres that it is not run from Emacs and thus it does not
forward requests to Emacs but uses the standard pinentry (or should
return an error for pinentry-emacs).  INSIDE_EMACS support is in GnUPG
since 2.1.5 (4 years ago).  It seems that for whatever reasons Emacs
does not pass that envvar on.

> Looking at the local build settings, I believe so. Is there a way to
> figure this out with no room for doubt with pinentry version 1.1.0?

Not really.

>> Adding "debug-pinentry" to gpg-agent.conf may help a bit, though.
>
> I did that, but I cannot seem to locate the debug output. Where is it
> written?

Put

log-file /somwhere/gpg-agent.log

into gpg-agent.conf.  It is best to also add "verbose".

  --log-file file
     Append all logging output to file.  This is very helpful in seeing
     what the agent actually does. Use ?socket://? to log to socket.

Witch the special file socket:// you can run watchgnupg in another tty
to immediately see the diagnostics.  Granted tail -f would do the same
but socket:// can be put into the conf files of all components and when
running

  watchgnupg --force --time-only $(gpgconf --list-dirs socketdir)/S.log

you will see all diagnostics from all components.


Salam-Shalom,

   Werner

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

From abbot at monksofcool.net  Fri Nov 15 21:45:44 2019
From: abbot at monksofcool.net (Ralph Seichter)
Date: Fri, 15 Nov 2019 21:45:44 +0100
Subject: gpg-agent, pinentry and Emacs
In-Reply-To: <87y2wha8y7.fsf@wheatstone.g10code.de>
References: <87mud1j8zs.fsf@wedjat.horus-it.com> <m2h8388soy.fsf@fastmail.fm>
 <87muczzpb3.fsf@wedjat.horus-it.com> <87o8xebzbj.fsf@wheatstone.g10code.de>
 <87eeya2ss0.fsf@wedjat.horus-it.com> <87y2wha8y7.fsf@wheatstone.g10code.de>
Message-ID: <87imnkrhqf.fsf@wedjat.horus-it.com>

* Werner Koch:

> INSIDE_EMACS support is in GnUPG since 2.1.5 (4 years ago). It seems
> that for whatever reasons Emacs does not pass that envvar on.

Perhaps I need to build Emacs "by hand" to get full control over all
options, instead of relying on the existing Gentoo ebuild. Not that I
want to do that. :-/

> log-file /somwhere/gpg-agent.log

Thanks. I did that, and also added 'verbose'. The output does not tell
me much, though:

gpg-agent[27187]: handler 0x7f85114d4700 for fd 9 started
gpg-agent[27187]: starting a new PIN Entry
gpg-agent[27187]: handler 0x7f850bfff700 for fd 16 started
gpg-agent[27187]: handler 0x7f850bfff700 for fd 16 terminated
gpg-agent[27187]: failed to unprotect the secret key: Timeout
gpg-agent[27187]: failed to read the secret key
gpg-agent[27187]: command 'PKDECRYPT' failed: Timeout <Pinentry>
gpg-agent[27187]: Assuan processing failed: Broken pipe
gpg-agent[27187]: handler 0x7f85114d4700 for fd 9 terminated
gpg-agent[27187]: handler 0x7f850bfff700 for fd 12 started
gpg-agent[27187]: handler 0x7f850bfff700 for fd 12 terminated
gpg-agent[27187]: handler 0x7f85114d4700 for fd 12 started
gpg-agent[27187]: handler 0x7f85114d4700 for fd 12 terminated
[...]

I did try to enter my pass phrase, but my interpretation of the above
timeout is that my input never made it back to gpg-agent?

I am not quite sure how to best debug this further. In my OP I mentioned
trying to have pinentry in a separate, dedicated terminal? Is that
possible, and if so, how would I set it up? Like I wrote, setting
GPG_TTY to a fixed value only works for a single time.

-Ralph


From steffen at sdaoden.eu  Sat Nov 16 01:23:31 2019
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Sat, 16 Nov 2019 01:23:31 +0100
Subject: Extraction of public key from an encrypted etc. message
Message-ID: <20191116002331.gs9xL%steffen@sdaoden.eu>

Hello.

Is there a way to extract the public key that can be seen when
doing --list-packets from any XY where this very circumstance is
true?

In times where people use Autocrypt headers to distribute their
(stripped etc.) public key with each message they send, it really
makes me a bit sad that when i get a message that actually is
encrypted for the sender and for me i have to download the key
from somewhere else.

The public key _is_ in there, no?
I could not find a solution via web search.

Thanks,

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)


From wk at gnupg.org  Sat Nov 16 08:34:12 2019
From: wk at gnupg.org (Werner Koch)
Date: Sat, 16 Nov 2019 08:34:12 +0100
Subject: gpg-agent, pinentry and Emacs
In-Reply-To: <87imnkrhqf.fsf@wedjat.horus-it.com> (Ralph Seichter's message of
 "Fri, 15 Nov 2019 21:45:44 +0100")
References: <87mud1j8zs.fsf@wedjat.horus-it.com> <m2h8388soy.fsf@fastmail.fm>
 <87muczzpb3.fsf@wedjat.horus-it.com>
 <87o8xebzbj.fsf@wheatstone.g10code.de>
 <87eeya2ss0.fsf@wedjat.horus-it.com>
 <87y2wha8y7.fsf@wheatstone.g10code.de>
 <87imnkrhqf.fsf@wedjat.horus-it.com>
Message-ID: <87bltc9swb.fsf@wheatstone.g10code.de>

On Fri, 15 Nov 2019 21:45, Ralph Seichter said:

> gpg-agent[27187]: failed to read the secret key
> gpg-agent[27187]: command 'PKDECRYPT' failed: Timeout <Pinentry>

You forgot to _add_

 debug-pinentry
 debug ipc
 verbose

to gpg-agent.conf.  (The "debug ipc" is helpful because it shows what
gpg is requesting from gpg-agent).


Salam-Shalom,

   Werner

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

From abbot at monksofcool.net  Sat Nov 16 18:22:53 2019
From: abbot at monksofcool.net (Ralph Seichter)
Date: Sat, 16 Nov 2019 18:22:53 +0100
Subject: gpg-agent, pinentry and Emacs
In-Reply-To: <87bltc9swb.fsf@wheatstone.g10code.de>
References: <87mud1j8zs.fsf@wedjat.horus-it.com> <m2h8388soy.fsf@fastmail.fm>
 <87muczzpb3.fsf@wedjat.horus-it.com> <87o8xebzbj.fsf@wheatstone.g10code.de>
 <87eeya2ss0.fsf@wedjat.horus-it.com> <87y2wha8y7.fsf@wheatstone.g10code.de>
 <87imnkrhqf.fsf@wedjat.horus-it.com> <87bltc9swb.fsf@wheatstone.g10code.de>
Message-ID: <87h833pwgi.fsf@wedjat.horus-it.com>

* Werner Koch:

> You forgot to _add_
>
>  debug-pinentry
>  debug ipc
>  verbose
>
> to gpg-agent.conf.

Here's the gpg-agent.conf I used:

  default-cache-ttl <nnn>
  max-cache-ttl <mmm>
  no-allow-mark-trusted
  enable-ssh-support
  pinentry-program /home/xyz/bin/pinentry-wrapper
  debug-pinentry
  log-file /tmp/gpg-agent.log
  verbose

Seems to me I had everything in place, with the exception of "debug
ipc". I added the latter, and the resulting log file is available via
https://seichter.de/aegi6bee9eShu/gpg-agent.log . Note that I killed
the agent manually at the end of that session in order to flush any
data still potentially buffered for logging.

-Ralph


From lhrazky at redhat.com  Fri Nov 15 12:28:32 2019
From: lhrazky at redhat.com (=?UTF-8?Q?Luk=C3=A1=C5=A1_Hr=C3=A1zk=C3=BD?=)
Date: Fri, 15 Nov 2019 12:28:32 +0100
Subject: Problems with gpg-agent cleanup in microdnf
Message-ID: <ee8f59d4298212292efa1929fa0de808ff1c2d0c.camel@redhat.com>

Hello,

we're having trouble with proper cleanup of the gpg-agent which is
launched by gpgme. There's a bug report, with a (Dockerfile) reproducer
and some more info here:
https://github.com/rpm-software-management/microdnf/issues/50

And the code in question is quite short and isolated here:
https://github.com/rpm-software-management/librepo/blob/master/librepo/gpg.c

The suspiciously hackish kill_gpg_agent() function was added because
strangely enough it makes the gpg-agent clean up its sockets, whereas
if the gpg-agent is left to exit on its own, the sockets aren't cleaned
up. The bug for this is here:
https://bugzilla.redhat.com/show_bug.cgi?id=1650266

TLDR; the sockets couldn't be tar-ed into containers, so we had to
clean them up somehow.

Now the issue with this seems to be there's a race condition, sending
the gpg-agent "KILLAGENT" may or may not cause it to exit before the
gpgme_release() function is called and if it does, the gpgme_release()
will get a SIGPIPE while trying to write to the socket.

So my question is, how to make the gpg-agent clean up its sockets
properly? Are we supposed to delete the sockets ourselves? There are
four of them, I don't think that's really something we should be doing
(listing and manipulating four files in our code whose names are an
implementation detail from a gpgme user's point of view).

Or is it a bug the sockets aren't cleaned up?

Please CC me in replies, thanks.

Cheers,
Lukas



From vedaal at nym.hush.com  Mon Nov 18 03:03:36 2019
From: vedaal at nym.hush.com (vedaal at nym.hush.com)
Date: Sun, 17 Nov 2019 21:03:36 -0500
Subject: Extraction of public key from an encrypted etc. message
In-Reply-To: <20191116002331.gs9xL%steffen@sdaoden.eu>
Message-ID: <20191118020337.0881AC0601@smtp.hushmail.com>



On 11/15/2019 at 7:26 PM, "Steffen Nurpmeso" <steffen at sdaoden.eu> wrote:The public key _is_ in there, no?
=====
No.

Only the public Key ID is in there, not the entire public key, and and even this keyID can be hidden too,
if the sender uses the option of --hidden-encrypt-to


vedaal



From steffen at sdaoden.eu  Mon Nov 18 18:26:46 2019
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Mon, 18 Nov 2019 18:26:46 +0100
Subject: Extraction of public key from an encrypted etc. message
In-Reply-To: <20191118020337.0881AC0601@smtp.hushmail.com>
References: <20191118020337.0881AC0601@smtp.hushmail.com>
Message-ID: <20191118172646.gkQy2%steffen@sdaoden.eu>

vedaal at nym.hush.com wrote in <20191118020337.0881AC0601 at smtp.hushmail.com>:
 |On 11/15/2019 at 7:26 PM, "Steffen Nurpmeso" <steffen at sdaoden.eu> wrote:\
 |The public key _is_ in there, no?
 |=====
 |No.
 |
 |Only the public Key ID is in there, not the entire public key, and \
 |and even this keyID can be hidden too,
 |if the sender uses the option of --hidden-encrypt-to

Yes -- thank you very much!  I am reading RFC 2440 again now, it
is a session key created by using the public key only.  I have
this document for so many years now, i had forgotten about it.
Ciao!

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)


From sebastian at karotte.org  Tue Nov 19 14:14:09 2019
From: sebastian at karotte.org (Sebastian Wiesinger)
Date: Tue, 19 Nov 2019 14:14:09 +0100
Subject: gpg-agent SSH agent returned incorrect signature type
In-Reply-To: <20191105164953.frwyrhoepj7twwg3@danton.fire-world.de>
References: <20191105164953.frwyrhoepj7twwg3@danton.fire-world.de>
Message-ID: <20191119131409.fxy76jvxcxzv7z26@danton.fire-world.de>

* Sebastian Wiesinger <sebastian at karotte.org> [2019-11-05 17:49]:
> Hi,
> 
> I'm using gpg-agent with the key stored on a Yubikey for ssh pubkey
> authentication. Since upgrading server systems to Debian 10 I get the following
> error when logging in:
> 
> agent key RSA SHA256:[keyhash] returned incorrect signature type

It seems this might be fixed in gnupg 2.2.6. It was reported here:

T3880 "gpg-agent's ssh-agent does not handle flags in signing requests properly"
https://dev.gnupg.org/T3880

Can't test right now because I would need a newer agent.

Regards

Sebastian

-- 
GPG Key: 0x58A2D94A93A0B9CE (F4F6 B1A3 866B 26E9 450A  9D82 58A2 D94A 93A0 B9CE)
'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE.
            -- Terry Pratchett, The Fifth Elephant


From abbot at monksofcool.net  Sun Nov 24 19:31:14 2019
From: abbot at monksofcool.net (Ralph Seichter)
Date: Sun, 24 Nov 2019 19:31:14 +0100
Subject: gpg-agent, pinentry and Emacs
In-Reply-To: <87h833pwgi.fsf@wedjat.horus-it.com>
References: <87mud1j8zs.fsf@wedjat.horus-it.com> <m2h8388soy.fsf@fastmail.fm>
 <87muczzpb3.fsf@wedjat.horus-it.com> <87o8xebzbj.fsf@wheatstone.g10code.de>
 <87eeya2ss0.fsf@wedjat.horus-it.com> <87y2wha8y7.fsf@wheatstone.g10code.de>
 <87imnkrhqf.fsf@wedjat.horus-it.com> <87bltc9swb.fsf@wheatstone.g10code.de>
 <87h833pwgi.fsf@wedjat.horus-it.com>
Message-ID: <87tv6tgm8d.fsf@wedjat.horus-it.com>

* Ralph Seichter:

> https://seichter.de/aegi6bee9eShu/gpg-agent.log

Gentle bump, because I posted this a week ago. Did you have a chance to
examine the log, Werner?

-Ralph


From wk at gnupg.org  Mon Nov 25 08:44:17 2019
From: wk at gnupg.org (Werner Koch)
Date: Mon, 25 Nov 2019 08:44:17 +0100
Subject: gpg-agent, pinentry and Emacs
In-Reply-To: <87h833pwgi.fsf@wedjat.horus-it.com> (Ralph Seichter's message of
 "Sat, 16 Nov 2019 18:22:53 +0100")
References: <87mud1j8zs.fsf@wedjat.horus-it.com> <m2h8388soy.fsf@fastmail.fm>
 <87muczzpb3.fsf@wedjat.horus-it.com>
 <87o8xebzbj.fsf@wheatstone.g10code.de>
 <87eeya2ss0.fsf@wedjat.horus-it.com>
 <87y2wha8y7.fsf@wheatstone.g10code.de>
 <87imnkrhqf.fsf@wedjat.horus-it.com>
 <87bltc9swb.fsf@wheatstone.g10code.de>
 <87h833pwgi.fsf@wedjat.horus-it.com>
Message-ID: <877e3obdta.fsf@wheatstone.g10code.de>

On Sat, 16 Nov 2019 18:22, Ralph Seichter said:

> ipc". I added the latter, and the resulting log file is available via
> https://seichter.de/aegi6bee9eShu/gpg-agent.log . Note that I killed

Thanks.  I don't see that INSIDE_EMACS is propagated and I can duplicate
that problem here.  I will look into this today so that a possible fix
can go into 2.2.18.

Thanks for the reminder.


Salam-Shalom,

   Werner


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

From abbot at monksofcool.net  Mon Nov 25 15:47:13 2019
From: abbot at monksofcool.net (Ralph Seichter)
Date: Mon, 25 Nov 2019 15:47:13 +0100
Subject: gpg-agent, pinentry and Emacs
In-Reply-To: <877e3obdta.fsf@wheatstone.g10code.de>
References: <87mud1j8zs.fsf@wedjat.horus-it.com> <m2h8388soy.fsf@fastmail.fm>
 <87muczzpb3.fsf@wedjat.horus-it.com> <87o8xebzbj.fsf@wheatstone.g10code.de>
 <87eeya2ss0.fsf@wedjat.horus-it.com> <87y2wha8y7.fsf@wheatstone.g10code.de>
 <87imnkrhqf.fsf@wedjat.horus-it.com> <87bltc9swb.fsf@wheatstone.g10code.de>
 <87h833pwgi.fsf@wedjat.horus-it.com> <877e3obdta.fsf@wheatstone.g10code.de>
Message-ID: <87imn8ovwu.fsf@wedjat.horus-it.com>

* Werner Koch:

> I will look into this today so that a possible fix can go into 2.2.18.

Thanks a lot, Werner.

-Ralph


From wk at gnupg.org  Mon Nov 25 16:56:56 2019
From: wk at gnupg.org (Werner Koch)
Date: Mon, 25 Nov 2019 16:56:56 +0100
Subject: gpg-agent, pinentry and Emacs
In-Reply-To: <877e3obdta.fsf@wheatstone.g10code.de> (Werner Koch via
 Gnupg-users's message of "Mon, 25 Nov 2019 08:44:17 +0100")
References: <87mud1j8zs.fsf@wedjat.horus-it.com> <m2h8388soy.fsf@fastmail.fm>
 <87muczzpb3.fsf@wedjat.horus-it.com>
 <87o8xebzbj.fsf@wheatstone.g10code.de>
 <87eeya2ss0.fsf@wedjat.horus-it.com>
 <87y2wha8y7.fsf@wheatstone.g10code.de>
 <87imnkrhqf.fsf@wedjat.horus-it.com>
 <87bltc9swb.fsf@wheatstone.g10code.de>
 <87h833pwgi.fsf@wedjat.horus-it.com>
 <877e3obdta.fsf@wheatstone.g10code.de>
Message-ID: <8736ecar07.fsf@wheatstone.g10code.de>

On Mon, 25 Nov 2019 08:44, Werner Koch said:

> Thanks.  I don't see that INSIDE_EMACS is propagated and I can duplicate

My fault.  We pass the the envvars to pinentry using setnev in an atfork
handler.  Thus we do not see them in the Assuan log.  I added some
logging to so that we can now see without a wrapper which envvars care
send to pinentry.

In my tests INSIDE_EMACS is set if I set it before calling gpg;
regardless of whether the agent is running or not.  Thus the problem is
not in gnupg but may be in pinentry or the emacs code calling gpg.


Shalom-Salam,

   Werner

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

From wk at gnupg.org  Mon Nov 25 22:07:36 2019
From: wk at gnupg.org (Werner Koch)
Date: Mon, 25 Nov 2019 22:07:36 +0100
Subject: [Announce] GnuPG 2.2.18 released
Message-ID: <87sgmbacmf.fsf@wheatstone.g10code.de>

Hello!

We are pleased to announce the availability of a new GnuPG release:
version 2.2.18.  This is maintenance release to fix a couple of minor
bugs and provide a few feature updates.  This release also retires the
use of SHA-1 key signatures created since this year.  See below for a
list of changes.


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

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

GnuPG allows to encrypt and sign data and communication, features a
versatile key management system as well as access modules for public key
directories.  GnuPG itself is a command line tool with features for easy
integration with other applications.  The separate library GPGME provides
a uniform API to use the GnuPG engine by software written in common
programming languages.  A wealth of frontend applications and libraries
making use of GnuPG are available.  As an universal crypto engine GnuPG
provides support for S/MIME and Secure Shell in addition to OpenPGP.

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


Noteworthy changes in version 2.2.18
====================================

  * gpg: Changed the way keys are detected on a smartcards; this
    allows the use of non-OpenPGP cards.  In the case of a not very
    likely regression the new option --use-only-openpgp-card is
    available.  [#4681]

  * gpg: The commands --full-gen-key and --quick-gen-key now allow
    direct key generation from supported cards.  [#4681]

  * gpg: Prepare against chosen-prefix SHA-1 collisions in key
    signatures.  This change removes all SHA-1 based key signature
    newer than 2019-01-19 from the web-of-trust.  Note that this
    includes all key signature created with dsa1024 keys.  The new
    option --allow-weak-key-signatues can be used to override the new
    and safer behaviour.  [#4755,CVE-2019-14855]

  * gpg: Improve performance for import of large keyblocks.  [#4592]

  * gpg: Implement a keybox compression run.  [#4644]

  * gpg: Show warnings from dirmngr about redirect and certificate
    problems (details require --verbose as usual).

  * gpg: Allow to pass the empty string for the passphrase if the
    '--passphase=' syntax is used.  [#4633]

  * gpg: Fix printing of the KDF object attributes.

  * gpg: Avoid surprises with --locate-external-key and certain
    --auto-key-locate settings.  [#4662]

  * gpg: Improve selection of best matching key.  [#4713]

  * gpg: Delete key binding signature when deletring a subkey.
    [#4665,#4457]

  * gpg: Fix a potential loss of key sigantures during import with
    self-sigs-only active.  [#4628]

  * gpg: Silence "marked as ultimately trusted" diagnostics if
    option --quiet is used.  [#4634]

  * gpg: Silence some diagnostics during in key listsing even with
    option --verbose.  [#4627]

  * gpg, gpgsm: Change parsing of agent's pkdecrypt results.  [#4652]

  * gpgsm: Support AES-256 keys.

  * gpgsm: Fix a bug in triggering a keybox compression run if
    --faked-system-time is used.

  * dirmngr: System CA certificates are no longer used for the SKS
    pool if GNUTLS instead of NTBTLS is used as TLS library.  [#4594]

  * dirmngr: On Windows detect usability of IPv4 and IPv6 interfaces
    to avoid long timeouts.  [#4165]

  * scd: Fix BWI value for APDU level transfers to make Gemalto Ezio
    Shield and Trustica Cryptoucan work.  [#4654,#4566]

  * wkd: gpg-wks-client --install-key now installs the required policy
    file.

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


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

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

GnuPG 2.2.18 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.18.tar.bz2 (6582k)
 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.18.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.18_20191125.exe (4139k)
 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.18_20191125.exe.sig

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

A new version of Gpg4win including this version of GnuPG will be
released in a few days.


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

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

     sha1sum gnupg-2.2.18.tar.bz2

   and check that the output matches the next line:

2f95d6aa409f666c61c1526641fd609f1a50c4c4  gnupg-2.2.18.tar.bz2
e77d823abb64202aa9fe7d651f3ba03d9358669c  gnupg-w32-2.2.18_20191125.tar.xz
62c369400da1ee0de7b0275ecd0bcc969805b9da  gnupg-w32-2.2.18_20191125.exe


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

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


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

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

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

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

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

or can be downloaded as PDF at

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

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.  https://wiki.gnupg.org has user contributed
information around GnuPG and relate software.

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

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

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


Thanks
======

Maintenance and development of GnuPG is mostly financed by donations.
The GnuPG project currently employs two full-time developers and one
contractor.  They all work exclusively on GnuPG and closely related
software like Libgcrypt, GPGME and Gpg4win.

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

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


Happy hacking,

   Your GnuPG hackers



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

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

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

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

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

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

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

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

From yjgt at hotmail.com  Tue Nov 26 18:51:48 2019
From: yjgt at hotmail.com (Yves T)
Date: Tue, 26 Nov 2019 17:51:48 +0000
Subject: multiple recipients encryption and decryption in gpgsm
Message-ID: <HE1PR0101MB22988EEC41F80F75D0E1A0D2CF450@HE1PR0101MB2298.eurprd01.prod.exchangelabs.com>

Dears,

A client uses gpgsm with multiple recipient options. The first option refers to his own certificate, the second option to the recipients certificate.
The receiving end has trouble decrypting the file. Output mentions
gpgsm: error decrypting session key: No secret key
gpgsm: decrypting session key failed: No secret key

The solution which was mentioned to us was to use local-user option but this does not seem to work.

Is it possible in gpgsm to encrypt for different recipients and how can they decrypt. Can you please complete with an example?
Thank you.

Verzonden vanuit Mail<https://go.microsoft.com/fwlink/?LinkId=550986> voor Windows 10

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

From angel at pgp.16bits.net  Thu Nov 28 01:29:39 2019
From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=)
Date: Thu, 28 Nov 2019 01:29:39 +0100
Subject: multiple recipients encryption and decryption in gpgsm
In-Reply-To: <HE1PR0101MB22988EEC41F80F75D0E1A0D2CF450@HE1PR0101MB2298.eurprd01.prod.exchangelabs.com>
References: <HE1PR0101MB22988EEC41F80F75D0E1A0D2CF450@HE1PR0101MB2298.eurprd01.prod.exchangelabs.com>
Message-ID: <1574900979.915.1.camel@16bits.net>

On 2019-11-26 at 17:51 +0000, Yves T via Gnupg-users wrote:
> Dears,
>  
> A client uses gpgsm with multiple recipient options. The first option
> refers to his own certificate, the second option to the recipients
> certificate.
> The receiving end has trouble decrypting the file. Output mentions
> gpgsm: error decrypting session key: No secret key
> gpgsm: decrypting session key failed: No secret key
> 
> The solution which was mentioned to us was to use local-user option
> but this does not seem to work.
> 
> Is it possible in gpgsm to encrypt for different recipients and how
> can they decrypt. Can you please complete with an example?
> 
> Thank you.
> 
Sorry for the obvious but, does the receiving part have the private part
of the certificate that the sender thinks belong to them?

What you report seems like a perfect message with the receiver not
having their own keys imported.

Cheers


From yjgt at hotmail.com  Thu Nov 28 11:57:14 2019
From: yjgt at hotmail.com (Yves T)
Date: Thu, 28 Nov 2019 10:57:14 +0000
Subject: multiple recipients encryption and decryption in gpgsm 
Message-ID: <DB6PR0101MB229617746156390CD6D96ACDCF470@DB6PR0101MB2296.eurprd01.prod.exchangelabs.com>


Sender A:
To recapitulate : sender A uses gpgsm with 2 recipients:
gpgsm --recipient <A own cert id> --recipient <B cert id> --encrypt file.txt > encryptedfile.gpg

Receiver B:
The receiving end B has his own correct secret key available but not the secret key from B and gets an error when decrypting the file:

gpgsm: DBG: recp 0 - issuer: 'CN=MYREALM CA,DC=REALM' gpgsm: DBG: recp 0 - serial: <serial number of the sender certificate> gpgsm: error decrypting session key: No secret key gpgsm: decrypting session key failed: No secret key
gpgsm: DBG: recp 1 - issuer: 'CN=MYREALM CA,DC=REALM' gpgsm: DBG: recp 1 - serial: <serial number of the receiver certificate>

So the question is:

  1.  is B able to decrypt the file if he has not the secret key from A
  2.  should he be able to do this even when not having A's secret key
  3.  am I missing something
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20191128/de6d7aec/attachment.html>

From wk at gnupg.org  Thu Nov 28 13:12:56 2019
From: wk at gnupg.org (Werner Koch)
Date: Thu, 28 Nov 2019 13:12:56 +0100
Subject: multiple recipients encryption and decryption in gpgsm
In-Reply-To: <DB6PR0101MB229617746156390CD6D96ACDCF470@DB6PR0101MB2296.eurprd01.prod.exchangelabs.com>
 (Yves T. via Gnupg-users's message of "Thu, 28 Nov 2019 10:57:14
 +0000")
References: <DB6PR0101MB229617746156390CD6D96ACDCF470@DB6PR0101MB2296.eurprd01.prod.exchangelabs.com>
Message-ID: <87k17k8aif.fsf@wheatstone.g10code.de>

On Thu, 28 Nov 2019 10:57, Yves T said:

>   1.  is B able to decrypt the file if he has not the secret key from A

Yes.  As long as the secret key (aka private key) is available

Quick test:

  $ fortune | gpgsm -ev  -r 0xE297583E -r  0xCA89261C >/tmp/testenc

The first -r ist for s/n 1A02 and the secon for 1A04.  Now switching to
another account where we have only the secret part for 1A04:

  $ gpgsm -vd </tmp/testenc
  gpgsm: DBG: recp 0 - issuer: '1.2.840.113549.1.9.1=#696E666F4[...]
  gpgsm: DBG: recp 0 - serial: 1A02
  gpgsm: error decrypting session key: No secret key
  gpgsm: decrypting session key failed: No secret key
  gpgsm: DBG: recp 1 - issuer: '1.2.840.113549.1.9.1=#696E666F4[...]
  gpgsm: DBG: recp 1 - serial: 1A04
  Nothing endures but change.
                 -- Heraclitus

The first recipient can't be decrypted because the secret key is
missing.  For the second recipient the secret key is available and
decryption succeeds.


Salam-Shalom,

   Werner

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

From yjgt at hotmail.com  Thu Nov 28 15:38:31 2019
From: yjgt at hotmail.com (Yves T)
Date: Thu, 28 Nov 2019 14:38:31 +0000
Subject: multiple recipients encryption and decryption in gpgsm
Message-ID: <DB6PR0101MB2296ECA549EF19DBAC6B6764CF470@DB6PR0101MB2296.eurprd01.prod.exchangelabs.com>

Dear Werner,

Thank you for your prompt reaction.

I did a test an despite the error I see indeed the file is correctly decrypted.
So the conclusion is that when a file is encrypted with two recipients - when the file is received by the second recipient it is sufficient that he has the corresponding private key; we do not need the private key of the other recipient.  Right?
Am I also correct to say the order or recipients is of no issue?

Thank you
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20191128/c6344ea6/attachment-0001.html>