From juanpablougarte at gmail.com  Tue Apr  1 22:20:22 2008
From: juanpablougarte at gmail.com (Juan Pablo Ugarte)
Date: Tue, 01 Apr 2008 17:20:22 -0300
Subject: [Help-gnutls] Signature Verify functions
Message-ID: <1207081222.3270.17.camel@XjuanNB>

Hello guys.

I need a function to verify a little text using a public key.

Its for a GPL project, i only need to verify some text and I can not add
gnutls as a dependancy because its just for an easter egg :)

hehe, anyways i just want to implement something like this...

int
verify_sign (pubkey, text, sign);

Can anyone give me some pointers on wich files/functions should i "look"
to implement such function?

thanks a lot

Juan Pablo





From dkg-debian.org at fifthhorseman.net  Wed Apr  2 04:42:20 2008
From: dkg-debian.org at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 01 Apr 2008 22:42:20 -0400
Subject: [Help-gnutls] trouble with OpenPGP DSA MPI extraction and OpenPGP
	private subkeys
Message-ID: <87fxu5dlkj.fsf@squeak.fifthhorseman.net>

Hey GnuTLS folks--

The development branch of gnutls is looking really nice with 2.3.4.
It's got functionality that i've been looking for for a while, in
particular the capabilities for MPI extraction and transformation.

I've just been playing around with the openpgp functions, and ran into
a couple stumbling blocks.  I opened a ticket about each of them:

 * DSA MPI extraction fails: i get GNUTLS_E_OPENPGP_GETKEY_FAILED when
   calling gnutls_openpgp_privkey_export_dsa_raw():

      http://trac.gnutls.org/cgi-bin/trac.cgi/ticket/21

 * gnutls should be able to read OpenPGP secret-subkey packets the
   same way as it reads secret-key packets

      http://trac.gnutls.org/cgi-bin/trac.cgi/ticket/22

I'm happy to discuss them either here or on the ticket tracker, if
it's better for the developers -- i wasn't sure what the protocol was,
but i thought i'd give a heads-up here at least.

Regards,

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: </pipermail/attachments/20080401/d27bb6ec/attachment.pgp>

From simon at josefsson.org  Wed Apr  2 12:01:24 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 02 Apr 2008 12:01:24 +0200
Subject: [Help-gnutls] Re: Signature Verify functions
In-Reply-To: <1207081222.3270.17.camel@XjuanNB> (Juan Pablo Ugarte's message
	of "Tue, 01 Apr 2008 17:20:22 -0300")
References: <1207081222.3270.17.camel@XjuanNB>
Message-ID: <87tziklgnf.fsf@mocca.josefsson.org>

Juan Pablo Ugarte <juanpablougarte at gmail.com> writes:

> Hello guys.
>
> I need a function to verify a little text using a public key.
>
> Its for a GPL project, i only need to verify some text and I can not add
> gnutls as a dependancy because its just for an easter egg :)
>
> hehe, anyways i just want to implement something like this...
>
> int
> verify_sign (pubkey, text, sign);
>
> Can anyone give me some pointers on wich files/functions should i "look"
> to implement such function?

Assuming you don't want the overheads of X.509 or OpenPGP, you should
look into libgcrypt which is the low-level crypto library.  It supports
signing and verification of RSA signatures.  If you have a bignum math
library available, writing a simple (and insecure) RSA verifier
shouldn't be that tricky.  It may be easier than trying to understand
the libgcrypt code and extract the necessary functions (which will
include the MPI code which is messy).

Of course, don't expect it to be secure (that's why we have the X.509
and OpenPGP umbrellas) but for an easter egg I guess that isn't a
priority.

/Simon




From simon at josefsson.org  Wed Apr  2 12:05:29 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 02 Apr 2008 12:05:29 +0200
Subject: [Help-gnutls] Re: trouble with OpenPGP DSA MPI extraction and
	OpenPGP private subkeys
In-Reply-To: <87fxu5dlkj.fsf@squeak.fifthhorseman.net> (Daniel Kahn Gillmor's
	message of "Tue, 01 Apr 2008 22:42:20 -0400")
References: <87fxu5dlkj.fsf@squeak.fifthhorseman.net>
Message-ID: <87od8slggm.fsf@mocca.josefsson.org>

Daniel Kahn Gillmor <dkg-debian.org at fifthhorseman.net> writes:

> Hey GnuTLS folks--
>
> The development branch of gnutls is looking really nice with 2.3.4.
> It's got functionality that i've been looking for for a while, in
> particular the capabilities for MPI extraction and transformation.
>
> I've just been playing around with the openpgp functions, and ran into
> a couple stumbling blocks.  I opened a ticket about each of them:
>
>  * DSA MPI extraction fails: i get GNUTLS_E_OPENPGP_GETKEY_FAILED when
>    calling gnutls_openpgp_privkey_export_dsa_raw():
>
>       http://trac.gnutls.org/cgi-bin/trac.cgi/ticket/21
>
>  * gnutls should be able to read OpenPGP secret-subkey packets the
>    same way as it reads secret-key packets
>
>       http://trac.gnutls.org/cgi-bin/trac.cgi/ticket/22
>
> I'm happy to discuss them either here or on the ticket tracker, if
> it's better for the developers -- i wasn't sure what the protocol was,
> but i thought i'd give a heads-up here at least.

A heads-up on the list is appreciated, there is no automatic
notification from the trac.gnutls.org.

This looks all OpenCDK/OpenPGP related, so I hope Nikos or Timo will
have time to look into it.  To understand if this should delay the
release, are these regressions compared to 2.2.x?  How important do you
think it is to fix this before the next stable release?

Thanks,
Simon




From nmav at gnutls.org  Wed Apr  2 15:37:25 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 2 Apr 2008 16:37:25 +0300
Subject: Fwd: [Help-gnutls] trouble with OpenPGP DSA MPI extraction and
	OpenPGP private subkeys
In-Reply-To: <c331d99a0804012358w150f6774q69c1b439fcf2f788@mail.gmail.com>
References: <87fxu5dlkj.fsf@squeak.fifthhorseman.net>
	<c331d99a0804012358w150f6774q69c1b439fcf2f788@mail.gmail.com>
Message-ID: <c331d99a0804020637v7b576f88pa90406064e80c33d@mail.gmail.com>

On Wed, Apr 2, 2008 at 5:42 AM, Daniel Kahn Gillmor
 <dkg-debian.org at fifthhorseman.net> wrote:
 > Hey GnuTLS folks--
 >
 >  The development branch of gnutls is looking really nice with 2.3.4.
 >  It's got functionality that i've been looking for for a while, in
 >  particular the capabilities for MPI extraction and transformation.
 >
 >  I've just been playing around with the openpgp functions, and ran into
 >  a couple stumbling blocks.  I opened a ticket about each of them:
 >
 >   * DSA MPI extraction fails: i get GNUTLS_E_OPENPGP_GETKEY_FAILED when
 >    calling gnutls_openpgp_privkey_export_dsa_raw():
 >
 >       http://trac.gnutls.org/cgi-bin/trac.cgi/ticket/21

 Hi!
  Thank you for your reports. I'll try to look into them as soon.
 However if you enable debugging level 2 in gnutls you will get the
 line number that this error occurred. It will be much faster for me to
 identify and fix this issue. Alternatively can this be reproduced with
 certtool?


 regards,
 Nikos




From dkg-debian.org at fifthhorseman.net  Wed Apr  2 19:01:42 2008
From: dkg-debian.org at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 02 Apr 2008 13:01:42 -0400
Subject: Fwd: [Help-gnutls] trouble with OpenPGP DSA MPI extraction and
	OpenPGP private subkeys
In-Reply-To: <c331d99a0804020637v7b576f88pa90406064e80c33d@mail.gmail.com>
	(Nikos Mavrogiannopoulos's message of "Wed\,
	2 Apr 2008 16\:37\:25 +0300")
References: <87fxu5dlkj.fsf@squeak.fifthhorseman.net>
	<c331d99a0804012358w150f6774q69c1b439fcf2f788@mail.gmail.com>
	<c331d99a0804020637v7b576f88pa90406064e80c33d@mail.gmail.com>
Message-ID: <87hcek5gy1.fsf@squeak.fifthhorseman.net>

On Wed 2008-04-02 09:37:25 -0400, Nikos Mavrogiannopoulos wrote:

>  If you enable debugging level 2 in gnutls you will get the line
>  number that this error occurred. It will be much faster for me to
>  identify and fix this issue.

I've followed up with this on the ticket itself:

   http://trac.gnutls.org/cgi-bin/trac.cgi/ticket/21#comment:1

> Alternatively can this be reproduced with certtool?

I don't know the certtool interface well enough to know how i'd do
that.  Reading the certtool man page, I don't see any options that
mention OpenPGP private keys.  If that's correct, i'd suggest that you
mention X.509 in the NAME section of the man page to distinguish it
From anything dealing with OpenPGP.

Thanks for the quick response, Nikos!

       --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: </pipermail/attachments/20080402/b1595604/attachment.pgp>

From nmav at gnutls.org  Wed Apr  2 19:24:08 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 02 Apr 2008 20:24:08 +0300
Subject: Fwd: [Help-gnutls] trouble with OpenPGP DSA MPI extraction and
	OpenPGP private subkeys
In-Reply-To: <87hcek5gy1.fsf@squeak.fifthhorseman.net>
References: <87fxu5dlkj.fsf@squeak.fifthhorseman.net>	<c331d99a0804012358w150f6774q69c1b439fcf2f788@mail.gmail.com>	<c331d99a0804020637v7b576f88pa90406064e80c33d@mail.gmail.com>
	<87hcek5gy1.fsf@squeak.fifthhorseman.net>
Message-ID: <47F3C138.3060409@gnutls.org>

Daniel Kahn Gillmor wrote:
> On Wed 2008-04-02 09:37:25 -0400, Nikos Mavrogiannopoulos wrote:
> 
>>  If you enable debugging level 2 in gnutls you will get the line
>>  number that this error occurred. It will be much faster for me to
>>  identify and fix this issue.
> 
> I've followed up with this on the ticket itself:
> 
>    http://trac.gnutls.org/cgi-bin/trac.cgi/ticket/21#comment:1

Thank you.

>> Alternatively can this be reproduced with certtool?
> 
> I don't know the certtool interface well enough to know how i'd do
> that.  Reading the certtool man page, I don't see any options that
> mention OpenPGP private keys.  If that's correct, i'd suggest that you
> mention X.509 in the NAME section of the man page to distinguish it
> From anything dealing with OpenPGP.

Oh, it seems I've not documented the new options to the manpage. The 
--help option for now is the only documentation.

regards,
Nikos




From dkg-debian.org at fifthhorseman.net  Wed Apr  2 19:30:45 2008
From: dkg-debian.org at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 02 Apr 2008 13:30:45 -0400
Subject: [Help-gnutls] Re: trouble with OpenPGP DSA MPI extraction and
	OpenPGP private subkeys
In-Reply-To: <87od8slggm.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Wed\, 02 Apr 2008 12\:05\:29 +0200")
References: <87fxu5dlkj.fsf@squeak.fifthhorseman.net>
	<87od8slggm.fsf@mocca.josefsson.org>
Message-ID: <87fxu4yxiy.fsf@squeak.fifthhorseman.net>

On Wed 2008-04-02 06:05:29 -0400, Simon Josefsson wrote:

> A heads-up on the list is appreciated, there is no automatic
> notification from the trac.gnutls.org.

Can i help you get that set up somehow?  I administer a few trac sites
myself, and i'd be happy to advise or tweak it so it works for you.

What works for me on other trac instances (already in place on
trac.gnutls.org, actually) is just to subscribe my RSS feed reader to
the feed on the timeline page.

We could also subscribe the trac site to one of the GnuTLS mailing
lists so that changes get published that way.

> This looks all OpenCDK/OpenPGP related, so I hope Nikos or Timo will
> have time to look into it.  To understand if this should delay the
> release, are these regressions compared to 2.2.x?  How important do
> you think it is to fix this before the next stable release?

#21 is *not* a regression compared to 2.2.x -- the function in
question (gnutls_openpgp_privkey_export_dsa_raw()) didn't even exist
in 2.2, afaict.

I haven't tested #22 against 2.2.x, but i seriously doubt it used to
be possible.  I wouldn't want to hold up the 2.4 release for either of
these issues.

Regards,

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: </pipermail/attachments/20080402/ae7b0d17/attachment.pgp>

From juanpablougarte at gmail.com  Wed Apr  2 21:53:52 2008
From: juanpablougarte at gmail.com (Juan Pablo Ugarte)
Date: Wed, 02 Apr 2008 16:53:52 -0300
Subject: [Help-gnutls] Re: Signature Verify functions
In-Reply-To: <87tziklgnf.fsf@mocca.josefsson.org>
References: <1207081222.3270.17.camel@XjuanNB>
	<87tziklgnf.fsf@mocca.josefsson.org>
Message-ID: <1207166032.3364.13.camel@XjuanNB>

Hi, thanks for reply

[...]
> 
> Assuming you don't want the overheads of X.509 or OpenPGP, you should

right

> look into libgcrypt which is the low-level crypto library.  It supports
> signing and verification of RSA signatures.  If you have a bignum math
> library available, writing a simple (and insecure) RSA verifier
> shouldn't be that tricky.  It may be easier than trying to understand
> the libgcrypt code and extract the necessary functions (which will
> include the MPI code which is messy).

After reading a bit more, i do not really need a signature verify
function, i just need a RSA decrypt function since the text i want to
sign/encrypt will be short (it will probably be just a name)
So there is no point in hashing the text and then encrypting the hash :)
Would not that be the insecure part you mention before?


btw, i am looking into xyssl library, seem like i can grab rsa.c and
bignum.c and save the public modulus and exponent as a string.
Hope that would be enough to decrypt.

hehe

thanks

Juan Pablo





From dkg-debian.org at fifthhorseman.net  Thu Apr  3 09:23:16 2008
From: dkg-debian.org at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 03 Apr 2008 03:23:16 -0400
Subject: [Help-gnutls] gnutls_openpgp_privkey_import() behavior seems
	inconsistent depending on choice of "format" variable
Message-ID: <87ve2zl7vf.fsf@squeak.fifthhorseman.net>

Hi GnuTLS folks--

I just opened another ticket, this time about weirdly inconsistent
behavior in the gnutls_openpgp_privkey_import() function:

 http://trac.gnutls.org/cgi-bin/trac.cgi/ticket/23

Please let me know if i can do anything to help debug it further.

Regards,

        --dkg

PS i'd like to follow the ticketing system via RSS, but i notice that
you don't appear to have the following setting in the [timeline]
section of your trac.ini:

  ticket_show_details = true

Having this set would make it easy for me to follow activity on the
tracker even if a ticket doesn't change state explicitly.

You can read more about this setting here:

 http://trac.gnutls.org/cgi-bin/trac.cgi/wiki/TracIni#timeline-section
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: </pipermail/attachments/20080403/73880445/attachment.pgp>

From ludo at gnu.org  Thu Apr  3 11:39:43 2008
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Thu, 03 Apr 2008 11:39:43 +0200
Subject: [Help-gnutls] Re: gnutls_openpgp_privkey_import() behavior seems
	inconsistent depending on choice of "format" variable
References: <87ve2zl7vf.fsf@squeak.fifthhorseman.net>
Message-ID: <87zlsbz38g.fsf@gnu.org>

Hi,

Daniel Kahn Gillmor <dkg-debian.org at fifthhorseman.net> writes:

> I just opened another ticket, this time about weirdly inconsistent
> behavior in the gnutls_openpgp_privkey_import() function:
>
>  http://trac.gnutls.org/cgi-bin/trac.cgi/ticket/23
>
> Please let me know if i can do anything to help debug it further.

There was a fix in this area some time ago, but it might be irrelevant
since the recent OpenPGP overhaul:

  http://permalink.gmane.org/gmane.network.gnutls.general/587
  http://permalink.gmane.org/gmane.network.gnutls.general/657

The `openpgp-keys.scm' Guile test checks the behavior of base64 import.
It should probably be extended to support raw imports as well.  I'll try
to do that later.

Thanks,
Ludovic.





From simon at josefsson.org  Thu Apr  3 12:42:02 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 03 Apr 2008 12:42:02 +0200
Subject: [Help-gnutls] trac.gnutls.org
In-Reply-To: <87fxu4yxiy.fsf@squeak.fifthhorseman.net> (Daniel Kahn Gillmor's
	message of "Wed, 02 Apr 2008 13:30:45 -0400")
References: <87fxu5dlkj.fsf@squeak.fifthhorseman.net>
	<87od8slggm.fsf@mocca.josefsson.org>
	<87fxu4yxiy.fsf@squeak.fifthhorseman.net>
Message-ID: <87wsnf9q4l.fsf_-_@mocca.josefsson.org>

Daniel Kahn Gillmor <dkg-debian.org at fifthhorseman.net> writes:

> On Wed 2008-04-02 06:05:29 -0400, Simon Josefsson wrote:
>
>> A heads-up on the list is appreciated, there is no automatic
>> notification from the trac.gnutls.org.
>
> Can i help you get that set up somehow?  I administer a few trac sites
> myself, and i'd be happy to advise or tweak it so it works for you.
>
> What works for me on other trac instances (already in place on
> trac.gnutls.org, actually) is just to subscribe my RSS feed reader to
> the feed on the timeline page.
>
> We could also subscribe the trac site to one of the GnuTLS mailing
> lists so that changes get published that way.

We definitely could use help with trac.gnutls.org.  Btw, do you know a
good way to deal with trac-spam?  Right now I remove it manually when I
noticed it but that doesn't scale well, and I'm pretty sure I fail to
catch some spam.

Subscribing gnutls-devel at gnu.org to get updates from the trac site would
work, unless the emails are completely unreadable.  Do you have examples
of such e-mails?  How could we set this up?

Do you know a trac hosting site, so that someone else takes care of the
low-level trac administration?  I'd ideally want to find someone else to
host or co-maintain trac.gnutls.org because it steals my time from more
important things.  The reason we aren't using savannah for everything is
that I need a gnutls-related wiki.  Savannah doesn't have roadmap or
timeline pages either, as far as I understand.  And I kind of like the
simplicity of the trac interface.

>> This looks all OpenCDK/OpenPGP related, so I hope Nikos or Timo will
>> have time to look into it.  To understand if this should delay the
>> release, are these regressions compared to 2.2.x?  How important do
>> you think it is to fix this before the next stable release?
>
> #21 is *not* a regression compared to 2.2.x -- the function in
> question (gnutls_openpgp_privkey_export_dsa_raw()) didn't even exist
> in 2.2, afaict.
>
> I haven't tested #22 against 2.2.x, but i seriously doubt it used to
> be possible.  I wouldn't want to hold up the 2.4 release for either of
> these issues.

Thanks.

/Simon




From simon at josefsson.org  Thu Apr  3 12:48:28 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 03 Apr 2008 12:48:28 +0200
Subject: [Help-gnutls] Re: gnutls_openpgp_privkey_import() behavior seems
	inconsistent depending on choice of "format" variable
In-Reply-To: <87ve2zl7vf.fsf@squeak.fifthhorseman.net> (Daniel Kahn Gillmor's
	message of "Thu, 03 Apr 2008 03:23:16 -0400")
References: <87ve2zl7vf.fsf@squeak.fifthhorseman.net>
Message-ID: <87r6dn9ptv.fsf@mocca.josefsson.org>

Daniel Kahn Gillmor <dkg-debian.org at fifthhorseman.net> writes:

> Hi GnuTLS folks--
>
> I just opened another ticket, this time about weirdly inconsistent
> behavior in the gnutls_openpgp_privkey_import() function:
>
>  http://trac.gnutls.org/cgi-bin/trac.cgi/ticket/23
>
> Please let me know if i can do anything to help debug it further.

Looks OpenPGP related so I'm counting on Nikos.

> PS i'd like to follow the ticketing system via RSS, but i notice that
> you don't appear to have the following setting in the [timeline]
> section of your trac.ini:
>
>   ticket_show_details = true
>
> Having this set would make it easy for me to follow activity on the
> tracker even if a ticket doesn't change state explicitly.

Changed.

Thanks,
/Simon




From dkg-debian.org at fifthhorseman.net  Thu Apr  3 17:15:49 2008
From: dkg-debian.org at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 03 Apr 2008 11:15:49 -0400
Subject: [Help-gnutls] Re: gnutls_openpgp_privkey_import() behavior seems
	inconsistent depending on choice of "format" variable
In-Reply-To: <87zlsbz38g.fsf@gnu.org> ("Ludovic =?utf-8?Q?Court=C3=A8s=22'?=
	=?utf-8?Q?s?= message of "Thu\, 03 Apr 2008 11\:39\:43 +0200")
References: <87ve2zl7vf.fsf@squeak.fifthhorseman.net> <87zlsbz38g.fsf@gnu.org>
Message-ID: <87tzijgeai.fsf@squeak.fifthhorseman.net>

On Thu 2008-04-03 05:39:43 -0400, Ludovic Court?s wrote:

> There was a fix in this area some time ago, but it might be irrelevant
> since the recent OpenPGP overhaul:
>
>   http://permalink.gmane.org/gmane.network.gnutls.general/587
>   http://permalink.gmane.org/gmane.network.gnutls.general/657

I forgot to mention in #23 that i was using the 2.3.4 release (i've
noted that on the ticket now), which is earlier than these changes.
So while they do look relevant, the inconsistency in behavior is still
present.

> The `openpgp-keys.scm' Guile test checks the behavior of base64
> import.  It should probably be extended to support raw imports as
> well.  I'll try to do that later.

Thanks, that would be great.

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: </pipermail/attachments/20080403/6d766139/attachment.pgp>

From dkg-debian.org at fifthhorseman.net  Thu Apr  3 17:31:08 2008
From: dkg-debian.org at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 03 Apr 2008 11:31:08 -0400
Subject: [Help-gnutls] Re: gnutls_openpgp_privkey_import() behavior seems
	inconsistent depending on choice of "format" variable
In-Reply-To: <87r6dn9ptv.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Thu\, 03 Apr 2008 12\:48\:28 +0200")
References: <87ve2zl7vf.fsf@squeak.fifthhorseman.net>
	<87r6dn9ptv.fsf@mocca.josefsson.org>
Message-ID: <87prt7gdkz.fsf@squeak.fifthhorseman.net>

On Thu 2008-04-03 06:48:28 -0400, Simon Josefsson wrote:

> Daniel Kahn Gillmor <dkg-debian.org at fifthhorseman.net> writes:
>
>> have the following setting in the [timeline] section of your
>> trac.ini:
>>
>>   ticket_show_details = true
>
> Changed.

Thanks.  i'm now subscribed to the feed at:

 http://trac.gnutls.org/cgi-bin/trac.cgi/timeline?milestone=on&ticket=on&ticket_details=on&wiki=on&max=50&daysback=90&format=rss

That should make it easier to keep track of what's going on.

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: </pipermail/attachments/20080403/3e0d53b7/attachment.pgp>

From ludo at gnu.org  Thu Apr  3 17:44:36 2008
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Thu, 03 Apr 2008 17:44:36 +0200
Subject: [Help-gnutls] Re: gnutls_openpgp_privkey_import() behavior seems
	inconsistent depending on choice of "format" variable
References: <87ve2zl7vf.fsf@squeak.fifthhorseman.net> <87zlsbz38g.fsf@gnu.org>
	<87tzijgeai.fsf@squeak.fifthhorseman.net>
Message-ID: <87y77vndsr.fsf@gnu.org>

Daniel Kahn Gillmor <dkg-debian.org at fifthhorseman.net> writes:

> On Thu 2008-04-03 05:39:43 -0400, Ludovic Court?s wrote:
>
>> There was a fix in this area some time ago, but it might be irrelevant
>> since the recent OpenPGP overhaul:
>>
>>   http://permalink.gmane.org/gmane.network.gnutls.general/587
>>   http://permalink.gmane.org/gmane.network.gnutls.general/657
>
> I forgot to mention in #23 that i was using the 2.3.4 release (i've
> noted that on the ticket now), which is earlier than these changes.
> So while they do look relevant, the inconsistency in behavior is still
> present.

You mean, it's still present after applying the referred patch?

Thanks,
Ludovic.





From nmav at gnutls.org  Thu Apr  3 19:38:49 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 03 Apr 2008 20:38:49 +0300
Subject: [Help-gnutls] trouble with OpenPGP DSA MPI extraction and OpenPGP
	private subkeys
In-Reply-To: <87zlsblayt.fsf@squeak.fifthhorseman.net>
References: <87fxu5dlkj.fsf@squeak.fifthhorseman.net>	<47F3C05E.1080408@gnutls.org>	<87k5jgw1ks.fsf@squeak.fifthhorseman.net>	<47F3D66B.2070201@gnutls.org>
	<87zlsblayt.fsf@squeak.fifthhorseman.net>
Message-ID: <47F51629.7000408@gnutls.org>

Daniel Kahn Gillmor wrote:
> On Wed 2008-04-02 14:54:35 -0400, Nikos Mavrogiannopoulos wrote:
> 
>> If you have a single (secret) subkey you can call:
>> gnutls_openpgp_privkey_get_subkey_pk_algorithm with index 0 to
>> retrieve the algorithm. You can also convert from key id to index
>> using:
>> gnutls_openpgp_privkey_get_subkey_idx().
>>
>> The idea is that you use gnutls_openpgp_privkey_get_pk to retrieve the
>> main secret key algorithm only.
> 
> OK, this makes sense for just getting the algorithm of a subkey.  But
> what i'm looking to do is to get the secret subkey details directly.
> For instance, if i'm looking at an RSA subkey, and i want to get at
> the raw components of the subkey (prime, modulus, etc), how would i do
> that from GnuTLS? 

There is gnutls_openpgp_privkey_export_subkey_rsa_raw() and 
gnutls_openpgp_privkey_export_subkey_dsa_raw(). Are they suitable for 
what you want to do?


> PS i'm happy having discussions like this on-list, if you'd prefer
>    them to be archived for other folks to find.  i'm replying to this
>    privately because it was sent to me privately, but i won't mind if
>    you choose to publish it anywhere.

It was accidentally not forwarded to the list.

regards,
Nikos





From dkg-debian.org at fifthhorseman.net  Thu Apr  3 19:45:55 2008
From: dkg-debian.org at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 03 Apr 2008 13:45:55 -0400
Subject: [Help-gnutls] Re: gnutls_openpgp_privkey_import() behavior seems
	inconsistent depending on choice of "format" variable
In-Reply-To: <87y77vndsr.fsf@gnu.org> ("Ludovic =?utf-8?Q?Court=C3=A8s=22'?=
	=?utf-8?Q?s?= message of "Thu\, 03 Apr 2008 17\:44\:36 +0200")
References: <87ve2zl7vf.fsf@squeak.fifthhorseman.net> <87zlsbz38g.fsf@gnu.org>
	<87tzijgeai.fsf@squeak.fifthhorseman.net> <87y77vndsr.fsf@gnu.org>
Message-ID: <87sky2de7g.fsf@squeak.fifthhorseman.net>

Thanks for the response, Ludovic--

On Thu 2008-04-03 11:44:36 -0400, Ludovic Court?s wrote:

>>>   http://permalink.gmane.org/gmane.network.gnutls.general/657
>
> You mean, it's still present after applying the referred patch?

Ah, i hadn't tried to apply the patch in the referenced message -- i
misunderstood and thought it was already applied.  I haven't applied
it myself.

When i try to apply it to the master branch in git, none of the hunks
are accepted:

[0 dkg at squeak git-gnutls]$ wget -q -O- 'http://cache.gmane.org/gmane/network/gnutls/general/657-001.bin' | patch -p1 --dry-run -f
patching file lib/gnutls_cert.c
Hunk #1 FAILED at 718.
1 out of 1 hunk FAILED -- saving rejects to file lib/gnutls_cert.c.rej
can't find file to patch at input line 18
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|
|
|--- orig/lib/gnutls_extra_hooks.h
|+++ mod/lib/gnutls_extra_hooks.h
--------------------------
No file to patch.  Skipping patch.
1 out of 1 hunk ignored
can't find file to patch at input line 32
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|
|
|--- orig/libextra/gnutls_openpgp.c
|+++ mod/libextra/gnutls_openpgp.c
--------------------------
No file to patch.  Skipping patch.
6 out of 6 hunks ignored
can't find file to patch at input line 103
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|
|
|--- orig/libextra/openpgp/gnutls_openpgp.h
|+++ mod/libextra/openpgp/gnutls_openpgp.h
--------------------------
No file to patch.  Skipping patch.
1 out of 1 hunk ignored
can't find file to patch at input line 117
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|
|
|--- orig/libextra/openpgp/privkey.c
|+++ mod/libextra/openpgp/privkey.c
--------------------------
No file to patch.  Skipping patch.
1 out of 1 hunk ignored
[1 dkg at squeak git-gnutls]$ 

Does it apply for you?  Am i doing something wrong?  Is this because
of the OpenPGP overhaul?

   --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: </pipermail/attachments/20080403/9c8f4cf1/attachment.pgp>

From nmav at gnutls.org  Thu Apr  3 19:48:37 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 03 Apr 2008 20:48:37 +0300
Subject: [Help-gnutls] gnutls_openpgp_privkey_import() behavior seems
	inconsistent depending on choice of "format" variable
In-Reply-To: <87ve2zl7vf.fsf@squeak.fifthhorseman.net>
References: <87ve2zl7vf.fsf@squeak.fifthhorseman.net>
Message-ID: <47F51875.7000901@gnutls.org>

Daniel Kahn Gillmor wrote:
> Hi GnuTLS folks--
> 
> I just opened another ticket, this time about weirdly inconsistent
> behavior in the gnutls_openpgp_privkey_import() function:
> 
>  http://trac.gnutls.org/cgi-bin/trac.cgi/ticket/23
> 
> Please let me know if i can do anything to help debug it further.

This is not quite easy to fix since it depends on the internals of 
opencdk. As far as I remember opencdk auto detects the input data and 
acts accordingly. However in gnutls we specifically set the raw/base64 
flag. An improvement I could think would be to check the data after the 
import in order to verify that import was successful.

Does the attached patch solve the issue for you?

regards,
Nikos
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: diff.txt
URL: </pipermail/attachments/20080403/231e9e91/attachment.txt>

From dkg-debian.org at fifthhorseman.net  Thu Apr  3 20:44:07 2008
From: dkg-debian.org at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 03 Apr 2008 14:44:07 -0400
Subject: [Help-gnutls] trouble with OpenPGP DSA MPI extraction and OpenPGP
	private subkeys
In-Reply-To: <47F51629.7000408@gnutls.org> (Nikos Mavrogiannopoulos's message
	of "Thu\, 03 Apr 2008 20\:38\:49 +0300")
References: <87fxu5dlkj.fsf@squeak.fifthhorseman.net>
	<47F3C05E.1080408@gnutls.org>
	<87k5jgw1ks.fsf@squeak.fifthhorseman.net>
	<47F3D66B.2070201@gnutls.org>
	<87zlsblayt.fsf@squeak.fifthhorseman.net>
	<47F51629.7000408@gnutls.org>
Message-ID: <87abkaaidk.fsf@squeak.fifthhorseman.net>

On Thu 2008-04-03 13:38:49 -0400, Nikos Mavrogiannopoulos wrote:

> There is gnutls_openpgp_privkey_export_subkey_rsa_raw() and
> gnutls_openpgp_privkey_export_subkey_dsa_raw(). Are they suitable for
> what you want to do?

Sigh.  Yes, those look like they'll do exactly what i want.  I'm not
sure how i missed them, having read the docs over and over again.
Thanks for pointing them out!  I've closed #22 and marked it as
invalid.

Regards,

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: </pipermail/attachments/20080403/849292c2/attachment.pgp>

From dkg-debian.org at fifthhorseman.net  Thu Apr  3 22:47:48 2008
From: dkg-debian.org at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 03 Apr 2008 16:47:48 -0400
Subject: [Help-gnutls] gnutls_openpgp_privkey_import() behavior seems
	inconsistent depending on choice of "format" variable
In-Reply-To: <47F51875.7000901@gnutls.org> (Nikos Mavrogiannopoulos's message
	of "Thu\, 03 Apr 2008 20\:48\:37 +0300")
References: <87ve2zl7vf.fsf@squeak.fifthhorseman.net>
	<47F51875.7000901@gnutls.org>
Message-ID: <87zlsawtqj.fsf@squeak.fifthhorseman.net>

On Thu 2008-04-03 13:48:37 -0400, Nikos Mavrogiannopoulos wrote:

> This is not quite easy to fix since it depends on the internals of
> opencdk. As far as I remember opencdk auto detects the input data
> and acts accordingly. However in gnutls we specifically set the
> raw/base64 flag. An improvement I could think would be to check the
> data after the import in order to verify that import was successful.
> 
> Does the attached patch solve the issue for you?

Thanks, Nikos.  That's certainly an improvement -- i now get
GNUTLS_E_OPENPGP_GETKEY_FAILED when i try a privkey_import in RAW mode
but the incoming datum is BASE64-encoded.  I think this patch should
be applied to the master branch.

However, i don't get any failures when i set format to
GNUTLS_OPENPGP_FMT_BASE64, whether the input is raw or not.  In fact,
i can successfully import the key and use it regardless of the input
format as long as i've set format this way.

So: why bother with this parameter to privkey_import, since one
setting (FMT_BASE64) works no matter what kind of input you've got?
Why would anyone choose FMT_RAW?

The inconsistency between format flags is confusing and unpredictable
From the docs; and unpredictability is a property that's undesirable
in a library, no?

Thanks for all your work on this!  It's exciting to see what the new
versions of GnuTLS make possible.

    --dkg

PS no need to Cc me.  I read the list!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: </pipermail/attachments/20080403/c33b66ed/attachment.pgp>

From ludo at gnu.org  Fri Apr  4 09:33:42 2008
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Fri, 04 Apr 2008 09:33:42 +0200
Subject: [Help-gnutls] Re: gnutls_openpgp_privkey_import() behavior seems
	inconsistent depending on choice of "format" variable
References: <87ve2zl7vf.fsf@squeak.fifthhorseman.net> <87zlsbz38g.fsf@gnu.org>
	<87tzijgeai.fsf@squeak.fifthhorseman.net> <87y77vndsr.fsf@gnu.org>
	<87sky2de7g.fsf@squeak.fifthhorseman.net>
Message-ID: <87k5jedqg9.fsf@gnu.org>

Hi,

Daniel Kahn Gillmor <dkg-debian.org at fifthhorseman.net> writes:

> Does it apply for you?  Am i doing something wrong?  Is this because
> of the OpenPGP overhaul?

Probably, but I initially thought you were using a version older than
the patch.

Anyway, it seems that Nikos' patch partly addresses the problem now.

Thanks,
Ludovic.





From nmav at gnutls.org  Fri Apr  4 22:57:51 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 04 Apr 2008 23:57:51 +0300
Subject: [Help-gnutls] gnutls_openpgp_privkey_import() behavior seems
	inconsistent depending on choice of "format" variable
In-Reply-To: <87zlsawtqj.fsf@squeak.fifthhorseman.net>
References: <87ve2zl7vf.fsf@squeak.fifthhorseman.net>	<47F51875.7000901@gnutls.org>
	<87zlsawtqj.fsf@squeak.fifthhorseman.net>
Message-ID: <47F6964F.6060303@gnutls.org>

Daniel Kahn Gillmor wrote:
> On Thu 2008-04-03 13:48:37 -0400, Nikos Mavrogiannopoulos wrote:
> 
>> This is not quite easy to fix since it depends on the internals of
>> opencdk. As far as I remember opencdk auto detects the input data
>> and acts accordingly. However in gnutls we specifically set the
>> raw/base64 flag. An improvement I could think would be to check the
>> data after the import in order to verify that import was successful.
>>
>> Does the attached patch solve the issue for you?
> 
> Thanks, Nikos.  That's certainly an improvement -- i now get
> GNUTLS_E_OPENPGP_GETKEY_FAILED when i try a privkey_import in RAW mode
> but the incoming datum is BASE64-encoded.  I think this patch should
> be applied to the master branch.

Thanks for trying. Applied.

> However, i don't get any failures when i set format to
> GNUTLS_OPENPGP_FMT_BASE64, whether the input is raw or not.  In fact,
> i can successfully import the key and use it regardless of the input
> format as long as i've set format this way.

This is not easy to fix and I'll leave it for now.

> So: why bother with this parameter to privkey_import, since one
> setting (FMT_BASE64) works no matter what kind of input you've got?
> Why would anyone choose FMT_RAW?

It is cleaner to specify what you want to import. The future API might 
not autodetect the input data.

> The inconsistency between format flags is confusing and unpredictable
> From the docs; and unpredictability is a property that's undesirable
> in a library, no?

The flags should be used as documented. The functionality to being able 
to import raw when specified base64 is not documented and might be 
removed at future versions.

regards,
Nikos




From ludo at gnu.org  Sun Apr  6 17:08:15 2008
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Sun, 06 Apr 2008 17:08:15 +0200
Subject: [Help-gnutls] Re: gnutls_openpgp_privkey_import() behavior seems
	inconsistent depending on choice of "format" variable
References: <87ve2zl7vf.fsf@squeak.fifthhorseman.net>
	<47F51875.7000901@gnutls.org>
	<87zlsawtqj.fsf@squeak.fifthhorseman.net>
	<47F6964F.6060303@gnutls.org>
Message-ID: <87prt3qaw0.fsf@gnu.org>

Hi,

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> It is cleaner to specify what you want to import. The future API might
> not autodetect the input data.

The thing is, based on the current GnuTLS documentation, applications
could try to implement autodetection by themselves, assuming importing
raw keys with a base64 flag or vice versa will fail, but this won't work
currently.

Thanks,
Ludovic.





From dkg-debian.org at fifthhorseman.net  Tue Apr  8 20:44:47 2008
From: dkg-debian.org at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 08 Apr 2008 14:44:47 -0400
Subject: [Help-gnutls] trac.gnutls.org
In-Reply-To: <87wsnf9q4l.fsf_-_@mocca.josefsson.org> (Simon Josefsson's
	message of "Thu\, 03 Apr 2008 12\:42\:02 +0200")
References: <87fxu5dlkj.fsf@squeak.fifthhorseman.net>
	<87od8slggm.fsf@mocca.josefsson.org>
	<87fxu4yxiy.fsf@squeak.fifthhorseman.net>
	<87wsnf9q4l.fsf_-_@mocca.josefsson.org>
Message-ID: <87bq4kw5i8.fsf@squeak.fifthhorseman.net>

On Thu 2008-04-03 06:42:02 -0400, Simon Josefsson wrote:

> We definitely could use help with trac.gnutls.org.  Btw, do you know
> a good way to deal with trac-spam?  Right now I remove it manually
> when I noticed it but that doesn't scale well, and I'm pretty sure I
> fail to catch some spam.

Sigh.  Spammers suck.  I notice that #20 should probably be purged
(not linking to it to avoid inflating the pagerank).  Subscribing to
the timeline RSS is probably a good idea if you want to see everything
that goes through it.

One site that i work with uses the TracSpamFilter plugin [0], and has
the following set in its [components] section of trac.ini:

tracspamfilter.* = enabled
tracspamfilter.adapters.* = enabled
tracspamfilter.admin.* = enabled
tracspamfilter.api.* = enabled
tracspamfilter.filters.akismet.* = enabled
tracspamfilter.filters.extlinks.* = enabled
tracspamfilter.filters.ip_throttle.* = enabled
tracspamfilter.filters.regex.* = enabled
tracspamfilter.filters.session.* = enabled
tracspamfilter.filters.valid_email.* = enabled

It also doesn't allow non-authenticated users to comment (but allows
anyone with an OpenID to authenticate).

> Subscribing gnutls-devel at gnu.org to get updates from the trac site
> would work, unless the emails are completely unreadable.  Do you
> have examples of such e-mails?  How could we set this up?

The e-mails are pretty readable.  A different trac site i maintain has
the smtp_* variables set in the [notification] section [1].  In
particular, if your machine has a functional MTA, you can set:

smtp_server = localhost
smtp_port = 25
smtp_enabled = true
smtp_default_domain = gnutls.org
smtp_always_cc = gnutls-devel at gnu.org
smtp_from = whatever at whatever.domain.you.want

(and make sure that gnutls-devel allows postings from senders set to
whatever smtp_from is set to)

> Do you know a trac hosting site, so that someone else takes care of
> the low-level trac administration?  I'd ideally want to find someone
> else to host or co-maintain trac.gnutls.org because it steals my
> time from more important things.  The reason we aren't using
> savannah for everything is that I need a gnutls-related wiki.
> Savannah doesn't have roadmap or timeline pages either, as far as I
> understand.  And I kind of like the simplicity of the trac
> interface.

Understood.  The trac interface is one of the cleaner ones out there.

I collaborate with May First/People Link [2], which is a membership
organization that assists its members with internet work.  There has
been some discussion at MF/PL recently about making it simpler to
support members' use of trac [3].  If gnutls.org was a member of
MF/PL, it could get the support of that organization, which at the
moment includes trac 0.11b1, fwict.

Alternately, i can take a look at your current trac setup -- i can't
promise to offer long-term support right now, but it looks like an
environment i'm comfortable with, if my snooping is correct: it's
hosted on kniv, which appears (from the ssh greeting string and the
Server: HTTP response headers) to be running debian etch.  If you'd
like me to poke around and see what makes sense, please let me know.

Perhaps most simply, if you want me to help monitor trac.gnutls.org
for spam, i'd just need a trac login with privileges to be able to
delete suspect comments or revert wiki edits.  I dunno how yer giving
those out, but i figure since i'm following the RSS feed anyway, i
could make myself useful if you want me to.

Regards,

        --dkg

[0] http://trac.edgewall.org/wiki/SpamFilter
[1] http://trac.gnutls.org/cgi-bin/trac.cgi/wiki/TracIni#notification-section
[2] http://mayfirst.org/
[3] https://support.mayfirst.org/wiki/setup_trac
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: </pipermail/attachments/20080408/952ec6bd/attachment.pgp>

From dkg-debian.org at fifthhorseman.net  Tue Apr  8 21:27:46 2008
From: dkg-debian.org at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 08 Apr 2008 15:27:46 -0400
Subject: [Help-gnutls] Setting OpenPGP private key MPI components
Message-ID: <873apww3il.fsf@squeak.fifthhorseman.net>

Hey folks--

I opened a ticket about being able to explicitly set the MPI
components of an OpenPGP private key:

 http://trac.gnutls.org/cgi-bin/trac.cgi/ticket/24

This would be really useful for me (and a step toward OpenPGP key
generation in GnuTLS, if that's desired), and i was wondering what
might be needed to get this functionality added.

I've done a brief review of the source of gnutls and opencdk to see if
there was an obvious way to add the function.  But either i don't
understand the libraries well enough (quite possible!) or there are
enough architectural pieces missing to make the solution non-obvious
to me.

Any thoughts about if this is something that seems possible in the
current framework?  I'm happy to take a crack at adding a function
named something like gnutls_openpgp_privkey_import_rsa_raw() (and
offering a patch for review) if one of the more experienced developers
thinks it's both desirable and possible, and is up for pointing me in
the right direction.

Regards,

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: </pipermail/attachments/20080408/5e8ee4f5/attachment.pgp>

From dkg-debian.org at fifthhorseman.net  Wed Apr  9 02:25:59 2008
From: dkg-debian.org at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 08 Apr 2008 20:25:59 -0400
Subject: [Help-gnutls] segfaults using certtool --pgp-certificate-info
Message-ID: <87ej9fc1rc.fsf@squeak.fifthhorseman.net>

Hey GnuTLS people--

I've opened two tickets about segfaults when using certtool with the
--pgp-certificate-info flag:

 http://trac.gnutls.org/cgi-bin/trac.cgi/ticket/26
 http://trac.gnutls.org/cgi-bin/trac.cgi/ticket/27

Just wanted to give a heads-up.

Thanks for all your work on this project,

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: </pipermail/attachments/20080408/9f9f34e6/attachment.pgp>

From dkg-debian.org at fifthhorseman.net  Wed Apr  9 02:28:31 2008
From: dkg-debian.org at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 08 Apr 2008 20:28:31 -0400
Subject: [Help-gnutls] gnutls_openpgp_crt_get_auth_subkey can return a key
	without the Authentication flag set
Message-ID: <87abk3c1n4.fsf@squeak.fifthhorseman.net>

Hey GnuTLS folks--

I've opened a ticket about how the semantics of
gnutls_openpgp_crt_get_auth_subkey() doesn't seem to match the
documentation, and the ways i think they could be reconciled:

 http://trac.gnutls.org/cgi-bin/trac.cgi/ticket/28

Any discussion or explanations on the ticket would be welcome.

Thanks,

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: </pipermail/attachments/20080408/9db76ed8/attachment.pgp>

From simon at josefsson.org  Wed Apr  9 09:51:03 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 09 Apr 2008 09:51:03 +0200
Subject: [Help-gnutls] Re: duplicate symbols complaint on Mac OS X 10.5.2
In-Reply-To: <87od90clgu.fsf@gnu.org> ("Ludovic =?iso-8859-1?Q?Court=E8s?=
	=?iso-8859-1?Q?=22's?= message of "Thu, 27
	Mar 2008 15:04:01 +0100")
References: <922d0b4d0802172330r33f794edu8b968adfee626357@mail.gmail.com>
	<87myp5jltq.fsf@mocca.josefsson.org>
	<D311DE37-F970-43EF-A1AB-394C6E407C16@gmail.com>
	<87myowwf5k.fsf@gnu.org>
	<8FD0D2D5-29C7-4E1B-9FB9-1CCB29E20438@gmail.com>
	<87ve3jn6na.fsf@gnu.org>
	<01646597-495C-4D75-8F65-665209687F06@gmail.com>
	<87d4pqj4zc.fsf@gnu.org>
	<FEB5CC46-BC82-44A6-BB6B-BE7EE1072B71@gmail.com>
	<87od9adag8.fsf@mocca.josefsson.org> <87k5jy4skb.fsf@gnu.org>
	<24445E26-11FC-479E-8501-8E4516194F52@gmail.com>
	<87ve3h4x2f.fsf@gnu.org> <87r6e5bubw.fsf@mocca.josefsson.org>
	<87prtpsh2v.fsf@gnu.org> <87y78dv53u.fsf@mocca.josefsson.org>
	<87od90clgu.fsf@gnu.org>
Message-ID: <874pabcvq0.fsf@mocca.josefsson.org>

Hi.  I just noticed this bug related to extern inline problems:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466778

If indeed that patch is the right thing to do, couldn't we consider this
gnutls problem a bug in guile?

It would be useful if David could test whether the patch solves the
problem under Mac OS X as well.

I'm sorry if I missed some e-mail with a proposed patch for gnutls, and
that this has already been solved.

/Simon




From ludo at gnu.org  Wed Apr  9 10:25:55 2008
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Wed, 09 Apr 2008 10:25:55 +0200
Subject: [Help-gnutls] Re: duplicate symbols complaint on Mac OS X 10.5.2
References: <922d0b4d0802172330r33f794edu8b968adfee626357@mail.gmail.com>
	<87myp5jltq.fsf@mocca.josefsson.org>
	<D311DE37-F970-43EF-A1AB-394C6E407C16@gmail.com>
	<87myowwf5k.fsf@gnu.org>
	<8FD0D2D5-29C7-4E1B-9FB9-1CCB29E20438@gmail.com>
	<87ve3jn6na.fsf@gnu.org>
	<01646597-495C-4D75-8F65-665209687F06@gmail.com>
	<87d4pqj4zc.fsf@gnu.org>
	<FEB5CC46-BC82-44A6-BB6B-BE7EE1072B71@gmail.com>
	<87od9adag8.fsf@mocca.josefsson.org> <87k5jy4skb.fsf@gnu.org>
	<24445E26-11FC-479E-8501-8E4516194F52@gmail.com>
	<87ve3h4x2f.fsf@gnu.org> <87r6e5bubw.fsf@mocca.josefsson.org>
	<87prtpsh2v.fsf@gnu.org> <87y78dv53u.fsf@mocca.josefsson.org>
	<87od90clgu.fsf@gnu.org> <874pabcvq0.fsf@mocca.josefsson.org>
Message-ID: <87od8jph7w.fsf@gnu.org>

Hi Simon,

Simon Josefsson <simon at josefsson.org> writes:

> Hi.  I just noticed this bug related to extern inline problems:
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466778

That's with GCC 4.3, and a fix is going to appear in the next stable
version of Guile (1.8.5):

  http://git.sv.gnu.org/gitweb/?p=guile.git;a=commitdiff;h=979eade6515559e3590f87f127d21172036f52a6

(Too bad Debian folks don't report bugs upstream...)

Using `-fgnu89-inline' (when available) has essentially the same effect
as this patch.

Furthermore, David is using 4.0, not 4.3:

  http://permalink.gmane.org/gmane.network.gnutls.general/1099

GCC 4.0 does not implement C99 "extern inline", so the problem
encountered by David is actually similar but normally not related to the
"extern inline" semantics change, unless Apple has shipped a patched GCC
for all this time.

Thanks,
Ludovic.





From simon at josefsson.org  Thu Apr 10 08:36:27 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 10 Apr 2008 08:36:27 +0200
Subject: [Help-gnutls] Re: duplicate symbols complaint on Mac OS X 10.5.2
In-Reply-To: <87od8jph7w.fsf@gnu.org> ("Ludovic =?iso-8859-1?Q?Court=E8s?=
	=?iso-8859-1?Q?=22's?= message of "Wed, 09
	Apr 2008 10:25:55 +0200")
References: <922d0b4d0802172330r33f794edu8b968adfee626357@mail.gmail.com>
	<87myp5jltq.fsf@mocca.josefsson.org>
	<D311DE37-F970-43EF-A1AB-394C6E407C16@gmail.com>
	<87myowwf5k.fsf@gnu.org>
	<8FD0D2D5-29C7-4E1B-9FB9-1CCB29E20438@gmail.com>
	<87ve3jn6na.fsf@gnu.org>
	<01646597-495C-4D75-8F65-665209687F06@gmail.com>
	<87d4pqj4zc.fsf@gnu.org>
	<FEB5CC46-BC82-44A6-BB6B-BE7EE1072B71@gmail.com>
	<87od9adag8.fsf@mocca.josefsson.org> <87k5jy4skb.fsf@gnu.org>
	<24445E26-11FC-479E-8501-8E4516194F52@gmail.com>
	<87ve3h4x2f.fsf@gnu.org> <87r6e5bubw.fsf@mocca.josefsson.org>
	<87prtpsh2v.fsf@gnu.org> <87y78dv53u.fsf@mocca.josefsson.org>
	<87od90clgu.fsf@gnu.org> <874pabcvq0.fsf@mocca.josefsson.org>
	<87od8jph7w.fsf@gnu.org>
Message-ID: <87wsn6p66s.fsf@mocca.josefsson.org>

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

> Hi Simon,
>
> Simon Josefsson <simon at josefsson.org> writes:
>
>> Hi.  I just noticed this bug related to extern inline problems:
>>
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466778
>
> That's with GCC 4.3, and a fix is going to appear in the next stable
> version of Guile (1.8.5):
>
>   http://git.sv.gnu.org/gitweb/?p=guile.git;a=commitdiff;h=979eade6515559e3590f87f127d21172036f52a6
>
> (Too bad Debian folks don't report bugs upstream...)

Yeah, I'm amazed they applied a patch like that without talking with
upstream.  Sigh.

> Using `-fgnu89-inline' (when available) has essentially the same effect
> as this patch.
>
> Furthermore, David is using 4.0, not 4.3:
>
>   http://permalink.gmane.org/gmane.network.gnutls.general/1099
>
> GCC 4.0 does not implement C99 "extern inline", so the problem
> encountered by David is actually similar but normally not related to the
> "extern inline" semantics change, unless Apple has shipped a patched GCC
> for all this time.

Which isn't entirely impossible from what I understand, so I'd
appreciate if David could try building Guile with the patch and then
build gnutls.

I'm still not sure whether this is a guile or gnutls problem.  Before
making changes in gnutls to override gnulib's gnu99 default, or adding
thinks like -fgnu89-inline, I want to understand the problem better.
Adding workarounds like that is easy to do, but years later the
workaround often start to cause new problems and it will be difficult to
know what to do.  (Compare the -D_REENTRANT flag..)

Would this problem go away if we removed all 'inline' tags from
functions in GnuTLS?  I don't think a most likely only tiny speed
improvement is worth these problems.

/Simon




From ludo at gnu.org  Thu Apr 10 10:00:03 2008
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Thu, 10 Apr 2008 10:00:03 +0200
Subject: [Help-gnutls] Re: duplicate symbols complaint on Mac OS X 10.5.2
References: <922d0b4d0802172330r33f794edu8b968adfee626357@mail.gmail.com>
	<87myp5jltq.fsf@mocca.josefsson.org>
	<D311DE37-F970-43EF-A1AB-394C6E407C16@gmail.com>
	<87myowwf5k.fsf@gnu.org>
	<8FD0D2D5-29C7-4E1B-9FB9-1CCB29E20438@gmail.com>
	<87ve3jn6na.fsf@gnu.org>
	<01646597-495C-4D75-8F65-665209687F06@gmail.com>
	<87d4pqj4zc.fsf@gnu.org>
	<FEB5CC46-BC82-44A6-BB6B-BE7EE1072B71@gmail.com>
	<87od9adag8.fsf@mocca.josefsson.org> <87k5jy4skb.fsf@gnu.org>
	<24445E26-11FC-479E-8501-8E4516194F52@gmail.com>
	<87ve3h4x2f.fsf@gnu.org> <87r6e5bubw.fsf@mocca.josefsson.org>
	<87prtpsh2v.fsf@gnu.org> <87y78dv53u.fsf@mocca.josefsson.org>
	<87od90clgu.fsf@gnu.org> <874pabcvq0.fsf@mocca.josefsson.org>
	<87od8jph7w.fsf@gnu.org> <87wsn6p66s.fsf@mocca.josefsson.org>
Message-ID: <87r6degmws.fsf@gnu.org>

Hi,

Simon Josefsson <simon at josefsson.org> writes:

> I'm still not sure whether this is a guile or gnutls problem.  Before
> making changes in gnutls to override gnulib's gnu99 default, or adding
> thinks like -fgnu89-inline, I want to understand the problem better.
> Adding workarounds like that is easy to do, but years later the
> workaround often start to cause new problems and it will be difficult to
> know what to do.  (Compare the -D_REENTRANT flag..)
>
> Would this problem go away if we removed all 'inline' tags from
> functions in GnuTLS?

No.  What happens is that GMP declares/defines various functions as
"extern inline" and expects the GNU semantics [0].  It properly guards
against the C99 semantic change (at least GMP 4.2.2 does) using the
recommended method [1].

However, it all looks as though Apple's GCC implemented C99 "extern
inline" without defining `__GNUC_STDC_INLINE__', thereby defeating said
method.

A useful code snippet seems to confirm this hypothesis:

  https://svn.r-project.org/R/trunk/src/include/Rinlinedfuns.h

  /* Apple's gcc build >5400 (since Xcode 3.0) doesn't support GNU inline in C99 mode */
  #if __APPLE_CC__ > 5400 && !defined(C99_INLINE_SEMANTICS) && __STDC_VERSION__ >= 199901L
  #define C99_INLINE_SEMANTICS 1
  #endif

So I suppose GMP and Guile just have to go ahead and duplicate this?

Thanks,
Ludovic.

[0] A nice summary of the "extern inline" mess:
    http://gcc.gnu.org/ml/gcc/2006-11/msg00006.html .

[1] http://gcc.gnu.org/gcc-4.3/porting_to.html





From simon at josefsson.org  Thu Apr 10 10:35:53 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 10 Apr 2008 10:35:53 +0200
Subject: [Help-gnutls] Re: duplicate symbols complaint on Mac OS X 10.5.2
In-Reply-To: <87r6degmws.fsf@gnu.org> ("Ludovic =?iso-8859-1?Q?Court=E8s?=
	=?iso-8859-1?Q?=22's?= message of "Thu, 10
	Apr 2008 10:00:03 +0200")
References: <922d0b4d0802172330r33f794edu8b968adfee626357@mail.gmail.com>
	<87myp5jltq.fsf@mocca.josefsson.org>
	<D311DE37-F970-43EF-A1AB-394C6E407C16@gmail.com>
	<87myowwf5k.fsf@gnu.org>
	<8FD0D2D5-29C7-4E1B-9FB9-1CCB29E20438@gmail.com>
	<87ve3jn6na.fsf@gnu.org>
	<01646597-495C-4D75-8F65-665209687F06@gmail.com>
	<87d4pqj4zc.fsf@gnu.org>
	<FEB5CC46-BC82-44A6-BB6B-BE7EE1072B71@gmail.com>
	<87od9adag8.fsf@mocca.josefsson.org> <87k5jy4skb.fsf@gnu.org>
	<24445E26-11FC-479E-8501-8E4516194F52@gmail.com>
	<87ve3h4x2f.fsf@gnu.org> <87r6e5bubw.fsf@mocca.josefsson.org>
	<87prtpsh2v.fsf@gnu.org> <87y78dv53u.fsf@mocca.josefsson.org>
	<87od90clgu.fsf@gnu.org> <874pabcvq0.fsf@mocca.josefsson.org>
	<87od8jph7w.fsf@gnu.org> <87wsn6p66s.fsf@mocca.josefsson.org>
	<87r6degmws.fsf@gnu.org>
Message-ID: <87fxtup0nq.fsf@mocca.josefsson.org>

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

> Hi,
>
> Simon Josefsson <simon at josefsson.org> writes:
>
>> I'm still not sure whether this is a guile or gnutls problem.  Before
>> making changes in gnutls to override gnulib's gnu99 default, or adding
>> thinks like -fgnu89-inline, I want to understand the problem better.
>> Adding workarounds like that is easy to do, but years later the
>> workaround often start to cause new problems and it will be difficult to
>> know what to do.  (Compare the -D_REENTRANT flag..)
>>
>> Would this problem go away if we removed all 'inline' tags from
>> functions in GnuTLS?
>
> No.  What happens is that GMP declares/defines various functions as
> "extern inline" and expects the GNU semantics [0].  It properly guards
> against the C99 semantic change (at least GMP 4.2.2 does) using the
> recommended method [1].

Thanks, I now understand this better.  I'll ask if gnulib can stop
placing the compiler in gnu99 mode by default, it seems that is only
done for some rather esoteric problem.

>   /* Apple's gcc build >5400 (since Xcode 3.0) doesn't support GNU inline in C99 mode */
>   #if __APPLE_CC__ > 5400 && !defined(C99_INLINE_SEMANTICS) && __STDC_VERSION__ >= 199901L
>   #define C99_INLINE_SEMANTICS 1
>   #endif
>
> So I suppose GMP and Guile just have to go ahead and duplicate this?

Or ask Apple to fix their compiler.  Isn't it possible to build gcc on
mac os x manually?  Then it wouldn't have this problem, I guess.

/Simon




From ludo at gnu.org  Thu Apr 10 14:48:35 2008
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Thu, 10 Apr 2008 14:48:35 +0200
Subject: [Help-gnutls] Re: duplicate symbols complaint on Mac OS X 10.5.2
References: <922d0b4d0802172330r33f794edu8b968adfee626357@mail.gmail.com>
	<D311DE37-F970-43EF-A1AB-394C6E407C16@gmail.com>
	<87myowwf5k.fsf@gnu.org>
	<8FD0D2D5-29C7-4E1B-9FB9-1CCB29E20438@gmail.com>
	<87ve3jn6na.fsf@gnu.org>
	<01646597-495C-4D75-8F65-665209687F06@gmail.com>
	<87d4pqj4zc.fsf@gnu.org>
	<FEB5CC46-BC82-44A6-BB6B-BE7EE1072B71@gmail.com>
	<87od9adag8.fsf@mocca.josefsson.org> <87k5jy4skb.fsf@gnu.org>
	<24445E26-11FC-479E-8501-8E4516194F52@gmail.com>
	<87ve3h4x2f.fsf@gnu.org> <87r6e5bubw.fsf@mocca.josefsson.org>
	<87prtpsh2v.fsf@gnu.org> <87y78dv53u.fsf@mocca.josefsson.org>
	<87od90clgu.fsf@gnu.org> <874pabcvq0.fsf@mocca.josefsson.org>
	<87od8jph7w.fsf@gnu.org> <87wsn6p66s.fsf@mocca.josefsson.org>
	<87r6degmws.fsf@gnu.org> <87fxtup0nq.fsf@mocca.josefsson.org>
Message-ID: <87od8h98po.fsf@gnu.org>

Hi,

Simon Josefsson <simon at josefsson.org> writes:

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

>> Simon Josefsson <simon at josefsson.org> writes:
>>
>>> I'm still not sure whether this is a guile or gnutls problem.  Before
>>> making changes in gnutls to override gnulib's gnu99 default, or adding
>>> thinks like -fgnu89-inline, I want to understand the problem better.
>>> Adding workarounds like that is easy to do, but years later the
>>> workaround often start to cause new problems and it will be difficult to
>>> know what to do.  (Compare the -D_REENTRANT flag..)

BTW, `-fgnu89-inline' will always be needed for the GnuTLS Guile code
anyway, because even if we fix it in Guile and GMP, there will always be
people trying to compile GnuTLS with a version of Guile and/or GMP that
doesn't have the fix.

> Or ask Apple to fix their compiler.  Isn't it possible to build gcc on
> mac os x manually?  Then it wouldn't have this problem, I guess.

I suppose there won't be any problem when they ship their OS with GCC
4.3 but in the meantime, we either have to implement the above fix or to
impede our software's portability as a sign of disagreement with Apple's
silliness.  I guess it's easier to stick to the former.  ;-)

(Of course, another option is to not build GnuTLS in C99 mode...)

Thanks,
Ludovic.





From dbreiser at gmail.com  Thu Apr 10 14:53:59 2008
From: dbreiser at gmail.com (David Reiser)
Date: Thu, 10 Apr 2008 08:53:59 -0400
Subject: [Help-gnutls] Re: duplicate symbols complaint on Mac OS X 10.5.2
In-Reply-To: <87fxtup0nq.fsf@mocca.josefsson.org>
References: <922d0b4d0802172330r33f794edu8b968adfee626357@mail.gmail.com>
	<87myp5jltq.fsf@mocca.josefsson.org>
	<D311DE37-F970-43EF-A1AB-394C6E407C16@gmail.com>
	<87myowwf5k.fsf@gnu.org>
	<8FD0D2D5-29C7-4E1B-9FB9-1CCB29E20438@gmail.com>
	<87ve3jn6na.fsf@gnu.org>
	<01646597-495C-4D75-8F65-665209687F06@gmail.com>
	<87d4pqj4zc.fsf@gnu.org>
	<FEB5CC46-BC82-44A6-BB6B-BE7EE1072B71@gmail.com>
	<87od9adag8.fsf@mocca.josefsson.org> <87k5jy4skb.fsf@gnu.org>
	<24445E26-11FC-479E-8501-8E4516194F52@gmail.com>
	<87ve3h4x2f.fsf@gnu.org> <87r6e5bubw.fsf@mocca.josefsson.org>
	<87prtpsh2v.fsf@gnu.org> <87y78dv53u.fsf@mocca.josefsson.org>
	<87od90clgu.fsf@gnu.org> <874pabcvq0.fsf@mocca.josefsson.org>
	<87od8jph7w.fsf@gnu.org> <87wsn6p66s.fsf@mocca.josefsson.org>
	<87r6degmws.fsf@gnu.org> <87fxtup0nq.fsf@mocca.josefsson.org>
Message-ID: <06A37F46-EDC1-4984-9198-ABC5507F0357@gmail.com>


On Apr 10, 2008, at 4:35 AM, Simon Josefsson wrote:

> ludo at gnu.org (Ludovic Court?s) writes:
>
>> [...]

>> /* Apple's gcc build >5400 (since Xcode 3.0) doesn't support GNU  
>> inline in C99 mode */
>>  #if __APPLE_CC__ > 5400 && !defined(C99_INLINE_SEMANTICS) &&  
>> __STDC_VERSION__ >= 199901L
>>  #define C99_INLINE_SEMANTICS 1
>>  #endif
>>
>> So I suppose GMP and Guile just have to go ahead and duplicate this?
>
> Or ask Apple to fix their compiler.  Isn't it possible to build gcc on
> mac os x manually?  Then it wouldn't have this problem, I guess.

Considering that Apple stayed with gcc 4.0.1 when system 10.5 was  
released last fall, I'm not so sure they'll respond to such requests,  
and we'll certainly never know until they release a new xcode whether  
or not they listened.

fink has gcc 4.3 (and 4.2) available, but they takes so long to  
compile, and have potential compatibility problems with older  
packages, that requiring one of them would be an unusual solution. The  
main reason the newer compilers are available is that apple didn't  
include a fortran compiler with their gcc, so some of the scientific  
packages have to use something other than apple's gcc.

I'll try the guile patch. It will take at least a few days for me to  
get to it.

Thanks for the continued help.

Dave
--
David Reiser
dbreiser at gmail.com







From simon at josefsson.org  Thu Apr 10 15:26:43 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 10 Apr 2008 15:26:43 +0200
Subject: [Help-gnutls] Re: duplicate symbols complaint on Mac OS X 10.5.2
In-Reply-To: <87od8h98po.fsf@gnu.org> ("Ludovic =?iso-8859-1?Q?Court=E8s?=
	=?iso-8859-1?Q?=22's?= message of "Thu, 10
	Apr 2008 14:48:35 +0200")
References: <922d0b4d0802172330r33f794edu8b968adfee626357@mail.gmail.com>
	<87myowwf5k.fsf@gnu.org>
	<8FD0D2D5-29C7-4E1B-9FB9-1CCB29E20438@gmail.com>
	<87ve3jn6na.fsf@gnu.org>
	<01646597-495C-4D75-8F65-665209687F06@gmail.com>
	<87d4pqj4zc.fsf@gnu.org>
	<FEB5CC46-BC82-44A6-BB6B-BE7EE1072B71@gmail.com>
	<87od9adag8.fsf@mocca.josefsson.org> <87k5jy4skb.fsf@gnu.org>
	<24445E26-11FC-479E-8501-8E4516194F52@gmail.com>
	<87ve3h4x2f.fsf@gnu.org> <87r6e5bubw.fsf@mocca.josefsson.org>
	<87prtpsh2v.fsf@gnu.org> <87y78dv53u.fsf@mocca.josefsson.org>
	<87od90clgu.fsf@gnu.org> <874pabcvq0.fsf@mocca.josefsson.org>
	<87od8jph7w.fsf@gnu.org> <87wsn6p66s.fsf@mocca.josefsson.org>
	<87r6degmws.fsf@gnu.org> <87fxtup0nq.fsf@mocca.josefsson.org>
	<87od8h98po.fsf@gnu.org>
Message-ID: <87zls1c030.fsf@mocca.josefsson.org>

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

> Hi,
>
> Simon Josefsson <simon at josefsson.org> writes:
>
>> ludo at gnu.org (Ludovic Court?s) writes:
>
>>> Simon Josefsson <simon at josefsson.org> writes:
>>>
>>>> I'm still not sure whether this is a guile or gnutls problem.  Before
>>>> making changes in gnutls to override gnulib's gnu99 default, or adding
>>>> thinks like -fgnu89-inline, I want to understand the problem better.
>>>> Adding workarounds like that is easy to do, but years later the
>>>> workaround often start to cause new problems and it will be difficult to
>>>> know what to do.  (Compare the -D_REENTRANT flag..)
>
> BTW, `-fgnu89-inline' will always be needed for the GnuTLS Guile code
> anyway, because even if we fix it in Guile and GMP, there will always be
> people trying to compile GnuTLS with a version of Guile and/or GMP that
> doesn't have the fix.
>
>> Or ask Apple to fix their compiler.  Isn't it possible to build gcc on
>> mac os x manually?  Then it wouldn't have this problem, I guess.
>
> I suppose there won't be any problem when they ship their OS with GCC
> 4.3 but in the meantime, we either have to implement the above fix or to
> impede our software's portability as a sign of disagreement with Apple's
> silliness.  I guess it's easier to stick to the former.  ;-)

Right.

> (Of course, another option is to not build GnuTLS in C99 mode...)

We'll see what my question on the gnulib list leads too..

http://lists.gnu.org/archive/html/bug-gnulib/2008-04/msg00079.html

/Simon




From rgerhards at gmail.com  Thu Apr 10 18:06:40 2008
From: rgerhards at gmail.com (Rainer Gerhards)
Date: Thu, 10 Apr 2008 18:06:40 +0200
Subject: [Help-gnutls] Beginner's question
Message-ID: <dc67eef70804100906g3042f217k91c11a26f36dc9a4@mail.gmail.com>

Hi there,

I have just begun looking at GNUTls. I intend to implement TLS for my
rsyslog project - http://www.rsyslog.com (a GPLed replacement
syslogd).  I am currently developing on Fedora 8 with GNUTls 1.6.3. I
obtained and compiled the sample programs. However, I do not have any
pem files and intended to create them via the steps outlined in

http://www.gnu.org/software/gnutls/manual/gnutls/gnutls.html#SECTION00930000000000000000

For my last try, I did exactly follow the steps on that page, from top
to bottom. When I now run certtool --certificate-info, I get good info
on ca-cert.pem, but for cert.pem I always just get "Decoding error:
Base64 decoding error." (and of course the same happens inside my
simple server).

Any advise on what I am doing wrong would be deeply appreciated.

Many thanks,
Rainer




From simon at josefsson.org  Fri Apr 11 14:36:16 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 11 Apr 2008 14:36:16 +0200
Subject: [Help-gnutls] Re: Beginner's question
In-Reply-To: <dc67eef70804100906g3042f217k91c11a26f36dc9a4@mail.gmail.com>
	(Rainer Gerhards's message of "Thu, 10 Apr 2008 18:06:40 +0200")
References: <dc67eef70804100906g3042f217k91c11a26f36dc9a4@mail.gmail.com>
Message-ID: <87prsw36wv.fsf@mocca.josefsson.org>

"Rainer Gerhards" <rgerhards at gmail.com> writes:

> Hi there,
>
> I have just begun looking at GNUTls. I intend to implement TLS for my
> rsyslog project - http://www.rsyslog.com (a GPLed replacement
> syslogd).  I am currently developing on Fedora 8 with GNUTls 1.6.3. I
> obtained and compiled the sample programs. However, I do not have any
> pem files and intended to create them via the steps outlined in
>
> http://www.gnu.org/software/gnutls/manual/gnutls/gnutls.html#SECTION00930000000000000000
>
> For my last try, I did exactly follow the steps on that page, from top
> to bottom. When I now run certtool --certificate-info, I get good info
> on ca-cert.pem, but for cert.pem I always just get "Decoding error:
> Base64 decoding error." (and of course the same happens inside my
> simple server).
>
> Any advise on what I am doing wrong would be deeply appreciated.

Could you attache the cert.pem file?

/Simon




From simon at josefsson.org  Fri Apr 11 15:09:10 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 11 Apr 2008 15:09:10 +0200
Subject: [Help-gnutls] Re: Beginner's question
In-Reply-To: <dc67eef70804110553p1349b6d1rb1be4a18d89fc3be@mail.gmail.com>
	(Rainer Gerhards's message of "Fri, 11 Apr 2008 14:53:03 +0200")
References: <dc67eef70804100906g3042f217k91c11a26f36dc9a4@mail.gmail.com>
	<87prsw36wv.fsf@mocca.josefsson.org>
	<dc67eef70804110553p1349b6d1rb1be4a18d89fc3be@mail.gmail.com>
Message-ID: <87iqyo35e1.fsf@mocca.josefsson.org>

"Rainer Gerhards" <rgerhards at gmail.com> writes:

> I will generate a new one and record what I am doing. In the mean
> time, I've also found the sample .pem's inside the tarball (which I
> now downloaded). But, of course, I need to know how to generate the
> required files.
>
> Thanks again for your help, will post shortly...

No problem.  For example credentials, see also:

http://www.gnu.org/software/gnutls/server.html
http://www.gnu.org/software/gnutls/test-credentials/

Btw, if you are going to make rsylog use gnutls you might want to
download the gnutls tar ball and build it.

/Simon

> Rainer
>
> On Fri, Apr 11, 2008 at 2:36 PM, Simon Josefsson <simon at josefsson.org> wrote:
>>
>> "Rainer Gerhards" <rgerhards at gmail.com> writes:
>>
>>  > Hi there,
>>  >
>>  > I have just begun looking at GNUTls. I intend to implement TLS for my
>>  > rsyslog project - http://www.rsyslog.com (a GPLed replacement
>>  > syslogd).  I am currently developing on Fedora 8 with GNUTls 1.6.3. I
>>  > obtained and compiled the sample programs. However, I do not have any
>>  > pem files and intended to create them via the steps outlined in
>>  >
>>  > http://www.gnu.org/software/gnutls/manual/gnutls/gnutls.html#SECTION00930000000000000000
>>  >
>>  > For my last try, I did exactly follow the steps on that page, from top
>>  > to bottom. When I now run certtool --certificate-info, I get good info
>>  > on ca-cert.pem, but for cert.pem I always just get "Decoding error:
>>  > Base64 decoding error." (and of course the same happens inside my
>>  > simple server).
>>  >
>>  > Any advise on what I am doing wrong would be deeply appreciated.
>>
>>  Could you attache the cert.pem file?
>>
>>  /Simon
>>




From simon at josefsson.org  Fri Apr 11 16:57:57 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 11 Apr 2008 16:57:57 +0200
Subject: [Help-gnutls] Re: Beginner's question
In-Reply-To: <dc67eef70804110720u27c50e35qfc4fdf867f1164d2@mail.gmail.com>
	(Rainer Gerhards's message of "Fri, 11 Apr 2008 16:20:58 +0200")
References: <dc67eef70804100906g3042f217k91c11a26f36dc9a4@mail.gmail.com>
	<87prsw36wv.fsf@mocca.josefsson.org>
	<dc67eef70804110553p1349b6d1rb1be4a18d89fc3be@mail.gmail.com>
	<87iqyo35e1.fsf@mocca.josefsson.org>
	<dc67eef70804110720u27c50e35qfc4fdf867f1164d2@mail.gmail.com>
Message-ID: <877if4v3pm.fsf@mocca.josefsson.org>

"Rainer Gerhards" <rgerhards at gmail.com> writes:

> On Fri, Apr 11, 2008 at 3:09 PM, Simon Josefsson <simon at josefsson.org> wrote:
>> "Rainer Gerhards" <rgerhards at gmail.com> writes:
>>
>>
>> > I will generate a new one and record what I am doing. In the mean
>>  > time, I've also found the sample .pem's inside the tarball (which I
>>  > now downloaded). But, of course, I need to know how to generate the
>>  > required files.
>>  >
>>  > Thanks again for your help, will post shortly...
>>
>
> umm... it looks like I screwed up yesterday. I "re"-did everything and
> now I don't get the base64 error. I will investigate, but it looks
> like all is well.

The base64 error is pretty general, so any kind of data corruption in
the PEM file would likely trigger it.

>>  No problem.  For example credentials, see also:
>>
>>  http://www.gnu.org/software/gnutls/server.html
>>  http://www.gnu.org/software/gnutls/test-credentials/
>>
>>  Btw, if you are going to make rsylog use gnutls you might want to
>>  download the gnutls tar ball and build it.
>
> I've actually tried with the package that is on the system because I
> do not want rsyslog to depend on anything that's not there by default.
> Being the syslogd and intending to recommend the use of TLS, I must be
> very careful to not pull too much in that's not already there. In
> essence, all of that would need to be present on *every* system and
> that would definitely be a burden. So I thought I stick with the
> default.

Sure.  I was mostly thinking about compiling with debugging symbols, but
on second thought most application programmers probably won't find
gnutls symbols useful anyway...

> BTW: the documentation and samples are really helpful. GnuTLS also
> seems to have (as far as I understand) a very clean API. I struggled a
> while with openssl in the past and GnuTLS is *much* cleaner. Very good
> work :)

Thanks!  Let us know if there is anything we could improve to help
explain something that you get stuck on.  It is easy to go blind in a
project, so input from new users are very valuable.

Btw, please cc the list so that the discussion is archived.

/Simon




From rgerhards at gmail.com  Fri Apr 11 17:03:08 2008
From: rgerhards at gmail.com (Rainer Gerhards)
Date: Fri, 11 Apr 2008 17:03:08 +0200
Subject: [Help-gnutls] Re: Beginner's question
In-Reply-To: <877if4v3pm.fsf@mocca.josefsson.org>
References: <dc67eef70804100906g3042f217k91c11a26f36dc9a4@mail.gmail.com>
	<87prsw36wv.fsf@mocca.josefsson.org>
	<dc67eef70804110553p1349b6d1rb1be4a18d89fc3be@mail.gmail.com>
	<87iqyo35e1.fsf@mocca.josefsson.org>
	<dc67eef70804110720u27c50e35qfc4fdf867f1164d2@mail.gmail.com>
	<877if4v3pm.fsf@mocca.josefsson.org>
Message-ID: <dc67eef70804110803j100d6110q30751cebb3f0254c@mail.gmail.com>

>  Thanks!  Let us know if there is anything we could improve to help
>  explain something that you get stuck on.  It is easy to go blind in a
>  project, so input from new users are very valuable.

There is one thing, if I may hijack this thread. The CRL files. I know
what certificate revocation is for, but I do not fully understand how
the CRL functions are used. Most importantly, do I need to create that
file and, if so, how? I know that's all pretty basic and I appreciate
your help on those boring questions ;).

>
>  Btw, please cc the list so that the discussion is archived.

Thanks for the reminder. I just started to use gmail for list traffic,
and I tend to forget the reply all in Google's interface ;)

Rainer




From massimo.gaspari at alice.it  Fri Apr 11 20:24:03 2008
From: massimo.gaspari at alice.it (Massimo Gaspari)
Date: Fri, 11 Apr 2008 20:24:03 +0200
Subject: [Help-gnutls] gnutls 2.3.4 doesn't copile using MinGW
Message-ID: <47FFACC3.7010400@alice.it>

Hi all,

I am trying to get gntls compiled on a Windows XP SP2 with mingw (Gcc 
4.2.1 , + Msys 1.0).

I compiled without issues zlib 1.2.3 , libgpg-error 1.6 and libgcrypt 
1.4.0. The latest one using

./configure --disable-shared --disable-asm --disable-dev-random


Now gnutls. I used

./configure --disable-shared --disable-rpath --disable-cxx --disable-guile

and then make. But the compilation stopped with


libtool: link: ( cd ".libs" && rm -f "libgnutls.la" && cp -p 
"../libgnutls.la" "libgnutls.la" )
make[3]: *** No rule to make target `libgnutls-26.def', needed by 
`all-am'.  Stop.
make[3]: Leaving directory `/home/emasgas/gnutls-2.3.4/lib'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/emasgas/gnutls-2.3.4/lib'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/emasgas/gnutls-2.3.4'
make: *** [all] Error

Any suggestion? Does gnutls compile on MinGW? Any help will be appreciated.

Thanks

Massimo


Hereafter the output from the .configure command.

checking build system type... i686-pc-mingw32
checking host system type... i686-pc-mingw32
checking target system type... i686-pc-mingw32
checking for a BSD-compatible install... /bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
configure: autobuild project... GnuTLS
configure: autobuild revision... 2.3.4
./configure: hostname: command not found
configure: autobuild timestamp... 20080411-152025
checking whether in dmalloc mode... no
checking whether in electric fence mode... no
checking whether in developer mode... no
checking whether in profile mode... no
***
*** Checking for compilation programs...

checking for gcc... gcc
checking for C compiler default output file name... a.exe
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... .exe
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking whether ln -s works... no, using cp -p
checking for pkg-config... no
checking whether to build gtk-doc documentation... no
checking for gtkdoc-check... no
checking for gaa... no
configure: WARNING: ***
*** GAA was not found.  It is only needed if you wish to modify
*** the source code or command-line description files.  In this case,
*** you may want to get it from http://gaa.sourceforge.net/
***
***
*** Detecting compiler options...

checking for ranlib... ranlib
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking for _LARGEFILE_SOURCE value needed for large files... unknown
checking for gcc option to accept ISO C99... -std=gnu99
checking for gcc -std=gnu99 option to accept ISO Standard C... (cached) 
-std=gnu99
checking for an ANSI C-conforming const... yes
checking for inline... inline
checking whether NLS is requested... yes
checking for msgfmt... no
checking for gmsgfmt... :
checking for xgettext... no
checking for msgmerge... no
checking for ld used by GCC... c:/mingw/mingw32/bin/ld.exe
checking if the linker (c:/mingw/mingw32/bin/ld.exe) is GNU ld... yes
checking for shared library run path origin... done
checking for CFPreferencesCopyAppValue... no
checking for CFLocaleCopyCurrent... no
checking for GNU gettext in libc... no
checking for iconv... no, consider installing GNU libiconv
checking for GNU gettext in libintl... no
checking whether to use NLS... no
checking whether to build C++ library... no
checking whether C99 macros are supported... yes
checking if gcc supports -Wno-pointer-sign... yes
checking if gcc/ld supports -Wl,--output-def... yes
checking whether we have GNU assembler... yes
***
*** Detecting C library capabilities...

checking for ANSI C header files... (cached) yes
checking for strings.h... (cached) yes
checking alloca.h usability... no
checking alloca.h presence... no
checking for alloca.h... no
checking errno.h usability... yes
checking errno.h presence... yes
checking for errno.h... yes
checking math.h usability... yes
checking math.h presence... yes
checking for math.h... yes
checking limits.h usability... yes
checking limits.h presence... yes
checking for limits.h... yes
checking float.h usability... yes
checking float.h presence... yes
checking for float.h... yes
checking stdarg.h usability... yes
checking stdarg.h presence... yes
checking for stdarg.h... yes
checking ctype.h usability... yes
checking ctype.h presence... yes
checking for ctype.h... yes
checking netdb.h usability... no
checking netdb.h presence... no
checking for netdb.h... no
checking for umask... yes
checking for vasprintf... no
checking for isascii... yes
checking for fork... no
checking for working alloca.h... no
checking for alloca... yes
***
*** Detecting system's parameters...

checking for valgrind... no
checking whether self tests are run under valgrind... no
checking for unsigned long int... yes
checking size of unsigned long int... 4
checking for unsigned int... yes
checking size of unsigned int... 4
checking for void *... yes
checking size of void *... 4
checking for long... yes
checking size of long... 4
checking for int... yes
checking size of int... 4
checking for uint... no
checking for ssize_t... yes
checking whether byte ordering is bigendian... no
***
*** Checking for external libraries...

checking whether building Guile bindings... no
checking for libgcrypt-config... /usr/local/bin/libgcrypt-config
checking for LIBGCRYPT - version >= 1.2.4... yes
checking LIBGCRYPT API version... okay
checking whether to enable Opaque PRF input support... no
checking whether to disable SRP authentication support... no
checking whether to disable PSK authentication support... no
checking whether to disable anonymous authentication support... no
checking for Camellia support in libgcrypt... yes
checking whether to disable Camellia cipher... no
checking whether to disable extra PKI stuff... no
checking whether to disable OpenPGP Certificate authentication support... no
checking whether to disable OpenSSL compatibility layer... no
checking for libtasn1-config... no
checking for libtasn1 - version >= 0.3.4... no
*** The libtasn1-config script installed by LIBTASN1 could not be found
*** If LIBTASN1 was installed in PREFIX, make sure PREFIX/bin is in
*** your path, or set the LIBTASN1_CONFIG environment variable to the
*** full path to libtasn1-config.
configure: WARNING:
***
*** LibtASN1 0.3.4 was not found. Will use the included one.

checking whether to use the included minitasn1... yes
checking for cfg_get_context in -lcfg+... no
configure: WARNING:
***
*** Libcfg+ was not found. Will use the included one.
checking whether to use the included libcfg... yes
checking whether to include zlib compression support... yes
checking for libz... yes
checking how to link with libz... -lz
checking whether to include LZO compression support... no
***
*** Setting up gnulib compatibility files...

checking arpa/inet.h usability... no
checking arpa/inet.h presence... no
checking for arpa/inet.h... no
checking sys/socket.h usability... no
checking sys/socket.h presence... no
checking for sys/socket.h... no
checking for netdb.h... (cached) no
checking netinet/in.h usability... no
checking netinet/in.h presence... no
checking for netinet/in.h... no
checking stdio_ext.h usability... no
checking stdio_ext.h presence... no
checking for stdio_ext.h... no
checking termios.h usability... no
checking termios.h presence... no
checking for termios.h... no
checking for stdarg.h... (cached) yes
checking for float.h... (cached) yes
checking for stdint.h... (cached) yes
checking wchar.h usability... yes
checking wchar.h presence... yes
checking for wchar.h... yes
checking stdio.h usability... yes
checking stdio.h presence... yes
checking for stdio.h... yes
checking for stdlib.h... (cached) yes
checking for string.h... (cached) yes
checking for sys/stat.h... (cached) yes
checking time.h usability... yes
checking time.h presence... yes
checking for time.h... yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking for unistd.h... (cached) yes
checking whether strerror_r is declared... no
checking for strerror_r... no
checking whether strerror_r returns char *... no
checking whether stdin defaults to large file offsets... yes
checking whether the preprocessor supports include_next... yes
checking whether <sys/socket.h> is self-contained... no
checking winsock2.h usability... yes
checking winsock2.h presence... yes
checking for winsock2.h... yes
checking ws2tcpip.h usability... yes
checking ws2tcpip.h presence... yes
checking for ws2tcpip.h... yes
checking for C/C++ restrict keyword... __restrict
checking for IPv4 sockets... yes
checking for IPv6 sockets... no
checking whether getdelim is declared... no
checking whether getline is declared... no
checking whether getpass is declared... no
checking for __fsetlocking... no
checking for tcgetattr... no
checking for tcsetattr... no
checking for lstat... no
checking for vasnprintf... no
checking whether fflush_unlocked is declared... no
checking whether flockfile is declared... no
checking whether fputs_unlocked is declared... no
checking whether funlockfile is declared... no
checking whether putc_unlocked is declared... no
checking whether strdup is declared... yes
checking for working strerror function... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for error_at_line... no
checking for fseeko... no
configure: checking how to do getaddrinfo, freeaddrinfo and getnameinfo
checking for library containing getaddrinfo... no
checking for getaddrinfo... no
checking for getaddrinfo in ws2tcpip.h and -lws2_32... no
checking for gai_strerror (possibly via ws2tcpip.h)... yes
checking for library containing gethostbyname... no
checking for library containing getservbyname... no
checking for gethostbyname... no
checking for gethostbyname in winsock2.h and -lws2_32... yes
checking whether getaddrinfo is declared... no
checking whether freeaddrinfo is declared... no
checking whether gai_strerror is declared... yes
checking whether getnameinfo is declared... no
checking for struct addrinfo... yes
checking for getdelim... no
checking for flockfile... no
checking for funlockfile... no
checking for getline... no
checking for getdelim... (cached) no
checking for flockfile... (cached) no
checking for funlockfile... (cached) no
checking for getpass... no
checking whether __fsetlocking is declared... no
checking for inet_ntop... no
checking whether inet_ntop is declared... no
checking for inet_pton... no
checking whether inet_pton is declared... no
checking whether lseek detects pipes... no
checking whether <netinet/in.h> is self-contained... no
checking for netinet/in.h... (cached) no
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for readline... no
checking readline/readline.h usability... no
checking readline/readline.h presence... no
checking for readline/readline.h... no
checking for socklen_t... yes
checking for va_copy... yes
checking for strdup... yes
checking whether memmem is declared... no
checking whether <limits.h> defines MIN and MAX... no
checking whether <sys/param.h> defines MIN and MAX... no
checking whether malloc, realloc, calloc are POSIX compliant... no
checking whether snprintf is declared... yes
checking for stdbool.h that conforms to C99... yes
checking for _Bool... yes
checking for long long int... yes
checking for unsigned long long int... yes
checking whether stat file-mode macros are broken... no
checking for struct timespec in <time.h>... no
checking for struct timespec in <sys/time.h>... no
checking for EOVERFLOW... E2BIG
checking for wchar_t... yes
checking for wint_t... yes
checking for size_t... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for intmax_t... yes
checking for camellia in libgcrypt... no
checking device with (strong) random data...... /dev/random
checking device with pseudo random data...... /dev/urandom
checking device with unpredictable data for nonces...... /dev/urandom
checking for /dev/random... yes
checking for /dev/urandom... yes
checking for /dev/urandom... (cached) yes
checking whether __func__ is available... yes
checking for memchr... yes
checking for working memcmp... yes
checking for memmem... no
checking for memmove... yes
checking for stdint.h... (cached) yes
checking for SIZE_MAX... yes
checking for snprintf... yes
checking for socklen_t... (cached) yes
checking whether stdint.h conforms to C99... yes
checking for strverscmp... no
checking whether <sys/socket.h> is self-contained... (cached) no
checking for winsock2.h... (cached) yes
checking for ws2tcpip.h... (cached) yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking whether mkdir is declared... no
checking io.h usability... yes
checking io.h presence... yes
checking for io.h... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking whether localtime_r is compatible with its POSIX signature... no
checking for ptrdiff_t... yes
checking for snprintf... (cached) yes
checking for wcslen... yes
checking whether _snprintf is declared... yes
checking for vasprintf... (cached) no
checking whether <wchar.h> is standalone... yes
checking for stdint.h... (cached) yes
checking if we have Windows sockets and WSAStartup/WSACleanup... yes
***
*** Detecting options for shared libraries...

checking for as... as
checking for dlltool... dlltool
checking for objdump... objdump
checking for a sed that does not truncate output... /bin/sed
checking for fgrep... /bin/grep -F
checking for ld used by gcc -std=gnu99... c:/mingw/mingw32/bin/ld.exe
checking if the linker (c:/mingw/mingw32/bin/ld.exe) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /mingw/bin/nm
checking the name lister (/mingw/bin/nm) interface... BSD nm
checking the maximum length of command line arguments... 8192
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... no
checking for c:/mingw/mingw32/bin/ld.exe option to reload object files... -r
checking how to recognize dependent libraries... file_magic file format 
pei*-i386(.*architecture: i386)?
checking for ar... ar
checking for strip... strip
checking for ranlib... (cached) ranlib
checking command to parse /mingw/bin/nm output from gcc -std=gnu99 
object... ok
checking for dlfcn.h... no
checking whether we are using the GNU C++ compiler... (cached) yes
checking whether g++ accepts -g... (cached) yes
checking dependency style of g++... (cached) gcc3
checking how to run the C++ preprocessor... g++ -E
checking for objdir... .libs
checking if gcc -std=gnu99 supports -fno-rtti -fno-exceptions... no
checking for gcc -std=gnu99 option to produce PIC... -DDLL_EXPORT -DPIC
checking if gcc -std=gnu99 PIC flag -DDLL_EXPORT -DPIC works... yes
checking if gcc -std=gnu99 static flag -static works... yes
checking if gcc -std=gnu99 supports -c -o file.o... yes
checking if gcc -std=gnu99 supports -c -o file.o... (cached) yes
checking whether the gcc -std=gnu99 linker (c:/mingw/mingw32/bin/ld.exe) 
supports shared libraries... yes
checking dynamic linker characteristics... Win32 ld.exe
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... no
checking whether to build static libraries... yes
checking for ld used by g++... c:/mingw/mingw32/bin/ld.exe
checking if the linker (c:/mingw/mingw32/bin/ld.exe) is GNU ld... yes
checking whether the g++ linker (c:/mingw/mingw32/bin/ld.exe) supports 
shared libraries... yes
checking for g++ option to produce PIC... -DDLL_EXPORT -DPIC
checking if g++ PIC flag -DDLL_EXPORT -DPIC works... yes
checking if g++ static flag -static works... yes
checking if g++ supports -c -o file.o... yes
checking if g++ supports -c -o file.o... (cached) yes
checking whether the g++ linker (c:/mingw/mingw32/bin/ld.exe) supports 
shared libraries... yes
checking dynamic linker characteristics... Win32 ld.exe
checking how to hardcode library paths into programs... immediate
configure: creating ./config.status
config.status: creating Makefile
config.status: creating po/Makefile.in
config.status: creating doc/Makefile
config.status: creating doc/examples/Makefile
config.status: creating doc/scripts/Makefile
config.status: creating doc/manpages/Makefile
config.status: creating doc/reference/Makefile
config.status: creating doc/credentials/Makefile
config.status: creating doc/credentials/x509/Makefile
config.status: creating doc/credentials/srp/Makefile
config.status: creating doc/credentials/openpgp/Makefile
config.status: creating gl/Makefile
config.status: creating lgl/Makefile
config.status: creating tests/Makefile
config.status: creating tests/rsa-md5-collision/Makefile
config.status: creating tests/userid/Makefile
config.status: creating tests/pkcs1-padding/Makefile
config.status: creating tests/pkcs8-decode/Makefile
config.status: creating tests/pkcs12-decode/Makefile
config.status: creating tests/pathlen/Makefile
config.status: creating tests/key-id/Makefile
config.status: creating tests/sha2/Makefile
config.status: creating tests/hostname-check/Makefile
config.status: creating includes/Makefile
config.status: creating includes/gnutls/gnutls.h
config.status: creating lib/Makefile
config.status: creating lib/minitasn1/Makefile
config.status: creating lib/x509/Makefile
config.status: creating libextra/Makefile
config.status: creating lib/openpgp/Makefile
config.status: creating lib/opencdk/Makefile
config.status: creating tests/openpgp/Makefile
config.status: creating src/Makefile
config.status: creating src/cfg/Makefile
config.status: creating src/cfg/platon/Makefile
config.status: creating src/cfg/platon/str/Makefile
config.status: creating lib/libgnutls-config
config.status: creating libextra/libgnutls-extra-config
config.status: creating lib/gnutls.pc
config.status: creating libextra/gnutls-extra.pc
config.status: creating guile/Makefile
config.status: creating guile/modules/Makefile
config.status: creating guile/src/Makefile
config.status: creating guile/tests/Makefile
config.status: creating guile/pre-inst-guile
config.status: creating config.h
config.status: config.h is unchanged
config.status: executing depfiles commands
config.status: executing po-directories commands
config.status: creating po/POTFILES
config.status: creating po/Makefile
config.status: executing libtool commands
config.status: executing chmod-config commands





From machinecat1666 at gmail.com  Sun Apr 13 05:00:54 2008
From: machinecat1666 at gmail.com (Alan Zheng)
Date: Sun, 13 Apr 2008 11:00:54 +0800
Subject: [Help-gnutls] GnuTLS error -8: A record packet with illegal version
	was received.
Message-ID: <28db3f450804122000s20e44298w6b5383ef914ff46d@mail.gmail.com>

Hello all:

I am Alan, I used ftp client ("filezilla") to connect my ftp server (vsftpd
with ssl). I used PASV mode. I want to use 443 port to transfer data, but I
got an error message "GnuTLS error -8: A record packet with illegal version
was received."

Did you know if GnuTLS don't allow ftp server to use 443 port (I know 443
port for https, but I have not https)?
-- 
Best Regards

Alan Zheng
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20080413/853d9874/attachment.htm>

From nmav at gnutls.org  Sun Apr 13 07:58:08 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 13 Apr 2008 08:58:08 +0300
Subject: [Help-gnutls] GnuTLS error -8: A record packet with illegal
	version was received.
In-Reply-To: <28db3f450804122000s20e44298w6b5383ef914ff46d@mail.gmail.com>
References: <28db3f450804122000s20e44298w6b5383ef914ff46d@mail.gmail.com>
Message-ID: <4801A0F0.4070502@gnutls.org>

Alan Zheng wrote:
> Hello all:
> 
> I am Alan, I used ftp client ("filezilla") to connect my ftp server 
> (vsftpd with ssl). I used PASV mode. I want to use 443 port to transfer 
> data, but I got an error message "GnuTLS error -8: A record packet with 
> illegal version was received."
> 
> Did you know if GnuTLS don't allow ftp server to use 443 port (I know 
> 443 port for https, but I have not https)?

This doesn't seem a gnutls problem. Probably you are starting a TLS 
connection on a clear channel, or some protocol error in the ftp has 
occurred. Use wireshark to find our what happened.

regards,
Nikos




From simon at josefsson.org  Sun Apr 13 12:16:45 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Sun, 13 Apr 2008 12:16:45 +0200
Subject: [Help-gnutls] Re: Beginner's question
In-Reply-To: <dc67eef70804110803j100d6110q30751cebb3f0254c@mail.gmail.com>
	(Rainer Gerhards's message of "Fri, 11 Apr 2008 17:03:08 +0200")
References: <dc67eef70804100906g3042f217k91c11a26f36dc9a4@mail.gmail.com>
	<87prsw36wv.fsf@mocca.josefsson.org>
	<dc67eef70804110553p1349b6d1rb1be4a18d89fc3be@mail.gmail.com>
	<87iqyo35e1.fsf@mocca.josefsson.org>
	<dc67eef70804110720u27c50e35qfc4fdf867f1164d2@mail.gmail.com>
	<877if4v3pm.fsf@mocca.josefsson.org>
	<dc67eef70804110803j100d6110q30751cebb3f0254c@mail.gmail.com>
Message-ID: <87k5j29i0i.fsf@mocca.josefsson.org>

"Rainer Gerhards" <rgerhards at gmail.com> writes:

>>  Thanks!  Let us know if there is anything we could improve to help
>>  explain something that you get stuck on.  It is easy to go blind in a
>>  project, so input from new users are very valuable.
>
> There is one thing, if I may hijack this thread. The CRL files. I know
> what certificate revocation is for, but I do not fully understand how
> the CRL functions are used. Most importantly, do I need to create that
> file and, if so, how? I know that's all pretty basic and I appreciate
> your help on those boring questions ;).

Good questions.  I think people are generally better off forgetting
about CRLs.  If you are designing something new, use an online checking
protocol like OCSP instead of CRLs.  If you are stuck with a system that
uses CRLs, you naturally has to use it.

As far as I could see, there wasn't any documentation on how to
generate/verify CRLs in the manual, I've fixed this:

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

We could probably discuss CRLs more in the manual, but I can't seem to
find a good place to do it or can think of anything concrete to say.

Thanks,
/Simon




From simon at josefsson.org  Sun Apr 13 12:48:36 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Sun, 13 Apr 2008 12:48:36 +0200
Subject: [Help-gnutls] Re: gnutls 2.3.4 doesn't copile using MinGW
In-Reply-To: <47FFACC3.7010400@alice.it> (Massimo Gaspari's message of "Fri,
	11 Apr 2008 20:24:03 +0200")
References: <47FFACC3.7010400@alice.it>
Message-ID: <87fxtq9gjf.fsf@mocca.josefsson.org>

Massimo Gaspari <massimo.gaspari at alice.it> writes:

> Hi all,
>
> I am trying to get gntls compiled on a Windows XP SP2 with mingw (Gcc
> 4.2.1 , + Msys 1.0).

Hi!  I haven't tried that, but it should be possible.  I use MinGW under
Debian.

> I compiled without issues zlib 1.2.3 , libgpg-error 1.6 and libgcrypt
> 1.4.0. The latest one using
>
> ./configure --disable-shared --disable-asm --disable-dev-random

I didn't use any parameter when building under debian.  Did you run into
problems that lead you to use these?

In particular, do you want --disable-shared?  Building a DLL should be
possible.

> Now gnutls. I used
>
> ./configure --disable-shared --disable-rpath --disable-cxx --disable-guile
>
> and then make. But the compilation stopped with
>
>
> libtool: link: ( cd ".libs" && rm -f "libgnutls.la" && cp -p 
> "../libgnutls.la" "libgnutls.la" )
> make[3]: *** No rule to make target `libgnutls-26.def', needed by
...
>
> Any suggestion? Does gnutls compile on MinGW? Any help will be appreciated.
...
> checking if gcc/ld supports -Wl,--output-def... yes

I think this is the problem: we check if -Wl,--output-def works, and
enable the *.def stuff if it is, but if --disable-shared is used, I
suspect that the linker won't output a *.def file, so the build fails.

To work around the problem, just 'touch lib/libgnutls-26.def' to create
a zero size dummy file.  Then re-run make.

You could try and remove --disabled-shared, then a shared library will
be built and the *.def file will be generated via --output-def.

However, building only static libraries should be supported too, so we
should fix this.  We probably shouldn't even attempt to use --output-def
if we aren't building shared libraries.  I've installed the following
patches.  Could you try tomorrow's daily snapshot?

http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=e33b897e0cb313ad21f116f02cfa5d40a825a645
http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=547af300bec94d0093813a8440870358940e159b
http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=f270fe0568186ca666e244cd88893c7cdb47467a

Thanks,
/Simon




From massimo.gaspari at alice.it  Sun Apr 13 22:41:59 2008
From: massimo.gaspari at alice.it (Massimo Gaspari)
Date: Sun, 13 Apr 2008 22:41:59 +0200
Subject: [Help-gnutls] Re: gnutls 2.3.4 doesn't copile using MinGW
In-Reply-To: <87fxtq9gjf.fsf@mocca.josefsson.org>
References: <47FFACC3.7010400@alice.it> <87fxtq9gjf.fsf@mocca.josefsson.org>
Message-ID: <48027017.6090508@alice.it>

Simon Josefsson wrote:


Thank you very much for your reply. And thank you in advance for any 
further help.
>> I compiled without issues zlib 1.2.3 , libgpg-error 1.6 and libgcrypt
>> 1.4.0. The latest one using
>>
>> ./configure --disable-shared --disable-asm --disable-dev-random
>>     
>
> I didn't use any parameter when building under debian.  Did you run into
> problems that lead you to use these?
>   

No
> In particular, do you want --disable-shared?  Building a DLL should be
> possible.
>
>   

I don't need and I prefer static libraries only.

I used

--disable-dev-random

because otherwise (please correct me if I'm wrong) I need /dev/random without that option
(Windows XP and/or Vista). Is it correct?  Can I use /dev/random on Windows platform as well?
Or is  --disable-dev-random needed on Windows?
As you know I'm a GnuTls beginner. So please be patient.. :-)

Just to tell you the whole story, the libgpgcrypt was configured using

./configure --disable-shared --disable-rpath

But I don't think libgpg-error is involved in the reported issue.
>> Now gnutls. I used
>>
>> ./configure --disable-shared --disable-rpath --disable-cxx --disable-guile
>>
>> and then make. But the compilation stopped with
>>
>>
>> libtool: link: ( cd ".libs" && rm -f "libgnutls.la" && cp -p 
>> "../libgnutls.la" "libgnutls.la" )
>> make[3]: *** No rule to make target `libgnutls-26.def', needed by
>>     
>
>   
> I think this is the problem: we check if -Wl,--output-def works, and
> enable the *.def stuff if it is, but if --disable-shared is used, I
> suspect that the linker won't output a *.def file, so the build fails.
>
> To work around the problem, just 'touch lib/libgnutls-26.def' to create
> a zero size dummy file.  Then re-run make.
>
> You could try and remove --disabled-shared, then a shared library will
> be built and the *.def file will be generated via --output-def.
>
> However, building only static libraries should be supported too, so we
> should fix this.  We probably shouldn't even attempt to use --output-def
> if we aren't building shared libraries.  I've installed the following
> patches.  Could you try tomorrow's daily snapshot?
>
> http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=e33b897e0cb313ad21f116f02cfa5d40a825a645
> http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=547af300bec94d0093813a8440870358940e159b
> http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=f270fe0568186ca666e244cd88893c7cdb47467a
>
> Thanks,
> /Simon
>   
I re-tried to compile gnutls and after the error message I made " touch 
lib/libgnutls-26.def" . Then I got the following error message

libtool: link: ranlib .libs/libgnutls-openssl.a
libtool: link: rm -fr .libs/libgnutls-openssl.lax
libtool: link: ( cd ".libs" && rm -f "libgnutls-openssl.la" && cp -p 
"../libgnutls-openssl.la" "libgnutls-openssl.la" )
make[3]: *** No rule to make target `libgnutls-openssl-26.def', needed 
by `all-am'.  Stop.
make[3]: Leaving directory `/home/Massimo/gnutls-2.3.4/libextra'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/Massimo/gnutls-2.3.4/libextra'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/Massimo/gnutls-2.3.4'
make: *** [all] Error 2


I made "touch libextra/libgnutls-openssl-26.def". Then the same for 
libgnutls-extra-26.def, after another  "touch" I got

/bin/sh ../libtool --tag=CC   --mode=link gcc -std=gnu99 -pipe 
-I/usr/local/include -O2 -Wno-pointer-sign   -o gnutls-serv.exe 
serv-gaa.o serv.o common.o select.o ../lib/libgnutls.la -L/usr/local/lib 
-lgcrypt -lgpg-error  ../gl/libgnu.la -lws2_32
libtool: link: gcc -std=gnu99 -pipe -I/usr/local/include -O2 
-Wno-pointer-sign -o gnutls-serv.exe serv-gaa.o serv.o common.o 
select.o  ../lib/.libs/libgnutls.a -L/usr/local/lib ../gl/.libs/libgnu.a 
/usr/local/lib/libgcrypt.a /usr/local/lib/libgpg-error.a -lws2_32
C:/msys/1.0/local/lib/libgcrypt.a(libgcrypt_la-missing-string.o):missing-string.c:(.text+0x30): 
multiple definition of `_vasprintf'
../lib/.libs/libgnutls.a(vasprintf.o):vasprintf.c:(.text+0x0): first 
defined here
collect2: ld returned 1 exit status
make[3]: *** [gnutls-serv.exe] Error 1
make[3]: Leaving directory `/home/Massimo/gnutls-2.3.4/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/Massimo/gnutls-2.3.4/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/Massimo/gnutls-2.3.4'
make: *** [all] Error 2

This time "touch" can't help :-).

Any other suggestion?

Nevertheless during compilation I got the followin warnings

libtool: compile:  gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. 
-I../../lgl -I../../lgl -I../../libextra -I../../lib/minitasn1 
-I../../libextra/openpgp/ -I../../libextra/opencdk -I../../lib 
-I../../includes -I../../includes -I/usr/local/include -pipe 
-I/usr/local/include -O2 -Wno-pointer-sign -MT x509.lo -MD -MP -MF 
.deps/x509.Tpo -c x509.c -o x509.o
x509.c: In function '_gnutls_x509_crt_cpy':
x509.c:95: warning: implicit declaration of function 'alloca'
x509.c:95: warning: incompatible implicit declaration of built-in 
function 'alloca'
x509.c: In function 'gnutls_x509_crt_get_fingerprint':
x509.c:1965: warning: incompatible implicit declaration of built-in 
function 'alloca'
x509.c: In function 'gnutls_x509_crt_get_key_id':
x509.c:2160: warning: incompatible implicit declaration of built-in 
function 'alloca'
mv -f .deps/x509.Tpo .deps/x509.Plo


The same warning is present for other files as well. Do you need a full 
list?

I was unable to find a new daily snapshot. May be it isn't available 
yet. I'm going to try as soon as the new snapshot is available.

Max





From massimo.gaspari at alice.it  Sun Apr 13 22:45:15 2008
From: massimo.gaspari at alice.it (Massimo Gaspari)
Date: Sun, 13 Apr 2008 22:45:15 +0200
Subject: [Help-gnutls] Re: gnutls 2.3.4 doesn't copile using MinGW
In-Reply-To: <48027017.6090508@alice.it>
References: <47FFACC3.7010400@alice.it> <87fxtq9gjf.fsf@mocca.josefsson.org>
	<48027017.6090508@alice.it>
Message-ID: <480270DB.1080206@alice.it>

Massimo Gaspari wrote:
>
>
> Just to tell you the whole story, the libgpgcrypt was configured using
>
> ./configure --disable-shared --disable-rpath
>
Sorry I meant libgpg-error library was compiled with ./configure 
--disable-shared --disable-rpath




From massimo.gaspari at alice.it  Mon Apr 14 21:46:19 2008
From: massimo.gaspari at alice.it (Massimo Gaspari)
Date: Mon, 14 Apr 2008 21:46:19 +0200
Subject: [Help-gnutls] Re: gnutls 2.3.4 doesn't copile using MinGW
In-Reply-To: <87fxtq9gjf.fsf@mocca.josefsson.org>
References: <47FFACC3.7010400@alice.it> <87fxtq9gjf.fsf@mocca.josefsson.org>
Message-ID: <4803B48B.4030409@alice.it>

Simon Josefsson wrote:
>
> However, building only static libraries should be supported too, so we
> should fix this.  We probably shouldn't even attempt to use --output-def
> if we aren't building shared libraries.  I've installed the following
> patches.  Could you try tomorrow's daily snapshot?
>
> http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=e33b897e0cb313ad21f116f02cfa5d40a825a645
> http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=547af300bec94d0093813a8440870358940e159b
> http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=f270fe0568186ca666e244cd88893c7cdb47467a
>
>   

I tried the latest snapshot gnutls-20080415.tar.gz and the ".def issue" 
is disappeared. But the error

mkdir .libs
gcc -std=gnu99 -pipe -I/usr/local/include -O2 -Wno-pointer-sign -o 
gnutls-serv.exe serv-gaa.o serv.o common.o select.o  
../lib/.libs/libgnutls.a -L/usr/local/lib -lz ../gl/.libs/libgnu.a 
/usr/local/lib/libgcrypt.a /usr/local/lib/libgpg-error.a -lws2_32
C:/msys/1.0/local/lib/libgcrypt.a(libgcrypt_la-missing-string.o):missing-string.c:(.text+0x30): 
multiple definition of `_vasprintf'
../lib/.libs/libgnutls.a(vasprintf.o):vasprintf.c:(.text+0x0): first 
defined here
collect2: ld returned 1 exit status
make[3]: *** [gnutls-serv.exe] Error 1
make[3]: Leaving directory `/home/emasgas/gnutls-2.3.5/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/emasgas/gnutls-2.3.5/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/emasgas/gnutls-2.3.5'
make: *** [all] Error 2


is still present.

In the meantime I recompiled libgcrypt using

./configure --disable-shared --disable-asm --enable-random=w32 
--disable-dev-random

Do you think that the "random" options are correct to use the library in 
a Windows environment (not using MinGW)?

Thx

Massimo





From aspecialj at gmail.com  Tue Apr 15 03:08:53 2008
From: aspecialj at gmail.com (John Brooks)
Date: Mon, 14 Apr 2008 19:08:53 -0600
Subject: [Help-gnutls] CRQ signing error
Message-ID: <e646fda30804141808g27bed377r76bd6ebfdf9a6283@mail.gmail.com>

I'm attempting to generate a certificate request with just a common name,
and it seems that gnutls_x509_crq_sign2 is giving me
GNUTLS_E_ASN1_VALUE_NOT_FOUND; i'm not sure what to do about that. As far as
I can see, my code is consistent with the docs and examples. Any pointers on
where this is incorrect?

        if ((re = gnutls_x509_crq_init(&req)) != 0)
        {
            gnutls_x509_privkey_deinit(key);
            return re;
        }

        if ((re = gnutls_x509_crq_set_dn_by_oid(req,
GNUTLS_OID_X520_COMMON_NAME, 0, dn, strlen(dn))) != 0)
        {
            gnutls_x509_crq_deinit(req);
            gnutls_x509_privkey_deinit(key);
            return re;
        }

        if ((re = gnutls_x509_crq_set_key(req, key)) != 0)
        {
            gnutls_x509_crq_deinit(req);
            gnutls_x509_privkey_deinit(key);
            return re;
        }

// This is where the error occurs
        if ((re = gnutls_x509_crq_sign2(req, key, GNUTLS_DIG_SHA1, 0)) != 0)
        {
            gnutls_x509_crq_deinit(req);
            gnutls_x509_privkey_deinit(key);
            return re;
        }

        if ((re = gnutls_x509_crq_export(req, GNUTLS_X509_FMT_PEM, buf,
bufsz)) != 0)
        {
            gnutls_x509_crq_deinit(req);
            gnutls_x509_privkey_deinit(key);
            return re;
        }

Thanks ;)
-- 
- John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20080414/de1e46f5/attachment.htm>

From aspecialj at gmail.com  Tue Apr 15 04:22:36 2008
From: aspecialj at gmail.com (John Brooks)
Date: Mon, 14 Apr 2008 20:22:36 -0600
Subject: [Help-gnutls] Re: CRQ signing error
In-Reply-To: <e646fda30804141808g27bed377r76bd6ebfdf9a6283@mail.gmail.com>
References: <e646fda30804141808g27bed377r76bd6ebfdf9a6283@mail.gmail.com>
Message-ID: <e646fda30804141922n2aabe67fn990d40311ee34aa0@mail.gmail.com>

After lots of tinkering, i've solved the problem. It seems to fail if
gnutls_x509_crq_set_version isn't called - although the error is rather
cryptic.

Thanks anyway :P

On Mon, Apr 14, 2008 at 7:08 PM, John Brooks <aspecialj at gmail.com> wrote:

> I'm attempting to generate a certificate request with just a common name,
> and it seems that gnutls_x509_crq_sign2 is giving me
> GNUTLS_E_ASN1_VALUE_NOT_FOUND; i'm not sure what to do about that. As far as
> I can see, my code is consistent with the docs and examples. Any pointers on
> where this is incorrect?
>
>         if ((re = gnutls_x509_crq_init(&req)) != 0)
>         {
>             gnutls_x509_privkey_deinit(key);
>             return re;
>         }
>
>         if ((re = gnutls_x509_crq_set_dn_by_oid(req,
> GNUTLS_OID_X520_COMMON_NAME, 0, dn, strlen(dn))) != 0)
>         {
>             gnutls_x509_crq_deinit(req);
>             gnutls_x509_privkey_deinit(key);
>             return re;
>         }
>
>         if ((re = gnutls_x509_crq_set_key(req, key)) != 0)
>         {
>             gnutls_x509_crq_deinit(req);
>             gnutls_x509_privkey_deinit(key);
>             return re;
>         }
>
> // This is where the error occurs
>         if ((re = gnutls_x509_crq_sign2(req, key, GNUTLS_DIG_SHA1, 0)) !=
> 0)
>         {
>             gnutls_x509_crq_deinit(req);
>             gnutls_x509_privkey_deinit(key);
>             return re;
>         }
>
>         if ((re = gnutls_x509_crq_export(req, GNUTLS_X509_FMT_PEM, buf,
> bufsz)) != 0)
>         {
>             gnutls_x509_crq_deinit(req);
>             gnutls_x509_privkey_deinit(key);
>             return re;
>         }
>
> Thanks ;)
> --
> - John




-- 
- John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20080414/77b53610/attachment.htm>

From simon at josefsson.org  Tue Apr 15 06:30:20 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 15 Apr 2008 06:30:20 +0200
Subject: [Help-gnutls] Re: CRQ signing error
In-Reply-To: <e646fda30804141922n2aabe67fn990d40311ee34aa0@mail.gmail.com>
	(John Brooks's message of "Mon, 14 Apr 2008 20:22:36 -0600")
References: <e646fda30804141808g27bed377r76bd6ebfdf9a6283@mail.gmail.com>
	<e646fda30804141922n2aabe67fn990d40311ee34aa0@mail.gmail.com>
Message-ID: <87skxnvixv.fsf@mocca.josefsson.org>

"John Brooks" <aspecialj at gmail.com> writes:

> After lots of tinkering, i've solved the problem. It seems to fail if
> gnutls_x509_crq_set_version isn't called - although the error is rather
> cryptic.

Right.  I've improved the documentation for the function:

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

Possibly the code could have done this for you, the version field is
always 0 in practice anyway...  yes, I installed this:

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

Thanks,
Simon

> Thanks anyway :P
>
> On Mon, Apr 14, 2008 at 7:08 PM, John Brooks <aspecialj at gmail.com> wrote:
>
>> I'm attempting to generate a certificate request with just a common name,
>> and it seems that gnutls_x509_crq_sign2 is giving me
>> GNUTLS_E_ASN1_VALUE_NOT_FOUND; i'm not sure what to do about that. As far as
>> I can see, my code is consistent with the docs and examples. Any pointers on
>> where this is incorrect?
>>
>>         if ((re = gnutls_x509_crq_init(&req)) != 0)
>>         {
>>             gnutls_x509_privkey_deinit(key);
>>             return re;
>>         }
>>
>>         if ((re = gnutls_x509_crq_set_dn_by_oid(req,
>> GNUTLS_OID_X520_COMMON_NAME, 0, dn, strlen(dn))) != 0)
>>         {
>>             gnutls_x509_crq_deinit(req);
>>             gnutls_x509_privkey_deinit(key);
>>             return re;
>>         }
>>
>>         if ((re = gnutls_x509_crq_set_key(req, key)) != 0)
>>         {
>>             gnutls_x509_crq_deinit(req);
>>             gnutls_x509_privkey_deinit(key);
>>             return re;
>>         }
>>
>> // This is where the error occurs
>>         if ((re = gnutls_x509_crq_sign2(req, key, GNUTLS_DIG_SHA1, 0)) !=
>> 0)
>>         {
>>             gnutls_x509_crq_deinit(req);
>>             gnutls_x509_privkey_deinit(key);
>>             return re;
>>         }
>>
>>         if ((re = gnutls_x509_crq_export(req, GNUTLS_X509_FMT_PEM, buf,
>> bufsz)) != 0)
>>         {
>>             gnutls_x509_crq_deinit(req);
>>             gnutls_x509_privkey_deinit(key);
>>             return re;
>>         }
>>
>> Thanks ;)
>> --
>> - John
>
>
>
>
> -- 
> - John
> _______________________________________________
> Help-gnutls mailing list
> Help-gnutls at gnu.org
> http://lists.gnu.org/mailman/listinfo/help-gnutls




From simon at josefsson.org  Tue Apr 15 06:44:55 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 15 Apr 2008 06:44:55 +0200
Subject: [Help-gnutls] Re: gnutls 2.3.4 doesn't copile using MinGW
In-Reply-To: <48027017.6090508@alice.it> (Massimo Gaspari's message of "Sun,
	13 Apr 2008 22:41:59 +0200")
References: <47FFACC3.7010400@alice.it> <87fxtq9gjf.fsf@mocca.josefsson.org>
	<48027017.6090508@alice.it>
Message-ID: <87mynvvi9k.fsf@mocca.josefsson.org>

Massimo Gaspari <massimo.gaspari at alice.it> writes:

>> In particular, do you want --disable-shared?  Building a DLL should be
>> possible.
>>
>>   
>
> I don't need and I prefer static libraries only.

Ok.

> I used
>
> --disable-dev-random
>
> because otherwise (please correct me if I'm wrong) I need /dev/random without that option
> (Windows XP and/or Vista). Is it correct?  Can I use /dev/random on Windows platform as well?
> Or is  --disable-dev-random needed on Windows?
> As you know I'm a GnuTls beginner. So please be patient.. :-)

Actually, since you use libgcrypt, that parameter doesn't do anything.
The --disable-dev-random flag is only used if you also add
--with-builtin-crypto but that isn't well supported, see README.  You
can safely remove it.

> Just to tell you the whole story, the libgpgcrypt was configured using
>
> ./configure --disable-shared --disable-rpath
>
> But I don't think libgpg-error is involved in the reported issue.

Agreed.

> I re-tried to compile gnutls and after the error message I made "
> touch lib/libgnutls-26.def" . Then I got the following error message
...
> I made "touch libextra/libgnutls-openssl-26.def". Then the same for
> libgnutls-extra-26.def, after another  "touch" I got
...

I see 2.3.5 fixed these for you, good.

> /bin/sh ../libtool --tag=CC   --mode=link gcc -std=gnu99 -pipe
> -I/usr/local/include -O2 -Wno-pointer-sign   -o gnutls-serv.exe
> serv-gaa.o serv.o common.o select.o ../lib/libgnutls.la
> -L/usr/local/lib -lgcrypt -lgpg-error  ../gl/libgnu.la -lws2_32
> libtool: link: gcc -std=gnu99 -pipe -I/usr/local/include -O2
> -Wno-pointer-sign -o gnutls-serv.exe serv-gaa.o serv.o common.o
> select.o  ../lib/.libs/libgnutls.a -L/usr/local/lib
> ../gl/.libs/libgnu.a /usr/local/lib/libgcrypt.a
> /usr/local/lib/libgpg-error.a -lws2_32
> C:/msys/1.0/local/lib/libgcrypt.a(libgcrypt_la-missing-string.o):missing-string.c:(.text+0x30):
> multiple definition of `_vasprintf'
> ../lib/.libs/libgnutls.a(vasprintf.o):vasprintf.c:(.text+0x0): first
> defined here
> collect2: ld returned 1 exit status
> make[3]: *** [gnutls-serv.exe] Error 1
> make[3]: Leaving directory `/home/Massimo/gnutls-2.3.4/src'
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory `/home/Massimo/gnutls-2.3.4/src'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/Massimo/gnutls-2.3.4'
> make: *** [all] Error 2
>
> This time "touch" can't help :-).
>
> Any other suggestion?

Ouch, this isn't a fun problem. :-(

I've known about this for some time, but don't know a good solution.

The problem is that libgcrypt defines a 'vasprintf' function, and it is
stored in the static library.

GnuTLS also defines a 'vasprintf' function.

When you use shared libraries, this isn't a problem because the
namespaces won't collide, so the symbols will just be hidden.

But with static libraries, both symbols are there, and they collide.

The interesting thing is that my Windows builds (see
<http://josefsson.org/gnutls4win/>) do not trigger this problem.  I
build both shared and static libraries.  So maybe you could see if
building shared libraries for some strange reason makes the static
library link for you?

I'm not sure what the best solution is.  Possibly 'vasprintf' shouldn't
be exported, but with static libraries, I don't think that is possible.
All symbols used are exported.  So maybe the symbol needs to be renamed.

This is a general problem with linking multiple libraries that use
modules from gnulib, so I should bring this up on the gnulib list.

> Nevertheless during compilation I got the followin warnings
>
> libtool: compile:  gcc -std=gnu99 -DHAVE_CONFIG_H
> -I. -I../.. -I../../lgl -I../../lgl -I../../libextra
> -I../../lib/minitasn1 -I../../libextra/openpgp/
> -I../../libextra/opencdk -I../../lib -I../../includes -I../../includes
> -I/usr/local/include -pipe -I/usr/local/include -O2 -Wno-pointer-sign
> -MT x509.lo -MD -MP -MF .deps/x509.Tpo -c x509.c -o x509.o
> x509.c: In function '_gnutls_x509_crt_cpy':
> x509.c:95: warning: implicit declaration of function 'alloca'
> x509.c:95: warning: incompatible implicit declaration of built-in
> function 'alloca'
> x509.c: In function 'gnutls_x509_crt_get_fingerprint':
> x509.c:1965: warning: incompatible implicit declaration of built-in
> function 'alloca'
> x509.c: In function 'gnutls_x509_crt_get_key_id':
> x509.c:2160: warning: incompatible implicit declaration of built-in
> function 'alloca'
> mv -f .deps/x509.Tpo .deps/x509.Plo
>
>
> The same warning is present for other files as well. Do you need a
> full list?

No, that error is sufficient for me.

Does your system have alloca.h?  What does ./configure say about alloca?

I'm not sure it is worth the problems to use alloca.  Even if we get it
to compile, there may be subtle size restrictions on it as well which
can cause failures at run-time instead.

> I was unable to find a new daily snapshot. May be it isn't available
> yet. I'm going to try as soon as the new snapshot is available.

It should be available now, but won't fix your two more important
problems.

/Simon




From simon at josefsson.org  Tue Apr 15 06:47:39 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 15 Apr 2008 06:47:39 +0200
Subject: [Help-gnutls] Re: gnutls 2.3.4 doesn't copile using MinGW
In-Reply-To: <4803B48B.4030409@alice.it> (Massimo Gaspari's message of "Mon,
	14 Apr 2008 21:46:19 +0200")
References: <47FFACC3.7010400@alice.it> <87fxtq9gjf.fsf@mocca.josefsson.org>
	<4803B48B.4030409@alice.it>
Message-ID: <87iqyjvi50.fsf@mocca.josefsson.org>

Massimo Gaspari <massimo.gaspari at alice.it> writes:

> In the meantime I recompiled libgcrypt using
>
> ./configure --disable-shared --disable-asm --enable-random=w32
> --disable-dev-random
>
> Do you think that the "random" options are correct to use the library
> in a Windows environment (not using MinGW)?

Yes.  I would think that the script will guess these values
automatically though, so you probably don't need to specify them.  If it
guesses the w32 module properly, the --disable-dev-random flag won't
matter since the w32 module doesn't use /dev/random.

Does building fail if you remove --disable-asm?  You may get a speed
improvement if you remove it, but removing it can also cause build
failures.

/Simon




From marlam at marlam.de  Tue Apr 15 07:13:47 2008
From: marlam at marlam.de (Martin Lambers)
Date: Tue, 15 Apr 2008 07:13:47 +0200
Subject: [Help-gnutls] Diffie Hellman size?
Message-ID: <20080415051347.GA13559@wile.lambers.home>

Hello all!

I had a few reports of failures with msmtp using GnuTLS:
"The Diffie Hellman prime sent by the server is not acceptable
(not long enough)". See for example
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=440344 .

It is possible to solve this by adding the line
gnutls_dh_set_prime_bits(session, 512);

However, there's certainly a reason why the required length was changed,
though I cannot find a related ChangeLog or NEWS entry.

Is it ok to reduce the the required length, or does this have security
implications?

Can the new function gnutls_priority_init() be used instead of
gnutls_dh_set_prime_bits()? Then the user could set all his special TLS
session requirements using a single interface. That would be nice.

Martin




From simon at josefsson.org  Tue Apr 15 09:39:11 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 15 Apr 2008 09:39:11 +0200
Subject: [Help-gnutls] Re: Diffie Hellman size?
In-Reply-To: <20080415051347.GA13559@wile.lambers.home> (Martin Lambers's
	message of "Tue, 15 Apr 2008 07:13:47 +0200")
References: <20080415051347.GA13559@wile.lambers.home>
Message-ID: <877iezo9cw.fsf@mocca.josefsson.org>

Martin Lambers <marlam at marlam.de> writes:

> Hello all!
>
> I had a few reports of failures with msmtp using GnuTLS:
> "The Diffie Hellman prime sent by the server is not acceptable
> (not long enough)". See for example
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=440344 .
>
> It is possible to solve this by adding the line
> gnutls_dh_set_prime_bits(session, 512);
>
> However, there's certainly a reason why the required length was changed,
> though I cannot find a related ChangeLog or NEWS entry.

I found the change, it was made roughly 5 years ago:

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

There is a Changelog entry for it, in ChangeLog.1.  No NEWS entry
though.

> Is it ok to reduce the the required length, or does this have security
> implications?

I can't seem to find a good reference for this.  RFC 4419 seems to
suggest 1024 bits for SSH, but it is not clear if the same
considerations apply to TLS.  RFC 3766 is rather vague, but suggests
that 2*K should be ok, where K is the needed symmetric key size.  From
that 512 bits would be ok, but that makes me confused why RFC 4419
requires more.  It would be nice to have a better answer for your
question.

Nikos, do you recall why you changed the default here?

> Can the new function gnutls_priority_init() be used instead of
> gnutls_dh_set_prime_bits()? Then the user could set all his special TLS
> session requirements using a single interface. That would be nice.

Good idea, that should definitely be supported:

http://trac.gnutls.org/cgi-bin/trac.cgi/ticket/29

Patches welcome. ;)

/Simon




From simon at josefsson.org  Tue Apr 15 09:54:14 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 15 Apr 2008 09:54:14 +0200
Subject: [Help-gnutls] Re: Diffie Hellman size?
In-Reply-To: <877iezo9cw.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Tue, 15 Apr 2008 09:39:11 +0200")
References: <20080415051347.GA13559@wile.lambers.home>
	<877iezo9cw.fsf@mocca.josefsson.org>
Message-ID: <87fxtn8sex.fsf@mocca.josefsson.org>

Simon Josefsson <simon at josefsson.org> writes:

>> Is it ok to reduce the the required length, or does this have security
>> implications?
>
> I can't seem to find a good reference for this.  RFC 4419 seems to
> suggest 1024 bits for SSH, but it is not clear if the same
> considerations apply to TLS.  RFC 3766 is rather vague, but suggests
> that 2*K should be ok, where K is the needed symmetric key size.  From
> that 512 bits would be ok, but that makes me confused why RFC 4419
> requires more.  It would be nice to have a better answer for your
> question.

I found a table in RFC 3526:

   This document describes new stronger groups to be used in IKE.  The
   strengths of the groups defined here are always estimates and there
   are as many methods to estimate them as there are cryptographers.
   For the strength estimates below we took the both ends of the scale
   so the actual strength estimate is likely between the two numbers
   given here.

   +--------+----------+---------------------+---------------------+
   | Group  | Modulus  | Strength Estimate 1 | Strength Estimate 2 |
   |        |          +----------+----------+----------+----------+
   |        |          |          | exponent |          | exponent |
   |        |          | in bits  | size     | in bits  | size     |
   +--------+----------+----------+----------+----------+----------+
   |   5    | 1536-bit |       90 |     180- |      120 |     240- |
   |  14    | 2048-bit |      110 |     220- |      160 |     320- |
   |  15    | 3072-bit |      130 |     260- |      210 |     420- |
   |  16    | 4096-bit |      150 |     300- |      240 |     480- |
   |  17    | 6144-bit |      170 |     340- |      270 |     540- |
   |  18    | 8192-bit |      190 |     380- |      310 |     620- |
   +--------+----------+---------------------+---------------------+

Which would suggest a DH prime modulus of size 512 would definitely be
sub-standard today.  Again, my reservation of how much of these non-TLS
discussions applies to TLS remain.

Do you know a live server that use this small parameters?  I'm curious
what kind of software is involved.

/Simon




From marlam at marlam.de  Tue Apr 15 10:52:05 2008
From: marlam at marlam.de (Martin Lambers)
Date: Tue, 15 Apr 2008 10:52:05 +0200
Subject: [Help-gnutls] Re: Diffie Hellman size?
In-Reply-To: <87fxtn8sex.fsf@mocca.josefsson.org>
References: <20080415051347.GA13559@wile.lambers.home>
	<877iezo9cw.fsf@mocca.josefsson.org>
	<87fxtn8sex.fsf@mocca.josefsson.org>
Message-ID: <20080415085205.GA26074@wile.lambers.home>

On Tue, 15. Apr 2008, 09:54:14 +0200, Simon Josefsson wrote:
> Which would suggest a DH prime modulus of size 512 would definitely be
> sub-standard today.  Again, my reservation of how much of these non-TLS
> discussions applies to TLS remain.
> 
> Do you know a live server that use this small parameters?  I'm curious
> what kind of software is involved.

Apparently some versions of sendmail are involved. The default for
Debian's package was updated only recently; see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=461802 .

Martin




From simon at josefsson.org  Tue Apr 15 11:23:46 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 15 Apr 2008 11:23:46 +0200
Subject: [Help-gnutls] Re: Diffie Hellman size?
In-Reply-To: <877iezo9cw.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Tue, 15 Apr 2008 09:39:11 +0200")
References: <20080415051347.GA13559@wile.lambers.home>
	<877iezo9cw.fsf@mocca.josefsson.org>
Message-ID: <87mynvzd25.fsf@mocca.josefsson.org>

FYI,

I asked Peter Gutmann about this, who recently posted some mathematical
limits he used in:

http://permalink.gmane.org/gmane.ietf.smime/6175

His response is below.  So there seems to be good reasons why we
shouldn't allow too small DH prime modulus.  Although I'd prefer if this
were a bit better documented.

/Simon

From: pgut001 at cs.auckland.ac.nz (Peter Gutmann)
Subject: Re: On D-H prime modulus sizes in TLS
To: simon at josefsson.org
Date: Tue, 15 Apr 2008 20:11:37 +1200

Hi,

>Thanks for providing those limits.

You're welcome, and if you have any more please let me know - it costs almost
nothing at key load since it's done only once, but can save a lot of headaches
later.

>Do you also have limits on the size of DH parameters in TLS?
>
>In GNUTLS we currently check if the prime modulus size is smaller than 712
>bits, and apparently there are some servers that trigger this check:
>
>http://thread.gmane.org/gmane.network.gnutls.general/1158
>
>I have not found any useful references that discuss D-H prime modulus sizes
>in TLS.  I'm not sure if the table in section 8 of RFC 3526 applies.  If it
>does, and if <= 712 bit sizes are used widely, it seems somewhat bad.

I use the same limits for DH as I do for RSA and DSA.  While the strength of
RSA and DH (or in general DLP-based PKCs) isn't really comparable, it is for
DSA and DH, so requiring DSA to be >= 1024 bits but allowing DH down to 700
bits doesn't seem wise.  Standards for DLP-based keys like FIPS 186 now
require at least 1024-bit keys, so there's a good case for not allowing such
short keys: it's a hard limit, you can't even get a product accepted for FIPS
testing if you have keys shorter than 1024 bits.

Peter.




From nmav at gnutls.org  Tue Apr 15 14:13:47 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 15 Apr 2008 15:13:47 +0300
Subject: Fwd: [Help-gnutls] Re: Diffie Hellman size?
In-Reply-To: <c331d99a0804150320w6ff658b3w99e561ff22049e83@mail.gmail.com>
References: <20080415051347.GA13559@wile.lambers.home>
	<877iezo9cw.fsf@mocca.josefsson.org>
	<87mynvzd25.fsf@mocca.josefsson.org>
	<c331d99a0804150320w6ff658b3w99e561ff22049e83@mail.gmail.com>
Message-ID: <c331d99a0804150513k4a3601ebia8652ec327b00354@mail.gmail.com>

On Tue, Apr 15, 2008 at 12:23 PM, Simon Josefsson <simon at josefsson.org> wrote:
 > FYI,
 >
 >  I asked Peter Gutmann about this, who recently posted some mathematical
 >  limits he used in:
 >
 >  http://permalink.gmane.org/gmane.ietf.smime/6175
 >
 >  His response is below.  So there seems to be good reasons why we
 >  shouldn't allow too small DH prime modulus.  Although I'd prefer if this
 >  were a bit better documented.

 We also have this:
 http://www.gnu.org/software/gnutls/manual/html_node/Selecting-cryptographic-key-sizes.html#Selecting-cryptographic-key-sizes

 The values apply to DH parameters as well.

 regards,
 Nikos




From simon at josefsson.org  Tue Apr 15 20:38:34 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 15 Apr 2008 20:38:34 +0200
Subject: [Help-gnutls] Re: Fwd: Re: Diffie Hellman size?
In-Reply-To: <c331d99a0804150513k4a3601ebia8652ec327b00354@mail.gmail.com>
	(Nikos Mavrogiannopoulos's message of "Tue, 15 Apr 2008 15:13:47
	+0300")
References: <20080415051347.GA13559@wile.lambers.home>
	<877iezo9cw.fsf@mocca.josefsson.org>
	<87mynvzd25.fsf@mocca.josefsson.org>
	<c331d99a0804150320w6ff658b3w99e561ff22049e83@mail.gmail.com>
	<c331d99a0804150513k4a3601ebia8652ec327b00354@mail.gmail.com>
Message-ID: <87skxnj74l.fsf@mocca.josefsson.org>

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

> On Tue, Apr 15, 2008 at 12:23 PM, Simon Josefsson <simon at josefsson.org> wrote:
>  > FYI,
>  >
>  >  I asked Peter Gutmann about this, who recently posted some mathematical
>  >  limits he used in:
>  >
>  >  http://permalink.gmane.org/gmane.ietf.smime/6175
>  >
>  >  His response is below.  So there seems to be good reasons why we
>  >  shouldn't allow too small DH prime modulus.  Although I'd prefer if this
>  >  were a bit better documented.
>
>  We also have this:
>  http://www.gnu.org/software/gnutls/manual/html_node/Selecting-cryptographic-key-sizes.html#Selecting-cryptographic-key-sizes
>
>  The values apply to DH parameters as well.

Ah, thanks.  I think that answer this question well.

I'm surprised openssl would accept such low DH parameters (which I
recall the debian BTS discussion implied?), it seems insecure to me.

/Simon




From massimo.gaspari at alice.it  Tue Apr 15 22:28:37 2008
From: massimo.gaspari at alice.it (Massimo Gaspari)
Date: Tue, 15 Apr 2008 22:28:37 +0200
Subject: [Help-gnutls] Re: gnutls 2.3.4 doesn't copile using MinGW
In-Reply-To: <87iqyjvi50.fsf@mocca.josefsson.org>
References: <47FFACC3.7010400@alice.it>
	<87fxtq9gjf.fsf@mocca.josefsson.org>	<4803B48B.4030409@alice.it>
	<87iqyjvi50.fsf@mocca.josefsson.org>
Message-ID: <48050FF5.7020909@alice.it>

Simon Josefsson wrote:
> Massimo Gaspari <massimo.gaspari at alice.it> writes:
>
>   
>> In the meantime I recompiled libgcrypt using
>>
>> ./configure --disable-shared --disable-asm --enable-random=w32
>> --disable-dev-random
>>
>> Do you think that the "random" options are correct to use the library
>> in a Windows environment (not using MinGW)?
>>     
>
> Yes.  I would think that the script will guess these values
> automatically though, so you probably don't need to specify them.  If it
> guesses the w32 module properly, the --disable-dev-random flag won't
> matter since the w32 module doesn't use /dev/random.
>
> Does building fail if you remove --disable-asm?  You may get a speed
> improvement if you remove it, but removing it can also cause build
> failures.
>
> /Simon
>   
I tried to compile libgcrypt without --disable-shared and I didn't 
observe any compilation issue. Moreover the make check was successfully.

Anyway I switched back to --disable-asm.


Massimo




From massimo.gaspari at alice.it  Tue Apr 15 23:40:07 2008
From: massimo.gaspari at alice.it (Massimo Gaspari)
Date: Tue, 15 Apr 2008 23:40:07 +0200
Subject: [Help-gnutls] Re: gnutls 2.3.4 doesn't copile using MinGW
In-Reply-To: <87mynvvi9k.fsf@mocca.josefsson.org>
References: <47FFACC3.7010400@alice.it>
	<87fxtq9gjf.fsf@mocca.josefsson.org>	<48027017.6090508@alice.it>
	<87mynvvi9k.fsf@mocca.josefsson.org>
Message-ID: <480520B7.60302@alice.it>

Simon Josefsson wrote:
>> /bin/sh ../libtool --tag=CC   --mode=link gcc -std=gnu99 -pipe
>> -I/usr/local/include -O2 -Wno-pointer-sign   -o gnutls-serv.exe
>> serv-gaa.o serv.o common.o select.o ../lib/libgnutls.la
>> -L/usr/local/lib -lgcrypt -lgpg-error  ../gl/libgnu.la -lws2_32
>> libtool: link: gcc -std=gnu99 -pipe -I/usr/local/include -O2
>> -Wno-pointer-sign -o gnutls-serv.exe serv-gaa.o serv.o common.o
>> select.o  ../lib/.libs/libgnutls.a -L/usr/local/lib
>> ../gl/.libs/libgnu.a /usr/local/lib/libgcrypt.a
>> /usr/local/lib/libgpg-error.a -lws2_32
>> C:/msys/1.0/local/lib/libgcrypt.a(libgcrypt_la-missing-string.o):missing-string.c:(.text+0x30):
>> multiple definition of `_vasprintf'
>> ../lib/.libs/libgnutls.a(vasprintf.o):vasprintf.c:(.text+0x0): first
>> defined here
>> collect2: ld returned 1 exit status
>> make[3]: *** [gnutls-serv.exe] Error 1
>> make[3]: Leaving directory `/home/Massimo/gnutls-2.3.4/src'
>> make[2]: *** [all-recursive] Error 1
>> make[2]: Leaving directory `/home/Massimo/gnutls-2.3.4/src'
>> make[1]: *** [all-recursive] Error 1
>> make[1]: Leaving directory `/home/Massimo/gnutls-2.3.4'
>> make: *** [all] Error 2
>>
>> This time "touch" can't help :-).
>>
>> Any other suggestion?
>>     
>
> Ouch, this isn't a fun problem. :-(
>
> I've known about this for some time, but don't know a good solution.
>
> The problem is that libgcrypt defines a 'vasprintf' function, and it is
> stored in the static library.
>
> GnuTLS also defines a 'vasprintf' function.
>
> When you use shared libraries, this isn't a problem because the
> namespaces won't collide, so the symbols will just be hidden.
>
> But with static libraries, both symbols are there, and they collide.
>
> The interesting thing is that my Windows builds (see
> <http://josefsson.org/gnutls4win/>) do not trigger this problem.  I
> build both shared and static libraries.  So maybe you could see if
> building shared libraries for some strange reason makes the static
> library link for you?
>
> I'm not sure what the best solution is.  Possibly 'vasprintf' shouldn't
> be exported, but with static libraries, I don't think that is possible.
> All symbols used are exported.  So maybe the symbol needs to be renamed.
>
> This is a general problem with linking multiple libraries that use
> modules from gnulib, so I should bring this up on the gnulib list.
>
>   

Wouldn't it be better to use the symbol gnutls_vasprintf in GnuTLS? 
There are few files using that symbol, stdio.h.in and three .c file, 
it's easy to do it. Is there any issue to do that?
That may solve the problem. I'll try to do it.
>>  Nevertheless during compilation I got the followin warnings
>>
>> libtool: compile:  gcc -std=gnu99 -DHAVE_CONFIG_H
>> -I. -I../.. -I../../lgl -I../../lgl -I../../libextra
>> -I../../lib/minitasn1 -I../../libextra/openpgp/
>> -I../../libextra/opencdk -I../../lib -I../../includes -I../../includes
>> -I/usr/local/include -pipe -I/usr/local/include -O2 -Wno-pointer-sign
>> -MT x509.lo -MD -MP -MF .deps/x509.Tpo -c x509.c -o x509.o
>> x509.c: In function '_gnutls_x509_crt_cpy':
>> x509.c:95: warning: implicit declaration of function 'alloca'
>> x509.c:95: warning: incompatible implicit declaration of built-in
>> function 'alloca'
>> x509.c: In function 'gnutls_x509_crt_get_fingerprint':
>> x509.c:1965: warning: incompatible implicit declaration of built-in
>> function 'alloca'
>> x509.c: In function 'gnutls_x509_crt_get_key_id':
>> x509.c:2160: warning: incompatible implicit declaration of built-in
>> function 'alloca'
>> mv -f .deps/x509.Tpo .deps/x509.Plo
>>
>>
>> The same warning is present for other files as well. Do you need a
>> full list?
>>     
>
> No, that error is sufficient for me.
>
> Does your system have alloca.h?  What does ./configure say about alloca?
>   

No MinGW hasn't the alloca.h. The configure script gave me the following 
messages

checking alloca.h usability... no
checking alloca.h presence... no
checking for alloca.h... no

and

checking for working alloca.h... no
checking for alloca... yes

and I got

#define HAVE_ALLOCA 1

in config.h. I found definition for alloca in malloc.h (MinGW include file).

Ok I added gnutls_ and edit config.h after the configure step using
#define HAVE_ALLOCA 0
#define HAVE_ALLOCA_H 0

and I did "make". Both issues seems disappeared (I got the  warning

libtool: compile:  gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I../intl 
-I/usr/local/include -pipe -I/usr/local/include -O2 -Wno-pointer-sign 
-MT asprintf.lo -MD -MP -MF .deps/asprintf.Tpo -c asprintf.c -o asprintf.o
asprintf.c: In function 'asprintf':
asprintf.c:36: warning: implicit declaration of function 'gnutls_vasprintf'

but this can be fixed later.)

But now I have a new issue!!

/bin/sh ../../libtool --tag=CC   --mode=link gcc -std=gnu99 -pipe 
-I/usr/local/include -O2 -Wno-pointer-sign -no-install  -o 
ex-client2.exe ex-client2.o libexamples.la ../../gl/libgnu.la 
../../lib/libgnutls.la ../../libextra/libgnutls-extra.la -lws2_32
libtool: link: warning: `-no-install' is ignored for i686-pc-mingw32
libtool: link: warning: assuming `-no-fast-install' instead
libtool: link: gcc -std=gnu99 -pipe -I/usr/local/include -O2 
-Wno-pointer-sign -o ex-client2.exe ex-client2.o  ./.libs/libexamples.a 
../../gl/.libs/libgnu.a -L/usr/local/lib ../../lib/.libs/libgnutls.a 
../../libextra/.libs/libgnutls-extra.a 
/home/Massimo/gnutls-2.3.5/lib/.libs/libgnutls.a -lz 
/usr/local/lib/libgcrypt.a /usr/local/lib/libgpg-error.a -lws2_32
../../lib/.libs/libgnutls.a(stream.o):stream.c:(.text+0xb7a): undefined 
reference to `_rpl_fseeko'
../../lib/.libs/libgnutls.a(armor.o):armor.c:(.text+0x7a2): undefined 
reference to `_rpl_fseeko'
collect2: ld returned 1 exit status
make[4]: *** [ex-client2.exe] Error 1
make[4]: Leaving directory `/home/Massimo/gnutls-2.3.5/doc/examples'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/home/Massimo/gnutls-2.3.5/doc'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/Massimo/gnutls-2.3.5/doc'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/Massimo/gnutls-2.3.5'
make: *** [all] Error 2

Compiling the example I think the oder of libs is wrong. libgnu.a (that 
contains the missed symbols) should be the latest.

I edited the Makefile in doc/example changing

LIBS =  -lws2_32

to

LIBS =  -lws2_32 ../../gl/.libs/libgnu.a


and this issue disappeared.

But now I got another one!!!

rm -rf $backupdir; exit $rc
gnutls.texi:429: @image file `gnutls-internals.txt' (for text) 
unreadable: No such file or directory.
gnutls.texi:593: @image file `gnutls-layers.txt' (for text) unreadable: 
No such file or directory.
gnutls.texi:1523: Unknown command `headitem'.
gnutls.texi:1633: @image file `gnutls-x509.txt' (for text) unreadable: 
No such file or directory.
gnutls.texi:1867: @image file `gnutls-pgp.txt' (for text) unreadable: No 
such file or directory.
./signatures.texi:14: Unknown command `euro'.
./signatures.texi:14: Misplaced {.
./signatures.texi:14: Misplaced }.
./signatures.texi:15: Unknown command `euro'.
./signatures.texi:15: Misplaced {.
./signatures.texi:15: Misplaced }.
gnutls.texi:3469: @image file `gnutls-client-server-use-case.txt' (for 
text) unreadable: No such file or directory.
gnutls.texi:3475: @image file `gnutls-objects.txt' (for text) 
unreadable: No such file or directory.
gnutls.texi:3483: @image file `gnutls-handshake-state.txt' (for text) 
unreadable: No such file or directory.
gnutls.texi:3492: @image file `gnutls-handshake-sequence.txt' (for text) 
unreadable: No such file or directory.
gnutls.texi:3500: @image file `gnutls-mod_auth_st.txt' (for text) 
unreadable: No such file or directory.
gnutls.texi:3515: @image file `gnutls-extensions_st.txt' (for text) 
unreadable: No such file or directory.
gnutls.texi:3691: @image file `gnutls-certificate-user-use-case.txt' 
(for text) unreadable: No such file or directory.
makeinfo: Removing output file `gnutls.info' due to errors; use --force 
to preserve.
make[4]: *** [gnutls.info] Error 1
make[4]: Leaving directory `/home/Massimo/gnutls-2.3.5/doc'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/home/Massimo/gnutls-2.3.5/doc'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/Massimo/gnutls-2.3.5/doc'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/Massimo/gnutls-2.3.5'
make: *** [all] Error 2


Why the doc processing is mandatory with make? Usually a 'make doc' is 
used avoiding doc processing if it's not required. (I got a pdf from the 
GnuTLS home site).


OK I surrend .......for the moment

Hope this helps.

Massimo





From simon at josefsson.org  Wed Apr 16 12:50:54 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 16 Apr 2008 12:50:54 +0200
Subject: [Help-gnutls] Re: gnutls 2.3.4 doesn't copile using MinGW
In-Reply-To: <48050FF5.7020909@alice.it> (Massimo Gaspari's message of "Tue,
	15 Apr 2008 22:28:37 +0200")
References: <47FFACC3.7010400@alice.it> <87fxtq9gjf.fsf@mocca.josefsson.org>
	<4803B48B.4030409@alice.it> <87iqyjvi50.fsf@mocca.josefsson.org>
	<48050FF5.7020909@alice.it>
Message-ID: <87abju9ipd.fsf@mocca.josefsson.org>

Massimo Gaspari <massimo.gaspari at alice.it> writes:

> Simon Josefsson wrote:
>> Massimo Gaspari <massimo.gaspari at alice.it> writes:
>>
>>   
>>> In the meantime I recompiled libgcrypt using
>>>
>>> ./configure --disable-shared --disable-asm --enable-random=w32
>>> --disable-dev-random
>>>
>>> Do you think that the "random" options are correct to use the library
>>> in a Windows environment (not using MinGW)?
>>>     
>>
>> Yes.  I would think that the script will guess these values
>> automatically though, so you probably don't need to specify them.  If it
>> guesses the w32 module properly, the --disable-dev-random flag won't
>> matter since the w32 module doesn't use /dev/random.
>>
>> Does building fail if you remove --disable-asm?  You may get a speed
>> improvement if you remove it, but removing it can also cause build
>> failures.
>>
>> /Simon
>>   
> I tried to compile libgcrypt without --disable-shared and I didn't
> observe any compilation issue. Moreover the make check was
> successfully.

What about doing the same for GnuTLS builds too?  Chances are that
you'll get static libraries out of it that builds, at least I do using
MinGW under linux.

> Anyway I switched back to --disable-asm.

I'm not sure I understand -- did you get errors if you removed it?

/Simon




From simon at josefsson.org  Wed Apr 16 13:00:48 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 16 Apr 2008 13:00:48 +0200
Subject: [Help-gnutls] Re: gnutls 2.3.4 doesn't copile using MinGW
In-Reply-To: <480520B7.60302@alice.it> (Massimo Gaspari's message of "Tue, 15
	Apr 2008 23:40:07 +0200")
References: <47FFACC3.7010400@alice.it> <87fxtq9gjf.fsf@mocca.josefsson.org>
	<48027017.6090508@alice.it> <87mynvvi9k.fsf@mocca.josefsson.org>
	<480520B7.60302@alice.it>
Message-ID: <8763ui9i8v.fsf@mocca.josefsson.org>

Massimo Gaspari <massimo.gaspari at alice.it> writes:

>> Ouch, this isn't a fun problem. :-(
>>
>> I've known about this for some time, but don't know a good solution.
>>
>> The problem is that libgcrypt defines a 'vasprintf' function, and it is
>> stored in the static library.
>>
>> GnuTLS also defines a 'vasprintf' function.
>>
>> When you use shared libraries, this isn't a problem because the
>> namespaces won't collide, so the symbols will just be hidden.
>>
>> But with static libraries, both symbols are there, and they collide.
>>
>> The interesting thing is that my Windows builds (see
>> <http://josefsson.org/gnutls4win/>) do not trigger this problem.  I
>> build both shared and static libraries.  So maybe you could see if
>> building shared libraries for some strange reason makes the static
>> library link for you?
>>
>> I'm not sure what the best solution is.  Possibly 'vasprintf' shouldn't
>> be exported, but with static libraries, I don't think that is possible.
>> All symbols used are exported.  So maybe the symbol needs to be renamed.
>>
>> This is a general problem with linking multiple libraries that use
>> modules from gnulib, so I should bring this up on the gnulib list.
>>
>>   
>
> Wouldn't it be better to use the symbol gnutls_vasprintf in GnuTLS?
> There are few files using that symbol, stdio.h.in and three .c file,
> it's easy to do it. Is there any issue to do that?
> That may solve the problem. I'll try to do it.

Yes, that is one solution, however doing it systematically for each and
every symbol defined by gnulib is a lot of work.

Maybe you could add '#define vasprintf gnutls_vasprintf' in your
config.h when building GnuTLS?  I'm not sure it will work, but something
like that will be necessary to fully solve this problem.

>>> x509.c: In function '_gnutls_x509_crt_cpy':
>>> x509.c:95: warning: implicit declaration of function 'alloca'
>>> x509.c:95: warning: incompatible implicit declaration of built-in
>>> function 'alloca'
...
>> Does your system have alloca.h?  What does ./configure say about alloca?
>>   
>
> No MinGW hasn't the alloca.h. The configure script gave me the
> following messages
>
> checking alloca.h usability... no
> checking alloca.h presence... no
> checking for alloca.h... no
>
> and
>
> checking for working alloca.h... no
> checking for alloca... yes
>
> and I got
>
> #define HAVE_ALLOCA 1
>
> in config.h. I found definition for alloca in malloc.h (MinGW include file).

Thanks.  We should use the gnulib alloca module.  I'll see if I can fix
this.

> Ok I added gnutls_ and edit config.h after the configure step using
> #define HAVE_ALLOCA 0
> #define HAVE_ALLOCA_H 0
>
> and I did "make". Both issues seems disappeared

That's a fine workaround meanwhile.

> (I got the warning
>
> libtool: compile:  gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I../intl
> -I/usr/local/include -pipe -I/usr/local/include -O2 -Wno-pointer-sign
> -MT asprintf.lo -MD -MP -MF .deps/asprintf.Tpo -c asprintf.c -o
> asprintf.o
> asprintf.c: In function 'asprintf':
> asprintf.c:36: warning: implicit declaration of function 'gnutls_vasprintf'
>
> but this can be fixed later.)

Yup, related to the gnutls_vasprintf problem.

> But now I have a new issue!!
>
> /bin/sh ../../libtool --tag=CC   --mode=link gcc -std=gnu99 -pipe
> -I/usr/local/include -O2 -Wno-pointer-sign -no-install  -o 
> ex-client2.exe ex-client2.o libexamples.la ../../gl/libgnu.la
> ../../lib/libgnutls.la ../../libextra/libgnutls-extra.la -lws2_32
> libtool: link: warning: `-no-install' is ignored for i686-pc-mingw32
> libtool: link: warning: assuming `-no-fast-install' instead
> libtool: link: gcc -std=gnu99 -pipe -I/usr/local/include -O2
> -Wno-pointer-sign -o ex-client2.exe ex-client2.o
> ./.libs/libexamples.a ../../gl/.libs/libgnu.a -L/usr/local/lib
> ../../lib/.libs/libgnutls.a ../../libextra/.libs/libgnutls-extra.a
> /home/Massimo/gnutls-2.3.5/lib/.libs/libgnutls.a -lz
> /usr/local/lib/libgcrypt.a /usr/local/lib/libgpg-error.a -lws2_32
> ../../lib/.libs/libgnutls.a(stream.o):stream.c:(.text+0xb7a):
> undefined reference to `_rpl_fseeko'
> ../../lib/.libs/libgnutls.a(armor.o):armor.c:(.text+0x7a2): undefined
> reference to `_rpl_fseeko'
> collect2: ld returned 1 exit status
> make[4]: *** [ex-client2.exe] Error 1
> make[4]: Leaving directory `/home/Massimo/gnutls-2.3.5/doc/examples'
> make[3]: *** [all-recursive] Error 1
> make[3]: Leaving directory `/home/Massimo/gnutls-2.3.5/doc'
> make[2]: *** [all] Error 2
> make[2]: Leaving directory `/home/Massimo/gnutls-2.3.5/doc'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/Massimo/gnutls-2.3.5'
> make: *** [all] Error 2
>
> Compiling the example I think the oder of libs is wrong. libgnu.a
> (that contains the missed symbols) should be the latest.
>
> I edited the Makefile in doc/example changing
>
> LIBS =  -lws2_32
>
> to
>
> LIBS =  -lws2_32 ../../gl/.libs/libgnu.a
>
>
> and this issue disappeared.

I'm not sure if it will solve this, but I changed the order of libgnu.la
in Makefile.am.  Please test tomorrow's snapshot.

>
> But now I got another one!!!
>
> rm -rf $backupdir; exit $rc
> gnutls.texi:429: @image file `gnutls-internals.txt' (for text)
> unreadable: No such file or directory.
> gnutls.texi:593: @image file `gnutls-layers.txt' (for text)
> unreadable: No such file or directory.
> gnutls.texi:1523: Unknown command `headitem'.
> gnutls.texi:1633: @image file `gnutls-x509.txt' (for text) unreadable:
> No such file or directory.
> gnutls.texi:1867: @image file `gnutls-pgp.txt' (for text) unreadable:
> No such file or directory.
> ./signatures.texi:14: Unknown command `euro'.
> ./signatures.texi:14: Misplaced {.
> ./signatures.texi:14: Misplaced }.
> ./signatures.texi:15: Unknown command `euro'.
> ./signatures.texi:15: Misplaced {.
> ./signatures.texi:15: Misplaced }.
> gnutls.texi:3469: @image file `gnutls-client-server-use-case.txt' (for
> text) unreadable: No such file or directory.
> gnutls.texi:3475: @image file `gnutls-objects.txt' (for text)
> unreadable: No such file or directory.
> gnutls.texi:3483: @image file `gnutls-handshake-state.txt' (for text)
> unreadable: No such file or directory.
> gnutls.texi:3492: @image file `gnutls-handshake-sequence.txt' (for
> text) unreadable: No such file or directory.
> gnutls.texi:3500: @image file `gnutls-mod_auth_st.txt' (for text)
> unreadable: No such file or directory.
> gnutls.texi:3515: @image file `gnutls-extensions_st.txt' (for text)
> unreadable: No such file or directory.
> gnutls.texi:3691: @image file `gnutls-certificate-user-use-case.txt'
> (for text) unreadable: No such file or directory.
> makeinfo: Removing output file `gnutls.info' due to errors; use
> --force to preserve.
> make[4]: *** [gnutls.info] Error 1
> make[4]: Leaving directory `/home/Massimo/gnutls-2.3.5/doc'
> make[3]: *** [all-recursive] Error 1
> make[3]: Leaving directory `/home/Massimo/gnutls-2.3.5/doc'
> make[2]: *** [all] Error 2
> make[2]: Leaving directory `/home/Massimo/gnutls-2.3.5/doc'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/Massimo/gnutls-2.3.5'
> make: *** [all] Error 2
>
>
> Why the doc processing is mandatory with make? Usually a 'make doc' is
> used avoiding doc processing if it's not required. (I got a pdf from
> the GnuTLS home site).

To build the manual, you need a newer texinfo.  However, building it
shouldn't be required unless you modified any source files that is used
by the manual.  Possibly you have done that...  I think this should go
away when all your other build problems are solved in the official
distribution.

I think you are making good progress.   Let's keep trying..

/Simon




From massimo.gaspari at alice.it  Wed Apr 16 19:54:26 2008
From: massimo.gaspari at alice.it (Massimo Gaspari)
Date: Wed, 16 Apr 2008 19:54:26 +0200
Subject: [Help-gnutls] Re: gnutls 2.3.4 doesn't copile using MinGW
In-Reply-To: <87abju9ipd.fsf@mocca.josefsson.org>
References: <47FFACC3.7010400@alice.it>
	<87fxtq9gjf.fsf@mocca.josefsson.org>	<4803B48B.4030409@alice.it>
	<87iqyjvi50.fsf@mocca.josefsson.org>	<48050FF5.7020909@alice.it>
	<87abju9ipd.fsf@mocca.josefsson.org>
Message-ID: <48063D52.8040802@alice.it>

Simon Josefsson wrote:
> Massimo Gaspari <massimo.gaspari at alice.it> writes:
>
>   
> What about doing the same for GnuTLS builds too?  Chances are that
> you'll get static libraries out of it that builds, at least I do using
> MinGW under linux.
>
>   

I tried. It seems that the vasprintf issue disappeared. But I got other 
issues related to undefined references. I have to investigate more on that.
But I'm about to have a successful compilation of the static 
libraries..so I'll see
>> Anyway I switched back to --disable-asm.
>>     
>
> I'm not sure I understand -- did you get errors if you removed it?
>
> /Simon
>
>   
No problem. But I'd like to change one thing at a time. Once I'm able to 
compile gnutls I'll remove the --disable-shared.
As far as you know are the assembler routine reliable?

Massimo

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20080416/086f9cd6/attachment.htm>

From massimo.gaspari at alice.it  Wed Apr 16 20:18:29 2008
From: massimo.gaspari at alice.it (Massimo Gaspari)
Date: Wed, 16 Apr 2008 20:18:29 +0200
Subject: [Help-gnutls] Re: gnutls 2.3.4 doesn't copile using MinGW
In-Reply-To: <8763ui9i8v.fsf@mocca.josefsson.org>
References: <47FFACC3.7010400@alice.it>
	<87fxtq9gjf.fsf@mocca.josefsson.org>	<48027017.6090508@alice.it>
	<87mynvvi9k.fsf@mocca.josefsson.org>	<480520B7.60302@alice.it>
	<8763ui9i8v.fsf@mocca.josefsson.org>
Message-ID: <480642F5.8000907@alice.it>

Simon Josefsson wrote:

> Massimo Gaspari <massimo.gaspari at alice.it> writes:

> Yes, that is one solution, however doing it systematically for each and
> every symbol defined by gnulib is a lot of work.
>
> Maybe you could add '#define vasprintf gnutls_vasprintf' in your
> config.h when building GnuTLS?  I'm not sure it will work, but something
> like that will be necessary to fully solve this problem.
>
>   
Up to now only the vasprintf seems to have problems. So It's not 
difficult to change the code.
>>
>> I edited the Makefile in doc/example changing
>>
>> LIBS =  -lws2_32
>>
>> to
>>
>> LIBS =  -lws2_32 ../../gl/.libs/libgnu.a
>>
>>
>> and this issue disappeared.
>>     
>
> I'm not sure if it will solve this, but I changed the order of libgnu.la
> in Makefile.am.  Please test tomorrow's snapshot.
>
>   
In my opinion it fixes the issue. Moreover if you use the following link

http://hpux.cs.utah.edu/hppd/cgi-bin/wwwtar?/hpux/Gnu/gnutls-2.3.4/gnutls-2.3.4-src-11.11.tar.gz+gnutls-2.3.4/HPUX.Install+text

you find some suggestion to get GnuTls compiled in HPUX for 2.3.4. 
There's the following comment

* doc/examples/Makefile.in:
  - Use ../../gl/.libs/libgnu.la at the end of the libtool link line
    to link examples, rather than ../../gl/libgnu.la in the middle of the
    line. This avoids a missing rpl_strerror symbol when linking on the
    Itanium platform.

So I'm not alone :-)

>
> To build the manual, you need a newer texinfo.  However, building it
> shouldn't be required unless you modified any source files that is used
> by the manual.  Possibly you have done that...  I think this should go
> away when all your other build problems are solved in the official
> distribution.
>   
I'll update the texinfo package. In the meantime I can skip the doc 
building using an empty Makefile

all:
check:

(quick and dirty, but better than an error)

So now I'm able to get gnutls compiled . Here's the full story

I get gnutls-2.3.5.tar.bz2 then

1) libgpg-error

./configure --disable-shared --disable-rpath
make
make check
make install


2) libgcrypt

./configure --disable-shared --disable-asm --enable-random=w32 
--disable-dev-random

make
make check
make install

3) GnuTLS

Edit the sources changing any vasprintf to gnutls_vasprintf (stdio.in.h, 
vasprintf.c, asprintf.c and gnutls_str.c)
Edit the config.h.in to have #define HAVE_ALLOCA 0 and #define 
HAVE_ALLOCA_H 0

./configure --disable-shared --disable-rpath --disable-cxx --disable-guile

Edit config.h to have #define HAVE_ALLOCA 0 (configure sets HAVE_ALLOCA 1)
Edit Makefile in doc to do nothing
Edit Makefile in doc/example adding ../../gl/libgnu.la to LIBS

4) make

Yup, it does! The compilation ended without any error, just two warnings 
only. All other issues disappear. The warnings are

/bin/sh ../libtool --tag=CC   --mode=compile gcc -std=gnu99 
-DHAVE_CONFIG_H -I. -I..  -DLOCALEDIR=\"/usr/local/share/locale\"       
-I../lgl -I../lgl -I../includes -I../includes -I./x509 -I../libextra 
-I../lib/openpgp/ -I../lib/opencdk  -I/usr/local/includ      e 
-I./opencdk -I./minitasn1   -pipe -I/usr/local/include -Wno-pointer-sign 
-MT pkix_asn1_tab.lo -MD -MP -MF .deps/pkix_asn1_t      ab.Tpo -c -o 
pkix_asn1_tab.lo pkix_asn1_tab.c
libtool: compile:  gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. 
-DLOCALEDIR=\"/usr/local/share/locale\" -I../lgl -I../lgl -I../inc      
ludes -I../includes -I./x509 -I../libextra -I../lib/openpgp/ 
-I../lib/opencdk -I/usr/local/include -I./opencdk -I./minitasn1       
-pipe -I/usr/local/include -Wno-pointer-sign -MT pkix_asn1_tab.lo -MD 
-MP -MF .deps/pkix_asn1_tab.Tpo -c pkix_asn1_tab.c -o p      kix_asn1_tab.o
pkix_asn1_tab.c:7: warning: 'pkix_asn1_tab' initialized and declared 
'extern'

mv -f .deps/pkix_asn1_tab.Tpo .deps/pkix_asn1_tab.Plo
/bin/sh ../libtool --tag=CC   --mode=compile gcc -std=gnu99 
-DHAVE_CONFIG_H -I. -I..  -DLOCALEDIR=\"/usr/local/share/locale\"       
-I../lgl -I../lgl -I../includes -I../includes -I./x509 -I../libextra 
-I../lib/openpgp/ -I../lib/opencdk  -I/usr/local/includ      e 
-I./opencdk -I./minitasn1   -pipe -I/usr/local/include -Wno-pointer-sign 
-MT gnutls_asn1_tab.lo -MD -MP -MF .deps/gnutls_as      n1_tab.Tpo -c -o 
gnutls_asn1_tab.lo gnutls_asn1_tab.c
libtool: compile:  gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. 
-DLOCALEDIR=\"/usr/local/share/locale\" -I../lgl -I../lgl -I../inc      
ludes -I../includes -I./x509 -I../libextra -I../lib/openpgp/ 
-I../lib/opencdk -I/usr/local/include -I./opencdk -I./minitasn1       
-pipe -I/usr/local/include -Wno-pointer-sign -MT gnutls_asn1_tab.lo -MD 
-MP -MF .deps/gnutls_asn1_tab.Tpo -c gnutls_asn1_tab.      c -o 
gnutls_asn1_tab.o
gnutls_asn1_tab.c:7: warning: 'gnutls_asn1_tab' initialized and declared 
'extern'

I think the compiler is right. The two variable are used in

pkix_asn1_tab.c
gnutls_global.c

in both files you use the extern qualifier, but in pkix_asn1_tab.c you 
also assign a "value". Wouldn't it be better to remove the extern 
qualifier in
pkix_asn1_tab.c? Ok is a very minor issue but avoid two warnings.

So is this the end of the story? Unfortunately no!!When I did 'make 
check' I got

==================
All 1 tests passed
==================
make[3]: Leaving directory `/home/emasgas/gnutls-2.3.5/tests/userid'
make[2]: Leaving directory `/home/emasgas/gnutls-2.3.5/tests/userid'
Making check in pathlen
make[2]: Entering directory `/home/emasgas/gnutls-2.3.5/tests/pathlen'
make  pathlen
make[3]: Entering directory `/home/emasgas/gnutls-2.3.5/tests/pathlen'
make[3]: Nothing to be done for `pathlen'.
make[3]: Leaving directory `/home/emasgas/gnutls-2.3.5/tests/pathlen'
make  check-TESTS
make[3]: Entering directory `/home/emasgas/gnutls-2.3.5/tests/pathlen'
NOTE: you should run 'diskperf -y' to enable the disk statistics
NOTE: you should run 'diskperf -y' to enable the disk statistics
NOTE: you should run 'diskperf -y' to enable the disk statistics
NOTE: you should run 'diskperf -y' to enable the disk statistics
NOTE: you should run 'diskperf -y' to enable the disk statistics
NOTE: you should run 'diskperf -y' to enable the disk statistics
--- ./ca-no-pathlen.pem Mon Feb 25 16:20:41 2008
+++ new-ca-no-pathlen.pem       Wed Apr 16 15:13:11 2008
@@ -3,8 +3,8 @@
        Serial Number (hex): 00
        Issuer: O=GnuTLS test certificate
        Validity:
-               Not Before: Fri Jan 26 10:00:04 UTC 2007
-               Not After: Sat Jan 27 10:00:06 UTC 2007
+               Not Before: Fri Jan  10:00:04 UTC 2007
+               Not After: Sat Jan  10:00:06 UTC 2007
        Subject: O=GnuTLS test certificate
        Subject Public Key Algorithm: RSA
                Modulus (bits 512):
FAIL: pathlen
===================================
1 of 1 tests failed
Please report to bug-gnutls at gnu.org
===================================
make[3]: *** [check-TESTS] Error 1
make[3]: Leaving directory `/home/emasgas/gnutls-2.3.5/tests/pathlen'
make[2]: *** [check-am] Error 2
make[2]: Leaving directory `/home/emasgas/gnutls-2.3.5/tests/pathlen'
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory `/home/emasgas/gnutls-2.3.5/tests'
make: *** [check-recursive] Error 1

Googling the internet I  got the opinion that this may be related to 
isprint(), I'm not sure anyway. Is the following recommandation (from 
HPUX suggestions) relevat to the failure?

* lib/x509/output.c:
  - The isprint() routine on Itanium platforms seemed to like printing
    8-bit chars (possibly to do with the sign of the char?), so changed it
    to simply print any char between ' ' and '~'. Without this change,
    Itanium's "gmake check" fails one of the checks.

Just for verification I repeated the whole process twice (from scratch) 
using

CFLAGS=-O2

and

CFLAGS=

getting exactly the same results

So the optimizer is not involved.

I absolutely need your help to fix the latest issue.

Massimo

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

From dbreiser at gmail.com  Thu Apr 17 02:48:56 2008
From: dbreiser at gmail.com (David Reiser)
Date: Wed, 16 Apr 2008 20:48:56 -0400
Subject: [Help-gnutls] Re: duplicate symbols complaint on Mac OS X 10.5.2
In-Reply-To: <87wsn6p66s.fsf@mocca.josefsson.org>
References: <922d0b4d0802172330r33f794edu8b968adfee626357@mail.gmail.com>
	<87myp5jltq.fsf@mocca.josefsson.org>
	<D311DE37-F970-43EF-A1AB-394C6E407C16@gmail.com>
	<87myowwf5k.fsf@gnu.org>
	<8FD0D2D5-29C7-4E1B-9FB9-1CCB29E20438@gmail.com>
	<87ve3jn6na.fsf@gnu.org>
	<01646597-495C-4D75-8F65-665209687F06@gmail.com>
	<87d4pqj4zc.fsf@gnu.org>
	<FEB5CC46-BC82-44A6-BB6B-BE7EE1072B71@gmail.com>
	<87od9adag8.fsf@mocca.josefsson.org> <87k5jy4skb.fsf@gnu.org>
	<24445E26-11FC-479E-8501-8E4516194F52@gmail.com>
	<87ve3h4x2f.fsf@gnu.org> <87r6e5bubw.fsf@mocca.josefsson.org>
	<87prtpsh2v.fsf@gnu.org> <87y78dv53u.fsf@mocca.josefsson.org>
	<87od90clgu.fsf@gnu.org> <874pabcvq0.fsf@mocca.josefsson.org>
	<87od8jph7w.fsf@gnu.org> <87wsn6p66s.fsf@mocca.josefsson.org>
Message-ID: <A6B2D1C3-901C-4208-B93E-24C20D13E118@gmail.com>


On Apr 10, 2008, at 2:36 AM, Simon Josefsson wrote:
...
> Which isn't entirely impossible from what I understand, so I'd
> appreciate if David could try building Guile with the patch and then
> build gnutls.


I still get the duplicate symbols error. Should I be surprised that a  
change in guile doesn't cure a gmp problem?

Dave
--
David Reiser
dbreiser at gmail.com







From simon at josefsson.org  Thu Apr 17 10:17:27 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 17 Apr 2008 10:17:27 +0200
Subject: [Help-gnutls] Re: duplicate symbols complaint on Mac OS X 10.5.2
In-Reply-To: <A6B2D1C3-901C-4208-B93E-24C20D13E118@gmail.com> (David Reiser's
	message of "Wed, 16 Apr 2008 20:48:56 -0400")
References: <922d0b4d0802172330r33f794edu8b968adfee626357@mail.gmail.com>
	<87myp5jltq.fsf@mocca.josefsson.org>
	<D311DE37-F970-43EF-A1AB-394C6E407C16@gmail.com>
	<87myowwf5k.fsf@gnu.org>
	<8FD0D2D5-29C7-4E1B-9FB9-1CCB29E20438@gmail.com>
	<87ve3jn6na.fsf@gnu.org>
	<01646597-495C-4D75-8F65-665209687F06@gmail.com>
	<87d4pqj4zc.fsf@gnu.org>
	<FEB5CC46-BC82-44A6-BB6B-BE7EE1072B71@gmail.com>
	<87od9adag8.fsf@mocca.josefsson.org> <87k5jy4skb.fsf@gnu.org>
	<24445E26-11FC-479E-8501-8E4516194F52@gmail.com>
	<87ve3h4x2f.fsf@gnu.org> <87r6e5bubw.fsf@mocca.josefsson.org>
	<87prtpsh2v.fsf@gnu.org> <87y78dv53u.fsf@mocca.josefsson.org>
	<87od90clgu.fsf@gnu.org> <874pabcvq0.fsf@mocca.josefsson.org>
	<87od8jph7w.fsf@gnu.org> <87wsn6p66s.fsf@mocca.josefsson.org>
	<A6B2D1C3-901C-4208-B93E-24C20D13E118@gmail.com>
Message-ID: <87ej9499pk.fsf@mocca.josefsson.org>

David Reiser <dbreiser at gmail.com> writes:

> On Apr 10, 2008, at 2:36 AM, Simon Josefsson wrote:
> ...
>> Which isn't entirely impossible from what I understand, so I'd
>> appreciate if David could try building Guile with the patch and then
>> build gnutls.
>
>
> I still get the duplicate symbols error. Should I be surprised that a
> change in guile doesn't cure a gmp problem?

Probably not, could you also try to re-compile gmp with this patch?

http://permalink.gmane.org/gmane.comp.lib.gmp.bugs/1979

Ludovic, is that the latest patch for gmp?

/Simon




From simon at josefsson.org  Thu Apr 17 10:59:43 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 17 Apr 2008 10:59:43 +0200
Subject: [Help-gnutls] Re: gnutls 2.3.4 doesn't copile using MinGW
In-Reply-To: <48063D52.8040802@alice.it> (Massimo Gaspari's message of "Wed,
	16 Apr 2008 19:54:26 +0200")
References: <47FFACC3.7010400@alice.it> <87fxtq9gjf.fsf@mocca.josefsson.org>
	<4803B48B.4030409@alice.it> <87iqyjvi50.fsf@mocca.josefsson.org>
	<48050FF5.7020909@alice.it> <87abju9ipd.fsf@mocca.josefsson.org>
	<48063D52.8040802@alice.it>
Message-ID: <87bq4826ww.fsf@mocca.josefsson.org>

Massimo Gaspari <massimo.gaspari at alice.it> writes:

> Simon Josefsson wrote:
>> Massimo Gaspari <massimo.gaspari at alice.it> writes:
>>
>>   What about doing the same for GnuTLS builds too?  Chances are that
>> you'll get static libraries out of it that builds, at least I do using
>> MinGW under linux.
>
> I tried. It seems that the vasprintf issue disappeared.

Which matches was happened with mingw under linux.  This is quite
surprising to me, perhaps some vasprintf configure test turn out
different when building shared libraries?  I dunno.

> But I got other issues related to undefined references. I have to
> investigate more on that.  But I'm about to have a successful
> compilation of the static libraries..so I'll see

Ok no problem.  Building static libraries should be supported, so I
appreciate your effort in going through these problems (and especially
for reporting them!).

>>> Anyway I switched back to --disable-asm.
>>>     
>>
>> I'm not sure I understand -- did you get errors if you removed it?
>>
>> /Simon
>>
>>   
> No problem. But I'd like to change one thing at a time. Once I'm able
> to compile gnutls I'll remove the --disable-shared.
> As far as you know are the assembler routine reliable?

Yes, they are used by most users.  However, if you get assembler related
build errors, it is usually not worth the effort to track it down; just
use --disable-asm instead.

/Simon




From ludo at gnu.org  Thu Apr 17 11:11:33 2008
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Thu, 17 Apr 2008 11:11:33 +0200
Subject: [Help-gnutls] Re: duplicate symbols complaint on Mac OS X 10.5.2
References: <922d0b4d0802172330r33f794edu8b968adfee626357@mail.gmail.com>
	<87myp5jltq.fsf@mocca.josefsson.org>
	<D311DE37-F970-43EF-A1AB-394C6E407C16@gmail.com>
	<87myowwf5k.fsf@gnu.org>
	<8FD0D2D5-29C7-4E1B-9FB9-1CCB29E20438@gmail.com>
	<87ve3jn6na.fsf@gnu.org>
	<01646597-495C-4D75-8F65-665209687F06@gmail.com>
	<87d4pqj4zc.fsf@gnu.org>
	<FEB5CC46-BC82-44A6-BB6B-BE7EE1072B71@gmail.com>
	<87od9adag8.fsf@mocca.josefsson.org> <87k5jy4skb.fsf@gnu.org>
	<24445E26-11FC-479E-8501-8E4516194F52@gmail.com>
	<87ve3h4x2f.fsf@gnu.org> <87r6e5bubw.fsf@mocca.josefsson.org>
	<87prtpsh2v.fsf@gnu.org> <87y78dv53u.fsf@mocca.josefsson.org>
	<87od90clgu.fsf@gnu.org> <874pabcvq0.fsf@mocca.josefsson.org>
	<87od8jph7w.fsf@gnu.org> <87wsn6p66s.fsf@mocca.josefsson.org>
	<A6B2D1C3-901C-4208-B93E-24C20D13E118@gmail.com>
Message-ID: <87prsoonga.fsf@gnu.org>

Hi David,

David Reiser <dbreiser at gmail.com> writes:

> I still get the duplicate symbols error. Should I be surprised that a
> change in guile doesn't cure a gmp problem?

Guile 1.8.5 will have all the patches needed to fix the problem.  I
emailed the GMP folks too but haven't heard from them [0].

Unfortunately, in the meantime, you'll have to patch things by hand,
along the lines of:

  http://thread.gmane.org/gmane.network.gnutls.general/1135

Or maybe you can try building GnuTLS with "make CFLAGS=-std=c89"?

Thanks,
Ludovic.

[0] http://article.gmane.org/gmane.comp.lib.gmp.bugs/1979/focus=1984





From simon at josefsson.org  Thu Apr 17 11:21:07 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 17 Apr 2008 11:21:07 +0200
Subject: [Help-gnutls] Re: gnutls 2.3.4 doesn't copile using MinGW
In-Reply-To: <480642F5.8000907@alice.it> (Massimo Gaspari's message of "Wed,
	16 Apr 2008 20:18:29 +0200")
References: <47FFACC3.7010400@alice.it> <87fxtq9gjf.fsf@mocca.josefsson.org>
	<48027017.6090508@alice.it> <87mynvvi9k.fsf@mocca.josefsson.org>
	<480520B7.60302@alice.it> <8763ui9i8v.fsf@mocca.josefsson.org>
	<480642F5.8000907@alice.it>
Message-ID: <877iew25x8.fsf@mocca.josefsson.org>

Massimo Gaspari <massimo.gaspari at alice.it> writes:

> Simon Josefsson wrote:
>
>> Massimo Gaspari <massimo.gaspari at alice.it> writes:
>
>> Yes, that is one solution, however doing it systematically for each and
>> every symbol defined by gnulib is a lot of work.
>>
>> Maybe you could add '#define vasprintf gnutls_vasprintf' in your
>> config.h when building GnuTLS?  I'm not sure it will work, but something
>> like that will be necessary to fully solve this problem.
>>   
> Up to now only the vasprintf seems to have problems. So It's not
> difficult to change the code.

Right.

> Moreover if you use the following link
>
> http://hpux.cs.utah.edu/hppd/cgi-bin/wwwtar?/hpux/Gnu/gnutls-2.3.4/gnutls-2.3.4-src-11.11.tar.gz+gnutls-2.3.4/HPUX.Install+text
>
> you find some suggestion to get GnuTls compiled in HPUX for
> 2.3.4. There's the following comment
>
> * doc/examples/Makefile.in:
>  - Use ../../gl/.libs/libgnu.la at the end of the libtool link line
>    to link examples, rather than ../../gl/libgnu.la in the middle of the
>    line. This avoids a missing rpl_strerror symbol when linking on the
>    Itanium platform.
>
> So I'm not alone :-)

Thanks for the pointer!  There is plenty of stuff we should fix there.
I'll go through it.  I don't have access to a HPUX platform, but some
may be possible to fix anyway.

>> To build the manual, you need a newer texinfo.  However, building it
>> shouldn't be required unless you modified any source files that is used
>> by the manual.  Possibly you have done that...  I think this should go
>> away when all your other build problems are solved in the official
>> distribution.
>>   
> I'll update the texinfo package. In the meantime I can skip the doc
> building using an empty Makefile
>
> all:
> check:
>
> (quick and dirty, but better than an error)

Yup.

> 3) GnuTLS
>
> Edit the sources changing any vasprintf to gnutls_vasprintf
> (stdio.in.h, vasprintf.c, asprintf.c and gnutls_str.c)
> Edit the config.h.in to have #define HAVE_ALLOCA 0 and #define
> HAVE_ALLOCA_H 0
>
> ./configure --disable-shared --disable-rpath --disable-cxx --disable-guile
>
> Edit config.h to have #define HAVE_ALLOCA 0 (configure sets HAVE_ALLOCA 1)
> Edit Makefile in doc to do nothing
> Edit Makefile in doc/example adding ../../gl/libgnu.la to LIBS

Thanks for summarizing this.  I'll see if I can add the gnulib alloca
module now, it should fix the alloca problem.

> pkix_asn1_tab.c:7: warning: 'pkix_asn1_tab' initialized and declared
> extern'
...
> gnutls_asn1_tab.c:7: warning: 'gnutls_asn1_tab' initialized and
> declared 'extern'
>
> I think the compiler is right. The two variable are used in
>
> pkix_asn1_tab.c
> gnutls_global.c
>
> in both files you use the extern qualifier, but in pkix_asn1_tab.c you
> also assign a "value". Wouldn't it be better to remove the extern
> qualifier in
> pkix_asn1_tab.c? Ok is a very minor issue but avoid two warnings.

Right.  Those files are generated, and I had fixed this problem in
libtasn1 but not re-generated the files in GnuTLS.  I've installed
freshly generated files now.

> So is this the end of the story? Unfortunately no!!

But very close. :)

> -               Not Before: Fri Jan 26 10:00:04 UTC 2007
> -               Not After: Sat Jan 27 10:00:06 UTC 2007
> +               Not Before: Fri Jan  10:00:04 UTC 2007
> +               Not After: Sat Jan  10:00:06 UTC 2007

Huh!  The day of month is missing.  This suggest a bug in strftime on
Windows, the code reads:

      if (gmtime_r (&tim, &t) == NULL)
	addf (str, "error: gmtime_r (%d)\n", t);
      else if (strftime (s, max, "%a %b %e %H:%M:%S UTC %Y", &t) == 0)
	addf (str, "error: strftime (%d)\n", t);
      else
	addf (str, _("\t\tNot Before: %s\n"), s);

In other words, the '%e' field doesn't work.  Possibly '%d' is more
portable, from the man page:

       %d     The day of the month as a decimal number (range 01 to 31).

       %e     Like %d, the day of the month as a decimal number, but a leading
              zero is replaced by a space. (SU)

Could you try replacing all occurrences of '%e' to '%d' in
lib/x509/output.c, re-build and re-run the self tests?

> Googling the internet I  got the opinion that this may be related to
> isprint(), I'm not sure anyway. Is the following recommandation (from
> HPUX suggestions) relevat to the failure?
>
> * lib/x509/output.c:
>  - The isprint() routine on Itanium platforms seemed to like printing
>    8-bit chars (possibly to do with the sign of the char?), so changed it
>    to simply print any char between ' ' and '~'. Without this change,
>    Itanium's "gmake check" fails one of the checks.

Nope, this is not related.  The problem here is that if the platform has
this bug, gnutls will print non-ascii characters when printing X.509
subject/issuer names.  We should fix that too, but it is more difficult
to do if nobody can help debug any proposed fix.

/Simon




From ludo at gnu.org  Thu Apr 17 11:27:15 2008
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Thu, 17 Apr 2008 11:27:15 +0200
Subject: [Help-gnutls] Re: duplicate symbols complaint on Mac OS X 10.5.2
References: <922d0b4d0802172330r33f794edu8b968adfee626357@mail.gmail.com>
	<D311DE37-F970-43EF-A1AB-394C6E407C16@gmail.com>
	<87myowwf5k.fsf@gnu.org>
	<8FD0D2D5-29C7-4E1B-9FB9-1CCB29E20438@gmail.com>
	<87ve3jn6na.fsf@gnu.org>
	<01646597-495C-4D75-8F65-665209687F06@gmail.com>
	<87d4pqj4zc.fsf@gnu.org>
	<FEB5CC46-BC82-44A6-BB6B-BE7EE1072B71@gmail.com>
	<87od9adag8.fsf@mocca.josefsson.org> <87k5jy4skb.fsf@gnu.org>
	<24445E26-11FC-479E-8501-8E4516194F52@gmail.com>
	<87ve3h4x2f.fsf@gnu.org> <87r6e5bubw.fsf@mocca.josefsson.org>
	<87prtpsh2v.fsf@gnu.org> <87y78dv53u.fsf@mocca.josefsson.org>
	<87od90clgu.fsf@gnu.org> <874pabcvq0.fsf@mocca.josefsson.org>
	<87od8jph7w.fsf@gnu.org> <87wsn6p66s.fsf@mocca.josefsson.org>
	<A6B2D1C3-901C-4208-B93E-24C20D13E118@gmail.com>
	<87ej9499pk.fsf@mocca.josefsson.org>
Message-ID: <87mynshlvw.fsf@gnu.org>

Hi,

Simon Josefsson <simon at josefsson.org> writes:

> Probably not, could you also try to re-compile gmp with this patch?
>
> http://permalink.gmane.org/gmane.comp.lib.gmp.bugs/1979
>
> Ludovic, is that the latest patch for gmp?

Yes, but this specific patch is for the regular GCC, not for Apple's
(see my other reply).

Thanks,
Ludovic.





From simon at josefsson.org  Thu Apr 17 13:03:35 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 17 Apr 2008 13:03:35 +0200
Subject: [Help-gnutls] Re: gnutls 2.3.4 doesn't copile using MinGW
In-Reply-To: <480642F5.8000907@alice.it> (Massimo Gaspari's message of "Wed,
	16 Apr 2008 20:18:29 +0200")
References: <47FFACC3.7010400@alice.it> <87fxtq9gjf.fsf@mocca.josefsson.org>
	<48027017.6090508@alice.it> <87mynvvi9k.fsf@mocca.josefsson.org>
	<480520B7.60302@alice.it> <8763ui9i8v.fsf@mocca.josefsson.org>
	<480642F5.8000907@alice.it>
Message-ID: <873apkvj3s.fsf@mocca.josefsson.org>

Massimo Gaspari <massimo.gaspari at alice.it> writes:

> 3) GnuTLS
>
> Edit the sources changing any vasprintf to gnutls_vasprintf
> (stdio.in.h, vasprintf.c, asprintf.c and gnutls_str.c)
> Edit the config.h.in to have #define HAVE_ALLOCA 0 and #define
> HAVE_ALLOCA_H 0
>
> ./configure --disable-shared --disable-rpath --disable-cxx --disable-guile
>
> Edit config.h to have #define HAVE_ALLOCA 0 (configure sets HAVE_ALLOCA 1)
> Edit Makefile in doc to do nothing
> Edit Makefile in doc/example adding ../../gl/libgnu.la to LIBS
...
> pkix_asn1_tab.c:7: warning: 'pkix_asn1_tab' initialized and declared
> extern'
...
> gnutls_asn1_tab.c:7: warning: 'gnutls_asn1_tab' initialized and
> declared 'extern'
...
> -               Not Before: Fri Jan 26 10:00:04 UTC 2007
> -               Not After: Sat Jan 27 10:00:06 UTC 2007
> +               Not Before: Fri Jan  10:00:04 UTC 2007
> +               Not After: Sat Jan  10:00:06 UTC 2007

Hi again.  I believe all of these, except for the vasprintf problem,
should be fixed in this (updated) daily snapshot:

http://daily.josefsson.org/gnutls/gnutls-20080417.tar.gz

/Simon




From simon at josefsson.org  Thu Apr 17 14:49:54 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 17 Apr 2008 14:49:54 +0200
Subject: [Help-gnutls] Re: gnutls_openpgp_crt_get_auth_subkey can return a
	key without the Authentication flag set
In-Reply-To: <87abk3c1n4.fsf@squeak.fifthhorseman.net> (Daniel Kahn Gillmor's
	message of "Tue, 08 Apr 2008 20:28:31 -0400")
References: <87abk3c1n4.fsf@squeak.fifthhorseman.net>
Message-ID: <874pa0d4st.fsf@mocca.josefsson.org>

Daniel Kahn Gillmor <dkg-debian.org at fifthhorseman.net> writes:

> Hey GnuTLS folks--
>
> I've opened a ticket about how the semantics of
> gnutls_openpgp_crt_get_auth_subkey() doesn't seem to match the
> documentation, and the ways i think they could be reconciled:
>
>  http://trac.gnutls.org/cgi-bin/trac.cgi/ticket/28
>
> Any discussion or explanations on the ticket would be welcome.

This has been fixed, right?

/Simon




From simon at josefsson.org  Thu Apr 17 15:09:46 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 17 Apr 2008 15:09:46 +0200
Subject: [Help-gnutls] Re: gnutls 2.3.4 doesn't copile using MinGW
In-Reply-To: <873apkvj3s.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Thu, 17 Apr 2008 13:03:35 +0200")
References: <47FFACC3.7010400@alice.it> <87fxtq9gjf.fsf@mocca.josefsson.org>
	<48027017.6090508@alice.it> <87mynvvi9k.fsf@mocca.josefsson.org>
	<480520B7.60302@alice.it> <8763ui9i8v.fsf@mocca.josefsson.org>
	<480642F5.8000907@alice.it> <873apkvj3s.fsf@mocca.josefsson.org>
Message-ID: <87tzi0bpb9.fsf@mocca.josefsson.org>

Hi again Massimo.  I released 2.3.6 with several of the fixes you have
brought up.  Please test it instead of the daily snapshot.

http://josefsson.org/gnutls/releases/gnutls-2.3.6.tar.bz2

/Simon




From dbreiser at gmail.com  Thu Apr 17 16:10:51 2008
From: dbreiser at gmail.com (David Reiser)
Date: Thu, 17 Apr 2008 10:10:51 -0400
Subject: [Help-gnutls] Re: duplicate symbols complaint on Mac OS X 10.5.2
In-Reply-To: <87mynshlvw.fsf@gnu.org>
References: <922d0b4d0802172330r33f794edu8b968adfee626357@mail.gmail.com>
	<D311DE37-F970-43EF-A1AB-394C6E407C16@gmail.com>
	<87myowwf5k.fsf@gnu.org>
	<8FD0D2D5-29C7-4E1B-9FB9-1CCB29E20438@gmail.com>
	<87ve3jn6na.fsf@gnu.org>
	<01646597-495C-4D75-8F65-665209687F06@gmail.com>
	<87d4pqj4zc.fsf@gnu.org>
	<FEB5CC46-BC82-44A6-BB6B-BE7EE1072B71@gmail.com>
	<87od9adag8.fsf@mocca.josefsson.org> <87k5jy4skb.fsf@gnu.org>
	<24445E26-11FC-479E-8501-8E4516194F52@gmail.com>
	<87ve3h4x2f.fsf@gnu.org> <87r6e5bubw.fsf@mocca.josefsson.org>
	<87prtpsh2v.fsf@gnu.org> <87y78dv53u.fsf@mocca.josefsson.org>
	<87od90clgu.fsf@gnu.org> <874pabcvq0.fsf@mocca.josefsson.org>
	<87od8jph7w.fsf@gnu.org> <87wsn6p66s.fsf@mocca.josefsson.org>
	<A6B2D1C3-901C-4208-B93E-24C20D13E118@gmail.com>
	<87ej9499pk.fsf@mocca.josefsson.org> <87mynshlvw.fsf@gnu.org>
Message-ID: <9E9ADDB2-BDAA-4819-8ECE-D3CFC9F355F2@gmail.com>


On Apr 17, 2008, at 5:27 AM, Ludovic Court?s wrote:
> Hi,
>
> Simon Josefsson <simon at josefsson.org> writes:
>
>> Probably not, could you also try to re-compile gmp with this patch?
>>
>> http://permalink.gmane.org/gmane.comp.lib.gmp.bugs/1979
>>
>> Ludovic, is that the latest patch for gmp?
>
> Yes, but this specific patch is for the regular GCC, not for Apple's
> (see my other reply).
>
I've been pointed to
http://www.opensource.apple.com/darwinsource/iPhoneSDKBeta3/gcc-5479/gcc/c-cppbuiltin.c
as evidence that Apple is about to fix the extern inline problem. To  
my untrained eye, it looks like the fix is to bring Apple's gcc to the  
point where it will understand the other patches.
   /* APPLE LOCAL begin mainline */
   if (flag_gnu89_inline)
     cpp_define (pfile, "__GNUC_GNU_INLINE__");
   else
     cpp_define (pfile, "__GNUC_STDC_INLINE__");
   /* APPLE LOCAL end mainline */
dave
--
David Reiser
dbreiser at gmail.com







From ludo at gnu.org  Thu Apr 17 17:49:21 2008
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Thu, 17 Apr 2008 17:49:21 +0200
Subject: [Help-gnutls] Re: duplicate symbols complaint on Mac OS X 10.5.2
References: <922d0b4d0802172330r33f794edu8b968adfee626357@mail.gmail.com>
	<8FD0D2D5-29C7-4E1B-9FB9-1CCB29E20438@gmail.com>
	<87ve3jn6na.fsf@gnu.org>
	<01646597-495C-4D75-8F65-665209687F06@gmail.com>
	<87d4pqj4zc.fsf@gnu.org>
	<FEB5CC46-BC82-44A6-BB6B-BE7EE1072B71@gmail.com>
	<87od9adag8.fsf@mocca.josefsson.org> <87k5jy4skb.fsf@gnu.org>
	<24445E26-11FC-479E-8501-8E4516194F52@gmail.com>
	<87ve3h4x2f.fsf@gnu.org> <87r6e5bubw.fsf@mocca.josefsson.org>
	<87prtpsh2v.fsf@gnu.org> <87y78dv53u.fsf@mocca.josefsson.org>
	<87od90clgu.fsf@gnu.org> <874pabcvq0.fsf@mocca.josefsson.org>
	<87od8jph7w.fsf@gnu.org> <87wsn6p66s.fsf@mocca.josefsson.org>
	<A6B2D1C3-901C-4208-B93E-24C20D13E118@gmail.com>
	<87ej9499pk.fsf@mocca.josefsson.org> <87mynshlvw.fsf@gnu.org>
	<9E9ADDB2-BDAA-4819-8ECE-D3CFC9F355F2@gmail.com>
Message-ID: <871w54wkfy.fsf@gnu.org>

Hi,

David Reiser <dbreiser at gmail.com> writes:

> I've been pointed to
> http://www.opensource.apple.com/darwinsource/iPhoneSDKBeta3/gcc-5479/gcc/c-cppbuiltin.c
> as evidence that Apple is about to fix the extern inline problem. To
> my untrained eye, it looks like the fix is to bring Apple's gcc to the
> point where it will understand the other patches.
>   /* APPLE LOCAL begin mainline */
>   if (flag_gnu89_inline)
>     cpp_define (pfile, "__GNUC_GNU_INLINE__");
>   else
>     cpp_define (pfile, "__GNUC_STDC_INLINE__");
>   /* APPLE LOCAL end mainline */

Sure, but until then, you have to have an `#ifdef' as in:

  http://git.sv.gnu.org/gitweb/?p=guile.git;a=blob;f=libguile/inline.h;

And it may be the case that people will be reluctant to add yet another
Apple-specific workaround when they fix their compiler...

Thanks,
Ludovic.





From dkg-debian.org at fifthhorseman.net  Thu Apr 17 20:38:04 2008
From: dkg-debian.org at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 17 Apr 2008 14:38:04 -0400
Subject: [Help-gnutls] Re: gnutls_openpgp_crt_get_auth_subkey can return a
	key without the Authentication flag set
In-Reply-To: <874pa0d4st.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Thu\, 17 Apr 2008 14\:49\:54 +0200")
References: <87abk3c1n4.fsf@squeak.fifthhorseman.net>
	<874pa0d4st.fsf@mocca.josefsson.org>
Message-ID: <87d4oo2upf.fsf@squeak.fifthhorseman.net>

On Thu 2008-04-17 08:49:54 -0400, Simon Josefsson wrote:

> Daniel Kahn Gillmor <dkg-debian.org at fifthhorseman.net> writes:
>
>>  http://trac.gnutls.org/cgi-bin/trac.cgi/ticket/28
>
> This has been fixed, right?

I just tested with GnuTLS 2.3.6, and i can't get it to work with the
flag set to 0 at all, unfortunately.

I've posted some followup info on the ticket.

Regards,

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: </pipermail/attachments/20080417/2c342348/attachment.pgp>

From nmav at gnutls.org  Thu Apr 17 22:11:38 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 17 Apr 2008 23:11:38 +0300
Subject: [Help-gnutls] Re: gnutls_openpgp_crt_get_auth_subkey can return
	a key without the Authentication flag set
In-Reply-To: <87d4oo2upf.fsf@squeak.fifthhorseman.net>
References: <87abk3c1n4.fsf@squeak.fifthhorseman.net>	<874pa0d4st.fsf@mocca.josefsson.org>
	<87d4oo2upf.fsf@squeak.fifthhorseman.net>
Message-ID: <4807AEFA.7090406@gnutls.org>

Daniel Kahn Gillmor wrote:
> On Thu 2008-04-17 08:49:54 -0400, Simon Josefsson wrote:
> 
>> Daniel Kahn Gillmor <dkg-debian.org at fifthhorseman.net> writes:
>>
>>>  http://trac.gnutls.org/cgi-bin/trac.cgi/ticket/28
>> This has been fixed, right?
> 
> I just tested with GnuTLS 2.3.6, and i can't get it to work with the
> flag set to 0 at all, unfortunately.
> 
> I've posted some followup info on the ticket.

I've also replied you. However note that for the new openpgp 
functionality only the included opencdk should be used.

regards,
Nikos




From massimo.gaspari at alice.it  Thu Apr 17 23:36:09 2008
From: massimo.gaspari at alice.it (Massimo Gaspari)
Date: Thu, 17 Apr 2008 23:36:09 +0200
Subject: [Help-gnutls] Re: gnutls 2.3.4 doesn't copile using MinGW
In-Reply-To: <877iew25x8.fsf@mocca.josefsson.org>
References: <47FFACC3.7010400@alice.it>
	<87fxtq9gjf.fsf@mocca.josefsson.org>	<48027017.6090508@alice.it>
	<87mynvvi9k.fsf@mocca.josefsson.org>	<480520B7.60302@alice.it>
	<8763ui9i8v.fsf@mocca.josefsson.org>	<480642F5.8000907@alice.it>
	<877iew25x8.fsf@mocca.josefsson.org>
Message-ID: <4807C2C9.3020700@alice.it>

Simon Josefsson wrote
> Huh!  The day of month is missing.  This suggest a bug in strftime on
> Windows, the code reads:
>
>       if (gmtime_r (&tim, &t) == NULL)
> 	addf (str, "error: gmtime_r (%d)\n", t);
>       else if (strftime (s, max, "%a %b %e %H:%M:%S UTC %Y", &t) == 0)
> 	addf (str, "error: strftime (%d)\n", t);
>       else
> 	addf (str, _("\t\tNot Before: %s\n"), s);
>
> In other words, the '%e' field doesn't work.  Possibly '%d' is more
> portable, from the man page:
>
>        %d     The day of the month as a decimal number (range 01 to 31).
>
>        %e     Like %d, the day of the month as a decimal number, but a leading
>               zero is replaced by a space. (SU)
>   
I read the MSDN documentation and as far as I understand  %e is not 
supported by the Microsoft C Runtime library, it's not listed in the 
available format specifiers.
So because MinGW uses the Microsoft's runtime-lib I got that issue, also 
Visual C should have it.

Anyway I got the latest version as you suggested, gnutls-2.3.6.tar.bz2. 
I see that you changed the %e specifier using %d.

After unpacking I changed the vasprintf to gnutls_vasprintf and nothing 
else. With just this single modification make terminated successfully. 
So the alloca isssue disappeared.

I observed a thing. When I did make for the very first time I didn't get 
the documentation building issue, but then if I do

make clean
make

I get the doc building issue. Does the "make clean" really delete all 
the modified and/or created files? May be not. Anyway I'm going to try 
to update the texinfo (f a new MinGW package is available).

So now 'make test'. The error is still present but is changed to

==================
All 1 tests passed
==================
make[3]: Leaving directory `/home/emasgas/gnutls-2.3.6/tests/userid'
make[2]: Leaving directory `/home/emasgas/gnutls-2.3.6/tests/userid'
Making check in pathlen
make[2]: Entering directory `/home/emasgas/gnutls-2.3.6/tests/pathlen'
make  pathlen
make[3]: Entering directory `/home/emasgas/gnutls-2.3.6/tests/pathlen'
make[3]: Nothing to be done for `pathlen'.
make[3]: Leaving directory `/home/emasgas/gnutls-2.3.6/tests/pathlen'
make  check-TESTS
make[3]: Entering directory `/home/emasgas/gnutls-2.3.6/tests/pathlen'
NOTE: you should run 'diskperf -y' to enable the disk statistics
NOTE: you should run 'diskperf -y' to enable the disk statistics
NOTE: you should run 'diskperf -y' to enable the disk statistics
NOTE: you should run 'diskperf -y' to enable the disk statistics
NOTE: you should run 'diskperf -y' to enable the disk statistics
NOTE: you should run 'diskperf -y' to enable the disk statistics
NOTE: you should run 'diskperf -y' to enable the disk statistics
NOTE: you should run 'diskperf -y' to enable the disk statistics
25c25
<                       ASCII: 
0;09..`.H...E....0*0(..+.........https://www.verisign.com/rpa
---
 >                       ASCII: 
0;09..`.H..?E....0*0(..+.........https://www.verisign.com/rpa
FAIL: pathlen
===================================
1 of 1 tests failed
Please report to bug-gnutls at gnu.org
===================================
make[3]: *** [check-TESTS] Error 1
make[3]: Leaving directory `/home/emasgas/gnutls-2.3.6/tests/pathlen'
make[2]: *** [check-am] Error 2
make[2]: Leaving directory `/home/emasgas/gnutls-2.3.6/tests/pathlen'
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory `/home/emasgas/gnutls-2.3.6/tests'
make: *** [check-recursive] Error 1

Is still pathlen. There is a ? difference!!! Tomorrow I'll try to 
understand what that test is doing.

Because the issue is in the runtime lib I think that without a patch 
neither MinGW nor Visual C can pass the test. But I think you couldn't 
care less of Visual C :-),  is it?
> Nope, this is not related.  The problem here is that if the platform has
> this bug, gnutls will print non-ascii characters when printing X.509
> subject/issuer names.  We should fix that too, but it is more difficult
> to do if nobody can help debug any proposed fix.
>   
I can help you  for the  MinGW environment. Or, at least, I would. I 
don't know if I'm really helping you or not. :-)

So the last issue for compilation is the vasprintf. Are you going to 
change something? May be the least is to add a comment to the 
installation instruction.

Massimo.




From simon at josefsson.org  Fri Apr 18 08:10:35 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 18 Apr 2008 08:10:35 +0200
Subject: [Help-gnutls] Re: gnutls 2.3.4 doesn't copile using MinGW
In-Reply-To: <4807C2C9.3020700@alice.it> (Massimo Gaspari's message of "Thu,
	17 Apr 2008 23:36:09 +0200")
References: <47FFACC3.7010400@alice.it> <87fxtq9gjf.fsf@mocca.josefsson.org>
	<48027017.6090508@alice.it> <87mynvvi9k.fsf@mocca.josefsson.org>
	<480520B7.60302@alice.it> <8763ui9i8v.fsf@mocca.josefsson.org>
	<480642F5.8000907@alice.it> <877iew25x8.fsf@mocca.josefsson.org>
	<4807C2C9.3020700@alice.it>
Message-ID: <87hcdzitgk.fsf@mocca.josefsson.org>

Massimo Gaspari <massimo.gaspari at alice.it> writes:

> Simon Josefsson wrote
>> Huh!  The day of month is missing.  This suggest a bug in strftime on
>> Windows, the code reads:
>>
>>       if (gmtime_r (&tim, &t) == NULL)
>> 	addf (str, "error: gmtime_r (%d)\n", t);
>>       else if (strftime (s, max, "%a %b %e %H:%M:%S UTC %Y", &t) == 0)
>> 	addf (str, "error: strftime (%d)\n", t);
>>       else
>> 	addf (str, _("\t\tNot Before: %s\n"), s);
>>
>> In other words, the '%e' field doesn't work.  Possibly '%d' is more
>> portable, from the man page:
>>
>>        %d     The day of the month as a decimal number (range 01 to 31).
>>
>>        %e     Like %d, the day of the month as a decimal number, but a leading
>>               zero is replaced by a space. (SU)
>>   
> I read the MSDN documentation and as far as I understand  %e is not
> supported by the Microsoft C Runtime library, it's not listed in the
> available format specifiers.
> So because MinGW uses the Microsoft's runtime-lib I got that issue,
> also Visual C should have it.

Right.  I've documented this in gnulib in:

http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=doc/posix-functions/strftime.texi;hb=HEAD

> Anyway I got the latest version as you suggested,
> gnutls-2.3.6.tar.bz2. I see that you changed the %e specifier using
> %d.

Yes, it should be more portable, and using %e is not that important in
this case.

> After unpacking I changed the vasprintf to gnutls_vasprintf and
> nothing else. With just this single modification make terminated
> successfully.

Great!

> So the alloca isssue disappeared.

Yes, I removed all uses of alloca in the code, see the NEWS file.

> I observed a thing. When I did make for the very first time I didn't
> get the documentation building issue, but then if I do
>
> make clean
> make
>
> I get the doc building issue. Does the "make clean" really delete all
> the modified and/or created files? May be not. Anyway I'm going to try
> to update the texinfo (f a new MinGW package is available).

Hm, interesting, I'll see if I can reproduce this.  It may be that this
is intentional, but I'm not sure.

> <                       ASCII:
> 0;09..`.H...E....0*0(..+.........https://www.verisign.com/rpa
> ---
>>                       ASCII: 
> 0;09..`.H..?E....0*0(..+.........https://www.verisign.com/rpa
> FAIL: pathlen
...
>
> Is still pathlen. There is a ? difference!!! Tomorrow I'll try to
> understand what that test is doing.

This seems like a isprint() problem.  Windows probably think ? is a
printable character, and it is difficult to argue with that.  The code
needs to use a ASCII-only isprint function here, so that the output is
consistent regardless of locale it is run in.

> Because the issue is in the runtime lib I think that without a patch
> neither MinGW nor Visual C can pass the test. But I think you couldn't
> care less of Visual C :-),  is it?

Nah, we should support it when feasible... some of the issues you have
brought up affect other platforms too, so they are bugs in gnutls.

>> Nope, this is not related.  The problem here is that if the platform has
>> this bug, gnutls will print non-ascii characters when printing X.509
>> subject/issuer names.  We should fix that too, but it is more difficult
>> to do if nobody can help debug any proposed fix.
>>   
> I can help you  for the  MinGW environment. Or, at least, I would. I
> don't know if I'm really helping you or not. :-)

You are helping a lot!  We have fixed several things based on your
report.

> So the last issue for compilation is the vasprintf. Are you going to
> change something? May be the least is to add a comment to the
> installation instruction.

Yes, but I need to look into how we can solve this in a clean/portable
way.  Meanwhile we could document this... although this discussion in
the mailing list archive may be sufficient.

/Simon




From simon at josefsson.org  Fri Apr 18 11:34:51 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 18 Apr 2008 11:34:51 +0200
Subject: [Help-gnutls] Re: gnutls 2.3.4 doesn't copile using MinGW
In-Reply-To: <4807C2C9.3020700@alice.it> (Massimo Gaspari's message of "Thu,
	17 Apr 2008 23:36:09 +0200")
References: <47FFACC3.7010400@alice.it> <87fxtq9gjf.fsf@mocca.josefsson.org>
	<48027017.6090508@alice.it> <87mynvvi9k.fsf@mocca.josefsson.org>
	<480520B7.60302@alice.it> <8763ui9i8v.fsf@mocca.josefsson.org>
	<480642F5.8000907@alice.it> <877iew25x8.fsf@mocca.josefsson.org>
	<4807C2C9.3020700@alice.it>
Message-ID: <87lk3b8q10.fsf@mocca.josefsson.org>

Massimo Gaspari <massimo.gaspari at alice.it> writes:

> After unpacking I changed the vasprintf to gnutls_vasprintf and
> nothing else.

Hi.  You may find it easier to solve this in a different way: remove the
definition of 'vasprintf' from libgcrypt (src/missing-string.c), see
discussion in:

http://thread.gmane.org/gmane.comp.encryption.gpg.libgcrypt.devel/1963

I have installed a potential fix for this in gnutls in case people can't
patch libgcrypt easily.  Please try updated snapshot:

http://daily.josefsson.org/gnutls/gnutls-20080418.tar.gz

That one should also fix the isprint problem.

/Simon




From rgerhards at gmail.com  Fri Apr 18 17:19:29 2008
From: rgerhards at gmail.com (Rainer Gerhards)
Date: Fri, 18 Apr 2008 17:19:29 +0200
Subject: [Help-gnutls] gnutls_transport_ptr and int fd's
Message-ID: <dc67eef70804180819n3b01b5b3of322f9af1a634f9c@mail.gmail.com>

Hi all,

[working on Fedora 8 with GCC]

I have a minor nit. The root cause is probably not in GnuTLS but in me
overlooking something...

I supply the int fd I got from socket() to gnutls_transport_set_ptr().
However, when I do so, I receive the following GCC warning:

cast to pointer from integer of different size

This is annoying during the build process, but of course tolerable. I
would prefer to see this warning go away, but I do not like to reduce
GCCs warning level. Any advise would be appreciated.

Thanks,
Rainer

PS: I have finally gotten my code ready for TLS implementation. I
managed to send the first TLS records within an hour or so. Good
examples, excellent API [of course, my implementation is currently far
from being secure ;)].




From massimo.gaspari at alice.it  Fri Apr 18 23:01:59 2008
From: massimo.gaspari at alice.it (Massimo Gaspari)
Date: Fri, 18 Apr 2008 23:01:59 +0200
Subject: [Help-gnutls] Re: gnutls 2.3.4 doesn't copile using MinGW
In-Reply-To: <87hcdzitgk.fsf@mocca.josefsson.org>
References: <47FFACC3.7010400@alice.it>
	<87fxtq9gjf.fsf@mocca.josefsson.org>	<48027017.6090508@alice.it>
	<87mynvvi9k.fsf@mocca.josefsson.org>	<480520B7.60302@alice.it>
	<8763ui9i8v.fsf@mocca.josefsson.org>	<480642F5.8000907@alice.it>
	<877iew25x8.fsf@mocca.josefsson.org>	<4807C2C9.3020700@alice.it>
	<87hcdzitgk.fsf@mocca.josefsson.org>
Message-ID: <48090C47.2060808@alice.it>

Simon Josefsson wrote:


I got the gnuttls-20080417.tar.gz archive and I have some good news and 
some bad news.

The good news are that now gnutls can be compiled "out-of-the-box" and 
that "make check" terminates successfully (no errors!!!)
You did a very good patching.

There is still the "documentation-building-issue" when you compile twice 
or more times. Ok, I'll compile only once! :-)


The bad news are

>> So the alloca isssue disappeared.
>>     
>
> Yes, I removed all uses of alloca in the code, see the NEWS file.
>
>   

Unfortunatley it's not true. In a previous post I said that the issue 
was fixed. Because I checked the warnings I previously recorded. They 
disappeared (for example x509.c has no warnings) for some files but not 
for all sources.

There are three  warnings (in both 2.3.6 and gnttls-20080417.tar.gz) I 
missed to report. I apologize for that! They are



make[3]: Entering directory `/home/emasgas/gnutls-2.3.7/lib/minitasn1'
/bin/sh ../../libtool --tag=CC   --mode=compile gcc -std=gnu99 
-DHAVE_CONFIG_H -I. -I../.. -I../../lib -I../../lgl -I../../lgl   -pipe 
-I/usr/local/include -O2 -Wno-pointer-sign -MT decoding.lo -MD -MP -MF 
.deps/decoding.Tpo -c -o decoding.lo decoding.c
 gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../../lib -I../../lgl 
-I../../lgl -pipe -I/usr/local/include -O2 -Wno-pointer-sign -MT 
decoding.lo -MD -MP -MF .deps/decoding.Tpo -c decoding.c -o decoding.o
decoding.c: In function '_asn1_get_octet_string':
decoding.c:621: warning: implicit declaration of function 'alloca'
decoding.c:621: warning: incompatible implicit declaration of built-in 
function 'alloca'
decoding.c: In function 'asn1_der_decoding':
decoding.c:1196: warning: incompatible implicit declaration of built-in 
function 'alloca'
decoding.c:1225: warning: incompatible implicit declaration of built-in 
function 'alloca'
decoding.c: In function 'asn1_der_decoding_element':
decoding.c:1882: warning: incompatible implicit declaration of built-in 
function 'alloca'
decoding.c:1919: warning: incompatible implicit declaration of built-in 
function 'alloca'
mv -f .deps/decoding.Tpo .deps/decoding.Plo



/bin/sh ../../libtool --tag=CC   --mode=compile gcc -std=gnu99 
-DHAVE_CONFIG_H -I. -I../.. -I../../lib -I../../lgl -I../../lgl   -pipe 
-I/usr/local/include -O2 -Wno-pointer-sign -MT element.lo -MD -MP -MF 
.deps/element.Tpo -c -o element.lo element.c
 gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../../lib -I../../lgl 
-I../../lgl -pipe -I/usr/local/include -O2 -Wno-pointer-sign -MT 
element.lo -MD -MP -MF .deps/element.Tpo -c element.c -o element.o
element.c: In function 'asn1_write_value':
element.c:353: warning: implicit declaration of function 'alloca'
element.c:353: warning: incompatible implicit declaration of built-in 
function 'alloca'
element.c:373: warning: incompatible implicit declaration of built-in 
function 'alloca'
element.c:392: warning: incompatible implicit declaration of built-in 
function 'alloca'
element.c:421: warning: incompatible implicit declaration of built-in 
function 'alloca'
mv -f .deps/element.Tpo .deps/element.Plo
/bin/sh ../../libtool --tag=CC   --mode=compile gcc -std=gnu99 
-DHAVE_CONFIG_H -I. -I../.. -I../../lib -I../../lgl -I../../lgl   -pipe 
-I/usr/local/include -O2 -Wno-pointer-sign -MT coding.lo -MD -MP -MF 
.deps/coding.Tpo -c -o coding.lo coding.c
 gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../../lib -I../../lgl 
-I../../lgl -pipe -I/usr/local/include -O2 -Wno-pointer-sign -MT 
coding.lo -MD -MP -MF .deps/coding.Tpo -c coding.c -o coding.o
coding.c: In function '_asn1_objectid_der':
coding.c:263: warning: implicit declaration of function 'alloca'
coding.c:263: warning: incompatible implicit declaration of built-in 
function 'alloca'
coding.c: In function '_asn1_ordering_set':
coding.c:639: warning: incompatible implicit declaration of built-in 
function 'alloca'
coding.c:680: warning: incompatible implicit declaration of built-in 
function 'alloca'
coding.c: In function '_asn1_ordering_set_of':
coding.c:753: warning: incompatible implicit declaration of built-in 
function 'alloca'
coding.c:818: warning: incompatible implicit declaration of built-in 
function 'alloca'
mv -f .deps/coding.Tpo .deps/coding.Plo

I 'm listing all the warnings I get (hopefully is a full list). I think 
the "alloca" ones deserve to be fixed. The other warnings are related to 
examples or tests. May be they don't deserve fixing.


gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I..  -I../includes -I../includes 
-I../lgl -I../lgl -I../gl -I../gl -I./cfg  -pipe -I/usr/local/include 
-O2 -Wno-pointer-sign -MT serv.o -MD -MP -MF .deps/serv.Tpo -c -o serv.o 
serv.c
serv.c: In function 'main':
serv.c:1044: warning: implicit declaration of function '_win_select'

gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I..  -I../includes -I../includes 
-I../lgl -I../lgl -I../gl -I../gl -I./cfg  -pipe -I/usr/local/include 
-O2 -Wno-pointer-sign -MT cli.o -MD -MP -MF .deps/cli.Tpo -c -o cli.o cli.c
cli.c: In function 'main':
cli.c:709: warning: implicit declaration of function '_win_select'
mv -f .deps/cli.Tpo .deps/cli.Po

gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I..  -I../includes -I../includes 
-I../lgl -I../lgl -I../gl -I../gl -I./cfg  -pipe -I/usr/local/include 
-O2 -Wno-pointer-sign -MT psk-gaa.o -MD -MP -MF .deps/psk-gaa.Tpo -c -o 
psk-gaa.o psk-gaa.c
psk.gaa: In function 'gaa':
psk.gaa:28: warning: assignment makes integer from pointer without a cast
mv -f .deps/psk-gaa.Tpo .deps/psk-gaa.Po


gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I..  -I../includes -I../includes 
-I../lgl -I../lgl -I../gl -I../gl -I./cfg  -pipe -I/usr/local/include 
-O2 -Wno-pointer-sign -MT psk-gaa.o -MD -MP -MF .deps/psk-gaa.Tpo -c -o 
psk-gaa.o psk-gaa.c
psk.gaa: In function 'gaa':
psk.gaa:28: warning: assignment makes integer from pointer without a cast
mv -f .deps/psk-gaa.Tpo .deps/psk-gaa.Po


mv -f .deps/tls_test.Tpo .deps/tls_test.Po
gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I..  -I../includes -I../includes 
-I../lgl -I../lgl -I../gl -I../gl -I./cfg  -pipe -I/usr/local/include 
-O2 -Wno-pointer-sign -MT tests.o -MD -MP -MF .deps/tests.Tpo -c -o 
tests.o tests.c
tests.c: In function 'test_bye':
tests.c:518: warning: passing argument 1 of 'setsockopt' makes integer 
from pointer without a cast
mv -f .deps/tests.Tpo .deps/tests.Po

mv -f .deps/ex-verify.Tpo .deps/ex-verify.Plo
/bin/sh ../../libtool --tag=CC   --mode=compile gcc -std=gnu99 
-DHAVE_CONFIG_H -I. -I../..  -I../../includes -I../../includes 
-I../../lgl -I../../lgl -I../../gl -I../../gl  -pipe 
-I/usr/local/include -O2 -Wno-pointer-sign -MT tcp.lo -MD -MP -MF 
.deps/tcp.Tpo -c -o tcp.lo tcp.c
 gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../../includes 
-I../../includes -I../../lgl -I../../lgl -I../../gl -I../../gl -pipe 
-I/usr/local/include -O2 -Wno-pointer-sign -MT tcp.lo -MD -MP -MF 
.deps/tcp.Tpo -c tcp.c -o tcp.o
tcp.c: In function 'tcp_connect':
tcp.c:41: warning: implicit declaration of function 'inet_pton'
mv -f .deps/tcp.Tpo .deps/tcp.Plo
/bin/sh ../../libtool --tag=CC   --mode=link gcc -std=gnu99 -pipe 
-I/usr/local/include -O2 -Wno-pointer-sign -no-install  -o 
libexamples.la  ex-alert.lo ex-pkcs12.lo ex-rfc2818.lo 
ex-session-info.lo ex-x509-info.lo ex-verify.lo tcp.lo 
libtool: link: warning: `-no-install' is ignored for i686-pc-mingw32
libtool: link: warning: assuming `-no-fast-install' instead
mkdir .libs

gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../..  -I../../includes 
-I../../includes -I../../lgl -I../../lgl -I../../gl -I../../gl  -pipe 
-I/usr/local/include -O2 -Wno-pointer-sign -MT ex-serv1.o -MD -MP -MF 
.deps/ex-serv1.Tpo -c -o ex-serv1.o ex-serv1.c
ex-serv1.c: In function 'main':
ex-serv1.c:133: warning: passing argument 4 of 'setsockopt' from 
incompatible pointer type
ex-serv1.c:150: warning: implicit declaration of function 'inet_ntop'
mv -f .deps/ex-serv1.Tpo .deps/ex-serv1.Po
/bin/sh ../../libtool --tag=CC   --mode=link gcc -std=gnu99 -pipe 
-I/usr/local/include -O2 -Wno-pointer-sign -no-install  -o ex-serv1.exe 
ex-serv1.o libexamples.la ../../lib/libgnutls.la 
../../libextra/libgnutls-extra.la ../../gl/libgnu.la
libtool: link: warning: `-no-install' is ignored for i686-pc-mingw32
libtool: link: warning: assuming `-no-fast-install' instead


gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../..  -I../../includes 
-I../../includes -I../../lgl -I../../lgl -I../../gl -I../../gl  -pipe 
-I/usr/local/include -O2 -Wno-pointer-sign -MT ex-serv-export.o -MD -MP 
-MF .deps/ex-serv-export.Tpo -c -o ex-serv-export.o ex-serv-export.c
ex-serv-export.c: In function 'main':
ex-serv-export.c:182: warning: passing argument 4 of 'setsockopt' from 
incompatible pointer type
ex-serv-export.c:199: warning: implicit declaration of function 'inet_ntop'
mv -f .deps/ex-serv-export.Tpo .deps/ex-serv-export.Po


gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../..  -I../../includes 
-I../../includes -I../../lgl -I../../lgl -I../../gl -I../../gl  -pipe 
-I/usr/local/include -O2 -Wno-pointer-sign -MT ex-serv-anon.o -MD -MP 
-MF .deps/ex-serv-anon.Tpo -c -o ex-serv-anon.o ex-serv-anon.c
ex-serv-anon.c: In function 'main':
ex-serv-anon.c:102: warning: passing argument 4 of 'setsockopt' from 
incompatible pointer type
ex-serv-anon.c:119: warning: implicit declaration of function 'inet_ntop'
mv -f .deps/ex-serv-anon.Tpo .deps/ex-serv-anon.Po
/bin/sh ../../libtool --tag=CC   --mode=link gcc -std=gnu99 -pipe 
-I/usr/local/include -O2 -Wno-pointer-sign -no-install  -o 
ex-serv-anon.exe ex-serv-anon.o libexamples.la ../../lib/libgnutls.la 
../../libextra/libgnutls-extra.la ../../gl/libgnu.la


gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../..  -I../../includes 
-I../../includes -I../../lgl -I../../lgl -I../../gl -I../../gl  -pipe 
-I/usr/local/include -O2 -Wno-pointer-sign -MT ex-serv-pgp.o -MD -MP -MF 
.deps/ex-serv-pgp.Tpo -c -o ex-serv-pgp.o ex-serv-pgp.c
ex-serv-pgp.c: In function 'main':
ex-serv-pgp.c:114: warning: passing argument 4 of 'setsockopt' from 
incompatible pointer type
ex-serv-pgp.c:131: warning: implicit declaration of function 'inet_ntop'
mv -f .deps/ex-serv-pgp.Tpo .deps/ex-serv-pgp.Po


gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../..  -I../../includes 
-I../../includes -I../../lgl -I../../lgl -I../../gl -I../../gl  -pipe 
-I/usr/local/include -O2 -Wno-pointer-sign -MT ex-serv-srp.o -MD -MP -MF 
.deps/ex-serv-srp.Tpo -c -o ex-serv-srp.o ex-serv-srp.c
ex-serv-srp.c: In function 'main':
ex-serv-srp.c:107: warning: passing argument 4 of 'setsockopt' from 
incompatible pointer type
ex-serv-srp.c:124: warning: implicit declaration of function 'inet_ntop'
mv -f .deps/ex-serv-srp.Tpo .deps/ex-serv-srp.Po
/bin/sh ../../libtool --tag=CC   --mode=link gcc -std=gnu99 -pipe 
-I/usr/local/include -O2 -Wno-pointer-sign -no-install  -o 
ex-serv-srp.exe ex-serv-srp.o libexamples.la ../../lib/libgnutls.la 
../../libextra/libgnutls-extra.la ../../gl/libgnu.la
libtool: link: warning: `-no-install' is ignored for i686-pc-mingw32
libtool: link: warning: assuming `-no-fast-install' instead


/bin/sh ../libtool --tag=CC   --mode=compile gcc -std=gnu99 
-DHAVE_CONFIG_H -I. -I..  -I../lgl -I../lgl -I../gl -I../gl 
-I../includes -I../includes -I../doc/examples  -pipe 
-I/usr/local/include -O2 -Wno-pointer-sign -MT utils.lo -MD -MP -MF 
.deps/utils.Tpo -c -o utils.lo utils.c
 gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I../lgl -I../lgl -I../gl 
-I../gl -I../includes -I../includes -I../doc/examples -pipe 
-I/usr/local/include -O2 -Wno-pointer-sign -MT utils.lo -MD -MP -MF 
.deps/utils.Tpo -c utils.c -o utils.o
mv -f .deps/utils.Tpo .deps/utils.Plo
/bin/sh ../libtool --tag=CC   --mode=link gcc -std=gnu99 -pipe 
-I/usr/local/include -O2 -Wno-pointer-sign -no-install  -o libutils.la  
utils.lo 
libtool: link: warning: `-no-install' is ignored for i686-pc-mingw32
libtool: link: warning: assuming `-no-fast-install' instead

Hope this helps

Massimo

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20080418/642b9437/attachment.htm>

From massimo.gaspari at alice.it  Fri Apr 18 23:12:28 2008
From: massimo.gaspari at alice.it (Massimo Gaspari)
Date: Fri, 18 Apr 2008 23:12:28 +0200
Subject: [Help-gnutls] Re: gnutls 2.3.4 doesn't copile using MinGW
In-Reply-To: <48090C47.2060808@alice.it>
References: <47FFACC3.7010400@alice.it>	<87fxtq9gjf.fsf@mocca.josefsson.org>	<48027017.6090508@alice.it>	<87mynvvi9k.fsf@mocca.josefsson.org>	<480520B7.60302@alice.it>	<8763ui9i8v.fsf@mocca.josefsson.org>	<480642F5.8000907@alice.it>	<877iew25x8.fsf@mocca.josefsson.org>	<4807C2C9.3020700@alice.it>	<87hcdzitgk.fsf@mocca.josefsson.org>
	<48090C47.2060808@alice.it>
Message-ID: <48090EBC.8010202@alice.it>

Massimo Gaspari wrote:
> Simon Josefsson wrote:
>
>
> I got the gnuttls-20080417.tar.gz archive and I have some good news 
> and some bad news.

It's gnuttls-20080418.tar.gz , the latest one

I'm tired ....

Massimo





From simon at josefsson.org  Mon Apr 21 12:56:35 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 21 Apr 2008 12:56:35 +0200
Subject: [Help-gnutls] Libtasn1 1.4
Message-ID: <87k5irqxwc.fsf@mocca.josefsson.org>

Libtasn1 is a standalone library written in C for manipulating ASN.1
objects including DER/BER encoding and DER/BER decoding.  Libtasn1 is
used by GnuTLS to manipulate X.509 objects and by Shishi to handle
Kerberos V5 packets.

Version 1.4 (released 2008-04-21)
- Update gnulib files.
- Replace uses of alloca with malloc.

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

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

Homepage:
  http://josefsson.org/libtasn1/

Manual in many formats:
  http://josefsson.org/gnutls/manual/libtasn1/

Here are the compressed sources (1.5MB):
  ftp://ftp.gnutls.org/pub/gnutls/libtasn1/libtasn1-1.4.tar.gz
  http://josefsson.org/gnutls/releases/libtasn1/libtasn1-1.4.tar.gz

Here are GPG detached signatures using key 0xB565716F:
  ftp://ftp.gnutls.org/pub/gnutls/libtasn1/libtasn1-1.4.tar.gz.sig
  http://josefsson.org/gnutls/releases/libtasn1/libtasn1-1.4.tar.gz.sig

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

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

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

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

684c9dc343b0155a074c2127ac8050f983528bc8  libtasn1-1.4.tar.gz

717d633b49d68b8ce884bb51129c93ae54bd6b020adb96c30e4bb750  libtasn1-1.4.tar.gz

Happy hacking,
Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 419 bytes
Desc: not available
URL: </pipermail/attachments/20080421/67c33dd6/attachment.pgp>

From simon at josefsson.org  Mon Apr 21 13:19:51 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 21 Apr 2008 13:19:51 +0200
Subject: [Help-gnutls] Re: gnutls 2.3.4 doesn't copile using MinGW
In-Reply-To: <48090C47.2060808@alice.it> (Massimo Gaspari's message of "Fri,
	18 Apr 2008 23:01:59 +0200")
References: <47FFACC3.7010400@alice.it> <87fxtq9gjf.fsf@mocca.josefsson.org>
	<48027017.6090508@alice.it> <87mynvvi9k.fsf@mocca.josefsson.org>
	<480520B7.60302@alice.it> <8763ui9i8v.fsf@mocca.josefsson.org>
	<480642F5.8000907@alice.it> <877iew25x8.fsf@mocca.josefsson.org>
	<4807C2C9.3020700@alice.it> <87hcdzitgk.fsf@mocca.josefsson.org>
	<48090C47.2060808@alice.it>
Message-ID: <87ej8zqwtk.fsf@mocca.josefsson.org>

Massimo Gaspari <massimo.gaspari at alice.it> writes:

> I got the gnuttls-20080417.tar.gz archive and I have some good news
> and some bad news.
>
> The good news are that now gnutls can be compiled "out-of-the-box" and
> that "make check" terminates successfully (no errors!!!)
> You did a very good patching.

That's good.  Thanks.

> There is still the "documentation-building-issue" when you compile
> twice or more times. Ok, I'll compile only once! :-)

Hm.  I'll see if I can reproduce this.

> The bad news are

Some of these should be fixed in updated:

http://daily.josefsson.org/gnutls/gnutls-20080421.tar.gz

Please let me know what still fails.  It seems we are now almost
finished, so I should make another release and you can do final testing
of it.

>>> So the alloca isssue disappeared.
>>>     
>>
>> Yes, I removed all uses of alloca in the code, see the NEWS file.
>
> Unfortunatley it's not true. In a previous post I said that the issue
> was fixed. Because I checked the warnings I previously recorded. They
> disappeared (for example x509.c has no warnings) for some files but
> not for all sources.
>
> There are three  warnings (in both 2.3.6 and gnttls-20080417.tar.gz) I
> missed to report. I apologize for that! They are
...
> make[3]: Entering directory `/home/emasgas/gnutls-2.3.7/lib/minitasn1'
...

Those were in libtasn1, so I made a new release of it with a similar
fix, and then updated the internal copy of libtasn1 inside gnutls.

> I 'm listing all the warnings I get (hopefully is a full list). I
> think the "alloca" ones deserve to be fixed. The other warnings are
> related to examples or tests. May be they don't deserve fixing.

>
> gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I..  -I../includes -I../includes
> -I../lgl -I../lgl -I../gl -I../gl -I./cfg  -pipe -I/usr/local/include
> -O2 -Wno-pointer-sign -MT serv.o -MD -MP -MF .deps/serv.Tpo -c -o
> serv.o serv.c
> serv.c: In function 'main':
> serv.c:1044: warning: implicit declaration of function '_win_select'
>
> gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I..  -I../includes -I../includes
> -I../lgl -I../lgl -I../gl -I../gl -I./cfg  -pipe -I/usr/local/include
> -O2 -Wno-pointer-sign -MT cli.o -MD -MP -MF .deps/cli.Tpo -c -o cli.o
> cli.c
> cli.c: In function 'main':
> cli.c:709: warning: implicit declaration of function '_win_select'
> mv -f .deps/cli.Tpo .deps/cli.Po

Missing prototype, fixed.

> gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I..  -I../includes -I../includes
> -I../lgl -I../lgl -I../gl -I../gl -I./cfg  -pipe -I/usr/local/include
> -O2 -Wno-pointer-sign -MT psk-gaa.o -MD -MP -MF .deps/psk-gaa.Tpo -c
> -o 
> psk-gaa.o psk-gaa.c
> psk.gaa: In function 'gaa':
> psk.gaa:28: warning: assignment makes integer from pointer without a cast
> mv -f .deps/psk-gaa.Tpo .deps/psk-gaa.Po
>
>
> gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I..  -I../includes -I../includes
> -I../lgl -I../lgl -I../gl -I../gl -I./cfg  -pipe -I/usr/local/include
> -O2 -Wno-pointer-sign -MT psk-gaa.o -MD -MP -MF .deps/psk-gaa.Tpo -c
> -o 
> psk-gaa.o psk-gaa.c
> psk.gaa: In function 'gaa':
> psk.gaa:28: warning: assignment makes integer from pointer without a cast
> mv -f .deps/psk-gaa.Tpo .deps/psk-gaa.Po

Silly error, fixed too.

>
> mv -f .deps/tls_test.Tpo .deps/tls_test.Po
> gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I..  -I../includes -I../includes
> -I../lgl -I../lgl -I../gl -I../gl -I./cfg  -pipe -I/usr/local/include
> -O2 -Wno-pointer-sign -MT tests.o -MD -MP -MF .deps/tests.Tpo -c -o 
> tests.o tests.c
> tests.c: In function 'test_bye':
> tests.c:518: warning: passing argument 1 of 'setsockopt' makes integer
> from pointer without a cast
> mv -f .deps/tests.Tpo .deps/tests.Po

Should be fixed, please confirm.

> tcp.c:41: warning: implicit declaration of function 'inet_pton'
> ex-serv1.c:150: warning: implicit declaration of function 'inet_ntop'

Problem in gnulib, I'll see if I can get these fixed.  I don't think
this is important though.

> ex-serv1.c:133: warning: passing argument 4 of 'setsockopt' from
> incompatible pointer type

Probably a buggy system header file, the argument should be 'void*'
which should be castable from any type.

> /bin/sh ../libtool --tag=CC   --mode=compile gcc -std=gnu99
> -DHAVE_CONFIG_H -I. -I..  -I../lgl -I../lgl -I../gl -I../gl
> -I../includes -I../includes -I../doc/examples  -pipe
> -I/usr/local/include -O2 -Wno-pointer-sign -MT utils.lo -MD -MP -MF
> .deps/utils.Tpo -c -o utils.lo utils.c
> gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I../lgl -I../lgl -I../gl
> -I../gl -I../includes -I../includes -I../doc/examples -pipe
> -I/usr/local/include -O2 -Wno-pointer-sign -MT utils.lo -MD -MP -MF
> .deps/utils.Tpo -c utils.c -o utils.o
> mv -f .deps/utils.Tpo .deps/utils.Plo
> /bin/sh ../libtool --tag=CC   --mode=link gcc -std=gnu99 -pipe
> -I/usr/local/include -O2 -Wno-pointer-sign -no-install  -o libutils.la
> utils.lo libtool: link: warning: `-no-install' is ignored for
> i686-pc-mingw32
> libtool: link: warning: assuming `-no-fast-install' instead

I have no idea what this warning is about, it can probably be ignored.

/Simon




From simon at josefsson.org  Mon Apr 21 13:33:13 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 21 Apr 2008 13:33:13 +0200
Subject: [Help-gnutls] Re: gnutls 2.3.4 doesn't copile using MinGW
In-Reply-To: <87ej8zqwtk.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Mon, 21 Apr 2008 13:19:51 +0200")
References: <47FFACC3.7010400@alice.it> <87fxtq9gjf.fsf@mocca.josefsson.org>
	<48027017.6090508@alice.it> <87mynvvi9k.fsf@mocca.josefsson.org>
	<480520B7.60302@alice.it> <8763ui9i8v.fsf@mocca.josefsson.org>
	<480642F5.8000907@alice.it> <877iew25x8.fsf@mocca.josefsson.org>
	<4807C2C9.3020700@alice.it> <87hcdzitgk.fsf@mocca.josefsson.org>
	<48090C47.2060808@alice.it> <87ej8zqwtk.fsf@mocca.josefsson.org>
Message-ID: <8763ubqw7a.fsf@mocca.josefsson.org>

Simon Josefsson <simon at josefsson.org> writes:

>> There is still the "documentation-building-issue" when you compile
>> twice or more times. Ok, I'll compile only once! :-)
>
> Hm.  I'll see if I can reproduce this.

I was, and it should be fixed in the updated daily snapshot (timestamp
13:32).

/Simon




From simon at josefsson.org  Mon Apr 21 13:56:01 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 21 Apr 2008 13:56:01 +0200
Subject: [Help-gnutls] Re: gnutls 2.3.4 doesn't copile using MinGW
In-Reply-To: <8763ubqw7a.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Mon, 21 Apr 2008 13:33:13 +0200")
References: <47FFACC3.7010400@alice.it> <87fxtq9gjf.fsf@mocca.josefsson.org>
	<48027017.6090508@alice.it> <87mynvvi9k.fsf@mocca.josefsson.org>
	<480520B7.60302@alice.it> <8763ui9i8v.fsf@mocca.josefsson.org>
	<480642F5.8000907@alice.it> <877iew25x8.fsf@mocca.josefsson.org>
	<4807C2C9.3020700@alice.it> <87hcdzitgk.fsf@mocca.josefsson.org>
	<48090C47.2060808@alice.it> <87ej8zqwtk.fsf@mocca.josefsson.org>
	<8763ubqw7a.fsf@mocca.josefsson.org>
Message-ID: <87tzhvpgku.fsf@mocca.josefsson.org>

Simon Josefsson <simon at josefsson.org> writes:

> Simon Josefsson <simon at josefsson.org> writes:
>
>>> There is still the "documentation-building-issue" when you compile
>>> twice or more times. Ok, I'll compile only once! :-)
>>
>> Hm.  I'll see if I can reproduce this.
>
> I was, and it should be fixed in the updated daily snapshot (timestamp
> 13:32).

But please try latest 2.3.7 instead, it should contain all fixes.
  http://alpha.gnu.org/gnu/gnutls/gnutls-2.3.7.tar.bz2
  ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.3.7.tar.bz2

/Simon




From dh at triple-media.com  Mon Apr 21 21:04:09 2008
From: dh at triple-media.com (Dennis Heuer)
Date: Mon, 21 Apr 2008 21:04:09 +0200
Subject: [Help-gnutls] gnutls-2.3.7 not installing OpenSSL-compatibility
	headers?
Message-ID: <20080421210409.e16ff587.dh@triple-media.com>

Hello,

I tried to install gnutls-2.2.2 on a freshly bootstrapped, plain
X86_64 linux 2.6.25 system with GCC 4.3.0 and the rest up-to-date too.
The build failed because of a relocation problem (definitions not in
local scope). This is why I tried 2.3.7, and it seemed to work fine.
However, though it did not 'disable' OpenSSL-compatibility (taken from
config.log), there are finally no compatibility headers on the
filesystem. I wouldn't care if not the xorg-server were dependent on
OpenSSL. Do I have to activate something or type make install-compat or
similar?

Regards,
Dennis Heuer




From massimo.gaspari at alice.it  Mon Apr 21 22:17:21 2008
From: massimo.gaspari at alice.it (Massimo Gaspari)
Date: Mon, 21 Apr 2008 22:17:21 +0200
Subject: [Help-gnutls] Re: gnutls 2.3.4 doesn't copile using MinGW
In-Reply-To: <87tzhvpgku.fsf@mocca.josefsson.org>
References: <47FFACC3.7010400@alice.it>
	<87fxtq9gjf.fsf@mocca.josefsson.org>	<48027017.6090508@alice.it>
	<87mynvvi9k.fsf@mocca.josefsson.org>	<480520B7.60302@alice.it>
	<8763ui9i8v.fsf@mocca.josefsson.org>	<480642F5.8000907@alice.it>
	<877iew25x8.fsf@mocca.josefsson.org>	<4807C2C9.3020700@alice.it>
	<87hcdzitgk.fsf@mocca.josefsson.org>	<48090C47.2060808@alice.it>
	<87ej8zqwtk.fsf@mocca.josefsson.org>	<8763ubqw7a.fsf@mocca.josefsson.org>
	<87tzhvpgku.fsf@mocca.josefsson.org>
Message-ID: <480CF651.3010607@alice.it>

Simon Josefsson wrote:
> But please try latest 2.3.7 instead, it should contain all fixes.
>   http://alpha.gnu.org/gnu/gnutls/gnutls-2.3.7.tar.bz2
>   ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.3.7.tar.bz2
>
> /Simon
>   

Ok, downloaded and configured as usual. GnuTLS compiles out of the box 
and make check is successful (no errors!).

I don't want to be a perfectionist but I am listing the few very minor 
issues.


1) a warning realted to vasprintf (an old friend , isn't it?)

/bin/sh ../libtool --tag=CC   --mode=compile gcc -std=gnu99 
-DHAVE_CONFIG_H -I. -I..  -DLOCALEDIR=\"/usr/local/share/locale\" -I../lgl
-I../lgl -I../includes -I../includes -I./x509 -I../libextra 
-I../lib/openpgp/ -I/usr/local/include -I./opencdk -I../lib/opencdk -I./min
itasn1  -I/usr/local/include -pipe -I/usr/local/include -O2 
-Wno-pointer-sign -MT gnutls_str.lo -MD -MP -MF .deps/gnutls_str.Tpo -c -o
gnutls_str.lo gnutls_str.c
libtool: compile:  gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. 
-DLOCALEDIR=\"/usr/local/share/locale\" -I../lgl -I../lgl -I../includes -I..
/includes -I./x509 -I../libextra -I../lib/openpgp/ -I/usr/local/include 
-I./opencdk -I../lib/opencdk -I./minitasn1 -I/usr/local/include
 -pipe -I/usr/local/include -O2 -Wno-pointer-sign -MT gnutls_str.lo -MD 
-MP -MF .deps/gnutls_str.Tpo -c gnutls_str.c -o gnutls_str.o
gnutls_str.c: In function '_gnutls_string_append_printf':
gnutls_str.c:238: warning: implicit declaration of function 'vasprintf'


2) A warning related to inet_pton. In a previous e-mail you said

> Problem in gnulib, I'll see if I can get these fixed.  I don't think
> this is important though.

I usually think that an implicit declaration is always dangerous, but 
you are the expert!
 
/bin/sh ../../libtool --tag=CC   --mode=compile gcc -std=gnu99 
-DHAVE_CONFIG_H -I. -I../..  -I../../includes -I../../includes -I../../l
gl -I../../lgl -I../../gl -I../../gl -I/usr/local/include -pipe 
-I/usr/local/include -O2 -Wno-pointer-sign -MT tcp.lo -MD -MP -MF .deps
/tcp.Tpo -c -o tcp.lo tcp.c
libtool: compile:  gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. 
-I../../includes -I../../includes -I../../lgl -I../../lgl -I../../gl -I..
/../gl -I/usr/local/include -pipe -I/usr/local/include -O2 
-Wno-pointer-sign -MT tcp.lo -MD -MP -MF .deps/tcp.Tpo -c tcp.c -o tcp.o
tcp.c: In function 'tcp_connect':
tcp.c:41: warning: implicit declaration of function 'inet_pton'

This warnig appears in some other files.

3)  A warning about 'setsockopt'.
In a previous e-mail you said

>Probably a buggy system header file, the argument should be 'void*'
>which should be castable from any type.

Uhm... in the MSDN documentation the 4th argument is  const char* and in 
MinGW  setsockopt  is in
winsock.h,winsock2.h and ws2spi.h. In all includes the 4th argument is 
const char*. May be in some other platform is void * but in Windows I 
think is definitively const char *.

libtool: link: gcc -std=gnu99 -pipe -I/usr/local/include -O2 
-Wno-pointer-sign -o ex-serv1.exe ex-serv1.o  ./.libs/libexamples.a 
../../lib/.libs/libgnutls.a -L/usr/local/lib 
../../libextra/.libs/libgnutls-extra.a 
/home/Massimo/gnutls-2.3.7/lib/.libs/libgnutls.a -lz -lws2_32 
../../gl/.libs/libgnu.a /usr/local/lib/libgcrypt.a 
/usr/local/lib/libgpg-error.a
gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../..  -I../../includes 
-I../../includes -I../../lgl -I../../lgl -I../../gl -I../../gl 
-I/usr/local/include -pipe -I/usr/local/include -O2 -Wno-pointer-sign 
-MT ex-serv-export.o -MD -MP -MF .deps/ex-serv-export.Tpo -c -o 
ex-serv-export.o ex-serv-export.c
ex-serv-export.c: In function 'main':
ex-serv-export.c:182: warning: passing argument 4 of 'setsockopt' from 
incompatible pointer type

4) several

libtool: link: warning: `-no-install' is ignored for i686-pc-mingw32
libtool: link: warning: assuming `-no-fast-install' instead

We can ignore those..


Hope this helps

Massimo






From simon at josefsson.org  Tue Apr 22 10:08:09 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 22 Apr 2008 10:08:09 +0200
Subject: [Help-gnutls] Re: gnutls 2.3.4 doesn't copile using MinGW
In-Reply-To: <480CF651.3010607@alice.it> (Massimo Gaspari's message of "Mon,
	21 Apr 2008 22:17:21 +0200")
References: <47FFACC3.7010400@alice.it> <87fxtq9gjf.fsf@mocca.josefsson.org>
	<48027017.6090508@alice.it> <87mynvvi9k.fsf@mocca.josefsson.org>
	<480520B7.60302@alice.it> <8763ui9i8v.fsf@mocca.josefsson.org>
	<480642F5.8000907@alice.it> <877iew25x8.fsf@mocca.josefsson.org>
	<4807C2C9.3020700@alice.it> <87hcdzitgk.fsf@mocca.josefsson.org>
	<48090C47.2060808@alice.it> <87ej8zqwtk.fsf@mocca.josefsson.org>
	<8763ubqw7a.fsf@mocca.josefsson.org>
	<87tzhvpgku.fsf@mocca.josefsson.org> <480CF651.3010607@alice.it>
Message-ID: <87k5iq5n2u.fsf@mocca.josefsson.org>

Massimo Gaspari <massimo.gaspari at alice.it> writes:

> Simon Josefsson wrote:
>> But please try latest 2.3.7 instead, it should contain all fixes.
>>   http://alpha.gnu.org/gnu/gnutls/gnutls-2.3.7.tar.bz2
>>   ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.3.7.tar.bz2
>>
>> /Simon
>>   
>
> Ok, downloaded and configured as usual. GnuTLS compiles out of the box
> and make check is successful (no errors!).

Great.  Thanks for testing.

> I don't want to be a perfectionist but I am listing the few very minor
> issues.
>
>
> 1) a warning realted to vasprintf (an old friend , isn't it?)
>
> gnutls_str.c: In function '_gnutls_string_append_printf':
> gnutls_str.c:238: warning: implicit declaration of function 'vasprintf'

This seems strange.  The gnutls_str.c file includes gnutls_int.h which
includes defines.h which includes stdio.h.  Gnulib will create stdio.h
if mingw doesn't provide one with suitable vasprintf declaration.  Can
you search for vasprintf in lgl/stdio.h and show me how the block looks?

> 2) A warning related to inet_pton. In a previous e-mail you said
>
>> Problem in gnulib, I'll see if I can get these fixed.  I don't think
>> this is important though.
>
> I usually think that an implicit declaration is always dangerous, but
> you are the expert!
...
> tcp.c:41: warning: implicit declaration of function 'inet_pton'
>
> This warnig appears in some other files.

The proper fix is to make gnulib's arpa/inet.h define them.  I'll work
on this.

> 3)  A warning about 'setsockopt'.
> In a previous e-mail you said
>
>>Probably a buggy system header file, the argument should be 'void*'
>>which should be castable from any type.
>
> Uhm... in the MSDN documentation the 4th argument is  const char* and
> in MinGW  setsockopt  is in
> winsock.h,winsock2.h and ws2spi.h. In all includes the 4th argument is
> const char*. May be in some other platform is void * but in Windows I
> think is definitively const char *.
...
> ex-serv-export.c:182: warning: passing argument 4 of 'setsockopt' from
> incompatible pointer type

According to POSIX it should be 'const void*':

http://www.opengroup.org/onlinepubs/009695399/functions/setsockopt.html

Gnulib should probably needs to add a wrapper for this as well.

> 4) several
>
> libtool: link: warning: `-no-install' is ignored for i686-pc-mingw32
> libtool: link: warning: assuming `-no-fast-install' instead
>
> We can ignore those..

I think those are harmless libtool problems, but I'm not sure.  If you
(or anyone) wants to track it down and investigate it, please do.

/Simon




From simon at josefsson.org  Tue Apr 22 17:17:03 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 22 Apr 2008 17:17:03 +0200
Subject: [Help-gnutls] Re: 64bit GnuTLS4win?
In-Reply-To: <000001c8a481$20365ff0$60a31fd0$@com> (Jonathan Manktelow's
	message of "Tue, 22 Apr 2008 14:59:43 +0100")
References: <000001c8a481$20365ff0$60a31fd0$@com>
Message-ID: <87r6cxaphs.fsf@mocca.josefsson.org>

"Jonathan Manktelow" <jonathan at dyalog.com> writes:

> Hi,
> Is there a 64bit build of gnutls available for windows? We've been using the
> 32bit for a while, but want to start using it in a 64 bit application...

Hi.  There isn't a 64bit build available right now.  There seems to be a
mingw64 project [1] around, so you could try installing that and base
the build scripts on my mingw32 tools [2].  If it turns out to be simple
to do this, please let me know and I can provide official builds.

/Simon

[1] http://sourceforge.net/projects/mingw-w64
[2] http://josefsson.org/gnutls4win/Makefile




From simon at josefsson.org  Tue Apr 22 17:32:04 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 22 Apr 2008 17:32:04 +0200
Subject: [Help-gnutls] Re: 64bit GnuTLS4win?
In-Reply-To: <87r6cxaphs.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Tue, 22 Apr 2008 17:17:03 +0200")
References: <000001c8a481$20365ff0$60a31fd0$@com>
	<87r6cxaphs.fsf@mocca.josefsson.org>
Message-ID: <87iqy9aosr.fsf@mocca.josefsson.org>

Simon Josefsson <simon at josefsson.org> writes:

> "Jonathan Manktelow" <jonathan at dyalog.com> writes:
>
>> Hi,
>> Is there a 64bit build of gnutls available for windows? We've been using the
>> 32bit for a while, but want to start using it in a 64 bit application...
>
> Hi.  There isn't a 64bit build available right now.  There seems to be a
> mingw64 project [1] around, so you could try installing that and base
> the build scripts on my mingw32 tools [2].  If it turns out to be simple
> to do this, please let me know and I can provide official builds.
>
> /Simon
>
> [1] http://sourceforge.net/projects/mingw-w64
> [2] http://josefsson.org/gnutls4win/Makefile

Btw, I also found pre-compiled binaries at:

http://drangon.org/mingw/

Also, I realized that I don't have any 64-bit capable machines to test
any of this on.

/Simon




From simon at josefsson.org  Tue Apr 22 18:41:04 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 22 Apr 2008 18:41:04 +0200
Subject: [Help-gnutls] Re: 64bit GnuTLS4win?
In-Reply-To: <000501c8a495$80103f90$8030beb0$@com> (Jonathan Manktelow's
	message of "Tue, 22 Apr 2008 17:25:36 +0100")
References: <000001c8a481$20365ff0$60a31fd0$@com>
	<87r6cxaphs.fsf@mocca.josefsson.org>
	<A46CBABCBAB04F03837454B59961B9CB@Causeway.local>
	<000501c8a495$80103f90$8030beb0$@com>
Message-ID: <87abjl6dwf.fsf@mocca.josefsson.org>

Try building libgcrypt with --disable-asm.

Also, try the recent libgcrypt 1.4.1rc1, it contains a few mingw32
fixes.

Btw, please keep cc to help-gnutls at gnu.org so that others can learn from
the discussion.

/Simon

"Jonathan Manktelow" <jonathan at dyalog.com> writes:

> Thanks for the pointers - particularly the precompiled mingw-w64.
> Unfortunately I'm stuck trying to compile the basic gnutls4win at the
> moment! (thought I should make sure I can compile that before moving to
> 64bit.)
>
> I'm getting:
>
> ../../../src/libgcrypt-1.4.0/cipher/rijndael.c:2062: error: can't find a
> register in class `GENERAL_REGS' while reloading `asm'
>
> (in do_padlock)
>
> Tying to build on Debian 4r3
>
> Have you got any ideas/suggestions? Inline assembler bugs are a little out
> of my area of expertise :)
>
> Thanks,
>
>
> Jonathan Manktelow
> Dyalog Ltd.
>
> -----Original Message-----
> From: Simon Josefsson [mailto:simon at josefsson.org] 
> Sent: 22 April 2008 16:46
> To: Jonathan Manktelow
> Cc: help-gnutls at gnu.org
> Subject: Re: 64bit GnuTLS4win?
>
> Simon Josefsson <simon at josefsson.org> writes:
>
>> "Jonathan Manktelow" <jonathan at dyalog.com> writes:
>>
>>> Hi,
>>> Is there a 64bit build of gnutls available for windows? We've been using
> the
>>> 32bit for a while, but want to start using it in a 64 bit application...
>>
>> Hi.  There isn't a 64bit build available right now.  There seems to be a
>> mingw64 project [1] around, so you could try installing that and base
>> the build scripts on my mingw32 tools [2].  If it turns out to be simple
>> to do this, please let me know and I can provide official builds.
>>
>> /Simon
>>
>> [1] http://sourceforge.net/projects/mingw-w64
>> [2] http://josefsson.org/gnutls4win/Makefile
>
> Btw, I also found pre-compiled binaries at:
>
> http://drangon.org/mingw/
>
> Also, I realized that I don't have any 64-bit capable machines to test
> any of this on.
>
> /Simon




From massimo.gaspari at alice.it  Tue Apr 22 22:55:17 2008
From: massimo.gaspari at alice.it (Massimo Gaspari)
Date: Tue, 22 Apr 2008 22:55:17 +0200
Subject: [Help-gnutls] Re: gnutls 2.3.4 doesn't copile using MinGW
In-Reply-To: <87k5iq5n2u.fsf@mocca.josefsson.org>
References: <47FFACC3.7010400@alice.it>
	<87fxtq9gjf.fsf@mocca.josefsson.org>	<48027017.6090508@alice.it>
	<87mynvvi9k.fsf@mocca.josefsson.org>	<480520B7.60302@alice.it>
	<8763ui9i8v.fsf@mocca.josefsson.org>	<480642F5.8000907@alice.it>
	<877iew25x8.fsf@mocca.josefsson.org>	<4807C2C9.3020700@alice.it>
	<87hcdzitgk.fsf@mocca.josefsson.org>	<48090C47.2060808@alice.it>
	<87ej8zqwtk.fsf@mocca.josefsson.org>	<8763ubqw7a.fsf@mocca.josefsson.org>	<87tzhvpgku.fsf@mocca.josefsson.org>
	<480CF651.3010607@alice.it> <87k5iq5n2u.fsf@mocca.josefsson.org>
Message-ID: <480E50B5.7020703@alice.it>

Simon Josefsson wrote:
>> I don't want to be a perfectionist but I am listing the few very minor
>> issues.
>>
>>
>> 1) a warning realted to vasprintf (an old friend , isn't it?)
>>
>> gnutls_str.c: In function '_gnutls_string_append_printf':
>> gnutls_str.c:238: warning: implicit declaration of function 'vasprintf'
>>     
>
> This seems strange.  The gnutls_str.c file includes gnutls_int.h which
> includes defines.h which includes stdio.h.  Gnulib will create stdio.h
> if mingw doesn't provide one with suitable vasprintf declaration.  Can
> you search for vasprintf in lgl/stdio.h and show me how the block looks?
>
>   
Here it is.

#if 1
# if 0
#  define asprintf rpl_asprintf
#  define vasprintf rpl_vasprintf
# endif
# if 0 || !1
  /* Write formatted output to a string dynamically allocated with malloc().
     If the memory allocation succeeds, store the address of the string in
     *RESULT and return the number of resulting bytes, excluding the 
trailing
     NUL.  Upon memory allocation error, or some other error, return -1.  */
  extern int asprintf (char **result, const char *format, ...)
    __attribute__ ((__format__ (__printf__, 2, 3)));
  extern int vasprintf (char **result, const char *format, va_list args)
    __attribute__ ((__format__ (__printf__, 2, 0)));
# endif
#endif

The stdio.in.h says

#if @GNULIB_VASPRINTF@
# if @REPLACE_VASPRINTF@
#  define asprintf rpl_asprintf
#  define vasprintf rpl_vasprintf
# endif
# if @REPLACE_VASPRINTF@ || !@HAVE_VASPRINTF@
  /* Write formatted output to a string dynamically allocated with malloc().
     If the memory allocation succeeds, store the address of the string in
     *RESULT and return the number of resulting bytes, excluding the 
trailing
     NUL.  Upon memory allocation error, or some other error, return -1.  */
  extern int asprintf (char **result, const char *format, ...)
    __attribute__ ((__format__ (__printf__, 2, 3)));
  extern int vasprintf (char **result, const char *format, va_list args)
    __attribute__ ((__format__ (__printf__, 2, 0)));
# endif
#endif

And the compiler is right.


>> ex-serv-export.c:182: warning: passing argument 4 of 'setsockopt' from
>> incompatible pointer type
>>     
>
> According to POSIX it should be 'const void*':
>
> http://www.opengroup.org/onlinepubs/009695399/functions/setsockopt.html
>
> Gnulib should probably needs to add a wrapper for this as well.
>   

Yes but Windows is not POSIX compliant.
>> 4) several
>>
>> libtool: link: warning: `-no-install' is ignored for i686-pc-mingw32
>> libtool: link: warning: assuming `-no-fast-install' instead
>>
>> We can ignore those..
>>     
>
> I think those are harmless libtool problems, but I'm not sure.  If you
> (or anyone) wants to track it down and investigate it, please do.
>
> /Simon
>   
I'll try to look at that.

 Massimo

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20080422/54e1aed7/attachment.htm>

From simon at josefsson.org  Wed Apr 23 01:06:25 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 23 Apr 2008 01:06:25 +0200
Subject: [Help-gnutls] Re: gnutls 2.3.4 doesn't copile using MinGW
In-Reply-To: <480E50B5.7020703@alice.it> (Massimo Gaspari's message of "Tue,
	22 Apr 2008 22:55:17 +0200")
References: <47FFACC3.7010400@alice.it> <87fxtq9gjf.fsf@mocca.josefsson.org>
	<48027017.6090508@alice.it> <87mynvvi9k.fsf@mocca.josefsson.org>
	<480520B7.60302@alice.it> <8763ui9i8v.fsf@mocca.josefsson.org>
	<480642F5.8000907@alice.it> <877iew25x8.fsf@mocca.josefsson.org>
	<4807C2C9.3020700@alice.it> <87hcdzitgk.fsf@mocca.josefsson.org>
	<48090C47.2060808@alice.it> <87ej8zqwtk.fsf@mocca.josefsson.org>
	<8763ubqw7a.fsf@mocca.josefsson.org>
	<87tzhvpgku.fsf@mocca.josefsson.org> <480CF651.3010607@alice.it>
	<87k5iq5n2u.fsf@mocca.josefsson.org> <480E50B5.7020703@alice.it>
Message-ID: <873apdbiby.fsf@mocca.josefsson.org>

Massimo Gaspari <massimo.gaspari at alice.it> writes:

>>> 1) a warning realted to vasprintf (an old friend , isn't it?)
>>>
>>> gnutls_str.c: In function '_gnutls_string_append_printf':
>>> gnutls_str.c:238: warning: implicit declaration of function 'vasprintf'
>>>     
>>
>> This seems strange.  The gnutls_str.c file includes gnutls_int.h which
>> includes defines.h which includes stdio.h.  Gnulib will create stdio.h
>> if mingw doesn't provide one with suitable vasprintf declaration.  Can
>> you search for vasprintf in lgl/stdio.h and show me how the block looks?
>>
>>   
> Here it is.
>
> #if 1
> # if 0
> #  define asprintf rpl_asprintf
> #  define vasprintf rpl_vasprintf
> # endif
> # if 0 || !1
>  /* Write formatted output to a string dynamically allocated with malloc().
>     If the memory allocation succeeds, store the address of the string in
>     *RESULT and return the number of resulting bytes, excluding the
> trailing
>     NUL.  Upon memory allocation error, or some other error, return -1.  */
>  extern int asprintf (char **result, const char *format, ...)
>    __attribute__ ((__format__ (__printf__, 2, 3)));
>  extern int vasprintf (char **result, const char *format, va_list args)
>    __attribute__ ((__format__ (__printf__, 2, 0)));
> # endif
> #endif
>
> The stdio.in.h says
>
> #if @GNULIB_VASPRINTF@
> # if @REPLACE_VASPRINTF@
> #  define asprintf rpl_asprintf
> #  define vasprintf rpl_vasprintf
> # endif
> # if @REPLACE_VASPRINTF@ || !@HAVE_VASPRINTF@
>  /* Write formatted output to a string dynamically allocated with malloc().
>     If the memory allocation succeeds, store the address of the string in
>     *RESULT and return the number of resulting bytes, excluding the
> trailing
>     NUL.  Upon memory allocation error, or some other error, return -1.  */
>  extern int asprintf (char **result, const char *format, ...)
>    __attribute__ ((__format__ (__printf__, 2, 3)));
>  extern int vasprintf (char **result, const char *format, va_list args)
>    __attribute__ ((__format__ (__printf__, 2, 0)));
> # endif
> #endif
>
> And the compiler is right.

This suggests ./configure thought that your system had vasprintf but it
was not declared anywhere.  This would be a consequence from using
libgcrypt < 1.4.1rc1.  Earlier libgcrypt versions contained an unused
implementation of vasprintf which was exported to the static library.  I
added a cludge in GnuTLS to detect and use that vasprintf, but I think
it is the wrong thing to do -- it doesn't handle the function prototype.

I have reverted the workaround.  Instead, you'll need to use libgcrypt
1.4.1rc1 to avoid the duplicate vasprintf symbol problem.  Please try
tomorrow's snapshot.

>>> ex-serv-export.c:182: warning: passing argument 4 of 'setsockopt' from
>>> incompatible pointer type
>>>     
>>
>> According to POSIX it should be 'const void*':
>>
>> http://www.opengroup.org/onlinepubs/009695399/functions/setsockopt.html
>>
>> Gnulib should probably needs to add a wrapper for this as well.
>>   
>
> Yes but Windows is not POSIX compliant.

I have added a fix in gnulib for this now, so the warning should be
gone.

>>> 4) several
>>>
>>> libtool: link: warning: `-no-install' is ignored for i686-pc-mingw32
>>> libtool: link: warning: assuming `-no-fast-install' instead
>>>
>>> We can ignore those..
>>>     
>>
>> I think those are harmless libtool problems, but I'm not sure.  If you
>> (or anyone) wants to track it down and investigate it, please do.
> I'll try to look at that.

Thanks,
Simon




From simon at josefsson.org  Mon Apr 28 11:24:25 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 28 Apr 2008 11:24:25 +0200
Subject: [Help-gnutls] Re: GnuTLS Windows package as non-exe file
In-Reply-To: <480F2617.4030301@lotharmay.de> (Lothar May's message of "Wed, 23
	Apr 2008 14:05:43 +0200")
References: <480F2617.4030301@lotharmay.de>
Message-ID: <87ej8qjprq.fsf@mocca.josefsson.org>

Hi Lothar,

Thanks for the inquiry, and thanks for using gnutls. :)

It should be easy for me to provide zip files of the various components.
I need to modify the build makefile to create zip's during build.  I'll
see if I can produce something based on a 2.3.8 snapshot.

/Simon

Lothar May <mail at lotharmay.de> writes:

> Hi Simon Josefsson,
>
> it is great that you are offering a Windows version of GnuTLS for
> download, this has saved me a lot of work! Thank you!
>
> I'm using GnuTLS for the Windows release of the open source project
> PokerTH. Anyway, I have a small problem: I'm offering an automated
> build script which downloads all libraries and automatically compiles
> PokerTH. I would like to use the "official" binary release of GnuTLS
> for this, but unfortunately, as I see things, there is only an
> interactive exe installer available for this binary release.
>
> So my question is: Could you please provide the GnuTLS Windows
> binaries also as some kind of archive (zip or whichever you prefer)?
> That would be really great!
>
> Thanks and best of luck to you,
>
> Lothar May




From simon at josefsson.org  Mon Apr 28 12:28:45 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 28 Apr 2008 12:28:45 +0200
Subject: [Help-gnutls] Re: GnuTLS Windows package as non-exe file
In-Reply-To: <87ej8qjprq.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Mon, 28 Apr 2008 11:24:25 +0200")
References: <480F2617.4030301@lotharmay.de>
	<87ej8qjprq.fsf@mocca.josefsson.org>
Message-ID: <87tzhmi882.fsf@mocca.josefsson.org>

Check out <http://josefsson.org/gnutls4win/> now, it contains a
gnutls-2.3.8.zip with the entire installation tree.  You should be able
to extract everything you need from it.  Note that this is a unreleased
development snapshot, but it should work.  Since it is now part of the
makefile, the zip file will be updated for every future release.

Does this solve the problem?  I could generate separate zip archives for
libgpg-error, libgcrypt etc, or more minimal *.DLL-only zip archives,
but I'm not sure what is useful.

There is also <http://gnuwin32.sourceforge.net/> but I don't know how to
get packages uploaded there.  They provide several zip archives for each
project, see for example
<http://gnuwin32.sourceforge.net/packages/jpeg.htm>.

/Simon

Simon Josefsson <simon at josefsson.org> writes:

> Hi Lothar,
>
> Thanks for the inquiry, and thanks for using gnutls. :)
>
> It should be easy for me to provide zip files of the various components.
> I need to modify the build makefile to create zip's during build.  I'll
> see if I can produce something based on a 2.3.8 snapshot.
>
> /Simon
>
> Lothar May <mail at lotharmay.de> writes:
>
>> Hi Simon Josefsson,
>>
>> it is great that you are offering a Windows version of GnuTLS for
>> download, this has saved me a lot of work! Thank you!
>>
>> I'm using GnuTLS for the Windows release of the open source project
>> PokerTH. Anyway, I have a small problem: I'm offering an automated
>> build script which downloads all libraries and automatically compiles
>> PokerTH. I would like to use the "official" binary release of GnuTLS
>> for this, but unfortunately, as I see things, there is only an
>> interactive exe installer available for this binary release.
>>
>> So my question is: Could you please provide the GnuTLS Windows
>> binaries also as some kind of archive (zip or whichever you prefer)?
>> That would be really great!
>>
>> Thanks and best of luck to you,
>>
>> Lothar May




From simon at josefsson.org  Mon Apr 28 13:45:01 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 28 Apr 2008 13:45:01 +0200
Subject: [Help-gnutls] Re: GnuTLS Windows package as non-exe file
In-Reply-To: <35624.BlQMCloQQFc=.1209380973.squirrel@webmailer.hosteurope.de>
	(Lothar May's message of "Mon, 28 Apr 2008 13:09:33 +0200 (CEST)")
References: <480F2617.4030301@lotharmay.de>
	<87ej8qjprq.fsf@mocca.josefsson.org>
	<87tzhmi882.fsf@mocca.josefsson.org>
	<35624.BlQMCloQQFc=.1209380973.squirrel@webmailer.hosteurope.de>
Message-ID: <87ej8qi4oy.fsf@mocca.josefsson.org>

"Lothar May" <mail at lotharmay.de> writes:

> Hi Simon,
>
> a zip file containing the installation tree would suit perfectly, and yes,
> this would solve the problem entirely. Since the PokerTH for Windows build
> script is used only by very few people, it won't hurt in terms of
> bandwidth if they download more than is actually needed.

Great.  If bandwidth becomes an issue, I can find another place to host
it.

> However, I cannot locate the file on http://josefsson.org/gnutls4win/
> - even after deleting my browser cache - maybe your upload script also
> needs an update? Or maybe I just need a little patience ;-).

It seems to be there now.  There are several scripts involved to update
that page, so perhaps they just needed some time.

/Simon

> Anyway, thank you very much for your help!
>
> Best regards,
>
> Lothar
>
>
> Am Mo, 28.04.2008, 12:28, schrieb Simon Josefsson:
>> Check out <http://josefsson.org/gnutls4win/> now, it contains a
>> gnutls-2.3.8.zip with the entire installation tree.  You should be able
>> to extract everything you need from it.  Note that this is a unreleased
>> development snapshot, but it should work.  Since it is now part of the
>> makefile, the zip file will be updated for every future release.
>>
>> Does this solve the problem?  I could generate separate zip archives for
>> libgpg-error, libgcrypt etc, or more minimal *.DLL-only zip archives,
>> but I'm not sure what is useful.
>>
>> There is also <http://gnuwin32.sourceforge.net/> but I don't know how to
>> get packages uploaded there.  They provide several zip archives for each
>> project, see for example
>> <http://gnuwin32.sourceforge.net/packages/jpeg.htm>.
>>
>> /Simon
>>




From massimo.gaspari at alice.it  Mon Apr 28 21:43:01 2008
From: massimo.gaspari at alice.it (Massimo Gaspari)
Date: Mon, 28 Apr 2008 21:43:01 +0200
Subject: [Help-gnutls] Re: gnutls 2.3.4 doesn't copile using MinGW
In-Reply-To: <873apdbiby.fsf@mocca.josefsson.org>
References: <47FFACC3.7010400@alice.it>
	<87fxtq9gjf.fsf@mocca.josefsson.org>	<48027017.6090508@alice.it>
	<87mynvvi9k.fsf@mocca.josefsson.org>	<480520B7.60302@alice.it>
	<8763ui9i8v.fsf@mocca.josefsson.org>	<480642F5.8000907@alice.it>
	<877iew25x8.fsf@mocca.josefsson.org>	<4807C2C9.3020700@alice.it>
	<87hcdzitgk.fsf@mocca.josefsson.org>	<48090C47.2060808@alice.it>
	<87ej8zqwtk.fsf@mocca.josefsson.org>	<8763ubqw7a.fsf@mocca.josefsson.org>	<87tzhvpgku.fsf@mocca.josefsson.org>
	<480CF651.3010607@alice.it>	<87k5iq5n2u.fsf@mocca.josefsson.org>
	<480E50B5.7020703@alice.it> <873apdbiby.fsf@mocca.josefsson.org>
Message-ID: <481628C5.2030404@alice.it>

Simon Josefsson wrote:
>
> I have reverted the workaround.  Instead, you'll need to use libgcrypt
> 1.4.1rc1 to avoid the duplicate vasprintf symbol problem.  Please try
> tomorrow's snapshot.
>
>   
>>>> 4) several
>>>>
>>>> libtool: link: warning: `-no-install' is ignored for i686-pc-mingw32
>>>> libtool: link: warning: assuming `-no-fast-install' instead
>>>>
>>>> We can ignore those..
>>>>     
>>>>         
>>> I think those are harmless libtool problems, but I'm not sure.  If you
>>> (or anyone) wants to track it down and investigate it, please do.
>>>       
>> I'll try to look at that.
>>     

Using gnutls-20080428.tar.gz, libgcrypt-1.4.1.tar.bz2 and 
libgpg-error-1.6.tar.7z  with the past configure option only the

libtool: link: warning: is present. All the past flagged warnings are disappeared.

I hadn't the time to look at the libtool, I'll see next.

Thank you for fixing gnutls for the MinGW.

Massimo
 






From simon at josefsson.org  Mon Apr 28 21:47:05 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 28 Apr 2008 21:47:05 +0200
Subject: [Help-gnutls] Re: gnutls 2.3.4 doesn't copile using MinGW
In-Reply-To: <481628C5.2030404@alice.it> (Massimo Gaspari's message of "Mon,
	28 Apr 2008 21:43:01 +0200")
References: <47FFACC3.7010400@alice.it> <87fxtq9gjf.fsf@mocca.josefsson.org>
	<48027017.6090508@alice.it> <87mynvvi9k.fsf@mocca.josefsson.org>
	<480520B7.60302@alice.it> <8763ui9i8v.fsf@mocca.josefsson.org>
	<480642F5.8000907@alice.it> <877iew25x8.fsf@mocca.josefsson.org>
	<4807C2C9.3020700@alice.it> <87hcdzitgk.fsf@mocca.josefsson.org>
	<48090C47.2060808@alice.it> <87ej8zqwtk.fsf@mocca.josefsson.org>
	<8763ubqw7a.fsf@mocca.josefsson.org>
	<87tzhvpgku.fsf@mocca.josefsson.org> <480CF651.3010607@alice.it>
	<87k5iq5n2u.fsf@mocca.josefsson.org> <480E50B5.7020703@alice.it>
	<873apdbiby.fsf@mocca.josefsson.org> <481628C5.2030404@alice.it>
Message-ID: <87fxt5g3t2.fsf@mocca.josefsson.org>

Massimo Gaspari <massimo.gaspari at alice.it> writes:

> Using gnutls-20080428.tar.gz, libgcrypt-1.4.1.tar.bz2 and
> libgpg-error-1.6.tar.7z  with the past configure option only the
>
> libtool: link: warning: is present. All the past flagged warnings are disappeared.
>
> I hadn't the time to look at the libtool, I'll see next.
>
> Thank you for fixing gnutls for the MinGW.

Great.  Thanks for confirming that (most) issues were fixed.

/Simon




From dev001 at pas-world.com  Tue Apr 29 11:55:02 2008
From: dev001 at pas-world.com (F.)
Date: Tue, 29 Apr 2008 11:55:02 +0200
Subject: [Help-gnutls] About certtool certs.
Message-ID: <1209462902.6680.3.camel@localhost.localdomain>

Hello,
In the past, I have used certtool to make certificates.
But seems that can not set correct bit flags and OIDs in certificate.
Problems in some cases on mozilla, and IE always.
It's solved this problem in new versions?


-- 




--
Publicidad http://www.pas-world.com





From simon at josefsson.org  Tue Apr 29 23:34:41 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 29 Apr 2008 23:34:41 +0200
Subject: [Help-gnutls] Re: About certtool certs.
In-Reply-To: <1209462902.6680.3.camel@localhost.localdomain> (F.'s message of
	"Tue, 29 Apr 2008 11:55:02 +0200")
References: <1209462902.6680.3.camel@localhost.localdomain>
Message-ID: <87wsmgs5u6.fsf@mocca.josefsson.org>

"F." <dev001 at pas-world.com> writes:

> Hello,
> In the past, I have used certtool to make certificates.
> But seems that can not set correct bit flags and OIDs in certificate.
> Problems in some cases on mozilla, and IE always.
> It's solved this problem in new versions?

Hi.  You need to describe in more detail what bit flags and OIDs you are
trying to set, and the error messages you get from Mozilla/MSIE.

/Simon




From simon at josefsson.org  Tue Apr 29 23:36:46 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 29 Apr 2008 23:36:46 +0200
Subject: [Help-gnutls] Re: gnutls-2.3.7 not installing OpenSSL-compatibility
	headers?
In-Reply-To: <20080421210409.e16ff587.dh@triple-media.com> (Dennis Heuer's
	message of "Mon, 21 Apr 2008 21:04:09 +0200")
References: <20080421210409.e16ff587.dh@triple-media.com>
Message-ID: <87skx4s5qp.fsf@mocca.josefsson.org>

Dennis Heuer <dh at triple-media.com> writes:

> Hello,
>
> I tried to install gnutls-2.2.2 on a freshly bootstrapped, plain
> X86_64 linux 2.6.25 system with GCC 4.3.0 and the rest up-to-date too.
> The build failed because of a relocation problem (definitions not in
> local scope). This is why I tried 2.3.7, and it seemed to work fine.
> However, though it did not 'disable' OpenSSL-compatibility (taken from
> config.log), there are finally no compatibility headers on the
> filesystem. I wouldn't care if not the xorg-server were dependent on
> OpenSSL. Do I have to activate something or type make install-compat or
> similar?

No, the default install should have installed
$prefix/include/gnutls/openssl.h for you.  Didn't it work?  Note that
our openssl compat library requires source modifications to include the
new header file.  It is also rather limited in functionality it
provides.

Btw, we hope to release an updated stable 2.2.x release that fixes the
relocation problem (which only happens with gcc 4.3.x).

/Simon




From simon at josefsson.org  Tue Apr 29 23:38:50 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 29 Apr 2008 23:38:50 +0200
Subject: [Help-gnutls] Re: gnutls_transport_ptr and int fd's
In-Reply-To: <dc67eef70804180819n3b01b5b3of322f9af1a634f9c@mail.gmail.com>
	(Rainer Gerhards's message of "Fri, 18 Apr 2008 17:19:29 +0200")
References: <dc67eef70804180819n3b01b5b3of322f9af1a634f9c@mail.gmail.com>
Message-ID: <87od7ss5n9.fsf@mocca.josefsson.org>

"Rainer Gerhards" <rgerhards at gmail.com> writes:

> Hi all,
>
> [working on Fedora 8 with GCC]
>
> I have a minor nit. The root cause is probably not in GnuTLS but in me
> overlooking something...
>
> I supply the int fd I got from socket() to gnutls_transport_set_ptr().
> However, when I do so, I receive the following GCC warning:
>
> cast to pointer from integer of different size
>
> This is annoying during the build process, but of course tolerable. I
> would prefer to see this warning go away, but I do not like to reduce
> GCCs warning level. Any advise would be appreciated.

Try to use a cast when calling the function, such as:

  gnutls_transport_set_ptr (session, (gnutls_transport_ptr) sockfd);

> PS: I have finally gotten my code ready for TLS implementation. I
> managed to send the first TLS records within an hour or so. Good
> examples, excellent API [of course, my implementation is currently far
> from being secure ;)].

Cool!

/Simon




From simon at josefsson.org  Wed Apr 30 00:24:20 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 30 Apr 2008 00:24:20 +0200
Subject: [Help-gnutls] Re: gnutls-2.3.7 not installing OpenSSL-compatibility
	headers?
In-Reply-To: <20080430000904.af47c172.dh@triple-media.com> (Dennis Heuer's
	message of "Wed, 30 Apr 2008 00:09:04 +0200")
References: <20080421210409.e16ff587.dh@triple-media.com>
	<87skx4s5qp.fsf@mocca.josefsson.org>
	<20080430000904.af47c172.dh@triple-media.com>
Message-ID: <87ej8ol2p7.fsf@mocca.josefsson.org>

Dennis Heuer <dh at triple-media.com> writes:

>> No, the default install should have installed
>> $prefix/include/gnutls/openssl.h for you.  Didn't it work?  Note that
>> our openssl compat library requires source modifications to include the
>> new header file.  It is also rather limited in functionality it
>> provides.
>
>
> It worked but xorg isn't modified :) I installed openssl because curl
> and others can't work with this compat-layer, it seems :(

Right, they need modifications to use our compat-layer.  As far as I
recall, curl supports GnuTLS natively though.  I don't know about
xorg-server.

/Simon