From simon at josefsson.org  Tue Dec  1 13:47:45 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 01 Dec 2009 13:47:45 +0100
Subject: missing file
In-Reply-To: <4B12F5D9.3060603@gnutls.org> (Nikos Mavrogiannopoulos's message
	of "Mon, 30 Nov 2009 00:29:45 +0200")
References: <878wdpzbel.fsf@mocca.josefsson.org> <4B12F5D9.3060603@gnutls.org>
Message-ID: <874ooaeu8e.fsf@mocca.josefsson.org>

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> Simon Josefsson wrote:
>> Nikos, did you forget to commit some file?
>> 
>> cryptodev.c:29:30: error: crypto/cryptodev.h: No such file or directory
>
> It was including this file unconditionally. Now it should be ok (only
> included if --enable-cryptodev is specified). If you have a cpu with
> crypto accelerator that is supported by linux (via and some amd geode
> cpus have), and you use cryptodev you should get quite a difference. For
> some reason I get big difference by using the kernel aes implementation.

Any links to the cryptodev.h stuff?  Any pointers on how to enable it on
Debian would be useful, I can't seem to find anything.

I see you made changes to the public header files, several of those
changes appears backwards incompatible -- that will break ABI
compatibility, which isn't a good idea.  Are these changes necessary?
If they are, and we really want to deprecate the old interfaces, we need
compatibility functions defined somewhere, and prototypes for them in
gnutls/compat.h.  Please also write a NEWS blurb for these API changes.

Building fails for me right now:

crq.c: In function 'rsadsa_crq_get_key_id':
crq.c:2333: error: implicit declaration of function '_gnutls_hash' [-Wimplicit-function-declaration]
crq.c:2333: error: nested extern declaration of '_gnutls_hash' [-Wnested-externs]

/Simon




From nmav at gnutls.org  Tue Dec  1 14:48:20 2009
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 1 Dec 2009 15:48:20 +0200
Subject: missing file
In-Reply-To: <874ooaeu8e.fsf@mocca.josefsson.org>
References: <878wdpzbel.fsf@mocca.josefsson.org> <4B12F5D9.3060603@gnutls.org>
	<874ooaeu8e.fsf@mocca.josefsson.org>
Message-ID: <c331d99a0912010548k17921989n44799079f7ac1b42@mail.gmail.com>

On Tue, Dec 1, 2009 at 2:47 PM, Simon Josefsson <simon at josefsson.org> wrote:
> Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:
>
>> Simon Josefsson wrote:
>>> Nikos, did you forget to commit some file?
>>>
>>> cryptodev.c:29:30: error: crypto/cryptodev.h: No such file or directory
>>
>> It was including this file unconditionally. Now it should be ok (only
>> included if --enable-cryptodev is specified). If you have a cpu with
>> crypto accelerator that is supported by linux (via and some amd geode
>> cpus have), and you use cryptodev you should get quite a difference. For
>> some reason I get big difference by using the kernel aes implementation.
>
> Any links to the cryptodev.h stuff? ?Any pointers on how to enable it on
> Debian would be useful, I can't seem to find anything.

The cryptodev for linux module is at:
http://www.logix.cz/michal/devel/cryptodev/
(note that it may not install the crypto/cryptodev.h correctly, thus you might
need to copy it by yourself).

> I see you made changes to the public header files, several of those
> changes appears backwards incompatible -- that will break ABI
> compatibility, which isn't a good idea. ?Are these changes necessary?
> If they are, and we really want to deprecate the old interfaces, we need
> compatibility functions defined somewhere, and prototypes for them in
> gnutls/compat.h. ?Please also write a NEWS blurb for these API changes.

I will but I need more time to finish this. I might change more stuff.
ABI compatibility on the crypto.h is not really an issue- the new code
can know whether the old abi is used an return an error.

> Building fails for me right now:
> crq.c: In function 'rsadsa_crq_get_key_id':
> crq.c:2333: error: implicit declaration of function '_gnutls_hash' [-Wimplicit-function-declaration]
> crq.c:2333: error: nested extern declaration of '_gnutls_hash' [-Wnested-externs]

I will check it later, probably some header is missing.

regards,
Nikos




From nmav at gnutls.org  Tue Dec  1 22:31:48 2009
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 01 Dec 2009 23:31:48 +0200
Subject: rfc5081bis
Message-ID: <4B158B44.90707@gnutls.org>

Hello,
 Due to some procedural issues [0] it is not possible to publish
RFC5081bis as independent submission. My last draft it at [1]. I have
tried to publish it as AD-sponsored but the area director refuses to
publish it as informational. I see no reason to publish it again as
experimental, thus I give up. Is any of you interested in adopting this
document?

best regards,
Nikos


[0]. An independently submitted draft cannot obsolete a TLS WG rfc.
[1]. http://tools.ietf.org/html/draft-mavrogiannopoulos-rfc5081bis-04




From dkg at fifthhorseman.net  Tue Dec  1 23:49:41 2009
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 01 Dec 2009 17:49:41 -0500
Subject: rfc5081bis
In-Reply-To: <4B158B44.90707@gnutls.org>
References: <4B158B44.90707@gnutls.org>
Message-ID: <4B159D85.1020904@fifthhorseman.net>

Hi Nikos--

On 12/01/2009 04:31 PM, Nikos Mavrogiannopoulos wrote:
>  Due to some procedural issues [0] it is not possible to publish
> RFC5081bis as independent submission. My last draft it at [1]. I have
> tried to publish it as AD-sponsored but the area director refuses to
> publish it as informational. I see no reason to publish it again as
> experimental, thus I give up. Is any of you interested in adopting this
> document?

I don't know enough about the process in general or the history of this
specific draft to be able to push it forward, though i'm interested in
seeing it formalized.  Presumably, the way around the procedural issues
is to get the TLS WG to approve it, no?

Actually, it looks like 5081 was not a TLS WG RFC -- it shows up as a
"Network Working Group" RFC here, anyway:

  http://tools.ietf.org/html/rfc5081

so now i guess i'm even more confused ;)  Can you explain?

Also, is there source for this draft?  Are you working on it in plain
text, or are you using the xml2rfc workflow?

Thanks for your work on this so far, Nikos!

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 891 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20091201/974329b4/attachment.pgp>

From nmav at gnutls.org  Wed Dec  2 07:15:46 2009
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 02 Dec 2009 08:15:46 +0200
Subject: rfc5081bis
In-Reply-To: <4B159D85.1020904@fifthhorseman.net>
References: <4B158B44.90707@gnutls.org> <4B159D85.1020904@fifthhorseman.net>
Message-ID: <4B160612.5080303@gnutls.org>

Daniel Kahn Gillmor wrote:
> Hi Nikos--
> 
> On 12/01/2009 04:31 PM, Nikos Mavrogiannopoulos wrote:
>>  Due to some procedural issues [0] it is not possible to publish
>> RFC5081bis as independent submission. My last draft it at [1]. I have
>> tried to publish it as AD-sponsored but the area director refuses to
>> publish it as informational. I see no reason to publish it again as
>> experimental, thus I give up. Is any of you interested in adopting this
>> document?
> 
> I don't know enough about the process in general or the history of this
> specific draft to be able to push it forward, though i'm interested in
> seeing it formalized.  Presumably, the way around the procedural issues
> is to get the TLS WG to approve it, no?

Yes. The way to achieve that is to have people support it from the WG.

> Actually, it looks like 5081 was not a TLS WG RFC -- it shows up as a
> "Network Working Group" RFC here, anyway:

No it is a TLS WG. I don't know the network working group header but it
seems all TLS WG documents have it. Check:
http://www.ietf.org/dyn/wg/charter/tls-charter.html
for the TLS WG documents.

> Also, is there source for this draft?  Are you working on it in plain
> text, or are you using the xml2rfc workflow?

I attached you in personal.

regards,
Nikos




From dkg at fifthhorseman.net  Wed Dec  2 08:21:18 2009
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 02 Dec 2009 02:21:18 -0500
Subject: rfc5081bis
In-Reply-To: <4B160612.5080303@gnutls.org>
References: <4B158B44.90707@gnutls.org> <4B159D85.1020904@fifthhorseman.net>
	<4B160612.5080303@gnutls.org>
Message-ID: <4B16156E.5070406@fifthhorseman.net>

On 12/02/2009 01:15 AM, Nikos Mavrogiannopoulos wrote:
> Yes. The way to achieve that is to have people support it from the WG.

OK, and what is the current consensus of that WG about 5081bis?  can you
give me some pointers to discussion to read?  I only just subscribed to
the TLS WG today, and the recent archives are understandably flooded
with dealing with mitigation of the renegotiation flaw.

> No it is a TLS WG. I don't know the network working group header but it
> seems all TLS WG documents have it. Check:
> http://www.ietf.org/dyn/wg/charter/tls-charter.html
> for the TLS WG documents.

ah, ok.  thanks for clearing that up.

> I attached you in personal.

got it, thanks.  i'm looking it over now.  any reason to believe that
the source itself should not be public?  If i was going to take this
over and drive it, are there any licensing/copyright concerns i would
need to be aware of?

Regards,

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 891 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20091202/37a59c67/attachment.pgp>

From nmav at gnutls.org  Wed Dec  2 10:23:03 2009
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 2 Dec 2009 11:23:03 +0200
Subject: rfc5081bis
In-Reply-To: <4B16156E.5070406@fifthhorseman.net>
References: <4B158B44.90707@gnutls.org> <4B159D85.1020904@fifthhorseman.net>
	<4B160612.5080303@gnutls.org> <4B16156E.5070406@fifthhorseman.net>
Message-ID: <c331d99a0912020123p1ac52926hd8d12aa284e8d805@mail.gmail.com>

On Wed, Dec 2, 2009 at 9:21 AM, Daniel Kahn Gillmor
<dkg at fifthhorseman.net> wrote:

> OK, and what is the current consensus of that WG about 5081bis? ?can you
> give me some pointers to discussion to read? ?I only just subscribed to
> the TLS WG today, and the recent archives are understandably flooded
> with dealing with mitigation of the renegotiation flaw.
For RFC5081bis there wasn't any discussion since it was independent
submission. You can find discussion about the old RFC5081 at
http://www.imc.org/ietf-tls/mail-archive/mail12.html
and over older at:
http://www.imc.org/ietf-tls/mail-archive/mail16.html

> got it, thanks. ?i'm looking it over now. ?any reason to believe that
> the source itself should not be public? ?If i was going to take this
> over and drive it, are there any licensing/copyright concerns i would
> need to be aware of?

No not really, i just sent it in personal to reduce data on list.

regards,
Nikos




From lfinsto at gwdg.de  Wed Dec  2 15:54:18 2009
From: lfinsto at gwdg.de (lfinsto at gwdg.de)
Date: Wed, 2 Dec 2009 15:54:18 +0100 (CET)
Subject: Git repository --- build errors
Message-ID: <52027.134.76.5.25.1259765658.squirrel@mailbox.gwdg.de>

Hello,

I managed to build the package from the git repository at Savannah, but I
had to fix several errors:

1.

cryptodev.c:46: error: 'EALG_MAX_BLOCK_LEN' undeclared here (not in a
function)

I solved this by adding this line in `cryptodev.c':

#define EALG_MAX_BLOCK_LEN 16

I don't think this is a very clean or safe solution.  Does anyone know
where it's supposed to be defined?

2.

serv.c:1170: error: cast to pointer from integer of different size
[-Wint-to-pointer-cast]

Solved by calling `configure' with the option `--enable_gcc_warnings=no',
then calling `make' again.

The problem is in the last line of this code:

gnutls_transport_set_ptr (tls_session,
                          (gnutls_transport_ptr_t)
			   gl_fd_to_handle (accept_fd));

I tried various things which didn't work before calling `configure' again
as above, but didn't go into the problem very thoroughly.  It seems to
involve `_get_osfhandle()'.

3.

/home/lfinsto/gnutls/doc//gnutls.texi:4077: Cross reference to nonexistent
node `gnutls_crypto_digest_register2' (perhaps incorrect sectioning?).
/home/lfinsto/gnutls/doc//gnutls.texi:4053: Cross reference to nonexistent
node `gnutls_crypto_single_mac_register2' (perhaps incorrect sectioning?).

Solved by commenting-out these lines in `gnutls.texi'.

I hope this report is useful.

There's another thing which may or may not be an issue from the point of
view of the GNUTLS developers:  I usually program in C++ and I've been
using code from the samples in the documentation and compiling with g++. 
Several times I've had to add explicit casts of pointers where C doesn't
require them but C++ does.  Not wishing to interfere in something that's
not my business, but I thought I'd mention this in case the developers
think that compatibility with C++ would be desirable.

Laurence


Laurence Finston
Gesellschaft fuer wissenschaftliche Datenverarbeitung mbH
Am Fassberg 11
37077 Goettingen

Telefon: 	+49 551 201-1882
E-Mail: 	lfinsto at gwdg.de





From nmav at gnutls.org  Wed Dec  2 21:55:39 2009
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 02 Dec 2009 22:55:39 +0200
Subject: Git repository --- build errors
In-Reply-To: <52027.134.76.5.25.1259765658.squirrel@mailbox.gwdg.de>
References: <52027.134.76.5.25.1259765658.squirrel@mailbox.gwdg.de>
Message-ID: <4B16D44B.8020001@gnutls.org>

lfinsto at gwdg.de wrote:
> Hello,
> 
> I managed to build the package from the git repository at Savannah, but I
> had to fix several errors:
> 
> 1.
> cryptodev.c:46: error: 'EALG_MAX_BLOCK_LEN' undeclared here (not in a
> function)

Hi,
 I'm curious which system is that? Could you send me your cryptodev.h?
(now by default cryptodev shouldn't be used unless specified in configure)

> 3.
> 
> /home/lfinsto/gnutls/doc//gnutls.texi:4077: Cross reference to nonexistent
> node `gnutls_crypto_digest_register2' (perhaps incorrect sectioning?).
> /home/lfinsto/gnutls/doc//gnutls.texi:4053: Cross reference to nonexistent
> node `gnutls_crypto_single_mac_register2' (perhaps incorrect sectioning?).
> 
> Solved by commenting-out these lines in `gnutls.texi'.

This should be fixed by now.


> I hope this report is useful.

Indeed!

> There's another thing which may or may not be an issue from the point of
> view of the GNUTLS developers:  I usually program in C++ and I've been
> using code from the samples in the documentation and compiling with g++. 
> Several times I've had to add explicit casts of pointers where C doesn't
> require them but C++ does.  Not wishing to interfere in something that's
> not my business, but I thought I'd mention this in case the developers
> think that compatibility with C++ would be desirable.

Do you use the C++ compatibility API or do you call the C functions
directly? Currently the idea is to have the C api, and the alternative
C++ API, to be used by C++ applications.

regards,
Nikos




From lfinsto at gwdg.de  Thu Dec  3 11:18:55 2009
From: lfinsto at gwdg.de (lfinsto at gwdg.de)
Date: Thu, 3 Dec 2009 11:18:55 +0100 (CET)
Subject: Git repository --- build errors
In-Reply-To: <4B16D44B.8020001@gnutls.org>
References: <52027.134.76.5.25.1259765658.squirrel@mailbox.gwdg.de>   
	<4B16D44B.8020001@gnutls.org>
Message-ID: <46568.134.76.5.25.1259835535.squirrel@mailbox.gwdg.de>

"Nikos Mavrogiannopoulos" <nmav at gnutls.org> wrote:

>  I'm curious which system is that?

It's a Dell Precision T3400.

uname -a
-->
Linux pcfinston 2.6.27.29-0.1-default #1 SMP 2009-08-15 17:53:59 +0200
x86_64 x86_64 x86_64 GNU/Linux

> Could you send me your cryptodev.h?
> (now by default cryptodev shouldn't be used unless specified in
configure)

I've attached it. I got it from here:

http://www.logix.cz/michal/devel/cryptodev/cryptodev-20091126/

("module" for Linux kernel 2.6.27+)

> Do you use the C++ compatibility API or do you call the C functions
directly? Currently the idea is to have the C api, and the alternative
C++ API, to be used by C++ applications.

I use the C API.  I prefer to use C APIs where present rather than C++ APIs.



Thanks,

Laurence


Laurence Finston
Gesellschaft fuer wissenschaftliche Datenverarbeitung mbH
Am Fassberg 11
37077 Goettingen

Telefon: 	+49 551 201-1882
E-Mail: 	lfinsto at gwdg.de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: cryptodev.h
Type: text/x-chdr
Size: 3128 bytes
Desc: not available
URL: </pipermail/attachments/20091203/16973374/attachment.h>

From simon at josefsson.org  Thu Dec  3 14:59:12 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 03 Dec 2009 14:59:12 +0100
Subject: missing file
In-Reply-To: <c331d99a0912010548k17921989n44799079f7ac1b42@mail.gmail.com>
	(Nikos Mavrogiannopoulos's message of "Tue, 1 Dec 2009 15:48:20
	+0200")
References: <878wdpzbel.fsf@mocca.josefsson.org> <4B12F5D9.3060603@gnutls.org>
	<874ooaeu8e.fsf@mocca.josefsson.org>
	<c331d99a0912010548k17921989n44799079f7ac1b42@mail.gmail.com>
Message-ID: <87d42wf9an.fsf@mocca.josefsson.org>

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> On Tue, Dec 1, 2009 at 2:47 PM, Simon Josefsson <simon at josefsson.org> wrote:
>> Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:
>>
>>> Simon Josefsson wrote:
>>>> Nikos, did you forget to commit some file?
>>>>
>>>> cryptodev.c:29:30: error: crypto/cryptodev.h: No such file or directory
>>>
>>> It was including this file unconditionally. Now it should be ok (only
>>> included if --enable-cryptodev is specified). If you have a cpu with
>>> crypto accelerator that is supported by linux (via and some amd geode
>>> cpus have), and you use cryptodev you should get quite a difference. For
>>> some reason I get big difference by using the kernel aes implementation.
>>
>> Any links to the cryptodev.h stuff? ?Any pointers on how to enable it on
>> Debian would be useful, I can't seem to find anything.
>
> The cryptodev for linux module is at:
> http://www.logix.cz/michal/devel/cryptodev/
> (note that it may not install the crypto/cryptodev.h correctly, thus you might
> need to copy it by yourself).

Thanks!  My debian kernel doesn't have /dev/crytpo, so I'll think I'll
defer testing this for a while...

>> I see you made changes to the public header files, several of those
>> changes appears backwards incompatible -- that will break ABI
>> compatibility, which isn't a good idea. ?Are these changes necessary?
>> If they are, and we really want to deprecate the old interfaces, we need
>> compatibility functions defined somewhere, and prototypes for them in
>> gnutls/compat.h. ?Please also write a NEWS blurb for these API changes.
>
> I will but I need more time to finish this. I might change more stuff.
> ABI compatibility on the crypto.h is not really an issue- the new code
> can know whether the old abi is used an return an error.

ABI compatibility is always an issue, we cannot remove any existing
interfaces unless we bump the ABI version (and that will cause a
significant amount of pain for packagers so let's not).  So please add
compatibility hooks for everything that was removed.

Maybe the cryptodev stuff should be developed on a branch until your new
crypto.h ABI has stabilized, if you are thinking of changing more
things?  I was thinking of making a GnuTLS 2.10.x release with official
stable support for TLS 1.2 soon, and the 2.9.x branch was relatively
stable before these changes.

>> Building fails for me right now:
>> crq.c: In function 'rsadsa_crq_get_key_id':
>> crq.c:2333: error: implicit declaration of function '_gnutls_hash' [-Wimplicit-function-declaration]
>> crq.c:2333: error: nested extern declaration of '_gnutls_hash' [-Wnested-externs]
>
> I will check it later, probably some header is missing.

That was fixed, but git trunk still doesn't build for me:

compat.c:35: error: no previous prototype for 'gnutls_crypto_single_mac_register2' [-Wmissing-prototypes]
compat.c:40: error: no previous prototype for 'gnutls_crypto_mac_register2' [-Wmissing-prototypes]

/Simon




From nmav at gnutls.org  Thu Dec  3 16:17:15 2009
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 3 Dec 2009 17:17:15 +0200
Subject: missing file
In-Reply-To: <87d42wf9an.fsf@mocca.josefsson.org>
References: <878wdpzbel.fsf@mocca.josefsson.org> <4B12F5D9.3060603@gnutls.org>
	<874ooaeu8e.fsf@mocca.josefsson.org>
	<c331d99a0912010548k17921989n44799079f7ac1b42@mail.gmail.com>
	<87d42wf9an.fsf@mocca.josefsson.org>
Message-ID: <c331d99a0912030717kb922b1bh6bc4074761663bb@mail.gmail.com>

On Thu, Dec 3, 2009 at 3:59 PM, Simon Josefsson <simon at josefsson.org> wrote:
> Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:
>
>> The cryptodev for linux module is at:
>> http://www.logix.cz/michal/devel/cryptodev/
>> (note that it may not install the crypto/cryptodev.h correctly, thus you might
>> need to copy it by yourself).
>
> Thanks! ?My debian kernel doesn't have /dev/crytpo, so I'll think I'll
> defer testing this for a while...

I think you will wait for long then :) This is an OpenBSD and FreeBSD
interface, I don't know when and if will ever be added to linux
(except for the external patch mentioned above).

>> I will but I need more time to finish this. I might change more stuff.
>> ABI compatibility on the crypto.h is not really an issue- the new code
>> can know whether the old abi is used an return an error.
> ABI compatibility is always an issue, we cannot remove any existing
> interfaces unless we bump the ABI version (and that will cause a
> significant amount of pain for packagers so let's not). ?So please add
> compatibility hooks for everything that was removed.

The ABI is part of the API in register functions of crypto.h. It is
different than the other parts of gnutls since you explicitly specify
the ABI version in the calls. Thus ABI is not breaking with my changes
and the compat.c file.

> Maybe the cryptodev stuff should be developed on a branch until your new
> crypto.h ABI has stabilized, if you are thinking of changing more
> things? ?I was thinking of making a GnuTLS 2.10.x release with official
> stable support for TLS 1.2 soon, and the 2.9.x branch was relatively
> stable before these changes.

Maybe I should have elaborated on the changes that have occurred. Those are:
1. crypto API cleanup
2. cryptodev

The cleanup merged the MAC and HASH interfaces to a single one to
avoid code duplication and to allow future use of crypto acceleration
of hashes.

The cryptodev change uses kernel drivers for symmetric crypto
algorithms and is not enabled by default.

Both of the changes are currently stable.

(unrelated but I don't think there should be a release without the fix
for renegotiation.)

> compat.c:35: error: no previous prototype for 'gnutls_crypto_single_mac_register2' [-Wmissing-prototypes]
> compat.c:40: error: no previous prototype for 'gnutls_crypto_mac_register2' [-Wmissing-prototypes]

That is because you used -Wmissing-prototypes. Those are compatibility
functions to keep the ABI. I'll add prototypes later.

regards,
Nikos




From lfinsto at gwdg.de  Thu Dec  3 16:22:59 2009
From: lfinsto at gwdg.de (lfinsto at gwdg.de)
Date: Thu, 3 Dec 2009 16:22:59 +0100 (CET)
Subject: Warnings:  pointer size vs. integer size
Message-ID: <56438.134.76.5.25.1259853779.squirrel@mailbox.gwdg.de>

Hello,

I'm not sure if this will be of any use to you, but I'm sending it in
case it is.

In order to get rid of this warning:

ex-client1.c: In function ?main?:
ex-client1.c:81: warning: cast to pointer from integer of different size
mv -f .deps/ex-client1.Tpo .deps/ex-client1.Po

I've made the following changes in `gnutls/configure.ac' and
`gnutls/doc/examples/ex-client1.c', which I've attached:

In `configure.ac':

#### Added.  LDF 2009.12.03.

AC_CHECK_SIZEOF([int])
AC_CHECK_SIZEOF([long int])
AC_CHECK_SIZEOF([void*])

#### End of added code.  LDF 2009.12.03.

In `gnutls/doc/examples/ex-client1.c':

Before `main':

/* Added.  LDF 2009.12.03.  */

#if (SIZEOF_VOIDP == SIZEOF_INT)
#define PTR_SIZE_INT
#undef  PTR_SIZE_LONG
#undef PTR_SIZE_UNDEFINED
#elif (SIZEOF_VOIDP == SIZEOF_LONG_INT)
#define PTR_SIZE_LONG
#undef  PTR_SIZE_INT
#undef PTR_SIZE_UNDEFINED
#else
#define PTR_SIZE_UNDEFINED
#undef PTR_SIZE_INT
#undef PTR_SIZE_LONG
#endif

/* End of added code.  LDF 2009.12.03.  */

I would have liked `configure' to write this to `config.h', but
I don't know how to get it to do it and I don't have time at the
moment to search through the manual to try to find out.

In `main':

/* Added conditionally compiled code.  LDF 2009.12.03.  */

#ifdef PTR_SIZE_LONG
  printf("PTR_SIZE_LONG is defined.\n");   /* Debugging output  */
  gnutls_transport_set_ptr (session, (gnutls_transport_ptr_t) ((long) sd));
#else
  printf("PTR_SIZE_LONG is undefined.\n");  /* Debugging output  */
  gnutls_transport_set_ptr (session, (gnutls_transport_ptr_t) sd);
#endif

/* End of added conditionally compiled code.  LDF 2009.12.03.  */

There are lots of other places where similar warnings occur.
(I was happy with 32 bit addresses, myself.)


Laurence
-------------- next part --------------
A non-text attachment was scrubbed...
Name: configure.ac
Type: application/octet-stream
Size: 9923 bytes
Desc: not available
URL: </pipermail/attachments/20091203/77715668/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ex-client1.c
Type: text/x-csrc
Size: 2801 bytes
Desc: not available
URL: </pipermail/attachments/20091203/77715668/attachment.c>

From lfinsto at gwdg.de  Thu Dec  3 16:59:19 2009
From: lfinsto at gwdg.de (lfinsto at gwdg.de)
Date: Thu, 3 Dec 2009 16:59:19 +0100 (CET)
Subject: Warnings:  pointer size vs. integer size
In-Reply-To: <56438.134.76.5.25.1259853779.squirrel@mailbox.gwdg.de>
References: <56438.134.76.5.25.1259853779.squirrel@mailbox.gwdg.de>
Message-ID: <42306.134.76.5.25.1259855959.squirrel@mailbox.gwdg.de>

I wrote:

[...]

> #if (SIZEOF_VOIDP == SIZEOF_INT)
> #define PTR_SIZE_INT
> #undef  PTR_SIZE_LONG

[...]

> #endif
>
> /* End of added code.  LDF 2009.12.03.  */
>
> I would have liked `configure' to write this to `config.h', but
> I don't know how to get it to do it and I don't have time at the
> moment to search through the manual to try to find out.

Apparently, one isn't supposed to do this.  The proper thing to do is to
put the code into another file and call `AH_BOTTOM([#include <filename>])'
in `configure.ac' (when using `autoheader').

Laurence


Laurence Finston
Gesellschaft fuer wissenschaftliche Datenverarbeitung mbH
Am Fassberg 11
37077 Goettingen

Telefon: 	+49 551 201-1882
E-Mail: 	lfinsto at gwdg.de





From andrew at mcdonald.org.uk  Thu Dec  3 21:22:23 2009
From: andrew at mcdonald.org.uk (Andrew McDonald)
Date: Thu, 3 Dec 2009 20:22:23 +0000
Subject: rfc5081bis
In-Reply-To: <4B160612.5080303@gnutls.org>
References: <4B158B44.90707@gnutls.org> <4B159D85.1020904@fifthhorseman.net>
	<4B160612.5080303@gnutls.org>
Message-ID: <20091203202223.GC17999@mcdonald.org.uk>

On Wed, Dec 02, 2009 at 08:15:46AM +0200, Nikos Mavrogiannopoulos wrote:
> > On 12/01/2009 04:31 PM, Nikos Mavrogiannopoulos wrote:
> >>  Due to some procedural issues [0] it is not possible to publish
> >> RFC5081bis as independent submission. My last draft it at [1]. I have
> >> tried to publish it as AD-sponsored but the area director refuses to
> >> publish it as informational. I see no reason to publish it again as
> >> experimental, thus I give up. Is any of you interested in adopting this
> >> document?

Do you know why the original RFC5081 was published as experimental
rather than standards track?

Are there independent interoperating implementations that could be used
as an indication that "RFC5081 had some issues, but is basically good
enough for standards track"? Otherwise reissue at experimental might be
the most appropriate route.

> > I don't know enough about the process in general or the history of this
> > specific draft to be able to push it forward, though i'm interested in
> > seeing it formalized.  Presumably, the way around the procedural issues
> > is to get the TLS WG to approve it, no?
> 
> Yes. The way to achieve that is to have people support it from the WG.

I didn't spot any mails that indicated that you've tried to initiate
any discussion on the TLS WG - that would be the obvious starting
point - "Here's a draft. It fixes these flaws in RFC5081. Any support
for taking up as a wg draft to update RFC5081?"

I've only the skimmed the draft - mainly the "Changes from RFC5081"
section. The immediately obvious concern is the "major and
incompatible" changes statement (though what happens if an RFC5081bis
endpoint tries to talk to an RFC5081 endpoint is not entirely clear to
me). Is there a way to make it compatible? (Even if it involves
defining a new certificate type?)

> > Actually, it looks like 5081 was not a TLS WG RFC -- it shows up as a
> > "Network Working Group" RFC here, anyway:
> 
> No it is a TLS WG. I don't know the network working group header but it
> seems all TLS WG documents have it. Check:
> http://www.ietf.org/dyn/wg/charter/tls-charter.html
> for the TLS WG documents.

"Network Working Group" is a historical thing - it was what the IETF
was before it became the IETF.

Andrew
-- 
Andrew McDonald
Contact details: admcd.tel
http://www.mcdonald.org.uk/andrew/




From nmav at gnutls.org  Fri Dec  4 00:57:15 2009
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 4 Dec 2009 01:57:15 +0200
Subject: missing file
In-Reply-To: <c331d99a0912030717kb922b1bh6bc4074761663bb@mail.gmail.com>
References: <878wdpzbel.fsf@mocca.josefsson.org> <4B12F5D9.3060603@gnutls.org>
	<874ooaeu8e.fsf@mocca.josefsson.org>
	<c331d99a0912010548k17921989n44799079f7ac1b42@mail.gmail.com>
	<87d42wf9an.fsf@mocca.josefsson.org>
	<c331d99a0912030717kb922b1bh6bc4074761663bb@mail.gmail.com>
Message-ID: <c331d99a0912031557l119e3f09g5f32bad447a746ad@mail.gmail.com>

> Maybe I should have elaborated on the changes that have occurred. Those are:
> 1. crypto API cleanup
>
> The cleanup merged the MAC and HASH interfaces to a single one to
> avoid code duplication and to allow future use of crypto acceleration
> of hashes.

And this is the thing that required the most changes in the code and
API. What do you think of this
merge? It makes the assumption that a hash can be an HMAC and vice
versa. Currently this saves
some duplicate code, but if this assumption is not correct the result
might be worse code. What do
you think?




From lfinsto at gwdg.de  Fri Dec  4 09:04:46 2009
From: lfinsto at gwdg.de (lfinsto at gwdg.de)
Date: Fri, 4 Dec 2009 09:04:46 +0100 (CET)
Subject: Warnings:  pointer size vs. integer size
In-Reply-To: <42306.134.76.5.25.1259855959.squirrel@mailbox.gwdg.de>
References: <56438.134.76.5.25.1259853779.squirrel@mailbox.gwdg.de>
	<42306.134.76.5.25.1259855959.squirrel@mailbox.gwdg.de>
Message-ID: <42717.134.76.5.25.1259913886.squirrel@mailbox.gwdg.de>

Just pulled the latest changes from the git repository and rebuilt the
package.  These are all the warnings I get from make:


   1003:fipsmd5.c:160: warning: initialization from incompatible pointer type
   1004:fipsmd5.c:162: warning: initialization from incompatible pointer type
   1005:fipsmd5.c:163: warning: initialization from incompatible pointer type
   1006:fipsmd5.c:164: warning: initialization from incompatible pointer type
   1634:serv.c:1171: warning: cast to pointer from integer of different size
   1642:cli.c:982: warning: cast to pointer from integer of different size
   1652:tls_test.c:265: warning: cast to pointer from integer of different
size
   1714:ex-client2.c:67: warning: cast to pointer from integer of
different size
   1720:ex-client-resume.c:62: warning: cast to pointer from integer of
different size
   1726:ex-cert-select.c:163: warning: cast to pointer from integer of
different size
   1736:ex-serv1.c:149: warning: cast to pointer from integer of different
size
   1742:ex-serv-export.c:197: warning: cast to pointer from integer of
different size
   1756:ex-serv-anon.c:118: warning: cast to pointer from integer of
different size
   1762:ex-client-tlsia.c:85: warning: cast to pointer from integer of
different size
   1768:ex-serv-pgp.c:132: warning: cast to pointer from integer of
different size
   1774:ex-client-psk.c:64: warning: cast to pointer from integer of
different size
   1780:ex-serv-psk.c:163: warning: cast to pointer from integer of
different size
   1786:ex-client-srp.c:67: warning: cast to pointer from integer of
different size
   1792:ex-serv-srp.c:123: warning: cast to pointer from integer of
different size

I think none of these is really a problem, except when warnings are
treated as errors.


Laurence




Laurence Finston
Gesellschaft fuer wissenschaftliche Datenverarbeitung mbH
Am Fassberg 11
37077 Goettingen

Telefon: 	+49 551 201-1882
E-Mail: 	lfinsto at gwdg.de





From lfinsto at gwdg.de  Fri Dec  4 11:04:23 2009
From: lfinsto at gwdg.de (lfinsto at gwdg.de)
Date: Fri, 4 Dec 2009 11:04:23 +0100 (CET)
Subject: Minor patch for the Texinfo manual
Message-ID: <44098.134.76.5.25.1259921063.squirrel@mailbox.gwdg.de>

Hello Simon,

Since I only have read access to the git repository I'm sending you this
minor patch to `gnutls.texi' (see below).

Though the manual is excellent, it contains quite a few grammatical
errors, as you probably know. In particular, there are many errors with
respect to the congruence of subject and verb in sentences.  As a native
speaker of English, it wouldn't be hard for me to correct them as I run
across them in the manual.  If you like, I'll be glad to do this.  The
easiest way would be to correct the Texinfo sources in a branch in the the
git repository, so you could check them before merging them, assuming the
copyright paperwork goes through.

Something I miss in the manual is `@deftypefn' entries and a "Data Types"
index.  I could make a start on writing them as I run across types that I
need to understand, if this would be of use to you.

Laurence



lfinsto at pcfinston:~/gnutls/doc> diff -Naur gnutls.texi gnutls.texi.new

-->

--- gnutls.texi	2009-12-03 11:20:44.000000000 +0100
+++ gnutls.texi.new	2009-12-04 10:52:07.000000000 +0100
@@ -1834,14 +1834,14 @@

 @table @code

- at item CERT_INVALID:
+ at item GNUTLS_CERT_INVALID:
 The certificate is not signed by one of the known authorities, or the
signature is invalid.

- at item CERT_REVOKED:
+ at item GNUTLS_CERT_REVOKED:
 The certificate has been revoked by its CA.

- at item CERT_SIGNER_NOT_FOUND:
+ at item GNUTLS_CERT_SIGNER_NOT_FOUND:
 The certificate's issuer is not known. This is the case when the
 issuer is not in the trusted certificates list.






Laurence Finston
Gesellschaft fuer wissenschaftliche Datenverarbeitung mbH
Am Fassberg 11
37077 Goettingen

Telefon: 	+49 551 201-1882
E-Mail: 	lfinsto at gwdg.de





From simon at josefsson.org  Fri Dec  4 11:55:36 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 04 Dec 2009 11:55:36 +0100
Subject: Minor patch for the Texinfo manual
In-Reply-To: <44098.134.76.5.25.1259921063.squirrel@mailbox.gwdg.de>
	(lfinsto@gwdg.de's message of "Fri, 4 Dec 2009 11:04:23 +0100 (CET)")
References: <44098.134.76.5.25.1259921063.squirrel@mailbox.gwdg.de>
Message-ID: <87einb57pz.fsf@mocca.josefsson.org>

lfinsto at gwdg.de writes:

> Hello Simon,
>
> Since I only have read access to the git repository I'm sending you this
> minor patch to `gnutls.texi' (see below).

Applied, thank you!

> Though the manual is excellent, it contains quite a few grammatical
> errors, as you probably know. In particular, there are many errors with
> respect to the congruence of subject and verb in sentences.  As a native
> speaker of English, it wouldn't be hard for me to correct them as I run
> across them in the manual.  If you like, I'll be glad to do this.

Yes this is very much appreciated, neither Nikos or me are native
English speakers so there is likely many errors in it.

> The easiest way would be to correct the Texinfo sources in a branch in
> the the git repository, so you could check them before merging them,
> assuming the copyright paperwork goes through.

I forget, did you already fill out the copyright assignment?  What's the
status of it?  If this is in process, I'll add you to the project on
savannah if you send me your savannah username -- but please don't
commit anything on any existing branch until the paperwork has been
completed.

> Something I miss in the manual is `@deftypefn' entries and a "Data Types"
> index.  I could make a start on writing them as I run across types that I
> need to understand, if this would be of use to you.

That would be great too.  Note that some of the manual is auto-generated
from the source code, so you may need to modify some script.

/Simon




From lfinsto at gwdg.de  Fri Dec  4 12:55:17 2009
From: lfinsto at gwdg.de (lfinsto at gwdg.de)
Date: Fri, 4 Dec 2009 12:55:17 +0100 (CET)
Subject: Minor patch for the Texinfo manual
In-Reply-To: <87einb57pz.fsf@mocca.josefsson.org>
References: <44098.134.76.5.25.1259921063.squirrel@mailbox.gwdg.de>
	<87einb57pz.fsf@mocca.josefsson.org>
Message-ID: <59565.134.76.5.25.1259927717.squirrel@mailbox.gwdg.de>

"Simon Josefsson" <simon at josefsson.org> wrote:
>
> I forget, did you already fill out the copyright assignment?

I filled out the email form and sent it to assign at gnu.org, but I haven't
heard anything yet.  My experience is that it takes a week or two for the
papers to get to Germany by post.  If I don't hear anything soon, I'll
write to the copyright clerk again.

> What's the
> status of it?  If this is in process, I'll add you to the project on
> savannah if you send me your savannah username -- but please don't
> commit anything on any existing branch until the paperwork has been
> completed.

My Savannah user name is lfinsto1.  I won't commit anything on an existing
branch until you say it's okay and the paperwork is done.

>
>> Something I miss in the manual is `@deftypefn' entries and a "Data
>> Types"
>> index.  I could make a start on writing them as I run across types that
>> I
>> need to understand, if this would be of use to you.
>
> That would be great too.  Note that some of the manual is auto-generated
> from the source code, so you may need to modify some script.

Okay, I'll have to look at how you do this.

I was saving these up so I don't send you too many tiny bug reports, but
as long as I'm writing:

The `char' arrays for DNs in a couple of functions from your sample
programs were too short for the DNs in my certificates, so nothing was
output:

In `print_x509_certificate_info':

Changed

  char dn[128];

to

  char dn[256];

Same in `verify_cert2':

 char name[64];

changed to

  char name[256];


Laurence



Laurence Finston
Gesellschaft fuer wissenschaftliche Datenverarbeitung mbH
Am Fassberg 11
37077 Goettingen

Telefon: 	+49 551 201-1882
E-Mail: 	lfinsto at gwdg.de





From simon at josefsson.org  Fri Dec  4 13:09:05 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 04 Dec 2009 13:09:05 +0100
Subject: Minor patch for the Texinfo manual
In-Reply-To: <59565.134.76.5.25.1259927717.squirrel@mailbox.gwdg.de>
	(lfinsto@gwdg.de's message of "Fri, 4 Dec 2009 12:55:17 +0100 (CET)")
References: <44098.134.76.5.25.1259921063.squirrel@mailbox.gwdg.de>
	<87einb57pz.fsf@mocca.josefsson.org>
	<59565.134.76.5.25.1259927717.squirrel@mailbox.gwdg.de>
Message-ID: <87ocmf2b6m.fsf@mocca.josefsson.org>

lfinsto at gwdg.de writes:

>> What's the
>> status of it?  If this is in process, I'll add you to the project on
>> savannah if you send me your savannah username -- but please don't
>> commit anything on any existing branch until the paperwork has been
>> completed.
>
> My Savannah user name is lfinsto1.  I won't commit anything on an existing
> branch until you say it's okay and the paperwork is done.

Added, welcome on board!

/Simon




From simon at josefsson.org  Fri Dec  4 13:39:42 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 04 Dec 2009 13:39:42 +0100
Subject: Minor patch for the Texinfo manual
In-Reply-To: <59565.134.76.5.25.1259927717.squirrel@mailbox.gwdg.de>
	(lfinsto@gwdg.de's message of "Fri, 4 Dec 2009 12:55:17 +0100 (CET)")
References: <44098.134.76.5.25.1259921063.squirrel@mailbox.gwdg.de>
	<87einb57pz.fsf@mocca.josefsson.org>
	<59565.134.76.5.25.1259927717.squirrel@mailbox.gwdg.de>
Message-ID: <87d42u3oc1.fsf@mocca.josefsson.org>

lfinsto at gwdg.de writes:

>>> Something I miss in the manual is `@deftypefn' entries and a "Data
>>> Types"
>>> index.  I could make a start on writing them as I run across types that
>>> I
>>> need to understand, if this would be of use to you.
>>
>> That would be great too.  Note that some of the manual is auto-generated
>> from the source code, so you may need to modify some script.
>
> Okay, I'll have to look at how you do this.
>
> I was saving these up so I don't send you too many tiny bug reports, but
> as long as I'm writing:
>
> The `char' arrays for DNs in a couple of functions from your sample
> programs were too short for the DNs in my certificates, so nothing was
> output:
>
> In `print_x509_certificate_info':
>
> Changed
>
>   char dn[128];
>
> to
>
>   char dn[256];
>
> Same in `verify_cert2':
>
>  char name[64];
>
> changed to
>
>   char name[256];

Hm, that example is obsoleted by gnutls_x509_crt_print.  I have improved
it slightly.

/Simon




From nmav at gnutls.org  Sat Dec  5 23:07:40 2009
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 06 Dec 2009 00:07:40 +0200
Subject: rfc5081bis
In-Reply-To: <20091203202223.GC17999@mcdonald.org.uk>
References: <4B158B44.90707@gnutls.org>
	<4B159D85.1020904@fifthhorseman.net>	<4B160612.5080303@gnutls.org>
	<20091203202223.GC17999@mcdonald.org.uk>
Message-ID: <4B1AD9AC.80709@gnutls.org>

Andrew McDonald wrote:

> Do you know why the original RFC5081 was published as experimental
> rather than standards track?
> Are there independent interoperating implementations that could be used
> as an indication that "RFC5081 had some issues, but is basically good
> enough for standards track"? Otherwise reissue at experimental might be
> the most appropriate route.

Hello Andrew,
 Indeed if that was the product of the TLS WG then experimental could be
the status. However this was an individual submission of a description
of existing protocol, thus I believe informational was the appropriate
status.

> I didn't spot any mails that indicated that you've tried to initiate
> any discussion on the TLS WG - that would be the obvious starting
> point - "Here's a draft. It fixes these flaws in RFC5081. Any support
> for taking up as a wg draft to update RFC5081?"

When I first published the rc5081bis update the chair notified me that I
should submit it independently since there was not much interest from
the WG. I also felt the same and continued with the independent submission.

> I've only the skimmed the draft - mainly the "Changes from RFC5081"
> section. The immediately obvious concern is the "major and
> incompatible" changes statement (though what happens if an RFC5081bis
> endpoint tries to talk to an RFC5081 endpoint is not entirely clear to
> me). Is there a way to make it compatible? (Even if it involves
> defining a new certificate type?)

The two protocols are incompatible. Compatibility should be possible but
I saw no reason to keep it back then since gnutls is still the only
implementation.

best regards,
Nikos




From nmav at gnutls.org  Sun Dec  6 10:00:09 2009
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 06 Dec 2009 11:00:09 +0200
Subject: Warnings:  pointer size vs. integer size
In-Reply-To: <42717.134.76.5.25.1259913886.squirrel@mailbox.gwdg.de>
References: <56438.134.76.5.25.1259853779.squirrel@mailbox.gwdg.de>	<42306.134.76.5.25.1259855959.squirrel@mailbox.gwdg.de>
	<42717.134.76.5.25.1259913886.squirrel@mailbox.gwdg.de>
Message-ID: <4B1B7299.50709@gnutls.org>

lfinsto at gwdg.de wrote:
> Just pulled the latest changes from the git repository and rebuilt the
> package.  These are all the warnings I get from make:
> 
> 
>    1003:fipsmd5.c:160: warning: initialization from incompatible pointer type
>    1004:fipsmd5.c:162: warning: initialization from incompatible pointer type
>    1005:fipsmd5.c:163: warning: initialization from incompatible pointer type
>    1006:fipsmd5.c:164: warning: initialization from incompatible pointer type

At least those should have been fixed.

>    1634:serv.c:1171: warning: cast to pointer from integer of different size
>    1642:cli.c:982: warning: cast to pointer from integer of different size

Those are harmless but nevertheless we have not been able to eliminate them.

regards,
Nikos




From lfinsto at gwdg.de  Wed Dec  9 15:06:57 2009
From: lfinsto at gwdg.de (lfinsto at gwdg.de)
Date: Wed, 9 Dec 2009 15:06:57 +0100 (CET)
Subject: Handshake and verification
Message-ID: <52943.134.76.5.25.1260367617.squirrel@mailbox.gwdg.de>

Hello,

I've been working on my client-server pair with X.509 authentication,
using the code from the examples in the manuals.  I've put the code for
handling the connections into a (POSIX) thread function, i.e., one passed
to `pthread_create'.  In order to test this, I've made it possible to call
the client with a `--sleep' argument to put it to sleep for a few seconds.
 I call it several times and put it into the background, so several
clients can be running and connected to the server at the same time.

I got this error:

optdbsrv: ath.c:186: _gcry_ath_mutex_lock: Assertion `*lock ==
((ath_mutex_t) 0)' failed.
Aborted

I was able to fix it by locking and unlocking a mutex before and after the
call to `gnutls_handshake'.

I have determined that I don't have the file `ath.c' on my system, so I
will have to download the source distribution of `libgcrypt'.  It would be
nicer if one didn't have to lock and unlock a mutex.  If it can't be
avoided, perhaps it would be good to document this. (I'll glad to do this
myself, if I can).

I think my server-client pair would make a good example and test case, but
I need to discuss some things with my employer regarding copyright,
permission to publish, etc., and I also haven't gotten the papers from the
FSF yet.

I've tried downloading the sources from the git repository using the
method for developers, but it didn't work.  Perhaps I need to register a
public key somewhere;  I haven't had a chance to try to find out what I
need to do yet.

*********************

This is my workaround for handling proxy certificates (based on example
from manual and modified):

 /* Do the actual verification.  */

  gnutls_x509_crt_verify (crt, &issuer, 1, 0, &output);

if (output & GNUTLS_CERT_INVALID)
    {
      if (output & GNUTLS_CERT_SIGNER_NOT_FOUND)
      {
        fprintf (stderr, "Not trusted");
        fprintf (stderr, ": no issuer was found");
      }

      if (output & GNUTLS_CERT_SIGNER_NOT_CA)
      {
        fprintf (stderr, "Trusted");
        fprintf (stderr, ": issuer is not a CA\n");
        fprintf (stderr, "This isn't so important, the previous
certificate might be a proxy.");
      }
      fprintf (stderr, "\n");
    }
  else
    fprintf (stderr, "Trusted\n");

It would be neater if `GNUTLS_CERT_INVALID' wasn't necessarily true just
because `GNUTLS_CERT_SIGNER_NOT_CA' is, but it doesn't really cause any
harm.  If anyone implements any special handling for proxy certificates,
please let me know so I can test them.

Thanks,

Laurence

------------------------------------------------------------
Laurence Finston
Gesellschaft fuer wissenschaftliche Datenverarbeitung mbH
Am Fassberg 11
37077 Goettingen

Telefon: 	+49 551 201-1882
E-Mail: 	lfinsto at gwdg.de





From dkg at fifthhorseman.net  Wed Dec  9 15:51:44 2009
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 09 Dec 2009 09:51:44 -0500
Subject: thread safety in gnutls [was: Re: Handshake and verification]
In-Reply-To: <52943.134.76.5.25.1260367617.squirrel@mailbox.gwdg.de>
References: <52943.134.76.5.25.1260367617.squirrel@mailbox.gwdg.de>
Message-ID: <4B1FB980.5060100@fifthhorseman.net>

Hi Laurence--

On 12/09/2009 09:06 AM, lfinsto at gwdg.de wrote:
> I've been working on my client-server pair with X.509 authentication,
> using the code from the examples in the manuals.  I've put the code for
> handling the connections into a (POSIX) thread function, i.e., one passed
> to `pthread_create'.  In order to test this, I've made it possible to call
> the client with a `--sleep' argument to put it to sleep for a few seconds.
>  I call it several times and put it into the background, so several
> clients can be running and connected to the server at the same time.
> 
> I got this error:
> 
> optdbsrv: ath.c:186: _gcry_ath_mutex_lock: Assertion `*lock ==
> ((ath_mutex_t) 0)' failed.
> Aborted
> 
> I was able to fix it by locking and unlocking a mutex before and after the
> call to `gnutls_handshake'.

are you initializing gcrypt itself to be threadsafe in your
multithreaded program?

http://www.gnu.org/software/gnutls/manual/html_node/Multi_002dthreaded-applications.html

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 891 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20091209/06cd3931/attachment.pgp>

From lfinsto at gwdg.de  Wed Dec  9 16:29:58 2009
From: lfinsto at gwdg.de (lfinsto at gwdg.de)
Date: Wed, 9 Dec 2009 16:29:58 +0100 (CET)
Subject: thread safety in gnutls [was: Re: Handshake and verification]
In-Reply-To: <4B1FB980.5060100@fifthhorseman.net>
References: <52943.134.76.5.25.1260367617.squirrel@mailbox.gwdg.de>
	<4B1FB980.5060100@fifthhorseman.net>
Message-ID: <49133.134.76.5.25.1260372598.squirrel@mailbox.gwdg.de>


On Wed, December 9, 2009 3:51 pm, Daniel Kahn Gillmor wrote:
> On 12/09/2009 09:06 AM, lfinsto at gwdg.de wrote:

[...]

>> I got this error:
>>
>> optdbsrv: ath.c:186: _gcry_ath_mutex_lock: Assertion `*lock ==
>> ((ath_mutex_t) 0)' failed.
>> Aborted

[...]

> are you initializing gcrypt itself to be threadsafe in your
> multithreaded program?
>
> http://www.gnu.org/software/gnutls/manual/html_node/Multi_002dthreaded-applications.html

No, I had actually read this, but forgotten about it.  However, when I
tried it, i.e.,

#include <gnutls.h>
#include <gcrypt.h>
#include <errno.h>
#include <pthread.h>
GCRY_THREAD_OPTION_PTHREAD_IMPL;

int main()
{
   /* The order matters.  */
   gcry_control (GCRYCTL_SET_THREAD_CBS, &gcry_threads_pthread);
   gnutls_global_init();
}

I got this error from the call to `generate_rsa_params':

Ohhhh jeeee: operation is not possible without initialized secure memory
Aborted

I'll have to take a closer look at the documentation, and also get the
documentation to `libcrypt', since I don't know what this is about.

Thanks,

Laurence

-------------------------------------------------------------
Laurence Finston
Gesellschaft fuer wissenschaftliche Datenverarbeitung mbH
Am Fassberg 11
37077 Goettingen

Telefon: 	+49 551 201-1882
E-Mail: 	lfinsto at gwdg.de





From dkg at fifthhorseman.net  Wed Dec  9 16:45:58 2009
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 09 Dec 2009 10:45:58 -0500
Subject: thread safety in gnutls [was: Re: Handshake and verification]
In-Reply-To: <49133.134.76.5.25.1260372598.squirrel@mailbox.gwdg.de>
References: <52943.134.76.5.25.1260367617.squirrel@mailbox.gwdg.de>	<4B1FB980.5060100@fifthhorseman.net>
	<49133.134.76.5.25.1260372598.squirrel@mailbox.gwdg.de>
Message-ID: <4B1FC636.3050505@fifthhorseman.net>

On 12/09/2009 10:29 AM, lfinsto at gwdg.de wrote:
> No, I had actually read this, but forgotten about it.  However, when I
> tried it, i.e.,

 [...]

> I got this error from the call to `generate_rsa_params':
> 
> Ohhhh jeeee: operation is not possible without initialized secure memory
> Aborted

You're probably using a gcrypt version earlier than 1.4.3, when they
added a default initialization of secure memory.  Try adding the
following after the THREAD_CBS, but before the global_init to initialize
gcrypt's secure memory explicitly:

  gcry_control (GCRYCTL_SUSPEND_SECMEM_WARN);
  gcry_control (GCRYCTL_INIT_SECMEM, 32768, 0);
  gcry_control (GCRYCTL_RESUME_SECMEM_WARN);

for further reference, you can read here:

http://www.gnupg.org/documentation/manuals/gcrypt/Initializing-the-library.html

but unfortunately, the documentation for initializing gcrypt isn't
terribly clear.  I've asked for improved documentation on that recently,
but haven't gotten much of a response:

 http://lists.gnupg.org/pipermail/gcrypt-devel/2009-October/001504.html

I'm afraid i don't know the library well enough myself to write improved
documentation for it, though.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 891 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20091209/707bd7c4/attachment.pgp>

From lfinsto at gwdg.de  Wed Dec  9 16:58:38 2009
From: lfinsto at gwdg.de (lfinsto at gwdg.de)
Date: Wed, 9 Dec 2009 16:58:38 +0100 (CET)
Subject: thread safety in gnutls [was: Re: Handshake and verification]
In-Reply-To: <4B1FC636.3050505@fifthhorseman.net>
References: <52943.134.76.5.25.1260367617.squirrel@mailbox.gwdg.de>
	<4B1FB980.5060100@fifthhorseman.net>
	<49133.134.76.5.25.1260372598.squirrel@mailbox.gwdg.de>
	<4B1FC636.3050505@fifthhorseman.net>
Message-ID: <39426.134.76.5.25.1260374318.squirrel@mailbox.gwdg.de>


On Wed, December 9, 2009 4:45 pm, Daniel Kahn Gillmor wrote:
> On 12/09/2009 10:29 AM, lfinsto at gwdg.de wrote:
>> No, I had actually read this, but forgotten about it.  However, when I
>> tried it, i.e.,
>
>  [...]
>
> You're probably using a gcrypt version earlier than 1.4.3, when they
> added a default initialization of secure memory.  Try adding the
> following after the THREAD_CBS, but before the global_init to initialize
> gcrypt's secure memory explicitly:
>
>   gcry_control (GCRYCTL_SUSPEND_SECMEM_WARN);
>   gcry_control (GCRYCTL_INIT_SECMEM, 32768, 0);
>   gcry_control (GCRYCTL_RESUME_SECMEM_WARN);
>

It worked!  Thank you, and for the references.

Laurence







From dkg at fifthhorseman.net  Wed Dec  9 17:07:54 2009
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 09 Dec 2009 11:07:54 -0500
Subject: thread safety in gnutls [was: Re: Handshake and verification]
In-Reply-To: <39426.134.76.5.25.1260374318.squirrel@mailbox.gwdg.de>
References: <52943.134.76.5.25.1260367617.squirrel@mailbox.gwdg.de>	<4B1FB980.5060100@fifthhorseman.net>	<49133.134.76.5.25.1260372598.squirrel@mailbox.gwdg.de>	<4B1FC636.3050505@fifthhorseman.net>
	<39426.134.76.5.25.1260374318.squirrel@mailbox.gwdg.de>
Message-ID: <4B1FCB5A.5020008@fifthhorseman.net>

On 12/09/2009 10:58 AM, lfinsto at gwdg.de wrote:
> On Wed, December 9, 2009 4:45 pm, Daniel Kahn Gillmor wrote:
>>   gcry_control (GCRYCTL_SUSPEND_SECMEM_WARN);
>>   gcry_control (GCRYCTL_INIT_SECMEM, 32768, 0);
>>   gcry_control (GCRYCTL_RESUME_SECMEM_WARN);
> 
> It worked!  Thank you, and for the references.

great!  just to be clear: you were able to remove the mutex and the
locking that you had needed earlier, and the program now runs fine?  i
want to make sure that gnutls hasn't introduced any threadsafety issues
of its own.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 891 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20091209/fd5993b4/attachment.pgp>

From lfinsto at gwdg.de  Wed Dec  9 17:28:41 2009
From: lfinsto at gwdg.de (lfinsto at gwdg.de)
Date: Wed, 9 Dec 2009 17:28:41 +0100 (CET)
Subject: thread safety in gnutls [was: Re: Handshake and verification]
In-Reply-To: <4B1FCB5A.5020008@fifthhorseman.net>
References: <52943.134.76.5.25.1260367617.squirrel@mailbox.gwdg.de>
	<4B1FB980.5060100@fifthhorseman.net>
	<49133.134.76.5.25.1260372598.squirrel@mailbox.gwdg.de>
	<4B1FC636.3050505@fifthhorseman.net>
	<39426.134.76.5.25.1260374318.squirrel@mailbox.gwdg.de>
	<4B1FCB5A.5020008@fifthhorseman.net>
Message-ID: <42710.134.76.5.25.1260376121.squirrel@mailbox.gwdg.de>


On Wed, December 9, 2009 5:07 pm, Daniel Kahn Gillmor wrote:
> On 12/09/2009 10:58 AM, lfinsto at gwdg.de wrote:
>> On Wed, December 9, 2009 4:45 pm, Daniel Kahn Gillmor wrote:
>>>   gcry_control (GCRYCTL_SUSPEND_SECMEM_WARN);
>>>   gcry_control (GCRYCTL_INIT_SECMEM, 32768, 0);
>>>   gcry_control (GCRYCTL_RESUME_SECMEM_WARN);
>>
>> It worked!  Thank you, and for the references.
>
> great!  just to be clear: you were able to remove the mutex and the
> locking that you had needed earlier, and the program now runs fine?

Yes, it now works without locking the mutex (which I've removed entirely).

I'll try installing the newest version of the gcrypt library and removing
the code for explicitly initializing the secure memory, but I won't be
able to work on that today.


Laurence






From dkg at fifthhorseman.net  Wed Dec  9 17:34:57 2009
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 09 Dec 2009 11:34:57 -0500
Subject: thread safety in gnutls [was: Re: Handshake and verification]
In-Reply-To: <42710.134.76.5.25.1260376121.squirrel@mailbox.gwdg.de>
References: <52943.134.76.5.25.1260367617.squirrel@mailbox.gwdg.de>	<4B1FB980.5060100@fifthhorseman.net>	<49133.134.76.5.25.1260372598.squirrel@mailbox.gwdg.de>	<4B1FC636.3050505@fifthhorseman.net>	<39426.134.76.5.25.1260374318.squirrel@mailbox.gwdg.de>	<4B1FCB5A.5020008@fifthhorseman.net>
	<42710.134.76.5.25.1260376121.squirrel@mailbox.gwdg.de>
Message-ID: <4B1FD1B1.6080601@fifthhorseman.net>

On 12/09/2009 11:28 AM, lfinsto at gwdg.de wrote:
> Yes, it now works without locking the mutex (which I've removed entirely).

great.

> I'll try installing the newest version of the gcrypt library and removing
> the code for explicitly initializing the secure memory, but I won't be
> able to work on that today.

no worries. i think the gcrypt folks would rather that your app
explicitly initialized the secure memory anyway, rather than relying on
their default internal initialization.

the gcrypt NEWS file says:

Noteworthy changes in version 1.4.3 (2008-09-18)
------------------------------------------------

 * Try to auto-initialize Libgcrypt to minimize the effect of
   applications not doing that correctly.  This is not a perfect
   solution but given that many applicationion would totally fail
   without such a hack, we try to help at least with the most common
   cases.  Folks, please read the manual to learn how to properly
   initialize Libgcrypt!


Glad it's working for you now, anyway.

Regards,

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 891 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20091209/9e9ded54/attachment.pgp>

From kalee at monitorapp.com  Wed Dec 23 03:38:00 2009
From: kalee at monitorapp.com (Kyung a Lee)
Date: Wed, 23 Dec 2009 11:38:00 +0900
Subject: Question... about importing private key
Message-ID: <003301ca8378$f2440a60$d6cc1f20$@com>

Hi,

 

I wanna import x509 private key (RSA), but it returns -69,

I follow the sources, and found that occurred from asn1_create_element. In
this status, they 

Returns ASN1_ELEMENT_NOT_FOUND..

I used this funcs for parse private key:

   Gnutls_x509_privkey_init(&priv_key);

   Gnutls_x509_privkey_import(priv_key, &key, GNUTLS_X509_FMT_PEM)

 

And this is the contents of key file:

-----BEGIN RSA PRIVATE KEY-----

MIICXAIBAAKBgQC80PsdzO8ghbLAYRFsgzNLbHThfZ/s7akgiBgDnE/kFDO032Sl

MfidvuR9Y78wIhjOcRf8rufIZS1yanMATf2lZy2TqKdm7UGmwcf9ciUlISG4uwF4

NrZOYmPJPbVy6zf/bRLy5OFwijAIK/E3kC9wUhTB9j1wo/qUNrzeYVW5rQIDAQAB

AoGAU2I+46QzHjus+wRi+3bdWjulSkd+LtWt0O4JHN8U8PZy9zeIbOOqlY9NvIom

To1gQxryquZa+cak0VhtPP80Oess4umL4SFUCii7kH8/ReImP8aDUHritjg5GLZg

p7BqvYkLsmVWlq4TcYy4JPMkURy55MeLgNN0XHUsXsin9ckCQQDcmzwfXJ40EHt1

3XT3NqM3CreMefrKbRGIJ8cJgcApos+HtxTwHXalBwWW+MayUweasyRtlCaJqGLn

UpDRXZbHAkEA2xwP50ZolQ6/crbHAlZSxjHOdMlX1CwS6uerYiHZEH8cFZuX5HI1

0yr1mHnVIBVMs/VIZOf7Q+arkuEzmewn6wJAD5XP+485hggcEMmid8yeX0ccjIoZ

k69865eT0jIed1KPQtFGY2hRd3s1g+LzdqmzAdTiH/O1fUguJJWKsZ/hBQJBAJCZ

1XkJQ23TvM9FBtNpCtmX9yul0RvKNnXmjHmH4wv7BxrPg4+VPCZvfIOzK88vn15I

aw2E95MZQXP+waI8cx8CQFteO0k/kuUqpYYjjtTzFEjP2m4aB0aEhRx6cTJoK86g

05T+6QkBjdGhPKkLOoFtqZFO9qIZWvRvgKE081cMiLg=

-----END RSA PRIVATE KEY-----

 

Please reply , I really don?t know how to figure it out?

Have a nice day,

Thanks??. J

 

Gloria Lee.

 

========================================

?Kyung a Lee (? ? ?)

?Research&Development Div.                   

 

?MONITORAPP CO., LTD.

?306, Ace Techno Tower1, 197-17, Guro3-Dong, 

?Seoul, Korea 152-050

?Tel : 02-749-0799

?Fax : 02-749-0798

?Mobile : 010-2078-8137

?E-mail : kalee at monitorapp.com

========================================

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20091223/9976c94c/attachment.htm>

From nmav at gnutls.org  Wed Dec 23 16:07:19 2009
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 23 Dec 2009 17:07:19 +0200
Subject: Question... about importing private key
In-Reply-To: <003301ca8378$f2440a60$d6cc1f20$@com>
References: <003301ca8378$f2440a60$d6cc1f20$@com>
Message-ID: <4B323227.4070503@gnutls.org>

Kyung a Lee wrote:

Now it not that much of a private key :) Anyway I was able to parse it
with certtool -k and see its contents. Which version of gnutls do you use?

regards,
Nikos


> Hi,
> 
>  
> 
> I wanna import x509 private key (RSA), but it returns -69,
> 
> I follow the sources, and found that occurred from asn1_create_element. In
> this status, they 
> 
> Returns ASN1_ELEMENT_NOT_FOUND..
> 
> I used this funcs for parse private key:
> 
>    Gnutls_x509_privkey_init(&priv_key);
> 
>    Gnutls_x509_privkey_import(priv_key, &key, GNUTLS_X509_FMT_PEM)
> 
>  
> 
> And this is the contents of key file:
> 
> -----BEGIN RSA PRIVATE KEY-----
> 
> MIICXAIBAAKBgQC80PsdzO8ghbLAYRFsgzNLbHThfZ/s7akgiBgDnE/kFDO032Sl
> 
> MfidvuR9Y78wIhjOcRf8rufIZS1yanMATf2lZy2TqKdm7UGmwcf9ciUlISG4uwF4
> 
> NrZOYmPJPbVy6zf/bRLy5OFwijAIK/E3kC9wUhTB9j1wo/qUNrzeYVW5rQIDAQAB
> 
> AoGAU2I+46QzHjus+wRi+3bdWjulSkd+LtWt0O4JHN8U8PZy9zeIbOOqlY9NvIom
> 
> To1gQxryquZa+cak0VhtPP80Oess4umL4SFUCii7kH8/ReImP8aDUHritjg5GLZg
> 
> p7BqvYkLsmVWlq4TcYy4JPMkURy55MeLgNN0XHUsXsin9ckCQQDcmzwfXJ40EHt1
> 
> 3XT3NqM3CreMefrKbRGIJ8cJgcApos+HtxTwHXalBwWW+MayUweasyRtlCaJqGLn
> 
> UpDRXZbHAkEA2xwP50ZolQ6/crbHAlZSxjHOdMlX1CwS6uerYiHZEH8cFZuX5HI1
> 
> 0yr1mHnVIBVMs/VIZOf7Q+arkuEzmewn6wJAD5XP+485hggcEMmid8yeX0ccjIoZ
> 
> k69865eT0jIed1KPQtFGY2hRd3s1g+LzdqmzAdTiH/O1fUguJJWKsZ/hBQJBAJCZ
> 
> 1XkJQ23TvM9FBtNpCtmX9yul0RvKNnXmjHmH4wv7BxrPg4+VPCZvfIOzK88vn15I
> 
> aw2E95MZQXP+waI8cx8CQFteO0k/kuUqpYYjjtTzFEjP2m4aB0aEhRx6cTJoK86g
> 
> 05T+6QkBjdGhPKkLOoFtqZFO9qIZWvRvgKE081cMiLg=
> 
> -----END RSA PRIVATE KEY-----





From billr at neocat.org  Mon Dec 28 05:00:05 2009
From: billr at neocat.org (Bill Randle)
Date: Sun, 27 Dec 2009 20:00:05 -0800
Subject: bug: missing ifdef in lib/x509/mpi.c
Message-ID: <1261972805.6106.23.camel@neosoft.neocat.org>

mpi.c calls gnutls_x509_crq_get_pk_algorithm() without protecting the
function with a #ifdef ENABLE_PKI. As a result, the linker will complain
about an undefined reference if ENABLE_PKI is not defined.

This happens when building gnutls-2.8.5, cross-compiled for an embedded
arm system. Configure was run as follows:

./configure --prefix=/usr --host=arm-linux
--disable-openssl-compatibility --disable-openpgp-authentication
--disable-extra-pki --disable-camellia --disable-psk-authentication
--with-included-libtasn1 --with-gnu-ld --disable-gtk-doc-html
--disable-guile
--with-libgcrypt-prefix=/proj2/pvpowered/workspace/ltib/ltib/rootfs/usr

I haven't looked the code enough to know where to put the ifdef or the
side effects of adding an ifdef. A suggested patch would be appreciated.

	-Bill Randle
	billr at neocat.org






From billr at neocat.org  Mon Dec 28 05:54:26 2009
From: billr at neocat.org (Bill Randle)
Date: Sun, 27 Dec 2009 20:54:26 -0800
Subject: bug: lib/gnutlsxx.cpp missing various ENABLE_XXX ifdefs
Message-ID: <1261976066.7474.7.camel@neosoft.neocat.org>

I fixed my previous problem with the missing ifdef in mpi.c (see patch
below). A similar problem also exists in gnutlsxx.cpp where the only
ENABLE_XXX ifdefs are ENABLE_OPENPGP and ENABLE_SRP. There should also
be ifdefs for ENABLE_PKI and ENABLE_PSK (and perhaps others?).

	-Bill

P.S. I apologize if this has been reported already; I did look back
several months in the mailing list archives.

--- gnutls-2.8.5/lib/x509/mpi.c.dist	2009-06-02 11:59:32.000000000 -0700
+++ gnutls-2.8.5/lib/x509/mpi.c	2009-12-27 20:21:27.000000000 -0800
@@ -331,6 +331,8 @@
 		   params_size);
 }
 
+#ifdef ENABLE_PKI
+
 /* Extracts DSA and RSA parameters from a certificate.
  */
 int
@@ -348,6 +350,8 @@
 		   params_size);
 }
 
+#endif
+
 /*
  * some x509 certificate functions that relate to MPI parameter
  * setting. This writes the BIT STRING subjectPublicKey.