Closed
Bug 545755
Opened 15 years ago
Closed 15 years ago
Update Mozilla stable branches to NSS 3.12.6 and minimal support for RFC 5746
Categories
(Core :: Security: PSM, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: KaiE, Assigned: KaiE)
References
Details
(Keywords: verified1.9.1, verified1.9.2, Whiteboard: [sg:high])
Attachments
(3 files, 2 obsolete files)
23 bytes,
patch
|
dveditz
:
approval1.9.2.2+
dveditz
:
approval1.9.1.9+
|
Details | Diff | Splinter Review |
20.30 KB,
patch
|
KaiE
:
review+
dveditz
:
approval1.9.1.9+
|
Details | Diff | Splinter Review |
20.73 KB,
patch
|
KaiE
:
review+
dveditz
:
approval1.9.2.2+
|
Details | Diff | Splinter Review |
I'm filing a separate bug for branch-landing, because we want a slightly different mix of patches in comparison to what we do on trunk = mozilla-central.
We'd like to land NSS 3.12.6 as per bug 527659 and necessary configure and PSM makefile tweaks, which includes the patch to disable (NSS-new) support for TLS-compression and the compilation fix for moz-sqlite from bug 519550 on top of that NSS release.
We'd like to include the error string addition from bug 540332, however, because of the localization problem on stable branches, we'll potentially land only half of that patch on the stable branch (string error codes yes, human readable strings maybe not).
We'd like to include the patch v6 from bug 535649, however, with a difference in preferences. More specifically, we might not yet want to change the default behaviour regarding renegotiation on old-protocol SSL/TLS sockets. We consider to use:
pref("security.ssl.allow_unrestricted_renego_everywhere__temporarily_available_pref", true);
This will still allow any kind of connections, even the few unsafe renegotiations that we're able to detect, but we'll start spamming the error console, reporting the not-yet-upgraded sites to users.
I'll make a combination of patches and attach them.
I'll not ask for reviews of patches, as the patches will be identical besides the two minor changes/omissions. I'll rather ask a PSM peer to state that this procedure is OK for the stable branches.
Dan, Johnathan, I think this is what you consider the reasonable approach, but please let me know if I'm wrong.
Which branches?
I think we want
mozilla-1.9.2 for Firefox 3.6.x
and
mozilla-1.9.1 for Firefox 3.5.x
(which will also affect Thunderbird 3 et. al.)
I believe we're targetting mid-end March, 3.5.9 and 3.6.3
Assignee | ||
Comment 1•15 years ago
|
||
We don't need patch from bug 519550 on stable branches, because the stable branches don't yet use the moz prefix for sqlite.
Assignee | ||
Comment 2•15 years ago
|
||
I see both 1.9.1 and 1.9.2 have already been upgraded to NSPR 4.8.3, I guess that's sufficient for NSS 3.12.6
Assignee | ||
Comment 3•15 years ago
|
||
Requesting approval flag for 1.9.2.3 and 1.9.1.9
(flag 1.9.2.3 is not here yet, so I'm requesting 1.9.2.2 as a reminder to create that flag)
Attachment #427115 -
Flags: approval1.9.2.2?
Attachment #427115 -
Flags: approval1.9.1.9?
Assignee | ||
Comment 4•15 years ago
|
||
Comment on attachment 427115 [details] [diff] [review]
Update Mozilla to NSS 3.12.6 (approval collector)
I won't attach the full patch of all NSS changes, it's huge, and it can be easily produced by using "cvs diff", comparing current the proposed NSS tag with the current NSS tag.
On both mozilla-1.9.1 and mozilla-1.9.2 the currently used version is NSS 3.12.4.5
The landing of the final 3.12.6 release will either include a fix to bug 546389, or I'll add a fix on top of it.
Assignee | ||
Comment 5•15 years ago
|
||
Merged version of reviewed patches from bug 527659, bug 540332, bug 535649.
Branch version of merged patch uses default value "true" for
security.ssl.allow_unrestricted_renego_everywhere__temporarily_available_pref
Attachment #427119 -
Flags: review+
Attachment #427119 -
Flags: approval1.9.1.9?
Assignee | ||
Comment 6•15 years ago
|
||
From bug 540332.
The code using these strings is failsafe, it will either show or omit them.
Attachment #427120 -
Flags: review+
Assignee | ||
Updated•15 years ago
|
Attachment #427120 -
Flags: approval1.9.1.9?
Assignee | ||
Comment 7•15 years ago
|
||
Attachment #427121 -
Flags: review+
Attachment #427121 -
Flags: approval1.9.2.2?
Assignee | ||
Comment 8•15 years ago
|
||
Comment on attachment 427121 [details] [diff] [review]
mandatory patch for 3.12.6 landing into mozilla-1.9.2
Merged version of reviewed patches from bug 527659, bug 540332, bug 535649.
Branch version of merged patch uses default value "true" for
security.ssl.allow_unrestricted_renego_everywhere__temporarily_available_pref
Assignee | ||
Comment 9•15 years ago
|
||
From bug 540332.
The code using these strings is failsafe, it will either show or omit them.
Attachment #427122 -
Flags: review+
Attachment #427122 -
Flags: approval1.9.2.2?
Assignee | ||
Comment 10•15 years ago
|
||
Testing:
I've built 1.9.1 and 1.9.2 and I get correct test results on site ssltls.de
Assignee | ||
Comment 11•15 years ago
|
||
Axel, this is the spin-off from bug 535649 and bug 540332, for stable branches, where we consider to land strings.
See the patches labeled "optional" attached to this bug.
I'm completely neutral whether to land them or not. Landing them is nice, not landing them won't hurt.
Comment 12•15 years ago
|
||
No new strings for either 1.9.1 nor 1.9.2.
Assignee | ||
Comment 13•15 years ago
|
||
Comment on attachment 427120 [details] [diff] [review]
optional additional string patch for 3.12.6 landing into mozilla-1.9.1 / mozilla-1.9.2
Removing approval request and marking as obsolete, as Axel rejected this optional patch.
Attachment #427120 -
Attachment description: optional additional string patch for 3.12.6 landing into mozilla-1.9.1 → optional additional string patch for 3.12.6 landing into mozilla-1.9.1 / mozilla-1.9.2
Attachment #427120 -
Attachment is obsolete: true
Attachment #427120 -
Flags: approval1.9.1.9?
Assignee | ||
Updated•15 years ago
|
Attachment #427122 -
Attachment is obsolete: true
Attachment #427122 -
Flags: approval1.9.2.2?
Assignee | ||
Comment 14•15 years ago
|
||
(In reply to comment #10)
> Testing:
> I've built 1.9.1 and 1.9.2 and I get correct test results on site ssltls.de
If you'd like to see the effect of the missing error string, in comparison to trunk where the string is available, you can visit:
https://www.startssl.com/logon.ssl
(on branches will show error code "ssl_error_renegotiation_not_allowed", but no human readable explanation.)
(Testing ability will go away once that server gets upgraded)
Updated•15 years ago
|
status1.9.1:
--- → wanted
status1.9.2:
--- → wanted
Comment 15•15 years ago
|
||
Do we now need to update these patches with 3.12.6-rtm ? or do you want to handle that in a separate patch?
Assignee | ||
Comment 16•15 years ago
|
||
I think your question is, are there changes between NSS 3.12.6 release candidates and NSS 3.12.6 final release that require us to update the PSM code?
No.
Although NSS has changed its default, it doesn't matter for PSM, because PSM overrides the defaults and sets its own desired behaviour explicitly (based on (default) prefs).
Comment 17•15 years ago
|
||
The summary of this bug sounds like it covers NSS too, and afaik we are currently using NSS 3.12.6-rc0 (maybe rc1?). Are we going to upgrade to 3.12.6-rtm (rc2) as part of this bug, in a different bug, or not at all?
Also, in order to land in the stable branches we need to change the default for security.ssl.allow_unrestricted_renego_everywhere__temporarily_available_pref to true -- we don't want to break any current server uses with the initial landing. Just the console warnings and the ability for people to opt into better security.
Assignee | ||
Comment 18•15 years ago
|
||
(In reply to comment #17)
> The summary of this bug sounds like it covers NSS too, and afaik we are
> currently using NSS 3.12.6-rc0 (maybe rc1?). Are we going to upgrade to
> 3.12.6-rtm (rc2) as part of this bug, in a different bug, or not at all?
I don't propose to land betas or release candidates to stable branches.
Yes, my intention of this bug is to upgrade both NSS to 3.12.6 -final- and in addition take the PSM patch attached.
The 3.12.6 -final- is about to be released today or tomorrow (same as rc2), and I plan to upgrade mozilla-central, first.
> Also, in order to land in the stable branches we need to change the default for
> security.ssl.allow_unrestricted_renego_everywhere__temporarily_available_pref
> to true -- we don't want to break any current server uses with the initial
> landing.
The attached patch(es) already do(es) that! :)
The patches attached to this bug are adjusted versions of the mozilla-central patches, adjusted for the stable branches. They change the default pref, they omit the strings.
> Just the console warnings and the ability for people to opt into
> better security.
Yes
Updated•15 years ago
|
Attachment #427115 -
Flags: approval1.9.2.2?
Attachment #427115 -
Flags: approval1.9.2.2+
Attachment #427115 -
Flags: approval1.9.1.9?
Attachment #427115 -
Flags: approval1.9.1.9+
Comment 19•15 years ago
|
||
Comment on attachment 427119 [details] [diff] [review]
mandatory patch for 3.12.6 landing into mozilla-1.9.1
Approved for 1.9.1.9, a=dveditz for release-drivers
Attachment #427119 -
Flags: approval1.9.1.9? → approval1.9.1.9+
Comment 20•15 years ago
|
||
Comment on attachment 427121 [details] [diff] [review]
mandatory patch for 3.12.6 landing into mozilla-1.9.2
Approved for 1.9.2.2, a=dveditz for release-drivers
Attachment #427121 -
Flags: approval1.9.2.2? → approval1.9.2.2+
Assignee | ||
Comment 21•15 years ago
|
||
Assignee | ||
Updated•15 years ago
|
Assignee | ||
Comment 22•15 years ago
|
||
Assignee | ||
Updated•15 years ago
|
Assignee | ||
Updated•15 years ago
|
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Updated•15 years ago
|
Flags: wanted1.9.0.x-
Updated•15 years ago
|
Blocks: C191ConfSync
Updated•15 years ago
|
Blocks: C192ConfSync
Updated•15 years ago
|
Whiteboard: [sg:high]
Comment 23•15 years ago
|
||
Verified that these landed on the branches, see links in comment#20 and comment#21. Also see testing statement in comment#10.
Keywords: verified1.9.1,
verified1.9.2
Updated•15 years ago
|
Blocks: 535649, moz-rfc5746
You need to log in
before you can comment on or make changes to this bug.
Description
•