From wk at gnupg.org Mon Aug 3 14:02:19 2009 From: wk at gnupg.org (Werner Koch) Date: Mon, 03 Aug 2009 14:02:19 +0200 Subject: Poldi feature suggestion In-Reply-To: <20090730181600.GA13159@capsaicin.mamane.lu> (Lionel Elie Mamane's message of "Thu, 30 Jul 2009 20:16:00 +0200") References: <20090730181600.GA13159@capsaicin.mamane.lu> Message-ID: <87ab2humus.fsf@wheatstone.g10code.de> On Thu, 30 Jul 2009 20:16, lionel at mamane.lu said: > Low priority: > +* allow user to skip card authentication without submitting a wrong > + PIN to the card, e.g. by entering an empty PIN? Return > + PAM_CRED_INSUFFICIENT in that case? PAM_AUTHINFO_UNAVAIL? PAM_AUTH_ERR? Applied ;-). Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Mon Aug 3 14:09:54 2009 From: wk at gnupg.org (Werner Koch) Date: Mon, 03 Aug 2009 14:09:54 +0200 Subject: Poldi bug report: allow non-digit PIN In-Reply-To: <20090730174934.GC12475@capsaicin.mamane.lu> (Lionel Elie Mamane's message of "Thu, 30 Jul 2009 19:49:34 +0200") References: <20090730174934.GC12475@capsaicin.mamane.lu> Message-ID: <874ospumi5.fsf@wheatstone.g10code.de> On Thu, 30 Jul 2009 19:49, lionel at mamane.lu said: > My OpenPGP smartcard has non-digits in its PIN, so it needs poldi to > allow that. Please use only digits. You would get into severe trouble if you switch to a keypad reader. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Mon Aug 3 14:13:20 2009 From: wk at gnupg.org (Werner Koch) Date: Mon, 03 Aug 2009 14:13:20 +0200 Subject: Poldi bug report: absence of DISables (not ENables) x509 support In-Reply-To: <20090730105136.GA5801@capsaicin.mamane.lu> (Lionel Elie Mamane's message of "Thu, 30 Jul 2009 12:51:36 +0200") References: <20090730105136.GA5801@capsaicin.mamane.lu> Message-ID: <87r5vtt7rz.fsf@wheatstone.g10code.de> On Thu, 30 Jul 2009 12:51, lionel at mamane.lu said: > -*** libksba not found, building with X.509 authentication support. > +*** libksba not found, building without X.509 authentication support. Fixed. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Mon Aug 3 14:14:20 2009 From: wk at gnupg.org (Werner Koch) Date: Mon, 03 Aug 2009 14:14:20 +0200 Subject: Poldi bug report: hangs indefinitely when no card inserted In-Reply-To: <20090730173836.GA12475@capsaicin.mamane.lu> (Lionel Elie Mamane's message of "Thu, 30 Jul 2009 19:38:36 +0200") References: <20090730173836.GA12475@capsaicin.mamane.lu> Message-ID: <87my6ht7qb.fsf@wheatstone.g10code.de> Hi, For the other bugs we better wait for Moritz. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Mon Aug 3 14:12:50 2009 From: wk at gnupg.org (Werner Koch) Date: Mon, 03 Aug 2009 14:12:50 +0200 Subject: Poldi bug report: version of the GPL In-Reply-To: <20090730103235.GB5457@capsaicin.mamane.lu> (Lionel Elie Mamane's message of "Thu, 30 Jul 2009 12:32:35 +0200") References: <20090730103235.GB5457@capsaicin.mamane.lu> Message-ID: <87y6q1t7st.fsf@wheatstone.g10code.de> On Thu, 30 Jul 2009 12:32, lionel at mamane.lu said: > The file COPYING is version 2 of the GPL, but a pseudo-random sampling > of .c/.h files in the source says GNU GPL v3 or later, thus v2 not > allowed. Indeed, it is GPLv3. I changed the file. However there is no problem with some files saying GPLv2+ (v2 or later) because v3 is surely later than v2. -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From amul.shah at fnis.com Mon Aug 3 19:58:36 2009 From: amul.shah at fnis.com (Amul Shah) Date: Mon, 03 Aug 2009 13:58:36 -0400 Subject: Adding support for z/OS in gnupg and related libraries In-Reply-To: <87k51qqnln.fsf@wheatstone.g10code.de> References: <4A7097AB.9080705@fnis.com> <87k51qqnln.fsf@wheatstone.g10code.de> Message-ID: <4A77254C.1090604@fnis.com> comments inline: On 07/30/2009 09:58 AM, Werner Koch wrote: > On Wed, 29 Jul 2009 20:40, amul.shah at fnis.com said: > > >> Please excuse the cross-post. Some of the hoops that I jumped through >> > > gnupg-devel is fine. We can drop gcrypt-devel. > [amul:2] thanks >> gnupg 1.4.9 >> libgpg-errors 1.7 >> libgcrypt 1.4.4 >> libgpgme 1.1.8 >> > > Is there a reason why you work on 1.4.x and libgcrypt? Libgcrypt is > only required for 2.x. > [amul:2] We are using both libgcrypt and gpg. Ideally I would have compiled gpg 2.x, but we have had better success on various platforms (AIX, Solaris, HPUX) with 1.4.x. We had issues compiling some of the libraries needed for the 2.x version. >> Services. The platform's native character encoding (aka code page or >> code set) is not ASCII, but EBCDIC. The US dialect of EBCDIC is >> > > FWIW, once upon a time gpg had some limited support for EBCDIC but that > was later dropped. > [amul:2] IMHO, after the port we just went through, it's best to compile Unix applications as ASCII and let z/OS do its conversion magic. Working with Unicode adds another layer of complexity. >> USS program are compiled as 31bit EBCDIC with no Unicode capabilities. >> > > What does USS mean in this context? > [amul:2] sorry, USS means "Unix System Services", one of the names the POSIX environment goes by. See the following link for more information. http://www-03.ibm.com/servers/eserver/zseries/zos/unix/ >> autotools is weak. Where I wanted to build shared libraries, I compiled >> archives. I unpacked the archives and converted them to shared libs >> > > Support for shared libraries needs to be added to libtool; that is a > wrapper to abstarct the building of shared libs. It is quite possible > that it does not yet support zOS - I have not checked. > [amul:2] I spent some time with libtool, but I didn't write down what I tried. I'll get back to you with some more information. >> Configuration options: >> ./configure CC=xlc CFLAGS="-qchars=signed -qascii -q64 -qlanglvl=extc99 >> -qexportall -qrent -qnocsect -W l,DLL -D_XOPEN_SOURCE=600 >> -D_ENHANCED_ASCII_EXT=0xFFFFFFFF -D_IEEEV1_COMPATIBILITY >> -D_OPEN_MSGQ_EXT" LD=xlc LDFLAGS="-qascii -q64 -W l,DLL" CXX=xlc++ >> --enable-shared --prefix=/usr/local >> > > In general those required options should go into configure.ac. We can > test there for the zOS and apply specific options. > [amul:2] configure.ac is my area of inexperience. > What is the reason that you used CC=xls? Is there another C compiler > which can't be used? The configure script should be able to detect the > compiler. > [amul:2] I don't recall what happened when I didn't specify a compiler CC option. Will let you know after I check it. >> There is an issue with the xlc configuration that defaults to picking up >> include files from '.' (current working directory) and /usr/include >> before picking up command line options. Since the z/OS system has two >> headers with the same name as headers in libgcrypt, we link them into >> > > Doesn't xlc support the -I option? "-I ." should pick up the packages > header files first. > [amul:2] xlc supports "-I", but it picks up those options _after_ its default search path. Confused me to no end when I was trying to compile. There are xlc configuration options that you can customize (like having a .bashrc, but for xlc) to fix this. >> -- gnupg-1.4.9 >> Apply the attached patch gnupg-1.4.9.patch which applies to gnupg >> 1.4.9. I will need help migrating this to the v2 line of gnupg >> > > Is your target GnuPG-1.4 or GnuPG-2? If at all possible I would suggest > to target GnuPG-2. > [amul:2] For now it's GnuPG-1.4. :( As I mentioned before we had compilation problems on a bunch of platforms. >> Configuration options: >> ./configure CC=xlc CFLAGS="-qchars=signed -qascii -q64 -qlanglvl=extc99 >> -qexportall -qrent -qnocsect -W l,DLL -D_XOPEN_SOURCE=600 >> -D_ENHANCED_ASCII_EXT=0xFFFFFFFF -D_IEEEV1_COMPATIBILITY >> -D_OPEN_MSGQ_EXT" LD=xlc LDFLAGS="-qascii -q64 -W l,DLL" CXX=xlc++ >> --without-pth --without-libassuan --without-ksba --prefix=/usr/local >> > > The --without-* options are not needed but they don't harm for 1.4. > --prefix=/usr/local is anyway the default. > [amul:2] Good to know. I was following configuration options used by someone else to compile GPG + libs on other platforms. >> -- Generating Shared Libs from archives >> > > Weel, we need to look into libtool. > [amul:2] ok. >> diff -purN gnupg-1.4.9.orig/checks/conventional-mdc.test gnupg-1.4.9.working-20090430/checks/conventional-mdc.test >> --- gnupg-1.4.9.orig/checks/conventional-mdc.test Tue Oct 23 04:53:20 2007 >> +++ gnupg-1.4.9.working-20090430/checks/conventional-mdc.test Wed Apr 29 16:29:29 2009 >> @@ -9,8 +9,10 @@ for ciph in `all_cipher_algos`; do >> # *BSD's dd can't cope with a count of 0 >> if test "$i" = "0"; then >> : >z >> + chtag -tc ISO8859-1 z >> > > This is a platform specific tool. It needs to be changed to a shell > fucntion which figures out the the latform and calls it only if needed. > Not a big deal. > [amul:2] so something like an alias that is a nop on other platforms would do the trick. >> diff -purN gnupg-1.4.9.orig/g10/gpg.c gnupg-1.4.9.working-20090430/g10/gpg.c >> --- gnupg-1.4.9.orig/g10/gpg.c Thu Mar 20 05:06:43 2008 >> +++ gnupg-1.4.9.working-20090430/g10/gpg.c Thu Apr 30 13:02:17 2009 >> @@ -18,6 +18,7 @@ >> * along with this program; if not, see . >> */ >> >> +#include "platform_pragma.h" >> #include >> > > This platform_pragma.h file should be included by config.h so that > there is no need to chnage all source files. config.h is created by > configure. > [amul:2] I'll move that to confih.h. >> --- gnupg-1.4.9.orig/g10/Makefile.in Wed Mar 26 13:30:47 2008 >> +++ gnupg-1.4.9.working-20090430/g10/Makefile.in Thu Apr 30 10:05:30 2009 >> > Don't chnage Makefile.in; the source is Makefile.am. > > >> clean-generic: >> + rm -f *.dbg *.x >> > > This is done using a CLEAN target in Makefile.am > [amul:2] Ok, I'll take a look at the Makefile.am. >> +/* platform_pragma.h - platform specific pragmas >> + * Copyright (C) 2009 Fidelity Information Services, Inc >> > > One imortant point to get your code into GnuPG. We require copyright > assignments to the FSF. We should discuss the terms off-list. > [amul:2] sure, we can do that. I thought saying that the code is GPL is good enough. >> diff -purN gnupg-1.4.9.orig/intl/bindtextdom.c gnupg-1.4.9.working-20090430/intl/bindtextdom.c >> --- gnupg-1.4.9.orig/intl/bindtextdom.c Tue Oct 23 05:25:01 2007 >> +++ gnupg-1.4.9.working-20090430/intl/bindtextdom.c Mon Apr 27 14:38:32 2009 >> > > These are files installed from the gettext package. It is possible to > change that in GnuPG but the next time we update the gettext stuff it > will be lost. Thus it needs to be integrated into gettext proper. > [amul:2] The below project right? http://www.gnu.org/software/gettext/ [amul:2] I'll make sure I send that project a patch. >> +int zos_getpccsid(int fd) >> +{ >> > > The GNU project uses a different indendation; The important part is > to align the function name to the first column: > > int > zos_getpccsid(int fd) > { > [amul:2] Thanks. For future reference, here's the link. I should have thought about that. http://www.gnu.org/prep/standards/html_node/Formatting.html >> diff -purN gnupg-1.4.9.orig/util/Makefile.in gnupg-1.4.9.working-20090430/util/Makefile.in >> > > Well, Makefile.am ;-) > [amul:2] Yup. I'll fix that. :) >> diff -pruN libgcrypt-1.4.4.orig/src/ath.c libgcrypt-1.4.4.new/src/ath.c >> --- libgcrypt-1.4.4.orig/src/ath.c Wed Sep 3 06:04:42 2008 >> +++ libgcrypt-1.4.4.new/src/ath.c Thu Apr 30 11:16:28 2009 >> @@ -30,6 +30,9 @@ >> # include >> #endif >> #include >> +#if defined(__MVS__) >> +#include >> +#endif >> > > This is better handled using a configure test. > [amul:2] How would that work? thanks, Amul _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. _____________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Wed Aug 5 12:37:52 2009 From: wk at gnupg.org (Werner Koch) Date: Wed, 05 Aug 2009 12:37:52 +0200 Subject: 1024-3072 bit OpenPGP cards In-Reply-To: <877hy78xtu.fsf@wheatstone.g10code.de> (Werner Koch's message of "Fri, 17 Jul 2009 11:26:21 +0200") References: <877hy78xtu.fsf@wheatstone.g10code.de> Message-ID: <87d47ar1fj.fsf@wheatstone.g10code.de> Hi, I just commited code to allow selection of the key size. It works by always asking for the keyseize and presenting the current size as the default. A warning is shown once if you try to change the keysize. I don't think that a sepeare keysize command makes much sense now. Here is a sample session: Command> generate Make off-card backup of encryption key? (Y/n) gpg: NOTE: keys are already stored on the card! Replace existing keys? (y/N) y Please note that the factory settings of the PINs are PIN = `123456' Admin PIN = `12345678' You should change them using the command --change-pin What keysize do you want for the Signature key? (1024) 2048 The card will now be re-configured to generate a key of 2048 bits NOTE: There is no guarantee that the card supports the requested size. If the key generation does not succeed, please check the documentation of your card to see what sizes are allowed. What keysize do you want for the Encryption key? (2048) 1024 The card will be re-configured to generate a key of 1024 bits What keysize do you want for the Authentication key? (2048) Please specify how long the key should be valid. 0 = key does not expire = key expires in n days w = key expires in n weeks m = key expires in n months y = key expires in n years Key is valid for? (0) Key does not expire at all Is this correct? (y/N) y [...] A failure looks like this: [...] What keysize do you want for the Encryption key? (1024) 1530 rounded up to 1536 bits The card will now be re-configured to generate a key of 1536 bits NOTE: There is no guarantee that the card supports the requested size. If the key generation does not succeed, please check the documentation of your card to see what sizes are allowed. gpg: error changing size of key 2 to 1536 bits: Invalid value What keysize do you want for the Encryption key? (1024) 2048 The card will now be re-configured to generate a key of 2048 bits [...] The warning notice is printed in advance to cover the case that changing the key attributes does not report an error but the actual key generation fails at a later point. On a lower level you can change the keysize using gpg-connect-agent: $ gpg-connect-agent > /hex > scd serialno OK > scd setattr KEY-ATTR --force 3 1 1024 OK This deletes the authentication key from the card and prepares it for creatiion of a 1024 bit key. The "--force" ist used to prevent accidental key deletion. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Wed Aug 5 15:52:05 2009 From: wk at gnupg.org (Werner Koch) Date: Wed, 05 Aug 2009 15:52:05 +0200 Subject: Adding support for z/OS in gnupg and related libraries In-Reply-To: <4A77254C.1090604@fnis.com> (Amul Shah's message of "Mon, 03 Aug 2009 13:58:36 -0400") References: <4A7097AB.9080705@fnis.com> <87k51qqnln.fsf@wheatstone.g10code.de> <4A77254C.1090604@fnis.com> Message-ID: <878whyqsfu.fsf@wheatstone.g10code.de> On Mon, 3 Aug 2009 19:58, amul.shah at fnis.com said: > [amul:2] We are using both libgcrypt and gpg. Ideally I would have > compiled gpg 2.x, but we have had better success on various platforms > (AIX, Solaris, HPUX) with 1.4.x. We had issues compiling some of the > libraries needed for the 2.x version. GnuPG-2 requires a more modern Unix that GnuPG-1. That is not to say that Solaris, AIX and HPUX aren't modern Unices. There are just some little things which need to be adjusted and we usually don't have such a system for tests. > [amul:2] IMHO, after the port we just went through, it's best to compile > Unix applications as ASCII and let z/OS do its conversion magic. > Working with Unicode adds another layer of complexity. There must have been a reason that IBM added that magic ASCII support ;-). > [amul:2] sorry, USS means "Unix System Services", one of the names the > POSIX environment goes by. See the following link for more information. > http://www-03.ibm.com/servers/eserver/zseries/zos/unix/ Right. It is 10 years since I last worked a bit on a MVS and the USS (not sure whether it was already called this back then). > [amul:2] I spent some time with libtool, but I didn't write down what I > tried. I'll get back to you with some more information. Libtool is a nasty beast but it has the advantage that if you get it right for your platform all software can take advantage of it. > [amul:2] configure.ac is my area of inexperience. Just ask me or let me know what you need. > [amul:2] xlc supports "-I", but it picks up those options _after_ its > default search path. Confused me to no end when I was trying to > compile. There are xlc configuration options that you can customize > (like having a .bashrc, but for xlc) to fix this. I feared that. What about mangling the vac.cfg and passing a new one via -F to xlc. It might be possible to extract the -I option from that file build a new one and pass the extracted -I option on the command line after our own -I. It might fail if one of the system include files requires the system memory.h - bad. I think I once had a simialr problem with OS/2. So what about changing all #include "memory.h" to #include "../include/memory.h we might then need to change the name of the include directory as well. Would that work? Looking closer at it, this is a problem of gpg 1.4 and not one of libgcrypt. The strange thing is that libgcrypt includes a memory.h but does not provide one - thus the system memory.h is used. Must be a leftover from an earlier version. I will fix that in libgcrypt 1.5. > [amul:2] so something like an alias that is a nop on other platforms > would do the trick. Something like this (see the FIXME): =================================================================== --- defs.inc (revision 5106) +++ defs.inc (working copy) @@ -112,6 +112,16 @@ # cleanup_files="$cleanup_files $*" #} + +# Special fucntion for zOS. +my_chtag () { + #FIXME: Is there an envvar to test for the OS or do we + # need to resort to a configure test + #if test "$FOO" = "bar"; then + # chtag -tc ISO8859-1 $1 + #fi +} + have_pubkey_algo () { if ../g10/gpg --homedir . --version | grep "Pubkey:.*$1" >/dev/null then Index: conventional-mdc.test =================================================================== --- conventional-mdc.test (revision 5106) +++ conventional-mdc.test (working copy) @@ -9,6 +9,7 @@ # *BSD's dd can't cope with a count of 0 if test "$i" = "0"; then : >z + my_chtag z else dd if=data-80000 of=z bs=1 count=$i 2>/dev/null fi ================================ >>> +#include "platform_pragma.h" >>> #include >>> >> >> This platform_pragma.h file should be included by config.h so that >> there is no need to chnage all source files. config.h is created by >> configure. >> > > [amul:2] I'll move that to confih.h. That's done in configure.ac by adding a line to AH_TOP([ #ifndef GNUPG_CONFIG_H_INCLUDED #define GNUPG_CONFIG_H_INCLUDED ]) or using AH_VERBATIM. Easy. >> This is done using a CLEAN target in Makefile.am >> > > [amul:2] Ok, I'll take a look at the Makefile.am. You would add something like: CLEANFILES = prepared.stamp x y yy z out err $(DATA_FILES) \ plain-1 plain-2 plain-3 trustdb.gpg *.lock .\#lk* \ *.test.log gpg_dearmor gpg.conf \ pubring.gpg secring.gpg pubring.pkr secring.skr DISTCLEANFILES = pubring.gpg~ random_seed there is also a MOSTLEANFILES target. >> assignments to the FSF. We should discuss the terms off-list. >> > > [amul:2] sure, we can do that. I thought saying that the code is GPL is > good enough. The GNU project requires copyright assignments or dislaimers for all core software. Without that legal BS I may not include changes into the package (you may distrubute your own of course, but then you have the burden of maintaining it). Let's take this off-list. > [amul:2] The below project right? > http://www.gnu.org/software/gettext/ > > [amul:2] I'll make sure I send that project a patch. Right. It may take a while for a new release. In the meantime we can apply the patches to the copy in GnuPG. > [amul:2] Thanks. For future reference, here's the link. I should have > thought about that. > http://www.gnu.org/prep/standards/html_node/Formatting.html It is not a hard rule anyway and all authors have different tastes. I just make sure that some basic formatting is right. >> This is better handled using a configure test. >> > > [amul:2] How would that work? --- configure.ac (revision 1400) +++ configure.ac (working copy) @@ -571,7 +571,7 @@ ################################## AC_HEADER_STDC -AC_CHECK_HEADERS(unistd.h sys/select.h) +AC_CHECK_HEADERS(unistd.h sys/select.h sys/msg.h) ########################################## #### Checks for typedefs, structures, #### --- src/ath.h (revision 1400) +++ src/ath.h (working copy) @@ -32,6 +32,9 @@ # include # endif # include +# ifdef HAVE_SYS_MSG_H +# include /* (e.g. for zOS) */ +# endif # include #endif /* !_WIN32 */ #include Already commited. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From Moritz.Schulte at rub.de Sat Aug 8 14:06:15 2009 From: Moritz.Schulte at rub.de (Moritz Schulte) Date: 8 Aug 2009 14:06:15 +0200 Subject: Poldi bug report: allow non-digit PIN In-Reply-To: <874ospumi5.fsf@wheatstone.g10code.de> References: <20090730174934.GC12475@capsaicin.mamane.lu> <874ospumi5.fsf@wheatstone.g10code.de> Message-ID: <4A7D6A37.5020802@rub.de> >> My OpenPGP smartcard has non-digits in its PIN, so it needs poldi to >> allow that. > > Please use only digits. You would get into severe trouble if you switch > to a keypad reader. What does this mean for Poldi? Should Poldi _forbid_ the use of non-digit PINs or not? Maybe we should add a configuration option ("allow-non-digit-pins"?) to make it clear that using non-digit PINs might get you into trouble? Thanks, mo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 269 bytes Desc: OpenPGP digital signature URL: From mo at g10code.com Sat Aug 8 20:07:43 2009 From: mo at g10code.com (Moritz Schulte) Date: 8 Aug 2009 20:07:43 +0200 Subject: Poldi bug report: quieter, better prompts In-Reply-To: <20090730174627.GB12475@capsaicin.mamane.lu> References: <20090730174627.GB12475@capsaicin.mamane.lu> Message-ID: <4A7DBEEF.3020506@g10code.com> Dear Lionel, Regarding Poldi being rather chatty: that has already been changed in SVN trunk. I have reintroduced the "quiet" option a couple of weeks ago and protected several calls to conv_tell() by "if (!quiet)". I have applied the string substitutions you suggested. Thanks, mo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 269 bytes Desc: OpenPGP digital signature URL: From mo at g10code.com Sat Aug 8 20:01:53 2009 From: mo at g10code.com (Moritz Schulte) Date: 8 Aug 2009 20:01:53 +0200 Subject: Poldi bug report: better scdaemon handling In-Reply-To: <20090730175843.GE12475@capsaicin.mamane.lu> References: <20090730175843.GE12475@capsaicin.mamane.lu> Message-ID: <4A7DBD91.20606@g10code.com> Dear Lionel, in the SVN trunk of Poldi I have implemented an (experimental[0]) Poldi option named "scdaemon-options". This option can be used to specify the scdaemon configuration file to use for spawning new scdaemon instancens right in poldi.conf. I guess this is better than hard-coding the name of the configuration file. Regarding the stderr issue: I agree we better find a fix for this, but I'm not yet sure if the fix you proposed is the most appropriate one. I put this one my todo list. Thanks, mo [0] Needless to say, since _Poldi_ is still considered experimental. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 269 bytes Desc: OpenPGP digital signature URL: From peter at palfrader.org Mon Aug 10 20:41:43 2009 From: peter at palfrader.org (Peter Palfrader) Date: Mon, 10 Aug 2009 20:41:43 +0200 Subject: r5108 FTBFS without HAVE_LIBREADLINE Message-ID: <20090810184143.GE29091@anguilla.noreply.org> Hi, card-util.c: In function 'card_edit': card-util.c:1819: error: 'card_edit_completion' undeclared (first use in this function) card-util.c:1819: error: (Each undeclared identifier is reported only once card-util.c:1819: error: for each function it appears in.) card_edit_completion is only defined conditionally on HAVE_LIBREADLINE, but it's used unconditionally. Cheers, Peter -- | .''`. ** Debian GNU/Linux ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `- http://www.debian.org/ From dshaw at jabberwocky.com Tue Aug 11 19:24:21 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 11 Aug 2009 13:24:21 -0400 Subject: r5108 FTBFS without HAVE_LIBREADLINE In-Reply-To: <20090810184143.GE29091@anguilla.noreply.org> References: <20090810184143.GE29091@anguilla.noreply.org> Message-ID: <1C646B17-8431-46EA-A518-AA1BB1D3DF58@jabberwocky.com> On Aug 10, 2009, at 2:41 PM, Peter Palfrader wrote: > Hi, > > card-util.c: In function 'card_edit': > card-util.c:1819: error: 'card_edit_completion' undeclared (first > use in this function) > card-util.c:1819: error: (Each undeclared identifier is reported > only once > card-util.c:1819: error: for each function it appears in.) > > card_edit_completion is only defined conditionally on > HAVE_LIBREADLINE, > but it's used unconditionally. All fixed. David From wk at gnupg.org Mon Aug 10 19:47:07 2009 From: wk at gnupg.org (Werner Koch) Date: Mon, 10 Aug 2009 19:47:07 +0200 Subject: Poldi bug report: allow non-digit PIN In-Reply-To: <4A7D6A37.5020802@rub.de> (Moritz Schulte's message of "8 Aug 2009 14:06:15 +0200") References: <20090730174934.GC12475@capsaicin.mamane.lu> <874ospumi5.fsf@wheatstone.g10code.de> <4A7D6A37.5020802@rub.de> Message-ID: <87fxbzblyc.fsf@wheatstone.g10code.de> On Sat, 8 Aug 2009 14:06, Moritz.Schulte at rub.de said: > What does this mean for Poldi? Should Poldi _forbid_ the use of > non-digit PINs or not? Maybe we should add a configuration option > ("allow-non-digit-pins"?) to make it clear that using non-digit PINs > might get you into trouble? In GnuPG we do these checks /* do some basic checks on the entered PIN. */ if (!all_digitsp (pininfo->pin)) errtext = _("Invalid characters in PIN"); else if (pininfo->max_digits && strlen (pininfo->pin) > pininfo->max_digits) errtext = _("PIN too long"); else if (strlen (pininfo->pin) < pininfo->min_digits) errtext = _("PIN too short"); if asking for a PIN via Pinentry. MIN_MAXDIGITS are 0/16. This is in the generic code; the actual smartcard application code in scdaemon may even be more restrictive. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Thu Aug 13 10:37:33 2009 From: wk at gnupg.org (Werner Koch) Date: Thu, 13 Aug 2009 10:37:33 +0200 Subject: [Announce] Gpg4win 2.0.0 has been released Message-ID: <87bpmk6rea.fsf@wheatstone.g10code.de> Hi! Building and installing GnuPG on the Microsoft Windows platform is more complicated than doing this on a Unix platform. To help users we are providing binary versions of GnuPG as part of the Gpg4win project. Thus if you need GnuPG on Microsoft Windows, we suggest to use the Gpg4win installer. The installer allows to select the required components. If you only need GnuPG, you may just download the light version of the installer. However, most users want the full fledged version with all the GUI tools. Find below the original announcement. With the exception of the KDE parts and a few utility libraries, the installer has been build from the original sources by me. There are a few patches applied to add features From the soon to be released 2.0.13 version of GnuPG; these patches are part of the installer source tarball. Shalom-Salam, Werner ============== From: Emanuel Sch?tze Subject: [Gpg4win-announce] Gpg4win 2.0.0 released To: gpg4win-announce at wald.intevation.org Date: Wed, 12 Aug 2009 20:28:33 +0200 Hello, we are pleased to announce the availability of a new stable Gpg4win release: Version 2.0.0. This is the first production release of the major redesign. Over the last 15 months we did 16 beta releases and hopefully squashed most of the serious bugs. The download is available via the usual download page: http://www.gpg4win.org/download.html Changes ------- Gpg4win2 has major changes compared to Gpg4win 1.x. Below is a list of the most important ones: - Kleopatra is the new certificate manager. Kleopatra is the S/MIME certificate manager of KDE (a desktop environment used on many GNU/Linux systems). For use in Gpg4win it has been extended to support OpenPGP and to act as a graphical user interface for all cryptographic operations. It is automatically started if another component requests its services and then runs permanently in your system tray. WinPT has been dropped. - GpgEX is the new plugin for the Microsoft Explorer and replaces GpgEE. - The mail program Claws Mail has been updated to a modern version. It now supports SSL, NNTP and IMAP. - GpgOL, the plugin for Outlook 2003 and 2007 has been comprehensively updated. It now supports PGP/MIME and thus makes the use of encrypted or signed attachments much easier and standard conform. Support for S/MIME has been added. Most dialogs are now provided by Kleopatra for graphical user dialogs. - The German "Gpg4win-Kompendium" is the new documentation for Gpg4win. This combines the previous "Einsteiger" and "Durchblicker" manuals. All chapters were reworked and extended to describe the new Gpg4win Version 2.0. Among other things, this means adaption to Kleopatra, GpgEX and PGP/MIME and new texts for S/MIME and X.509. - Support of these platforms: Operating System: Windows 2000, XP (32/64), Vista (32/64) Outlook: 2003, 2007 - Included components are: GnuPG: 2.0.12 Kleopatra: 2.0.11-svn1008232 (20090807) GPA: 0.9.0 GpgOL: 1.0.0 GpgEX: 0.9.3 Claws-Mail: 3.7.2 Kompendium: 3.0.0-beta3 Installation ------------ For installation instructions, please visit http://www.gpg4win.org or read on. Developers who want to *build an installer* need to get the following files from http://wald.intevation.org/projects/gpg4win/ : ? gpg4win-2.0.0.tar.bz2 (5M) ? gpg4win-2.0.0.tar.bz2.sig The second file is a digital signature of the the first file. ?Either check that this signature is fine or compare with the checksums given below. ?(see also http://www.gpg4win.org/package-integrity.html) The *ready to use installer* is available at: ? http://ftp.gpg4win.org/gpg4win-2.0.0.exe ?(35M) ? http://ftp.gpg4win.org/gpg4win-2.0.0.exe.sig Or using the ftp protocol at: ? ftp://ftp.gpg4win.org/gpg4win/gpg4win-2.0.0.exe ?(35M) ? ftp://ftp.gpg4win.org/gpg4win/gpg4win-2.0.0.exe.sig SHA1 checksums for these files are given below. If you don't need the manuals or the GnuPG2 command line tools for S/MIME, you might alternatively download the "light" version of the installer: ? http://ftp.gpg4win.org/gpg4win-light-2.0.0.exe ?(12M) ? http://ftp.gpg4win.org/gpg4win-light-2.0.0.exe.sig or using FTP at: ? ftp://ftp.gpg4win.org/gpg4win/gpg4win-light-2.0.0.exe (12M) ? ftp://ftp.gpg4win.org/gpg4win/gpg4win-light-2.0.0.exe.sig A separate installer with the source files used to build the above installer is available at: ? ftp://ftp.gpg4win.org/gpg4win/gpg4win-src-2.0.0.exe ?(277M) ? ftp://ftp.gpg4win.org/gpg4win/gpg4win-src-2.0.0.exe.sig Most people don't need this source installer; it is merely stored on that server to satisfy the conditions of the GPL. In general it is better to get the gpg4win builder tarball (see above) and follow the instructions in the README to build new installers; building the installer is not possible on Windows machines and works best on current Debian GNU/Linux systems. SHA1 checksums are: 5a900a6807d2b4753d88cdb9548c528cf4bbbe3e gpg4win-2.0.0.exe d00fe78e71a55861a4ccbf92d6e06f4dcbe6aa82 gpg4win-light-2.0.0.exe ba6e4c56bc721707e363640e357d87350c441e02 gpg4win-src-2.0.0.exe f5457f61c8544cbae856738aabfff1a140c754b6 gpg4win-2.0.0.tar.bz2 If you have problems downloading the above files, you may try the mirror server listed at the download page. We like to thank the authors of the included packages, the NSIS authors, all other contributors and first of all, those folks who stayed with us and helped testing Gpg4win. To help furthering this project, please consider to sponsor the development. ?See http://www.gpg4win.org . With best regards ? ?your Gpg4win Development Team -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 205 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From wk at gnupg.org Thu Aug 13 16:40:25 2009 From: wk at gnupg.org (Werner Koch) Date: Thu, 13 Aug 2009 16:40:25 +0200 Subject: 1.4.10 release candidate Message-ID: <87ocqj6ali.fsf@wheatstone.g10code.de> Hi, I just uploaded a release candidate for GnuPG 1.4.10: ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.4.10rc1.tar.bz2 ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.4.10rc1.tar.bz2.sig Since the release of 1.4.9 back in March 2008 we did quite some changes. It would be good if you can give this version a try, so that we won't run into too many build problems with the actual release. Please report bugs to the devel or users mailing list. Happy hacking, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Thu Aug 13 16:44:54 2009 From: wk at gnupg.org (Werner Koch) Date: Thu, 13 Aug 2009 16:44:54 +0200 Subject: Changes in 1.4.10 (was: 1.4.10 release candidate) In-Reply-To: <87ocqj6ali.fsf@wheatstone.g10code.de> (Werner Koch's message of "Thu, 13 Aug 2009 16:40:25 +0200") References: <87ocqj6ali.fsf@wheatstone.g10code.de> Message-ID: <87k5176ae1.fsf@wheatstone.g10code.de> Noteworthy changes in version 1.4.10 (unreleased) ------------------------------------------------- * 2048 bit RSA keys are now generated by default. The default hash algorithm preferences has changed to prefer SHA-256 over SHA-1. 2048 bit DSA keys are now generated to use a 256 bit hash algorithm * Support v2 OpenPGP cards. * The algorithm to compute the SIG_ID status has been changed to match the one from 2.0.10. * Improved file locking. Implemented it for W32. * Fixed a memory leak which made imports of many keys very slow. * Many smaller bug fixes. * Support for the Camellia cipher (RFC-5581). * Support for HKP keyservers over SSL ("HKPS"). -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From aoz.syn at gmail.com Thu Aug 13 20:52:04 2009 From: aoz.syn at gmail.com (RB) Date: Thu, 13 Aug 2009 12:52:04 -0600 Subject: 1.4.10 release candidate In-Reply-To: <87ocqj6ali.fsf@wheatstone.g10code.de> References: <87ocqj6ali.fsf@wheatstone.g10code.de> Message-ID: <4255c2570908131152r3a256563w163be58cfb964fc3@mail.gmail.com> On Thu, Aug 13, 2009 at 08:40, Werner Koch wrote: > Please report bugs to the devel or users mailing list. Is there any hope of getting this[1] bug fixed in distribution? It's mostly an inconvenience, but --enable-minimal still doesn't work without manual modification and autoreconf. [1] https://bugs.g10code.com/gnupg/issue1007 From dshaw at jabberwocky.com Fri Aug 14 04:21:46 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 13 Aug 2009 22:21:46 -0400 Subject: Please test :) Message-ID: <30EFAB5F-705F-438C-A2F4-F94E26AFE0F4@jabberwocky.com> Hi everyone, I'd appreciate it if people could test two particular things in the keyserver support: 1) LDAP now works with DNS service discovery. So, if you have keys in a ldap keyserver, you can put something like _pgpkey-ldap._tcp SRV 0 0 389 my-ldap-keyserver.example.com. in your DNS and GPG will know that for addresses at example.com, it can query ldap://my-ldap-keyserver.example.com for keys. This is very similar to the current support for ldap where GPG will look for a ldap keyserver named "keys" (i.e. for address at example.com, it looks for ldap://keys.example.com), but is no longer required to be named "keys". If the SRV record does not exist, GPG will still look for the "keys" name for backwards (and PGP) compatibility. Setting "auto-key-locate ldap" turns this feature on. If you use an email address as a recipient, and do not have a key for that recipient, the key location feature will kick in and try to find the key for you. Incidentally, it is legal to do this: _pgpkey-ldap._tcp.example.com. SRV 0 0 389 keyserver.pgp.com. That is, point to a non-local (but public) keyserver. It just means "to find keys for addresses @example.com, consult the keyserver at ldap://keyserver.pgp.com". 2) HKPS - in other words regular old HKP over SSL (i.e. https). So far as I know, the only hkps server in existence right now is hkps:// zimmermann.mayfirst.org. David From schot at A-Eskwadraat.nl Fri Aug 14 11:46:19 2009 From: schot at A-Eskwadraat.nl (Jeroen Schot) Date: Fri, 14 Aug 2009 11:46:19 +0200 Subject: Please test :) In-Reply-To: <30EFAB5F-705F-438C-A2F4-F94E26AFE0F4@jabberwocky.com> References: <30EFAB5F-705F-438C-A2F4-F94E26AFE0F4@jabberwocky.com> Message-ID: <20090814094619.GA4693@A-Eskwadraat.nl> Hi, On Thu, Aug 13, 2009 at 10:21:46PM -0400, David Shaw wrote: > 2) HKPS - in other words regular old HKP over SSL (i.e. https). So far as I > know, the only hkps server in existence right now is hkps:// > zimmermann.mayfirst.org. I successfully tested HKPS, but encountered a lack of documentation. So here a short howto specifically for the zimmermann.mayfirst.org keyserver: Download the 'May First/People Link CA' certificate from and store it in ~/.gnupg/ca.crt. Add the following two lines to your gpg.conf (or add them to the commandline): keyserver hkps://zimmermann.mayfirst.org keyserver-options ca-cert-file ~/.gnupg/ca.crt Test the keyserver with a '--search-keys' or '--recv-keys'. Note: The ca-cert-file option is not documented? Regards, -- Jeroen Schot -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 230 bytes Desc: Digital signature URL: From daniel.leidert.spam at gmx.net Fri Aug 14 16:15:32 2009 From: daniel.leidert.spam at gmx.net (Daniel Leidert) Date: Fri, 14 Aug 2009 16:15:32 +0200 Subject: Please test :) In-Reply-To: <20090814094619.GA4693@A-Eskwadraat.nl> References: <30EFAB5F-705F-438C-A2F4-F94E26AFE0F4@jabberwocky.com> <20090814094619.GA4693@A-Eskwadraat.nl> Message-ID: <1250259332.6509.21.camel@leidi> Am Freitag, den 14.08.2009, 11:46 +0200 schrieb Jeroen Schot: > On Thu, Aug 13, 2009 at 10:21:46PM -0400, David Shaw wrote: > > 2) HKPS - in other words regular old HKP over SSL (i.e. https). So far as I > > know, the only hkps server in existence right now is hkps:// > > zimmermann.mayfirst.org. > > I successfully tested HKPS, but encountered a lack of documentation. So here a > short howto specifically for the zimmermann.mayfirst.org keyserver: > > Download the 'May First/People Link CA' certificate from > and store it in > ~/.gnupg/ca.crt. > > Add the following two lines to your gpg.conf (or add them to the commandline): > keyserver hkps://zimmermann.mayfirst.org > keyserver-options ca-cert-file ~/.gnupg/ca.crt > > Test the keyserver with a '--search-keys' or '--recv-keys'. I tried to follow your short howto (got mfpl.crt as .gnupg/ca.crt and added the options), but I always get an error: gpgkeys: HTTP search error 60: server certificate verification failed. CAfile: none CRLfile: none gpg: key "Leidert" not found on keyserver gpg: keyserver internal error gpg: keyserver search failed: keyserver error Following the webform, the keys exist. Any idea? Regards, Daniel From wk at gnupg.org Thu Aug 13 16:44:54 2009 From: wk at gnupg.org (Werner Koch) Date: Thu, 13 Aug 2009 16:44:54 +0200 Subject: Changes in 1.4.10 (was: 1.4.10 release candidate) In-Reply-To: <87ocqj6ali.fsf@wheatstone.g10code.de> (Werner Koch's message of "Thu, 13 Aug 2009 16:40:25 +0200") References: <87ocqj6ali.fsf@wheatstone.g10code.de> Message-ID: <87k5176ae1.fsf@wheatstone.g10code.de> Noteworthy changes in version 1.4.10 (unreleased) ------------------------------------------------- * 2048 bit RSA keys are now generated by default. The default hash algorithm preferences has changed to prefer SHA-256 over SHA-1. 2048 bit DSA keys are now generated to use a 256 bit hash algorithm * Support v2 OpenPGP cards. * The algorithm to compute the SIG_ID status has been changed to match the one from 2.0.10. * Improved file locking. Implemented it for W32. * Fixed a memory leak which made imports of many keys very slow. * Many smaller bug fixes. * Support for the Camellia cipher (RFC-5581). * Support for HKP keyservers over SSL ("HKPS"). -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users From wk at gnupg.org Thu Aug 13 16:40:25 2009 From: wk at gnupg.org (Werner Koch) Date: Thu, 13 Aug 2009 16:40:25 +0200 Subject: 1.4.10 release candidate Message-ID: <87ocqj6ali.fsf@wheatstone.g10code.de> Hi, I just uploaded a release candidate for GnuPG 1.4.10: ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.4.10rc1.tar.bz2 ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.4.10rc1.tar.bz2.sig Since the release of 1.4.9 back in March 2008 we did quite some changes. It would be good if you can give this version a try, so that we won't run into too many build problems with the actual release. Please report bugs to the devel or users mailing list. Happy hacking, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users From dshaw at jabberwocky.com Fri Aug 14 20:25:16 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 14 Aug 2009 14:25:16 -0400 Subject: Please test :) In-Reply-To: <20090814094619.GA4693@A-Eskwadraat.nl> References: <30EFAB5F-705F-438C-A2F4-F94E26AFE0F4@jabberwocky.com> <20090814094619.GA4693@A-Eskwadraat.nl> Message-ID: <412D6349-3A70-4E82-A8BC-C00FD6633240@jabberwocky.com> On Aug 14, 2009, at 5:46 AM, Jeroen Schot wrote: > Hi, > > On Thu, Aug 13, 2009 at 10:21:46PM -0400, David Shaw wrote: >> 2) HKPS - in other words regular old HKP over SSL (i.e. https). So >> far as I >> know, the only hkps server in existence right now is hkps:// >> zimmermann.mayfirst.org. > > I successfully tested HKPS, but encountered a lack of documentation. > So here a > short howto specifically for the zimmermann.mayfirst.org keyserver: > > Download the 'May First/People Link CA' certificate from > and > store it in > ~/.gnupg/ca.crt. > > Add the following two lines to your gpg.conf (or add them to the > commandline): > keyserver hkps://zimmermann.mayfirst.org > keyserver-options ca-cert-file ~/.gnupg/ca.crt > > Test the keyserver with a '--search-keys' or '--recv-keys'. > > Note: The ca-cert-file option is not documented? You're right. I'll fix that. There is also a check-cert / no-check-cert option to enable checking or not. It's actually a bit of a question whether the default should be to check or not to check (it's currently defaulting to check). Usually, you'd want to check by default, but in the case of OpenPGP keys, the keys are not validated by the keyserver anyway. David From dshaw at jabberwocky.com Fri Aug 14 20:27:03 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 14 Aug 2009 14:27:03 -0400 Subject: Please test :) In-Reply-To: <1250259332.6509.21.camel@leidi> References: <30EFAB5F-705F-438C-A2F4-F94E26AFE0F4@jabberwocky.com> <20090814094619.GA4693@A-Eskwadraat.nl> <1250259332.6509.21.camel@leidi> Message-ID: <22ECADC6-06F2-435C-B38F-573DD1CF4F5A@jabberwocky.com> On Aug 14, 2009, at 10:15 AM, Daniel Leidert wrote: > Am Freitag, den 14.08.2009, 11:46 +0200 schrieb Jeroen Schot: > >> On Thu, Aug 13, 2009 at 10:21:46PM -0400, David Shaw wrote: >>> 2) HKPS - in other words regular old HKP over SSL (i.e. https). So >>> far as I >>> know, the only hkps server in existence right now is hkps:// >>> zimmermann.mayfirst.org. >> >> I successfully tested HKPS, but encountered a lack of >> documentation. So here a >> short howto specifically for the zimmermann.mayfirst.org keyserver: >> >> Download the 'May First/People Link CA' certificate from >> and >> store it in >> ~/.gnupg/ca.crt. >> >> Add the following two lines to your gpg.conf (or add them to the >> commandline): >> keyserver hkps://zimmermann.mayfirst.org >> keyserver-options ca-cert-file ~/.gnupg/ca.crt >> >> Test the keyserver with a '--search-keys' or '--recv-keys'. > > I tried to follow your short howto (got mfpl.crt as .gnupg/ca.crt and > added the options), but I always get an error: > > gpgkeys: HTTP search error 60: server certificate verification failed. > CAfile: none CRLfile: none > gpg: key "Leidert" not found on keyserver > gpg: keyserver internal error > gpg: keyserver search failed: keyserver error > > Following the webform, the keys exist. Any idea? Try not using the ~ in the file path. Rather, spell out the complete path. Different distros sometimes build curl with different backend SSL libraries, and not all understand ~. David From tmz at pobox.com Fri Aug 14 20:46:23 2009 From: tmz at pobox.com (Todd Zullinger) Date: Fri, 14 Aug 2009 14:46:23 -0400 Subject: Please test :) In-Reply-To: <412D6349-3A70-4E82-A8BC-C00FD6633240@jabberwocky.com> References: <30EFAB5F-705F-438C-A2F4-F94E26AFE0F4@jabberwocky.com> <20090814094619.GA4693@A-Eskwadraat.nl> <412D6349-3A70-4E82-A8BC-C00FD6633240@jabberwocky.com> Message-ID: <20090814184623.GD4169@inocybe.localdomain> David Shaw wrote: > There is also a check-cert / no-check-cert option to enable checking > or not. It's actually a bit of a question whether the default > should be to check or not to check (it's currently defaulting to > check). Usually, you'd want to check by default, but in the case of > OpenPGP keys, the keys are not validated by the keyserver anyway. This is one of those potential bike shed topics. :) While the keyserver doesn't validate the keys, if someone is using hkps:// it may well be to provide privacy and security for which keys they are looking up. If the cert is not checked the user cannot be sure the keyserver they are connecting to is the legitimate site which they trust. To me, it seems like checking is the more reasonable default. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I visualize a time when we will be to robots what dogs are to humans, and I'm rooting for the machines. -- Claude Shannon -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From tmz at pobox.com Fri Aug 14 20:41:32 2009 From: tmz at pobox.com (Todd Zullinger) Date: Fri, 14 Aug 2009 14:41:32 -0400 Subject: Please test :) In-Reply-To: <22ECADC6-06F2-435C-B38F-573DD1CF4F5A@jabberwocky.com> References: <30EFAB5F-705F-438C-A2F4-F94E26AFE0F4@jabberwocky.com> <20090814094619.GA4693@A-Eskwadraat.nl> <1250259332.6509.21.camel@leidi> <22ECADC6-06F2-435C-B38F-573DD1CF4F5A@jabberwocky.com> Message-ID: <20090814184132.GC4169@inocybe.localdomain> David Shaw wrote: > Try not using the ~ in the file path. Rather, spell out the complete > path. Different distros sometimes build curl with different backend > SSL libraries, and not all understand ~. On fedora, where curl is built with nss, this seems to be the case. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The United States is a nation of laws, badly written and randomly enforced. -- Frank Zappa -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From dshaw at jabberwocky.com Sat Aug 15 06:19:37 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Sat, 15 Aug 2009 00:19:37 -0400 Subject: Please test :) Message-ID: On Aug 14, 2009, at 2:46 PM, Todd Zullinger wrote: > David Shaw wrote: >> There is also a check-cert / no-check-cert option to enable checking >> or not. It's actually a bit of a question whether the default >> should be to check or not to check (it's currently defaulting to >> check). Usually, you'd want to check by default, but in the case of >> OpenPGP keys, the keys are not validated by the keyserver anyway. > > This is one of those potential bike shed topics. :) > > While the keyserver doesn't validate the keys, if someone is using > hkps:// it may well be to provide privacy and security for which keys > they are looking up. If the cert is not checked the user cannot be > sure the keyserver they are connecting to is the legitimate site which > they trust. To me, it seems like checking is the more reasonable > default. I agree (note that the default is to check, for both hkps and ldaps). While we cannot know the reason why someone is using hkps (rather than hkp), it is generally healthy to default to the more secure setting unless there is a clear reason not to. Those who don't want cert checking can always turn it off. David From daniel.leidert.spam at gmx.net Sat Aug 15 19:12:20 2009 From: daniel.leidert.spam at gmx.net (Daniel Leidert) Date: Sat, 15 Aug 2009 19:12:20 +0200 Subject: Please test :) In-Reply-To: <22ECADC6-06F2-435C-B38F-573DD1CF4F5A@jabberwocky.com> References: <30EFAB5F-705F-438C-A2F4-F94E26AFE0F4@jabberwocky.com> <20090814094619.GA4693@A-Eskwadraat.nl> <1250259332.6509.21.camel@leidi> <22ECADC6-06F2-435C-B38F-573DD1CF4F5A@jabberwocky.com> Message-ID: <1250356340.5390.16.camel@leidi> Am Freitag, den 14.08.2009, 14:27 -0400 schrieb David Shaw: > On Aug 14, 2009, at 10:15 AM, Daniel Leidert wrote: [test hkps support] > > I tried to follow your short howto (got mfpl.crt as .gnupg/ca.crt and > > added the options), but I always get an error: > > > > gpgkeys: HTTP search error 60: server certificate verification failed. > > CAfile: none CRLfile: none > > gpg: key "Leidert" not found on keyserver > > gpg: keyserver internal error > > gpg: keyserver search failed: keyserver error > > > > Following the webform, the keys exist. Any idea? > > Try not using the ~ in the file path. Rather, spell out the complete > path. Different distros sometimes build curl with different backend > SSL libraries, and not all understand ~. I used the full path too with the same result. But I tried the whole thing in a chroot environment and I'll try to examine this further. Not sure, what's happening. Regards, Daniel From schot at A-Eskwadraat.nl Sat Aug 15 21:17:49 2009 From: schot at A-Eskwadraat.nl (Jeroen Schot) Date: Sat, 15 Aug 2009 21:17:49 +0200 Subject: Please test :) In-Reply-To: <1250356340.5390.16.camel@leidi> References: <30EFAB5F-705F-438C-A2F4-F94E26AFE0F4@jabberwocky.com> <20090814094619.GA4693@A-Eskwadraat.nl> <1250259332.6509.21.camel@leidi> <22ECADC6-06F2-435C-B38F-573DD1CF4F5A@jabberwocky.com> <1250356340.5390.16.camel@leidi> Message-ID: <20090815191749.GA28067@A-Eskwadraat.nl> Hi, On Sat, Aug 15, 2009 at 07:12:20PM +0200, Daniel Leidert wrote: > I used the full path too with the same result. But I tried the whole > thing in a chroot environment and I'll try to examine this further. Not > sure, what's happening. Could you try to change the line keyserver-options ca-cert-file ~/.gnupg/ca.crt to keyserver-options ca-cert-file=/path/to/.gnupg/ca.crt Note the '=' sign. Regards, -- Jeroen Schot -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 230 bytes Desc: Digital signature URL: From daniel.leidert.spam at gmx.net Sat Aug 15 22:16:49 2009 From: daniel.leidert.spam at gmx.net (Daniel Leidert) Date: Sat, 15 Aug 2009 22:16:49 +0200 Subject: Please test :) In-Reply-To: <20090815191749.GA28067@A-Eskwadraat.nl> References: <30EFAB5F-705F-438C-A2F4-F94E26AFE0F4@jabberwocky.com> <20090814094619.GA4693@A-Eskwadraat.nl> <1250259332.6509.21.camel@leidi> <22ECADC6-06F2-435C-B38F-573DD1CF4F5A@jabberwocky.com> <1250356340.5390.16.camel@leidi> <20090815191749.GA28067@A-Eskwadraat.nl> Message-ID: <1250367409.7694.2.camel@leidi> Am Samstag, den 15.08.2009, 21:17 +0200 schrieb Jeroen Schot: > On Sat, Aug 15, 2009 at 07:12:20PM +0200, Daniel Leidert wrote: > > I used the full path too with the same result. But I tried the whole > > thing in a chroot environment and I'll try to examine this further. Not > > sure, what's happening. > > Could you try to change the line > keyserver-options ca-cert-file ~/.gnupg/ca.crt > to > keyserver-options ca-cert-file=/path/to/.gnupg/ca.crt > > Note the '=' sign. Many thanks. That's it. JFTR: The tilde sign doesn't work under Debian too. So the full path is necessary. Regards, Daniel From daniel.leidert.spam at gmx.net Sun Aug 16 14:27:13 2009 From: daniel.leidert.spam at gmx.net (Daniel Leidert) Date: Sun, 16 Aug 2009 14:27:13 +0200 Subject: 64bit: util/iobuf.c:322: warning: cast to pointer from integer of different size Message-ID: <1250425633.7694.28.camel@leidi> Hi, There is a warning from the compiler on 64 bit systems: ../../util/iobuf.c: In function 'fd_cache_close': ../../util/iobuf.c:322: warning: cast to pointer from integer of different size Regards, Daniel From eric at debian.org Mon Aug 17 00:59:40 2009 From: eric at debian.org (Eric Dorland) Date: Sun, 16 Aug 2009 18:59:40 -0400 Subject: Why Is libassuan still a static lib? 2009 Edition Message-ID: <20090816225940.GA16229@gambit> Hello, When I last brought this up (http://markmail.org/message/anh6vlx3dx2vdgyq#query:libassuan%20shared%20Eric%20Dorland+page:1+mid:4jfwogujquqaaqnu+state:results), it was said that libassuan was still a static library because the API was still not stabilized. It's now 3 years later nearly and as far as I can tell the API hasn't changed very much. Can we revisit this? I'm happy to provide the patch :) -- Eric Dorland ICQ: #61138586, Jabber: hooty at jabber.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From dougb at dougbarton.us Mon Aug 17 06:51:04 2009 From: dougb at dougbarton.us (Doug Barton) Date: Sun, 16 Aug 2009 21:51:04 -0700 Subject: 1.4.10 release candidate In-Reply-To: <87ocqj6ali.fsf@wheatstone.g10code.de> References: <87ocqj6ali.fsf@wheatstone.g10code.de> Message-ID: <4A88E1B8.5080103@dougbarton.us> Werner Koch wrote: > Hi, > > I just uploaded a release candidate for GnuPG 1.4.10: No build problems on FreeBSD 8-current (soon to be 8.0-release). The resultant gpg binary passes a few simple regression tests as well. hth, Doug From thijs at debian.org Sun Aug 16 10:02:37 2009 From: thijs at debian.org (Thijs Kinkhorst) Date: Sun, 16 Aug 2009 10:02:37 +0200 Subject: GnuPG 1.4.10 RC1 available from Debian Experimental Message-ID: <200908161002.39602.thijs@debian.org> Hi, The recent release candidate 1 for GnuPG 1.4.10 has been packaged and uploaded to Debian's "experimental" distribution, in order to facilitate testing. If you wish, please try it out and of course report bugs found. All cautions around release candidates and the experimental distribution of course apply. See: http://packages.debian.org/experimental/gnupg cheers, Thijs -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 489 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Mon Aug 17 12:24:22 2009 From: wk at gnupg.org (Werner Koch) Date: Mon, 17 Aug 2009 12:24:22 +0200 Subject: Please test :) In-Reply-To: <22ECADC6-06F2-435C-B38F-573DD1CF4F5A@jabberwocky.com> (David Shaw's message of "Fri, 14 Aug 2009 14:27:03 -0400") References: <30EFAB5F-705F-438C-A2F4-F94E26AFE0F4@jabberwocky.com> <20090814094619.GA4693@A-Eskwadraat.nl> <1250259332.6509.21.camel@leidi> <22ECADC6-06F2-435C-B38F-573DD1CF4F5A@jabberwocky.com> Message-ID: <87zl9y3fhl.fsf@wheatstone.g10code.de> On Fri, 14 Aug 2009 20:27, dshaw at jabberwocky.com said: > Try not using the ~ in the file path. Rather, spell out the complete We should process the tilde. We do this at all other places and it is a bit surprising that it does not work here. While looking at the code I figured that 1.4. and 2.0 are not anymore identical. 1.4. does complete tilde expansion since 2005 whereas 2.0 still looks only at $HOME. I'll put this on my list for 2.0.13. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Mon Aug 17 12:28:20 2009 From: wk at gnupg.org (Werner Koch) Date: Mon, 17 Aug 2009 12:28:20 +0200 Subject: Why Is libassuan still a static lib? 2009 Edition In-Reply-To: <20090816225940.GA16229@gambit> (Eric Dorland's message of "Sun, 16 Aug 2009 18:59:40 -0400") References: <20090816225940.GA16229@gambit> Message-ID: <87vdkm3faz.fsf@wheatstone.g10code.de> On Mon, 17 Aug 2009 00:59, eric at debian.org said: > was still not stabilized. It's now 3 years later nearly and as far as > I can tell the API hasn't changed very much. Can we revisit this? I'm > happy to provide the patch :) It is more than a patch. Actually we have this in the works for several months now. However other projects required too much attention (gpg4win in particular :-(). More on this soon. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From marcus.brinkmann at ruhr-uni-bochum.de Mon Aug 17 20:17:05 2009 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 17 Aug 2009 20:17:05 +0200 Subject: Please test :) In-Reply-To: <412D6349-3A70-4E82-A8BC-C00FD6633240@jabberwocky.com> References: <30EFAB5F-705F-438C-A2F4-F94E26AFE0F4@jabberwocky.com> <20090814094619.GA4693@A-Eskwadraat.nl> <412D6349-3A70-4E82-A8BC-C00FD6633240@jabberwocky.com> Message-ID: <4A899EA1.9080600@ruhr-uni-bochum.de> David Shaw wrote: > There is also a check-cert / no-check-cert option to enable checking or > not. It's actually a bit of a question whether the default should be to > check or not to check (it's currently defaulting to check). Usually, > you'd want to check by default, but in the case of OpenPGP keys, the > keys are not validated by the keyserver anyway. Protecting the channel is important if for example replay attacks are a concern, and you want to avoid a man in the middle providing out of date keys and suppressing revoke certificates. Thanks, Marcus From dshaw at jabberwocky.com Mon Aug 17 20:26:39 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 17 Aug 2009 14:26:39 -0400 Subject: Please test :) In-Reply-To: <4A899EA1.9080600@ruhr-uni-bochum.de> References: <30EFAB5F-705F-438C-A2F4-F94E26AFE0F4@jabberwocky.com> <20090814094619.GA4693@A-Eskwadraat.nl> <412D6349-3A70-4E82-A8BC-C00FD6633240@jabberwocky.com> <4A899EA1.9080600@ruhr-uni-bochum.de> Message-ID: <5398F9D3-AE79-44FE-A720-5FE8911A90D2@jabberwocky.com> On Aug 17, 2009, at 2:17 PM, Marcus Brinkmann wrote: > David Shaw wrote: >> There is also a check-cert / no-check-cert option to enable >> checking or >> not. It's actually a bit of a question whether the default should >> be to >> check or not to check (it's currently defaulting to check). Usually, >> you'd want to check by default, but in the case of OpenPGP keys, the >> keys are not validated by the keyserver anyway. > > Protecting the channel is important if for example replay attacks > are a > concern, and you want to avoid a man in the middle providing out of > date keys > and suppressing revoke certificates. Yes, and so the default for cert checking is on to be extra safe, but I don't think that case is very common. Most people just talk to a public keyserver that they do not have any particular relationship to. David From wk at gnupg.org Tue Aug 18 11:35:48 2009 From: wk at gnupg.org (Werner Koch) Date: Tue, 18 Aug 2009 11:35:48 +0200 Subject: 64bit: util/iobuf.c:322: warning: cast to pointer from integer of different size In-Reply-To: <1250425633.7694.28.camel@leidi> (Daniel Leidert's message of "Sun, 16 Aug 2009 14:27:13 +0200") References: <1250425633.7694.28.camel@leidi> Message-ID: <87ljlh31mz.fsf@wheatstone.g10code.de> On Sun, 16 Aug 2009 14:27, daniel.leidert.spam at gmx.net said: > ../../util/iobuf.c: In function 'fd_cache_close': > ../../util/iobuf.c:322: warning: cast to pointer from integer of different size It is anyway only debug output. However I changed it in svn 5124. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From lionel at mamane.lu Tue Aug 18 15:02:00 2009 From: lionel at mamane.lu (Lionel Elie Mamane) Date: Tue, 18 Aug 2009 15:02:00 +0200 Subject: Poldi bug report: allow non-digit PIN In-Reply-To: <87fxbzblyc.fsf@wheatstone.g10code.de> References: <20090730174934.GC12475@capsaicin.mamane.lu> <874ospumi5.fsf@wheatstone.g10code.de> <4A7D6A37.5020802@rub.de> <87fxbzblyc.fsf@wheatstone.g10code.de> Message-ID: <20090818130200.GA3767@capsaicin.mamane.lu> On Mon, Aug 10, 2009 at 07:47:07PM +0200, Werner Koch wrote: > On Sat, 8 Aug 2009 14:06, Moritz.Schulte at rub.de said: >> What does this mean for Poldi? Should Poldi _forbid_ the use of >> non-digit PINs or not? Maybe we should add a configuration option >> ("allow-non-digit-pins"?) to make it clear that using non-digit PINs >> might get you into trouble? > In GnuPG we do these checks > /* do some basic checks on the entered PIN. */ > if (!all_digitsp (pininfo->pin)) > errtext = _("Invalid characters in PIN"); > else if (pininfo->max_digits > && strlen (pininfo->pin) > pininfo->max_digits) > errtext = _("PIN too long"); > else if (strlen (pininfo->pin) < pininfo->min_digits) > errtext = _("PIN too short"); > if asking for a PIN via Pinentry. MIN_MAXDIGITS are 0/16. This is in > the generic code; the actual smartcard application code in scdaemon may > even be more restrictive. I use a non-digit PIN for SSH authentication (so gpg-agent / scdaemon), and it works. So it would seem that scdaemon is much less restrictive. lionelm at harif:~$ scdaemon --version scdaemon (GnuPG) 2.0.11 libgcrypt 1.4.4 libksba 1.0.6 It is possible that it is a Debian-specific patch that allows me that, not sure. -- Lionel From lionel at mamane.lu Tue Aug 18 15:04:05 2009 From: lionel at mamane.lu (Lionel Elie Mamane) Date: Tue, 18 Aug 2009 15:04:05 +0200 Subject: Poldi bug report: better scdaemon handling In-Reply-To: <4A7DBD91.20606@g10code.com> References: <20090730175843.GE12475@capsaicin.mamane.lu> <4A7DBD91.20606@g10code.com> Message-ID: <20090818130405.GB3767@capsaicin.mamane.lu> On Sat, Aug 08, 2009 at 08:01:53PM +0200, Moritz Schulte wrote: > in the SVN trunk of Poldi I have implemented an (experimental[0]) Poldi > option named "scdaemon-options". This option can be used to specify the > scdaemon configuration file to use for spawning new scdaemon instancens > right in poldi.conf. I guess this is better than hard-coding the name of > the configuration file. Yes, it is. Thanks. > Regarding the stderr issue: I agree we better find a fix for this, > but I'm not yet sure if the fix you proposed is the most appropriate > one. Another thing to consider is to redirect the scdaemon stderr to the poldi logfile? -- Lionel From wk at gnupg.org Tue Aug 18 20:02:58 2009 From: wk at gnupg.org (Werner Koch) Date: Tue, 18 Aug 2009 20:02:58 +0200 Subject: Poldi bug report: allow non-digit PIN In-Reply-To: <20090818130200.GA3767@capsaicin.mamane.lu> (Lionel Elie Mamane's message of "Tue, 18 Aug 2009 15:02:00 +0200") References: <20090730174934.GC12475@capsaicin.mamane.lu> <874ospumi5.fsf@wheatstone.g10code.de> <4A7D6A37.5020802@rub.de> <87fxbzblyc.fsf@wheatstone.g10code.de> <20090818130200.GA3767@capsaicin.mamane.lu> Message-ID: <87iqgl0zl9.fsf@wheatstone.g10code.de> On Tue, 18 Aug 2009 15:02, lionel at mamane.lu said: > I use a non-digit PIN for SSH authentication (so gpg-agent / > scdaemon), and it works. So it would seem that scdaemon is much less > restrictive. Quite possible that this slipped in. I am a bit reluctant to make the check for ssh more restrictive as this would mean you can't use it anymore. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From eric at kuroneko.ca Mon Aug 24 01:04:29 2009 From: eric at kuroneko.ca (Eric Dorland) Date: Sun, 23 Aug 2009 19:04:29 -0400 Subject: Why Is libassuan still a static lib? 2009 Edition In-Reply-To: <87vdkm3faz.fsf@wheatstone.g10code.de> References: <20090816225940.GA16229@gambit> <87vdkm3faz.fsf@wheatstone.g10code.de> Message-ID: <20090823230429.GB4557@gambit> * Werner Koch (wk at gnupg.org) wrote: > On Mon, 17 Aug 2009 00:59, eric at debian.org said: > > > was still not stabilized. It's now 3 years later nearly and as far as > > I can tell the API hasn't changed very much. Can we revisit this? I'm > > happy to provide the patch :) > > It is more than a patch. Actually we have this in the works for several > months now. However other projects required too much attention (gpg4win > in particular :-(). > > More on this soon. What about it is more than a patch to build system? -- Eric Dorland ICQ: #61138586, Jabber: hooty at jabber.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From dshaw at jabberwocky.com Mon Aug 24 03:46:33 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 23 Aug 2009 21:46:33 -0400 Subject: Please test :) In-Reply-To: <87zl9y3fhl.fsf@wheatstone.g10code.de> References: <30EFAB5F-705F-438C-A2F4-F94E26AFE0F4@jabberwocky.com> <20090814094619.GA4693@A-Eskwadraat.nl> <1250259332.6509.21.camel@leidi> <22ECADC6-06F2-435C-B38F-573DD1CF4F5A@jabberwocky.com> <87zl9y3fhl.fsf@wheatstone.g10code.de> Message-ID: <8E2EE82E-C06D-4BE9-A579-B9F6DEDBCD2E@jabberwocky.com> On Aug 17, 2009, at 6:24 AM, Werner Koch wrote: > On Fri, 14 Aug 2009 20:27, dshaw at jabberwocky.com said: > >> Try not using the ~ in the file path. Rather, spell out the complete > > We should process the tilde. We do this at all other places and it > is a > bit surprising that it does not work here. I agree. How should we handle this? This raises a different question, as the current tilde expansion code is in libutil, rather than libcompat, which is what is linked with the keyserver helpers. My notes say we split libcompat and libutil in 2006 for licensing reasons, as the keyserver helpers might be linked with OpenSSL, which is not GPL compatible (hence the special exception in the keyserver helper license). Now, it would be possible to move the tilde expanding code to libcompat (or even just implement things slightly differently), but I notice that GnuPG 2.x doesn't do any of this stuff with a different library, and just uses libcommon everywhere, including in the keyserver helpers. Is libcompat really necessary for GPL compliance? If not, this is an easier problem. If it is necessary, we need to fix GnuPG 2.x. David From wk at gnupg.org Tue Aug 25 08:12:36 2009 From: wk at gnupg.org (Werner Koch) Date: Tue, 25 Aug 2009 08:12:36 +0200 Subject: Why Is libassuan still a static lib? 2009 Edition In-Reply-To: <20090823230429.GB4557@gambit> (Eric Dorland's message of "Sun, 23 Aug 2009 19:04:29 -0400") References: <20090816225940.GA16229@gambit> <87vdkm3faz.fsf@wheatstone.g10code.de> <20090823230429.GB4557@gambit> Message-ID: <87tyzw8lrf.fsf@vigenere.g10code.de> On Mon, 24 Aug 2009 01:04, eric at kuroneko.ca said: > What about it is more than a patch to build system? We need to define an ABI for the years to come; some old APIs will be removed, other will undergo minor changes. Changing an ABI after its initial release is far more troublesome than changing an API for a static lib. Switching to a DSO is a good opportunity to do this. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Tue Aug 25 14:45:00 2009 From: wk at gnupg.org (Werner Koch) Date: Tue, 25 Aug 2009 14:45:00 +0200 Subject: Please test :) In-Reply-To: <8E2EE82E-C06D-4BE9-A579-B9F6DEDBCD2E@jabberwocky.com> (David Shaw's message of "Sun, 23 Aug 2009 21:46:33 -0400") References: <30EFAB5F-705F-438C-A2F4-F94E26AFE0F4@jabberwocky.com> <20090814094619.GA4693@A-Eskwadraat.nl> <1250259332.6509.21.camel@leidi> <22ECADC6-06F2-435C-B38F-573DD1CF4F5A@jabberwocky.com> <87zl9y3fhl.fsf@wheatstone.g10code.de> <8E2EE82E-C06D-4BE9-A579-B9F6DEDBCD2E@jabberwocky.com> Message-ID: <87k50s83lf.fsf@vigenere.g10code.de> On Mon, 24 Aug 2009 03:46, dshaw at jabberwocky.com said: > which is what is linked with the keyserver helpers. My notes say we > split libcompat and libutil in 2006 for licensing reasons, as the > keyserver helpers might be linked with OpenSSL, which is not GPL Right, I forgot about this. > Now, it would be possible to move the tilde expanding code to > libcompat (or even just implement things slightly differently), but I Yeah we should do that: Add the exception to gnupg14/util/fileutil.c and make sure that it does not need other stuff from util/ . BTW, srv.c, which is used in libcompat, is also missing the OpenSSL exception. Easy to fix. > notice that GnuPG 2.x doesn't do any of this stuff with a different > library, and just uses libcommon everywhere, including in the > keyserver helpers. Right. Actually, I forgot about this problem while porting the keyserver code to GnuPG-2, or assumed that OpenSSL is not used. Those who distribute GnuPG-2, need to take care of the license, meaning to use gnutls, yaSSL or another GPL compatible SSL library. In particular gnutls is a good choice because gnutls uses libgcrypt which is a requirement for GnupG anyway. > Is libcompat really necessary for GPL compliance? If not, this is an > easier problem. If it is necessary, we need to fix GnuPG 2.x. We should allow the (indirect) use of OpenSSL with GnuPG 1.4, thus we need to extend libcompat. No need to care about it for GnuPG-2. Shall I take care of the tilde code? Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From dshaw at JABBERWOCKY.COM Tue Aug 25 21:03:55 2009 From: dshaw at JABBERWOCKY.COM (David Shaw) Date: Tue, 25 Aug 2009 15:03:55 -0400 Subject: Please test :) In-Reply-To: <87k50s83lf.fsf@vigenere.g10code.de> References: <30EFAB5F-705F-438C-A2F4-F94E26AFE0F4@jabberwocky.com> <20090814094619.GA4693@A-Eskwadraat.nl> <1250259332.6509.21.camel@leidi> <22ECADC6-06F2-435C-B38F-573DD1CF4F5A@jabberwocky.com> <87zl9y3fhl.fsf@wheatstone.g10code.de> <8E2EE82E-C06D-4BE9-A579-B9F6DEDBCD2E@jabberwocky.com> <87k50s83lf.fsf@vigenere.g10code.de> Message-ID: On Aug 25, 2009, at 8:45 AM, Werner Koch wrote: > On Mon, 24 Aug 2009 03:46, dshaw at jabberwocky.com said: > >> which is what is linked with the keyserver helpers. My notes say we >> split libcompat and libutil in 2006 for licensing reasons, as the >> keyserver helpers might be linked with OpenSSL, which is not GPL > > Right, I forgot about this. > >> Now, it would be possible to move the tilde expanding code to >> libcompat (or even just implement things slightly differently), but I > > Yeah we should do that: Add the exception to gnupg14/util/fileutil.c > and make sure that it does not need other stuff from util/ . Alas, it does. It pulls in the memory allocation code (xmalloc and friends). We could fairly easily make a ~ expander that doesn't use the other code though. It's a shame we can't just use wordexp(). > Actually, I forgot about this problem while porting the keyserver code > to GnuPG-2, or assumed that OpenSSL is not used. Those who distribute > GnuPG-2, need to take care of the license, meaning to use gnutls, > yaSSL > or another GPL compatible SSL library. In particular gnutls is a good > choice because gnutls uses libgcrypt which is a requirement for GnupG > anyway. I worry this might be a excessive burden in some places. It basically means that if a distribution builds Curl with OpenSSL, that distribution must build GnuPG without Curl. Since Curl defaults to building with OpenSSL, and GnuPG-2 defaults to building with Curl, that requires the distribution builder to know about this potential license conflict and override the defaults somewhere in the GnuPG-2- >Curl->OpenSSL chain. I don't know how many distros fall into this category (I do know that Fedora is okay here), but any distro that follows the defaults will. David From wk at gnupg.org Tue Aug 25 21:17:54 2009 From: wk at gnupg.org (Werner Koch) Date: Tue, 25 Aug 2009 21:17:54 +0200 Subject: Please test :) In-Reply-To: (David Shaw's message of "Tue, 25 Aug 2009 15:03:55 -0400") References: <30EFAB5F-705F-438C-A2F4-F94E26AFE0F4@jabberwocky.com> <20090814094619.GA4693@A-Eskwadraat.nl> <1250259332.6509.21.camel@leidi> <22ECADC6-06F2-435C-B38F-573DD1CF4F5A@jabberwocky.com> <87zl9y3fhl.fsf@wheatstone.g10code.de> <8E2EE82E-C06D-4BE9-A579-B9F6DEDBCD2E@jabberwocky.com> <87k50s83lf.fsf@vigenere.g10code.de> Message-ID: <874orv8zz1.fsf@vigenere.g10code.de> On Tue, 25 Aug 2009 21:03, dshaw at JABBERWOCKY.COM said: > Alas, it does. It pulls in the memory allocation code (xmalloc and > friends). We could fairly easily make a ~ expander that doesn't use No problem anymore. I just added a small memory allocation stub. > means that if a distribution builds Curl with OpenSSL, that > distribution must build GnuPG without Curl. Since Curl defaults to > building with OpenSSL, and GnuPG-2 defaults to building with Curl, Most GPL software is bugged by this problem. This was discussed a few years ago and all distros should by now know about it. The problems are sometimes even deeper hidden than gpl_application->openldap->openssl. > I don't know how many distros fall into this category (I do know that > Fedora is okay here), but any distro that follows the defaults will. Debian and thus Ubunto gets this right. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From dshaw at jabberwocky.com Wed Aug 26 17:33:39 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 26 Aug 2009 11:33:39 -0400 Subject: Please test :) In-Reply-To: <874orv8zz1.fsf@vigenere.g10code.de> References: <30EFAB5F-705F-438C-A2F4-F94E26AFE0F4@jabberwocky.com> <20090814094619.GA4693@A-Eskwadraat.nl> <1250259332.6509.21.camel@leidi> <22ECADC6-06F2-435C-B38F-573DD1CF4F5A@jabberwocky.com> <87zl9y3fhl.fsf@wheatstone.g10code.de> <8E2EE82E-C06D-4BE9-A579-B9F6DEDBCD2E@jabberwocky.com> <87k50s83lf.fsf@vigenere.g10code.de> <874orv8zz1.fsf@vigenere.g10code.de> Message-ID: <5CA7DF15-FBA7-4089-9CE8-318C0C5046EF@jabberwocky.com> On Aug 25, 2009, at 3:17 PM, Werner Koch wrote: > On Tue, 25 Aug 2009 21:03, dshaw at JABBERWOCKY.COM said: > >> Alas, it does. It pulls in the memory allocation code (xmalloc and >> friends). We could fairly easily make a ~ expander that doesn't use > > No problem anymore. I just added a small memory allocation stub. Great! >> means that if a distribution builds Curl with OpenSSL, that >> distribution must build GnuPG without Curl. Since Curl defaults to >> building with OpenSSL, and GnuPG-2 defaults to building with Curl, > > Most GPL software is bugged by this problem. This was discussed a few > years ago and all distros should by now know about it. The problems > are > sometimes even deeper hidden than gpl_application->openldap->openssl. > >> I don't know how many distros fall into this category (I do know that >> Fedora is okay here), but any distro that follows the defaults will. > > Debian and thus Ubunto gets this right. Sounds good to me. I just don't want any distribution to get any grief for distributing GnuPG. David From lists at lina.inka.de Wed Aug 26 19:19:10 2009 From: lists at lina.inka.de (Bernd Eckenfels) Date: Wed, 26 Aug 2009 19:19:10 +0200 Subject: Please test :) In-Reply-To: <5CA7DF15-FBA7-4089-9CE8-318C0C5046EF@jabberwocky.com> References: <30EFAB5F-705F-438C-A2F4-F94E26AFE0F4@jabberwocky.com> <20090814094619.GA4693@A-Eskwadraat.nl> <1250259332.6509.21.camel@leidi> <22ECADC6-06F2-435C-B38F-573DD1CF4F5A@jabberwocky.com> <87zl9y3fhl.fsf@wheatstone.g10code.de> <8E2EE82E-C06D-4BE9-A579-B9F6DEDBCD2E@jabberwocky.com> <87k50s83lf.fsf@vigenere.g10code.de> <874orv8zz1.fsf@vigenere.g10code.de> <5CA7DF15-FBA7-4089-9CE8-318C0C5046EF@jabberwocky.com> Message-ID: <20090826171910.GA22134@lina.inka.de> On Wed, Aug 26, 2009 at 11:33:39AM -0400, David Shaw wrote: > Sounds good to me. I just don't want any distribution to get any > grief for distributing GnuPG. In that case it would help to get rid of GPL :) Gruss Bernd -- (OO) -- Bernd_Eckenfels at M?rscher_Strasse_8.76185Karlsruhe.de -- ( .. ) ecki@{inka.de,linux.de,debian.org} http://www.eckes.org/ o--o 1024D/E383CD7E eckes at IRCNet v:+497211603874 f:+49721151516129 (O____O) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!