Jan Vcelak wrote:
Of course, cipher suite enumeration in MozNSS is possible. But translation from OpenSSL names without the translation table would be very messy. I still think this is a better solution.
There were 11 MozNSS patches in 2.4.32. Looks like 5 more waiting for review here, plus 2 already committed for 2.4.33. We will not accept patches that require constant revisiting every time NSS updates. This is too much. No more.
I'm sending one patch per change. And looking at the patches, I do not think I'm introducing new bugs. It's mostly a fixes for issues present in the code before I started sending my first patches. And be sure that I'm testing the TLS heavily before submitting anything.
I do not understand why you strictly refuse anything which comes from Fedora or Red Hat. We decided to use MozNSS and you can disagree. We still want to fix the problems with that backend to use it without any pain. Sorry, I really do not feel like your feedback is constructive.
Let's be very clear. I'm not rejecting patches because they come from Red Hat. Anyone can plainly see that we have accepted many patches from Red Hat. I'm rejecting patches because the relevant code sucks, and when things related to them break, the OpenLDAP Project takes the heat even though we're not responsible for the breakage. There are CVEs issued against OpenLDAP security holes, even though the bugs are in MozNSS, not OpenLDAP. I wouldn't have a problem with these patches if they actually worked, or if Red Hat took the blame when they don't work, but that's not what has happened. Instead we get CVE-2012-2668. We get users asking why their TLS connections don't work after upgrading from one RedHat release to the next. We get a pointless support burden because users say "we have to run the Red Hat packages otherwise they won't support us" but then they don't actually ask Red Hat for support, they ask us.
It may seem like this feedback is not constructive, but to me it is not productive for the Project to support a crypto library that was designed for use in a web browser and still assumes that its callers always have a human user sitting in front. Bugs like #7316 shouldn't ever have happened.
None of this should come as a surprise to you since I've been stating this from the very first moment MozNSS support was ever mentioned. The NSS crypto architecture was never suited for any setting other than a single user application. It is completely inappropriate for use as a multi-user system library, or in a headless server environment. That was true 4 years ago when we first started working with it and it clearly hasn't improved by today.