From wk at gnupg.org Wed Nov 1 00:22:22 2006 From: wk at gnupg.org (Werner Koch) Date: Wed Nov 1 00:25:24 2006 Subject: Logo contest closed Message-ID: <873b94t6j5.fsf@wheatstone.g10code.de> Hi, we have received 28 submissions to the logo contest. It is now up to the folks listed as GnuPG authors in AUTHORS to decide. I will mail them later the day. If you are interested in the submissions, please check out http://logo-contest.gnupg.org . Note: If you submitted a logo and your name does not appear in the list, please let me know. I had to fish quite some submissions out of my spam folder so there is a slight chance that one got lost. Salam-Shalom, Werner From kazu at iij.ad.jp Wed Nov 1 03:13:50 2006 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Wed Nov 1 03:13:14 2006 Subject: version Message-ID: <20061101.111350.05403970.kazu@iij.ad.jp> Hello, I have not tested GnuPG 1.9.94 yet but GnuPG 1.9.93 does not show "Supported algorithms:" when the --version option is specified. Just in case. P.S. GnuPG 1.9.93 can handle verisign certificates very well. Many thanks! --Kazu From wk at gnupg.org Wed Nov 1 12:32:22 2006 From: wk at gnupg.org (Werner Koch) Date: Wed Nov 1 12:36:59 2006 Subject: version In-Reply-To: <20061101.111350.05403970.kazu@iij.ad.jp> (Kazu Yamamoto's message of "Wed\, 01 Nov 2006 11\:13\:50 +0900 \(JST\)") References: <20061101.111350.05403970.kazu@iij.ad.jp> Message-ID: <87u01jv1vd.fsf@wheatstone.g10code.de> On Wed, 1 Nov 2006 03:13, Kazu Yamamoto (????) said: > I have not tested GnuPG 1.9.94 yet but GnuPG 1.9.93 does not show > "Supported algorithms:" when the --version option is specified. > Just in case. I know. The list of supported algorithms is in fact not very long. The problem are more due to teh OIDs. We could write, it supprts 3DES but there might still be OIDs for 3DES out which we don't know about. Salam-Shalom, Werner From alon.barlev at gmail.com Wed Nov 1 18:25:15 2006 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Wed Nov 1 19:17:35 2006 Subject: Some build fixes Message-ID: <200611011925.15879.alon.barlev@gmail.com> Hello Werner, I don't know if you are aware of these patches that are being used by Gentoo. fbsd - allow compilation under... make - solves parallel make issue. pic - check macro __PIC__ instead of PIC (gcc uses __PIC__) Also for libgcrypt at mpi/config.links, the test for powerpc64*-*-* will never be reached since there is powerpc*-*-linux* before. Best Regards, Alon Bar-Lev. -------------- next part -------------- A non-text attachment was scrubbed... Name: gnupg-1.9.94-fbsd.patch Type: text/x-diff Size: 926 bytes Desc: not available Url : /pipermail/attachments/20061101/43b11ac8/gnupg-1.9.94-fbsd.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: gnupg-1.9.94-make.patch Type: text/x-diff Size: 526 bytes Desc: not available Url : /pipermail/attachments/20061101/43b11ac8/gnupg-1.9.94-make.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: gnupg-1.9.94-pic.patch Type: text/x-diff Size: 1286 bytes Desc: not available Url : /pipermail/attachments/20061101/43b11ac8/gnupg-1.9.94-pic.bin From huehn-ml at arcor.de Thu Nov 2 07:38:39 2006 From: huehn-ml at arcor.de (Thomas =?utf-8?b?SMO8aG4=?=) Date: Thu Nov 2 08:08:07 2006 Subject: documentation in texi format Message-ID: Hi How do I generate HTML, plain text or PDF from gpg.texi in the doc subdirectory of gnupg-1.9.92? I don't want to build the software, just read the documentation. I thought, makeinfo or texi2html or texi2dvi should be the answer, but none of these work. makeinfo gives me (this is from a Windows version, but I see the same problems under Fedora Core 6): makeinfo (GNU texinfo) 4.8 Making info file `gpg.info' from `gpg.texi'. Formatting node Invoking GPG... gpg.texi:42: Unknown command `manpage'. gpg.texi:48: Unknown command `mansect'. gpg.texi:62: Unknown command `mansect'. gpg.texi:85: Unknown command `manpause'. gpg.texi:92: Unknown command `mancont'. gpg.texi:112: Unknown command `mansect'. Formatting node GPG Commands... Formatting node General GPG Commands... gpg.texi:144: Unknown command `gnupgtabopt'. gpg.texi:144: Misplaced {. gpg.texi:144: Misplaced }. [...] Too many errors! Gave up. Aree the texi files to be pre-processed by some tool? Am I misunderstanding something completely and these aren't Texinfo files? It works with the documentation of gnupg-1.4.0, though. Thomas From pgut001 at cs.auckland.ac.nz Thu Nov 2 10:58:52 2006 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Thu Nov 2 12:54:34 2006 Subject: GPG's S2K iteration count Message-ID: I've been sent a test keyring from a user with the following password- processing characteristics: Iterated and salted string-to-key(s2k 3): Hash alg - SHA1(hash 2) Salt - fa f8 53 61 9f 7c 90 b1 Count - 8388608(coded count 208) Is there any reason why GPG uses 8 million iterations of hashing for key setup? This is a recent change to the source: if( s2k->mode == 3 ) - s2k->count = 96; /* 65536 iterations */ + s2k->count = 208; /* 8388608 byte count */ and seems like a completely excessive value, it's going to cause problems on less-powerful clients. I think this came from loop-aes (where you only need to enter the password once when mounting the FS), but why is it now in GPG (particularly since Werner seemed to be against it when it was originally proposed)? Peter. From dshaw at jabberwocky.com Thu Nov 2 14:54:50 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Thu Nov 2 14:52:58 2006 Subject: GPG's S2K iteration count In-Reply-To: References: Message-ID: <20061102135450.GA2643@jabberwocky.com> On Thu, Nov 02, 2006 at 10:58:52PM +1300, Peter Gutmann wrote: > I've been sent a test keyring from a user with the following password- > processing characteristics: > > Iterated and salted string-to-key(s2k 3): > Hash alg - SHA1(hash 2) > Salt - fa f8 53 61 9f 7c 90 b1 > Count - 8388608(coded count 208) > > Is there any reason why GPG uses 8 million iterations of hashing for key > setup? This is a recent change to the source: > > if( s2k->mode == 3 ) > - s2k->count = 96; /* 65536 iterations */ > + s2k->count = 208; /* 8388608 byte count */ > > and seems like a completely excessive value, it's going to cause problems on > less-powerful clients. I think this came from loop-aes (where you only need > to enter the password once when mounting the FS), but why is it now in GPG > (particularly since Werner seemed to be against it when it was originally > proposed)? That change is in loop-AES, but so far as I can tell is not present in in GnuPG, in either the 1.4 or 1.9 branches of the code. The only change to the S2K count in years was a few weeks ago when I added the --s2k-count option to allow people to set different values. The default, however, is still 65536. David From wk at gnupg.org Thu Nov 2 17:02:57 2006 From: wk at gnupg.org (Werner Koch) Date: Thu Nov 2 17:06:55 2006 Subject: documentation in texi format In-Reply-To: (Thomas =?utf-8?Q?H?= =?utf-8?Q?=C3=BChn's?= message of "Thu\, 2 Nov 2006 06\:38\:39 +0000 \(UTC\)") References: Message-ID: <87odrpsuoe.fsf@wheatstone.g10code.de> On Thu, 2 Nov 2006 07:38, Thomas H?hn said: > How do I generate HTML, plain text or PDF from gpg.texi in the doc subdirectory > of gnupg-1.9.92? I don't want to build the software, just read the documentation. $ make gnupg.pdf gnupg.html > Making info file `gpg.info' from `gpg.texi'. If you want to do it from individual parts, you need to write a short top level file. > gpg.texi:42: Unknown command `manpage'. > gpg.texi:48: Unknown command `mansect'. @c A couple of macros with no effect on texinfo @c but used by the yat2m processor. @macro manpage {a} @end macro @macro mansect {a} @end macro @macro manpause @end macro @macro mancont @end macro > Aree the texi files to be pre-processed by some tool? Am I misunderstanding No, it is just that there are things missing. > It works with the documentation of gnupg-1.4.0, though. Tehre we build texinfo from SGML. This has changed in 1.9, where we use textinfo as the source. 1.4.6 will also use Texinfo as the source (in fact using the same same source as 1.9 just with some defines). Shalom-Salam, Werner From huehn-ml at arcor.de Thu Nov 2 20:27:52 2006 From: huehn-ml at arcor.de (Thomas =?utf-8?b?SMO8aG4=?=) Date: Thu Nov 2 20:50:47 2006 Subject: documentation in texi format References: <87odrpsuoe.fsf@wheatstone.g10code.de> Message-ID: Werner Koch gnupg.org> writes: > $ make gnupg.pdf gnupg.html Okay, but I need at least a successful configure run for that (to get the Makefile), right? I wanted to avoid that. > > Making info file `gpg.info' from `gpg.texi'. > > If you want to do it from individual parts, you need to write a short > top level file. > > > gpg.texi:42: Unknown command `manpage'. > > gpg.texi:48: Unknown command `mansect'. > > c A couple of macros with no effect on texinfo > c but used by the yat2m processor. > macro manpage {a} > end macro > macro mansect {a} > end macro > macro manpause > end macro > macro mancont > end macro Ah, I saw those lines in the yat2m file, pasted them to the top of gnupg.texi and had no luck. I don't know anything about Texinfo, so I thought that might work. :-) So now I try it under Linux. I have installed all the dependencies (libassuan et al) successfully (make check gives no errors). And I got the documentation now. Thanks for helping out. Thomas From wk at gnupg.org Fri Nov 3 10:49:13 2006 From: wk at gnupg.org (Werner Koch) Date: Fri Nov 3 10:52:15 2006 Subject: documentation in texi format In-Reply-To: (Thomas =?utf-8?Q?H?= =?utf-8?Q?=C3=BChn's?= message of "Thu\, 2 Nov 2006 19\:27\:52 +0000 \(UTC\)") References: <87odrpsuoe.fsf@wheatstone.g10code.de> Message-ID: <87ejskoo6e.fsf@wheatstone.g10code.de> On Thu, 2 Nov 2006 20:27, Thomas H?hn said: > Okay, but I need at least a successful configure run for that (to get the > Makefile), right? I wanted to avoid that. Yes. Salam-Shalom, Werner From wk at gnupg.org Fri Nov 3 11:24:42 2006 From: wk at gnupg.org (Werner Koch) Date: Fri Nov 3 11:27:00 2006 Subject: [PATCH] fix a typo when building libgcrypt and gnupg 1.4 with mingw-runtime 3.10 In-Reply-To: <20061102211700.0933ba9b@zod> (=?utf-8?Q?Rafa=C3=ABl_Carr?= =?utf-8?Q?=C3=A9's?= message of "Thu\, 2 Nov 2006 21\:17\:00 +0100") References: <20061102211700.0933ba9b@zod> Message-ID: <87ac38omj9.fsf@wheatstone.g10code.de> On Thu, 2 Nov 2006 21:17, Rafa?l Carr? said: > Please replace by because this is an > annoying typo. Done in my working copy of gnupg 1.4 and libgcrypt trunk. Thanks, Werner From wk at gnupg.org Fri Nov 3 16:46:54 2006 From: wk at gnupg.org (Werner Koch) Date: Fri Nov 3 16:51:56 2006 Subject: Some build fixes In-Reply-To: <200611011925.15879.alon.barlev@gmail.com> (Alon Bar-Lev's message of "Wed\, 1 Nov 2006 19\:25\:15 +0200") References: <200611011925.15879.alon.barlev@gmail.com> Message-ID: <873b90jzwx.fsf@wheatstone.g10code.de> On Wed, 1 Nov 2006 18:25, Alon Bar-Lev said: > I don't know if you are aware of these patches that are being used by > Gentoo. Not really. > fbsd - allow compilation under... Applied. However, I don't understand why gentoo needs this symcryptrun thing. I is too special for almost everyone. > make - solves parallel make issue. Indeed. > pic - check macro __PIC__ instead of PIC (gcc uses __PIC__) I don't understand this one. However, I can't fix it becuase it is a gettext issue. Please report it to gettext. The included gettext might not be the newest one but in general the system provided gettext will be used anyway. > Also for libgcrypt at mpi/config.links, the test for powerpc64*-*-* > will never be reached since there is powerpc*-*-linux* before. Already fixed over there in the SVN. Thanks, Werner From robbat2 at gentoo.org Fri Nov 3 21:34:25 2006 From: robbat2 at gentoo.org (Robin H. Johnson) Date: Fri Nov 3 21:32:26 2006 Subject: Some build fixes In-Reply-To: <873b90jzwx.fsf@wheatstone.g10code.de> References: <200611011925.15879.alon.barlev@gmail.com> <873b90jzwx.fsf@wheatstone.g10code.de> Message-ID: <20061103203425.GC15897@curie-int.orbis-terrarum.net> On Fri, Nov 03, 2006 at 04:46:54PM +0100, Werner Koch wrote: > > I don't know if you are aware of these patches that are being used by > > Gentoo. > Not really. The fbsd one I posted on -user earlier in the week. > > fbsd - allow compilation under... > Applied. However, I don't understand why gentoo needs this > symcryptrun thing. I is too special for almost everyone. The patch was from our Gentoo/FreeBSD folks, IIRC because blinding using '#include ' lead to compile failures. One of the Gentoo development practices is to try and make patches that are generally applicable, and not just applied for certain cases (eg no custom patch that's only applied on ppc). -- Robin Hugh Johnson E-Mail : robbat2@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available Url : /pipermail/attachments/20061103/96ff9ce3/attachment.pgp From wk at gnupg.org Mon Nov 6 11:20:09 2006 From: wk at gnupg.org (Werner Koch) Date: Mon Nov 6 11:22:57 2006 Subject: GnuPG 1.9.95 released Message-ID: <87ac34op0m.fsf@wheatstone.g10code.de> Hi, I have just released version 1.9.95 of GnuPG. This one fixes some build problems and is expected to be the last release before 2.0.0. Thanks to Nilg?n Belma Bug?ner for providing the first complete translation (tr). Available at the usual place: ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.9.95.tar.bz2 (3780k) ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.9.95.tar.bz2.sig or as a patch (without PO file updates): ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.9.94-1.9.95.diff.bz2 (10k) Shalom-Salam, Werner -- Werner Koch The GnuPG Experts http://g10code.com Join the Fellowship and protect your Freedom! http://www.fsfe.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available Url : /pipermail/attachments/20061106/ecc2f5eb/attachment.pgp From umq.461 at gmail.com Tue Nov 7 03:01:15 2006 From: umq.461 at gmail.com (Hirohisa Yamaguchi) Date: Tue Nov 7 02:59:28 2006 Subject: GnuPG 1.9.95: gpg2 segfaults on build test References: <87ac34op0m.fsf@wheatstone.g10code.de> Message-ID: <861wogc8wk.wl%umq@ueo.co.jp> Hi In my FreeBSD/amd64 box, gpg2 build test fails with a SIGSEGV. It seems like the same problem as the one reported in last month. # http://lists.gnupg.org/pipermail/gnupg-devel/2006-October/023253.html I attached gdb backtrace below. Any suggestions?. -- Hirohisa Yamaguchi umq.461@gmail.com Configure Environment: CFLAGS="-g -O2 -fno-strict-aliasing -pipe -march=athlon64 -I/usr/local/include/pth" LDFLAGS=" -L/usr/local/lib/pth" SHELL=/bin/sh CONFIG_SHELL=/bin/sh PORTOBJFORMAT=elf MAKE=gmake lt_cv_sys_max_cmd_len=262144 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... (gdb) b parse-packet.c:1958 Breakpoint 1 at 0x424020: file parse-packet.c, line 1958. (gdb) r -v -v --homedir . --quiet --yes --no-permission-warning --import ./pubdemo.asc Starting program: /usr/ports/security/gnupg-devel/work/gnupg-1.9.95/g10/gpg2 -v -v --homedir . --quiet --yes --no-permission-warning --import ./pubdemo.asc Breakpoint 1, parse_key (inp=0x8016701a0, pkttype=6, pktlen=412, hdr=0x7fffffffe0d0 "\004", hdrlen=3, pkt=0x801604180) at parse-packet.c:1958 1958 n = pktlen; pk->pkey[i] = mpi_read(inp, &n, 0 ); pktlen -=n; (gdb) p pk $1 = (PKT_public_key *) 0x8016901a0 (gdb) p &pk->pkey[i] $2 = (gcry_mpi_t *) 0x801690228 (gdb) n Program received signal SIGSEGV, Segmentation fault. 0x000000000042403b in parse_key (inp=0x8016701a0, pkttype=0, pktlen=412, hdr=0x8012de040 "$=}\224", hdrlen=3, pkt=0x801604180) at parse-packet.c:1958 1958 n = pktlen; pk->pkey[i] = mpi_read(inp, &n, 0 ); pktlen -=n; (gdb) p pk $3 = (PKT_public_key *) 0x800000000 (gdb) p &pk->pkey[i] $4 = (gcry_mpi_t *) 0x800000088 (gdb) bt full #0 0x000000000042403b in parse_key (inp=0x8016701a0, pkttype=0, pktlen=412, hdr=0x8012de040 "$=}\224", hdrlen=3, pkt=0x801604180) at parse-packet.c:1958 pk = (PKT_public_key *) 0x800000000 i = 0 version = 0 algorithm = 0 n = 130 timestamp = 4 expiredate = 0 max_expiredate = 0 npkey = 4 nskey = 5 is_v4 = 1 rc = 0 #1 0x0000000000425f74 in parse (inp=0x8016701a0, pkt=0x801604180, onlykeypkts=0, retpos=0x2, skip=0x7fffffffe2e4, out=0x0, do_skip=0, dbg_w=0x47a4f8 "parse", dbg_f=0x801608160 "\020", dbg_l=23101792) at parse-packet.c:535 rc = 2 c = 19783744 ctb = -7876 pkttype = 6 lenbytes = 2 pktlen = 418 hdr = "\231\001?\000\b\000\000" hdrlen = 3 new_ctb = 0 partial = 0 with_uid = 0 __func__ = "parse" #2 0x00000000004273e5 in dbg_parse_packet (inp=0x8016701a0, pkt=0x801604180, dbg_f=0x481e30 "import.c", dbg_l=375) at parse-packet.c:212 skip = 0 rc = 23101792 #3 0x00000000004478db in import (inp=0x8016701a0, fname=0x7fffffffedac "./pubdemo.asc", stats=0x801660180, fpr=0x0, fpr_len=0x0, options=8) at import.c:437 pending_pkt = (PACKET *) 0x0 keyblock = 0x0 rc = 23085440 #4 0x00000000004485f5 in import_keys_internal (inp=0x8016701a0, fnames=0x7fffffffeb68, nnames=1, stats_handle=0x0, fpr=0x0, fpr_len=0x0, options=8) at import.c:198 fname = 0x7fffffffedac "./pubdemo.asc" inp2 = 0x8016701a0 i = 0 rc = 0 stats = (struct stats_s *) 0x801660180 #5 0x00000000004486fc in import_keys (fnames=0x8012de048, nnames=0, stats_handle=0x801608160, options=19783744) at import.c:231 No locals. #6 0x00000000004095aa in main (argc=1, argv=0x7fffffffeb68) at gpg.c:3492 badalg = 0x1 badtype = 23101792 pargs = {argc = 0x7fffffffe59c, argv = 0x7fffffffe590, flags = 32769, err = 0, r_opt = 0, r_type = 0, r = {ret_int = 0, ret_long = 0, ret_ulong = 0, ret_str = 0x0}, internal = {idx = 9, inarg = 0, stopped = 1, last = 0x7fffffffedac "./pubdemo.asc", aliases = 0x0, cur_alias = 0x0}} a = 0x1 rc = 23101792 orig_argc = -4692 orig_argv = (char **) 0x0 fname = 0x7fffffffedac "./pubdemo.asc" username = 0x1 may_coredump = 0 sl = 0x0 remusr = 0x0 locusr = 0x0 nrings = 0x0 sec_nrings = 0x0 afx = {what = 4200888, only_keyblocks = 0, hdrlines = 0x402cb7 "atexit", no_openpgp_data = 0, inp_checked = 0, inp_bypass = 5858381, in_cleartext = 8, not_dash_escaped = 0, hashes = 1, faked = -5544, truncated = 32767, qp_detected = 6017024, pgp2mode = 8, eol = "\000`[", buffer = 0x599af0 "\340W\002\001\b", buffer_size = 1, buffer_len = 0, buffer_pos = 0, radbuf = "\000\000\000", idx = 5870905, idx2 = 8, crc = 16930784, status = 8, cancel = 5858744, any_data = 8, pending_lf = 0} detached_sig = 0 configfp = (FILE *) 0x1 configname = 0x1 save_configname = 0x0 configlineno = 0 parse_debug = 0 default_config = 0 default_keyring = 1 greeting = 0 nogreeting = 0 logfile = 0x0 use_random_seed = 1 cmd = aImport debug_level = 0x0 trustdb_name = 0x0 def_cipher_string = 0x0 def_digest_string = 0x0 compress_algo_string = 0x0 cert_digest_string = 0x0 s2k_cipher_string = 0x0 s2k_digest_string = 0x0 pers_cipher_list = 0x0 pers_digest_list = 0x470e2a "h2" pers_compress_list = 0x0 eyes_only = 0 multifile = 0 pwfd = -1 with_fpr = 0 any_explicit_recipient = 0 require_secmem = 0 got_secmem = 1 __FUNCTION__ = "main" (gdb) q The program is running. Exit anyway? (y or n) From wk at gnupg.org Tue Nov 7 09:38:31 2006 From: wk at gnupg.org (Werner Koch) Date: Tue Nov 7 09:42:25 2006 Subject: GnuPG 1.9.95: gpg2 segfaults on build test In-Reply-To: <861wogc8wk.wl%umq@ueo.co.jp> (Hirohisa Yamaguchi's message of "Tue\, 07 Nov 2006 11\:01\:15 +0900") References: <87ac34op0m.fsf@wheatstone.g10code.de> <861wogc8wk.wl%umq@ueo.co.jp> Message-ID: <87ejsfr6rc.fsf@wheatstone.g10code.de> On Tue, 7 Nov 2006 03:01, umq.461@gmail.com said: > It seems like the same problem as the one reported in last month. > # http://lists.gnupg.org/pipermail/gnupg-devel/2006-October/023253.html > > I attached gdb backtrace below. > Any suggestions?. Remove the -O2 from the CFLAGS. This seems to be an optimization problem. What gcc version are you using? May you try building it using an older gcc version? Shalom-Salam, Werner From rdieter at math.unl.edu Tue Nov 7 14:05:11 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue Nov 7 14:04:03 2006 Subject: GnuPG 1.9.95: gpg2 segfaults on build test References: <87ac34op0m.fsf@wheatstone.g10code.de> <861wogc8wk.wl%umq@ueo.co.jp> <87ejsfr6rc.fsf@wheatstone.g10code.de> Message-ID: Werner Koch wrote: > On Tue, 7 Nov 2006 03:01, umq.461@gmail.com said: > >> It seems like the same problem as the one reported in last month. >> # http://lists.gnupg.org/pipermail/gnupg-devel/2006-October/023253.html >> >> I attached gdb backtrace below. >> Any suggestions?. > > Remove the -O2 from the CFLAGS. This seems to be an optimization > problem. What gcc version are you using? May you try building it > using an older gcc version? Yup, likely. We ended up building our x86_64 port using ./configure --disable-optimization -- Rex From umq.461 at gmail.com Tue Nov 7 17:16:34 2006 From: umq.461 at gmail.com (Hirohisa Yamaguchi) Date: Tue Nov 7 17:14:34 2006 Subject: GnuPG 1.9.95: gpg2 segfaults on build test In-Reply-To: <87ejsfr6rc.fsf@wheatstone.g10code.de> References: <87ac34op0m.fsf@wheatstone.g10code.de> <861wogc8wk.wl%umq@ueo.co.jp> <87ejsfr6rc.fsf@wheatstone.g10code.de> Message-ID: <86hcxbb5b1.wl%umq@ueo.co.jp> At Tue, 07 Nov 2006 09:38:31 +0100, Werner Koch wrote: > > It seems like the same problem as the one reported in last month. > > # http://lists.gnupg.org/pipermail/gnupg-devel/2006-October/023253.html > > I attached gdb backtrace below. > > Any suggestions?. > Remove the -O2 from the CFLAGS. This seems to be an optimization > problem. What gcc version are you using? May you try building it > using an older gcc version? Removing -O2 seems to cease the error. I'll apply this in my build ENV. I use gcc that comes with the system. I could not build/run older gcc's. | $ gcc --version | gcc (GCC) 3.4.6 [FreeBSD] 20060825 | Copyright (C) 2006 Free Software Foundation, Inc. | This is free software; see the source for copying conditions. There is NO | warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. # Also, the same errors occur with GCC 4.0, 4.1, and 4.2. Regards, -- Hirohisa Yamaguchi umq.461@gmail.com From wk at gnupg.org Fri Nov 10 11:44:53 2006 From: wk at gnupg.org (Werner Koch) Date: Fri Nov 10 11:58:50 2006 Subject: GnuPG 1.9.95: gpg2 segfaults on build test In-Reply-To: <86hcxbb5b1.wl%umq@ueo.co.jp> (Hirohisa Yamaguchi's message of "Wed\, 08 Nov 2006 01\:16\:34 +0900") References: <87ac34op0m.fsf@wheatstone.g10code.de> <861wogc8wk.wl%umq@ueo.co.jp> <87ejsfr6rc.fsf@wheatstone.g10code.de> <86hcxbb5b1.wl%umq@ueo.co.jp> Message-ID: <87fycr37iy.fsf@wheatstone.g10code.de> On Tue, 7 Nov 2006 17:16, umq.461@gmail.com said: > Removing -O2 seems to cease the error. > I'll apply this in my build ENV. Well, sitting at the SFScon at Bozen, Marcus and me tracked down the bug. It is very easy to fix and actually an oversight when I wrote mpi_read. It reveals it self only on 64 bit machines because there sizeof(unsigned int) != sizeof(size_t). gcc should have emitted a warning when compiling on 64 bit. I agree that gnupg is a lot of code and such warnings are easily overlooked. I attach a patch. Most of it is just re-indentation. Shalom-Salam, Werner -------------- next part -------------- Index: parse-packet.c =================================================================== --- parse-packet.c (revision 4329) +++ parse-packet.c (working copy) @@ -112,41 +112,41 @@ /*FIXME: Needs to be synced with gnupg14/mpi/mpicoder.c*/ int c, c1, c2, i; - unsigned int nbits, nbytes, nread=0; + unsigned int nbits, nbytes; + size_t nread; gcry_mpi_t a = NULL; byte *buf = NULL; byte *p; - if( (c = c1 = iobuf_get(inp)) == -1 ) + if ( (c = c1 = iobuf_get (inp)) == -1 ) goto leave; nbits = c << 8; - if( (c = c2 = iobuf_get(inp)) == -1 ) + if ( (c = c2 = iobuf_get (inp)) == -1 ) goto leave; nbits |= c; - if( nbits > MAX_EXTERN_MPI_BITS ) + if ( nbits > MAX_EXTERN_MPI_BITS ) { log_error("mpi too large (%u bits)\n", nbits); goto leave; } nread = 2; nbytes = (nbits+7) / 8; - buf = secure? gcry_xmalloc_secure( nbytes+2 ) : gcry_xmalloc( nbytes+2 ); + buf = secure ? gcry_xmalloc_secure (nbytes + 2) : gcry_xmalloc (nbytes + 2); p = buf; p[0] = c1; p[1] = c2; - for( i=0 ; i < nbytes; i++ ) + for ( i=0 ; i < nbytes; i++ ) { p[i+2] = iobuf_get(inp) & 0xff; nread++; } - nread += nbytes; - if( gcry_mpi_scan( &a, GCRYMPI_FMT_PGP, buf, nread, &nread ) ) + if ( gcry_mpi_scan( &a, GCRYMPI_FMT_PGP, buf, nread, &nread ) ) a = NULL; leave: gcry_free(buf); - if( nread > *ret_nread ) - log_bug("mpi larger than packet"); + if ( nread > *ret_nread ) + log_bug ("mpi larger than packet"); else *ret_nread = nread; return a; From rdieter at math.unl.edu Fri Nov 10 13:50:02 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri Nov 10 13:49:15 2006 Subject: GnuPG 1.9.95: gpg2 segfaults on build test References: <87ac34op0m.fsf@wheatstone.g10code.de> <861wogc8wk.wl%umq@ueo.co.jp> <87ejsfr6rc.fsf@wheatstone.g10code.de> <86hcxbb5b1.wl%umq@ueo.co.jp> <87fycr37iy.fsf@wheatstone.g10code.de> Message-ID: Werner Koch wrote: >> Removing -O2 seems to cease the error. >> I'll apply this in my build ENV. > > Well, sitting at the SFScon at Bozen, Marcus and me tracked down the > bug. It is very easy to fix and actually an oversight when I wrote > mpi_read. It reveals it self only on 64 bit machines because there > sizeof(unsigned int) != sizeof(size_t). gcc should have emitted a > warning when compiling on 64 bit. I agree that gnupg is a lot of code > and such warnings are easily overlooked. Many thanks. -- Rex From umq.461 at gmail.com Fri Nov 10 14:45:08 2006 From: umq.461 at gmail.com (Hirohisa yamaguchi) Date: Fri Nov 10 14:43:29 2006 Subject: GnuPG 1.9.95: gpg2 segfaults on build test In-Reply-To: <87fycr37iy.fsf@wheatstone.g10code.de> References: <87ac34op0m.fsf@wheatstone.g10code.de> <861wogc8wk.wl%umq@ueo.co.jp> <87ejsfr6rc.fsf@wheatstone.g10code.de> <86hcxbb5b1.wl%umq@ueo.co.jp> <87fycr37iy.fsf@wheatstone.g10code.de> Message-ID: <8664dnh0uz.wl%umq@ueo.co.jp> At Fri, 10 Nov 2006 11:44:53 +0100, Werner Koch wrote: > On Tue, 7 Nov 2006 17:16, umq.461@gmail.com said: > Well, sitting at the SFScon at Bozen, Marcus and me tracked down the > bug. It is very easy to fix and actually an oversight when I wrote > mpi_read. It reveals it self only on 64 bit machines because there > sizeof(unsigned int) != sizeof(size_t). gcc should have emitted a > warning when compiling on 64 bit. I agree that gnupg is a lot of code > and such warnings are easily overlooked. > I attach a patch. Most of it is just re-indentation. It looks okay, thanks. -- end Hirohisa Yamaguchi umq.461@gmail.com From rdieter at math.unl.edu Fri Nov 10 15:26:32 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri Nov 10 15:31:55 2006 Subject: GnuPG 1.9.95: gpg2 segfaults on build test References: <87ac34op0m.fsf@wheatstone.g10code.de> <861wogc8wk.wl%umq@ueo.co.jp> <87ejsfr6rc.fsf@wheatstone.g10code.de> <86hcxbb5b1.wl%umq@ueo.co.jp> <87fycr37iy.fsf@wheatstone.g10code.de> Message-ID: Werner Koch wrote: >> Removing -O2 seems to cease the error. >> I'll apply this in my build ENV. > > Well, sitting at the SFScon at Bozen, Marcus and me tracked down the > bug. It is very easy to fix and actually an oversight when I wrote > mpi_read. It reveals it self only on 64 bit machines because there > sizeof(unsigned int) != sizeof(size_t). gcc should have emitted a > warning when compiling on 64 bit. I agree that gnupg is a lot of code > and such warnings are easily overlooked. > > I attach a patch. Most of it is just re-indentation. Better, no more segfaults, but now 'make check' hangs... make[3]: Entering directory `/builddir/build/BUILD/gnupg-1.9.95/tests/openpgp' gpg (GnuPG) 1.9.95 NOTE: THIS IS A DEVELOPMENT VERSION! It is only intended for test purposes and should NOT be used in a production environment or with production keys! Copyright (C) 2006 Free Software Foundation, Inc. This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the file COPYING for details. Home: . Supported algorithms: Pubkey: RSA, ELG, DSA, ELG Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH Hash: MD5, SHA1, RIPEMD160, TIGER192, SHA256, SHA384, SHA512 Compression: Uncompressed, ZIP, ZLIB, BZIP2 PASS: version.test Hash algorithm SHA-224 is not installed (not an error) PASS: mds.test FAIL: decrypt.test ... waiting forever ... From umq.461 at gmail.com Sat Nov 11 13:00:24 2006 From: umq.461 at gmail.com (Hirohisa Yamaguchi) Date: Sat Nov 11 12:58:39 2006 Subject: GnuPG 1.9.95: gpg2 segfaults on build test In-Reply-To: <87fycr37iy.fsf@wheatstone.g10code.de> References: <87ac34op0m.fsf@wheatstone.g10code.de> <861wogc8wk.wl%umq@ueo.co.jp> <87ejsfr6rc.fsf@wheatstone.g10code.de> <86hcxbb5b1.wl%umq@ueo.co.jp> <87fycr37iy.fsf@wheatstone.g10code.de> Message-ID: <86mz6y42hz.wl%umq@ueo.co.jp> At Fri, 10 Nov 2006 11:44:53 +0100, Werner Koch wrote: > Well, sitting at the SFScon at Bozen, Marcus and me tracked down the > bug. It is very easy to fix and actually an oversight when I wrote > mpi_read. It reveals it self only on 64 bit machines because there > sizeof(unsigned int) != sizeof(size_t). gcc should have emitted a > warning when compiling on 64 bit. I agree that gnupg is a lot of code > and such warnings are easily overlooked. > I attach a patch. Most of it is just re-indentation. Here I attach a set of patch to avoid ``incompatible pointer type'' warnings. I'm not sure if this causes any side-effects. -- end Hirohisa Yamaguchi umq.461@gmail.com -------------- next part -------------- A non-text attachment was scrubbed... Name: gnupg-1.9.95.patch Type: application/octet-stream Size: 6914 bytes Desc: not available Url : /pipermail/attachments/20061111/52f3d5ef/gnupg-1.9.95.obj From wk at gnupg.org Sat Nov 11 15:15:03 2006 From: wk at gnupg.org (Werner Koch) Date: Sat Nov 11 15:17:26 2006 Subject: Latest news from Duesseldorf and Bolzano Message-ID: <874pt6134o.fsf@wheatstone.g10code.de> Hi! Today it is not just the awakening of Hoppeditz [1] but also GnuPG 2.0.0 has hit the server: ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.0.0.tar.bz2 (3813k) ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.0.0.tar.bz2.sig A real announcement will follow soon. Shalom-Salam, Werner [1] http://wn.wikipedia.org/wiki/Hoppeditz (German) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : /pipermail/attachments/20061111/ae7887db/attachment.pgp From alphasigmax at gmail.com Sun Nov 12 00:45:00 2006 From: alphasigmax at gmail.com (Alphax) Date: Sun Nov 12 00:43:57 2006 Subject: Latest news from Duesseldorf and Bolzano In-Reply-To: <874pt6134o.fsf@wheatstone.g10code.de> References: <874pt6134o.fsf@wheatstone.g10code.de> Message-ID: <4556607C.1040608@gmail.com> Werner Koch wrote: > Hi! > > Today it is not just the awakening of Hoppeditz [1] but also GnuPG > 2.0.0 has hit the server: > > ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.0.0.tar.bz2 (3813k) > ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.0.0.tar.bz2.sig > > A real announcement will follow soon. > > r4334 didn't have a log entry at commit, can you add one? SVN syntax is $ svn propset svn:log (message) -r4334 --revprop provided it's enabled on the server. > [1] http://wn.wikipedia.org/wiki/Hoppeditz (German) > wn isn't an ISO 639-1 code; assuming you meant en, there's no article in English yet. The correct URL is http://de.wikipedia.org/wiki/Hoppeditz (German) :) -- Alphax Death to all fanatics! Down with categorical imperative! OpenPGP key: http://tinyurl.com/lvq4g -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 569 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20061112/6b0632bd/signature.pgp From wk at gnupg.org Sun Nov 12 13:04:14 2006 From: wk at gnupg.org (Werner Koch) Date: Sun Nov 12 23:41:56 2006 Subject: GnuPG 2 and Debian's Pth (was: Latest news from Duesseldorf and Bolzano) In-Reply-To: <20061111213237.GA1836@rio-grande.ping.de> (Daniel Hess's message of "Sat\, 11 Nov 2006 22\:32\:38 +0100") References: <874pt6134o.fsf@wheatstone.g10code.de> <20061111213237.GA1836@rio-grande.ping.de> Message-ID: <871wo8j2gx.fsf_-_@wheatstone.g10code.de> On Sat, 11 Nov 2006 22:32, daniel-gnupg-users@rio-grande.ping.de said: > I've problems building it on debian unstable with GNU Pth. > I've traced it down to pth.h which has PTH_SYSCALL_SOFT to 1 per > default, because it's configured with --enable-pthread, which implies > --enable-syscall-soft, by debian. With PTH_SYSCALL_SOFT set to 1 the > pth.h header enables some #defines which replace write with pth_write. > This way io.write is replaced with io.pth_write and the non existing > member pth_write is used, which does not succeed. This is an unusual change in Sid. I am still using the old 2.0.1 version of pth and thus I have not seen that problem on my development boxes. Debian even installs a new libthread and pthread.h which is obviously a problem: Pth and Pthread are two different libraries and not interchangeable. This needs to be discussed with the Debian folks. Shalom-Salam, Werner From wk at gnupg.org Sun Nov 12 18:38:39 2006 From: wk at gnupg.org (Werner Koch) Date: Sun Nov 12 23:42:10 2006 Subject: GnuPG 1.9.95: gpg2 segfaults on build test In-Reply-To: <86mz6y42hz.wl%umq@ueo.co.jp> (Hirohisa Yamaguchi's message of "Sat\, 11 Nov 2006 21\:00\:24 +0900") References: <87ac34op0m.fsf@wheatstone.g10code.de> <861wogc8wk.wl%umq@ueo.co.jp> <87ejsfr6rc.fsf@wheatstone.g10code.de> <86hcxbb5b1.wl%umq@ueo.co.jp> <87fycr37iy.fsf@wheatstone.g10code.de> <86mz6y42hz.wl%umq@ueo.co.jp> Message-ID: <87velkftuo.fsf@wheatstone.g10code.de> On Sat, 11 Nov 2006 13:00, umq.461@gmail.com said: > At Fri, 10 Nov 2006 11:44:53 +0100, > Werner Koch wrote: >> Well, sitting at the SFScon at Bozen, Marcus and me tracked down the >> bug. It is very easy to fix and actually an oversight when I wrote >> mpi_read. It reveals it self only on 64 bit machines because there >> sizeof(unsigned int) != sizeof(size_t). gcc should have emitted a >> warning when compiling on 64 bit. I agree that gnupg is a lot of code >> and such warnings are easily overlooked. > >> I attach a patch. Most of it is just re-indentation. > > Here I attach a set of patch to avoid ``incompatible pointer type'' warnings. > I'm not sure if this causes any side-effects. Thanks for looking into this. I can't use the patches because sprintf (numbuf, "%zd:", rsa_n_len); is not portable enough ("%zd"). As there are several of such problems, I will build a x64 cross compiler and check myself. Shalom-Salam, Werner From umq.461 at gmail.com Mon Nov 13 01:55:10 2006 From: umq.461 at gmail.com (Hirohisa Yamaguchi) Date: Mon Nov 13 01:53:20 2006 Subject: GnuPG 1.9.95: gpg2 segfaults on build test In-Reply-To: <87velkftuo.fsf@wheatstone.g10code.de> References: <87ac34op0m.fsf@wheatstone.g10code.de> <861wogc8wk.wl%umq@ueo.co.jp> <87ejsfr6rc.fsf@wheatstone.g10code.de> <86hcxbb5b1.wl%umq@ueo.co.jp> <87fycr37iy.fsf@wheatstone.g10code.de> <86mz6y42hz.wl%umq@ueo.co.jp> <87velkftuo.fsf@wheatstone.g10code.de> Message-ID: <86d57sp3m9.wl%umq@ueo.co.jp> At Sun, 12 Nov 2006 18:38:39 +0100, Werner Koch wrote: > On Sat, 11 Nov 2006 13:00, umq.461@gmail.com said: > > Here I attach a set of patch to avoid ``incompatible pointer type'' warnings. > > I'm not sure if this causes any side-effects. > Thanks for looking into this. I can't use the patches because > sprintf (numbuf, "%zd:", rsa_n_len); > is not portable enough ("%zd"). As there are several of such > problems, I will build a x64 cross compiler and check myself. "%zd" in printf(3) might be safely replaced by "%lu", for portability to non-C99 compilers. There're other wornings like: ``warning: cast to pointer from integer of different size'' or ``warning: comparison is always false due to limited range of data type''. These may be the cause of problems we've not seen yet. Regards, -- end Hirohisa Yamaguchi umq.461@gmail.com From wk at gnupg.org Mon Nov 13 09:23:19 2006 From: wk at gnupg.org (Werner Koch) Date: Mon Nov 13 09:27:09 2006 Subject: GnuPG 1.9.95: gpg2 segfaults on build test In-Reply-To: <86d57sp3m9.wl%umq@ueo.co.jp> (Hirohisa Yamaguchi's message of "Mon\, 13 Nov 2006 09\:55\:10 +0900") References: <87ac34op0m.fsf@wheatstone.g10code.de> <861wogc8wk.wl%umq@ueo.co.jp> <87ejsfr6rc.fsf@wheatstone.g10code.de> <86hcxbb5b1.wl%umq@ueo.co.jp> <87fycr37iy.fsf@wheatstone.g10code.de> <86mz6y42hz.wl%umq@ueo.co.jp> <87velkftuo.fsf@wheatstone.g10code.de> <86d57sp3m9.wl%umq@ueo.co.jp> Message-ID: <87ejs7dabs.fsf@wheatstone.g10code.de> On Mon, 13 Nov 2006 01:55, umq.461@gmail.com said: > "%zd" in printf(3) might be safely replaced by "%lu", for portability > to non-C99 compilers. It is actually a matter of the C library being C99 compliant. Anyway, we write code for C90. %lu will only worg if size_t is defined as unsigned long but this is not always the case. Casing it is in okay here because we know the range of the values. > There're other wornings like: Well, I will see that as soon as I have the cross compiler running. Shalom-Salam, Werner From wk at gnupg.org Mon Nov 13 12:27:32 2006 From: wk at gnupg.org (Werner Koch) Date: Mon Nov 13 14:04:06 2006 Subject: [Announce] GnuPG 2.0 released Message-ID: <87d57r37tn.fsf@wheatstone.g10code.de> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From funman at videolan.org Thu Nov 2 21:17:00 2006 From: funman at videolan.org (=?UTF-8?B?UmFmYcOrbCBDYXJyw6k=?=) Date: Mon Nov 13 16:04:56 2006 Subject: [PATCH] fix a typo when building libgcrypt and gnupg 1.4 with mingw-runtime 3.10 Message-ID: <20061102211700.0933ba9b@zod> Hello, Since version 3.10, mingw-runtime now includes gettimeofday() defined in as specified by POSIX: http://www.opengroup.org/onlinepubs/009695399/functions/gettimeofday.html People using this version to compile are experiencing problems with a piece of code which is common to gnupg 1.4 and libcrypt 1.2.3 : cipher/random.c http://lists.gnupg.org/pipermail/gnupg-devel/2006-June/022975.html Here is that code: #ifdef HAVE_GETTIMEOFDAY #include #endif What will happen on UNIX systems: they all have gettimeofday(), and they all have sys/times.h so it's ok What will happen on WINDOWS systems: they don't have gettimeofday() , so it's ok too What will happen on WINDOWS systems using mingw compiler and mingw-runtime 3.10 : they have gettimeofday(), but they don't have so the build will fail To my knowledge, there is no system that defines gettimeofday() in , only in Please replace by because this is an annoying typo. Thanks. -- Rafa?l Carr? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20061102/3223c3aa/signature-0001.pgp From daniel-gnupg-users at rio-grande.ping.de Sat Nov 11 22:32:38 2006 From: daniel-gnupg-users at rio-grande.ping.de (Daniel Hess) Date: Mon Nov 13 16:05:01 2006 Subject: Latest news from Duesseldorf and Bolzano In-Reply-To: <874pt6134o.fsf@wheatstone.g10code.de> References: <874pt6134o.fsf@wheatstone.g10code.de> Message-ID: <20061111213237.GA1836@rio-grande.ping.de> Hello On Sat, Nov 11, 2006 at 03:15:03PM +0100, Werner Koch wrote: > Today it is not just the awakening of Hoppeditz [1] but also GnuPG > 2.0.0 has hit the server: > > ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.0.0.tar.bz2 (3813k) > ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.0.0.tar.bz2.sig > > A real announcement will follow soon. I've problems building it on debian unstable with GNU Pth. The build is aborted with the following error message: if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../gl -I/usr/include \ -I/usr/include -Wall -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -Wno-format-y2k -Wformat-security -Wformat-nonliteral -Wno-pointer-sign -MT libcommonpth_a-estream.o -MD -MP -MF ".deps/libcommonpth_a-estream.Tpo" -c -o libcommonpth_a-estream.o `test -f 'estream.c' || echo './'`estream.c; \ then mv -f ".deps/libcommonpth_a-estream.Tpo" ".deps/libcommonpth_a-estream.Po"; else rm -f ".deps/libcommonpth_a-estream.Tpo"; exit 1; fi estream.c: In function ?es_print?: estream.c:1689: error: ?cookie_io_functions_t? has no member named ?pth_write? I've traced it down to pth.h which has PTH_SYSCALL_SOFT to 1 per default, because it's configured with --enable-pthread, which implies --enable-syscall-soft, by debian. With PTH_SYSCALL_SOFT set to 1 the pth.h header enables some #defines which replace write with pth_write. This way io.write is replaced with io.pth_write and the non existing member pth_write is used, which does not succeed. I've now placed an "# define PTH_SYSCALL_SOFT 0" top of "# include ", which disables the define in pth.h. Greetings Daniel From brunij at earthlink.net Sun Nov 12 02:53:14 2006 From: brunij at earthlink.net (Joseph Oreste Bruni) Date: Mon Nov 13 16:05:05 2006 Subject: Latest news from Duesseldorf and Bolzano In-Reply-To: <874pt6134o.fsf@wheatstone.g10code.de> References: <874pt6134o.fsf@wheatstone.g10code.de> Message-ID: <94ADB1B1-4D01-4CB2-BC3C-A5D51B9141A5@earthlink.net> Does not build on OS X (10.4.8). While trying to build libgpg-error I received the following link error: ld: common symbols not allowed with MH_DYLIB output format with the - multi_module option ../intl/libintl.a(loadmsgcat.o) definition of common __nl_msg_cat_cntr (size 4) ../intl/libintl.a(dcigettext.o) definition of common _libintl_nl_domain_bindings (size 4) ../intl/libintl.a(plural-exp.o) definition of common _libintl_gettext_germanic_plural (size 20) On Nov 11, 2006, at 7:15 AM, Werner Koch wrote: > Hi! > > Today it is not just the awakening of Hoppeditz [1] but also GnuPG > 2.0.0 has hit the server: > > ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.0.0.tar.bz2 (3813k) > ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.0.0.tar.bz2.sig > > A real announcement will follow soon. > > > Shalom-Salam, > > Werner > > > [1] http://wn.wikipedia.org/wiki/Hoppeditz (German) > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2508 bytes Desc: not available Url : /pipermail/attachments/20061111/54301cae/smime-0001.bin From marcus.brinkmann at ruhr-uni-bochum.de Mon Nov 13 16:25:20 2006 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Mon Nov 13 17:48:13 2006 Subject: [Announce] Scute 1.0 released Message-ID: <87y7qfl673.wl%marcus.brinkmann@ruhr-uni-bochum.de> Hello! g10 Code GmbH is pleased to announce the availability of the new software package Scute. Scute is a PKCS #11 implementation for the OpenPGP card using the GnuPG 2.0 framework. It allows you to use your OpenPGP card for client authentication in Mozilla-based web browsers. Scute is distributed under the terms of the GNU General Public License (GPL). Scute works best on GNU/Linux or *BSD systems. Other POSIX compliant systems are also supported but have not yet been tested very well. Getting the Software ==================== Please follow the instructions found at http://www.scute.org/download.xhtml or read on: Scute may be downloaded from one of the GnuPG mirror sites or directly from ftp://ftp.gnupg.org/gcrypt/ . The list of mirrors can be found at http://www.gnupg.org/mirrors.html . On the mirrors you should find the following files in the *scute* directory: scute-1.0.0.tar.bz2 scute-1.0.0.tar.bz2.sig Scute source compressed using BZIP2 and OpenPGP signature. Please try another mirror if exceptional your mirror is not yet up to date. Scute requires a couple of libraries to be installed; see the README file for details. Checking the Integrity ====================== In order to check that the version of Scute which you are going to install is an original and unmodified one, simply check the supplied signature. For example to check the signature of the file scute-1.0.0.tar.bz2 you would use this command: gpg --verify scute-1.0.0.tar.bz2.sig This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by that signing key. Make sure that you have the right key, either by checking the fingerprint of that key with other sources or by checking that the key has been signed by a trustworthy other key. Note, that you can retrieve the signing key using the command finger wk ,at' g10code.com or using a key server like gpg --recv-key 1CE0C630 The distribution key 1CE0C630 is signed by the well known key 5B0358A2. If you get an key expired message, you should retrieve a fresh copy as the expiration date might have been prolonged. NEVER USE A GNUPG VERSION YOU JUST DOWNLOADED TO CHECK THE INTEGRITY OF THE SOURCE - USE AN EXISTING GNUPG INSTALLATION! Documentation ============= Documentation is currently only available in the file README. More detailed instructions will be part of the next version and become available on the web page in the next two weeks. Support ======= Improving Scute is costly, but you can help! We are looking for organizations that find Scute useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or by donating money. Commercial support contracts for Scute are available, and they help finance continued maintenance. g10 Code GmbH, a Duesseldorf based company owned and headed by GnuPG's principal author, is currently funding Scute development. We are always looking for interesting development projects. Happy Hacking, The Scute Team (Werner and Marcus) _______________________________________________ Gnupg-announce mailing list Gnupg-announce@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From ueno at unixuser.org Tue Nov 14 06:58:39 2006 From: ueno at unixuser.org (Daiki Ueno) Date: Tue Nov 14 07:37:55 2006 Subject: --status-fd incompatibility between gpg & gpgsm Message-ID: Hi, I found a small compatibility issue between gpg2 and gpgsm. According to doc/DETAILS, it seems that gpgsm writes GOODSIG and VALIDSIG in illegal formats. $ gpg2 --status-fd 1 --verify test.txt.gpg 2> /dev/null | grep '^\[GNUPG:' [GNUPG:] SIG_ID 1DmCO9m83ur60sS/ylTOB1AI68w 2006-11-14 1163482953 [GNUPG:] GOODSIG A5B6B2D4B15813FE Daiki Ueno [GNUPG:] VALIDSIG 80037CD00F1A940003CA50AAA5B6B2D4B15813FE 2006-11-14 1163482953 0 3 0 17 2 00 80037CD00F1A940003CA50AAA5B6B2D4B15813FE [GNUPG:] TRUST_ULTIMATE $ gpgsm --status-fd 1 --verify test.p7s 2> /dev/null | grep '^\[GNUPG:' [GNUPG:] NEWSIG [GNUPG:] GOODSIG [GNUPG:] VALIDSIG AEEAE230F415D401C78F1F3FD4BB2EDB066538B4 2006-11-14 20061114T054140 20070421T135232 [GNUPG:] TRUST_FULLY Regards, -- Daiki Ueno From wk at gnupg.org Tue Nov 14 08:46:34 2006 From: wk at gnupg.org (Werner Koch) Date: Tue Nov 14 08:51:36 2006 Subject: --status-fd incompatibility between gpg & gpgsm In-Reply-To: (Daiki Ueno's message of "Tue\, 14 Nov 2006 14\:58\:39 +0900") References: Message-ID: <878xiewjvp.fsf@wheatstone.g10code.de> On Tue, 14 Nov 2006 06:58, ueno@unixuser.org said: > [GNUPG:] GOODSIG I will add the missing keyid and the user's name. > [GNUPG:] VALIDSIG AEEAE230F415D401C78F1F3FD4BB2EDB066538B4 2006-11-14 20061114T054140 20070421T135232 I fixed the documentation. The missing arguments are OpenPGP specific and thus not available for CMS. Shalom-Salam, Werner From alex at bofh.net.pl Tue Nov 14 15:46:17 2006 From: alex at bofh.net.pl (Janusz A. Urbanowicz) Date: Tue Nov 14 16:46:11 2006 Subject: 2.0 fails to build on debian testing Message-ID: <20061114144617.GB12190@hell.pl> I'm trying to build 2.0 on testing with configure --enable-mailto --enable-symcryptrun --disable-photo-viewers --enable-selinux-support as this is a remote system for all users. It fails with: rm -f ".deps/libcommonpth_a-exechelp.Tpo"; exit 1; fi if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../gl -I/usr/local/include -I/usr/local/include -I/usr/include -g -O2 -Wall -Wno-pointer-sign -MT libcommonpth_a-simple-gettext.o -MD -MP -MF ".deps/libcommonpth_a-simple-gettext.Tpo" -c -o libcommonpth_a-simple-gettext.o `test -f 'simple-gettext.c' || echo './'`simple-gettext.c; \ then mv -f ".deps/libcommonpth_a-simple-gettext.Tpo" ".deps/libcommonpth_a-simple-gettext.Po"; else rm -f ".deps/libcommonpth_a-simple-gettext.Tpo"; exit 1; fi if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../gl -I/usr/local/include -I/usr/local/include -I/usr/include -g -O2 -Wall -Wno-pointer-sign -MT libcommonpth_a-w32reg.o -MD -MP -MF ".deps/libcommonpth_a-w32reg.Tpo" -c -o libcommonpth_a-w32reg.o `test -f 'w32reg.c' || echo './'`w32reg.c; \ then mv -f ".deps/libcommonpth_a-w32reg.Tpo" ".deps/libcommonpth_a-w32reg.Po"; else rm -f ".deps/libcommonpth_a-w32reg.Tpo"; exit 1; fi if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../gl -I/usr/local/include -I/usr/local/include -I/usr/include -g -O2 -Wall -Wno-pointer-sign -MT libcommonpth_a-signal.o -MD -MP -MF ".deps/libcommonpth_a-signal.Tpo" -c -o libcommonpth_a-signal.o `test -f 'signal.c' || echo './'`signal.c; \ then mv -f ".deps/libcommonpth_a-signal.Tpo" ".deps/libcommonpth_a-signal.Po"; else rm -f ".deps/libcommonpth_a-signal.Tpo"; exit 1; fi if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../gl -I/usr/local/include -I/usr/local/include -I/usr/include -g -O2 -Wall -Wno-pointer-sign -MT libcommonpth_a-estream.o -MD -MP -MF ".deps/libcommonpth_a-estream.Tpo" -c -o libcommonpth_a-estream.o `test -f 'estream.c' || echo './'`estream.c; \ then mv -f ".deps/libcommonpth_a-estream.Tpo" ".deps/libcommonpth_a-estream.Po"; else rm -f ".deps/libcommonpth_a-estream.Tpo"; exit 1; fi estream.c: In function 'es_print': estream.c:1689: error: 'cookie_io_functions_t' has no member named 'pth_write' make[2]: *** [libcommonpth_a-estream.o] B??d 1 make[2]: Opuszczenie katalogu `/home/staff/alex/gnupg-2.0.0/common' make[1]: *** [all-recursive] B??d 1 make[1]: Opuszczenie katalogu `/home/staff/alex/gnupg-2.0.0' make: *** [all] B??d 2 configure.log will be sent on request as it is 200 k long Alex -- JID: alex@hell.pl PGP: 0x46399138 od zwracania uwagi na detale s? lekarze, adwokaci, programi?ci i zegarmistrze -- Czerski From wk at gnupg.org Tue Nov 14 18:38:09 2006 From: wk at gnupg.org (Werner Koch) Date: Tue Nov 14 18:41:44 2006 Subject: 2.0 fails to build on debian testing In-Reply-To: <20061114144617.GB12190@hell.pl> (Janusz A. Urbanowicz's message of "Tue\, 14 Nov 2006 15\:46\:17 +0100") References: <20061114144617.GB12190@hell.pl> Message-ID: <87veliorni.fsf@wheatstone.g10code.de> On Tue, 14 Nov 2006 15:46, alex@bofh.net.pl said: > I'm trying to build 2.0 on testing with configure --enable-mailto > --enable-symcryptrun --disable-photo-viewers --enable-selinux-support > as this is a remote system for all users. Sid and thus tetsing is seriously broken in regard to libpth. There are changes in 2.0.7 which I don't understand. They have changed the API without renaming the library. libpth does now do soft mapping of all system calls (like #define write pth_write) by default. I can't see why they did this change. A workaround is to put #define PTH_SYSCALL_SOFT 0 into config.h I do not want to change this in GnuPG as it is Debian's fault. The maintainer has not yet answered so I consider filing an RC bug. Shalom-Salam, Werner From news at kfwebs.net Wed Nov 15 17:17:41 2006 From: news at kfwebs.net (Kristian Fiskerstrand) Date: Wed Nov 15 18:54:11 2006 Subject: IDEA Message-ID: <455B3DA5.2090403@kfwebs.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Greetings. I don't know if this is available already, and if so just disregard this email. Anyways, I had to open up a couple of old emails using IDEA as the symmetric cipher, so I threw together a small wrapper for libgcrypt-1.2.3 to add IDEA support to GnuPG 2.0. if anyone else is interested it can be found at http://www.kfwebs.net/articles/article/42/GnuPG-2.0---IDEA-support . Comments are welcome, Yours sincerely, - -- - ---------------------------- Kristian Fiskerstrand http://www.kfwebs.net - ---------------------------- http://www.secure-my-email.com http://www.secure-my-internet.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.0 (GNU/Linux) iQIVAwUBRVs9pBbgz41rC5UIAQiXZBAAj/eskdNR8Ot/aM00UJHYuTz4gYmbgq1v C7ET9z85kuYsRRMtTO5YmCC+79dLrEQBzjj14f6I6AJTr8VXwaPJnRBoCiuW4Kwl 9rcm0u8DxCq7L8OhF5vWG+PQ66xV+r5tf8zqCJAH6h3sJGPx7M3o/O1hVekD3CZJ q5stlweHt/Ew/5aZ+kdvcb0ANLsSJ3s0wnNkAQVBcMBpPrgs9OH9SulMmZ0mIHY3 8W5HhDlX7+Tg5Q1is4gs7fe2YhgrFo/bNNT3+PFMHwlCQCgnPBuxwjhKMG/ydwH3 uG1DeY+/oTDPWLs1LCJLEOlrSFxY6Nr2S/E/z9GX93gK1JHFpw6wXZr4CaCtrDDQ RwFn0gIPqBq7HYKiFb/Dpk64GuQEzRSZsYH9rVcyypght3JqaRW62ndwXCmkDV4O ZBgiKgk9yKrYOUpV9njvD5ehvQ/Onfd+gRoNacr8pqEa+HM3tkx9GnNUMICXAJmc r1uac8QPyxdFwyf23nC4GCL/Ztuty9ExWfaMYUOJ55/DuQPsXNSrsZcDUX6Ye7NU 1EaIAMgoGlnTwPDeGZPmg0ruWSXQ7FaZZ6tp0Vxab/K1NJZZ0chdARSnrHl67AwW wzTM3lNP0TgCe5XmRZJORaAZ/oR/Y9EE1ijjI5qC2Eo1tz5aBjuNq8dgIZJZg2rO qOyb7C9fLAY= =E9uQ -----END PGP SIGNATURE----- From wk at gnupg.org Thu Nov 16 15:18:46 2006 From: wk at gnupg.org (Werner Koch) Date: Thu Nov 16 15:21:45 2006 Subject: Outcome of the Logo Ballot Message-ID: <87ac2rpj95.fsf@wheatstone.g10code.de> Hi, The logo contest for GnuPG (see http://logo-contest.gnupg.org) has been finished some time ago. However up to the end of the voting period, I received only 11 votes out of 40 people eligible to vote. Further there is no clear results. 9 votes are for 9 different submissions and only 2 voted for the same. Given these results anything else but canceling this ballot would be unfair. To come to a decision, I have setup a new ballot using Condorcet voting at the the CIVS service [1]. All 1230 subscribers of gnupg-users and gnupg-devel are eligible to cast their vote. They will soon receive a mail with an URL to the ballow page. There you may rank all submissions or tag them with "no opinion". Note that, some submissions are by the same authors; they are distinguished by small letter and a description in parentheses (the name is only given one). Please make sure that your spam filters don't catch the mail with the URL, it will be send from andru at cs.cornell.edu. The ballot runs to the end of this month. Shalom-Salam, Werner [1] http://www.cs.cornell.edu/andru/civs.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : /pipermail/attachments/20061116/4562613b/attachment.pgp From twoaday at gmx.net Fri Nov 17 08:18:27 2006 From: twoaday at gmx.net (Timo Schulz) Date: Fri Nov 17 17:24:15 2006 Subject: [gpgme] set gpg options Message-ID: <455D6243.6030100@gmx.net> Hi, I would like to propose a change to the gpgme_set_XXX style functions. For example gpgme_set_textmode(). IMHO it would be a good idea to change the behaviour like that: if (val == true) cmdline += "--textmode"; else cmdline += "--no-textmode"; and if no gpgme_set_textmode() call were issued, no textmode related option will be added. The reason is, that if somebody calls gpgme_set_textmode(false), he wants to disable the textmode and wants to skip possible settings in the gpg.conf. With the current style, the mode is not supressed, but only not used. Timo From eric at debian.org Sun Nov 19 00:01:29 2006 From: eric at debian.org (Eric Dorland) Date: Sun Nov 19 01:32:52 2006 Subject: [PATCH] Put pcsc-wrapper in libexecdir Message-ID: <20061118230129.GB4519@nightcrawler.kuroneko.ca> Hello, I believe the pcsc-wrapper program should go into libexecdir rather than pkglibdir. Patch is below and the rationale from the GNU Coding Standards: libexecdir The directory for installing executable programs to be run by other programs rather than by users. This directory should normally be /usr/local/libexec, but write it as $(exec_prefix)/libexec. (If you are using Autoconf, write it as '@libexecdir@'.) Index: scd/Makefile.am =================================================================== --- scd/Makefile.am (revision 47512) +++ scd/Makefile.am (working copy) @@ -21,7 +21,7 @@ bin_PROGRAMS = scdaemon if ! HAVE_W32_SYSTEM -pkglib_PROGRAMS = pcsc-wrapper +libexec_PROGRAMS = pcsc-wrapper endif AM_CPPFLAGS = -I$(top_srcdir)/gl -I$(top_srcdir)/intl -I$(top_srcdir)/common Index: scd/apdu.c =================================================================== --- scd/apdu.c (revision 47512) +++ scd/apdu.c (working copy) @@ -1329,7 +1329,7 @@ int err; unsigned int dummy_status; int sw = SW_HOST_CARD_IO_ERROR; - const char *wrapperpgm = GNUPG_LIBDIR "/pcsc-wrapper"; + const char *wrapperpgm = GNUPG_LIBEXECDIR "/pcsc-wrapper"; if (access (wrapperpgm, X_OK)) { -- Eric Dorland ICQ: #61138586, Jabber: hooty@jabber.com 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : /pipermail/attachments/20061118/49a35710/attachment-0001.pgp From albrecht.dress at arcor.de Sun Nov 19 15:55:58 2006 From: albrecht.dress at arcor.de (=?iso-8859-1?q?Albrecht_Dre=DF?=) Date: Sun Nov 19 15:55:13 2006 Subject: Odd keyserver problem Message-ID: <1163948165l.3378l.0l@antares.localdomain> Hi all, I have an odd problem searching for a key on a HKP keyserver using GnuPG 1.4.5. Searching for a key using the mail address works fine (name & address removed for privacy): gpg --search-keys --keyserver hkp://blackhole.pca.dfn.de '<...@...>' gpg: searching for "...@..." from hkp server blackhole.pca.dfn.de (1) .... <...@...> 1024 bit DSA key 4DA565F9, created: 2004-06-01 (2) ... <...@...> .... <...@...> 1024 bit DSA key 7108E308, created: 2002-01-14 When I try to search directly for the second key id above, I get the following failure: gpg --search-keys --keyserver hkp://blackhole.pca.dfn.de 0x7108E308 gpg: searching for "0x7108E308" from hkp server blackhole.pca.dfn.de gpg: key "0x7108E308" not found on keyserver Using the http interface of the key server properly returns the key when I enter the key id. Using any other key server, I get the same results. I am pretty sure this /did/ work with earlier versions of GnuPG. Any idea what goes wrong here? Cheers, Albrecht. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Albrecht Dre? - Johanna-Kirchner-Stra?e 13 - D-53123 Bonn (Germany) Phone (+49) 228 6199571 - mailto:albrecht.dress@arcor.de GnuPG public key: http://www.mynetcologne.de/~nc-dreszal/pubkey.asc _________________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20061119/ceedd97e/attachment.pgp From news at kfwebs.net Sun Nov 19 16:11:35 2006 From: news at kfwebs.net (Kristian Fiskerstrand) Date: Sun Nov 19 16:09:59 2006 Subject: Odd keyserver problem In-Reply-To: <1163948165l.3378l.0l@antares.localdomain> References: <1163948165l.3378l.0l@antares.localdomain> Message-ID: <45607427.9020106@kfwebs.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Albrecht Dre? wrote, On 11/19/2006 03:55 PM: > Hi all, > > I have an odd problem searching for a key on a HKP keyserver using GnuPG > 1.4.5. Searching for a key using the mail address works fine (name & > address removed for privacy): ... snip ... > Using the http interface of the key server properly returns the key when > I enter the key id. Using any other key server, I get the same > results. I am pretty sure this /did/ work with earlier versions of > GnuPG. Any idea what goes wrong here? > Generally when knowing the key ID you'd just use gpg --recv-key 0x7108E308 though. - -- - ---------------------------- Kristian Fiskerstrand http://www.kfwebs.net - ---------------------------- http://www.secure-my-email.com http://www.secure-my-internet.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.0 (GNU/Linux) iQIVAwUBRWB0Jhbgz41rC5UIAQgefQ//cLlZpn71HOrTAzBI+ipvxtbVrS6xIkkI 3AheFtGUAMYb7/nJREReOxGnTIqseWEJZ1eie11bV3oi0scwvgu2lXedMowbbdVp 4GUzUPJWz5yIzRViZvp9D+un8xOhvnsINGfWMVR7paA1fywM0KSapRYCiuNgW4sz VGXeDaIjG4MO6zlLbcFOr5xL3BM8NN2ixwt7lOijEuBzy8dB6BUAsx2MoZ8kyZst PIgbi0ZehN9Ie4JJBdCFd3MOPk4onDqi9N3aIXzJZKrRMpvGuw5V0Mpg8oLuWmqV zmmW3/oFKKDUnpkMT3wWH5CcT/vhPeJ1efnBBVB9g8E93CST7gPOG4xN6Xyrds6j HB4xBYJX4AtTHFjwmWM6JePjeL2U4E/Ca39aML3K4bOJi1nQ/KVQC1CS1RUe7kjz mxpDAZ+8tkEE6WT0/Ww1Spddh5nzuko+0IkOEr4WY1YZr8r8MHkS6ZtxhvLWPpST EccTtAg9PQc1VjZk7w8nXolSBNzeGi6IFpfuJgX4nFQDBaqjVzuxp6BXQnyGrxC4 tJFow+alZwtBTPKeYWapuNBnGzy+PPUps9o3zJiltQtdqk8XrP3oGnl6kR8T9sSH kDPWoLem2YDDKp7aOEGFzOhPeZBy+ZeL0xBmFK3GRw2SHMEJvQZp4F2cLC54I8g+ BBqRRT/jKt4= =HME4 -----END PGP SIGNATURE----- From wk at gnupg.org Tue Nov 21 10:27:19 2006 From: wk at gnupg.org (Werner Koch) Date: Tue Nov 21 10:32:05 2006 Subject: [PATCH] Put pcsc-wrapper in libexecdir In-Reply-To: <20061118230129.GB4519@nightcrawler.kuroneko.ca> (Eric Dorland's message of "Sat\, 18 Nov 2006 18\:01\:29 -0500") References: <20061118230129.GB4519@nightcrawler.kuroneko.ca> Message-ID: <87odr15evc.fsf@wheatstone.g10code.de> On Sun, 19 Nov 2006 00:01, eric@debian.org said: > I believe the pcsc-wrapper program should go into libexecdir rather > than pkglibdir. Patch is below and the rationale from the GNU Coding You are right. Thanks, Werner From wk at gnupg.org Tue Nov 21 11:04:13 2006 From: wk at gnupg.org (Werner Koch) Date: Tue Nov 21 11:06:47 2006 Subject: [gpgme] set gpg options In-Reply-To: <455D6243.6030100@gmx.net> (Timo Schulz's message of "Fri\, 17 Nov 2006 08\:18\:27 +0100") References: <455D6243.6030100@gmx.net> Message-ID: <87fycd5d5u.fsf@wheatstone.g10code.de> On Fri, 17 Nov 2006 08:18, twoaday@gmx.net said: > The reason is, that if somebody calls gpgme_set_textmode(false), he > wants to disable the textmode and wants to skip possible settings in > the gpg.conf. With the current style, the mode is not supressed, but > only not used. That is an API change and thus we can't do it. The only problem I can see with it is that someone has textmode in his gpg.conf. However that is a bad idea anyway. Putting unresonable options into gpg.conf may break all kind of things. Salam-Shalom, Werner From wk at gnupg.org Thu Nov 23 12:26:28 2006 From: wk at gnupg.org (Werner Koch) Date: Thu Nov 23 13:03:14 2006 Subject: GnuPG 2.0.1rc1 released Message-ID: <87slgacskb.fsf@wheatstone.g10code.de> Hi, I did a release candidate for GnuPG 2.0.1. It fixes the problems on AMD64 as well as on 64 bit platforms. There are also some other build fixes. ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-2.0.1rc1.tar.bz2 ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-2.0.1rc1.tar.bz2.sig You should also get an updated libassuan version: ftp://ftp.gnupg.org/gcrypt/libassuan/libassuan-1.0.1.tar.bz2 ftp://ftp.gnupg.org/gcrypt/libassuan/libassuan-1.0.1.tar.bz2.sig Noteworthy changes in GnuPG: * Experimental support for the PIN pads of the SPR 532 and the Kaan Advanced card readers. Add "disable-keypad" scdaemon.conf if you don't want it. Does currently only work for the OpenPGP card and the authentication and decrypt keys. * Fixed build problems on some some platforms and crashes on amd64. Noteworthy changes in libassuan 1.0.1: * New function: assuan_set_io_monitor. * New function: assuan_register_post_cmd_notify. * Fixed a memory leak. Shalom-Salam, Werner From wk at gnupg.org Thu Nov 23 15:41:03 2006 From: wk at gnupg.org (Werner Koch) Date: Thu Nov 23 15:47:04 2006 Subject: Logo ballot reminder Message-ID: <8764d6b4zk.fsf@wheatstone.g10code.de> Hi, this is a reminder for the logo ballot. All subscribers of the gnupg-users and gnupg-devel lists should have received a mail (unfortunately text/html) with an URL to the ballot page. If you miss such a mail, please let me know and I will resend this mail. As of now only 151 out of 1230 casted their vote. Hurry, the deadline is next Thursday. Salam-Shalom, Werner From albrecht.dress at arcor.de Sat Nov 25 17:46:13 2006 From: albrecht.dress at arcor.de (=?iso-8859-1?q?Albrecht_Dre=DF?=) Date: Sat Nov 25 17:44:57 2006 Subject: GnuPG 2.0 vs. 1.4 locale; gpgme_set_locale Message-ID: <1164473182l.8316l.0l@antares.localdomain> Hi all, I have two related questions regarding the locale treatment in gnupg and gpgme. After upgrading from gnupg 1.4 to 2.0 I noticed that the behaviour of passing strings to pinentry changed if I e.g. just type "gpg --sign" on the terminal. The following table lists the locale settings, the encoding of the strings printed on the terminal and the encoding of the strings passed to pinentry: Application | terminal locale | terminal output | pinentry strings ------------+------------------+------------------+----------------- gnupg 1.4 | de_DE.ISO-8859-1 | de_DE.ISO-8859-1 | *de_DE.UTF-8* gnupg 1.4 | de_DE.UTF-8 | de_DE.UTF-8 | de_DE.UTF-8 gnupg 2.0 | de_DE.ISO-8859-1 | de_DE.ISO-8859-1 | *de_DE.ISO-8859-1* gnupg 2.0 | de_DE.UTF-8 | de_DE.UTF-8 | de_DE.UTF-8 Both versions use the agent and the Gtk+-2.0 pinentry version. As my environment is still set to latin1, pinentry gets confused if it gets a string containing /mixed/ character sets where the message is in latin1 ("Sie ben?tigen eine Passphrase...), but the description of my key ("Albrecht Dre?") is in utf-8. Launching the agent with LC_ALL set to de_DE.UTF-8 makes things even worse as it calls pinentry with this setting, and then pinentry has no clue how it should call iconv to convert the latin1 string properly. Shouldn't the conversation between gnupg and the agent always be in utf-8? If not, gnupg /must/ ensure that the strings contain characters from only /one/ encoding. However, IMHO exclusively using utf-8 is the better solution as key descriptions may contain characters from any codeset. The second question is how gpgme treats gpgme_set_locale() when I call the gnupg backend. I mainly use gpg through the Gnome MUA balsa, which talks to gnupg through gpgme. In balsa, I tried to explicitly set a gpgme utf-8 locale, but apparently this setting isn't fed through to gpg, i.e. it still runs with my "normal" (Latin-1) environment. A quick glance over the source shows that (in posix-io.c) a execv() call is used instead of execve(). How are the locales set in gpgme are supposed to work? Cheers, Albrecht. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Albrecht Dre? - Johanna-Kirchner-Stra?e 13 - D-53123 Bonn (Germany) Phone (+49) 228 6199571 - mailto:albrecht.dress@arcor.de GnuPG public key: http://www.mynetcologne.de/~nc-dreszal/pubkey.asc _________________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20061125/a9763fce/attachment.pgp From marcus.brinkmann at ruhr-uni-bochum.de Mon Nov 27 12:35:46 2006 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Mon Nov 27 13:33:42 2006 Subject: GnuPG 2.0 vs. 1.4 locale; gpgme_set_locale In-Reply-To: <1164473182l.8316l.0l@antares.localdomain> References: <1164473182l.8316l.0l@antares.localdomain> Message-ID: <1164627347.5009.4.camel@localhost> On Sat, 2006-11-25 at 17:46 +0100, Albrecht Dre? wrote: > I have two related questions regarding the locale treatment in gnupg and > gpgme. > > After upgrading from gnupg 1.4 to 2.0 I noticed that the behaviour of > passing strings to pinentry changed if I e.g. just type "gpg --sign" on > the terminal. The following table lists the locale settings, the encoding > of the strings printed on the terminal and the encoding of the strings > passed to pinentry: > > Application | terminal locale | terminal output | pinentry strings > ------------+------------------+------------------+----------------- > gnupg 1.4 | de_DE.ISO-8859-1 | de_DE.ISO-8859-1 | *de_DE.UTF-8* > gnupg 1.4 | de_DE.UTF-8 | de_DE.UTF-8 | de_DE.UTF-8 > gnupg 2.0 | de_DE.ISO-8859-1 | de_DE.ISO-8859-1 | *de_DE.ISO-8859-1* > gnupg 2.0 | de_DE.UTF-8 | de_DE.UTF-8 | de_DE.UTF-8 > > Both versions use the agent and the Gtk+-2.0 pinentry version. As my > environment is still set to latin1, pinentry gets confused if it gets a > string containing /mixed/ character sets where the message is in latin1 > ("Sie ben?tigen eine Passphrase...), but the description of my key > ("Albrecht Dre?") is in utf-8. Launching the agent with LC_ALL set to > de_DE.UTF-8 makes things even worse as it calls pinentry with this > setting, and then pinentry has no clue how it should call iconv to convert > the latin1 string properly. > > Shouldn't the conversation between gnupg and the agent always be in utf-8? Yes, I think so. That it isn't above for GnuPG 2.0 seems to be a bug. Can you file a report at bugs.g10code.com? > If not, gnupg /must/ ensure that the strings contain characters from only > /one/ encoding. However, IMHO exclusively using utf-8 is the better > solution as key descriptions may contain characters from any codeset. > > The second question is how gpgme treats gpgme_set_locale() when I call the > gnupg backend. I mainly use gpg through the Gnome MUA balsa, which talks > to gnupg through gpgme. In balsa, I tried to explicitly set a gpgme utf-8 > locale, but apparently this setting isn't fed through to gpg, i.e. it > still runs with my "normal" (Latin-1) environment. A quick glance over > the source shows that (in posix-io.c) a execv() call is used instead of > execve(). How are the locales set in gpgme are supposed to work? The locale setting is currently only honored for gpgsm, see engine-gpgsm.c:gpgsm_new(). The main idea behind gpgme_set_locale is to set GPGME to the same locale as the application (which GPGME can't do for you because of thread safety issues). I don't mind supporting locale setting for GnuPG. Do you want to work out a patch? Otherwise it will probably be done when we run GnuPG in server mode as well. Thanks, Marcus From wk at gnupg.org Mon Nov 27 18:13:02 2006 From: wk at gnupg.org (Werner Koch) Date: Mon Nov 27 20:14:26 2006 Subject: [Announce] GnuPG 1.4 and 2.0 buffer overflow Message-ID: <87mz6cke3l.fsf@wheatstone.g10code.de> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From albrecht.dress at arcor.de Mon Nov 27 21:08:52 2006 From: albrecht.dress at arcor.de (=?iso-8859-1?q?Albrecht_Dre=DF?=) Date: Mon Nov 27 21:07:32 2006 Subject: GnuPG 2.0 vs. 1.4 locale; gpgme_set_locale In-Reply-To: <1164627347.5009.4.camel@localhost> (from marcus.brinkmann@ruhr-uni-bochum.de on Mon Nov 27 12:35:46 2006) Message-ID: <1164658142l.3273l.0l@antares.localdomain> Am 27.11.06 12:35 schrieb(en) Marcus Brinkmann: > Yes, I think so. That it isn't above for GnuPG 2.0 seems to be a bug. > Can you file a report at bugs.g10code.com? See https://bugs.g10code.com/gnupg/issue734 > I don't mind supporting locale setting for GnuPG. Do you want to work > out a patch? Otherwise it will probably be done when we run GnuPG in > server mode as well. That shouldn't be too difficult - basically make a copy of environ, but omit LC_*, replacing them by the values set in gpgme, then call execve() and free the array in the parent, right? I can do that if it is not urgent (read: probably next weekend or so). Cheers, Albrecht. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Albrecht Dre? - Johanna-Kirchner-Stra?e 13 - D-53123 Bonn (Germany) Phone (+49) 228 6199571 - mailto:albrecht.dress@arcor.de GnuPG public key: http://www.mynetcologne.de/~nc-dreszal/pubkey.asc _________________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20061127/b72a5440/attachment.pgp From bart at inGen.be Thu Nov 23 09:27:45 2006 From: bart at inGen.be (bart@inGen.be) Date: Mon Nov 27 21:32:02 2006 Subject: make check-TESTS fails Message-ID: <20061123082745.GA77179@inGen.be> Hi, I'm trying to install gnupg-1.9.20-r3 on a gentoo machine, via the stable ebuild in portage. this is on a x86 machine. compilation seems to succees, but the testing always fails at the same place: [...] >>> Source compiled. >>> Test phase [check]: app-crypt/gnupg-1.9.20-r3 Making check in m4 make[1]: Entering directory `/var/tmp/portage/gnupg-1.9.20-r3/work/gnupg-1.9.20/m4' make[1]: Nothing to be done for `check'. make[1]: Leaving directory `/var/tmp/portage/gnupg-1.9.20-r3/work/gnupg-1.9.20/m4' Making check in intl make[1]: Entering directory `/var/tmp/portage/gnupg-1.9.20-r3/work/gnupg-1.9.20/intl' make[1]: Nothing to be done for `check'. make[1]: Leaving directory `/var/tmp/portage/gnupg-1.9.20-r3/work/gnupg-1.9.20/intl' Making check in gl make[1]: Entering directory `/var/tmp/portage/gnupg-1.9.20-r3/work/gnupg-1.9.20/gl' make check-am make[2]: Entering directory `/var/tmp/portage/gnupg-1.9.20-r3/work/gnupg-1.9.20/gl' make[2]: Nothing to be done for `check-am'. make[2]: Leaving directory `/var/tmp/portage/gnupg-1.9.20-r3/work/gnupg-1.9.20/gl' make[1]: Leaving directory `/var/tmp/portage/gnupg-1.9.20-r3/work/gnupg-1.9.20/gl' Making check in jnlib make[1]: Entering directory `/var/tmp/portage/gnupg-1.9.20-r3/work/gnupg-1.9.20/jnlib' make[1]: Nothing to be done for `check'. make[1]: Leaving directory `/var/tmp/portage/gnupg-1.9.20-r3/work/gnupg-1.9.20/jnlib' Making check in common make[1]: Entering directory `/var/tmp/portage/gnupg-1.9.20-r3/work/gnupg-1.9.20/common' make[1]: Nothing to be done for `check'. make[1]: Leaving directory `/var/tmp/portage/gnupg-1.9.20-r3/work/gnupg-1.9.20/common' Making check in kbx make[1]: Entering directory `/var/tmp/portage/gnupg-1.9.20-r3/work/gnupg-1.9.20/kbx' make[1]: Nothing to be done for `check'. make[1]: Leaving directory `/var/tmp/portage/gnupg-1.9.20-r3/work/gnupg-1.9.20/kbx' Making check in sm make[1]: Entering directory `/var/tmp/portage/gnupg-1.9.20-r3/work/gnupg-1.9.20/sm' make[1]: Nothing to be done for `check'. make[1]: Leaving directory `/var/tmp/portage/gnupg-1.9.20-r3/work/gnupg-1.9.20/sm' Making check in agent make[1]: Entering directory `/var/tmp/portage/gnupg-1.9.20-r3/work/gnupg-1.9.20/agent' make check-TESTS make[2]: Entering directory `/var/tmp/portage/gnupg-1.9.20-r3/work/gnupg-1.9.20/agent' PASS: t-protect ================== All 1 tests passed ================== make[2]: Leaving directory `/var/tmp/portage/gnupg-1.9.20-r3/work/gnupg-1.9.20/agent' make[1]: Leaving directory `/var/tmp/portage/gnupg-1.9.20-r3/work/gnupg-1.9.20/agent' Making check in tools make[1]: Entering directory `/var/tmp/portage/gnupg-1.9.20-r3/work/gnupg-1.9.20/tools' make[1]: Nothing to be done for `check'. make[1]: Leaving directory `/var/tmp/portage/gnupg-1.9.20-r3/work/gnupg-1.9.20/tools' Making check in po make[1]: Entering directory `/var/tmp/portage/gnupg-1.9.20-r3/work/gnupg-1.9.20/po' make[1]: Nothing to be done for `check'. make[1]: Leaving directory `/var/tmp/portage/gnupg-1.9.20-r3/work/gnupg-1.9.20/po' Making check in doc make[1]: Entering directory `/var/tmp/portage/gnupg-1.9.20-r3/work/gnupg-1.9.20/doc' make check-am make[2]: Entering directory `/var/tmp/portage/gnupg-1.9.20-r3/work/gnupg-1.9.20/doc' make[2]: Nothing to be done for `check-am'. make[2]: Leaving directory `/var/tmp/portage/gnupg-1.9.20-r3/work/gnupg-1.9.20/doc' make[1]: Leaving directory `/var/tmp/portage/gnupg-1.9.20-r3/work/gnupg-1.9.20/doc' Making check in tests make[1]: Entering directory `/var/tmp/portage/gnupg-1.9.20-r3/work/gnupg-1.9.20/tests' make check-TESTS make[2]: Entering directory `/var/tmp/portage/gnupg-1.9.20-r3/work/gnupg-1.9.20/tests' FAIL: sm-sign+verify PASS: sm-verify ====================================== 1 of 2 tests failed Please report to gnupg-devel@gnupg.org ====================================== make[2]: *** [check-TESTS] Error 1 make[2]: Leaving directory `/var/tmp/portage/gnupg-1.9.20-r3/work/gnupg-1.9.20/tests' make[1]: *** [check-am] Error 2 make[1]: Leaving directory `/var/tmp/portage/gnupg-1.9.20-r3/work/gnupg-1.9.20/tests' make: *** [check-recursive] Error 1 !!! ERROR: app-crypt/gnupg-1.9.20-r3 failed. Call stack: ebuild.sh, line 1546: Called dyn_test ebuild.sh, line 986: Called src_test ebuild.sh, line 616: Called die !!! Make check failed. See above for details. !!! If you need support, post the topmost build error, and the call stack if relevant. If necessary. I can also file a bug at the Gentoo Bugzilla. -- regards, Bart Van Loon You can present the material, but you can't make me care. -- Calvin From ca+gnupg at esmtp.org Mon Nov 27 19:46:28 2006 From: ca+gnupg at esmtp.org (Claus Assmann) Date: Mon Nov 27 21:32:06 2006 Subject: [Announce] GnuPG 1.4 and 2.0 buffer overflow In-Reply-To: <87mz6cke3l.fsf@wheatstone.g10code.de> References: <87mz6cke3l.fsf@wheatstone.g10code.de> Message-ID: <20061127184627.GA3638@zardoc.esmtp.org> > + n = strlen(s) + (defname?strlen (defname):0) + 10; > prompt = xmalloc(n); > if( defname ) > sprintf(prompt, "%s [%s]: ", s, defname ); Wouldn't it be more secure to replace sprintf with snprintf (and the proper length restriction of course)? snprintf(prompt, n, "%s [%s]: ", s, defname ); (same for strcpy() -> strlcpy(), strcat() -> strlcat(), etc). From wk at gnupg.org Tue Nov 28 09:04:00 2006 From: wk at gnupg.org (Werner Koch) Date: Tue Nov 28 09:06:53 2006 Subject: GnuPG 2.0 vs. 1.4 locale; gpgme_set_locale In-Reply-To: <1164658142l.3273l.0l@antares.localdomain> (Albrecht =?utf-8?Q?Dre=C3=9F's?= message of "Mon\, 27 Nov 2006 21\:08\:52 +0100") References: <1164658142l.3273l.0l@antares.localdomain> Message-ID: <87vel0gfpr.fsf@wheatstone.g10code.de> On Mon, 27 Nov 2006 21:08, albrecht.dress@arcor.de said: > That shouldn't be too difficult - basically make a copy of environ, but > omit LC_*, replacing them by the values set in gpgme, then call execve() > and free the array in the parent, right? I can do that if it is not > urgent (read: probably next weekend or so). It is actually easier: We have the options --display --ttyname --ttytype --lc-ctype --lc-messages To override the values from the environment. Just pass them to gpg (>= 1.3.0). Salam-Shalom, Werner From wk at gnupg.org Tue Nov 28 09:17:37 2006 From: wk at gnupg.org (Werner Koch) Date: Tue Nov 28 09:22:04 2006 Subject: [Announce] GnuPG 1.4 and 2.0 buffer overflow In-Reply-To: <20061127184627.GA3638@zardoc.esmtp.org> (Claus Assmann's message of "Mon\, 27 Nov 2006 10\:46\:28 -0800") References: <87mz6cke3l.fsf@wheatstone.g10code.de> <20061127184627.GA3638@zardoc.esmtp.org> Message-ID: <87r6vogf32.fsf@wheatstone.g10code.de> On Mon, 27 Nov 2006 19:46, ca+gnupg@esmtp.org said: > Wouldn't it be more secure to replace sprintf with snprintf > (and the proper length restriction of course)? > > snprintf(prompt, n, "%s [%s]: ", s, defname ); Actually I did this in the 2.0 SVN. However by the time I wrote that code, snprintf was not available on all platforms and even worse existing implementations had bugs, like forgetting to append a Nul. > (same for strcpy() -> strlcpy(), strcat() -> strlcat(), etc). No. I consider the OpenSBD approach flawed. Simply cutting off strings helps agains buffer overflows but there are other problems: You increase the complexity of the code because you need to track to string termination conditions. You change what the code does and somewhere else you run into problems because important properties of the cut-off string are missing. Think of an API which takes the presence of a keyword to encrypt or not to encrypt the output. The code using strlcpy might be used to skip over comments and voila you have a neat way of controlling a remote application. If you want protection against buffer overflow, audit the code and use an OS which traps execution of code at arbitrary addresses. Shalom-Salam, Werner From wk at gnupg.org Tue Nov 28 09:19:24 2006 From: wk at gnupg.org (Werner Koch) Date: Tue Nov 28 09:22:08 2006 Subject: make check-TESTS fails In-Reply-To: <20061123082745.GA77179@inGen.be> (bart@inGen.be's message of "Thu\, 23 Nov 2006 09\:27\:45 +0100") References: <20061123082745.GA77179@inGen.be> Message-ID: <87mz6cgf03.fsf@wheatstone.g10code.de> On Thu, 23 Nov 2006 09:27, bart@inGen.be said: > I'm trying to install gnupg-1.9.20-r3 on a gentoo machine, via the > stable ebuild in portage. this is on a x86 machine. 1.9.20 is too old. Please try 2.0.0 or better wait a day or two until 2.0.1 has been released. Salam-Shalom, Werner From rjh at sixdemonbag.org Tue Nov 28 09:32:27 2006 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue Nov 28 09:30:26 2006 Subject: [Announce] GnuPG 1.4 and 2.0 buffer overflow In-Reply-To: <87r6vogf32.fsf@wheatstone.g10code.de> References: <87mz6cke3l.fsf@wheatstone.g10code.de> <20061127184627.GA3638@zardoc.esmtp.org> <87r6vogf32.fsf@wheatstone.g10code.de> Message-ID: <456BF41B.1010509@sixdemonbag.org> Werner Koch wrote: > If you want protection against buffer overflow, audit the code and > use an OS which traps execution of code at arbitrary addresses. A different approach would be to use a language in which buffer overflows are simply not possible. Ada95 is an example of a language which compiles to fast native code and has robust protections against buffer overflow. Following this thread further would probably go very much off-topic for gnupg-devel, but the contrary view--that C is simply the wrong language to use for security-critical software--should at least be mentioned, I think. (Note: Ada95 is used as an example. I'm not actually suggesting GnuPG should be, or should have been, written in it.) From wk at gnupg.org Tue Nov 28 09:43:53 2006 From: wk at gnupg.org (Werner Koch) Date: Tue Nov 28 09:46:51 2006 Subject: [Announce] GnuPG 1.4 and 2.0 buffer overflow In-Reply-To: <456BF41B.1010509@sixdemonbag.org> (Robert J. Hansen's message of "Tue\, 28 Nov 2006 02\:32\:27 -0600") References: <87mz6cke3l.fsf@wheatstone.g10code.de> <20061127184627.GA3638@zardoc.esmtp.org> <87r6vogf32.fsf@wheatstone.g10code.de> <456BF41B.1010509@sixdemonbag.org> Message-ID: <87ac2cgdva.fsf@wheatstone.g10code.de> On Tue, 28 Nov 2006 09:32, rjh@sixdemonbag.org said: > overflows are simply not possible. Ada95 is an example of a language > which compiles to fast native code and has robust protections against > buffer overflow. Unless you disable them which is often done for performance reasons ;-). We can't change the implementation language: It is too much work and there are not enough developers available which are up to Ada. > gnupg-devel, but the contrary view--that C is simply the wrong language > to use for security-critical software--should at least be mentioned, I C is used everywhere and before you start to change all applications you need to change the underlying infrastructure. That huge and constantly changing Linux kernel needs to be targeted too. Salam-Shalom, Werner From rjh at sixdemonbag.org Tue Nov 28 09:56:31 2006 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue Nov 28 09:54:21 2006 Subject: [Announce] GnuPG 1.4 and 2.0 buffer overflow In-Reply-To: <87ac2cgdva.fsf@wheatstone.g10code.de> References: <87mz6cke3l.fsf@wheatstone.g10code.de> <20061127184627.GA3638@zardoc.esmtp.org> <87r6vogf32.fsf@wheatstone.g10code.de> <456BF41B.1010509@sixdemonbag.org> <87ac2cgdva.fsf@wheatstone.g10code.de> Message-ID: <456BF9BF.30308@sixdemonbag.org> Werner Koch wrote: > Unless you disable them which is often done for performance reasons > ;-). Bjarne Stroustrup once characterized this as "wearing your life jacket while your boat is close to shore, but throwing it overboard once you start to cross the ocean". While I agree it's often done for performance reasons, I think it's an open question as to whether it should be done. Ninety percent of the time when coders talk about 'performance reasons', what we really mean is 'we haven't profiled the code yet, so here are our wild guesses as to what will work'. If the code's been profiled, array access is a bottleneck, and you can give strong promises that the array access will not go out of bounds, then fine, disable array checks. Otherwise, it seems premature. > We can't change the implementation language: It is too much work and > there are not enough developers available which are up to Ada. Right. As I said, I used Ada95 as an example--not because I thought it was reasonable or practical for GnuPG to use it. > C is used everywhere and before you start to change all applications > you need to change the underlying infrastructure. That huge and > constantly changing Linux kernel needs to be targeted too. Yep. But I sincerely think that if we were to start migrating away from C except for those applications where C is absolutely necessary, it would do leaps and bounds for software reliability. From ca+gnupg-devel at esmtp.org Tue Nov 28 17:21:58 2006 From: ca+gnupg-devel at esmtp.org (Claus Assmann) Date: Tue Nov 28 17:24:06 2006 Subject: buffer overflow and snprintf/strlcpy In-Reply-To: <87r6vogf32.fsf@wheatstone.g10code.de> References: <87mz6cke3l.fsf@wheatstone.g10code.de> <20061127184627.GA3638@zardoc.esmtp.org> <87r6vogf32.fsf@wheatstone.g10code.de> Message-ID: <20061128162158.GA11107@zardoc.esmtp.org> On Tue, Nov 28, 2006, Werner Koch wrote: > On Mon, 27 Nov 2006 19:46, ca+gnupg@esmtp.org said: > > Wouldn't it be more secure to replace sprintf with snprintf > > (and the proper length restriction of course)? > Actually I did this in the 2.0 SVN. However by the time I wrote that > > (same for strcpy() -> strlcpy(), strcat() -> strlcat(), etc). > No. I consider the OpenSBD approach flawed. Simply cutting off > strings helps agains buffer overflows but there are other problems: I probably misunderstand you, but snprintf() and strlcpy() behave the same in that matter, don't they? strlcpy(dst, src, size); is basically the same as snprintf(dst, size, "%s", src); and in both cases you check the return value to see whether the "dst" string was large enough to hold the "src" string. Auditing the code is fine, but humans have the tendency to make mistakes :-( If you are sure that the "dst" string is large enough for a strcpy() function than you may as well use an assertion after a strlcpy() to let the code check that you were right. From albrecht.dress at arcor.de Tue Nov 28 20:30:53 2006 From: albrecht.dress at arcor.de (=?iso-8859-1?q?Albrecht_Dre=DF?=) Date: Tue Nov 28 20:29:57 2006 Subject: GnuPG 2.0 vs. 1.4 locale; gpgme_set_locale In-Reply-To: <87vel0gfpr.fsf@wheatstone.g10code.de> (from wk@gnupg.org on Tue Nov 28 09:04:00 2006) Message-ID: <1164742278l.21919l.0l@antares.localdomain> Am 28.11.06 09:04 schrieb(en) Werner Koch: > It is actually easier: We have the options > > --display > --ttyname > --ttytype > --lc-ctype > --lc-messages > > To override the values from the environment. Just pass them to gpg > (>= 1.3.0). That is actually trivial, and I already have a patch for gpgme. However, it doesn't work... I have the agent launched with locale de_DE (i.e. Latin1). When I run gpg 2.0.0 from a command line, also in locale de_DE, with the following command gpg --lc-ctype de_DE.UTF-8 --lc-messages de_DE.UTF-8 --sign --armor pinentry comes up, but still with a wrong string! I dumped the input string, and here is what I get: Sie ben?tigen eine Passphrase, um den geheimen Schl?ssel zu entsperren. Benutzer: "Albrecht Dre?? (NetCologne) " 1024-bit DSA Schl?ssel, ID D027FFD1, erzeugt 2002-04-15 The information string is still in Latin1 (e.g. ? == 0xf6), but the key information is in utf-8 (e.g. ? == 0xc39f). Replace the same command above with gpg-1.4, and the /complete/ string is properly encoded in utf8 (i.e. ? == 0xc3b6). Any ideas? Cheers, Albrecht. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Albrecht Dre? - Johanna-Kirchner-Stra?e 13 - D-53123 Bonn (Germany) Phone (+49) 228 6199571 - mailto:albrecht.dress@arcor.de GnuPG public key: http://www.mynetcologne.de/~nc-dreszal/pubkey.asc _________________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20061128/5d19caa9/attachment.pgp From harakiri_23 at yahoo.com Wed Nov 29 00:28:29 2006 From: harakiri_23 at yahoo.com (Harakiri) Date: Wed Nov 29 02:24:04 2006 Subject: gnupg + keyrings = thread safe? Message-ID: <199195.16453.qm@web52202.mail.yahoo.com> I read somewhere (i cant recall sorry) that gnupg locks internally each keyring it uses (i.e. for sign/decrypt). I figured, if gnupg uses the same keyring for multiple processes - some processes do indeed return "no key found" or similar on a multi threaded envirenment. Is creating temporary keyring files the best option here ? i.e. copy them from a master file prior to use ? Why does this happend ? For read process locking shouldnt be needed.. Thanks ____________________________________________________________________________________ Want to start your own business? Learn how on Yahoo! Small Business. http://smallbusiness.yahoo.com/r-index From wk at gnupg.org Tue Nov 28 20:37:07 2006 From: wk at gnupg.org (Werner Koch) Date: Wed Nov 29 11:06:37 2006 Subject: GnuPG 2.0 vs. 1.4 locale; gpgme_set_locale In-Reply-To: <1164742278l.21919l.0l@antares.localdomain> (Albrecht =?utf-8?Q?Dre=C3=9F's?= message of "Tue\, 28 Nov 2006 20\:30\:53 +0100") References: <1164742278l.21919l.0l@antares.localdomain> Message-ID: <87ejrnbbx8.fsf@wheatstone.g10code.de> On Tue, 28 Nov 2006 20:30, albrecht.dress@arcor.de said: > Any ideas? Once we had similar problems with gpgsm. I will check the code. Shalom-Salam, Werner From wk at gnupg.org Wed Nov 29 11:18:06 2006 From: wk at gnupg.org (Werner Koch) Date: Wed Nov 29 11:21:35 2006 Subject: buffer overflow and snprintf/strlcpy In-Reply-To: <20061128162158.GA11107@zardoc.esmtp.org> (Claus Assmann's message of "Tue\, 28 Nov 2006 08\:21\:58 -0800") References: <87mz6cke3l.fsf@wheatstone.g10code.de> <20061127184627.GA3638@zardoc.esmtp.org> <87r6vogf32.fsf@wheatstone.g10code.de> <20061128162158.GA11107@zardoc.esmtp.org> Message-ID: <87wt5ev9nl.fsf@wheatstone.g10code.de> On Tue, 28 Nov 2006 17:21, ca+gnupg-devel@esmtp.org said: > I probably misunderstand you, but snprintf() and strlcpy() behave > the same in that matter, don't they? Depends on the format string. A format is often too complex to easily figure out a maximum length. > If you are sure that the "dst" string is large enough for a strcpy() > function than you may as well use an assertion after a strlcpy() > to let the code check that you were right. If I am sure I don't need an assert ;-) But then I can also use a simple loop which makes testing for a premature terminatiion much easier. But it is not that expressive. Shalom-Salam, Werner From alphasigmax at gmail.com Wed Nov 29 13:01:58 2006 From: alphasigmax at gmail.com (Alphax) Date: Wed Nov 29 13:01:09 2006 Subject: FreeBSD ports for libassuan 1.0.1 and gnupg 2.0.1 In-Reply-To: <456D5A54.5070900@dougbarton.us> References: <456D5A54.5070900@dougbarton.us> Message-ID: <456D76B6.8010905@gmail.com> Doug Barton wrote: > For FreeBSD users eager to get started with the new versions, I'm told > that the official ports will be updated "soon." They are just waiting > on a repo copy of the old gnupg-devel port, and the CVS folks are a > bit backlogged right now. > > Meanwhile, I've updated my unofficial patches. The libassuan patch is > at http://dougbarton.us/libassuan.diff, and should apply cleanly to > the existing port. For gnupg, 'cd /usr/ports/security && cp -Rp > gnupg-devel gnupg2 && cd gnupg2 && patch < gnupg2.diff'. You can find > the patch at http://dougbarton.us/gnupg2.diff. > (cc-ed to gnupg-devel instead of -users) This might seem like a dumb question, but is there any specific reason why a specific patch is needed? Can't extra configure/make/#ifdef rules be added? -- Alphax Death to all fanatics! Down with categorical imperative! OpenPGP key: http://tinyurl.com/lvq4g -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 569 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20061129/4edb3c17/signature.pgp From christianbiere at gmx.de Wed Nov 29 11:52:42 2006 From: christianbiere at gmx.de (Christian Biere) Date: Wed Nov 29 13:26:19 2006 Subject: [Announce] GnuPG 1.4 and 2.0 buffer overflow Message-ID: <20061129105242.GB29560@cyclonus> "How I wish C-90 had introduced asprintf or at least it would be available on more platforms." Who needs printf-like functions to concatenate a bunch of strings? It's trivial to write a function similar to asprintf() that takes no format string but simply a variable number of string arguments to be concatened into a newly allocated buffer. The issue here was clearly the precalculation of the assumed string length which is simply unnecessary. Also, asprintf() returns an int instead of size_t. Yet another library function broken by design. -- Christian From wk at gnupg.org Wed Nov 29 14:55:45 2006 From: wk at gnupg.org (Werner Koch) Date: Wed Nov 29 15:26:31 2006 Subject: [Announce] GnuPG 2.0.1 released Message-ID: <877ixetl0e.fsf@wheatstone.g10code.de> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From wk at gnupg.org Wed Nov 29 15:28:13 2006 From: wk at gnupg.org (Werner Koch) Date: Wed Nov 29 15:33:46 2006 Subject: [Announce] GnuPG 1.4 and 2.0 buffer overflow In-Reply-To: <20061129105242.GB29560@cyclonus> (Christian Biere's message of "Wed\, 29 Nov 2006 11\:52\:42 +0100") References: <20061129105242.GB29560@cyclonus> Message-ID: <87psb6s4xu.fsf@wheatstone.g10code.de> On Wed, 29 Nov 2006 11:52, christianbiere@gmx.de said: > similar to asprintf() that takes no format string but simply a variable number of string arguments Well in that concrete case that would be a good idea. However the sentinel attribute is only available since gcc 4 and in the past it was common to miss the terminating NULL in the arg list ;-) In general such a function will not help as it gets into the way when doing i18n. > Also, asprintf() returns an int instead of size_t. Yet another library function broken by design. This is perfectly reasonable. How would you return an error code with size_t? Salam-Shalom, Werner From wk at gnupg.org Wed Nov 29 15:34:33 2006 From: wk at gnupg.org (Werner Koch) Date: Wed Nov 29 15:36:44 2006 Subject: FreeBSD ports for libassuan 1.0.1 and gnupg 2.0.1 In-Reply-To: <456D76B6.8010905@gmail.com> (alphasigmax@gmail.com's message of "Wed\, 29 Nov 2006 22\:31\:58 +1030") References: <456D5A54.5070900@dougbarton.us> <456D76B6.8010905@gmail.com> Message-ID: <87lklus4na.fsf@wheatstone.g10code.de> On Wed, 29 Nov 2006 13:01, alphasigmax@gmail.com said: > This might seem like a dumb question, but is there any specific reason > why a specific patch is needed? Can't extra configure/make/#ifdef rules > be added? Not even needed, libassuan builds out of the box: http://g10code.com/autobuild/libassuan-1.0.1.tar.gz-x86-freebsd1-output.html There are some problems left with gnupg but they are mainly due to problems with NLS. Passing --disable-nls should help. To solve these NLS problems, I consider to remove the included gettext from gnupg2 and all the other libraries. Shalom-Salam, Werner From christianbiere at gmx.de Wed Nov 29 17:32:43 2006 From: christianbiere at gmx.de (Christian Biere) Date: Wed Nov 29 17:27:07 2006 Subject: [Announce] GnuPG 1.4 and 2.0 buffer overflow In-Reply-To: <87psb6s4xu.fsf@wheatstone.g10code.de> References: <20061129105242.GB29560@cyclonus> <87psb6s4xu.fsf@wheatstone.g10code.de> Message-ID: <20061129163243.GB2685@cyclonus> Werner Koch wrote: > On Wed, 29 Nov 2006 11:52, christianbiere@gmx.de said: > > > similar to asprintf() that takes no format string but simply a variable number of string arguments > > Well in that concrete case that would be a good idea. However the > sentinel attribute is only available since gcc 4 and in the past it > was common to miss the terminating NULL in the arg list ;-) Sure, but assuming you're at least half-consistent about your coding style, a very simple script (awk, Perl, whatever) could be used to check for this. Also there are always typical mistakes the compiler won't check for. Calculating a buffer size can be very tricky and is well-known to be error-prone. Forgetting some terminator or typing "," instead of ";" and whatnot happens too but it's not that tricky. Also compilers with format string checks haven't been around forever either and many code still is ignorant of this GCC feature. Even with these format checks, bugs might be unnoticed for example if people pass a size_t, pid_t or whatever implementation-defined type as %d (or %u). There might be absolutely no warnings on the developer's machine. So the format string solution has much more issues whereas the other one has mainly two: forgetting to terminate the list with "(void *) 0" and accidently passing a parameter that is NULL but that's easy to prevent and easy to check statically. > In general such a function will not help as it gets into the way when > doing i18n. Yes, unfortunately but not in this case and restricting printf-like printing to those cases where it's needed or rather the straight-forward solution (i18n implies pretty-printing) seems like a good practice. Also replacement implementations for snprintf() have been around for years and vsnprintf() can be used to write your own asprintf() in about 5 lines. This should even work with the non-C99 variant, it just requires multiple passes. If library functions are buggy, that's sad but really not your problem. The library vendor should be screwed for that. > > Also, asprintf() returns an int instead of size_t. Yet another library > > function broken by design. > This is perfectly reasonable. How would you return an error code with > size_t? (size_t)-1 or ASPRINTF_ERROR? -- Christian From wk at gnupg.org Wed Nov 29 15:12:56 2006 From: wk at gnupg.org (Werner Koch) Date: Wed Nov 29 18:42:27 2006 Subject: [Announce] Dirmngr 1.0.0 released Message-ID: <87u00is5nb.fsf@wheatstone.g10code.de> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From dshaw at jabberwocky.com Thu Nov 30 04:21:43 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Thu Nov 30 04:20:21 2006 Subject: [Announce] First release candidate for 1.4.6 available Message-ID: <20061130032143.GA6518@jabberwocky.com> We are pleased to announce the availability of the first release candidate for the forthcoming 1.4.6 version of GnuPG: ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.4.6rc1.tar.bz2 (3.0M) ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.4.6rc1.tar.bz2.sig SHA-1 checksums for the above files are: c7fe6551350866af8509c3ba0666d1e69a1668cd gnupg-1.4.6rc1.tar.bz2 9a35c9b9a9544dd0b5afd91c6595655dca2c0b9c gnupg-1.4.6rc1.tar.bz2.sig Note that this is only a release candidate, and as such is not intended for use on production systems. If you are inclined to help test, however, we would appreciate you trying this new version and reporting any problems. Noteworthy changes since 1.4.5: * Fixed a bug while decrypting certain compressed and encrypted messages. [bug#537] * Fixed a buffer overflow in gpg. [bug#728] * Added --s2k-count to set the number of times passphrase mangling is repeated. The default is 65536 times. * Added a GPL license exception to the keyserver helper programs gpgkeys_ldap, gpgkeys_curl, and gpgkeys_hkp, to clarify any potential questions about the ability to distribute binaries that link to the OpenSSL library. GnuPG does not link directly to OpenSSL, but libcurl (used for HKP, HTTP, and FTP) and OpenLDAP (used for LDAP) may. Note that this license exception is considered a bug fix and is intended to forgive any violations pertaining to this issue, including those that may have occurred in the past. Happy Hacking, David, Timo, Werner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available Url : /pipermail/attachments/20061129/e4b20e35/attachment.pgp From sms at antinode.org Thu Nov 30 05:42:29 2006 From: sms at antinode.org (Steven M. Schweda) Date: Thu Nov 30 06:24:06 2006 Subject: [Announce] First release candidate for 1.4.6 available Message-ID: <06112922422987_2020028F@antinode.org> From: David Shaw > We are pleased to announce the availability of the first release > candidate for the forthcoming 1.4.6 version of GnuPG: > > ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.4.6rc1.tar.bz2 (3.0M) I'd've been more pleased to hear it if 1.4.6 contained any sign of the VMS-related changed I suggested for 1.4.5. Knowing nothing, I'd figure that this would be a good time to make changes of this sort. ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-org 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 From henman at it.to-be.co.jp Thu Nov 30 06:14:25 2006 From: henman at it.to-be.co.jp (djh) Date: Thu Nov 30 07:54:08 2006 Subject: Build Problem Message-ID: <20061130141425.2692@henman-np.b-eng.it.to-be.co.jp> I have run into a build problem. ./configure result: # GPGME v1.0.3 has been configured as follows: # GnuPG path: /usr/local/bin/gpg # GnuPG version: 1.4.5, min. 1.2.2 # GpgSM path: no # GpgSM version: unknown, min. 1.9.6 # GPGME Pthread: yes # GPGME Pth: I am not an expert in the utilities used to build gpgme. But, wonder why a library seems to be missing. Could this be a command line argument ordering problem?? Read below for more information: Thanks, D. Henman -------------------------------- Start # # Make problem (November 30, 2006): (see below) # (cd .libs && rm -f libgpgme.la && ln -s ../libgpgme.la libgpgme.la) if /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -MT ath-pthread.lo -MD -MP -MF ".deps/ath-pthread.Tpo" -c -o ath-pthread.lo ath-pthread.c; \ then mv -f ".deps/ath-pthread.Tpo" ".deps/ath-pthread.Plo"; else rm -f ".deps/ath-pthread.Tpo"; exit 1; fi gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -MT ath-pthread.lo -MD -MP -MF .deps/ath-pthread.Tpo -c ath-pthread.c -DPIC -o .libs/ath-pthread.o /bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -o libgpgme-pthread.la -rpath /usr/local/lib -version-info 15:0:4 ath-pthread.lo libgpgme-real.la stpcpy.lo memrchr.lo -lpthread -lgpg-error libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin shared libraries . . . Making all in tests make[2]: Entering directory `/usr/src/gpgme/gpgme-1.0.3/tests' Making all in gpg make[3]: Entering directory `/usr/src/gpgme/gpgme-1.0.3/tests/gpg' if gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../../gpgme -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -MT t-encrypt.o -MD -MP -MF ".deps/t-encrypt.Tpo" -c -o t-encrypt.o t-encrypt.c; \ then mv -f ".deps/t-encrypt.Tpo" ".deps/t-encrypt.Po"; else rm -f ".deps/t-encrypt.Tpo"; exit 1; fi /bin/sh ../../libtool --tag=CC --mode=link gcc -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -o t-encrypt.exe t-encrypt.o ../../gpgme/libgpgme.la mkdir .libs gcc -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -o t-encrypt.exe t-encrypt.o ../../gpgme/.libs/libgpgme.a /usr/lib/libgpg-error.dll.a -L/usr/lib /usr/lib/libintl.dll.a /usr/lib/libiconv.dll.a ../../gpgme/.libs/libgpgme.a(posix-sema.o): In posix-sema.c - undefined reference to `__gpgme_ath_mutex_destroy' - undefined reference to `__gpgme_ath_init' - undefined reference to `__gpgme_ath_mutex_lock' - undefined reference to `__gpgme_ath_mutex_unlock' - undefined reference to `__gpgme_ath_read' - undefined reference to `__gpgme_ath_write' - undefined reference to `__gpgme_ath_waitpid' - undefined reference to `__gpgme_ath_select' make[3]: *** [t-encrypt.exe] Error 1 make[3]: Leaving directory `/usr/src/gpgme/gpgme-1.0.3/tests/gpg' -------------------------------- END From wk at gnupg.org Thu Nov 30 08:57:32 2006 From: wk at gnupg.org (Werner Koch) Date: Thu Nov 30 09:01:42 2006 Subject: [Announce] First release candidate for 1.4.6 available In-Reply-To: <06112922422987_2020028F@antinode.org> (Steven M. Schweda's message of "Wed\, 29 Nov 2006 22\:42\:29 -0600 \(CST\)") References: <06112922422987_2020028F@antinode.org> Message-ID: <87lkltmknn.fsf@wheatstone.g10code.de> On Thu, 30 Nov 2006 05:42, sms@antinode.org said: > I'd've been more pleased to hear it if 1.4.6 contained any sign of > the VMS-related changed I suggested for 1.4.5. Knowing nothing, I'd > figure that this would be a good time to make changes of this sort. We have been working mainly on GnuGP 2 and thus there was no time to look at the VMS stuff. Due to the buffer overflow, we need to get out a 1.4.6 RSN. I will look at the VMS changes after that. Shalom-Salam, Werner From wk at gnupg.org Thu Nov 30 11:50:10 2006 From: wk at gnupg.org (Werner Koch) Date: Thu Nov 30 11:56:48 2006 Subject: [Announce] GnuPG 1.4 and 2.0 buffer overflow In-Reply-To: <20061129163243.GB2685@cyclonus> (Christian Biere's message of "Wed\, 29 Nov 2006 17\:32\:43 +0100") References: <20061129105242.GB29560@cyclonus> <87psb6s4xu.fsf@wheatstone.g10code.de> <20061129163243.GB2685@cyclonus> Message-ID: <87d575ky3h.fsf@wheatstone.g10code.de> On Wed, 29 Nov 2006 17:32, christianbiere@gmx.de said: > Also replacement implementations for snprintf() have been around for years > and vsnprintf() can be used to write your own asprintf() in about 5 lines. va_copy is not a standard function/macro and actually missing on a lot of systems or again buggy. Without that you can implement neither asprintf nor your proposed astrcat - unless you want to resort to realloc chains. Instead of repeating these old discussions over and over again, I wonder why people don't look at the code to figure out the flaws. A bug lurking for 7 years and not detected by thousands of eyeballs scrutinizing every line of free code? SCNR. Salam-Shalom, Werner From christianbiere at gmx.de Thu Nov 30 12:42:28 2006 From: christianbiere at gmx.de (Christian Biere) Date: Thu Nov 30 12:38:20 2006 Subject: [Announce] GnuPG 1.4 and 2.0 buffer overflow In-Reply-To: <87d575ky3h.fsf@wheatstone.g10code.de> References: <20061129105242.GB29560@cyclonus> <87psb6s4xu.fsf@wheatstone.g10code.de> <20061129163243.GB2685@cyclonus> <87d575ky3h.fsf@wheatstone.g10code.de> Message-ID: <20061130114228.GA26430@cyclonus> Werner Koch wrote: > > Also replacement implementations for snprintf() have been around for years > > and vsnprintf() can be used to write your own asprintf() in about 5 lines. > > va_copy is not a standard function/macro and actually missing on a lot Nonsense. Do you want to deny that ISO C99 is a standard? > of systems or again buggy. Then send bug reports or stop supporting these systems. Do you think it's alright to use flawed techniques just to "support" some broken and deprecated systems? This might be acceptable as a temporary workaround but not more. > Without that you can implement neither asprintf nor your proposed astrcat - > unless you want to resort to realloc chains. Indeed you don't need va_copy() at all. What is the problem with realloc()? Are you now going to argue with performance concerns? > Instead of repeating these old discussions over and over again, This can't be discussed often enough. Instead of repeating the same bugs over and over again, why don't you start to re-evaluate your tools? I'm not talking about C itself. > I wonder why people don't look at the code to figure out the flaws. A > bug lurking for 7 years and not detected by thousands of eyeballs > scrutinizing every line of free code? SCNR. Because that's just a myth created by some open-source zealots. I think most people have better things to do or maybe they are already busy with fixing other software. Also you get tired of this pretty fast if you see people repeating the same bugs. So you say it's a better idea to look for buffer overflows and other bugs, providing patches, just so that people can add these bugs again, instead of trying to tell them how they can avoid these in the first place? -- Christian From wk at gnupg.org Thu Nov 30 14:16:26 2006 From: wk at gnupg.org (Werner Koch) Date: Thu Nov 30 14:21:48 2006 Subject: [Announce] GnuPG 1.4 and 2.0 buffer overflow In-Reply-To: <20061130114228.GA26430@cyclonus> (Christian Biere's message of "Thu\, 30 Nov 2006 12\:42\:28 +0100") References: <20061129105242.GB29560@cyclonus> <87psb6s4xu.fsf@wheatstone.g10code.de> <20061129163243.GB2685@cyclonus> <87d575ky3h.fsf@wheatstone.g10code.de> <20061130114228.GA26430@cyclonus> Message-ID: <87ejrljcr9.fsf@wheatstone.g10code.de> On Thu, 30 Nov 2006 12:42, christianbiere@gmx.de said: > Nonsense. Do you want to deny that ISO C99 is a standard? We target C-90! There are only handful of systems with C-99 support (please don't look just at ggc, look alon at what systems each new gcc version does not anymore support). > Then send bug reports or stop supporting these systems. Do you think it's > alright to use flawed techniques just to "support" some broken and deprecated > systems? This might be acceptable as a temporary workaround but not more. Portability is actually a security feature. Only thinking Linux or BSD is narrow minded. > This can't be discussed often enough. Instead of repeating the same bugs over > and over again, why don't you start to re-evaluate your tools? I'm There are a lot of things which can be made better. However radical changes to a matured code basis are not an option. And you overlook the economic constrains: Get me financial support for documentation and code overhaul and I will start immediatley with it. I really wish I could do that. First of all I need to make a living; that is as important as to have access to a keyboard, monitor and the other hardware. > Because that's just a myth created by some open-source zealots. I think most You missed the irony in my statement. > repeating the same bugs. So you say it's a better idea to look for buffer > overflows and other bugs, providing patches, just so that people can add these > bugs again, instead of trying to tell them how they can avoid these in the It is not about tools or languages. It is about education and experience. Look at the polls done with first semester IT students: Most of them do not want to learn on porgramming, but to get a high paid manage job. Guess what most of them eventually do: Writing C++, Java and PHP code. Without being interested in the field of software architecture that leads to bad software. Today, you look at buffer overflows but theire are more severe bugs out in the wild. What about all these routers distributed by DSL providers which come with a default password and are accessible from the Net - a valueable resource to spammers. That is not a mere programming fault but one which is due to the management/QC/marketing. There are so many places to start with making software systems more matured. Nobody is even inteerested to do the simple things first. However, this is not the right place for such academic discussions. The folks at http://krvw.com/mailman/listinfo/sc-l are more interested in it. Salam-Shalom, Werner From dshaw at jabberwocky.com Thu Nov 30 15:34:45 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Thu Nov 30 15:32:46 2006 Subject: [Announce] First release candidate for 1.4.6 available In-Reply-To: <06112922422987_2020028F@antinode.org> References: <06112922422987_2020028F@antinode.org> Message-ID: <20061130143445.GB6518@jabberwocky.com> On Wed, Nov 29, 2006 at 10:42:29PM -0600, Steven M. Schweda wrote: > From: David Shaw > > > We are pleased to announce the availability of the first release > > candidate for the forthcoming 1.4.6 version of GnuPG: > > > > ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.4.6rc1.tar.bz2 (3.0M) > > I'd've been more pleased to hear it if 1.4.6 contained any sign of > the VMS-related changed I suggested for 1.4.5. Knowing nothing, I'd > figure that this would be a good time to make changes of this sort. I'm afraid I missed your original post. I'll take a look. It's not likely there will be changes in 1.4.6 before release though, given that it contains critical bug fixes. David From marcus.brinkmann at ruhr-uni-bochum.de Thu Nov 30 17:01:09 2006 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Thu Nov 30 16:58:11 2006 Subject: Build Problem In-Reply-To: <20061130141425.2692@henman-np.b-eng.it.to-be.co.jp> References: <20061130141425.2692@henman-np.b-eng.it.to-be.co.jp> Message-ID: <87wt5cx6t6.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Thu, 30 Nov 2006 14:14:25 +0900, "djh" wrote: > I have run into a build problem. > > ./configure result: > # GPGME v1.0.3 has been configured as follows: > # GnuPG path: /usr/local/bin/gpg > # GnuPG version: 1.4.5, min. 1.2.2 > # GpgSM path: no > # GpgSM version: unknown, min. 1.9.6 > # GPGME Pthread: yes > # GPGME Pth: > > > I am not an expert in the utilities used to build gpgme. But, wonder why a library seems to be missing. Could this be a command line argument ordering problem?? It seems libtool doesn't support your target architecture well enough for GPGME to build. You may want to contact the libtool people about that. We are using the mingw32 architecture, not cygwin, for our native Windows builds. Thanks, Marcus From christianbiere at gmx.de Thu Nov 30 17:05:27 2006 From: christianbiere at gmx.de (Christian Biere) Date: Thu Nov 30 16:59:46 2006 Subject: [Announce] GnuPG 1.4 and 2.0 buffer overflow In-Reply-To: <87d575ky3h.fsf@wheatstone.g10code.de> References: <20061129105242.GB29560@cyclonus> <87psb6s4xu.fsf@wheatstone.g10code.de> <20061129163243.GB2685@cyclonus> <87d575ky3h.fsf@wheatstone.g10code.de> Message-ID: <20061130160527.GA24093@cyclonus> Werner Koch wrote: > On Wed, 29 Nov 2006 17:32, christianbiere@gmx.de said: > > Also replacement implementations for snprintf() have been around for years > > and vsnprintf() can be used to write your own asprintf() in about 5 lines. > va_copy is not a standard function/macro and actually missing on a lot > of systems or again buggy. Without that you can implement neither > asprintf nor your proposed astrcat - unless you want to resort to > realloc chains. Just for the record: 99% of the time a local array to copy all members of va_list to will be just fine. The freely available ISO C99 draft even has example code for this in section 7.15. It's not C99-specific, it just shows it's a well-known practice and that va_copy() is virtually redundant. If you exceed this array, you'll have to resort to some dynamically allocated array. In pathologic cases, you might need realloc for this array. Very simple and straight-forward. I write this just in case anyone thought one would use realloc() here for appending strings. -- Christian From christianbiere at gmx.de Thu Nov 30 17:30:29 2006 From: christianbiere at gmx.de (Christian Biere) Date: Thu Nov 30 17:24:48 2006 Subject: [Announce] GnuPG 1.4 and 2.0 buffer overflow In-Reply-To: <87ejrljcr9.fsf@wheatstone.g10code.de> References: <20061129105242.GB29560@cyclonus> <87psb6s4xu.fsf@wheatstone.g10code.de> <20061129163243.GB2685@cyclonus> <87d575ky3h.fsf@wheatstone.g10code.de> <20061130114228.GA26430@cyclonus> <87ejrljcr9.fsf@wheatstone.g10code.de> Message-ID: <20061130163029.GB24093@cyclonus> Werner Koch wrote: > On Thu, 30 Nov 2006 12:42, christianbiere@gmx.de said: > Portability is actually a security feature. Only thinking Linux or > BSD is narrow minded. Actually, the "portability" argument supports my point of view because the printf() family is - as some would call it - "non-portable" due to the huge difference of implementations. So they are best avoided except for simple cases. Instead of working around missing features and bugs in those, it's best to use the same portable, easy-to-audit, non-error-prone functions for each platform. However, you have to differ. Some platforms support secure functions (which prevent race-conditions, for example) that are missing on others and cannot be replaced in userland because they require support by the kernel. In such cases, I would certainly not back-off to the unsafe variant just for portability but instead use the safer variant where possible. In case of GnuPG mlock() might be a good example. On Linux and many other systems it typically requires root-privileges, on BSD systems it doesn't instead there's a configurable limit. Also I don't think I qualify as BSD or Linux zealot because at the very least I read the manual pages at opengroup.org before I use a new feature and also those of IRIX and Solaris. However it's a shame that commercial vendors often provide a very poor flavour of Unix compared to the freely available variants. I wasn't actually asking you to rewrite or convert anything. My concern was that you discouraged use of asprintf() and this was part of the official announcement. Now asprintf() may not be the best choice. I just wanted to show that there are other options besides malloc() + sprintf() that can be considered. > It is not about tools or languages. It is about education and experience. > Look at the polls done with first semester IT students: Most of them do not > want to learn on porgramming, but to get a high paid manage job. Guess what > most of them eventually do: Writing C++, Java and PHP code. Without being > interested in the field of software architecture that leads to bad software. Agreed. However, don't blame it only on the students. I don't think you can learn C properly at a university because they're teaching Java nowadays and C or C++ courses are often of dubious quality. Also few have a clue about what to do with an IT graduate. They are frequently mistaken for "Programmer Gold Plus" albeit that often isn't their strength at all. -- Christian From harakiri_23 at yahoo.com Thu Nov 30 17:49:36 2006 From: harakiri_23 at yahoo.com (Harakiri) Date: Thu Nov 30 17:47:54 2006 Subject: Multithreaded Bug in GNUPG? - Sometimes Returns Exit Code 2 while decrypting Message-ID: <421497.70021.qm@web52215.mail.yahoo.com> On a multithreaded envirenment, when calling the gnupg binary multiple times, sometimes (2-3%) not 0 is returned for decryption but 2 and no further error messages. I was able to reproduce it with a simple script which would decrypt the same data everytime, this script was running in 20 threads for a while - and gnupg would return indeed the mysterious 2 on a debian sarge system. First i thought it was an issue with the keyrings and input data - so i made sure that for each thread a seperate copy of each file (secring, encrypted data) which will be used by GNUPG has been created - the same result happend - there seems to be a concurrency issue with gnupg - anyone could shed any insight to this ? Thanks ____________________________________________________________________________________ Cheap talk? Check out Yahoo! Messenger's low PC-to-Phone call rates. http://voice.yahoo.com From wk at gnupg.org Thu Nov 30 19:16:37 2006 From: wk at gnupg.org (Werner Koch) Date: Thu Nov 30 19:21:39 2006 Subject: [Announce] GnuPG 1.4 and 2.0 buffer overflow In-Reply-To: <20061130163029.GB24093@cyclonus> (Christian Biere's message of "Thu\, 30 Nov 2006 17\:30\:29 +0100") References: <20061129105242.GB29560@cyclonus> <87psb6s4xu.fsf@wheatstone.g10code.de> <20061129163243.GB2685@cyclonus> <87d575ky3h.fsf@wheatstone.g10code.de> <20061130114228.GA26430@cyclonus> <87ejrljcr9.fsf@wheatstone.g10code.de> <20061130163029.GB24093@cyclonus> Message-ID: <87hcwgiyuy.fsf@wheatstone.g10code.de> On Thu, 30 Nov 2006 17:30, christianbiere@gmx.de said: > Actually, the "portability" argument supports my point of view because the > printf() family is - as some would call it - "non-portable" due to the huge Of course you may only use the C-90 defined format elements. Things like size_t and off_t are problem of course. > read the manual pages at opengroup.org before I use a new feature and also > those of IRIX and Solaris. However it's a shame that commercial vendors often > provide a very poor flavour of Unix compared to the freely available variants. For some functions that is true. However, there are lot of older systems in use and they won't get replaced in the near future. The vendor can't do anything but to provide important bug fixes. API changes are not possible. > Agreed. However, don't blame it only on the students. I don't think you can That was not my intention. Of course, the teachers are responsible. Salam-Shalom, Werner From wk at gnupg.org Thu Nov 30 19:22:01 2006 From: wk at gnupg.org (Werner Koch) Date: Thu Nov 30 19:26:39 2006 Subject: Multithreaded Bug in GNUPG? - Sometimes Returns Exit Code 2 while decrypting In-Reply-To: <421497.70021.qm@web52215.mail.yahoo.com> (harakiri_23@yahoo.com's message of "Thu\, 30 Nov 2006 08\:49\:36 -0800 \(PST\)") References: <421497.70021.qm@web52215.mail.yahoo.com> Message-ID: <87d574iyly.fsf@wheatstone.g10code.de> On Thu, 30 Nov 2006 17:49, harakiri_23@yahoo.com said: > On a multithreaded envirenment, when calling the gnupg > binary multiple times, sometimes (2-3%) not 0 is GnuPG 1.4 is not multithreaded. So this can't be an issue. > returned for decryption but 2 and no further error > messages. If you run several processes at once on the same keyring, locking might timeout and thus you see the failure. It is also possible that file locking failed and thus you get an error return. This may for example be due to problems with the file system. Please provide system, version and log information and a way to replicate it. Shalom-Salam, Werner From rjh at sixdemonbag.org Thu Nov 30 21:52:26 2006 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu Nov 30 21:50:34 2006 Subject: [Announce] GnuPG 1.4 and 2.0 buffer overflow In-Reply-To: <20061130163029.GB24093@cyclonus> References: <20061129105242.GB29560@cyclonus> <87psb6s4xu.fsf@wheatstone.g10code.de> <20061129163243.GB2685@cyclonus> <87d575ky3h.fsf@wheatstone.g10code.de> <20061130114228.GA26430@cyclonus> <87ejrljcr9.fsf@wheatstone.g10code.de> <20061130163029.GB24093@cyclonus> Message-ID: <456F448A.6020703@sixdemonbag.org> Christian Biere wrote: > Agreed. However, don't blame it only on the students. I don't think > you can learn C properly at a university because they're teaching > Java nowadays and C or C++ courses are often of dubious quality. This has almost always been the case. University programming courses are almost always taught by either professors who haven't been in the real world in over a decade, or graduate students who have yet to enter the real world. Grad students who are coming in from the private sector are fairly rare. University IT departments also typically are reluctant to support CS departments properly. At the university I'm at, it takes an act of God to get them to create a CVS repository for a class. IT tends to want to treat us as if we've got the exact same IT needs as Classical Languages or Theater Arts, because it's easier for them that way. From dougb at dougbarton.us Wed Nov 29 19:35:02 2006 From: dougb at dougbarton.us (Doug Barton) Date: Fri Dec 1 13:31:17 2006 Subject: FreeBSD ports for libassuan 1.0.1 and gnupg 2.0.1 In-Reply-To: <87lklus4na.fsf@wheatstone.g10code.de> References: <456D5A54.5070900@dougbarton.us> <456D76B6.8010905@gmail.com> <87lklus4na.fsf@wheatstone.g10code.de> Message-ID: <456DD2D6.3000501@dougbarton.us> Werner Koch wrote: > On Wed, 29 Nov 2006 13:01, alphasigmax@gmail.com said: > >> This might seem like a dumb question, but is there any specific reason >> why a specific patch is needed? Can't extra configure/make/#ifdef rules >> be added? > > Not even needed, libassuan builds out of the box: Sorry for the misunderstanding. If you were to take a look at the patches I posted you would see that they are not to the libassuan or gnupg2 sources, they are for the FreeBSD ports. Our ports are similar to source RPMs. Werner is correct that no patches are needed to the sources for either to build on FreeBSD. > There are some problems left with gnupg but they are mainly due to > problems with NLS. Passing --disable-nls should help. Hrrm, I always build without NLS, but I just tested gnupg2 without that configure flag and it builds and runs just fine on FreeBSD, FYI. BTW, I'm still seeing the "Warning: using insecure memory!" error, in spite of having the no-secmem-warning option in my gpg.conf. I'm still willing to help debug that if Werner can give me some pointers. Doug -- If you're never wrong, you're not trying hard enough From neilm at debian.org Thu Nov 30 13:10:34 2006 From: neilm at debian.org (Neil McGovern) Date: Fri Dec 1 13:31:35 2006 Subject: Issue #728: gpg segfaults on 'af' byte - CVE-ified :) Message-ID: <20061130121034.GT16330@mx0.halon.org.uk> Hi all, WRT: https://bugs.g10code.com/gnupg/issue728 , the Debian Security team have received a CVE ID for your tracking pleasure: CVE-2006-6169 Many thanks, Neil McGovern (ps: please cc, I'm not subscribed) -- A. Because it breaks the logical sequence of discussion Q. Why is top posting bad? gpg key - http://www.halon.org.uk/pubkey.txt ; the.earth.li B345BDD3