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: 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] " 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: 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: 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: -----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: References: <20191030003331.stgm7magl7kpjwul@raf.org> Message-ID: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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 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: 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: -----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: References: 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: References: <9962aeca-c896-7c64-03ef-a61ead1a9ba0@gmx.ch> <18bc863a-b5eb-8f63-7ccf-f104e68b9980@gmail.com> <451a1aff-d9a4-9baf-f786-db1e3d85ab3d@gmx.ch> Message-ID: 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: <87v9s1o65p.fsf@netris.org> Message-ID: -----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 References: <9962aeca-c896-7c64-03ef-a61ead1a9ba0@gmx.ch> <18bc863a-b5eb-8f63-7ccf-f104e68b9980@gmail.com> <451a1aff-d9a4-9baf-f786-db1e3d85ab3d@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: <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: <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> <187da16e-f28d-dfb3-bb2f-cd661411b36e@gmail.com> Message-ID: 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: <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 > 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: 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: 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: 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: 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: 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: 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: 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: 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: References: Message-ID: 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 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: 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: <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 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 > >> 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: References: 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: References: 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 >> 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: 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: <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: 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: References: <20191030003331.stgm7magl7kpjwul@raf.org> 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: <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 > >> 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: References: 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: 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: 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: 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: 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: 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: <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: 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: (Horst Skatmus's message of "Sat, 2 Nov 2019 12:20:07 +0100") References: 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: 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: (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> <187da16e-f28d-dfb3-bb2f-cd661411b36e@gmail.com> 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: 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: References: 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> <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> <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> <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> <187da16e-f28d-dfb3-bb2f-cd661411b36e@gmail.com> <87y2wvq3h8.fsf@wheatstone.g10code.de> Message-ID: 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: (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> <187da16e-f28d-dfb3-bb2f-cd661411b36e@gmail.com> <87y2wvq3h8.fsf@wheatstone.g10code.de> 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: 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: (karel-v's message of "Mon, 4 Nov 2019 08:58:19 +0100 (CET)") References: 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: 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: References: 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: <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: 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: 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> <187da16e-f28d-dfb3-bb2f-cd661411b36e@gmail.com> <87y2wvq3h8.fsf@wheatstone.g10code.de> <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: <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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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> <187da16e-f28d-dfb3-bb2f-cd661411b36e@gmail.com> <87y2wvq3h8.fsf@wheatstone.g10code.de> <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> <187da16e-f28d-dfb3-bb2f-cd661411b36e@gmail.com> <87y2wvq3h8.fsf@wheatstone.g10code.de> <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: 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: 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 [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: 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: 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: 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: 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: References: 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> <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 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: 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: 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: References: <87mud1j8zs.fsf@wedjat.horus-it.com> 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> <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: 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> <87muczzpb3.fsf@wedjat.horus-it.com> Message-ID: 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> <87muczzpb3.fsf@wedjat.horus-it.com> Message-ID: 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> <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: References: <87mud1j8zs.fsf@wedjat.horus-it.com> <87muczzpb3.fsf@wedjat.horus-it.com> 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> <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: 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> <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 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> <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 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: 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> <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 max-cache-ttl 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: 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" 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" 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 [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> <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> <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: 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> <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> <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: 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 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 . 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: . We suggest to send bug reports for a new release to this list in favor of filing a bug at . If you need commercial support visit or . 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) 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) 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 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: -------------- 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: 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 voor Windows 10 -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: References: 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: Sender A: To recapitulate : sender A uses gpgsm with 2 recipients: gpgsm --recipient --recipient --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: 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: 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: 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: (Yves T. via Gnupg-users's message of "Thu, 28 Nov 2019 10:57:14 +0000") References: 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 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: 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: