From Brian.Cameron at Sun.COM Thu May 1 22:53:21 2008 From: Brian.Cameron at Sun.COM (Brian Cameron) Date: Thu, 01 May 2008 15:53:21 -0500 Subject: Problem building libgcrypt on Solaris Message-ID: <481A2DC1.8020404@sun.com> libgcrypt team: The latest libgcrypt version 1.4.0 will not build on Solaris with the Sun Studio compiler because it includes some void functions that return values, which the Sun Studio compiler considers an error. Obviously GCC lets this go. I'm attaching a patch to fix this problem. Can this go upstream? Thanks, Brian -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: libgcrypt-01-fixvoid.diff URL: From mooney at dogbert.cc.ndsu.NoDak.edu Fri May 2 18:59:37 2008 From: mooney at dogbert.cc.ndsu.NoDak.edu (Tim Mooney) Date: Fri, 2 May 2008 11:59:37 -0500 (CDT) Subject: Problem building libgcrypt on Solaris In-Reply-To: <481A2DC1.8020404@sun.com> References: <481A2DC1.8020404@sun.com> Message-ID: In regard to: Problem building libgcrypt on Solaris, Brian Cameron said (at...: > The latest libgcrypt version 1.4.0 will not build on Solaris with the > Sun Studio compiler because it includes some void functions that > return values, which the Sun Studio compiler considers an error. > Obviously GCC lets this go. > > I'm attaching a patch to fix this problem. Can this go upstream? I reported it a while back, and it is fixed in libgcrypt 1.4.1, which was released a few days ago. Tim -- Tim Mooney mooney at dogbert.cc.ndsu.NoDak.edu Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 From knoch at searshc.com Thu May 8 22:27:04 2008 From: knoch at searshc.com (Noch, Keith) Date: Thu, 8 May 2008 16:27:04 -0400 Subject: Is there a version for aix5.2? Message-ID: <33FEEE6E2ADCE94A81CF34CB79DB5E9AEC6176@USKIHSVPEXCH19.kih.kmart.com> Hello, I am very unfamiliar with this product and I need to know if there is a version for aix5.2? Thanks for any help. -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian at jaeger.mine.nu Tue May 13 02:53:26 2008 From: christian at jaeger.mine.nu (Christian Jaeger) Date: Tue, 13 May 2008 02:53:26 +0200 Subject: [PATCH] In the manpage, mention at the --sign options how to select the signing key Message-ID: <385d35c928e409bc8a361b33e963e293@jaeger.mine.nu> Hello I've got several private keys. Although I'm a long time (but not frequent) gpg user now, I still find a few things in the user interface a bit confusing; today I've searched the man page in vain trying to find out how to specify which private key to use for signing. Someone helped me point it out on the IRC channel; I didn't find it at first since I was searching the manpage for strings like sign.*key and similar. So I propose to add this to the place where I was expecting to find it, at the sign options themselves. This patch is against current svn://cvs.gnupg.org/gnupg/trunk gnupg, that seems to be gnupg2, but I'm actually using gnupg version 1 (version 1.4.6 from Debian testing), but both of the man pages need the same fix, so I suggest to apply the patch to both versions. Thanks, Christian. (ps. this is from git-format-patch out of a git-svn clone of the svn repository; I'm hoping you're not having problems applying it using the svn tools (or patch)?) --- doc/gpg.texi | 7 +++++-- 1 files changed, 5 insertions(+), 2 deletions(-) diff --git a/doc/gpg.texi b/doc/gpg.texi index a122691..a4dbd9c 100644 --- a/doc/gpg.texi +++ b/doc/gpg.texi @@ -178,7 +178,9 @@ Make a signature. This command may be combined with @option{--encrypt} (for a signed and encrypted message), @option{--symmetric} (for a signed and symmetrically encrypted message), or @option{--encrypt} and @option{--symmetric} together (for a signed message that may be -decrypted via a secret key or a passphrase). +decrypted via a secret key or a passphrase). For changing the private +key to be used for signing, see the --local-user and --default-key +options. @item --clearsign @opindex clearsign @@ -186,7 +188,8 @@ Make a clear text signature. The content in a clear text signature is readable without any special software. OpenPGP software is only needed to verify the signature. Clear text signatures may modify end-of-line whitespace for platform independence and are not intended -to be reversible. +to be reversible. For changing the private key to be used for signing, +see the --local-user and --default-key options. @item --detach-sign @itemx -b -- 1.5.5.1 From cswiger at mac.com Tue May 13 19:13:35 2008 From: cswiger at mac.com (Chuck Swiger) Date: Tue, 13 May 2008 10:13:35 -0700 Subject: gnupg-2.0.9: bug in certchain.c... Message-ID: <7A45720B-A2A5-487A-AC58-09D2BC5843D8@mac.com> Hi, all-- In gnupg-2.0.9, a local variable is being declared after a statement in a block rather than at the start, resulting in: > [ ... ] > source='certchain.c' object='certchain.o' libtool=no \ > DEPDIR=.deps depmode=gcc /bin/sh ../scripts/depcomp \ > cc -DHAVE_CONFIG_H -I. -I.. -I../gl -I../common -I../intl - > DLOCALEDIR=\"/usr/local/share/locale\" -DGNUPG_BINDIR="\"/usr/local/ > bin\"" -DGNUPG_LIBEXECDIR="\"/usr/local/libexec\"" - > DGNUPG_LIBDIR="\"/usr/local/lib/gnupg\"" -DGNUPG_DATADIR="\"/usr/ > local/share/gnupg\"" -DGNUPG_SYSCONFDIR="\"/usr/local/etc/gnupg > \"" -I/usr/local/include -I/usr/local/include -I/usr/local/ > include -I/usr/local/include -O -pipe -march=pentium -Wall - > Wpointer-arith -c certchain.c > certchain.c: In function `find_up': > certchain.c:710: syntax error before `int' > certchain.c:711: `old' undeclared (first use in this function) > certchain.c:711: (Each undeclared identifier is reported only once > certchain.c:711: for each function it appears in.) A diff to fix this bug follows: --- gnupg-2.0.9/sm/certchain.c~ Mon Feb 18 13:51:54 2008 +++ gnupg-2.0.9/sm/certchain.c Tue May 13 13:00:36 2008 @@ -702,12 +702,13 @@ rc = keydb_search_subject (kh, issuer); if (rc == -1 && !find_next) { + int old; /* Also try to get it from the Dirmngr cache. The function merely puts it into the ephemeral database. */ find_up_dirmngr (ctrl, kh, NULL, issuer, 0); /* Not found, let us see whether we have one in the ephemeral key DB. */ - int old = keydb_set_ephemeral (kh, 1); + old = keydb_set_ephemeral (kh, 1); if (!old) { keydb_search_reset (kh); Regards, -- -Chuck From marcus.brinkmann at ruhr-uni-bochum.de Thu May 15 12:34:59 2008 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Thu, 15 May 2008 12:34:59 +0200 Subject: [PATCH] In the manpage, mention at the --sign options how to select the signing key In-Reply-To: <385d35c928e409bc8a361b33e963e293@jaeger.mine.nu> References: <385d35c928e409bc8a361b33e963e293@jaeger.mine.nu> Message-ID: <87wslvua7g.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Tue, 13 May 2008 02:53:26 +0200, Christian Jaeger wrote: > I've got several private keys. Although I'm a long time (but not > frequent) gpg user now, I still find a few things in the user > interface a bit confusing; today I've searched the man page in vain > trying to find out how to specify which private key to use for > signing. Someone helped me point it out on the IRC channel; I didn't > find it at first since I was searching the manpage for strings like > sign.*key and similar. So I propose to add this to the place where I > was expecting to find it, at the sign options themselves. I agree, so I put in the change with a slightly different wording and added the expected formatting for the option strings. > (ps. this is from git-format-patch out of a git-svn clone of the svn > repository; I'm hoping you're not having problems applying it using > the svn tools (or patch)?) I do. diff complained about ambiguous ending of the second hunk. Thanks, Marcus 2008-05-15 Marcus Brinkmann * gpg.texi (Operational GPG Commands): Mention the way to change the default signing key. From marcus.brinkmann at ruhr-uni-bochum.de Thu May 15 12:37:48 2008 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Thu, 15 May 2008 12:37:48 +0200 Subject: gnupg-2.0.9: bug in certchain.c... In-Reply-To: <7A45720B-A2A5-487A-AC58-09D2BC5843D8@mac.com> References: <7A45720B-A2A5-487A-AC58-09D2BC5843D8@mac.com> Message-ID: <87ve1fua2r.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Tue, 13 May 2008 10:13:35 -0700, Chuck Swiger wrote: > > Hi, all-- > > In gnupg-2.0.9, a local variable is being declared after a statement > in a block rather than at the start, resulting in: Thank you for reporting this. It was already reported and fixed by the following change in SVN: 2008-04-23 Werner Koch * certchain.c (find_up): Make correct C89 code. Declare variable at the top of the block. Reported by Alain Guibert. Thanks, Marcus From marcus.brinkmann at ruhr-uni-bochum.de Thu May 15 13:20:05 2008 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Thu, 15 May 2008 13:20:05 +0200 Subject: Vs Combined Method? E+S from RFC 3156 6.2 In-Reply-To: <200804291414.53915.bernhard@intevation.de> References: <200804291414.53915.bernhard@intevation.de> Message-ID: <87tzgzu84a.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Tue, 29 Apr 2008 14:14:45 +0200, Bernhard Reiter wrote: > Given the enhanced compatibility, why not do combined method whenever you can, > just getting the compatibility advantage? Compatibility with what? If every mail reader today supports MIME, there is no advantage in not using it. It would be more compatible to have passwords with only uppercase characters, but luckily those terminals have died out. However, it is still advisable to restrict passwords to 7 bit. There are always such battles fought out. A GNOME terminal is 80 characters wide by default, for compatibility with IBM punch cards, and I am actually annoyed if I have to read code or documents that don't fit on punch cards. But, luckily, that ain't need to be so for everything. Some things can move on. So, the question is, are there significant MUAs that support only combined mode? Thanks, Marcus From bernhard at intevation.de Thu May 15 14:16:09 2008 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 15 May 2008 14:16:09 +0200 Subject: Vs Combined Method? E+S from RFC 3156 6.2 In-Reply-To: <87tzgzu84a.wl%marcus.brinkmann@ruhr-uni-bochum.de> References: <200804291414.53915.bernhard@intevation.de> <87tzgzu84a.wl%marcus.brinkmann@ruhr-uni-bochum.de> Message-ID: <200805151416.14925.bernhard@intevation.de> Hi Marcus, On Thursday 15 May 2008 13:20, Marcus Brinkmann wrote: > At Tue, 29 Apr 2008 14:14:45 +0200, > > Bernhard Reiter wrote: > > Given the enhanced compatibility, why not do combined method whenever you > > can, just getting the compatibility advantage? > > Compatibility with what? The RFC from August 2001 says "to increase compatibility with non-MIME implementations of OpenPGP". > If every mail reader today supports MIME, > there is no advantage in not using it. ? Also they all MUST support the combined method. So even if there is a tiny small number of MUA out there that still cannot do MIME based OpenPGP, why break compatibility with them? >?Some things can move on. Sure, so you are basically saying: The argument from 2001 is obsolete. On the other hand, to ease the implementation, shouldn't we then push for the removal of the combined method requirement? At least make it mandadory in new implementation to not create new combined method emails? > So, the question is, are there significant MUAs that support only > combined mode? As for non-MIME MUAs, I think Outlook is significant. (Being one of the developers of Gpg4win, you know that until recently it could not do MIME OpenPGP. And that Outlook itself it not fully MIME compliant, e.g. it does not display the text part of a multipart/signed email, though it MUST according to MIME standards.) There will be others out there as well, e.g. on older unix machines which did not update software very often. Best, Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: