From flameeyes at gmail.com Wed Jun 1 17:40:27 2011 From: flameeyes at gmail.com (Diego Elio =?ISO-8859-1?Q?Petten=F2?=) Date: Wed, 01 Jun 2011 17:40:27 +0200 Subject: dirmngr repository? Message-ID: <1306942827.2405.55.camel@raven.home.flameeyes.eu> Hello all, I was tracking down an issue with dirmngr today (underlinking: it uses functions from liblber but it doesn't link to it directly by default), and I noticed that there is no git repository for it. Is this intended or just there hasn't been work on dirmngr recently? Thanks, -- Diego Elio Petten? ? Flameeyes http://blog.flameeyes.eu/ From wk at gnupg.org Fri Jun 3 09:00:27 2011 From: wk at gnupg.org (Werner Koch) Date: Fri, 03 Jun 2011 09:00:27 +0200 Subject: dirmngr repository? In-Reply-To: <1306942827.2405.55.camel@raven.home.flameeyes.eu> ("Diego Elio =?utf-8?Q?Petten=C3=B2=22's?= message of "Wed, 01 Jun 2011 17:40:27 +0200") References: <1306942827.2405.55.camel@raven.home.flameeyes.eu> Message-ID: <87boyfz9f8.fsf@vigenere.g10code.de> On Wed, 1 Jun 2011 17:40, flameeyes at gmail.com said: > I was tracking down an issue with dirmngr today (underlinking: it uses > functions from liblber but it doesn't link to it directly by default), As you know, these functions are sometimes found in libldap and sometimes in liblber and iirc in some other as well. GnuPG uses quite some configure code to test for this. I am not sure about dirmngr. > and I noticed that there is no git repository for it. That's right. Dirmngr has been merged with GnuPG. The GnuPG master has a Dirmngr directory which has the most up to date code. We will only do security updates for the old Dirmngr. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From andreas at metaspace.dk Mon Jun 6 14:44:57 2011 From: andreas at metaspace.dk (Andreas Hindborg) Date: Mon, 06 Jun 2011 14:44:57 +0200 Subject: gpg-agent and launchd In-Reply-To: References: Message-ID: <4DECCBC9.8020201@metaspace.dk> Hi St?phane, On 21/03/08 18.32, St?phane Corth?sy wrote: > I modified gpg-agent 2.0.8 to add support for launchd: I had to modify > only gpg-agent.c. > I added a new command, --launchd, which is exclusive with --daemon and > --server, and does currently the following: > - it creates sockets, like in daemon mode > - it does not fork - this is forbidden > - it does not run any program on the command line - this is forbidden > - it does not print the environment variables (though it might, maybe) > - it passes back to launchd the environment variables; launchd will make > all user processes inherit of these variables > - it does not detach from tty (I don't know what this means and what are > the consequences) > - it doesn't chdir("/"), but the launchd plist sets the working dir to > "/", so it should be equivalent > - it removes the environment variables from launchd, when terminating > > Is there any interest here to review and maybe include that code > (available on demand) into gpg-agent? I have just begun to use gpg-agent on OS X, and I would also like to see gpg-agent managed by launchd. It has been 3 years since your post. Do you still have the changes? I would like to see a patch. I am using gpg-agent from macports. Perhaps we can create a patch that can be enabled as a variant in the portfile? Best regards, Andreas From wk at gnupg.org Tue Jun 7 10:04:28 2011 From: wk at gnupg.org (Werner Koch) Date: Tue, 07 Jun 2011 10:04:28 +0200 Subject: gpg-agent and launchd In-Reply-To: <4DECCBC9.8020201@metaspace.dk> (Andreas Hindborg's message of "Mon, 06 Jun 2011 14:44:57 +0200") References: <4DECCBC9.8020201@metaspace.dk> Message-ID: <87aaduvzhv.fsf@vigenere.g10code.de> Hi, FWIW, the default with GnuPG 2.1 will be to launch the gpg-agent on demand. There won't be any need to start it in the xsession and it will automagically be restarted if needed. There is a 2.1. beta available and Marcus recently succeeded in building it for Mac OS. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From benjamin at py-soft.co.uk Wed Jun 8 18:16:51 2011 From: benjamin at py-soft.co.uk (Benjamin Donnachie) Date: Wed, 8 Jun 2011 10:16:51 -0600 Subject: gpg-agent and launchd In-Reply-To: <4DECCBC9.8020201@metaspace.dk> References: <4DECCBC9.8020201@metaspace.dk> Message-ID: On 6 June 2011 06:44, Andreas Hindborg wrote: > I have just begun to use gpg-agent on OS X, and I would also like to see > gpg-agent managed by launchd. MacGPG2, which merged with GPGTools, runs gpg-agent under launchd control using a modified version of St?phane's patch. Source available from github - https://github.com/GPGTools/MacGPG2 Ben From matthias at nlinux.org Tue Jun 14 18:32:11 2011 From: matthias at nlinux.org (Matthias Klumpp) Date: Tue, 14 Jun 2011 18:32:11 +0200 Subject: Strange =?UTF-8?Q?gpgme=5Fsigsum=5Ft=20value=20in=20gpgme=20=28bug=3F=29?= Message-ID: Hi! I'm new to GPGMe, so this maybe is a foolish question, but I stumbled upon a very weird behavior of GPGMe, which cause my application to act very, very weird :P I want to verify a signature, so I call result = gpgme_op_verify (ctx, sig, dt, NULL); and fetch the result as _gpgme_op_verify_result*. Then I get the sigsum (gpgme_sigsum_t) from the results: result->signatures->summary I expect one of these values for the sigsum: GPGME_SIGSUM_VALID = 0x0001, /* The signature is fully valid. */ GPGME_SIGSUM_GREEN = 0x0002, /* The signature is good. */ GPGME_SIGSUM_RED = 0x0004, /* The signature is bad. */ GPGME_SIGSUM_KEY_REVOKED = 0x0010, /* One key has been revoked. */ GPGME_SIGSUM_KEY_EXPIRED = 0x0020, /* One key has expired. */ GPGME_SIGSUM_SIG_EXPIRED = 0x0040, /* The signature has expired. */ GPGME_SIGSUM_KEY_MISSING = 0x0080, /* Can't verify: key missing. */ GPGME_SIGSUM_CRL_MISSING = 0x0100, /* CRL not available. */ GPGME_SIGSUM_CRL_TOO_OLD = 0x0200, /* Available CRL is too old. */ GPGME_SIGSUM_BAD_POLICY = 0x0400, /* A policy was not met. */ GPGME_SIGSUM_SYS_ERROR = 0x0800 /* A system error occured. */ But instead I get 0x0003 as sigsum, which is not in the enum. This causes my application to malfunction. Is this a bug, or am I just doing it wrong? Kind regards Matthias Klumpp From matthias at nlinux.org Tue Jun 14 19:54:58 2011 From: matthias at nlinux.org (Matthias Klumpp) Date: Tue, 14 Jun 2011 19:54:58 +0200 Subject: Strange =?UTF-8?Q?gpgme=5Fsigsum=5Ft=20value=20in=20gpgme=20=28bug=3F?= =?UTF-8?Q?=29?= In-Reply-To: <4DF79CE1.4030407@fifthhorseman.net> References: <4DF79CE1.4030407@fifthhorseman.net> Message-ID: <12cf1147ba0b0d6924af80c278df14e0@mb8-2.1blu.de> On Tue, 14 Jun 2011 13:39:45 -0400, Daniel Kahn Gillmor wrote: > On 06/14/2011 12:32 PM, Matthias Klumpp wrote: >> Hi! >> I'm new to GPGMe, so this maybe is a foolish question, but I stumbled >> upon >> a very weird behavior of GPGMe, which cause my application to act very, >> very weird :P >> [...] >> Is this a bug, or am I just doing it wrong? > > I believe the field is a bitfield, so the flags are additive. > > 0x03 == 0x02 + 0x01 > > So that means GPGME_SIGSUM_VALID + GPGME_SIGSUM_GREEN > > hth, Oo... Thanks! I'm using GPGMe via Vala, maybe this brought me on the wrong track (the vapi file for GPGMe is buggy, I'm ficing it at time) Sorry for the noise and thanks again for your help! --- Matthias From cswiger at mac.com Tue Jun 14 19:37:36 2011 From: cswiger at mac.com (Chuck Swiger) Date: Tue, 14 Jun 2011 10:37:36 -0700 Subject: Strange gpgme_sigsum_t value in gpgme (bug?) In-Reply-To: References: Message-ID: <9FB59B00-EB30-4EC6-9B75-ED61196E2ECD@mac.com> On Jun 14, 2011, at 9:32 AM, Matthias Klumpp wrote: [ ... ] > But instead I get 0x0003 as sigsum, which is not in the enum. This causes > my application to malfunction. > Is this a bug, or am I just doing it wrong? Yes, you're doing it wrong. That's not an enum, that's a bitfield. Test for individual flags being set via (sigsum & GPGME_SIGSUM_VALID). Regards, -- -Chuck From dkg at fifthhorseman.net Tue Jun 14 19:39:45 2011 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 14 Jun 2011 13:39:45 -0400 Subject: Strange gpgme_sigsum_t value in gpgme (bug?) In-Reply-To: References: Message-ID: <4DF79CE1.4030407@fifthhorseman.net> On 06/14/2011 12:32 PM, Matthias Klumpp wrote: > Hi! > I'm new to GPGMe, so this maybe is a foolish question, but I stumbled upon > a very weird behavior of GPGMe, which cause my application to act very, > very weird :P > I want to verify a signature, so I call > result = gpgme_op_verify (ctx, sig, dt, NULL); > and fetch the result as _gpgme_op_verify_result*. > Then I get the sigsum (gpgme_sigsum_t) from the results: > result->signatures->summary > I expect one of these values for the sigsum: > GPGME_SIGSUM_VALID = 0x0001, /* The signature is fully valid. > */ > GPGME_SIGSUM_GREEN = 0x0002, /* The signature is good. */ > GPGME_SIGSUM_RED = 0x0004, /* The signature is bad. */ > GPGME_SIGSUM_KEY_REVOKED = 0x0010, /* One key has been revoked. */ > GPGME_SIGSUM_KEY_EXPIRED = 0x0020, /* One key has expired. */ > GPGME_SIGSUM_SIG_EXPIRED = 0x0040, /* The signature has expired. */ > GPGME_SIGSUM_KEY_MISSING = 0x0080, /* Can't verify: key missing. */ > GPGME_SIGSUM_CRL_MISSING = 0x0100, /* CRL not available. */ > GPGME_SIGSUM_CRL_TOO_OLD = 0x0200, /* Available CRL is too old. */ > GPGME_SIGSUM_BAD_POLICY = 0x0400, /* A policy was not met. */ > GPGME_SIGSUM_SYS_ERROR = 0x0800 /* A system error occured. */ > > But instead I get 0x0003 as sigsum, which is not in the enum. This causes > my application to malfunction. > Is this a bug, or am I just doing it wrong? I believe the field is a bitfield, so the flags are additive. 0x03 == 0x02 + 0x01 So that means GPGME_SIGSUM_VALID + GPGME_SIGSUM_GREEN 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 gniibe at fsij.org Wed Jun 15 02:07:10 2011 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 15 Jun 2011 09:07:10 +0900 Subject: Gnuk version 0.13 Message-ID: <1308096430.1823.11.camel@latx1.gniibe.org> Hi, Gnuk version 0.13 is out. Gnuk is software implementation of a USB token for GNU Privacy Guard. Gnuk supports OpenPGP card protocol version 2, and it runs on STM32 processor. Highlights are (in gnuk-0.13/NEWS): * Improved RSA routine. About 20% speed improvement. * New tool: hub_ctrl. It is a Python implementation ported from original C implementation. It is useful for development of USB target if you have a good hub. You can power off/on the port to reset Gnuk Token. Update of the FAQ: Q2: How long does it take for digital signing? A2: It takes a second and a half or so. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part URL: From bernhard at intevation.de Thu Jun 16 11:25:01 2011 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 16 Jun 2011 11:25:01 +0200 Subject: gpgme-config largefile support missmatch? Message-ID: <201106161125.04608.bernhard@intevation.de> gpgme-config --cflags does not output anything on my Debian Lenny systems with Package: libgpgme11-dev, Version: 1.3.0-0kk3 but, if I try to compile a simple application, I get an error about largefile support missing: cat foo.c #include int main() { } gcc -c foo.c `gpgme-config --cflags` In file included from foo.c:1: /usr/include/gpgme.h:89:2: error: #error GPGME was compiled with _FILE_OFFSET_BITS = 64, please see the section "Largefile support (LFS)" in the GPGME manual. Any hints where the issues comes from? I am not very proficient with the automake chain to debug this myself. Should I open an issue for it? Best, Bernhard -- Managing Director + Owner: www.Intevation.net <- A Free Software Company Kolabsys.com: Board Member FSFE.org: Founding GA Member 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: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Thu Jun 16 14:46:05 2011 From: wk at gnupg.org (Werner Koch) Date: Thu, 16 Jun 2011 14:46:05 +0200 Subject: gpgme-config largefile support missmatch? In-Reply-To: <201106161125.04608.bernhard@intevation.de> (Bernhard Reiter's message of "Thu, 16 Jun 2011 11:25:01 +0200") References: <201106161125.04608.bernhard@intevation.de> Message-ID: <87k4cmosfm.fsf@vigenere.g10code.de> On Thu, 16 Jun 2011 11:25, bernhard at intevation.de said: > Any hints where the issues comes from? I am not very proficient with > the automake chain to debug this myself. Should I open an issue for it? Unfortunately most linux systems support two ABIs (at least) One uses off_t with 32 bit and one with 64 bit. The gpgme ABI requires off_t and thus we compile for the most common off_t which is 64 bit these days. All common GUI frameworks do it the same way. To save the user from strange crashes gpgme detects such an ABI mismatch and print the error message you see. There is a long chapter in the gpgme manual explaining this; in short you should have a line AC_SYS_LARGEFILE in configure.ac. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From bernhard at intevation.de Thu Jun 16 15:44:12 2011 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 16 Jun 2011 15:44:12 +0200 Subject: gpgme-config largefile support missmatch? In-Reply-To: <87k4cmosfm.fsf@vigenere.g10code.de> References: <201106161125.04608.bernhard@intevation.de> <87k4cmosfm.fsf@vigenere.g10code.de> Message-ID: <201106161544.16546.bernhard@intevation.de> Werner, thanks for the prompt response. Am Donnerstag, 16. Juni 2011 14:46:05 schrieb Werner Koch: > On Thu, 16 Jun 2011 11:25, bernhard at intevation.de said: > > Any hints where the issues comes from? I am not very proficient with > > the automake chain to debug this myself. Should I open an issue for it? > There is a long chapter in the gpgme manual explaining this; in short > you should have a line > > ? AC_SYS_LARGEFILE > > in configure.ac. I did read the section in the gpgme manual before I had posted the question. As I understood it, either gpgme-config --cflags is wrong by not printing "-D_FILE_OFFSET_BITS=64 -DLARGEFILE_SOURCE=1" or the section in "Building the Source" is missleading that recommends: gcc -c foo.c `gpgme-config --cflags` if would need to hint upon that largefile options might also be necessary in addition. BTW: gpgme-config --help outputs the line [--thread={ pth pthread pthread}] shouldn't this be [--thread={ pth pthread}] ? Best, Bernhard -- Managing Director + Owner: www.Intevation.net <- A Free Software Company Kolabsys.com: Board Member FSFE.org: Founding GA Member 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: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From marcus.brinkmann at ruhr-uni-bochum.de Thu Jun 16 17:27:22 2011 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 16 Jun 2011 17:27:22 +0200 Subject: gpgme-config largefile support missmatch? In-Reply-To: <201106161544.16546.bernhard@intevation.de> References: <201106161125.04608.bernhard@intevation.de> <87k4cmosfm.fsf@vigenere.g10code.de> <201106161544.16546.bernhard@intevation.de> Message-ID: <4DFA20DA.6080507@ruhr-uni-bochum.de> On 06/16/2011 03:44 PM, Bernhard Reiter wrote: > I did read the section in the gpgme manual before I had posted the question. > > As I understood it, either gpgme-config --cflags is wrong > by not printing "-D_FILE_OFFSET_BITS=64 -DLARGEFILE_SOURCE=1" > or the section in "Building the Source" is missleading that recommends: > gcc -c foo.c `gpgme-config --cflags` > if would need to hint upon that largefile options might also be necessary > in addition. gpgme-config and largefile support are two different sections in the manual, and have nothing to do with each other. The reason is that the cflags to locate the header file are only relevant for that one source file. The largefile support however must be consistent across the whole application domain. It's worse than you think. For example, if two applications exchange file descriptors over a pipe, then both applications must agree on the largefile support in order to handle descriptors to large files correctly. No isolated compiler flag alone can ensure that. (BTW, if systems using for example dbus-daemon and descriptor passing over dbus channels get this right, it is probably by accident rather than by being conscious about the issue! POSIX/C programming has many pitfalls, many of them are quite obscure. Tread carefully.) Accidently compiling some files with and some files without largefile support would only make the matter more confusing. > BTW: gpgme-config --help > outputs the line > [--thread={ pth pthread pthread}] > shouldn't this be > [--thread={ pth pthread}] > ? It is correct here. Thanks, Marcus From marcus.brinkmann at ruhr-uni-bochum.de Thu Jun 16 17:37:58 2011 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 16 Jun 2011 17:37:58 +0200 Subject: Strange gpgme_sigsum_t value in gpgme (bug?) In-Reply-To: <12cf1147ba0b0d6924af80c278df14e0@mb8-2.1blu.de> References: <4DF79CE1.4030407@fifthhorseman.net> <12cf1147ba0b0d6924af80c278df14e0@mb8-2.1blu.de> Message-ID: <4DFA2356.8080005@ruhr-uni-bochum.de> On 06/14/2011 07:54 PM, Matthias Klumpp wrote: > On Tue, 14 Jun 2011 13:39:45 -0400, Daniel Kahn Gillmor > wrote: >> On 06/14/2011 12:32 PM, Matthias Klumpp wrote: >>> Hi! >>> I'm new to GPGMe, so this maybe is a foolish question, but I stumbled >>> upon >>> a very weird behavior of GPGMe, which cause my application to act very, >>> very weird :P >>> [...] >>> Is this a bug, or am I just doing it wrong? >> >> I believe the field is a bitfield, so the flags are additive. >> >> 0x03 == 0x02 + 0x01 >> >> So that means GPGME_SIGSUM_VALID + GPGME_SIGSUM_GREEN >> >> hth, > Oo... Thanks! I'm using GPGMe via Vala, maybe this brought me on the wrong > track (the vapi file for GPGMe is buggy, I'm ficing it at time) > Sorry for the noise and thanks again for your help! Well, in a sense, it's my fault, too, I shouldn't have made it an enum in the first place, but just constant #defines. Thanks, Marcus From wk at gnupg.org Thu Jun 16 18:48:52 2011 From: wk at gnupg.org (Werner Koch) Date: Thu, 16 Jun 2011 18:48:52 +0200 Subject: Strange gpgme_sigsum_t value in gpgme (bug?) In-Reply-To: <4DFA2356.8080005@ruhr-uni-bochum.de> (Marcus Brinkmann's message of "16 Jun 2011 17:37:58 +0200") References: <4DF79CE1.4030407@fifthhorseman.net> <12cf1147ba0b0d6924af80c278df14e0@mb8-2.1blu.de> <4DFA2356.8080005@ruhr-uni-bochum.de> Message-ID: <8739j9pvrf.fsf@vigenere.g10code.de> On Thu, 16 Jun 2011 17:37, marcus.brinkmann at ruhr-uni-bochum.de said: > Well, in a sense, it's my fault, too, I shouldn't have made it an enum in the > first place, but just constant #defines. Enums are easier for debugging because gdb knows about it and thus you may use tab completion to write tests. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From n-roeser at gmx.net Sat Jun 18 11:40:40 2011 From: n-roeser at gmx.net (Nico) Date: Sat, 18 Jun 2011 11:40:40 +0200 Subject: gpg-agent from gnupg-2.0.17 crashes when trying to add ECDSA key Message-ID: <4DFC7298.4040509@gmx.net> Hello! When I try to add an ECDSA key to a running gpg-agent, the agent crashes: $ eval `LC_ALL=POSIX gpg-agent --daemon --debug-all --enable-ssh-support` gpg-agent[6688]: NOTE: no default option file `/home/nico/.gnupg/gpg-agent.conf' gpg-agent[6688]: enabled debug flags: command mpi crypto memory cache memstat hashing assuan gpg-agent[6688]: listening on socket `/tmp/gpg-zuZIze/S.gpg-agent' gpg-agent[6688]: listening on socket `/tmp/gpg-rOACBd/S.gpg-agent.ssh' gpg-agent[6689]: gpg-agent (GnuPG) 2.0.17 started $ LC_ALL=POSIX ssh-add /tmp/testkey gpg-agent[6689]: ssh handler 0x9a9a328 for fd 7 started gpg-agent[6689]: ssh request handler for add_identity (17) started *** glibc detected *** gpg-agent: free(): invalid pointer: 0x080801ad *** Error reading response length from authentication socket. Could not add identity: /tmp/testkey The bug is triggered in gnupg-2.0.17/agent/command-ssh.c, line 1410, which says ?xfree (comment);?. Here is a (forced) backtrace (I added code to divide by zero), in order to see what functions were called before it crashed. Ignore the line numbers, as I added some debugging output. #0 0x08055184 in ssh_receive_key (stream=, key_new=0xb765bf1c, secret=1, read_comment=1, key_spec=0x0) at command-ssh.c:1421 #1 0x08055cec in ssh_handler_add_identity (ctrl=0x80dc258, request=0x80debd8, response=0x80e0cb8) at command-ssh.c:2536 #2 0x08057d5d in ssh_request_process (ctrl=0x80dc258, sock_client=7) at command-ssh.c:2868 #3 start_command_handler_ssh (ctrl=0x80dc258, sock_client=7) at command-ssh.c:3012 #4 0x0804e097 in start_connection_thread_ssh (arg=0x80dc258) at gpg-agent.c:1825 #5 0xb77f2d89 in pth_spawn_trampoline () at pth_lib.c:216 #6 0xb769f01b in makecontext () at ../sysdeps/unix/sysv/linux/i386/makecontext.S:88 #7 0xbff83768 in ?? () #8 0x00000000 in ?? () A quick look at the ssh_key_types structure in command-ssh.c (lines 218 ff.) suggests that gpg-agent does not yet support ECDSA keys; is that right? Nevertheless, it should not crash, but rather return some kind of informative message or so. -- Nico -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From robbat2 at gentoo.org Mon Jun 20 06:42:36 2011 From: robbat2 at gentoo.org (Robin H. Johnson) Date: Mon, 20 Jun 2011 04:42:36 +0000 Subject: --check-trustdb very slow (2+ hours) for large keyrings (6k keys, 906k sigs) Message-ID: <20110620044236.GD28470@orbis-terrarum.net> I need a way to speed up the trustdb check. As my keyring has grown over the years, it's become intractably slow. I already have no-auto-check-trustdb, and normally do a weekly check, but whenever I sign a key (at least once a week), GPG requires a trustdb check before the trust are usable for that key. How big is my keyring? $ time gpg --with-colon --fast-list-mode --list-sig |cut -d: -f1 | sort | uniq -c gpg: please do a --check-trustdb 6410 pub 5532 rev 167 rvk 906030 sig 7915 sub 1 tru real 1m9.699s user 1m10.102s sys 0m0.360s (Dropping fast-list-mode causes list-sig to be in the realm of 20-30 minutes). The system is a Core2 Quad Q6600, 2.4Ghz, w/ 6GiB of RAM. It's not hitting swap. Compiled w/ CFLAGS/CXXFLAGS='-march=nocona -O2 -pipe' ==== gpg (GnuPG) 2.0.17 libgcrypt 1.5.0-beta1 ... Home: ~/.gnupg Supported algorithms: Pubkey: RSA, ELG, DSA Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 ==== -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robbat2 at gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 330 bytes Desc: not available URL: From bernhard at intevation.de Mon Jun 20 10:26:29 2011 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 20 Jun 2011 10:26:29 +0200 Subject: gpgme-config largefile support missmatch? In-Reply-To: <4DFA20DA.6080507@ruhr-uni-bochum.de> References: <201106161125.04608.bernhard@intevation.de> <201106161544.16546.bernhard@intevation.de> <4DFA20DA.6080507@ruhr-uni-bochum.de> Message-ID: <201106201026.29941.bernhard@intevation.de> Am Donnerstag, 16. Juni 2011 17:27:22 schrieb Marcus Brinkmann: > gpgme-config and largefile support are two different sections in the > manual, and have nothing to do with each other. Why not add a sentence like In addition to gpgme-config output, you might need other flags to successfully buil and compile an application with gpgme, e.g. to get a consistent largefile support, see next secion. Or extend the examples have something to gcc -c foo.c `gpgme-config --cflags` $PLATFORMCFLAGS > The reason is that the cflags to locate the header file are only relevant > for that one source file. ?The largefile support however must be consistent > across the whole application domain. ?It's worse than you think. ?For > example, if two applications exchange file descriptors over a pipe, then > both applications must agree on the largefile support in order to handle > descriptors to large files correctly. ?No isolated compiler flag alone can > ensure that. ?(BTW, if systems using for example dbus-daemon and descriptor > passing over dbus channels get this right, it is probably by accident > rather than by being conscious about the issue! ?POSIX/C programming has > many pitfalls, many of them are quite obscure. ?Tread carefully.) Thanks for the explanation, but wouldn't it be nice to then be able to find out which options had been used to compile gpgme? So they can be checked against whatever my application is using? > Accidently compiling some files with and some files without largefile > support would only make the matter more confusing. -- Managing Director + Owner: www.Intevation.net <- A Free Software Company Kolabsys.com: Board Member FSFE.org: Founding GA Member 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: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From robbat2 at gentoo.org Mon Jun 20 11:39:10 2011 From: robbat2 at gentoo.org (Robin H. Johnson) Date: Mon, 20 Jun 2011 09:39:10 +0000 Subject: --check-trustdb very slow (2+ hours) for large keyrings (6k keys, 906k sigs) In-Reply-To: <20110620044236.GD28470@orbis-terrarum.net> References: <20110620044236.GD28470@orbis-terrarum.net> Message-ID: On Mon, Jun 20, 2011 at 04:42:36AM +0000, Robin H. Johnson wrote: ... Current timing, nearly 3 hours: $ date ; gpg --check-trustdb ; date Mon Jun 20 04:39:20 UTC 2011 gpg: public key 37C85380 is 167212187 seconds newer than the signature gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model gpg: depth: 0 valid: 2 signed: 162 trust: 0-, 0q, 0n, 0m, 0f, 2u gpg: public key E08384C0 is 2559 seconds newer than the signature gpg: depth: 1 valid: 162 signed: 2023 trust: 144-, 0q, 2n, 9m, 7f, 0u gpg: depth: 2 valid: 18 signed: 161 trust: 10-, 0q, 0n, 8m, 0f, 0u gpg: depth: 3 valid: 3 signed: 36 trust: 3-, 0q, 0n, 0m, 0f, 0u gpg: next trustdb check due at 2011-06-20 Mon Jun 20 07:34:34 UTC 2011 -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robbat2 at gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 330 bytes Desc: not available URL: From squalyl at gmail.com Mon Jun 20 15:30:10 2011 From: squalyl at gmail.com (=?UTF-8?Q?S=C3=A9bastien_Lorquet?=) Date: Mon, 20 Jun 2011 15:30:10 +0200 Subject: needs in OpenPGP to use it for a bitcoin replacement. In-Reply-To: References: <201105251921.16544.jeanjacquesbrucker@gmail.com> <201105281305.01583.jeanjacquesbrucker@gmail.com> <201105311244.43616.jeanjacquesbrucker@gmail.com> Message-ID: just to add oil in the fire... http://leanback.eu/bitcoin/plots/20110619195756-mtgox.png source: Le Monde (in french): http://www.lemonde.fr/technologies/article/2011/06/20/la-monnaie-virtuelle-bitcoin-en-crise_1538194_651865.html bitcoin? do not want! Sebastien On Tue, May 31, 2011 at 7:32 PM, Jerome Baum wrote: > On Tue, May 31, 2011 at 12:44, Jean-Jacques Brucker > wrote: > > > >> > >> So what happens if I don't have an established WoT? Does this currency > >> just not work for me? If you want to promote OpenPGP, then it's > >> probably best to promote it to people who aren't using it yet -- as > >> opposed to people who are already using it and have an established > >> WoT. > > > > As it is WoT-based, a given currency can only be exchanged in only one > WoT. > > > > Building a WoT is so the mandatory first step. > > Point still applies. > > >> I have no interests, economically speaking, of writing this email. > >> It's not like I'm going to make money from this, not even indirectly. > >> People have other interests than economic ones -- say you want to > >> promote digital currencies, or you are genuinely interested in the > >> challenge. > > > > Both of them. > > > > If u want a short retrospection about my motivation > > Sorry for the subtlety, I was pointing out the fact that the Bitcoin > creators needn't have economic interests in helping you, and still may > be happy to do so. You should still definitely get in touch with them > if you want to create an improvement over Bitcoin. > > >> > ? 5 an entity is an human or a group of defined humans (no legal > entity). > >> > >> Why? > > > > To keep things simple. > > Why is this simpler? How is any market going to spawn with your new > digital currency if businesses are prohibited from trading there? Why > make a restriction that isn't strictly related to the technical and > economical model you are designing? > > >> I've also taken a look at http://www.open-udc.org/en/money_rules and > >> frankly it feels like I was hit by a bus: "A new Open-UDC member must > >> be approuved by 2/3 or more of all members" is quite a condition. Does > >> this mean I cannot trade the currency if I don't have prior approval > >> of a 2/3 majority of the existing traders? Two options: > > > By the way, such kind of rules is not in the technical heart of a > WoT-based > > solution which I try to define (and need help for that). > > Exactly my point when it comes to ? 6. > > -- > Jerome Baum > tel +49-1578-8434336 > email jerome at jeromebaum.com > -- > PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A > PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bernhard at intevation.de Wed Jun 22 10:18:31 2011 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 22 Jun 2011 10:18:31 +0200 Subject: [Gpg4win-devel] X509 Root certificates and trusting them In-Reply-To: <201009221001.16509.bernhard@intevation.de> References: <201009221001.16509.bernhard@intevation.de> Message-ID: <201106221018.34144.bernhard@intevation.de> Am Mittwoch, 22. September 2010 10:01:13 schrieb Bernhard Reiter: > Am Freitag, 21. Mai 2010 12:03:22 schrieb Bernhard Reiter: > > The recommended way for a > > production X509 /CMS system is that a list of trusted X509 root > > certificates is maintained by the administrator of the system > > directly for dirmngr and possibly the global gpgsm. > > For gpgsm to be able to use certificates, > you need to have the full validated chain of certificates. > > [Forth edition] > > Especially for the root certificate, the person administrating > the machines (e.g. you) must ensure four conditions are given. > (Paths examples are for GNU systems, > the paths will be different for Mac OS or Windows.) > > a) You need to have the root certificate and be sure that the file you have > is really the root certificate you would like to trust. You need to do > this best at installation time, because later - in the heat of the moment - > users will go along with everthing unchecked just to get the task done. > > b.1) Make sure dirmngr trusts the root certificate. > info dirmngr Installation > konqueror info:/dirmngr/Installation > http://gnupg.org/documentation/manuals/dirmngr/Installation.html > > In short, recommended is to use the system dirmngr, > place the root certification file in .der format > in /etc/dirmngr/trusted-certs and restart the dirmngr service. > > b.2) Current revocation status information must be available. > gpgsm will ask dirmngr to validate each certificate. > As administrator you need to make sure that dirmngr can do that check. > > Usually certificates contain information where to get the revocation > list via http or ldap. So dirmngr should be able to do http and ldap calls > to the internet. Secure connections are not necessary as revocation info is > already signed. > > You can tune dirmngr to use proxies or always ask specific servers > via ldap. There are a number of other ways, like OCSP, to get revocation > information. Too much to list them here. With sane certificate > authorities and network settings it will just work with the revocation > lists out of the box. > > If you need to trouble shoot, you can turn off checking of revocation > information for a moment to verify that this is the problem. Leaving > this off for production will degrade security significantly. > > Users should have "prefer-system-dirmngr" in their local > gpgsm.conf (Usually ~/.gnupg/gpgsm.conf). > So that the system dirmngr is asked all the time. Using the system dirmngr has the advantage that central administration can approve root certificates for the most common communication partners of the organisation. IT-Administration should do this in my view. In addition for extra comfort of the users I believe that well used intermediate certificates should be added to /var/lib/dirmngr/extra-certs/ and that common directories services should be configured in vim /etc/dirmngr/ldapservers.conf (Don't forget to kick dirmngr after a change in configuration, e.g. by restarting the service.) > > c) Make sure gpg-agent trusts the root certificate > Recommended way is to do this system wide: > c.1) Place the right line in /etc/gnupg/trustlist.txt > > Note that quite a few certificate authorities need the "relax" option > because they fail to get some requirements right. So test everything > later and if it does not work, try with "relax". > > References: > Existence of configuration file: > info gnupg2 Installation > konqueror info:/gnupg2/Installation > http://gnupg.org/documentation/manuals/gnupg/Installation.html > > Format of trustlist.txt: > info gnupg2 "Invoking GPG-AGENT" "Agent Configuration" > konqueror info:/gnupg2/Agent Configuration > http://gnupg.org/documentation/manuals/gnupg/Agent-Configuration.html > > c.2) Make sure all users either > * have no personal trustlist.txt or > * have the option "include-default" in it. > The file will usually searched at ~/.gnupg/trustlist.txt. > > I guess all gpg-agents will need a kick after the trustlist.txt change. > Try sending a SIGHUP to all gpg-agent processes, e.g. > pkill -SIGHUP gpg-agent > or reboot. > > In general: If you wish to update all users' private configuration files, > you can try using Gnupg's helper application called > applygnupgdefaults > Documentation starts here: > info gnupg2 "Helper Tools" applygnupgdefaults > konqueror info:/gnupg2/applygnupgdefaults > http://gnupg.org/documentation/manuals/gnupg/applygnupgdefaults.html > > Hints for reading the documentation: > Using the documentation of your installed version is preferred, > because it usually is most correct. > > Use "info" on the commandline, if you are familiar with it. > It will be installed on many GNU systems. There are other exotic texinfo > console viewers of course like tkman or pinfo. > > If you have konqueror installed using "info:gnupg2" as URL will also work. > Konqueror internally uses the script /usr/share/apps/kio_info/kde-info2html > which on Debian Lenny comes with the kdebase-kio-plugins package. > This is my prefered method. > > Best, > Bernhard -- Managing Director + Owner: www.Intevation.net <- A Free Software Company Kolabsys.com: Board Member FSFE.org: Founding GA Member 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: smime.p7s Type: application/pkcs7-signature Size: 3694 bytes Desc: not available URL: From bernhard at intevation.de Wed Jun 22 12:18:50 2011 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 22 Jun 2011 12:18:50 +0200 Subject: doc/gpgsm.texi com-certs.pem mini-fix Message-ID: <201106221218.57799.bernhard@intevation.de> Example path for com-certs.pem corrected. -------------- next part -------------- A non-text attachment was scrubbed... Name: doc.diff Type: text/x-diff Size: 531 bytes Desc: not available URL: -------------- 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 Mon Jun 27 09:35:09 2011 From: wk at gnupg.org (Werner Koch) Date: Mon, 27 Jun 2011 09:35:09 +0200 Subject: gpg-agent from gnupg-2.0.17 crashes when trying to add ECDSA key In-Reply-To: <4DFC7298.4040509@gmx.net> (Nico's message of "Sat, 18 Jun 2011 11:40:40 +0200") References: <4DFC7298.4040509@gmx.net> Message-ID: <871uyfohg2.fsf@vigenere.g10code.de> On Sat, 18 Jun 2011 11:40, n-roeser at gmx.net said: > The bug is triggered in gnupg-2.0.17/agent/command-ssh.c, line 1410, > which says ?xfree (comment);?. Arghh, this function is indeed buggy. We are freeing a constant. I better review the whole file. > A quick look at the ssh_key_types structure in command-ssh.c (lines 218 > ff.) suggests that gpg-agent does not yet support ECDSA keys; is that > right? Nevertheless, it should not crash, but rather return some kind of Right. Agreed. Thanks, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Jun 27 16:13:15 2011 From: wk at gnupg.org (Werner Koch) Date: Mon, 27 Jun 2011 16:13:15 +0200 Subject: doc/gpgsm.texi com-certs.pem mini-fix In-Reply-To: <201106221218.57799.bernhard@intevation.de> (Bernhard Reiter's message of "Wed, 22 Jun 2011 12:18:50 +0200") References: <201106221218.57799.bernhard@intevation.de> Message-ID: <87pqlzl5vo.fsf@vigenere.g10code.de> On Wed, 22 Jun 2011 12:18, bernhard at intevation.de said: > Example path for com-certs.pem corrected. Thanks, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Jun 29 12:18:34 2011 From: wk at gnupg.org (Werner Koch) Date: Wed, 29 Jun 2011 12:18:34 +0200 Subject: [Announce] Libgcrypt 1.5.0 released Message-ID: <874o39hret.fsf@vigenere.g10code.de> Hello! The GNU project is pleased to announce the availability of Libgcrypt version 1.5.0. This is the new stable version of Libgcrypt and upward compatible with the 1.4 series. The 1.4 series will enter end of life state on 2012-12-31. Libgcrypt is a general purpose library of cryptographic building blocks. It is originally based on code used by GnuPG. It does not provide any implementation of OpenPGP or other protocols. Thorough understanding of applied cryptography is required to use Libgcrypt. Noteworthy changes between version 1.4.6 and 1.5.0: * New function gcry_kdf_derive implementing OpenPGP S2K algorithms and PBKDF2. * Support for WindowsCE. * Support for ECDH. * Support for OAEP and PSS methods as described by RFC-3447. * Fixed PKCS v1.5 code to always return the leading zero. * New format specifiers "%M" and "%u" for gcry_sexp_build. * Support opaque MPIs with "%m" and "%M" in gcry_sexp_build. * New functions gcry_pk_get_curve and gcry_pk_get_param to map ECC parameters to a curve name and to retrieve parameter values. * gcry_mpi_cmp applied to opaque values has a defined semantic now. * Uses the Intel AES-NI instructions if available. * The use of the deprecated Alternative Public Key Interface (gcry_ac_*) will now print compile time warnings. * *The module register subsystem has been deprecated.* This subsystem is not flexible enough and would always require ABI changes to extend the internal interfaces. It will eventually be removed. Please contact us on the gcrypt-devel mailing list to discuss whether you really need this feature or how it can be replaced by an internal plugin mechanism. * CTR mode may now be used with data chunks of arbitrary length. * Interface changes relative to the 1.4.6 release: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ GCRY_PK_ECDH NEW. gcry_pk_get_curve NEW. gcry_pk_get_param NEW. GCRYCTL_DISABLE_HWF NEW. gcry_kdf_derive NEW. gcry_pk_encrypt EXTENDED: Support OAEP. gcry_pk_decrypt EXTENDED: Support OAEP. gcry_pk_sign EXTENDED: Support PSS. gcry_pk_verify EXTENDED: Support PSS. gcry_sexp_build EXTENDED: Add format specifiers M and u. Source code is hosted at the GnuPG FTP server and its mirrors as listed at http://www.gnupg.org/download/mirrors.html . On the primary server the source file and its digital signatures is: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.0.tar.bz2 (1400k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.0.tar.bz2.sig This file is bzip2 compressed. A gzip compressed version is also available: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.0.tar.gz (1698k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.0.tar.gz.sig Due to a lot of changes regarding white spaces we don't provide a patch file against 1.4.6. The SHA-1 checksums are: e6508315b76eaf3d0df453f67371b106654bd4fe libgcrypt-1.5.0.tar.gz 3e776d44375dc1a710560b98ae8437d5da6e32cf libgcrypt-1.5.0.tar.bz2 For help on developing with Libgcrypt you should read the included manual and optional ask on the gcrypt-devel mailing list [1]. Improving Libgcrypt is costly, but you can help! We are looking for organizations that find Libgcrypt useful and wish to contribute back. You can contribute by reporting bugs, improve the software [2], order extensions or support or more general by donating money to the Free Software movement [3]. Commercial support contracts for Libgcrypt are available [4], and they help finance continued maintenance. g10 Code GmbH, a Duesseldorf based company, is currently funding Libgcrypt development. We are always looking for interesting development projects. Many thanks to all who contributed to Libgcrypt development, be it bug fixes, code, documentation, testing or helping users. Happy hacking, Werner [1] See . [2] Note that copyright assignments to the FSF are required. [3] For example see . [4] See the service directory at . -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 207 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 arian.sameni at gmail.com Wed Jun 29 12:46:25 2011 From: arian.sameni at gmail.com (Arian Sameni) Date: Wed, 29 Jun 2011 12:46:25 +0200 Subject: Error using GPG2 in FIPS mode Message-ID: <4E0B0281.5080006@gmail.com> Hi everybody, I'm having some trouble trying to use GnuPG2 with FIPS mode enabled*. For example, when invoking --gen-key I get the following error: --- Ohhhh jeeee: cipher 3 not found fatal error in libgcrypt, file misc.c, line 137, function _gcry_logv: internal error (fatal or bug) Aborted --- And when trying to encrypt: --- gpg: no valid OpenPGP data found. gpg: processing message failed: Unknown system error --- Even --help fails: --- Home: ~/.gnupg Supported algorithms: Ohhhh jeeee: secure memory is disabledfatal error in libgcrypt, file misc.c, line 137, function _gcry_logv: internal error (fatal or bug) Aborted --- I'm using GnuPG 2.0.17 with libgcrypt 1.4.6, both compiled from source. When FIPS is not enabled, everything works OK. Also, generating a key in batch mode with FIPS enabled works too. Even a small program I made ex profeso while checking this, that uses libgcrypt's gcry_random_bytes() with FIPS enabled, works. Am I missing something here? Is there any kind of restriction in FIPS about interactive usage, or something like that? Isn't gnupg aware of FIPS yet? Or is it just some kind of bug? Thanks. *I've tried both echoing 1 to the FIPS_FORCE_FILE (/etc/gcrypt/fips_enabled) and editing gnupg-2.0.17/g10/gpg.c so that it calls gcry_control (GCRYCTL_FORCE_FIPS_MODE); before all other initialization. Both fail. From wk at gnupg.org Wed Jun 29 14:53:23 2011 From: wk at gnupg.org (Werner Koch) Date: Wed, 29 Jun 2011 14:53:23 +0200 Subject: Error using GPG2 in FIPS mode In-Reply-To: <4E0B0281.5080006@gmail.com> (Arian Sameni's message of "Wed, 29 Jun 2011 12:46:25 +0200") References: <4E0B0281.5080006@gmail.com> Message-ID: <87vcvohk8s.fsf@vigenere.g10code.de> > I'm having some trouble trying to use GnuPG2 with FIPS mode enabled*. > > For example, when invoking --gen-key I get the following error: > --- > Ohhhh jeeee: cipher 3 not found This is due to the passphrase generation code which calls Libgcrypt with a certain algorithm: dek->keylen = openpgp_cipher_get_algo_keylen (dek->algo); Now Libgcrypt expects that the algorithm used for this function is valid and because that is not the case in FIPS mode it aborts. Agreed, GnuPG should check whether the algorithm is valid before calling such functions. However in non-FIPS mode this is always guaranteed because CAST5 is a SHOULD algorithm in OpenPGP. I only did some basic fixups to GnuPG to allow running it on a FIPS enabled system (like separate implementation of RIPE-MD-160, which is used internally by GPG). There was no request to make GPG runnable on a FIPS enabled system. You make use the option "--s2k-cipher-algo AES128" to solve at least this problem. There are likely other problems. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Jun 29 15:36:02 2011 From: wk at gnupg.org (Werner Koch) Date: Wed, 29 Jun 2011 15:36:02 +0200 Subject: Error using GPG2 in FIPS mode In-Reply-To: <4E0B0281.5080006@gmail.com> (Arian Sameni's message of "Wed, 29 Jun 2011 12:46:25 +0200") References: <4E0B0281.5080006@gmail.com> Message-ID: <87r56chi9p.fsf@vigenere.g10code.de> Hi! I looked again at it and there is indeed a bug lingering in Libgcrypt. What a pitty that I released 1.5.0 a few hours ago. Please find attach a patch against libgcrypt which should fix it. Well, not really ... at least it bails out in GnuPG and not in Libgcrypt which is more or less fine. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fixed-a-bug-in-the-gcry_cipher_get_algo_keylen-and-g.patch Type: text/x-patch Size: 5961 bytes Desc: not available URL: