From bernhard at intevation.de Tue Feb 3 14:26:29 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 3 Feb 2009 14:26:29 +0100 Subject: Fix pinentry.tex lc-type command line option type In-Reply-To: <200901291003.33423.bernhard@intevation.de> References: <200901291003.33423.bernhard@intevation.de> Message-ID: <200902031426.29472.bernhard@intevation.de> On Donnerstag, 29. Januar 2009, Bernhard Reiter wrote an email where all of you will have a bad checksum on the signature. I believe this is Mailman defect https://bugs.launchpad.net/mailman/+bug/265967 (Breaking signatures in message/rfc822 attachement!) (A patch for a part of the problem is available, Debian used to have it applied to their Mailman.) Here is the fix if you wanted to verify my signature: --- b.mbox 2009-02-03 11:26:17.659538344 +0100 +++ c.mbox 2009-02-03 11:29:54.064639768 +0100 @@ -100,2 +100,3 @@ -Content-Type: text/x-diff; charset="us-ascii"; - name="pinentry-r189-lc-ctype-fix.texi.patch" +Content-Type: text/x-diff; + charset="us-ascii"; + name="pinentry-r189-lc-ctype-fix.texi.patch" @@ -103 +104,2 @@ -Content-Disposition: inline; filename="pinentry-r189-lc-ctype-fix.texi.patch" +Content-Disposition: inline; + filename="pinentry-r189-lc-ctype-fix.texi.patch" -- 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: 206 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Tue Feb 3 16:28:12 2009 From: wk at gnupg.org (Werner Koch) Date: Tue, 03 Feb 2009 16:28:12 +0100 Subject: Fix pinentry.tex lc-type command line option type In-Reply-To: <200902031426.29472.bernhard@intevation.de> (Bernhard Reiter's message of "Tue, 3 Feb 2009 14:26:29 +0100") References: <200901291003.33423.bernhard@intevation.de> <200902031426.29472.bernhard@intevation.de> Message-ID: <87hc3bwneb.fsf@wheatstone.g10code.de> On Tue, 3 Feb 2009 14:26, bernhard at intevation.de said: > (A patch for a part of the problem is available, Debian used to have it > applied to their Mailman.) it seems that Mailman still rewrites the MIME headers, right? Why at all are they not abale to fix that problem. Over years I have applied this or a similar patch and it is still not in upstream. Will patch it. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From bernhard at intevation.de Wed Feb 4 08:20:50 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 4 Feb 2009 08:20:50 +0100 Subject: Mailman and signatures (Re: Fix pinentry.tex lc-type command line option type) In-Reply-To: <87hc3bwneb.fsf@wheatstone.g10code.de> References: <200901291003.33423.bernhard@intevation.de> <200902031426.29472.bernhard@intevation.de> <87hc3bwneb.fsf@wheatstone.g10code.de> Message-ID: <200902040820.54314.bernhard@intevation.de> On Dienstag, 3. Februar 2009, Werner Koch wrote: > On Tue, ?3 Feb 2009 14:26, bernhard at intevation.de said: > > (A patch for a part of the problem is available, Debian used to have it > > applied to their Mailman.) > > it seems that Mailman still rewrites the MIME headers, right? ?Why at > all are they not abale to fix that problem. ?Over years I have applied > this or a similar patch and it is still not in upstream. It is not just MIME-headers, but other header files as well. I believe the problem results out of a bad design decision of the "email" python library that does not save the full email. So a full fix would be a partial rewrite of that library. (My patch only fixes part of the problem.) > Will patch it. Thanks. -- 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: 1603 bytes Desc: not available URL: From wk at gnupg.org Wed Feb 4 09:08:01 2009 From: wk at gnupg.org (Werner Koch) Date: Wed, 04 Feb 2009 09:08:01 +0100 Subject: Mailman and signatures (Re: Fix pinentry.tex lc-type command line option type) In-Reply-To: <200902040820.54314.bernhard@intevation.de> (Bernhard Reiter's message of "Wed, 4 Feb 2009 08:20:50 +0100") References: <200901291003.33423.bernhard@intevation.de> <200902031426.29472.bernhard@intevation.de> <87hc3bwneb.fsf@wheatstone.g10code.de> <200902040820.54314.bernhard@intevation.de> Message-ID: <87zlh2vd3y.fsf@wheatstone.g10code.de> On Wed, 4 Feb 2009 08:20, bernhard at intevation.de said: >> Will patch it. > > Thanks. Unfortunately the patch does not apply cleanly to 2.1.12. There are quite some changes in Mailman. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From thorpejeffrey at gmail.com Wed Feb 4 12:12:10 2009 From: thorpejeffrey at gmail.com (Jeff Thorpe) Date: Wed, 04 Feb 2009 06:12:10 -0500 Subject: Compiling for iPhone? Message-ID: Having trouble with servers, so if this is duplicated, I apologize on this account too... Apologies if I?m on the wrong list... I am trying to get gnupg-1.4.9 compiled with IDEA for the iPhone. This was possible on the iPhone itself under the 1.1.4 firmware, but since the upgrade to 2.2, gcc on it isn?t so swell. So, I have tried to compile it on my MacBook with the iPhone SDK, but don?t really know anything. (I am not a developer). The only generic instructions for cross-compiling to the iPhone included a generic Makefile that would install the developers app (over WiFi to the jailbroken iPhone), but this doesn?t fit with gnupg, which apparently generates its own Makefile, and so when I fumble about, I just end up compiling for my MacBook. There is an iPhone compiled package for gnupg-1.4.8 without IDEA for download and install, but this isn?t what I want, and obviously cannot be considered secure. Can anybody give me any pointers? Sorry again if this is the wrong list. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dshaw at jabberwocky.com Wed Feb 4 15:14:56 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 4 Feb 2009 09:14:56 -0500 Subject: Compiling for iPhone? In-Reply-To: References: Message-ID: On Feb 4, 2009, at 6:12 AM, Jeff Thorpe wrote: > Having trouble with servers, so if this is duplicated, I apologize > on this account too... > > Apologies if I?m on the wrong list... > I am trying to get gnupg-1.4.9 compiled with IDEA for the iPhone. > This was possible on the iPhone itself under the 1.1.4 firmware, but > since the upgrade to 2.2, gcc on it isn?t so swell. So, I have > tried to compile it on my MacBook with the iPhone SDK, but don?t > really know anything. (I am not a developer). The only generic > instructions for cross-compiling to the iPhone included a generic > Makefile that would install the developers app (over WiFi to the > jailbroken iPhone), but this doesn?t fit with gnupg, which > apparently generates its own Makefile, and so when I fumble about, I > just end up compiling for my MacBook. Point me towards these generic instructions and I'll take a look. If you have the iPhone SDK, you have the right compiler and toolchain for building (it's an ARM device), but there may be some special magic involved at some step. David From thorpejeffrey at gmail.com Tue Feb 3 19:30:37 2009 From: thorpejeffrey at gmail.com (Jeff Thorpe) Date: Tue, 03 Feb 2009 13:30:37 -0500 Subject: for iPhone? Message-ID: Apologies if I?m on the wrong list... I am trying to get gnupg-1.4.9 compiled with IDEA for the iPhone. This was possible on the iPhone itself under the 1.1.4 firmware, but since the upgrade to 2.2, gcc on it isn?t so swell. So, I have tried to compile it on my MacBook with the iPhone SDK, but don?t really know anything. (I am not a developer). The only generic instructions for cross-compiling to the iPhone included a generic Makefile that would install the developers app (over WiFi to the jailbroken iPhone), but this doesn?t fit with gnupg, which apparently generates its own Makefile, and so when I fumble about, I just end up compiling for my MacBook. There is an iPhone compiled package for gnupg-1.4.8 without IDEA for download and install, but this isn?t what I want, and obviously cannot be considered secure. Can anybody give me any pointers? Sorry again if this is the wrong list. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bernhard at intevation.de Fri Feb 6 18:20:51 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 6 Feb 2009 18:20:51 +0100 Subject: gpgsm: Cipher default: 3DES, because of OL2003 Message-ID: <200902061820.51760.bernhard@intevation.de> It seems that Outlook 2003 cannot deal with AES encrypted S/MIME emails and even spits out some error message which is unhelpful. At least in German is says something about an ID not found. So the default for gpgsm should be 3DES. (For 2.0.10 is was changed to AES, and this causes us to detect the interoperability problem.) Note, to find out the default encryption cipher, you could use the command: gpgconf --list-options gpgsm (or the internal version gpgsm --gpgconf-list ) -- 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: 1603 bytes Desc: not available URL: From joel_rees at sannet.ne.jp Sat Feb 7 09:44:56 2009 From: joel_rees at sannet.ne.jp (Joel Rees) Date: Sat, 7 Feb 2009 17:44:56 +0900 Subject: expired sig? Message-ID: I just installed gnupg 1.4.9 and, just for grins (since I hadn't yet installed gpg and had already checked the SHA1 signature), I did gpg --verify on the signature file gnupg-1.4.9.tar.gz.sig . It says the signature for "Werner Koch (dist sig) " is good, then it says: gpg: Note: This key has expired! (Signature made Thu Mar 27 02:39:36 2008 JST using RSA key ID 1CE0C630) Maybe they expected an update to occur before now? From ametzler at downhill.at.eu.org Sat Feb 7 13:15:08 2009 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sat, 7 Feb 2009 13:15:08 +0100 Subject: expired sig? References: Message-ID: Joel Rees wrote: > I just installed gnupg 1.4.9 and, just for grins (since I hadn't yet > installed gpg and had already checked the SHA1 signature), I did gpg > --verify on the signature file gnupg-1.4.9.tar.gz.sig . > It says the signature for "Werner Koch (dist sig) " is > good, then it says: > gpg: Note: This key has expired! > (Signature made Thu Mar 27 02:39:36 2008 JST using RSA key ID 1CE0C630) > Maybe they expected an update to occur before now? You need to refresh the key. http://news.gmane.org/find-root.php?message_id=%3c87zli0ada0.fsf%5f%5f11524.4188149974%241231504564%24gmane%24org%40wheatstone.g10code.de%3e gpg --keyserver x-hkp://subkeys.pgp.net --recv-keys 1CE0C630 cu andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' From joel_rees at sannet.ne.jp Sat Feb 7 15:33:34 2009 From: joel_rees at sannet.ne.jp (Joel Rees) Date: Sat, 7 Feb 2009 23:33:34 +0900 Subject: expired sig? In-Reply-To: References: Message-ID: <678F70C7-454A-4E32-85C2-2EF9A978071F@sannet.ne.jp> On ?? 21/02/07, at 21:15, Andreas Metzler wrote: > Joel Rees wrote: >> I just installed gnupg 1.4.9 and, just for grins (since I hadn't yet >> installed gpg and had already checked the SHA1 signature), I did gpg >> --verify on the signature file gnupg-1.4.9.tar.gz.sig . > >> It says the signature for "Werner Koch (dist sig) " is >> good, then it says: > >> gpg: Note: This key has expired! > >> (Signature made Thu Mar 27 02:39:36 2008 JST using RSA key ID >> 1CE0C630) > >> Maybe they expected an update to occur before now? > > You need to refresh the key. > http://news.gmane.org/find-root.php?message_id=%3c87zli0ada0.fsf%5f% > 5f11524.4188149974%241231504564%24gmane%24org% > 40wheatstone.g10code.de%3e > > gpg --keyserver x-hkp://subkeys.pgp.net --recv-keys 1CE0C630 I guess I missed that one on announce at gnupg.org . So the gnu servers or wherever I picked up the key has the old key, maybe? I checked to make sure the key matched several places on-line, including last spring's announce@ of the version, but I don't remember where all I checked. Okay, thanks. From nicholas.cole at gmail.com Mon Feb 9 00:28:42 2009 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Sun, 8 Feb 2009 23:28:42 +0000 Subject: Decoding sig packet data Message-ID: Does anyone have any advice about decoding the 'octets' in the last field of the spk lines of the --with-colons output. The notation appears non-standard. The only python library, for example, that I can see that deals with 'percent encoded' octets is the urllib library, but that library's 'decode' function outputs gibberish. I know, of course, that the answer will be something completely obvious, but for the moment I'm completely stumped! Best wishes, Nicholas From wk at gnupg.org Mon Feb 9 10:25:39 2009 From: wk at gnupg.org (Werner Koch) Date: Mon, 09 Feb 2009 10:25:39 +0100 Subject: Decoding sig packet data In-Reply-To: (Nicholas Cole's message of "Sun, 8 Feb 2009 23:28:42 +0000") References: Message-ID: <87d4dst10s.fsf@wheatstone.g10code.de> On Mon, 9 Feb 2009 00:28, nicholas.cole at gmail.com said: > Does anyone have any advice about decoding the 'octets' in the last > field of the spk lines of the --with-colons output. The notation > appears non-standard. The only python library, for example, that I > can see that deals with 'percent encoded' octets is the urllib > library, but that library's 'decode' function outputs gibberish. >From doc/DETAILS: The "spk" signature subpacket records have the fields: 2: Subpacket number as per RFC-4880 and later. 3: Flags in hex. Currently the only two bits assigned are 1, to indicate that the subpacket came from the hashed part of the signature, and 2, to indicate the subpacket was marked critical. 4: Length of the subpacket. Note that this is the length of the subpacket, and not the length of field 5 below. Due to the need for %-encoding, the length of field 5 may be up to 3x this value. 5: The subpacket data. Printable ASCII is shown as ASCII, but other values are rendered as %XX where XX is the hex value for the byte. The content of field 5 is the raw subpacket data. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From marcus.brinkmann at ruhr-uni-bochum.de Tue Feb 17 16:11:16 2009 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Tue, 17 Feb 2009 16:11:16 +0100 Subject: Keyrings file format In-Reply-To: <20090106171220.7973c468@gmail.com> References: <20090106105826.2b34ebca@gmail.com> <20090106171220.7973c468@gmail.com> Message-ID: <499AD394.90004@ruhr-uni-bochum.de> Hi, David Paleino wrote: > Also, I could've written a binding to libgpgme -- but that too reads gpg's > output, so I preferred doing that myself to avoid one more layer of complexity / > bugs / whatever. Sorry for jumping into the discussion so late, but: By duplicating the code in GPGME you are not avoiding the bugs, you are just making them yourselves. But now you can't benefit from our fixes in GPGME (and we can't benefit from yours). GPGME isn't the answer to all needs, but it should provide a useful basis for any further enhancements to the API you can think of. > So, being both --with-colons and the keyring format uncertain, why adding one > more layer (i.e. forking the gpg process from my current code, read its output, > act consequently) to the code, if I can directly read the keyrings? Layers are good. They protect what's inside from the outside, and the other way round. > The conclusion is: if it's too difficult, or does not give concrete advantages > over the method I'm using now, then all the argumentation above is moot. But, > if it gives concrete advantages (in terms of speed, for example), it might be > worth a try, at least. Or, an option could be giving developers the chance to > use whichever implementation they prefer/trust. GPGME has almost no overhead. Starting the gpg process has some significant overhead, but it's unavoidable. For gpgsm we already have experimental code to only do this only once per gpgme context, for many operations, in which case it is amortized easily. In the future, we want to do the same for gpg. By using gpgme, you can automatically benefit from such improvements. Thanks, Marcus From marcus.brinkmann at ruhr-uni-bochum.de Tue Feb 17 15:44:40 2009 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Tue, 17 Feb 2009 15:44:40 +0100 Subject: (gpg/gcry)_strsource_r()? In-Reply-To: References: Message-ID: <499ACD58.5030706@ruhr-uni-bochum.de> Pat Pannuto wrote: > Hi all, > > I'm writing an app using libgcrypt, and I noticed that a reentrant / > thread-safe version of gcry_strerror is provided (gpg_strerror_r), but there > is no analog for gcry_strsource? I tried both gcry_strsource_r and > gpg_strsource_r on the off chance that they would work, but they did not. > >> >From what I've noticed in debugging, the source is rarely very useful, and I > see no real harm in just leaving it out I suppose, but if such a function > exists, it would be nice to include it for completeness. Sorry for the late reply. *_strsource already is reentrant. The reason that *_strerror is not is because it can use the system's strerror function which may be not. Thanks, Marcus From marcus.brinkmann at ruhr-uni-bochum.de Wed Feb 18 12:02:24 2009 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Wed, 18 Feb 2009 12:02:24 +0100 Subject: assuan interface for gpgme In-Reply-To: <87bptu9v4r.fsf@wheatstone.g10code.de> References: <87bptu9v4r.fsf@wheatstone.g10code.de> Message-ID: <499BEAC0.8080706@ruhr-uni-bochum.de> Hi, I have a couple of interface change suggestions for the assuan operations. They fall into two groups: Correctness with the asynchronous variant and consistency with the other interfaces. Werner Koch wrote: > This callback is used for 'INQUIRE ' lines. NAME is the name of the > inquiry and ARGS gives the rest of the line. An inquiry is used by a > server to retrieve additional data from the client. If the client has > this data available it needs to use the SENDFNC to send the data back to > the server like this: > > err = sendfnc (sendfnc_value, my_data, my_datalen); I think we should use a gpgme_assuan_send function that does the dispatch to the sendfnc. We use user provided function pointers in the interface, but this would introduce gpgme provided function pointers in the interface as well, and I don't think that's necessary. One reason is that this way we can catch all calls into GPGME with a regex breakpoint on gpgme_*. > If the server returns an error this error should be the return value of > the inquiry. This send function may be called as often as required. This is fine for the synchronous variant, but I have some doubts about the validity of this interface in the asynchronous variant, as sending inquire data may block. Instead, the user could indicate if there is more data to be returned by setting a flag in a return value slot, and GPGME can keep calling the inquire callback when sending data is possible until the user is satisfied. If we also provide a buffer for the user to fill, then no send callback is necessary. [...] > To make the synchronous and asynchronous versions similar, the error > code from gpgme_op_assuan_transact does only return errors pertaining to > the use Assuan connection and gpgme itself; it does not return the > result of the actual Assuan command (OK or ERR). To get that result you > use: > > err = gpgme_op_assuan_result (ctx); > > which returns 0 for the 'OK' line and an gpg-error code for the 'ERR > ' line. For consistency and extensibility, we should return a struct, just as with all the other result functions. > The connection is kept open regardless of this return > value. [...] > and because we do not want to send another command, we close the > connection by releasing the context: > > gpgme_release (ctx); We should add a gpgme_op_assuan_end function, as we have for keylistings. No need to trash a perfectly reasonably context to disconnect. > The remaining question is how to use a different socket than the default > one sued for gpg-agent. We use the engine set_info function to > accomplish this: Right after creating the context you may call > > err = gpgme_ctx_set_engine_info (ctx, GPGME_PROTOCOL_ASSUAN, > "/tmp/foo/socket", > ""); > > to connect to an Assuan server listening on socket /tmp/foo/socket. > Note that the last parameter is an empty string. If you would use NULL, > here the gpgme default value would be used which is an option to run the > initial Assuan commands used for gpg-agent. Right, we are re-using > HOME_DIR parameter to pass flags to the engine. I don't think home_dir should be overloaded in this way. In fact, there is no need to have this mechanism: Options can be passed as assuan commands using transact the normal way, that's the whole purpose of the protocol. Using default options for the default gpg-agent is a convenience that is arguably worth to have, but setting any engine infos explicitly should void this convenience behavior as well. My preference however would be to just require home_dir to be NULL at all times, and to not have any default commands, and instead provide a convenience function gpgme_error_t gpgme_op_assuan_init_gpg_agent (ctx); or similar that sends the default commands for a gpg-agent connection. That way there is no inconsistency and no difficulty in understanding and extending the interface. This also avoids sending commands at connection time, which is good for reliability in the asynchronous variant (in case the server blocks errornously). Thanks, Marcus From wk at gnupg.org Wed Feb 18 15:09:26 2009 From: wk at gnupg.org (Werner Koch) Date: Wed, 18 Feb 2009 15:09:26 +0100 Subject: [Announce] Gpg4win 1.1.4 released Message-ID: <87hc2rq1k9.fsf@wheatstone.g10code.de> Hi! We are pleased to announce the availability of a new stable Gpg4win release: Version 1.1.4. This is a maintenance release; if you don't have any problems there is no need for an update. It mainly fixes problem using GnuPG on Windows Vista by updating to a newer version of the included GnuPG. About Gpg4win ------------- The Gpg4win project aims at updating the Gpg4win Windows installation package with GnuPG encryption tool, associated applications and documentation on a regular basis. Especially the documentation (handbooks "Novices", "Einsteiger" and "Durchblicker") are directly maintained as part of the gpg4win project. It is an international project. Due to the origin of the project the German language is fully supported. People helping with translations are very welcome! The main difference compared to all other similar approaches (mainly GnuPP, GnuPT, Windows Privacy Tools and GnuPG-Basics) is that the first thing developed was the Gpg4win-Builder. This builder allows to easily create new gpg4win.exe installers with updated components. The builder runs on any decent Unix system, preferable Debian GNU/Linux. Almost all products are automatically cross-compiled for integration into the installer. With this concept it is hoped to prevent quick aging of the installer package. This is due to easier updating and less dependency on single developers. Noteworthy changes in version 1.1.4 (2009-02-17) ------------------------------------------------ * Updated GnuPG to 1.4.9 to solve problems on Windows Vista. * Updated the optional GnuPG-2 components. * Included the small Paperkey and Scute utilities. * Included components are: GnuPG: 1.4.9 [*] GnuPG2: 2.0.10 [*] DirMngr: 1.0.3-svn310 [*] GPA: 0.8.0 [*] GPGol: 0.9.92 GPGee: 1.3.1 WinPT: 1.2.0 Claws-Mail: 3.0.0-rc2 Novices: 1.0.0 Einsteiger: 2.0.2 Durchblicker: 2.0.2 (Marked packages are updated since the last release) Incompatibilities ----------------- The Dirmngr, which is used by GnuPG-2, uses another location for its configuration files. It is not anymore below the installation directory put at the proper place for data files. This ensures that they will persist over updates and allows to use a network share for the program files. Gpg4win 1.1.4 deletes those old configuration files it knows about but keeps those not installed by Gpg4win. However, the left over files are not anymore used and need to be copied to the new location manually if this is desired. Given that GnuPG-2 and Dirmngr are not used by the other tools, we believe that this is not a hard problem. Current Work ------------ We are still working towards Gpg4win 2.0, featuring a completely new architecture. The currently available Beta version (available through http://www.gpg4win.org/download.html) is almost usable. However there are a couple of problems we need to solve before we are able to release a stable Gpg4win 2.0. Due to these problems we decided to release 1.1.4 as an update for 1.1.3 first. Using GPG via %PATH% -------------------- As of version 1.1.0, Gpg4win updates the PATH variable to include a new public directory containing the command line tools of Gpg4win. To avoid having a bunch of DLLs in the PATH a special wrapper is used to access these tools. With this release the wrapper should actually work and allows access to gpg, gpgsm and gpg-connect-agent from anywhere in the system without the need to know where Gpg4win has been installed. Developers of frontends making use of Gpg4win might want to avoid the use of these wrappers. A hidden option in the wrapper makes the actual used binary available. For example, running "gpg --version --version" will print the following to stdout if the wrapper is being used: gpgwrap (Gpg4win) 1.1.4 ;C:\Programme\GNU\GnuPG\gpg.exe gpg (GnuPG) 1.4.9 (Gpg4win 1.1.4) .... The string after the semicolon up to the end of the first line may be used for future invocations of gpg.exe. Installation ------------ For installation instructions, please visit http://www.gpg4win.org or read on. Developers who want to *build an installer* need to get the following files from http://wald.intevation.org/projects/gpg4win/ : gpg4win-1.1.4.tar.bz2 (4.3M) gpg4win-1.1.4.tar.bz2.sig The second file is a digital signature of the the first file. Either check that this signature is fine or compare with the checksums given below. (see also http://www.gnupg.org/download/integrity_check.html) The *ready to use installer* is available at: http://ftp.gpg4win.org/gpg4win-1.1.4.exe (9.6M) http://ftp.gpg4win.org/gpg4win-1.1.4.exe.sig Or using the ftp protocol at: ftp://ftp.gpg4win.org/gpg4win/gpg4win-1.1.4.exe (9.6M) ftp://ftp.gpg4win.org/gpg4win/gpg4win-1.1.4.exe.sig SHA1 and MD5 checksums for these files are given below. If you don't need the manuals or the GnuPG2 command line tools for S/MIME, you might alternatively download the "light" version of the installer: http://ftp.gpg4win.org/gpg4win-light-1.1.4.exe (5.9M) http://ftp.gpg4win.org/gpg4win-light-1.1.4.exe.sig or using FTP at: ftp://ftp.gpg4win.org/gpg4win/gpg4win-1.1.4.exe (5.9M) ftp://ftp.gpg4win.org/gpg4win/gpg4win-1.1.4.exe.sig A separate installer with the source files used to build the above installer is available at: ftp://ftp.gpg4win.org/gpg4win/gpg4win-src-1.1.4.exe (60M) ftp://ftp.gpg4win.org/gpg4win/gpg4win-src-1.1.4.exe.sig Most people don't need this source installer; it is merely stored on that server to satisfy the conditions of the GPL. In general it is better to get the gpg4win builder tarball (see above) and follow the instructions in the README to build new installers; building the installer is not possible on Windows machines and works best on current Debian GNU/Linux systems (we currently use the mingw32 package from Etch). SHA1 checksums are: e1c41605b0a359759059e4e2f527055b0f4036d5 gpg4win-1.1.4.exe 6ae2b32ec97801543e954fd23888fa10a9a1781a gpg4win-light-1.1.4.exe 08c585347750e8345d964afa73aff7d455c81f39 gpg4win-src-1.1.4.exe 6a3ec8f7cb5a4252b3b93f49b733bcb5e344eb06 gpg4win-1.1.4.tar.bz2 MD5 checksums are: b2e18fd37a14b065a8361f5348c83f72 gpg4win-1.1.4.exe bb3bee4d8c30f5376d532c7135b17045 gpg4win-light-1.1.4.exe 2efc36781e7b3f463064129d6819fe4d gpg4win-src-1.1.4.exe 2b1ac6dbc4d4fe3e710348b7a671b102 gpg4win-1.1.4.tar.bz2 If you have problems downloading the above files, you may try the mirror servers listed at the download page. We like to thank the authors of the included packages, the NSIS authors, all other contributors and first of all, those folks who stayed with us and helped testing Gpg4win. To help furthering this project, please consider to sponsor the development. See http://www.gpg4win.org . Happy hacking, The Gpg4win hackers -- 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 wk at gnupg.org Wed Feb 18 17:00:23 2009 From: wk at gnupg.org (Werner Koch) Date: Wed, 18 Feb 2009 17:00:23 +0100 Subject: assuan interface for gpgme In-Reply-To: <499BEAC0.8080706@ruhr-uni-bochum.de> (Marcus Brinkmann's message of "Wed, 18 Feb 2009 12:02:24 +0100") References: <87bptu9v4r.fsf@wheatstone.g10code.de> <499BEAC0.8080706@ruhr-uni-bochum.de> Message-ID: <8763j7pwfc.fsf@wheatstone.g10code.de> On Wed, 18 Feb 2009 12:02, marcus.brinkmann at ruhr-uni-bochum.de said: >> err = sendfnc (sendfnc_value, my_data, my_datalen); > > I think we should use a gpgme_assuan_send function that does the dispatch to > the sendfnc. We use user provided function pointers in the interface, but I considered that but it has the drawback that we need, more or less, to expose the assuan interface. Another option I considered was to either pass the gpgme context to the callback or some opaque data to be passed to an gpgme_assuan_send_data_from_inq function. > well, and I don't think that's necessary. One reason is that this way we can > catch all calls into GPGME with a regex breakpoint on gpgme_*. Good point. Given that there may only be one inquire going on per gpgme context, what about changing the calllback to: typedef gpgme_error_t (*gpgme_assuan_inquire_cb_t) (void *opaque, const char *name, const char *args, gpgme_ctx_t ctx); and a gpgme_op_assuan_send_inq_data (...) which takes the context and may check that it has been called from an inq callback. > Instead, the user could indicate if there is more data to be returned by > setting a flag in a return value slot, and GPGME can keep calling the inquire > callback when sending data is possible until the user is satisfied. That would complicate the data flow and make an inquire callback pretty unreadable. We need to allow calling a send function as often as needed. > If we also provide a buffer for the user to fill, then no send callback is > necessary. That makes it hard to use. You don't know beforehand how much data to send back. For example a requested certificate my be just a few hundred bytes of 100kb in the case of PGP. >> err = gpgme_op_assuan_result (ctx); >> >> which returns 0 for the 'OK' line and an gpg-error code for the 'ERR >> ' line. > > For consistency and extensibility, we should return a struct, just as with all I don't see a reason for extensibility because the protocol defines that there is just a retrun value of OK or ERR which can all be represented by an integer (famous last 640k-are-enough words) if (!err) { s = gpgme_op_assuan_result (ctx); err = s? s->err : gpg_error (GPG_ERR_BUG); } is a lot of unneeded code. The question is more whether we need a separate error code at all for syncronous operations: Folding it into the error code returned by gpgmg_op_assuan_transact would make things even easier. If there is need to check whetehr it is an application error or a gpgme error, a test with gpg_err_source (err) == GPG_ERR_SORUC$E_GPGME would do the trick. In fact the code I wrote until now always did: err = gpgme_op_assuan_transact (); if (!err) err = gpgme_op_assuan_result (); and thus not distinguish between the errors. Usuallay you expect success or a few well defined error codes, everyhing else is a severe error and most likely you will close or reset the context in response. Thus my proposal would be to keep the result function as it is now and change the syncronous version of gpgme_op_assuan_transact to return the application error directly. > We should add a gpgme_op_assuan_end function, as we have for keylistings. No > need to trash a perfectly reasonably context to disconnect. A new gpgme_reset could be used to reuse a context. Pretty easy to implement, given that we already have a _gpgme_op_reset. > need to have this mechanism: Options can be passed as assuan commands using > transact the normal way, that's the whole purpose of the protocol. Using I was think not thinking about application option but those required to operate a certain socket. > convenience behavior as well. My preference however would be to just require > home_dir to be NULL at all times, and to not have any default commands, and > instead provide a convenience function > > gpgme_error_t gpgme_op_assuan_init_gpg_agent (ctx); That is very special for the gpg-agent. Right the option I suggested is also special for the gpg-agent (due to PINENTRY_LAUNCHED) but it is not codified in the API and on the same semantic level as the name of the socket. > way there is no inconsistency and no difficulty in understanding and extending > the interface. This also avoids sending commands at connection time, which is > good for reliability in the asynchronous variant (in case the server blocks > errornously). We have quite a couple of hacks in gpgme to cope with special requirements of GnuPG. I don't see the gpgme_op_assuan family as a replacement for libassuan. it is merely a convenience API which allows us to re-use code we already have in gpgme in case an application requires services from GnuPG which are not implemented by gpgme proper. We are expecting well behaving servers and frankly a buggy server my block at any time not just right after a completed command transaction. In fact that is even more likely due to the size of the OS buffers. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From marcus.brinkmann at ruhr-uni-bochum.de Wed Feb 18 18:54:55 2009 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Wed, 18 Feb 2009 18:54:55 +0100 Subject: assuan interface for gpgme In-Reply-To: <8763j7pwfc.fsf@wheatstone.g10code.de> References: <87bptu9v4r.fsf@wheatstone.g10code.de> <499BEAC0.8080706@ruhr-uni-bochum.de> <8763j7pwfc.fsf@wheatstone.g10code.de> Message-ID: <499C4B6F.6000604@ruhr-uni-bochum.de> Werner Koch wrote: > On Wed, 18 Feb 2009 12:02, marcus.brinkmann at ruhr-uni-bochum.de said: > >>> err = sendfnc (sendfnc_value, my_data, my_datalen); >> I think we should use a gpgme_assuan_send function that does the dispatch to >> the sendfnc. We use user provided function pointers in the interface, but > > I considered that but it has the drawback that we need, more or less, to > expose the assuan interface. Another option I considered was to either > pass the gpgme context to the callback or some opaque data to be passed > to an gpgme_assuan_send_data_from_inq function. It doesn't matter if the interface is similar to the assuan interface, as long as it is the correct interface from GPGME's point of view. >> well, and I don't think that's necessary. One reason is that this way we can >> catch all calls into GPGME with a regex breakpoint on gpgme_*. > > Good point. Given that there may only be one inquire going on per gpgme > context, what about changing the calllback to: > > typedef gpgme_error_t (*gpgme_assuan_inquire_cb_t) > (void *opaque, const char *name, const char *args, > gpgme_ctx_t ctx); > > and a > > gpgme_op_assuan_send_inq_data (...) > > which takes the context and may check that it has been called from an > inq callback. In this case, the user can keep the CTX behind the opaque pointer. No need to pass redundant information. However, I still think that providing a buffer that the user fills is a reasonable idea. There is one other idea below which also avoids a send_inq_data function. >> Instead, the user could indicate if there is more data to be returned by >> setting a flag in a return value slot, and GPGME can keep calling the inquire >> callback when sending data is possible until the user is satisfied. > > That would complicate the data flow and make an inquire callback pretty > unreadable. We need to allow calling a send function as often as > needed. Yes, it complicates the data flow. Unfortunately, the simple data flow doesn't work reliably for asynchronous operation. We can not allow sending more data in response to an unblocked file descriptor than the system's PIPE_BUF guaranteed write space. This is why it makes sense to provide the buffer to be filled with the inquire callback and drop the send function. The available buffer size is a system parameter that GPGME can encapsulate. Even if you expect the server not to block, there is a problem: The current interface (but not my proposals) require the user to send all the data at once. This can make the application unresponsive for an unacceptable length of time if a lot of data needs to be sent in an inquiry. Responsiveness in usability is measured in miliseconds. >> If we also provide a buffer for the user to fill, then no send callback is >> necessary. > > That makes it hard to use. You don't know beforehand how much data to > send back. For example a requested certificate my be just a few hundred > bytes of 100kb in the case of PGP. Inquiries are hard to use because of their nature. They turn around the data flow semantics between the client and the server in the middle of an operation. We know beforehand what data we can allow to send back in response to an unblocked select call on the file descriptor. It is PIPE_BUF on Unix and something else on Windows (depending on the I/O backend). In any way, it is not so hard to implement a pointer into a buffer and provide the data in chunks, using the opaque pointer. However, here is another idea: The user could return a gpgme_data_t object to the inquire call, and GPGME could handle the flow control transparently. This is flexible, and relatively easy for the application. For simple inquiries, this is more overhead, but for bulk data it is simpler. Of course, we could provide both (a buffer for the user to fill and a gpgme_data_t* if the buffer is too small). >>> err = gpgme_op_assuan_result (ctx); >>> >>> which returns 0 for the 'OK' line and an gpg-error code for the 'ERR >>> ' line. >> For consistency and extensibility, we should return a struct, just as with all > > I don't see a reason for extensibility because the protocol defines that > there is just a retrun value of OK or ERR which can all be represented > by an integer (famous last 640k-are-enough words). Just from the top of my head, we may want to provide a log of the transaction, some statistics, debug information (audit log), or the server's welcome message with a version info. In any case, consistency alone is reason enough to not use a different semantics for the _result function. > if (!err) > { > s = gpgme_op_assuan_result (ctx); > err = s? s->err : gpg_error (GPG_ERR_BUG); > } > > is a lot of unneeded code. The check for S is superfluous if you know that the last operation was an assuan operation. So it is possible to write: if (!err) err = (gpgme_op_assuan_result (ctx))->err; If you feel strongly about it, we can provide an accessor function for the error field in the result structure: gpgme_error_t gpgme_op_assuan_error (ctx); On the other hand, I introduced the result structures exactly to avoid the need for accessor functions. My main point is that it shouldn't be called _result() if it doesn't behave like one of those. > The question is more whether we need a > separate error code at all for syncronous operations. Folding it into > the error code returned by gpgmg_op_assuan_transact would make things > even easier. If there is need to check whetehr it is an application > error or a gpgme error, a test with gpg_err_source (err) == > GPG_ERR_SORUC$E_GPGME would do the trick. There is nothing that prevents the server from returning an error with a GPGME error source. This can get very confusing. I think there is some advantage to return all results of the operation in the result structure, and to return only GPGME internal errors in functions: It is a simple rule that can be easily understood. The current mix of return codes for example for a verify operation is not easy to understand. > In fact the code I wrote > until now always did: > > err = gpgme_op_assuan_transact (); > if (!err) > err = gpgme_op_assuan_result (); > > and thus not distinguish between the errors. Usuallay you expect > success or a few well defined error codes, everyhing else is a severe > error and most likely you will close or reset the context in response. True, but it should happen as late as possible, so that a proper diagnostic is possible. >> We should add a gpgme_op_assuan_end function, as we have for keylistings. No >> need to trash a perfectly reasonably context to disconnect. > > A new gpgme_reset could be used to reuse a context. Pretty easy to > implement, given that we already have a _gpgme_op_reset. A specific end function is more reliable, as it can do consistency checks. It can also try to terminate the server connection nicely. This does not preclude adding a reset function, but specifying that is more work. >> need to have this mechanism: Options can be passed as assuan commands using >> transact the normal way, that's the whole purpose of the protocol. Using > > I was think not thinking about application option but those required to > operate a certain socket. As far as I know, all assuan sockets are equal. What do you have in mind? In any case, the only example we have, GPG_AGENT, is not operating on the socket, but on the application behind it. >> convenience behavior as well. My preference however would be to just require >> home_dir to be NULL at all times, and to not have any default commands, and >> instead provide a convenience function >> >> gpgme_error_t gpgme_op_assuan_init_gpg_agent (ctx); > > That is very special for the gpg-agent. Right the option I suggested is > also special for the gpg-agent (due to PINENTRY_LAUNCHED) but it is not > codified in the API and on the same semantic level as the name of the > socket. I don't understand why you think that this is not part of the API. It most definitely is. OPTION is a regular command and PINENTRY_LAUNCHED is a regular inquiry that must be handled according to an application-specific policy. Let's separate the issues. The OPTIONs can be put into the init function I prototyped above. The pinentry_launched is actually not particular to gpg-agent, it could be passed through several other applications (and in fact it is!). In fact, it is not even clear that the current process is the right one to allow the set foreground call. It may need to be forwarded. In fact, it is a bug that it is not possible right now for the application to intercept PINENTRY_LAUNED inquiries resulting from GpgSM operations. Thus, I think automatic or external (ie application-level) handling of PINENTRY_LAUNCHED should be a special flag for the gpgme context, shared by assuan and gpgsm operations. The interface should be a configurable pinentry_launched callback function that can be set per context and that defaults to calling the set foreground window function. >> way there is no inconsistency and no difficulty in understanding and extending >> the interface. This also avoids sending commands at connection time, which is >> good for reliability in the asynchronous variant (in case the server blocks >> errornously). > > We have quite a couple of hacks in gpgme to cope with special > requirements of GnuPG. I don't see the gpgme_op_assuan family as a > replacement for libassuan. it is merely a convenience API which allows > us to re-use code we already have in gpgme in case an application > requires services from GnuPG which are not implemented by gpgme proper. I am not objecting to the functionality in GPGME, I am only arguing about the correct interface. There are at least two reasons against the home_dir overload: It's a misuse of an existing interface, it is not extensible (can only pass fixed strings). Also, parsing strings in C is not very good (source for bugs, no type safety, no compile time checks, ...) > We are expecting well behaving servers and frankly a buggy server my > block at any time not just right after a completed command transaction. > In fact that is even more likely due to the size of the OS buffers. That's true, and we actually build on that assumption in the gpgsm engine in GPGME. We should specify this in the assuan documentation. Because this is true, I did not propose to split up the init function for gpg-agent (that sets the OPTIONs) into asynchronously operating parts. I feel pretty strongly about interface consistency. I do not feel too strongly about asynchronous operation at this moment, but I think that we should prepare the interfaces for it to be possible. Thanks, Marcus From buanzo at buanzo.com.ar Mon Feb 23 15:00:46 2009 From: buanzo at buanzo.com.ar (Arturo 'Buanzo' Busleiman) Date: Mon, 23 Feb 2009 12:00:46 -0200 Subject: GnuPG and Python Message-ID: <49A2AC0E.8030305@buanzo.com.ar> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Group, just wondering... what python module would you recommend to use GPGME from within python? Would you use GPGME at all, or...? Thanks! PS: Yes, I'm googling too. Maybe I can find my own answer, but I wonder about what you guys have to say anyway. Sorry to bother! - -- Arturo "Buanzo" Busleiman / Arturo Busleiman @ 4:900/107 Independent Linux and Security Consultant - SANS - OISSG - OWASP http://www.buanzo.com.ar/pro/eng.html Mailing List Archives at http://archiver.mailfighter.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJoqwOAlpOsGhXcE0RCozMAJ9pBiifT8YJ9TVjXhQtUZy6AOrPbwCdF8gN 6O77pREvaGJudujctU9vxH8= =RwUI -----END PGP SIGNATURE----- From bernhard at intevation.de Tue Feb 24 12:54:47 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 24 Feb 2009 12:54:47 +0100 Subject: GnuPG and Python In-Reply-To: <49A2AC0E.8030305@buanzo.com.ar> References: <49A2AC0E.8030305@buanzo.com.ar> Message-ID: <200902241254.48226.bernhard@intevation.de> Am Montag, 23. Februar 2009 15:00:46 schrieb Arturo 'Buanzo' Busleiman: > Hi Group, just wondering... what python module would you recommend to use > GPGME from within python? http://pyme.sourceforge.net/ , I do not know if there is another one and I have used this one successfully a few times. > Would you use GPGME at all, or...? Of course, GPGME hides the complexity of executing and communicating with the gnupg binaries on different platforms. -- 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: 198 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Tue Feb 24 13:29:43 2009 From: wk at gnupg.org (Werner Koch) Date: Tue, 24 Feb 2009 13:29:43 +0100 Subject: assuan interface for gpgme In-Reply-To: <499C4B6F.6000604@ruhr-uni-bochum.de> (Marcus Brinkmann's message of "Wed, 18 Feb 2009 18:54:55 +0100") References: <87bptu9v4r.fsf@wheatstone.g10code.de> <499BEAC0.8080706@ruhr-uni-bochum.de> <8763j7pwfc.fsf@wheatstone.g10code.de> <499C4B6F.6000604@ruhr-uni-bochum.de> Message-ID: <87ab8cj9vs.fsf@wheatstone.g10code.de> On Wed, 18 Feb 2009 18:54, marcus.brinkmann at ruhr-uni-bochum.de said: > It doesn't matter if the interface is similar to the assuan interface, as long > as it is the correct interface from GPGME's point of view. >From a pragmatic point of view a similar interface makes life easier. You can just take the code from GnuPG and use it in a GUI application. OTOH, we try to get hackers to use GPGME and thus this advantage is more one for me than for a wide group of developers. > Yes, it complicates the data flow. Unfortunately, the simple data flow > doesn't work reliably for asynchronous operation. We can not allow sending I have not really considered asynchronous operations. So better get the API right instead of fixing it later. > However, here is another idea: The user could return a gpgme_data_t object to > the inquire call, and GPGME could handle the flow control transparently. This > is flexible, and relatively easy for the application. For simple inquiries, > this is more overhead, but for bulk data it is simpler. Of course, we could Okay, let me give it a shot. > Just from the top of my head, we may want to provide a log of the transaction, > some statistics, debug information (audit log), or the server's welcome > message with a version info. I don't see that.... > In any case, consistency alone is reason enough to not use a different > semantics for the _result function. ... but I agree that this is a valid point. > A specific end function is more reliable, as it can do consistency checks. It > can also try to terminate the server connection nicely. This does not > preclude adding a reset function, but specifying that is more work. We need a reset function anyway and if there will ever arise a problem from not having an end connection function we can add one later without too much trouble. > I don't understand why you think that this is not part of the API. It most > definitely is. OPTION is a regular command and PINENTRY_LAUNCHED is a regular Right, OPTION is one but not the specific options we use with gpg-agent. Given that GPGME has the goal to make access to GnuPG easier it really should do so and not require the user to code extra boilerblate stuff all the time or even think about how to do it. Accessing gpg-agent will be the major service requested, things are easier if the default is to make it really easy. > Let's separate the issues. The OPTIONs can be put into the init function I > prototyped above. The pinentry_launched is actually not particular to > gpg-agent, it could be passed through several other applications (and in fact > it is!). In fact, it is not even clear that the current process is the right > one to allow the set foreground call. It may need to be forwarded. In fact, It is correct for almost all applications but I agree that there may eventually be services which need access to this inquiry. > Thus, I think automatic or external (ie application-level) handling of > PINENTRY_LAUNCHED should be a special flag for the gpgme context, shared by > assuan and gpgsm operations. The interface should be a configurable Agreed, the default should be a handle it assuming that the application is the actual foreground GUI task. > only pass fixed strings). Also, parsing strings in C is not very good (source > for bugs, no type safety, no compile time checks, ...) We parse strings all the time. For now there is just one option and the parser is primitive. If we eventually add more options, I promise to write a regression test for the parser. > I feel pretty strongly about interface consistency. I do not feel too > strongly about asynchronous operation at this moment, but I think that we > should prepare the interfaces for it to be possible. Okay, let me hack on it and we see where we are going. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From buanzo at buanzo.com.ar Tue Feb 24 20:48:06 2009 From: buanzo at buanzo.com.ar (Arturo 'Buanzo' Busleiman) Date: Tue, 24 Feb 2009 17:48:06 -0200 Subject: GnuPG and Python In-Reply-To: <200902241254.48226.bernhard@intevation.de> References: <49A2AC0E.8030305@buanzo.com.ar> <200902241254.48226.bernhard@intevation.de> Message-ID: <49A44EF6.4020500@buanzo.com.ar> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Bernhard Reiter wrote: > http://pyme.sourceforge.net/ , I do not know if there is another one > and I have used this one successfully a few times. I got to the same choice, yesterday. Thanks for the confirmation, Bernhard! - -- Arturo "Buanzo" Busleiman / Arturo Busleiman @ 4:900/107 Independent Linux and Security Consultant - SANS - OISSG - OWASP http://www.buanzo.com.ar/pro/eng.html Mailing List Archives at http://archiver.mailfighter.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJpE7xAlpOsGhXcE0RCpASAJ0Qu9MQmHkwE5j49b7fFyZ/okXlPwCfaB7j yYXRdyJTR6j23D7qCW254fs= =TZi/ -----END PGP SIGNATURE----- From wk at gnupg.org Wed Feb 25 10:57:29 2009 From: wk at gnupg.org (Werner Koch) Date: Wed, 25 Feb 2009 10:57:29 +0100 Subject: scdaemon problems solved Message-ID: <87wsbej0ty.fsf@wheatstone.g10code.de> Hi! I just fixed a bug in Scdaemon which could let to a card reset on scdaemon startup with a card already inserted. This is properly the reasons for a lot of problems with the latests versions of Scdaemon. SVN revision 4933. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From buanzo at buanzo.com.ar Thu Feb 26 00:33:37 2009 From: buanzo at buanzo.com.ar (Arturo 'Buanzo' Busleiman) Date: Wed, 25 Feb 2009 21:33:37 -0200 Subject: GnuPG and Python In-Reply-To: <49A5D379.3050308@katehok.ac93.org> References: <49A2AC0E.8030305@buanzo.com.ar> <200902241254.48226.bernhard@intevation.de> <49A44EF6.4020500@buanzo.com.ar> <49A5D379.3050308@katehok.ac93.org> Message-ID: <49A5D551.206@buanzo.com.ar> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Igor Belyi wrote: > There's also http://py-gnupg.sourceforge.net/ which does not use GPGME > but executes gpg directly instead. Unfortunately, I don't have much > experience with it. I will take a look at it, too. Considering the very simple operations I have to perform, maybe using GPGME is an overkill, too... Thanks Igor! - -- Arturo "Buanzo" Busleiman / Arturo Busleiman @ 4:900/107 Independent Linux and Security Consultant - SANS - OISSG - OWASP http://www.buanzo.com.ar/pro/eng.html Mailing List Archives at http://archiver.mailfighter.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJpdVRAlpOsGhXcE0RCiWRAJ9xm8T+XCoM8ZqKQUSuD7/qaxM2jgCZATy+ Xv1rNnjmQoW2JOhgWI4wYxc= =gllg -----END PGP SIGNATURE----- From gpgme at katehok.ac93.org Thu Feb 26 00:25:45 2009 From: gpgme at katehok.ac93.org (Igor Belyi) Date: Wed, 25 Feb 2009 18:25:45 -0500 Subject: GnuPG and Python In-Reply-To: <49A44EF6.4020500@buanzo.com.ar> References: <49A2AC0E.8030305@buanzo.com.ar> <200902241254.48226.bernhard@intevation.de> <49A44EF6.4020500@buanzo.com.ar> Message-ID: <49A5D379.3050308@katehok.ac93.org> Arturo 'Buanzo' Busleiman wrote: > Bernhard Reiter wrote: > >> http://pyme.sourceforge.net/ , I do not know if there is another one >> and I have used this one successfully a few times. There's also http://py-gnupg.sourceforge.net/ which does not use GPGME but executes gpg directly instead. Unfortunately, I don't have much experience with it. Cheers, Igor From bernhard at intevation.de Thu Feb 26 08:39:33 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 26 Feb 2009 08:39:33 +0100 Subject: GnuPG and Python In-Reply-To: <49A5D551.206@buanzo.com.ar> References: <49A2AC0E.8030305@buanzo.com.ar> <49A5D379.3050308@katehok.ac93.org> <49A5D551.206@buanzo.com.ar> Message-ID: <200902260839.34144.bernhard@intevation.de> Am Donnerstag, 26. Februar 2009 00:33:37 schrieb Arturo 'Buanzo' Busleiman: > Igor Belyi wrote: > > There's also http://py-gnupg.sourceforge.net/ which does not use GPGME > > but executes gpg directly instead. Igor, you are confirming that there is only one python gpgme interface as py-gnupg does not seem to use gpgme. There are a couple of other non-gpgme python interface attempts. (Which I am too lazy too look up right now.) > I will take a look at it, too. Considering the very simple operations I > have to perform, maybe using GPGME is an overkill, too... Arturo, I still recommend using gpgme, even for the simplest operation because the fork and exe really never is simple. 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: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Thu Feb 26 09:09:45 2009 From: wk at gnupg.org (Werner Koch) Date: Thu, 26 Feb 2009 09:09:45 +0100 Subject: GnuPG and Python In-Reply-To: <49A5D551.206@buanzo.com.ar> (Arturo Busleiman's message of "Wed, 25 Feb 2009 21:33:37 -0200") References: <49A2AC0E.8030305@buanzo.com.ar> <200902241254.48226.bernhard@intevation.de> <49A44EF6.4020500@buanzo.com.ar> <49A5D379.3050308@katehok.ac93.org> <49A5D551.206@buanzo.com.ar> Message-ID: <87myc9liuu.fsf@wheatstone.g10code.de> On Thu, 26 Feb 2009 00:33, buanzo at buanzo.com.ar said: > I will take a look at it, too. Considering the very simple operations I have to perform, maybe using > GPGME is an overkill, too... Thanks Igor! FWIW: I don't think that GPGME is overkill. Instead it offers you an easy way for better performance because eventually we will implement a co-process scheme so that a running gpg process can be used for more than one operation. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From buanzo at buanzo.com.ar Thu Feb 26 11:58:20 2009 From: buanzo at buanzo.com.ar (Arturo 'Buanzo' Busleiman) Date: Thu, 26 Feb 2009 08:58:20 -0200 Subject: GnuPG and Python In-Reply-To: <87myc9liuu.fsf@wheatstone.g10code.de> References: <49A2AC0E.8030305@buanzo.com.ar> <200902241254.48226.bernhard@intevation.de> <49A44EF6.4020500@buanzo.com.ar> <49A5D379.3050308@katehok.ac93.org> <49A5D551.206@buanzo.com.ar> <87myc9liuu.fsf@wheatstone.g10code.de> Message-ID: <49A675CC.2030902@buanzo.com.ar> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Werner Koch wrote: > FWIW: I don't think that GPGME is overkill. Instead it offers you an > easy way for better performance because eventually we will implement a > co-process scheme so that a running gpg process can be used for more > than one operation. Yes, with that detail in mind, then going GPGME seems like the best option. Thanks for the insight, team. - -- Arturo "Buanzo" Busleiman / Arturo Busleiman @ 4:900/107 Independent Linux and Security Consultant - SANS - OISSG - OWASP http://www.buanzo.com.ar/pro/eng.html Mailing List Archives at http://archiver.mailfighter.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJpnXIAlpOsGhXcE0RCngRAJ4rww3yo00lwunA95yajWiRKHRTQACbBMEb OPtHV4fltrCfgC1teyeReRc= =4QZ0 -----END PGP SIGNATURE----- From tmz at pobox.com Thu Feb 26 15:24:22 2009 From: tmz at pobox.com (Todd Zullinger) Date: Thu, 26 Feb 2009 09:24:22 -0500 Subject: GnuPG and Python In-Reply-To: <200902260839.34144.bernhard@intevation.de> References: <49A2AC0E.8030305@buanzo.com.ar> <49A5D379.3050308@katehok.ac93.org> <49A5D551.206@buanzo.com.ar> <200902260839.34144.bernhard@intevation.de> Message-ID: <20090226142422.GJ4505@inocybe.teonanacatl.org> Bernhard Reiter wrote: > Igor, you are confirming that there is only one python gpgme > interface as py-gnupg does not seem to use gpgme. There are a couple > of other non-gpgme python interface attempts. (Which I am too lazy > too look up right now.) There is also pygpgme: https://launchpad.net/pygpgme -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Going to hell when I die would just be redundant. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From d.paleino at gmail.com Tue Feb 17 16:13:38 2009 From: d.paleino at gmail.com (David Paleino) Date: Tue, 17 Feb 2009 16:13:38 +0100 Subject: Keyrings file format In-Reply-To: <499AD394.90004@ruhr-uni-bochum.de> References: <20090106105826.2b34ebca@gmail.com> <20090106171220.7973c468@gmail.com> <499AD394.90004@ruhr-uni-bochum.de> Message-ID: <20090217161338.39e5061c@gmail.com> On Tue, 17 Feb 2009 16:11:16 +0100, Marcus Brinkmann wrote: > Hi, Hello, > David Paleino wrote: > > Also, I could've written a binding to libgpgme -- but that too reads gpg's > > output, so I preferred doing that myself to avoid one more layer of > > complexity / bugs / whatever. > > Sorry for jumping into the discussion so late, but: By duplicating the code in > GPGME you are not avoiding the bugs, you are just making them yourselves. But > now you can't benefit from our fixes in GPGME (and we can't benefit from > yours). > > GPGME isn't the answer to all needs, but it should provide a useful basis for > any further enhancements to the API you can think of. Yes, my later plans were to start using libgpgme :) Thank you for your contribution, David -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 ----|---- http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From i.demonstrate at gmail.com Thu Feb 19 06:33:34 2009 From: i.demonstrate at gmail.com (He, Li) Date: Thu, 19 Feb 2009 13:33:34 +0800 Subject: Cross compilation failed Message-ID: <200902191333.34482.I.demonstrate@gmail.com> Hi all. I want to make a Win32 port of GnuPG 2.0.10 from my sid with the help of mingw32. $ dpkg -l "mingw32*" Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig- aWait/Trig-pend |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-=====================-=====================- ========================================================== ii mingw32 4.2.1.dfsg-1 Minimalist GNU win32 (cross) compiler ii mingw32-binutils 2.18.50-20080109-1 Minimalist GNU win32 (cross) binutils ii mingw32-runtime 3.13-1 Minimalist GNU win32 (cross) runtime I downloaded the following libraries for building GnuPG: libgcrypt-1.4.4.tar.bz2 w32pth-2.0.2.tar.bz2 libgpg-error-1.7.tar.bz2 zlib-1.2.3.tar.gz gettext-0.17.tar.gz libiconv-1.12.tar.gz readline-5.0-1-bin.zip readline-5.0-1-lib.zip libassuan-1.0.5 libksba-1.0.5.tar.bz2 libassuan-1.0.5.tar.bz2 When cross compiling libassuan, I got the following warnings: configure: WARNING: *** *** Data structure for sending ancillary data missing. *** Descriptor passing won't work. *** *** *** No implementation of fopencookie or funopen available. *** The assuan_get_data_fp feature won't work. *** But it succeeded in creating the library itself. However when it comes to linking GnuPG, something went wrong: i586-mingw32msvc-gcc -g -O2 -Wall -Wno-pointer-sign -Wpointer-arith -L/home/heli/w32root/lib -o gpg2.exe gpg.o server.o build-packet.o compress.o free-packet.o getkey.o keydb.o keyring.o seskey.o kbnode.o mainproc.o armor.o mdfilter.o textfilter.o progress.o misc.o rmd160.o openfile.o keyid.o parse-packet.o cpr.o plaintext.o sig-check.o keylist.o pkglue.o pkclist.o skclist.o pubkey-enc.o passphrase.o seckey-cert.o encr-data.o cipher.o encode.o sign.o verify.o revoke.o decrypt.o keyedit.o dearmor.o import.o export.o trustdb.o tdbdump.o tdbio.o delkey.o keygen.o helptext.o keyserver.o photoid.o call- agent.o card-util.o exec.o ../common/libcommon.a ../jnlib/libjnlib.a ../gl/libgnu.a ../common/libgpgrl.a -lz -lreadline -lws2_32 - lgcrypt -lassuan -lgpg-error /home/heli/w32root/lib/libiconv.dll.a - L/home/heli/w32root/lib /home/heli/w32root/lib/libassuan.a(assuan-socket.o): In function `_assuan_sock_bind': /home/heli/w32src/libassuan-1.0.5/src/assuan-socket.c:300: undefined reference to `_bind at 12' /home/heli/w32src/libassuan-1.0.5/src/assuan-socket.c:260: undefined reference to `_htonl at 4' /home/heli/w32src/libassuan-1.0.5/src/assuan-socket.c:280: undefined reference to `_bind at 12' /home/heli/w32src/libassuan-1.0.5/src/assuan-socket.c:282: undefined reference to `_getsockname at 12' /home/heli/w32src/libassuan-1.0.5/src/assuan-socket.c:292: undefined reference to `_ntohs at 4' /home/heli/w32root/lib/libassuan.a(assuan-socket.o): In function `_assuan_sock_connect': /home/heli/w32src/libassuan-1.0.5/src/assuan-socket.c:228: undefined reference to `_connect at 12' /home/heli/w32src/libassuan-1.0.5/src/assuan-socket.c:203: undefined reference to `_htons at 4' /home/heli/w32src/libassuan-1.0.5/src/assuan-socket.c:204: undefined reference to `_htonl at 4' /home/heli/w32src/libassuan-1.0.5/src/assuan-socket.c:211: undefined reference to `_connect at 12' /home/heli/w32root/lib/libassuan.a(assuan-socket.o): In function `_assuan_sock_new': /home/heli/w32src/libassuan-1.0.5/src/assuan-socket.c:176: undefined reference to `_socket at 12' /home/heli/w32root/lib/libassuan.a(assuan-uds.o): In function `uds_writer': /home/heli/w32src/libassuan-1.0.5/src/assuan-uds.c:187: undefined reference to `_sendto at 24' /home/heli/w32root/lib/libassuan.a(assuan-uds.o): In function `uds_reader': /home/heli/w32src/libassuan-1.0.5/src/assuan-uds.c:155: undefined reference to `_recvfrom at 24' collect2: ld returned 1 exit status make[2]: *** [gpg2.exe] Error 1 make[2]: Leaving directory `/home/heli/MyDownloads/gnupg-2.0.10/g10' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/heli/MyDownloads/gnupg-2.0.10' make: *** [all] Error 2 I think there might be something wrong with my compilation of libassuan. But I am not sure what caused it. Could anybody tell me how to fix it? Thank you a lot! -- He, Li Shanghai Key Lab of Intelligent Information Processing School of Computer Science, Fudan University, Shanghai, China E-mail: I.demonstrate at gmail.com