From sven.r.richter at protonmail.ch Wed Dec 1 01:19:45 2021 From: sven.r.richter at protonmail.ch (Sven Richter) Date: Wed, 01 Dec 2021 00:19:45 +0000 Subject: Why are 64-bit libraries not included in GnuPG but Gpg4win? Message-ID: As the title states, why are there no 64-bit libraries in GnuPG for Windows? (The installer from the binary releases) It's not like they don't exist at all but they are part of Gpg4win only. Shouldn't they be included directly in the core part? Why are they "moved out" to Gpg4win? It seems weird to me that I would have to install gpg4win just to get hold of some 64-bit libraries for GnuPG. For some context: I've been using gpg for years, for simple things like to verify files, not mailing. And I'm only using pure GnuPG, not Gpg4win, as I've never felt any need for things like Kleopatra. I'm fine with basic gpg on the terminal, don't need all that additional stuff from Gpg4win. However, recently I decided to change this and set my mail accounts up. The issue apparently? The fact that I'm already using Thunderbird 64-bit. As many will know, Enigmail isn't much of a thing anymore. But I don't really trust that new OpenPGP.js implementation they have now, I rather use my existing setup. No problem, there is a setting just for this in Thunderbird after all, simply set mail.openpgp.allow_external_gnupg = true. Except that this got me vague error messages.I'll spare everybody any long explanations but as hinted the issue seemingly was my 64-bit client. After hours of work I ended up having to install Gpg4win, copy the 64-bit libraries over and deinstall it again. Luckily the libraries work despite Gpg4win 3.1.16 containing only GnuPG 2.2.28, while I'm already using GnuPG 2.3.3, still seems questionable though.This brought me to the question above: Why are the 64-bit libraries only in Gpg4win? Why does GnuPG not come with 64-bit libraries in the first place? I can't imagine that I'm the only or first one using GnuPG and wanting it to work with 64-bit software. 64-bit is getting more and more common after all. Greetings Sven -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: publickey - sven.r.richter at protonmail.ch - 0x141E8192.asc Type: application/pgp-keys Size: 1158 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature URL: From bernhard at intevation.de Thu Dec 2 09:57:06 2021 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 2 Dec 2021 09:57:06 +0100 Subject: Thunderbird's hints and history for OpenPGP/MIME (new wiki page) Message-ID: <202112020957.12700.bernhard@intevation.de> Hi, just compiled a new wiki page with history and hints about using Thunderbird with OpenPGP/MIME. https://wiki.gnupg.org/EMailClients/Thunderbird Mainly I've used information from the email list, but it also adds a conclusion how to deal with subject lines of email. Let me know how you like it. 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 bernhard at intevation.de Thu Dec 2 10:06:11 2021 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 2 Dec 2021 10:06:11 +0100 Subject: Why are 64-bit libraries not included in GnuPG but Gpg4win? In-Reply-To: References: Message-ID: <202112021006.11625.bernhard@intevation.de> Am Mittwoch 01 Dezember 2021 01:19:45 schrieb Sven Richter via Gnupg-users: > As the title states, why are there no 64-bit libraries in GnuPG for > Windows? (The installer from the binary releases) I don't know (but I respond with hints and repeat the question as HTML emails are filtered out by some participants.) > It's not like they don't > exist at all but they are part of Gpg4win only. Shouldn't they be included > directly in the core part? Why are they "moved out" to Gpg4win? It seems > weird to me that I would have to install gpg4win just to get hold of some > 64-bit libraries for GnuPG. Gpg4win is an official GnuPG distribution for Windows and it is possible to customise the installation to mainly install GnuPG. Overal I believe this maybe an oversight, maybe you should file an issue with dev.gnupg.org. > The fact that I'm already using Thunderbird 64-bit. As many will know, > Enigmail isn't much of a thing anymore. But I don't really trust that new > OpenPGP.js implementation they have now, As far as I know Thunderbird 78+ uses RNP/Botan, and not OpenPGP.js. > I rather use my existing setup. No > problem, there is a setting just for this in Thunderbird after all, simply > set mail.openpgp.allow_external_gnupg = true. Except that this got me vague > error messages.I'll spare everybody any long explanations but as hinted the > issue seemingly was my 64-bit client. After hours of work I ended up having > to install Gpg4win, copy the 64-bit libraries over and deinstall it again. Thanks for reporting that this worked fine for you after the right setup! > Luckily the libraries work despite Gpg4win 3.1.16 containing only GnuPG > 2.2.28, while I'm already using GnuPG 2.3.3, still seems questionable > though.This brought me to the question above: Why are the 64-bit libraries > only in Gpg4win? Why does GnuPG not come with 64-bit libraries in the first > place? I can't imagine that I'm the only or first one using GnuPG and > wanting it to work with 64-bit software. Most people use Gpg4win, only recently we had to recommed to install the crypto engine installers over it. So thanks for reporting the issue! 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 pvoigt at uos.de Thu Dec 2 17:35:17 2021 From: pvoigt at uos.de (Dr. Peter Voigt) Date: Thu, 02 Dec 2021 17:35:17 +0100 Subject: Thunderbird's hints and history for OpenPGP/MIME (new wiki page) In-Reply-To: <202112020957.12700.bernhard@intevation.de> References: <202112020957.12700.bernhard@intevation.de> Message-ID: Hi Bernhard, thanks for that page. I'm not using Thunderbird but I know many people who do. In particular the option to turn off the annoying dots is very useful. I'm going to spread the link at least in our association and between friends and colleagues. Did you toot the link through Mastodon as well - I just failed to find and re-toot a correspondig content. Regards, Peter On Thu, 2021-12-02 at 09:57 +0100, Bernhard Reiter wrote: > Hi, > just compiled a new wiki page with history and hints > about using Thunderbird with OpenPGP/MIME. > > ? https://wiki.gnupg.org/EMailClients/Thunderbird > > Mainly I've used information from the email list, > but it also adds a conclusion how to deal with subject lines > of email. > > Let me know how you like it. > > Regards, > Bernhard > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 854 bytes Desc: This is a digitally signed message part URL: From bernhard at intevation.de Fri Dec 3 12:04:18 2021 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 3 Dec 2021 12:04:18 +0100 Subject: Thunderbird's hints and history for OpenPGP/MIME (new wiki page) In-Reply-To: References: <202112020957.12700.bernhard@intevation.de> Message-ID: <202112031204.31216.bernhard@intevation.de> Hi Peter, Am Donnerstag 02 Dezember 2021 17:35:17 schrieb Dr. Peter Voigt: > thanks for that page. I'm not using Thunderbird but I know many people > who do. In particular the option to turn off the annoying dots is very > useful. good to know that you think it is useful. :) > Did you toot the link through Mastodon as well > - I just failed to find and re-toot a correspondig content. I didn't toot it so far. First I wanted to gather some feedback, especially about the following section, where I've added a recommendation what to use instead of incompatible header encryption: | Transport information in a decentral network - just like the writing on the | outside of a postal mail envelope - cannot be protected in principle. | When reflecting on this, chose a subject that is plausible in context, | but without sensitive contents, to best veil potential unwanted observers. | (Your thinking is right: The more sensitive this is, the more you have | to build up a plausible context for your unavoidable traces first.) (Also I've just improved the phrasing and spelling.) 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 bernhard at intevation.de Fri Dec 3 12:10:48 2021 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 3 Dec 2021 12:10:48 +0100 Subject: Why are 64-bit libraries not included in GnuPG but Gpg4win? In-Reply-To: <202112021006.11625.bernhard@intevation.de> References: <202112021006.11625.bernhard@intevation.de> Message-ID: <202112031210.49007.bernhard@intevation.de> Hi Sven, Am Donnerstag 02 Dezember 2021 10:06:11 schrieb Bernhard Reiter: > > It's not like they don't > > exist at all but they are part of Gpg4win only. was in contact with Werner (for other reasons) yesterday, he may still write something about this, but what I think now is that you are talking about libraries like gpgme which Thunderbird uses. > > Shouldn't they be included directly in the core part? Gpgme is an access libary (the official API) and of course it is mainly needed when other application access it. Some people do not need it and it seems reasonable to me, to not consider it part of the core of the GnuPG crypto engine. > Gpg4win is an official GnuPG distribution for Windows > and it is possible to customise the installation to mainly install GnuPG. If it really is the libraries (like I assume now), it seems fine to have them in the full distribution for Windows. Another aspect is interesting: After the setup change you did to Thunderbird, did all operations work fine using public and private keys from GnuPG? 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 jrf at mailbox.org Fri Dec 3 13:52:19 2021 From: jrf at mailbox.org (Rainer Fiebig) Date: Fri, 3 Dec 2021 13:52:19 +0100 Subject: Thunderbird's hints and history for OpenPGP/MIME (new wiki page) In-Reply-To: <202112031204.31216.bernhard@intevation.de> References: <202112020957.12700.bernhard@intevation.de> <202112031204.31216.bernhard@intevation.de> Message-ID: <3d08ccf1-c116-37d9-0198-696c7bfb78be@mailbox.org> Am 03.12.21 um 12:04 schrieb Bernhard Reiter: > Hi Peter, > > Am Donnerstag 02 Dezember 2021 17:35:17 schrieb Dr. Peter Voigt: >> thanks for that page. I'm not using Thunderbird but I know many people >> who do. In particular the option to turn off the annoying dots is very >> useful. > > good to know that you think it is useful. :) No doubt it is useful. This three-dot-BS by default looks more like a bug than a meaningful feature, IMO. > >> Did you toot the link through Mastodon as well >> - I just failed to find and re-toot a correspondig content. > > I didn't toot it so far. > > First I wanted to gather some feedback, especially about the following > section, where I've added a recommendation what to use instead > of incompatible header encryption: > > > | Transport information in a decentral network - just like the writing on the > | outside of a postal mail envelope - cannot be protected in principle. > | When reflecting on this, chose a subject that is plausible in context, > | but without sensitive contents, to best veil potential unwanted observers. > | (Your thinking is right: The more sensitive this is, the more you have > | to build up a plausible context for your unavoidable traces first.) > This caters more to spies or people who have to be paranoid for an other reason. And they will know already. The average user, I guess, just wants to keep private communication private. And what the subject reveals should in most cases be negligible. So to me this paragraph seems a bit out of place. > (Also I've just improved the phrasing and spelling.) > > Best Regards, > Bernhard Thanks for your time and effort! Rainer > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > From sven.r.richter at protonmail.ch Sat Dec 4 05:13:28 2021 From: sven.r.richter at protonmail.ch (Sven Richter) Date: Sat, 04 Dec 2021 04:13:28 +0000 Subject: Why are 64-bit libraries not included in GnuPG but Gpg4win? In-Reply-To: <202112031210.49007.bernhard@intevation.de> References: <202112021006.11625.bernhard@intevation.de> <202112031210.49007.bernhard@intevation.de> Message-ID: Hello Bernhard, > I don't know (but I respond with hints and repeat the question as HTML emails > are filtered out by some participants.) Thanks for pointing that out. This is actually my first time participating on a mailing list, I'm more used to forums and chats, so if there's anything else that's unusual about my mails, feel free to mention it. This one should now be plain text. > As far as I know Thunderbird 78+ uses RNP/Botan, and not OpenPGP.js. Maybe this has changed since I last looked into the topic, guess I'll have to check on that. However I doubt that would change my setup. I far rather have GnuPG manage my keys as much as possible than the email client. I kind of already guessed that maybe most people would use Gpg4win. But the installer for GnuPG is there and I'm sure some other people will use that as well. Since I've set everything up, it works just fine with the 64-bit client, no issues at all. It's really just the 64-bit libraries missing when you use the basic GnuPG installation, once you get those it works without issues. As far as it goes for the libraries, maybe I should specify that a bit more. What I did was to create a folder at C:\Program Files (x86)\gnupg\bin_64 (used the same folder name as I found within the Gpg4win directory) and then I copied the following files over to that folder: gpgme-w32spawn.exe, libassuan6-0.dll, libgpg-error6-0.dll and libgpgme-11.dll. >From what I'm able to tell, all of these already exist in the regular bin folder of the GnuPG installation (or rather their 32-bit variants do I guess). Unless there are any leftovers from when I installed Gpg4win, but I'm quite sure I checked that the whole gnupg folder was deleted after I deinstalled Gpg4win, before I reinstalled the latest version of GnuPG again. The only difference I see is the number six in the file name libassuan-0.dll -> libassuan6-0.dll and the file size. I'm sure the bin_64 folder in the Gpg4win directory has some libraries which might be specific to Kleopatra, GPA or some other part of Gpg4win, however I don't need those. I believe I'm only using 64-bit variants of files are are already present in their 32-bit form in the regular bin folder of GnuPG anyway. Hence it would make sense in my opinion to directly include the 64-bit variants of them in the basic GnuPG installation. > Another aspect is interesting: After the setup change you did to Thunderbird, > did all operations work fine using public and private keys from GnuPG? Not quite, I had to import public keys into Thunderbird. Thunderbird expects to be able to manage all public keys regardless. Even with this setup of mine, it only pulls the private keys from GnuPG. If people are interested in the exact process of how I've set it up, I could write a detailed explanation/guide for it. Either on the Thunderbird page of the wiki that you just recently created or on a dedicated page. Kind regards, Sven ??????? Original Message ??????? On Friday, December 3, 2021 11:10 AM, Bernhard Reiter wrote: > Hi Sven, > > Am Donnerstag 02 Dezember 2021 10:06:11 schrieb Bernhard Reiter: > > > > It's not like they don't > > > exist at all but they are part of Gpg4win only. > > was in contact with Werner (for other reasons) yesterday, > he may still write something about this, but what I think now is > that you are talking about libraries like gpgme which Thunderbird uses. > > > > Shouldn't they be included directly in the core part? > > Gpgme is an access libary (the official API) and of course it is mainly needed > when other application access it. Some people do not need it and it seems > reasonable to me, to not consider it part of the core of the GnuPG crypto > engine. > > > Gpg4win is an official GnuPG distribution for Windows > > and it is possible to customise the installation to mainly install GnuPG. > > If it really is the libraries (like I assume now), > it seems fine to have them in the full distribution for Windows. > > Another aspect is interesting: After the setup change you did to Thunderbird, > did all operations work fine using public and private keys from GnuPG? > > 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 > > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature URL: From andrewg at andrewg.com Sat Dec 4 11:41:15 2021 From: andrewg at andrewg.com (Andrew Gallagher) Date: Sat, 4 Dec 2021 10:41:15 +0000 Subject: Why are 64-bit libraries not included in GnuPG but Gpg4win? In-Reply-To: References: Message-ID: > On 4 Dec 2021, at 04:14, Sven Richter via Gnupg-users wrote: > > Thunderbird expects to be able to manage all public keys regardless. Even with this setup of mine, it only pulls the private keys from GnuPG. You may be interested in the Sequoia Octopus, which is a drop in replacement for Thunderbird?s RNP library and enables public keyring sync between TB and GnuPG: https://gitlab.com/sequoia-pgp/sequoia-octopus-librnp#building-installing A -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Mon Dec 6 02:28:07 2021 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 5 Dec 2021 20:28:07 -0500 Subject: 2.3 --list-keys weirdness Message-ID: rjh at ripley:~$ gpg -vvvv --list-keys gpg: using character set 'utf-8' gpg: Note: RFC4880bis features are enabled. gpg: key 1DCBDC01B44427C7: accepted as trusted key gpg: key 1E7A94D4E87F91D5: accepted as trusted key gpg: key A3C418D1C6F3453A: accepted as trusted key ... No output is ever produced: it just hangs without ever giving a hint as to what's going on, what's wrong, or how to fix it. This is not the behavior I expect from a high-verbosity output. What's going on here? From kloecker at kde.org Mon Dec 6 09:33:31 2021 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Mon, 06 Dec 2021 09:33:31 +0100 Subject: 2.3 --list-keys weirdness In-Reply-To: References: Message-ID: <1647886.usRXaOL7yN@breq> On Montag, 6. Dezember 2021 02:28:07 CET Robert J. Hansen via Gnupg-users wrote: > rjh at ripley:~$ gpg -vvvv --list-keys > gpg: using character set 'utf-8' > gpg: Note: RFC4880bis features are enabled. > gpg: key 1DCBDC01B44427C7: accepted as trusted key > gpg: key 1E7A94D4E87F91D5: accepted as trusted key > gpg: key A3C418D1C6F3453A: accepted as trusted key Looks like the output on stdout is missing completely. > ... No output is ever produced: it just hangs without ever giving a hint > as to what's going on, what's wrong, or how to fix it. This is not the > behavior I expect from a high-verbosity output. What's going on here? Doesn't happen here with self-compiled $ gpg --version gpg (GnuPG) 2.3.3-beta6 libgcrypt 1.9.4-beta84 Which version exactly are you using? Try attaching gdb to see where it hangs. 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 rjh at sixdemonbag.org Mon Dec 6 09:41:51 2021 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 6 Dec 2021 03:41:51 -0500 Subject: 2.3 --list-keys weirdness In-Reply-To: <1647886.usRXaOL7yN@breq> References: <1647886.usRXaOL7yN@breq> Message-ID: <26e29ef4-ce6d-9e0a-fc8c-8e28695af1bc@sixdemonbag.org> > Which version exactly are you using? 2.3.3. > Try attaching gdb to see where it hangs. (gdb) run Starting program: /usr/local/bin/gpg --list-keys [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Detaching after fork from child process 41865] ^C Program received signal SIGINT, Interrupt. 0x00007ffff7c70e87 in __libc_recvmsg (fd=fd at entry=4, msg=msg at entry=0x7fffffffd490, flags=flags at entry=0) at ../sysdeps/unix/sysv/linux/recvmsg.c:28 28 ../sysdeps/unix/sysv/linux/recvmsg.c: No such file or directory. (gdb) backtrace #0 0x00007ffff7c70e87 in __libc_recvmsg (fd=fd at entry=4, msg=msg at entry=0x7fffffffd490, flags=flags at entry=0) at ../sysdeps/unix/sysv/linux/recvmsg.c:28 #1 0x00007ffff7c96437 in __assuan_recvmsg (ctx=ctx at entry=0x555555681ec0, fd=fd at entry=4, msg=msg at entry=0x7fffffffd490, flags=flags at entry=0) at system-posix.c:133 #2 0x000055555556eacf in _assuan_npth_recvmsg (ctx=0x555555681ec0, fd=4, msg=0x7fffffffd490, flags=0) at gpg.c:1037 #3 0x00007ffff7c94923 in uds_reader (ctx=0x555555681ec0, buf=, buflen=) at assuan-uds.c:113 #4 0x00007ffff7c8f23f in readline (ctx=ctx at entry=0x555555681ec0, buf=buf at entry=0x555555682010 "", buflen=buflen at entry=1002, r_nread=r_nread at entry=0x7fffffffd56c, r_eof=r_eof at entry=0x55555568200c) at assuan-buffer.c:79 #5 0x00007ffff7c8f419 in _assuan_read_line (ctx=ctx at entry=0x555555681ec0) at assuan-buffer.c:151 #6 0x00007ffff7c8ea50 in assuan_client_read_response ( ctx=ctx at entry=0x555555681ec0, line_r=line_r at entry=0x7fffffffd660, linelen_r=linelen_r at entry=0x7fffffffd65c) at client.c:87 #7 0x00007ffff7c8edbb in _assuan_read_from_server ( ctx=ctx at entry=0x555555681ec0, response=response at entry=0x7fffffffd6b0, off=off at entry=0x7fffffffd6b4, convey_comments=convey_comments at entry=0) at client.c:209 #8 0x00007ffff7c93f07 in _assuan_connect_finalize ( ctx=ctx at entry=0x555555681ec0, fd=fd at entry=4, flags=flags at entry=1) at assuan-socket-connect.c:125 #9 0x00007ffff7c942e8 in assuan_socket_connect (ctx=ctx at entry=0x555555681ec0, name=, name at entry=0x555555686de0 "/run/user/1000/gnupg/S.keyboxd", server_pid=server_pid at entry=0, flags=flags at entry=1) at assuan-socket-connect.c:343 #10 0x000055555562004b in wait_for_sock (secs=5, did_success_msg=, ctx=0x555555681ec0, verbose=0, connect_flags=1, sockname=0x555555686de0 "/run/user/1000/gnupg/S.keyboxd", module_name_id=13) at asshelp.c:358 #11 start_new_service (r_ctx=r_ctx at entry=0x7fffffffd930, module_name_id=module_name_id at entry=13, errsource=errsource at entry=GPG_ERR_SOURCE_GPG, program_name=, opt_lc_ctype=opt_lc_ctype at entry=0x0, opt_lc_messages=opt_lc_messages at entry=0x0, session_env=0x0, autostart=1, verbose=0, debug=0, status_cb=0x0, status_cb_arg=0x555555684b70) at asshelp.c:548 #12 0x000055555562025c in start_new_keyboxd (r_ctx=r_ctx at entry=0x7fffffffd930, errsource=errsource at entry=GPG_ERR_SOURCE_GPG, keyboxd_program=, autostart=, verbose=, debug=, status_cb=0x0, status_cb_arg=0x555555684b70) at asshelp.c:635 #13 0x000055555558a0ba in create_new_context (r_ctx=0x5555556850d8, ctrl=0x555555684b70) at call-keyboxd.c:143 #14 open_context (r_kbl=0x555555684c70, ctrl=0x555555684b70) at call-keyboxd.c:219 #15 keydb_new (ctrl=ctrl at entry=0x555555684b70) at call-keyboxd.c:277 #16 0x00005555555b28fb in list_all (ctrl=ctrl at entry=0x555555684b70, secret=secret at entry=0, mark_secret=0) at keylist.c:527 --Type for more, q to quit, c to continue without paging--c #17 0x00005555555b2f34 in public_key_list (ctrl=ctrl at entry=0x555555684b70, list=0x0, locate_mode=0, no_local=0) at keylist.c:146 #18 0x000055555556acf2 in main (argc=, argv=) at gpg.c:4638 From rjh at sixdemonbag.org Tue Dec 7 08:04:21 2021 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 7 Dec 2021 02:04:21 -0500 Subject: 2.3 --list-keys weirdness In-Reply-To: <26e29ef4-ce6d-9e0a-fc8c-8e28695af1bc@sixdemonbag.org> References: <1647886.usRXaOL7yN@breq> <26e29ef4-ce6d-9e0a-fc8c-8e28695af1bc@sixdemonbag.org> Message-ID: >> Try attaching gdb to see where it hangs. > > (gdb) run > Starting program: /usr/local/bin/gpg --list-keys > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". > [Detaching after fork from child process 41865] > ^C "gpgconf --kill all" solved my problem, but I'd still advise y'all to look into where it got wedged and why -- this was an incredibly annoying problem to solve, and the total lack of debugging output elevated it to tremendously frustrating. From rjh at sixdemonbag.org Tue Dec 7 08:07:51 2021 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 7 Dec 2021 02:07:51 -0500 Subject: 2.3 --list-keys weirdness In-Reply-To: References: <1647886.usRXaOL7yN@breq> <26e29ef4-ce6d-9e0a-fc8c-8e28695af1bc@sixdemonbag.org> Message-ID: <8b15e4c3-399f-42ed-0db1-f3eb6dc4e38a@sixdemonbag.org> > "gpgconf --kill all" solved my problem, but I'd still advise y'all to > look into where it got wedged and why -- this was an incredibly annoying > problem to solve, and the total lack of debugging output elevated it to > tremendously frustrating. I'm such an idiot, I forgot I was sshed into another machine. Nope, problem still exists, and gpgconf hangs just like everything else. GnuPG is still unusable. ===== rjh at ripley:~$ gdb --args gpgconf --kill all [boilerplate stripped] (gdb) run Starting program: /usr/local/bin/gpgconf --kill all [Detaching after fork from child process 101626] [Detaching after fork from child process 101629] [Detaching after fork from child process 101632] [Detaching after fork from child process 101634] ^C Program received signal SIGINT, Interrupt. 0x00007ffff7d2b83a in __GI___wait4 (pid=pid at entry=101634, stat_loc=stat_loc at entry=0x7fffffffdd24, options=options at entry=0, usage=usage at entry=0x0) at ../sysdeps/unix/sysv/linux/wait4.c:30 30 ../sysdeps/unix/sysv/linux/wait4.c: No such file or directory. (gdb) backtrace #0 0x00007ffff7d2b83a in __GI___wait4 (pid=pid at entry=101634, stat_loc=stat_loc at entry=0x7fffffffdd24, options=options at entry=0, usage=usage at entry=0x0) at ../sysdeps/unix/sysv/linux/wait4.c:30 #1 0x00007ffff7d2b7fb in __GI___waitpid (pid=pid at entry=101634, stat_loc=stat_loc at entry=0x7fffffffdd24, options=options at entry=0) at waitpid.c:38 #2 0x0000555555570610 in gnupg_wait_process ( pgmname=pgmname at entry=0x555555589eb0 "/usr/local/bin/gpg-connect-agent", pid=101634, hang=hang at entry=1, r_exitcode=r_exitcode at entry=0x0) at exechelp-posix.c:672 #3 0x000055555555e0a3 in keyboxd_runtime_change (killflag=1) at gpgconf-comp.c:919 #4 0x000055555555d5e4 in do_runtime_change (component=3, killflag=killflag at entry=1) at gpgconf-comp.c:1018 #5 0x000055555555e5de in gc_component_kill (component=) at gpgconf-comp.c:1027 #6 0x000055555555bcbf in main (argc=, argv=) at gpgconf.c:793 From kloecker at kde.org Tue Dec 7 09:16:33 2021 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Tue, 07 Dec 2021 09:16:33 +0100 Subject: 2.3 --list-keys weirdness In-Reply-To: <26e29ef4-ce6d-9e0a-fc8c-8e28695af1bc@sixdemonbag.org> References: <1647886.usRXaOL7yN@breq> <26e29ef4-ce6d-9e0a-fc8c-8e28695af1bc@sixdemonbag.org> Message-ID: <4674932.nqGfILh9ZU@daneel> On Montag, 6. Dezember 2021 09:41:51 CET Robert J. Hansen via Gnupg-users wrote: > > Which version exactly are you using? > > 2.3.3. > > > Try attaching gdb to see where it hangs. > > #12 0x000055555562025c in start_new_keyboxd > (r_ctx=r_ctx at entry=0x7fffffffd930, > errsource=errsource at entry=GPG_ERR_SOURCE_GPG, > keyboxd_program=, autostart=, > verbose=, debug=, status_cb=0x0, > status_cb_arg=0x555555684b70) at asshelp.c:635 The problem seems to be caused by the new experimental keyboxd. Try disabling it. Unfortunately, you may lose all keys stored by the daemon because it doesn't use the keyrings. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From rjh at sixdemonbag.org Wed Dec 8 04:49:12 2021 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 7 Dec 2021 22:49:12 -0500 Subject: Continuing 2.3 weirdness Message-ID: <907a8b71-9e31-9e82-268f-c4bee3943116@sixdemonbag.org> Turns out the problem was keyboxd was waiting for a lock. Unfortunately I wasn't able to find the lock: so, after making a backup, I decided to resort to harsh measures: I nuked my .gnupg directory. Now GnuPG is getting a little further along, but it's still not working properly. Let's start by nuking the .gnupg directory and shutting down all GnuPG daemons: rjh at ripley:~$ rm -rf .gnupg rjh at ripley:~$ /usr/local/bin/gpgconf --kill all rjh at ripley:~$ ps ax|grep [g]pg-agent No output: gpg-agent is gone, and I'm assuming other GnuPG daemons are, too. Next, verify we have a /usr/local/bin/gpg-agent and that it points to the correct GnuPG helper programs: rjh at ripley:~$ ls -lh /usr/local/bin/gpg-agent -rwxr-xr-x 1 root root 2.3M Dec 5 20:19 /usr/local/bin/gpg-agent rjh at ripley:~$ /usr/local/bin/gpgconf --check-programs gpg:OpenPGP:/usr/local/bin/gpg:1:1: gpgsm:S/MIME:/usr/local/bin/gpgsm:1:1: keyboxd:Public Keys:/usr/local/libexec/keyboxd:1:1: gpg-agent:Private Keys:/usr/local/bin/gpg-agent:1:1: scdaemon:Smartcards:/usr/local/libexec/scdaemon:1:1: dirmngr:Network:/usr/local/bin/dirmngr:1:1: pinentry:Passphrase Entry:/usr/local/bin/pinentry:1:1: All looks good. Let's launch gpg-agent. rjh at ripley:~$ /usr/local/bin/gpgconf --launch gpg-agent rjh at ripley:~$ ps ax|grep [g]pg-agent 229366 ? SLs 0:00 /usr/bin/gpg-agent --supervised Wait, what? Why was /usr/bin/gpg-agent (system-provided, version 2.2) used instead of 2.3? From kloecker at kde.org Wed Dec 8 09:27:24 2021 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Wed, 08 Dec 2021 09:27:24 +0100 Subject: Continuing 2.3 weirdness In-Reply-To: <907a8b71-9e31-9e82-268f-c4bee3943116@sixdemonbag.org> References: <907a8b71-9e31-9e82-268f-c4bee3943116@sixdemonbag.org> Message-ID: <6587699.mX3c7hZMXn@daneel> On Mittwoch, 8. Dezember 2021 04:49:12 CET Robert J. Hansen via Gnupg-users wrote: > Let's start by nuking the .gnupg directory and shutting down all GnuPG > daemons: > > rjh at ripley:~$ rm -rf .gnupg > rjh at ripley:~$ /usr/local/bin/gpgconf --kill all > rjh at ripley:~$ ps ax|grep [g]pg-agent > > rjh at ripley:~$ /usr/local/bin/gpgconf --launch gpg-agent > rjh at ripley:~$ ps ax|grep [g]pg-agent > 229366 ? SLs 0:00 /usr/bin/gpg-agent --supervised > > Wait, what? Why was /usr/bin/gpg-agent (system-provided, version 2.2) > used instead of 2.3? I make different observations (using self-compiled gpg installed to /opt/ gnupg/master with a non-standard GNUPGHOME): $ echo $PATH | grep /opt/gnupg/master -> no output $ GNUPGHOME=$(mktemp -d --tmpdir gnupg.XXXXXXXXXX) \ /opt/gnupg/master/bin/gpgconf --launch gpg-agent -> use a new temporary GNUPGHOME $ ps ax | grep [g]pg-agent 7337 ? Ss 0:00 gpg-agent --homedir /tmp/gnupg.hq2lhQi4eF --use- standard-socket --daemon $ ls -l /proc/7337/exe lrwxrwxrwx 1 ingo users 0 Dez 8 09:13 /proc/7337/exe -> /opt/gnupg/master/ bin/gpg-agent* Observations: * Here gpgconf launches the correct gpg-agent. * Here gpgconf is launched with different command line arguments. Do you probably have a global gnupg configuration file in /etc? $ /opt/gnupg/master/bin/gpgconf --list-config -> no output -> no global configuration file Or use the brand new (post-2.3.3) --show-configs option which lists all configuration files with all options: $ GNUPGHOME=/tmp/gnupg.hq2lhQi4eF /opt/gnupg/master/bin/gpgconf --show-configs ### Dump of all standard config files ### GnuPG 2.3.4-beta24 (b124bca59) ### GNU/Linux ### Libgcrypt 1.9.4-unknown ### GpgRT 1.43 ### sysconfdir:/etc/gnupg bindir:/opt/gnupg/master/bin libexecdir:/opt/gnupg/master/libexec libdir:/opt/gnupg/master/lib64/gnupg datadir:/opt/gnupg/master/share/gnupg localedir:/opt/gnupg/master/share/locale socketdir:/run/user/1000/gnupg/d.61urptbn5qmwuf71byjbhrh8 dirmngr-socket:/run/user/1000/gnupg/d.61urptbn5qmwuf71byjbhrh8/S.dirmngr keyboxd-socket:/run/user/1000/gnupg/d.61urptbn5qmwuf71byjbhrh8/S.keyboxd agent-ssh-socket:/run/user/1000/gnupg/d.61urptbn5qmwuf71byjbhrh8/S.gpg- agent.ssh agent-extra-socket:/run/user/1000/gnupg/d.61urptbn5qmwuf71byjbhrh8/S.gpg- agent.extra agent-browser-socket:/run/user/1000/gnupg/d.61urptbn5qmwuf71byjbhrh8/S.gpg- agent.browser agent-socket:/run/user/1000/gnupg/d.61urptbn5qmwuf71byjbhrh8/S.gpg-agent homedir:/tmp/gnupg.hq2lhQi4eF ### ### global config "/etc/gnupg/common.conf": not installed ### ### ### local config "/tmp/gnupg.hq2lhQi4eF/common.conf": not installed ### ### ### global config "/etc/gnupg/gpg-agent.conf": not installed ### ### ### local config "/tmp/gnupg.hq2lhQi4eF/gpg-agent.conf": not installed ### ### ### global config "/etc/gnupg/scdaemon.conf": not installed ### ### ### local config "/tmp/gnupg.hq2lhQi4eF/scdaemon.conf": not installed ### ### ### global config "/etc/gnupg/dirmngr.conf": not installed ### ### ### local config "/tmp/gnupg.hq2lhQi4eF/dirmngr.conf": not installed ### ### ### global config "/etc/gnupg/gpg.conf": not installed ### ### ### local config "/tmp/gnupg.hq2lhQi4eF/gpg.conf": not installed ### ### ### global config "/etc/gnupg/gpgsm.conf": not installed ### ### ### local config "/tmp/gnupg.hq2lhQi4eF/gpgsm.conf": not installed ### Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From rjh at sixdemonbag.org Wed Dec 8 17:31:29 2021 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 8 Dec 2021 11:31:29 -0500 Subject: Continuing 2.3 weirdness In-Reply-To: <6587699.mX3c7hZMXn@daneel> References: <907a8b71-9e31-9e82-268f-c4bee3943116@sixdemonbag.org> <6587699.mX3c7hZMXn@daneel> Message-ID: <3b1d22d2-e246-6da1-7334-138fb23248dc@sixdemonbag.org> > I make different observations (using self-compiled gpg installed to /opt/ > gnupg/master with a non-standard GNUPGHOME): It turns out the source of the trouble was systemd, which was starting gpg-agent on demand, and was forcing it to use /usr/bin/gpg-agent. Setting a user override file fixed the behavior. Really annoying to hunt down, though. My thanks to Phil Pennock for helping me debug this. From christoph-klassen at mail.de Thu Dec 9 17:10:29 2021 From: christoph-klassen at mail.de (Christoph Klassen) Date: Thu, 9 Dec 2021 17:10:29 +0100 Subject: Thunderbird's hints and history for OpenPGP/MIME (new wiki page) In-Reply-To: <3d08ccf1-c116-37d9-0198-696c7bfb78be@mailbox.org> References: <202112020957.12700.bernhard@intevation.de> <202112031204.31216.bernhard@intevation.de> <3d08ccf1-c116-37d9-0198-696c7bfb78be@mailbox.org> Message-ID: <20211209171029.25423ff4@littleparrot.fritz.box> I was testing Thunderbird Daily 97.0a1 for a different purpose, but I saw that you can disable the encryption of the subject in the settings (in the category "End-to-end Encryption). Just added this information to the wiki with a screenshot. For me the encryption of the subject seemed to be an advantage because the subject is some kind of meta information and meta information can say very much about a person. Greetings, Christoph From bereska at hotmail.com Sat Dec 11 13:17:57 2021 From: bereska at hotmail.com (bereska at hotmail.com) Date: Sat, 11 Dec 2021 14:17:57 +0200 Subject: using two Yubikeys with the same key Message-ID: Dear GnuPG Experts, After moving the _same_ PGP keys to two Yubikeys (created on an air gapped live Tails USB) I have a problem using the second one. The fist key successfully encrypt and decrypts. But when trying to use the second Yubikey, the decryption operation of the file encrypted with first Yubikey prompts to insert the first Yubikey with serial number XXX. This kills the reason for using the second Yubikey. Is there a way to tell gnupg to use the second key with the same keys but a different serial number YYY to decrypt the same very file? I am using: gpg (GnuPG) 2.2.28 libgcrypt 1.8.8 MacOS Big Sur thank you, Dmitry -------------- next part -------------- An HTML attachment was scrubbed... URL: From kloecker at kde.org Sat Dec 11 20:55:10 2021 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Sat, 11 Dec 2021 20:55:10 +0100 Subject: using two Yubikeys with the same key In-Reply-To: References: Message-ID: <3180063.JRCsQXGWca@breq> On Samstag, 11. Dezember 2021 13:17:57 CET bereska--- via Gnupg-users wrote: > Is there a way to tell gnupg to use the second key with the same keys > but a different serial number YYY to decrypt the same very file? > > I am using: > gpg (GnuPG) 2.2.28 This should work with GnuPG 2.3.x which has improved support for multiple card readers and tokens. 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 Sun Dec 12 18:30:47 2021 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Sun, 12 Dec 2021 18:30:47 +0100 Subject: using two Yubikeys with the same key In-Reply-To: References: Message-ID: <1778354.aDOlfHxISX@breq> Please keep replies on this mailing list. On Sonntag, 12. Dezember 2021 09:12:28 CET bereska at hotmail.com wrote: > everything is cool now except for one symlink error: > > $ gpg --version > *gpg: error reading symlink '/proc/curproc/file': No such file or directory* You can safely ignore this error. It's harmless and the error message should no longer be shown in the next version. 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 bereska at hotmail.com Sun Dec 12 19:03:54 2021 From: bereska at hotmail.com (bereska at hotmail.com) Date: Sun, 12 Dec 2021 20:03:54 +0200 Subject: using two Yubikeys with the same key In-Reply-To: <1778354.aDOlfHxISX@breq> References: <1778354.aDOlfHxISX@breq> Message-ID: sure I will thanks for your help 12.12.2021 19:30, Ingo Kl?cker ?????: > Please keep replies on this mailing list. > > On Sonntag, 12. Dezember 2021 09:12:28 CET bereska at hotmail.com wrote: >> everything is cool now except for one symlink error: >> >> $ gpg --version >> *gpg: error reading symlink '/proc/curproc/file': No such file or directory* > You can safely ignore this error. It's harmless and the error message should > no longer be shown in the next version. > > Regards, > Ingo > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From bereska at hotmail.com Mon Dec 13 08:34:57 2021 From: bereska at hotmail.com (bereska at hotmail.com) Date: Mon, 13 Dec 2021 09:34:57 +0200 Subject: using two Yubikeys with the same key In-Reply-To: <1778354.aDOlfHxISX@breq> References: <1778354.aDOlfHxISX@breq> Message-ID: I hate to bother you but after updating to Mac OS Monterey last night gnupg does not work with the two Yubikeys nicely(. It asks for the first Yubikey the file was encrypted with when I try to decrypt this file with the second Yubikey. Both Yubikeys have the same secret keys. I am now using: gpg (GnuPG) 2.3.3 libgcrypt 1.9.4 Mac OS Monterey thank you 12.12.2021 19:30, Ingo Kl?cker ?????: > Please keep replies on this mailing list. > > On Sonntag, 12. Dezember 2021 09:12:28 CET bereska at hotmail.com wrote: >> everything is cool now except for one symlink error: >> >> $ gpg --version >> *gpg: error reading symlink '/proc/curproc/file': No such file or directory* > You can safely ignore this error. It's harmless and the error message should > no longer be shown in the next version. > > Regards, > Ingo > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From bereska at hotmail.com Mon Dec 13 08:39:52 2021 From: bereska at hotmail.com (bereska at hotmail.com) Date: Mon, 13 Dec 2021 09:39:52 +0200 Subject: using two Yubikeys with the same key In-Reply-To: References: <1778354.aDOlfHxISX@breq> Message-ID: quick update ... after running it starts working as it should is it a feature or a bug? thank you 13.12.2021 09:34, bereska at hotmail.com ?????: > I hate to bother you but after updating to Mac OS Monterey last night > gnupg does not work with the two Yubikeys nicely(. It asks for the > first Yubikey the file was encrypted with when I try to decrypt this > file with the second Yubikey. Both Yubikeys have the same secret keys. > > I am now using: > > gpg (GnuPG) 2.3.3 > libgcrypt 1.9.4 > Mac OS Monterey > > thank you > > 12.12.2021 19:30, Ingo Kl?cker ?????: >> Please keep replies on this mailing list. >> >> On Sonntag, 12. Dezember 2021 09:12:28 CET bereska at hotmail.com wrote: >>> everything is cool now except for one symlink error: >>> >>> $ gpg --version >>> *gpg: error reading symlink '/proc/curproc/file': No such file or >>> directory* >> You can safely ignore this error. It's harmless and the error message >> should >> no longer be shown in the next version. >> >> Regards, >> Ingo >> >> _______________________________________________ >> Gnupg-users mailing list >> Gnupg-users at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-users > From bernhard at intevation.de Wed Dec 15 12:45:43 2021 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 15 Dec 2021 12:45:43 +0100 Subject: Why are 64-bit libraries not included in GnuPG but Gpg4win? In-Reply-To: References: <202112031210.49007.bernhard@intevation.de> Message-ID: <202112151245.58476.bernhard@intevation.de> Hello Sven, Am Samstag 04 Dezember 2021 05:13:28 schrieb Sven Richter via Gnupg-users: > Thunderbird > expects to be able to manage all public keys regardless. Even with this > setup of mine, it only pulls the private keys from GnuPG. > I far rather > have GnuPG manage my keys as much as possible than the email client. yes, it would be cool to give that as a wish to Thunderbird to develop a full GnuPG based backend for that purposes for the people that have that use case and install Gpg4win anyway. (I think adding another experimental layer in between will not be the best solution, it can introduce other sources of differences in behaviour.) [back to the 64bit libraries question] > I believe I'm only using 64-bit variants of > files are are already present in their 32-bit form in the regular bin > folder of GnuPG anyway. Hence it would make sense in my opinion to directly > include the 64-bit variants of them in the basic GnuPG installation. Maybe. The current aim is to get Gpg4win 4 out of the door, so right now the question to change the roles of the small engine installer and the full installer for Windows (Gpg4win) is taking the backseat to this. Best, 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 bernhard at intevation.de Wed Dec 15 12:51:26 2021 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 15 Dec 2021 12:51:26 +0100 Subject: Thunderbird's hints and history for OpenPGP/MIME (new wiki page) In-Reply-To: <3d08ccf1-c116-37d9-0198-696c7bfb78be@mailbox.org> References: <202112020957.12700.bernhard@intevation.de> <202112031204.31216.bernhard@intevation.de> <3d08ccf1-c116-37d9-0198-696c7bfb78be@mailbox.org> Message-ID: <202112151251.27353.bernhard@intevation.de> Am Freitag 03 Dezember 2021 13:52:19 schrieb Rainer Fiebig via Gnupg-users: > Am 03.12.21 um 12:04 schrieb Bernhard Reiter: > > of incompatible header encryption: > > | Transport information in a decentral network - just like the writing on > > | the outside of a postal mail envelope - cannot be protected in > > | principle. When reflecting on this, chose a subject that is plausible > > | in context, but without sensitive contents, to best veil potential > > | unwanted observers. (Your thinking is right: The more sensitive this > > | is, the more you have to build up a plausible context for your > > | unavoidable traces first.) > > This caters more to spies or people who have to be paranoid for an other > reason. And they will know already. > The average user, I guess, just wants to keep private communication > private. And what the subject reveals should in most cases be > negligible. So to me this paragraph seems a bit out of place. Okay, thanks for letting me know. I've included it because many people feel that encrypting this part of the meta data is a good idea and should be done for average users. (As Christoph wrote Donnerstag 09 Dezember 2021 17:10:29: | For me the encryption of the subject seemed to be an advantage because | the subject is some kind of meta information and meta information can | say very much about a person. ) This clashes a bit with the confidentially improvement somebody may get using a transport network that is not controlled by one entity and by multiple indepentently implemented clients. For this I believe that all users need to be aware of what is meta information and what is not. My hypothesis is that people can deal with this in daily non-digital life already, like considering what to talk about or display in a public or semi-public place. Anyway, next time I'll check that paragraph, I think how I can make the connection in a better way. 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 rhettbohling at gmail.com Wed Dec 15 13:07:21 2021 From: rhettbohling at gmail.com (Rhetoric Bohling) Date: Wed, 15 Dec 2021 07:07:21 -0500 Subject: GnuPG / Mailvelope on Windows 11 Message-ID: Hello GnuPGers, I recently was in a loop trying to figure out GnuPG on Windows 10/11. Can you natively use GnuPG? Or is it limited to the few implementations of it through Kleapatra/etc.?pgp. I was using Mailvelope, and I could not get the Mailvelope app to recognize I was using GnuPG. It kept saying OpenPGP. I am confused. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sami.badri at gmail.com Thu Dec 16 12:52:28 2021 From: sami.badri at gmail.com (S.B.) Date: Thu, 16 Dec 2021 06:52:28 -0500 Subject: fingerprint associated public key does not match displayed public key Message-ID: Hello GnuPG world, I'm a new (and obsessed) pgp user, so please bear with me. Also, I hope I'm in the right place. I read through some archives and the questions seemed a little advanced. I hope I'm not annoying anyone here. I use GnuPG 2.3.3 on a MacBook Pro running Mac OS Monterey (v. 12.0.1) Here is my situation: I have imported a public key using gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys fingerprint* *provided by the intended recipient on their profile page The person also displayed the pgp public key block text (in armor) but not as an asc file. I first tried importing the block directly into gpg but couldn't figure it out. when comparing the imported key (again, obtained via the keyserver using the fingerprint) to the displayed public key block, they do not match. Reasons for this (I think) are: 1. either the fingerprint or the key has been changed but not updated on the profile page 2. it's a scam/hack 3. I don't understand what's going on (most likely reason) Any help would be appreciated. Thank you. From kloecker at kde.org Thu Dec 16 14:33:00 2021 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Thu, 16 Dec 2021 14:33:00 +0100 Subject: fingerprint associated public key does not match displayed public key In-Reply-To: References: Message-ID: <1852328.iejboYy8mS@daneel> On Donnerstag, 16. Dezember 2021 12:52:28 CET S.B. via Gnupg-users wrote: > Here is my situation: I have imported a public key using > gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys fingerprint* > > *provided by the intended recipient on their profile page > > The person also displayed the pgp public key block text (in armor) but > not as an asc file. I first tried importing the block directly into > gpg but couldn't figure it out. > > when comparing the imported key (again, obtained via the keyserver > using the fingerprint) to the displayed public key block, they do not > match. How do you do this, i.e. what commands are you using? > Reasons for this (I think) are: > 1. either the fingerprint or the key has been changed but not updated > on the profile page The fingerprint of an OpenPGP key never changes (except if its creation time changes). Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From sami.badri at gmail.com Thu Dec 16 16:37:30 2021 From: sami.badri at gmail.com (S.B.) Date: Thu, 16 Dec 2021 10:37:30 -0500 Subject: fingerprint associated public key does not match displayed public key In-Reply-To: <1852328.iejboYy8mS@daneel> References: <1852328.iejboYy8mS@daneel> Message-ID: maybe I'm not explaining it well. I was able to import a public key using: gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys fingerprint* the fingerprint was provided to me by the intended recipient via their profile page. the profile page also displayed the pgp public key block when i compared the imported pgp public key block (which I obtained using the import command and the provided fingerprint) to the displated pgp public key block, they didn't match shouldn't they match? thank you On Thu, Dec 16, 2021 at 8:34 AM Ingo Kl?cker wrote: > > On Donnerstag, 16. Dezember 2021 12:52:28 CET S.B. via Gnupg-users wrote: > > Here is my situation: I have imported a public key using > > gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys fingerprint* > > > > *provided by the intended recipient on their profile page > > > > The person also displayed the pgp public key block text (in armor) but > > not as an asc file. I first tried importing the block directly into > > gpg but couldn't figure it out. > > > > when comparing the imported key (again, obtained via the keyserver > > using the fingerprint) to the displayed public key block, they do not > > match. > > How do you do this, i.e. what commands are you using? > > > Reasons for this (I think) are: > > 1. either the fingerprint or the key has been changed but not updated > > on the profile page > > The fingerprint of an OpenPGP key never changes (except if its creation time > changes). > > Regards, > Ingo > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From kloecker at kde.org Thu Dec 16 16:49:28 2021 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Thu, 16 Dec 2021 16:49:28 +0100 Subject: fingerprint associated public key does not match displayed public key In-Reply-To: References: <1852328.iejboYy8mS@daneel> Message-ID: <1771108.0XmxmFt431@daneel> On Donnerstag, 16. Dezember 2021 16:37:30 CET S.B. via Gnupg-users wrote: > maybe I'm not explaining it well. Indeed. > I was able to import a public key using: > > gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys fingerprint* > > the fingerprint was provided to me by the intended recipient via their > profile page. > > the profile page also displayed the pgp public key block > > when i compared the imported pgp public key block (which I obtained > using the import command and the provided fingerprint) to the > displated pgp public key block, they didn't match > > shouldn't they match? I'm sorry, but I have no idea what you are comparing because you do not tell us how you get the "fingerprints" that you are comparing. If you do not want to give us more details because you want to protect the personal data of the intended recipient then that's completely understandable. But in this case you have to ask the intended recipient why the information provided by them on their profile page does not match what you get when you receive their key from the key server. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From rjh at sixdemonbag.org Thu Dec 16 17:11:35 2021 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 16 Dec 2021 11:11:35 -0500 Subject: fingerprint associated public key does not match displayed public key In-Reply-To: References: <1852328.iejboYy8mS@daneel> Message-ID: <47b175c3-b152-dd76-5a29-c5e2c541a4b8@sixdemonbag.org> > when i compared the imported pgp public key block (which I obtained > using the import command and the provided fingerprint) to the > displated pgp public key block, they didn't match > > shouldn't they match? No. The key block is not a human-readable format. It's a binary format that's meant to be read by computers. Imagine a word processing document. You open up a blank document and type "Hello, World!". You save that as document-1. Then you think about it, erase your text, write something else, delete that, too, and after some more hemming and hawing you go back to "Hello, World!". You save this as document-2. Now open up document-1 and document-2 in a hex editor. Despite the fact they have exactly the same *human-meaningful* information, the two documents will look different to a computer. Things like a timestamp for when it was last edited, things like a revision history, things like... etc. For all human purposes, document-1 and document-2 are the same. But they're different on disk, and that's okay. The exact same thing happens with OpenPGP certificates. When you import the certificate, GnuPG starts tracking other information -- the same way the word processor does. But that doesn't mean the certificate is *different*, really, not in any way you care about. Hope this helps! From telegraph at gmx.net Thu Dec 16 17:03:34 2021 From: telegraph at gmx.net (Gregor Zattler) Date: Thu, 16 Dec 2021 17:03:34 +0100 Subject: fingerprint associated public key does not match displayed public key In-Reply-To: References: <1852328.iejboYy8mS@daneel> Message-ID: <87ee6csfjd.fsf@no.workgroup> Hi S.B., * "S.B. via Gnupg-users" [2021-12-16; 10:37]: > maybe I'm not explaining it well. I was able to import a public key using: > > gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys fingerprint* > > the fingerprint was provided to me by the intended recipient via their > profile page. > > the profile page also displayed the pgp public key block > > when i compared the imported pgp public key block (which I obtained > using the import command and the provided fingerprint) to the > displated pgp public key block, they didn't match I assume you exported the public key you just downloaded from the key server with gpg --export --armor fingerprint? and then compared the output of this command to the key block shown on the web page? > shouldn't they match? then no, the do not need to match. The fingerpint is the fingerprint of the private signing key, while the key blocks in question are the public key with its signatures. At different times these may not match, because in between someone might have signed the public key. Then the public key block with this additional signature is different from the time before the signature was added. The signer might have mailed this public key block to the keys owner or to the key server and the key owner might or might not have imported this change to her/his public key and might have updated the website or perhaps not. Ciao; Gregor -- -... --- .-. . -.. ..--.. ...-.- From sami.badri at gmail.com Fri Dec 17 02:43:25 2021 From: sami.badri at gmail.com (S.B.) Date: Thu, 16 Dec 2021 20:43:25 -0500 Subject: fingerprint associated public key does not match displayed public key In-Reply-To: <47b175c3-b152-dd76-5a29-c5e2c541a4b8@sixdemonbag.org> References: <1852328.iejboYy8mS@daneel> <47b175c3-b152-dd76-5a29-c5e2c541a4b8@sixdemonbag.org> Message-ID: Thank you guys. This is helping. No, I did not export the key. Using the fingerprint, I downloaded the asc file from openpgp.org and placed it into my disk/users/SamiBadri, and then used the command: cat filename, to reveal the key block. That key block did not match the one on his profile. That?s what confused me. But I?m learning (from you guys) that the key blocks don?t necessarily have to match. So I can assume that: - the fingerprint is specific for the secret key component of the generated key pair and does not change. - the pgp public key is, in a way, fluid. It can take many different forms but encrypts specifically for the matching secret key only. The same public key can have different key blocks. - I could?ve used the keyserver-obtained public key (retrieved via the fingerprint), or I could?ve used the displayed public key that was given in armor text form. They are one and the same, even though their revealed text is different. Is all this correct? When you want to give someone your public key, do you normally just give your email, fingerprint, key ID, or the armor form key block? and... is there a command i could've used to directly import the key using the displayed key block? I've tried some different ones I found in various places but nothing worked. Thank you guys. S.B. On Thu, Dec 16, 2021 at 11:12 AM Robert J. Hansen via Gnupg-users wrote: > > > when i compared the imported pgp public key block (which I obtained > > using the import command and the provided fingerprint) to the > > displated pgp public key block, they didn't match > > > > shouldn't they match? > > No. > > The key block is not a human-readable format. It's a binary format > that's meant to be read by computers. > > Imagine a word processing document. You open up a blank document and > type "Hello, World!". You save that as document-1. Then you think > about it, erase your text, write something else, delete that, too, and > after some more hemming and hawing you go back to "Hello, World!". You > save this as document-2. > > Now open up document-1 and document-2 in a hex editor. Despite the fact > they have exactly the same *human-meaningful* information, the two > documents will look different to a computer. Things like a timestamp > for when it was last edited, things like a revision history, things > like... etc. > > For all human purposes, document-1 and document-2 are the same. But > they're different on disk, and that's okay. > > The exact same thing happens with OpenPGP certificates. When you import > the certificate, GnuPG starts tracking other information -- the same way > the word processor does. But that doesn't mean the certificate is > *different*, really, not in any way you care about. > > Hope this helps! > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From rjh at sixdemonbag.org Fri Dec 17 10:43:13 2021 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 17 Dec 2021 04:43:13 -0500 Subject: fingerprint associated public key does not match displayed public key In-Reply-To: References: <1852328.iejboYy8mS@daneel> <47b175c3-b152-dd76-5a29-c5e2c541a4b8@sixdemonbag.org> Message-ID: <6a247fe6-7b61-50ea-3e57-cb95a6f3946b@sixdemonbag.org> > That key block did not match the one on his profile. That?s what > confused me. But I?m learning (from you guys) that the key blocks > don?t necessarily have to match. So I can assume that: More accurately, they're very unlikely to match. The version on his site may lack some signatures or user IDs present on the keyserver copy, or vice-versa. Think of them as two different snapshots of the same document at different points in time, as various minor edits are made to it. But the important bits, the stuff you care about, will be consistent through revisions so long as the fingerprint remains unchanged. > - the fingerprint is specific for the secret key component of the > generated key pair and does not change. No, and I'm going to strongly encourage you to stop asking implementation questions. You're not ready for them. For now, learn how to use the system, and only then start paying attention to the fine detail of how the system is implemented. But if you insist, see section 12.2 of RFC4880. "A V4 fingerprint is the 160-bit SHA-1 hash of the octet 0x99, followed by the two-octet packet length, followed by the entire Public-Key packet starting with the version field. The Key ID is the low-order 64 bits of the fingerprint." > - the pgp public key is, in a way, fluid. It can take many different > forms but encrypts specifically for the matching secret key only. The > same public key can have different key blocks. No. This will probably become easier to understand if we use the correct language. *Keys* are not fluid. *Certificates* can be. What you're calling a "key block" is a certificate, not a key. A certificate includes cryptographic keys and metadata about those keys. The keys generally don't change (although I can think of pathological cases where they do). The metadata about those keys can change a lot. Most of the data in a certificate is metadata. > - I could?ve used the keyserver-obtained public key (retrieved via the > fingerprint), or I could?ve used the displayed public key that was > given in armor text form. They are one and the same, even though > their revealed text is different. You could have used it and the odds are quite good it wouldn't have mattered in the slightest. > When you want to give someone your public key, do you normally just > give your email, fingerprint, key ID, or the armor form key block? I use WKS. > is there a command i could've used to directly import the key using > the displayed key block? I've tried some different ones I found in > various places but nothing worked. gpg --import < certificate.asc From kloecker at kde.org Fri Dec 17 13:01:57 2021 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Fri, 17 Dec 2021 13:01:57 +0100 Subject: fingerprint associated public key does not match displayed public key In-Reply-To: References: <47b175c3-b152-dd76-5a29-c5e2c541a4b8@sixdemonbag.org> Message-ID: <6147132.XK5uJCGDXA@daneel> Please reply inline unless your email client makes this difficult. As you can see from the replies to your messages that's what we prefer on this mailing list. It helps to make the context of the replies more clear. There is a Frequently Asked Questions document that you may want to read if you haven't done so already: https://gnupg.org/faq/gnupg-faq.html On Freitag, 17. Dezember 2021 02:43:25 CET S.B. via Gnupg-users wrote: > When you want to give someone your public key, do you normally just > give your email, fingerprint, key ID, or the armor form key block? The easiest way is to use WKD/WKS (Web Key Directory/Service) if your email provider supports this because then some OpenPGP-aware automatically download your key when someone enters your email address into their email client. I don't think gmail supports WKD. Otherwise, you can simply send your exported key to the person you want to give your public key to. You may want to use the option "--export-options export-minimal" when exporting your key to keep the armor form key block small. It may also make sense to upload your key to some keyservers, so that people can get your key without first having to contact you. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From sami.badri at gmail.com Fri Dec 17 17:30:02 2021 From: sami.badri at gmail.com (S.B.) Date: Fri, 17 Dec 2021 11:30:02 -0500 Subject: fingerprint associated public key does not match displayed public key In-Reply-To: <6a247fe6-7b61-50ea-3e57-cb95a6f3946b@sixdemonbag.org> References: <1852328.iejboYy8mS@daneel> <47b175c3-b152-dd76-5a29-c5e2c541a4b8@sixdemonbag.org> <6a247fe6-7b61-50ea-3e57-cb95a6f3946b@sixdemonbag.org> Message-ID: > Think of them as two different snapshots of the same document at different points in time, as various minor edits are made to it. But the important bits, the stuff you care about, will be consistent through revisions so long as the fingerprint remains unchanged. The document snapshot analogy really helps. > No, and I'm going to strongly encourage you to stop asking implementation questions. I think I'll take that advice. > What you're calling a "key block" is a certificate, not a key. A certificate includes cryptographic keys and metadata about those keys. I'm getting the picture now. The pgp key block is really the certificate. The certificate holds the key and metadata. > gpg --import < certificate.asc So, when dealing with a displayed certificate (what I was calling a pgp public key block), the only method I thought of was copying and pasting it onto a txt file. But the import command doesn't work with txt. I was thinking of converting the txt to asc using a conversion app but then I knew that it can't be that difficult. If the only thing you have is the person's certificate, and it's not in an .asc format, is there any other way of importing it into your key ring? Or are all public key imports obtained via asc files? S.B. On Fri, Dec 17, 2021 at 4:43 AM Robert J. Hansen wrote: > > > That key block did not match the one on his profile. That?s what > > confused me. But I?m learning (from you guys) that the key blocks > > don?t necessarily have to match. So I can assume that: > > More accurately, they're very unlikely to match. The version on his > site may lack some signatures or user IDs present on the keyserver copy, > or vice-versa. Think of them as two different snapshots of the same > document at different points in time, as various minor edits are made to > it. But the important bits, the stuff you care about, will be > consistent through revisions so long as the fingerprint remains unchanged. > > > - the fingerprint is specific for the secret key component of the > > generated key pair and does not change. > > No, and I'm going to strongly encourage you to stop asking > implementation questions. You're not ready for them. For now, learn > how to use the system, and only then start paying attention to the fine > detail of how the system is implemented. > > But if you insist, see section 12.2 of RFC4880. "A V4 fingerprint is > the 160-bit SHA-1 hash of the octet 0x99, followed by the two-octet > packet length, followed by the entire Public-Key packet starting with > the version field. The Key ID is the low-order 64 bits of the fingerprint." > > > - the pgp public key is, in a way, fluid. It can take many different > > forms but encrypts specifically for the matching secret key only. The > > same public key can have different key blocks. > > No. This will probably become easier to understand if we use the > correct language. *Keys* are not fluid. *Certificates* can be. What > you're calling a "key block" is a certificate, not a key. A certificate > includes cryptographic keys and metadata about those keys. The keys > generally don't change (although I can think of pathological cases where > they do). The metadata about those keys can change a lot. > > Most of the data in a certificate is metadata. > > > - I could?ve used the keyserver-obtained public key (retrieved via the > > fingerprint), or I could?ve used the displayed public key that was > > given in armor text form. They are one and the same, even though > > their revealed text is different. > > You could have used it and the odds are quite good it wouldn't have > mattered in the slightest. > > > When you want to give someone your public key, do you normally just > > give your email, fingerprint, key ID, or the armor form key block? > > I use WKS. > > > is there a command i could've used to directly import the key using > > the displayed key block? I've tried some different ones I found in > > various places but nothing worked. > > gpg --import < certificate.asc From sami.badri at gmail.com Fri Dec 17 18:04:04 2021 From: sami.badri at gmail.com (S.B.) Date: Fri, 17 Dec 2021 12:04:04 -0500 Subject: fingerprint associated public key does not match displayed public key In-Reply-To: <6147132.XK5uJCGDXA@daneel> References: <47b175c3-b152-dd76-5a29-c5e2c541a4b8@sixdemonbag.org> <6147132.XK5uJCGDXA@daneel> Message-ID: > Please reply inline unless your email client makes this difficult. I will be doing that from now on. I'm not sure of any other way besides manually copying and pasting, but that's not a problem. > There is a Frequently Asked Questions document that you may want to read if you haven't done so already: I read the whole thing. It helped a little, but there was a lot that I just don't get (yet). I'll be reading through it again, along with the users archives, and the manual itself. I've started on a journey here, I see that. There's a lot to learn. But I am thrilled to learn it all. I do appreciate all the help. > The easiest way is to use WKD/WKS (Web Key Directory/Service) if your email provider supports this because then some OpenPGP-aware automatically download your key when someone enters your email address into their email client. I don't think gmail supports WKD. I'll look into a WKS/D supporting email provider. > Otherwise, you can simply send your exported key to the person you want to give your public key to. Yeah so, I can attach the .asc file that's in my Disk/users/SamiBadri folder (it's the only .asc file I've seen), but I'm assuming that is my public key. Is that correct? Is there anyway to send your private key? I want to know so that I don't do it accidentally. Also, if I use the cat SamiB.asc command, the terminal reveals a certificate (and I assume that's my public key certificate). Can I copy/paste and send that as a txt attachment? Will they be able to do anything with it? For instance, let's say they don't have my email, key ID, or fingerprint, only the pgp public key block (aka certificate), can you do anything with a txt-type file that only shows the certificate in armor? Lastly, I see that you have attached a signature .asc file with your email. I can import that file, and compare to? S.B. On Fri, Dec 17, 2021 at 7:02 AM Ingo Kl?cker wrote: > > Please reply inline unless your email client makes this difficult. As you can > see from the replies to your messages that's what we prefer on this mailing > list. It helps to make the context of the replies more clear. > > There is a Frequently Asked Questions document that you may want to read if > you haven't done so already: > https://gnupg.org/faq/gnupg-faq.html > > On Freitag, 17. Dezember 2021 02:43:25 CET S.B. via Gnupg-users wrote: > > When you want to give someone your public key, do you normally just > > give your email, fingerprint, key ID, or the armor form key block? > > The easiest way is to use WKD/WKS (Web Key Directory/Service) if your email > provider supports this because then some OpenPGP-aware automatically download > your key when someone enters your email address into their email client. I > don't think gmail supports WKD. > > Otherwise, you can simply send your exported key to the person you want to > give your public key to. You may want to use the option "--export-options > export-minimal" when exporting your key to keep the armor form key block > small. > > It may also make sense to upload your key to some keyservers, so that people > can get your key without first having to contact you. > > Regards, > Ingo > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From rjh at sixdemonbag.org Fri Dec 17 18:42:18 2021 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 17 Dec 2021 12:42:18 -0500 Subject: fingerprint associated public key does not match displayed public key In-Reply-To: References: <1852328.iejboYy8mS@daneel> <47b175c3-b152-dd76-5a29-c5e2c541a4b8@sixdemonbag.org> <6a247fe6-7b61-50ea-3e57-cb95a6f3946b@sixdemonbag.org> Message-ID: > The document snapshot analogy really helps. I'm glad it's helped! >> No, and I'm going to strongly encourage you to stop asking > implementation questions. > > I think I'll take that advice. When you think you're ready, we'll be here to answer your implementation questions. It would break my heart if you thought you should never ask them -- I just, only, think that diving into implementation details is almost always a bad idea for new users. If you want to teach someone poetry you start by showing them the witty banter and playful puns in Shakespeare, and encourage them to laugh and enjoy the show. Learning about iambic pentameter can wait. :) > I'm getting the picture now. The pgp key block is really the > certificate. The certificate holds the key and metadata. Key(s): a certificate holds at least one, but usually more than one. Beyond that minor detail you've got it perfect. >> gpg --import < certificate.asc > > So, when dealing with a displayed certificate (what I was calling a > pgp public key block), the only method I thought of was copying and > pasting it onto a txt file. But the import command doesn't work with > txt. Sure it does. I did that no more than twenty minutes ago myself. How were you trying to do this? From sami.badri at gmail.com Sat Dec 18 02:46:18 2021 From: sami.badri at gmail.com (S.B.) Date: Fri, 17 Dec 2021 20:46:18 -0500 Subject: fingerprint associated public key does not match displayed public key In-Reply-To: References: <1852328.iejboYy8mS@daneel> <47b175c3-b152-dd76-5a29-c5e2c541a4b8@sixdemonbag.org> <6a247fe6-7b61-50ea-3e57-cb95a6f3946b@sixdemonbag.org> Message-ID: > Key(s): a certificate holds at least one, but usually more than one. I see. So, a certificate (aka pgp public key block) holds at least one key (+ pertinent metadata that changes/updates depending on use, etc.), but usually more. What other keys would it hold? The paired secret key? No. Other public keys in my key ring? Unlikely. If the certificate is made for encryption of a message that only one specific secret key can decrypt. Why would it hold more than one key? >> But the import command doesn't work with txt. > Sure it does. I did that no more than twenty minutes ago myself. So I typed the gpg --import > certificate.txt command and it says "no such file or directory: certificate.txt" (certificate has a different name of course). I placed the file in my .gnupg hidden folder. Here is really the root of my problem. As you probably know, I'm not using a Web Key Service/Directory enabled email provider, so if I were to get an encrypted message intended for me, I'd have to copy the encryption text, paste it into txt file, then import/decrypt it like that with: gpg --decrypt ~/Desktop/encryptedfile.txt | perl -MMIME::QuotedPrint -0777 -nle 'print decode_qp($_)' That's a command I found online from a source that I've been using for learning pgp. What am I missing? Does this only work well with WKS/D enabled message services? On Fri, Dec 17, 2021 at 12:42 PM Robert J. Hansen wrote: > > > The document snapshot analogy really helps. > > I'm glad it's helped! > > >> No, and I'm going to strongly encourage you to stop asking > > implementation questions. > > > > I think I'll take that advice. > > When you think you're ready, we'll be here to answer your implementation > questions. It would break my heart if you thought you should never ask > them -- I just, only, think that diving into implementation details is > almost always a bad idea for new users. > > If you want to teach someone poetry you start by showing them the witty > banter and playful puns in Shakespeare, and encourage them to laugh and > enjoy the show. Learning about iambic pentameter can wait. :) > > > I'm getting the picture now. The pgp key block is really the > > certificate. The certificate holds the key and metadata. > > Key(s): a certificate holds at least one, but usually more than one. > Beyond that minor detail you've got it perfect. > > >> gpg --import < certificate.asc > > > > So, when dealing with a displayed certificate (what I was calling a > > pgp public key block), the only method I thought of was copying and > > pasting it onto a txt file. But the import command doesn't work with > > txt. > > Sure it does. I did that no more than twenty minutes ago myself. > > How were you trying to do this? From rjh at sixdemonbag.org Sat Dec 18 03:24:15 2021 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 17 Dec 2021 21:24:15 -0500 Subject: fingerprint associated public key does not match displayed public key In-Reply-To: References: <1852328.iejboYy8mS@daneel> <47b175c3-b152-dd76-5a29-c5e2c541a4b8@sixdemonbag.org> <6a247fe6-7b61-50ea-3e57-cb95a6f3946b@sixdemonbag.org> Message-ID: <33c91806-5ff0-2a81-209b-c224eaf8b8a6@sixdemonbag.org> > What other keys would it hold? Behold: pub ed25519/1E7A94D4E87F91D5 2021-02-22 [SC] 7D8EC4B85B6FEDD6C10D3C791E7A94D4E87F91D5 uid [ultimate] Robert J. Hansen uid [ultimate] Robert J. Hansen sub cv25519/7D6CCDB66CA1202F 2021-02-22 [E] My public certificate has two keys: an Edwards-25519 signing key and a Curve-25519 encryption key. Back in the '90s, certificates almost always held a single key that was used for both encryption and signing. Then we realized, "if the courts force us to give our decryption key to the cops so they can read our traffic, we're also giving them the ability to impersonate us." Since then, virtually every OpenPGP certificate has had at least two keys: one for signing and one for encryption. There are cases where three or more keys are appropriate, but they're kind of outside the scope of the current discussion. >> Sure it does. I did that no more than twenty minutes ago myself. > > So I typed the gpg --import > certificate.txt command and it says "no > such file or directory: certificate.txt" (certificate has a different > name of course). Did you notice the command is "gpg --import < certificate.txt"? > I placed the file in my .gnupg hidden folder. Then you'd need to do "gpg --import < ~/.gnupg/certificate.txt". If certificate.txt isn't in your current directory, you need to tell Linux where to look for it. > Here is really the root of my problem. As you probably know, I'm not > using a Web Key Service/Directory enabled email provider, so if I were > to get an encrypted message intended for me, I'd have to copy the > encryption text, paste it into txt file, then import/decrypt it like > that with: gpg --decrypt ~/Desktop/encryptedfile.txt | perl > -MMIME::QuotedPrint -0777 -nle 'print decode_qp($_)' That's shockingly bad. Try using an email client with OpenPGP support built-in. On Linux the two major choices are Evolution and Thunderbird. > That's a command I found online from a source that I've been using for > learning pgp. Please stop using that resource. As mentioned above, it's shockingly bad. As the FAQ says, "The good news is the internet is a treasure trove of information. The bad news is that the internet is a festering sewer of misinformation, conspiracy theories, and half-informed speculations all masquerading as informed commentary." From andrewg at andrewg.com Sat Dec 18 10:02:39 2021 From: andrewg at andrewg.com (Andrew Gallagher) Date: Sat, 18 Dec 2021 09:02:39 +0000 Subject: fingerprint associated public key does not match displayed public key In-Reply-To: <33c91806-5ff0-2a81-209b-c224eaf8b8a6@sixdemonbag.org> References: <33c91806-5ff0-2a81-209b-c224eaf8b8a6@sixdemonbag.org> Message-ID: > On 18 Dec 2021, at 02:25, Robert J. Hansen via Gnupg-users wrote: > > As the FAQ says, "The good news is the internet is a treasure trove of information. The bad news is that the internet is a festering sewer of misinformation, conspiracy theories, and half-informed speculations all masquerading as informed commentary." Indeed. The internet is also full of articles that haven?t been updated since before the iPhone was invented, and thus are *at best* so technologically outdated they might as well be written in hieroglyphics? A From kloecker at kde.org Sat Dec 18 19:07:35 2021 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Sat, 18 Dec 2021 19:07:35 +0100 Subject: fingerprint associated public key does not match displayed public key In-Reply-To: References: <6147132.XK5uJCGDXA@daneel> Message-ID: <2133426.79vsZ0q33Q@breq> On Freitag, 17. Dezember 2021 18:04:04 CET S.B. via Gnupg-users wrote: > > Otherwise, you can simply send your exported key to the person you want to > > give your public key to. > > Yeah so, I can attach the .asc file that's in my Disk/users/SamiBadri > folder (it's the only .asc file I've seen), but I'm assuming that is > my public key. Is that correct? Well, it depends. We have no idea what the .asc file in Disk/users/SamiBadri contains. It could be your public key. Or it could be somebody else's public key. Or it could be something other than a public key. Quite frankly, I suggest that you follow Robert's advice and start your learning experience with OpenPGP by using an email client that supports OpenPGP out-of-the-box. All decent email clients should have a functionality to attach your public key to an email without you having to attach some file manually. > Is there anyway to send your private key? Sure. You can send any file to anyone, so, of course, you can do the same with your private key (unless it's stored on a smartcard in a read-protected slot). A decent email client should not offer a functionality to attach your secret key to an email. So, if you stick to what your email client offers you, then you should be safe. > I want to know so that I don't do it accidentally. Then don't attach random files you find on your disk to your emails without knowing what those files contain. > Also, if I > use the cat SamiB.asc command, the terminal reveals a certificate (and > I assume that's my public key certificate). You shouldn't assume anything if you are dealing with encryption software. You should be sure what you are doing. Otherwise, in the extreme, you could jeopardize the lives of other people. > Can I copy/paste and send > that as a txt attachment? Will they be able to do anything with it? > For instance, let's say they don't have my email, key ID, or > fingerprint, only the pgp public key block (aka certificate), can you > do anything with a txt-type file that only shows the certificate in > armor? If you send someone the public key block of your public key, e.g. some file that contains something like -----BEGIN PGP PUBLIC KEY BLOCK----- [...] -----END PGP PUBLIC KEY BLOCK----- then this person can import your public key in their keyring and use it to verify signatures made by you and to encrypt text or files for you. You can use the command gpg --show-key Lastly, I see that you have attached a signature .asc file with your > email. I can import that file, and compare to? No, you cannot import that file. You need an email client that supports OpenPGP to do anything useful with it. Alternatively, you could have a look at Mailvelope (https://mailvelope.com). It's a browser add-on that will extend GMail (and many other webmail providers) with OpenPGP support. 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 sami.badri at gmail.com Sun Dec 19 03:44:46 2021 From: sami.badri at gmail.com (S.B.) Date: Sat, 18 Dec 2021 21:44:46 -0500 Subject: fingerprint associated public key does not match displayed public key In-Reply-To: <33c91806-5ff0-2a81-209b-c224eaf8b8a6@sixdemonbag.org> References: <1852328.iejboYy8mS@daneel> <47b175c3-b152-dd76-5a29-c5e2c541a4b8@sixdemonbag.org> <6a247fe6-7b61-50ea-3e57-cb95a6f3946b@sixdemonbag.org> <33c91806-5ff0-2a81-209b-c224eaf8b8a6@sixdemonbag.org> Message-ID: > Did you notice the command is "gpg --import < certificate.txt"? Yes, sorry. I did type the command correctly. >> I placed the file in my .gnupg hidden folder. > > Then you'd need to do "gpg --import < ~/.gnupg/certificate.txt". If certificate.txt isn't in your current directory, you need to tell Linux where to look for it. It worked. I placed the txt file (copied and pasted) certificate in my .gnugp folder and it went through. > Please stop using that resource. As mentioned above, it's shockingly bad. To be fair. The resource didn't actually tell me to do it that way. It only supplied me with the command. The method was my roundabout way of making it work (based on my underivative understanding). It seems as though my entry into this realm was clearly... bad. I wanted to learn the system without using separate encryption software like kleopatra. I wanted to know how to do it with just gpg and any email provider. It's difficult, and I have a lot to learn. and... I was hoping that, since I have your email, key ID, and fingerprint ;) I could write an encrypted message to your sixdemonbag email. I'd completely understand if you'd rather not. I just have now found myself luring friends and relatives into learning this with me and exchanging encrypted emails and... it's not going well. > On Fri, Dec 17, 2021 at 9:24 PM Robert J. Hansen wrote: > > > What other keys would it hold? > > Behold: > > pub ed25519/1E7A94D4E87F91D5 2021-02-22 [SC] > 7D8EC4B85B6FEDD6C10D3C791E7A94D4E87F91D5 > uid [ultimate] Robert J. Hansen > uid [ultimate] Robert J. Hansen > sub cv25519/7D6CCDB66CA1202F 2021-02-22 [E] > > > My public certificate has two keys: an Edwards-25519 signing key and a > Curve-25519 encryption key. > > Back in the '90s, certificates almost always held a single key that was > used for both encryption and signing. Then we realized, "if the courts > force us to give our decryption key to the cops so they can read our > traffic, we're also giving them the ability to impersonate us." Since > then, virtually every OpenPGP certificate has had at least two keys: one > for signing and one for encryption. > > There are cases where three or more keys are appropriate, but they're > kind of outside the scope of the current discussion. > > >> Sure it does. I did that no more than twenty minutes ago myself. > > > > So I typed the gpg --import > certificate.txt command and it says "no > > such file or directory: certificate.txt" (certificate has a different > > name of course). > > Did you notice the command is "gpg --import < certificate.txt"? > > > I placed the file in my .gnupg hidden folder. > > Then you'd need to do "gpg --import < ~/.gnupg/certificate.txt". If > certificate.txt isn't in your current directory, you need to tell Linux > where to look for it. > > > Here is really the root of my problem. As you probably know, I'm not > > using a Web Key Service/Directory enabled email provider, so if I were > > to get an encrypted message intended for me, I'd have to copy the > > encryption text, paste it into txt file, then import/decrypt it like > > that with: gpg --decrypt ~/Desktop/encryptedfile.txt | perl > > -MMIME::QuotedPrint -0777 -nle 'print decode_qp($_)' > > That's shockingly bad. > > Try using an email client with OpenPGP support built-in. On Linux the > two major choices are Evolution and Thunderbird. > > > That's a command I found online from a source that I've been using for > > learning pgp. > > Please stop using that resource. As mentioned above, it's shockingly bad. > > As the FAQ says, "The good news is the internet is a treasure trove of > information. The bad news is that the internet is a festering sewer of > misinformation, conspiracy theories, and half-informed speculations all > masquerading as informed commentary." From sami.badri at gmail.com Sun Dec 19 04:42:24 2021 From: sami.badri at gmail.com (S.B.) Date: Sat, 18 Dec 2021 22:42:24 -0500 Subject: fingerprint associated public key does not match displayed public key In-Reply-To: <2133426.79vsZ0q33Q@breq> References: <6147132.XK5uJCGDXA@daneel> <2133426.79vsZ0q33Q@breq> Message-ID: > Well, it depends. We have no idea what the .asc file in Disk/users/SamiBadri contains. It could be your public key. Or it could be somebody else's public key. Or it could be something other than a public key. That was my mistake. When I generated my first key pair I used the command: gpg --armor --export sami.badri at gmail.com> ~/Desktop/SamiB.asc I moved it into my user folder. That's the file I uploaded to openpgp.org. It is the public key block. > You shouldn't assume anything if you are dealing with encryption software. You should be sure what you are doing. Otherwise, in the extreme, you could jeopardize the lives of other people. I absolutely understand. > You can use the command gpg --show-key But, as with using a proper email client you should probably also use a proper graphical tool for working with GnuPG. On Linux, I suggest using Kleopatra. On Windows, I recommend gpg4win. I'm researching other email clients and will definitely get a GnuPG graphical tool. PGP Tool for Mac looks ok. > Alternatively, you could have a look at Mailvelope (https://mailvelope.com). It's a browser add-on that will extend GMail (and many other webmail providers) with OpenPGP support. I'm looking at Mailvelope and FlowCrypt for Gmail extensions. On Sat, Dec 18, 2021 at 3:23 PM Ingo Kl?cker wrote: > > On Freitag, 17. Dezember 2021 18:04:04 CET S.B. via Gnupg-users wrote: > > > Otherwise, you can simply send your exported key to the person you want to > > > give your public key to. > > > > Yeah so, I can attach the .asc file that's in my Disk/users/SamiBadri > > folder (it's the only .asc file I've seen), but I'm assuming that is > > my public key. Is that correct? > > Well, it depends. We have no idea what the .asc file in Disk/users/SamiBadri > contains. It could be your public key. Or it could be somebody else's public > key. Or it could be something other than a public key. > > Quite frankly, I suggest that you follow Robert's advice and start your > learning experience with OpenPGP by using an email client that supports > OpenPGP out-of-the-box. All decent email clients should have a functionality > to attach your public key to an email without you having to attach some file > manually. > > > Is there anyway to send your private key? > > Sure. You can send any file to anyone, so, of course, you can do the same with > your private key (unless it's stored on a smartcard in a read-protected slot). > > A decent email client should not offer a functionality to attach your secret > key to an email. So, if you stick to what your email client offers you, then > you should be safe. > > > I want to know so that I don't do it accidentally. > > Then don't attach random files you find on your disk to your emails without > knowing what those files contain. > > > Also, if I > > use the cat SamiB.asc command, the terminal reveals a certificate (and > > I assume that's my public key certificate). > > You shouldn't assume anything if you are dealing with encryption software. You > should be sure what you are doing. Otherwise, in the extreme, you could > jeopardize the lives of other people. > > > Can I copy/paste and send > > that as a txt attachment? Will they be able to do anything with it? > > For instance, let's say they don't have my email, key ID, or > > fingerprint, only the pgp public key block (aka certificate), can you > > do anything with a txt-type file that only shows the certificate in > > armor? > > If you send someone the public key block of your public key, e.g. some file > that contains something like > > -----BEGIN PGP PUBLIC KEY BLOCK----- > > [...] > -----END PGP PUBLIC KEY BLOCK----- > > then this person can import your public key in their keyring and use it to > verify signatures made by you and to encrypt text or files for you. > > You can use the command > gpg --show-key to have a look at the key (or keys) contained in SamiB.asc. But, as with using > a proper email client you should probably also use a proper graphical tool for > working with GnuPG. On Linux, I suggest using Kleopatra. On Windows, I > recommend gpg4win. > > > Lastly, I see that you have attached a signature .asc file with your > > email. I can import that file, and compare to? > > No, you cannot import that file. You need an email client that supports > OpenPGP to do anything useful with it. > > Alternatively, you could have a look at Mailvelope (https://mailvelope.com). > It's a browser add-on that will extend GMail (and many other webmail > providers) with OpenPGP support. > > Regards, > Ingo > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From rjh at sixdemonbag.org Mon Dec 20 22:51:04 2021 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 20 Dec 2021 16:51:04 -0500 Subject: fingerprint associated public key does not match displayed public key In-Reply-To: References: <1852328.iejboYy8mS@daneel> <47b175c3-b152-dd76-5a29-c5e2c541a4b8@sixdemonbag.org> <6a247fe6-7b61-50ea-3e57-cb95a6f3946b@sixdemonbag.org> <33c91806-5ff0-2a81-209b-c224eaf8b8a6@sixdemonbag.org> Message-ID: <179f1587-3421-d406-bccc-eac0ff676abc@sixdemonbag.org> > seems as though my entry into this realm was clearly... bad. I wanted > to learn the system without using separate encryption software like > kleopatra. I wanted to know how to do it with just gpg and any email > provider. It's difficult, and I have a lot to learn. Don't do that. Seriously. This is like saying "I want to learn how to farm like my grandparents did!" Farming is hard enough: voluntarily doing without, you know, *electricity* is just crazy. (In the United States, many farms were without electricity until the 1940s!) These easy-to-use tools exist for a reason: to make GnuPG easy to use. If you insist on doing things the hard way you have only yourself to blame. First learn how to use GnuPG, and then figure out how to use GnuPG like you would if it was 1992 after you've got your basic skills down. > and... I was hoping that, since I have your email, key ID, and fingerprint ;) > I could write an encrypted message to your sixdemonbag email. I'd > completely understand if you'd rather not. I just have now found > myself luring friends and relatives into learning this with me and > exchanging encrypted emails and... it's not going well. You may want to check out a mailing list like PGPNET, which exists specifically to give people experience in sending/receiving encrypted mail. :) From wk at gnupg.org Mon Dec 20 23:26:35 2021 From: wk at gnupg.org (Werner Koch) Date: Mon, 20 Dec 2021 23:26:35 +0100 Subject: [Announce] GnuPG 2.3.4 released Message-ID: <87y24eq5es.fsf@wheatstone.g10code.de> Hello! 24 years after the first public release we are pleased to announce the availability of a new GnuPG release: version 2.3.4. This is the fifth release in the new 2.3 series which introduces a few new options and and fixes some bugs. See below for details. 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 series of GnuPG are actively maintained: - Version 2.3 is the current stable version with a lot of new features compared to 2.2. This announcement is about the latest release of this series. - 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 only 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.4 (2021-12-20) ================================================ * gpg: New option --min-rsa-length. [rG5f39db70c0] * gpg: New option --forbid-gen-key. [rGc397ba3ac0] * gpg: New option --override-compliance-check. [T5655] * gpgconf: New command --show-configs. [rGa0fb78ee0f] * agent,dirmngr,keyboxd: New option --steal-socket. [rGb0079ab39d,rGdd708f60d5] * gpg: Fix printing of binary notations. [T5667] * gpg: Remove stale ultimately trusted keys from the trustdb. [T5685,T5742] * gpg: Fix indentation of --print-mds and --print-md sha512. [T5679] * gpg: Emit gpg 2.2 compatible Ed25519 signature. [T5331] * gpgsm: Detect circular chains in --list-chain. [rG74c5b35062] * dirmngr: Make reading resolv.conf more robust. [T5657] * dirmngr: Ask keyservers to provide the key fingerprints. [T5741] * gpgconf: Allow changing gpg's deprecated keyserver option. [T5462] * gpg-wks-server: Fix created file permissions. [rG60be00b033] * scd: Support longer data for ssh-agent authentication with openpgp cards. [T5682] * scd: Modify DEVINFO behavior to support looping forever. [T5359] * Support gpgconf.ctl for NetBSD and Solaris. [T5656,T5671] * Silence "Garbled console data" warning under Windows in most cases. [rGe293da3b21] * Silence warning about the rootdir under Unices w/o a mounted /proc file system. [T5656] * Fix possible build problems about missing include files. [T5592] Release-info: https://dev.gnupg.org/T5654 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.4.tar.bz2 (7411k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.3.4.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.4_20211220.exe (4708k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.3.4_20211220.exe.sig The source used to build the Windows installer can be found in the same directory with a ".tar.xz" suffix. 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.4.tar.bz2 you would use this command: gpg --verify gnupg-2.3.4.tar.bz2.sig gnupg-2.3.4.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.4.tar.bz2, you run the command like this: sha1sum gnupg-2.3.4.tar.bz2 and check that the output matches the next line: 436823f57b8387ece6053d9a395374243d64feff gnupg-2.3.4.tar.bz2 c1443f71a2be02a4ab30027e2ec6336dd08fdc26 gnupg-w32-2.3.4_20211220.tar.xz 2af6d08717f5367f1e8c7306bd10f8a20ef9ebdc gnupg-w32-2.3.4_20211220.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/T5654 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 has mostly been 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. Fortunately, and this is still not common with free software, we have now established a way of financing the development while keeping all our software free and freely available for everyone. Our model is similar to the way RedHat manages RHEL and Fedora: Except for the actual binary of the MSI installer for Windows and client specific configuration files, all the software is available under the GNU GPL and other Open Source licenses. Thus customers may even build and distribute their own version of the software as long as they do not use our trademark GnuPG VS-Desktop?. 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, answering questions on the mailing lists, or helping with donations. *Thank you all* Your GnuPG hackers p.s Those of you with standing SEPA donations, please cancel them or consider to redirect your funds to other projects which are more in need of financial support. The donations done via Stripe or PayPal have already been canceled. 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: rsa3072 2017-03-17 [expires: 2027-03-15] 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28 Andre Heinecke (Release Signing Key) ed25519 2020-08-24 [expires: 2030-06-30] 6DAA 6E64 A76D 2840 571B 4902 5288 97B8 2640 3ADA Werner Koch (dist signing 2020) ed25519 2021-05-19 [expires: 2027-04-04] AC8E 115B F73E 2D8D 47FA 9908 E98E 9B2D 19C6 C8BD Niibe Yutaka (GnuPG Release Key) brainpoolP256r1 2021-10-15 [expires: 2029-12-31] 02F3 8DFF 731F F97C B039 A1DA 549E 695E 905B A208 GnuPG.com (Release Signing Key 2021) The keys are available at https://gnupg.org/signature_key.html and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. -- Please read Nils Melzer: Der Fall Julian Assange It is really important to know the background of the Assange case to understand the massive perils to free journalism. The book is right now only available in German: https://dev.gnupg.org/u/melzerassang -------------- 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 jrf at mailbox.org Tue Dec 21 11:39:51 2021 From: jrf at mailbox.org (Rainer Fiebig) Date: Tue, 21 Dec 2021 11:39:51 +0100 Subject: fingerprint associated public key does not match displayed public key In-Reply-To: <2133426.79vsZ0q33Q@breq> References: <6147132.XK5uJCGDXA@daneel> <2133426.79vsZ0q33Q@breq> Message-ID: Am 18.12.21 um 19:07 schrieb Ingo Kl?cker: > On Freitag, 17. Dezember 2021 18:04:04 CET S.B. via Gnupg-users wrote: >>> Otherwise, you can simply send your exported key to the person you want to >>> give your public key to. >> >> Yeah so, I can attach the .asc file that's in my Disk/users/SamiBadri >> folder (it's the only .asc file I've seen), but I'm assuming that is >> my public key. Is that correct? > > Well, it depends. We have no idea what the .asc file in Disk/users/SamiBadri > contains. It could be your public key. Or it could be somebody else's public > key. Or it could be something other than a public key. > > Quite frankly, I suggest that you follow Robert's advice and start your > learning experience with OpenPGP by using an email client that supports > OpenPGP out-of-the-box. All decent email clients should have a functionality > to attach your public key to an email without you having to attach some file > manually. > >> Is there anyway to send your private key? > > Sure. You can send any file to anyone, so, of course, you can do the same with > your private key (unless it's stored on a smartcard in a read-protected slot). > > A decent email client should not offer a functionality to attach your secret > key to an email. So, if you stick to what your email client offers you, then > you should be safe. > >> I want to know so that I don't do it accidentally. > > Then don't attach random files you find on your disk to your emails without > knowing what those files contain. > >> Also, if I >> use the cat SamiB.asc command, the terminal reveals a certificate (and >> I assume that's my public key certificate). > > You shouldn't assume anything if you are dealing with encryption software. You > should be sure what you are doing. Otherwise, in the extreme, you could > jeopardize the lives of other people. > And then there's the one you're communicating with. Also make sure that *he* knows what he is doing. Otherwise you might jeopardize your own life. For example: Someone who replies to your top secret, perfectly encrypted mail - without encrypting his reply. ;) Rainer From sami.badri at gmail.com Wed Dec 22 12:41:33 2021 From: sami.badri at gmail.com (S.B.) Date: Wed, 22 Dec 2021 06:41:33 -0500 Subject: fingerprint associated public key does not match displayed public key In-Reply-To: <179f1587-3421-d406-bccc-eac0ff676abc@sixdemonbag.org> References: <1852328.iejboYy8mS@daneel> <47b175c3-b152-dd76-5a29-c5e2c541a4b8@sixdemonbag.org> <6a247fe6-7b61-50ea-3e57-cb95a6f3946b@sixdemonbag.org> <33c91806-5ff0-2a81-209b-c224eaf8b8a6@sixdemonbag.org> <179f1587-3421-d406-bccc-eac0ff676abc@sixdemonbag.org> Message-ID: > Don't do that. Seriously. This is like saying "I want to learn how to > farm like my grandparents did!" Farming is hard enough: voluntarily > doing without, you know, *electricity* is just crazy. (In the United > States, many farms were without electricity until the 1940s!) > These easy-to-use tools exist for a reason: to make GnuPG easy to use. > If you insist on doing things the hard way you have only yourself to > blame. First learn how to use GnuPG, and then figure out how to use > GnuPG like you would if it was 1992 after you've got your basic skills down. Haha. You're good with these. I don't want to be farming without electricity. You may want to check out a mailing list like PGPNET, which exists specifically to give people experience in sending/receiving encrypted mail. :) > I immediately did it. I saw you there. Using Thunderbird. Figuring it out. Thank you all for all the good advice. S.B. On Mon, Dec 20, 2021 at 4:50 PM Robert J. Hansen wrote: > > > seems as though my entry into this realm was clearly... bad. I wanted > > to learn the system without using separate encryption software like > > kleopatra. I wanted to know how to do it with just gpg and any email > > provider. It's difficult, and I have a lot to learn. > > Don't do that. Seriously. This is like saying "I want to learn how to > farm like my grandparents did!" Farming is hard enough: voluntarily > doing without, you know, *electricity* is just crazy. (In the United > States, many farms were without electricity until the 1940s!) > > These easy-to-use tools exist for a reason: to make GnuPG easy to use. > If you insist on doing things the hard way you have only yourself to > blame. First learn how to use GnuPG, and then figure out how to use > GnuPG like you would if it was 1992 after you've got your basic skills down. > > > and... I was hoping that, since I have your email, key ID, and fingerprint ;) > > I could write an encrypted message to your sixdemonbag email. I'd > > completely understand if you'd rather not. I just have now found > > myself luring friends and relatives into learning this with me and > > exchanging encrypted emails and... it's not going well. > > You may want to check out a mailing list like PGPNET, which exists > specifically to give people experience in sending/receiving encrypted > mail. :) From benoit at neviani.fr Wed Dec 22 14:47:10 2021 From: benoit at neviani.fr (=?utf-8?Q?Beno=C3=AEt?=) Date: Wed, 22 Dec 2021 14:47:10 +0100 Subject: Curve25519 key generation on GnuPG card or import key to the card failures Message-ID: <20211222134710.GA6719@x1.localdomain> I got 3x OpenPGP Smart Card v3.3 and I am unable to generate Curve25519 on the card nor importing a cv/ev25519 to it. When importing a cv/ev25519, I got gpg : KEYTOCARD failed : Invalid value. When I try to use key-attr option from gpg --card-edit, I got two options : Curve25519 and nsit-384. nsit-384 is fine for both generation or import but nor generation or import are working with Curve25519. I can see on the release note that v3.3.1 fixes "Error correction of Algorithm IDs for ECDSA and ECDH" but I don't have more details so I have a doubt that this would solve my issue. Any idea where this could come from ? I am also surprised to only have two options for key-attr from gpg --card-edit as Curve25519 should only be available for E, (ed25519 for A,S,C). OpenPGP Smart Card v3.3 gnupg 2.2.31 Thanks -- blt From wk at gnupg.org Wed Dec 22 16:46:52 2021 From: wk at gnupg.org (Werner Koch) Date: Wed, 22 Dec 2021 16:46:52 +0100 Subject: Curve25519 key generation on GnuPG card or import key to the card failures In-Reply-To: <20211222134710.GA6719@x1.localdomain> (=?utf-8?Q?=22Beno?= =?utf-8?Q?=C3=AEt?= via Gnupg-users"'s message of "Wed, 22 Dec 2021 14:47:10 +0100") References: <20211222134710.GA6719@x1.localdomain> Message-ID: <87y24ciqvn.fsf@wheatstone.g10code.de> On Wed, 22 Dec 2021 14:47, Beno?t said: > I got 3x OpenPGP Smart Card v3.3 and I am unable to generate Curve25519 > on the card nor importing a cv/ev25519 to it. Whether this is supported depends on the type of the card. The Gnuk and newer Yubikeys support curve25519 but the Zeitcontrol card does not yet. With the Zeitcontrol cards of version 3.3 you may use the NIST and with 3.4 also Brainpool curves. 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 benoit at neviani.fr Wed Dec 22 20:08:31 2021 From: benoit at neviani.fr (=?utf-8?Q?Beno=C3=AEt?=) Date: Wed, 22 Dec 2021 20:08:31 +0100 Subject: Curve25519 key generation on GnuPG card or import key to the card failures In-Reply-To: <87y24ciqvn.fsf@wheatstone.g10code.de> References: <20211222134710.GA6719@x1.localdomain> <87y24ciqvn.fsf@wheatstone.g10code.de> Message-ID: <20211222190831.GA25600@x1.localdomain> Thanks Werner! So it is simply a compatibility issue with Zeitcontrol ! Do you have any info on the future Zeitcontrol 3.5 version and the potential compatibility with Curve25519 ? On Wed, Dec 22, 2021 at 04:46:52PM +0100, Werner Koch wrote: >On Wed, 22 Dec 2021 14:47, Beno?t said: >> I got 3x OpenPGP Smart Card v3.3 and I am unable to generate Curve25519 >> on the card nor importing a cv/ev25519 to it. > >Whether this is supported depends on the type of the card. The Gnuk and >newer Yubikeys support curve25519 but the Zeitcontrol card does not >yet. With the Zeitcontrol cards of version 3.3 you may use the NIST and >with 3.4 also Brainpool curves. > > >Shalom-Salam, > > Werner > >-- >Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -- Beno?t From bernhard at intevation.de Thu Dec 23 11:00:06 2021 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 23 Dec 2021 11:00:06 +0100 Subject: GnuPG / Mailvelope on Windows 11 In-Reply-To: References: Message-ID: <202112231100.17201.bernhard@intevation.de> Hello, Am Mittwoch 15 Dezember 2021 13:07:21 schrieb Rhetoric Bohling via Gnupg-users: > I recently was in a loop trying to figure out GnuPG on Windows 10/11. Can > you natively use GnuPG? yes, you can use GnuPG natively build on Windows, either with a graphical or a command line interface. The official distribution of GnuPG is included in www.gpg4win.org For some use cases, there is also a crypto-engine only "simple" installer availalbe from https://gnupg.org/download/index.html see section of binary releases on this page. > Or is it limited to the few implementations of it > through Kleapatra/etc.?pgp. Kleopatra is one of several applications that use the native GnuPG installation on Windows. The Outlook add-in, the explorer plugin also use it. (Because GnuPG implements open standards like OpenPGP or the Cryptographic Message Syntax, it is interoperable with other implementations of those standards.) > I was using Mailvelope, and I could not get the Mailvelope app to recognize > I was using GnuPG. It kept saying OpenPGP. I am confused. Mailvelope uses an OpenPGP implementation called OpenPGP.js by default, because it is fully implemented in Javascript. There is the possibility to use GnuPG as backend to Mailvelope, but you need to activate it, see https://github.com/mailvelope/mailvelope/wiki/Mailvelope-GnuPG-integration (Both backend "OpenPGP.js" and "GnuPG" implement "OpenPGP". :) ) 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 alex.nadtoka at gmail.com Thu Dec 23 11:37:36 2021 From: alex.nadtoka at gmail.com (Alex Nadtoka) Date: Thu, 23 Dec 2021 12:37:36 +0200 Subject: issue with gpg4win Message-ID: > > I cannot connect to any keyserver. The error is certificate expired. Here > is Debug log. I am on latest (I think) Windows 10 2021-12-23 11:27:15 gpg[17680] using character set 'utf-8' 2021-12-23 11:27:15 gpg[17680] Note: RFC4880bis features are enabled. 2021-12-23 11:27:15 gpg[17680] enabled debug flags: packet mpi crypto filter iobuf memory cache memstat trust hashing ipc clock lookup extprog 2021-12-23 11:27:15 gpg[17680] DBG: [no clock] start 2021-12-23 11:27:15 gpg[17680] using pgp trust model 2021-12-23 11:27:15 gpg[17680] key F82A7011A81784E3: accepted as trusted key 2021-12-23 11:27:15 gpg[17680] DBG: [no clock] keydb_new 2021-12-23 11:27:15 gpg[17680] DBG: [no clock] keydb_search_reset 2021-12-23 11:27:15 gpg[17680] DBG: keydb_search_reset (hd=0x0089c678) 2021-12-23 11:27:15 gpg[17680] DBG: [no clock] keydb_search enter 2021-12-23 11:27:15 gpg[17680] DBG: keydb_search: 1 search descriptions: 2021-12-23 11:27:15 gpg[17680] DBG: keydb_search 0: FIRST 2021-12-23 11:27:15 gpg[17680] DBG: internal_keydb_search: searching keybox (resource 0 of 1) 2021-12-23 11:27:15 gpg[17680] DBG: internal_keydb_search: searched keybox (resource 0 of 1) => Success 2021-12-23 11:27:15 gpg[17680] DBG: [no clock] keydb_search leave (found) 2021-12-23 11:27:15 gpg[17680] DBG: [no clock] keydb_get_keyblock enter 2021-12-23 11:27:15 gpg[17680] DBG: parse_packet(iob=1): type=6 length=397 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[17680] DBG: parse_packet(iob=1): type=12 length=12 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[17680] DBG: parse_packet(iob=1): type=13 length=47 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[17680] DBG: parse_packet(iob=1): type=12 length=12 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[17680] DBG: parse_packet(iob=1): type=2 length=468 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[17680] DBG: parse_packet(iob=1): type=12 length=6 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[17680] DBG: parse_packet(iob=1): type=2 length=566 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[17680] DBG: parse_packet(iob=1): type=12 length=6 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[17680] DBG: parse_packet(iob=1): type=14 length=397 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[17680] DBG: parse_packet(iob=1): type=2 length=444 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[17680] DBG: parse_packet(iob=1): type=12 length=6 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[17680] DBG: iobuf-1.0: underflow: buffer size: 2388; still buffered: 0 => space for 2388 bytes 2021-12-23 11:27:15 gpg[17680] DBG: iobuf-1.0: close '?' 2021-12-23 11:27:15 gpg[17680] DBG: [no clock] keydb_get_keyblock leave 2021-12-23 11:27:15 gpg[17680] DBG: free_packet() type=6 2021-12-23 11:27:15 gpg[17680] DBG: free_packet() type=13 2021-12-23 11:27:15 gpg[17680] DBG: free_packet() type=2 2021-12-23 11:27:15 gpg[17680] DBG: free_packet() type=2 2021-12-23 11:27:15 gpg[17680] DBG: free_packet() type=14 2021-12-23 11:27:15 gpg[17680] DBG: free_packet() type=2 2021-12-23 11:27:15 gpg[17680] DBG: [no clock] keydb_search enter 2021-12-23 11:27:15 gpg[17680] DBG: keydb_search: 1 search descriptions: 2021-12-23 11:27:15 gpg[17680] DBG: keydb_search 0: NEXT 2021-12-23 11:27:15 gpg[17680] DBG: internal_keydb_search: searching keybox (resource 0 of 1) 2021-12-23 11:27:15 gpg[17680] DBG: internal_keydb_search: searched keybox (resource 0 of 1) => Success 2021-12-23 11:27:15 gpg[17680] DBG: [no clock] keydb_search leave (found) 2021-12-23 11:27:15 gpg[17680] DBG: [no clock] keydb_get_keyblock enter 2021-12-23 11:27:15 gpg[17680] DBG: parse_packet(iob=2): type=6 length=397 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[17680] DBG: parse_packet(iob=2): type=12 length=12 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[17680] DBG: parse_packet(iob=2): type=13 length=31 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[17680] DBG: parse_packet(iob=2): type=12 length=12 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[17680] DBG: parse_packet(iob=2): type=2 length=472 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[17680] DBG: parse_packet(iob=2): type=12 length=6 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[17680] DBG: parse_packet(iob=2): type=14 length=397 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[17680] DBG: parse_packet(iob=2): type=2 length=444 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[17680] DBG: parse_packet(iob=2): type=12 length=6 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[17680] DBG: iobuf-2.0: underflow: buffer size: 1799; still buffered: 0 => space for 1799 bytes 2021-12-23 11:27:15 gpg[17680] DBG: iobuf-2.0: close '?' 2021-12-23 11:27:15 gpg[17680] DBG: [no clock] keydb_get_keyblock leave 2021-12-23 11:27:15 gpg[17680] DBG: rsa_verify data:+01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffff003031300d0609608648016503040201050004207d \ 2021-12-23 11:27:15 gpg[17680] DBG: 9a68e639a33113a5d96e6e603c922e3819aca5dc26611c15e24909988c8a7f 2021-12-23 11:27:15 gpg[17680] DBG: rsa_verify sig:+090da0d3f65b75d4ea3f8672d0a9836c5e5578bc54275ca49336157569bd8bcf \ 2021-12-23 11:27:15 gpg[17680] DBG: 4bd78791867a9d6b6a7235ac74a7172490d9b2cf8d204753e7a27e81db949e49 \ 2021-12-23 11:27:15 gpg[17680] DBG: 80e7f0b2c28ec1e06e34eb4a86cbe41bf74ce4354b01e9f1b05637788b0f2831 \ 2021-12-23 11:27:15 gpg[17680] DBG: 647ba8c66aee7d89248a9685b170c71c2374baf49eb53bff97c25489ad074521 \ 2021-12-23 11:27:15 gpg[17680] DBG: 44dfdc325d04478525c014569a54bdb5890db28d282f308af9f4d25b119031f5 \ 2021-12-23 11:27:15 gpg[17680] DBG: 54a5cc75587566c04b7a152a4b22b7d3d920c486e635f482ffc5de32bc15c25e \ 2021-12-23 11:27:15 gpg[17680] DBG: 131d11d1ec1572421d4decc7443c67546a1715fbacdbc683cadb4279bd0180c1 \ 2021-12-23 11:27:15 gpg[17680] DBG: 28d6c319f50a0375243befca9e15f25be25d126c47c5215b276e4813aab38d6a \ 2021-12-23 11:27:15 gpg[17680] DBG: 569ed09c42be135339058cce8e9e10a7defba0224b85e3c1c0c493979d5ada67 \ 2021-12-23 11:27:15 gpg[17680] DBG: 221c024e452ffa89d7f7c9028aeb06513d1991080f2368e9f5a9453b7a4d573c \ 2021-12-23 11:27:15 gpg[17680] DBG: 13d114650780163e7377616b01529727f17c646fb3d12b503c0741693020a44a \ 2021-12-23 11:27:15 gpg[17680] DBG: 81b3b2d2f6f6c5cdd9e661c2410515faa23e3a66a7b83f4a1ee4ff8af6422a58 2021-12-23 11:27:15 gpg[17680] DBG: rsa_verify n:+d2429b711a2026f990e0149167c6f5ff8ee0666b51836d4787b28c24cbfeb3ed \ 2021-12-23 11:27:15 gpg[17680] DBG: 700075abd721112c0c83fafb48153e0f54cca6e5e9f2223584a61e879facc16e \ 2021-12-23 11:27:15 gpg[17680] DBG: 3b322419bc575e9d2c66561a9560b8f18787410d4d5afe1b30c7f269e4bd4a34 \ 2021-12-23 11:27:15 gpg[17680] DBG: 593879181c8fd65547886f6daa04ae9c3e377bd01993440d308fa588ddeffa8e \ 2021-12-23 11:27:15 gpg[17680] DBG: 7fbec190a85716e2cc10558f2dad18027816904dc33a47814064c7697be34708 \ 2021-12-23 11:27:15 gpg[17680] DBG: 217791bbd357f9ac5136451b4e167825514a87d3a820e2b95788508153de9f1a \ 2021-12-23 11:27:15 gpg[17680] DBG: 4ed21cd5c9f5f87d042dbf65225eb4206729128f7e20cdc014a04b1ef342c9fe \ 2021-12-23 11:27:15 gpg[17680] DBG: 186746c68388a09676cdd5ec4e21a0c3f673c15014464c8e7c69eb343aa00638 \ 2021-12-23 11:27:15 gpg[17680] DBG: 2331d3e2cb8a0ffb6c655b98f85961f6a2397dd18c794d9102f7df8aa7e06a27 \ 2021-12-23 11:27:15 gpg[17680] DBG: ddf6e78ed934b7e5fad06f044228d7bacb865e33bdcf842c3c2d8d4277b77a55 \ 2021-12-23 11:27:15 gpg[17680] DBG: 975b8bf6e24bc6516dc09df3968339eac1170839991cb50276665c1c2c323cfc \ 2021-12-23 11:27:15 gpg[17680] DBG: 5093ede4f29fc24a83dfb4e1a80e89eeed8070f9c46084a91493590b0c9e09e3 2021-12-23 11:27:15 gpg[17680] DBG: rsa_verify e:+010001 2021-12-23 11:27:15 gpg[17680] DBG: rsa_verify cmp:+01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffff003031300d0609608648016503040201050004207d \ 2021-12-23 11:27:15 gpg[17680] DBG: 9a68e639a33113a5d96e6e603c922e3819aca5dc26611c15e24909988c8a7f 2021-12-23 11:27:15 gpg[17680] DBG: rsa_verify => Good 2021-12-23 11:27:15 gpg[17680] DBG: rsa_verify data:+01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffff003031300d060960864801650304020105000420e0 \ 2021-12-23 11:27:15 gpg[17680] DBG: 25c36493f6a0b0b9d387652d947b7ebfa44c8e84f696331b475fec9720806f 2021-12-23 11:27:15 gpg[17680] DBG: rsa_verify sig:+21aebadc451c681cf4badb2db3bc66470e2c62687a8b92af65b86a1c6b73d804 \ 2021-12-23 11:27:15 gpg[17680] DBG: 55e40d88750a1cc6fb5337639ef28d5869a5349d408bd9e20b795de26c9969e7 \ 2021-12-23 11:27:15 gpg[17680] DBG: 067cc3d7ce4b7c86456464e9dd6e47b839536932fe521b3bdbd50bed9dbe8c79 \ 2021-12-23 11:27:15 gpg[17680] DBG: 1b3005ef6875850ddbeb52aad860641f28eaa98ef4b8857ddc343264afa5d4cf \ 2021-12-23 11:27:15 gpg[17680] DBG: 2eaef03414d428ba61d1f853bae52b201efb96a0bbd53ac983828dd496dea58d \ 2021-12-23 11:27:15 gpg[17680] DBG: eccce4abea90a71d458503560610e56695c7fceb184d90cb58b630455fd06575 \ 2021-12-23 11:27:15 gpg[17680] DBG: 12a5936701be736b2a9a25c3a8dcdf978943fa4fe8bb68e83a9056f6e728307a \ 2021-12-23 11:27:15 gpg[17680] DBG: c62bbddd1f7dd43d32d4bf91ad21f9b529d3848dcb68bba3e52375d3e3ad3dd4 \ 2021-12-23 11:27:15 gpg[17680] DBG: 583104f4036545b7392a8d2a0aceca1afc9e255988c3d61dd8533626b5bea305 \ 2021-12-23 11:27:15 gpg[17680] DBG: e99dc419867ffbf4595b5ba46002710a6a4b674bb59067f5f365ef5593f61a6a \ 2021-12-23 11:27:15 gpg[17680] DBG: 4368509e2cc76d7b40e117b1de712ae0ee3ab18fa67feaa912859d6ccd0fb409 \ 2021-12-23 11:27:15 gpg[17680] DBG: 815ececc524de605bf5add5ee6110b618276c7b266ccdf8eac978884d8277529 2021-12-23 11:27:15 gpg[17680] DBG: rsa_verify n:+d2429b711a2026f990e0149167c6f5ff8ee0666b51836d4787b28c24cbfeb3ed \ 2021-12-23 11:27:15 gpg[17680] DBG: 700075abd721112c0c83fafb48153e0f54cca6e5e9f2223584a61e879facc16e \ 2021-12-23 11:27:15 gpg[17680] DBG: 3b322419bc575e9d2c66561a9560b8f18787410d4d5afe1b30c7f269e4bd4a34 \ 2021-12-23 11:27:15 gpg[17680] DBG: 593879181c8fd65547886f6daa04ae9c3e377bd01993440d308fa588ddeffa8e \ 2021-12-23 11:27:15 gpg[17680] DBG: 7fbec190a85716e2cc10558f2dad18027816904dc33a47814064c7697be34708 \ 2021-12-23 11:27:15 gpg[17680] DBG: 217791bbd357f9ac5136451b4e167825514a87d3a820e2b95788508153de9f1a \ 2021-12-23 11:27:15 gpg[17680] DBG: 4ed21cd5c9f5f87d042dbf65225eb4206729128f7e20cdc014a04b1ef342c9fe \ 2021-12-23 11:27:15 gpg[17680] DBG: 186746c68388a09676cdd5ec4e21a0c3f673c15014464c8e7c69eb343aa00638 \ 2021-12-23 11:27:15 gpg[17680] DBG: 2331d3e2cb8a0ffb6c655b98f85961f6a2397dd18c794d9102f7df8aa7e06a27 \ 2021-12-23 11:27:15 gpg[17680] DBG: ddf6e78ed934b7e5fad06f044228d7bacb865e33bdcf842c3c2d8d4277b77a55 \ 2021-12-23 11:27:15 gpg[17680] DBG: 975b8bf6e24bc6516dc09df3968339eac1170839991cb50276665c1c2c323cfc \ 2021-12-23 11:27:15 gpg[17680] DBG: 5093ede4f29fc24a83dfb4e1a80e89eeed8070f9c46084a91493590b0c9e09e3 2021-12-23 11:27:15 gpg[17680] DBG: rsa_verify e:+010001 2021-12-23 11:27:15 gpg[17680] DBG: rsa_verify cmp:+01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffff003031300d060960864801650304020105000420e0 \ 2021-12-23 11:27:15 gpg[17680] DBG: 25c36493f6a0b0b9d387652d947b7ebfa44c8e84f696331b475fec9720806f 2021-12-23 11:27:15 gpg[17680] DBG: rsa_verify => Good 2021-12-23 11:27:15 gpg[17680] DBG: free_packet() type=6 2021-12-23 11:27:15 gpg[17680] DBG: free_packet() type=13 2021-12-23 11:27:15 gpg[17680] DBG: free_packet() type=2 2021-12-23 11:27:15 gpg[17680] DBG: free_packet() type=14 2021-12-23 11:27:15 gpg[17680] DBG: free_packet() type=2 2021-12-23 11:27:15 gpg[17680] DBG: [no clock] keydb_search enter 2021-12-23 11:27:15 gpg[17680] DBG: keydb_search: 1 search descriptions: 2021-12-23 11:27:15 gpg[17680] DBG: keydb_search 0: NEXT 2021-12-23 11:27:15 gpg[17680] DBG: internal_keydb_search: searching keybox (resource 0 of 1) 2021-12-23 11:27:15 gpg[17680] DBG: internal_keydb_search: searched keybox (resource 0 of 1) => EOF 2021-12-23 11:27:15 gpg[17680] DBG: [no clock] keydb_search leave (not found) 2021-12-23 11:27:15 gpg[17680] DBG: [no clock] keydb_release 2021-12-23 11:27:15 gpg[17680] DBG: [no clock] stop 2021-12-23 11:27:15 gpg[17680] keydb: handles=1 locks=0 parse=2 get=2 2021-12-23 11:27:15 gpg[17680] build=0 update=0 insert=0 delete=0 2021-12-23 11:27:15 gpg[17680] reset=1 found=2 not=1 cache=0 not=0 2021-12-23 11:27:15 gpg[17680] kid_not_found_cache: count=0 peak=0 flushes=0 2021-12-23 11:27:15 gpg[17680] sig_cache: total=4 cached=2 good=2 bad=0 2021-12-23 11:27:15 gpg[17680] objcache: keys=0/0/0 chains=0,0..0 buckets=0/0 attic=0 2021-12-23 11:27:15 gpg[17680] objcache: uids=0/0/0 chains=0,0..0 buckets=0/0 2021-12-23 11:27:15 gpg[17680] random usage: poolsize=600 mixed=0 polls=0/0 added=0/0 outmix=0 getlvl1=0/0 getlvl2=0/0 2021-12-23 11:27:15 gpg[17680] rndjent stat: collector=0x00000000 calls=0 bytes=0 2021-12-23 11:27:15 gpg[17680] secmem usage: 0/32768 bytes in 0 blocks 2021-12-23 11:27:15 gpg[18260] using character set 'utf-8' 2021-12-23 11:27:15 gpg[18260] Note: RFC4880bis features are enabled. 2021-12-23 11:27:15 gpg[18260] enabled debug flags: packet mpi crypto filter iobuf memory cache memstat trust hashing ipc clock lookup extprog 2021-12-23 11:27:15 gpg[18260] DBG: [no clock] start 2021-12-23 11:27:15 gpg[18260] using pgp trust model 2021-12-23 11:27:15 gpg[18260] key F82A7011A81784E3: accepted as trusted key 2021-12-23 11:27:15 gpg[18260] DBG: [no clock] keydb_new 2021-12-23 11:27:15 gpg[18260] DBG: [no clock] keydb_search_reset 2021-12-23 11:27:15 gpg[18260] DBG: keydb_search_reset (hd=0x02b1a2e0) 2021-12-23 11:27:15 gpg[18260] DBG: [no clock] keydb_search enter 2021-12-23 11:27:15 gpg[18260] DBG: keydb_search: 1 search descriptions: 2021-12-23 11:27:15 gpg[18260] DBG: keydb_search 0: FIRST 2021-12-23 11:27:15 gpg[18260] DBG: internal_keydb_search: searching keybox (resource 0 of 1) 2021-12-23 11:27:15 gpg[18260] DBG: internal_keydb_search: searched keybox (resource 0 of 1) => Success 2021-12-23 11:27:15 gpg[18260] DBG: [no clock] keydb_search leave (found) 2021-12-23 11:27:15 gpg[18260] DBG: [no clock] keydb_get_keyblock enter 2021-12-23 11:27:15 gpg[18260] DBG: parse_packet(iob=1): type=6 length=397 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[18260] DBG: parse_packet(iob=1): type=12 length=12 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[18260] DBG: parse_packet(iob=1): type=13 length=47 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[18260] DBG: parse_packet(iob=1): type=12 length=12 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[18260] DBG: parse_packet(iob=1): type=2 length=468 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[18260] DBG: parse_packet(iob=1): type=12 length=6 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[18260] DBG: parse_packet(iob=1): type=2 length=566 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[18260] DBG: parse_packet(iob=1): type=12 length=6 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[18260] DBG: parse_packet(iob=1): type=14 length=397 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[18260] DBG: parse_packet(iob=1): type=2 length=444 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[18260] DBG: parse_packet(iob=1): type=12 length=6 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[18260] DBG: iobuf-1.0: underflow: buffer size: 2388; still buffered: 0 => space for 2388 bytes 2021-12-23 11:27:15 gpg[18260] DBG: iobuf-1.0: close '?' 2021-12-23 11:27:15 gpg[18260] DBG: [no clock] keydb_get_keyblock leave 2021-12-23 11:27:15 gpg[18260] DBG: chan_0x0000026c <- OK Pleased to meet you 2021-12-23 11:27:15 gpg[18260] DBG: connection to the gpg-agent established 2021-12-23 11:27:15 gpg[18260] DBG: chan_0x0000026c -> RESET 2021-12-23 11:27:15 gpg[18260] DBG: chan_0x0000026c <- OK 2021-12-23 11:27:15 gpg[18260] DBG: chan_0x0000026c -> OPTION ttyname=/dev/tty 2021-12-23 11:27:15 gpg[18260] DBG: chan_0x0000026c <- OK 2021-12-23 11:27:15 gpg[18260] DBG: chan_0x0000026c -> GETINFO version 2021-12-23 11:27:15 gpg[18260] DBG: chan_0x0000026c <- D 2.3.4 2021-12-23 11:27:15 gpg[18260] DBG: chan_0x0000026c <- OK 2021-12-23 11:27:15 gpg[18260] DBG: chan_0x0000026c -> OPTION allow-pinentry-notify 2021-12-23 11:27:15 gpg[18260] DBG: chan_0x0000026c <- OK 2021-12-23 11:27:15 gpg[18260] DBG: chan_0x0000026c -> OPTION agent-awareness=2.1.0 2021-12-23 11:27:15 gpg[18260] DBG: chan_0x0000026c <- OK 2021-12-23 11:27:15 gpg[18260] DBG: chan_0x0000026c -> HAVEKEY --list=1000 2021-12-23 11:27:15 gpg[18260] DBG: chan_0000026C <- [ 44 20 16 7e 99 2a d0 5c e3 78 5d aa dd 48 f7 36 ...(28 byte(s) skipped) ] 2021-12-23 11:27:15 gpg[18260] DBG: chan_0x0000026c <- OK 2021-12-23 11:27:15 gpg[18260] DBG: get_keygrip for public key 2021-12-23 11:27:15 gpg[18260] DBG: keygrip= b5c5d84ced38925bff90debb4d828de8aa003d84 2021-12-23 11:27:15 gpg[18260] DBG: get_keygrip for public key 2021-12-23 11:27:15 gpg[18260] DBG: keygrip= cc55afcc2c73df7231a53171c5e8a3192ad6eca8 2021-12-23 11:27:15 gpg[18260] DBG: get_keygrip for public key 2021-12-23 11:27:15 gpg[18260] DBG: keygrip= b5c5d84ced38925bff90debb4d828de8aa003d84 2021-12-23 11:27:15 gpg[18260] DBG: get_keygrip for public key 2021-12-23 11:27:15 gpg[18260] DBG: keygrip= cc55afcc2c73df7231a53171c5e8a3192ad6eca8 2021-12-23 11:27:15 gpg[18260] DBG: free_packet() type=6 2021-12-23 11:27:15 gpg[18260] DBG: free_packet() type=13 2021-12-23 11:27:15 gpg[18260] DBG: free_packet() type=2 2021-12-23 11:27:15 gpg[18260] DBG: free_packet() type=2 2021-12-23 11:27:15 gpg[18260] DBG: free_packet() type=14 2021-12-23 11:27:15 gpg[18260] DBG: free_packet() type=2 2021-12-23 11:27:15 gpg[18260] DBG: [no clock] keydb_search enter 2021-12-23 11:27:15 gpg[18260] DBG: keydb_search: 1 search descriptions: 2021-12-23 11:27:15 gpg[18260] DBG: keydb_search 0: NEXT 2021-12-23 11:27:15 gpg[18260] DBG: internal_keydb_search: searching keybox (resource 0 of 1) 2021-12-23 11:27:15 gpg[18260] DBG: internal_keydb_search: searched keybox (resource 0 of 1) => Success 2021-12-23 11:27:15 gpg[18260] DBG: [no clock] keydb_search leave (found) 2021-12-23 11:27:15 gpg[18260] DBG: [no clock] keydb_get_keyblock enter 2021-12-23 11:27:15 gpg[18260] DBG: parse_packet(iob=2): type=6 length=397 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[18260] DBG: parse_packet(iob=2): type=12 length=12 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[18260] DBG: parse_packet(iob=2): type=13 length=31 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[18260] DBG: parse_packet(iob=2): type=12 length=12 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[18260] DBG: parse_packet(iob=2): type=2 length=472 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[18260] DBG: parse_packet(iob=2): type=12 length=6 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[18260] DBG: parse_packet(iob=2): type=14 length=397 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[18260] DBG: parse_packet(iob=2): type=2 length=444 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[18260] DBG: parse_packet(iob=2): type=12 length=6 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[18260] DBG: iobuf-2.0: underflow: buffer size: 1799; still buffered: 0 => space for 1799 bytes 2021-12-23 11:27:15 gpg[18260] DBG: iobuf-2.0: close '?' 2021-12-23 11:27:15 gpg[18260] DBG: [no clock] keydb_get_keyblock leave 2021-12-23 11:27:15 gpg[18260] DBG: get_keygrip for public key 2021-12-23 11:27:15 gpg[18260] DBG: keygrip= a04d691688b19d284309134aecaf4f1c4584f52a 2021-12-23 11:27:15 gpg[18260] DBG: rsa_verify data:+01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffff003031300d0609608648016503040201050004207d \ 2021-12-23 11:27:15 gpg[18260] DBG: 9a68e639a33113a5d96e6e603c922e3819aca5dc26611c15e24909988c8a7f 2021-12-23 11:27:15 gpg[18260] DBG: rsa_verify sig:+090da0d3f65b75d4ea3f8672d0a9836c5e5578bc54275ca49336157569bd8bcf \ 2021-12-23 11:27:15 gpg[18260] DBG: 4bd78791867a9d6b6a7235ac74a7172490d9b2cf8d204753e7a27e81db949e49 \ 2021-12-23 11:27:15 gpg[18260] DBG: 80e7f0b2c28ec1e06e34eb4a86cbe41bf74ce4354b01e9f1b05637788b0f2831 \ 2021-12-23 11:27:15 gpg[18260] DBG: 647ba8c66aee7d89248a9685b170c71c2374baf49eb53bff97c25489ad074521 \ 2021-12-23 11:27:15 gpg[18260] DBG: 44dfdc325d04478525c014569a54bdb5890db28d282f308af9f4d25b119031f5 \ 2021-12-23 11:27:15 gpg[18260] DBG: 54a5cc75587566c04b7a152a4b22b7d3d920c486e635f482ffc5de32bc15c25e \ 2021-12-23 11:27:15 gpg[18260] DBG: 131d11d1ec1572421d4decc7443c67546a1715fbacdbc683cadb4279bd0180c1 \ 2021-12-23 11:27:15 gpg[18260] DBG: 28d6c319f50a0375243befca9e15f25be25d126c47c5215b276e4813aab38d6a \ 2021-12-23 11:27:15 gpg[18260] DBG: 569ed09c42be135339058cce8e9e10a7defba0224b85e3c1c0c493979d5ada67 \ 2021-12-23 11:27:15 gpg[18260] DBG: 221c024e452ffa89d7f7c9028aeb06513d1991080f2368e9f5a9453b7a4d573c \ 2021-12-23 11:27:15 gpg[18260] DBG: 13d114650780163e7377616b01529727f17c646fb3d12b503c0741693020a44a \ 2021-12-23 11:27:15 gpg[18260] DBG: 81b3b2d2f6f6c5cdd9e661c2410515faa23e3a66a7b83f4a1ee4ff8af6422a58 2021-12-23 11:27:15 gpg[18260] DBG: rsa_verify n:+d2429b711a2026f990e0149167c6f5ff8ee0666b51836d4787b28c24cbfeb3ed \ 2021-12-23 11:27:15 gpg[18260] DBG: 700075abd721112c0c83fafb48153e0f54cca6e5e9f2223584a61e879facc16e \ 2021-12-23 11:27:15 gpg[18260] DBG: 3b322419bc575e9d2c66561a9560b8f18787410d4d5afe1b30c7f269e4bd4a34 \ 2021-12-23 11:27:15 gpg[18260] DBG: 593879181c8fd65547886f6daa04ae9c3e377bd01993440d308fa588ddeffa8e \ 2021-12-23 11:27:15 gpg[18260] DBG: 7fbec190a85716e2cc10558f2dad18027816904dc33a47814064c7697be34708 \ 2021-12-23 11:27:15 gpg[18260] DBG: 217791bbd357f9ac5136451b4e167825514a87d3a820e2b95788508153de9f1a \ 2021-12-23 11:27:15 gpg[18260] DBG: 4ed21cd5c9f5f87d042dbf65225eb4206729128f7e20cdc014a04b1ef342c9fe \ 2021-12-23 11:27:15 gpg[18260] DBG: 186746c68388a09676cdd5ec4e21a0c3f673c15014464c8e7c69eb343aa00638 \ 2021-12-23 11:27:15 gpg[18260] DBG: 2331d3e2cb8a0ffb6c655b98f85961f6a2397dd18c794d9102f7df8aa7e06a27 \ 2021-12-23 11:27:15 gpg[18260] DBG: ddf6e78ed934b7e5fad06f044228d7bacb865e33bdcf842c3c2d8d4277b77a55 \ 2021-12-23 11:27:15 gpg[18260] DBG: 975b8bf6e24bc6516dc09df3968339eac1170839991cb50276665c1c2c323cfc \ 2021-12-23 11:27:15 gpg[18260] DBG: 5093ede4f29fc24a83dfb4e1a80e89eeed8070f9c46084a91493590b0c9e09e3 2021-12-23 11:27:15 gpg[18260] DBG: rsa_verify e:+010001 2021-12-23 11:27:15 gpg[18260] DBG: rsa_verify cmp:+01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffff003031300d0609608648016503040201050004207d \ 2021-12-23 11:27:15 gpg[18260] DBG: 9a68e639a33113a5d96e6e603c922e3819aca5dc26611c15e24909988c8a7f 2021-12-23 11:27:15 gpg[18260] DBG: rsa_verify => Good 2021-12-23 11:27:15 gpg[18260] DBG: rsa_verify data:+01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffff003031300d060960864801650304020105000420e0 \ 2021-12-23 11:27:15 gpg[18260] DBG: 25c36493f6a0b0b9d387652d947b7ebfa44c8e84f696331b475fec9720806f 2021-12-23 11:27:15 gpg[18260] DBG: rsa_verify sig:+21aebadc451c681cf4badb2db3bc66470e2c62687a8b92af65b86a1c6b73d804 \ 2021-12-23 11:27:15 gpg[18260] DBG: 55e40d88750a1cc6fb5337639ef28d5869a5349d408bd9e20b795de26c9969e7 \ 2021-12-23 11:27:15 gpg[18260] DBG: 067cc3d7ce4b7c86456464e9dd6e47b839536932fe521b3bdbd50bed9dbe8c79 \ 2021-12-23 11:27:15 gpg[18260] DBG: 1b3005ef6875850ddbeb52aad860641f28eaa98ef4b8857ddc343264afa5d4cf \ 2021-12-23 11:27:15 gpg[18260] DBG: 2eaef03414d428ba61d1f853bae52b201efb96a0bbd53ac983828dd496dea58d \ 2021-12-23 11:27:15 gpg[18260] DBG: eccce4abea90a71d458503560610e56695c7fceb184d90cb58b630455fd06575 \ 2021-12-23 11:27:15 gpg[18260] DBG: 12a5936701be736b2a9a25c3a8dcdf978943fa4fe8bb68e83a9056f6e728307a \ 2021-12-23 11:27:15 gpg[18260] DBG: c62bbddd1f7dd43d32d4bf91ad21f9b529d3848dcb68bba3e52375d3e3ad3dd4 \ 2021-12-23 11:27:15 gpg[18260] DBG: 583104f4036545b7392a8d2a0aceca1afc9e255988c3d61dd8533626b5bea305 \ 2021-12-23 11:27:15 gpg[18260] DBG: e99dc419867ffbf4595b5ba46002710a6a4b674bb59067f5f365ef5593f61a6a \ 2021-12-23 11:27:15 gpg[18260] DBG: 4368509e2cc76d7b40e117b1de712ae0ee3ab18fa67feaa912859d6ccd0fb409 \ 2021-12-23 11:27:15 gpg[18260] DBG: 815ececc524de605bf5add5ee6110b618276c7b266ccdf8eac978884d8277529 2021-12-23 11:27:15 gpg[18260] DBG: rsa_verify n:+d2429b711a2026f990e0149167c6f5ff8ee0666b51836d4787b28c24cbfeb3ed \ 2021-12-23 11:27:15 gpg[18260] DBG: 700075abd721112c0c83fafb48153e0f54cca6e5e9f2223584a61e879facc16e \ 2021-12-23 11:27:15 gpg[18260] DBG: 3b322419bc575e9d2c66561a9560b8f18787410d4d5afe1b30c7f269e4bd4a34 \ 2021-12-23 11:27:15 gpg[18260] DBG: 593879181c8fd65547886f6daa04ae9c3e377bd01993440d308fa588ddeffa8e \ 2021-12-23 11:27:15 gpg[18260] DBG: 7fbec190a85716e2cc10558f2dad18027816904dc33a47814064c7697be34708 \ 2021-12-23 11:27:15 gpg[18260] DBG: 217791bbd357f9ac5136451b4e167825514a87d3a820e2b95788508153de9f1a \ 2021-12-23 11:27:15 gpg[18260] DBG: 4ed21cd5c9f5f87d042dbf65225eb4206729128f7e20cdc014a04b1ef342c9fe \ 2021-12-23 11:27:15 gpg[18260] DBG: 186746c68388a09676cdd5ec4e21a0c3f673c15014464c8e7c69eb343aa00638 \ 2021-12-23 11:27:15 gpg[18260] DBG: 2331d3e2cb8a0ffb6c655b98f85961f6a2397dd18c794d9102f7df8aa7e06a27 \ 2021-12-23 11:27:15 gpg[18260] DBG: ddf6e78ed934b7e5fad06f044228d7bacb865e33bdcf842c3c2d8d4277b77a55 \ 2021-12-23 11:27:15 gpg[18260] DBG: 975b8bf6e24bc6516dc09df3968339eac1170839991cb50276665c1c2c323cfc \ 2021-12-23 11:27:15 gpg[18260] DBG: 5093ede4f29fc24a83dfb4e1a80e89eeed8070f9c46084a91493590b0c9e09e3 2021-12-23 11:27:15 gpg[18260] DBG: rsa_verify e:+010001 2021-12-23 11:27:15 gpg[18260] DBG: rsa_verify cmp:+01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffff003031300d060960864801650304020105000420e0 \ 2021-12-23 11:27:15 gpg[18260] DBG: 25c36493f6a0b0b9d387652d947b7ebfa44c8e84f696331b475fec9720806f 2021-12-23 11:27:15 gpg[18260] DBG: rsa_verify => Good 2021-12-23 11:27:15 gpg[18260] DBG: get_keygrip for public key 2021-12-23 11:27:15 gpg[18260] DBG: keygrip= a04d691688b19d284309134aecaf4f1c4584f52a 2021-12-23 11:27:15 gpg[18260] DBG: chan_0x0000026c -> KEYINFO A04D691688B19D284309134AECAF4F1C4584F52A 2021-12-23 11:27:15 gpg[18260] DBG: chan_0x0000026c <- S KEYINFO A04D691688B19D284309134AECAF4F1C4584F52A D - - - P - - - 2021-12-23 11:27:15 gpg[18260] DBG: chan_0x0000026c <- OK 2021-12-23 11:27:15 gpg[18260] DBG: get_keygrip for public key 2021-12-23 11:27:15 gpg[18260] DBG: keygrip= 167e992ad05ce3785daadd48f736fc0d1283e241 2021-12-23 11:27:15 gpg[18260] DBG: chan_0x0000026c -> KEYINFO 167E992AD05CE3785DAADD48F736FC0D1283E241 2021-12-23 11:27:15 gpg[18260] DBG: chan_0x0000026c <- S KEYINFO 167E992AD05CE3785DAADD48F736FC0D1283E241 D - - - P - - - 2021-12-23 11:27:15 gpg[18260] DBG: chan_0x0000026c <- OK 2021-12-23 11:27:15 gpg[18260] DBG: free_packet() type=6 2021-12-23 11:27:15 gpg[18260] DBG: free_packet() type=13 2021-12-23 11:27:15 gpg[18260] DBG: free_packet() type=2 2021-12-23 11:27:15 gpg[18260] DBG: free_packet() type=14 2021-12-23 11:27:15 gpg[18260] DBG: free_packet() type=2 2021-12-23 11:27:15 gpg[18260] DBG: [no clock] keydb_search enter 2021-12-23 11:27:15 gpg[18260] DBG: keydb_search: 1 search descriptions: 2021-12-23 11:27:15 gpg[18260] DBG: keydb_search 0: NEXT 2021-12-23 11:27:15 gpg[18260] DBG: internal_keydb_search: searching keybox (resource 0 of 1) 2021-12-23 11:27:15 gpg[18260] DBG: internal_keydb_search: searched keybox (resource 0 of 1) => EOF 2021-12-23 11:27:15 gpg[18260] DBG: [no clock] keydb_search leave (not found) 2021-12-23 11:27:15 gpg[18260] DBG: [no clock] keydb_release 2021-12-23 11:27:15 gpg[18260] DBG: [no clock] stop 2021-12-23 11:27:15 gpg[18260] keydb: handles=1 locks=0 parse=2 get=2 2021-12-23 11:27:15 gpg[18260] build=0 update=0 insert=0 delete=0 2021-12-23 11:27:15 gpg[18260] reset=1 found=2 not=1 cache=0 not=0 2021-12-23 11:27:15 gpg[18260] kid_not_found_cache: count=0 peak=0 flushes=0 2021-12-23 11:27:15 gpg[18260] sig_cache: total=4 cached=2 good=2 bad=0 2021-12-23 11:27:15 gpg[18260] objcache: keys=0/0/0 chains=0,0..0 buckets=0/0 attic=0 2021-12-23 11:27:15 gpg[18260] objcache: uids=0/0/0 chains=0,0..0 buckets=0/0 2021-12-23 11:27:15 gpg[18260] random usage: poolsize=600 mixed=0 polls=0/0 added=0/0 outmix=0 getlvl1=0/0 getlvl2=0/0 2021-12-23 11:27:15 gpg[18260] rndjent stat: collector=0x00000000 calls=0 bytes=0 2021-12-23 11:27:15 gpg[18260] secmem usage: 0/32768 bytes in 0 blocks 2021-12-23 11:27:30 gpg[12864] using character set 'utf-8' 2021-12-23 11:27:30 gpg[12864] Note: RFC4880bis features are enabled. 2021-12-23 11:27:30 gpg[12864] enabled debug flags: packet mpi crypto filter iobuf memory cache memstat trust hashing ipc clock lookup extprog 2021-12-23 11:27:30 gpg[12864] DBG: [no clock] start 2021-12-23 11:27:30 gpg[12864] DBG: chan_0x0000025c <- # Home: C:\Users\Oleksandr\AppData\Roaming\gnupg 2021-12-23 11:27:30 gpg[12864] DBG: chan_0x0000025c <- # Config: C:/Users/Oleksandr/AppData/Roaming/gnupg/dirmngr.conf 2021-12-23 11:27:30 gpg[12864] DBG: chan_0x0000025c <- OK Dirmngr 2.3.4 at your service 2021-12-23 11:27:30 gpg[12864] DBG: connection to the dirmngr established 2021-12-23 11:27:30 gpg[12864] DBG: chan_0x0000025c -> GETINFO version 2021-12-23 11:27:30 gpg[12864] DBG: chan_0x0000025c <- D 2.3.4 2021-12-23 11:27:30 gpg[12864] DBG: chan_0x0000025c <- OK 2021-12-23 11:27:30 gpg[12864] DBG: chan_0x0000025c -> KEYSERVER --clear hkps://gpg.example.com/ 2021-12-23 11:27:30 gpg[12864] DBG: chan_0x0000025c <- OK 2021-12-23 11:27:30 gpg[12864] DBG: chan_0x0000025c -> KS_SEARCH -- oleksandr at example.com 2021-12-23 11:27:30 gpg[12864] DBG: chan_0x0000025c <- ERR 167772261 Certificate expired 2021-12-23 11:27:30 gpg[12864] error searching keyserver: Certificate expired 2021-12-23 11:27:30 gpg[12864] keyserver search failed: Certificate expired 2021-12-23 11:27:30 gpg[12864] DBG: chan_0x0000025c -> BYE 2021-12-23 11:27:30 gpg[12864] DBG: [no clock] stop 2021-12-23 11:27:30 gpg[12864] keydb: handles=0 locks=0 parse=0 get=0 2021-12-23 11:27:30 gpg[12864] build=0 update=0 insert=0 delete=0 2021-12-23 11:27:30 gpg[12864] reset=0 found=0 not=0 cache=0 not=0 2021-12-23 11:27:30 gpg[12864] kid_not_found_cache: count=0 peak=0 flushes=0 2021-12-23 11:27:30 gpg[12864] sig_cache: total=0 cached=0 good=0 bad=0 2021-12-23 11:27:30 gpg[12864] objcache: keys=0/0/0 chains=0,0..0 buckets=0/0 attic=0 2021-12-23 11:27:30 gpg[12864] objcache: uids=0/0/0 chains=0,0..0 buckets=0/0 2021-12-23 11:27:30 gpg[12864] random usage: poolsize=600 mixed=0 polls=0/0 added=0/0 outmix=0 getlvl1=0/0 getlvl2=0/0 2021-12-23 11:27:30 gpg[12864] rndjent stat: collector=0x00000000 calls=0 bytes=0 2021-12-23 11:27:30 gpg[12864] secmem usage: 0/32768 bytes in 0 blocks Virus-free. www.avast.com <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.nadtoka at gmail.com Thu Dec 23 16:13:10 2021 From: alex.nadtoka at gmail.com (Alex Nadtoka) Date: Thu, 23 Dec 2021 17:13:10 +0200 Subject: issue with gpg4win In-Reply-To: References: Message-ID: > Hello guys. I cannot connect to any keyserver. The error is certificate > expired. What could be the problem? how to debug? our keyserver uses latest > letcencrypt certificate. Here is Debug log. I am on latest (I think) > Windows 10. In attachment you can see SSL certificate details. 2021-12-23 11:27:15 gpg[17680] using character set 'utf-8' 2021-12-23 11:27:15 gpg[17680] Note: RFC4880bis features are enabled. 2021-12-23 11:27:15 gpg[17680] enabled debug flags: packet mpi crypto filter iobuf memory cache memstat trust hashing ipc clock lookup extprog 2021-12-23 11:27:15 gpg[17680] DBG: [no clock] start 2021-12-23 11:27:15 gpg[17680] using pgp trust model 2021-12-23 11:27:15 gpg[17680] key F82A7011A81784E3: accepted as trusted key 2021-12-23 11:27:15 gpg[17680] DBG: [no clock] keydb_new 2021-12-23 11:27:15 gpg[17680] DBG: [no clock] keydb_search_reset 2021-12-23 11:27:15 gpg[17680] DBG: keydb_search_reset (hd=0x0089c678) 2021-12-23 11:27:15 gpg[17680] DBG: [no clock] keydb_search enter 2021-12-23 11:27:15 gpg[17680] DBG: keydb_search: 1 search descriptions: 2021-12-23 11:27:15 gpg[17680] DBG: keydb_search 0: FIRST 2021-12-23 11:27:15 gpg[17680] DBG: internal_keydb_search: searching keybox (resource 0 of 1) 2021-12-23 11:27:15 gpg[17680] DBG: internal_keydb_search: searched keybox (resource 0 of 1) => Success 2021-12-23 11:27:15 gpg[17680] DBG: [no clock] keydb_search leave (found) 2021-12-23 11:27:15 gpg[17680] DBG: [no clock] keydb_get_keyblock enter 2021-12-23 11:27:15 gpg[17680] DBG: parse_packet(iob=1): type=6 length=397 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[17680] DBG: parse_packet(iob=1): type=12 length=12 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[17680] DBG: parse_packet(iob=1): type=13 length=47 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[17680] DBG: parse_packet(iob=1): type=12 length=12 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[17680] DBG: parse_packet(iob=1): type=2 length=468 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[17680] DBG: parse_packet(iob=1): type=12 length=6 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[17680] DBG: parse_packet(iob=1): type=2 length=566 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[17680] DBG: parse_packet(iob=1): type=12 length=6 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[17680] DBG: parse_packet(iob=1): type=14 length=397 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[17680] DBG: parse_packet(iob=1): type=2 length=444 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[17680] DBG: parse_packet(iob=1): type=12 length=6 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[17680] DBG: iobuf-1.0: underflow: buffer size: 2388; still buffered: 0 => space for 2388 bytes 2021-12-23 11:27:15 gpg[17680] DBG: iobuf-1.0: close '?' 2021-12-23 11:27:15 gpg[17680] DBG: [no clock] keydb_get_keyblock leave 2021-12-23 11:27:15 gpg[17680] DBG: free_packet() type=6 2021-12-23 11:27:15 gpg[17680] DBG: free_packet() type=13 2021-12-23 11:27:15 gpg[17680] DBG: free_packet() type=2 2021-12-23 11:27:15 gpg[17680] DBG: free_packet() type=2 2021-12-23 11:27:15 gpg[17680] DBG: free_packet() type=14 2021-12-23 11:27:15 gpg[17680] DBG: free_packet() type=2 2021-12-23 11:27:15 gpg[17680] DBG: [no clock] keydb_search enter 2021-12-23 11:27:15 gpg[17680] DBG: keydb_search: 1 search descriptions: 2021-12-23 11:27:15 gpg[17680] DBG: keydb_search 0: NEXT 2021-12-23 11:27:15 gpg[17680] DBG: internal_keydb_search: searching keybox (resource 0 of 1) 2021-12-23 11:27:15 gpg[17680] DBG: internal_keydb_search: searched keybox (resource 0 of 1) => Success 2021-12-23 11:27:15 gpg[17680] DBG: [no clock] keydb_search leave (found) 2021-12-23 11:27:15 gpg[17680] DBG: [no clock] keydb_get_keyblock enter 2021-12-23 11:27:15 gpg[17680] DBG: parse_packet(iob=2): type=6 length=397 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[17680] DBG: parse_packet(iob=2): type=12 length=12 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[17680] DBG: parse_packet(iob=2): type=13 length=31 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[17680] DBG: parse_packet(iob=2): type=12 length=12 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[17680] DBG: parse_packet(iob=2): type=2 length=472 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[17680] DBG: parse_packet(iob=2): type=12 length=6 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[17680] DBG: parse_packet(iob=2): type=14 length=397 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[17680] DBG: parse_packet(iob=2): type=2 length=444 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[17680] DBG: parse_packet(iob=2): type=12 length=6 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[17680] DBG: iobuf-2.0: underflow: buffer size: 1799; still buffered: 0 => space for 1799 bytes 2021-12-23 11:27:15 gpg[17680] DBG: iobuf-2.0: close '?' 2021-12-23 11:27:15 gpg[17680] DBG: [no clock] keydb_get_keyblock leave 2021-12-23 11:27:15 gpg[17680] DBG: rsa_verify data:+01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffff003031300d0609608648016503040201050004207d \ 2021-12-23 11:27:15 gpg[17680] DBG: 9a68e639a33113a5d96e6e603c922e3819aca5dc26611c15e24909988c8a7f 2021-12-23 11:27:15 gpg[17680] DBG: rsa_verify sig:+090da0d3f65b75d4ea3f8672d0a9836c5e5578bc54275ca49336157569bd8bcf \ 2021-12-23 11:27:15 gpg[17680] DBG: 4bd78791867a9d6b6a7235ac74a7172490d9b2cf8d204753e7a27e81db949e49 \ 2021-12-23 11:27:15 gpg[17680] DBG: 80e7f0b2c28ec1e06e34eb4a86cbe41bf74ce4354b01e9f1b05637788b0f2831 \ 2021-12-23 11:27:15 gpg[17680] DBG: 647ba8c66aee7d89248a9685b170c71c2374baf49eb53bff97c25489ad074521 \ 2021-12-23 11:27:15 gpg[17680] DBG: 44dfdc325d04478525c014569a54bdb5890db28d282f308af9f4d25b119031f5 \ 2021-12-23 11:27:15 gpg[17680] DBG: 54a5cc75587566c04b7a152a4b22b7d3d920c486e635f482ffc5de32bc15c25e \ 2021-12-23 11:27:15 gpg[17680] DBG: 131d11d1ec1572421d4decc7443c67546a1715fbacdbc683cadb4279bd0180c1 \ 2021-12-23 11:27:15 gpg[17680] DBG: 28d6c319f50a0375243befca9e15f25be25d126c47c5215b276e4813aab38d6a \ 2021-12-23 11:27:15 gpg[17680] DBG: 569ed09c42be135339058cce8e9e10a7defba0224b85e3c1c0c493979d5ada67 \ 2021-12-23 11:27:15 gpg[17680] DBG: 221c024e452ffa89d7f7c9028aeb06513d1991080f2368e9f5a9453b7a4d573c \ 2021-12-23 11:27:15 gpg[17680] DBG: 13d114650780163e7377616b01529727f17c646fb3d12b503c0741693020a44a \ 2021-12-23 11:27:15 gpg[17680] DBG: 81b3b2d2f6f6c5cdd9e661c2410515faa23e3a66a7b83f4a1ee4ff8af6422a58 2021-12-23 11:27:15 gpg[17680] DBG: rsa_verify n:+d2429b711a2026f990e0149167c6f5ff8ee0666b51836d4787b28c24cbfeb3ed \ 2021-12-23 11:27:15 gpg[17680] DBG: 700075abd721112c0c83fafb48153e0f54cca6e5e9f2223584a61e879facc16e \ 2021-12-23 11:27:15 gpg[17680] DBG: 3b322419bc575e9d2c66561a9560b8f18787410d4d5afe1b30c7f269e4bd4a34 \ 2021-12-23 11:27:15 gpg[17680] DBG: 593879181c8fd65547886f6daa04ae9c3e377bd01993440d308fa588ddeffa8e \ 2021-12-23 11:27:15 gpg[17680] DBG: 7fbec190a85716e2cc10558f2dad18027816904dc33a47814064c7697be34708 \ 2021-12-23 11:27:15 gpg[17680] DBG: 217791bbd357f9ac5136451b4e167825514a87d3a820e2b95788508153de9f1a \ 2021-12-23 11:27:15 gpg[17680] DBG: 4ed21cd5c9f5f87d042dbf65225eb4206729128f7e20cdc014a04b1ef342c9fe \ 2021-12-23 11:27:15 gpg[17680] DBG: 186746c68388a09676cdd5ec4e21a0c3f673c15014464c8e7c69eb343aa00638 \ 2021-12-23 11:27:15 gpg[17680] DBG: 2331d3e2cb8a0ffb6c655b98f85961f6a2397dd18c794d9102f7df8aa7e06a27 \ 2021-12-23 11:27:15 gpg[17680] DBG: ddf6e78ed934b7e5fad06f044228d7bacb865e33bdcf842c3c2d8d4277b77a55 \ 2021-12-23 11:27:15 gpg[17680] DBG: 975b8bf6e24bc6516dc09df3968339eac1170839991cb50276665c1c2c323cfc \ 2021-12-23 11:27:15 gpg[17680] DBG: 5093ede4f29fc24a83dfb4e1a80e89eeed8070f9c46084a91493590b0c9e09e3 2021-12-23 11:27:15 gpg[17680] DBG: rsa_verify e:+010001 2021-12-23 11:27:15 gpg[17680] DBG: rsa_verify cmp:+01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffff003031300d0609608648016503040201050004207d \ 2021-12-23 11:27:15 gpg[17680] DBG: 9a68e639a33113a5d96e6e603c922e3819aca5dc26611c15e24909988c8a7f 2021-12-23 11:27:15 gpg[17680] DBG: rsa_verify => Good 2021-12-23 11:27:15 gpg[17680] DBG: rsa_verify data:+01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffff003031300d060960864801650304020105000420e0 \ 2021-12-23 11:27:15 gpg[17680] DBG: 25c36493f6a0b0b9d387652d947b7ebfa44c8e84f696331b475fec9720806f 2021-12-23 11:27:15 gpg[17680] DBG: rsa_verify sig:+21aebadc451c681cf4badb2db3bc66470e2c62687a8b92af65b86a1c6b73d804 \ 2021-12-23 11:27:15 gpg[17680] DBG: 55e40d88750a1cc6fb5337639ef28d5869a5349d408bd9e20b795de26c9969e7 \ 2021-12-23 11:27:15 gpg[17680] DBG: 067cc3d7ce4b7c86456464e9dd6e47b839536932fe521b3bdbd50bed9dbe8c79 \ 2021-12-23 11:27:15 gpg[17680] DBG: 1b3005ef6875850ddbeb52aad860641f28eaa98ef4b8857ddc343264afa5d4cf \ 2021-12-23 11:27:15 gpg[17680] DBG: 2eaef03414d428ba61d1f853bae52b201efb96a0bbd53ac983828dd496dea58d \ 2021-12-23 11:27:15 gpg[17680] DBG: eccce4abea90a71d458503560610e56695c7fceb184d90cb58b630455fd06575 \ 2021-12-23 11:27:15 gpg[17680] DBG: 12a5936701be736b2a9a25c3a8dcdf978943fa4fe8bb68e83a9056f6e728307a \ 2021-12-23 11:27:15 gpg[17680] DBG: c62bbddd1f7dd43d32d4bf91ad21f9b529d3848dcb68bba3e52375d3e3ad3dd4 \ 2021-12-23 11:27:15 gpg[17680] DBG: 583104f4036545b7392a8d2a0aceca1afc9e255988c3d61dd8533626b5bea305 \ 2021-12-23 11:27:15 gpg[17680] DBG: e99dc419867ffbf4595b5ba46002710a6a4b674bb59067f5f365ef5593f61a6a \ 2021-12-23 11:27:15 gpg[17680] DBG: 4368509e2cc76d7b40e117b1de712ae0ee3ab18fa67feaa912859d6ccd0fb409 \ 2021-12-23 11:27:15 gpg[17680] DBG: 815ececc524de605bf5add5ee6110b618276c7b266ccdf8eac978884d8277529 2021-12-23 11:27:15 gpg[17680] DBG: rsa_verify n:+d2429b711a2026f990e0149167c6f5ff8ee0666b51836d4787b28c24cbfeb3ed \ 2021-12-23 11:27:15 gpg[17680] DBG: 700075abd721112c0c83fafb48153e0f54cca6e5e9f2223584a61e879facc16e \ 2021-12-23 11:27:15 gpg[17680] DBG: 3b322419bc575e9d2c66561a9560b8f18787410d4d5afe1b30c7f269e4bd4a34 \ 2021-12-23 11:27:15 gpg[17680] DBG: 593879181c8fd65547886f6daa04ae9c3e377bd01993440d308fa588ddeffa8e \ 2021-12-23 11:27:15 gpg[17680] DBG: 7fbec190a85716e2cc10558f2dad18027816904dc33a47814064c7697be34708 \ 2021-12-23 11:27:15 gpg[17680] DBG: 217791bbd357f9ac5136451b4e167825514a87d3a820e2b95788508153de9f1a \ 2021-12-23 11:27:15 gpg[17680] DBG: 4ed21cd5c9f5f87d042dbf65225eb4206729128f7e20cdc014a04b1ef342c9fe \ 2021-12-23 11:27:15 gpg[17680] DBG: 186746c68388a09676cdd5ec4e21a0c3f673c15014464c8e7c69eb343aa00638 \ 2021-12-23 11:27:15 gpg[17680] DBG: 2331d3e2cb8a0ffb6c655b98f85961f6a2397dd18c794d9102f7df8aa7e06a27 \ 2021-12-23 11:27:15 gpg[17680] DBG: ddf6e78ed934b7e5fad06f044228d7bacb865e33bdcf842c3c2d8d4277b77a55 \ 2021-12-23 11:27:15 gpg[17680] DBG: 975b8bf6e24bc6516dc09df3968339eac1170839991cb50276665c1c2c323cfc \ 2021-12-23 11:27:15 gpg[17680] DBG: 5093ede4f29fc24a83dfb4e1a80e89eeed8070f9c46084a91493590b0c9e09e3 2021-12-23 11:27:15 gpg[17680] DBG: rsa_verify e:+010001 2021-12-23 11:27:15 gpg[17680] DBG: rsa_verify cmp:+01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[17680] DBG: ffffffffffffffffffffff003031300d060960864801650304020105000420e0 \ 2021-12-23 11:27:15 gpg[17680] DBG: 25c36493f6a0b0b9d387652d947b7ebfa44c8e84f696331b475fec9720806f 2021-12-23 11:27:15 gpg[17680] DBG: rsa_verify => Good 2021-12-23 11:27:15 gpg[17680] DBG: free_packet() type=6 2021-12-23 11:27:15 gpg[17680] DBG: free_packet() type=13 2021-12-23 11:27:15 gpg[17680] DBG: free_packet() type=2 2021-12-23 11:27:15 gpg[17680] DBG: free_packet() type=14 2021-12-23 11:27:15 gpg[17680] DBG: free_packet() type=2 2021-12-23 11:27:15 gpg[17680] DBG: [no clock] keydb_search enter 2021-12-23 11:27:15 gpg[17680] DBG: keydb_search: 1 search descriptions: 2021-12-23 11:27:15 gpg[17680] DBG: keydb_search 0: NEXT 2021-12-23 11:27:15 gpg[17680] DBG: internal_keydb_search: searching keybox (resource 0 of 1) 2021-12-23 11:27:15 gpg[17680] DBG: internal_keydb_search: searched keybox (resource 0 of 1) => EOF 2021-12-23 11:27:15 gpg[17680] DBG: [no clock] keydb_search leave (not found) 2021-12-23 11:27:15 gpg[17680] DBG: [no clock] keydb_release 2021-12-23 11:27:15 gpg[17680] DBG: [no clock] stop 2021-12-23 11:27:15 gpg[17680] keydb: handles=1 locks=0 parse=2 get=2 2021-12-23 11:27:15 gpg[17680] build=0 update=0 insert=0 delete=0 2021-12-23 11:27:15 gpg[17680] reset=1 found=2 not=1 cache=0 not=0 2021-12-23 11:27:15 gpg[17680] kid_not_found_cache: count=0 peak=0 flushes=0 2021-12-23 11:27:15 gpg[17680] sig_cache: total=4 cached=2 good=2 bad=0 2021-12-23 11:27:15 gpg[17680] objcache: keys=0/0/0 chains=0,0..0 buckets=0/0 attic=0 2021-12-23 11:27:15 gpg[17680] objcache: uids=0/0/0 chains=0,0..0 buckets=0/0 2021-12-23 11:27:15 gpg[17680] random usage: poolsize=600 mixed=0 polls=0/0 added=0/0 outmix=0 getlvl1=0/0 getlvl2=0/0 2021-12-23 11:27:15 gpg[17680] rndjent stat: collector=0x00000000 calls=0 bytes=0 2021-12-23 11:27:15 gpg[17680] secmem usage: 0/32768 bytes in 0 blocks 2021-12-23 11:27:15 gpg[18260] using character set 'utf-8' 2021-12-23 11:27:15 gpg[18260] Note: RFC4880bis features are enabled. 2021-12-23 11:27:15 gpg[18260] enabled debug flags: packet mpi crypto filter iobuf memory cache memstat trust hashing ipc clock lookup extprog 2021-12-23 11:27:15 gpg[18260] DBG: [no clock] start 2021-12-23 11:27:15 gpg[18260] using pgp trust model 2021-12-23 11:27:15 gpg[18260] key F82A7011A81784E3: accepted as trusted key 2021-12-23 11:27:15 gpg[18260] DBG: [no clock] keydb_new 2021-12-23 11:27:15 gpg[18260] DBG: [no clock] keydb_search_reset 2021-12-23 11:27:15 gpg[18260] DBG: keydb_search_reset (hd=0x02b1a2e0) 2021-12-23 11:27:15 gpg[18260] DBG: [no clock] keydb_search enter 2021-12-23 11:27:15 gpg[18260] DBG: keydb_search: 1 search descriptions: 2021-12-23 11:27:15 gpg[18260] DBG: keydb_search 0: FIRST 2021-12-23 11:27:15 gpg[18260] DBG: internal_keydb_search: searching keybox (resource 0 of 1) 2021-12-23 11:27:15 gpg[18260] DBG: internal_keydb_search: searched keybox (resource 0 of 1) => Success 2021-12-23 11:27:15 gpg[18260] DBG: [no clock] keydb_search leave (found) 2021-12-23 11:27:15 gpg[18260] DBG: [no clock] keydb_get_keyblock enter 2021-12-23 11:27:15 gpg[18260] DBG: parse_packet(iob=1): type=6 length=397 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[18260] DBG: parse_packet(iob=1): type=12 length=12 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[18260] DBG: parse_packet(iob=1): type=13 length=47 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[18260] DBG: parse_packet(iob=1): type=12 length=12 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[18260] DBG: parse_packet(iob=1): type=2 length=468 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[18260] DBG: parse_packet(iob=1): type=12 length=6 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[18260] DBG: parse_packet(iob=1): type=2 length=566 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[18260] DBG: parse_packet(iob=1): type=12 length=6 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[18260] DBG: parse_packet(iob=1): type=14 length=397 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[18260] DBG: parse_packet(iob=1): type=2 length=444 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[18260] DBG: parse_packet(iob=1): type=12 length=6 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[18260] DBG: iobuf-1.0: underflow: buffer size: 2388; still buffered: 0 => space for 2388 bytes 2021-12-23 11:27:15 gpg[18260] DBG: iobuf-1.0: close '?' 2021-12-23 11:27:15 gpg[18260] DBG: [no clock] keydb_get_keyblock leave 2021-12-23 11:27:15 gpg[18260] DBG: chan_0x0000026c <- OK Pleased to meet you 2021-12-23 11:27:15 gpg[18260] DBG: connection to the gpg-agent established 2021-12-23 11:27:15 gpg[18260] DBG: chan_0x0000026c -> RESET 2021-12-23 11:27:15 gpg[18260] DBG: chan_0x0000026c <- OK 2021-12-23 11:27:15 gpg[18260] DBG: chan_0x0000026c -> OPTION ttyname=/dev/tty 2021-12-23 11:27:15 gpg[18260] DBG: chan_0x0000026c <- OK 2021-12-23 11:27:15 gpg[18260] DBG: chan_0x0000026c -> GETINFO version 2021-12-23 11:27:15 gpg[18260] DBG: chan_0x0000026c <- D 2.3.4 2021-12-23 11:27:15 gpg[18260] DBG: chan_0x0000026c <- OK 2021-12-23 11:27:15 gpg[18260] DBG: chan_0x0000026c -> OPTION allow-pinentry-notify 2021-12-23 11:27:15 gpg[18260] DBG: chan_0x0000026c <- OK 2021-12-23 11:27:15 gpg[18260] DBG: chan_0x0000026c -> OPTION agent-awareness=2.1.0 2021-12-23 11:27:15 gpg[18260] DBG: chan_0x0000026c <- OK 2021-12-23 11:27:15 gpg[18260] DBG: chan_0x0000026c -> HAVEKEY --list=1000 2021-12-23 11:27:15 gpg[18260] DBG: chan_0000026C <- [ 44 20 16 7e 99 2a d0 5c e3 78 5d aa dd 48 f7 36 ...(28 byte(s) skipped) ] 2021-12-23 11:27:15 gpg[18260] DBG: chan_0x0000026c <- OK 2021-12-23 11:27:15 gpg[18260] DBG: get_keygrip for public key 2021-12-23 11:27:15 gpg[18260] DBG: keygrip= b5c5d84ced38925bff90debb4d828de8aa003d84 2021-12-23 11:27:15 gpg[18260] DBG: get_keygrip for public key 2021-12-23 11:27:15 gpg[18260] DBG: keygrip= cc55afcc2c73df7231a53171c5e8a3192ad6eca8 2021-12-23 11:27:15 gpg[18260] DBG: get_keygrip for public key 2021-12-23 11:27:15 gpg[18260] DBG: keygrip= b5c5d84ced38925bff90debb4d828de8aa003d84 2021-12-23 11:27:15 gpg[18260] DBG: get_keygrip for public key 2021-12-23 11:27:15 gpg[18260] DBG: keygrip= cc55afcc2c73df7231a53171c5e8a3192ad6eca8 2021-12-23 11:27:15 gpg[18260] DBG: free_packet() type=6 2021-12-23 11:27:15 gpg[18260] DBG: free_packet() type=13 2021-12-23 11:27:15 gpg[18260] DBG: free_packet() type=2 2021-12-23 11:27:15 gpg[18260] DBG: free_packet() type=2 2021-12-23 11:27:15 gpg[18260] DBG: free_packet() type=14 2021-12-23 11:27:15 gpg[18260] DBG: free_packet() type=2 2021-12-23 11:27:15 gpg[18260] DBG: [no clock] keydb_search enter 2021-12-23 11:27:15 gpg[18260] DBG: keydb_search: 1 search descriptions: 2021-12-23 11:27:15 gpg[18260] DBG: keydb_search 0: NEXT 2021-12-23 11:27:15 gpg[18260] DBG: internal_keydb_search: searching keybox (resource 0 of 1) 2021-12-23 11:27:15 gpg[18260] DBG: internal_keydb_search: searched keybox (resource 0 of 1) => Success 2021-12-23 11:27:15 gpg[18260] DBG: [no clock] keydb_search leave (found) 2021-12-23 11:27:15 gpg[18260] DBG: [no clock] keydb_get_keyblock enter 2021-12-23 11:27:15 gpg[18260] DBG: parse_packet(iob=2): type=6 length=397 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[18260] DBG: parse_packet(iob=2): type=12 length=12 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[18260] DBG: parse_packet(iob=2): type=13 length=31 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[18260] DBG: parse_packet(iob=2): type=12 length=12 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[18260] DBG: parse_packet(iob=2): type=2 length=472 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[18260] DBG: parse_packet(iob=2): type=12 length=6 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[18260] DBG: parse_packet(iob=2): type=14 length=397 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[18260] DBG: parse_packet(iob=2): type=2 length=444 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[18260] DBG: parse_packet(iob=2): type=12 length=6 (parse./home/wk/b/gnupg/dist/PLAY-release/gnupg-w32-2.3.4/g10/keydb.c.1161) 2021-12-23 11:27:15 gpg[18260] DBG: iobuf-2.0: underflow: buffer size: 1799; still buffered: 0 => space for 1799 bytes 2021-12-23 11:27:15 gpg[18260] DBG: iobuf-2.0: close '?' 2021-12-23 11:27:15 gpg[18260] DBG: [no clock] keydb_get_keyblock leave 2021-12-23 11:27:15 gpg[18260] DBG: get_keygrip for public key 2021-12-23 11:27:15 gpg[18260] DBG: keygrip= a04d691688b19d284309134aecaf4f1c4584f52a 2021-12-23 11:27:15 gpg[18260] DBG: rsa_verify data:+01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffff003031300d0609608648016503040201050004207d \ 2021-12-23 11:27:15 gpg[18260] DBG: 9a68e639a33113a5d96e6e603c922e3819aca5dc26611c15e24909988c8a7f 2021-12-23 11:27:15 gpg[18260] DBG: rsa_verify sig:+090da0d3f65b75d4ea3f8672d0a9836c5e5578bc54275ca49336157569bd8bcf \ 2021-12-23 11:27:15 gpg[18260] DBG: 4bd78791867a9d6b6a7235ac74a7172490d9b2cf8d204753e7a27e81db949e49 \ 2021-12-23 11:27:15 gpg[18260] DBG: 80e7f0b2c28ec1e06e34eb4a86cbe41bf74ce4354b01e9f1b05637788b0f2831 \ 2021-12-23 11:27:15 gpg[18260] DBG: 647ba8c66aee7d89248a9685b170c71c2374baf49eb53bff97c25489ad074521 \ 2021-12-23 11:27:15 gpg[18260] DBG: 44dfdc325d04478525c014569a54bdb5890db28d282f308af9f4d25b119031f5 \ 2021-12-23 11:27:15 gpg[18260] DBG: 54a5cc75587566c04b7a152a4b22b7d3d920c486e635f482ffc5de32bc15c25e \ 2021-12-23 11:27:15 gpg[18260] DBG: 131d11d1ec1572421d4decc7443c67546a1715fbacdbc683cadb4279bd0180c1 \ 2021-12-23 11:27:15 gpg[18260] DBG: 28d6c319f50a0375243befca9e15f25be25d126c47c5215b276e4813aab38d6a \ 2021-12-23 11:27:15 gpg[18260] DBG: 569ed09c42be135339058cce8e9e10a7defba0224b85e3c1c0c493979d5ada67 \ 2021-12-23 11:27:15 gpg[18260] DBG: 221c024e452ffa89d7f7c9028aeb06513d1991080f2368e9f5a9453b7a4d573c \ 2021-12-23 11:27:15 gpg[18260] DBG: 13d114650780163e7377616b01529727f17c646fb3d12b503c0741693020a44a \ 2021-12-23 11:27:15 gpg[18260] DBG: 81b3b2d2f6f6c5cdd9e661c2410515faa23e3a66a7b83f4a1ee4ff8af6422a58 2021-12-23 11:27:15 gpg[18260] DBG: rsa_verify n:+d2429b711a2026f990e0149167c6f5ff8ee0666b51836d4787b28c24cbfeb3ed \ 2021-12-23 11:27:15 gpg[18260] DBG: 700075abd721112c0c83fafb48153e0f54cca6e5e9f2223584a61e879facc16e \ 2021-12-23 11:27:15 gpg[18260] DBG: 3b322419bc575e9d2c66561a9560b8f18787410d4d5afe1b30c7f269e4bd4a34 \ 2021-12-23 11:27:15 gpg[18260] DBG: 593879181c8fd65547886f6daa04ae9c3e377bd01993440d308fa588ddeffa8e \ 2021-12-23 11:27:15 gpg[18260] DBG: 7fbec190a85716e2cc10558f2dad18027816904dc33a47814064c7697be34708 \ 2021-12-23 11:27:15 gpg[18260] DBG: 217791bbd357f9ac5136451b4e167825514a87d3a820e2b95788508153de9f1a \ 2021-12-23 11:27:15 gpg[18260] DBG: 4ed21cd5c9f5f87d042dbf65225eb4206729128f7e20cdc014a04b1ef342c9fe \ 2021-12-23 11:27:15 gpg[18260] DBG: 186746c68388a09676cdd5ec4e21a0c3f673c15014464c8e7c69eb343aa00638 \ 2021-12-23 11:27:15 gpg[18260] DBG: 2331d3e2cb8a0ffb6c655b98f85961f6a2397dd18c794d9102f7df8aa7e06a27 \ 2021-12-23 11:27:15 gpg[18260] DBG: ddf6e78ed934b7e5fad06f044228d7bacb865e33bdcf842c3c2d8d4277b77a55 \ 2021-12-23 11:27:15 gpg[18260] DBG: 975b8bf6e24bc6516dc09df3968339eac1170839991cb50276665c1c2c323cfc \ 2021-12-23 11:27:15 gpg[18260] DBG: 5093ede4f29fc24a83dfb4e1a80e89eeed8070f9c46084a91493590b0c9e09e3 2021-12-23 11:27:15 gpg[18260] DBG: rsa_verify e:+010001 2021-12-23 11:27:15 gpg[18260] DBG: rsa_verify cmp:+01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffff003031300d0609608648016503040201050004207d \ 2021-12-23 11:27:15 gpg[18260] DBG: 9a68e639a33113a5d96e6e603c922e3819aca5dc26611c15e24909988c8a7f 2021-12-23 11:27:15 gpg[18260] DBG: rsa_verify => Good 2021-12-23 11:27:15 gpg[18260] DBG: rsa_verify data:+01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffff003031300d060960864801650304020105000420e0 \ 2021-12-23 11:27:15 gpg[18260] DBG: 25c36493f6a0b0b9d387652d947b7ebfa44c8e84f696331b475fec9720806f 2021-12-23 11:27:15 gpg[18260] DBG: rsa_verify sig:+21aebadc451c681cf4badb2db3bc66470e2c62687a8b92af65b86a1c6b73d804 \ 2021-12-23 11:27:15 gpg[18260] DBG: 55e40d88750a1cc6fb5337639ef28d5869a5349d408bd9e20b795de26c9969e7 \ 2021-12-23 11:27:15 gpg[18260] DBG: 067cc3d7ce4b7c86456464e9dd6e47b839536932fe521b3bdbd50bed9dbe8c79 \ 2021-12-23 11:27:15 gpg[18260] DBG: 1b3005ef6875850ddbeb52aad860641f28eaa98ef4b8857ddc343264afa5d4cf \ 2021-12-23 11:27:15 gpg[18260] DBG: 2eaef03414d428ba61d1f853bae52b201efb96a0bbd53ac983828dd496dea58d \ 2021-12-23 11:27:15 gpg[18260] DBG: eccce4abea90a71d458503560610e56695c7fceb184d90cb58b630455fd06575 \ 2021-12-23 11:27:15 gpg[18260] DBG: 12a5936701be736b2a9a25c3a8dcdf978943fa4fe8bb68e83a9056f6e728307a \ 2021-12-23 11:27:15 gpg[18260] DBG: c62bbddd1f7dd43d32d4bf91ad21f9b529d3848dcb68bba3e52375d3e3ad3dd4 \ 2021-12-23 11:27:15 gpg[18260] DBG: 583104f4036545b7392a8d2a0aceca1afc9e255988c3d61dd8533626b5bea305 \ 2021-12-23 11:27:15 gpg[18260] DBG: e99dc419867ffbf4595b5ba46002710a6a4b674bb59067f5f365ef5593f61a6a \ 2021-12-23 11:27:15 gpg[18260] DBG: 4368509e2cc76d7b40e117b1de712ae0ee3ab18fa67feaa912859d6ccd0fb409 \ 2021-12-23 11:27:15 gpg[18260] DBG: 815ececc524de605bf5add5ee6110b618276c7b266ccdf8eac978884d8277529 2021-12-23 11:27:15 gpg[18260] DBG: rsa_verify n:+d2429b711a2026f990e0149167c6f5ff8ee0666b51836d4787b28c24cbfeb3ed \ 2021-12-23 11:27:15 gpg[18260] DBG: 700075abd721112c0c83fafb48153e0f54cca6e5e9f2223584a61e879facc16e \ 2021-12-23 11:27:15 gpg[18260] DBG: 3b322419bc575e9d2c66561a9560b8f18787410d4d5afe1b30c7f269e4bd4a34 \ 2021-12-23 11:27:15 gpg[18260] DBG: 593879181c8fd65547886f6daa04ae9c3e377bd01993440d308fa588ddeffa8e \ 2021-12-23 11:27:15 gpg[18260] DBG: 7fbec190a85716e2cc10558f2dad18027816904dc33a47814064c7697be34708 \ 2021-12-23 11:27:15 gpg[18260] DBG: 217791bbd357f9ac5136451b4e167825514a87d3a820e2b95788508153de9f1a \ 2021-12-23 11:27:15 gpg[18260] DBG: 4ed21cd5c9f5f87d042dbf65225eb4206729128f7e20cdc014a04b1ef342c9fe \ 2021-12-23 11:27:15 gpg[18260] DBG: 186746c68388a09676cdd5ec4e21a0c3f673c15014464c8e7c69eb343aa00638 \ 2021-12-23 11:27:15 gpg[18260] DBG: 2331d3e2cb8a0ffb6c655b98f85961f6a2397dd18c794d9102f7df8aa7e06a27 \ 2021-12-23 11:27:15 gpg[18260] DBG: ddf6e78ed934b7e5fad06f044228d7bacb865e33bdcf842c3c2d8d4277b77a55 \ 2021-12-23 11:27:15 gpg[18260] DBG: 975b8bf6e24bc6516dc09df3968339eac1170839991cb50276665c1c2c323cfc \ 2021-12-23 11:27:15 gpg[18260] DBG: 5093ede4f29fc24a83dfb4e1a80e89eeed8070f9c46084a91493590b0c9e09e3 2021-12-23 11:27:15 gpg[18260] DBG: rsa_verify e:+010001 2021-12-23 11:27:15 gpg[18260] DBG: rsa_verify cmp:+01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2021-12-23 11:27:15 gpg[18260] DBG: ffffffffffffffffffffff003031300d060960864801650304020105000420e0 \ 2021-12-23 11:27:15 gpg[18260] DBG: 25c36493f6a0b0b9d387652d947b7ebfa44c8e84f696331b475fec9720806f 2021-12-23 11:27:15 gpg[18260] DBG: rsa_verify => Good 2021-12-23 11:27:15 gpg[18260] DBG: get_keygrip for public key 2021-12-23 11:27:15 gpg[18260] DBG: keygrip= a04d691688b19d284309134aecaf4f1c4584f52a 2021-12-23 11:27:15 gpg[18260] DBG: chan_0x0000026c -> KEYINFO A04D691688B19D284309134AECAF4F1C4584F52A 2021-12-23 11:27:15 gpg[18260] DBG: chan_0x0000026c <- S KEYINFO A04D691688B19D284309134AECAF4F1C4584F52A D - - - P - - - 2021-12-23 11:27:15 gpg[18260] DBG: chan_0x0000026c <- OK 2021-12-23 11:27:15 gpg[18260] DBG: get_keygrip for public key 2021-12-23 11:27:15 gpg[18260] DBG: keygrip= 167e992ad05ce3785daadd48f736fc0d1283e241 2021-12-23 11:27:15 gpg[18260] DBG: chan_0x0000026c -> KEYINFO 167E992AD05CE3785DAADD48F736FC0D1283E241 2021-12-23 11:27:15 gpg[18260] DBG: chan_0x0000026c <- S KEYINFO 167E992AD05CE3785DAADD48F736FC0D1283E241 D - - - P - - - 2021-12-23 11:27:15 gpg[18260] DBG: chan_0x0000026c <- OK 2021-12-23 11:27:15 gpg[18260] DBG: free_packet() type=6 2021-12-23 11:27:15 gpg[18260] DBG: free_packet() type=13 2021-12-23 11:27:15 gpg[18260] DBG: free_packet() type=2 2021-12-23 11:27:15 gpg[18260] DBG: free_packet() type=14 2021-12-23 11:27:15 gpg[18260] DBG: free_packet() type=2 2021-12-23 11:27:15 gpg[18260] DBG: [no clock] keydb_search enter 2021-12-23 11:27:15 gpg[18260] DBG: keydb_search: 1 search descriptions: 2021-12-23 11:27:15 gpg[18260] DBG: keydb_search 0: NEXT 2021-12-23 11:27:15 gpg[18260] DBG: internal_keydb_search: searching keybox (resource 0 of 1) 2021-12-23 11:27:15 gpg[18260] DBG: internal_keydb_search: searched keybox (resource 0 of 1) => EOF 2021-12-23 11:27:15 gpg[18260] DBG: [no clock] keydb_search leave (not found) 2021-12-23 11:27:15 gpg[18260] DBG: [no clock] keydb_release 2021-12-23 11:27:15 gpg[18260] DBG: [no clock] stop 2021-12-23 11:27:15 gpg[18260] keydb: handles=1 locks=0 parse=2 get=2 2021-12-23 11:27:15 gpg[18260] build=0 update=0 insert=0 delete=0 2021-12-23 11:27:15 gpg[18260] reset=1 found=2 not=1 cache=0 not=0 2021-12-23 11:27:15 gpg[18260] kid_not_found_cache: count=0 peak=0 flushes=0 2021-12-23 11:27:15 gpg[18260] sig_cache: total=4 cached=2 good=2 bad=0 2021-12-23 11:27:15 gpg[18260] objcache: keys=0/0/0 chains=0,0..0 buckets=0/0 attic=0 2021-12-23 11:27:15 gpg[18260] objcache: uids=0/0/0 chains=0,0..0 buckets=0/0 2021-12-23 11:27:15 gpg[18260] random usage: poolsize=600 mixed=0 polls=0/0 added=0/0 outmix=0 getlvl1=0/0 getlvl2=0/0 2021-12-23 11:27:15 gpg[18260] rndjent stat: collector=0x00000000 calls=0 bytes=0 2021-12-23 11:27:15 gpg[18260] secmem usage: 0/32768 bytes in 0 blocks 2021-12-23 11:27:30 gpg[12864] using character set 'utf-8' 2021-12-23 11:27:30 gpg[12864] Note: RFC4880bis features are enabled. 2021-12-23 11:27:30 gpg[12864] enabled debug flags: packet mpi crypto filter iobuf memory cache memstat trust hashing ipc clock lookup extprog 2021-12-23 11:27:30 gpg[12864] DBG: [no clock] start 2021-12-23 11:27:30 gpg[12864] DBG: chan_0x0000025c <- # Home: C:\Users\Oleksandr\AppData\Roaming\gnupg 2021-12-23 11:27:30 gpg[12864] DBG: chan_0x0000025c <- # Config: C:/Users/Oleksandr/AppData/Roaming/gnupg/dirmngr.conf 2021-12-23 11:27:30 gpg[12864] DBG: chan_0x0000025c <- OK Dirmngr 2.3.4 at your service 2021-12-23 11:27:30 gpg[12864] DBG: connection to the dirmngr established 2021-12-23 11:27:30 gpg[12864] DBG: chan_0x0000025c -> GETINFO version 2021-12-23 11:27:30 gpg[12864] DBG: chan_0x0000025c <- D 2.3.4 2021-12-23 11:27:30 gpg[12864] DBG: chan_0x0000025c <- OK 2021-12-23 11:27:30 gpg[12864] DBG: chan_0x0000025c -> KEYSERVER --clear hkps://gpg.example.com/ 2021-12-23 11:27:30 gpg[12864] DBG: chan_0x0000025c <- OK 2021-12-23 11:27:30 gpg[12864] DBG: chan_0x0000025c -> KS_SEARCH -- oleksandr at example.com 2021-12-23 11:27:30 gpg[12864] DBG: chan_0x0000025c <- ERR 167772261 Certificate expired 2021-12-23 11:27:30 gpg[12864] error searching keyserver: Certificate expired 2021-12-23 11:27:30 gpg[12864] keyserver search failed: Certificate expired 2021-12-23 11:27:30 gpg[12864] DBG: chan_0x0000025c -> BYE 2021-12-23 11:27:30 gpg[12864] DBG: [no clock] stop 2021-12-23 11:27:30 gpg[12864] keydb: handles=0 locks=0 parse=0 get=0 2021-12-23 11:27:30 gpg[12864] build=0 update=0 insert=0 delete=0 2021-12-23 11:27:30 gpg[12864] reset=0 found=0 not=0 cache=0 not=0 2021-12-23 11:27:30 gpg[12864] kid_not_found_cache: count=0 peak=0 flushes=0 2021-12-23 11:27:30 gpg[12864] sig_cache: total=0 cached=0 good=0 bad=0 2021-12-23 11:27:30 gpg[12864] objcache: keys=0/0/0 chains=0,0..0 buckets=0/0 attic=0 2021-12-23 11:27:30 gpg[12864] objcache: uids=0/0/0 chains=0,0..0 buckets=0/0 2021-12-23 11:27:30 gpg[12864] random usage: poolsize=600 mixed=0 polls=0/0 added=0/0 outmix=0 getlvl1=0/0 getlvl2=0/0 2021-12-23 11:27:30 gpg[12864] rndjent stat: collector=0x00000000 calls=0 bytes=0 2021-12-23 11:27:30 gpg[12864] secmem usage: 0/32768 bytes in 0 blocks Virus-free. www.avast.com <#m_8829319104948773264_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gpg_cert.png Type: image/png Size: 192691 bytes Desc: not available URL: From andrewg at andrewg.com Fri Dec 24 14:56:38 2021 From: andrewg at andrewg.com (Andrew Gallagher) Date: Fri, 24 Dec 2021 13:56:38 +0000 Subject: issue with gpg4win In-Reply-To: References: Message-ID: <7063791e90577cabd848e67049b0480531f1c3cd.camel@andrewg.com> On Thu, 2021-12-23 at 12:37 +0200, Alex Nadtoka via Gnupg-users wrote: > 2021-12-23 11:27:30 gpg[12864] DBG: chan_0x0000025c -> KEYSERVER -- > clear hkps://gpg.example.com/ This doesn't look like a real keyserver. Did you redact this, or is this really what is currently configured in dirmngr.conf? If you currently have "pool.sks-keyservers.net" configured in dirmngr.conf, please note that it has been deprecated for some time. Try a known working keyserver such as keyserver.ubuntu.com or pgpkeys.eu instead, and see if it works better. A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 862 bytes Desc: This is a digitally signed message part URL: From andrewg at andrewg.com Fri Dec 24 15:49:57 2021 From: andrewg at andrewg.com (Andrew Gallagher) Date: Fri, 24 Dec 2021 14:49:57 +0000 Subject: issue with gpg4win In-Reply-To: References: Message-ID: > 2021-12-23 11:27:30 gpg[12864] DBG: connection to the dirmngr established > 2021-12-23 11:27:30 gpg[12864] DBG: chan_0x0000025c -> GETINFO version > 2021-12-23 11:27:30 gpg[12864] DBG: chan_0x0000025c <- D 2.3.4 > 2021-12-23 11:27:30 gpg[12864] DBG: chan_0x0000025c <- OK > 2021-12-23 11:27:30 gpg[12864] DBG: chan_0x0000025c -> KEYSERVER --clear hkps://gpg.example.com/ > 2021-12-23 11:27:30 gpg[12864] DBG: chan_0x0000025c <- OK > 2021-12-23 11:27:30 gpg[12864] DBG: chan_0x0000025c -> KS_SEARCH -- oleksandr at example.com > 2021-12-23 11:27:30 gpg[12864] DBG: chan_0x0000025c <- ERR 167772261 Certificate expired > 2021-12-23 11:27:30 gpg[12864] error searching keyserver: Certificate expired > 2021-12-23 11:27:30 gpg[12864] keyserver search failed: Certificate expired > 2021-12-23 11:27:30 gpg[12864] DBG: chan_0x0000025c -> BYE OK, so I can see from the image that you?re not actually using example.com, fair enough :-) I do notice that your chosen keyserver is using a recently-issued letsencrypt certificate. There is a known issue with Letsencrypt certificates due to the replacement of their upstream CA and a known bug in openssl. Are you able to upgrade openssl and the ca-certificates bundle on your client machine? A -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.nadtoka at gmail.com Sat Dec 25 12:24:07 2021 From: alex.nadtoka at gmail.com (Alex Nadtoka) Date: Sat, 25 Dec 2021 13:24:07 +0200 Subject: issue with gpg4win In-Reply-To: References: Message-ID: Hi Andrew, yes I have changed the real name of my mailbox and the server) Thanks for the reply. My Client Machine is Windows . If you can tell me how to do that I would appreciate it. Thanks again for the update) Finally got some help. Sorry for all these troubles and Merry Christmas Regards, Oleksandr ??, 24 ????. 2021 ?. ? 16:50 Andrew Gallagher via Gnupg-users < gnupg-users at gnupg.org> ????: > > 2021-12-23 11:27:30 gpg[12864] DBG: connection to the dirmngr established > 2021-12-23 11:27:30 gpg[12864] DBG: chan_0x0000025c -> GETINFO version > 2021-12-23 11:27:30 gpg[12864] DBG: chan_0x0000025c <- D 2.3.4 > 2021-12-23 11:27:30 gpg[12864] DBG: chan_0x0000025c <- OK > 2021-12-23 11:27:30 gpg[12864] DBG: chan_0x0000025c -> KEYSERVER --clear > hkps://gpg.example.com/ > 2021-12-23 11:27:30 gpg[12864] DBG: chan_0x0000025c <- OK > 2021-12-23 11:27:30 gpg[12864] DBG: chan_0x0000025c -> KS_SEARCH -- > oleksandr at example.com > 2021-12-23 11:27:30 gpg[12864] DBG: chan_0x0000025c <- ERR 167772261 > Certificate expired > 2021-12-23 11:27:30 gpg[12864] error searching keyserver: Certificate > expired > 2021-12-23 11:27:30 gpg[12864] keyserver search failed: Certificate expired > 2021-12-23 11:27:30 gpg[12864] DBG: chan_0x0000025c -> BYE > > > OK, so I can see from the image that you?re not actually using example.com, > fair enough :-) I do notice that your chosen keyserver is using a > recently-issued letsencrypt certificate. There is a known issue with > Letsencrypt certificates due to the replacement of their upstream CA and a > known bug in openssl. Are you able to upgrade openssl and the > ca-certificates bundle on your client machine? > > A > _______________________________________________ > 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 andrewg at andrewg.com Sat Dec 25 19:08:06 2021 From: andrewg at andrewg.com (Andrew Gallagher) Date: Sat, 25 Dec 2021 18:08:06 +0000 Subject: issue with gpg4win In-Reply-To: References: Message-ID: <412B983A-EEEF-4B03-84E2-724D2B4F6E52@andrewg.com> > On 25 Dec 2021, at 11:24, Alex Nadtoka wrote: > > ? > Hi Andrew, yes I have changed the real name of my mailbox and the server) Thanks for the reply. > My Client Machine is Windows . If you can tell me how to do that I would appreciate it. Thanks again for the update) > Finally got some help. I haven?t had to do this myself on windows, so I?m not an expert; if you have windows update enabled it should get fixed automatically. If for whatever reason you aren?t getting updates you could try something like this: https://www.stephenwagner.com/2021/09/30/sophos-dst-root-ca-x3-expiration-problems-fix/ > Sorry for all these troubles and Merry Christmas Merry Christmas! A -------------- next part -------------- An HTML attachment was scrubbed... URL: From x10an14 at gmail.com Sun Dec 26 04:47:09 2021 From: x10an14 at gmail.com (Christian Chavez) Date: Sun, 26 Dec 2021 04:47:09 +0100 Subject: Is it possible to require two private keys to decrypt with gpg? Message-ID: Hi! I've currently got some sensitive data I'd like to require _two_ gpg keys for decryption/unlocking. As in both are needed (AND operation), not that either can decrypt on their own (OR operation). I can only find description of AND operation in manpages/tutorials online. I'm hoping for a solution which doesn't just require encrypting twice (though I admit that will give the same security benefit). The reason why I'd like a "single gpg command solution" is the hope that such a magical incantation would play well with other tools, such as pass for passwordstore (e.g.). Anyone on this mailing list got any tips on how that might be achieved? -- Med vennlig hilsen/Kind regards, Christian Chavez Phone/Tlf: +47 922 22 603 -------------- next part -------------- An HTML attachment was scrubbed... URL: From x10an14 at gmail.com Sun Dec 26 11:07:17 2021 From: x10an14 at gmail.com (Christian Chavez) Date: Sun, 26 Dec 2021 11:07:17 +0100 Subject: Unable to `keytocard` twice in a row (with an import between) Message-ID: Hi! So, I've come across either a bug, or a somewhat unfortunate wording in the man-pages I wanted to ask if it has been discussed before, before I spend any more effort learning man-pages' source and coming with a patch. I'm currently in the process of updating the expiry date on my gpg key's subkeys. So I import the backup files (noticing that there are two, one for the masterkey's secret key, and another one for the subkeys' secret keys), and decide to export them to _one_ file with `--export-secret-keys `. The man pages state: """ --export-secret-keys --export-secret-subkeys Same as --export, but exports the secret keys instead. The exported keys are written to STDOUT or to the file given with option --output. This command is often used along with the option --armor to allow for easy printing of the key for paper backup; however the external tool paperkey does a better job of creating backups on paper. Note that exporting a secret key can be a security risk if the exported keys are sent over an insecure channel. The second form of the command has the special property to render the secret part of the primary key useless; this is a GNU extension to OpenPGP and other implementations can not be expected to successfully import such a key. Its in? tended use is in generating a full key with an additional signing subkey on a dedicated machine. This command then exports the key without the primary key to the main machine. """ I don't see how to interpret that in any way other than that the output of `--export-secret-keys` is a superset of `--export-secret-subkeys`. So I export to _one_ file (as mentioned above), to simplify my life before I update the expiration date, and use `keytocard`. Deciding I'd like to confirm that I've got a working backup, I repeat the process, AKA import the file I just exported before running `keytocard`, and running `keytocard` again (just intending to overwrite with a new machine-local copy). But now I get: """ Replace existing key? (y/N) y gpg: KEYTOCARD failed: Unusable secret key """ There are several mentions of such symptoms online, but I found one particularly interesting one: https://dev.gnupg.org/T3391. Ignoring my newly created export of the secret keys, following the instructions in above link with the old file that _only_ had the subkeys, seem to work for me. Like I asked at the beginning of this sordid tale, anyone got any suggestions/tips/thoughts about this? I imagine this can be quite jarring and annoying for users who interpret the man-pages in the same way as I have (especially for new users who must have spent some time and effort ensuring they've got all their ducks in a row, just for this to fail here due to their understanding of the man-pages or the above bug). -- Med vennlig hilsen/Kind regards, Christian Chavez Phone/Tlf: +47 922 22 603 -------------- next part -------------- An HTML attachment was scrubbed... URL: From oscar at prutt.party Sun Dec 26 12:06:00 2021 From: oscar at prutt.party (Oscar Carlsson) Date: Sun, 26 Dec 2021 12:06:00 +0100 Subject: Is it possible to require two private keys to decrypt with gpg? In-Reply-To: References: Message-ID: Christian Chavez via Gnupg-users writes: > Hi! > > I've currently got some sensitive data I'd like to require _two_ gpg keys for decryption/unlocking. > > As in both are needed (AND operation), not that either can decrypt on their own (OR operation). > I can only find description of AND operation in manpages/tutorials online. > > I'm hoping for a solution which doesn't just require encrypting twice (though I admit that will give the same security benefit). > The reason why I'd like a "single gpg command solution" is the hope that such a magical incantation would play well with other tools, such as pass for > passwordstore (e.g.). > > Anyone on this mailing list got any tips on how that might be achieved? Hi, I think Shamir's Secret Sharing might be interesting to read up about - I'm not sure about it's support in GnuPG or similar, tho. https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing Regards, Oscar From khl at kenhlee.com Sun Dec 26 20:53:16 2021 From: khl at kenhlee.com (Kenneth H. Lee) Date: Sun, 26 Dec 2021 14:53:16 -0500 Subject: issue with gpg4win In-Reply-To: References: <412B983A-EEEF-4B03-84E2-724D2B4F6E52@andrewg.com> Message-ID: I forgot to mention that I installed gpg4win 4.0.0 which has gpg 2.3.4 Regards, *Ken* *Kenneth H. Lee, CISSP*Google Voice: +1 646 883 9195 KHL at KENHLEE dot COM On Sun, Dec 26, 2021 at 2:36 PM Kenneth H. Lee wrote: > I am having a similar issue on my Windows 11 system (upgraded from Windows > 10). > > I've tried with no luck > > - adding the 2 root CAs and the intermediate CA from the referenced > article > - deleted the expired DST Root CA X3 > - rebooted my system > > > Regards, > *Ken* > > > *Kenneth H. Lee, CISSP*Google Voice: +1 646 883 9195 > KHL at KENHLEE dot COM > > > On Sat, Dec 25, 2021 at 1:09 PM Andrew Gallagher via Gnupg-users < > gnupg-users at gnupg.org> wrote: > >> >> On 25 Dec 2021, at 11:24, Alex Nadtoka wrote: >> >> ? >> Hi Andrew, yes I have changed the real name of my mailbox and the server) >> Thanks for the reply. >> My Client Machine is Windows . If you can tell me how to do that I >> would appreciate it. Thanks again for the update) >> Finally got some help. >> >> >> I haven?t had to do this myself on windows, so I?m not an expert; if you >> have windows update enabled it should get fixed automatically. If for >> whatever reason you aren?t getting updates you could try something like >> this: >> >> >> https://www.stephenwagner.com/2021/09/30/sophos-dst-root-ca-x3-expiration-problems-fix/ >> >> Sorry for all these troubles and Merry Christmas >> >> >> Merry Christmas! >> >> A >> _______________________________________________ >> 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 khl at kenhlee.com Sun Dec 26 20:36:04 2021 From: khl at kenhlee.com (Kenneth H. Lee) Date: Sun, 26 Dec 2021 14:36:04 -0500 Subject: issue with gpg4win In-Reply-To: <412B983A-EEEF-4B03-84E2-724D2B4F6E52@andrewg.com> References: <412B983A-EEEF-4B03-84E2-724D2B4F6E52@andrewg.com> Message-ID: I am having a similar issue on my Windows 11 system (upgraded from Windows 10). I've tried with no luck - adding the 2 root CAs and the intermediate CA from the referenced article - deleted the expired DST Root CA X3 - rebooted my system Regards, *Ken* *Kenneth H. Lee, CISSP*Google Voice: +1 646 883 9195 KHL at KENHLEE dot COM On Sat, Dec 25, 2021 at 1:09 PM Andrew Gallagher via Gnupg-users < gnupg-users at gnupg.org> wrote: > > On 25 Dec 2021, at 11:24, Alex Nadtoka wrote: > > ? > Hi Andrew, yes I have changed the real name of my mailbox and the server) > Thanks for the reply. > My Client Machine is Windows . If you can tell me how to do that I > would appreciate it. Thanks again for the update) > Finally got some help. > > > I haven?t had to do this myself on windows, so I?m not an expert; if you > have windows update enabled it should get fixed automatically. If for > whatever reason you aren?t getting updates you could try something like > this: > > > https://www.stephenwagner.com/2021/09/30/sophos-dst-root-ca-x3-expiration-problems-fix/ > > Sorry for all these troubles and Merry Christmas > > > Merry Christmas! > > A > _______________________________________________ > 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 oub at mat.ucm.es Sun Dec 26 09:20:24 2021 From: oub at mat.ucm.es (Uwe Brauer) Date: Sun, 26 Dec 2021 09:20:24 +0100 Subject: gpgsm "Encrypt failed" "Unusable public key: 53A51054BB68F7C3" root certificate missing? Message-ID: <87bl13ydyv.fsf@mat.ucm.es> Hi I am on Ubuntu 16.04 running gpgsm (GnuPG) 2.1.11 libgcrypt 1.6.5 libksba 1.3.3-unknown I am also a die hard user of emacs and use it for encrypting and decrypting my mails. I received a smime message from a colleague (with his public key embedded of course). When I tried to send him a smime encrypted and signed message I obtained the lisp error: Debugger entered--Lisp error: (epg-error "Encrypt failed" "Unusable public key: 53A51054BB68F7C3") I suspect that the key was signed from an authority whose root certificate I don't posses. For example using thunderbird and opening his signed message, I see I also tried to run gpgsm -e -r arober at ucm.es epg-bug.txt But I receive gpgsm: enabled debug flags: ipc gpgsm: can't encrypt to 'arober at ucm.es': Ambiguous name secmem usage: 0/16384 bytes in 0 blocks I am not sure whether this connected, but I do have old certificates of this user. Any help would be strongly appreciated. Regards Uwe Brauer -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.png Type: image/png Size: 28207 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5673 bytes Desc: not available URL: From wk at gnupg.org Mon Dec 27 17:19:09 2021 From: wk at gnupg.org (Werner Koch) Date: Mon, 27 Dec 2021 17:19:09 +0100 Subject: gpgsm "Encrypt failed" "Unusable public key: 53A51054BB68F7C3" root certificate missing? In-Reply-To: <87bl13ydyv.fsf@mat.ucm.es> (Uwe Brauer via Gnupg-users's message of "Sun, 26 Dec 2021 09:20:24 +0100") References: <87bl13ydyv.fsf@mat.ucm.es> Message-ID: <87a6gm9g1u.fsf@wheatstone.g10code.de> On Sun, 26 Dec 2021 09:20, Uwe Brauer said: > gpgsm (GnuPG) 2.1.11 Please get a decent version. The LTS branch is currently at 2.2.33. Your version is 5 years old! 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 oub at mat.ucm.es Mon Dec 27 17:34:36 2021 From: oub at mat.ucm.es (Uwe Brauer) Date: Mon, 27 Dec 2021 17:34:36 +0100 Subject: [SOLVED] (was: gpgsm "Encrypt failed" "Unusable public key: 53A51054BB68F7C3" root certificate missing?) References: <87bl13ydyv.fsf@mat.ucm.es> Message-ID: <877dbq9fc3.fsf@mat.ucm.es> >>> "UBvG" == Uwe Brauer via Gnupg-users writes: > Hi > I am on Ubuntu 16.04 running > gpgsm (GnuPG) 2.1.11 > libgcrypt 1.6.5 > libksba 1.3.3-unknown > I am also a die hard user of emacs and use it for encrypting and > decrypting my mails. > I received a smime message from a colleague (with his public key > embedded of course). > When I tried to send him a smime encrypted and signed message I obtained > the lisp error: > Debugger entered--Lisp error: (epg-error "Encrypt failed" "Unusable public key: 53A51054BB68F7C3") It turned out that I indeed needed root certificate AC_Sector_Publico.cer That I imported via gpgsm --import *.cer Then everything was fine. Sorry for the noise. Regards Uwe Brauer -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5673 bytes Desc: not available URL: From x10an14 at gmail.com Mon Dec 27 18:52:42 2021 From: x10an14 at gmail.com (Christian Chavez) Date: Mon, 27 Dec 2021 18:52:42 +0100 Subject: Is it possible to require two private keys to decrypt with gpg? In-Reply-To: References: Message-ID: A small correction: On Sun, 26 Dec 2021, 04:47 Christian Chavez, wrote: (...) > As in both are needed (AND operation), not that either can decrypt on > their own (OR operation). > I can only find description of AND operation in manpages/tutorials online. > The second line is supposed to read "I can only find descriptions of OR operation in man pages/tutorials online. Apologies. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.nadtoka at gmail.com Wed Dec 29 13:33:14 2021 From: alex.nadtoka at gmail.com (Alex Nadtoka) Date: Wed, 29 Dec 2021 14:33:14 +0200 Subject: Gpg4win LetsEncrypt issue Message-ID: I cannot connect to any keyserver. The error is certificate expired. I am on latest (I think) Windows 10 . Tried reinstalling it or installing on new Windows machine but no luck . dirmngr keeps telling me that certificate is expired. I know I can put ignore-cert followed by the SHA-1 fingerprint of the problematic certificate in my dirmngr.conf to ignore certificate errors. But where I can get thouse fingerprints for lets encrypt certificates? I feel like I I can get ot from here ... but not sure where exactly the fingerpring is? ( https://letsencrypt.org/certificates/ Also it should be for root or intermediate CA or both? Also is there anybody who can successfully connect with Kleopatra to any keyserver on Windows? Oleksandr -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrewg at andrewg.com Wed Dec 29 16:05:11 2021 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 29 Dec 2021 15:05:11 +0000 Subject: Gpg4win LetsEncrypt issue In-Reply-To: References: Message-ID: <99400d1d1790e38384692973df573a00f40874d9.camel@andrewg.com> On Wed, 2021-12-29 at 14:33 +0200, Alex Nadtoka via Gnupg-users wrote: > I cannot connect to any keyserver. The error is certificate expired. > I am on latest (I think) Windows 10 . Tried reinstalling it or > installing on new Windows machine but no luck . dirmngr keeps telling > me that certificate is expired.? Have you tried configuring an hkps keyserver that does not use LetsEncrypt, e.g. keyserver-01.2ndquadrant.com ? A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 862 bytes Desc: This is a digitally signed message part URL: From alex.nadtoka at gmail.com Wed Dec 29 21:15:06 2021 From: alex.nadtoka at gmail.com (Alex Nadtoka) Date: Wed, 29 Dec 2021 22:15:06 +0200 Subject: Gpg4win LetsEncrypt issue In-Reply-To: <99400d1d1790e38384692973df573a00f40874d9.camel@andrewg.com> References: <99400d1d1790e38384692973df573a00f40874d9.camel@andrewg.com> Message-ID: yes it works with keyserver-01.2ndquadrant.com ??, 29 ????. 2021 ?. ? 17:06 Andrew Gallagher via Gnupg-users < gnupg-users at gnupg.org> ????: > On Wed, 2021-12-29 at 14:33 +0200, Alex Nadtoka via Gnupg-users wrote: > > I cannot connect to any keyserver. The error is certificate expired. > > I am on latest (I think) Windows 10 . Tried reinstalling it or > > installing on new Windows machine but no luck . dirmngr keeps telling > > me that certificate is expired. > > Have you tried configuring an hkps keyserver that does not use > LetsEncrypt, e.g. keyserver-01.2ndquadrant.com ? > > A > _______________________________________________ > 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 andrewg at andrewg.com Wed Dec 29 22:10:35 2021 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 29 Dec 2021 21:10:35 +0000 Subject: Gpg4win LetsEncrypt issue In-Reply-To: References: Message-ID: <2D2C14E4-23C6-4461-A7F4-223CBE920615@andrewg.com> > On 29 Dec 2021, at 20:15, Alex Nadtoka wrote: > > yes it works with keyserver-01.2ndquadrant.com Is this server sufficient for your purposes or do you also need to support an internal keyserver? A > ??, 29 ????. 2021 ?. ? 17:06 Andrew Gallagher via Gnupg-users ????: >> On Wed, 2021-12-29 at 14:33 +0200, Alex Nadtoka via Gnupg-users wrote: >> > I cannot connect to any keyserver. The error is certificate expired. >> > I am on latest (I think) Windows 10 . Tried reinstalling it or >> > installing on new Windows machine but no luck . dirmngr keeps telling >> > me that certificate is expired. >> >> Have you tried configuring an hkps keyserver that does not use >> LetsEncrypt, e.g. keyserver-01.2ndquadrant.com ? >> >> A >> _______________________________________________ >> 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 alex.nadtoka at gmail.com Wed Dec 29 22:12:30 2021 From: alex.nadtoka at gmail.com (Alex Nadtoka) Date: Wed, 29 Dec 2021 23:12:30 +0200 Subject: Gpg4win LetsEncrypt issue In-Reply-To: <2D2C14E4-23C6-4461-A7F4-223CBE920615@andrewg.com> References: <2D2C14E4-23C6-4461-A7F4-223CBE920615@andrewg.com> Message-ID: We have our internal GPG server( I want people in company to be able to connect to it from windows as well... ??, 29 ????. 2021 ?. ? 23:11 Andrew Gallagher via Gnupg-users < gnupg-users at gnupg.org> ????: > > On 29 Dec 2021, at 20:15, Alex Nadtoka wrote: > > yes it works with keyserver-01.2ndquadrant.com > > > Is this server sufficient for your purposes or do you also need to support > an internal keyserver? > > A > > ??, 29 ????. 2021 ?. ? 17:06 Andrew Gallagher via Gnupg-users < > gnupg-users at gnupg.org> ????: > >> On Wed, 2021-12-29 at 14:33 +0200, Alex Nadtoka via Gnupg-users wrote: >> > I cannot connect to any keyserver. The error is certificate expired. >> > I am on latest (I think) Windows 10 . Tried reinstalling it or >> > installing on new Windows machine but no luck . dirmngr keeps telling >> > me that certificate is expired. >> >> Have you tried configuring an hkps keyserver that does not use >> LetsEncrypt, e.g. keyserver-01.2ndquadrant.com ? >> >> A >> _______________________________________________ >> Gnupg-users mailing list >> Gnupg-users at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-users >> > _______________________________________________ > 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 andrewg at andrewg.com Wed Dec 29 22:33:36 2021 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 29 Dec 2021 21:33:36 +0000 Subject: Gpg4win LetsEncrypt issue In-Reply-To: References: Message-ID: <72DA99A8-E69A-4468-BD0B-E4446596182B@andrewg.com> > On 29 Dec 2021, at 21:12, Alex Nadtoka wrote: > > We have our internal GPG server( I want people in company to be able to connect to it from windows as well... OK, so you definitely need to solve the root certificate issue. Do sites using letsencrypt work from an Edge browser on that machine, or is it just dirmngr? A From alex.nadtoka at gmail.com Wed Dec 29 22:53:24 2021 From: alex.nadtoka at gmail.com (Alex Nadtoka) Date: Wed, 29 Dec 2021 23:53:24 +0200 Subject: Gpg4win LetsEncrypt issue In-Reply-To: <72DA99A8-E69A-4468-BD0B-E4446596182B@andrewg.com> References: <72DA99A8-E69A-4468-BD0B-E4446596182B@andrewg.com> Message-ID: It is just dirmngr .... Through browsers everything works fine as well as from gpg command line client in Linux ??, 29 ????. 2021 ?. ? 23:34 Andrew Gallagher via Gnupg-users < gnupg-users at gnupg.org> ????: > > > On 29 Dec 2021, at 21:12, Alex Nadtoka wrote: > > > > We have our internal GPG server( I want people in company to be able to > connect to it from windows as well... > > OK, so you definitely need to solve the root certificate issue. > > Do sites using letsencrypt work from an Edge browser on that machine, or > is it just dirmngr? > > A > _______________________________________________ > 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 anze at anze.dev Wed Dec 29 14:55:07 2021 From: anze at anze.dev (Anze Jensterle) Date: Wed, 29 Dec 2021 14:55:07 +0100 Subject: Error in 2.3 regarding reader-port (infinite loop) Message-ID: Hey everyone, I just updated my Windows PC to 2.3. I used the "reader-port" option in scdaemon.conf to only use my Yubikey. Since updating I have found that with that option set, the scdaemon goes into an infinite loop when trying to access smart cards (for example Kleopatra hangs while opening). If I remove the reader-port option in the config, the loop stops. Looking at the logs, it seems like scd is constantly trying to initiate the first reader it finds) I have attached logs of the wrong and correct behavior I observed (debug-level guru, debug-all). Best, Anze Jensterle -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- 2021-12-29 14:18:30 scdaemon[19892] DBG: chan_0x00000300 <- SERIALNO --all 2021-12-29 14:18:30 scdaemon[19892] detected reader 'ACS ACR1252 1S CL Reader PICC 0' 2021-12-29 14:18:30 scdaemon[19892] detected reader 'ACS ACR1252 1S CL Reader SAM 0' 2021-12-29 14:18:30 scdaemon[19892] detected reader 'OMNIKEY CardMan 3821 0' 2021-12-29 14:18:30 scdaemon[19892] detected reader 'Windows Hello for Business 1' 2021-12-29 14:18:30 scdaemon[19892] DBG: apdu_open_reader: ACS ACR1252 1S CL Reader PICC 0 2021-12-29 14:18:30 scdaemon[19892] DBG: apdu_open_reader: new device=ACS ACR1252 1S CL Reader PICC 0 2021-12-29 14:18:30 scdaemon[19892] DBG: apdu_open_reader: ACS ACR1252 1S CL Reader PICC 0 2021-12-29 14:18:30 scdaemon[19892] DBG: apdu_open_reader: new device=ACS ACR1252 1S CL Reader PICC 0 2021-12-29 14:18:30 scdaemon[19892] DBG: apdu_open_reader: ACS ACR1252 1S CL Reader PICC 0 2021-12-29 14:18:30 scdaemon[19892] DBG: apdu_open_reader: new device=ACS ACR1252 1S CL Reader PICC 0 2021-12-29 14:18:30 scdaemon[19892] DBG: apdu_open_reader: ACS ACR1252 1S CL Reader PICC 0 2021-12-29 14:18:30 scdaemon[19892] DBG: apdu_open_reader: new device=ACS ACR1252 1S CL Reader PICC 0 2021-12-29 14:18:30 scdaemon[19892] DBG: apdu_open_reader: ACS ACR1252 1S CL Reader PICC 0 2021-12-29 14:18:30 scdaemon[19892] DBG: apdu_open_reader: new device=ACS ACR1252 1S CL Reader PICC 0 2021-12-29 14:18:30 scdaemon[19892] DBG: apdu_open_reader: ACS ACR1252 1S CL Reader PICC 0 2021-12-29 14:18:30 scdaemon[19892] DBG: apdu_open_reader: new device=ACS ACR1252 1S CL Reader PICC 0 2021-12-29 14:18:30 scdaemon[19892] DBG: apdu_open_reader: ACS ACR1252 1S CL Reader PICC 0 2021-12-29 14:18:30 scdaemon[19892] DBG: apdu_open_reader: new device=ACS ACR1252 1S CL Reader PICC 0 2021-12-29 14:18:30 scdaemon[19892] DBG: apdu_open_reader: ACS ACR1252 1S CL Reader PICC 0 2021-12-29 14:18:30 scdaemon[19892] DBG: apdu_open_reader: new device=ACS ACR1252 1S CL Reader PICC 0 2021-12-29 14:18:30 scdaemon[19892] DBG: apdu_open_reader: ACS ACR1252 1S CL Reader PICC 0 2021-12-29 14:18:30 scdaemon[19892] DBG: apdu_open_reader: new device=ACS ACR1252 1S CL Reader PICC 0 2021-12-29 14:18:30 scdaemon[19892] DBG: apdu_open_reader: ACS ACR1252 1S CL Reader PICC 0 2021-12-29 14:18:30 scdaemon[19892] DBG: apdu_open_reader: new device=ACS ACR1252 1S CL Reader PICC 0 -------------- next part -------------- 2021-12-29 14:38:46 scdaemon[10144] DBG: chan_0x000002e4 <- serialno 2021-12-29 14:38:46 scdaemon[10144] detected reader 'OMNIKEY CardMan 3821 0' 2021-12-29 14:38:46 scdaemon[10144] detected reader 'Windows Hello for Business 1' 2021-12-29 14:38:46 scdaemon[10144] detected reader 'Yubico YubiKey OTP+FIDO+CCID 0' 2021-12-29 14:38:46 scdaemon[10144] DBG: apdu_open_reader: OMNIKEY CardMan 3821 0 2021-12-29 14:38:46 scdaemon[10144] DBG: apdu_open_reader: new device=OMNIKEY CardMan 3821 0 2021-12-29 14:38:46 scdaemon[10144] reader slot 0: not connected 2021-12-29 14:38:46 scdaemon[10144] DBG: enter: apdu_connect: slot=0 2021-12-29 14:38:46 scdaemon[10144] DBG: feature: code=06, len=4, v=31300C 2021-12-29 14:38:46 scdaemon[10144] DBG: feature: code=07, len=4, v=313010 2021-12-29 14:38:46 scdaemon[10144] DBG: feature: code=0F, len=4, v=31302C 2021-12-29 14:38:46 scdaemon[10144] DBG: feature: code=11, len=4, v=313034 2021-12-29 14:38:46 scdaemon[10144] DBG: feature: code=0A, len=4, v=313008 2021-12-29 14:38:46 scdaemon[10144] DBG: feature: code=10, len=4, v=313030 2021-12-29 14:38:46 scdaemon[10144] reader slot 0: active protocol: T0 2021-12-29 14:38:46 scdaemon[10144] slot 0: ATR=3b7d96000080318065b0830201f383009000 2021-12-29 14:38:46 scdaemon[10144] DBG: pcsc_get_status_change: changed present excl inuse 2021-12-29 14:38:46 scdaemon[10144] DBG: leave: apdu_connect => sw=0x0 2021-12-29 14:38:46 scdaemon[10144] DBG: send apdu: c=00 i=A4 p1=00 p2=0C lc=2 le=-1 em=0 2021-12-29 14:38:46 scdaemon[10144] DBG: PCSC_data: 00a4000c023f00 2021-12-29 14:38:46 scdaemon[10144] DBG: response: sw=6A86 datalen=0 2021-12-29 14:38:46 scdaemon[10144] DBG: send apdu: c=00 i=A4 p1=04 p2=00 lc=6 le=-1 em=0 2021-12-29 14:38:46 scdaemon[10144] DBG: PCSC_data: 00a4040006d27600012401 2021-12-29 14:38:46 scdaemon[10144] DBG: response: sw=6A82 datalen=0 2021-12-29 14:38:46 scdaemon[10144] DBG: send apdu: c=00 i=A4 p1=04 p2=00 lc=9 le=256 em=0 2021-12-29 14:38:46 scdaemon[10144] DBG: PCSC_data: 00a4040009a00000030800001000 2021-12-29 14:38:46 scdaemon[10144] DBG: response: sw=6A82 datalen=0 2021-12-29 14:38:46 scdaemon[10144] DBG: send apdu: c=00 i=A4 p1=04 p2=0C lc=7 le=-1 em=0 2021-12-29 14:38:46 scdaemon[10144] DBG: PCSC_data: 00a4040c07d2760000030102 2021-12-29 14:38:46 scdaemon[10144] DBG: response: sw=6A82 datalen=0 2021-12-29 14:38:46 scdaemon[10144] DBG: send apdu: c=00 i=A4 p1=04 p2=0C lc=7 le=-1 em=0 2021-12-29 14:38:46 scdaemon[10144] DBG: PCSC_data: 00a4040c07d2760000030c01 2021-12-29 14:38:46 scdaemon[10144] DBG: response: sw=6A82 datalen=0 2021-12-29 14:38:46 scdaemon[10144] DBG: send apdu: c=00 i=A4 p1=04 p2=00 lc=12 le=256 em=0 2021-12-29 14:38:46 scdaemon[10144] DBG: PCSC_data: 00a404000ca000000063504b43532d3135 2021-12-29 14:38:46 scdaemon[10144] DBG: response: sw=6A82 datalen=0 2021-12-29 14:38:46 scdaemon[10144] DBG: send apdu: c=00 i=A4 p1=08 p2=0C lc=2 le=-1 em=0 2021-12-29 14:38:46 scdaemon[10144] DBG: PCSC_data: 00a4080c022f00 2021-12-29 14:38:46 scdaemon[10144] DBG: response: sw=6A86 datalen=0 2021-12-29 14:38:46 scdaemon[10144] DBG: send apdu: c=00 i=A4 p1=01 p2=0C lc=2 le=-1 em=0 2021-12-29 14:38:46 scdaemon[10144] DBG: PCSC_data: 00a4010c025015 2021-12-29 14:38:46 scdaemon[10144] DBG: response: sw=6A86 datalen=0 2021-12-29 14:38:46 scdaemon[10144] DBG: send apdu: c=00 i=A4 p1=04 p2=0C lc=9 le=-1 em=0 2021-12-29 14:38:46 scdaemon[10144] DBG: PCSC_data: 00a4040c09d27600002545500200 2021-12-29 14:38:46 scdaemon[10144] DBG: response: sw=6A82 datalen=0 2021-12-29 14:38:46 scdaemon[10144] DBG: send apdu: c=00 i=A4 p1=04 p2=0C lc=6 le=-1 em=0 2021-12-29 14:38:46 scdaemon[10144] DBG: PCSC_data: 00a4040c06d27600006601 2021-12-29 14:38:46 scdaemon[10144] DBG: response: sw=6A82 datalen=0 2021-12-29 14:38:46 scdaemon[10144] DBG: send apdu: c=00 i=A4 p1=04 p2=0C lc=11 le=-1 em=0 2021-12-29 14:38:46 scdaemon[10144] DBG: PCSC_data: 00a4040c0be82b0601040181c31f0201 2021-12-29 14:38:46 scdaemon[10144] DBG: response: sw=6A82 datalen=0 2021-12-29 14:38:46 scdaemon[10144] no supported card application found: No such file or directory 2021-12-29 14:38:46 scdaemon[10144] DBG: chan_0x000002e4 -> S PINCACHE_PUT 0// 2021-12-29 14:38:46 scdaemon[10144] DBG: enter: apdu_close_reader: slot=0 2021-12-29 14:38:46 scdaemon[10144] DBG: enter: apdu_disconnect: slot=0 2021-12-29 14:38:46 scdaemon[10144] DBG: leave: apdu_disconnect => sw=0x0 2021-12-29 14:38:46 scdaemon[10144] DBG: leave: apdu_close_reader => 0x0 (close_reader) 2021-12-29 14:38:46 scdaemon[10144] DBG: apdu_open_reader: Windows Hello for Business 1 2021-12-29 14:38:46 scdaemon[10144] DBG: apdu_open_reader: new device=Windows Hello for Business 1 2021-12-29 14:38:46 scdaemon[10144] reader slot 0: not connected 2021-12-29 14:38:46 scdaemon[10144] DBG: enter: apdu_connect: slot=0 2021-12-29 14:38:46 scdaemon[10144] pcsc_control failed: insufficient buffer (0x80100008) 2021-12-29 14:38:46 scdaemon[10144] pcsc_vendor_specific_init: GET_FEATURE_REQUEST failed: 65538 2021-12-29 14:38:46 scdaemon[10144] reader slot 0: active protocol: T1 2021-12-29 14:38:46 scdaemon[10144] slot 0: ATR=3b8d0180fba000000397425446590401cf 2021-12-29 14:38:46 scdaemon[10144] DBG: pcsc_get_status_change: changed present excl inuse 2021-12-29 14:38:46 scdaemon[10144] DBG: leave: apdu_connect => sw=0x0 2021-12-29 14:38:46 scdaemon[10144] DBG: send apdu: c=00 i=A4 p1=00 p2=0C lc=2 le=-1 em=0 2021-12-29 14:38:46 scdaemon[10144] DBG: PCSC_data: 00a4000c023f00 2021-12-29 14:38:46 scdaemon[10144] DBG: response: sw=6A82 datalen=0 2021-12-29 14:38:46 scdaemon[10144] DBG: send apdu: c=00 i=A4 p1=04 p2=00 lc=6 le=-1 em=0 2021-12-29 14:38:46 scdaemon[10144] DBG: PCSC_data: 00a4040006d27600012401 2021-12-29 14:38:46 scdaemon[10144] DBG: response: sw=6A82 datalen=0 2021-12-29 14:38:46 scdaemon[10144] DBG: send apdu: c=00 i=A4 p1=04 p2=00 lc=9 le=256 em=0 2021-12-29 14:38:46 scdaemon[10144] DBG: PCSC_data: 00a4040009a0000003080000100000 2021-12-29 14:38:46 scdaemon[10144] DBG: response: sw=6A82 datalen=0 2021-12-29 14:38:46 scdaemon[10144] DBG: send apdu: c=00 i=A4 p1=04 p2=0C lc=7 le=-1 em=0 2021-12-29 14:38:46 scdaemon[10144] DBG: PCSC_data: 00a4040c07d2760000030102 2021-12-29 14:38:46 scdaemon[10144] DBG: response: sw=6A82 datalen=0 2021-12-29 14:38:46 scdaemon[10144] DBG: send apdu: c=00 i=A4 p1=04 p2=0C lc=7 le=-1 em=0 2021-12-29 14:38:46 scdaemon[10144] DBG: PCSC_data: 00a4040c07d2760000030c01 2021-12-29 14:38:46 scdaemon[10144] DBG: response: sw=6A82 datalen=0 2021-12-29 14:38:46 scdaemon[10144] DBG: send apdu: c=00 i=A4 p1=04 p2=00 lc=12 le=256 em=0 2021-12-29 14:38:46 scdaemon[10144] DBG: PCSC_data: 00a404000ca000000063504b43532d313500 2021-12-29 14:38:46 scdaemon[10144] DBG: response: sw=6A82 datalen=0 2021-12-29 14:38:46 scdaemon[10144] DBG: send apdu: c=00 i=A4 p1=08 p2=0C lc=2 le=-1 em=0 2021-12-29 14:38:46 scdaemon[10144] DBG: PCSC_data: 00a4080c022f00 2021-12-29 14:38:46 scdaemon[10144] DBG: response: sw=6A86 datalen=0 2021-12-29 14:38:46 scdaemon[10144] DBG: send apdu: c=00 i=A4 p1=01 p2=0C lc=2 le=-1 em=0 2021-12-29 14:38:46 scdaemon[10144] DBG: PCSC_data: 00a4010c025015 2021-12-29 14:38:46 scdaemon[10144] DBG: response: sw=6A86 datalen=0 2021-12-29 14:38:46 scdaemon[10144] DBG: send apdu: c=00 i=A4 p1=04 p2=0C lc=9 le=-1 em=0 2021-12-29 14:38:46 scdaemon[10144] DBG: PCSC_data: 00a4040c09d27600002545500200 2021-12-29 14:38:46 scdaemon[10144] DBG: response: sw=6A82 datalen=0 2021-12-29 14:38:46 scdaemon[10144] DBG: send apdu: c=00 i=A4 p1=04 p2=0C lc=6 le=-1 em=0 2021-12-29 14:38:46 scdaemon[10144] DBG: PCSC_data: 00a4040c06d27600006601 2021-12-29 14:38:46 scdaemon[10144] DBG: response: sw=6A82 datalen=0 2021-12-29 14:38:46 scdaemon[10144] DBG: send apdu: c=00 i=A4 p1=04 p2=0C lc=11 le=-1 em=0 2021-12-29 14:38:46 scdaemon[10144] DBG: PCSC_data: 00a4040c0be82b0601040181c31f0201 2021-12-29 14:38:46 scdaemon[10144] DBG: response: sw=6A82 datalen=0 2021-12-29 14:38:46 scdaemon[10144] no supported card application found: No such file or directory 2021-12-29 14:38:46 scdaemon[10144] DBG: chan_0x000002e4 -> S PINCACHE_PUT 0// 2021-12-29 14:38:46 scdaemon[10144] DBG: enter: apdu_close_reader: slot=0 2021-12-29 14:38:46 scdaemon[10144] DBG: enter: apdu_disconnect: slot=0 2021-12-29 14:38:46 scdaemon[10144] DBG: leave: apdu_disconnect => sw=0x0 2021-12-29 14:38:46 scdaemon[10144] DBG: leave: apdu_close_reader => 0x0 (close_reader) 2021-12-29 14:38:46 scdaemon[10144] DBG: apdu_open_reader: Yubico YubiKey OTP+FIDO+CCID 0 2021-12-29 14:38:46 scdaemon[10144] DBG: apdu_open_reader: new device=Yubico YubiKey OTP+FIDO+CCID 0 2021-12-29 14:38:46 scdaemon[10144] reader slot 0: not connected 2021-12-29 14:38:46 scdaemon[10144] DBG: enter: apdu_connect: slot=0 2021-12-29 14:38:46 scdaemon[10144] reader slot 0: active protocol: T1 2021-12-29 14:38:46 scdaemon[10144] slot 0: ATR=3bfd1300008131fe158073c021c057597562694b657940 2021-12-29 14:38:46 scdaemon[10144] DBG: pcsc_get_status_change: changed present excl inuse 2021-12-29 14:38:46 scdaemon[10144] DBG: leave: apdu_connect => sw=0x0 2021-12-29 14:38:46 scdaemon[10144] DBG: send apdu: c=00 i=A4 p1=00 p2=0C lc=2 le=-1 em=0 2021-12-29 14:38:46 scdaemon[10144] DBG: PCSC_data: 00a4000c023f00 2021-12-29 14:38:46 scdaemon[10144] DBG: response: sw=6D00 datalen=0 2021-12-29 14:38:46 scdaemon[10144] DBG: send apdu: c=00 i=A4 p1=04 p2=00 lc=8 le=-1 em=0 2021-12-29 14:38:46 scdaemon[10144] DBG: PCSC_data: 00a4040008a000000527471117 2021-12-29 14:38:46 scdaemon[10144] DBG: response: sw=9000 datalen=30 2021-12-29 14:38:46 scdaemon[10144] DBG: dump: 5669727475616c206d6772202d2046572076657273696f6e20352e322e34 2021-12-29 14:38:46 scdaemon[10144] DBG: PCSC_data: 001d000000 2021-12-29 14:38:46 scdaemon[10144] DBG: response: sw=9000 datalen=47 2021-12-29 14:38:46 scdaemon[10144] DBG: dump: 2e0102023f0302023f020400b74de604010105030502040602000007010f0801 \ 2021-12-29 14:38:46 scdaemon[10144] DBG: 000d02023f0e02023a0a01000f01009000 2021-12-29 14:38:46 scdaemon[10144] Yubico: config=2e0102023f0302023f020400b74de604010105030502040602000007010f0801000d02023f0e02023a0a01000f0100 2021-12-29 14:38:46 scdaemon[10144] DBG: send apdu: c=00 i=A4 p1=04 p2=00 lc=6 le=-1 em=0 2021-12-29 14:38:46 scdaemon[10144] DBG: PCSC_data: 00a4040006d27600012401 2021-12-29 14:38:46 scdaemon[10144] DBG: response: sw=9000 datalen=0 2021-12-29 14:38:46 scdaemon[10144] DBG: dump: [all zero] 2021-12-29 14:38:46 scdaemon[10144] DBG: send apdu: c=00 i=CA p1=00 p2=4F lc=-1 le=256 em=0 2021-12-29 14:38:46 scdaemon[10144] DBG: PCSC_data: 00ca004f00 2021-12-29 14:38:46 scdaemon[10144] DBG: response: sw=9000 datalen=16 2021-12-29 14:38:46 scdaemon[10144] DBG: dump: d2760001240103040006120130300000 2021-12-29 14:38:46 scdaemon[10144] AID: d2760001240103040006120130300000 2021-12-29 14:38:46 scdaemon[10144] DBG: send apdu: c=00 i=CA p1=5F p2=52 lc=-1 le=256 em=0 2021-12-29 14:38:46 scdaemon[10144] DBG: PCSC_data: 00ca5f5200 2021-12-29 14:38:46 scdaemon[10144] DBG: response: sw=9000 datalen=8 2021-12-29 14:38:46 scdaemon[10144] DBG: dump: 00730000e0059000 2021-12-29 14:38:46 scdaemon[10144] Historical Bytes: 00730000e0059000 2021-12-29 14:38:46 scdaemon[10144] DBG: send apdu: c=00 i=CA p1=00 p2=C4 lc=-1 le=256 em=0 2021-12-29 14:38:46 scdaemon[10144] DBG: PCSC_data: 00ca00c400 2021-12-29 14:38:46 scdaemon[10144] DBG: response: sw=9000 datalen=7 2021-12-29 14:38:46 scdaemon[10144] DBG: dump: 007f7f7f030003 2021-12-29 14:38:46 scdaemon[10144] DBG: send apdu: c=00 i=CA p1=00 p2=6E lc=-1 le=256 em=0 2021-12-29 14:38:46 scdaemon[10144] DBG: PCSC_data: 00ca006e00 2021-12-29 14:38:46 scdaemon[10144] DBG: response: sw=6140 datalen=256 2021-12-29 14:38:46 scdaemon[10144] DBG: apdu_send_simple(0): 64 more bytes available 2021-12-29 14:38:46 scdaemon[10144] DBG: PCSC_data: 00c0000040 2021-12-29 14:38:46 scdaemon[10144] DBG: more: sw=9000 datalen=64 2021-12-29 14:38:46 scdaemon[10144] DBG: dump: 6e82013c4f10d27600012401030400061201303000005f520800730000e00590 \ 2021-12-29 14:38:46 scdaemon[10144] DBG: 007f740381012073820115c00a7d000bfe080000ff0000c106010800001100c2 \ 2021-12-29 14:38:46 scdaemon[10144] DBG: 06010800001100c30b162b06010401da470f0125da06010800001100c407007f \ 2021-12-29 14:38:46 scdaemon[10144] DBG: 7f7f030003c550f4b8a5c8743db94c08b37b6556821505069ebf5fe4d403d8f4 \ 2021-12-29 14:38:46 scdaemon[10144] DBG: d4c078aae939c8264caed2386b36456c7e66b8aa83edb1434c24e6238cf1ad0d \ 2021-12-29 14:38:46 scdaemon[10144] DBG: e1bac90000000000000000000000000000000000000000c65000000000000000 \ 2021-12-29 14:38:46 scdaemon[10144] DBG: 0000000000000000000000000000000000000000000000000000000000000000 \ 2021-12-29 14:38:46 scdaemon[10144] DBG: 0000000000000000000000000000000000000000000000000000000000000000 \ 2021-12-29 14:38:46 scdaemon[10144] DBG: 000000000000000000cd105b4b47635b4b4784619ab1a100000000de08010202 \ 2021-12-29 14:38:46 scdaemon[10144] DBG: 02030281027f660802020bfe02020bfed6020020d7020020d8020020d9020020 2021-12-29 14:38:46 scdaemon[10144] DBG: send apdu: c=00 i=CA p1=00 p2=5E lc=-1 le=65534 em=255 2021-12-29 14:38:46 scdaemon[10144] DBG: PCSC_data: 00ca005e00fffe 2021-12-29 14:38:46 scdaemon[10144] DBG: response: sw=9000 datalen=4 2021-12-29 14:38:46 scdaemon[10144] DBG: dump: 616e7a65 2021-12-29 14:38:46 scdaemon[10144] Version-2+ .....: yes 2021-12-29 14:38:46 scdaemon[10144] Version-3+ .....: yes 2021-12-29 14:38:46 scdaemon[10144] Button .........: yes 2021-12-29 14:38:46 scdaemon[10144] SM-Support .....: no 2021-12-29 14:38:46 scdaemon[10144] Get-Challenge ..: yes (3070 bytes max) 2021-12-29 14:38:46 scdaemon[10144] Key-Import .....: yes 2021-12-29 14:38:46 scdaemon[10144] Change-Force-PW1: yes 2021-12-29 14:38:46 scdaemon[10144] Private-DOs ....: yes 2021-12-29 14:38:46 scdaemon[10144] Algo-Attr-Change: yes 2021-12-29 14:38:46 scdaemon[10144] Symmetric Crypto: no 2021-12-29 14:38:46 scdaemon[10144] KDF-Support ....: yes 2021-12-29 14:38:46 scdaemon[10144] Max-Cert-Len ...: 2048 2021-12-29 14:38:46 scdaemon[10144] PIN-Block-2 ....: no 2021-12-29 14:38:46 scdaemon[10144] MSE-Support ....: no 2021-12-29 14:38:46 scdaemon[10144] Max-Special-DOs : 255 2021-12-29 14:38:46 scdaemon[10144] Cmd-Chaining ...: yes 2021-12-29 14:38:46 scdaemon[10144] Ext-Lc-Le ......: yes 2021-12-29 14:38:46 scdaemon[10144] Status-Indicator: 05 2021-12-29 14:38:46 scdaemon[10144] GnuPG-No-Sync ..: no 2021-12-29 14:38:46 scdaemon[10144] GnuPG-Def-PW2 ..: no 2021-12-29 14:38:46 scdaemon[10144] Key-Attr-sign ..: RSA, n=2048, e=17, fmt=std 2021-12-29 14:38:46 scdaemon[10144] Key-Algo-sign ..: rsa2048 2021-12-29 14:38:46 scdaemon[10144] Key-Attr-encr ..: RSA, n=2048, e=17, fmt=std 2021-12-29 14:38:46 scdaemon[10144] Key-Algo-encr ..: rsa2048 2021-12-29 14:38:46 scdaemon[10144] Key-Attr-auth ..: 2021-12-29 14:38:46 scdaemon[10144] DBG: Curve with OID not supported: 2b06010401da470f0125 From wk at gnupg.org Thu Dec 30 15:28:43 2021 From: wk at gnupg.org (Werner Koch) Date: Thu, 30 Dec 2021 15:28:43 +0100 Subject: Gpg4win LetsEncrypt issue In-Reply-To: <72DA99A8-E69A-4468-BD0B-E4446596182B@andrewg.com> (Andrew Gallagher via Gnupg-users's message of "Wed, 29 Dec 2021 21:33:36 +0000") References: <72DA99A8-E69A-4468-BD0B-E4446596182B@andrewg.com> Message-ID: <878rw22mlg.fsf@wheatstone.g10code.de> On Wed, 29 Dec 2021 21:33, Andrew Gallagher said: > OK, so you definitely need to solve the root certificate issue. This has been fixed with gnupg 2.2.32 - please get an update. The workaround is to delete the old LE certificate from your Root CA store. 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 Thu Dec 30 15:31:22 2021 From: wk at gnupg.org (Werner Koch) Date: Thu, 30 Dec 2021 15:31:22 +0100 Subject: Error in 2.3 regarding reader-port (infinite loop) In-Reply-To: (Anze Jensterle's message of "Wed, 29 Dec 2021 14:55:07 +0100") References: Message-ID: <874k6q2mh1.fsf@wheatstone.g10code.de> On Wed, 29 Dec 2021 14:55, Anze Jensterle said: > I just updated my Windows PC to 2.3. I used the "reader-port" option in Do you mean gnupg 2.3.4 for Windows or the gpg4win 4.0 ? > I have attached logs of the wrong and correct behavior I observed > (debug-level guru, debug-all). Thanks. We will try to replicate this. 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 alex.nadtoka at gmail.com Thu Dec 30 15:44:56 2021 From: alex.nadtoka at gmail.com (Alex Nadtoka) Date: Thu, 30 Dec 2021 16:44:56 +0200 Subject: Gpg4win LetsEncrypt issue In-Reply-To: <878rw22mlg.fsf@wheatstone.g10code.de> References: <72DA99A8-E69A-4468-BD0B-E4446596182B@andrewg.com> <878rw22mlg.fsf@wheatstone.g10code.de> Message-ID: Cool thanks. going to test it today Yesterday tested also with GPG Suite on MacOS - works fine, so only windows issue I think. ??, 30 ????. 2021 ?. ? 16:31 Werner Koch via Gnupg-users < gnupg-users at gnupg.org> ????: > On Wed, 29 Dec 2021 21:33, Andrew Gallagher said: > > > OK, so you definitely need to solve the root certificate issue. > > This has been fixed with gnupg 2.2.32 - please get an update. The > workaround is to delete the old LE certificate from your Root CA store. > > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Thu Dec 30 15:51:48 2021 From: wk at gnupg.org (Werner Koch) Date: Thu, 30 Dec 2021 15:51:48 +0100 Subject: Error in 2.3 regarding reader-port (infinite loop) In-Reply-To: (Anze Jensterle's message of "Wed, 29 Dec 2021 14:55:07 +0100") References: Message-ID: <87zgoi16yj.fsf@wheatstone.g10code.de> > I have attached logs of the wrong and correct behavior I observed > (debug-level guru, debug-all). Yes, this is an obvious bug. We have not yet seen it because on Unix we prefer to use the CCID driver using a different code path and further with 2.3 there is not much need to specify a port. Here is the bug: while (dl->idx < dl->idx_max) { const char *rdrname = pcsc.rdrname[dl->idx]; if (DBG_READER) log_debug ("apdu_open_reader: %s\n", rdrname); /* Check the identity of reader against already opened one. */ for (slot = 0; slot < MAX_READER; slot++) if (reader_table[slot].used && !strcmp (reader_table[slot].rdrname, rdrname)) break; if (slot == MAX_READER) { /* Found a new device. */ if (DBG_READER) log_debug ("apdu_open_reader: new device=%s\n", rdrname); /* When reader string is specified, check if it is the one. */ if (readerno < 0 && strncmp (rdrname, dl->portstr, strlen (dl->portstr)) != 0) continue; The /continue/ causes the loop because the loop index is not bumped. 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 lars.nooden at gmx.com Thu Dec 30 15:38:47 2021 From: lars.nooden at gmx.com (=?UTF-8?Q?Lars_Nood=c3=a9n?=) Date: Thu, 30 Dec 2021 16:38:47 +0200 Subject: SSH and gpg2: pinentry errors hidden from view, agent refused operation Message-ID: <0a9aaf6f-3b68-469f-609f-28a5c7ea391e@gmx.com> Hello, I have used GNUpg2 v 2.2.19 [1] to create an authentication RSA subkey for use with SSH. At one point, I got past pinentry's blocking of the use of the private key and successfully logged in via SSH to the server from the one session. In order to test my notes (as I usually do) I erased everything and started over with a newly created client-side account and updated authorized_keys on the server. Some step is missing and I cannot figure out how to get pinentry involved to make the key available for the SSH client to use again. What else is needed to get pinentry invoked so that the SSH client can connect using the GnuPG RSA key? At this point the public key is visible in the SSH agent: $ ssh-add -l 3072 SHA256:j0V4cVzC...NKQPA (none) (RSA) and the public key has been saved in the default file: $ssh-add -L > ~/.ssh/id_rsa and the SSH client seems to offer the public key to the server, $ time ssh -v server.example.org ... debug1: Next authentication method: publickey debug1: Offering public key: (none) RSA SHA256:j0V4cVzC...NKQPA agent debug1: Server accepts key: (none) RSA SHA256:j0V4cVzC...NKQPA agent sign_and_send_pubkey: signing failed for RSA "/home/lars/.ssh/id_rsa" from agent: agent refused operation ... debug1: Trying private key: /home/lars/.ssh/id_xmss debug1: No more authentication methods to try. debug1: Next authentication method: keyboard-interactive Connection closed by server.example.org port 22 ssh -v server.example.org 0.00s user 0.00s system 0% cpu 2:05.81 total The contents of gpg-agent.conf and gpg.conf are as follows: $ cat ~/.gnupg/gpg-agent.conf pinentry-program /usr/bin/pinentry-curses enable-ssh-support allow-loopback-pinentry $ cat ~/.gnupg/gpg.conf use-agent pinentry-mode loopback I have set $GPG_TTY and $SSH_AUTH_SOCK $ export GPG_TTY=$(tty) $ gpg-connect-agent updatestartuptty /bye >/dev/null $ export SSH_AUTH_SOCK=$(gpgconf --list-dirs agent-ssh-socket) $ gpg-agent status /bye gpg-agent[48580]: gpg-agent running and available What else should I add, change, or read to get past the barrier of pinentry? /Lars [1] $ apt-cache policy gnupg2 | head -n 2 gnupg2: Installed: 2.2.19-3ubuntu2.1 $ gpg2 --version | head -n 2 gpg (GnuPG) 2.2.19 libgcrypt 1.8.5 $ lsb_release -rd Description: Linux Mint 20.2 Release: 20.2 $ uname -prs Linux 5.4.0-91-generic x86_64 From kloecker at kde.org Thu Dec 30 16:44:10 2021 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Thu, 30 Dec 2021 16:44:10 +0100 Subject: SSH and gpg2: pinentry errors hidden from view, agent refused operation In-Reply-To: <0a9aaf6f-3b68-469f-609f-28a5c7ea391e@gmx.com> References: <0a9aaf6f-3b68-469f-609f-28a5c7ea391e@gmx.com> Message-ID: <5421517.TRhDxJR1VL@breq> On Donnerstag, 30. Dezember 2021 15:38:47 CET Lars Nood?n via Gnupg-users wrote: > What else is needed to get pinentry invoked so that the SSH client can > connect using the GnuPG RSA key? > > At this point the public key is visible in the SSH agent: > > $ ssh-add -l > 3072 SHA256:j0V4cVzC...NKQPA (none) (RSA) > > and the public key has been saved in the default file: > > $ssh-add -L > ~/.ssh/id_rsa The file ~/.ssh/id_rsa usually contains the secret key. The corresponding public key is usually in the file called ~/.ssh/id_rsa.pub. I'm not sure whether this confuses ssh. Maybe it tries to interpret your public key as secret key. 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 alex.nadtoka at gmail.com Thu Dec 30 17:26:50 2021 From: alex.nadtoka at gmail.com (Alex Nadtoka) Date: Thu, 30 Dec 2021 18:26:50 +0200 Subject: Gpg4win LetsEncrypt issue In-Reply-To: References: <72DA99A8-E69A-4468-BD0B-E4446596182B@andrewg.com> <878rw22mlg.fsf@wheatstone.g10code.de> Message-ID: Actually I just now realized that the things are automated on the server. Certbot+nginx renews SSL certificates every 3 months. And currently keyserver uses the latest SSL certificate with automatically set up CA Root certificates. Even if I remove root certificate from the server it will be added again on renewal. Well again, I have latest gpg4win with latest gnupg and cannot connect to ANY keyserver that uses lets encrypt. BUT I can without any issues connect to my keyserver via GPG Suite for Mac OS, simple command line gpg client on my Ubuntu and CentOS servers. May be the issue is indeed bug in dirmngr ? From command line on windows cmd when I try to connect to keyserver the issue is the same. Pretty weird that I can connect to one keyserver from everywhere except the windows tool... Sorry to bother you... It is just that I am trying to understand the way it may work from the box OR by adding some parameter to GnuPG System menu in Kleopatra configuration... I understand that previously there was some issue with lets encrypt certificates and it was fixed in gnupg 2.2.32 but I was using 2.3.4 version and now tried installing 2.2.32 instead and still no luck. The error is the same 2021-12-30 18:13:16 gpg[17256] DBG: chan_0x00000274 <- ERR 167772261 Certificate expired 2021-12-30 18:13:16 gpg[17256] error searching keyserver: Certificate expired 2021-12-30 18:13:16 gpg[17256] keyserver search failed: Certificate expired Oleksandr ??, 30 ????. 2021 ?. ? 16:44 Alex Nadtoka ????: > Cool thanks. going to test it today > Yesterday tested also with GPG Suite on MacOS - works fine, so only > windows issue I think. > > ??, 30 ????. 2021 ?. ? 16:31 Werner Koch via Gnupg-users < > gnupg-users at gnupg.org> ????: > >> On Wed, 29 Dec 2021 21:33, Andrew Gallagher said: >> >> > OK, so you definitely need to solve the root certificate issue. >> >> This has been fixed with gnupg 2.2.32 - please get an update. The >> workaround is to delete the old LE certificate from your Root CA store. >> >> >> Salam-Shalom, >> >> Werner >> >> -- >> Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. >> _______________________________________________ >> Gnupg-users mailing list >> Gnupg-users at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-users >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars.nooden at gmx.com Thu Dec 30 16:50:07 2021 From: lars.nooden at gmx.com (=?UTF-8?Q?Lars_Nood=c3=a9n?=) Date: Thu, 30 Dec 2021 17:50:07 +0200 Subject: SSH and gpg2: pinentry errors hidden from view, agent refused operation In-Reply-To: <5421517.TRhDxJR1VL@breq> References: <0a9aaf6f-3b68-469f-609f-28a5c7ea391e@gmx.com> <5421517.TRhDxJR1VL@breq> Message-ID: On 12/30/21 17:44, Ingo Kl?cker wrote: > On Donnerstag, 30. Dezember 2021 15:38:47 CET Lars Nood?n via Gnupg-users > wrote: >> What else is needed to get pinentry invoked so that the SSH client can >> connect using the GnuPG RSA key? >> >> At this point the public key is visible in the SSH agent: >> >> $ ssh-add -l >> 3072 SHA256:j0V4cVzC...NKQPA (none) (RSA) >> >> and the public key has been saved in the default file: >> >> $ssh-add -L > ~/.ssh/id_rsa > > The file ~/.ssh/id_rsa usually contains the secret key. The corresponding > public key is usually in the file called ~/.ssh/id_rsa.pub. I'm not sure > whether this confuses ssh. Maybe it tries to interpret your public key as > secret key. > > Regards, > Ingo Sorry. That was a rekeying error, meant to avoid copy-paste errors :/ I have double checked and the public key is indeed in ~/.ssh/id_rsa as it should be. Also, ~/.gnupg/sshcontrol is populated with the keygrip which matches the authentication subkey. /Lars From andrewg at andrewg.com Thu Dec 30 21:53:09 2021 From: andrewg at andrewg.com (Andrew Gallagher) Date: Thu, 30 Dec 2021 20:53:09 +0000 Subject: Gpg4win LetsEncrypt issue In-Reply-To: References: Message-ID: > On 30 Dec 2021, at 16:27, Alex Nadtoka wrote: > > Even if I remove root certificate from the server it will be added again on renewal. It is the client that needs the ca certificate to be removed, not the server. The root cause is that there is more than one verification path possible and unpatched openssl versions pick the wrong (expired) option. A From anze at anze.dev Fri Dec 31 15:57:06 2021 From: anze at anze.dev (Anze Jensterle) Date: Fri, 31 Dec 2021 15:57:06 +0100 Subject: Error in 2.3 regarding reader-port (infinite loop) In-Reply-To: <87zgoi16yj.fsf@wheatstone.g10code.de> References: <87zgoi16yj.fsf@wheatstone.g10code.de> Message-ID: I made a PR to fix this: https://dev.gnupg.org/D547. Best, Anze On Thu, Dec 30, 2021 at 3:52 PM Werner Koch wrote: > > I have attached logs of the wrong and correct behavior I observed > > (debug-level guru, debug-all). > > Yes, this is an obvious bug. We have not yet seen it because on Unix we > prefer to use the CCID driver using a different code path and further > with 2.3 there is not much need to specify a port. > > Here is the bug: > > while (dl->idx < dl->idx_max) > { > const char *rdrname = pcsc.rdrname[dl->idx]; > > if (DBG_READER) > log_debug ("apdu_open_reader: %s\n", rdrname); > > /* Check the identity of reader against already opened one. */ > for (slot = 0; slot < MAX_READER; slot++) > if (reader_table[slot].used > && !strcmp (reader_table[slot].rdrname, rdrname)) > break; > > if (slot == MAX_READER) > { /* Found a new device. */ > if (DBG_READER) > log_debug ("apdu_open_reader: new device=%s\n", rdrname); > > /* When reader string is specified, check if it is the one. > */ > if (readerno < 0 > && strncmp (rdrname, dl->portstr, strlen (dl->portstr)) > != 0) > continue; > > The /continue/ causes the loop because the loop index is not bumped. > > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.nadtoka at gmail.com Fri Dec 31 22:23:52 2021 From: alex.nadtoka at gmail.com (Alex Nadtoka) Date: Fri, 31 Dec 2021 23:23:52 +0200 Subject: Gpg4win LetsEncrypt issue In-Reply-To: References: Message-ID: Ok, thanks. Where on the client end i can remove it? ??, 30 ???. 2021 ?., 23:12 Andrew Gallagher via Gnupg-users < gnupg-users at gnupg.org>: > > > On 30 Dec 2021, at 16:27, Alex Nadtoka wrote: > > > > Even if I remove root certificate from the server it will be added again > on renewal. > > It is the client that needs the ca certificate to be removed, not the > server. The root cause is that there is more than one verification path > possible and unpatched openssl versions pick the wrong (expired) option. > > A > _______________________________________________ > 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 angel at pgp.16bits.net Wed Dec 29 02:33:56 2021 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Wed, 29 Dec 2021 02:33:56 +0100 Subject: Is it possible to require two private keys to decrypt with gpg? In-Reply-To: References: Message-ID: <1c220638a9f36cc707fe59085a4adc6499b26709.camel@16bits.net> On 2021-12-26 at 04:47 +0100, Christian Chavez wrote: > Hi! > > I've currently got some sensitive data I'd like to require _two_ gpg > keys for decryption/unlocking. > > As in both are needed (AND operation), not that either can decrypt on > their own (OR operation). > I can only find description of AND operation in manpages/tutorials > online. > > I'm hoping for a solution which doesn't just require encrypting twice > (though I admit that will give the same security benefit). > The reason why I'd like a "single gpg command solution" is the hope > that such a magical incantation would play well with other tools, > such as pass for passwordstore (e.g.). > > Anyone on this mailing list got any tips on how that might be > achieved? You could use a wrapper which calls gpg twice, while the user only calls your wrapper (as if it is gpg) once. However, I would like to question your need for requiring two gpg keys. How are they two gpg going to be more secure? Usually, if someone was able to steal one key, they could steal the second one as well as the same time, and you could simply require a different second key, or tweak the key parameters to get an higher level, if that's what you want to achieve from the double encryption. Kind regards