From simon at josefsson.org  Wed Oct  1 12:25:54 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 01 Oct 2008 12:25:54 +0200
Subject: draft release notes for 2.6.0, final call for bugfixes
In-Reply-To: <87hc8g5kpo.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Tue, 16 Sep 2008 14:38:59 +0200")
References: <87hc8g5kpo.fsf@mocca.josefsson.org>
Message-ID: <87myhopq6l.fsf@mocca.josefsson.org>

Below are updated draft release notes that takes into account what
happened in recent 2.5.x releases.

Please read and comment, we'll publish it when I get back on Monday!

Btw, if you have time, please test the 2.5.9 release more as it right
now the 2.6.0 will be exactly identical to it (modulo version number):
http://alpha.gnu.org/gnu/gnutls/gnutls-2.5.9.tar.bz2

If 2.5.9 is not working as you would like the final 2.6.0 to work, now
is the time to say so!

/Simon

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

GnuTLS is a modern C library that implement 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.2 (or later).

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

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

Major end-user visible changes compared to the v2.4 branch:

** certtool: updated so it can add several subject alternative names using
the template file.

** opencdk: Parse (but not decrypt) encrypted secret keys.
Contributed by Daniel Kahn Gillmor <dkg at fifthhorseman.net>.

** libgnutls: Remove code to import certificate chains in PKCS#7 format.
The code has not worked since v0.9.0 and apparently nobody has missed
it, so we decided to remove the code rather than fix it.  If you have
old certificate chains stored in PKCS#7 format, you can convert them
to a list of PEM certificates by using 'certtool --p7-info'.  Reported
by Christian Grothoff <christian at grothoff.org>.

** gnutls-cli: Improve --list output to include public key and signature algs.

** gnutls-cli, gnutls-serv: Remove --copyright parameter.
Use standard --version to get license info.

** The main manual and the GTK-DOC API documentation have been improved.

** Uses autoconf 2.63, automake 1.10.1, libtool 2.2.6a.

Major developer visible changes compared to the v2.4 branch:

** Added API to replace and update the crypto backend.
The header gnutls/crypto.h is now officially supported, and declares
the symbols below.
gnutls_crypto_bigint_register2: ADDED.
gnutls_crypto_cipher_register2: ADDED.
gnutls_crypto_digest_register2: ADDED.
gnutls_crypto_mac_register2: ADDED.
gnutls_crypto_pk_register2: ADDED.
gnutls_crypto_rnd_register2: ADDED.
gnutls_crypto_single_cipher_register2: ADDED.
gnutls_crypto_single_digest_register2: ADDED.
gnutls_crypto_single_mac_register2: ADDED.

** libgnutls: gnutls_x509_crt_set_subject_alt_name() was added that can
either set or append alternative names. It can also handle binary structures
such as IP addresses.

** libgnutls: New function to set minimum acceptable SRP bits.
The function is gnutls_srp_set_prime_bits.  Tiny patch by Kevin Quick
<quick at sparq.org> in <https://savannah.gnu.org/support/index.php?106454>.

** libgnutls: Add interface to deal with public key and signature algorithms.
The functions are called gnutls_pk_list, gnutls_pk_get_id,
gnutls_sign_list, and gnutls_sign_get_id.  Suggested by Sam
Varshavchik <mrsam at courier-mta.com>.

** libgnutls: New interfaces to get name of public key and signing algorithms.
The functions are gnutls_sign_get_name and gnutls_pk_get_name.

** libgnutls: New API to get a string corresponding to a error symbol.
The function is gnutls_strerror_name.

** libgnutls: New API to set the public parameters in a certificate request
** from a private key.
The function is gnutls_x509_crq_set_key_rsa_raw.  Inspired by
discussion with "Zach C." <fxchip at gmail.com>.

** libgnutls: New API to set a callback to extract TLS Finished data.
The function to register is gnutls_session_set_finished_function and
it takes a callback of the gnutls_finished_callback_func type.

** libgnutls: Fix namespace problem with TLS_MASTER_SIZE and TLS_RANDOM_SIZE.
The new names are GNUTLS_MASTER_SIZE and GNUTLS_RANDOM_SIZE.  The old
names are mapped to the new names in compat.h.  These mappings will
likely be removed more quickly than other mappings in that file due to
the namespace violation.

** libgnutls: New interface to register a new TLS extension handler.
The new function gnutls_ext_register can be used to register handlers
for specific TLS extension types.  The callback functions have the new
types gnutls_ext_recv_func and gnutls_ext_send_func.  A type to
classify TLS extensions, gnutls_ext_parse_type_t, has been added as
well.

** Opencdk: Add calls to gnutls_assert to ease debugging.

** libgnutls-extra: Add function to work with Libgcrypt in FIPS mode.
The function is gnutls_register_md5_handler.  When libgcrypt is in
FIPS mode, MD5 is disabled, but TLS normally requires use of MD5 in
the PRF.

Of course, many smaller fixes have been made, see the ChangeLog file.

API/ABI changes in GnuTLS 2.6
=============================

No functions have been removed or modified.  The library should be
fully backwards compatible on both the source and binary level.

A new header file 'gnutls/crypto.h' have been added.  It contains
definitions related to replacing the internal crypto functionality.
All definitions and the header itself is experimental but supported.

We have realized that the symbols TLS_MASTER_SIZE and TLS_RANDOM_SIZE
does not use the normal namespace.  We have added GNUTLS_MASTER_SIZE
and GNUTLS_RANDOM_SIZE, but the old symbols are still defined.

The following functions have been added to libgnutls:

GNUTLS_MASTER_SIZE
GNUTLS_RANDOM_SIZE
gnutls_crypto_bigint_register2
gnutls_crypto_cipher_register2
gnutls_crypto_digest_register2
gnutls_crypto_mac_register2
gnutls_crypto_pk_register2
gnutls_crypto_rnd_register2
gnutls_crypto_single_cipher_register2
gnutls_crypto_single_digest_register2
gnutls_crypto_single_mac_register2
gnutls_ext_register
gnutls_pk_get_id
gnutls_pk_get_name
gnutls_pk_list
gnutls_session_set_finished_function
gnutls_sign_get_id
gnutls_sign_get_name
gnutls_sign_list
gnutls_srp_set_prime_bits:
gnutls_strerror_name
gnutls_x509_crq_set_key_rsa_raw
gnutls_x509_crt_set_crl_dist_points2
gnutls_x509_crt_set_subject_alt_name

The following functions have been added to libgnutls-extra:

gnutls_register_md5_handler:

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

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

Here are the BZIP2 compressed sources (4.9MB):

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

Here are OpenPGP detached signatures signed using key 0xB565716F:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.6.0.tar.bz2.sig
  http://ftp.gnu.org/gnu/gnutls/gnutls-2.6.0.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.6.0.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: 2009-04-21]
      Key fingerprint = 0424 D4EE 81A0 E3D1 19C6  F835 EDA2 1E94 B565 716F
uid                  Simon Josefsson <simon at josefsson.org>
uid                  Simon Josefsson <jas at extundo.com>
sub   1280R/4D5D40AE 2002-05-05 [expires: 2009-04-21]

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:

9bb3be9f2ad67037d3a571bec4fac65e0ffbadbb  gnutls-2.6.0.tar.bz2

9dc4435b637a4841a88ec294b8a82841eb257cee4948bc957c1a96d7  gnutls-2.6.0.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:

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

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.gnupg.org/mailman/listinfo/gnutls-dev

Windows installer
=================

GnuTLS has been ported to the Windows operating system, and a binary
installer is available.  The installer contains DLLs for application
development, manuals, examples, and source code.  The installer uses
libgpg-error v1.6, libgcrypt v1.4.3, libtasn1 v1.5, and GnuTLS v2.6.0.

For more information about GnuTLS for Windows:
  http://josefsson.org/gnutls4win/

The Windows binary installer and PGP signature:
  http://josefsson.org/gnutls4win/gnutls-2.6.0.exe (14MB)
  http://josefsson.org/gnutls4win/gnutls-2.6.0.exe.sig

The checksum values for SHA-1 and SHA-224 are:

e704df715ed6cad14c7a6e4350d7557d81de655b  gnutls-2.6.0.exe

b548c3178f89669d1245b266c7caa834feeea63b142a8871f1185097  gnutls-2.6.0.exe

Thanks to Enrico Tassi, we also have mingw32 *.deb's available:
  http://josefsson.org/gnutls4win/mingw32-gnutls_2.3.15-1_all.deb

The checksum values for SHA-1 and SHA-224 are:

3fc1e58fe58ac77c6dc433052685d59400a88559  mingw32-gnutls_2.6.0-1_all.deb

601549a449ce25dc4520c591bad42d833b23f05a8f67cf4fe732f7de  mingw32-gnutls_2.6.0-1_all.deb

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

GnuTLS messages have been translated into Dutch, French, German,
Malay, Polish, 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, 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




From davefx at gmail.com  Thu Oct  2 18:53:06 2008
From: davefx at gmail.com (=?UTF-8?Q?David_Mar=C3=ADn_Carre=C3=B1o?=)
Date: Thu, 2 Oct 2008 18:53:06 +0200
Subject: How to set CRL number, and authority key id extensions.
Message-ID: <f43cca2f0810020953q591ad4aeg896af81504d74aec@mail.gmail.com>

Hi all.

I'm the main developer of gnoMint, a graphical Certification Authority
managing tool.

I would like to set authority key id extension, and number extension,
for each one of the created CRLs.

Currently, the generated CRLs are not compliant with RFC5280, as it
says in pages 60 and 61, that these extensions are a MUST for CRLs
made by complying CAs.

Do you plan to include CRL extensions?

Greetings.

-- 
David Mar?n Carre?o

From nmav at gnutls.org  Fri Oct  3 20:06:19 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 03 Oct 2008 21:06:19 +0300
Subject: How to set CRL number, and authority key id extensions.
In-Reply-To: <f43cca2f0810020953q591ad4aeg896af81504d74aec@mail.gmail.com>
References: <f43cca2f0810020953q591ad4aeg896af81504d74aec@mail.gmail.com>
Message-ID: <48E65F1B.3090602@gnutls.org>

David Mar?n Carre?o wrote:
> Hi all.
> 
> I'm the main developer of gnoMint, a graphical Certification Authority
> managing tool.
> 
> I would like to set authority key id extension, and number extension,
> for each one of the created CRLs.
> 
> Currently, the generated CRLs are not compliant with RFC5280, as it
> says in pages 60 and 61, that these extensions are a MUST for CRLs
> made by complying CAs.
> Do you plan to include CRL extensions?

Hello David,
 Both the CRL and CRQ interfaces were based on very old RFCs thus they
don't contain the functionality you requested. I'll check how easy it is
to add what you requested and let you know. In general it would be very
helpful if, like you did now, provide references and specific requests
to functionality you request.

regards,
Nikos




From n.mavrogiannopoulos at gmail.com  Fri Oct  3 22:24:35 2008
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Fri, 03 Oct 2008 23:24:35 +0300
Subject: How to set CRL number, and authority key id extensions.
In-Reply-To: <48E65F1B.3090602@gnutls.org>
References: <f43cca2f0810020953q591ad4aeg896af81504d74aec@mail.gmail.com>
	<48E65F1B.3090602@gnutls.org>
Message-ID: <48E67F83.6050505@gmail.com>

Nikos Mavrogiannopoulos wrote:
> David Mar?n Carre?o wrote:
>> Hi all.
>>
>> I'm the main developer of gnoMint, a graphical Certification Authority
>> managing tool.
>>
>> I would like to set authority key id extension, and number extension,
>> for each one of the created CRLs.
>>
>> Currently, the generated CRLs are not compliant with RFC5280, as it
>> says in pages 60 and 61, that these extensions are a MUST for CRLs
>> made by complying CAs.
>> Do you plan to include CRL extensions?

I have checked the issue and it seems that most of the functionality
already existed for CRL extension handling. I have commited a patch on
the current code base which adds this support. This is not a big change,
since it only adds functions, however it is up to Simon to decide on
whether this will be included on the upcoming release.

regards,
Nikos




From nmav at gnutls.org  Sat Oct  4 18:58:15 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 04 Oct 2008 19:58:15 +0300
Subject: pkcs #10 requests
Message-ID: <48E7A0A7.6010406@gnutls.org>

Following the thread for request to add certain X.509v3 extensions such
as alternative name to certificate requests (pkcs #10 that is), I have
noticed that in PKCS #9 they define a way to insert those extensions as
a PKCS #10 attribute. I've added support for this, thus in the
repository gnutls can generate and parse extensions from certificate
request (CRQ) files. Moreover I have included the additions suggested by
David Marin Carreno to support certain extensions in the CRL files. I'd
appreciate testing and feedback.

regards,
Nikos




From simon at josefsson.org  Sun Oct  5 16:36:41 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Sun, 05 Oct 2008 16:36:41 +0200
Subject: How to set CRL number, and authority key id extensions.
In-Reply-To: <48E67F83.6050505@gmail.com> (Nikos Mavrogiannopoulos's message
	of "Fri, 03 Oct 2008 23:24:35 +0300")
References: <f43cca2f0810020953q591ad4aeg896af81504d74aec@mail.gmail.com>
	<48E65F1B.3090602@gnutls.org> <48E67F83.6050505@gmail.com>
Message-ID: <87od1zcdmu.fsf@mocca.josefsson.org>

Nikos Mavrogiannopoulos <n.mavrogiannopoulos at gmail.com> writes:

> Nikos Mavrogiannopoulos wrote:
>> David Mar?n Carre?o wrote:
>>> Hi all.
>>>
>>> I'm the main developer of gnoMint, a graphical Certification Authority
>>> managing tool.
>>>
>>> I would like to set authority key id extension, and number extension,
>>> for each one of the created CRLs.
>>>
>>> Currently, the generated CRLs are not compliant with RFC5280, as it
>>> says in pages 60 and 61, that these extensions are a MUST for CRLs
>>> made by complying CAs.
>>> Do you plan to include CRL extensions?
>
> I have checked the issue and it seems that most of the functionality
> already existed for CRL extension handling. I have commited a patch on
> the current code base which adds this support. This is not a big change,
> since it only adds functions, however it is up to Simon to decide on
> whether this will be included on the upcoming release.

It is really too late for 2.6.x, I want to release tomorrow.  There is
no reason why we couldn't have a short gnutls 2.7.x cycle though, I'm
not aware of any major pending changes?  We could set a release goal for
2.8.x on January 1th.

/Simon




From simon at josefsson.org  Mon Oct  6 09:48:57 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 06 Oct 2008 09:48:57 +0200
Subject: GnuTLS 2.6.0
Message-ID: <87myhitb86.fsf@mocca.josefsson.org>

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

GnuTLS is a modern C library that implement 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.2 (or later).

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

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

Major end-user visible changes compared to the v2.4 branch:

** certtool: updated so it can add several subject alternative names using
the template file.

** opencdk: Parse (but not decrypt) encrypted secret keys.
Contributed by Daniel Kahn Gillmor <dkg at fifthhorseman.net>.

** libgnutls: Remove code to import certificate chains in PKCS#7 format.
The code has not worked since v0.9.0 and apparently nobody has missed
it, so we decided to remove the code rather than fix it.  If you have
old certificate chains stored in PKCS#7 format, you can convert them
to a list of PEM certificates by using 'certtool --p7-info'.  Reported
by Christian Grothoff <christian at grothoff.org>.

** gnutls-cli: Improve --list output to include public key and signature algs.

** gnutls-cli, gnutls-serv: Remove --copyright parameter.
Use standard --version to get license info.

** The main manual and the GTK-DOC API documentation have been improved.

** Uses autoconf 2.63, automake 1.10.1, libtool 2.2.6a.

Major developer visible changes compared to the v2.4 branch:

** Added API to replace and update the crypto backend.
The header gnutls/crypto.h is now officially supported, and declares
the symbols below.
gnutls_crypto_bigint_register2: ADDED.
gnutls_crypto_cipher_register2: ADDED.
gnutls_crypto_digest_register2: ADDED.
gnutls_crypto_mac_register2: ADDED.
gnutls_crypto_pk_register2: ADDED.
gnutls_crypto_rnd_register2: ADDED.
gnutls_crypto_single_cipher_register2: ADDED.
gnutls_crypto_single_digest_register2: ADDED.
gnutls_crypto_single_mac_register2: ADDED.

** libgnutls: gnutls_x509_crt_set_subject_alt_name() was added that can
either set or append alternative names. It can also handle binary structures
such as IP addresses.

** libgnutls: New function to set minimum acceptable SRP bits.
The function is gnutls_srp_set_prime_bits.  Tiny patch by Kevin Quick
<quick at sparq.org> in <https://savannah.gnu.org/support/index.php?106454>.

** libgnutls: Add interface to deal with public key and signature algorithms.
The functions are called gnutls_pk_list, gnutls_pk_get_id,
gnutls_sign_list, and gnutls_sign_get_id.  Suggested by Sam
Varshavchik <mrsam at courier-mta.com>.

** libgnutls: New interfaces to get name of public key and signing algorithms.
The functions are gnutls_sign_get_name and gnutls_pk_get_name.

** libgnutls: New API to get a string corresponding to a error symbol.
The function is gnutls_strerror_name.

** libgnutls: New API to set the public parameters in a certificate request
** from a private key.
The function is gnutls_x509_crq_set_key_rsa_raw.  Inspired by
discussion with "Zach C." <fxchip at gmail.com>.

** libgnutls: New API to set a callback to extract TLS Finished data.
The function to register is gnutls_session_set_finished_function and
it takes a callback of the gnutls_finished_callback_func type.

** libgnutls: Fix namespace problem with TLS_MASTER_SIZE and TLS_RANDOM_SIZE.
The new names are GNUTLS_MASTER_SIZE and GNUTLS_RANDOM_SIZE.  The old
names are mapped to the new names in compat.h.  These mappings will
likely be removed more quickly than other mappings in that file due to
the namespace violation.

** libgnutls: New interface to register a new TLS extension handler.
The new function gnutls_ext_register can be used to register handlers
for specific TLS extension types.  The callback functions have the new
types gnutls_ext_recv_func and gnutls_ext_send_func.  A type to
classify TLS extensions, gnutls_ext_parse_type_t, has been added as
well.

** Opencdk: Add calls to gnutls_assert to ease debugging.

** libgnutls-extra: Add function to work with Libgcrypt in FIPS mode.
The function is gnutls_register_md5_handler.  When libgcrypt is in
FIPS mode, MD5 is disabled, but TLS normally requires use of MD5 in
the PRF.

Of course, many smaller fixes have been made, see the ChangeLog file.

API/ABI changes in GnuTLS 2.6
=============================

No functions have been removed or modified.  The library should be
fully backwards compatible on both the source and binary level.

A new header file <gnutls/crypto.h> have been added.  It contains
definitions related to replacing the internal crypto functionality.
All definitions and the header itself is experimental but supported.

We have realized that the symbols TLS_MASTER_SIZE and TLS_RANDOM_SIZE
does not use the normal namespace.  We have added GNUTLS_MASTER_SIZE
and GNUTLS_RANDOM_SIZE, but the old symbols are still defined.

The following functions have been added to libgnutls:

GNUTLS_MASTER_SIZE
GNUTLS_RANDOM_SIZE
gnutls_crypto_bigint_register2
gnutls_crypto_cipher_register2
gnutls_crypto_digest_register2
gnutls_crypto_mac_register2
gnutls_crypto_pk_register2
gnutls_crypto_rnd_register2
gnutls_crypto_single_cipher_register2
gnutls_crypto_single_digest_register2
gnutls_crypto_single_mac_register2
gnutls_ext_register
gnutls_pk_get_id
gnutls_pk_get_name
gnutls_pk_list
gnutls_session_set_finished_function
gnutls_sign_get_id
gnutls_sign_get_name
gnutls_sign_list
gnutls_srp_set_prime_bits:
gnutls_strerror_name
gnutls_x509_crq_set_key_rsa_raw
gnutls_x509_crt_set_crl_dist_points2
gnutls_x509_crt_set_subject_alt_name

The following functions have been added to libgnutls-extra:

gnutls_register_md5_handler

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

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

Here are the BZIP2 compressed sources (4.9MB):

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

Here are OpenPGP detached signatures signed using key 0xB565716F:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.6.0.tar.bz2.sig
  http://ftp.gnu.org/gnu/gnutls/gnutls-2.6.0.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.6.0.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: 2009-04-21]
      Key fingerprint = 0424 D4EE 81A0 E3D1 19C6  F835 EDA2 1E94 B565 716F
uid                  Simon Josefsson <simon at josefsson.org>
uid                  Simon Josefsson <jas at extundo.com>
sub   1280R/4D5D40AE 2002-05-05 [expires: 2009-04-21]

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:

bbd9e5f3a77bfcbef5a769c67d1576e7a6e4bda5  gnutls-2.6.0.tar.bz2

c8b42e979224051e756bd0a9c37da54ef19f49f47f18f741e3c33c56  gnutls-2.6.0.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:

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

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.gnupg.org/mailman/listinfo/gnutls-dev

Windows installer
=================

GnuTLS has been ported to the Windows operating system, and a binary
installer is available.  The installer contains DLLs for application
development, manuals, examples, and source code.  The installer uses
libgpg-error v1.6, libgcrypt v1.4.3, libtasn1 v1.5, and GnuTLS v2.6.0.

For more information about GnuTLS for Windows:
  http://josefsson.org/gnutls4win/

The Windows binary installer and PGP signature:
  http://josefsson.org/gnutls4win/gnutls-2.6.0.exe (14MB)
  http://josefsson.org/gnutls4win/gnutls-2.6.0.exe.sig

The checksum values for SHA-1 and SHA-224 are:

305efcd1515dc8c4e3b0b2caa5cfe4436b74c09d  gnutls-2.6.0.exe

5a2971b672d50e3c384e78a334002f4c04d63e9eae49dc5d28a84b4d  gnutls-2.6.0.exe

Thanks to Enrico Tassi, we also have mingw32 *.deb's available:
  http://josefsson.org/gnutls4win/mingw32-gnutls_2.3.15-1_all.deb

The checksum values for SHA-1 and SHA-224 are:

cde730b75340676f5149afda9a0d8556131f47a8  mingw32-gnutls_2.6.0-1_all.deb

8eb3d88360da079b86eec549ba41111acc7be5b8a375eee08f4bf848  mingw32-gnutls_2.6.0-1_all.deb

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

GnuTLS messages have been translated into Dutch, French, German,
Malay, Polish, 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, 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: 419 bytes
Desc: not available
URL: </pipermail/attachments/20081006/0a06b153/attachment.pgp>

From simon at josefsson.org  Tue Oct  7 14:53:42 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 07 Oct 2008 14:53:42 +0200
Subject: OWASP talk and Cyclomatic Code Complexity
Message-ID: <87d4icwoq1.fsf@mocca.josefsson.org>

FYI, I gave a talk about open source security processes for the Swedish
OWASP chapter yesterday, see:

http://josefsson.org/talks/owasp-sec.pdf

One consequence of that is that I have made some cyclomatic code
complexity charts for GnuTLS available, see:

http://josefsson.org/cyclo/
http://josefsson.org/cyclo/cyclo-gnutls.html

Two of our security advisories have been in one of the top-five most
complicated functions, so performing code review on more complex
functions may be fruitful.

I've blogged about it too:
http://blog.josefsson.org/2008/10/07/cyclomatic-code-complexity/

/Simon




From ludo at gnu.org  Tue Oct  7 18:04:51 2008
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Tue, 07 Oct 2008 18:04:51 +0200
Subject: GnuTLS 2.6.0
References: <87myhitb86.fsf@mocca.josefsson.org>
Message-ID: <87od1wl7bw.fsf@gnu.org>

Hi,

The attached patch fixes compilation of the `pkcs12-decode' test in
2.6.0 when using minitasn1.

Thanks,
Ludo'.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Fix-compilation-of-pkcs12-decode-test-when-using-m.patch
Type: text/x-patch
Size: 1013 bytes
Desc: The patch
URL: </pipermail/attachments/20081007/fab843a3/attachment.bin>

From simon at josefsson.org  Tue Oct  7 19:35:07 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 07 Oct 2008 19:35:07 +0200
Subject: GnuTLS 2.6.0
In-Reply-To: <87od1wl7bw.fsf@gnu.org> ("Ludovic =?iso-8859-1?Q?Court=E8s?=
	=?iso-8859-1?Q?=22's?= message of "Tue, 07
	Oct 2008 18:04:51 +0200")
References: <87myhitb86.fsf@mocca.josefsson.org> <87od1wl7bw.fsf@gnu.org>
Message-ID: <873aj8ux4k.fsf@mocca.josefsson.org>

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

> Hi,
>
> The attached patch fixes compilation of the `pkcs12-decode' test in
> 2.6.0 when using minitasn1.

Hi!  As far as I can tell, the LDADD should not be necessary,
libminitasn1.la should be linked together with libgnutls.la.  Could you
check if only adding the -I solves the problem?

Thanks,
Simon

> From bd887245be3448b8d5e87015b1c04848e7c10c95 Mon Sep 17 00:00:00 2001
> From: =?utf-8?q?Ludovic=20Court=C3=A8s?= <ludo at gnu.org>
> Date: Tue, 7 Oct 2008 18:02:25 +0200
> Subject: [PATCH] Fix compilation of `pkcs12-decode' test when using minitasn1.
>
> * tests/pkcs12-decode/Makefile.am (AM_CPPFLAGS)[ENABLE_MINITASN1]: Add
>   `minitasn1' include directory.
>   (LDADD)[ENABLE_MINITASN1]: Likewise.
> ---
>  tests/pkcs12-decode/Makefile.am |    6 ++++++
>  1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/tests/pkcs12-decode/Makefile.am b/tests/pkcs12-decode/Makefile.am
> index 8a62aee..80eb7ef 100644
> --- a/tests/pkcs12-decode/Makefile.am
> +++ b/tests/pkcs12-decode/Makefile.am
> @@ -36,3 +36,9 @@ AM_CPPFLAGS = -I$(top_srcdir)/lgl -I$(top_builddir)/lgl 		\
>  AM_LDFLAGS = -no-install
>  LDADD = ../../lib/libgnutls.la ../../gl/libgnu.la ../../lgl/liblgnu.la ../libutils.la
>  
> +if ENABLE_MINITASN1
> +
> +AM_CPPFLAGS += -I$(top_srcdir)/lib/minitasn1
> +LDADD += $(top_builddir)/lib/minitasn1/libminitasn1.la
> +
> +endif
> -- 
> 1.6.0
>
> _______________________________________________
> Gnutls-devel mailing list
> Gnutls-devel at gnu.org
> http://lists.gnu.org/mailman/listinfo/gnutls-devel




From ludo at gnu.org  Tue Oct  7 19:56:00 2008
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Tue, 07 Oct 2008 19:56:00 +0200
Subject: GnuTLS 2.6.0
References: <87myhitb86.fsf@mocca.josefsson.org> <87od1wl7bw.fsf@gnu.org>
	<873aj8ux4k.fsf@mocca.josefsson.org>
Message-ID: <873aj8e1cf.fsf@gnu.org>

Hello,

Simon Josefsson <simon at josefsson.org> writes:

> Hi!  As far as I can tell, the LDADD should not be necessary,
> libminitasn1.la should be linked together with libgnutls.la.  Could you
> check if only adding the -I solves the problem?

You're right, I added it just in case.  Here's the new patch.

Thanks,
Ludo'.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Fix-compilation-of-pkcs12-decode-test-when-using-m.patch
Type: text/x-patch
Size: 917 bytes
Desc: The patch.
URL: </pipermail/attachments/20081007/e22a7ee6/attachment.bin>

From simon at josefsson.org  Tue Oct  7 20:08:14 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 07 Oct 2008 20:08:14 +0200
Subject: GnuTLS 2.6.0
In-Reply-To: <873aj8e1cf.fsf@gnu.org> ("Ludovic =?iso-8859-1?Q?Court=E8s?=
	=?iso-8859-1?Q?=22's?= message of "Tue, 07
	Oct 2008 19:56:00 +0200")
References: <87myhitb86.fsf@mocca.josefsson.org> <87od1wl7bw.fsf@gnu.org>
	<873aj8ux4k.fsf@mocca.josefsson.org> <873aj8e1cf.fsf@gnu.org>
Message-ID: <87r66sth0x.fsf@mocca.josefsson.org>

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

> Hello,
>
> Simon Josefsson <simon at josefsson.org> writes:
>
>> Hi!  As far as I can tell, the LDADD should not be necessary,
>> libminitasn1.la should be linked together with libgnutls.la.  Could you
>> check if only adding the -I solves the problem?
>
> You're right, I added it just in case.  Here's the new patch.

Pushed, thank you!  I back-ported it to v2.6.x as well.

/Simon




From ludo at gnu.org  Tue Oct  7 21:10:27 2008
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Tue, 07 Oct 2008 21:10:27 +0200
Subject: GnuTLS 2.6.0
References: <87myhitb86.fsf@mocca.josefsson.org> <87od1wl7bw.fsf@gnu.org>
	<873aj8ux4k.fsf@mocca.josefsson.org> <873aj8e1cf.fsf@gnu.org>
	<87r66sth0x.fsf@mocca.josefsson.org>
Message-ID: <87r66scjbw.fsf@gnu.org>

Simon Josefsson <simon at josefsson.org> writes:

> Pushed, thank you!  I back-ported it to v2.6.x as well.

I had forgotten another one (attached).

Thanks!

Ludo'.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-More-test-compilation-fixes-with-minitasn1.patch
Type: text/x-patch
Size: 872 bytes
Desc: The patch
URL: </pipermail/attachments/20081007/c533b833/attachment.bin>

From aleksander at es.gnu.org  Tue Oct  7 21:26:40 2008
From: aleksander at es.gnu.org (Aleksander Morgado)
Date: Tue, 07 Oct 2008 21:26:40 +0200
Subject: Tickets in Trac
Message-ID: <48EBB7F0.9040700@es.gnu.org>

Hi all,

I guess you should disable the ability to add new tickets in your Trac 
to anonymous users...

http://trac.gnutls.org/cgi-bin/trac.cgi/report/1

It's full of spam.

Cheers,
-Aleksander




From simon at josefsson.org  Tue Oct  7 21:46:04 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 07 Oct 2008 21:46:04 +0200
Subject: GnuTLS 2.6.0
In-Reply-To: <87r66scjbw.fsf@gnu.org> ("Ludovic =?iso-8859-1?Q?Court=E8s?=
	=?iso-8859-1?Q?=22's?= message of "Tue, 07
	Oct 2008 21:10:27 +0200")
References: <87myhitb86.fsf@mocca.josefsson.org> <87od1wl7bw.fsf@gnu.org>
	<873aj8ux4k.fsf@mocca.josefsson.org> <873aj8e1cf.fsf@gnu.org>
	<87r66sth0x.fsf@mocca.josefsson.org> <87r66scjbw.fsf@gnu.org>
Message-ID: <87ej2stchv.fsf@mocca.josefsson.org>

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

> Simon Josefsson <simon at josefsson.org> writes:
>
>> Pushed, thank you!  I back-ported it to v2.6.x as well.
>
> I had forgotten another one (attached).

Pushed as well, thank you.

/Simon




From teddy at fukt.bsnet.se  Wed Oct  8 03:26:11 2008
From: teddy at fukt.bsnet.se (Teddy Hogeborn)
Date: Wed, 08 Oct 2008 03:26:11 +0200
Subject: Announcement: Yet another GnuTLS-using program: Mandos
Message-ID: <87ljwzc1xo.fsf@tower.fukt.bsnet.se>

(The web page <http://www.gnu.org/software/gnutls/programs.html> says
"Please contact us at bug-gnutls at gnu.org to notify us about other
programs that use gnutls.", so I'm sending this there as well.)

Hi there; I just wanted all you GnuTLS folks to know about our project
Mandos' slightly unusual use of GnuTLS.

The goal of the Mandos system is to enable server computers to have an
encrypted root file system and still be able to reboot automatically
without anyone having to be there and type in a password.

What happens is that we run a small Mandos client program at boot time
in the initial RAM disk environment (initrd), before even networking
is configured, using IPv6 link-local addresses.

The Mandos client connects to the Mandos server.  The Mandos clients
each have an OpenPGP key, which they use to handshake as TLS *servers*
to the Mandos server, which in turn handshakes as a TLS *client*.  The
Mandos server does not have a key, but computes the fingerprint of the
OpenPGP key received from the Mandos client and looks up that
fingerprint in an internal list, and, if the fingerprint is found,
sends the corresponding binary blob to the client.

(This binary blob is an OpenPGP-encrypted password necessary to unlock
the client's root file system, but this is no longer GnuTLS-related.)

(The server is written in Python, and uses the python-gnutls library
from <http://pypi.python.org/pypi/python-gnutls>.)

Oh yes, the project's home page:  http://www.fukt.bsnet.se/mandos

I just thought you might find it interesting.

/Teddy, Mandos Maintainer Team




From Jeff.Cai at Sun.COM  Wed Oct  8 13:25:59 2008
From: Jeff.Cai at Sun.COM (Jeff Cai)
Date: Wed, 08 Oct 2008 19:25:59 +0800
Subject: Which license is libtasn1-config?
Message-ID: <48EC98C7.30104@sun.com>

Hi, Simon

I'm confused that though libtasn1 is licensed under LGPLv2, then does it 
mean libtasn1-config also is licensed under LGPLv2?

 If not, then what is its license? GPLv3 or LGPLv2?

thanks

Jeff




From simon at josefsson.org  Wed Oct  8 14:09:12 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 08 Oct 2008 14:09:12 +0200
Subject: Which license is libtasn1-config?
In-Reply-To: <48EC98C7.30104@sun.com> (Jeff Cai's message of "Wed, 08 Oct 2008
	19:25:59 +0800")
References: <48EC98C7.30104@sun.com>
Message-ID: <87wsgjffvb.fsf@mocca.josefsson.org>

Jeff Cai <Jeff.Cai at Sun.COM> writes:

> Hi, Simon
>
> I'm confused that though libtasn1 is licensed under LGPLv2, then does
> it mean libtasn1-config also is licensed under LGPLv2?
>
> If not, then what is its license? GPLv3 or LGPLv2?

Hi.  Actually, I cannot find a license header in libtasn1-config.in, so
I'm equally confused.

Normally build infrastructure stuff is GPLv3, so using that would be
close at hand.  Alternatively, the all-permissive license used for other
autoconf-related files may be used.  I noticed that libgcrypt uses it.

However, I would prefer to get rid of the *-config scripts.  The idea
behind *-config scripts is against the normal autoconf-approach to test
for features, and works poorly in corner cases.  Even if some users
prefers that model rather than the normal autoconf-approach, libtasn1
supports pkg-config.  Pkg-config is at least widely used, and the M4
code for it is likely more correct than libtasn1.m4.  People have
probably adapted pkg-config for some corner cases before us.

So let me propose that we remove libtasn1-config and libtasn1.m4 from
libtasn1.  Instead, we recommend developers to use the normal
autoconf-machinery to test for libraries, or if they don't like that,
that they use pkg-config.

Thoughts?

/Simon




From simon at josefsson.org  Wed Oct  8 14:44:59 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 08 Oct 2008 14:44:59 +0200
Subject: Which license is libtasn1-config?
In-Reply-To: <48ECA6BC.5040701@sun.com> (Jeff Cai's message of "Wed, 08 Oct
	2008 20:25:32 +0800")
References: <48EC98C7.30104@sun.com> <87wsgjffvb.fsf@mocca.josefsson.org>
	<48ECA6BC.5040701@sun.com>
Message-ID: <87od1vfe7o.fsf@mocca.josefsson.org>

Jeff Cai <Jeff.Cai at Sun.COM> writes:

> Sun couldn't ship those files under GPLv3, so if we can't make sure
> whether it is under GPLv3, maybe we have to change the package on
> Solaris.
> But since all files under libtasn1/lib are under LGPLv2, can I assume
> it is under LGPLv2 also?

I don't think anyone will sue you over making that assumption.

> Since version 1.0, some source code has been changed to GPLv3.  As the
> current maintainer, could you also give me an answer about its
> license?

Right now the file doesn't seem to have a clear license.  The
_intention_ was most likely LGPLv2.1+, but it was never encoded
anywhere.

> And if you can't give me an confirmed answer, do you know who changed
> the license to GPLv3 and Can I contact him directly?

I changed the license from GPLv2+ to GPLv3+ on those parts that used
GPLv2+ before.

According to the vc logs, Nikos added libtasn1-config back in 2004.  You
could ask him for the license.  However, I suspect the files were
derived from somewhere else (GnuTLS?  Which in turn may have derived
them from libgcrypt?) so that may require chasing the authors further.

I believe the simplest solution is to remove these files.

/Simon


> Thanks
>
> Jeff
>
> Simon Josefsson wrote:
>> Jeff Cai <Jeff.Cai at Sun.COM> writes:
>>
>>   
>>> Hi, Simon
>>>
>>> I'm confused that though libtasn1 is licensed under LGPLv2, then does
>>> it mean libtasn1-config also is licensed under LGPLv2?
>>>
>>> If not, then what is its license? GPLv3 or LGPLv2?
>>>     
>>
>> Hi.  Actually, I cannot find a license header in libtasn1-config.in, so
>> I'm equally confused.
>>
>> Normally build infrastructure stuff is GPLv3, so using that would be
>> close at hand.  Alternatively, the all-permissive license used for other
>> autoconf-related files may be used.  I noticed that libgcrypt uses it.
>>
>> However, I would prefer to get rid of the *-config scripts.  The idea
>> behind *-config scripts is against the normal autoconf-approach to test
>> for features, and works poorly in corner cases.  Even if some users
>> prefers that model rather than the normal autoconf-approach, libtasn1
>> supports pkg-config.  Pkg-config is at least widely used, and the M4
>> code for it is likely more correct than libtasn1.m4.  People have
>> probably adapted pkg-config for some corner cases before us.
>>
>> So let me propose that we remove libtasn1-config and libtasn1.m4 from
>> libtasn1.  Instead, we recommend developers to use the normal
>> autoconf-machinery to test for libraries, or if they don't like that,
>> that they use pkg-config.
>>
>> Thoughts?
>>
>> /Simon
>>
>>
>> _______________________________________________
>> Gnutls-devel mailing list
>> Gnutls-devel at gnu.org
>> http://lists.gnu.org/mailman/listinfo/gnutls-devel
>>   




From Jeff.Cai at Sun.COM  Wed Oct  8 15:00:06 2008
From: Jeff.Cai at Sun.COM (Jeff Cai)
Date: Wed, 08 Oct 2008 21:00:06 +0800
Subject: Which license is libtasn1-config?
In-Reply-To: <87od1vfe7o.fsf@mocca.josefsson.org>
References: <48EC98C7.30104@sun.com> <87wsgjffvb.fsf@mocca.josefsson.org>
	<48ECA6BC.5040701@sun.com> <87od1vfe7o.fsf@mocca.josefsson.org>
Message-ID: <48ECAED6.50801@sun.com>

Simon Josefsson wrote:
>
>
> I changed the license from GPLv2+ to GPLv3+ on those parts that used
> GPLv2+ before.
>   
Could you confirm that you DID NOT changed libtasn1-config to GPLv3+? If 
so, I think it is still the original license (LGPLv2 or GPLv2), right?

Jeff





From Jeff.Cai at Sun.COM  Wed Oct  8 15:06:36 2008
From: Jeff.Cai at Sun.COM (Jeff Cai)
Date: Wed, 08 Oct 2008 21:06:36 +0800
Subject: Which license is libtasn1-config?
In-Reply-To: <87od1vfe7o.fsf@mocca.josefsson.org>
References: <48EC98C7.30104@sun.com> <87wsgjffvb.fsf@mocca.josefsson.org>
	<48ECA6BC.5040701@sun.com> <87od1vfe7o.fsf@mocca.josefsson.org>
Message-ID: <48ECB05C.7060204@sun.com>


> I changed the license from GPLv2+ to GPLv3+ on those parts that used
> GPLv2+ before.
>
> According to the vc logs, Nikos added libtasn1-config back in 2004.  You
> could ask him for the license.  However, I suspect the files were
> derived from somewhere else (GnuTLS?  Which in turn may have derived
> them from libgcrypt?) so that may require chasing the authors further.
>
> I believe the simplest solution is to remove these files.
>   
Currently gnome-keyring and GnuTLS still uses the command line, if we 
remove the script, the build will be broken.
Do you have plan to change it to use the .pc file.

Jeff
> /Simon
>
>
>   
>> Thanks
>>
>> Jeff
>>
>> Simon Josefsson wrote:
>>     
>>> Jeff Cai <Jeff.Cai at Sun.COM> writes:
>>>
>>>   
>>>       
>>>> Hi, Simon
>>>>
>>>> I'm confused that though libtasn1 is licensed under LGPLv2, then does
>>>> it mean libtasn1-config also is licensed under LGPLv2?
>>>>
>>>> If not, then what is its license? GPLv3 or LGPLv2?
>>>>     
>>>>         
>>> Hi.  Actually, I cannot find a license header in libtasn1-config.in, so
>>> I'm equally confused.
>>>
>>> Normally build infrastructure stuff is GPLv3, so using that would be
>>> close at hand.  Alternatively, the all-permissive license used for other
>>> autoconf-related files may be used.  I noticed that libgcrypt uses it.
>>>
>>> However, I would prefer to get rid of the *-config scripts.  The idea
>>> behind *-config scripts is against the normal autoconf-approach to test
>>> for features, and works poorly in corner cases.  Even if some users
>>> prefers that model rather than the normal autoconf-approach, libtasn1
>>> supports pkg-config.  Pkg-config is at least widely used, and the M4
>>> code for it is likely more correct than libtasn1.m4.  People have
>>> probably adapted pkg-config for some corner cases before us.
>>>
>>> So let me propose that we remove libtasn1-config and libtasn1.m4 from
>>> libtasn1.  Instead, we recommend developers to use the normal
>>> autoconf-machinery to test for libraries, or if they don't like that,
>>> that they use pkg-config.
>>>
>>> Thoughts?
>>>
>>> /Simon
>>>
>>>
>>> _______________________________________________
>>> Gnutls-devel mailing list
>>> Gnutls-devel at gnu.org
>>> http://lists.gnu.org/mailman/listinfo/gnutls-devel
>>>   
>>>       
>
>
> _______________________________________________
> Gnutls-devel mailing list
> Gnutls-devel at gnu.org
> http://lists.gnu.org/mailman/listinfo/gnutls-devel
>   





From simon at josefsson.org  Wed Oct  8 15:13:38 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 08 Oct 2008 15:13:38 +0200
Subject: Which license is libtasn1-config?
In-Reply-To: <48ECAED6.50801@sun.com> (Jeff Cai's message of "Wed, 08 Oct 2008
	21:00:06 +0800")
References: <48EC98C7.30104@sun.com> <87wsgjffvb.fsf@mocca.josefsson.org>
	<48ECA6BC.5040701@sun.com> <87od1vfe7o.fsf@mocca.josefsson.org>
	<48ECAED6.50801@sun.com>
Message-ID: <87fxn7fcvx.fsf@mocca.josefsson.org>

Jeff Cai <Jeff.Cai at Sun.COM> writes:

> Simon Josefsson wrote:
>>
>>
>> I changed the license from GPLv2+ to GPLv3+ on those parts that used
>> GPLv2+ before.
>>   
> Could you confirm that you DID NOT changed libtasn1-config to GPLv3+?

Yes.  I only changed the text in files that said GPLv2+ to GPLv3+.
libtasn1-config wasn't one of those files.

> If so, I think it is still the original license (LGPLv2 or GPLv2),
> right?

Yes, although the license for a file without a clear header seems
unclear.

So either we should:

1) Remove libtasn1-config and libtasn1.m4, or

2) Clarify the license on those files.

I'll wait a few days for other feedback, otherwise I'll go with 1).

/Simon




From simon at josefsson.org  Wed Oct  8 15:26:38 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 08 Oct 2008 15:26:38 +0200
Subject: Which license is libtasn1-config?
In-Reply-To: <48ECB05C.7060204@sun.com> (Jeff Cai's message of "Wed, 08 Oct
	2008 21:06:36 +0800")
References: <48EC98C7.30104@sun.com> <87wsgjffvb.fsf@mocca.josefsson.org>
	<48ECA6BC.5040701@sun.com> <87od1vfe7o.fsf@mocca.josefsson.org>
	<48ECB05C.7060204@sun.com>
Message-ID: <878wszfca9.fsf@mocca.josefsson.org>

Jeff Cai <Jeff.Cai at Sun.COM> writes:

>> I changed the license from GPLv2+ to GPLv3+ on those parts that used
>> GPLv2+ before.
>>
>> According to the vc logs, Nikos added libtasn1-config back in 2004.  You
>> could ask him for the license.  However, I suspect the files were
>> derived from somewhere else (GnuTLS?  Which in turn may have derived
>> them from libgcrypt?) so that may require chasing the authors further.
>>
>> I believe the simplest solution is to remove these files.
>>   
> Currently gnome-keyring and GnuTLS still uses the command line, if we
> remove the script, the build will be broken.

Yes, I'll fix GnuTLS.  I can't see any calls to libtasn1-config in
gnome-keyring SVN though.

> Do you have plan to change it to use the .pc file.

I'll use AC_LIB_HAVE_LINKFLAGS instead, it is more reliable.

/Simon




From colin at colino.net  Fri Oct 10 16:18:26 2008
From: colin at colino.net (Colin Leroy)
Date: Fri, 10 Oct 2008 16:18:26 +0200
Subject: Claws Mail uses GnuTLS...
Message-ID: <20081010161826.62338919@paperstreet.colino.net>

... with only one little problem.

I've mailed about that a while ago, and am wondering whether any
progress has been made:

http://www.nabble.com/libgnutls:-Verifying-certificate-chains,-disconnected-td13269707.html

We save the certificate in DER form, so we're able to check whether it
changed, and also able to show it from a list of saved certificates,
like this:

http://colino.net/tmp/offline_cert_check.png

The problem is that in this case, we can't get the signature status. 

It would be very nice to have this issue solved.

The API could look like

gnutls_x509_crt cert_to_check = ...;
gnutls_certificate_credentials_t xcred;

gnutls_certificate_set_x509_trust_file(xcred,
	"/etc/ssl/ca-certificates/ca-bundle.crt",  
	GNUTLS_X509_FMT_PEM);

gnutls_certificate_verify_crt(cert_to_check, xcred);

-- 
Colin




From charley.internet at collins.ch  Fri Oct 10 09:16:24 2008
From: charley.internet at collins.ch (Charley Collins)
Date: Fri, 10 Oct 2008 09:16:24 +0200
Subject: mod_gnutls: NameVirtualHost gets wrong Cert
Message-ID: <85531F2C-B890-43D1-BE4A-129FDB08F2A7@collins.ch>

Hi

Everything works fine, if I have only one virtual host.
If I configure a second one and go with a browser to the first site, I  
come in trouble:
On Firefox it works well. With IE7 the browser get the right site but  
the wrong certificate, this one of the second configured site! I t  
looks like the VirtualName service is not working in mod_gnutls.

I hope someone can help me...
Pleas check my configuration above:

Linux Centos 5.2
http: 2.2.3-11
mod_gnutls: 0.2.0-1
gnutls: 1.4.1-3

I found only this old version for centos binary.
I tried compiling the actual version from source, but it ends apache  
without any message or errormessage...


Configuration

mod_gnutls.conf:

LoadModule gnutls_module modules/libmod_gnutls.so
AddType application/x-x509-ca-cert .crt
GnuTLSCache dbm "/var/cache/mod_gnutls_cache"
GnuTLSCacheTimeout 300
Listen 195.2.228.126:443
NameVirtualHost 195.2.228.126:443
Include /etc/httpd/conf/sslvhosts/*.conf

/etc/httpd/conf/sslvhosts/shop.moon-shop.com.conf: (Works fine, if  
only this file exists in sslvhosts)

<VirtualHost 195.2.228.126:443>
         ServerAdmin ###@#####.###     # anti spam
         GnuTLSEnable on
         GnuTLSCertificateFile /etc/httpd/ssl/shop.moon-shop.com.crt
         GnuTLSKeyFile /etc/httpd/ssl/shop.moon-shop.com.key
         #GnuTLSPriorities NORMAL
         DocumentRoot /var/www/shop.moon-shop.com/htdocs/joomla
         ServerName shop.moon-shop.com
         DirectoryIndex index.php
         ErrorLog /var/www/shop.moon-shop.com/log/ssl_error.log
         CustomLog /var/www/shop.moon-shop.com/log/ssl_access.log common
         AddType application/x-httpd-php .php
         #php_admin_flag safe_mode On
         php_admin_value file_uploads 1
         php_admin_value upload_tmp_dir /var/www/shop.moon-shop.com/ 
phptmp/
         php_admin_value session.save_path /var/www/shop.moon-shop.com/ 
phptmp/
         AddType text/html .shtml
         AddOutputFilter INCLUDES .shtml
</VirtualHost>

/etc/httpd/conf/sslvhosts/customer.moon-shop.com.conf: (cert of this  
conf will be deliered in shop if this file exists)

<VirtualHost 195.2.228.126:443>
         ServerAdmin ###@#####.###     # anti spam
         GnuTLSEnable on
         GnuTLSCertificateFile /etc/httpd/ssl/customer.moon-shop.com.crt
         GnuTLSKeyFile /etc/httpd/ssl/customer.moon-shop.com.key
         DocumentRoot /var/turbogears/turbotest
         ServerName customer.moon-shop.com:443
         ErrorLog /var/log/httpd/ssl_error-test.log
         CustomLog /var/log/httpd/ssl_access-test.log common
</VirtualHost>

Thank you for your help

Kind Regards
Charley




From nmav at gnutls.org  Fri Oct 10 18:57:00 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 10 Oct 2008 19:57:00 +0300
Subject: Claws Mail uses GnuTLS...
In-Reply-To: <20081010161826.62338919@paperstreet.colino.net>
References: <20081010161826.62338919@paperstreet.colino.net>
Message-ID: <48EF895C.1030209@gnutls.org>

Colin Leroy wrote:
> ... with only one little problem.
> 
> I've mailed about that a while ago, and am wondering whether any
> progress has been made:
> 
> http://www.nabble.com/libgnutls:-Verifying-certificate-chains,-disconnected-td13269707.html
> 
> We save the certificate in DER form, so we're able to check whether it
> changed, and also able to show it from a list of saved certificates,
> like this:
> 
> http://colino.net/tmp/offline_cert_check.png
> 
> The problem is that in this case, we can't get the signature status. 

About the certificate file that you mention, note that "trust" is a
local issue outside the scope of gnutls. If I trust verisign does not
mean you trust it too since you use gnutls. I'd understand some
distributions adding some trusted CA list under some specific criteria
and gnutls could work with that.

About the certificate verification, if I understand what you want to do,
there are no high level functions to verify a certificate using a
certificate list as the ones you describe.

However you can do it using the x.509 API though with the following (not
very efficient) procedure:

1. You load the trusted certificate list as well as the certificate to
be verified into memory

2. You convert the certificate to gnutls_x509_t structure using
gnutls_crt_import

3. You convert the CA certificate list using gnutls_x509_crt_list_import
to gnutls_x509_t structures

4. You verify the certificate against the CA list using
gnutls_x509_crt_verify


If you want to verify against CRLs[0]:
1. You get the issuer of the certificate using gnutls_x509_crt_get_issuer_dn

2. By traversing the imported CA list you find the issuer's certificate
(using gnutls_x509_crt_get_dn)

3. You use  gnutls_x509_crt_get_crl_dist_points the obtain the URL of
the CA's CRL list

4. You download the CRL

5. You import the CRL using gnutls_x509_crl_import

6. You verify that the CRL belongs to the CA you found using
gnutls_x509_crl_verify

7. You check if the certificate's serial number is in the CRL list
using gnutls_x509_crl_get_crt_serial



[0] There are some other protocols such as OCSP to verify for a revoked
certificate.




From colin at colino.net  Fri Oct 10 20:47:55 2008
From: colin at colino.net (Colin Leroy)
Date: Fri, 10 Oct 2008 20:47:55 +0200
Subject: Claws Mail uses GnuTLS...
In-Reply-To: <48EF895C.1030209@gnutls.org>
References: <20081010161826.62338919@paperstreet.colino.net>
	<48EF895C.1030209@gnutls.org>
Message-ID: <20081010204755.4fa07412@colino.net>

On 10 October 2008 at 19h10, Nikos Mavrogiannopoulos wrote:

Hi, 

> About the certificate file that you mention, note that "trust" is a
> local issue outside the scope of gnutls. If I trust verisign does not
> mean you trust it too since you use gnutls. I'd understand some
> distributions adding some trusted CA list under some specific criteria
> and gnutls could work with that.

Yes, that's what I meant -- users expect the MUA to display the same
status as Firefox would, for example :)

> However you can do it using the x.509 API though with the following
> (not very efficient) procedure:
> [snip]

Thanks a bunch. It works very well. I don't know how I didn't figure it
out :)

-- 
Colin




From ucko at ncbi.nlm.nih.gov  Fri Oct 10 22:11:08 2008
From: ucko at ncbi.nlm.nih.gov (Aaron Ucko)
Date: Fri, 10 Oct 2008 16:11:08 -0400
Subject: [patch] libextra/fipsmd5.c: dig and mac should be static
Message-ID: <w98tzbkw6qr.fsf@ncbimac1005.ncbi.nlm.nih.gov>

In libextra/fipsmd5.c, dig and mac should be static to avoid name
collisions; in particular, certtool also defines a dig, leading to
errors (at least in --disable-shared configurations).  The following
patches against 2.6.0 and HEAD take care of the matter:

--- gnutls-2.6.0/libextra/fipsmd5.c~	2008-10-05 09:41:43.000000000 -0400
+++ gnutls-2.6.0/libextra/fipsmd5.c	2008-10-10 16:08:11.000000000 -0400
@@ -194,7 +194,7 @@
   gnutls_free (p);
 }
 
-gnutls_crypto_single_digest_st dig =
+static gnutls_crypto_single_digest_st dig =
   {
     md5init,
     NULL,
@@ -204,7 +204,7 @@
     md5deinit
   };
 
-gnutls_crypto_single_mac_st mac =
+static gnutls_crypto_single_mac_st mac =
   {
     hmacmd5init,
     hmacmd5setkey,

--- gnutls-HEAD/libextra/fipsmd5.c~	2008-10-10 16:03:26.000000000 -0400
+++ gnutls-HEAD/libextra/fipsmd5.c	2008-10-10 16:09:11.000000000 -0400
@@ -194,7 +194,7 @@
   gnutls_free (p);
 }
 
-gnutls_crypto_single_digest_st dig = {
+static gnutls_crypto_single_digest_st dig = {
   md5init,
   NULL,
   md5hash,
@@ -203,7 +203,7 @@
   md5deinit
 };
 
-gnutls_crypto_single_mac_st mac = {
+static gnutls_crypto_single_mac_st mac = {
   hmacmd5init,
   hmacmd5setkey,
   hmacmd5hash,

Could you please apply them?

Thanks!

-- 
Aaron Ucko <ucko at ncbi>, NCBI C++ Toolkit core development group




From simon at josefsson.org  Sat Oct 11 07:25:36 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Sat, 11 Oct 2008 07:25:36 +0200
Subject: [patch] libextra/fipsmd5.c: dig and mac should be static
In-Reply-To: <w98tzbkw6qr.fsf@ncbimac1005.ncbi.nlm.nih.gov> (Aaron Ucko's
	message of "Fri, 10 Oct 2008 16:11:08 -0400")
References: <w98tzbkw6qr.fsf@ncbimac1005.ncbi.nlm.nih.gov>
Message-ID: <87r66nvh2n.fsf@mocca.josefsson.org>

Aaron Ucko <ucko at ncbi.nlm.nih.gov> writes:

> In libextra/fipsmd5.c, dig and mac should be static to avoid name
> collisions; in particular, certtool also defines a dig, leading to
> errors (at least in --disable-shared configurations).  The following
> patches against 2.6.0 and HEAD take care of the matter:

Ouch.  Thank you, applied.

/Simon




From colin at colino.net  Sat Oct 11 15:10:39 2008
From: colin at colino.net (Colin Leroy)
Date: Sat, 11 Oct 2008 15:10:39 +0200
Subject: "Interesting" problem
Message-ID: <20081011151039.5c407e52@jack>

Hi,

We have an interesting bug reported in Claws Mail's bugzilla, related
to GnuTLS. I think it might be useful to point you to it, because
unlike the other GnuTLS bugs we had (and solved), gnutls-cli fails too
on the reporter's server - usually it always works.

It's at
http://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=1755

Thanks in advance for your advice!
-- 
Colin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: </pipermail/attachments/20081011/18f9408b/attachment.pgp>

From simon at josefsson.org  Sat Oct 11 18:08:03 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Sat, 11 Oct 2008 18:08:03 +0200
Subject: "Interesting" problem
In-Reply-To: <20081011151039.5c407e52@jack> (Colin Leroy's message of "Sat, 11
	Oct 2008 15:10:39 +0200")
References: <20081011151039.5c407e52@jack>
Message-ID: <87vdvzazdo.fsf@mocca.josefsson.org>

Colin Leroy <colin at colino.net> writes:

> Hi,
>
> We have an interesting bug reported in Claws Mail's bugzilla, related
> to GnuTLS. I think it might be useful to point you to it, because
> unlike the other GnuTLS bugs we had (and solved), gnutls-cli fails too
> on the reporter's server - usually it always works.
>
> It's at
> http://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=1755

Hi!  Thanks for the report, I'm in a hurry now so I can't look into this
completely, but gnutls-cli from 2.6.0 seems to work fine against that
server (or has the server changed somehow?).  It may be a bug that has
been fixed.  I'll debug it more later, but thought I'd give you a quick
reply.

/Simon




From colin at colino.net  Sat Oct 11 18:48:02 2008
From: colin at colino.net (Colin Leroy)
Date: Sat, 11 Oct 2008 18:48:02 +0200
Subject: "Interesting" problem
In-Reply-To: <87vdvzazdo.fsf@mocca.josefsson.org>
References: <20081011151039.5c407e52@jack> <87vdvzazdo.fsf@mocca.josefsson.org>
Message-ID: <20081011184802.05babf6b@colino.net>

On 11 October 2008 at 18h10, Simon Josefsson wrote:

Hi, 

> Hi!  Thanks for the report, I'm in a hurry now so I can't look into
> this completely, but gnutls-cli from 2.6.0 seems to work fine against
> that server (or has the server changed somehow?).  It may be a bug
> that has been fixed.  I'll debug it more later, but thought I'd give
> you a quick reply.

Thanks; it looks like Gnutls 2.4.1 also works -- 2.0.4 is the version I
and the reporter are using.

-- 
Colin




From simon at josefsson.org  Sat Oct 11 21:06:16 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Sat, 11 Oct 2008 21:06:16 +0200
Subject: "Interesting" problem
In-Reply-To: <20081011184802.05babf6b@colino.net> (Colin Leroy's message of
	"Sat, 11 Oct 2008 18:48:02 +0200")
References: <20081011151039.5c407e52@jack> <87vdvzazdo.fsf@mocca.josefsson.org>
	<20081011184802.05babf6b@colino.net>
Message-ID: <87k5cfar4n.fsf@mocca.josefsson.org>

Colin Leroy <colin at colino.net> writes:

> On 11 October 2008 at 18h10, Simon Josefsson wrote:
>
> Hi, 
>
>> Hi!  Thanks for the report, I'm in a hurry now so I can't look into
>> this completely, but gnutls-cli from 2.6.0 seems to work fine against
>> that server (or has the server changed somehow?).  It may be a bug
>> that has been fixed.  I'll debug it more later, but thought I'd give
>> you a quick reply.
>
> Thanks; it looks like Gnutls 2.4.1 also works -- 2.0.4 is the version I
> and the reporter are using.

I tracked down the problem.

The reason the problem is triggered is that the server sends a huge list
of CA's it trusts, and older GnuTLS's had a small limit to protect
against DoS attacks.  The limit has been increased in v2.4.0:

*** The default handshake size limit has been increased to 48kb.
It appears as if some valid handshakes are large due to sending many
CA certificates.  (The earlier limit was 16kb.)

Thus, the gnutls handshake failed against the server with your GnuTLS
version.  Arguable the server is somewhat strangely configured, but
there are many debian machines out there that has a large CA trust list
(possibly a bug in the ca-certificates package).

The reason for the _crash_ is a bug in gnutls-cli: older versions didn't
behave correctly on handshake failures.  This was fixed for v.2.4.0 as
well:

** gnutls-cli: Fix crash on TLS handshake failures.
Reported by "Marc F. Clemente" <marc at mclemente.net> in Debian BTS #466477.
This is similar to <http://bugs.debian.org/429183>.

See those bug reports for more information.

This explains why Claws Mail just return an error, whereas gnutls-cli
crashes.  If the problem was in the library, you'd expect that Claws
Mail would have crashed as well.

Anyway, this has been fixed in modern releases.

/Simon




From simon at josefsson.org  Mon Oct 13 10:02:10 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 13 Oct 2008 10:02:10 +0200
Subject: GNUTLS_E_AGAIN strerror
In-Reply-To: <7B6F170840CA6C4DA63EE0C8A7BB43EC02D7F4FD@NIHCESMLBX15.nih.gov>
	(Anton Lavrentiev's message of "Mon, 13 Oct 2008 01:09:25 -0400")
References: <7B6F170840CA6C4DA63EE0C8A7BB43EC02D7F4FD@NIHCESMLBX15.nih.gov>
Message-ID: <87iqrw53el.fsf@mocca.josefsson.org>

"Lavrentiev, Anton (NIH/NLM/NCBI) [C]" <lavr at ncbi.nlm.nih.gov> writes:

> Hi,
>
> May I request that GNUTLS_E_AGAIN text description as returned by
> gnutls_strerror() be
> changed from "Function was interrupted" to something more like "Try
> again".
> ("Function was interrupted" seems to be a cut-n-paste of
> GNUTLS_E_INTERRUPTED, where
> it rightfully belong.)  Source: gnutls_errors.c:159-160 as of gnutls
> 2.6.0.

Hi.  Good idea.  strerror(EAGAIN) returns 'Resource temporarily
unavailable' on my system, so I changed the text to contain that too.

I've pushed this change:

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

/Simon




From simon at josefsson.org  Tue Oct 14 15:17:04 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 14 Oct 2008 15:17:04 +0200
Subject: GnuTLS 2.6.0
In-Reply-To: <20081012185945.GA30038@garfield> (Enrico Tassi's message of
	"Sun, 12 Oct 2008 20:59:45 +0200")
References: <87myhitb86.fsf@mocca.josefsson.org>
	<20081012185945.GA30038@garfield>
Message-ID: <87zll7joz3.fsf@mocca.josefsson.org>

Enrico Tassi <gareuselesinge at debian.org> writes:

> On Mon, Oct 06, 2008 at 09:48:57AM +0200, Simon Josefsson wrote:
>> We are proud to announce a new stable GnuTLS release: Version 2.6.0.
>> Thanks to Enrico Tassi, we also have mingw32 *.deb's available:
>>   http://josefsson.org/gnutls4win/mingw32-gnutls_2.3.15-1_all.deb
>
> thanks you very much for giving me credit, anyway I found some issues,
> mainly you have to execute something like this before packing up the
> deb:
>
> find . -name \*.la -exec sed \
> 	s?/home/jas/gnutls4win/inst?/usr/i586-mingw32msvc?g -i {} \;
> chmod a+x bin/*
>
> I'm using gnutls to build libcurl and both fix are necessary, otherwise
> linking using the .la gives an error due to the relocation of the .la
> file and curl seems to want to run libgnutls-config as a binary and not
> calling a shell on it.

Thanks, I added the call in debify.sh:

http://cvs.savannah.gnu.org/viewvc/gnutls4win/debify.sh?root=gnutls&r1=1.3&r2=1.4

Somewhat ugly, but maybe it works.

/Simon




From charley.internet at collins.ch  Wed Oct 15 10:27:46 2008
From: charley.internet at collins.ch (Charley Collins)
Date: Wed, 15 Oct 2008 10:27:46 +0200
Subject: mod_gnutls: NameVirtualHost gets wrong Cert
Message-ID: <48F5A982.90703@collins.ch>

Hi

Everything works fine, if I have only one virtual host.
If I configure a second one and go with a browser to the first site, I
come in trouble:
On Firefox it works well. With IE7 the browser get the right site but
the wrong certificate, this one of the second configured site! I t
looks like the VirtualName service is not working in mod_gnutls.

I hope someone can help me...
Pleas check my configuration above:

Linux Centos 5.2
http: 2.2.3-11
mod_gnutls: 0.2.0-1
gnutls: 1.4.1-3

I found only this old version for centos binary.
I tried compiling the actual version from source, but it ends apache
without any message or errormessage...


Configuration

mod_gnutls.conf:

LoadModule gnutls_module modules/libmod_gnutls.so
AddType application/x-x509-ca-cert .crt
GnuTLSCache dbm "/var/cache/mod_gnutls_cache"
GnuTLSCacheTimeout 300
Listen 195.2.228.126:443
NameVirtualHost 195.2.228.126:443
Include /etc/httpd/conf/sslvhosts/*.conf

/etc/httpd/conf/sslvhosts/shop.moon-shop.com.conf: (Works fine, if
only this file exists in sslvhosts)

<VirtualHost 195.2.228.126:443>
         ServerAdmin ###@#####.###     # anti spam
         GnuTLSEnable on
         GnuTLSCertificateFile /etc/httpd/ssl/shop.moon-shop.com.crt
         GnuTLSKeyFile /etc/httpd/ssl/shop.moon-shop.com.key
         #GnuTLSPriorities NORMAL
         DocumentRoot /var/www/shop.moon-shop.com/htdocs/joomla
         ServerName shop.moon-shop.com
         DirectoryIndex index.php
         ErrorLog /var/www/shop.moon-shop.com/log/ssl_error.log
         CustomLog /var/www/shop.moon-shop.com/log/ssl_access.log common
         AddType application/x-httpd-php .php
         #php_admin_flag safe_mode On
         php_admin_value file_uploads 1
         php_admin_value upload_tmp_dir /var/www/shop.moon-shop.com/
phptmp/
         php_admin_value session.save_path /var/www/shop.moon-shop.com/
phptmp/
         AddType text/html .shtml
         AddOutputFilter INCLUDES .shtml
</VirtualHost>

/etc/httpd/conf/sslvhosts/customer.moon-shop.com.conf: (cert of this
conf will be deliered in shop if this file exists)

<VirtualHost 195.2.228.126:443>
         ServerAdmin ###@#####.###     # anti spam
         GnuTLSEnable on
         GnuTLSCertificateFile /etc/httpd/ssl/customer.moon-shop.com.crt
         GnuTLSKeyFile /etc/httpd/ssl/customer.moon-shop.com.key
         DocumentRoot /var/turbogears/turbotest
         ServerName customer.moon-shop.com:443
         ErrorLog /var/log/httpd/ssl_error-test.log
         CustomLog /var/log/httpd/ssl_access-test.log common
</VirtualHost>

Thank you for your help

Kind Regards
Charley




From sdecugis at nict.go.jp  Wed Oct 15 10:59:39 2008
From: sdecugis at nict.go.jp (Sebastien Decugis)
Date: Wed, 15 Oct 2008 17:59:39 +0900
Subject: mod_gnutls: NameVirtualHost gets wrong Cert
In-Reply-To: <48F5A982.90703@collins.ch>
References: <48F5A982.90703@collins.ch>
Message-ID: <48F5B0FB.8090802@nict.go.jp>

Hello,

According to your configuration file, you are using two virtualhosts
with the same IP address and different names. It is impossible to use
https in this configuration. See
http://httpd.apache.org/docs/2.0/vhosts/name-based.html (second item)

In short, you need to negociate your SSL settings (therefore select the
correct certificate) even before the first request is sent, containing
the server name with which you want to communicate.

The usual workarounds are:
- use a different IP
- use a different port.

I hope this helps...
Sebastien.

Charley Collins a ?crit :
> Hi
>
> Everything works fine, if I have only one virtual host.
> If I configure a second one and go with a browser to the first site, I
> come in trouble:
> On Firefox it works well. With IE7 the browser get the right site but
> the wrong certificate, this one of the second configured site! I t
> looks like the VirtualName service is not working in mod_gnutls.
>
> I hope someone can help me...
> Pleas check my configuration above:
>
> Linux Centos 5.2
> http: 2.2.3-11
> mod_gnutls: 0.2.0-1
> gnutls: 1.4.1-3
>
> I found only this old version for centos binary.
> I tried compiling the actual version from source, but it ends apache
> without any message or errormessage...
>
>
> Configuration
>
> mod_gnutls.conf:
>
> LoadModule gnutls_module modules/libmod_gnutls.so
> AddType application/x-x509-ca-cert .crt
> GnuTLSCache dbm "/var/cache/mod_gnutls_cache"
> GnuTLSCacheTimeout 300
> Listen 195.2.228.126:443
> NameVirtualHost 195.2.228.126:443
> Include /etc/httpd/conf/sslvhosts/*.conf
>
> /etc/httpd/conf/sslvhosts/shop.moon-shop.com.conf: (Works fine, if
> only this file exists in sslvhosts)
>
> <VirtualHost 195.2.228.126:443>
>         ServerAdmin ###@#####.###     # anti spam
>         GnuTLSEnable on
>         GnuTLSCertificateFile /etc/httpd/ssl/shop.moon-shop.com.crt
>         GnuTLSKeyFile /etc/httpd/ssl/shop.moon-shop.com.key
>         #GnuTLSPriorities NORMAL
>         DocumentRoot /var/www/shop.moon-shop.com/htdocs/joomla
>         ServerName shop.moon-shop.com
>         DirectoryIndex index.php
>         ErrorLog /var/www/shop.moon-shop.com/log/ssl_error.log
>         CustomLog /var/www/shop.moon-shop.com/log/ssl_access.log common
>         AddType application/x-httpd-php .php
>         #php_admin_flag safe_mode On
>         php_admin_value file_uploads 1
>         php_admin_value upload_tmp_dir /var/www/shop.moon-shop.com/
> phptmp/
>         php_admin_value session.save_path /var/www/shop.moon-shop.com/
> phptmp/
>         AddType text/html .shtml
>         AddOutputFilter INCLUDES .shtml
> </VirtualHost>
>
> /etc/httpd/conf/sslvhosts/customer.moon-shop.com.conf: (cert of this
> conf will be deliered in shop if this file exists)
>
> <VirtualHost 195.2.228.126:443>
>         ServerAdmin ###@#####.###     # anti spam
>         GnuTLSEnable on
>         GnuTLSCertificateFile /etc/httpd/ssl/customer.moon-shop.com.crt
>         GnuTLSKeyFile /etc/httpd/ssl/customer.moon-shop.com.key
>         DocumentRoot /var/turbogears/turbotest
>         ServerName customer.moon-shop.com:443
>         ErrorLog /var/log/httpd/ssl_error-test.log
>         CustomLog /var/log/httpd/ssl_access-test.log common
> </VirtualHost>
>
> Thank you for your help
>
> Kind Regards
> Charley
>
>
> _______________________________________________
> Gnutls-devel mailing list
> Gnutls-devel at gnu.org
> http://lists.gnu.org/mailman/listinfo/gnutls-devel
>

-- 
Sebastien Decugis
Research fellow
Network Architecture Group
NICT (nict.go.jp)





From nmav at gnutls.org  Wed Oct 15 20:34:31 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 15 Oct 2008 21:34:31 +0300
Subject: mod_gnutls: NameVirtualHost gets wrong Cert
In-Reply-To: <85531F2C-B890-43D1-BE4A-129FDB08F2A7@collins.ch>
References: <85531F2C-B890-43D1-BE4A-129FDB08F2A7@collins.ch>
Message-ID: <48F637B7.1000403@gnutls.org>

Charley Collins wrote:
> Hi
> 
> Everything works fine, if I have only one virtual host.
> If I configure a second one and go with a browser to the first site, I
> come in trouble:
> On Firefox it works well. With IE7 the browser get the right site but
> the wrong certificate, this one of the second configured site! I t looks
> like the VirtualName service is not working in mod_gnutls.

Please use the mod gnutls for these issues. Although relevant this is
not the most appropriate mailing list. Anyway for the virtual name
support for mod_gnutls to work the browser must support the dns_name TLS
extension. IE7 on XP does not support it (strangely IE7 on vista works).

regards,
Nikos






From dkg at fifthhorseman.net  Wed Oct 15 22:04:12 2008
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 15 Oct 2008 16:04:12 -0400
Subject: mod_gnutls: NameVirtualHost gets wrong Cert
In-Reply-To: <48F5B0FB.8090802@nict.go.jp> (Sebastien Decugis's message of
	"Wed\, 15 Oct 2008 17\:59\:39 +0900")
References: <48F5A982.90703@collins.ch> <48F5B0FB.8090802@nict.go.jp>
Message-ID: <87abd5fww3.fsf@squeak.fifthhorseman.net>

On Wed 2008-10-15 04:59:39 -0400, Sebastien Decugis wrote:

> According to your configuration file, you are using two virtualhosts
> with the same IP address and different names. It is impossible to
> use https in this configuration.

This is no longer the case with modern TLS clients, and the poster has
a legitimate question.  For example, for years now people have been
able to use a single certificate with a single TLS service (on a
single port of a single IP address) with all target names listed in an
X.509v3 SubjectAltName extension in the certificate itself.

But the OP is asking about being able to switch certificates based on
the host name, which is a TLS extension known as "Server Name
Indication".  Please see:

  http://tools.ietf.org/html/rfc4366#section-3.1

The question is very much relevant to gnutls, since mod_gnutls is one
of the first apache modules to implement support for this extension.

Sorry i don't have any answers myself!

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

From charley.internet at collins.ch  Wed Oct 15 22:19:59 2008
From: charley.internet at collins.ch (Charley Collins)
Date: Wed, 15 Oct 2008 22:19:59 +0200
Subject: mod_gnutls: NameVirtualHost gets wrong Cert
In-Reply-To: <87abd5fww3.fsf@squeak.fifthhorseman.net>
References: <48F5A982.90703@collins.ch> <48F5B0FB.8090802@nict.go.jp>
	<87abd5fww3.fsf@squeak.fifthhorseman.net>
Message-ID: <48F6506F.2080801@collins.ch>

Thank you for your answers.

IE7, Firfox and Opera 8 support Server Name Indication, but I did not 
know that IE7 on Xp does NOT support Server Name Indication. This was my 
Problem...

Regards
Charley






Daniel Kahn Gillmor schrieb:
> On Wed 2008-10-15 04:59:39 -0400, Sebastien Decugis wrote:
>
>   
>> According to your configuration file, you are using two virtualhosts
>> with the same IP address and different names. It is impossible to
>> use https in this configuration.
>>     
>
> This is no longer the case with modern TLS clients, and the poster has
> a legitimate question.  For example, for years now people have been
> able to use a single certificate with a single TLS service (on a
> single port of a single IP address) with all target names listed in an
> X.509v3 SubjectAltName extension in the certificate itself.
>
> But the OP is asking about being able to switch certificates based on
> the host name, which is a TLS extension known as "Server Name
> Indication".  Please see:
>
>   http://tools.ietf.org/html/rfc4366#section-3.1
>
> The question is very much relevant to gnutls, since mod_gnutls is one
> of the first apache modules to implement support for this extension.
>
> Sorry i don't have any answers myself!
>
>    --dkg
>   





From sdecugis at nict.go.jp  Thu Oct 16 03:43:31 2008
From: sdecugis at nict.go.jp (Sebastien Decugis)
Date: Thu, 16 Oct 2008 10:43:31 +0900
Subject: mod_gnutls: NameVirtualHost gets wrong Cert
In-Reply-To: <87abd5fww3.fsf@squeak.fifthhorseman.net>
References: <48F5A982.90703@collins.ch> <48F5B0FB.8090802@nict.go.jp>
	<87abd5fww3.fsf@squeak.fifthhorseman.net>
Message-ID: <48F69C43.20001@nict.go.jp>


> This is no longer the case with modern TLS clients, and the poster has
> a legitimate question.  For example, for years now people have been
> able to use a single certificate with a single TLS service (on a
> single port of a single IP address) with all target names listed in an
> X.509v3 SubjectAltName extension in the certificate itself.
>   
Oh, ok, thank you for this information, and sorry I was not aware of this!

Bests,
Sebastien.




From simon at josefsson.org  Thu Oct 16 12:27:51 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 16 Oct 2008 12:27:51 +0200
Subject: GnuTLS 2.7.0
Message-ID: <871vygx2ag.fsf@mocca.josefsson.org>

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

Here are the compressed sources:
  http://alpha.gnu.org/gnu/gnutls/gnutls-2.7.0.tar.bz2 (5.0MB)
  ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.7.0.tar.bz2

Here is the OpenPGP signature:
  http://alpha.gnu.org/gnu/gnutls/gnutls-2.7.0.tar.bz2.sig
  ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.7.0.tar.bz2.sig

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, 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.

/Simon

* Version 2.7.0 (released 2008-10-16)

** libgnutls: Added functions to handle CRL extensions.

** libgnutls: Added functions to handle X.509 extensions in Certificate
Requests.

** libgnutls: Improved error string for GNUTLS_E_AGAIN.
Suggested by "Lavrentiev, Anton (NIH/NLM/NCBI) [C]" <lavr at ncbi.nlm.nih.gov>.

** certtool: Print and set CRL and CRQ extensions.

** libgnutls-extra: Protect internal symbols with static.
Fixes problem when linking certtool statically.  Tiny patch from Aaron
Ucko <ucko at ncbi.nlm.nih.gov>.

** libgnutls-openssl: fix out of bounds access.
Problem in X509_get_subject_name and X509_get_issuer_name.  Tiny patch
From Thomas Viehmann <tv at beamnet.de>.

** libgnutlsxx: Define server_session::get_srp_username even if no SRP.

** tests: Make tests compile when using internal libtasn1.
Patch by ludo at gnu.org (Ludovic Court?s).

** Changed detection of libtasn1 and libgcrypt to avoid depending on *-config.
We now require a libgcrypt that has Camellia constants declared in
gcrypt.h, which means v1.3.0 or later.

** API and ABI modifications:
gnutls_x509_crl_get_authority_key_id: ADDED
gnutls_x509_crl_get_number: ADDED
gnutls_x509_crl_get_extension_oid: ADDED
gnutls_x509_crl_get_extension_info: ADDED
gnutls_x509_crl_get_extension_data: ADDED
gnutls_x509_crl_set_authority_key_id: ADDED
gnutls_x509_crl_set_number: ADDED
gnutls_x509_crq_get_key_rsa_raw: ADDED
gnutls_x509_crq_get_attribute_info: ADDED
gnutls_x509_crq_get_attribute_data: ADDED
gnutls_x509_crq_get_extension_info: ADDED
gnutls_x509_crq_get_extension_data: ADDED
gnutls_x509_crq_get_key_usage: ADDED
gnutls_x509_crq_get_basic_constraints: ADDED
gnutls_x509_crq_get_subject_alt_name: ADDED
gnutls_x509_crq_get_subject_alt_othername_oid: ADDED
gnutls_x509_crq_get_extension_by_oid: ADDED
gnutls_x509_crq_set_subject_alt_name: ADDED
gnutls_x509_crq_set_basic_constraints: ADDED
gnutls_x509_crq_set_key_usage: ADDED
gnutls_x509_crq_get_key_purpose_oid: ADDED
gnutls_x509_crq_set_key_purpose_oid: ADDED
gnutls_x509_crq_print: ADDED
gnutls_x509_crt_set_crq_extensions: ADDED
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 419 bytes
Desc: not available
URL: </pipermail/attachments/20081016/2046a52d/attachment.pgp>

From davefx at gmail.com  Tue Oct 21 18:53:07 2008
From: davefx at gmail.com (=?UTF-8?Q?David_Mar=C3=ADn_Carre=C3=B1o?=)
Date: Tue, 21 Oct 2008 18:53:07 +0200
Subject: Possible bug in pkcs8 import
Message-ID: <f43cca2f0810210953g5e7a3b3dpbc6dbd948694f6b2@mail.gmail.com>

Hi all.

I am developing PKCS#8 import in gnoMint (http://gnomint.sf.net).

For testing what are the error codes obtained while probing the type
of a given file, I have developed a little program that tries to
import a given file as a PEM-codified crypted and unencrypted PKCS8
file, and the same with DER format.

The problem is that I am not able to import any PKCS#8 file, crypted
or unencrypted, DER or PEM. I have generated these PKCS#8 (attached)
files using gnutls (test-pem-crypt.pkcs8), openssl
(test-pem-uncrypt.pkcs8, and both test-der-*.pkcs8), and certtool
(test-pem-crypt2048.pkcs8).

I am obtaining -207 (GNUTLS_E_BASE64_UNEXPECTED_HEADER_ERROR) while
trying to import a DER file as a PEM file, which is correct. But all
other combinations always result with an error -67
(GNUTLS_E_ASN1_ELEMENT_NOT_FOUND).

Could anyone help me? Is the problem in the PKCS8 files, in my test
program, or in gnutls?

Thank you all.

-- 
David Mar?n Carre?o
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test-pem-unencrypt.pkcs8
Type: application/octet-stream
Size: 508 bytes
Desc: not available
URL: </pipermail/attachments/20081021/3918385f/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test-pem-crypt.pkcs8
Type: application/octet-stream
Size: 581 bytes
Desc: not available
URL: </pipermail/attachments/20081021/3918385f/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test-der-unencrypt.pkcs8
Type: application/octet-stream
Size: 334 bytes
Desc: not available
URL: </pipermail/attachments/20081021/3918385f/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test-der-crypt.pkcs8
Type: application/octet-stream
Size: 373 bytes
Desc: not available
URL: </pipermail/attachments/20081021/3918385f/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test-pem-crypt2048.pkcs8
Type: application/octet-stream
Size: 1772 bytes
Desc: not available
URL: </pipermail/attachments/20081021/3918385f/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test-gnutls.c
Type: application/octet-stream
Size: 1892 bytes
Desc: not available
URL: </pipermail/attachments/20081021/3918385f/attachment-0005.obj>

From simon at josefsson.org  Wed Oct 22 17:04:48 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 22 Oct 2008 17:04:48 +0200
Subject: GnuTLS regression test failing on OpenBSD/sparc64
In-Reply-To: <20081022145647.GD7744@lizzy.fr.homeunix.org> (Landry Breuil's
	message of "Wed, 22 Oct 2008 16:56:47 +0200")
References: <20081022145647.GD7744@lizzy.fr.homeunix.org>
Message-ID: <878wsgekmn.fsf@mocca.josefsson.org>

Landry Breuil <gaston at gcu.info> writes:

> Hi,
>
> after working on an update to latest libgcrypt, i'm in the process of
> updating GnuTLS in OpenBSD's ports-tree. It's currently building fine on
> sparc64, but i got an error in regression suite.

Hi.  Thanks for working on this.

> Bus error (core dumped)
> FAIL: rsa-md5-collision
> ===================================
> 1 of 1 tests failed
> Please report to bug-gnutls at gnu.org
> ===================================
>
> certtool is crashing badly due to symbol conflicts:
> WARNING: symbol(dig) size mismatch, relink your program
> /usr/obj/ports/gnutls-2.6.0/gnutls-2.6.0/src/.libs/certtool : WARNING:
> symbol(dig) size mismatch, relink your program
>
> The attached patch fixes the issue by avoiding name conflicts between
> two different variables of the same name and different types.

This has been fixed on the trunk in a better way, see:

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

> I also noticed that two regress tests were failing to build when
> using included libtasn1, there's a missing -I$(top_srcdir)/lib/minitasn1/
> in tests/pkcs12-decode/Makefile.am and tests/Makefile.am

Also already fixed:

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

> Other than that, everything's okay, regress tests works fine on amd64
> too.

Good.

I guess we should do a v2.6.1 release...

/Simon




From simon at josefsson.org  Wed Oct 22 17:43:57 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 22 Oct 2008 17:43:57 +0200
Subject: Possible bug in pkcs8 import
In-Reply-To: <f43cca2f0810210953g5e7a3b3dpbc6dbd948694f6b2@mail.gmail.com>
	("David =?iso-8859-1?Q?Mar=EDn_Carre=F1o=22's?= message of "Tue, 21 Oct
	2008 18:53:07 +0200")
References: <f43cca2f0810210953g5e7a3b3dpbc6dbd948694f6b2@mail.gmail.com>
Message-ID: <87vdvkd48y.fsf@mocca.josefsson.org>

"David Mar?n Carre?o" <davefx at gmail.com> writes:

> Hi all.
>
> I am developing PKCS#8 import in gnoMint (http://gnomint.sf.net).
>
> For testing what are the error codes obtained while probing the type
> of a given file, I have developed a little program that tries to
> import a given file as a PEM-codified crypted and unencrypted PKCS8
> file, and the same with DER format.
>
> The problem is that I am not able to import any PKCS#8 file, crypted
> or unencrypted, DER or PEM. I have generated these PKCS#8 (attached)
> files using gnutls (test-pem-crypt.pkcs8), openssl
> (test-pem-uncrypt.pkcs8, and both test-der-*.pkcs8), and certtool
> (test-pem-crypt2048.pkcs8).
>
> I am obtaining -207 (GNUTLS_E_BASE64_UNEXPECTED_HEADER_ERROR) while
> trying to import a DER file as a PEM file, which is correct. But all
> other combinations always result with an error -67
> (GNUTLS_E_ASN1_ELEMENT_NOT_FOUND).
>
> Could anyone help me? Is the problem in the PKCS8 files, in my test
> program, or in gnutls?

What is the password for your test files?

I can't seem to read your unencrypted files using openssl either:

jas at mocca:~$ openssl pkcs8 -inform pem -in test-pem-unencrypt.pkcs8 
Error reading key
19169:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:647:Expecting: ENCRYPTED PRIVATE KEY
jas at mocca:~$ openssl pkcs8 -inform der -in test-der-unencrypt.pkcs8 
Error reading key
19178:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag:tasn_dec.c:1294:
19178:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:tasn_dec.c:380:Type=X509_ALGOR
19178:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:749:Field=algor, Type=X509_SIG
jas at mocca:~$ 

How did you generate the files?

/Simon




From davefx at gmail.com  Wed Oct 22 18:02:38 2008
From: davefx at gmail.com (=?UTF-8?Q?David_Mar=C3=ADn_Carre=C3=B1o?=)
Date: Wed, 22 Oct 2008 18:02:38 +0200
Subject: Possible bug in pkcs8 import
In-Reply-To: <87vdvkd48y.fsf@mocca.josefsson.org>
References: <f43cca2f0810210953g5e7a3b3dpbc6dbd948694f6b2@mail.gmail.com>
	<87vdvkd48y.fsf@mocca.josefsson.org>
Message-ID: <f43cca2f0810220902ra77fb11y5d56d16249069f62@mail.gmail.com>

For the unencrypted files, an extra -nocrypt option must be supplied to openssl.
For the crypted files, the password is "lalalala", without the quotes.


$ openssl pkcs8 -inform pem -nocrypt -in test-pem-unencrypt.pkcs8
-----BEGIN DSA PRIVATE KEY-----
MIIBugIBAAKBgQCl3TEqvbZ3vQaLkO9A3UOWNriaVFvXHxhyDmWP3uB65VAgmRLx
0uxDo31qDaj76OwS5x4BoPhpSen8wejRNsFLSCY07Nzg/1kcgsfn8i7QxRliHtmn
+AC+nMIqgGi+x22CmeO5D/SU2Vjs5wj48Dn/Y4gwpw3YZVKI9ZTHlGpLEwIVAPEd
toV2SRI5Ph782+01w9WhvgY3AoGAOK1cl5OlYxpY9yM1AHzFLMS8xfwquNzK0C0I
Yg+nyjzZibAOJ4PCmKnGC25nRrYLt8IpSYjv8qFrK3Brj1ymaPkgunSIj3FQRqrf
c046sqabnrgeJ53E8//g8DLOo+e6M7VIZKiynTwqR4evkajAk7axfzlQBJe+cCwL
xQMMhsICgYBSCZ4pr/PfyBPcqrfrRZt+pz2HDJqXfyoD9dB2QUFacdssVesZMQWq
Q00IZ0lOmb+ZiN45/27nULGl85llrLjSmDyby7jG0OfHEEoF9I+m7YXOc6dCLaq8
bRUzsj2SRTKJTx0iPA4Zk65DgxBHTtPEzOb4W7pNgYjIF+kbqMjTWwIUbZ1dbKU0
I1BI2l3BbSmtEzxRZ04=
-----END DSA PRIVATE KEY-----


2008/10/22 Simon Josefsson <simon at josefsson.org>:
> "David Mar?n Carre?o" <davefx at gmail.com> writes:
>
>> Hi all.
>>
>> I am developing PKCS#8 import in gnoMint (http://gnomint.sf.net).
>>
>> For testing what are the error codes obtained while probing the type
>> of a given file, I have developed a little program that tries to
>> import a given file as a PEM-codified crypted and unencrypted PKCS8
>> file, and the same with DER format.
>>
>> The problem is that I am not able to import any PKCS#8 file, crypted
>> or unencrypted, DER or PEM. I have generated these PKCS#8 (attached)
>> files using gnutls (test-pem-crypt.pkcs8), openssl
>> (test-pem-uncrypt.pkcs8, and both test-der-*.pkcs8), and certtool
>> (test-pem-crypt2048.pkcs8).
>>
>> I am obtaining -207 (GNUTLS_E_BASE64_UNEXPECTED_HEADER_ERROR) while
>> trying to import a DER file as a PEM file, which is correct. But all
>> other combinations always result with an error -67
>> (GNUTLS_E_ASN1_ELEMENT_NOT_FOUND).
>>
>> Could anyone help me? Is the problem in the PKCS8 files, in my test
>> program, or in gnutls?
>
> What is the password for your test files?
>
> I can't seem to read your unencrypted files using openssl either:
>
> jas at mocca:~$ openssl pkcs8 -inform pem -in test-pem-unencrypt.pkcs8
> Error reading key
> 19169:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:647:Expecting: ENCRYPTED PRIVATE KEY
> jas at mocca:~$ openssl pkcs8 -inform der -in test-der-unencrypt.pkcs8
> Error reading key
> 19178:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag:tasn_dec.c:1294:
> 19178:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:tasn_dec.c:380:Type=X509_ALGOR
> 19178:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:749:Field=algor, Type=X509_SIG
> jas at mocca:~$
>
> How did you generate the files?
>
> /Simon
>



-- 
David Mar?n Carre?o

From nmav at gnutls.org  Wed Oct 22 20:57:55 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 22 Oct 2008 21:57:55 +0300
Subject: Possible bug in pkcs8 import
In-Reply-To: <f43cca2f0810210953g5e7a3b3dpbc6dbd948694f6b2@mail.gmail.com>
References: <f43cca2f0810210953g5e7a3b3dpbc6dbd948694f6b2@mail.gmail.com>
Message-ID: <48FF77B3.6060702@gnutls.org>

David Mar?n Carre?o wrote:
> Hi all.
> 
> I am developing PKCS#8 import in gnoMint (http://gnomint.sf.net).
> 
> For testing what are the error codes obtained while probing the type
> of a given file, I have developed a little program that tries to
> import a given file as a PEM-codified crypted and unencrypted PKCS8
> file, and the same with DER format.
> 
> The problem is that I am not able to import any PKCS#8 file, crypted
> or unencrypted, DER or PEM. I have generated these PKCS#8 (attached)
> files using gnutls (test-pem-crypt.pkcs8), openssl
> (test-pem-uncrypt.pkcs8, and both test-der-*.pkcs8), and certtool
> (test-pem-crypt2048.pkcs8).
> 
> I am obtaining -207 (GNUTLS_E_BASE64_UNEXPECTED_HEADER_ERROR) while
> trying to import a DER file as a PEM file, which is correct. But all
> other combinations always result with an error -67
> (GNUTLS_E_ASN1_ELEMENT_NOT_FOUND).

It seems certtool cannot handle not encrypted PKCS #8 files properly.
Moreover if run with -d 2 I can see that
|<1>| PKCS encryption schema OID '1.2.840.113549.1.5.3' (DES-CBC) is
unsupported.

How did you encrypted this key?

> Could anyone help me? Is the problem in the PKCS8 files, in my test
> program, or in gnutls?

It seems it's a combination of certtool issues and gnutls not supporting
 DES-CBC for PKCS #8.

regards,
Nikos




From davefx at gmail.com  Thu Oct 23 08:19:29 2008
From: davefx at gmail.com (=?UTF-8?Q?David_Mar=C3=ADn_Carre=C3=B1o?=)
Date: Thu, 23 Oct 2008 08:19:29 +0200
Subject: Possible bug in pkcs8 import
In-Reply-To: <48FF77B3.6060702@gnutls.org>
References: <f43cca2f0810210953g5e7a3b3dpbc6dbd948694f6b2@mail.gmail.com>
	<48FF77B3.6060702@gnutls.org>
Message-ID: <f43cca2f0810222319l2be94455mc29fb5e9eb2b55fd@mail.gmail.com>

Hi all again.
2008/10/22 Nikos Mavrogiannopoulos <nmav at gnutls.org>:
> David Mar?n Carre?o wrote:
>> Hi all.
>>
>> I am developing PKCS#8 import in gnoMint (http://gnomint.sf.net).
>>
>> For testing what are the error codes obtained while probing the type
>> of a given file, I have developed a little program that tries to
>> import a given file as a PEM-codified crypted and unencrypted PKCS8
>> file, and the same with DER format.
>>
>> The problem is that I am not able to import any PKCS#8 file, crypted
>> or unencrypted, DER or PEM. I have generated these PKCS#8 (attached)
>> files using gnutls (test-pem-crypt.pkcs8), openssl
>> (test-pem-uncrypt.pkcs8, and both test-der-*.pkcs8), and certtool
>> (test-pem-crypt2048.pkcs8).
>>
>> I am obtaining -207 (GNUTLS_E_BASE64_UNEXPECTED_HEADER_ERROR) while
>> trying to import a DER file as a PEM file, which is correct. But all
>> other combinations always result with an error -67
>> (GNUTLS_E_ASN1_ELEMENT_NOT_FOUND).
>
> It seems certtool cannot handle not encrypted PKCS #8 files properly.
> Moreover if run with -d 2 I can see that
> |<1>| PKCS encryption schema OID '1.2.840.113549.1.5.3' (DES-CBC) is
> unsupported.
>
> How did you encrypted this key?
>

The file test-pem-crypt.pkcs8 was created with libgnutls, with the function
gnutls_x509_privkey_export_pkcs8:

gnutls_x509_privkey_export_pkcs8 (key, GNUTLS_X509_FMT_PEM, "lalalala",
                                  GNUTLS_PKCS_USE_PKCS12_3DES, buffer,
                                  &buffer_len)

"key" is a private DSA key, also generated with libgnutls.

The file test-pem-crypt2048.pkcs8 was created with certtool, with the
command options:

certtool -8 -p > test-pem-crypt2048.pkcs8

The other files were created with openssl, importing test-pem-crypt.pkcs8
and exporting it into other formats.

>> Could anyone help me? Is the problem in the PKCS8 files, in my test
>> program, or in gnutls?
>
> It seems it's a combination of certtool issues and gnutls not supporting
>  DES-CBC for PKCS #8.
>

But it seems to support it while generating PKCS#8 files...

> regards,
> Nikos
>

Best regards,

-- 
David Mar?n Carre?o
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20081023/f44ce107/attachment.htm>

From nmav at gnutls.org  Thu Oct 23 15:57:13 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 23 Oct 2008 16:57:13 +0300
Subject: Possible bug in pkcs8 import
In-Reply-To: <f43cca2f0810222319l2be94455mc29fb5e9eb2b55fd@mail.gmail.com>
References: <f43cca2f0810210953g5e7a3b3dpbc6dbd948694f6b2@mail.gmail.com>	
	<48FF77B3.6060702@gnutls.org>
	<f43cca2f0810222319l2be94455mc29fb5e9eb2b55fd@mail.gmail.com>
Message-ID: <490082B9.5090905@gnutls.org>

David Mar?n Carre?o wrote:
> Hi all again.
> 2008/10/22 Nikos Mavrogiannopoulos <nmav at gnutls.org>:
>> David Mar?n Carre?o wrote:
>>> Hi all.
>>>
>>> I am developing PKCS#8 import in gnoMint (http://gnomint.sf.net).
>>>
>>> For testing what are the error codes obtained while probing the type
>>> of a given file, I have developed a little program that tries to
>>> import a given file as a PEM-codified crypted and unencrypted PKCS8
>>> file, and the same with DER format.
>>>
>>> The problem is that I am not able to import any PKCS#8 file, crypted
>>> or unencrypted, DER or PEM. I have generated these PKCS#8 (attached)
>>> files using gnutls (test-pem-crypt.pkcs8), openssl
>>> (test-pem-uncrypt.pkcs8, and both test-der-*.pkcs8), and certtool
>>> (test-pem-crypt2048.pkcs8).
>>>
>>> I am obtaining -207 (GNUTLS_E_BASE64_UNEXPECTED_HEADER_ERROR) while
>>> trying to import a DER file as a PEM file, which is correct. But all
>>> other combinations always result with an error -67
>>> (GNUTLS_E_ASN1_ELEMENT_NOT_FOUND).
>> It seems certtool cannot handle not encrypted PKCS #8 files properly.
>> Moreover if run with -d 2 I can see that
>> |<1>| PKCS encryption schema OID '1.2.840.113549.1.5.3' (DES-CBC) is
>> unsupported.
>>
>> How did you encrypted this key?
>>
> 
> The file test-pem-crypt.pkcs8 was created with libgnutls, with the function
> gnutls_x509_privkey_export_pkcs8:
> 
> gnutls_x509_privkey_export_pkcs8 (key, GNUTLS_X509_FMT_PEM, "lalalala",
>                                   GNUTLS_PKCS_USE_PKCS12_3DES, buffer,
>                                   &buffer_len)
> 
> "key" is a private DSA key, also generated with libgnutls.
> 
> The file test-pem-crypt2048.pkcs8 was created with certtool, with the
> command options:
> 
> certtool -8 -p > test-pem-crypt2048.pkcs8
> 
> The other files were created with openssl, importing test-pem-crypt.pkcs8
> and exporting it into other formats.

Wait. I though all the files were just the same encoded under different
formats. Please explain which files fail for you and what is the error
message you get with -d 2. I suppose you use certtool -k -8 to print the
keys?

If you use the latest version from the git repository are your issues
solved? (I committed a fix for certtool to decode decrypted pkcs8 files).

> 
>>> Could anyone help me? Is the problem in the PKCS8 files, in my test
>>> program, or in gnutls?
>> It seems it's a combination of certtool issues and gnutls not supporting
>>  DES-CBC for PKCS #8.
> But it seems to support it while generating PKCS#8 files...
It doesn't. gnutls doesn't support this algorithm, and the issues you
encounter in the files you attached are different since they are totally
different files. Please explain what issues you see and with which files.

regards,
Nikos




From simon at josefsson.org  Thu Oct 23 20:27:29 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 23 Oct 2008 20:27:29 +0200
Subject: GnuTLS regression test failing on OpenBSD/sparc64
In-Reply-To: <20081023180237.GF7744@lizzy.fr.homeunix.org> (Landry Breuil's
	message of "Thu, 23 Oct 2008 20:02:37 +0200")
References: <20081022145647.GD7744@lizzy.fr.homeunix.org>
	<878wsgekmn.fsf@mocca.josefsson.org>
	<20081023180237.GF7744@lizzy.fr.homeunix.org>
Message-ID: <87od1b6ub2.fsf@mocca.josefsson.org>

Landry Breuil <gaston at gcu.info> writes:

> On Wed, Oct 22, 2008 at 05:04:48PM +0200, Simon Josefsson wrote:
>> Landry Breuil <gaston at gcu.info> writes:
>> 
>> > Hi,
>> >
>> > after working on an update to latest libgcrypt, i'm in the process of
>> > updating GnuTLS in OpenBSD's ports-tree. It's currently building fine on
>> > sparc64, but i got an error in regression suite.
>> 
>> Hi.  Thanks for working on this.
>> 
>> > Bus error (core dumped)
>> > FAIL: rsa-md5-collision
>> > ===================================
>> > 1 of 1 tests failed
>> > Please report to bug-gnutls at gnu.org
>> > ===================================
>> >
>> > certtool is crashing badly due to symbol conflicts:
>> > WARNING: symbol(dig) size mismatch, relink your program
>> > /usr/obj/ports/gnutls-2.6.0/gnutls-2.6.0/src/.libs/certtool : WARNING:
>> > symbol(dig) size mismatch, relink your program
>> >
>> > The attached patch fixes the issue by avoiding name conflicts between
>> > two different variables of the same name and different types.
>> 
>> This has been fixed on the trunk in a better way, see:
>> 
>> http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=8080538ff60efe605727401bf37f270112703f46
>
> Hm, sorry but it seems not fixed for me.. i cherry picked you patch and
> still get the failing test here on amd64:
>
> /usr/obj/ports/gnutls-2.6.0/gnutls-2.6.0/src/.libs/certtool : WARNING:
> symbol(dig) size mismatch, relink your program
> Segmentation fault (core dumped) 
> FAIL: rsa-md5-collision

Did you recompile fipsmd5.c and re-link libgnutls-extra?

>> > I also noticed that two regress tests were failing to build when
>> > using included libtasn1, there's a missing -I$(top_srcdir)/lib/minitasn1/
>> > in tests/pkcs12-decode/Makefile.am and tests/Makefile.am
>> 
>> Also already fixed:
>> 
>> http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=3cbc220926c1490cbd726e63bb30efcd542c383e
>> http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=fbdc6734027077b1f3bf9864f3f3efc265cd91d0
>
> Cool, thanks. Anyway i'm now planning to use the updated libtasn1
> version we have in ports-tree.

That's the preferred approach, yes.

/Simon




From gaston at gcu.info  Thu Oct 23 20:02:37 2008
From: gaston at gcu.info (Landry Breuil)
Date: Thu, 23 Oct 2008 20:02:37 +0200
Subject: GnuTLS regression test failing on OpenBSD/sparc64
In-Reply-To: <878wsgekmn.fsf@mocca.josefsson.org>
References: <20081022145647.GD7744@lizzy.fr.homeunix.org>
	<878wsgekmn.fsf@mocca.josefsson.org>
Message-ID: <20081023180237.GF7744@lizzy.fr.homeunix.org>

On Wed, Oct 22, 2008 at 05:04:48PM +0200, Simon Josefsson wrote:
> Landry Breuil <gaston at gcu.info> writes:
> 
> > Hi,
> >
> > after working on an update to latest libgcrypt, i'm in the process of
> > updating GnuTLS in OpenBSD's ports-tree. It's currently building fine on
> > sparc64, but i got an error in regression suite.
> 
> Hi.  Thanks for working on this.
> 
> > Bus error (core dumped)
> > FAIL: rsa-md5-collision
> > ===================================
> > 1 of 1 tests failed
> > Please report to bug-gnutls at gnu.org
> > ===================================
> >
> > certtool is crashing badly due to symbol conflicts:
> > WARNING: symbol(dig) size mismatch, relink your program
> > /usr/obj/ports/gnutls-2.6.0/gnutls-2.6.0/src/.libs/certtool : WARNING:
> > symbol(dig) size mismatch, relink your program
> >
> > The attached patch fixes the issue by avoiding name conflicts between
> > two different variables of the same name and different types.
> 
> This has been fixed on the trunk in a better way, see:
> 
> http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=8080538ff60efe605727401bf37f270112703f46

Hm, sorry but it seems not fixed for me.. i cherry picked you patch and
still get the failing test here on amd64:

/usr/obj/ports/gnutls-2.6.0/gnutls-2.6.0/src/.libs/certtool : WARNING:
symbol(dig) size mismatch, relink your program
Segmentation fault (core dumped) 
FAIL: rsa-md5-collision

> > I also noticed that two regress tests were failing to build when
> > using included libtasn1, there's a missing -I$(top_srcdir)/lib/minitasn1/
> > in tests/pkcs12-decode/Makefile.am and tests/Makefile.am
> 
> Also already fixed:
> 
> http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=3cbc220926c1490cbd726e63bb30efcd542c383e
> http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=fbdc6734027077b1f3bf9864f3f3efc265cd91d0

Cool, thanks. Anyway i'm now planning to use the updated libtasn1
version we have in ports-tree.

Landry




From gaston at gcu.info  Thu Oct 23 21:04:35 2008
From: gaston at gcu.info (Landry Breuil)
Date: Thu, 23 Oct 2008 21:04:35 +0200
Subject: GnuTLS regression test failing on OpenBSD/sparc64
In-Reply-To: <87od1b6ub2.fsf@mocca.josefsson.org>
References: <20081022145647.GD7744@lizzy.fr.homeunix.org>
	<878wsgekmn.fsf@mocca.josefsson.org>
	<20081023180237.GF7744@lizzy.fr.homeunix.org>
	<87od1b6ub2.fsf@mocca.josefsson.org>
Message-ID: <20081023190435.GH7744@lizzy.fr.homeunix.org>

On Thu, Oct 23, 2008 at 08:27:29PM +0200, Simon Josefsson wrote:
> Landry Breuil <gaston at gcu.info> writes:
> 
> > On Wed, Oct 22, 2008 at 05:04:48PM +0200, Simon Josefsson wrote:
> >> Landry Breuil <gaston at gcu.info> writes:
> >> 
> >> > Hi,
> >> >
> >> > after working on an update to latest libgcrypt, i'm in the process of
> >> > updating GnuTLS in OpenBSD's ports-tree. It's currently building fine on
> >> > sparc64, but i got an error in regression suite.
> >> 
> >> Hi.  Thanks for working on this.
> >> 
> >> > Bus error (core dumped)
> >> > FAIL: rsa-md5-collision
> >> > ===================================
> >> > 1 of 1 tests failed
> >> > Please report to bug-gnutls at gnu.org
> >> > ===================================
> >> >
> >> > certtool is crashing badly due to symbol conflicts:
> >> > WARNING: symbol(dig) size mismatch, relink your program
> >> > /usr/obj/ports/gnutls-2.6.0/gnutls-2.6.0/src/.libs/certtool : WARNING:
> >> > symbol(dig) size mismatch, relink your program
> >> >
> >> > The attached patch fixes the issue by avoiding name conflicts between
> >> > two different variables of the same name and different types.
> >> 
> >> This has been fixed on the trunk in a better way, see:
> >> 
> >> http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=8080538ff60efe605727401bf37f270112703f46
> >
> > Hm, sorry but it seems not fixed for me.. i cherry picked you patch and
> > still get the failing test here on amd64:
> >
> > /usr/obj/ports/gnutls-2.6.0/gnutls-2.6.0/src/.libs/certtool : WARNING:
> > symbol(dig) size mismatch, relink your program
> > Segmentation fault (core dumped) 
> > FAIL: rsa-md5-collision
> 
> Did you recompile fipsmd5.c and re-link libgnutls-extra?

Indeeed.. my bad, i ran make clean, but forgot that there was an
installed version of it. With a clean system it's okay now with your
patch.

Thanks,
Landry




From simon at josefsson.org  Thu Oct 23 22:25:34 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 23 Oct 2008 22:25:34 +0200
Subject: GnuTLS regression test failing on OpenBSD/sparc64
In-Reply-To: <20081023190435.GH7744@lizzy.fr.homeunix.org> (Landry Breuil's
	message of "Thu, 23 Oct 2008 21:04:35 +0200")
References: <20081022145647.GD7744@lizzy.fr.homeunix.org>
	<878wsgekmn.fsf@mocca.josefsson.org>
	<20081023180237.GF7744@lizzy.fr.homeunix.org>
	<87od1b6ub2.fsf@mocca.josefsson.org>
	<20081023190435.GH7744@lizzy.fr.homeunix.org>
Message-ID: <87abcvnjnl.fsf@mocca.josefsson.org>

Landry Breuil <gaston at gcu.info> writes:

>> Did you recompile fipsmd5.c and re-link libgnutls-extra?
>
> Indeeed.. my bad, i ran make clean, but forgot that there was an
> installed version of it. With a clean system it's okay now with your
> patch.

Great, thanks for confirming that it solved the problem.  We should do a
v2.6.1 release... although I'll wait a few days to see if the PKCS#8
stuff needs a patch.

/Simon




From joe at manyfish.co.uk  Tue Oct 28 11:27:52 2008
From: joe at manyfish.co.uk (Joe Orton)
Date: Tue, 28 Oct 2008 10:27:52 +0000
Subject: Unparseable PKCS#12 cert
Message-ID: <20081028102752.GA28132@manyfish.co.uk>

Hi folks, I've attached a PKCS#12 file which was apparently produced by 
the Bouncy Castle Java crypto toolkit; GnuTLS 2.5.6 + libtasn1 1.3 can't 
parse it.  I haven't attempted to debug this any further.

OpenSSL can parse it, though PKCS12_parse() failed to pair up the key 
and cert correctly (instead giving the key and embedded CA cert), which 
is why I heard about this.  Just happened to try this cert with GnuTLS 
too.

$ bin/certtool --p12-info --infile ~/TestUser.p12  --inder
bin/certtool: p12_import: ASN1 parser: Error in TAG.

The encryption password is "password".

Regards, Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TestUser.p12
Type: application/octet-stream
Size: 2824 bytes
Desc: not available
URL: </pipermail/attachments/20081028/cf04cd26/attachment.obj>

From simon at josefsson.org  Tue Oct 28 11:53:20 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 28 Oct 2008 11:53:20 +0100
Subject: Code coverage report
Message-ID: <87wsft0z4u.fsf@mocca.josefsson.org>

All,

In git master you can now generate code coverage reports using 'make
coverage'.  You need the lcov tools.  Output is also available from:

http://www.gnu.org/software/gnutls/coverage/

The lib/* sub-directories are probably the most interesting.

It would be great if someone wants to contribute new self-tests that
exercises code paths that aren't tested right now.  Today the self-tests
invoke around 48.9% of the library, which could be improved.

/Simon




From simon at josefsson.org  Thu Oct 30 14:17:03 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 30 Oct 2008 14:17:03 +0100
Subject: Adding a configure.ac in lib/ and using AC_CONFIG_SUBDIR
Message-ID: <87r65yi5o0.fsf@mocca.josefsson.org>

I've run into some problems with gnulib for mingw, and the gnulib
recommended approach is that you need one config.h per gnulib-directory.

Right now we have lgl/ for the core libgnutls, libextra/gl/ for
libgnutls-extra, and gl/ for tools and self-tests.  So what is needed is
to move the libgnutls-specific configure.in code into a
lib/configure.ac, and the libgnutls-extra specific configure.in code
into a libextra/configure.ac.  This will make 'autoreconf' and
'configure' take slightly longer, but it allows us to cleanly separate
the projects various tasks, and will make gnulib module work again.

I think it is good timing to make this change early in the current 2.7.x
branch.

Any thoughts or objections?

/Simon




From n.mavrogiannopoulos at gmail.com  Thu Oct 30 14:25:02 2008
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Thu, 30 Oct 2008 15:25:02 +0200
Subject: Adding a configure.ac in lib/ and using AC_CONFIG_SUBDIR
In-Reply-To: <87r65yi5o0.fsf@mocca.josefsson.org>
References: <87r65yi5o0.fsf@mocca.josefsson.org>
Message-ID: <c331d99a0810300625k5bb829c6j546b337d55a1a40c@mail.gmail.com>

No objection from me.

On Thu, Oct 30, 2008 at 3:17 PM, Simon Josefsson <simon at josefsson.org> wrote:
> I've run into some problems with gnulib for mingw, and the gnulib
> recommended approach is that you need one config.h per gnulib-directory.
>
> Right now we have lgl/ for the core libgnutls, libextra/gl/ for
> libgnutls-extra, and gl/ for tools and self-tests.  So what is needed is
> to move the libgnutls-specific configure.in code into a
> lib/configure.ac, and the libgnutls-extra specific configure.in code
> into a libextra/configure.ac.  This will make 'autoreconf' and
> 'configure' take slightly longer, but it allows us to cleanly separate
> the projects various tasks, and will make gnulib module work again.
>
> I think it is good timing to make this change early in the current 2.7.x
> branch.
>
> Any thoughts or objections?
>
> /Simon
>




From simon at josefsson.org  Thu Oct 30 14:49:34 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 30 Oct 2008 14:49:34 +0100
Subject: Adding a configure.ac in lib/ and using AC_CONFIG_SUBDIR
In-Reply-To: <c331d99a0810300625k5bb829c6j546b337d55a1a40c@mail.gmail.com>
	(Nikos Mavrogiannopoulos's message of "Thu, 30 Oct 2008 15:25:02
	+0200")
References: <87r65yi5o0.fsf@mocca.josefsson.org>
	<c331d99a0810300625k5bb829c6j546b337d55a1a40c@mail.gmail.com>
Message-ID: <87k5bqi45t.fsf@mocca.josefsson.org>

Great, I'll work on this now.

/Simon

"Nikos Mavrogiannopoulos" <n.mavrogiannopoulos at gmail.com> writes:

> No objection from me.
>
> On Thu, Oct 30, 2008 at 3:17 PM, Simon Josefsson <simon at josefsson.org> wrote:
>> I've run into some problems with gnulib for mingw, and the gnulib
>> recommended approach is that you need one config.h per gnulib-directory.
>>
>> Right now we have lgl/ for the core libgnutls, libextra/gl/ for
>> libgnutls-extra, and gl/ for tools and self-tests.  So what is needed is
>> to move the libgnutls-specific configure.in code into a
>> lib/configure.ac, and the libgnutls-extra specific configure.in code
>> into a libextra/configure.ac.  This will make 'autoreconf' and
>> 'configure' take slightly longer, but it allows us to cleanly separate
>> the projects various tasks, and will make gnulib module work again.
>>
>> I think it is good timing to make this change early in the current 2.7.x
>> branch.
>>
>> Any thoughts or objections?
>>
>> /Simon
>>




From simon at josefsson.org  Thu Oct 30 19:08:08 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 30 Oct 2008 19:08:08 +0100
Subject: Adding a configure.ac in lib/ and using AC_CONFIG_SUBDIR
In-Reply-To: <87k5bqi45t.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Thu, 30 Oct 2008 14:49:34 +0100")
References: <87r65yi5o0.fsf@mocca.josefsson.org>
	<c331d99a0810300625k5bb829c6j546b337d55a1a40c@mail.gmail.com>
	<87k5bqi45t.fsf@mocca.josefsson.org>
Message-ID: <87fxmegdmf.fsf@mocca.josefsson.org>

Does anyone use --enable-dmalloc-mode or --enable-efence-mode?  I'm
inclined to remove them, they seem rather obsolete.

/Simon




From n.mavrogiannopoulos at gmail.com  Thu Oct 30 19:12:19 2008
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Thu, 30 Oct 2008 20:12:19 +0200
Subject: Adding a configure.ac in lib/ and using AC_CONFIG_SUBDIR
In-Reply-To: <87fxmegdmf.fsf@mocca.josefsson.org>
References: <87r65yi5o0.fsf@mocca.josefsson.org>	<c331d99a0810300625k5bb829c6j546b337d55a1a40c@mail.gmail.com>	<87k5bqi45t.fsf@mocca.josefsson.org>
	<87fxmegdmf.fsf@mocca.josefsson.org>
Message-ID: <4909F903.20201@gmail.com>

Simon Josefsson wrote:
> Does anyone use --enable-dmalloc-mode or --enable-efence-mode?  I'm
> inclined to remove them, they seem rather obsolete.

remove them. Last time I used them was in 2002.

regards,
Nikos




From joe at manyfish.co.uk  Thu Oct 30 20:20:44 2008
From: joe at manyfish.co.uk (Joe Orton)
Date: Thu, 30 Oct 2008 19:20:44 +0000
Subject: Unparseable PKCS#12 cert
In-Reply-To: <20081028102752.GA28132@manyfish.co.uk>
References: <20081028102752.GA28132@manyfish.co.uk>
Message-ID: <20081030192044.GA15612@manyfish.co.uk>

On Tue, Oct 28, 2008 at 10:27:52AM +0000, Joe Orton wrote:
> Hi folks, I've attached a PKCS#12 file which was apparently produced by 
> the Bouncy Castle Java crypto toolkit; GnuTLS 2.5.6 + libtasn1 1.3 can't 
> parse it.  I haven't attempted to debug this any further.

Apparently this can happen with certs exported from Firefox (NSS) too:

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

Regards, Joe




From n.mavrogiannopoulos at gmail.com  Thu Oct 30 21:48:07 2008
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Thu, 30 Oct 2008 22:48:07 +0200
Subject: Unparseable PKCS#12 cert
In-Reply-To: <20081030192044.GA15612@manyfish.co.uk>
References: <20081028102752.GA28132@manyfish.co.uk>
	<20081030192044.GA15612@manyfish.co.uk>
Message-ID: <c331d99a0810301348r391df23al8751c16bfe5cda63@mail.gmail.com>

I'll check these and let you know. PKCS #12 is quite complicated and
there can be issues like this. Thank you for reporting it.

regards,
Nikos

On Thu, Oct 30, 2008 at 9:20 PM, Joe Orton <joe at manyfish.co.uk> wrote:
> On Tue, Oct 28, 2008 at 10:27:52AM +0000, Joe Orton wrote:
>> Hi folks, I've attached a PKCS#12 file which was apparently produced by
>> the Bouncy Castle Java crypto toolkit; GnuTLS 2.5.6 + libtasn1 1.3 can't
>> parse it.  I haven't attempted to debug this any further.
>
> Apparently this can happen with certs exported from Firefox (NSS) too:
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=503833
>
> Regards, Joe
>
>
> _______________________________________________
> Gnutls-devel mailing list
> Gnutls-devel at gnu.org
> http://lists.gnu.org/mailman/listinfo/gnutls-devel
>




From simon at josefsson.org  Fri Oct 31 00:18:45 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 31 Oct 2008 00:18:45 +0100
Subject: GnuTLS 2.7.1
Message-ID: <87k5bpekoa.fsf@mocca.josefsson.org>

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

Here are the compressed sources:
  http://alpha.gnu.org/gnu/gnutls/gnutls-2.7.1.tar.bz2 (5.6MB)
  ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.7.1.tar.bz2

Here is the OpenPGP signature:
  http://alpha.gnu.org/gnu/gnutls/gnutls-2.7.1.tar.bz2.sig
  ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.7.1.tar.bz2.sig

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.

/Simon

* Version 2.7.1 (released 2008-10-30)

** certtool: print a PKCS #8 key even if it is not encrypted.

** Old libgnutls.m4 and libgnutls-config scripts removed.
Please use pkg-config instead.

** Configuration system modified.
There is now a configure script in lib/ and libextra/ as well, because
gnulib works better with a config.h per gnulib directory.

** 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: 419 bytes
Desc: not available
URL: </pipermail/attachments/20081031/2890bed6/attachment.pgp>

From wk at gnupg.org  Fri Oct 31 14:41:41 2008
From: wk at gnupg.org (Werner Koch)
Date: Fri, 31 Oct 2008 14:41:41 +0100
Subject: Unparseable PKCS#12 cert
In-Reply-To: <c331d99a0810301348r391df23al8751c16bfe5cda63@mail.gmail.com>
	(Nikos Mavrogiannopoulos's message of "Thu, 30 Oct 2008 22:48:07
	+0200")
References: <20081028102752.GA28132@manyfish.co.uk>
	<20081030192044.GA15612@manyfish.co.uk>
	<c331d99a0810301348r391df23al8751c16bfe5cda63@mail.gmail.com>
Message-ID: <87r65wx4oa.fsf@wheatstone.g10code.de>

On Thu, 30 Oct 2008 21:48, n.mavrogiannopoulos at gmail.com said:
> I'll check these and let you know. PKCS #12 is quite complicated and
> there can be issues like this. Thank you for reporting it.

I had the same problem wa few years ago with Mozilla exported files.
See gnupg/agent/minip12.c.  IIRC, there are some comments related to
Mozilla.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.