On 10/07/2013 11:19 AM, Ryan Sleevi wrote: > On Mon, October 7, 2013 11:07 am, Robert Relyea wrote: >> On 10/04/2013 06:52 PM, Ludovic Hirlimann wrote: >>> Hi, >>> >>> AFAIK NSS still contains code for SSL2 , but no product uses it. SSL2 >>> has been turned off at least 2 years ago. By removing SSL2 code we get : >>> >>> Smaller librarie >>> faster compile time + test time >>> >>> What do you guys think ? >>> >>> Ludo >> That's something we would like to do, but we do have downstreams that >> can't remove it yet. >> We could make it a compile option so it can be compiled out (which will >> get most of the benefits most of the time). >> >> bob >> >> -- >> dev-tech-crypto mailing list >> dev-tech-crypto@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-tech-crypto > Adding compile-time flags (and the accompanying #define soup) can almost > end up worse - it prevents graceful cleanup/refactoring work that would > also come with dead code removal. refactoring isn't one of the features we could support until the code is removed (at least easily)... nor was it one of the things Ludo was looking for (at least in the mail). Though the SSL 2 code is not as intertwined as some of the other features. I think it's basically the gather and caching code that is really the only code that is affected by ssl2. There doesn't seem to be any code in ssl3con.c and sslcon.c is strictly SSL2 (well there's some code that calls ssl3 if you are using the compatible hello, but you don't need that code if you are strictly ssl3/tls). > > Bob, could you provide more information about these downstreams using it? > 1) Are they staying up to date with NSS? eg: If they're stuck on NSS > 3.12.x, what should it matter about removing it in 3.16?
It's Red Hat. We are staying up to date with NSS. Unfortunately I also have to support features in that version of the OS. So when we change defaults upstream, the don't necessarily get changed in NSS itself. > 2) If so, is the reason for doing so security patches/updates? Mozilla requires NSS rebases as new version of Mozilla are released. > 3) If so, why would they have SSL 2.0 enabled and yet still be following > security updates? They're at odds with eachother. This is the way enterprise support works. Enterprise customers work on decade long support cycles. We've had these discussions before, which is why we have started working on making sure that we aren't locked in for another 10 years at Red Hat. Our customers are really sensitive to these kinds of changes 'mid release'. It's the fact the NSS upstream has supported these that even allows us to do things like update the browser. > > I'd like to see us be able to come up with clear exit criteria for > removing this feature. I can appreciate "It's being used", but can you > provide more details about why and how, so that we can have a more > productive discussion about what it would mean and take to remove this > code? We understand that we want to remove several pieces of code from NSS. That is why we have disabled the ability to even enable SSL2 in RHEL-7. Actually the bar is quite a bit lower than in the past. In the past we could never really rip any code out. bob > > Cheers, > Ryan >
smime.p7s
Description: S/MIME Cryptographic Signature
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
