openldap-bugs

openldap-bugs@openldap.org

1 participants
20962 discussions

Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
by richm＠stanfordalumni.org 04 Oct '12

04 Oct '12

On 10/04/2012 03:19 PM, Quanah Gibson-Mount wrote: > --On Wednesday, October 03, 2012 10:42 PM +0000 > richm(a)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(a)zimbra.com wrote: >>> --On Wednesday, October 03, 2012 8:33 AM +0000 jvcelak(a)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 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 that would not > qualify as stable. I'm not. I'm saying be responsible, and do right > by your customers. Given them actual stable builds of OpenLDAP, > instead of hiding behind this excuse of sticking to a specific version > for "stability". You will notice that the OpenLDAP foundation does > not mark *any* release as "stable". And that is because people would > use that in the same broken fashion Red Hat is applying here. So moving from OpenLDAP 2.4.x to 2.4.x+1 does not introduce any new features or regressions, ever? 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? > > >>> 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? > > Absolutely. They were kind enough to contribute it to the OpenLDAP > FAQ. I'm actually surprised you aren't familiar with it at this point, > given that I routinely note it on IRC and the mailing list: > > <http://www.openldap.org/faq/data/cache/1456.html> 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. > > >>> 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. > > See above. You say they are happy, but would they actually be happy > if they knew the risks Red Hat was knowingly putting their data > under? And in that "happiness" quotient, are you counting the > increasing number of people emailing the -technical list and asking > question on IRC about why their OpenLDAP build is so broken? I'm > think that is likely not the case. 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? As for other comments, see below. > >>> 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 other OpenLDAP maintainers feel that it is better to rebase than patch, then that's a good start. They are the ones who are on the hook - it's their necks if things don't work correctly. Once they convince themselves, then they have to convince QE, Doc, support, and management that it really is the best policy. And part of it is Red Hat's policy towards release stability, which adds additional process, but is workable. > > --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

1 0

Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
by quanah＠zimbra.com 04 Oct '12

04 Oct '12

--On Wednesday, October 03, 2012 10:42 PM +0000 richm(a)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(a)zimbra.com wrote: >> --On Wednesday, October 03, 2012 8:33 AM +0000 jvcelak(a)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 that would not qualify as stable. I'm not. I'm saying be responsible, and do right by your customers. Given them actual stable builds of OpenLDAP, instead of hiding behind this excuse of sticking to a specific version for "stability". You will notice that the OpenLDAP foundation does not mark *any* release as "stable". And that is because people would use that in the same broken fashion Red Hat is applying here. >> 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? Absolutely. They were kind enough to contribute it to the OpenLDAP FAQ. I'm actually surprised you aren't familiar with it at this point, given that I routinely note it on IRC and the mailing list: <http://www.openldap.org/faq/data/cache/1456.html> >> 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. See above. You say they are happy, but would they actually be happy if they knew the risks Red Hat was knowingly putting their data under? And in that "happiness" quotient, are you counting the increasing number of people emailing the -technical list and asking question on IRC about why their OpenLDAP build is so broken? I'm think that is likely not the case. >> 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. --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

1 0

Re: (ITS#7409) ldapsearch issue using * in filters
by quanah＠zimbra.com 04 Oct '12

04 Oct '12

--On Thursday, October 04, 2012 9:14 AM +0000 fishakos(a)yahoo.gr wrote: > When i try to use the command >> ldapsearch -h localhost -LLL -x -s sub -d 32 -b > bill=postpaid,msisdn=*,dc=cosmote,dc=ro -b is the base, not a filter. Your search is invalid, and you definitely have provided an invalid DN syntax. This ITS will be closed. I would note that back-ndb was never finished, and is considered beta at best. --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

1 0

(ITS#7410) ldapsearch issue using * in filters
by fishakos＠yahoo.gr 04 Oct '12

04 Oct '12

Full_Name: Panagiotis Psarrakos Version: 2.4.31 OS: CentOS release 5.5 (Final) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.205.53.214) My environment consists of MySQL Cluster database with 2 Data nodes and 2 mysql nodes. I have installed openLDAP at both mysql nodesusing back-ndb for retrieving data from MySQL Cluster database. The table OL_dn2id contains entries like the sample below eid |objectclass | a0 | a1 | a2 | a3 --------------------------------------------------------------------------------- 2790113 |entitlement@top| dc=ro | dc=cosmote | msisdn=40765494677 | bill=prepaid --------------------------------------------------------------------------------- 993566 |usertable@top | dc=ro | dc=cosmote | msisdn=40765494677 | bill=postpaid I need to perfrom search based on msisdn or based on attribute bill (bill can have values prepaid/postpaid) When i try to use the command >ldapsearch -h localhost -LLL -x -s sub -d 32 -b bill=postpaid,msisdn=*,dc=cosmote,dc=ro then i receive the error Invalid DN syntax (34) Additional information: invalid DN As i understand i have to use both columns a3 and a2 in order to do searches based on bill attribute but i need to have all msisdn based on the bill value Is there a limitation in openLDAP implementation in using the character * for wildcard LDAP searches?

1 0

(ITS#7409) ldapsearch issue using * in filters
by fishakos＠yahoo.gr 04 Oct '12

04 Oct '12

1 0

Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
by richm＠stanfordalumni.org 03 Oct '12

03 Oct '12

This is quite off-topic, but I could not resist replying. On 10/03/2012 03:29 PM, quanah(a)zimbra.com wrote: > --On Wednesday, October 03, 2012 8:33 AM +0000 jvcelak(a)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 > >

1 0

Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
by quanah＠zimbra.com 03 Oct '12

03 Oct '12

--On Wednesday, October 03, 2012 8:33 AM +0000 jvcelak(a)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

1 0

Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
by richm＠stanfordalumni.org 03 Oct '12

03 Oct '12

On 10/03/2012 10:18 AM, Howard Chu wrote: > Thanks for your comments, Rich. > > richm(a)stanfordalumni.org wrote: >>> On Tuesday 02 of October 2012 14:18:49, hyc(a)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?

1 0

Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
by hyc＠symas.com 03 Oct '12

03 Oct '12

Thanks for your comments, Rich. richm(a)stanfordalumni.org wrote: >> On Tuesday 02 of October 2012 14:18:49, hyc(a)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/

1 0

Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
by richm＠stanfordalumni.org 03 Oct '12

03 Oct '12

On 10/03/2012 02:33 AM, jvcelak(a)redhat.com wrote: > Hello, > > On Tuesday 02 of October 2012 14:01:16, hyc(a)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(a)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 > >

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs