[Date Prev][Date Next]
Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
On 10/03/2012 02:33 AM, email@example.com wrote:
> On Tuesday 02 of October 2012 14:01:16, firstname.lastname@example.org wrote:
>> 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.
This was my fault - just a straight up coding error. I take the blame
>> 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.
I have been active in the openldap community - mailing lists, irc - in
answering questions about openldap + moznss. My assumption is that any
TLS/SSL problems with openldap on RHEL/Fedora/CentOS are problems with
the moznss code. I realize that it is a support burden because the
first instinct of a user is to blame openldap. I try to deflect as much
of that as possible towards Red Hat. I try to get people who are paid
RHEL users to go through support. I try to get "free" users to file bugs.
> Sometimes a security bug appears. We are not flawless. I do not know how we
> should take the blame. The CVE clearly stated that this is a problem only with
> Mozilla NSS backend. Which is used only by Fedora, RHEL, and their derivates.
> And the affected code was from RH, anyone can see it in VCS. Tell me what did
> you expect us to do and we can try to do it next time.
> If our users have a problem, they should first contact our support. Or create
> a bug in our issue tracker. We cannot prevent them from contacting upstream.
> And you can always say them 'Sorry, we cannot help you.' if the question is
> not general enough or the problem depends on our build.
> I understand that you don't want to support older OpenLDAP versions, builds
> with non-default libraries, etc. But the users will rather use the package
> from their distribution, instead of compiling it by themselves. And we cannot
> support users' builds, because we do not have the sources and the build
> environment under control. And we cannot rebase the packages freely.
> On Tuesday 02 of October 2012 14:18:49, email@example.com wrote:
>> Back to this point - surely OpenLDAP libldap is not the only piece of
>> software that expects to use OpenSSL-style cipher suite names. libldap is
>> certainly not the best place to put this translation.
> I'm not sure about that. We tried to go a "compatible" way with OpenLDAP,
> don't know about other projects. I will take a look.
This is the nss_compat_ossl library approach, which attempts to make
moznss look as much like openssl as possible to applications. I thought
about trying to use that with openldap a few years ago when we first
started looking at having openldap support moznss, but Howard had
already done a great deal of work to make the tls code "pluggable" with
tls2.c and tls_m.c, which takes the approach of using the moznss code
directly rather than indirectly through another layer . This has been
the preferred approach of the Red Hat and Fedora teams that were
attempting to replace openssl with moznss. nss_compat_ossl has not been
actively worked on for a couple of years, and would require many changes
to support multi-init, multiple key/cert databases, and other fixes that
have gone into tls_m.c.
I suppose we could try to get some sort of openssl cipher name support
directly in upstream moznss, but they would probably assert that it
doesn't belong there either.
Maybe we could use nss_compat_ossl to do the mapping of cipher names
from openssl to moznss?