From cloos at jhcloos.com  Fri Apr  5 19:53:11 2013
From: cloos at jhcloos.com (James Cloos)
Date: Fri, 05 Apr 2013 13:53:11 -0400
Subject: [gnutls-devel] ipv6 vs ipv4 vs udp
Message-ID: <m3ppy8amov.fsf@carbon.jhcloos.org>

The fallback from v6 to v4 works well for tcp, but not for udp.

I get something like:

:; gnutls-cli -u -p 5555 liberty.jhcloos.com
Processed 159 CA certificate(s).
Resolving 'liberty.jhcloos.com'...
Connecting to '2001:4830:1662::53:5555'...
*** Fatal error: The operation timed out
*** Handshake has failed
GnuTLS error: The operation timed out

There is an openssl s_server -dtls1 listening on that port (v4 only).
gnutls-serv -u (debian's version 3.0.22-3+really2.12.20-6) failed
complaining that -u (or --udp) were unknown.

-JimC
-- 
James Cloos <cloos at jhcloos.com>         OpenPGP: 1024D/ED7DAEA6


From nmav at gnutls.org  Mon Apr  8 17:44:58 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 08 Apr 2013 17:44:58 +0200
Subject: [gnutls-devel] ipv6 vs ipv4 vs udp
In-Reply-To: <m3ppy8amov.fsf@carbon.jhcloos.org>
References: <m3ppy8amov.fsf@carbon.jhcloos.org>
Message-ID: <5162E5FA.5020301@gnutls.org>

On 04/05/2013 07:53 PM, James Cloos wrote:

> The fallback from v6 to v4 works well for tcp, but not for udp.
> I get something like:
> :; gnutls-cli -u -p 5555 liberty.jhcloos.com
> Processed 159 CA certificate(s).
> Resolving 'liberty.jhcloos.com'...
> Connecting to '2001:4830:1662::53:5555'...
> *** Fatal error: The operation timed out
> *** Handshake has failed
> GnuTLS error: The operation timed out


UDP is different than TCP because there is no connection. So there is no
fallback since connection doesn't fail, it just timeout. I suppose that
even if we tried to resume using ipv4 after the timeout you notice it
would have taken too much time to be a practical solution.

Any suggestions?

regards,
Nikos


From cloos at jhcloos.com  Mon Apr  8 19:26:17 2013
From: cloos at jhcloos.com (James Cloos)
Date: Mon, 08 Apr 2013 13:26:17 -0400
Subject: [gnutls-devel] ipv6 vs ipv4 vs udp
In-Reply-To: <5162E5FA.5020301@gnutls.org> (Nikos Mavrogiannopoulos's message
 of "Mon, 08 Apr 2013 17:44:58 +0200")
References: <m3ppy8amov.fsf@carbon.jhcloos.org> <5162E5FA.5020301@gnutls.org>
Message-ID: <m3obdp53xp.fsf@carbon.jhcloos.org>

>>>>> "NM" == Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

NM> UDP is different than TCP because there is no connection.

Of course.

NM> So there is no fallback since connection doesn't fail, it just
NM> timeout. I suppose that even if we tried to resume using ipv4 after
NM> the timeout you notice it would have taken too much time to be a
NM> practical solution.

Trying the next after the timeout was my expectation.

If that takes too long, the original suggestion would work:  -4 and -6
or --ipv4 and --ipv6 command line options to limit to AF_INET or AF_INET6.

Or both in parallel, dropping whichever one doesn't answer first.

I can see how automatic coverage may be preferred when using cli over a
pipe or tty as a substitute for linking, but when using cli at a shell
for testing remote servers/services, explicit command line options are
ideal.

[Having a tough time typing today; hope I didn't miss any typos/thinkos.]

[And appologies for the double post; I stopped my outgoing mta during
the postgres update and forgot to restart it.....]

-JimC
-- 
James Cloos <cloos at jhcloos.com>         OpenPGP: 1024D/ED7DAEA6


From dkg at fifthhorseman.net  Fri Apr 12 17:33:37 2013
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 12 Apr 2013 11:33:37 -0400
Subject: [gnutls-devel] OpenPGP key parsing safety
Message-ID: <87mwt3dar2.fsf@alice.fifthhorseman.net>

hi folks--



From daniele.athome at gmail.com  Sat Apr 20 16:08:20 2013
From: daniele.athome at gmail.com (Daniele Ricci)
Date: Sat, 20 Apr 2013 16:08:20 +0200
Subject: [gnutls-devel] [Python] Fork of python-gnutls
Message-ID: <CA+yWqeV=wtqTYFH7AOj8cmh8xVAc9dR2jzb3vkN9+jb806=AfA@mail.gmail.com>

Hello list!
I've just subscribed, I'd like to inform about the new fork I've
created on Gitorious [1].
Since the python-gnutls [2] seems to be dead (and stuck to GnuTLS
2.x), and original mainteiner did not replied my request, I'm taking
over development.

My first objective is to include OpenPGP authentication (I need it for
my project), but I guess I will also upgrade it to a more recent
version of GnuTLS eventually (3.x).

Bye

[1] https://gitorious.org/pygnutls
[2] https://pypi.python.org/pypi/python-gnutls/

-- 
Daniele


From nmav at gnutls.org  Sun Apr 21 12:23:51 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 21 Apr 2013 13:23:51 +0300
Subject: [gnutls-devel] [Python] Fork of python-gnutls
In-Reply-To: <CA+yWqeV=wtqTYFH7AOj8cmh8xVAc9dR2jzb3vkN9+jb806=AfA@mail.gmail.com>
References: <CA+yWqeV=wtqTYFH7AOj8cmh8xVAc9dR2jzb3vkN9+jb806=AfA@mail.gmail.com>
Message-ID: <CAJU7za+ZL2GXy7QMR21kH7w+97FaxgMF28sXZ0ppcBNaKi9tLw@mail.gmail.com>

On Sat, Apr 20, 2013 at 5:08 PM, Daniele Ricci <daniele.athome at gmail.com> wrote:
> Hello list!
> I've just subscribed, I'd like to inform about the new fork I've
> created on Gitorious [1].
> Since the python-gnutls [2] seems to be dead (and stuck to GnuTLS
> 2.x), and original mainteiner did not replied my request, I'm taking
> over development.
> My first objective is to include OpenPGP authentication (I need it for
> my project), but I guess I will also upgrade it to a more recent
> version of GnuTLS eventually (3.x).

Thank you for letting us know. I'll update the gnutls pages to link to
your fork as well as soon as I am back from holidays.

regards,
Nikos


From stefw at gnome.org  Sat Apr 27 15:44:49 2013
From: stefw at gnome.org (Stef Walter)
Date: Sat, 27 Apr 2013 15:44:49 +0200
Subject: [gnutls-devel] Various fixes for hex DN attributes
Message-ID: <517BD651.9060006@gnome.org>

The encoding of unrecognized (or non-string) DN attributes via functions
like gnutls_x509_crt_get_dn() doesn't work properly. The function
returns GNUTLS_E_ASN1_DER_ERROR. Attached are a number of patches and
some test code to demonstrate the problem and fix related things.

Cheers,

Stef
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Don-t-try-to-include-null-terminator-in-DN-string.patch
Type: text/x-patch
Size: 793 bytes
Desc: not available
URL: </pipermail/attachments/20130427/75373da6/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Don-t-reencode-strings-already-in-RFC-5246-form.patch
Type: text/x-patch
Size: 4716 bytes
Desc: not available
URL: </pipermail/attachments/20130427/75373da6/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-Add-the-standard-description-OID-to-those-recognized.patch
Type: text/x-patch
Size: 919 bytes
Desc: not available
URL: </pipermail/attachments/20130427/75373da6/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gnutls-dn-unprintable.c
Type: text/x-csrc
Size: 3620 bytes
Desc: not available
URL: </pipermail/attachments/20130427/75373da6/attachment.c>

From nmav at gnutls.org  Sat Apr 27 20:54:00 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 27 Apr 2013 21:54:00 +0300
Subject: [gnutls-devel] Various fixes for hex DN attributes
In-Reply-To: <517BD651.9060006@gnome.org>
References: <517BD651.9060006@gnome.org>
Message-ID: <CAJU7zaJSHA2m7hT4bpFYAwqytGgvrai0U765LSqQrRacifUKcA@mail.gmail.com>

On Sat, Apr 27, 2013 at 4:44 PM, Stef Walter <stefw at gnome.org> wrote:
> The encoding of unrecognized (or non-string) DN attributes via functions
> like gnutls_x509_crt_get_dn() doesn't work properly. The function
> returns GNUTLS_E_ASN1_DER_ERROR. Attached are a number of patches and
> some test code to demonstrate the problem and fix related things.

Thank you for that patches and the report. I've committed a slightly
different fix for the first two as it uncovered some issues in the
code.

Did you notice any such issues in the 3.0.x series?

regards,
Nikos


From ryandesign at macports.org  Tue Apr  2 04:50:42 2013
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 02 Apr 2013 02:50:42 -0000
Subject: [gnutls-devel] gnutls 3.1.10 compile fails on OS X 10.5 Leopard
	because of invalid start-of-comment characters in
	macosx/appro-aes-x86-macosx.s
Message-ID: <61182AAD-BFAC-4CF4-8A69-57FF3FD9DB3F@macports.org>

Building gnutls 3.1.10 fails on OS X 10.5.8 Leopard i386 with Xcode 3.1.4:


macosx/appro-aes-x86-macosx.s:1:3: error: invalid preprocessing directive #Copyright
macosx/appro-aes-x86-macosx.s:2:3: error: invalid preprocessing directive #All
macosx/appro-aes-x86-macosx.s:4:3: error: invalid preprocessing directive #Redistribution
macosx/appro-aes-x86-macosx.s:5:3: error: invalid preprocessing directive #modification
macosx/appro-aes-x86-macosx.s:6:3: error: invalid preprocessing directive #are
macosx/appro-aes-x86-macosx.s:8:7: error: invalid preprocessing directive #*
macosx/appro-aes-x86-macosx.s:9:8: error: invalid preprocessing directive #this
macosx/appro-aes-x86-macosx.s:11:7: error: invalid preprocessing directive #*
macosx/appro-aes-x86-macosx.s:12:8: error: invalid preprocessing directive #copyright
macosx/appro-aes-x86-macosx.s:13:8: error: invalid preprocessing directive #disclaimer
macosx/appro-aes-x86-macosx.s:14:8: error: invalid preprocessing directive #provided
macosx/appro-aes-x86-macosx.s:16:7: error: invalid preprocessing directive #*
macosx/appro-aes-x86-macosx.s:17:8: error: invalid preprocessing directive #copyright
macosx/appro-aes-x86-macosx.s:18:8: error: invalid preprocessing directive #promote
macosx/appro-aes-x86-macosx.s:19:8: error: invalid preprocessing directive #prior
macosx/appro-aes-x86-macosx.s:21:3: error: invalid preprocessing directive #ALTERNATIVELY
macosx/appro-aes-x86-macosx.s:22:3: error: invalid preprocessing directive #product
macosx/appro-aes-x86-macosx.s:23:3: error: invalid preprocessing directive #License
macosx/appro-aes-x86-macosx.s:24:3: error: invalid preprocessing directive #those
macosx/appro-aes-x86-macosx.s:26:3: error: invalid preprocessing directive #THIS
macosx/appro-aes-x86-macosx.s:27:3: error: invalid preprocessing directive #"AS IS"
macosx/appro-aes-x86-macosx.s:28:3: error: invalid preprocessing directive #LIMITED
macosx/appro-aes-x86-macosx.s:29:3: error: invalid preprocessing directive #A
macosx/appro-aes-x86-macosx.s:30:3: error: invalid preprocessing directive #OWNER
macosx/appro-aes-x86-macosx.s:31:3: error: invalid preprocessing directive #SPECIAL
macosx/appro-aes-x86-macosx.s:32:3: error: invalid preprocessing directive #LIMITED
macosx/appro-aes-x86-macosx.s:33:3: error: invalid preprocessing directive #DATA
macosx/appro-aes-x86-macosx.s:34:3: error: invalid preprocessing directive #THEORY
macosx/appro-aes-x86-macosx.s:35:3: error: invalid preprocessing directive #(
macosx/appro-aes-x86-macosx.s:36:3: error: invalid preprocessing directive #OF
macosx/appro-aes-x86-macosx.s:38:3: error: invalid preprocessing directive #*


"#" appears not to be a valid start-of-comment character for this assembler (which is "Apple Inc version cctools-698.1~1, GNU assembler version 1.38"). Removing the lines that start with "#" fixes the problem. I don't know what the correct start-of-comment character should be; the documentation I found says it should be "#" on i386 and ";" on ppc.





From harry.mason at smoothwall.net  Mon Apr 29 16:59:50 2013
From: harry.mason at smoothwall.net (Harry Mason)
Date: Mon, 29 Apr 2013 15:59:50 +0100
Subject: [gnutls-devel] certtool bug: key_purpose_oids ignored when
	generating CSR
Message-ID: <1367247590.4556.9.camel@azathoth.dev.smoothwall.net>

I'm using certtool to generate a certificate for EAP authentication. I
was trying to use the key_purpose_oids option to add the necessary OID
to the CSR, but the code in generate_request never checks the value of
this option.

If generating a certificate directly without an intermediate CSR it
works, because generate_certificate calls get_key_purpose_set; but there
is no corresponding function to add the OIDs to a gnutls_x509_crq_t.

-- 
Harry Mason
Senior Developer

harry.mason at smoothwall.net

Smoothwall Ltd
1 John Charles Way, Leeds, LS12 6QA United Kingdom
Telephone:  USA: 1 800 959 3760  Europe: +44 (0) 8701 999500
www.smoothwall.net

Smoothwall Limited is registered in England, Company Number: 4298247.  This
email and any attachments transmitted with it are confidential to the
intended recipient(s) and may not be communicated to any other person or
published by any means without the permission of Smoothwall Limited.  Any
opinions stated in this message are solely those of the author.