From nmav at gnutls.org  Tue Apr  1 11:21:17 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 1 Apr 2014 11:21:17 +0200
Subject: [gnutls-devel] 3.3.0pre0 - [sparc] Bus error on chainverify test
In-Reply-To: <20140330173753.GB3217@downhill.g.la>
References: <20140330173753.GB3217@downhill.g.la>
Message-ID: <CAJU7za+FnVLoPgGwKmUEsoohVsv1oy+jmtSC+MpKHBgWN=qi+w@mail.gmail.com>

On Sun, Mar 30, 2014 at 7:37 PM, Andreas Metzler <ametzler at bebt.de> wrote:
> Hello,
> Program received signal SIGBUS, Bus error.
> asn1_delete_structure2 (structure=0x1bf10, flags=0) at structure.c:315
> 315           if (p->down)
> (gdb) bt
> #0  asn1_delete_structure2 (structure=0x1bf10, flags=0) at structure.c:315
> #1  0xf7f3f18c in gnutls_x509_crt_import (cert=0x1bf10, data=0xffffd668,
>     format=GNUTLS_X509_FMT_PEM) at x509.c:207
> #2  0x00010f40 in doit () at chainverify.c:1279
> #3  0x00010b30 in main (argc=0, argv=0xffffd7c4) at utils.c:146
> (gdb)
> -------------
> I have built against included minitasn for improved debugging output.

Andreas, could there be an issue with calloc or the compiler on this
system? If you
follow the code in gnutls_x509_crt_import() it only enters the
location that receives
sigbus  when 'cert->expanded' is non zero. As this is the first call
after gnutls_x509_crt_init()
it means that this value should have been zero.

A way to see if it is a compiler issue, is to change the compiler, or
try compiling with -O0 (and
hoping the issue is in the optimizer). You can see if it is an issue
in calloc() on that system
by placing a memset() to zero just after it and seeing whether it
fixes the issue.

regards,
Nikos


From jaak.ristioja at cyber.ee  Tue Apr  1 11:40:33 2014
From: jaak.ristioja at cyber.ee (Jaak Ristioja)
Date: Tue, 01 Apr 2014 12:40:33 +0300
Subject: [gnutls-devel] Other versions of GnuTLS manual
Message-ID: <533A8991.9010603@cyber.ee>

Hi!

Does anybody know where I could find manuals for previous versions of
GnuTLS? I'm having trouble locating them on the website.

Best regards,
Jaak Ristioja


From nmav at gnutls.org  Tue Apr  1 18:39:13 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 1 Apr 2014 18:39:13 +0200
Subject: [gnutls-devel] Other versions of GnuTLS manual
In-Reply-To: <533A8991.9010603@cyber.ee>
References: <533A8991.9010603@cyber.ee>
Message-ID: <CAJU7za+fWQe0fbVXkK9HsrgYzCcJj1vxHTsKLdbe2amFN6yztA@mail.gmail.com>

On Tue, Apr 1, 2014 at 11:40 AM, Jaak Ristioja <jaak.ristioja at cyber.ee> wrote:
> Hi!
> Does anybody know where I could find manuals for previous versions of
> GnuTLS? I'm having trouble locating them on the website.

Hello,
 The manuals are included in the corresponding releases.

regards,
Nikos


From dcypherd at gmail.com  Wed Apr  2 04:23:38 2014
From: dcypherd at gmail.com (Jim Shaver)
Date: Tue, 1 Apr 2014 20:23:38 -0600
Subject: [gnutls-devel] Broken Links
Message-ID: <CAOcgUzZcR+SR2Q4=feE=w5EY5xCcRrhv_bzLXpKpdUfK4+Yr0A@mail.gmail.com>

I'm having a good time digging into the gnutls project.  Just noticed a
couple of broken links.

The front page links to "DANE" which goes nowhere.

The http://gnutls.org/help.html page links to a TODO which appears to not
exist on Gitorius anylonger.

Thanks!
Jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20140401/d7626f5e/attachment.html>

From nmav at gnutls.org  Wed Apr  2 19:18:26 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 02 Apr 2014 19:18:26 +0200
Subject: [gnutls-devel] Broken Links
In-Reply-To: <CAOcgUzZcR+SR2Q4=feE=w5EY5xCcRrhv_bzLXpKpdUfK4+Yr0A@mail.gmail.com>
References: <CAOcgUzZcR+SR2Q4=feE=w5EY5xCcRrhv_bzLXpKpdUfK4+Yr0A@mail.gmail.com>
Message-ID: <1396459106.3865.0.camel@nomad.lan>

On Tue, 2014-04-01 at 20:23 -0600, Jim Shaver wrote:
> I'm having a good time digging into the gnutls project.  Just noticed
> a couple of broken links

> The front page links to "DANE" which goes nowhere.
> The http://gnutls.org/help.html page links to a TODO which appears to
> not exist on Gitorius anylonger.

Thank you for reporting them. They will be fixed as soon!

regards,
Nikos





From ametzler at bebt.de  Wed Apr  2 19:32:53 2014
From: ametzler at bebt.de (Andreas Metzler)
Date: Wed, 2 Apr 2014 19:32:53 +0200
Subject: [gnutls-devel] 3.3.0pre0 - [sparc] Bus error on chainverify test
In-Reply-To: <CAJU7za+FnVLoPgGwKmUEsoohVsv1oy+jmtSC+MpKHBgWN=qi+w@mail.gmail.com>
References: <20140330173753.GB3217@downhill.g.la>
 <CAJU7za+FnVLoPgGwKmUEsoohVsv1oy+jmtSC+MpKHBgWN=qi+w@mail.gmail.com>
Message-ID: <20140402173253.GA3222@downhill.g.la>

On 2014-04-01 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> On Sun, Mar 30, 2014 at 7:37 PM, Andreas Metzler <ametzler at bebt.de> wrote:
> > Program received signal SIGBUS, Bus error.
> > asn1_delete_structure2 (structure=0x1bf10, flags=0) at structure.c:315
> > 315           if (p->down)
> > (gdb) bt
> > #0  asn1_delete_structure2 (structure=0x1bf10, flags=0) at structure.c:315
> > #1  0xf7f3f18c in gnutls_x509_crt_import (cert=0x1bf10, data=0xffffd668,
> >     format=GNUTLS_X509_FMT_PEM) at x509.c:207
> > #2  0x00010f40 in doit () at chainverify.c:1279
> > #3  0x00010b30 in main (argc=0, argv=0xffffd7c4) at utils.c:146
[...]
> Andreas, could there be an issue with calloc or the compiler on this
> system? If you follow the code in gnutls_x509_crt_import() it only
> enters the location that receives sigbus  when 'cert->expanded' is
> non zero. As this is the first call after gnutls_x509_crt_init() it
> means that this value should have been zero.

> A way to see if it is a compiler issue, is to change the compiler,
> or try compiling with -O0 (and hoping the issue is in the
> optimizer). You can see if it is an issue in calloc() on that system
> by placing a memset() to zero just after it and seeing whether it
> fixes the issue.

Hello,

what I have tried these things without success:
-O0 -> no change

-------------------
--- /home/ametzler/GIT/gnutls/lib/x509/x509.c   2014-04-01 19:47:18.934610756 +0200
+++ lib/x509/x509.c     2014-04-02 19:26:31.562655272 +0200
@@ -51,6 +51,7 @@ int gnutls_x509_crt_init(gnutls_x509_crt

        tmp =
            gnutls_calloc(1, sizeof(gnutls_x509_crt_int));
+       memset(tmp, '\0', sizeof(gnutls_x509_crt_int));
        int result;

        if (!tmp)
-------------------

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


From nmav at gnutls.org  Wed Apr  2 20:58:43 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 02 Apr 2014 20:58:43 +0200
Subject: [gnutls-devel] 3.3.0pre0 - [sparc] Bus error on chainverify test
In-Reply-To: <20140402173253.GA3222@downhill.g.la>
References: <20140330173753.GB3217@downhill.g.la>
 <CAJU7za+FnVLoPgGwKmUEsoohVsv1oy+jmtSC+MpKHBgWN=qi+w@mail.gmail.com>
 <20140402173253.GA3222@downhill.g.la>
Message-ID: <1396465123.4614.2.camel@nomad.lan>

On Wed, 2014-04-02 at 19:32 +0200, Andreas Metzler wrote:

> what I have tried these things without success:
> -O0 -> no change
> 
> -------------------
> --- /home/ametzler/GIT/gnutls/lib/x509/x509.c   2014-04-01 19:47:18.934610756 +0200
> +++ lib/x509/x509.c     2014-04-02 19:26:31.562655272 +0200
> @@ -51,6 +51,7 @@ int gnutls_x509_crt_init(gnutls_x509_crt
> 
>         tmp =
>             gnutls_calloc(1, sizeof(gnutls_x509_crt_int));
> +       memset(tmp, '\0', sizeof(gnutls_x509_crt_int));
>         int result;

Thanks, could you add a fprintf(stderr,"%d", cert->expanded); just
before the return of crt_init() and before the "if (cert->expanded)" in
gnutls_x509_crt_import()?





From ametzler at bebt.de  Thu Apr  3 20:12:13 2014
From: ametzler at bebt.de (Andreas Metzler)
Date: Thu, 3 Apr 2014 20:12:13 +0200
Subject: [gnutls-devel] 3.3.0pre0 - [sparc] Bus error on chainverify test
In-Reply-To: <1396465123.4614.2.camel@nomad.lan>
References: <20140330173753.GB3217@downhill.g.la>
 <CAJU7za+FnVLoPgGwKmUEsoohVsv1oy+jmtSC+MpKHBgWN=qi+w@mail.gmail.com>
 <20140402173253.GA3222@downhill.g.la>
 <1396465123.4614.2.camel@nomad.lan>
Message-ID: <20140403181213.GC3273@downhill.g.la>

On 2014-04-02 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> On Wed, 2014-04-02 at 19:32 +0200, Andreas Metzler wrote:

>> what I have tried these things without success:
[...]
> Thanks, could you add a fprintf(stderr,"%d", cert->expanded); just
> before the return of crt_init() and before the "if (cert->expanded)" in
> gnutls_x509_crt_import()?

Like this?

-------------------------------
--- /home/ametzler/GIT/gnutls/lib/x509/x509.c   2014-04-01 19:47:18.934610756 +0200
@@ -200,6 +201,7 @@ gnutls_x509_crt_import(gnutls_x509_crt_t
                need_free = 1;
        }

+       fprintf(stderr,"[at %s line %d]; %d", __FILE__, __LINE__, cert->expanded);
        if (cert->expanded) {
                /* Any earlier asn1_der_decoding will modify the ASN.1
                   structure, so we need to replace it with a fresh
-------------------------------

It results in this:
----------
sid_sparc-dchroot)ametzler at smetana:~/GNUTLS/gnutls28-3.3.0~pre0/tests$ ./chainverify
[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 0[at x509.c line 204]; 1229856835Bus error
----------

hth, cu Andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: chainverify--verbose.out.gz
Type: application/octet-stream
Size: 3592 bytes
Desc: not available
URL: </pipermail/attachments/20140403/326e01ad/attachment-0001.obj>

From nmav at gnutls.org  Fri Apr  4 10:04:46 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 4 Apr 2014 10:04:46 +0200
Subject: [gnutls-devel] 3.3.0pre0 - [sparc] Bus error on chainverify test
In-Reply-To: <20140403181213.GC3273@downhill.g.la>
References: <20140330173753.GB3217@downhill.g.la>
 <CAJU7za+FnVLoPgGwKmUEsoohVsv1oy+jmtSC+MpKHBgWN=qi+w@mail.gmail.com>
 <20140402173253.GA3222@downhill.g.la>
 <1396465123.4614.2.camel@nomad.lan>
 <20140403181213.GC3273@downhill.g.la>
Message-ID: <CAJU7zaLpf7iX7ivifiB-NJb6aBCpPkh34SJ3yVUpv+7NFJDhPA@mail.gmail.com>

On Thu, Apr 3, 2014 at 8:12 PM, Andreas Metzler <ametzler at bebt.de> wrote:
> It results in this:
> ----------
[at x509.c line 204]; 0[at x509.c line 204]; 1229856835Bus error

So it seems that there is a memory corruption between
gnutls_x509_crt_init() and gnutls_x509_crt_import() in chainverify.c,
but cannot be justified by the code and the fact that there is no
issue in other systems. That's why I suspect some miscompilation
there. Could I have access to that system in order to run that program
under a debugger?

regards,
Nikos


From ametzler at bebt.de  Fri Apr  4 19:25:39 2014
From: ametzler at bebt.de (Andreas Metzler)
Date: Fri, 4 Apr 2014 19:25:39 +0200
Subject: [gnutls-devel] 3.3.0pre0 - [sparc] Bus error on chainverify test
In-Reply-To: <CAJU7zaLpf7iX7ivifiB-NJb6aBCpPkh34SJ3yVUpv+7NFJDhPA@mail.gmail.com>
References: <20140330173753.GB3217@downhill.g.la>
 <CAJU7za+FnVLoPgGwKmUEsoohVsv1oy+jmtSC+MpKHBgWN=qi+w@mail.gmail.com>
 <20140402173253.GA3222@downhill.g.la>
 <1396465123.4614.2.camel@nomad.lan>
 <20140403181213.GC3273@downhill.g.la>
 <CAJU7zaLpf7iX7ivifiB-NJb6aBCpPkh34SJ3yVUpv+7NFJDhPA@mail.gmail.com>
Message-ID: <20140404172539.GA3234@downhill.g.la>

On 2014-04-04 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> On Thu, Apr 3, 2014 at 8:12 PM, Andreas Metzler <ametzler at bebt.de> wrote:
>> It results in this:
>> ----------
> [at x509.c line 204]; 0[at x509.c line 204]; 1229856835Bus error

> So it seems that there is a memory corruption between
> gnutls_x509_crt_init() and gnutls_x509_crt_import() in chainverify.c,
> but cannot be justified by the code and the fact that there is no
> issue in other systems. That's why I suspect some miscompilation
> there. Could I have access to that system in order to run that program
> under a debugger?

Hello Nikos,

it is a Debian machine, but as there is a process for getting an 
account [1]. I will happily act as sponsor if you are willing to
go for it.

cu Andreas

[1] https://dsa.debian.org/doc/guest-account/

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: </pipermail/attachments/20140404/df5c2756/attachment.sig>

From nmav at gnutls.org  Sat Apr  5 00:50:50 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 05 Apr 2014 00:50:50 +0200
Subject: [gnutls-devel] 3.3.0pre0 - [sparc] Bus error on chainverify test
In-Reply-To: <20140404172539.GA3234@downhill.g.la>
References: <20140330173753.GB3217@downhill.g.la>
 <CAJU7za+FnVLoPgGwKmUEsoohVsv1oy+jmtSC+MpKHBgWN=qi+w@mail.gmail.com>
 <20140402173253.GA3222@downhill.g.la> <1396465123.4614.2.camel@nomad.lan>
 <20140403181213.GC3273@downhill.g.la>
 <CAJU7zaLpf7iX7ivifiB-NJb6aBCpPkh34SJ3yVUpv+7NFJDhPA@mail.gmail.com>
 <20140404172539.GA3234@downhill.g.la>
Message-ID: <1396651850.28668.3.camel@nomad.lan>

On Fri, 2014-04-04 at 19:25 +0200, Andreas Metzler wrote:

> Hello Nikos,
> 
> it is a Debian machine, but as there is a process for getting an 
> account [1]. I will happily act as sponsor if you are willing to
> go for it.

I tried the 4.0 sparc qemu image and there was no issue in chainverify,
so it seems I cannot avoid testing on the real thing.

btw. what I am supposed to send for "Signed agreement to abide by DMUP"?

regards,
Nikos




From ametzler at bebt.de  Sat Apr  5 08:15:31 2014
From: ametzler at bebt.de (Andreas Metzler)
Date: Sat, 5 Apr 2014 08:15:31 +0200
Subject: [gnutls-devel] 3.3.0pre0 - [sparc] Bus error on chainverify test
In-Reply-To: <1396651850.28668.3.camel@nomad.lan>
References: <20140330173753.GB3217@downhill.g.la>
 <CAJU7za+FnVLoPgGwKmUEsoohVsv1oy+jmtSC+MpKHBgWN=qi+w@mail.gmail.com>
 <20140402173253.GA3222@downhill.g.la>
 <1396465123.4614.2.camel@nomad.lan>
 <20140403181213.GC3273@downhill.g.la>
 <CAJU7zaLpf7iX7ivifiB-NJb6aBCpPkh34SJ3yVUpv+7NFJDhPA@mail.gmail.com>
 <20140404172539.GA3234@downhill.g.la>
 <1396651850.28668.3.camel@nomad.lan>
Message-ID: <20140405061531.GA3220@downhill.g.la>

On 2014-04-05 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
[...]
> btw. what I am supposed to send for "Signed agreement to abide by DMUP"?

Good morning,

a pgp signed text file (or mail). I guess this should do the trick:

8X---------
I, Nikos Mavrogiannopoulos, have read and agree to abide by the Debian
Machine Usage Policies ("DMUP") <https://www.debian.org/devel/dmup>.
2014-04-05
8X---------

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


From nmav at gnutls.org  Mon Apr  7 21:58:33 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 07 Apr 2014 21:58:33 +0200
Subject: [gnutls-devel] gnutls 3.2.13
Message-ID: <1396900713.21845.2.camel@nomad.lan>

Hello,
 I've just released gnutls 3.2.13. This is a bugfix release on the
current stable branch.

* Version 3.2.13 (released 2014-04-07)

** libgnutls: gnutls_openpgp_keyring_import will no longer fail silently
if there are no base64 data. Report and patch by Ramkumar Chinchani.

** libgnutls: gnutls_record_send is now safe to be called under DTLS when
in corked mode.

** libgnutls: Ciphersuites that use the SHA256 or SHA384 MACs are
only available in TLS 1.0 as SSL 3.0 doesn't specify parameters for
these algorithms.

** libgnutls: Changed the behaviour in wildcard acceptance in certificates.
Wildcards are only accepted when there are more than two domain components
after the wildcard. This drops support for the permissive RFC2818 wildcards
and adds more conservative support based on the suggestions in RFC6125. Suggested 
by Jeffrey Walton.

** certtool: When no password is provided to export a PKCS #8 keys, do
not encrypt by default. This reverts to the certtool behavior of gnutls
3.0. The previous behavior of encrypting using an empty password can be
replicating using the new parameter --empty-password.

** p11tool: Avoid dual initialization of the PKCS #11 subsystem when
the --provider option is given.

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


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

GnuTLS may be downloaded directly from
<ftp://ftp.gnutls.org/gcrypt/gnutls/>.  A list of GnuTLS mirrors can be
found at <http://www.gnutls.org/download.html>.

Here are the XZ and LZIP compressed sources:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.13.tar.xz
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.13.tar.lz

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.13.tar.xz.sig
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.13.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 nmav at gnutls.org  Mon Apr  7 21:57:17 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 07 Apr 2014 21:57:17 +0200
Subject: [gnutls-devel] gnutls 3.1.23
Message-ID: <1396900637.21845.0.camel@nomad.lan>

Hello,
 I've just released gnutls 3.1.23. This is a bug fix release on the old
stable branch.


* Version 3.1.23 (released 2014-04-07)

** libgnutls: Ciphersuites that use the SHA256 or SHA384 MACs are
only available in TLS 1.0 as SSL 3.0 doesn't specify parameters for
these algorithms.

** libgnutls: gnutls_record_send is now safe to be called under DTLS when
in corked mode.

** libgnutls: Changed the behaviour in wildcard acceptance in certificates.
Wildcards are only accepted when there are more than two domain components
after the wildcard. This drops support for the permissive RFC2818 wildcards
and adds more conservative support based on the suggestions in RFC6125. Suggested 
by Jeffrey Walton.

** certtool: When no password is provided to export a PKCS #8 keys, do
not encrypt by default. This reverts to the certtool behavior of gnutls
3.0. The previous behavior of encrypting using an empty password can be
replicating using the new parameter --empty-password.

** p11tool: Avoid dual initialization of the PKCS #11 subsystem when
the --provider option is given.

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


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

GnuTLS may be downloaded directly from
<ftp://ftp.gnutls.org/gcrypt/gnutls/>.  A list of GnuTLS mirrors can be
found at <http://www.gnutls.org/download.html>.

Here are the XZ and LZIP compressed sources:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.23.tar.xz
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.23.tar.lz

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.23.tar.xz.sig
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.23.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 zaolin at das-labor.org  Tue Apr  8 23:19:00 2014
From: zaolin at das-labor.org (Zaolin)
Date: Tue, 08 Apr 2014 23:19:00 +0200
Subject: [gnutls-devel] Use of gnutls_x509_trust_list_add_cas() function
Message-ID: <534467C4.5010601@das-labor.org>

Hi,

yesterday I browsed the code of gnutls and found some strange behaviour
in the check of a return value.The gnutls_x509_trust_list_add_cas
function returns the elements which has been added to the trust list.

/**
 * gnutls_x509_trust_list_add_cas:
 * @list: The structure of the list
 * @clist: A list of CAs
 * @clist_size: The length of the CA list
 * @flags: should be 0.
 *
 * This function will add the given certificate authorities
 * to the trusted list. The list of CAs must not be deinitialized
 * during this structure's lifetime.
 *
 * Returns: The number of added elements is returned.
 *
 * Since: 3.0
 **/

But in the whole gnutls code including the apps the return value is
checked like this:

ret = gnutls_x509_trust_list_add_cas
if( ret < 0 ) {

The return value of this function can never be negative as the
implementation shows. So it seems that this is a bug if I am right ?

I am thinking about catching all misused lines of code and submiting a
patch.

Regards Zaolin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20140408/55a7aeec/attachment-0001.sig>

From nmav at gnutls.org  Wed Apr  9 11:00:46 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 9 Apr 2014 11:00:46 +0200
Subject: [gnutls-devel] Use of gnutls_x509_trust_list_add_cas() function
In-Reply-To: <534467C4.5010601@das-labor.org>
References: <534467C4.5010601@das-labor.org>
Message-ID: <CAJU7zaJQFjbEM4jiT7M0fKtpGNPDC0A8G-C+jzhg9=4S922nJw@mail.gmail.com>

On Tue, Apr 8, 2014 at 11:19 PM, Zaolin <zaolin at das-labor.org> wrote:
> Hi,
> yesterday I browsed the code of gnutls and found some strange behaviour
> in the check of a return value.The gnutls_x509_trust_list_add_cas
> function returns the elements which has been added to the trust list.
>  * Returns: The number of added elements is returned.
> But in the whole gnutls code including the apps the return value is
> checked like this:
> ret = gnutls_x509_trust_list_add_cas
> if( ret < 0 ) {
> The return value of this function can never be negative as the
> implementation shows. So it seems that this is a bug if I am right ?

Hello Zaolin,
 You are right. Feel free to submit a patch; the tricky part is
determining the uses of the function that require its return value be
non-zero.

regards,
Nikos


From nmav at gnutls.org  Thu Apr 10 20:28:38 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 10 Apr 2014 20:28:38 +0200
Subject: [gnutls-devel] gnutls 3.3.0
Message-ID: <1397154518.15268.7.camel@nomad.lan>

We are proud to announce the next stable GnuTLS release: Version 3.3.0.

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

The GnuTLS library is distributed under the terms of the GNU Lesser
General Public License version 2 (or later).  The OpenSSL compatibility
library, the self tests and the command line tools are all distributed
under the GNU General Public License version 3.0 (or later).  The manual
is distributed under the GNU Free Documentation License version 1.3 (or
later).

Special thanks to Red Hat that sponsored several of the new features.

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


What's New
==========
* Version 3.3.0 (released 2014-04-10)

** libgnutls: The initialization of the library was moved to a
constructor. That is, gnutls_global_init() is no longer required
unless linking with a static library or a system that does not
support library constructors.

** libgnutls: static libraries are not built by default.

** libgnutls: PKCS #11 initialization is delayed to first usage.
That avoids long delays in gnutls initialization due to broken PKCS #11
modules.

** libgnutls: The PKCS #11 subsystem is re-initialized "automatically"
on the first PKCS #11 API call after a fork. 

** libgnutls: certificate verification profiles were introduced
that can be specified as flags to verification functions. They
are enumerations in gnutls_certificate_verification_profiles_t
and can be converted to flags for use in a verification function
using GNUTLS_PROFILE_TO_VFLAGS().

** libgnutls: Added the ability to read system-specific initial
keywords, if they are prefixed with '@'. That allows a compile-time
specified configuration file to be used to read pre-configured priority
strings from. That can be used to impose system specific policies.

** libgnutls: Increased the default security level of priority
strings (NORMAL and PFS strings require at minimum a 1008 DH prime), 
and set a verification profile by default.  The LEGACY keyword is 
introduced to set the old defaults.

** libgnutls: Added support for the name constraints PKIX extension.
Currently only DNS names and e-mails are supported (no URIs, IPs
or DNs).

** libgnutls: Security parameter SEC_PARAM_NORMAL was renamed to 
SEC_PARAM_MEDIUM to avoid confusion with the priority string NORMAL.

** libgnutls: Added new API in x509-ext.h to handle X.509 extensions.
This API handles the X.509 extensions in isolation, allowing to parse
similarly formatted extensions stored in other structures.

** libgnutls: When generating DSA keys the macro GNUTLS_SUBGROUP_TO_BITS
can be used to specify a particular subgroup as the number of bits in
gnutls_privkey_generate; e.g., GNUTLS_SUBGROUP_TO_BITS(2048, 256).

** libgnutls: DH parameter generation is now delegated to nettle.
That unfortunately has the side-effect that DH parameters longer than
3072 bits, cannot be generated (not without a nettle update).

** libgnutls: Separated nonce RNG from the main RNG. The nonce
random number generator is based on salsa20/12.

** libgnutls: The buffer alignment provided to crypto backend is
enforced to be 16-byte aligned, when compiled with cryptodev
support. That allows certain cryptodev drivers to operate more
efficiently.

** libgnutls: Return error when a public/private key pair that doesn't
match is set into a credentials structure.

** libgnutls: Depend on p11-kit 0.20.0 or later.

** libgnutls: The new padding (%NEW_PADDING) experimental TLS extension
has been removed. It was not approved by IETF.

** libgnutls: The experimental xssl library is removed from the gnutls
distribution.

** libgnutls: Reduced the number of gnulib modules used in the main
library.

** libgnutls: Added priority string %DISABLE_WILDCARDS.

** libgnutls: Added the more extensible verification function
gnutls_certificate_verify_peers(), that allows checking, in addition
to a peer's DNS hostname, for the key purpose of the end certificate
(via PKIX extended key usage).

** certtool: Timestamps for serial numbers were increased to 8 bytes,
and in batch mode to 12 (appended with 4 random bytes).

** certtool: When no CRL number is provided (or value set to -1), then
a time-based number will be used, similarly to the serial generation
number in certificates.

** certtool: Print the SHA256 fingerprint of a certificate in addition
to SHA1.

** libgnutls: Added --enable-fips140-mode configuration option
(unsupported). That option enables (when running on FIPS140-enabled
system):
 o RSA, DSA and DH key generation as in FIPS-186-4 (using provable
primes)
 o The DRBG-CTR-AES256 deterministic random generator from SP800-90A.
 o Self-tests on initialization on ciphers/MACs, public key algorithms 
   and the random generator.
 o HMAC-SHA256 verification of the library on load.
 o MD5 is included for TLS purposes but cannot be used by the high level
   hashing functions.
 o All ciphers except AES are disabled.
 o All MACs and hashes except GCM and SHA are disabled (e.g., HMAC-MD5).
 o All keys (temporal and long term) are zeroized after use.
 o Security levels are adjusted to the FIPS140-2 recommendations (rather
   than ECRYPT).

** API and ABI modifications:
GNUTLS_VERIFY_DO_NOT_ALLOW_WILDCARDS: Added
gnutls_certificate_verify_peers: Added
gnutls_privkey_generate: Added
gnutls_pkcs11_crt_is_known: Added
gnutls_fips140_mode_enabled: Added
gnutls_sec_param_to_symmetric_bits: Added
gnutls_pubkey_export_ecc_x962: Added (replaces
gnutls_pubkey_get_pk_ecc_x962)
gnutls_pubkey_export_ecc_raw: Added (replaces
gnutls_pubkey_get_pk_ecc_raw)
gnutls_pubkey_export_dsa_raw: Added (replaces
gnutls_pubkey_get_pk_dsa_raw)
gnutls_pubkey_export_rsa_raw: Added (replaces
gnutls_pubkey_get_pk_rsa_raw)
gnutls_pubkey_verify_params: Added
gnutls_privkey_export_ecc_raw: Added
gnutls_privkey_export_dsa_raw: Added
gnutls_privkey_export_rsa_raw: Added
gnutls_privkey_import_ecc_raw: Added
gnutls_privkey_import_dsa_raw: Added
gnutls_privkey_import_rsa_raw: Added
gnutls_privkey_verify_params: Added
gnutls_x509_crt_check_hostname2: Added
gnutls_openpgp_crt_check_hostname2: Added
gnutls_x509_name_constraints_init: Added
gnutls_x509_name_constraints_deinit: Added
gnutls_x509_crt_get_name_constraints: Added
gnutls_x509_name_constraints_add_permitted: Added
gnutls_x509_name_constraints_add_excluded: Added
gnutls_x509_crt_set_name_constraints: Added
gnutls_x509_name_constraints_get_permitted: Added
gnutls_x509_name_constraints_get_excluded: Added
gnutls_x509_name_constraints_check: Added
gnutls_x509_name_constraints_check_crt: Added
gnutls_x509_crl_get_extension_data2: Added
gnutls_x509_crt_get_extension_data2: Added
gnutls_x509_crq_get_extension_data2: Added
gnutls_subject_alt_names_init: Added
gnutls_subject_alt_names_deinit: Added
gnutls_subject_alt_names_get: Added
gnutls_subject_alt_names_set: Added
gnutls_x509_ext_import_subject_alt_names: Added
gnutls_x509_ext_export_subject_alt_names: Added
gnutls_x509_crl_dist_points_init: Added
gnutls_x509_crl_dist_points_deinit: Added
gnutls_x509_crl_dist_points_get: Added
gnutls_x509_crl_dist_points_set: Added
gnutls_x509_ext_import_crl_dist_points: Added
gnutls_x509_ext_export_crl_dist_points: Added
gnutls_x509_ext_import_name_constraints: Added
gnutls_x509_ext_export_name_constraints: Added
gnutls_x509_aia_init: Added
gnutls_x509_aia_deinit: Added
gnutls_x509_aia_get: Added
gnutls_x509_aia_set: Added
gnutls_x509_ext_import_aia: Added
gnutls_x509_ext_export_aia: Added
gnutls_x509_ext_import_subject_key_id: Added
gnutls_x509_ext_export_subject_key_id: Added
gnutls_x509_ext_export_authority_key_id: Added
gnutls_x509_ext_import_authority_key_id: Added
gnutls_x509_aki_init: Added
gnutls_x509_aki_get_id: Added
gnutls_x509_aki_get_cert_issuer: Added
gnutls_x509_aki_set_id: Added
gnutls_x509_aki_set_cert_issuer: Added
gnutls_x509_aki_deinit: Added
gnutls_x509_ext_import_private_key_usage_period: Added
gnutls_x509_ext_export_private_key_usage_period: Added
gnutls_x509_ext_import_basic_constraints: Added
gnutls_x509_ext_export_basic_constraints: Added
gnutls_x509_ext_import_key_usage: Added
gnutls_x509_ext_export_key_usage: Added
gnutls_x509_ext_import_proxy: Added
gnutls_x509_ext_export_proxy: Added
gnutls_x509_policies_init: Added
gnutls_x509_policies_deinit: Added
gnutls_x509_policies_get: Added
gnutls_x509_policies_set: Added
gnutls_x509_ext_import_policies: Added
gnutls_x509_ext_export_policies: Added
gnutls_x509_key_purpose_init: Added
gnutls_x509_key_purpose_deinit: Added
gnutls_x509_key_purpose_set: Added
gnutls_x509_key_purpose_get: Added
gnutls_x509_ext_import_key_purposes: Added
gnutls_x509_ext_export_key_purposes: Added
gnutls_digest_self_test: Added (conditionally)
gnutls_mac_self_test: Added (conditionally)
gnutls_pk_self_test: Added (conditionally)
gnutls_cipher_self_test: Added (conditionally)
gnutls_global_set_mem_functions: Deprecated


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

GnuTLS may be downloaded directly from
<ftp://ftp.gnutls.org/gcrypt/gnutls/>.  A list of GnuTLS mirrors can be
found at <http://www.gnutls.org/download.html>.

Here are the XZ and LZIP compressed sources:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.0.tar.xz
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.0.tar.lz

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.0.tar.xz.sig
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.0.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 frankli714 at gmail.com  Fri Apr 11 03:34:43 2014
From: frankli714 at gmail.com (Frank Li)
Date: Thu, 10 Apr 2014 18:34:43 -0700
Subject: [gnutls-devel] Incorrect SSL heartbeat bounds checking (not
	exploitable)
Message-ID: <CALeAufUzaHfxqW0Wcq9bcL-QTgn-zUd7jgGCPnxnEqTinZ-NZw@mail.gmail.com>

Hi,

This may have already been discovered due to Heartbleed. gnutls's TLS
heartbeat implementation is not vulnerable to heartbleed but also does not
check the heartbeat length field matches the payload length. A heartbeat
response may be larger than the heartbeat request. I bring this up for
correctness and RFC6520-adherence sake.

Cheers,

Frank Li

Proof of concept: I think the below code is clear enough. I have tested
using openSSL's s_client to send a heartbeat request where the payload
length field is 1 larger than the payload, and I preset the padding. I see
my first bye of padding return.

I explain the error in comments //*** comment **//

In gnutls's lib/ext/heartbeat.c:

int _gnutls_heartbeat_handle(gnutls_session_t session, mbuffer_st * bufel)
{
  int ret;
  unsigned type;
  unsigned pos;
  uint8_t *msg = _mbuffer_get_udata_ptr(bufel);
  size_t hb_len, len = _mbuffer_get_udata_size(bufel);

  if (gnutls_heartbeat_allowed(session, GNUTLS_HB_PEER_ALLOWED_TO_SEND) ==
0)
    return gnutls_assert_val(GNUTLS_E_UNEXPECTED_PACKET);

  if (len < 4)
    return  gnutls_assert_val(GNUTLS_E_UNEXPECTED_PACKET_LENGTH);

  pos = 0;
  type = msg[pos++];

////**** hb_len is simply the length field (2 bytes) from heartbeat packet
***////
  hb_len = _gnutls_read_uint16(&msg[pos]);

////**** hb_len can be as big as len(padding)+len(payload). So not
vulnerable to heartbleed***////
if (hb_len > len - 3)
    return
        gnutls_assert_val(GNUTLS_E_UNEXPECTED_PACKET_LENGTH);

  pos += 2;

  switch (type) {
  case HEARTBEAT_REQUEST:
    _gnutls_buffer_reset(&session->internals.hb_remote_data);

////**** buffer sized to that of hb_len, which could be wrong (like in
heartbleed)***////
    ret =
        _gnutls_buffer_resize(&session->internals.
            hb_remote_data, hb_len);
    if (ret < 0)
      return gnutls_assert_val(ret);

////**** copying hb_len of data, which can reading bytes in padding (no
further). Hence this is not vulnerable, but still is an unchecked bound and
not RFC compliant ***////
    if (hb_len > 0)
      memcpy(session->internals.hb_remote_data.data,
             &msg[pos], hb_len);
    session->internals.hb_remote_data.length = hb_len;

    return gnutls_assert_val(GNUTLS_E_HEARTBEAT_PING_RECEIVED);

  case HEARTBEAT_RESPONSE:
.... (end of important stuff)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20140410/4e616063/attachment.html>

From peter.dettman at bouncycastle.org  Fri Apr 11 11:02:38 2014
From: peter.dettman at bouncycastle.org (Peter Dettman)
Date: Fri, 11 Apr 2014 16:02:38 +0700
Subject: [gnutls-devel] Incorrect SSL heartbeat bounds checking (not
	exploitable)
In-Reply-To: <CALeAufUzaHfxqW0Wcq9bcL-QTgn-zUd7jgGCPnxnEqTinZ-NZw@mail.gmail.com>
References: <CALeAufUzaHfxqW0Wcq9bcL-QTgn-zUd7jgGCPnxnEqTinZ-NZw@mail.gmail.com>
Message-ID: <5347AFAE.4040908@bouncycastle.org>

Hi All,

I concur with Frank, in that this code is not enforcing a minimum length 
for the padding of 16 bytes as specified in RFC 6520.

       if (len < 4)
         return  gnutls_assert_val(GNUTLS_E_UNEXPECTED_PACKET_LENGTH);

The minimum packet length is 19, so that should be "len < 19".

       if (hb_len > len - 3)
         return gnutls_assert_val(GNUTLS_E_UNEXPECTED_PACKET_LENGTH);

The payload is bounded by the minimum 19 bytes for non-payload data, so 
this should be "hb_len > len - 19". I would wonder also whether that is 
the most appropriate error code for a malformed message, but I don't 
know enough about the available error codes to judge.

A further comment on the message format:

    struct {
       HeartbeatMessageType type;
       uint16 payload_length;
       opaque payload[HeartbeatMessage.payload_length];
       opaque padding[padding_length];
    } HeartbeatMessage;
  

The "padding_length" is defined implicitly here i.e. "whatever is left 
in the record following the previous fields" (subject to being at least 
16 bytes). That's quite a strange choice; the only other example of such 
a thing I can think of is ClientHello.extensions, where there is a more 
apparent justification. Why not explicitly include the padding_length?

Perhaps more seriously, requiring that it be filled with "random padding 
of at least 16 bytes" is 1) semantically pretty meaningless (later it 
says that the receiver MUST ignore the contents anyway!), and 2) 
suspicious in the light of DUAL_EC_DRBG and other RNG-related 
revelations. I would advise to review what randomness is used by GnuTLS 
here, and I suggest a deterministic construction of the TLS PRF keyed on 
a hash of the payload  (by analogy to RFC 6979) should be considered 
instead of actual random data (especially if the same source is used for 
key material).

Regards
Pete Dettman

On 11/04/2014 8:34 AM, Frank Li wrote:
> This may have already been discovered due to Heartbleed. gnutls's TLS 
> heartbeat implementation is not vulnerable to heartbleed but also does 
> not check the heartbeat length field matches the payload length. A 
> heartbeat response may be larger than the heartbeat request. I bring 
> this up for correctness and RFC6520-adherence sake.



From home_pw at msn.com  Fri Apr 11 12:30:35 2014
From: home_pw at msn.com (Peter Williams)
Date: Fri, 11 Apr 2014 10:30:35 +0000
Subject: [gnutls-devel]
 =?utf-8?q?Incorrect_SSL_heartbeat_bounds_checking_?=
 =?utf-8?q?=28not=09exploitable=29?=
Message-ID: <SNT405-EAS325C749182542F0F927150592540@phx.gbl>

general comment.


Dont think TOO much in terms of per-layer countermeasures (i.e. dont assume that the attack vector is via just one layer) Dont forget to think like those who have designed packet-based  exploits for decades now - and assume that folks deliver malformed packets in order to alter the behaviour of the driver STACK-  an ability enabled because of their packet-handlers coding style and pre-placement by the OS/networking vendor of code so as to accept the exploit (or become an exploit typically by inducing a timing based covert channel). Assume the very coding style of drivers and packet handlers is what allows for the class of exploit, that is; and that the exploitability is a function of the COMBINATION of handlers.


For 40+ years, folks have designed C structures like this, for messaging and packet handling. And , if one looks back over 40 years of telco-linked computing at HOW exploits were delivered or effected via networking packet based methods of altering the packet handler OR the protocol handler, its always the same story.


be careful. Even as late as 1990, you?d be taken out and shot for addressing these topics publicly. There is a lot of still secret long-term vendor/govt  politics around this topic, and NOT all of it/was badly motivated.








From: Peter Dettman
Sent: ?Friday?, ?April? ?11?, ?2014 ?2?:?55? ?AM
To: gnutls-devel at lists.gnutls.org





Hi All,

I concur with Frank, in that this code is not enforcing a minimum length 
for the padding of 16 bytes as specified in RFC 6520.

       if (len < 4)
         return  gnutls_assert_val(GNUTLS_E_UNEXPECTED_PACKET_LENGTH);

The minimum packet length is 19, so that should be "len < 19".

       if (hb_len > len - 3)
         return gnutls_assert_val(GNUTLS_E_UNEXPECTED_PACKET_LENGTH);

The payload is bounded by the minimum 19 bytes for non-payload data, so 
this should be "hb_len > len - 19". I would wonder also whether that is 
the most appropriate error code for a malformed message, but I don't 
know enough about the available error codes to judge.

A further comment on the message format:

    struct {
       HeartbeatMessageType type;
       uint16 payload_length;
       opaque payload[HeartbeatMessage.payload_length];
       opaque padding[padding_length];
    } HeartbeatMessage;
  

The "padding_length" is defined implicitly here i.e. "whatever is left 
in the record following the previous fields" (subject to being at least 
16 bytes). That's quite a strange choice; the only other example of such 
a thing I can think of is ClientHello.extensions, where there is a more 
apparent justification. Why not explicitly include the padding_length?

Perhaps more seriously, requiring that it be filled with "random padding 
of at least 16 bytes" is 1) semantically pretty meaningless (later it 
says that the receiver MUST ignore the contents anyway!), and 2) 
suspicious in the light of DUAL_EC_DRBG and other RNG-related 
revelations. I would advise to review what randomness is used by GnuTLS 
here, and I suggest a deterministic construction of the TLS PRF keyed on 
a hash of the payload  (by analogy to RFC 6979) should be considered 
instead of actual random data (especially if the same source is used for 
key material).

Regards
Pete Dettman

On 11/04/2014 8:34 AM, Frank Li wrote:
> This may have already been discovered due to Heartbleed. gnutls's TLS 
> heartbeat implementation is not vulnerable to heartbleed but also does 
> not check the heartbeat length field matches the payload length. A 
> heartbeat response may be larger than the heartbeat request. I bring 
> this up for correctness and RFC6520-adherence sake.


_______________________________________________
Gnutls-devel mailing list
Gnutls-devel at lists.gnutls.org
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20140411/472da2fd/attachment.html>

From nmav at gnutls.org  Fri Apr 11 13:46:42 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 11 Apr 2014 13:46:42 +0200
Subject: [gnutls-devel] Incorrect SSL heartbeat bounds checking (not
	exploitable)
In-Reply-To: <5347AFAE.4040908@bouncycastle.org>
References: <CALeAufUzaHfxqW0Wcq9bcL-QTgn-zUd7jgGCPnxnEqTinZ-NZw@mail.gmail.com>
 <5347AFAE.4040908@bouncycastle.org>
Message-ID: <CAJU7zaKR_EH2OETmcnXErfcZzB+xb+adu+7VZRAHe=BOg1gKjA@mail.gmail.com>

On Fri, Apr 11, 2014 at 11:02 AM, Peter Dettman
<peter.dettman at bouncycastle.org> wrote:
> Hi All,
> I concur with Frank, in that this code is not enforcing a minimum length for
> the padding of 16 bytes as specified in RFC 6520.

Thank you Frank and Peter for investigating the issue.

If I understand correctly what you say Frank, I don't think we can do
much about it. The payload is set by the sender, so if he sets it
incorrectly we cannot do anything than believe him (given the fact
that the given structure allows unaccountable data). Being more strict
as Peter says and ensuring that padding is at least 16 bytes would
help.

>       if (len < 4)
>         return  gnutls_assert_val(GNUTLS_E_UNEXPECTED_PACKET_LENGTH);
> The minimum packet length is 19, so that should be "len < 19".

The checks are check as you go, so the code only checks whether the
data that are going to be read next actually exist. It's a nice idea
to be updated to ensure that padding_length is at least 16 bytes, but
I'm afraid that given the inexplicable reason for padding, there may
be implementations that don't follow that requirement correctly. In
any case, I'll try to update it to be more precise.

> A further comment on the message format:
>    struct {
>       HeartbeatMessageType type;
>       uint16 payload_length;
>       opaque payload[HeartbeatMessage.payload_length];
>       opaque padding[padding_length];
>    } HeartbeatMessage;
> The "padding_length" is defined implicitly here i.e. "whatever is left in
> the record following the previous fields" (subject to being at least 16
> bytes). That's quite a strange choice; the only other example of such a
> thing I can think of is ClientHello.extensions, where there is a more
> apparent justification. Why not explicitly include the padding_length?

Yes, that's a pretty weird decision. Unfortunately I do not remember
much of the TLS heartbeat extension discussion in TLS working group.
The distinction between payload and padding (and the requirement to
have a padding of at least 16), is there for undocumented reasons. I
cannot guess the reason it is there.

 and 2) suspicious in the
> light of DUAL_EC_DRBG and other RNG-related revelations. I would advise to

I remember that this was not the choice of the authors. That change
was forced by the IESG reviewers.
http://www.ietf.org/mail-archive/web/tls/current/msg08311.html

> review what randomness is used by GnuTLS here, and I suggest a deterministic
> construction of the TLS PRF keyed on a hash of the payload  (by analogy to
> RFC 6979) should be considered instead of actual random data (especially if
> the same source is used for key material).

I'd be afraid to introduce more complexity by an rng only for that
code (which is really rarely enabled/used). In 3.3.0 I've separated
the rng to generate keys from the rng that generates nonces as in that
case, and I believe that should be sufficient.

regards,
Nikos


From frankli714 at gmail.com  Fri Apr 11 18:18:37 2014
From: frankli714 at gmail.com (Frank Li)
Date: Fri, 11 Apr 2014 09:18:37 -0700
Subject: [gnutls-devel] Incorrect SSL heartbeat bounds checking (not
	exploitable)
In-Reply-To: <CAJU7zaKR_EH2OETmcnXErfcZzB+xb+adu+7VZRAHe=BOg1gKjA@mail.gmail.com>
References: <CALeAufUzaHfxqW0Wcq9bcL-QTgn-zUd7jgGCPnxnEqTinZ-NZw@mail.gmail.com>
 <5347AFAE.4040908@bouncycastle.org>
 <CAJU7zaKR_EH2OETmcnXErfcZzB+xb+adu+7VZRAHe=BOg1gKjA@mail.gmail.com>
Message-ID: <CALeAufWnkjBbhn0fXhW4PuRuJxQQbB0_hsEiS5OCKBcafPw++Q@mail.gmail.com>

Hi Nikos and Peter,

Thanks for the quick confirmation and reply. The heartbeat RFC specs are
indeed a bit odd. My suggestions would be to update whenever convenient the
if (len < 4) check to if (len <19), and the if (hb_len > len - 3) to if
(hb_len > len - 19).

As for client compatibility, I'm inclined to believe the above changes
should not be a serious issue. The RFC specs are quite clear (for unclear
reasons) on the message structure, and other TLS implementations I've seen
have not made a mistake about sending a 16 byte padding. In fact, openSSL's
bounds check protecting against Heartbleed checks that (hb_len == len -
19), enforcing an exactly 16 byte padding. I'd imagine if gnuTLS included
those bounds, any reasonable client should decide to follow the RFC for
sake of working correctly with both openSSL and gnuTLS :P

Anyhow, this is not a priority bug, just wanted to inform you guys (noted
this when investigating Heartbleed).

Cheers!

Frank





On Fri, Apr 11, 2014 at 4:46 AM, Nikos Mavrogiannopoulos <nmav at gnutls.org>wrote:

> On Fri, Apr 11, 2014 at 11:02 AM, Peter Dettman
> <peter.dettman at bouncycastle.org> wrote:
> > Hi All,
> > I concur with Frank, in that this code is not enforcing a minimum length
> for
> > the padding of 16 bytes as specified in RFC 6520.
>
> Thank you Frank and Peter for investigating the issue.
>
> If I understand correctly what you say Frank, I don't think we can do
> much about it. The payload is set by the sender, so if he sets it
> incorrectly we cannot do anything than believe him (given the fact
> that the given structure allows unaccountable data). Being more strict
> as Peter says and ensuring that padding is at least 16 bytes would
> help.
>
> >       if (len < 4)
> >         return  gnutls_assert_val(GNUTLS_E_UNEXPECTED_PACKET_LENGTH);
> > The minimum packet length is 19, so that should be "len < 19".
>
> The checks are check as you go, so the code only checks whether the
> data that are going to be read next actually exist. It's a nice idea
> to be updated to ensure that padding_length is at least 16 bytes, but
> I'm afraid that given the inexplicable reason for padding, there may
> be implementations that don't follow that requirement correctly. In
> any case, I'll try to update it to be more precise.
>
> > A further comment on the message format:
> >    struct {
> >       HeartbeatMessageType type;
> >       uint16 payload_length;
> >       opaque payload[HeartbeatMessage.payload_length];
> >       opaque padding[padding_length];
> >    } HeartbeatMessage;
> > The "padding_length" is defined implicitly here i.e. "whatever is left in
> > the record following the previous fields" (subject to being at least 16
> > bytes). That's quite a strange choice; the only other example of such a
> > thing I can think of is ClientHello.extensions, where there is a more
> > apparent justification. Why not explicitly include the padding_length?
>
> Yes, that's a pretty weird decision. Unfortunately I do not remember
> much of the TLS heartbeat extension discussion in TLS working group.
> The distinction between payload and padding (and the requirement to
> have a padding of at least 16), is there for undocumented reasons. I
> cannot guess the reason it is there.
>
>  and 2) suspicious in the
> > light of DUAL_EC_DRBG and other RNG-related revelations. I would advise
> to
>
> I remember that this was not the choice of the authors. That change
> was forced by the IESG reviewers.
> http://www.ietf.org/mail-archive/web/tls/current/msg08311.html
>
> > review what randomness is used by GnuTLS here, and I suggest a
> deterministic
> > construction of the TLS PRF keyed on a hash of the payload  (by analogy
> to
> > RFC 6979) should be considered instead of actual random data (especially
> if
> > the same source is used for key material).
>
> I'd be afraid to introduce more complexity by an rng only for that
> code (which is really rarely enabled/used). In 3.3.0 I've separated
> the rng to generate keys from the rng that generates nonces as in that
> case, and I believe that should be sufficient.
>
> regards,
> Nikos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20140411/b5b1bbf1/attachment-0001.html>

From peter.dettman at bouncycastle.org  Sat Apr 12 05:53:55 2014
From: peter.dettman at bouncycastle.org (Peter Dettman)
Date: Sat, 12 Apr 2014 10:53:55 +0700
Subject: [gnutls-devel] Incorrect SSL heartbeat bounds checking (not
	exploitable)
In-Reply-To: <CAJU7zaKR_EH2OETmcnXErfcZzB+xb+adu+7VZRAHe=BOg1gKjA@mail.gmail.com>
References: <CALeAufUzaHfxqW0Wcq9bcL-QTgn-zUd7jgGCPnxnEqTinZ-NZw@mail.gmail.com>	<5347AFAE.4040908@bouncycastle.org>
 <CAJU7zaKR_EH2OETmcnXErfcZzB+xb+adu+7VZRAHe=BOg1gKjA@mail.gmail.com>
Message-ID: <5348B8D3.8090505@bouncycastle.org>

Hi Nikos,
I noticed the git commit go thru yesterday and it appears correct to me 
(although the commit message names the wrong Peter!).

On 11/04/2014 6:46 PM, Nikos Mavrogiannopoulos wrote:
> I remember that this was not the choice of the authors. That change 
> was forced by the IESG reviewers. 
> http://www.ietf.org/mail-archive/web/tls/current/msg08311.html 

Thankyou for the link; your comments on that thread do you credit. May I 
infer that you were somehat dubious of the reasoning at the time?

> I'd be afraid to introduce more complexity by an rng only for that 
> code (which is really rarely enabled/used). In 3.3.0 I've separated 
> the rng to generate keys from the rng that generates nonces as in that 
> case, and I believe that should be sufficient.

I confirmed for myself that the heartbeat padding is now filled using 
GNUTLS_RND_NONCE (as of 26 Jan, 2013). I agree that is probably 
sufficient, and am glad to see that such a separation exists in GnuTLS 
more generally. The original author's "decision" to use GNUTLS_RND_NONCE 
in one place and GNUTLS_RND_RANDOM in another (if I understand the code 
- for the padding) is less comforting.

Regards,
Pete Dettman



From peter.dettman at bouncycastle.org  Sat Apr 12 08:37:58 2014
From: peter.dettman at bouncycastle.org (Peter Dettman)
Date: Sat, 12 Apr 2014 13:37:58 +0700
Subject: [gnutls-devel] An (historical) heartbeat.c issue more relevant to
	Heartbleed
Message-ID: <5348DF46.30604@bouncycastle.org>

Hi All,
I would like to draw the list's attention to this commit of heartbeat.c:
https://gitorious.org/gnutls/gnutls/commit/c2793ea302bc5e499c19f8969ca473045ca8d768

Putting aside the error in setting the message type, let's look at the 
_gnutls_write_uint16 call. This call is necessary to correctly set the 
HeartbeatMessage.payload_length field, and was apparently an oversight 
in the previous commit which migrated from the use of gnutls_buffer_st.

In the absence of the payload_length being set correctly, it actually is 
written to from the random data of the payload itself (or perhaps 
padding if the payload is short). It seems clear that at least some of 
those generated packets will therefore be malformed in the precise 
manner associated with the Heartbleed vulnerability.

The previous commit also introduced the ability to disable heartbeats 
when building, but AFAICT, they remained enabled by default. At a 
cursory analysis, the affected releases are/were: 3.1.7, 3.1.8, 3.1.9, 
3.1.10. Those presently scouring their logs for evidence of the 
Heartbleed attack in the wild may need to take this into account.

I have not yet confirmed this behaviour with actual builds, and would 
welcome corrections on any of the above.

Regards,
Pete Dettman



From nmav at gnutls.org  Sat Apr 12 09:00:08 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 12 Apr 2014 09:00:08 +0200
Subject: [gnutls-devel] An (historical) heartbeat.c issue more relevant
	to Heartbleed
In-Reply-To: <5348DF46.30604@bouncycastle.org>
References: <5348DF46.30604@bouncycastle.org>
Message-ID: <CAJU7zaLvg1NEHth+Y=xLNqKBnKcFzDrAHCZUXXsdGpfsPuSWjQ@mail.gmail.com>

On Sat, Apr 12, 2014 at 8:37 AM, Peter Dettman
<peter.dettman at bouncycastle.org> wrote:

> The previous commit also introduced the ability to disable heartbeats when
> building, but AFAICT, they remained enabled by default. At a cursory
> analysis, the affected releases are/were: 3.1.7, 3.1.8, 3.1.9, 3.1.10. Those
> presently scouring their logs for evidence of the Heartbleed attack in the
> wild may need to take this into account.

Hello,
 I have not yet checked in detail, but note that heartbeats even if
compiled in gnutls, they remain disabled by default unless an
application explicitly enables them. Given that there is no need for
heartbeats in TLS I doubt that there is any application enabling them.
So it seems that these versions of gnutls are usable/broken in respect
to heartbeats, and if anyone would have used this broken version of
gnutls to debug openssl heartbeats he may have uncovered the bug :)

regards,
Nikos


From nmav at gnutls.org  Sat Apr 12 09:15:00 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 12 Apr 2014 09:15:00 +0200
Subject: [gnutls-devel] Incorrect SSL heartbeat bounds checking (not
	exploitable)
In-Reply-To: <5348B8D3.8090505@bouncycastle.org>
References: <CALeAufUzaHfxqW0Wcq9bcL-QTgn-zUd7jgGCPnxnEqTinZ-NZw@mail.gmail.com>
 <5347AFAE.4040908@bouncycastle.org>
 <CAJU7zaKR_EH2OETmcnXErfcZzB+xb+adu+7VZRAHe=BOg1gKjA@mail.gmail.com>
 <5348B8D3.8090505@bouncycastle.org>
Message-ID: <CAJU7zaJs0cQsbxWezcPQjhv=T62W-aTF5NL3Ky4RdYL2gmOjEw@mail.gmail.com>

On Sat, Apr 12, 2014 at 5:53 AM, Peter Dettman
<peter.dettman at bouncycastle.org> wrote:
> Hi Nikos,
> I noticed the git commit go thru yesterday and it appears correct to me
> (although the commit message names the wrong Peter!).

Sorry, copy-paste error. I've corrected it in the NEWS entry.

>> I remember that this was not the choice of the authors. That change was
>> forced by the IESG reviewers.
>> http://www.ietf.org/mail-archive/web/tls/current/msg08311.html
> Thankyou for the link; your comments on that thread do you credit. May I
> infer that you were somehat dubious of the reasoning at the time?

If I remember well I think my point was based on the fact that
requiring the data to be random you cannot verify if any of the
parties are leaking information (either willingly or not) to the peer.
The IESG's point was that using a fixed string would allow a known
plaintext attack on the cipher. There are of course arguments for both
points. Given the dual-ec issue, my suggestion looks better, but a
different vulnerability on the cipher could have made my suggestion
dubious.

regards,
Nikos


From peter.dettman at bouncycastle.org  Sat Apr 12 09:40:18 2014
From: peter.dettman at bouncycastle.org (Peter Dettman)
Date: Sat, 12 Apr 2014 14:40:18 +0700
Subject: [gnutls-devel] An (historical) heartbeat.c issue more relevant
 to Heartbleed
In-Reply-To: <CAJU7zaLvg1NEHth+Y=xLNqKBnKcFzDrAHCZUXXsdGpfsPuSWjQ@mail.gmail.com>
References: <5348DF46.30604@bouncycastle.org>
 <CAJU7zaLvg1NEHth+Y=xLNqKBnKcFzDrAHCZUXXsdGpfsPuSWjQ@mail.gmail.com>
Message-ID: <5348EDE2.3080409@bouncycastle.org>

On 12/04/2014 2:00 PM, Nikos Mavrogiannopoulos wrote:
> So it seems that these versions of gnutls are usable/broken in respect 
> to heartbeats, and if anyone would have used this broken version of 
> gnutls to debug openssl heartbeats he may have uncovered the bug :) 
> regards, Nikos 

Yes, I did have the same thought, but left it out of my post, which was 
already in danger of sounding accusatory.

I got as far as implementing the structures from RFC 6520 in 
BouncyCastle, in late June of last year, but never got around to 
actually implementing the protocol. I certainly would have tested 
against openssl (as usual), but would I have "asked the right questions"?

Pete.



From wiz at netbsd.org  Sat Apr 12 12:31:13 2014
From: wiz at netbsd.org (Thomas Klausner)
Date: Sat, 12 Apr 2014 12:31:13 +0200
Subject: [gnutls-devel] test hangs in 3.2.8.1
In-Reply-To: <CAJU7za++nBXywgL_seXTNjYbwGZKyDoF=zQDLfhXepJupYRW=Q@mail.gmail.com>
References: <20140116101819.GK16992@danbala.tuwien.ac.at>
 <52D8D541.2030109@gnutls.org>
 <20140117103102.GV16992@danbala.tuwien.ac.at>
 <52DC0C76.4020805@gnutls.org>
 <20140209115236.GI27673@danbala.tuwien.ac.at>
 <sfid-+20140212-094819-+011.19-1@spamfilter.osbf.lua>
 <CAJU7za++nBXywgL_seXTNjYbwGZKyDoF=zQDLfhXepJupYRW=Q@mail.gmail.com>
Message-ID: <20140412103113.GR10596@danbala.tuwien.ac.at>

On Wed, Feb 12, 2014 at 09:48:10AM +0100, Nikos Mavrogiannopoulos wrote:
> It seems that the executed programs are linked to a different gnutls
> version, which doesn't support TLS 1.2. Could that be the case?

No, I don't think that was it. My guess is that previous servers
started by tests were not killed, and thus were reused. I found some
of these later in my process list and can't really tell if they were
active at the time or not.

I've tried the 3.2.12 testsuite today and saw:

FAIL: mini-dtls-rehandshake
===========================

gnutls_rehandshake: Resource temporarily unavailable, try again.

The same test worked when I tried again, and the whole test suite
finished successfully.

So currently there are no open issues with the tests.

Thanks,
 Thomas


From nikita at karetnikov.org  Sun Apr 13 23:55:07 2014
From: nikita at karetnikov.org (Nikita Karetnikov)
Date: Mon, 14 Apr 2014 01:55:07 +0400
Subject: [gnutls-devel] =?utf-8?q?Suggestion=3A_mention_=E2=80=98--priorit?=
 =?utf-8?q?y=3DPFS=E2=80=99__in_the_manpage?=
Message-ID: <87ha5wzyh0.fsf@karetnikov.org>

I believe this [1] is important and should be mentioned in the manpage
of gnutls-cli.  I?ve checked the manpage of 3.2.12, and it?s not there.
Perhaps it?s not the case for the development version, but I don?t
understand how the manpages are generated and which file have to be
modified.

[1] http://lists.gnutls.org/pipermail/gnutls-help/2014-March/003364.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: </pipermail/attachments/20140414/17a49b84/attachment.sig>

From nmav at gnutls.org  Mon Apr 14 11:55:07 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 14 Apr 2014 11:55:07 +0200
Subject: [gnutls-devel] Suggestion: mention '--priority=PFS' in the
	manpage
In-Reply-To: <87ha5wzyh0.fsf@karetnikov.org>
References: <87ha5wzyh0.fsf@karetnikov.org>
Message-ID: <CAJU7zaLAu7=9YD-Jniw806zYZTEAaNcrARnT++S+2np44CfuOA@mail.gmail.com>

On Sun, Apr 13, 2014 at 11:55 PM, Nikita Karetnikov
<nikita at karetnikov.org> wrote:
> I believe this [1] is important and should be mentioned in the manpage
> of gnutls-cli.  I've checked the manpage of 3.2.12, and it's not there.
> Perhaps it's not the case for the development version, but I don't
> understand how the manpages are generated and which file have to be
> modified.

That you. I've now mentioned PFS to the list of acceptable strings.

regards,
Nikos


From mk at cognitivedissonance.ca  Sun Apr 13 19:08:43 2014
From: mk at cognitivedissonance.ca (MK)
Date: Sun, 13 Apr 2014 13:08:43 -0400
Subject: [gnutls-devel] 3.3.0 check fails "chainverify" on raspbian
Message-ID: <20140413130843.cbf8fe06e9a7023d4fa6f0e1@cognitivedissonance.ca>

`make check` failed on raspbian 
(debian wheezy for the armv6 "raspberry pi"):

==========================================
Testsuite summary for GnuTLS 3.3.0
==========================================
# TOTAL: 83
# PASS:  80
# SKIP:  2
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0
==========================================
See tests/test-suite.log
Please report to bugs at gnutls.org
==========================================

'test-suite.log' is attached.   3.2.12 passes check on the same
platform.

I did not have this problem on fedora 20 x86_64.

MK

-- 
"Enthusiasm is not the enemy of the intellect." (said of Irving Howe)
-------------- next part --------------
========================================
   GnuTLS 3.3.0: tests/test-suite.log
========================================

# TOTAL: 83
# PASS:  80
# SKIP:  2
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: chainverify
=================


SKIP: mini-record-range
=======================


SKIP: fips-test
===============

Please note that if in FIPS140 mode, you need to assure the library's integrity prior to running this test
We are not in FIPS140 mode


From nmav at gnutls.org  Mon Apr 14 13:17:20 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 14 Apr 2014 13:17:20 +0200
Subject: [gnutls-devel] 3.3.0 check fails "chainverify" on raspbian
In-Reply-To: <20140413130843.cbf8fe06e9a7023d4fa6f0e1@cognitivedissonance.ca>
References: <20140413130843.cbf8fe06e9a7023d4fa6f0e1@cognitivedissonance.ca>
Message-ID: <CAJU7zaLpjYOzyoZHsW4uR_s5b_aCUSfqpEJEMGUBqyYRbb=0dQ@mail.gmail.com>

On Sun, Apr 13, 2014 at 7:08 PM, MK <mk at cognitivedissonance.ca> wrote:
> `make check` failed on raspbian
> (debian wheezy for the armv6 "raspberry pi"):
> 'test-suite.log' is attached.   3.2.12 passes check on the same
> platform.

Hello,
 Most probably you'll need the check for clues in the chainverify.log.
The best would be if you could debug the issue on this system.

regards,
Nikos


From nmav at gnutls.org  Thu Apr 17 00:12:57 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 17 Apr 2014 00:12:57 +0200
Subject: [gnutls-devel] 3.3.0pre0 - [sparc] Bus error on chainverify test
In-Reply-To: <20140330173753.GB3217@downhill.g.la>
References: <20140330173753.GB3217@downhill.g.la>
Message-ID: <1397686377.12768.2.camel@nomad.lan>

On Sun, 2014-03-30 at 19:37 +0200, Andreas Metzler wrote:
> Hello,
> 
> 3.3.0pre0's testsuite produces an error on sparc:
> -------------
> (sid_sparc-dchroot)ametzler at smetana:~/GNUTLS/gnutls28-3.3.0~pre0$ ./tests/chainverify
> Bus error
> (sid_sparc-dchroot)ametzler at smetana:~/GNUTLS/gnutls28-3.3.0~pre0$

Thank you. It seems that certs[4] in chainverify was not sufficient for
the last test that had 5 certificates. Since there were quite some
variables in the stack they were happily being overwritten and that
caused quite some mayhem. Thank you for providing access to that system.

regards,
Nikos

Fix:
https://gitorious.org/gnutls/gnutls/commit/98901d7c4bc5d2a143f4f19dc37bb377f821f8bd





From josemrecio at gmail.com  Wed Apr 16 20:30:13 2014
From: josemrecio at gmail.com (JMRecio)
Date: Wed, 16 Apr 2014 20:30:13 +0200
Subject: [gnutls-devel] pull_timeout_func invoked with transport_send_ptr
	instead of transport_recv_ptr
Message-ID: <534ECC35.7060808@gmail.com>

Hello, all,

I am using GnuTLS 3.2.13 (background on the project below), I have found 
a behaviour that I think is a bug:

pull_timeout_func() is invoked with the transport pointer registered for 
push_func(), it is not invoked with the same transport pointer as 
pull_func().

See first line in _gnutls_io_check_recv(), fd is assigned to 
session->internals.transport_send_ptr instead of 
session->internals.transport_recv_ptr

int _gnutls_io_check_recv(gnutls_session_t session, unsigned int ms)
{
         gnutls_transport_ptr_t fd = session->internals.transport_send_ptr;
         int ret = 0, err;

         if (unlikely
             (session->internals.pull_timeout_func == system_recv_timeout
              && session->internals.pull_func != system_read)) {
                 _gnutls_debug_log("The pull function has been replaced 
but not the pull timeout.");



Background (probably not relevant, but just in case): I am developing a 
SSL adaptor to netty.io (powerful java async and threading framework) 
based on GnuTLS.

I/O and threading is managed by netty, received datagrams are stored in 
queues, that I can get from the pull_func() and pull_func_timeout() 
based on the transport pointer. For example, when pull_func_timeout() is 
invoked, I return a positive number if the queue is not empty.

I have found some "impedance matching" problems (that I would be happy 
to comment) but I think GnuTLS documentation and code is much better 
than anything else out there for this project, kudos for the great job.

JM




From aklitzing at gmail.com  Thu Apr 17 23:31:29 2014
From: aklitzing at gmail.com (A. Klitzing)
Date: Thu, 17 Apr 2014 23:31:29 +0200
Subject: [gnutls-devel] memcpy problem with RSA-PSK
Message-ID: <CAJaftdiCAD--M9u1Ar6fri-aQJ5CsAQdx=6eiqHdXj-rFreRTw@mail.gmail.com>

Hi there!

We implemented a client that used GnuTLS with an RSA-PSK cipher. We're
compiling our binary with the address sanitizer of clang and found that it
will catch a memcpy problem of GnuTLS.

So we tried a little bit and used valgrind, too. It will get the same
stacktrace. The same problem is in gnutls-cli binary with RSA-PSK. So this
cannot be a mistake in our code.

This stacktrace is from valgrind with v3.3.0 of gnutls-cli. You will get
the same in v3.2.4.

Could you look into it? It's really annoying that the adress sanitizer will
terminate our binary because of GnuTLS. ;-)

Best regards!
  Andr? Klitzing


Used cipher: RSA_PSK_SHA_AES_256_CBC_SHA1

==10822== Invalid write of size 2
==10822==    at 0x4C2CD54: memcpy@@GLIBC_2.14 (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==10822==    by 0x4F14C4A: _gnutls_proc_psk_server_kx (psk.c:350)
==10822==    by 0x4E7132F: _gnutls_recv_server_kx_message (gnutls_kx.c:452)
==10822==    by 0x4E6C3A7: _gnutls_handshake_client
(gnutls_handshake.c:2717)
==10822==    by 0x4E6BD21: gnutls_handshake (gnutls_handshake.c:2532)
==10822==    by 0x409952: do_handshake (cli.c:1501)
==10822==    by 0x408B3E: main (cli.c:1119)
==10822==  Address 0x71d8ca0 is 48 bytes inside a block of size 64 free'd
==10822==    at 0x4C2999C: free (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==10822==    by 0x4F0D674: _gnutls_proc_x509_server_crt (cert.c:1148)
==10822==    by 0x4F0E183: _gnutls_proc_crt (cert.c:1369)
==10822==    by 0x4E717D3: _gnutls_recv_server_certificate (gnutls_kx.c:634)
==10822==    by 0x4E6C1DE: _gnutls_handshake_client
(gnutls_handshake.c:2695)
==10822==    by 0x4E6BD21: gnutls_handshake (gnutls_handshake.c:2532)
==10822==    by 0x409952: do_handshake (cli.c:1501)
==10822==    by 0x408B3E: main (cli.c:1119)
==10822==
==10822== Invalid write of size 1
==10822==    at 0x4F14C54: _gnutls_proc_psk_server_kx (psk.c:351)
==10822==    by 0x4E7132F: _gnutls_recv_server_kx_message (gnutls_kx.c:452)
==10822==    by 0x4E6C3A7: _gnutls_handshake_client
(gnutls_handshake.c:2717)
==10822==    by 0x4E6BD21: gnutls_handshake (gnutls_handshake.c:2532)
==10822==    by 0x409952: do_handshake (cli.c:1501)
==10822==    by 0x408B3E: main (cli.c:1119)
==10822==  Address 0x71d8ca4 is 52 bytes inside a block of size 64 free'd
==10822==    at 0x4C2999C: free (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==10822==    by 0x4F0D674: _gnutls_proc_x509_server_crt (cert.c:1148)
==10822==    by 0x4F0E183: _gnutls_proc_crt (cert.c:1369)
==10822==    by 0x4E717D3: _gnutls_recv_server_certificate (gnutls_kx.c:634)
==10822==    by 0x4E6C1DE: _gnutls_handshake_client
(gnutls_handshake.c:2695)
==10822==    by 0x4E6BD21: gnutls_handshake (gnutls_handshake.c:2532)
==10822==    by 0x409952: do_handshake (cli.c:1501)
==10822==    by 0x408B3E: main (cli.c:1119)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20140417/e856420a/attachment.html>

From nmav at gnutls.org  Fri Apr 18 10:46:51 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 18 Apr 2014 10:46:51 +0200
Subject: [gnutls-devel] pull_timeout_func invoked with
 transport_send_ptr instead of transport_recv_ptr
In-Reply-To: <534ECC35.7060808@gmail.com>
References: <534ECC35.7060808@gmail.com>
Message-ID: <CAJU7zaJn_e7C34ys3H5YaiApHBpdhJE6vkxT-jag+MH_dtQ8Og@mail.gmail.com>

On Wed, Apr 16, 2014 at 8:30 PM, JMRecio <josemrecio at gmail.com> wrote:
> Hello, all,
>
> I am using GnuTLS 3.2.13 (background on the project below), I have found a
> behaviour that I think is a bug:
> pull_timeout_func() is invoked with the transport pointer registered for
> push_func(), it is not invoked with the same transport pointer as
> pull_func().

Thanks, it looks indeed as a bug. I've committed a fix.

regards,
Nikos


From aklitzing at gmail.com  Fri Apr 18 13:57:01 2014
From: aklitzing at gmail.com (A. Klitzing)
Date: Fri, 18 Apr 2014 13:57:01 +0200
Subject: [gnutls-devel] memcpy problem with RSA-PSK
In-Reply-To: <CAJaftdiCAD--M9u1Ar6fri-aQJ5CsAQdx=6eiqHdXj-rFreRTw@mail.gmail.com>
References: <CAJaftdiCAD--M9u1Ar6fri-aQJ5CsAQdx=6eiqHdXj-rFreRTw@mail.gmail.com>
Message-ID: <CAJaftdgviNWXD_4SPPegWE4Hse+znko4GCt9_zUcMo_yH3wtmQ@mail.gmail.com>

Hi!

I looked into it a little bit.

In lib/auth/psk.c in line 343 it will call "info =
_gnutls_get_auth_info(session);". It is expected that info is a
psk_auth_info_t with a size of 1096 but it will return a cert_auth_info_t
with a size of 80. So memcpy will write into bad memory!

It seems that _gnutls_auth_info_set in lib/gnutls_auth.c won't reallocate
the buffer to another size. It will be called to create a buffer with 1096
and GNUTLS_CRD_PSK (psk_auth_info_t) as the type but it won't happen and
session->key.auth_info has still a size of 80 and type
GNUTLS_CRD_CERTIFICATE.

I don't know how to fix it as I don't know the internals of GnuTLS. :-) But
I hope it is helpful to fix it.

Best regards
  Andr? Klitzing
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20140418/92279e9c/attachment-0001.html>

From nmav at gnutls.org  Fri Apr 18 16:34:58 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 18 Apr 2014 16:34:58 +0200
Subject: [gnutls-devel] memcpy problem with RSA-PSK
In-Reply-To: <CAJaftdgviNWXD_4SPPegWE4Hse+znko4GCt9_zUcMo_yH3wtmQ@mail.gmail.com>
References: <CAJaftdiCAD--M9u1Ar6fri-aQJ5CsAQdx=6eiqHdXj-rFreRTw@mail.gmail.com>
 <CAJaftdgviNWXD_4SPPegWE4Hse+znko4GCt9_zUcMo_yH3wtmQ@mail.gmail.com>
Message-ID: <CAJU7zaLQUQDSrd8K89VLe3L5VCO4WbsDzz_LhT6cE2wkV32iLA@mail.gmail.com>

On Fri, Apr 18, 2014 at 1:57 PM, A. Klitzing <aklitzing at gmail.com> wrote:
> Hi!
>
> I looked into it a little bit.
>
> In lib/auth/psk.c in line 343 it will call "info =
> _gnutls_get_auth_info(session);". It is expected that info is a
> psk_auth_info_t with a size of 1096 but it will return a cert_auth_info_t
> with a size of 80. So memcpy will write into bad memory!

Indeed valgrind was quite indicative. It seems that RSA-PSK has issues
when the server sends the identity hint. The self check didn't do that
and that's how it wasn't detected so far. I've committed a fix in the
repository.

regards,
Nikos


From ametzler at bebt.de  Fri Apr 18 19:36:18 2014
From: ametzler at bebt.de (Andreas Metzler)
Date: Fri, 18 Apr 2014 19:36:18 +0200
Subject: [gnutls-devel] 3.3.0pre0 - [sparc] Bus error on chainverify test
In-Reply-To: <1397686377.12768.2.camel@nomad.lan>
References: <20140330173753.GB3217@downhill.g.la>
 <1397686377.12768.2.camel@nomad.lan>
Message-ID: <20140418173618.GA2872@downhill.g.la>

On 2014-04-17 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> On Sun, 2014-03-30 at 19:37 +0200, Andreas Metzler wrote:
>> 3.3.0pre0's testsuite produces an error on sparc:
>> -------------
>> (sid_sparc-dchroot)ametzler at smetana:~/GNUTLS/gnutls28-3.3.0~pre0$ ./tests/chainverify
>> Bus error
>> (sid_sparc-dchroot)ametzler at smetana:~/GNUTLS/gnutls28-3.3.0~pre0$

> Thank you. It seems that certs[4] in chainverify was not sufficient for
> the last test that had 5 certificates. Since there were quite some
> variables in the stack they were happily being overwritten and that
> caused quite some mayhem. Thank you for providing access to that system.

Hello,

great, thank you very much.

FWIW I needed this patch on sparc
-----------------
--- gnutls28-3.3.0.orig/tests/dsa/testdsa
+++ gnutls28-3.3.0/tests/dsa/testdsa
@@ -143,7 +143,8 @@ echo "Checking DSA-3072 with TLS 1.2"
 
 launch_server $$  --priority "NORMAL:-VERS-TLS-ALL:+VERS-TLS1.2" --x509certfile $srcdir/cert.dsa.3072.pem --x509keyfile $srcdir/dsa.3072.pem >/dev/null 2>&1 & PID=$!
 wait_server $PID
-
+# startup takes longer here ...
+sleep 2
 $CLI $DEBUG -p $PORT 127.0.0.1 --insecure </dev/null >/dev/null || \
   fail $PID "Failed connection to a server with DSA 3072 key and TLS 1.2!"
-----------------
to let the testsuite succeed on sparc. It seems that the server
startup for DSA-3072 with TLS 1.2 takes longer than 2 seconds for this
test on sparc.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


From nmav at gnutls.org  Fri Apr 18 20:48:45 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 18 Apr 2014 20:48:45 +0200
Subject: [gnutls-devel] 3.3.0pre0 - [sparc] Bus error on chainverify test
In-Reply-To: <20140418173618.GA2872@downhill.g.la>
References: <20140330173753.GB3217@downhill.g.la>
 <1397686377.12768.2.camel@nomad.lan> <20140418173618.GA2872@downhill.g.la>
Message-ID: <1397846925.5135.8.camel@nomad.lan>

On Fri, 2014-04-18 at 19:36 +0200, Andreas Metzler wrote:

>  launch_server $$  --priority "NORMAL:-VERS-TLS-ALL:+VERS-TLS1.2" --x509certfile $srcdir/cert.dsa.3072.pem --x509keyfile $srcdir/dsa.3072.pem >/dev/null 2>&1 & PID=$!
>  wait_server $PID
> -
> +# startup takes longer here ...
> +sleep 2
>  $CLI $DEBUG -p $PORT 127.0.0.1 --insecure </dev/null >/dev/null || \
>    fail $PID "Failed connection to a server with DSA 3072 key and TLS 1.2!"
> -----------------
> to let the testsuite succeed on sparc. It seems that the server
> startup for DSA-3072 with TLS 1.2 takes longer than 2 seconds for this
> test on sparc.

It must be the new code to check the validity of key/cert pair which
does a sign/verify operation on key load. I've increased the wait time
for all scripts in case we are in some borderline.

regards,
Nikos




From cloos at jhcloos.com  Fri Apr 18 21:19:39 2014
From: cloos at jhcloos.com (James Cloos)
Date: Fri, 18 Apr 2014 15:19:39 -0400
Subject: [gnutls-devel] gnutls-cli --dane
Message-ID: <m361m6jvh7.fsf@carbon.jhcloos.org>

The report when using --dane is at best misleading during certificate
rollovers.

During a rollover, when two tlsa records are in play, gnutls-cli gives
results like this:

  ...
  - DANE: Verification failed. The certificate differs. 
  - Description: (TLS1.2)-(ECDHE-RSA-SECP256R1)-(AES-256-GCM)
  ...
  - Simple Client Mode:

That it gets to SCM shows that it was happy with one of the TLSAs, but
it only mentions that it was unhappy with the other TLSA.

When a single TLSA is in play, the report is like:

  ...
- DANE: Certificate matches. 
  - Description: (TLS1.2)-(ECDHE-RSA-SECP256R1)-(AES-128-GCM)
  ...
  - Simple Client Mode:

DANE says that verification succeeds if any of the TLSA records match.
That language was chosen expressly to permit secure rollovers.

Gnutls gets that partly right, in that it allows the socket to
continue.  It also accurately should report the verification facts.

Maybe something akin to this language:

  - DANE: (1 of 2) Certificate(s) match.

The command lines I used for the above excerpts are:
(the first is in the midst of a rollover):

  gnutls-cli --no-ca-verification --dane keys.jhcloos.com
  gnutls-cli --no-ca-verification --dane jhcloos.com

(I'm happy that the worst of it is that the verbiage can be misleading.)

-JimC
--
James Cloos <cloos at jhcloos.com>         OpenPGP: 1024D/ED7DAEA6


From nmav at gnutls.org  Sat Apr 19 13:15:59 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 19 Apr 2014 13:15:59 +0200
Subject: [gnutls-devel] gnutls 3.3.1
Message-ID: <1397906159.15205.1.camel@nomad.lan>

Hello,
 I've just released gnutls 3.3.1. This is a bugfix release on the next stable branch.


* Version 3.3.1 (released 2014-04-19)

** libgnutls: Enforce more strict checks to heartbeat messages
concerning padding and payload. Suggested by Peter Dettman.

** libgnutls: Allow decoding PKCS #8 files with ECC parameters
from openssl.

** libgnutls: Several small bug fixes found by coverity.

** libgnutls: The conditionally available self-test functions
were moved to self-test.h.

** libgnutls: Fixed issue with the check of incoming data when two
different recv and send pointers have been specified. Reported and
investigated by JMRecio.

** libgnutls: Fixed issue in the RSA-PSK key exchange, which would 
result to illegal memory access if a server hint was provided. Reported
by Andr? Klitzing.

** libgnutls: Fixed client memory leak in the PSK key exchange, if a
server hint was provided.

** libgnutls: Corrected the *get_*_othername_oid() functions.

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


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

GnuTLS may be downloaded directly from
<ftp://ftp.gnutls.org/gcrypt/gnutls/>.  A list of GnuTLS mirrors can be
found at <http://www.gnutls.org/download.html>.

Here are the XZ and LZIP compressed sources:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.1.tar.xz
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.1.tar.lz

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.1.tar.xz.sig
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.1.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 ametzler at bebt.de  Sat Apr 19 14:23:03 2014
From: ametzler at bebt.de (Andreas Metzler)
Date: Sat, 19 Apr 2014 14:23:03 +0200
Subject: [gnutls-devel] gnutls 3.3.1
In-Reply-To: <1397906159.15205.1.camel@nomad.lan>
References: <1397906159.15205.1.camel@nomad.lan>
Message-ID: <20140419122303.GA8540@downhill.g.la>

On 2014-04-19 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> Hello,
>  I've just released gnutls 3.3.1. This is a bugfix release on the
>  next stable branch.
[...]

Hello,

removal of gnutls_secure_malloc from gnutls.h broke guile support:
-----------------------
In file included from core.c:519:0:
priorities.i.c: In function 'scm_gnutls_set_session_cipher_priority_x':
priorities.i.c:11:3: warning: implicit declaration of function 'scm_c_issue_deprecation_warning' [-Wimplicit-function-declaration]
   scm_c_issue_deprecation_warning ("`set-session-cipher-priority!' is deprecated, use `set-session-priorities!' instead");
   ^
core.c: In function 'scm_init_gnutls':
core.c:3369:3: error: 'gnutls_secure_malloc' undeclared (first use in this function)
   gnutls_secure_malloc = scm_malloc;
   ^
core.c:3369:3: note: each undeclared identifier is reported only once for each function it appears in
make[6]: *** [guile_gnutls_v_2_la-core.lo] Error 1
-----------------------

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


From nmav at gnutls.org  Sat Apr 19 15:08:36 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 19 Apr 2014 15:08:36 +0200
Subject: [gnutls-devel] gnutls 3.3.1
In-Reply-To: <20140419122303.GA8540@downhill.g.la>
References: <1397906159.15205.1.camel@nomad.lan>
 <20140419122303.GA8540@downhill.g.la>
Message-ID: <1397912916.24376.2.camel@nomad.lan>

On Sat, 2014-04-19 at 14:23 +0200, Andreas Metzler wrote:
> On 2014-04-19 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> > Hello,
> >  I've just released gnutls 3.3.1. This is a bugfix release on the
> >  next stable branch.
> [...]
> 
> Hello,
> removal of gnutls_secure_malloc from gnutls.h broke guile support:
> -----------------------
> In file included from core.c:519:0:
> priorities.i.c: In function 'scm_gnutls_set_session_cipher_priority_x':
> priorities.i.c:11:3: warning: implicit declaration of function 'scm_c_issue_deprecation_warning' [-Wimplicit-function-declaration]
>    scm_c_issue_deprecation_warning ("`set-session-cipher-priority!' is deprecated, use `set-session-priorities!' instead");
>    ^
> core.c: In function 'scm_init_gnutls':
> core.c:3369:3: error: 'gnutls_secure_malloc' undeclared (first use in this function)
>    gnutls_secure_malloc = scm_malloc;
>    ^

Thanks, I've removed these overrides completely. The way to override
these functions was using gnutls_global_set_mem_functions(), and in
3.3.x it is no longer possible to override them. In fact it  may lead to
a crash on deinitialization if done the way the guile module did.

regards,
Nikos




From ametzler at bebt.de  Sat Apr 19 16:44:13 2014
From: ametzler at bebt.de (Andreas Metzler)
Date: Sat, 19 Apr 2014 16:44:13 +0200
Subject: [gnutls-devel] gnutls 3.3.1
In-Reply-To: <1397906159.15205.1.camel@nomad.lan>
References: <1397906159.15205.1.camel@nomad.lan>
Message-ID: <20140419144413.GB8540@downhill.g.la>

On 2014-04-19 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
>  I've just released gnutls 3.3.1. This is a bugfix release on the
>  next stable branch.


> * Version 3.3.1 (released 2014-04-19)

Hello,

the latter of the newly added parts of the pem-decoding test does not
succeed for me:
-----------------
(SID)ametzler at argenau:/tmp/GNUTLS/gnutls-3.3.1/tests/cert-tests$ ./pem-decoding 
68a69
> warning: altname contains an embedded NUL, replacing with '!'
72a74
> warning: altname contains an embedded NUL, replacing with '!'
74a77
> warning: altname contains an embedded NUL, replacing with '!'
76a80
> warning: altname contains an embedded NUL, replacing with '!'
80a85
> warning: altname contains an embedded NUL, replacing with '!'
82a88
> warning: altname contains an embedded NUL, replacing with '!'
68a69
> warning: altname contains an embedded NUL, replacing with '!'
72a74
> warning: altname contains an embedded NUL, replacing with '!'
74a77
> warning: altname contains an embedded NUL, replacing with '!'
76a80
> warning: altname contains an embedded NUL, replacing with '!'
80a85
> warning: altname contains an embedded NUL, replacing with '!'
82a88
> warning: altname contains an embedded NUL, replacing with '!'
XMPP cert decoding failed 2
-----------------

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


From nmav at gnutls.org  Sat Apr 19 18:49:23 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 19 Apr 2014 18:49:23 +0200
Subject: [gnutls-devel] gnutls 3.3.1
In-Reply-To: <20140419144413.GB8540@downhill.g.la>
References: <1397906159.15205.1.camel@nomad.lan>
 <20140419144413.GB8540@downhill.g.la>
Message-ID: <1397926163.25399.2.camel@nomad.lan>

On Sat, 2014-04-19 at 16:44 +0200, Andreas Metzler wrote:
> On 2014-04-19 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> >  I've just released gnutls 3.3.1. This is a bugfix release on the
> >  next stable branch.
> 
> 
> > * Version 3.3.1 (released 2014-04-19)
> 
> Hello,
> 
> the latter of the newly added parts of the pem-decoding test does not
> succeed for me:
> -----------------
> (SID)ametzler at argenau:/tmp/GNUTLS/gnutls-3.3.1/tests/cert-tests$ ./pem-decoding 
> 68a69

Thanks. Too bad it wasn't detected on my run. I've modified some of the
tests in the suite to run under valgrind as well. Even better all of the
scripts should run under valgrind...

regards,
Nikos




From ametzler at bebt.de  Sat Apr 19 20:11:39 2014
From: ametzler at bebt.de (Andreas Metzler)
Date: Sat, 19 Apr 2014 20:11:39 +0200
Subject: [gnutls-devel] Typo fix
Message-ID: <20140419181139.GB2837@downhill.g.la>

Hello,

find attached a trivial patch against GIT head,
s/overriden/overridden/

hth, cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Typo-fix-overriden-overridden.patch
Type: text/x-diff
Size: 2211 bytes
Desc: not available
URL: </pipermail/attachments/20140419/32a5bea9/attachment.patch>

From ametzler at bebt.de  Sat Apr 19 20:13:26 2014
From: ametzler at bebt.de (Andreas Metzler)
Date: Sat, 19 Apr 2014 20:13:26 +0200
Subject: [gnutls-devel] gnutls 3.3.1
In-Reply-To: <1397926163.25399.2.camel@nomad.lan>
References: <1397906159.15205.1.camel@nomad.lan>
 <20140419144413.GB8540@downhill.g.la>
 <1397926163.25399.2.camel@nomad.lan>
Message-ID: <20140419181326.GC2837@downhill.g.la>

On 2014-04-19 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
[...]
> Thanks. Too bad it wasn't detected on my run. I've modified some of the
> tests in the suite to run under valgrind as well. Even better all of the
> scripts should run under valgrind...


Thank you very much, the testsuite now completes successfully.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


From kurt at roeckx.be  Sat Apr 19 20:13:58 2014
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sat, 19 Apr 2014 20:13:58 +0200
Subject: [gnutls-devel] [PATCH 3/3] _asn1_ordering_set_of(): Fix memory
 leak in case of error.
In-Reply-To: <1397929579-13059-3-git-send-email-kurt@roeckx.be>
References: <1397929579-13059-1-git-send-email-kurt@roeckx.be>
 <1397929579-13059-3-git-send-email-kurt@roeckx.be>
Message-ID: <20140419181358.GA26395@roeckx.be>

I need to look at this again, more examples cases of it in the
same file different function.  And I might have misunderstood the
intention of the function, so I'm looking at this again.


Kurt

On Sat, Apr 19, 2014 at 07:46:19PM +0200, Kurt Roeckx wrote:
> ---
>  lib/minitasn1/coding.c | 17 +++++++++++++----
>  1 file changed, 13 insertions(+), 4 deletions(-)
> 
> diff --git a/lib/minitasn1/coding.c b/lib/minitasn1/coding.c
> index ef2f96f..5e9864d 100644
> --- a/lib/minitasn1/coding.c
> +++ b/lib/minitasn1/coding.c
> @@ -842,7 +842,7 @@ _asn1_ordering_set_of (unsigned char *der, int der_len, asn1_node node)
>      {
>        p_vet = malloc (sizeof (struct vet));
>        if (p_vet == NULL)
> -	return;
> +	goto error;
>  
>        p_vet->next = NULL;
>        p_vet->prev = last;
> @@ -859,12 +859,12 @@ _asn1_ordering_set_of (unsigned char *der, int der_len, asn1_node node)
>  	  if (asn1_get_tag_der
>  	      (der + counter, der_len - counter, &class, &len,
>  	       NULL) != ASN1_SUCCESS)
> -	    return;
> +	    goto error;
>  	  counter += len;
>  
>  	  len2 = asn1_get_length_der (der + counter, der_len - counter, &len);
>  	  if (len2 < 0)
> -	    return;
> +	    goto error;
>  	  counter += len + len2;
>  	}
>  
> @@ -907,7 +907,7 @@ _asn1_ordering_set_of (unsigned char *der, int der_len, asn1_node node)
>  	      /* change position */
>  	      temp = malloc (p_vet->end - counter);
>  	      if (temp == NULL)
> -		return;
> +		goto error;
>  
>  	      memcpy (temp, der + counter, (p_vet->end) - counter);
>  	      memcpy (der + counter, der + (p_vet->end),
> @@ -931,6 +931,15 @@ _asn1_ordering_set_of (unsigned char *der, int der_len, asn1_node node)
>        free (p_vet);
>        p_vet = first;
>      }
> +    return;
> +
> +error:
> +  while (first != NULL)
> +    {
> +      p_vet = first;
> +      first = first->next;
> +      free(p_vet);
> +    }
>  }
>  
>  /**
> -- 
> 1.9.1
> 


From kurt at roeckx.be  Sat Apr 19 19:46:17 2014
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sat, 19 Apr 2014 19:46:17 +0200
Subject: [gnutls-devel] [PATCH 1/3] Add _gnutls_fips_mode_enabled() return
	values.
Message-ID: <1397929579-13059-1-git-send-email-kurt@roeckx.be>

---
 lib/fips.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/lib/fips.c b/lib/fips.c
index 1812610..8cd4b94 100644
--- a/lib/fips.c
+++ b/lib/fips.c
@@ -36,6 +36,11 @@ unsigned int _gnutls_lib_mode = LIB_STATE_POWERON;
 #define FIPS_KERNEL_FILE "/proc/sys/crypto/fips_enabled"
 #define FIPS_SYSTEM_FILE "/etc/system-fips"
 
+/* Returns:
+ * 0 - FIPS mode disabled
+ * 1 - FIPS mode enabled and enforced
+ * 2 - FIPS in testing mode
+ */
 unsigned _gnutls_fips_mode_enabled(void)
 {
 unsigned f1p = 0, f2p;
-- 
1.9.1



From kurt at roeckx.be  Sat Apr 19 19:46:19 2014
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sat, 19 Apr 2014 19:46:19 +0200
Subject: [gnutls-devel] [PATCH 3/3] _asn1_ordering_set_of(): Fix memory leak
	in case of error.
In-Reply-To: <1397929579-13059-1-git-send-email-kurt@roeckx.be>
References: <1397929579-13059-1-git-send-email-kurt@roeckx.be>
Message-ID: <1397929579-13059-3-git-send-email-kurt@roeckx.be>

---
 lib/minitasn1/coding.c | 17 +++++++++++++----
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/lib/minitasn1/coding.c b/lib/minitasn1/coding.c
index ef2f96f..5e9864d 100644
--- a/lib/minitasn1/coding.c
+++ b/lib/minitasn1/coding.c
@@ -842,7 +842,7 @@ _asn1_ordering_set_of (unsigned char *der, int der_len, asn1_node node)
     {
       p_vet = malloc (sizeof (struct vet));
       if (p_vet == NULL)
-	return;
+	goto error;
 
       p_vet->next = NULL;
       p_vet->prev = last;
@@ -859,12 +859,12 @@ _asn1_ordering_set_of (unsigned char *der, int der_len, asn1_node node)
 	  if (asn1_get_tag_der
 	      (der + counter, der_len - counter, &class, &len,
 	       NULL) != ASN1_SUCCESS)
-	    return;
+	    goto error;
 	  counter += len;
 
 	  len2 = asn1_get_length_der (der + counter, der_len - counter, &len);
 	  if (len2 < 0)
-	    return;
+	    goto error;
 	  counter += len + len2;
 	}
 
@@ -907,7 +907,7 @@ _asn1_ordering_set_of (unsigned char *der, int der_len, asn1_node node)
 	      /* change position */
 	      temp = malloc (p_vet->end - counter);
 	      if (temp == NULL)
-		return;
+		goto error;
 
 	      memcpy (temp, der + counter, (p_vet->end) - counter);
 	      memcpy (der + counter, der + (p_vet->end),
@@ -931,6 +931,15 @@ _asn1_ordering_set_of (unsigned char *der, int der_len, asn1_node node)
       free (p_vet);
       p_vet = first;
     }
+    return;
+
+error:
+  while (first != NULL)
+    {
+      p_vet = first;
+      first = first->next;
+      free(p_vet);
+    }
 }
 
 /**
-- 
1.9.1



From kurt at roeckx.be  Sat Apr 19 19:46:18 2014
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sat, 19 Apr 2014 19:46:18 +0200
Subject: [gnutls-devel] [PATCH 2/3] Test for the existance of the
	/etc/system-fips file
In-Reply-To: <1397929579-13059-1-git-send-email-kurt@roeckx.be>
References: <1397929579-13059-1-git-send-email-kurt@roeckx.be>
Message-ID: <1397929579-13059-2-git-send-email-kurt@roeckx.be>

We don't read it, the existance of the file is enough to say in what
mode we are.
---
 lib/fips.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/fips.c b/lib/fips.c
index 8cd4b94..71f7492 100644
--- a/lib/fips.c
+++ b/lib/fips.c
@@ -59,7 +59,7 @@ static int fips_mode = -1;
 		else f1p = 0;
 	}
 
-	f2p = !access(FIPS_SYSTEM_FILE, R_OK);
+	f2p = !access(FIPS_SYSTEM_FILE, F_OK);
 
 	if (f1p != 0 && f2p != 0) {
 		_gnutls_debug_log("FIPS140-2 mode enabled\n");
-- 
1.9.1



From kurt at roeckx.be  Sun Apr 20 16:58:44 2014
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sun, 20 Apr 2014 16:58:44 +0200
Subject: [gnutls-devel] [PATCH 3/3] _asn1_ordering_set_of(): Fix memory
 leak in case of error.
In-Reply-To: <20140419181358.GA26395@roeckx.be>
References: <1397929579-13059-1-git-send-email-kurt@roeckx.be>
 <1397929579-13059-3-git-send-email-kurt@roeckx.be>
 <20140419181358.GA26395@roeckx.be>
Message-ID: <20140420145844.GA27484@roeckx.be>

On Sat, Apr 19, 2014 at 08:13:58PM +0200, Kurt Roeckx wrote:
> I need to look at this again, more examples cases of it in the
> same file different function.  And I might have misunderstood the
> intention of the function, so I'm looking at this again.

So I ended up submitting a reworked version of this patch and a
few others to libtasn1.


Kurt



From home_pw at msn.com  Sun Apr 20 19:13:46 2014
From: home_pw at msn.com (Peter Williams)
Date: Sun, 20 Apr 2014 17:13:46 +0000
Subject: [gnutls-devel]
 =?utf-8?q?=5BPATCH_3/3=5D_=5Fasn1=5Fordering=5Fset?=
 =?utf-8?q?=5Fof=28=29=3A_Fix_memory_leak_in_case_of_error=2E?=
Message-ID: <SNT404-EAS199748124996DAE423950AF925F0@phx.gbl>

off topic.


Remember, ASN.1 is abstract and begets several concrete encodings. In particular, BER was INTENDED to allow (security) processors doing relaying to reorder set elements on the wire (or drop tagged elements they just could not process). IN the associated doctrine for ASN.1 - heavily used in 1990s era military messaging system security concepts, one should not assume that the inbound wire has the originator?s instance of BER coding or all the originally-tagged data elements.  Recoding into the canonical form (of those elements actually received) is of course the classical DER requirement - used when performing a security services on the inbound PDU.


As I recall, canonical encoding set of requires forming a binary representation of the collection of child TLVs, and doing a binary compare to order the set.


If the code to do all this is within the security module (within the FIPS 140 crypto module boundary that is) one gets to time all this activity, since one can inject different orderings under these BER rules and induce difference amount of work - and associated energy/power usage.


Sneaky, no!

 

One might leak the raw signal in one module, and then, ahem, induce another - via garbage collection etc - to modulate that signal on a suitable bearer easily available to the party penetrating the commodity crypto module.






From: Kurt Roeckx
Sent: ?Sunday?, ?April? ?20?, ?2014 ?7?:?59? ?AM
To: gnutls-devel at lists.gnutls.org





On Sat, Apr 19, 2014 at 08:13:58PM +0200, Kurt Roeckx wrote:
> I need to look at this again, more examples cases of it in the
> same file different function.  And I might have misunderstood the
> intention of the function, so I'm looking at this again.

So I ended up submitting a reworked version of this patch and a
few others to libtasn1.


Kurt


_______________________________________________
Gnutls-devel mailing list
Gnutls-devel at lists.gnutls.org
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20140420/64b915ab/attachment.html>

From home_pw at msn.com  Mon Apr 21 18:56:22 2014
From: home_pw at msn.com (Peter Williams)
Date: Mon, 21 Apr 2014 16:56:22 +0000
Subject: [gnutls-devel]
 =?utf-8?q?=5BPATCH_3/3=5D_=5Fasn1=5Fordering=5Fset?=
 =?utf-8?q?=5Fof=28=29=3A_Fix_memory_leak_in_case_of_error=2E?=
Message-ID: <SNT404-EAS293662FF116EBA29FFC3D2A925E0@phx.gbl>

is no longer a secret that set of (sequence of) was used, even as far back as the v1 certs era, to do things that the spec ?enabled? but did not specify. This is the usual example of an ISO spec in the security track having different meanings (as intended by those with classified knowledge). IN the profile, such features are used - e.g. MISSI profiles of X.509 and X.5.11.


One MIGHT know that a signed object is typically a signing action over a SETOF/SEQOF explicitely-tagged elements. But, one might ALSO know that such a typed value MIGHT be encoded on the wire with extra tagged elements not standarized by the spec. (X.509 v1 allowed this, and conforming implementations MUST not object). Thus on the wire, a sender OR RELAY can omit a mandatory tag from the concrete encoding of a given value, and ADD a custom tag (with an pairwise-encrypted copy of the missing standard tag, say). To verify the signature one has to process the custom tag to decrypt the value, that then completes the PDV and would allow the signature to verify.



One of those lovely examples in which the public line of the authentication framework was: that ISO had not enabled open systems encryption (allowing for certain national politics to claim success). But, at the same time, in double-speak, to do the exact opposite of what the public claims were. Its also an example of a once-classified that was all abou policy (and negotiation stances) vs some super-secret technology.






From: peter Msn
Sent: ?Sunday?, ?April? ?20?, ?2014 ?10?:?25? ?AM
To: gnutls-devel at lists.gnutls.org





off topic.




Remember, ASN.1 is abstract and begets several concrete encodings. In particular, BER was INTENDED to allow (security) processors doing relaying to reorder set elements on the wire (or drop tagged elements they just could not process). IN the associated doctrine for ASN.1 - heavily used in 1990s era military messaging system security concepts, one should not assume that the inbound wire has the originator?s instance of BER coding or all the originally-tagged data elements.  Recoding into the canonical form (of those elements actually received) is of course the classical DER requirement - used when performing a security services on the inbound PDU.




As I recall, canonical encoding set of requires forming a binary representation of the collection of child TLVs, and doing a binary compare to order the set.




If the code to do all this is within the security module (within the FIPS 140 crypto module boundary that is) one gets to time all this activity, since one can inject different orderings under these BER rules and induce difference amount of work - and associated energy/power usage.




Sneaky, no!

 

One might leak the raw signal in one module, and then, ahem, induce another - via garbage collection etc - to modulate that signal on a suitable bearer easily available to the party penetrating the commodity crypto module.






From: Kurt Roeckx
Sent: ?Sunday?, ?April? ?20?, ?2014 ?7?:?59? ?AM
To: gnutls-devel at lists.gnutls.org





On Sat, Apr 19, 2014 at 08:13:58PM +0200, Kurt Roeckx wrote:
> I need to look at this again, more examples cases of it in the
> same file different function.  And I might have misunderstood the
> intention of the function, so I'm looking at this again.

So I ended up submitting a reworked version of this patch and a
few others to libtasn1.


Kurt


_______________________________________________
Gnutls-devel mailing list
Gnutls-devel at lists.gnutls.org
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20140421/e743d0ef/attachment-0001.html>
-------------- next part --------------
_______________________________________________
Gnutls-devel mailing list
Gnutls-devel at lists.gnutls.org
http://lists.gnupg.org/mailman/listinfo/gnutls-devel

From nikita at karetnikov.org  Wed Apr 23 01:13:32 2014
From: nikita at karetnikov.org (Nikita Karetnikov)
Date: Wed, 23 Apr 2014 03:13:32 +0400
Subject: [gnutls-devel] GnuTLS 3.3.1: core.c:3369:3: error:
	'gnutls_secure_malloc' undeclared
Message-ID: <87k3aht0tf.fsf@karetnikov.org>

?gnutls-remove-gnutls_secure_malloc.patch? fixes the following issue:

make[4]: Entering directory '/tmp/nix-build-gnutls-3.3.1.drv-0/gnutls-3.3.1/guile/src'
  CC       guile_gnutls_v_2_la-core.lo
core.c: In function 'scm_init_gnutls':
core.c:3369:3: error: 'gnutls_secure_malloc' undeclared (first use in this function)
   gnutls_secure_malloc = scm_malloc;
   ^
core.c:3369:3: note: each undeclared identifier is reported only once for each function it appears in
Makefile:1448: recipe for target 'guile_gnutls_v_2_la-core.lo' failed
make[4]: *** [guile_gnutls_v_2_la-core.lo] Error 1
make[4]: Leaving directory '/tmp/nix-build-gnutls-3.3.1.drv-0/gnutls-3.3.1/guile/src'
Makefile:1340: recipe for target 'all' failed
make[3]: *** [all] Error 2
make[3]: Leaving directory '/tmp/nix-build-gnutls-3.3.1.drv-0/gnutls-3.3.1/guile/src'
Makefile:1301: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory '/tmp/nix-build-gnutls-3.3.1.drv-0/gnutls-3.3.1/guile'
Makefile:1373: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/tmp/nix-build-gnutls-3.3.1.drv-0/gnutls-3.3.1'
Makefile:1300: recipe for target 'all' failed
make: *** [all] Error 2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: gnutls-remove-gnutls_secure_malloc.patch
Type: text/x-diff
Size: 571 bytes
Desc: not available
URL: </pipermail/attachments/20140423/8fb48bed/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: </pipermail/attachments/20140423/8fb48bed/attachment.sig>

From wiredrat at gmail.com  Mon Apr 21 16:34:35 2014
From: wiredrat at gmail.com (=?UTF-8?Q?Marcos_Ag=C3=BCero?=)
Date: Mon, 21 Apr 2014 16:34:35 +0200
Subject: [gnutls-devel] segfault on gnutls_x509_crt_import
Message-ID: <CABD9f3NKWUn+cntkinP2Qgm6zmnJ4U==GujpSKhvdXZxCaBQzQ@mail.gmail.com>

Hi,

While using libcurl with gnutls, on certain URL
hxxps://harrowmedia.com/(WARNING! URL is known to host malware), i'm
getting unexpected
segmentation fault. I'm not sure if it's related to libcurl version or
gnutls, but I suspect that is a malformed certificate.

I'm using gnutls version 2.12.23-12ubuntu2 (latest ubuntu package)

Sample program (attached) backtrace:
(gdb) run
Starting program: /home/wiredrat/src/curl_poc/curl_gnutls
https://harrowmedia.com/
[Depuraci?n de hilo usando libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Nuevo Thread 0x7ffff2c2b700 (LWP 25858)]
[Thread 0x7ffff2c2b700 (LWP 25858) terminado]

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff6e9db19 in gnutls_x509_crt_import () from
/usr/lib/x86_64-linux-gnu/libgnutls.so.26
(gdb) bt
#0  0x00007ffff6e9db19 in gnutls_x509_crt_import () from
/usr/lib/x86_64-linux-gnu/libgnutls.so.26
#1  0x00007ffff7bc1ec9 in gtls_connect_step3 (conn=conn at entry=0x65aa50,
sockindex=sockindex at entry=0) at vtls/gtls.c:708
#2  0x00007ffff7bc2a7a in gtls_connect_common (conn=conn at entry=0x65aa50,
sockindex=sockindex at entry=0, nonblocking=nonblocking at entry=true,
    done=done at entry=0x7fffffffdde5) at vtls/gtls.c:918
#3  0x00007ffff7bc2e0d in Curl_gtls_connect_nonblocking
(conn=conn at entry=0x65aa50,
sockindex=sockindex at entry=0,
    done=done at entry=0x7fffffffdde5) at vtls/gtls.c:933
#4  0x00007ffff7bc3540 in Curl_ssl_connect_nonblocking
(conn=conn at entry=0x65aa50,
sockindex=sockindex at entry=0, done=0x7fffffffdde5)
    at vtls/vtls.c:293
#5  0x00007ffff7b86ffe in https_connecting (conn=0x65aa50, done=<optimized
out>) at http.c:1354
#6  0x00007ffff7ba9571 in multi_runsingle (multi=multi at entry=0x6514f0,
now=..., data=data at entry=0x648750) at multi.c:1195
#7  0x00007ffff7baa1c1 in curl_multi_perform
(multi_handle=multi_handle at entry=0x6514f0,
    running_handles=running_handles at entry=0x7fffffffdea4) at multi.c:1752
#8  0x00007ffff7ba1923 in easy_transfer (multi=0x6514f0) at easy.c:705
#9  easy_perform (events=false, data=0x648750) at easy.c:784
#10 curl_easy_perform (easy=0x648750) at easy.c:803
#11 0x0000000000400b06 in main ()
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20140421/e77f940f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: curl_poc.c
Type: text/x-csrc
Size: 1238 bytes
Desc: not available
URL: </pipermail/attachments/20140421/e77f940f/attachment.c>

From nikita at karetnikov.org  Thu Apr 24 21:19:44 2014
From: nikita at karetnikov.org (Nikita Karetnikov)
Date: Thu, 24 Apr 2014 23:19:44 +0400
Subject: [gnutls-devel] GnuTLS 3.3.1: cert-tests: FAIL: pem-decoding
Message-ID: <87oazqo7qn.fsf@karetnikov.org>

The build fails with the following error if I apply the (unrelated)
patch from this thread [1].

make[4]: Entering directory '/tmp/nix-build-gnutls-3.3.1.drv-0/gnutls-3.3.1/tests/cert-tests'
PASS: pathlen
PASS: aki
FAIL: pem-decoding
SKIP: template-test
make[5]: Entering directory '/tmp/nix-build-gnutls-3.3.1.drv-0/gnutls-3.3.1/tests/cert-tests'
make[5]: Nothing to be done for 'all'.
make[5]: Leaving directory '/tmp/nix-build-gnutls-3.3.1.drv-0/gnutls-3.3.1/tests/cert-tests'
============================================================================
Testsuite summary for GnuTLS 3.3.1
============================================================================
# TOTAL: 4
# PASS:  2
# SKIP:  1
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0
============================================================================
See tests/cert-tests/test-suite.log
Please report to bugs at gnutls.org
============================================================================
Makefile:1478: recipe for target 'test-suite.log' failed
make[4]: *** [test-suite.log] Error 1
make[4]: Leaving directory '/tmp/nix-build-gnutls-3.3.1.drv-0/gnutls-3.3.1/tests/cert-tests'
Makefile:1584: recipe for target 'check-TESTS' failed
make[3]: *** [check-TESTS] Error 2
make[3]: Leaving directory '/tmp/nix-build-gnutls-3.3.1.drv-0/gnutls-3.3.1/tests/cert-tests'
Makefile:1685: recipe for target 'check-am' failed
make[2]: *** [check-am] Error 2
make[2]: Leaving directory '/tmp/nix-build-gnutls-3.3.1.drv-0/gnutls-3.3.1/tests/cert-tests'
Makefile:2657: recipe for target 'check-recursive' failed
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory '/tmp/nix-build-gnutls-3.3.1.drv-0/gnutls-3.3.1/tests'
Makefile:1373: recipe for target 'check-recursive' failed
make: *** [check-recursive] Error 1

?tests/cert-tests/test-suite.log?:

FAIL: pem-decoding
==================

68a69
> warning: altname contains an embedded NUL, replacing with '!'
74a76
> warning: altname contains an embedded NUL, replacing with '!'
76a79
> warning: altname contains an embedded NUL, replacing with '!'
80a84
> warning: altname contains an embedded NUL, replacing with '!'
82a87
> warning: altname contains an embedded NUL, replacing with '!'
68a69
> warning: altname contains an embedded NUL, replacing with '!'
74a76
> warning: altname contains an embedded NUL, replacing with '!'
76a79
> warning: altname contains an embedded NUL, replacing with '!'
80a84
> warning: altname contains an embedded NUL, replacing with '!'
82a87
> warning: altname contains an embedded NUL, replacing with '!'
XMPP cert decoding failed 2

[1] http://lists.gnutls.org/pipermail/gnutls-devel/2014-April/006909.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: </pipermail/attachments/20140424/86e29611/attachment.sig>

From danw at gnome.org  Thu Apr 24 22:01:45 2014
From: danw at gnome.org (Dan Winship)
Date: Thu, 24 Apr 2014 16:01:45 -0400
Subject: [gnutls-devel] no way to detect gnutls_global_init() failure in 3.3
Message-ID: <53596DA9.6080801@gnome.org>

If gnutls_global_init() has been called before, it always returns 0,
even if it failed the first time. Since it now gets called from a
constructor, this means it will always return 0 when called from
application code, even if it failed when called from the constructor.

Probably it should save the original return value for future calls?

(qv https://bugzilla.redhat.com/show_bug.cgi?id=1091053)

-- Dan


From luto at amacapital.net  Fri Apr 25 00:58:21 2014
From: luto at amacapital.net (Andy Lutomirski)
Date: Thu, 24 Apr 2014 15:58:21 -0700
Subject: [gnutls-devel] Please stop automatically initializing p11-kit
In-Reply-To: <CALCETrX5G2emhz9reMrfQiqAa9LA1Z2TK3aFij2hC4oeYvFSMg@mail.gmail.com>
References: <CALCETrX5G2emhz9reMrfQiqAa9LA1Z2TK3aFij2hC4oeYvFSMg@mail.gmail.com>
Message-ID: <CALCETrW7v36hzkK0urBPKA4qqusZ-mG9-w92jyVdybnxcC_a_A@mail.gmail.com>

On Thu, Apr 24, 2014 at 3:37 PM, Andy Lutomirski <luto at amacapital.net> wrote:
> I realize that this is arguably a bug in p11-kit.  But it's a problem
> with gnutls, too.  Please just stop all the automatic PKCS11 madness.

My apologies -- this is already fixed.  I'll file a bug against Fedora
asking them to update GnuTLS.

--Andy


From luto at amacapital.net  Fri Apr 25 00:37:40 2014
From: luto at amacapital.net (Andy Lutomirski)
Date: Thu, 24 Apr 2014 15:37:40 -0700
Subject: [gnutls-devel] Please stop automatically initializing p11-kit
Message-ID: <CALCETrX5G2emhz9reMrfQiqAa9LA1Z2TK3aFij2hC4oeYvFSMg@mail.gmail.com>

I just found this call trace when my program starts:

#0  0x0000003a76a2a4c0 in pthread_atfork () from /lib64/libp11-kit.so.0
#1  0x0000003a76a19a32 in init_globals_unlocked () from /lib64/libp11-kit.so.0
#2  0x0000003a76a1bb2a in p11_kit_initialize_registered () from
/lib64/libp11-kit.so.0
#3  0x0000003d59459b68 in gnutls_pkcs11_init () from /lib64/libgnutls.so.28
#4  0x0000003d5943f5d3 in gnutls_global_init () from /lib64/libgnutls.so.28
#5  0x00007ffff5b57b39 in _GLOBAL__sub_I_net_tls_TLSSession.cpp ()
from /lib64/libvmime.so.0
#6  0x0000003a5ca0f2ea in call_init.part.0 () from /lib64/ld-linux-x86-64.so.2
#7  0x0000003a5ca0f3d3 in _dl_init_internal () from /lib64/ld-linux-x86-64.so.2
#8  0x0000003a5ca0122a in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#9  0x0000000000000001 in ?? ()
#10 0x00007fffffffe2d5 in ?? ()
#11 0x0000000000000000 in ?? ()

I'm not doing any crypto whatsoever.  This program *does not use* TLS
under any circumstances whatsoever.  It links against a library that
optionally speaks TLS, and that library links against gnutls, and
gnutls is automagically initializing PKCS11 at startup.  This happens
because:

 - A constructor calls gnutls_global_init.  This is fine, as long as
gnutls_global_init has no harmful side effects.

 - gnutls_global_init calls gnutls_pkcs11_init, which I think is a
disaster.  PKCS11 sucks, full stop.  The API is fundamentally broken.

But now I'm screwed, because p11-kit's atfork handler is buggy and is
sitting here deadlocked.  In a test case.  THAT HAS NOTHING TO DO WITH
CRYPTOGRAPHY.

I understand that gnutls needs to support PKCS11.  Fine.  But please
don't initialize the damn thing until someone actually tries to use
it.

I realize that this is arguably a bug in p11-kit.  But it's a problem
with gnutls, too.  Please just stop all the automatic PKCS11 madness.

--Andy


From dcb314 at hotmail.com  Thu Apr 24 22:23:15 2014
From: dcb314 at hotmail.com (David Binderman)
Date: Thu, 24 Apr 2014 20:23:15 +0000
Subject: [gnutls-devel] safe_renegotiation.c: 2 * possible cut'n'paste error
Message-ID: <DUB130-W36684D863C29C9158684C69C5B0@phx.gbl>

Hello there,

1.

[safe_renegotiation.c:204]: (style) Expression is always false because 'else if' condition matches previous condition at line 202.

??? if (ret < 0) {
??????? set = 1;
??? } else if (ret < 0) {
??????? gnutls_assert();
??????? return ret;
??? }

2.

[safe_renegotiation.c:241]: (style) Expression is always false because 'else if' condition matches previous condition at line 239.

Duplicate.

Regards

David Binderman

 		 	   		  

From ametzler at bebt.de  Fri Apr 25 19:42:16 2014
From: ametzler at bebt.de (Andreas Metzler)
Date: Fri, 25 Apr 2014 19:42:16 +0200
Subject: [gnutls-devel] GnuTLS 3.3.1: cert-tests: FAIL: pem-decoding
In-Reply-To: <87oazqo7qn.fsf@karetnikov.org>
References: <87oazqo7qn.fsf@karetnikov.org>
Message-ID: <20140425174216.GA2937@downhill.g.la>

On 2014-04-24 Nikita Karetnikov <nikita at karetnikov.org> wrote:
> The build fails with the following error if I apply the (unrelated)
> patch from this thread [1].

> make[4]: Entering directory '/tmp/nix-build-gnutls-3.3.1.drv-0/gnutls-3.3.1/tests/cert-tests'
> PASS: pathlen
> PASS: aki
> FAIL: pem-decoding
[...]
> FAIL: pem-decoding
> ==================

> 68a69
> > warning: altname contains an embedded NUL, replacing with '!'
[...]

Hello,

Fixed by 9b8271f0015526f017aa70b8d1f3a8fa1f8d3a62 in upstream git, see
http://lists.gnutls.org/pipermail/gnutls-devel/2014-April/006898.html

> [1] http://lists.gnutls.org/pipermail/gnutls-devel/2014-April/006909.html

This one is also already fixed in upstream git by
872409857351f28b1e3c21526bfa6606c918b176 see
http://lists.gnutls.org/pipermail/gnutls-devel/2014-April/006897.html

hth, cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


From asyourmind at gmail.com  Sat Apr 26 07:08:06 2014
From: asyourmind at gmail.com (cl)
Date: Sat, 26 Apr 2014 13:08:06 +0800
Subject: [gnutls-devel] openwrt used gnutls version3.2.12 with x86 platform
 have something wrong.
Message-ID: <535B3F36.8000406@gmail.com>

how can i fix it, plz help me. thx.

------------------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20140426/f0657273/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot from 2014-04-26 13:03:41.jpg
Type: image/jpeg
Size: 436553 bytes
Desc: not available
URL: </pipermail/attachments/20140426/f0657273/attachment-0001.jpg>

From ametzler at bebt.de  Sun Apr 27 17:09:28 2014
From: ametzler at bebt.de (Andreas Metzler)
Date: Sun, 27 Apr 2014 17:09:28 +0200
Subject: [gnutls-devel] gnutls 2.12.23 - chainverify testsuite failure on
	amd64
Message-ID: <20140427150928.GC2851@downhill.g.la>

Hello,

gnutls 2.12.23 has recently started failing the chainverify test on
amd64 (i386 works):

------------------------
(sid-AMD64)ametzler at argenau:/tmp/GNUTLS/gnutls-2.12.23$ ./tests/chainverify ; echo $?
chain[cacertrsamd5 ok]: verify_status: 1026 expected: 0
1
------------------------

Any idea? --verbose attached.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
-------------- next part --------------
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: verify.c:306
|<2>| ASSERT: verify.c:356
|<2>| ASSERT: verify.c:588
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:1209
Chain 'CVE-2008-4989' (0)...
	Certificate 0: subject `C=DE,O=GNU TLS Attack,CN=server', issuer `C=DE,O=GNU TLS Attack,CN=intermediate', RSA key 1024 bits, signed using RSA-SHA1, activated `2008-11-03 12:05:04 UTC', expires `2008-12-03 12:05:04 UTC', SHA-1 fingerprint `0cc65ee009e1345dbc0458545ffaaacbaf11c6ef'
	Certificate 1: subject `C=DE,O=GNU TLS Attack,CN=intermediate', issuer `C=DE,O=GNU TLS Attack,CN=root', RSA key 1024 bits, signed using RSA-SHA1, activated `2008-11-03 12:04:45 UTC', expires `2008-12-03 12:04:45 UTC', SHA-1 fingerprint `6d20189cb569bd77b7775a41171781dfa49f6211'
	Certificate 2: subject `C=US,O=thawte\, Inc.,OU=Certification Services Division,OU=(c) 2006 thawte\, Inc. - For authorized use only,CN=thawte Primary Root CA', issuer `C=US,O=thawte\, Inc.,OU=Certification Services Division,OU=(c) 2006 thawte\, Inc. - For authorized use only,CN=thawte Primary Root CA', RSA key 2048 bits, signed using RSA-SHA1, activated `2006-11-17 00:00:00 UTC', expires `2036-07-16 23:59:59 UTC', SHA-1 fingerprint `91c6d6ee3e8ac86384e548c299295c756c817b81'
	CA Certificate: subject `C=US,O=thawte\, Inc.,OU=Certification Services Division,OU=(c) 2006 thawte\, Inc. - For authorized use only,CN=thawte Primary Root CA', issuer `C=US,O=thawte\, Inc.,OU=Certification Services Division,OU=(c) 2006 thawte\, Inc. - For authorized use only,CN=thawte Primary Root CA', RSA key 2048 bits, signed using RSA-SHA1, activated `2006-11-17 00:00:00 UTC', expires `2036-07-16 23:59:59 UTC', SHA-1 fingerprint `91c6d6ee3e8ac86384e548c299295c756c817b81'
	Verifying...done
	Cleanup...done


Chain 'verisign.com v1 fail' (1)...
	Certificate 0: subject `serialNumber=2497886,jurisdictionOfIncorporationCountryName=US,jurisdictionOfIncorporationStateOrProvinceName=Delaware,C=US,postalCode=94043,ST=California,L=Mountain View,STREET=487 East Middlefield Road,O=VeriSign\, Inc.,OU=Production Security Services,OU=Terms of use at www.verisign.com/rpa (c)06,CN=www.verisign.com', issuer `C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=Terms of use at https://www.verisign.com/rpa (c)06,CN=VeriSign Class 3 Extended Validation SSL SGC CA', RSA key 1024 bits, signed using RSA-SHA1, activated `2007-05-09 00:00:00 UTC', expires `2009-05-08 23:59:59 UTC', SHA-1 fingerprint `c6750e8da95f5a65bb046d6079d4fc87402e0381'
	Certificate 1: subject `C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=Terms of use at https://www.verisign.com/rpa (c)06,CN=VeriSign Class 3 Extended Validation SSL SGC CA', issuer `C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=(c) 2006 VeriSign\, Inc. - For authorized use only,CN=VeriSign Class 3 Public Primary Certification Authority - G5', RSA key 2048 bits, signed using RSA-SHA1, activated `2006-11-08 00:00:00 UTC', expires `2016-11-07 23:59:59 UTC', SHA-1 fingerprint `4a8a2a0e276ff33b5dd88a362146010f2a8b6aee'
	Certificate 2: subject `C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=(c) 2006 VeriSign\, Inc. - For authorized use only,CN=VeriSign Class 3 Public Primary Certification Authority - G5', issuer `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', RSA key 2048 bits, signed using RSA-SHA1, activated `2006-11-08 00:00:00 UTC', expires `2021-11-07 23:59:59 UTC', SHA-1 fingerprint `7e7e026f71bfe7bbc7e7e5c591b1915cb6684e6c'
	Certificate 3: subject `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', issuer `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', RSA key 1024 bits, signed using RSA-MD2 (broken!), activated `1996-01-29 00:00:00 UTC', expires `2028-08-01 23:59:59 UTC', SHA-1 fingerprint `742c3192e607e424eb4549542be1bbc53e6174e2'
	CA Certificate: subject `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', issuer `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', RSA key 1024 bits, signed using RSA-MD2 (broken!), activated `1996-01-29 00:00:00 UTC', expires `2028-08-01 23:59:59 UTC', SHA-1 fingerprint `742c3192e607e424eb4549542be1bbc53e6174e2'
	Verifying...done
	Cleanup...done


Chain 'verisign.com v1 ok' (2)|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: mpi.c:609
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
...
	Certificate 0: subject `serialNumber=2497886,jurisdictionOfIncorporationCountryName=US,jurisdictionOfIncorporationStateOrProvinceName=Delaware,C=US,postalCode=94043,ST=California,L=Mountain View,STREET=487 East Middlefield Road,O=VeriSign\, Inc.,OU=Production Security Services,OU=Terms of use at www.verisign.com/rpa (c)06,CN=www.verisign.com', issuer `C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=Terms of use at https://www.verisign.com/rpa (c)06,CN=VeriSign Class 3 Extended Validation SSL SGC CA', RSA key 1024 bits, signed using RSA-SHA1, activated `2007-05-09 00:00:00 UTC', expires `2009-05-08 23:59:59 UTC', SHA-1 fingerprint `c6750e8da95f5a65bb046d6079d4fc87402e0381'
	Certificate 1: subject `C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=Terms of use at https://www.verisign.com/rpa (c)06,CN=VeriSign Class 3 Extended Validation SSL SGC CA', issuer `C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=(c) 2006 VeriSign\, Inc. - For authorized use only,CN=VeriSign Class 3 Public Primary Certification Authority - G5', RSA key 2048 bits, signed using RSA-SHA1, activated `2006-11-08 00:00:00 UTC', expires `2016-11-07 23:59:59 UTC', SHA-1 fingerprint `4a8a2a0e276ff33b5dd88a362146010f2a8b6aee'
	Certificate 2: subject `C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=(c) 2006 VeriSign\, Inc. - For authorized use only,CN=VeriSign Class 3 Public Primary Certification Authority - G5', issuer `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', RSA key 2048 bits, signed using RSA-SHA1, activated `2006-11-08 00:00:00 UTC', expires `2021-11-07 23:59:59 UTC', SHA-1 fingerprint `7e7e026f71bfe7bbc7e7e5c591b1915cb6684e6c'
	Certificate 3: subject `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', issuer `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', RSA key 1024 bits, signed using RSA-MD2 (broken!), activated `1996-01-29 00:00:00 UTC', expires `2028-08-01 23:59:59 UTC', SHA-1 fingerprint `742c3192e607e424eb4549542be1bbc53e6174e2'
	CA Certificate: subject `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', issuer `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', RSA key 1024 bits, signed using RSA-MD2 (broken!), activated `1996-01-29 00:00:00 UTC', expires `2028-08-01 23:59:59 UTC', SHA-1 fingerprint `742c3192e607e424eb4549542be1bbc53e6174e2'
	Verifying...done
	Cleanup...done


Chain 'citibank.com v1 fail' (3)...
	Certificate 0: subject `C=US,ST=New Jersey,L=Weehawken,O=Citigroup,OU=whg-oak6,CN=www.citibank.com', issuer `O=VeriSign Trust Network,OU=VeriSign\, Inc.,OU=VeriSign International Server CA - Class 3,OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign', RSA key 1024 bits, signed using RSA-SHA1, activated `2008-08-29 00:00:00 UTC', expires `2010-08-29 23:59:59 UTC', SHA-1 fingerprint `8b410d9cf13f191596a65f1f77580ddfa37aba49'
	Certificate 1: subject `O=VeriSign Trust Network,OU=VeriSign\, Inc.,OU=VeriSign International Server CA - Class 3,OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign', issuer `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', RSA key 1024 bits, signed using RSA-SHA1, activated `1997-04-17 00:00:00 UTC', expires `2011-10-24 23:59:59 UTC', SHA-1 fingerprint `c2f0087d01e686053a4d633e7e70d4ef65c2cc4f'
	Certificate 2: subject `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', issuer `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', RSA key 1024 bits, signed using RSA-MD2 (broken!), activated `1996-01-29 00:00:00 UTC', expires `2028-08-01 23:59:59 UTC', SHA-1 fingerprint `742c3192e607e424eb4549542be1bbc53e6174e2'
	CA Certificate: subject `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', issuer `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', RSA key 1024 bits, signed using RSA-MD2 (broken!), activated `1996-01-29 00:00:00 UTC', expires `2028-08-01 23:59:59 UTC', SHA-1 fingerprint `742c3192e607e424eb4549542be1bbc53|<2>| ASSERT: verify.c:207
|<2>| ASSERT: verify.c:376
|<2>| ASSERT: verify.c:588
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: mpi.c:609
|<2>| ASSERT: verify.c:207
|<2>| ASSERT: verify.c:376
|<2>| ASSERT: verify.c:588
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: mpi.c:609
|<2>| ASSERT: verify.c:207
|<2>| ASSERT: verify.c:376
|<2>| ASSERT: verify.c:588
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
e6174e2'
	Verifying...done
	Cleanup...done


Chain 'expired self signed' (4)...
	Certificate 0: subject `C=BR,O=Minas Livre,CN=Thadeu Lima de Souza Cascardo', issuer `C=BR,O=Minas Livre,CN=Thadeu Lima de Souza Cascardo', RSA key 2048 bits, signed using RSA-SHA1, activated `2008-05-30 19:53:43 UTC', expires `2008-11-26 19:53:43 UTC', SHA-1 fingerprint `87a0285ef6fa364664a50034a631c10a7279a77f'
	CA Certificate: subject `C=BR,O=Minas Livre,CN=Thadeu Lima de Souza Cascardo', issuer `C=BR,O=Minas Livre,CN=Thadeu Lima de Souza Cascardo', RSA key 2048 bits, signed using RSA-SHA1, activated `2008-05-30 19:53:43 UTC', expires `2008-11-26 19:53:43 UTC', SHA-1 fingerprint `87a0285ef6fa364664a50034a631c10a7279a77f'
	Verifying...done
	Cleanup...done


Chain 'self signed' (5)...
	Certificate 0: subject `C=BR,O=Minas Livre,CN=Thadeu Lima de Souza Cascardo', issuer `C=BR,O=Minas Livre,CN=Thadeu Lima de Souza Cascardo', RSA key 2048 bits, signed using RSA-SHA1, activated `2008-05-30 19:53:43 UTC', expires `2008-11-26 19:53:43 UTC', SHA-1 fingerprint `87a0285ef6fa364664a50034a631c10a7279a77f'
	CA Certificate: subject `C=BR,O=Minas Livre,CN=Thadeu Lima de Souza Cascardo', issuer `C=BR,O=Minas Livre,CN=Thadeu Lima de Souza Cascardo', RSA key 2048 bits, signed using RSA-SHA1, activated `2008-05-30 19:53:43 UTC', expires `2008-11-26 19:53:43 UTC', SHA-1 fingerprint `87a0285ef6fa364664a50034a631c10a7279a77f'
	Verifying...done
	Cleanup...done


Chain 'ca=false' (6)...
	Certificate 0: subject `C=DE,ST=RLP,L=Kaiserslautern,O=Technische Universitaet,OU=Fachbereich Physik,CN=thea.physik.uni-kl.de', issuer `C=DE,ST=RLP,O=Technische Universitaet,OU=Fachbereich Physik,CN=CA', RSA key 1024 bits, signed using RSA-SHA1, activated `2008-09-11 10:52:07 UTC', expires `2018-09-09 10:52:07 UTC', SHA-1 fingerprint `2fbe7e0f2266f7247b06cd41e63a3e1a104e4fd5'
	Certificate 1: subject `C=DE,ST=RLP,O=Technische Universitaet,OU=Fachbereich Physik,CN=CA', issuer `C=DE,ST=RLP,O=Technische Universitaet,OU=Fachbereich Physik,CN=CA', RSA key 1024 bits, signed using RSA-SHA1, activated `2008-09-11 10:47:44 UTC', expires `2018-09-09 10:47:44 UTC', SHA-1 fingerprint `5c3a6e72781972580071abeefe730d1b85f6d167'
	CA Certificate: subject `C=DE,ST=RLP,O=Technische Universitaet,OU=Fachbereich Physik,CN=CA', issuer `C=DE,ST=RLP,O=Technische Universitaet,OU=Fachbereich Physik,CN=CA', RSA key 1024 bits, signed using RSA-SHA1, activated `2008-09-11 10:47:44 UTC', expires `2018-09-09 10:47:44 UTC', SHA-1 fingerprint `5c3a6e72781972580071abeefe730d1b85f6d167'
	Verifying...done
	Cleanup...done


Chain 'ca=false2' (7)...
	Certificate 0: subject `C=DE,ST=RLP,L=Kaiserslautern,O=Technische Universitaet,OU=Fachbereich Physik,CN=thea.physik.uni-kl.de', issuer `C=DE,ST=RLP,O=Technische Universitaet,OU=Fachbereich Physik,CN=CA', RSA key 1024 bits, signed using RSA-SHA1, activated `2008-09-11 10:52:07 UTC', expires `2018-09-09 10:52:07 UTC', SHA-1 fingerprint `2fbe7e0f2266f7247b06cd41e63a3e1a104e4fd5'
	Certificate 1: subject `C=DE,ST=RLP,O=Technische Universitaet,OU=Fachbereich Physik,CN=CA', issuer `C=DE,ST=RLP,O=Technische Universitaet,OU=Fachbereich Physik,CN=CA', RSA key 1024 bits, signed using RSA-SHA1, activated `2008-09-11 10:47:44 UTC', expires `2018-09-09 10:47:44 UTC', SHA-1 fingerprint `5c3a6e72781972580071abeefe730d1b85f6d167'
	CA Certificate: subject `C=DE,ST=RLP,O=Technische Universitaet,OU=Fachbereich Physik,CN=CA', issuer `C=DE,ST=RLP,O=Technische Universitaet,OU=Fachbereich Physik,CN=CA', RSA key 1024 bits, signed using RSA-SHA1, activated `2008-09-11 10:47:44 UTC', expires `2018-09-09 10:47:44 UTC', SHA-1 fingerprint `5c3a6e72781972580071abeefe730d1b85f6d167'
	Verifying...done
	Cleanup...done


Chain 'hbci v1 fail' (8)...
	Certificate 0: subject `C=DE,ST=Hessen,L=Frankfurt am Main,O=Sparkassen Informatik GmbH & Co. KG,OU=Terms of use at www.verisign.com,CN=hbci-pintan-rp.s-hbci.de', issuer `O=VeriSign Trust Network,OU=VeriSign\, Inc.,OU=VeriSign International Server CA - Class 3,OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign', RSA key 1024 bits, signed using |<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: verify.c:207
|<2>| ASSERT: verify.c:376
|<2>| ASSERT: verify.c:588
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
RSA-SHA1, activated `2008-06-10 00:00:00 UTC', expires `2009-07-30 23:59:59 UTC', SHA-1 fingerprint `a648bde8c1d773504947bc581ac730ea0bdb4df6'
	Certificate 1: subject `O=VeriSign Trust Network,OU=VeriSign\, Inc.,OU=VeriSign International Server CA - Class 3,OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign', issuer `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', RSA key 1024 bits, signed using RSA-SHA1, activated `1997-04-17 00:00:00 UTC', expires `2011-10-24 23:59:59 UTC', SHA-1 fingerprint `c2f0087d01e686053a4d633e7e70d4ef65c2cc4f'
	Certificate 2: subject `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', issuer `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', RSA key 1024 bits, signed using RSA-MD2 (broken!), activated `1996-01-29 00:00:00 UTC', expires `2028-08-01 23:59:59 UTC', SHA-1 fingerprint `742c3192e607e424eb4549542be1bbc53e6174e2'
	CA Certificate: subject `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', issuer `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', RSA key 1024 bits, signed using RSA-MD2 (broken!), activated `1996-01-29 00:00:00 UTC', expires `2028-08-01 23:59:59 UTC', SHA-1 fingerprint `742c3192e607e424eb4549542be1bbc53e6174e2'
	Verifying...done
	Cleanup...done


Chain 'hbci v1 ok expired' (9)...
	Certificate 0: subject `C=DE,ST=Hessen,L=Frankfurt am Main,O=Sparkassen Informatik GmbH & Co. KG,OU=Terms of use at www.verisign.com,CN=hbci-pintan-rp.s-hbci.de', issuer `O=VeriSign Trust Network,OU=VeriSign\, Inc.,OU=VeriSign International Server CA - Class 3,OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign', RSA key 1024 bits, signed using RSA-SHA1, activated `2008-06-10 00:00:00 UTC', expires `2009-07-30 23:59:59 UTC', SHA-1 fingerprint `a648bde8c1d773504947bc581ac730ea0bdb4df6'
	Certificate 1: subject `O=VeriSign Trust Network,OU=VeriSign\, Inc.,OU=VeriSign International Server CA - Class 3,OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign', issuer `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', RSA key 1024 bits, signed using RSA-SHA1, activated `1997-04-17 00:00:00 UTC', expires `2011-10-24 23:59:59 UTC', SHA-1 fingerprint `c2f0087d01e686053a4d633e7e70d4ef65c2cc4f'
	Certificate 2: subject `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', issuer `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', RSA key 1024 bits, signed using RSA-MD2 (broken!), activated `1996-01-29 00:00:00 UTC', expires `2028-08-01 23:59:59 UTC', SHA-1 fingerprint `742c3192e607e424eb4549542be1bbc53e6174e2'
	CA Certificate: subject `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', issuer `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', RSA key 1024 bits, signed using RSA-MD2 (broken!), activated `1996-01-29 00:00:00 UTC', expires `2028-08-01 23:59:59 UTC', SHA-1 fingerprint `742c3192e607e424eb4549542be1bbc53e6174e2'
	Verifying...done
	Cleanup...done


Chain 'hbci v1 ok' (10)...
	Certificate 0: subject `C=DE,ST=Hessen,L=Frankfurt am Main,O=Sparkassen Informatik GmbH & Co. KG,OU=Terms of use at www.verisign.com,CN=hbci-pintan-rp.s-hbci.de', issuer `O=VeriSign Trust Network,OU=VeriSign\, Inc.,OU=VeriSign International Server CA - Class 3,OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign', RSA key 1024 bits, signed using RSA-SHA1, activated `2008-06-10 00:00:00 UTC', expires `2009-07-30 23:59:59 UTC', SHA-1 fingerprint `a648bde8c1d773504947bc581ac730ea0bdb4df6'
	Certificate 1: subject `O=VeriSign Trust Network,OU=VeriSign\, Inc.,OU=VeriSign International Server CA - Class 3,OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign', issuer `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', RSA key 1024 bits, signed using RSA-SHA1, activated `1997-04-17 00:00:00 UTC', expires `2011-10-24 23:59:59 UTC', SHA-1 fingerprint `c2f0087d01e686053a4d633e7e70d4ef65c2cc4f'
	Certif|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: mpi.c:609
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: verify.c:588
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: mpi.c:609
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: verify.c:588
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
icate 2: subject `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', issuer `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', RSA key 1024 bits, signed using RSA-MD2 (broken!), activated `1996-01-29 00:00:00 UTC', expires `2028-08-01 23:59:59 UTC', SHA-1 fingerprint `742c3192e607e424eb4549542be1bbc53e6174e2'
	CA Certificate: subject `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', issuer `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', RSA key 1024 bits, signed using RSA-MD2 (broken!), activated `1996-01-29 00:00:00 UTC', expires `2028-08-01 23:59:59 UTC', SHA-1 fingerprint `742c3192e607e424eb4549542be1bbc53e6174e2'
	Verifying...done
	Cleanup...done


Chain 'rsa-md5 fail' (11)...
	Certificate 0: subject `C=US,O=support.mayfirst.org,OU=GT69079880,OU=See www.rapidssl.com/resources/cps (c)07,OU=Domain Control Validated - RapidSSL(R),CN=support.mayfirst.org', issuer `C=US,O=Equifax Secure Inc.,CN=Equifax Secure Global eBusiness CA-1', RSA key 1024 bits, signed using RSA-MD5 (broken!), activated `2008-05-19 05:29:19 UTC', expires `2009-10-19 05:29:19 UTC', SHA-1 fingerprint `be7755879c78be4a19c16f789f752c4394a85395'
	Certificate 1: subject `C=US,O=Equifax Secure Inc.,CN=Equifax Secure Global eBusiness CA-1', issuer `C=US,O=Equifax Secure Inc.,CN=Equifax Secure Global eBusiness CA-1', RSA key 1024 bits, signed using RSA-MD5 (broken!), activated `1999-06-21 04:00:00 UTC', expires `2020-06-21 04:00:00 UTC', SHA-1 fingerprint `7e784a101c8265cc2de1f16d47b440cad90a1945'
	CA Certificate: subject `C=US,O=Equifax Secure Inc.,CN=Equifax Secure Global eBusiness CA-1', issuer `C=US,O=Equifax Secure Inc.,CN=Equifax Secure Global eBusiness CA-1', RSA key 1024 bits, signed using RSA-MD5 (broken!), activated `1999-06-21 04:00:00 UTC', expires `2020-06-21 04:00:00 UTC', SHA-1 fingerprint `7e784a101c8265cc2de1f16d47b440cad90a1945'
	Verifying...done
	Cleanup...done


Chain 'rsa-md5 not ok' (12)...
	Certificate 0: subject `C=US,O=support.mayfirst.org,OU=GT69079880,OU=See www.rapidssl.com/resources/cps (c)07,OU=Domain Control Validated - RapidSSL(R),CN=support.mayfirst.org', issuer `C=US,O=Equifax Secure Inc.,CN=Equifax Secure Global eBusiness CA-1', RSA key 1024 bits, signed using RSA-MD5 (broken!), activated `2008-05-19 05:29:19 UTC', expires `2009-10-19 05:29:19 UTC', SHA-1 fingerprint `be7755879c78be4a19c16f789f752c4394a85395'
	Certificate 1: subject `C=US,O=Equifax Secure Inc.,CN=Equifax Secure Global eBusiness CA-1', issuer `C=US,O=Equifax Secure Inc.,CN=Equifax Secure Global eBusiness CA-1', RSA key 1024 bits, signed using RSA-MD5 (broken!), activated `1999-06-21 04:00:00 UTC', expires `2020-06-21 04:00:00 UTC', SHA-1 fingerprint `7e784a101c8265cc2de1f16d47b440cad90a1945'
	CA Certificate: subject `C=US,O=Equifax Secure Inc.,CN=Equifax Secure Global eBusiness CA-1', issuer `C=US,O=Equifax Secure Inc.,CN=Equifax Secure Global eBusiness CA-1', RSA key 1024 bits, signed using RSA-MD5 (broken!), activated `1999-06-21 04:00:00 UTC', expires `2020-06-21 04:00:00 UTC', SHA-1 fingerprint `7e784a101c8265cc2de1f16d47b440cad90a1945'
	Verifying...done
	Cleanup...done


Chain 'rsa-md5 not ok2' (13)...
	Certificate 0: subject `C=US,O=support.mayfirst.org,OU=GT69079880,OU=See www.rapidssl.com/resources/cps (c)07,OU=Domain Control Validated - RapidSSL(R),CN=support.mayfirst.org', issuer `C=US,O=Equifax Secure Inc.,CN=Equifax Secure Global eBusiness CA-1', RSA key 1024 bits, signed using RSA-MD5 (broken!), activated `2008-05-19 05:29:19 UTC', expires `2009-10-19 05:29:19 UTC', SHA-1 fingerprint `be7755879c78be4a19c16f789f752c4394a85395'
	Certificate 1: subject `C=US,O=Equifax Secure Inc.,CN=Equifax Secure Global eBusiness CA-1', issuer `C=US,O=Equifax Secure Inc.,CN=Equifax Secure Global eBusiness CA-1', RSA key 1024 bits, signed using RSA-MD5 (broken!), activated `1999-06-21 04:00:00 UTC', expires `2020-06-21 04:00:00 UTC', SHA-1 fingerprint `7e784a101c8265cc2de1f16d47b440cad90a1945'
	CA Certificate: subject `C=US,O=Equifax Secure Inc.,CN=Equifax Secure |<2>| ASSERT: mpi.c:609
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: mpi.c:609
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: verify.c:207
|<2>| ASSERT: verify.c:376
|<2>| ASSERT: verify.c:588
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
Global eBusiness CA-1', issuer `C=US,O=Equifax Secure Inc.,CN=Equifax Secure Global eBusiness CA-1', RSA key 1024 bits, signed using RSA-MD5 (broken!), activated `1999-06-21 04:00:00 UTC', expires `2020-06-21 04:00:00 UTC', SHA-1 fingerprint `7e784a101c8265cc2de1f16d47b440cad90a1945'
	Verifying...done
	Cleanup...done


Chain 'rsa-md5 ok' (14)...
	Certificate 0: subject `C=US,O=support.mayfirst.org,OU=GT69079880,OU=See www.rapidssl.com/resources/cps (c)07,OU=Domain Control Validated - RapidSSL(R),CN=support.mayfirst.org', issuer `C=US,O=Equifax Secure Inc.,CN=Equifax Secure Global eBusiness CA-1', RSA key 1024 bits, signed using RSA-MD5 (broken!), activated `2008-05-19 05:29:19 UTC', expires `2009-10-19 05:29:19 UTC', SHA-1 fingerprint `be7755879c78be4a19c16f789f752c4394a85395'
	Certificate 1: subject `C=US,O=Equifax Secure Inc.,CN=Equifax Secure Global eBusiness CA-1', issuer `C=US,O=Equifax Secure Inc.,CN=Equifax Secure Global eBusiness CA-1', RSA key 1024 bits, signed using RSA-MD5 (broken!), activated `1999-06-21 04:00:00 UTC', expires `2020-06-21 04:00:00 UTC', SHA-1 fingerprint `7e784a101c8265cc2de1f16d47b440cad90a1945'
	CA Certificate: subject `C=US,O=Equifax Secure Inc.,CN=Equifax Secure Global eBusiness CA-1', issuer `C=US,O=Equifax Secure Inc.,CN=Equifax Secure Global eBusiness CA-1', RSA key 1024 bits, signed using RSA-MD5 (broken!), activated `1999-06-21 04:00:00 UTC', expires `2020-06-21 04:00:00 UTC', SHA-1 fingerprint `7e784a101c8265cc2de1f16d47b440cad90a1945'
	Verifying...done
	Cleanup...done


Chain 'v1ca fail' (15)...
	Certificate 0: subject `C=US,ST=Illinois,L=Du Page,O=Argonne National Laboratory,CN=auth2.it.anl.gov', issuer `C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=Terms of use at https://www.verisign.com/rpa (c)05,CN=VeriSign Class 3 Secure Server CA', RSA key 1024 bits, signed using RSA-SHA1, activated `2008-05-05 00:00:00 UTC', expires `2009-05-22 23:59:59 UTC', SHA-1 fingerprint `687c93b7db0cc9b9d899aa2e9633e18db0ba7925'
	Certificate 1: subject `C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=Terms of use at https://www.verisign.com/rpa (c)05,CN=VeriSign Class 3 Secure Server CA', issuer `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', RSA key 2048 bits, signed using RSA-SHA1, activated `2005-01-19 00:00:00 UTC', expires `2015-01-18 23:59:59 UTC', SHA-1 fingerprint `188590e94878478e33b6194e59fbbb28ff0888d5'
	Certificate 2: subject `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', issuer `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', RSA key 1024 bits, signed using RSA-MD2 (broken!), activated `1996-01-29 00:00:00 UTC', expires `2028-08-01 23:59:59 UTC', SHA-1 fingerprint `742c3192e607e424eb4549542be1bbc53e6174e2'
	CA Certificate: subject `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', issuer `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', RSA key 1024 bits, signed using RSA-MD2 (broken!), activated `1996-01-29 00:00:00 UTC', expires `2028-08-01 23:59:59 UTC', SHA-1 fingerprint `742c3192e607e424eb4549542be1bbc53e6174e2'
	Verifying...done
	Cleanup...done


Chain 'v1ca expired' (16)...
	Certificate 0: subject `C=US,ST=Illinois,L=Du Page,O=Argonne National Laboratory,CN=auth2.it.anl.gov', issuer `C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=Terms of use at https://www.verisign.com/rpa (c)05,CN=VeriSign Class 3 Secure Server CA', RSA key 1024 bits, signed using RSA-SHA1, activated `2008-05-05 00:00:00 UTC', expires `2009-05-22 23:59:59 UTC', SHA-1 fingerprint `687c93b7db0cc9b9d899aa2e9633e18db0ba7925'
	Certificate 1: subject `C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=Terms of use at https://www.verisign.com/rpa (c)05,CN=VeriSign Class 3 Secure Server CA', issuer `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', RSA key 2048 bits, signed using RSA-SHA1, activated `2005-01-19 00:00:00 UTC', expires `2015-01-18 23:59:59 UTC', SHA-1 fingerprint `188590e94878478e33b6194e59fbbb28ff0888d5'
	Certificate 2: subject `C=|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', issuer `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', RSA key 1024 bits, signed using RSA-MD2 (broken!), activated `1996-01-29 00:00:00 UTC', expires `2028-08-01 23:59:59 UTC', SHA-1 fingerprint `742c3192e607e424eb4549542be1bbc53e6174e2'
	CA Certificate: subject `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', issuer `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', RSA key 1024 bits, signed using RSA-MD2 (broken!), activated `1996-01-29 00:00:00 UTC', expires `2028-08-01 23:59:59 UTC', SHA-1 fingerprint `742c3192e607e424eb4549542be1bbc53e6174e2'
	Verifying...done
	Cleanup...done


Chain 'v1ca ok' (17)...
	Certificate 0: subject `C=US,ST=Illinois,L=Du Page,O=Argonne National Laboratory,CN=auth2.it.anl.gov', issuer `C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=Terms of use at https://www.verisign.com/rpa (c)05,CN=VeriSign Class 3 Secure Server CA', RSA key 1024 bits, signed using RSA-SHA1, activated `2008-05-05 00:00:00 UTC', expires `2009-05-22 23:59:59 UTC', SHA-1 fingerprint `687c93b7db0cc9b9d899aa2e9633e18db0ba7925'
	Certificate 1: subject `C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=Terms of use at https://www.verisign.com/rpa (c)05,CN=VeriSign Class 3 Secure Server CA', issuer `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', RSA key 2048 bits, signed using RSA-SHA1, activated `2005-01-19 00:00:00 UTC', expires `2015-01-18 23:59:59 UTC', SHA-1 fingerprint `188590e94878478e33b6194e59fbbb28ff0888d5'
	Certificate 2: subject `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', issuer `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', RSA key 1024 bits, signed using RSA-MD2 (broken!), activated `1996-01-29 00:00:00 UTC', expires `2028-08-01 23:59:59 UTC', SHA-1 fingerprint `742c3192e607e424eb4549542be1bbc53e6174e2'
	CA Certificate: subject `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', issuer `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', RSA key 1024 bits, signed using RSA-MD2 (broken!), activated `1996-01-29 00:00:00 UTC', expires `2028-08-01 23:59:59 UTC', SHA-1 fingerprint `742c3192e607e424eb4549542be1bbc53e6174e2'
	Verifying...done
	Cleanup...done


Chain 'v1ca2 expired' (18)...
	Certificate 0: subject `C=US,ST=Illinois,L=Du Page,O=Argonne National Laboratory,CN=auth2.it.anl.gov', issuer `C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=Terms of use at https://www.verisign.com/rpa (c)05,CN=VeriSign Class 3 Secure Server CA', RSA key 1024 bits, signed using RSA-SHA1, activated `2008-05-05 00:00:00 UTC', expires `2009-05-22 23:59:59 UTC', SHA-1 fingerprint `687c93b7db0cc9b9d899aa2e9633e18db0ba7925'
	Certificate 1: subject `C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=Terms of use at https://www.verisign.com/rpa (c)05,CN=VeriSign Class 3 Secure Server CA', issuer `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', RSA key 2048 bits, signed using RSA-SHA1, activated `2005-01-19 00:00:00 UTC', expires `2015-01-18 23:59:59 UTC', SHA-1 fingerprint `188590e94878478e33b6194e59fbbb28ff0888d5'
	Certificate 2: subject `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', issuer `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', RSA key 1024 bits, signed using RSA-MD2 (broken!), activated `1996-01-29 00:00:00 UTC', expires `2028-08-01 23:59:59 UTC', SHA-1 fingerprint `742c3192e607e424eb4549542be1bbc53e6174e2'
	CA Certificate: subject `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', issuer `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', RSA key 1024 bits, signed using RSA-MD2 (broken!), activated `1996-01-29 00:00:00 UTC', expires `2028-08-01 23:59:59 UTC', SHA-1 fingerprint `742c3192e607e424eb4549542be1bbc53e6174e2'
	Verifying...done
	Cleanup...done


Chain 'v1ca2 ok' (19)...
	Certificate 0: subject|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: mpi.c:609
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: verify.c:588
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
 `C=US,ST=Illinois,L=Du Page,O=Argonne National Laboratory,CN=auth2.it.anl.gov', issuer `C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=Terms of use at https://www.verisign.com/rpa (c)05,CN=VeriSign Class 3 Secure Server CA', RSA key 1024 bits, signed using RSA-SHA1, activated `2008-05-05 00:00:00 UTC', expires `2009-05-22 23:59:59 UTC', SHA-1 fingerprint `687c93b7db0cc9b9d899aa2e9633e18db0ba7925'
	Certificate 1: subject `C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=Terms of use at https://www.verisign.com/rpa (c)05,CN=VeriSign Class 3 Secure Server CA', issuer `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', RSA key 2048 bits, signed using RSA-SHA1, activated `2005-01-19 00:00:00 UTC', expires `2015-01-18 23:59:59 UTC', SHA-1 fingerprint `188590e94878478e33b6194e59fbbb28ff0888d5'
	Certificate 2: subject `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', issuer `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', RSA key 1024 bits, signed using RSA-MD2 (broken!), activated `1996-01-29 00:00:00 UTC', expires `2028-08-01 23:59:59 UTC', SHA-1 fingerprint `742c3192e607e424eb4549542be1bbc53e6174e2'
	CA Certificate: subject `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', issuer `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', RSA key 1024 bits, signed using RSA-MD2 (broken!), activated `1996-01-29 00:00:00 UTC', expires `2028-08-01 23:59:59 UTC', SHA-1 fingerprint `742c3192e607e424eb4549542be1bbc53e6174e2'
	Verifying...done
	Cleanup...done


Chain 'cacertrsamd5 fail' (20)...
	Certificate 0: subject `CN=fry.serverama.de', issuer `O=CAcert Inc.,OU=http://www.CAcert.org,CN=CAcert Class 3 Root', RSA key 1024 bits, signed using RSA-SHA1, activated `2009-01-16 22:29:47 UTC', expires `2011-01-16 22:29:47 UTC', SHA-1 fingerprint `7d18c5e1f1fc350458b499ee5d95bbf41274597d'
	Certificate 1: subject `O=CAcert Inc.,OU=http://www.CAcert.org,CN=CAcert Class 3 Root', issuer `O=Root CA,OU=http://www.cacert.org,CN=CA Cert Signing Authority,EMAIL=support at cacert.org', RSA key 4096 bits, signed using RSA-MD5 (broken!), activated `2005-10-14 07:36:55 UTC', expires `2033-03-28 07:36:55 UTC', SHA-1 fingerprint `db4c4269073fe9c2a37d890a5c1b18c4184e2a2d'
	Certificate 2: subject `O=Root CA,OU=http://www.cacert.org,CN=CA Cert Signing Authority,EMAIL=support at cacert.org', issuer `O=Root CA,OU=http://www.cacert.org,CN=CA Cert Signing Authority,EMAIL=support at cacert.org', RSA key 4096 bits, signed using RSA-MD5 (broken!), activated `2003-03-30 12:29:49 UTC', expires `2033-03-29 12:29:49 UTC', SHA-1 fingerprint `135cec36f49cb8e93b1ab270cd80884676ce8f33'
	CA Certificate: subject `O=Root CA,OU=http://www.cacert.org,CN=CA Cert Signing Authority,EMAIL=support at cacert.org', issuer `O=Root CA,OU=http://www.cacert.org,CN=CA Cert Signing Authority,EMAIL=support at cacert.org', RSA key 4096 bits, signed using RSA-MD5 (broken!), activated `2003-03-30 12:29:49 UTC', expires `2033-03-29 12:29:49 UTC', SHA-1 fingerprint `135cec36f49cb8e93b1ab270cd80884676ce8f33'
	Verifying...done
	Cleanup...done


Chain 'cacertrsamd5 ok' (21)...
	Certificate 0: subject `CN=fry.serverama.de', issuer `O=CAcert Inc.,OU=http://www.CAcert.org,CN=CAcert Class 3 Root', RSA key 1024 bits, signed using RSA-SHA1, activated `2009-01-16 22:29:47 UTC', expires `2011-01-16 22:29:47 UTC', SHA-1 fingerprint `7d18c5e1f1fc350458b499ee5d95bbf41274597d'
	Certificate 1: subject `O=CAcert Inc.,OU=http://www.CAcert.org,CN=CAcert Class 3 Root', issuer `O=Root CA,OU=http://www.cacert.org,CN=CA Cert Signing Authority,EMAIL=support at cacert.org', RSA key 4096 bits, signed using RSA-MD5 (broken!), activated `2005-10-14 07:36:55 UTC', expires `2033-03-28 07:36:55 UTC', SHA-1 fingerprint `db4c4269073fe9c2a37d890a5c1b18c4184e2a2d'
	Certificate 2: subject `O=Root CA,OU=http://www.cacert.org,CN=CA Cert Signing Authority,EMAIL=support at cacert.org', issuer `O=Root CA,OU=http://www.cacert.org,CN=CA Cert Signing Authority,EMAIL=support at cacert.org', RSA key 4096 bits, signed using RSA-MD5 (broke|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: mpi.c:609
|<2>| ASSERT: dn.c:1209
chain[cacertrsamd5 ok]: verify_status: 1026 expected: 0
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: verify.c:306
|<2>| ASSERT: verify.c:356
|<2>| ASSERT: verify.c:588
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: dn.c:305
|<2>| ASSERT: mpi.c:609
|<2>| ASSERT: dn.c:1209
chain[cacertrsamd5 short-cut ok]: verify_status: 1026 expected: 0
n!), activated `2003-03-30 12:29:49 UTC', expires `2033-03-29 12:29:49 UTC', SHA-1 fingerprint `135cec36f49cb8e93b1ab270cd80884676ce8f33'
	CA Certificate: subject `O=Root CA,OU=http://www.cacert.org,CN=CA Cert Signing Authority,EMAIL=support at cacert.org', issuer `O=Root CA,OU=http://www.cacert.org,CN=CA Cert Signing Authority,EMAIL=support at cacert.org', RSA key 4096 bits, signed using RSA-MD5 (broken!), activated `2003-03-30 12:29:49 UTC', expires `2033-03-29 12:29:49 UTC', SHA-1 fingerprint `135cec36f49cb8e93b1ab270cd80884676ce8f33'
	Verifying...	Cleanup...done


Chain 'cacertrsamd5 short-cut not ok' (22)...
	Certificate 0: subject `CN=fry.serverama.de', issuer `O=CAcert Inc.,OU=http://www.CAcert.org,CN=CAcert Class 3 Root', RSA key 1024 bits, signed using RSA-SHA1, activated `2009-01-16 22:29:47 UTC', expires `2011-01-16 22:29:47 UTC', SHA-1 fingerprint `7d18c5e1f1fc350458b499ee5d95bbf41274597d'
	Certificate 1: subject `O=CAcert Inc.,OU=http://www.CAcert.org,CN=CAcert Class 3 Root', issuer `O=Root CA,OU=http://www.cacert.org,CN=CA Cert Signing Authority,EMAIL=support at cacert.org', RSA key 4096 bits, signed using RSA-MD5 (broken!), activated `2005-10-14 07:36:55 UTC', expires `2033-03-28 07:36:55 UTC', SHA-1 fingerprint `db4c4269073fe9c2a37d890a5c1b18c4184e2a2d'
	Certificate 2: subject `O=Root CA,OU=http://www.cacert.org,CN=CA Cert Signing Authority,EMAIL=support at cacert.org', issuer `O=Root CA,OU=http://www.cacert.org,CN=CA Cert Signing Authority,EMAIL=support at cacert.org', RSA key 4096 bits, signed using RSA-MD5 (broken!), activated `2003-03-30 12:29:49 UTC', expires `2033-03-29 12:29:49 UTC', SHA-1 fingerprint `135cec36f49cb8e93b1ab270cd80884676ce8f33'
	CA Certificate: subject `CN=fry.serverama.de', issuer `O=CAcert Inc.,OU=http://www.CAcert.org,CN=CAcert Class 3 Root', RSA key 1024 bits, signed using RSA-SHA1, activated `2009-01-16 22:29:47 UTC', expires `2011-01-16 22:29:47 UTC', SHA-1 fingerprint `7d18c5e1f1fc350458b499ee5d95bbf41274597d'
	Verifying...done
	Cleanup...done


Chain 'cacertrsamd5 short-cut ok' (23)...
	Certificate 0: subject `CN=fry.serverama.de', issuer `O=CAcert Inc.,OU=http://www.CAcert.org,CN=CAcert Class 3 Root', RSA key 1024 bits, signed using RSA-SHA1, activated `2009-01-16 22:29:47 UTC', expires `2011-01-16 22:29:47 UTC', SHA-1 fingerprint `7d18c5e1f1fc350458b499ee5d95bbf41274597d'
	Certificate 1: subject `O=CAcert Inc.,OU=http://www.CAcert.org,CN=CAcert Class 3 Root', issuer `O=Root CA,OU=http://www.cacert.org,CN=CA Cert Signing Authority,EMAIL=support at cacert.org', RSA key 4096 bits, signed using RSA-MD5 (broken!), activated `2005-10-14 07:36:55 UTC', expires `2033-03-28 07:36:55 UTC', SHA-1 fingerprint `db4c4269073fe9c2a37d890a5c1b18c4184e2a2d'
	Certificate 2: subject `O=Root CA,OU=http://www.cacert.org,CN=CA Cert Signing Authority,EMAIL=support at cacert.org', issuer `O=Root CA,OU=http://www.cacert.org,CN=CA Cert Signing Authority,EMAIL=support at cacert.org', RSA key 4096 bits, signed using RSA-MD5 (broken!), activated `2003-03-30 12:29:49 UTC', expires `2033-03-29 12:29:49 UTC', SHA-1 fingerprint `135cec36f49cb8e93b1ab270cd80884676ce8f33'
	CA Certificate: subject `O=CAcert Inc.,OU=http://www.CAcert.org,CN=CAcert Class 3 Root', issuer `O=Root CA,OU=http://www.cacert.org,CN=CA Cert Signing Authority,EMAIL=support at cacert.org', RSA key 4096 bits, signed using RSA-MD5 (broken!), activated `2005-10-14 07:36:55 UTC', expires `2033-03-28 07:36:55 UTC', SHA-1 fingerprint `db4c4269073fe9c2a37d890a5c1b18c4184e2a2d'
	Verifying...	Cleanup...done


Exit status...0
0

From nmav at gnutls.org  Sun Apr 27 18:40:39 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 27 Apr 2014 18:40:39 +0200
Subject: [gnutls-devel] Typo fix
In-Reply-To: <20140419181139.GB2837@downhill.g.la>
References: <20140419181139.GB2837@downhill.g.la>
Message-ID: <1398616839.25589.19.camel@nomad.lan>

On Sat, 2014-04-19 at 20:11 +0200, Andreas Metzler wrote:
> Hello,
> 
> find attached a trivial patch against GIT head,
> s/overriden/overridden/

Applied, thank you!




From nmav at gnutls.org  Sun Apr 27 18:41:42 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 27 Apr 2014 18:41:42 +0200
Subject: [gnutls-devel] [PATCH 2/3] Test for the existance of the
 /etc/system-fips file
In-Reply-To: <1397929579-13059-2-git-send-email-kurt@roeckx.be>
References: <1397929579-13059-1-git-send-email-kurt@roeckx.be>
 <1397929579-13059-2-git-send-email-kurt@roeckx.be>
Message-ID: <1398616902.25589.20.camel@nomad.lan>

On Sat, 2014-04-19 at 19:46 +0200, Kurt Roeckx wrote:
> We don't read it, the existance of the file is enough to say in what
> mode we are.

Both 1 and 2 applied. Thank you!




From nmav at gnutls.org  Sun Apr 27 18:43:29 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 27 Apr 2014 18:43:29 +0200
Subject: [gnutls-devel] GnuTLS 3.3.1: core.c:3369:3: error:
 'gnutls_secure_malloc' undeclared
In-Reply-To: <87k3aht0tf.fsf@karetnikov.org>
References: <87k3aht0tf.fsf@karetnikov.org>
Message-ID: <1398617009.25589.21.camel@nomad.lan>

On Wed, 2014-04-23 at 03:13 +0400, Nikita Karetnikov wrote:
> ?gnutls-remove-gnutls_secure_malloc.patch? fixes the following issue:
> 
> make[4]: Entering directory '/tmp/nix-build-gnutls-3.3.1.drv-0/gnutls-3.3.1/guile/src'
>   CC       guile_gnutls_v_2_la-core.lo
> core.c: In function 'scm_init_gnutls':
> core.c:3369:3: error: 'gnutls_secure_malloc' undeclared (first use in this function)
>    gnutls_secure_malloc = scm_malloc;

Thank you. A similar fix is already applied on the repository.

regards,
Nikos




From nmav at gnutls.org  Sun Apr 27 18:45:54 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 27 Apr 2014 18:45:54 +0200
Subject: [gnutls-devel] segfault on gnutls_x509_crt_import
In-Reply-To: <CABD9f3NKWUn+cntkinP2Qgm6zmnJ4U==GujpSKhvdXZxCaBQzQ@mail.gmail.com>
References: <CABD9f3NKWUn+cntkinP2Qgm6zmnJ4U==GujpSKhvdXZxCaBQzQ@mail.gmail.com>
Message-ID: <1398617154.25589.23.camel@nomad.lan>

On Mon, 2014-04-21 at 16:34 +0200, Marcos Ag?ero wrote:
> Hi,

> While using libcurl with gnutls, on certain URL
> hxxps://harrowmedia.com/ (WARNING! URL is known to host malware), i'm
> getting unexpected segmentation fault. I'm not sure if it's related to
> libcurl version or gnutls, but I suspect that is a malformed
> certificate.
> 
> 
> I'm using gnutls version 2.12.23-12ubuntu2 (latest ubuntu package)

Hello Marcos,
 This version is no longer supported. Please report it on the ubuntu bug
tracker, or again here if the problem persists with a the latest stable
branch.

regards,
Nikos





From nmav at gnutls.org  Sun Apr 27 19:03:18 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 27 Apr 2014 19:03:18 +0200
Subject: [gnutls-devel] gnutls 2.12.23 - chainverify testsuite failure
 on amd64
In-Reply-To: <20140427150928.GC2851@downhill.g.la>
References: <20140427150928.GC2851@downhill.g.la>
Message-ID: <1398618198.25589.28.camel@nomad.lan>

On Sun, 2014-04-27 at 17:09 +0200, Andreas Metzler wrote:
> Hello,
> 
> gnutls 2.12.23 has recently started failing the chainverify test on
> amd64 (i386 works):
> 
> ------------------------
> (sid-AMD64)ametzler at argenau:/tmp/GNUTLS/gnutls-2.12.23$ ./tests/chainverify ; echo $?
> chain[cacertrsamd5 ok]: verify_status: 1026 expected: 0
> 1
> ------------------------
> 
> Any idea? --verbose attached.

Hello Andreas,
 1024+2 is an expiration failure. There may be some check in that
version that isn't time-independent. Could it be that i386 and amd64
have different time?

regards,
Nikos





From nmav at gnutls.org  Sun Apr 27 19:40:53 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 27 Apr 2014 19:40:53 +0200
Subject: [gnutls-devel] openwrt used gnutls version3.2.12 with x86
 platform have something wrong.
In-Reply-To: <535B3F36.8000406@gmail.com>
References: <535B3F36.8000406@gmail.com>
Message-ID: <1398620453.1404.1.camel@nomad.lan>

On Sat, 2014-04-26 at 13:08 +0800, cl wrote:
> how can i fix it, plz help me. thx.

That looks like a clash of the included x86.h with some openwrt header.
See https://dev.openwrt.org/ticket/15555 for a possible fix.

regards,
Nikos




From ametzler at bebt.de  Sun Apr 27 20:10:56 2014
From: ametzler at bebt.de (Andreas Metzler)
Date: Sun, 27 Apr 2014 20:10:56 +0200
Subject: [gnutls-devel] gnutls 2.12.23 - chainverify testsuite failure
 on amd64
In-Reply-To: <1398618198.25589.28.camel@nomad.lan>
References: <20140427150928.GC2851@downhill.g.la>
 <1398618198.25589.28.camel@nomad.lan>
Message-ID: <20140427181056.GD2851@downhill.g.la>

On 2014-04-27 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> On Sun, 2014-04-27 at 17:09 +0200, Andreas Metzler wrote:
>> gnutls 2.12.23 has recently started failing the chainverify test on
>> amd64 (i386 works):
 
>> ------------------------
>> (sid-AMD64)ametzler at argenau:/tmp/GNUTLS/gnutls-2.12.23$ ./tests/chainverify ; echo $?
>> chain[cacertrsamd5 ok]: verify_status: 1026 expected: 0
>> 1
>> ------------------------

>> Any idea? --verbose attached.

> Hello Andreas,
>  1024+2 is an expiration failure. There may be some check in that
> version that isn't time-independent. Could it be that i386 and amd64
> have different time?

Hello Nikos,
It is the same machine, different chroot. ;-) However the hint seems
to be a good one:

* The test succeeds with "datefudge '@1256803113' tests/chainverify".
* gnutls3 works
* Comparing chainverify in 2.12 with GIT master shows that the latter is
  using gnutls_global_set_time().

Looking at git head one sees that while gnutls_global_set_time was
added not only in master but also in gnutls_2_12_x, however
c0d9ae7f9444e828b17f68d34361ea9fe77fe6a0 in gnutls_2_12_x is missing
the changes to tests/chainverify which
6a125fea8d4ddb545a6c88dbab04b6ac26c183ab includes.

Adding this missing piece (see attachment) seems to work. Am I missing
something?

cu Andreas

gnutls_2_12_x
https://www.gitorious.org/gnutls/gnutls/commit/c0d9ae7f9444e828b17f68d34361ea9fe77fe6a0
master
https://www.gitorious.org/gnutls/gnutls/commit/6a125fea8d4ddb545a6c88dbab04b6ac26c183ab
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
-------------- next part --------------
A non-text attachment was scrubbed...
Name: use_gnutls_global_set_time.diff
Type: text/x-diff
Size: 604 bytes
Desc: not available
URL: </pipermail/attachments/20140427/2e8e8484/attachment.diff>

From nmav at gnutls.org  Mon Apr 28 10:17:18 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 28 Apr 2014 10:17:18 +0200
Subject: [gnutls-devel] no way to detect gnutls_global_init() failure in
	3.3
In-Reply-To: <53596DA9.6080801@gnome.org>
References: <53596DA9.6080801@gnome.org>
Message-ID: <CAJU7zaJstb_-3Y8uK6k-oWe9Cnx=De7Y5VJVhtM5HVY45Yz8iw@mail.gmail.com>

On Thu, Apr 24, 2014 at 10:01 PM, Dan Winship <danw at gnome.org> wrote:
> If gnutls_global_init() has been called before, it always returns 0,
> even if it failed the first time. Since it now gets called from a
> constructor, this means it will always return 0 when called from
> application code, even if it failed when called from the constructor.
> Probably it should save the original return value for future calls?

Thanks, that would be useful. I've now modified it to cache the
initial error code.

> (qv https://bugzilla.redhat.com/show_bug.cgi?id=1091053)

That may have to do with an issue that was fixed in 3.3.1. I'll follow up there.

regards,
Nikos


From wiredrat at gmail.com  Mon Apr 28 10:45:03 2014
From: wiredrat at gmail.com (=?UTF-8?Q?Marcos_Ag=C3=BCero?=)
Date: Mon, 28 Apr 2014 10:45:03 +0200
Subject: [gnutls-devel] segfault on gnutls_x509_crt_import
In-Reply-To: <1398617154.25589.23.camel@nomad.lan>
References: <CABD9f3NKWUn+cntkinP2Qgm6zmnJ4U==GujpSKhvdXZxCaBQzQ@mail.gmail.com>
 <1398617154.25589.23.camel@nomad.lan>
Message-ID: <CABD9f3NBoi8vKfDAFyoL7c7MNw1AACYV=uuhCqft15F2qpzjNA@mail.gmail.com>

Hi,
Iv'e reported to Ubuntu, on bug
https://bugs.launchpad.net/ubuntu/+source/curl/+bug/1310636 and was
accepted.
I created it under the "curl" package, however, they should change to
"libgnutls" package if needed.

Thanks!


2014-04-27 18:45 GMT+02:00 Nikos Mavrogiannopoulos <nmav at gnutls.org>:

> On Mon, 2014-04-21 at 16:34 +0200, Marcos Ag?ero wrote:
> > Hi,
>
> > While using libcurl with gnutls, on certain URL
> > hxxps://harrowmedia.com/ (WARNING! URL is known to host malware), i'm
> > getting unexpected segmentation fault. I'm not sure if it's related to
> > libcurl version or gnutls, but I suspect that is a malformed
> > certificate.
> >
> >
> > I'm using gnutls version 2.12.23-12ubuntu2 (latest ubuntu package)
>
> Hello Marcos,
>  This version is no longer supported. Please report it on the ubuntu bug
> tracker, or again here if the problem persists with a the latest stable
> branch.
>
> regards,
> Nikos
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20140428/6fbf00a4/attachment.html>

From nmav at gnutls.org  Mon Apr 28 11:42:02 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 28 Apr 2014 11:42:02 +0200
Subject: [gnutls-devel] gnutls-cli --dane
In-Reply-To: <m361m6jvh7.fsf@carbon.jhcloos.org>
References: <m361m6jvh7.fsf@carbon.jhcloos.org>
Message-ID: <CAJU7zaJ=+9Wgh4fakAxMzr5QPhsGcyi6pc7dKwNfqcZCMFQz3A@mail.gmail.com>

On Fri, Apr 18, 2014 at 9:19 PM, James Cloos <cloos at jhcloos.com> wrote:

> DANE says that verification succeeds if any of the TLSA records match.
> That language was chosen expressly to permit secure rollovers.

Hello,
 There was a patch in
https://savannah.gnu.org/support/?func=detailitem&item_id=108549
that should fix the issue you mention. It is now applied.

regards,
Nikos


From nmav at gnutls.org  Mon Apr 28 11:49:55 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 28 Apr 2014 11:49:55 +0200
Subject: [gnutls-devel] safe_renegotiation.c: 2 * possible cut'n'paste
	error
In-Reply-To: <DUB130-W36684D863C29C9158684C69C5B0@phx.gbl>
References: <DUB130-W36684D863C29C9158684C69C5B0@phx.gbl>
Message-ID: <CAJU7zaKvDQ9jCFM=_OZzYLgZRQN3N+D+1mk5R+5Gn7LErp1CUw@mail.gmail.com>

On Thu, Apr 24, 2014 at 10:23 PM, David Binderman <dcb314 at hotmail.com> wrote:
> Hello there,
>
> 1.
> [safe_renegotiation.c:204]: (style) Expression is always false because 'else if' condition matches previous condition at line 202.
>
>     if (ret < 0) {
>         set = 1;
>     } else if (ret < 0) {
>         gnutls_assert();
>         return ret;
>     }
>
> 2.
> [safe_renegotiation.c:241]: (style) Expression is always false because 'else if' condition matches previous condition at line 239.

Thank you. I've removed the redundant code.

regards,
Nikos


From asyourmind at gmail.com  Mon Apr 28 16:00:26 2014
From: asyourmind at gmail.com (Parklee)
Date: Mon, 28 Apr 2014 22:00:26 +0800
Subject: [gnutls-devel] openwrt used gnutls version3.2.12 with x86
 platform have something wrong.
In-Reply-To: <1398620453.1404.1.camel@nomad.lan>
References: <535B3F36.8000406@gmail.com>
	<1398620453.1404.1.camel@nomad.lan>
Message-ID: <CAKXHJ5hLT2ZO=rSMuO40kAjvhQK6_o6nYagibuDmE=gBMarX3A@mail.gmail.com>

Thanks.

with my best wishes
cl


2014-04-28 1:40 GMT+08:00 Nikos Mavrogiannopoulos <nmav at gnutls.org>:

> On Sat, 2014-04-26 at 13:08 +0800, cl wrote:
> > how can i fix it, plz help me. thx.
>
> That looks like a clash of the included x86.h with some openwrt header.
> See https://dev.openwrt.org/ticket/15555 for a possible fix.
>
> regards,
> Nikos
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20140428/58f114dd/attachment.html>

From nmav at gnutls.org  Mon Apr 28 16:02:21 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 28 Apr 2014 16:02:21 +0200
Subject: [gnutls-devel] gnutls 2.12.23 - chainverify testsuite failure
	on amd64
In-Reply-To: <20140427181056.GD2851@downhill.g.la>
References: <20140427150928.GC2851@downhill.g.la>
 <1398618198.25589.28.camel@nomad.lan>
 <20140427181056.GD2851@downhill.g.la>
Message-ID: <CAJU7za+TyQrML6h_5dd=iGHSnhyUQo-n5o-Xq4AQQoDPM1KgBw@mail.gmail.com>

On Sun, Apr 27, 2014 at 8:10 PM, Andreas Metzler <ametzler at bebt.de> wrote:

> * The test succeeds with "datefudge '@1256803113' tests/chainverify".
> * gnutls3 works
> * Comparing chainverify in 2.12 with GIT master shows that the latter is
>   using gnutls_global_set_time().
> Looking at git head one sees that while gnutls_global_set_time was
> added not only in master but also in gnutls_2_12_x, however
> c0d9ae7f9444e828b17f68d34361ea9fe77fe6a0 in gnutls_2_12_x is missing
> the changes to tests/chainverify which
> 6a125fea8d4ddb545a6c88dbab04b6ac26c183ab includes.
> Adding this missing piece (see attachment) seems to work. Am I missing
> something?

No, that would do.

regards,
Nikos