From nmav at gnutls.org  Sun Apr  1 20:26:29 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 01 Apr 2012 20:26:29 +0200
Subject: NXWEB 3.0 is out (adds SSL, http proxy,
	and even better performance)
In-Reply-To: <CACNYQ9FaDsLYt2aheHwcnMz+oPFHRyXmDgTfQJKdO1QtFe0bKg@mail.gmail.com>
References: <CACNYQ9FCYf7Zjj5MQczJjapSJges+ut_aamYenen=9m=bNAG5A@mail.gmail.com>	<4F22FCC9.2020009@gnutls.org>
	<CACNYQ9FaDsLYt2aheHwcnMz+oPFHRyXmDgTfQJKdO1QtFe0bKg@mail.gmail.com>
Message-ID: <4F789DD5.3050706@gnutls.org>

On 01/27/2012 08:52 PM, Yaroslav wrote:

> I'd be happy if somene could do independent benchmarks of nxweb on
> different hardware. So that we know for sure that it is all true :)


Hello Yaroslav,
 I've done benchmarks on a small system and pretty much verify your
results. I've put at:

http://nikmav.blogspot.com/2012/04/in-some-embedded-systems-space-may.html

regards,
Nikos

PS. I've modified httpress to print "rps" as floating point, because the
numbers were really small for this system.



From yarosla at gmail.com  Sun Apr  1 21:11:46 2012
From: yarosla at gmail.com (Yaroslav)
Date: Sun, 1 Apr 2012 23:11:46 +0400
Subject: NXWEB 3.0 is out (adds SSL, http proxy,
	and even better performance)
In-Reply-To: <4F789DD5.3050706@gnutls.org>
References: <CACNYQ9FCYf7Zjj5MQczJjapSJges+ut_aamYenen=9m=bNAG5A@mail.gmail.com>
	<4F22FCC9.2020009@gnutls.org>
	<CACNYQ9FaDsLYt2aheHwcnMz+oPFHRyXmDgTfQJKdO1QtFe0bKg@mail.gmail.com>
	<4F789DD5.3050706@gnutls.org>
Message-ID: <CACNYQ9EU2O9QD6vPXqax1cYwapwGt_D4LmTtChVdFov99Y+4BA@mail.gmail.com>

Hi Nikos,

That's good. Thank you very much for the reference.

http://vincent.bernat.im/en/blog/2011-ssl-benchmark-round2.html
Have you seen those benchmarks? There was no GnuTLS tested but now I think
it could be. Do you happen to know the author?

Yaroslav

On Sun, Apr 1, 2012 at 10:26 PM, Nikos Mavrogiannopoulos <nmav at gnutls.org>wrote:

> On 01/27/2012 08:52 PM, Yaroslav wrote:
>
> > I'd be happy if somene could do independent benchmarks of nxweb on
> > different hardware. So that we know for sure that it is all true :)
>
>
> Hello Yaroslav,
>  I've done benchmarks on a small system and pretty much verify your
> results. I've put at:
>
> http://nikmav.blogspot.com/2012/04/in-some-embedded-systems-space-may.html
>
> regards,
> Nikos
>
> PS. I've modified httpress to print "rps" as floating point, because the
> numbers were really small for this system.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20120401/b75998e4/attachment.htm>

From nmav at gnutls.org  Sun Apr  1 22:09:12 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 01 Apr 2012 22:09:12 +0200
Subject: NXWEB 3.0 is out (adds SSL, http proxy,
	and even better performance)
In-Reply-To: <CACNYQ9EU2O9QD6vPXqax1cYwapwGt_D4LmTtChVdFov99Y+4BA@mail.gmail.com>
References: <CACNYQ9FCYf7Zjj5MQczJjapSJges+ut_aamYenen=9m=bNAG5A@mail.gmail.com>	<4F22FCC9.2020009@gnutls.org>	<CACNYQ9FaDsLYt2aheHwcnMz+oPFHRyXmDgTfQJKdO1QtFe0bKg@mail.gmail.com>	<4F789DD5.3050706@gnutls.org>
	<CACNYQ9EU2O9QD6vPXqax1cYwapwGt_D4LmTtChVdFov99Y+4BA@mail.gmail.com>
Message-ID: <4F78B5E8.4020200@gnutls.org>

On 04/01/2012 09:11 PM, Yaroslav wrote:

> Hi Nikos,
> 
> That's good. Thank you very much for the reference.
> http://vincent.bernat.im/en/blog/2011-ssl-benchmark-round2.html
> Have you seen those benchmarks? There was no GnuTLS tested but now I think
> it could be. Do you happen to know the author?


Interesting benchmark, but I don't know the author.

regards,
Nikos



From librarian_rus at yahoo.com  Mon Apr  2 07:06:11 2012
From: librarian_rus at yahoo.com (Ilya Tumaykin)
Date: Mon, 02 Apr 2012 09:06:11 +0400
Subject: [GSoC 2012] Faster elliptic curve scalar multiplication project.
In-Reply-To: <4F774F0F.8020407@gnutls.org>
References: <1492936.rRhKB13goU@photon> <5629117.yVxUNfCt26@photon>
	<4F774F0F.8020407@gnutls.org>
Message-ID: <1755791.TgtFoHRjgz@photon>

Hello, Nikos.

I am very very sorry for such a big delay. I received your last message today 
in the morning where you referring to your previous post and was very 
surprised, because I don't have it in my mail box. I can see it through web 
interface to ML, but it is missing from my mailbox. I am very very sorry.
I started thinking that no one will ever answer me, but it was probably 
filtered as spam.

I gave a brief look to ecc_mulmod.c and it looks ok to me. I'll start reading 
one or two books. They will be most probably Koblitz and/or maybe another one
suggested by my university mentor. And, of course, papers that describing the 
algorithm. I'll apply through Google site today's evening.

I've attached some files from project I'm currently involved in. I hope it will 
be publicly available as soon as it is 100% working. Right now about two 
thirds of it is done, but the last third is pretty hard and the other guy will 
do it.

On Saturday 31 March 2012 20:38:07 you wrote:
> On 03/27/2012 12:07 PM, Ilya Tumaykin wrote:
> > Should I provide any additional info or do some extra actions to make my
> > proposal approved?
> 
> Hello Ilya, I hope my previous mail didn't intimidate or demotivate you.
> My feeling is that it is not that hard of a project, but if you'd
> like to discuss anything on it write me in google talk (xmpp) at
> n.mavrogiannopoulos at gmail.com.
> 
> regards,
> Nikos
-- 
Best regards.
Ilya Tumaykin.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: example.tar.gz
Type: application/x-compressed-tar
Size: 3962 bytes
Desc: not available
URL: </pipermail/attachments/20120402/e9af3a12/attachment.bin>

From tzz at lifelogs.com  Mon Apr  2 14:39:58 2012
From: tzz at lifelogs.com (Ted Zlatanov)
Date: Mon, 02 Apr 2012 08:39:58 -0400
Subject: gnutls-cli fails to handshake with Exchange server that uses
	DES-CBC3-SHA cipher
References: <m362dtoe6j.fsf@fitzsim.org> <4F6EDDC5.60804@gnutls.org>
	<m3sjgvm2nr.fsf@fitzsim.org>
	<CAJU7zaKVXGgqKBThXuNAxr2M-4jAHi5a5Ht_yS_kLh_X7uB98g@mail.gmail.com>
	<m3obrflyyg.fsf@fitzsim.org> <87limiwb3g.fsf@lifelogs.com>
	<4F773FA0.6040703@gnutls.org>
Message-ID: <87mx6upash.fsf@lifelogs.com>

On Sat, 31 Mar 2012 19:32:16 +0200 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote: 

NM> On 03/30/2012 02:02 PM, Ted Zlatanov wrote:
>> On Thu, 29 Mar 2012 20:22:31 -0400 Thomas Fitzsimmons <fitzsim at fitzsim.org> wrote: 
>> 
TF> Emacs allows overriding the default GnuTLS priority string using a
TF> variable (gnutls-algorithm-priority) so I set it to "performance" to
TF> work around this server-side issue.  In cases where Emacs would
TF> otherwise fail to connect to a server because of a weak ciphersuite
TF> maybe the UI should warn the user and ask them whether or not to
TF> proceed.  Anyway, thanks for analyzing the logs.
>> I don't think currently Emacs can distinguish this case from a normal
>> negotiation failure.  The best we can do is to generally suggest a
>> weaker priority string, which seems to be a bad idea.  Is there a way to
>> determine that this case has occurred?

NM> You cannot in general distinguish a negotiation with a broken server and
NM> negotiation failure. What (I think) browsers do is if negotiation fails
NM> they fallback to the most compatible mode (SSL 3.0 or so).

So you're suggesting to try a weaker (more compatible) priority string,
right?  We could do that per server name.  Considering we have just one
bug report on this and from a broken server, I'm not sure it's worth the
effort to automate the fallback.  In your experience, is this a
widespread problem worth addressing through code, or is it better as a
FAQ?

Thanks
Ted




From nmav at gnutls.org  Mon Apr  2 17:46:30 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 2 Apr 2012 17:46:30 +0200
Subject: gnutls-cli fails to handshake with Exchange server that uses
	DES-CBC3-SHA cipher
In-Reply-To: <87mx6upash.fsf@lifelogs.com>
References: <m362dtoe6j.fsf@fitzsim.org> <4F6EDDC5.60804@gnutls.org>
	<m3sjgvm2nr.fsf@fitzsim.org>
	<CAJU7zaKVXGgqKBThXuNAxr2M-4jAHi5a5Ht_yS_kLh_X7uB98g@mail.gmail.com>
	<m3obrflyyg.fsf@fitzsim.org> <87limiwb3g.fsf@lifelogs.com>
	<4F773FA0.6040703@gnutls.org> <87mx6upash.fsf@lifelogs.com>
Message-ID: <CAJU7zaJLwOxFNBXrdTQNmd0cJA1QPW0sZsscHvzcwOwO2gp5SQ@mail.gmail.com>

2012/4/2 Ted Zlatanov <tzz at lifelogs.com>:

> NM> You cannot in general distinguish a negotiation with a broken server and
> NM> negotiation failure. What (I think) browsers do is if negotiation fails
> NM> they fallback to the most compatible mode (SSL 3.0 or so).
> So you're suggesting to try a weaker (more compatible) priority string,
> right? ?We could do that per server name. ?Considering we have just one
> bug report on this and from a broken server, I'm not sure it's worth the
> effort to automate the fallback. ?In your experience, is this a
> widespread problem worth addressing through code, or is it better as a
> FAQ?

Experience has shown that there are quite many broken servers [0]
out there, so we'd encourage applications to have a fallback strategy.
Whether that would include manual intervention of the user or not is not
as important.

regards,
Nikos

[0]. http://tools.ietf.org/id/draft-pettersen-tls-interop-experience-00.txt



From nmav at gnutls.org  Mon Apr  2 20:40:45 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 02 Apr 2012 20:40:45 +0200
Subject: gnutls 3.0.18
Message-ID: <4F79F2AD.4020202@gnutls.org>

Hello,
 I've just released gnutls 3.0.18. This is a bug-fix release on the
current stable branch. Note that this release is available both
under xz and lzip compression formats. We might switch to using only
one of these compression formats in the future.

* Version 3.0.18 (released 2012-04-02)

** certtool: Avoid a Y2K38 bug when generating certificates.
Patch by Robert Millan.

** libgnutls: Make sure that GNUTLS_E_PREMATURE_TERMINATION
is returned on premature termination (and added unit test).

** libgnutls: Fixes for W64 API. Patch by B. Scott Michel.

** libgnutls: Corrected VIA padlock detection for old
VIA processors. Reported by Kris Karas.

** libgnutls: Updated assembler files.

** libgnutls: Time in generated certificates is stored
as GeneralizedTime instead of UTCTime (which only stores
2 digits of a year).

** minitasn1: Upgraded to libtasn1 version 2.13 (pre-release).

** API and ABI modifications:
gnutls_x509_crt_set_private_key_usage_period: Added
gnutls_x509_crt_get_private_key_usage_period: Added
gnutls_x509_crq_set_private_key_usage_period: Added
gnutls_x509_crq_get_private_key_usage_period: Added
gnutls_session_get_random: Added


Getting the Software
====================

GnuTLS may be downloaded from one of the GNU mirror sites or directly
>From <ftp://ftp.gnu.org/gnu/gnutls/>.  The list of GNU mirrors can be
found at <http://www.gnu.org/prep/ftp.html> and a list of GnuTLS mirrors
can be found at <http://www.gnu.org/software/gnutls/download.html>.

Here are the XZ compressed sources:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.18.tar.xz
  http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.18.tar.xz
  ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.18.tar.xz

Here are the LZIP compressed sources:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.18.tar.lz
  http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.18.tar.lz
  ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.18.tar.lz

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.18.tar.xz.sig
  http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.18.tar.xz.sig
  ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.18.tar.xz.sig

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.18.tar.lz.sig
  http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.18.tar.lz.sig
  ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.18.tar.lz.sig

Note that it has been signed with my openpgp key:
pub   3104R/96865171 2008-05-04 [expires: 2028-04-29]
uid                  Nikos Mavrogiannopoulos <nmav <at> gnutls.org>
uid                  Nikos Mavrogiannopoulos <n.mavrogiannopoulos <at>
gmail.com>
sub   2048R/9013B842 2008-05-04 [expires: 2018-05-02]
sub   2048R/1404A91D 2008-05-04 [expires: 2018-05-02]

regards,
Nikos



From INVALID.NOREPLY at gnu.org  Mon Apr  2 20:53:58 2012
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Mon, 02 Apr 2012 18:53:58 +0000
Subject: [sr #108004] Since GnuTLS 3.0.17 upgrade,
	evolution 3.2.x and newer cannot synchronise with google calendar
	account
In-Reply-To: <20120329-101545.sv0.80853@savannah.gnu.org>
References: <20120327-191056.sv85256.91775@savannah.gnu.org>
	<20120328-074702.sv0.71531@savannah.gnu.org>
	<20120328-081323.sv85256.47512@savannah.gnu.org>
	<20120328-082128.sv0.54490@savannah.gnu.org>
	<20120328-090754.sv85256.78849@savannah.gnu.org>
	<20120328-151125.sv73763.63696@savannah.gnu.org>
	<20120328-152642.sv85256.5203@savannah.gnu.org>
	<20120328-193827.sv85256.57035@savannah.gnu.org>
	<20120328-194632.sv85256.9286@savannah.gnu.org>
	<20120329-090548.sv0.97596@savannah.gnu.org>
	<20120329-091157.sv85256.65360@savannah.gnu.org>
	<20120329-101545.sv0.80853@savannah.gnu.org>
Message-ID: <20120402-215357.sv707.62962@savannah.gnu.org>

Update of sr #108004 (project gnutls):

                  Status:                    None => Done                   
             Assigned to:                    None => nmav                   

    _______________________________________________________

Follow-up Comment #9:

GnuTLS 3.0.18 should solve this issue.

    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Mon Apr  2 20:54:15 2012
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Mon, 02 Apr 2012 18:54:15 +0000
Subject: [sr #107996] MinGW-W64 enhancements
In-Reply-To: <20120321-220649.sv0.42148@savannah.gnu.org>
References: <20120321-220649.sv0.42148@savannah.gnu.org>
Message-ID: <20120402-215415.sv707.26150@savannah.gnu.org>

Update of sr #107996 (project gnutls):

                  Status:                    None => Done                   
             Assigned to:                    None => nmav                   
             Open/Closed:                    Open => Closed                 


    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Mon Apr  2 20:54:44 2012
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Mon, 02 Apr 2012 18:54:44 +0000
Subject: [sr #107985] dtls-stress doesn't compile on darwin
In-Reply-To: <20120328-082607.sv0.13683@savannah.gnu.org>
References: <20120316-003117.sv75110.94570@savannah.gnu.org>
	<20120328-082607.sv0.13683@savannah.gnu.org>
Message-ID: <20120402-215444.sv707.67060@savannah.gnu.org>

Update of sr #107985 (project gnutls):

                  Status:                    None => Done                   
             Assigned to:                    None => nmav                   
             Open/Closed:                    Open => Closed                 

    _______________________________________________________

Follow-up Comment #2:

This should be solved in GnuTLS 3.0.18.


    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Mon Apr  2 20:55:54 2012
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Mon, 02 Apr 2012 18:55:54 +0000
Subject: [sr #107977] Test failed with building gnutls 3.0.15
In-Reply-To: <20120303-043621.sv68311.31172@savannah.gnu.org>
References: <20120303-043621.sv68311.31172@savannah.gnu.org>
Message-ID: <20120402-215554.sv707.69706@savannah.gnu.org>

Update of sr #107977 (project gnutls):

                  Status:                    None => Wont Do                
             Assigned to:                    None => nmav                   
             Open/Closed:                    Open => Closed                 

    _______________________________________________________

Follow-up Comment #1:

This is because some process is using the 5555 or 5556 ports used by the test
programs.


    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Mon Apr  2 20:56:20 2012
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Mon, 02 Apr 2012 18:56:20 +0000
Subject: [sr #107967] Add missing file to distribution tarball
In-Reply-To: <20120225-104022.sv707.36858@savannah.gnu.org>
References: <20120224-190137.sv87248.96117@savannah.gnu.org>
	<20120225-104022.sv707.36858@savannah.gnu.org>
Message-ID: <20120402-215620.sv707.49427@savannah.gnu.org>

Update of sr #107967 (project gnutls):

                  Status:                    None => Done                   
             Assigned to:                    None => nmav                   
             Open/Closed:                    Open => Closed                 

    _______________________________________________________

Follow-up Comment #2:

This should be fixed in the latest releases.


    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Mon Apr  2 20:56:44 2012
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Mon, 02 Apr 2012 18:56:44 +0000
Subject: [sr #107983] lib/accelerated/x86/asm files incompatible with
	i386/x86_64 darwin
In-Reply-To: <20120315-194901.sv707.64470@savannah.gnu.org>
References: <20120315-034047.sv75110.75468@savannah.gnu.org>
	<20120315-194901.sv707.64470@savannah.gnu.org>
Message-ID: <20120402-215644.sv707.27980@savannah.gnu.org>

Update of sr #107983 (project gnutls):

                  Status:                    None => Done                   
             Assigned to:                    None => nmav                   
             Open/Closed:                    Open => Closed                 

    _______________________________________________________

Follow-up Comment #2:

This should be fixed in the latest releases.

    _______________________________________________________

Reply to this item at:

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

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




From yoi_no_myoujou at yahoo.co.jp  Tue Apr  3 16:00:38 2012
From: yoi_no_myoujou at yahoo.co.jp (Kiyoshi KANAZAWA)
Date: Tue, 3 Apr 2012 23:00:38 +0900 (JST)
Subject: gnutls-3.0.18 make check fails on Solaris10
Message-ID: <465902.24003.qm@web100708.mail.kks.yahoo.co.jp>

Hello,

Gnutls-3.0.18 make check fails on Solaris10 x86-64.

There are 2 types of errors.
(1) 'AF_LOCAL' undeclared
  CC     mini-loss-time.o
mini-loss-time.c: In function `start':
mini-loss-time.c:256: error: `AF_LOCAL' undeclared (first use in this function)
mini-loss-time.c:256: error: (Each undeclared identifier is reported only once
mini-loss-time.c:256: error: for each function it appears in.)
make[3]: *** [mini-loss-time.o] Error 1

This occurs also on
mini-dtls-rehandshake.o
mini-record.o
dtls-stress.o
mini-srp.o

(2) Segmentation Fault
make[3]: Entering directory `/tmp/gnutls-3.0.18/tests/pkcs12-decode'
NEON PKCS12 OK client.p12 foobar
NEON PKCS12 OK noclient.p12
NEON PKCS12 OK unclient.p12
Segmentation Fault
        Type: Encrypted

        Decrypting...
        Type: Certificate
        Type: Certificate
NEON PKCS12 FATAL pkcs12_2certs.p12
NEON PKCS12 DONE (rc 1)
FAIL: pkcs12

gnutls-3.0.17 also has the same problem.

--- Kiyoshi <yoi_no_myoujou at yahoo.co.jp>




From nmav at gnutls.org  Tue Apr  3 16:37:26 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 3 Apr 2012 16:37:26 +0200
Subject: gnutls-3.0.18 make check fails on Solaris10
In-Reply-To: <465902.24003.qm@web100708.mail.kks.yahoo.co.jp>
References: <465902.24003.qm@web100708.mail.kks.yahoo.co.jp>
Message-ID: <CAJU7zaJ4xJDSrkKhGvYddkR3AE-43DH6meu8XP9XT06_3QPOJw@mail.gmail.com>

On Tue, Apr 3, 2012 at 4:00 PM, Kiyoshi KANAZAWA
<yoi_no_myoujou at yahoo.co.jp> wrote:

Hello,
 Thank you for the report. Some questions inline.

> Gnutls-3.0.18 make check fails on Solaris10 x86-64.
> There are 2 types of errors.
> (1) 'AF_LOCAL' undeclared
> ?CC ? ? mini-loss-time.o
> mini-loss-time.c: In function `start':
> mini-loss-time.c:256: error: `AF_LOCAL' undeclared (first use in this function)

If you define AF_LOCAL to AF_UNIX do they compile?

> (2) Segmentation Fault
> make[3]: Entering directory `/tmp/gnutls-3.0.18/tests/pkcs12-decode'
> NEON PKCS12 OK client.p12 foobar
> NEON PKCS12 OK noclient.p12
> NEON PKCS12 OK unclient.p12
> Segmentation Fault

Could you apply the patch and run the pkcs12 test? (you'll need valgrind)

regards,
Nikos
-------------- next part --------------
diff --git a/tests/pkcs12-decode/pkcs12 b/tests/pkcs12-decode/pkcs12
index e35004f..c01e950 100755
--- a/tests/pkcs12-decode/pkcs12
+++ b/tests/pkcs12-decode/pkcs12
@@ -29,8 +29,8 @@ for p12 in 'client.p12 foobar' noclient.p12 unclient.p12 pkcs12_2certs.p12; do
     set -- $p12
     file=$1
     passwd=$2
-    $CERTTOOL --p12-info --inder --password "$passwd" \
-		--infile $srcdir/$file > out 2>&1
+    valgrind $CERTTOOL --p12-info --inder --password "$passwd" \
+		--infile $srcdir/$file > out
     rc=$?
     if test $rc != 0; then
 	cat out

From a.radke at arcor.de  Tue Apr  3 19:45:21 2012
From: a.radke at arcor.de (Andreas Radke)
Date: Tue, 3 Apr 2012 19:45:21 +0200
Subject: gnutls 3.0.18
In-Reply-To: <4F79F2AD.4020202@gnutls.org>
References: <4F79F2AD.4020202@gnutls.org>
Message-ID: <20120403194521.1e2e32d8@laptop64.home>

make check hang here for all time even when running non-parallel:

=============
1 test passed
=============
make[3]: Leaving directory `/build/src/gnutls-3.0.18/tests/srp'
make[2]: Leaving directory `/build/src/gnutls-3.0.18/tests/srp'
Making check in openpgp-certs
make[2]: Entering directory `/build/src/gnutls-3.0.18/tests/openpgp-certs'
make  testselfsigs testcerts
make[3]: Entering directory `/build/src/gnutls-3.0.18/tests/openpgp-certs'
make[3]: Nothing to be done for `testselfsigs'.
make[3]: Nothing to be done for `testcerts'.
make[3]: Leaving directory `/build/src/gnutls-3.0.18/tests/openpgp-certs'
make  check-TESTS
make[3]: Entering directory `/build/src/gnutls-3.0.18/tests/openpgp-certs'
Checking OpenPGP certificate self verification
PASS: testselfsigs
Checking OpenPGP certificate verification
PASS: testcerts
==================
All 2 tests passed
==================
make[3]: Leaving directory `/build/src/gnutls-3.0.18/tests/openpgp-certs'
make[2]: Leaving directory `/build/src/gnutls-3.0.18/tests/openpgp-certs'
make[1]: Leaving directory `/build/src/gnutls-3.0.18/tests'
make[1]: Entering directory `/build/src/gnutls-3.0.18'
make[1]: Nothing to be done for `check-am'.
make[1]: Leaving directory `/build/src/gnutls-3.0.18'
  GEN    public-submodule-commit
^C


any idea? we had something similar in 3.0.10 release.

-Andy
ArchLinux - using gcc 4.7.0 now



From yoi_no_myoujou at yahoo.co.jp  Tue Apr  3 21:04:04 2012
From: yoi_no_myoujou at yahoo.co.jp (Kiyoshi KANAZAWA)
Date: Wed, 4 Apr 2012 04:04:04 +0900 (JST)
Subject: gnutls-3.0.18 make check fails on Solaris10
Message-ID: <634747.15702.qm@web100710.mail.kks.yahoo.co.jp>

Hi, Nikos,

Answer to your quiestions.

(1) 'AF_LOCAL' undeclared
Yes, they compile with -DAF_LOCAL=AF_UNIX
But encountered new FAILs such as
gnutls_check_version ERROR
Self test `./simple' finished with 1 errors
FAIL: simple
? ? :
client: Unexpected error: -9 (A TLS packet with unexpected length was received.)
Child died with status 1
FAIL: mini-termination

(2) Segmentation Fault
Error messages are changed by the patch (No Segmentation Fault now).
# It seems to be correct because valgrind-3.7.0 could not be installed saying that
# "configure: error: Valgrind is operating system specific. Sorry."
./pkcs12: valgrind: not found
cat: cannot open out
NEON PKCS12 FATAL client.p12 foobar
./pkcs12: valgrind: not found
cat: cannot open out
NEON PKCS12 FATAL noclient.p12
./pkcs12: valgrind: not found
cat: cannot open out
NEON PKCS12 FATAL unclient.p12
./pkcs12: valgrind: not found
cat: cannot open out
NEON PKCS12 FATAL pkcs12_2certs.p12
NEON PKCS12 DONE (rc 1)
FAIL: pkcs12

Regards,

--- Kiyoshi <yoi_no_myoujou at yahoo.co.jp>

--- On Tue, 2012/4/3, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:

> On Tue, Apr 3, 2012 at 4:00 PM, Kiyoshi KANAZAWA
> <yoi_no_myoujou at yahoo.co.jp> wrote:
> 
> Hello,
>? Thank you for the report. Some questions inline.
> 
> > Gnutls-3.0.18 make check fails on Solaris10 x86-64.
> > There are 2 types of errors.
> > (1) 'AF_LOCAL' undeclared
> > ?CC ? ? mini-loss-time.o
> > mini-loss-time.c: In function `start':
> > mini-loss-time.c:256: error: `AF_LOCAL' undeclared (first use in this function)
> 
> If you define AF_LOCAL to AF_UNIX do they compile?
> 
> > (2) Segmentation Fault
> > make[3]: Entering directory `/tmp/gnutls-3.0.18/tests/pkcs12-decode'
> > NEON PKCS12 OK client.p12 foobar
> > NEON PKCS12 OK noclient.p12
> > NEON PKCS12 OK unclient.p12
> > Segmentation Fault
> 
> Could you apply the patch and run the pkcs12 test? (you'll need valgrind)
> 
> regards,
> Nikos
>




From yoi_no_myoujou at yahoo.co.jp  Wed Apr  4 05:24:34 2012
From: yoi_no_myoujou at yahoo.co.jp (Kiyoshi KANAZAWA)
Date: Wed, 4 Apr 2012 12:24:34 +0900 (JST)
Subject: gnutls-3.0.18 make check fails on Solaris10
In-Reply-To: <634747.15702.qm@web100710.mail.kks.yahoo.co.jp>
Message-ID: <956415.14515.qm@web100706.mail.kks.yahoo.co.jp>

Hi, Nikos,

(2) Segmentation Fault is my error.
I install GNU software in /usr/local/GNU instead of /usr/local,
and have to specify -I/usr/local/GNU/include.
I also specified -I/TOP/lib before that, but it should be -I/TOP/lib/includes.
With this (both -I/TOP/lib/includes & -DAF_LOCAL=AF_UNIX),
pkcs12 passed.

(1) 'AF_LOCAL' undeclared
As I mentioned in the previous e-mail, it chenged to
FAIL: simple
FAIL: mini-termination
by -DAF_LOCAL=AF_UNIX

Regards,

--- Kiyoshi <yoi_no_myoujou at yahoo.co.jp>

--- On Wed, 2012/4/4, Kiyoshi KANAZAWA <yoi_no_myoujou at yahoo.co.jp> wrote:

> Hi, Nikos,
> 
> Answer to your quiestions.
> 
> (1) 'AF_LOCAL' undeclared
> Yes, they compile with -DAF_LOCAL=AF_UNIX
> But encountered new FAILs such as
> gnutls_check_version ERROR
> Self test `./simple' finished with 1 errors
> FAIL: simple
> ? ? :
> client: Unexpected error: -9 (A TLS packet with unexpected length was received.)
> Child died with status 1
> FAIL: mini-termination
> 
> (2) Segmentation Fault
> Error messages are changed by the patch (No Segmentation Fault now).
> # It seems to be correct because valgrind-3.7.0 could not be installed saying that
> # "configure: error: Valgrind is operating system specific. Sorry."
> ./pkcs12: valgrind: not found
> cat: cannot open out
> NEON PKCS12 FATAL client.p12 foobar
> ./pkcs12: valgrind: not found
> cat: cannot open out
> NEON PKCS12 FATAL noclient.p12
> ./pkcs12: valgrind: not found
> cat: cannot open out
> NEON PKCS12 FATAL unclient.p12
> ./pkcs12: valgrind: not found
> cat: cannot open out
> NEON PKCS12 FATAL pkcs12_2certs.p12
> NEON PKCS12 DONE (rc 1)
> FAIL: pkcs12
> 
> Regards,
> 
> --- Kiyoshi <yoi_no_myoujou at yahoo.co.jp>
> 
> --- On Tue, 2012/4/3, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> 
> > On Tue, Apr 3, 2012 at 4:00 PM, Kiyoshi KANAZAWA
> > <yoi_no_myoujou at yahoo.co.jp> wrote:
> > 
> > Hello,
> >? Thank you for the report. Some questions inline.
> > 
> > > Gnutls-3.0.18 make check fails on Solaris10 x86-64.
> > > There are 2 types of errors.
> > > (1) 'AF_LOCAL' undeclared
> > > ?CC ? ? mini-loss-time.o
> > > mini-loss-time.c: In function `start':
> > > mini-loss-time.c:256: error: `AF_LOCAL' undeclared (first use in this function)
> > 
> > If you define AF_LOCAL to AF_UNIX do they compile?
> > 
> > > (2) Segmentation Fault
> > > make[3]: Entering directory `/tmp/gnutls-3.0.18/tests/pkcs12-decode'
> > > NEON PKCS12 OK client.p12 foobar
> > > NEON PKCS12 OK noclient.p12
> > > NEON PKCS12 OK unclient.p12
> > > Segmentation Fault
> > 
> > Could you apply the patch and run the pkcs12 test? (you'll need valgrind)
> > 
> > regards,
> > Nikos
> >
> 
> 



From nmav at gnutls.org  Wed Apr  4 09:23:34 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 4 Apr 2012 09:23:34 +0200
Subject: gnutls 3.0.18
In-Reply-To: <20120403194521.1e2e32d8@laptop64.home>
References: <4F79F2AD.4020202@gnutls.org>
	<20120403194521.1e2e32d8@laptop64.home>
Message-ID: <CAJU7zaKH_hjDgxd-uxZbgr49yMWWTW5XJ51_u08nDhvvNS-TBw@mail.gmail.com>

On Tue, Apr 3, 2012 at 7:45 PM, Andreas Radke <a.radke at arcor.de> wrote:
> make check hang here for all time even when running non-parallel:
[...]
> any idea? we had something similar in 3.0.10 release.

This is on gnulib generated code. What was your process to compile and check?

regards,
Nikos



From nmav at gnutls.org  Wed Apr  4 09:25:19 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 4 Apr 2012 09:25:19 +0200
Subject: gnutls-3.0.18 make check fails on Solaris10
In-Reply-To: <956415.14515.qm@web100706.mail.kks.yahoo.co.jp>
References: <634747.15702.qm@web100710.mail.kks.yahoo.co.jp>
	<956415.14515.qm@web100706.mail.kks.yahoo.co.jp>
Message-ID: <CAJU7zaJn6fTytVEG2_ZmLxaxStzeCQiopaYPPdYQ=c6kWxO5oA@mail.gmail.com>

On Wed, Apr 4, 2012 at 5:24 AM, Kiyoshi KANAZAWA
<yoi_no_myoujou at yahoo.co.jp> wrote:

> (1) 'AF_LOCAL' undeclared
> As I mentioned in the previous e-mail, it chenged to
> FAIL: simple
> FAIL: mini-termination
> by -DAF_LOCAL=AF_UNIX

Nice. Could you provide me the output of
$ simple -v
and
$ mini-termination -v



regards,
Nikos



From yoi_no_myoujou at yahoo.co.jp  Wed Apr  4 12:30:50 2012
From: yoi_no_myoujou at yahoo.co.jp (Kiyoshi KANAZAWA)
Date: Wed, 4 Apr 2012 19:30:50 +0900 (JST)
Subject: gnutls-3.0.18 make check fails on Solaris10
In-Reply-To: <CAJU7zaJn6fTytVEG2_ZmLxaxStzeCQiopaYPPdYQ=c6kWxO5oA@mail.gmail.com>
Message-ID: <250954.5333.qm@web100712.mail.kks.yahoo.co.jp>

Hi, Nikos,

Checking "simple -v", I understood /usr/local/GNU/lib/libgnutls.so.28 was linked instead of TOP/gnutls-3.0.18/lib/.libs/libgnutls.so.28.
After setting "TOP/gnutls-3.0.18/lib/.libs" to the head of LD_LIBRARY_PATH,
both "simple" and "mini-termination" passed.
It seemed that there is no problem except for -DAF_LOCAL=AF_UNIX, if old versions of GNUTLS are uninstalled, but, 
I encountered "Segmentation Fault" in pkcs12 again, even if I specifyed -I(TOP)/lib/includes.
It might be unstable.

This time, made coredump and watched it.
NULL is given to the parameter of fprintf's "%s" in print_bag_data (), certtool.c

% pwd
/tmp/gnutls-3.0.18/tests/pkcs12-decode 
% pkcs12 -v
NEON PKCS12 OK client.p12 foobar
NEON PKCS12 OK noclient.p12
NEON PKCS12 OK unclient.p12
Segmentation Fault - core dumped
        Type: Encrypted

        Decrypting...
        Type: Certificate
        Type: Certificate
NEON PKCS12 FATAL pkcs12_2certs.p12
NEON PKCS12 DONE (rc 1)
% file core
core: ELF 32-bit LSB core file 80386 Version 1, from 'certtool'
% file `find /tmp/gnutls-3.0.18 -type f -name certtool`
/tmp/gnutls-3.0.18/src/.libs/certtool: ELF 32-bit LSB executable 80386 Version 1, dynamically linked, not stripped
/tmp/gnutls-3.0.18/src/certtool: executable /bin/bash script

%dbx /tmp/gnutls-3.0.18/src/.libs/certtool core
    :
t at 1 (l at 1) program terminated by signal SEGV (no mapping at the fault address)
0xfe9f63dc: strlen+0x000c:      movl     (%eax),%edx
Current function is print_bag_data
 2605         fprintf (outfile, "\tKey ID: %s\n", raw_to_string (id.data, id.size));
(dbx) where
current thread: t at 1
dbx: internal error: reference through NULL pointer at line 1111 in file symbol.cc
  [1] strlen(0x0), at 0xfe9f63dc 
  [2] _ndoprnt(0x807ae0a, 0x8046638, 0x808f5d0, 0x0), at 0xfea5169a 
  [3] _fprintf(0x808f5d0, 0x807adff, 0x0, 0x808f5e0, 0x8046660, 0xfefc4a84), at 0xfea54229 
=>[4] print_bag_data( (inlined), line 2605 in "certtool.c"
  [5] pkcs12_info(cinfo = (nil)), line -2106288 in "certtool.c"

Regards,

--- Kiyoshi <yoi_no_myoujou at yahoo.co.jp>


--- On Wed, 2012/4/4, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:

> On Wed, Apr 4, 2012 at 5:24 AM, Kiyoshi KANAZAWA
> <yoi_no_myoujou at yahoo.co.jp> wrote:
> 
> > (1) 'AF_LOCAL' undeclared
> > As I mentioned in the previous e-mail, it chenged to
> > FAIL: simple
> > FAIL: mini-termination
> > by -DAF_LOCAL=AF_UNIX
> 
> Nice. Could you provide me the output of
> $ simple -v
> and
> $ mini-termination -v
> 
> 
> 
> regards,
> Nikos
> 



From nmav at gnutls.org  Wed Apr  4 17:31:05 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 04 Apr 2012 17:31:05 +0200
Subject: gnutls 3.0.18
In-Reply-To: <20120404165704.6d244e69@laptop64.home>
References: <4F79F2AD.4020202@gnutls.org>	<20120403194521.1e2e32d8@laptop64.home>	<CAJU7zaKH_hjDgxd-uxZbgr49yMWWTW5XJ51_u08nDhvvNS-TBw@mail.gmail.com>
	<20120404165704.6d244e69@laptop64.home>
Message-ID: <4F7C6939.7070008@gnutls.org>

On 04/04/2012 04:57 PM, Andreas Radke wrote:


> build() {
>   cd "${srcdir}/${pkgname}-${pkgver}"
>   ./configure --prefix=/usr \
> 	--with-zlib \
> 	--disable-static \
> 	--disable-guile \
> 	--disable-valgrind-tests
>   make
> }


So I suppose this is over a build system. Do you see the issue if you do
$ tar xvf gnutls-3.0.18.tar.lz
$ cd gnutls-3.0.18
$ make -jx
$ make check
?

regards,
Nikos



From me at enric.me  Wed Apr  4 15:00:54 2012
From: me at enric.me (Enric Caussa Morales)
Date: Wed, 4 Apr 2012 15:00:54 +0200
Subject: 1 Failed test on GNUTLS 3.0.18
Message-ID: <20120404130054.GB26547@balrog>

Good day.
I've been building 3.0.18 on Arch Linux PPC, and during `make check'
there's a failed test. GCC version is 4.6.2. Here's the bit that fails:

	test-float.c:344: assertion failed
	/bin/sh: line 5:  8887 Aborted                 EXEEXT='' srcdir='.'
	abs_aux_dir='/build/src/gnutls-3.0.18/build-aux' MAKE='make' ${dir}$tst
	FAIL: test-float
	PASS: test-fputc

What information can I add to solve this?
Thanks,

-- 
Enric Caussa Morales
<me at enric.me>



From a.radke at arcor.de  Wed Apr  4 16:57:04 2012
From: a.radke at arcor.de (Andreas Radke)
Date: Wed, 4 Apr 2012 16:57:04 +0200
Subject: gnutls 3.0.18
In-Reply-To: <CAJU7zaKH_hjDgxd-uxZbgr49yMWWTW5XJ51_u08nDhvvNS-TBw@mail.gmail.com>
References: <4F79F2AD.4020202@gnutls.org>
	<20120403194521.1e2e32d8@laptop64.home>
	<CAJU7zaKH_hjDgxd-uxZbgr49yMWWTW5XJ51_u08nDhvvNS-TBw@mail.gmail.com>
Message-ID: <20120404165704.6d244e69@laptop64.home>

Am Wed, 4 Apr 2012 09:23:34 +0200
schrieb Nikos Mavrogiannopoulos <nmav at gnutls.org>:

> This is on gnulib generated code. What was your process to compile
> and check?
> 
> regards,
> Nikos

build() {
  cd "${srcdir}/${pkgname}-${pkgver}"
  ./configure --prefix=/usr \
	--with-zlib \
	--disable-static \
	--disable-guile \
	--disable-valgrind-tests
  make
}

check() {
  cd "${srcdir}/${pkgname}-${pkgver}"
  make check 
}

package() {
  cd "${srcdir}/${pkgname}-${pkgver}"
  make DESTDIR="${pkgdir}" install


-Andy



From nmav at gnutls.org  Thu Apr  5 08:57:26 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 5 Apr 2012 08:57:26 +0200
Subject: 1 Failed test on GNUTLS 3.0.18
In-Reply-To: <20120404130054.GB26547@balrog>
References: <20120404130054.GB26547@balrog>
Message-ID: <CAJU7zaK8xqH8JEmb5KfJuAiWHVuHkF68y758uoPYWKSL3fgzFw@mail.gmail.com>

On Wed, Apr 4, 2012 at 3:00 PM, Enric Caussa Morales <me at enric.me> wrote:
> Good day.
> I've been building 3.0.18 on Arch Linux PPC, and during `make check'
> there's a failed test. GCC version is 4.6.2. Here's the bit that fails:
> ? ? ? ?test-float.c:344: assertion failed
> ? ? ? ?/bin/sh: line 5: ?8887 Aborted ? ? ? ? ? ? ? ? EXEEXT='' srcdir='.'
> ? ? ? ?abs_aux_dir='/build/src/gnutls-3.0.18/build-aux' MAKE='make' ${dir}$tst
> ? ? ? ?FAIL: test-float
> ? ? ? ?PASS: test-fputc

Hello,
 This is a floating point test suite, from gnulib. Does this processor
has floating point?
If you do:
$ cd tests
$ make check

in the gnutls top directory do all tests succeed?

regards,
Nikos



From nmav at gnutls.org  Thu Apr  5 11:01:57 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 5 Apr 2012 11:01:57 +0200
Subject: gnutls 3.0.18
In-Reply-To: <4F7C6939.7070008@gnutls.org>
References: <4F79F2AD.4020202@gnutls.org>
	<20120403194521.1e2e32d8@laptop64.home>
	<CAJU7zaKH_hjDgxd-uxZbgr49yMWWTW5XJ51_u08nDhvvNS-TBw@mail.gmail.com>
	<20120404165704.6d244e69@laptop64.home>
	<4F7C6939.7070008@gnutls.org>
Message-ID: <CAJU7zaLxKyXwaWfcC0R_0M58C2ibqeRtWCFrK=9-WeTZD2v=CQ@mail.gmail.com>

On Wed, Apr 4, 2012 at 5:31 PM, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:

> So I suppose this is over a build system. Do you see the issue if you do
> $ tar xvf gnutls-3.0.18.tar.lz
> $ cd gnutls-3.0.18
> $ make -jx
> $ make check
> ?

Could you be that you have a .git directory inside gnutls directory?



From a.radke at arcor.de  Thu Apr  5 19:15:40 2012
From: a.radke at arcor.de (Andreas Radke)
Date: Thu, 5 Apr 2012 19:15:40 +0200
Subject: gnutls 3.0.18
In-Reply-To: <CAJU7zaLxKyXwaWfcC0R_0M58C2ibqeRtWCFrK=9-WeTZD2v=CQ@mail.gmail.com>
References: <4F79F2AD.4020202@gnutls.org>
	<20120403194521.1e2e32d8@laptop64.home>
	<CAJU7zaKH_hjDgxd-uxZbgr49yMWWTW5XJ51_u08nDhvvNS-TBw@mail.gmail.com>
	<20120404165704.6d244e69@laptop64.home>
	<4F7C6939.7070008@gnutls.org>
	<CAJU7zaLxKyXwaWfcC0R_0M58C2ibqeRtWCFrK=9-WeTZD2v=CQ@mail.gmail.com>
Message-ID: <20120405191540.49d177b0@laptop64.home>

Am Thu, 5 Apr 2012 11:01:57 +0200
schrieb Nikos Mavrogiannopoulos <nmav at gnutls.org>:

> On Wed, Apr 4, 2012 at 5:31 PM, Nikos Mavrogiannopoulos
> <nmav at gnutls.org> wrote:
> 
> > So I suppose this is over a build system. Do you see the issue if
> > you do $ tar xvf gnutls-3.0.18.tar.lz
> > $ cd gnutls-3.0.18
> > $ make -jx
> > $ make check
> > ?
> 
> Could you be that you have a .git directory inside gnutls directory?
> 

Just found out that there's a hanging mini-loss-time process probably
preventing a proper make check finish.

-Andy



From ametzler at downhill.at.eu.org  Thu Apr  5 20:01:23 2012
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Thu, 5 Apr 2012 20:01:23 +0200
Subject: gnutls 3.0.18
In-Reply-To: <4F79F2AD.4020202@gnutls.org>
References: <4F79F2AD.4020202@gnutls.org>
Message-ID: <20120405180123.GA2434@downhill.g.la>

On 2012-04-02 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> Hello,
>  I've just released gnutls 3.0.18. This is a bug-fix release on the
> current stable branch. Note that this release is available both
> under xz and lzip compression formats. We might switch to using only
> one of these compression formats in the future.
[...]

Hello,

Speaking with my Debian hat I would prefer to keep using xz. We would
not be able to ship the original tarballs but would need to
re-compress, as lzip is currently not a supported by the source
packages.

-------------

With this release the testsuite again does not cleanly exit, if one
redirects stdout/err the build hangs. I have not got time currently to
track this down to a single test.

cu andreas




From nmav at gnutls.org  Thu Apr  5 18:29:56 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 05 Apr 2012 18:29:56 +0200
Subject: gnutls-3.0.18 make check fails on Solaris10
In-Reply-To: <250954.5333.qm@web100712.mail.kks.yahoo.co.jp>
References: <250954.5333.qm@web100712.mail.kks.yahoo.co.jp>
Message-ID: <4F7DC884.7060601@gnutls.org>

On 04/04/2012 12:30 PM, Kiyoshi KANAZAWA wrote:

> Hi, Nikos,
> 
> Checking "simple -v", I understood /usr/local/GNU/lib/libgnutls.so.28 was linked instead of TOP/gnutls-3.0.18/lib/.libs/libgnutls.so.28.
> After setting "TOP/gnutls-3.0.18/lib/.libs" to the head of LD_LIBRARY_PATH,
> both "simple" and "mini-termination" passed.
> It seemed that there is no problem except for -DAF_LOCAL=AF_UNIX, if old versions of GNUTLS are uninstalled, but, 
> I encountered "Segmentation Fault" in pkcs12 again, even if I specifyed -I(TOP)/lib/includes.
> It might be unstable.
> This time, made coredump and watched it.
> NULL is given to the parameter of fprintf's "%s" in print_bag_data (), certtool.c


This shouldn't have happened. What do you see after applying this patch
(and compiling)?

regards,
Nikos
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch.txt
URL: </pipermail/attachments/20120405/d452017e/attachment.txt>

From nmav at gnutls.org  Fri Apr  6 00:11:06 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 06 Apr 2012 00:11:06 +0200
Subject: gnutls 3.0.18
In-Reply-To: <20120405191540.49d177b0@laptop64.home>
References: <4F79F2AD.4020202@gnutls.org>	<20120403194521.1e2e32d8@laptop64.home>	<CAJU7zaKH_hjDgxd-uxZbgr49yMWWTW5XJ51_u08nDhvvNS-TBw@mail.gmail.com>	<20120404165704.6d244e69@laptop64.home>	<4F7C6939.7070008@gnutls.org>	<CAJU7zaLxKyXwaWfcC0R_0M58C2ibqeRtWCFrK=9-WeTZD2v=CQ@mail.gmail.com>
	<20120405191540.49d177b0@laptop64.home>
Message-ID: <4F7E187A.1030201@gnutls.org>

On 04/05/2012 07:15 PM, Andreas Radke wrote:


> Just found out that there's a hanging mini-loss-time process probably
> preventing a proper make check finish.


mini-loss-time should spend around 60-70 seconds running, are you sure
it is hanging? The make check output you sent in your first e-mail
showed it terminate properly.





From yoi_no_myoujou at yahoo.co.jp  Fri Apr  6 01:06:49 2012
From: yoi_no_myoujou at yahoo.co.jp (Kiyoshi KANAZAWA)
Date: Fri, 6 Apr 2012 08:06:49 +0900 (JST)
Subject: gnutls-3.0.18 make check fails on Solaris10
Message-ID: <360372.35704.qm@web100720.mail.kks.yahoo.co.jp>

Hi, Nikos,

"Segmentation Fault"  disappeared after applying the patch.
Attached file is the result of "pkcs12 -v" (with the patch).

Regards,

--- Kiyoshi <yoi_no_myoujou at yahoo.co.jp>

--- On Fri, 2012/4/6, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:

> On 04/04/2012 12:30 PM, Kiyoshi KANAZAWA wrote:
> 
> > Hi, Nikos,
> > 
> > Checking "simple -v", I understood /usr/local/GNU/lib/libgnutls.so.28 was linked instead of TOP/gnutls-3.0.18/lib/.libs/libgnutls.so.28.
> > After setting "TOP/gnutls-3.0.18/lib/.libs" to the head of LD_LIBRARY_PATH,
> > both "simple" and "mini-termination" passed.
> > It seemed that there is no problem except for -DAF_LOCAL=AF_UNIX, if old versions of GNUTLS are uninstalled, but, 
> > I encountered "Segmentation Fault" in pkcs12 again, even if I specifyed -I(TOP)/lib/includes.
> > It might be unstable.
> > This time, made coredump and watched it.
> > NULL is given to the parameter of fprintf's "%s" in print_bag_data (), certtool.c
> 
> 
> This shouldn't have happened. What do you see after applying this patch
> (and compiling)?
> 
> regards,
> Nikos
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pkcs12.log
Type: text/x-log
Size: 8266 bytes
Desc: not available
URL: </pipermail/attachments/20120406/ac52d7ee/attachment.bin>

From nmav at gnutls.org  Fri Apr  6 08:43:27 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 06 Apr 2012 08:43:27 +0200
Subject: gnutls-3.0.18 make check fails on Solaris10
In-Reply-To: <360372.35704.qm@web100720.mail.kks.yahoo.co.jp>
References: <360372.35704.qm@web100720.mail.kks.yahoo.co.jp>
Message-ID: <4F7E908F.7040602@gnutls.org>

On 04/06/2012 01:06 AM, Kiyoshi KANAZAWA wrote:

> Hi, Nikos,
> 
> "Segmentation Fault"  disappeared after applying the patch.
> Attached file is the result of "pkcs12 -v" (with the patch).

Thank you for the information provide. I've solved the issue using
the following commit (the previous patch is not needed).

http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=206cd53276d284b3a1649b8d61a28d271a8a6247

This was a bug in the test rather than a bug in the library so
you can safely ignore it for now.

best regards,
Nikos



From nmav at gnutls.org  Fri Apr  6 08:55:52 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 06 Apr 2012 08:55:52 +0200
Subject: gnutls 3.0.18
In-Reply-To: <20120405180123.GA2434@downhill.g.la>
References: <4F79F2AD.4020202@gnutls.org> <20120405180123.GA2434@downhill.g.la>
Message-ID: <4F7E9378.7010708@gnutls.org>

On 04/05/2012 08:01 PM, Andreas Metzler wrote:

> Hello,
> With this release the testsuite again does not cleanly exit, if one
> redirects stdout/err the build hangs. I have not got time currently to
> track this down to a single test.


Hi,
 I tried to reproduce by doing "make check >/tmp/out 2>&1" and it
completed (it took few minutes though). Is there some other way to
reproduce it?

regards,
Nikos




From INVALID.NOREPLY at gnu.org  Fri Apr  6 12:33:35 2012
From: INVALID.NOREPLY at gnu.org (Darren Davison)
Date: Fri, 06 Apr 2012 10:33:35 +0000
Subject: [sr #108004] Since GnuTLS 3.0.17 upgrade,
	evolution 3.2.x and newer cannot synchronise with google calendar
	account
In-Reply-To: <20120402-215357.sv707.62962@savannah.gnu.org>
References: <20120327-191056.sv85256.91775@savannah.gnu.org>
	<20120328-074702.sv0.71531@savannah.gnu.org>
	<20120328-081323.sv85256.47512@savannah.gnu.org>
	<20120328-082128.sv0.54490@savannah.gnu.org>
	<20120328-090754.sv85256.78849@savannah.gnu.org>
	<20120328-151125.sv73763.63696@savannah.gnu.org>
	<20120328-152642.sv85256.5203@savannah.gnu.org>
	<20120328-193827.sv85256.57035@savannah.gnu.org>
	<20120328-194632.sv85256.9286@savannah.gnu.org>
	<20120329-090548.sv0.97596@savannah.gnu.org>
	<20120329-091157.sv85256.65360@savannah.gnu.org>
	<20120329-101545.sv0.80853@savannah.gnu.org>
	<20120402-215357.sv707.62962@savannah.gnu.org>
Message-ID: <20120406-103335.sv87759.63492@savannah.gnu.org>

Follow-up Comment #10, sr #108004 (project gnutls):

I can confirm that 3.0.18 fixed this issue for me (Arch Linux).  Thank you.

    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Fri Apr  6 18:44:03 2012
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Fri, 06 Apr 2012 16:44:03 +0000
Subject: [sr #108004] Since GnuTLS 3.0.17 upgrade,
	evolution 3.2.x and newer cannot synchronise with google calendar
	account
In-Reply-To: <20120406-103335.sv87759.63492@savannah.gnu.org>
References: <20120327-191056.sv85256.91775@savannah.gnu.org>
	<20120328-074702.sv0.71531@savannah.gnu.org>
	<20120328-081323.sv85256.47512@savannah.gnu.org>
	<20120328-082128.sv0.54490@savannah.gnu.org>
	<20120328-090754.sv85256.78849@savannah.gnu.org>
	<20120328-151125.sv73763.63696@savannah.gnu.org>
	<20120328-152642.sv85256.5203@savannah.gnu.org>
	<20120328-193827.sv85256.57035@savannah.gnu.org>
	<20120328-194632.sv85256.9286@savannah.gnu.org>
	<20120329-090548.sv0.97596@savannah.gnu.org>
	<20120329-091157.sv85256.65360@savannah.gnu.org>
	<20120329-101545.sv0.80853@savannah.gnu.org>
	<20120402-215357.sv707.62962@savannah.gnu.org>
	<20120406-103335.sv87759.63492@savannah.gnu.org>
Message-ID: <20120406-194403.sv707.61620@savannah.gnu.org>

Update of sr #108004 (project gnutls):

             Open/Closed:                    Open => Closed                 


    _______________________________________________________

Reply to this item at:

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

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




From ametzler at downhill.at.eu.org  Fri Apr  6 19:45:21 2012
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Fri, 6 Apr 2012 19:45:21 +0200
Subject: gnutls 3.0.18
In-Reply-To: <4F7E9378.7010708@gnutls.org>
References: <4F79F2AD.4020202@gnutls.org> <20120405180123.GA2434@downhill.g.la>
	<4F7E9378.7010708@gnutls.org>
Message-ID: <20120406174521.GA2792@downhill.g.la>

On 2012-04-06 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> On 04/05/2012 08:01 PM, Andreas Metzler wrote:
> > With this release the testsuite again does not cleanly exit, if one
> > redirects stdout/err the build hangs. I have not got time currently to
> > track this down to a single test.


> Hi,
>  I tried to reproduce by doing "make check >/tmp/out 2>&1" and it
> completed (it took few minutes though). Is there some other way to
> reproduce it?

Hej,
tee does the trick.
make check 2>&1 | tee /tmp/foo

mini-loss-time seems to be the culprit, reverting the single line
change from 3.0.17 to 3.0.18
(4965c2fbfd3405e2dfe7f7d747d03185d155c2a1) seems to fix the issue.
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 nmav at gnutls.org  Sat Apr  7 08:53:58 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 07 Apr 2012 08:53:58 +0200
Subject: gnutls 3.0.18
In-Reply-To: <20120406174521.GA2792@downhill.g.la>
References: <4F79F2AD.4020202@gnutls.org>
	<20120405180123.GA2434@downhill.g.la>	<4F7E9378.7010708@gnutls.org>
	<20120406174521.GA2792@downhill.g.la>
Message-ID: <4F7FE486.4060608@gnutls.org>

On 04/06/2012 07:45 PM, Andreas Metzler wrote:

> Hej,
> tee does the trick.
> make check 2>&1 | tee /tmp/foo
> 
> mini-loss-time seems to be the culprit, reverting the single line
> change from 3.0.17 to 3.0.18
> (4965c2fbfd3405e2dfe7f7d747d03185d155c2a1) seems to fix the issue.


I undid it.

Thanks,
Nikos




From lrn1986 at gmail.com  Sun Apr  8 20:28:43 2012
From: lrn1986 at gmail.com (LRN)
Date: Sun, 08 Apr 2012 22:28:43 +0400
Subject: [W32] gnutls-2.12.18 fixes
Message-ID: <4F81D8DB.6020404@gmail.com>

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

W32 support in GNUTLS 2.x deteriorated a little bit since my last
patching session. Here's a few things that require fixing:
1) gnutls-2.12.18/lib/nettle/egd.* is incompatible with W32 (uses UNIX
domain sockets, absolute UNIX-style paths, calls stat() on integer
file descriptors thought to be sockets, and uses S_IFSOCK). It should
be disabled at configure time.
2) gnutls-2.12.18/lib/nettle/rnd.c requires #include <wincrypt.h> on W32
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPgdjaAAoJEOs4Jb6SI2Cwt2AIAKklNgkkJpo1YqTcy9HasmNS
GcfV0BSRQO2ftjEh3YeEPtm9igoPoSZkzCMmRTslCCx6mD3NbZGo3qIcdJnvWDzk
RKGyZtvCLz6Fi+Wz9g9vnmKb3yIrXDvrvDh4nHYlpMCTD1ZpGdsApja99GbaC379
bTp3P321y4E5hTQWmZKNQJSygKv+JhVYkXgJoD2DTa6SF7oZwMYJSH3c9eMFH7N7
ihw9FQxSLhF3FDhfF88PCmdxIMTzFddsVNFgsN7ISSJhzgn0fYZdYIK0owP0+aP+
3bNnzajR4S6NdEhG0qzYrfEIZFGEVna+6TErLmWWeYNPGWXfAoJpOLt7y9B7O8M=
=k4Oc
-----END PGP SIGNATURE-----



From nmav at gnutls.org  Mon Apr  9 15:15:44 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 09 Apr 2012 15:15:44 +0200
Subject: [W32] gnutls-2.12.18 fixes
In-Reply-To: <4F81D8DB.6020404@gmail.com>
References: <4F81D8DB.6020404@gmail.com>
Message-ID: <4F82E100.6080105@gnutls.org>

On 04/08/2012 08:28 PM, LRN wrote:

> W32 support in GNUTLS 2.x deteriorated a little bit since my last
> patching session. Here's a few things that require fixing:
> 1) gnutls-2.12.18/lib/nettle/egd.* is incompatible with W32 (uses UNIX
> domain sockets, absolute UNIX-style paths, calls stat() on integer
> file descriptors thought to be sockets, and uses S_IFSOCK). It should
> be disabled at configure time.
> 2) gnutls-2.12.18/lib/nettle/rnd.c requires #include <wincrypt.h> on W32


Hello,
 Do these issues occur in gnutls 3.0.18?

regards,
Nikos


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

From lrn1986 at gmail.com  Mon Apr  9 16:13:15 2012
From: lrn1986 at gmail.com (LRN)
Date: Mon, 09 Apr 2012 18:13:15 +0400
Subject: [W32] gnutls-2.12.18 fixes
In-Reply-To: <4F82E100.6080105@gnutls.org>
References: <4F81D8DB.6020404@gmail.com> <4F82E100.6080105@gnutls.org>
Message-ID: <4F82EE7B.8040900@gmail.com>

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

On 09.04.2012 17:15, Nikos Mavrogiannopoulos wrote:
> On 04/08/2012 08:28 PM, LRN wrote:
> 
>> W32 support in GNUTLS 2.x deteriorated a little bit since my
>> last patching session. Here's a few things that require fixing: 
>> 1) gnutls-2.12.18/lib/nettle/egd.* is incompatible with W32 (uses
>> UNIX domain sockets, absolute UNIX-style paths, calls stat() on
>> integer file descriptors thought to be sockets, and uses
>> S_IFSOCK). It should be disabled at configure time. 2)
>> gnutls-2.12.18/lib/nettle/rnd.c requires #include <wincrypt.h> on
>> W32
> 
> 
> Hello, Do these issues occur in gnutls 3.0.18?
> 
No idea, haven't tried 3.x yet (should i?).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPgu54AAoJEOs4Jb6SI2CwQScIAJeyqF/oCTT/3svBO1z1V0Dr
oJVB/pN+v4JdPy88xnstTAZXHVmUvOCi+mPWnFwv4dq9LYYNuE4dm0KibAA8Pid+
zGPr2gVVRqY3koECmdLLuMV0mkQQpvUakd0zW4CKopwREfcaTNCsXZ1Ep3oclRdz
VT3STUuZlaTv7RYKcnMto379NjY3e7Yx5SA/X3CMC8aT+cSBHgxGKe+U+ZLZad0f
4gBcA+ynduxqbsLicmK4HDzWQ19aosoud90vxNcVmwtb46Lb5Wyi3w+HPA13SHb6
n57a8Lj9JhXk1ufU+07f8B9MJhtRs5aLTfxE4CHAzijCsIDA1VyE5WASA9iAmU4=
=zL7r
-----END PGP SIGNATURE-----



From nmav at gnutls.org  Mon Apr  9 17:55:53 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 09 Apr 2012 17:55:53 +0200
Subject: [W32] gnutls-2.12.18 fixes
In-Reply-To: <4F82EE7B.8040900@gmail.com>
References: <4F81D8DB.6020404@gmail.com> <4F82E100.6080105@gnutls.org>
	<4F82EE7B.8040900@gmail.com>
Message-ID: <4F830689.1070101@gnutls.org>

On 04/09/2012 04:13 PM, LRN wrote:

>>> W32 support in GNUTLS 2.x deteriorated a little bit since my
>>> last patching session. Here's a few things that require fixing: 
>>> 1) gnutls-2.12.18/lib/nettle/egd.* is incompatible with W32 (uses
>>> UNIX domain sockets, absolute UNIX-style paths, calls stat() on
>>> integer file descriptors thought to be sockets, and uses
>>> S_IFSOCK). It should be disabled at configure time. 2)
>>> gnutls-2.12.18/lib/nettle/rnd.c requires #include <wincrypt.h> on
>>> W32
>> Hello, Do these issues occur in gnutls 3.0.18?
> No idea, haven't tried 3.x yet (should i?).


I'd suggest yes, because 3.0 is the current stable branch. The 2.12.x is
pretty much end of life.

regards,
Nikos


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

From ludo at gnu.org  Mon Apr  9 22:07:34 2012
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Mon, 09 Apr 2012 22:07:34 +0200
Subject: [3.0.18] =?utf-8?Q?=E2=80=98mini-loss-time=E2=80=99?= left running
	after =?utf-8?B?4oCcbWFrZSBjaGVja+KAnQ==?=
Message-ID: <87hawsekjd.fsf@gnu.org>

Hello,

FYI ?make check? in 3.0.18 leaves a ?mini-loss-time? process behind it.
I haven?t taken the time to investigate.

Thanks,
Ludo?.



From nmav at gnutls.org  Mon Apr  9 22:40:21 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 09 Apr 2012 22:40:21 +0200
Subject: [3.0.18] =?UTF-8?B?4oCYbWluaS1sb3NzLXRpbWXigJkgbGVmdCBydW5uaQ==?=
	=?UTF-8?B?bmcgYWZ0ZXIg4oCcbWFrZSBjaGVja+KAnQ==?=
In-Reply-To: <87hawsekjd.fsf@gnu.org>
References: <87hawsekjd.fsf@gnu.org>
Message-ID: <4F834935.2000806@gnutls.org>

On 04/09/2012 10:07 PM, Ludovic Court?s wrote:

> Hello,
> 
> FYI ?make check? in 3.0.18 leaves a ?mini-loss-time? process behind it.
> I haven?t taken the time to investigate.


Thanks for reporting it. This issue should be solved in master.

regards,
Nikos




From lrn1986 at gmail.com  Mon Apr  9 22:45:58 2012
From: lrn1986 at gmail.com (LRN)
Date: Tue, 10 Apr 2012 00:45:58 +0400
Subject: [W32] gnutls-2.12.18 fixes
In-Reply-To: <4F830689.1070101@gnutls.org>
References: <4F81D8DB.6020404@gmail.com> <4F82E100.6080105@gnutls.org>
	<4F82EE7B.8040900@gmail.com> <4F830689.1070101@gnutls.org>
Message-ID: <4F834A86.2070005@gmail.com>

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

On 09.04.2012 19:55, Nikos Mavrogiannopoulos wrote:
> On 04/09/2012 04:13 PM, LRN wrote:
> 
>>>> W32 support in GNUTLS 2.x deteriorated a little bit since my 
>>>> last patching session. Here's a few things that require
>>>> fixing: 1) gnutls-2.12.18/lib/nettle/egd.* is incompatible
>>>> with W32 (uses UNIX domain sockets, absolute UNIX-style
>>>> paths, calls stat() on integer file descriptors thought to be
>>>> sockets, and uses S_IFSOCK). It should be disabled at
>>>> configure time. 2) gnutls-2.12.18/lib/nettle/rnd.c requires
>>>> #include <wincrypt.h> on W32
>>> Hello, Do these issues occur in gnutls 3.0.18?
>> No idea, haven't tried 3.x yet (should i?).
> 
> 
> I'd suggest yes, because 3.0 is the current stable branch. The
> 2.12.x is pretty much end of life.
> 
libopts depends on libintl on W32, but -lintl is not added to its
dependencies.
The attached patch is W32-only, because it adds -lintl
unconditionally. I can get away with that, but you'll probably need to
set some variable to "-lintl" in configure, AC_SUBST() it, and use it
to set libopts_la_LIBADD in src/libopts/Makefile.am

Other than that, everything is fine - all enabled tests pass.
gl tests fail to compile, but after patching (i've attached the patch)
they all pass too.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPg0qGAAoJEOs4Jb6SI2CwMqYIAIouMGIZaOquzCPXPEsTrRsq
p7xmorQkspkWyk2PpSNPOoPkfzkIV00eOVc7A8n+V1XI68InGu73UEQ49n7WsQPk
4HO5MgjqLT1y7CqjQ6c2PVfSgiFslzXUjRMMu+ZI935txBdIVWj7GUXAboZ0diMi
VNIEjGLmaz0sd7qJL0QuOV1o3SO4Z5n+CljR4vmz4Xoa5XNhpkbiwpD1cL67mhef
FchPlugP483omLJNpWuWewDfPXLhdC8EObtqAA/4j6qZzKainkpHN9X3DgOmnESJ
dNkW4hB2s5u3boLfZjIRDiIedN3w566ff3UQD1sILEA1szm/giuuTC5/M8ZWAaQ=
=lokj
-----END PGP SIGNATURE-----
-------------- next part --------------
--- gnutls-3.0.18/src/libopts/Makefile.am.orig	2012-03-22 23:08:06 +0400
+++ gnutls-3.0.18/src/libopts/Makefile.am	2012-04-09 21:14:01 +0400
@@ -8,6 +8,7 @@
 libopts_la_SOURCES      = libopts.c
 libopts_la_CPPFLAGS     = -I$(top_srcdir)
 libopts_la_LDFLAGS      = -version-info  36:3:11
+libopts_la_LIBADD       = -lintl
 EXTRA_DIST              = \
     ag-char-map.h           alias.c                 ao-strs.c  \
     ao-strs.h               autoopts/project.h      autoopts/options.h  \
-------------- next part --------------
--- gnutls-3.0.18/gl/tests/ioctl.c.orig	2012-02-08 13:38:01 +0400
+++ gnutls-3.0.18/gl/tests/ioctl.c	2012-04-09 23:40:46 +0400
@@ -49,6 +49,8 @@
 # include "fd-hook.h"
 /* Get _get_osfhandle.  */
 # include "msvc-nothrow.h"
+/* Get HANDLE */
+# include <windows.h>
 
 static int
 primary_ioctl (int fd, int request, void *arg)

From nmav at gnutls.org  Tue Apr 10 20:06:18 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 10 Apr 2012 20:06:18 +0200
Subject: [W32] gnutls-2.12.18 fixes
In-Reply-To: <4F834A86.2070005@gmail.com>
References: <4F81D8DB.6020404@gmail.com> <4F82E100.6080105@gnutls.org>
	<4F82EE7B.8040900@gmail.com> <4F830689.1070101@gnutls.org>
	<4F834A86.2070005@gmail.com>
Message-ID: <4F84769A.6030806@gnutls.org>

On 04/09/2012 10:45 PM, LRN wrote:

>> I'd suggest yes, because 3.0 is the current stable branch. The
>> 2.12.x is pretty much end of life.
> libopts depends on libintl on W32, but -lintl is not added to its
> dependencies.
> The attached patch is W32-only, because it adds -lintl
> unconditionally. I can get away with that, but you'll probably need to
> set some variable to "-lintl" in configure, AC_SUBST() it, and use it
> to set libopts_la_LIBADD in src/libopts/Makefile.am
> Other than that, everything is fine - all enabled tests pass.
> gl tests fail to compile, but after patching (i've attached the patch)
> they all pass too.


Thank you. I've forwarded the patches to gnulib and libopts. Hopefully
they'll be included in the next release of gnutls.

regards,
Nikos


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

From nmav at gnutls.org  Wed Apr 11 22:04:42 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 11 Apr 2012 22:04:42 +0200
Subject: [W32] gnutls-2.12.18 fixes
In-Reply-To: <4F834A86.2070005@gmail.com>
References: <4F81D8DB.6020404@gmail.com> <4F82E100.6080105@gnutls.org>
	<4F82EE7B.8040900@gmail.com> <4F830689.1070101@gnutls.org>
	<4F834A86.2070005@gmail.com>
Message-ID: <4F85E3DA.40404@gnutls.org>

On 04/09/2012 10:45 PM, LRN wrote:

> libopts depends on libintl on W32, but -lintl is not added to its
> dependencies.

> The attached patch is W32-only, because it adds -lintl

> unconditionally. I can get away with that, but you'll probably need to
> set some variable to "-lintl" in configure, AC_SUBST() it, and use it
> to set libopts_la_LIBADD in src/libopts/Makefile.am


Do you build gnutls with --disable-nls or just normal?
In any case would the attached patch solve the issue you see?

regards,
Nikos


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch.txt
URL: </pipermail/attachments/20120411/52bbe5e1/attachment.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 554 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20120411/52bbe5e1/attachment.pgp>

From lrn1986 at gmail.com  Wed Apr 11 23:08:45 2012
From: lrn1986 at gmail.com (LRN)
Date: Thu, 12 Apr 2012 01:08:45 +0400
Subject: [W32] gnutls-2.12.18 fixes
In-Reply-To: <4F85E3DA.40404@gnutls.org>
References: <4F81D8DB.6020404@gmail.com> <4F82E100.6080105@gnutls.org>
	<4F82EE7B.8040900@gmail.com> <4F830689.1070101@gnutls.org>
	<4F834A86.2070005@gmail.com> <4F85E3DA.40404@gnutls.org>
Message-ID: <4F85F2DD.4020805@gmail.com>

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

On 12.04.2012 0:04, Nikos Mavrogiannopoulos wrote:
> On 04/09/2012 10:45 PM, LRN wrote:
> 
>> libopts depends on libintl on W32, but -lintl is not added to
>> its dependencies.
> 
>> The attached patch is W32-only, because it adds -lintl
> 
>> unconditionally. I can get away with that, but you'll probably
>> need to set some variable to "-lintl" in configure, AC_SUBST()
>> it, and use it to set libopts_la_LIBADD in
>> src/libopts/Makefile.am
> 
> 
> Do you build gnutls with --disable-nls or just normal?
with --enable-nls
> In any case would the attached patch solve the issue you see?
yes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPhfLdAAoJEOs4Jb6SI2CwX2EH/R3ugFMYaAlcGW8CFBJRAxIl
FGaSJLuqha8PqUfiLr5KZUTOlFZBksTGtgiUFalfDeZkQYWxh6CAKj5u6o93IEZO
7e6jYVu/x2JlEY38/mRpCwVgCc7Yp/LsyniY2IVn54F96tLz/RwDxqj5vqOZO6RO
+6mHHd+/1WOjaH3+edeWe71NVyrDP/SXdFSmrbHWOuJOANp7PzLdINnTGwz4lk4D
DKXeJTPP2+aOQSBjSUn3ee5XZMY7KMa3YntTDX54hSegAsPSGWQvnMSvKZ7UrA5K
CElhrarwHLAIpo5jZ6LGQDcEGnKvQKv5jC54gt9AWoLL/aY2RDh/sU9O3C2qAHw=
=XWhr
-----END PGP SIGNATURE-----



From ametzler at downhill.at.eu.org  Sun Apr 15 09:35:40 2012
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Sun, 15 Apr 2012 09:35:40 +0200
Subject: LP#929108 support reading PIN from file when using PKCS#11 devices
Message-ID: <20120415073540.GC2059@downhill.g.la>

Hello,

FYI launchpad bug
https://bugs.launchpad.net/ubuntu/+source/gnutls26/+bug/929108 says
that specifying a PIN file for accessing PKCS#11 devices is broken in 
gnutls 3.x and 2.12.x due to a change in p11-kit.

I cannot test this, however the patch in the bug report still applies to
master. I have also seen that gnutls is using
p11_kit_uri_get_pinfile() which was marked as deprecated in favour of 
p11_kit_uri_get_pin_source() in p11-kit 0.4.

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 impulze at impulze.org  Sun Apr 15 18:13:23 2012
From: impulze at impulze.org (Daniel Mierswa)
Date: Sun, 15 Apr 2012 18:13:23 +0200
Subject: [PATCH] make crywrap optional
Message-ID: <1334506403-9048-1-git-send-email-impulze@impulze.org>

---
 configure.ac |    9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index 5350a90..4ce677f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -409,7 +409,14 @@ AC_CHECK_FUNCS([alarm atexit dup2 epoll_create kqueue memchr memset munmap \
 		putenv regcomp scandir select socket strcasecmp strchr \
 		strdup strerror strncasecmp strrchr strstr strtoul uname])
 
-PKG_CHECK_MODULES(LIBIDN, libidn >= 0.0.0, [libidn=yes], [libidn=no])
+AC_ARG_ENABLE(crywrap,
+	AS_HELP_STRING([--disable-crywrap], [unconditionally disable the crywrap TLS proxy service]))
+
+libidn=no
+
+if test "x$enable_crywrap" != "xno" ; then
+	PKG_CHECK_MODULES(LIBIDN, libidn >= 0.0.0, [libidn=yes], [libidn=no])
+fi
 
  if test "x$libidn" != "xno" && test "$ac_cv_func_daemon" != "no";then
   crywrap=yes
-- 
1.7.9.6




From nmav at gnutls.org  Mon Apr 16 13:21:16 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 16 Apr 2012 13:21:16 +0200
Subject: [PATCH] make crywrap optional
In-Reply-To: <1334506403-9048-1-git-send-email-impulze@impulze.org>
References: <1334506403-9048-1-git-send-email-impulze@impulze.org>
Message-ID: <CAJU7zaKEcDDZHz+h+S+TY1nQNBTWdMOsCHPRw9yYqofpwOx3Ag@mail.gmail.com>

Hello,
 Would you like to comment a bit on why you propose doing crywrap optional?

regards,
Nikos

On Sun, Apr 15, 2012 at 6:13 PM, Daniel Mierswa <impulze at impulze.org> wrote:
> ---
> ?configure.ac | ? ?9 ++++++++-
> ?1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/configure.ac b/configure.ac
> index 5350a90..4ce677f 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -409,7 +409,14 @@ AC_CHECK_FUNCS([alarm atexit dup2 epoll_create kqueue memchr memset munmap \
> ? ? ? ? ? ? ? ?putenv regcomp scandir select socket strcasecmp strchr \
> ? ? ? ? ? ? ? ?strdup strerror strncasecmp strrchr strstr strtoul uname])
>
> -PKG_CHECK_MODULES(LIBIDN, libidn >= 0.0.0, [libidn=yes], [libidn=no])
> +AC_ARG_ENABLE(crywrap,
> + ? ? ? AS_HELP_STRING([--disable-crywrap], [unconditionally disable the crywrap TLS proxy service]))
> +
> +libidn=no
> +
> +if test "x$enable_crywrap" != "xno" ; then
> + ? ? ? PKG_CHECK_MODULES(LIBIDN, libidn >= 0.0.0, [libidn=yes], [libidn=no])
> +fi
>
> ?if test "x$libidn" != "xno" && test "$ac_cv_func_daemon" != "no";then
> ? crywrap=yes
> --
> 1.7.9.6
>
>
> _______________________________________________
> Gnutls-devel mailing list
> Gnutls-devel at gnu.org
> https://lists.gnu.org/mailman/listinfo/gnutls-devel



From INVALID.NOREPLY at gnu.org  Mon Apr 16 15:28:16 2012
From: INVALID.NOREPLY at gnu.org (Mallikarjun)
Date: Mon, 16 Apr 2012 13:28:16 +0000
Subject: [sr #108028] My own public method, exposed to DLL
Message-ID: <20120416-132815.sv87870.62476@savannah.gnu.org>

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

                 Summary: My own public method, exposed to DLL
                 Project: GnuTLS
            Submitted by: mallugb
            Submitted on: Mon 16 Apr 2012 01:28:15 PM GMT
                Category: Core library
                Priority: 5 - Normal
                Severity: 4 - Important
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
        Operating System: Microsoft Windows

    _______________________________________________________

Details:

Hallo,

I would like to implement one public method in GNU-TLS, which should be linked
and exported via the DLL. 

How can I achieve the same?
Can some one please help.

Thanks.

Regards,
Malik

 




    _______________________________________________________

Reply to this item at:

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

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




From nmav at gnutls.org  Mon Apr 16 18:28:34 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 16 Apr 2012 18:28:34 +0200
Subject: Fwd: LP#929108 support reading PIN from file when using PKCS#11
	devices
In-Reply-To: <4F8C42AC.4060102@gnome.org>
References: <20120415073540.GC2059@downhill.g.la>
	<4F8B16AC.3030401@gnutls.org> <4F8C42AC.4060102@gnome.org>
Message-ID: <4F8C48B2.4090403@gnutls.org>

On 04/16/2012 06:02 PM, Stef Walter wrote:

> On 2012-04-15 20:42, Nikos Mavrogiannopoulos wrote:
>> Hello Stef,
>>  I see the patch and I think it is based on a misunderstanding of what
>> pinfile is (or was). However, I'm not sure how the "pin" field is used
>> in p11-kit. Is there a way for someone to specify a pin in a file?
> 
> p11-kit has functions to coordinate use of the pin-source (which used to
> called the pinfile) of a uri.
> 
> Applications or libraries that which to 'provide' a PIN can install
> handlers for different values of pin-source. Gnutls (or other consumers
> of PINs) then call p11_kit_pin_request(), which will redirect to the
> correct pin-source handler.
> 
> By default no pin-source handlers are installed. By adding the following
> default handler, p11-kit to default to treating pin-source (or pinfile)
> actual files. It will handle invocations of p11_kit_pin_request() by
> reading actual files:
> 
>   p11_kit_pin_register_callback (P11_KIT_PIN_FALLBACK,
>                                  p11_kit_pin_file_callback,
>                                  NULL, NULL);
> 
> It's up to you if you want this as default behavior for gnutls. It may
> make sense.


Indeed it makes sense to be the default. Could this, however, have bad
interactions with other callbacks that may be registered by other
programs or libraries?

> The patch adds that line so I guess that's the real meat of the
> suggested change.

There is also a change to avoid calling retrieve_pin_for_pinfile if
attempts is zero. I've currently included it but although it seems
sensible for a file read, it might break other callbacks. Does the
p11-kit file read callback fail if the attempt is not the first one?

I've currently added the check, but if the file callback fails
I should remove it.

http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=c1eddcfe663b9e3cb9a411f855e00f49811ff205

regards,
Nikos



From nmav at gnutls.org  Mon Apr 16 18:39:34 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 16 Apr 2012 18:39:34 +0200
Subject: Fwd: LP#929108 support reading PIN from file when using PKCS#11
	devices
In-Reply-To: <4F8C48B2.4090403@gnutls.org>
References: <20120415073540.GC2059@downhill.g.la>
	<4F8B16AC.3030401@gnutls.org> <4F8C42AC.4060102@gnome.org>
	<4F8C48B2.4090403@gnutls.org>
Message-ID: <4F8C4B46.5070204@gnutls.org>

On 04/16/2012 06:28 PM, Nikos Mavrogiannopoulos wrote:

>> The patch adds that line so I guess that's the real meat of the
>> suggested change.
> There is also a change to avoid calling retrieve_pin_for_pinfile if
> attempts is zero. I've currently included it but although it seems
> sensible for a file read, it might break other callbacks. Does the
> p11-kit file read callback fail if the attempt is not the first one?

Ok I see that there exists the line
if (pin_flags & P11_KIT_PIN_FLAGS_RETRY) return NULL;
thus there is no reason for the check in attempts. I have modified the
patch.

regards,
Nikos



From nmav at gnutls.org  Mon Apr 16 18:50:36 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 16 Apr 2012 18:50:36 +0200
Subject: Fwd: LP#929108 support reading PIN from file when using PKCS#11
	devices
In-Reply-To: <4F8C4BE4.9000208@gnome.org>
References: <20120415073540.GC2059@downhill.g.la>
	<4F8B16AC.3030401@gnutls.org> <4F8C42AC.4060102@gnome.org>
	<4F8C48B2.4090403@gnutls.org> <4F8C4BE4.9000208@gnome.org>
Message-ID: <4F8C4DDC.6080603@gnutls.org>

On 04/16/2012 06:42 PM, Stef Walter wrote:

> 
>  * An application uses a URI which it received from an untrusted
>    source.
>  * The URI contains a pin-source which nobody in the stack has
>    registered to handle (and thus the gnutls installed fallback file
>    handler is used).
>  * And the application wasn't expecting the PKCS#11 URI to read from a
>    file and use it as a PIN.
>  * And somehow this gives an attacker an advantage they would not

>    otherwise have.

Interesting.

> I think that's a pretty remote possibility, and if an attacker can
> specify a PKCS#11 URI at all, then they are able to control which keys
> and certs are used. In that case it seems that being able to specify a
> PIN read from a file is irrelevant. PKCS#11 URIs should not come from
> untrusted sources.


Maybe this can be mitigated by providing a sanitize_pkcs11_url()
function that would strip this field? Then programmers would be advised
to call this function for untrusted urls.

> But for sanity's sake would we want to limit the size of the file that
> p11-kit will read in its p11_kit_pin_file_callback() handler?


Having a sanity check would also be good regardless of a url sanitize
function.

>> I've currently added the check, but if the file callback fails

>> I should remove it.
> Now that I think about it, I don't think the attempts check is correct.
> It assumes that the PIN returned from a registered pin-source handler
> will always be identical on each try. That's the case for the
> p11_kit_pin_file_callback() but not the case for pretty much any other
> handler (such as prompts and such).


I've removed it. p11_kit_pin_file_callback() properly handles the
P11_KIT_PIN_FLAGS_RETRY flag.

regards,
Nikos



From nmav at gnutls.org  Mon Apr 16 20:22:35 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 16 Apr 2012 20:22:35 +0200
Subject: Fwd: LP#929108 support reading PIN from file when using PKCS#11
	devices
In-Reply-To: <4F8C566A.9040101@gnome.org>
References: <20120415073540.GC2059@downhill.g.la>
	<4F8B16AC.3030401@gnutls.org> <4F8C42AC.4060102@gnome.org>
	<4F8C48B2.4090403@gnutls.org> <4F8C4BE4.9000208@gnome.org>
	<4F8C4DDC.6080603@gnutls.org> <4F8C566A.9040101@gnome.org>
Message-ID: <4F8C636B.3020307@gnutls.org>

On 04/16/2012 07:27 PM, Stef Walter wrote:


>> Maybe this can be mitigated by providing a sanitize_pkcs11_url()
>> function that would strip this field? Then programmers would be advised
>> to call this function for untrusted urls.
> Is the problem of PKCS#11 URIs from untrusted sources sufficiently
> understood? Until the problem and use cases are better understood, I
> would err on the side of discouraging any use of PKCS#11 URIs from
> untrusted sources.


Untrusted sources is quite difficult to define. Untrusted source
might also be the user in some application, so a sanitization might
be required for some applications.

>>> But for sanity's sake would we want to limit the size of the file that
>>> p11-kit will read in its p11_kit_pin_file_callback() handler?
>> Having a sanity check would also be good regardless of a url sanitize
>> function.
> 1MB be a good max sanity check size?


For a PIN? I'd use something like 256 bytes or so!

> Also, while we're on the topic, is the current behavior of reading the
> PIN file byte-for-byte verbatim what's generally expected?


Are there alternatives? PKCS #11 accepts a byte string anyway.

regards,
Nikos



From stefw at gnome.org  Mon Apr 16 17:47:03 2012
From: stefw at gnome.org (Stef Walter)
Date: Mon, 16 Apr 2012 17:47:03 +0200
Subject: Fix build failure on git master
Message-ID: <4F8C3EF7.9090101@gnome.org>

Hi there,

gnutls git master fails (for me) with the following message:

certtool-args.c:55:13: error: conflicting types for 'optionAlias'
In file included from certtool-args.h:49:0,
                 from certtool-args.c:48:
../src/libopts/autoopts/options.h:1031:12: note: previous declaration of
'optionAlias' was here
make[3]: *** [libcmd_certtool_la-certtool-args.lo] Error 1
make[3]: Leaving directory `/data/projects/gnutls/src'

Patch attached.

In addition configure.ac doesn't check for the 'autogen' tool, and so in
its absence one gets failures later on in the build.

Cheers,

Stef
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Fix-build-error-with-duplicate-declaration.patch
Type: text/x-patch
Size: 849 bytes
Desc: not available
URL: </pipermail/attachments/20120416/682b376b/attachment.bin>

From stefw at gnome.org  Mon Apr 16 18:42:12 2012
From: stefw at gnome.org (Stef Walter)
Date: Mon, 16 Apr 2012 18:42:12 +0200
Subject: Fwd: LP#929108 support reading PIN from file when using PKCS#11
	devices
In-Reply-To: <4F8C48B2.4090403@gnutls.org>
References: <20120415073540.GC2059@downhill.g.la>
	<4F8B16AC.3030401@gnutls.org> <4F8C42AC.4060102@gnome.org>
	<4F8C48B2.4090403@gnutls.org>
Message-ID: <4F8C4BE4.9000208@gnome.org>

On 2012-04-16 18:28, Nikos Mavrogiannopoulos wrote:
> On 04/16/2012 06:02 PM, Stef Walter wrote:
>> By default no pin-source handlers are installed. By adding the following
>> default handler, p11-kit to default to treating pin-source (or pinfile)
>> actual files. It will handle invocations of p11_kit_pin_request() by
>> reading actual files:
>>
>>   p11_kit_pin_register_callback (P11_KIT_PIN_FALLBACK,
>>                                  p11_kit_pin_file_callback,
>>                                  NULL, NULL);
>>
>> It's up to you if you want this as default behavior for gnutls. It may
>> make sense.
> 
> Indeed it makes sense to be the default. Could this, however, have bad
> interactions with other callbacks that may be registered by other
> programs or libraries?

Other programs or libraries can install handlers for specific pin
sources. Or they can register fallback handlers. Relevant handlers each
have a turn to return a PIN when p11_kit_pin_request() is called, so
technically it should all work.

Not sure if there is a possible theoretical remote security issue if:

 * An application uses a URI which it received from an untrusted
   source.
 * The URI contains a pin-source which nobody in the stack has
   registered to handle (and thus the gnutls installed fallback file
   handler is used).
 * And the application wasn't expecting the PKCS#11 URI to read from a
   file and use it as a PIN.
 * And somehow this gives an attacker an advantage they would not
   otherwise have.

I think that's a pretty remote possibility, and if an attacker can
specify a PKCS#11 URI at all, then they are able to control which keys
and certs are used. In that case it seems that being able to specify a
PIN read from a file is irrelevant. PKCS#11 URIs should not come from
untrusted sources.

But for sanity's sake would we want to limit the size of the file that
p11-kit will read in its p11_kit_pin_file_callback() handler?

>> The patch adds that line so I guess that's the real meat of the
>> suggested change.
> 
> There is also a change to avoid calling retrieve_pin_for_pinfile if
> attempts is zero. I've currently included it but although it seems
> sensible for a file read, it might break other callbacks. Does the
> p11-kit file read callback fail if the attempt is not the first one?
> 
> I've currently added the check, but if the file callback fails
> I should remove it.

Now that I think about it, I don't think the attempts check is correct.
It assumes that the PIN returned from a registered pin-source handler
will always be identical on each try. That's the case for the
p11_kit_pin_file_callback() but not the case for pretty much any other
handler (such as prompts and such).

In fact I'm pretty sure this change would break glib-networking. Let me
know if you want me to test further.

To mitigate this change, do you think that p11_kit_pin_file_callback()
should not handle the request if it detects that this isn't the first
attempt to read a PIN? Seems like this could fix the issue of an endless
loop, where callers assume that the pin-source handlers will 'give up'
but the p11_kit_pin_file_callback() never gives up returning the same PIN.

Cheers,

Stef



From stefw at gnome.org  Mon Apr 16 18:43:29 2012
From: stefw at gnome.org (Stef Walter)
Date: Mon, 16 Apr 2012 18:43:29 +0200
Subject: Fwd: LP#929108 support reading PIN from file when using PKCS#11
	devices
In-Reply-To: <4F8C4B46.5070204@gnutls.org>
References: <20120415073540.GC2059@downhill.g.la>
	<4F8B16AC.3030401@gnutls.org> <4F8C42AC.4060102@gnome.org>
	<4F8C48B2.4090403@gnutls.org> <4F8C4B46.5070204@gnutls.org>
Message-ID: <4F8C4C31.201@gnome.org>

On 2012-04-16 18:39, Nikos Mavrogiannopoulos wrote:
> On 04/16/2012 06:28 PM, Nikos Mavrogiannopoulos wrote:
> 
>>> The patch adds that line so I guess that's the real meat of the
>>> suggested change.
>> There is also a change to avoid calling retrieve_pin_for_pinfile if
>> attempts is zero. I've currently included it but although it seems
>> sensible for a file read, it might break other callbacks. Does the
>> p11-kit file read callback fail if the attempt is not the first one?
> 
> Ok I see that there exists the line
> if (pin_flags & P11_KIT_PIN_FLAGS_RETRY) return NULL;
> thus there is no reason for the check in attempts. I have modified the
> patch.

Ah yes. Ignore my comments about this in the other email. Looks like I
already fixed it to prevent an endless loop.

Cheers,

Stef



From stefw at gnome.org  Mon Apr 16 19:27:06 2012
From: stefw at gnome.org (Stef Walter)
Date: Mon, 16 Apr 2012 19:27:06 +0200
Subject: Fwd: LP#929108 support reading PIN from file when using PKCS#11
	devices
In-Reply-To: <4F8C4DDC.6080603@gnutls.org>
References: <20120415073540.GC2059@downhill.g.la>
	<4F8B16AC.3030401@gnutls.org> <4F8C42AC.4060102@gnome.org>
	<4F8C48B2.4090403@gnutls.org> <4F8C4BE4.9000208@gnome.org>
	<4F8C4DDC.6080603@gnutls.org>
Message-ID: <4F8C566A.9040101@gnome.org>

On 2012-04-16 18:50, Nikos Mavrogiannopoulos wrote:
> On 04/16/2012 06:42 PM, Stef Walter wrote:
> 
>>
>>  * An application uses a URI which it received from an untrusted
>>    source.
>>  * The URI contains a pin-source which nobody in the stack has
>>    registered to handle (and thus the gnutls installed fallback file
>>    handler is used).
>>  * And the application wasn't expecting the PKCS#11 URI to read from a
>>    file and use it as a PIN.
>>  * And somehow this gives an attacker an advantage they would not
> 
>>    otherwise have.
> 
> Interesting.
> 
>> I think that's a pretty remote possibility, and if an attacker can
>> specify a PKCS#11 URI at all, then they are able to control which keys
>> and certs are used. In that case it seems that being able to specify a
>> PIN read from a file is irrelevant. PKCS#11 URIs should not come from
>> untrusted sources.
> 
> 
> Maybe this can be mitigated by providing a sanitize_pkcs11_url()
> function that would strip this field? Then programmers would be advised
> to call this function for untrusted urls.

Is the problem of PKCS#11 URIs from untrusted sources sufficiently
understood? Until the problem and use cases are better understood, I
would err on the side of discouraging any use of PKCS#11 URIs from
untrusted sources.

>> But for sanity's sake would we want to limit the size of the file that
>> p11-kit will read in its p11_kit_pin_file_callback() handler?
> 
> 
> Having a sanity check would also be good regardless of a url sanitize
> function.

1MB be a good max sanity check size?

Also, while we're on the topic, is the current behavior of reading the
PIN file byte-for-byte verbatim what's generally expected?

Cheers,

Stef



From stefw at gnome.org  Mon Apr 16 18:02:52 2012
From: stefw at gnome.org (Stef Walter)
Date: Mon, 16 Apr 2012 18:02:52 +0200
Subject: Fwd: LP#929108 support reading PIN from file when using PKCS#11
	devices
In-Reply-To: <4F8B16AC.3030401@gnutls.org>
References: <20120415073540.GC2059@downhill.g.la> <4F8B16AC.3030401@gnutls.org>
Message-ID: <4F8C42AC.4060102@gnome.org>

On 2012-04-15 20:42, Nikos Mavrogiannopoulos wrote:
> Hello Stef,
>  I see the patch and I think it is based on a misunderstanding of what
> pinfile is (or was). However, I'm not sure how the "pin" field is used
> in p11-kit. Is there a way for someone to specify a pin in a file?

p11-kit has functions to coordinate use of the pin-source (which used to
called the pinfile) of a uri.

Applications or libraries that which to 'provide' a PIN can install
handlers for different values of pin-source. Gnutls (or other consumers
of PINs) then call p11_kit_pin_request(), which will redirect to the
correct pin-source handler.

By default no pin-source handlers are installed. By adding the following
default handler, p11-kit to default to treating pin-source (or pinfile)
actual files. It will handle invocations of p11_kit_pin_request() by
reading actual files:

  p11_kit_pin_register_callback (P11_KIT_PIN_FALLBACK,
                                 p11_kit_pin_file_callback,
                                 NULL, NULL);

It's up to you if you want this as default behavior for gnutls. It may
make sense.

The patch adds that line so I guess that's the real meat of the
suggested change.

I'm not sure what p11-kit regression David is referring to that broke
this. Andreas if you have more info, let me know. I'd be happy to fix it
if possible.

The rest of the patch (outside of the call to
p11_kit_pin_register_callback()) seems about cosmetics and logging.

Cheers,

Stef



From nmav at gnutls.org  Mon Apr 16 22:53:32 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 16 Apr 2012 22:53:32 +0200
Subject: Fix build failure on git master
In-Reply-To: <4F8C3EF7.9090101@gnome.org>
References: <4F8C3EF7.9090101@gnome.org>
Message-ID: <4F8C86CC.7040404@gnutls.org>

On 04/16/2012 05:47 PM, Stef Walter wrote:

> Hi there,
> gnutls git master fails (for me) with the following message:
> 
> certtool-args.c:55:13: error: conflicting types for 'optionAlias'
> In file included from certtool-args.h:49:0,
>                  from certtool-args.c:48:
> ../src/libopts/autoopts/options.h:1031:12: note: previous declaration of
> 'optionAlias' was here
> make[3]: *** [libcmd_certtool_la-certtool-args.lo] Error 1
> make[3]: Leaving directory `/data/projects/gnutls/src'
> 
> Patch attached.


Thanks, I've forwarded it to the author of autogen.

> In addition configure.ac doesn't check for the 'autogen' tool, and so in
> its absence one gets failures later on in the build.


Indeed but it is not required for normal (non-git) builds thus we don't
check for it. However because we normally depend on a specific version
of it, it might be better to commit the auto-generated files. I'll do it
after the new autogen release.

regards,
Nikos



From INVALID.NOREPLY at gnu.org  Tue Apr 17 08:21:29 2012
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Tue, 17 Apr 2012 06:21:29 +0000
Subject: [sr #108028] My own public method, exposed to DLL
In-Reply-To: <20120416-132815.sv87870.62476@savannah.gnu.org>
References: <20120416-132815.sv87870.62476@savannah.gnu.org>
Message-ID: <20120417-092129.sv707.87122@savannah.gnu.org>

Update of sr #108028 (project gnutls):

                  Status:                    None => Invalid                
             Open/Closed:                    Open => Closed                 

    _______________________________________________________

Follow-up Comment #1:

Please use the help-gnutls mailing list for support requests.

http://www.gnu.org/software/gnutls/lists.html

    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Tue Apr 17 15:30:05 2012
From: INVALID.NOREPLY at gnu.org (=?UTF-8?B?QmrDuHJu?= Christensen)
Date: Tue, 17 Apr 2012 13:30:05 +0000
Subject: [sr #108029] Build does not honnor --disable-openpgp
Message-ID: <20120417-133004.sv79827.44446@savannah.gnu.org>

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

                 Summary: Build does not honnor --disable-openpgp
                 Project: GnuTLS
            Submitted by: cybear
            Submitted on: Tue 17 Apr 2012 01:30:04 PM GMT
                Category: Core library
                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:

I have just tried to build gnutls version 3.0.18 on Linux, AIX and windows and
all of them fails due to error in verify-tofu.c and common.c. I am building
with --disable-openpgp and these to files does not honnor the disable
setting.

added #ifdef ENABLE_OPENPGP to verify-tofu.c a couple of places seems to make
the build complete.

I have attached my version of verify-tofu.c so you can see where I had to add
the 3 defines.


/bhc



    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Tue 17 Apr 2012 01:30:04 PM GMT  Name: verify-tofu-3.0.18.c  Size: 22kB 
 By: cybear

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

    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Tue Apr 17 21:41:12 2012
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Tue, 17 Apr 2012 19:41:12 +0000
Subject: [sr #108029] Build does not honnor --disable-openpgp
In-Reply-To: <20120417-133004.sv79827.44446@savannah.gnu.org>
References: <20120417-133004.sv79827.44446@savannah.gnu.org>
Message-ID: <20120417-224112.sv707.29411@savannah.gnu.org>

Update of sr #108029 (project gnutls):

                  Status:                    None => Done                   

    _______________________________________________________

Follow-up Comment #1:

Thanks for reporting it. I've commited a similar fix.

http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=bfedb373f4b53da3380d29177b3a20e8d133589a


    _______________________________________________________

Reply to this item at:

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

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




From nmav at gnutls.org  Tue Apr 17 23:10:13 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 17 Apr 2012 23:10:13 +0200
Subject: [PATCH] make crywrap optional
In-Reply-To: <4F8C46C4.6080909@impulze.org>
References: <1334506403-9048-1-git-send-email-impulze@impulze.org>
	<CAJU7zaKEcDDZHz+h+S+TY1nQNBTWdMOsCHPRw9yYqofpwOx3Ag@mail.gmail.com>
	<4F8C46C4.6080909@impulze.org>
Message-ID: <4F8DDC35.6010001@gnutls.org>

On 04/16/2012 06:20 PM, Daniel Mierswa wrote:


>>  Would you like to comment a bit on why you propose doing crywrap optional?
> I don't know anyone including myself that would need it.
> And besides that it's not feasible for source distribution packagers when they want
> to package gnutls without depending on libidn.
> One way would seem to be always enabling or disabling it in the package
> to not restrict users to either choice.
> I prefer making it optional because, in a way, it already is, depending on the presence
> of libidn.


Applied. Thank you.

Nikos



From bique.alexandre at gmail.com  Wed Apr 18 19:08:36 2012
From: bique.alexandre at gmail.com (Alexandre Bique)
Date: Wed, 18 Apr 2012 19:08:36 +0200
Subject: [PATCH 1/1] Add gnutls::session::set_transport_vec_push().
Message-ID: <4F8EF514.70409@gmail.com>

Hi,

This patch add missing function set_transport_vec_push() to the C++ wrapper.

Regards,
-- 
Alexandre Bique
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-gnutls-session-set_transport_vec_push.patch
Type: text/x-patch
Size: 1407 bytes
Desc: not available
URL: </pipermail/attachments/20120418/26aead2c/attachment.bin>

From nmav at gnutls.org  Wed Apr 18 22:41:36 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 18 Apr 2012 22:41:36 +0200
Subject: [PATCH 1/1] Add gnutls::session::set_transport_vec_push().
In-Reply-To: <4F8EF514.70409@gmail.com>
References: <4F8EF514.70409@gmail.com>
Message-ID: <4F8F2700.5020301@gnutls.org>

On 04/18/2012 07:08 PM, Alexandre Bique wrote:

> This patch add missing function set_transport_vec_push() to the C++ wrapper.


Applied in master. Thank you.


Nikos




From bique.alexandre at gmail.com  Wed Apr 18 23:06:08 2012
From: bique.alexandre at gmail.com (Alexandre Bique)
Date: Wed, 18 Apr 2012 23:06:08 +0200
Subject: bug in 3.0.18: gnutls-cli fails to transfer data to gnutls-serv --echo
Message-ID: <4F8F2CC0.6070507@gmail.com>

Hi,

I reported the bug first to archlinux, but I forward it here:
https://bugs.archlinux.org/task/29531

I have a bug with GnuTLS-3.0.18, which is that my httpd server (custom
implementation) fails to serve pages to chromium and firefox goes into
an infinite loop. But in the other hand, wget (which is linked against
openssl) succeed in getting files from my server.

There is an easy thing to do to reproduce the bug:

- start a gnutls echo server: gnutls-serv --x509keyfile=key.pem
--x509certfile=cert.pem -p 4242 --disable-client-cert --nodb --generate
--echo

- start a client, and copy a big file: cat /usr/include/*.h >test-file;
gnutls-cli --insecure 0.0.0.0 -p 4242 <test-file

Then it doesn't work :^)

You can also test with an openssl client (it will fail as well): openssl
s_client -connect 0.0.0.0:4242 <test-file

I am using x86_64 architecture.

Regards,
-- 
Alexandre Bique



From nmav at gnutls.org  Thu Apr 19 09:06:35 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 19 Apr 2012 09:06:35 +0200
Subject: bug in 3.0.18: gnutls-cli fails to transfer data to gnutls-serv
	--echo
In-Reply-To: <4F8F2CC0.6070507@gmail.com>
References: <4F8F2CC0.6070507@gmail.com>
Message-ID: <4F8FB97B.8000106@gnutls.org>

On 04/18/2012 11:06 PM, Alexandre Bique wrote:

> I reported the bug first to archlinux, but I forward it here:
> https://bugs.archlinux.org/task/29531
> I have a bug with GnuTLS-3.0.18, which is that my httpd server (custom
> implementation) fails to serve pages to chromium and firefox goes into
> an infinite loop. But in the other hand, wget (which is linked against
> openssl) succeed in getting files from my server.

Hello,
 why you think this is a gnutls error? There are other web servers like
libmicrohttpd, nxweb or apache's mod_gnutls that as far as I know they
have no such issues with firefox or chromium.

> There is an easy thing to do to reproduce the bug:
> - start a gnutls echo server: gnutls-serv --x509keyfile=key.pem
> --x509certfile=cert.pem -p 4242 --disable-client-cert --nodb --generate
> --echo

> - start a client, and copy a big file: cat /usr/include/*.h >test-file;

> gnutls-cli --insecure 0.0.0.0 -p 4242 <test-file
> Then it doesn't work :^)


What doesn't work? gnutls-serv is a test server and many things might
not work. However this seems unrelated to the above where you mention
incompatibility with chromium and firefox. Does gnutls-serv --http
work with the browsers you mention?

regards,
Nikos



From bique.alexandre at gmail.com  Thu Apr 19 11:42:57 2012
From: bique.alexandre at gmail.com (Alexandre Bique)
Date: Thu, 19 Apr 2012 11:42:57 +0200
Subject: bug in 3.0.18: gnutls-cli fails to transfer data to gnutls-serv
	--echo
In-Reply-To: <4F8FB97B.8000106@gnutls.org>
References: <4F8F2CC0.6070507@gmail.com> <4F8FB97B.8000106@gnutls.org>
Message-ID: <CAP737oJFE84z=Ewx386ns4qQ+cP-9FzzCeVOzhpQ_16yhKSfkg@mail.gmail.com>

On Thu, Apr 19, 2012 at 09:06, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> On 04/18/2012 11:06 PM, Alexandre Bique wrote:
>
>> I reported the bug first to archlinux, but I forward it here:
>> https://bugs.archlinux.org/task/29531
>> I have a bug with GnuTLS-3.0.18, which is that my httpd server (custom
>> implementation) fails to serve pages to chromium and firefox goes into
>> an infinite loop. But in the other hand, wget (which is linked against
>> openssl) succeed in getting files from my server.
>
> Hello,
> ?why you think this is a gnutls error? There are other web servers like
> libmicrohttpd, nxweb or apache's mod_gnutls that as far as I know they
> have no such issues with firefox or chromium.

Yep I had a bug in my code, but for the firefox part, it look like you
can take it down by sending an infinite text file over http, because
it is keeping every thing in memory.

>> There is an easy thing to do to reproduce the bug:
>> - start a gnutls echo server: gnutls-serv --x509keyfile=key.pem
>> --x509certfile=cert.pem -p 4242 --disable-client-cert --nodb --generate
>> --echo
>
>> - start a client, and copy a big file: cat /usr/include/*.h >test-file;
>
>> gnutls-cli --insecure 0.0.0.0 -p 4242 <test-file
>> Then it doesn't work :^)
>
>
> What doesn't work? gnutls-serv is a test server and many things might
> not work. However this seems unrelated to the above where you mention
> incompatibility with chromium and firefox. Does gnutls-serv --http
> work with the browsers you mention?

I'm digging and you may be right, but I still have an error when
"cating" a file through openssl s_client  to gnutls-serv --echo:

openssl s_client ....

RENEGOTIATING
140361428772520:error:140940F5:SSL routines:SSL3_READ_BYTES:unexpected
record:s3_pkt.c:1393:

So do you know why is this happening ? Is it expected ?

And I wonder if it is possible to serve large content-length with
gnutls-serv --http ?

Thanks,
-- 
Alexandre Bique



From nmav at gnutls.org  Thu Apr 19 15:43:52 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 19 Apr 2012 15:43:52 +0200
Subject: bug in 3.0.18: gnutls-cli fails to transfer data to gnutls-serv
	--echo
In-Reply-To: <CAP737oJFE84z=Ewx386ns4qQ+cP-9FzzCeVOzhpQ_16yhKSfkg@mail.gmail.com>
References: <4F8F2CC0.6070507@gmail.com> <4F8FB97B.8000106@gnutls.org>
	<CAP737oJFE84z=Ewx386ns4qQ+cP-9FzzCeVOzhpQ_16yhKSfkg@mail.gmail.com>
Message-ID: <CAJU7zaJ-3gEZb+UW33t6EpUa_5acNC9oqQKi=Y3=MozsA7nCjQ@mail.gmail.com>

On Thu, Apr 19, 2012 at 11:42 AM, Alexandre Bique
<bique.alexandre at gmail.com> wrote:

>> Hello,
>> ?why you think this is a gnutls error? There are other web servers like
>> libmicrohttpd, nxweb or apache's mod_gnutls that as far as I know they
>> have no such issues with firefox or chromium.
> Yep I had a bug in my code, but for the firefox part, it look like you
> can take it down by sending an infinite text file over http, because
> it is keeping every thing in memory.

:)

>> What doesn't work? gnutls-serv is a test server and many things might
>> not work. However this seems unrelated to the above where you mention
>> incompatibility with chromium and firefox. Does gnutls-serv --http
>> work with the browsers you mention?
> I'm digging and you may be right, but I still have an error when
> "cating" a file through openssl s_client ?to gnutls-serv --echo:
> openssl s_client ....
> RENEGOTIATING
> 140361428772520:error:140940F5:SSL routines:SSL3_READ_BYTES:unexpected
> record:s3_pkt.c:1393:

I see a renegotiation request there and gnutls-serv doesn't do that,
so it might be that.
I'll have to check though.  Which was the command you used in openssl
and which openssl
version?

> And I wonder if it is possible to serve large content-length with
> gnutls-serv --http ?

No. It is really a test application. You might want to check one of
the small web servers
using gnutls instead.

regards,
Nikos



From bique.alexandre at gmail.com  Thu Apr 19 16:00:28 2012
From: bique.alexandre at gmail.com (Alexandre Bique)
Date: Thu, 19 Apr 2012 16:00:28 +0200
Subject: bug in 3.0.18: gnutls-cli fails to transfer data to gnutls-serv
	--echo
In-Reply-To: <CAJU7zaJ-3gEZb+UW33t6EpUa_5acNC9oqQKi=Y3=MozsA7nCjQ@mail.gmail.com>
References: <4F8F2CC0.6070507@gmail.com> <4F8FB97B.8000106@gnutls.org>
	<CAP737oJFE84z=Ewx386ns4qQ+cP-9FzzCeVOzhpQ_16yhKSfkg@mail.gmail.com>
	<CAJU7zaJ-3gEZb+UW33t6EpUa_5acNC9oqQKi=Y3=MozsA7nCjQ@mail.gmail.com>
Message-ID: <CAP737o+hZzUPbJ6TL5_dk4m2PiTM6Oy=pm9pk2k8MPRkghynXw@mail.gmail.com>

On Thu, Apr 19, 2012 at 15:43, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> On Thu, Apr 19, 2012 at 11:42 AM, Alexandre Bique
> <bique.alexandre at gmail.com> wrote:
>
>>> Hello,
>>> ?why you think this is a gnutls error? There are other web servers like
>>> libmicrohttpd, nxweb or apache's mod_gnutls that as far as I know they
>>> have no such issues with firefox or chromium.
>> Yep I had a bug in my code, but for the firefox part, it look like you
>> can take it down by sending an infinite text file over http, because
>> it is keeping every thing in memory.
>
> :)
>
>>> What doesn't work? gnutls-serv is a test server and many things might
>>> not work. However this seems unrelated to the above where you mention
>>> incompatibility with chromium and firefox. Does gnutls-serv --http
>>> work with the browsers you mention?
>> I'm digging and you may be right, but I still have an error when
>> "cating" a file through openssl s_client ?to gnutls-serv --echo:
>> openssl s_client ....
>> RENEGOTIATING
>> 140361428772520:error:140940F5:SSL routines:SSL3_READ_BYTES:unexpected
>> record:s3_pkt.c:1393:
>
> I see a renegotiation request there and gnutls-serv doesn't do that,
> so it might be that.

So in production code, do I have to check gnutls_record_{send,recv}
return value to manually start a renegotiation or re-handshake?

Could we add renegotiation to gnutls-serv?

> I'll have to check though. ?Which was the command you used in openssl
> and which openssl
> version?

I used openssl-1.0.1-3 from archlinux (x86_64).

The openssl command:
openssl s_client -connect 0.0.0.0:4242 <test-file

With test-file being a large file, generated with ``cat
/usr/include/*.h >test-file''.

>> And I wonder if it is possible to serve large content-length with
>> gnutls-serv --http ?
>
> No. It is really a test application. You might want to check one of
> the small web servers
> using gnutls instead.

OK.

Regards,
-- 
Alexandre Bique



From nmav at gnutls.org  Thu Apr 19 17:29:22 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 19 Apr 2012 17:29:22 +0200
Subject: [gnu-prog-discuss] lzip vs. xz
In-Reply-To: <87k41b6bz0.fsf@gnu.org>
References: <87y5qijhan.fsf@rho.meyering.net>
	<jwvsjgm3rfq.fsf-monnier+INBOX@gnu.org>
	<CAJuRt+rYvL+Xx3FrCWOUwgz3vmr6pR+osOO+1Atx9h4_VWOjgw@mail.gmail.com>
	<jwvk41xyggd.fsf-monnier+INBOX@gnu.org>
	<4F7A453A.5050106@teleline.es>
	<jwv398lxxb1.fsf-monnier+INBOX@gnu.org>
	<E1SEvkL-00054A-Ri@fencepost.gnu.org>
	<CADCnXoax8jM6OuMghaewA73APAihnc_kYMbiw1b7AikWcTh9VQ@mail.gmail.com>
	<CAJuRt+qMbMj1mb9soHY2E7z75EgYk4GJduqeqC2TGDmB0WYONA@mail.gmail.com>
	<E1SF8Mx-0001bC-Ns@fencepost.gnu.org>
	<4F7B6D6F.1060202@teleline.es>
	<jwvvclgzbsb.fsf-monnier+INBOX@gnu.org>
	<4F7C8B43.4070108@teleline.es>
	<jwvy5qbmjzv.fsf-monnier+INBOX@gnu.org> <87pqbnnxmc.fsf@gnu.org>
	<4F7DCCFB.5010108@teleline.es> <87aa2cm45g.fsf@latte.josefsson.org>
	<4F8C2A15.3050100@teleline.es> <4F8C43A8.9060003@gmail.com>
	<87aa283byg.fsf@gnu.org> <4F8FB698.7070403@gnutls.org>
	<87k41b6bz0.fsf@gnu.org>
Message-ID: <CAJU7zaJUM+wboLH6Q0XpSZ01JJE4qye-ifcp1-zQXa4A-_RJ8Q@mail.gmail.com>

On Thu, Apr 19, 2012 at 4:19 PM, Ludovic Court?s <ludo at gnu.org> wrote:

>>>> The other was that the code was GPLv2-only
>>> It?s no longer the case.
>> But still it is GPLv2 and gnutls is LGPL.
> In the past GnuTLS-Extra existed precisely for this situation.

Yes, but it no longer exists and I don't think it is a good idea to
move back to the dual library approach. Since faster algorithms than
LZO exist with more suitable licenses we might consider adding one of
those. (it's better if we move this to gnutls-devel)

regards,
Nikos



From nmav at gnutls.org  Thu Apr 19 17:34:39 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 19 Apr 2012 17:34:39 +0200
Subject: bug in 3.0.18: gnutls-cli fails to transfer data to gnutls-serv
	--echo
In-Reply-To: <CAP737o+hZzUPbJ6TL5_dk4m2PiTM6Oy=pm9pk2k8MPRkghynXw@mail.gmail.com>
References: <4F8F2CC0.6070507@gmail.com> <4F8FB97B.8000106@gnutls.org>
	<CAP737oJFE84z=Ewx386ns4qQ+cP-9FzzCeVOzhpQ_16yhKSfkg@mail.gmail.com>
	<CAJU7zaJ-3gEZb+UW33t6EpUa_5acNC9oqQKi=Y3=MozsA7nCjQ@mail.gmail.com>
	<CAP737o+hZzUPbJ6TL5_dk4m2PiTM6Oy=pm9pk2k8MPRkghynXw@mail.gmail.com>
Message-ID: <CAJU7zaLWskDEvaCNWW1S5Q9m3tVFM2hyYcxFKPTLrhbZ7POdFQ@mail.gmail.com>

On Thu, Apr 19, 2012 at 4:00 PM, Alexandre Bique
<bique.alexandre at gmail.com> wrote:

>> I see a renegotiation request there and gnutls-serv doesn't do that,
>> so it might be that.
> So in production code, do I have to check gnutls_record_{send,recv}
> return value to manually start a renegotiation or re-handshake?

It depends on what you want to do. A server isn't obliged to renegotiate
just because the client asked. I don't know why openssl s_client asked
for renegotiation in your example.

> Could we add renegotiation to gnutls-serv?

Now that I check it, it does support renegotiation. I cannot check the
issue soon, but you can check the debugging output of gnutls-serv
using -d 9 or so.

regards,
Nikos



From bique.alexandre at gmail.com  Thu Apr 19 18:01:58 2012
From: bique.alexandre at gmail.com (Alexandre Bique)
Date: Thu, 19 Apr 2012 18:01:58 +0200
Subject: bug in 3.0.18: gnutls-cli fails to transfer data to gnutls-serv
	--echo
In-Reply-To: <CAJU7zaLWskDEvaCNWW1S5Q9m3tVFM2hyYcxFKPTLrhbZ7POdFQ@mail.gmail.com>
References: <4F8F2CC0.6070507@gmail.com> <4F8FB97B.8000106@gnutls.org>
	<CAP737oJFE84z=Ewx386ns4qQ+cP-9FzzCeVOzhpQ_16yhKSfkg@mail.gmail.com>
	<CAJU7zaJ-3gEZb+UW33t6EpUa_5acNC9oqQKi=Y3=MozsA7nCjQ@mail.gmail.com>
	<CAP737o+hZzUPbJ6TL5_dk4m2PiTM6Oy=pm9pk2k8MPRkghynXw@mail.gmail.com>
	<CAJU7zaLWskDEvaCNWW1S5Q9m3tVFM2hyYcxFKPTLrhbZ7POdFQ@mail.gmail.com>
Message-ID: <CAP737oKJ_G8N6mGiDcf77n+w1CovmapKb43rqo49zee4gg7DiQ@mail.gmail.com>

On Thu, Apr 19, 2012 at 17:34, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> On Thu, Apr 19, 2012 at 4:00 PM, Alexandre Bique
> <bique.alexandre at gmail.com> wrote:
>
>>> I see a renegotiation request there and gnutls-serv doesn't do that,
>>> so it might be that.
>> So in production code, do I have to check gnutls_record_{send,recv}
>> return value to manually start a renegotiation or re-handshake?
>
> It depends on what you want to do. A server isn't obliged to renegotiate
> just because the client asked. I don't know why openssl s_client asked
> for renegotiation in your example.

Ok.

>> Could we add renegotiation to gnutls-serv?
>
> Now that I check it, it does support renegotiation. I cannot check the
> issue soon, but you can check the debugging output of gnutls-serv
> using -d 9 or so.

Here the last line on stderr:

|<2>| ASSERT: gnutls_record.c:366
Error while sending data
|<4>| REC[0x121ae30]: SSL 3.2 Application Data packet received. Epoch
0, length: 8240
|<4>| REC[0x121ae30]: Expected Packet Application Data(23)
|<4>| REC[0x121ae30]: Received Packet Application Data(23) with length: 8240
|<2>| ASSERT: gnutls_buffers.c:494
|<2>| ASSERT: gnutls_record.c:1002
|<2>| ASSERT: gnutls_record.c:1204
|<4>| REC[0x121ae30]: SSL 3.2 Application Data packet received. Epoch
0, length: 8240
|<4>| REC[0x121ae30]: Expected Packet Application Data(23)
|<4>| REC[0x121ae30]: Received Packet Application Data(23) with length: 8240
|<2>| ASSERT: gnutls_buffers.c:482
|<2>| ASSERT: gnutls_record.c:1002
|<2>| ASSERT: gnutls_record.c:1204
|<2>| errno: 32
|<2>| ASSERT: gnutls_buffers.c:374
|<2>| ASSERT: gnutls_buffers.c:599
|<2>| ASSERT: gnutls_record.c:201
|<4>| REC[0x121ae30]: Start of epoch cleanup
|<4>| REC[0x121ae30]: End of epoch cleanup
|<4>| REC[0x121ae30]: Epoch #1 freed

And on stdout I got:

Error: The specified session has been invalidated for some reason.
Error: The specified session has been invalidated for some reason.
Error: The specified session has been invalidated for some reason.
Error: The specified session has been invalidated for some reason.
Error: The specified session has been invalidated for some reason.
Error: The specified session has been invalidated for some reason.
Error: The specified session has been invalidated for some reason.
Error: The specified session has been invalidated for some reason.
Error: The specified session has been invalidated for some reason.
Error: The specified session has been invalidated for some reason.
Error: The specified session has been invalidated for some reason.
Error: The specified session has been invalidated for some reason.
Error: The specified session has been invalidated for some reason.
Error: The specified session has been invalidated for some reason.
Error: The specified session has been invalidated for some reason.
Error: The specified session has been invalidated for some reason.
...

-- 
Alexandre Bique



From nmav at gnutls.org  Thu Apr 19 18:02:22 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 19 Apr 2012 18:02:22 +0200
Subject: bug in 3.0.18: gnutls-cli fails to transfer data to gnutls-serv
	--echo
In-Reply-To: <4F8F2CC0.6070507@gmail.com>
References: <4F8F2CC0.6070507@gmail.com>
Message-ID: <4F90370E.1020707@gnutls.org>

On 04/18/2012 11:06 PM, Alexandre Bique wrote:

> - start a gnutls echo server: gnutls-serv --x509keyfile=key.pem
> --x509certfile=cert.pem -p 4242 --disable-client-cert --nodb --generate
> --echo
> 
> - start a client, and copy a big file: cat /usr/include/*.h >test-file;
> gnutls-cli --insecure 0.0.0.0 -p 4242 <test-file
> 
> Then it doesn't work :^)
> You can also test with an openssl client (it will fail as well): openssl
> s_client -connect 0.0.0.0:4242 <test-file


Ok it seems it is an issue in s_client of openssl. After it transmits
some number of data it requests a rehandshake (renegotiation). It does
that by sending a client hello. If the next message it receives is
application data then it does issue the error you see. So it is no
error to worry about, just a bug in s_client.

regards,
Nikos



From bique.alexandre at gmail.com  Thu Apr 19 18:04:18 2012
From: bique.alexandre at gmail.com (Alexandre Bique)
Date: Thu, 19 Apr 2012 18:04:18 +0200
Subject: bug in 3.0.18: gnutls-cli fails to transfer data to gnutls-serv
	--echo
In-Reply-To: <4F90370E.1020707@gnutls.org>
References: <4F8F2CC0.6070507@gmail.com> <4F90370E.1020707@gnutls.org>
Message-ID: <CAP737oJ-LqqGyg5hZT1muYORRwn_8ZVLQq9_raEg_Q+zj8i3oA@mail.gmail.com>

On Thu, Apr 19, 2012 at 18:02, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> On 04/18/2012 11:06 PM, Alexandre Bique wrote:
>
>> - start a gnutls echo server: gnutls-serv --x509keyfile=key.pem
>> --x509certfile=cert.pem -p 4242 --disable-client-cert --nodb --generate
>> --echo
>>
>> - start a client, and copy a big file: cat /usr/include/*.h >test-file;
>> gnutls-cli --insecure 0.0.0.0 -p 4242 <test-file
>>
>> Then it doesn't work :^)
>> You can also test with an openssl client (it will fail as well): openssl
>> s_client -connect 0.0.0.0:4242 <test-file
>
>
> Ok it seems it is an issue in s_client of openssl. After it transmits
> some number of data it requests a rehandshake (renegotiation). It does
> that by sending a client hello. If the next message it receives is
> application data then it does issue the error you see. So it is no
> error to worry about, just a bug in s_client.

Thanks a lot Nikos!

Is it worth to tell the OpenSSL guys?

Regards,
-- 
Alexandre Bique



From nmav at gnutls.org  Thu Apr 19 18:06:05 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 19 Apr 2012 18:06:05 +0200
Subject: bug in 3.0.18: gnutls-cli fails to transfer data to gnutls-serv
	--echo
In-Reply-To: <CAP737oJ-LqqGyg5hZT1muYORRwn_8ZVLQq9_raEg_Q+zj8i3oA@mail.gmail.com>
References: <4F8F2CC0.6070507@gmail.com> <4F90370E.1020707@gnutls.org>
	<CAP737oJ-LqqGyg5hZT1muYORRwn_8ZVLQq9_raEg_Q+zj8i3oA@mail.gmail.com>
Message-ID: <4F9037ED.5020205@gnutls.org>

On 04/19/2012 06:04 PM, Alexandre Bique wrote:

>>> Then it doesn't work :^)
>>> You can also test with an openssl client (it will fail as well): openssl
>>> s_client -connect 0.0.0.0:4242 <test-file
>> Ok it seems it is an issue in s_client of openssl. After it transmits
>> some number of data it requests a rehandshake (renegotiation). It does
>> that by sending a client hello. If the next message it receives is
>> application data then it does issue the error you see. So it is no
>> error to worry about, just a bug in s_client.
> Thanks a lot Nikos!
> Is it worth to tell the OpenSSL guys?


I don't know, but I'd report it.

regards,
Nikos



From ludo at gnu.org  Thu Apr 19 23:18:52 2012
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Thu, 19 Apr 2012 23:18:52 +0200
Subject: [gnu-prog-discuss] lzip vs. xz
In-Reply-To: <CAJU7zaJUM+wboLH6Q0XpSZ01JJE4qye-ifcp1-zQXa4A-_RJ8Q@mail.gmail.com>
	(Nikos Mavrogiannopoulos's message of "Thu, 19 Apr 2012 17:29:22
	+0200")
References: <87y5qijhan.fsf@rho.meyering.net>
	<jwvk41xyggd.fsf-monnier+INBOX@gnu.org> <4F7A453A.5050106@teleline.es>
	<jwv398lxxb1.fsf-monnier+INBOX@gnu.org>
	<E1SEvkL-00054A-Ri@fencepost.gnu.org>
	<CADCnXoax8jM6OuMghaewA73APAihnc_kYMbiw1b7AikWcTh9VQ@mail.gmail.com>
	<CAJuRt+qMbMj1mb9soHY2E7z75EgYk4GJduqeqC2TGDmB0WYONA@mail.gmail.com>
	<E1SF8Mx-0001bC-Ns@fencepost.gnu.org> <4F7B6D6F.1060202@teleline.es>
	<jwvvclgzbsb.fsf-monnier+INBOX@gnu.org> <4F7C8B43.4070108@teleline.es>
	<jwvy5qbmjzv.fsf-monnier+INBOX@gnu.org> <87pqbnnxmc.fsf@gnu.org>
	<4F7DCCFB.5010108@teleline.es> <87aa2cm45g.fsf@latte.josefsson.org>
	<4F8C2A15.3050100@teleline.es> <4F8C43A8.9060003@gmail.com>
	<87aa283byg.fsf@gnu.org> <4F8FB698.7070403@gnutls.org>
	<87k41b6bz0.fsf@gnu.org>
	<CAJU7zaJUM+wboLH6Q0XpSZ01JJE4qye-ifcp1-zQXa4A-_RJ8Q@mail.gmail.com>
Message-ID: <87pqb3s9mr.fsf@gnu.org>

Hi Nikos,

Nikos Mavrogiannopoulos <nmav at gnutls.org> skribis:

> On Thu, Apr 19, 2012 at 4:19 PM, Ludovic Court?s <ludo at gnu.org> wrote:
>
>>>>> The other was that the code was GPLv2-only
>>>> It?s no longer the case.
>>> But still it is GPLv2 and gnutls is LGPL.
>> In the past GnuTLS-Extra existed precisely for this situation.
>
> Yes, but it no longer exists and I don't think it is a good idea to
> move back to the dual library approach. Since faster algorithms than
> LZO exist with more suitable licenses we might consider adding one of
> those.

What compressor do you have in mind?  I guess the main criterion here is
latency.

FWIW, I find GPLv2+ perfectly suitable.  When a feature gives a package
an advantage, it may be a good strategy to use GPL instead of LGPL, as
discussed in <http://www.gnu.org/licenses/why-not-lgpl.html>.

Thanks,
Ludo?.



From nmav at gnutls.org  Fri Apr 20 09:38:08 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 20 Apr 2012 09:38:08 +0200
Subject: [gnu-prog-discuss] lzip vs. xz
In-Reply-To: <87pqb3s9mr.fsf@gnu.org>
References: <87y5qijhan.fsf@rho.meyering.net>
	<jwvk41xyggd.fsf-monnier+INBOX@gnu.org>
	<4F7A453A.5050106@teleline.es>
	<jwv398lxxb1.fsf-monnier+INBOX@gnu.org>
	<E1SEvkL-00054A-Ri@fencepost.gnu.org>
	<CADCnXoax8jM6OuMghaewA73APAihnc_kYMbiw1b7AikWcTh9VQ@mail.gmail.com>
	<CAJuRt+qMbMj1mb9soHY2E7z75EgYk4GJduqeqC2TGDmB0WYONA@mail.gmail.com>
	<E1SF8Mx-0001bC-Ns@fencepost.gnu.org>
	<4F7B6D6F.1060202@teleline.es>
	<jwvvclgzbsb.fsf-monnier+INBOX@gnu.org>
	<4F7C8B43.4070108@teleline.es>
	<jwvy5qbmjzv.fsf-monnier+INBOX@gnu.org>
	<87pqbnnxmc.fsf@gnu.org> <4F7DCCFB.5010108@teleline.es>
	<87aa2cm45g.fsf@latte.josefsson.org>
	<4F8C2A15.3050100@teleline.es> <4F8C43A8.9060003@gmail.com>
	<87aa283byg.fsf@gnu.org> <4F8FB698.7070403@gnutls.org>
	<87k41b6bz0.fsf@gnu.org>
	<CAJU7zaJUM+wboLH6Q0XpSZ01JJE4qye-ifcp1-zQXa4A-_RJ8Q@mail.gmail.com>
	<87pqb3s9mr.fsf@gnu.org>
Message-ID: <4F911260.4000104@gnutls.org>

On 04/19/2012 11:18 PM, Ludovic Court?s wrote:


>>>>>> The other was that the code was GPLv2-only
>>>>> It?s no longer the case.
>>>> But still it is GPLv2 and gnutls is LGPL.
>>> In the past GnuTLS-Extra existed precisely for this situation.
>>
>> Yes, but it no longer exists and I don't think it is a good idea to
>> move back to the dual library approach. Since faster algorithms than
>> LZO exist with more suitable licenses we might consider adding one of
>> those.
> 
> What compressor do you have in mind?  I guess the main criterion here is
> latency.


LZ4, at http://code.google.com/p/lz4/, although I have not tested it
a all, I'd be interested to see its interaction with TLS. The code looks
x86-centric though.

> FWIW, I find GPLv2+ perfectly suitable.  When a feature gives a package
> an advantage, it may be a good strategy to use GPL instead of LGPL, as
> discussed in <http://www.gnu.org/licenses/why-not-lgpl.html>.


This is a nice idea but I don't think it is applicable in this case
because there are quite a few non-gplv2 compressors. Moreover the
overhead of maintaining two libraries isn't worth it in my opinion.

regards,
Nikos



From code at funwithsoftware.org  Sat Apr 21 06:13:26 2012
From: code at funwithsoftware.org (Patrick Pelletier)
Date: Fri, 20 Apr 2012 21:13:26 -0700
Subject: fast compressors for TLS (was lzip vs. xz)
In-Reply-To: <mailman.166.1334937633.10285.gnutls-devel@gnu.org>
References: <mailman.166.1334937633.10285.gnutls-devel@gnu.org>
Message-ID: <C525E811-1597-435B-8E2D-82182D297102@funwithsoftware.org>

nmav at gnutls.org wrote:

> LZ4, at http://code.google.com/p/lz4/, although I have not tested it
> a all, I'd be interested to see its interaction with TLS. The code  
> looks
> x86-centric though.

Snappy is another possible option.  (Although at least according to  
the lz4 benchmarks, snappy doesn't perform quite as well as lz4.)  I  
mention it because a co-worker of mine is using snappy to compress  
some real-time data between two machines on the same LAN, and he seems  
very happy with it.

https://code.google.com/p/snappy/

The license should be compatible, although Snappy might not be a good  
fit for gnutls, because Snappy is written in C++.  The Snappy page  
links to an independent Snappy implementation in C, but I can't speak  
for that one; my coworker is using the C++ version.

https://github.com/andikleen/snappy-c

I'm afraid I missed the beginning of the conversation.  Are you guys  
planning on standardizing this new compression method in an RFC?  (i.  
e. in the 0-63 "standards action" or 64-223 "specification required"  
compression methods)  Or is this just going to be in the "private use"  
area (224-255), only for when one gnutls instance is talking to  
another gnutls instance?  It would be nice to have a standardized,  
fast compression method implemented by more than one TLS library.   
(Compression seems to be rarely used in TLS; I assume because people  
feel zlib is too slow.)

--Patrick

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20120420/97957e3b/attachment.htm>

From nmav at gnutls.org  Sat Apr 21 11:55:56 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 21 Apr 2012 11:55:56 +0200
Subject: fast compressors for TLS (was lzip vs. xz)
In-Reply-To: <C525E811-1597-435B-8E2D-82182D297102@funwithsoftware.org>
References: <mailman.166.1334937633.10285.gnutls-devel@gnu.org>
	<C525E811-1597-435B-8E2D-82182D297102@funwithsoftware.org>
Message-ID: <CAJU7zaLaWD95UigGXbN0ZJhNU0wY9baQfg9-qmSbYDfWJFrvjA@mail.gmail.com>

On Sat, Apr 21, 2012 at 6:13 AM, Patrick Pelletier
<code at funwithsoftware.org> wrote:

> Snappy is another possible option. ?(Although at least according to the lz4
> benchmarks, snappy doesn't perform quite as well as lz4.) ?I mention it
> because a co-worker of mine is using snappy to compress some real-time data
> between two machines on the same LAN, and he seems very happy with it.

I don't really plan to work on it soon (but will accept any patches of
course), but
indeed all available options should be evaluated.

> I'm afraid I missed the beginning of the conversation. ?Are you guys
> planning on standardizing this new compression method in an RFC? ?(i. e. in
> the 0-63 "standards action" or 64-223 "specification required" compression
> methods) ?Or is this just going to be in the "private use" area (224-255),

Not really but close. But were considering whether there are fast compression
algorithms decently described that could at some point be
standardized. That is, to
avoid sticking with non-standard extensions.

> only for when one gnutls instance is talking to another gnutls instance? ?It
> would be nice to have a standardized, fast compression method implemented by
> more than one TLS library. ?(Compression seems to be rarely used in TLS; I
> assume because people feel zlib is too slow.)

zlib is pretty slow in TLS according to some benchmarks I did (long
time ago). Having a low-latency compression
algorithm there might change that.


regards,
Nikos



From code at funwithsoftware.org  Sun Apr 22 00:53:32 2012
From: code at funwithsoftware.org (Patrick Pelletier)
Date: Sat, 21 Apr 2012 15:53:32 -0700
Subject: patch: some more documentation fixes
Message-ID: <C5427194-6FEB-430D-A748-DE81591CF02B@funwithsoftware.org>

Here is a commit with some various documentation and comment  
nitpicks.  I've attached the output of "git format-patch" as an  
attachment to this message; I think that worked successfully the last  
time I submitted one of these.

--Patrick

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-documentation-and-comment-fixes.patch
Type: application/octet-stream
Size: 8893 bytes
Desc: not available
URL: </pipermail/attachments/20120421/47d87704/attachment.obj>
-------------- next part --------------


From nmav at gnutls.org  Sun Apr 22 17:21:22 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 22 Apr 2012 17:21:22 +0200
Subject: gnutls 3.0.19
Message-ID: <4F9421F2.3060106@gnutls.org>

Hello,
 I've just released gnutls 3.0.19. This is a bug-fix release on the
current stable branch.


* Version 3.0.19 (released 2012-04-22)

** libgnutls: When decoding a PKCS #11 URL the pin-source field
is assumed to be a file that stores the pin. Based on patch
by David Smith.

** libgnutls: gnutls_record_check_pending() no longer
returns unprocessed data, and thus ensure the non-blocking
of the next call to gnutls_record_recv().

** libgnutls: Added strict tests in Diffie-Hellman and
SRP key exchange public keys.

** libgnutls: in ECDSA and DSA TLS 1.2 authentication be less
strict in hash selection, and allow a stronger hash to
be used than the appropriate, to improve interoperability
with openssl.

** tests: Disabled floating point test, and corrections
in pkcs12 decoding tests.

** API and ABI modifications:
No changes since last version.


Getting the Software
====================

GnuTLS may be downloaded from one of the GNU mirror sites or directly
>From <ftp://ftp.gnu.org/gnu/gnutls/>.  The list of GNU mirrors can be
found at <http://www.gnu.org/prep/ftp.html> and a list of GnuTLS mirrors
can be found at <http://www.gnu.org/software/gnutls/download.html>.

Here are the XZ compressed sources:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.19.tar.xz
  http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.19.tar.xz
  ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.19.tar.xz

Here are the LZIP compressed sources:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.19.tar.lz
  http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.19.tar.lz
  ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.19.tar.lz

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.19.tar.xz.sig
  http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.19.tar.xz.sig
  ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.19.tar.xz.sig

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.19.tar.lz.sig
  http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.19.tar.lz.sig
  ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.19.tar.lz.sig

Note that it has been signed with my openpgp key:
pub   3104R/96865171 2008-05-04 [expires: 2028-04-29]
uid                  Nikos Mavrogiannopoulos <nmav <at> gnutls.org>
uid                  Nikos Mavrogiannopoulos <n.mavrogiannopoulos <at>
gmail.com>
sub   2048R/9013B842 2008-05-04 [expires: 2018-05-02]
sub   2048R/1404A91D 2008-05-04 [expires: 2018-05-02]

regards,
Nikos



From nmav at gnutls.org  Sun Apr 22 17:26:39 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 22 Apr 2012 17:26:39 +0200
Subject: patch: some more documentation fixes
In-Reply-To: <C5427194-6FEB-430D-A748-DE81591CF02B@funwithsoftware.org>
References: <C5427194-6FEB-430D-A748-DE81591CF02B@funwithsoftware.org>
Message-ID: <4F94232F.3030704@gnutls.org>

On 04/22/2012 12:53 AM, Patrick Pelletier wrote:

> Here is a commit with some various documentation and comment nitpicks. 
> I've attached the output of "git format-patch" as an attachment to this
> message; I think that worked successfully the last time I submitted one
> of these.


Applied thank you!





From ludo at gnu.org  Mon Apr 23 00:42:37 2012
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Mon, 23 Apr 2012 00:42:37 +0200
Subject: Incompatibilities between 3.0.8 and 3.0.18
Message-ID: <87mx63o0bm.fsf@gnu.org>

Hello,

While upgrading libchop from GnuTLS 3.0.8 to 3.0.18, I noticed a few
quirks.

First, compat.h lacks:

    typedef gnutls_openpgp_crt_fmt_t gnutls_openpgp_key_fmt_t
      _GNUTLS_GCC_ATTR_DEPRECATED;

Second, when using OpenPGP mutual authentication,
?gnutls_certificate_get_peers? (when called on the server side) now
returns a raw certificate, whereas it previously returned a base64
certificate.

This is in agreement with the doc of that function (dated 2008), but
different from what 3.0.8 and earlier did.

I couldn?t find it in NEWS, nor did I find the commit that changes this,
so I thought it may be worth raising it here.

Thanks,
Ludo?.



From nmav at gnutls.org  Mon Apr 23 08:48:37 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 23 Apr 2012 08:48:37 +0200
Subject: Incompatibilities between 3.0.8 and 3.0.18
In-Reply-To: <87mx63o0bm.fsf@gnu.org>
References: <87mx63o0bm.fsf@gnu.org>
Message-ID: <4F94FB45.4020607@gnutls.org>

On 04/23/2012 12:42 AM, Ludovic Court?s wrote:

> Hello,
> 
> While upgrading libchop from GnuTLS 3.0.8 to 3.0.18, I noticed a few
> quirks.
> 
> First, compat.h lacks:
> 
>     typedef gnutls_openpgp_crt_fmt_t gnutls_openpgp_key_fmt_t
>       _GNUTLS_GCC_ATTR_DEPRECATED;


Hi Ludovic,
 I've removed several typedefs to types that didn't exist today, but
this looks like a side-effect. Do you need it be revived?

> Second, when using OpenPGP mutual authentication,
> ?gnutls_certificate_get_peers? (when called on the server side) now
> returns a raw certificate, whereas it previously returned a base64
> certificate.


I don't think that this changed in gnutls. What did change in
3.0.10 is:

** libgnutls: When GNUTLS_OPENPGP_FMT_BASE64 is specified
the stream is assumed to be base64 encoded (previously
the encoding was auto-detected). This avoids a decoding
issue in windows systems.

Is the auto-detection the reason that you thought that this buffer
is base64?

Thanks for reporting these.
Nikos



From ludo at gnu.org  Mon Apr 23 16:16:09 2012
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Mon, 23 Apr 2012 16:16:09 +0200
Subject: Incompatibilities between 3.0.8 and 3.0.18
In-Reply-To: <4F94FB45.4020607@gnutls.org> (Nikos Mavrogiannopoulos's message
	of "Mon, 23 Apr 2012 08:48:37 +0200")
References: <87mx63o0bm.fsf@gnu.org> <4F94FB45.4020607@gnutls.org>
Message-ID: <871unesfdi.fsf@gnu.org>

Hi Nikos,

Nikos Mavrogiannopoulos <nmav at gnutls.org> skribis:

>  I've removed several typedefs to types that didn't exist today, but
> this looks like a side-effect. Do you need it be revived?

No, but I thought this was an omission in compat.h.

>> Second, when using OpenPGP mutual authentication,
>> ?gnutls_certificate_get_peers? (when called on the server side) now
>> returns a raw certificate, whereas it previously returned a base64
>> certificate.
>
>
> I don't think that this changed in gnutls. What did change in
> 3.0.10 is:
>
> ** libgnutls: When GNUTLS_OPENPGP_FMT_BASE64 is specified
> the stream is assumed to be base64 encoded (previously
> the encoding was auto-detected). This avoids a decoding
> issue in windows systems.
>
> Is the auto-detection the reason that you thought that this buffer
> is base64?

Aaah, probably then.

Thanks for the info!

Ludo?.



From INVALID.NOREPLY at gnu.org  Wed Apr 25 05:25:56 2012
From: INVALID.NOREPLY at gnu.org (Mann Ern Kang)
Date: Wed, 25 Apr 2012 03:25:56 +0000
Subject: [sr #108037] gnutls_cpuid assembler code follows incorrect calling
	convention on Windows x64
Message-ID: <20120425-032556.sv87957.75875@savannah.gnu.org>

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

                 Summary: gnutls_cpuid assembler code follows incorrect
calling convention on Windows x64
                 Project: GnuTLS
            Submitted by: mannern
            Submitted on: Wed 25 Apr 2012 03:25:56 AM GMT
                Category: Core library
                Priority: 5 - Normal
                Severity: 3 - Normal
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
        Operating System: Microsoft Windows

    _______________________________________________________

Details:

The gnutls_cpuid function in file lib\accelerated\x86\coff\cpuid-x86-64-coff.s
follows the Linux parameter passing convention instead of the Windows x64 one,
resulting in a crash (access violation) if hardware acceleration is enabled on
a Windows x64 build of gnutls.

Attaching a patch. This is my first time submitting to gnutls so please let me
know if I missed out anything :)



    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Wed 25 Apr 2012 03:25:56 AM GMT  Name: cpuid-x86-64-coff.s  Size: 1kB  
By: mannern

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

    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Wed Apr 25 09:48:42 2012
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Wed, 25 Apr 2012 07:48:42 +0000
Subject: [sr #108037] gnutls_cpuid assembler code follows incorrect calling
	convention on Windows x64
In-Reply-To: <20120425-032556.sv87957.75875@savannah.gnu.org>
References: <20120425-032556.sv87957.75875@savannah.gnu.org>
Message-ID: <20120425-104842.sv707.56058@savannah.gnu.org>

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

Hello Mann,
 Thanks for the patch. This file is auto-generated from perlasm (the same as
used in openssl) at:
http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=blob;f=devel/perlasm/cpuid-x86_64.pl;hb=HEAD
If you could provide a patch for that file I'd be grateful. 

regards,
Nikos


    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Wed Apr 25 11:45:54 2012
From: INVALID.NOREPLY at gnu.org (Mann Ern Kang)
Date: Wed, 25 Apr 2012 09:45:54 +0000
Subject: [sr #108037] gnutls_cpuid assembler code follows incorrect calling
	convention on Windows x64
In-Reply-To: <20120425-104842.sv707.56058@savannah.gnu.org>
References: <20120425-032556.sv87957.75875@savannah.gnu.org>
	<20120425-104842.sv707.56058@savannah.gnu.org>
Message-ID: <20120425-174554.sv87957.73412@savannah.gnu.org>

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

Hi Nikos,

Attaching the modified cpuid-x86_64.pl file. It was just a problem with the
tag on the gnutls_cpuid function: it should have been @function instead of
@abi-omnipotent, to direct x86_64-xlate.pl to generate the appropriate
function prologue and epilogue for Windows.

Cheers,
Mann Ern

(file #25727)
    _______________________________________________________

Additional Item Attachment:

File name: cpuid-x86_64.pl                Size:1 KB


    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Wed Apr 25 12:04:15 2012
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Wed, 25 Apr 2012 10:04:15 +0000
Subject: [sr #108037] gnutls_cpuid assembler code follows incorrect calling
	convention on Windows x64
In-Reply-To: <20120425-174554.sv87957.73412@savannah.gnu.org>
References: <20120425-032556.sv87957.75875@savannah.gnu.org>
	<20120425-104842.sv707.56058@savannah.gnu.org>
	<20120425-174554.sv87957.73412@savannah.gnu.org>
Message-ID: <20120425-130415.sv707.91663@savannah.gnu.org>

Update of sr #108037 (project gnutls):

                  Status:                    None => Done                   
             Assigned to:                    None => nmav                   

    _______________________________________________________

Follow-up Comment #3:

Thank you applied.

    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Wed Apr 25 15:19:29 2012
From: INVALID.NOREPLY at gnu.org (=?UTF-8?B?QmrDuHJu?= Christensen)
Date: Wed, 25 Apr 2012 13:19:29 +0000
Subject: [sr #108038] version 3.0.18 for windows 64 bit crashes during
	initialisation.
Message-ID: <20120425-131929.sv79827.58125@savannah.gnu.org>

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

                 Summary: version 3.0.18 for windows 64 bit crashes during
initialisation.   
                 Project: GnuTLS
            Submitted by: cybear
            Submitted on: Wed 25 Apr 2012 13:19:29 GMT
                Category: Extra library
                Priority: 5 - Normal
                Severity: 3 - Normal
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
        Operating System: Microsoft Windows

    _______________________________________________________

Details:

I have build gnutls version 3.0.18 using nettle version 2.4 and when I call
gnutls_global_init() it calls _gnutls_rnd_init()  and deep down in
--nettle_aes_encrypt() in file aes-encrypt-internal.s:123 I get a segmentation
fault.

If I choose to build libnettle with the option --disable-assembler it works
fine.

I have no clue what is wrong but I am fairly sure it is the assembler code,
probably the calling convention.

I do not know if this is the right place to report this problem.





    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Wed Apr 25 16:40:24 2012
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Wed, 25 Apr 2012 14:40:24 +0000
Subject: [sr #108038] version 3.0.18 for windows 64 bit crashes during
	initialisation.
In-Reply-To: <20120425-131929.sv79827.58125@savannah.gnu.org>
References: <20120425-131929.sv79827.58125@savannah.gnu.org>
Message-ID: <20120425-174024.sv707.4986@savannah.gnu.org>

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

Hi, a fix was committed few hours ago. 
http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=2da36bd42cca5f54564ff617ccb410b5ea8ad050


    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Wed Apr 25 17:29:35 2012
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Wed, 25 Apr 2012 15:29:35 +0000
Subject: [sr #108038] version 3.0.18 for windows 64 bit crashes during
	initialisation.
In-Reply-To: <20120425-231906.sv87957.59163@savannah.gnu.org>
References: <20120425-131929.sv79827.58125@savannah.gnu.org>
	<20120425-174024.sv707.4986@savannah.gnu.org>
	<20120425-231906.sv87957.59163@savannah.gnu.org>
Message-ID: <20120425-182935.sv707.83989@savannah.gnu.org>

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

Ah, ok then. May I ask you to report it also to nettle?
http://www.lysator.liu.se/~nisse/nettle/


    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Wed Apr 25 17:19:06 2012
From: INVALID.NOREPLY at gnu.org (Mann Ern Kang)
Date: Wed, 25 Apr 2012 15:19:06 +0000
Subject: [sr #108038] version 3.0.18 for windows 64 bit crashes during
	initialisation.
In-Reply-To: <20120425-174024.sv707.4986@savannah.gnu.org>
References: <20120425-131929.sv79827.58125@savannah.gnu.org>
	<20120425-174024.sv707.4986@savannah.gnu.org>
Message-ID: <20120425-231906.sv87957.59163@savannah.gnu.org>

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

I believe this is a different issue. The fix mentioned only corrects the
parameter passing for the cpuid assembler code inside gnutls. 

I came across this issue while building nettle for Windows x64 earlier on.
This crash is actually due to the assembler code for aes inside nettle. The
RNG for gnutls uses yarrow from nettle, which in turn uses some aes functions
internally. Nettle has custom assembler code for aes, which after inspecting
the .asm files, appears to support only the Linux calling convention on x86_64
(based on nettle 2.4).

As such, this seems to be more of a nettle problem rather than a gnutls one.

Cheers,
Mann Ern

    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Thu Apr 26 02:51:29 2012
From: INVALID.NOREPLY at gnu.org (Mann Ern Kang)
Date: Thu, 26 Apr 2012 00:51:29 +0000
Subject: [sr #108038] version 3.0.18 for windows 64 bit crashes during
	initialisation.
In-Reply-To: <20120425-182935.sv707.83989@savannah.gnu.org>
References: <20120425-131929.sv79827.58125@savannah.gnu.org>
	<20120425-174024.sv707.4986@savannah.gnu.org>
	<20120425-231906.sv87957.59163@savannah.gnu.org>
	<20120425-182935.sv707.83989@savannah.gnu.org>
Message-ID: <20120426-085129.sv87957.94432@savannah.gnu.org>

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

Posted to the nettle-bugs mailing list.

    _______________________________________________________

Reply to this item at:

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

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




From dam at opencsw.org  Fri Apr 27 14:23:13 2012
From: dam at opencsw.org (Dagobert Michelsen)
Date: Fri, 27 Apr 2012 14:23:13 +0200
Subject: Problem with int types persists on nettle 2.4 and gnutls 3.0.19
	on Solaris 9 Sparc
In-Reply-To: <D7947BF2-D7D5-427D-A734-699E1227DF48@baltic-online.de>
References: <D7947BF2-D7D5-427D-A734-699E1227DF48@baltic-online.de>
Message-ID: <6F92CE78-7FBD-4792-A97E-D457886874A2@opencsw.org>

Hi Niels,

Am 05.05.2011 um 13:35 schrieb Dagobert Michelsen:
> I am trying to compile gnutls 2.12.3 with libnettle 2.1 and get the
> following errors. From the output I assume an incompatibility between
> different gnulib inclusions.
> 
> dam at testing9s :/home/dam/mgar/pkg/gnutls/trunk/work/solaris9-sparc/build-isa-sparcv8/gnutls-2.12.3/lib/nettle > gmake V=1
> \
> source='pk.c' object='pk.lo' libtool=yes \
> DEPDIR=.deps depmode=none /bin/bash ../build-aux/depcomp \
> /bin/bash ../libtool  --tag=CC   --mode=compile /opt/SUNWspro/bin/cc -DHAVE_CONFIG_H -I. -I..  -I./../gl -I./../gl -I./../includes -I./../includes -I./..  -I/opt/csw/include    -xO3 -m32 -xarch=v8 -c -o pk.lo pk.c
> libtool: compile:  /opt/SUNWspro/bin/cc -DHAVE_CONFIG_H -I. -I.. -I./../gl -I./../gl -I./../includes -I./../includes -I./.. -I/opt/csw/include -xO3 -m32 -xarch=v8 -c pk.c  -KPIC -DPIC -o .libs/pk.o
> "/opt/csw/include/nettle/nettle-stdint.h", line 237: identifier redeclared: gl_int_fast8_t
>        current : signed char
>        previous: long : "./../gl/stdint.h", line 241
> "/opt/csw/include/nettle/nettle-stdint.h", line 238: warning: modification of typedef with "int" ignored
> "/opt/csw/include/nettle/nettle-stdint.h", line 238: identifier redeclared: gl_int_fast16_t
>        current : int
>        previous: long : "./../gl/stdint.h", line 243
> "/opt/csw/include/nettle/nettle-stdint.h", line 239: warning: modification of typedef with "int" ignored
> "/opt/csw/include/nettle/nettle-stdint.h", line 239: identifier redeclared: gl_int_fast32_t
>        current : int
>        previous: long : "./../gl/stdint.h", line 245
> "/opt/csw/include/nettle/nettle-stdint.h", line 241: warning: typedef redeclared: int64_t
> "/opt/csw/include/nettle/nettle-stdint.h", line 244: identifier redeclared: gl_uint_fast8_t
>        current : unsigned char
>        previous: unsigned long : "./../gl/stdint.h", line 242
> "/opt/csw/include/nettle/nettle-stdint.h", line 245: identifier redeclared: gl_uint_fast16_t
>        current : unsigned int
>        previous: unsigned long : "./../gl/stdint.h", line 244
> "/opt/csw/include/nettle/nettle-stdint.h", line 246: identifier redeclared: gl_uint_fast32_t
>        current : unsigned int
>        previous: unsigned long : "./../gl/stdint.h", line 246
> "/opt/csw/include/nettle/nettle-stdint.h", line 248: warning: typedef redeclared: uint64_t
> cc: acomp failed for pk.c
> gmake: *** [pk.lo] Error 1
> zsh: 9813 exit 2     gmake V=1

I just verified that the problem persists with nettle 2.4 and gnutls-3.0.19. As you seem to have
access to the Solaris buildfarm it would be cool if you could finally fix this as it blocks
new releases of gnutls for the OpenCSW distribution.


Best regards

  -- Dago

-- 
"You don't become great by trying to be great, you become great by wanting to do something,
and then doing it so hard that you become great in the process." - xkcd #896




From nisse at lysator.liu.se  Fri Apr 27 14:54:48 2012
From: nisse at lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=)
Date: Fri, 27 Apr 2012 14:54:48 +0200
Subject: Problem with int types persists on nettle 2.4 and gnutls 3.0.19
	on Solaris 9 Sparc
In-Reply-To: <6F92CE78-7FBD-4792-A97E-D457886874A2@opencsw.org> (Dagobert
	Michelsen's message of "Fri, 27 Apr 2012 14:23:13 +0200")
References: <D7947BF2-D7D5-427D-A734-699E1227DF48@baltic-online.de>
	<6F92CE78-7FBD-4792-A97E-D457886874A2@opencsw.org>
Message-ID: <nnmx5xwd0n.fsf@stalhein.lysator.liu.se>

Dagobert Michelsen <dam at opencsw.org> writes:

> I just verified that the problem persists with nettle 2.4 and gnutls-3.0.19. As you seem to have
> access to the Solaris buildfarm it would be cool if you could finally fix this as it blocks
> new releases of gnutls for the OpenCSW distribution.

It's some time since I looked in to this. My understaning of the problem
is that

1. This Solaris version lack both <stdint.h> and <inttypes.h>. (A
   comment in AX_CREATE_STDINT_H seems to imply that it does have a
   <sys/inttypes.h>, should we use that?)

2. Nettle defines uint32_t and friends using the AX_CREATE_STDINT_H
   autoconf macro.

3. gnulib defines them in a different way.

4. The multiple definitions of, e.g., uint32_t, agree and are no
   problem.

5. The definitions of some other (unused) types are incompatible, e.g.,
   int_fast8_t, and cause the compilation errors.

6. The definitions from AX_CREATE_STDINT_H is compatible with the
   definitions of these types in Solaris 10. gnulib's definitions
   aren't, so any code using them can potentially break if linked
   together with code compiled on Solaris 10.

Hence I think it ought to be fixed in gnulib. Simon (and any other
gnulib people on these lists), do you agree?

To address (1), maybe you can try

diff --git a/configure.ac b/configure.ac
index 6bf2b8b..77bb9b1 100644
--- a/configure.ac
+++ b/configure.ac
@@ -518,7 +518,7 @@ LSH_GCC_ATTRIBUTES
 
 # According to Simon Josefsson, looking for uint32_t and friends in
 # sys/types.h is needed on some systems, in particular cygwin.
-AX_CREATE_STDINT_H([nettle-stdint.h], [sys/types.h])
+AX_CREATE_STDINT_H([nettle-stdint.h], [sys/types.h], [sys/inttypes.h])
 
 # Check for file locking. We (AC_PROG_CC?) have already checked for
 # sys/types.h and unistd.h.

but I suspect you would still get compilation errors due to incompatible
definitions in gnulib and sys/inttypes.h.

Maybe the easiest nettle workaround would be to somehow disable the
definitions of the problematic types, which we don't use anyway.

Could you try something like the following?

diff --git a/nettle-types.h b/nettle-types.h
index b694332..d0aa332 100644
--- a/nettle-types.h
+++ b/nettle-types.h
@@ -23,6 +23,9 @@
 #ifndef NETTLE_TYPES_H
 #define NETTLE_TYPES_H
 
+/* Pretend this type always exists. Nettle doesn't use it. */
+#define _STDINT_HAVE_INT_FAST32_T 1
+
 #include "nettle-stdint.h"
 
 #ifdef __cplusplus

Have a look into the generated nettle-stdint.h (or the template in
aclocal.m4) for other potentially useful defines.

The closest Solaris 5.8 box I used to have acccess to
(hanna.lysator.liu.se) seems to have been decomissioned.

Regardss,
/Niels

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



From simon at josefsson.org  Fri Apr 27 15:46:18 2012
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 27 Apr 2012 15:46:18 +0200
Subject: Problem with int types persists on nettle 2.4 and gnutls 3.0.19
	on Solaris 9 Sparc
In-Reply-To: <nnmx5xwd0n.fsf@stalhein.lysator.liu.se>
References: <D7947BF2-D7D5-427D-A734-699E1227DF48@baltic-online.de>
	<6F92CE78-7FBD-4792-A97E-D457886874A2@opencsw.org>
	<nnmx5xwd0n.fsf@stalhein.lysator.liu.se>
Message-ID: <1335534378.6649.2.camel@latte>

fre 2012-04-27 klockan 14:54 +0200 skrev Niels M?ller:
> Dagobert Michelsen <dam at opencsw.org> writes:
> 
> > I just verified that the problem persists with nettle 2.4 and gnutls-3.0.19. As you seem to have
> > access to the Solaris buildfarm it would be cool if you could finally fix this as it blocks
> > new releases of gnutls for the OpenCSW distribution.
> 
> It's some time since I looked in to this. My understaning of the problem
> is that
> 
> 1. This Solaris version lack both <stdint.h> and <inttypes.h>. (A
>    comment in AX_CREATE_STDINT_H seems to imply that it does have a
>    <sys/inttypes.h>, should we use that?)

Using system headers if available seems like a good idea.

> 2. Nettle defines uint32_t and friends using the AX_CREATE_STDINT_H
>    autoconf macro.
> 
> 3. gnulib defines them in a different way.

What is the difference?  This sounds bad.

> 5. The definitions of some other (unused) types are incompatible, e.g.,
>    int_fast8_t, and cause the compilation errors.

If they are unused, we could remove the definitions.

> 6. The definitions from AX_CREATE_STDINT_H is compatible with the
>    definitions of these types in Solaris 10. gnulib's definitions
>    aren't, so any code using them can potentially break if linked
>    together with code compiled on Solaris 10.
> 
> Hence I think it ought to be fixed in gnulib. Simon (and any other
> gnulib people on these lists), do you agree?

Yes.  Understanding what the differences is, and which one is right, seems useful first though.  If the problem is in gnulib, we can fix that and GnuTLS will have the new variant soon.

/Simon





From nisse at lysator.liu.se  Fri Apr 27 17:24:20 2012
From: nisse at lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=)
Date: Fri, 27 Apr 2012 17:24:20 +0200
Subject: Problem with int types persists on nettle 2.4 and gnutls 3.0.19
	on Solaris 9 Sparc
In-Reply-To: <1335534378.6649.2.camel@latte> (Simon Josefsson's message of
	"Fri, 27 Apr 2012 15:46:18 +0200")
References: <D7947BF2-D7D5-427D-A734-699E1227DF48@baltic-online.de>
	<6F92CE78-7FBD-4792-A97E-D457886874A2@opencsw.org>
	<nnmx5xwd0n.fsf@stalhein.lysator.liu.se>
	<1335534378.6649.2.camel@latte>
Message-ID: <nn62clw63f.fsf@stalhein.lysator.liu.se>

Simon Josefsson <simon at josefsson.org> writes:

> Yes. Understanding what the differences is, and which one is right,
> seems useful first though. If the problem is in gnulib, we can fix
> that and GnuTLS will have the new variant soon.

Quoting my investigation from an old (off-list) email thread, from
November last year:

  And the problem seems to be that inttypes.h doesn't define int_fast8_t
  types. And then AX_CREATE_STDINT_H (used by nettle) and gnulib (used by
  gnutls) both decide to define them, and they do that in an incompatible
  way.

---

  From a quick look at gl/stdint.h.in and on posted error messages, I
  think glib uses long for all of int_fast8_t, int_fast16_t and
  int_fast32_t, and int64_t for int_fast64_t, while nettle uses int8_t,
  int, int32_t and int64_t.

---

  >> Actually, one ought to have a look at the definitions in the stdint.h
  >> provided by gcc (and at the definitions in the solaris10 stdint.h), and
  >> make sure the definitions of the int_fast* types are equivalent.
  >> Otherwise one might end up with subtle ABI differences and errors when
  >> linking together code compiled by different compilers.
  >
  > Agreed.
  
  I did a quick check. The following seems to be the correct sizes:
  
  int_fast8_t: 1
  int_fast16_t: 4
  int_fast32_t: 4
  int_fast64_t: 8
  
  This is using sizeof on the types defined in stdint.h, trying:
  
  gcc -m32 on solaris 9
  gcc -m64 on solaris 9
  cc -m32 on solaris 10
  cc -m64 on solaris 10
  
  Remarkably enough, they all agree. I also get the same sizes from
  nettle-stdint.h, for both 32 bit and 64 bit configurations. So I think
  nettle (or really, AX_CREATE_STDINT_H) gets this right.
  
  While if I understand gl correctly, it uses 4,4,4,8 for a 32-bit build
  and 8,8,8,8 for a 64-bit build (the size of long is different). This
  seems wrong. Sure, these are perfectly ok sizes according to C99, but
  they differ from the sparc conventions (and possibly conventions for
  other architectures as well).

Regards,
/Niels

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



From fviscomi at gmail.com  Mon Apr 30 00:10:07 2012
From: fviscomi at gmail.com (Francesco Viscomi)
Date: Mon, 30 Apr 2012 00:10:07 +0200
Subject: help me pleasssse
Message-ID: <CABr7xBv3P5n3q4F0jTph32oZDvNDFZ6FS0TuQmOcvZFwPpCfeQ@mail.gmail.com>

Hi,
i'm trying to install GnuTLS but i'm going to get crazy.

in the directory*, where i download the package gnutls-3.0.8, i run
.***<bug-gnutls at gnu.org>
/configure
then
run make
and then
as root run make install

everything seems to goes well, but in the directory -usr/local/bin i not
find the script libgnutls-config


-- 
Ing. Viscomi Francesco
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20120430/9c554bcc/attachment.htm>