4f54ef76a3278370fafb9861a91dbf5241bbbe0b: set version unmber NSS_3_36_BRANCH NSS_3_36_4_RTM
Franziskus Kiefer <franziskuskiefer@gmail.com> - Tue, 05 Jun 2018 11:54:46 +0200 - rev 14391
Push 3118 by franziskuskiefer@gmail.com at Tue, 05 Jun 2018 09:55:48 +0000
set version unmber
18b8dfeceb77550a0f6649b0477af8990563b736: Added tag NSS_3_37_2_RTM for changeset 0556d8c00a42 NSS_3_37_BRANCH
Franziskus Kiefer <franziskuskiefer@gmail.com> - Tue, 05 Jun 2018 10:21:40 +0200 - rev 14390
Push 3117 by franziskuskiefer@gmail.com at Tue, 05 Jun 2018 08:23:30 +0000
Added tag NSS_3_37_2_RTM for changeset 0556d8c00a42
0556d8c00a42f78dde7fe10d18d9b056ce36ae72: clang-format NSS_3_37_BRANCH NSS_3_37_2_RTM
Franziskus Kiefer <franziskuskiefer@gmail.com> - Tue, 05 Jun 2018 10:21:14 +0200 - rev 14389
Push 3117 by franziskuskiefer@gmail.com at Tue, 05 Jun 2018 08:23:30 +0000
clang-format
5b95c5c7b28121b7476c4a2e8907eac5cd5cb8ca: Added tag NSS_3_36_3_RTM for changeset 197e03b510a0 NSS_3_36_BRANCH
Franziskus Kiefer <franziskuskiefer@gmail.com> - Mon, 04 Jun 2018 17:52:28 +0200 - rev 14388
Push 3116 by franziskuskiefer@gmail.com at Mon, 04 Jun 2018 15:53:06 +0000
Added tag NSS_3_36_3_RTM for changeset 197e03b510a0
197e03b510a05b9675e4b78eed3661598205020d: fix abi and clang-format, a=me NSS_3_36_BRANCH NSS_3_36_3_RTM
Franziskus Kiefer <franziskuskiefer@gmail.com> - Mon, 04 Jun 2018 16:25:04 +0200 - rev 14387
Push 3116 by franziskuskiefer@gmail.com at Mon, 04 Jun 2018 15:53:06 +0000
fix abi and clang-format, a=me
20cb9179495d925c8a9c70ae051ac9635b2c89ce: Bug 1466073 - update hacl* revision and fix image build, r=jcj
Franziskus Kiefer <franziskuskiefer@gmail.com> - Mon, 04 Jun 2018 11:08:25 +0200 - rev 14386
Push 3115 by franziskuskiefer@gmail.com at Mon, 04 Jun 2018 14:20:05 +0000
Bug 1466073 - update hacl* revision and fix image build, r=jcj Differential Revision: https://phabricator.services.mozilla.com/D1528
a2d51195427ab3af84e2d8d9a2a3cefbd94bdf60: Bug 1461731 - wait indefinitely in nssSlot_IsTokenPresent; r=rrelyea,fkiefer NSS_3_36_BRANCH
Nathan Froyd <froydnj@mozilla.com> - Wed, 30 May 2018 10:29:53 -0400 - rev 14385
Push 3114 by franziskuskiefer@gmail.com at Mon, 04 Jun 2018 13:37:22 +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.
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
(0) -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 tip