From albrecht.dress at arcor.de Wed Sep 1 16:53:29 2004 From: albrecht.dress at arcor.de (=?iso-8859-1?q?Albrecht_Dre=DF?=) Date: Wed Sep 1 16:50:53 2004 Subject: [OT] pinentry 0.7.1 & Gtk+-2 In-Reply-To: <87d61p62h5.wl@ulysses.g10code.com> (from marcus.brinkmann@ruhr-uni-bochum.de on Tue Aug 17 20:31:18 2004) References: <20040523143643.GA1078@antares.localdomain> <87d61p62h5.wl@ulysses.g10code.com> Message-ID: <1094050419l.1437l.3l@antares.localdomain> Hi Marcus, sorry for answering late - I returned from my holiday (*without* internet) only yesterday... Am 17.08.04 20:31 schrieb(en) Marcus Brinkmann: > Thanks for providing this patch. I have put it into CVS now. There Wow, cool... thanks a lot!! > 1. The GNU coding style should be honored, at least for our own code. > It doesn't make much sense for gtksecentry.{c,h}, but I changed it > for pinentry-gtk-2.c. Please keep this in mind for the future. Sorry.. I'll do that! Is "indent -gnu" sufficient, or do you recommend/ require additional options? > 2. We need a clearer copyright statement from you for [snip] > The simplest thing for you would be to just add yourself to the top > of the file, where the other authors are listed, like this: A patch (against today's cvs) is attached. I hope it's o.k. now? > 3. We have no copyright in padlock-keyhole.xpm. I think you told me Starting with gtk+ 2.4.0, this icon is now a "stock" one (and not only referred to in the gnome hig). So you can (should) remove the xpm file from the cvs, the (tiny) changes needed in the sources are again in the patch below. > 4. I think we would want assignment for the changes to > pinentry-gtk-2.c and the configure.ac and Makefile.am files > (gtksecentry.{h,c} are special again). Are you willing to do that? Sure, if you tell me what I have to do... ;-)) Thanks, Albrecht. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Albrecht Dre? - Johanna-Kirchner-Stra?e 13 - D-53123 Bonn (Germany) Phone (+49) 228 6199571 - mailto:albrecht.dress@arcor.de _________________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: pinentry-patch-20040901.diff.gz Type: application/x-gzip Size: 973 bytes Desc: not available Url : /pipermail/attachments/20040901/1c73d740/pinentry-patch-20040901.diff.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20040901/1c73d740/attachment.bin From marcus.brinkmann at ruhr-uni-bochum.de Thu Sep 2 03:46:49 2004 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Thu Sep 2 03:43:46 2004 Subject: [OT] pinentry 0.7.1 & Gtk+-2 In-Reply-To: <1094050419l.1437l.3l@antares.localdomain> References: <20040523143643.GA1078@antares.localdomain> <87d61p62h5.wl@ulysses.g10code.com> <1094050419l.1437l.3l@antares.localdomain> Message-ID: <87k6vdphme.wl@ulysses.g10code.com> At Wed, 01 Sep 2004 14:53:29 +0000, Albrecht Dre? wrote: > Am 17.08.04 20:31 schrieb(en) Marcus Brinkmann: > > 1. The GNU coding style should be honored, at least for our own code. > > It doesn't make much sense for gtksecentry.{c,h}, but I changed it > > for pinentry-gtk-2.c. Please keep this in mind for the future. > > Sorry.. I'll do that! Is "indent -gnu" sufficient, or do you recommend/ > require additional options? Well, for the patch I already did that, at least for those parts we want it for. I really recommend reading the GNU standards and using the emacs C mode in its default settings, this will get most of it right. I guess indent will also do a good job, but I never tried it. Manual discretion is always required in some cases, for example when the number and content of comments is regarded (a simple rule is to put two spaces after each full stop, but of course there are some periods which do not end a sentence, and then you only need one space, etc). Also I don't think indent will touch things like this: int a, b; which should be int a; int b; and it probably won't deal with other issues like not initializing static or global variables, etc. It's a huge topic. > > 2. We need a clearer copyright statement from you for > [snip] > > The simplest thing for you would be to just add yourself to the top > > of the file, where the other authors are listed, like this: > > A patch (against today's cvs) is attached. I hope it's o.k. now? Looks fine. > > 3. We have no copyright in padlock-keyhole.xpm. I think you told me > > Starting with gtk+ 2.4.0, this icon is now a "stock" one (and not only > referred to in the gnome hig). So you can (should) remove the xpm file > from the cvs, the (tiny) changes needed in the sources are again in the > patch below. Excellent. > > 4. I think we would want assignment for the changes to > > pinentry-gtk-2.c and the configure.ac and Makefile.am files > > (gtksecentry.{h,c} are special again). Are you willing to do that? > > Sure, if you tell me what I have to do... ;-)) Actually, after discussing this with Werner, it turns out we do not require this, because of the nature of the pinentry package. I just had an idea though. If you really care about this a lot, you may want to make a secure widget part of gtk proper. This might require making the code a bit more abstract to allow setting callbacks for memory allocation. I found out that making a widget secure usually requires messing with intimate internals of the widget set, and thus I think there is some sense in letting widget people deal with it, not application writers (ie, you not only derive from standard widgets, but you go into the implementation of existing widgets). In the process of adding such a beast to gtk, you would assign your changes to whatever gtk people assign their changes, probably the FSF. But if that doesn't sound like fun for you, don't sweat it. We are quite happy with having all this messy stuff in pinentry just as well. Thanks, Marcus From flz at xbsd.org Wed Sep 1 03:12:07 2004 From: flz at xbsd.org (Florent Thoumie) Date: Thu Sep 2 13:18:33 2004 Subject: Http-Proxy Authentification Support Message-ID: <413521E7.3090609@xbsd.org> Hi ! I've just written a quick and dirty patch to add authentification support for http-proxies. With this patch, do_parse_uri() now support this scheme : -> http://username:password@proxy.example.com:3128 I haven't found such a patch, so I thought some people could be quite interested in this. Here is the patch attached, it applies cleanly against 1.2.5 and 1.2.6. Hope it'll be useful. Thanks for your work ! PS: I'm not subscribed to the list, so please keep me in Cc: field. -- Florent Thoumie flz@xbsd.org -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch-gnupg Url: /pipermail/attachments/20040901/5bea0bc7/patch-gnupg.txt -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20040901/5bea0bc7/signature.bin From mike at halcrow.us Thu Sep 2 19:04:46 2004 From: mike at halcrow.us (Michael Halcrow) Date: Thu Sep 2 20:10:19 2004 Subject: Minimal GnuPG-processable File Message-ID: <20040902170446.GA17203@halcrow.us> I'm working on an encrypting filesystem that has the option of writing files that are in OpenPGP format. I've been looking over RFC 2440 and the source for GnuPG, and I would like to verify something with someone who is knowledgeable in this subject, just to make sure that I am on the right track. I'm not asking a lot; I just want to know that I will be debugging code that resembles something sane in the first place. I want to start out as simple as possible - basically, a passphrase-encrypted session key and a packet of encrypted data. I need to write out, byte-for-byte, this entire file, and GnuPG needs to be able to decrypt it with a passphrase. Here is what I have so far (basically, I'm writing an ESK packet (tag 3) and a data packet (tag 9): page_virt = (__user char*)kmalloc( PAGE_CACHE_SIZE, GFP_USER ); i = 0; page_virt[i++] = 0xc3; /* ctb; tag 3 = ESK */ i++; /* size comes later */ /* - A one-octet version number. The only currently defined * version is 4. */ page_virt[i++] = 4; /* - A one-octet number describing the symmetric algorithm * used. */ page_virt[i++] = 4; /* Blowfish */ /* - A string-to-key (S2K) specifier, length as defined * above. */ page_virt[i++] = 0x01; /* salted s2k */ page_virt[i++] = 1; /* md5 */ memcpy( &page_virt[i], "saltsalt", 8 ); /* test value */ i += 8; /* - Optionally, the encrypted session key itself, which is * decrypted with the string-to-key object. */ cryptfs_md5( session_key_encryption_key, "saltsaltpassword", 16 ); /* The decryption result consists of a one-octet algorithm * identifier that specifies the symmetric-key encryption algorithm * used to encrypt the following Symmetrically Encrypted Data Packet, * followed by the session key octets themselves. */ cipher_and_session_key[0] = 4; /* Blowfish */ memcpy( &cipher_and_session_key[1], crypt_stats->key, crypt_stats->key_size_bits/8 ); /* ... crypto initialization code removed for brevity ... */ crypto_cipher_encrypt( tfm, dest_sg, src_sg, (crypt_stats->key_size_bits/8)+1 ); memcpy( &page_virt[i], encrypted_cipher_and_session_key, (crypt_stats->key_size_bits/8)+1 ); i += (crypt_stats->key_size_bits/8)+1; page_virt[1] = i; So at this point, I've written out an ESK packet (I hope). Now, can I just follow it up with a Symmetrically Encrypted Data Packet (Tag 9) packet, right? And it is a requirement that I encapsulate a plaintext packet in the encrypted packet, or can I just write raw data? I am going to be testing this code next week, and it would really speed up the debugging process if someone could let me know whether or not I am even on the right track here, or if there is some glaring omission (like, I'm missing a required packet or making a silly assumption). Thanks, Mike .___________________________________________________________________. Michael A. Halcrow Security Software Engineer, IBM Linux Technology Center GnuPG Fingerprint: 05B5 08A8 713A 64C1 D35D 2371 2D3C FDDA 3EB6 601D -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20040902/fe9475d8/attachment.bin From mike at halcrow.us Thu Sep 2 23:19:27 2004 From: mike at halcrow.us (Michael Halcrow) Date: Fri Sep 3 00:24:57 2004 Subject: Minimal GnuPG-processable File In-Reply-To: <20040902170446.GA17203@halcrow.us> References: <20040902170446.GA17203@halcrow.us> Message-ID: <20040902211927.GA20011@halcrow.us> I just ran gpg through gdb and watched how it broke up packets, so I think I understand the process and file format well enough at this point. It looks like the session key is just derived from the passphrase. In OpenPGP, is there a way to specify a different session key, and have the key itself be encrypted by a key derived from the passphrase? If I have several tag 3 packets encapsulating tag 11 packets concatenated together (to support random access), will GnuPG just know to use the most recent session key for each of the packets, or will it expect a separate tag 3 packet for each tag 11 packet? If I use the _CONSOLE filename for each tag 11 packet, will GPG simply dump out a concatenation of the contents of each packet (so one can do gpg -d file.gpg > file)? Again, I'll figure all this out on my own soon enough, but any comments would be helpful. Mike .___________________________________________________________________. Michael A. Halcrow Security Software Engineer, IBM Linux Technology Center GnuPG Fingerprint: 05B5 08A8 713A 64C1 D35D 2371 2D3C FDDA 3EB6 601D If you understand what you're doing, you're not learning anything. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20040902/3ebfb314/attachment.bin From aniketpkate at cse.iitb.ac.in Fri Sep 3 09:04:51 2004 From: aniketpkate at cse.iitb.ac.in (Kate Aniket Pundlik) Date: Fri Sep 3 16:52:24 2004 Subject: Using GPG Keys for the Kerberos Users Identification Message-ID: <41381793.8000104@cse.iitb.ac.in> Hello, I am a Computer Science graduate student at IIT Bombay, India. Due to our interest in Kerberos and PGP, my team is thinking of doing the project "Using GPG Keys for the Kerberos Users Identification". But we have lots of doubts about these like Which API or library of GnuPG to be used or can be more suitable ? How to make use this for pratical purpose ? Can any body guide us how to go about that ? Is it the right forum to ask this ? If not them please guide us where to go ? Thanks in advance. Regards, Aniket Kate, MTech - I, IIT B, Mumbai, India -76 From jas at extundo.com Fri Sep 3 22:46:49 2004 From: jas at extundo.com (Simon Josefsson) Date: Fri Sep 3 22:47:22 2004 Subject: Using GPG Keys for the Kerberos Users Identification References: <41381793.8000104@cse.iitb.ac.in> Message-ID: Kate Aniket Pundlik writes: > Hello, > I am a Computer Science graduate student at IIT Bombay, India. > Due to our interest in Kerberos and PGP, my team is thinking of doing > the project "Using GPG Keys for the Kerberos Users Identification". But > we have lots of doubts about these like > Which API or library of GnuPG to be used or can be more > suitable ? > How to make use this for pratical purpose ? I'm not sure it is what you are looking for, but Shishi will be able to do initial user authentication to Kerberos using OpenPGP keys, instead of using normal Kerberos passwords. The idea is to negotiate TLS to the Kerberos server, then use OpenPGP authentication in TLS, and then have the Kerberos server give out a Kerberos TGT for the user based on the TLS authentication. The TGT can be used to authenticate to Kerberos services as any other TGT. The last public Shishi release support X.509 authentication on the client side. Adding the OpenPGP part is pending, but should be simple given the good support for OpenPGP in GnuTLS. A practical remaining problem is that, if I understand correctly, GnuTLS do not support the same OpenPGP key rings that GnuPG uses. Since GnuPG isn't involved, this might be off topic here, but I'd be happy to discuss this with anyone interested. The protocol to negotiate TLS against the Kerberos is specific for Shishi, I have described it in the Shishi manual: http://www.gnu.org/software/shishi/manual/html_node/STARTTLS-protected-KDC-exchanges.html Thanks, Simon From dshaw at jabberwocky.com Fri Sep 3 23:20:57 2004 From: dshaw at jabberwocky.com (David Shaw) Date: Fri Sep 3 23:18:29 2004 Subject: Minimal GnuPG-processable File In-Reply-To: <20040902211927.GA20011@halcrow.us> References: <20040902170446.GA17203@halcrow.us> <20040902211927.GA20011@halcrow.us> Message-ID: <20040903212057.GA4879@jabberwocky.com> On Thu, Sep 02, 2004 at 04:19:27PM -0500, Michael Halcrow wrote: > I just ran gpg through gdb and watched how it broke up packets, so I > think I understand the process and file format well enough at this > point. It looks like the session key is just derived from the > passphrase. In OpenPGP, is there a way to specify a different session > key, and have the key itself be encrypted by a key derived from the > passphrase? Yes. The tag 3 packet can support both "passphrase mangled to key" and "passphrase mangled to key that is used to decrypt session key" functionality. GnuPG can decrypt either form. > If I have several tag 3 packets encapsulating tag 11 packets > concatenated together (to support random access), will GnuPG just > know to use the most recent session key for each of the packets, or > will it expect a separate tag 3 packet for each tag 11 packet? If I > use the _CONSOLE filename for each tag 11 packet, will GPG simply > dump out a concatenation of the contents of each packet (so one can > do gpg -d file.gpg > file)? Again, I'll figure all this out on my > own soon enough, but any comments would be helpful. Unfortunately, you're creating packet arrangements that never occur in current OpenPGP usage, so you're likely to hit some problems. Check the grammar in RFC-2440: tag 3(tag 11 + tag 11) isn't currently legal OpenPGP. tag 3 (tag 11) + tag 3 (tag 11) is not exactly legal either, but could be treated as two different messages, each consisting of a 3(11). I seem to recall that GnuPG doesn't handle that right now, but don't recall the reason offhand. David From ajgpgml at tesla.inka.de Sun Sep 5 19:09:52 2004 From: ajgpgml at tesla.inka.de (Andreas John) Date: Sun Sep 5 19:06:09 2004 Subject: GnuPG 1.2.6 binary for win32? References: <200409021539.RAA02725@vulcan.xs4all.nl> <87sma0ppop.fsf@wheatstone.g10code.de> Message-ID: <004e01c4936b$2d268760$2baae4d9@tesla> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! > We have nio locking in Windows at all. IIRC, all files are opened in > "compatibility" mode, meaning that only one process may have it open. Well, this is what I found out about Compatibility mode: Any process can open the file any number of times with this mode. It fails if the file's opened in any other sharing mode. And: Because the default is "compatibility" mode, it means that by default most applications can't ensure the integrity of their data. Instead of your data being secure by default, you need to take special actions to guarantee that nobody else messes with the data. (http://blogs.msdn.com/larryosterman/archive/2004/05/13/131263.aspx) Another thing: I just had a quick look into the GPG1.2.6 dotlock.c (to get a better feel for the problem) and I think I've found a small memleak for win32: The destroy_dotlock()-function does nothing for DOSISH_SYSTEM, whereas the create_dotlock()-function doesn't do too much, but at least mallocs the returned DOTLOCK as well as the lockname-member, so the mfree gets never called. I'm not sure, but it seems not too hairy to write some win32-code to do the required locking with dropping of the verbose dotlock-file-management (eg. using _get_osfhandle() and LockFile()?). Is there any work done for GPG 1.4? Or won't proper handling for win32 be there even with GPG 2.0? In case this was discussed already, please give me note. Also, I'd be willing to do spend some time coding myself if required to get it done. So indeed I'm interrested in discussing this topic. Anyway, I believe the bigger problem is the different rename-semantics of windows and unix. The SHARE_DELETE-Flag might help, but is not available in win9x. So if it should become correctly working in all blends of windows there must be some other mechanism implemented to do the renaming (eg., also lock files for read-access, and then copy whole data into the locked file instead of rename). Hehe, okay, I really doubt you'll consider this at a stage this late :)) But has anybody a better solution? Maybe some mechanism to let the rename be done by the last instance of gpg running? Also a complex task for an unloved system... Bye! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) - GPGrelay v0.954 iD8DBQFBO0hrnTiKrQObWqkRApngAJ9GVCSUE2qy3rm+CTHN8N2Eyd7M7gCfdWab trFq2QwTLK0HoV9uGtvg7vs= =FI1Z -----END PGP SIGNATURE----- From wk at gnupg.org Mon Sep 6 10:19:46 2004 From: wk at gnupg.org (Werner Koch) Date: Mon Sep 6 10:18:58 2004 Subject: GnuPG 1.2.6 binary for win32? In-Reply-To: <004e01c4936b$2d268760$2baae4d9@tesla> (Andreas John's message of "Sun, 5 Sep 2004 19:09:52 +0200") References: <200409021539.RAA02725@vulcan.xs4all.nl> <87sma0ppop.fsf@wheatstone.g10code.de> <004e01c4936b$2d268760$2baae4d9@tesla> Message-ID: <877jr7dd25.fsf@wheatstone.g10code.de> On Sun, 5 Sep 2004 19:09:52 +0200, Andreas John said: > Well, this is what I found out about Compatibility mode: Any process > can open the file any number of times with this mode. It fails if > the file's opened in any other sharing mode. OKay, compatibility mode might not be the correct term. Anyway, files are opened in the default mode and thus only the first open will succeed and all other opens are going to fail - even from the same process. This is the reason whey we had to tweak the file opening from time to time. IIRC, 1.3.x currently has a problem with this. > Another thing: I just had a quick look into the GPG1.2.6 dotlock.c (to get a better feel for the problem) and I think I've found a small memleak for win32: > The destroy_dotlock()-function does nothing for DOSISH_SYSTEM, whereas the create_dotlock()-function doesn't do too much, but at least mallocs the returned DOTLOCK as well as the lockname-member, so the mfree gets never called. Thanks. I fix it. > I'm not sure, but it seems not too hairy to write some win32-code to do the required locking with dropping of the verbose dotlock-file-management (eg. using _get_osfhandle() and LockFile()?). We don't need any locking unless we want to improve on the performance ;-) > Anyway, I believe the bigger problem is the different rename-semantics of windows and unix. We know that there is a problem but did not look closer at it. > The SHARE_DELETE-Flag might help, but is not available in win9x. So we can't use it. Salam-Shalom, Werner p.s. Please take care not use use overlong lines, your lines are far too long; 72 is a good limit. From wk at gnupg.org Mon Sep 6 10:26:47 2004 From: wk at gnupg.org (Werner Koch) Date: Mon Sep 6 10:28:51 2004 Subject: Minimal GnuPG-processable File In-Reply-To: <20040903212057.GA4879@jabberwocky.com> (David Shaw's message of "Fri, 3 Sep 2004 17:20:57 -0400") References: <20040902170446.GA17203@halcrow.us> <20040902211927.GA20011@halcrow.us> <20040903212057.GA4879@jabberwocky.com> Message-ID: <873c1vdcqg.fsf@wheatstone.g10code.de> On Fri, 3 Sep 2004 17:20:57 -0400, David Shaw said: > be treated as two different messages, each consisting of a 3(11). I > seem to recall that GnuPG doesn't handle that right now, but don't > recall the reason offhand. That's due to an old problem with the signature format. We tried to figure out where a messages ends but this is not always possible in cases where old signatures (sig||data) and new signatures withou one-pass-packets (data||sig) are concatenated. Werner From albrecht.dress at arcor.de Mon Sep 6 19:36:34 2004 From: albrecht.dress at arcor.de (=?iso-8859-1?q?Albrecht_Dre=DF?=) Date: Mon Sep 6 19:33:25 2004 Subject: [OT] pinentry 0.7.1 & Gtk+-2 In-Reply-To: <87k6vdphme.wl@ulysses.g10code.com> (from marcus.brinkmann@ruhr-uni-bochum.de on Thu Sep 2 03:46:49 2004) References: <20040523143643.GA1078@antares.localdomain> <87d61p62h5.wl@ulysses.g10code.com> <1094050419l.1437l.3l@antares.localdomain> <87k6vdphme.wl@ulysses.g10code.com> Message-ID: <1094492202l.1399l.0l@antares.localdomain> Am 02.09.04 03:46 schrieb(en) Marcus Brinkmann: > I just had an idea though. If you really care about this a lot, you > may want to make a secure widget part of gtk proper. This might > require making the code a bit more abstract to allow setting callbacks > for memory allocation. I found out that making a widget secure > usually requires messing with intimate internals of the widget set, > and thus I think there is some sense in letting widget people deal > with it, not application writers (ie, you not only derive from > standard widgets, but you go into the implementation of existing > widgets). > > In the process of adding such a beast to gtk, you would assign your > changes to whatever gtk people assign their changes, probably the FSF. I added two bugzillas (glib for mem allocation, and gtk+ for the entry) for that a few minutes ago [1, 2]. If I find some time, I could try to at least provide parts of it myself. But there is s/mime support for balsa waiting, as well as some stuff left for GnuPG, so this will be anything else but fast... Cheers, Albrecht. [1] http://bugzilla.gnome.org/show_bug.cgi?id=151999 [2] http://bugzilla.gnome.org/show_bug.cgi?id=152001 -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Albrecht Dre? - Johanna-Kirchner-Stra?e 13 - D-53123 Bonn (Germany) Phone (+49) 228 6199571 - mailto:albrecht.dress@arcor.de _________________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20040906/e707c42e/attachment.bin From uug at halcrow.us Thu Sep 9 15:14:36 2004 From: uug at halcrow.us (Michael Halcrow) Date: Fri Sep 10 13:09:30 2004 Subject: Minimal GnuPG-processable File In-Reply-To: <873c1vdcqg.fsf@wheatstone.g10code.de> References: <20040902170446.GA17203@halcrow.us> <20040902211927.GA20011@halcrow.us> <20040903212057.GA4879@jabberwocky.com> <873c1vdcqg.fsf@wheatstone.g10code.de> Message-ID: <20040909131436.GA2089@halcrow.us> On Mon, Sep 06, 2004 at 10:26:47AM +0200, Werner Koch wrote: > On Fri, 3 Sep 2004 17:20:57 -0400, David Shaw said: > > be treated as two different messages, each consisting of a 3(11). > > I seem to recall that GnuPG doesn't handle that right now, but > > don't recall the reason offhand. > > That's due to an old problem with the signature format. We tried to > figure out where a messages ends but this is not always possible in > cases where old signatures (sig||data) and new signatures withou > one-pass-packets (data||sig) are concatenated. This complicates my attempt to write ``pgpfs''. I need to be able to seek into the middle of the file and modify a portion without having to decrypt everything before that point and encrypt everything past that point; I would like to limit the amount that I have to decrypt and encrypt to about one page. The performance will leave something to be desired, but as long as OpenPGP dictates CFB, I have little choice if I want GnuPG to be able to read the files written by my filesystem. Any suggestions on how to approach this? If GnuPG could only support *reading* data encrypted using CTR mode, this would solve a lot of my problems. If I were to submit a patch for this, how likely would the GnuPG maintainers be to accepting it? It would probably involve adding a new set of extended values for Symmetric Key Algorithm identifiers. The RFC defines 100 to 110 as ``Private/Experimental'' algorithms; maybe they could be CTR-mode versions of the algorithms? The primary goal here is for files written by cryptfs to be readable by a common userspace utility like GnuPG. Thanks, Mike .___________________________________________________________________. Michael A. Halcrow Security Software Engineer, IBM Linux Technology Center GnuPG Fingerprint: 05B5 08A8 713A 64C1 D35D 2371 2D3C FDDA 3EB6 601D -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20040909/268a5082/attachment.bin From mike at halcrow.us Thu Sep 9 15:43:14 2004 From: mike at halcrow.us (Michael Halcrow) Date: Fri Sep 10 13:09:33 2004 Subject: Minimal GnuPG-processable File] Message-ID: <20040909134313.GA2581@halcrow.us> I'm resending this; my mail header mangler messed things up the first time. On Mon, Sep 06, 2004 at 10:26:47AM +0200, Werner Koch wrote: > On Fri, 3 Sep 2004 17:20:57 -0400, David Shaw said: > > be treated as two different messages, each consisting of a 3(11). > > I seem to recall that GnuPG doesn't handle that right now, but > > don't recall the reason offhand. > > That's due to an old problem with the signature format. We tried to > figure out where a messages ends but this is not always possible in > cases where old signatures (sig||data) and new signatures withou > one-pass-packets (data||sig) are concatenated. This complicates my attempt to write ``pgpfs''. I need to be able to seek into the middle of the file and modify a portion without having to decrypt everything before that point and encrypt everything past that point; I would like to limit the amount that I have to decrypt and encrypt to about one page. The performance will leave something to be desired, but as long as OpenPGP dictates CFB, I have little choice if I want GnuPG to be able to read the files written by my filesystem. Any suggestions on how to approach this? If GnuPG could only support *reading* data encrypted using CTR mode, this would solve a lot of my problems. If I were to submit a patch for this, how likely would the GnuPG maintainers be to accepting it? It would probably involve adding a new set of extended values for Symmetric Key Algorithm identifiers. The RFC defines 100 to 110 as ``Private/Experimental'' algorithms; maybe they could be CTR-mode versions of the algorithms? The primary goal here is for files written by cryptfs to be readable by a common userspace utility like GnuPG. Thanks, Mike .___________________________________________________________________. Michael A. Halcrow Security Software Engineer, IBM Linux Technology Center GnuPG Fingerprint: 05B5 08A8 713A 64C1 D35D 2371 2D3C FDDA 3EB6 601D The sum of the Universe is zero. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20040909/74d8530c/attachment.bin From mroth at nessie.de Sun Sep 12 18:30:35 2004 From: mroth at nessie.de (Michael Roth) Date: Mon Sep 13 18:36:40 2004 Subject: Problems with --export-secret-subkeys and deleted subkeys Message-ID: <414479AB.8020700@nessie.de> Hello list, I have an odd problem. I created a DSA primary key, with two subkeys on it, a DSA sign only and a RSA encrypt only subkey: /home/mroth/.gnupg-test/pubring.gpg ----------------------------------- pub 1024D/19A47D04 2004-09-12 GnuPG Test sub 1024D/01D44C96 2004-09-12 [expires: 2004-09-26] sub 1024R/A2F45B3E 2004-09-12 [expires: 2004-09-26] Then I fiddled with --export-secret-subkeys and deleted one subkey from the secret key to get the following secret keyring: /home/mroth/.gnupg-test/secring.gpg ----------------------------------- sec# 1024D/19A47D04 2004-09-12 GnuPG Test ssb 1024D/01D44C96 2004-09-12 The secret subkey of the RSA encryption subkey is deleted in the secret keyring and the primary secret key is scrambled. Now, it should possible, to sign some data with the DSA subkey: # gpg-test -v -s --local-user 0x01D44C96! file.txt But I get the following output: gpg: no secret subkey for public subkey A2F45B3E - ignoring gpg: skipped `0x01D44C96!': unusable secret key gpg: signing failed: unusable secret key But that's wrong. 0x01D44C96 should be useable, because the secret subkey is available and it isn't the scrambled primary secret key. I can verify this by using --edit-key to delete the RSA public subkey from the public keyring: /home/mroth/.gnupg-test/pubring.gpg ----------------------------------- pub 1024D/19A47D04 2004-09-12 GnuPG Test sub 1024D/01D44C96 2004-09-12 [expires: 2004-09-26] The secret keyring is still unchanged: /home/mroth/.gnupg-test/secring.gpg ----------------------------------- sec# 1024D/19A47D04 2004-09-12 GnuPG Test ssb 1024D/01D44C96 2004-09-12 Now, if I try the command from above: # gpg-test -v -s --local-user 0x01D44C96! file.txt All will work fine and I get: gpg: using secondary key 01D44C96 instead of primary key 19A47D04 You need a passphrase to unlock the secret key for user: "GnuPG Test" gpg: using secondary key 01D44C96 instead of primary key 19A47D04 1024-bit DSA key, ID 01D44C96, created 2004-09-12 (main key ID 19A47D04) gpg: writing to `file.txt.gpg' gpg: DSA signature from: "01D44C96 GnuPG Test" So, the problem is, if there is a subkey on the public keyring presented, which doesn't have a corresponding secret subkey on an scrambled primary key, gnupg somehow fails. I tried to find the error in getkey.c function premerge_public_with_secret(), but had no success, maybe I'm just to stupid... :-\ I used gnupg 1.2.5 for these tests, but I guess the problem is also presented in 1.2.6. Any idea, where I should search the failure? Any hints or pointers? cu Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 222 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20040912/438afd63/signature.bin From dshaw at jabberwocky.com Mon Sep 13 20:43:49 2004 From: dshaw at jabberwocky.com (David Shaw) Date: Mon Sep 13 20:40:58 2004 Subject: Problems with --export-secret-subkeys and deleted subkeys In-Reply-To: <414479AB.8020700@nessie.de> References: <414479AB.8020700@nessie.de> Message-ID: <20040913184349.GC12988@jabberwocky.com> On Sun, Sep 12, 2004 at 06:30:35PM +0200, Michael Roth wrote: > So, the problem is, if there is a subkey on the public keyring > presented, which doesn't have a corresponding secret subkey on an > scrambled primary key, gnupg somehow fails. Very interesting bug, and excellent research (I love bug reports like this). Can you try two things for me? First, try to make the signature with --no-sig-cache set. If that works, then try the attached patch. David -------------- next part -------------- Index: getkey.c =================================================================== RCS file: /cvs/gnupg/gnupg/g10/getkey.c,v retrieving revision 1.78.2.32 diff -u -r1.78.2.32 getkey.c --- getkey.c 20 Aug 2004 17:24:07 -0000 1.78.2.32 +++ getkey.c 13 Sep 2004 18:36:53 -0000 @@ -2164,7 +2164,7 @@ assert ( last ); /* find the next subkey */ for (next=pub->next,ll=pub; - next && pub->pkt->pkttype != PKT_PUBLIC_SUBKEY; + next && next->pkt->pkttype != PKT_PUBLIC_SUBKEY; ll = next, next = next->next ) ; /* make new link */ From mroth at nessie.de Mon Sep 13 22:44:42 2004 From: mroth at nessie.de (Michael Roth) Date: Mon Sep 13 22:41:33 2004 Subject: Problems with --export-secret-subkeys and deleted subkeys In-Reply-To: <20040913184349.GC12988@jabberwocky.com> References: <414479AB.8020700@nessie.de> <20040913184349.GC12988@jabberwocky.com> Message-ID: <414606BA.8060700@nessie.de> Hello David, David Shaw wrote: > Very interesting bug, and excellent research (I love bug reports like > this). Can you try two things for me? First, try to make the > signature with --no-sig-cache set. If that works, then try the > attached patch. To make it short: Both proposals work perfectly! Thank you very mutch! In the mean time, I also verified this bug on 1.3.6. cu Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 222 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20040913/e037865f/signature.bin From marcus.brinkmann at ruhr-uni-bochum.de Tue Sep 14 19:21:36 2004 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Tue Sep 14 19:18:16 2004 Subject: strerror_r in libgpg-error 0.5 on Solaris In-Reply-To: <001f01c3d2e1$d2eba900$7608fd0a@corp.mtncameroon.net> References: <001f01c3d2e1$d2eba900$7608fd0a@corp.mtncameroon.net> Message-ID: <87pt4o6a1r.wl@localhost.localdomain> Hi Andreas, At Sun, 4 Jan 2004 17:42:59 +0100, Andreas Almroth wrote: > I have compiled libgpg-error 0.5 on Solaris 2.8 and encountered the > classic problem with strerror_r. > In Solaris the function strerror is thread-safe, and no _r function > exists. > > It would be nice if the configure script could consider this when on > Solaris platform. I don't know enough about autoconf so I can > unfortunately not easily fix a patch for this myself. Well, maybe I > should try... > A perhaps non-important issue, but still... I have checked the following change into CVS, it should do the trick for all versions of Solaris. If you want, check it out and let me know if it works for you. 2004-09-14 Marcus Brinkmann * configure.ac: Call AC_CANONICAL_HOST. Suppress warning about lack of strerror_r on all Solaris platforms. Thanks, Marcus From christof.debaes at vub.ac.be Wed Sep 15 20:40:07 2004 From: christof.debaes at vub.ac.be (Christof Debaes) Date: Wed Sep 15 18:29:56 2004 Subject: ath.c:201: _gcry_ath_mutex_unlock: Assertion `*lock == ((ath_mutex_t) 1)' failed. Message-ID: <200409151840.07260.christof.debaes@vub.ac.be> Hey, I saw the the thread of Thorsten Hirsch about the assertion error with gnupg version 1.9.10, and I have found that here gpg is failing at the same assertion error while generating a new key Here is the end of the output of: gpg --gen-key: >We need to generate a lot of random bytes. It is a good idea to perform >some other action (type on the keyboard, move the mouse, utilize the >disks) during the prime generation; this gives the random number >generator a better chance to gain enough entropy. >ath.c:201: _gcry_ath_mutex_unlock: Assertion `*lock == ((ath_mutex_t) 1)' failed. >Aborted As with Thorsten Hirsch, I'm also running it on a gentoo distribution. It might be related to this. I have recently update from gnupg 1.2.4. Any suggestion what I can test to dig more into this problem? --Christof From mo at g10code.com Wed Sep 15 20:39:29 2004 From: mo at g10code.com (Moritz Schulte) Date: Wed Sep 15 20:36:24 2004 Subject: ath.c:201: _gcry_ath_mutex_unlock: Assertion `*lock == ((ath_mutex_t) 1)' failed. In-Reply-To: <200409151840.07260.christof.debaes@vub.ac.be> References: <200409151840.07260.christof.debaes@vub.ac.be> Message-ID: <20040915183929.GA11368@cuttysark.lan> > I saw the the thread of Thorsten Hirsch about the assertion error with gnupg > version 1.9.10, and I have found that here gpg is failing at the same > assertion error while generating a new key Please try Libgcrypt >= 1.2, in case you are running a lower version right now. I expect this version to fix your problem. Thanks, Moritz -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 192 bytes Desc: not available Url : /pipermail/attachments/20040915/de4e9ba5/attachment.bin From asj at ipa.net Wed Sep 22 04:59:28 2004 From: asj at ipa.net (Alan S. Jones) Date: Wed Sep 22 19:59:32 2004 Subject: Weaknesses in SHA-1 Message-ID: <3.0.5.32.20040921215928.019c2000@popc.ipa.net> I would be curious if anyone knows what the commercial PGP app supports also for a good comparison. I think it would be helpful not just for rumored weaknesses, but for over all compatibility knowledge. Maybe an ongoing table we could keep current. I know t hat SHA-1 has been analyzed more then SHA256, SHA384, or SHA512 thus could actually be stronger. However why not let people create keys with those algorithms also in 1.4? On a side note I know that the 1.3.x series will become the new stable 1.4. However I was wondering when we would see the first builds that actually said 1.4 come along? I figure we will see a much more use of that build series when it actually says 1.4. Alan > >gpg --version > >In 1.2.x, GnuPG supports MD5, SHA1, and RIPEMD160. It also supports >SHA256 read-only (you can verify existing signatures made with SHA256, >but not make new ones). If you compile it with the right options, you >can get SHA384 and SHA512 read-only. TIGER192 is allowed, but >discouraged. > >In 1.4, GnuPG will suppports MD5, SHA1, RIPEMD160, and SHA256. It >will support SHA384 and SHA512 read-only. TIGER192 is removed. > >David -- Alan S. Jones asj@ipa.net http://users.ipa.net/~asj From dshaw at jabberwocky.com Wed Sep 22 20:45:38 2004 From: dshaw at jabberwocky.com (David Shaw) Date: Wed Sep 22 20:42:34 2004 Subject: Weaknesses in SHA-1 In-Reply-To: <3.0.5.32.20040921215928.019c2000@popc.ipa.net> References: <3.0.5.32.20040921215928.019c2000@popc.ipa.net> Message-ID: <20040922184538.GB29202@jabberwocky.com> On Tue, Sep 21, 2004 at 09:59:28PM -0500, Alan S. Jones wrote: > I would be curious if anyone knows what the commercial PGP app supports > also for a good comparison. I think it would be helpful not just for > rumored weaknesses, but for over all compatibility knowledge. Maybe an > ongoing table we could keep current. The best table I've seen on the subject: https://netfiles.uiuc.edu/ehowes/www/pgp-summ.htm It's a little out of date though, only going up to GnuPG 1.2.1. > I know t hat SHA-1 has been analyzed more then SHA256, SHA384, or SHA512 > thus could actually be stronger. However why not let people create keys > with those algorithms also in 1.4? I'm not sure what you mean here - these are hash algorithms. You don't create a key using them. > On a side note I know that the 1.3.x series will become the new > stable 1.4. However I was wondering when we would see the first > builds that actually said 1.4 come along? I figure we will see a > much more use of that build series when it actually says 1.4. It won't be long now. David From t.schorpp at gmx.de Wed Sep 22 21:24:27 2004 From: t.schorpp at gmx.de (Thomas Schorpp) Date: Wed Sep 22 21:22:08 2004 Subject: Weaknesses in SHA-1, gnupg dev versions In-Reply-To: <20040922184538.GB29202@jabberwocky.com> References: <3.0.5.32.20040921215928.019c2000@popc.ipa.net> <20040922184538.GB29202@jabberwocky.com> Message-ID: <4151D16B.5020502@gmx.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Shaw wrote: | On Tue, Sep 21, 2004 at 09:59:28PM -0500, Alan S. Jones wrote: | | I'm not sure what you mean here - these are hash algorithms. You | don't create a key using them. | i would like sha512 too for better protection of my passphrase(?). sorry, i cant afford helping implementing crypto-algorithms in gnupg. | |>On a side note I know that the 1.3.x series will become the new |>stable 1.4. However I was wondering when we would see the first |>builds that actually said 1.4 come along? I figure we will see a |>much more use of that build series when it actually says 1.4. | | | It won't be long now. BTW, have i missed a newer dev-release than 1.3.6, ive seen the trust stepping 1-3 was out and "problems" signing keys...? ill not try cvs due to possible security hazard, since im doing "near production" field tests with the openpgp testcard. are there any newly known security issues and scenarios with >=1.3.6 non ?gypten versions? if theres no official "security quality cycle" in this dev process, i suggest cryptology specialists involved attacking my test key with target "signature reproducal", etc. since i can see a lot of keys without foreign signatures around, the whole trust system should become "suspect" in future ;) | | David | Tom -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.6 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iQCVAwUBQVHRaGqsze5HSzyoAQKseQQArwXQvmVR3w5B++vVcWKKLWWQKVOaXWoN 88I/LoRs37IrmRxsl4wbIC6WsHvVdCqKS87yq0gdLxsjC9WVU6JJ8IgVJvSpGofg NCS4W3rhoEeVOjZ5n+r2IwuFh/7Y+K6Y2FNwFO45OOyB5QtK52miAXQ+Z6LqDfks HNohRbjMVCc= =z7E0 -----END PGP SIGNATURE----- From atom at suspicious.org Thu Sep 23 00:47:27 2004 From: atom at suspicious.org (Atom 'Smasher') Date: Thu Sep 23 00:44:23 2004 Subject: Weaknesses in SHA-1, gnupg dev versions In-Reply-To: <4151D16B.5020502@gmx.de> References: <3.0.5.32.20040921215928.019c2000@popc.ipa.net> <20040922184538.GB29202@jabberwocky.com> <4151D16B.5020502@gmx.de> Message-ID: <20040922184215.K344@willy_wonka> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Wed, 22 Sep 2004, Thomas Schorpp wrote: > i would like sha512 too for better protection of my passphrase(?). > sorry, i cant afford helping implementing crypto-algorithms in gnupg. =============== it may or may not be any better. - --s2k-digest-algo of course that wil work with almost any hash other than SHA-512 ;) hhmmm... just noticed the (1.2.4) man page on that: --s2k-digest-algo name Use name as the digest algorithm used to mangle the passphrases. The default algorithm is SHA-1. This digest algorithm is also used for conventional encryption if --digest-algo is not given. i'm not sure what that last sentence means here, but it's not in the 1.3.6 man page. ...atom _________________________________________ PGP key - http://atom.smasher.org/pgp.txt 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 ------------------------------------------------- "God save the queen and her fascist regime" -- Sex Pistols -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.6 (FreeBSD) Comment: What is this gibberish? Comment: http://atom.smasher.org/links/#digital_signatures iQEcBAEBCAAGBQJBUgEEAAoJEAx/d+cTpVciwisIAIjj/txUb2Gh2PueY6Q7qtXT XAlf6Wf3BXTFFhANIyisP81jqHjAqn16vokUt2wjTsJvpQA10W5lKaFQOSrgY8h8 yK+9sERRNSNdO5M/3WizFwYO/HRJuYmA6l5srJ6li37s3+e100BQVc7gnQYWYcGw ioNeDI73SWavj9On2UQXGdnEx4l8bwcpy9zm4eDoH52o2svcsxI+iairO3HTbUQd gsZjHjYcrEDDYAFSCyd6PYfjbswplLfgmFfr+yoF03NGBQsrykGhOFeElu8/Py/p tKACHC80S3Mf6xDVY9BVNSxhflfz4PcYpVjYLJ5PtKMJF/GcJUO1mtrfMZa2+p8= =4pwS -----END PGP SIGNATURE----- From maschoch at compuserve.com Thu Sep 23 15:49:00 2004 From: maschoch at compuserve.com (Martin Schoch) Date: Thu Sep 23 15:45:36 2004 Subject: GnuPG error message when connecting keyserver Message-ID: <0950403.20040923154900@compuserve.com> Hi list The setup is made that missing keys are searched on a keyserver: gpg.conf keyserver ldap://pgp.surfnet.nl:11370 keyserver-options auto-key-retrieve Could you please tell me what this error message means: Getting key(s) 0xCFED3275 from server ldap://pgp.surfnet.nl:11370 . . . gpgkeys: internal LDAP bind error: Nicht verf?gbar gpg: no valid OpenPGP data found. gpg: Total number processed: 0 Or is this keyserver down? BTW. Using GPG 1.2.5 under Windows 2000 SP4 -- Best regards, Martin Schoch maschoch@compuserve.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 331 bytes Desc: not available Url : /pipermail/attachments/20040923/6b5b0d31/attachment.bin From wk at gnupg.org Thu Sep 23 16:33:40 2004 From: wk at gnupg.org (Werner Koch) Date: Thu Sep 23 16:34:05 2004 Subject: Weaknesses in SHA-1, gnupg dev versions In-Reply-To: <4151D16B.5020502@gmx.de> (Thomas Schorpp's message of "Wed, 22 Sep 2004 21:24:27 +0200") References: <3.0.5.32.20040921215928.019c2000@popc.ipa.net> <20040922184538.GB29202@jabberwocky.com> <4151D16B.5020502@gmx.de> Message-ID: <87ekktrr5n.fsf@wheatstone.g10code.de> On Wed, 22 Sep 2004 21:24:27 +0200, Thomas Schorpp said: > i would like sha512 too for better protection of my passphrase(?). > sorry, i cant afford helping implementing crypto-algorithms in gnupg. The protection of your passphrase is limited by the length of the passphrase you are able to remember. A SHA-1 based key wrapping is more than sufficient. > stepping 1-3 was out and "problems" signing keys...? > ill not try cvs due to possible security hazard, since im doing "near > production" field tests with the openpgp testcard. There is not much difference between a release and the CVS version - a development release is merely easier to build and should not have obvious build problems. I have just commited a couple of changes to the card code. There are now commands to import a key and to create individual key on the card (--edit-key, addcardkey, keytocard). Main missing point is now a backup scheme for the encryption key. > if theres no official "security quality cycle" in this dev process, i > suggest cryptology specialists involved attacking my test key with > target "signature reproducal", etc. Sorry, I don't understand this. Werner From dshaw at jabberwocky.com Thu Sep 23 16:49:18 2004 From: dshaw at jabberwocky.com (David Shaw) Date: Thu Sep 23 16:46:08 2004 Subject: GnuPG error message when connecting keyserver In-Reply-To: <0950403.20040923154900@compuserve.com> References: <0950403.20040923154900@compuserve.com> Message-ID: <20040923144918.GA8114@jabberwocky.com> On Thu, Sep 23, 2004 at 03:49:00PM +0200, Martin Schoch wrote: > Hi list > > The setup is made that missing keys are searched on a keyserver: > > gpg.conf > > keyserver ldap://pgp.surfnet.nl:11370 > keyserver-options auto-key-retrieve > > Could you please tell me what this error message means: > > Getting key(s) 0xCFED3275 from server ldap://pgp.surfnet.nl:11370 . . . > > gpgkeys: internal LDAP bind error: Nicht verf?gbar > gpg: no valid OpenPGP data found. > gpg: Total number processed: 0 > > Or is this keyserver down? Yep. David From jharris at widomaker.com Thu Sep 23 19:52:36 2004 From: jharris at widomaker.com (Jason Harris) Date: Thu Sep 23 19:49:32 2004 Subject: GnuPG error message when connecting keyserver In-Reply-To: <20040923144918.GA8114@jabberwocky.com> References: <0950403.20040923154900@compuserve.com> <20040923144918.GA8114@jabberwocky.com> Message-ID: <20040923175235.GE1723@wilma.widomaker.com> On Thu, Sep 23, 2004 at 10:49:18AM -0400, David Shaw wrote: > On Thu, Sep 23, 2004 at 03:49:00PM +0200, Martin Schoch wrote: > > keyserver ldap://pgp.surfnet.nl:11370 > > Getting key(s) 0xCFED3275 from server ldap://pgp.surfnet.nl:11370 . . . > > > > gpgkeys: internal LDAP bind error: Nicht verf?gbar > > gpg: no valid OpenPGP data found. > > gpg: Total number processed: 0 > > > > Or is this keyserver down? > > Yep. ["No, Elvis isn't dead..." :)] This wasn't announced anywhere (that I'm aware of), unfortunately, but pgp.surfnet.nl now points to minsky.surfnet.nl, the site of the new SKS keyserver, instead of horowitz.surfnet.nl, the site of the well-known pks and LDAP keyservers. Also, everyone who uses/prefers LDAP, please make it a point to submit your keys to ldap://horowitz.surfnet.nl:11370, which is synchronized with other public keyservers. ldap://keyserver.pgp.com has not shared keys with other keyservers for a long time now. -- Jason Harris | NIC: JH329, PGP: This _is_ PGP-signed, isn't it? jharris@widomaker.com _|_ web: http://keyserver.kjsl.com/~jharris/ Got photons? (TM), (C) 2004 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : /pipermail/attachments/20040923/804edc87/attachment.bin From t.schorpp at gmx.de Fri Sep 24 12:54:51 2004 From: t.schorpp at gmx.de (Thomas Schorpp) Date: Fri Sep 24 12:52:27 2004 Subject: Weaknesses in SHA-1, gnupg dev versions In-Reply-To: <87ekktrr5n.fsf@wheatstone.g10code.de> References: <3.0.5.32.20040921215928.019c2000@popc.ipa.net> <20040922184538.GB29202@jabberwocky.com> <4151D16B.5020502@gmx.de> <87ekktrr5n.fsf@wheatstone.g10code.de> Message-ID: <4153FCFB.8060506@gmx.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Werner Koch wrote: | On Wed, 22 Sep 2004 21:24:27 +0200, Thomas Schorpp said: | | |>i would like sha512 too for better protection of my passphrase(?). |>sorry, i cant afford helping implementing crypto-algorithms in gnupg. | | | The protection of your passphrase is limited by the length of the | passphrase you are able to remember. A SHA-1 based key wrapping is | more than sufficient. hopefully. i personally use "cascaded" passphrase storage with scurity ranking, holding lower security ranking passwords within a gpg encrypted file protected by my many words unforgetable master phrase since 1996, meantime on a "secure" usb device with cryptochip. since ive got many "customers" here having the "forgot passswords problem" (even for simple unix root accs or smime mail certificates with ms-strong-crypto-provider), i suggest such a system. better ideas, comments, risk analysis? | | |>stepping 1-3 was out and "problems" signing keys...? |>ill not try cvs due to possible security hazard, since im doing "near |>production" field tests with the openpgp testcard. | | | There is not much difference between a release and the CVS version - | a development release is merely easier to build and should not have | obvious build problems. i see. | | I have just commited a couple of changes to the card code. There are | now commands to import a key and to create individual key on the card | (--edit-key, addcardkey, keytocard). Main missing point is now a | backup scheme for the encryption key. cool ;) any special testing scenarios/cases? | | |>if theres no official "security quality cycle" in this dev process, i |>suggest cryptology specialists involved attacking my test key with |>target "signature reproducal", etc. | | | Sorry, I don't understand this. i knew youd say that ;) but i cannot lecture such an experienced project lead like You on security sw lifecycle management and sw qm/qa since You know about. the question was, (regarding the ?gypten project): why not here, too? are classic oss projects maillists alone sufficient for gnupg and security software (oncoming) special requirements? | | Werner | | Tomm -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.6 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iQCVAwUBQVP8+Gqsze5HSzyoAQJSbQQA6OLjTIGFbAB3xFBneuLc06eYR0n6JG8f I+UWdHFaYyjw1NXJ4aWr5InVfAUHp9wqcyc1pd9DXkhaSLv1kB+yV06LodpnBI/A QqlBkOirzfYPxSNSKUcIxcWLgtqBbo/J2TV4XIFsTmzMlwk11lMQ28ZUdk91snhK H117xjrvoUg= =ncpc -----END PGP SIGNATURE----- From dshaw at jabberwocky.com Mon Sep 27 01:52:09 2004 From: dshaw at jabberwocky.com (David Shaw) Date: Mon Sep 27 01:48:58 2004 Subject: Weaknesses in SHA-1, gnupg dev versions In-Reply-To: <20040922184215.K344@willy_wonka> References: <3.0.5.32.20040921215928.019c2000@popc.ipa.net> <20040922184538.GB29202@jabberwocky.com> <4151D16B.5020502@gmx.de> <20040922184215.K344@willy_wonka> Message-ID: <20040926235209.GA31184@jabberwocky.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Sep 22, 2004 at 06:47:27PM -0400, Atom 'Smasher' wrote: > On Wed, 22 Sep 2004, Thomas Schorpp wrote: > > > i would like sha512 too for better protection of my passphrase(?). > > sorry, i cant afford helping implementing crypto-algorithms in gnupg. > =============== > > it may or may not be any better. > > --s2k-digest-algo > > of course that wil work with almost any hash other than SHA-512 ;) > > hhmmm... just noticed the (1.2.4) man page on that: > > --s2k-digest-algo name > Use name as the digest algorithm used to mangle the passphrases. > The default algorithm is SHA-1. This digest algorithm is also > used for conventional encryption if --digest-algo is not given. > > i'm not sure what that last sentence means here, but it's not in the 1.3.6 > man page. It means that in 1.2.x that --digest-algo is used for passphrase mangling when using --symmetric, but --s2k-digest-algo is used for other passphrase mangling. In 1.3.x, --s2k-digest-algo is used for all passphrase mangling. David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.90-cvs (GNU/Linux) iGoEARECACoFAkFXVikjGGh0dHA6Ly93d3cuamFiYmVyd29ja3kuY29tL2tleS5h c2MACgkQ4mZch0nhy8nsBACfejHYdgA1pr7KZ3ZZ7f+4WFLEb/UAoM2YHpPYObyL kGopYY4m0pMDwtVf =D+I2 -----END PGP SIGNATURE----- From am33 at 2wire.ch Thu Sep 23 00:56:31 2004 From: am33 at 2wire.ch (=?ISO-8859-1?Q?Thomas_Str=F6sslin?=) Date: Mon Sep 27 11:44:03 2004 Subject: gpgme compile problem (ld too old?) Message-ID: <4152031F.1010902@2wire.ch> Marcus Brinkmann wrote: > > > but if you can confirm that it works ok if > > > you remove the /* */ comment, then I will remove it from CVS, as it is > > > not really needed. > > > > Removing that comment works. > > Thanks a lot for trying that, I removed the comment from CVS. I don't know what you mean when you speak about those comments, they are not there anymore in version 0.4.3. However, compilation still failed with a "parse error in VERSION script" because a version string seems to be necessary in front of the opening brace: old (non working): { global: gpgme_*; local: *; }; new (working): VERS_0.4.3 { global: gpgme_*; local: *; }; -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20040923/3299b5ca/signature.bin From marcus.brinkmann at ruhr-uni-bochum.de Mon Sep 27 18:46:46 2004 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Mon Sep 27 18:46:24 2004 Subject: gpgme compile problem (ld too old?) In-Reply-To: <4152031F.1010902@2wire.ch> References: <4152031F.1010902@2wire.ch> Message-ID: <87y8ivaccp.wl@ulysses.g10code.de> At Thu, 23 Sep 2004 00:56:31 +0200, Thomas Str?sslin wrote: > > [1 ] > [1.1 ] > Marcus Brinkmann wrote: > > > > > but if you can confirm that it works ok if > > > > you remove the /* */ comment, then I will remove it from CVS, as > it is > > > > not really needed. > > > > > > Removing that comment works. > > > > Thanks a lot for trying that, I removed the comment from CVS. > > I don't know what you mean when you speak about those comments, they are Just that, I removed the C-style comment from the version script. > not there anymore in version 0.4.3. However, compilation still failed > with a "parse error in VERSION script" because a version string seems to > be necessary in front of the opening brace: That might be a too old ld, although I can't really tell. I have never really researched which versions of ld support which type of version scripts. Having a version string is very much different from having no version string at all (it's a completely different functionality), but in any case, it happens that we decided to use versioned symbols on targets that support them (currently only GNU). So, you should be ok with CVS, which will be released as 1.0 soon. Thanks, Marcus From cstork at ics.uci.edu Mon Sep 27 23:12:55 2004 From: cstork at ics.uci.edu (Christian Stork) Date: Wed Sep 29 10:52:58 2004 Subject: Authenticating TCP connections based on public keys Message-ID: <20040927211255.GB18121@anthony.ics.uci.edu> Hi, I have a potentially naive question so please forgive me if I missed an obvious answer or if this is not the appropriate list (at least I know it's not an FAQ): Assume I'm running a service for certain peers. My server knows the public keys of each peer. How can I use GPG (or any of its subprojects) to authenticate an incoming connection based on these public keys? Is there a standard for this case? (I'm interested in keeping the administrative overhead as low as possible, which is why extra SSL certificates etc. are out of question.) -Chris PS: Please cc me in your replies since I'm not subscribed to this list. -- Chris Stork <> Support eff.org! <> http://www.ics.uci.edu/~cstork/ OpenPGP fingerprint: B08B 602C C806 C492 D069 021E 41F3 8C8D 50F9 CA2F From alex at bofh.net.pl Wed Sep 29 12:36:04 2004 From: alex at bofh.net.pl (Janusz A. Urbanowicz) Date: Wed Sep 29 12:33:50 2004 Subject: Authenticating TCP connections based on public keys In-Reply-To: <20040927211255.GB18121@anthony.ics.uci.edu> References: <20040927211255.GB18121@anthony.ics.uci.edu> Message-ID: <20040929103603.GV19831@syjon.fantastyka.net> On Mon, Sep 27, 2004 at 02:12:55PM -0700, Christian Stork wrote: > Hi, > > I have a potentially naive question so please forgive me if I missed an > obvious answer or if this is not the appropriate list (at least I know > it's not an FAQ): > > Assume I'm running a service for certain peers. My server knows the > public keys of each peer. How can I use GPG (or any of its subprojects) > to authenticate an incoming connection based on these public keys? Is > there a standard for this case? > > (I'm interested in keeping the administrative overhead as low as > possible, which is why extra SSL certificates etc. are out of question.) You have to do key distribution in some way anyway (unless you want to use already distributed keys) so why don't use certs? SSL is the thing you want anyway. Or possibly SSH port tunneling. Or IPSec. SSL/TLS is still the main answer for question you asked. Alex -- 0x46399138 From cstork at ics.uci.edu Wed Sep 29 16:36:52 2004 From: cstork at ics.uci.edu (Christian Stork) Date: Wed Sep 29 16:43:13 2004 Subject: Authenticating TCP connections based on public keys In-Reply-To: <20040929103603.GV19831@syjon.fantastyka.net> References: <20040927211255.GB18121@anthony.ics.uci.edu> <20040929103603.GV19831@syjon.fantastyka.net> Message-ID: <20040929143652.GA513@anthony.ics.uci.edu> On Wed, Sep 29, 2004 at 12:36:04PM +0200, Janusz A. Urbanowicz wrote: > On Mon, Sep 27, 2004 at 02:12:55PM -0700, Christian Stork wrote: > > Hi, > > > > I have a potentially naive question so please forgive me if I missed an > > obvious answer or if this is not the appropriate list (at least I know > > it's not an FAQ): > > > > Assume I'm running a service for certain peers. My server knows the > > public keys of each peer. How can I use GPG (or any of its subprojects) > > to authenticate an incoming connection based on these public keys? Is > > there a standard for this case? > > > > (I'm interested in keeping the administrative overhead as low as > > possible, which is why extra SSL certificates etc. are out of question.) > > You have to do key distribution in some way anyway (unless you want to use > already distributed keys) so why don't use certs? SSL is the thing you want > anyway. Or possibly SSH port tunneling. Or IPSec. SSL/TLS is still the main > answer for question you asked. Well, as I said, the GPG keys are already in place and the certs aren't. Could I use GPG keys as certs? Or how about a nice challenge-responce protocol based on GPG keys? Anyway, thanks for you answer, Alex. -- Chris Stork <> Support eff.org! <> http://www.ics.uci.edu/~cstork/ OpenPGP fingerprint: B08B 602C C806 C492 D069 021E 41F3 8C8D 50F9 CA2F From gnupg-devel=gnupg.org at lists.palfrader.org Wed Sep 29 21:04:19 2004 From: gnupg-devel=gnupg.org at lists.palfrader.org (Peter Palfrader) Date: Wed Sep 29 21:00:55 2004 Subject: gpg --edit, delsigs and --no-tty Message-ID: <20040929190419.GA6293@opium.multi24.com> Hi, I want to remove certain signatures on uids using a script. When I call gpg --edit with --no-tty then I don't get any information about which signature is about to be removed: | $ gpg --no-tty --with-colons --status-fd=2 --command-fd=0 --edit c82e0039 | gpg (GnuPG) 1.2.5; Copyright (C) 2004 Free Software Foundation, Inc. [..] | pub:-:4096:1:62AF4031C82E0039:1048514712:0::-: | fpr:::::::::25FC1614B8F87B52FF2F99B962AF4031C82E0039: | uid:-::::::::Peter Palfrader:::S7 S3 S2 H2 H3 Z2 Z1,mdc:1,ps: | uid:-::::::::Peter Palfrader :::S7 S3 S2 H2 H3 Z2 Z1,mdc:2,: | [GNUPG:] GET_LINE keyedit.prompt | delsig | [GNUPG:] GOT_IT | [GNUPG:] GET_BOOL keyedit.delsig.unknown When there is a tty, I do get the information: | delsig | [GNUPG:] GOT_IT | uid Peter Palfrader | sig?3 2477CAF8 2003-07-13 | [GNUPG:] GET_BOOL keyedit.delsig.unknown It's not in colons, but it's still better than nothing. It would be great if that information wa also available in the --no-tty case. -- Peter From dshaw at jabberwocky.com Wed Sep 29 21:40:47 2004 From: dshaw at jabberwocky.com (David Shaw) Date: Wed Sep 29 21:37:29 2004 Subject: gpg --edit, delsigs and --no-tty In-Reply-To: <20040929190419.GA6293@opium.multi24.com> References: <20040929190419.GA6293@opium.multi24.com> Message-ID: <20040929194047.GC28944@jabberwocky.com> On Wed, Sep 29, 2004 at 09:04:19PM +0200, Peter Palfrader wrote: > When I call gpg --edit with --no-tty then I don't get any information > about which signature is about to be removed: Printing to a TTY despite the user specifying --no-tty would be a pretty unpleasant hack. This is fixed properly in 1.3.x, where delsig and --with-colons gives you the sig in colon form and the TTY is irrelevant. David From gnupg-devel=gnupg.org at lists.palfrader.org Wed Sep 29 21:54:32 2004 From: gnupg-devel=gnupg.org at lists.palfrader.org (Peter Palfrader) Date: Wed Sep 29 21:51:05 2004 Subject: gpg --edit, delsigs and --no-tty In-Reply-To: <20040929194047.GC28944@jabberwocky.com> References: <20040929190419.GA6293@opium.multi24.com> <20040929194047.GC28944@jabberwocky.com> Message-ID: <20040929195432.GC6293@opium.multi24.com> On Wed, 29 Sep 2004, David Shaw wrote: > On Wed, Sep 29, 2004 at 09:04:19PM +0200, Peter Palfrader wrote: > > > When I call gpg --edit with --no-tty then I don't get any information > > about which signature is about to be removed: > > Printing to a TTY despite the user specifying --no-tty would be a > pretty unpleasant hack. Well, of course I meant printing it to stdout, not the tty :) > This is fixed properly in 1.3.x, where delsig > and --with-colons gives you the sig in colon form and the TTY is > irrelevant. Cool. 1.3.6 doesn't do this yet, is there an ETA for the next 1.3.x release? -- Peter From marcus.brinkmann at ruhr-uni-bochum.de Thu Sep 30 18:07:54 2004 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Thu Sep 30 18:06:27 2004 Subject: [Announce] GPGME 1.0.0 released Message-ID: <87d603agf9.wl@ulysses.g10code.de> We are pleased to announce version 1.0.0 of GnuPG Made Easy, a library designed to make access to GnuPG easier for applications. It may be found in the file (about 791 KB compressed) ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.0.0.tar.gz The following files are also available: ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.0.0.tar.gz.sig ftp://ftp.gnupg.org/gcrypt/alpha/gpgme/gpgme-0.9.0-1.0.0.diff.gz It should soon appear on the mirrors listed at: http://www.gnupg.org/mirrors.html Bug reports and requests for assistance should be sent to: gnupg-devel@gnupg.org The md5sum checksums for this distibution are 6b6847d1fb58ee3ac613019a44a58a0e gpgme-0.9.0-1.0.0.diff.gz 1abf7accd905c435da567d0852c080af gpgme-1.0.0.tar.gz f489a46c0047a11e6563821fb22504e3 gpgme-1.0.0.tar.gz.sig Noteworthy changes in version 1.0.0 (2004-09-30) ------------------------------------------------ * Version 1.0.0! We are proud to present you with a thoroughly tested and stable version of the GPGME library. A big Thank You! to all the people who made this possible. The development will be branched into a stable 1.x.y series and the head. * The gpgme.m4 macro supports checking the API version. Just prepend it to the required version string, separated by a colon. For example, this release has the version "1:1.0.0". The last release to which this version is (mostly) ABI compatible is "1:0.4.2", which is the default required version. Marcus Brinkmann mb@g10code.de From jsogo at debian.org Thu Sep 30 19:13:15 2004 From: jsogo at debian.org (Jose Carlos Garcia Sogo) Date: Thu Sep 30 19:10:10 2004 Subject: Fails when compiling [WAS: Re: [Announce] GPGME 1.0.0 released] In-Reply-To: <87d603agf9.wl@ulysses.g10code.de> References: <87d603agf9.wl@ulysses.g10code.de> Message-ID: <1096564395.13868.3.camel@localhost> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente Url : /pipermail/attachments/20040930/4c772c45/attachment.bin From jharris at widomaker.com Thu Sep 30 20:05:04 2004 From: jharris at widomaker.com (Jason Harris) Date: Thu Sep 30 20:01:57 2004 Subject: [Sks-devel] another bounds problem in SKS In-Reply-To: <20040930142653.GO16153@parcelfarce.linux.theplanet.co.uk> References: <20040930001319.GA12699@wilma.widomaker.com> <891bd33904092919455fa9c784@mail.gmail.com> <20040930025800.GC32295@jabberwocky.com> <20040930110243.GL16153@parcelfarce.linux.theplanet.co.uk> <20040930121508.GB18394@jabberwocky.com> <20040930142653.GO16153@parcelfarce.linux.theplanet.co.uk> Message-ID: <20040930180503.GA14568@wilma.widomaker.com> On Thu, Sep 30, 2004 at 03:26:53PM +0100, Matthew Wilcox wrote: > On Thu, Sep 30, 2004 at 08:15:08AM -0400, David Shaw wrote: > > No, that looks like something else. The diff is a little mangled, > > since you have an error output from another packet in the middle of > > the signature packet output. > > It's not the diff that's mangled, it's the original output file. > There must be some buffering problem because the error goes to stderr > and the rest goes to stdout. I produced the log using: > > $ gpg -vv --recv-keys BCE09436 >fabien.log 2>&1 GPG must not be flushing stdout before writing to stderr, which should be unbuffered. -- Jason Harris | NIC: JH329, PGP: This _is_ PGP-signed, isn't it? jharris@widomaker.com _|_ web: http://keyserver.kjsl.com/~jharris/ Got photons? (TM), (C) 2004 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : /pipermail/attachments/20040930/0b14ba78/attachment.bin From dshaw at jabberwocky.com Thu Sep 30 20:16:36 2004 From: dshaw at jabberwocky.com (David Shaw) Date: Thu Sep 30 20:13:18 2004 Subject: [Sks-devel] another bounds problem in SKS In-Reply-To: <20040930180503.GA14568@wilma.widomaker.com> References: <20040930001319.GA12699@wilma.widomaker.com> <891bd33904092919455fa9c784@mail.gmail.com> <20040930025800.GC32295@jabberwocky.com> <20040930110243.GL16153@parcelfarce.linux.theplanet.co.uk> <20040930121508.GB18394@jabberwocky.com> <20040930142653.GO16153@parcelfarce.linux.theplanet.co.uk> <20040930180503.GA14568@wilma.widomaker.com> Message-ID: <20040930181636.GA21884@jabberwocky.com> On Thu, Sep 30, 2004 at 02:05:04PM -0400, Jason Harris wrote: > On Thu, Sep 30, 2004 at 03:26:53PM +0100, Matthew Wilcox wrote: > > On Thu, Sep 30, 2004 at 08:15:08AM -0400, David Shaw wrote: > > > > No, that looks like something else. The diff is a little mangled, > > > since you have an error output from another packet in the middle of > > > the signature packet output. > > > > It's not the diff that's mangled, it's the original output file. > > There must be some buffering problem because the error goes to stderr > > and the rest goes to stdout. I produced the log using: > > > > $ gpg -vv --recv-keys BCE09436 >fabien.log 2>&1 > > GPG must not be flushing stdout before writing to stderr, > which should be unbuffered. No, it does not flush stdout before writing to stderr. It shouldn't. They are two different outputs for a reason, and stderr must not be blocked because stdout is. David From marcus.brinkmann at ruhr-uni-bochum.de Thu Sep 30 23:22:47 2004 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Thu Sep 30 23:21:31 2004 Subject: Fails when compiling [WAS: Re: [Announce] GPGME 1.0.0 released] In-Reply-To: <1096564395.13868.3.camel@localhost> References: <87d603agf9.wl@ulysses.g10code.de> <1096564395.13868.3.camel@localhost> Message-ID: <87brfna1ug.wl@ulysses.g10code.de> At Thu, 30 Sep 2004 19:13:15 +0200, Jose Carlos Garcia Sogo wrote: > > We are pleased to announce version 1.0.0 of GnuPG Made Easy, > > Hi, when trying to compile it in Debian fails. Attached is the build > log. > > I'm not applying any patch (I have disabled 10_relibtoolize patch you > can find in 0.9.x versions), so it must be a problem in gpgme itself. Holy Bartholomeus, there is actually somebody compiling GPGME without GpgSM support! You'd think I would have thought of testing that before this major release, but we have worked hard on the Aegypten project recently, so that was all that was on my mind. I guess I have to thank you for this, but you are spoiling my party, grrr :) Ok, gpgme 1.0.1 should come soon. Marcus From marcus.brinkmann at ruhr-uni-bochum.de Thu Sep 30 23:57:55 2004 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Thu Sep 30 23:56:26 2004 Subject: Fails when compiling [WAS: Re: [Announce] GPGME 1.0.0 released] In-Reply-To: <1096564395.13868.3.camel@localhost> References: <87d603agf9.wl@ulysses.g10code.de> <1096564395.13868.3.camel@localhost> Message-ID: <87acv7a07w.wl@ulysses.g10code.de> At Thu, 30 Sep 2004 19:13:15 +0200, Jose Carlos Garcia Sogo wrote: > > [1 ] > [1.1 ] > [1.1.1 ] > El jue, 30-09-2004 a las 18:07 +0200, Marcus Brinkmann escribi?: > > We are pleased to announce version 1.0.0 of GnuPG Made Easy, > > Hi, when trying to compile it in Debian fails. Attached is the build > log. > > I'm not applying any patch (I have disabled 10_relibtoolize patch you > can find in 0.9.x versions), so it must be a problem in gpgme itself. Ok. Before I make myself a real fool by releasing a GPGME 1.0.1 that still doesn't work, can you test this patch, please? It fixes the problem for me. diff -u -r1.87 configure.ac --- configure.ac 30 Sep 2004 01:32:17 -0000 1.87 +++ configure.ac 30 Sep 2004 21:52:25 -0000 @@ -330,7 +330,7 @@ AC_DEFINE_UNQUOTED(GPGSM_PATH, "$GPGSM", [Path to the GPGSM binary.]) AC_SUBST(GPGSM) fi -AM_CONDITIONAL(HAVE_GPGSM, [test -n "$GPGSM"]) +AM_CONDITIONAL(HAVE_GPGSM, ["$GPGSM" != "no"]) dnl Check for GPGSM version requirement. GPGSM_VERSION=unknown ok=maybe Thanks, Marcus From marcus.brinkmann at ruhr-uni-bochum.de Thu Sep 30 18:07:54 2004 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Fri Oct 1 10:26:29 2004 Subject: [Announce] GPGME 1.0.0 released Message-ID: <87d603agf9.wl@ulysses.g10code.de> We are pleased to announce version 1.0.0 of GnuPG Made Easy, a library designed to make access to GnuPG easier for applications. It may be found in the file (about 791 KB compressed) ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.0.0.tar.gz The following files are also available: ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.0.0.tar.gz.sig ftp://ftp.gnupg.org/gcrypt/alpha/gpgme/gpgme-0.9.0-1.0.0.diff.gz It should soon appear on the mirrors listed at: http://www.gnupg.org/mirrors.html Bug reports and requests for assistance should be sent to: gnupg-devel@gnupg.org The md5sum checksums for this distibution are 6b6847d1fb58ee3ac613019a44a58a0e gpgme-0.9.0-1.0.0.diff.gz 1abf7accd905c435da567d0852c080af gpgme-1.0.0.tar.gz f489a46c0047a11e6563821fb22504e3 gpgme-1.0.0.tar.gz.sig Noteworthy changes in version 1.0.0 (2004-09-30) ------------------------------------------------ * Version 1.0.0! We are proud to present you with a thoroughly tested and stable version of the GPGME library. A big Thank You! to all the people who made this possible. The development will be branched into a stable 1.x.y series and the head. * The gpgme.m4 macro supports checking the API version. Just prepend it to the required version string, separated by a colon. For example, this release has the version "1:1.0.0". The last release to which this version is (mostly) ABI compatible is "1:0.4.2", which is the default required version. Marcus Brinkmann mb@g10code.de _______________________________________________ Gnupg-announce mailing list Gnupg-announce@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From marcus.brinkmann at ruhr-uni-bochum.de Thu Sep 30 18:07:54 2004 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Fri Oct 1 11:17:59 2004 Subject: [Announce] GPGME 1.0.0 released Message-ID: We are pleased to announce version 1.0.0 of GnuPG Made Easy, a library designed to make access to GnuPG easier for applications. It may be found in the file (about 791 KB compressed) ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.0.0.tar.gz The following files are also available: ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.0.0.tar.gz.sig ftp://ftp.gnupg.org/gcrypt/alpha/gpgme/gpgme-0.9.0-1.0.0.diff.gz It should soon appear on the mirrors listed at: http://www.gnupg.org/mirrors.html Bug reports and requests for assistance should be sent to: gnupg-devel@gnupg.org The md5sum checksums for this distibution are 6b6847d1fb58ee3ac613019a44a58a0e gpgme-0.9.0-1.0.0.diff.gz 1abf7accd905c435da567d0852c080af gpgme-1.0.0.tar.gz f489a46c0047a11e6563821fb22504e3 gpgme-1.0.0.tar.gz.sig Noteworthy changes in version 1.0.0 (2004-09-30) ------------------------------------------------ * Version 1.0.0! We are proud to present you with a thoroughly tested and stable version of the GPGME library. A big Thank You! to all the people who made this possible. The development will be branched into a stable 1.x.y series and the head. * The gpgme.m4 macro supports checking the API version. Just prepend it to the required version string, separated by a colon. For example, this release has the version "1:1.0.0". The last release to which this version is (mostly) ABI compatible is "1:0.4.2", which is the default required version. Marcus Brinkmann mb@g10code.de _______________________________________________ Gnupg-announce mailing list Gnupg-announce@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From marcus.brinkmann at ruhr-uni-bochum.de Thu Sep 30 18:07:54 2004 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Fri Oct 1 11:19:59 2004 Subject: [Announce] GPGME 1.0.0 released Message-ID: <87d603agf9.wl@ulysses.g10code.de> We are pleased to announce version 1.0.0 of GnuPG Made Easy, a library designed to make access to GnuPG easier for applications. It may be found in the file (about 791 KB compressed) ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.0.0.tar.gz The following files are also available: ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.0.0.tar.gz.sig ftp://ftp.gnupg.org/gcrypt/alpha/gpgme/gpgme-0.9.0-1.0.0.diff.gz It should soon appear on the mirrors listed at: http://www.gnupg.org/mirrors.html Bug reports and requests for assistance should be sent to: gnupg-devel@gnupg.org The md5sum checksums for this distibution are 6b6847d1fb58ee3ac613019a44a58a0e gpgme-0.9.0-1.0.0.diff.gz 1abf7accd905c435da567d0852c080af gpgme-1.0.0.tar.gz f489a46c0047a11e6563821fb22504e3 gpgme-1.0.0.tar.gz.sig Noteworthy changes in version 1.0.0 (2004-09-30) ------------------------------------------------ * Version 1.0.0! We are proud to present you with a thoroughly tested and stable version of the GPGME library. A big Thank You! to all the people who made this possible. The development will be branched into a stable 1.x.y series and the head. * The gpgme.m4 macro supports checking the API version. Just prepend it to the required version string, separated by a colon. For example, this release has the version "1:1.0.0". The last release to which this version is (mostly) ABI compatible is "1:0.4.2", which is the default required version. Marcus Brinkmann mb@g10code.de _______________________________________________ Gnupg-announce mailing list Gnupg-announce@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce