OpenLDAP
Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest

Viewing Incoming/7367
Full headers

From: jvcelak@redhat.com
Subject: [PATCH] MozNSS: update list of supported cipher suites
Compose comment
Download message
State:
0 replies:
19 followups: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

Major security issue: yes  no

Notes:

Notification:


Date: Thu, 23 Aug 2012 15:08:34 +0000
From: jvcelak@redhat.com
To: openldap-its@OpenLDAP.org
Subject: [PATCH] MozNSS: update list of supported cipher suites
Full_Name: Jan Vcelak
Version: git master
OS: Linux
URL: ftp://ftp.openldap.org/incoming/jvcelak-20120823-moznss-update-list-of-cipher-suites.patch
Submission from: (NULL) (209.132.186.34)


I'm attaching patch which updates the list of supported cipher suites for
Mozilla NSS backend. All ciphers currently implemented in NSS (3.13.5) are
included.

Default ciphers are selected on the same basis as in OpenSSL.
NULL/EXPORT/LOW/MEDIUM/HIGH classification is taken from OpenSSL as well.


The attached file is derived from OpenLDAP Software. All of the modifications to
OpenLDAP Software represented in the following patch(es) were developed by Red
Hat. Red Hat has not assigned rights and/or interest in this work to any party.
I, Jan Vcelak am authorized by Red Hat, my employer, to release this work under
the following terms. 

Red Hat hereby place the following modifications to OpenLDAP Software (and only
these modifications) into the public domain. Hence, these modifications may be
freely used and/or redistributed for any purpose with or without attribution
and/or other notice. 

Followup 1

Download message
Date: Mon, 01 Oct 2012 08:53:31 -0700
From: Howard Chu <hyc@symas.com>
To: jvcelak@redhat.com
CC: openldap-its@openldap.org
Subject: Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
jvcelak@redhat.com wrote:
> Full_Name: Jan Vcelak
> Version: git master
> OS: Linux
> URL: ftp://ftp.openldap.org/incoming/jvcelak-20120823-moznss-update-list-of-cipher-suites.patch
> Submission from: (NULL) (209.132.186.34)
>
>
> I'm attaching patch which updates the list of supported cipher suites for
> Mozilla NSS backend. All ciphers currently implemented in NSS (3.13.5) are
> included.

Recall what I said in ITS#7388 about an endless stream of patches to an 
unmaintainable code base...

This is completely the wrong approach. There is no way you should be putting 
hardcoded constants in libldap that are tied to specific MozNSS versions. The 
MozNSS library needs to provide a cipher enumerator API.

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.

Tell the NSS guys to fix their design, or tell Red Hat to use a crypto library 
that actually works for the intended purpose. MozNSS clearly doesn't.

> Default ciphers are selected on the same basis as in OpenSSL.
> NULL/EXPORT/LOW/MEDIUM/HIGH classification is taken from OpenSSL as well.
>
>
> The attached file is derived from OpenLDAP Software. All of the
modifications to
> OpenLDAP Software represented in the following patch(es) were developed by
Red
> Hat. Red Hat has not assigned rights and/or interest in this work to any
party.
> I, Jan Vcelak am authorized by Red Hat, my employer, to release this work
under
> the following terms.
>
> Red Hat hereby place the following modifications to OpenLDAP Software (and
only
> these modifications) into the public domain. Hence, these modifications may
be
> freely used and/or redistributed for any purpose with or without
attribution
> and/or other notice.
>
>


-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/



Followup 2

Download message
Date: Tue, 2 Oct 2012 07:19:50 -0400 (EDT)
From: Jan Vcelak <jvcelak@redhat.com>
To: hyc@symas.com
Cc: openldap-its@openldap.org
Subject: Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher
 suites
> This is completely the wrong approach. There is no way you should be
> putting
> hardcoded constants in libldap that are tied to specific MozNSS
> versions. The
> MozNSS library needs to provide a cipher enumerator API.

Let me quote OpenLDAP documentation:

| When using Mozilla NSS, the OpenSSL cipher suite specifications are
| used and translated into the format used internally by Mozilla NSS.

And FAQ page about Mozilla NSS in OpenLDAP:

| OpenLDAP can use Mozilla NSS as the TLS/SSL implementation. If you
| previously used OpenLDAP with OpenSSL, and have certificate files,
| cipher suites, and other TLS settings specified in your configuration
| files, those settings should work exactly the same way with Mozilla
| NSS - OpenLDAP with Mozilla NSS knows how to read those settings,
| files, etc. and apply them in the same way. The goal is that you
| will not be able to tell you are using OpenLDAP with Mozilla NSS
| because it will work exactly the same as OpenLDAP with OpenSSL.

Which means that if we decided at some point to make the MozNSS layer
compatible with OpenSSL, we have to keep up with it now.

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.

Jan



Followup 3

Download message
Date: Tue, 02 Oct 2012 07:00:24 -0700
From: Howard Chu <hyc@symas.com>
To: Jan Vcelak <jvcelak@redhat.com>
CC: openldap-its@openldap.org
Subject: Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
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.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/



Followup 4

Download message
Date: Tue, 02 Oct 2012 07:18:00 -0700
From: Howard Chu <hyc@symas.com>
To: openldap-its@openldap.org
Subject: Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
hyc@symas.com wrote:
> 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.

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.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/



Followup 5

Download message
From: Jan =?utf-8?B?VsSNZWzDoWs=?= <jvcelak@redhat.com>
To: hyc@symas.com
Cc: openldap-its@openldap.org
Subject: Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
Date: Wed, 03 Oct 2012 10:30:46 +0200
Hello,

On Tuesday 02 of October 2012 14:01:16, hyc@symas.com 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. 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.

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, hyc@symas.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.

Jan



Followup 6

Download message
Date: Wed, 03 Oct 2012 09:53:04 -0600
From: Rich Megginson <rich.megginson@gmail.com>
To: jvcelak@redhat.com
CC: openldap-its@openldap.org
Subject: Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
On 10/03/2012 02:33 AM, jvcelak@redhat.com wrote:
> Hello,
>
> On Tuesday 02 of October 2012 14:01:16, hyc@symas.com 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 
for this.

>> 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, hyc@symas.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?

>
> Jan
>
>



Followup 7

Download message
Date: Wed, 03 Oct 2012 09:18:10 -0700
From: Howard Chu <hyc@symas.com>
To: richm@stanfordalumni.org
CC: openldap-its@openldap.org
Subject: Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
Thanks for your comments, Rich.

richm@stanfordalumni.org wrote:
>> On Tuesday 02 of October 2012 14:18:49, hyc@symas.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?

That makes sense to me, although if as you say it hasn't been actively 
maintained, that sounds like another problem. But certainly if other apps are 
using it, then aren't they going to want new cipher suite support too?

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/



Followup 8

Download message
Date: Wed, 03 Oct 2012 10:24:10 -0600
From: Rich Megginson <rich.megginson@gmail.com>
To: Howard Chu <hyc@symas.com>
CC: richm@stanfordalumni.org, openldap-its@openldap.org
Subject: Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
On 10/03/2012 10:18 AM, Howard Chu wrote:
> Thanks for your comments, Rich.
>
> richm@stanfordalumni.org wrote:
>>> On Tuesday 02 of October 2012 14:18:49, hyc@symas.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?
>
> That makes sense to me, although if as you say it hasn't been actively 
> maintained, that sounds like another problem. But certainly if other 
> apps are using it, then aren't they going to want new cipher suite 
> support too?
>
Yes, and imho nss_compat_ossl is the place to do this.

But, would it be possible to update the cipher suite list in tls_m.c 
first, to bring it up to date, then work on updating the compat library?



Followup 9

Download message
Date: Wed, 03 Oct 2012 14:28:36 -0700
From: Quanah Gibson-Mount <quanah@zimbra.com>
To: jvcelak@redhat.com, openldap-its@openldap.org
Subject: Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher
 suites
--On Wednesday, October 03, 2012 8:33 AM +0000 jvcelak@redhat.com wrote:

> 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.

Redhat needs to come up with a solution to this problem, because they are 
putting their users in a catch-22 situation.  Either they get support from 
RedHat for a package that will not work, or they build their own, and can't 
get support from RedHat.  There are reasons new *patch* level releases are 
made.  I see zero reason why RedHat cannot update the versions of OpenLDAP 
they ship since the fixes are incremental.  No one should be running 
OpenLDAP 2.4.23 as a *production server*.  Keep the RPM version string the 
same, and note the upstream release in the RPM patchlevel, if that is 
necessary, but fix the actual code to be current.

This is why the Debian folks *wisely* recommend that people do *not* use 
the distribution build for a production server.

As long as RedHat keeps up this policy, the only advice ever for RedHat 
customers is to build their own RPMs, and get support elsewhere, since 
RedHat clearly can't keep working server versions together for their 
customers.  And then that leads to the question of what exactly they are 
paying RedHat for support for in the first place.

--Quanah

--

Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra ::  the leader in open source messaging and collaboration



Followup 10

Download message
Date: Wed, 03 Oct 2012 16:41:17 -0600
From: Rich Megginson <rich.megginson@gmail.com>
To: quanah@zimbra.com
CC: openldap-its@openldap.org
Subject: Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
This is quite off-topic, but I could not resist replying.

On 10/03/2012 03:29 PM, quanah@zimbra.com wrote:
> --On Wednesday, October 03, 2012 8:33 AM +0000 jvcelak@redhat.com wrote:
>
>> 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.
> Redhat needs to come up with a solution to this problem, because they are
> putting their users in a catch-22 situation.  Either they get support from
> RedHat for a package that will not work,

There are many Red Hat customers who are happy using the openldap server 
that comes with the distribution, and they do escalate problems through 
the support they are paying for, and they do get help and fixes that 
they pay for.


> or they build their own, and can't
> get support from RedHat.

Why should they get support from Red Hat if they build their own (in 
which case they have to support it themselves, or use the openldap 
community), or install 3rd party software (in which case they should get 
support from whoever provided the software)?

> There are reasons new *patch* level releases are
> made.  I see zero reason why RedHat cannot update the versions of OpenLDAP
> they ship since the fixes are incremental.  No one should be running
> OpenLDAP 2.4.23 as a *production server*.

The openldap in RHEL6 is *not* a *stock* openldap 2.4.23.  They are 
running 2.4.23 with many patches backported from later openldap 
releases.  The current version is openldap-2.4.23-26.el6_3.2.x86_64 - 
note the "-26" which means a lot more than 26 patches.

> Keep the RPM version string the
> same, and note the upstream release in the RPM patchlevel, if that is
> necessary, but fix the actual code to be current.

That's not what many Red Hat customers pay for.  They pay for very 
stable releases with only critical patches applied.  The Red Hat 
customers that want to use newer versions have many options - use Fedora 
(which does track upstream openldap closely), build their own, go to 
Symas, etc.

>
> This is why the Debian folks *wisely* recommend that people do *not* use
> the distribution build for a production server.

Can you point me to a link that has that statement in context?

>
> As long as RedHat keeps up this policy, the only advice ever for RedHat
> customers is to build their own RPMs, and get support elsewhere, since
> RedHat clearly can't keep working server versions together for their
> customers.

Clearly.  Except for the many customers who are quite happy.

> And then that leads to the question of what exactly they are
> paying RedHat for support for in the first place.

I like how you use "RedHat" instead of "Red Hat".

>
> --Quanah
>
> --
>
> Quanah Gibson-Mount
> Sr. Member of Technical Staff
> Zimbra, Inc
> A Division of VMware, Inc.
> --------------------
> Zimbra ::  the leader in open source messaging and collaboration
>
>



Followup 11

Download message
Date: Thu, 04 Oct 2012 14:19:37 -0700
From: Quanah Gibson-Mount <quanah@zimbra.com>
To: richm@stanfordalumni.org, openldap-its@openldap.org
Subject: Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher
 suites
--On Wednesday, October 03, 2012 10:42 PM +0000 richm@stanfordalumni.org 
wrote:

> This is quite off-topic, but I could not resist replying.

Agreed, but Jan opened it up for discussion.

> On 10/03/2012 03:29 PM, quanah@zimbra.com wrote:
>> --On Wednesday, October 03, 2012 8:33 AM +0000 jvcelak@redhat.com
wrote:
>>
>>> 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.
>> Redhat needs to come up with a solution to this problem, because they
are
>> putting their users in a catch-22 situation.  Either they get support
>> from RedHat for a package that will not work,
>
> There are many Red Hat customers who are happy using the openldap server
> that comes with the distribution, and they do escalate problems through
> the support they are paying for, and they do get help and fixes that
> they pay for.

There are many people who use Red Hat.  There are many of those many who 
don't use openldap at all.  There are many people just now migrating to 
RHEL6.  My question would be -- Why is Red Hat being reactive instead of 
proactive?  Upgrade your builds to include the latest patch level.  Also, 
you may have "many" happy customers using the distribution version, but I 
wonder how many would be "happy" if they knew the risks they were being 
exposed to because Red Hat will not update the build.  Like data loss in 
sync replication, etc.

>> or they build their own, and can't
>> get support from RedHat.
>
> Why should they get support from Red Hat if they build their own (in
> which case they have to support it themselves, or use the openldap
> community), or install 3rd party software (in which case they should get
> support from whoever provided the software)?

You missed my point entirely.  My point is they shouldn't have to build it 
themselves in the first place.  Red Hat, as the provider, should be a 
*responsible* entity, and upgrade the build being provided, so none of 
their customers get put in the untenable situation they now face.  Either 
build it themselves to get a working OpenLDAP server and lose Red Hat 
support, or deal with the fact that they are provided with a bad build.

>> There are reasons new *patch* level releases are
>> made.  I see zero reason why RedHat cannot update the versions of
>> OpenLDAP they ship since the fixes are incremental.  No one should be
>> running OpenLDAP 2.4.23 as a *production server*.
>
> The openldap in RHEL6 is *not* a *stock* openldap 2.4.23.  They are
> running 2.4.23 with many patches backported from later openldap
> releases.  The current version is openldap-2.4.23-26.el6_3.2.x86_64 -
> note the "-26" which means a lot more than 26 patches.

Sorry, but the number "26" is quite unimpressive.  How many of those 26 
patches deal with fixing Red Hat's busted MozNSS bits?  Your statement here 
is like having a mechanic tell me how much better my vehicle is now because 
he replaced one of twelve bad spark plugs.

There have been approximately 450 committed fixes to RE24 since 2.4.23 was 
released.  So you have about 5% of the fixes in your build.  That is just 
so very encouraging to hear, isn't it?  As a customer, wouldn't you truly 
feel that Red Hat was doing its best for you, but grabbing a full 5% of 
fixes to OpenLDAP?  And lets not forget a fair number of those patches you 
have actually have zero to do with OpenLDAP itself, but with MozNSS... So 
we're down to what?  3%?


>> Keep the RPM version string the
>> same, and note the upstream release in the RPM patchlevel, if that is
>> necessary, but fix the actual code to be current.
>
> That's not what many Red Hat customers pay for.  They pay for very
> stable releases with only critical patches applied.  The Red Hat
> customers that want to use newer versions have many options - use Fedora
> (which does track upstream openldap closely), build their own, go to
> Symas, etc.

As is often noted, Fedora is for "bleeding edge".  Patch level releases are 
not bleeding edge.  They are INCREMENTAL FIXES.  If Red Hat's goal is to 
provide a "stable release", then your current strategy is utterly flawed. 
You aren't providing a stable release.  Your fixing your distribution to a 
*random* release, and then holding all your customers to that release, 
regardless of how broken it might be.  If your goal is truly to provide a 
stable release, then upgrade the patch level.  If I was asking you to jump 
from 2.3 to 2.4, or 2.4 to 2.5, where the minor level was changing, I'd 
agree 

Message of length 7028 truncated


Followup 12

Download message
Date: Thu, 04 Oct 2012 17:28:27 -0600
From: Rich Megginson <rich.megginson@gmail.com>
To: Quanah Gibson-Mount <quanah@zimbra.com>
CC: openldap-its@openldap.org
Subject: Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
On 10/04/2012 03:19 PM, Quanah Gibson-Mount wrote:
> --On Wednesday, October 03, 2012 10:42 PM +0000 
> richm@stanfordalumni.org wrote:
>
>> This is quite off-topic, but I could not resist replying.
>
> Agreed, but Jan opened it up for discussion.
>
>> On 10/03/2012 03:29 PM, quanah@zimbra.com wrote:
>>> --On Wednesday, October 03, 2012 8:33 AM +0000 jvcelak@redhat.com 
>>> wrote:
>>>
>>>> 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.
>>> Redhat needs to come up with a solution to this problem, because 
>>> they are
>>> putting their users in a catch-22 situation.  Either they get
support
>>> from RedHat for a package that will not work,
>>
>> There are many Red Hat customers who are happy using the openldap
server
>> that comes with the distribution, and they do escalate problems through
>> the support they are paying for, and they do get help and fixes that
>> they pay for.
>
> There are many people who use Red Hat.  There are many of those many 
> who don't use openldap at all.  There are many people just now 
> migrating to RHEL6.  My question would be -- Why is Red Hat being 
> reactive instead of proactive?  Upgrade your builds to include the 
> latest patch level.  Also, you may have "many" happy customers using 
> the distribution version, but I wonder how many would be "happy" if 
> they knew the risks they were being exposed to because Red Hat will 
> not update the build.  Like data loss in sync replication, etc.

If a customer reports such a problem, Red Hat will respond.

>
>>> or they build their own, and can't
>>> get support from RedHat.
>>
>> Why should they get support from Red Hat if they build their own (in
>> which case they have to support it themselves, or use the openldap
>> community), or install 3rd party software (in which case they should
get
>> support from whoever provided the software)?
>
> You missed my point entirely.  My point is they shouldn't have to 
> build it themselves in the first place.  Red Hat, as the provider, 
> should be a *responsible* entity, and upgrade the build being 
> provided, so none of their customers get put in the untenable 
> situation they now face.  Either build it themselves to get a working 
> OpenLDAP server and lose Red Hat support, or deal with the fact that 
> they are provided with a bad build.
>
>>> There are reasons new *patch* level releases are
>>> made.  I see zero reason why RedHat cannot update the versions of
>>> OpenLDAP they ship since the fixes are incremental.  No one should
be
>>> running OpenLDAP 2.4.23 as a *production server*.
>>
>> The openldap in RHEL6 is *not* a *stock* openldap 2.4.23.  They are
>> running 2.4.23 with many patches backported from later openldap
>> releases.  The current version is openldap-2.4.23-26.el6_3.2.x86_64 -
>> note the "-26" which means a lot more than 26 patches.
>
> Sorry, but the number "26" is quite unimpressive.

It is not meant to impress, just a statement of fact that the RHEL 
OpenLDAP 2.4.23 is not a stock 2.4.23, but contains many patches 
backported from 2.4.24 and later.

> How many of those 26 patches deal with fixing Red Hat's busted MozNSS 
> bits?

Many, not all.

> Your statement here is like having a mechanic tell me how much better 
> my vehicle is now because he replaced one of twelve bad spark plugs.

I did not mean to imply that more patches == better.  I just meant more 
patches == not stock 2.4.23.

>
> There have been approximately 450 committed fixes to RE24 since 2.4.23 
> was released.  So you have about 5% of the fixes in your build.  That 
> is just so very encouraging to hear, isn't it?  As a customer, 
> wouldn't you truly feel that Red Hat was doing its best for you, but 
> grabbing a full 5% of fixes to OpenLDAP?  And lets not forget a fair 
> number of those patches you have actually have zero to do with 
> OpenLDAP itself, but with MozNSS... So we're down to what?  3%?

If you will concede the point that quantity != quality, then so will I.

>
>
>>> Keep the RPM version string the
>>> same, and note the upstream release in the RPM patchlevel, if that
is
>>> necessary, but fix the actual code to be current.
>>
>> That's not what many Red Hat customers 

Message of length 11142 truncated


Followup 13

Download message
Date: Thu, 04 Oct 2012 17:07:41 -0700
From: Quanah Gibson-Mount <quanah@zimbra.com>
To: richm@stanfordalumni.org, openldap-its@openldap.org
Subject: Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher
 suites
--On Thursday, October 04, 2012 11:29 PM +0000 richm@stanfordalumni.org 
wrote:

> If a customer reports such a problem, Red Hat will respond.

Again, reactive rather than proactive.

>> There have been approximately 450 committed fixes to RE24 since 2.4.23
>> was released.  So you have about 5% of the fixes in your build.  That
>> is just so very encouraging to hear, isn't it?  As a customer,
>> wouldn't you truly feel that Red Hat was doing its best for you, but
>> grabbing a full 5% of fixes to OpenLDAP?  And lets not forget a fair
>> number of those patches you have actually have zero to do with
>> OpenLDAP itself, but with MozNSS... So we're down to what?  3%?
>
> If you will concede the point that quantity != quality, then so will I.

Certainly, but a fair number of those commits are actual bug fixes.  2.4.23 
in particular had some significant issues.

> So moving from OpenLDAP 2.4.x to 2.4.x+1 does not introduce any new
> features or regressions, ever?

We have introduced new features, sure.  MDB and delta-syncrepl for MMR 
would be examples.  But they don't impact existing functionality.  And 
certainly can be the case that regressions are introduced.  I'm not saying 
to immediately upgrade to the latest OpenLDAP release every time it comes 
out.  One has to have some common sense about it.  However, it has been 
over 2 years since 2.4.23 was released.  Many significant and real issues 
have been fixed since that 2.4.23 was done, with numerous fixes in the 
syncrepl area and the cn=config DB, which Red Hat deploys on RHEL6.

> If this is really the case, then why would Debian or any other
> distribution not want to rebase every time OpenLDAP has a 2.4.x+1
> release?  The FAQ says ". . . upgrading to newer versions is often
> desireable but also means introducing change into stable releases, which
> is exactly opposite to the point of release stability".  So it's ok for
> Debian to take a hard line for release stability, but not Red Hat?  Or
> is your problem really that Red Hat doesn't openly proclaim that the
> OpenLDAP server included with the distribution is not for "a large site,
> a complicated installation" or the like?  So if Red Hat were to provide
> such a disclaimer, it would be ok for Red Hat to take a hard line for
> release stability?

Debian provides a backports channel that allows its users to update to 
later releases.  And no, I don't find Debian's hard line any more 
acceptable, but at least they provide a supported solution. Red Hat doesn't 
provide any supported alternative.

> So what's the difference between Debian and Red Hat with respect to
> OpenLDAP?  That is, why bash Red Hat's handling of OpenLDAP and not
> Debian stable?  I suppose the same thing applies to Red Hat - if a Red
> Hat customer has "a large site, a complicated installation, or problems
> for which [they] need to seek help here", they will probably be willing
> to pay extra for extra attention, in the form of adding additional
> resources to build and maintain OpenLDAP themselves, or hiring a firm
> like Symas.

If you think I don't bash Debian, then you haven't been paying attention. 
;)  In any case, my point is about improving how Red Hat handles things, 
not about bashing.  There are improvements that can be made.


> Most of the complaints I see from users in the OpenLDAP community are
> about the TLS/SSL support in RHEL6.  Do you have evidence to the contrary?

Certainly, here's a recent example: 
<https://www.openldap.org/lists/openldap-technical/201210/msg00024.html>

>>>> And then that leads to the question of what exactly they are
>>>> paying RedHat for support for in the first place.
>>>
>>> I like how you use "RedHat" instead of "Red Hat".
>>
>> I like how you avoided addressing my point.
>
> I see your point.  I get it - the OpenLDAP community is not happy with
> the way Red Hat handles OpenLDAP.  If you are really, truly concerned
> about Red Hat customers using OpenLDAP software, what are you going to
> do about it?   If your goal is to get Red Hat to rebase OpenLDAP
> releases on a regular basis, how can you achieve that goal?  Complain to
> Jan and I in an OpenLDAP ITS?  Bash Red Hat to every user who has the
> temerity to use rhel/fedora/centos and ask a question in #ldap and
># openldap and the OpenLDAP mailing lists?  If a critical mass of paying
> Red Hat customers tells Red Hat that they are not happy with OpenLDAP,
> then Red Hat will do something about it.  That's the demand side.
>
> Red Hat (and probably all OS distributions) has the same problem to some
> extent with all upstream projects.  There are probably Apache upstream
> community members who are unhappy with the way Red Hat deals with Apache
> releases.
>
> As for the supply side, if Jan and the

Message of length 6121 truncated


Followup 14

Download message
Date: Thu, 04 Oct 2012 20:10:17 -0600
From: Rich Megginson <rich.megginson@gmail.com>
To: Quanah Gibson-Mount <quanah@zimbra.com>
CC: richm@stanfordalumni.org, openldap-its@openldap.org
Subject: Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
On 10/04/2012 06:07 PM, Quanah Gibson-Mount wrote:
> --On Thursday, October 04, 2012 11:29 PM +0000 
> richm@stanfordalumni.org wrote:
>
>> If a customer reports such a problem, Red Hat will respond.
>
> Again, reactive rather than proactive.

Red Hat is not entirely reactive.

>
>>> There have been approximately 450 committed fixes to RE24 since
2.4.23
>>> was released.  So you have about 5% of the fixes in your build. 
That
>>> is just so very encouraging to hear, isn't it?  As a customer,
>>> wouldn't you truly feel that Red Hat was doing its best for you,
but
>>> grabbing a full 5% of fixes to OpenLDAP?  And lets not forget a
fair
>>> number of those patches you have actually have zero to do with
>>> OpenLDAP itself, but with MozNSS... So we're down to what?  3%?
>>
>> If you will concede the point that quantity != quality, then so will I.
>
> Certainly, but a fair number of those commits are actual bug fixes.  
> 2.4.23 in particular had some significant issues.
>
>> So moving from OpenLDAP 2.4.x to 2.4.x+1 does not introduce any new
>> features or regressions, ever?
>
> We have introduced new features, sure.  MDB and delta-syncrepl for MMR 
> would be examples.  But they don't impact existing functionality. 

Famous last words.

> And certainly can be the case that regressions are introduced.  I'm 
> not saying to immediately upgrade to the latest OpenLDAP release every 
> time it comes out.  One has to have some common sense about it.  
> However, it has been over 2 years since 2.4.23 was released.  Many 
> significant and real issues have been fixed since that 2.4.23 was 
> done, with numerous fixes in the syncrepl area and the cn=config DB, 
> which Red Hat deploys on RHEL6.

Ok.  Fair enough.  This then gets to the point about whether the Red Hat 
OpenLDAP maintainers would be willing and able to do this.

>
>> If this is really the case, then why would Debian or any other
>> distribution not want to rebase every time OpenLDAP has a 2.4.x+1
>> release?  The FAQ says ". . . upgrading to newer versions is often
>> desireable but also means introducing change into stable releases,
which
>> is exactly opposite to the point of release stability".  So it's ok for
>> Debian to take a hard line for release stability, but not Red Hat?  Or
>> is your problem really that Red Hat doesn't openly proclaim that the
>> OpenLDAP server included with the distribution is not for "a large
site,
>> a complicated installation" or the like?  So if Red Hat were to provide
>> such a disclaimer, it would be ok for Red Hat to take a hard line for
>> release stability?
>
> Debian provides a backports channel that allows its users to update to 
> later releases.  And no, I don't find Debian's hard line any more 
> acceptable, but at least they provide a supported solution. Red Hat 
> doesn't provide any supported alternative.

Ok.  This is feasible.  I know that Red Hat has done things like this in 
the past.  This is something that could be done.

>
>> So what's the difference between Debian and Red Hat with respect to
>> OpenLDAP?  That is, why bash Red Hat's handling of OpenLDAP and not
>> Debian stable?  I suppose the same thing applies to Red Hat - if a Red
>> Hat customer has "a large site, a complicated installation, or problems
>> for which [they] need to seek help here", they will probably be willing
>> to pay extra for extra attention, in the form of adding additional
>> resources to build and maintain OpenLDAP themselves, or hiring a firm
>> like Symas.
>
> If you think I don't bash Debian, then you haven't been paying 
> attention. ;)  In any case, my point is about improving how Red Hat 
> handles things, not about bashing.  There are improvements that can be 
> made.

It's hard not to pay attention to you.  But I guess your point is that 
Debian does provide a supported way to get newer versions of packages 
even on older, stable releases, and that is an important distinction.

>
>
>> Most of the complaints I see from users in the OpenLDAP community are
>> about the TLS/SSL support in RHEL6.  Do you have evidence to the 
>> contrary?
>
> Certainly, here's a recent example: 
> <https://www.openldap.org/lists/openldap-technical/201210/msg00024.html>

I guess I missed it, but exactly which OpenLDAP release(s) had the fix 
for this particular problem?  That is, how could Red Hat have avoided 
this problem by rebasing to a later OpenLDAP?

>
>>>>> And then that leads to the question of what exactly they
are
>>>>> paying RedHat for support for in the first place.
>>>>
>>>> I like how you use "RedHat" instead of "Red Hat".
>

Message of length 7521 truncated


Followup 15

Download message
Date: Fri, 05 Oct 2012 13:12:09 -0700
From: Quanah Gibson-Mount <quanah@zimbra.com>
To: richm@stanfordalumni.org, openldap-its@openldap.org
Subject: Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher
 suites
--On Friday, October 05, 2012 2:11 AM +0000 richm@stanfordalumni.org wrote:

>> Certainly, here's a recent example:
>> <https://www.openldap.org/lists/openldap-technical/201210/msg00024.html>
>
> I guess I missed it, but exactly which OpenLDAP release(s) had the fix
> for this particular problem?  That is, how could Red Hat have avoided
> this problem by rebasing to a later OpenLDAP?

My guess is it was fixed in 2.4.26 or 2.4.27.  There have been numerous 
fixes to cn=config support since 2.4.23, so it is hard to know specifically 
which one fixes the above issue. ;)

>> I will note that Mandriva, at least, continually updates the version
>> of OpenLDAP they ship, unlike most distributions, so it definitely
>> isn't all. And my point is, Red Hat could do better, and I'd like to
>> see them do better.  I'd like to see Debian/Ubuntu do better too.
>> I.e., this isn't specific to Red Hat, but the discussion here is about
>> Red Hat, and what it can do.  I discuss Debian and what it can do
>> better with the Debian devs on their openldap dev list.
>
> Then I'd like to hear what Jan and the other Red Hat OpenLDAP
> maintainers have to say.

Ok.  One thing I do with Debian is help triage issues that are reported 
there with the upstream ITS system if the issues do not appear to be due to 
the usage of an old version.  If there is a simple way to do that with Red 
Hat, I could help there as well.

--Quanah

--

Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra ::  the leader in open source messaging and collaboration



Followup 16

Download message
Date: Fri, 05 Oct 2012 16:07:37 -0600
From: Rich Megginson <rich.megginson@gmail.com>
To: quanah@zimbra.com
CC: openldap-its@openldap.org
Subject: Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
On 10/05/2012 02:12 PM, quanah@zimbra.com wrote:
> --On Friday, October 05, 2012 2:11 AM +0000 richm@stanfordalumni.org wrote:
>
>>> Certainly, here's a recent example:
>>> <https://www.openldap.org/lists/openldap-technical/201210/msg00024.html>
>> I guess I missed it, but exactly which OpenLDAP release(s) had the fix
>> for this particular problem?  That is, how could Red Hat have avoided
>> this problem by rebasing to a later OpenLDAP?
> My guess is it was fixed in 2.4.26 or 2.4.27.  There have been numerous
> fixes to cn=config support since 2.4.23, so it is hard to know specifically
> which one fixes the above issue. ;)

I've gone through the entire thread again.  I still don't know
1) what caused the hanging problem with slaptest
2) if upgrading to 2.4.32 fixed the problem

https://www.openldap.org/lists/openldap-technical/201210/msg00024.html
"
# slaptest -v -d 448 -f ./slapd.conf.new -F /etc/openldap/slapd.d

The last step just hangs and does not do anything even after waiting 45 
minutes.
"

Do you know if there was a specific hanging problem with slaptest used 
to convert slapd.conf to slapd.d in 2.4.1-2.4.23 that would have been 
fixed by rebasing to 2.4.26-2.4.27?  How can you be sure that upgrading 
to 2.4.32 will fix the problem that this guy was having?  No one asked 
him to use gdb to attach to the process to see what was going on.  No 
one asked him to provide the log output of the -d 448 log level.  Is it 
possible that his issue was unrelated to the version of openldap he was 
using?  I guess we'll never know.

I've looked through the list of changes at 
http://www.openldap.org/software/release/changes.html
I do see several fixes for cn=config/slapd.d issues in 2.4.24 and 
later.  But I don't see any that look like they have something to do 
with hanging.

I would still like to know a specific problem in Red Hat's OpenLDAP, 
that has been reported by a customer/user, that would have been avoided 
by rebasing.  It would be a good data point to present to management to 
say "we could have avoided all of these customer problems by rebasing 
instead of cherry picking patches".

>
>>> I will note that Mandriva, at least, continually updates the
version
>>> of OpenLDAP they ship, unlike most distributions, so it definitely
>>> isn't all. And my point is, Red Hat could do better, and I'd like
to
>>> see them do better.  I'd like to see Debian/Ubuntu do better too.
>>> I.e., this isn't specific to Red Hat, but the discussion here is
about
>>> Red Hat, and what it can do.  I discuss Debian and what it can do
>>> better with the Debian devs on their openldap dev list.
>> Then I'd like to hear what Jan and the other Red Hat OpenLDAP
>> maintainers have to say.
> Ok.  One thing I do with Debian is help triage issues that are reported
> there with the upstream ITS system if the issues do not appear to be due to
> the usage of an old version.  If there is a simple way to do that with Red
> Hat, I could help there as well.

Here is the current RHEL 6 openldap bug list - 
https://bugzilla.redhat.com/buglist.cgi?list_id=641623&classification=Red%20Hat&query_format=advanced&bug_status=NEW&bug_status=ASSIGNED&component=openldap&product=Red%20Hat%20Enterprise%20Linux%206

Here is the current Fedora openldap bug list - 
https://bugzilla.redhat.com/buglist.cgi?list_id=641625&classification=Fedora&query_format=advanced&bug_status=NEW&bug_status=ASSIGNED&component=openldap&product=Fedora

If you have a bugzilla account, you can simply add the link to the ITS 
as a comment in the bugzilla bug.  That would be most appreciated.  Thanks!

>
> --Quanah
>
> --
>
> Quanah Gibson-Mount
> Sr. Member of Technical Staff
> Zimbra, Inc
> A Division of VMware, Inc.
> --------------------
> Zimbra ::  the leader in open source messaging and collaboration
>
>



Followup 17

Download message
From: Jan =?utf-8?B?VsSNZWzDoWs=?= <jvcelak@redhat.com>
To: quanah@zimbra.com
Cc: openldap-its@openldap.org
Subject: Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
Date: Mon, 08 Oct 2012 09:49:51 +0200
> >> I will note that Mandriva, at least, continually updates the
version
> >> of OpenLDAP they ship, unlike most distributions, so it definitely
> >> isn't all. And my point is, Red Hat could do better, and I'd like
to
> >> see them do better.  I'd like to see Debian/Ubuntu do better too.
> >> I.e., this isn't specific to Red Hat, but the discussion here is
about
> >> Red Hat, and what it can do.  I discuss Debian and what it can do
> >> better with the Debian devs on their openldap dev list.
> > 
> > Then I'd like to hear what Jan and the other Red Hat OpenLDAP
> > maintainers have to say.

As for Fedora, I usualy rebase the package immediately when the new upstream 
version is available. And I do it in the stable and newer releases (for today 
it would be stable F17, alpha F18, and Rawhide). And if there is a problem in 
older Fedora, I just pick the patch.

So we are definitelly not behind with Fedora -- the last submitted updates can 
be found here: https://admin.fedoraproject.org/updates/search/openldap

As for RHEL it is more complicated, the rebases are allowed rarely. We cannot 
afford any API/ABI breakage and regressions. and I can imagine that a new 
feature in OpenLDAP changes the current behavior or affects some other 
component.

I can remind a bug which appeared after rebase to 2.4.31 in Fedora and we do 
not want to cause a similar problems in RHEL:
https://bugzilla.redhat.com/show_bug.cgi?id=771484
http://www.openldap.org/its/index.cgi?findid=7167

I would like to see newer OpenLDAP in RHEL because it would be easier for me 
to maintain it. But I'm not sure if the advantages will outweight the 
disadvantages and if our customers will benefit from it rather than be forced 
to deal with new problems.

> Ok.  One thing I do with Debian is help triage issues that are reported
> there with the upstream ITS system if the issues do not appear to be due to
> the usage of an old version.  If there is a simple way to do that with Red
> Hat, I could help there as well.

When there is a new bug report, I usualy try to reproduce with the package 
from RHEL or Fedora. And then with the newest OpenLDAP from git master. If I'm 
able to reproduce, I always create a report in your ITS.

Jan



Followup 18

Download message
Date: Fri, 19 Oct 2012 09:24:04 -0700
From: Quanah Gibson-Mount <quanah@zimbra.com>
To: =?UTF-8?Q?Jan_V=C4=8Del=C3=A1k?= <jvcelak@redhat.com>
cc: openldap-its@openldap.org
Subject: Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher
 suites
--On Monday, October 08, 2012 9:49 AM +0200 Jan V..el..k 
<jvcelak@redhat.com> wrote:

> I would like to see newer OpenLDAP in RHEL because it would be easier for
> me  to maintain it. But I'm not sure if the advantages will outweight the
> disadvantages and if our customers will benefit from it rather than be
> forced  to deal with new problems.

The lack of a current version of OpenLDAP exposes your customers to 
numerous significant issues, whether or not you choose acknowledge that.

>> Ok.  One thing I do with Debian is help triage issues that are reported
>> there with the upstream ITS system if the issues do not appear to be
due
>> to the usage of an old version.  If there is a simple way to do that
>> with Red Hat, I could help there as well.
>
> When there is a new bug report, I usualy try to reproduce with the
> package  from RHEL or Fedora. And then with the newest OpenLDAP from git
> master. If I'm  able to reproduce, I always create a report in your ITS.

I was curious more in a list like pkg-openldap-devel w/ Debian, which also 
gets cc'd on all ldap related tickets.  But it sounds like you are already 
doing what I was thinking of.

--Quanah

--

Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra ::  the leader in open source messaging and collaboration



Followup 19

Download message
Date: Tue, 30 Oct 2012 16:14:44 -0700
From: Howard Chu <hyc@symas.com>
To: richm@stanfordalumni.org
CC: Rich Megginson <rich.megginson@gmail.com>, openldap-its@openldap.org
Subject: Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
Rich Megginson wrote:
> On 10/03/2012 10:18 AM, Howard Chu wrote:
>> Thanks for your comments, Rich.

>>> Maybe we could use nss_compat_ossl to do the mapping of cipher
names
>>> from openssl to moznss?
>>
>> That makes sense to me, although if as you say it hasn't been actively
>> maintained, that sounds like another problem. But certainly if other
>> apps are using it, then aren't they going to want new cipher suite
>> support too?
>>
> Yes, and imho nss_compat_ossl is the place to do this.
>
> But, would it be possible to update the cipher suite list in tls_m.c
> first, to bring it up to date, then work on updating the compat library?

I discussed this with Kurt; the Project's policy on issues like this in the 
past has been not to commit any backward-compatibility fixes of this sort 
until the real fix has already been released. I.e., we should wait until 
nss_compat_ossl has been updated.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/


Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest


The OpenLDAP Issue Tracking System uses a hacked version of JitterBug

______________
© Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org