From stephane at sente.ch Tue Apr 1 12:46:12 2008 From: stephane at sente.ch (=?ISO-8859-1?Q?St=E9phane_Corth=E9sy?=) Date: Tue, 1 Apr 2008 12:46:12 +0200 Subject: gpg-agent and launchd - again References: Message-ID: Hi, I saw no interest in this message; I try once again, then I'll keep it in my pocket. St?phane Begin forwarded message: > From: St?phane Corth?sy > Date: March 21, 2008 6:32:07 PM GMT+01:00 > To: Gnupg-devel at gnupg.org > Subject: gpg-agent and launchd > X-Spam-Status: No, score=-2.5 required=5.0 > tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.7 > X-Mailer: Apple Mail (2.919.2) > > Hi, > > I'd like to see support of launchd in gpg-agent. > > "launchd is a unified, open source service management framework for > starting, stopping and managing daemons, programs and > scripts" (wikipedia) > > It is open-source , under apache > license, and is, under Darwin/MacOSX, responsible to launch all > daemons and agents, based on different criteria, and will relaunch > them if necessary. It replaces init, watchdogd, crond, etc. > > Though apache license is incompatible with GPL, launchd is a system > component on OSX (this is even the key component, with PID 1). That > shouldn't cause problem, would it? > > > The goal is to have a well-integrated agent under MacOSX 10.5: the > agent is launched when user logs in, is relaunched automatically in > case of failure, and is stopped when user logs out. This is already > achievable currently, but there are some limitations: > - as gpg-agent runs as a daemon, we cannot watchdog it, and > relaunch it automatically, without an external watch dog process > - as we cannot make all user processes inherit from the environment > variables of gpg-agent (user processes don't read the ~/.login or > whatever), we need to stick with standard socket path, which works > only if the home directory is mounted as a local file system > - when user logs out, gpg-agent is not terminated automatically > > > On a technical POV, a program launched by launchd must respect the > following constraints (copied from launchd.plist(5) man page): > > It MUST NOT: > ? Call daemon(3). > ? Do the moral equivalent of daemon(3) by calling fork > (2) and > have the parent process exit(3) or _exit(2). > > It SHOULD NOT: > ? Setup the user ID or group ID. > ? Setup the working directory. > ? chroot(2) > ? setsid(2) > ? Close "stray" file descriptors. > ? Change stdio(3) to /dev/null. > ? Setup resource limits with setrusage(2). > ? Setup priority with setpriority(2). > ? Ignore the SIGTERM signal. > > It SHOULD: > ? Launch on demand given criteria specified in the XML > property > list. More information can be found later in this > man page. > ? Catch the SIGTERM signal. > > Avoiding fork() is possible, as it is already done for Win32. > Avoiding the chdir() too, as well as avoiding changing uig, gid, > sid. I found no setrusage() nor setpriority(), at first look. > SIGTERM is not ignored, and actually used by the code to terminate > properly. I have no idea about the two other constraints, Close > "stray" file descriptors, and Change stdio(3) to /dev/null. > > Launching the agent on demand is unfortunately not possible: though > we can configure launchd to create a secure socket, pass it through > an environment variable, and launch gpg-agent only when the secure > socket is being accessed, this is not possible for gpg-agent, > because agent client processes (gpg) expect the GPG_AGENT_INFO to > contain the socket path, the agent pid, and a version number. This > cannot work for us, as the pid is unknown until the agent has been > launched, and the created environment variable is only the socket > path. Anyway, launching the agent at user's login works fine too. > > > 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? > > > St?phane > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel From wk at gnupg.org Tue Apr 1 14:23:04 2008 From: wk at gnupg.org (Werner Koch) Date: Tue, 01 Apr 2008 14:23:04 +0200 Subject: gpg-agent and launchd In-Reply-To: (=?utf-8?Q?=22St=C3=A9phane=09Corth=C3=A9sy=22's?= message of "Fri, 21 Mar 2008 18:32:07 +0100") References: Message-ID: <87ej9p4vdj.fsf@wheatstone.g10code.de> On Fri, 21 Mar 2008 18:32, stephane at sente.ch said: > - as gpg-agent runs as a daemon, we cannot watchdog it, and relaunch > it automatically, without an external watch dog process Simply run gpg-agent to see whether the agent is still alive. > - as we cannot make all user processes inherit from the environment > variables of gpg-agent (user processes don't read the ~/.login or > whatever), we need to stick with standard socket path, which works > only if the home directory is mounted as a local file system It would be straightforward to add a configure or runtime option to set a different standard socket name. Let me know if you really need this. However all tools need to have a way to figure out the standard socket. /etc/gnupg/foo might be usable to describe a system wide standard socket. > - when user logs out, gpg-agent is not terminated automatically Depends on how you install it. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From stephane at sente.ch Wed Apr 2 09:32:23 2008 From: stephane at sente.ch (=?ISO-8859-1?Q?St=E9phane_Corth=E9sy?=) Date: Wed, 2 Apr 2008 09:32:23 +0200 Subject: gpg-agent and launchd In-Reply-To: <87ej9p4vdj.fsf@wheatstone.g10code.de> References: <87ej9p4vdj.fsf@wheatstone.g10code.de> Message-ID: <218CC71C-B266-4F83-8B89-1C37D670AB5E@sente.ch> Hello, On Apr 1, 2008, at 2:23 PM, Werner Koch wrote: > On Fri, 21 Mar 2008 18:32, stephane at sente.ch said: > >> - as gpg-agent runs as a daemon, we cannot watchdog it, and relaunch >> it automatically, without an external watch dog process > > Simply run gpg-agent to see whether the agent is still alive. Not very user friendly. User expects agent to start at login, then stops at logout, without having to relaunch it n case of doubt. User should have the possibility to start/stop it manually too, but shouldn't have to ckeck that it is running. Using the system's watchdog mechanism (launchd) would be much better. Anyway, that's not a critical point. >> - as we cannot make all user processes inherit from the environment >> variables of gpg-agent (user processes don't read the ~/.login or >> whatever), we need to stick with standard socket path, which works >> only if the home directory is mounted as a local file system > > It would be straightforward to add a configure or runtime option to > set > a different standard socket name. Let me know if you really need > this. > However all tools need to have a way to figure out the standard > socket. > /etc/gnupg/foo might be usable to describe a system wide standard > socket. That's the critical point. Having a configure option could work only if standard socket name would include a dynamic part (e.g. the uid), else it could mean that 2 users couldn't run the agent at the same time on the same machine, if they both use the same socket name. Having a new option would work, though we'd need also new gpg and gpg2 executables that would support that new option too, as you wrote it; the new agent would not work with old versions of gpg/gpg2. Using /etc/gnupg/foo would not be a good idea, because that could prevent two users running the agent at the same time; the two agents can't use the same socket. Note that if in the future you use the PID part in the GPG_AGENT_INFO environment variable, we will have a problem again: we can't make all user processes inherit from that dynamic GPG_AGENT_INFO environment variable, without launchd-specific code. >> - when user logs out, gpg-agent is not terminated automatically > > Depends on how you install it. What do you mean? How am I supposed to install it? Agent is launched on user's login; there is no logout hook to kill it, on OSX. Is it what the 'no-detach' option could be used for? Thanks for your comments, St?phane > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel From michael at vorlon.ping.de Wed Apr 2 13:00:47 2008 From: michael at vorlon.ping.de (Michael Bienia) Date: Wed, 2 Apr 2008 13:00:47 +0200 Subject: Insufficient/missing check on libgcrypt when gpg2 is used with --enable-dsa2? Message-ID: <20080402110047.GA8006@vorlon.ping.de> Hello, I tried to generate a DSA2 key on my Ubuntu hardy box. I have gnupg2 2.0.9 (I took the Debian unstable package and build it on my box) and libgcrypt11 1.2.4 (from the Ubuntu archive) installed. I called gpg2 with --enable-dsa2 --gen-key and tried to generate a 3072/4096 DSA2 key which ended in: gpg: WARNING: some OpenPGP programs can't handle a DSA key with this digest size gpg2: dsa.c:187: generate: Assertion `nbits >= 512 && nbits <= 1024' failed. Aborted (core dumped) After upgrading libgcrypt to 1.4.0 (taken from Debian unstable) it worked then as expected. Shouldn't then gpg2 require libgcrypt >= 1.4.0 during build or check during runtime if the installed libgcrypt supports DSA2 when one tries to generate/use such a key? Michael From wk at gnupg.org Wed Apr 2 19:42:04 2008 From: wk at gnupg.org (Werner Koch) Date: Wed, 02 Apr 2008 19:42:04 +0200 Subject: Insufficient/missing check on libgcrypt when gpg2 is used with --enable-dsa2? In-Reply-To: <20080402110047.GA8006@vorlon.ping.de> (Michael Bienia's message of "Wed, 2 Apr 2008 13:00:47 +0200") References: <20080402110047.GA8006@vorlon.ping.de> Message-ID: <874pakrw5v.fsf@wheatstone.g10code.de> On Wed, 2 Apr 2008 13:00, michael at vorlon.ping.de said: > Shouldn't then gpg2 require libgcrypt >= 1.4.0 during build or check > during runtime if the installed libgcrypt supports DSA2 when one tries to > generate/use such a key? Right. Fixed in SVN: $ gpg2 --version gpg (GnuPG) 2.0.10-svn4720 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: ~/.gnupg Supported algorithms: Pubkey: RSA, ELG, DSA Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512 Compression: Uncompressed, ZIP, ZLIB Used libraries: gcrypt(1.2.5-svn1275) $ gpg2 --enable-dsa2 gpg: WARNING: DSA2 is only available with Libgcrypt 1.4 and later gpg: Go ahead and type your message ... Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From turkay.eren at gmail.com Wed Apr 2 20:00:28 2008 From: turkay.eren at gmail.com (Eren =?utf-8?q?T=C3=BCrkay?=) Date: Wed, 2 Apr 2008 21:00:28 +0300 Subject: Patch for Duplicated IDs Memory Corruption on 2.0.4 tarball Message-ID: <200804022100.28730.turkay.eren@gmail.com> Hello, You may think at first that this problem was fixed in the latest release, yes it was but I have a problem with it. I maintain GnuPG package for my distro. We have 2 repositories in general. Stable and development. In stable repository, we can't add additional dependencies of GnuPG 2.0.9 because it should be tested throughly and right now, I should add patch for the vulnerability immediately. I prepared a patch for 2.0.4 tarball by looking the fix in trunk/. The code in 2.0.4 tarball is little similar to that of in trunk/ so I'm not sure if it is a real fix or not since there is no PoC. I'll really appriciate that you review it. I don't want to add a patch which doesn't solve anything but breaks something. Best regards, Eren -------------- next part -------------- A non-text attachment was scrubbed... Name: CVE-2008-1530-2.0.4.patch Type: text/x-diff Size: 1843 bytes Desc: not available URL: From dshaw at jabberwocky.com Wed Apr 2 21:19:13 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 2 Apr 2008 15:19:13 -0400 Subject: Patch for Duplicated IDs Memory Corruption on 2.0.4 tarball In-Reply-To: <200804022100.28730.turkay.eren@gmail.com> References: <200804022100.28730.turkay.eren@gmail.com> Message-ID: <20080402191913.GB959@jabberwocky.com> On Wed, Apr 02, 2008 at 09:00:28PM +0300, Eren T??rkay wrote: > Hello, > > You may think at first that this problem was fixed in the latest release, yes > it was but I have a problem with it. > > I maintain GnuPG package for my distro. We have 2 repositories in general. > Stable and development. In stable repository, we can't add additional > dependencies of GnuPG 2.0.9 because it should be tested throughly and right > now, I should add patch for the vulnerability immediately. > > I prepared a patch for 2.0.4 tarball by looking the fix in > trunk/. The code in 2.0.4 tarball is little similar to that of in > trunk/ so I'm not sure if it is a real fix or not since there is no > PoC. The problem does not exist in 2.0.4, so no patch is needed. The problem only exists in 2.0.8 and 1.4.8. David From turkay.eren at gmail.com Wed Apr 2 21:34:24 2008 From: turkay.eren at gmail.com (Eren =?iso-8859-1?q?T=FCrkay?=) Date: Wed, 2 Apr 2008 22:34:24 +0300 Subject: Patch for Duplicated IDs Memory Corruption on 2.0.4 tarball In-Reply-To: <20080402191913.GB959@jabberwocky.com> References: <200804022100.28730.turkay.eren@gmail.com> <20080402191913.GB959@jabberwocky.com> Message-ID: <200804022234.24222.turkay.eren@gmail.com> On 02 Apr 2008 Wed 22:19:13 David Shaw wrote: > The problem does not exist in 2.0.4, so no patch is needed. ?The > problem only exists in 2.0.8 and 1.4.8. > > David Hmm, secunia [0] published it as 2.x and 1.x, so I though that the vulnerability exists on all versions of GnuPG except 2.0.9 and 1.4.9. [0] http://secunia.com/advisories/29568/ From dshaw at jabberwocky.com Wed Apr 2 21:52:21 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 2 Apr 2008 15:52:21 -0400 Subject: Patch for Duplicated IDs Memory Corruption on 2.0.4 tarball In-Reply-To: <200804022234.24222.turkay.eren@gmail.com> References: <200804022100.28730.turkay.eren@gmail.com> <20080402191913.GB959@jabberwocky.com> <200804022234.24222.turkay.eren@gmail.com> Message-ID: <20080402195220.GC959@jabberwocky.com> On Wed, Apr 02, 2008 at 10:34:24PM +0300, Eren T?rkay wrote: > On 02 Apr 2008 Wed 22:19:13 David Shaw wrote: > > The problem does not exist in 2.0.4, so no patch is needed. ?The > > problem only exists in 2.0.8 and 1.4.8. > > > > David > > Hmm, secunia [0] published it as 2.x and 1.x, so I though that the > vulnerability exists on all versions of GnuPG except 2.0.9 and 1.4.9. > > [0] http://secunia.com/advisories/29568/ Secunia are fine people, but they're in error on this point. The only versions of GnuPG that have the bug are 1.4.8 and 2.0.8. No other versions. The CVE (CVE-2008-1530) gets it right. David From turkay.eren at gmail.com Wed Apr 2 23:03:33 2008 From: turkay.eren at gmail.com (Eren =?iso-8859-1?q?T=FCrkay?=) Date: Thu, 3 Apr 2008 00:03:33 +0300 Subject: Patch for Duplicated IDs Memory Corruption on 2.0.4 tarball In-Reply-To: <20080402195220.GC959@jabberwocky.com> References: <200804022100.28730.turkay.eren@gmail.com> <200804022234.24222.turkay.eren@gmail.com> <20080402195220.GC959@jabberwocky.com> Message-ID: <200804030003.33494.turkay.eren@gmail.com> On 02 Apr 2008 Wed 22:52:21 David Shaw wrote: > Secunia are fine people, but they're in error on this point. ?The only > versions of GnuPG that have the bug are 1.4.8 and 2.0.8. ?No other > versions. Thanks for your reply, have a good hacking :-) From gpgme at katehok.ac93.org Sat Apr 5 15:38:09 2008 From: gpgme at katehok.ac93.org (Igor Belyi) Date: Sat, 05 Apr 2008 09:38:09 -0400 Subject: Problem with gpgme in gpg4win 1.1.3 Message-ID: <47F780C1.2000307@katehok.ac93.org> It looks like moderator for gpg4win mailing list is not around, so I'll repost my message here. I ran into the problem when a different than default directory is selected during gpg4win 1.1.3 install. It manifests itself when gpa.exe is started and fails to find the engine. It is caused by mismatch between gpg4win using newer approach of registering "Install Directory" and "gpgProgram" strings in "HKLM\Software\GNU\GnuPG\" key and GPGME relying on either "HKCU\Software\GNU\GnuPG\gpgProgram" (note the HKCU vs HKLM) or on the program being in the default location. There's a note in the "src/inst-gnupg.nsi" of the gpg4win source saying that relying on "gpgProgram" key is an old style and sure enough the newer version of GPGME (although also 1.1.6, just like in gpg4win 1.1.3) does uses the "Install Directory" to find all the necessary gpg.exe, gpgsm.exe, and gpgconf.exe. On related note, the new GPGME still checks for gpgProgram in HKCU and not HKLM rooted location. On my machine I noticed that there was an entry in there which looks like left-over from some previous installation and (as expected) it is not removed by the newer version of gpg4win on install/uninstall. This caused even newer GPGME to assume a wrong location for gpg.exe. I removed that registry value on my machine but I suspect other users may run into similar problem. Hope it helps. Cheers, Igor From marcus.brinkmann at ruhr-uni-bochum.de Mon Apr 7 16:18:54 2008 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Mon, 07 Apr 2008 16:18:54 +0200 Subject: Problem with gpgme in gpg4win 1.1.3 In-Reply-To: <47F780C1.2000307@katehok.ac93.org> References: <47F780C1.2000307@katehok.ac93.org> Message-ID: <87od8lwxwx.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Sat, 05 Apr 2008 09:38:09 -0400, Igor Belyi wrote: > I ran into the problem when a different than default directory is > selected during gpg4win 1.1.3 install. Should be fixed in the upcoming 1.9/2 releases of gpg4win. > It manifests itself when gpa.exe > is started and fails to find the engine. It is caused by mismatch > between gpg4win using newer approach of registering "Install Directory" > and "gpgProgram" strings in "HKLM\Software\GNU\GnuPG\" key and GPGME > relying on either "HKCU\Software\GNU\GnuPG\gpgProgram" (note the HKCU vs > HKLM) or on the program being in the default location. GPGME checks HKCU and falls back on HKLM. In any case, gpgProgram should not really be set, there was some confusion and error. Some tools like winpt set it, that should be reported as a bug. > There's a note in > the "src/inst-gnupg.nsi" of the gpg4win source saying that relying on > "gpgProgram" key is an old style and sure enough the newer version of > GPGME (although also 1.1.6, just like in gpg4win 1.1.3) does uses the > "Install Directory" to find all the necessary gpg.exe, gpgsm.exe, and > gpgconf.exe. Right. > On related note, the new GPGME still checks for gpgProgram in HKCU and > not HKLM rooted location. That's useful for manual override. > On my machine I noticed that there was an > entry in there which looks like left-over from some previous > installation and (as expected) it is not removed by the newer version of > gpg4win on install/uninstall. This caused even newer GPGME to assume a > wrong location for gpg.exe. I removed that registry value on my machine > but I suspect other users may run into similar problem. We can not remove it reliably at installation time because it can be a per-user setting. The new GUI, kleopatra, will check for the registry key, present a warning and allow to remove it. In the long haul, gpgProgram should almost never be present. Thanks, Marcus From marcus.brinkmann at ruhr-uni-bochum.de Mon Apr 7 21:09:47 2008 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Mon, 07 Apr 2008 21:09:47 +0200 Subject: scim and pinentry-gtk2 In-Reply-To: <47E09E50.8040106@rlworkman.net> References: <47BDF11A.8010500@rlworkman.net> <87hcfvg8wu.wl%marcus.brinkmann@ruhr-uni-bochum.de> <47E09E50.8040106@rlworkman.net> Message-ID: <87myo5wkg3.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Wed, 19 Mar 2008 00:02:08 -0500, Robby Workman wrote: > > Marcus Brinkmann wrote: > > At Thu, 21 Feb 2008 15:46:02 -0600, > > Robby Workman wrote: > >> To make a long story short, pinentry-gtk2 doesn't receive keyboard > >> input when scim is being used. This has previously been reported > >> to both Ubuntu and OpenSuSE, and after scim and friends were recently > >> added to Slackware, we're seeing it there. > >> > >> https://bugs.launchpad.net/ubuntu/+source/pinentry/+bug/176815 > >> > >> https://bugzilla.novell.com/show_bug.cgi?id=330073#c5 > >> > >> Any idea what's at fault? > > > > pinentry grabs the keyboard and the screen by default (there is an > > option to switch it off). Maybe scim doesn't work well with that? > > > Hi Marcus, > > Sorry for the delay - I've unfortunately been short on time lately. > > Starting gpg-agent with the --no-grab option has no effect. > This is quite annoying for users who need alternate input methods, > especially scim. Maybe I'm missing something obvious, but here's > how it appears to me: > > 1. Pinentry is a GTK+ app. > 2. GTK+ apps can use GTK+ input methods. > 3. Rather than using an input method, pinentry grabs the raw input. > > I understand that there are perhaps security concerns with not > grabbing raw input, but surely there's a way to fix this? > pinentry-qt handles this just fine, btw... If it can be implemented without linking to any more libraries, I would suggest a command line option to enable external input methods. If more libraries are required, or if there is a slippery slope towards more GNOME/Gtk compliance, it might make sense to provide two separate versions of pinentry: A hardened version based on the current code, and a weakened version that does not make extra efforts to be secure, but instead complies to a multitude of GUI standards. How does this sound? Thanks, Marcus From wk at gnupg.org Tue Apr 8 16:50:28 2008 From: wk at gnupg.org (Werner Koch) Date: Tue, 08 Apr 2008 16:50:28 +0200 Subject: scim and pinentry-gtk2 In-Reply-To: <87myo5wkg3.wl%marcus.brinkmann@ruhr-uni-bochum.de> (Marcus Brinkmann's message of "Mon, 07 Apr 2008 21:09:47 +0200") References: <47BDF11A.8010500@rlworkman.net> <87hcfvg8wu.wl%marcus.brinkmann@ruhr-uni-bochum.de> <47E09E50.8040106@rlworkman.net> <87myo5wkg3.wl%marcus.brinkmann@ruhr-uni-bochum.de> Message-ID: <87myo45rkb.fsf@wheatstone.g10code.de> On Mon, 7 Apr 2008 21:09, marcus.brinkmann at ruhr-uni-bochum.de said: > If it can be implemented without linking to any more libraries, I > would suggest a command line option to enable external input methods. Command line options are cumbersome because we would need to implement them in gpg-agent and and gpgconf too. > towards more GNOME/Gtk compliance, it might make sense to provide two > separate versions of pinentry: A hardened version based on the current That's also my suggestion. Our framework makes it pretty easy to add new pinentries Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From rw at rlworkman.net Tue Apr 8 20:15:19 2008 From: rw at rlworkman.net (Robby Workman) Date: Tue, 08 Apr 2008 13:15:19 -0500 Subject: scim and pinentry-gtk2 In-Reply-To: <87myo5wkg3.wl%marcus.brinkmann@ruhr-uni-bochum.de> References: <47BDF11A.8010500@rlworkman.net> <87hcfvg8wu.wl%marcus.brinkmann@ruhr-uni-bochum.de> <47E09E50.8040106@rlworkman.net> <87myo5wkg3.wl%marcus.brinkmann@ruhr-uni-bochum.de> Message-ID: <47FBB637.9070103@rlworkman.net> Note: added Eric Hameleers to CC list; please preserve in replies... Marcus Brinkmann wrote: > At Wed, 19 Mar 2008 00:02:08 -0500, > Robby Workman wrote: >> Marcus Brinkmann wrote: >>> At Thu, 21 Feb 2008 15:46:02 -0600, >>> Robby Workman wrote: >>>> To make a long story short, pinentry-gtk2 doesn't receive keyboard >>>> input when scim is being used. This has previously been reported >>>> to both Ubuntu and OpenSuSE, and after scim and friends were recently >>>> added to Slackware, we're seeing it there. >>>> >>>> https://bugs.launchpad.net/ubuntu/+source/pinentry/+bug/176815 >>>> >>>> https://bugzilla.novell.com/show_bug.cgi?id=330073#c5 >>>> >>>> Any idea what's at fault? >>> pinentry grabs the keyboard and the screen by default (there is an >>> option to switch it off). Maybe scim doesn't work well with that? >> >> Hi Marcus, >> >> Sorry for the delay - I've unfortunately been short on time lately. >> >> Starting gpg-agent with the --no-grab option has no effect. >> This is quite annoying for users who need alternate input methods, >> especially scim. Maybe I'm missing something obvious, but here's >> how it appears to me: >> >> 1. Pinentry is a GTK+ app. >> 2. GTK+ apps can use GTK+ input methods. >> 3. Rather than using an input method, pinentry grabs the raw input. >> >> I understand that there are perhaps security concerns with not >> grabbing raw input, but surely there's a way to fix this? >> pinentry-qt handles this just fine, btw... > > If it can be implemented without linking to any more libraries, I > would suggest a command line option to enable external input methods. > > If more libraries are required, or if there is a slippery slope > towards more GNOME/Gtk compliance, it might make sense to provide two > separate versions of pinentry: A hardened version based on the current > code, and a weakened version that does not make extra efforts to be > secure, but instead complies to a multitude of GUI standards. > > How does this sound? I suppose the command line option to pinentry might be acceptable, but there would need to be some way to specify in gpg-agent that pinentry should be called with the --scim (or whatever) option. Perhaps it could check for the presence of the XIM_PROGRAM or GTK_IM_MODULE environment variables and automatically do the right thing. Alternatively, a pinentry-scim binary (which could then be specified in gpg-agent with --pinentry-program) would be acceptable, I suppose. I know basically nothing about gtk programming, but I must admit that I find it hard to believe that there's no "correct" way to do this in gtk without either command line options to pinentry or a special pinentry binary -- obviously qt provides the ability, so surely gtk does as well? -RW From rw at rlworkman.net Tue Apr 8 20:17:42 2008 From: rw at rlworkman.net (Robby Workman) Date: Tue, 08 Apr 2008 13:17:42 -0500 Subject: scim and pinentry-gtk2 In-Reply-To: <87myo45rkb.fsf@wheatstone.g10code.de> References: <47BDF11A.8010500@rlworkman.net> <87hcfvg8wu.wl%marcus.brinkmann@ruhr-uni-bochum.de> <47E09E50.8040106@rlworkman.net> <87myo5wkg3.wl%marcus.brinkmann@ruhr-uni-bochum.de> <87myo45rkb.fsf@wheatstone.g10code.de> Message-ID: <47FBB6C6.1030701@rlworkman.net> Werner Koch wrote: > On Mon, 7 Apr 2008 21:09, marcus.brinkmann at ruhr-uni-bochum.de said: > >> If it can be implemented without linking to any more libraries, I >> would suggest a command line option to enable external input methods. > > Command line options are cumbersome because we would need to implement > them in gpg-agent and and gpgconf too. Aha; I should have read this one before replying - I didn't consider gpgconf, but yeah, this was one of my concerns. >> towards more GNOME/Gtk compliance, it might make sense to provide two >> separate versions of pinentry: A hardened version based on the current > > That's also my suggestion. Our framework makes it pretty easy to add new > pinentries Ideally, this could be done with native gtk, but yeah, if it can't be done within the ideals you guys set, a new pinentry-scim binary would certainly be acceptable, I think. -RW From bernhard at intevation.de Tue Apr 8 22:34:59 2008 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 8 Apr 2008 22:34:59 +0200 Subject: Problem with gpgme in gpg4win 1.1.3 In-Reply-To: <47F780C1.2000307@katehok.ac93.org> References: <47F780C1.2000307@katehok.ac93.org> Message-ID: <200804082235.03045.bernhard@intevation.de> On Saturday 05 April 2008 15:38, Igor Belyi wrote: > It looks like moderator for gpg4win mailing list is not around, so I'll > repost my message here. Well, Jan is around, but with so much spam that the lists are getting most moderators do not look into the queue very often. I suggest to subscribe yourself to most lists these days. (I have seen lists were posts will be silently discarded if you are on subscribed.) Anyway I have let through your post to gpg4win-users-de and also forward Marcus' answer there. Best, Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. 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: 1571 bytes Desc: not available URL: From wk at gnupg.org Wed Apr 9 10:10:05 2008 From: wk at gnupg.org (Werner Koch) Date: Wed, 09 Apr 2008 10:10:05 +0200 Subject: scim and pinentry-gtk2 In-Reply-To: <47FBB6C6.1030701@rlworkman.net> (Robby Workman's message of "Tue, 08 Apr 2008 13:17:42 -0500") References: <47BDF11A.8010500@rlworkman.net> <87hcfvg8wu.wl%marcus.brinkmann@ruhr-uni-bochum.de> <47E09E50.8040106@rlworkman.net> <87myo5wkg3.wl%marcus.brinkmann@ruhr-uni-bochum.de> <87myo45rkb.fsf@wheatstone.g10code.de> <47FBB6C6.1030701@rlworkman.net> Message-ID: <87d4oz30v6.fsf@wheatstone.g10code.de> On Tue, 8 Apr 2008 20:17, rw at rlworkman.net said: > Ideally, this could be done with native gtk, but yeah, if it can't be That is no contadiction. The framework integrates well with any GUI stuff. It merely handles the communication with the client (e.g. gpg-agent) and thus make sure that all pinentries of the pinentry package speak the same protocol. A generic GTK+ pinentry would be identically to the current one but not using the Secure Text Entry Widget. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From marcus.brinkmann at ruhr-uni-bochum.de Wed Apr 9 15:25:17 2008 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Wed, 09 Apr 2008 15:25:17 +0200 Subject: scim and pinentry-gtk2 In-Reply-To: <47FBB637.9070103@rlworkman.net> References: <47BDF11A.8010500@rlworkman.net> <87hcfvg8wu.wl%marcus.brinkmann@ruhr-uni-bochum.de> <47E09E50.8040106@rlworkman.net> <87myo5wkg3.wl%marcus.brinkmann@ruhr-uni-bochum.de> <47FBB637.9070103@rlworkman.net> Message-ID: <87iqyrw476.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Tue, 08 Apr 2008 13:15:19 -0500, Robby Workman wrote: > I suppose the command line option to pinentry might be acceptable, > but there would need to be some way to specify in gpg-agent that > pinentry should be called with the --scim (or whatever) option. > Perhaps it could check for the presence of the XIM_PROGRAM or > GTK_IM_MODULE environment variables and automatically do the right > thing. In response to this and Werner's concern, it could also be done by means of a wrapper script. But this is basically the same as a new binary, really. > Alternatively, a pinentry-scim binary (which could then be specified > in gpg-agent with --pinentry-program) would be acceptable, I suppose. Right. I would haggle about the name, because there is nothing special about scim (maybe the current gtk pinentry should be renamed instead), but the idea is the same. > I know basically nothing about gtk programming, but I must admit that > I find it hard to believe that there's no "correct" way to do this > in gtk without either command line options to pinentry or a special > pinentry binary -- obviously qt provides the ability, so surely gtk > does as well? I am not sure what you mean by "this" here. I have not looked into it yet. Anything is possible :) Thanks, Marcus From stknig at googlemail.com Fri Apr 4 08:47:34 2008 From: stknig at googlemail.com (Steve Knight) Date: Fri, 4 Apr 2008 09:47:34 +0300 Subject: GPGME & GPGCOM Message-ID: <6f8c26610804032347i5c48ae51sbba9cd05c48fb96a@mail.gmail.com> Hello, I was recently on the hunt for a COM component to use to be able to script GPG and include it in .NET projects etc. I found that GPGME has a COM server but it doesn't want to build for me which is probably something to do with my build environment not having all the required dependencies: stkni at ubuntu:~/pkgs/gpgme-1.1.4/complus$ make if i586-mingw32msvc-gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../jnlib -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -mms-bitfields -MT gpgcom.o -MD -MP -MF ".deps/gpgcom.Tpo" -c -o gpgcom.o gpgcom.c; \ then mv -f ".deps/gpgcom.Tpo" ".deps/gpgcom.Po"; else rm -f ".deps/gpgcom.Tpo"; exit 1; fi gpgcom.c:33:22: argparse.h: No such file or directory In file included from gpgcom.c:35: main.h:24:21: xmalloc.h: No such file or directory main.h:25:24: stringhelp.h: No such file or directory main.h:26:21: logging.h: No such file or directory ... snip ... I'm guessing that the build problem could be resolved but I was wondering what the status of GPGCOM is and whether I should spend time getting it to work or seek an alternative. I apologise if this has been asked before but I couldn't find an answer anywhere and I couldn't seem to search the mailman archives (trying to do so gives me HTTP 403: Forbidden). Many thanks, Steve Knight From dirtyepic at gentoo.org Sun Apr 6 07:59:24 2008 From: dirtyepic at gentoo.org (Ryan Hill) Date: Sat, 05 Apr 2008 23:59:24 -0600 Subject: Build failure with curl-7.18.1 and GCC 4.3 Message-ID: <47F866BC.6020402@gentoo.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello. I'm getting a compilation error building gnupg-2.0.9 using GCC 4.3 and curl-7.18.1. The error appears to be the result of this change from the curl release announcement: - added type checking macros for curl_easy_setopt() and curl_easy_getinfo(), watch out for new warnings in code using libcurl (needs gcc-4.3 and currently only works in C mode) http://curl.haxx.se/mail/lib-2008-02/0267.html http://curl.haxx.se/mail/lib-2008-02/0292.html i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I../gl -I../common -I../intl -DLOCALEDIR=\"/usr/share/locale\" -DGNUPG_BINDIR="\"/usr/bin\"" -DGNUPG_LIBEXECDIR="\"/usr/libexec\"" -DGNUPG_LIBDIR="\"/usr/lib/gnupg\"" -DGNUPG_DATADIR="\"/usr/share/gnupg\"" -DGNUPG_SYSCONFDIR="\"/etc/gnupg\"" -O2 -g -march=prescott -fomit-frame-pointer -pipe -fdirectives-only -Wall -Wno-pointer-sign -Wpointer-arith -MT gpg2keys_curl-gpgkeys_curl.o -MD -MP -MF .deps/gpg2keys_curl-gpgkeys_curl.Tpo -c -o gpg2keys_curl-gpgkeys_curl.o `test -f 'gpgkeys_curl.c' || echo './'`gpgkeys_curl.c gpgkeys_curl.c: In function 'main': gpgkeys_curl.c:303: error: 'typeof' applied to a bit-field -- fonts, gcc-porting, by design, by neglect mips, treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEAREIAAYFAkf4Y44ACgkQiqiDRvmkBmIhcQCeP24txWEQ9N764cq7WcY4cZN3 VxQAn0c4sD4yyFXIvmltiLKsiDGPLSRK =RXvp -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From mca_debu at yahoo.co.in Tue Apr 8 15:47:40 2008 From: mca_debu at yahoo.co.in (Debabrata Das) Date: Tue, 8 Apr 2008 14:47:40 +0100 (BST) Subject: Need Help Message-ID: <304216.41718.qm@web94109.mail.in2.yahoo.com> Hi All, Currently we are using GnuPG 1.4.7 which is under GPL V2 on HP-UX ,but we came to know that there is a security vulnerability on GnuPG 1.4.8 & earlier version.Since Gnupg 1.4.9 is under GPL V3 & we don't want to move to product under GPL v3.Can you please tell us if it is permissible to back port all the changes made to GnuPg 1.4.9 on to Gnupg 1.4.7. We are interested to use whatever the changes made to bug-fix release Gnupg 1.4.9 on to Gnupg 1.4.7 which is under GPL V2 and use it. Looking forward for your response. Regards Debabrata India --------------------------------- Bring your gang together. Do your thing. Find your favourite Yahoo! Group. -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.esp at free.fr Fri Apr 11 15:31:23 2008 From: g.esp at free.fr (Gilles Espinasse) Date: Fri, 11 Apr 2008 15:31:23 +0200 Subject: Need Help backporting from 1.4.9 to 1.4.7 In-Reply-To: <304216.41718.qm@web94109.mail.in2.yahoo.com> References: <304216.41718.qm@web94109.mail.in2.yahoo.com> Message-ID: <1207920683.47ff682b678c3@imp.free.fr> Selon Debabrata Das : > Hi All, > > Currently we are using GnuPG 1.4.7 which is under GPL V2 on HP-UX ,but we > came to know that there is a security vulnerability on GnuPG 1.4.8 & earlier > version.Since Gnupg 1.4.9 is under GPL V3 & we don't want to move to product > under GPL v3.Can you please tell us if it is permissible to back port all > the changes made to GnuPg 1.4.9 on to Gnupg 1.4.7. > 1.4.9 announce state that : "... Version 1.4.9. This is a maintenance release to fix a possible vulnerability introduced with 1.4.8. ..." http://lists.gnupg.org/pipermail/gnupg-announce/2008q1/000272.html So my understanding is that 1.4.7 is not vulnerable to the problem fixed in 1.4.9. Please use a meaningfull title the next time. Gilles From wk at gnupg.org Fri Apr 11 21:49:49 2008 From: wk at gnupg.org (Werner Koch) Date: Fri, 11 Apr 2008 21:49:49 +0200 Subject: GPGME & GPGCOM In-Reply-To: <6f8c26610804032347i5c48ae51sbba9cd05c48fb96a@mail.gmail.com> (Steve Knight's message of "Fri, 4 Apr 2008 09:47:34 +0300") References: <6f8c26610804032347i5c48ae51sbba9cd05c48fb96a@mail.gmail.com> Message-ID: <87ej9cqihu.fsf@wheatstone.g10code.de> On Fri, 4 Apr 2008 08:47, stknig at googlemail.com said: > script GPG and include it in .NET projects etc. I found that GPGME > has a COM server but it doesn't want to build for me which is probably > something to do with my build environment not having all the required Well that thing is close to 7 years old. I doubt it is of any use today. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Fri Apr 11 21:51:58 2008 From: wk at gnupg.org (Werner Koch) Date: Fri, 11 Apr 2008 21:51:58 +0200 Subject: Need Help backporting from 1.4.9 to 1.4.7 In-Reply-To: <1207920683.47ff682b678c3@imp.free.fr> (Gilles Espinasse's message of "Fri, 11 Apr 2008 15:31:23 +0200") References: <304216.41718.qm@web94109.mail.in2.yahoo.com> <1207920683.47ff682b678c3@imp.free.fr> Message-ID: <87abk0qie9.fsf@wheatstone.g10code.de> On Fri, 11 Apr 2008 15:31, g.esp at free.fr said: > So my understanding is that 1.4.7 is not vulnerable to the problem fixed in > 1.4.9. Correct. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From dshaw at jabberwocky.com Fri Apr 11 22:17:27 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 11 Apr 2008 16:17:27 -0400 Subject: Need Help In-Reply-To: <304216.41718.qm@web94109.mail.in2.yahoo.com> References: <304216.41718.qm@web94109.mail.in2.yahoo.com> Message-ID: <20080411201727.GA1546@jabberwocky.com> On Tue, Apr 08, 2008 at 02:47:40PM +0100, Debabrata Das wrote: > Hi All, > > Currently we are using GnuPG 1.4.7 which is under GPL V2 on HP-UX ,but we came to know that there is a security vulnerability on GnuPG 1.4.8 & earlier version.Since Gnupg 1.4.9 is under GPL V3 & we don't want to move to product under GPL v3.Can you please tell us if it is permissible to back port all the changes made to GnuPg 1.4.9 on to Gnupg 1.4.7. The recent bug only applies to 1.4.8 and 2.0.8. It does not apply to 1.4.7 or any earlier version. There is no need to backport any patches. David From ladislav.hagara at unob.cz Sat Apr 12 02:39:31 2008 From: ladislav.hagara at unob.cz (Ladislav Hagara) Date: Sat, 12 Apr 2008 02:39:31 +0200 Subject: GPGME & GPGCOM In-Reply-To: <6f8c26610804032347i5c48ae51sbba9cd05c48fb96a@mail.gmail.com> References: <6f8c26610804032347i5c48ae51sbba9cd05c48fb96a@mail.gmail.com> Message-ID: <480004C3.4000007@unob.cz> > > I apologise if this has been asked before but I couldn't find an > answer anywhere and I couldn't seem to search the mailman archives > (trying to do so gives me HTTP 403: Forbidden). Here is a bugreport I created https://bugs.g10code.com/gnupg/issue900 (3 days ago). The correct link to archive is http://lists.gnupg.org/pipermail/gnupg-devel/ -- Ladislav Hagara From ladislav.hagara at unob.cz Sun Apr 13 13:04:49 2008 From: ladislav.hagara at unob.cz (Ladislav Hagara) Date: Sun, 13 Apr 2008 13:04:49 +0200 Subject: Build failure with curl-7.18.1 and GCC 4.3 In-Reply-To: <47F866BC.6020402@gentoo.org> References: <47F866BC.6020402@gentoo.org> Message-ID: <4801E8D1.7070009@unob.cz> > Hello. I'm getting a compilation error building gnupg-2.0.9 using GCC > 4.3 and curl-7.18.1. V Source Mage GNU/Linux we have this path http://bugs.sourcemage.org/attachment.cgi?id=6992 The same problem is with gnupg-1.4.9, patch http://bugs.sourcemage.org/attachment.cgi?id=6991 Our Bugzilla Bug 14446 http://bugs.sourcemage.org/show_bug.cgi?id=14446 -- Ladislav Hagara From dshaw at jabberwocky.com Sun Apr 13 16:13:03 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 13 Apr 2008 10:13:03 -0400 Subject: Build failure with curl-7.18.1 and GCC 4.3 In-Reply-To: <4801E8D1.7070009@unob.cz> References: <47F866BC.6020402@gentoo.org> <4801E8D1.7070009@unob.cz> Message-ID: <1F19D6CC-807C-432F-8BB5-AAFB012BF48C@jabberwocky.com> On Apr 13, 2008, at 7:04 AM, Ladislav Hagara wrote: > >> Hello. I'm getting a compilation error building gnupg-2.0.9 using >> GCC >> 4.3 and curl-7.18.1. > > > V Source Mage GNU/Linux we have this path http://bugs.sourcemage.org/attachment.cgi?id=6992 > The same problem is with gnupg-1.4.9, patch http://bugs.sourcemage.org/attachment.cgi?id=6991 This seems to be an issue between GPG and the new curl. I don't see GCC involvement here. There is some macro magic using 'typeof' that didn't exist in earlier versions of curl. I've notified the curl folks. It's not clear yet where the best fix is, but there will be one soon. David From stknig at googlemail.com Mon Apr 14 07:42:31 2008 From: stknig at googlemail.com (Steve Knight) Date: Mon, 14 Apr 2008 08:42:31 +0300 Subject: GPGME & GPGCOM In-Reply-To: <87ej9cqihu.fsf@wheatstone.g10code.de> References: <6f8c26610804032347i5c48ae51sbba9cd05c48fb96a@mail.gmail.com> <87ej9cqihu.fsf@wheatstone.g10code.de> Message-ID: <6f8c26610804132242m11e9ed97i72a5c635f7cfa558@mail.gmail.com> I see, thanks. Is there any interest in creating a GPGME based .NET or COM wrapper? Or is this not a direction you really want to go in? Steve On Fri, Apr 11, 2008 at 10:49 PM, Werner Koch wrote: > On Fri, 4 Apr 2008 08:47, stknig at googlemail.com said: > > > script GPG and include it in .NET projects etc. I found that GPGME > > has a COM server but it doesn't want to build for me which is probably > > something to do with my build environment not having all the required > > Well that thing is close to 7 years old. I doubt it is of any use > today. > > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. > > From dshaw at jabberwocky.com Mon Apr 14 17:58:23 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 14 Apr 2008 11:58:23 -0400 Subject: Build failure with curl-7.18.1 and GCC 4.3 In-Reply-To: <4801E8D1.7070009@unob.cz> References: <47F866BC.6020402@gentoo.org> <4801E8D1.7070009@unob.cz> Message-ID: <20080414155823.GC54766@jabberwocky.com> On Sun, Apr 13, 2008 at 01:04:49PM +0200, Ladislav Hagara wrote: > >> Hello. I'm getting a compilation error building gnupg-2.0.9 using GCC >> 4.3 and curl-7.18.1. > > > V Source Mage GNU/Linux we have this path > http://bugs.sourcemage.org/attachment.cgi?id=6992 > The same problem is with gnupg-1.4.9, patch > http://bugs.sourcemage.org/attachment.cgi?id=6991 > > Our Bugzilla Bug 14446 > http://bugs.sourcemage.org/show_bug.cgi?id=14446 This is an issue with how GPG is passing arguments to curl. I've attached the patch I'm about to commit. It applies to either 1.4.9 or 2.0.9. David -------------- next part -------------- Index: gpgkeys_curl.c =================================================================== --- gpgkeys_curl.c (revision 4741) +++ gpgkeys_curl.c (working copy) @@ -286,7 +286,7 @@ if(follow_redirects) { - curl_easy_setopt(curl,CURLOPT_FOLLOWLOCATION,1); + curl_easy_setopt(curl,CURLOPT_FOLLOWLOCATION,1L); if(follow_redirects>0) curl_easy_setopt(curl,CURLOPT_MAXREDIRS,follow_redirects); } @@ -298,10 +298,10 @@ { fprintf(console,"gpgkeys: curl version = %s\n",curl_version()); curl_easy_setopt(curl,CURLOPT_STDERR,console); - curl_easy_setopt(curl,CURLOPT_VERBOSE,1); + curl_easy_setopt(curl,CURLOPT_VERBOSE,1L); } - curl_easy_setopt(curl,CURLOPT_SSL_VERIFYPEER,opt->flags.check_cert); + curl_easy_setopt(curl,CURLOPT_SSL_VERIFYPEER,(long)opt->flags.check_cert); curl_easy_setopt(curl,CURLOPT_CAINFO,opt->ca_cert_file); if(proxy) Index: gpgkeys_hkp.c =================================================================== --- gpgkeys_hkp.c (revision 4741) +++ gpgkeys_hkp.c (working copy) @@ -202,9 +202,9 @@ fprintf(console,"gpgkeys: HTTP URL is `%s'\n",request); curl_easy_setopt(curl,CURLOPT_URL,request); - curl_easy_setopt(curl,CURLOPT_POST,1); + curl_easy_setopt(curl,CURLOPT_POST,1L); curl_easy_setopt(curl,CURLOPT_POSTFIELDS,key); - curl_easy_setopt(curl,CURLOPT_FAILONERROR,1); + curl_easy_setopt(curl,CURLOPT_FAILONERROR,1L); res=curl_easy_perform(curl); if(res!=0) @@ -661,7 +661,7 @@ { fprintf(console,"gpgkeys: curl version = %s\n",curl_version()); curl_easy_setopt(curl,CURLOPT_STDERR,console); - curl_easy_setopt(curl,CURLOPT_VERBOSE,1); + curl_easy_setopt(curl,CURLOPT_VERBOSE,1L); } if(proxy) From marcus.brinkmann at ruhr-uni-bochum.de Mon Apr 14 18:11:02 2008 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Mon, 14 Apr 2008 18:11:02 +0200 Subject: GPGME & GPGCOM In-Reply-To: <6f8c26610804132242m11e9ed97i72a5c635f7cfa558@mail.gmail.com> References: <6f8c26610804032347i5c48ae51sbba9cd05c48fb96a@mail.gmail.com> <87ej9cqihu.fsf@wheatstone.g10code.de> <6f8c26610804132242m11e9ed97i72a5c635f7cfa558@mail.gmail.com> Message-ID: <87abjwh0x4.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Mon, 14 Apr 2008 08:42:31 +0300, "Steve Knight" wrote: > > I see, thanks. Is there any interest in creating a GPGME based .NET > or COM wrapper? > > Or is this not a direction you really want to go in? We don't have any need for this ourselves, but we generally appreciate language bindings of GPGME (and other libraries) for a diverse set of languages. Thanks, Marcus -- g10 Code GmbH http://g10code.com AmtsGer. Wuppertal HRB 14459 H?ttenstr. 61 Gesch?ftsf?hrung Werner Koch D-40699 Erkrath -=- The GnuPG Experts -=- USt-Id DE215605608 From bh at intevation.de Tue Apr 15 12:25:43 2008 From: bh at intevation.de (Bernhard Herzog) Date: Tue, 15 Apr 2008 12:25:43 +0200 Subject: Errors running PKITS tests Message-ID: <200804151225.47927.bh@intevation.de> Hi, I'm trying to run the PKITS tests that are part of gnugp2 trunk rev. 4740. "make" followed by "make check" fails with errors: make[3]: Entering directory `/tmp/checkout2/tests/pkits' FAIL: import-all-certs FAIL: validate-all-certs /bin/sh: line 8: ./signature-verification: Permission denied FAIL: signature-verification /bin/sh: line 8: ./validity-periods: Permission denied FAIL: validity-periods [... snip more "Permission denied" messages ... ] FAIL: private-certificate-extensions ==================================== 18 of 18 tests failed Please report to bug-gnupg at gnupg.org The executable permission is missing from many of the test scripts. Regards, Bernhard -- Bernhard Herzog Intevation GmbH, Osnabr?ck Amtsgericht Osnabr?ck, HR B 18998 http://www.intevation.de/ 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: 189 bytes Desc: not available URL: From wk at gnupg.org Tue Apr 15 17:34:23 2008 From: wk at gnupg.org (Werner Koch) Date: Tue, 15 Apr 2008 17:34:23 +0200 Subject: Errors running PKITS tests In-Reply-To: <200804151225.47927.bh@intevation.de> (Bernhard Herzog's message of "Tue, 15 Apr 2008 12:25:43 +0200") References: <200804151225.47927.bh@intevation.de> Message-ID: <87y77fi134.fsf@wheatstone.g10code.de> On Tue, 15 Apr 2008 12:25, bh at intevation.de said: > The executable permission is missing from many of the test scripts. I just added them. (rev 4745). Don't expect that all tests will pass. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From robertburrelldonkin at blueyonder.co.uk Sun Apr 20 11:58:54 2008 From: robertburrelldonkin at blueyonder.co.uk (Robert Burrell Donkin) Date: Sun, 20 Apr 2008 10:58:54 +0100 Subject: "an mpi of size 0 is not allowed" in 2.0.9 Message-ID: <1208685534.6125.34.camel@localhost> hi i've been happily using GnuPG for many years now and have had nothing but good things to say about it. kudos to everyone who developed it. now that gentoo has upgraded to 2.0.x, i'm having some problems with my existing key rings. for example $ gpg --refresh-keys an mpi of size 0 is not allowed gpg: keyring_get_keyblock: read error: Invalid packet gpg: error reading keyblock: Invalid keyring gpg: keyserver refresh failed: Invalid keyring this still happens with the latest version supported by gentoo: $ gpg --version gpg (GnuPG) 2.0.9 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: ~/.gnupg Supported algorithms: Pubkey: RSA, ELG, DSA Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB Used libraries: gcrypt(1.4.0) the keyring is complex (main secret key removed, email signing subkey retained) but 1.4.x coped fine with it - robert -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mumbaihawk at sbcglobal.net Sat Apr 12 03:12:00 2008 From: mumbaihawk at sbcglobal.net (Mumbai Hawk) Date: Fri, 11 Apr 2008 20:12:00 -0500 Subject: help with bug Message-ID: <48000C60.7040102@sbcglobal.net> Have a bug of some kind. When trying to send it wants a key that I do not have. The key it wants has been over written and is no more. So how do you get the program to forget the keys you do not have and use a new key. It keeps saying it can not encrypt and throws up the key number 0x73dfbf16. Program has been uninstalled. Entery in registery set back to 0000 and other file deleted. The application files have been deleted for it. Still when you reinstall it and try to encrypt from the mumbaihawk at sbcglobal.net address it asks for the key I do not have and will not use the new one. I just do not understand where it is getting this key number from. I feel if I wipe the drive it still may come back to haunt me. The program is GPG -- Have a very wonderful day, Mumbai Hawk http://360.yahoo.com/mumbaihawk at sbcglobal.net http://www.flickr.com/photos/mumbaihawk/ From eric at sandall.us Sun Apr 13 12:05:37 2008 From: eric at sandall.us (Eric Sandall) Date: Sun, 13 Apr 2008 03:05:37 -0700 Subject: Build failure with curl-7.18.1 and GCC 4.3 Message-ID: <200804130305.41140.eric@sandall.us> Ryan, I have a quick and dirty hack for the same issue which we ran into. The patches are attached and available in our bug report for gnupg 1.4.9 and 2.0.9 at http://bugs.sourcemage.org/show_bug.cgi?id=14446. All the patches do are obfuscate that we're passing a bit-field. :/ Hope this helps, -sandalle PS: I am not subscribed to gnupg-devel -- Eric Sandall | Source Mage GNU/Linux Developer eric at sandall.us PGP: 0xA8EFDD61 | http://www.sourcemage.org/ http://eric.sandall.us/ | http://counter.li.org/ #196285 -------------- next part -------------- A non-text attachment was scrubbed... Name: gnupg-1.4.9-gcc43.patch Type: text/x-diff Size: 845 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gnupg-2.0.9-gcc43.patch Type: text/x-diff Size: 845 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From Paul.Hicks at Sensis.com.au Mon Apr 21 02:50:17 2008 From: Paul.Hicks at Sensis.com.au (Hicks, Paul) Date: Mon, 21 Apr 2008 10:50:17 +1000 Subject: Exec Error Warning: This messages modification detection code does not match the message. This means it is likely the message has been changed since the time it was encrypted. Message-ID: <472AAF63A310604C99AA54DDCEBEADBA0AC9DA5B@C1-EXG-VS1.corp.org.local> Hello, I'm hoping someone may be able to help us interpret the following error message: Exec Error Warning: This messages modification detection code does not match the message. This means it is likely the message has been changed since the time it was encrypted. We are currently trying to test the software and as such a new key has been created, which was used to encrypt a simple XLS test file. Many thanks Paul Paul Hicks Privacy Business Operations Manager Strategic Marketing Sensis t +61 3 8653 8027 m 0437 175 921 e paul.hicks at sensis.com.au Sensis. Australia's leading information resource. Making complex lives simpler by helping you find, buy and sell. www.sensis.com.au - www.yellow.com.au - www.whitepages.com.au - www.citysearch.com.au - www.about.sensis.com.au www.whereis.com.au - www.gostay.com.au - www.justlisted.com.au - www.tradingpost.com.au - www.linkme.com.au www.carshowroom.com.au - www.telstra.com.au - www.smallbusiness.sensis.com.au - www.universalpublishers.com.au Sensis cares for the environment - think before you print. This email and any attachments are intended only for the use of the recipient and may be confidential and/or legally privileged. Sensis Pty Ltd disclaims liability for any errors, omissions, viruses, loss and/or damage arising from using, opening or transmitting this email. If you are not the intended recipient you must not use, interfere with, disclose, copy or retain this email and you should notify the sender immediately by return email or by contacting Sensis Pty Ltd by telephone on [+61 3 8653 5000] -------------- next part -------------- An HTML attachment was scrubbed... URL: From rwillmer at gmail.com Mon Apr 21 12:50:29 2008 From: rwillmer at gmail.com (Rachel Willmer) Date: Mon, 21 Apr 2008 11:50:29 +0100 Subject: Exec Error Warning: This messages modification detection code does not match the message. This means it is likely the message has been changed since the time it was encrypted. In-Reply-To: <472AAF63A310604C99AA54DDCEBEADBA0AC9DA5B@C1-EXG-VS1.corp.org.local> References: <472AAF63A310604C99AA54DDCEBEADBA0AC9DA5B@C1-EXG-VS1.corp.org.local> Message-ID: <5cd112870804210350s68192843ge81ccabb42e3a841@mail.gmail.com> On 21/04/2008, Hicks, Paul wrote: > > Hello, > > > > I'm hoping someone may be able to help us interpret the following error > message: > > > > *Exec Error Warning: This messages modification detection code does not > match the message. This means it is likely the message has been changed > since the time it was encrypted.* > The "Modification Detection Code" is a OpenPGP packet which is created at the time of encryption, which contains a SHA-1 hash of the plaintext data. It is analagous to a checksum, and is encrypted together with the plaintext. What the error message is saying (I think) is that the decryption process which you're running is recreating that hash from the plaintext it has found, and it doesn't match the original hash (which it should). Sections 5.13 and 5.14 of RFC 4880 talk about the use of the MDC packet in more detail. HTH Rachel -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrick.riley at primefactors.com Thu Apr 24 15:00:55 2008 From: patrick.riley at primefactors.com (Patrick Riley) Date: Thu, 24 Apr 2008 08:00:55 -0500 Subject: New to the group Message-ID: <2555E772820BC84891BF58D2CBAC745C01A1FFEE@mail-21ps.atlarge.net> I am new to the group and was wondering how active it is? Thanks, Patrick -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Thu Apr 24 17:56:20 2008 From: wk at gnupg.org (Werner Koch) Date: Thu, 24 Apr 2008 17:56:20 +0200 Subject: ADNS update Message-ID: <87wsmnckm3.fsf@wheatstone.g10code.de> Hi! There is a new keyserver helper in GnuPG which uses ADNS. To make it work on Windows too, I have created an updated ADNS package. The adns ML seems to have some problems, thus I re-post here. Salam-Shalom, Werner -------------- next part -------------- An embedded message was scrubbed... From: unknown sender Subject: Topics Date: no date Size: 164 URL: -------------- next part -------------- An embedded message was scrubbed... From: Werner Koch Subject: New build system and Windows support Date: Thu, 24 Apr 2008 14:11:07 +0200 Size: 4133 URL: -------------- next part -------------- An embedded message was scrubbed... From: Werner Koch Subject: Re: New build system and Windows support Date: Thu, 24 Apr 2008 17:45:46 +0200 Size: 1779 URL: -------------- next part -------------- -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From aoz.syn at gmail.com Thu Apr 24 16:04:51 2008 From: aoz.syn at gmail.com (RB) Date: Thu, 24 Apr 2008 08:04:51 -0600 Subject: Static linking Message-ID: <4255c2570804240704se2535b4re369b330d30634cd@mail.gmail.com> I'm working on a Linux preboot environment in which I'd like to include GPG support for key storage (i.e. 'gpg --decrypt --quiet foo.asc | cryptsetup...'). I find that at least my distro (Gentoo) stopped providing the ability to statically link GPG with version 2, but when I hand-compile with LDFLAGS='-static', everything comes out fine. I've been told that 'upstream' (you guys) stopped supporting static linking with 2.x; I'm fine without support, but do any of you see or know of any issues or pitfalls one would run into? Doing the leg work for testing and such really doesn't bother me, just want to make sure I'm not painting myself into a corner, cryptographically or not. Thanks for your time! RB From g.esp at free.fr Thu Apr 24 19:55:56 2008 From: g.esp at free.fr (Gilles Espinasse) Date: Thu, 24 Apr 2008 19:55:56 +0200 Subject: Static linking References: <4255c2570804240704se2535b4re369b330d30634cd@mail.gmail.com> Message-ID: <436f01c8a634$728f8e20$f9b5a8c0@pii350> ----- Original Message ----- From: "RB" To: Sent: Thursday, April 24, 2008 4:04 PM Subject: Static linking > I'm working on a Linux preboot environment in which I'd like to > include GPG support for key storage (i.e. 'gpg --decrypt --quiet > foo.asc | cryptsetup...'). I find that at least my distro (Gentoo) > stopped providing the ability to statically link GPG with version 2, > but when I hand-compile with LDFLAGS='-static', everything comes out > fine. > Did you need the fancy v2 features on a preboot environment? Is not 1.4 enought for that? Gilles From wk at gnupg.org Thu Apr 24 20:00:23 2008 From: wk at gnupg.org (Werner Koch) Date: Thu, 24 Apr 2008 20:00:23 +0200 Subject: Static linking In-Reply-To: <4255c2570804240704se2535b4re369b330d30634cd@mail.gmail.com> (aoz.syn@gmail.com's message of "Thu, 24 Apr 2008 08:04:51 -0600") References: <4255c2570804240704se2535b4re369b330d30634cd@mail.gmail.com> Message-ID: <874p9rcevc.fsf@wheatstone.g10code.de> On Thu, 24 Apr 2008 16:04, aoz.syn at gmail.com said: > I've been told that 'upstream' (you guys) stopped supporting static > linking with 2.x; I'm fine without support, but do any of you see or Do we? Frankly, I even don't know how to disable that. Anyway it does not make much sense to do so because you will have several copies of the same libraies in activly in use. For a preboot thing I would not suggest to use GnuPG-2, though. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From aoz.syn at gmail.com Thu Apr 24 21:26:06 2008 From: aoz.syn at gmail.com (RB) Date: Thu, 24 Apr 2008 13:26:06 -0600 Subject: Static linking In-Reply-To: <874p9rcevc.fsf@wheatstone.g10code.de> References: <4255c2570804240704se2535b4re369b330d30634cd@mail.gmail.com> <874p9rcevc.fsf@wheatstone.g10code.de> Message-ID: <4255c2570804241226l11c28bdcn2a277730550c67b8@mail.gmail.com> Two-for-one - hope you guys don't mind. On 4/24/08, Gilles Espinasse wrote: > Did you need the fancy v2 features on a preboot environment? > Is not 1.4 enought for that? I really only need one feature - decryption, but am trying to make a generalized, long-term addition to Gentoo's genkernel. My purpose in trying to use the latest version was threefold: to minimize end-user complexity, avoid maintenance beyond normal upgrades, and head off questions like, "why do I have to be behind the times to use this?" Too many people (particularly on my favorite distro) have a [wrong] impression that if we're not running today's SVN release, something is wrong. On 4/24/08, Werner Koch wrote: > Do we? Frankly, I even don't know how to disable that. >From what I see, the '--enable-static' configuration argument and its ilk were removed with gnupg-2. My experiment with LDFLAGS has shown that doesn't prevent static linking, but it's not explicitly supported by the build process; you have to know what you're doing (which is good, IMHO). > Anyway it does not make much sense to do so because you will have > several copies of the same libraies in activly in use. Agreed and understood; I would rather have a unified init environment myself, but don't have the private time right now to spend doing a proper re-structure of the entire initrd build. For the time being I'm willing to stick with the existing standard of 'add a static binary to extend genkernel' and sacrifice some init efficiency for expediency. Unless, of course, there exists some edge case particular to gnupg that I don't know about, which is why I came to you guys. > For a preboot thing I would not suggest to use GnuPG-2, though. If I may ask, then, what would you suggest? My only real requirement is to get away from storing unencrypted key material on-disk, unless someone can make a good case that it provides no reasonable additional security. Overall, my goal is solely to improve key storage for genkernel without excessively increasing user complexity, and am willing to listen to suggestions on how to achieve that. RB From g.esp at free.fr Thu Apr 24 21:33:37 2008 From: g.esp at free.fr (Gilles Espinasse) Date: Thu, 24 Apr 2008 21:33:37 +0200 Subject: Static linking References: <4255c2570804240704se2535b4re369b330d30634cd@mail.gmail.com><874p9rcevc.fsf@wheatstone.g10code.de> <4255c2570804241226l11c28bdcn2a277730550c67b8@mail.gmail.com> Message-ID: <43b401c8a642$17db27b0$f9b5a8c0@pii350> ----- Original Message ----- From: "RB" To: Sent: Thursday, April 24, 2008 9:26 PM Subject: Re: Static linking > Two-for-one - hope you guys don't mind. > > On 4/24/08, Gilles Espinasse wrote: > > Did you need the fancy v2 features on a preboot environment? > > Is not 1.4 enought for that? > I really only need one feature - decryption, but am trying to make a > generalized, long-term addition to Gentoo's genkernel. My purpose in > trying to use the latest version was threefold: to minimize end-user > complexity, avoid maintenance beyond normal upgrades, and head off > questions like, "why do I have to be behind the times to use this?" > Too many people (particularly on my favorite distro) have a [wrong] > impression that if we're not running today's SVN release, something is > wrong. > In that case, read them the arguments taken from any last gnupg-1.4 announces http://lists.gnupg.org/pipermail/gnupg-announce/2007q4/000266.html That should be enought Gilles From aoz.syn at gmail.com Thu Apr 24 22:16:20 2008 From: aoz.syn at gmail.com (RB) Date: Thu, 24 Apr 2008 14:16:20 -0600 Subject: Static linking In-Reply-To: <43b401c8a642$17db27b0$f9b5a8c0@pii350> References: <4255c2570804240704se2535b4re369b330d30634cd@mail.gmail.com> <874p9rcevc.fsf@wheatstone.g10code.de> <4255c2570804241226l11c28bdcn2a277730550c67b8@mail.gmail.com> <43b401c8a642$17db27b0$f9b5a8c0@pii350> Message-ID: <4255c2570804241316g3d0c1098h4a78cbdad4dae6fa@mail.gmail.com> On 4/24/08, Gilles Espinasse wrote: > In that case, read them the arguments taken from any last gnupg-1.4 > announces > http://lists.gnupg.org/pipermail/gnupg-announce/2007q4/000266.html > That should be enought That's encouraging and helpful, but doesn't really fulfill the complexity requirements I am striving for, since it would require a version that will make most users have to uninstall gnupg-2 (the way Gentoo is packaging it now). I'll talk to the current package maintainer about slotting it to make this easier, but they seem to have their minds made up about 1.x versus 2.x (https://bugs.gentoo.org/show_bug.cgi?id=159623#c2). Adding to the problem is that the tools added to init (LVM2, cryptsetup, etc) are not bundled or built with the package that generates the initrd; rather, they are borrowed from the existing userspace. I didn't design it, but regardless of aesthetics it works and carries as little baggage around with it as possible. Your opposition to the unnecessary features is understandable, but do you know of any issues particular to static linking on the 2.x branch? From wk at gnupg.org Fri Apr 25 09:43:26 2008 From: wk at gnupg.org (Werner Koch) Date: Fri, 25 Apr 2008 09:43:26 +0200 Subject: Static linking In-Reply-To: <4255c2570804241226l11c28bdcn2a277730550c67b8@mail.gmail.com> (aoz.syn@gmail.com's message of "Thu, 24 Apr 2008 13:26:06 -0600") References: <4255c2570804240704se2535b4re369b330d30634cd@mail.gmail.com> <874p9rcevc.fsf@wheatstone.g10code.de> <4255c2570804241226l11c28bdcn2a277730550c67b8@mail.gmail.com> Message-ID: <87mynibcrl.fsf@wheatstone.g10code.de> On Thu, 24 Apr 2008 21:26, aoz.syn at gmail.com said: > I really only need one feature - decryption, but am trying to make a In this case it might be useful to write a new application just for this purpose. The major part of gpg is about key management, and coping with all kinds of OpenPGP features. In fact, it seems that you can control how the encrypted OpenPGP data is made up (Algorithms for example). Thus it will be very easy to write code which just takes care of such OpenPGP message (e.g. RSA, AES and SHA-1). Add a basic keyring parsing and a way t provide a passpharse and you are mostly done. Last year I started with a project to write a minimal OpenPGP allication, called tgpg. It is designed as a library and thus it should be possible to include it in grub. There is some basic code already but is far from being finished. It might be a starting point. >>From what I see, the '--enable-static' configuration argument and its > ilk were removed with gnupg-2. My experiment with LDFLAGS has shown Hmmm. This configure option is due to libtool. Because GnupG does not use libtool I don't udnerstand why it should have been there at all. > expediency. Unless, of course, there exists some edge case particular > to gnupg that I don't know about, which is why I came to you guys. Not that I know. > If I may ask, then, what would you suggest? My only real requirement > is to get away from storing unencrypted key material on-disk, unless > someone can make a good case that it provides no reasonable additional A new package based on gnupg-1 which just the minla features enabled? Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From aoz.syn at gmail.com Fri Apr 25 16:34:41 2008 From: aoz.syn at gmail.com (RB) Date: Fri, 25 Apr 2008 08:34:41 -0600 Subject: Static linking In-Reply-To: <87mynibcrl.fsf@wheatstone.g10code.de> References: <4255c2570804240704se2535b4re369b330d30634cd@mail.gmail.com> <874p9rcevc.fsf@wheatstone.g10code.de> <4255c2570804241226l11c28bdcn2a277730550c67b8@mail.gmail.com> <87mynibcrl.fsf@wheatstone.g10code.de> Message-ID: <4255c2570804250734h7ba2aeafoa31716cc199a18f5@mail.gmail.com> On 4/25/08, Werner Koch wrote: > In this case it might be useful to write a new application just for this I had considered this and like the idea, but it may end up being stage 3 of this project. Stage 2 would fall more along the lines of Gilles' suggestions and involve doing a proper build focused on embedded use instead of borrowing static binaries from userspace. > allication, called tgpg. It is designed as a library and thus it should > be possible to include it in grub. There is some basic code already but > is far from being finished. It might be a starting point. I like that idea - may have to request that code from you shortly, unless it's already in the gnupg SVN tree. An interesting (to me) idea would be tying it together with some of the TrouSerS patches for GRUB and using the TPM as a smartcard. > > expediency. Unless, of course, there exists some edge case particular > > to gnupg that I don't know about, which is why I came to you guys. > > > Not that I know. > > > > If I may ask, then, what would you suggest? My only real requirement > > is to get away from storing unencrypted key material on-disk, unless > > someone can make a good case that it provides no reasonable additional > > > A new package based on gnupg-1 which just the minla features enabled? Great, and thanks for your input! I'll scratch my immediate itch and do a set of static binaries, then will start on implementing it properly. I like the idea of (and have had need before for) a simple, small 'degpg' program that just does basic password or keyring-based decryption. Thanks! From wk at gnupg.org Fri Apr 25 18:51:21 2008 From: wk at gnupg.org (Werner Koch) Date: Fri, 25 Apr 2008 18:51:21 +0200 Subject: [Announce] Libgcrypt 1.4.1 released Message-ID: <87ve2598ty.fsf@wheatstone.g10code.de> Hello! The GNU project is pleased to announce the availability of Libgcrypt version 1.4.1. This is a maintenance release to fix a few problems. Libgcrypt is a general purpose library of cryptographic building blocks. It is originally based on code used by GnuPG. It does not provide any implementation of OpenPGP or other protocols. Thorough understanding of applied cryptography is required to use Libgcrypt. Noteworthy changes in version 1.4.1 (2008-04-25) ------------------------------------------------ * Fixed a bug introduced by 1.3.1 which led to the comsumption of far too much entropy for the intial seeding. * Improved AES performance for CFB and CBC modes. * Removed build problems for the Padlock support. 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.4.1.tar.bz2 (946k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.4.1.tar.bz2.sig This file is bzip2 compressed. A gzip compressed version is also available: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.4.1.tar.gz (1179k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.4.1.tar.gz.sig Alternativley you may upgrade version 1.4.0 using this patch file: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.4.0-1.4.1.diff.bz2 (49k) The SHA-1 checksums are: 367fe7fecd2ed4ab743849279dbc2f7e148f9956 libgcrypt-1.4.1.tar.bz2 36f1c6632fa06a6d3c92f83c3cdca8c7731a4220 libgcrypt-1.4.1.tar.gz 458fa5939df46da383df64b27ed8f8f580931618 libgcrypt-1.4.0-1.4.1.diff.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 http://www.gnupg.org/documentation/mailing-lists.html . [2] Note that copyright assignments to the FSF are required. [3] For example http://www.fsfeurope.org/help/donate.en.html . [4] See the service directory at http://www.gnupg.org/service.html . -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 205 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 g.esp at free.fr Sat Apr 26 09:40:33 2008 From: g.esp at free.fr (Gilles Espinasse) Date: Sat, 26 Apr 2008 09:40:33 +0200 Subject: configure -enable-minimal failure Message-ID: <44ed01c8a770$cfb28ca0$f9b5a8c0@pii350> Trying to use --enable-minimal with gnupg-1.4.9, configure look to work with gcc-3.3.3, linux-2.4.36.3 configure fail with gcc-4.2.3, linux-2.6.24.5 I suspect -enable-minimal is broken because mode_t detection does not work as intented. With both linux-2.6.24.5 and 2.4.36.3 headers, - if --enable-mininal is not used, mode_t detection answer is yes - if --enable-minimal is used, mode_t detection answer is no (with linux-2.4.24.5 and gcc-4.2.3 without --enable-minimal) configure:17255: checking for mode_t configure:17285: gcc -c -Os -fomit-frame-pointer -march=i486 -mtune=pentium -pipe conftest.c >&5 configure:17291: $? = 0 configure:17306: result: yes (with linux-2.4.24.5 and gcc-4.2.3 with -enable-minimal) see configure-mode_t-detection-failure log file Except mode_t result, this part of configure is different Without --enable-minimal checking for ushort typedef... yes checking for ulong typedef... yes checking for u16 typedef... no checking for u32 typedef... no checking for unsigned short... yes checking size of unsigned short... 2 With --enable-minimal checking for ushort typedef... no checking for ulong typedef... no checking for u16 typedef... no checking for u32 typedef... no checking for unsigned short... yes checking size of unsigned short... configure: error: cannot compute sizeof (unsigned short) Difference in detection is caused by this error In file included from /usr/include/stdlib.h:320, from conftest.c:31: /usr/include/sys/types.h:72: error: two or more data types in declaration specifiers The reason that stop configure is in configure-size-failure attached log Gilles -------------- next part -------------- A non-text attachment was scrubbed... Name: configure-mode_t-detection-failure Type: application/octet-stream Size: 2174 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: configure-size-failure Type: application/octet-stream Size: 10666 bytes Desc: not available URL: From g.esp at free.fr Sat Apr 26 10:02:49 2008 From: g.esp at free.fr (Gilles Espinasse) Date: Sat, 26 Apr 2008 10:02:49 +0200 Subject: configure -enable-minimal failure References: <44ed01c8a770$cfb28ca0$f9b5a8c0@pii350> Message-ID: <451201c8a773$ebe3ed80$f9b5a8c0@pii350> ----- Original Message ----- From: "Gilles Espinasse" To: Sent: Saturday, April 26, 2008 9:40 AM Subject: configure -enable-minimal failure > Trying to use --enable-minimal with gnupg-1.4.9, > configure look to work with gcc-3.3.3, linux-2.4.36.3 > configure fail with gcc-4.2.3, linux-2.6.24.5 > > I suspect -enable-minimal is broken because mode_t detection does not work > as intented. > With both linux-2.6.24.5 and 2.4.36.3 headers, > - if --enable-mininal is not used, mode_t detection answer is yes > - if --enable-minimal is used, mode_t detection answer is no > I forget to say - in 1.4.5, mode_t detection answer is yes and configure work - in 1.4.6 mode_t detection answer is no and configure stop on cannot compute sizeof (unsigned short) Gilles From dshaw at jabberwocky.com Mon Apr 28 06:11:13 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 28 Apr 2008 00:11:13 -0400 Subject: configure -enable-minimal failure In-Reply-To: <44ed01c8a770$cfb28ca0$f9b5a8c0@pii350> References: <44ed01c8a770$cfb28ca0$f9b5a8c0@pii350> Message-ID: On Apr 26, 2008, at 3:40 AM, Gilles Espinasse wrote: > Trying to use --enable-minimal with gnupg-1.4.9, > configure look to work with gcc-3.3.3, linux-2.4.36.3 > configure fail with gcc-4.2.3, linux-2.6.24.5 > > I suspect -enable-minimal is broken because mode_t detection does > not work > as intented. > With both linux-2.6.24.5 and 2.4.36.3 headers, > - if --enable-mininal is not used, mode_t detection answer is yes > - if --enable-minimal is used, mode_t detection answer is no Oddly enough, I recall fixing this bug last year (it's a gettext issue). Let me do some digging here and figure out what happened. David From bernhard at intevation.de Tue Apr 29 14:14:45 2008 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 29 Apr 2008 14:14:45 +0200 Subject: Vs Combined Method? E+S from RFC 3156 6.2 Message-ID: <200804291414.53915.bernhard@intevation.de> Hello, in this email I am trying to collect arguments against the combined method for encryption and signature as outlined in section 6.2 of RFC 3156. The other method describe there is 6.1 RFC 1847 Encapsulation and means doing a signature first and then encrypt the result, aka the MIME method. I know that Werner advises against the combined method, now I am looking for the arguments. Werner puts forward that it would be possible to strip the encryption layer with the MIME method. The RFC suggest that this can be done also with the combined method. I take it that it is easier to implement with the MIME method as there is no rewriting involved. Counting one argument for the MIME method. The RFC puts forward that the combined method saves computing time and is more compatible with older implementation. The computing time is almost neglectable in my view, but the compatibility is a countable argument for the combined method. The RFC only states that the MIME method is "most useful for standard MIME- compliant message forwarding." I take it this hold for all cases where there is a MIME structure inside the encryption, which means many emails today where there is an attachment or an multipart/alternative. Otherwise the compatibility advantages with non-MIME (email) applications would be gone. It is clear that all implementations have to be able to cope with combined emails as readers anyway, this also means being able to strip the encryption layer. Taken you want to implement this stripping functionality you will have to do it for both methods as users would not really understand why it does not work in some cases. Given the enhanced compatibility, why not do combined method whenever you can, just getting the compatibility advantage? Looks like this is what email applications should use as default so far. What arguments am I missing? Bernhard Some public statements of Werner that I did find: http://marc.info/?l=gnupg-devel&m=100167296722730&w=2 List: gnupg-devel Subject: Re: gpgme 0.3.3 questions From: Werner Koch Date: 2001-09-28 9:56:14 > - Currently there is no way to perform encrypt+sign operations!!! > gpgme_signers_add() cannot be used for gpgme_op_encrypt(). I know but this is a minor problem compared to the fact that it is not possible to decrypt and check the signature. I don't know what application you have currently in mind, my primary target are MUAs and tehre is is better not to use the combined method but first sign, pack this into a MIEM object and the encrypt this MIME object again. The big advantage is that you can remove the encryption layer and still keep the signature. - On Fri, Jan 14, 2005 at 03:55:05PM +0000, Shaun Lipscombe wrote: > Is there any particular reason why one must be done before the other? > I.E. Sign & Encrypt over Encrypt & Sign. http://marc.info/?l=gnupg-users&m=110572664810100&w=2 List: gnupg-users Subject: Re: Encrypt & Sign From: Werner Koch Date: 2005-01-14 18:11:13 Message-ID: 877jmfvq2m.fsf () wheatstone ! g10code ! de On Fri, 14 Jan 2005 11:25:59 -0500, David Shaw said: > signer. There is no particular reason why one is better than the > other, but generally people like the identity protection aspect of There is one reason: If you store texts in the clear you still can keep the signature intact. If you encrypt and sign then this won't be possible. To implement that you should - for practical reasons - not use the combined method of gpg but the standard PGP/MIME method of encrypting an PGP/MIME signed message. -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. 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: 189 bytes Desc: not available URL: