From nmav at gnutls.org  Tue Jul  3 00:19:13 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 03 Jul 2012 00:19:13 +0200
Subject: gnutls 3.0.21
Message-ID: <4FF21E61.8040309@gnutls.org>

Hello,
 I've just released gnutls 3.0.21. This is a minor feature update and
bug-fix release on the current stable branch.


* Version 3.0.21 (released 2012-07-02)

** libgnutls: fixed bug in gnutls_x509_privkey_import()
that prevented the loading of EC private keys when DER
encoded. Reported by David Woodhouse.

** libgnutls: In DTLS larger to mtu records result to
GNUTLS_E_LARGE_PACKET instead of being truncated.

** libgnutls: gnutls_dtls_get_data_mtu() is more precise. Based
on patch by David Woodhouse.

** libgnutls: Fixed memory leak in PKCS #8 key import.

** libgnutls: Added support for an old version of the DTLS protocol
used by openconnect vpn client for compatibility with Cisco's AnyConnect
SSL VPN. It is marked as GNUTLS_DTLS0_9. Do not use it for newer protocols
as it has issues.

** libgnutls: Corrected bug that prevented resolving PKCS #11 URLs
if only the label is specified. Patch by David Woodhouse.

** libgnutls: When EMSGSIZE errno is seen then GNUTLS_E_LARGE_PACKET
is returned.

** API and ABI modifications:
gnutls_dtls_set_data_mtu: Added
gnutls_session_set_premaster: Added




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

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

Here are the XZ compressed sources:

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

Here are the LZIP compressed sources:

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

Here are OpenPGP detached signatures signed using key 0x96865171:

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

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

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

regards,
Nikos



From mabrand at mabrand.nl  Tue Jul  3 09:58:01 2012
From: mabrand at mabrand.nl (Mark Brand)
Date: Tue, 03 Jul 2012 09:58:01 +0200
Subject: CertEnumCRLsInStore not supplied by MinGW
Message-ID: <4FF2A609.5050308@mabrand.nl>

Hi,

I just wanted to mention that CertEnumCRLsInStore does not seem to be 
supplied by MinGW. Since gnutls-3.0.20, this breaks the build on MinGW 
(mingw.org).

In the 3.0.21 release (and tag gnutls_3_0_21_real) it appears here:

   gnutls-3.0.21/lib/gnutls_x509.c:1614:      crl = 
CertEnumCRLsInStore(store, NULL);
   gnutls-3.0.21/lib/gnutls_x509.c:1637:          crl = 
CertEnumCRLsInStore(store, crl);

In the master branch, it appears here:

   lib/system.c:399:    crl = CertEnumCRLsInStore(store, NULL);
   lib/system.c:421:        crl = CertEnumCRLsInStore(store, crl);

Is there a good way to deal with this?

regards,

Mark




From nmav at gnutls.org  Tue Jul  3 10:02:58 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 3 Jul 2012 10:02:58 +0200
Subject: CertEnumCRLsInStore not supplied by MinGW
In-Reply-To: <4FF2A609.5050308@mabrand.nl>
References: <4FF2A609.5050308@mabrand.nl>
Message-ID: <CAJU7zaK1tJJ2YiWWG00yszzY-NKg6KFmvZDp+hbAqUErUdRxFQ@mail.gmail.com>

On Tue, Jul 3, 2012 at 9:58 AM, Mark Brand <mabrand at mabrand.nl> wrote:
> Hi,
>
> I just wanted to mention that CertEnumCRLsInStore does not seem to be
> supplied by MinGW. Since gnutls-3.0.20, this breaks the build on MinGW
> (mingw.org).

Hello,
 Which mingw have you tried? Did you try mingw64?
You could also use the pre-build mingw binaries at
ftp://ftp.gnu.org/gnu/gnutls/w32/ (no 3.0.21 yet though).

regards,
Nikos



From mabrand at mabrand.nl  Tue Jul  3 10:13:18 2012
From: mabrand at mabrand.nl (Mark Brand)
Date: Tue, 03 Jul 2012 10:13:18 +0200
Subject: CertEnumCRLsInStore not supplied by MinGW
In-Reply-To: <CAJU7zaK1tJJ2YiWWG00yszzY-NKg6KFmvZDp+hbAqUErUdRxFQ@mail.gmail.com>
References: <4FF2A609.5050308@mabrand.nl>
	<CAJU7zaK1tJJ2YiWWG00yszzY-NKg6KFmvZDp+hbAqUErUdRxFQ@mail.gmail.com>
Message-ID: <4FF2A99E.9040204@mabrand.nl>

Nikos Mavrogiannopoulos wrote:
> On Tue, Jul 3, 2012 at 9:58 AM, Mark Brand <mabrand at mabrand.nl> wrote:
>> Hi,
>>
>> I just wanted to mention that CertEnumCRLsInStore does not seem to be
>> supplied by MinGW. Since gnutls-3.0.20, this breaks the build on MinGW
>> (mingw.org).
> Hello,
>   Which mingw have you tried? Did you try mingw64?
> You could also use the pre-build mingw binaries at
> ftp://ftp.gnu.org/gnu/gnutls/w32/ (no 3.0.21 yet though).

This is about the "official" MinGW at mingw.org. The issue comes up for 
MXE (previously called mingw-cross-env), which is based on MinGW and 
builds static versions of many libraries including gnutls.

It appears that mingw-w64 does have CertEnumCRLsInStore:
http://mingw-w64.sourcearchive.com/documentation/0~20100125-3/wincrypt_8h-source.html

Mark



From nmav at gnutls.org  Tue Jul  3 11:24:55 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 3 Jul 2012 11:24:55 +0200
Subject: CertEnumCRLsInStore not supplied by MinGW
In-Reply-To: <4FF2A99E.9040204@mabrand.nl>
References: <4FF2A609.5050308@mabrand.nl>
	<CAJU7zaK1tJJ2YiWWG00yszzY-NKg6KFmvZDp+hbAqUErUdRxFQ@mail.gmail.com>
	<4FF2A99E.9040204@mabrand.nl>
Message-ID: <CAJU7za+M25PsZDdBU=R64EcZtB6CGdP78VEP=A9LXCfYW-V_Ww@mail.gmail.com>

On Tue, Jul 3, 2012 at 10:13 AM, Mark Brand <mabrand at mabrand.nl> wrote:

>>> I just wanted to mention that CertEnumCRLsInStore does not seem to be
>>> supplied by MinGW. Since gnutls-3.0.20, this breaks the build on MinGW
>>> (mingw.org).
>> Hello,
>>   Which mingw have you tried? Did you try mingw64?
>> You could also use the pre-build mingw binaries at
>> ftp://ftp.gnu.org/gnu/gnutls/w32/ (no 3.0.21 yet though).
> This is about the "official" MinGW at mingw.org. The issue comes up for MXE
> (previously called mingw-cross-env), which is based on MinGW and builds
> static versions of many libraries including gnutls.

Is there something we can do to fix it in gnutls or should I just
assume it is a mingw quirk and suggest mingw-w64?

regards,
Nikos



From mabrand at mabrand.nl  Tue Jul  3 13:59:22 2012
From: mabrand at mabrand.nl (Mark Brand)
Date: Tue, 03 Jul 2012 13:59:22 +0200
Subject: CertEnumCRLsInStore not supplied by MinGW
In-Reply-To: <CAJU7za+M25PsZDdBU=R64EcZtB6CGdP78VEP=A9LXCfYW-V_Ww@mail.gmail.com>
References: <4FF2A609.5050308@mabrand.nl>
	<CAJU7zaK1tJJ2YiWWG00yszzY-NKg6KFmvZDp+hbAqUErUdRxFQ@mail.gmail.com>
	<4FF2A99E.9040204@mabrand.nl>
	<CAJU7za+M25PsZDdBU=R64EcZtB6CGdP78VEP=A9LXCfYW-V_Ww@mail.gmail.com>
Message-ID: <4FF2DE9A.7090508@mabrand.nl>

Nikos Mavrogiannopoulos wrote:
> On Tue, Jul 3, 2012 at 10:13 AM, Mark Brand <mabrand at mabrand.nl> wrote:
>
>>>> I just wanted to mention that CertEnumCRLsInStore does not seem to be
>>>> supplied by MinGW. Since gnutls-3.0.20, this breaks the build on MinGW
>>>> (mingw.org).
>>> Hello,
>>>    Which mingw have you tried? Did you try mingw64?
>>> You could also use the pre-build mingw binaries at
>>> ftp://ftp.gnu.org/gnu/gnutls/w32/ (no 3.0.21 yet though).
>> This is about the "official" MinGW at mingw.org. The issue comes up for MXE
>> (previously called mingw-cross-env), which is based on MinGW and builds
>> static versions of many libraries including gnutls.
> Is there something we can do to fix it in gnutls or should I just
> assume it is a mingw quirk and suggest mingw-w64?

I think the w32api in MinGW could use an update. I mentioned this on 
their list. Maybe it's best to wait and see what they say.

Mark



From eliz at gnu.org  Tue Jul  3 17:43:24 2012
From: eliz at gnu.org (Eli Zaretskii)
Date: Tue, 03 Jul 2012 18:43:24 +0300
Subject: CertEnumCRLsInStore not supplied by MinGW
In-Reply-To: <4FF2DE9A.7090508@mabrand.nl>
References: <4FF2A609.5050308@mabrand.nl>
	<CAJU7zaK1tJJ2YiWWG00yszzY-NKg6KFmvZDp+hbAqUErUdRxFQ@mail.gmail.com>
	<4FF2A99E.9040204@mabrand.nl>
	<CAJU7za+M25PsZDdBU=R64EcZtB6CGdP78VEP=A9LXCfYW-V_Ww@mail.gmail.com>
	<4FF2DE9A.7090508@mabrand.nl>
Message-ID: <837guk6ear.fsf@gnu.org>

> Date: Tue, 03 Jul 2012 13:59:22 +0200
> From: Mark Brand <mabrand at mabrand.nl>
> Cc: GnuTLS development list <gnutls-devel at gnu.org>
> 
> > Is there something we can do to fix it in gnutls or should I just
> > assume it is a mingw quirk and suggest mingw-w64?
> 
> I think the w32api in MinGW could use an update.

Does it work to link against crypt32.dll?



From mabrand at mabrand.nl  Tue Jul  3 20:12:08 2012
From: mabrand at mabrand.nl (Mark Brand)
Date: Tue, 03 Jul 2012 20:12:08 +0200
Subject: CertEnumCRLsInStore not supplied by MinGW
In-Reply-To: <837guk6ear.fsf@gnu.org>
References: <4FF2A609.5050308@mabrand.nl>
	<CAJU7zaK1tJJ2YiWWG00yszzY-NKg6KFmvZDp+hbAqUErUdRxFQ@mail.gmail.com>
	<4FF2A99E.9040204@mabrand.nl>
	<CAJU7za+M25PsZDdBU=R64EcZtB6CGdP78VEP=A9LXCfYW-V_Ww@mail.gmail.com>
	<4FF2DE9A.7090508@mabrand.nl> <837guk6ear.fsf@gnu.org>
Message-ID: <4FF335F8.4000107@mabrand.nl>


Eli Zaretskii wrote:
>> Date: Tue, 03 Jul 2012 13:59:22 +0200
>> From: Mark Brand <mabrand at mabrand.nl>
>> Cc: GnuTLS development list <gnutls-devel at gnu.org>
>>
>>> Is there something we can do to fix it in gnutls or should I just
>>> assume it is a mingw quirk and suggest mingw-w64?
>> I think the w32api in MinGW could use an update.
> Does it work to link against crypt32.dll?

I haven't tried it, but have every reason to believe that should work.

Mark



From eliz at gnu.org  Tue Jul  3 20:23:04 2012
From: eliz at gnu.org (Eli Zaretskii)
Date: Tue, 03 Jul 2012 21:23:04 +0300
Subject: CertEnumCRLsInStore not supplied by MinGW
In-Reply-To: <4FF335F8.4000107@mabrand.nl>
References: <4FF2A609.5050308@mabrand.nl>
	<CAJU7zaK1tJJ2YiWWG00yszzY-NKg6KFmvZDp+hbAqUErUdRxFQ@mail.gmail.com>
	<4FF2A99E.9040204@mabrand.nl>
	<CAJU7za+M25PsZDdBU=R64EcZtB6CGdP78VEP=A9LXCfYW-V_Ww@mail.gmail.com>
	<4FF2DE9A.7090508@mabrand.nl> <837guk6ear.fsf@gnu.org>
	<4FF335F8.4000107@mabrand.nl>
Message-ID: <83pq8c4sc7.fsf@gnu.org>

> Date: Tue, 03 Jul 2012 20:12:08 +0200
> From: Mark Brand <mabrand at mabrand.nl>
> CC: nmav at gnutls.org, gnutls-devel at gnu.org
> 
> 
> Eli Zaretskii wrote:
> >> Date: Tue, 03 Jul 2012 13:59:22 +0200
> >> From: Mark Brand <mabrand at mabrand.nl>
> >> Cc: GnuTLS development list <gnutls-devel at gnu.org>
> >>
> >>> Is there something we can do to fix it in gnutls or should I just
> >>> assume it is a mingw quirk and suggest mingw-w64?
> >> I think the w32api in MinGW could use an update.
> > Does it work to link against crypt32.dll?
> 
> I haven't tried it, but have every reason to believe that should work.

Than this is something the gnutls project could do to un-break the
MinGW build, I think.



From scottm at aero.org  Tue Jul 10 18:34:42 2012
From: scottm at aero.org (B. Scott Michel)
Date: Tue, 10 Jul 2012 09:34:42 -0700
Subject: CertEnumCRLsInStore not supplied by MinGW
In-Reply-To: <4FF2DE9A.7090508@mabrand.nl>
References: <4FF2A609.5050308@mabrand.nl>
	<CAJU7zaK1tJJ2YiWWG00yszzY-NKg6KFmvZDp+hbAqUErUdRxFQ@mail.gmail.com>
	<4FF2A99E.9040204@mabrand.nl>
	<CAJU7za+M25PsZDdBU=R64EcZtB6CGdP78VEP=A9LXCfYW-V_Ww@mail.gmail.com>
	<4FF2DE9A.7090508@mabrand.nl>
Message-ID: <4FFC59A2.4020802@aero.org>

On 7/3/2012 4:59 AM, Mark Brand wrote:
> Nikos Mavrogiannopoulos wrote:
>> On Tue, Jul 3, 2012 at 10:13 AM, Mark Brand <mabrand at mabrand.nl> wrote:
>>
>>>>> I just wanted to mention that CertEnumCRLsInStore does not seem to be
>>>>> supplied by MinGW. Since gnutls-3.0.20, this breaks the build on 
>>>>> MinGW
>>>>> (mingw.org).
>>>> Hello,
>>>>    Which mingw have you tried? Did you try mingw64?
>>>> You could also use the pre-build mingw binaries at
>>>> ftp://ftp.gnu.org/gnu/gnutls/w32/ (no 3.0.21 yet though).
>>> This is about the "official" MinGW at mingw.org. The issue comes up 
>>> for MXE
>>> (previously called mingw-cross-env), which is based on MinGW and builds
>>> static versions of many libraries including gnutls.
>> Is there something we can do to fix it in gnutls or should I just
>> assume it is a mingw quirk and suggest mingw-w64?
>
> I think the w32api in MinGW could use an update. I mentioned this on 
> their list. Maybe it's best to wait and see what they say.
I'm going to hazard a guess that you're going to have this problem 
regardless of whether you use mingw or mingw-64. CertEnumCRLsInStore is 
probably not marked for export.


-scooter



From kelly at silka.with-linux.com  Sun Jul 15 18:16:49 2012
From: kelly at silka.with-linux.com (Kelly Anderson)
Date: Sun, 15 Jul 2012 10:16:49 -0600
Subject: [PATCH] hardware crypto in GnuTls 3.X
Message-ID: <5002ECF1.4040302@silka.with-linux.com>

Hello,

I recently enable GnuTls hardware crypto on my Marvell Dove CPU.
Unfortunately the benchmarks indicated the same speed for
benchmark-ciphers as benchmark-soft-ciphers.

So I started adding printf's to the code until I figured out
what the problem was.  It turns out the logic that decides
whether the algorithms are hardware enabled has inverted logic.
So removing three "!"s fixed the problem.  I've listed the benchmark
results with the patched GnuTls after the patch.  This does not
affect GnuTls 2.X since it does not check to see if the algorithms
are hardware enabled.


--- ./lib/accelerated/cryptodev.c.orig    2012-04-12 14:05:11.000000000 
-0600
+++ ./lib/accelerated/cryptodev.c    2012-07-12 21:52:07.796464191 -0600
@@ -208,7 +208,7 @@ register_crypto (int cfd)
        siop.ses = sess.ses; /* do not register ciphers that are not hw 
accelerated */
        if (ioctl(cfd, CIOCGSESSINFO, &siop) == 0)
          {
-          if (!(siop.flags & SIOP_FLAG_KERNEL_DRIVER_ONLY))
+          if ( (siop.flags & SIOP_FLAG_KERNEL_DRIVER_ONLY) )
              {
                ioctl (cfd, CIOCFSESSION, &sess.ses);
                continue;
@@ -441,7 +441,7 @@ register_mac_digest (int cfd)
        siop.ses = sess.ses; /* do not register ciphers that are not hw 
accelerated */
        if (ioctl(cfd, CIOCGSESSINFO, &siop) == 0)
          {
-          if (!(siop.flags & SIOP_FLAG_KERNEL_DRIVER_ONLY))
+          if ( (siop.flags & SIOP_FLAG_KERNEL_DRIVER_ONLY) )
              {
                ioctl (cfd, CIOCFSESSION, &sess.ses);
                continue;
@@ -480,7 +480,7 @@ register_mac_digest (int cfd)
        siop.ses = sess.ses;
        if (ioctl(cfd, CIOCGSESSINFO, &siop) == 0)
          {
-          if (!(siop.flags & SIOP_FLAG_KERNEL_DRIVER_ONLY))
+          if ( (siop.flags & SIOP_FLAG_KERNEL_DRIVER_ONLY) )
              {
                ioctl (cfd, CIOCFSESSION, &sess.ses);
                continue;



  gnutls-cli --benchmark-ciphers
Checking AES-128-CBC with SHA1 (16kb payload)... Processed 20.77 MB in 
2.00 secs: 10.38 MB/sec
Checking AES-128-CBC with SHA256 (16kb payload)... Processed 16.25 MB in 
2.00 secs: 8.13 MB/sec
Checking AES-128-GCM (16kb payload)... Processed 14.53 MB in 2.00 secs: 
7.26 MB/sec
Checking SHA1 (16kb payload)... Processed 84.48 MB in 2.00 secs: 42.22 
MB/sec
Checking SHA256 (16kb payload)... Processed 40.80 MB in 2.00 secs: 20.40 
MB/sec
Checking SHA512 (16kb payload)... Processed 10.35 MB in 2.00 secs: 5.17 
MB/sec
Checking 3DES-CBC (16kb payload)... Processed 8.09 MB in 2.00 secs: 4.04 
MB/sec
Checking AES-128-CBC (16kb payload)... Processed 32.85 MB in 2.00 secs: 
16.42 MB/sec
Checking ARCFOUR-128 (16kb payload)... Processed 74.99 MB in 2.00 secs: 
37.49 MB/sec

gnutls-cli --benchmark-soft-ciphers
Checking AES-128-CBC with SHA1 (16kb payload)... Processed 15.52 MB in 
2.00 secs: 7.75 MB/sec
Checking AES-128-CBC with SHA256 (16kb payload)... Processed 11.86 MB in 
2.00 secs: 5.93 MB/sec
Checking AES-128-GCM (16kb payload)... Processed 15.34 MB in 2.00 secs: 
7.66 MB/sec
Checking SHA1 (16kb payload)... Processed 67.22 MB in 2.00 secs: 33.61 
MB/sec
Checking SHA256 (16kb payload)... Processed 32.65 MB in 2.00 secs: 16.33 
MB/sec
Checking SHA512 (16kb payload)... Processed 9.55 MB in 2.00 secs: 4.78 
MB/sec
Checking 3DES-CBC (16kb payload)... Processed 5.21 MB in 2.00 secs: 2.60 
MB/sec
Checking AES-128-CBC (16kb payload)... Processed 19.87 MB in 2.00 secs: 
9.93 MB/sec
Checking ARCFOUR-128 (16kb payload)... Processed 73.88 MB in 2.00 secs: 
36.94 MB/sec


Regards,

Kelly Anderson



From nmav at gnutls.org  Mon Jul 16 09:17:31 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 16 Jul 2012 09:17:31 +0200
Subject: [PATCH] hardware crypto in GnuTls 3.X
In-Reply-To: <5002ECF1.4040302@silka.with-linux.com>
References: <5002ECF1.4040302@silka.with-linux.com>
Message-ID: <5003C00B.1020009@gnutls.org>

On 07/15/2012 06:16 PM, Kelly Anderson wrote:

> Hello,
> 
> I recently enable GnuTls hardware crypto on my Marvell Dove CPU.
> Unfortunately the benchmarks indicated the same speed for

> benchmark-ciphers as benchmark-soft-ciphers.

Hello,
 Which version of cryptodev-linux do you use? The latest should work
with the SIOP_FLAG_KERNEL_DRIVER_ONLY. The test is there to prevent
software ciphers included in the kernel from being used by cryptodev.

regards,
Nikos



From INVALID.NOREPLY at gnu.org  Wed Jul 18 18:57:00 2012
From: INVALID.NOREPLY at gnu.org (Alexandre Chataignon)
Date: Wed, 18 Jul 2012 16:57:00 +0000
Subject: [sr #108090] Unable to decode PKCS12 with NULL password since 3.0.20
Message-ID: <20120718-165700.sv88698.84726@savannah.gnu.org>

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

                 Summary: Unable to decode PKCS12 with NULL password since
3.0.20
                 Project: GnuTLS
            Submitted by: xouillet
            Submitted on: Wed 18 Jul 2012 04:56:59 PM GMT
                Category: Core library
                Priority: 5 - Normal
                Severity: 3 - Normal
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
        Operating System: None

    _______________________________________________________

Details:

Since gnutls 3.0.20, decoding of PKCS12 with a NULL password (NULL, not "") is
impossible.

For example this line used to work in gnutls-3.0.19 :
ret = gnutls_certificate_set_x509_simple_pkcs12_file(xcred, pkcs12_f,
GNUTLS_X509_FMT_DER, NULL) ;

The problem comes from line : 
lib/x509/privkey_pkcs8.c:1231:  if (password == NULL || (flags &
GNUTLS_PKCS_PLAIN))

that used to be 
lib/x509/privkey_pkcs8.c:1231:  if (flags & GNUTLS_PKCS_PLAIN)

PKCS12 file with NULL password can be easily generated via openssl library,
for example with this python snippet :

  from OpenSSL import crypto
  key  = crypto.load_privatekey(crypto.FILETYPE_PEM, 
open("mycert.key").read())
  cert = crypto.load_certificate(crypto.FILETYPE_PEM,
open("mycert.crt").read())

  p12 = crypto.PKCS12()
  p12.set_certificate(cert)
  p12.set_privatekey(key)
  open("test.p12",'w').write(p12.export())





    _______________________________________________________

Reply to this item at:

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

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




From bgurup.ndk at gmail.com  Thu Jul 19 06:44:46 2012
From: bgurup.ndk at gmail.com (Guru Prasad)
Date: Thu, 19 Jul 2012 10:14:46 +0530
Subject: Issue in SSL/TLS connection setup
Message-ID: <CADOz54hR6_9iuKEVR93bh0hOiX1PaFZ4bqsGGmK82-Kyi1TSxw@mail.gmail.com>

I am facing SSL/TLS connection setup issue with python-twisted (12.0.0) and
python-gnutls(1.1.9). Version of Ubuntu (unstable), I am using is: 12.10
During the SSL/TLS connection setup, there is ClientHello request from the
client and for this request there is no response from the server where
Twisted and GnuTLS are running.
I see only TCP FIN and RST sent by the server end for the ClientHello
request.

When I checked the syslog, I see below messages.

 Traceback (most recent call last):
:   File "/usr/lib/python2.7/dist-
packages/twisted/python/log.py", line 84, in callWithLogger
:     return callWithContext({"system": lp}, func, *args, **kw)
:   File "/usr/lib/python2.7/dist-packages/twisted/python/log.py", line 69,
in callWithContext
:     return context.call({ILogContext: newCtx}, func, *args, **kw)
:   File "/usr/lib/python2.7/dist-packages/twisted/python/context.py", line
118, in callWithContext
:     return self.currentContext().callWithContext(ctx, func, *args, **kw)
:   File "/usr/lib/python2.7/dist-packages/twisted/python/context.py", line
81, in callWithContext
:     return func(*args,**kw)
:   File "/usr/lib/python2.7/dist-packages/twisted/internet/posixbase.py",
line 599, in _doReadOrWrite
:     self._disconnectSelectable(selectable, why, inRead)
:   File "/usr/lib/python2.7/dist-packages/twisted/internet/posixbase.py",
line 266, in _disconnectSelectable
:     selectable.connectionLost(failure.Failure(why))
:   File
"/usr/local/lib/python2.7/dist-packages/gnutls/interfaces/twisted/__init__.py",
line 328, in connectionLost
:     tcp.Server.connectionLost(self, reason)
:   File "/usr/lib/python2.7/dist-packages/twisted/internet/tcp.py", line
277, in connectionLost
:     protocol.connectionLost(reason)
:   File "/usr/lib/python2.7/dist-packages/twisted/web2/channel/http.py",
line 853, in connectionLost
:     self.readConnectionLost()
:   File "/usr/lib/python2.7/dist-packages/twisted/web2/channel/http.py",
line 842, in readConnectionLost
:     self.transport.loseConnection()
:   File
"/usr/local/lib/python2.7/dist-packages/gnutls/interfaces/twisted/__init__.py",
line 322, in loseConnection
:     tcp.Server.loseConnection(self, reason)
: TypeError: loseConnection() takes exactly 1 argument (2 given)

Anyone else has faced this issue, earlier? Is this a bug in GnuTLS package?
I am not having any clue like what went wrong. Have I missed anything which
is required?
Please help me to come out of this issue.

--bgurup
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20120719/4bee9951/attachment.htm>

From RobMcMahonCV at gmail.com  Thu Jul 19 18:08:58 2012
From: RobMcMahonCV at gmail.com (Rob McMahon)
Date: Thu, 19 Jul 2012 17:08:58 +0100
Subject: Compilation problems on Solaris 10
Message-ID: <5008311A.7070506@gmail.com>

Solaris 10,
cc: Sun WorkShop 6 update 2 C 5.3 Patch 111679-12 2003/05/18
gnutls-3.0.21

The file lib/nettle/cipher.c fails to compile saying

   CC     cipher.lo
"cipher.c", line 93: void function cannot return value
"cipher.c", line 101: void function cannot return value
cc: acomp failed for cipher.c

_gcm_encrypt and_gcm_decrypt are declared void. gcm_aes_encrypt 
andgcm_aes_decrypt are also void functions in libnettle.

 > rcsdiff -u5 cipher.c
===================================================================
RCS file: cipher.c,v
retrieving revision 1.1
diff -u5 -r1.1 cipher.c
--- cipher.c    2012/07/19 14:45:28     1.1
+++ cipher.c    2012/07/19 14:45:52
@@ -88,19 +88,19 @@
  static void _gcm_encrypt(void *_ctx, nettle_crypt_func f,
              unsigned block_size, uint8_t *iv,
              unsigned length, uint8_t *dst,
              const uint8_t *src)
  {
-  return gcm_aes_encrypt(_ctx, length, dst, src);
+  gcm_aes_encrypt(_ctx, length, dst, src);
  }

  static void _gcm_decrypt(void *_ctx, nettle_crypt_func f,
              unsigned block_size, uint8_t *iv,
              unsigned length, uint8_t *dst,
              const uint8_t *src)
  {
-  return gcm_aes_decrypt(_ctx, length, dst, src);
+  gcm_aes_decrypt(_ctx, length, dst, src);
  }

  static int wrap_nettle_cipher_exists(gnutls_cipher_algorithm_t algo)
  {
    switch (algo)
Exit 1


The two test files openpgp-auth.c fail to compile with "alloca 
undefined".  They need to #include <alloca.h>:

 > rcsdiff -u openpgp-auth*.c,v
===================================================================
RCS file: openpgp-auth.c,v
retrieving revision 1.1
diff -u -r1.1 openpgp-auth.c
--- openpgp-auth.c      2012/07/19 15:16:54     1.1
+++ openpgp-auth.c      2012/07/19 15:17:44
@@ -39,6 +39,9 @@
  #include <string.h>
  #include <errno.h>
  #include <stdio.h>
+#ifdef HAVE_ALLOCA_H
+#include <alloca.h>
+#endif
  #if !defined(_WIN32)
  static const char message[] = "Hello, brave GNU world!";

===================================================================
RCS file: openpgp-auth2.c,v
retrieving revision 1.1
diff -u -r1.1 openpgp-auth2.c
--- openpgp-auth2.c     2012/07/19 15:19:27     1.1
+++ openpgp-auth2.c     2012/07/19 15:19:54
@@ -39,7 +39,9 @@
  #include <string.h>
  #include <errno.h>
  #include <stdio.h>
-
+#ifdef HAVE_ALLOCA_H
+#include <alloca.h>
+#endif

  /* This is the same test as openpgp-auth but tests
   * openpgp under the latest TLS protocol (TLSv1.2). In
Exit 1

Cheers,

Rob

-- 
E-Mail:	Rob.McMahon at warwick.ac.uk		PHONE:  +44 24 7652 3037
Rob McMahon, IT Services, Warwick University, Coventry, CV4 7AL, England




From nmav at gnutls.org  Thu Jul 19 21:00:55 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 19 Jul 2012 21:00:55 +0200
Subject: Compilation problems on Solaris 10
In-Reply-To: <5008311A.7070506@gmail.com>
References: <5008311A.7070506@gmail.com>
Message-ID: <50085967.7090503@gnutls.org>

Thank you. I've applied your first fix and solved differently the
alloca() issue.

regards,
Nikos

On 07/19/2012 06:08 PM, Rob McMahon wrote:

> Solaris 10,
> cc: Sun WorkShop 6 update 2 C 5.3 Patch 111679-12 2003/05/18
> gnutls-3.0.21
> 
> The file lib/nettle/cipher.c fails to compile saying
> 
>   CC     cipher.lo
> "cipher.c", line 93: void function cannot return value
> "cipher.c", line 101: void function cannot return value
> cc: acomp failed for cipher.c
> 
> _gcm_encrypt and_gcm_decrypt are declared void. gcm_aes_encrypt
> andgcm_aes_decrypt are also void functions in libnettle.





From INVALID.NOREPLY at gnu.org  Thu Jul 19 22:15:10 2012
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Thu, 19 Jul 2012 20:15:10 +0000
Subject: [sr #108090] Unable to decode PKCS12 with NULL password since 3.0.20
In-Reply-To: <20120718-165700.sv88698.84726@savannah.gnu.org>
References: <20120718-165700.sv88698.84726@savannah.gnu.org>
Message-ID: <20120719-231510.sv707.61446@savannah.gnu.org>

Update of sr #108090 (project gnutls):

                  Status:                    None => Need Info              
             Assigned to:                    None => nmav                   

    _______________________________________________________

Follow-up Comment #1:

I'm not sure if it is the right behavior to accept such keys. Is there a
reason you use them and do not use unencrypted keys or is it a bug that you
want to keep backwards compatibility with?

Do you see difference in the key generated from "" with 0 size, and NULL with
0 size?


    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Thu Jul 19 23:32:35 2012
From: INVALID.NOREPLY at gnu.org (Alexandre Chataignon)
Date: Thu, 19 Jul 2012 21:32:35 +0000
Subject: [sr #108090] Unable to decode PKCS12 with NULL password since 3.0.20
In-Reply-To: <20120719-231510.sv707.61446@savannah.gnu.org>
References: <20120718-165700.sv88698.84726@savannah.gnu.org>
	<20120719-231510.sv707.61446@savannah.gnu.org>
Message-ID: <20120719-213235.sv88698.80504@savannah.gnu.org>

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

Actually, I have generated a batch of pkcs12 certificates with a python
snippet similar to the one I have posted without asking me too much questions.
I mean, it uses openssl api in its simplest form, the generated pkcs12 works
fine with openssl itself, but also in OpenVPN for example. It's impossible for
me to regenerate all the certificates, so yes, I would like backwards
compatibility.

I don't know the right behavior, but the fact that it used to work in gnutls
and that it works in OpenSSL makes me think that's a regression.

> Do you see difference in the key generated from "" with 0 size, and NULL
with 0 size? 

Ahem, I don't understand the question, can you describe please ?

    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Fri Jul 20 00:09:33 2012
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Thu, 19 Jul 2012 22:09:33 +0000
Subject: [sr #108090] Unable to decode PKCS12 with NULL password since 3.0.20
In-Reply-To: <20120719-213235.sv88698.80504@savannah.gnu.org>
References: <20120718-165700.sv88698.84726@savannah.gnu.org>
	<20120719-231510.sv707.61446@savannah.gnu.org>
	<20120719-213235.sv88698.80504@savannah.gnu.org>
Message-ID: <20120720-010933.sv707.70079@savannah.gnu.org>

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

Did you try specifying a password containing the null string (not NULL), and a
password size of zero?

btw. How do you generate and/or decrypt those keys of yours from the openssl
command line applications?



    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Fri Jul 20 00:24:39 2012
From: INVALID.NOREPLY at gnu.org (Alexandre Chataignon)
Date: Thu, 19 Jul 2012 22:24:39 +0000
Subject: [sr #108090] Unable to decode PKCS12 with NULL password since 3.0.20
In-Reply-To: <20120720-010933.sv707.70079@savannah.gnu.org>
References: <20120718-165700.sv88698.84726@savannah.gnu.org>
	<20120719-231510.sv707.61446@savannah.gnu.org>
	<20120719-213235.sv88698.80504@savannah.gnu.org>
	<20120720-010933.sv707.70079@savannah.gnu.org>
Message-ID: <20120719-222439.sv88698.53332@savannah.gnu.org>

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

> Did you try specifying a password containing the null string (not NULL), and
a password size of zero? 

Yes, It doesn't work

> btw. How do you generate and/or decrypt those keys of yours from the openssl
command line applications? 

I'm not sure it's possible to generate those keys from the command line, but
it is definitely possible to decrypt them with the "" password

    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Fri Jul 20 09:26:25 2012
From: INVALID.NOREPLY at gnu.org (anonymous)
Date: Fri, 20 Jul 2012 07:26:25 +0000
Subject: [sr #108090] Unable to decode PKCS12 with NULL password since 3.0.20
In-Reply-To: <20120719-222439.sv88698.53332@savannah.gnu.org>
References: <20120718-165700.sv88698.84726@savannah.gnu.org>
	<20120719-231510.sv707.61446@savannah.gnu.org>
	<20120719-213235.sv88698.80504@savannah.gnu.org>
	<20120720-010933.sv707.70079@savannah.gnu.org>
	<20120719-222439.sv88698.53332@savannah.gnu.org>
Message-ID: <20120720-072625.sv0.3763@savannah.gnu.org>

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

Could you attach a PKCS #12 file encrypted with NULL in this bug report for
testing?

    _______________________________________________________

Reply to this item at:

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

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




From bgurup.ndk at gmail.com  Tue Jul 24 07:47:28 2012
From: bgurup.ndk at gmail.com (Guru Prasad)
Date: Tue, 24 Jul 2012 11:17:28 +0530
Subject: Fwd: Issue in SSL/TLS connection setup
In-Reply-To: <CADOz54hR6_9iuKEVR93bh0hOiX1PaFZ4bqsGGmK82-Kyi1TSxw@mail.gmail.com>
References: <CADOz54hR6_9iuKEVR93bh0hOiX1PaFZ4bqsGGmK82-Kyi1TSxw@mail.gmail.com>
Message-ID: <CADOz54iBAE4uzwkWKA0f+2pu-ULE1ywJp_1+y6dsSJsuL7GWjg@mail.gmail.com>

Please let me know whether this is an issue in python-gnutls version 1.1.9.

---------- Forwarded message ----------
From: Guru Prasad <bgurup.ndk at gmail.com>
Date: Thu, Jul 19, 2012 at 10:14 AM
Subject: Issue in SSL/TLS connection setup
To: bug-gnutls at gnu.org


I am facing SSL/TLS connection setup issue with python-twisted (12.0.0) and
python-gnutls(1.1.9). Version of Ubuntu (unstable), I am using is: 12.10
During the SSL/TLS connection setup, there is ClientHello request from the
client and for this request there is no response from the server where
Twisted and GnuTLS are running.
I see only TCP FIN and RST sent by the server end for the ClientHello
request.

When I checked the syslog, I see below messages.

 Traceback (most recent call last):
:   File "/usr/lib/python2.7/dist-
packages/twisted/python/log.py", line 84, in callWithLogger
:     return callWithContext({"system": lp}, func, *args, **kw)
:   File "/usr/lib/python2.7/dist-packages/twisted/python/log.py", line 69,
in callWithContext
:     return context.call({ILogContext: newCtx}, func, *args, **kw)
:   File "/usr/lib/python2.7/dist-packages/twisted/python/context.py", line
118, in callWithContext
:     return self.currentContext().callWithContext(ctx, func, *args, **kw)
:   File "/usr/lib/python2.7/dist-packages/twisted/python/context.py", line
81, in callWithContext
:     return func(*args,**kw)
:   File "/usr/lib/python2.7/dist-packages/twisted/internet/posixbase.py",
line 599, in _doReadOrWrite
:     self._disconnectSelectable(selectable, why, inRead)
:   File "/usr/lib/python2.7/dist-packages/twisted/internet/posixbase.py",
line 266, in _disconnectSelectable
:     selectable.connectionLost(failure.Failure(why))
:   File
"/usr/local/lib/python2.7/dist-packages/gnutls/interfaces/twisted/__init__.py",
line 328, in connectionLost
:     tcp.Server.connectionLost(self, reason)
:   File "/usr/lib/python2.7/dist-packages/twisted/internet/tcp.py", line
277, in connectionLost
:     protocol.connectionLost(reason)
:   File "/usr/lib/python2.7/dist-packages/twisted/web2/channel/http.py",
line 853, in connectionLost
:     self.readConnectionLost()
:   File "/usr/lib/python2.7/dist-packages/twisted/web2/channel/http.py",
line 842, in readConnectionLost
:     self.transport.loseConnection()
:   File
"/usr/local/lib/python2.7/dist-packages/gnutls/interfaces/twisted/__init__.py",
line 322, in loseConnection
:     tcp.Server.loseConnection(self, reason)
: TypeError: loseConnection() takes exactly 1 argument (2 given)

Anyone else has faced this issue, earlier? Is this a bug in GnuTLS package?
I am not having any clue like what went wrong. Have I missed anything which
is required?
Please help me to come out of this issue.

--bgurup
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20120724/638d1f11/attachment.htm>

From INVALID.NOREPLY at gnu.org  Wed Jul 25 21:41:09 2012
From: INVALID.NOREPLY at gnu.org (Steve Trotman)
Date: Wed, 25 Jul 2012 19:41:09 +0000
Subject: [sr #108094] unresolved symbols in windows because wincrypt.h is not
	included
Message-ID: <20120725-194109.sv88767.22707@savannah.gnu.org>

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

                 Summary: unresolved symbols in windows because wincrypt.h is
not included
                 Project: GnuTLS
            Submitted by: stevetrotman
            Submitted on: Wed 25 Jul 2012 07:41:08 PM GMT
                Category: None
                Priority: 5 - Normal
                Severity: 5 - Blocker
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
        Operating System: Microsoft Windows

    _______________________________________________________

Details:

crypto-api.c and gnutls_x509.c both use certificate functions that need
wincrypt.h under windows.  Adding #include <wincrypt.h> to these two files
allowed them to compile successfully.




    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Thu Jul 26 10:14:04 2012
From: INVALID.NOREPLY at gnu.org (Alexandre Chataignon)
Date: Thu, 26 Jul 2012 08:14:04 +0000
Subject: [sr #108090] Unable to decode PKCS12 with NULL password since 3.0.20
In-Reply-To: <20120720-072625.sv0.3763@savannah.gnu.org>
References: <20120718-165700.sv88698.84726@savannah.gnu.org>
	<20120719-231510.sv707.61446@savannah.gnu.org>
	<20120719-213235.sv88698.80504@savannah.gnu.org>
	<20120720-010933.sv707.70079@savannah.gnu.org>
	<20120719-222439.sv88698.53332@savannah.gnu.org>
	<20120720-072625.sv0.3763@savannah.gnu.org>
Message-ID: <20120726-081403.sv88698.37017@savannah.gnu.org>

Additional Item Attachment, sr #108090 (project gnutls):

File name: test.p12                       Size:1 KB


    _______________________________________________________

Reply to this item at:

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

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




From petr.pisar at atlas.cz  Thu Jul 26 16:18:44 2012
From: petr.pisar at atlas.cz (=?UTF-8?q?Petr=20P=C3=ADsa=C5=99?=)
Date: Thu, 26 Jul 2012 16:18:44 +0200
Subject: [PATCH] Respect certtool --hash when signing request and CRL
Message-ID: <1343312324-16993-1-git-send-email-petr.pisar@atlas.cz>

The certtool hard-codes the digest algorithm despite '--hash' option exists.
This patch allows user to choose the algorithm when signing certificate
request or certificate revocation list.
---
 src/certtool.c |   37 ++++++++++++++++++++++++-------------
 1 files changed, 24 insertions(+), 13 deletions(-)

diff --git a/src/certtool.c b/src/certtool.c
index 7078d24..dfe36a5 100644
--- a/src/certtool.c
+++ b/src/certtool.c
@@ -641,12 +641,32 @@ generate_crl (gnutls_x509_crt_t ca_crt, common_info_st * cinfo)
 }
 
 static gnutls_digest_algorithm_t
+get_dig_for_pub (gnutls_pubkey_t pubkey)
+{
+  gnutls_digest_algorithm_t dig;
+  int result;
+  unsigned int mand;
+
+  result = gnutls_pubkey_get_preferred_hash_algorithm (pubkey, &dig, &mand);
+  if (result < 0)
+    {
+      error (EXIT_FAILURE, 0, "crt_get_preferred_hash_algorithm: %s",
+             gnutls_strerror (result));
+    }
+
+  /* if algorithm allows alternatives */
+  if (mand == 0 && default_dig != GNUTLS_DIG_UNKNOWN)
+    dig = default_dig;
+
+  return dig;
+}
+
+static gnutls_digest_algorithm_t
 get_dig (gnutls_x509_crt_t crt)
 {
   gnutls_digest_algorithm_t dig;
   gnutls_pubkey_t pubkey;
   int result;
-  unsigned int mand;
 
   gnutls_pubkey_init(&pubkey);
 
@@ -657,19 +677,10 @@ get_dig (gnutls_x509_crt_t crt)
              gnutls_strerror (result));
     }
 
-  result = gnutls_pubkey_get_preferred_hash_algorithm (pubkey, &dig, &mand);
-  if (result < 0)
-    {
-      error (EXIT_FAILURE, 0, "crt_get_preferred_hash_algorithm: %s",
-             gnutls_strerror (result));
-    }
+  dig = get_dig_for_pub (pubkey);
 
   gnutls_pubkey_deinit(pubkey);
 
-  /* if algorithm allows alternatives */
-  if (mand == 0 && default_dig != GNUTLS_DIG_UNKNOWN)
-    dig = default_dig;
-
   return dig;
 }
 
@@ -813,7 +824,7 @@ generate_signed_crl (common_info_st * cinfo)
   crl = generate_crl (ca_crt, cinfo);
 
   fprintf (stderr, "\n");
-  result = gnutls_x509_crl_privkey_sign(crl, ca_crt, ca_key, SIGN_HASH, 0);
+  result = gnutls_x509_crl_privkey_sign(crl, ca_crt, ca_key, get_dig (ca_crt), 0);
   if (result < 0)
     error (EXIT_FAILURE, 0, "crl_privkey_sign: %s", gnutls_strerror (result));
 
@@ -1873,7 +1884,7 @@ generate_request (common_info_st * cinfo)
   if (ret < 0)
     error (EXIT_FAILURE, 0, "set_key: %s", gnutls_strerror (ret));
 
-  ret = gnutls_x509_crq_privkey_sign (crq, pkey, SIGN_HASH, 0);
+  ret = gnutls_x509_crq_privkey_sign (crq, pkey, get_dig_for_pub (pubkey), 0);
   if (ret < 0)
     error (EXIT_FAILURE, 0, "sign: %s", gnutls_strerror (ret));
 
-- 
1.7.8.6




From olyasib12 at gmail.com  Thu Jul 26 23:00:43 2012
From: olyasib12 at gmail.com (Olya)
Date: Fri, 27 Jul 2012 04:00:43 +0700
Subject: buffer\datum questions
Message-ID: <5011AFFB.7040803@gmail.com>

Hello.

I've been struggling with data buffering - seems like what I've guessed from source
code is not entirely true: buffer content is not what I've put in there, segfaults etc.

Could you help me to figure out how to use gnutls_str properly?
Code snippets would be most awesome. (Yepp, I'm aware that it's used throughout
GnuTLS - but thousands of lines of undocumented code is hardly a good illustration :)
I'll try to add some documentation to gnutls_str.c once I figure out how stuff in
there actually works.

1) I've got gnutls_buffer_st with some content and void * data of size len - how do I
replace the buffer content? Who\when does memory allocation\free?

2) I'd like to get hex representation of buffer content to char * (for printing) -
how do I do that?

3) What's the difference between datum and buffer - when I should use one?

4) What's with memory management? Is it completely automated? When and why do I need
_gnutls_buffer_resize()?

5) What does various _prefix() functions do?

This is so trivially obvious that it wasn't even documented - but it's really hard
for newcomers to figure out. That's why I'd like to produce at least something to
doxygen gnutls_str.c

-- 
best regards,
Olga.



From todd at fries.net  Mon Jul 30 19:18:51 2012
From: todd at fries.net (Todd T. Fries)
Date: Mon, 30 Jul 2012 12:18:51 -0500
Subject: 'gnutls-cli -d 9999 --insecure -p 443 post.craigslist.org' fails
	with 3.0.20
Message-ID: <20120730171851.GA30437@fries.net>

|<2>| p11: loaded provider 'gnome-keyring-module' with 0 slots
|<2>| ASSERT: pkcs11.c:459
Processed 152 CA certificate(s).
Resolving 'post.craigslist.org'...
Connecting to '208.82.238.151:443'...
|<4>| REC[0x73118]: Allocating epoch #0
|<1>| Note that the security level of the Diffie-Hellman key exchange has been lowered to 512 bits and this may allow decryption of the session data
|<2>| ASSERT: gnutls_constate.c:717
|<4>| REC[0x73118]: Allocating epoch #1
|<3>| HSK[0x73118]: Keeping ciphersuite: ECDHE_ECDSA_AES_128_CBC_SHA1 (C0.09)
|<3>| HSK[0x73118]: Keeping ciphersuite: ECDHE_ECDSA_AES_128_CBC_SHA256 (C0.23)
|<3>| HSK[0x73118]: Keeping ciphersuite: ECDHE_ECDSA_AES_128_GCM_SHA256 (C0.2B)
|<3>| HSK[0x73118]: Keeping ciphersuite: ECDHE_ECDSA_AES_256_CBC_SHA1 (C0.0A)
|<3>| HSK[0x73118]: Keeping ciphersuite: ECDHE_ECDSA_AES_256_CBC_SHA384 (C0.24)
|<3>| HSK[0x73118]: Keeping ciphersuite: ECDHE_ECDSA_AES_256_GCM_SHA384 (C0.2C)
|<3>| HSK[0x73118]: Keeping ciphersuite: ECDHE_ECDSA_3DES_EDE_CBC_SHA1 (C0.08)
|<3>| HSK[0x73118]: Keeping ciphersuite: ECDHE_RSA_AES_128_CBC_SHA1 (C0.13)
|<3>| HSK[0x73118]: Keeping ciphersuite: ECDHE_RSA_AES_128_CBC_SHA256 (C0.27)
|<3>| HSK[0x73118]: Keeping ciphersuite: ECDHE_RSA_AES_128_GCM_SHA256 (C0.2F)
|<3>| HSK[0x73118]: Keeping ciphersuite: ECDHE_RSA_AES_256_CBC_SHA1 (C0.14)
|<3>| HSK[0x73118]: Keeping ciphersuite: ECDHE_RSA_AES_256_GCM_SHA384 (C0.30)
|<3>| HSK[0x73118]: Keeping ciphersuite: ECDHE_RSA_3DES_EDE_CBC_SHA1 (C0.12)
|<3>| HSK[0x73118]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1 (00.33)
|<3>| HSK[0x73118]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA256 (00.67)
|<3>| HSK[0x73118]: Keeping ciphersuite: DHE_RSA_CAMELLIA_128_CBC_SHA1 (00.45)
|<3>| HSK[0x73118]: Keeping ciphersuite: DHE_RSA_AES_128_GCM_SHA256 (00.9E)
|<3>| HSK[0x73118]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1 (00.39)
|<3>| HSK[0x73118]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA256 (00.6B)
|<3>| HSK[0x73118]: Keeping ciphersuite: DHE_RSA_CAMELLIA_256_CBC_SHA1 (00.88)
|<3>| HSK[0x73118]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1 (00.16)
|<3>| HSK[0x73118]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA1 (00.32)
|<3>| HSK[0x73118]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA256 (00.40)
|<3>| HSK[0x73118]: Keeping ciphersuite: DHE_DSS_CAMELLIA_128_CBC_SHA1 (00.44)
|<3>| HSK[0x73118]: Keeping ciphersuite: DHE_DSS_AES_128_GCM_SHA256 (00.A2)
|<3>| HSK[0x73118]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA1 (00.38)
|<3>| HSK[0x73118]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA256 (00.6A)
|<3>| HSK[0x73118]: Keeping ciphersuite: DHE_DSS_CAMELLIA_256_CBC_SHA1 (00.87)
|<3>| HSK[0x73118]: Keeping ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1 (00.13)
|<3>| HSK[0x73118]: Keeping ciphersuite: DHE_DSS_ARCFOUR_SHA1 (00.66)
|<3>| HSK[0x73118]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1 (00.2F)
|<3>| HSK[0x73118]: Keeping ciphersuite: RSA_AES_128_CBC_SHA256 (00.3C)
|<3>| HSK[0x73118]: Keeping ciphersuite: RSA_CAMELLIA_128_CBC_SHA1 (00.41)
|<3>| HSK[0x73118]: Keeping ciphersuite: RSA_AES_128_GCM_SHA256 (00.9C)
|<3>| HSK[0x73118]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1 (00.35)
|<3>| HSK[0x73118]: Keeping ciphersuite: RSA_AES_256_CBC_SHA256 (00.3D)
|<3>| HSK[0x73118]: Keeping ciphersuite: RSA_CAMELLIA_256_CBC_SHA1 (00.84)
|<3>| HSK[0x73118]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1 (00.0A)
|<3>| HSK[0x73118]: Keeping ciphersuite: RSA_ARCFOUR_SHA1 (00.05)
|<3>| HSK[0x73118]: Keeping ciphersuite: RSA_ARCFOUR_MD5 (00.04)
|<3>| EXT[0x73118]: Sending extension SERVER NAME (24 bytes)
|<3>| EXT[0x73118]: Sending extension SAFE RENEGOTIATION (1 bytes)
|<3>| EXT[0x73118]: Sending extension SUPPORTED ECC (12 bytes)
|<3>| EXT[0x73118]: Sending extension SUPPORTED ECC POINT FORMATS (2 bytes)
|<3>| EXT[0x73118]: sent signature algo (4.1) RSA-SHA256
|<3>| EXT[0x73118]: sent signature algo (4.2) DSA-SHA256
|<3>| EXT[0x73118]: sent signature algo (4.3) ECDSA-SHA256
|<3>| EXT[0x73118]: sent signature algo (5.1) RSA-SHA384
|<3>| EXT[0x73118]: sent signature algo (5.3) ECDSA-SHA384
|<3>| EXT[0x73118]: sent signature algo (6.1) RSA-SHA512
|<3>| EXT[0x73118]: sent signature algo (6.3) ECDSA-SHA512
|<3>| EXT[0x73118]: sent signature algo (3.1) RSA-SHA224
|<3>| EXT[0x73118]: sent signature algo (3.2) DSA-SHA224
|<3>| EXT[0x73118]: sent signature algo (3.3) ECDSA-SHA224
|<3>| EXT[0x73118]: sent signature algo (2.1) RSA-SHA1
|<3>| EXT[0x73118]: sent signature algo (2.2) DSA-SHA1
|<3>| EXT[0x73118]: sent signature algo (2.3) ECDSA-SHA1
|<3>| EXT[0x73118]: Sending extension SIGNATURE ALGORITHMS (28 bytes)
|<3>| HSK[0x73118]: CLIENT HELLO was queued [212 bytes]
|<7>| HWRITE: enqueued [CLIENT HELLO] 212. Total 212 bytes.
|<7>| HWRITE FLUSH: 212 bytes in buffer.
|<4>| REC[0x73118]: Preparing Packet Handshake(22) with length: 212
|<9>| ENC[0x73118]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
|<7>| WRITE: enqueued 217 bytes for 0x4. Total 217 bytes.
|<4>| REC[0x73118]: Sent Packet[1] Handshake(22) in epoch 0 and length: 217
|<7>| HWRITE: wrote 1 bytes, 0 bytes left.
|<7>| WRITE FLUSH: 217 bytes in buffer.
|<7>| WRITE: wrote 217 bytes, 0 bytes left.
|<2>| ASSERT: gnutls_buffers.c:974
|<7>| READ: Got 0 bytes from 0x4
|<7>| READ: read 0 bytes from 0x4
|<2>| ASSERT: gnutls_buffers.c:482
|<2>| ASSERT: gnutls_record.c:876
|<2>| ASSERT: gnutls_record.c:986
|<2>| ASSERT: gnutls_buffers.c:1175
|<2>| ASSERT: gnutls_handshake.c:1269
|<2>| ASSERT: gnutls_handshake.c:2484
*** Fatal error: The TLS connection was non-properly terminated.
|<2>| ASSERT: gnutls_ui.c:544
No certificates found!
|<4>| REC: Sending Alert[2|10] - Unexpected message
|<4>| REC[0x73118]: Preparing Packet Alert(21) with length: 2
|<9>| ENC[0x73118]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
|<7>| WRITE: enqueued 7 bytes for 0x4. Total 7 bytes.
|<7>| WRITE FLUSH: 7 bytes in buffer.
|<7>| WRITE: wrote 7 bytes, 0 bytes left.
|<4>| REC[0x73118]: Sent Packet[2] Alert(21) in epoch 0 and length: 7
*** Handshake has failed
GnuTLS error: The TLS connection was non-properly terminated.
|<4>| REC[0x73118]: Start of epoch cleanup
|<4>| REC[0x73118]: End of epoch cleanup
|<4>| REC[0x73118]: Epoch #0 freed
|<4>| REC[0x73118]: Epoch #1 freed

I can confirm this same behavior on Linux/Debian/arm and OpenBSD/i386.

Thanks,
-- 
Todd Fries .. todd at fries.net

 _____________________________________________
|                                             \  1.636.410.0632 (voice)
| Free Daemon Consulting, LLC                 \  1.405.227.9094 (voice)
| http://FreeDaemonConsulting.com             \  1.866.792.3418 (FAX)
| 2525 NW Expy #525, Oklahoma City, OK 73112  \  sip:freedaemon at ekiga.net
| "..in support of free software solutions."  \  sip:4052279094 at ekiga.net
 \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
                                                 
              37E7 D3EB 74D0 8D66 A68D  B866 0326 204E 3F42 004A
                        http://todd.fries.net/pgp.txt




From dkg at fifthhorseman.net  Tue Jul 31 17:50:00 2012
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 31 Jul 2012 11:50:00 -0400
Subject: segfault in gnutls-cli -d 65535 post.craigslist.org
Message-ID: <878ve0x74n.fsf@pip.fifthhorseman.net>

In attempting to replicate Todd T. Fries' report, i found a segmentation
fault in gnutls-cli when asking for out-of-range debugging (> 9999):

here's a backtrace from debian-packaged 3.0.20-3:


(gdb) run -d 65535 post.craigslist.org
Starting program: /usr/bin/gnutls-cli -d 65535 post.craigslist.org
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/i686/cmov/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0xb7d5cbb0 in _IO_vfprintf_internal (s=0xbfffde20, format=0xb7e98bb1 "%s error:  %s option value ``%s'' is out of range.\n", 
    ap=0xbfffe4c8 "\260\371\377\277\350t\005\b\377\377") at vfprintf.c:1623
1623	vfprintf.c: No such file or directory.
(gdb) bt
#0  0xb7d5cbb0 in _IO_vfprintf_internal (s=0xbfffde20, format=0xb7e98bb1 "%s error:  %s option value ``%s'' is out of range.\n", 
    ap=0xbfffe4c8 "\260\371\377\277\350t\005\b\377\377") at vfprintf.c:1623
#1  0xb7d5d092 in buffered_vfprintf (s=0xb7e74580, format=0xffff <Address 0xffff out of bounds>, args=0xffffffff <Address 0xffffffff out of bounds>)
    at vfprintf.c:2289
#2  0xb7d58273 in _IO_vfprintf_internal (s=0xb7e74580, format=0xb7e98bb1 "%s error:  %s option value ``%s'' is out of range.\n", 
    ap=0xbfffe4c8 "\260\371\377\277\350t\005\b\377\377") at vfprintf.c:1309
#3  0xb7d6232f in __fprintf (stream=0xb7e74580, format=0xb7e98bb1 "%s error:  %s option value ``%s'' is out of range.\n") at fprintf.c:33
#4  0xb7e8acb6 in optionShowRange () from /usr/lib/libopts.so.25
#5  0x08053f68 in doOptDebug (pOptions=0x805c140, pOptDesc=0x805c1e0) at cli-args.c:1046
#6  0xb7e84c81 in ?? () from /usr/lib/libopts.so.25
#7  0xb7e8d243 in ?? () from /usr/lib/libopts.so.25
#8  0xb7e8eef3 in optionProcess () from /usr/lib/libopts.so.25
#9  0x0804cd1a in cmd_parser (argv=0xbffff824, argc=4) at cli.c:1107
#10 main (argc=4, argv=0xbffff824) at cli.c:848


and here it is from 3.0.21-1:

(gdb) run -d 65535 post.craigslist.org
Starting program: /usr/bin/gnutls-cli -d 65535 post.craigslist.org
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/i686/cmov/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0xb7d5cbb0 in _IO_vfprintf_internal (s=0xbfffde20, format=0xb7e98bb1 "%s error:  %s option value ``%s'' is out of range.\n", 
    ap=0xbfffe4c8 "\260\371\377\277\bu\005\b\377\377") at vfprintf.c:1623
1623	vfprintf.c: No such file or directory.
(gdb) bt
#0  0xb7d5cbb0 in _IO_vfprintf_internal (s=0xbfffde20, format=0xb7e98bb1 "%s error:  %s option value ``%s'' is out of range.\n", 
    ap=0xbfffe4c8 "\260\371\377\277\bu\005\b\377\377") at vfprintf.c:1623
#1  0xb7d5d092 in buffered_vfprintf (s=0xb7e74580, format=0xffff <Address 0xffff out of bounds>, args=0xffffffff <Address 0xffffffff out of bounds>)
    at vfprintf.c:2289
#2  0xb7d58273 in _IO_vfprintf_internal (s=0xb7e74580, format=0xb7e98bb1 "%s error:  %s option value ``%s'' is out of range.\n", 
    ap=0xbfffe4c8 "\260\371\377\277\bu\005\b\377\377") at vfprintf.c:1309
#3  0xb7d6232f in __fprintf (stream=0xb7e74580, format=0xb7e98bb1 "%s error:  %s option value ``%s'' is out of range.\n") at fprintf.c:33
#4  0xb7e8acb6 in optionShowRange () from /usr/lib/libopts.so.25
#5  0x08053f88 in doOptDebug (pOptions=0x805c140, pOptDesc=0x805c1e0) at cli-args.c:1046
#6  0xb7e84c81 in ?? () from /usr/lib/libopts.so.25
#7  0xb7e8d243 in ?? () from /usr/lib/libopts.so.25
#8  0xb7e8eef3 in optionProcess () from /usr/lib/libopts.so.25
#9  0x0804cd1a in cmd_parser (argv=0xbffff824, argc=4) at cli.c:1107
#10 main (argc=4, argv=0xbffff824) at cli.c:848
(gdb) 


Something about the way optionShowRange is being invoked, or the data
being passed to it seems wrong, but i'm not sure what it is.

      --dkg