From simon at josefsson.org  Wed May  2 15:50:41 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 02 May 2007 15:50:41 +0200
Subject: [gnutls-dev] GnuTLS 1.7.8.p11.0
Message-ID: <877irruyfi.fsf@mocca.josefsson.org>

A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 419 bytes
Desc: not available
Url : /pipermail/attachments/20070502/c64bacc7/attachment.pgp 

From simon at josefsson.org  Wed May  2 15:57:41 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 02 May 2007 15:57:41 +0200
Subject: [gnutls-dev] GnuTLS 1.7.8.p11.0
In-Reply-To: <877irruyfi.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Wed\, 02 May 2007 15\:50\:41 +0200")
References: <877irruyfi.fsf@mocca.josefsson.org>
Message-ID: <87slaftjje.fsf@mocca.josefsson.org>

Simon Josefsson <simon at josefsson.org> writes:

> Here are the compressed sources (4.3MB):
>   ftp://ftp.gnutls.org/pub/gnutls/devel/gnutls-1.7.8.p11.0.tar.bz2
>   http://josefsson.org/gnutls/releases/gnutls-1.7.8.p11.0.tar.bz2
>
> Here are GPG detached signatures signed using key 0xB565716F:
>   ftp://ftp.gnutls.org/pub/gnutls/devel/gnutls-1.7.8.p11.0.tar.bz2.sig
>   http://josefsson.org/gnutls/releases/gnutls-1.7.8.p11.0.tar.bz2.sig

Sorry, the https URLs were wrong.  The correct URLs should be:

   http://josefsson.org/gnutls/releases/pkcs11/gnutls-1.7.8.p11.0.tar.bz2
   http://josefsson.org/gnutls/releases/pkcs11/gnutls-1.7.8.p11.0.tar.bz2.sig

/Simon


From wk at gnupg.org  Wed May  2 16:24:15 2007
From: wk at gnupg.org (Werner Koch)
Date: Wed, 02 May 2007 16:24:15 +0200
Subject: [gnutls-dev] GnuTLS 1.7.8.p11.0
In-Reply-To: <877irruyfi.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Wed\, 02 May 2007 15\:50\:41 +0200")
References: <877irruyfi.fsf@mocca.josefsson.org>
Message-ID: <87fy6fjoc0.fsf@wheatstone.g10code.de>

On Wed,  2 May 2007 15:50, simon at josefsson.org said:

> To test it, you'll need to build scute from SVN (because it contains a
> CKA_TRUSTED related fix), and set it up (try using it in mozilla), which
> can be non-trivial.  See the Scute manual.  I generated new keys on an

Shall we do a new release of Scute for that?


Shalom-Salam,

   Werner



From simon at josefsson.org  Wed May  2 17:55:10 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 02 May 2007 17:55:10 +0200
Subject: [gnutls-dev] GnuTLS 1.7.8.p11.0
In-Reply-To: <87fy6fjoc0.fsf@wheatstone.g10code.de> (Werner Koch's message of
	"Wed\, 02 May 2007 16\:24\:15 +0200")
References: <877irruyfi.fsf@mocca.josefsson.org>
	<87fy6fjoc0.fsf@wheatstone.g10code.de>
Message-ID: <87wszrrzj5.fsf@mocca.josefsson.org>

Werner Koch <wk at gnupg.org> writes:

> On Wed,  2 May 2007 15:50, simon at josefsson.org said:
>
>> To test it, you'll need to build scute from SVN (because it contains a
>> CKA_TRUSTED related fix), and set it up (try using it in mozilla), which
>> can be non-trivial.  See the Scute manual.  I generated new keys on an
>
> Shall we do a new release of Scute for that?

Yes, please.  I e-mailed Marcus about it.

/Simon


From simon at josefsson.org  Thu May  3 14:06:42 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 03 May 2007 14:06:42 +0200
Subject: [gnutls-dev] Integrating Guile bindings?
In-Reply-To: <87k5w031dw.fsf@laas.fr> ("Ludovic =?iso-8859-1?Q?Court=E8s?=
	=?iso-8859-1?Q?=22's?= message of "Wed\, 25
	Apr 2007 17\:43\:55 +0200")
References: <87slaqos4h.fsf@laas.fr> <87wt01budh.fsf@mocca.josefsson.org>
	<87fy6odf0w.fsf@laas.fr> <87odlcainn.fsf@mocca.josefsson.org>
	<87mz0w61fq.fsf@laas.fr> <87irbk8spj.fsf@mocca.josefsson.org>
	<878xcg4inw.fsf@laas.fr> <87ejm879q8.fsf@mocca.josefsson.org>
	<87k5w031dw.fsf@laas.fr>
Message-ID: <87fy6e5cx9.fsf@mocca.josefsson.org>

Nobody seems to protest, so let's add the guile bindings.  Ludovic,
could you provide a patch?  Would getting CVS commit access help?  Then
you could install it yourself.  Are you familiar with GIT?  I have been
considering to switch to it for some time, as it makes it easier to
merge patches from various sources/branches, and generally feels
snappier.

/Simon


From ludovic.courtes at laas.fr  Thu May  3 13:24:26 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Thu, 03 May 2007 13:24:26 +0200
Subject: [gnutls-dev] Integrating Guile bindings?
References: <87slaqos4h.fsf@laas.fr> <87wt01budh.fsf@mocca.josefsson.org>
	<87fy6odf0w.fsf@laas.fr> <87odlcainn.fsf@mocca.josefsson.org>
	<87mz0w61fq.fsf@laas.fr> <87irbk8spj.fsf@mocca.josefsson.org>
	<878xcg4inw.fsf@laas.fr> <87ejm879q8.fsf@mocca.josefsson.org>
	<87k5w031dw.fsf@laas.fr> <87fy6e5cx9.fsf@mocca.josefsson.org>
Message-ID: <87ejlyw3o5.fsf@laas.fr>

Hi,

Simon Josefsson <simon at josefsson.org> writes:

> Nobody seems to protest, so let's add the guile bindings.  Ludovic,
> could you provide a patch?

Alright, let's go.  I'll take care of that hopefully in the next few
days or so.

> Would getting CVS commit access help?  Then
> you could install it yourself.  Are you familiar with GIT?  I have been
> considering to switch to it for some time, as it makes it easier to
> merge patches from various sources/branches, and generally feels
> snappier.

Actually, I've been using Arch for several years, but I've been
pondering the idea of switching to GIT (or "Git", whatever) recently.
So if you're willing to switch, I'd be happy with that, probably happier
than with CVS anyway.  ;-)

Otherwise, if you don't want to switch right now, I can cope with CVS.

Thanks,
Ludovic.



From simon at josefsson.org  Thu May  3 15:53:52 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 03 May 2007 15:53:52 +0200
Subject: [gnutls-dev] Integrating Guile bindings?
In-Reply-To: <87ejlyw3o5.fsf@laas.fr> ("Ludovic =?iso-8859-1?Q?Court=E8s?=
	=?iso-8859-1?Q?=22's?= message of "Thu\, 03
	May 2007 13\:24\:26 +0200")
References: <87slaqos4h.fsf@laas.fr> <87wt01budh.fsf@mocca.josefsson.org>
	<87fy6odf0w.fsf@laas.fr> <87odlcainn.fsf@mocca.josefsson.org>
	<87mz0w61fq.fsf@laas.fr> <87irbk8spj.fsf@mocca.josefsson.org>
	<878xcg4inw.fsf@laas.fr> <87ejm879q8.fsf@mocca.josefsson.org>
	<87k5w031dw.fsf@laas.fr> <87fy6e5cx9.fsf@mocca.josefsson.org>
	<87ejlyw3o5.fsf@laas.fr>
Message-ID: <87k5vq2etr.fsf@mocca.josefsson.org>

ludovic.courtes at laas.fr (Ludovic Court?s) writes:

> Hi,
>
> Simon Josefsson <simon at josefsson.org> writes:
>
>> Nobody seems to protest, so let's add the guile bindings.  Ludovic,
>> could you provide a patch?
>
> Alright, let's go.  I'll take care of that hopefully in the next few
> days or so.

Great!

>> Would getting CVS commit access help?  Then
>> you could install it yourself.  Are you familiar with GIT?  I have been
>> considering to switch to it for some time, as it makes it easier to
>> merge patches from various sources/branches, and generally feels
>> snappier.
>
> Actually, I've been using Arch for several years, but I've been
> pondering the idea of switching to GIT (or "Git", whatever) recently.
> So if you're willing to switch, I'd be happy with that, probably happier
> than with CVS anyway.  ;-)
>
> Otherwise, if you don't want to switch right now, I can cope with CVS.

I'll see if I can set up a Git<->CVS gateway using repo.or.cz quickly,
and then we can use it as a test whether migrating to Git will work or
not.  What do you think?

Btw, what I particulary like with Git is that it duplicates the entire
repository locally, which makes 'git-diff' very quick.  That is
important when I will be working from my summer house over a GSM
dialup...

/Simon


From ludovic.courtes at laas.fr  Thu May  3 17:12:04 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Thu, 03 May 2007 17:12:04 +0200
Subject: [gnutls-dev] Integrating Guile bindings?
References: <87slaqos4h.fsf@laas.fr> <87wt01budh.fsf@mocca.josefsson.org>
	<87fy6odf0w.fsf@laas.fr> <87odlcainn.fsf@mocca.josefsson.org>
	<87mz0w61fq.fsf@laas.fr> <87irbk8spj.fsf@mocca.josefsson.org>
	<878xcg4inw.fsf@laas.fr> <87ejm879q8.fsf@mocca.josefsson.org>
	<87k5w031dw.fsf@laas.fr> <87fy6e5cx9.fsf@mocca.josefsson.org>
	<87ejlyw3o5.fsf@laas.fr> <87k5vq2etr.fsf@mocca.josefsson.org>
Message-ID: <87y7k6szzv.fsf@laas.fr>

Simon Josefsson <simon at josefsson.org> writes:

> I'll see if I can set up a Git<->CVS gateway using repo.or.cz quickly,
> and then we can use it as a test whether migrating to Git will work or
> not.  What do you think?

Sounds like a good plan to me.

That said, being only an occasional contributor (at best), I'm not sure
my opinion matters that much.  ;-)

> Btw, what I particulary like with Git is that it duplicates the entire
> repository locally, which makes 'git-diff' very quick.  That is
> important when I will be working from my summer house over a GSM
> dialup...

Yes, speed and seamless disconnected operation are the main reasons for
me to switch.  Well, speed, really.

Thanks,
Ludovic.



From simon at josefsson.org  Thu May  3 18:01:03 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 03 May 2007 18:01:03 +0200
Subject: [gnutls-dev] GnuTLS 1.7.8.p11.0
In-Reply-To: <877irruyfi.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Wed\, 02 May 2007 15\:50\:41 +0200")
References: <877irruyfi.fsf@mocca.josefsson.org>
Message-ID: <87lkg528xs.fsf@mocca.josefsson.org>

Simon Josefsson <simon at josefsson.org> writes:

> To test it, you'll need to build scute from SVN (because it contains a
> CKA_TRUSTED related fix)

Scute 1.1.0 has been released, so you don't need to build from SVN.  Get
it from: ftp://ftp.gnupg.org/gcrypt/scute

Having Debian packages of Scute would be welcome...

/Simon


From simon at josefsson.org  Thu May  3 19:52:05 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 03 May 2007 19:52:05 +0200
Subject: [gnutls-dev] OpenCDK 0.6.0 problems
In-Reply-To: <878xc5hkc0.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Thu\, 03 May 2007 19\:45\:51 +0200")
References: <46377548.7060109@gmx.net> <878xc5hkc0.fsf@mocca.josefsson.org>
Message-ID: <871whxhk1m.fsf_-_@mocca.josefsson.org>

I installed a tiny patch to fix some build problems of 0.6.0 under
mingw32:

/bin/sh ../libtool --tag=CC   --mode=link i586-mingw32msvc-gcc  -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -no-undefined -export-symbols ../../../src/opencdk-0.6.0/src/opencdk.def -version-info 10:0:0   -o libopencdk.la -rpath /home/jas/gnutls4win/inst/lib new-packet.lo read-packet.lo proc-packet.lo write-packet.lo main.lo verify.lo armor.lo sig-check.lo sign.lo keydb.lo keylist.lo seskey.lo pubkey.lo misc.lo encrypt.lo trustdb.lo kbnode.lo compress.lo literal.lo cipher.lo stream.lo stream-socket.lo keyserver.lo keygen.lo -L/home/jas/gnutls4win/inst/lib -lgcrypt -L/home/jas/gnutls4win/inst/lib -lgpg-error -lws2_32
libtool: link: symbol file `../../../src/opencdk-0.6.0/src/opencdk.def' does not exist
make[2]: *** [libopencdk.la] Error 1
make[2]: Leaving directory `/home/jas/gnutls4win/build/opencdk-0.6.0/src'

However, 'make check' doesn't work under mingw32 any more:

make[2]: Entering directory `/home/jas/gnutls4win/build/opencdk-0.6.0/tests'
fixme:msvcrt:MSVCRT__sopen : pmode 0x615196d8 ignored
../../../src/opencdk-0.6.0/tests/t-stream.c:114 temp FAILED
Wine failed with return code 1
FAIL: t-stream.exe
fixme:msvcrt:MSVCRT__sopen : pmode 0x0001 ignored
../../../src/opencdk-0.6.0/tests/t-sign.c:131 plain-test.gpg: FAILED
fixme:msvcrt:MSVCRT__sopen : pmode 0x615196d8 ignored
../../../src/opencdk-0.6.0/tests/t-sign.c:131 plain-test-cs.asc: FAILED
../../../src/opencdk-0.6.0/tests/t-sign.c:131 plain-test.sig: FAILED
fixme:msvcrt:MSVCRT__sopen : pmode 0x40343de8 ignored
../../../src/opencdk-0.6.0/tests/t-sign.c: 209 sign enc FAILED
Wine failed with return code 4
FAIL: t-sign.exe
fixme:msvcrt:MSVCRT__sopen : pmode 0x4075dcb8 ignored
../../../src/opencdk-0.6.0/tests/t-key.c:248 pub-asc.gpg:CCC07C35: FAILED
fixme:msvcrt:MSVCRT__sopen : pmode 0x615196d8 ignored
fixme:msvcrt:MSVCRT__sopen : pmode 0x615196d8 ignored
../../../src/opencdk-0.6.0/tests/t-key.c:407 photo-id key FAILED
Wine failed with return code 2
FAIL: t-key.exe
fixme:msvcrt:MSVCRT__sopen : pmode 0x4075f598 ignored
../../../src/opencdk-0.6.0/tests/t-encr.c:205 plain-test-sym.gpg: Permission denied FAILED
fixme:msvcrt:MSVCRT__sopen : pmode 0x6e0072 ignored
fixme:msvcrt:MSVCRT__sopen : pmode 0x4075d4a4 ignored
fixme:toolhelp:CreateToolhelp32Snapshot Unimplemented: heap list snapshot
fixme:toolhelp:Heap32ListFirst : stub
DBG: rndw32: get performance data problem
fixme:process:GetProcessWorkingSetSize (0xffffffff,0x4075eff0,0x4075eff4): stub
fixme:msvcrt:MSVCRT__sopen : pmode 0x4075f598 ignored
../../../src/opencdk-0.6.0/tests/t-encr.c:205 plain-test-pubenc-part.gpg: Permission denied FAILED
fixme:msvcrt:MSVCRT__sopen : pmode 0x615196d8 ignored
../../../src/opencdk-0.6.0/tests/t-encr.c:391 decrypt FAILED
fixme:msvcrt:MSVCRT__sopen : pmode 0x615196d8 ignored
../../../src/opencdk-0.6.0/tests/t-encr.c: 398 handle FAILED
fixme:msvcrt:MSVCRT__sopen : pmode 0x615196d8 ignored
../../../src/opencdk-0.6.0/tests/t-encr.c: 405 illegal FAILED
fixme:msvcrt:MSVCRT__sopen : pmode 0x615196d8 ignored
../../../src/opencdk-0.6.0/tests/t-encr.c:368 transform encrypt FAILED
fixme:msvcrt:MSVCRT__sopen : pmode 0x615196d8 ignored
../../../src/opencdk-0.6.0/tests/t-encr.c:368 transform encrypt FAILED
fixme:msvcrt:MSVCRT__sopen : pmode 0x615196d8 ignored
../../../src/opencdk-0.6.0/tests/t-encr.c:379 transform sym FAILED
Wine failed with return code 8
FAIL: t-encr.exe
fixme:msvcrt:MSVCRT__sopen : pmode 0x0001 ignored
../../../src/opencdk-0.6.0/tests/t-keydb.c: 349 search asc file FAILED
fixme:msvcrt:MSVCRT__sopen : pmode 0x615196d8 ignored
../../../src/opencdk-0.6.0/tests/t-keydb.c: 356 search asc data FAILED
fixme:msvcrt:MSVCRT__sopen : pmode 0x615196d8 ignored
../../../src/opencdk-0.6.0/tests/t-keydb.c: 371 asc tmp read FAILED
Wine failed with return code 3
FAIL: t-keydb.exe
Wine exited with a successful status
PASS: t-misc.exe
OpenCDK header version 0.6.0.
OpenCDK library version 0.6.0.
Wine exited with a successful status
PASS: basic.exe
================================
5 of 7 tests failed
Please report to twoaday at gmx.net
================================
make[2]: *** [check-TESTS] Error 1
make[2]: Leaving directory `/home/jas/gnutls4win/build/opencdk-0.6.0/tests'

Ideas?

/Simon


From simon at josefsson.org  Thu May  3 19:56:07 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 03 May 2007 19:56:07 +0200
Subject: [gnutls-dev] OpenCDK sync
Message-ID: <87wszpg5ag.fsf@mocca.josefsson.org>

Timo, the OpenCDK copy in GnuTLS CVS trunk (which claim to be 0.6.0 in
its opencdk.h) seem to differ from the released 0.6.0.  Do you want to
update the OpenCDK copy in GnuTLS so it matches 0.6.0?

/Simon


From alon.barlev at gmail.com  Thu May  3 22:45:23 2007
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Thu, 3 May 2007 23:45:23 +0300
Subject: [gnutls-dev] GnuTLS 1.7.8.p11.0
In-Reply-To: <877irruyfi.fsf@mocca.josefsson.org>
References: <877irruyfi.fsf@mocca.josefsson.org>
Message-ID: <9e0cf0bf0705031345t380e9940sfa61e853fea4b262@mail.gmail.com>

Hello,

I was about to get this implementation and suggest an alternative,
only to discover that you are not doing any private key operations.

So there is no implementation to modify, and I don't wish to re-write
the large part of GnuTLS code.

So I ask you again, please implement a callback structure for engines,
this callback should have the following methods:

typedef struct {
   void *user_data;
   int (*init)(void *user_data);
   int (*cleanup)(void *user_data);
   int (*sign)(void *user_data, int algorithm, size_t input_size,
const unsigned char * const input, size_t *output_size, unsigned char
* const output);
   int (*decrypt)(void *user_data, int algorithm, size_t input_size,
const unsigned char * const input, size_t *output_size, unsigned char
* const output);
} engine_t;

Provide a replacement function for:
gnutls_certificate_set_x509_key_file ()
Something like:
gnutls_certificate_set_x509_key_engine
(gnutls_certificate_credentials_t res, engine_t *engine)

This will allow application to enumerate the token certificates, set
the trust correctly by using the regular
gnutls_certificate_set_x509_trust_file() call, and handle the
sign/decrypt in any way it likes... One implementation may be PKCS#11.

As I said before, if you provide such interface, I will provide a
*COMPLETE* and *WORKING* PKCS#11 support for GnuTLS, after a day or
two.

It will also clean up your implementation, and allow many other
engines to be added.

Another alternative is to wait for you to have a remotely working
solution, and create a patch for the above (this is what I intended to
do now...), but it would be much cleaner if you create the interface
as you know GnuTLS best, and it will save a lot of work for all.

Please consider to cooperate, you loose nothing, as you will be able
to use the same interface for your implementation as-well.

Best Regards,
Alon Bar-Lev.

On 5/2/07, Simon Josefsson <simon at josefsson.org> wrote:
> Here is the first release on the PKCS#11 branch.  The support is
> currently rather limited, but I decided to make a release early to
> invite more feedback.  The NEWS entry is:
>
> * Version 1.7.8.p11.0 (released 2007-05-02)
>
> ** New function to get trusted CA certificates from PKCS#11 provider.
>
> ** API and ABI modifications:
> gnutls_pkcs11_get_ca_certificates: ADD.
>
> Warning!  This is even more experimental than the experimental 1.7.x
> branch.  However, the changes compared to 1.7.8 are intentionally kept
> minimal, to facilitate easy merging later on.
>
> The support is limited to:
>
> 1) Support for build-time linking to the PKCS#11 provider scute, see
>    http://www.scute.org/.
>
> 2) Retrieving trusted CA certificates from the PKCS#11 provider.
>
> To test it, you'll need to build scute from SVN (because it contains a
> CKA_TRUSTED related fix), and set it up (try using it in mozilla), which
> can be non-trivial.  See the Scute manual.  I generated new keys on an
> OpenPGP smartcard with gpg2 --edit-card and gpgsm-gencert.sh, then
> signed the CSR with certtool using the GnuTLS test CA, and imported the
> certificates using 'gpgsm --import'.
>
> If someone can explain to me how I can test other PKCS#11 providers, I
> can test them too.  Supporting the NSS soft token provider is an
> important target.
>
> The gnutls-cli tool in this release automatically import all CAs from
> Scute, and here is an output from running it against the GnuTLS test
> server:
>
> jas at mocca:~$ ~/src/gnutls-pkcs11/src/gnutls-cli --port 5556 test.gnutls.org --ctypes x509
> Resolving 'test.gnutls.org'...
> Connecting to '217.13.230.178:5556'...
> ...
> - Successfully sent 0 certificate(s) to server.
> - Certificate type: X.509
>  - Got a certificate list of 1 certificates.
>
>  - Certificate[0] info:
>  # The hostname in the certificate matches 'test.gnutls.org'.
>  # valid since: Wed Apr 18 15:29:21 CEST 2007
>  # expires at: Thu Apr 17 15:29:21 CEST 2008
>  # fingerprint: 08:8B:4B:0F:68:88:4E:95:15:D6:AC:F6:B3:64:81:5B
>  # Subject's DN: O=GnuTLS test server,CN=test.gnutls.org
>  # Issuer's DN: CN=GnuTLS test CA
>
>
> - Peer's certificate is trusted
> - Version: TLS 1.2
> - Key Exchange: DHE RSA
> - Cipher: AES 256 CBC
> - MAC: SHA
> - Compression: DEFLATE
> - Handshake was completed
> ...
>
> Notice that it says the peer's certificate is trusted, without any
> --x509certfile.  The GnuTLS CA is retrieved from Scute.  To debug
> things, add a '-d 10' and you'll see some debug info:
>
> |<2>| PKCS#11 slot count 1
> |<2>| PKCS#11 slot[1].description: `GnuPG Smart Card Daemon                                         g10 Code GmbH                   '
> |<2>| PKCS#11 slot[1].manufacturer: `g10 Code GmbH                   '
> |<2>| PKCS#11 slot[1].token.label: `D2760001240101010001000005320000PPC Card Systems                OpenPGP         00000532
> '
> |<2>| Adding CA certificate 1532B4BA5A8A7988CA264283591BA3A21C0BCC24 (0)
> |<2>| Skipping certificate BD5F80DE63034EC9E2841E6309552E345C5F226F (0/0)
>
> Here the 1532B4BA5A8A7988CA264283591BA3A21C0BCC24 certificate is the
> GnuTLS CA, and the BD5F80DE63034EC9E2841E6309552E345C5F226F certificate
> is my client certificate (which is not used as a trusted root).
>
> Here are the compressed sources (4.3MB):
>   ftp://ftp.gnutls.org/pub/gnutls/devel/gnutls-1.7.8.p11.0.tar.bz2
>   http://josefsson.org/gnutls/releases/gnutls-1.7.8.p11.0.tar.bz2
>
> Here are GPG detached signatures signed using key 0xB565716F:
>   ftp://ftp.gnutls.org/pub/gnutls/devel/gnutls-1.7.8.p11.0.tar.bz2.sig
>   http://josefsson.org/gnutls/releases/gnutls-1.7.8.p11.0.tar.bz2.sig
>
> Here are the SHA-1 and SHA-224 checksums:
>
> 9fe33805fb5083f5db7be2a3861b2cbd24e818da  gnutls-1.7.8.p11.0.tar.bz2
> 07cf60a582e8a83c10c13e60b6817c6329630f9f  gnutls-1.7.8.p11.0.tar.bz2.sig
>
> 31abe6790b26eb35964cb14a7b56cd2ad96cdbd29a1c732ad4b7cfae  gnutls-1.7.8.p11.0.tar.bz2
> bd957671b09205c4e6622f438939c311af8401ebf504e0de7f4ad887  gnutls-1.7.8.p11.0.tar.bz2.sig
>
> Improving GnuTLS is costly, but you can help!  We are looking for
> organizations that find GnuTLS useful and wish to contribute back.
> You can contribute by reporting bugs, improve the software, or donate
> money or equipment.
>
> Commercial support contracts for GnuTLS are available, and they help
> finance continued maintenance.  Simon Josefsson Datakonsult, a
> Stockholm based privately held company, is currently funding GnuTLS
> maintenance.  We are always looking for interesting development
> projects.  See http://josefsson.org/ for more details.
>
> /Simon
>
> _______________________________________________
> Gnutls-dev mailing list
> Gnutls-dev at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnutls-dev
>
>
>


From simon at josefsson.org  Fri May  4 14:06:05 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 04 May 2007 14:06:05 +0200
Subject: [gnutls-dev] GnuTLS 1.7.8.p11.0
In-Reply-To: <9e0cf0bf0705031345t380e9940sfa61e853fea4b262@mail.gmail.com>
	(Alon Bar-Lev's message of "Thu\, 3 May 2007 23\:45\:23 +0300")
References: <877irruyfi.fsf@mocca.josefsson.org>
	<9e0cf0bf0705031345t380e9940sfa61e853fea4b262@mail.gmail.com>
Message-ID: <87r6pw7pzm.fsf@mocca.josefsson.org>

"Alon Bar-Lev" <alon.barlev at gmail.com> writes:

> Hello,
>
> I was about to get this implementation and suggest an alternative,
> only to discover that you are not doing any private key operations.

Hi!  Right.  I wanted to get things out as soon as possible, and right
now getting the CA trust stuff is all that I can show to be working.

> So there is no implementation to modify, and I don't wish to re-write
> the large part of GnuTLS code.
>
> So I ask you again, please implement a callback structure for engines,
> this callback should have the following methods:
>
> typedef struct {
>    void *user_data;
>    int (*init)(void *user_data);
>    int (*cleanup)(void *user_data);
>    int (*sign)(void *user_data, int algorithm, size_t input_size,
> const unsigned char * const input, size_t *output_size, unsigned char
> * const output);
>    int (*decrypt)(void *user_data, int algorithm, size_t input_size,
> const unsigned char * const input, size_t *output_size, unsigned char
> * const output);
> } engine_t;
>
> Provide a replacement function for:
> gnutls_certificate_set_x509_key_file ()
> Something like:
> gnutls_certificate_set_x509_key_engine
> (gnutls_certificate_credentials_t res, engine_t *engine)

It will be something like that.  It may start out as somewhat simpler,
to better fit with how the GnuTLS API works today: right now
applications can be invoked with a callback to retrieve the appropriate
cert+key.  They need some function to get the user certificates and key
handles from the PKCS#11 layer.  I'm thinking this interface will be:

  int gnutls_pkcs11_get_user_certificates (gnutls_x509_crt_t ** cert_list,
						unsigned int *ncerts);

Or similar.

When an application, in the certificate callback, indicate that the
private key is 'NULL', they will have to provider another callback to
perform the sign operation, otherwise the user certificate will be
ignored.  That function should likely receive the user certificate or
similar.  GnuTLS should have an API available to perform the sign
operation using PKCS#11, but it could also let the application perform
the sign operation in any way it chose.  This way, the interface will
not be specific to PKCS#11, but it will be easy to make PKCS#11 work.

> This will allow application to enumerate the token certificates, set
> the trust correctly by using the regular
> gnutls_certificate_set_x509_trust_file() call, and handle the
> sign/decrypt in any way it likes... One implementation may be PKCS#11.

I started providing such an API, but then I realized that it doesn't
work with the callback approach that GnuTLS offers.
gnutls_certificate_set_key etc doesn't do anything if used within a
callback.  Hence the current more flexible approach, which doesn't
involve modifying the gnutls_certificate_* functions or structures.

> As I said before, if you provide such interface, I will provide a
> *COMPLETE* and *WORKING* PKCS#11 support for GnuTLS, after a day or
> two.
>
> It will also clean up your implementation, and allow many other
> engines to be added.
>
> Another alternative is to wait for you to have a remotely working
> solution, and create a patch for the above (this is what I intended to
> do now...), but it would be much cleaner if you create the interface
> as you know GnuTLS best, and it will save a lot of work for all.
>
> Please consider to cooperate, you loose nothing, as you will be able
> to use the same interface for your implementation as-well.

Of course!  I think the best is for me to produce an API that works for
me and fits with how GnuTLS works.  I believe it will be quite close to
what you need, even if not perfectly the same.  The API will not be
fixed until it is merged into the normal experimental branch.  There
will be several iterations of release on the PKCS#11 branch until that
happens, and your input is valuable here.  I think it would be useful to
demonstrate interoperability with at least some other PKCS#11 provider
than Scute until the API is ready.

Regards,
Simon

> Best Regards,
> Alon Bar-Lev.
>
> On 5/2/07, Simon Josefsson <simon at josefsson.org> wrote:
>> Here is the first release on the PKCS#11 branch.  The support is
>> currently rather limited, but I decided to make a release early to
>> invite more feedback.  The NEWS entry is:
>>
>> * Version 1.7.8.p11.0 (released 2007-05-02)
>>
>> ** New function to get trusted CA certificates from PKCS#11 provider.
>>
>> ** API and ABI modifications:
>> gnutls_pkcs11_get_ca_certificates: ADD.
>>
>> Warning!  This is even more experimental than the experimental 1.7.x
>> branch.  However, the changes compared to 1.7.8 are intentionally kept
>> minimal, to facilitate easy merging later on.
>>
>> The support is limited to:
>>
>> 1) Support for build-time linking to the PKCS#11 provider scute, see
>>    http://www.scute.org/.
>>
>> 2) Retrieving trusted CA certificates from the PKCS#11 provider.
>>
>> To test it, you'll need to build scute from SVN (because it contains a
>> CKA_TRUSTED related fix), and set it up (try using it in mozilla), which
>> can be non-trivial.  See the Scute manual.  I generated new keys on an
>> OpenPGP smartcard with gpg2 --edit-card and gpgsm-gencert.sh, then
>> signed the CSR with certtool using the GnuTLS test CA, and imported the
>> certificates using 'gpgsm --import'.
>>
>> If someone can explain to me how I can test other PKCS#11 providers, I
>> can test them too.  Supporting the NSS soft token provider is an
>> important target.
>>
>> The gnutls-cli tool in this release automatically import all CAs from
>> Scute, and here is an output from running it against the GnuTLS test
>> server:
>>
>> jas at mocca:~$ ~/src/gnutls-pkcs11/src/gnutls-cli --port 5556 test.gnutls.org --ctypes x509
>> Resolving 'test.gnutls.org'...
>> Connecting to '217.13.230.178:5556'...
>> ...
>> - Successfully sent 0 certificate(s) to server.
>> - Certificate type: X.509
>>  - Got a certificate list of 1 certificates.
>>
>>  - Certificate[0] info:
>>  # The hostname in the certificate matches 'test.gnutls.org'.
>>  # valid since: Wed Apr 18 15:29:21 CEST 2007
>>  # expires at: Thu Apr 17 15:29:21 CEST 2008
>>  # fingerprint: 08:8B:4B:0F:68:88:4E:95:15:D6:AC:F6:B3:64:81:5B
>>  # Subject's DN: O=GnuTLS test server,CN=test.gnutls.org
>>  # Issuer's DN: CN=GnuTLS test CA
>>
>>
>> - Peer's certificate is trusted
>> - Version: TLS 1.2
>> - Key Exchange: DHE RSA
>> - Cipher: AES 256 CBC
>> - MAC: SHA
>> - Compression: DEFLATE
>> - Handshake was completed
>> ...
>>
>> Notice that it says the peer's certificate is trusted, without any
>> --x509certfile.  The GnuTLS CA is retrieved from Scute.  To debug
>> things, add a '-d 10' and you'll see some debug info:
>>
>> |<2>| PKCS#11 slot count 1
>> |<2>| PKCS#11 slot[1].description: `GnuPG Smart Card Daemon                                         g10 Code GmbH                   '
>> |<2>| PKCS#11 slot[1].manufacturer: `g10 Code GmbH                   '
>> |<2>| PKCS#11 slot[1].token.label: `D2760001240101010001000005320000PPC Card Systems                OpenPGP         00000532
>> '
>> |<2>| Adding CA certificate 1532B4BA5A8A7988CA264283591BA3A21C0BCC24 (0)
>> |<2>| Skipping certificate BD5F80DE63034EC9E2841E6309552E345C5F226F (0/0)
>>
>> Here the 1532B4BA5A8A7988CA264283591BA3A21C0BCC24 certificate is the
>> GnuTLS CA, and the BD5F80DE63034EC9E2841E6309552E345C5F226F certificate
>> is my client certificate (which is not used as a trusted root).
>>
>> Here are the compressed sources (4.3MB):
>>   ftp://ftp.gnutls.org/pub/gnutls/devel/gnutls-1.7.8.p11.0.tar.bz2
>>   http://josefsson.org/gnutls/releases/gnutls-1.7.8.p11.0.tar.bz2
>>
>> Here are GPG detached signatures signed using key 0xB565716F:
>>   ftp://ftp.gnutls.org/pub/gnutls/devel/gnutls-1.7.8.p11.0.tar.bz2.sig
>>   http://josefsson.org/gnutls/releases/gnutls-1.7.8.p11.0.tar.bz2.sig
>>
>> Here are the SHA-1 and SHA-224 checksums:
>>
>> 9fe33805fb5083f5db7be2a3861b2cbd24e818da  gnutls-1.7.8.p11.0.tar.bz2
>> 07cf60a582e8a83c10c13e60b6817c6329630f9f  gnutls-1.7.8.p11.0.tar.bz2.sig
>>
>> 31abe6790b26eb35964cb14a7b56cd2ad96cdbd29a1c732ad4b7cfae  gnutls-1.7.8.p11.0.tar.bz2
>> bd957671b09205c4e6622f438939c311af8401ebf504e0de7f4ad887  gnutls-1.7.8.p11.0.tar.bz2.sig
>>
>> Improving GnuTLS is costly, but you can help!  We are looking for
>> organizations that find GnuTLS useful and wish to contribute back.
>> You can contribute by reporting bugs, improve the software, or donate
>> money or equipment.
>>
>> Commercial support contracts for GnuTLS are available, and they help
>> finance continued maintenance.  Simon Josefsson Datakonsult, a
>> Stockholm based privately held company, is currently funding GnuTLS
>> maintenance.  We are always looking for interesting development
>> projects.  See http://josefsson.org/ for more details.
>>
>> /Simon
>>
>> _______________________________________________
>> Gnutls-dev mailing list
>> Gnutls-dev at gnupg.org
>> http://lists.gnupg.org/mailman/listinfo/gnutls-dev
>>
>>
>>


From twoaday at gmx.net  Fri May  4 14:49:53 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Fri, 04 May 2007 14:49:53 +0200
Subject: [gnutls-dev] OpenCDK sync
In-Reply-To: <87wszpg5ag.fsf@mocca.josefsson.org>
References: <87wszpg5ag.fsf@mocca.josefsson.org>
Message-ID: <463B2BF1.7050709@gmx.net>

Simon Josefsson wrote:

> Timo, the OpenCDK copy in GnuTLS CVS trunk (which claim to be 0.6.0 in
> its opencdk.h) seem to differ from the released 0.6.0.  Do you want to
> update the OpenCDK copy in GnuTLS so it matches 0.6.0?

Yes, I will do this. But first I need to find out if we can still use
a stripped version of opencdk. If not, I will put a copy of the src
files in the gnutls opencdk folder and commit the changes.


	Timo


From alon.barlev at gmail.com  Fri May  4 14:31:37 2007
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Fri, 4 May 2007 15:31:37 +0300
Subject: [gnutls-dev] GnuTLS 1.7.8.p11.0
In-Reply-To: <87r6pw7pzm.fsf@mocca.josefsson.org>
References: <877irruyfi.fsf@mocca.josefsson.org>
	<9e0cf0bf0705031345t380e9940sfa61e853fea4b262@mail.gmail.com>
	<87r6pw7pzm.fsf@mocca.josefsson.org>
Message-ID: <9e0cf0bf0705040531h4cb99e4dl3e469afa5d3b98dd@mail.gmail.com>

On 5/4/07, Simon Josefsson <simon at josefsson.org> wrote:
> "Alon Bar-Lev" <alon.barlev at gmail.com> writes:
>
> > Hello,
> >
> > I was about to get this implementation and suggest an alternative,
> > only to discover that you are not doing any private key operations.
>
> Hi!  Right.  I wanted to get things out as soon as possible, and right
> now getting the CA trust stuff is all that I can show to be working.

As I said before... Most tokens do not hold certificate chain within
them, it is just a waste of memory when you have 16K, 32K or 64K.
Also I already warned you that this is highly insecure... Since anyone
can store whatever certificates as public objects, thus modifying the
trust.

> It will be something like that.  It may start out as somewhat simpler,
> to better fit with how the GnuTLS API works today: right now
> applications can be invoked with a callback to retrieve the appropriate
> cert+key.  They need some function to get the user certificates and key
> handles from the PKCS#11 layer.  I'm thinking this interface will be:
>
>   int gnutls_pkcs11_get_user_certificates (gnutls_x509_crt_t ** cert_list,
>                                                 unsigned int *ncerts);

But you will be able to to implement the above using the API I suggested.
As I see it you can have the PKCS#11 stuff maintained separately, as
an optional components, something like gnutls-pkcs11 that will use the
engine API in order to add the above function.

You also don't handle much of the issues related of token management...
1. Tokens are ****SLOW***** enumerating the certificates takes
****LONG**** time.
2. Tokens are dynamic, you can remove them and insert them, so
enumerating all available tokens every time is not wise.
3. You may have more than one token available at the same time, you
may need to handle this state.
4. As I understand from your API documentation, gnutls_x509_crt_t  has
nothing to do with the private key, which is the one that really
important when you handle hardware tokens.

> When an application, in the certificate callback, indicate that the
> private key is 'NULL', they will have to provider another callback to
> perform the sign operation, otherwise the user certificate will be
> ignored.  That function should likely receive the user certificate or
> similar.  GnuTLS should have an API available to perform the sign
> operation using PKCS#11, but it could also let the application perform
> the sign operation in any way it chose.  This way, the interface will
> not be specific to PKCS#11, but it will be easy to make PKCS#11 work.

I don't understand the above... How do you set the callback in the
certificate object?
How do you set user defined data for the callback to be used?
I did not see this in the GnuTLS documentation.

Anyway... I think that your implementation should not be differnet
than any other one.
If you have such a generic mechanism, use it, don't implement two
different methods.

> I started providing such an API, but then I realized that it doesn't
> work with the callback approach that GnuTLS offers.
> gnutls_certificate_set_key etc doesn't do anything if used within a
> callback.  Hence the current more flexible approach, which doesn't
> involve modifying the gnutls_certificate_* functions or structures.

OK... But as I said... It is the least important... :)

> > As I said before, if you provide such interface, I will provide a
> > *COMPLETE* and *WORKING* PKCS#11 support for GnuTLS, after a day or
> > two.
> >
> > It will also clean up your implementation, and allow many other
> > engines to be added.
> >
> > Another alternative is to wait for you to have a remotely working
> > solution, and create a patch for the above (this is what I intended to
> > do now...), but it would be much cleaner if you create the interface
> > as you know GnuTLS best, and it will save a lot of work for all.
> >
> > Please consider to cooperate, you loose nothing, as you will be able
> > to use the same interface for your implementation as-well.
>
> Of course!  I think the best is for me to produce an API that works for
> me and fits with how GnuTLS works.  I believe it will be quite close to
> what you need, even if not perfectly the same.  The API will not be
> fixed until it is merged into the normal experimental branch.  There
> will be several iterations of release on the PKCS#11 branch until that
> happens, and your input is valuable here.  I think it would be useful to
> demonstrate interoperability with at least some other PKCS#11 provider
> than Scute until the API is ready.

All I suggest is an API that fits GnuTLS!
But I suggest that the low-level PKCS#11 will reuse current effort and
knowledge.
Also I think it would be best if the PKCS#11 support will be provided
as a separate library, that uses GnuTLS API.

The functions:
gnutls_pkcs11_set_config() /* Set providers and parameters */
gnutls_pkcs11_enum_certificates() /* Enumerate available certificates */
gnutls_pkcs11_serialize_certificate() /* Serialize specific
certificate so we don't need enum again */
gnutls_pkcs11_deserialize_certificate() /* Deserialize certificate,
good for configuration files */

Can be implemented using PKCS#11 code and GnuTLS with engine API as a
separate library.

Also, if you would like to be more generic you should provide an
engines much more powerful and allow gnutls to serialize/deserialize
any certificate includeing the engine specific information, and allow
callbacks for an engine to enumerate certificates.

Best Regards,
Alon Bar-Lev.


From twoaday at gmx.net  Fri May  4 14:49:01 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Fri, 04 May 2007 14:49:01 +0200
Subject: [gnutls-dev] OpenCDK 0.6.0 problems
In-Reply-To: <871whxhk1m.fsf_-_@mocca.josefsson.org>
References: <46377548.7060109@gmx.net> <878xc5hkc0.fsf@mocca.josefsson.org>
	<871whxhk1m.fsf_-_@mocca.josefsson.org>
Message-ID: <463B2BBD.2010108@gmx.net>

Simon Josefsson wrote:

> /bin/sh ../libtool --tag=CC   --mode=link i586-mingw32msvc-gcc  -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -no-undefined -export-symbols ../../../src/opencdk-0.6.0/src/opencdk.def -version-info 10:0:0   -o libopencdk.la -rpath /home/jas/gnutls4win/inst/lib new-packet.lo read-packet.lo proc-packet.lo write-packet.lo main.lo verify.lo armor.lo sig-check.lo sign.lo keydb.lo keylist.lo seskey.lo pubkey.lo misc.lo encrypt.lo trustdb.lo kbnode.lo compress.lo literal.lo cipher.lo stream.lo stream-socket.lo keyserver.lo keygen.lo -L/home/jas/gnutls4win/inst/lib -lgcrypt -L/home/jas/gnutls4win/inst/lib -lgpg-error -lws2_32
> libtool: link: symbol file `../../../src/opencdk-0.6.0/src/opencdk.def' does not exist
> make[2]: *** [libopencdk.la] Error 1
> make[2]: Leaving directory `/home/jas/gnutls4win/build/opencdk-0.6.0/src'

Oh, I assumed that the integrated version would be build as a static
lib. Now that I see the error, I'm not sure if we can still use a
stripped version of opencdk.


> However, 'make check' doesn't work under mingw32 any more:
> 
> make[2]: Entering directory `/home/jas/gnutls4win/build/opencdk-0.6.0/tests'

I definitely need to check the code for the mingw32 build. I made a
'make distcheck' but I did not test the mingw32 build.

I will do some tests right now.


	Timo



From twoaday at gmx.net  Fri May  4 15:28:24 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Fri, 04 May 2007 15:28:24 +0200
Subject: [gnutls-dev] OpenCDK 0.6.0 problems
In-Reply-To: <463B2BBD.2010108@gmx.net>
References: <46377548.7060109@gmx.net>
	<878xc5hkc0.fsf@mocca.josefsson.org>	<871whxhk1m.fsf_-_@mocca.josefsson.org>
	<463B2BBD.2010108@gmx.net>
Message-ID: <463B34F8.70607@gmx.net>

Timo Schulz wrote:

>> However, 'make check' doesn't work under mingw32 any more:
>>
>> make[2]: Entering directory `/home/jas/gnutls4win/build/opencdk-0.6.0/tests'
> 
> I definitely need to check the code for the mingw32 build. I made a
> 'make distcheck' but I did not test the mingw32 build.
> 
> I will do some tests right now.

I did some tests and it seems my wine environment is not properly
initialized. The reason why all the tests are failing is that
the mapping of 'FILE *tmpfile (void)' fails.

IMHO wine supports the tmpfile() mapping because opencdk uses this
functions since the begin and older gnutls(win32) builds are working.


	Timo


From twoaday at gmx.net  Fri May  4 15:53:06 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Fri, 04 May 2007 15:53:06 +0200
Subject: [gnutls-dev] opencdk: mingw32 make check
Message-ID: <463B3AC2.2060409@gmx.net>


Hi!

It seems there are other minor problems with the code
and WINE. For example I get an EOF where I shouldn't
get one.

Maybe we can disable the opencdk tests for the mingw32
build until we found a solution? Maybe this is not just
a WINE problem, but also a real win32 problem. I currently
have no w32 box for tests.

But it would be useful to know if the test files (t-encr.exe)
would fail on a real w32 system.



	Timo


From simon at josefsson.org  Fri May  4 15:40:50 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 04 May 2007 15:40:50 +0200
Subject: [gnutls-dev] OpenCDK sync
In-Reply-To: <463B2BF1.7050709@gmx.net> (Timo Schulz's message of "Fri\, 04 May
	2007 14\:49\:53 +0200")
References: <87wszpg5ag.fsf@mocca.josefsson.org> <463B2BF1.7050709@gmx.net>
Message-ID: <87lkg46719.fsf@mocca.josefsson.org>

Timo Schulz <twoaday at gmx.net> writes:

> Simon Josefsson wrote:
>
>> Timo, the OpenCDK copy in GnuTLS CVS trunk (which claim to be 0.6.0 in
>> its opencdk.h) seem to differ from the released 0.6.0.  Do you want to
>> update the OpenCDK copy in GnuTLS so it matches 0.6.0?
>
> Yes, I will do this. But first I need to find out if we can still use
> a stripped version of opencdk. If not, I will put a copy of the src
> files in the gnutls opencdk folder and commit the changes.

Sounds good, thanks!

I did copy all files from the 0.6.0 release into libextra/opencdk and it
appeared to build, but I'm not sure it works.

/Simon


From simon at josefsson.org  Fri May  4 16:08:29 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 04 May 2007 16:08:29 +0200
Subject: [gnutls-dev] OpenCDK 0.6.0 problems
In-Reply-To: <463B2BBD.2010108@gmx.net> (Timo Schulz's message of "Fri\, 04 May
	2007 14\:49\:01 +0200")
References: <46377548.7060109@gmx.net> <878xc5hkc0.fsf@mocca.josefsson.org>
	<871whxhk1m.fsf_-_@mocca.josefsson.org> <463B2BBD.2010108@gmx.net>
Message-ID: <871whw65r6.fsf@mocca.josefsson.org>

Timo Schulz <twoaday at gmx.net> writes:

> Simon Josefsson wrote:
>
>> /bin/sh ../libtool --tag=CC   --mode=link i586-mingw32msvc-gcc  -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -no-undefined -export-symbols ../../../src/opencdk-0.6.0/src/opencdk.def -version-info 10:0:0   -o libopencdk.la -rpath /home/jas/gnutls4win/inst/lib new-packet.lo read-packet.lo proc-packet.lo write-packet.lo main.lo verify.lo armor.lo sig-check.lo sign.lo keydb.lo keylist.lo seskey.lo pubkey.lo misc.lo encrypt.lo trustdb.lo kbnode.lo compress.lo literal.lo cipher.lo stream.lo stream-socket.lo keyserver.lo keygen.lo -L/home/jas/gnutls4win/inst/lib -lgcrypt -L/home/jas/gnutls4win/inst/lib -lgpg-error -lws2_32
>> libtool: link: symbol file `../../../src/opencdk-0.6.0/src/opencdk.def' does not exist
>> make[2]: *** [libopencdk.la] Error 1
>> make[2]: Leaving directory `/home/jas/gnutls4win/build/opencdk-0.6.0/src'
>
> Oh, I assumed that the integrated version would be build as a static
> lib. Now that I see the error, I'm not sure if we can still use a
> stripped version of opencdk.

Note that this was building the standalone version.  The integrated
version _will_ be built as a static library!  Sorry if the paths used
here are confusing.

>> However, 'make check' doesn't work under mingw32 any more:
>> 
>> make[2]: Entering directory `/home/jas/gnutls4win/build/opencdk-0.6.0/tests'
>
> I definitely need to check the code for the mingw32 build. I made a
> 'make distcheck' but I did not test the mingw32 build.
>
> I will do some tests right now.

Thanks,
Simon


From twoaday at gmx.net  Fri May  4 16:28:05 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Fri, 04 May 2007 16:28:05 +0200
Subject: [gnutls-dev] OpenCDK 0.6.0 problems
In-Reply-To: <871whw65r6.fsf@mocca.josefsson.org>
References: <46377548.7060109@gmx.net>
	<878xc5hkc0.fsf@mocca.josefsson.org>	<871whxhk1m.fsf_-_@mocca.josefsson.org>
	<463B2BBD.2010108@gmx.net> <871whw65r6.fsf@mocca.josefsson.org>
Message-ID: <463B42F5.9000109@gmx.net>

Simon Josefsson wrote:

> Note that this was building the standalone version.  The integrated
> version _will_ be built as a static library!  Sorry if the paths used
> here are confusing.

Yep, a little. But I should have read it more carefully.

For now I changed the makefile so it will only execute tests
which are supposed to work for mingw32. For Posix systems, all
tests will be executed of course.

This will at least fix the problems temporary, until I found
a better solution.


	Timo

p.s.
If this fixes the build errors, I will prepare a new release.


From simon at josefsson.org  Fri May  4 16:21:39 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 04 May 2007 16:21:39 +0200
Subject: [gnutls-dev] GnuTLS 1.7.8.p11.0
In-Reply-To: <9e0cf0bf0705040531h4cb99e4dl3e469afa5d3b98dd@mail.gmail.com>
	(Alon Bar-Lev's message of "Fri\, 4 May 2007 15\:31\:37 +0300")
References: <877irruyfi.fsf@mocca.josefsson.org>
	<9e0cf0bf0705031345t380e9940sfa61e853fea4b262@mail.gmail.com>
	<87r6pw7pzm.fsf@mocca.josefsson.org>
	<9e0cf0bf0705040531h4cb99e4dl3e469afa5d3b98dd@mail.gmail.com>
Message-ID: <87wszo4qks.fsf@mocca.josefsson.org>

"Alon Bar-Lev" <alon.barlev at gmail.com> writes:

> On 5/4/07, Simon Josefsson <simon at josefsson.org> wrote:
>> "Alon Bar-Lev" <alon.barlev at gmail.com> writes:
>>
>> > Hello,
>> >
>> > I was about to get this implementation and suggest an alternative,
>> > only to discover that you are not doing any private key operations.
>>
>> Hi!  Right.  I wanted to get things out as soon as possible, and right
>> now getting the CA trust stuff is all that I can show to be working.
>
> As I said before... Most tokens do not hold certificate chain within
> them, it is just a waste of memory when you have 16K, 32K or 64K.

GnuTLS doesn't need the entire chain, just the CA.

Also, if the smartcard doesn't contain CA certificates, GnuTLS will not
find them and not use them: thus no problem?

> Also I already warned you that this is highly insecure... Since anyone
> can store whatever certificates as public objects, thus modifying the
> trust.

I don't understand this.  It seems to me that anyone who can make the
PKCS#11 provider give GnuTLS an insecure CA cert can also provide GnuTLS
directly with a insecure CA cert.

Could you describe how the attack would work?

>> It will be something like that.  It may start out as somewhat simpler,
>> to better fit with how the GnuTLS API works today: right now
>> applications can be invoked with a callback to retrieve the appropriate
>> cert+key.  They need some function to get the user certificates and key
>> handles from the PKCS#11 layer.  I'm thinking this interface will be:
>>
>>   int gnutls_pkcs11_get_user_certificates (gnutls_x509_crt_t ** cert_list,
>>                                                 unsigned int *ncerts);
>
> But you will be able to to implement the above using the API I suggested.
> As I see it you can have the PKCS#11 stuff maintained separately, as
> an optional components, something like gnutls-pkcs11 that will use the
> engine API in order to add the above function.

Sure -- the PKCS#11 support that GnuTLS will provide will always be
optional.  Applications that doesn't like the GnuTLS PKCS#11
implementation can implement their own callback function to retrieve
user/CA certs and handle signing requests.

> You also don't handle much of the issues related of token management...
> 1. Tokens are ****SLOW***** enumerating the certificates takes
> ****LONG**** time.
> 2. Tokens are dynamic, you can remove them and insert them, so
> enumerating all available tokens every time is not wise.
> 3. You may have more than one token available at the same time, you
> may need to handle this state.
> 4. As I understand from your API documentation, gnutls_x509_crt_t  has
> nothing to do with the private key, which is the one that really
> important when you handle hardware tokens.

I don't know how to solve this yet.  If you want to work on it, that
could help, although right now I just want to get client-PKI via the
OpenPGP smart card to work, and that's my main priority.

>> When an application, in the certificate callback, indicate that the
>> private key is 'NULL', they will have to provider another callback to
>> perform the sign operation, otherwise the user certificate will be
>> ignored.  That function should likely receive the user certificate or
>> similar.  GnuTLS should have an API available to perform the sign
>> operation using PKCS#11, but it could also let the application perform
>> the sign operation in any way it chose.  This way, the interface will
>> not be specific to PKCS#11, but it will be easy to make PKCS#11 work.
>
> I don't understand the above... How do you set the callback in the
> certificate object?
> How do you set user defined data for the callback to be used?
> I did not see this in the GnuTLS documentation.

See gnutls_certificate_client_set_retrieve_function(), and for example
the 'cert_callback' function in src/cli.c (the gnutls-cli tool).  That
callback is invoked during the TLS handshake to get the user certificate
and private key to use.  My idea is to allow the function to return a
private key 'NULL' which indicate that GnuTLS will have to callback into
the application to perform the private key operation.  These APIs will
not be PKCS#11 specific.

> Anyway... I think that your implementation should not be differnet
> than any other one.
> If you have such a generic mechanism, use it, don't implement two
> different methods.

Yup, the idea is to have a generic mechanism, and to provide the
necessary PKCS#11 glue to make it easy to use the generic mechanism with
PKCS#11 providers.  Application doesn't need to use the glue code
though.

>> Of course!  I think the best is for me to produce an API that works for
>> me and fits with how GnuTLS works.  I believe it will be quite close to
>> what you need, even if not perfectly the same.  The API will not be
>> fixed until it is merged into the normal experimental branch.  There
>> will be several iterations of release on the PKCS#11 branch until that
>> happens, and your input is valuable here.  I think it would be useful to
>> demonstrate interoperability with at least some other PKCS#11 provider
>> than Scute until the API is ready.
>
> All I suggest is an API that fits GnuTLS!
> But I suggest that the low-level PKCS#11 will reuse current effort and
> knowledge.
> Also I think it would be best if the PKCS#11 support will be provided
> as a separate library, that uses GnuTLS API.

Yes, I think it will be possible to use external libraries to implement
the PKCS#11 (or CAPI, or ...) support.

> The functions:
> gnutls_pkcs11_set_config() /* Set providers and parameters */
> gnutls_pkcs11_enum_certificates() /* Enumerate available certificates */
> gnutls_pkcs11_serialize_certificate() /* Serialize specific
> certificate so we don't need enum again */
> gnutls_pkcs11_deserialize_certificate() /* Deserialize certificate,
> good for configuration files */
>
> Can be implemented using PKCS#11 code and GnuTLS with engine API as a
> separate library.
>
> Also, if you would like to be more generic you should provide an
> engines much more powerful and allow gnutls to serialize/deserialize
> any certificate includeing the engine specific information, and allow
> callbacks for an engine to enumerate certificates.

I want to keep the PKCS#11 APIs minimal.  It should provide basic
functionality for applications that want to build on it.  Applications
that wants to get fancy can do their own PKCS#11 integration.

/Simon


From alon.barlev at gmail.com  Fri May  4 17:21:46 2007
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Fri, 4 May 2007 18:21:46 +0300
Subject: [gnutls-dev] GnuTLS 1.7.8.p11.0
In-Reply-To: <87wszo4qks.fsf@mocca.josefsson.org>
References: <877irruyfi.fsf@mocca.josefsson.org>
	<9e0cf0bf0705031345t380e9940sfa61e853fea4b262@mail.gmail.com>
	<87r6pw7pzm.fsf@mocca.josefsson.org>
	<9e0cf0bf0705040531h4cb99e4dl3e469afa5d3b98dd@mail.gmail.com>
	<87wszo4qks.fsf@mocca.josefsson.org>
Message-ID: <9e0cf0bf0705040821u6bae0c6aodfc6d12451e0b129@mail.gmail.com>

On 5/4/07, Simon Josefsson <simon at josefsson.org> wrote:
> I don't understand this.  It seems to me that anyone who can make the
> PKCS#11 provider give GnuTLS an insecure CA cert can also provide GnuTLS
> directly with a insecure CA cert.
>
> Could you describe how the attack would work?

You insert your token in my computer, I put my own self-signed
certificate as trusted in your token, then you come back to your token
and work with my fake TLS server side certificate.

> I don't know how to solve this yet.  If you want to work on it, that
> could help, although right now I just want to get client-PKI via the
> OpenPGP smart card to work, and that's my main priority.

Well... I see we are not communicating well... So I say this last time
and I say this clearly.

I offer you the quickest way to achieve your goal.
Split the work into two parts, one part is the GnuTLS infrastructure
missing external private key implementation, the other is PKCS#11
engine.
You implement the GnuTLS stuff, I implement the PKCS#11 engine, this
way everyone is doing what he is best of.

Now, you will have "A" working PKCS#11 implementation. Why "A", since
you may decide you can do this better, and implement "THE" PKCS#11
engine on your own later, it will take you a while to mess with
PKCS#11, learn how people are using it, where and when, address
different provider implementations and incompatibilities etc...

But you will have "A" working provider so you can learn and copy
whatever you like, it will be GPLed, so no licensing problem here.

This means that you STOP writing PKCS#11 low level code, and
consentrate on the missing functionality of GnuTLS, document the
engine interface and then test out if my implementation meets your
needs.

Best Regards,
Alon Bar-Lev.


From alon.barlev at gmail.com  Sun May  6 21:01:55 2007
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Sun, 6 May 2007 22:01:55 +0300
Subject: [gnutls-dev] PKCS#11 for CryptoAPI
Message-ID: <9e0cf0bf0705061201mb25b323je6acd9c840bb7935@mail.gmail.com>

On 5/6/07, Nate Nielsen <nielsen-list at memberwebs.com> wrote:
> > Alon Bar-Lev wrote:
> >> On 4/24/07, Nate Nielsen <nielsen-list at memberwebs.com> wrote:
> >>> BTW, I'm working on building a complete PKCS#11 provider for CAPI. So by
> >>> supporting PKCS#11 you'd be able to have things like CAPI support.
> >> This is great to hear!
> >> It has been long since I developed for Microsoft environment... But I
> >> can help if you like!
>
> Here's the basic version 0.1 CAPI PKCS#11 plugin. It exposes
> certificates (but not keys yet) and certificate trust.
>
> I'll probably end up hosting this at code.google.com unless anyone has
> better suggestions.

Nice!
Are you interested in hosting this at opensc-project.org?
I think it is a good place for this project.
Andreas, what do you think?

I will review this in week-end, but just a general comment... The RSA
Security include files come with L/GPL incompatible license.
There is a free alternative that we use, please test it out, so we
don't have licensing issues.

The file is maintained at:
http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/trunk/src/pkcs11.h?rev=55&root=Scute&view=auto

Best Regads,
Alon Bar-Lev.


From alon.barlev at gmail.com  Sun May  6 21:01:55 2007
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Sun, 6 May 2007 22:01:55 +0300
Subject: [gnutls-dev] [opensc-devel] PKCS#11 for CryptoAPI
Message-ID: <9e0cf0bf0705061201mb25b323je6acd9c840bb7935@mail.gmail.com>

On 5/6/07, Nate Nielsen <nielsen-list at memberwebs.com> wrote:
> > Alon Bar-Lev wrote:
> >> On 4/24/07, Nate Nielsen <nielsen-list at memberwebs.com> wrote:
> >>> BTW, I'm working on building a complete PKCS#11 provider for CAPI. So by
> >>> supporting PKCS#11 you'd be able to have things like CAPI support.
> >> This is great to hear!
> >> It has been long since I developed for Microsoft environment... But I
> >> can help if you like!
>
> Here's the basic version 0.1 CAPI PKCS#11 plugin. It exposes
> certificates (but not keys yet) and certificate trust.
>
> I'll probably end up hosting this at code.google.com unless anyone has
> better suggestions.

Nice!
Are you interested in hosting this at opensc-project.org?
I think it is a good place for this project.
Andreas, what do you think?

I will review this in week-end, but just a general comment... The RSA
Security include files come with L/GPL incompatible license.
There is a free alternative that we use, please test it out, so we
don't have licensing issues.

The file is maintained at:
http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/trunk/src/pkcs11.h?rev=55&root=Scute&view=auto

Best Regads,
Alon Bar-Lev.
_______________________________________________
opensc-devel mailing list
opensc-devel at lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel


From nielsen-list at memberwebs.com  Sun May  6 22:42:07 2007
From: nielsen-list at memberwebs.com (Nate Nielsen)
Date: Sun,  6 May 2007 20:42:07 +0000 (UTC)
Subject: [gnutls-dev] [opensc-devel] PKCS#11 for CryptoAPI
References: <9e0cf0bf0705061201mb25b323je6acd9c840bb7935@mail.gmail.com>
	<200705062109.01383.aj@dungeon.inka.de>
Message-ID: <20070506204206.B1E92D4C08@mx.npubs.com>

Andreas Jellinghaus wrote:
> sure, it is very welcome. well, it is the third project next to pkcscsp and 
> csp11, but both of that are dead and no longer under development.

Well CSP#11, as I understand it, does the exact opposite. It presents a
Windows Cryptographic Service Provider interface which allows use of
PKCS#11 modules.

The cryptoki-capi plugin I put together allows PKCS#11 compatible
programs to use Windows CAPI certificates and keys.

It's similar to this:

http://lxr.mozilla.org/security/source/security/nss/lib/ckfw/capi/

... but without the NSS dependency and with intent to become an
implementation complete enough to be usable.

> so I't be happy to offer hosting the code. give me a project name
> (lowercase, short, like "opensc", "openct", "libp11", "pkcscsp", etc.
> and I will setup a svn repository and trac wiki / bug tracker for you and
> give you access to it.

Cool. Thanks. I'll let you know in a short while.

Cheers,
Nate Nielsen













From nielsen-list at memberwebs.com  Sun May  6 22:20:07 2007
From: nielsen-list at memberwebs.com (Nate Nielsen)
Date: Sun,  6 May 2007 20:20:07 +0000 (UTC)
Subject: [gnutls-dev] [opensc-devel] PKCS#11 for CryptoAPI
References: <9e0cf0bf0705061201mb25b323je6acd9c840bb7935@mail.gmail.com>
Message-ID: <20070506202006.9BAFFD4C11@mx.npubs.com>

Alon Bar-Lev wrote:
> I will review this in week-end, but just a general comment... The RSA
> Security include files come with L/GPL incompatible license.
> There is a free alternative that we use, please test it out, so we
> don't have licensing issues.
> 
> The file is maintained at:
> http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/trunk/src/pkcs11.h?rev=55&root=Scute&view=auto

Good point. Thanks. I'll use that instead.

Cheers,
Nate Nielsen

_______________________________________________
opensc-devel mailing list
opensc-devel at lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel


From nielsen-list at memberwebs.com  Sun May  6 22:42:07 2007
From: nielsen-list at memberwebs.com (Nate Nielsen)
Date: Sun,  6 May 2007 20:42:07 +0000 (UTC)
Subject: [gnutls-dev] [opensc-devel] PKCS#11 for CryptoAPI
References: <9e0cf0bf0705061201mb25b323je6acd9c840bb7935@mail.gmail.com>
	<200705062109.01383.aj@dungeon.inka.de>
Message-ID: <20070506204206.B1E92D4C08@mx.npubs.com>

Andreas Jellinghaus wrote:
> sure, it is very welcome. well, it is the third project next to pkcscsp and 
> csp11, but both of that are dead and no longer under development.

Well CSP#11, as I understand it, does the exact opposite. It presents a
Windows Cryptographic Service Provider interface which allows use of
PKCS#11 modules.

The cryptoki-capi plugin I put together allows PKCS#11 compatible
programs to use Windows CAPI certificates and keys.

It's similar to this:

http://lxr.mozilla.org/security/source/security/nss/lib/ckfw/capi/

... but without the NSS dependency and with intent to become an
implementation complete enough to be usable.

> so I't be happy to offer hosting the code. give me a project name
> (lowercase, short, like "opensc", "openct", "libp11", "pkcscsp", etc.
> and I will setup a svn repository and trac wiki / bug tracker for you and
> give you access to it.

Cool. Thanks. I'll let you know in a short while.

Cheers,
Nate Nielsen











_______________________________________________
opensc-devel mailing list
opensc-devel at lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel


From nielsen-list at memberwebs.com  Sun May  6 22:20:07 2007
From: nielsen-list at memberwebs.com (Nate Nielsen)
Date: Sun,  6 May 2007 20:20:07 +0000 (UTC)
Subject: [gnutls-dev] PKCS#11 for CryptoAPI
References: <9e0cf0bf0705061201mb25b323je6acd9c840bb7935@mail.gmail.com>
Message-ID: <20070506202006.9BAFFD4C11@mx.npubs.com>

Alon Bar-Lev wrote:
> I will review this in week-end, but just a general comment... The RSA
> Security include files come with L/GPL incompatible license.
> There is a free alternative that we use, please test it out, so we
> don't have licensing issues.
> 
> The file is maintained at:
> http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/trunk/src/pkcs11.h?rev=55&root=Scute&view=auto

Good point. Thanks. I'll use that instead.

Cheers,
Nate Nielsen



From simon at josefsson.org  Mon May  7 10:27:25 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 07 May 2007 10:27:25 +0200
Subject: [gnutls-dev] GnuTLS 1.7.8.p11.0
In-Reply-To: <9e0cf0bf0705040821u6bae0c6aodfc6d12451e0b129@mail.gmail.com>
	(Alon Bar-Lev's message of "Fri\, 4 May 2007 18\:21\:46 +0300")
References: <877irruyfi.fsf@mocca.josefsson.org>
	<9e0cf0bf0705031345t380e9940sfa61e853fea4b262@mail.gmail.com>
	<87r6pw7pzm.fsf@mocca.josefsson.org>
	<9e0cf0bf0705040531h4cb99e4dl3e469afa5d3b98dd@mail.gmail.com>
	<87wszo4qks.fsf@mocca.josefsson.org>
	<9e0cf0bf0705040821u6bae0c6aodfc6d12451e0b129@mail.gmail.com>
Message-ID: <87zm4hrqc2.fsf@mocca.josefsson.org>

"Alon Bar-Lev" <alon.barlev at gmail.com> writes:

> On 5/4/07, Simon Josefsson <simon at josefsson.org> wrote:
>> I don't understand this.  It seems to me that anyone who can make the
>> PKCS#11 provider give GnuTLS an insecure CA cert can also provide GnuTLS
>> directly with a insecure CA cert.
>>
>> Could you describe how the attack would work?
>
> You insert your token in my computer, I put my own self-signed
> certificate as trusted in your token, then you come back to your token
> and work with my fake TLS server side certificate.

Oh, I see.  Are there smart cards out there that doesn't require an
admin-PIN in order to do that?  Maybe it would be good to document this
somewhere, it seems like a good thing to know before buying such
products.

If this is the case, I'll add documentation for
gnutls_pkcs11_get_ca_certificates:

 * Note that there exists PKCS#11 providers that allow users to add
 * trusted CA certificates to the underlying crypto storage.  Thus, an
 * attacker could, if they can access your smart card, install a new
 * trusted CA on your smart card, and then cause this function to
 * return their CA.  Be aware of this threat when using this function
 * in your application.

>> I don't know how to solve this yet.  If you want to work on it, that
>> could help, although right now I just want to get client-PKI via the
>> OpenPGP smart card to work, and that's my main priority.
>
> Well... I see we are not communicating well... So I say this last time
> and I say this clearly.
>
> I offer you the quickest way to achieve your goal.
> Split the work into two parts, one part is the GnuTLS infrastructure
> missing external private key implementation, the other is PKCS#11
> engine.

Well, as I've tried to explain, that is what I'm working on.  What may
be confusing is that I'm _also_ working on an optional libgnutls-pkcs11
that links to Scute.  That is written for testing purpose, since the
only smart card I have is an OpenPGP smart card, and I've decided that
my goal for this project is to make OpenPGP cards work with
client-authenticated connections (and I chose PKCS#11 to do that).

Hopefully the signing infrastructure will be released within a few
weeks, and then you can try it...

/Simon


From andrew.w.nosenko at gmail.com  Mon May  7 12:11:10 2007
From: andrew.w.nosenko at gmail.com (Andrew W. Nosenko)
Date: Mon, 7 May 2007 13:11:10 +0300
Subject: [gnutls-dev] gnutls-1.6.1.auth_cert.mem-leak.awn.1.patch
In-Reply-To: <6161f3180704270635m198a66f4kd337c2985c240312@mail.gmail.com>
References: <6161f3180704260818p39b399d2x594da396b76bfb9e@mail.gmail.com>
	<6161f3180704270515s5cff14x3bd6f4a811809fdc@mail.gmail.com>
	<874pn2roki.fsf@mocca.josefsson.org>
	<6161f3180704270635m198a66f4kd337c2985c240312@mail.gmail.com>
Message-ID: <6161f3180705070311l757c059g2a93b05b0b8abafd@mail.gmail.com>

Sorry, but I don't see patch applied neither to the HEAD nor to the
gnutls_1_6_x branch.

Does it mean that patch is forbidden for some reason?

-- 
Andrew W. Nosenko <andrew.w.nosenko at gmail.com>


From simon at josefsson.org  Tue May  8 12:24:28 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 08 May 2007 12:24:28 +0200
Subject: [gnutls-dev] Gnutls 1.7.8.p11.1
Message-ID: <87r6prk3z7.fsf@mocca.josefsson.org>

A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 419 bytes
Desc: not available
Url : /pipermail/attachments/20070508/ddee6aca/attachment.pgp 

From simon at josefsson.org  Tue May  8 12:37:04 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 08 May 2007 12:37:04 +0200
Subject: [gnutls-dev] sign callback for certificate authentication
In-Reply-To: <461A36B7020000960002E069@mcclure.wal.novell.com> (Jacob
	Berkman's message of "Mon\, 09 Apr 2007 12\:51\:02 -0400")
References: <461A36B7020000960002E069@mcclure.wal.novell.com>
Message-ID: <87mz0fk3e7.fsf@mocca.josefsson.org>

Hi again.  I just realized that the work I'm doing on the PKCS#11 branch
is rather similar to what you provided a patch for here.  The code is
different from yours, but let me what you think and if you can test it:

http://article.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/2006

I intend to move the external-signing callback API back into the 1.7.x
branch as soon as possible, because it looks rather safe.  I'm not sure
about our PKCS#11 interface library.  Alon Bar-Lev's comments indicate
that it may be better if we stay out of providing tighter PKCS#11
integration and leave that to him and others to work on.  I'd be happy
with that, since I personally think the PKCS#11 interface is too complex
to inspire good confidence in implementations of it.  Still, making it
easy to use OpenPGP cards is an important use-case for me.

/Simon

"Jacob Berkman" <jberkman at novell.com> writes:

> Hello,
>
> I've attached a patch to gnutls which adds a callback for the signing
> step of certificate-based authentication.  This was needed because
> some smart card policies do not allow private keys to be read/exported
> from them.  They implement signing directly on the card.
>
> With this patch, the application can return a NULL private key, and if
> they implement the signing callback, can sign the data themselves.
>
> I developed this patch against gnutls 1.4.4, but it patches and builds
> cleanly against 1.7.7.  Please let me know if any changes are
> required.
>
> Thanks,
>  -- jacob
>
>
> _______________________________________________
> Gnutls-dev mailing list
> Gnutls-dev at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnutls-dev


From alon.barlev at gmail.com  Tue May  8 21:55:05 2007
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Tue, 8 May 2007 22:55:05 +0300
Subject: [gnutls-dev] sign callback for certificate authentication
In-Reply-To: <87mz0fk3e7.fsf@mocca.josefsson.org>
References: <461A36B7020000960002E069@mcclure.wal.novell.com>
	<87mz0fk3e7.fsf@mocca.josefsson.org>
Message-ID: <9e0cf0bf0705081255t730263c9g35231a8ea2965db8@mail.gmail.com>

Hello Simon,

Can you please clean up the branch removing the scote requirement and
PKCS#11 implementation, leaving only the engine callbacks so I can
work on this?

BTW: Your API need to allow adding user data pointer so that callbacks
will be able to access some private data.

Ludovic already suggested this at:
http://lists.gnupg.org/pipermail/gnutls-dev/2007-April/001434.html
And I already suggested it at:
http://lists.gnupg.org/pipermail/gnutls-dev/2007-May/001557.html

BTW2: You should add cleanup callback, so that resources can be
released on session end.
http://lists.gnupg.org/pipermail/gnutls-dev/2007-May/001557.html

We can discuss the API before you start implementation, so if you
provide the prototypes before implementation it will allow reduce
efforts.

Best Regards,
Alon Bar-Lev.

On 5/8/07, Simon Josefsson <simon at josefsson.org> wrote:
> Hi again.  I just realized that the work I'm doing on the PKCS#11 branch
> is rather similar to what you provided a patch for here.  The code is
> different from yours, but let me what you think and if you can test it:
>
> http://article.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/2006
>
> I intend to move the external-signing callback API back into the 1.7.x
> branch as soon as possible, because it looks rather safe.  I'm not sure
> about our PKCS#11 interface library.  Alon Bar-Lev's comments indicate
> that it may be better if we stay out of providing tighter PKCS#11
> integration and leave that to him and others to work on.  I'd be happy
> with that, since I personally think the PKCS#11 interface is too complex
> to inspire good confidence in implementations of it.  Still, making it
> easy to use OpenPGP cards is an important use-case for me.
>
> /Simon
>
> "Jacob Berkman" <jberkman at novell.com> writes:
>
> > Hello,
> >
> > I've attached a patch to gnutls which adds a callback for the signing
> > step of certificate-based authentication.  This was needed because
> > some smart card policies do not allow private keys to be read/exported
> > from them.  They implement signing directly on the card.
> >
> > With this patch, the application can return a NULL private key, and if
> > they implement the signing callback, can sign the data themselves.
> >
> > I developed this patch against gnutls 1.4.4, but it patches and builds
> > cleanly against 1.7.7.  Please let me know if any changes are
> > required.
> >
> > Thanks,
> >  -- jacob
> >
> >
> > _______________________________________________
> > Gnutls-dev mailing list
> > Gnutls-dev at gnupg.org
> > http://lists.gnupg.org/mailman/listinfo/gnutls-dev
>
> _______________________________________________
> Gnutls-dev mailing list
> Gnutls-dev at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnutls-dev
>


From nielsen at memberwebs.com  Tue May  8 22:41:27 2007
From: nielsen at memberwebs.com (Nate Nielsen)
Date: Tue,  8 May 2007 20:41:27 +0000 (UTC)
Subject: [gnutls-dev] [opensc-devel] PKCS#11 for CryptoAPI
References: <9e0cf0bf0705061201mb25b323je6acd9c840bb7935@mail.gmail.com>	<200705062109.01383.aj@dungeon.inka.de>	<20070506204206.B1E92D4C08@mx.npubs.com>
	<463F655E.2040004@REDHAT.COM>
Message-ID: <20070508204127.1BC3FD4C03@mx.npubs.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Relyea wrote:
> nss/lib/ckfw itself is meant to be a framework to quickly bring up new
> PKCS #11 adapters. It's meant to be separable from NSS, (and in fact has
> no nspr dependencies).

Interesting. I guess it compiles the parts of NSS and NSPR that it uses
into the the PKCS#11 module itself?

Is there documentation anywhere for this CKFW framework?

Just to clarify, the reason I'm developing the cryptoki-capi, is that
several clients of mine dislike the Mozilla state of affairs as far as
not using the OS's (in this case Windows') certificate and key store. It
makes things so much more insecure to have keys and policy littered
throughout the configuration files of each program.

Cheers,
Nate Nielsen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGQL+9e/sRCNknZa8RAi5YAKCGU0g8M15CNNkIzm8IGU67u7w5bACfWxiR
AGu2X8KfqrIcRX1SGh4JlWQ=
=ozvE
-----END PGP SIGNATURE-----

_______________________________________________
opensc-devel mailing list
opensc-devel at lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel


From alon.barlev at gmail.com  Fri May 11 19:38:06 2007
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Fri, 11 May 2007 20:38:06 +0300
Subject: [gnutls-dev] sign callback for certificate authentication
In-Reply-To: <874pmjsc7f.fsf@mocca.josefsson.org>
References: <461A36B7020000960002E069@mcclure.wal.novell.com>
	<87mz0fk3e7.fsf@mocca.josefsson.org>
	<9e0cf0bf0705081255t730263c9g35231a8ea2965db8@mail.gmail.com>
	<874pmjsc7f.fsf@mocca.josefsson.org>
Message-ID: <9e0cf0bf0705111038o89f023at7293e94abdacd085@mail.gmail.com>

On 5/11/07, Simon Josefsson <simon at josefsson.org> wrote:
> Hi.  I'm making Scute an optional dependency on the branch now.

OK.
Just reference me to the place I can sync your modifications.

> > BTW: Your API need to allow adding user data pointer so that callbacks
> > will be able to access some private data.
> I've added this too.

Great!

> > BTW2: You should add cleanup callback, so that resources can be
> > released on session end.
> > http://lists.gnupg.org/pipermail/gnutls-dev/2007-May/001557.html
>
> This seem to be bloat to me, since it offers no additional
> functionality.  Applications can cleanup resources when they deinit the
> particular GnuTLS session that uses the sign callback, can they not?

We would like to add a layer for application to use...
So except get certificate/credentials/whatever, the layer should be
able to free its resources.
So if we put this at gnutls_certificate_credentials_t we should have
gnutls_certificate_free_credentials() call callback cleanup so that
resources may be released.

So that user code will look like:
gnutls_pkcs11_set_certificate (gnutls_certificate_credentials_t *cred, <id>)

And that's it!

provider code will register sign callback, put certificate and
register clean callback.

> I'm considering to change the APIs (see below), so I didn't want to
> spend time discussing the changes for the next release now (otherwise I
> wouldn't have time to release it today).
>
> When I have time to write down my ideas about the changes that are
> necessary -- the sign callback should be set per
> gnutls_certificate_credential_t and not per session -- we can discuss
> the new API.  However, I'm going to be busy for about 10 days so nothing
> will happen until after that.
>
> What should be possible for you with the upcoming p11.2 release is to
> write a PKCS#11 interface that can be invoked via the sign callback.  I
> hope that you will be able to test signing via the callback and some
> PKCS#11 provider that you have until I come back.  Then we your
> experience and the new API, finalize it and bring it back into the 1.7.x
> branch.

Thanks!
Alon.


From ludo at chbouib.org  Sun May 13 13:00:55 2007
From: ludo at chbouib.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Sun, 13 May 2007 13:00:55 +0200
Subject: [gnutls-dev] [PATCH] Fixing OpenPGP keyring import (again)
Message-ID: <87lkft6l94.fsf@chbouib.org>

A non-text attachment was scrubbed...
Name: ,,keyring-import-2.diff
Type: text/x-patch
Size: 13230 bytes
Desc: The patch
Url : /pipermail/attachments/20070513/0dc51480/attachment.bin 

From twoaday at gmx.net  Sun May 13 13:13:50 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Sun, 13 May 2007 13:13:50 +0200
Subject: [gnutls-dev] [PATCH] Fixing OpenPGP keyring import (again)
In-Reply-To: <87lkft6l94.fsf@chbouib.org>
References: <87lkft6l94.fsf@chbouib.org>
Message-ID: <4646F2EE.3040505@gmx.net>

Ludovic Court?s wrote:

> The patch below (against) `HEAD' fixes OpenPGP keyring import.  It
> should also work for ASCII-armored keyrings, although I did not test it
> since I did not have ASCII-armored keyrings at hand.  It also adds a

I thought the problem would be fixed with the new opencdk code. I
might mix up things so, so please could you explain again what the
problem here is?


>   1. For some reason, `check_id ()' doesn't work with the second ID
>      that's commented in `keyring.c', although it should.  Actually, I

I will try to check this ASAP.


>         at 0x401D4B0: malloc (vg_replace_malloc.c:149)
>         by 0x420C7F3: (within /usr/lib/libgcrypt.so.11.2.2)
>         by 0x420CA60: gcry_malloc (in /usr/lib/libgcrypt.so.11.2.2)
>         by 0x420CCDC: gcry_calloc (in /usr/lib/libgcrypt.so.11.2.2)
>         by 0x402BBA5: cdk_calloc (main.c:163)
>         by 0x402E33A: cdk_kbnode_new (kbnode.c:41)
>         by 0x4030758: cdk_keydb_get_keyblock (keydb.c:1715)
>         by 0x4031953: cdk_keydb_search (keydb.c:938)
>         by 0x40325D7: cdk_keydb_get_pk (keydb.c:1268)
>         by 0x4029878: gnutls_openpgp_keyring_check_id (extras.c:103)
>         by 0x8048921: doit (keyring.c:163)
>         by 0x8048B44: main (utils.c:148)

Actually I already documented it in the TODO file, but the fix
is a little tricky because it is not obvious where the leak occurs.




From twoaday at gmx.net  Sun May 13 13:41:59 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Sun, 13 May 2007 13:41:59 +0200
Subject: [gnutls-dev] [PATCH] Fixing OpenPGP keyring import (again)
In-Reply-To: <87lkft6l94.fsf@chbouib.org>
References: <87lkft6l94.fsf@chbouib.org>
Message-ID: <4646F987.40108@gmx.net>

Ludovic Court?s wrote:

> The patch below (against) `HEAD' fixes OpenPGP keyring import.  It
> should also work for ASCII-armored keyrings, although I did not test it
> since I did not have ASCII-armored keyrings at hand.  It also adds a

I forgot to ask how the openpgp test environment usually looks like?
Do you use the included opencdk package for tests or an external? If
you use an external, I would suggest to use 0.6.1 because it contains
minor enhancements and bug fixes.


	Timo



From twoaday at gmx.net  Sun May 13 14:05:11 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Sun, 13 May 2007 14:05:11 +0200
Subject: [gnutls-dev] Malformed raw keyring in test
Message-ID: <4646FEF7.9060007@gmx.net>

Hi!

I checked your test (keyring.c) and the raw_keyring
string was malformed. It contained a \0 somewhere after
the first Dr. Who key. (To confirm this, dump the raw
data on stdout/stderr and use pgpdump raw_data. You will
notice an premature EOF)

I corrected it and now it works without any problems. I
attached the corrected test file for test purposes.


	Timo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: keyring.c
Type: text/x-csrc
Size: 11867 bytes
Desc: not available
Url : /pipermail/attachments/20070513/aaa59ac8/attachment-0001.c 

From ludo at chbouib.org  Sun May 13 14:57:10 2007
From: ludo at chbouib.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Sun, 13 May 2007 14:57:10 +0200
Subject: [gnutls-dev] [PATCH] Fixing OpenPGP keyring import (again)
References: <87lkft6l94.fsf@chbouib.org> <4646F2EE.3040505@gmx.net>
Message-ID: <87ps546fvd.fsf@chbouib.org>

Hi,

Timo Schulz <twoaday at gmx.net> writes:

> I thought the problem would be fixed with the new opencdk code. I
> might mix up things so, so please could you explain again what the
> problem here is?

Raw-keyring import does not work without the patch.  Please, run the
test case I sent (part of the patch).

> Actually I already documented it in the TODO file, but the fix
> is a little tricky because it is not obvious where the leak occurs.

Funny to document a leak.  :-)

> I forgot to ask how the openpgp test environment usually looks like?
> Do you use the included opencdk package for tests or an external? If
> you use an external, I would suggest to use 0.6.1 because it contains
> minor enhancements and bug fixes.

I use the included OpenCDK which is supposed to work fine for GnuTLS
purposes.

Thanks,
Ludovic.



From ludo at chbouib.org  Sun May 13 15:19:13 2007
From: ludo at chbouib.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Sun, 13 May 2007 15:19:13 +0200
Subject: [gnutls-dev] Malformed raw keyring in test
References: <4646FEF7.9060007@gmx.net>
Message-ID: <87sla050a6.fsf@chbouib.org>

Hi,

Timo Schulz <twoaday at gmx.net> writes:

> I checked your test (keyring.c) and the raw_keyring
> string was malformed. It contained a \0 somewhere after
> the first Dr. Who key. (To confirm this, dump the raw
> data on stdout/stderr and use pgpdump raw_data. You will
> notice an premature EOF)

Cool, thanks!

Can you check in the whole patch, i.e., keyring import-fix plus new test
case (your version)?

Thanks,
Ludovic.



From twoaday at gmx.net  Sun May 13 17:21:35 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Sun, 13 May 2007 17:21:35 +0200
Subject: [gnutls-dev] [PATCH] Fixing OpenPGP keyring import (again)
In-Reply-To: <87ps546fvd.fsf@chbouib.org>
References: <87lkft6l94.fsf@chbouib.org> <4646F2EE.3040505@gmx.net>
	<87ps546fvd.fsf@chbouib.org>
Message-ID: <46472CFF.7050508@gmx.net>

Ludovic Court?s wrote:

> Raw-keyring import does not work without the patch.  Please, run the
> test case I sent (part of the patch).

I did, but _after_ I applied the patch for extras. I wasn't aware
the raw import did not work, so the patch makes sense. Thanks.


>> Actually I already documented it in the TODO file, but the fix
>> is a little tricky because it is not obvious where the leak occurs.
> 
> Funny to document a leak.  :-)

Yes and no. If somebody reports a leak and you cannot fix it, you
need at least to document it, no?


> I use the included OpenCDK which is supposed to work fine for GnuTLS
> purposes.

IMHO it's the easiest solution, all I need to do is to keep the source
in the opencdk folder in sync with the latest opencdk release.


	Timo


From twoaday at gmx.net  Sun May 13 17:23:48 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Sun, 13 May 2007 17:23:48 +0200
Subject: [gnutls-dev] Malformed raw keyring in test
In-Reply-To: <87sla050a6.fsf@chbouib.org>
References: <4646FEF7.9060007@gmx.net> <87sla050a6.fsf@chbouib.org>
Message-ID: <46472D84.2090908@gmx.net>

Ludovic Court?s wrote:

>> data on stdout/stderr and use pgpdump raw_data. You will
>> notice an premature EOF)
> 
> Cool, thanks!

No problem. I wanted to write a test myself and now I can
extend yours :-).


> Can you check in the whole patch, i.e., keyring import-fix plus new test
> case (your version)?

Yes.

Simon, is it OK that I will check in the changes? None of the patches
touches the core code, if you are concerned of the stability. Plus
I already run the tests and made a successful connection to test server.


	Timo


From alon.barlev at gmail.com  Sun May 13 21:41:24 2007
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Sun, 13 May 2007 22:41:24 +0300
Subject: [gnutls-dev] GnuTLS PKCS#11 Engine
Message-ID: <9e0cf0bf0705131241i637dce16t3772ed0e3528014@mail.gmail.com>

Hello,

An initial version of gnugls-pkcs11 is available for testing.
It should provide a simple API to access PKCS#11 cryptographic tokens.

I tried to keep the API as simple as I could, by copying some of
gnutls "simple" interface, although I think gnutls interface should be
modified to eliminate the requirement of global variables, and the
programmer to develop a specific code if it uses an engine.
I also cleaned the cli so it will only test the pkcs11 implementation,
I hope to clean this further.

The implementation allows to use several providers at the same time,
support session expiration, token request (if needed), several tokens
at the same time, detect a token if it is removed and insert to a
different slot, loading certificate authorities from token and much
more.

You can download gnutls-pkcs11 from:
http://alon.barlev.googlepages.com/gnutls-pkcs11-0.01.tar.bz2

Generated documentation is available at:
http://alon.barlev.googlepages.com/gnutls-pkcs11-0.01-docs.tar.bz2

In order to compile the engine, you should use the following components:
1. http://josefsson.org/gnutls/releases/pkcs11/gnutls-1.7.8.p11.2.tar.bz2
2. http://www.opensc-project.org/files/pkcs11-helper/pkcs11-helper-1.02.tar.bz2

Configure gnutls with --without-pkcs11-scute, I hope that next branch
will have this off by default.

In order to test gnutls-pkcs11 I use:
$ ./configure GNUTLS_CFLAGS="-I${GNUTLS_HOME}/include"
GNUTLS_LIBS="-L${GNUTLS_HOME}/lib -lgnutls"

In order to test, use:
LD_LIBRARY_PATH="${GNUTLS_HOME}/lib" src/gnutls-pkcs11-cli
--add-provider=/usr/lib/pkcs11/<provider>  --cmd=ids

You will get available certificates that may be used, look at the:
PKCS#11 ID: XXXX

Now:

$ LD_LIBRARY_PATH="${GNUTLS_HOME}/lib" src/gnutls-pkcs11-cli
--add-provider=/usr/lib/pkcs11/<provider>  --cmd=connect
--host=localhost --port=5556 --pkcs11-id='XXXX'

Where XXXX is the id selected from the list. Please note the single
quote, it is required so sh will not mess with the backslashes.

If it does not work for you, please add --debug=5 and send me the log.

Any comments/suggestions are appriciated!

Best Regards,
Alon Bar-Lev.


From simon at josefsson.org  Mon May 14 08:00:25 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 14 May 2007 08:00:25 +0200
Subject: [gnutls-dev] Malformed raw keyring in test
In-Reply-To: <46472D84.2090908@gmx.net> (Timo Schulz's message of "Sun\, 13 May
	2007 17\:23\:48 +0200")
References: <4646FEF7.9060007@gmx.net> <87sla050a6.fsf@chbouib.org>
	<46472D84.2090908@gmx.net>
Message-ID: <87wszckkqu.fsf@mocca.josefsson.org>

Timo Schulz <twoaday at gmx.net> writes:

> Simon, is it OK that I will check in the changes? None of the patches
> touches the core code, if you are concerned of the stability. Plus
> I already run the tests and made a successful connection to test server.

Sure, if it just touches opencdk or the opencdk glue in gnutls without
changing any APIs, please go ahead.

(Let's see if this message makes it to the gnutls-dev list..)

/Simon



From simon at josefsson.org  Sat May 12 11:11:38 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Sat, 12 May 2007 11:11:38 +0200
Subject: [gnutls-dev] sign callback for certificate authentication
In-Reply-To: <9e0cf0bf0705111038o89f023at7293e94abdacd085@mail.gmail.com>
	(Alon Bar-Lev's message of "Fri\, 11 May 2007 20\:38\:06 +0300")
References: <461A36B7020000960002E069@mcclure.wal.novell.com>
	<87mz0fk3e7.fsf@mocca.josefsson.org>
	<9e0cf0bf0705081255t730263c9g35231a8ea2965db8@mail.gmail.com>
	<874pmjsc7f.fsf@mocca.josefsson.org>
	<9e0cf0bf0705111038o89f023at7293e94abdacd085@mail.gmail.com>
Message-ID: <87mz0ao185.fsf@mocca.josefsson.org>

"Alon Bar-Lev" <alon.barlev at gmail.com> writes:

> On 5/11/07, Simon Josefsson <simon at josefsson.org> wrote:
>> Hi.  I'm making Scute an optional dependency on the branch now.
>
> OK.
> Just reference me to the place I can sync your modifications.

See:

http://josefsson.org/gnutls/releases/pkcs11/

The announcement (and likely, this message too) didn't make it to the
gnutls-dev list because I recently changed mail server to one that
doesn't have any reverse-dns.  Sigh...

There is a branch in CVS too:

http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/gnutls/?root=GNU+TLS+Library&only_with_tag=gnutls_1_7_8_with_pkcs11

I'm going to set up a Git server for it today.

>> > BTW2: You should add cleanup callback, so that resources can be
>> > released on session end.
>> > http://lists.gnupg.org/pipermail/gnutls-dev/2007-May/001557.html
>>
>> This seem to be bloat to me, since it offers no additional
>> functionality.  Applications can cleanup resources when they deinit the
>> particular GnuTLS session that uses the sign callback, can they not?
>
> We would like to add a layer for application to use...
> So except get certificate/credentials/whatever, the layer should be
> able to free its resources.
> So if we put this at gnutls_certificate_credentials_t we should have
> gnutls_certificate_free_credentials() call callback cleanup so that
> resources may be released.

The application calls gnutls_certificate_free_credential, so it should
be able to call another function at the same place to clean up the
resources that itself allocated.  This seems a better API separation to
me: the application is responsible for deallocating what it allocates,
and GnuTLS deallocate what it has allocated.

> So that user code will look like:
> gnutls_pkcs11_set_certificate (gnutls_certificate_credentials_t *cred, <id>)
>
> And that's it!

That API could be the same with my approach.

However, I don't think strongly about this, and when I get around to
changing the API to be certificate_credential-specific rather than
session-specific, we'll see how it works out.

/Simon



From simon at josefsson.org  Fri May 11 15:48:36 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 11 May 2007 15:48:36 +0200
Subject: [gnutls-dev] sign callback for certificate authentication
In-Reply-To: <9e0cf0bf0705081255t730263c9g35231a8ea2965db8@mail.gmail.com>
	(Alon Bar-Lev's message of "Tue\, 8 May 2007 22\:55\:05 +0300")
References: <461A36B7020000960002E069@mcclure.wal.novell.com>
	<87mz0fk3e7.fsf@mocca.josefsson.org>
	<9e0cf0bf0705081255t730263c9g35231a8ea2965db8@mail.gmail.com>
Message-ID: <874pmjsc7f.fsf@mocca.josefsson.org>

"Alon Bar-Lev" <alon.barlev at gmail.com> writes:

> Hello Simon,
>
> Can you please clean up the branch removing the scote requirement and
> PKCS#11 implementation, leaving only the engine callbacks so I can
> work on this?

Hi.  I'm making Scute an optional dependency on the branch now.

> BTW: Your API need to allow adding user data pointer so that callbacks
> will be able to access some private data.
>
> Ludovic already suggested this at:
> http://lists.gnupg.org/pipermail/gnutls-dev/2007-April/001434.html
> And I already suggested it at:
> http://lists.gnupg.org/pipermail/gnutls-dev/2007-May/001557.html

I've added this too.

> BTW2: You should add cleanup callback, so that resources can be
> released on session end.
> http://lists.gnupg.org/pipermail/gnutls-dev/2007-May/001557.html

This seem to be bloat to me, since it offers no additional
functionality.  Applications can cleanup resources when they deinit the
particular GnuTLS session that uses the sign callback, can they not?

> We can discuss the API before you start implementation, so if you
> provide the prototypes before implementation it will allow reduce
> efforts.

I'm considering to change the APIs (see below), so I didn't want to
spend time discussing the changes for the next release now (otherwise I
wouldn't have time to release it today).

When I have time to write down my ideas about the changes that are
necessary -- the sign callback should be set per
gnutls_certificate_credential_t and not per session -- we can discuss
the new API.  However, I'm going to be busy for about 10 days so nothing
will happen until after that.

What should be possible for you with the upcoming p11.2 release is to
write a PKCS#11 interface that can be invoked via the sign callback.  I
hope that you will be able to test signing via the callback and some
PKCS#11 provider that you have until I come back.  Then we your
experience and the new API, finalize it and bring it back into the 1.7.x
branch.

Thanks,
Simon

> Best Regards,
> Alon Bar-Lev.
>
> On 5/8/07, Simon Josefsson <simon at josefsson.org> wrote:
>> Hi again.  I just realized that the work I'm doing on the PKCS#11 branch
>> is rather similar to what you provided a patch for here.  The code is
>> different from yours, but let me what you think and if you can test it:
>>
>> http://article.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/2006
>>
>> I intend to move the external-signing callback API back into the 1.7.x
>> branch as soon as possible, because it looks rather safe.  I'm not sure
>> about our PKCS#11 interface library.  Alon Bar-Lev's comments indicate
>> that it may be better if we stay out of providing tighter PKCS#11
>> integration and leave that to him and others to work on.  I'd be happy
>> with that, since I personally think the PKCS#11 interface is too complex
>> to inspire good confidence in implementations of it.  Still, making it
>> easy to use OpenPGP cards is an important use-case for me.
>>
>> /Simon
>>
>> "Jacob Berkman" <jberkman at novell.com> writes:
>>
>> > Hello,
>> >
>> > I've attached a patch to gnutls which adds a callback for the signing
>> > step of certificate-based authentication.  This was needed because
>> > some smart card policies do not allow private keys to be read/exported
>> > from them.  They implement signing directly on the card.
>> >
>> > With this patch, the application can return a NULL private key, and if
>> > they implement the signing callback, can sign the data themselves.
>> >
>> > I developed this patch against gnutls 1.4.4, but it patches and builds
>> > cleanly against 1.7.7.  Please let me know if any changes are
>> > required.
>> >
>> > Thanks,
>> >  -- jacob
>> >
>> >
>> > _______________________________________________
>> > Gnutls-dev mailing list
>> > Gnutls-dev at gnupg.org
>> > http://lists.gnupg.org/mailman/listinfo/gnutls-dev
>>
>> _______________________________________________
>> Gnutls-dev mailing list
>> Gnutls-dev at gnupg.org
>> http://lists.gnupg.org/mailman/listinfo/gnutls-dev
>>



From simon at josefsson.org  Mon May 14 08:30:18 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 14 May 2007 08:30:18 +0200
Subject: [gnutls-dev] [PATCH] Fixing OpenPGP keyring import (again)
In-Reply-To: <87lkft6l94.fsf@chbouib.org> ("Ludovic =?iso-8859-1?Q?Court?=
	=?iso-8859-1?Q?=E8s=22's?= message of
	"Sun\, 13 May 2007 13\:00\:55 +0200")
References: <87lkft6l94.fsf@chbouib.org>
Message-ID: <874pmfkjd1.fsf@mocca.josefsson.org>

ludo at chbouib.org (Ludovic Court?s) writes:

> The patch below (against) `HEAD' fixes OpenPGP keyring import.

I think Timo took care of this.

> PS: BTW, how's Git going?  :-)

I'm talking with savannah.gnu.org about hosting it.  I'm not yet sure
how I want things to work.  I would prefer to push my local git
repository to josefsson.org and savannah and repo.or.cz can mirror it,
but maybe that is too much work.

/Simon


From simon at josefsson.org  Mon May 14 08:26:02 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 14 May 2007 08:26:02 +0200
Subject: [gnutls-dev] GnuTLS PKCS#11 Engine
In-Reply-To: <9e0cf0bf0705131241i637dce16t3772ed0e3528014@mail.gmail.com>
	(Alon Bar-Lev's message of "Sun\, 13 May 2007 22\:41\:24 +0300")
References: <9e0cf0bf0705131241i637dce16t3772ed0e3528014@mail.gmail.com>
Message-ID: <878xbrkjk5.fsf@mocca.josefsson.org>

"Alon Bar-Lev" <alon.barlev at gmail.com> writes:

> An initial version of gnugls-pkcs11 is available for testing.
> It should provide a simple API to access PKCS#11 cryptographic tokens.

Cool!  I'm able to authenticate to the test.gnutls.org test server using
my brand new Swedish NIDEL ID card using the OpenSC PKCS#11 provider.

Pkcs11-helper needs the following patch to compile configured with

./configure --without-crypto-engine-openssl --disable-openssl

though.

--- pkcs11h-crypto.c~	2006-12-23 18:39:16.000000000 +0100
+++ pkcs11h-crypto.c	2007-05-14 07:33:15.000000000 +0200
@@ -688,12 +688,12 @@
 	_PKCS11H_ASSERT (issuer_blob!=NULL);
 	_PKCS11H_ASSERT (cert_blob!=NULL);
 
-	if (ok && gnutls_x509_crt_init (&cert_issuer) != GNUTLS_E_SUCCESS) {
+	if (gnutls_x509_crt_init (&cert_issuer) != GNUTLS_E_SUCCESS) {
 		/* gnutls sets output */
 		cert_issuer = NULL;
 		goto cleanup;
 	}
-	if (ok && gnutls_x509_crt_init (&cert_cert) != GNUTLS_E_SUCCESS) {
+	if (gnutls_x509_crt_init (&cert_cert) != GNUTLS_E_SUCCESS) {
 		/* gnutls sets output */
 		cert_cert = NULL;
 		goto cleanup;

/Simon


From simon at josefsson.org  Fri May 11 16:08:32 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 11 May 2007 16:08:32 +0200
Subject: [gnutls-dev] Gnutls 1.7.8.p11.2
Message-ID: <87r6pnqwpr.fsf@mocca.josefsson.org>

Here is the third release on the PKCS#11 branch.  This is only minor
fixes.  I'm thinking of changing the API so that the sign callback is
set on the credential and not on the session instead, which appears to
be cleaner API-wise.  I don't have time to implement that today, though,
and I won't have time to work on it more until Monday 21:th, but I
wanted to get this release out the door anyway.

The NEWS entry is:

* Version 1.7.8.p11.2 (released 2007-05-11)

** Make Scute dependency optional.
Suggested by Alon Bar-Lev.  When Scute is not found, gnutls-cli will
not support the PKCS#11 interface.

** Add void* parameter to sign callbacks.
Suggested by Ludovic Court?s and Alon Bar-Lev.  This changes the
get/set_sign callback APIs.

** Rename gnutls_set_sign_function to gnutls_x509_sign_callback_set,
** and gnutls_get_sign_function to gnutls_x509_sign_callback_set.
The functions are X.509 specific, and the name should reflect that.
Ideally, these callbacks function should be set in the
gnutls_certificate_credentials_t structure since there is where the
private key is set.  However, the implementation to do that is more
complicated.

** API and ABI modifications:
gnutls_set_sign_function: REMOVED, renamed to gnutls_x509_sign_callback_set.
gnutls_x509_sign_callback_set: NEW, renamed from gnutls_set_sign_function.
gnutls_get_sign_function: REMOVED, renamed to gnutls_x509_sign_callback_get.
gnutls_x509_sign_callback_get: NEW, renamed from gnutls_get_sign_function.
gnutls_sign_func: CHANGED, added userdata type.

Warning!  This is even more experimental than the experimental 1.7.x
branch.  However, the changes compared to 1.7.8 are intentionally kept
minimal, to facilitate easy merging later on.

The support is limited to:

1) Optional support for build-time linking to the PKCS#11 provider
   scute, see http://www.scute.org/.

2) Retrieving trusted CA certificates from the PKCS#11 provider.  (If
scute is installed.)

3) Retrieving user certificates from the PKCS#11 provider.  (If scute is
installed.)

4) Provide a callback to perform signing operations.

5) Provide an API to perform PKCS#11 signing via the PKCS#11 provider.

You can test the sign callback infrastructure separately, if you want to
implement your own PKCS#11 interface or similar.

To test the PKCS#11 integration, you'll need to build scute 1.1.0, and
set it up (try using it in mozilla), which requires some reading, see
the Scute manual.  I generated new keys on an OpenPGP smartcard with
gpg2 --edit-card and gpgsm-gencert.sh, then signed the CSR with certtool
using the GnuTLS test CA, and imported the certificates using 'gpgsm
--import'.

If someone can explain to me how I can test other PKCS#11 providers, I
can test them too.  Supporting the NSS soft token provider is an
important target.

The gnutls-cli tool in this release automatically import all CAs from
Scute, and will load the user certificates too, and invoke Scute for
signing.  Here is an output from running it against the GnuTLS test
server:

jas at mocca:~/src/gnutls-pkcs11$ ~/src/gnutls-pkcs11/src/gnutls-cli --port 5556 test.gnutls.org --ctypes x509
Resolving 'test.gnutls.org'...
Connecting to '217.13.230.178:5556'...
- Received authorization data, format 01 of 59 bytes
  data: 546869732069732074686520582e3530392041747472696275746520436572746966696361746520617574686f72697a6174696f6e20646174610a
- Received authorization data, format 02 of 46 bytes
  data: 54686973206973207468652053414d4c20617373657274696f6e20617574686f72697a6174696f6e20646174610a
- Successfully sent 1 certificate(s) to server.
- Certificate type: X.509
 - Got a certificate list of 1 certificates.

 - Certificate[0] info:
 # The hostname in the certificate matches 'test.gnutls.org'.
 # valid since: Wed Apr 18 15:29:21 CEST 2007
 # expires at: Thu Apr 17 15:29:21 CEST 2008
 # fingerprint: 08:8B:4B:0F:68:88:4E:95:15:D6:AC:F6:B3:64:81:5B
 # Subject's DN: O=GnuTLS test server,CN=test.gnutls.org
 # Issuer's DN: CN=GnuTLS test CA


- Peer's certificate is trusted
- Version: TLS 1.2
- Key Exchange: DHE RSA
- Cipher: AES 256 CBC
- MAC: SHA
- Compression: DEFLATE
- Handshake was completed

- Simple Client Mode:

GET / HTTP/1.1

HTTP/1.0 200 OK
Content-type: text/html


<HTML><BODY>
<CENTER><H1>This is <a href="http://www.gnu.org/software/gnutls">GNUTLS</a></H1></CENTER>


<p>Session ID: <i>403FF1B7889FD2BF9CA9E9B70120CFB7C01F1A08EC9FD2BF0100000000042B08</i></p>
<h5>If your browser supports session resuming, then you should see the same session ID, when you press the <b>reload</b> button.</h5>

<p>Server Name: test.gnutls.org</p>
Ephemeral DH using prime of <b>1032</b> bits.<br>
<P>
<TABLE border=1><TR><TD>Protocol version:</TD><TD>TLS 1.2</TD></TR>
<TR><TD>Certificate Type:</TD><TD>X.509</TD></TR>
<TR><TD>Key Exchange:</TD><TD>DHE RSA</TD></TR>
<TR><TD>Compression</TD><TD>DEFLATE</TD></TR>
<TR><TD>Cipher</TD><TD>AES 256 CBC</TD></TR>
<TR><TD>MAC</TD><TD>SHA</TD></TR>
<TR><TD>Ciphersuite</TD><TD>DHE_RSA_AES_256_CBC_SHA1</TD></TR></p></TABLE>
<hr><PRE>X.509 Certificate Information:
        Version: 3
        Serial Number (hex): 4628a165
        Issuer: CN=GnuTLS test CA
        Validity:
                Not Before: Fri Apr 20 11:17:59 UTC 2007
                Not After: Wed Oct 17 11:18:02 UTC 2007
        Subject: O=Simon Josefsson,CN=Test Key
        Subject Public Key Algorithm: RSA
                Modulus (bits 1024):
                        ad:9e:08:78:73:a7:19:b0:45:58:0f:77:df:68:52:1d
                        74:c3:06:ad:d4:01:8f:e7:73:a6:2b:9b:26:90:85:bc
                        5b:f1:8c:a4:6e:44:a4:f0:c0:51:79:05:05:7e:2c:35
                        4f:fc:de:72:7f:b5:35:6f:71:8d:24:58:ee:09:a1:ba
                        1b:59:c0:64:73:50:94:f0:4f:cc:20:46:24:f3:a5:c1
                        a2:e2:80:92:9e:62:48:d3:67:91:5f:51:9e:f6:1a:fb
                        f4:0a:5d:26:7e:04:2e:15:51:a8:22:28:87:07:ca:0f
                        6e:cb:a0:58:a1:35:8b:6e:cb:9f:e0:94:a2:89:ce:31
                Exponent:
                        86:6d:78:01
        Extensions:
                Basic Constraints (critical):
                        Certificate Authority (CA): FALSE
                Key Purpose (not critical):
                        TLS WWW Client.
                        TLS WWW Server.
                Subject Alternative Name (not critical):
                        DNSname: josefsson.org
                Key Usage (critical):
                        Digital signature.
                        Key encipherment.
                Subject Key Identifier (not critical):
                        b83879aed2d2f990c21a2732e2441c056ff9f9b1
                Authority Key Identifier (not critical):
                        e93c1cfbad926ee606a4562ca2e1c05327c8f295
        Signature Algorithm: RSA-SHA
        Signature:
                86:16:40:75:4a:75:c4:dd:1b:57:cf:de:d3:c8:3c:29
                31:a4:99:18:0e:86:9b:d6:5b:6d:7c:d4:1b:8c:a3:64
                de:e1:27:64:19:7c:22:2d:70:4a:11:d8:3f:b2:27:1b
                28:c5:92:d1:62:da:5a:15:4f:90:b3:d4:15:87:00:57
                a0:c8:9e:f1:96:e2:82:f2:d9:9f:4d:28:df:37:94:83
                bb:84:56:0f:06:f0:32:79:4a:38:46:e2:df:f3:16:cc
                35:da:1d:04:32:61:6f:da:e4:4d:3a:44:54:56:82:47
                6a:8e:c7:b7:79:e3:f3:1c:f2:b4:8d:ff:13:35:b9:3e
Other Information:
        MD5 fingerprint:
                c9132f91ca88ffba4d40c420570e2986
        SHA-1 fingerprint:
                bd5f80de63034ec9e2841e6309552e345c5f226f
        Public Key Id:
                b83879aed2d2f990c21a2732e2441c056ff9f9b1
</PRE><P><PRE>
</PRE>
<hr><P>Your HTTP header was:<PRE></PRE></P>
</BODY></HTML>

- Peer has closed the GNUTLS connection
jas at mocca:~/src/gnutls-pkcs11$

To debug things, add a '-d 10' and you'll see some debug info.  First
loading the CA certificates:

|<2>| PKCS#11 slot count 1
|<2>| PKCS#11 slot[1].description: `GnuPG Smart Card Daemon                                         g10 Code GmbH                   '
|<2>| PKCS#11 slot[1].manufacturer: `g10 Code GmbH                   '
|<2>| PKCS#11 slot[1].token.label: `D2760001240101010001000005320000PPC Card Systems                OpenPGP         00000532
'
|<2>| Adding CA certificate 1532B4BA5A8A7988CA264283591BA3A21C0BCC24 (0)
|<2>| Skipping certificate BD5F80DE63034EC9E2841E6309552E345C5F226F (0/0)

Then the user certificates:

|<2>| PKCS#11 slot count 1
|<2>| PKCS#11 slot[1].description: `GnuPG Smart Card Daemon                                         g10 Code GmbH                   '
|<2>| PKCS#11 slot[1].manufacturer: `g10 Code GmbH                   '
|<2>| PKCS#11 slot[1].token.label: `D2760001240101010001000005320000PPC Card Systems                OpenPGP         00000532
'
|<2>| Added private key BD5F80DE63034EC9E2841E6309552E345C5F226F from slot 1
|<2>| Skipping certificate 1532B4BA5A8A7988CA264283591BA3A21C0BCC24 (1/0)
|<2>| Adding user certificate BD5F80DE63034EC9E2841E6309552E345C5F226F
- Successfully sent 1 certificate(s) to server.

Then signing using the user certificate:

|<2>| PKCS#11 slot count 1
|<2>| PKCS#11 slot[1].description: `GnuPG Smart Card Daemon                                         g10 Code GmbH                   '
|<2>| PKCS#11 slot[1].manufacturer: `g10 Code GmbH                   '
|<2>| PKCS#11 slot[1].token.label: `D2760001240101010001000005320000PPC Card Systems                OpenPGP         00000532
'
|<3>| HSK[8079ee0]: CERTIFICATE VERIFY was send [134 bytes]

The 1532B4BA5A8A7988CA264283591BA3A21C0BCC24 certificate is the GnuTLS
CA, and the BD5F80DE63034EC9E2841E6309552E345C5F226F certificate is my
client certificate.

Here are the compressed sources (4.3MB):
  ftp://ftp.gnutls.org/pub/gnutls/devel/gnutls-1.7.8.p11.2.tar.bz2
  http://josefsson.org/gnutls/releases/pkcs11/gnutls-1.7.8.p11.2.tar.bz2

Here are GPG detached signatures signed using key 0xB565716F:
  ftp://ftp.gnutls.org/pub/gnutls/devel/gnutls-1.7.8.p11.2.tar.bz2.sig
  http://josefsson.org/gnutls/releases/pkcs11/gnutls-1.7.8.p11.2.tar.bz2.sig

Here are the SHA-1 and SHA-224 checksums:

10fddb83282c467e2299790a8badc2ed4c74ca1c  gnutls-1.7.8.p11.2.tar.bz2
40c1eeb16c532ffed1357b2e54ce0a47e1119f6d  gnutls-1.7.8.p11.2.tar.bz2.sig

94557b4c9d1050751f16fdfc4ca7138b88914049e9347eb50b0f70f8  gnutls-1.7.8.p11.2.tar.bz2
5219eb7c41f155ba1e5772eafa55b99e9b1be3337aa2147b62886180  gnutls-1.7.8.p11.2.tar.bz2.sig

Improving GnuTLS is costly, but you can help!  We are looking for
organizations that find GnuTLS useful and wish to contribute back.
You can contribute by reporting bugs, improve the software, or donate
money or equipment.

Commercial support contracts for GnuTLS are available, and they help
finance continued maintenance.  Simon Josefsson Datakonsult, a
Stockholm based privately held company, is currently funding GnuTLS
maintenance.  We are always looking for interesting development
projects.  See http://josefsson.org/ for more details.

/Simon



From alon.barlev at gmail.com  Mon May 14 09:35:52 2007
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Mon, 14 May 2007 10:35:52 +0300
Subject: [gnutls-dev] GnuTLS PKCS#11 Engine
In-Reply-To: <878xbrkjk5.fsf@mocca.josefsson.org>
References: <9e0cf0bf0705131241i637dce16t3772ed0e3528014@mail.gmail.com>
	<878xbrkjk5.fsf@mocca.josefsson.org>
Message-ID: <9e0cf0bf0705140035h251f0766h5f04a604d7eeddc0@mail.gmail.com>

On 5/14/07, Simon Josefsson <simon at josefsson.org> wrote:
> "Alon Bar-Lev" <alon.barlev at gmail.com> writes:
>
> > An initial version of gnugls-pkcs11 is available for testing.
> > It should provide a simple API to access PKCS#11 cryptographic tokens.
>
> Cool!  I'm able to authenticate to the test.gnutls.org test server using
> my brand new Swedish NIDEL ID card using the OpenSC PKCS#11 provider.

Great!
Please try Scute... I've never tried it before... It should use
protected authentication, it means that the program should not ask you
for PIN but the gnupg pinentry should pop up.

Some questions:

1. Do you have any comments regarding the API?

2. Do you want me to add the gnutls interface to pkcs11-helper (as in
OpenSSL case) or leave it as a separate module?

3. Do you think there is advantage of creating subset API of
pkcs11-helper available (current state), or have the developer access
pkcs11-helper directly and provide some utilities for GnuTLS
environment (as in OpenSSL case).

> Pkcs11-helper needs the following patch to compile configured with
>
> ./configure --without-crypto-engine-openssl --disable-openssl
>
> though.

Oops... Long time since I tried GnuTLS only... :)
Thanks!

Best Regards,
Alon Bar-Lev.


From ludo at chbouib.org  Mon May 14 09:35:55 2007
From: ludo at chbouib.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Mon, 14 May 2007 09:35:55 +0200
Subject: [gnutls-dev] [PATCH] Fixing OpenPGP keyring import (again)
References: <87lkft6l94.fsf@chbouib.org> <4646F2EE.3040505@gmx.net>
	<87ps546fvd.fsf@chbouib.org> <46472CFF.7050508@gmx.net>
Message-ID: <87wszbq2lg.fsf@chbouib.org>

Hi,

Timo Schulz <twoaday at gmx.net> writes:

> I did, but _after_ I applied the patch for extras. I wasn't aware
> the raw import did not work, so the patch makes sense. Thanks.

Any idea how we can get an ASCII-armored keyring so that we can test it
as well?

I was (presumably) able to create one with:

  $ gpg --keyring ./openpgp-keyring.gpg --export -a > t

But then `gpg' was unable to show me its contents:

  $ gpg --keyring ./t -a --list-keys
  [Lists ~/.gnupg/pubring.gpg...]
  gpg: [don't know]: invalid packet (ctb=2d)
  gpg: keydb_search_next failed: invalid packet

I was able to open it using the GnuTLS keyring API, though, which is
encouraging.

Thanks,
Ludovic.



From wk at gnupg.org  Mon May 14 10:08:05 2007
From: wk at gnupg.org (Werner Koch)
Date: Mon, 14 May 2007 10:08:05 +0200
Subject: [gnutls-dev] [PATCH] Fixing OpenPGP keyring import (again)
In-Reply-To: <87wszbq2lg.fsf@chbouib.org> ("Ludovic =?utf-8?Q?Court=C3=A8s?=
	=?utf-8?Q?=22's?= message of "Mon\, 14 May 2007 09\:35\:55 +0200")
References: <87lkft6l94.fsf@chbouib.org> <4646F2EE.3040505@gmx.net>
	<87ps546fvd.fsf@chbouib.org> <46472CFF.7050508@gmx.net>
	<87wszbq2lg.fsf@chbouib.org>
Message-ID: <87odknygii.fsf@wheatstone.g10code.de>

On Mon, 14 May 2007 09:35, ludo at chbouib.org said:

>   $ gpg --keyring ./t -a --list-keys
>   [Lists ~/.gnupg/pubring.gpg...]
>   gpg: [don't know]: invalid packet (ctb=2d)
>   gpg: keydb_search_next failed: invalid packet

A keyring must not be ASCII armored and using the transfer format
directly as the keyring is not suggested for future compatibility
reasons.

To show the content of an exported keyring, simply run

  $ gpg ./t



Salam-Shalom,

   Werner



From twoaday at gmx.net  Mon May 14 10:47:02 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Mon, 14 May 2007 10:47:02 +0200
Subject: [gnutls-dev] [PATCH] Fixing OpenPGP keyring import (again)
In-Reply-To: <87wszbq2lg.fsf@chbouib.org>
References: <87lkft6l94.fsf@chbouib.org>
	<4646F2EE.3040505@gmx.net>	<87ps546fvd.fsf@chbouib.org>
	<46472CFF.7050508@gmx.net> <87wszbq2lg.fsf@chbouib.org>
Message-ID: <46482206.7010203@gmx.net>

Ludovic Court?s wrote:

> I was (presumably) able to create one with:
> 
>   $ gpg --keyring ./openpgp-keyring.gpg --export -a > t
> 
> But then `gpg' was unable to show me its contents:
> 
>   $ gpg --keyring ./t -a --list-keys
>   gpg: [don't know]: invalid packet (ctb=2d)
>   gpg: keydb_search_next failed: invalid packet

To make sure I understand you. You try to check than an
armored key file is correctly formatted and contains
valid openpgp keys?

We should either write a small helper program or a handy
function.


	Timo


From twoaday at gmx.net  Mon May 14 10:47:40 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Mon, 14 May 2007 10:47:40 +0200
Subject: [gnutls-dev] Malformed raw keyring in test
In-Reply-To: <87wszckkqu.fsf@mocca.josefsson.org>
References: <4646FEF7.9060007@gmx.net>
	<87sla050a6.fsf@chbouib.org>	<46472D84.2090908@gmx.net>
	<87wszckkqu.fsf@mocca.josefsson.org>
Message-ID: <4648222C.7020605@gmx.net>

Simon Josefsson wrote:

> Sure, if it just touches opencdk or the opencdk glue in gnutls without
> changing any APIs, please go ahead.

OK, then I will add the patch for the raw keyring and the selftest.


	Timo


From simon at josefsson.org  Mon May 14 10:54:45 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 14 May 2007 10:54:45 +0200
Subject: [gnutls-dev] GnuTLS PKCS#11 Engine
In-Reply-To: <9e0cf0bf0705140035h251f0766h5f04a604d7eeddc0@mail.gmail.com>
	(Alon Bar-Lev's message of "Mon\, 14 May 2007 10\:35\:52 +0300")
References: <9e0cf0bf0705131241i637dce16t3772ed0e3528014@mail.gmail.com>
	<878xbrkjk5.fsf@mocca.josefsson.org>
	<9e0cf0bf0705140035h251f0766h5f04a604d7eeddc0@mail.gmail.com>
Message-ID: <878xbriy3u.fsf@mocca.josefsson.org>

"Alon Bar-Lev" <alon.barlev at gmail.com> writes:

> On 5/14/07, Simon Josefsson <simon at josefsson.org> wrote:
>> "Alon Bar-Lev" <alon.barlev at gmail.com> writes:
>>
>> > An initial version of gnugls-pkcs11 is available for testing.
>> > It should provide a simple API to access PKCS#11 cryptographic tokens.
>>
>> Cool!  I'm able to authenticate to the test.gnutls.org test server using
>> my brand new Swedish NIDEL ID card using the OpenSC PKCS#11 provider.
>
> Great!
> Please try Scute... I've never tried it before... It should use
> protected authentication, it means that the program should not ask you
> for PIN but the gnupg pinentry should pop up.

It doesn't seem to work.  Here is what happens.  Any ideas?

jas at mocca:~/src/gnutls-pkcs11-0.01/src$ ./gnutls-pkcs11-cli --add-provider=/usr/local/lib/libscute.so --cmd=ids --host=test.gnutls.org --port=5556 --debug 10
|<5>| PKCS#11: pkcs11h_addProvider entry pid=30115, reference='/usr/local/lib/libscute.so', provider_location='/usr/local/lib/libscute.so', allow_protected_auth=1, mask_private_mode=00000000, cert_is_private=0
|<4>| PKCS#11: Adding provider '/usr/local/lib/libscute.so'-'/usr/local/lib/libscute.so'
|<5>| PKCS#11: _pkcs11h_slotevent_notify entry
|<5>| PKCS#11: _pkcs11h_slotevent_notify return
|<4>| PKCS#11: Provider '/usr/local/lib/libscute.so' added rv=0-'CKR_OK'
|<5>| PKCS#11: pkcs11h_addProvider return rv=0-'CKR_OK'
|<5>| PKCS#11: pkcs11h_certificate_enumCertificateIds entry method=1, mask_prompt=00000003, p_cert_id_issuers_list=0xbf822628, p_cert_id_end_list=0xbf822624
|<5>| PKCS#11: _pkcs11h_session_getSlotList entry provider=0x8069df0, token_present=1, pSlotList=0xbf8225c8, pulCount=0xbf8225c4
|<5>| PKCS#11: pkcs11h_forkFixup entry pid=30129
scute: scute_agent_initialize: GPG Agent connection already established
|<5>| PKCS#11: pkcs11h_forkFixup return
|<5>| PKCS#11: pkcs11h_terminate entry
|<4>| PKCS#11: Removing providers
|<5>| PKCS#11: pkcs11h_removeProvider entry reference='/usr/local/lib/libscute.so'
|<4>| PKCS#11: Removing provider '/usr/local/lib/libscute.so'
|<5>| PKCS#11: _pkcs11h_slotevent_notify entry
|<5>| PKCS#11: _pkcs11h_slotevent_notify return
|<5>| PKCS#11: pkcs11h_removeProvider return rv=0-'CKR_OK'
|<4>| PKCS#11: Releasing sessions
|<4>| PKCS#11: Terminating slotevent
|<5>| PKCS#11: _pkcs11h_slotevent_terminate entry
|<5>| PKCS#11: _pkcs11h_slotevent_terminate return
|<4>| PKCS#11: Marking as uninitialized
can't connect server: ec=31.16383
|<5>| PKCS#11: _pkcs11h_session_getSlotList return rv=6-'CKR_FUNCTION_FAILED' *pulCount=0
|<4>| PKCS#11: Cannot get slot list for provider 'g10 Code GmbH' rv=6-'CKR_FUNCTION_FAILED'
|<5>| PKCS#11: __pkcs11h_certificate_splitCertificateIdList entry cert_id_all=(nil), p_cert_id_issuers_list=0xbf822628, p_cert_id_end_list=0xbf822624
|<5>| PKCS#11: __pkcs11h_certificate_splitCertificateIdList return rv=0-'CKR_OK'
|<5>| PKCS#11: pkcs11h_certificate_enumCertificateIds return rv=0-'CKR_OK'
jas at mocca:~/src/gnutls-pkcs11-0.01/src$

I suspect Scute is failing here.

> Some questions:
>
> 1. Do you have any comments regarding the API?
>
> 2. Do you want me to add the gnutls interface to pkcs11-helper (as in
> OpenSSL case) or leave it as a separate module?
>
> 3. Do you think there is advantage of creating subset API of
> pkcs11-helper available (current state), or have the developer access
> pkcs11-helper directly and provide some utilities for GnuTLS
> environment (as in OpenSSL case).

I haven't really made up my mind about how things should work here.

One concern I have is any OpenSSL dependency.

Another concern is that I would like GnuTLS to include some native
PKCS#11 interface, to support the OpenPGP card, GNOME Seahorse, and
possibly NSS's provider directly.  I think it doesn't make sense for
GnuTLS to handle pin's etc.  I think GnuTLS should assume the PKCS#11
provider takes care of PIN entry internally.  (Although I don't know how
the NSS provider works.)  I don't yet know how this is best implemented.
Including a copy of pkcs11-helper and your gnutls-pkcs11 library
(assuming the copyright and license situation is suitable) is a
possibility.

/Simon


From alon.barlev at gmail.com  Mon May 14 12:44:43 2007
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Mon, 14 May 2007 13:44:43 +0300
Subject: [gnutls-dev] GnuTLS PKCS#11 Engine
In-Reply-To: <878xbriy3u.fsf@mocca.josefsson.org>
References: <9e0cf0bf0705131241i637dce16t3772ed0e3528014@mail.gmail.com>
	<878xbrkjk5.fsf@mocca.josefsson.org>
	<9e0cf0bf0705140035h251f0766h5f04a604d7eeddc0@mail.gmail.com>
	<878xbriy3u.fsf@mocca.josefsson.org>
Message-ID: <9e0cf0bf0705140344u684a71cdg641f115d93a1c270@mail.gmail.com>

On 5/14/07, Simon Josefsson <simon at josefsson.org> wrote:
> It doesn't seem to work.  Here is what happens.  Any ideas?

Yes...
It seems that it forks.
After fork, I must call C_Initialize/C_Finalize again to cleanup state
in child. This is part of PKCS#11 spec.
Nobody thought about a provider that doing fork()... :)
So I guess scote should have somekind of recursion protection on
C_Initialize/C_Finalize and also have reference counter so that
multiple call of C_Initialize will be allowed.

> > Some questions:
> >
> > 1. Do you have any comments regarding the API?
> >
> > 2. Do you want me to add the gnutls interface to pkcs11-helper (as in
> > OpenSSL case) or leave it as a separate module?
> >
> > 3. Do you think there is advantage of creating subset API of
> > pkcs11-helper available (current state), or have the developer access
> > pkcs11-helper directly and provide some utilities for GnuTLS
> > environment (as in OpenSSL case).
>
> I haven't really made up my mind about how things should work here.
>
> One concern I have is any OpenSSL dependency.

Can you please explain...?
There is none.

> Another concern is that I would like GnuTLS to include some native
> PKCS#11 interface, to support the OpenPGP card, GNOME Seahorse, and
> possibly NSS's provider directly.  I think it doesn't make sense for
> GnuTLS to handle pin's etc.  I think GnuTLS should assume the PKCS#11
> provider takes care of PIN entry internally.  (Although I don't know how
> the NSS provider works.)  I don't yet know how this is best implemented.
> Including a copy of pkcs11-helper and your gnutls-pkcs11 library
> (assuming the copyright and license situation is suitable) is a
> possibility.

Why not just maintain it as sepearate component?
What is the benafit in maintaining one large library?

Best Regards,
Alon Bar-Lev.


From simon at josefsson.org  Mon May 14 13:23:36 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 14 May 2007 13:23:36 +0200
Subject: [gnutls-dev] GnuTLS PKCS#11 Engine
In-Reply-To: <9e0cf0bf0705140344u684a71cdg641f115d93a1c270@mail.gmail.com>
	(Alon Bar-Lev's message of "Mon\, 14 May 2007 13\:44\:43 +0300")
References: <9e0cf0bf0705131241i637dce16t3772ed0e3528014@mail.gmail.com>
	<878xbrkjk5.fsf@mocca.josefsson.org>
	<9e0cf0bf0705140035h251f0766h5f04a604d7eeddc0@mail.gmail.com>
	<878xbriy3u.fsf@mocca.josefsson.org>
	<9e0cf0bf0705140344u684a71cdg641f115d93a1c270@mail.gmail.com>
Message-ID: <87646vhcnb.fsf@mocca.josefsson.org>

"Alon Bar-Lev" <alon.barlev at gmail.com> writes:

> On 5/14/07, Simon Josefsson <simon at josefsson.org> wrote:
>> It doesn't seem to work.  Here is what happens.  Any ideas?
>
> Yes...
> It seems that it forks.
> After fork, I must call C_Initialize/C_Finalize again to cleanup state
> in child. This is part of PKCS#11 spec.
> Nobody thought about a provider that doing fork()... :)
> So I guess scote should have somekind of recursion protection on
> C_Initialize/C_Finalize and also have reference counter so that
> multiple call of C_Initialize will be allowed.

I suppose this is just PKCS#11 internal stuff, and I hope you will solve
it.  If I can assist in testing anything, let me know.

>> One concern I have is any OpenSSL dependency.
>
> Can you please explain...?
> There is none.

pkcs11-helper seem to link to OpenSSL by default.  As far as I
understand, distributions cannot distribute packages that links
pkcs11-helper together with gnutls via your gnutls-pkcs11 legally.
Perhaps gnutls and/or gnutls-pkcs11 could check whether pkcs11-helper
picks up OpenSSL, and if so, emit an error message.

>> Another concern is that I would like GnuTLS to include some native
>> PKCS#11 interface, to support the OpenPGP card, GNOME Seahorse, and
>> possibly NSS's provider directly.  I think it doesn't make sense for
>> GnuTLS to handle pin's etc.  I think GnuTLS should assume the PKCS#11
>> provider takes care of PIN entry internally.  (Although I don't know how
>> the NSS provider works.)  I don't yet know how this is best implemented.
>> Including a copy of pkcs11-helper and your gnutls-pkcs11 library
>> (assuming the copyright and license situation is suitable) is a
>> possibility.
>
> Why not just maintain it as sepearate component?
> What is the benafit in maintaining one large library?

They are separate components, see the pkcs11-branch: there is a
standalone libgnutls-pkcs11 library (see the top-level pkcs11/
directory) that provides a simple PKCS#11 interface to Scute via the
header gnutls/pkcs11.h.  Applications can chose to implement the sign
callback using GnuTLS's pkcs11 library, but then they'll have to link to
it, or your library, or some other library (that may use CAPI or
whatever).

/Simon


From alon.barlev at gmail.com  Mon May 14 13:28:54 2007
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Mon, 14 May 2007 14:28:54 +0300
Subject: [gnutls-dev] GnuTLS PKCS#11 Engine
In-Reply-To: <87646vhcnb.fsf@mocca.josefsson.org>
References: <9e0cf0bf0705131241i637dce16t3772ed0e3528014@mail.gmail.com>
	<878xbrkjk5.fsf@mocca.josefsson.org>
	<9e0cf0bf0705140035h251f0766h5f04a604d7eeddc0@mail.gmail.com>
	<878xbriy3u.fsf@mocca.josefsson.org>
	<9e0cf0bf0705140344u684a71cdg641f115d93a1c270@mail.gmail.com>
	<87646vhcnb.fsf@mocca.josefsson.org>
Message-ID: <9e0cf0bf0705140428t2c1f507ere46b9e6edc68fc09@mail.gmail.com>

On 5/14/07, Simon Josefsson <simon at josefsson.org> wrote:
> I suppose this is just PKCS#11 internal stuff, and I hope you will solve
> it.  If I can assist in testing anything, let me know.

This is sute problem, I cannot solved this... I CCed Marcus, I hope he
will be able to solve it.

> pkcs11-helper seem to link to OpenSSL by default.  As far as I
> understand, distributions cannot distribute packages that links
> pkcs11-helper together with gnutls via your gnutls-pkcs11 legally.
> Perhaps gnutls and/or gnutls-pkcs11 could check whether pkcs11-helper
> picks up OpenSSL, and if so, emit an error message.

I don't understand...
The OpenSSL stuff is not used, I can provide an engine for GnuTLS
inside the gnutls-pkcs11.
Even if it linked it is not used.

> > Why not just maintain it as sepearate component?
> > What is the benafit in maintaining one large library?
>
> They are separate components, see the pkcs11-branch: there is a
> standalone libgnutls-pkcs11 library (see the top-level pkcs11/
> directory) that provides a simple PKCS#11 interface to Scute via the
> header gnutls/pkcs11.h.  Applications can chose to implement the sign
> callback using GnuTLS's pkcs11 library, but then they'll have to link to
> it, or your library, or some other library (that may use CAPI or
> whatever).

I don't understand...
The simple scute implementation is irrelevant for 99.999% of users.
And if application chooses to use PKCS#11 it can also chose to add a
library to its linkage.

Alon.


From alon.barlev at gmail.com  Mon May 14 13:30:19 2007
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Mon, 14 May 2007 14:30:19 +0300
Subject: [gnutls-dev] GnuTLS PKCS#11 Engine
In-Reply-To: <9e0cf0bf0705140428t2c1f507ere46b9e6edc68fc09@mail.gmail.com>
References: <9e0cf0bf0705131241i637dce16t3772ed0e3528014@mail.gmail.com>
	<878xbrkjk5.fsf@mocca.josefsson.org>
	<9e0cf0bf0705140035h251f0766h5f04a604d7eeddc0@mail.gmail.com>
	<878xbriy3u.fsf@mocca.josefsson.org>
	<9e0cf0bf0705140344u684a71cdg641f115d93a1c270@mail.gmail.com>
	<87646vhcnb.fsf@mocca.josefsson.org>
	<9e0cf0bf0705140428t2c1f507ere46b9e6edc68fc09@mail.gmail.com>
Message-ID: <9e0cf0bf0705140430r196a663fv3b9efacf2a20b8a@mail.gmail.com>

On 5/14/07, Alon Bar-Lev <alon.barlev at gmail.com> wrote:
> On 5/14/07, Simon Josefsson <simon at josefsson.org> wrote:
> > I suppose this is just PKCS#11 internal stuff, and I hope you will solve
> > it.  If I can assist in testing anything, let me know.
>
> This is sute problem, I cannot solved this... I CCed Marcus, I hope he
> will be able to solve it.

Hmmm...
You can try to configure pkcs11-helper with --disable-threading
--disable-slotevent, I guess it will stop fixup the fork()
automatically.

Alon.


From simon at josefsson.org  Mon May 14 13:45:47 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 14 May 2007 13:45:47 +0200
Subject: [gnutls-dev] GnuTLS PKCS#11 Engine
In-Reply-To: <9e0cf0bf0705140428t2c1f507ere46b9e6edc68fc09@mail.gmail.com>
	(Alon Bar-Lev's message of "Mon\, 14 May 2007 14\:28\:54 +0300")
References: <9e0cf0bf0705131241i637dce16t3772ed0e3528014@mail.gmail.com>
	<878xbrkjk5.fsf@mocca.josefsson.org>
	<9e0cf0bf0705140035h251f0766h5f04a604d7eeddc0@mail.gmail.com>
	<878xbriy3u.fsf@mocca.josefsson.org>
	<9e0cf0bf0705140344u684a71cdg641f115d93a1c270@mail.gmail.com>
	<87646vhcnb.fsf@mocca.josefsson.org>
	<9e0cf0bf0705140428t2c1f507ere46b9e6edc68fc09@mail.gmail.com>
Message-ID: <87wszbfx1w.fsf@mocca.josefsson.org>

"Alon Bar-Lev" <alon.barlev at gmail.com> writes:

> On 5/14/07, Simon Josefsson <simon at josefsson.org> wrote:
>> I suppose this is just PKCS#11 internal stuff, and I hope you will solve
>> it.  If I can assist in testing anything, let me know.
>
> This is sute problem, I cannot solved this... I CCed Marcus, I hope he
> will be able to solve it.

Yup, right.

>> pkcs11-helper seem to link to OpenSSL by default.  As far as I
>> understand, distributions cannot distribute packages that links
>> pkcs11-helper together with gnutls via your gnutls-pkcs11 legally.
>> Perhaps gnutls and/or gnutls-pkcs11 could check whether pkcs11-helper
>> picks up OpenSSL, and if so, emit an error message.
>
> I don't understand...
> The OpenSSL stuff is not used, I can provide an engine for GnuTLS
> inside the gnutls-pkcs11.
> Even if it linked it is not used.

The license is on the source code, and by using the OpenSSL API I
believe the FSF would consider pkcs11-helper to be a derived work from
OpenSSL, and thus GPL-incompatible.  This would have to be confirmed
with the FSF, though.

>> > Why not just maintain it as sepearate component?
>> > What is the benafit in maintaining one large library?
>>
>> They are separate components, see the pkcs11-branch: there is a
>> standalone libgnutls-pkcs11 library (see the top-level pkcs11/
>> directory) that provides a simple PKCS#11 interface to Scute via the
>> header gnutls/pkcs11.h.  Applications can chose to implement the sign
>> callback using GnuTLS's pkcs11 library, but then they'll have to link to
>> it, or your library, or some other library (that may use CAPI or
>> whatever).
>
> I don't understand...
> The simple scute implementation is irrelevant for 99.999% of users.

That may be true, but as far as I can tell, the simple scute
implementation doesn't harm anything else, so I don't see a problem with
it.

> And if application chooses to use PKCS#11 it can also chose to add a
> library to its linkage.

Yes, that is the point.  Applications that wants to support external
signing will have to do something extra.  That can link to your
gnutls-pkcs11 library, or my scute gnutls-pkcs11 library (there appears
to be a naming conflict here though), or something else, or even
implement everything by itself.  It is even possible to do all at at the
same time, if properly multiplexed by the application.  The nice
property is that the core GnuTLS library doesn't need to know about
this.

/Simon


From simon at josefsson.org  Mon May 14 13:50:21 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 14 May 2007 13:50:21 +0200
Subject: [gnutls-dev] GnuTLS PKCS#11 Engine
In-Reply-To: <9e0cf0bf0705140430r196a663fv3b9efacf2a20b8a@mail.gmail.com>
	(Alon Bar-Lev's message of "Mon\, 14 May 2007 14\:30\:19 +0300")
References: <9e0cf0bf0705131241i637dce16t3772ed0e3528014@mail.gmail.com>
	<878xbrkjk5.fsf@mocca.josefsson.org>
	<9e0cf0bf0705140035h251f0766h5f04a604d7eeddc0@mail.gmail.com>
	<878xbriy3u.fsf@mocca.josefsson.org>
	<9e0cf0bf0705140344u684a71cdg641f115d93a1c270@mail.gmail.com>
	<87646vhcnb.fsf@mocca.josefsson.org>
	<9e0cf0bf0705140428t2c1f507ere46b9e6edc68fc09@mail.gmail.com>
	<9e0cf0bf0705140430r196a663fv3b9efacf2a20b8a@mail.gmail.com>
Message-ID: <87sl9zfwua.fsf@mocca.josefsson.org>

"Alon Bar-Lev" <alon.barlev at gmail.com> writes:

> On 5/14/07, Alon Bar-Lev <alon.barlev at gmail.com> wrote:
>> On 5/14/07, Simon Josefsson <simon at josefsson.org> wrote:
>> > I suppose this is just PKCS#11 internal stuff, and I hope you will solve
>> > it.  If I can assist in testing anything, let me know.
>>
>> This is sute problem, I cannot solved this... I CCed Marcus, I hope he
>> will be able to solve it.
>
> Hmmm...
> You can try to configure pkcs11-helper with --disable-threading
> --disable-slotevent, I guess it will stop fixup the fork()
> automatically.

It works!  (The key below is on the OpenPGP smart card.)

/Simon

jas at mocca:~/src/gnutls-pkcs11-0.01/src$ ./gnutls-pkcs11-cli --add-provider=/usr/local/lib/libscute.so --cmd=connect --host=test.gnutls.org --port=5556 --pkcs11-id='PPC\x20Card\x20Systems/OpenPGP/00000532/D2760001240101010001000005320000/42443546383044453633303334454339453238343145363330393535324533343543354632323646'
Resolving 'test.gnutls.org'...
Connecting to '83.241.177.38:5556'...
- Successfully sent 1 certificate(s) to server.
- Handshake was completed

- Simple Client Mode:

GET / HTTP/1.1

HTTP/1.0 200 OK
Content-type: text/html


<HTML><BODY>
<CENTER><H1>This is <a href="http://www.gnu.org/software/gnutls">GNUTLS</a></H1></CENTER>


<p>Session ID: <i>40EFFAB78842BCBF9C59F3B701D0D8B718D80708EC42BCBF0100000010950908</i></p>
<h5>If your browser supports session resuming, then you should see the same session ID, when you press the <b>reload</b> button.</h5>
Ephemeral DH using prime of <b>1032</b> bits.<br>
<P>
<TABLE border=1><TR><TD>Protocol version:</TD><TD>TLS 1.2</TD></TR>
<TR><TD>Certificate Type:</TD><TD>X.509</TD></TR>
<TR><TD>Key Exchange:</TD><TD>DHE RSA</TD></TR>
<TR><TD>Compression</TD><TD>DEFLATE</TD></TR>
<TR><TD>Cipher</TD><TD>AES 256 CBC</TD></TR>
<TR><TD>MAC</TD><TD>SHA</TD></TR>
<TR><TD>Ciphersuite</TD><TD>DHE_RSA_AES_256_CBC_SHA1</TD></TR></p></TABLE>
<hr><PRE>X.509 Certificate Information:
        Version: 3
        Serial Number (hex): 4628a165
        Issuer: CN=GnuTLS test CA
        Validity:
                Not Before: Fri Apr 20 11:17:59 UTC 2007
                Not After: Wed Oct 17 11:18:02 UTC 2007
        Subject: O=Simon Josefsson,CN=Test Key
        Subject Public Key Algorithm: RSA
                Modulus (bits 1024):
                        ad:9e:08:78:73:a7:19:b0:45:58:0f:77:df:68:52:1d
                        74:c3:06:ad:d4:01:8f:e7:73:a6:2b:9b:26:90:85:bc
                        5b:f1:8c:a4:6e:44:a4:f0:c0:51:79:05:05:7e:2c:35
                        4f:fc:de:72:7f:b5:35:6f:71:8d:24:58:ee:09:a1:ba
                        1b:59:c0:64:73:50:94:f0:4f:cc:20:46:24:f3:a5:c1
                        a2:e2:80:92:9e:62:48:d3:67:91:5f:51:9e:f6:1a:fb
                        f4:0a:5d:26:7e:04:2e:15:51:a8:22:28:87:07:ca:0f
                        6e:cb:a0:58:a1:35:8b:6e:cb:9f:e0:94:a2:89:ce:31
                Exponent:
                        86:6d:78:01
        Extensions:
                Basic Constraints (critical):
                        Certificate Authority (CA): FALSE
                Key Purpose (not critical):
                        TLS WWW Client.
                        TLS WWW Server.
                Subject Alternative Name (not critical):
                        DNSname: josefsson.org
                Key Usage (critical):
                        Digital signature.
                        Key encipherment.
                Subject Key Identifier (not critical):
                        b83879aed2d2f990c21a2732e2441c056ff9f9b1
                Authority Key Identifier (not critical):
                        e93c1cfbad926ee606a4562ca2e1c05327c8f295
        Signature Algorithm: RSA-SHA
        Signature:
                86:16:40:75:4a:75:c4:dd:1b:57:cf:de:d3:c8:3c:29
                31:a4:99:18:0e:86:9b:d6:5b:6d:7c:d4:1b:8c:a3:64
                de:e1:27:64:19:7c:22:2d:70:4a:11:d8:3f:b2:27:1b
                28:c5:92:d1:62:da:5a:15:4f:90:b3:d4:15:87:00:57
                a0:c8:9e:f1:96:e2:82:f2:d9:9f:4d:28:df:37:94:83
                bb:84:56:0f:06:f0:32:79:4a:38:46:e2:df:f3:16:cc
                35:da:1d:04:32:61:6f:da:e4:4d:3a:44:54:56:82:47
                6a:8e:c7:b7:79:e3:f3:1c:f2:b4:8d:ff:13:35:b9:3e
Other Information:
        MD5 fingerprint:
                c9132f91ca88ffba4d40c420570e2986
        SHA-1 fingerprint:
                bd5f80de63034ec9e2841e6309552e345c5f226f
        Public Key Id:
                b83879aed2d2f990c21a2732e2441c056ff9f9b1
</PRE><P><PRE>
</PRE>
<hr><P>Your HTTP header was:<PRE></PRE></P>
</BODY></HTML>

- Peer has closed the GNUTLS connection
jas at mocca:~/src/gnutls-pkcs11-0.01/src$ 


From alon.barlev at gmail.com  Mon May 14 16:20:25 2007
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Mon, 14 May 2007 17:20:25 +0300
Subject: [gnutls-dev] GnuTLS PKCS#11 Engine
In-Reply-To: <87y7jr6292.wl%marcus.brinkmann@ruhr-uni-bochum.de>
References: <9e0cf0bf0705131241i637dce16t3772ed0e3528014@mail.gmail.com>
	<878xbrkjk5.fsf@mocca.josefsson.org>
	<9e0cf0bf0705140035h251f0766h5f04a604d7eeddc0@mail.gmail.com>
	<878xbriy3u.fsf@mocca.josefsson.org>
	<9e0cf0bf0705140344u684a71cdg641f115d93a1c270@mail.gmail.com>
	<87646vhcnb.fsf@mocca.josefsson.org>
	<9e0cf0bf0705140428t2c1f507ere46b9e6edc68fc09@mail.gmail.com>
	<87y7jr6292.wl%marcus.brinkmann@ruhr-uni-bochum.de>
Message-ID: <9e0cf0bf0705140720p46f36fa6pa2521fcf882dc3ae@mail.gmail.com>

Hello Marcus,

The sequence is as follows:
1. Application calls C_Initialize() of some providers.
2. Application fork()
3. Application must call C_Initialize() at child, as the spec
instructs, so child environment will be complete.
4. Application wishes to do something else in this child, so it C_Finalize()
5. Parent can access PKCS#11 token.
6. Child does not.

In your case you fork, so automatically you get C_Iniitalize(),
C_Finalize() at child, and it seems that somehow it makes the parent
not working?

Best Regards,
Alon Bar-Lev.

On 5/14/07, Marcus Brinkmann <marcus.brinkmann at ruhr-uni-bochum.de> wrote:
> At Mon, 14 May 2007 14:28:54 +0300,
> "Alon Bar-Lev" <alon.barlev at gmail.com> wrote:
> >
> > On 5/14/07, Simon Josefsson <simon at josefsson.org> wrote:
> > > I suppose this is just PKCS#11 internal stuff, and I hope you will solve
> > > it.  If I can assist in testing anything, let me know.
> >
> > This is sute problem, I cannot solved this... I CCed Marcus, I hope he
> > will be able to solve it.
>
> I am happy to help, but I need to know with what.  I am not subscribed
> to gnutls, please forward me the relevant details.
>
> From the followup mail I was CC'ed I guess it is related to threading
> and Scute's use of fork().  I realize that it could be a problem (also
> I would still like to know the particular details that bother you).
> Unfortunately, we can not limit ourselves to the gpg-agent interface,
> because we need the certificates, and those are in gpgsm's database,
> and not accessed by gpg-agent.
>
> Another idea: If gpgsm were to run as a server on a named pipe, it
> could have a call-agent passthrough interface for the gpg-agent stuff
> (similar to SCD command in gpg-agent), and then we could do everything
> over a socket.  However, we are not quite there yet to fully support
> such a model of operation, so that's more of a long-term option.
>
> Enough guessing, let's hear you now :)
>
> Thanks,
> Marcus
>
>


From alon.barlev at gmail.com  Mon May 14 16:25:20 2007
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Mon, 14 May 2007 17:25:20 +0300
Subject: [gnutls-dev] GnuTLS PKCS#11 Engine
In-Reply-To: <87wszbfx1w.fsf@mocca.josefsson.org>
References: <9e0cf0bf0705131241i637dce16t3772ed0e3528014@mail.gmail.com>
	<878xbrkjk5.fsf@mocca.josefsson.org>
	<9e0cf0bf0705140035h251f0766h5f04a604d7eeddc0@mail.gmail.com>
	<878xbriy3u.fsf@mocca.josefsson.org>
	<9e0cf0bf0705140344u684a71cdg641f115d93a1c270@mail.gmail.com>
	<87646vhcnb.fsf@mocca.josefsson.org>
	<9e0cf0bf0705140428t2c1f507ere46b9e6edc68fc09@mail.gmail.com>
	<87wszbfx1w.fsf@mocca.josefsson.org>
Message-ID: <9e0cf0bf0705140725x137f9cebu22a6de285bc9b488@mail.gmail.com>

On 5/14/07, Simon Josefsson <simon at josefsson.org> wrote:
> The license is on the source code, and by using the OpenSSL API I
> believe the FSF would consider pkcs11-helper to be a derived work from
> OpenSSL, and thus GPL-incompatible.  This would have to be confirmed
> with the FSF, though.

No... since the OpenSSL is not used in the solution with GnuTLS, it is
not derived work.

> > I don't understand...
> > The simple scute implementation is irrelevant for 99.999% of users.
>
> That may be true, but as far as I can tell, the simple scute
> implementation doesn't harm anything else, so I don't see a problem with
> it.

OK... Whatever...
1. How user can chose which API to select?
2. You need to sync the API.
3. Working PKCS#11 with only one provider is irrelevant... This is not
why PKCS#11 was introduced.


> Yes, that is the point.  Applications that wants to support external
> signing will have to do something extra.  That can link to your
> gnutls-pkcs11 library, or my scute gnutls-pkcs11 library (there appears
> to be a naming conflict here though), or something else, or even
> implement everything by itself.  It is even possible to do all at at the
> same time, if properly multiplexed by the application.  The nice
> property is that the core GnuTLS library doesn't need to know about
> this.

I don't understand your desire to push a library which is not exactly
doing anything.
Also calling yours gnutls-pkcs11 is misleading, since you really gnutls-scute...

Alon.


From alon.barlev at gmail.com  Mon May 14 17:34:59 2007
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Mon, 14 May 2007 18:34:59 +0300
Subject: [gnutls-dev] GnuTLS PKCS#11 Engine
In-Reply-To: <87sl9z5tp3.wl%marcus.brinkmann@ruhr-uni-bochum.de>
References: <9e0cf0bf0705131241i637dce16t3772ed0e3528014@mail.gmail.com>
	<878xbrkjk5.fsf@mocca.josefsson.org>
	<9e0cf0bf0705140035h251f0766h5f04a604d7eeddc0@mail.gmail.com>
	<878xbriy3u.fsf@mocca.josefsson.org>
	<9e0cf0bf0705140344u684a71cdg641f115d93a1c270@mail.gmail.com>
	<87646vhcnb.fsf@mocca.josefsson.org>
	<9e0cf0bf0705140428t2c1f507ere46b9e6edc68fc09@mail.gmail.com>
	<87y7jr6292.wl%marcus.brinkmann@ruhr-uni-bochum.de>
	<9e0cf0bf0705140720p46f36fa6pa2521fcf882dc3ae@mail.gmail.com>
	<87sl9z5tp3.wl%marcus.brinkmann@ruhr-uni-bochum.de>
Message-ID: <9e0cf0bf0705140834h7cec6603hb606c78089d8cc3c@mail.gmail.com>

On 5/14/07, Marcus Brinkmann <marcus.brinkmann at ruhr-uni-bochum.de> wrote:
> Thanks for bringing this up.  I'll let you know when I have something
> for you to try.

Thanks!


From ludo at chbouib.org  Mon May 14 17:54:20 2007
From: ludo at chbouib.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Mon, 14 May 2007 17:54:20 +0200
Subject: [gnutls-dev] [PATCH] Fixing OpenPGP keyring import (again)
References: <87lkft6l94.fsf@chbouib.org> <4646F2EE.3040505@gmx.net>
	<87ps546fvd.fsf@chbouib.org> <46472CFF.7050508@gmx.net>
	<87wszbq2lg.fsf@chbouib.org> <46482206.7010203@gmx.net>
Message-ID: <87d513o0yb.fsf@chbouib.org>

Hi,

Timo Schulz <twoaday at gmx.net> writes:

> To make sure I understand you. You try to check than an
> armored key file is correctly formatted and contains
> valid openpgp keys?

The test case I posted, `keyring.c', only checks whether a raw keyring
can be imported.  It would be nice to augment the test so that it checks
whether ASCII-armored keyrings can be imported as well (i.e., passing
`GNUTLS_OPENPGP_FMT_BASE64' to `gnutls_openpgp_keyring_import ()').

To that end, we need an ASCII-armored keyring.  I was able to create one
with GPG and to load it with `gnutls_openpgp_keyring_import ()', but I
did not managed to get GPG to show me its contents, until Werner Koch
showed how to do it.

The issue now is that "gpg --export -a < ./keyring.gpg > ./keyring.asc"
includes my own keyring (from `~/.gnupg/pubring.gpg') into its output.

Thanks,
Ludovic.



From ludo at chbouib.org  Mon May 14 18:06:15 2007
From: ludo at chbouib.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Mon, 14 May 2007 18:06:15 +0200
Subject: [gnutls-dev] [PATCH] Fixing OpenPGP keyring import (again)
References: <87lkft6l94.fsf@chbouib.org> <4646F2EE.3040505@gmx.net>
	<87ps546fvd.fsf@chbouib.org> <46472CFF.7050508@gmx.net>
	<87wszbq2lg.fsf@chbouib.org> <87odknygii.fsf@wheatstone.g10code.de>
Message-ID: <87fy5zmlu0.fsf@chbouib.org>

Hi,

Werner Koch <wk at gnupg.org> writes:

> A keyring must not be ASCII armored and using the transfer format
> directly as the keyring is not suggested for future compatibility
> reasons.

You mean future GPG versions may not be able to import/export keyrings
encoded in the raw or "ASCII armor" formats, is that correct?

> To show the content of an exported keyring, simply run
>
>   $ gpg ./t

Right, thanks!

Thanks,
Ludovic.



From ludo at chbouib.org  Mon May 14 19:20:47 2007
From: ludo at chbouib.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Mon, 14 May 2007 19:20:47 +0200
Subject: [gnutls-dev] [PATCH] Fixing OpenPGP keyring import (again)
References: <87lkft6l94.fsf@chbouib.org> <4646F2EE.3040505@gmx.net>
	<87ps546fvd.fsf@chbouib.org> <46472CFF.7050508@gmx.net>
	<87wszbq2lg.fsf@chbouib.org> <46482206.7010203@gmx.net>
	<87d513o0yb.fsf@chbouib.org>
Message-ID: <87fy5zjp8w.fsf@chbouib.org>

ludo at chbouib.org (Ludovic Court?s) writes:

> The issue now is that "gpg --export -a < ./keyring.gpg > ./keyring.asc"
> includes my own keyring (from `~/.gnupg/pubring.gpg') into its output.

I was able to work around it this way:

  $ gpg --keyring ./openpgp-keyring.gpg -a --export A7D93C3F CCC07C35 > t

(Where `openpgp-keyring.gpg' is the raw keyring we use in `keyring.c'.)

There's one last fix need for ASCII-import to work: `cdk_stream_close ()'
must not be called when `cdk_keydb_new_from_stream ()' succeeds
(patch attached).  I tested it (ASCII-import, followed by `check_id ()'
calls) from a Guile script and it does work with the patch applied
(segfaults otherwise).

BTW, you removed the repeated `if (err) { gnutls_assert () ... }' that
appeared in my patch.  I don't think this is a good idea: having
repeated `gnutls_assert ()' calls allows one to pinpoint the exact
source of a failure.

Also, please do update the `ChangeLog' file, it makes it easier to
follow what goes on.

Thanks,
Ludovic.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: ,,keyring-import-3.diff
Type: text/x-patch
Size: 702 bytes
Desc: Fix for ASCII-armored import
Url : /pipermail/attachments/20070514/6dd533a6/attachment.bin 

From alon.barlev at gmail.com  Mon May 14 21:11:38 2007
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Mon, 14 May 2007 22:11:38 +0300
Subject: [gnutls-dev] GnuTLS PKCS#11 Engine
In-Reply-To: <87sl9zfwua.fsf@mocca.josefsson.org>
References: <9e0cf0bf0705131241i637dce16t3772ed0e3528014@mail.gmail.com>
	<878xbrkjk5.fsf@mocca.josefsson.org>
	<9e0cf0bf0705140035h251f0766h5f04a604d7eeddc0@mail.gmail.com>
	<878xbriy3u.fsf@mocca.josefsson.org>
	<9e0cf0bf0705140344u684a71cdg641f115d93a1c270@mail.gmail.com>
	<87646vhcnb.fsf@mocca.josefsson.org>
	<9e0cf0bf0705140428t2c1f507ere46b9e6edc68fc09@mail.gmail.com>
	<9e0cf0bf0705140430r196a663fv3b9efacf2a20b8a@mail.gmail.com>
	<87sl9zfwua.fsf@mocca.josefsson.org>
Message-ID: <9e0cf0bf0705141211l272a5e44nb4cca207a21f4a44@mail.gmail.com>

On 5/14/07, Simon Josefsson <simon at josefsson.org> wrote:
> It works!  (The key below is on the OpenPGP smart card.)

Did it ask you for PIN in application or just see the gnupg pinentry?
(expected: pinentry only).
If you run the gpg-agent and then the test program twice, you should
be prompted by pinentry only at first run, please verify.
What happen if you remove and insert token? I hope you will be
prompted for PIN at next run.
What happen if you remove the token and run the test program? I guess
you should be prompted by application to insert your card, but maybe
pinentry will prompt you... The later will happen if scute does not
manage dynamic objects.

Thanks,
Alon.


From twoaday at gmx.net  Mon May 14 22:24:31 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Mon, 14 May 2007 22:24:31 +0200
Subject: [gnutls-dev] [PATCH] Fixing OpenPGP keyring import (again)
In-Reply-To: <87d513o0yb.fsf@chbouib.org>
References: <87lkft6l94.fsf@chbouib.org>
	<4646F2EE.3040505@gmx.net>	<87ps546fvd.fsf@chbouib.org>
	<46472CFF.7050508@gmx.net>	<87wszbq2lg.fsf@chbouib.org>
	<46482206.7010203@gmx.net> <87d513o0yb.fsf@chbouib.org>
Message-ID: <4648C57F.3080809@gmx.net>

Ludovic Court?s wrote:

> can be imported.  It would be nice to augment the test so that it checks
> whether ASCII-armored keyrings can be imported as well (i.e., passing
> `GNUTLS_OPENPGP_FMT_BASE64' to `gnutls_openpgp_keyring_import ()').

Actually we do not need an armored keyring, just a file with armored
keys. The GnuTLS openpgp support makes no real difference between
a key file and keyring. It's only important that the file contains a
sequence of openpgp packets which form a valid key {public or private}.

Because keyrings formats are not described in the openpgp message
format. It's up to the implementation to define a suitable format.
But, as Werner pointed out, transferable keys needs to follow the
openpgp format.


	Timo


From twoaday at gmx.net  Mon May 14 23:09:18 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Mon, 14 May 2007 23:09:18 +0200
Subject: [gnutls-dev] GnuTLS[W32] OpenPGP support
Message-ID: <4648CFFE.8000109@gmx.net>


Hi!

