c368cc029700ec15be4a583bf8294e9ff1b07f81: Bug 1466468 - coverity CID 1435922: Uninitialized members in RecordSizeDefaultsTest, r=mt
Franziskus Kiefer <franziskuskiefer@gmail.com> - Mon, 04 Jun 2018 09:11:24 +0200 - rev 14384
Push 3113 by franziskuskiefer@gmail.com at Mon, 04 Jun 2018 08:29:39 +0000
Bug 1466468 - coverity CID 1435922: Uninitialized members in RecordSizeDefaultsTest, r=mt Differential Revision: https://phabricator.services.mozilla.com/D1527
8002af887838cf420ae71bc7d719d5922eadb212: Bug 1466365 - Add a missing test for MAC failure. r=mt
EKR <ekr@rtfm.com> - Sat, 02 Jun 2018 11:10:37 -0700 - rev 14383
Push 3112 by ekr@mozilla.com at Sun, 03 Jun 2018 00:58:28 +0000
Bug 1466365 - Add a missing test for MAC failure. r=mt Reviewers: mt Tags: #secure-revision Differential Revision: https://phabricator.services.mozilla.com/D1517
bde45e406ea449f0a6259814587b8508539802d5: Bug 1396487 - Record size limiting extension, r=ekr
Martin Thomson <martin.thomson@gmail.com> - Fri, 24 Nov 2017 16:40:22 +1100 - rev 14382
Push 3111 by martin.thomson@gmail.com at Fri, 01 Jun 2018 09:10:49 +0000
Bug 1396487 - Record size limiting extension, r=ekr Summary: See draft-ietf-tls-record-limit for details. Reviewers: ekr Bug #: 1396487 Differential Revision: https://phabricator.services.mozilla.com/D23
2209bddb98b8d105159998b9be91a155aa6bd283: Bug 1432455 - Build FStar.c when not building with int128 support. r=fkiefer NSS_3_37_BRANCH
Mike Hommey <mh@glandium.org> - Sun, 27 May 2018 16:20:00 +0200 - rev 14381
Push 3110 by franziskuskiefer@gmail.com at Thu, 31 May 2018 12:58:56 +0000
Bug 1432455 - Build FStar.c when not building with int128 support. r=fkiefer
97ba6eed6d8beb366e01eba5970b452282910e6a: Bug 1461731 - wait indefinitely in nssSlot_IsTokenPresent; r=rrelyea,fkiefer NSS_3_37_BRANCH
Nathan Froyd <froydnj@mozilla.com> - Wed, 30 May 2018 10:29:53 -0400 - rev 14380
Push 3110 by franziskuskiefer@gmail.com at Thu, 31 May 2018 12:58:56 +0000
Bug 1461731 - wait indefinitely in nssSlot_IsTokenPresent; r=rrelyea,fkiefer Crashes for a particular hang have been spiking in the last month, and all the crashes are associated with macOS 10.12 and 10.13. The crashes look like this: Thread 1: waiting on a condition variable in nssSlot_IsTokenPresent Thread 2: waiting on the (contended) lock in nssSlot_IsTokenPresent Thread 3: waiting on the (contended) lock in nssSlot_IsTokenPresent Thread 2 and 3 are waiting on the lock associated with the condition variable that thread 1 is holding. One would expect that thread 1 would drop the lock associated with the condition variable when the wait occurs, and enable thread 2 or thread 3 to make progress. But the particular wait in question passes a (relative) timeout of zero (which corresponds to what would be PR_INTERVAL_NO_WAIT), which is unusual in NSS code and condition variable-using programs in general. A relative timeout of zero on macOS needs to be translated to an absolute time for the underlying API, pthread_cond_timedwait. What appears to be happening is that some absolute time, $NOW, is determined before calling pthread_cond_timedwait. We then call into pthread_cond_timedwait and do whatever work we need to do before checking whether the specified time ($NOW) has passed. Of course it has; we are at some time $NOW + epsilon, and so the wait times out. The wait appears to time out without the lock ever being released; if the lock was released, even if ever-so-shortly, presumably one of the other threads would be able to make progress. Since the hang only occurs on macOS 10.12 and 10.13, we are assuming that there was some change in the condition variable code that attempts to optimize extremely short timeouts, or treats timeouts of zero differently (even if inadvertently). The other possibility is this is the way macOS has always worked, and the crash data we have is only for those versions of the operating system. In any event, there's no need to specify a timeout of zero here. We can specify an "infinite" wait instead (PR_INTERVAL_NO_TIMEOUT) and let another thread make progress, waking us up when it is done.
8232a58332dda55059b02430b93d09aabf93d840: Bug 1461731 - wait indefinitely in nssSlot_IsTokenPresent; r=rrelyea,fkiefer
Nathan Froyd <froydnj@mozilla.com> - Wed, 30 May 2018 10:29:53 -0400 - rev 14379
Push 3109 by franziskuskiefer@gmail.com at Thu, 31 May 2018 12:55:33 +0000
Bug 1461731 - wait indefinitely in nssSlot_IsTokenPresent; r=rrelyea,fkiefer Crashes for a particular hang have been spiking in the last month, and all the crashes are associated with macOS 10.12 and 10.13. The crashes look like this: Thread 1: waiting on a condition variable in nssSlot_IsTokenPresent Thread 2: waiting on the (contended) lock in nssSlot_IsTokenPresent Thread 3: waiting on the (contended) lock in nssSlot_IsTokenPresent Thread 2 and 3 are waiting on the lock associated with the condition variable that thread 1 is holding. One would expect that thread 1 would drop the lock associated with the condition variable when the wait occurs, and enable thread 2 or thread 3 to make progress. But the particular wait in question passes a (relative) timeout of zero (which corresponds to what would be PR_INTERVAL_NO_WAIT), which is unusual in NSS code and condition variable-using programs in general. A relative timeout of zero on macOS needs to be translated to an absolute time for the underlying API, pthread_cond_timedwait. What appears to be happening is that some absolute time, $NOW, is determined before calling pthread_cond_timedwait. We then call into pthread_cond_timedwait and do whatever work we need to do before checking whether the specified time ($NOW) has passed. Of course it has; we are at some time $NOW + epsilon, and so the wait times out. The wait appears to time out without the lock ever being released; if the lock was released, even if ever-so-shortly, presumably one of the other threads would be able to make progress. Since the hang only occurs on macOS 10.12 and 10.13, we are assuming that there was some change in the condition variable code that attempts to optimize extremely short timeouts, or treats timeouts of zero differently (even if inadvertently). The other possibility is this is the way macOS has always worked, and the crash data we have is only for those versions of the operating system. In any event, there's no need to specify a timeout of zero here. We can specify an "infinite" wait instead (PR_INTERVAL_NO_TIMEOUT) and let another thread make progress, waking us up when it is done.
b2d99d984272464df6752f133d88472306359815: Bug 1464778 - tstclnt - Check pollset[STDIN_FD] before accessing r=franziskus
Tim Taubert <ttaubert@mozilla.com> - Wed, 30 May 2018 09:27:51 +0200 - rev 14378
Push 3108 by ttaubert@mozilla.com at Wed, 30 May 2018 07:28:41 +0000
Bug 1464778 - tstclnt - Check pollset[STDIN_FD] before accessing r=franziskus Reviewers: franziskus Reviewed By: franziskus Bug #: 1464778 Differential Revision: https://phabricator.services.mozilla.com/D1433
1ca362213631d6edc885b6b965b52ecffcf29afd: Bug 1457716 - bustage fix, r=ttaubert
Franziskus Kiefer <franziskuskiefer@gmail.com> - Tue, 29 May 2018 17:01:05 +0200 - rev 14377
Push 3107 by franziskuskiefer@gmail.com at Tue, 29 May 2018 15:38:18 +0000
Bug 1457716 - bustage fix, r=ttaubert
c1f2ee7a941e00a4048acdd4e70f6a3e3dc308fb: Bug 1457716 - bustage fix for exporting of SECITEM_MakeItem, a=bustage
Martin Thomson <martin.thomson@gmail.com> - Tue, 29 May 2018 15:15:57 +1000 - rev 14376
Push 3106 by martin.thomson@gmail.com at Tue, 29 May 2018 05:18:52 +0000
Bug 1457716 - bustage fix for exporting of SECITEM_MakeItem, a=bustage
f08049a0df4abac67c156925c78bf5b5b223d22a: Bug 1457716 - Fix CertificateRequest processing for TLS 1.3. r=mt
EKR <ekr@rtfm.com> - Sun, 29 Apr 2018 21:24:28 -0700 - rev 14375
Push 3105 by ekr@mozilla.com at Mon, 28 May 2018 20:37:10 +0000
Bug 1457716 - Fix CertificateRequest processing for TLS 1.3. r=mt Reviewers: mt Tags: #secure-revision Bug #: 1457716 Differential Revision: https://phabricator.services.mozilla.com/D1062
3d3e34bb75172462c7b4bbe7bd5e3e47ed65e464: Bug 1432455 - Build FStar.c when not building with int128 support. r=fkiefer
Mike Hommey <mh@glandium.org> - Sun, 27 May 2018 16:20:00 +0200 - rev 14374
Push 3104 by franziskuskiefer@gmail.com at Mon, 28 May 2018 12:45:53 +0000
Bug 1432455 - Build FStar.c when not building with int128 support. r=fkiefer
8e600e2af5bf0c29e88f928471e6aba1a734d05b: Bug 1461075 - use getentropy() on OpenBSD, r=franziskus
Landry Breuil <landry@openbsd.org> - Mon, 21 May 2018 00:10:00 +0200 - rev 14373
Push 3103 by franziskuskiefer@gmail.com at Mon, 28 May 2018 12:33:32 +0000
Bug 1461075 - use getentropy() on OpenBSD, r=franziskus
2f3ace03cbf89e9300c2dd09da2317a82e382791: Bug 430198, bustage fix, Windows doesn't have strncasecmp, use equivalent NSPR function PL_strncasecmp
Kai Engert <kaie@kuix.de> - Thu, 24 May 2018 19:57:29 +0200 - rev 14372
Push 3102 by kaie@kuix.de at Thu, 24 May 2018 17:56:37 +0000
Bug 430198, bustage fix, Windows doesn't have strncasecmp, use equivalent NSPR function PL_strncasecmp
bf3c9e2318aa70fa8875813b272659acb21421fe: Bug 430198, certutil capability: generate CSR from orphan private key, adding a test, r=rrelyea
Kai Engert <kaie@kuix.de> - Thu, 24 May 2018 18:22:28 +0200 - rev 14371
Push 3101 by kaie@kuix.de at Thu, 24 May 2018 16:21:42 +0000
Bug 430198, certutil capability: generate CSR from orphan private key, adding a test, r=rrelyea
54b4da2b8991595888e8432169ed2daaf96ad6b5: Bug 430198, certutil capability: generate CSR from orphan private key, r=kaie
Fraser Tweedale <frase@frase.id.au> - Thu, 24 May 2018 18:21:50 +0200 - rev 14370
Push 3101 by kaie@kuix.de at Thu, 24 May 2018 16:21:42 +0000
Bug 430198, certutil capability: generate CSR from orphan private key, r=kaie
16645cb510db99eb6d4d034a27a7b9ffb6281161: Bug 1462627, add new option --simple-self-signed for certutil -O, r=rrelyea
Kai Engert <kaie@kuix.de> - Thu, 24 May 2018 18:10:01 +0200 - rev 14369
Push 3100 by kaie@kuix.de at Thu, 24 May 2018 16:09:10 +0000
Bug 1462627, add new option --simple-self-signed for certutil -O, r=rrelyea
328d235fc7eefe7411bb32b4806203220636a60f: Bug 1423018 - Retain write polling when 0-RTT is enabled, r=ekr
Martin Thomson <martin.thomson@gmail.com> - Tue, 28 Nov 2017 15:56:47 +1100 - rev 14368
Push 3099 by martin.thomson@gmail.com at Thu, 24 May 2018 05:26:53 +0000
Bug 1423018 - Retain write polling when 0-RTT is enabled, r=ekr This is a nasty one. I was having trouble with tstclnt when testing against other implementations. It would hang. I made similar changes to that for kazuho and picotls, where the input file is read for every connection. So, I did that here too and it also worked nicely. In order to get 0-RTT working though, I needed to teach ssl_Poll about 0-RTT. Luckily, there was code already there for that and it just needed a tweak. The only thing I ran into here was that boringssl (the server I was using to test against here), was too fast. By the time we had written out the ClientHello, it had produced a response and we would complete the handshake before leaving the handshake loop in ssl3_Do1stHandshake(). That meant that we would never actually send any 0-RTT data, either before or after this patch. Adding a sleep(1) to the handshake in boringssl did the trick and I could show that we can send data before the handshake completes. Nothing really actionable here unless you can think of ways to make our handshake more performant. Mostly just information. Separately, people have noticed that tstclnt writes 0-RTT after the first round trip. That's a symptom of not retaining the poll on write.
60ea633b7c4121eae3ece559359daa6300dcbbdc: Bug 1463379 - [CID 1435689] Dereferencing null pointer "cx" r=jcj
Tim Taubert <ttaubert@mozilla.com> - Wed, 23 May 2018 14:07:30 +0200 - rev 14367
Push 3098 by ttaubert@mozilla.com at Wed, 23 May 2018 12:08:29 +0000
Bug 1463379 - [CID 1435689] Dereferencing null pointer "cx" r=jcj Reviewers: jcj Reviewed By: jcj Bug #: 1463379 Differential Revision: https://phabricator.services.mozilla.com/D1347
aca2bdbd8823e85f71d8138fcd2c1f2edebefd85: Added tag NSS_3_37_1_RTM for changeset a89d294083a6 NSS_3_37_BRANCH
J.C. Jones <jjones@mozilla.com> - Tue, 22 May 2018 07:57:58 -0700 - rev 14366
Push 3097 by jjones@mozilla.com at Tue, 22 May 2018 14:59:08 +0000
Added tag NSS_3_37_1_RTM for changeset a89d294083a6
a89d294083a6a3717d698f71b3acb9099b0ab838: Bug 1460673 - handle p12 properly, r=ttaubert NSS_3_37_BRANCH NSS_3_37_1_RTM
Franziskus Kiefer <franziskuskiefer@gmail.com> - Wed, 16 May 2018 10:24:05 +0200 - rev 14365
Push 3097 by jjones@mozilla.com at Tue, 22 May 2018 14:59:08 +0000
Bug 1460673 - handle p12 properly, r=ttaubert Differential Revision: https://phabricator.services.mozilla.com/D1295
(0) -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 tip