Closed Bug 1172128 Opened 9 years ago Closed 9 years ago

Undo the freebl/softoken RSA/DH/DSA minimum key size increases in bug 1138554

Categories

(NSS :: Libraries, defect, P1)

3.19.1

Tracking

(Not tracked)

RESOLVED FIXED
3.19.2

People

(Reporter: wtc, Assigned: wtc)

References

Details

Attachments

(1 file)

Attached patch Proposed patch (deleted) — Splinter Review
In bug 1138554 comment 84, Ryan reported that the fix for bug 1138554 breaks an NSS-based application that needs to generate or import an RSA/DH/DSA key shorter than 1023 bits. The proposed patch does two things: 1. It reverts the freebl/softoken RSA, DH, and DSA minimum key sizes to the original values in NSS 3.19. (I chose to simply revert because nobody has suggested what the appropriate freebl/softoken minimum key sizes should be.) 2. It adds three SSL-specific macros for the minimum server key sizes accepted by the clients. We should treat this bug as a regression with urgency.
Attachment #8616195 - Flags: review?(martin.thomson)
Comment on attachment 8616195 [details] [diff] [review] Proposed patch r+ rrelyea. I have not clobbered the review request for martin because I'm still interested in martin's feedback. bob
Attachment #8616195 - Flags: review+
Comment on attachment 8616195 [details] [diff] [review] Proposed patch Review of attachment 8616195 [details] [diff] [review]: ----------------------------------------------------------------- Sorry for missing this; I've been out of town.
Attachment #8616195 - Flags: review?(martin.thomson) → review+
I don't mind either way here. Minimums will always be set low for compatibility reasons, and that is lower than I think ideal. I suspect that the right thing to do is make the minimum values for libssl configurable. Firefox enforces its own limits for that reason. Note that this will affect some of the changes that were landed in Firefox. cc :keeler.
If you can land this and request uplift by tomorrow evening, this can make it into 39 Beta 5. There is one more week to land changes for Beta 7 (our last of this 4 week short cycle.)
Flags: needinfo?(wtc)
needinfoing mt and rbarnes since it looks like Wan-Teh may be on vacation for the next couple of weeks.
Flags: needinfo?(rlb)
Flags: needinfo?(martin.thomson)
This is unlikely to make the next beta. And it doesn't need to. The changes here require backouts for the extra fixes added in bug 1166031 if it lands. Since this doesn't affect Firefox, other than by messing with our tests, I'm going to recommend that we wait for the normal release cycle to clean this up.
Flags: needinfo?(martin.thomson)
Martin: please check in this patch for me. Thanks. Also, we should release an NSS release soon to address this bug. The minimum sizes for freebl/softoken can still be increased. Since nobody came forward with suggestions, I decided to go back to the original minimum sizes so that we can make the important changes quickly.
Flags: needinfo?(wtc)
(In reply to Martin Thomson [:mt:] from comment #6) > > The changes here require backouts for the extra fixes added in bug 1166031 > if it lands. Martin: which fixes need to be backed out? None of the patches in bug 1166031 seem to depend on the minimum key sizes of freebl/softoken or lib/cryptohi.
Flags: needinfo?(rlb) → needinfo?(martin.thomson)
I think that we would need to backout attachment 8613120 [details] [diff] [review]. The others look OK. Do you want me to apply a 3.19.2 beta1 tag so that we can get this into mozilla-central?
Flags: needinfo?(martin.thomson)
https://hg.mozilla.org/projects/nss/rev/2b29dfe134a5 I got the attribution wrong here, but it's there.
Oh, got it. I misunderstood an email from rbarnes to mean this should land. Thanks martin and wan-teh.
(In reply to Martin Thomson [:mt:] from comment #9) > I think that we would need to backout attachment 8613120 [details] [diff] [review]. Could you explain why? I didn't revert any of the SECKEY_BigIntegerBitLength changes. > Do you want me to apply a 3.19.2 beta1 tag so that we can get this into > mozilla-central? Yes, please. Thank you very much for your help.
Actually I was wrong about the attachment, David made the numbers bigger, which should be OK.
Blocks: 1174102
(In reply to Martin Thomson [:mt:] from comment #10) > https://hg.mozilla.org/projects/nss/rev/2b29dfe134a5 > > I got the attribution wrong here, but it's there. marking fixed in NSS
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Liz, FYI: We consider NSS a separate product, with its own release cycles. The NSS library is consumed by multiple parties, in addition to Firefox. Linux distributions consume NSS and Firefox separately. For that reason, Firefox release versions must always use release version of NSS. Although this bug marks the issue as fixed in NSS, tracking the fix for Firefox is done separately. I've filed 1174102 to track upgrading Firefox to the NSS release with this fix.
Blocks: 1176097
Blocks: 1176101
Thanks Kai. Any explanations are super useful to me and I appreciate them. I know it is a separate entity but I think we do decide how quickly or how hard we can uplift NSS updates. For example, we could choose to do a point release on the current version of Firefox (38.0.5) but will likely not do that. (Which is what we would have to do if the Firefox release version needed to use the release version of NSS)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: