From derleader at abv.bg  Sun Oct  2 15:12:48 2011
From: derleader at abv.bg (derleader mail)
Date: Sun, 2 Oct 2011 16:12:48 +0300 (EEST)
Subject: how to generate certificate and key for examples
Message-ID: <524951370.43082.1317561168542.JavaMail.apache@mail21.abv.bg>

 
Hi,

 I'm trying to test the sample TLS echo server and client, supporting X.509 and PSK


 authentication. The files are located in doc/examples - ex-serv-psk and ex-client-psk. I compiled them and I generate and certificate and key. But when I try to test them this message appears 

*** Handshake failed
GnuTLS error: Insufficient credentials for that request.

It seems that the certificate is wrong. Can you tell me how to generate appropriate certificate and key.

Regards


-----------------------------------------------------------------
100 ?? ?????. ???-?????? ???????????. Tempobet.com
http://bg.tempobet.com/affiliates/3208311
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20111002/cad22929/attachment.htm>

From erinn.looneytriggs at gmail.com  Tue Oct 11 04:24:13 2011
From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs)
Date: Mon, 10 Oct 2011 18:24:13 -0800
Subject: Unable to process private key
Message-ID: <4E93A8CD.3080004@gmail.com>

I am receiving the following error when trying to use gnutls-cli:

gnutls-cli --x509cafile /etc/pki/certmaster/ca.cert --x509keyfile
foo.example.com.pem --x509certfile foo.example.com.cert -p 514
bar.example.com
Processed 1 CA certificate(s).
Processed 1 client certificates...
*** Error loading key file: Base64 decoding error.

I am able to successfully render the private key using openssl:

openssl rsa -noout -text -in <key>

Is their an equivalent command for gnutls?

However, I am unsure of what the problem with the key is that I am
looking for, any guidance would be greatly appreciated.

This is gnutls-2.8.5-4.el6.x86_64 on a RHEL 6 system.

Thanks,
-Erinn



From ml at wzff.de  Tue Oct 11 11:56:16 2011
From: ml at wzff.de (Moritz Wilhelmy)
Date: Tue, 11 Oct 2011 11:56:16 +0200
Subject: Generating a certificate with multiple common names
Message-ID: <20111011095616.GG16096@barfooze.de>

Hello,

it isn't all too obvious to me from the documentation how to generate a
certificate with more than one CN with certtool(1), and what the
template file syntax for this looks like.

Maybe I'm not looking around enough, but just by quickly looking over
this list's archive I didn't find anything either.

The story behind this is that we have two second-level domains, and
want our certificates to be valid for both of them.

Is this possible at all? At least openssl seems to support it, but I
would prefer knowing how to do it with certtool.


Best regards,

Moritz Wilhelmy



From nmav at gnutls.org  Tue Oct 11 17:30:54 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 11 Oct 2011 17:30:54 +0200
Subject: Unable to process private key
In-Reply-To: <4E93A8CD.3080004@gmail.com>
References: <4E93A8CD.3080004@gmail.com>
Message-ID: <CAJU7za+ryvqMSnNx703bohUcFyLrQUanwHFqTkrKsuRHjQqHoA@mail.gmail.com>

On Tue, Oct 11, 2011 at 4:24 AM, Erinn Looney-Triggs
<erinn.looneytriggs at gmail.com> wrote:
> I am receiving the following error when trying to use gnutls-cli:
> gnutls-cli --x509cafile /etc/pki/certmaster/ca.cert --x509keyfile
> foo.example.com.pem --x509certfile foo.example.com.cert -p 514
> bar.example.com
> Processed 1 CA certificate(s).
> Processed 1 client certificates...
> *** Error loading key file: Base64 decoding error.

I suppose it is a base64 decoding error? It could be that there are
carriage returns, spaces or tabs in the PEM encoded file and gnutls
2.8.x doesn't like them.

> I am able to successfully render the private key using openssl:
> openssl rsa -noout -text -in <key>

openssl as well as Gnutls 2.12.x are more liberal in PEM (base64) decoding.

> Is their an equivalent command for gnutls?

Upgrade to 2.12.x or use openssl to convert the file to "correct"
encoding and then try loading again.

regards,
Nikos



From erinn.looneytriggs at gmail.com  Tue Oct 11 18:34:49 2011
From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs)
Date: Tue, 11 Oct 2011 08:34:49 -0800
Subject: Unable to process private key
In-Reply-To: <CAJU7za+ryvqMSnNx703bohUcFyLrQUanwHFqTkrKsuRHjQqHoA@mail.gmail.com>
References: <4E93A8CD.3080004@gmail.com>
	<CAJU7za+ryvqMSnNx703bohUcFyLrQUanwHFqTkrKsuRHjQqHoA@mail.gmail.com>
Message-ID: <4E947029.7000507@gmail.com>

On 10/11/2011 07:30 AM, Nikos Mavrogiannopoulos wrote:
> On Tue, Oct 11, 2011 at 4:24 AM, Erinn Looney-Triggs
> <erinn.looneytriggs at gmail.com> wrote:
>> I am receiving the following error when trying to use gnutls-cli:
>> gnutls-cli --x509cafile /etc/pki/certmaster/ca.cert --x509keyfile
>> foo.example.com.pem --x509certfile foo.example.com.cert -p 514
>> bar.example.com
>> Processed 1 CA certificate(s).
>> Processed 1 client certificates...
>> *** Error loading key file: Base64 decoding error.
> I suppose it is a base64 decoding error? It could be that there are
> carriage returns, spaces or tabs in the PEM encoded file and gnutls
> 2.8.x doesn't like them.
>
>> I am able to successfully render the private key using openssl:
>> openssl rsa -noout -text -in <key>
> openssl as well as Gnutls 2.12.x are more liberal in PEM (base64) decoding.
>
>> Is their an equivalent command for gnutls?
> Upgrade to 2.12.x or use openssl to convert the file to "correct"
> encoding and then try loading again.
>
> regards,
> Nikos

Thanks, I dug into this further last night. I am no expert in this realm
but it looks like the problem lies in the fact that the key is in PKCS#8
format. With the version of gnutls I have on RHEL 6, certtool will
happily decode it automatically via certtool -k, however, gnutls-cli
will not, nor in fact will rsyslog which is what really drove me down
this path. Rsyslog simply crashes and core dumps. Rumor is that there is
a gnutls function that will automatically detect/decode pkcs#8 format,
but I have yet to find it or fully understand this situation, so I am
continuing to look. Again if you have any advice I would apprecciate it,
upgrading isn't much of an option at least in the short term, I may be
able to coax Red Hat into an upgrade but I doubt it.

-Erinn




From nmav at gnutls.org  Tue Oct 11 18:42:00 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 11 Oct 2011 18:42:00 +0200
Subject: Unable to process private key
In-Reply-To: <4E947029.7000507@gmail.com>
References: <4E93A8CD.3080004@gmail.com>
	<CAJU7za+ryvqMSnNx703bohUcFyLrQUanwHFqTkrKsuRHjQqHoA@mail.gmail.com>
	<4E947029.7000507@gmail.com>
Message-ID: <CAJU7zaJXxb-2KUqLjtMCRadqZ1sffKCk28AzNJ_e+NYZJmn=aQ@mail.gmail.com>

On Tue, Oct 11, 2011 at 6:34 PM, Erinn Looney-Triggs
<erinn.looneytriggs at gmail.com> wrote:

> Thanks, I dug into this further last night. I am no expert in this realm
> but it looks like the problem lies in the fact that the key is in PKCS#8
> format.
> With the version of gnutls I have on RHEL 6, certtool will
> happily decode it automatically via certtool -k, however, gnutls-cli
> will not, nor in fact will rsyslog which is what really drove me down

Ah. In that case just use the output of certtool -k to gnutls-cli or
the program your want to use.

> this path. Rsyslog simply crashes and core dumps. Rumor is that there is
> a gnutls function that will automatically detect/decode pkcs#8 format,

If you used 2.12.x the decoder would have falled back to pkcs #8.

regards,
Nikos



From nmav at gnutls.org  Tue Oct 11 19:10:27 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 11 Oct 2011 19:10:27 +0200
Subject: Generating a certificate with multiple common names
In-Reply-To: <20111011095616.GG16096@barfooze.de>
References: <20111011095616.GG16096@barfooze.de>
Message-ID: <4E947883.5020905@gnutls.org>

On 10/11/2011 11:56 AM, Moritz Wilhelmy wrote:
> Hello,
>
> it isn't all too obvious to me from the documentation how to generate a
> certificate with more than one CN with certtool(1), and what the
> template file syntax for this looks like.

Using multiple CNs is not correct. You should use the dns_name
directive, and you can add as many as you like.

regards,
Nikos



From erinn.looneytriggs at gmail.com  Tue Oct 11 19:37:57 2011
From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs)
Date: Tue, 11 Oct 2011 09:37:57 -0800
Subject: Unable to process private key
In-Reply-To: <CAJU7zaJXxb-2KUqLjtMCRadqZ1sffKCk28AzNJ_e+NYZJmn=aQ@mail.gmail.com>
References: <4E93A8CD.3080004@gmail.com>
	<CAJU7za+ryvqMSnNx703bohUcFyLrQUanwHFqTkrKsuRHjQqHoA@mail.gmail.com>
	<4E947029.7000507@gmail.com>
	<CAJU7zaJXxb-2KUqLjtMCRadqZ1sffKCk28AzNJ_e+NYZJmn=aQ@mail.gmail.com>
Message-ID: <4E947EF5.1030807@gmail.com>

On 10/11/2011 08:42 AM, Nikos Mavrogiannopoulos wrote:
> On Tue, Oct 11, 2011 at 6:34 PM, Erinn Looney-Triggs
> <erinn.looneytriggs at gmail.com> wrote:
>
>> Thanks, I dug into this further last night. I am no expert in this realm
>> but it looks like the problem lies in the fact that the key is in PKCS#8
>> format.
>> With the version of gnutls I have on RHEL 6, certtool will
>> happily decode it automatically via certtool -k, however, gnutls-cli
>> will not, nor in fact will rsyslog which is what really drove me down
> Ah. In that case just use the output of certtool -k to gnutls-cli or
> the program your want to use.
>
>> this path. Rsyslog simply crashes and core dumps. Rumor is that there is
>> a gnutls function that will automatically detect/decode pkcs#8 format,
> If you used 2.12.x the decoder would have falled back to pkcs #8.
>
> regards,
> Nikos

So versions of gnutls < 2.12 will not automagically decode it? Just want
to make sure so I can figure out which direction to push Red Hat in (if
I can push them at all).

-Erinn




From nmav at gnutls.org  Tue Oct 11 20:10:29 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 11 Oct 2011 20:10:29 +0200
Subject: Unable to process private key
In-Reply-To: <4E947EF5.1030807@gmail.com>
References: <4E93A8CD.3080004@gmail.com>
	<CAJU7za+ryvqMSnNx703bohUcFyLrQUanwHFqTkrKsuRHjQqHoA@mail.gmail.com>
	<4E947029.7000507@gmail.com>
	<CAJU7zaJXxb-2KUqLjtMCRadqZ1sffKCk28AzNJ_e+NYZJmn=aQ@mail.gmail.com>
	<4E947EF5.1030807@gmail.com>
Message-ID: <4E948695.1010308@gnutls.org>

On 10/11/2011 07:37 PM, Erinn Looney-Triggs wrote:

> So versions of gnutls<  2.12 will not automagically decode it? Just want
> to make sure so I can figure out which direction to push Red Hat in (if
> I can push them at all).

This change occurred after 2.12.0.

regards,
Nikos



From nmav at gnutls.org  Sat Oct 15 01:49:54 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 15 Oct 2011 01:49:54 +0200
Subject: gnutls 3.0.4
Message-ID: <4E98CAA2.8010908@gnutls.org>

Hello,
  I've just released gnutls 3.0.4. It includes several bug fixes
and adds new features to the latest stable branch. Moreover since this
version the printed manual (see
http://www.gnu.org/software/gnutls/documentation.html ) is no longer
used as a donation method, and is available at the printing cost.

The changelog since 3.0.3 follows.

* Version 3.0.4 (released 2011-10-15)

** gnutls-cli-debug: Added more tests including AES-GCM,
SHA256 and elliptic curves.

** gnutls-cli: Added --benchmark-soft-ciphers to benchmark
the software version of the ciphers instead of hw accelerated
(where available)

** libgnutls: Public key ID calculation is consistent among
all structures. It uses a SHA-1 hash of the subjectPublicKeyInfo.

** libgnutls: gnutls_privkey_t allows setting external callback
to perform signing or decryption. Can be set using
gnutls_privkey_import_ext()

** libgnutls: A certificate credentials structure can be
used with a gnutls_privkey_t and a gnutls_pcert_st
structure using gnutls_certificate_set_key().

** libgnutls: Fixes to enable external signing callback to
operate with TLS 1.2.

** libgnutls: Fixed crash when printing ECDSA certificate key
ID. Reported by Erik Jensen.

** libgnutls: Corrected VIA padlock code for C3. In C3 benchmarks
show a 2x increase in AES speed and a 14x increase in VIA nano. Added
support for hashes and HMACs.

** libgnutls: Compilation fixed when p11-kit is not detected.

** libgnutls: Fixed the deflate compression code.

** libgnutls: Added gnutls_x509_crt_get_authority_info_access.
Used to get the PKIX Authority Information Access (AIA) field.

** libgnutls: gnutls_x509_crt_print supports printing AIA fields.

** libgnutls: Added ability to gnutls_privkey_t to operate with
signing callback function.

** API and ABI modifications:
gnutls_x509_crt_get_authority_info_access (x509.h): Added function.
gnutls_privkey_import_ext: Added function.
gnutls_certificate_set_key: Added function.
gnutls_info_access_what_t (x509.h): Added enum.
GNUTLS_OID_AIA (x509.h): Added symbol.
GNUTLS_OID_AD_OCSP (x509.h): Added symbol.
GNUTLS_OID_AD_CAISSUERS (x509.h): Added symbol.


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

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

Here are the XZ compressed sources:

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

Here are OpenPGP detached signatures signed using key 0x96865171:

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

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

regards,
Nikos



From alfredo.pironti at inria.fr  Mon Oct 17 17:59:01 2011
From: alfredo.pironti at inria.fr (Alfredo Pironti)
Date: Mon, 17 Oct 2011 17:59:01 +0200
Subject: GCM Implementation and TLSCompressed.Length
Message-ID: <CALR0uiJEYqkRB2PszcgFPhMuYrDbuNCe-oa3Tji3VkUQjVfVFw@mail.gmail.com>

Dear list,

I'm a post-doc researcher at INRIA, France, and I'm developing a TLS
implementation (with the goal of formal verification), and I would
like to include support for AEAD ciphers (e.g. AEAD_AES_128_GCM).
However, I got stuck because of the following problem.

According to RFC 5246, sec 6.2.3.3, the additional data (AD) for AEAD
consist of "seq_num + TLSCompressed.type + TLSCompressed.version +
TLSCompressed.length".
Computing such AD, and in particular TLSCompressed.length, is feasible
when encrypting. However, when decrypting it seems impossible to me to
retrieve that value (indeed it should be secret, and the AEAD
ciphertext should not reveal the size of the plaintext, right? After
all, in the Mac-then-encrypt mode of TLS, random padding is added for
this exact purpose -- and TLSCompressed.length becomes available only
after decryption, and before mac verification).

Can you please explain me where am I wrong?
I tried to take a quick look at the GnuTLS implementation of GCM (the
only open source TLS implementation I'm aware of implementing GCM),
but I could not find an evident mapping between the AEAD interface
described in RFC 5246 and the code, especially w.r.t. to the AD. Have
you got any hint about it?

Thank you very much in advance for your support.

Best,
Alfredo



From nmav at gnutls.org  Tue Oct 18 00:01:03 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 18 Oct 2011 00:01:03 +0200
Subject: GCM Implementation and TLSCompressed.Length
In-Reply-To: <CALR0uiJEYqkRB2PszcgFPhMuYrDbuNCe-oa3Tji3VkUQjVfVFw@mail.gmail.com>
References: <CALR0uiJEYqkRB2PszcgFPhMuYrDbuNCe-oa3Tji3VkUQjVfVFw@mail.gmail.com>
Message-ID: <4E9CA59F.4000803@gnutls.org>

On 10/17/2011 05:59 PM, Alfredo Pironti wrote:

Hello Alfredo,

> I'm a post-doc researcher at INRIA, France, and I'm developing a TLS
> implementation (with the goal of formal verification), and I would
> like to include support for AEAD ciphers (e.g. AEAD_AES_128_GCM).
> However, I got stuck because of the following problem.
> According to RFC 5246, sec 6.2.3.3, the additional data (AD) for AEAD
> consist of "seq_num + TLSCompressed.type + TLSCompressed.version +
> TLSCompressed.length".
> Computing such AD, and in particular TLSCompressed.length, is feasible
> when encrypting. However, when decrypting it seems impossible to me to
> retrieve that value (indeed it should be secret, and the AEAD
> ciphertext should not reveal the size of the plaintext, right?

The supported AEAD ciphers in TLS are stream thus the length of the 
ciphertext is the length of the plaintext. The spec prevents block AEAD 
ciphers or any kind of random padding to be added in the future.

> After
> all, in the Mac-then-encrypt mode of TLS, random padding is added for
> this exact purpose -- and TLSCompressed.length becomes available only
> after decryption, and before mac verification).
> Can you please explain me where am I wrong?

You are not. The spec was published in haste. However it works because 
the currently supported AEAD ciphers are stream.

regards,
Nikos



From alfredo.pironti at inria.fr  Tue Oct 18 13:30:28 2011
From: alfredo.pironti at inria.fr (Alfredo Pironti)
Date: Tue, 18 Oct 2011 13:30:28 +0200
Subject: GCM Implementation and TLSCompressed.Length
In-Reply-To: <4E9CA59F.4000803@gnutls.org>
References: <CALR0uiJEYqkRB2PszcgFPhMuYrDbuNCe-oa3Tji3VkUQjVfVFw@mail.gmail.com>
	<4E9CA59F.4000803@gnutls.org>
Message-ID: <CALR0uiLZBZyfriJ93-pxxT3HFOFp=TGMpLu76F6F+17aaHJoxw@mail.gmail.com>

Dear Nikos,

Thank you very much, that clarified things a lot. I re-read docs in
this perspective and things work now (still, I find TLS RFC a bit
misleading when citing padding in the AEAD section).

Practically, when I have an AEAD ciphertext in GCM mode, I subtract 16
to its length (in bytes), and that's the plaintext length, isn't it?

Best,
Alfredo

On Tue, Oct 18, 2011 at 12:01 AM, Nikos Mavrogiannopoulos
<nmav at gnutls.org> wrote:
> On 10/17/2011 05:59 PM, Alfredo Pironti wrote:
>
> Hello Alfredo,
>
>> I'm a post-doc researcher at INRIA, France, and I'm developing a TLS
>> implementation (with the goal of formal verification), and I would
>> like to include support for AEAD ciphers (e.g. AEAD_AES_128_GCM).
>> However, I got stuck because of the following problem.
>> According to RFC 5246, sec 6.2.3.3, the additional data (AD) for AEAD
>> consist of "seq_num + TLSCompressed.type + TLSCompressed.version +
>> TLSCompressed.length".
>> Computing such AD, and in particular TLSCompressed.length, is feasible
>> when encrypting. However, when decrypting it seems impossible to me to
>> retrieve that value (indeed it should be secret, and the AEAD
>> ciphertext should not reveal the size of the plaintext, right?
>
> The supported AEAD ciphers in TLS are stream thus the length of the
> ciphertext is the length of the plaintext. The spec prevents block AEAD
> ciphers or any kind of random padding to be added in the future.
>
>> After
>> all, in the Mac-then-encrypt mode of TLS, random padding is added for
>> this exact purpose -- and TLSCompressed.length becomes available only
>> after decryption, and before mac verification).
>> Can you please explain me where am I wrong?
>
> You are not. The spec was published in haste. However it works because the
> currently supported AEAD ciphers are stream.
>
> regards,
> Nikos
>
> _______________________________________________
> Help-gnutls mailing list
> Help-gnutls at gnu.org
> https://lists.gnu.org/mailman/listinfo/help-gnutls
>



From nmav at gnutls.org  Tue Oct 18 15:37:44 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 18 Oct 2011 15:37:44 +0200
Subject: GCM Implementation and TLSCompressed.Length
In-Reply-To: <CALR0uiLZBZyfriJ93-pxxT3HFOFp=TGMpLu76F6F+17aaHJoxw@mail.gmail.com>
References: <CALR0uiJEYqkRB2PszcgFPhMuYrDbuNCe-oa3Tji3VkUQjVfVFw@mail.gmail.com>	<4E9CA59F.4000803@gnutls.org>
	<CALR0uiLZBZyfriJ93-pxxT3HFOFp=TGMpLu76F6F+17aaHJoxw@mail.gmail.com>
Message-ID: <4E9D8128.7030108@gnutls.org>

On 10/18/2011 01:30 PM, Alfredo Pironti wrote:
> Dear Nikos,
>
> Thank you very much, that clarified things a lot. I re-read docs in
> this perspective and things work now (still, I find TLS RFC a bit
> misleading when citing padding in the AEAD section).
>
> Practically, when I have an AEAD ciphertext in GCM mode, I subtract 16
> to its length (in bytes), and that's the plaintext length, isn't it?

You have to subtract the AEAD explicit data and the tag (16+8).

Check how gnutls does it:

http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=blob;f=lib/gnutls_cipher.c;h=716b7c9bd261ba7e38ab493ab74d34d839d66244;hb=HEAD#l458


regards,
Nikos



From mwd at cert.org  Wed Oct 19 20:30:44 2011
From: mwd at cert.org (Michael Welsh Duggan)
Date: Wed, 19 Oct 2011 14:30:44 -0400
Subject: Checking CA expiration
Message-ID: <tntd3dsbzqj.fsf@waterbuck.yellow.cert.org>

In our code, we add CAs to our credentials using
gnutls_set_x509_trust_file.  In gnutls 2.x, we then get a list of the
CAs using gnutls_certificate_get_x509_cas which we then use to verify
that at least one of the CAs has not yet expired.  We want to do this
_before_ initiating a session.

Is this possible in gnutls 3.x?  gnutls_certificate_get_x509_cas has
gone away, supposedly in favor of gnutls_certificate_get_issuer(), but
that requires an existing session.

-- 
Michael Welsh Duggan
(mwd at cert.org)



From nmav at gnutls.org  Thu Oct 20 09:34:07 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 20 Oct 2011 09:34:07 +0200
Subject: Checking CA expiration
In-Reply-To: <tntd3dsbzqj.fsf@waterbuck.yellow.cert.org>
References: <tntd3dsbzqj.fsf@waterbuck.yellow.cert.org>
Message-ID: <4E9FCEEF.8000803@gnutls.org>

On 10/19/2011 08:30 PM, Michael Welsh Duggan wrote:
> In our code, we add CAs to our credentials using
> gnutls_set_x509_trust_file.  In gnutls 2.x, we then get a list of the
> CAs using gnutls_certificate_get_x509_cas which we then use to verify
> that at least one of the CAs has not yet expired.  We want to do this
> _before_ initiating a session.
> Is this possible in gnutls 3.x?  gnutls_certificate_get_x509_cas has
> gone away, supposedly in favor of gnutls_certificate_get_issuer(), but
> that requires an existing session.

Why not use gnutls_x509_crt_list_import() or 
gnutls_x509_crt_list_import2() and traverse the list of the CAs? The 
access to the the CA list in the credentials structure has been 
restricted to allow for future internal changes.

regards,
Nikos



From nmav at gnutls.org  Thu Oct 20 21:18:57 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 20 Oct 2011 21:18:57 +0200
Subject: gnutls 2.12.12
Message-ID: <4EA07421.9060003@gnutls.org>

Hello,
  I've just released gnutls 2.12.12. This is a bugfix
release on the 2.12.x branch.

Version 2.12.12 (released 2011-10-20)

** gnulib: updated

** libgnutls: Fixes to enable external signing callback to
operate with TLS 1.2.

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



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

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

Here are the BZIP2 compressed sources:

   ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.12.12.tar.bz2
   http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.12.tar.bz2

Here are OpenPGP detached signatures signed using key 0x96865171:

   ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.12.12.tar.bz2.sig
   http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.12.tar.bz2.sig

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

regards,
Nikos



From mwd at cert.org  Thu Oct 20 21:37:13 2011
From: mwd at cert.org (Michael Welsh Duggan)
Date: Thu, 20 Oct 2011 15:37:13 -0400
Subject: Checking CA expiration
In-Reply-To: <4E9FCEEF.8000803@gnutls.org> (Nikos Mavrogiannopoulos's message
	of "Thu, 20 Oct 2011 03:34:07 -0400")
References: <tntd3dsbzqj.fsf@waterbuck.yellow.cert.org>
	<4E9FCEEF.8000803@gnutls.org>
Message-ID: <tntzkgvfo9i.fsf@waterbuck.yellow.cert.org>

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> On 10/19/2011 08:30 PM, Michael Welsh Duggan wrote:
>> In our code, we add CAs to our credentials using
>> gnutls_set_x509_trust_file.  In gnutls 2.x, we then get a list of the
>> CAs using gnutls_certificate_get_x509_cas which we then use to verify
>> that at least one of the CAs has not yet expired.  We want to do this
>> _before_ initiating a session.
>> Is this possible in gnutls 3.x?  gnutls_certificate_get_x509_cas has
>> gone away, supposedly in favor of gnutls_certificate_get_issuer(), but
>> that requires an existing session.
>
> Why not use gnutls_x509_crt_list_import() or 
> gnutls_x509_crt_list_import2() and traverse the list of the CAs? The 
> access to the the CA list in the credentials structure has been 
> restricted to allow for future internal changes.

Yup this works.  There are so many API calls, it can be difficult to
determine which ones to use.

-- 
Michael Welsh Duggan
(mwd at cert.org)



From hoyt6 at llnl.gov  Thu Oct 20 23:27:32 2011
From: hoyt6 at llnl.gov (Hoyt, David)
Date: Thu, 20 Oct 2011 14:27:32 -0700
Subject: gnutls 3.0.4 and mingw-w64 build issues
Message-ID: <B288BDCCFC5B874BBC7D22117EDFB6F9010B335C76B5@NSPEXMBX-C.the-lab.llnl.gov>

When building 3.0.4 with mingw-w64 (gcc 4.5.2) on a windows 7 machine, I get the following error:


In file included from gnutls-3.0.4/lib/x509/common.c:24:0:
gnutls-3.0.4/lib/x509/../gnutls_int.h:46:24: fatal error: sys/socket.h: No such file or directory
compilation terminated. 


I double checked and I do not have sys/socket.h. What's the correct fix for gnutls_int.h? Removing the include altogether allowed compilation to proceed further (so perhaps the include could be guarded if needed elsewhere), but then I got:


In file included from gnutls-3.0.4/lib/accelerated/x86/sha-padlock.c:24:0:
gnutls-3.0.4/lib/accelerated/x86/../../gnutls_int.h:65:27: fatal error: gnutls/gnutls.h: No such file or directory
compilation terminated.
make[4]: *** [sha-padlock.lo] Error 1


Not exactly sure what's the best way to fix that.

Thanks,
- David Hoyt



From simon at josefsson.org  Fri Oct 21 13:26:08 2011
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 21 Oct 2011 13:26:08 +0200
Subject: gnutls 3.0.4 and mingw-w64 build issues
In-Reply-To: <B288BDCCFC5B874BBC7D22117EDFB6F9010B335C76B5@NSPEXMBX-C.the-lab.llnl.gov>
	(David Hoyt's message of "Thu, 20 Oct 2011 14:27:32 -0700")
References: <B288BDCCFC5B874BBC7D22117EDFB6F9010B335C76B5@NSPEXMBX-C.the-lab.llnl.gov>
Message-ID: <87botamvqn.fsf@latte.josefsson.org>

"Hoyt, David" <hoyt6 at llnl.gov> writes:

> When building 3.0.4 with mingw-w64 (gcc 4.5.2) on a windows 7 machine,
> I get the following error:
>
>
> In file included from gnutls-3.0.4/lib/x509/common.c:24:0:
> gnutls-3.0.4/lib/x509/../gnutls_int.h:46:24: fatal error:
> sys/socket.h: No such file or directory
> compilation terminated. 
>
>
> I double checked and I do not have sys/socket.h. What's the correct
> fix for gnutls_int.h?

You should have a sys/socket.h in the GnuTLS build tree somewhere, from
gnulib.  Some -I's are missing, I've pushed this patch:

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

> Removing the include altogether allowed compilation to proceed further
> (so perhaps the include could be guarded if needed elsewhere), but
> then I got:
>
>
> In file included from gnutls-3.0.4/lib/accelerated/x86/sha-padlock.c:24:0:
> gnutls-3.0.4/lib/accelerated/x86/../../gnutls_int.h:65:27: fatal
> error: gnutls/gnutls.h: No such file or directory
> compilation terminated.
> make[4]: *** [sha-padlock.lo] Error 1

Similar issue, I've added:

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

Please try building from git, or try next release.

/Simon



From hoyt6 at llnl.gov  Fri Oct 21 20:14:19 2011
From: hoyt6 at llnl.gov (Hoyt, David)
Date: Fri, 21 Oct 2011 11:14:19 -0700
Subject: gnutls 3.0.4 and mingw-w64 build issues
In-Reply-To: <87botamvqn.fsf@latte.josefsson.org>
References: <B288BDCCFC5B874BBC7D22117EDFB6F9010B335C76B5@NSPEXMBX-C.the-lab.llnl.gov>
	<87botamvqn.fsf@latte.josefsson.org>
Message-ID: <B288BDCCFC5B874BBC7D22117EDFB6F9010B39E19415@NSPEXMBX-C.the-lab.llnl.gov>

> You should have a sys/socket.h in the GnuTLS build tree somewhere, from
> gnulib.  Some -I's are missing, I've pushed this patch:

Thank you very much! Those patches helped push through a bit further. I grabbed the latest from git, but I still had to make another adjustment to "lib/accelerated/x86/Makefile.am" -- similar to your patch, I had to add "-I$(builddir)/../../../gl" to AM_CPPFLAGS. If it isn't obvious by now, I'm trying to compile from a separate build directory than my source (as is the typical recommendation).

> Please try building from git, or try next release.

Configure proceeded fine, but then during the build, I got the following errors (and a whole lot more exactly like it, just on different lines): 

gnutls-3.0.4-git/lib/accelerated/x86/asm/appro-aes-x86.s: Assembler messages:
gnutls-3.0.4-git/lib/accelerated/x86/asm/appro-aes-x86.s:41: Warning: .type pseudo-op used outside of .def/.endef ignored.
gnutls-3.0.4-git/lib/accelerated/x86/asm/appro-aes-x86.s:41: Error: junk at end of line, first unrecognized character is `a'
gnutls-3.0.4-git/lib/accelerated/x86/asm/appro-aes-x86.s:63: Warning: .size pseudo-op used outside of .def/.endef ignored.
gnutls-3.0.4-git/lib/accelerated/x86/asm/appro-aes-x86.s:63: Error: junk at end of line, first unrecognized character is `a'

Any thoughts?

Thanks,
- David Hoyt



From nmav at gnutls.org  Fri Oct 21 20:47:24 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 21 Oct 2011 20:47:24 +0200
Subject: gnutls 3.0.4 and mingw-w64 build issues
In-Reply-To: <B288BDCCFC5B874BBC7D22117EDFB6F9010B39E19415@NSPEXMBX-C.the-lab.llnl.gov>
References: <B288BDCCFC5B874BBC7D22117EDFB6F9010B335C76B5@NSPEXMBX-C.the-lab.llnl.gov>	<87botamvqn.fsf@latte.josefsson.org>
	<B288BDCCFC5B874BBC7D22117EDFB6F9010B39E19415@NSPEXMBX-C.the-lab.llnl.gov>
Message-ID: <4EA1BE3C.6010309@gnutls.org>

On 10/21/2011 08:14 PM, Hoyt, David wrote:
>> You should have a sys/socket.h in the GnuTLS build tree somewhere, from
>> gnulib.  Some -I's are missing, I've pushed this patch:
>
> Thank you very much! Those patches helped push through a bit further. I grabbed the latest from git, but I still had to make another adjustment to "lib/accelerated/x86/Makefile.am" -- similar to your patch, I had to add "-I$(builddir)/../../../gl" to AM_CPPFLAGS. If it isn't obvious by now, I'm trying to compile from a separate build directory than my source (as is the typical recommendation).
>> Please try building from git, or try next release.
> Configure proceeded fine, but then during the build, I got the following errors (and a whole lot more exactly like it, just on different lines):
> gnutls-3.0.4-git/lib/accelerated/x86/asm/appro-aes-x86.s: Assembler messages:
> gnutls-3.0.4-git/lib/accelerated/x86/asm/appro-aes-x86.s:41: Warning: .type pseudo-op used outside of .def/.endef ignored.
> gnutls-3.0.4-git/lib/accelerated/x86/asm/appro-aes-x86.s:41: Error: junk at end of line, first unrecognized character is `a'
> gnutls-3.0.4-git/lib/accelerated/x86/asm/appro-aes-x86.s:63: Warning: .size pseudo-op used outside of .def/.endef ignored.
> gnutls-3.0.4-git/lib/accelerated/x86/asm/appro-aes-x86.s:63: Error: junk at end of line, first unrecognized character is `a'

What is the assembler version used? If you don't need AES-NI or padlock 
acceleration you can use the "--disable-hardware-acceleration" to 
configure to avoid that.

regards,
Nikos



From hoyt6 at llnl.gov  Fri Oct 21 21:27:16 2011
From: hoyt6 at llnl.gov (Hoyt, David)
Date: Fri, 21 Oct 2011 12:27:16 -0700
Subject: gnutls 3.0.4 and mingw-w64 build issues
In-Reply-To: <4EA1BE3C.6010309@gnutls.org>
References: <B288BDCCFC5B874BBC7D22117EDFB6F9010B335C76B5@NSPEXMBX-C.the-lab.llnl.gov>
	<87botamvqn.fsf@latte.josefsson.org>
	<B288BDCCFC5B874BBC7D22117EDFB6F9010B39E19415@NSPEXMBX-C.the-lab.llnl.gov>
	<4EA1BE3C.6010309@gnutls.org>
Message-ID: <B288BDCCFC5B874BBC7D22117EDFB6F9010B39E19437@NSPEXMBX-C.the-lab.llnl.gov>

> What is the assembler version used?

GNU assembler (GNU Binutils) 2.20.51.20100928
Copyright 2010 Free Software Foundation, Inc.
...
This assembler was configured for a target of `i686-w64-mingw32'.

> If you don't need AES-NI or padlock 
> acceleration you can use the "--disable-hardware-acceleration" to 
> configure to avoid that.

I'm building a general-purpose lib, so it'd be nice to take advantage of optimizations if I can, even if I don't directly use them myself.

Building with "--disable-hardware-acceleration" results in some more build issues. I had to additionally modify the following files:

lib/accelerated/Makefile.am: added "-I$(builddir)/../../gl \" to AM_CPPFLAGS
lib/auth/Makefile.am: added "-I$(builddir)/../../gl \" to AM_CPPFLAGS
lib/ext/Makefile.am: added "-I$(builddir)/../../gl \" to AM_CPPFLAGS
lib/algorithms/Makefile.am: added "-I$(builddir)/../../gl \" to AM_CPPFLAGS
lib/opencdk/Makefile.am: added "-I$(builddir)/../../gl \" to AM_CPPFLAGS
lib/openpgp/Makefile.am: added "-I$(builddir)/../../gl \" to AM_CPPFLAGS
lib/nettle/Makefile.am: added "-I$(builddir)/../../gl \" to AM_CPPFLAGS
lib/minitasn1/Makefile.am: added "-I$(builddir)/../../gl \" to AM_CPPFLAGS

I'm sure you can start to see a pattern emerging. :D

At this point, I'm still getting the following error:


make[3]: Entering directory `/home/hoyt6/native/build/gnutls-3.0.4-git/lib'
  CC     gnutls_record.lo
In file included from ../../../pkgs/gnutls-3.0.4-git/lib/gnutls_record.c:27:0:
../../../pkgs/gnutls-3.0.4-git/lib/gnutls_int.h:65:27: fatal error: gnutls/gnutls.h: No such file or directory
compilation terminated.


Your continued help is appreciated. (c:

Thanks,
- David Hoyt



From hoyt6 at llnl.gov  Fri Oct 21 22:11:02 2011
From: hoyt6 at llnl.gov (Hoyt, David)
Date: Fri, 21 Oct 2011 13:11:02 -0700
Subject: gnutls 3.0.4 and mingw-w64 build issues
In-Reply-To: <B288BDCCFC5B874BBC7D22117EDFB6F9010B39E19437@NSPEXMBX-C.the-lab.llnl.gov>
References: <B288BDCCFC5B874BBC7D22117EDFB6F9010B335C76B5@NSPEXMBX-C.the-lab.llnl.gov>
	<87botamvqn.fsf@latte.josefsson.org>
	<B288BDCCFC5B874BBC7D22117EDFB6F9010B39E19415@NSPEXMBX-C.the-lab.llnl.gov>
	<4EA1BE3C.6010309@gnutls.org>
	<B288BDCCFC5B874BBC7D22117EDFB6F9010B39E19437@NSPEXMBX-C.the-lab.llnl.gov>
Message-ID: <B288BDCCFC5B874BBC7D22117EDFB6F9010B39E1945C@NSPEXMBX-C.the-lab.llnl.gov>

> At this point, I'm still getting the following error:
> [...]
>

Again, I modified the following files:


lib/Makefile.am: added "-I$(builddir)/includes \" to AM_CPPFLAGS
lib/Makefile.am: added "-I$(builddir)/includes" to AM_CXXFLAGS


You'll likely need to make more of these kinds of changes depending on configure options. I attached a patch with all my makefile.am changes so far (against origin). I am now getting the following:

make[3]: Entering directory `/home/hoyt6/native/build/gnutls-3.0.4-git/lib'
  CC     gnutls_record.lo
  CC     gnutls_compress.lo
  [...]
  CC     gnutls_psk.lo
  CXX    libgnutlsxx_la-gnutlsxx.lo
make[3]: *** No rule to make target `libgnutls-28.def', needed by `all-am'.  Stop.


Thanks,
- David Hoyt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix_build.patch
Type: application/octet-stream
Size: 4709 bytes
Desc: fix_build.patch
URL: </pipermail/attachments/20111021/f9af1a1d/attachment.obj>

From nmav at gnutls.org  Fri Oct 21 22:14:10 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 21 Oct 2011 22:14:10 +0200
Subject: gnutls 3.0.4 and mingw-w64 build issues
In-Reply-To: <B288BDCCFC5B874BBC7D22117EDFB6F9010B39E19437@NSPEXMBX-C.the-lab.llnl.gov>
References: <B288BDCCFC5B874BBC7D22117EDFB6F9010B335C76B5@NSPEXMBX-C.the-lab.llnl.gov>	<87botamvqn.fsf@latte.josefsson.org>
	<B288BDCCFC5B874BBC7D22117EDFB6F9010B39E19415@NSPEXMBX-C.the-lab.llnl.gov>
	<4EA1BE3C.6010309@gnutls.org>
	<B288BDCCFC5B874BBC7D22117EDFB6F9010B39E19437@NSPEXMBX-C.the-lab.llnl.gov>
Message-ID: <4EA1D292.4070108@gnutls.org>

On 10/21/2011 09:27 PM, Hoyt, David wrote:
>> What is the assembler version used?
>
> GNU assembler (GNU Binutils) 2.20.51.20100928
> Copyright 2010 Free Software Foundation, Inc.
> ...
> This assembler was configured for a target of `i686-w64-mingw32'.

Ah ok... Because it is cross build the detection didn't work properly 
and you were trying to compile the 32-bit version of the files. Can you 
try the --host x86_64 configure option?

> lib/accelerated/Makefile.am: added "-I$(builddir)/../../gl \" to AM_CPPFLAGS
> lib/auth/Makefile.am: added "-I$(builddir)/../../gl \" to AM_CPPFLAGS
> lib/ext/Makefile.am: added "-I$(builddir)/../../gl \" to AM_CPPFLAGS
> lib/algorithms/Makefile.am: added "-I$(builddir)/../../gl \" to AM_CPPFLAGS
> lib/opencdk/Makefile.am: added "-I$(builddir)/../../gl \" to AM_CPPFLAGS
> lib/openpgp/Makefile.am: added "-I$(builddir)/../../gl \" to AM_CPPFLAGS
> lib/nettle/Makefile.am: added "-I$(builddir)/../../gl \" to AM_CPPFLAGS
> lib/minitasn1/Makefile.am: added "-I$(builddir)/../../gl \" to AM_CPPFLAGS
> I'm sure you can start to see a pattern emerging. :D
> At this point, I'm still getting the following error:

Thanks. I've added them.
>
> make[3]: Entering directory `/home/hoyt6/native/build/gnutls-3.0.4-git/lib'
>    CC     gnutls_record.lo
> In file included from ../../../pkgs/gnutls-3.0.4-git/lib/gnutls_record.c:27:0:
> ../../../pkgs/gnutls-3.0.4-git/lib/gnutls_int.h:65:27: fatal error: gnutls/gnutls.h: No such file or directory
> compilation terminated.

I've added more -Ibuilddir stuff. I wonder why srcdir is not enough in 
this build.

regards,
Nikos



From hoyt6 at llnl.gov  Fri Oct 21 22:23:12 2011
From: hoyt6 at llnl.gov (Hoyt, David)
Date: Fri, 21 Oct 2011 13:23:12 -0700
Subject: gnutls 3.0.4 and mingw-w64 build issues
In-Reply-To: <B288BDCCFC5B874BBC7D22117EDFB6F9010B39E1945C@NSPEXMBX-C.the-lab.llnl.gov>
References: <B288BDCCFC5B874BBC7D22117EDFB6F9010B335C76B5@NSPEXMBX-C.the-lab.llnl.gov>
	<87botamvqn.fsf@latte.josefsson.org>
	<B288BDCCFC5B874BBC7D22117EDFB6F9010B39E19415@NSPEXMBX-C.the-lab.llnl.gov>
	<4EA1BE3C.6010309@gnutls.org>
	<B288BDCCFC5B874BBC7D22117EDFB6F9010B39E19437@NSPEXMBX-C.the-lab.llnl.gov>
	<B288BDCCFC5B874BBC7D22117EDFB6F9010B39E1945C@NSPEXMBX-C.the-lab.llnl.gov>
Message-ID: <B288BDCCFC5B874BBC7D22117EDFB6F9010B39E19466@NSPEXMBX-C.the-lab.llnl.gov>

> make[3]: *** No rule to make target `libgnutls-28.def', needed by `all-am'.  Stop.

Re-running make without parallel builds (I was doing "make -j3") seemed to resolve this problem. Still might want to check what's going on, though.

Had to make similar Makefile.am fixes in the following (on top of my previous patch):

extra/Makefile.am: added "-I$(builddir)/../gl \" to AM_CPPFLAGS

Now getting the following error:

make[3]: Entering directory `~/native/build/gnutls-3.0.4-git/extra'
  CC     gnutls_openssl.lo
  CC     openssl_compat.lo
In file included from ../../../pkgs/gnutls-3.0.4-git/extra/openssl_compat.h:30:0,
                 from ../../../pkgs/gnutls-3.0.4-git/extra/openssl_compat.c:36:
../../../pkgs/gnutls-3.0.4-git/extra/includes/gnutls/openssl.h:95:26: error: expected ')' before numeric constant
../../../pkgs/gnutls-3.0.4-git/extra/includes/gnutls/openssl.h:283:3: error: expected identifier or '(' before 'LPCSTR'
../../../pkgs/gnutls-3.0.4-git/extra/includes/gnutls/openssl.h:283:3: error: expected ')' before numeric constant
../../../pkgs/gnutls-3.0.4-git/extra/includes/gnutls/openssl.h:284:3: error: expected identifier or '(' before 'LPCSTR'
../../../pkgs/gnutls-3.0.4-git/extra/includes/gnutls/openssl.h:284:3: error: expected ')' before numeric constant
make[3]: *** [openssl_compat.lo] Error 1





From hoyt6 at llnl.gov  Fri Oct 21 22:47:08 2011
From: hoyt6 at llnl.gov (Hoyt, David)
Date: Fri, 21 Oct 2011 13:47:08 -0700
Subject: gnutls 3.0.4 and mingw-w64 build issues
In-Reply-To: <4EA1D292.4070108@gnutls.org>
References: <B288BDCCFC5B874BBC7D22117EDFB6F9010B335C76B5@NSPEXMBX-C.the-lab.llnl.gov>
	<87botamvqn.fsf@latte.josefsson.org>
	<B288BDCCFC5B874BBC7D22117EDFB6F9010B39E19415@NSPEXMBX-C.the-lab.llnl.gov>
	<4EA1BE3C.6010309@gnutls.org>
	<B288BDCCFC5B874BBC7D22117EDFB6F9010B39E19437@NSPEXMBX-C.the-lab.llnl.gov>
	<4EA1D292.4070108@gnutls.org>
Message-ID: <B288BDCCFC5B874BBC7D22117EDFB6F9010B39E19477@NSPEXMBX-C.the-lab.llnl.gov>

> Ah ok... Because it is cross build the detection didn't work properly 
> and you were trying to compile the 32-bit version of the files. Can you 
> try the --host x86_64 configure option?

It's sort of a cross build. It's a 64-bit host OS, but I'm running all the build tools in 32-bit mode (Windows-on-Windows, WOW), so everything should appear to be 32-bit and there shouldn't be any distinction.

I'll retry with the --host option, however, as soon as possible and let you know the results.

With what I had, configure gives me the following output:

 version:          3.0.4 shared 30:0:2
 Host type:        i686-pc-mingw32
 Install prefix:   ~/native/staging
 Compiler:         gcc -mtune=i686 -mthreads -std=gnu99
 [...]

Host type *should* be, I believe, "i686-w64-mingw32" and that may be what's leading to the problems I'm seeing w/ the assembly.

> I've added more -Ibuilddir stuff. I wonder why srcdir is not enough in 
> this build.

I believe it's because I don't build inside the source directory and gnulib generates some headers, but they're generated in the build dir and not the source dir (which sounds correct to me).




From hoyt6 at llnl.gov  Sat Oct 22 01:46:11 2011
From: hoyt6 at llnl.gov (Hoyt, David)
Date: Fri, 21 Oct 2011 16:46:11 -0700
Subject: gnutls 3.0.4 and mingw-w64 build issues
In-Reply-To: <B288BDCCFC5B874BBC7D22117EDFB6F9010B39E19466@NSPEXMBX-C.the-lab.llnl.gov>
References: <B288BDCCFC5B874BBC7D22117EDFB6F9010B335C76B5@NSPEXMBX-C.the-lab.llnl.gov>
	<87botamvqn.fsf@latte.josefsson.org>
	<B288BDCCFC5B874BBC7D22117EDFB6F9010B39E19415@NSPEXMBX-C.the-lab.llnl.gov>
	<4EA1BE3C.6010309@gnutls.org>
	<B288BDCCFC5B874BBC7D22117EDFB6F9010B39E19437@NSPEXMBX-C.the-lab.llnl.gov>
	<B288BDCCFC5B874BBC7D22117EDFB6F9010B39E1945C@NSPEXMBX-C.the-lab.llnl.gov>
	<B288BDCCFC5B874BBC7D22117EDFB6F9010B39E19466@NSPEXMBX-C.the-lab.llnl.gov>
Message-ID: <B288BDCCFC5B874BBC7D22117EDFB6F9010B39E194E4@NSPEXMBX-C.the-lab.llnl.gov>

> ../../../pkgs/gnutls-3.0.4-git/extra/includes/gnutls/openssl.h:95:26: error: expected ')' before numeric constant

I've attached all my patches so far dealing with Makefile.am build issues. These also resolve the above problem. 

There are several more issues, however, when compiling gnutls-server -- headers being included that don't exist with mingw-w64. e.g.:

src/common.h: <netinet/ip.h> doesn't exist (guard with _WIN32 or something looking for MinGW?)
src/certtool-cfg.c: <arpa/inet.h> doesn't exist (guard?)
src/serv.c: <sys/select.h> doesn't exist (guard?)
src/udp-serv.c: <arpa/inet.h> doesn't exist (guard?)

Guarding them and compiling results in a slew of errors. My patch does not include those guards b/c I was unsure what the best course of action is. At any rate, here are the errors I get when guarding them with #ifndef _WIN32:

  CC     libcmd_certtool_la-certtool-cfg.lo
../../../pkgs/gnutls-3.0.4-git/src/certtool-cfg.c: In function 'string_to_ip':
../../../pkgs/gnutls-3.0.4-git/src/certtool-cfg.c:831:7: warning: implicit declaration of function 'inet_pton'
  CCLD   libcmd-certtool.la
copying selected object files to avoid basename conflicts...
  CC     serv.o
../../../pkgs/gnutls-3.0.4-git/src/serv.c: In function 'listener_free':
../../../pkgs/gnutls-3.0.4-git/src/serv.c:156:7: warning: implicit declaration of function 'shutdown_used_without_requesting_gnulib_module_shutdown'
../../../pkgs/gnutls-3.0.4-git/src/serv.c:157:7: warning: implicit declaration of function 'close_used_without_including_unistd_h'
../../../pkgs/gnutls-3.0.4-git/src/serv.c: In function 'wait_for_connection':
../../../pkgs/gnutls-3.0.4-git/src/serv.c:661:3: warning: implicit declaration of function 'select_used_without_including_sys_select_h'
../../../pkgs/gnutls-3.0.4-git/src/serv.c: In function 'listen_socket':
../../../pkgs/gnutls-3.0.4-git/src/serv.c:719:7: warning: implicit declaration of function 'socket_used_without_requesting_gnulib_module_socket'
../../../pkgs/gnutls-3.0.4-git/src/serv.c:729:11: warning: implicit declaration of function 'setsockopt_used_without_requesting_gnulib_module_setsockopt'
../../../pkgs/gnutls-3.0.4-git/src/serv.c:749:7: warning: implicit declaration of function 'bind_used_without_requesting_gnulib_module_bind'
../../../pkgs/gnutls-3.0.4-git/src/serv.c:758:11: warning: implicit declaration of function 'listen_used_without_requesting_gnulib_module_listen'
../../../pkgs/gnutls-3.0.4-git/src/serv.c: In function 'tcp_server':
../../../pkgs/gnutls-3.0.4-git/src/serv.c:1213:13: warning: implicit declaration of function 'accept_used_without_requesting_gnulib_module_accept'
  CC     udp-serv.o
../../../pkgs/gnutls-3.0.4-git/src/udp-serv.c: In function 'udp_server':
../../../pkgs/gnutls-3.0.4-git/src/udp-serv.c:82:9: warning: implicit declaration of function 'recvfrom_used_without_requesting_gnulib_module_recvfrom'
../../../pkgs/gnutls-3.0.4-git/src/udp-serv.c: In function 'pull_timeout_func':
../../../pkgs/gnutls-3.0.4-git/src/udp-serv.c:189:3: warning: implicit declaration of function 'select_used_without_including_sys_select_h'
../../../pkgs/gnutls-3.0.4-git/src/udp-serv.c: In function 'push_func':
../../../pkgs/gnutls-3.0.4-git/src/udp-serv.c:212:3: warning: implicit declaration of function 'sendto_used_without_requesting_gnulib_module_sendto'
  CC     common.o
  CCLD   gnutls-serv.exe
serv.o:serv.c:(.text+0xd6): undefined reference to `shutdown_used_without_requesting_gnulib_module_shutdown'
serv.o:serv.c:(.text+0xe4): undefined reference to `close_used_without_including_unistd_h'
serv.o:serv.c:(.text+0x11f1): undefined reference to `select_used_without_including_sys_select_h'
serv.o:serv.c:(.text+0x13ca): undefined reference to `socket_used_without_requesting_gnulib_module_socket'
serv.o:serv.c:(.text+0x141b): undefined reference to `setsockopt_used_without_requesting_gnulib_module_setsockopt'
serv.o:serv.c:(.text+0x1436): undefined reference to `close_used_without_including_unistd_h'
serv.o:serv.c:(.text+0x145a): undefined reference to `bind_used_without_requesting_gnulib_module_bind'
serv.o:serv.c:(.text+0x1475): undefined reference to `close_used_without_including_unistd_h'
serv.o:serv.c:(.text+0x1493): undefined reference to `listen_used_without_requesting_gnulib_module_listen'
serv.o:serv.c:(.text+0x23df): undefined reference to `select_used_without_including_sys_select_h'
serv.o:serv.c:(.text+0x24b8): undefined reference to `accept_used_without_requesting_gnulib_module_accept'
udp-serv.o:udp-serv.c:(.text+0x10d): undefined reference to `recvfrom_used_without_requesting_gnulib_module_recvfrom'
udp-serv.o:udp-serv.c:(.text+0x259): undefined reference to `recvfrom_used_without_requesting_gnulib_module_recvfrom'
udp-serv.o:udp-serv.c:(.text+0x609): undefined reference to `select_used_without_including_sys_select_h'
udp-serv.o:udp-serv.c:(.text+0x660): undefined reference to `recvfrom_used_without_requesting_gnulib_module_recvfrom'
udp-serv.o:udp-serv.c:(.text+0x6ef): undefined reference to `sendto_used_without_requesting_gnulib_module_sendto'
udp-serv.o:udp-serv.c:(.text+0x739): undefined reference to `recvfrom_used_without_requesting_gnulib_module_recvfrom'
collect2: ld returned 1 exit status


-------------- next part --------------
A non-text attachment was scrubbed...
Name: build_fixes.patch
Type: application/octet-stream
Size: 5799 bytes
Desc: build_fixes.patch
URL: </pipermail/attachments/20111021/037718f7/attachment.obj>

From hoyt6 at llnl.gov  Sat Oct 22 01:57:00 2011
From: hoyt6 at llnl.gov (Hoyt, David)
Date: Fri, 21 Oct 2011 16:57:00 -0700
Subject: gnutls 3.0.4 and mingw-w64 build issues
In-Reply-To: <B288BDCCFC5B874BBC7D22117EDFB6F9010B39E194E4@NSPEXMBX-C.the-lab.llnl.gov>
References: <B288BDCCFC5B874BBC7D22117EDFB6F9010B335C76B5@NSPEXMBX-C.the-lab.llnl.gov>
	<87botamvqn.fsf@latte.josefsson.org>
	<B288BDCCFC5B874BBC7D22117EDFB6F9010B39E19415@NSPEXMBX-C.the-lab.llnl.gov>
	<4EA1BE3C.6010309@gnutls.org>
	<B288BDCCFC5B874BBC7D22117EDFB6F9010B39E19437@NSPEXMBX-C.the-lab.llnl.gov>
	<B288BDCCFC5B874BBC7D22117EDFB6F9010B39E1945C@NSPEXMBX-C.the-lab.llnl.gov>
	<B288BDCCFC5B874BBC7D22117EDFB6F9010B39E19466@NSPEXMBX-C.the-lab.llnl.gov>
	<B288BDCCFC5B874BBC7D22117EDFB6F9010B39E194E4@NSPEXMBX-C.the-lab.llnl.gov>
Message-ID: <B288BDCCFC5B874BBC7D22117EDFB6F9010B39E194EE@NSPEXMBX-C.the-lab.llnl.gov>

> [...] headers being included that don't exist with mingw-w64. e.g.:

gnulib does provide the following:

sys/select.h: http://www.gnu.org/s/hello/manual/gnulib/sys_002fselect_002eh.html
arpa/inet.h: http://www.gnu.org/s/hello/manual/gnulib/arpa_002finet_002eh.html

You can see that mingw and mingw-w64 don't provide those headers. Not sure what to do about netinet/ip.h, though.




From nmav at gnutls.org  Sat Oct 22 11:13:58 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 22 Oct 2011 11:13:58 +0200
Subject: gnutls 3.0.4 and mingw-w64 build issues
In-Reply-To: <B288BDCCFC5B874BBC7D22117EDFB6F9010B39E194E4@NSPEXMBX-C.the-lab.llnl.gov>
References: <B288BDCCFC5B874BBC7D22117EDFB6F9010B335C76B5@NSPEXMBX-C.the-lab.llnl.gov>
	<87botamvqn.fsf@latte.josefsson.org>
	<B288BDCCFC5B874BBC7D22117EDFB6F9010B39E19415@NSPEXMBX-C.the-lab.llnl.gov>
	<4EA1BE3C.6010309@gnutls.org>
	<B288BDCCFC5B874BBC7D22117EDFB6F9010B39E19437@NSPEXMBX-C.the-lab.llnl.gov>
	<B288BDCCFC5B874BBC7D22117EDFB6F9010B39E1945C@NSPEXMBX-C.the-lab.llnl.gov>
	<B288BDCCFC5B874BBC7D22117EDFB6F9010B39E19466@NSPEXMBX-C.the-lab.llnl.gov>
	<B288BDCCFC5B874BBC7D22117EDFB6F9010B39E194E4@NSPEXMBX-C.the-lab.llnl.gov>
Message-ID: <CAJU7za+RmcynjqxzJLvYabeh2dQF7Z4egcMHckLtsrcnihgvSg@mail.gmail.com>

On Sat, Oct 22, 2011 at 1:46 AM, Hoyt, David <hoyt6 at llnl.gov> wrote:
>> ../../../pkgs/gnutls-3.0.4-git/extra/includes/gnutls/openssl.h:95:26: error: expected ')' before numeric constant
>
> I've attached all my patches so far dealing with Makefile.am build issues. These also resolve the above problem.
>
> There are several more issues, however, when compiling gnutls-server -- headers being included that don't exist with mingw-w64. e.g.:

I have updated gnulib. Could you check again?

regards,
Nikos



From nmav at gnutls.org  Sat Oct 22 11:24:25 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 22 Oct 2011 11:24:25 +0200
Subject: gnutls 3.0.4 and mingw-w64 build issues
In-Reply-To: <B288BDCCFC5B874BBC7D22117EDFB6F9010B39E19477@NSPEXMBX-C.the-lab.llnl.gov>
References: <B288BDCCFC5B874BBC7D22117EDFB6F9010B335C76B5@NSPEXMBX-C.the-lab.llnl.gov>	<87botamvqn.fsf@latte.josefsson.org>
	<B288BDCCFC5B874BBC7D22117EDFB6F9010B39E19415@NSPEXMBX-C.the-lab.llnl.gov>
	<4EA1BE3C.6010309@gnutls.org>
	<B288BDCCFC5B874BBC7D22117EDFB6F9010B39E19437@NSPEXMBX-C.the-lab.llnl.gov>
	<4EA1D292.4070108@gnutls.org>
	<B288BDCCFC5B874BBC7D22117EDFB6F9010B39E19477@NSPEXMBX-C.the-lab.llnl.gov>
Message-ID: <4EA28BC9.8070402@gnutls.org>

On 10/21/2011 10:47 PM, Hoyt, David wrote:
>> Ah ok... Because it is cross build the detection didn't work properly
>> and you were trying to compile the 32-bit version of the files. Can you
>> try the --host x86_64 configure option?
>
> It's sort of a cross build. It's a 64-bit host OS, but I'm running all the build tools in 32-bit mode (Windows-on-Windows, WOW), so everything should appear to be 32-bit and there shouldn't be any distinction.

Ok it seems you have to use disable-hardware-optimizations. Windows uses 
coff format which requires a different assembly file. I'll check on it soon.

regards,
Nikos




From nmav at gnutls.org  Tue Oct 25 19:40:43 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 25 Oct 2011 19:40:43 +0200
Subject: gnutls 3.0.4 and mingw-w64 build issues
In-Reply-To: <4EA28BC9.8070402@gnutls.org>
References: <B288BDCCFC5B874BBC7D22117EDFB6F9010B335C76B5@NSPEXMBX-C.the-lab.llnl.gov>
	<87botamvqn.fsf@latte.josefsson.org>
	<B288BDCCFC5B874BBC7D22117EDFB6F9010B39E19415@NSPEXMBX-C.the-lab.llnl.gov>
	<4EA1BE3C.6010309@gnutls.org>
	<B288BDCCFC5B874BBC7D22117EDFB6F9010B39E19437@NSPEXMBX-C.the-lab.llnl.gov>
	<4EA1D292.4070108@gnutls.org>
	<B288BDCCFC5B874BBC7D22117EDFB6F9010B39E19477@NSPEXMBX-C.the-lab.llnl.gov>
	<4EA28BC9.8070402@gnutls.org>
Message-ID: <CAJU7zaL-nP9G5CHOcRGdA0bfVYHyBiYYY14BmS9GbguOK2Y7xA@mail.gmail.com>

On Sat, Oct 22, 2011 at 11:24 AM, Nikos Mavrogiannopoulos
<nmav at gnutls.org> wrote:

>> It's sort of a cross build. It's a 64-bit host OS, but I'm running all the
>> build tools in 32-bit mode (Windows-on-Windows, WOW), so everything should
>> appear to be 32-bit and there shouldn't be any distinction.
> Ok it seems you have to use disable-hardware-optimizations. Windows uses
> coff format which requires a different assembly file. I'll check on it soon.

Hi,
 I've added COFF assembly files in the git master. Could you try them?

regards,
Nikos



From hoyt6 at llnl.gov  Tue Oct 25 21:40:57 2011
From: hoyt6 at llnl.gov (Hoyt, David)
Date: Tue, 25 Oct 2011 12:40:57 -0700
Subject: gnutls 3.0.4 and mingw-w64 build issues
In-Reply-To: <CAJU7zaL-nP9G5CHOcRGdA0bfVYHyBiYYY14BmS9GbguOK2Y7xA@mail.gmail.com>
References: <B288BDCCFC5B874BBC7D22117EDFB6F9010B335C76B5@NSPEXMBX-C.the-lab.llnl.gov>
	<87botamvqn.fsf@latte.josefsson.org>
	<B288BDCCFC5B874BBC7D22117EDFB6F9010B39E19415@NSPEXMBX-C.the-lab.llnl.gov>
	<4EA1BE3C.6010309@gnutls.org>
	<B288BDCCFC5B874BBC7D22117EDFB6F9010B39E19437@NSPEXMBX-C.the-lab.llnl.gov>
	<4EA1D292.4070108@gnutls.org>
	<B288BDCCFC5B874BBC7D22117EDFB6F9010B39E19477@NSPEXMBX-C.the-lab.llnl.gov>
	<4EA28BC9.8070402@gnutls.org>
	<CAJU7zaL-nP9G5CHOcRGdA0bfVYHyBiYYY14BmS9GbguOK2Y7xA@mail.gmail.com>
Message-ID: <B288BDCCFC5B874BBC7D22117EDFB6F9010B39E199F2@NSPEXMBX-C.the-lab.llnl.gov>

> I've added COFF assembly files in the git master. Could you try them?

Build went much smoother w/ hardware optimizations. However, it looks like there's a lingering linker issue. I got the following error:


  [...]

  CC     gnutls_srp.lo
  CC     gnutls_psk.lo
  CCLD   libgnutls.la
Creating library file: .libs/libgnutls.dll.a
accelerated/.libs/libaccelerated.a(accelerated.o): In function `gnutls_register_accel_crypto':
~\native\build\gnutls-3.0.4-git\lib\accelerated/../../../../pkgs/gnutls-3.0.4-git/lib/accelerated/accelerated.c:33: undefined reference to `_gnutls_have_cpuid'
accelerated/.libs/libaccelerated.a(aes-padlock.o): In function `check_via':
~\native\build\gnutls-3.0.4-git\lib\accelerated\x86/../../../../../pkgs/gnutls-3.0.4-git/lib/accelerated/x86/aes-padlock.c:217: undefined reference to `_gnutls_cpuid'
accelerated/.libs/libaccelerated.a(aes-x86.o): In function `check_intel_or_amd':
~\native\build\gnutls-3.0.4-git\lib\accelerated\x86/../../../../../pkgs/gnutls-3.0.4-git/lib/accelerated/x86/aes-x86.c:149: undefined reference to `_gnutls_cpuid'
accelerated/.libs/libaccelerated.a(aes-x86.o): In function `check_optimized_aes':
~\native\build\gnutls-3.0.4-git\lib\accelerated\x86/../../../../../pkgs/gnutls-3.0.4-git/lib/accelerated/x86/aes-x86.c:129: undefined reference to `_gnutls_cpuid'
collect2: ld returned 1 exit status
make[3]: *** [libgnutls.la] Error 1
make[3]: Leaving directory `/home/hoyt/native/build/gnutls-3.0.4-git/lib'

  [...]


My configure looks like:

lt_cv_deplibs_check_method=pass_all CC="gcc -mtune=i686 -mthreads" LDFLAGS="-Wl,--enable-auto-image-base" ../../pkgs/gnutls-3.0.4-git/configure --prefix=/home/hoyt6/native/staging --disable-guile --disable-cxx --disable-openssl-compatibility

From nmav at gnutls.org  Thu Oct 27 20:48:17 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 27 Oct 2011 20:48:17 +0200
Subject: gnutls 3.0.5
Message-ID: <4EA9A771.7060203@gnutls.org>

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

The changelog since 3.0.4 follows.

* Version 3.0.5 (released 2011-10-27)

** libgnutls-extra: is no more

** libgnutls: Corrections in order to compile with mingw32.

** libgnutls: Corrections in VIA padlock code for VIA C5 processor
and new detection of PHE with support for partial hashing.

** libgnutls: Corrected bug in gnutls_x509_data2hex. Report and fix
by Vincent Untz.

** minitasn1: Upgraded to libtasn1 version 2.10.

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


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

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

Here are the XZ compressed sources:

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

Here are OpenPGP detached signatures signed using key 0x96865171:

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

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

regards,
Nikos



From hoyt6 at llnl.gov  Fri Oct 28 01:19:10 2011
From: hoyt6 at llnl.gov (Hoyt, David)
Date: Thu, 27 Oct 2011 16:19:10 -0700
Subject: gnutls 3.0.5
In-Reply-To: <4EA9A771.7060203@gnutls.org>
References: <4EA9A771.7060203@gnutls.org>
Message-ID: <B288BDCCFC5B874BBC7D22117EDFB6F9010B3C4D006B@NSPEXMBX-C.the-lab.llnl.gov>

The latest release fails to build for me with mingw-w64 on a windows 7 machine with:

make[4]: Entering directory `~/native/build/gnutls-3.0.5/doc'
gcc -mtune=i686 -mthreads -std=gnu99 -g -O2 -I~/native/staging/include -Wl,--enable-auto-image-base  ../../../pkgs/gnutls-3.0.5/doc/printlist.c   -o printlist
../../../pkgs/gnutls-3.0.5/doc/printlist.c:21:20: fatal error: config.h: No such file or directory
compilation terminated.
make[4]: *** [printlist] Error 1
make[4]: Leaving directory `~/native/build/gnutls-3.0.5/doc'



From tzz at lifelogs.com  Fri Oct 28 22:12:45 2011
From: tzz at lifelogs.com (Ted Zlatanov)
Date: Fri, 28 Oct 2011 16:12:45 -0400
Subject: gnutls 3.0.5
References: <4EA9A771.7060203@gnutls.org>
Message-ID: <87r51wx4ci.fsf@lifelogs.com>

On Thu, 27 Oct 2011 20:48:17 +0200 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote: 

NM>  I've just released gnutls 3.0.5. It is a bug-fix release on the current
NM> stable branch.

Thanks, Nikos.  Simon Josefsson's Windows DLL builds haven't been
updated since 2.10.x (July 2010).  Can the GnuTLS project provide these
builds for 3.x or will Simon remain their provider?

The reason I ask is I'd like to start using 3.x in the Emacs project,
but don't want to leave all our Windows users out.

Thanks
Ted




From nmav at gnutls.org  Sat Oct 29 01:42:30 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 29 Oct 2011 01:42:30 +0200
Subject: gnutls 3.0.5
In-Reply-To: <87r51wx4ci.fsf@lifelogs.com>
References: <4EA9A771.7060203@gnutls.org>
	<87r51wx4ci.fsf@lifelogs.com>
Message-ID: <CAJU7za+iEdJfcUkArpt+ChPnSzK5oKq45jOpE1DWePjtPi=8Ow@mail.gmail.com>

2011/10/28 Ted Zlatanov <tzz at lifelogs.com>:

> NM> ?I've just released gnutls 3.0.5. It is a bug-fix release on the current
> NM> stable branch.
> Thanks, Nikos. ?Simon Josefsson's Windows DLL builds haven't been
> updated since 2.10.x (July 2010). ?Can the GnuTLS project provide these
> builds for 3.x or will Simon remain their provider?

I cannot provide win32 builds. If however there is someone who can
provide win32 builds for the releases, he's welcome to join us.

regards,
Nikos