From dashohoxha at gmail.com Fri Feb 1 00:36:15 2019 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Fri, 1 Feb 2019 00:36:15 +0100 Subject: What should '--local-user' mean when multiple secret keys match? In-Reply-To: <87imy4327t.fsf@fifthhorseman.net> References: <875zu84bog.fsf@fifthhorseman.net> <87imy4327t.fsf@fifthhorseman.net> Message-ID: On Thu, Jan 31, 2019 at 11:33 PM Daniel Kahn Gillmor wrote: > > > From my experience (and meditation) I have arrived in the conclusion > > that usually it is better to keep only one secret key per context (or > > GNUPGHOME), and to change the context whenever you need to use a > > different key. > > This is a super interesting observation. Do other people have the same > experience? it seems to me that keeping the public keyrings in sync > alone would be a fair amount of hassle. Can you describe any other > scenarios where that might improve the user experience? I want to > really focus on making it easy for even a non-technical user to do > sensible things easily, in particular here: a planned, phased-in, > non-sudden key transition. Can you give other examples of where the > separated secret keyring is concretely useful and usable? > Suppose that one wants to use a secret key to communicate with colleagues, another one to communicate with friends, and another one to communicate with his family. If he keeps all the secret keys and all the public keys on the same addressbook (or keyring), it is possible that sometimes he may make mistakes and use the wrong key for decryption and signatures. If they are kept on separate contexts (or separate keyrings, or addressbooks) the possibility of mistakes may be smaller. In general, if you need to have more than one secret key (for any reason), it seems to me more complicated, confusing and error-prone to keep them in the same keyring than to keep them on separate keyrings (contexts). Dashamir -------------- next part -------------- An HTML attachment was scrubbed... URL: From bernhard at intevation.de Fri Feb 1 13:29:39 2019 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 1 Feb 2019 13:29:39 +0100 Subject: GnuPG 2.2 on elder Debian & Ubuntu distros In-Reply-To: <201901100929.42086.bernhard@intevation.de> References: <201901100929.42086.bernhard@intevation.de> Message-ID: <201902011329.43580.bernhard@intevation.de> Am Donnerstag 10 Januar 2019 09:29:37 schrieb Bernhard Reiter: > Am Freitag 27 Oktober 2017 18:24:45 schrieb Phil Pennock: > > Thus at I have packages > > thanks again for those packages, I'll still use them for test sometimes! Note that since August there are current gnupg 2.2 packages in Debian Stretch backports, see https://tracker.debian.org/pkg/gnupg2 Still missing Jessie and Ubuntu https://packages.ubuntu.com/search?keywords=gnupg&searchon=names&suite=all§ion=all but at least Ubuntu has 2.2.4 in 18.04LTS. 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: 488 bytes Desc: This is a digitally signed message part. URL: From peter at digitalbrains.com Fri Feb 1 15:42:01 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Fri, 1 Feb 2019 15:42:01 +0100 Subject: GnuPG 2.2 on elder Debian & Ubuntu distros In-Reply-To: <201902011329.43580.bernhard@intevation.de> References: <201901100929.42086.bernhard@intevation.de> <201902011329.43580.bernhard@intevation.de> Message-ID: On 01/02/2019 13:29, Bernhard Reiter wrote: > Still missing Jessie and Ubuntu I don't know about Ubuntu, but it can't go into jessie-backports because backports can't go ahead of what the /next/ stable version has. (That obviously doesn't mean somebody couldn't provide packages for jessie, just that it won't go into the official jessie-backports). > but at least Ubuntu has 2.2.4 in 18.04LTS. Yes, it's nice that the LTS has 2.2. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From d at d.sb Mon Feb 4 05:35:26 2019 From: d at d.sb (Daniel Lo Nigro) Date: Sun, 3 Feb 2019 20:35:26 -0800 Subject: Debug symbols for libgpgme-11.dll Message-ID: Hi! Is there somewhere I can get a debug build of the Windows version of the GPGME library (libgpgme-11.dll), or a PDB file containing the debug symbols? I'm hitting some access violations while using the library in my code, and would like to do some debugging Thanks! -- Regards, Daniel Lo Nigro https://d.sb/ | Twitter | Facebook -------------- next part -------------- An HTML attachment was scrubbed... URL: From aheinecke at gnupg.org Mon Feb 4 12:26:40 2019 From: aheinecke at gnupg.org (Andre Heinecke) Date: Mon, 04 Feb 2019 12:26:40 +0100 Subject: Debug symbols for libgpgme-11.dll In-Reply-To: References: Message-ID: <2552751.Zi73ILQ52C@esus> Hi, On Sunday, February 3, 2019 8:35:26 PM CET Daniel Lo Nigro wrote: > Is there somewhere I can get a debug build of the Windows version of the > GPGME library (libgpgme-11.dll), or a PDB file containing the debug > symbols? I'm hitting some access violations while using the library in my > code, and would like to do some debugging Sorry, currently there are no MSVC compatible debug symbols available. We compile with GCC and the debug info is incompatible. My suggestion is to run your code with an environment variable set like: set GPGME_DEBUG=9;c:\tmp\gpgme.log (assuming c:\tmp exists and is writable) this will show you a lot of what is going on inside GPGME. Access violations sound like maybe a NULL pointer variable where there should not be one or an unterminated string. (Or random / uninitialized pointers passed as we mostly check for NULL pointers). Best Regards, Andre -- GnuPG e.V., Rochusstr. 44, D-40479 D?sseldorf. VR 11482 D?sseldorf Vorstand: W.Koch, M.Gollowitzer, A.Heinecke. Mail: board at gnupg.org Finanzamt D-Altstadt, St-Nr: 103/5923/1779. Tel: +49-2104-4938799 -------------- 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 d at d.sb Mon Feb 4 18:28:55 2019 From: d at d.sb (Daniel Lo Nigro) Date: Mon, 4 Feb 2019 09:28:55 -0800 Subject: Debug symbols for libgpgme-11.dll In-Reply-To: <2552751.Zi73ILQ52C@esus> References: <2552751.Zi73ILQ52C@esus> Message-ID: In that case, is there a pre-compiled version with GDB debug symbols available? I should be able to attach GDB instead of Visual Studio and at least get a stack trace of where the error is being thrown in the native library. Or would I need to compile it myself with optimizations disabled? Sent from my phone. On Mon, Feb 4, 2019, 3:26 AM Andre Heinecke Hi, > > On Sunday, February 3, 2019 8:35:26 PM CET Daniel Lo Nigro wrote: > > Is there somewhere I can get a debug build of the Windows version of the > > GPGME library (libgpgme-11.dll), or a PDB file containing the debug > > symbols? I'm hitting some access violations while using the library in my > > code, and would like to do some debugging > > Sorry, currently there are no MSVC compatible debug symbols available. We > compile with GCC and the debug info is incompatible. > > My suggestion is to run your code with an environment variable set like: > > set GPGME_DEBUG=9;c:\tmp\gpgme.log > > (assuming c:\tmp exists and is writable) this will show you a lot of what > is > going on inside GPGME. > > > Access violations sound like maybe a NULL pointer variable where there > should > not be one or an unterminated string. (Or random / uninitialized pointers > passed as we mostly check for NULL pointers). > > > Best Regards, > Andre > > -- > GnuPG e.V., Rochusstr. 44, D-40479 D?sseldorf. VR 11482 D?sseldorf > Vorstand: W.Koch, M.Gollowitzer, A.Heinecke. Mail: board at gnupg.org > Finanzamt D-Altstadt, St-Nr: 103/5923/1779. Tel: +49-2104-4938799 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Tue Feb 5 00:55:44 2019 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 04 Feb 2019 17:55:44 -0600 Subject: GnuPG 2.2 on elder Debian & Ubuntu distros In-Reply-To: References: <201901100929.42086.bernhard@intevation.de> <201902011329.43580.bernhard@intevation.de> Message-ID: <87o97r1533.fsf@fifthhorseman.net> On Fri 2019-02-01 15:42:01 +0100, Peter Lebbing wrote: > On 01/02/2019 13:29, Bernhard Reiter wrote: > >> Still missing Jessie and Ubuntu > > I don't know about Ubuntu, but it can't go into jessie-backports because > backports can't go ahead of what the /next/ stable version has. > > (That obviously doesn't mean somebody couldn't provide packages for > jessie, just that it won't go into the official jessie-backports). please see this depressing thread on the debian-lts mailing list about the unlikelihood of getting gnupg itself fixed in jessie: https://lists.debian.org/debian-lts/2019/01/msg00050.html --dkg From aheinecke at gnupg.org Tue Feb 5 11:40:51 2019 From: aheinecke at gnupg.org (Andre Heinecke) Date: Tue, 05 Feb 2019 11:40:51 +0100 Subject: Debug symbols for libgpgme-11.dll In-Reply-To: References: <2552751.Zi73ILQ52C@esus> Message-ID: <2473823.608G7juIiR@esus> Hi, On Monday, February 4, 2019 9:28:55 AM CET Daniel Lo Nigro wrote: > In that case, is there a pre-compiled version with GDB debug symbols > available? I should be able to attach GDB instead of Visual Studio and at > least get a stack trace of where the error is being thrown in the native > library. I would not be so sure, I had bad experiences using GDB in the past on Windows. But you can of course try. Our code is compiled with gcc / mingw from debian stretch. I've uploaded a dll of 1.12.1-beta43 (the version in Gpg4win-3.1.5) with debugsyms (as created by the Gpg4win buildsystem) at: https://heinecke.or.at/ div/libgpgme-11.dll > Or would I need to compile it myself with optimizations disabled? Might be better because then you could also add debug output in the codepath where it is crashing for you. Regards, Andre -- GnuPG e.V., Rochusstr. 44, D-40479 D?sseldorf. VR 11482 D?sseldorf Vorstand: W.Koch, M.Gollowitzer, A.Heinecke. Mail: board at gnupg.org Finanzamt D-Altstadt, St-Nr: 103/5923/1779. Tel: +49-2104-4938799 -------------- 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 d at d.sb Tue Feb 5 19:14:51 2019 From: d at d.sb (Daniel Lo Nigro) Date: Tue, 5 Feb 2019 10:14:51 -0800 Subject: Debug symbols for libgpgme-11.dll In-Reply-To: <2473823.608G7juIiR@esus> References: <2552751.Zi73ILQ52C@esus> <2473823.608G7juIiR@esus> Message-ID: Hey Andre, thanks for your reply. I also managed to compile my own version, however both my build and your build seem to be missing the debug symbols for libgpgme itself. I was trying to use a tool called "cv2pdb" ( https://github.com/rainers/cv2pdb) to convert the debug symbols into a PDB file that Visual Studio can use, however it didn't work properly, and its author said that the library is missing the symbols: There is only debug information for the mingw runtime in the original DLL. > You can check by dumping the output of `objdump.exe -W > libgpgme-11-original.dll` and searching for `DW_TAG_compile_unit`. > > I guess something went wrong when building a debug version of that DLL. > See https://github.com/rainers/cv2pdb/issues/50 Is there some build step that is unintentionally stripping out symbols from the object files before linking, or something like that? I don't write any C or C++ so I'm unfamiliar with the build processes. -- Regards, Daniel Lo Nigro https://d.sb/ | Twitter | Facebook On Tue, Feb 5, 2019 at 2:40 AM Andre Heinecke wrote: > Hi, > > On Monday, February 4, 2019 9:28:55 AM CET Daniel Lo Nigro wrote: > > In that case, is there a pre-compiled version with GDB debug symbols > > available? I should be able to attach GDB instead of Visual Studio and at > > least get a stack trace of where the error is being thrown in the native > > library. > > I would not be so sure, I had bad experiences using GDB in the past on > Windows. But you can of course try. Our code is compiled with gcc / mingw > from > debian stretch. > > I've uploaded a dll of 1.12.1-beta43 (the version in Gpg4win-3.1.5) with > debugsyms (as created by the Gpg4win buildsystem) at: > https://heinecke.or.at/ > div/libgpgme-11.dll > > > Or would I need to compile it myself with optimizations disabled? > > Might be better because then you could also add debug output in the > codepath > where it is crashing for you. > > Regards, > Andre > > -- > GnuPG e.V., Rochusstr. 44, D-40479 D?sseldorf. VR 11482 D?sseldorf > Vorstand: W.Koch, M.Gollowitzer, A.Heinecke. Mail: board at gnupg.org > Finanzamt D-Altstadt, St-Nr: 103/5923/1779. Tel: +49-2104-4938799 -------------- next part -------------- An HTML attachment was scrubbed... URL: From d at d.sb Tue Feb 5 19:21:45 2019 From: d at d.sb (Daniel Lo Nigro) Date: Tue, 5 Feb 2019 10:21:45 -0800 Subject: Access violation using gpgme Message-ID: I'm trying to track down an access violation I'm encountering while using GPGME to encrypt and decrypt data from within a C# app. This is the error I'm hitting: "Exception thrown at 0x0057E018 in dotnet.exe: 0xC0000005: Access violation executing location 0x0057E018". Unfortunately I have not been successful in getting debug symbols working in neither gdb on Windows nor Visual Studio, so I haven't been able to look at a native stack trace to work out where it's coming from :( I'm using gpgme_set_pinentry_mode to set the pinentry mode to "loopback", and the access violation is being encountered after my pinentry callback returns. It works fine if I don't use loopback, and instead use the system's pinentry mechanism. Windows 10 version 1809 gpg version 2.2.11 gpgme 1.12.1 I can post the full code if needed, but basically it's a modified version of the PgpEncryptDecrypt sample from gpgme-sharp: https://github.com/Daniel15/gpgme-sharp/blob/master/Examples/PgpEncryptDecrypt/Program.cs Log from when I call gpgme_op_encrypt until the app crashes: https://gist.github.com/Daniel15/925ed7346933e95c47830fae635c6b1c Log for the entire session (finds a key, encrypts some data, then tries to decrypt it): https://gist.github.com/Daniel15/59d95a3bbb75a94aa6fd8e419fc21588 Thanks! -- Regards, Daniel Lo Nigro https://d.sb/ | Twitter | Facebook -------------- next part -------------- An HTML attachment was scrubbed... URL: From aheinecke at gnupg.org Tue Feb 5 19:32:31 2019 From: aheinecke at gnupg.org (Andre Heinecke) Date: Tue, 05 Feb 2019 18:32:31 +0000 Subject: Access violation using gpgme In-Reply-To: References: Message-ID: <1827200.Ck3mivub6Y@esus> Hi, On Tuesday, February 5, 2019 6:21:45 PM GMT Daniel Lo Nigro wrote: > I'm using gpgme_set_pinentry_mode to set the pinentry mode to "loopback", > and the access violation is being encountered after my pinentry callback > returns. It works fine if I don't use loopback, and instead use the > system's pinentry mechanism. This sounds like your passphrase callback returns invalid data. I would have to look how the PassphraseResult is mapped in the C# bindings but from the C API: The user must write the passphrase, followed by a newline character, to the file descriptor @var{fd}. The function @code{gpgme_io_writen} should be used for the write operation. Note that if the user returns 0 to indicate success, the user must at least write a newline character before returning from the callback. I do not think that you need to post your full code, but I would be interested in seeing your Passphrase callback. (Sorry If I'm the only one answering here but in the GnuPG Team I'm the Guy for "all things windows" ;-) ) Regards, Andre -- GnuPG e.V., Rochusstr. 44, D-40479 D?sseldorf. VR 11482 D?sseldorf Vorstand: W.Koch, M.Gollowitzer, A.Heinecke. Mail: board at gnupg.org Finanzamt D-Altstadt, St-Nr: 103/5923/1779. Tel: +49-2104-4938799 -------------- 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 d at d.sb Tue Feb 5 19:59:48 2019 From: d at d.sb (Daniel Lo Nigro) Date: Tue, 5 Feb 2019 10:59:48 -0800 Subject: Access violation using gpgme In-Reply-To: <1827200.Ck3mivub6Y@esus> References: <1827200.Ck3mivub6Y@esus> Message-ID: The code was using gpgme_io_write to write the passphrase followed by a null byte: https://github.com/wget/gpgme-sharp/blob/master/gpgme-sharp/Context.cs#L353-L354. I changed it to gpgme_io_writen and newline. That code was written by someone else way back in 2013 so I wonder if it's been broken this entire time. Here's the changes I've made so far: https://github.com/wget/gpgme-sharp/compare/master...Daniel15:pinentry Now I'm getting closer, but there's still some odd behaviour. The first time I run my test app, I get an access violation. However, it does spawn gpg-agent correctly, and the second time I run it, it works fine! I guess gpg-agent is properly receiving/caching the passphrase. -- Regards, Daniel Lo Nigro https://d.sb/ | Twitter | Facebook On Tue, Feb 5, 2019 at 10:32 AM Andre Heinecke wrote: > Hi, > > On Tuesday, February 5, 2019 6:21:45 PM GMT Daniel Lo Nigro wrote: > > I'm using gpgme_set_pinentry_mode to set the pinentry mode to "loopback", > > and the access violation is being encountered after my pinentry callback > > returns. It works fine if I don't use loopback, and instead use the > > system's pinentry mechanism. > > This sounds like your passphrase callback returns invalid data. I would > have > to look how the PassphraseResult is mapped in the C# bindings but from the > C > API: > > The user must write the passphrase, followed by a newline character, > to the file descriptor @var{fd}. The function @code{gpgme_io_writen} > should be used for the write operation. Note that if the user returns > 0 to indicate success, the user must at least write a newline > character before returning from the callback. > > > I do not think that you need to post your full code, but I would be > interested > in seeing your Passphrase callback. > (Sorry If I'm the only one answering here but in the GnuPG Team I'm the > Guy > for "all things windows" ;-) ) > > > Regards, > Andre > > -- > GnuPG e.V., Rochusstr. 44, D-40479 D?sseldorf. VR 11482 D?sseldorf > Vorstand: W.Koch, M.Gollowitzer, A.Heinecke. Mail: board at gnupg.org > Finanzamt D-Altstadt, St-Nr: 103/5923/1779. Tel: +49-2104-4938799 -------------- next part -------------- An HTML attachment was scrubbed... URL: From d at d.sb Wed Feb 6 08:04:19 2019 From: d at d.sb (Daniel Lo Nigro) Date: Tue, 5 Feb 2019 23:04:19 -0800 Subject: Debug symbols for libgpgme-11.dll In-Reply-To: References: <2552751.Zi73ILQ52C@esus> <2473823.608G7juIiR@esus> Message-ID: I worked this out. Even though I passed CFLAGS and CXXFLAGS to the ./autogen.sh or ./configure call in the root directory, it seems like the gpg4win build process didn't pass the flags to the package builds. I manually modified src/playground/build/gpgme-1.12.1-beta43-build/src/Makefile and changed these flags: CFLAGS: Added -gdwarf -O0 CXXFLAGS: Changed -O2 to -gdwarf -O0 Then I re-ran make, and ran the resulting .dll through cv2pdb. Now the debug symbols appear to be working in Visual Studio, although I haven't had time to actually try and debug an issue yet. https://d.sb/2019/02/devenv_05-23.01.28.png -- Regards, Daniel Lo Nigro https://d.sb/ | Twitter | Facebook On Tue, Feb 5, 2019 at 10:14 AM Daniel Lo Nigro wrote: > Hey Andre, thanks for your reply. I also managed to compile my own > version, however both my build and your build seem to be missing the debug > symbols for libgpgme itself. I was trying to use a tool called "cv2pdb" ( > https://github.com/rainers/cv2pdb) to convert the debug symbols into a > PDB file that Visual Studio can use, however it didn't work properly, and > its author said that the library is missing the symbols: > > There is only debug information for the mingw runtime in the original DLL. >> You can check by dumping the output of `objdump.exe -W >> libgpgme-11-original.dll` and searching for `DW_TAG_compile_unit`. >> >> I guess something went wrong when building a debug version of that DLL. >> > > See https://github.com/rainers/cv2pdb/issues/50 > > Is there some build step that is unintentionally stripping out symbols > from the object files before linking, or something like that? I don't write > any C or C++ so I'm unfamiliar with the build processes. > > -- > Regards, > Daniel Lo Nigro > https://d.sb/ | Twitter | Facebook > > > > On Tue, Feb 5, 2019 at 2:40 AM Andre Heinecke wrote: > >> Hi, >> >> On Monday, February 4, 2019 9:28:55 AM CET Daniel Lo Nigro wrote: >> > In that case, is there a pre-compiled version with GDB debug symbols >> > available? I should be able to attach GDB instead of Visual Studio and >> at >> > least get a stack trace of where the error is being thrown in the native >> > library. >> >> I would not be so sure, I had bad experiences using GDB in the past on >> Windows. But you can of course try. Our code is compiled with gcc / mingw >> from >> debian stretch. >> >> I've uploaded a dll of 1.12.1-beta43 (the version in Gpg4win-3.1.5) with >> debugsyms (as created by the Gpg4win buildsystem) at: >> https://heinecke.or.at/ >> div/libgpgme-11.dll >> >> > Or would I need to compile it myself with optimizations disabled? >> >> Might be better because then you could also add debug output in the >> codepath >> where it is crashing for you. >> >> Regards, >> Andre >> >> -- >> GnuPG e.V., Rochusstr. 44, D-40479 D?sseldorf. VR 11482 D?sseldorf >> Vorstand: W.Koch, M.Gollowitzer, A.Heinecke. Mail: board at gnupg.org >> Finanzamt D-Altstadt, St-Nr: 103/5923/1779. Tel: +49-2104-4938799 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From d at d.sb Fri Feb 8 07:53:53 2019 From: d at d.sb (Daniel Lo Nigro) Date: Thu, 7 Feb 2019 22:53:53 -0800 Subject: Access violation using gpgme In-Reply-To: References: <1827200.Ck3mivub6Y@esus> Message-ID: Hey Andre, I was just wondering if you had any other ideas about this? I tried to use WinDbg to debug it, which showed this error message: > Attempt to execute non-executable address 004fef7c Full output: https://gist.github.com/Daniel15/c8c31b9e46d8c2eea6385d7dd1ba6c40 I've been stepping through the code and haven't been able to work out why this happens, particularly since it happens after the passphrase callback has returned (so gpgme is calling the callback fine). However, I've never written any C code, so I'm not familiar with debugging it. The thing I'm not sure how to determine is where that pointer 0x004fef7c is coming from, and whether it's inside the gpgme library or in my app. Thanks! -- Regards, Daniel Lo Nigro https://d.sb/ | Twitter | Facebook On Tue, Feb 5, 2019 at 10:59 AM Daniel Lo Nigro wrote: > The code was using gpgme_io_write to write the passphrase followed by a > null byte: > https://github.com/wget/gpgme-sharp/blob/master/gpgme-sharp/Context.cs#L353-L354. > I changed it to gpgme_io_writen and newline. That code was written by > someone else way back in 2013 so I wonder if it's been broken this entire > time. Here's the changes I've made so far: > https://github.com/wget/gpgme-sharp/compare/master...Daniel15:pinentry > > Now I'm getting closer, but there's still some odd behaviour. The first > time I run my test app, I get an access violation. However, it does spawn > gpg-agent correctly, and the second time I run it, it works fine! I guess > gpg-agent is properly receiving/caching the passphrase. > > -- > Regards, > Daniel Lo Nigro > https://d.sb/ | Twitter | Facebook > > > > On Tue, Feb 5, 2019 at 10:32 AM Andre Heinecke > wrote: > >> Hi, >> >> On Tuesday, February 5, 2019 6:21:45 PM GMT Daniel Lo Nigro wrote: >> > I'm using gpgme_set_pinentry_mode to set the pinentry mode to >> "loopback", >> > and the access violation is being encountered after my pinentry callback >> > returns. It works fine if I don't use loopback, and instead use the >> > system's pinentry mechanism. >> >> This sounds like your passphrase callback returns invalid data. I would >> have >> to look how the PassphraseResult is mapped in the C# bindings but from >> the C >> API: >> >> The user must write the passphrase, followed by a newline character, >> to the file descriptor @var{fd}. The function @code{gpgme_io_writen} >> should be used for the write operation. Note that if the user returns >> 0 to indicate success, the user must at least write a newline >> character before returning from the callback. >> >> >> I do not think that you need to post your full code, but I would be >> interested >> in seeing your Passphrase callback. >> (Sorry If I'm the only one answering here but in the GnuPG Team I'm the >> Guy >> for "all things windows" ;-) ) >> >> >> Regards, >> Andre >> >> -- >> GnuPG e.V., Rochusstr. 44, D-40479 D?sseldorf. VR 11482 D?sseldorf >> Vorstand: W.Koch, M.Gollowitzer, A.Heinecke. Mail: board at gnupg.org >> Finanzamt D-Altstadt, St-Nr: 103/5923/1779. Tel: +49-2104-4938799 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Fri Feb 8 19:47:47 2019 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 08 Feb 2019 13:47:47 -0500 Subject: Access violation using gpgme In-Reply-To: <1827200.Ck3mivub6Y@esus> References: <1827200.Ck3mivub6Y@esus> Message-ID: <87a7j6yv58.fsf@fifthhorseman.net> On Tue 2019-02-05 18:32:31 +0000, Andre Heinecke wrote: > On Tuesday, February 5, 2019 6:21:45 PM GMT Daniel Lo Nigro wrote: >> I'm using gpgme_set_pinentry_mode to set the pinentry mode to "loopback", >> and the access violation is being encountered after my pinentry callback >> returns. It works fine if I don't use loopback, and instead use the >> system's pinentry mechanism. > > This sounds like your passphrase callback returns invalid data. I would have > to look how the PassphraseResult is mapped in the C# bindings but from the C > API: > > The user must write the passphrase, followed by a newline character, > to the file descriptor @var{fd}. The function @code{gpgme_io_writen} > should be used for the write operation. Note that if the user returns > 0 to indicate success, the user must at least write a newline > character before returning from the callback. If the data returned from the passphrase callback doesn't meet this format, it should fail (and possibly produce a clear/helpful warning message), but it *still* should not cause an access violation. If it does cause an access violation, that sounds like a bug in whatever is handling the result. can someone with more windows chops than i have open a bug report about this particular problem? linking to libgpgme should not cause crashing behavior under any circumstance. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From d at d.sb Sun Feb 10 20:39:29 2019 From: d at d.sb (Daniel Lo Nigro) Date: Sun, 10 Feb 2019 11:39:29 -0800 Subject: Access violation using gpgme In-Reply-To: References: <1827200.Ck3mivub6Y@esus> Message-ID: I ended up working this out. .NET Core is cross-platform and runs on Linux too, so I thought I'd test it on Linux too. One thing I ended up noticing was that the same code worked fine on 64-bit Linux, but failed on 32-bit Windows. I can't find a 64-bit build of Gpg4Win so I was unable to test 64-bit Windows, but I think it would have worked too. This led me to look at the potential differences between 32-bit and 64-bit. I found that all the calls from C# into GPGME were correctly marked as using the "cdecl" calling convention, however the callback was not, Microsoft compilers default to using "stdcall" calling convention. The main difference between them is that with cdecl the caller is responsible for cleaning up the stack, whereas with stdcall the callee is responsible for cleaning up the stack. Using the wrong one corrupts your stack. The callback actually seemed to execute fine, but the function that called the callback ended up crashing when it tried to return. 64-bit systems only use one calling convention (Windows differs from "everything else", but it's consistent within the same platform), which is why it worked fine on 64-bit. So in the end, I spent around a week debugging it, but it ended up just being a single-line change to fix it: https://github.com/Daniel15/gpgme-sharp/commit/108b6af6abaadd52e31798e0aea930fc18a14498 :D Thanks, -- Regards, Daniel Lo Nigro https://d.sb/ | Twitter | Facebook On Thu, Feb 7, 2019 at 10:53 PM Daniel Lo Nigro wrote: > Hey Andre, I was just wondering if you had any other ideas about this? I > tried to use WinDbg to debug it, which showed this error message: > > > Attempt to execute non-executable address 004fef7c > > Full output: > https://gist.github.com/Daniel15/c8c31b9e46d8c2eea6385d7dd1ba6c40 > > I've been stepping through the code and haven't been able to work out why > this happens, particularly since it happens after the passphrase callback > has returned (so gpgme is calling the callback fine). However, I've never > written any C code, so I'm not familiar with debugging it. The thing I'm > not sure how to determine is where that pointer 0x004fef7c is coming from, > and whether it's inside the gpgme library or in my app. > > Thanks! > > -- > Regards, > Daniel Lo Nigro > https://d.sb/ | Twitter | Facebook > > > > On Tue, Feb 5, 2019 at 10:59 AM Daniel Lo Nigro wrote: > >> The code was using gpgme_io_write to write the passphrase followed by a >> null byte: >> https://github.com/wget/gpgme-sharp/blob/master/gpgme-sharp/Context.cs#L353-L354. >> I changed it to gpgme_io_writen and newline. That code was written by >> someone else way back in 2013 so I wonder if it's been broken this entire >> time. Here's the changes I've made so far: >> https://github.com/wget/gpgme-sharp/compare/master...Daniel15:pinentry >> >> Now I'm getting closer, but there's still some odd behaviour. The first >> time I run my test app, I get an access violation. However, it does spawn >> gpg-agent correctly, and the second time I run it, it works fine! I guess >> gpg-agent is properly receiving/caching the passphrase. >> >> -- >> Regards, >> Daniel Lo Nigro >> https://d.sb/ | Twitter | Facebook >> >> >> >> On Tue, Feb 5, 2019 at 10:32 AM Andre Heinecke >> wrote: >> >>> Hi, >>> >>> On Tuesday, February 5, 2019 6:21:45 PM GMT Daniel Lo Nigro wrote: >>> > I'm using gpgme_set_pinentry_mode to set the pinentry mode to >>> "loopback", >>> > and the access violation is being encountered after my pinentry >>> callback >>> > returns. It works fine if I don't use loopback, and instead use the >>> > system's pinentry mechanism. >>> >>> This sounds like your passphrase callback returns invalid data. I would >>> have >>> to look how the PassphraseResult is mapped in the C# bindings but from >>> the C >>> API: >>> >>> The user must write the passphrase, followed by a newline character, >>> to the file descriptor @var{fd}. The function @code{gpgme_io_writen} >>> should be used for the write operation. Note that if the user returns >>> 0 to indicate success, the user must at least write a newline >>> character before returning from the callback. >>> >>> >>> I do not think that you need to post your full code, but I would be >>> interested >>> in seeing your Passphrase callback. >>> (Sorry If I'm the only one answering here but in the GnuPG Team I'm the >>> Guy >>> for "all things windows" ;-) ) >>> >>> >>> Regards, >>> Andre >>> >>> -- >>> GnuPG e.V., Rochusstr. 44, D-40479 D?sseldorf. VR 11482 D?sseldorf >>> Vorstand: W.Koch, M.Gollowitzer, A.Heinecke. Mail: board at gnupg.org >>> Finanzamt D-Altstadt, St-Nr: 103/5923/1779. Tel: +49-2104-4938799 >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Tue Feb 12 18:54:35 2019 From: wk at gnupg.org (Werner Koch) Date: Tue, 12 Feb 2019 18:54:35 +0100 Subject: [Announce] GnuPG 2.2.13 released Message-ID: <87mun03nac.fsf@wheatstone.g10code.de> Hello! We are pleased to announce the availability of a new GnuPG release: version 2.2.13. This is a maintenance release; see below for a list of fixed bugs. About GnuPG =========== The GNU Privacy Guard (GnuPG) is a complete and free implementation of the OpenPGP standard which is commonly abbreviated as PGP. 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. A wealth of frontend applications and libraries making use of GnuPG are available. As an universal crypto engine GnuPG provides support for S/MIME and Secure Shell in addition to OpenPGP. GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU General Public License. Noteworthy changes in version 2.2.13 ==================================== * gpg: Implement key lookup via keygrip (using the & prefix). * gpg: Allow generating Ed25519 key from existing key. * gpg: Emit an ERROR status line if no key was found with -k. * gpg: Stop early when trying to create a primary Elgamal key. [#4329] * gpgsm: Print the card's key algorithms along with their keygrips in interactive key generation. * agent: Clear bogus pinentry cache in the error case. [#4348] * scd: Support "acknowledge button" feature. * scd: Fix for USB INTERRUPT transfer. [#4308] * wks: Do no use compression for the the encrypted challenge and response. Release-info: https://dev.gnupg.org/T4290 Getting the Software ==================== Please follow the instructions found at or read on: GnuPG 2.2.13 may be downloaded from one of the GnuPG mirror sites or direct from its primary FTP server. The list of mirrors can be found at . Note that GnuPG is not available at ftp.gnu.org. The GnuPG source code compressed using BZIP2 and its OpenPGP signature are available here: https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.13.tar.bz2 (6545k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.13.tar.bz2.sig An installer for Windows without any graphical frontend except for a very minimal Pinentry tool is available here: https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.13_20190212.exe (4078k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.13_20190212.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.2.13.tar.bz2 you would use this command: gpg --verify gnupg-2.2.13.tar.bz2.sig gnupg-2.2.13.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See the end of this mail for information on the signing keys. * If you are not able to use an existing version of GnuPG, you have to verify the SHA-1 checksum. On Unix systems the command to do this is either "sha1sum" or "shasum". Assuming you downloaded the file gnupg-2.2.13.tar.bz2, you run the command like this: sha1sum gnupg-2.2.13.tar.bz2 and check that the output matches the next line: 66ebc053e2d22f743673d3fbe54453774e4fac58 gnupg-2.2.13.tar.bz2 2b76bf7981957ebc8ca74e70cb1776ad6ab656fd gnupg-w32-2.2.13_20190212.tar.xz ce2c5e60f851f3d54c85da1be717cc53742c4953 gnupg-w32-2.2.13_20190212.exe Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese (traditional and simplified), Czech, French, German, Japanese, Norwegian, Russian, and Ukrainian being almost completely translated. Documentation and Support ========================= If you used GnuPG in the past you should read the description of changes and new features at doc/whats-new-in-2.1.txt or online at https://gnupg.org/faq/whats-new-in-2.1.html The file gnupg.info has the complete reference manual of the system. Separate man pages are included as well but they miss some of the details available only in thee manual. The manual is also available online at https://gnupg.org/documentation/manuals/gnupg/ or can be downloaded as PDF at https://gnupg.org/documentation/manuals/gnupg.pdf . The chapters on gpg-agent, gpg and gpgsm include information on how to set up the whole thing. 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. In case of build problems specific to this release please first check https://dev.gnupg.org/T4290 for updated information. Please consult the archive of the gnupg-users mailing list before reporting a bug: . We suggest to send bug reports for a new release to this list in favor of filing a bug at . If you need commercial support check out . If you are a developer and you need a certain feature for your project, please do not hesitate to bring it to the gnupg-devel mailing list for discussion. Thanks ====== Maintenance and development of GnuPG is mostly financed by donations. The GnuPG project currently employs two full-time developers and one contractor. They all work exclusively on GnuPG and closely related software like Libgcrypt, GPGME and Gpg4win. We have to thank all the people who helped the GnuPG project, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, and answering questions on the mailing lists. Many thanks to our numerous financial supporters, both corporate and individuals. Without you it would not be possible to keep GnuPG in a good shape and to address all the small and larger requests made by our users. Thanks. Happy hacking, Your GnuPG hackers p.s. This is an announcement only mailing list. Please send replies only to the gnupg-users'at'gnupg.org mailing list. p.p.s List of Release Signing Keys: To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: rsa2048 2011-01-12 [expires: 2019-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048 2014-10-29 [expires: 2019-12-31] Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 David Shaw (GnuPG Release Signing Key) rsa2048 2014-10-29 [expires: 2020-10-30] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa3072 2017-03-17 [expires: 2027-03-15] Key fingerprint = 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28 Andre Heinecke (Release Signing Key) The keys are available at and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From gniibe at fsij.org Thu Feb 14 01:23:17 2019 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 14 Feb 2019 09:23:17 +0900 Subject: [PATCH libksba 2/2] Support multi-valued signatures in CSRs. In-Reply-To: <20181116012738.23296-3-dgouttegattat@incenp.org> References: <20181116012738.23296-1-dgouttegattat@incenp.org> <20181116012738.23296-3-dgouttegattat@incenp.org> Message-ID: <875ztngqve.fsf@iwagami.gniibe.org> Hello, Damien Goutte-Gattat wrote: > * src/certreq.c (ksba_certreq_set_sig_val): Support signatures > made of several values. > -- > > The current implementation of ksba_certreq_set_sig_val takes > only the first MPI value in the provided S-expression to build > the CSR signature. This is enough for RSA, but not for ECDSA > since a ECDSA signature is made of two values. > > This patch makes sure all values are taken into account. It > also partially replaces some of the ad-hoc parsing code by > the helper functions defined in sexp-parse.h. Thanks, applied and pushed. -- From gniibe at fsij.org Thu Feb 14 01:55:59 2019 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 14 Feb 2019 09:55:59 +0900 Subject: [PATCH gnupg 1/2] sm: Support generation of card-based ECDSA CSR. In-Reply-To: <20181116012738.23296-2-dgouttegattat@incenp.org> References: <20181116012738.23296-1-dgouttegattat@incenp.org> <20181116012738.23296-2-dgouttegattat@incenp.org> Message-ID: <8736orgpcw.fsf@iwagami.gniibe.org> Hello, Damien Goutte-Gattat wrote: > * sm/call-agent.c (gpgsm_scd_pksign): Identify type of signing key > and format resulting S-expression accordingly. > * sm/misc.c (transform_sigval): Support ECDSA signatures. > -- > > Current GpgSM implementation assumes card-based keys are RSA keys. > This patch introduces support for ECDSA keys. > > By itself this patch is not sufficient, we also need support > from libksba. Comparing agent_pksign_do in gnupg/agent/pksign.c and your gpgsm_scd_pksign, I think that it's not yet perfect. (1) There are three cases; RSA, ECDSA, and EdDSA. It's good that we can support all. (2) The format of signature by card in agent_pksign_do is the one of libgcrypt. In the agent_pksign_do function, for ECDSA, it checks the MSB, and put the prefix 0x00 in this case. It should be same for GpgSM. Well, shall we apply your patch first, and then proceed to more changes for EdDSA and 0x00-for-MSB? Or, are you going to submit updated patch? Whichever is OK. Let me know. -- From ben at adversary.org Thu Feb 14 13:32:01 2019 From: ben at adversary.org (Ben McGinnes) Date: Thu, 14 Feb 2019 23:32:01 +1100 Subject: gpgme_op_delete() does not work with gpg 2.x In-Reply-To: References:

Message-ID: <20190214123201.r6r6scdfx4gumkch@adversary.org> On Wed, Jan 02, 2019 at 05:34:31PM -0500, brent s. wrote: > On 1/2/19 4:17 PM, Jeroen Ooms wrote: > >> I'm not sure how much this will help you, but deleting a private key > >> works in the Python bindings if I use the abstracted method but not the > >> direct gpgme method (see attached POC). > > > > So which C function does the latter use then? I don't use python but > > to me it looks like both those methods are different syntax for the > > same thing? Why would they show different behavior? > > > > I don't know much about the bindings themselves other than they're > generated (mostly?) automatically via SWIG[0]. However, the former > method (gpgme.gpgme_op_delete()) is, I believe, the direct SWIG > method. Yes, SWIG generates methods to match every correspondingly named method, function, call and constant in GPGME itself. So everything which starts with "gpgme_op_" is generated by SWIG. Those methods behave as close as possible to the C originals. Then there's a more Pythonic layer above that which has been added manually. It doesn't do everything GPGME does, but it probably does most of the things most developers would want. In many cases the opportunity has been taken to simplify certain things (e.g. to make it unnecessary for devs to need to memorise or reference check mode or status values in the constants, as can be seen with the key exporting code). Inevitably some people ask, why use SWIG. Aside from historical reasons stemming from PyME; SWIG can generate bindings in a form which is complete and which certain other popular methods simply can't do (e.g. CFFI, ctypes, etc.). GPGME is somewhat larger than many people realise and every time it's compiled, SWIG generates somewhere in the vicinity of a couple of thousand bindings. That number is increasing with each release, albeit gradually ? it's currently a little over 2,070 functions across GPGME's calls, methods and constants. That's with duplicates, Python specific bits and SWIG specific bits removed from the count. Still, those bindings will often be somewhat confusing to developers with no experience dealing with C at all. Between that issue and the intention of being able to make a consistent Pythonic interface, regardless of what happens under the hood; there was more than good enough reasons for writing that Pythonic layer of essential functions. Most of that is in gpg.core; then components are imported from core to the parent module. This includes the Context() and Data() methods, amongst other things. The actual SWIG bindings can be accessed via either or both of gpg._gpgme or gpg.core.gpgme; but I don't recommend it unless there's something you *really* need and which isn't accessible via the Context() directly. > SWIG does support R, it looks like[1] so you may be able to create the R > bindings in much the same way (while even reusing many of the parts for > python[2]). It can probably be done, just as long as one is familiar with SWIG's own syntax and can adapt it between languages. > Based on git commit history, I'd try to see if you can get in touch > with Ben McGinnes[3]; he should be able to answer your question with > much more clarity, I'd imagine. Sorry I wasn't much more help! Well, to answer that question: gpgme_op_delete is in src/delete.c in the GPGME repo or any source release. The auto-generated GPGME documentation entry for that and related calls is here: https://gnupg.org/documentation/manuals/gpgme/Deleting-Keys.html That documentation, however, is rather sparse. It's better used as a reference than an instruction manual. The Python bindings, however, do have a more readable documentation set' that being the HOWTO it ships with. > [0] http://www.swig.org/ > [1] http://www.swig.org/Doc1.3/R.html > [2] > https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=tree;f=lang/python > [3] You can get his email address by cloning the gpgme git repo and running: > > git shortlog -nes -- lang/python That's one way, to be sure. It's also at the top of the Python bindings HOWTO doc. That address will also be effectively filtered so things don't get lost amidst the many thousands of things that come to this address. > or just getting it from the gitweb interface. That too. > (not pasting the email addresses here in case there are harvesting > spiders for spammers) Appreciated, but I've had this domain for about twenty years. Spam harvesting from lists is something I stopped worrying about a *long* time ago. ;) Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From dkg at fifthhorseman.net Thu Feb 14 15:47:15 2019 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 14 Feb 2019 09:47:15 -0500 Subject: [PATCH] Fix for simple typo in the Norwegian translation In-Reply-To: References: Message-ID: <87a7iyv34c.fsf@fifthhorseman.net> On Thu 2018-11-08 09:44:09 +0100, Ingvar Hagelund wrote: > Here's a fix for a simple typo in the Norwegian translation. applied to master and to STABLE_BRANCH_2_2, thanks. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From dgouttegattat at incenp.org Fri Feb 15 00:19:52 2019 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Thu, 14 Feb 2019 23:19:52 +0000 Subject: [PATCH gnupg 1/2] sm: Support generation of card-based ECDSA CSR. In-Reply-To: <8736orgpcw.fsf@iwagami.gniibe.org> References: <20181116012738.23296-1-dgouttegattat@incenp.org> <20181116012738.23296-2-dgouttegattat@incenp.org> <8736orgpcw.fsf@iwagami.gniibe.org> Message-ID: <20190214231952.3lrxbv2vd6iq4yfp@aurora.local.incenp.org> Hi, On Thu, Feb 14, 2019 at 09:55:59AM +0900, NIIBE Yutaka wrote: > (1) There are three cases; RSA, ECDSA, and EdDSA. It's good that we can > support all. Agreed. I have another patch in the works to add support for EdDSA. > (2) The format of signature by card in agent_pksign_do is the one of > libgcrypt. In the agent_pksign_do function, for ECDSA, it checks > the MSB, and put the prefix 0x00 in this case. It should be same > for GpgSM. I can look into that, but I am not sure I understand everything here. Looking at the agent_pksign_do function, I can see that this MSB checking is performed for RSA and ECDSA signatures, but not for EdDSA. (1) Is it normal not to do this check for EdDSA? (2) Currently gpgsm_scd_pksign does not perform this check for RSA (that?s actually why I didn?t think it was needed for ECDSA as well, and didn?t implement it in my patch). Again, is that normal? Or should we add this check also for RSA? > Well, shall we apply your patch first, and then proceed to more changes > for EdDSA Yes, that was kind of my plan: First add ECDSA support, then build upon that to add EdDSA support afterward. I will post the patch for EdDSA soon. > and 0x00-for-MSB? Likewise, I can submit another patch later for this issue, once I will be sure I know what I am doing and why I am doing it. :) Thanks, - Damien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From dgouttegattat at incenp.org Fri Feb 15 00:03:03 2019 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Thu, 14 Feb 2019 23:03:03 +0000 Subject: [PATCH libksba 2/2] Support multi-valued signatures in CSRs. In-Reply-To: <875ztngqve.fsf@iwagami.gniibe.org> References: <20181116012738.23296-1-dgouttegattat@incenp.org> <20181116012738.23296-3-dgouttegattat@incenp.org> <875ztngqve.fsf@iwagami.gniibe.org> Message-ID: <20190214230302.7vlmd7tqgztmgf55@aurora.local.incenp.org> Hi, On Thu, Feb 14, 2019 at 09:23:17AM +0900, NIIBE Yutaka wrote: > Hello, > > Damien Goutte-Gattat wrote: > > * src/certreq.c (ksba_certreq_set_sig_val): Support signatures > > made of several values. > > Thanks, applied and pushed. Thanks. I just want to note that when I wrote this patch, I (mistakently) thought that EdDSA signature values were constructed the same way as ECDSA signature values (that is, as a SEQUENCE of INTEGER values). I realized later that it is not the case. The RFC 8410 [1] states that for EdDSA signatures, the value shall simply be the concatenation of the two MPIs that are the result of the EdDSA operation. Therefore this patch only adds support for ECDSA, and more work will be needed to make the ksba_certreq_set_sig_val function usable with EdDSA. Best, - Damien [1] https://tools.ietf.org/html/rfc8410#section-6 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From dgouttegattat at incenp.org Sun Feb 17 18:40:51 2019 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Sun, 17 Feb 2019 17:40:51 +0000 Subject: [PATCH gnupg] sm: Support generation of card-based ed25519 CSR. In-Reply-To: <20190214231952.3lrxbv2vd6iq4yfp@aurora.local.incenp.org> References: <20190214231952.3lrxbv2vd6iq4yfp@aurora.local.incenp.org> Message-ID: <20190217174051.9335-1-dgouttegattat@incenp.org> Hi, On Thu, 14 Feb 2019 23:19:52 +0000, Damien Goutte-Gattat wrote: > > (1) There are three cases; RSA, ECDSA, and EdDSA. It's good that we > > can support all. > > Agreed. I have another patch in the works to add support for EdDSA. Here is the patch to add EdDSA support when generating a CSR from a token-based key. What is still missing for this to work is support from Libksba, which currently generates both an incorrect SPKI and an incorrect signature value for EdDSA-based CSRs. -- >8 -- Subject: sm: Support generation of card-based ed25519 CSR. * sm/call-agent.c (gpgsm_scd_pksign): Allow SHA512. Create proper S-expression for EdDSA signature. * sm/certreqgen.c (create_request): Force use of SHA512 when using a ed25519 key. * sm/misc.c (transform_sigval): Insert OID for ed25519. GnuPG-bug-id: 4013 Signed-off-by: Damien Goutte-Gattat --- sm/call-agent.c | 7 +++++++ sm/certreqgen.c | 6 ++++-- sm/misc.c | 10 ++++++++-- 3 files changed, 19 insertions(+), 4 deletions(-) diff --git a/sm/call-agent.c b/sm/call-agent.c index 6ac715fab..4f2b83f56 100644 --- a/sm/call-agent.c +++ b/sm/call-agent.c @@ -354,6 +354,7 @@ gpgsm_scd_pksign (ctrl_t ctrl, const char *keyid, const char *desc, case GCRY_MD_RMD160:hashopt = "--hash=rmd160"; break; case GCRY_MD_MD5: hashopt = "--hash=md5"; break; case GCRY_MD_SHA256:hashopt = "--hash=sha256"; break; + case GCRY_MD_SHA512:hashopt = "--hash=sha512"; break; default: return gpg_error (GPG_ERR_DIGEST_ALGO); } @@ -417,6 +418,12 @@ gpgsm_scd_pksign (ctrl_t ctrl, const char *keyid, const char *desc, sigbuflen/2, sigbuf + sigbuflen/2); break; + case GCRY_PK_EDDSA: + rc = gcry_sexp_build (&sig, NULL, "(sig-val(eddsa(r%b)(s%b)))", + sigbuflen/2, sigbuf, + sigbuflen/2, sigbuf + sigbuflen/2); + break; + default: rc = gpg_error (GPG_ERR_WRONG_PUBKEY_ALGO); break; diff --git a/sm/certreqgen.c b/sm/certreqgen.c index 1d610c1bb..01fba30f5 100644 --- a/sm/certreqgen.c +++ b/sm/certreqgen.c @@ -807,8 +807,10 @@ create_request (ctrl_t ctrl, if (err) return err; - string = get_parameter_value (para, pHASHALGO, 0); - if (string) + len = gcry_sexp_canon_len (public, 0, NULL, NULL); + if (get_pk_algo_from_canon_sexp (public, len) == GCRY_PK_EDDSA) + mdalgo = GCRY_MD_SHA512; + else if ((string = get_parameter_value (para, pHASHALGO, 0))) mdalgo = gcry_md_map_name (string); else mdalgo = GCRY_MD_SHA256; diff --git a/sm/misc.c b/sm/misc.c index 9bf528513..4672f269e 100644 --- a/sm/misc.c +++ b/sm/misc.c @@ -146,6 +146,8 @@ transform_sigval (const unsigned char *sigval, size_t sigvallen, int mdalgo, pkalgo = GCRY_PK_RSA; else if (toklen == 5 && !memcmp ("ecdsa", tok, 5)) pkalgo = GCRY_PK_ECC; + else if (toklen == 5 && !memcmp ("eddsa", tok, 5)) + pkalgo = GCRY_PK_EDDSA; else return gpg_error (GPG_ERR_WRONG_PUBKEY_ALGO); @@ -170,7 +172,7 @@ transform_sigval (const unsigned char *sigval, size_t sigvallen, int mdalgo, mpi = &rsa_s; mpi_len = &rsa_s_len; } - else if (pkalgo == GCRY_PK_ECC) + else if (pkalgo == GCRY_PK_ECC || pkalgo == GCRY_PK_EDDSA) { mpi = &ecc_s; mpi_len = &ecc_s_len; @@ -236,6 +238,10 @@ transform_sigval (const unsigned char *sigval, size_t sigvallen, int mdalgo, oid = "1.2.840.10045.4.3.4"; /* ecdsa-with-sha512 */ break; + case GCRY_MD_SHA512 | (GCRY_PK_EDDSA << 8): + oid = "1.3.101.112"; /* ed25519 */ + break; + default: return gpg_error (GPG_ERR_DIGEST_ALGO); } @@ -245,7 +251,7 @@ transform_sigval (const unsigned char *sigval, size_t sigvallen, int mdalgo, else if (pkalgo == GCRY_PK_RSA) err = gcry_sexp_build (&sexp, NULL, "(sig-val(%s(s%b)))", oid, (int)rsa_s_len, rsa_s); - else if (pkalgo == GCRY_PK_ECC) + else if (pkalgo == GCRY_PK_ECC || pkalgo == GCRY_PK_EDDSA) err = gcry_sexp_build (&sexp, NULL, "(sig-val(%s(r%b)(s%b)))", oid, (int)ecc_r_len, ecc_r, (int)ecc_s_len, ecc_s); if (err) -- 2.14.5 From gniibe at fsij.org Mon Feb 18 03:35:53 2019 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 18 Feb 2019 11:35:53 +0900 Subject: [PATCH gnupg] sm: Support generation of card-based ed25519 CSR. In-Reply-To: <20190217174051.9335-1-dgouttegattat@incenp.org> References: <20190214231952.3lrxbv2vd6iq4yfp@aurora.local.incenp.org> <20190217174051.9335-1-dgouttegattat@incenp.org> Message-ID: <871s45rfg6.fsf@iwagami.gniibe.org> Damien Goutte-Gattat via Gnupg-devel wrote: > Here is the patch to add EdDSA support when generating a CSR from a > token-based key. Thanks. Applied and pushed. -- From smueller at chronox.de Tue Feb 19 08:14:41 2019 From: smueller at chronox.de (Stephan Mueller) Date: Tue, 19 Feb 2019 08:14:41 +0100 Subject: [PATCH GnuPG v2] gpg: expand GPG groups when resolving a key Message-ID: <15508587.oujxkZr0W8@tauon.chronox.de> Hi, Changes v2: Traverse namelist and namelist_expanded ---8<--- * g10/expand_group.c: New * g10/pkclist.c: Extract expand_group and expand_id into expand_group.c * g10/keydb.h: Add prototypes of expand_id and expand_group * g10/getkey.c: Use expand_group before resolving key references * g10/Makefile.am: Compile expand_group.c -- When searching a key by its name, try to expand the provided name in case it is a GPG group reference. This GPG group resolution is performed before the individual keys are verified. This allows key listing using a GPG group reference. In particular, this modification fixes the encryption to group support in KDE's Kmail which is broken since version 18.04. Signed-off-by: Stephan Mueller --- g10/Makefile.am | 1 + g10/expand_group.c | 73 ++++++++++++++++++++++++++++++++++++++++++++++ g10/getkey.c | 26 +++++++++++++++-- g10/keydb.h | 2 ++ g10/pkclist.c | 49 ------------------------------- 5 files changed, 99 insertions(+), 52 deletions(-) create mode 100644 g10/expand_group.c diff --git a/g10/Makefile.am b/g10/Makefile.am index 3b4464364..63a42aba5 100644 --- a/g10/Makefile.am +++ b/g10/Makefile.am @@ -99,6 +99,7 @@ common_source = \ filter.h \ free-packet.c \ getkey.c \ + expand_group.c \ keydb.c keydb.h \ keyring.c keyring.h \ seskey.c \ diff --git a/g10/expand_group.c b/g10/expand_group.c new file mode 100644 index 000000000..310daa944 --- /dev/null +++ b/g10/expand_group.c @@ -0,0 +1,73 @@ +/* expand_group.c - expand GPG group definitions + * Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, + * 2008, 2009, 2010 Free Software Foundation, Inc. + * + * This file is part of GnuPG. + * + * GnuPG is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 3 of the License, or + * (at your option) any later version. + * + * GnuPG is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, see . + */ + +#include + +#include "gpg.h" +#include "options.h" +#include "keydb.h" + +int +expand_id(const char *id,strlist_t *into,unsigned int flags) +{ + struct groupitem *groups; + int count=0; + + for(groups=opt.grouplist;groups;groups=groups->next) + { + /* need strcasecmp() here, as this should be localized */ + if(strcasecmp(groups->name,id)==0) + { + strlist_t each,sl; + + /* this maintains the current utf8-ness */ + for(each=groups->values;each;each=each->next) + { + sl=add_to_strlist(into,each->d); + sl->flags=flags; + count++; + } + + break; + } + } + + return count; +} + +/* For simplicity, and to avoid potential loops, we only expand once - + * you can't make an alias that points to an alias. */ +strlist_t +expand_group (strlist_t input) +{ + strlist_t output = NULL; + strlist_t sl, rover; + + for (rover = input; rover; rover = rover->next) + if (!(rover->flags & PK_LIST_FROM_FILE) + && !expand_id(rover->d,&output,rover->flags)) + { + /* Didn't find any groups, so use the existing string */ + sl=add_to_strlist(&output,rover->d); + sl->flags=rover->flags; + } + + return output; +} diff --git a/g10/getkey.c b/g10/getkey.c index 08e17e930..84528cdca 100644 --- a/g10/getkey.c +++ b/g10/getkey.c @@ -1098,7 +1098,7 @@ key_byname (ctrl_t ctrl, GETKEY_CTX *retctx, strlist_t namelist, { int rc = 0; int n; - strlist_t r; + strlist_t r, namelist_expanded = NULL, link = NULL; GETKEY_CTX ctx; KBNODE help_kb = NULL; KBNODE found_key = NULL; @@ -1127,6 +1127,19 @@ key_byname (ctrl_t ctrl, GETKEY_CTX *retctx, strlist_t namelist, } else { + namelist_expanded = expand_group (namelist); + + /* Chain namelist and namelist_expanded */ + for (r = namelist; r; r = r->next) + { + if (!r->next) + { + r->next = namelist_expanded; + link = r; + break; + } + } + /* Build the search context. */ for (n = 0, r = namelist; r; r = r->next) n++; @@ -1148,7 +1161,8 @@ key_byname (ctrl_t ctrl, GETKEY_CTX *retctx, strlist_t namelist, if (err) { xfree (ctx); - return gpg_err_code (err); /* FIXME: remove gpg_err_code. */ + rc = gpg_err_code (err); /* FIXME: remove gpg_err_code. */ + goto out; } if (!include_unusable && ctx->items[n].mode != KEYDB_SEARCH_MODE_SHORT_KID @@ -1169,7 +1183,7 @@ key_byname (ctrl_t ctrl, GETKEY_CTX *retctx, strlist_t namelist, { rc = gpg_error_from_syserror (); getkey_end (ctrl, ctx); - return rc; + goto out; } if (!ret_kb) @@ -1200,6 +1214,12 @@ key_byname (ctrl_t ctrl, GETKEY_CTX *retctx, strlist_t namelist, getkey_end (ctrl, ctx); } +out: + if (namelist_expanded) + free_strlist(namelist_expanded); + /* Un-chain namelist and namelist_expanded */ + if (link) + link->next = NULL; return rc; } diff --git a/g10/keydb.h b/g10/keydb.h index 9748e571e..14cf04ff3 100644 --- a/g10/keydb.h +++ b/g10/keydb.h @@ -254,6 +254,8 @@ void show_revocation_reason (ctrl_t ctrl, PKT_public_key *pk, int mode ); int check_signatures_trust (ctrl_t ctrl, PKT_signature *sig); void release_pk_list (PK_LIST pk_list); +int expand_id(const char *id,strlist_t *into,unsigned int flags); +strlist_t expand_group (strlist_t input); int build_pk_list (ctrl_t ctrl, strlist_t rcpts, PK_LIST *ret_pk_list); gpg_error_t find_and_check_key (ctrl_t ctrl, const char *name, unsigned int use, diff --git a/g10/pkclist.c b/g10/pkclist.c index e7484432a..8b49a31d3 100644 --- a/g10/pkclist.c +++ b/g10/pkclist.c @@ -759,55 +759,6 @@ default_recipient (ctrl_t ctrl) } -static int -expand_id(const char *id,strlist_t *into,unsigned int flags) -{ - struct groupitem *groups; - int count=0; - - for(groups=opt.grouplist;groups;groups=groups->next) - { - /* need strcasecmp() here, as this should be localized */ - if(strcasecmp(groups->name,id)==0) - { - strlist_t each,sl; - - /* this maintains the current utf8-ness */ - for(each=groups->values;each;each=each->next) - { - sl=add_to_strlist(into,each->d); - sl->flags=flags; - count++; - } - - break; - } - } - - return count; -} - -/* For simplicity, and to avoid potential loops, we only expand once - - * you can't make an alias that points to an alias. */ -static strlist_t -expand_group (strlist_t input) -{ - strlist_t output = NULL; - strlist_t sl, rover; - - for (rover = input; rover; rover = rover->next) - if (!(rover->flags & PK_LIST_FROM_FILE) - && !expand_id(rover->d,&output,rover->flags)) - { - /* Didn't find any groups, so use the existing string */ - sl=add_to_strlist(&output,rover->d); - sl->flags=rover->flags; - } - - return output; -} - - /* Helper for build_pk_list to find and check one key. This helper is * also used directly in server mode by the RECIPIENTS command. On * success the new key is added to PK_LIST_ADDR. NAME is the user id -- 2.20.1 From patrick at enigmail.net Tue Feb 19 17:35:07 2019 From: patrick at enigmail.net (Patrick Brunschwig) Date: Tue, 19 Feb 2019 17:35:07 +0100 Subject: Bug or Feature with export-filter? Message-ID: I'm using gpg as follows to export a minimum key: gpg --export-options export-minimal,no-export-attributes \ --export-filter "keep-uid=mbox=invalid" \ --export some-key-id If the key to export does not have a UID "invalid", then the exported key does not contain any UID packet at all. Is this expected, a bug or a feature? Thanks, Patrick From wk at gnupg.org Wed Feb 20 08:38:38 2019 From: wk at gnupg.org (Werner Koch) Date: Wed, 20 Feb 2019 08:38:38 +0100 Subject: Bug or Feature with export-filter? In-Reply-To: (Patrick Brunschwig's message of "Tue, 19 Feb 2019 17:35:07 +0100") References: Message-ID: <87d0nmj4e9.fsf@wheatstone.g10code.de> On Tue, 19 Feb 2019 17:35, patrick at enigmail.net said: > If the key to export does not have a UID "invalid", then the exported > key does not contain any UID packet at all. Is this expected, a bug or a Expected. I can see your problem with that but fear that others view this as a feature to export just the public key part. I would not mind if you issue a bug report or feature request. 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 d at d.sb Mon Feb 25 02:33:46 2019 From: d at d.sb (Daniel Lo Nigro) Date: Sun, 24 Feb 2019 17:33:46 -0800 Subject: Selecting subkey with GPGME Message-ID: Hi! When using GPGME to sign a file, how can I choose which subkey to use? gpgme_signers_add seems to only take a gpgme_key_t, not a gpgme_subkey_t. Thanks, -- Regards, Daniel Lo Nigro https://d.sb/ | Twitter | Facebook -------------- next part -------------- An HTML attachment was scrubbed... URL: