From ludo at gnu.org  Wed Mar  2 09:51:41 2016
From: ludo at gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=)
Date: Wed, 02 Mar 2016 09:51:41 +0100
Subject: [gnutls-devel] change in posting policy
In-Reply-To: <1456762195.1861.3.camel@gnutls.org> (Nikos Mavrogiannopoulos's
 message of "Mon, 29 Feb 2016 17:09:55 +0100")
References: <1456762195.1861.3.camel@gnutls.org>
Message-ID: <87si09jm8y.fsf@gnu.org>

Nikos Mavrogiannopoulos <nmav at gnutls.org> skribis:

>  Due to a large amount of spam received by the list, it is no longer
> practical to go through the list of held postings and approve them. As
> such, I've switched the posting policy to members only. 

Sigh.  lists.gnu.org did not have that drawback?

Ludo?.


From ludo at gnu.org  Wed Mar  2 10:01:31 2016
From: ludo at gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=)
Date: Wed, 02 Mar 2016 10:01:31 +0100
Subject: [gnutls-devel] [PATCH 0/8] Assorted Guile bindings improvements
In-Reply-To: <CAJU7zaJMYUbwW16uULRhJ=aF6FTkqb8dLWiYW4dWLZvK1=0mxg@mail.gmail.com>
 (Nikos Mavrogiannopoulos's message of "Mon, 22 Feb 2016 11:56:36
 +0100")
References: <1455228278-23708-1-git-send-email-ludo@gnu.org>
 <874md1x6f8.fsf@gnu.org>
 <CAJU7zaJMYUbwW16uULRhJ=aF6FTkqb8dLWiYW4dWLZvK1=0mxg@mail.gmail.com>
Message-ID: <87h9gpjlsk.fsf@gnu.org>

Nikos Mavrogiannopoulos <nmav at gnutls.org> skribis:

> On Sun, Feb 21, 2016 at 7:30 PM, Ludovic Court?s <ludo at gnu.org> wrote:
>> Ludovic Court?s <ludo at gnu.org> skribis:
>>> This is against master but could be applied to the 3.4 branch
>>> as well.
>> Thanks, Nikos, for pushing these patches to ?master?!
>> I can provide ?NEWS? entries for the changes, but I?d need to know in
>> which branch(es) to put them.  Thoughts?
>
> Hello Ludo,
>  I don't know. The details for each release are at:
> https://gitlab.com/gnutls/gnutls/milestones
>
> My plan is to have 3.5.0 in the next couple of months and will
> eventually replace the 3.4.x branch (since it will be backwards
> compatible).

OK, so let?s keep those Guile changes for 3.5.0.

Attached is a ?NEWS? update for master.  Thanks in advance!

Ludo?.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Update-NEWS.patch
Type: text/x-patch
Size: 1166 bytes
Desc: the patch
URL: </pipermail/attachments/20160302/63d0b115/attachment.bin>

From nmav at gnutls.org  Thu Mar  3 09:31:25 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 03 Mar 2016 09:31:25 +0100
Subject: [gnutls-devel] gnutls 3.4.10
Message-ID: <1456993885.2768.1.camel@gnutls.org>

Hello, 
 I've just released gnutls 3.4.10. This is a bug fix release of the
current stable branch.

* Version 3.4.10 (released 2016-03-03)

** libgnutls: Eliminated issues preventing buffers more than 2^32 bytes
   to be used with hashing functions.

** libgnutls: Corrected leaks and other issues in
   gnutls_x509_crt_list_import().

** libgnutls: Fixes in DSA key handling for PKCS #11. Report and 
   patches by Jan Vcelak.

** libgnutls: Several fixes to prevent relying on undefined behavior
   of C (found with libubsan).

** 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 compressed sources:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.10.tar.xz

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.10.tar.xz.sig

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

regards,
Nikos



From hecht at hlrs.de  Thu Mar  3 13:45:31 2016
From: hecht at hlrs.de (Martin Hecht)
Date: Thu, 3 Mar 2016 13:45:31 +0100
Subject: [gnutls-devel] change in posting policy
In-Reply-To: <87si09jm8y.fsf@gnu.org>
References: <1456762195.1861.3.camel@gnutls.org> <87si09jm8y.fsf@gnu.org>
Message-ID: <56D831EB.8060504@hlrs.de>

On 03/02/2016 09:51 AM, Ludovic Court?s wrote:
> Nikos Mavrogiannopoulos <nmav at gnutls.org> skribis:
>
>>  Due to a large amount of spam received by the list, it is no longer
>> practical to go through the list of held postings and approve them. As
>> such, I've switched the posting policy to members only. 
> Sigh.  lists.gnu.org did not have that drawback?
I think it's not a problem specific to the particular list.
We observe a strong increase of spam in general these days,
on several lists, and individual accounts also.

Martin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2252 bytes
Desc: S/MIME Cryptographic Signature
URL: </pipermail/attachments/20160303/470937d2/attachment.bin>

From ankitashukla707 at gmail.com  Fri Mar  4 18:26:32 2016
From: ankitashukla707 at gmail.com (Ankita Shukla)
Date: Fri, 4 Mar 2016 22:56:32 +0530
Subject: [gnutls-devel] p11tool error
Message-ID: <CAPJvrns0h8brpwg3WApkO9nc0bDxkBM-ZdV1nLyi8LQtcfgAGw@mail.gmail.com>

Hi,

I was trying to install tlspool in my system. I have been able to install
it as per the instructions given here. The next steps as given here
<https://github.com/arpa2/tlspool/blob/master/INSTALL#L82>, ask to cd into
testdata/ and run "make".
But every time, I run make in the testdata/ directory, I get this error
<http://pastebin.com/TH4nTTL7>.

The error says

Invalid option 'generate-rsa'

Try `p11tool --help' for more information.

while "man p11tool" does show --generate-rsa as an option for key
generation.

I tried googling this, but unfortunately not a lot of material is available
in this regard.

-- 
Thanks and Regards,

Ankita Shukla
Computer Science Engineering
B.Tech Final Year (Senior)
Indian Institute of Technology Roorkee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20160304/32451e38/attachment.html>

From ankitashukla707 at gmail.com  Fri Mar  4 18:29:26 2016
From: ankitashukla707 at gmail.com (Ankita Shukla)
Date: Fri, 4 Mar 2016 22:59:26 +0530
Subject: [gnutls-devel] p11tool error
In-Reply-To: <CAPJvrns0h8brpwg3WApkO9nc0bDxkBM-ZdV1nLyi8LQtcfgAGw@mail.gmail.com>
References: <CAPJvrns0h8brpwg3WApkO9nc0bDxkBM-ZdV1nLyi8LQtcfgAGw@mail.gmail.com>
Message-ID: <CAPJvrnuGZaHdqRrw8+eAKwp2AsWXjgSKkHqCtGCJm-G8c_5SJA@mail.gmail.com>

Hi,

I was trying to install tlspool in my system. I have been able to install
it as per the instructions given here. The next steps as given here
<https://github.com/arpa2/tlspool/blob/master/INSTALL#L82>, ask to cd into
testdata/ and run "make".
But every time, I run make in the testdata/ directory, I get this error
<http://pastebin.com/TH4nTTL7>.

The error says

Invalid option 'generate-rsa'

Try `p11tool --help' for more information.

while "man p11tool" does show --generate-rsa as an option for key
generation.

I tried googling this, but unfortunately not a lot of material is available
in this regard.

-- 
Thanks and Regards,

Ankita Shukla
Computer Science Engineering
B.Tech Final Year (Senior)
Indian Institute of Technology Roorkee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20160304/b0e22c7d/attachment.html>

From ametzler at bebt.de  Sat Mar  5 17:30:38 2016
From: ametzler at bebt.de (Andreas Metzler)
Date: Sat, 5 Mar 2016 17:30:38 +0100
Subject: [gnutls-devel] FTBFS[kfreebsd]: tests/mini-loss-time race
In-Reply-To: <CAJU7za+1cbOcBuwpgrVNbhUWGj19euQp2DQLkfMyFPR5x4hsHw@mail.gmail.com>
References: <20160214141422.GA27708@argenau.bebt.de>
 <CAJU7za+1cbOcBuwpgrVNbhUWGj19euQp2DQLkfMyFPR5x4hsHw@mail.gmail.com>
Message-ID: <20160305163038.GB4466@argenau.bebt.de>

Control: reopen 813598

On 2016-02-15 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> On Sun, Feb 14, 2016 at 3:14 PM, Andreas Metzler <ametzler at bebt.de> wrote:
> > this is http://bugs.debian.org/813598 reported by Steven Chamberlain:

> > gnutls28 tests/mini-loss-time fails about 20% of the time when I try it
> > on kfreebsd-amd64.  I think probably introduced by this commit:
> > https://gitlab.com/gnutls/gnutls/commit/e2a3ad31c487cbce997a08dddc55db639b60c024

> I've applied a similar fix in master.

Well with 3.4.10 the timeout does not seem to make any difference. Any of

gnutls_dtls_set_timeouts(session, 1 * 1000, 29 * 1000); [Steven's patch]
gnutls_dtls_set_timeouts(session, 1 * 1000, 30 * 1000); [3.4.10]
gnutls_dtls_set_timeouts(session, 1 * 1000, 29 * 1000);
                              [e6dcb14dbbd3e9e40a1f193a7bf6657e82b88cb9]

*always* fails on kfreebsd-amd64.

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 n.mavrogiannopoulos at gmail.com  Sat Mar  5 18:46:57 2016
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Sat, 05 Mar 2016 18:46:57 +0100
Subject: [gnutls-devel] FTBFS[kfreebsd]: tests/mini-loss-time race
In-Reply-To: <20160305163038.GB4466@argenau.bebt.de>
References: <20160214141422.GA27708@argenau.bebt.de>
 <CAJU7za+1cbOcBuwpgrVNbhUWGj19euQp2DQLkfMyFPR5x4hsHw@mail.gmail.com>
 <20160305163038.GB4466@argenau.bebt.de>
Message-ID: <1457200017.13877.2.camel@gmail.com>

On Sat, 2016-03-05 at 17:30 +0100, Andreas Metzler wrote:
> Control: reopen 813598
> 
> On 2016-02-15 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> > On Sun, Feb 14, 2016 at 3:14 PM, Andreas Metzler <ametzler at bebt.de> 
> > wrote:
> > > this is http://bugs.debian.org/813598 reported by Steven 
> > > Chamberlain:
> 
> > > gnutls28 tests/mini-loss-time fails about 20% of the time when I 
> > > try it
> > > on kfreebsd-amd64.  I think probably introduced by this commit:
> > > https://gitlab.com/gnutls/gnutls/commit/e2a3ad31c487cbce997a08ddd
> > > c55db639b60c024
> 
> > I've applied a similar fix in master.
> 
> Well with 3.4.10 the timeout does not seem to make any difference. 
> Any of
> 
> gnutls_dtls_set_timeouts(session, 1 * 1000, 29 * 1000); [Steven's 
> patch]
> gnutls_dtls_set_timeouts(session, 1 * 1000, 30 * 1000); [3.4.10]
> gnutls_dtls_set_timeouts(session, 1 * 1000, 29 * 1000);
>                              
>  [e6dcb14dbbd3e9e40a1f193a7bf6657e82b88cb9]
> *always* fails on kfreebsd-amd64.

Then the issue may have been different that what was initially thought.
It would be nice to have some debugging output of the failed test
(e.g., run with -v). Is that a 32-bit system? I'm wondering whether it
relates to the undefined behavior fixes.

regards,
Nikos



From steven at pyro.eu.org  Sat Mar  5 19:57:03 2016
From: steven at pyro.eu.org (Steven Chamberlain)
Date: Sat, 5 Mar 2016 18:57:03 +0000
Subject: [gnutls-devel] Bug#813598: FTBFS[kfreebsd]:
 tests/mini-loss-time race
In-Reply-To: <1457200017.13877.2.camel@gmail.com>
References: <20160214141422.GA27708@argenau.bebt.de>
 <CAJU7za+1cbOcBuwpgrVNbhUWGj19euQp2DQLkfMyFPR5x4hsHw@mail.gmail.com>
 <20160305163038.GB4466@argenau.bebt.de>
 <1457200017.13877.2.camel@gmail.com>
Message-ID: <20160305185703.GA83721@pyro.eu.org>

Hi Andreas,

In a future upload please could you try the attached diff, which is a
much simpler way I found to get the testsuite output into the build log.
Since more than one set of tests runs in parallel, we only currently see
the test-suite.log for one set of tests, and not all of them.

> On Sat, 2016-03-05 at 17:30 +0100, Andreas Metzler wrote:
> > Well with 3.4.10 the timeout does not seem to make any difference. 
> > Any of
> > 
> > gnutls_dtls_set_timeouts(session, 1 * 1000, 29 * 1000); [Steven's 
> > patch]

Your commit to the gnutls28 package in experimental
https://anonscm.debian.org/cgit/pkg-gnutls/gnutls.git/commit/?h=experimental&id=896b247a321271ab61ed1fce5065cadbd472c207
seems to do the opposite of my patch, it increases the server timeout?
My patch decreased it:  https://bugs.debian.org/813598#5

> > gnutls_dtls_set_timeouts(session, 1 * 1000, 30 * 1000); [3.4.10]
> > gnutls_dtls_set_timeouts(session, 1 * 1000, 29 * 1000); [e6dcb14dbbd3e9e40a1f193a7bf6657e82b88cb9]
> > *always* fails on kfreebsd-amd64.

If it fails _reliably_ now, I consider that an improvement!
I'll try to test all of the above and see how often each one fails.

Nikos Mavrogiannopoulos wrote:
> It would be nice to have some debugging output of the failed test
> (e.g., run with -v). Is that a 32-bit system? I'm wondering whether it
> relates to the undefined behavior fixes.

I've also attached a log of `tests/mini-loss-time -v`, from a
kfreebsd-amd64 system after I built Andreas' gnutls28/3.4.10-1 package
from experimental.

Thanks,
Regards,
-- 
Steven Chamberlain
steven at pyro.eu.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gnutls28.diff
Type: text/x-diff
Size: 572 bytes
Desc: not available
URL: </pipermail/attachments/20160305/664f3a23/attachment.diff>
-------------- next part --------------
0.000020 
0.141000 Will discard server packet 2
0.141029 client|<5>| REC[0x621b20]: Allocating epoch #0
0.141044 client|<3>| ASSERT: gnutls_constate.c:596
0.141057 client|<5>| REC[0x621b20]: Allocating epoch #1
0.141070 server|<5>| REC[0x621b20]: Allocating epoch #0
0.141084 client|<4>| HSK[0x621b20]: Keeping ciphersuite: GNUTLS_ECDH_ANON_AES_128_CBC_SHA1 (C0.18)
0.141098 client|<4>| HSK[0x621b20]: Keeping ciphersuite: GNUTLS_ECDH_ANON_AES_256_CBC_SHA1 (C0.19)
0.141111 client|<4>| HSK[0x621b20]: Keeping ciphersuite: GNUTLS_ECDH_ANON_3DES_EDE_CBC_SHA1 (C0.17)
0.141124 client|<4>| EXT[0x621b20]: Sending extension EXT MASTER SECRET (0 bytes)
0.141137 client|<4>| EXT[0x621b20]: Sending extension STATUS REQUEST (5 bytes)
0.141150 client|<4>| EXT[0x621b20]: Sending extension SAFE RENEGOTIATION (1 bytes)
0.141163 client|<4>| EXT[0x621b20]: Sending extension SESSION TICKET (0 bytes)
0.141177 client|<4>| EXT[0x621b20]: Sending extension SUPPORTED ECC (12 bytes)
0.141191 client|<4>| EXT[0x621b20]: Sending extension SUPPORTED ECC POINT FORMATS (2 bytes)
0.141204 client|<4>| HSK[0x621b20]: CLIENT HELLO was queued [104 bytes]
0.141217 client|<11>| HWRITE: enqueued [CLIENT HELLO] 104. Total 104 bytes.
0.141236 client|<11>| HWRITE FLUSH: 104 bytes in buffer.
0.141250 client|<6>| DTLS[0x621b20]: Start of flight transmission.
0.141263 client|<6>| DTLS[0x621b20]: Sending Packet[0] fragment CLIENT HELLO(1) with length: 92, offset: 0, fragment length: 92
0.141277 client|<5>| REC[0x621b20]: Preparing Packet Handshake(22) with length: 104 and min pad: 0
0.141291 client|<9>| ENC[0x621b20]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
0.141304 server|<3>| ASSERT: gnutls_constate.c:596
0.141316 client|<11>| WRITE: enqueued 117 bytes for 0x5. Total 117 bytes.
0.141329 server|<5>| REC[0x621b20]: Allocating epoch #1
0.141342 client|<5>| REC[0x621b20]: Sent Packet[1] Handshake(22) in epoch 0 and length: 117
0.141355 client|<11>| WRITE FLUSH: 117 bytes in buffer.
0.141369 client|<11>| WRITE: wrote 117 bytes, 0 bytes left.
0.141389 server|<3>| ASSERT: gnutls_buffers.c:1158
0.141405 server|<10>| READ: Got 117 bytes from 0x4
0.141423 server|<10>| READ: read 117 bytes from 0x4
0.141436 server|<10>| RB: Have 0 bytes into buffer. Adding 117 bytes.
0.141449 server|<10>| RB: Requested 13 bytes
0.141469 server|<5>| REC[0x621b20]: SSL 254.255 Handshake packet received. Epoch 0, length: 104
0.141482 server|<5>| REC[0x621b20]: Expected Packet Handshake(22)
0.141496 server|<5>| REC[0x621b20]: Received Packet Handshake(22) with length: 104
0.141509 server|<5>| REC[0x621b20]: Decrypted Packet[0.0] Handshake(22) with length: 104
0.141522 server|<13>| BUF[REC]: Inserted 104 bytes of Data(22)
0.141534 server|<4>| HSK[0x621b20]: CLIENT HELLO (1) was received. Length 92[92], frag offset 0, frag length: 92, sequence: 0
0.141547 server|<4>| HSK[0x621b20]: Client's version: 254.255
0.141560 server|<4>| HSK[0x621b20]: Selected version DTLS1.0
0.141574 server|<3>| ASSERT: gnutls_db.c:263
0.141586 server|<4>| EXT[0x621b20]: Found extension 'EXT MASTER SECRET/23'
0.141600 server|<4>| EXT[0x621b20]: Found extension 'STATUS REQUEST/5'
0.141615 server|<4>| EXT[0x621b20]: Found extension 'SAFE RENEGOTIATION/65281'
0.141628 server|<4>| EXT[0x621b20]: Found extension 'SESSION TICKET/35'
0.141641 server|<4>| EXT[0x621b20]: Found extension 'SUPPORTED ECC/10'
0.141654 server|<4>| EXT[0x621b20]: Found extension 'SUPPORTED ECC POINT FORMATS/11'
0.141672 server|<4>| EXT[0x621b20]: Parsing extension 'EXT MASTER SECRET/23' (0 bytes)
0.141685 server|<4>| EXT[0x621b20]: Found extension 'STATUS REQUEST/5'
0.141698 server|<4>| EXT[0x621b20]: Parsing extension 'SAFE RENEGOTIATION/65281' (1 bytes)
0.141712 server|<4>| EXT[0x621b20]: Parsing extension 'SESSION TICKET/35' (0 bytes)
0.141725 server|<4>| EXT[0x621b20]: Found extension 'SUPPORTED ECC/10'
0.141738 server|<4>| EXT[0x621b20]: Found extension 'SUPPORTED ECC POINT FORMATS/11'
0.141750 server|<4>| EXT[0x621b20]: Found extension 'EXT MASTER SECRET/23'
0.141763 server|<4>| EXT[0x621b20]: Parsing extension 'STATUS REQUEST/5' (5 bytes)
0.141776 server|<4>| EXT[0x621b20]: Found extension 'SAFE RENEGOTIATION/65281'
0.141862 server|<4>| EXT[0x621b20]: Found extension 'SESSION TICKET/35'
0.141936 server|<4>| EXT[0x621b20]: Parsing extension 'SUPPORTED ECC/10' (12 bytes)
0.141951 server|<4>| HSK[0x621b20]: Selected ECC curve SECP256R1 (2)
0.141964 server|<4>| EXT[0x621b20]: Parsing extension 'SUPPORTED ECC POINT FORMATS/11' (2 bytes)
0.141977 server|<4>| HSK[0x621b20]: Keeping ciphersuite: GNUTLS_ECDH_ANON_AES_128_CBC_SHA1 (C0.18)
0.141991 server|<4>| HSK[0x621b20]: Keeping ciphersuite: GNUTLS_ECDH_ANON_AES_256_CBC_SHA1 (C0.19)
0.142003 server|<4>| HSK[0x621b20]: Keeping ciphersuite: GNUTLS_ECDH_ANON_3DES_EDE_CBC_SHA1 (C0.17)
0.142016 server|<4>| HSK[0x621b20]: Requested cipher suites[size: 6]: 
0.142029 server|<4>| 	0xc0, 0x18 ECDH_ANON_AES_128_CBC_SHA1
0.142042 server|<4>| HSK[0x621b20]: Selected cipher suite: ECDH_ANON_AES_128_CBC_SHA1
0.142055 server|<4>| HSK[0x621b20]: Selected Compression Method: NULL
0.142068 server|<4>| HSK[0x621b20]: Safe renegotiation succeeded
0.142080 server|<4>| EXT[0x621b20]: Sending extension EXT MASTER SECRET (0 bytes)
0.142093 server|<3>| ASSERT: status_request.c:215
0.142105 server|<4>| EXT[0x621b20]: Sending extension SAFE RENEGOTIATION (1 bytes)
0.142118 server|<4>| EXT[0x621b20]: Sending extension SUPPORTED ECC POINT FORMATS (2 bytes)
0.142131 server|<4>| HSK[0x621b20]: SessionID: 24a5fefe8afb4aa2d197cc025b49579abe5c93323e7d90cb04d19af4dd59ef98
0.142143 server|<4>| HSK[0x621b20]: SERVER HELLO was queued [99 bytes]
0.142156 server|<11>| HWRITE: enqueued [SERVER HELLO] 99. Total 99 bytes.
0.142168 server|<4>| HSK[0x621b20]: SERVER KEY EXCHANGE was queued [81 bytes]
0.142181 server|<11>| HWRITE: enqueued [SERVER KEY EXCHANGE] 81. Total 180 bytes.
0.142194 server|<4>| HSK[0x621b20]: SERVER HELLO DONE was queued [12 bytes]
0.142206 server|<11>| HWRITE: enqueued [SERVER HELLO DONE] 12. Total 192 bytes.
0.142219 server|<11>| HWRITE FLUSH: 192 bytes in buffer.
0.142232 server|<6>| DTLS[0x621b20]: Start of flight transmission.
0.142245 server|<6>| DTLS[0x621b20]: Sending Packet[0] fragment SERVER HELLO(2) with length: 87, offset: 0, fragment length: 87
0.142258 server|<5>| REC[0x621b20]: Preparing Packet Handshake(22) with length: 99 and min pad: 0
0.142271 server|<9>| ENC[0x621b20]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
0.142284 server|<11>| WRITE: enqueued 112 bytes for 0x4. Total 112 bytes.
0.142296 server|<5>| REC[0x621b20]: Sent Packet[1] Handshake(22) in epoch 0 and length: 112
0.142309 server|<6>| DTLS[0x621b20]: Sending Packet[1] fragment SERVER KEY EXCHANGE(12) with length: 69, offset: 0, fragment length: 69
0.142324 server|<5>| REC[0x621b20]: Preparing Packet Handshake(22) with length: 81 and min pad: 0
0.142337 server|<9>| ENC[0x621b20]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
0.142349 server|<11>| WRITE: enqueued 94 bytes for 0x4. Total 206 bytes.
0.142362 server|<5>| REC[0x621b20]: Sent Packet[2] Handshake(22) in epoch 0 and length: 94
0.142375 server|<6>| DTLS[0x621b20]: Sending Packet[2] fragment SERVER HELLO DONE(14) with length: 0, offset: 0, fragment length: 0
0.142387 server|<5>| REC[0x621b20]: Preparing Packet Handshake(22) with length: 12 and min pad: 0
0.142400 server|<9>| ENC[0x621b20]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
0.142412 server|<11>| WRITE: enqueued 25 bytes for 0x4. Total 231 bytes.
0.142426 server|<5>| REC[0x621b20]: Sent Packet[3] Handshake(22) in epoch 0 and length: 25
0.142439 server|<11>| WRITE FLUSH: 231 bytes in buffer.
0.142452 Discarding packet 2: Server Key exchange
0.142470 Discarding packet 1: Server Hello Done
0.142483 server|<11>| WRITE: wrote 231 bytes, 0 bytes left.
0.142495 client|<10>| READ: Got 112 bytes from 0x5
0.142508 client|<10>| READ: read 112 bytes from 0x5
0.142521 client|<10>| RB: Have 0 bytes into buffer. Adding 112 bytes.
0.142533 client|<10>| RB: Requested 13 bytes
0.142549 client|<5>| REC[0x621b20]: SSL 254.255 Handshake packet received. Epoch 0, length: 99
0.142562 client|<5>| REC[0x621b20]: Expected Packet Handshake(22)
0.142575 client|<5>| REC[0x621b20]: Received Packet Handshake(22) with length: 99
0.142588 client|<5>| REC[0x621b20]: Decrypted Packet[0.0] Handshake(22) with length: 99
0.142600 client|<13>| BUF[REC]: Inserted 99 bytes of Data(22)
0.142613 client|<4>| HSK[0x621b20]: SERVER HELLO (2) was received. Length 87[87], frag offset 0, frag length: 87, sequence: 0
0.142635 client|<6>| DTLS[0x621b20]: End of flight transmission.
0.142649 client|<3>| ASSERT: gnutls_buffers.c:1115
0.142661 client|<3>| ASSERT: gnutls_buffers.c:1374
0.142674 client|<3>| ASSERT: gnutls_buffers.c:1374
0.142687 client|<4>| HSK[0x621b20]: Server's version: 254.255
0.142699 client|<4>| HSK[0x621b20]: SessionID length: 32
0.142712 client|<4>| HSK[0x621b20]: SessionID: 24a5fefe8afb4aa2d197cc025b49579abe5c93323e7d90cb04d19af4dd59ef98
0.142725 client|<4>| HSK[0x621b20]: Selected cipher suite: ECDH_ANON_AES_128_CBC_SHA1
0.142738 client|<4>| HSK[0x621b20]: Selected compression method: NULL (0)
0.142751 client|<4>| EXT[0x621b20]: Parsing extension 'EXT MASTER SECRET/23' (0 bytes)
0.142763 client|<4>| EXT[0x621b20]: Parsing extension 'SAFE RENEGOTIATION/65281' (1 bytes)
0.142776 client|<4>| EXT[0x621b20]: Parsing extension 'SUPPORTED ECC POINT FORMATS/11' (2 bytes)
0.142789 client|<4>| HSK[0x621b20]: Safe renegotiation succeeded
0.142801 client|<3>| ASSERT: gnutls_buffers.c:1158
1.020882 server|<6>| DTLS[0x621b20]: re-Start of flight transmission.
1.021037 server|<6>| DTLS[0x621b20]: Sending Packet[0] fragment SERVER HELLO(2) with length: 87, offset: 0, fragment length: 87
1.021136 server|<5>| REC[0x621b20]: Preparing Packet Handshake(22) with length: 99 and min pad: 0
1.021150 server|<9>| ENC[0x621b20]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
1.021165 server|<11>| WRITE: enqueued 112 bytes for 0x4. Total 112 bytes.
1.021178 server|<5>| REC[0x621b20]: Sent Packet[4] Handshake(22) in epoch 0 and length: 112
1.021192 server|<6>| DTLS[0x621b20]: Sending Packet[1] fragment SERVER KEY EXCHANGE(12) with length: 69, offset: 0, fragment length: 69
1.021205 server|<5>| REC[0x621b20]: Preparing Packet Handshake(22) with length: 81 and min pad: 0
1.021219 server|<9>| ENC[0x621b20]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
1.021232 server|<11>| WRITE: enqueued 94 bytes for 0x4. Total 206 bytes.
1.021245 server|<5>| REC[0x621b20]: Sent Packet[5] Handshake(22) in epoch 0 and length: 94
1.021259 server|<6>| DTLS[0x621b20]: Sending Packet[2] fragment SERVER HELLO DONE(14) with length: 0, offset: 0, fragment length: 0
1.021273 server|<5>| REC[0x621b20]: Preparing Packet Handshake(22) with length: 12 and min pad: 0
1.021287 server|<9>| ENC[0x621b20]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
1.021300 server|<11>| WRITE: enqueued 25 bytes for 0x4. Total 231 bytes.
1.021313 server|<5>| REC[0x621b20]: Sent Packet[6] Handshake(22) in epoch 0 and length: 25
1.021326 server|<11>| WRITE FLUSH: 231 bytes in buffer.
1.021339 Discarding packet 1: Server Hello
1.021354 Discarding packet 1: Server Key exchange
1.021367 Discarding packet 1: Server Hello Done
1.021379 server|<11>| WRITE: wrote 231 bytes, 0 bytes left.
2.025506 server|<11>| WRITE FLUSH: 0 bytes in buffer.
2.025634 server|<3>| ASSERT: gnutls_buffers.c:695
4.034434 server|<6>| DTLS[0x621b20]: re-Start of flight transmission.
4.034562 server|<6>| DTLS[0x621b20]: Sending Packet[0] fragment SERVER HELLO(2) with length: 87, offset: 0, fragment length: 87
4.034581 server|<5>| REC[0x621b20]: Preparing Packet Handshake(22) with length: 99 and min pad: 0
4.034597 server|<9>| ENC[0x621b20]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
4.034610 server|<11>| WRITE: enqueued 112 bytes for 0x4. Total 112 bytes.
4.034622 server|<5>| REC[0x621b20]: Sent Packet[7] Handshake(22) in epoch 0 and length: 112
4.034635 server|<6>| DTLS[0x621b20]: Sending Packet[1] fragment SERVER KEY EXCHANGE(12) with length: 69, offset: 0, fragment length: 69
4.034648 server|<5>| REC[0x621b20]: Preparing Packet Handshake(22) with length: 81 and min pad: 0
4.034661 server|<9>| ENC[0x621b20]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
4.034673 server|<11>| WRITE: enqueued 94 bytes for 0x4. Total 206 bytes.
4.034686 server|<5>| REC[0x621b20]: Sent Packet[8] Handshake(22) in epoch 0 and length: 94
4.034701 server|<6>| DTLS[0x621b20]: Sending Packet[2] fragment SERVER HELLO DONE(14) with length: 0, offset: 0, fragment length: 0
4.034714 server|<5>| REC[0x621b20]: Preparing Packet Handshake(22) with length: 12 and min pad: 0
4.034727 server|<9>| ENC[0x621b20]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
4.034741 server|<11>| WRITE: enqueued 25 bytes for 0x4. Total 231 bytes.
4.034754 server|<5>| REC[0x621b20]: Sent Packet[9] Handshake(22) in epoch 0 and length: 25
4.034767 server|<11>| WRITE FLUSH: 231 bytes in buffer.
4.034789 Discarding packet 1: Server Hello
4.034805 Discarding packet 1: Server Key exchange
4.034818 Discarding packet 1: Server Hello Done
4.034832 server|<11>| WRITE: wrote 231 bytes, 0 bytes left.
6.035732 server|<11>| WRITE FLUSH: 0 bytes in buffer.
6.035850 server|<3>| ASSERT: gnutls_buffers.c:695
10.051089 server|<6>| DTLS[0x621b20]: re-Start of flight transmission.
10.051208 server|<6>| DTLS[0x621b20]: Sending Packet[0] fragment SERVER HELLO(2) with length: 87, offset: 0, fragment length: 87
10.051223 server|<5>| REC[0x621b20]: Preparing Packet Handshake(22) with length: 99 and min pad: 0
10.051237 server|<9>| ENC[0x621b20]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
10.051250 server|<11>| WRITE: enqueued 112 bytes for 0x4. Total 112 bytes.
10.051262 server|<5>| REC[0x621b20]: Sent Packet[10] Handshake(22) in epoch 0 and length: 112
10.051275 server|<6>| DTLS[0x621b20]: Sending Packet[1] fragment SERVER KEY EXCHANGE(12) with length: 69, offset: 0, fragment length: 69
10.051288 server|<5>| REC[0x621b20]: Preparing Packet Handshake(22) with length: 81 and min pad: 0
10.051301 server|<9>| ENC[0x621b20]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
10.051314 server|<11>| WRITE: enqueued 94 bytes for 0x4. Total 206 bytes.
10.051327 server|<5>| REC[0x621b20]: Sent Packet[11] Handshake(22) in epoch 0 and length: 94
10.051340 server|<6>| DTLS[0x621b20]: Sending Packet[2] fragment SERVER HELLO DONE(14) with length: 0, offset: 0, fragment length: 0
10.051353 server|<5>| REC[0x621b20]: Preparing Packet Handshake(22) with length: 12 and min pad: 0
10.051366 server|<9>| ENC[0x621b20]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
10.051379 server|<11>| WRITE: enqueued 25 bytes for 0x4. Total 231 bytes.
10.051392 server|<5>| REC[0x621b20]: Sent Packet[12] Handshake(22) in epoch 0 and length: 25
10.051405 server|<11>| WRITE FLUSH: 231 bytes in buffer.
10.051418 Discarding packet 1: Server Hello
10.051431 Discarding packet 1: Server Key exchange
10.051444 Discarding packet 1: Server Hello Done
10.051465 server|<11>| WRITE: wrote 231 bytes, 0 bytes left.
14.056767 server|<11>| WRITE FLUSH: 0 bytes in buffer.
14.056890 server|<3>| ASSERT: gnutls_buffers.c:695
22.065525 server|<6>| DTLS[0x621b20]: re-Start of flight transmission.
22.065645 server|<6>| DTLS[0x621b20]: Sending Packet[0] fragment SERVER HELLO(2) with length: 87, offset: 0, fragment length: 87
22.065665 server|<5>| REC[0x621b20]: Preparing Packet Handshake(22) with length: 99 and min pad: 0
22.065679 server|<9>| ENC[0x621b20]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
22.065692 server|<11>| WRITE: enqueued 112 bytes for 0x4. Total 112 bytes.
22.065705 server|<5>| REC[0x621b20]: Sent Packet[13] Handshake(22) in epoch 0 and length: 112
22.065718 server|<6>| DTLS[0x621b20]: Sending Packet[1] fragment SERVER KEY EXCHANGE(12) with length: 69, offset: 0, fragment length: 69
22.065731 server|<5>| REC[0x621b20]: Preparing Packet Handshake(22) with length: 81 and min pad: 0
22.065743 server|<9>| ENC[0x621b20]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
22.065756 server|<11>| WRITE: enqueued 94 bytes for 0x4. Total 206 bytes.
22.065769 server|<5>| REC[0x621b20]: Sent Packet[14] Handshake(22) in epoch 0 and length: 94
22.065781 server|<6>| DTLS[0x621b20]: Sending Packet[2] fragment SERVER HELLO DONE(14) with length: 0, offset: 0, fragment length: 0
22.065795 server|<5>| REC[0x621b20]: Preparing Packet Handshake(22) with length: 12 and min pad: 0
22.065808 server|<9>| ENC[0x621b20]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
22.065821 server|<11>| WRITE: enqueued 25 bytes for 0x4. Total 231 bytes.
22.065834 server|<5>| REC[0x621b20]: Sent Packet[15] Handshake(22) in epoch 0 and length: 25
22.065848 server|<11>| WRITE FLUSH: 231 bytes in buffer.
22.065861 Discarding packet 1: Server Hello
22.065875 Discarding packet 1: Server Key exchange
22.065887 Discarding packet 1: Server Hello Done
22.065900 server|<11>| WRITE: wrote 231 bytes, 0 bytes left.
30.067663 server|<6>| Session timeout: 30102 ms
30.067793 server|<3>| ASSERT: gnutls_dtls.c:294
30.067812 server|<6>| DTLS[0x621b20]: End of flight transmission.
30.067826 server|<3>| ASSERT: gnutls_handshake.c:3193
30.067839 server|<5>| REC[0x621b20]: Start of epoch cleanup
30.067852 server|<5>| REC[0x621b20]: End of epoch cleanup
30.067865 server|<5>| REC[0x621b20]: Epoch #0 freed
30.067878 server|<5>| REC[0x621b20]: Epoch #1 freed
30.067890 server received timeout
30.068681 client|<10>| READ_TIMEOUT: -1 returned from 0x5, errno=4 (timeout: 31000)
30.068747 client|<3>| ASSERT: gnutls_buffers.c:252
30.068760 client|<3>| ASSERT: gnutls_buffers.c:588
30.068776 client|<3>| ASSERT: gnutls_kx.c:463
30.122652 client|<3>| ASSERT: gnutls_buffers.c:1158
30.122731 client|<10>| READ: -1 returned from 0x5, errno=54
30.122749 client|<3>| ASSERT: gnutls_buffers.c:228
30.122764 client|<3>| ASSERT: gnutls_buffers.c:588
30.122777 client|<3>| ASSERT: gnutls_record.c:1038
30.122790 client|<3>| ASSERT: gnutls_record.c:1158
30.122803 client|<3>| ASSERT: gnutls_buffers.c:1409
30.122816 client|<3>| ASSERT: gnutls_handshake.c:1446
30.122829 client|<3>| ASSERT: gnutls_kx.c:463
30.122841 client|<3>| ASSERT: gnutls_handshake.c:2798
30.122854 client|<5>| REC[0x621b20]: Start of epoch cleanup
30.122867 client|<5>| REC[0x621b20]: End of epoch cleanup
30.122881 client|<5>| REC[0x621b20]: Epoch #0 freed
30.122911 client|<5>| REC[0x621b20]: Epoch #1 freed
30.122928 client: Handshake failed with unexpected reason: Error in the push function.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: </pipermail/attachments/20160305/664f3a23/attachment.sig>

From ametzler at bebt.de  Sun Mar  6 07:25:41 2016
From: ametzler at bebt.de (Andreas Metzler)
Date: Sun, 6 Mar 2016 07:25:41 +0100
Subject: [gnutls-devel] Bug#813598: FTBFS[kfreebsd]:
	tests/mini-loss-time race
In-Reply-To: <1457200017.13877.2.camel@gmail.com>
References: <20160214141422.GA27708@argenau.bebt.de>
 <CAJU7za+1cbOcBuwpgrVNbhUWGj19euQp2DQLkfMyFPR5x4hsHw@mail.gmail.com>
 <20160305163038.GB4466@argenau.bebt.de>
 <1457200017.13877.2.camel@gmail.com>
Message-ID: <20160306062541.GB1239@argenau.bebt.de>

On 2016-03-05 Nikos Mavrogiannopoulos <n.mavrogiannopoulos at gmail.com> wrote:
> On Sat, 2016-03-05 at 17:30 +0100, Andreas Metzler wrote:
[...]
>> Well with 3.4.10 the timeout does not seem to make any difference. 
>> Any of

>> gnutls_dtls_set_timeouts(session, 1 * 1000, 29 * 1000); [Steven's 
>> patch]
>> gnutls_dtls_set_timeouts(session, 1 * 1000, 30 * 1000); [3.4.10]
>> gnutls_dtls_set_timeouts(session, 1 * 1000, 29 * 1000);
                             
>>  [e6dcb14dbbd3e9e40a1f193a7bf6657e82b88cb9]
>> *always* fails on kfreebsd-amd64.

> Then the issue may have been different that what was initially thought.
> It would be nice to have some debugging output of the failed test
> (e.g., run with -v). Is that a 32-bit system? I'm wondering whether it
> relates to the undefined behavior fixes.

Hello,

this was on kfreebsd-amd64 but it also fails on kfreebsd-i386. Steven
has posted the -v output. (Which is lucky since the respective Debian
porter machine has become unreachable overnight.)

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 n.mavrogiannopoulos at gmail.com  Mon Mar  7 09:26:16 2016
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Mon, 7 Mar 2016 09:26:16 +0100
Subject: [gnutls-devel] Bug#813598: FTBFS[kfreebsd]:
	tests/mini-loss-time race
In-Reply-To: <20160305185703.GA83721@pyro.eu.org>
References: <20160214141422.GA27708@argenau.bebt.de>
 <CAJU7za+1cbOcBuwpgrVNbhUWGj19euQp2DQLkfMyFPR5x4hsHw@mail.gmail.com>
 <20160305163038.GB4466@argenau.bebt.de> <1457200017.13877.2.camel@gmail.com>
 <20160305185703.GA83721@pyro.eu.org>
Message-ID: <CAJU7za+TeBdxZd3b1TbhWw-p4RAo3OXDORMzyxPnDvUSMq6YTw@mail.gmail.com>

On Sat, Mar 5, 2016 at 7:57 PM, Steven Chamberlain <steven at pyro.eu.org> wrote:
> Hi Andreas,
>
> In a future upload please could you try the attached diff, which is a
> much simpler way I found to get the testsuite output into the build log.
> Since more than one set of tests runs in parallel, we only currently see
> the test-suite.log for one set of tests, and not all of them.
>
>> On Sat, 2016-03-05 at 17:30 +0100, Andreas Metzler wrote:
>> > Well with 3.4.10 the timeout does not seem to make any difference.
>> > Any of
>> > gnutls_dtls_set_timeouts(session, 1 * 1000, 29 * 1000); [Steven's
>> > patch]
>
> Your commit to the gnutls28 package in experimental
> https://anonscm.debian.org/cgit/pkg-gnutls/gnutls.git/commit/?h=experimental&id=896b247a321271ab61ed1fce5065cadbd472c207
> seems to do the opposite of my patch, it increases the server timeout?
> My patch decreased it:  https://bugs.debian.org/813598#5
>
>> > gnutls_dtls_set_timeouts(session, 1 * 1000, 30 * 1000); [3.4.10]
>> > gnutls_dtls_set_timeouts(session, 1 * 1000, 29 * 1000); [e6dcb14dbbd3e9e40a1f193a7bf6657e82b88cb9]
>> > *always* fails on kfreebsd-amd64.
>
> If it fails _reliably_ now, I consider that an improvement!
> I'll try to test all of the above and see how often each one fails.

That's quite interesting. It seems that the child times out first and
closes the connection prior to parent detecting the timeout. Would the
attached patch solve the issue?

regards,
Nikos
-------------- next part --------------
diff --git a/tests/mini-loss-time.c b/tests/mini-loss-time.c
index 13de21e..8145657 100644
--- a/tests/mini-loss-time.c
+++ b/tests/mini-loss-time.c
@@ -116,7 +116,7 @@ push(gnutls_transport_ptr_t tr, const void *data, size_t len)
 	return send(fd, data, len, 0);
 }
 
-static void client(int fd)
+static void client(int fd, unsigned timeout)
 {
 	int ret;
 	gnutls_anon_client_credentials_t anoncred;
@@ -136,7 +136,7 @@ static void client(int fd)
 	 */
 	gnutls_init(&session, GNUTLS_CLIENT | GNUTLS_DATAGRAM);
 	gnutls_dtls_set_mtu(session, 1500);
-	gnutls_dtls_set_timeouts(session, 1 * 1000, 30 * 1000);
+	gnutls_dtls_set_timeouts(session, 1 * 1000, timeout * 1000);
 
 	/* Use default priorities */
 	gnutls_priority_set_direct(session,
@@ -178,7 +178,7 @@ static void client(int fd)
 /* These are global */
 pid_t child;
 
-static void server(int fd, int packet)
+static void server(int fd, int packet, unsigned timeout)
 {
 	gnutls_anon_server_credentials_t anoncred;
 	gnutls_session_t session;
@@ -196,7 +196,7 @@ static void server(int fd, int packet)
 
 	gnutls_init(&session, GNUTLS_SERVER | GNUTLS_DATAGRAM);
 	gnutls_dtls_set_mtu(session, 1500);
-	gnutls_dtls_set_timeouts(session, 1 * 1000, 30 * 1000);
+	gnutls_dtls_set_timeouts(session, 1 * 1000, timeout * 1000);
 
 	/* avoid calling all the priority functions, since the defaults
 	 * are adequate.
@@ -265,17 +265,17 @@ static void start(int server_packet, int wait_server)
 		/* parent */
 		close(fd[0]);
 		if (wait_server)
-			server(fd[1], server_packet);
+			server(fd[1], server_packet, 30);
 		else
-			client(fd[1]);
+			client(fd[1], 30);
 		close(fd[1]);
 		kill(child, SIGTERM);
 	} else {
 		close(fd[1]);
 		if (wait_server)
-			client(fd[0]);
+			client(fd[0], 32);
 		else
-			server(fd[0], server_packet);
+			server(fd[0], server_packet, 32);
 		close(fd[0]);
 		exit(0);
 	}

From ametzler at bebt.de  Mon Mar  7 19:27:56 2016
From: ametzler at bebt.de (Andreas Metzler)
Date: Mon, 7 Mar 2016 19:27:56 +0100
Subject: [gnutls-devel] Bug#813598: FTBFS[kfreebsd]:
	tests/mini-loss-time race
In-Reply-To: <CAJU7za+TeBdxZd3b1TbhWw-p4RAo3OXDORMzyxPnDvUSMq6YTw@mail.gmail.com>
References: <20160214141422.GA27708@argenau.bebt.de>
 <CAJU7za+1cbOcBuwpgrVNbhUWGj19euQp2DQLkfMyFPR5x4hsHw@mail.gmail.com>
 <20160305163038.GB4466@argenau.bebt.de>
 <1457200017.13877.2.camel@gmail.com>
 <20160305185703.GA83721@pyro.eu.org>
 <CAJU7za+TeBdxZd3b1TbhWw-p4RAo3OXDORMzyxPnDvUSMq6YTw@mail.gmail.com>
Message-ID: <20160307182756.GA1314@argenau.bebt.de>

On 2016-03-07 Nikos Mavrogiannopoulos <n.mavrogiannopoulos at gmail.com> wrote:
> On Sat, Mar 5, 2016 at 7:57 PM, Steven Chamberlain <steven at pyro.eu.org> wrote:
[...]
> > If it fails _reliably_ now, I consider that an improvement!
> > I'll try to test all of the above and see how often each one fails.

> That's quite interesting. It seems that the child times out first and
> closes the connection prior to parent detecting the timeout. Would the
> attached patch solve the issue?

It worked for me. I will upload and let the autobuilders give it a try.

thanks, cu Andreas



From steven at pyro.eu.org  Mon Mar  7 21:41:22 2016
From: steven at pyro.eu.org (Steven Chamberlain)
Date: Mon, 7 Mar 2016 20:41:22 +0000
Subject: [gnutls-devel] Bug#813598: FTBFS[kfreebsd]:
 tests/mini-loss-time race
In-Reply-To: <CAJU7za+TeBdxZd3b1TbhWw-p4RAo3OXDORMzyxPnDvUSMq6YTw@mail.gmail.com>
References: <20160214141422.GA27708@argenau.bebt.de>
 <CAJU7za+1cbOcBuwpgrVNbhUWGj19euQp2DQLkfMyFPR5x4hsHw@mail.gmail.com>
 <20160305163038.GB4466@argenau.bebt.de>
 <1457200017.13877.2.camel@gmail.com>
 <20160305185703.GA83721@pyro.eu.org>
 <CAJU7za+TeBdxZd3b1TbhWw-p4RAo3OXDORMzyxPnDvUSMq6YTw@mail.gmail.com>
Message-ID: <20160307204122.GA94706@pyro.eu.org>

Hi,

Nikos Mavrogiannopoulos wrote:
> That's quite interesting. It seems that the child times out first and
> closes the connection prior to parent detecting the timeout. Would the
> attached patch solve the issue?

That works reliably for me now on kfreebsd-amd64, thank you very much!
It also has built on the Debian buildds:
https://buildd.debian.org/status/package.php?p=gnutls28&suite=experimental
Let me know if you have any other questions.

I've began to do daily builds of gnutls Git on kfreebsd-amd64:
http://jenkins.kfreebsd.eu/jenkins/job/upstream_gnutls28/9/console

Regards,
-- 
Steven Chamberlain
steven at pyro.eu.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: </pipermail/attachments/20160307/fc62d532/attachment.sig>

From jan.vcelak at nic.cz  Tue Mar  8 14:56:45 2016
From: jan.vcelak at nic.cz (=?UTF-8?Q?Jan_V=c4=8delak?=)
Date: Tue, 8 Mar 2016 14:56:45 +0100
Subject: [gnutls-devel] gnutls 3.4.10
In-Reply-To: <1456993885.2768.1.camel@gnutls.org>
References: <1456993885.2768.1.camel@gnutls.org>
Message-ID: <56DEDA1D.30905@nic.cz>

On 3.3.2016 09:31, Nikos Mavrogiannopoulos wrote:
> ** libgnutls: Fixes in DSA key handling for PKCS #11. Report and 
>    patches by Jan Vcelak.

The DSA keys still cannot be generated in the PKCS #11 token. I've
checked the tarball and it seems that the following patch from master
was not included: f9840c85dcbf9c6ad1bf53dc943a860bdb819dfe

Cheers,

Jan


From nmav at gnutls.org  Tue Mar  8 15:09:22 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 8 Mar 2016 15:09:22 +0100
Subject: [gnutls-devel] gnutls 3.4.10
In-Reply-To: <56DEDA1D.30905@nic.cz>
References: <1456993885.2768.1.camel@gnutls.org> <56DEDA1D.30905@nic.cz>
Message-ID: <CAJU7zaKn0srjnLS8LJgFhUADz5a5R5ZF9yTCwMoT1V9LrDSCdA@mail.gmail.com>

On Tue, Mar 8, 2016 at 2:56 PM, Jan V?elak <jan.vcelak at nic.cz> wrote:
> On 3.3.2016 09:31, Nikos Mavrogiannopoulos wrote:
>> ** libgnutls: Fixes in DSA key handling for PKCS #11. Report and
>>    patches by Jan Vcelak.
> The DSA keys still cannot be generated in the PKCS #11 token. I've
> checked the tarball and it seems that the following patch from master
> was not included: f9840c85dcbf9c6ad1bf53dc943a860bdb819dfe

It seems I relied on the test suite, but the tests did not fail if
they don't work :(
The RETCODE path was to continue the tests even on old softhsm which
did not support certain functionality. I'll see to merge that and
eliminate the retcode path in testpkcs11.sh.

regards,
Nikos


From jan.vcelak at nic.cz  Tue Mar  8 15:34:23 2016
From: jan.vcelak at nic.cz (=?UTF-8?Q?Jan_V=c4=8delak?=)
Date: Tue, 8 Mar 2016 15:34:23 +0100
Subject: [gnutls-devel] gnutls 3.4.10
In-Reply-To: <CAJU7zaKn0srjnLS8LJgFhUADz5a5R5ZF9yTCwMoT1V9LrDSCdA@mail.gmail.com>
References: <1456993885.2768.1.camel@gnutls.org> <56DEDA1D.30905@nic.cz>
 <CAJU7zaKn0srjnLS8LJgFhUADz5a5R5ZF9yTCwMoT1V9LrDSCdA@mail.gmail.com>
Message-ID: <56DEE2EF.7080205@nic.cz>

On 8.3.2016 15:09, Nikos Mavrogiannopoulos wrote:
> It seems I relied on the test suite, but the tests did not fail if
> they don't work :(
> The RETCODE path was to continue the tests even on old softhsm which
> did not support certain functionality. I'll see to merge that and
> eliminate the retcode path in testpkcs11.sh.

I don't know. I've probably used different version of SoftHSM. The tests
were failing when I reverted the patch.

Jan


From nmav at gnutls.org  Thu Mar 10 08:27:05 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 10 Mar 2016 08:27:05 +0100
Subject: [gnutls-devel] gnutls 3.3.22
Message-ID: <1457594825.20131.0.camel@gnutls.org>

Hello, 
 I've just released gnutls 3.3.22. This is a bug-fix release on
the previous stable branch.

* Version 3.3.22 (released 2016-03-10)

** libgnutls: Eliminated issues preventing buffers more than 2^32 bytes
   to be used with hashing functions.

** libgnutls: Follow closely RFC5280 recommendations and use UTCTime 
   for dates prior to 2050. Backported from 3.4.x branch.

** libgnutls: Several fixes to prevent relying on undefined behavior
   of C (found with libubsan).

** libgnutls: SSL 3.0 is no longer included in the default priorities
   list. It has to be explicitly enabled, e.g., with a string like
   "NORMAL:+VERS-SSL3.0". The previous behavior can be restored using
   the flag --with-ssl3 to configure.

** 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 compressed sources:

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

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.22.tar.xz.sig

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

regards,
Nikos



From ludo at gnu.org  Mon Mar 14 10:44:07 2016
From: ludo at gnu.org (=?UTF-8?q?Ludovic=20Court=C3=A8s?=)
Date: Mon, 14 Mar 2016 10:44:07 +0100
Subject: [gnutls-devel] [PATCH 1/2] guile: doc: Explain "Application Data"
	packets and 'session-record-port'.
Message-ID: <1457948648-5558-1-git-send-email-ludo@gnu.org>

* doc/gnutls-guile.texi (Input and Output): Mention "Application Data"
packets and buffering.
---
 doc/gnutls-guile.texi | 16 +++++++++++++---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/doc/gnutls-guile.texi b/doc/gnutls-guile.texi
index 061a31f..8a085be 100644
--- a/doc/gnutls-guile.texi
+++ b/doc/gnutls-guile.texi
@@ -359,18 +359,28 @@ Once a TLS session is established, data can be communicated through it
 
   ;;
   ;; Initialize the various parameters of SESSION, set up
-  ;; a network connection, etc...
+  ;; a network connection, etc.
   ;;
 
   (let ((i/o (session-record-port session)))
-    (write "Hello peer!" i/o)
+    (display "Hello peer!" i/o)
     (let ((greetings (read i/o)))
 
-      ;; ...
+      ;; @dots{}
 
       (bye session close-request/rdwr))))
 @end example
 
+ at c See <http://bugs.gnu.org/22966> for details.
+ at cindex buffering
+Note that each write to the session record port leads to the
+transmission of an encrypted TLS ``Application Data'' packet.  In the
+above example, we create an Application Data packet for the 11 bytes for
+the string that we write.  This is not efficient both in terms of CPU
+usage and bandwidth (each packet adds at least 5 bytes of overhead and
+can lead to one @code{write} system call), so we recommend that
+applications do their own buffering.
+
 @findex record-send
 @findex record-receive!
 
-- 
2.6.3



From ludo at gnu.org  Mon Mar 14 10:44:08 2016
From: ludo at gnu.org (=?UTF-8?q?Ludovic=20Court=C3=A8s?=)
Date: Mon, 14 Mar 2016 10:44:08 +0100
Subject: [gnutls-devel] [PATCH 2/2] guile: doc: Mention bytevectors.
In-Reply-To: <1457948648-5558-1-git-send-email-ludo@gnu.org>
References: <1457948648-5558-1-git-send-email-ludo@gnu.org>
Message-ID: <1457948648-5558-2-git-send-email-ludo@gnu.org>

* doc/gnutls-guile.texi (Representation of Binary Data): Mention bytevectors.
(Input and Output): Likewise.
---
 doc/gnutls-guile.texi | 18 ++++++++++--------
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/doc/gnutls-guile.texi b/doc/gnutls-guile.texi
index 8a085be..0bb7995 100644
--- a/doc/gnutls-guile.texi
+++ b/doc/gnutls-guile.texi
@@ -288,13 +288,14 @@ procedure applies to session.
 Many procedures operate on binary data.  For instance,
 @code{pkcs3-import-dh-parameters} expects binary data as input.
 
+ at cindex bytevectors
 @cindex SRFI-4
 @cindex homogeneous vector
-
-Binary data is represented on the Scheme side using SRFI-4 homogeneous
-vectors (@pxref{SRFI-4,,, guile, The GNU Guile Reference Manual}).
-Although any type of homogeneous vector may be used, @code{u8vector}s
-(i.e., vectors of bytes) are highly recommended.
+Binary data is represented on the Scheme side using bytevectors
+(@pxref{Bytevectors,,, guile, The GNU Guile Reference Manual}).
+Homogeneous vectors such as SRFI-4 @code{u8vector}s can also be
+used at footnote{Historically, SRFI-4 @code{u8vector}s are the closest
+thing to bytevectors that Guile 1.8 and earlier supported.}.
 
 As an example, generating and then exporting Diffie-Hellman parameters
 in the PEM format can be done as follows:
@@ -385,9 +386,10 @@ applications do their own buffering.
 @findex record-receive!
 
 A lower-level I/O API is provided by @code{record-send} and
- at code{record-receive!} which take an SRFI-4 vector to represent the
-data sent or received.  While it might improve performance, it is much
-less convenient than the above and should rarely be needed.
+ at code{record-receive!} which take a bytevector (or a SRFI-4 vector) to
+represent the data sent or received.  While it might improve
+performance, it is much less convenient than the session record port and
+should rarely be needed.
 
 
 @node Exception Handling
-- 
2.6.3



From nmav at gnutls.org  Tue Mar 15 11:51:41 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 15 Mar 2016 11:51:41 +0100
Subject: [gnutls-devel] [PATCH 2/2] guile: doc: Mention bytevectors.
In-Reply-To: <1457948648-5558-2-git-send-email-ludo@gnu.org>
References: <1457948648-5558-1-git-send-email-ludo@gnu.org>
 <1457948648-5558-2-git-send-email-ludo@gnu.org>
Message-ID: <CAJU7zaJ6Ffa0FmiouH9O053mjHM-RezZp=wTieKDRSE6iVcR9g@mail.gmail.com>

Both pushed, thank you.

On Mon, Mar 14, 2016 at 10:44 AM, Ludovic Court?s <ludo at gnu.org> wrote:
> * doc/gnutls-guile.texi (Representation of Binary Data): Mention bytevectors.
> (Input and Output): Likewise.
> ---
>  doc/gnutls-guile.texi | 18 ++++++++++--------
>  1 file changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/doc/gnutls-guile.texi b/doc/gnutls-guile.texi
> index 8a085be..0bb7995 100644
> --- a/doc/gnutls-guile.texi
> +++ b/doc/gnutls-guile.texi
> @@ -288,13 +288,14 @@ procedure applies to session.
>  Many procedures operate on binary data.  For instance,
>  @code{pkcs3-import-dh-parameters} expects binary data as input.
>
> + at cindex bytevectors
>  @cindex SRFI-4
>  @cindex homogeneous vector
> -
> -Binary data is represented on the Scheme side using SRFI-4 homogeneous
> -vectors (@pxref{SRFI-4,,, guile, The GNU Guile Reference Manual}).
> -Although any type of homogeneous vector may be used, @code{u8vector}s
> -(i.e., vectors of bytes) are highly recommended.
> +Binary data is represented on the Scheme side using bytevectors
> +(@pxref{Bytevectors,,, guile, The GNU Guile Reference Manual}).
> +Homogeneous vectors such as SRFI-4 @code{u8vector}s can also be
> +used at footnote{Historically, SRFI-4 @code{u8vector}s are the closest
> +thing to bytevectors that Guile 1.8 and earlier supported.}.
>
>  As an example, generating and then exporting Diffie-Hellman parameters
>  in the PEM format can be done as follows:
> @@ -385,9 +386,10 @@ applications do their own buffering.
>  @findex record-receive!
>
>  A lower-level I/O API is provided by @code{record-send} and
> - at code{record-receive!} which take an SRFI-4 vector to represent the
> -data sent or received.  While it might improve performance, it is much
> -less convenient than the above and should rarely be needed.
> + at code{record-receive!} which take a bytevector (or a SRFI-4 vector) to
> +represent the data sent or received.  While it might improve
> +performance, it is much less convenient than the session record port and
> +should rarely be needed.
>
>
>  @node Exception Handling
> --
> 2.6.3
>


From ludo at gnu.org  Tue Mar 15 13:57:18 2016
From: ludo at gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=)
Date: Tue, 15 Mar 2016 13:57:18 +0100
Subject: [gnutls-devel] change in posting policy
In-Reply-To: <56D831EB.8060504@hlrs.de> (Martin Hecht's message of "Thu, 3 Mar
 2016 13:45:31 +0100")
References: <1456762195.1861.3.camel@gnutls.org> <87si09jm8y.fsf@gnu.org>
 <56D831EB.8060504@hlrs.de>
Message-ID: <87a8lzsxu9.fsf@gnu.org>

Martin Hecht <hecht at hlrs.de> skribis:

> On 03/02/2016 09:51 AM, Ludovic Court?s wrote:
>> Nikos Mavrogiannopoulos <nmav at gnutls.org> skribis:
>>
>>>  Due to a large amount of spam received by the list, it is no longer
>>> practical to go through the list of held postings and approve them. As
>>> such, I've switched the posting policy to members only. 
>> Sigh.  lists.gnu.org did not have that drawback?
> I think it's not a problem specific to the particular list.

What I meant is that running one?s own mailing list service is more work
than sharing infrastructure with others.

lists.gnu.org has very good spam filtering in place, which is why it
allows non-member posts, in the spirit of lowering the barrier to entry.

Ludo?.


From ludo at gnu.org  Tue Mar 15 18:50:56 2016
From: ludo at gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=)
Date: Tue, 15 Mar 2016 18:50:56 +0100
Subject: [gnutls-devel] [PATCH 2/2] guile: doc: Mention bytevectors.
In-Reply-To: <CAJU7zaJ6Ffa0FmiouH9O053mjHM-RezZp=wTieKDRSE6iVcR9g@mail.gmail.com>
 (Nikos Mavrogiannopoulos's message of "Tue, 15 Mar 2016 11:51:41
 +0100")
References: <1457948648-5558-1-git-send-email-ludo@gnu.org>
 <1457948648-5558-2-git-send-email-ludo@gnu.org>
 <CAJU7zaJ6Ffa0FmiouH9O053mjHM-RezZp=wTieKDRSE6iVcR9g@mail.gmail.com>
Message-ID: <87y49jsk8v.fsf@gnu.org>

Nikos Mavrogiannopoulos <nmav at gnutls.org> skribis:

> Both pushed, thank you.

Awesome, thanks!

Ludo?.


From ametzler at bebt.de  Tue Mar 15 19:44:05 2016
From: ametzler at bebt.de (Andreas Metzler)
Date: Tue, 15 Mar 2016 19:44:05 +0100
Subject: [gnutls-devel] gnutls 3.4.10 testsuite error on amd64 (SSSE3 cipher
	tests failed)
Message-ID: <20160315184405.GB1628@argenau.bebt.de>

Hello,

./test-hash-large failed on one of Debian's autobuilders (AMD Opteron
23xx):
(sid_amd64-dchroot)ametzler at barriere:~/GNUTLS/gnutls28-3.4.10/tests/slow$ ./test-hash-large --verbose --debug  7777
Illegal instruction
SSSE3 cipher tests failed

Find attached /proc/cpuinfo of the respective machine.

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 --------------
processor	: 0
vendor_id	: AuthenticAMD
cpu family	: 15
model		: 6
model name	: AMD Opteron 23xx (Gen 3 Class Opteron)
stepping	: 1
microcode	: 0x1000065
cpu MHz		: 2400.084
cache size	: 512 KB
physical id	: 0
siblings	: 1
core id		: 0
cpu cores	: 1
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 5
wp		: yes
flags		: fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx lm rep_good nopl extd_apicid pni cx16 x2apic popcnt hypervisor svm abm sse4a misalignsse vmmcall
bogomips	: 4800.16
TLB size	: 1024 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 40 bits physical, 48 bits virtual
power management:

processor	: 1
vendor_id	: AuthenticAMD
cpu family	: 15
model		: 6
model name	: AMD Opteron 23xx (Gen 3 Class Opteron)
stepping	: 1
microcode	: 0x1000065
cpu MHz		: 2400.084
cache size	: 512 KB
physical id	: 1
siblings	: 1
core id		: 0
cpu cores	: 1
apicid		: 1
initial apicid	: 1
fpu		: yes
fpu_exception	: yes
cpuid level	: 5
wp		: yes
flags		: fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx lm rep_good nopl extd_apicid pni cx16 x2apic popcnt hypervisor svm abm sse4a misalignsse vmmcall
bogomips	: 4800.16
TLB size	: 1024 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 40 bits physical, 48 bits virtual
power management:

processor	: 2
vendor_id	: AuthenticAMD
cpu family	: 15
model		: 6
model name	: AMD Opteron 23xx (Gen 3 Class Opteron)
stepping	: 1
microcode	: 0x1000065
cpu MHz		: 2400.084
cache size	: 512 KB
physical id	: 2
siblings	: 1
core id		: 0
cpu cores	: 1
apicid		: 2
initial apicid	: 2
fpu		: yes
fpu_exception	: yes
cpuid level	: 5
wp		: yes
flags		: fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx lm rep_good nopl extd_apicid pni cx16 x2apic popcnt hypervisor svm abm sse4a misalignsse vmmcall
bogomips	: 4800.16
TLB size	: 1024 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 40 bits physical, 48 bits virtual
power management:

processor	: 3
vendor_id	: AuthenticAMD
cpu family	: 15
model		: 6
model name	: AMD Opteron 23xx (Gen 3 Class Opteron)
stepping	: 1
microcode	: 0x1000065
cpu MHz		: 2400.084
cache size	: 512 KB
physical id	: 3
siblings	: 1
core id		: 0
cpu cores	: 1
apicid		: 3
initial apicid	: 3
fpu		: yes
fpu_exception	: yes
cpuid level	: 5
wp		: yes
flags		: fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx lm rep_good nopl extd_apicid pni cx16 x2apic popcnt hypervisor svm abm sse4a misalignsse vmmcall
bogomips	: 4800.16
TLB size	: 1024 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 40 bits physical, 48 bits virtual
power management:


From nmav at gnutls.org  Wed Mar 16 10:02:24 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 16 Mar 2016 10:02:24 +0100
Subject: [gnutls-devel] gnutls 3.4.10 testsuite error on amd64 (SSSE3
 cipher tests failed)
In-Reply-To: <20160315184405.GB1628@argenau.bebt.de>
References: <20160315184405.GB1628@argenau.bebt.de>
Message-ID: <CAJU7zaKQf_JmNzoZGGGOA0H9+vQJ=EX8kq60oLjuc2GXMjK-Zg@mail.gmail.com>

On Tue, Mar 15, 2016 at 7:44 PM, Andreas Metzler <ametzler at bebt.de> wrote:
> Hello,
> ./test-hash-large failed on one of Debian's autobuilders (AMD Opteron
> 23xx):
> (sid_amd64-dchroot)ametzler at barriere:~/GNUTLS/gnutls28-3.4.10/tests/slow$ ./test-hash-large --verbose --debug  7777
> Illegal instruction
> SSSE3 cipher tests failed

Thanks. It seems that the CPU has no SSSE3 and the test overrides the
cpuid to force SSSE3 usage. I'm wondering whether it is better to
change the test to detect cpu capabilities via /proc/cpuinfo, or
remove the ability to override a CPU flag if the CPU doesn't support
it.

regards,
Nikos


From ametzler at bebt.de  Wed Mar 16 17:44:35 2016
From: ametzler at bebt.de (Andreas Metzler)
Date: Wed, 16 Mar 2016 17:44:35 +0100
Subject: [gnutls-devel] gnutls 3.4.10 testsuite error on amd64 (SSSE3
 cipher tests failed)
In-Reply-To: <CAJU7zaKQf_JmNzoZGGGOA0H9+vQJ=EX8kq60oLjuc2GXMjK-Zg@mail.gmail.com>
References: <20160315184405.GB1628@argenau.bebt.de>
 <CAJU7zaKQf_JmNzoZGGGOA0H9+vQJ=EX8kq60oLjuc2GXMjK-Zg@mail.gmail.com>
Message-ID: <20160316164435.GC1228@argenau.bebt.de>

On 2016-03-16 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> On Tue, Mar 15, 2016 at 7:44 PM, Andreas Metzler <ametzler at bebt.de> wrote:
>> ./test-hash-large failed on one of Debian's autobuilders (AMD Opteron
>> 23xx):
>> (sid_amd64-dchroot)ametzler at barriere:~/GNUTLS/gnutls28-3.4.10/tests/slow$ ./test-hash-large --verbose --debug  7777
>> Illegal instruction
>> SSSE3 cipher tests failed

> Thanks. It seems that the CPU has no SSSE3 and the test overrides the
> cpuid to force SSSE3 usage. I'm wondering whether it is better to
> change the test to detect cpu capabilities via /proc/cpuinfo, or
> remove the ability to override a CPU flag if the CPU doesn't support
> it.

Hello,

I thought that GNUTLS_CPUID_OVERRIDE was not supposed to enable
unavailable features: "Note that CPU detection cannot be overriden,
i.e., VIA options cannot be enabled on an Intel CPU."

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 yumkam at gmail.com  Wed Mar 16 20:51:34 2016
From: yumkam at gmail.com (Yuriy M. Kaminskiy)
Date: Wed, 16 Mar 2016 22:51:34 +0300
Subject: [gnutls-devel] [resent][PATCH] ALPN and session resumption
Message-ID: <56E9B946.4020800@gmail.com>

I've played a bit with curl with HTTP/2 support and gnutls backend (curl 
git master [curl-7_47_1-75-g3c2ef2a], [self-compiled] nghttp2 1.8.0, 
[distro] debian's gnutls 3.3.8), and it looks like ALPN is broken with 
session resumption.

   curl -v -c jar --location https://www.google.com/ncr >log 2>errlog

fails; first connection succeed (got redirect), then second connection
to same server (resumes session) fails with

   * ALPN, server did not agree to a protocol

If I disable session support:
   curl -v -c jar --location --no-sessionid https://www.google.com/ncr
everything works.

I played with gdb, looked at gnutls sources, and found that libgnutls 
neither parse ALPN extension on resume[1], nor re-uses session data[2], 
as a result after session resumption 
gnutls_alpn_get_selected_protocol() returns failure (even though server 
sent ALPN/h2 in ServerHello).

I've re-tested with (self-compiled) gnutls 3.3.22, it behaves same.

I cannot test with 3.4.* atm (missing build-req), but quick look at 
sources suggests bug is still present.

[1] ALPN extension state is per-connection, it should not be saved with 
session data, and should be parsed on each connection:
=== rfc7301 ===
     Unlike many other TLS extensions, this extension does not establish
     properties of the session, only of the connection.  When session
     resumption or session tickets [RFC5077] are used, the previous
     contents of this extension are irrelevant, and only the values in
     the new handshake messages are considered.
=== cut ===

See attached patches against gnutls_3_3_x (not sure if it is correct, as
it also may affect SRTP extension, please verify). Briefly run-tested,
passes `make check`.

I also attached same patches rebased against git master (*completely 
untested*).

[2] I'm not sure, but other extension may also want their data after 
session resumption, restored from saved state or parsed?

Before commit 20151edffdb8d99c7feb986a2f102df76314cb7d, all
(non-GNUTLS_EXT_MANDATORY) extension data from resumed session was
pulled back by _gnutls_ext_restore_resumed_session() function. After
that commit, extension data are not restored (and, except for 
*MANDATORY, are not parsed from ServerHello either), and this function 
remains unused.

Probably, it should be either removed (if each extension should deal 
with resumed session data by itself), or used again?

(but it should not cover ALPN either way, as ALPN state is not session data)

Disclaimer: my knowledge of TLS protocol and gnutls implementation in
particular is rather limited, please review carefully.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-alpn-ALPN-state-is-per-connection-it-should-not-be-s.patch
Type: text/x-diff
Size: 3762 bytes
Desc: not available
URL: </pipermail/attachments/20160316/c8e68f12/attachment-0004.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-handshake-parse-ALPN-extension-in-resumed-client-ses.patch
Type: text/x-diff
Size: 956 bytes
Desc: not available
URL: </pipermail/attachments/20160316/c8e68f12/attachment-0005.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: master-0001-alpn-ALPN-state-is-per-connection-it-should-not-be-s.patch
Type: text/x-diff
Size: 3582 bytes
Desc: not available
URL: </pipermail/attachments/20160316/c8e68f12/attachment-0006.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: master-0002-handshake-parse-ALPN-extension-in-resumed-client-ses.patch
Type: text/x-diff
Size: 856 bytes
Desc: not available
URL: </pipermail/attachments/20160316/c8e68f12/attachment-0007.patch>
-------------- next part --------------
*   Trying 2a00:1450:4001:805::1013...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* Connected to www.google.com (2a00:1450:4001:805::1013) port 443 (#0)
* found 174 certificates in /etc/ssl/certs/ca-certificates.crt
* ALPN, offering h2
* ALPN, offering http/1.1
  0     0    0     0    0     0      0      0 --:--:--  0:00:01 --:--:--     0* SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
* 	 server certificate verification OK
* 	 server certificate status verification SKIPPED
* 	 common name: www.google.com (matched)
* 	 server certificate expiration date OK
* 	 server certificate activation date OK
* 	 certificate public key: RSA
* 	 certificate version: #3
* 	 subject: C=US,ST=California,L=Mountain View,O=Google Inc,CN=www.google.com
* 	 start date: Wed, 02 Mar 2016 11:08:25 GMT
* 	 expire date: Tue, 31 May 2016 00:00:00 GMT
* 	 issuer: C=US,O=Google Inc,CN=Google Internet Authority G2
* 	 compression: NULL
* ALPN, server accepted to use h2
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* TCP_NODELAY set
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x8a71a58)
> GET /ncr HTTP/1.1
> Host: www.google.com
> User-Agent: curl/7.47.2-DEV
> Accept: */*
> 
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2.0 302
< location:https://www.google.com/
< cache-control:private
< content-type:text/html; charset=UTF-8
< p3p:CP="This is not a P3P policy! See https://www.google.com/support/accounts/answer/151657?hl=en for more info."
< date:Tue, 15 Mar 2016 22:15:01 GMT
< server:gws
< content-length:220
< x-xss-protection:1; mode=block
< x-frame-options:SAMEORIGIN
* Added cookie NID="77=c7OgNFwKmGK9ljYBGoWfZc7btb6HYFVYPigYRv_71hOycRU4aw31XSoTxI2YwzG1gZtOEHoM-vvTxV9LJP_S3IvQTHgE4LWwevyLYJ90m_UPiuVxQQJQANp09WqywAQO" for domain google.com, path /, expire 1473891301
< set-cookie:NID=77=c7OgNFwKmGK9ljYBGoWfZc7btb6HYFVYPigYRv_71hOycRU4aw31XSoTxI2YwzG1gZtOEHoM-vvTxV9LJP_S3IvQTHgE4LWwevyLYJ90m_UPiuVxQQJQANp09WqywAQO; expires=Wed, 14-Sep-2016 22:15:01 GMT; path=/; domain=.google.com; HttpOnly
< alternate-protocol:443:quic,p=1
< alt-svc:quic=":443"; ma=2592000; v="31,30,29,28,27,26,25"
< 
* Ignoring the response-body
{ [220 bytes data]
100   220  100   220    0     0    138      0  0:00:01  0:00:01 --:--:--   156
* Connection #0 to host www.google.com left intact
* Issue another request to this URL: 'https://www.google.com/'
* Connection 0 seems to be dead!
* Closing connection 0
* Hostname www.google.com was found in DNS cache
*   Trying 2a00:1450:4001:805::1013...
* Connected to www.google.com (2a00:1450:4001:805::1013) port 443 (#1)
* found 174 certificates in /etc/ssl/certs/ca-certificates.crt
* ALPN, offering h2
* ALPN, offering http/1.1
* SSL re-using session ID
* SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
* 	 server certificate verification OK
* 	 server certificate status verification SKIPPED
* 	 common name: www.google.com (matched)
* 	 server certificate expiration date OK
* 	 server certificate activation date OK
* 	 certificate public key: RSA
* 	 certificate version: #3
* 	 subject: C=US,ST=California,L=Mountain View,O=Google Inc,CN=www.google.com
* 	 start date: Wed, 02 Mar 2016 11:08:25 GMT
* 	 expire date: Tue, 31 May 2016 00:00:00 GMT
* 	 issuer: C=US,O=Google Inc,CN=Google Internet Authority G2
* 	 compression: NULL
* ALPN, server did not agree to a protocol
> GET / HTTP/1.1
> Host: www.google.com
> User-Agent: curl/7.47.2-DEV
> Accept: */*
> Cookie: NID=77=c7OgNFwKmGK9ljYBGoWfZc7btb6HYFVYPigYRv_71hOycRU4aw31XSoTxI2YwzG1gZtOEHoM-vvTxV9LJP_S3IvQTHgE4LWwevyLYJ90m_UPiuVxQQJQANp09WqywAQO
> 
{ [27 bytes data]
100    54    0    54    0     0     27      0 --:--:--  0:00:01 --:--:--    27* GnuTLS recv error (-110): The TLS connection was non-properly terminated.
100   106    0   106    0     0     54      0 --:--:--  0:00:01 --:--:-- 52000
* Closing connection 1
curl: (56) GnuTLS recv error (-110): The TLS connection was non-properly terminated.
* Hostname www.google.com was found in DNS cache
*   Trying 2a00:1450:4001:805::1013...
* Connected to www.google.com (2a00:1450:4001:805::1013) port 443 (#2)
* found 174 certificates in /etc/ssl/certs/ca-certificates.crt
* ALPN, offering h2
* ALPN, offering http/1.1
* SSL re-using session ID
* SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
* 	 server certificate verification OK
* 	 server certificate status verification SKIPPED
* 	 common name: www.google.com (matched)
* 	 server certificate expiration date OK
* 	 server certificate activation date OK
* 	 certificate public key: RSA
* 	 certificate version: #3
* 	 subject: C=US,ST=California,L=Mountain View,O=Google Inc,CN=www.google.com
* 	 start date: Wed, 02 Mar 2016 11:08:25 GMT
* 	 expire date: Tue, 31 May 2016 00:00:00 GMT
* 	 issuer: C=US,O=Google Inc,CN=Google Internet Authority G2
* 	 compression: NULL
* ALPN, server accepted to use h2
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* TCP_NODELAY set
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x8a71a58)
> GET /ncr HTTP/1.1
> Host: www.google.com
> User-Agent: curl/7.47.2-DEV
> Accept: */*
> Cookie: NID=77=c7OgNFwKmGK9ljYBGoWfZc7btb6HYFVYPigYRv_71hOycRU4aw31XSoTxI2YwzG1gZtOEHoM-vvTxV9LJP_S3IvQTHgE4LWwevyLYJ90m_UPiuVxQQJQANp09WqywAQO
> 
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2.0 302
< location:https://www.google.com/
< cache-control:private
< content-type:text/html; charset=UTF-8
< date:Tue, 15 Mar 2016 22:15:01 GMT
< server:gws
< content-length:220
< x-xss-protection:1; mode=block
< x-frame-options:SAMEORIGIN
< alternate-protocol:443:quic,p=1
< alt-svc:quic=":443"; ma=2592000; v="31,30,29,28,27,26,25"
< 
* Ignoring the response-body
{ [220 bytes data]
100   220  100   220    0     0    482      0 --:--:-- --:--:-- --:--:--   482
* Connection #2 to host www.google.com left intact
* Issue another request to this URL: 'https://www.google.com/'
* Found bundle for host www.google.com: 0x8a69d58 [can multiplex]
* Connection 2 seems to be dead!
* Closing connection 2
* Hostname www.google.com was found in DNS cache
*   Trying 2a00:1450:4001:805::1013...
* Connected to www.google.com (2a00:1450:4001:805::1013) port 443 (#3)
* found 174 certificates in /etc/ssl/certs/ca-certificates.crt
* ALPN, offering h2
* ALPN, offering http/1.1
* SSL re-using session ID
* SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
* 	 server certificate verification OK
* 	 server certificate status verification SKIPPED
* 	 common name: www.google.com (matched)
* 	 server certificate expiration date OK
* 	 server certificate activation date OK
* 	 certificate public key: RSA
* 	 certificate version: #3
* 	 subject: C=US,ST=California,L=Mountain View,O=Google Inc,CN=www.google.com
* 	 start date: Wed, 02 Mar 2016 11:08:25 GMT
* 	 expire date: Tue, 31 May 2016 00:00:00 GMT
* 	 issuer: C=US,O=Google Inc,CN=Google Internet Authority G2
* 	 compression: NULL
* ALPN, server did not agree to a protocol
> GET / HTTP/1.1
> Host: www.google.com
> User-Agent: curl/7.47.2-DEV
> Accept: */*
> Cookie: NID=77=c7OgNFwKmGK9ljYBGoWfZc7btb6HYFVYPigYRv_71hOycRU4aw31XSoTxI2YwzG1gZtOEHoM-vvTxV9LJP_S3IvQTHgE4LWwevyLYJ90m_UPiuVxQQJQANp09WqywAQO
> 
{ [27 bytes data]
* GnuTLS recv error (-110): The TLS connection was non-properly terminated.
100   106    0   106    0     0    136      0 --:--:-- --:--:-- --:--:--   136
* Closing connection 3
curl: (56) GnuTLS recv error (-110): The TLS connection was non-properly terminated.

-------------- next part --------------
*   Trying 2a00:1450:4001:805::1013...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* Connected to www.google.com (2a00:1450:4001:805::1013) port 443 (#0)
* found 174 certificates in /etc/ssl/certs/ca-certificates.crt
* ALPN, offering h2
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
* 	 server certificate verification OK
* 	 server certificate status verification SKIPPED
* 	 common name: www.google.com (matched)
* 	 server certificate expiration date OK
* 	 server certificate activation date OK
* 	 certificate public key: RSA
* 	 certificate version: #3
* 	 subject: C=US,ST=California,L=Mountain View,O=Google Inc,CN=www.google.com
* 	 start date: Wed, 02 Mar 2016 11:08:25 GMT
* 	 expire date: Tue, 31 May 2016 00:00:00 GMT
* 	 issuer: C=US,O=Google Inc,CN=Google Internet Authority G2
* 	 compression: NULL
* ALPN, server accepted to use h2
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* TCP_NODELAY set
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x8b2ca58)
> GET /ncr HTTP/1.1
> Host: www.google.com
> User-Agent: curl/7.47.2-DEV
> Accept: */*
> 
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2.0 302
< location:https://www.google.com/
< cache-control:private
< content-type:text/html; charset=UTF-8
< p3p:CP="This is not a P3P policy! See https://www.google.com/support/accounts/answer/151657?hl=en for more info."
< date:Tue, 15 Mar 2016 22:16:29 GMT
< server:gws
< content-length:220
< x-xss-protection:1; mode=block
< x-frame-options:SAMEORIGIN
* Added cookie NID="77=eLRcQff-tv-XdEugTW2Gh9r0y49l-O_iWUBGqtOYYGOSILbzji4dsikgr4tjU62OmbCbpNrmNtdF07Scmmc8lbkYo9hQYY-rZTMTQagWmeboKfqEhSzDYrBZIG6IuY1A" for domain google.com, path /, expire 1473891389
< set-cookie:NID=77=eLRcQff-tv-XdEugTW2Gh9r0y49l-O_iWUBGqtOYYGOSILbzji4dsikgr4tjU62OmbCbpNrmNtdF07Scmmc8lbkYo9hQYY-rZTMTQagWmeboKfqEhSzDYrBZIG6IuY1A; expires=Wed, 14-Sep-2016 22:16:29 GMT; path=/; domain=.google.com; HttpOnly
< alternate-protocol:443:quic,p=1
< alt-svc:quic=":443"; ma=2592000; v="31,30,29,28,27,26,25"
< 
* Ignoring the response-body
{ [220 bytes data]
100   220  100   220    0     0    332      0 --:--:-- --:--:-- --:--:--   397
* Connection #0 to host www.google.com left intact
* Issue another request to this URL: 'https://www.google.com/'
* Found bundle for host www.google.com: 0x8b177c8 [can multiplex]
* Connection 0 seems to be dead!
* Closing connection 0
* Hostname www.google.com was found in DNS cache
*   Trying 2a00:1450:4001:805::1013...
* Connected to www.google.com (2a00:1450:4001:805::1013) port 443 (#1)
* found 174 certificates in /etc/ssl/certs/ca-certificates.crt
* ALPN, offering h2
* ALPN, offering http/1.1
  0     0    0     0    0     0      0      0 --:--:--  0:00:01 --:--:--     0* SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
* 	 server certificate verification OK
* 	 server certificate status verification SKIPPED
* 	 common name: www.google.com (matched)
* 	 server certificate expiration date OK
* 	 server certificate activation date OK
* 	 certificate public key: RSA
* 	 certificate version: #3
* 	 subject: C=US,ST=California,L=Mountain View,O=Google Inc,CN=www.google.com
* 	 start date: Wed, 02 Mar 2016 11:08:25 GMT
* 	 expire date: Tue, 31 May 2016 00:00:00 GMT
* 	 issuer: C=US,O=Google Inc,CN=Google Internet Authority G2
* 	 compression: NULL
* ALPN, server accepted to use h2
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* TCP_NODELAY set
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x8b2ca58)
> GET / HTTP/1.1
> Host: www.google.com
> User-Agent: curl/7.47.2-DEV
> Accept: */*
> Cookie: NID=77=eLRcQff-tv-XdEugTW2Gh9r0y49l-O_iWUBGqtOYYGOSILbzji4dsikgr4tjU62OmbCbpNrmNtdF07Scmmc8lbkYo9hQYY-rZTMTQagWmeboKfqEhSzDYrBZIG6IuY1A
> 
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2.0 200
< date:Tue, 15 Mar 2016 22:16:30 GMT
< expires:-1
< cache-control:private, max-age=0
< content-type:text/html; charset=ISO-8859-1
< p3p:CP="This is not a P3P policy! See https://www.google.com/support/accounts/answer/151657?hl=en for more info."
< server:gws
< x-xss-protection:1; mode=block
< x-frame-options:SAMEORIGIN
* Replaced cookie NID="77=fHsBvo5s4xB0c1erVngykj7rF3z4gssxWWqxDKS7-euakJIcDYHJR22ovZBQp3JEoUstldpUNTOUJQjZebHM2HjbgyR-bWEAYrTTRU7AyRDdjYkYNbW-fE-uBV26PszDnqfhAfan1KJpuIfaSY39xmc" for domain google.com, path /, expire 1473891390
< set-cookie:NID=77=fHsBvo5s4xB0c1erVngykj7rF3z4gssxWWqxDKS7-euakJIcDYHJR22ovZBQp3JEoUstldpUNTOUJQjZebHM2HjbgyR-bWEAYrTTRU7AyRDdjYkYNbW-fE-uBV26PszDnqfhAfan1KJpuIfaSY39xmc; expires=Wed, 14-Sep-2016 22:16:30 GMT; path=/; domain=.google.com; HttpOnly
< alternate-protocol:443:quic,p=1
< alt-svc:quic=":443"; ma=2592000; v="31,30,29,28,27,26,25"
< accept-ranges:none
< vary:Accept-Encoding
< 
{ [1170 bytes data]
100 19216    0 19216    0     0  14017      0 --:--:--  0:00:01 --:--:-- 56187
* Connection #1 to host www.google.com left intact
* Connection 1 seems to be dead!
* Closing connection 1
* Hostname www.google.com was found in DNS cache
*   Trying 2a00:1450:4001:805::1013...
* Connected to www.google.com (2a00:1450:4001:805::1013) port 443 (#2)
* found 174 certificates in /etc/ssl/certs/ca-certificates.crt
* ALPN, offering h2
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
* 	 server certificate verification OK
* 	 server certificate status verification SKIPPED
* 	 common name: www.google.com (matched)
* 	 server certificate expiration date OK
* 	 server certificate activation date OK
* 	 certificate public key: RSA
* 	 certificate version: #3
* 	 subject: C=US,ST=California,L=Mountain View,O=Google Inc,CN=www.google.com
* 	 start date: Wed, 02 Mar 2016 11:08:25 GMT
* 	 expire date: Tue, 31 May 2016 00:00:00 GMT
* 	 issuer: C=US,O=Google Inc,CN=Google Internet Authority G2
* 	 compression: NULL
* ALPN, server accepted to use h2
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* TCP_NODELAY set
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x8b2ca58)
> GET /ncr HTTP/1.1
> Host: www.google.com
> User-Agent: curl/7.47.2-DEV
> Accept: */*
> Cookie: NID=77=fHsBvo5s4xB0c1erVngykj7rF3z4gssxWWqxDKS7-euakJIcDYHJR22ovZBQp3JEoUstldpUNTOUJQjZebHM2HjbgyR-bWEAYrTTRU7AyRDdjYkYNbW-fE-uBV26PszDnqfhAfan1KJpuIfaSY39xmc
> 
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2.0 302
< location:https://www.google.com/
< cache-control:private
< content-type:text/html; charset=UTF-8
< date:Tue, 15 Mar 2016 22:16:31 GMT
< server:gws
< content-length:220
< x-xss-protection:1; mode=block
< x-frame-options:SAMEORIGIN
< alternate-protocol:443:quic,p=1
< alt-svc:quic=":443"; ma=2592000; v="31,30,29,28,27,26,25"
< 
* Ignoring the response-body
{ [220 bytes data]
100   220  100   220    0     0    477      0 --:--:-- --:--:-- --:--:--   477
* Connection #2 to host www.google.com left intact
* Issue another request to this URL: 'https://www.google.com/'
* Found bundle for host www.google.com: 0x8ef9538 [can multiplex]
* Connection 2 seems to be dead!
* Closing connection 2
* Hostname www.google.com was found in DNS cache
*   Trying 2a00:1450:4001:805::1013...
* Connected to www.google.com (2a00:1450:4001:805::1013) port 443 (#3)
* found 174 certificates in /etc/ssl/certs/ca-certificates.crt
* ALPN, offering h2
* ALPN, offering http/1.1
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
* 	 server certificate verification OK
* 	 server certificate status verification SKIPPED
* 	 common name: www.google.com (matched)
* 	 server certificate expiration date OK
* 	 server certificate activation date OK
* 	 certificate public key: RSA
* 	 certificate version: #3
* 	 subject: C=US,ST=California,L=Mountain View,O=Google Inc,CN=www.google.com
* 	 start date: Wed, 02 Mar 2016 11:08:25 GMT
* 	 expire date: Tue, 31 May 2016 00:00:00 GMT
* 	 issuer: C=US,O=Google Inc,CN=Google Internet Authority G2
* 	 compression: NULL
* ALPN, server accepted to use h2
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* TCP_NODELAY set
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x8b2ca58)
> GET / HTTP/1.1
> Host: www.google.com
> User-Agent: curl/7.47.2-DEV
> Accept: */*
> Cookie: NID=77=fHsBvo5s4xB0c1erVngykj7rF3z4gssxWWqxDKS7-euakJIcDYHJR22ovZBQp3JEoUstldpUNTOUJQjZebHM2HjbgyR-bWEAYrTTRU7AyRDdjYkYNbW-fE-uBV26PszDnqfhAfan1KJpuIfaSY39xmc
> 
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2.0 200
< date:Tue, 15 Mar 2016 22:16:31 GMT
< expires:-1
< cache-control:private, max-age=0
< content-type:text/html; charset=ISO-8859-1
< server:gws
< x-xss-protection:1; mode=block
< x-frame-options:SAMEORIGIN
< alternate-protocol:443:quic,p=1
< alt-svc:quic=":443"; ma=2592000; v="31,30,29,28,27,26,25"
< accept-ranges:none
< vary:Accept-Encoding
< 
{ [1170 bytes data]
100 19216    0 19216    0     0  19489      0 --:--:-- --:--:-- --:--:-- 57361
* Connection #3 to host www.google.com left intact

-------------- next part --------------
*   Trying 2a00:1450:4001:805::1013...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* Connected to www.google.com (2a00:1450:4001:805::1013) port 443 (#0)
* found 174 certificates in /etc/ssl/certs/ca-certificates.crt
* ALPN, offering h2
* ALPN, offering http/1.1
  0     0    0     0    0     0      0      0 --:--:--  0:00:01 --:--:--     0* SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
* 	 server certificate verification OK
* 	 server certificate status verification SKIPPED
* 	 common name: www.google.com (matched)
* 	 server certificate expiration date OK
* 	 server certificate activation date OK
* 	 certificate public key: RSA
* 	 certificate version: #3
* 	 subject: C=US,ST=California,L=Mountain View,O=Google Inc,CN=www.google.com
* 	 start date: Wed, 02 Mar 2016 11:08:25 GMT
* 	 expire date: Tue, 31 May 2016 00:00:00 GMT
* 	 issuer: C=US,O=Google Inc,CN=Google Internet Authority G2
* 	 compression: NULL
* ALPN, server accepted to use h2
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* TCP_NODELAY set
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x8be3aa0)
> GET /ncr HTTP/1.1
> Host: www.google.com
> User-Agent: curl/7.47.2-DEV
> Accept: */*
> 
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2.0 302
< location:https://www.google.com/
< cache-control:private
< content-type:text/html; charset=UTF-8
< p3p:CP="This is not a P3P policy! See https://www.google.com/support/accounts/answer/151657?hl=en for more info."
< date:Tue, 15 Mar 2016 22:19:10 GMT
< server:gws
< content-length:220
< x-xss-protection:1; mode=block
< x-frame-options:SAMEORIGIN
* Added cookie NID="77=Hurb2mzgSJuNgd8Ml2DjETqqaShKSTQ7zz-tvpTzZMUYZoL7lIxUWXcLUnKpgsr2wBQEseGVRV05UB0m6BNEMfGwipLfwILNgYu5LWSl5m2Ul6IiGsqqySlqTy9b3ddC" for domain google.com, path /, expire 1473891550
< set-cookie:NID=77=Hurb2mzgSJuNgd8Ml2DjETqqaShKSTQ7zz-tvpTzZMUYZoL7lIxUWXcLUnKpgsr2wBQEseGVRV05UB0m6BNEMfGwipLfwILNgYu5LWSl5m2Ul6IiGsqqySlqTy9b3ddC; expires=Wed, 14-Sep-2016 22:19:10 GMT; path=/; domain=.google.com; HttpOnly
< alternate-protocol:443:quic,p=1
< alt-svc:quic=":443"; ma=2592000; v="31,30,29,28,27,26,25"
< 
* Ignoring the response-body
{ [220 bytes data]
100   220  100   220    0     0    108      0  0:00:02  0:00:02 --:--:--   124
* Connection #0 to host www.google.com left intact
* Issue another request to this URL: 'https://www.google.com/'
* Connection 0 seems to be dead!
* Closing connection 0
* Hostname www.google.com was found in DNS cache
*   Trying 2a00:1450:4001:805::1013...
* Connected to www.google.com (2a00:1450:4001:805::1013) port 443 (#1)
* found 174 certificates in /etc/ssl/certs/ca-certificates.crt
* ALPN, offering h2
* ALPN, offering http/1.1
* SSL re-using session ID
* SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
* 	 server certificate verification OK
* 	 server certificate status verification SKIPPED
* 	 common name: www.google.com (matched)
* 	 server certificate expiration date OK
* 	 server certificate activation date OK
* 	 certificate public key: RSA
* 	 certificate version: #3
* 	 subject: C=US,ST=California,L=Mountain View,O=Google Inc,CN=www.google.com
* 	 start date: Wed, 02 Mar 2016 11:08:25 GMT
* 	 expire date: Tue, 31 May 2016 00:00:00 GMT
* 	 issuer: C=US,O=Google Inc,CN=Google Internet Authority G2
* 	 compression: NULL
* ALPN, server accepted to use h2
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* TCP_NODELAY set
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x8be3aa0)
> GET / HTTP/1.1
> Host: www.google.com
> User-Agent: curl/7.47.2-DEV
> Accept: */*
> Cookie: NID=77=Hurb2mzgSJuNgd8Ml2DjETqqaShKSTQ7zz-tvpTzZMUYZoL7lIxUWXcLUnKpgsr2wBQEseGVRV05UB0m6BNEMfGwipLfwILNgYu5LWSl5m2Ul6IiGsqqySlqTy9b3ddC
> 
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2.0 200
< date:Tue, 15 Mar 2016 22:19:11 GMT
< expires:-1
< cache-control:private, max-age=0
< content-type:text/html; charset=ISO-8859-1
< p3p:CP="This is not a P3P policy! See https://www.google.com/support/accounts/answer/151657?hl=en for more info."
< server:gws
< x-xss-protection:1; mode=block
< x-frame-options:SAMEORIGIN
* Replaced cookie NID="77=PASAKCaQbbS1mn79D3iovTJqQgQ-URT1bMC7IaOtWtbQ06--Wcwu4TvTQh62-Z090HcoP-NWPKdRkIZIIt9_atSlIy5mY3AcH_Tkem71TzHzcMDR-ZdDXgGnVZZvrHE39XnpPh7P73gfmjCx41xSTq4" for domain google.com, path /, expire 1473891551
< set-cookie:NID=77=PASAKCaQbbS1mn79D3iovTJqQgQ-URT1bMC7IaOtWtbQ06--Wcwu4TvTQh62-Z090HcoP-NWPKdRkIZIIt9_atSlIy5mY3AcH_Tkem71TzHzcMDR-ZdDXgGnVZZvrHE39XnpPh7P73gfmjCx41xSTq4; expires=Wed, 14-Sep-2016 22:19:11 GMT; path=/; domain=.google.com; HttpOnly
< alternate-protocol:443:quic,p=1
< alt-svc:quic=":443"; ma=2592000; v="31,30,29,28,27,26,25"
< accept-ranges:none
< vary:Accept-Encoding
< 
{ [1170 bytes data]
100 19206    0 19206    0     0   8124      0 --:--:--  0:00:02 --:--:--  8124
* Connection #1 to host www.google.com left intact
* Found bundle for host www.google.com: 0x8bce750 [can multiplex]
* Connection 1 seems to be dead!
* Closing connection 1
* Hostname www.google.com was found in DNS cache
*   Trying 2a00:1450:4001:805::1013...
* Connected to www.google.com (2a00:1450:4001:805::1013) port 443 (#2)
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* found 174 certificates in /etc/ssl/certs/ca-certificates.crt
* ALPN, offering h2
* ALPN, offering http/1.1
* SSL re-using session ID
* SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
* 	 server certificate verification OK
* 	 server certificate status verification SKIPPED
* 	 common name: www.google.com (matched)
* 	 server certificate expiration date OK
* 	 server certificate activation date OK
* 	 certificate public key: RSA
* 	 certificate version: #3
* 	 subject: C=US,ST=California,L=Mountain View,O=Google Inc,CN=www.google.com
* 	 start date: Wed, 02 Mar 2016 11:08:25 GMT
* 	 expire date: Tue, 31 May 2016 00:00:00 GMT
* 	 issuer: C=US,O=Google Inc,CN=Google Internet Authority G2
* 	 compression: NULL
* ALPN, server accepted to use h2
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* TCP_NODELAY set
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x8be3aa0)
> GET /ncr HTTP/1.1
> Host: www.google.com
> User-Agent: curl/7.47.2-DEV
> Accept: */*
> Cookie: NID=77=PASAKCaQbbS1mn79D3iovTJqQgQ-URT1bMC7IaOtWtbQ06--Wcwu4TvTQh62-Z090HcoP-NWPKdRkIZIIt9_atSlIy5mY3AcH_Tkem71TzHzcMDR-ZdDXgGnVZZvrHE39XnpPh7P73gfmjCx41xSTq4
> 
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2.0 302
< location:https://www.google.com/
< cache-control:private
< content-type:text/html; charset=UTF-8
< date:Tue, 15 Mar 2016 22:19:11 GMT
< server:gws
< content-length:220
< x-xss-protection:1; mode=block
< x-frame-options:SAMEORIGIN
< alternate-protocol:443:quic,p=1
< alt-svc:quic=":443"; ma=2592000; v="31,30,29,28,27,26,25"
< 
* Ignoring the response-body
{ [220 bytes data]
100   220  100   220    0     0    457      0 --:--:-- --:--:-- --:--:--   536
* Connection #2 to host www.google.com left intact
* Issue another request to this URL: 'https://www.google.com/'
* Found bundle for host www.google.com: 0x8fb61f0 [can multiplex]
* Connection 2 seems to be dead!
* Closing connection 2
* Hostname www.google.com was found in DNS cache
*   Trying 2a00:1450:4001:805::1013...
* Connected to www.google.com (2a00:1450:4001:805::1013) port 443 (#3)
* found 174 certificates in /etc/ssl/certs/ca-certificates.crt
* ALPN, offering h2
* ALPN, offering http/1.1
* SSL re-using session ID
* SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
* 	 server certificate verification OK
* 	 server certificate status verification SKIPPED
* 	 common name: www.google.com (matched)
* 	 server certificate expiration date OK
* 	 server certificate activation date OK
* 	 certificate public key: RSA
* 	 certificate version: #3
* 	 subject: C=US,ST=California,L=Mountain View,O=Google Inc,CN=www.google.com
* 	 start date: Wed, 02 Mar 2016 11:08:25 GMT
* 	 expire date: Tue, 31 May 2016 00:00:00 GMT
* 	 issuer: C=US,O=Google Inc,CN=Google Internet Authority G2
* 	 compression: NULL
* ALPN, server accepted to use h2
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* TCP_NODELAY set
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x8be3aa0)
> GET / HTTP/1.1
> Host: www.google.com
> User-Agent: curl/7.47.2-DEV
> Accept: */*
> Cookie: NID=77=PASAKCaQbbS1mn79D3iovTJqQgQ-URT1bMC7IaOtWtbQ06--Wcwu4TvTQh62-Z090HcoP-NWPKdRkIZIIt9_atSlIy5mY3AcH_Tkem71TzHzcMDR-ZdDXgGnVZZvrHE39XnpPh7P73gfmjCx41xSTq4
> 
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2.0 200
< date:Tue, 15 Mar 2016 22:19:12 GMT
< expires:-1
< cache-control:private, max-age=0
< content-type:text/html; charset=ISO-8859-1
< server:gws
< x-xss-protection:1; mode=block
< x-frame-options:SAMEORIGIN
< alternate-protocol:443:quic,p=1
< alt-svc:quic=":443"; ma=2592000; v="31,30,29,28,27,26,25"
< accept-ranges:none
< vary:Accept-Encoding
< 
{ [1170 bytes data]
100 19206    0 19206    0     0  22984      0 --:--:-- --:--:-- --:--:-- 22984
* Connection #3 to host www.google.com left intact


From yumkam at gmail.com  Wed Mar 16 21:34:38 2016
From: yumkam at gmail.com (Yuriy M. Kaminskiy)
Date: Wed, 16 Mar 2016 23:34:38 +0300
Subject: [gnutls-devel] [resent][PATCH] fix SessionTicket when server opted
 for not renewing ticket
Message-ID: <56E9C35E.5080600@gmail.com>

When I played with fixed (wrt ALPN-with-sessions) gnutls library and
curl, I noticed in wireshark capture for

   `curl -v -c jar --location https://www.google.com/ncr 
https://www.google.com/ncr`,

that SessionTickets are used only *once*:

1.ClientHello (empty session id, empty SessionTicket)
   <ServerHello (empty session_id, empty SessionTicket)
   <Certificate
   ClientKeyExchange
   ...
   <NewSessionTicket [1]
   <ChangeCipherSpec
   ChangeCipherSpec
   ...
2.ClientHello (new random session id[2], SessionTicket with data
   from [1])
   <ServerHello (same session id[2], *no* SessionTicket)
   <ChangeCipherSpec
   ...
   (=resumed client/ticket-stored session)
3.ClientHello (same session id[2], *no* SessionTicket extension)
   <ServerHello (*new* random session id[3], *no* SessionTicket extension)
   <Certificate
   ClientKeyExchange
   ...
   <ChangeCipherSpec
   ...
   (=non-resumed full handshake, establish new server-stored session)
4.ClientHello (same session id[3], *no* SessionTicket extension)
   <ServerHello (same session id[3], *no* SessionTicket extension)
   <ChangeCipherSpec
   (=resumed server-stored session)

I've addede debug print of session data in curl, it looks like session
data saved after step 2 is 150+ bytes shorter (apparently, it does not
contain SessionTicket data).

After looking at rfc5077, it looks like server is allowed to resume
session this way, and client should just keep old SessionTicket data.
However, gnutls forgets it instead.

Attached patch (against 3.3.* branch) fixes this issue. With patch applied:

3.ClientHello (same session id[2], SessionTicket from [1])
   <ServerHello (same session id[2], no *SessionTicket extension)
   <ChangeCipherSpec
   ...
   (=resumed client/ticket-stored session, no NewTicket)
4.ClientHello (same session id[2], SessionTicket from [1])
   <ServerHello (same session id[2], *no* SessionTicket extension)
   <ChangeCipherSpec
   (=resumed client/ticket-stored session)

Passes `make check`.

(I also attached *completely untested* patch rebased against git master).

Disclaimer: my knowledge of TLS protocol and gnutls implementation in
particular is rather limited, please review carefully.

(And note that this issue does not really "break things").
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-SessionTicket-keep-old-ticket-when-server-have-not-o.patch
Type: text/x-diff
Size: 2969 bytes
Desc: not available
URL: </pipermail/attachments/20160316/14edec17/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: master-0001-SessionTicket-keep-old-ticket-when-server-have-not-o.patch
Type: text/x-diff
Size: 2939 bytes
Desc: not available
URL: </pipermail/attachments/20160316/14edec17/attachment-0001.patch>

From nmav at gnutls.org  Thu Mar 17 10:46:03 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 17 Mar 2016 10:46:03 +0100
Subject: [gnutls-devel] gnutls 3.4.10 testsuite error on amd64 (SSSE3
 cipher tests failed)
In-Reply-To: <20160316164435.GC1228@argenau.bebt.de>
References: <20160315184405.GB1628@argenau.bebt.de>
 <CAJU7zaKQf_JmNzoZGGGOA0H9+vQJ=EX8kq60oLjuc2GXMjK-Zg@mail.gmail.com>
 <20160316164435.GC1228@argenau.bebt.de>
Message-ID: <CAJU7zaL-5uaGwASBaqQEPnB34-k83HbALofNfNqEQwdYjmmEPw@mail.gmail.com>

On Wed, Mar 16, 2016 at 5:44 PM, Andreas Metzler <ametzler at bebt.de> wrote:
> On 2016-03-16 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
>> On Tue, Mar 15, 2016 at 7:44 PM, Andreas Metzler <ametzler at bebt.de> wrote:
>>> ./test-hash-large failed on one of Debian's autobuilders (AMD Opteron
>>> 23xx):
>>> (sid_amd64-dchroot)ametzler at barriere:~/GNUTLS/gnutls28-3.4.10/tests/slow$ ./test-hash-large --verbose --debug  7777
>>> Illegal instruction
>>> SSSE3 cipher tests failed
>
>> Thanks. It seems that the CPU has no SSSE3 and the test overrides the
>> cpuid to force SSSE3 usage. I'm wondering whether it is better to
>> change the test to detect cpu capabilities via /proc/cpuinfo, or
>> remove the ability to override a CPU flag if the CPU doesn't support
>> it.
>
> Hello,
>
> I thought that GNUTLS_CPUID_OVERRIDE was not supposed to enable
> unavailable features: "Note that CPU detection cannot be overriden,
> i.e., VIA options cannot be enabled on an Intel CPU."

Correct, and the statement is in a way precise :) Only VIA options
cannot be enabled on an Intel CPU. Let's fix that then. Does the
attached patch solves the issue in the system without ssse3?

regards,
Nikos
-------------- next part --------------
diff --git a/lib/accelerated/x86/x86-common.c b/lib/accelerated/x86/x86-common.c
index 18e3710..5cc8c00 100644
--- a/lib/accelerated/x86/x86-common.c
+++ b/lib/accelerated/x86/x86-common.c
@@ -76,18 +76,40 @@ unsigned int _gnutls_x86_cpuid_s[3];
 
 static void capabilities_to_intel_cpuid(unsigned capabilities)
 {
+	unsigned a,b,c,t;
+
 	memset(_gnutls_x86_cpuid_s, 0, sizeof(_gnutls_x86_cpuid_s));
+
 	if (capabilities & EMPTY_SET) {
 		return;
 	}
+
+	gnutls_cpuid(1, &t, &a, &b, &c);
+
 	if (capabilities & INTEL_AES_NI) {
-		_gnutls_x86_cpuid_s[1] |= bit_AES;
+		if (b & bit_AES) {
+			_gnutls_x86_cpuid_s[1] |= bit_AES;
+		} else {
+			_gnutls_debug_log
+			    ("AESNI acceleration requested but not available\n");
+		}
 	}
+
 	if (capabilities & INTEL_SSSE3) {
-		_gnutls_x86_cpuid_s[1] |= bit_SSSE3;
+		if (b & bit_SSSE3) {
+			_gnutls_x86_cpuid_s[1] |= bit_SSSE3;
+		} else {
+			_gnutls_debug_log
+			    ("SSSE3 acceleration requested but not available\n");
+		}
 	}
-	if (capabilities & INTEL_PCLMUL) { /* ecx */
-		_gnutls_x86_cpuid_s[1] |= bit_PCLMUL;
+	if (capabilities & INTEL_PCLMUL) {
+		if (b & bit_PCLMUL) { /* ecx */
+			_gnutls_x86_cpuid_s[1] |= bit_PCLMUL;
+		} else {
+			_gnutls_debug_log
+			    ("PCLMUL acceleration requested but not available\n");
+		}
 	}
 }
 
@@ -111,19 +133,43 @@ static unsigned check_pclmul(void)
 #ifdef ENABLE_PADLOCK
 static unsigned capabilities_to_via_edx(unsigned capabilities)
 {
+	unsigned a,b,c,t;
+
 	memset(_gnutls_x86_cpuid_s, 0, sizeof(_gnutls_x86_cpuid_s));
+
 	if (capabilities & EMPTY_SET) {
 		return 0;
 	}
-	if (capabilities & VIA_PADLOCK) { /* edx */
-		_gnutls_x86_cpuid_s[2] |= via_bit_PADLOCK;
+
+	gnutls_cpuid(1, &t, &a, &b, &c);
+
+	if (capabilities & VIA_PADLOCK) {
+		if (c & via_bit_PADLOCK) {
+			_gnutls_x86_cpuid_s[2] |= via_bit_PADLOCK;
+		} else {
+			_gnutls_debug_log
+			    ("Padlock acceleration requested but not available\n");
+		}
 	}
-	if (capabilities & VIA_PADLOCK_PHE) { /* edx */
-		_gnutls_x86_cpuid_s[2] |= via_bit_PADLOCK_PHE;
+
+	if (capabilities & VIA_PADLOCK_PHE) {
+		if (c & via_bit_PADLOCK_PHE) { /* edx */
+			_gnutls_x86_cpuid_s[2] |= via_bit_PADLOCK_PHE;
+		} else {
+			_gnutls_debug_log
+			    ("Padlock-PHE acceleration requested but not available\n");
+		}
 	}
-	if (capabilities & VIA_PADLOCK_PHE_SHA512) { /* edx */
-		_gnutls_x86_cpuid_s[2] |= via_bit_PADLOCK_PHE_SHA512;
+
+	if (capabilities & VIA_PADLOCK_PHE_SHA512) {
+		if (c & via_bit_PADLOCK_PHE_SHA512) {
+			_gnutls_x86_cpuid_s[2] |= via_bit_PADLOCK_PHE_SHA512;
+		} else {
+			_gnutls_debug_log
+			    ("Padlock-PHE-SHA512 acceleration requested but not available\n");
+		}
 	}
+
 	return _gnutls_x86_cpuid_s[2];
 }
 

From ametzler at bebt.de  Thu Mar 17 19:40:45 2016
From: ametzler at bebt.de (Andreas Metzler)
Date: Thu, 17 Mar 2016 19:40:45 +0100
Subject: [gnutls-devel] gnutls 3.4.10 testsuite error on amd64 (SSSE3
 cipher tests failed)
In-Reply-To: <CAJU7zaL-5uaGwASBaqQEPnB34-k83HbALofNfNqEQwdYjmmEPw@mail.gmail.com>
References: <20160315184405.GB1628@argenau.bebt.de>
 <CAJU7zaKQf_JmNzoZGGGOA0H9+vQJ=EX8kq60oLjuc2GXMjK-Zg@mail.gmail.com>
 <20160316164435.GC1228@argenau.bebt.de>
 <CAJU7zaL-5uaGwASBaqQEPnB34-k83HbALofNfNqEQwdYjmmEPw@mail.gmail.com>
Message-ID: <20160317184045.GB1944@argenau.bebt.de>

On 2016-03-17 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
[...]
> Correct, and the statement is in a way precise :) Only VIA options
> cannot be enabled on an Intel CPU.

;-)

> Let's fix that then. Does the
> attached patch solves the issue in the system without ssse3?

Thank you, works for me:

#previously failing machine:
(sid_amd64-dchroot)ametzler at barriere:~/GNUTLS/gnutls28-3.4.10/tests/slow$ GNUTLS_DEBUG_LEVEL=9 GNUTLS_CPUID_OVERRIDE=0x4 ./hash-large  --verbose --debug=7777
gnutls[2]: Enabled GnuTLS 3.4.10 logging...
gnutls[2]: SSSE3 acceleration requested but not available
gnutls_hash_fast(SHA256) 4295032831 OK
gnutls_hash_fast(SHA256) 4295032831 OK
gnutls_hash_fast(SHA1) OK
gnutls_hmac_fast(SHA1) OK
Self test `./hash-large' finished with 0 errors

#SSE3 supporting machine:
(sid)ametzler at argenau:/tmp/GNUTLS/gnutls-3.4.10/tests/slow$ GNUTLS_DEBUG_LEVEL=9 GNUTLS_CPUID_OVERRIDE=0x4 ./hash-large  --verbose --debug=7777
gnutls[2]: Enabled GnuTLS 3.4.10 logging...
gnutls[2]: Intel SSSE3 was detected
gnutls_hash_fast(SHA256) 4295032831 OK
gnutls_hash_fast(SHA256) 4295032831 OK
gnutls_hash_fast(SHA1) OK
gnutls_hmac_fast(SHA1) OK
Self test `./hash-large' finished with 0 errors

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 Mar 18 09:20:41 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 18 Mar 2016 09:20:41 +0100
Subject: [gnutls-devel] [resent][PATCH] ALPN and session resumption
In-Reply-To: <56E9B946.4020800@gmail.com>
References: <56E9B946.4020800@gmail.com>
Message-ID: <CAJU7zaK1+L2Lc7v1FADcyhC8JiWnpVmExH5S3rKYAQBTPRpkBQ@mail.gmail.com>

On Wed, Mar 16, 2016 at 8:51 PM, Yuriy M. Kaminskiy <yumkam at gmail.com> wrote:
> I've played a bit with curl with HTTP/2 support and gnutls backend (curl git
> master [curl-7_47_1-75-g3c2ef2a], [self-compiled] nghttp2 1.8.0, [distro]
> debian's gnutls 3.3.8), and it looks like ALPN is broken with session
> resumption.
>
>   curl -v -c jar --location https://www.google.com/ncr >log 2>errlog
>
> fails; first connection succeed (got redirect), then second connection
> to same server (resumes session) fails with
>
>   * ALPN, server did not agree to a protocol
>
> If I disable session support:
>   curl -v -c jar --location --no-sessionid https://www.google.com/ncr
> everything works.
>
> I played with gdb, looked at gnutls sources, and found that libgnutls
> neither parse ALPN extension on resume[1], nor re-uses session data[2], as a
> result after session resumption gnutls_alpn_get_selected_protocol() returns
> failure (even though server sent ALPN/h2 in ServerHello).
> I've re-tested with (self-compiled) gnutls 3.3.22, it behaves same.
> I cannot test with 3.4.* atm (missing build-req), but quick look at sources
> suggests bug is still present.

Thank you for reporting that. It may make sense to move the ALPN
extension to the mandatory to parse set. I'll check it, and try to
introduce some checks to detect this issue.

regards,
Nikos


From yumkam at gmail.com  Fri Mar 18 10:53:05 2016
From: yumkam at gmail.com (Yuriy M. Kaminskiy)
Date: Fri, 18 Mar 2016 12:53:05 +0300
Subject: [gnutls-devel] [resent][PATCH] ALPN and session resumption
In-Reply-To: <CAJU7zaK1+L2Lc7v1FADcyhC8JiWnpVmExH5S3rKYAQBTPRpkBQ@mail.gmail.com>
References: <56E9B946.4020800@gmail.com>
 <CAJU7zaK1+L2Lc7v1FADcyhC8JiWnpVmExH5S3rKYAQBTPRpkBQ@mail.gmail.com>
Message-ID: <56EBD001.90205@gmail.com>



On 18.03.2016 11:20, Nikos Mavrogiannopoulos wrote:
> On Wed, Mar 16, 2016 at 8:51 PM, Yuriy M. Kaminskiy <yumkam at gmail.com> wrote:
>> I've played a bit with curl with HTTP/2 support and gnutls backend (curl git
>> master [curl-7_47_1-75-g3c2ef2a], [self-compiled] nghttp2 1.8.0, [distro]
>> debian's gnutls 3.3.8), and it looks like ALPN is broken with session
>> resumption.
>>
>>    curl -v -c jar --location https://www.google.com/ncr >log 2>errlog
>>
>> fails; first connection succeed (got redirect), then second connection
>> to same server (resumes session) fails with
>>
>>    * ALPN, server did not agree to a protocol
>>
>> If I disable session support:
>>    curl -v -c jar --location --no-sessionid https://www.google.com/ncr
>> everything works.
>>
>> I played with gdb, looked at gnutls sources, and found that libgnutls
>> neither parse ALPN extension on resume[1], nor re-uses session data[2], as a
>> result after session resumption gnutls_alpn_get_selected_protocol() returns
>> failure (even though server sent ALPN/h2 in ServerHello).
>> I've re-tested with (self-compiled) gnutls 3.3.22, it behaves same.
>> I cannot test with 3.4.* atm (missing build-req), but quick look at sources
>> suggests bug is still present.
> Thank you for reporting that. It may make sense to move the ALPN
> extension to the mandatory to parse set. I'll check it, and try to
> introduce some checks to detect this issue.
I considered changing it at first, but it would interfere with 
sever-side (GNUTLS_EXT_APPLICATION are parsed *before* running 
user-defined hook, *MANDATORY - after).


From nmav at gnutls.org  Fri Mar 18 11:17:43 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 18 Mar 2016 11:17:43 +0100
Subject: [gnutls-devel] [resent][PATCH] ALPN and session resumption
In-Reply-To: <56EBD001.90205@gmail.com>
References: <56E9B946.4020800@gmail.com>
 <CAJU7zaK1+L2Lc7v1FADcyhC8JiWnpVmExH5S3rKYAQBTPRpkBQ@mail.gmail.com>
 <56EBD001.90205@gmail.com>
Message-ID: <CAJU7zaL2STPWFFxZYvqLumvUDVOUKq6HuSWywJ3HdFr=YaEhwA@mail.gmail.com>

On Fri, Mar 18, 2016 at 10:53 AM, Yuriy M. Kaminskiy <yumkam at gmail.com> wrote:
>>> I played with gdb, looked at gnutls sources, and found that libgnutls
>>> neither parse ALPN extension on resume[1], nor re-uses session data[2],
>>> as a
>>> result after session resumption gnutls_alpn_get_selected_protocol()
>>> returns
>>> failure (even though server sent ALPN/h2 in ServerHello).
>>> I've re-tested with (self-compiled) gnutls 3.3.22, it behaves same.
>>> I cannot test with 3.4.* atm (missing build-req), but quick look at
>>> sources
>>> suggests bug is still present.
>>
>> Thank you for reporting that. It may make sense to move the ALPN
>> extension to the mandatory to parse set. I'll check it, and try to
>> introduce some checks to detect this issue.
> I considered changing it at first, but it would interfere with sever-side
> (GNUTLS_EXT_APPLICATION are parsed *before* running user-defined hook,
> *MANDATORY - after).

Right. That's also desirable. In master the mandatory extensions are
parsed first so
that wouldn't require any change but for 3.3 and 3.4 I'd need to
change that as well
and introduce a check.

regards,
Nikos


From nmav at gnutls.org  Fri Mar 18 13:05:13 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 18 Mar 2016 13:05:13 +0100
Subject: [gnutls-devel] [resent][PATCH] fix SessionTicket when server
 opted for not renewing ticket
In-Reply-To: <56E9C35E.5080600@gmail.com>
References: <56E9C35E.5080600@gmail.com>
Message-ID: <CAJU7zaLZ9vHLez=tFcK6A6WVuj0krS6PwaS+dnVSZQME+XOVgQ@mail.gmail.com>

On Wed, Mar 16, 2016 at 9:34 PM, Yuriy M. Kaminskiy <yumkam at gmail.com> wrote:
> When I played with fixed (wrt ALPN-with-sessions) gnutls library and
> curl, I noticed in wireshark capture for
>
>   `curl -v -c jar --location https://www.google.com/ncr
> https://www.google.com/ncr`,
>
> that SessionTickets are used only *once*:
>
> 1.ClientHello (empty session id, empty SessionTicket)
>   <ServerHello (empty session_id, empty SessionTicket)
>   <Certificate
>   ClientKeyExchange
>   ...
>   <NewSessionTicket [1]
>   <ChangeCipherSpec
>   ChangeCipherSpec
>   ...
> 2.ClientHello (new random session id[2], SessionTicket with data
>   from [1])
>   <ServerHello (same session id[2], *no* SessionTicket)
>   <ChangeCipherSpec
>   ...
>   (=resumed client/ticket-stored session)
> 3.ClientHello (same session id[2], *no* SessionTicket extension)
>   <ServerHello (*new* random session id[3], *no* SessionTicket extension)
>   <Certificate
>   ClientKeyExchange
>   ...
>   <ChangeCipherSpec
>   ...
>   (=non-resumed full handshake, establish new server-stored session)
> 4.ClientHello (same session id[3], *no* SessionTicket extension)
>   <ServerHello (same session id[3], *no* SessionTicket extension)
>   <ChangeCipherSpec
>   (=resumed server-stored session)
>
> I've addede debug print of session data in curl, it looks like session
> data saved after step 2 is 150+ bytes shorter (apparently, it does not
> contain SessionTicket data).
>
> After looking at rfc5077, it looks like server is allowed to resume
> session this way, and client should just keep old SessionTicket data.
> However, gnutls forgets it instead.

Hello Yuriy,
 I am unable to understand which scenario does not work from the
description. Could you describe only the non-working scenario and if
possible provide some reproducer with gnutls-cli or a sample gnutls
application?

regards,
Nikos


From yumkam at gmail.com  Fri Mar 18 14:32:30 2016
From: yumkam at gmail.com (Yuriy M. Kaminskiy)
Date: Fri, 18 Mar 2016 16:32:30 +0300
Subject: [gnutls-devel] [resent][PATCH] fix SessionTicket when server
 opted for not renewing ticket
In-Reply-To: <CAJU7zaLZ9vHLez=tFcK6A6WVuj0krS6PwaS+dnVSZQME+XOVgQ@mail.gmail.com>
References: <56E9C35E.5080600@gmail.com>
 <CAJU7zaLZ9vHLez=tFcK6A6WVuj0krS6PwaS+dnVSZQME+XOVgQ@mail.gmail.com>
Message-ID: <56EC036E.2040207@gmail.com>



On 18.03.2016 15:05, Nikos Mavrogiannopoulos wrote:
> On Wed, Mar 16, 2016 at 9:34 PM, Yuriy M. Kaminskiy <yumkam at gmail.com> wrote:
>> When I played with fixed (wrt ALPN-with-sessions) gnutls library and
>> curl, I noticed in wireshark capture for
>>
>>    `curl -v -c jar --location https://www.google.com/ncr
>> https://www.google.com/ncr`,
>>
>> that SessionTickets are used only *once*:
>>
>> 1.ClientHello (empty session id, empty SessionTicket)
>>    <ServerHello (empty session_id, empty SessionTicket)
>>    <Certificate
>>    ClientKeyExchange
>>    ...
>>    <NewSessionTicket [1]
>>    <ChangeCipherSpec
>>    ChangeCipherSpec
>>    ...
>> 2.ClientHello (new random session id[2], SessionTicket with data
>>    from [1])
>>    <ServerHello (same session id[2], *no* SessionTicket)
>>    <ChangeCipherSpec
>>    ...
>>    (=resumed client/ticket-stored session)
>> 3.ClientHello (same session id[2], *no* SessionTicket extension)
>>    <ServerHello (*new* random session id[3], *no* SessionTicket extension)
>>    <Certificate
>>    ClientKeyExchange
>>    ...
>>    <ChangeCipherSpec
>>    ...
>>    (=non-resumed full handshake, establish new server-stored session)
>> 4.ClientHello (same session id[3], *no* SessionTicket extension)
>>    <ServerHello (same session id[3], *no* SessionTicket extension)
>>    <ChangeCipherSpec
>>    (=resumed server-stored session)
>>
>> I've addede debug print of session data in curl, it looks like session
>> data saved after step 2 is 150+ bytes shorter (apparently, it does not
>> contain SessionTicket data).
>>
>> After looking at rfc5077, it looks like server is allowed to resume
>> session this way, and client should just keep old SessionTicket data.
>> However, gnutls forgets it instead.
>   I am unable to understand which scenario does not work from the
> description. Could you describe only the non-working scenario and if
> possible provide some reproducer with gnutls-cli or a sample gnutls
> application?
You need to resume session 2 or more times, with server that opt for 
*not* renewing ticket (e.g. https://www.google.com show this behavior 
for me).
Run
$ wireshark-gtk -p -f 'tcp && port https' &
Set filter to ssl.handshake, start capture.
$ gnutls-cli --inline-commands www.google.com
^resume^
^resume^

Current behavior: SessionTicket is used only once, on 2nd resume 
SessionTicket is not sent by client, and 2nd resume fails (fallbacks^1 
to full handshake), 3rd and following uses server-side sessions and 
don't even try to use SessionTicket (look for presence of "SessionTicket 
TLS" extension in ClientHello).

Correct behavior (with my patch): SessionTicket is used all times (empty 
on first connect, same data on all following), full handshake is used 
only on first connect.

^1 once again, this is *not* a user-visible error, it correctly handled 
inside gnutls. Only problem - tiny bit larger resource consumption (and 
server-side [non-SessionTicket] sessions are more heavy for server).


From nmav at gnutls.org  Mon Mar 21 11:25:01 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 21 Mar 2016 11:25:01 +0100
Subject: [gnutls-devel] [resent][PATCH] fix SessionTicket when server
 opted for not renewing ticket
In-Reply-To: <56EC036E.2040207@gmail.com>
References: <56E9C35E.5080600@gmail.com>
 <CAJU7zaLZ9vHLez=tFcK6A6WVuj0krS6PwaS+dnVSZQME+XOVgQ@mail.gmail.com>
 <56EC036E.2040207@gmail.com>
Message-ID: <CAJU7zaJk9d3mnG7uWbfYgH9MJoaSA3yCYcEMk7bUJRL-bhBY_g@mail.gmail.com>

On Fri, Mar 18, 2016 at 2:32 PM, Yuriy M. Kaminskiy <yumkam at gmail.com> wrote:
>>> After looking at rfc5077, it looks like server is allowed to resume
>>> session this way, and client should just keep old SessionTicket data.
>>> However, gnutls forgets it instead.
>>
>>   I am unable to understand which scenario does not work from the
>> description. Could you describe only the non-working scenario and if
>> possible provide some reproducer with gnutls-cli or a sample gnutls
>> application?
>
> You need to resume session 2 or more times, with server that opt for *not*
> renewing ticket (e.g. https://www.google.com show this behavior for me).
> Run
> $ wireshark-gtk -p -f 'tcp && port https' &
> Set filter to ssl.handshake, start capture.
> $ gnutls-cli --inline-commands www.google.com
> ^resume^
> ^resume^

That seems to be a limitation of gnutls-cli.
gnutls_session_get_data2() can only be called on non-resumed sessions,
and gnutls-cli does call it on resumed as well causing the issue that
you notice. Fixing gnutls-cli to conform to the documented behavior
fixes the issue. Could that be the same happening in curl?

I'm thinking if that's a commonly used pattern maybe we can fix the
API to store any value provided by gnutls_session_set_data() and
return the same value by gnutls_session_get_data*() if it is not a
resumed value. This however would increase memory usage in such a
session.

regards,
Nikos


From jaak.ristioja at cyber.ee  Mon Mar 21 11:41:54 2016
From: jaak.ristioja at cyber.ee (Jaak Ristioja)
Date: Mon, 21 Mar 2016 12:41:54 +0200
Subject: [gnutls-devel] [PATCH] Broke apart _gnutls_recv_int() to the
 packet and non-packet cases.
In-Reply-To: <1455531292-10204-1-git-send-email-jaak.ristioja@cyber.ee>
References: <1455531292-10204-1-git-send-email-jaak.ristioja@cyber.ee>
Message-ID: <56EFCFF2.1090507@cyber.ee>

Postponed, rejected or forgotten?

On 15.02.2016 12:14, Jaak Ristioja wrote:
> Only gnutls_record_recv_packet() called _gnutls_recv_int() with
> (packet != NULL). I refactored this logic directly downstream into
> gnutls_record_recv_packet(). The _gnutls_recv_int() function now only
> handles non-packet specific logic. The _gnutls_recv_int2() function
> was created to deduplicate common code which would otherwise have
> ended up in both functions.
> 
> The rationale behind this change is to optimize what were previously
> calls of _gnutls_recv_int(). First of all _gnutls_recv_int() now has
> only 6 parameters, which according to the x86_64 System V Application
> Binary Interface should now fit into CPU registers and no longer use
> the stack. Secondly this change avoids a number of branching checks
> for both packet and non-packet cases.
> ---
>  lib/ext/heartbeat.c |   2 +-
>  lib/handshake.c     |   2 +-
>  lib/record.c        | 103 ++++++++++++++++++++++++++++++----------------------
>  lib/record.h        |   1 -
>  4 files changed, 62 insertions(+), 46 deletions(-)
> 
> diff --git a/lib/ext/heartbeat.c b/lib/ext/heartbeat.c
> index cc13508..77d990b 100644
> --- a/lib/ext/heartbeat.c
> +++ b/lib/ext/heartbeat.c
> @@ -229,7 +229,7 @@ gnutls_heartbeat_ping(gnutls_session_t session, size_t data_size,
>  
>  	case SHB_RECV:
>  		ret =
> -		    _gnutls_recv_int(session, GNUTLS_HEARTBEAT, NULL,
> +		    _gnutls_recv_int(session, GNUTLS_HEARTBEAT,
>  				     NULL, 0, NULL,
>  				     session->internals.
>  				     hb_actual_retrans_timeout_ms);
> diff --git a/lib/handshake.c b/lib/handshake.c
> index 3d7a153..82f605b 100644
> --- a/lib/handshake.c
> +++ b/lib/handshake.c
> @@ -3104,7 +3104,7 @@ static int recv_handshake_final(gnutls_session_t session, int init)
>  
>  		ret =
>  		    _gnutls_recv_int(session, GNUTLS_CHANGE_CIPHER_SPEC,
> -				     NULL, ccs, ccs_len, NULL, tleft);
> +				     ccs, ccs_len, NULL, tleft);
>  		if (ret <= 0) {
>  			ERR("recv ChangeCipherSpec", ret);
>  			gnutls_assert();
> diff --git a/lib/record.c b/lib/record.c
> index a2f8637..713dd94 100644
> --- a/lib/record.c
> +++ b/lib/record.c
> @@ -301,7 +301,7 @@ int gnutls_bye(gnutls_session_t session, gnutls_close_request_t how)
>  			do {
>  				ret =
>  				    _gnutls_recv_int(session, GNUTLS_ALERT,
> -						     NULL, NULL, 0, NULL,
> +						     NULL, 0, NULL,
>  						     session->internals.
>  						     record_timeout_ms);
>  			}
> @@ -1356,23 +1356,13 @@ _gnutls_recv_in_buffers(gnutls_session_t session, content_type_t type,
>  		return ret;
>  }
>  
> -/* This function behaves exactly like read(). The only difference is
> - * that it accepts the gnutls_session_t and the content_type_t of data to
> - * receive (if called by the user the Content is Userdata only)
> - * It is intended to receive data, under the current session.
> - */
> -ssize_t
> -_gnutls_recv_int(gnutls_session_t session, content_type_t type,
> -		 gnutls_packet_t *packet,
> -		 uint8_t * data, size_t data_size, void *seq,
> -		 unsigned int ms)
> +/* Returns a value greater than zero (>= 0) if buffers should be checked
> + * for data. */
> +static ssize_t
> +_gnutls_recv_int2(gnutls_session_t session)
>  {
>  	int ret;
>  
> -	if (packet == NULL && (type != GNUTLS_ALERT && type != GNUTLS_HEARTBEAT)
> -	    && (data_size == 0 || data == NULL))
> -		return gnutls_assert_val(GNUTLS_E_INVALID_REQUEST);
> -
>  	if (session->internals.read_eof != 0) {
>  		/* if we have already read an EOF
>  		 */
> @@ -1390,37 +1380,48 @@ _gnutls_recv_int(gnutls_session_t session, content_type_t type,
>  			return gnutls_assert_val(ret);
>  
>  		session->internals.recv_state = RECV_STATE_0;
> +		/* Fall through: */
>  	case RECV_STATE_0:
>  
>  		_dtls_async_timer_check(session);
> +		return 1;
> +	default:
> +		return gnutls_assert_val(GNUTLS_E_INTERNAL_ERROR);
> +	}
> +}
>  
> -		if (packet == NULL) {
> -			/* If we have enough data in the cache do not bother receiving
> -			 * a new packet. (in order to flush the cache)
> -			 */
> -			ret = check_buffers(session, type, data, data_size, seq);
> -			if (ret != 0)
> -				return ret;
> +/* This function behaves exactly like read(). The only difference is
> + * that it accepts the gnutls_session_t and the content_type_t of data to
> + * receive (if called by the user the Content is Userdata only)
> + * It is intended to receive data, under the current session.
> + */
> +ssize_t
> +_gnutls_recv_int(gnutls_session_t session, content_type_t type,
> +		 uint8_t * data, size_t data_size, void *seq,
> +		 unsigned int ms)
> +{
> +	int ret;
>  
> -			ret = _gnutls_recv_in_buffers(session, type, -1, ms);
> -			if (ret < 0 && ret != GNUTLS_E_SESSION_EOF)
> -				return gnutls_assert_val(ret);
> +	if ((type != GNUTLS_ALERT && type != GNUTLS_HEARTBEAT)
> +	    && (data_size == 0 || data == NULL))
> +		return gnutls_assert_val(GNUTLS_E_INVALID_REQUEST);
>  
> -			return check_buffers(session, type, data, data_size, seq);
> -		} else {
> -			ret = check_packet_buffers(session, type, packet);
> -			if (ret != 0)
> -				return ret;
> +	ret = _gnutls_recv_int2(session);
> +	if (ret <= 0)
> +		return ret;
>  
> -			ret = _gnutls_recv_in_buffers(session, type, -1, ms);
> -			if (ret < 0 && ret != GNUTLS_E_SESSION_EOF)
> -				return gnutls_assert_val(ret);
> +	/* If we have enough data in the cache do not bother receiving
> +	 * a new packet. (in order to flush the cache)
> +	 */
> +	ret = check_buffers(session, type, data, data_size, seq);
> +	if (ret != 0)
> +		return ret;
>  
> -			return check_packet_buffers(session, type, packet);
> -		}
> -	default:
> -		return gnutls_assert_val(GNUTLS_E_INTERNAL_ERROR);
> -	}
> +	ret = _gnutls_recv_in_buffers(session, type, -1, ms);
> +	if (ret < 0 && ret != GNUTLS_E_SESSION_EOF)
> +		return gnutls_assert_val(ret);
> +
> +	return check_buffers(session, type, data, data_size, seq);
>  }
>  
>  /**
> @@ -1511,9 +1512,25 @@ ssize_t
>  gnutls_record_recv_packet(gnutls_session_t session, 
>  		   	  gnutls_packet_t *packet)
>  {
> -	return _gnutls_recv_int(session, GNUTLS_APPLICATION_DATA, packet,
> -				NULL, 0, NULL,
> -				session->internals.record_timeout_ms);
> +	int ret;
> +
> +	if (packet == NULL)
> +		return gnutls_assert_val(GNUTLS_E_INVALID_REQUEST);
> +
> +	ret = _gnutls_recv_int2(session);
> +	if (ret <= 0)
> +		return ret;
> +
> +	ret = check_packet_buffers(session, GNUTLS_APPLICATION_DATA, packet);
> +	if (ret != 0)
> +		return ret;
> +
> +	ret = _gnutls_recv_in_buffers(session, GNUTLS_APPLICATION_DATA, -1,
> +	                              session->internals.record_timeout_ms);
> +	if (ret < 0 && ret != GNUTLS_E_SESSION_EOF)
> +		return gnutls_assert_val(ret);
> +
> +	return check_packet_buffers(session, GNUTLS_APPLICATION_DATA, packet);
>  }
>  
>  /**
> @@ -1694,7 +1711,7 @@ int gnutls_record_uncork(gnutls_session_t session, unsigned int flags)
>  ssize_t
>  gnutls_record_recv(gnutls_session_t session, void *data, size_t data_size)
>  {
> -	return _gnutls_recv_int(session, GNUTLS_APPLICATION_DATA, NULL,
> +	return _gnutls_recv_int(session, GNUTLS_APPLICATION_DATA,
>  				data, data_size, NULL,
>  				session->internals.record_timeout_ms);
>  }
> @@ -1723,7 +1740,7 @@ ssize_t
>  gnutls_record_recv_seq(gnutls_session_t session, void *data,
>  		       size_t data_size, unsigned char *seq)
>  {
> -	return _gnutls_recv_int(session, GNUTLS_APPLICATION_DATA, NULL,
> +	return _gnutls_recv_int(session, GNUTLS_APPLICATION_DATA,
>  				data, data_size, seq,
>  				session->internals.record_timeout_ms);
>  }
> diff --git a/lib/record.h b/lib/record.h
> index d029586..f16df47 100644
> --- a/lib/record.h
> +++ b/lib/record.h
> @@ -45,7 +45,6 @@ _gnutls_send_int(gnutls_session_t session, content_type_t type,
>  }
>  
>  ssize_t _gnutls_recv_int(gnutls_session_t session, content_type_t type,
> -			 gnutls_packet_t *packet,
>  			 uint8_t * data,
>  			 size_t sizeofdata, void *seq, unsigned int ms);
>  
> 



From jaak.ristioja at cyber.ee  Mon Mar 21 12:09:58 2016
From: jaak.ristioja at cyber.ee (Jaak Ristioja)
Date: Mon, 21 Mar 2016 13:09:58 +0200
Subject: [gnutls-devel] [PATCH] Broke apart _gnutls_recv_int() to the
 packet and non-packet cases.
In-Reply-To: <CAJU7zaKNHD3skqAm3px+uHrTgueZdnsxATDPkJD33bDJJsVt3A@mail.gmail.com>
References: <1455531292-10204-1-git-send-email-jaak.ristioja@cyber.ee>
 <56EFCFF2.1090507@cyber.ee>
 <CAJU7zaKNHD3skqAm3px+uHrTgueZdnsxATDPkJD33bDJJsVt3A@mail.gmail.com>
Message-ID: <56EFD686.1010809@cyber.ee>

On 21.03.2016 13:04, Nikos Mavrogiannopoulos wrote:
> On Mon, Mar 21, 2016 at 11:41 AM, Jaak Ristioja <jaak.ristioja at cyber.ee> wrote:
>> Postponed, rejected or forgotten?
>>
>> On 15.02.2016 12:14, Jaak Ristioja wrote:
>>> Only gnutls_record_recv_packet() called _gnutls_recv_int() with
>>> (packet != NULL). I refactored this logic directly downstream into
>>> gnutls_record_recv_packet(). The _gnutls_recv_int() function now only
>>> handles non-packet specific logic. The _gnutls_recv_int2() function
>>> was created to deduplicate common code which would otherwise have
>>> ended up in both functions.
>>>
>>> The rationale behind this change is to optimize what were previously
>>> calls of _gnutls_recv_int(). First of all _gnutls_recv_int() now has
>>> only 6 parameters, which according to the x86_64 System V Application
>>> Binary Interface should now fit into CPU registers and no longer use
>>> the stack. Secondly this change avoids a number of branching checks
>>> for both packet and non-packet cases.
> 
> Must have lost it. I've now committed it with some minor tweaks
> (function name changes).

No problem. Thanks! :)

J



From nmav at gnutls.org  Mon Mar 21 12:04:15 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 21 Mar 2016 12:04:15 +0100
Subject: [gnutls-devel] [PATCH] Broke apart _gnutls_recv_int() to the
 packet and non-packet cases.
In-Reply-To: <56EFCFF2.1090507@cyber.ee>
References: <1455531292-10204-1-git-send-email-jaak.ristioja@cyber.ee>
 <56EFCFF2.1090507@cyber.ee>
Message-ID: <CAJU7zaKNHD3skqAm3px+uHrTgueZdnsxATDPkJD33bDJJsVt3A@mail.gmail.com>

On Mon, Mar 21, 2016 at 11:41 AM, Jaak Ristioja <jaak.ristioja at cyber.ee> wrote:
> Postponed, rejected or forgotten?
>
> On 15.02.2016 12:14, Jaak Ristioja wrote:
>> Only gnutls_record_recv_packet() called _gnutls_recv_int() with
>> (packet != NULL). I refactored this logic directly downstream into
>> gnutls_record_recv_packet(). The _gnutls_recv_int() function now only
>> handles non-packet specific logic. The _gnutls_recv_int2() function
>> was created to deduplicate common code which would otherwise have
>> ended up in both functions.
>>
>> The rationale behind this change is to optimize what were previously
>> calls of _gnutls_recv_int(). First of all _gnutls_recv_int() now has
>> only 6 parameters, which according to the x86_64 System V Application
>> Binary Interface should now fit into CPU registers and no longer use
>> the stack. Secondly this change avoids a number of branching checks
>> for both packet and non-packet cases.

Must have lost it. I've now committed it with some minor tweaks
(function name changes).


From yumkam at gmail.com  Mon Mar 21 14:08:10 2016
From: yumkam at gmail.com (Yuriy M. Kaminskiy)
Date: Mon, 21 Mar 2016 16:08:10 +0300
Subject: [gnutls-devel] [resent][PATCH] fix SessionTicket when server
 opted for not renewing ticket
In-Reply-To: <CAJU7zaJk9d3mnG7uWbfYgH9MJoaSA3yCYcEMk7bUJRL-bhBY_g@mail.gmail.com>
References: <56E9C35E.5080600@gmail.com>
 <CAJU7zaLZ9vHLez=tFcK6A6WVuj0krS6PwaS+dnVSZQME+XOVgQ@mail.gmail.com>
 <56EC036E.2040207@gmail.com>
 <CAJU7zaJk9d3mnG7uWbfYgH9MJoaSA3yCYcEMk7bUJRL-bhBY_g@mail.gmail.com>
Message-ID: <56EFF23A.20800@gmail.com>

On 21.03.2016 13:25, Nikos Mavrogiannopoulos wrote:
> On Fri, Mar 18, 2016 at 2:32 PM, Yuriy M. Kaminskiy <yumkam at gmail.com> wrote:
>>>> After looking at rfc5077, it looks like server is allowed to resume
>>>> session this way, and client should just keep old SessionTicket data.
>>>> However, gnutls forgets it instead.
>>>    I am unable to understand which scenario does not work from the
>>> description. Could you describe only the non-working scenario and if
>>> possible provide some reproducer with gnutls-cli or a sample gnutls
>>> application?
>> You need to resume session 2 or more times, with server that opt for *not*
>> renewing ticket (e.g. https://www.google.com show this behavior for me).
>> Run
>> $ wireshark-gtk -p -f 'tcp && port https' &
>> Set filter to ssl.handshake, start capture.
>> $ gnutls-cli --inline-commands www.google.com
>> ^resume^
>> ^resume^
> That seems to be a limitation of gnutls-cli.
> gnutls_session_get_data2() can only be called on non-resumed sessions,
> and gnutls-cli does call it on resumed as well causing the issue that
> you notice. Fixing gnutls-cli to conform to the documented behavior
> fixes the issue. Could that be the same happening in curl?

Hmm? Yes, this is documented, however it is only *recently* documented 
(at 2015-02-24, after gnutls-3.3.12).
(However, it looks like only documented pre-existing [for long time?] 
behavior)

And it looks like it will break another rfc5077-conforming server behavior:
=== cut rfc5077 ===
     If the server successfully verifies the client's ticket, then it may
     renew the ticket by including a NewSessionTicket handshake message
     after the ServerHello.
=== cut ===

That is, session resumed, however server also issued *new* ticket. If 
client won't not save this *new* ticket, next resume will (probably) fail.

(Disclaimer: untested, I don't know which servers exhibit this behavior)

> I'm thinking if that's a commonly used pattern maybe we can fix the
> API to store any value provided by gnutls_session_set_data() and
> return the same value by gnutls_session_get_data*() if it is not a
> resumed value. This however would increase memory usage in such a
> session.
Well, let's look 
https://codesearch.debian.net/search?perpkg=1&q=gnutls_session_get_data

wget: does something strange
wpa, filezilla, curl, lftp, bitlbee, reaver: does not check is_resumed 
before get_data (a number of projects embeds curl code)
glib-networking, neon27: only saves new data if session is not resumed 
(a number of projects embeds neon code)


From nmav at gnutls.org  Wed Mar 23 10:09:26 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 23 Mar 2016 10:09:26 +0100
Subject: [gnutls-devel] [resent][PATCH] fix SessionTicket when server
 opted for not renewing ticket
In-Reply-To: <56EFF23A.20800@gmail.com>
References: <56E9C35E.5080600@gmail.com>
 <CAJU7zaLZ9vHLez=tFcK6A6WVuj0krS6PwaS+dnVSZQME+XOVgQ@mail.gmail.com>
 <56EC036E.2040207@gmail.com>
 <CAJU7zaJk9d3mnG7uWbfYgH9MJoaSA3yCYcEMk7bUJRL-bhBY_g@mail.gmail.com>
 <56EFF23A.20800@gmail.com>
Message-ID: <1458724166.1837.7.camel@gnutls.org>

On Mon, 2016-03-21 at 16:08 +0300, Yuriy M. Kaminskiy wrote:

> > > $ wireshark-gtk -p -f 'tcp && port https' &
> > > Set filter to ssl.handshake, start capture.
> > > $ gnutls-cli --inline-commands www.google.com
> > > ^resume^
> > > ^resume^
> > That seems to be a limitation of gnutls-cli.
> > gnutls_session_get_data2() can only be called on non-resumed 
> > sessions,
> > and gnutls-cli does call it on resumed as well causing the issue 
> > that
> > you notice. Fixing gnutls-cli to conform to the documented behavior
> > fixes the issue. Could that be the same happening in curl?
> 
> Hmm? Yes, this is documented, however it is only *recently* 
> documented 
> (at 2015-02-24, after gnutls-3.3.12).
> (However, it looks like only documented pre-existing [for long time?] 
> 
> behavior)
> 
> And it looks like it will break another rfc5077-conforming server 
> behavior:
> === cut rfc5077 ===
>      If the server successfully verifies the client's ticket, then it 
> may
>      renew the ticket by including a NewSessionTicket handshake 
> message
>      after the ServerHello.
> === cut ===
> 
> That is, session resumed, however server also issued *new* ticket. If 
> 
> client won't not save this *new* ticket, next resume will (probably) 
> fail.

Then the proper fix would be to make gnutls_session_get_data2() to work
irrespective of the status of the session (resumed or not). This was
also be backwards compatible and would not affect any programs relying
the previous semantics. Would you be interested in making a patch
towards that path?

I've opened a ticket for it at:
https://gitlab.com/gnutls/gnutls/issues/79

regards,
Nikos