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
