From william.yu at work-microwave.com Fri Mar 4 16:33:57 2022 From: william.yu at work-microwave.com (William Yu) Date: Fri, 04 Mar 2022 16:33:57 +0100 Subject: gpgme can't find keys Message-ID: <34f-62223180-27-5891bd00@71048883> Hello, I am running Ubuntu 20.04.4 LTS, I installed libgpgme11 from Ubuntu with version 1.13.1-7ubuntu2 and I installed gpg2 with gpg 2.2.19, libgcrypt 1.8.5. My problem is this, I try to use keys on my computer in a C program and sign something with it. Currently my program can't find any keys. I can see 2 of my keys in terminal with gpg2 --list-keys. One key is 1024 bits, no passphrase, type 4(RSA) key, the other is the same but type 1 + subkey. I attached my test c program, which basically just configured everything according to manual and try to read out the keys. I also tried to generate key with my test program but it returned GPG_ERR_NOT_SUPPORTED. I setup everything as default, so my home folder is /home/wyu/.gnupg, gpg2 locates in /usr/bin/gpg2 and so on. Maybe someone could tell me what have I missed? Thanks a lot and best regards, William -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: tstgpgme.c Type: text/x-csrc Size: 3999 bytes Desc: not available URL: From kloecker at kde.org Fri Mar 4 22:57:27 2022 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Fri, 04 Mar 2022 22:57:27 +0100 Subject: gpgme can't find keys In-Reply-To: <34f-62223180-27-5891bd00@71048883> References: <34f-62223180-27-5891bd00@71048883> Message-ID: <2670808.THPNoRzmsY@breq> On Freitag, 4. M?rz 2022 16:33:57 CET William Yu via Gnupg-users wrote: > I am running Ubuntu 20.04.4 LTS, I installed libgpgme11 from Ubuntu with > version 1.13.1-7ubuntu2 and I installed gpg2 with gpg 2.2.19, libgcrypt > 1.8.5. > > My problem is this, I try to use keys on my computer in a C program and sign > something with it. Currently my program can't find any keys. I can see 2 of > my keys in terminal with gpg2 --list-keys. One key is 1024 bits, no > passphrase, type 4(RSA) key, the other is the same but type 1 + subkey. I > attached my test c program, which basically just configured everything > according to manual and try to read out the keys. I also tried to generate > key with my test program but it returned GPG_ERR_NOT_SUPPORTED. > > I setup everything as default, so my home folder is /home/wyu/.gnupg, gpg2 > locates in /usr/bin/gpg2 and so on. Maybe someone could tell me what have I > missed? Please have a look at the test programs that you can find under https://dev.gnupg.org/source/gpgme/browse/master/tests/ in particular, run-keylist.c which shows how to list keys and run-genkey.c which shows how to generate keys. 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 sven.schultschik at siemens.com Thu Mar 10 14:30:29 2022 From: sven.schultschik at siemens.com (Schultschik, Sven) Date: Thu, 10 Mar 2022 13:30:29 +0000 Subject: Cancel operation does not return error code Message-ID: Hi, if your using gpgme with interactive password entry on the command line and the user cancels the operation, shouldn't there be an error returned? Following code err = gpgme_op_encrypt(ctx, NULL, GPGME_ENCRYPT_SYMMETRIC, in, out); fprintf(stdout, "DEBUG ERROR Code = \%d \%s \%s\n" , gpgme_err_code(err), gpgme_strsource(err) , gpgme_strerror(err)); If user cancel on the passwort screen, the following error code is returned ERROR Code = 0 Unspecified source Success If I look at the docu and search through the net, there is always said that GPG_ERR_CANCELED should be returned. https://www.gnupg.org/documentation/manuals/gpgme/Error-Codes.html Why this is important? The output stream already created the output file and if the users cancel the operation I need an indicator to do a cleanup afterwards. Thx Regards Sven -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 14944 bytes Desc: not available URL: From sven.schultschik at siemens.com Thu Mar 10 16:10:49 2022 From: sven.schultschik at siemens.com (Schultschik, Sven) Date: Thu, 10 Mar 2022 15:10:49 +0000 Subject: Cancel operation does not return error code In-Reply-To: References: Message-ID: Hi, if your using gpgme with interactive password entry on the command line and the user cancels the operation, shouldn't there be an error returned? Following code err = gpgme_op_encrypt(ctx, NULL, GPGME_ENCRYPT_SYMMETRIC, in, out); fprintf(stdout, "DEBUG ERROR Code = \%d \%s \%s\n" , gpgme_err_code(err), gpgme_strsource(err) , gpgme_strerror(err)); If user cancel on the passwort screen, the following error code is returned ERROR Code = 0 Unspecified source Success If I look at the docu and search through the net, there is always said that GPG_ERR_CANCELED should be returned. https://www.gnupg.org/documentation/manuals/gpgme/Error-Codes.html Why this is important? The output stream already created the output file and if the users cancel the operation I need an indicator to do a cleanup afterwards. Thx Regards Sven From kloecker at kde.org Thu Mar 10 22:15:50 2022 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Thu, 10 Mar 2022 22:15:50 +0100 Subject: Cancel operation does not return error code In-Reply-To: References: Message-ID: <1945751.NjBk4Wa9oY@daneel> On Donnerstag, 10. M?rz 2022 14:30:29 CET Schultschik, Sven via Gnupg-users wrote: > if your using gpgme with interactive password entry on the command line and > the user cancels the operation, shouldn't there be an error returned? > > Following code > > err = gpgme_op_encrypt(ctx, NULL, GPGME_ENCRYPT_SYMMETRIC, in, out); > > fprintf(stdout, "DEBUG ERROR Code = \%d \%s \%s\n" , gpgme_err_code(err), > gpgme_strsource(err) , gpgme_strerror(err)); > > If user cancel on the passwort screen, the following error code is returned > > ERROR Code = 0 Unspecified source Success When I run t-encrypt-sym (in gpgme/tests/gpg) and cancel the passphrase dialog provided by pinentry-qt, then t-encrypt-sym prints ../../../../src/gpgme/tests/gpg/t-encrypt-sym.c:67: GPGME: Operation cancelled When I force usage of pinentry-tty and cancel the passphrase entry with Ctrl+D, then I get the same result: ===== $ ./t-encrypt-sym Enter passphrase Passphrase: ../../../../src/gpgme/tests/gpg/t-encrypt-sym.c:67: GPGME: Operation cancelled ===== So, in general, gpgme_op_encrypt seems to return the correct error code. What I'm wondering is how do you cancel "interactive password entry on the command line" resp. how do you do "interactive password entry on the command line"? 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 sven.schultschik at siemens.com Fri Mar 11 10:29:41 2022 From: sven.schultschik at siemens.com (Schultschik, Sven) Date: Fri, 11 Mar 2022 09:29:41 +0000 Subject: AW: Cancel operation does not return error code In-Reply-To: <1945751.NjBk4Wa9oY@daneel> References: <1945751.NjBk4Wa9oY@daneel> Message-ID: The method gpgme_op_encrypt provides the interactive possibility itself. If you don't set a passphrase with gpgme_set_passphrase_cb before calling gpgme_op_encrypt, it asks itself for a passphrase. See screenshot. There are more issues with this interactive view. 1. Cancel does not send an error 2. If you wait for the timeout of the passphrase form, it returns Error 0 Success as well 3. Ctrl+C does not cancel the gpgme passphrase entry. See screenshot 2 Ctrl+C I tried to fix by catching the ctrl+c signal an cancel gpgme itself void signal_callback_handler(int signum) { gpgme_error_t err = gpgme_cancel(_ctx); _ctx = gpgme_wait(_ctx, &err, false); } signal(SIGINT, signal_callback_handler); regards Sven -----Urspr?ngliche Nachricht----- Von: Gnupg-users Im Auftrag von Ingo Kl?cker Gesendet: Donnerstag, 10. M?rz 2022 22:16 An: gnupg-users at gnupg.org Betreff: Re: Cancel operation does not return error code On Donnerstag, 10. M?rz 2022 14:30:29 CET Schultschik, Sven via Gnupg-users wrote: > if your using gpgme with interactive password entry on the command > line and the user cancels the operation, shouldn't there be an error returned? > > Following code > > err = gpgme_op_encrypt(ctx, NULL, GPGME_ENCRYPT_SYMMETRIC, in, out); > > fprintf(stdout, "DEBUG ERROR Code = \%d \%s \%s\n" , > gpgme_err_code(err), > gpgme_strsource(err) , gpgme_strerror(err)); > > If user cancel on the passwort screen, the following error code is > returned > > ERROR Code = 0 Unspecified source Success When I run t-encrypt-sym (in gpgme/tests/gpg) and cancel the passphrase dialog provided by pinentry-qt, then t-encrypt-sym prints ../../../../src/gpgme/tests/gpg/t-encrypt-sym.c:67: GPGME: Operation cancelled When I force usage of pinentry-tty and cancel the passphrase entry with Ctrl+D, then I get the same result: ===== $ ./t-encrypt-sym Enter passphrase Passphrase: ../../../../src/gpgme/tests/gpg/t-encrypt-sym.c:67: GPGME: Operation cancelled ===== So, in general, gpgme_op_encrypt seems to return the correct error code. What I'm wondering is how do you cancel "interactive password entry on the command line" resp. how do you do "interactive password entry on the command line"? Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: ctrl-c.png Type: image/png Size: 15046 bytes Desc: ctrl-c.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 2022-03-11 09_54_07-Clipboard.png Type: image/png Size: 6866 bytes Desc: 2022-03-11 09_54_07-Clipboard.png URL: From kloecker at kde.org Fri Mar 11 11:17:33 2022 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Fri, 11 Mar 2022 11:17:33 +0100 Subject: Cancel operation does not return error code In-Reply-To: References: <1945751.NjBk4Wa9oY@daneel> Message-ID: <2091051.FdYHGDcMvI@daneel> [It would be great, if you wouldn't top-post even if this isn't easy with Outlook or Office 365 or whatever email client you are using.] On Freitag, 11. M?rz 2022 10:29:41 CET Schultschik, Sven via Gnupg-users wrote: > The method gpgme_op_encrypt provides the interactive possibility itself. > > If you don't set a passphrase with gpgme_set_passphrase_cb before calling > gpgme_op_encrypt, it asks itself for a passphrase. > > See screenshot. Okay. You are using pinentry-curses. > There are more issues with this interactive view. > > 1. Cancel does not send an error I cannot reproduce this. For me it works correctly. ``` $ export GNUPGHOME=$(mktemp --directory) $ cat >${GNUPGHOME}/gpg-agent.conf < 2. If you wait for the timeout of the passphrase form, it returns Error 0 > Success as well Let's try. ``` $ cat >>${GNUPGHOME}/gpg-agent.conf < 3. Ctrl+C does not cancel the gpgme passphrase entry. See > screenshot 2 Pressing Ctrl+C while t-encrypt-sym is running and pinentry-curses is asking for the password quits pinentry-curses and t-encrypt-sym without further output. That's common behavior for command line programs. My conclusion is that gpgme_op_encrypt() is working as expected as my experiments with the official test t-encrypt-sym proves. I suspect that there is something wrong with your program. Please have a look at the official test t-encrypt-sym (in tests/gpg of gpgme's source code) and check what you are doing differently. I'm using gpgme 1.17.1. Regards, Ingo > -----Urspr?ngliche Nachricht----- > Von: Gnupg-users Im Auftrag von Ingo Kl?cker > Gesendet: Donnerstag, 10. M?rz 2022 22:16 > An: gnupg-users at gnupg.org > Betreff: Re: Cancel operation does not return error code > > On Donnerstag, 10. M?rz 2022 14:30:29 CET Schultschik, Sven via Gnupg-users > > wrote: > > if your using gpgme with interactive password entry on the command > > line and the user cancels the operation, shouldn't there be an error > > returned? > > > > Following code > > > > err = gpgme_op_encrypt(ctx, NULL, GPGME_ENCRYPT_SYMMETRIC, in, out); > > > > fprintf(stdout, "DEBUG ERROR Code = \%d \%s \%s\n" , > > gpgme_err_code(err), > > gpgme_strsource(err) , gpgme_strerror(err)); > > > > If user cancel on the passwort screen, the following error code is > > returned > > > > ERROR Code = 0 Unspecified source Success > > When I run t-encrypt-sym (in gpgme/tests/gpg) and cancel the passphrase > dialog provided by pinentry-qt, then t-encrypt-sym prints > ../../../../src/gpgme/tests/gpg/t-encrypt-sym.c:67: GPGME: Operation > cancelled > > When I force usage of pinentry-tty and cancel the passphrase entry with > Ctrl+D, then I get the same result: > ===== > $ ./t-encrypt-sym > Enter passphrase > > Passphrase: > ../../../../src/gpgme/tests/gpg/t-encrypt-sym.c:67: GPGME: Operation > cancelled ===== > > So, in general, gpgme_op_encrypt seems to return the correct error code. > What I'm wondering is how do you cancel "interactive password entry on the > command line" resp. how do you do "interactive password entry on the > command line"? > > 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 sven.schultschik at siemens.com Fri Mar 11 13:02:02 2022 From: sven.schultschik at siemens.com (Schultschik, Sven) Date: Fri, 11 Mar 2022 12:02:02 +0000 Subject: AW: Cancel operation does not return error code In-Reply-To: <2091051.FdYHGDcMvI@daneel> References: <1945751.NjBk4Wa9oY@daneel> <2091051.FdYHGDcMvI@daneel> Message-ID: [Sorry, i need to use outlook even if I don't like it, but I will try to make things better if I know whats wrong. Outlook doesn't even format text answers correctly :( I made it by hand ... ] > -----Urspr?ngliche Nachricht----- > Von: Gnupg-users Im Auftrag von Ingo Kl?cker > Gesendet: Freitag, 11. M?rz 2022 11:18 > An: gnupg-users at gnupg.org > Betreff: Re: Cancel operation does not return error code > > [It would be great, if you wouldn't top-post even if this isn't easy with Outlook or Office 365 or whatever email client you are using.] > > On Freitag, 11. M?rz 2022 10:29:41 CET Schultschik, Sven via Gnupg-users > wrote: > > The method gpgme_op_encrypt provides the interactive possibility itself. > > > > If you don't set a passphrase with gpgme_set_passphrase_cb before > > calling gpgme_op_encrypt, it asks itself for a passphrase. > > > > See screenshot. > > Okay. You are using pinentry-curses. > > > There are more issues with this interactive view. > > > > 1. Cancel does not send an error > > I cannot reproduce this. For me it works correctly. > ``` > $ export GNUPGHOME=$(mktemp --directory) $ cat >${GNUPGHOME}/gpg-agent.conf <../../../../src/gpgme/tests/gpg/t-encrypt-sym.c:67: GPGME: Operation cancelled ``` > > > 2. If you wait for the timeout of the passphrase form, it returns > > Error 0 Success as well > > Let's try. > ``` > $ cat >>${GNUPGHOME}/gpg-agent.conf <../../../../src/gpgme/tests/gpg/t-encrypt-sym.c:67: GPGME: Operation cancelled ``` > > > 3. Ctrl+C does not cancel the gpgme passphrase entry. See screenshot 2 > > Pressing Ctrl+C while t-encrypt-sym is running and pinentry-curses is asking for the password quits pinentry-curses and t-encrypt-sym without further output. That's common behavior for command line programs. > > My conclusion is that gpgme_op_encrypt() is working as expected as my experiments with the official test t-encrypt-sym proves. I suspect that there is something wrong with your program. Please have a look at the official test t-encrypt-sym (in tests/gpg > of gpgme's source code) and check what you are doing differently. I pretty much copied the tests/gpg/t-encrypt-sym.c Only difference is to use streams instead of mem int encryptBackup(string infile, bool cliintpw, string webpw) { gpgme_check_version(NULL); gpgme_error_t err; gpgme_encrypt_result_t result; init_gpgme(); err = gpgme_new(&_ctx); fail_if_err(err, NULL, NULL); gpgme_set_armor(_ctx, 1); FILE *instream; instream = fopen(infile.c_str(), "r"); if (instream == NULL) { throw runtime_error("Backup archive not found " + infile + "\n"); } gpgme_data_t in = NULL; err = gpgme_data_new_from_stream(&in, instream); fail_if_err(err, in, NULL, instream); FILE *outstream; _encryptedArchiveFullFilePath = infile.append(".gpg"); outstream = fopen(_encryptedArchiveFullFilePath.c_str(), "w"); gpgme_data_t out = NULL; err = gpgme_data_new_from_stream(&out, outstream); fail_if_err(err, in, out, instream, outstream, _encryptedArchiveFullFilePath); fprintf(stdout, "DEBUG Start encryption\n"); err = gpgme_op_encrypt(_ctx, NULL, GPGME_ENCRYPT_SYMMETRIC, in, out); fprintf(stdout, "DEBUG ERROR Code = \%d \%s \%s\n" , gpgme_err_code(err), gpgme_strsource(err) , gpgme_strerror(err)); fprintf(stdout, "DEBUG End encryption\n"); fprintf(stdout, "DEBUG Outpath = \%s\n", _encryptedArchiveFullFilePath.c_str()); fail_if_err(err, in, out, instream, outstream, _encryptedArchiveFullFilePath); result = gpgme_op_encrypt_result(_ctx); if (result->invalid_recipients) { string err(result->invalid_recipients->fpr); throw runtime_error("Invalid recipient encountered: " + err + "\n"); } fclose(instream); fclose(outstream); gpgme_data_release(in); gpgme_data_release(out); gpgme_release(_ctx); return 0; } > I'm using gpgme 1.17.1. I'm on Debian 11 with 1.14.0-1 Could it be a bug in the "old" version? Regards Sven > Regards, > Ingo > > -----Urspr?ngliche Nachricht----- > > Von: Gnupg-users Im Auftrag von Ingo > > Kl?cker > > Gesendet: Donnerstag, 10. M?rz 2022 22:16 > > An: gnupg-users at gnupg.org > > Betreff: Re: Cancel operation does not return error code > > > > On Donnerstag, 10. M?rz 2022 14:30:29 CET Schultschik, Sven via > > Gnupg-users > > > > wrote: > > > if your using gpgme with interactive password entry on the command > > > line and the user cancels the operation, shouldn't there be an error > > > returned? > > > > > > Following code > > > > > > err = gpgme_op_encrypt(ctx, NULL, GPGME_ENCRYPT_SYMMETRIC, in, out); > > > > > > fprintf(stdout, "DEBUG ERROR Code = \%d \%s \%s\n" , > > > gpgme_err_code(err), > > > gpgme_strsource(err) , gpgme_strerror(err)); > > > > > > If user cancel on the passwort screen, the following error code is > > > returned > > > > > > ERROR Code = 0 Unspecified source Success > > > > When I run t-encrypt-sym (in gpgme/tests/gpg) and cancel the > > passphrase dialog provided by pinentry-qt, then t-encrypt-sym prints > > ../../../../src/gpgme/tests/gpg/t-encrypt-sym.c:67: GPGME: Operation > > cancelled > > > > When I force usage of pinentry-tty and cancel the passphrase entry > > with > > Ctrl+D, then I get the same result: > > ===== > > $ ./t-encrypt-sym > > Enter passphrase > > > > Passphrase: > > ../../../../src/gpgme/tests/gpg/t-encrypt-sym.c:67: GPGME: Operation > > cancelled ===== > > > > So, in general, gpgme_op_encrypt seems to return the correct error code. > > What I'm wondering is how do you cancel "interactive password entry on > > the command line" resp. how do you do "interactive password entry on > > the command line"? > > > > Regards, > > Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 14944 bytes Desc: not available URL: From sven.schultschik at siemens.com Fri Mar 11 17:05:44 2022 From: sven.schultschik at siemens.com (Schultschik, Sven) Date: Fri, 11 Mar 2022 16:05:44 +0000 Subject: AW: Cancel operation does not return error code In-Reply-To: <2091051.FdYHGDcMvI@daneel> References: <1945751.NjBk4Wa9oY@daneel> <2091051.FdYHGDcMvI@daneel> Message-ID: > -----Urspr?ngliche Nachricht----- > Von: Gnupg-users Im Auftrag von Ingo Kl?cker > Gesendet: Freitag, 11. M?rz 2022 11:18 > An: gnupg-users at gnupg.org > Betreff: Re: Cancel operation does not return error code > > [It would be great, if you wouldn't top-post even if this isn't easy with Outlook or Office 365 or whatever email client you are using.] > > > 3. Ctrl+C does not cancel the gpgme passphrase entry. See screenshot 2 > > Pressing Ctrl+C while t-encrypt-sym is running and pinentry-curses is asking for the password quits pinentry-curses and t-encrypt-sym without further output. That's common behavior for command line programs. The problem is not that it quits without any further ouput. The problem is, that the command line is broken after a ctrl+c and the pinentry-curse is somehow still alife. You can't type or it is not visible. If you hit enter you get back to the pinentry saying that you don't inserted any passwort. Is there a proper way or example how to cancel all operations on a ctrl-c signal? > > My conclusion is that gpgme_op_encrypt() is working as expected as my experiments with the official test t-encrypt-sym proves. I suspect that there is something wrong with your program. Please have a look at the official test t-encrypt-sym (in tests/gpg > of gpgme's source code) and check what you are doing differently. > > I'm using gpgme 1.17.1. I tested now in a docker container with Arch:latest and gpgme 1.17 and the Canceloperation err returned as expected. It really seems to be a bug in the 1.14. Regards Sven From kloecker at kde.org Fri Mar 11 22:21:57 2022 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Fri, 11 Mar 2022 22:21:57 +0100 Subject: Cancel operation does not return error code In-Reply-To: References: <2091051.FdYHGDcMvI@daneel> Message-ID: <10300209.2QMzp5bVFr@daneel> On Freitag, 11. M?rz 2022 17:05:44 CET Schultschik, Sven via Gnupg-users wrote: > > -----Urspr?ngliche Nachricht----- > > Von: Gnupg-users Im Auftrag von Ingo > > Kl?cker Gesendet: Freitag, 11. M?rz 2022 11:18 > > An: gnupg-users at gnupg.org > > Betreff: Re: Cancel operation does not return error code > > > > [It would be great, if you wouldn't top-post even if this isn't easy with > > Outlook or Office 365 or whatever email client you are using.]> > > > 3. Ctrl+C does not cancel the gpgme passphrase entry. See screenshot 2 > > > > Pressing Ctrl+C while t-encrypt-sym is running and pinentry-curses is > > asking for the password quits pinentry-curses and t-encrypt-sym without > > further output. That's common behavior for command line programs. > > The problem is not that it quits without any further ouput. The problem is, > that the command line is broken after a ctrl+c and the pinentry-curse is > somehow still alife. You can't type or it is not visible. If you hit enter > you get back to the pinentry saying that you don't inserted any passwort. Hmm, I didn't observe this problem with t-encrypt-sym. Maybe using pinentry- tty is an option. It's not as fancy as the curses one, but hopefully it doesn't mess up the terminal on Ctrl+C. > Is there a proper way or example how to cancel all operations on a ctrl-c > signal? There is gpgme_cancel and gpgme_cancel_async: https://www.gnupg.org/documentation/manuals/gpgme/Cancellation.html But I don't know how to use them to cancel all operations on Ctrl+C. > > My conclusion is that gpgme_op_encrypt() is working as expected as my > > experiments with the official test t-encrypt-sym proves. I suspect that > > there is something wrong with your program. Please have a look at the > > official test t-encrypt-sym (in tests/gpg > of gpgme's source code) and > > check what you are doing differently. > > > > I'm using gpgme 1.17.1. > > I tested now in a docker container with Arch:latest and gpgme 1.17 and the > Canceloperation err returned as expected. It really seems to be a bug in > the 1.14. Yes. Could have been fixed by the following commit: https://dev.gnupg.org/rM35ca460019ea29ae646d08c954d4d4bf2dc1e8e1 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 alireza0101sadeghpour at gmail.com Sat Mar 12 10:19:27 2022 From: alireza0101sadeghpour at gmail.com (Alireza Sadeghpour) Date: Sat, 12 Mar 2022 12:49:27 +0330 Subject: why injecting same RSA keys to different smartcards lead to different key id's Message-ID: I've injected the same RSA keys to two different smartcard using the pkcs11-tool, but when I import them in the gpg I got different keyids. With this behavior a critical problem arises in the below scenario: Consider I've generated an RSA key pair to sign and verify patches of a product, and I backed up them in a safe environment and injected them in a smartcard#1. Then I imported the smart-card resident keys to gpg. In the product, I use the corresponding public key to verify the product patches. If something goes wrong with smartcard#1, I expect to inject the backed-up keys to smartcard#2 and use it to sign patches of the product. However, if I import smartcard#2 keys in the gpg it leads to different key ids in comparison to smartcard#1 and as the result, the product couldn't verify the patch because the keyids are different. Is there any workaround for this problem? -------------- next part -------------- An HTML attachment was scrubbed... URL: From kloecker at kde.org Sun Mar 13 11:05:06 2022 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Sun, 13 Mar 2022 11:05:06 +0100 Subject: why injecting same RSA keys to different smartcards lead to different key id's In-Reply-To: References: Message-ID: <3314416.8NBhnVKgxC@daneel> On Samstag, 12. M?rz 2022 10:19:27 CET Alireza Sadeghpour via Gnupg-users wrote: > I've injected the same RSA keys to two different smartcard using the > pkcs11-tool, but when I import them in the gpg I got different keyids. This is probably due to the fact that the creation date/time of the key is included in the calculation of the fingerprint and thus the key ID. My guess is that the creation date/time differs for the two smartcards. > Is there any workaround for this problem? You can experiment with gpg's --faked-system-time option, when you import the keys from the smartcards, or, alternatively, with some other tool that fakes the system time. 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 marckilaver at gmail.com Sun Mar 13 17:23:50 2022 From: marckilaver at gmail.com (marckilaver at gmail.com) Date: Sun, 13 Mar 2022 10:23:50 -0600 Subject: key creation time Message-ID: > This is probably due to the fact that the creation date/time of the key is > included in the calculation of the fingerprint and thus the key ID. My guess > is that the creation date/time differs for the two smartcards. Would someone be kind enough to explain the reason for including the creation time in the key-pair in general, and the reason for including it in the fingerprint derivation in particular? (It appears to be an item that has no role in the encryption process whatsoever, while on the other hand provides the adversary with information that the key user might in some instances prefer not be known to the adversary?) Regards, MarcK From sven.schultschik at siemens.com Mon Mar 14 10:54:42 2022 From: sven.schultschik at siemens.com (Schultschik, Sven) Date: Mon, 14 Mar 2022 09:54:42 +0000 Subject: AW: Cancel operation does not return error code In-Reply-To: <10300209.2QMzp5bVFr@daneel> References: <2091051.FdYHGDcMvI@daneel> <10300209.2QMzp5bVFr@daneel> Message-ID: > -----Urspr?ngliche Nachricht----- > Von: Gnupg-users Im Auftrag von Ingo Kl?cker > Gesendet: Freitag, 11. M?rz 2022 22:22 > An: gnupg-users at gnupg.org > Betreff: Re: Cancel operation does not return error code > > On Freitag, 11. M?rz 2022 17:05:44 CET Schultschik, Sven via Gnupg-users > wrote: > > > -----Urspr?ngliche Nachricht----- > > > Von: Gnupg-users Im Auftrag von Ingo > > > Kl?cker Gesendet: Freitag, 11. M?rz 2022 11:18 > > > An: gnupg-users at gnupg.org > > > Betreff: Re: Cancel operation does not return error code > > > > > > [It would be great, if you wouldn't top-post even if this isn't easy > > > with Outlook or Office 365 or whatever email client you are using.]> > > > > 3. Ctrl+C does not cancel the gpgme passphrase entry. See > > > > screenshot 2 > > > > > > Pressing Ctrl+C while t-encrypt-sym is running and pinentry-curses > > > is asking for the password quits pinentry-curses and t-encrypt-sym > > > without further output. That's common behavior for command line programs. > > > > The problem is not that it quits without any further ouput. The > > problem is, that the command line is broken after a ctrl+c and the > > pinentry-curse is somehow still alife. You can't type or it is not > > visible. If you hit enter you get back to the pinentry saying that you don't inserted any passwort. > > Hmm, I didn't observe this problem with t-encrypt-sym. Maybe using pinentry- tty is an option. It's not as fancy as the curses one, but hopefully it doesn't mess up the terminal on Ctrl+C. I didn't saw that there is a possible choose between different pinentry terminal modes. I thought there is only modes ASK or LOOPBACK to choose of https://www.gnupg.org/documentation/manuals/gpgme/Pinentry-Mode.html#Pinentr y-Mode > > > Is there a proper way or example how to cancel all operations on a > > ctrl-c signal? > > There is gpgme_cancel and gpgme_cancel_async: > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.gnupg. org%2Fdocumentation%2Fmanuals%2Fgpgme%2FCancellation.html&data=04%7C01%7 Csven.schultschik%40siemens.com% 7C9be151e1b53748551dc108da03a5b0af%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C 0%7C637826308011207949%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=B%2FwuWdAQ%2FyWZa5AAP 7MTFxR7xbwdo%2Fl6iiREatwfIOE%3D&reserved=0 > But I don't know how to use them to cancel all operations on Ctrl+C. I'm using the Cancel methods on ctrl+c but the terminal is anyway messed up. Would it be worth a bug report? I tried both gpgme_cancel and gpgme_cancel_async with same result. /** * Clean Up after ctrl-c * * @since 1.2.0 * * @param signum */ void signal_callback_handler(int signum) { fprintf(stdout, "Interrupt signal caught\n"); if (_ctx) { fprintf(stdout, "DEBUG cancel async"); gpgme_error_t err = gpgme_cancel_async(_ctx); fail_if_err(err); _ctx = gpgme_wait(_ctx, &err, false); fail_if_err(err); } // Terminate program exit(signum); } -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 14944 bytes Desc: not available URL: From wk at gnupg.org Tue Mar 15 12:50:30 2022 From: wk at gnupg.org (Werner Koch) Date: Tue, 15 Mar 2022 12:50:30 +0100 Subject: AW: Cancel operation does not return error code In-Reply-To: (Sven via Gnupg-users Schultschik's message of "Mon, 14 Mar 2022 09:54:42 +0000") References: <2091051.FdYHGDcMvI@daneel> <10300209.2QMzp5bVFr@daneel> Message-ID: <87wngva0zd.fsf@wheatstone.g10code.de> > I'm using the Cancel methods on ctrl+c but the terminal is anyway messed up. > Would it be worth a bug report? No. The pinentry is background process and there is no portable way to save and restore the screen. Thus your application may want to do something like this after a gpgme operation: if ((s = gpgme_get_ctx_flag (ctx, "redraw")) && *s) fputs ("Screen redraw suggested\n", stdout); Salam-Shalom, Werner p.s. Please trim your quotes to make them easier for everyone to read. -- 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 kaleb.dk at gmail.com Wed Mar 16 09:26:15 2022 From: kaleb.dk at gmail.com (Daniel Kilimnik) Date: Wed, 16 Mar 2022 09:26:15 +0100 Subject: Change Passphrase in Batch Mode Message-ID: Hey, I am trying to change a passphrase of my gpg keys as part of a script. I saw the --change-passphrase option, but I could not get it to work in batch mode. With --pinentry-mode loopback --passphrase-fd 0 activated. It asks for my current passphrase, but then exits with a success. The whole command I used was this: gpg --pinentry-mode loopback --status-fd 2 --no-tty --no-verbose --batch --home /tmp/keys --passphrase-fd 0 --change-passphrase 6ABA6B37E3566FAAB258F9E0E5E81AFB0F59B624 Maybe somone has an idea how to do this properly. Thx Regards Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From contact at hubert-lombard.website Wed Mar 16 13:13:00 2022 From: contact at hubert-lombard.website (Hubert Lombard) Date: Wed, 16 Mar 2022 13:13:00 +0100 Subject: (my) E-mail address not found by 'https://keys.openpgp.org' Message-ID: <5ee33d90ccf2252b1308294e43f43ef9964a99e8.camel@hubert-lombard.website> Hello ! I recently started to get interested in GPG. Last week, during my first tests, I sent my first key to 'keys.gnupg.net' but I understood only yesterday that this server could have been compromised since 2019. When I tried to revoke the key permanently, it was not found. So I deleted the key from my computer with Seahorse, and immediately after, still with Seahorse, I generated a new key pair using the same email address and choosing the key server 'keys.openpgp.org' When creating this new key pair, instead of going directly to the revocation step, I sent my public key. After that, I performed the revocation step. Could the inversion of these 2 steps have had an impact on the fact that 'https://keys.openpgp.org/' does not find my e-mail address? On the other hand, it does find my E67C43563F94C4756557A483B2A8FF57185B13B0 key I'm wondering at this point if there is an error I could fix or if it's better to revoke/delete this current key-pair. Thank in advance for your advice Regards Hubert -- Hubert Lombard From me at entrez.cc Wed Mar 16 14:51:53 2022 From: me at entrez.cc (Michael Meyer) Date: Wed, 16 Mar 2022 13:51:53 +0000 Subject: (my) E-mail address not found by 'https://keys.openpgp.org' In-Reply-To: <5ee33d90ccf2252b1308294e43f43ef9964a99e8.camel@hubert-lombard.website> References: <5ee33d90ccf2252b1308294e43f43ef9964a99e8.camel@hubert-lombard.website> Message-ID: <20220316135149.ioauuk366qiamfqa@rain.local> Hi, On Wed, Mar 16, 2022 at 01:13:00PM +0100, Hubert Lombard wrote: > Could the inversion of these 2 steps have had an impact on the fact > that 'https://keys.openpgp.org/' does not find my e-mail address? > On the other hand, it does find my > E67C43563F94C4756557A483B2A8FF57185B13B0 key Unlike most keyservers, keys.openpgp.org requires you verify your email address before the key is available by email, but it can be searched by fingerprint even without that (though it won't contain the email information, iirc). Since this sounds similar, it seems to me like you may not have completed this verification step, or something went wrong there. - Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: attachment.asc Type: application/pgp-signature Size: 849 bytes Desc: not available URL: From hfollmann at itcfollmann.com Wed Mar 16 15:57:58 2022 From: hfollmann at itcfollmann.com (Henning Follmann) Date: Wed, 16 Mar 2022 10:57:58 -0400 Subject: (my) E-mail address not found by 'https://keys.openpgp.org' In-Reply-To: <5ee33d90ccf2252b1308294e43f43ef9964a99e8.camel@hubert-lombard.website> References: <5ee33d90ccf2252b1308294e43f43ef9964a99e8.camel@hubert-lombard.website> Message-ID: On Wed, Mar 16, 2022 at 01:13:00PM +0100, Hubert Lombard wrote: > Hello ! > > I recently started to get interested in GPG. Last week, during my first > tests, I sent my first key to 'keys.gnupg.net' > but I understood only yesterday that this server could have been > compromised since 2019. When I tried to revoke the key permanently, it > was not found. > So I deleted the key from my computer with Seahorse, and immediately > after, still with Seahorse, I generated a new key pair using the same > email address and choosing the key server 'keys.openpgp.org' Why? The integrity of your privat key will not be affected by the keyserver you put your public key on. > > When creating this new key pair, instead of going directly to the > revocation step, I sent my public key. > After that, I performed the revocation step. That again does not make any sense. Why would you create a key pair just to revoke this immediately? > > Could the inversion of these 2 steps have had an impact on the fact > that 'https://keys.openpgp.org/' does not find my e-mail address? > On the other hand, it does find my > E67C43563F94C4756557A483B2A8FF57185B13B0 key > > I'm wondering at this point if there is an error I could fix or if it's > better to revoke/delete this current key-pair. Maybe you want to read the GNU Privacy Handbook https://gnupg.org/gph/en/manual.html It is not a perfect beginners guide but it may give you a better understanding how things are working. > > Thank in advance for your advice > > Regards > > Hubert > -- > Hubert Lombard > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > https://lists.gnupg.org/mailman/listinfo/gnupg-users -- Henning Follmann | hfollmann at itcfollmann.com From hfollmann at itcfollmann.com Wed Mar 16 20:00:18 2022 From: hfollmann at itcfollmann.com (Henning Follmann) Date: Wed, 16 Mar 2022 15:00:18 -0400 Subject: (my) E-mail address not found by 'https://keys.openpgp.org' In-Reply-To: <914dbf2b313a6d13dcc7f5e22597be06d471a4de.camel@hubert-lombard.website> References: <5ee33d90ccf2252b1308294e43f43ef9964a99e8.camel@hubert-lombard.website> <914dbf2b313a6d13dcc7f5e22597be06d471a4de.camel@hubert-lombard.website> Message-ID: On Wed, Mar 16, 2022 at 07:39:35PM +0100, Hubert Lombard wrote: > Hi Henning! > > > On Wed, Mar 16, 2022 at 01:13:00PM +0100, Hubert Lombard wrote: > > > Hello ! > > > > > > I recently started to get interested in GPG. Last week, during my > > > first > > > tests, I sent my first key to 'keys.gnupg.net' > > > but I understood only yesterday that this server could have been > > > compromised since 2019. When I tried to revoke the key permanently, > > > it > > > was not found. > > > So I deleted the key from my computer with Seahorse, and immediately > > > after, still with Seahorse, I generated? a new key pair using the > > > same > > > email address and choosing the key server 'keys.openpgp.org' > > > > Why? The integrity of your privat key will not be affected by the > > keyserver you put your public key on. > > > Oh, I didn't know, I was advised yesterday on another irc channel > (#debian-facile) to change my key server: > > "They were ('keys.gnupg.net' and others) all flooded with fake keys > mid-2019 > this is the reason why debian, among others, uses keys.openpgp.org as a > keyserver > see also CVE-2019-13050 (SKS servers poisoning)" Well, that was good advice, however you didn't have to revoke your key. Your key was not compromized by using a different key server. You'll revoke your key when you think something is wrong with your private key. And it basically is a public notice to anybody else to not trust that key after a certain date. But it will not remove the key from anywhere. It's out there for good. > > > > > > > > When creating this new key pair, instead of going directly to the > > > revocation step, I sent my public key. > > > After that, I performed the revocation step. > > > > That again does not make any sense. Why would you create a key pair > > just to revoke this immediately? > > > In fact, while following some instructions for use, I have just tried > to generate the revocation certificates. > As English is not my native language, there may have been an ambiguity > in the form of my question. > I mistakenly used the term "performed", when I simply tried to generate > the certificates, > just to have them on hand... That is common practice. And yes I obviously misunderstood. > > hubert at gnu ~$ gpg --gen-revoke 185B13B0 > .gnupg/openpgp- > revocs.d/E67C43563F94C4756557A483B2A8FF57185B13B0.rev > > sec rsa2048/B2A8FF57185B13B0 2022-03-15 Hubert Lombard > > > Faut-il cr?er un certificat de r?vocation pour cette clef?? (o/N) > > I have left "N' > > I was afraid that by choosing 'o', the key would be permanently > revoked. > > I will have to clarify this question. > > Otherwise, in my question to the list, I thought I had done the steps > out of order :/ > But I just realized on https://emailselfdefense.fsf.org/en/ that I > followed the steps correctly. > > > > > > > Could the inversion of these 2 steps have had an impact on the fact > > > that 'https://keys.openpgp.org/'?does not find my e-mail address? > > > On the other hand, it does find my > > > E67C43563F94C4756557A483B2A8FF57185B13B0 key > > > > > > I'm wondering at this point if there is an error I could fix or if > > > it's > > > better to revoke/delete this current key-pair. > > > > Maybe you want to read the GNU Privacy Handbook > > https://gnupg.org/gph/en/manual.html > > It is not a perfect beginners guide but it may give you a better > > understanding how things are working. > > > The link looks like precious infos. > > In my bookmarks right now! > > Thank you for your answer. > > Regards > > > > > -- > Hubert Lombard -- Henning Follmann | hfollmann at itcfollmann.com From sven.schultschik at siemens.com Wed Mar 16 17:22:29 2022 From: sven.schultschik at siemens.com (Schultschik, Sven) Date: Wed, 16 Mar 2022 16:22:29 +0000 Subject: AW: AW: Cancel operation does not return error code In-Reply-To: <87wngva0zd.fsf@wheatstone.g10code.de> References: <2091051.FdYHGDcMvI@daneel> <10300209.2QMzp5bVFr@daneel> <87wngva0zd.fsf@wheatstone.g10code.de> Message-ID: > > I'm using the Cancel methods on ctrl+c but the terminal is anyway messed up. > > Would it be worth a bug report? > > No. The pinentry is background process and there is no portable way to save and restore the screen. Thus your application may want to do something like this after a gpgme operation: > > if ((s = gpgme_get_ctx_flag (ctx, "redraw")) && *s) > fputs ("Screen redraw suggested\n", stdout); > I implemented as suggested. And yes this makes it possible to type again, but the pinentry still running in the background and if you hit enter two times it comes back and the terminal acts weird. See screenshots gpgme_error_t err = gpgme_cancel(_ctx); const char* s; if (( s = gpgme_get_ctx_flag (_ctx, "redraw")) && *s) if (!system("reset")) log(LOG_ERR, "Could not reset terminal. Reset Terminal suggested"); fail_if_err(err); _ctx = gpgme_wait(_ctx, &err, false); fail_if_err(err); gpgme_release(_ctx); There must be a possibility to proper kill the pinentry Regards Sven -------------- next part -------------- A non-text attachment was scrubbed... Name: 2022-03-16 17_18_25-ICEdge - VMware Workstation.png Type: image/png Size: 17384 bytes Desc: 2022-03-16 17_18_25-ICEdge - VMware Workstation.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 2022-03-16 17_19_10-ICEdge - VMware Workstation.png Type: image/png Size: 51436 bytes Desc: 2022-03-16 17_19_10-ICEdge - VMware Workstation.png URL: From contact at hubert-lombard.website Wed Mar 16 21:29:29 2022 From: contact at hubert-lombard.website (Hubert Lombard) Date: Wed, 16 Mar 2022 21:29:29 +0100 Subject: (my) E-mail address not found by 'https://keys.openpgp.org' In-Reply-To: References: <5ee33d90ccf2252b1308294e43f43ef9964a99e8.camel@hubert-lombard.website> <914dbf2b313a6d13dcc7f5e22597be06d471a4de.camel@hubert-lombard.website> Message-ID: <8bc23a28b62718de9a669fd9cdd926556369e340.camel@hubert-lombard.website> Hi Henning, > > Well, that was good advice, however you didn't have to revoke your > key. Your key was not compromized by using a different key server. > > You'll revoke your key when you think something is wrong with > your private key. And it basically is a public notice to > anybody else to not trust that key after a certain date. But > it will not remove the key from anywhere. It's out there for good. Got it! I didn't know... > > > > > > > > > > > > > In fact, while following some instructions for use, I have just tried > > to generate the revocation certificates. > > As English is not my native language, there may have been an > > ambiguity > > in the form of my question. > > I mistakenly used the term "performed", when I simply tried to > > generate > > the certificates, > > just to have them on hand... > > That is common practice. And yes I obviously misunderstood. > Thanks again Henning :) Regards > > Hubert Lombard From contact at hubert-lombard.website Wed Mar 16 19:30:47 2022 From: contact at hubert-lombard.website (Hubert Lombard) Date: Wed, 16 Mar 2022 19:30:47 +0100 Subject: (my) E-mail address not found by 'https://keys.openpgp.org' In-Reply-To: <20220316135149.ioauuk366qiamfqa@rain.local> References: <5ee33d90ccf2252b1308294e43f43ef9964a99e8.camel@hubert-lombard.website> <20220316135149.ioauuk366qiamfqa@rain.local> Message-ID: <8d8ca9d4bdfd8e708e511436f385be60d4ba8ce2.camel@hubert-lombard.website> Hi Michael! Thank you for your answers, I have to learn and verify several things indeed. In particular, checking my email address, I didn't know that :) 'https://gnupg.org/gph/en/manual.html' will surely enlighten me on some points... Thanks again Regards > Hi, > > On Wed, Mar 16, 2022 at 01:13:00PM +0100, Hubert Lombard wrote: > > Could the inversion of these 2 steps have had an impact on the fact > > that 'https://keys.openpgp.org/'?does not find my e-mail address? > > On the other hand, it does find my > > E67C43563F94C4756557A483B2A8FF57185B13B0 key > > Unlike most keyservers, keys.openpgp.org requires you verify your email > address before the key is available by email, but it can be searched by > fingerprint even without that (though it won't contain the email > information, iirc).? Since this sounds similar, it seems to me like you > may not have completed this verification step, or something went wrong > there. > > - Michael -- Hubert Lombard From contact at hubert-lombard.website Wed Mar 16 19:39:35 2022 From: contact at hubert-lombard.website (Hubert Lombard) Date: Wed, 16 Mar 2022 19:39:35 +0100 Subject: (my) E-mail address not found by 'https://keys.openpgp.org' In-Reply-To: References: <5ee33d90ccf2252b1308294e43f43ef9964a99e8.camel@hubert-lombard.website> Message-ID: <914dbf2b313a6d13dcc7f5e22597be06d471a4de.camel@hubert-lombard.website> Hi Henning! > On Wed, Mar 16, 2022 at 01:13:00PM +0100, Hubert Lombard wrote: > > Hello ! > > > > I recently started to get interested in GPG. Last week, during my > > first > > tests, I sent my first key to 'keys.gnupg.net' > > but I understood only yesterday that this server could have been > > compromised since 2019. When I tried to revoke the key permanently, > > it > > was not found. > > So I deleted the key from my computer with Seahorse, and immediately > > after, still with Seahorse, I generated? a new key pair using the > > same > > email address and choosing the key server 'keys.openpgp.org' > > Why? The integrity of your privat key will not be affected by the > keyserver you put your public key on. > Oh, I didn't know, I was advised yesterday on another irc channel (#debian-facile) to change my key server: "They were ('keys.gnupg.net' and others) all flooded with fake keys mid-2019 this is the reason why debian, among others, uses keys.openpgp.org as a keyserver see also CVE-2019-13050 (SKS servers poisoning)" > > > > > When creating this new key pair, instead of going directly to the > > revocation step, I sent my public key. > > After that, I performed the revocation step. > > That again does not make any sense. Why would you create a key pair > just to revoke this immediately? > In fact, while following some instructions for use, I have just tried to generate the revocation certificates. As English is not my native language, there may have been an ambiguity in the form of my question. I mistakenly used the term "performed", when I simply tried to generate the certificates, just to have them on hand... hubert at gnu ~$ gpg --gen-revoke 185B13B0 > .gnupg/openpgp- revocs.d/E67C43563F94C4756557A483B2A8FF57185B13B0.rev sec rsa2048/B2A8FF57185B13B0 2022-03-15 Hubert Lombard Faut-il cr?er un certificat de r?vocation pour cette clef?? (o/N) I have left "N' I was afraid that by choosing 'o', the key would be permanently revoked. I will have to clarify this question. Otherwise, in my question to the list, I thought I had done the steps out of order :/ But I just realized on https://emailselfdefense.fsf.org/en/ that I followed the steps correctly. > > > > Could the inversion of these 2 steps have had an impact on the fact > > that 'https://keys.openpgp.org/'?does not find my e-mail address? > > On the other hand, it does find my > > E67C43563F94C4756557A483B2A8FF57185B13B0 key > > > > I'm wondering at this point if there is an error I could fix or if > > it's > > better to revoke/delete this current key-pair. > > Maybe you want to read the GNU Privacy Handbook > https://gnupg.org/gph/en/manual.html > It is not a perfect beginners guide but it may give you a better > understanding how things are working. > The link looks like precious infos. In my bookmarks right now! Thank you for your answer. Regards > -- Hubert Lombard From wk at gnupg.org Thu Mar 17 10:25:36 2022 From: wk at gnupg.org (Werner Koch) Date: Thu, 17 Mar 2022 10:25:36 +0100 Subject: Change Passphrase in Batch Mode In-Reply-To: (Daniel Kilimnik via Gnupg-users's message of "Wed, 16 Mar 2022 09:26:15 +0100") References: Message-ID: <87y2196icv.fsf@wheatstone.g10code.de> On Wed, 16 Mar 2022 09:26, Daniel Kilimnik said: > mode. With --pinentry-mode loopback --passphrase-fd 0 activated. It asks > for my current passphrase, but then exits with a success. --passphrase-fd works only if a password is request but not if two passwords are quested (the old one and the new one). You need to use the --command-fd thingy and write a state machine for this. Here is a manual example --8<---------------cut here---------------start------------->8--- $ gpg --pinentry-mode loopback --status-fd 2 -v --batch --command-fd 0 --passwd FE894309B6844A3004FE8BF9476CAB1C3623CAA6 [GNUPG:] KEY_CONSIDERED FE894309B6844A3004FE8BF9476CAB1C3623CAA6 0 [GNUPG:] INQUIRE_MAXLEN 100 [GNUPG:] GET_HIDDEN passphrase.enter abc [GNUPG:] GOT_IT [GNUPG:] INQUIRE_MAXLEN 100 [GNUPG:] GET_HIDDEN passphrase.enter def [GNUPG:] GOT_IT [GNUPG:] SUCCESS keyedit.passwd --8<---------------cut here---------------end--------------->8--- 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 kaleb.dk at gmail.com Thu Mar 17 13:40:38 2022 From: kaleb.dk at gmail.com (Daniel Kilimnik) Date: Thu, 17 Mar 2022 13:40:38 +0100 Subject: Change Passphrase in Batch Mode In-Reply-To: <87y2196icv.fsf@wheatstone.g10code.de> References: <87y2196icv.fsf@wheatstone.g10code.de> Message-ID: Thanks, that does work, but is is also possible to set an empty passphrase i.e. remove the passphrase with this method? Best, Daniel Am Do., 17. M?rz 2022 um 10:26 Uhr schrieb Werner Koch : > On Wed, 16 Mar 2022 09:26, Daniel Kilimnik said: > > > mode. With --pinentry-mode loopback --passphrase-fd 0 activated. It asks > > for my current passphrase, but then exits with a success. > > --passphrase-fd works only if a password is request but not if two > passwords are quested (the old one and the new one). You need to use > the --command-fd thingy and write a state machine for this. Here is a > manual example > > --8<---------------cut here---------------start------------->8--- > $ gpg --pinentry-mode loopback --status-fd 2 -v --batch --command-fd 0 > --passwd FE894309B6844A3004FE8BF9476CAB1C3623CAA6 > [GNUPG:] KEY_CONSIDERED FE894309B6844A3004FE8BF9476CAB1C3623CAA6 0 > [GNUPG:] INQUIRE_MAXLEN 100 > [GNUPG:] GET_HIDDEN passphrase.enter > abc > [GNUPG:] GOT_IT > [GNUPG:] INQUIRE_MAXLEN 100 > [GNUPG:] GET_HIDDEN passphrase.enter > def > [GNUPG:] GOT_IT > [GNUPG:] SUCCESS keyedit.passwd > --8<---------------cut here---------------end--------------->8--- > > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Thu Mar 17 14:50:36 2022 From: wk at gnupg.org (Werner Koch) Date: Thu, 17 Mar 2022 14:50:36 +0100 Subject: AW: AW: Cancel operation does not return error code In-Reply-To: (Sven Schultschik's message of "Wed, 16 Mar 2022 16:22:29 +0000") References: <2091051.FdYHGDcMvI@daneel> <10300209.2QMzp5bVFr@daneel> <87wngva0zd.fsf@wheatstone.g10code.de> Message-ID: <87zglo6637.fsf@wheatstone.g10code.de> On Wed, 16 Mar 2022 16:22, Schultschik, Sven said: > There must be a possibility to proper kill the pinentry gpg-agent closes the pinentry or kills it on timeout. You need to properly restore your tty in case the used curses version does not act correctly or the pinentry died. 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 Mar 17 16:33:35 2022 From: wk at gnupg.org (Werner Koch) Date: Thu, 17 Mar 2022 16:33:35 +0100 Subject: (my) E-mail address not found by 'https://keys.openpgp.org' In-Reply-To: <914dbf2b313a6d13dcc7f5e22597be06d471a4de.camel@hubert-lombard.website> (Hubert Lombard's message of "Wed, 16 Mar 2022 19:39:35 +0100") References: <5ee33d90ccf2252b1308294e43f43ef9964a99e8.camel@hubert-lombard.website> <914dbf2b313a6d13dcc7f5e22597be06d471a4de.camel@hubert-lombard.website> Message-ID: <87v8wc61bk.fsf@wheatstone.g10code.de> Hi! Just for the records > Oh, I didn't know, I was advised yesterday on another irc channel > (#debian-facile) to change my key server: > > "They were ('keys.gnupg.net' and others) all flooded with fake keys > mid-2019 You can't talk about fake key on a keyserver. That is not the task of a keyserver. A keyserver is just a place to store arbitrary keys. The user needs to make sure whether the key is authentic. The actual DoS problem was that the keyservers also carry key signatures. This led to some very large keys (due to arbitrary added key signature) which took very long for gpg to check. This has meanwhile been fixed by gpg by not importing 3rd party key-signatures anymore. There is actual no way in an system, which on purpose is distributed and non-controlled - to inhibit the storage of keys. The keyserver protocol unfortunately has had no specification on how to inhibit the addition of arbitrary key signatures for example by allowing uploads of new key-signatures only by data signed by the actual key. keys.openpgp.net OTOH does away with the concept of a decentralized system and tries again (like PGP.com and keyserver.org 20 years ago) to establish a single source for keys. That is not for what PGP and thus GnuPG where invented. Federation is okay for keyserver, but a central authority is not desirable. 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 j_speagle at icloud.com Mon Mar 21 12:04:26 2022 From: j_speagle at icloud.com (Justin Speagle) Date: Mon, 21 Mar 2022 07:04:26 -0400 Subject: No subject Message-ID: I need help Sent from my iPhone From bruderb at cation.de Mon Mar 21 16:08:29 2022 From: bruderb at cation.de (BruderB) Date: Mon, 21 Mar 2022 16:08:29 +0100 Subject: No subject In-Reply-To: References: Message-ID: <7fb9f46d-f31b-a8ba-461f-5d1fae04e5be@cation.de> Yes, you do. Am 21.03.22 um 12:04 schrieb Justin Speagle via Gnupg-users: > > I need help > Sent from my iPhone From mwood at iupui.edu Mon Mar 21 17:39:44 2022 From: mwood at iupui.edu (Mark H. Wood) Date: Mon, 21 Mar 2022 12:39:44 -0400 Subject: No subject In-Reply-To: <7fb9f46d-f31b-a8ba-461f-5d1fae04e5be@cation.de> References: <7fb9f46d-f31b-a8ba-461f-5d1fae04e5be@cation.de> Message-ID: On Mon, Mar 21, 2022 at 04:08:29PM +0100, BruderB wrote: > Yes, you do. > > Am 21.03.22 um 12:04 schrieb Justin Speagle via Gnupg-users: > > > > I need help > > Sent from my iPhone > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > https://lists.gnupg.org/mailman/listinfo/gnupg-users http://catb.org/~esr/faqs/smart-questions.html -- Mark H. Wood Lead Technology Analyst University Library Indiana University - Purdue University Indianapolis 755 W. Michigan Street Indianapolis, IN 46202 317-274-0749 www.ulib.iupui.edu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From yaowenbin1 at huawei.com Tue Mar 22 10:09:46 2022 From: yaowenbin1 at huawei.com (yaowenbin) Date: Tue, 22 Mar 2022 17:09:46 +0800 Subject: [PATCH] Add npth socket test case Message-ID: * tests/t-socket.c: New Signed-off-by: yaowenbin1 --- tests/t-socket.c | 270 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 270 insertions(+) create mode 100644 tests/t-socket.c diff --git a/tests/t-socket.c b/tests/t-socket.c new file mode 100644 index 0000000..8e980d4 --- /dev/null +++ b/tests/t-socket.c @@ -0,0 +1,270 @@ +/* t-socket.c + * + * This file is free software; as a special exception the author gives + * unlimited permission to copy and/or distribute it, with or without + * modifications, as long as this notice is preserved. + * + * This file is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY, to the extent permitted by law; without even the + * implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + */ + +#include "t-support.h" +#include +#include +#include +#include +#include +#include +#include + +#define NAME "Socket" +#define DATA "Test npth socket interfaces. . ." + +static void * +thread_one (void *arg) +{ + int sock, msgsock, rval; + struct sockaddr_un server; + char buf[1024]; + struct timeval tv; + struct timespec ts; + + info_msg ("thread-one started"); + tv.tv_sec = 0; + tv.tv_usec = 100; + ts.tv_sec = 0; + ts.tv_nsec = 1000; + + sock = socket(AF_UNIX, SOCK_STREAM, 0); + if (sock < 0) { + perror("opening stream socket"); + exit(1); + } + server.sun_family = AF_UNIX; + strcpy(server.sun_path, NAME); + if (bind(sock, (struct sockaddr *) &server, sizeof(struct sockaddr_un))) { + perror("binding stream socket"); + exit(1); + } + info_msg("Socket has name %s\n", server.sun_path); + listen(sock, 5); + msgsock = npth_accept(sock, 0, 0); + if (msgsock == -1) + perror("accept"); + else do { + bzero(buf, sizeof(buf)); + if ((rval = npth_read(msgsock, buf, 1024)) < 0) + perror("reading stream message"); + else if (rval == 0) + info_msg("Ending connection\n"); + else + info_msg("-->%s\n", buf); + } while (rval > 0); + + npth_select(0, NULL, NULL, NULL, &tv); + npth_pselect(0, NULL, NULL, NULL, &ts, NULL); + close(msgsock); + close(sock); + unlink(NAME); + info_msg ("thread-one terminated"); + + return (void*)4711; +} + + +static void * +thread_two (void *arg) +{ + + int sock; + struct sockaddr_un server; + char buf[1024]; + + info_msg ("thread-two started"); + sock = socket(AF_UNIX, SOCK_STREAM, 0); + if (sock < 0) { + perror("opening stream socket"); + exit(1); + } + server.sun_family = AF_UNIX; + strcpy(server.sun_path, NAME); + + if (npth_connect(sock, (struct sockaddr *) &server, sizeof(struct sockaddr_un)) < 0) { + close(sock); + perror("connecting stream socket"); + exit(1); + } + if (npth_write(sock, DATA, sizeof(DATA)) < 0) + perror("writing on stream socket"); + close(sock); + + info_msg ("thread-two terminated"); + + return (void*)4722; +} + +static void * +thread_three (void *arg) +{ + int sock, msgsock, rval; + struct sockaddr_un server; + char buf[1024]; + struct msghdr msg; + struct iovec io; + + msg.msg_name = NULL; + io.iov_base = buf; + io.iov_len = 1024; + msg.msg_iov = &io; + msg.msg_iovlen = 1; + + info_msg ("thread-three started"); + + sock = socket(AF_UNIX, SOCK_STREAM, 0); + if (sock < 0) { + perror("opening stream socket"); + exit(1); + } + server.sun_family = AF_UNIX; + strcpy(server.sun_path, NAME); + if (bind(sock, (struct sockaddr *) &server, sizeof(struct sockaddr_un))) { + perror("binding stream socket"); + exit(1); + } + info_msg("Socket has name %s\n", server.sun_path); + listen(sock, 5); + msgsock = npth_accept(sock, 0, 0); + if (msgsock == -1) + perror("accept"); + else { + bzero(buf, sizeof(buf)); + ssize_t recv_size = npth_recvmsg(msgsock, &msg, 0); + char * temp = msg.msg_iov[0].iov_base; + temp[recv_size] = '\0'; + info_msg("get message:%s", temp); + }; + + close(msgsock); + close(sock); + unlink(NAME); + info_msg ("thread-three terminated"); + + return (void*)4711; +} + + +static void * +thread_four (void *arg) +{ + + int sock; + struct sockaddr_un server; + char buf[1024] = "test sendmsg and recvmsg\n"; + struct msghdr msg; + struct iovec io; + + msg.msg_name = NULL; + io.iov_base = buf; + io.iov_len = sizeof(buf); + msg.msg_iov = &io; + msg.msg_iovlen = 1; + + info_msg ("thread-four started"); + sock = socket(AF_UNIX, SOCK_STREAM, 0); + if (sock < 0) { + perror("opening stream socket"); + exit(1); + } + server.sun_family = AF_UNIX; + strcpy(server.sun_path, NAME); + + if (npth_connect(sock, (struct sockaddr *) &server, sizeof(struct sockaddr_un)) < 0) { + close(sock); + perror("connecting stream socket"); + exit(1); + } + npth_sendmsg(sock, &msg, 0); + close(sock); + + info_msg ("thread-four terminated"); + + return (void*)4722; +} + +int +main (int argc, char *argv[]) +{ + int rc; + npth_attr_t tattr; + int state; + npth_t tid1, tid2; + npth_t tid3, tid4; + void *retval; + + if (argc >= 2 && !strcmp (argv[1], "--verbose")) + opt_verbose = 1; + + rc = npth_init (); + fail_if_err (rc); + + rc = npth_attr_init (&tattr); + fail_if_err (rc); + rc = npth_attr_getdetachstate (&tattr, &state); + fail_if_err (rc); + if ( state != NPTH_CREATE_JOINABLE ) + fail_msg ("new tattr is not joinable"); + + info_msg ("creating thread-one"); + rc = npth_create (&tid1, &tattr, thread_one, NULL); + fail_if_err (rc); + npth_setname_np (tid1, "thread-one"); + + npth_usleep(100); + + info_msg ("creating thread-two"); + rc = npth_create (&tid2, &tattr, thread_two, NULL); + fail_if_err (rc); + npth_setname_np (tid2, "thread-two"); + + rc = npth_attr_destroy (&tattr); + fail_if_err (rc); + + info_msg ("waiting for thread-one to terminate"); + rc = npth_join (tid1, &retval); + fail_if_err (rc); + if (retval != (void*)4711) + fail_msg ("thread-one returned an unexpected value"); + + info_msg ("waiting for thread-two to terminate"); + rc = npth_join (tid2, &retval); + fail_if_err (rc); + if (retval != (void*)4722) + fail_msg ("thread-two returned an unexpected value"); + + info_msg ("creating thread-three"); + rc = npth_create (&tid3, NULL, thread_three, NULL); + fail_if_err (rc); + npth_setname_np (tid3, "thread-three"); + + npth_usleep(100); + + info_msg ("creating thread-four"); + rc = npth_create (&tid4, NULL, thread_four, NULL); + fail_if_err (rc); + npth_setname_np (tid4, "thread-two"); + + info_msg ("waiting for thread-three to terminate"); + rc = npth_join (tid3, &retval); + fail_if_err (rc); + if (retval != (void*)4711) + fail_msg ("thread-three returned an unexpected value"); + + info_msg ("waiting for thread-four to terminate"); + rc = npth_join (tid4, &retval); + fail_if_err (rc); + if (retval != (void*)4722) + fail_msg ("thread-four returned an unexpected value"); + + return 0; +} -- 2.27.0 From wk at gnupg.org Mon Mar 28 16:40:13 2022 From: wk at gnupg.org (Werner Koch) Date: Mon, 28 Mar 2022 16:40:13 +0200 Subject: [Announce] Libgcrypt 1.10.1 released Message-ID: <87czi6w376.fsf@wheatstone.g10code.de> Hello! We are pleased to announce the availability of Libgcrypt version 1.10.1. This release starts a new stable branch of Libgcrypt with full API and ABI compatibility to the 1.9 series. Over the last year Jussi Kivilinna put again a lot of work into speeding up the algorithms for the most commonly used CPUs. See below for a list of improvements and new features in 1.10. Libgcrypt is a general purpose library of cryptographic building blocks. It is originally based on code used by GnuPG. It does not provide any implementation of OpenPGP or other protocols. Thorough understanding of applied cryptography is required to use Libgcrypt. Noteworthy changes in Libgcrypt 1.10.0 and 1.10.1 ================================================= * New and extended interfaces: - New control codes to check for FIPS 140-3 approved algorithms. - New control code to switch into non-FIPS mode. - New cipher modes SIV and GCM-SIV as specified by RFC-5297. - Extended cipher mode AESWRAP with padding as specified by RFC-5649. [T5752] - New set of KDF functions. - New KDF modes Argon2 and Balloon. - New functions for combining hashing and signing/verification. [T4894] * Performance: - Improved support for PowerPC architectures. - Improved ECC performance on zSeries/s390x by using accelerated scalar multiplication. - Many more assembler performance improvements for several architectures. * Bug fixes: - Fix Elgamal encryption for other implementations. [R5328,CVE-2021-40528] - Fix alignment problem on macOS. [T5440] - Check the input length of the point in ECDH. [T5423] - Fix an abort in gcry_pk_get_param for "Curve25519". [T5490] - Fix minor memory leaks in FIPS mode. - Build fixes for MUSL libc. [rCffaef0be61] * Other features: - The control code GCRYCTL_SET_ENFORCED_FIPS_FLAG is ignored because it is useless with the FIPS 140-3 related changes. - Update of the jitter entropy RNG code. [T5523] - Simplification of the entropy gatherer when using the getentropy system call. - More portable integrity check in FIPS mode. [rC9fa4c8946a,T5835] - Add X9.62 OIDs to sha256 and sha512 modules. [rC52fd2305ba] Note that 1.10.0 was already released on 2022-02-01 without a public announcement to allow for some extra test time. For a list of links to commits and bug numbers see the release info at https://dev.gnupg.org/T5691 and https://dev.gnupg.org/T5810 Download ======== Source code is hosted at the GnuPG FTP server and its mirrors as listed at https://gnupg.org/download/mirrors.html. On the primary server the source tarball and its digital signature are: https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.10.1.tar.bz2 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.10.1.tar.bz2.sig or gzip compressed: https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.10.1.tar.gz https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.10.1.tar.gz.sig In order to check that the version of Libgcrypt you downloaded is an original and unmodified file please follow the instructions found at https://gnupg.org/download/integrity_check.html. In short, you may use one of the following methods: - Check the supplied OpenPGP signature. For example to check the signature of the file libgcrypt-1.10.1.tar.bz2 you would use this command: gpg --verify libgcrypt-1.10.1.tar.bz2.sig libgcrypt-1.10.1.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See the end of this mail for information on the signing keys. - If you are not able to use an existing version of GnuPG, you have to verify the SHA-1 checksum. On Unix systems the command to do this is either "sha1sum" or "shasum". Assuming you downloaded the file libgcrypt-1.10.1.tar.bz2, you run the command like this: sha1sum libgcrypt-1.10.1.tar.bz2 and check that the output matches the first line from the this list: de2cc32e7538efa376de7bf5d3eafa85626fb95f libgcrypt-1.10.1.tar.bz2 9db3ef0ec74bd2915fa7ca6f32ea9ba7e013e1a1 libgcrypt-1.10.1.tar.gz You should also verify that the checksums above are authentic by matching them with copies of this announcement. Those copies can be found at other mailing lists, web sites, and search engines. Copying ======= Libgcrypt is distributed under the terms of the GNU Lesser General Public License (LGPLv2.1+). The helper programs as well as the documentation are distributed under the terms of the GNU General Public License (GPLv2+). The file LICENSES has notices about contributions that require that these additional notices are distributed. Support ======= For help on developing with Libgcrypt you should read the included manual and if needed ask on the gcrypt-devel mailing list. In case of problems specific to this release please first check https://dev.gnupg.org/T5810 for updated information. Please also consult the archive of the gcrypt-devel 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 gcrypt-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 Libgcrypt hackers p.s. This is an announcement only mailing list. Please send replies only to the gnupg-users'at'gnupg.org mailing list. 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 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. -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- 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 franciskp19 at gmail.com Wed Mar 30 07:21:00 2022 From: franciskp19 at gmail.com (Francis Kp) Date: Wed, 30 Mar 2022 10:51:00 +0530 Subject: Help with "config.h file not found error" on Gnupg version 1.4.13 Message-ID: Hi all, As in exercise in understanding Cybersecurity in IoT better, I'm trying to implement the flush-reload attack from the paper "FLUSH+RELOAD: A High Resolution, Low Noise, L3 Cache Side-Channel Attack". The crux of the attack is to extract the private key of RSA encryption used in Gnupg. One of the steps to initiate the attack is to find certain memory addresses to feed to a spy function. For that I'm trying to open a C executable in Gnu debugger(gdb). The program is part of the Gnupg 1.4.13 version. My aim is to get the memory address of a particular function by setting breakpoint at that line. While compiling the c program using **gcc -g mpi-pow.c**, (And yes I tried without the -g option) I'm getting this error: *mpi-pow.c:28:10: fatal error: config.h: No such file or directory 28 | #include | ^~~~~~~~~~ compilation terminated* These were the exact steps I did:--> 1. - Extracted the Gnupg source code using tar xjvf gnupg-1.4.13.tar.bz2 2. - cd gnupg-1.4.13/ 3. - ./configure 4. - sudo make 5. - sudo make install The source code of Gnupg 1.4.13 is at Link_to_code The original paper is here Link_to_paper A quick google search told me that "In computing, configuration files (commonly known simply as config files) are files used to configure the parameters and initial settings for some computer programs". *And as far as I understood, the config file is made when the "./configure" command is run and in this case, it simply means there is no config.h file in the current directory*. There were no errors during the compilation of Gnupg. I'm using the Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz processor. I tried it on WSL and on Ubuntu 20.04 installed on dual boot. 1. What might be the reason ? 2. How can I rectify this error ? Any help would be highly appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Wed Mar 30 17:48:59 2022 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 30 Mar 2022 11:48:59 -0400 Subject: Help with "config.h file not found error" on Gnupg version 1.4.13 In-Reply-To: References: Message-ID: <13314e18-21a0-9531-e539-2ebc9f0174e3@sixdemonbag.org> You will have much better luck if you send only plain-text emails to this list. Some of the people you'd really like to see your email refuse to read HTML email, on the grounds that it's a security risk. I've quoted your entire message below as plaintext to help you reach these people. To resolve your problem I'd suggest finding where the Automake-created config.h header file lies, and including that directory in your GCC invocation by using the -I flag. Hope this helps. :) On 3/30/2022 1:21 AM, Francis Kp via Gnupg-users wrote: > Hi all, > As in exercise in understanding Cybersecurity in IoT better, I'm trying > to implement the flush-reload attack from the paper "FLUSH+RELOAD: A > High Resolution, Low Noise, L3 Cache Side-Channel Attack". The crux of > the attack is to extract the private key of RSA encryption used in > Gnupg. One of the steps to initiate the attack is to find certain memory > addresses to feed to a spy function. For that I'm trying to open a C > executable in Gnu debugger(gdb). The program is part of the Gnupg 1.4.13 > version. My aim is to get the memory address of a particular function by > setting breakpoint at that line. While compiling the c program using > **gcc -g mpi-pow.c**, (And yes I tried without the -g option) I'm > getting this error: > > > > *mpi-pow.c:28:10: fatal error: config.h: No such file or directory > ? ? ? ?28 | #include > ? ? ? ? ? | ? ? ? ? ?^~~~~~~~~~ > ? ? compilation terminated* > > > > These were the exact steps I did:--> > > 1. ?- Extracted the Gnupg source code using tar xjvf gnupg-1.4.13.tar.bz2 > 2. ?- cd gnupg-1.4.13/ > 3. ?- ./configure > 4. ?- sudo make > 5. ?- sudo make install > > > The source code of Gnupg 1.4.13 is at Link_to_code > > The original paper is here Link_to_paper > > > A quick google search told me that "In computing, configuration files > (commonly known simply as config files) are files used to configure the > parameters and initial settings for some computer programs". /And as far > as I understood, the config file is made when the "./configure" command > is run and in this case, it simply means there is no config.h file in > the current directory/.?There were no errors during the compilation of > Gnupg. > > I'm using the Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz processor. > I tried it on WSL and on Ubuntu 20.04 installed on dual boot. > > ?1. What might be the reason ? > ?2. How can I rectify this error ? > > Any help would be highly appreciated. > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > https://lists.gnupg.org/mailman/listinfo/gnupg-users