From mrsam at courier-mta.com  Fri Oct  1 00:08:00 2010
From: mrsam at courier-mta.com (Sam Varshavchik)
Date: Thu, 30 Sep 2010 18:08:00 -0400
Subject: Small issue on GnuTLS 2.10.2
References: <87zkuzd26y.fsf@mocca.josefsson.org>
	<996662C3-824F-4579-B23B-8FD8969AFF53@opencsw.org>
	<87y6aj9sri.fsf@mocca.josefsson.org> <4CA4B803.2070005@onetel.net>
	<alpine.DEB.2.00.1009301723570.11924@noise.cbg.collabora.co.uk>
	<alpine.DEB.2.00.1009301815370.11924@noise.cbg.collabora.co.uk>
Message-ID: <cone.1285884480.612917.27396.500@commodore.email-scan.com>

Vivek Dasmohapatra writes:

> On Thu, 30 Sep 2010, Vivek Dasmohapatra wrote:
> 
>> On Thu, 30 Sep 2010, Dr. David Kirkby wrote:
>>
>>>> Thanks, fixed.  I wish we could catch these with a GCC warning so you
>>>> don't have to run into them all the time...
>>
>> make sizeof
>> cc     sizeof.c   -o sizeof
>> sizeof.c: In function ?wfm?:
>> sizeof.c:11: warning: ?return? with a value, in function returning void
>>
>> tested wiith: gcc (Debian 4.4.3-3) 4.4.3
>>              gcc (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu4)
>>
>> Seems to warn just fine.
> 
> And you can crank up the pedantry even further with --pedantic,
> which will warn of a void expression return in a function
> with a void return signature.

And -Werror, which will make any warning fail the build.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: </pipermail/attachments/20100930/f0520013/attachment.pgp>

From simon at josefsson.org  Fri Oct  1 08:35:16 2010
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 01 Oct 2010 08:35:16 +0200
Subject: Small issue on GnuTLS 2.10.2
References: <87zkuzd26y.fsf@mocca.josefsson.org>
	<996662C3-824F-4579-B23B-8FD8969AFF53@opencsw.org>
	<87y6aj9sri.fsf@mocca.josefsson.org> <4CA4B803.2070005@onetel.net>
	<alpine.DEB.2.00.1009301723570.11924@noise.cbg.collabora.co.uk>
	<alpine.DEB.2.00.1009301815370.11924@noise.cbg.collabora.co.uk>
	<cone.1285884480.612917.27396.500@commodore.email-scan.com>
Message-ID: <8739sqzahn.fsf@mocca.josefsson.org>

Sam Varshavchik <mrsam at courier-mta.com> writes:

> Vivek Dasmohapatra writes:
>
>> On Thu, 30 Sep 2010, Vivek Dasmohapatra wrote:
>>
>>> On Thu, 30 Sep 2010, Dr. David Kirkby wrote:
>>>
>>>>> Thanks, fixed.  I wish we could catch these with a GCC warning so you
>>>>> don't have to run into them all the time...
>>>
>>> make sizeof
>>> cc     sizeof.c   -o sizeof
>>> sizeof.c: In function ?wfm?:
>>> sizeof.c:11: warning: ?return? with a value, in function returning void
>>>
>>> tested wiith: gcc (Debian 4.4.3-3) 4.4.3
>>>              gcc (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu4)
>>>
>>> Seems to warn just fine.

And sizeof.c looks how?  I don't think you tested our situation:

jas at mocca:~$ cat foo.c
void foo (void)
{
  return;
}

void bar (void)
{
  return foo ();
}

int main (void)
{
  bar ();
  return 0;
}
jas at mocca:~$ gcc -o foo foo.c -Wall -Wextra
jas at mocca:~$ gcc --version
gcc (Debian 4.4.4-8) 4.4.5 20100728 (prerelease)
jas at mocca:~$ 

>> And you can crank up the pedantry even further with --pedantic,
>> which will warn of a void expression return in a function
>> with a void return signature.
>
> And -Werror, which will make any warning fail the build.

I already build with -Werror together with the following warnings:

-Wall -W -Wframe-larger-than=2100 -Wformat-security -Winit-self -Wmissing-include-dirs -Wunused -Wunknown-pragmas -Wstrict-aliasing -Wfloat-equal -Wdeclaration-after-statement -Wpointer-arith -Wbad-function-cast -Wcast-align -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wmissing-format-attribute -Wpacked -Wredundant-decls -Wnested-externs -Winline -Winvalid-pch -Wlong-long -Wvla -Wvolatile-register-var -Wdisabled-optimization -Wstack-protector -Woverlength-strings -Wbuiltin-macro-redefined -Wmudflap -Wpacked-bitfield-compat -Wsync-nand -Wattributes -Wcoverage-mismatch -Wmultichar -Wunused-macros -Wno-missing-field-initializers -Wno-sign-compare -Wno-pointer-sign -Wno-unused-parameter -Wno-unused-parameter -Wno-stack-protector -Wno-int-to-pointer-cast -fdiagnostics-show-option

However none of those warnings catches a return void situation.

Yes, --pedantic catches this problem, but it also triggers on many other
constructs that we haven't fixed, and some of the --pedantic warnings
doesn't make sense.

So it would be great if there were a single gcc warning flag to enable
this particular warning, rather than the heavy handed --pedantic.

/Simon



From simon at josefsson.org  Fri Oct  1 10:35:52 2010
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 01 Oct 2010 10:35:52 +0200
Subject: Small issue on GnuTLS 2.10.2
In-Reply-To: <4CA4B803.2070005@onetel.net> (David Kirkby's message of "Thu, 30
	Sep 2010 17:17:07 +0100")
References: <87zkuzd26y.fsf@mocca.josefsson.org>
	<996662C3-824F-4579-B23B-8FD8969AFF53@opencsw.org>
	<87y6aj9sri.fsf@mocca.josefsson.org> <4CA4B803.2070005@onetel.net>
Message-ID: <87d3ruxqc7.fsf@mocca.josefsson.org>

"Dr. David Kirkby" <david.kirkby at onetel.net> writes:

> On 09/30/10 04:05 PM, Simon Josefsson wrote:
>> Dagobert Michelsen<dam at opencsw.org>  writes:
>>
>>> Hi Simon,
>>>
>>> I just encountered a small issue when compiling GnuTLS 2.10.2 on
>>> Solaris 9 with Sun Studio 12:
>>>
>>> - Method declared void returns something:
>>
>> Thanks, fixed.  I wish we could catch these with a GCC warning so you
>> don't have to run into them all the time...
>
> Assuming you develop under Linux, you could install Sun Studio there,
> which will catch a lot more problems than gcc, which is very lax. Sun
> Studio is obviously supported on Solaris, but also Linux too.
>
> http://www.oracle.com/technetwork/server-storage/solarisstudio/overview/index.html

I don't have resources to do this myself, but if someone wants to setup
a daily builder for Sun Studio and e-mail builds log to
gnutls at autobuild.josefsson.org I will see it before future releases.

/Simon



From mrsam at courier-mta.com  Fri Oct  1 13:05:53 2010
From: mrsam at courier-mta.com (Sam Varshavchik)
Date: Fri, 01 Oct 2010 07:05:53 -0400
Subject: Small issue on GnuTLS 2.10.2
References: <87zkuzd26y.fsf@mocca.josefsson.org>
	<996662C3-824F-4579-B23B-8FD8969AFF53@opencsw.org>
	<87y6aj9sri.fsf@mocca.josefsson.org> <4CA4B803.2070005@onetel.net>
	<alpine.DEB.2.00.1009301723570.11924@noise.cbg.collabora.co.uk>
	<alpine.DEB.2.00.1009301815370.11924@noise.cbg.collabora.co.uk>
	<cone.1285884480.612917.27396.500@commodore.email-scan.com>
	<8739sqzahn.fsf@mocca.josefsson.org>
Message-ID: <cone.1285931153.790529.31750.500@commodore.email-scan.com>

Simon Josefsson writes:

> 
> However none of those warnings catches a return void situation.
> 
> Yes, --pedantic catches this problem, but it also triggers on many other
> constructs that we haven't fixed, and some of the --pedantic warnings
> doesn't make sense.
> 
> So it would be great if there were a single gcc warning flag to enable
> this particular warning, rather than the heavy handed --pedantic.

-Wreturn-type might be the one.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: </pipermail/attachments/20101001/022ddf92/attachment.pgp>

From vivek at collabora.co.uk  Fri Oct  1 13:13:46 2010
From: vivek at collabora.co.uk (Vivek Dasmohapatra)
Date: Fri, 1 Oct 2010 12:13:46 +0100 (BST)
Subject: Small issue on GnuTLS 2.10.2
In-Reply-To: <cone.1285931153.790529.31750.500@commodore.email-scan.com>
References: <87zkuzd26y.fsf@mocca.josefsson.org>
	<996662C3-824F-4579-B23B-8FD8969AFF53@opencsw.org>
	<87y6aj9sri.fsf@mocca.josefsson.org> <4CA4B803.2070005@onetel.net>
	<alpine.DEB.2.00.1009301723570.11924@noise.cbg.collabora.co.uk>
	<alpine.DEB.2.00.1009301815370.11924@noise.cbg.collabora.co.uk>
	<cone.1285884480.612917.27396.500@commodore.email-scan.com>
	<8739sqzahn.fsf@mocca.josefsson.org>
	<cone.1285931153.790529.31750.500@commodore.email-scan.com>
Message-ID: <alpine.DEB.2.00.1010011212590.11924@noise.cbg.collabora.co.uk>

>> So it would be great if there were a single gcc warning flag to enable
>> this particular warning, rather than the heavy handed --pedantic.
>
> -Wreturn-type might be the one.

It specifically doesn't warn when you return a void expression in
a void context, currently only --pedantic does that afaik.




From simon at josefsson.org  Fri Oct  1 14:44:49 2010
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 01 Oct 2010 14:44:49 +0200
Subject: Small issue on GnuTLS 2.10.2
In-Reply-To: <alpine.DEB.2.00.1010011212590.11924@noise.cbg.collabora.co.uk>
	(Vivek Dasmohapatra's message of "Fri, 1 Oct 2010 12:13:46 +0100
	(BST)")
References: <87zkuzd26y.fsf@mocca.josefsson.org>
	<996662C3-824F-4579-B23B-8FD8969AFF53@opencsw.org>
	<87y6aj9sri.fsf@mocca.josefsson.org> <4CA4B803.2070005@onetel.net>
	<alpine.DEB.2.00.1009301723570.11924@noise.cbg.collabora.co.uk>
	<alpine.DEB.2.00.1009301815370.11924@noise.cbg.collabora.co.uk>
	<cone.1285884480.612917.27396.500@commodore.email-scan.com>
	<8739sqzahn.fsf@mocca.josefsson.org>
	<cone.1285931153.790529.31750.500@commodore.email-scan.com>
	<alpine.DEB.2.00.1010011212590.11924@noise.cbg.collabora.co.uk>
Message-ID: <87aamydqv2.fsf@mocca.josefsson.org>

Vivek Dasmohapatra <vivek at collabora.co.uk> writes:

>>> So it would be great if there were a single gcc warning flag to enable
>>> this particular warning, rather than the heavy handed --pedantic.
>>
>> -Wreturn-type might be the one.
>
> It specifically doesn't warn when you return a void expression in
> a void context, currently only --pedantic does that afaik.

You are right, see below.  I'm looking into how difficult it would be to
fix the --pedantic warnings too, but it does warn about some constructs
(like variadic CPP function macros) that we only use if they work.

jas at mocca:~$ cat foo.c
void foo (void)
{
  return;
}

void bar (void)
{
  return foo ();
}

int main (void)
{
  bar ();
  return 0;
}
jas at mocca:~$ gcc -o foo foo.c -Wreturn-type
jas at mocca:~$ 

/Simon



From vivek at collabora.co.uk  Fri Oct  1 15:20:46 2010
From: vivek at collabora.co.uk (Vivek Dasmohapatra)
Date: Fri, 1 Oct 2010 14:20:46 +0100 (BST)
Subject: Small issue on GnuTLS 2.10.2
In-Reply-To: <87aamydqv2.fsf@mocca.josefsson.org>
References: <87zkuzd26y.fsf@mocca.josefsson.org>
	<996662C3-824F-4579-B23B-8FD8969AFF53@opencsw.org>
	<87y6aj9sri.fsf@mocca.josefsson.org> <4CA4B803.2070005@onetel.net>
	<alpine.DEB.2.00.1009301723570.11924@noise.cbg.collabora.co.uk>
	<alpine.DEB.2.00.1009301815370.11924@noise.cbg.collabora.co.uk>
	<cone.1285884480.612917.27396.500@commodore.email-scan.com>
	<8739sqzahn.fsf@mocca.josefsson.org>
	<cone.1285931153.790529.31750.500@commodore.email-scan.com>
	<alpine.DEB.2.00.1010011212590.11924@noise.cbg.collabora.co.uk>
	<87aamydqv2.fsf@mocca.josefsson.org>
Message-ID: <alpine.DEB.2.00.1010011415240.11924@noise.cbg.collabora.co.uk>

On Fri, 1 Oct 2010, Simon Josefsson wrote:

> You are right, see below.  I'm looking into how difficult it would be to
> fix the --pedantic warnings too, but it does warn about some constructs
> (like variadic CPP function macros) that we only use if they work.

fwiw, with --std=c99 --pedantic

// bitches about this (GNU named vararg syntax)
#define GNU_VARIADIC(x...) fprintf(stderr, x)

// happy with this
#define C9X_VARIADIC(...) fprintf(stderr, __VA_ARGS__)





From tzz at lifelogs.com  Fri Oct  1 21:50:36 2010
From: tzz at lifelogs.com (Ted Zlatanov)
Date: Fri, 01 Oct 2010 14:50:36 -0500
Subject: recommendations for storage of accepted certificates
Message-ID: <87eic9itf7.fsf@lifelogs.com>

I want to store the server certificates that the user accepts.  This is
inside Emacs so I have easy access to file editing and all the other
nifty Emacs Lisp functions.

Can I generate a trust file?  Currently the trust file is the one that
comes with the OS but I could make a user-specific one and copy the OS
trust file contents into the user's.  Or is the trust file only a bundle
of certificate authorities?  I can't find documentation on the format.

Any recommendations are welcome.

Thanks
Ted




From nmav at gnutls.org  Sat Oct  2 08:51:18 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 02 Oct 2010 08:51:18 +0200
Subject: recommendations for storage of accepted certificates
In-Reply-To: <87eic9itf7.fsf@lifelogs.com>
References: <87eic9itf7.fsf@lifelogs.com>
Message-ID: <4CA6D666.301@gnutls.org>

On 10/01/2010 09:50 PM, Ted Zlatanov wrote:
> I want to store the server certificates that the user accepts.  This is
> inside Emacs so I have easy access to file editing and all the other
> nifty Emacs Lisp functions.
> 
> Can I generate a trust file? 

Of course you can. Just store the trusted certificates in PEM format.
However there you place trusted CAs thus any CA you store could verify
potentially any server which is quite dangerous and might not be what
you want.

The best alternative would be to store for every server the
corresponding certificate and during next connection verify that it
remained the same.

> Currently the trust file is the one that
> comes with the OS but I could make a user-specific one and copy the OS
> trust file contents into the user's.  Or is the trust file only a bundle
> of certificate authorities?  I can't find documentation on the format.

If you go with the 1st approach, you don't really need to store the
system file to the user one. You can call
gnutls_certificate_set_x509_key_file() multiple times (one to load the
system and one more for the user).

regards,
Nikos



From INVALID.NOREPLY at gnu.org  Sat Oct  2 15:36:40 2010
From: INVALID.NOREPLY at gnu.org (Micah Anderson)
Date: Sat, 02 Oct 2010 13:36:40 +0000
Subject: [sr #107489] ipsec_ike_key created in wrong code path
Message-ID: <20101002-133639.sv80249.56906@savannah.gnu.org>


URL:
  <http://savannah.gnu.org/support/?107489>

                 Summary: ipsec_ike_key created in wrong code path
                 Project: GnuTLS
            Submitted by: micahanderson
            Submitted on: Sat 02 Oct 2010 01:36:39 PM GMT
                Category: None
                Priority: 5 - Normal
                Severity: 3 - Normal
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
        Operating System: None

    _______________________________________________________

Details:

The ipsec_ike_key patch submitted in #107485 creates a certificate with the
KU flag for ipsec IKE only when the "ca" flag is set. The reason for this is
the get_ipsec_ike_status() check in src/certtool.c:547 is wrapped inside an if
(ca_status) predicate.

This is wrong, because you should not be a CA to offer a cert for IKE. In
fact, IKE should not appear in a CA certificate, but otherwise should be
independent of any other status as it is not unreasonable to want to use such
a certificate for other things on the host, such as a WWW server.

It is for this reason I've adjusted the patch to make it fall under the if
(!ca_status || server) predicate, instead of under the if (ca_status)
predicate.

Additionally, an IKE certificate should be able to set the SubjectAltName
(ie. dns_name parameters in the config; and ip_address parameters in the
config) v3 extensions. To achieve this I've added an is_ike check and added
the test to see if that is set along with the other checks that were
happening, and then if so add the get_dns_name_set (TYPE_CRT, crt);
get_ip_addr_set (TYPE_CRT, crt); to the cert. 

Attached is a patch to the 2_10_x branch, as well as patch to the HEAD of
master. You can also find these commits in my repository
git://labs.riseup.net/~micah/gnutls there are two branches there, one for
2_10_x and one against master (which has been rebased against the latest
upstream commits).



    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Sat 02 Oct 2010 01:36:39 PM GMT  Name: ipsec_ike_gnutls_2_10_2.diff 
Size: 2kB   By: micahanderson

<http://savannah.gnu.org/support/download.php?file_id=21593>
-------------------------------------------------------
Date: Sat 02 Oct 2010 01:36:39 PM GMT  Name: ipsec_ike_gnutls_master.diff 
Size: 2kB   By: micahanderson

<http://savannah.gnu.org/support/download.php?file_id=21594>

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107489>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From INVALID.NOREPLY at gnu.org  Sat Oct  2 16:01:56 2010
From: INVALID.NOREPLY at gnu.org (Micah Anderson)
Date: Sat, 02 Oct 2010 14:01:56 +0000
Subject: [sr #107489] ipsec_ike_key created in wrong code path
In-Reply-To: <20101002-133639.sv80249.56906@savannah.gnu.org>
References: <20101002-133639.sv80249.56906@savannah.gnu.org>
Message-ID: <20101002-140156.sv80249.19148@savannah.gnu.org>


Follow-up Comment #1, sr #107489 (project gnutls):

There is another issue with the ike patch that must be resolved:

according to http://tools.ietf.org/html/rfc4945#section-5.1.3.2: 

*if* any KU is set, 
*then* either digSig or nonRep *must* be set within that KU for all IKE
certs

this is currently not happening in the attached patches, so please hold off
on applying these until this has been adjusted.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107489>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From tzz at lifelogs.com  Sat Oct  2 17:45:07 2010
From: tzz at lifelogs.com (Ted Zlatanov)
Date: Sat, 02 Oct 2010 10:45:07 -0500
Subject: recommendations for storage of accepted certificates
References: <87eic9itf7.fsf@lifelogs.com> <4CA6D666.301@gnutls.org>
Message-ID: <874od4k398.fsf@lifelogs.com>

On Sat, 02 Oct 2010 08:51:18 +0200 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote: 

NM> On 10/01/2010 09:50 PM, Ted Zlatanov wrote:
>> I want to store the server certificates that the user accepts.  This is
>> inside Emacs so I have easy access to file editing and all the other
>> nifty Emacs Lisp functions.
>> 
>> Can I generate a trust file? 

NM> Of course you can. Just store the trusted certificates in PEM format.
NM> However there you place trusted CAs thus any CA you store could verify
NM> potentially any server which is quite dangerous and might not be what
NM> you want.

Yeah.  We have to discuss it in the context of Emacs, which is pretty
unusual (more like an OS than most applications) so we may decide to
augment the OS-level trusted certificates with our own CA.  But it's
good to know I can make a personalized one for each user.

NM> The best alternative would be to store for every server the
NM> corresponding certificate and during next connection verify that it
NM> remained the same.

OK.  The question is then where to store it.  Emacs can handle all the
file interactions but I wondered if there's a convention
(e.g. $HOME/.certs or some such) where I can drop those certificates.
I'll call it $CERTDROP below.

>> Currently the trust file is the one that comes with the OS but I
>> could make a user-specific one and copy the OS trust file contents
>> into the user's.  Or is the trust file only a bundle of certificate
>> authorities?  I can't find documentation on the format.

NM> If you go with the 1st approach, you don't really need to store the
NM> system file to the user one. You can call
NM> gnutls_certificate_set_x509_key_file() multiple times (one to load
NM> the system and one more for the user).

Oh!  I didn't notice that gnutls_certificate_set_x509_key_file() and
gnutls_certificate_set_x509_trust_file() can be called multiple times.
It's pretty easy then and won't require making bundles:

1) set up a conventional place where Emacs will drop accepted
certificates, $CERTDROP/*.pem

2) on gnutls-boot call, load all the accepted certificates plus whatever
the user specifies (is there a performance penalty for a large number of
these?)

3) set up a facility within the Emacs GnuTLS support to accept and store
unknown server certificates.  What function in the GnuTLS API can I use
to provide this?  I can't find the right way in the docs or in the
examples, sorry.

Thanks for your help
Ted




From INVALID.NOREPLY at gnu.org  Sat Oct  2 20:34:54 2010
From: INVALID.NOREPLY at gnu.org (Micah Anderson)
Date: Sat, 02 Oct 2010 18:34:54 +0000
Subject: [sr #107489] ipsec_ike_key created in wrong code path
In-Reply-To: <20101002-140156.sv80249.19148@savannah.gnu.org>
References: <20101002-133639.sv80249.56906@savannah.gnu.org>
	<20101002-140156.sv80249.19148@savannah.gnu.org>
Message-ID: <20101002-183453.sv80249.43612@savannah.gnu.org>


Follow-up Comment #2, sr #107489 (project gnutls):

the attached patches add the section 5.1.3.2 compliance on top of the other
attached patches. also available in my repository

(file #21596, file #21597)
    _______________________________________________________

Additional Item Attachment:

File name: ipsec_ike_non_repudiation_2_10_x.diff Size:0 KB
File name: ipsec_ike_non_repudiation_master.diff Size:0 KB


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107489>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From david.kirkby at onetel.net  Sat Oct  2 20:38:47 2010
From: david.kirkby at onetel.net (Dr. David Kirkby)
Date: Sat, 02 Oct 2010 19:38:47 +0100
Subject: Small issue on GnuTLS 2.10.2
In-Reply-To: <alpine.DEB.2.00.1009301815370.11924@noise.cbg.collabora.co.uk>
References: <87zkuzd26y.fsf@mocca.josefsson.org>
	<996662C3-824F-4579-B23B-8FD8969AFF53@opencsw.org>
	<87y6aj9sri.fsf@mocca.josefsson.org> <4CA4B803.2070005@onetel.net>
	<alpine.DEB.2.00.1009301723570.11924@noise.cbg.collabora.co.uk>
	<alpine.DEB.2.00.1009301815370.11924@noise.cbg.collabora.co.uk>
Message-ID: <4CA77C37.4000104@onetel.net>

On 09/30/10 06:16 PM, Vivek Dasmohapatra wrote:
> On Thu, 30 Sep 2010, Vivek Dasmohapatra wrote:
>
>> On Thu, 30 Sep 2010, Dr. David Kirkby wrote:
>>
>>>> Thanks, fixed. I wish we could catch these with a GCC warning so you
>>>> don't have to run into them all the time...
>>
>> make sizeof
>> cc sizeof.c -o sizeof
>> sizeof.c: In function ?wfm?:
>> sizeof.c:11: warning: ?return? with a value, in function returning void
>>
>> tested wiith: gcc (Debian 4.4.3-3) 4.4.3
>> gcc (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu4)
>>
>> Seems to warn just fine.
>
> And you can crank up the pedantry even further with --pedantic,
> which will warn of a void expression return in a function
> with a void return signature.

Still though, using the Sun compiler on Linux will give you another "opinion". 
I'd trust the Sun compiler more than gcc. SunStudio also comes with a "lint" 
program too.

At least the Sun compilers compiles C.

gcc compiles a both a superset and a subset of the C programming language. 
(i.e. gcc fails to fully support C99, but has tons of extensions).

Dave



From INVALID.NOREPLY at gnu.org  Sat Oct  2 23:36:04 2010
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Sat, 02 Oct 2010 21:36:04 +0000
Subject: [sr #107464] Secure Connections on AIX using non blocking socket
In-Reply-To: <20100825-171444.sv707.51438@savannah.gnu.org>
References: <20100825-124430.sv79827.98910@savannah.gnu.org>
	<20100825-171444.sv707.51438@savannah.gnu.org>
Message-ID: <20101003-003604.sv707.36504@savannah.gnu.org>


Update of sr #107464 (project gnutls):

                  Status:                    None => Wont Do                
             Open/Closed:                    Open => Closed                 

    _______________________________________________________

Follow-up Comment #2:

I close this because it is an AIX related bug, that we cannot fix in a clean
way.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107464>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From INVALID.NOREPLY at gnu.org  Sat Oct  2 23:35:00 2010
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Sat, 02 Oct 2010 21:35:00 +0000
Subject: [sr #107489] ipsec_ike_key created in wrong code path
In-Reply-To: <20101002-183453.sv80249.43612@savannah.gnu.org>
References: <20101002-133639.sv80249.56906@savannah.gnu.org>
	<20101002-140156.sv80249.19148@savannah.gnu.org>
	<20101002-183453.sv80249.43612@savannah.gnu.org>
Message-ID: <20101003-003459.sv707.4922@savannah.gnu.org>


Update of sr #107489 (project gnutls):

                  Status:                    None => In Progress            
             Assigned to:                    None => nmav                   

    _______________________________________________________

Follow-up Comment #3:

I've applied the patches to 2.10.x and master. Could you verify that they
work as expected?



    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107489>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From nmav at gnutls.org  Sun Oct  3 08:34:48 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 03 Oct 2010 08:34:48 +0200
Subject: recommendations for storage of accepted certificates
In-Reply-To: <874od4k398.fsf@lifelogs.com>
References: <87eic9itf7.fsf@lifelogs.com> <4CA6D666.301@gnutls.org>
	<874od4k398.fsf@lifelogs.com>
Message-ID: <4CA82408.4040505@gnutls.org>

On 10/02/2010 05:45 PM, Ted Zlatanov wrote:

> NM> The best alternative would be to store for every server the
> NM> corresponding certificate and during next connection verify that it
> NM> remained the same.
> OK.  The question is then where to store it.  Emacs can handle all the
> file interactions but I wondered if there's a convention
> (e.g. $HOME/.certs or some such) where I can drop those certificates.
> I'll call it $CERTDROP below.

I don't think there is a standard location for that. I'd put it in a DB
file (gdbm or so).

> 1) set up a conventional place where Emacs will drop accepted
> certificates, $CERTDROP/*.pem

If you're talking about server certificates I'd use:
servername.pem, instead of loading it with the trusted certificate root.

> 3) set up a facility within the Emacs GnuTLS support to accept and store
> unknown server certificates.  What function in the GnuTLS API can I use
> to provide this?  I can't find the right way in the docs or in the
> examples, sorry.

What do you mean by unknown server? Do you mean known but untrusted? In
any case gnutls doesn't provide such facility for any of them. It was
considered to be application specific (now I'm looking for a solution to
that using pkcs11, but wouldn't be available soon).

regards,
Nikos



From nmav at gnutls.org  Sun Oct  3 08:43:07 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 03 Oct 2010 08:43:07 +0200
Subject: recommendations for storage of accepted certificates
In-Reply-To: <4CA82408.4040505@gnutls.org>
References: <87eic9itf7.fsf@lifelogs.com> <4CA6D666.301@gnutls.org>
	<874od4k398.fsf@lifelogs.com> <4CA82408.4040505@gnutls.org>
Message-ID: <4CA825FB.2070606@gnutls.org>

On 10/03/2010 08:34 AM, Nikos Mavrogiannopoulos wrote:

>> 1) set up a conventional place where Emacs will drop accepted
>> certificates, $CERTDROP/*.pem
> If you're talking about server certificates I'd use:
> servername.pem, instead of loading it with the trusted certificate root.

And here I mean, that I'd use this certificate as trusted only when
connecting to the specific server.

regards,
Nikos



From tzz at lifelogs.com  Mon Oct  4 03:27:28 2010
From: tzz at lifelogs.com (Ted Zlatanov)
Date: Sun, 03 Oct 2010 20:27:28 -0500
Subject: Emacs and TLS support
References: <4C9F70AE.3020705@alice.it> <m3eicgbhkv.fsf@quimbies.gnus.org>
	<87tylcz0aa.fsf@lifelogs.com> <m3aan4w6xl.fsf@quimbies.gnus.org>
	<87eicgyyun.fsf@lifelogs.com> <87k4m3bklp.fsf@mocca.josefsson.org>
Message-ID: <87wrpyhhmn.fsf@lifelogs.com>

On Thu, 30 Sep 2010 12:18:26 +0200 Simon Josefsson <simon at josefsson.org> wrote: 

SJ> I don't know Emacs internals well enough, but it may be that replacing
SJ> the send/recv functions could make things more reliable...

It turned out to be better to do the handshake at the C level.  It's not
ideal but at least it works now.

SJ> I don't have a lot of time to help here alas, and when I tried building
SJ> Emacs from CVS the other day it just crashed...  maybe you could provide
SJ> simple step-by-step instructions to get something building that I can
SJ> test?  With some specific CVS revision that is known working.

Sure.  See http://www.emacswiki.org/emacs/BzrForEmacsDevs for all the
details.

Thanks for your help.  I'll follow up to the other comments too.

Ted




From tzz at lifelogs.com  Mon Oct  4 03:37:36 2010
From: tzz at lifelogs.com (Ted Zlatanov)
Date: Sun, 03 Oct 2010 20:37:36 -0500
Subject: recommendations for storage of accepted certificates
References: <87eic9itf7.fsf@lifelogs.com> <4CA6D666.301@gnutls.org>
	<874od4k398.fsf@lifelogs.com> <4CA82408.4040505@gnutls.org>
Message-ID: <87mxquhh5r.fsf@lifelogs.com>

On Sun, 03 Oct 2010 08:34:48 +0200 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote: 

NM> On 10/02/2010 05:45 PM, Ted Zlatanov wrote:
NM> The best alternative would be to store for every server the
NM> corresponding certificate and during next connection verify that it
NM> remained the same.
>> OK.  The question is then where to store it.  Emacs can handle all the
>> file interactions but I wondered if there's a convention
>> (e.g. $HOME/.certs or some such) where I can drop those certificates.
>> I'll call it $CERTDROP below.

NM> I don't think there is a standard location for that. I'd put it in a DB
NM> file (gdbm or so).

OK.  For Emacs it's better to use a directory than a DBM file because of
the many platforms supported and lack of native *DBM support.  So maybe
$HOME/.emacs.d/certificates/SERVER.pem where SERVER is a normalized
version of the server name.  Hmm, or maybe just use the IP address.  It
gets complicated (like the OpenSSH known hosts :)

>> 1) set up a conventional place where Emacs will drop accepted
>> certificates, $CERTDROP/*.pem

NM> If you're talking about server certificates I'd use:
NM> servername.pem, instead of loading it with the trusted certificate root.
...
NM> And here I mean, that I'd use this certificate as trusted only when
NM> connecting to the specific server.

OK.  I'll set up something but it's not simple so I'll look at how other
applications store keys and certificates.  I may use the OpenSSH known
hosts model and just dump/load a hashtable keyed by server name.

>> 3) set up a facility within the Emacs GnuTLS support to accept and store
>> unknown server certificates.  What function in the GnuTLS API can I use
>> to provide this?  I can't find the right way in the docs or in the
>> examples, sorry.

NM> What do you mean by unknown server? Do you mean known but untrusted? In
NM> any case gnutls doesn't provide such facility for any of them. It was
NM> considered to be application specific (now I'm looking for a solution to
NM> that using pkcs11, but wouldn't be available soon).

Sorry for the badly phrased questions.  Yes: I mean I connect to a known
server but its certificate is not trusted (I let GnuTLS verify the
certificate chain).  Would I just look at the error and ask the user to
accept the certificate and retry?  I was hoping to do it during the
handshake with a callback function.

Thanks
Ted




From tzz at lifelogs.com  Mon Oct  4 05:42:43 2010
From: tzz at lifelogs.com (Ted Zlatanov)
Date: Sun, 03 Oct 2010 22:42:43 -0500
Subject: Emacs core TLS support
References: <878wc1vfh3.fsf@lifelogs.com>
	<jwvbpgw1yp2.fsf-monnier+emacs@gnu.org> <87d41csktn.fsf@lifelogs.com>
	<87k4v0n0m8.fsf@lifelogs.com> <87wrrvfnc4.fsf@lifelogs.com>
	<m3zkwqhixi.fsf@carbon.jhcloos.org> <87r5i2d00q.fsf@lifelogs.com>
	<87zkwqijye.fsf@stupidchicken.com> <878w4actmg.fsf@lifelogs.com>
	<877hju123h.fsf@stupidchicken.com> <8762yklrdk.fsf@lifelogs.com>
	<jwvlj7fg7gk.fsf-monnier+emacs@gnu.org> <87wrqzhrjv.fsf@lifelogs.com>
	<jwvmxruehco.fsf-monnier+emacs@gnu.org> <87fwxmihyz.fsf@lifelogs.com>
	<8762ycfhqo.fsf@lifelogs.com>
	<AANLkTim_joNAMDoUACseNbTwVEn6dOAexWzb7PKML7K2@mail.gmail.com>
	<87d3sf9soo.fsf@lifelogs.com> <87eicn2upl.fsf@mocca.josefsson.org>
	<87k4m92fuq.fsf@lifelogs.com> <87sk0rbkz5.fsf@mocca.josefsson.org>
Message-ID: <87iq1ihbd8.fsf@lifelogs.com>

On Thu, 30 Sep 2010 12:10:22 +0200 Simon Josefsson <simon at josefsson.org> wrote: 

SJ> Ted Zlatanov <tzz at lifelogs.com> writes:
>>>> +PRIORITY-STRING is as per the GnuTLS docs.
>> 
SJ> Maybe there could be an info hyperlink here?
SJ> I was thinking to the Info manual.  Just a nit...

Generally I don't see Info links in the function docstrings.  It's
common to link to other functions, but I don't know about Info links.
Maybe someone more knowledgeable can say.

It's pretty unusual to use a priority string other than the default of
"NORMAL", right?  I think if we provide decent defaults, this will
rarely need to be checked and so it's not too important to provide live
links to a manual.

SJ> 2) The design makes it a bit difficult to support multiple
SJ> credentials.  The GnuTLS API allows clients to have several
SJ> credentials (X.509, OpenPGP, etc).

Do you think it's sensible to add the complexity of multiple
credentials?  It would make the current API much heavier.  Right now we
just have a credential type (anon or X.509) and a few options for
trust/keyfiles, etc.  Stacking multiple credentials could maybe work by
passing multiple plists, each with its own type, instead of just one, to
gnutls-boot.  But is that really a common scenario for a client?

>> As I mentioned earlier I think GnuTLS should consider further
>> extending the idea of priority strings to a full configuration
>> (credentials especially) in a single string or file.  That would make
>> using it so much easier from Emacs Lisp.

SJ> Hm.  Interesting, yes, it could do that.  I'm not sure it makes sense to
SJ> support at the C layer, but I'll think about it.

Thanks.  That would be very nice for talking to GnuTLS not only from
Emacs, but from Perl and other scripting languages and even from the
shell as well.

Ted




From nmav at gnutls.org  Mon Oct  4 08:17:21 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 4 Oct 2010 08:17:21 +0200
Subject: recommendations for storage of accepted certificates
In-Reply-To: <87mxquhh5r.fsf@lifelogs.com>
References: <87eic9itf7.fsf@lifelogs.com> <4CA6D666.301@gnutls.org>
	<874od4k398.fsf@lifelogs.com> <4CA82408.4040505@gnutls.org>
	<87mxquhh5r.fsf@lifelogs.com>
Message-ID: <AANLkTim4qQO98AL+-QQhECPTe8_p35VQqc8YEZNnVcqG@mail.gmail.com>

2010/10/4 Ted Zlatanov <tzz at lifelogs.com>:

> NM> What do you mean by unknown server? Do you mean known but untrusted? In
> NM> any case gnutls doesn't provide such facility for any of them. It was
> NM> considered to be application specific (now I'm looking for a solution to
> NM> that using pkcs11, but wouldn't be available soon).
>
> Sorry for the badly phrased questions. ?Yes: I mean I connect to a known
> server but its certificate is not trusted (I let GnuTLS verify the
> certificate chain). ?Would I just look at the error and ask the user to
> accept the certificate and retry? ?I was hoping to do it during the
> handshake with a callback function.

You can do it during the handshake. There is a callback function that
provides you with the peer certificate and you can do verification there.

regards,
Nikos



From nmav at gnutls.org  Mon Oct  4 08:24:46 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 4 Oct 2010 08:24:46 +0200
Subject: Emacs core TLS support
In-Reply-To: <87iq1ihbd8.fsf@lifelogs.com>
References: <878wc1vfh3.fsf@lifelogs.com>
	<jwvbpgw1yp2.fsf-monnier+emacs@gnu.org>
	<87d41csktn.fsf@lifelogs.com> <87k4v0n0m8.fsf@lifelogs.com>
	<87wrrvfnc4.fsf@lifelogs.com> <m3zkwqhixi.fsf@carbon.jhcloos.org>
	<87r5i2d00q.fsf@lifelogs.com> <87zkwqijye.fsf@stupidchicken.com>
	<878w4actmg.fsf@lifelogs.com> <877hju123h.fsf@stupidchicken.com>
	<8762yklrdk.fsf@lifelogs.com>
	<jwvlj7fg7gk.fsf-monnier+emacs@gnu.org>
	<87wrqzhrjv.fsf@lifelogs.com>
	<jwvmxruehco.fsf-monnier+emacs@gnu.org>
	<87fwxmihyz.fsf@lifelogs.com> <8762ycfhqo.fsf@lifelogs.com>
	<AANLkTim_joNAMDoUACseNbTwVEn6dOAexWzb7PKML7K2@mail.gmail.com>
	<87d3sf9soo.fsf@lifelogs.com> <87eicn2upl.fsf@mocca.josefsson.org>
	<87k4m92fuq.fsf@lifelogs.com> <87sk0rbkz5.fsf@mocca.josefsson.org>
	<87iq1ihbd8.fsf@lifelogs.com>
Message-ID: <AANLkTimjmaghMymZDTBrVbsuaAswSbdakdy_BxyVPLNA@mail.gmail.com>

2010/10/4 Ted Zlatanov <tzz at lifelogs.com>:

> SJ> Hm. ?Interesting, yes, it could do that. ?I'm not sure it makes sense to
> SJ> support at the C layer, but I'll think about it.
> Thanks. ?That would be very nice for talking to GnuTLS not only from
> Emacs, but from Perl and other scripting languages and even from the
> shell as well.

Keep in mind that gnutls is a C library. Doing something like that it is pretty
unusual for a C API. This can be done at a higher level on the wrapper libraries
sometimes more easily.

regards,
Nikos



From INVALID.NOREPLY at gnu.org  Mon Oct  4 19:28:30 2010
From: INVALID.NOREPLY at gnu.org (Micah Anderson)
Date: Mon, 04 Oct 2010 17:28:30 +0000
Subject: [sr #107489] ipsec_ike_key created in wrong code path
In-Reply-To: <20101003-003459.sv707.4922@savannah.gnu.org>
References: <20101002-133639.sv80249.56906@savannah.gnu.org>
	<20101002-140156.sv80249.19148@savannah.gnu.org>
	<20101002-183453.sv80249.43612@savannah.gnu.org>
	<20101003-003459.sv707.4922@savannah.gnu.org>
Message-ID: <20101004-172829.sv80249.19715@savannah.gnu.org>


Follow-up Comment #4, sr #107489 (project gnutls):

Ok, I have done some additional testing to verify things work as expected. As
a result, I found that the certificate request code path needed to also be
adjusted. I've attached those patches, and committed them to my git
repository.

I was able to test generation of certificates and generation of certificate
requests, and then also generating certificates based on those requests. I set
various flags for different tests, and am now satisfied that it is doing the
correct thing.


(file #21611, file #21612)
    _______________________________________________________

Additional Item Attachment:

File name: ipsec_ike_crq_2_10_x.diff      Size:1 KB
File name: ipsec_ike_crq_master.diff      Size:1 KB


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107489>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From INVALID.NOREPLY at gnu.org  Mon Oct  4 19:35:19 2010
From: INVALID.NOREPLY at gnu.org (Micah Anderson)
Date: Mon, 04 Oct 2010 17:35:19 +0000
Subject: [sr #107489] ipsec_ike_key created in wrong code path
In-Reply-To: <20101004-172829.sv80249.19715@savannah.gnu.org>
References: <20101002-133639.sv80249.56906@savannah.gnu.org>
	<20101002-140156.sv80249.19148@savannah.gnu.org>
	<20101002-183453.sv80249.43612@savannah.gnu.org>
	<20101003-003459.sv707.4922@savannah.gnu.org>
	<20101004-172829.sv80249.19715@savannah.gnu.org>
Message-ID: <20101004-173519.sv80249.7650@savannah.gnu.org>


Follow-up Comment #5, sr #107489 (project gnutls):

I should note that you can also find these commits in my repository which is
located here: git://labs.riseup.net/~micah/gnutls there are two branches
there, one for 2_10_x and one against master (which has been rebased against
the latest upstream commits).

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107489>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From INVALID.NOREPLY at gnu.org  Tue Oct  5 08:55:17 2010
From: INVALID.NOREPLY at gnu.org (anonymous)
Date: Tue, 05 Oct 2010 06:55:17 +0000
Subject: [sr #107489] ipsec_ike_key created in wrong code path
In-Reply-To: <20101004-173519.sv80249.7650@savannah.gnu.org>
References: <20101002-133639.sv80249.56906@savannah.gnu.org>
	<20101002-140156.sv80249.19148@savannah.gnu.org>
	<20101002-183453.sv80249.43612@savannah.gnu.org>
	<20101003-003459.sv707.4922@savannah.gnu.org>
	<20101004-172829.sv80249.19715@savannah.gnu.org>
	<20101004-173519.sv80249.7650@savannah.gnu.org>
Message-ID: <20101005-065517.sv0.3749@savannah.gnu.org>


Follow-up Comment #6, sr #107489 (project gnutls):

Hi,
 Could you post information on which should have been the "correct" path for
the code, so we can verify it as well?


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107489>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From tzz at lifelogs.com  Tue Oct  5 12:54:43 2010
From: tzz at lifelogs.com (Ted Zlatanov)
Date: Tue, 05 Oct 2010 05:54:43 -0500
Subject: recommendations for storage of accepted certificates
References: <87eic9itf7.fsf@lifelogs.com> <4CA6D666.301@gnutls.org>
	<874od4k398.fsf@lifelogs.com> <4CA82408.4040505@gnutls.org>
	<87mxquhh5r.fsf@lifelogs.com>
	<AANLkTim4qQO98AL+-QQhECPTe8_p35VQqc8YEZNnVcqG@mail.gmail.com>
Message-ID: <87pqvogb9o.fsf@lifelogs.com>

On Mon, 4 Oct 2010 08:17:21 +0200 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote: 

NM> 2010/10/4 Ted Zlatanov <tzz at lifelogs.com>:
NM> What do you mean by unknown server? Do you mean known but untrusted? In
NM> any case gnutls doesn't provide such facility for any of them. It was
NM> considered to be application specific (now I'm looking for a solution to
NM> that using pkcs11, but wouldn't be available soon).
>> 
>> Sorry for the badly phrased questions. ?Yes: I mean I connect to a known
>> server but its certificate is not trusted (I let GnuTLS verify the
>> certificate chain). ?Would I just look at the error and ask the user to
>> accept the certificate and retry? ?I was hoping to do it during the
>> handshake with a callback function.

NM> You can do it during the handshake. There is a callback function that
NM> provides you with the peer certificate and you can do verification there.

You mean gnutls_certificate_set_verify_function()?  I see the example in
ex-rfc2818.c.  It seems that gnutls_certificate_verify_peers2() is the
one to call.  The example calls gnutls_x509_crt_check_hostname()
explicitly so I guess I will too.  Also, rather than setting the
verify_flags, it seems cleaner to use these priority string options in
Emacs Lisp:

"%VERIFY_ALLOW_SIGN_RSA_MD5" will allow RSA-MD5 signatures in certificate chains.

"%VERIFY_ALLOW_X509_V1_CA_CRT" will allow V1 CAs in chains.

...but all the verify_flags are not available this way.  Can this be
changed or is that intentional?  If it's intentional I'll provide all
those flags as API options since I can imagine we'll need them.

So, my code will do:

1) set verify function to my own emacs_gnutls_verify

2) emacs_gnutls_verify: call verify_peers2

3) emacs_gnutls_verify: verify the host name (this will be optional):

  if (!gnutls_x509_crt_check_hostname (cert, hostname))
    {
      printf ("The certificate's owner does not match hostname '%s'\n",
              hostname);
      return GNUTLS_E_CERTIFICATE_ERROR;
    }

If verify_peers2 passed in (2) and the hostname passed return approved.

4) emacs_gnutls_verify: load $CERTSTORE/HOSTNAME.pem for the current
hostname.  If it's equivalent to the server's presented certificate (is
there a certificate_equals() function or do I just use memcmp?), the
verification passes and return approved.

5) emacs_gnutls_verify: call any user-defined callbacks (some of which
may approve the certificate by default and will return approved)

6) emacs_gnutls_verify: if the certificate failed verification, the
callbacks didn't approve it, and the gnutls-accept-unknown certificate
option is not nil, use it ('ask to ask the user, true (t) to accept
unconditionally, nil to never accept at this stage).  If the certificate
is approved, save it in $CERTSTORE/HOSTNAME.pem and return approved.

7) emacs_gnutls_verify: return unapproved

Does that seem correct logically and sequentially?  Because users can
provide their own callbacks this turns out to be a bit more complicated
than the usual verification flow but I think it's manageable.

Thanks for your help
Ted




From INVALID.NOREPLY at gnu.org  Tue Oct  5 15:13:55 2010
From: INVALID.NOREPLY at gnu.org (Micah Anderson)
Date: Tue, 05 Oct 2010 13:13:55 +0000
Subject: [sr #107489] ipsec_ike_key created in wrong code path
In-Reply-To: <20101005-065517.sv0.3749@savannah.gnu.org>
References: <20101002-133639.sv80249.56906@savannah.gnu.org>
	<20101002-140156.sv80249.19148@savannah.gnu.org>
	<20101002-183453.sv80249.43612@savannah.gnu.org>
	<20101003-003459.sv707.4922@savannah.gnu.org>
	<20101004-172829.sv80249.19715@savannah.gnu.org>
	<20101004-173519.sv80249.7650@savannah.gnu.org>
	<20101005-065517.sv0.3749@savannah.gnu.org>
Message-ID: <20101005-131355.sv80249.94138@savannah.gnu.org>


Follow-up Comment #7, sr #107489 (project gnutls):

Originally, the patches submitted in #107485 only created a certificate with
the KP flag for ipsec IKE *only* when the "ca" flag was set. That was because
the get_ipsec_ike_status() check in src/certtool.c:547 was wrapped inside an
if (ca_status) predicate. That was the incorrect place to have that check, as
the ipsec_ike_key KP should not be set in a certificate designated for a CA.

If you compile the code, with the patches, you can test that the following
are true:

1. build a cert with ipsec_ike_key set in the template, it should create a
cert with the following:

		Key Purpose (not critical):
			Ipsec IKE.

this test checks to make sure that you get a certificate built with the Ipsec
IKE KP set, when there is no 'ca' flag set. This was the original code pathing
problem.

2. build a cert with the 'ca' option set in the template, along with the
ipsec_ike_key option set. It should have the following v3 extension Basic
Constraint set, and *no* Ipsec IKE Key Purpose set:

		Basic Constraints (critical):
			Certificate Authority (CA): TRUE

This test checks to make sure that when you set the 'ca' flag, no Ipsec IKE
KP is set, as this KP should not be set when the certificate is a CA
certificate. This is the inverse of the previous test.

3. build a certificate with ipsec_ike_key set in the template, with multiple
dns_name parameters set (dns_name="test.gnutls.org, test2.gnutls.org") and an
IP address set (ip_address=192.168.1.1) to achieve a certificate with
subjectAltNames set. The certificate should have the Key Purpose Ipsec IKE set
as in test #1 above, and the SubjectAltName bits should be set:

		Subject Alternative Name (not critical):
		DNSname: test.gnutls.org, test2.gnutls.org
		IPAddress: 192.168.1.1

This test makes sure that subjectAltName support works with the Ipsec IKE
KP.

4. build a certificate with "tls_www_server" set along with "ipsec_ike_key"
set and subjectAltNames as in test #3. The generated certificate Key Purpose
should have both "TLS WWW Server." set as well as "Ipsec IKE." and the
subjectAltNames should also be set, as in test #3

This test ensures that you can build a certificate with multiple KP's set,
along with Ipsec IKE. With the added bonus that the subjectAltNames should
continue to persist.

5. build a certificate with "signing_key" set, as well as "ipsec_ike_key"
set. This should result in a certificate that has the "Ipsec IKE" Key Purpose
set, and the Key Usage set to "Digital Signature", as follows:

		Key Purpose (not critical):
			Ipsec IKE.
		Key Usage (critical):
			Digital signature.

This test makes sure that when the Ipsec IKE KP is set, and 'signing_key' is
set, that the KU is properly set to Digital signature. This tests compliance
with RFC 4945 ? 5.1.3.2.

6. build a certificate with 'encryption_key' set, along with 'ipsec_ike_key'
set. This should result in a certificate that has the "Ipsec IKE" Key Purpose
set, and the Key Usage set to both "Non repudiation" and "Key encipherment",
as follows:

		Key Purpose (not critical):
			Ipsec IKE.
		Key Usage (critical):
			Non repudiation.
			Key encipherment.

This test makes sure that when Ipsec IKE KP is set, and encryption_key is
set, that the Non repudiation KU is also set. This tests compliance with RFC
4945 ? 5.1.3.2.

7. build a certificate with 'encryption_key' set, along with 'signing_key'
set, and with 'ipsec_ike_key' set. This should result in a certificate that
has the "Ipsec IKE" Key Purpose set, and the Key Usage flags set to both
"Digital Signature" and "Key encipherment" as follows:

		Key Purpose (not critical):
			Ipsec IKE.
		Key Usage (critical):
			Digital signature.
			Key encipherment.

This test makes sure that when Ipsec IKE KP is set, and both encryption_key
and signing_key are set, that the KU is properly set to have both Digital
signature and Key encipherment (and not Non Repudiation). This tests
compliance with RFC 4945 ? 5.1.3.2.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107489>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From nmav at gnutls.org  Thu Oct  7 09:17:10 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 07 Oct 2010 09:17:10 +0200
Subject: recommendations for storage of accepted certificates
In-Reply-To: <87pqvogb9o.fsf@lifelogs.com>
References: <87eic9itf7.fsf@lifelogs.com>
	<4CA6D666.301@gnutls.org>	<874od4k398.fsf@lifelogs.com>
	<4CA82408.4040505@gnutls.org>	<87mxquhh5r.fsf@lifelogs.com>	<AANLkTim4qQO98AL+-QQhECPTe8_p35VQqc8YEZNnVcqG@mail.gmail.com>
	<87pqvogb9o.fsf@lifelogs.com>
Message-ID: <4CAD73F6.3060601@gnutls.org>

On 10/05/2010 12:54 PM, Ted Zlatanov wrote:

> You mean gnutls_certificate_set_verify_function()?  I see the example in
> ex-rfc2818.c.  It seems that gnutls_certificate_verify_peers2() is the
> one to call.  The example calls gnutls_x509_crt_check_hostname()
> explicitly so I guess I will too. 

Indeed. This is a complete example.

> Also, rather than setting the
> verify_flags, it seems cleaner to use these priority string options in
> Emacs Lisp: 
> "%VERIFY_ALLOW_SIGN_RSA_MD5" will allow RSA-MD5 signatures in certificate chains.
> "%VERIFY_ALLOW_X509_V1_CA_CRT" will allow V1 CAs in chains.
> ...but all the verify_flags are not available this way.  Can this be
> changed or is that intentional?  If it's intentional I'll provide all
> those flags as API options since I can imagine we'll need them.

It is intentional. You have to pick the default flags for the subsystem
that you're building, and some flags that related to key strength can
be overriden with a priority string.

The flags are not supposed to be used by an end-user.

> 3) emacs_gnutls_verify: verify the host name (this will be optional):

Why optional? This as important as everything else.

> 4) emacs_gnutls_verify: load $CERTSTORE/HOSTNAME.pem for the current
> hostname.  If it's equivalent to the server's presented certificate (is
> there a certificate_equals() function or do I just use memcmp?), the
> verification passes and return approved.

You mean to compare strings? You can compare them as you would compare
two UTF-8 strings, no special function is required.

regards,
Nikos




From INVALID.NOREPLY at gnu.org  Thu Oct  7 09:27:14 2010
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Thu, 07 Oct 2010 07:27:14 +0000
Subject: [sr #106112] Uses way too much entropy
In-Reply-To: <20100703-134306.sv707.58941@savannah.gnu.org>
References: <20071205-124005.sv0.79845@savannah.gnu.org>
	<20071206-091128.sv0.39656@savannah.gnu.org>
	<20071206-160338.sv64085.59071@savannah.gnu.org>
	<20080205-082001.sv7213.54742@savannah.gnu.org>
	<20080813-132516.sv7213.805@savannah.gnu.org>
	<20090604-092255.sv7213.4803@savannah.gnu.org>
	<20100703-134306.sv707.58941@savannah.gnu.org>
Message-ID: <20101007-102714.sv707.83478@savannah.gnu.org>


Update of sr #106112 (project gnutls):

             Open/Closed:                    Open => Closed                 


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?106112>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From INVALID.NOREPLY at gnu.org  Thu Oct  7 09:27:01 2010
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Thu, 07 Oct 2010 07:27:01 +0000
Subject: [sr #106541] DTLS implementation
In-Reply-To: <20100703-134144.sv707.18044@savannah.gnu.org>
References: <20081103-204148.sv0.61349@savannah.gnu.org>
	<20081104-073136.sv7213.22042@savannah.gnu.org>
	<20081215-152152.sv7213.28064@savannah.gnu.org>
	<20090804-145247.sv7213.26024@savannah.gnu.org>
	<20100703-134144.sv707.18044@savannah.gnu.org>
Message-ID: <20101007-102701.sv707.22564@savannah.gnu.org>


Update of sr #106541 (project gnutls):

             Open/Closed:                    Open => Closed                 


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?106541>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From INVALID.NOREPLY at gnu.org  Thu Oct  7 09:26:40 2010
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Thu, 07 Oct 2010 07:26:40 +0000
Subject: [sr #107489] ipsec_ike_key created in wrong code path
In-Reply-To: <20101005-131355.sv80249.94138@savannah.gnu.org>
References: <20101002-133639.sv80249.56906@savannah.gnu.org>
	<20101002-140156.sv80249.19148@savannah.gnu.org>
	<20101002-183453.sv80249.43612@savannah.gnu.org>
	<20101003-003459.sv707.4922@savannah.gnu.org>
	<20101004-172829.sv80249.19715@savannah.gnu.org>
	<20101004-173519.sv80249.7650@savannah.gnu.org>
	<20101005-065517.sv0.3749@savannah.gnu.org>
	<20101005-131355.sv80249.94138@savannah.gnu.org>
Message-ID: <20101007-102640.sv707.73711@savannah.gnu.org>


Follow-up Comment #8, sr #107489 (project gnutls):

In line:
if (get_ipsec_ike_status && (get_sign_status (get_tls_server_status()) !=1))

You check for get_ipsec_ike_status which is always non-zero since it is a
pointer to a function and the patch does not apply cleanly to 2.8.x branch.
Probably you meant to check for something else there. Could you create a test
script similar to the existing "sha2" that will check the expected behavior?
This will make it much easier to verify that everything works as expected.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107489>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From tzz at lifelogs.com  Thu Oct  7 16:59:00 2010
From: tzz at lifelogs.com (Ted Zlatanov)
Date: Thu, 07 Oct 2010 09:59:00 -0500
Subject: recommendations for storage of accepted certificates
References: <87eic9itf7.fsf@lifelogs.com> <4CA6D666.301@gnutls.org>
	<874od4k398.fsf@lifelogs.com> <4CA82408.4040505@gnutls.org>
	<87mxquhh5r.fsf@lifelogs.com>
	<AANLkTim4qQO98AL+-QQhECPTe8_p35VQqc8YEZNnVcqG@mail.gmail.com>
	<87pqvogb9o.fsf@lifelogs.com> <4CAD73F6.3060601@gnutls.org>
Message-ID: <877hhu122z.fsf@lifelogs.com>

On Thu, 07 Oct 2010 09:17:10 +0200 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote: 

NM> On 10/05/2010 12:54 PM, Ted Zlatanov wrote:

>> Also, rather than setting the
>> verify_flags, it seems cleaner to use these priority string options in
>> Emacs Lisp: 
>> "%VERIFY_ALLOW_SIGN_RSA_MD5" will allow RSA-MD5 signatures in certificate chains.
>> "%VERIFY_ALLOW_X509_V1_CA_CRT" will allow V1 CAs in chains.
>> ...but all the verify_flags are not available this way.  Can this be
>> changed or is that intentional?  If it's intentional I'll provide all
>> those flags as API options since I can imagine we'll need them.

NM> It is intentional. You have to pick the default flags for the subsystem
NM> that you're building, and some flags that related to key strength can
NM> be overriden with a priority string.

NM> The flags are not supposed to be used by an end-user.

See below...

>> 3) emacs_gnutls_verify: verify the host name (this will be optional):

NM> Why optional? This as important as everything else.

In the context of Emacs, I think it makes sense: I'm providing an API
wrapper at the ELisp level and not a complete SSL/TLS interface.  So
there can be some applications or users that find it necessary to
disable the host name check.  I'll make the default to verify, of
course.

Similarly for the verify_flags, the application or user may need a
specific subset.  So I'll provide them as options if they are not
available in the priority string.

If you think either of these is going to cause problems, let me know.  

I tend to err on the side of configurability because of it's a strong
tradition throughout the Emacs editor and the Emacs community.

>> 4) emacs_gnutls_verify: load $CERTSTORE/HOSTNAME.pem for the current
>> hostname.  If it's equivalent to the server's presented certificate (is
>> there a certificate_equals() function or do I just use memcmp?), the
>> verification passes and return approved.

NM> You mean to compare strings? You can compare them as you would compare
NM> two UTF-8 strings, no special function is required.

OK.  I didn't know that was sufficient.

Thanks
Ted




From INVALID.NOREPLY at gnu.org  Fri Oct  8 08:37:15 2010
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Fri, 08 Oct 2010 06:37:15 +0000
Subject: [sr #107489] ipsec_ike_key created in wrong code path
In-Reply-To: <20101007-102640.sv707.73711@savannah.gnu.org>
References: <20101002-133639.sv80249.56906@savannah.gnu.org>
	<20101002-140156.sv80249.19148@savannah.gnu.org>
	<20101002-183453.sv80249.43612@savannah.gnu.org>
	<20101003-003459.sv707.4922@savannah.gnu.org>
	<20101004-172829.sv80249.19715@savannah.gnu.org>
	<20101004-173519.sv80249.7650@savannah.gnu.org>
	<20101005-065517.sv0.3749@savannah.gnu.org>
	<20101005-131355.sv80249.94138@savannah.gnu.org>
	<20101007-102640.sv707.73711@savannah.gnu.org>
Message-ID: <20101008-093715.sv707.54871@savannah.gnu.org>


Follow-up Comment #9, sr #107489 (project gnutls):

I've checked again the patch and I think the one without the last fix is
quite better. That is because you call functions to verify values such as
get_sign_status (get_tls_server_status()) that work pretty ok in the batch
mode, but have issues in the interactive mode (such as asking the same
questions again and again). 

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107489>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From nmav at gnutls.org  Fri Oct  8 08:46:21 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 08 Oct 2010 08:46:21 +0200
Subject: gnutls 2.11.2
Message-ID: <4CAEBE3D.6040609@gnutls.org>

Hello,

The GnuTLS 2.11.x branch is NOT what you want for your stable system.
It is intended for developers and experienced users.

This is major update release that includes features such as PKCS #11
support for cryptographic objects, support for local system thread
locks, new message buffering layer, support for nettle library and more.

Here are the compressed sources:
  ftp://ftp.gnutls.org/pub/gnutls/devel/gnutls-2.11.2.tar.bz2
  ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.11.2.tar.bz2

Here is the OpenPGP signature:
  ftp://ftp.gnutls.org/pub/gnutls/devel/gnutls-2.11.2.tar.bz2.sig
  ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.11.2.tar.bz2.sig

regards,
Nikos

* Version 2.11.2 (released 2010-10-08)

** libgnutls: Several bug fixes on session resumption
and session tickets support.

** libgnutls: Add new extended key usage ipsecIKE.

** certtool: Renamed PKCS #11 options to: --p11-provider,
--p11-export-url, --p11-list-certs, --p11-list-certs,
--p11-list-privkeys, --p11-list-trusted, --p11-list-all-certs,
--p11-list-all, --p11-list-tokens, --p11-login, --p11-write,
--p11-write-label, --p11-write-trusted, --p11-detailed-url,
--p11-delete-url

** libgnutls: Corrected bug that caused importing DSA keys as RSA,
introduced with the new nettle code.

** libgnutls: Corrected advertizing issue for session tickets.

** API and ABI modifications:
gnutls_x509_crt_get_subject_unique_id: ADDED.
gnutls_x509_crt_get_issuer_unique_id: ADDED.



From ametzler at downhill.at.eu.org  Fri Oct  8 20:16:27 2010
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Fri, 8 Oct 2010 20:16:27 +0200
Subject: Nettle as default (was: gnutls 2.11.1)
In-Reply-To: <4C8F62FE.1020808@gnutls.org>
References: <4C8F62FE.1020808@gnutls.org>
Message-ID: <20101008181626.GB2104@downhill.g.la>

On 2010-09-14 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
[...]
> * Version 2.11.1 (released 2010-09-14)

> ** libgnutls: Nettle is the default crypto back end. Use
> --with-libgcrypt to use the libgcrypt back end.

> ** libgnutls: Depend on nettle 2.1. This makes nettle a fully working
> backend crypto library.
[...]

Hello,

I suspect we will need to keep using gcrypt in Debian for license
reasons. Nettle is GPL (at least some parts, blowfish and serpent)
instead og GnuTLS' LGP-2.1+.

cu andreas



From nmav at gnutls.org  Fri Oct  8 21:27:25 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 08 Oct 2010 21:27:25 +0200
Subject: Nettle as default
In-Reply-To: <20101008181626.GB2104@downhill.g.la>
References: <4C8F62FE.1020808@gnutls.org> <20101008181626.GB2104@downhill.g.la>
Message-ID: <4CAF709D.2020908@gnutls.org>

On 10/08/2010 08:16 PM, Andreas Metzler wrote:

> Hello,
> I suspect we will need to keep using gcrypt in Debian for license
> reasons. Nettle is GPL (at least some parts, blowfish and serpent)
> instead og GnuTLS' LGP-2.1+.

In gnutls serpent and blowfish are not used at all.

Niels would there be other GPL parts of nettle except serpent and
blowfish? Would there be a way to have an LGPL-only nettle (I suppose
the GPL would be a problem for the shared library).


regards,
Nikos



From nisse at lysator.liu.se  Fri Oct  8 23:51:44 2010
From: nisse at lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=)
Date: Fri, 08 Oct 2010 23:51:44 +0200
Subject: Nettle as default
In-Reply-To: <4CAF709D.2020908@gnutls.org> (Nikos Mavrogiannopoulos's message
	of "Fri, 08 Oct 2010 21:27:25 +0200")
References: <4C8F62FE.1020808@gnutls.org>
	<20101008181626.GB2104@downhill.g.la> <4CAF709D.2020908@gnutls.org>
Message-ID: <nniq1c8ia7.fsf@stalhein.lysator.liu.se>

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> Niels would there be other GPL parts of nettle except serpent and
> blowfish?

Not that I'm aware of.

> Would there be a way to have an LGPL-only nettle

In principle, you can delete the files which are not LGPL-compatible,
and make the necessary tweaks to the build system. The result could then
be distributed and used under the terms of the LGPL. But that's of
course not very convenient.

Personally, I'm a bit pragmatic, and I say the following in the manual:

  This means that if you don't use the parts of nettle that are
  GPL-only, you have the option to use the Nettle library just as if it
  were licensed under the LGPL.

For static libraries, that's more or less obvious (the object code
corresponding to the serpent and blowfish source code won't be copied
into the executable).

For shared libraries, I don't see a big problem linking a proprietary
(or otherwise non-GPL-compatible executable) with a nettle library
containing those GPL:ed files, in the special case that those functions
are not used and that the executable would link successfully and work in
exactly the same way if one substituted the nettle shared library with a
hacked version in which all GPL:ed functions are removed (and with no
other changes). But I understand not everyone will agree with my
judgement here.

Adding a configure option like --enable-lgpl-compatibility has been
suggested. The meaning would be to include only LGPL-compatible files in
the built libraries and executables. I have not given the subtle details
much thought (such as what sonames should be used, and how to keep both
default nettle and lgpl-compatible variants of libnettle.so on the same
system). Suggestions are welcome.

But I suspect such a configure option would not really help you; if you
don't agree with my thinking that it's ok to link a non-gpl program with
a library which contains some gpl code which the executable doesn't use
at all, you still can't link to the shared nettle library provided by
debian (since that ought to include the full set of algorithms). You'd
need to provide a separate lgpl-only shared nettle library, and then
maybe it would be easier for you to just link libgnutls.so statically to
nettle (have a look at the code size of the objects you'll pull in
before ruling this option out). Might be against debian policy though,
and have some practical problems in case there's some security problem
in nettle which must be fixed.

Long term, the best way would naturally be to simply replace the
non-lgpl-compatible code. For blowfish, that's no big deal (just copy
the version in libgcrypt and convert it to nettle conventions; patches
to do that are welcome). For serpent, I'm not aware of any other
implementation than the gpl:ed one I use, but I may well be missing
something.

Regards,
/Niels

-- 
Niels M?ller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.



From ametzler at downhill.at.eu.org  Sat Oct  9 15:15:28 2010
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Sat, 9 Oct 2010 15:15:28 +0200
Subject: Nettle as default
In-Reply-To: <nniq1c8ia7.fsf@stalhein.lysator.liu.se>
References: <4C8F62FE.1020808@gnutls.org> <20101008181626.GB2104@downhill.g.la>
	<4CAF709D.2020908@gnutls.org>
	<nniq1c8ia7.fsf@stalhein.lysator.liu.se>
Message-ID: <20101009131528.GA2101@downhill.g.la>

On 2010-10-08 Niels M?ller <nisse at lysator.liu.se> wrote:
> Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:
[...]
> > Would there be a way to have an LGPL-only nettle

[...]
> Adding a configure option like --enable-lgpl-compatibility has been
> suggested. The meaning would be to include only LGPL-compatible files in
> the built libraries and executables. I have not given the subtle details
> much thought (such as what sonames should be used, and how to keep both
> default nettle and lgpl-compatible variants of libnettle.so on the same
> system). Suggestions are welcome.
[...]

Hello,
How about doing it the GnuTLS way? GnuTLS consists of a of a core LGPL
library (libgnutls) and libgnutls-extra, which only contains the GPL
licensed stuff. Applications which only need the LGPL parts link
against libgnutls, those that require the GPL stuff link against both
libraries.

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 wk at gnupg.org  Sun Oct 10 17:40:40 2010
From: wk at gnupg.org (Werner Koch)
Date: Sun, 10 Oct 2010 17:40:40 +0200
Subject: Nettle as default
In-Reply-To: <nniq1c8ia7.fsf@stalhein.lysator.liu.se> ("Niels =?utf-8?Q?M?=
	=?utf-8?Q?=C3=B6ller=22's?=
	message of "Fri, 08 Oct 2010 23:51:44 +0200")
References: <4C8F62FE.1020808@gnutls.org>
	<20101008181626.GB2104@downhill.g.la> <4CAF709D.2020908@gnutls.org>
	<nniq1c8ia7.fsf@stalhein.lysator.liu.se>
Message-ID: <87sk0e5a4n.fsf@vigenere.g10code.de>

On Fri,  8 Oct 2010 23:51, nisse at lysator.liu.se said:

> to do that are welcome). For serpent, I'm not aware of any other
> implementation than the gpl:ed one I use, but I may well be missing
> something.

You are missing Libgcrypt; we have Serpent support for 7 years.  BTW,
the offcial OID for Serpent is below the FSF arc.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.




From andrew.w.nosenko at gmail.com  Sun Oct 10 22:23:48 2010
From: andrew.w.nosenko at gmail.com (Andrew W. Nosenko)
Date: Sun, 10 Oct 2010 23:23:48 +0300
Subject: Nettle as default
In-Reply-To: <nniq1c8ia7.fsf@stalhein.lysator.liu.se>
References: <4C8F62FE.1020808@gnutls.org> <20101008181626.GB2104@downhill.g.la>
	<4CAF709D.2020908@gnutls.org>
	<nniq1c8ia7.fsf@stalhein.lysator.liu.se>
Message-ID: <AANLkTimyp1XWFTc_8U9A5v_HOsaTCAzU4p1WfTEZU_s8@mail.gmail.com>

On Sat, Oct 9, 2010 at 00:51, Niels M?ller <nisse at lysator.liu.se> wrote:
> Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:
>
>> Niels would there be other GPL parts of nettle except serpent and
>> blowfish?
>
> Not that I'm aware of.
>
>> Would there be a way to have an LGPL-only nettle
>
> In principle, you can delete the files which are not LGPL-compatible,
> and make the necessary tweaks to the build system. The result could then
> be distributed and used under the terms of the LGPL. But that's of
> course not very convenient.
>
> Personally, I'm a bit pragmatic, and I say the following in the manual:
>
> ?This means that if you don't use the parts of nettle that are
> ?GPL-only, you have the option to use the Nettle library just as if it
> ?were licensed under the LGPL.
>
> For static libraries, that's more or less obvious (the object code
> corresponding to the serpent and blowfish source code won't be copied
> into the executable).
>
> For shared libraries, I don't see a big problem linking a proprietary
> (or otherwise non-GPL-compatible executable) with a nettle library
> containing those GPL:ed files, in the special case that those functions
> are not used and that the executable would link successfully and work in
> exactly the same way if one substituted the nettle shared library with a
> hacked version in which all GPL:ed functions are removed (and with no
> other changes). But I understand not everyone will agree with my
> judgement here.
>
> Adding a configure option like --enable-lgpl-compatibility has been
> suggested. The meaning would be to include only LGPL-compatible files in
> the built libraries and executables. I have not given the subtle details
> much thought (such as what sonames should be used, and how to keep both
> default nettle and lgpl-compatible variants of libnettle.so on the same
> system). Suggestions are welcome.
>
> But I suspect such a configure option would not really help you; if you
> don't agree with my thinking that it's ok to link a non-gpl program with
> a library which contains some gpl code which the executable doesn't use
> at all, you still can't link to the shared nettle library provided by
> debian (since that ought to include the full set of algorithms). You'd
> need to provide a separate lgpl-only shared nettle library, and then
> maybe it would be easier for you to just link libgnutls.so statically to
> nettle (have a look at the code size of the objects you'll pull in
> before ruling this option out). Might be against debian policy though,
> and have some practical problems in case there's some security problem
> in nettle which must be fixed.
>
> Long term, the best way would naturally be to simply replace the
> non-lgpl-compatible code. For blowfish, that's no big deal (just copy
> the version in libgcrypt and convert it to nettle conventions; patches
> to do that are welcome). For serpent, I'm not aware of any other
> implementation than the gpl:ed one I use, but I may well be missing
> something.

I see two variants more or less convinient for all variants (no
options like --enable/disable-gpl involved at all):

1.  2 shared libraries:
    libnettle-lgpl.so  -- LGPL compatible code, suitable for linking
itself (like Nettle would to build with GPL code removed), if nettle
contains utility support/framework functionts, they are here also
    libnettle-gpl.so -- GPL code only, linked with libnettle-lgpl.so
therefore by linking with libnettle-lgpl.so you are LGPL clean, by
linking with libnettle-gpl.so you have full fetured Nettle (LGPL part
going through inter-library dependence).

2. 3 libraries (variation about variant #1):
    libnettle-lgpl.so  -- LGPL compatible code, suitable for linking
itself (like Nettle would to build with GPL code removed), if nettle
contains utility support/framework functionts, they are here also
    libnettle-gpl.so -- GPL code only
    libnettle.so -- dummy library linked with both libnettle-lgpl.so
and libnettle-gpl.so and therefore GPL licensed.  Just for keep the
backward compatible name.

"Inter-library dependence" or "linked with..." doesn't need to be at
the system's ld.so level.  It may be just looks like for developer
point of view and be implemented through additional "metadata" like
pkg-config's .pc file or libtool's .la file.

Therefore, you won't need to have a kinds of packages, configs or
builds.  One build will have anything for satisfy both needs.

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



From nisse at lysator.liu.se  Mon Oct 11 12:39:33 2010
From: nisse at lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=)
Date: Mon, 11 Oct 2010 12:39:33 +0200
Subject: Nettle as default
In-Reply-To: <20101009131528.GA2101@downhill.g.la> (Andreas Metzler's message
	of "Sat, 9 Oct 2010 15:15:28 +0200")
References: <4C8F62FE.1020808@gnutls.org>
	<20101008181626.GB2104@downhill.g.la> <4CAF709D.2020908@gnutls.org>
	<nniq1c8ia7.fsf@stalhein.lysator.liu.se>
	<20101009131528.GA2101@downhill.g.la>
Message-ID: <nneibx813u.fsf@stalhein.lysator.liu.se>

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

> How about doing it the GnuTLS way? GnuTLS consists of a of a core LGPL
> library (libgnutls) and libgnutls-extra, which only contains the GPL
> licensed stuff.

Technically, that's most likely the cleanest way to do it. But I'd
prefer not to have to split the library up further like that.

Regards,
/Niels

-- 
Niels M?ller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.



From nisse at lysator.liu.se  Mon Oct 11 12:50:04 2010
From: nisse at lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=)
Date: Mon, 11 Oct 2010 12:50:04 +0200
Subject: Nettle as default
In-Reply-To: <87sk0e5a4n.fsf@vigenere.g10code.de> (Werner Koch's message of
	"Sun, 10 Oct 2010 17:40:40 +0200")
References: <4C8F62FE.1020808@gnutls.org>
	<20101008181626.GB2104@downhill.g.la> <4CAF709D.2020908@gnutls.org>
	<nniq1c8ia7.fsf@stalhein.lysator.liu.se>
	<87sk0e5a4n.fsf@vigenere.g10code.de>
Message-ID: <nnaaml80mb.fsf@stalhein.lysator.liu.se>

Werner Koch <wk at gnupg.org> writes:

> You are missing Libgcrypt; we have Serpent support for 7 years.

Great! Then the easiest way to make nettle LGPL all the way is to simply
replace Blowfish and Serpent by libgrypt's implementation.

What's the origin of libgcrypt's serpent implementation? The Serpent
code in Nettle is based on the original GPLed implementation by the
Serpent team (Ross Anderson, Eli Biham, and Lars Knudsen). When I mailed
them years ago they were unwilling to relicense it as LGPL (IIRC, for
practical rather than philosophical reasons).

Regards,
/Niels

-- 
Niels M?ller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.



From wk at gnupg.org  Mon Oct 11 19:09:22 2010
From: wk at gnupg.org (Werner Koch)
Date: Mon, 11 Oct 2010 19:09:22 +0200
Subject: Nettle as default
In-Reply-To: <nnaaml80mb.fsf@stalhein.lysator.liu.se> ("Niels =?utf-8?Q?M?=
	=?utf-8?Q?=C3=B6ller=22's?=
	message of "Mon, 11 Oct 2010 12:50:04 +0200")
References: <4C8F62FE.1020808@gnutls.org>
	<20101008181626.GB2104@downhill.g.la> <4CAF709D.2020908@gnutls.org>
	<nniq1c8ia7.fsf@stalhein.lysator.liu.se>
	<87sk0e5a4n.fsf@vigenere.g10code.de>
	<nnaaml80mb.fsf@stalhein.lysator.liu.se>
Message-ID: <87fwwc64hp.fsf@vigenere.g10code.de>

On Mon, 11 Oct 2010 12:50, nisse at lysator.liu.se said:

> What's the origin of libgcrypt's serpent implementation? The Serpent
> code in Nettle is based on the original GPLed implementation by the

IIRC, Moritz took the S-boxes from the reference implementation and
rewrote the other code:

/* These are the S-Boxes of Serpent.  They are copied from Serpents
   reference implementation (the optimized one, contained in
   `floppy2') and are therefore:

     Copyright (C) 1998 Ross Anderson, Eli Biham, Lars Knudsen.

  To quote the Serpent homepage
  (http://www.cl.cam.ac.uk/~rja14/serpent.html):

  "Serpent is now completely in the public domain, and we impose no
   restrictions on its use.  This was announced on the 21st August at
   the First AES Candidate Conference. The optimised implementations
   in the submission package are now under the GNU PUBLIC LICENSE
   (GPL), although some comments in the code still say otherwise. You
   are welcome to use Serpent for any application."  */

Might not be the best optimized code, though.


Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.




From simon at josefsson.org  Thu Oct 14 16:04:23 2010
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 14 Oct 2010 16:04:23 +0200
Subject: GnuTLS 2.11.3
Message-ID: <878w20yioo.fsf@mocca.josefsson.org>

The GnuTLS 2.11.x branch is NOT what you want for your stable system.
It is intended for developers and experienced users.

Here are the compressed sources:
  ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.11.3.tar.bz2
  http://alpha.gnu.org/gnu/gnutls/gnutls-2.11.3.tar.bz2

Here is the OpenPGP signature:
  ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.11.3.tar.bz2.sig
  http://alpha.gnu.org/gnu/gnutls/gnutls-2.11.3.tar.bz2.sig

Happy Hacking,
Simon

* Version 2.11.3 (released 2010-10-14)

** Indent code to follow the GNU Coding Standard.
You should be able to unpack the 2.11.2 release and run 'make indent'
twice to get exactly the same content as 2.11.3 except for generated
files.  Using GNU Indent 2.2.11.

** API and ABI modifications:
No changes since last version.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 420 bytes
Desc: not available
URL: </pipermail/attachments/20101014/6dd2efd8/attachment.pgp>

From simon at josefsson.org  Thu Oct 14 21:29:18 2010
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 14 Oct 2010 21:29:18 +0200
Subject: GnuTLS guile self checks takes a lot of time
Message-ID: <87lj60tvxt.fsf@mocca.josefsson.org>

Ludo,

I just ran 'make distcheck' with GnuTLS and noticed that the guile self
checks are taken a lot of time.  They are stuck reading /dev/*random to
generate DH parameters or RSA parameters.  Search for
'make-dh-parameters'.  Is there any reason you need a fresh DH/RSA
parameter every time these self tests run?  In the C self tests, it
loads a static DH/RSA parameter hard coded in the binary instead, which
avoids expensive prime generation.

This may suggest a real problem in the randomness code -- I thought it
should be quicker now than with libgcrypt -- but I think it would be
good to fix the self tests to not cause prime generations except when it
is those particular functions that are tested.

/Simon



From nmav at gnutls.org  Thu Oct 14 22:02:48 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 14 Oct 2010 22:02:48 +0200
Subject: GnuTLS guile self checks takes a lot of time
In-Reply-To: <87lj60tvxt.fsf@mocca.josefsson.org>
References: <87lj60tvxt.fsf@mocca.josefsson.org>
Message-ID: <4CB761E8.7050508@gnutls.org>

On 10/14/2010 09:29 PM, Simon Josefsson wrote:
> Ludo,
> This may suggest a real problem in the randomness code -- I thought it
> should be quicker now than with libgcrypt -- but I think it would be
> good to fix the self tests to not cause prime generations except when it
> is those particular functions that are tested.

The nettle code shouldn't have caused multiple reads to /dev/*random. It
reads 32 bytes on initialization from /dev/urandom and will read some
more after few hours. Which test causes this delay?

regards,
Nikos



From simon at josefsson.org  Thu Oct 14 22:23:29 2010
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 14 Oct 2010 22:23:29 +0200
Subject: GnuTLS guile self checks takes a lot of time
In-Reply-To: <87lj60tvxt.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Thu, 14 Oct 2010 21:29:18 +0200")
References: <87lj60tvxt.fsf@mocca.josefsson.org>
Message-ID: <87ocawr0am.fsf@mocca.josefsson.org>

Simon Josefsson <simon at josefsson.org> writes:

> Ludo,
>
> I just ran 'make distcheck' with GnuTLS and noticed that the guile self
> checks are taken a lot of time.  They are stuck reading /dev/*random to
> generate DH parameters or RSA parameters.  Search for
> 'make-dh-parameters'.  Is there any reason you need a fresh DH/RSA
> parameter every time these self tests run?  In the C self tests, it
> loads a static DH/RSA parameter hard coded in the binary instead, which
> avoids expensive prime generation.

I have fixed this:

http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=e8decd82ed4be106b5ba9ca250b8b54e1aec522b

This is mostly cut'n'paste, so please correct my guile code.

/Simon



From simon at josefsson.org  Thu Oct 14 22:34:00 2010
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 14 Oct 2010 22:34:00 +0200
Subject: DH prime generation taking a long time
In-Reply-To: <4CB761E8.7050508@gnutls.org> (Nikos Mavrogiannopoulos's message
	of "Thu, 14 Oct 2010 22:02:48 +0200")
References: <87lj60tvxt.fsf@mocca.josefsson.org> <4CB761E8.7050508@gnutls.org>
Message-ID: <87k4lkqzt3.fsf_-_@mocca.josefsson.org>

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> On 10/14/2010 09:29 PM, Simon Josefsson wrote:
>> Ludo,
>> This may suggest a real problem in the randomness code -- I thought it
>> should be quicker now than with libgcrypt -- but I think it would be
>> good to fix the self tests to not cause prime generations except when it
>> is those particular functions that are tested.
>
> The nettle code shouldn't have caused multiple reads to /dev/*random. It
> reads 32 bytes on initialization from /dev/urandom and will read some
> more after few hours. Which test causes this delay?

Newly committed self-test tests/gendh.c triggers it too.  Running strace
on it reveals it is calling time() a lot, which suggests it is spending
time in nettle/rnd.c.  This is with GnuTLS built with Nettle as backend.

open("/dev/urandom", O_RDONLY)          = 3
fcntl64(3, F_GETFD)                     = 0
fcntl64(3, F_SETFD, FD_CLOEXEC)         = 0
read(3, "...", 32) = 32
gettimeofday({1287088271, 237216}, NULL) = 0
open("/etc/gnutls/pkcs11.conf", O_RDONLY) = -1 ENOENT (No such file or directory)
gettimeofday({1287088271, 243685}, NULL) = 0
time(NULL)                              = 1287088271
gettimeofday({1287088271, 243786}, NULL) = 0
time(NULL)                              = 1287088271
gettimeofday({1287088271, 243857}, NULL) = 0
time(NULL)                              = 1287088271
...
gettimeofday({1287088331, 926694}, NULL) = 0
time(NULL)                              = 1287088331
gettimeofday({1287088332, 156845}, NULL) = 0
time(NULL)                              = 1287088332
fstat64(1, {st_mode=S_IFREG|0644, st_size=4779192, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb76a9000
write(1, "generated DH params OKSelf test "..., 65generated DH params OKSelf test `./gendh' finished with 0 errors
) = 65
exit_group(0)                           = ?

/Simon



From INVALID.NOREPLY at gnu.org  Fri Oct 15 09:40:17 2010
From: INVALID.NOREPLY at gnu.org (anonymous)
Date: Fri, 15 Oct 2010 07:40:17 +0000
Subject: [sr #107495] gnutls_bye() blocks on network issues
Message-ID: <20101015-074016.sv0.24620@savannah.gnu.org>


URL:
  <http://savannah.gnu.org/support/?107495>

                 Summary: gnutls_bye() blocks on network issues
                 Project: GnuTLS
            Submitted by: None
            Submitted on: Fri Oct 15 07:40:15 2010
                Category: None
                Priority: 5 - Normal
                Severity: 3 - Normal
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: arthur at arthurdejong.org
             Open/Closed: Open
         Discussion Lock: Any
        Operating System: None

    _______________________________________________________

Details:

The problem is that when a network problem occurs (a TCP connection is
severed with iptables in this test) GnuTLS blocks on a read() when shutting
down the connection.

This was a problem originally submitted to the nss-pam-ldapd project [0].
This was reported to the OpenLDAP project [1] where it was determined that it
is probably a bug in GnuTLS (the problem is not there when using OpenSSL).

I don't use the GnuTLS API myself so I don't know any details about it. If
you need more info, feel free to ask though.

[0] http://bugs.debian.org/596983
[1] http://www.openldap.org/its/index.cgi?selectid=6673





    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107495>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From INVALID.NOREPLY at gnu.org  Fri Oct 15 09:56:53 2010
From: INVALID.NOREPLY at gnu.org (Simon Josefsson)
Date: Fri, 15 Oct 2010 07:56:53 +0000
Subject: [sr #107495] gnutls_bye() blocks on network issues
In-Reply-To: <20101015-074016.sv0.24620@savannah.gnu.org>
References: <20101015-074016.sv0.24620@savannah.gnu.org>
Message-ID: <20101015-075653.sv7213.62214@savannah.gnu.org>


Follow-up Comment #1, sr #107495 (project gnutls):

How do you shut down the connection?  gnutls_bye() needs to talk to the other
server to negotiate a disconnect, otherwise things will be insecure (it was
one of the security issues with SSLv2).

Does it really block if you set the socket in non-blocking mode?

/Simon


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107495>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From nmav at gnutls.org  Fri Oct 15 09:59:46 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 15 Oct 2010 09:59:46 +0200
Subject: DH prime generation taking a long time
In-Reply-To: <87k4lkqzt3.fsf_-_@mocca.josefsson.org>
References: <87lj60tvxt.fsf@mocca.josefsson.org> <4CB761E8.7050508@gnutls.org>
	<87k4lkqzt3.fsf_-_@mocca.josefsson.org>
Message-ID: <AANLkTinC+zjL+x6m940KdFw97BL+HZy_Vf+fhrypp1YQ@mail.gmail.com>

On Thu, Oct 14, 2010 at 10:34 PM, Simon Josefsson <simon at josefsson.org> wrote:

>> The nettle code shouldn't have caused multiple reads to /dev/*random. It
>> reads 32 bytes on initialization from /dev/urandom and will read some
>> more after few hours. Which test causes this delay?
> Newly committed self-test tests/gendh.c triggers it too. ?Running strace
> on it reveals it is calling time() a lot, which suggests it is spending
> time in nettle/rnd.c. ?This is with GnuTLS built with Nettle as backend.

But do these calls actually cause a/the delay or the prime generation?



From INVALID.NOREPLY at gnu.org  Fri Oct 15 10:12:41 2010
From: INVALID.NOREPLY at gnu.org (anonymous)
Date: Fri, 15 Oct 2010 08:12:41 +0000
Subject: [sr #107495] gnutls_bye() blocks on network issues
In-Reply-To: <20101015-080735.sv0.85090@savannah.gnu.org>
References: <20101015-074016.sv0.24620@savannah.gnu.org>
	<20101015-075653.sv7213.62214@savannah.gnu.org>
	<20101015-080735.sv0.85090@savannah.gnu.org>
Message-ID: <20101015-081241.sv0.8744@savannah.gnu.org>


Follow-up Comment #3, sr #107495 (project gnutls):

I'm not sure what mechanism is used in OpenLDAP (I'm the developer of
nss-pam-ldapd and I don't know too much about OpenLDAP internals). ITS#6673
has a backtrace that may be helpful though.

I suspect OpenLDAP uses a blocking socket and uses select() to do polling. As
a user of the OpenLDAP API, the socket is mostly hidden for me. As a
workaround for this problem I get the socket from OpenLDAP and use
setsockopt() to set SO_RCVTIMEO and SO_SNDTIMEO.

I don't understand why you need to negotiate a disconnect though. If the TCP
connection is severed for some reason or the other end is not responsive I
don't see the extra security in trying to negotiate a disconnect. Am I missing
something?

Anyway, thanks for your response.

Arthur

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107495>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From INVALID.NOREPLY at gnu.org  Fri Oct 15 10:07:35 2010
From: INVALID.NOREPLY at gnu.org (anonymous)
Date: Fri, 15 Oct 2010 08:07:35 +0000
Subject: [sr #107495] gnutls_bye() blocks on network issues
In-Reply-To: <20101015-075653.sv7213.62214@savannah.gnu.org>
References: <20101015-074016.sv0.24620@savannah.gnu.org>
	<20101015-075653.sv7213.62214@savannah.gnu.org>
Message-ID: <20101015-080735.sv0.85090@savannah.gnu.org>


Follow-up Comment #2, sr #107495 (project gnutls):

This how is the typical TLS session closure works. In TLS the connection
closes if both peers agree on it (very few implementations though do that
right). If you want to set timeout or sockets to non blocking I/O you should
do it to the underlying layer (sockets). You could also non wait for reply
from the peer (by specifying to _WR only flag to _bye) but then you will be
vulnerable to attacks that terminate the connection prematurely.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107495>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From INVALID.NOREPLY at gnu.org  Fri Oct 15 10:26:04 2010
From: INVALID.NOREPLY at gnu.org (anonymous)
Date: Fri, 15 Oct 2010 08:26:04 +0000
Subject: [sr #107495] gnutls_bye() blocks on network issues
In-Reply-To: <20101015-081241.sv0.8744@savannah.gnu.org>
References: <20101015-074016.sv0.24620@savannah.gnu.org>
	<20101015-075653.sv7213.62214@savannah.gnu.org>
	<20101015-080735.sv0.85090@savannah.gnu.org>
	<20101015-081241.sv0.8744@savannah.gnu.org>
Message-ID: <20101015-082603.sv0.78492@savannah.gnu.org>


Follow-up Comment #4, sr #107495 (project gnutls):

On why this is required see the TLS protocol:
http://tools.ietf.org/html/rfc5246#section-7.2.1
But how would you distinguish a network error from
a truncation attack? Both should be detected by TLS.

Since openldap uses select you could use gnutls_bye with GNUTLS_SHUT_WR, and
once the socket is readable try to read
with gnutls_record_recv() which should return 0 (EOF). If it is not readable
within some time limit terminate the connection with error.




    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107495>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From INVALID.NOREPLY at gnu.org  Fri Oct 15 10:46:37 2010
From: INVALID.NOREPLY at gnu.org (Howard Chu)
Date: Fri, 15 Oct 2010 08:46:37 +0000
Subject: [sr #107495] gnutls_bye() blocks on network issues
In-Reply-To: <20101015-082603.sv0.78492@savannah.gnu.org>
References: <20101015-074016.sv0.24620@savannah.gnu.org>
	<20101015-075653.sv7213.62214@savannah.gnu.org>
	<20101015-080735.sv0.85090@savannah.gnu.org>
	<20101015-081241.sv0.8744@savannah.gnu.org>
	<20101015-082603.sv0.78492@savannah.gnu.org>
Message-ID: <20101015-084637.sv46754.6180@savannah.gnu.org>


Follow-up Comment #5, sr #107495 (project gnutls):

Notice in the RFC section you referenced:

_ It is not required for the initiator
   of the close to wait for the responding close_notify alert before
   closing the read side of the connection._

Judging from the comments, it seems we should just use GNUTLS_SHUT_WR instead
of GNUTLS_SHUT_RDWR.


re: _Since openldap uses select you could use gnutls_bye with GNUTLS_SHUT_WR,
and once the socket is readable try to read
with gnutls_record_recv() which should return 0 (EOF). If it is not readable
within some time limit terminate the connection with error._

OpenLDAP only calls gnutls_bye during a session teardown, so the connection
is already being terminated. Nobody is going to be attempting to read anything
more from the socket at that point, there's no point in select'ing on it for
readability.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107495>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From INVALID.NOREPLY at gnu.org  Fri Oct 15 10:51:26 2010
From: INVALID.NOREPLY at gnu.org (anonymous)
Date: Fri, 15 Oct 2010 08:51:26 +0000
Subject: [sr #107495] gnutls_bye() blocks on network issues
In-Reply-To: <20101015-084637.sv46754.6180@savannah.gnu.org>
References: <20101015-074016.sv0.24620@savannah.gnu.org>
	<20101015-075653.sv7213.62214@savannah.gnu.org>
	<20101015-080735.sv0.85090@savannah.gnu.org>
	<20101015-081241.sv0.8744@savannah.gnu.org>
	<20101015-082603.sv0.78492@savannah.gnu.org>
	<20101015-084637.sv46754.6180@savannah.gnu.org>
Message-ID: <20101015-085126.sv0.70026@savannah.gnu.org>


Follow-up Comment #6, sr #107495 (project gnutls):

Of course you are not required. You are not required to use TLS either. You
use those fascilities if you care about specific attacks, and in this case
about truncation attacks. If you don't care you don't have to use them. 


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107495>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From simon at josefsson.org  Fri Oct 15 11:11:43 2010
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 15 Oct 2010 11:11:43 +0200
Subject: DH prime generation taking a long time
In-Reply-To: <AANLkTinC+zjL+x6m940KdFw97BL+HZy_Vf+fhrypp1YQ@mail.gmail.com>
	(Nikos Mavrogiannopoulos's message of "Fri, 15 Oct 2010 09:59:46
	+0200")
References: <87lj60tvxt.fsf@mocca.josefsson.org> <4CB761E8.7050508@gnutls.org>
	<87k4lkqzt3.fsf_-_@mocca.josefsson.org>
	<AANLkTinC+zjL+x6m940KdFw97BL+HZy_Vf+fhrypp1YQ@mail.gmail.com>
Message-ID: <87iq13om5s.fsf@mocca.josefsson.org>

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> On Thu, Oct 14, 2010 at 10:34 PM, Simon Josefsson <simon at josefsson.org> wrote:
>
>>> The nettle code shouldn't have caused multiple reads to /dev/*random. It
>>> reads 32 bytes on initialization from /dev/urandom and will read some
>>> more after few hours. Which test causes this delay?
>> Newly committed self-test tests/gendh.c triggers it too. ?Running strace
>> on it reveals it is calling time() a lot, which suggests it is spending
>> time in nettle/rnd.c. ?This is with GnuTLS built with Nettle as backend.
>
> But do these calls actually cause a/the delay or the prime generation?

Nope, false alarm.  It is GMP operations that is taking time because of 

#define PRIME_CHECK_PARAM 18
...
      ret = mpz_probab_prime_p (w, PRIME_CHECK_PARAM);

Perhaps 18 is a too excessive number.  Are there established
recommendations on what number of repetitions are considered sufficient
for crypto purposes?  Maybe there should be...

/Simon



From simon at josefsson.org  Fri Oct 15 15:21:05 2010
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 15 Oct 2010 15:21:05 +0200
Subject: GnuTLS 2.11.4
Message-ID: <87bp6vioce.fsf@mocca.josefsson.org>

The GnuTLS 2.11.x branch is NOT what you want for your stable system.
It is intended for developers and experienced users.

Here are the compressed sources:
  ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.11.4.tar.bz2
  http://alpha.gnu.org/gnu/gnutls/gnutls-2.11.4.tar.bz2

Here is the OpenPGP signature:
  ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.11.4.tar.bz2.sig
  http://alpha.gnu.org/gnu/gnutls/gnutls-2.11.4.tar.bz2.sig

Happy Hacking,
Simon

* Version 2.11.4 (released 2010-10-15)

** libgnutls: Add new API gnutls_session_channel_binding.
The function is used to get the channel binding data.  Currently only
the "tls-unique" (RFC 5929) channel binding type is supported, through
the GNUTLS_CB_TLS_UNIQUE type.  See new section "Channel Bindings" in
the manual.

** gnutls-cli, gnutls-serv: Print 'tls-unique' Channel Bindings.

** doc: Added pkcs11.h header file to GTK-DOC manual.

** build: Update gnulib files.

** i18n: Update translations.

** tests: Add self tests gendh.c.  Speed up Guile self checks.

** API and ABI modifications:
gnutls_session_channel_binding: New function.
gnutls_channel_binding_t: New enumeration.
GNUTLS_CB_TLS_UNIQUE: New gnutls_channel_binding_t enum member.
GNUTLS_E_CHANNEL_BINDING_NOT_AVAILABLE: New error code.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 420 bytes
Desc: not available
URL: </pipermail/attachments/20101015/2d77b0e2/attachment.pgp>

From simon at josefsson.org  Sun Oct 17 23:31:26 2010
From: simon at josefsson.org (Simon Josefsson)
Date: Sun, 17 Oct 2010 23:31:26 +0200
Subject: GnuTLS guile self checks takes a lot of time
In-Reply-To: <877hhgh5xg.fsf@chbouib.org> ("Ludovic =?iso-8859-1?Q?Court?=
	=?iso-8859-1?Q?=E8s=22's?= message of
	"Sun, 17 Oct 2010 23:20:59 +0200")
References: <87lj60tvxt.fsf@mocca.josefsson.org>
	<87ocawr0am.fsf@mocca.josefsson.org> <877hhgh5xg.fsf@chbouib.org>
Message-ID: <878w1wo6a9.fsf@mocca.josefsson.org>

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

> Hi Simon,
>
> Sorry for not answering earlier.
>
> Simon Josefsson <simon at josefsson.org> writes:
>
>> Simon Josefsson <simon at josefsson.org> writes:
>>
>>> Ludo,
>>>
>>> I just ran 'make distcheck' with GnuTLS and noticed that the guile self
>>> checks are taken a lot of time.  They are stuck reading /dev/*random to
>>> generate DH parameters or RSA parameters.  Search for
>>> 'make-dh-parameters'.  Is there any reason you need a fresh DH/RSA
>>> parameter every time these self tests run?  In the C self tests, it
>>> loads a static DH/RSA parameter hard coded in the binary instead, which
>>> avoids expensive prime generation.
>>
>> I have fixed this:
>>
>> http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=e8decd82ed4be106b5ba9ca250b8b54e1aec522b
>>
>> This is mostly cut'n'paste, so please correct my guile code.
>
> This looks great to me, thanks?and welcome to Guile!  ;-)
>
> ISTR that this was much slower after the switch to Nettle.  Did you
> measure that?

Yes, it seems the DH parameter generating code is much slower with
Nettle compared to libgcrypt.  We are looking into that separately.  It
is stuck in bignum operations (not /dev/*random), so possibly it is just
a question of choosing the right number of Miller-Rabin iterations.

/Simon



From ludo at chbouib.org  Sun Oct 17 23:20:59 2010
From: ludo at chbouib.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Sun, 17 Oct 2010 23:20:59 +0200
Subject: GnuTLS guile self checks takes a lot of time
In-Reply-To: <87ocawr0am.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Thu, 14 Oct 2010 22:23:29 +0200")
References: <87lj60tvxt.fsf@mocca.josefsson.org>
	<87ocawr0am.fsf@mocca.josefsson.org>
Message-ID: <877hhgh5xg.fsf@chbouib.org>

Hi Simon,

Sorry for not answering earlier.

Simon Josefsson <simon at josefsson.org> writes:

> Simon Josefsson <simon at josefsson.org> writes:
>
>> Ludo,
>>
>> I just ran 'make distcheck' with GnuTLS and noticed that the guile self
>> checks are taken a lot of time.  They are stuck reading /dev/*random to
>> generate DH parameters or RSA parameters.  Search for
>> 'make-dh-parameters'.  Is there any reason you need a fresh DH/RSA
>> parameter every time these self tests run?  In the C self tests, it
>> loads a static DH/RSA parameter hard coded in the binary instead, which
>> avoids expensive prime generation.
>
> I have fixed this:
>
> http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=e8decd82ed4be106b5ba9ca250b8b54e1aec522b
>
> This is mostly cut'n'paste, so please correct my guile code.

This looks great to me, thanks?and welcome to Guile!  ;-)

ISTR that this was much slower after the switch to Nettle.  Did you
measure that?

Thanks,
Ludo?.



From arfrever.fta at gmail.com  Sun Oct 24 14:09:15 2010
From: arfrever.fta at gmail.com (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 24 Oct 2010 14:09:15 +0200
Subject: `pkg-config gnutls --variable=crypto_lib`
Message-ID: <201010241409.16287.Arfrever.FTA@gmail.com>

The attached patch adds support for `pkg-config gnutls --variable=crypto_lib`
so that users of GnuTLS can check crypto library used by GnuTLS.
It might be useful for build systems of packages, which use GnuTLS.

$ pkg-config gnutls --variable=crypto_lib
nettle

-- 
Arfrever Frehtes Taifersar Arahesis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gnutls-2.11.4-crypto_lib.patch
Type: text/x-patch
Size: 463 bytes
Desc: not available
URL: </pipermail/attachments/20101024/1fd65d9e/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20101024/1fd65d9e/attachment.pgp>

From nmav at gnutls.org  Sun Oct 24 14:44:02 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 24 Oct 2010 14:44:02 +0200
Subject: `pkg-config gnutls --variable=crypto_lib`
In-Reply-To: <201010241409.16287.Arfrever.FTA@gmail.com>
References: <201010241409.16287.Arfrever.FTA@gmail.com>
Message-ID: <4CC42A12.5080403@gnutls.org>

On 10/24/2010 02:09 PM, Arfrever Frehtes Taifersar Arahesis wrote:
> The attached patch adds support for `pkg-config gnutls --variable=crypto_lib`
> so that users of GnuTLS can check crypto library used by GnuTLS.
> It might be useful for build systems of packages, which use GnuTLS.

Why you need to know the backend library? The only reason that might
require knowing that is when you do conditional compilation with older
gnutls versions that use libgcrypt and pthreads. In that case you might
want to follow  the instructions in the "NEWS" file. That is use:

#if GNUTLS_VERSION_NUMBER <= 0x020b00
        gcry_control(...)
#endif

to distinguish between the situations where you need to call libgcrypt
to setup the threads explicitly (later gnutls versions implicitly
initialize thread support whether with libgcrypt or nettle).

regards,
Nikos



From arfrever.fta at gmail.com  Sun Oct 24 15:22:32 2010
From: arfrever.fta at gmail.com (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 24 Oct 2010 15:22:32 +0200
Subject: `pkg-config gnutls --variable=crypto_lib`
In-Reply-To: <4CC42A12.5080403@gnutls.org>
References: <201010241409.16287.Arfrever.FTA@gmail.com>
	<4CC42A12.5080403@gnutls.org>
Message-ID: <201010241523.04080.Arfrever.FTA@gmail.com>

2010-10-24 14:44:02 Nikos Mavrogiannopoulos napisa?(a):
> On 10/24/2010 02:09 PM, Arfrever Frehtes Taifersar Arahesis wrote:
> > The attached patch adds support for `pkg-config gnutls --variable=crypto_lib`
> > so that users of GnuTLS can check crypto library used by GnuTLS.
> > It might be useful for build systems of packages, which use GnuTLS.
> 
> Why you need to know the backend library? The only reason that might
> require knowing that is when you do conditional compilation with older
> gnutls versions that use libgcrypt and pthreads. In that case you might
> want to follow  the instructions in the "NEWS" file. That is use:
> 
> #if GNUTLS_VERSION_NUMBER <= 0x020b00
>         gcry_control(...)
> #endif
> 
> to distinguish between the situations where you need to call libgcrypt
> to setup the threads explicitly (later gnutls versions implicitly
> initialize thread support whether with libgcrypt or nettle).

I thought that this functionality might be useful for Neon. See:
http://lists.manyfish.co.uk/pipermail/neon/2010-October/001286.html

src/ne_gnutls.c of Neon contains:

int ne__ssl_init(void)
{
#ifdef NE_HAVE_TS_SSL
    gcry_control(GCRYCTL_SET_THREAD_CBS, &gcry_threads_pthread);
#endif
    gcry_control(GCRYCTL_ENABLE_QUICK_RANDOM, 0);
    return gnutls_global_init();
}

-- 
Arfrever Frehtes Taifersar Arahesis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20101024/ffa28620/attachment.pgp>

From wayne.connolly at measanctum.com  Mon Oct 25 09:22:50 2010
From: wayne.connolly at measanctum.com (Wayne Connolly)
Date: Mon, 25 Oct 2010 17:22:50 +1000
Subject: mod_gnutls incorrect cert issued by server
Message-ID: <4CC5304A.2000300@measanctum.com>

Hi all,

I just tried out mod-gnutls in apache 2.2.12 ubuntu 9.10 because mod-ssl 
is not a option (no TLS compiled into our version and no way to get it...)

All went perfect with the exception that one of the https sites always 
shows up the wrong cert.

Each 443 vhost is in its very own vhost file because having 
'ServerAlias' in the 443 section failed to recognise the ServerAlias 
correctly. This is good practice anyway.

So I have one IP - and mod_gnutls enabled and working for 5 of the 5 
domains.

It is close to working. I have 4 or the 5 domains working :

Working

    * https://portal.jglinvestments.com.au/
    * https://www.measanctum.com/
    * https://measanctum.com/
    * https://www.wendysmusic.com.au/

Faulty

    * https://wendysmusic.com.au/ <- uses the wrong certificate from
      MeaSanctum.com.


THEN::: The weird thing is that if i put a '0' in front of the vhost 
filename 0measanctum.com_SSL 0www.wendysmusic.com.au_SSL then apache 
reads the measanctum one first and the above situation is true. However 
if I remove the 0 from 0www.wendysmusic.com.au_SSL then the below happens


Working

     * https://portal.jglinvestments.com.au/
     * https://www.measanctum.com/
     * https://wendysmusic.com.au/
     * https://www.wendysmusic.com.au/

Faulty

     * https://measanctum.com/ <- uses the wrong certificate from 
*.wendysmusic.com.au.

Before you ask - all cert/docroots/domains have been triple checked by 
others and are correct. Why would the order change do this? Any tips?

P.S. This is driving me insane.

-- 
Kind Regards,

Wayne

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20101025/f4e92f3d/attachment.htm>

From nmav at gnutls.org  Mon Oct 25 13:09:15 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 25 Oct 2010 13:09:15 +0200
Subject: mod_gnutls incorrect cert issued by server
In-Reply-To: <4CC5304A.2000300@measanctum.com>
References: <4CC5304A.2000300@measanctum.com>
Message-ID: <AANLkTinv1e6Rt638=im5cxWb0O_B3J6=T3S7TN2jU0vZ@mail.gmail.com>

On Mon, Oct 25, 2010 at 9:22 AM, Wayne Connolly
<wayne.connolly at measanctum.com> wrote:

> I just tried out mod-gnutls in apache 2.2.12 ubuntu 9.10 because mod-ssl is
> not a option (no TLS compiled into our version and no way to get it...)
> All went perfect with the exception that one of the https sites always shows
> up the wrong cert.
> Each 443 vhost is in its very own vhost file because having 'ServerAlias' in
> the 443 section failed to recognise the ServerAlias correctly. This is good
> practice anyway.
[...]
> Before you ask - all cert/docroots/domains have been triple checked by
> others and are correct. Why would the order change do this? Any tips?

I suppose you use the latest mod_gnutls. Could you try enabling
debugging in mod_gnutls? (modify mod_gnutls.h to have MOD_GNUTLS_DEBUG
to 1 before compilation). The output will be placed in your /tmp.

regards,
Nikos



From INVALID.NOREPLY at gnu.org  Sun Oct 31 22:07:10 2010
From: INVALID.NOREPLY at gnu.org (Tomas Hoger)
Date: Sun, 31 Oct 2010 21:07:10 +0000
Subject: [sr #107508] gnutls: commit 41467217 missing in master
Message-ID: <20101031-210709.sv73003.67650@savannah.gnu.org>


URL:
  <http://savannah.gnu.org/support/?107508>

                 Summary: gnutls: commit 41467217 missing in master
                 Project: GnuTLS
            Submitted by: thoger
            Submitted on: Sun 31 Oct 2010 09:07:09 PM GMT
                Category: None
                Priority: 5 - Normal
                Severity: 2 - Minor
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
        Operating System: None

    _______________________________________________________

Details:

Commit 41467217 fixed safe renegotiation documentation in gnutls_priority.c
in 2.10.x branch, but the change was not merged to master and hence the
documentation in 2.11.x is incorrect (e.g. listing %PARTIAL_SAFE_RENEGOTIATION
instead of %PARTIAL_RENEGOTIATION).




    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107508>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/