I finally managed it to run some opencdk tests on a Windows box
and it seems that the code needs to be more W32 specific fixes :-(.
In other words, I don't believe that the openpgp support is working
for the gnutls/w32 binary.

Could anybody test the w32 build with the included opencdk code?


	Timo

p.s.
But I managed to fix all memory leaks valgrind reported. Thank
again to Ludovic for reminding me of this issue.



From ametzler at downhill.at.eu.org  Tue May 15 19:15:32 2007
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Tue, 15 May 2007 19:15:32 +0200
Subject: [gnutls-dev] RFH gnutls related crash of exim4 on x86_64
	(Bug#412886)
Message-ID: <20070515171532.GB4755@downhill.g.la>


Hello,

Ronny Adsetts has been plagued by an exim4 crash in the gnutls code
when receiving mail from a specific server. - It seems like gnutls
does not like the client certificate and crashes. The complete bug
history is on <http://bugs.debian.org/412886>, featuring strace output
and a tcpdump capture.

Ronny has been able to get the following backtrace, with the segfault
happening due to null-pointer dereferencing in _gnutls_read_uint16.

I do not know how debug this efficiently, the machine in question is
a production machine and the bug only occurs on specific third party
hosts connecting.

TIA for your help. This is gnutls 1.4.x, BTW)
cu andreas

----- Forwarded message from Ronny Adsetts <ronny.adsetts at amazinginternet.com> -----
Message-ID: <46474C1C.1040207 at amazinginternet.com>
Date: Sun, 13 May 2007 18:34:20 +0100
From: Ronny Adsetts <ronny.adsetts at amazinginternet.com>
To: 412886 at bugs.debian.org, Marc Haber <mh+debian-packages at zugschlus.de>,
	Andreas Metzler <ametzler at downhill.at.eu.org>

Hi Marc/Andreas,

I've finally managed to get a core file on this segfault:

---
$ sudo gdb /usr/sbin/exim4 core
GNU gdb 6.3-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-linux"...Using host libthread_db library "/l.

Core was generated by `/usr/sbin/exim4 -bd -q30m -oX 587:465:25 -oP /var/run/ex.
Program terminated with signal 11, Segmentation fault.

[...]

#0  _gnutls_read_uint16 (data=0x0) at gnutls_num.c:120
120     gnutls_num.c: No such file or directory.
        in gnutls_num.c
(gdb) bt
#0  _gnutls_read_uint16 (data=0x0) at gnutls_num.c:120
#1  0x00002ba3e841bfc9 in _gnutls_proc_rsa_client_kx (session=0x629e10,
    data=0x0, _data_size=61) at auth_rsa.c:213
#2  0x00002ba3e84171e9 in _gnutls_recv_client_kx_message (session=0x629e10)
    at gnutls_kx.c:333
#3  0x00002ba3e8412c72 in _gnutls_handshake_server (session=0x629e10)
    at gnutls_handshake.c:2259
#4  0x00002ba3e841236b in gnutls_handshake (session=0x629e10)
    at gnutls_handshake.c:1908
#5  0x00000000004604a7 in tls_server_start (require_ciphers=0x0)
    at tls-gnu.c:838
#6  0x0000000000459339 in smtp_setup_msg () at smtp_in.c:3212
#7  0x0000000000418fc3 in handle_smtp_call (listen_sockets=0x5e3cd0,
    listen_socket_count=6, accept_socket=0, accepted=0x0) at daemon.c:495
#8  0x000000000041a55c in daemon_go () at daemon.c:1815
#9  0x000000000042848b in main (argc=7, cargv=0x0) at exim.c:3922
---

Please let me know if you want any more information.

Thanks.

Ronny
-- 
Ronny Adsetts
Technical Director
Amazing Internet Ltd, London
t: +44 20 8607 9535
f: +44 20 8607 9536
w: www.amazinginternet.com

Registered office: UK House, 82 Heath Road, Twickenham TW1 4BW
Registered in England. Company No. 4042957 
----- End forwarded message -----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : /pipermail/attachments/20070515/5e74a14c/attachment-0001.pgp 

From simon at josefsson.org  Tue May 15 21:53:24 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 15 May 2007 21:53:24 +0200
Subject: [gnutls-dev] RFH gnutls related crash of exim4 on x86_64
	(Bug#412886)
In-Reply-To: <20070515171532.GB4755@downhill.g.la> (Andreas Metzler's message
	of "Tue\, 15 May 2007 19\:15\:32 +0200")
References: <20070515171532.GB4755@downhill.g.la>
Message-ID: <87sl9xamob.fsf@mocca.josefsson.org>

Andreas Metzler <ametzler at downhill.at.eu.org> writes:

> #0  _gnutls_read_uint16 (data=0x0) at gnutls_num.c:120
> 120     gnutls_num.c: No such file or directory.
>         in gnutls_num.c
> (gdb) bt
> #0  _gnutls_read_uint16 (data=0x0) at gnutls_num.c:120
> #1  0x00002ba3e841bfc9 in _gnutls_proc_rsa_client_kx (session=0x629e10,
>     data=0x0, _data_size=61) at auth_rsa.c:213
      ^^^^^^^^^^^^^^^^^^^^^^^

Interesting, data is NULL here, as invoked from this function:

> #2  0x00002ba3e84171e9 in _gnutls_recv_client_kx_message (session=0x629e10)
>     at gnutls_kx.c:333

The function reads:

      ret =
	_gnutls_recv_handshake (session, &data,
				&datasize,
				GNUTLS_HANDSHAKE_CLIENT_KEY_EXCHANGE,
				MANDATORY_PACKET);
      if (ret < 0)
	return ret;

      ret =
	session->internals.auth_struct->
	gnutls_process_client_kx (session, data, datasize);
      gnutls_free (data);
      if (ret < 0)
	return ret;

Reading the source for _gnutls_recv_handshake, it seems to be possible
for it to return >= 0 if the code received a
GNUTLS_HANDSHAKE_CLIENT_HELLO or GNUTLS_HANDSHAKE_SERVER_HELLO packet.
I'm not 100 % certain of this though.

> #3  0x00002ba3e8412c72 in _gnutls_handshake_server (session=0x629e10)
>     at gnutls_handshake.c:2259
> #4  0x00002ba3e841236b in gnutls_handshake (session=0x629e10)
>     at gnutls_handshake.c:1908
> #5  0x00000000004604a7 in tls_server_start (require_ciphers=0x0)
>     at tls-gnu.c:838
> #6  0x0000000000459339 in smtp_setup_msg () at smtp_in.c:3212
> #7  0x0000000000418fc3 in handle_smtp_call (listen_sockets=0x5e3cd0,
>     listen_socket_count=6, accept_socket=0, accepted=0x0) at daemon.c:495
> #8  0x000000000041a55c in daemon_go () at daemon.c:1815
> #9  0x000000000042848b in main (argc=7, cargv=0x0) at exim.c:3922
> ---
>
> Please let me know if you want any more information.

If you can reproduce the crash in gdb, try getting a backtrace using 'bt
full', and invoke 'up' until you are in the _gnutls_recv_handshake stack
frame, then 'p recv_type'.  If it is indeed
GNUTLS_HANDSHAKE_CLIENT_HELLO or GNUTLS_HANDSHAKE_SERVER_HELLO then I
think we have diagnosed the cause.

It may be that the client got confused and started sending client
hello's all over, and this confused the GnuTLS state machine.  Of
course, it shouldn't be possible to crash it.

Debugging exactly why the other end sends these funny messages would be
the next step, I'm not sure that if we would fix the crash that the
hosts will be able to handshake properly.

Any chance to contact the remote host to find out what software it is
using?

/Simon


From victor at inl.fr  Wed May 16 01:06:19 2007
From: victor at inl.fr (Victor Stinner)
Date: Wed, 16 May 2007 01:06:19 +0200
Subject: [gnutls-dev] Problem with gnutls_certificate_verify_peers2()
Message-ID: <200705160106.19537.victor@inl.fr>

Hi,

I'm trying to understand how to use gnutls_certificate_verify_peers2() and how 
the function works. I think that there is a bug in x509 certificate code:

[gnutls/lib/gnutls_x509.c, near line 181]

   ret = gnutls_x509_crt_list_verify(..., status);
   ...
   if (ret < 0) { ...; return ret; }
   return 0;

[gnutls/lib/x509/verify.c, near line 784]

   int gnutls_x509_crt_list_verify(...)
   {
      *verify = _gnutls_x509_verify_certificate(...);
      return 0;
   }


_gnutls_x509_verify_certificate() return code (stored in *status) is never 
checked :-/

Problem: gnutls_certificate_verify_peers2() returns 0 even if the certificate 
is invalid :-/

Solutions:
 * Workaround: in application code: 
     * check status value: if (ret < 0 || status != 0) error!
     * NEVER use gnutls_certificate_verify_peers()
 * Fix gnutls: use status value, something like:
      if (status != 0) { gnutls_assert(); return -1; }

This bug looks to be a security bug :-/

Victor Stinner
http://www.inl.fr/


From simon at josefsson.org  Wed May 16 09:59:31 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 16 May 2007 09:59:31 +0200
Subject: [gnutls-dev] RFH gnutls related crash of exim4 on x86_64
	(Bug#412886)
In-Reply-To: <464AB359.3070408@amazinginternet.com> (Ronny Adsetts's message
	of "Wed\, 16 May 2007 08\:31\:37 +0100")
References: <20070515171532.GB4755@downhill.g.la>
	<87sl9xamob.fsf@mocca.josefsson.org>
	<464A16E5.604@amazinginternet.com>
	<441BA349-3306-4CCC-9314-F5CB03367EAE@josefsson.org>
	<464AB359.3070408@amazinginternet.com>
Message-ID: <87odkl9p24.fsf@mocca.josefsson.org>

Ronny Adsetts <ronny.adsetts at amazinginternet.com> writes:

> I have tcpdumps from a couple of earlier crashing sessions. They're attached to the Cc'd Debian bug:
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=412886;msg=15;filename=20070228_190841_crasher.pcap;att=1
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=412886;msg=20;filename=20070228_200842_crasher.pcap;att=1
>
> Hopefully that'll be helpful.

The tcpdump's are only in one direction, and ethereal can't decode it as
a SSL stream then...  It would be useful to capture both what is sent
and what is received.  Now it appears to be only what the other end is
sending.

> NB. My posts are being rejected from gnutls-dev at gnupg.org so I assume the list is subscriber only

I have added you to the whitelist.

/Simon


From victor at inl.fr  Wed May 16 10:36:56 2007
From: victor at inl.fr (Victor Stinner)
Date: Wed, 16 May 2007 10:36:56 +0200
Subject: [gnutls-dev] Problem with gnutls_certificate_verify_peers2()
In-Reply-To: <200705160106.19537.victor@inl.fr>
References: <200705160106.19537.victor@inl.fr>
Message-ID: <200705161036.57837.victor@inl.fr>

I'm still not sure that it's a bug but looks to be a problem in the 
documentation.
-----
   int gnutls_certificate_verify_peers2(
       gnutls_session_t session, unsigned int * status); 

ARGUMENTS 
   gnutls_session_t session is a gnutls session 
   unsigned int * status is the output of the verification

DESCRIPTION 
   This function will try to verify the peer's certificate and return its
   status (trusted, invalid etc.). (...)
   Returns a negative error code on error and zero on success. 
-----

What is "a success" in this case? In my mind, success means that the 
certificate is valid but it looks like I'm wrong.

Victor
-- 
Victor Stinner
http://www.inl.fr/


From simon at josefsson.org  Wed May 16 13:05:36 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 16 May 2007 13:05:36 +0200
Subject: [gnutls-dev] Problem with gnutls_certificate_verify_peers2()
In-Reply-To: <200705161036.57837.victor@inl.fr> (Victor Stinner's message of
	"Wed\, 16 May 2007 10\:36\:56 +0200")
References: <200705160106.19537.victor@inl.fr>
	<200705161036.57837.victor@inl.fr>
Message-ID: <87abw5xc3j.fsf@mocca.josefsson.org>

Victor Stinner <victor at inl.fr> writes:

> I'm still not sure that it's a bug but looks to be a problem in the 
> documentation.
> -----
>    int gnutls_certificate_verify_peers2(
>        gnutls_session_t session, unsigned int * status); 
>
> ARGUMENTS 
>    gnutls_session_t session is a gnutls session 
>    unsigned int * status is the output of the verification
>
> DESCRIPTION 
>    This function will try to verify the peer's certificate and return its
>    status (trusted, invalid etc.). (...)
>    Returns a negative error code on error and zero on success. 
> -----
>
> What is "a success" in this case? In my mind, success means that the 
> certificate is valid but it looks like I'm wrong.

A "success" is that the verification operation worked correctly, but the
_status_ of that successful verification (which can be failure) is
reported through the status output parameter.

Frankly, I find the old gnutls_certificate_verify_peers() function more
logical, but Nikos wanted to deprecated it in favor
gnutls_certificate_verify_peers2().  The use of a bitmap'ed status type
like gnutls_certificate_status_t may be problematic though (limit us to
32 different kind of failures).

Suggestions on how to improve the documentation would be appreciated.

Ideally, all the X.509 stuff should be moved to a different library.
GnuTLS's current certificate verifier fails on some chains, see the
PKITS self-tests:

http://www.mail-archive.com/help-gnutls at gnu.org/msg00581.html

/Simon


From ametzler at downhill.at.eu.org  Fri May 18 10:23:20 2007
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Fri, 18 May 2007 10:23:20 +0200
Subject: [gnutls-dev] opencdk 0.6.x - symbol versioning needs to be bumped.
Message-ID: <20070518082320.GA3771@downhill.g.la>

Hello,

Since opencdk 0.6.x introduces a new soname, the symbol versioning
info in src/libopencdk.vers needs to be bumped to stay useful.
(Otherwise a program accidentally liked against opencdk 0.5.x and
opencdk 0.6.x at runtime will crash.)

-OPENCDK_5
+OPENCDK_6

cu andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


From twoaday at gmx.net  Fri May 18 13:15:42 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Fri, 18 May 2007 13:15:42 +0200
Subject: [gnutls-dev] opencdk 0.6.x - symbol versioning needs to be
	bumped.
In-Reply-To: <20070518082320.GA3771@downhill.g.la>
References: <20070518082320.GA3771@downhill.g.la>
Message-ID: <464D8ADE.5050708@gmx.net>

Andreas Metzler wrote:

> info in src/libopencdk.vers needs to be bumped to stay useful.
> (Otherwise a program accidentally liked against opencdk 0.5.x and
> opencdk 0.6.x at runtime will crash.)
> 
> -OPENCDK_5
> +OPENCDK_6

I will change this.


Thanks,

	Timo



From christian.haene at gmx.ch  Mon May 21 10:34:56 2007
From: christian.haene at gmx.ch (Christian =?iso-8859-1?q?H=E4ne?=)
Date: Mon, 21 May 2007 10:34:56 +0200
Subject: [gnutls-dev] Gnutls for windows with microsoft compiler
Message-ID: <200705211034.56146.christian.haene@gmx.ch>

Hello

I'm trying to compile a program which includes gnutls.h under windows with 
microsoft C/C++ Compiler. But there are some errors in the gnutls.h file and 
I can't figure out the problem. This is the output I get:

Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42 for 
80x86
Copyright (C) Microsoft Corporation. ?All rights reserved.

secure_net.c
E:\GnuTLS-1.7.8\include\gnutls/gnutls.h(411) : error C2061: syntax error : 
ident
ifier 'gnutls_record_send'
E:\GnuTLS-1.7.8\include\gnutls/gnutls.h(411) : error C2059: syntax error : ';'
E:\GnuTLS-1.7.8\include\gnutls/gnutls.h(411) : error C2059: syntax 
error : 'type
'
E:\GnuTLS-1.7.8\include\gnutls/gnutls.h(412) : error C2061: syntax error : 
ident
ifier 'gnutls_record_recv'
E:\GnuTLS-1.7.8\include\gnutls/gnutls.h(412) : error C2059: syntax error : ';'
E:\GnuTLS-1.7.8\include\gnutls/gnutls.h(412) : error C2059: syntax 
error : 'type
'
E:\GnuTLS-1.7.8\include\gnutls/gnutls.h(419) : error C2061: syntax error : 
ident
ifier 'gnutls_record_set_max_size'
E:\GnuTLS-1.7.8\include\gnutls/gnutls.h(419) : error C2059: syntax error : ';'
E:\GnuTLS-1.7.8\include\gnutls/gnutls.h(419) : error C2059: syntax 
error : 'type
'
E:\GnuTLS-1.7.8\include\gnutls/gnutls.h(791) : error C2143: syntax error : 
missi
ng '{' before '*'
E:\GnuTLS-1.7.8\include\gnutls/gnutls.h(792) : error C2143: syntax error : 
missi
ng ')' before '*'
E:\GnuTLS-1.7.8\include\gnutls/gnutls.h(792) : error C2143: syntax error : 
missi
ng '{' before '*'
E:\GnuTLS-1.7.8\include\gnutls/gnutls.h(792) : error C2059: syntax error : ')'
E:\GnuTLS-1.7.8\include\gnutls/gnutls.h(808) : error C2146: syntax error : 
missi
ng ')' before identifier 'push_func'
E:\GnuTLS-1.7.8\include\gnutls/gnutls.h(808) : error 
C2081: 'gnutls_push_func' :
?name in formal parameter list illegal
E:\GnuTLS-1.7.8\include\gnutls/gnutls.h(808) : error C2061: syntax error : 
ident
ifier 'push_func'
E:\GnuTLS-1.7.8\include\gnutls/gnutls.h(808) : error C2059: syntax error : ';'
E:\GnuTLS-1.7.8\include\gnutls/gnutls.h(808) : error C2059: syntax error : ')'
E:\GnuTLS-1.7.8\include\gnutls/gnutls.h(810) : error C2146: syntax error : 
missi
ng ')' before identifier 'pull_func'
E:\GnuTLS-1.7.8\include\gnutls/gnutls.h(810) : error 
C2081: 'gnutls_pull_func' :
?name in formal parameter list illegal
E:\GnuTLS-1.7.8\include\gnutls/gnutls.h(810) : error C2061: syntax error : 
ident
ifier 'pull_func'
E:\GnuTLS-1.7.8\include\gnutls/gnutls.h(810) : error C2059: syntax error : ';'
E:\GnuTLS-1.7.8\include\gnutls/gnutls.h(810) : error C2059: syntax error : ')'



From ludovic.courtes at laas.fr  Mon May 21 15:04:22 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Mon, 21 May 2007 15:04:22 +0200
Subject: [gnutls-dev] [PATCH] Fixing OpenPGP keyring import (again)
References: <87lkft6l94.fsf@chbouib.org> <4646F2EE.3040505@gmx.net>
	<87ps546fvd.fsf@chbouib.org> <46472CFF.7050508@gmx.net>
	<87wszbq2lg.fsf@chbouib.org> <46482206.7010203@gmx.net>
	<87d513o0yb.fsf@chbouib.org> <87fy5zjp8w.fsf@chbouib.org>
Message-ID: <873b1qxr8p.fsf@laas.fr>

Hi,

ludo at chbouib.org (Ludovic Court?s) writes:

> There's one last fix need for ASCII-import to work: `cdk_stream_close ()'
> must not be called when `cdk_keydb_new_from_stream ()' succeeds
> (patch attached).

s/need/needed/

Can you make sure this patch is applied?

Thanks in advance,
Ludovic.



From ludovic.courtes at laas.fr  Mon May 21 15:06:30 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Mon, 21 May 2007 15:06:30 +0200
Subject: [gnutls-dev] Porting bug fixes to 1.6.x
Message-ID: <87lkfiwckp.fsf@laas.fr>

Hi,

Is there a plan to "back-port" the (OpenPGP-related) bug fixes in HEAD
into the 1.6 branch?  (Especially those that do not require the latest
OpenCDK.)

Thanks,
Ludovic.



From simon at josefsson.org  Mon May 21 18:36:34 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 21 May 2007 18:36:34 +0200
Subject: [gnutls-dev] Gnutls for windows with microsoft compiler
In-Reply-To: <200705211034.56146.christian.haene@gmx.ch> ("Christian
	=?iso-8859-1?Q?H=E4ne=22's?=
	message of "Mon\, 21 May 2007 10\:34\:56 +0200")
References: <200705211034.56146.christian.haene@gmx.ch>
Message-ID: <877ir22kx9.fsf@mocca.josefsson.org>

Christian H?ne <christian.haene at gmx.ch> writes:

> Hello
>
> I'm trying to compile a program which includes gnutls.h under windows with 
> microsoft C/C++ Compiler. But there are some errors in the gnutls.h file and 
> I can't figure out the problem. This is the output I get:
>
> Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42 for 
> 80x86
> Copyright (C) Microsoft Corporation. ?All rights reserved.
>
> secure_net.c
> E:\GnuTLS-1.7.8\include\gnutls/gnutls.h(411) : error C2061: syntax error : 
> ident
> ifier 'gnutls_record_send'

You need to define 'ssize_t' somehow.  For example, build using
'./configure CFLAGS=-Dssize_t=long'.

/Simon


From twoaday at gmx.net  Mon May 21 20:46:46 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Mon, 21 May 2007 20:46:46 +0200
Subject: [gnutls-dev] [PATCH] Fixing OpenPGP keyring import (again)
In-Reply-To: <873b1qxr8p.fsf@laas.fr>
References: <87lkft6l94.fsf@chbouib.org>
	<4646F2EE.3040505@gmx.net>	<87ps546fvd.fsf@chbouib.org>
	<46472CFF.7050508@gmx.net>	<87wszbq2lg.fsf@chbouib.org>
	<46482206.7010203@gmx.net>	<87d513o0yb.fsf@chbouib.org>
	<87fy5zjp8w.fsf@chbouib.org> <873b1qxr8p.fsf@laas.fr>
Message-ID: <4651E916.7040906@gmx.net>

Ludovic Court?s wrote:

> Can you make sure this patch is applied?

Yes, I will apply the patch. I wonder why
my test with the new code, I slightly modified
your patch, did not provoke this error!?


	Timo



From twoaday at gmx.net  Mon May 21 21:01:59 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Mon, 21 May 2007 21:01:59 +0200
Subject: [gnutls-dev] [PATCH] Fixing OpenPGP keyring import (again)
In-Reply-To: <873b1qxr8p.fsf@laas.fr>
References: <87lkft6l94.fsf@chbouib.org>
	<4646F2EE.3040505@gmx.net>	<87ps546fvd.fsf@chbouib.org>
	<46472CFF.7050508@gmx.net>	<87wszbq2lg.fsf@chbouib.org>
	<46482206.7010203@gmx.net>	<87d513o0yb.fsf@chbouib.org>
	<87fy5zjp8w.fsf@chbouib.org> <873b1qxr8p.fsf@laas.fr>
Message-ID: <4651ECA7.5000507@gmx.net>

Ludovic Court?s wrote:

> Can you make sure this patch is applied?

I applied the patch, but I still have a little problem.

For my tests I use:

./gnutls-cli --pgpkeyfile openpgp/cli_sec.asc \
 --pgpkeyring openpgp/cli_ring.asc \
 --pgpcertfile openpgp/cli_pub.asc --port 5556 test.gnutls.org

(I generated the "cli_ring.asc" file with
 cp cli_ring.gpg /tmp
 gpg --homedir . --no-options --no-emit-version \
     --keyring cli_ring.gpg -a --export > cli_ring.asc
)

But I'm a little confused because the import
code, with the armor flag, is never called.
That's why I also did not detect the problem the first
time. Did I forget to set an option to assure the code
will be used?


	Timo


From twoaday at gmx.net  Mon May 21 21:17:45 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Mon, 21 May 2007 21:17:45 +0200
Subject: [gnutls-dev] [PATCH] Fixing OpenPGP keyring import (again)
In-Reply-To: <873b1qxr8p.fsf@laas.fr>
References: <87lkft6l94.fsf@chbouib.org>
	<4646F2EE.3040505@gmx.net>	<87ps546fvd.fsf@chbouib.org>
	<46472CFF.7050508@gmx.net>	<87wszbq2lg.fsf@chbouib.org>
	<46482206.7010203@gmx.net>	<87d513o0yb.fsf@chbouib.org>
	<87fy5zjp8w.fsf@chbouib.org> <873b1qxr8p.fsf@laas.fr>
Message-ID: <4651F059.4050800@gmx.net>

Ludovic Court?s wrote:

> Can you make sure this patch is applied?

Actually the function code also contains another error.
Due to the nature of cdk_keydb_new_from_stream(),
the function do not close the stream at the end, cdk_keydb_close(),
itself, so we need to store it separately and close it
later.

I already modified the code but I still need to test it.


	Timo


From twoaday at gmx.net  Mon May 21 21:55:02 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Mon, 21 May 2007 21:55:02 +0200
Subject: [gnutls-dev] [PATCH] Fixing OpenPGP keyring import (again)
In-Reply-To: <873b1qxr8p.fsf@laas.fr>
References: <87lkft6l94.fsf@chbouib.org>
	<4646F2EE.3040505@gmx.net>	<87ps546fvd.fsf@chbouib.org>
	<46472CFF.7050508@gmx.net>	<87wszbq2lg.fsf@chbouib.org>
	<46482206.7010203@gmx.net>	<87d513o0yb.fsf@chbouib.org>
	<87fy5zjp8w.fsf@chbouib.org> <873b1qxr8p.fsf@laas.fr>
Message-ID: <4651F916.3070007@gmx.net>

Ludovic Court?s wrote:

> Can you make sure this patch is applied?

Sorry for the unnecessary mails, I accidentally
have overwritten my test script and the --ctypes OPENPGP
flag were missing then.

Again I'm sorry, now it works again.


	Timo



From ludovic.courtes at laas.fr  Tue May 22 09:46:53 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Tue, 22 May 2007 09:46:53 +0200
Subject: [gnutls-dev] [PATCH] Fixing OpenPGP keyring import (again)
References: <87lkft6l94.fsf@chbouib.org> <4646F2EE.3040505@gmx.net>
	<87ps546fvd.fsf@chbouib.org> <46472CFF.7050508@gmx.net>
	<87wszbq2lg.fsf@chbouib.org> <46482206.7010203@gmx.net>
	<87d513o0yb.fsf@chbouib.org> <87fy5zjp8w.fsf@chbouib.org>
	<873b1qxr8p.fsf@laas.fr> <4651F059.4050800@gmx.net>
Message-ID: <87k5v1qp02.fsf@laas.fr>

Hi,

Timo Schulz <twoaday at gmx.net> writes:

> Actually the function code also contains another error.
> Due to the nature of cdk_keydb_new_from_stream(),
> the function do not close the stream at the end, cdk_keydb_close(),
> itself, so we need to store it separately and close it
> later.

Hmm, good point!

There's still something wrong with what you checked in, though:

  err = cdk_stream_tmp_from_mem (data->data, data->size, &input);
  if (!err)
    err = cdk_stream_set_armor_flag (input, 0);
  if (!err)
    err = cdk_keydb_new_from_stream (&keyring->db, 0, input);  
  if (err)
    {
      cdk_stream_close (input);
      gnutls_assert ();
    }

That won't work if `cdk_stream_tmp_from_mem ()' returns an error.

How about ChangeLog entries BTW?

> I already modified the code but I still need to test it.

Please, run the tests in Guile-GnuTLS 0.1 [*].  You need Guile 1.8 and
then run "make check".

I'm currently unable to compile GnuTLS from HEAD because of something
fishy going on with Gnulib:

  $ make CFLAGS='-g -Wall' -j2
  make: *** No rule to make target `gl/m4/getpass.m4', needed by `Makefile.in'.  Stop.

  $ find -name getpass.m4
  ./lgl/m4/getpass.m4

  $ grep -r getpass gl/
  gl/Makefile:# Reproduce by: gnulib-tool --import --dir=. --local-dir=gl/override --lib=libgnu --source-base=gl --m4-base=gl/m4 --doc-base=doc --aux-dir=. --avoid=snprintf --avoid=vasnprintf --makefile-name=gnulib.mk --libtool --macro-prefix=gl arpa_inet fdl gendocs getaddrinfo getline getpass gpl inet_ntop inet_pton lgpl maintainer-makefile readline
  gl/Makefile:    $(top_srcdir)/gl/m4/getpass.m4 \
  gl/Makefile:    getdelim.h getline.c getline.h getpass.c getpass.h inet_ntop.c \
  gl/Makefile:    getline.c getpass.c inet_ntop.c inet_pton.c readline.c \
  gl/Makefile:include ./$(DEPDIR)/getpass.Plo
  gl/Makefile.in: $(top_srcdir)/lgl/m4/getpass.m4 \

So, for some reason, the generated `Makefile' gets the path to
`getpass.m4' wrong, although `Makefile.in' has the right one.

Running `autoreconf', `automake' or `gnulib-tool --update' doesn't
help.  Any idea?

Thanks,
Ludovic.

[*] http://www.laas.fr/~lcourtes/software/guile/guile-gnutls-0.1.tar.gz



From twoaday at gmx.net  Tue May 22 11:44:25 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Tue, 22 May 2007 11:44:25 +0200
Subject: [gnutls-dev] [PATCH] Fixing OpenPGP keyring import (again)
In-Reply-To: <87k5v1qp02.fsf@laas.fr>
References: <87lkft6l94.fsf@chbouib.org>
	<4646F2EE.3040505@gmx.net>	<87ps546fvd.fsf@chbouib.org>
	<46472CFF.7050508@gmx.net>	<87wszbq2lg.fsf@chbouib.org>
	<46482206.7010203@gmx.net>	<87d513o0yb.fsf@chbouib.org>
	<87fy5zjp8w.fsf@chbouib.org>	<873b1qxr8p.fsf@laas.fr>
	<4651F059.4050800@gmx.net> <87k5v1qp02.fsf@laas.fr>
Message-ID: <4652BB79.4060408@gmx.net>

Ludovic Courtes wrote:

Hi,

>   err = cdk_stream_tmp_from_mem (data->data, data->size, &input);
>   if (!err)
>     err = cdk_stream_set_armor_flag (input, 0);
>   if (!err)
>     err = cdk_keydb_new_from_stream (&keyring->db, 0, input);  
>   if (err)
>     {
>       cdk_stream_close (input);
>       gnutls_assert ();
>     }
> 
> That won't work if `cdk_stream_tmp_from_mem ()' returns an error.

Why? input is set to NULL in the function and thus cdk_stream_close
does nothing because the param is NULL.


> How about ChangeLog entries BTW?

IMHO the ChangeLog entries are generated from the CVS commit logs.


	Timo


From simon at josefsson.org  Tue May 22 12:21:00 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 22 May 2007 12:21:00 +0200
Subject: [gnutls-dev] Porting bug fixes to 1.6.x
In-Reply-To: <87lkfiwckp.fsf@laas.fr> ("Ludovic =?iso-8859-1?Q?Court=E8s?=
	=?iso-8859-1?Q?=22's?= message of "Mon\, 21
	May 2007 15\:06\:30 +0200")
References: <87lkfiwckp.fsf@laas.fr>
Message-ID: <87fy5pb1mb.fsf@mocca.josefsson.org>

ludovic.courtes at laas.fr (Ludovic Court?s) writes:

> Hi,
>
> Is there a plan to "back-port" the (OpenPGP-related) bug fixes in HEAD
> into the 1.6 branch?  (Especially those that do not require the latest
> OpenCDK.)

Hi!  If you can provide a patch, I'll review it and integrate it.  We
could do a 1.6.x release quickly based on it.

/Simon


From simon at josefsson.org  Tue May 22 12:23:08 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 22 May 2007 12:23:08 +0200
Subject: [gnutls-dev] [PATCH] Fixing OpenPGP keyring import (again)
In-Reply-To: <87k5v1qp02.fsf@laas.fr> ("Ludovic =?iso-8859-1?Q?Court=E8s?=
	=?iso-8859-1?Q?=22's?= message of "Tue\, 22
	May 2007 09\:46\:53 +0200")
References: <87lkft6l94.fsf@chbouib.org> <4646F2EE.3040505@gmx.net>
	<87ps546fvd.fsf@chbouib.org> <46472CFF.7050508@gmx.net>
	<87wszbq2lg.fsf@chbouib.org> <46482206.7010203@gmx.net>
	<87d513o0yb.fsf@chbouib.org> <87fy5zjp8w.fsf@chbouib.org>
	<873b1qxr8p.fsf@laas.fr> <4651F059.4050800@gmx.net>
	<87k5v1qp02.fsf@laas.fr>
Message-ID: <87bqgdb1ir.fsf@mocca.josefsson.org>

ludovic.courtes at laas.fr (Ludovic Court?s) writes:

> I'm currently unable to compile GnuTLS from HEAD because of something
> fishy going on with Gnulib:
>
>   $ make CFLAGS='-g -Wall' -j2
>   make: *** No rule to make target `gl/m4/getpass.m4', needed by `Makefile.in'.  Stop.
>
>   $ find -name getpass.m4
>   ./lgl/m4/getpass.m4
>
>   $ grep -r getpass gl/
>   gl/Makefile:# Reproduce by: gnulib-tool --import --dir=. --local-dir=gl/override --lib=libgnu --source-base=gl --m4-base=gl/m4 --doc-base=doc --aux-dir=. --avoid=snprintf --avoid=vasnprintf --makefile-name=gnulib.mk --libtool --macro-prefix=gl arpa_inet fdl gendocs getaddrinfo getline getpass gpl inet_ntop inet_pton lgpl maintainer-makefile readline
>   gl/Makefile:    $(top_srcdir)/gl/m4/getpass.m4 \
>   gl/Makefile:    getdelim.h getline.c getline.h getpass.c getpass.h inet_ntop.c \
>   gl/Makefile:    getline.c getpass.c inet_ntop.c inet_pton.c readline.c \
>   gl/Makefile:include ./$(DEPDIR)/getpass.Plo
>   gl/Makefile.in: $(top_srcdir)/lgl/m4/getpass.m4 \
>
> So, for some reason, the generated `Makefile' gets the path to
> `getpass.m4' wrong, although `Makefile.in' has the right one.
>
> Running `autoreconf', `automake' or `gnulib-tool --update' doesn't
> help.  Any idea?

I think 'autoreconf -fvi' should help.  You could try 'cvsco' from
cvs-utils too, it cleans up everything to get a fresh checkout.

/Simon


From ludovic.courtes at laas.fr  Tue May 22 13:31:38 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Tue, 22 May 2007 13:31:38 +0200
Subject: [gnutls-dev] [PATCH] Fixing OpenPGP keyring import (again)
References: <87lkft6l94.fsf@chbouib.org> <4646F2EE.3040505@gmx.net>
	<87ps546fvd.fsf@chbouib.org> <46472CFF.7050508@gmx.net>
	<87wszbq2lg.fsf@chbouib.org> <46482206.7010203@gmx.net>
	<87d513o0yb.fsf@chbouib.org> <87fy5zjp8w.fsf@chbouib.org>
	<873b1qxr8p.fsf@laas.fr> <4651F059.4050800@gmx.net>
	<87k5v1qp02.fsf@laas.fr> <4652BB79.4060408@gmx.net>
Message-ID: <87odkdksbp.fsf@laas.fr>

Hi,

Timo Schulz <twoaday at gmx.net> writes:

> Ludovic Courtes wrote:

>>   err = cdk_stream_tmp_from_mem (data->data, data->size, &input);
>>   if (!err)
>>     err = cdk_stream_set_armor_flag (input, 0);
>>   if (!err)
>>     err = cdk_keydb_new_from_stream (&keyring->db, 0, input);  
>>   if (err)
>>     {
>>       cdk_stream_close (input);
>>       gnutls_assert ();
>>     }
>> 
>> That won't work if `cdk_stream_tmp_from_mem ()' returns an error.
>
> Why? input is set to NULL in the function and thus cdk_stream_close
> does nothing because the param is NULL.

`cdk_keydb_new_from_stream ()' does not always initialize INPUT to NULL
on error, at least not in the OpenCDK currently available in HEAD:

  cdk_error_t 
  cdk_keydb_new_from_stream (cdk_keydb_hd_t *r_hd, int secret,
                             cdk_stream_t in)
  {
    cdk_keydb_hd_t hd;

    if (!r_hd)
      return CDK_Inv_Value;
    
And `cdk_stream_close ()' returns an error if STREAM is NULL:

  cdk_error_t
  cdk_stream_close (cdk_stream_t s)
  {
    struct stream_filter_s *f, *f2;
    cdk_error_t rc;

    if (!s)
      return CDK_Inv_Value;

Well, we don't check its return value...

> IMHO the ChangeLog entries are generated from the CVS commit logs.

It turns out that they are not automatically generated.

Thanks,
Ludovic.



From twoaday at gmx.net  Tue May 22 13:52:06 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Tue, 22 May 2007 13:52:06 +0200
Subject: [gnutls-dev] [PATCH] Fixing OpenPGP keyring import (again)
In-Reply-To: <87odkdksbp.fsf@laas.fr>
References: <87lkft6l94.fsf@chbouib.org>
	<4646F2EE.3040505@gmx.net>	<87ps546fvd.fsf@chbouib.org>
	<46472CFF.7050508@gmx.net>	<87wszbq2lg.fsf@chbouib.org>
	<46482206.7010203@gmx.net>	<87d513o0yb.fsf@chbouib.org>
	<87fy5zjp8w.fsf@chbouib.org>	<873b1qxr8p.fsf@laas.fr>
	<4651F059.4050800@gmx.net>	<87k5v1qp02.fsf@laas.fr>
	<4652BB79.4060408@gmx.net> <87odkdksbp.fsf@laas.fr>
Message-ID: <4652D966.9020103@gmx.net>

Ludovic Courtes wrote:

>>>   err = cdk_stream_tmp_from_mem (data->data, data->size, &input);
>>>   if (!err)
>>>     err = cdk_stream_set_armor_flag (input, 0);
>>>   if (!err)
>>>     err = cdk_keydb_new_from_stream (&keyring->db, 0, input);  

if cdk_stream_tmp_from_mem returns != 0 the
"if (!err)" expression fails and the keydb function is not called.


> `cdk_keydb_new_from_stream ()' does not always initialize INPUT to NULL
> on error, at least not in the OpenCDK currently available in HEAD:

That's right, but with the current code cdk_keydb_new_from_stream is
never called. It would be only called if there is _no_ error!


> And `cdk_stream_close ()' returns an error if STREAM is NULL:
[snip]
> Well, we don't check its return value...

The patch is not very elegant, it works but I guess I shall
cleanup it up.


Thanks,

	Timo



From ludovic.courtes at laas.fr  Wed May 23 19:00:50 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Wed, 23 May 2007 19:00:50 +0200
Subject: [gnutls-dev] Porting bug fixes to 1.6.x
References: <87lkfiwckp.fsf@laas.fr> <87fy5pb1mb.fsf@mocca.josefsson.org>
Message-ID: <87d50r5vb1.fsf@laas.fr>

Hi,

Simon Josefsson <simon at josefsson.org> writes:

> Hi!  If you can provide a patch, I'll review it and integrate it.  We
> could do a 1.6.x release quickly based on it.

I've done a quick review of past patches.  Here's what should be
applicable (since most of the messages contain individual patches and a
description of the problem, I thought they might be easier to review
than a single big patch):

  * raw OpenPGP keyring import (doesn't address ASCII import since this
    requires the recent additions in OpenCDK)

    http://article.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/1873

  * trivial bug in `gnutls_certificate_set_openpgp_key ()'

    http://article.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/1858

  * TLS 1.2 RSA/DSA signature verification bug

    http://article.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/1760

  * TLS 1.2 handshake bug

    http://article.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/1749

  * off-by-one in `gnutls_openpgp.c'

    http://article.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/1669

  * small OpenPGP API inconsistencies

    http://article.gmane.org/gmane.network.gnutls.general/591


Unfortunately, an interesting bug fix may not be applicable due to
API/ABI-breaking issues (although it is unclear whether there really is
a problem since only internal functions are changed):

  * allow import of ASCII-armored OpenPGP private keys

    http://article.gmane.org/gmane.network.gnutls.general/617
    http://article.gmane.org/gmane.network.gnutls.general/645
    http://article.gmane.org/gmane.network.gnutls.general/657


Let me know if I can help better.

BTW, is the Git-on-Savannah project suspended for now?

Thanks,
Ludovic.



From simon at josefsson.org  Fri May 25 14:36:26 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 25 May 2007 14:36:26 +0200
Subject: [gnutls-dev] Porting bug fixes to 1.6.x
In-Reply-To: <87d50r5vb1.fsf@laas.fr> ("Ludovic =?iso-8859-1?Q?Court=E8s?=
	=?iso-8859-1?Q?=22's?= message of "Wed\, 23
	May 2007 19\:00\:50 +0200")
References: <87lkfiwckp.fsf@laas.fr> <87fy5pb1mb.fsf@mocca.josefsson.org>
	<87d50r5vb1.fsf@laas.fr>
Message-ID: <87646hw051.fsf@mocca.josefsson.org>

ludovic.courtes at laas.fr (Ludovic Court?s) writes:

> Hi,
>
> Simon Josefsson <simon at josefsson.org> writes:
>
>> Hi!  If you can provide a patch, I'll review it and integrate it.  We
>> could do a 1.6.x release quickly based on it.
>
> I've done a quick review of past patches.  Here's what should be
> applicable (since most of the messages contain individual patches and a
> description of the problem, I thought they might be easier to review
> than a single big patch):
>
>   * raw OpenPGP keyring import (doesn't address ASCII import since this
>     requires the recent additions in OpenCDK)
>
>     http://article.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/1873
>
>   * trivial bug in `gnutls_certificate_set_openpgp_key ()'
>
>     http://article.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/1858

These two looks fine.

>   * TLS 1.2 RSA/DSA signature verification bug
>
>     http://article.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/1760
>
>   * TLS 1.2 handshake bug
>
>     http://article.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/1749

1.6.x doesn't support TLS 1.2, so these doesn't matter, right?

>   * off-by-one in `gnutls_openpgp.c'
>
>     http://article.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/1669
>
>   * small OpenPGP API inconsistencies
>
>     http://article.gmane.org/gmane.network.gnutls.general/591

These seems fine too.

> Unfortunately, an interesting bug fix may not be applicable due to
> API/ABI-breaking issues (although it is unclear whether there really is
> a problem since only internal functions are changed):
>
>   * allow import of ASCII-armored OpenPGP private keys
>
>     http://article.gmane.org/gmane.network.gnutls.general/617
>     http://article.gmane.org/gmane.network.gnutls.general/645
>     http://article.gmane.org/gmane.network.gnutls.general/657

This one seems too big...  I think we could start pre-testing of 1.7.x
targetting a stable 1.8.0 soon instead.

> Let me know if I can help better.

Thanks for compiling things separately, very useful!

> BTW, is the Git-on-Savannah project suspended for now?

It didn't work out with Savannah for now (they don't want to mirror
other git repositories), but I'm working on getting a mirror up at
repo.or.cz now.

/Simon


From simon at josefsson.org  Fri May 25 15:03:44 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 25 May 2007 15:03:44 +0200
Subject: [gnutls-dev] Git mirror of CVS repository
Message-ID: <87y7jdukb3.fsf@mocca.josefsson.org>

There is now a Git mirror of the GnuTLS CVS repository:

http://repo.or.cz/w/gnutls.git

I'll see if I can release a new 1.7.x release from it now.

/Simon


From ludovic.courtes at laas.fr  Fri May 25 15:08:33 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Fri, 25 May 2007 15:08:33 +0200
Subject: [gnutls-dev] Porting bug fixes to 1.6.x
References: <87lkfiwckp.fsf@laas.fr> <87fy5pb1mb.fsf@mocca.josefsson.org>
	<87d50r5vb1.fsf@laas.fr> <87646hw051.fsf@mocca.josefsson.org>
Message-ID: <87r6p5capa.fsf@laas.fr>

Hi Simon,

Simon Josefsson <simon at josefsson.org> writes:

>>   * TLS 1.2 RSA/DSA signature verification bug
>>
>>     http://article.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/1760
>>
>>   * TLS 1.2 handshake bug
>>
>>     http://article.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/1749
>
> 1.6.x doesn't support TLS 1.2, so these doesn't matter, right?

Oh, right.

>> Unfortunately, an interesting bug fix may not be applicable due to
>> API/ABI-breaking issues (although it is unclear whether there really is
>> a problem since only internal functions are changed):
>>
>>   * allow import of ASCII-armored OpenPGP private keys
>>
>>     http://article.gmane.org/gmane.network.gnutls.general/617
>>     http://article.gmane.org/gmane.network.gnutls.general/645
>>     http://article.gmane.org/gmane.network.gnutls.general/657
>
> This one seems too big...  I think we could start pre-testing of 1.7.x
> targetting a stable 1.8.0 soon instead.

Yeah, if you think time has come, then that would be easier.

> It didn't work out with Savannah for now (they don't want to mirror
> other git repositories), but I'm working on getting a mirror up at
> repo.or.cz now.

Alright.

I'd like to have the Guile bindings integrated by the time you release
1.8.  So I'll start the integration work from your Git repository when
it's available.

Thanks!

Ludovic.



From simon at josefsson.org  Fri May 25 15:21:52 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 25 May 2007 15:21:52 +0200
Subject: [gnutls-dev] Libtasn1 0.3.10
Message-ID: <87tzu1ujgv.fsf@mocca.josefsson.org>

A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 419 bytes
Desc: not available
Url : /pipermail/attachments/20070525/50558e57/attachment.pgp 

From simon at josefsson.org  Fri May 25 16:54:11 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 25 May 2007 16:54:11 +0200
Subject: [gnutls-dev] GnuTLS 1.7.10
Message-ID: <87abvtuf70.fsf@mocca.josefsson.org>

A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 419 bytes
Desc: not available
Url : /pipermail/attachments/20070525/2cc4294a/attachment.pgp 

From novel at FreeBSD.org  Fri May 25 19:46:24 2007
From: novel at FreeBSD.org (Roman Bogorodskiy)
Date: Fri, 25 May 2007 21:46:24 +0400
Subject: [gnutls-dev] GnuTLS 1.7.10
In-Reply-To: <87abvtuf70.fsf@mocca.josefsson.org>
References: <87abvtuf70.fsf@mocca.josefsson.org>
Message-ID: <20070525174624.GA889@underworld.novel.ru>

  Simon Josefsson wrote:

[..]
> * Version 1.7.10 (released 2007-05-25)
[..]

It seems you forgot to add opencdk.h file to the distfile.

novel at underworld:~/ports_stuff/gnutls-devel/work/gnutls-1.7.10 %> find . -name opencdk.h
novel at underworld:~/ports_stuff/gnutls-devel/work/gnutls-1.7.10 %> 

In previous releases this file were located at 
/libextra/opencdk/opencdk.h.

Roman Bogorodskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 305 bytes
Desc: not available
Url : /pipermail/attachments/20070525/1d37d704/attachment-0001.pgp 

From twoaday at gmx.net  Sat May 26 16:01:57 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Sat, 26 May 2007 16:01:57 +0200
Subject: [gnutls-dev] GnuTLS 1.7.10
In-Reply-To: <20070525174624.GA889@underworld.novel.ru>
References: <87abvtuf70.fsf@mocca.josefsson.org>
	<20070525174624.GA889@underworld.novel.ru>
Message-ID: <46583DD5.4060805@gmx.net>

Roman Bogorodskiy wrote:

> It seems you forgot to add opencdk.h file to the distfile.
> 
> novel at underworld:~/ports_stuff/gnutls-devel/work/gnutls-1.7.10 %> find . -name opencdk.h
> novel at underworld:~/ports_stuff/gnutls-devel/work/gnutls-1.7.10 %> 
> 
> In previous releases this file were located at 
> /libextra/opencdk/opencdk.h.

This file is now generated from the template file opencdk.h.in.


	Timo


From novel at FreeBSD.org  Sat May 26 16:41:55 2007
From: novel at FreeBSD.org (Roman Bogorodskiy)
Date: Sat, 26 May 2007 18:41:55 +0400
Subject: [gnutls-dev] GnuTLS 1.7.10
In-Reply-To: <46583DD5.4060805@gmx.net>
References: <87abvtuf70.fsf@mocca.josefsson.org>
	<20070525174624.GA889@underworld.novel.ru>
	<46583DD5.4060805@gmx.net>
Message-ID: <20070526144155.GA1429@underworld.novel.ru>

  Timo Schulz wrote:

> Roman Bogorodskiy wrote:
> 
> > It seems you forgot to add opencdk.h file to the distfile.
> > 
> > novel at underworld:~/ports_stuff/gnutls-devel/work/gnutls-1.7.10 %> find . -name opencdk.h
> > novel at underworld:~/ports_stuff/gnutls-devel/work/gnutls-1.7.10 %> 
> > 
> > In previous releases this file were located at 
> > /libextra/opencdk/opencdk.h.
> 
> This file is now generated from the template file opencdk.h.in.

I can't find it either.

novel at underworld:~/gnutls-1.7.10 %> find . -name "opencdk.h*"
novel at underworld:~/gnutls-1.7.10 %>

Maybe I'm missing something obvious? But gnutls 1.7.10 doesn't build
anyway, because of the missing opencdk.h.

Roman Bogorodskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 305 bytes
Desc: not available
Url : /pipermail/attachments/20070526/81d850b3/attachment.pgp 

From simon at josefsson.org  Sat May 26 17:43:09 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Sat, 26 May 2007 17:43:09 +0200
Subject: [gnutls-dev] GnuTLS 1.7.10
In-Reply-To: <20070525174624.GA889@underworld.novel.ru> (Roman Bogorodskiy's
	message of "Fri, 25 May 2007 21:46:24 +0400")
References: <87abvtuf70.fsf@mocca.josefsson.org>
	<20070525174624.GA889@underworld.novel.ru>
Message-ID: <87r6p3egky.fsf@mocca.josefsson.org>

Roman Bogorodskiy <novel at FreeBSD.org> writes:

>   Simon Josefsson wrote:
>
> [..]
>> * Version 1.7.10 (released 2007-05-25)
> [..]
>
> It seems you forgot to add opencdk.h file to the distfile.
>
> novel at underworld:~/ports_stuff/gnutls-devel/work/gnutls-1.7.10 %> find . -name opencdk.h
> novel at underworld:~/ports_stuff/gnutls-devel/work/gnutls-1.7.10 %> 
>
> In previous releases this file were located at 
> /libextra/opencdk/opencdk.h.

Thanks for the report, I'll release 1.7.11 shortly to fix this.

/Simon


From simon at josefsson.org  Sat May 26 18:24:56 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Sat, 26 May 2007 18:24:56 +0200
Subject: [gnutls-dev] GnuTLS 1.7.11
Message-ID: <87hcpzeenb.fsf@mocca.josefsson.org>

A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 419 bytes
Desc: not available
Url : /pipermail/attachments/20070526/603d8459/attachment.pgp 

From simon at josefsson.org  Sat May 26 18:56:50 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Sat, 26 May 2007 18:56:50 +0200
Subject: [gnutls-dev] Things to do before next stable release?
Message-ID: <87bqg7ed65.fsf@mocca.josefsson.org>

I think 1.7.x now contains a lot of stuff that we should release as a
stable release, for example:

* TLS 1.2 support (although protocol not finalized in the IETF yet).

* Proxy certificate support.

* Signing using RSA-SHA256/384/512.

* New APIs to print textual representation of certificates.

* Support for 'otherName' SAN.

* Support for supplemental data (RFC 4680).

* Support for tls-authz.

* New APIs to iterate through supported algorithms.

Plus many, many bug fixes and other improvements of existing code.

Initially I wanted to wait for TLS 1.2 to stabilize until we would
release 1.8.0, although that seems to take longer than expected.

I think we could release 1.8.0 as-is, with TLS 1.2 disabled as a default
protocol, and with a release note saying that the TLS 1.2 stuff is
subject to change incompatibility if the IETF changes the protocol.

Can anyone think of other things to do before releasing the 1.7.x branch
as a new stable 1.8.0?

Come to think of it, the amount of new features (especially TLS 1.2) may
warrant calling this release 2.0.0.  What do you think?

I'll try to go over a 'diff -r gnutls_1_6_2 gnutls_1_7_11' to see if
there is some pending work that I've forgotten about.

/Simon


From alon.barlev at gmail.com  Sat May 26 19:24:24 2007
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Sat, 26 May 2007 20:24:24 +0300
Subject: [gnutls-dev] Things to do before next stable release?
In-Reply-To: <87bqg7ed65.fsf@mocca.josefsson.org>
References: <87bqg7ed65.fsf@mocca.josefsson.org>
Message-ID: <9e0cf0bf0705261024i16b5e903pe1826922aebb28ff@mail.gmail.com>

What about the external engine? (To enable PKCS#11 and such?)

Alon.

On 5/26/07, Simon Josefsson <simon at josefsson.org> wrote:
> I think 1.7.x now contains a lot of stuff that we should release as a
> stable release, for example:
>
> * TLS 1.2 support (although protocol not finalized in the IETF yet).
>
> * Proxy certificate support.
>
> * Signing using RSA-SHA256/384/512.
>
> * New APIs to print textual representation of certificates.
>
> * Support for 'otherName' SAN.
>
> * Support for supplemental data (RFC 4680).
>
> * Support for tls-authz.
>
> * New APIs to iterate through supported algorithms.
>
> Plus many, many bug fixes and other improvements of existing code.
>
> Initially I wanted to wait for TLS 1.2 to stabilize until we would
> release 1.8.0, although that seems to take longer than expected.
>
> I think we could release 1.8.0 as-is, with TLS 1.2 disabled as a default
> protocol, and with a release note saying that the TLS 1.2 stuff is
> subject to change incompatibility if the IETF changes the protocol.
>
> Can anyone think of other things to do before releasing the 1.7.x branch
> as a new stable 1.8.0?
>
> Come to think of it, the amount of new features (especially TLS 1.2) may
> warrant calling this release 2.0.0.  What do you think?
>
> I'll try to go over a 'diff -r gnutls_1_6_2 gnutls_1_7_11' to see if
> there is some pending work that I've forgotten about.
>
> /Simon
>
> _______________________________________________
> Gnutls-dev mailing list
> Gnutls-dev at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnutls-dev
>


From simon at josefsson.org  Sat May 26 22:09:01 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Sat, 26 May 2007 22:09:01 +0200
Subject: [gnutls-dev] PKCS#8 parser does not return ASN.1 errors properly
In-Reply-To: <20070524084442.7722DD4CB7@mx.npubs.com> (Nate Nielsen's message
	of "Thu, 24 May 2007 08:44:43 +0000 (UTC)")
References: <20070524084442.7722DD4CB7@mx.npubs.com>
Message-ID: <874plzqrdu.fsf@mocca.josefsson.org>

(I'm cc'ing gnutls-dev... I'll ask the gnu.org people to redirect
bug-gnutls at gnu.org to this list too.)

Nate Nielsen <nielsen-list at memberwebs.com> writes:

> I'm working on the gnome-keyring X509 code and trying to use gnutls for
> this. I've run into a bug:
>
> The PKCS#8 code does not return ASN.1 errors properly when parsing a
> non-PKCS#8 private key.
>
> Attached is test case, and patch.

Patch installed on 1.6.x.

I'd like to incorporate your self-test for the 1.7.x branch, though, but
that requires that you assign the copyright on the self test to the FSF.
Is that ok with you?  If so, I can send you the proper forms.

Thanks,
Simon

> Cheers,
> Nate Nielsen
> --- lib/x509/privkey_pkcs8.c.orig	2007-05-23 22:11:51.000000000 -0000
> +++ lib/x509/privkey_pkcs8.c	2007-05-23 22:12:33.000000000 -0000
> @@ -779,6 +779,7 @@
>    if (result != ASN1_SUCCESS)
>      {
>        gnutls_assert ();
> +      result = _gnutls_asn2err (result);
>        goto error;
>      }
>  
> /* gcc -g -O0 -o gnutls-test `pkg-config --libs --cflags gnutls` gnutls-test-pkcs8.c */
>
> #include <stdio.h>
> #include <stdlib.h>
> #include <unistd.h>
>
> #include <gnutls/gnutls.h>
> #include <gnutls/x509.h>
> #include <gcrypt.h>
>
> static void
> read_file (const char *file, gnutls_datum_t *datum)
> {
> 	FILE *f = fopen (file, "rb");
> 	if (f) {
> 		datum->data = malloc (8192);
> 		datum->size = fread (datum->data, 1, 8192, f);
> 	}
> 	if (!f || ferror (f))
> 		err (1, "couldn't read from file: %s", file);
> 	fclose (f);
> }
>
> int
> main (int argc, char **argv)
> {
> 	gnutls_x509_privkey_t privkey;
> 	gnutls_datum_t datum;
> 	int gerr;
>
> 	if (argc < 2)
> 		errx (1, "specify key to parse");
>
> 	gcry_check_version (GCRYPT_VERSION);
> 	gnutls_global_init ();
>
> 	read_file (argv[1], &datum);
> 				
> 	gnutls_x509_privkey_init (&privkey);
>
> 	gerr = gnutls_x509_privkey_import_pkcs8 (privkey, &datum, 
> 			GNUTLS_X509_FMT_DER, "test", GNUTLS_PKCS_PLAIN);
> 	printf ("parse result: %d\n", gerr);
>
> 	gnutls_global_deinit ();
> 	return 0;
> }


From simon at josefsson.org  Sat May 26 22:17:30 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Sat, 26 May 2007 22:17:30 +0200
Subject: [gnutls-dev] GnuTLS Fix: Decrypting PKCS#8 privkey with invalid
	password has same error as parse failure
In-Reply-To: <20070524085642.77ED0D4CB7@mx.npubs.com> (Nate Nielsen's message
	of "Thu, 24 May 2007 08:56:43 +0000 (UTC)")
References: <20070524085642.77ED0D4CB7@mx.npubs.com>
Message-ID: <87wsyvpcf9.fsf@mocca.josefsson.org>

Nate Nielsen <nielsen-list at memberwebs.com> writes:

> I'm working on using gnutls to parse certificates and keys in
> gnome-keyring.
>
> I've come across a problem where a invalid password for a PKCS#8
> encrypted key produces the same error as a ASN.1 parse failure.
>
> Attached is a patch which fixes the problem in a way that I hope makes
> sense. Any ASN.1 parse failures that late in the game, and immediately
> after decryption are treated as an invalid password.
>
> Given the terseness of DER encoded data, I don't think that there is a
> reliable (and quick) way of guaranteeing this in all extreme corner
> cases. However I believe that the fix makes gnutls more correct.
>
> Attached are test cases and patch.

Patch installed on 1.6.x branch, even though it is close to the ~10
lines limit that would require copyright assignments.  The self-test is
longer than 10 lines, though, and papers are required for it.  I'd like
to include it in 1.7.x with your co-operation, see the response to your
other report.

Thanks,
Simon

> In order for this to work, the patch from my earlier bug report (about
> PKCS#8 key parsing not reporting parse failures) will need to be applied.
>
> Cheers,
> Nate Nielsen
>
> /* gcc -g -O0 -o gnutls-test `pkg-config --libs --cflags gnutls` gnutls-test-pkcs8-password.c */
>
> #include <stdio.h>
> #include <stdlib.h>
> #include <unistd.h>
>
> #include <gnutls/gnutls.h>
> #include <gnutls/x509.h>
> #include <gcrypt.h>
>
> static void
> read_file (const char *file, gnutls_datum_t *datum)
> {
> 	FILE *f = fopen (file, "rb");
> 	if (f) {
> 		datum->data = malloc (8192);
> 		datum->size = fread (datum->data, 1, 8192, f);
> 	}
> 	if (!f || ferror (f))
> 		err (1, "couldn't read from file: %s", file);
> 	fclose (f);
> }
>
> int
> main (int argc, char **argv)
> {
> 	gnutls_x509_privkey_t privkey;
> 	gnutls_datum_t datum;
> 	int gerr;
>
> 	if (argc < 2)
> 		errx (1, "specify key to parse");
>
> 	gcry_check_version (GCRYPT_VERSION);
> 	gnutls_global_init ();
>
> 	read_file (argv[1], &datum);
> 				
> 	gnutls_x509_privkey_init (&privkey);
>
> 	gerr = gnutls_x509_privkey_import_pkcs8 (privkey, &datum, 
> 			GNUTLS_X509_FMT_DER, "test", GNUTLS_PKCS_PLAIN);
> 	printf ("no password: %d\n", gerr);
> 	printf ("       algo: %d\n", gnutls_x509_privkey_get_pk_algorithm (privkey));		
>
>
> 	gerr = gnutls_x509_privkey_import_pkcs8 (privkey, &datum, 
> 			GNUTLS_X509_FMT_DER, "test", GNUTLS_PKCS_USE_PBES2_3DES);
> 	printf ("pasword 'test': %d\n", gerr);		
> 	printf ("          algo: %d\n", gnutls_x509_privkey_get_pk_algorithm (privkey));		
>
> 	gerr = gnutls_x509_privkey_import_pkcs8 (privkey, &datum, 
> 			GNUTLS_X509_FMT_DER, "bork", GNUTLS_PKCS_USE_PBES2_3DES);
> 	printf ("pasword 'bork': %d\n", gerr);		
> 	printf ("          algo: %d\n", gnutls_x509_privkey_get_pk_algorithm (privkey));		
> 	
> 	gnutls_global_deinit ();
> 	return 0;
> }
>
> --- lib/x509/privkey_pkcs8.c.orig	2007-05-23 22:11:51.000000000 -0000
> +++ lib/x509/privkey_pkcs8.c	2007-05-23 22:43:49.000000000 -0000
> @@ -739,6 +739,25 @@
>  
>    if (result < 0)
>      {
> +      /* We've gotten this far. In the real world it's almost certain
> +       * that we're dealing with a good file, but wrong password. 
> +       * Sadly like 90% of random data is somehow valid DER for the 
> +       * a first small number of bytes, so no easy way to guarantee. */
> +      if (result == GNUTLS_E_ASN1_ELEMENT_NOT_FOUND ||
> +          result == GNUTLS_E_ASN1_IDENTIFIER_NOT_FOUND ||
> +          result == GNUTLS_E_ASN1_DER_ERROR ||
> +          result == GNUTLS_E_ASN1_VALUE_NOT_FOUND ||
> +          result == GNUTLS_E_ASN1_GENERIC_ERROR ||
> +          result == GNUTLS_E_ASN1_VALUE_NOT_VALID ||
> +          result == GNUTLS_E_ASN1_TAG_ERROR || 
> +          result == GNUTLS_E_ASN1_TAG_IMPLICIT ||
> +          result == GNUTLS_E_ASN1_TYPE_ANY_ERROR ||
> +          result == GNUTLS_E_ASN1_SYNTAX_ERROR ||
> +          result == GNUTLS_E_ASN1_DER_OVERFLOW)
> +        {
> +           result = GNUTLS_E_DECRYPTION_FAILED;
> +        }
> +
>        gnutls_assert ();
>        goto error;
>      }


From simon at josefsson.org  Sat May 26 22:22:57 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Sat, 26 May 2007 22:22:57 +0200
Subject: [gnutls-dev] Things to do before next stable release?
In-Reply-To: <9e0cf0bf0705261024i16b5e903pe1826922aebb28ff@mail.gmail.com>
	(Alon Bar-Lev's message of "Sat, 26 May 2007 20:24:24 +0300")
References: <87bqg7ed65.fsf@mocca.josefsson.org>
	<9e0cf0bf0705261024i16b5e903pe1826922aebb28ff@mail.gmail.com>
Message-ID: <87sl9jpc66.fsf@mocca.josefsson.org>

Oh, right, definitely.  Thanks for reminding me.  I'll try to get 1.6.3
out tonight, then I'll work on reworking the sign callback API, and wait
for your review of it.  After that, we can move it into the 1.7.x
branch.  I think the sign callback work is important enough to hold up
the next stable branch.

Note to self, my todo-list before releasing 1.8.0 right now is:

* Fix sign callback API to be per-credential rather than per-session.

* Check copyright papers for everyone who contributed during the 1.7.x
  phase (I opportunistically installed some fixes after confirming with
  authors that they were sending copyright assignments, although I have
  not verified that the assignment were actually received).

* Make sure the stuff in the GIT repository (i.e., all recent work) is
  available through CVS, either through back-ports to the old server or
  a git-cvsserver approach.

/Simon

"Alon Bar-Lev" <alon.barlev at gmail.com> writes:

> What about the external engine? (To enable PKCS#11 and such?)
>
> Alon.
>
> On 5/26/07, Simon Josefsson <simon at josefsson.org> wrote:
>> I think 1.7.x now contains a lot of stuff that we should release as a
>> stable release, for example:
>>
>> * TLS 1.2 support (although protocol not finalized in the IETF yet).
>>
>> * Proxy certificate support.
>>
>> * Signing using RSA-SHA256/384/512.
>>
>> * New APIs to print textual representation of certificates.
>>
>> * Support for 'otherName' SAN.
>>
>> * Support for supplemental data (RFC 4680).
>>
>> * Support for tls-authz.
>>
>> * New APIs to iterate through supported algorithms.
>>
>> Plus many, many bug fixes and other improvements of existing code.
>>
>> Initially I wanted to wait for TLS 1.2 to stabilize until we would
>> release 1.8.0, although that seems to take longer than expected.
>>
>> I think we could release 1.8.0 as-is, with TLS 1.2 disabled as a default
>> protocol, and with a release note saying that the TLS 1.2 stuff is
>> subject to change incompatibility if the IETF changes the protocol.
>>
>> Can anyone think of other things to do before releasing the 1.7.x branch
>> as a new stable 1.8.0?
>>
>> Come to think of it, the amount of new features (especially TLS 1.2) may
>> warrant calling this release 2.0.0.  What do you think?
>>
>> I'll try to go over a 'diff -r gnutls_1_6_2 gnutls_1_7_11' to see if
>> there is some pending work that I've forgotten about.
>>
>> /Simon
>>
>> _______________________________________________
>> Gnutls-dev mailing list
>> Gnutls-dev at gnupg.org
>> http://lists.gnupg.org/mailman/listinfo/gnutls-dev
>>


From simon at josefsson.org  Sat May 26 22:25:08 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Sat, 26 May 2007 22:25:08 +0200
Subject: [gnutls-dev] gnutls-1.6.1.auth_cert.mem-leak.awn.1.patch
In-Reply-To: <6161f3180705070311l757c059g2a93b05b0b8abafd@mail.gmail.com>
	(Andrew W. Nosenko's message of "Mon, 7 May 2007 13:11:10 +0300")
References: <6161f3180704260818p39b399d2x594da396b76bfb9e@mail.gmail.com>
	<6161f3180704270515s5cff14x3bd6f4a811809fdc@mail.gmail.com>
	<874pn2roki.fsf@mocca.josefsson.org>
	<6161f3180704270635m198a66f4kd337c2985c240312@mail.gmail.com>
	<6161f3180705070311l757c059g2a93b05b0b8abafd@mail.gmail.com>
Message-ID: <87odk7pc2j.fsf@mocca.josefsson.org>

"Andrew W. Nosenko" <andrew.w.nosenko at gmail.com> writes:

> Sorry, but I don't see patch applied neither to the HEAD nor to the
> gnutls_1_6_x branch.
>
> Does it mean that patch is forbidden for some reason?

No, it just means that I haven't gotten around to it.  It has been
installed on the 1.6.x branch now.

Thanks,
Simon


From simon at josefsson.org  Sat May 26 23:05:00 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Sat, 26 May 2007 23:05:00 +0200
Subject: [gnutls-dev] GnuTLS 1.6.3
Message-ID: <87fy5jpa83.fsf@mocca.josefsson.org>

I am happy to announce GnuTLS 1.6.3!

This is a bugfix-only release on the stable branch.  This version is
what we recommend for those who need a stable version of GnuTLS.

GnuTLS is a modern C library that implement the standard network
security protocol Transport Layer Security (TLS), for use by network
applications.  GnuTLS is developed for GNU/Linux, but works on many
Unix-like systems and comes with a binary installer for Windows.

   Warning!  GnuTLS uses OpenCDK for OpenPGP parsing.  Recently, a new
   branch of OpenCDK has been released by Timo as 0.6.x.  Unfortunately,
   the new branch is not backwards API/ABI compatible with the old 0.5.x
   branch.  The stable branch of GnuTLS do not support the newer OpenCDK
   0.6.x releases.  To be able to build GnuTLS 1.6.x, you must use
   OpenCDK 0.5.x instead of 0.6.x.  Alternatively, use the ./configure
   parameter --with-included-opencdk to use the included copy of OpenCDK
   0.5.13 for building GnuTLS, or the --disable-openpgp-authentication
   parameter to disable OpenPGP altogether.

* Version 1.6.3 (released 2007-05-26)

** New API functions to extract DER encoded X.509 Subject/Issuer DN.
Suggested by Nate Nielsen <nielsen-list at memberwebs.com>.  Backported
From the 1.7.x branch, see
<http://lists.gnu.org/archive/html/help-gnutls/2007-05/msg00029.html>.

** Have PKCS8 parser return better error codes.
Reported by Nate Nielsen <nielsen-list at memberwebs.com>, see
<http://lists.gnupg.org/pipermail/gnutls-dev/2007-May/001653.html> and
<http://lists.gnupg.org/pipermail/gnutls-dev/2007-May/001654.html>.

** Fix mem leak for sessions with client authentication via certificates.
Reported by Andrew W. Nosenko <andrew.w.nosenko at gmail.com>, see
<http://lists.gnupg.org/pipermail/gnutls-dev/2007-April/001539.html>.

** Fix building of 'tlsia' self test.
Earlier some gcc are known to build tlsia linking to
$prefix/lib/libgnutls-extra.so rather than the libgnutls-extra.so in
the build directory, even though command line parameters look OK.
Changing order of some parameters fixes it.

** API and ABI modifications:
gnutls_x509_crt_get_raw_issuer_dn: ADD.
gnutls_x509_crt_get_raw_dn: ADD.

Improving GnuTLS is costly, but you can help!  We are looking for
organizations that find GnuTLS useful and wish to contribute back.
You can contribute by reporting bugs, improve the software, or donate
money or equipment.

Commercial support contracts for GnuTLS are available, and they help
finance continued maintenance.  Simon Josefsson Datakonsult, a
Stockholm based privately held company, is currently funding GnuTLS
maintenance.  We are always looking for interesting development
projects.  See http://josefsson.org/ for more details.

All manual formats are available from:
  http://www.gnutls.org/manual/

Direct link to the most popular formats:
  http://www.gnutls.org/manual/gnutls.html - HTML format
  http://www.gnutls.org/manual/gnutls.pdf  - PDF format
  http://www.gnutls.org/reference/ch01.html  - API Reference, GTK-DOC HTML

If you need help to use GnuTLS, or want to help others, you are
invited to join our help-gnutls mailing list, see:
<http://lists.gnu.org/mailman/listinfo/help-gnutls>.

The project page of the library is available at:
  http://www.gnutls.org/
  http://www.gnu.org/software/gnutls/
  http://josefsson.org/gnutls/

Here are the compressed sources (4.2MB):
  ftp://ftp.gnutls.org/pub/gnutls/gnutls-1.6.3.tar.bz2
  http://josefsson.org/gnutls/releases/gnutls-1.6.3.tar.bz2

Here are GPG detached signatures signed using key 0xB565716F:
  ftp://ftp.gnutls.org/pub/gnutls/gnutls-1.6.3.tar.bz2.sig
  http://josefsson.org/gnutls/releases/gnutls-1.6.3.tar.bz2.sig

For more information about GnuTLS for Windows:
  http://josefsson.org/gnutls4win/

The Windows binary installer and PGP signature:
  http://josefsson.org/gnutls4win/gnutls-1.6.3.exe (23MB)
  http://josefsson.org/gnutls4win/gnutls-1.6.3.exe.sig

The software is cryptographically signed by the author using an
OpenPGP key identified by the following information:

pub   1280R/B565716F 2002-05-05 [expires: 2008-06-30]
      Key fingerprint = 0424 D4EE 81A0 E3D1 19C6  F835 EDA2 1E94 B565 716F
uid                  Simon Josefsson <simon at josefsson.org>
uid                  Simon Josefsson <jas at extundo.com>
sub   1280R/4D5D40AE 2002-05-05 [expires: 2008-06-30]

The key is available from:
  http://josefsson.org/key.txt
  dns:b565716f.josefsson.org?TYPE=CERT

Here are the SHA-1 and SHA-224 checksums:

7553b9f7ddd4982c0759b814bc6d9bf892cf7347  gnutls-1.6.3.tar.bz2
bc498d2b5c889508f4710a2df5fb12efd68017b6  gnutls-1.6.3.tar.bz2.sig

ad48dcb65eb2c35bf4056d91c61f7653007b9e54bb458d40e71991d8  gnutls-1.6.3.tar.bz2
d66b001c0a82b6e6db9939a93d367f2c0983eaff5a9d649058b60405  gnutls-1.6.3.tar.bz2.sig

0aa3170d94fef9760fafdfab7cb0dbf5ad51b8be  gnutls-1.6.3.exe
6beaaa5fcefd0f137470c527bfe7e6d3cb926d6b  gnutls-1.6.3.exe.sig

4ac84057d4dde931dab4db0886acb448cb778ccc4e7cfce1bdc549e8  gnutls-1.6.3.exe
217ba330a6e8ad2e9ed0fa9c9dd0defec14fd9d27d113920a48d1d35  gnutls-1.6.3.exe.sig

/Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 419 bytes
Desc: not available
Url : /pipermail/attachments/20070526/805440e4/attachment.pgp 

From simon at josefsson.org  Sat May 26 23:20:26 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Sat, 26 May 2007 23:20:26 +0200
Subject: [gnutls-dev] Porting bug fixes to 1.6.x
In-Reply-To: <87r6p5capa.fsf@laas.fr> ("Ludovic =?iso-8859-1?Q?Court=E8s?=
	=?iso-8859-1?Q?=22's?= message of "Fri, 25
	May 2007 15:08:33 +0200")
References: <87lkfiwckp.fsf@laas.fr> <87fy5pb1mb.fsf@mocca.josefsson.org>
	<87d50r5vb1.fsf@laas.fr> <87646hw051.fsf@mocca.josefsson.org>
	<87r6p5capa.fsf@laas.fr>
Message-ID: <87bqg7p9id.fsf@mocca.josefsson.org>

Hi Ludovic.  I am sorry these patches didn't make it for 1.6.3, but I
had to cut the line somewhere, and I felt these hadn't been reviewed
sufficiently for back-porting yet.  We can still make a 1.6.4 soon if
you want.

ludovic.courtes at laas.fr (Ludovic Court?s) writes:

>> This one seems too big...  I think we could start pre-testing of 1.7.x
>> targetting a stable 1.8.0 soon instead.
>
> Yeah, if you think time has come, then that would be easier.

Yes, I think we should push out 1.8.0 (or 2.0.0) within a few weeks or
so, if we can settle all open issues with it.  Perhaps that would be
sufficient, and you don't need 1.6.x with (only some of) the OpenPGP
fixes?  1.8 will contain the new OpenCDK 0.6.x and all the fixes.

>> It didn't work out with Savannah for now (they don't want to mirror
>> other git repositories), but I'm working on getting a mirror up at
>> repo.or.cz now.
>
> Alright.
>
> I'd like to have the Guile bindings integrated by the time you release
> 1.8.  So I'll start the integration work from your Git repository when
> it's available.

The git repository at repo.or.cz is what I'm using for 1.7.x development
now, so you could start right now.  I don't really know much about git
though, so when you are done, you'll probably have to tell me what
commands to invoke, or we'll have to experiment, so I can pull your
changes from you into my git archive.

Btw, having the guile bindings be part of 1.8 is a good idea.  I think
it should be a blocking milestone for it.  So now my todo-list for 1.8
is:

* Integrate Guile bindings.

* Fix sign callback API to be per-credential rather than per-session.

* Check copyright papers for everyone who contributed during the 1.7.x
  phase (I opportunistically installed some fixes after confirming with
  authors that they were sending copyright assignments, although I have
  not verified that the assignment were actually received).

* Make sure the stuff in the GIT repository (i.e., all recent work) is
  available through CVS, either through back-ports to the old server or
  a git-cvsserver approach.

/Simon


From simon at josefsson.org  Sun May 27 00:09:00 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Sun, 27 May 2007 00:09:00 +0200
Subject: [gnutls-dev] GnuTLS vs OpenSSL vs NSS
In-Reply-To: <6738615.19821180139659054.JavaMail.nabble@isper.nabble.com>
	(rrelyea@redhat.com's message of "Fri, 25 May 2007 17:34:19 -0700")
References: <6738615.19821180139659054.JavaMail.nabble@isper.nabble.com>
Message-ID: <87irafnsoz.fsf@mocca.josefsson.org>

rrelyea at redhat.com writes:

> Simon Josefsson-2 wrote:
>> 
>> Hi!
>> 
>> I've created some tables with a comparison between common TLS
>> implementations.  I'm running short of ideas on things to compare.  Any
>> ideas or suggestions?  The URL is:
>> 
>> http://www.gnu.org/software/gnutls/comparison.html
>> 
>> What do you think?
>> 
>> Also, if you notice any mistakes, or know for sure the status on some I
>> put down as 'No?', please let me know and I'll fix it.
>
> Hi simon,
>
> I have a few updates for you:

Hi!  Many thanks.  I have intended to send links to the OpenSSL/NSS
teams, but I haven't felt finished enough with the page to do so yet.  I
am happy to incorporate your suggestions now.

> Under portability concerns, NSS should read:
>
> NSS Platform requirements - NSPR* Network requirements - NSPR* thread
> safety- NSPR* (uses native platform threads when available, provides
> thread implementation if f necessary) Random Seed - set through native
> OS API, extra entropy grab from installed PKCS #11 modules,
> application can also add entropy on the fly

Added most of it, but I don't understand the last part -- how is the
random seed set through a 'native OS API'?  Does this refer to some NSPR
API?  Or what OS APIs do you mean?  I'm not aware of any standard APIs
for setting random seeds.

> *NSPR(and NSS) has(have) been ported to the following platforms (that
> I know about): AIX, BSD, BeOS, HP-UX, IRIX, Linux, Mac OS X, Mac OS 9,
> OS/2, Solaris, OpenVMS, Amiga DE, Windows, WinCE, Sony playstation.
>
> Under Developement:
> remove PR_ * from namespace in the NSS page. PR_ is part of the NSPR
> namespace...  crypto library... change NSS from included, monolithic
> to included, PKCS #11 based*
>
> *On the fly replaceable/augmentable.

Fixed.

> It would be good to add a column on certificate management/storage and
> PKCS #11/token support.
>
> There's also a missing table to include things like OCSP and CRL
> processing support.

Good ideas, I've added this on the todo list at the bottom of the page.

> Finally, Under Protocol support, the NSS column for SSL2 should say (yes, off by default)

Changed.

Thanks,
Simon

> Thanks
>
> bob
>
>
>
>> 
>> /Simon
>> 
>> 
>> _______________________________________________
>> Help-gnutls mailing list
>> Help-gnutls at gnu.org
>> http://lists.gnu.org/mailman/listinfo/help-gnutls
>> 
>> 
> Quoted from: 
> http://www.nabble.com/GnuTLS-vs-OpenSSL-vs-NSS-tf3685816.html#a10302694


From ametzler at downhill.at.eu.org  Sun May 27 11:52:48 2007
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Sun, 27 May 2007 11:52:48 +0200
Subject: [gnutls-dev] Bug#386530: sits waiting for server reponse in
	socket_bye
In-Reply-To: <20060908093409.GA11427@acklap03>
References: <20060908093409.GA11427@acklap03>
Message-ID: <20070527095248.GB3725@downhill.g.la>

Hello,
this is http://bugs.debian.org/386530 submitted by "Robert Millan
[ackstorm]" <rmillan at ackstorm.es>:

On 2006-09-08 "Robert Millan [ackstorm]" <rmillan at ackstorm.es> wrote:
> Package: gnutls-bin
> Severity: normal
> Tags: patch upstream

> Some servers (e.g. IIS) don't send a reply to gnutls_bye's close request.  This
> causes socket_bye to sit waiting for input from peer that never comes.

> Since socket_bye is going to close the connection, we don't need to wait for
> it anyway.  My attached patch replaces GNUTLS_SHUT_RDWR with GNUTLS_SHUT_WR,
> which seems to archieve that.

> Note: this patch has already been sent to upstream (bug-gnutls at gnu.org)


I have stumbled upon this when browsing through gnutls' Debian's bug
and it still seems to be open in 1.7.x. Due to bug-gnutls at gnu.org
being non-public I do not know whether this has already been
discussed.

cu andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: do_not_wait_for_server_in_socket_bye.diff
Type: text/x-diff
Size: 550 bytes
Desc: not available
Url : /pipermail/attachments/20070527/2bd56691/attachment.bin 

From ametzler at downhill.at.eu.org  Sun May 27 13:14:54 2007
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Sun, 27 May 2007 13:14:54 +0200
Subject: [gnutls-dev] png images referenced in info docs not installed
	(#423577)
Message-ID: <20070527111454.GD3725@downhill.g.la>

Hello,
this was reported by Kevin Ryde <user42 at zip.com.au> in
<http://bugs.debian.org/423577>. gnutls' info docs refer/include a
couple of png-images, however make install does not install them.

Since installing a file of the generic name "internals.png" directly
into /usr/share/info might result in conflicts with other software
using a dedicated subdirectory (gnutls/) seems to be the way to solve
this.

cu andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


From nielsen-list at memberwebs.com  Mon May  7 00:02:14 2007
From: nielsen-list at memberwebs.com (Nate Nielsen)
Date: Sun, 06 May 2007 22:02:14 -0000
Subject: [gnutls-dev] RFC: PKCS#11 plans
References: <87abx061cr.fsf@mocca.josefsson.org>	
	<9e0cf0bf0704220540w2fb9168co8e3ea75cb15fa983@mail.gmail.com>	
	<87d51w4l9x.fsf@mocca.josefsson.org>	
	<9e0cf0bf0704220613j6138d941y640d6d330b2ad54c@mail.gmail.com>	
	<87odlg33eu.fsf@mocca.josefsson.org>	
	<20070424152835.8CA64D4C43@mx.npubs.com>
	<9e0cf0bf0704240853q25c7960el5e0b32235d893575@mail.gmail.com>
	<462FDC50.40208@memberwebs.com>
Message-ID: <20070506183814.30BB9D4C0E@mx.npubs.com>

> Alon Bar-Lev wrote:
>> On 4/24/07, Nate Nielsen <nielsen-list at memberwebs.com> wrote:
>>> BTW, I'm working on building a complete PKCS#11 provider for CAPI. So by
>>> supporting PKCS#11 you'd be able to have things like CAPI support.
>> This is great to hear!
>> It has been long since I developed for Microsoft environment... But I
>> can help if you like!

Here's the basic version 0.1 CAPI PKCS#11 plugin. It exposes
certificates (but not keys yet) and certificate trust.

I'll probably end up hosting this at code.google.com unless anyone has
better suggestions.

Cheers,
Nate Nielsen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ckcapi.dll.zip
Type: application/zip
Size: 62638 bytes
Desc: not available
Url : /pipermail/attachments/20070506/5b3b5305/attachment-0001.zip 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cryptoki-capi-0.1.tar.gz
Type: application/x-gzip
Size: 60743 bytes
Desc: not available
Url : /pipermail/attachments/20070506/5b3b5305/attachment-0001.bin 

From nielsen-list at memberwebs.com  Mon May  7 00:02:29 2007
From: nielsen-list at memberwebs.com (Nate Nielsen)
Date: Sun, 06 May 2007 22:02:29 -0000
Subject: [gnutls-dev] RFC: PKCS#11 plans
References: <87abx061cr.fsf@mocca.josefsson.org>	
	<9e0cf0bf0704220540w2fb9168co8e3ea75cb15fa983@mail.gmail.com>	
	<87d51w4l9x.fsf@mocca.josefsson.org>	
	<9e0cf0bf0704220613j6138d941y640d6d330b2ad54c@mail.gmail.com>	
	<87odlg33eu.fsf@mocca.josefsson.org>	
	<20070424152835.8CA64D4C43@mx.npubs.com>
	<9e0cf0bf0704240853q25c7960el5e0b32235d893575@mail.gmail.com>
	<462FDC50.40208@memberwebs.com>
Message-ID: <20070506183806.C264BD4C01@mx.npubs.com>

> Alon Bar-Lev wrote:
>> On 4/24/07, Nate Nielsen <nielsen-list at memberwebs.com> wrote:
>>> BTW, I'm working on building a complete PKCS#11 provider for CAPI. So by
>>> supporting PKCS#11 you'd be able to have things like CAPI support.
>> This is great to hear!
>> It has been long since I developed for Microsoft environment... But I
>> can help if you like!

Here's my basic version 0.1 CAPI PKCS#11 plugin. It exposes certificates
(but not keys yet) and certificate trust.

I'll probably end up hosting this at code.google.com unless anyone has
better suggestions.

Cheers,
Nate Nielsen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ckcapi.dll.zip
Type: application/zip
Size: 62638 bytes
Desc: not available
Url : /pipermail/attachments/20070506/153ba76c/attachment-0001.zip 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cryptoki-capi-0.1.tar.gz
Type: application/x-gzip
Size: 60743 bytes
Desc: not available
Url : /pipermail/attachments/20070506/153ba76c/attachment-0001.bin 

From simon at josefsson.org  Sun May 27 16:10:28 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Sun, 27 May 2007 16:10:28 +0200
Subject: [gnutls-dev] Bug#386530: sits waiting for server reponse in
	socket_bye
In-Reply-To: <20070527095248.GB3725@downhill.g.la> (Andreas Metzler's message
	of "Sun, 27 May 2007 11:52:48 +0200")
References: <20060908093409.GA11427@acklap03>
	<20070527095248.GB3725@downhill.g.la>
Message-ID: <877iqucq7f.fsf@mocca.josefsson.org>

Andreas Metzler <ametzler at downhill.at.eu.org> writes:

> Hello,
> this is http://bugs.debian.org/386530 submitted by "Robert Millan
> [ackstorm]" <rmillan at ackstorm.es>:
>
> On 2006-09-08 "Robert Millan [ackstorm]" <rmillan at ackstorm.es> wrote:
>> Package: gnutls-bin
>> Severity: normal
>> Tags: patch upstream
>
>> Some servers (e.g. IIS) don't send a reply to gnutls_bye's close request.  This
>> causes socket_bye to sit waiting for input from peer that never comes.
>
>> Since socket_bye is going to close the connection, we don't need to wait for
>> it anyway.  My attached patch replaces GNUTLS_SHUT_RDWR with GNUTLS_SHUT_WR,
>> which seems to archieve that.
>
>> Note: this patch has already been sent to upstream (bug-gnutls at gnu.org)
>
>
> I have stumbled upon this when browsing through gnutls' Debian's bug
> and it still seems to be open in 1.7.x. Due to bug-gnutls at gnu.org
> being non-public I do not know whether this has already been
> discussed.

I recall discussing this, but I can't find it in my bug-gnutls folder.
That is all the more reason to make that alias publicly archived--I've
done so now, bug-gnutls at gnu.org should go to gnutls-dev at gnupg.org,
although I have yet to test it.

However, I'm not convinced this is the right fix.  I believe the servers
are buggy here, and changing gnutls seems the wrong response.

What we may want to do is to improve the behaviour when we encounter a
buggy server, which may include some kind of timeout or similar.
However, if the server closed the connection, I think it should be
possible to detect this, and then we can print a message.

To work on this, I need a way to reproduce it though.  Do you know of a
server that exhibit this behaviour that we can use?

Thanks,
Simon

> cu andreas
>
> diff -ur gnutls13-1.4.2.old/src/cli.c gnutls13-1.4.2/src/cli.c
> --- gnutls13-1.4.2.old/src/cli.c	2006-07-10 23:09:45.000000000 +0200
> +++ gnutls13-1.4.2/src/cli.c	2006-09-08 11:02:52.000000000 +0200
> @@ -1084,7 +1084,7 @@
>      if (socket->secure)
>      {
>          do
> -            ret = gnutls_bye (socket->session, GNUTLS_SHUT_RDWR);
> +            ret = gnutls_bye (socket->session, GNUTLS_SHUT_WR);
>          while (ret == GNUTLS_E_INTERRUPTED || ret == GNUTLS_E_AGAIN);
>          if (ret < 0)
>              fprintf (stderr, "*** gnutls_bye() error: %s\n",
>
> _______________________________________________
> Gnutls-dev mailing list
> Gnutls-dev at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnutls-dev


From simon at josefsson.org  Sun May 27 16:11:37 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Sun, 27 May 2007 16:11:37 +0200
Subject: [gnutls-dev] png images referenced in info docs not installed
	(#423577)
In-Reply-To: <20070527111454.GD3725@downhill.g.la> (Andreas Metzler's message
	of "Sun, 27 May 2007 13:14:54 +0200")
References: <20070527111454.GD3725@downhill.g.la>
Message-ID: <873b1icq5i.fsf@mocca.josefsson.org>

Andreas Metzler <ametzler at downhill.at.eu.org> writes:

> Hello,
> this was reported by Kevin Ryde <user42 at zip.com.au> in
> <http://bugs.debian.org/423577>. gnutls' info docs refer/include a
> couple of png-images, however make install does not install them.
>
> Since installing a file of the generic name "internals.png" directly
> into /usr/share/info might result in conflicts with other software
> using a dedicated subdirectory (gnutls/) seems to be the way to solve
> this.

How to deal with this properly is probably something that could be
discussed with the texinfo maintainers and/or gnu-hackers, I'll forward
the question.

/Simon


From simon at josefsson.org  Sun May 27 16:04:37 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Sun, 27 May 2007 16:04:37 +0200
Subject: [gnutls-dev] test
Message-ID: <87bqg6cqh6.fsf@mocca.josefsson.org>

test to see if bug-gnutls at gnu.org gets forwarded ok


From ametzler at downhill.at.eu.org  Sun May 27 17:10:03 2007
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Sun, 27 May 2007 17:10:03 +0200
Subject: [gnutls-dev] How to properly generate gnutls.pdf?
Message-ID: <20070527151003.GE3725@downhill.g.la>

Hello,

How is gnutls.pdf as included in the distribution generated? I have
tried to re-generate it after make clean but have stumbled upon a
couple of issues.

"make pdf" does not work for me, since @image is looking for .pdf:

| This is `epsf.tex' v2.7.3 <23 July 2005>
| ) localization, and turning on texinfo input format.) (./gnutls.aux)
| (./version.texi) (./my-bib-macros.texi)
| !pdfTeX error: pdfetex (file gnutls-logo.pdf): cannot find image file
| ==> Fatal error occurred, no output PDF file produced!

I can regenerate them manually with ps2pdf. After doing this I realize
that I need to run (La)TeX twice to get the references right
| [1{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}] [2] [-1] Chapter 1
| l.1: Undefined cross reference `Bibliography-snt'.
[1300 similar messages snipped]

So all in all it looks like I need to do this:
cd doc
make clean
for i in *eps ; do ps2pdf $i ; done
make pdf
rm gnutls.pdf
make pdf

The resulting file is more or less ok, the images are scaled wrongly
though. So, how do you do it?

thanks, cu andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


From simon at josefsson.org  Mon May 28 11:40:52 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 28 May 2007 11:40:52 +0200
Subject: [gnutls-dev] How to properly generate gnutls.pdf?
In-Reply-To: <20070527151003.GE3725@downhill.g.la> (Andreas Metzler's message
	of "Sun, 27 May 2007 17:10:03 +0200")
References: <20070527151003.GE3725@downhill.g.la>
Message-ID: <87tztxe15n.fsf@mocca.josefsson.org>

Andreas Metzler <ametzler at downhill.at.eu.org> writes:

> Hello,
>
> How is gnutls.pdf as included in the distribution generated? I have
> tried to re-generate it after make clean but have stumbled upon a
> couple of issues.
>
> "make pdf" does not work for me, since @image is looking for .pdf:
>
> | This is `epsf.tex' v2.7.3 <23 July 2005>
> | ) localization, and turning on texinfo input format.) (./gnutls.aux)
> | (./version.texi) (./my-bib-macros.texi)
> | !pdfTeX error: pdfetex (file gnutls-logo.pdf): cannot find image file
> | ==> Fatal error occurred, no output PDF file produced!

This was fixed in 1.7.9, gnutls-logo.pdf is in CVS but wasn't
distributed.  I suspect 'make distcheck' doesn't check this because
gnutls.pdf is already available.  Are you using 1.6.x?  That version
might not have the same fix yet.

> I can regenerate them manually with ps2pdf. After doing this I realize
> that I need to run (La)TeX twice to get the references right
> | [1{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}] [2] [-1] Chapter 1
> | l.1: Undefined cross reference `Bibliography-snt'.
> [1300 similar messages snipped]
>
> So all in all it looks like I need to do this:
> cd doc
> make clean
> for i in *eps ; do ps2pdf $i ; done
> make pdf
> rm gnutls.pdf
> make pdf
>
> The resulting file is more or less ok, the images are scaled wrongly
> though. So, how do you do it?

'make gnutls.pdf' in doc/, which is triggered by top-level 'make dist'.
Generally, if that doesn't work, something is wrong and should be fixed.

/Simon


From ametzler at downhill.at.eu.org  Mon May 28 12:46:40 2007
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Mon, 28 May 2007 12:46:40 +0200
Subject: [gnutls-dev] How to properly generate gnutls.pdf?
In-Reply-To: <87tztxe15n.fsf@mocca.josefsson.org>
References: <20070527151003.GE3725@downhill.g.la>
	<87tztxe15n.fsf@mocca.josefsson.org>
Message-ID: <20070528104640.GA3807@downhill.g.la>

On 2007-05-28 Simon Josefsson <simon at josefsson.org> wrote:
> Andreas Metzler <ametzler at downhill.at.eu.org> writes:

>> How is gnutls.pdf as included in the distribution generated? I have
>> tried to re-generate it after make clean but have stumbled upon a
>> couple of issues.

>> "make pdf" does not work for me, since @image is looking for .pdf:

>> | This is `epsf.tex' v2.7.3 <23 July 2005>
>> | ) localization, and turning on texinfo input format.) (./gnutls.aux)
>> | (./version.texi) (./my-bib-macros.texi)
>> | !pdfTeX error: pdfetex (file gnutls-logo.pdf): cannot find image file
>> | ==> Fatal error occurred, no output PDF file produced!

> This was fixed in 1.7.9, gnutls-logo.pdf is in CVS but wasn't
> distributed.  I suspect 'make distcheck' doesn't check this because
> gnutls.pdf is already available.  Are you using 1.6.x?  That version
> might not have the same fix yet.

1.7.9 contains gnutls-logo.pdf but it does not contain the other
images in pdf format (doc/layers.png doc/x509-1.png doc/internals.png
doc/pgp1.png)

Generating them from the png input with convert (instead of using
ps2pdf on the eps figures) seems to produce satisfying results.

>> I can regenerate them manually with ps2pdf. After doing this I realize
>> that I need to run (La)TeX twice to get the references right
>> | [1{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}] [2] [-1] Chapter 1
>> | l.1: Undefined cross reference `Bibliography-snt'.
>> [1300 similar messages snipped]

>> So all in all it looks like I need to do this:
>> cd doc
>> make clean
>> for i in *eps ; do ps2pdf $i ; done
>> make pdf
>> rm gnutls.pdf
>> make pdf

>> The resulting file is more or less ok, the images are scaled wrongly
>> though. So, how do you do it?

> 'make gnutls.pdf' in doc/, which is triggered by top-level 'make dist'.
> Generally, if that doesn't work, something is wrong and should be fixed.

Ok. So it is broken due to the missing pdf-converted images.

I am not able to reproduce the "Undefined cross reference" messages with
1.7.9, so I guess I did something stupid yesterday.
cu andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


From simon at josefsson.org  Mon May 28 14:49:52 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 28 May 2007 14:49:52 +0200
Subject: [gnutls-dev] How to properly generate gnutls.pdf?
In-Reply-To: <20070528104640.GA3807@downhill.g.la> (Andreas Metzler's message
	of "Mon, 28 May 2007 12:46:40 +0200")
References: <20070527151003.GE3725@downhill.g.la>
	<87tztxe15n.fsf@mocca.josefsson.org>
	<20070528104640.GA3807@downhill.g.la>
Message-ID: <87y7j9az9r.fsf@mocca.josefsson.org>

Andreas Metzler <ametzler at downhill.at.eu.org> writes:

> On 2007-05-28 Simon Josefsson <simon at josefsson.org> wrote:
>> Andreas Metzler <ametzler at downhill.at.eu.org> writes:
>
>>> How is gnutls.pdf as included in the distribution generated? I have
>>> tried to re-generate it after make clean but have stumbled upon a
>>> couple of issues.
>
>>> "make pdf" does not work for me, since @image is looking for .pdf:
>
>>> | This is `epsf.tex' v2.7.3 <23 July 2005>
>>> | ) localization, and turning on texinfo input format.) (./gnutls.aux)
>>> | (./version.texi) (./my-bib-macros.texi)
>>> | !pdfTeX error: pdfetex (file gnutls-logo.pdf): cannot find image file
>>> | ==> Fatal error occurred, no output PDF file produced!
>
>> This was fixed in 1.7.9, gnutls-logo.pdf is in CVS but wasn't
>> distributed.  I suspect 'make distcheck' doesn't check this because
>> gnutls.pdf is already available.  Are you using 1.6.x?  That version
>> might not have the same fix yet.
>
> 1.7.9 contains gnutls-logo.pdf but it does not contain the other
> images in pdf format (doc/layers.png doc/x509-1.png doc/internals.png
> doc/pgp1.png)

Oh!  I wonder how this went by unnoticed for this long.  Probably
because gnutls.pdf is included in the distribution.  I have fixed this
now in GIT, thanks.

/Simon


From Jeff.Cai at Sun.COM  Tue May 29 10:19:40 2007
From: Jeff.Cai at Sun.COM (Jeff Cai)
Date: Tue, 29 May 2007 16:19:40 +0800
Subject: [gnutls-dev] About RSA BSAFE libraries denial of service
	vulnerability
Message-ID: <1180426780.4544.17.camel@commissionaire>

Hi,
Maybe this is a very simple question. But because it concern security,
it becomes so important. 
Recently, someone found a security vulnerability of RSA BSAFE libraries
http://www.kb.cert.org/vuls/id/754281/ I don't know whether GNUTls uses
RSA algorithm or has similar problem.

Thanks 
-- 



From Jeff.Cai at Sun.COM  Tue May 29 09:18:55 2007
From: Jeff.Cai at Sun.COM (Jeff Cai)
Date: Tue, 29 May 2007 15:18:55 +0800
Subject: [gnutls-dev] About RSA BSAFE libraries denial of service
	vulnerability
Message-ID: <1180423135.4544.11.camel@commissionaire>

Hi,
Maybe this is a very simple question. But because it concern security,
it becomes so important. 
Recently, someone found a security vulnerability of RSA BSAFE libraries
http://www.kb.cert.org/vuls/id/754281/ I don't know whether GNUTls uses
RSA algorithm or has similar problem.

Thanks 

-- 



From simon at josefsson.org  Tue May 29 12:48:47 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 29 May 2007 12:48:47 +0200
Subject: [gnutls-dev] About RSA BSAFE libraries denial of service
	vulnerability
In-Reply-To: <1180423135.4544.11.camel@commissionaire> (Jeff Cai's message of
	"Tue, 29 May 2007 15:18:55 +0800")
References: <1180423135.4544.11.camel@commissionaire>
Message-ID: <87ps4jaos0.fsf@mocca.josefsson.org>

Jeff Cai <Jeff.Cai at Sun.COM> writes:

> Hi,
> Maybe this is a very simple question. But because it concern security,
> it becomes so important. 
> Recently, someone found a security vulnerability of RSA BSAFE libraries
> http://www.kb.cert.org/vuls/id/754281/ I don't know whether GNUTls uses
> RSA algorithm or has similar problem.

GnuTLS doesn't use RSA BSAFE Crypto-C or Cert-C, so if it is a problem
with those particular implementations, we are not affected.

There isn't sufficient technical information in the link you provide
that I can use to tell if GnuTLS is affected by a similar bug though.

/Simon


From Jeff.Cai at Sun.COM  Tue May 29 13:56:09 2007
From: Jeff.Cai at Sun.COM (Jeff Cai)
Date: Tue, 29 May 2007 19:56:09 +0800
Subject: [gnutls-dev] About RSA BSAFE libraries denial of service
	vulnerability
In-Reply-To: <87ps4jaos0.fsf@mocca.josefsson.org>
References: <1180423135.4544.11.camel@commissionaire>
	<87ps4jaos0.fsf@mocca.josefsson.org>
Message-ID: <1180439769.4544.21.camel@commissionaire>

Thanks Simon for your quick response.
I'll let you know if I can get more information about this vulnerability
of RSA BSAFE.

Jeff

On Tue, 2007-05-29 at 12:48 +0200, Simon Josefsson wrote:
> Jeff Cai <Jeff.Cai at Sun.COM> writes:
> 
> > Hi,
> > Maybe this is a very simple question. But because it concern security,
> > it becomes so important. 
> > Recently, someone found a security vulnerability of RSA BSAFE libraries
> > http://www.kb.cert.org/vuls/id/754281/ I don't know whether GNUTls uses
> > RSA algorithm or has similar problem.
> 
> GnuTLS doesn't use RSA BSAFE Crypto-C or Cert-C, so if it is a problem
> with those particular implementations, we are not affected.
> 
> There isn't sufficient technical information in the link you provide
> that I can use to tell if GnuTLS is affected by a similar bug though.
> 
> /Simon
-- 



From ludovic.courtes at laas.fr  Tue May 29 14:11:03 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Tue, 29 May 2007 14:11:03 +0200
Subject: [gnutls-dev] Porting bug fixes to 1.6.x
References: <87lkfiwckp.fsf@laas.fr> <87fy5pb1mb.fsf@mocca.josefsson.org>
	<87d50r5vb1.fsf@laas.fr> <87646hw051.fsf@mocca.josefsson.org>
	<87r6p5capa.fsf@laas.fr> <87bqg7p9id.fsf@mocca.josefsson.org>
Message-ID: <87veebu8x4.fsf@laas.fr>

Hi Simon,

Simon Josefsson <simon at josefsson.org> writes:

> Hi Ludovic.  I am sorry these patches didn't make it for 1.6.3, but I
> had to cut the line somewhere, and I felt these hadn't been reviewed
> sufficiently for back-porting yet.  We can still make a 1.6.4 soon if
> you want.

Alright, no problem.

> Yes, I think we should push out 1.8.0 (or 2.0.0) within a few weeks or
> so, if we can settle all open issues with it.  Perhaps that would be
> sufficient, and you don't need 1.6.x with (only some of) the OpenPGP
> fixes?  1.8 will contain the new OpenCDK 0.6.x and all the fixes.

If 1.8 is so close, then we (at least I) can probably live without
back-porting bug fixes into 1.6.  Initially, I thought 1.8 was further
away from now.

> The git repository at repo.or.cz is what I'm using for 1.7.x development
> now, so you could start right now.  I don't really know much about git
> though, so when you are done, you'll probably have to tell me what
> commands to invoke, or we'll have to experiment, so I can pull your
> changes from you into my git archive.

So far I just cloned it, so everything is alright.  ;-)

I'm a Git beginner as well, so we'll have to be cautious I guess.

> Btw, having the guile bindings be part of 1.8 is a good idea.  I think
> it should be a blocking milestone for it.  So now my todo-list for 1.8
> is:
>
> * Integrate Guile bindings.

Then I'll start working on it this week (that shouldn't be too much
work).

> * Fix sign callback API to be per-credential rather than per-session.

Oh, good.

BTW, will your PCKS#11 work get into 1.8?

Thanks!
Ludovic.



From simon at josefsson.org  Tue May 29 15:44:55 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 29 May 2007 15:44:55 +0200
Subject: [gnutls-dev] Porting bug fixes to 1.6.x
In-Reply-To: <87veebu8x4.fsf@laas.fr> ("Ludovic =?iso-8859-1?Q?Court=E8s?=
	=?iso-8859-1?Q?=22's?= message of "Tue, 29
	May 2007 14:11:03 +0200")
References: <87lkfiwckp.fsf@laas.fr> <87fy5pb1mb.fsf@mocca.josefsson.org>
	<87d50r5vb1.fsf@laas.fr> <87646hw051.fsf@mocca.josefsson.org>
	<87r6p5capa.fsf@laas.fr> <87bqg7p9id.fsf@mocca.josefsson.org>
	<87veebu8x4.fsf@laas.fr>
Message-ID: <87d50jagmg.fsf@mocca.josefsson.org>

ludovic.courtes at laas.fr (Ludovic Court?s) writes:

>> Yes, I think we should push out 1.8.0 (or 2.0.0) within a few weeks or
>> so, if we can settle all open issues with it.  Perhaps that would be
>> sufficient, and you don't need 1.6.x with (only some of) the OpenPGP
>> fixes?  1.8 will contain the new OpenCDK 0.6.x and all the fixes.
>
> If 1.8 is so close, then we (at least I) can probably live without
> back-porting bug fixes into 1.6.  Initially, I thought 1.8 was further
> away from now.

Well, let's try to make 1.8 happen as soon as possible.  If it takes
more than a month, then we can re-evaluate it.  Of course, if you want
to go through the trouble of applying the patches to the 1.6.x branch on
some git clone, I could probably learn how to pull in those changes into
my own git tree and make a 1.6.4 release of it.  Might even be useful as
git learning experience...

>> Btw, having the guile bindings be part of 1.8 is a good idea.  I think
>> it should be a blocking milestone for it.  So now my todo-list for 1.8
>> is:
>>
>> * Integrate Guile bindings.
>
> Then I'll start working on it this week (that shouldn't be too much
> work).

Great!

>> * Fix sign callback API to be per-credential rather than per-session.
>
> Oh, good.

I'll probably start to do that on a new branch, based on the most recent
1.7.x.  The current pkcs11-branch did it per-session, and it is probably
more work involved trying to revert those changes than creating a new
branch.

> BTW, will your PCKS#11 work get into 1.8?

I'm not sure how it should be integrated.  I strongly want GnuTLS to
support OpenPGP cards easily, although I'm not sure it makes sense to
have GnuTLS provide a full-blown native PKCS#11 interface.

I'm currently not sure whether to label the support as 'libgnutls-scute'
since it links to scute at build-time, or rename it as
'libgnutls-simple-pkcs11' and add some dlopen() stuff.

One reason against calling it 'libgnutls-pkcs11' (the current name) is
that we probably won't support all variations of pkcs11 modules, with
PIN entry callbacks and so on.  On the other hand, if we can support 90%
of the common uses of PKCS#11 through a simple API, I think we should
include that into GnuTLS natively.

I suppose the options are:

1) Ship libgnutls_scute.so which links directly to scute, and provides
   some APIs like gnutls_scute_get_user_certificates,
   gnutls_scute_get_ca_certificates, gnutls_scute_sign_callback.  The
   problem here is that it is scute-specific, even though I think other
   PKCS#11 plugins may easily be supported too by just replacing
   libscute.so with something else.

2) Ship libgnutls_simple_pkcs11, or perhaps rather libgnutls_spkcs11.so,
   which would dlopen a library, and provide an API like
   gnutls_spkcs11_dlopen, gnutls_spkcs11_get_user_certificates,
   gnutls_spkcs11_get_ca_certificates, gnutls_spkcs11_sign_callback,
   possibly gnutls_spkcs11_set_pin_callback.  The problem here is that
   we might not be a full-blown PKCS#11 implementation at day one, with
   support for every variation of PKCS#11 features.  However, if we can
   support some other PKCS#11 plugins easily through this route, I think
   it is the best one.

Of course, applications can always be able to use the sign callback
interface themselves, and implement a really full-blown PKCS#11
interface using an external library, or a CrytoAPI interface, or
whatever.  Neither option 1) and 2) forces applications to use PKCS#11
or Scute through our libraries.

I think I'm leaning towards 2) and stating in the release notes that we
haven't tried all PKCS#11 provides on the earth, and that there may be
significant missing functionality, and that patches are welcome.

However, implementing the dlopen() stuff may be non-trivial, and to save
time, perhaps we could settle with a gnutls-scute solution.  It feels
somewhat sub-optimal though.

/Simon


From robert.millan at ackstorm.es  Wed May 30 13:09:22 2007
From: robert.millan at ackstorm.es (Robert Millan [ackstorm])
Date: Wed, 30 May 2007 13:09:22 +0200
Subject: [gnutls-dev] [PATCH] gnutls-cli -t <timeout>
In-Reply-To: <20070528171903.GA19685@acklap03>
References: <20060908093409.GA11427@acklap03>
	<20070527095248.GB3725@downhill.g.la>
	<877iqucq7f.fsf@mocca.josefsson.org>
	<20070528082314.GB4547@acklap03> <20070528171903.GA19685@acklap03>
Message-ID: <20070530110922.GA5044@acklap03>


It seems that my mail didn't make it to the list.  I subscribed and resending it.

Btw, I found a bug in my previous patch, which is fixed here.

On Mon, May 28, 2007 at 07:19:03PM +0200, Robert Millan [ackstorm] wrote:
> On Mon, May 28, 2007 at 10:23:14AM +0200, Robert Millan [ackstorm] wrote:
> > On Sun, May 27, 2007 at 04:10:28PM +0200, Simon Josefsson wrote:
> > > 
> > > However, I'm not convinced this is the right fix.  I believe the servers
> > > are buggy here, and changing gnutls seems the wrong response.
> > > 
> > > What we may want to do is to improve the behaviour when we encounter a
> > > buggy server, which may include some kind of timeout or similar.
> > > However, if the server closed the connection, I think it should be
> > > possible to detect this, and then we can print a message.
> > 
> > I'm working on this atm.  I have almost completed a patch that implements this
> > timeout option (will send it RSN).
> > 
> > > To work on this, I need a way to reproduce it though.  Do you know of a
> > > server that exhibit this behaviour that we can use?
> > 
> > This works:  while sudo nc -lp 443 ; do true ; done
> > 
> > But please wait a day or two for my patch.
> 
> Here is it.  The SIGALRM feature was getting into the way, so I moved it to
> SIGHUP, which is more consistent with existing practice.
> 
> Works for dumb netcat-like servers, but is also useful for normal servers when
> you want to gather information about certificates without starting an HTTP
> session.

-- 
Robert Millan

ACK STORM, S.L. - http://www.ackstorm.es
-------------- next part --------------
A non-text attachment was scrubbed...
Name: timeout.diff
Type: text/x-diff
Size: 5284 bytes
Desc: not available
Url : /pipermail/attachments/20070530/fd75746f/attachment.bin 

From ludo at chbouib.org  Thu May 31 00:44:40 2007
From: ludo at chbouib.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Thu, 31 May 2007 00:44:40 +0200
Subject: [gnutls-dev] Starting Guile integration
Message-ID: <87myzmhqxz.fsf@chbouib.org>

Hi,

I think Guile integration is starting to be in a good shape.  Basically,
all the Guile code falls into the `guile' subdirectory.  The
documentation extraction stuff is added in the `doc' subdirectory but
should hopefully not be disruptive for those Guile-less builds (and the
generated files are in `EXTRA_DIST').

I'm currently unable to run `distcheck' because building the PDF file
fails after getting a large amount of "underfull/overfull \hbox"
messages.

My Git repository is available over HTTP at:

  http://www.laas.fr/~lcourtes/software/gnutls.git

If you prefer I can also send the patches generated by
`git-format-patch' but I had the feeling that it'd kind of a spammish
approach.  ;-)

Thanks,
Ludovic.



From ludo at chbouib.org  Thu May 31 09:11:06 2007
From: ludo at chbouib.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Thu, 31 May 2007 09:11:06 +0200
Subject: [gnutls-dev] Starting Guile integration
References: <87myzmhqxz.fsf@chbouib.org>
Message-ID: <87fy5dii2d.fsf@chbouib.org>

ludo at chbouib.org (Ludovic Court?s) writes:

> The documentation extraction stuff is added in the `doc' subdirectory
> but should hopefully not be disruptive for those Guile-less builds
                              ^^^^^^^^^^
This should be "disturbing".

Thanks,
Ludovic.



From simon at josefsson.org  Thu May 31 17:30:23 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 31 May 2007 17:30:23 +0200
Subject: [gnutls-dev] Starting Guile integration
In-Reply-To: <87myzmhqxz.fsf@chbouib.org> ("Ludovic =?iso-8859-1?Q?Court?=
	=?iso-8859-1?Q?=E8s=22's?= message of
	"Thu, 31 May 2007 00:44:40 +0200")
References: <87myzmhqxz.fsf@chbouib.org>
Message-ID: <87k5upyprk.fsf@mocca.josefsson.org>

ludo at chbouib.org (Ludovic Court?s) writes:

> Hi,
>
> I think Guile integration is starting to be in a good shape.  Basically,
> all the Guile code falls into the `guile' subdirectory.  The
> documentation extraction stuff is added in the `doc' subdirectory but
> should hopefully not be disruptive for those Guile-less builds (and the
> generated files are in `EXTRA_DIST').
>
> I'm currently unable to run `distcheck' because building the PDF file
> fails after getting a large amount of "underfull/overfull \hbox"
> messages.
>
> My Git repository is available over HTTP at:
>
>   http://www.laas.fr/~lcourtes/software/gnutls.git
>
> If you prefer I can also send the patches generated by
> `git-format-patch' but I had the feeling that it'd kind of a spammish
> approach.  ;-)

Thanks!  I accidentally used 'git pull' on your repository (I think I
wanted to use 'git fetch' instead), so your changes have now been
installed!

In general it looks good, but some things we need to address:

* guile/ isn't part of SUBDIRS in top-level Makefile.am so it is never
  built...

* building in the directory fails:

Making all in modules
make[1]: Entering directory `/home/jas/src/gnutls/guile/modules'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/jas/src/gnutls/guile/modules'
Making all in src
make[1]: Entering directory `/home/jas/src/gnutls/guile/src'
/usr/bin/guile -L ../../modules make-enum-map.scm > enum-map.i.c
ERROR: no code for module (gnutls build enums)
make[1]: *** [enum-map.i.c] Error 1
make[1]: Leaving directory `/home/jas/src/gnutls/guile/src'
make: *** [all-recursive] Error 1
jas at mocca:~/src/gnutls/guile$

* configure.ac contains:

   AC_PATH_PROG([guile_snarf], [guile-snarf], [not-found])
   if test "x$guile_snarf" = "xnot-found"; then
      AC_MSG_ERROR([`guile-snarf' not found.  Please install Guile 1.8.x or later.])
   fi

  This seems unsafe.  Could you change this so that if guile-snarf is
  not available, the guile bindings are disabled rather than aborting
  the build?

* Automake complains:

doc/Makefile.am:131: `%'-style pattern rules are a GNU make extension
doc/Makefile.am:139: `%'-style pattern rules are a GNU make extension

We don't want any GNU make extensions.  Hard-coding the rules for the
two files would be one solution.

* The manual's @node's were heavily changed, which causes problems.  You
  shouldn't need these modifications if you use the latest texinfo.  I
  reverted this stuff.

Thanks,
Simon


From simon at josefsson.org  Thu May 31 18:05:43 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 31 May 2007 18:05:43 +0200
Subject: [gnutls-dev] Starting Guile integration
In-Reply-To: <87k5upyprk.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Thu, 31 May 2007 17:30:23 +0200")
References: <87myzmhqxz.fsf@chbouib.org> <87k5upyprk.fsf@mocca.josefsson.org>
Message-ID: <87tztt7zc8.fsf@mocca.josefsson.org>

Another problem:

./configure: line 7459: GUILE_PROGS: command not found
./configure: line 7460: GUILE_FLAGS: command not found

The m4 files that define these macros need to be included in GnuTLS, I
suggest to place them in m4/.

/Simon