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!