From tom at ritter.vg Mon Apr 4 00:51:42 2011 From: tom at ritter.vg (Tom Ritter) Date: Sun, 3 Apr 2011 18:51:42 -0400 Subject: Compiling in low-memory conditions Message-ID: I was compiling libgcrypt and gnupg on a low-memory VPS, and ran into a few problems. First, I compiled libgcrypt, and ran into a gcc crash, when it ran out of memory trying to compile twofish.o. It looked like this: gcc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/usr/local/include -g -O2 --param ggc-min-expand=0 --param ggc-min-heapsize=32768 -fvisibility=hidden -Wall -MT twofish.lo -MD -MP -MF .deps/twofish.Tpo -c twofish.c -fPIC -DPIC -o .libs/twofish.o cc1: out of memory allocating 3082800 bytes after a total of 4681728 bytes make[2]: *** [twofish.lo] Error 1 I worked around that, I'll explain in a minute but I did compile libgcrypt, and moved onto gnupg. For gnupg I ran ./configure and after installing the libraries I needed, I began to compile gnupg. However it failed with an error about missing zlib.h - I would have though configure would pick that up. But no worries, after getting it, I continued the compile and ran into the same gcc out-of-memory crashes on : - keyedit.o - gpg.o - keygen.o To get around the out of memory issue, I tried using ulimit, but this did not help. What did work was editing the Makefile and temporarily setting the optimization level to -O0. After the module was compiled I killed the build, and set it back to O2. Repeating for each module that crashed it. I don't know if there's any way this could be prevented without unnecessary work, so I mainly just wanted to document it for anyone who ran into the same problem as me. Finally, i believe the 'status_codes.h' getting deleted that I reported last summer[1] is still active. -tom [1] http://lists.gnupg.org/pipermail/gnupg-devel/2010-July/025642.html From g.esp at free.fr Mon Apr 4 07:34:44 2011 From: g.esp at free.fr (Gilles Espinasse) Date: Mon, 4 Apr 2011 07:34:44 +0200 Subject: Compiling in low-memory conditions References: Message-ID: <067401cbf28a$02542a30$f9b5a8c0@pii350> ----- Original Message ----- From: "Tom Ritter" To: ; Sent: Monday, April 04, 2011 12:51 AM Subject: Compiling in low-memory conditions > I was compiling libgcrypt and gnupg on a low-memory VPS, and ran into > a few problems. First, I compiled libgcrypt, and ran into a gcc crash, > when it ran out of memory trying to compile twofish.o. It looked like > this: > > gcc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/usr/local/include -g > -O2 --param ggc-min-expand=0 --param ggc-min-heapsize=32768 > -fvisibility=hidden -Wall -MT twofish.lo -MD -MP -MF .deps/twofish.Tpo > -c twofish.c -fPIC -DPIC -o .libs/twofish.o > > cc1: out of memory allocating 3082800 bytes after a total of 4681728 bytes > make[2]: *** [twofish.lo] Error 1 > Not enabling debugging with '-g' should spare memory for the compilation. Gilles From wk at gnupg.org Mon Apr 4 09:32:44 2011 From: wk at gnupg.org (Werner Koch) Date: Mon, 04 Apr 2011 09:32:44 +0200 Subject: Compiling in low-memory conditions In-Reply-To: <067401cbf28a$02542a30$f9b5a8c0@pii350> (Gilles Espinasse's message of "Mon, 4 Apr 2011 07:34:44 +0200") References: <067401cbf28a$02542a30$f9b5a8c0@pii350> Message-ID: <8739lybher.fsf@vigenere.g10code.de> On Mon, 4 Apr 2011 07:34, g.esp at free.fr said: > Not enabling debugging with '-g' should spare memory for the compilation. I don't think this helps. The optimizer is the problem and has always been. It tries to unroll the core of the twofish algorithm but it can't get it better than what we have in the source code. Newer gcc versions default to -O2 which exhibits the problem. Use -O1 or return to an older gcc version. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From aheinecke at intevation.de Tue Apr 5 10:10:48 2011 From: aheinecke at intevation.de (Andre Heinecke) Date: Tue, 5 Apr 2011 10:10:48 +0200 Subject: Including gpgme.h fails with i686-mingw-w64 Message-ID: <201104051011.03106.aheinecke@intevation.de> Hello, In gpgme.h ssize_t is defined as long this leads to a conflicting definition in mingw (since 3da380293d146f74f52ca81db0e31a18b51a1c27) it is not only defined for _MSC_VER but for all _WIN32 Error: >u:\include/gpgme.h:39: error: conflicting declaration 'typedef long int ssize_t' >c: \kdepim-e5-builds\kdepim-e5-package_2011-04-04-18-38\mingw\bin\../lib/gcc/i686-w64-mingw32/4.4.5/../../../../i686-w64-mingw32/include/_mingw.h:341: error: 'ssize_t' has a previous declaration as 'typedef int ssize_t' This is the same on 32Bit Windows but when compiling for x64 it would fail because long is 32Bit on Windows on 64Bit Systems but ssize_t is defined as int64 on 64Bit Systems. Why is there ssize_t defined in gpgme and not the one from BaseTsd.h taken? Regards, Andre -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Tue Apr 5 17:52:12 2011 From: wk at gnupg.org (Werner Koch) Date: Tue, 05 Apr 2011 17:52:12 +0200 Subject: Including gpgme.h fails with i686-mingw-w64 In-Reply-To: <201104051011.03106.aheinecke@intevation.de> (Andre Heinecke's message of "Tue, 5 Apr 2011 10:10:48 +0200") References: <201104051011.03106.aheinecke@intevation.de> Message-ID: <87hbacae6r.fsf@vigenere.g10code.de> On Tue, 5 Apr 2011 10:10, aheinecke at intevation.de said: > This is the same on 32Bit Windows but when compiling for x64 it would fail > because long is 32Bit on Windows on 64Bit Systems but ssize_t is defined as > int64 on 64Bit Systems. We simply don't support 64 bit windows - yet. > Why is there ssize_t defined in gpgme and not the one from BaseTsd.h taken? Because the mingw folks are constantly changing their header files without proper versioning. The code we use is based on an older mingw version or even on my original port of Colin Peter's mingw32. I can only suggest to stick to the version we are using. This is the only guarantee that things are working. We can't support multiple incompatible versions of that toolchain. You should also be aware that with each release they replace Windows defined function by their own functions which sometimes breaks assumption we need to make about windows bugs and in the end results in new bugs. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From aheinecke at intevation.de Tue Apr 5 18:43:50 2011 From: aheinecke at intevation.de (Andre Heinecke) Date: Tue, 5 Apr 2011 18:43:50 +0200 Subject: Including gpgme.h fails with i686-mingw-w64 In-Reply-To: <87hbacae6r.fsf@vigenere.g10code.de> References: <201104051011.03106.aheinecke@intevation.de> <87hbacae6r.fsf@vigenere.g10code.de> Message-ID: <201104051843.50332.aheinecke@intevation.de> Hi, At Dienstag, 5. April 2011 17:52:12 Werner Koch wrote: > We simply don't support 64 bit windows - yet. I do not suggest that i just wanted to point out that your ssize_t definition differs there. > I can only suggest to stick to the version we are using. This is the > only guarantee that things are working. We can't support multiple > incompatible versions of that toolchain. You should also be aware that > with each release they replace Windows defined function by their own > functions which sometimes breaks assumption we need to make about > windows bugs and in the end results in new bugs. Maybe there is a missunderstanding here, I do not whish to compile gpgme with mingw-w64. I do not even build gnupg for windows at all but take the binaries that are provided by gpg4win but i need to be able to link libgpgme and for that i need to be able to include the correct header files. I understand your point about making as few assumptions as possible and defining your own types. But wouldn't it then be better named gpgme_ssize_t ? Can there be a check if ssize_t is already defined instead of having a conflicting definition of a system type in a header file? Regards, Andre -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From jeanjacquesbrucker at gmail.com Tue Apr 5 18:03:20 2011 From: jeanjacquesbrucker at gmail.com (Jean-Jacques Brucker) Date: Tue, 5 Apr 2011 18:03:20 +0200 Subject: sig binary format Message-ID: <201104051803.20375.jeanjacquesbrucker@gmail.com> Hi, I have a question concerning the first octet of *.sig file (created with --detach-sign option). I have see almost data match section 5.2.3. of the RFC4880, but i am asking me why is the first octet of a *.sig file (packet tag) 0x88 ? According to section 4.3 of RFC4880 0x88 means "Compressed Data Packet", I was instead expecting 0x82 for "Signature Packet" !? (sorry for a such annoying question). regards, -- Jean-Jacques B. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 316 bytes Desc: This is a digitally signed message part. URL: From dshaw at jabberwocky.com Tue Apr 5 19:29:00 2011 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 5 Apr 2011 13:29:00 -0400 Subject: sig binary format In-Reply-To: <201104051803.20375.jeanjacquesbrucker@gmail.com> References: <201104051803.20375.jeanjacquesbrucker@gmail.com> Message-ID: <4587B449-8D3F-48EC-98AE-08ED8FD2F2A7@jabberwocky.com> On Apr 5, 2011, at 12:03 PM, Jean-Jacques Brucker wrote: > > Hi, I have a question concerning the first octet of *.sig file (created with --detach-sign option). > > I have see almost data match section 5.2.3. of the RFC4880, but i am asking me why is the first octet of a *.sig file (packet tag) 0x88 ? > According to section 4.3 of RFC4880 0x88 means "Compressed Data Packet", I was instead expecting 0x82 for "Signature Packet" !? 0x88 means old-style signature packet. 0x88 == 10001000. Bit 6 is not set, so its an old-style tag. The relevant bits to indicate a packet type in an old-style tag are bits 5 through 2, so 0010. 0010 == 2, and 2 is a signature packet. David From dkg at fifthhorseman.net Tue Apr 5 19:29:40 2011 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 05 Apr 2011 13:29:40 -0400 Subject: sig binary format In-Reply-To: <201104051803.20375.jeanjacquesbrucker@gmail.com> References: <201104051803.20375.jeanjacquesbrucker@gmail.com> Message-ID: <4D9B5184.50807@fifthhorseman.net> On 04/05/2011 12:03 PM, Jean-Jacques Brucker wrote: > > Hi, I have a question concerning the first octet of *.sig file (created with --detach-sign option). > > I have see almost data match section 5.2.3. of the RFC4880, but i am asking me why is the first octet of a *.sig file (packet tag) 0x88 ? > According to section 4.3 of RFC4880 0x88 means "Compressed Data Packet", I was instead expecting 0x82 for "Signature Packet" !? The first octet (byte) of a packet contains the "packet tag", and determines how large the rest of the packet header is: https://tools.ietf.org/html/rfc4880#section-4.2 0x88 is (in binary): 10001000b aligned with bit location index: 76543210 <- bit index 10001000 <- bit value so bit 7 is 1: that's good. bit 6 is 0: this is an old-format packet. since it's old-format: bits 5 through 2 are the packet tag: 0010b -- or 2 in decimal. (see https://tools.ietf.org/html/rfc4880#section-4.3) and bits 1 and 0 indicate how the old-format packet stores its length. in your case, that's 00b -- or 0 in decimal, indicating that there is a simple one-octet packet length that immediately follows this first octet that contains the length of the rest of the packet. make sense? How did you compute 0x82? If you're doing this sort of packet dissection, you might be interested in "gpg --list-packets" or in the tool "pgpdump", which provides a similar implementation. hth, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Wed Apr 6 10:13:16 2011 From: wk at gnupg.org (Werner Koch) Date: Wed, 06 Apr 2011 10:13:16 +0200 Subject: Including gpgme.h fails with i686-mingw-w64 In-Reply-To: <201104051843.50332.aheinecke@intevation.de> (Andre Heinecke's message of "Tue, 5 Apr 2011 18:43:50 +0200") References: <201104051011.03106.aheinecke@intevation.de> <87hbacae6r.fsf@vigenere.g10code.de> <201104051843.50332.aheinecke@intevation.de> Message-ID: <874o6bajc3.fsf@vigenere.g10code.de> On Tue, 5 Apr 2011 18:43, aheinecke at intevation.de said: > I understand your point about making as few assumptions as possible and > defining your own types. But wouldn't it then be better named gpgme_ssize_t ? We once changed the gpgme data functions to be similar to the standard IO functions. Thus we need ssize_t and can't use a custom type - such a custom size would shift the problem to the application which needs to see how to match gpgme_size_t and the standard ssize_t. The whole point of the API change was to make using gpgme easier. > Can there be a check if ssize_t is already defined instead of having a > conflicting definition of a system type in a header file? There should be one but wait ... I just checked and noticed that it is hardwired in gpgme.h. For other types, like socklen_t we use a configure test. Having said this, I reconsider and will add a configure test. Thus if gpgme and the application are built on the same platform (or under Windows the same version of the toolchain), it should work. Libgcrypt also needs it. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From jeanjacquesbrucker at gmail.com Wed Apr 6 11:34:26 2011 From: jeanjacquesbrucker at gmail.com (Jean-Jacques Brucker) Date: Wed, 6 Apr 2011 11:34:26 +0200 Subject: sig binary format In-Reply-To: <4587B449-8D3F-48EC-98AE-08ED8FD2F2A7@jabberwocky.com> References: <201104051803.20375.jeanjacquesbrucker@gmail.com> <4587B449-8D3F-48EC-98AE-08ED8FD2F2A7@jabberwocky.com> Message-ID: <201104061134.26782.jeanjacquesbrucker@gmail.com> Thank you David and Daniel. (I read the RCF too fast, some details are a bit complicated...) -- Jean-Jacques B. Le mardi 5 avril 2011 19:29:00, vous avez ?crit : > On Apr 5, 2011, at 12:03 PM, Jean-Jacques Brucker wrote: > > > > > Hi, I have a question concerning the first octet of *.sig file (created with --detach-sign option). > > > > I have see almost data match section 5.2.3. of the RFC4880, but i am asking me why is the first octet of a *.sig file (packet tag) 0x88 ? > > According to section 4.3 of RFC4880 0x88 means "Compressed Data Packet", I was instead expecting 0x82 for "Signature Packet" !? > > 0x88 means old-style signature packet. 0x88 == 10001000. Bit 6 is not set, so its an old-style tag. The relevant bits to indicate a packet type in an old-style tag are bits 5 through 2, so 0010. 0010 == 2, and 2 is a signature packet. > > David > > From wk at gnupg.org Wed Apr 6 16:00:07 2011 From: wk at gnupg.org (Werner Koch) Date: Wed, 06 Apr 2011 16:00:07 +0200 Subject: Including gpgme.h fails with i686-mingw-w64 In-Reply-To: <874o6bajc3.fsf@vigenere.g10code.de> (Werner Koch's message of "Wed, 06 Apr 2011 10:13:16 +0200") References: <201104051011.03106.aheinecke@intevation.de> <87hbacae6r.fsf@vigenere.g10code.de> <201104051843.50332.aheinecke@intevation.de> <874o6bajc3.fsf@vigenere.g10code.de> Message-ID: <87mxk38opk.fsf@vigenere.g10code.de> Hi, I spend quite some time on this thing and started to prepare the build system for W64 (i.e. 64 bit W32 API). (It does not yet work because we need to change libgpg-error and libassuan also.) The MS specs say that ssize_t is defined as LONG_PTR and LONG_PTR is defined as long for 32 bit and as __int64 for 64 bit. Thus mingw does not get it right for 32 bit platforms where they typedef it as an int. They should have typedef'd it as long to be compatible to MSC and with tyhe specs. A workaround would be to pass _SSIZE_T_DEFINED to gcc. But that is an mingw internal macro, thus we shouldn't use it. You may want to fix mingw. I have not yet build all libs with the new mingw; I will eventually do that and thus need to come up with solution. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From jeanjacquesbrucker at gmail.com Thu Apr 7 21:23:31 2011 From: jeanjacquesbrucker at gmail.com (Jean-Jacques Brucker) Date: Thu, 7 Apr 2011 21:23:31 +0200 Subject: I d like to have multiple signing key in my certificate Message-ID: <201104072123.36741.jeanjacquesbrucker@gmail.com> Hi, I wanted to hold multiple signing key in my certificate, so I created 2 sub-keys with the sign flag. But I am unable to choose the key I want to use to sign : I have tried to specify the signing key I want to use with the --local-user option, eg.: $ gpg2 --detach-sign -u 96193F28 M.C.jpg $ gpg2 --detach-sign -u 7CFD0EC7 M.C.jpg But both signatures use the last signing key in my certificate. (ie. 7CFD0EC7). Is there a way to tel gpg (i still use v. 2.0.13... i will compile the git version soon) to sign with a specific key in a certificate ? Thx. ---- I have an other question, but concerning the RFC4880 : There is a lot of reserved subpacket type for signature. Why so many ? In fact I would like to make signing chain, there is a subpacket type for "Issuer", but none for "Recipient" which make sense in a signing chain. Was a reserved type used for "Recipient" which we could reuse for signing chain ? (17 ?) (I see the subpacket type for embedded signature but it is useless for what I'd like to do). ---- BEGIN of the RFC4880 extract ---- ;-) The value of the subpacket type octet may be: 0 = Reserved 1 = Reserved 2 = Signature Creation Time 3 = Signature Expiration Time 4 = Exportable Certification 5 = Trust Signature 6 = Regular Expression Callas, et al Standards Track [Page 25] RFC 4880 OpenPGP Message Format November 2007 7 = Revocable 8 = Reserved 9 = Key Expiration Time 10 = Placeholder for backward compatibility 11 = Preferred Symmetric Algorithms 12 = Revocation Key 13 = Reserved 14 = Reserved 15 = Reserved 16 = Issuer 17 = Reserved 18 = Reserved 19 = Reserved 20 = Notation Data 21 = Preferred Hash Algorithms 22 = Preferred Compression Algorithms 23 = Key Server Preferences 24 = Preferred Key Server 25 = Primary User ID 26 = Policy URI 27 = Key Flags 28 = Signer's User ID 29 = Reason for Revocation 30 = Features 31 = Signature Target 32 = Embedded Signature 100 To 110 = Private or experimental ---- END of the RFC4880 extract ---- Thx for all. -- Jean-Jacques B. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 230 bytes Desc: This is a digitally signed message part. URL: From dshaw at jabberwocky.com Thu Apr 7 21:46:50 2011 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 7 Apr 2011 15:46:50 -0400 Subject: I d like to have multiple signing key in my certificate In-Reply-To: <201104072123.36741.jeanjacquesbrucker@gmail.com> References: <201104072123.36741.jeanjacquesbrucker@gmail.com> Message-ID: On Apr 7, 2011, at 3:23 PM, Jean-Jacques Brucker wrote: > Hi, I wanted to hold multiple signing key in my certificate, so I created 2 sub-keys with the sign flag. But I am unable to choose the key I want to use to sign : I have tried to specify the signing key I want to use with the --local-user option, eg.: > > $ gpg2 --detach-sign -u 96193F28 M.C.jpg > $ gpg2 --detach-sign -u 7CFD0EC7 M.C.jpg > > But both signatures use the last signing key in my certificate. (ie. 7CFD0EC7). > > Is there a way to tel gpg (i still use v. 2.0.13... i will compile the git version soon) to sign with a specific key in a certificate ? Yes. Add an ! (exclamation point) after the key number you want. For example: $ gpg2 --detach-sign -u 96193F28! M.C.jpg $ gpg2 --detach-sign -u 7CFD0EC7! M.C.jpg > I have an other question, but concerning the RFC4880 : There is a lot of reserved subpacket type for signature. Why so many ? > In fact I would like to make signing chain, there is a subpacket type for "Issuer", but none for "Recipient" which make sense in a signing chain. Was a reserved type used for "Recipient" which we could reuse for signing chain ? (17 ?) Reserved in this context pretty much means reserved so that nobody uses it (i.e. the numbers were in use at one point, and marking them reserved ensures that nobody accidentally makes a new subpacket that conflicts). If a new subpacket is defined, we'd number it after 32. Perhaps someday we'll be forced to reallocate the reserved numbers, but we're nowhere near the need for that yet. David From John at enigmail.net Thu Apr 7 21:50:22 2011 From: John at enigmail.net (John Clizbe) Date: Thu, 07 Apr 2011 14:50:22 -0500 Subject: I d like to have multiple signing key in my certificate In-Reply-To: <201104072123.36741.jeanjacquesbrucker@gmail.com> References: <201104072123.36741.jeanjacquesbrucker@gmail.com> Message-ID: <4D9E157E.5080407@enigmail.net> Jean-Jacques Brucker wrote: > Hi, I wanted to hold multiple signing key in my certificate, so I created 2 sub-keys with the sign flag. But I am unable to choose the key I want to use to sign : I have tried to specify the signing key I want to use with the --local-user option, eg.: > > $ gpg2 --detach-sign -u 96193F28 M.C.jpg > $ gpg2 --detach-sign -u 7CFD0EC7 M.C.jpg > > But both signatures use the last signing key in my certificate. (ie. 7CFD0EC7). > > Is there a way to tell gpg (i still use v. 2.0.13... i will compile the git > version soon) to sign with a specific key in a certificate ? IIRC, GnuPG will use the newest valid capable subkey to sign. From the man papge: > Note that you can append an exclamation mark (!) to key IDs or finger- > prints. This flag tells GnuPG to use the specified primary or sec- > ondary key and not to try and calculate which primary or secondary key > to use. So your example commands become: $ gpg2 --detach-sign -u 0x96193F28! M.C.jpg $ gpg2 --detach-sign -u 0x7CFD0EC7! M.C.jpg -John -- John P. Clizbe Inet:John (a) Mozilla-Enigmail.org FSF Assoc #995 / FSFE Fellow #1797 hkp://keyserver.gingerbear.net or mailto:pgp-public-keys at gingerbear.net?subject=HELP Q:"Just how do the residents of Haiku, Hawai'i hold conversations?" A:"An odd melody / island voices on the winds / surplus of vowels" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 886 bytes Desc: OpenPGP digital signature URL: From mailinglisten at hauke-laging.de Thu Apr 7 21:30:20 2011 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Thu, 7 Apr 2011 21:30:20 +0200 Subject: I d like to have multiple signing key in my certificate In-Reply-To: <201104072123.36741.jeanjacquesbrucker@gmail.com> References: <201104072123.36741.jeanjacquesbrucker@gmail.com> Message-ID: <201104072130.21371.mailinglisten@hauke-laging.de> Am Donnerstag 07 April 2011 21:23:31 schrieb Jean-Jacques Brucker: > But I am unable to choose the key I want to use to sign : So was I. :-) > $ gpg2 --detach-sign -u 96193F28 M.C.jpg > $ gpg2 --detach-sign -u 7CFD0EC7 M.C.jpg > > But both signatures use the last signing key in my certificate. (ie. > 7CFD0EC7). > > Is there a way to tel gpg (i still use v. 2.0.13... i will compile the git > version soon) to sign with a specific key in a certificate ? Quote from the man page: "When using gpg an exclamation mark (!) may be appended to force using the specified primary or secondary key and not to try and calculate which primary or secondary key to use." Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 555 bytes Desc: This is a digitally signed message part. URL: From marcus.brinkmann at ruhr-uni-bochum.de Fri Apr 8 22:56:41 2011 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 8 Apr 2011 22:56:41 +0200 Subject: ERROR: _gpgme_io_set_close_notify: error: Invalid argument In-Reply-To: <5EB56C65-A588-4074-9A92-6C6D5F6A260A@gmx.net> References: <5EB56C65-A588-4074-9A92-6C6D5F6A260A@gmx.net> Message-ID: <4D9F7689.1060402@ruhr-uni-bochum.de> On 02/08/2011 02:55 PM, mbo wrote: > If we run this python script direcly in the command line, everything works fine. If we call the python script within freeswitch (www.freeswitch.org) using the mod_python module, we receive the following debug output, when the environment variable GPGME_DEBUG is set to ?9:/tmp?: > > ... > gpgme_op_keylist_start: enter: ctx=0x7fcd8c2078c0, pattern=B9F2747A, secret_only=0 > GPGME 2011-02-07 21:40:58 <0x3b06> _gpgme_io_pipe: enter: filedes=0x7fcd8c1e5bc8, inherit_idx=1 (GPGME uses it for reading) > GPGME 2011-02-07 21:40:58 <0x3b06> _gpgme_io_pipe: leave: read=0x1a5, write=0x1a6 > GPGME 2011-02-07 21:40:58 <0x3b06> _gpgme_io_set_close_notify: enter: fd=0x1a5, close_handler=0x7fcd84074420/0x7fcd8c1e5ba0 > GPGME 2011-02-07 21:40:58 <0x3b06> _gpgme_io_set_close_notify: error: Invalid argument This looks bogus. Looking at the code path, _gpgme_io_set_close_notify on POSIX systems (as opposed to Windows) can only fail on calloc. And we allocate in 64 table entry incrementals which is not big at all. The other thing that is looking a bit unconventional is the number of open fds you have. With 0x1a6 that's 423, which is a bit on the largish side. Still, _gpgme_io_set_close_notify doesn't allocate fds, so that can't be it. Maybe strace/ltrace or gdb trace it to see why/where it's failing in the calloc. Thanks, Marcus From gniibe at fsij.org Fri Apr 15 11:17:25 2011 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 15 Apr 2011 18:17:25 +0900 Subject: Gnuk version 0.11 Message-ID: <4DA80D25.3030805@fsij.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Gnuk version 0.11 is out. Yes, I am alive in Japan. Gnuk is a software for USB Token which follows OpenPGP card protocol version 2. It runs on STM32 processor. Changes since 0.10 are minimal. One bug fix for Gnuk proper, and one bug fix for tool/dfuse.py. I start Gitweb for Gnuk, so that people can see development of Gnuk on the web. Download page of Gnuk is changed. Now, it is generated on the fly from Git repository, when requested. These days, Gnuk Token is my daily use. SSH remote login to server, signing Debian packages, and signing e-mail, everything works well. This e-mail is an example. Gnuk News: http://www.fsij.org/gnuk/ Gitweb: http://www.gniibe.org/gitweb?p=gnuk.git;a=summary Download: http://www.gniibe.org/download/ - -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJNqA0jAAoJEAC0Xr1Mp7q+hzwH/ApvoFJF0HOffUZzvXNCSIml QTF8mVWMf6K/LSTjKutpJrwtG44eynnu8bec9M+I120pjtKlR+fPRMhb5QlM4UNn rL8YP7A6AhkSBsX5lkd3ppQw6g1ac5yx88QgtgfDqEWAZqL2Yr3ku1olTt6YyOd+ ugcX8kirrSWc0rS/h3u9C7D/mcyFFeoxvcPPd+zpoE6+KEv22Tcshza+Gf3D3D/Q CWHdG6K1tj9zsn2m/VgwfsqoM46BS8oDH1vOp7jw3gIO1Xy1TLIixvfR5fL8egtB isknhnzBipPnej2g1EMWaiJHj1lcXT2tbY3At1nMeBGW0r4n8LW5p34Wp3oyFIU= =tDnE -----END PGP SIGNATURE----- From flameeyes at gmail.com Sun Apr 17 00:18:33 2011 From: flameeyes at gmail.com (Diego Elio =?ISO-8859-1?Q?Petten=F2?=) Date: Sun, 17 Apr 2011 00:18:33 +0200 Subject: SCUTE and library versioning Message-ID: <1302992313.2295.71.camel@raven.home.flameeyes.eu> Hi all, since it seems like my FSF assignment forms never reached FSF I guess I'll speak in text rather than code even though I have already a patch to solve the issue locally. Right now SCUTE installs as a standard, libtool versioned library; but versioning is usually provided for ABI compatibility, and libscute's ABI is supposed to be a standard PKCS#11 one. Avoiding the version should be well enough for this kind of library. I'd also suggest declaring it as installed on pkcs11dir so that it gets installed where other PKCS#11 providers are. -- Diego Elio Petten? ? Flameeyes http://blog.flameeyes.eu/ From wk at gnupg.org Wed Apr 20 16:47:52 2011 From: wk at gnupg.org (Werner Koch) Date: Wed, 20 Apr 2011 16:47:52 +0200 Subject: SCUTE and library versioning In-Reply-To: <1302992313.2295.71.camel@raven.home.flameeyes.eu> ("Diego Elio =?utf-8?Q?Petten=C3=B2=22's?= message of "Sun, 17 Apr 2011 00:18:33 +0200") References: <1302992313.2295.71.camel@raven.home.flameeyes.eu> Message-ID: <87liz5vv1j.fsf@vigenere.g10code.de> On Sun, 17 Apr 2011 00:18, flameeyes at gmail.com said: > since it seems like my FSF assignment forms never reached FSF I guess That is strange. Shall I complain about this? > Right now SCUTE installs as a standard, libtool versioned library; but > versioning is usually provided for ABI compatibility, and libscute's ABI > is supposed to be a standard PKCS#11 one. Avoiding the version should be Right. Marcus will take care of it. > well enough for this kind of library. I'd also suggest declaring it as > installed on pkcs11dir so that it gets installed where other PKCS#11 So, how is the the pkcs11dir defined? Is $(libdir)/pkcs11 always correct? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From flameeyes at gmail.com Tue Apr 26 16:36:08 2011 From: flameeyes at gmail.com (Diego Elio =?ISO-8859-1?Q?Petten=F2?=) Date: Tue, 26 Apr 2011 16:36:08 +0200 Subject: SCUTE and library versioning In-Reply-To: <87liz5vv1j.fsf@vigenere.g10code.de> References: <1302992313.2295.71.camel@raven.home.flameeyes.eu> <87liz5vv1j.fsf@vigenere.g10code.de> Message-ID: <1303828568.2367.44.camel@raven.home.flameeyes.eu> Il giorno mer, 20/04/2011 alle 16.47 +0200, Werner Koch ha scritto: > That is strange. Shall I complain about this? Thanks for taking care of it ? we should be (partially) set now ;) > > well enough for this kind of library. I'd also suggest declaring it as > > installed on pkcs11dir so that it gets installed where other PKCS#11 > > So, how is the the pkcs11dir defined? Is $(libdir)/pkcs11 always correct? I thought a bit more about it and it might not be the wisest thing to do indeed: if you only name the PKCS#11 module, you want to find it in the linker search path... and I doubt that many vendors have /usr/lib*/pkcs11 in their search path. Maybe it should just create a symlink to be in both places? -- Diego Elio Petten? ? Flameeyes http://blog.flameeyes.eu/ From flameeyes at gmail.com Tue Apr 26 16:35:56 2011 From: flameeyes at gmail.com (=?UTF-8?q?Diego=20Elio=20Petten=C3=B2?=) Date: Tue, 26 Apr 2011 16:35:56 +0200 Subject: [PATCH] gpgsm-gencert.sh: make sure not to abort after creating temp file. Message-ID: <1303828556-11574-1-git-send-email-flameeyes@gmail.com> Signed-off-by: Diego Elio Petten? --- tools/gpgsm-gencert.sh | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/tools/gpgsm-gencert.sh b/tools/gpgsm-gencert.sh index b209c8e..e7c812f 100755 --- a/tools/gpgsm-gencert.sh +++ b/tools/gpgsm-gencert.sh @@ -178,10 +178,10 @@ Key-Length: $KEY_LENGTH Key-Usage: $KEY_USAGE Name-DN: $NAME EOF -[ -n "$KEY_GRIP" ] && echo "Key-Grip: $KEY_GRIP" -[ -n "$EMAIL_ADDRESSES" ] && echo "$EMAIL_ADDRESSES" -[ -n "$DNS_ADDRESSES" ] && echo "$DNS_ADDRESSES" -[ -n "$URI_ADDRESSES" ] && echo "$URI_ADDRESSES" +[ -n "$KEY_GRIP" ] && echo "Key-Grip: $KEY_GRIP" || true +[ -n "$EMAIL_ADDRESSES" ] && echo "$EMAIL_ADDRESSES" || true +[ -n "$DNS_ADDRESSES" ] && echo "$DNS_ADDRESSES" || true +[ -n "$URI_ADDRESSES" ] && echo "$URI_ADDRESSES" || true ) > "$file_parameter" -- 1.7.5.rc1 From flameeyes at gmail.com Tue Apr 26 18:10:44 2011 From: flameeyes at gmail.com (Diego Elio =?ISO-8859-1?Q?Petten=F2?=) Date: Tue, 26 Apr 2011 18:10:44 +0200 Subject: Patches for scute Message-ID: <1303834244.2367.47.camel@raven.home.flameeyes.eu> Since at least the PDF copy of my assignment forms are available I spent a bit of time today to fix the issues I found with scute, and polished it for the small things at least. Since one of the patches removes a bunch of files from the repository (those that are re-generated or copied by autoreconf), sending them as email is not going to work, so I instead pushed it on a git mirror of scute I created on gitorious (the main repositories are synced every three hours through my vserver, I do this for a number of other projects as well). git://gitorious.org/~flameeyes/gnupg-org/flameeyes-scute.git Diego Elio Petten? (5): build-sys: build the PKCS#11 provider like a plugin. build-sys: remove files that are installed/symlinked by autoreconf. Add a .gitignore file to ignore generated files. build-sys: use libtool's -export-symbols to filter the exported interface. Add missing static modifiers to functions only used in a single unit. HTH! -- Diego Elio Petten? ? Flameeyes http://blog.flameeyes.eu/ From stavros.daliakopoulos at gmail.com Tue Apr 26 23:54:40 2011 From: stavros.daliakopoulos at gmail.com (stavros daliakopoulos) Date: Wed, 27 Apr 2011 00:54:40 +0300 Subject: greek translation gnugp Message-ID: Dear All, I updated the Greek translation of gnupg and I would like to have it added to the gnupg repository. I located the gnupg-i18n at gnupg.org mailing list at http://lists.gnupg.org/pipermail/gnupg-i18n/ however it appears that it is inactive. A request to add the Vietnamese translation in February was unanswered. The Greek translation is found at http://launchpadlibrarian.net/70470353/po_gnupg-el.po and it should replace the file at po/el.po (el: Language code for Greek). Thanks in advance, Stavros -------------- next part -------------- An HTML attachment was scrubbed... URL: From ismail at namtrac.org Wed Apr 27 15:39:00 2011 From: ismail at namtrac.org (=?UTF-8?B?xLBzbWFpbCBEw7ZubWV6?=) Date: Wed, 27 Apr 2011 15:39:00 +0200 Subject: gpgme 1.30 fails when tested with gnupg 2.0.17 Message-ID: Hi; Testing gpgme 1.30 with gnupg 2.0.17 fails in t-encrypt-sign test: Wrong hash algorithm reported: 3 FAIL: t-encrypt-sign The test expects SHA1 but the message is signed with RMD160. According to http://bugs.gentoo.org/show_bug.cgi?id=362645 test passes with gnupg 2.0.16 which I didn't verify myself personally. Only suspicious commit is http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commitdiff;h=398e686085fd40ea3d20e99ff5c83ef27626f1abbut I am not sure if its the culprit. Regards, ismail -------------- next part -------------- An HTML attachment was scrubbed... URL: From superpacko at gmail.com Wed Apr 27 17:50:35 2011 From: superpacko at gmail.com (Sebastian) Date: Wed, 27 Apr 2011 12:50:35 -0300 Subject: enarmor_file function doesnt close input file Message-ID: Im working on a proyect where we need to tweak some GPG functionality, since we need to use NSS crypto engine. Since we want to support armoring, im using the function enarmor_file from "dearmor.c". The things is that after armoring the given file, as the function creates a new file with the extension ".asc" i want to delete the previous file and rename the ".asc" to the original name. When i try to remove(file) i get a permission denied error. I've made a test, and tried to remove the file before armoring, and it worked fine, so i guess the armoring function (which is intact, no changes made) is not closing the file. here's an ej: file to armor-> file.dat armored file that enarmor_file function creates-> file.dat.asc what i want to do is (after armoring): remove file.dat --> i get a permission denied rename file.dat.asc as file.dat im using GPG's portable version (1.4) thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcus.brinkmann at ruhr-uni-bochum.de Thu Apr 28 00:26:24 2011 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 28 Apr 2011 00:26:24 +0200 Subject: gpgme 1.30 fails when tested with gnupg 2.0.17 In-Reply-To: References: Message-ID: <4DB89810.10709@ruhr-uni-bochum.de> On 04/27/2011 03:39 PM, ?smail D?nmez wrote: > Hi; > > Testing gpgme 1.30 with gnupg 2.0.17 fails in t-encrypt-sign test: > > Wrong hash algorithm reported: 3 > FAIL: t-encrypt-sign > > The test expects SHA1 but the message is signed with RMD160. According to > http://bugs.gentoo.org/show_bug.cgi?id=362645 test passes with gnupg 2.0.16 > which I didn't verify myself personally. > > Only suspicious commit is > http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commitdiff;h=398e686085fd40ea3d20e99ff5c83ef27626f1abbut > I am not sure if its the culprit. Yeah I know, I checked in an update to the test suite yesterday, which is targeted towards GnuPG 2.1, and that should fix this one (but as I didn't test GnuPG 2.0 yet, there may be other problems remaining). Thanks, Marcus From ismail at namtrac.org Thu Apr 28 08:31:25 2011 From: ismail at namtrac.org (=?UTF-8?B?xLBzbWFpbCBEw7ZubWV6?=) Date: Thu, 28 Apr 2011 08:31:25 +0200 Subject: gpgme 1.30 fails when tested with gnupg 2.0.17 In-Reply-To: <4DB89810.10709@ruhr-uni-bochum.de> References: <4DB89810.10709@ruhr-uni-bochum.de> Message-ID: Hi; On Thu, Apr 28, 2011 at 12:26 AM, Marcus Brinkmann < marcus.brinkmann at ruhr-uni-bochum.de> wrote: > On 04/27/2011 03:39 PM, ?smail D?nmez wrote: > > Hi; > > > > Testing gpgme 1.30 with gnupg 2.0.17 fails in t-encrypt-sign test: > > > > Wrong hash algorithm reported: 3 > > FAIL: t-encrypt-sign > > > > The test expects SHA1 but the message is signed with RMD160. According to > > http://bugs.gentoo.org/show_bug.cgi?id=362645 test passes with gnupg > 2.0.16 > > which I didn't verify myself personally. > > > > Only suspicious commit is > > > http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commitdiff;h=398e686085fd40ea3d20e99ff5c83ef27626f1abbut > > I am not sure if its the culprit. > > Yeah I know, I checked in an update to the test suite yesterday, which is > targeted towards GnuPG 2.1, and that should fix this one (but as I didn't > test > GnuPG 2.0 yet, there may be other problems remaining). > I cherry picked the t-encrypt-sign part, thanks! Regards, ismail -------------- next part -------------- An HTML attachment was scrubbed... URL: From freebsd-listen at fabiankeil.de Thu Apr 28 19:20:09 2011 From: freebsd-listen at fabiankeil.de (Fabian Keil) Date: Thu, 28 Apr 2011 19:20:09 +0200 Subject: Issue1320: SIGBUS running `gpg-agent --daemon` Message-ID: <20110428192009.270936ae@fabiankeil.de> I ran into https://bugs.g10code.com/gnupg/issue1320 but apparently I'm not allowed to comment there. I think the problem is caused by this chunk from the gpgtar backport 4d364ade61952b7: diff --git a/common/estream.c b/common/estream.c index 4015905..3ab68b5 100644 --- a/common/estream.c +++ b/common/estream.c [...] @@ -368,15 +453,18 @@ static int es_init_do (void) { -#ifdef HAVE_PTH static int initialized; if (!initialized) { +#ifdef HAVE_PTH if (!pth_init () && errno != EPERM ) return -1; if (pth_mutex_init (&estream_list_lock)) initialized = 1; - } +#else + initialized = 1; #endif + atexit (es_deinit); + } return 0; } In the "gpg-agent --daemon" case, main() calls pth_kill() after the client has been forked, so when es_deinit() is called on exit, acquiring the estream_list_lock seems to cause pth to dereference a pointer located in a memory region that has previously been free()'d. The attached patch (against 2.0.17) prevents the crashes by not locking the list when flushing the content through es_deinit(). I created it based on the assumption that locking isn't necessary in that situation, is that correct? Fabian -------------- next part -------------- A non-text attachment was scrubbed... Name: gnupg-2.0.17-Do-not-lock-the-es_list-when-flushing-it-from-es_dei.patch Type: text/x-patch Size: 1459 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: not available URL: From tsukebumi at gmail.com Thu Apr 28 22:56:44 2011 From: tsukebumi at gmail.com (dabicho) Date: Thu, 28 Apr 2011 15:56:44 -0500 Subject: Verify problem with gpgme Message-ID: Hi. I am trying to write a small application whose task is to execute a script only if it is signed by a specific key. How would you go about doing it? I thought I could use gpgme to verify it and check if the signature's key has the right name, comment and mail address, but I have not found a way to read the key data. Also, I suppose there must be a better way. Any suggestions? Thank you. From arfrever.fta at gmail.com Thu Apr 28 23:00:11 2011 From: arfrever.fta at gmail.com (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 28 Apr 2011 23:00:11 +0200 Subject: gpgme 1.30 fails when tested with gnupg 2.0.17 In-Reply-To: <4DB89810.10709@ruhr-uni-bochum.de> References: <4DB89810.10709@ruhr-uni-bochum.de> Message-ID: <201104282300.11618.Arfrever.FTA@gmail.com> 2011-04-28 00:26:24 Marcus Brinkmann napisa?(a): > On 04/27/2011 03:39 PM, ?smail D?nmez wrote: > > Hi; > > > > Testing gpgme 1.30 with gnupg 2.0.17 fails in t-encrypt-sign test: > > > > Wrong hash algorithm reported: 3 > > FAIL: t-encrypt-sign > > > > The test expects SHA1 but the message is signed with RMD160. According to > > http://bugs.gentoo.org/show_bug.cgi?id=362645 test passes with gnupg 2.0.16 > > which I didn't verify myself personally. > > > > Only suspicious commit is > > http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commitdiff;h=398e686085fd40ea3d20e99ff5c83ef27626f1abbut > > I am not sure if its the culprit. > > Yeah I know, I checked in an update to the test suite yesterday, which is > targeted towards GnuPG 2.1, and that should fix this one (but as I didn't test > GnuPG 2.0 yet, there may be other problems remaining). Backporting of whole http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=commitdiff;h=43f38db1afe9830b888076adeec1eec21f32335c to gpgme 1.3.0 fixes t-encrypt-sign, but breaks t-import: ... PASS: t-export Unexpected status 17 FAIL: t-import PASS: t-trustlist ... -- Arfrever Frehtes Taifersar Arahesis -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Fri Apr 29 10:27:22 2011 From: wk at gnupg.org (Werner Koch) Date: Fri, 29 Apr 2011 10:27:22 +0200 Subject: Issue1320: SIGBUS running `gpg-agent --daemon` In-Reply-To: <20110428192009.270936ae@fabiankeil.de> (Fabian Keil's message of "Thu, 28 Apr 2011 19:20:09 +0200") References: <20110428192009.270936ae@fabiankeil.de> Message-ID: <87r58lmpd8.fsf@vigenere.g10code.de> On Thu, 28 Apr 2011 19:20, freebsd-listen at fabiankeil.de said: > The attached patch (against 2.0.17) prevents the crashes by > not locking the list when flushing the content through es_deinit(). > I created it based on the assumption that locking isn't necessary in > that situation, is that correct? We keep on using estream via the log functions after pth_kill. Thus it is better to do a full fix. My approach is a pth_kill wrapper and to protect all pth calls in estream.c. Can you please try ce98524? For 2.1 we may not need it because the plan is to drop pth and use native threads instead. Thanks, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From freebsd-listen at fabiankeil.de Fri Apr 29 15:50:30 2011 From: freebsd-listen at fabiankeil.de (Fabian Keil) Date: Fri, 29 Apr 2011 15:50:30 +0200 Subject: Issue1320: SIGBUS running `gpg-agent --daemon` In-Reply-To: <87r58lmpd8.fsf@vigenere.g10code.de> References: <20110428192009.270936ae@fabiankeil.de> <87r58lmpd8.fsf@vigenere.g10code.de> Message-ID: <20110429155030.3342b9a3@fabiankeil.de> Werner Koch wrote: > On Thu, 28 Apr 2011 19:20, freebsd-listen at fabiankeil.de said: > > > The attached patch (against 2.0.17) prevents the crashes by > > not locking the list when flushing the content through es_deinit(). > > I created it based on the assumption that locking isn't necessary in > > that situation, is that correct? > > We keep on using estream via the log functions after pth_kill. Thus it > is better to do a full fix. My approach is a pth_kill wrapper and to > protect all pth calls in estream.c. > > Can you please try ce98524? Works for me, thanks. Fabian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: not available URL: