From nmav at gnutls.org  Wed Dec  1 11:23:07 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 1 Dec 2010 11:23:07 +0100
Subject: [sr #107545] Patch: output.c
In-Reply-To: <20101126-092855.sv80862.71660@savannah.gnu.org>
References: <20101126-092855.sv80862.71660@savannah.gnu.org>
Message-ID: <AANLkTinwyUDi04h8BO+F1VRmCTmd8e5v65fV=S_wiqwV@mail.gmail.com>

Due to savanah issue you might want to resubmit your patches. It is
better if you don't use the bug tracker in savanah but rather send an
e-mail to the list with the patch. In the mail, just mention what your
patch does and why it should be applied :)

regards,
Nikos

On Fri, Nov 26, 2010 at 10:28 AM, Jeffrey Walton
<INVALID.NOREPLY at gnu.org> wrote:
>
> URL:
> ?<http://savannah.gnu.org/support/?107545>
>
> ? ? ? ? ? ? ? ? Summary: Patch: output.c
> ? ? ? ? ? ? ? ? Project: GnuTLS
> ? ? ? ? ? ?Submitted by: noloader
> ? ? ? ? ? ?Submitted on: Fri 26 Nov 2010 09:28:55 AM GMT
> ? ? ? ? ? ? ? ?Category: None
> ? ? ? ? ? ? ? ?Priority: 5 - Normal
> ? ? ? ? ? ? ? ?Severity: 2 - Minor
> ? ? ? ? ? ? ? ? ?Status: None
> ? ? ? ? ? ? ? ? Privacy: Public
> ? ? ? ? ? ? Assigned to: None
> ? ? ? ?Originator Email:
> ? ? ? ? ? ? Open/Closed: Open
> ? ? ? ? Discussion Lock: Any
> ? ? ? ?Operating System: GNU/Linux
>
> ? ?_______________________________________________________
>
> Details:
>
> * cleared 16 warnings
>
>
>
> ? ?_______________________________________________________
>
> File Attachments:
>
>
> -------------------------------------------------------
> Date: Fri 26 Nov 2010 09:28:55 AM GMT ?Name: output.patch ?Size: 7kB ? By:
> noloader
>
> <http://savannah.gnu.org/support/download.php?file_id=22126>
>
> ? ?_______________________________________________________
>
> Reply to this item at:
>
> ?<http://savannah.gnu.org/support/?107545>
>
> _______________________________________________
> ?Message sent via/by Savannah
> ?http://savannah.gnu.org/
>
>
> _______________________________________________
> Gnutls-devel mailing list
> Gnutls-devel at gnu.org
> http://lists.gnu.org/mailman/listinfo/gnutls-devel
>



From richard at centreos.nl  Wed Dec  1 11:38:22 2010
From: richard at centreos.nl (Richard Wardt van Duijvenbode)
Date: Wed, 01 Dec 2010 11:38:22 +0100
Subject: GnuTLS error -8: A record packet with illegal version was received.
Message-ID: <4CF6259E.7020800@centreos.nl>

Hi,
I got this bug for you guys:


-ChanServ- [#gnu] Welcome to #gnu, the official channel of the GNU Project. Please read and follow http://www.gnu.org/server/irc-rules.html.
* #gnu :http://www.gnu.org/
<Wardt> I got a "GnuTLS error -8: A record packet with illegal version was received." using FTPES. One account works, the other doesn't. Does anyone know what this is and what I can do to fix it?
<jmd> Wardt, First you should report it as a bug to the GnuTLS maintainers since that error message is in breach of the Gnu coding standards.


Furthermore, could you please tell me what the error message means and how I can fix this situation?

Thanks,

Wardt



*CENTREOS * E-commerce & Relatiebeheer

Bezoekadres: 	Tivolilaan 205, 6824 BV Arnhem
Postadres: 	Postbus 2, 6800 AA Arnhem
Telefoon: 	+31 26 8454570 <callto:031268454570>
Fax: 	+31 26 8454540
Website: 	www.centreos.nl <http://www.centreos.nl/>
Twitter: 	Centreos <http://www.twitter.com/Centreos>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20101201/0de090ee/attachment.htm>

From nmav at gnutls.org  Wed Dec  1 22:16:20 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 01 Dec 2010 22:16:20 +0100
Subject: (no subject)
In-Reply-To: <0C4556B6BAE1734A840FDF7EEE66C1A506FD8401@AUSMERIMX01.adom.ad.corp>
References: <0C4556B6BAE1734A840FDF7EEE66C1A506FA4AD1@AUSMERIMX01.adom.ad.corp>
	<4CF6AE72.4060400@gnutls.org>
	<0C4556B6BAE1734A840FDF7EEE66C1A506FD8401@AUSMERIMX01.adom.ad.corp>
Message-ID: <4CF6BB24.8070305@gnutls.org>

On 12/01/2010 09:23 PM, HOY Mike wrote:
> Hi Nikos,
> 
> I am using 2.10.2
Use the latest 2.10.3. It fixes a memory leak.

regards,
Nikos




From nmav at gnutls.org  Wed Dec  1 22:19:57 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 01 Dec 2010 22:19:57 +0100
Subject: GnuTLS error -8: A record packet with illegal version was
	received.
Message-ID: <4CF6BBFD.5050308@gnutls.org>

On 12/01/2010 11:38 AM, Richard Wardt van Duijvenbode wrote:
> Hi, I got this bug for you guys: -ChanServ- [#gnu] Welcome to #gnu,
> the official channel of the GNU Project. Please read and follow
> http://www.gnu.org/server/irc-rules.html. * #gnu
> :http://www.gnu.org/ <Wardt> I got a "GnuTLS error -8: A record
> packet with illegal version was received." using FTPES. One account
> works, the other doesn't. Does anyone know what this is and what I
> can do to fix it? <jmd> Wardt, First you should report it as a bug to
> the GnuTLS maintainers since that error message is in breach of the
> Gnu coding standards. Furthermore, could you please tell me what the
> error message means and how I can fix this situation?

This is not a bug. Gnutls is complaining because the peer's packet is
not correctly formatted. Most probably you are trying to use TLS on a
server that doesn't support it.

If you know that server supports TLS, then tell us how to reproduce this
situation.

regards,
Nikos



From nmav at gnutls.org  Wed Dec  1 22:53:37 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 01 Dec 2010 22:53:37 +0100
Subject: gnutls 2.11.5
Message-ID: <4CF6C3E1.6010904@gnutls.org>

Hello,

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

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

Unless there are issues, this version contains the final version of the
PKCS #11 support for 2.12.x. It has been mostly tested with opensc and
Feitian smart cards, but I'd appreciate if you can test it with other
tokens and pkcs11 modules you may have.

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

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

regards,
Nikos

* Version 2.11.5 (released 2010-12-01)

** libgnutls: Reverted default behavior for verification and
introduced GNUTLS_VERIFY_DO_NOT_ALLOW_X509_V1_CA_CRT. Thus by default
V1 trusted CAs are allowed, unless the new flag is specified.

** libgnutls: Correctly add leading zero to PKCS #8 encoded DSA key.
Reported by Jeffrey Walton.

** libgnutls: Added SIGN-ALL, CTYPE-ALL, COMP-ALL, and VERS-TLS-ALL
as priority strings. Those allow to set all the supported algorithms
at once.

** p11tool: Introduced. It allows manipulating pkcs 11 tokens.

** gnutls-cli: Print channel binding only in verbose mode.
Before it printed it after the 'Compression:' output, thus breaking
Emacs starttls.el string searches.

** API and ABI modifications:
gnutls_pkcs11_token_init: New function
gnutls_pkcs11_token_set_pin: New function



From richard at centreos.nl  Thu Dec  2 09:32:00 2010
From: richard at centreos.nl (Richard Wardt van Duijvenbode)
Date: Thu, 02 Dec 2010 09:32:00 +0100
Subject: GnuTLS error -8: A record packet with illegal version was
	received.
In-Reply-To: <4CF7554E.7000407@gnutls.org>
References: <4CF6BBFD.5050308@gnutls.org> <4CF74E20.8030907@centreos.nl>
	<4CF7554E.7000407@gnutls.org>
Message-ID: <4CF75980.307@centreos.nl>

Sorry for that. Didn't notice the CC there.

For the preferred error message format you can look over here:
http://www.gnu.org/prep/standards/standards.html#Errors

For further information regarding the error message format, you
can contact jmd. He came with this on the gnu irc server.

Any questions about the error itself can be directed to me.


Wardt


*CENTREOS * E-commerce & Relatiebeheer

Bezoekadres: 	Tivolilaan 205, 6824 BV Arnhem
Postadres: 	Postbus 2, 6800 AA Arnhem
Telefoon: 	+31 26 8454570 <callto:031268454570>
Fax: 	+31 26 8454540
Website: 	www.centreos.nl <http://www.centreos.nl/>
Twitter: 	Centreos <http://www.twitter.com/Centreos>


On 12/02/2010 09:14 AM, Nikos Mavrogiannopoulos wrote:
> On 12/02/2010 08:43 AM, Richard Wardt van Duijvenbode wrote:
>> Hi,
>>
>> The bug report was concerning the error message that is in breach of
>>  the Gnu coding standard. The connection problems are something
>> else.
> How can an error message be in breach of the gnu coding standard? If
> this is the case then let me know what is exactly the issue there (and
> keep the list CC please). Simply "is in breach of the gnu coding
> standard", does not mean anything to me.
>
> regards,
> Nikos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20101202/868d3349/attachment.htm>

From nmav at gnutls.org  Thu Dec  2 09:45:44 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 02 Dec 2010 09:45:44 +0100
Subject: GnuTLS error -8: A record packet with illegal version was
	received.
In-Reply-To: <4CF75980.307@centreos.nl>
References: <4CF6BBFD.5050308@gnutls.org> <4CF74E20.8030907@centreos.nl>
	<4CF7554E.7000407@gnutls.org> <4CF75980.307@centreos.nl>
Message-ID: <4CF75CB8.3050203@gnutls.org>

On 12/02/2010 09:32 AM, Richard Wardt van Duijvenbode wrote:
> Sorry for that. Didn't notice the CC there. For the preferred error 
> message format you can look over here: 
> http://www.gnu.org/prep/standards/standards.html#Errors For further 
> information regarding the error message format, you can contact jmd. 
> He came with this on the gnu irc server. Any questions about the 
> error itself can be directed to me.

gnutls is a library not application. We just report an error code to
the application and the application may convert it back to a string (as
it is done here), which explains the error code further. This is pretty
much different than the standard you mention. The application using
gnutls though may format the string as it likes.

Thus if the application has to conform to the gnu coding standards and
it doesn't you should file a bug report against this application.

regards,
Nikos



From tmraz at redhat.com  Thu Dec  2 15:24:31 2010
From: tmraz at redhat.com (Tomas Mraz)
Date: Thu, 02 Dec 2010 15:24:31 +0100
Subject: Buffer overflow in gnutls-serv http code
Message-ID: <1291299871.15535.68.camel@vespa.frost.loc>

The gnutls-serv uses fixed allocated buffer for the response which can
be pretty long if a client certificate is presented to it and the http
header is large. This causes buffer overflow and heap corruption which
then leads to random segfaults or aborts.

It was reported originally here:
https://bugzilla.redhat.com/show_bug.cgi?id=659259

The attached patch changes sprintf calls in peer_print_info() to
snprintf so the buffer is never overflowed.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gnutls-2.10.3-sprintf.patch
Type: text/x-patch
Size: 5328 bytes
Desc: not available
URL: </pipermail/attachments/20101202/0bd370e2/attachment.bin>

From richard at centreos.nl  Thu Dec  2 10:20:32 2010
From: richard at centreos.nl (Richard Wardt van Duijvenbode)
Date: Thu, 02 Dec 2010 10:20:32 +0100
Subject: GnuTLS error -8: A record packet with illegal version was
	received.
In-Reply-To: <4CF75CB8.3050203@gnutls.org>
References: <4CF6BBFD.5050308@gnutls.org> <4CF74E20.8030907@centreos.nl>
	<4CF7554E.7000407@gnutls.org> <4CF75980.307@centreos.nl>
	<4CF75CB8.3050203@gnutls.org>
Message-ID: <4CF764E0.6070002@centreos.nl>

Ok, that's clear. Thank you for that answer. Any thoughts
about the connection problems?


*CENTREOS * E-commerce & Relatiebeheer

Bezoekadres: 	Tivolilaan 205, 6824 BV Arnhem
Postadres: 	Postbus 2, 6800 AA Arnhem
Telefoon: 	+31 26 8454570 <callto:031268454570>
Fax: 	+31 26 8454540
Website: 	www.centreos.nl <http://www.centreos.nl/>
Twitter: 	Centreos <http://www.twitter.com/Centreos>


On 12/02/2010 09:45 AM, Nikos Mavrogiannopoulos wrote:
> On 12/02/2010 09:32 AM, Richard Wardt van Duijvenbode wrote:
>> Sorry for that. Didn't notice the CC there. For the preferred error 
>> message format you can look over here: 
>> http://www.gnu.org/prep/standards/standards.html#Errors For further 
>> information regarding the error message format, you can contact jmd. 
>> He came with this on the gnu irc server. Any questions about the 
>> error itself can be directed to me.
> gnutls is a library not application. We just report an error code to
> the application and the application may convert it back to a string (as
> it is done here), which explains the error code further. This is pretty
> much different than the standard you mention. The application using
> gnutls though may format the string as it likes.
>
> Thus if the application has to conform to the gnu coding standards and
> it doesn't you should file a bug report against this application.
>
> regards,
> Nikos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20101202/353673f9/attachment.htm>

From nmav at gnutls.org  Thu Dec  2 16:36:12 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 02 Dec 2010 16:36:12 +0100
Subject: GnuTLS error -8: A record packet with illegal version was
	received.
In-Reply-To: <4CF764E0.6070002@centreos.nl>
References: <4CF6BBFD.5050308@gnutls.org> <4CF74E20.8030907@centreos.nl>
	<4CF7554E.7000407@gnutls.org> <4CF75980.307@centreos.nl>
	<4CF75CB8.3050203@gnutls.org> <4CF764E0.6070002@centreos.nl>
Message-ID: <4CF7BCEC.4010500@gnutls.org>

On 12/02/2010 10:20 AM, Richard Wardt van Duijvenbode wrote:
> Ok, that's clear. Thank you for that answer. Any thoughts about the
> connection problems?

Check the first e-mail. Most probably you are talking to a server that
doesn't speak TLS.

regards,
Nikos



From Joshua.Davies at travelocity.com  Thu Dec  2 17:49:13 2010
From: Joshua.Davies at travelocity.com (Davies, Joshua)
Date: Thu, 2 Dec 2010 10:49:13 -0600
Subject: GnuTLS error -8: A record packet with illegal version was
	received.
In-Reply-To: <4CF7BCEC.4010500@gnutls.org>
References: <4CF6BBFD.5050308@gnutls.org> <4CF74E20.8030907@centreos.nl>
	<4CF7554E.7000407@gnutls.org> <4CF75980.307@centreos.nl>
	<4CF75CB8.3050203@gnutls.org> <4CF764E0.6070002@centreos.nl>
	<4CF7BCEC.4010500@gnutls.org>
Message-ID: <B3C2DDD8A76699489B5EC9DC7029D6F70A447E71AC@SGTULMMP004.Global.ad.sabre.com>

It might also be that the target server only understands SSLv2 (although I did a quick check on my machine using openssl & gnutls-cli, and the error message I get from gnutls-cli is slightly different than what Richard originally reported).

If you can capture the packets that are being exchanged (with tcpdump or ethereal, for instance), I could tell you for sure.

-----Original Message-----
From: gnutls-devel-bounces+joshua.davies=travelocity.com at gnu.org [mailto:gnutls-devel-bounces+joshua.davies=travelocity.com at gnu.org] On Behalf Of Nikos Mavrogiannopoulos
Sent: Thursday, December 02, 2010 9:36 AM
To: Richard Wardt van Duijvenbode
Cc: gnutls-devel at gnu.org
Subject: Re: GnuTLS error -8: A record packet with illegal version was received.

On 12/02/2010 10:20 AM, Richard Wardt van Duijvenbode wrote:
> Ok, that's clear. Thank you for that answer. Any thoughts about the
> connection problems?

Check the first e-mail. Most probably you are talking to a server that
doesn't speak TLS.

regards,
Nikos

_______________________________________________
Gnutls-devel mailing list
Gnutls-devel at gnu.org
http://lists.gnu.org/mailman/listinfo/gnutls-devel



From noloader at gmail.com  Thu Dec  2 20:31:15 2010
From: noloader at gmail.com (Jeffrey Walton)
Date: Thu, 2 Dec 2010 14:31:15 -0500
Subject: common.c and getpass.c and thread safety, zeroization
Message-ID: <AANLkTikbDc-AkNMK4QxaxYSRbzmBNO_5tM5=RwxMN7+o@mail.gmail.com>

The caching that is occurring -  via static data declaration - with
respect to passwords in common.c and getpass.c appears to leak
sensitive material. At minimum, routines are not following best
practices regarding sensitive data such as passwords and PINs.

For example, if a password is only needed once, its unclear how to
zeroize the memory in a static buffer from an invoked function after
its use. Its also unclear how to specify that sensitive material, such
as a password or PIN, *not* be cached.

In addition, a static buffer in used in getpass.c. getline(3) states
it will realloc if the required buffer for the password is too small.
How does GnuTLS zeroize the memory in calls to getpass.c when the
static buffer needs to grow? getline(3) makes no guarantees the data
will be sanitized.

Finally, the static buffers are not thread safe in its current
implementation. stdin and stout out might be serialized, but threads
which are concurrently executing routines such as getpass.c will leave
the shared buffer in an unknown state since the buffer might change
before the caller can copy out the correct [expected?] password.



From noloader at gmail.com  Thu Dec  2 21:34:47 2010
From: noloader at gmail.com (Jeffrey Walton)
Date: Thu, 2 Dec 2010 15:34:47 -0500
Subject: Savannah, SQL Injection, Passwords, and Security Posture
Message-ID: <AANLkTikKk=wjAJkom1gaX02u5R0YN2hGWJYKqqwvgSn+@mail.gmail.com>

Hi All,

According to http://savannah.gnu.org/, the server was down for a few
days due to a SQL Injection. Because the server did not properly
sanitize its data, the password database was compromised.

Today, I tried to change my  password to a similar password.
Surprisingly, the change was rejected because the password was too
similar. The "surprising" part is it appears GNU is storing passwords
in plain text.

I'm going out on the limb and guessing that free software stored the
passwords in the plain text. "Password Security: A Case History" by
Morris and Thompson was written in the 1970s. Sadly, GNU has totally
punned lessons learned in the past.

The GnuTLS project happily uses dangerous string function. Use of the
functions appears unaudited, suffering unchecked buffer overflows and
truncations. In fact, the project took a buffer overflow report today
due to a call to sprintf. Sadly, GNU has totally punned lessons
learned in the past (again).

Would someone be able to provide GNU's policy regarding application
security and proper use of cryptography in GNU projects. "GNU Coding
Standards" (http://www.gnu.org/prep/standards/standards.html) does not
address anything security related. I'm very interested in learning
about GNU's security posture.

Jeff



From INVALID.NOREPLY at gnu.org  Sat Dec  4 22:07:36 2010
From: INVALID.NOREPLY at gnu.org (Michael Rommel)
Date: Sat, 04 Dec 2010 21:07:36 +0000
Subject: [sr #107540] iPhone/iPad TLS negotiation to postfix fails with
	certtool certs, works with openssl certs
Message-ID: <20101204-210735.sv80996.83739@savannah.gnu.org>


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

                 Summary: iPhone/iPad TLS negotiation to postfix fails with
certtool certs, works with openssl certs
                 Project: GnuTLS
            Submitted by: mr2147
            Submitted on: Sat 04 Dec 2010 09:07:35 PM GMT
                Category: None
                Priority: 5 - Normal
                Severity: 2 - Minor
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
        Operating System: GNU/Linux

    _______________________________________________________

Details:

Setup:
iPhone/iPad shall send mails through TLS encrypted channel to postfix.
postfix is set up to authenticate clients either by username/password SASL or
by certificate authentication. Therefore postfix/main.cf includes:

# TLS parameters
smtpd_use_tls=yes
smtpd_tls_CAfile = /etc/ssl/gnutls/ca.pem
smtpd_tls_cert_file=/etc/ssl/gnutls/pelican.layer-7.net.pem
smtpd_tls_key_file=/etc/ssl/gnutls/pelican.layer-7.net.key
smtpd_tls_ask_ccert = yes
smtpd_tls_loglevel = 2
smtpd_tls_received_header = yes

The following files are generated by certtool: ca.key, ca.pem,
pelican.layer-7.net.key, pelican.layer-7.net.req

If the resulting pelican.layer-7.net.pem certificate is generated by
certtool:

/root/source/gnutls-2.10.3/src/certtool --generate-certificate 
--load-ca-privkey /etc/ssl/gnutls/ca.key --load-ca-certificate
/etc/ssl/gnutls/ca.pem --load-request /etc/ssl/gnutls/pelican.layer-7.net.req 
--outfile /etc/ssl/gnutls/pelican.layer-7.net.pem

the iPad receives ca.pem and pelican...pem and responds with an (possibly
invalid) answer, on which postfix chokes with:

Dec  4 20:56:11 pelican postfix/smtpd[7317]: connect from
parrot-wlan.layer-7.net[192.168.1.137]
Dec  4 20:56:11 pelican postfix/smtpd[7317]: setting up TLS connection from
parrot-wlan.layer-7.net[192.168.1.137]
Dec  4 20:56:11 pelican postfix/smtpd[7317]:
parrot-wlan.layer-7.net[192.168.1.137]: TLS cipher list
"ALL:+RC4:@STRENGTH:!aNULL"
Dec  4 20:56:11 pelican postfix/smtpd[7317]: SSL_accept:before/accept
initialization
Dec  4 20:56:11 pelican postfix/smtpd[7317]: SSL_accept:SSLv3 read client
hello B
Dec  4 20:56:11 pelican postfix/smtpd[7317]: SSL_accept:SSLv3 write server
hello A
Dec  4 20:56:11 pelican postfix/smtpd[7317]: SSL_accept:SSLv3 write
certificate A
Dec  4 20:56:11 pelican postfix/smtpd[7317]: SSL_accept:SSLv3 write
certificate request A
Dec  4 20:56:11 pelican postfix/smtpd[7317]: SSL_accept:SSLv3 flush data
Dec  4 20:56:11 pelican postfix/smtpd[7317]: SSL_accept:SSLv3 read client
certificate A
Dec  4 20:56:11 pelican postfix/smtpd[7317]: SSL_accept:SSLv3 read client key
exchange A
Dec  4 20:56:11 pelican postfix/smtpd[7317]: SSL3 alert write:fatal:bad
record mac
Dec  4 20:56:11 pelican postfix/smtpd[7317]: SSL_accept:error in SSLv3 read
certificate verify A
Dec  4 20:56:11 pelican postfix/smtpd[7317]: SSL_accept error from
parrot-wlan.layer-7.net[192.168.1.137]: -1
Dec  4 20:56:11 pelican postfix/smtpd[7317]: warning: TLS library problem:
7317:error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad
record mac:s3_pkt.c:422:
Dec  4 20:56:11 pelican postfix/smtpd[7317]: lost connection after STARTTLS
from parrot-wlan.layer-7.net[192.168.1.137]
Dec  4 20:56:11 pelican postfix/smtpd[7317]: disconnect from
parrot-wlan.layer-7.net[192.168.1.137]

The same setup with the certificate generated by openssl, using the same
ca.key, ca.pem, pelican...req using:

openssl ca -policy policy_anything -days 365 -in
gnutls/pelican.layer-7.net.req -out gnutls/pelican.layer-7.net.pem

works, so that the iPad displays the certificate for review and acceptance.

Leaving out the CAfile directive in postfix works in both cases, because the
initial server hello sends only the pelican...pem cert and not the ca.pem
cert. It must have something to do with the combination of the ca.pem and the
pelican.layer-7.net.pem. Sending a completely different ca.pem, which has not
signed the pelican...pem also works.

Using openssl s_client -starttls smtp ... works in both cases. openssl verify
could not find a flaw, too.

I couldn't identify the root cause - it possibly is iOS' fault, that it
generates an invalid response. But on the other hand, why does it work with
openssl generated certs. I have carefully reviewed both generated certs and
they look very similar. Digging down asn1parse I could only detect three
additional NULL values at positions 32, 365 and 606.

I'm at a loss here.

I am just posting it here, so that you are aware, that certtool generated
certs may cause trouble with Apple devices.

BTW: generating certs directly without the request step doesn't work too. In
fact I tried various combinations over the course of 7 hours, see table

                                   request file generated by
                        | certtool  |    openssl   |   certtool   |  openssl
|
  used CA     openssl   |   works   |     works    |     works    |   works 
|
generated by  certtool  |   fails   |     works    |     works    |   works 
|
                        |       certtool           |           openssl      
|
                                    certificate creation using

Attached are the pem and req files and the openssl ca definition.

Cheers,

  Michael.





 



    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Sat 04 Dec 2010 09:07:35 PM GMT  Name: gnutls_bugreport.tar  Size: 30kB
  By: mr2147

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

    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Sat Dec  4 23:58:28 2010
From: INVALID.NOREPLY at gnu.org (anonymous)
Date: Sat, 04 Dec 2010 22:58:28 +0000
Subject: [sr #107540] iPhone/iPad TLS negotiation to postfix fails with
	certtool certs, works with openssl certs
In-Reply-To: <20101204-210735.sv80996.83739@savannah.gnu.org>
References: <20101204-210735.sv80996.83739@savannah.gnu.org>
Message-ID: <20101204-225828.sv0.9158@savannah.gnu.org>


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

This may be related to
  http://comments.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/4699

    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Sun Dec  5 10:16:32 2010
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Sun, 05 Dec 2010 09:16:32 +0000
Subject: [sr #107540] iPhone/iPad TLS negotiation to postfix fails with
	certtool certs, works with openssl certs
In-Reply-To: <20101204-225828.sv0.9158@savannah.gnu.org>
References: <20101204-210735.sv80996.83739@savannah.gnu.org>
	<20101204-225828.sv0.9158@savannah.gnu.org>
Message-ID: <20101205-111631.sv707.28910@savannah.gnu.org>


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

<i>generating certs directly without the request step doesn't work too. In
fact I tried various combinations over the course of 7 hours, see table</i>

You report two issues here. What is your issue in generating certificates
without the request step? What commands do you use? Could you elaborate?


    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Sun Dec  5 10:18:39 2010
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Sun, 05 Dec 2010 09:18:39 +0000
Subject: [sr #107540] iPhone/iPad TLS negotiation to postfix fails with
	certtool certs, works with openssl certs
In-Reply-To: <20101205-111631.sv707.28910@savannah.gnu.org>
References: <20101204-210735.sv80996.83739@savannah.gnu.org>
	<20101204-225828.sv0.9158@savannah.gnu.org>
	<20101205-111631.sv707.28910@savannah.gnu.org>
Message-ID: <20101205-111839.sv707.11771@savannah.gnu.org>


Update of sr #107540 (project gnutls):

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

    _______________________________________________________

Follow-up Comment #3:

There are many options to enable in a certificate when generating it. It
might be an option (PKIX extension) in the certificate of gnutls that
frustrates the clients you use. Could you post the gnutls certificate that has
issues and the openssl certificate that works? Have you tried different
combinations of options when generating the certificate?

    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Sun Dec  5 10:37:32 2010
From: INVALID.NOREPLY at gnu.org (Andreas Metzler)
Date: Sun, 05 Dec 2010 09:37:32 +0000
Subject: [sr #107540] iPhone/iPad TLS negotiation to postfix fails with
	certtool certs, works with openssl certs
In-Reply-To: <20101205-111839.sv707.11771@savannah.gnu.org>
References: <20101204-210735.sv80996.83739@savannah.gnu.org>
	<20101204-225828.sv0.9158@savannah.gnu.org>
	<20101205-111631.sv707.28910@savannah.gnu.org>
	<20101205-111839.sv707.11771@savannah.gnu.org>
Message-ID: <20101205-103732.sv20807.50660@savannah.gnu.org>


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

Nikos wrote
> Could you post the gnutls certificate that has issues and the
> openssl certificate that works?

Afaiui this has already been done, see
pelican.layer-7.net.pem_gtls_req_gtls_ca_openssl and
pelican.layer-7.net.pem_gtls_req_gtls_ca_certtool in the attached tarfile.

    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/




From nmav at gnutls.org  Sun Dec  5 10:39:09 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 05 Dec 2010 10:39:09 +0100
Subject: Buffer overflow in gnutls-serv http code
In-Reply-To: <1291299871.15535.68.camel@vespa.frost.loc>
References: <1291299871.15535.68.camel@vespa.frost.loc>
Message-ID: <4CFB5DBD.4010503@gnutls.org>

On 12/02/2010 03:24 PM, Tomas Mraz wrote:
> The gnutls-serv uses fixed allocated buffer for the response which can
> be pretty long if a client certificate is presented to it and the http
> header is large. This causes buffer overflow and heap corruption which
> then leads to random segfaults or aborts.
> 
> It was reported originally here:
> https://bugzilla.redhat.com/show_bug.cgi?id=659259
> 
> The attached patch changes sprintf calls in peer_print_info() to
> snprintf so the buffer is never overflowed.

Thank you. Applied.

regards,
Nikos




From nmav at gnutls.org  Sun Dec  5 10:41:22 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 05 Dec 2010 10:41:22 +0100
Subject: common.c and getpass.c and thread safety, zeroization
In-Reply-To: <AANLkTikbDc-AkNMK4QxaxYSRbzmBNO_5tM5=RwxMN7+o@mail.gmail.com>
References: <AANLkTikbDc-AkNMK4QxaxYSRbzmBNO_5tM5=RwxMN7+o@mail.gmail.com>
Message-ID: <4CFB5E42.1060600@gnutls.org>

On 12/02/2010 08:31 PM, Jeffrey Walton wrote:
> The caching that is occurring -  via static data declaration - with
> respect to passwords in common.c and getpass.c appears to leak
> sensitive material. At minimum, routines are not following best
> practices regarding sensitive data such as passwords and PINs.
> 
> For example, if a password is only needed once, its unclear how to
> zeroize the memory in a static buffer from an invoked function after
> its use. Its also unclear how to specify that sensitive material, such
> as a password or PIN, *not* be cached.
> In addition, a static buffer in used in getpass.c. getline(3) states
> it will realloc if the required buffer for the password is too small.
> How does GnuTLS zeroize the memory in calls to getpass.c when the
> static buffer needs to grow? getline(3) makes no guarantees the data
> will be sanitized.
> Finally, the static buffers are not thread safe in its current
> implementation. stdin and stout out might be serialized, but threads
> which are concurrently executing routines such as getpass.c will leave
> the shared buffer in an unknown state since the buffer might change
> before the caller can copy out the correct [expected?] password.

getpass() is an old interface to read a password from keyboard. It is
not the best out there but there isn't any alternative I know of. If you
know some we would be interested to know.

regards,
Nikos



From nmav at gnutls.org  Sun Dec  5 10:54:22 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 05 Dec 2010 10:54:22 +0100
Subject: Savannah, SQL Injection, Passwords, and Security Posture
In-Reply-To: <AANLkTikKk=wjAJkom1gaX02u5R0YN2hGWJYKqqwvgSn+@mail.gmail.com>
References: <AANLkTikKk=wjAJkom1gaX02u5R0YN2hGWJYKqqwvgSn+@mail.gmail.com>
Message-ID: <4CFB614E.5010702@gnutls.org>

On 12/02/2010 09:34 PM, Jeffrey Walton wrote:

> According to http://savannah.gnu.org/, the server was down for a few 
> days due to a SQL Injection. Because the server did not properly 
> sanitize its data, the password database was compromised. Today, I 
> tried to change my  password to a similar password. Surprisingly, the
> change was rejected because the password was too similar. The 
> "surprising" part is it appears GNU is storing passwords in plain 
> text. I'm going out on the limb and guessing that free software 
> stored the passwords in the plain text. "Password Security: A Case 
> History" by Morris and Thompson was written in the 1970s. Sadly, GNU
>  has totally punned lessons learned in the past.

GNU is a big organization, with different people, and maybe some common
policies. About security policies you might want to contact the gnu
maintainers mailing list, or some other internal list. My relation with
FSF and GNU is only the fact that GNUTLS is part of GNU, and I
transferred copyright to FSF. I'm not actively involved organizationally.

> The GnuTLS project happily uses dangerous string function. Use of
> the functions appears unaudited, suffering unchecked buffer overflows
> and truncations. In fact, the project took a buffer overflow report
> today due to a call to sprintf.

I thought you were familiar with the gnutls internals. In any case,
GnuTLS uses its own string functions, internally, which have no issues
related to buffer overflows. The only cases where we use the libc
functions, such as snprintf and friends, is when the strings are static,
and will not exceed the given buffers. If you have some example where
this is not case please report it (I already explained that in a
previous e-mail).

If you are referring to overflow of the test program gnutls-serv, I
wouldn't care that much. It is a testing program, not one expected to be
run in a non-developer's PC.

> Sadly, GNU has totally punned lessons learned in the past (again).

Please don't confuse me, with GNU.

regards,
Nikos



From INVALID.NOREPLY at gnu.org  Sun Dec  5 11:05:48 2010
From: INVALID.NOREPLY at gnu.org (Michael Rommel)
Date: Sun, 05 Dec 2010 10:05:48 +0000
Subject: [sr #107540] iPhone/iPad TLS negotiation to postfix fails with
	certtool certs, works with openssl certs
In-Reply-To: <20101205-103732.sv20807.50660@savannah.gnu.org>
References: <20101204-210735.sv80996.83739@savannah.gnu.org>
	<20101204-225828.sv0.9158@savannah.gnu.org>
	<20101205-111631.sv707.28910@savannah.gnu.org>
	<20101205-111839.sv707.11771@savannah.gnu.org>
	<20101205-103732.sv20807.50660@savannah.gnu.org>
Message-ID: <20101205-100547.sv80996.68511@savannah.gnu.org>


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

To comment #2:

Sorry, I may have been not exact: creation of the certificate without the
request step does work and produce a certificate, but the issue that I
reported occurs also with this certificate.

The table has been lost during reformatting in proportional font. I'll attach
a picture.

I tried to use different combinations of used ca.pem certificate to sign the
request files using both tools.

To comment #3:

At first I tried the recommended PKIX extensions defined in RFC5280 for the
pelican certificate which should be used for TLS sessions. 

If I understand the RFC correct, Key usage should be flagged as
digitalSignature, keyEncipherment or keyAgreement, as stated in 4.2.1.12.
Hopefully, the related certtool template keywords are: encryption_key and
signing_key.

Extended Key Usage should be id-kp-serverAuth and id-kp-clientAuth. certtool
template keywords: tls_www_client and tls_www_server. The client is needed, so
that the postfix mail server can authenticate to the upstream mail relay.

I have tried including these options to no success. So therefore I have
stripped down Key Usage and Extended Key usage and use them only in the CA
certificate to avoid further complication. I configured the openssl CA config
file, so that the resulting x509 output showed only minimal differences
between the certs created by certtool and openssl ca.

If you have further questions, go ahead. I can also try out commands to
further narrow down the issue.


(file #22125)
    _______________________________________________________

Additional Item Attachment:

File name: Screen shot 2010-12-05 at 10.52.58 .png Size:18 KB


    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Sun Dec  5 11:09:03 2010
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Sun, 05 Dec 2010 10:09:03 +0000
Subject: [sr #107540] iPhone/iPad TLS negotiation to postfix fails with
	certtool certs, works with openssl certs
In-Reply-To: <20101205-100547.sv80996.68511@savannah.gnu.org>
References: <20101204-210735.sv80996.83739@savannah.gnu.org>
	<20101204-225828.sv0.9158@savannah.gnu.org>
	<20101205-111631.sv707.28910@savannah.gnu.org>
	<20101205-111839.sv707.11771@savannah.gnu.org>
	<20101205-103732.sv20807.50660@savannah.gnu.org>
	<20101205-100547.sv80996.68511@savannah.gnu.org>
Message-ID: <20101205-120903.sv707.35847@savannah.gnu.org>


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

Ah, sorry I only read the description and left with the impression that only
the openssl was there. I've checked the certificates and they are exactly the
same except of one thing. The "signature" field of the certificate in certtool
which is an AlgorithmIdentifier does not include the parameters option, since
there are no parameters, while the openssl certificate includes the NULL
encoding. Both are correct, but it seems that client is picky. I'll try to
check if there is an easy patch to generate a key that will use NULL encoding
to try.

    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Sun Dec  5 11:20:12 2010
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Sun, 05 Dec 2010 10:20:12 +0000
Subject: [sr #107540] iPhone/iPad TLS negotiation to postfix fails with
	certtool certs, works with openssl certs
In-Reply-To: <20101205-120903.sv707.35847@savannah.gnu.org>
References: <20101204-210735.sv80996.83739@savannah.gnu.org>
	<20101204-225828.sv0.9158@savannah.gnu.org>
	<20101205-111631.sv707.28910@savannah.gnu.org>
	<20101205-111839.sv707.11771@savannah.gnu.org>
	<20101205-103732.sv20807.50660@savannah.gnu.org>
	<20101205-100547.sv80996.68511@savannah.gnu.org>
	<20101205-120903.sv707.35847@savannah.gnu.org>
Message-ID: <20101205-122012.sv707.93799@savannah.gnu.org>


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

Could you try the attached patch, on whether generates certificates that are
accepted by the devices?

(file #22126)
    _______________________________________________________

Additional Item Attachment:

File name: patch.txt                      Size:0 KB


    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Sun Dec  5 12:36:07 2010
From: INVALID.NOREPLY at gnu.org (Michael Rommel)
Date: Sun, 05 Dec 2010 11:36:07 +0000
Subject: [sr #107540] iPhone/iPad TLS negotiation to postfix fails with
	certtool certs, works with openssl certs
In-Reply-To: <20101205-113502.sv80996.19231@savannah.gnu.org>
References: <20101204-210735.sv80996.83739@savannah.gnu.org>
	<20101204-225828.sv0.9158@savannah.gnu.org>
	<20101205-111631.sv707.28910@savannah.gnu.org>
	<20101205-111839.sv707.11771@savannah.gnu.org>
	<20101205-103732.sv20807.50660@savannah.gnu.org>
	<20101205-100547.sv80996.68511@savannah.gnu.org>
	<20101205-120903.sv707.35847@savannah.gnu.org>
	<20101205-122012.sv707.93799@savannah.gnu.org>
	<20101205-113502.sv80996.19231@savannah.gnu.org>
Message-ID: <20101205-113602.sv80996.76367@savannah.gnu.org>


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

Oh, do I have to re-generate the keys, too? I'll try that, hang on....

    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Sun Dec  5 12:39:50 2010
From: INVALID.NOREPLY at gnu.org (Michael Rommel)
Date: Sun, 05 Dec 2010 11:39:50 +0000
Subject: [sr #107540] iPhone/iPad TLS negotiation to postfix fails with
	certtool certs, works with openssl certs
In-Reply-To: <20101205-113602.sv80996.76367@savannah.gnu.org>
References: <20101204-210735.sv80996.83739@savannah.gnu.org>
	<20101204-225828.sv0.9158@savannah.gnu.org>
	<20101205-111631.sv707.28910@savannah.gnu.org>
	<20101205-111839.sv707.11771@savannah.gnu.org>
	<20101205-103732.sv20807.50660@savannah.gnu.org>
	<20101205-100547.sv80996.68511@savannah.gnu.org>
	<20101205-120903.sv707.35847@savannah.gnu.org>
	<20101205-122012.sv707.93799@savannah.gnu.org>
	<20101205-113502.sv80996.19231@savannah.gnu.org>
	<20101205-113602.sv80996.76367@savannah.gnu.org>
Message-ID: <20101205-113950.sv80996.99224@savannah.gnu.org>


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

No, also with freshly generated new 1024 bit private keys, the symptom is the
same. :-( Thanks for your effort, I know that it is most probably not a
certtool issue, rather an Apple one.

    _______________________________________________________

Reply to this item at:

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

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




From nmav at gnutls.org  Sun Dec  5 16:33:12 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 05 Dec 2010 16:33:12 +0100
Subject: [sr #107540] iPhone/iPad TLS negotiation to postfix fails with
 certtool certs, works with openssl certs
In-Reply-To: <ED5FBD53-113F-4EE3-B85D-D7B36F2504DD@layer-7.net>
References: <20101204-210735.sv80996.83739@savannah.gnu.org>
	<20101204-225828.sv0.9158@savannah.gnu.org>
	<20101205-111631.sv707.28910@savannah.gnu.org>
	<20101205-111839.sv707.11771@savannah.gnu.org>
	<20101205-103732.sv20807.50660@savannah.gnu.org>
	<20101205-100547.sv80996.68511@savannah.gnu.org>
	<20101205-120903.sv707.35847@savannah.gnu.org>
	<20101205-122012.sv707.93799@savannah.gnu.org>
	<ED5FBD53-113F-4EE3-B85D-D7B36F2504DD@layer-7.net>
Message-ID: <4CFBB0B8.7090101@gnutls.org>

It might be that apple is correct here, and gnutls doesn't encode
properly. I see that only on ECDSA the parameters field must be ommited
while on RSA the parameters shall be of NULL type. Thus I'd handle this
as a bug on gnutls' side and commit a fix. Thank you for bringing that
to our attention!

regards,
Nikos


On 12/05/2010 03:29 PM, Michael Rommel wrote:
> Hi Nikos,
> 
> doing the same patch you suggested in a second location:
> 
> Line 1181 in lib/x509/common.c
> 
>       /* result = asn1_write_value (dst, name, NULL, 0); */
>       result = asn1_write_value (dst, name, "\x05\x00", 2);
> 
> did do the trick. Now the certificate is accepted and displayed for acceptance. I'll update the info as soon as savannah is reachable again, the last hour or so, no connection was possible.
> 
> Can you please give me a little bit more information, where I can find out more about the correct parameters?
> 
> RFC3279 states:
> The ASN.1 object identifier used to identify this signature algorithm
>    is:
> 
>       sha-1WithRSAEncryption OBJECT IDENTIFIER  ::=  {
>           iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
>           pkcs-1(1) 5  }
> 
>    When any of these three OIDs appears within the ASN.1 type
>    AlgorithmIdentifier, the parameters component of that type SHALL be
>    the ASN.1 type NULL.
> 
>    The RSA signature generation process and the encoding of the result
>    is described in detail in PKCS #1 [RFC 2313].
> So it is a SHOULD. But can you leave it out or what can you do, when you don't want to follow the SHOULD route?
> 
> I'd try to take the info to the openssl team and Apple because it would be their part now... But if the behaviour is not defined how to handle the non-SHOULD way it would make it difficult.
> 
> What's you opinion on that?
> 
> Thanks a lot!
> 
>   Michael.
> 
> 
> On 5. Dec 2010, at 11:20 , Nikos Mavrogiannopoulos wrote:
> 
>>
>> Follow-up Comment #7, sr #107540 (project gnutls):
>>
>> Could you try the attached patch, on whether generates certificates that are
>> accepted by the devices?
>>
>> (file #22126)
>>    _______________________________________________________
>>
>> Additional Item Attachment:
>>
>> File name: patch.txt                      Size:0 KB
>>
>>
>>    _______________________________________________________
>>
>> Reply to this item at:
>>
>>  <http://savannah.gnu.org/support/?107540>
>>
>> _______________________________________________
>>  Message sent via/by Savannah
>>  http://savannah.gnu.org/
>>
> 




From simon at josefsson.org  Mon Dec  6 15:26:38 2010
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 06 Dec 2010 15:26:38 +0100
Subject: GnuTLS 2.10.4 released
Message-ID: <87lj43asf5.fsf@latte.josefsson.org>

We are proud to announce a new stable GnuTLS release: Version 2.10.4.

GnuTLS is a modern C library that implements the standard network
security protocol Transport Layer Security (TLS), for use by network
applications.  GnuTLS is developed for GNU/Linux, but works on many
Unix-like systems and comes with a binary installer for Windows.

The GnuTLS library is distributed under the terms of the GNU Lesser
General Public License version 2.1 (or later).  The "extra" GnuTLS
library (which contains TLS/IA support, LZO compression and Libgcrypt
FIPS-mode handler), the OpenSSL compatibility library, the self tests
and the command line tools are all distributed under the GNU General
Public License version 3.0 (or later).  The manual is distributed
under the GNU Free Documentation License version 1.3 (or later).

The project page of the library is available at:
  http://www.gnu.org/software/gnutls/

What's New
==========

** gnutls-serv: Corrected a buffer overflow. Reported and patch by Tomas Mraz.

** libgnutls: Use ASN1_NULL when writing parameters for RSA signatures. 
This makes us comply with RFC3279. Reported by Michael Rommel.

** libgnutls: Reverted default behavior for verification and
introduced GNUTLS_VERIFY_DO_NOT_ALLOW_X509_V1_CA_CRT. Thus by default
V1 trusted CAs are allowed, unless the new flag is specified.

** minitasn1: Updated to Libtasn1 2.9.

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

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

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

Here are the BZIP2 compressed sources (7.0MB):

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

Here are OpenPGP detached signatures signed using key 0xB565716F:

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

Note, that we don't distribute gzip compressed tarballs.

In order to check that the version of GnuTLS which you are going to
install is an original and unmodified one, you should verify the OpenPGP
signature.  You can use the command

     gpg --verify gnutls-2.10.4.tar.bz2.sig

This checks whether the signature file matches the source file.  You
should see a message indicating that the signature is good and made by
that signing key.  Make sure that you have the right key, either by
checking the fingerprint of that key with other sources or by checking
that the key has been signed by a trustworthy other key.  The signing
key can be identified with the following information:

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

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

Alternatively, after successfully verifying the OpenPGP signature of
this announcement, you could verify that the files match the following
checksum values.  The values are for SHA-1 and SHA-224 respectively:

f0dcd7b68748b48d7b945c52b6a9e64d643e4b58  gnutls-2.10.4.tar.bz2

7c57226444af5744a938f9c1ef12e6c8c5f5144f2368859613afe968  gnutls-2.10.4.tar.bz2

Documentation
=============

The manual is available online at:

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

In particular the following formats are available:

 HTML: http://www.gnu.org/software/gnutls/manual/html_node/index.html
 PDF: http://www.gnu.org/software/gnutls/manual/gnutls.pdf

For developers there is a GnuTLS API reference manual formatted using
the GTK-DOC tools:

  HTML: http://www.gnu.org/software/gnutls/reference/gnutls-gnutls.html
  PDF: http://www.gnu.org/software/gnutls/reference/gnutls.pdf

Community
=========

If you need help to use GnuTLS, or want to help others, you are invited
to join our help-gnutls mailing list, see:

  http://lists.gnu.org/mailman/listinfo/help-gnutls

If you wish to participate in the development of GnuTLS, you are invited
to join our gnutls-dev mailing list, see:

  http://lists.gnu.org/mailman/listinfo/gnutls-devel

Internationalization
====================

The GnuTLS library messages have been translated into Czech, Dutch,
French, German, Italian, Malay, Polish, Simplified Chinese, Swedish,
and Vietnamese.  We welcome the addition of more translations.

Support
=======

Improving GnuTLS is costly, but you can help!  We are looking for
organizations that find GnuTLS useful and wish to contribute back.  You
can contribute by reporting bugs, improve the software, or donate money
or equipment.

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

The GnuTLS service directory is available at:

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

Happy Hacking,
Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 424 bytes
Desc: not available
URL: </pipermail/attachments/20101206/6fad6d98/attachment.pgp>

From simon at josefsson.org  Mon Dec  6 15:42:03 2010
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 06 Dec 2010 15:42:03 +0100
Subject: common.c and getpass.c and thread safety, zeroization
In-Reply-To: <AANLkTikbDc-AkNMK4QxaxYSRbzmBNO_5tM5=RwxMN7+o@mail.gmail.com>
	(Jeffrey Walton's message of "Thu, 2 Dec 2010 14:31:15 -0500")
References: <AANLkTikbDc-AkNMK4QxaxYSRbzmBNO_5tM5=RwxMN7+o@mail.gmail.com>
Message-ID: <87d3pfarpg.fsf@latte.josefsson.org>

Jeffrey Walton <noloader at gmail.com> writes:

> The caching that is occurring -  via static data declaration - with
> respect to passwords in common.c and getpass.c appears to leak
> sensitive material. At minimum, routines are not following best
> practices regarding sensitive data such as passwords and PINs.
>
> For example, if a password is only needed once, its unclear how to
> zeroize the memory in a static buffer from an invoked function after
> its use. Its also unclear how to specify that sensitive material, such
> as a password or PIN, *not* be cached.
>
> In addition, a static buffer in used in getpass.c. getline(3) states
> it will realloc if the required buffer for the password is too small.
> How does GnuTLS zeroize the memory in calls to getpass.c when the
> static buffer needs to grow? getline(3) makes no guarantees the data
> will be sanitized.

Improvements are welcome, it is not easy to do in a portable and easy to
maintain way.

> Finally, the static buffers are not thread safe in its current
> implementation. stdin and stout out might be serialized, but threads
> which are concurrently executing routines such as getpass.c will leave
> the shared buffer in an unknown state since the buffer might change
> before the caller can copy out the correct [expected?] password.

The command line tools are not threaded, so I don't believe this is
relevant.  Getpass is not used by the GnuTLS library.

/Simon



From simon at josefsson.org  Mon Dec  6 15:51:39 2010
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 06 Dec 2010 15:51:39 +0100
Subject: Savannah, SQL Injection, Passwords, and Security Posture
In-Reply-To: <AANLkTikKk=wjAJkom1gaX02u5R0YN2hGWJYKqqwvgSn+@mail.gmail.com>
	(Jeffrey Walton's message of "Thu, 2 Dec 2010 15:34:47 -0500")
References: <AANLkTikKk=wjAJkom1gaX02u5R0YN2hGWJYKqqwvgSn+@mail.gmail.com>
Message-ID: <8762v7ar9g.fsf@latte.josefsson.org>

Jeffrey Walton <noloader at gmail.com> writes:

> Hi All,
>
> According to http://savannah.gnu.org/, the server was down for a few
> days due to a SQL Injection. Because the server did not properly
> sanitize its data, the password database was compromised.
>
> Today, I tried to change my  password to a similar password.
> Surprisingly, the change was rejected because the password was too
> similar. The "surprising" part is it appears GNU is storing passwords
> in plain text.
>
> I'm going out on the limb and guessing that free software stored the
> passwords in the plain text. "Password Security: A Case History" by
> Morris and Thompson was written in the 1970s. Sadly, GNU has totally
> punned lessons learned in the past.

If you join the Savannah project, I'm sure they could use your help.  I
know that they need more manpower.

> The GnuTLS project happily uses dangerous string function. Use of the
> functions appears unaudited, suffering unchecked buffer overflows and
> truncations. In fact, the project took a buffer overflow report today
> due to a call to sprintf. Sadly, GNU has totally punned lessons
> learned in the past (again).

Again, without volunteers to do the work, it won't improve.

> Would someone be able to provide GNU's policy regarding application
> security and proper use of cryptography in GNU projects. "GNU Coding
> Standards" (http://www.gnu.org/prep/standards/standards.html) does not
> address anything security related. I'm very interested in learning
> about GNU's security posture.

To improve the document, you can send contributions to
bug-standards at gnu.org.

/Simon



From rommel at layer-7.net  Sun Dec  5 15:29:42 2010
From: rommel at layer-7.net (Michael Rommel)
Date: Sun, 5 Dec 2010 15:29:42 +0100
Subject: [sr #107540] iPhone/iPad TLS negotiation to postfix fails with
	certtool certs, works with openssl certs
In-Reply-To: <20101205-122012.sv707.93799@savannah.gnu.org>
References: <20101204-210735.sv80996.83739@savannah.gnu.org>
	<20101204-225828.sv0.9158@savannah.gnu.org>
	<20101205-111631.sv707.28910@savannah.gnu.org>
	<20101205-111839.sv707.11771@savannah.gnu.org>
	<20101205-103732.sv20807.50660@savannah.gnu.org>
	<20101205-100547.sv80996.68511@savannah.gnu.org>
	<20101205-120903.sv707.35847@savannah.gnu.org>
	<20101205-122012.sv707.93799@savannah.gnu.org>
Message-ID: <ED5FBD53-113F-4EE3-B85D-D7B36F2504DD@layer-7.net>

Hi Nikos,

doing the same patch you suggested in a second location:

Line 1181 in lib/x509/common.c

      /* result = asn1_write_value (dst, name, NULL, 0); */
      result = asn1_write_value (dst, name, "\x05\x00", 2);

did do the trick. Now the certificate is accepted and displayed for acceptance. I'll update the info as soon as savannah is reachable again, the last hour or so, no connection was possible.

Can you please give me a little bit more information, where I can find out more about the correct parameters?

RFC3279 states:
The ASN.1 object identifier used to identify this signature algorithm
   is:

      sha-1WithRSAEncryption OBJECT IDENTIFIER  ::=  {
          iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
          pkcs-1(1) 5  }

   When any of these three OIDs appears within the ASN.1 type
   AlgorithmIdentifier, the parameters component of that type SHALL be
   the ASN.1 type NULL.

   The RSA signature generation process and the encoding of the result
   is described in detail in PKCS #1 [RFC 2313].
So it is a SHOULD. But can you leave it out or what can you do, when you don't want to follow the SHOULD route?

I'd try to take the info to the openssl team and Apple because it would be their part now... But if the behaviour is not defined how to handle the non-SHOULD way it would make it difficult.

What's you opinion on that?

Thanks a lot!

  Michael.


On 5. Dec 2010, at 11:20 , Nikos Mavrogiannopoulos wrote:

> 
> Follow-up Comment #7, sr #107540 (project gnutls):
> 
> Could you try the attached patch, on whether generates certificates that are
> accepted by the devices?
> 
> (file #22126)
>    _______________________________________________________
> 
> Additional Item Attachment:
> 
> File name: patch.txt                      Size:0 KB
> 
> 
>    _______________________________________________________
> 
> Reply to this item at:
> 
>  <http://savannah.gnu.org/support/?107540>
> 
> _______________________________________________
>  Message sent via/by Savannah
>  http://savannah.gnu.org/
> 

-- 
Michael Rommel, Erlangen, Germany





From rommel at layer-7.net  Sun Dec  5 15:42:20 2010
From: rommel at layer-7.net (Michael Rommel)
Date: Sun, 5 Dec 2010 15:42:20 +0100
Subject: [sr #107540] iPhone/iPad TLS negotiation to postfix fails with
	certtool certs, works with openssl certs
In-Reply-To: <ED5FBD53-113F-4EE3-B85D-D7B36F2504DD@layer-7.net>
References: <20101204-210735.sv80996.83739@savannah.gnu.org>
	<20101204-225828.sv0.9158@savannah.gnu.org>
	<20101205-111631.sv707.28910@savannah.gnu.org>
	<20101205-111839.sv707.11771@savannah.gnu.org>
	<20101205-103732.sv20807.50660@savannah.gnu.org>
	<20101205-100547.sv80996.68511@savannah.gnu.org>
	<20101205-120903.sv707.35847@savannah.gnu.org>
	<20101205-122012.sv707.93799@savannah.gnu.org>
	<ED5FBD53-113F-4EE3-B85D-D7B36F2504DD@layer-7.net>
Message-ID: <2B78A8F6-F581-4706-8314-A0DFDD9CFBB0@layer-7.net>


Sorry, I meant SHALL not SHOULD.

On 5. Dec 2010, at 15:29 , Michael Rommel wrote:

> Hi Nikos,
> 
> doing the same patch you suggested in a second location:
> 
> Line 1181 in lib/x509/common.c
> 
>      /* result = asn1_write_value (dst, name, NULL, 0); */
>      result = asn1_write_value (dst, name, "\x05\x00", 2);
> 
> did do the trick. Now the certificate is accepted and displayed for acceptance. I'll update the info as soon as savannah is reachable again, the last hour or so, no connection was possible.
> 
> Can you please give me a little bit more information, where I can find out more about the correct parameters?
> 
> RFC3279 states:
> The ASN.1 object identifier used to identify this signature algorithm
>   is:
> 
>      sha-1WithRSAEncryption OBJECT IDENTIFIER  ::=  {
>          iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
>          pkcs-1(1) 5  }
> 
>   When any of these three OIDs appears within the ASN.1 type
>   AlgorithmIdentifier, the parameters component of that type SHALL be
>   the ASN.1 type NULL.
> 
>   The RSA signature generation process and the encoding of the result
>   is described in detail in PKCS #1 [RFC 2313].
> So it is a SHOULD. But can you leave it out or what can you do, when you don't want to follow the SHOULD route?
> 
> I'd try to take the info to the openssl team and Apple because it would be their part now... But if the behaviour is not defined how to handle the non-SHOULD way it would make it difficult.
> 
> What's you opinion on that?
> 
> Thanks a lot!
> 
>  Michael.
> 
> 
> On 5. Dec 2010, at 11:20 , Nikos Mavrogiannopoulos wrote:
> 
>> 
>> Follow-up Comment #7, sr #107540 (project gnutls):
>> 
>> Could you try the attached patch, on whether generates certificates that are
>> accepted by the devices?
>> 
>> (file #22126)
>>   _______________________________________________________
>> 
>> Additional Item Attachment:
>> 
>> File name: patch.txt                      Size:0 KB
>> 
>> 
>>   _______________________________________________________
>> 
>> Reply to this item at:
>> 
>> <http://savannah.gnu.org/support/?107540>
>> 
>> _______________________________________________
>> Message sent via/by Savannah
>> http://savannah.gnu.org/
>> 
> 
> -- 
> Michael Rommel, Erlangen, Germany
> 
> 

-- 
Michael Rommel, Erlangen, Germany





From brendand at gentrack.com  Mon Dec  6 23:49:29 2010
From: brendand at gentrack.com (Brendan Doherty)
Date: Tue, 7 Dec 2010 11:49:29 +1300
Subject: c++ compatibility of crypto.h
Message-ID: <E9DEE33D14535745BF7AD8EECE9AC74002CE1D23@SPHINX.talgentra.co.nz>

Hi, 

 

I've run into two problems when including gnutls/crypto.h into c++ code.

-          Missing extern "C"

-          Parameter names conflict with c++ keywords.

 

The patch below fixes the two problems.

 

Regards,

Brendan Doherty

Systems Architect

Gentrack Ltd

 

--- ../crypto.h 2010-12-07 11:46:25.000000000 +1300

+++ /gencore/gnutls-2.10.2/include/gnutls/crypto.h      2010-12-07
11:40:14.000000000 +1300

@@ -25,6 +25,11 @@

#ifndef GNUTLS_CRYPTO_H

# define GNUTLS_CRYPTO_H

+#ifdef __cplusplus

+extern "C"

+{

+#endif

+

typedef struct cipher_hd_st *gnutls_cipher_hd_t;

 int gnutls_cipher_init (gnutls_cipher_hd_t * handle,

@@ -266,17 +271,17 @@ typedef struct gnutls_crypto_pk

    * parameters, depending on the operation */

   int (*encrypt) (gnutls_pk_algorithm_t, gnutls_datum_t * ciphertext,

                  const gnutls_datum_t * plaintext,

-                 const gnutls_pk_params_st * public);

+                 const gnutls_pk_params_st * pub);

   int (*decrypt) (gnutls_pk_algorithm_t, gnutls_datum_t * plaintext,

                  const gnutls_datum_t * ciphertext,

-                 const gnutls_pk_params_st * private);

+                 const gnutls_pk_params_st * priv);

   int (*sign) (gnutls_pk_algorithm_t, gnutls_datum_t * signature,

               const gnutls_datum_t * data,

-              const gnutls_pk_params_st * private);

+              const gnutls_pk_params_st * priv);

   int (*verify) (gnutls_pk_algorithm_t, const gnutls_datum_t * data,

                 const gnutls_datum_t * signature,

-                const gnutls_pk_params_st * public);

+                const gnutls_pk_params_st * pub);

   int (*generate) (gnutls_pk_algorithm_t, unsigned int nbits,

                   gnutls_pk_params_st *);

@@ -346,4 +351,8 @@ int gnutls_crypto_pk_register2 (int prio

int gnutls_crypto_bigint_register2 (int priority, int version,

                                    const gnutls_crypto_bigint_st * s);

+#ifdef __cplusplus

+}

+#endif

+

#endif

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20101207/4d5d327b/attachment.htm>

From simon at josefsson.org  Tue Dec  7 08:31:21 2010
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 07 Dec 2010 08:31:21 +0100
Subject: Buffer overflow in gnutls-serv http code
In-Reply-To: <1291299871.15535.68.camel@vespa.frost.loc> (Tomas Mraz's message
	of "Thu, 02 Dec 2010 15:24:31 +0100")
References: <1291299871.15535.68.camel@vespa.frost.loc>
Message-ID: <87r5du599y.fsf@latte.josefsson.org>

Tomas Mraz <tmraz at redhat.com> writes:

> The gnutls-serv uses fixed allocated buffer for the response which can
> be pretty long if a client certificate is presented to it and the http
> header is large. This causes buffer overflow and heap corruption which
> then leads to random segfaults or aborts.
>
> It was reported originally here:
> https://bugzilla.redhat.com/show_bug.cgi?id=659259
>
> The attached patch changes sprintf calls in peer_print_info() to
> snprintf so the buffer is never overflowed.

Thanks -- for copyright reasons, did you do this on RedHat time?
Otherwise the RedHat copyright assignment doesn't cover it, and I
couldn't find an individual assignment.

/Simon



From tmraz at redhat.com  Tue Dec  7 09:03:38 2010
From: tmraz at redhat.com (Tomas Mraz)
Date: Tue, 07 Dec 2010 09:03:38 +0100
Subject: Buffer overflow in gnutls-serv http code
In-Reply-To: <87r5du599y.fsf@latte.josefsson.org>
References: <1291299871.15535.68.camel@vespa.frost.loc>
	<87r5du599y.fsf@latte.josefsson.org>
Message-ID: <1291709018.15535.105.camel@vespa.frost.loc>

On Tue, 2010-12-07 at 08:31 +0100, Simon Josefsson wrote: 
> Tomas Mraz <tmraz at redhat.com> writes:
> 
> > The gnutls-serv uses fixed allocated buffer for the response which can
> > be pretty long if a client certificate is presented to it and the http
> > header is large. This causes buffer overflow and heap corruption which
> > then leads to random segfaults or aborts.
> >
> > It was reported originally here:
> > https://bugzilla.redhat.com/show_bug.cgi?id=659259
> >
> > The attached patch changes sprintf calls in peer_print_info() to
> > snprintf so the buffer is never overflowed.
> 
> Thanks -- for copyright reasons, did you do this on RedHat time?
> Otherwise the RedHat copyright assignment doesn't cover it, and I
> couldn't find an individual assignment.

I did it on behalf of Red Hat so the Red Hat copyright assignment covers
it.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb




From simon at josefsson.org  Tue Dec  7 13:11:44 2010
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 07 Dec 2010 13:11:44 +0100
Subject: GnuTLS 2.11.6
Message-ID: <87lj41vl33.fsf@latte.josefsson.org>

Hello,

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

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

Unless there are issues, this version contains the final version of the
PKCS #11 support for 2.12.x. It has been mostly tested with OpenSC and
Feitian smart cards, but I'd appreciate if you can test it with other
tokens and PKCS11 modules you may have.

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

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

Happy hacking,
Simon

PS.  Accidentally I overwrote the 2.11.5 release on the FTP servers when
doing this release, I'll try to revert the old files.

* Version 2.11.6 (released 2010-12-06)

** libgnutls: Record version of Client Hellos is now set by default to
SSL 3.0. To restore the previous default behavior use %LATEST_RECORD_VERSION
priority string.

** libgnutls: Use ASN1_NULL when writing parameters for RSA signatures. 
This makes us comply with RFC3279. Reported by Michael Rommel.

** gnutls-serv: Corrected a buffer overflow. Reported and patch by Tomas Mraz.

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

From simon at josefsson.org  Tue Dec  7 20:43:20 2010
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 07 Dec 2010 20:43:20 +0100
Subject: c++ compatibility of crypto.h
In-Reply-To: <E9DEE33D14535745BF7AD8EECE9AC74002CE1D23@SPHINX.talgentra.co.nz>
	(Brendan Doherty's message of "Tue, 7 Dec 2010 11:49:29 +1300")
References: <E9DEE33D14535745BF7AD8EECE9AC74002CE1D23@SPHINX.talgentra.co.nz>
Message-ID: <87ipz5qsh3.fsf@latte.josefsson.org>

"Brendan Doherty" <brendand at gentrack.com> writes:

> Hi, 
>
>  
>
> I've run into two problems when including gnutls/crypto.h into c++ code.
>
> -          Missing extern "C"
>
> -          Parameter names conflict with c++ keywords.
>
>  
>
> The patch below fixes the two problems.

Hi Brendan.  Thanks for your patch, I have installed it.

/Simon



From INVALID.NOREPLY at gnu.org  Wed Dec  8 22:26:38 2010
From: INVALID.NOREPLY at gnu.org (Michael Rommel)
Date: Wed, 08 Dec 2010 21:26:38 +0000
Subject: [sr #107540] iPhone/iPad TLS negotiation to postfix fails with
	certtool certs, works with openssl certs
In-Reply-To: <20101205-113950.sv80996.99224@savannah.gnu.org>
References: <20101204-210735.sv80996.83739@savannah.gnu.org>
	<20101204-225828.sv0.9158@savannah.gnu.org>
	<20101205-111631.sv707.28910@savannah.gnu.org>
	<20101205-111839.sv707.11771@savannah.gnu.org>
	<20101205-103732.sv20807.50660@savannah.gnu.org>
	<20101205-100547.sv80996.68511@savannah.gnu.org>
	<20101205-120903.sv707.35847@savannah.gnu.org>
	<20101205-122012.sv707.93799@savannah.gnu.org>
	<20101205-113502.sv80996.19231@savannah.gnu.org>
	<20101205-113602.sv80996.76367@savannah.gnu.org>
	<20101205-113950.sv80996.99224@savannah.gnu.org>
Message-ID: <20101208-212638.sv80996.598@savannah.gnu.org>


Follow-up Comment #11, sr #107540 (project gnutls):

Hello,

during debugging, I tried to apply the same patch in a second location for
the SignatureAlgorithm just after the Subject:

Line 1181 in lib/x509/common.c

     /* result = asn1_write_value (dst, name, NULL, 0); */
     result = asn1_write_value (dst, name, "x05x00", 2);

This turned out to work. Now the certificate is accepted and displayed for
acceptance. 

RFC3279 states:
The ASN.1 object identifier used to identify this signature algorithm is:

     sha-1WithRSAEncryption OBJECT IDENTIFIER  ::=  {
         iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
         pkcs-1(1) 5  }

When any of these three OIDs appears within the ASN.1 type
AlgorithmIdentifier, the parameters component of that type SHALL be the ASN.1
type NULL.

It might be, that these two insertations are needed to conform to the
RFC3279.

Hopefully this does not break anything else.

  Michael.



    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Wed Dec  8 23:10:13 2010
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Wed, 08 Dec 2010 22:10:13 +0000
Subject: [sr #107540] iPhone/iPad TLS negotiation to postfix fails with
	certtool certs, works with openssl certs
In-Reply-To: <20101208-212638.sv80996.598@savannah.gnu.org>
References: <20101204-210735.sv80996.83739@savannah.gnu.org>
	<20101204-225828.sv0.9158@savannah.gnu.org>
	<20101205-111631.sv707.28910@savannah.gnu.org>
	<20101205-111839.sv707.11771@savannah.gnu.org>
	<20101205-103732.sv20807.50660@savannah.gnu.org>
	<20101205-100547.sv80996.68511@savannah.gnu.org>
	<20101205-120903.sv707.35847@savannah.gnu.org>
	<20101205-122012.sv707.93799@savannah.gnu.org>
	<20101205-113502.sv80996.19231@savannah.gnu.org>
	<20101205-113602.sv80996.76367@savannah.gnu.org>
	<20101205-113950.sv80996.99224@savannah.gnu.org>
	<20101208-212638.sv80996.598@savannah.gnu.org>
Message-ID: <20101209-001013.sv707.98927@savannah.gnu.org>


Update of sr #107540 (project gnutls):

                  Status:             In Progress => Done                   
             Open/Closed:                    Open => Closed                 

    _______________________________________________________

Follow-up Comment #12:

gnutls 2.10.4 should have solved those issues. If there is any other issue
remaining please reopen the bug. Thank you for the detailed report and
investigation!

    _______________________________________________________

Reply to this item at:

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

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




From simon at josefsson.org  Mon Dec 13 20:18:34 2010
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 13 Dec 2010 20:18:34 +0100
Subject: Buffer overflow in gnutls-serv http code
In-Reply-To: <1291709018.15535.105.camel@vespa.frost.loc> (Tomas Mraz's
	message of "Tue, 07 Dec 2010 09:03:38 +0100")
References: <1291299871.15535.68.camel@vespa.frost.loc>
	<87r5du599y.fsf@latte.josefsson.org>
	<1291709018.15535.105.camel@vespa.frost.loc>
Message-ID: <877hfd5vn9.fsf@latte.josefsson.org>

Tomas Mraz <tmraz at redhat.com> writes:

> On Tue, 2010-12-07 at 08:31 +0100, Simon Josefsson wrote: 
>> Tomas Mraz <tmraz at redhat.com> writes:
>> 
>> > The gnutls-serv uses fixed allocated buffer for the response which can
>> > be pretty long if a client certificate is presented to it and the http
>> > header is large. This causes buffer overflow and heap corruption which
>> > then leads to random segfaults or aborts.
>> >
>> > It was reported originally here:
>> > https://bugzilla.redhat.com/show_bug.cgi?id=659259
>> >
>> > The attached patch changes sprintf calls in peer_print_info() to
>> > snprintf so the buffer is never overflowed.
>> 
>> Thanks -- for copyright reasons, did you do this on RedHat time?
>> Otherwise the RedHat copyright assignment doesn't cover it, and I
>> couldn't find an individual assignment.
>
> I did it on behalf of Red Hat so the Red Hat copyright assignment covers
> it.

Thanks for confirming this!

/Simon



From INVALID.NOREPLY at gnu.org  Sun Dec 19 12:57:23 2010
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Sun, 19 Dec 2010 11:57:23 +0000
Subject: [sr #107520] GnuTLS: certtool accepts invalid DSA modulus sizes
In-Reply-To: <20101116-165313.sv707.91010@savannah.gnu.org>
References: <20101116-123923.sv80862.29504@savannah.gnu.org>
	<20101116-165313.sv707.91010@savannah.gnu.org>
Message-ID: <20101219-135723.sv707.45655@savannah.gnu.org>


Update of sr #107520 (project gnutls):

                  Status:             In Progress => None                   
             Open/Closed:                    Open => Closed                 


    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Sun Dec 19 12:57:38 2010
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Sun, 19 Dec 2010 11:57:38 +0000
Subject: [sr #107518] GnuTLS: After DSA Key Generation,
	2 Integers were Encoded Incorrectly
In-Reply-To: <20101116-164748.sv707.22406@savannah.gnu.org>
References: <20101116-091256.sv80862.53045@savannah.gnu.org>
	<20101116-091543.sv80862.9275@savannah.gnu.org>
	<20101116-113447.sv80862.68008@savannah.gnu.org>
	<20101116-132612.sv80862.12096@savannah.gnu.org>
	<20101116-132929.sv80862.36266@savannah.gnu.org>
	<20101116-164748.sv707.22406@savannah.gnu.org>
Message-ID: <20101219-135738.sv707.4488@savannah.gnu.org>


Update of sr #107518 (project gnutls):

             Open/Closed:                    Open => Closed                 


    _______________________________________________________

Reply to this item at:

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

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




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


Update of sr #107489 (project gnutls):

             Open/Closed:                    Open => Closed                 


    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Sun Dec 19 13:01:02 2010
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Sun, 19 Dec 2010 12:01:02 +0000
Subject: [sr #107532] gnutls-cli-debug [incorrecttly] reports SRP support
	for Windows Server 2003/IIS 6.0
In-Reply-To: <20101122-105321.sv80862.69033@savannah.gnu.org>
References: <20101122-080727.sv80862.97307@savannah.gnu.org>
	<20101122-104542.sv707.20460@savannah.gnu.org>
	<20101122-093059.sv80862.26667@savannah.gnu.org>
	<20101122-105321.sv80862.69033@savannah.gnu.org>
Message-ID: <20101219-140102.sv707.94014@savannah.gnu.org>


Update of sr #107532 (project gnutls):

             Open/Closed:                    Open => Closed                 


    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Sun Dec 19 13:02:43 2010
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Sun, 19 Dec 2010 12:02:43 +0000
Subject: [sr #107533] Proposed changes to README
In-Reply-To: <20101122-141632.sv80862.38089@savannah.gnu.org>
References: <20101122-141036.sv80862.86138@savannah.gnu.org>
	<20101122-141632.sv80862.38089@savannah.gnu.org>
Message-ID: <20101219-140243.sv707.22428@savannah.gnu.org>


Update of sr #107533 (project gnutls):

             Open/Closed:                    Open => Closed                 


    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Sun Dec 26 03:40:26 2010
From: INVALID.NOREPLY at gnu.org (LRN)
Date: Sun, 26 Dec 2010 02:40:26 +0000
Subject: [sr #107560] libextra/openssl.h conflicts with wincrypt.h
Message-ID: <20101226-024025.sv74148.29875@savannah.gnu.org>


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

                 Summary: libextra/openssl.h conflicts with wincrypt.h
                 Project: GnuTLS
            Submitted by: lrn
            Submitted on: Sun 26 Dec 2010 02:40:25 AM GMT
                Category: None
                Priority: 5 - Normal
                Severity: 3 - Normal
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
        Operating System: Microsoft Windows

    _______________________________________________________

Details:

wincrypt.h from w32api MinGW package contains this line:
#define X509_NAME_VALUE ((LPCSTR) 6)

This conflicts with the definition from openssl.h:
  typedef gnutls_x509_dn X509_NAME;

and results in compile-time errors:
gnutls-2.10.4/libextra/gnutls_openssl.c:862:1: error: expected identifier or
'(' before 'LPCSTR'
gnutls-2.10.4/libextra/gnutls_openssl.c:862:1: error: expected ')' before
numeric constant
gnutls-2.10.4/libextra/gnutls_openssl.c:875:1: error: expected identifier or
'(' before 'LPCSTR'
gnutls-2.10.4/libextra/gnutls_openssl.c:875:1: error: expected ')' before
numeric constant

How to fix:
since wincrypt.h is included as a result of inclusion of sys/socket.h from
gnutls_int.h, the obvious fix is to add this to gnutls_int.h, after #include
<sys/socket.h>:

#if defined(X509_NAME) && defined(__WINCRYPT_H__)
#  undef X509_NAME
#endif

Another way to fix this is to use a different name, such as GNUTLS_X509_NAME




    _______________________________________________________

Reply to this item at:

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

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




From arfrever.fta at gmail.com  Sun Dec 26 22:06:56 2010
From: arfrever.fta at gmail.com (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 26 Dec 2010 22:06:56 +0100
Subject: GnuTLS 2.11.6
In-Reply-To: <87lj41vl33.fsf@latte.josefsson.org>
References: <87lj41vl33.fsf@latte.josefsson.org>
Message-ID: <201012262207.29146.Arfrever.FTA@gmail.com>

Absence of tests/suite directory in the distributed tarballs causes failure of automake:

$ automake
...
configure.ac:190: the top level
configure.ac:296: required file `tests/suite/Makefile.in' not found
$ echo $?
1

Users/packagers might want to make custom changes in a Makefile.am and need to run automake.
Can this problem be fixed?

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

From nmav at gnutls.org  Mon Dec 27 13:32:15 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 27 Dec 2010 14:32:15 +0200
Subject: GnuTLS 2.11.6
In-Reply-To: <201012262207.29146.Arfrever.FTA@gmail.com>
References: <87lj41vl33.fsf@latte.josefsson.org>
	<201012262207.29146.Arfrever.FTA@gmail.com>
Message-ID: <AANLkTimb_7R8yTWQqK5c_0RkUzyHAxjtMeLfb4Qb9gB9@mail.gmail.com>

Temporarily you can use the git version. I'll add the Makefile.in for
the next release.

regards,
Nikos

On Sun, Dec 26, 2010 at 11:06 PM, Arfrever Frehtes Taifersar Arahesis
<arfrever.fta at gmail.com> wrote:
> Absence of tests/suite directory in the distributed tarballs causes failure of automake:
>
> $ automake
> ...
> configure.ac:190: the top level
> configure.ac:296: required file `tests/suite/Makefile.in' not found
> $ echo $?
> 1
>
> Users/packagers might want to make custom changes in a Makefile.am and need to run automake.
> Can this problem be fixed?
>
> --
> Arfrever Frehtes Taifersar Arahesis
>
> _______________________________________________
> Gnutls-devel mailing list
> Gnutls-devel at gnu.org
> http://lists.gnu.org/mailman/listinfo/gnutls-devel
>
>



From Rajitha.R at ge.com  Tue Dec 28 18:27:43 2010
From: Rajitha.R at ge.com (R, Rajitha (GE, Corporate, consultant))
Date: Tue, 28 Dec 2010 22:57:43 +0530
Subject: Query for Windows 2008
Message-ID: <05E98C55868F644DB2F65266128FC3E207F5E407@BANMLVEM04.e2k.ad.ge.com>

Hello,

 

I have a windows 2008 64 bit server, I would like to know which version
of GNUPG can be used for excryption. Also, please help me with exe file
path (URL used to download) and installation procedure. 

 

Many Thanks in advance 

 

Rajitha Ramakuru

GBS EMEA IT infrastructure operations
T    +91 40 66114640
D    *740-4928
E    Rajitha.R at ge.com

 

For any IT Issues Please Contact OneGE Helpdesk:
Dial Comm : *716-6170
Phone : 1-800-868-4513 or 513-716-6170
WebLink : http://helpdesk.ge.com <http://helpdesk.ge.com/>  

 

Please do not print this email unless it is absolutely necessary. Spread
environmental awareness.

 

This e-mail, together with any attachment/s, is confidential.  It may be
read, copied and used only by the intended recipient/s.  If you have
received it in error, please notify the sender immediately by e-mail or
telephone.  Once you have notified the concerned person/s, please delete
it from your computer without making any copies or disclosing it to any
other person. Any unauthorized copying, disclosure or distribution of
the material in this e-mail is strictly forbidden. Thank you. 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20101228/16a0c994/attachment.htm>

From camillo.lugaresi at gmail.com  Wed Dec 29 05:26:42 2010
From: camillo.lugaresi at gmail.com (Camillo Lugaresi)
Date: Wed, 29 Dec 2010 05:26:42 +0100
Subject: GnuTLS does not build on OS X 10.6 due to incompatibility with
	snprintf macro
Message-ID: <EAF78B3B-649C-4BCE-A06E-D95228D67DB4@gmail.com>

Code built with gcc on Mac OS X 10.6 uses the object size checking feature of gcc by default (<http://gcc.gnu.org/onlinedocs/gcc/Object-Size-Checking.html>). This involves redefining several functions as macros; one of these functions is snprintf:

	#define snprintf(str, len, ...) \
 	 __builtin___snprintf_chk (str, len, 0, __darwin_obsz(str), __VA_ARGS__)

The usage of snprintf in src/serv.c in gnutls-2.10.4 is not compatible with that macro. serv.c attempts to use a macro (tmp2) that expands into two different arguments:

	#define tmp2 &http_buffer[strlen(http_buffer)], len-strlen(http_buffer)

	snprintf (tmp2, "%.2X", sesid[i]);

Due to how nested macro evaluation works, the snprintf macro sees tmp2 as a single argument, and copies it into __darwin_obsz(); then, when tmp2 is expanded, __darwin_obsz has two arguments, but it is only defined for one, and the result is a compilation error.

One way to work around this issue might be to define _FORTIFY_SOURCE=0 so that the snprintf macro is not defined, or simply doing an #undef snprintf for that file, but it seems safer and more portable to split tmp2 into two macros. I append a patch that does so.

Best regards,
Camillo Lugaresi


diff --git a/src/serv.c b/src/serv.c
index 0307b05..4b6658d 100644
--- a/src/serv.c
+++ b/src/serv.c
@@ -438,7 +438,8 @@ static const char DEFAULT_DATA[] =
 
 /* Creates html with the current session information.
  */
-#define tmp2 &http_buffer[strlen(http_buffer)], len-strlen(http_buffer)
+#define tmp2b &http_buffer[strlen(http_buffer)]
+#define tmp2l len-strlen(http_buffer)
 static char *
 peer_print_info (gnutls_session_t session, int *ret_length,
 		 const char *header)
@@ -512,11 +513,11 @@ peer_print_info (gnutls_session_t session, int *ret_length,
 
   /* print session_id */
   gnutls_session_get_id (session, sesid, &sesid_size);
-  snprintf (tmp2, "\n<p>Session ID: <i>");
+  snprintf (tmp2b, tmp2l, "\n<p>Session ID: <i>");
   for (i = 0; i < sesid_size; i++)
-    snprintf (tmp2, "%.2X", sesid[i]);
-  snprintf (tmp2, "</i></p>\n");
-  snprintf (tmp2,
+    snprintf (tmp2b, tmp2l, "%.2X", sesid[i]);
+  snprintf (tmp2b, tmp2l, "</i></p>\n");
+  snprintf (tmp2b, tmp2l,
 	   "<h5>If your browser supports session resuming, then you should see the "
 	   "same session ID, when you press the <b>reload</b> button.</h5>\n");
 
@@ -530,7 +531,7 @@ peer_print_info (gnutls_session_t session, int *ret_length,
 
     if (gnutls_server_name_get (session, dns, &dns_size, &type, 0) == 0)
       {
-	snprintf (tmp2, "\n<p>Server Name: %s</p>\n", dns);
+	snprintf (tmp2b, tmp2l, "\n<p>Server Name: %s</p>\n", dns);
       }
 
   }
@@ -541,7 +542,7 @@ peer_print_info (gnutls_session_t session, int *ret_length,
 #ifdef ENABLE_SRP
   if (kx_alg == GNUTLS_KX_SRP)
     {
-      snprintf (tmp2, "<p>Connected as user '%s'.</p>\n",
+      snprintf (tmp2b, tmp2l, "<p>Connected as user '%s'.</p>\n",
 	       gnutls_srp_server_get_username (session));
     }
 #endif
@@ -549,7 +550,7 @@ peer_print_info (gnutls_session_t session, int *ret_length,
 #ifdef ENABLE_PSK
   if (kx_alg == GNUTLS_KX_PSK)
     {
-      snprintf (tmp2, "<p>Connected as user '%s'.</p>\n",
+      snprintf (tmp2b, tmp2l, "<p>Connected as user '%s'.</p>\n",
 	       gnutls_psk_server_get_username (session));
     }
 #endif
@@ -557,7 +558,7 @@ peer_print_info (gnutls_session_t session, int *ret_length,
 #ifdef ENABLE_ANON
   if (kx_alg == GNUTLS_KX_ANON_DH)
     {
-      snprintf (tmp2,
+      snprintf (tmp2b, tmp2l,
 	       "<p> Connect using anonymous DH (prime of %d bits)</p>\n",
 	       gnutls_dh_get_prime_bits (session));
     }
@@ -565,7 +566,7 @@ peer_print_info (gnutls_session_t session, int *ret_length,
 
   if (kx_alg == GNUTLS_KX_DHE_RSA || kx_alg == GNUTLS_KX_DHE_DSS)
     {
-      snprintf (tmp2,
+      snprintf (tmp2b, tmp2l,
 	       "Ephemeral DH using prime of <b>%d</b> bits.<br>\n",
 	       gnutls_dh_get_prime_bits (session));
     }
@@ -576,7 +577,7 @@ peer_print_info (gnutls_session_t session, int *ret_length,
   tmp = gnutls_protocol_get_name (gnutls_protocol_get_version (session));
   if (tmp == NULL)
     tmp = str_unknown;
-  snprintf (tmp2,
+  snprintf (tmp2b, tmp2l,
 	   "<TABLE border=1><TR><TD>Protocol version:</TD><TD>%s</TD></TR>\n",
 	   tmp);
 
@@ -587,44 +588,44 @@ peer_print_info (gnutls_session_t session, int *ret_length,
 					  (session));
       if (tmp == NULL)
 	tmp = str_unknown;
-      snprintf (tmp2, "<TR><TD>Certificate Type:</TD><TD>%s</TD></TR>\n", tmp);
+      snprintf (tmp2b, tmp2l, "<TR><TD>Certificate Type:</TD><TD>%s</TD></TR>\n", tmp);
     }
 
   tmp = gnutls_kx_get_name (kx_alg);
   if (tmp == NULL)
     tmp = str_unknown;
-  snprintf (tmp2, "<TR><TD>Key Exchange:</TD><TD>%s</TD></TR>\n", tmp);
+  snprintf (tmp2b, tmp2l, "<TR><TD>Key Exchange:</TD><TD>%s</TD></TR>\n", tmp);
 
   tmp = gnutls_compression_get_name (gnutls_compression_get (session));
   if (tmp == NULL)
     tmp = str_unknown;
-  snprintf (tmp2, "<TR><TD>Compression</TD><TD>%s</TD></TR>\n", tmp);
+  snprintf (tmp2b, tmp2l, "<TR><TD>Compression</TD><TD>%s</TD></TR>\n", tmp);
 
   tmp = gnutls_cipher_get_name (gnutls_cipher_get (session));
   if (tmp == NULL)
     tmp = str_unknown;
-  snprintf (tmp2, "<TR><TD>Cipher</TD><TD>%s</TD></TR>\n", tmp);
+  snprintf (tmp2b, tmp2l, "<TR><TD>Cipher</TD><TD>%s</TD></TR>\n", tmp);
 
   tmp = gnutls_mac_get_name (gnutls_mac_get (session));
   if (tmp == NULL)
     tmp = str_unknown;
-  snprintf (tmp2, "<TR><TD>MAC</TD><TD>%s</TD></TR>\n", tmp);
+  snprintf (tmp2b, tmp2l, "<TR><TD>MAC</TD><TD>%s</TD></TR>\n", tmp);
 
   tmp = gnutls_cipher_suite_get_name (kx_alg,
 				      gnutls_cipher_get (session),
 				      gnutls_mac_get (session));
   if (tmp == NULL)
     tmp = str_unknown;
-  snprintf (tmp2, "<TR><TD>Ciphersuite</TD><TD>%s</TD></TR></p></TABLE>\n",
+  snprintf (tmp2b, tmp2l, "<TR><TD>Ciphersuite</TD><TD>%s</TD></TR></p></TABLE>\n",
 	   tmp);
 
   if (crtinfo)
     {
-      snprintf(tmp2, "<hr><PRE>%s\n</PRE>\n", crtinfo);
+      snprintf(tmp2b, tmp2l, "<hr><PRE>%s\n</PRE>\n", crtinfo);
       free (crtinfo);
     }
 
-  snprintf(tmp2, "<hr><P>Your HTTP header was:<PRE>%s</PRE></P>\n" HTTP_END, header);
+  snprintf(tmp2b, tmp2l, "<hr><P>Your HTTP header was:<PRE>%s</PRE></P>\n" HTTP_END, header);
 
   *ret_length = strlen (http_buffer);
 




From INVALID.NOREPLY at gnu.org  Thu Dec 30 13:46:39 2010
From: INVALID.NOREPLY at gnu.org (Simon Josefsson)
Date: Thu, 30 Dec 2010 12:46:39 +0000
Subject: [sr #107560] libextra/openssl.h conflicts with wincrypt.h
In-Reply-To: <20101226-024025.sv74148.29875@savannah.gnu.org>
References: <20101226-024025.sv74148.29875@savannah.gnu.org>
Message-ID: <20101230-124638.sv7213.2817@savannah.gnu.org>


Update of sr #107560 (project gnutls):

                  Status:                    None => Confirmed              
             Assigned to:                    None => jas                    

    _______________________________________________________

Follow-up Comment #1:

Renaming the variable is not an option -- this is for the OpenSSL emulation,
and if we rename it, we are not emulating OpenSSL properly.

You want to build with --disable-openssl-compatibility to avoid building the
OpenSSL emulation stuff at all.

I'll think about the gnutls_int.h workaround, so I'm leaving the report
open.

/Simon

    _______________________________________________________

Reply to this item at:

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

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




From gnubug at bsls.de  Fri Dec 31 01:35:41 2010
From: gnubug at bsls.de (Heiko Berges)
Date: Fri, 31 Dec 2010 00:35:41 +0000
Subject: configure -- braindead failure message
Message-ID: <20101231003540.GA21298@bsls.de>

Hi,

I'd expect that at least GNU people themself would know how to use
autoconf, espacially how to design the tests and errormessages in 
a way so they resamble the problem:

# (blahblah)
# | #include <gcrypt.h>
# | int
# | main ()
# | {
# | enum gcry_cipher_algos i = GCRY_CIPHER_CAMELLIA128
# |   ;
# |   return 0;
# | }
# configure:7485: result: no
# configure:7516: error:
# ***
# *** libgcrypt was not found. You may want to get it from
# *** ftp://ftp.gnupg.org/gcrypt/libgcrypt/  
# ***

Wrong.

# $ libgcrypt-config --version
# 1.2.0

Too old, probably.  Doesn't know about CAMELLIA, in fact.   But I
will never know, if you use a new feature to test for the existence 
of library.

As always autoconf neither spare time nor diskspace and probably
makes it harder to compile instead of easier (as it really did
eight or ten years ago.)  These days it seems to be a tool to
prevent compilation on systems the developers don't care about.


	regards,
	Heiko



From bradh at frogmouth.net  Fri Dec 31 07:09:41 2010
From: bradh at frogmouth.net (Brad Hards)
Date: Fri, 31 Dec 2010 17:09:41 +1100
Subject: configure -- braindead failure message
In-Reply-To: <20101231003540.GA21298@bsls.de>
References: <20101231003540.GA21298@bsls.de>
Message-ID: <201012311709.41421.bradh@frogmouth.net>

On Friday, December 31, 2010 11:35:41 am Heiko Berges wrote:
> resamble
You spelt resemble incorrectly.

Brad