(ITS#7409) ldapsearch issue using * in filters
by fishakos＠yahoo.gr
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?
11 years
Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
by richm＠stanfordalumni.org
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
>
>
11 years
Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
by quanah＠zimbra.com
--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
11 years
Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
by richm＠stanfordalumni.org
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?
11 years
Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
by hyc＠symas.com
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/
11 years
Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
by richm＠stanfordalumni.org
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
>
>
11 years
Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
by jvcelak＠redhat.com
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. 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(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.
Jan
11 years
Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
by hyc＠symas.com
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/
11 years
Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
by jvcelak＠redhat.com
> 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
11 years