From bernhard at intevation.de Thu Apr 1 09:18:00 2021 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 1 Apr 2021 09:18:00 +0200 Subject: We shall value email usage In-Reply-To: <3b9f6e5a-2fe0-e355-39d2-7cb349e8a83f@posteo.ru> References: <202103231036.59847.bernhard@intevation.de> <202103250954.01860.bernhard@intevation.de> <3b9f6e5a-2fe0-e355-39d2-7cb349e8a83f@posteo.ru> Message-ID: <202104010918.15599.bernhard@intevation.de> Am Mittwoch 31 M?rz 2021 22:28:45 schrieb Stefan Vasilev via Gnupg-users: > The more I think about GnuPG with email MUA usage I strongly believe > that the Industry has better options than email, especially when it comes > to decentralised and confidential communications. And what options would that be? > Hopefully the Industry will take a look at affordable hardware based > encrypted Fax comms for the little individual or small business owner. > https://www.tccsecure.com/Products/voice-fax-data-encryption/CSD3324spf-detail.aspx Briefly skimmed the page, it does not say how the maschine-in-the-middle (MITM) attack is migitated. Also this hardware solution does not offer the means to transport electronic documents, neither would crypto phones. Best Regards, Bernhard -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From oub at mat.ucm.es Thu Apr 1 12:58:08 2021 From: oub at mat.ucm.es (Uwe Brauer) Date: Thu, 01 Apr 2021 12:58:08 +0200 Subject: gpgsm on mac (fink or ports) Message-ID: <87v9965l1b.fsf@mat.ucm.es> Hi My main machine is a X1 running Ubuntu 16.04. I have to use a macbook as well for which I currently installed fink. I mostly signing and encrypting with smime and emacs+gpgsm work nicely on my Ubuntu machine. Does anybody know, whether I can install gpgsm on fink or ports? (Or homebrew as method of last resort?) Regards Uwe Brauer From stefan.vasilev at posteo.ru Thu Apr 1 16:39:16 2021 From: stefan.vasilev at posteo.ru (Stefan Vasilev) Date: Thu, 1 Apr 2021 16:39:16 +0200 Subject: We shall value email usage In-Reply-To: <202104010918.15599.bernhard@intevation.de> References: <202103231036.59847.bernhard@intevation.de> <202103250954.01860.bernhard@intevation.de> <3b9f6e5a-2fe0-e355-39d2-7cb349e8a83f@posteo.ru> <202104010918.15599.bernhard@intevation.de> Message-ID: Bernhard Reiter wrote: > Am Mittwoch 31 M?rz 2021 22:28:45 schrieb Stefan Vasilev via Gnupg-users: >> The more I think about GnuPG with email MUA usage I strongly believe >> that the Industry has better options than email, especially when it comes >> to decentralised and confidential communications. > And what options would that be? First of all we should consider that GnuPG did not changed the email world as users may had expected over the decades and during to continuing mass-surveillance it is debatable if a few users should use this communication form further. It would be good if it would be accepted by millions when conducting online business but since this is not the case, nor never will be, it can be argued when a few people do encrypted email communications, why not switch to other channels, to reduce the flow of meta data? An option would be to use UIDless GnuPG key pairs with the Bitmessage p2p Network to give GnuPG users additional anonymity. Another method could be IPFS (InterPlanetary FileSystem) usage where users distribute encrypted GnuPG payloads and only provide the IPFS hashes to communication partners, so that they can read those hashes, say from an SMS, a FAX etc. and then download the encrypted payload from places they feel comfortable with. Another option would be direct FAX/GnuPG usage, with a different armor, which is OCR friendly. > >> Hopefully the Industry will take a look at affordable hardware based >> encrypted Fax comms for the little individual or small business owner. >> > https://www.tccsecure.com/Products/voice-fax-data-encryption/CSD3324spf-detail.aspx > > Briefly skimmed the page, it does not say how the maschine-in-the-middle > (MITM) attack is migitated. Also this hardware solution does not offer the > means to transport electronic documents, neither would crypto phones. > Correct no electronic documents, but would it be not a bit more difficult or less common to intercept DH usage from hardware based devices compared to software based Internet DH usage? At least this product exists and it can be assumed that it is been used. Regards Stefan From johanw at vulcan.xs4all.nl Thu Apr 1 17:43:18 2021 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Thu, 1 Apr 2021 17:43:18 +0200 Subject: We shall value email usage In-Reply-To: <3b9f6e5a-2fe0-e355-39d2-7cb349e8a83f@posteo.ru> References: <202103231036.59847.bernhard@intevation.de> <202103250954.01860.bernhard@intevation.de> <3b9f6e5a-2fe0-e355-39d2-7cb349e8a83f@posteo.ru> Message-ID: On 31-03-2021 22:28, Stefan Vasilev via Gnupg-users wrote: > Hopefully the Industry will take a look at affordable hardware based > encrypted Fax comms for Fax? To get the information on paper? In 2021? Why? > Hardware based AES/DH crypto phones (no smartphones) would be a welcome > addition too. Why limit yourself with expensive special purpose hardware that has far less options than the current? > Or that the OpenPGP community revives PGPfone, for free Internet calls, > at least ... I think Signal has already stepped into that niche. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From stefan.vasilev at posteo.ru Thu Apr 1 17:54:26 2021 From: stefan.vasilev at posteo.ru (Stefan Vasilev) Date: Thu, 1 Apr 2021 17:54:26 +0200 Subject: We shall value email usage In-Reply-To: References: <202103231036.59847.bernhard@intevation.de> <202103250954.01860.bernhard@intevation.de> <3b9f6e5a-2fe0-e355-39d2-7cb349e8a83f@posteo.ru> Message-ID: <02f0da27-461f-0514-9ffe-a3fef2ea662f@posteo.ru> Johan Wevers wrote: > On 31-03-2021 22:28, Stefan Vasilev via Gnupg-users wrote: > >> Hopefully the Industry will take a look at affordable hardware based >> encrypted Fax comms for > Fax? To get the information on paper? In 2021? Why? Fax is faster than email and arrives, while email delivery to a recipient can not been guranteed. Secondly it is more dezentralised than smpt(s) servers with many users. Third assuming households have muli-purpose printers too they can simply scan the Fax for further processing. > >> Hardware based AES/DH crypto phones (no smartphones) would be a welcome >> addition too. > Why limit yourself with expensive special purpose hardware that has far > less options than the current? Why not, this product is available and does not limit Internet users to do other things besides encrypted Fax usage. > >> Or that the OpenPGP community revives PGPfone, for free Internet calls, >> at least ... > I think Signal has already stepped into that niche. No, Signal is an easy to monitor smartphone tool needing a server with registered users, while PGPfone was a Computer usage only tool, for direct and secure comms, between two endpoints, without server usage. Dialing was done from IP address to IP address and verified with the included PGP wordlist. Regards Stefan From andrewg at andrewg.com Thu Apr 1 16:53:06 2021 From: andrewg at andrewg.com (Andrew Gallagher) Date: Thu, 1 Apr 2021 15:53:06 +0100 Subject: We shall value email usage In-Reply-To: References: <202103231036.59847.bernhard@intevation.de> <202103250954.01860.bernhard@intevation.de> <3b9f6e5a-2fe0-e355-39d2-7cb349e8a83f@posteo.ru> <202104010918.15599.bernhard@intevation.de> Message-ID: <5749e222-9749-59ed-ab35-65b20089d17a@andrewg.com> On 01/04/2021 15:39, Stefan Vasilev via Gnupg-users wrote: > Another option would be direct FAX/GnuPG usage, with a different armor, > which is OCR friendly. From a purely practical point of view, why would anyone in the modern world use a system where a digital message is rendered in OCR-able format on an analogue raster, to be converted into digital tones, then passed down an analogue connection, which is almost certainly carried over a VoIP backbone? Please stop. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From johanw at vulcan.xs4all.nl Thu Apr 1 18:19:45 2021 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Thu, 1 Apr 2021 18:19:45 +0200 Subject: We shall value email usage In-Reply-To: <02f0da27-461f-0514-9ffe-a3fef2ea662f@posteo.ru> References: <202103231036.59847.bernhard@intevation.de> <202103250954.01860.bernhard@intevation.de> <3b9f6e5a-2fe0-e355-39d2-7cb349e8a83f@posteo.ru> <02f0da27-461f-0514-9ffe-a3fef2ea662f@posteo.ru> Message-ID: <0f41c6ac-6e70-0d57-336f-ad855b30ab1a@vulcan.xs4all.nl> On 01-04-2021 17:54, Stefan Vasilev via Gnupg-users wrote: > Fax is faster than email and arrives, while email delivery to a > recipient can not On;y if the recipient has a landline that can always pickup the fax call. A more and more uncommon situation. I don't have a landline anymore, no use for it. > many users. Third assuming households have muli-purpose printers too > they can simply scan the Fax for further processing. What a waste of paper and expensive ink. And I don't have a (functioning) printer anyway, why would I? I can read everything on screen. Maybe RMS might do something like that but while I support him in the current which hunt I'm not as strict as he is about using modern hardware. Killing some Google services like advertising id on my phone and blocking ads is as far as I go. >> Why limit yourself with expensive special purpose hardware that has far >> less options than the current? > Why not, this product is available and does not limit Internet users to > do other thing besides encrypted Fax usage. Why buy expensive special purpose hardware for only that use case? > No, Signal is an easy to monitor smartphone tool needing a server with > registered users, while Not really easy to monitor, not since they implemented "sealed sender" so the server does only know the receiver, not the sender. > PGPfone was a Computer usage only tool, for direct and secure comms, > between two endpoints, Who both had to synchronize being online at the same time. That might have been acceptable 20 years ago but not now. > without server usage. Dialing was done from IP address to IP address and > verified with the included PGP wordlist. That might cause problems now that most people have dynamic IP addresses. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From stefan.vasilev at posteo.ru Thu Apr 1 18:19:40 2021 From: stefan.vasilev at posteo.ru (Stefan Vasilev) Date: Thu, 1 Apr 2021 18:19:40 +0200 Subject: We shall value email usage In-Reply-To: <5749e222-9749-59ed-ab35-65b20089d17a@andrewg.com> References: <202103231036.59847.bernhard@intevation.de> <202103250954.01860.bernhard@intevation.de> <3b9f6e5a-2fe0-e355-39d2-7cb349e8a83f@posteo.ru> <202104010918.15599.bernhard@intevation.de> <5749e222-9749-59ed-ab35-65b20089d17a@andrewg.com> Message-ID: <102cdc15-6d4d-4777-1a3a-82deba14dc15@posteo.ru> Andrew Gallagher wrote: > On 01/04/2021 15:39, Stefan Vasilev via Gnupg-users wrote: >> Another option would be direct FAX/GnuPG usage, with a different armor, >> which is OCR friendly. > > From a purely practical point of view, why would anyone in the modern > world use a system where a digital message is rendered in OCR-able > format on an analogue raster, to be converted into digital tones, then > passed down an analogue connection, which is almost certainly carried > over a VoIP backbone? Please stop. Why stop? It is a valid option for almost real time decentralized comms which guarantees that the recipient gets a time stamped encrypted document from a hardcoded landline no. email delivery, as you may no, can not be guaranteed and in case of GnuPG armored messages they will be most likely filtered for further archival and/or processing. Regards Stefan From stefan.vasilev at posteo.ru Thu Apr 1 18:36:32 2021 From: stefan.vasilev at posteo.ru (Stefan Vasilev) Date: Thu, 1 Apr 2021 18:36:32 +0200 Subject: We shall value email usage In-Reply-To: <0f41c6ac-6e70-0d57-336f-ad855b30ab1a@vulcan.xs4all.nl> References: <202103231036.59847.bernhard@intevation.de> <202103250954.01860.bernhard@intevation.de> <3b9f6e5a-2fe0-e355-39d2-7cb349e8a83f@posteo.ru> <02f0da27-461f-0514-9ffe-a3fef2ea662f@posteo.ru> <0f41c6ac-6e70-0d57-336f-ad855b30ab1a@vulcan.xs4all.nl> Message-ID: Johan Wevers wrote: Sorry for not quoting your message! Let's say it this way, Bernhard likes to promote email usage for GnuPG, or why should we here on this Mailing List value email usage (with a MUA)? I showed a couple of examples to make it for the surveillance industry a bit harder to collect decentralized distributed GnuPG encrypted payloads. :-) And I am aware that we have people here on this ML who for example work(ed) in that industry and that they like how GnuPG with MUAs on online devices work. ;-) Regards Stefan From wk at gnupg.org Thu Apr 1 20:31:48 2021 From: wk at gnupg.org (Werner Koch) Date: Thu, 01 Apr 2021 20:31:48 +0200 Subject: [admin] April Fools Day Message-ID: <87v995dffv.fsf@wheatstone.g10code.de> Hi! I ponder with the idea of shutting down the ML for a few days around next year's April 1 to keep discussions a bit more serious. But well, if you want to have some fun, please make it a bit more clear in your proposals. 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 l0f4r0 at tuta.io Thu Apr 1 19:23:35 2021 From: l0f4r0 at tuta.io (l0f4r0 at tuta.io) Date: Thu, 1 Apr 2021 19:23:35 +0200 (CEST) Subject: We shall value email usage In-Reply-To: <102cdc15-6d4d-4777-1a3a-82deba14dc15@posteo.ru> References: <202103231036.59847.bernhard@intevation.de> <202103250954.01860.bernhard@intevation.de> <3b9f6e5a-2fe0-e355-39d2-7cb349e8a83f@posteo.ru> <202104010918.15599.bernhard@intevation.de> <5749e222-9749-59ed-ab35-65b20089d17a@andrewg.com> <102cdc15-6d4d-4777-1a3a-82deba14dc15@posteo.ru> Message-ID: Hi, 1 avr. 2021, 18:19 de gnupg-users at gnupg.org: > Why stop? > You're right. Today is the good day to break habits, think out of the box and do things differently! ;) Best regards, l0f4r0 From karel-v_g at tutanota.com Sat Apr 3 13:28:01 2021 From: karel-v_g at tutanota.com (karel-v_g at tutanota.com) Date: Sat, 3 Apr 2021 13:28:01 +0200 (CEST) Subject: Kleopatra and GPA: Differentiate diabled and revoked keys optically Message-ID: Hello! Over the years I have collected quiet a few personal private and foreign public keys that were either revoked or that I have simply disabled. How can I configure Kleopatra and GPA to either optically differentiate, hide or these keys? GPA displays all keys in the same manner and I have found no way to change this. For Kleopatra I can change the visual style of these key-types in libkleopatrarc, but I wonder whether there is an option to sort these keys at the beginning or end of the list or hide them. Thanks for help! Karel From karel-v_g at tutanota.com Sat Apr 3 13:30:05 2021 From: karel-v_g at tutanota.com (karel-v_g at tutanota.com) Date: Sat, 3 Apr 2021 13:30:05 +0200 (CEST) Subject: GPA: How to get long Key-ID displayed Message-ID: Hello! For me GPA always display only the old short Key-ID. How / where can I change that? I have not found any option in the GUI or for gpa.conf. For GnuPG itself I have already set "keyid-format 0xlong" in gpg.conf, but that does not affect GPA. Thanks for help! Karel From karel-v_g at tutanota.com Sat Apr 3 12:28:19 2021 From: karel-v_g at tutanota.com (karel-v_g at tutanota.com) Date: Sat, 3 Apr 2021 12:28:19 +0200 (CEST) Subject: GPA: How to get long Key-ID displayed Message-ID: Hello! For me GPA always display only the old short Key-ID. How / where can I change that? I have not found any option in the GUI or for gpa.conf. For GnuPG itself I have already set "keyid-format 0xlong" in gpg.conf, but that does not affect GPA. Thanks for help! Karel From wk at gnupg.org Sun Apr 4 19:12:05 2021 From: wk at gnupg.org (Werner Koch) Date: Sun, 04 Apr 2021 19:12:05 +0200 Subject: GPA: How to get long Key-ID displayed In-Reply-To: (karel-v's message of "Sat, 3 Apr 2021 12:28:19 +0200 (CEST)") References: Message-ID: <87im52c6u2.fsf@wheatstone.g10code.de> On Sat, 3 Apr 2021 12:28, karel-v_g--- said: > For me GPA always display only the old short Key-ID. > How / where can I change that? I have not found any option in the GUI You can't. Have a look at the fingerprint in the line above; in general you should use the fingerprint. BTW, the keyid are the last4 or 8 bytes of the fingerprint. 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 jarraneil at gmail.com Sun Apr 4 20:14:56 2021 From: jarraneil at gmail.com (Neil Webster) Date: Sun, 4 Apr 2021 14:14:56 -0400 Subject: Migrating password store to new hard drive Message-ID: <3e14939d-6e63-59bf-bc84-f772c738e2d9@gmail.com> Hello, I have recently installed a new SSD on my computer and I am trying to move my password store (using pass) to the new drive. I am using Ubuntu 20.04.2 LTS. I can see the individual *.gpg files that form the password store but I am not able to decrypt them. Here are some things I have tried $gpg -K returns with nothing Running gpg directly on a single file in the password store using $gpg -d filename gives $gpg: encrypted with 3072-bit RSA key, ID 94FDE31D5B3E9BC6, created 2020-03-11 "my at emailaddress.com" $gpg: decryption failed: No secret key I tried exporting the secret key from the old drive using $gpg --export-secret-keys --armor --output privkey.asc my at emailaddress.com and tried importing on the new drive using $gpg --import privkey.asc the import process seems to succeed with the following message $gpg: key D96B626F551DE067: "my at emailaddress.com" not changed $gpg: key D96B626F551DE067: secret key imported $gpg: Total number processed: 1 $gpg:????????????? unchanged: 1 $gpg:?????? secret keys read: 1 $gpg:? secret keys unchanged: 1 Not sure if it is important or not but inside the ~/.gnupg/private-keys-v1.d/ directory I have 2 files 5A96EC16F8D4B37AEEF42D805853853AAECAAE20.key 6E8963C9E7FBC51DEFA9DDE31FC12AC65F7D865D.key Cheers, Neil -------------- next part -------------- An HTML attachment was scrubbed... URL: From kloecker at kde.org Sun Apr 4 21:48:06 2021 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Sun, 04 Apr 2021 21:48:06 +0200 Subject: Migrating password store to new hard drive In-Reply-To: <3e14939d-6e63-59bf-bc84-f772c738e2d9@gmail.com> References: <3e14939d-6e63-59bf-bc84-f772c738e2d9@gmail.com> Message-ID: <4650451.31r3eYUQgx@collossus.localdomain> On Sonntag, 4. April 2021 20:14:56 CEST Neil Webster via Gnupg-users wrote: > I have recently installed a new SSD on my computer and I am trying to > move my password store (using pass) to the new drive. I am using Ubuntu > 20.04.2 LTS. I have always copied the whole ~/.gnupg folder from the old system/disk to the new system/disk when I migrated to a new PC or a new hard drive. Actually, I always copied my whole home directory. Only when setting up a secondary computer I copied selected folders including the ~/.gnupg folder and the password store. I suggest to do the same, i.e., instead of exporting and importing secret keys, simply copy the .gnupg folder from the old disk to the new disk. Make a backup of the already existing .gnupg folder on the new disk before proceeding just in case. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: From erikrtn at gmail.com Tue Apr 6 18:44:39 2021 From: erikrtn at gmail.com (Erik Reinertsen) Date: Tue, 6 Apr 2021 12:44:39 -0400 Subject: GPG slows git commit In-Reply-To: <1682865.UsXe81Qx9F@breq> References: <0E0A8477-4537-437F-AC96-4267E671951C@gmail.com> <1748697.e9hGeTlPz6@breq> <8F9C9867-C654-49C2-A588-6AA4ABA072FC@gmail.com> <1682865.UsXe81Qx9F@breq> Message-ID: <509687DB-4BE3-4C36-B077-1FEE46BC5A3B@gmail.com> Ingo, Thank you for the response. If I run the same command again, I am prompted to enter my passphrase. Subsequently, I get: gpg: using "581F6A88B3F58A4E94A26040153F263741C51DC1" as default secret key for signing -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEEWB9qiLP1ik6UomBAFT8mN0HFHcEFAmBsjzEACgkQFT8mN0H ... =JcnT -----END PGP SIGNATURE----- gpg --clearsign 0.01s user 0.02s system 0% cpu 7.230 total Note I am on macOS 11.2.3 and zsh 5.8. Regarding your other suggestions, I don't have a command called "log-file". Is the full suggested syntax "log-file /somewhere/gpg.log"? Sorry if I'm missing obvious things here. Erik > On Mar 27, 2021, at 5:01 PM, Ingo Kl?cker wrote: > > On Freitag, 26. M?rz 2021 15:16:15 CET Erik Reinertsen via Gnupg-users wrote: >>> Moreover, let's time gpg signing without git. Run >>> echo Hello | time gpg --clearsign >> >> gpg --clearsign 0.01s user 0.01s system 0% cpu 6.696 total > > I'm not sure that I understand the result. (The time command on my system has > a different output format.) Does the "6.696 total" mean that clearsigning took > almost 7 seconds? gpg didn't ask you for your passphrase, right? > > Try putting > log-file /somewhere/gpg.log > verbose > debug ipc,lookup > into ~/.gnupg/gpg.conf > > Then make a signed test commit and check the log file. > > Regards, > Ingo > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From jarraneil at gmail.com Tue Apr 6 19:43:59 2021 From: jarraneil at gmail.com (Neil Webster) Date: Tue, 6 Apr 2021 13:43:59 -0400 Subject: Migrating password store to new hard drive In-Reply-To: <4650451.31r3eYUQgx@collossus.localdomain> References: <3e14939d-6e63-59bf-bc84-f772c738e2d9@gmail.com> <4650451.31r3eYUQgx@collossus.localdomain> Message-ID: That worked. Thanks for the help. On 4/4/21 3:48 PM, Ingo Kl?cker wrote: > On Sonntag, 4. April 2021 20:14:56 CEST Neil Webster via Gnupg-users wrote: >> I have recently installed a new SSD on my computer and I am trying to >> move my password store (using pass) to the new drive. I am using Ubuntu >> 20.04.2 LTS. > I have always copied the whole ~/.gnupg folder from the old system/disk to the > new system/disk when I migrated to a new PC or a new hard drive. Actually, I > always copied my whole home directory. Only when setting up a secondary > computer I copied selected folders including the ~/.gnupg folder and the > password store. > > I suggest to do the same, i.e., instead of exporting and importing secret > keys, simply copy the .gnupg folder from the old disk to the new disk. Make a > backup of the already existing .gnupg folder on the new disk before proceeding > just in case. > > Regards, > Ingo > > _______________________________________________ > 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 wk at gnupg.org Thu Apr 8 11:05:48 2021 From: wk at gnupg.org (Werner Koch) Date: Thu, 08 Apr 2021 11:05:48 +0200 Subject: [Announce] GnuPG 2.3.0 released Message-ID: <877dld87tf.fsf@wheatstone.g10code.de> Hello! We are pleased to announce the availability of a new GnuPG release: version 2.3.0. This release marks the start of public testing releases eventually leading to a new stable version 2.4. Although some bugs might linger in the 2.3 versions, they are intended to replace the 2.2 series. 2.3 may even be used for production purposes if either the risk of minor regressions is acceptable or the new features are important. What is 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. Three different versions of GnuPG are actively maintained: - This version (2.3) is the latest development with a lot of new features. This announcement is about the first release of this version. - Version 2.2 is our LTS (long term support) version and guaranteed to be maintained at least until the end of 2024. See https://gnupg.org/download/index.html#end-of-life - Version 1.4 is maintained to allow decryption of very old data which is, for security reasons, not anymore possible with other GnuPG versions. Noteworthy changes in version 2.3.0 (2021-04-07) ================================================ * A new experimental key database daemon is provided. To enable it put "use-keyboxd" into gpg.conf and gpgsm.conf. Keys are stored in a SQLite database and make key lookup much faster. * New tool gpg-card as a flexible frontend for all types of supported smartcards. * New option --chuid for gpg, gpgsm, gpgconf, gpg-card, and gpg-connect-agent. * The gpg-wks-client tool is now installed under bin; a wrapper for its old location at libexec is also installed. * tpm2d: New daemon to physically bind keys to the local machine. See https://gnupg.org/blog/20210315-using-tpm-with-gnupg-2.3.html * gpg: Switch to ed25519/cv25519 as default public key algorithms. * gpg: Verification results now depend on the --sender option and the signer's UID subpacket. [#4735] * gpg: Do not use any 64-bit block size cipher algorithm for encryption. Use AES as last resort cipher preference instead of 3DES. This can be reverted using --allow-old-cipher-algos. * gpg: Support AEAD encryption mode using OCB or EAX. * gpg: Support v5 keys and signatures. * gpg: Support curve X448 (ed448, cv448). * gpg: Allow use of group names in key listings. [e825aea2ba] * gpg: New option --full-timestrings to print date and time. * gpg: New option --force-sign-key. [#4584] * gpg: New option --no-auto-trust-new-key. * gpg: The legacy key discovery method PKA is no longer supported. The command --print-pka-records and the PKA related import and export options have been removed. * gpg: Support export of Ed448 Secure Shell keys. * gpgsm: Add basic ECC support. * gpgsm: Support creation of EdDSA certificates. [#4888] * agent: Allow the use of "Label:" in a key file to customize the pinentry prompt. [5388537806] * agent: Support ssh-agent extensions for environment variables. With a patched version of OpenSSH this avoids the need for the "updatestartuptty" kludge. [224e26cf7b] * scd: Improve support for multiple card readers and tokens. * scd: Support PIV cards. * scd: Support for Rohde&Schwarz Cybersecurity cards. * scd: Support Telesec Signature Cards v2.0 * scd: Support multiple application on certain smartcard. * scd: New option --application-priority. * scd: New option --pcsc-shared; see man page for important notes. * dirmngr: Support a gpgNtds parameter in LDAP keyserver URLs. * The symcryptrun tool, a wrapper for the now obsolete external Chiasmus tool, has been removed. * Full Unicode support under Windows for the command line. [#4398] Release-info: https://dev.gnupg.org/T5343 Getting the Software ==================== Please follow the instructions found at or read on: GnuPG 2.3.0 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.3.0.tar.bz2 (7380k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.3.0.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.3.0_20210407.exe (4560k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.3.0_20210407.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 featuring this version of GnuPG will be released soon. In the meantime it is possible to install this GnuPG version on top of Gpg4win 3.1.15. 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.3.0.tar.bz2 you would use this command: gpg --verify gnupg-2.3.0.tar.bz2.sig gnupg-2.3.0.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.3.0.tar.bz2, you run the command like this: sha1sum gnupg-2.3.0.tar.bz2 and check that the output matches the next line: 44d06ef6625378e2d135420543e5fb06b62437ab gnupg-2.3.0.tar.bz2 6069b70870cb378b1937a79a752ccc3e9951e0a1 gnupg-w32-2.3.0_20210407.tar.xz 2c1a25a57a785cc96ae7ec317de9d1fb513161b7 gnupg-w32-2.3.0_20210407.exe Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese (traditional and simplified), Czech, French, German, Italian, Japanese, Norwegian, Polish, Russian, and Ukrainian being almost completely translated. Documentation and Support ========================= 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 the 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/T5343 for updated information. Please consult the archive of the gnupg-users mailing list before reporting a bug: https://gnupg.org/documentation/mailing-lists.html. We suggest to send bug reports for a new release to this list in favor of filing a bug at https://bugs.gnupg.org. If you need commercial support go to https://gnupg.com or https://gnupg.org/service.html. If you are a developer and you need a certain feature for your project, please do not hesitate to bring it to the gnupg-devel mailing list for discussion. Thanks ====== Since 2001 maintenance and development of GnuPG is done by g10 Code GmbH and still mostly financed by donations. Three full-time employed developers as well as two contractors exclusively work on GnuPG and closely related software like Libgcrypt, GPGME and Gpg4win. We like to thank all the nice people who are helping the GnuPG project, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, or answering questions on the mailing lists. The financial support of the governmental CERT of Luxembourg (GOVCERT.LU) allowed us to develop new and improved features for smartcards (Yubikey, PIV and Scute) as well as various usability features. Thanks. Many thanks also to all other financial supporters, both corporate and individuals. Without you it would not be possible to keep GnuPG in a good and secure shape and to address all the small and larger requests made by our users. 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: ed25519 2020-08-24 [expires: 2030-06-30] Key fingerprint = 6DAA 6E64 A76D 2840 571B 4902 5288 97B8 2640 3ADA Werner Koch (dist signing 2020) 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) rsa2048 2011-01-12 [expires: 2021-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) The keys are available at https://gnupg.org/signature_key.html and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. -- "If privacy is outlawed, only outlaws will have privacy." - PRZ 1991 -------------- 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 lists at merit.unu.edu Thu Apr 8 11:01:52 2021 From: lists at merit.unu.edu (mj) Date: Thu, 8 Apr 2021 11:01:52 +0200 Subject: logrotate, cron and gpg Message-ID: <7d616c11-40aa-48ea-ef22-9dc25c9f5d29@merit.unu.edu> Hi, We are trying to encrypt log files via logrotate & cron, and I hope someone here can help out a bit. Our logrotate configuration file contains: > olddir gpg/ > compress > compresscmd /usr/bin/gpg > compressoptions -vv --verbose --encrypt --default-key A4DB7xxxD98 > compressext .gpg Now, when logrotates runs the above from cron, we're getting: > gpg: cannot open '/dev/tty': No such device or address > error: failed to compress log /logrotate/gpg//test.log.1 We know --no-tty exists, but it doesn't help in this case, because when using that: > gpg: Sorry, no terminal at all requested - can't get input I do see various howto's that use gpg to encrypt their logfiles this way, for example: https://www.ctrl.blog/entry/gdpr-web-server-logs.html So, we're asking the experts here: What could be our issue, and how to make this work..? This is on debian 10.9 Thanks for any pointers! MJ From m at the13thletter.info Thu Apr 8 13:51:15 2021 From: m at the13thletter.info (Marco Ricci) Date: Thu, 8 Apr 2021 13:51:15 +0200 Subject: logrotate, cron and gpg In-Reply-To: <7d616c11-40aa-48ea-ef22-9dc25c9f5d29@merit.unu.edu> References: <7d616c11-40aa-48ea-ef22-9dc25c9f5d29@merit.unu.edu> Message-ID: Hi mj. Thus spoke mj: > We are trying to encrypt log files via logrotate & cron, and I hope > someone here can help out a bit. > > Our logrotate configuration file contains: > >> olddir gpg/ >> compress >> compresscmd /usr/bin/gpg >> compressoptions -vv --verbose --encrypt --default-key A4DB7xxxD98 >> compressext .gpg > > Now, when logrotates runs the above from cron, we're getting: > >> gpg: cannot open '/dev/tty': No such device or address >> error: failed to compress log /logrotate/gpg//test.log.1 When I run the command gpg -vv --verbose --encrypt --default-key 0x... < /dev/null GnuPG prompts me for a recipient. Without a TTY, such a prompt would fail, of course. So presumably, instead of --default-key, you actually want -r instead...? Also: why are you using both -vv and --verbose at the same time? > We know --no-tty exists, but it doesn't help in this case, because > when using that: > >> gpg: Sorry, no terminal at all requested - can't get input See above. You probably also want --batch as well. Cheers, Marco -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From mac3iii at gmail.com Thu Apr 8 13:37:32 2021 From: mac3iii at gmail.com (murphy) Date: Thu, 8 Apr 2021 07:37:32 -0400 Subject: GnuPG 2.3.0 database Message-ID: <9807866d-a576-692b-627c-08a4d8ca8144@gmail.com> It is with great anticipation that I fire up a raspberry pi 4 to compile the newest version of GnuPG 2.3.0 using speedo. However I ran into: GnuPG version in swdb.lst is less than this version! ? This version: 2.3.0 ? SWDB version: 2.2.27 /home/pi/Downloads/gnupg-2.3.0/build-aux/speedo.mk:393: *** Error getting GnuPG software version database.? Stop. make[1]: Leaving directory '/home/pi/Downloads/gnupg-2.3.0' make: *** [build-aux/speedo.mk:139: native] Error 2 I'm looking forward with held breath to the updated SWDB :) Murphy -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Thu Apr 8 15:06:16 2021 From: wk at gnupg.org (Werner Koch) Date: Thu, 08 Apr 2021 15:06:16 +0200 Subject: logrotate, cron and gpg In-Reply-To: (Marco Ricci's message of "Thu, 8 Apr 2021 13:51:15 +0200") References: <7d616c11-40aa-48ea-ef22-9dc25c9f5d29@merit.unu.edu> Message-ID: <87lf9t6i47.fsf@wheatstone.g10code.de> On Thu, 8 Apr 2021 13:51, Marco Ricci said: > See above. You probably also want --batch as well. Definitely. It might also be a good idea to use a dedicated homedir (or user) for GnuPG or lacking this to add --no-options and give all args on the command line. 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 Thu Apr 8 17:19:27 2021 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 8 Apr 2021 11:19:27 -0400 Subject: Follow-up on L'Affaire Stallman Message-ID: <3e47e65a-790f-e323-7a0c-c14660cd27f2@sixdemonbag.org> A few weeks have passed, and I figured a recap might be appropriate: * FSF continues to support RMS * FSFE has ended collaboration with FSF and GNU ("we see ourselves unable to collaborate both with the FSF and any other organisation in which Richard Stallman has a leading position") * GnuPG has clarified it's not part of GNU * RMS is still welcome to contribute, as is anyone else, but has no authority in either FSFE or GnuPG Thank you, Bernhard and Werner: I really appreciate your quick statements on this. Given this is the current position, I'm starting a complete rewrite of the FAQ for the 2.3 release. I don't know when I'll be finished: not only is it a lot of writing and reviewing, but I have some personal matters that are demanding a lot of my attention. If anyone in the community has strong feelings about the FAQ -- what should go in, what should be left out, etc. -- now's the time. Werner, are you still set on org-mode as the native format, or has Markdown+Pandoc matured enough to also be acceptable? From steffen at sdaoden.eu Thu Apr 8 18:25:10 2021 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 08 Apr 2021 18:25:10 +0200 Subject: Follow-up on L'Affaire Stallman In-Reply-To: <3e47e65a-790f-e323-7a0c-c14660cd27f2@sixdemonbag.org> References: <3e47e65a-790f-e323-7a0c-c14660cd27f2@sixdemonbag.org> Message-ID: <20210408162510.BhIHW%steffen@sdaoden.eu> This is solely my opinion. But i have to say it now. Robert J. Hansen wrote in <3e47e65a-790f-e323-7a0c-c14660cd27f2 at sixdemonbag.org>: |A few weeks have passed, and I figured a recap might be appropriate: | | * FSF continues to support RMS I have no opinion on that. I do not know him, nor whatever. I saw some code from him twenty years ago and did not like it :) However, i did say in the past that i would allow him to travel by airplane, if it would be me, which is much more than i allow myself. And i stand to this opinion. | * FSFE has ended collaboration with FSF and GNU ("we see | ourselves unable to collaborate both with the FSF and any | other organisation in which Richard Stallman has a | leading position") The thing is that we live in a bigot world as gods and destroy live without just any respect. Most humans are very small minded and go for "each cheap piece of meat" just "to sneak away with it". Really, i am bored, thus. Sigh. Anyhow. In the western world cruelty and abuse and anti-social behaviour rather has become the norm, but everywhere you find that elder suppress the younger. Even more so if you _see_. So to tear open the indolence and coldness with which especially solvent white (but not only white) people perch upon exploitation of all possible kinds, environment, finite resources, literally billions of livestock, child and other sexual abuse can only be a good thing. The living conditions that our/the tremendous military and economic terror generates. All this nothing but a shame, that hole is too dark and deep, yet it exists. Quite the opposite, who does risk a saturated and comfortable life in order to aid for something better, at times is called a hero. Well i would not go that far here, Mr. Stallman is from or directly descends from a generation which actually had a quite good outcome of people who tried to make the white race better. Unfortunately, without success. :( Anyhow. There are too many narrow-minded individuals who (due to whatever shortcoming) are not capable to put things in the actual context of actual life as it really is (imho). | * GnuPG has clarified it's not part of GNU Always has, hasn't it. I look at that for hm a long time, and it always was like that. Thank you. And have a nice day. --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 Thu Apr 8 19:59:13 2021 From: wk at gnupg.org (Werner Koch) Date: Thu, 08 Apr 2021 19:59:13 +0200 Subject: Follow-up on L'Affaire Stallman In-Reply-To: <3e47e65a-790f-e323-7a0c-c14660cd27f2@sixdemonbag.org> (Robert J. Hansen via Gnupg-users's message of "Thu, 8 Apr 2021 11:19:27 -0400") References: <3e47e65a-790f-e323-7a0c-c14660cd27f2@sixdemonbag.org> Message-ID: <878s5s7j4e.fsf@wheatstone.g10code.de> On Thu, 8 Apr 2021 11:19, Robert J. Hansen said: > Werner, are you still set on org-mode as the native format, or has > Markdown+Pandoc matured enough to also be acceptable? Yes, pretty please. The FAQ is part of the website which gets automatically build from org-mode. However, if you want to do a complete rewrite, you may start in markdown and I will convert it back then. But please keep the links intact. Thanks for reconsidering to work with us. In fact I have quite some difficulties with the FSF and that started many years ago. There is a reason why some of us maintainers started the https://gnu.tools thing. Shalom-Salam, Werner p.s. I would really like to avoid the RFC-4880bis experience where way to much time was spent on converting a nearly finished draft to whatever markdown dialect is currently en-vogue (some Ruby thing right now). -- 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 lists at merit.unu.edu Thu Apr 8 20:17:53 2021 From: lists at merit.unu.edu (mj) Date: Thu, 8 Apr 2021 20:17:53 +0200 Subject: logrotate, cron and gpg In-Reply-To: <87lf9t6i47.fsf@wheatstone.g10code.de> References: <7d616c11-40aa-48ea-ef22-9dc25c9f5d29@merit.unu.edu> <87lf9t6i47.fsf@wheatstone.g10code.de> Message-ID: <530afadf-9074-0a7b-b211-a3269a1255d6@merit.unu.edu> Hi Werner and Marco, Thank you very much for both your kind responses. Have adjusted my config, and in my brief testing it seems to work. Curious to checkout my server tomorrow morning, after cron did it's nightly thing. Thank you! On 4/8/21 3:06 PM, Werner Koch via Gnupg-users wrote: > On Thu, 8 Apr 2021 13:51, Marco Ricci said: > >> See above. You probably also want --batch as well. > > Definitely. It might also be a good idea to use a dedicated homedir (or > user) for GnuPG or lacking this to add --no-options and give all args on > the command line. > > > Shalom-Salam, > > Werner > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > From lockywolf at gmail.com Fri Apr 9 04:59:43 2021 From: lockywolf at gmail.com (Vladimir Nikishkin) Date: Fri, 9 Apr 2021 10:59:43 +0800 Subject: Follow-up on L'Affaire Stallman In-Reply-To: <20210408162510.BhIHW%steffen@sdaoden.eu> References: <3e47e65a-790f-e323-7a0c-c14660cd27f2@sixdemonbag.org> <20210408162510.BhIHW%steffen@sdaoden.eu> Message-ID: I'm just a user, but since this mailing list is called "users", and for clairity: >>Always has, hasn't it. I look at that for hm a long time, and it always was like that. The FAQ (https://www.gnupg.org/faq/gnupg-faq.html) claims the other way round, namely: >GnuPG is free cryptographic software from the GNU Project which helps people ensure the confidentiality, integrity and assurance of their data. Let?s try that again: GnuPG is? >GNU Project. The GNU Project is a group that aims to give people the ability to do all their computing with free software. So I, as a user, was completely sure that GnuPG _is_ (or, at least, was) an official GNU Project. Regarding the Stallman story, the community seems to be split roughly by a third, with one third of activists having signed an open letter with criticism, and two thirds considering the criticism unjustified (and having signed the support letter). On Fri, 9 Apr 2021 at 01:59, Steffen Nurpmeso wrote: > > This is solely my opinion. But i have to say it now. > > Robert J. Hansen wrote in > <3e47e65a-790f-e323-7a0c-c14660cd27f2 at sixdemonbag.org>: > |A few weeks have passed, and I figured a recap might be appropriate: > | > | * FSF continues to support RMS > > I have no opinion on that. I do not know him, nor whatever. > I saw some code from him twenty years ago and did not like it :) > However, i did say in the past that i would allow him to travel by > airplane, if it would be me, which is much more than i allow > myself. And i stand to this opinion. > > | * FSFE has ended collaboration with FSF and GNU ("we see > | ourselves unable to collaborate both with the FSF and any > | other organisation in which Richard Stallman has a > | leading position") > > The thing is that we live in a bigot world as gods and destroy > live without just any respect. Most humans are very small minded > and go for "each cheap piece of meat" just "to sneak away with > it". Really, i am bored, thus. Sigh. Anyhow. In the western > world cruelty and abuse and anti-social behaviour rather has > become the norm, but everywhere you find that elder suppress the > younger. Even more so if you _see_. > > So to tear open the indolence and coldness with which especially > solvent white (but not only white) people perch upon exploitation > of all possible kinds, environment, finite resources, literally > billions of livestock, child and other sexual abuse can only be > a good thing. The living conditions that our/the tremendous > military and economic terror generates. All this nothing but > a shame, that hole is too dark and deep, yet it exists. > > Quite the opposite, who does risk a saturated and comfortable life > in order to aid for something better, at times is called a hero. > Well i would not go that far here, Mr. Stallman is from or > directly descends from a generation which actually had a quite > good outcome of people who tried to make the white race better. > Unfortunately, without success. :( > > Anyhow. There are too many narrow-minded individuals who (due to > whatever shortcoming) are not capable to put things in the actual > context of actual life as it really is (imho). > > | * GnuPG has clarified it's not part of GNU > > Always has, hasn't it. I look at that for hm a long time, and it > always was like that. > > Thank you. And have a nice day. > > --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) > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -- Yours sincerely, Vladimir Nikishkin (Sent from GMail web interface.) From rjh at sixdemonbag.org Fri Apr 9 06:39:01 2021 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 9 Apr 2021 00:39:01 -0400 Subject: Follow-up on L'Affaire Stallman In-Reply-To: References: <3e47e65a-790f-e323-7a0c-c14660cd27f2@sixdemonbag.org> <20210408162510.BhIHW%steffen@sdaoden.eu> Message-ID: <67bf246b-3495-75c7-dc13-48b6624c12ec@sixdemonbag.org> > The FAQ (https://www.gnupg.org/faq/gnupg-faq.html) claims the other > way round, namely: Yep. Which was why I stepped away: I've ended my affiliations with FSF and GNU. However, that FAQ was last overhauled in October 2017, and apparently the relationship has changed in the last three and a half years. From johndoe65534 at mail.com Fri Apr 9 08:52:43 2021 From: johndoe65534 at mail.com (john doe) Date: Fri, 9 Apr 2021 08:52:43 +0200 Subject: Follow-up on L'Affaire Stallman In-Reply-To: <3e47e65a-790f-e323-7a0c-c14660cd27f2@sixdemonbag.org> References: <3e47e65a-790f-e323-7a0c-c14660cd27f2@sixdemonbag.org> Message-ID: <8ca32bb6-acea-423b-e588-0a5e161fe558@mail.com> On 4/8/2021 5:19 PM, Robert J. Hansen via Gnupg-users wrote: > If anyone in the community has strong feelings about the FAQ -- what > should go in, what should be left out, etc. -- now's the time. > The only thing that I can say is that I would rather see a FAQ that reflect the current inplementation of GPG than a non-up to date FAQ per lack of user consensus (1). EG: Due to a lack of consensus, the FAQ was never updated to reflect that '3072' is now the default in GPG. That is to say, that in my view a FAQ that explains clearly how to use GPG is somewhat more importent than comunity feedback. A statement to that effect at the top of the page could be added describing why this way was chosen. 1) https://lists.gnupg.org/pipermail/gnupg-users/2021-March/064974.html -- John Doe From ldore at mailc.net Fri Apr 9 14:44:00 2021 From: ldore at mailc.net (Luc Dore) Date: Fri, 9 Apr 2021 05:44:00 -0700 Subject: Kleopatra v3.1.5 isn't happy Message-ID: Hello Everyone, I just updated my win 10 install to gnupg 3.1.5 and kleopatra isn't happy anymore.? I have this popup at startup about Kleopatra running as an admin: Does any one know the proper permissions that the error message is referring to?? my windows user has full control over my appdata\roaming\gnupg folder. Thanks. -- Luc D. -- ldore at mailc.net GPG key id: 0xB8E5417BA3D88402 Proud supporter of the EFF, www.eff.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: efopnkpjlonghloe.png Type: image/png Size: 18280 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0xB8E5417BA3D88402.asc Type: application/pgp-keys Size: 2353 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 665 bytes Desc: OpenPGP digital signature URL: From stefan.vasilev at posteo.ru Fri Apr 9 16:47:50 2021 From: stefan.vasilev at posteo.ru (Stefan Vasilev) Date: Fri, 9 Apr 2021 16:47:50 +0200 Subject: [GnuPG 1.4.x] max. amount of UIDs Message-ID: Hello, for a privacy project I am working on I need the ability to use GnuPG 1.4.x for Windows and would like to know how many UIDs Alice and Bob can assing to a shared single key pair. Regards Stefan From rjh at sixdemonbag.org Fri Apr 9 17:47:52 2021 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 9 Apr 2021 11:47:52 -0400 Subject: Follow-up on L'Affaire Stallman In-Reply-To: <8ca32bb6-acea-423b-e588-0a5e161fe558@mail.com> References: <3e47e65a-790f-e323-7a0c-c14660cd27f2@sixdemonbag.org> <8ca32bb6-acea-423b-e588-0a5e161fe558@mail.com> Message-ID: > The only thing that I can say is that I would rather see a FAQ that > reflect the current inplementation of GPG than a non-up to date FAQ per > lack of user consensus (1). The problem there is without community buy-in, the FAQ lacks credibility. It's supposed to be the *community's* FAQ, which is why people consider it authoritative. "This is Rob's thinking" would be, to say the least, controversial: some people think I explain things accurately and clearly, and others think I've been sniffing glue since a tender age. From wk at gnupg.org Fri Apr 9 18:54:46 2021 From: wk at gnupg.org (Werner Koch) Date: Fri, 09 Apr 2021 18:54:46 +0200 Subject: GnuPG 2.3.0 database In-Reply-To: <9807866d-a576-692b-627c-08a4d8ca8144@gmail.com> (murphy via Gnupg-users's message of "Thu, 8 Apr 2021 07:37:32 -0400") References: <9807866d-a576-692b-627c-08a4d8ca8144@gmail.com> Message-ID: <87czv35rft.fsf@wheatstone.g10code.de> On Thu, 8 Apr 2021 07:37, murphy said: > It is with great anticipation that I fire up a raspberry pi 4 to compile > the newest version of GnuPG 2.3.0 using speedo. However I ran into: > > GnuPG version in swdb.lst is less than this version! > ? This version: 2.3.0 > ? SWDB version: 2.2.27 Sorry about this. There is an easy fix: --8<---------------cut here---------------start------------->8--- --- a/build-aux/getswdb.sh +++ b/build-aux/getswdb.sh @@ -175,9 +175,9 @@ fi # to help detect rollback attacks. # if [ $skip_selfcheck = no ]; then - gnupg_ver=$(awk '$1=="gnupg22_ver" {print $2;exit}' swdb.lst) + gnupg_ver=$(awk '$1=="gnupg24_ver" {print $2;exit}' swdb.lst) if [ -z "$gnupg_ver" ]; then - echo "GnuPG 2.2 version missing in swdb.lst!" >&2 + echo "GnuPG 2.4 version info missing in swdb.lst!" >&2 exit 1 fi gnupg_ver_num=$(echo "$gnupg_ver" | cvtver) Modified configure.ac --8<---------------cut here---------------end--------------->8--- Not guarantee that things works, the release process uses speedo only for the Windows build. So, if you run into more errors, please let us know. 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 Fri Apr 9 19:01:52 2021 From: wk at gnupg.org (Werner Koch) Date: Fri, 09 Apr 2021 19:01:52 +0200 Subject: Kleopatra v3.1.5 isn't happy In-Reply-To: (Luc Dore via Gnupg-users's message of "Fri, 9 Apr 2021 05:44:00 -0700") References: Message-ID: <878s5r5r3z.fsf@wheatstone.g10code.de> On Fri, 9 Apr 2021 05:44, Luc Dore said: > anymore.? I have this popup at startup about Kleopatra running as an admin: You should never ever run programs as Admin on Windows (or as root under Unix) if there is no need for it. For an application GUI tool there is a never such a need - install it as admin but use it with a regualr user account. If you run gnupg on the command line as Admin, gnupg may create files which it can later, running as the regular user, not read or write again. Gpg4win mereley added a warning to avoid such pitfalls. 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 Fri Apr 9 19:08:47 2021 From: wk at gnupg.org (Werner Koch) Date: Fri, 09 Apr 2021 19:08:47 +0200 Subject: [GnuPG 1.4.x] max. amount of UIDs In-Reply-To: (Stefan Vasilev via Gnupg-users's message of "Fri, 9 Apr 2021 16:47:50 +0200") References: Message-ID: <8735vz5qsg.fsf@wheatstone.g10code.de> On Fri, 9 Apr 2021 16:47, Stefan Vasilev said: > for a privacy project I am working on I need the ability to use GnuPG 1.4.x No you don't need 1.4 - it is obsolete and maionatined only to decrypt existing data. > for Windows and would like to know how many UIDs Alice and Bob can There is some limit on the size of the keyblock (iirc 5 MiB) , but there is no explicit limit on the number of user ids. 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 ldore at mailc.net Fri Apr 9 19:11:54 2021 From: ldore at mailc.net (Luc Dore) Date: Fri, 9 Apr 2021 10:11:54 -0700 Subject: Kleopatra v3.1.5 isn't happy In-Reply-To: <878s5r5r3z.fsf@wheatstone.g10code.de> References: <878s5r5r3z.fsf@wheatstone.g10code.de> Message-ID: <5fec37b2-ad0d-baa6-1eff-b19da35645d1@mailc.net> HI Werner, You should never ever run programs as Admin on Windows -> I'm not running the program as admin,? I'm running it as my regular user, but it is part of the administrators group. Gpg4win merely added a warning to avoid such pitfalls -> That's the problem Werner, once you "OK" this window Kleopatra does /not/ launch.? I had to revert back to 3.0.14 to be able to use Kleopatra again. On 4/9/2021 10:01 AM, Werner Koch wrote: > On Fri, 9 Apr 2021 05:44, Luc Dore said: > >> anymore.? I have this popup at startup about Kleopatra running as an admin: > You should never ever run programs as Admin on Windows (or as root under > Unix) if there is no need for it. For an application GUI tool there is > a never such a need - install it as admin but use it with a regualr user > account. > > If you run gnupg on the command line as Admin, gnupg may create files > which it can later, running as the regular user, not read or write > again. > > Gpg4win mereley added a warning to avoid such pitfalls. > > > Salam-Shalom, > > Werner > -- Luc D. -- ldore at mailc.net GPG key id: 0xB8E5417BA3D88402 Proud supporter of the EFF, www.eff.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From joel.rees at gmail.com Fri Apr 9 18:33:00 2021 From: joel.rees at gmail.com (Joel Rees) Date: Sat, 10 Apr 2021 01:33:00 +0900 Subject: Follow-up on L'Affaire Stallman In-Reply-To: <3e47e65a-790f-e323-7a0c-c14660cd27f2@sixdemonbag.org> References: <3e47e65a-790f-e323-7a0c-c14660cd27f2@sixdemonbag.org> Message-ID: Can I ask what new reason to make Stallman a scapegoat has emerged? And why so many apparent core members of the gnupg community seem to be joining the cancel culture? -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Fri Apr 9 19:59:52 2021 From: wk at gnupg.org (Werner Koch) Date: Fri, 09 Apr 2021 19:59:52 +0200 Subject: Follow-up on L'Affaire Stallman In-Reply-To: (Joel Rees via Gnupg-users's message of "Sat, 10 Apr 2021 01:33:00 +0900") References: <3e47e65a-790f-e323-7a0c-c14660cd27f2@sixdemonbag.org> Message-ID: <87tuof49uv.fsf@wheatstone.g10code.de> Hi! can we please stop this thread? This is a technical and privacy oriented mailing list and not a medium to discuss the pros and cons of a certain person. There are a enough other places for such chitchat. 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 stefan.vasilev at posteo.ru Fri Apr 9 20:26:05 2021 From: stefan.vasilev at posteo.ru (Stefan Vasilev) Date: Fri, 9 Apr 2021 20:26:05 +0200 Subject: [GnuPG 1.4.x] max. amount of UIDs In-Reply-To: <8735vz5qsg.fsf@wheatstone.g10code.de> References: <8735vz5qsg.fsf@wheatstone.g10code.de> Message-ID: Werner Koch wrote: > On Fri, 9 Apr 2021 16:47, Stefan Vasilev said: > >> for a privacy project I am working on I need the ability to use GnuPG 1.4.x > No you don't need 1.4 - it is obsolete and maionatined only to decrypt > existing data. I am aware of that, but my thought was that the .exe and .dll from 1.4 can be used, for portability reasons, in a Desktop folder and then one only needs to use the --homedir parameter. I must admit I have not tried yet, but if this is possible with the latest version of gpg4win, that all its required components can be installed and used with --homedir then there is no need for 1.4. >> for Windows and would like to know how many UIDs Alice and Bob can > There is some limit on the size of the keyblock (iirc 5 MiB) , but there > is no explicit limit on the number of user ids. > Thank you, I will then have to work out how much UIDs may fit in a keyblock. Regards Stefan From klaus+gnupg at ethgen.ch Fri Apr 9 20:37:05 2021 From: klaus+gnupg at ethgen.ch (Klaus Ethgen) Date: Fri, 9 Apr 2021 19:37:05 +0100 Subject: Follow-up on L'Affaire Stallman In-Reply-To: <87tuof49uv.fsf@wheatstone.g10code.de> References: <3e47e65a-790f-e323-7a0c-c14660cd27f2@sixdemonbag.org> <87tuof49uv.fsf@wheatstone.g10code.de> Message-ID: Hi Werner, Am Fr den 9. Apr 2021 um 18:59 schrieb Werner Koch via Gnupg-users: > can we please stop this thread? > > This is a technical and privacy oriented mailing list and not a medium > to discuss the pros and cons of a certain person. There are a enough > other places for such chitchat. So please tell this to Robert J. Hansen who did twice bring some political cancel culture discussions to this list. I endorse Joel Rees question. There is no reason to try to cancel out RMS. I am not a big fan of him and his personality might be questionnaire to some, but there is no reason why he should be banned from anything. In fact, RMS did very great thinks for us as community. So please give at least something that justifies all that hate writings against RMS. Gru? Klaus -- Klaus Ethgen http://www.ethgen.ch/ pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 688 bytes Desc: not available URL: From r.f.wolpert at gmail.com Fri Apr 9 21:44:17 2021 From: r.f.wolpert at gmail.com (Rembrandt Wolpert) Date: Fri, 9 Apr 2021 21:44:17 +0200 Subject: Follow-up on L'Affaire Stallman In-Reply-To: <87tuof49uv.fsf@wheatstone.g10code.de> References: <3e47e65a-790f-e323-7a0c-c14660cd27f2@sixdemonbag.org> <87tuof49uv.fsf@wheatstone.g10code.de> Message-ID: <3b4629b1-a26e-bcb8-4aed-417bfab1c474@gmail.com> On 4/9/21 19:59, Werner Koch via Gnupg-users wrote: > Hi! > > can we please stop this thread? PLEASE! Thank you. > > This is a technical and privacy oriented mailing list and not a medium > to discuss the pros and cons of a certain person. There are a enough > other places for such chitchat.> Indeed. as ever, Rembrandt --- ????? ????? ????? ????? From jcb62281 at gmail.com Fri Apr 9 23:54:46 2021 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Fri, 09 Apr 2021 16:54:46 -0500 Subject: Follow-up on L'Affaire Stallman In-Reply-To: References: <3e47e65a-790f-e323-7a0c-c14660cd27f2@sixdemonbag.org> Message-ID: <6070CD26.6000006@gmail.com> Joel Rees via Gnupg-users wrote: > Can I ask what new reason to make Stallman a scapegoat has emerged? The recent round of attacks on Stallman seem to have begun after RMS returned to the FSF Board. There is some controversy over the factual basis for these attacks. (In other words, there are accusations that the current accusations against RMS have no basis in fact and are basically made up.) There was similar controversy over the events that led to RMS leaving the FSF Board previously. Based on what I have seen, some of the accusations are fabricated, some are RMS's words twisted and taken out of context, and some are legitimate complaints about Stallman as a person and his past behavior. That said, this list is supposed to be for discussion of issues related to the use of GPG, and RMS is not related to that, so this thread really should be dropped and I am only writing this so that future readers of the list archive will not be left hanging and thinking that that question was dodged. As to your other question, I cannot speak for the motivations of other people. -- Jacob From kiara.stankovic89 at outlook.com Sat Apr 10 05:46:34 2021 From: kiara.stankovic89 at outlook.com (Kiara Stankovic) Date: Sat, 10 Apr 2021 03:46:34 +0000 Subject: Add masterkey as subkey to new masterkey Message-ID: Hello gnupg-users, I want to add my existing master key as a subkey to a new master key. I have followed the steps at https://security.stackexchange.com/questions/32935/migrating-gpg-master-keys-as-subkeys-to-new-master-key, and I was able to slot in my subkey, as well concatenate it into one file as well, but while importing it (with the latest version of gnupg) I encountered an error - bad signature, realizing that I had to use an old version of gnupg - around 2005, but I did not have access to any such gpg binaries. Are there any workarounds for this? Adding a subkey with keygrip also doesnt work, since the new subkey has a different keyid than the original key. Can someone help me? -- Kiara Stankovic -------------- next part -------------- An HTML attachment was scrubbed... URL: From dyw972 at protonmail.com Fri Apr 9 11:22:54 2021 From: dyw972 at protonmail.com (Yohan W. Dunon) Date: Fri, 09 Apr 2021 09:22:54 +0000 Subject: GnuPG returns error after install but works Message-ID: Hello, First of all, I want to say thank you for your work! I'am a beginner and I've installed GnuPG 2.2.27 with the necessary packages: - npth (https://gnupg.org/ftp/gcrypt/npth/) - libgpg-error (https://gnupg.org/ftp/gcrypt/libgpg-error/) - libgcrypt (https://gnupg.org/ftp/gcrypt/libgcrypt/) - libksba (https://gnupg.org/ftp/gcrypt/libksba/) - libassuan (https://gnupg.org/ftp/gcrypt/libassuan/) Followed exactly the INSTALL files inside each packages. But at the end, my terminal return this: Making install in m4 make[2]: Nothing to be done for `install-exec-am'. make[2]: Nothing to be done for `install-data-am'. Making install in common /Applications/Xcode.app/Contents/Developer/usr/bin/makeinstall-am make[3]: Nothing to be done for `install-exec-am'. make[3]: Nothing to be done for `install-data-am'. Making install in regexp /Applications/Xcode.app/Contents/Developer/usr/bin/makeinstall-am make[3]: Nothing to be done for `install-exec-am'. make[3]: Nothing to be done for `install-data-am'. Making install in kbx ../build-aux/install-sh -c -d '/usr/local/bin' /usr/bin/install -c kbxutil '/usr/local/bin' make[2]: Nothing to be done for `install-data-am'. Making install in g10 /Applications/Xcode.app/Contents/Developer/usr/bin/makeinstall-exec-hook running install-exec-hook ../build-aux/install-sh -c -d '/usr/local/bin' /usr/bin/install -cgpg '/usr/local/bin/gpg' /usr/bin/install -cgpgv '/usr/local/bin/gpgv' /bin/sh ../build-aux/mkinstalldirs /usr/local/share/gnupg /usr/bin/install -c -m 644 ./distsigkey.gpg \ /usr/local/share/gnupg/distsigkey.gpg Making install in sm ../build-aux/install-sh -c -d '/usr/local/bin' /usr/bin/install -c gpgsm '/usr/local/bin' make[2]: Nothing to be done for `install-data-am'. Making install in agent ../build-aux/install-sh -c -d '/usr/local/bin' /usr/bin/install -c gpg-agent '/usr/local/bin' ../build-aux/install-sh -c -d '/usr/local/libexec' mkdir: /usr/local/libexec: Permission denied make[2]: *** [install-libexecPROGRAMS] Error 1 make[1]: *** [install-am] Error 2 make: *** [install-recursive] Error 1 There is something wrong ? However when I type which gpg in my terminal, returns /usr/local/bin/gpg and I can use it. Can you help with this ? Best regards Yohan W. Dunon Sent with [ProtonMail](https://protonmail.com) Secure Email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From secretaries_splenoptosia at aleeas.com Fri Apr 9 14:17:16 2021 From: secretaries_splenoptosia at aleeas.com (secretaries_splenoptosia at aleeas.com) Date: Fri, 09 Apr 2021 12:17:16 -0000 Subject: use "old" masterkey as subkey in new masterkey Message-ID: <161797063687.7.18365157218729095914.5656686@aleeas.com> hey, i am trying to manage my protonmail gpg by adding it to my masterkey. I have looked at https://security.stackexchange.com/questions/32935/migrating-gpg-master-keys-as-subkeys-to-new-master-key I was able to slot in my subkey, and was able to concatenate it into one file as well, but while importing it (with the lastest version of gnupg) i got an error - bad signature, realizing that i had to use an old version of gnupg - around 2005, but I did not have access to any such gpg binaries. Are there any workarounds for this? adding a subkey with keygrip also doesnt work, since the new subkey has a different keyid than the original key. Can someone help me? -------------- next part -------------- An HTML attachment was scrubbed... URL: From kiara.stankovic89 at outlook.com Sat Apr 10 06:08:51 2021 From: kiara.stankovic89 at outlook.com (Kiara Stankovic) Date: Sat, 10 Apr 2021 04:08:51 +0000 Subject: Add masterkey as subkey to new masterkey In-Reply-To: References: Message-ID: Hello gnupg-users, I want to add my existing master key as a subkey to a new master key. I have followed the steps at https://security.stackexchange.com/questions/32935/migrating-gpg-master-keys-as-subkeys-to-new-master-key, and I was able to slot in my subkey, as well concatenate it into one file as well, but while importing it (with the latest version of gnupg) I encountered an error - bad signature, realizing that I had to use an old version of gnupg - around 2005, but I did not have access to any such gpg binaries. Are there any workarounds for this? Adding a subkey with keygrip also doesnt work, since the new subkey has a different keyid than the original key. Can someone help me? -- Kiara Stankovic -------------- next part -------------- An HTML attachment was scrubbed... URL: From angel at pgp.16bits.net Sun Apr 11 04:17:07 2021 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Sun, 11 Apr 2021 04:17:07 +0200 Subject: Add masterkey as subkey to new masterkey In-Reply-To: References: Message-ID: <4b799b28f1b601237f8e8dab4bfc9fc68ddb011e.camel@16bits.net> On 2021-04-10 at 04:08 +0000, Kiara Stankovic wrote: > Hello gnupg-users, > > I want to add my existing master key as a subkey to a new master key. > > I have followed the steps at > https://security.stackexchange.com/questions/32935/migrating-gpg-master-keys-as-subkeys-to-new-master-key > , and I was able to slot in my subkey, as well concatenate it into > one file as well, but while importing it (with the latest version of > gnupg) I encountered an error - bad signature, realizing that I had > to use an old version of gnupg - around 2005, but I did not have > access to any such gpg binaries. > > Are there any workarounds for this? > Adding a subkey with keygrip also doesnt work, since the new subkey > has a different keyid than the original key. > > Can someone help me? > -- > Kiara Stankovic The solution of https://security.stackexchange.com/a/160847/ should work fine. What do you mean with "the new subkey has a different keyid than the original key" ? Note you need to use the keygrip, not the keyid. Maybe you could provide the steps you are doing along with its output? From andrew at lists.savchenko.net Sun Apr 11 03:22:36 2021 From: andrew at lists.savchenko.net (Andrew Savchenko) Date: Sun, 11 Apr 2021 10:52:36 +0930 Subject: TPM operations in v2.3 Message-ID: <649287747.20210411105136@savchenko.net> Hello GnuPG, Just read about the v2.3 release; TPM feature is straight from the "dreams come true" category, massive update! Two questions: 1. When the key is unsealed, which PCRs registers are queried to ensure that measurements are the same as when the key was sealed? 2. Is there ability to change which PCRs are used during the `keytotpm` phase? My very generic understanding of the process, please correct if the assumptions below are false: 1. Key is generated on the target host 2. Key is sealed in TPM using user-supplied password and PCR registers P.S. At the beginning of the blog-post, James says: "...is the ability to use a TPM 2.0 (which comes with all reasonably recent laptops) to protect all the private keys". This can be changed to "reasonably recent anything", as these days TPMs can be found in desktops, servers and CPUs. Either fTPM or dTPM, all conforming to TPM v2.0 standard. -- Regards, A From jsmith9810 at gmx.com Sun Apr 11 15:36:44 2021 From: jsmith9810 at gmx.com (jsmith9810 at gmx.com) Date: Sun, 11 Apr 2021 15:36:44 +0200 Subject: =?UTF-8?Q?Re=3A=C2=A0Re=3A_Add_masterkey_as_subkey_to_new_masterkey?= Message-ID: On 4/10/21, 10:18 PM "?ngel" wrote: > > On 2021-04-10 at 04:08 +0000, Kiara Stankovic wrote: > > > > Adding a subkey with keygrip also doesnt work, since the new subkey > > has a different keyid than the original key. > > The solution of?https://security.stackexchange.com/a/160847/?should > work fine. What do you mean with "the new subkey has a different keyid > than the original key" ? Note you need to use the keygrip, not the > keyid. > > Maybe you could provide the steps you are doing along with its output? Kiara is right - when importing an existing key using addkey command with --edit-key --expert options, gpg uses the current time as the key creation time for the newly imported key, thereby changing its fingerprint/keyid. To retain the original key-id, just get the key-creation timestamp of the existing key from its public key packet dump using this command: $ gpg --export | gpg --list-packet :public sub key packet: version 4, algo 1, created 1618147110, expires 0 Then use the following parameters with the --edit-key command when importing this key: --expert --faked-system-time="!" --ignore-time-conflict From karel-v_g at tutanota.com Sun Apr 11 20:32:19 2021 From: karel-v_g at tutanota.com (karel-v_g at tutanota.com) Date: Sun, 11 Apr 2021 20:32:19 +0200 (CEST) Subject: GnuPG 2.3.0: new ECC curves Message-ID: Hello! The list of additions and changes to GnuPG 2.3 is quite impressive. Thanks for all the work on GnuPG. Just out of curiosity one question: why did you "only" add curve x448 from the SafeCurves project and not also E-521? For NIST and Brainpool the available curves >500bits are also already supported. Cheers Karel From bernhard at intevation.de Mon Apr 12 12:40:11 2021 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 12 Apr 2021 12:40:11 +0200 Subject: Public relations: GnuPG 2.3.0 status? In-Reply-To: <877dld87tf.fsf@wheatstone.g10code.de> References: <877dld87tf.fsf@wheatstone.g10code.de> Message-ID: <202104121240.25779.bernhard@intevation.de> Am Donnerstag 08 April 2021 11:05:48 schrieb Werner Koch via Gnupg-devel: > We are pleased to announce the availability of a new GnuPG release: > version 2.3.0. Congratulations! As I am trying to spread the word, I am considering how to write about the status of the release. https://gnupg.org/download/index.html calls it **devel** GnuPG (devel) 2.3.0 (and the 2.2.27 "LTS"). In contrast, the text here assumes as least "beta": > This release marks the start of public testing releases > eventually leading to a new stable version 2.4. > > Although some bugs might linger in the 2.3 versions, they are intended > to replace the 2.2 series. 2.3 may even be used for production purposes > if either the risk of minor regressions is acceptable or the new > features are important. On the other hand it is "released", and it is okay to use in production, so it could just be labeled the "current release" (and 2.2 "LTS" in contrast") However the quote above talks about "public testing releases", which again more hints towards "release candidate". My suggestion: a) give it no label (thus implicitly assuming a regular release) b) change the download webpage to remove the "(devel)" substring. Rationale: It is okay for production (under some circumstances) and this is the main association people have with a release. It being a point release, will make people cautious that have reason to be conservative. Fine by you? Best Regards, Bernhard -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From karel-v_g at tutanota.com Sun Apr 11 22:07:08 2021 From: karel-v_g at tutanota.com (karel-v_g at tutanota.com) Date: Sun, 11 Apr 2021 22:07:08 +0200 (CEST) Subject: GnuPG 2.3.0: AEAD - no GCM-Mode? Message-ID: Hello! Another question: why don?t you use GCM as a possible mode for AEAD? It seems to be the most common nowadays and was also implemented in S/MIME v4 to overcome efail.Cheers Karel From dgouttegattat at incenp.org Mon Apr 12 15:06:33 2021 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Mon, 12 Apr 2021 14:06:33 +0100 Subject: GnuPG 2.3.0: AEAD - no GCM-Mode? In-Reply-To: References: Message-ID: <20210412130633.dqfv4idh6odln2bz@dynein.local.incenp.org> Hi, On Sun, Apr 11, 2021 at 10:07:08PM +0200, karel-v_g--- via Gnupg-users wrote: >Another question: why don?t you use GCM as a possible mode for AEAD? This kind of questions should rather go to the IETF OpenPGP mailing list [1], where the OpenPGP format iself (not its implementations) is discussed. The option of using GCM in particular *has* been discussed, but there was no consensus for it. If anything, there was almost a consensus *against* GCM [2,3]. >It seems to be the most common nowadays My understanding (from following the discussion in the WG at the time) was that people have been using GCM mostly because they could not or did not want to use OCB. Now that OCB is no longer encumbered by patents, there may not be an interest in GCM anymore. - Damien [1] https://www.ietf.org/mailman/listinfo/openpgp [2] https://mailarchive.ietf.org/arch/msg/openpgp/V4ND7Dcx8MG6oNnYbUntaX8cbzM/ [3] https://mailarchive.ietf.org/arch/msg/openpgp/fsxXaDD3SkZuktQ7yl22jHioDKw/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From wk at gnupg.org Mon Apr 12 18:39:01 2021 From: wk at gnupg.org (Werner Koch) Date: Mon, 12 Apr 2021 18:39:01 +0200 Subject: GnuPG 2.3.0: new ECC curves In-Reply-To: (karel-v's message of "Sun, 11 Apr 2021 20:32:19 +0200 (CEST)") References: Message-ID: <874kgb4fve.fsf@wheatstone.g10code.de> On Sun, 11 Apr 2021 20:32, karel-v_g--- said: > Just out of curiosity one question: why did you "only" add curve x448 Because 25519 and 448 are the IETF standard curves. More curves are a hassle for interoperability. > from the SafeCurves project and not also E-521? For NIST and Brainpool > the available curves >500bits are also already supported. NIST and Brainpool have been with us for 10 years and are still required by some policy requirements. 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 gnupg at shoran-und-alira.de Thu Apr 15 17:25:29 2021 From: gnupg at shoran-und-alira.de (Frank) Date: Thu, 15 Apr 2021 17:25:29 +0200 Subject: Compile of gnupg-2.2.27 fails on t-keydb.c In-Reply-To: <20210323161628.Horde.aogaZ7-Ew0X-TB7xEkVpHw5@webmail.df.eu> References: <20210320190641.Horde.ZLPIsIwUqzZkBGVP8ok6aA3@webmail.df.eu> <874kh2m5eh.fsf@wheatstone.g10code.de> <20210323161628.Horde.aogaZ7-Ew0X-TB7xEkVpHw5@webmail.df.eu> Message-ID: <20210415172529.Horde.OwHJ_i8fKeLD9lkXiYmQbQ3@webmail.df.eu> Hi Werner, I assume you are busy with the 2.30 release (congratulations!) but you have any more hints how to get more informations on my compile problem? Any help is appreciated. Kind regards Frank From gniibe at fsij.org Fri Apr 16 07:27:40 2021 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 16 Apr 2021 14:27:40 +0900 Subject: Compile of gnupg-2.2.27 fails on t-keydb.c In-Reply-To: <20210415172529.Horde.OwHJ_i8fKeLD9lkXiYmQbQ3@webmail.df.eu> References: <20210320190641.Horde.ZLPIsIwUqzZkBGVP8ok6aA3@webmail.df.eu> <874kh2m5eh.fsf@wheatstone.g10code.de> <20210323161628.Horde.aogaZ7-Ew0X-TB7xEkVpHw5@webmail.df.eu> <20210415172529.Horde.OwHJ_i8fKeLD9lkXiYmQbQ3@webmail.df.eu> Message-ID: <87r1jabxyr.fsf@iwagami.gniibe.org> Frank wrote: > Hi Werner, > > I assume you are busy with the 2.30 release (congratulations!) but you > have any more hints how to get more informations on my compile problem? Since Werner is busy, let me reply, to where I can understand. IIUC, GnuPG 2.3.0 needs some fix for your environment (xlc on AIX). > I think AIX might work with __inline__ (? have not tried that): I think that xlc supports C99 standard. But unfortunately, it seems that it is used with an option of "-qlanglvl=extc89", which specifies C89 standard. Note that you need a compiler which supports C99 standard for "inline". I your log: > > source='t-keydb.c' object='t-keydb.o' libtool=no > DEPDIR=.deps depmode=xlc /opt/freeware/bin/bash ../build-aux/depcomp > cc -qlanglvl=extc89 -DHAVE_CONFIG_H -I. -I.. ^^^^^^^^^^^^^^^ This is the problem. I wonder where this option comes from. If it is from autoconf, you would need a fix like: diff --git a/configure.ac b/configure.ac index 215a6535f..2a50c5b73 100644 --- a/configure.ac +++ b/configure.ac @@ -638,7 +638,7 @@ AM_MISSING_PROG(AUTOHEADER, autoheader, $missing_dir) AM_MISSING_PROG(MAKEINFO, makeinfo, $missing_dir) AM_SILENT_RULES AC_PROG_AWK -AC_PROG_CC +AC_PROG_CC_C99 AC_PROG_CPP AM_PROG_CC_C_O if test "x$ac_cv_prog_cc_c89" = "xno" ; then And you need to regenerate the configure script, becoure "make". Or it is you who specified CC, you invoking make with CC="cc -qlanglvl=extc99" ... may just work. -- From gniibe at fsij.org Fri Apr 16 07:28:00 2021 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 16 Apr 2021 14:28:00 +0900 Subject: Compile of gnupg-2.2.27 fails on t-keydb.c In-Reply-To: <20210415172529.Horde.OwHJ_i8fKeLD9lkXiYmQbQ3@webmail.df.eu> References: <20210320190641.Horde.ZLPIsIwUqzZkBGVP8ok6aA3@webmail.df.eu> <874kh2m5eh.fsf@wheatstone.g10code.de> <20210323161628.Horde.aogaZ7-Ew0X-TB7xEkVpHw5@webmail.df.eu> <20210415172529.Horde.OwHJ_i8fKeLD9lkXiYmQbQ3@webmail.df.eu> Message-ID: <87pmyubxy7.fsf@iwagami.gniibe.org> Frank wrote: > Hi Werner, > > I assume you are busy with the 2.30 release (congratulations!) but you > have any more hints how to get more informations on my compile problem? Since Werner is busy, let me reply, to where I can understand. IIUC, GnuPG needs some fix for your environment (xlc on AIX). > I think AIX might work with __inline__ (? have not tried that): I think that xlc supports C99 standard. But unfortunately, it seems that it is used with an option of "-qlanglvl=extc89", which specifies C89 standard. Note that you need a compiler which supports C99 standard for "inline". I your log: > > source='t-keydb.c' object='t-keydb.o' libtool=no > DEPDIR=.deps depmode=xlc /opt/freeware/bin/bash ../build-aux/depcomp > cc -qlanglvl=extc89 -DHAVE_CONFIG_H -I. -I.. ^^^^^^^^^^^^^^^ This is the problem. I wonder where this option comes from. If it is from autoconf, you would need a fix like: diff --git a/configure.ac b/configure.ac index 215a6535f..2a50c5b73 100644 --- a/configure.ac +++ b/configure.ac @@ -638,7 +638,7 @@ AM_MISSING_PROG(AUTOHEADER, autoheader, $missing_dir) AM_MISSING_PROG(MAKEINFO, makeinfo, $missing_dir) AM_SILENT_RULES AC_PROG_AWK -AC_PROG_CC +AC_PROG_CC_C99 AC_PROG_CPP AM_PROG_CC_C_O if test "x$ac_cv_prog_cc_c89" = "xno" ; then And you need to regenerate the configure script, becoure "make". Or it is you who specified CC, you invoking make with CC="cc -qlanglvl=extc99" ... may just work. -- From bernhard at intevation.de Fri Apr 16 17:29:17 2021 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 16 Apr 2021 17:29:17 +0200 Subject: Public relations: GnuPG 2.3.0 status? In-Reply-To: <202104121240.25779.bernhard@intevation.de> References: <877dld87tf.fsf@wheatstone.g10code.de> <202104121240.25779.bernhard@intevation.de> Message-ID: <202104161729.24941.bernhard@intevation.de> Am Montag 12 April 2021 12:40:11 schrieb Bernhard Reiter: > My suggestion: > ?a) give it no label (thus implicitly assuming a regular release) > ?b) change the download webpage to remove the "(devel)" substring. Patch to remove missleading "(devel)" from downloads webpage for 2.3.0 release. -------------- next part -------------- A non-text attachment was scrubbed... Name: gnupgweb.diff Type: text/x-diff Size: 845 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From anon85786376 at protonmail.com Sun Apr 18 02:06:40 2021 From: anon85786376 at protonmail.com (anon85786376) Date: Sun, 18 Apr 2021 00:06:40 +0000 Subject: Imported secret subkey unusable "ssb#" Message-ID: >From an issue raised on Stack Exchange (https://security.stackexchange.com/questions/248320/how-to-properly-export-and-re-import-gpg-secret-key-and-all-its-subkeys) When a batch mode key is created with "Subkey-Type: ECC" and "Subkey-Curve: Ed25519", the key is generated without errors and appears to function normally. However, importing the secret keys will yield an unusable secret subkey: $ gpg --batch --gen-key < Key-Type: default > Subkey-Type: ECC > Subkey-Curve: Ed25519 > Name-Real: testkey > EOF gpg: key 4C95665DD06F8126 marked as ultimately trusted gpg: revocation certificate stored as '/home/me/.gnupg/openpgp-revocs.d/1CB8F79F656BCD71BF9A89694C95665DD06F8126.rev' $ gpg -K gpg: checking the trustdb gpg: marginals needed: 3? completes needed: 1? trust model: pgp gpg: depth: 0? valid:?? 2? signed:?? 0? trust: 0-, 0q, 0n, 0m, 0f, 2u /home/me/.gnupg/pubring.kbx ----------------------------- sec?? rsa3072 2021-04-17 [SC] ????? 1CB8F79F656BCD71BF9A89694C95665DD06F8126 uid?????????? [ultimate] testkey ssb?? ed25519 2021-04-17 [E] $ gpg -ao test --export-secret-keys 1CB8F79F656BCD71BF9A89694C95665DD06F8126 $ gpg --yes --delete-secret-and-public-keys 1CB8F79F656BCD71BF9A89694C95665DD06F8126 $ gpg --import test gpg: key 4C95665DD06F8126: public key "testkey" imported gpg: key 4C95665DD06F8126: secret key imported gpg: Total number processed: 1 gpg:?????????????? imported: 1 gpg:?????? secret keys read: 1 gpg:?? secret keys imported: 1 $ gpg -K /home/me/.gnupg/pubring.kbx ----------------------------- sec?? rsa3072 2021-04-17 [SC] ????? 1CB8F79F656BCD71BF9A89694C95665DD06F8126 uid?????????? [ unknown] testkey ssb#? ed25519 2021-04-17 [E] The imported secret subkey is unusable. Files can be encrypted, but decryption fails with "no secret key". This occurs on GnuPG 2.2.19 and GnuPG 2.2.27. From kloecker at kde.org Sun Apr 18 21:55:59 2021 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Sun, 18 Apr 2021 21:55:59 +0200 Subject: Imported secret subkey unusable "ssb#" In-Reply-To: References: Message-ID: <4250405.SEn6QrjCWz@breq> On Sonntag, 18. April 2021 02:06:40 CEST anon85786376 via Gnupg-users wrote: > When a batch mode key is created with "Subkey-Type: ECC" and "Subkey-Curve: > Ed25519", the key is generated without errors and appears to function > normally. However, importing the secret keys will yield an unusable secret > subkey: [...] > $ gpg -K > /home/me/.gnupg/pubring.kbx > ----------------------------- > sec rsa3072 2021-04-17 [SC] > 1CB8F79F656BCD71BF9A89694C95665DD06F8126 > uid [ unknown] testkey > ssb# ed25519 2021-04-17 [E] I could reproduce the problem. Note that the "#" next to the subkey indicates that the subkey is just a stub for a secret key. I noticed that after importing there are (as expected) two new files in ~/.gnupg/private-keys-v1.d, e.g. 82380E8EB005D76AE6A1E73FCDC82B374B8D9584.key 05E9DDE401B12A726DF0058FB4F62EACED979CC5.key The names of those files should correspond to the keygrips of the primary key and the subkey. This is true for the primary key, but the keygrip of the subkey does not match. $ gpg -K --with-keygrip FB489AAC37C42F19 sec rsa3072/FB489AAC37C42F19 2021-04-18 [SC] 92AB7959B2905BED251F522DFB489AAC37C42F19 Keygrip = 82380E8EB005D76AE6A1E73FCDC82B374B8D9584 uid [ unknown] testkey ssb# ed25519/2C45A3D965A1FEFE 2021-04-18 [E] Keygrip = B1838BACC3F53C98C675146D7E929AB285C6E49C This seems to be the problem. gpg looks for a file named B1838BACC3F53C98C675146D7E929AB285C6E49C.key which doesn't exist. Please submit a bug report at https://dev.gnupg.org Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: From kloecker at kde.org Mon Apr 19 11:02:14 2021 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Mon, 19 Apr 2021 11:02:14 +0200 Subject: Imported secret subkey unusable "ssb#" In-Reply-To: <4250405.SEn6QrjCWz@breq> References: <4250405.SEn6QrjCWz@breq> Message-ID: <1861900.6uF5RIoebP@breq> On Sonntag, 18. April 2021 21:55:59 CEST Ingo Kl?cker wrote: > On Sonntag, 18. April 2021 02:06:40 CEST anon85786376 via Gnupg-users wrote: > > When a batch mode key is created with "Subkey-Type: ECC" and > > "Subkey-Curve: > > Ed25519", the key is generated without errors and appears to function > > normally. However, importing the secret keys will yield an unusable secret > > > subkey: > [...] > > > $ gpg -K > > /home/me/.gnupg/pubring.kbx > > ----------------------------- > > sec rsa3072 2021-04-17 [SC] > > > > 1CB8F79F656BCD71BF9A89694C95665DD06F8126 > > > > uid [ unknown] testkey > > ssb# ed25519 2021-04-17 [E] > > I could reproduce the problem. It turns out that --gen-key allows creating invalid keys. The problem is that ed25519 keys cannot be used for encryption. You need to create a key with an cv25519 encryption subkey, i.e. $ gpg --batch --gen-key < From wk at gnupg.org Tue Apr 20 15:27:47 2021 From: wk at gnupg.org (Werner Koch) Date: Tue, 20 Apr 2021 15:27:47 +0200 Subject: [Announce] GnuPG 2.3.1 released Message-ID: <87im4hjdbg.fsf@wheatstone.g10code.de> Hello! We are pleased to announce the availability of a new GnuPG release: version 2.3.1. This is the second release in the new 2.3 series which fixes a couple of bugs and adds a few new things. See below for details. Although some bugs might linger in the 2.3 versions, they are intended to replace the 2.2 series. 2.3 may even be used for production purposes if either the risk of minor regressions is acceptable or the new features are important. What is 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. Three different versions of GnuPG are actively maintained: - This version (2.3) is the latest development with a lot of new features. This announcement is about the first release of this version. - Version 2.2 is our LTS (long term support) version and guaranteed to be maintained at least until the end of 2024. See https://gnupg.org/download/index.html#end-of-life - Version 1.4 is maintained to allow decryption of very old data which is, for security reasons, not anymore possible with other GnuPG versions. Noteworthy changes in version 2.3.1 =================================== * The new configuration file common.conf is now used to enable the use of the key database daemon with "use-keyboxd". Using this option in gpg.conf and gpgsm.conf is supported for a transitional period. See doc/example/common.conf for more. * gpg: Force version 5 key creation for ed448 and cv448 algorithms. * gpg: By default do not use the self-sigs-only option when importing from an LDAP keyserver. [#5387] * gpg: Lookup a missing public key of the active card via LDAP. [d7e707170f] * gpgsm: New command --show-certs. [51419d6341] * scd: Fix CCID driver for SCM SPR332/SPR532. [#5297] * scd: Further improvements for PKCS#15 cards. * Fix build problems on Fedora. [#5389] * Fix build problems on macOS. [#5400] * New configure option --with-tss to allow the selection of the TSS library. [93c88d0af3] Release-info: https://dev.gnupg.org/T5386 Getting the Software ==================== Please follow the instructions found at or read on: GnuPG 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.3.1.tar.bz2 (7392k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.3.1.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.3.1_20210420.exe (4570k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.3.1_20210420.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 featuring this version of GnuPG will be released soon. In the meantime it is possible to install this GnuPG version on top of Gpg4win 3.1.15. 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.3.1.tar.bz2 you would use this command: gpg --verify gnupg-2.3.1.tar.bz2.sig gnupg-2.3.1.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.3.1.tar.bz2, you run the command like this: sha1sum gnupg-2.3.1.tar.bz2 and check that the output matches the next line: a8f66ba4f7dcb2e7322aef786f942ce5ccca6f14 gnupg-2.3.1.tar.bz2 8e81d5592b0f3c88c3b5c9928ec4bc50e811357b gnupg-w32-2.3.1_20210420.tar.xz af13b1620c234dd6124531ad2698827caaaa6287 gnupg-w32-2.3.1_20210420.exe Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese (traditional and simplified), Czech, French, German, Italian, Japanese, Norwegian, Polish, Russian, and Ukrainian being almost completely translated. Documentation and Support ========================= 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 the 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/T5405 for updated information. Please consult the archive of the gnupg-users mailing list before reporting a bug: https://gnupg.org/documentation/mailing-lists.html. We suggest to send bug reports for a new release to this list in favor of filing a bug at https://bugs.gnupg.org. If you need commercial support go to https://gnupg.com or https://gnupg.org/service.html. If you are a developer and you need a certain feature for your project, please do not hesitate to bring it to the gnupg-devel mailing list for discussion. Thanks ====== Since 2001 maintenance and development of GnuPG is done by g10 Code GmbH and still mostly financed by donations. Three full-time employed developers as well as two contractors exclusively work on GnuPG and closely related software like Libgcrypt, GPGME and Gpg4win. We like to thank all the nice people who are helping the GnuPG project, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, or answering questions on the mailing lists. The financial support of the governmental CERT of Luxembourg (GOVCERT.LU) allowed us to develop new and improved features for smartcards (Yubikey, PIV and Scute) as well as various usability features. Thanks. Many thanks also to all other financial supporters, both corporate and individuals. Without you it would not be possible to keep GnuPG in a good and secure shape and to address all the small and larger requests made by our users. 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: ed25519 2020-08-24 [expires: 2030-06-30] Key fingerprint = 6DAA 6E64 A76D 2840 571B 4902 5288 97B8 2640 3ADA Werner Koch (dist signing 2020) 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) rsa2048 2011-01-12 [expires: 2021-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) The keys are available at https://gnupg.org/signature_key.html and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. -- "If privacy is outlawed, only outlaws will have privacy." - PRZ 1991 -------------- 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 shridhar_mysore at hotmail.com Mon Apr 19 23:49:56 2021 From: shridhar_mysore at hotmail.com (Shridhar Mysore) Date: Mon, 19 Apr 2021 21:49:56 +0000 Subject: After upgrading to gpg4win 3.3.15 Kleopatra fails to come up Message-ID: Hello, I have an existing gpg4win 3.1.14 install which I want to upgrade to gpg4win 3.1.15. I tried to install gpg4win 3.1.15 over the existing gpgwin 3.1.14. The installation completed successfully and [GnuPG] and [Gpg4Win] folders reflected the expected versions as shown below : gnupg 2.2.27 gpg4win 3.1.15 Also I could run the gpg --list-keys to see the keys. And I could use gpg to encrypt/decrypt using the existing keys. However when I tried to start Kleopatra from my desktop it didn't come up ! It gave me an error message window titled "Running as Administrator" with the following message : <<<< Kleopatra cannot be run as adminstrator without breaking file permissions in the GnuPG data folder. To manage keys for others please manage them as a normal user and copy the 'AppData\Roaming\gnupg' directory with proper permissions. >>>> Found this link https://www.reddit.com/r/GnuPG/comments/lelzjc/kleopatra_error_how_to_fix_it/ as per which there doesn't seem to be any resolution here for gpg4win 3.1.15 ! Kleopatra error, how to fix it? : GnuPG - reddit I am looking for a key server that I can 1. Self host for only keys for me and my peers 2. is a automated (or easily manual) set up for linux (20.04/18.04) and 3. is not hard to import SSL/TLS. www.reddit.com We switched to gpg4win 3.1.15 in order to avail the security improvements, so going back to gpg4win 3.1.14 would be going backwards. Appreciate any help in how to resolve this. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirelagin at gmail.com Fri Apr 23 21:58:37 2021 From: kirelagin at gmail.com (Kirill Elagin) Date: Fri, 23 Apr 2021 15:58:37 -0400 Subject: =?UTF-8?Q?Can=E2=80=99t_set_new_PIN_using_Reset_Code?= Message-ID: Hello, Today gnupg suddenly refused to accept the PIN code of my YubiKey and it got blocked. I am not exactly sure what happened, but it does not matter now anyway. I am trying to unblock the PIN using a Reset Code. ``` $ gpg --edit-card Reader ...........: Yubico YubiKey FIDO CCID 00 00 Application ID ...: D2760001240103040006117659560000 Application type .: OpenPGP Version ..........: 3.4 Manufacturer .....: Yubico Serial number ....: 11765956 Name of cardholder: Kirill Elagin Language prefs ...: en Salutation .......: URL of public key : https://bruna.kir.elagin.me/kirelagin.asc Login data .......: kirelagin Signature PIN ....: not forced Key attributes ...: rsa2048 rsa2048 rsa2048 Max. PIN lengths .: 127 127 127 PIN retry counter : 0 3 0 Signature counter : 3 KDF setting ......: on Signature key ....: CC5E B1EF E671 C418 33CC 318B FA66 ABF3 CFA3 569C created ....: 2021-01-27 16:37:47 keygrip ....: AD296DDA5EB86005A83ABCCC57046D9E64007C10 Encryption key....: 047A 7B2F B0E9 6F07 F9C2 16DC B3D9 F87D 907D C8B1 created ....: 2021-01-27 16:38:41 keygrip ....: B0960250674C237FF7D7979C8871684392B84F9C Authentication key: 8039 572F A015 0862 CB26 7A65 6D74 9968 B8E9 D1FE created ....: 2021-01-27 16:39:33 keygrip ....: C9CAE2108556320815105E1D528B62D081965835 General key info..: sub rsa2048/FA66ABF3CFA3569C 2021-01-27 Kirill Elagin sec> rsa4096/90D516249B728BE6 created: 2017-11-30 expires: never card-no: 0006 05764872 ssb> rsa2048/FA66ABF3CFA3569C created: 2021-01-27 expires: 2022-01-01 card-no: 0006 11765956 ssb> rsa2048/B3D9F87D907DC8B1 created: 2021-01-27 expires: 2022-01-01 card-no: 0006 11765956 ssb> rsa2048/6D749968B8E9D1FE created: 2021-01-27 expires: 2022-01-01 card-no: 0006 11765956 ssb> rsa4096/85D128E1B30E1931 created: 2017-11-30 expires: never card-no: 0006 05764872 ssb> rsa4096/435BC889600C52F1 created: 2017-11-30 expires: never card-no: 0006 05764872 gpg/card> unblock gpg: OpenPGP card no. D2760001240103040006117659560000 detected PIN changed. gpg/card> ``` It says that the PIN was changed, however when I try to use the card with the new PIN, it keeps saying that it?s wrong. Note that the admin pin is blocked (which, ugh, is a different story ? I got it blocked months ago during the initial setup and I was so tired of that process that I decided not to start over). Also note that the first and the second retry counters are different (I have no idea why; I always assumed that gnupg was supposed to keep them in sync). And also note that KDF is enabled (which, I think, might be contributing to the issue ? all my problems with e.g. the admin PIN getting blocked started after I enabled KDF). I?m pretty sure that at this point the easiest option is just to wipe the card and start over, but, I thought, I would still give it a try, so I?m looking for tips on how to debug this issue. And has anyone seen anything like that before? This all started with gnupg 2.2.23, I have now upgraded to 2.2.27 and it?s still the same. Cheers, Kirill From mstep at podiuminternational.org Sat Apr 24 12:11:38 2021 From: mstep at podiuminternational.org (Marek Stepanek) Date: Sat, 24 Apr 2021 12:11:38 +0200 Subject: All my Passwords are lost Message-ID: <727D2DBB-89A8-45BB-8EBA-8635C3DE95A3@podiuminternational.org> Hello all, Perhaps somebody out there could be of some help. I use since 10 years now GnuPG in my Shell to encrypt my Passwords. I only open this file, from time to time to look up some pws which I need for banking, crypto or to check, which of my many mails I used on which webpage. After use I remove the pw.txt file immediately with my shell. All what is left is the file pw.txt.gpg. Now after such a long time, something strange happened: this file is apparently encrypted with a foreign private key, which I never have had: gpg: WARNING: no command supplied. Trying to guess what you mean ... gpg: encrypted with 2048-bit ELG key, ID 1F1EF0849B5C6D50, created 2019-06-30 "PAUSE Batch Signing Key 2021 " gpg: decryption failed: No secret key I would be *VERY* grateful for any help in: 1. Recover the original file pw.tx. This file I remove in my shell and for me, it seems impossible to recover this file. Right? And I am sure: I have even a SSD on my 2018 MB Pro. Which makes it even much more improbable, to recover the decrypted pw-file. 2. If the file is mistakenly encrypted with wrong headers from perl.org , perhaps it would be possible to change the headers to my private gpg key? I see in the pw.txt.gpg file <85> ? <8c> ? <91> which could be headers. If I replace some of them with a backup - two month old from a still working bu_pw.txt.pgg file? 3. As a last resort: is the private key of pause at pause.perl.org still in use? Would it possible to ? ok ok private key ? ok ok not possible ? I understand. Some ideas? Thank you for your insight Marek Stepanek -------------- next part -------------- An HTML attachment was scrubbed... URL: From cjac at colliertech.org Sun Apr 25 00:19:07 2021 From: cjac at colliertech.org (C.J. Collier) Date: Sat, 24 Apr 2021 15:19:07 -0700 Subject: All my Passwords are lost In-Reply-To: <727D2DBB-89A8-45BB-8EBA-8635C3DE95A3@podiuminternational.org> References: <727D2DBB-89A8-45BB-8EBA-8635C3DE95A3@podiuminternational.org> Message-ID: Did you encrypt to yourself as well as to the pause key for some reason? Are you a pause admin? It sounds like you encrypted to both yourself and pause at pause.perl.org for some reason. If that's the case and you cannot find your private key, you could maybe ask a pause admin to decrypt and re-encrypt to a key that you own, sending you back the encrypted file. But you'd need to trust the pause admin with your passwords. I probably know one that I would trust with this task, but it would put a bit of liability risk on them as well... On Sat, Apr 24, 2021, 15:00 Marek Stepanek wrote: > Hello all, > > Perhaps somebody out there could be of some help. I use since 10 years now > GnuPG in my Shell to encrypt my Passwords. I only open this file, from time > to time to look up some pws which I need for banking, crypto or to check, > which of my many mails I used on which webpage. > > After use I remove the pw.txt file immediately with my shell. All what is > left is the file pw.txt.gpg. > > Now after such a long time, something strange happened: this file is > apparently encrypted with a foreign private key, which I never have had: > > gpg: WARNING: no command supplied. Trying to guess what you mean ... > gpg: encrypted with 2048-bit ELG key, ID 1F1EF0849B5C6D50, created > 2019-06-30 > "PAUSE Batch Signing Key 2021 " > gpg: decryption failed: No secret key > > I would be *VERY* grateful for any help in: > > 1. Recover the original file pw.tx. This file I remove in my shell and for > me, it seems impossible to recover this file. Right? And I am sure: I have > even a SSD on my 2018 MB Pro. Which makes it even much more improbable, to > recover the decrypted pw-file. > > 2. If the file is mistakenly encrypted with wrong headers from perl.org, > perhaps it would be possible to change the headers to my private gpg key? I > see in the pw.txt.gpg file <85> ? <8c> ? <91> which could be headers. If I > replace some of them with a backup - two month old from a still working > bu_pw.txt.pgg file? > > 3. As a last resort: is the private key of pause at pause.perl.org still in > use? Would it possible to ? ok ok private key ? ok ok not possible ? I > understand. > > Some ideas? Thank you for your insight > > > Marek Stepanek > _______________________________________________ > 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 plr.vincent at gmail.com Sun Apr 25 10:41:06 2021 From: plr.vincent at gmail.com (Vincent Pelletier) Date: Sun, 25 Apr 2021 08:41:06 +0000 Subject: All my Passwords are lost In-Reply-To: References: <727D2DBB-89A8-45BB-8EBA-8635C3DE95A3@podiuminternational.org> Message-ID: <20210425084106.0f187786@gmail.com> On Sat, 24 Apr 2021 15:19:07 -0700, "C.J. Collier" wrote: > you could maybe ask a pause admin to decrypt and > re-encrypt to a key that you own, sending you back the encrypted file. Two ideas from a gpg-internal *UN*aware point of view: - I assume gpg file encryption works by generating a random symmetric cipher key, encrypting the file with this symmetric cipher, and only encrypting the symmetric cipher's key with the asymmetric cipher public key. If so, then the encrypted symmetric key could in theory (...again, I do not know enough of gnupg internals) be extracted and be the only thing sent for decryption and sent back deciphered. Of course, it means that if the file was leaked encrypted, then this deciphered key intercepted, then the file is completely leaked. - Is the asymmetric algorithm transitive ? If it is, then again starting from an extracted encrypted key, it could be encrypted again with the good public key, then sent for decryption. The key received back would still be encrypted by the good public key. It can then finally be deciphered, allowing the symmetric cipher to decipher the data. This would solve the plain-text vulnerability of the previous point. I believe (again, not an expert) decryption and signature use different parameters in gpg, so from the pause admin point of view they should not be worried about inadvertently signing a hash, but actually deciphering a symmetric key (which can otherwise be a concern). -- Vincent Pelletier GPG fingerprint 983A E8B7 3B91 1598 7A92 3845 CAC9 3691 4257 B0C1 From csalemi at hotmail.com Sun Apr 25 15:11:56 2021 From: csalemi at hotmail.com (Charlie Salemi) Date: Sun, 25 Apr 2021 13:11:56 +0000 Subject: Random_seed File Locking on NFS File System Across Networks/Domains Hangs Message-ID: For internal encrypting/decrypting operations we want to use a NFS location for the gpg keystore available to two (possibly more) user IDs across many servers. It was designed this way so we did not have to share the keystore to each server and updates to the keystore could be done in one location, not on several (100+) servers. When the servers and the NAS appliance are on the same network and domain, there is no issue calling the fcntl system call to lock the random_seed file. However, we are moving the servers to a new network and a new domain but not all at once. This is where the issue showed up. On servers already moved to the new network/domain any fctnl on the randon_seed file hangs. Servers still in the same network/domain as the NAS appliance work as before (no hang). We believe this is a firewall issue and are investigating a solution. However, this leads to the following questions: what functionality does the random_seed file provide? We know it can be ignored with the --no-random-seed-file option, but there is the possibility of doing many encrypting/decrypting operations simultaneously from both user IDs executing on different servers. Would ignoring the file locking on the random_seed file with the --no-random-seed-file option cause issues with independent processes accessing the same keystore at the same time on different servers? If so, what are those issues, and can they be avoided/worked around? -------------- next part -------------- An HTML attachment was scrubbed... URL: From xylene2016 at gmail.com Sun Apr 25 22:41:32 2021 From: xylene2016 at gmail.com (William Holmes) Date: Sun, 25 Apr 2021 16:41:32 -0400 Subject: gpg: keydb_search failed: Broken pipe Message-ID: Hi, I just found an issue today. There's 2 keys, TestUser1 and TestUser2. TestUser1 was without a passphrase. TestUser2 was passphrase-protected, and used Curve 448 for encryption. I encrypted the file with '--hidden-recipient'. After decryption failed, gpg-agent was killed. Here's the output: --------------------------------------------------------------------------------- # gpg2 --version gpg (GnuPG) 2.3.1 libgcrypt 1.9.3 # gpg2 -k /root/.gnupg/pubring.kbx ------------------------ pub ed25519/0xFB3157F958F70A96 2021-04-25 [SC] 55532181F95968D1D72E1E20FB3157F958F70A96 uid [ultimate] TestUser1 sub cv25519/0x2EE9DBD136764E1E 2021-04-25 [E] pub ed25519/0x19EC312D820A2F6E 2021-04-25 [C] BF4E1C04CD57D9F11CFE5B0A19EC312D820A2F6E uid [ultimate] TestUser2 sub ed25519/0x92588FA653AED764 2021-04-25 [S] sub cv448/0xB36D6CA2989293FF 2021-04-25 [E] sub ed25519/0x6C12D278DF8E2792 2021-04-25 [A] # gpg2 -a -R 0xB36D6CA2989293FF! -e 1.txt # gpg2 -d 1.txt.asc gpg: encrypted with ECDH key, ID 0x0000000000000000 gpg: anonymous recipient; trying secret key 0x2EE9DBD136764E1E ... gpg: keydb_search failed: Broken pipe gpg: public key decryption failed: End of file gpg: decryption failed: End of file --------------------------------------------------------------------------------- - William -------------- next part -------------- An HTML attachment was scrubbed... URL: From angel at pgp.16bits.net Mon Apr 26 01:41:52 2021 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Mon, 26 Apr 2021 01:41:52 +0200 Subject: All my Passwords are lost In-Reply-To: <20210425084106.0f187786@gmail.com> References: <727D2DBB-89A8-45BB-8EBA-8635C3DE95A3@podiuminternational.org> <20210425084106.0f187786@gmail.com> Message-ID: On 2021-04-25 at 08:41 +0000, Vincent Pelletier wrote: > On Sat, 24 Apr 2021 15:19:07 -0700, "C.J. Collier" wrote: > > you could maybe ask a pause admin to decrypt and > > re-encrypt to a key that you own, sending you back the encrypted file. > > Two ideas from a gpg-internal *UN*aware point of view: > - I assume gpg file encryption works by generating a random symmetric > cipher key, encrypting the file with this symmetric cipher, and > only encrypting the symmetric cipher's key with the asymmetric cipher > public key. > If so, then the encrypted symmetric key could in theory (...again, I > do not know enough of gnupg internals) be extracted and be the only > thing sent for decryption and sent back deciphered. Yes, passing that key is even supported out-of-the box. See the options: --show-session-key --override-session-key The "encryption header" could be extracted with gpgsplit. > I believe (again, not an expert) decryption and signature use > different parameters in gpg, so from the pause admin point of view > they should not be worried about inadvertently signing a hash, but > actually deciphering a symmetric key (which can otherwise be a > concern). Yes. Their concern should be that maybe someone sent them a secret message and is now trying to social engineer them with a story of pw.txt. Marek, didn't you make backups of this encrypted file? How did you plan for the event that your hard disk broke? Also, for the future, you may be interested in "gpg -d < pw.txt.gpg", as well as pass (https://www.passwordstore.org/) Cheers From angel at pgp.16bits.net Mon Apr 26 01:50:44 2021 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Mon, 26 Apr 2021 01:50:44 +0200 Subject: Random_seed File Locking on NFS File System Across Networks/Domains Hangs In-Reply-To: References: Message-ID: <4dcb5be9542747f9c8a914ae5d0bc289b570e148.camel@16bits.net> On 2021-04-25 at 13:11 +0000, Charlie Salemi via Gnupg-users wrote: > Would ignoring the file locking on the random_seed file with the -- > no-random-seed-file option cause issues with independent processes > accessing the same keystore at the same time on different servers? > If so, what are those issues, and can they be avoided/worked around? No. Not using the random seed files means just, not using that file. It isn't used for synchronization. Although, you could face the same issue when they try to lock other files. How are you handling the changes to that keystore? Are those 100 servers only reading the keys, or are they also *modifying* it (e.g. importing new keys) ? From kirelagin at gmail.com Mon Apr 26 04:07:52 2021 From: kirelagin at gmail.com (Kirill Elagin) Date: Sun, 25 Apr 2021 22:07:52 -0400 Subject: =?UTF-8?Q?Re=3A_Can=E2=80=99t_set_new_PIN_using_Reset_Code?= In-Reply-To: References: Message-ID: For anyone interested, I was able to get my card back in order. I am 85% confident that there is a bug in GnuPG that causes it to compute the KDF in the reset command incorrectly. Here is what I did. Step 1 was to figure out how to tap into the communication with the card. After a bit of searching I found out that `scdaemon` is responsible for communicating with the card. I ended up writing: ``` debug-level 8 debug-ccid-driver debug-ccid-driver log-file /tmp/scdaemon.log ``` into `$HOME/.gnupg/scdaemon.conf`. I did not really try any other options, my understanding is that `debug-ccid-driver` (twice!) is what makes it dump raw APDUs, but I have also thrown `debug-level` in just for good measure. Then I did `gpg --edit-card` and, as described in my previous email, used the `unblock` command to set PIN to 123456789. Immediately after that I used the `passwd` command entering both the old and the new PIN as 123456789. Then I inspected the log. The first APDU of interest is RESET RETRY COUNTER (00 2C ...). I took notice of the last 32 bytes, which are supposed to be the salted hash of the PIN. I kinda inspected to find the unhashed PIN there, but, not, the bytes looked pretty arbitrary. The second APDU of interest is CHANGE REFERENCE DATA (00 24 ...). Its payload is old hash followed by new hash. In my case they both were the same, but they both were different from what I found in the previous APDU. I simply took the first APDU and replaced the hash of the new PIN with the correct one from the second APDU. I sent it manually using `gpg-connect-agent --hex`, and ? tada! ? my card works again. I haven?t looked at the code yet, but my theory is that either a wrong salt is used or the hash calculation is incorrect in some other way. Cheers, Kirill On Fri, Apr 23, 2021 at 3:58 PM Kirill Elagin wrote: > > Hello, > > Today gnupg suddenly refused to accept the PIN code of my YubiKey and > it got blocked. I am not exactly sure what happened, but it does not > matter now anyway. > > I am trying to unblock the PIN using a Reset Code. > > ``` > $ gpg --edit-card > > Reader ...........: Yubico YubiKey FIDO CCID 00 00 > Application ID ...: D2760001240103040006117659560000 > Application type .: OpenPGP > Version ..........: 3.4 > Manufacturer .....: Yubico > Serial number ....: 11765956 > Name of cardholder: Kirill Elagin > Language prefs ...: en > Salutation .......: > URL of public key : https://bruna.kir.elagin.me/kirelagin.asc > Login data .......: kirelagin > Signature PIN ....: not forced > Key attributes ...: rsa2048 rsa2048 rsa2048 > Max. PIN lengths .: 127 127 127 > PIN retry counter : 0 3 0 > Signature counter : 3 > KDF setting ......: on > Signature key ....: CC5E B1EF E671 C418 33CC 318B FA66 ABF3 CFA3 569C > created ....: 2021-01-27 16:37:47 > keygrip ....: AD296DDA5EB86005A83ABCCC57046D9E64007C10 > Encryption key....: 047A 7B2F B0E9 6F07 F9C2 16DC B3D9 F87D 907D C8B1 > created ....: 2021-01-27 16:38:41 > keygrip ....: B0960250674C237FF7D7979C8871684392B84F9C > Authentication key: 8039 572F A015 0862 CB26 7A65 6D74 9968 B8E9 D1FE > created ....: 2021-01-27 16:39:33 > keygrip ....: C9CAE2108556320815105E1D528B62D081965835 > General key info..: > sub rsa2048/FA66ABF3CFA3569C 2021-01-27 Kirill Elagin > sec> rsa4096/90D516249B728BE6 created: 2017-11-30 expires: never > card-no: 0006 05764872 > ssb> rsa2048/FA66ABF3CFA3569C created: 2021-01-27 expires: 2022-01-01 > card-no: 0006 11765956 > ssb> rsa2048/B3D9F87D907DC8B1 created: 2021-01-27 expires: 2022-01-01 > card-no: 0006 11765956 > ssb> rsa2048/6D749968B8E9D1FE created: 2021-01-27 expires: 2022-01-01 > card-no: 0006 11765956 > ssb> rsa4096/85D128E1B30E1931 created: 2017-11-30 expires: never > card-no: 0006 05764872 > ssb> rsa4096/435BC889600C52F1 created: 2017-11-30 expires: never > card-no: 0006 05764872 > > gpg/card> unblock > gpg: OpenPGP card no. D2760001240103040006117659560000 detected > PIN changed. > > gpg/card> > ``` > > It says that the PIN was changed, however when I try to use the card > with the new PIN, it keeps saying that it?s wrong. > > Note that the admin pin is blocked (which, ugh, is a different story ? > I got it blocked months ago during the initial setup and I was so > tired of that process that I decided not to start over). Also note > that the first and the second retry counters are different (I have no > idea why; I always assumed that gnupg was supposed to keep them in > sync). And also note that KDF is enabled (which, I think, might be > contributing to the issue ? all my problems with e.g. the admin PIN > getting blocked started after I enabled KDF). > > I?m pretty sure that at this point the easiest option is just to wipe > the card and start over, but, I thought, I would still give it a try, > so I?m looking for tips on how to debug this issue. And has anyone > seen anything like that before? > > This all started with gnupg 2.2.23, I have now upgraded to 2.2.27 and > it?s still the same. > > Cheers, > Kirill From csalemi at hotmail.com Mon Apr 26 03:12:14 2021 From: csalemi at hotmail.com (Charlie Salemi) Date: Mon, 26 Apr 2021 01:12:14 +0000 Subject: Random_seed File Locking on NFS File System Across Networks/Domains Hangs In-Reply-To: <4dcb5be9542747f9c8a914ae5d0bc289b570e148.camel@16bits.net> References: , <4dcb5be9542747f9c8a914ae5d0bc289b570e148.camel@16bits.net> Message-ID: The 100+ servers only read the key. Each user ID has a sub-directory under a generic location so there are no warnings printed by gpg when using the key to decrypt files. Any operation that encrypts files imports the global key locally or uses User IDs that have the same key locally and uses it for the encrypting. Again, the concern using the global keystore on the NAS is that it doesn?t cause issues if multiple servers are decrypting different files at the same time using the same key without using the random_seed file. Using the ?no-random-seed-file would eliminate the file locking issue, I believe. ________________________________ From: Gnupg-users on behalf of ?ngel Sent: Sunday, April 25, 2021 7:51 PM To: gnupg-users at gnupg.org Subject: Re: Random_seed File Locking on NFS File System Across Networks/Domains Hangs On 2021-04-25 at 13:11 +0000, Charlie Salemi via Gnupg-users wrote: > Would ignoring the file locking on the random_seed file with the -- > no-random-seed-file option cause issues with independent processes > accessing the same keystore at the same time on different servers? > If so, what are those issues, and can they be avoided/worked around? No. Not using the random seed files means just, not using that file. It isn't used for synchronization. Although, you could face the same issue when they try to lock other files. How are you handling the changes to that keystore? Are those 100 servers only reading the keys, or are they also *modifying* it (e.g. importing new keys) ? _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.gnupg.org%2Fmailman%2Flistinfo%2Fgnupg-users&data=04%7C01%7C%7C9d89eb24058444eb94e008d908450ce8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637549914956463495%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=SwbfvbDf97w%2F%2FOPExS57YixLJgD%2B3fdfKT94OgtXIvM%3D&reserved=0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From skquinn at rushpost.com Mon Apr 26 06:12:34 2021 From: skquinn at rushpost.com (Shawn K. Quinn) Date: Sun, 25 Apr 2021 23:12:34 -0500 Subject: Random_seed File Locking on NFS File System Across Networks/Domains Hangs In-Reply-To: References: Message-ID: <5dcacab4-7c99-d092-6560-6aac79920e2c@rushpost.com> On 4/25/21 08:11, Charlie Salemi via Gnupg-users wrote: > However, this leads to the following questions:? what functionality does > the random_seed file provide? Per the documentation I have here: '~/.gnupg/random_seed' A file used to preserve the state of the internal random pool. Now, for me, that begs the question: what does the internal random pool offer that simply using /dev/random (or better yet a quality HWRNG) does not? -- Shawn K. Quinn http://www.rantroulette.com http://www.skqrecordquest.com From plr.vincent at gmail.com Mon Apr 26 13:12:32 2021 From: plr.vincent at gmail.com (Vincent Pelletier) Date: Mon, 26 Apr 2021 11:12:32 +0000 Subject: All my Passwords are lost In-Reply-To: References: <727D2DBB-89A8-45BB-8EBA-8635C3DE95A3@podiuminternational.org> <20210425084106.0f187786@gmail.com> Message-ID: <20210426111232.071f12c5@gmail.com> Hello Marek, On Sun, 25 Apr 2021 17:31:53 +0200, Marek Stepanek wrote: > I am unsure how GnuPG could pick up the wrong key, which does not exist in my key deposit. My guess is, that it is encrypted anyway with my private key Beware of a possible misunderstanding here: encryption is done with the *public* key. It is decryption which requires the private key. So you can easily encrypt something with any of the (possibly many) public keys from your key ring. > Thank you Vincent for your detailed answer, Welcome ! > which is way over my head. Don't worry, I was tossing some ideas to maybe save you from disclosing your entire file to someone else (by only exchanging the encrypted session key rather than the whole file). But I 100% deffer to anyone knowledgeable about gnupg itself for whether anything I suggest is actually possible, and how to do it. > I really should look into the internals of file encryption one day ? Besides on-line sources like wikipedia or youtube (computerphile channel has several crypto-related videos), I found the following book to be especially enlightening (...from a crypto-unrelated developer perspective anyway): https://www.schneier.com/books/cryptography-engineering/ Regards, -- Vincent Pelletier GPG fingerprint 983A E8B7 3B91 1598 7A92 3845 CAC9 3691 4257 B0C1 From mstep at podiuminternational.org Sun Apr 25 17:31:53 2021 From: mstep at podiuminternational.org (Marek Stepanek) Date: Sun, 25 Apr 2021 17:31:53 +0200 Subject: All my Passwords are lost In-Reply-To: <20210425084106.0f187786@gmail.com> References: <727D2DBB-89A8-45BB-8EBA-8635C3DE95A3@podiuminternational.org> <20210425084106.0f187786@gmail.com> Message-ID: Hello all, Thank you for your answers. Hope I respond to your questions: I encrypt in my Shell as follows - I am doing it just now with a Backup File on my desktop: $ gpg bu_pw_new.txt.gpg gpg: WARNING: no command supplied. Trying to guess what you mean ... gpg: encrypted with 2048-bit ELG key, ID F5FF48588C144291, created 2010-08-05 "Marek Stepanek ? If I change something with VIM I make: $ rm bu_pw_new.txt.gpg $ gpg -e bu_pw_new.txt You did not specify a user ID. (you may use "-r") Current recipients: Enter the user ID. End with an empty line: marek gpg: F5FF48588C144291: There is no assurance this key belongs to the named user sub elg2048/F5FF48588C144291 2010-08-05 Marek Stepanek Primary key fingerprint: B607 17A3 A754 8564 B209 6A9B D442 9D47 8F5D ABEF Subkey fingerprint: 4CE5 48A1 9A35 DCD7 D18D 183B F5FF 4858 8C14 4291 It is NOT certain that the key belongs to the person named in the user ID. If you *really* know what you are doing, you may answer the next question with yes. Use this key anyway? (y/N) y Current recipients: elg2048/F5FF48588C144291 2010-08-05 "Marek Stepanek " Enter the user ID. End with an empty line: And here it is encrypted again. Then I remove the raw text file: $ rm bu_pw_new.txt I am unsure how GnuPG could pick up the wrong key, which does not exist in my key deposit. My guess is, that it is encrypted anyway with my private key, but the headers are mangled up??? For that reason my question was: may I replace some headers from my backup file ( two month old! ) into the spoiled one? But until where? For that reason I was posting here, to ask some of the developers how to achieve it right. There are plenty of those <85> ? <8c> ? <91> - cutting the binary file in some pieces (?) Thank you Vincent for your detailed answer, which is way over my head. I really should look into the internals of file encryption one day ? Is pause at pause.perl.org listening? Is your PGP key still in use? Best greetings to all marek > On 25. Apr 2021, at 10:41, Vincent Pelletier wrote: > > On Sat, 24 Apr 2021 15:19:07 -0700, "C.J. Collier" wrote: >> you could maybe ask a pause admin to decrypt and >> re-encrypt to a key that you own, sending you back the encrypted file. > > Two ideas from a gpg-internal *UN*aware point of view: > - I assume gpg file encryption works by generating a random symmetric > cipher key, encrypting the file with this symmetric cipher, and > only encrypting the symmetric cipher's key with the asymmetric cipher > public key. > If so, then the encrypted symmetric key could in theory (...again, I > do not know enough of gnupg internals) be extracted and be the only > thing sent for decryption and sent back deciphered. > Of course, it means that if the file was leaked encrypted, then this > deciphered key intercepted, then the file is completely leaked. > - Is the asymmetric algorithm transitive ? If it is, then again > starting from an extracted encrypted key, it could be encrypted again > with the good public key, then sent for decryption. The key received > back would still be encrypted by the good public key. It can then > finally be deciphered, allowing the symmetric cipher to decipher the data. > This would solve the plain-text vulnerability of the previous point. > > I believe (again, not an expert) decryption and signature use different > parameters in gpg, so from the pause admin point of view they should > not be worried about inadvertently signing a hash, but actually > deciphering a symmetric key (which can otherwise be a concern). > -- > Vincent Pelletier > GPG fingerprint 983A E8B7 3B91 1598 7A92 3845 CAC9 3691 4257 B0C1 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Mon Apr 26 18:01:07 2021 From: wk at gnupg.org (Werner Koch) Date: Mon, 26 Apr 2021 18:01:07 +0200 Subject: =?utf-8?Q?Can=E2=80=99t?= set new PIN using Reset Code In-Reply-To: (Kirill Elagin via Gnupg-users's message of "Sun, 25 Apr 2021 22:07:52 -0400") References: Message-ID: <87a6plghmk.fsf@wheatstone.g10code.de> On Sun, 25 Apr 2021 22:07, Kirill Elagin said: > into `$HOME/.gnupg/scdaemon.conf`. I did not really try any other > options, my understanding is that `debug-ccid-driver` (twice!) is what Nope, that is todebug the low-level ccid driver. The best way to debug the APDUs is verbose debug ipc,cardio instead of the legacy debug-level cruft. "ipc" is just a helper to see the IPC I/O. > I haven?t looked at the code yet, but my theory is that either a wrong > salt is used or the hash calculation is incorrect in some other way. You may want to open a bug report at dev.gnupg.org so that we don't forget about 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 Apr 26 18:07:10 2021 From: wk at gnupg.org (Werner Koch) Date: Mon, 26 Apr 2021 18:07:10 +0200 Subject: Random_seed File Locking on NFS File System Across Networks/Domains Hangs In-Reply-To: <5dcacab4-7c99-d092-6560-6aac79920e2c@rushpost.com> (Shawn K. Quinn via Gnupg-users's message of "Sun, 25 Apr 2021 23:12:34 -0500") References: <5dcacab4-7c99-d092-6560-6aac79920e2c@rushpost.com> Message-ID: <875z09ghch.fsf@wheatstone.g10code.de> On Sun, 25 Apr 2021 23:12, Shawn K. Quinn said: > Now, for me, that begs the question: what does the internal random pool > offer that simply using /dev/random (or better yet a quality HWRNG) does > not? It speeds up the initial seeding of gpg and gpg-agent's the internal RNGs if the system's entropy sources is slow. These days it is of less use and in some cases a echo only-urandom >/etc/gcrypt/random.conf might be all what is required to speed up things. Note that this affects all processes using Libgcrypt so it might be advisable to clear this right at system startup and set it only after the early boot phases. YMMV 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 kirelagin at gmail.com Mon Apr 26 18:18:02 2021 From: kirelagin at gmail.com (Kirill Elagin) Date: Mon, 26 Apr 2021 12:18:02 -0400 Subject: =?UTF-8?Q?Re=3A_Can=E2=80=99t_set_new_PIN_using_Reset_Code?= In-Reply-To: <87a6plghmk.fsf@wheatstone.g10code.de> References: <87a6plghmk.fsf@wheatstone.g10code.de> Message-ID: On Mon, Apr 26, 2021 at 12:05 PM Werner Koch wrote: > You may want to open a bug report at dev.gnupg.org so that we don't > forget about this. Thanks for the tip, I?ll be sure to do so next time! However in this case I have already submitted a patch to gnupg-devel yesterday. I hope you don?t forget about it :). Cheers, Kirill From wk at gnupg.org Mon Apr 26 19:44:29 2021 From: wk at gnupg.org (Werner Koch) Date: Mon, 26 Apr 2021 19:44:29 +0200 Subject: gpg: keydb_search failed: Broken pipe In-Reply-To: (William Holmes via Gnupg-users's message of "Sun, 25 Apr 2021 16:41:32 -0400") References: Message-ID: <87wnspey9u.fsf@wheatstone.g10code.de> On Sun, 25 Apr 2021 16:41, William Holmes said: > I encrypted the file with '--hidden-recipient'. > After decryption failed, gpg-agent was killed. Right, I was able to valgrind the bug. We will have a solution soon. > pub ed25519/0xFB3157F958F70A96 2021-04-25 [SC] Better don't use the keyids. In particular with v5 keys they are confusing because for v5 the keyid are the leftmost bytes instead of the rightmost with v3 and v4 keys. You may want to remove the "keyid-format" from gpg.conf and instead add with-subkey-fingerprint. > sub cv448/0xB36D6CA2989293FF 2021-04-25 [E] Note that we also have a problem that, depending on how the key is created, a v4 instead of a v5 key is created with cv448. There is a fix in 2.3.1 to make sure 448 only uses v5 but that fix was not enough. 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 gniibe at fsij.org Tue Apr 27 13:07:31 2021 From: gniibe at fsij.org (Niibe Yutaka) Date: Tue, 27 Apr 2021 20:07:31 +0900 Subject: gpg: keydb_search failed: Broken pipe In-Reply-To: <87wnspey9u.fsf@wheatstone.g10code.de> References: <87wnspey9u.fsf@wheatstone.g10code.de> Message-ID: <87y2d4rnnw.fsf@jumper.gniibe.org> On Sun, 25 Apr 2021 16:41, William Holmes said: > I encrypted the file with '--hidden-recipient'. > After decryption failed, gpg-agent was killed. This is because there is a bug for decryption of anon recipient. The size of input for decryption should be checked. So far, we only have Curve25519 for Montgomery curve. With X448, we have another Montgomery curve. That's the reason. Werner Koch wrote: > We will have a solution soon. Fixed in libgcrypt master by the commit: 060c378c050e7ec6206358c681a313d6e1967dcf -- From xylene2016 at gmail.com Tue Apr 27 16:37:30 2021 From: xylene2016 at gmail.com (William Holmes) Date: Tue, 27 Apr 2021 10:37:30 -0400 Subject: gpg: keydb_search failed: Broken pipe In-Reply-To: <87y2d4rnnw.fsf@jumper.gniibe.org> References: <87wnspey9u.fsf@wheatstone.g10code.de> <87y2d4rnnw.fsf@jumper.gniibe.org> Message-ID: That's good, it's fixed. On Tue, Apr 27, 2021 at 7:07 AM Niibe Yutaka wrote: > On Sun, 25 Apr 2021 16:41, William Holmes said: > > I encrypted the file with '--hidden-recipient'. > > After decryption failed, gpg-agent was killed. > > This is because there is a bug for decryption of anon recipient. > > The size of input for decryption should be checked. So far, we only > have Curve25519 for Montgomery curve. With X448, we have another > Montgomery curve. That's the reason. > > Werner Koch wrote: > > We will have a solution soon. > > Fixed in libgcrypt master by the commit: > > 060c378c050e7ec6206358c681a313d6e1967dcf > -- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mstep at podiuminternational.org Tue Apr 27 20:32:04 2021 From: mstep at podiuminternational.org (Marek Stepanek) Date: Tue, 27 Apr 2021 20:32:04 +0200 Subject: All my Passwords are lost In-Reply-To: <20210426111232.071f12c5@gmail.com> References: <727D2DBB-89A8-45BB-8EBA-8635C3DE95A3@podiuminternational.org> <20210425084106.0f187786@gmail.com> <20210426111232.071f12c5@gmail.com> Message-ID: Thank you Vincent, I am really ashamed! Yes you are right: encryption is normally done with a public key. (I am blushing). I forgot, because nobody has a PGP-Key to correspond with. The only use for my own PGP-key was to encrypt my own Password-file, AND this with my private key, of course! Only for decrypting I need my (own) private key. Sorry to this mailing group, for this simplicity. But how did it happen? I encrypt always the same way: gpg -e pw.txt filling in my first name and hit twice. That means, no way to fiddle around with the headers (I called them like that) of the pw.gpg-file. It is really encrypted with the PUBLIC key of pause at pause.perl.org - probably a dead email address - nobody is reading. Don?t know what to do. The last month I started to invest into crypto-currency and some information are buried for ever in this gpg.file Suppose Vincent you are French. Donc merci infiniment pour votre aide! marek > On 26. Apr 2021, at 13:12, Vincent Pelletier wrote: > > Hello Marek, > > On Sun, 25 Apr 2021 17:31:53 +0200, Marek Stepanek wrote: >> I am unsure how GnuPG could pick up the wrong key, which does not exist in my key deposit. My guess is, that it is encrypted anyway with my private key > > Beware of a possible misunderstanding here: encryption is done with the > *public* key. It is decryption which requires the private key. So you > can easily encrypt something with any of the (possibly many) public > keys from your key ring. > >> Thank you Vincent for your detailed answer, > > Welcome ! > >> which is way over my head. > > Don't worry, I was tossing some ideas to maybe save you from disclosing > your entire file to someone else (by only exchanging the encrypted > session key rather than the whole file). > But I 100% deffer to anyone knowledgeable about gnupg itself for > whether anything I suggest is actually possible, and how to do it. > >> I really should look into the internals of file encryption one day ? > > Besides on-line sources like wikipedia or youtube (computerphile > channel has several crypto-related videos), I found the following book > to be especially enlightening (...from a crypto-unrelated developer > perspective anyway): > https://www.schneier.com/books/cryptography-engineering/ > > Regards, > -- > Vincent Pelletier > GPG fingerprint 983A E8B7 3B91 1598 7A92 3845 CAC9 3691 4257 B0C1 > -------------- next part -------------- An HTML attachment was scrubbed... URL: