RE: (ITS#7051) ldap_pvt_tls_get_peer_dn fails under gnutls
by Giampaolo＠Tomassoni.biz
> > This is the needed patch:
>
> This patch should not work either, you still need a skip_tag before the
> get_int.
>
> > - tag = ber_skip_tag( ber,&len ); /* Context +
> Constructed
> > (version) */
> > + tag = ber_peek_tag( ber,&len ); /* Context +
> Constructed
I confirm this patch worked for me, at least it did on an amd64 I'm working
on.
It worked both with openssl-generated v1 (no version tag present) and v3
certificates (version tag present).
I don't know if this is an cpu-architecture -dependent issue (I don't think
so), nor I know how the ber_* library works, but FWICU the Context +
Constructed stuff is handled as a tag prefix by the ber_get_int(), which
then discards it when found and fetches the encapsulated value.
Instead, ber_peek_tag() is probably more simple-minded in that it peeks the
first word at the buffer pointer, which is the Context + Constructed prefix,
not really the tag.
I can of course be wrong, but with this patch I got i==2 from v3
certificates, which is the correct value.
Giampaolo
12 years, 2 months
Re: (ITS#6979) test062 portability
by h.b.furuseth＠usit.uio.no
Aaron Richton writes:
> It looks like checking the function exit isn't portable; maybe some
> kind of bash-ism. It looks like the code was on the path to
> communicating the retval via $RCOUT file already?
I'm curious, what is this about - an observed bug, or not? There is
no function call here, 'wait' is checking a subprocess's exit status.
That's standard, and so is checking the return (not exit) status from
a function as far as I know, but I'm not surprised if some shells have
quirks.
I noticed because I saw the patch entering master. Which is fine by
me, except the patch may be a bit incomplete. Since $SEARCHRC is now
the output from `cat`, it may be best to quote it here:
> if test $SEARCHRC != 52 ; then
--
Hallvard
12 years, 2 months
Re: (ITS#7006) openldap does not accept wildcard certificates with mozilla/nss
by hyc＠symas.com
hash_oldap(a)cycdolphin.net wrote:
> Full_Name: Philippe Kueck
> Version: 2.4.23 / 2.4.26
> OS: RHEL 6.1
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (82.98.65.86)
>
>
> When compiled against Mozilla/NSS OpenLDAP does not accept wildcard
> certificates.
>
> This is probably because in tls_m.c the certificate CN (*.domain.example) is
> matched against the hostname (foo.domain.example), not against the domain
> (.domain.example).
>
> I suggest the following patch:
Thanks for the report, fixed in master.
>
> --%snip%--
> diff -Nru openldap-2.4.26-orig/libraries/libldap/tls_m.c
> openldap-2.4.26/libraries/libldap/tls_m.c
> --- openldap-2.4.26-orig/libraries/libldap/tls_m.c 2011-06-30 17:13:36.000000000
> +0200
> +++ openldap-2.4.26/libraries/libldap/tls_m.c 2011-08-01 16:29:42.000000000
> +0200
> @@ -2590,7 +2590,7 @@
> if ( av->len == nlen&& !strncasecmp( name, (char *)av->data, nlen )) {
> ret = LDAP_SUCCESS;
> } else if ( av->data[0] == '*'&& av->data[1] == '.'&&
> - domain&& dlen == av->len - 1&& !strncasecmp( name,
> + domain&& dlen == av->len - 1&& !strncasecmp( domain,
> (char *)(av->data+1), dlen )) {
> ret = LDAP_SUCCESS;
> } else {
> --%snip%--
>
>
> Kind regards,
>
> Philippe Kueck
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
12 years, 2 months
Re: (ITS#7011) signal 6 got in ldap_abandon
by hyc＠symas.com
ogermain(a)tibco.com wrote:
> Full_Name: Olivier GERMAIN
> Version: 2.4.24
> OS: Solaris 5.10
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (212.157.248.2)
>
>
> Dear All,
>
> One of our customer got a signal 6 during the execution of the ldap_abandon.
> This signal occurred whereas some maintenance was doing on a firewall which is
> not located on the same network. It seems that the ldap_abandon thrown this
> assert because it was a situation like a can't happen. I don't have much
> information on the action performed on the firewall which led to this sigabort.
>
>
> Please find the logs I have :
> 2011-07-19 04:08:52.876909|ENG|FATAL|84|engine.cpp(109)|
> /appl/kabira/MIPSPLUS-1.5.1-110510-SOL64/kis/distrib/kabira/lib/libsyssrv.so:sw_debugSignalHandler+0x18
> 2011-07-19 04:08:52.877541|ENG|FATAL|84|engine.cpp(109)|
> /lib/sparcv9/libc.so.1:<static-func>+0x5b0
> 2011-07-19 04:08:52.878082|ENG|FATAL|84|engine.cpp(109)|
> /lib/sparcv9/libc.so.1:<static-func>+0x628
> 2011-07-19 04:08:52.878658|ENG|FATAL|84|engine.cpp(109)|
> /lib/sparcv9/libc.so.1:_lwp_kill+0x8 [ Signal 6 (SIGABRT) ]
> 2011-07-19 04:08:52.879196|ENG|FATAL|84|engine.cpp(109)|
> /lib/sparcv9/libc.so.1:abort+0xd0
> 2011-07-19 04:08:52.879733|ENG|FATAL|84|engine.cpp(109)|
> /lib/sparcv9/libc.so.1:_assert+0x74
> 2011-07-19 04:08:52.880325|ENG|FATAL|84|engine.cpp(109)|
> /appl/kabira/MIPSPLUS-1.5.1-110510-SOL64/kis/3rdparty/sol/openldap/2.4.24_64/lib/libldap-2.4.so.2.6.0:<static-func>+0x4ec
> 2011-07-19 04:08:52.880776|ENG|FATAL|84|engine.cpp(109)|
> /appl/kabira/MIPSPLUS-1.5.1-110510-SOL64/kis/3rdparty/sol/openldap/2.4.24_64/lib/libldap-2.4.so.2.6.0:ldap_abandon+0xac
>
> I am in the process of a reproduction of this signal 6 but I would like to share
> the following idea.
>
> Do you think there is a possibility to enhance the openldap library to avoid
> this assert? Is it possible that instead of having an assert, we have a
> exception or a status code which tell us something went wrong of obviously that
> we can handle in our source code.
An assert means there is a bug, either in your code or ours. Since this part
of the library has been around for several years with no issues, that
generally means it's a bug in your code. The way to handle this is to fix your
code.
Trapping or ignoring the conditions that are asserted is just a bad idea.
>
> My best regards
> Olivier GERMAIN
> TIBCO Support team
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
12 years, 2 months
Re: (ITS#7037) slapd crashes with syncrepl when replica cleared out DB
by hyc＠symas.com
ml+openldap(a)esmtp.org wrote:
> Full_Name: Claus Assmann
> Version: 2.4.26
> OS: Red Hat Enterprise Linux Server release 5.5
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (63.211.143.38)
>
>
> While trying to determine how syncrepl behaves in various error
> conditions, I encountered a crash of slapd. A MASTER is set up to
> use push replication to a REPLICA as follows:
>
> database ldap
> hidden on
> suffix ""
> rootdn "cn=slapd-ldap"
> uri ldap://REPLICA/
> lastmod on
> restrict all
> sync_use_subentry true
>
> acl-bind bindmethod=simple
> binddn="cn=Monitor"
> credentials=password
>
> syncrepl rid=001
> provider=ldapi://%2Fvar%2Frun%2Fldapi
> binddn="cn=Manager"
> bindmethod=simple
> credentials=passwd
> searchbase=""
> type=refreshAndPersist
> retry="5 5 60 +"
>
> Reproduce:
> On REPLICA: stop slapd, clear out directory for DB, start
> slapd.
> On MASTER:
> add an entry master which has to be "synced" to REPLICA;
> run ldapsearch to lookup up that entry on MASTER
> slapd dumps core, backtrace:
Thanks for the report. There were two bugs here:
1) the syncrepl_add_glue_ancestors was not constructing a valid DN for the
empty-suffix case.
2) it shouldn't have tried to add glue entries in this case anyway, since
the underlying DB was pulled out from under it.
Both fixed now in master, please test.
> #0 0x00002b7e51344265 in raise () from /lib64/libc.so.6
> #1 0x00002b7e51345d10 in abort () from /lib64/libc.so.6
> #2 0x00002b7e5133d6e6 in __assert_fail () from /lib64/libc.so.6
> #3 0x0000000000549546 in ldap_add_ext (ld=0xbba1bc0, dn=0x0, attrs=0xbeb7ed0,
> sctrls=0x0, cctrls=0x0, msgidp=0x435224c4) at add.c:126
> #4 0x00000000004dbe6d in ldap_back_add (op=0x43523150, rs=0x43522770)
> at add.c:102
> #5 0x0000000000481152 in overlay_op_walk (op=0x43523150, rs=0x43522770,
> which=op_add, oi=0xb9eb6c0, on=0x0) at backover.c:671
> #6 0x00000000004816a7 in over_op_func (op=0x43523150, rs=0x43522770,
> which=op_add) at backover.c:723
> #7 0x0000000000473706 in syncrepl_add_glue_ancestors (op=0x43523150,
> e=0x2b7e56628fb8) at syncrepl.c:3149
> #8 0x000000000047384e in syncrepl_add_glue (op=0x43523150, e=0x2b7e56628fb8)
> at syncrepl.c:3193
> #9 0x0000000000474795 in syncrepl_entry (si=0xb9eb1c0, op=0x43523150,
> entry=0x0, modlist=0x43523ca0, syncstate=<value optimized out>,
> syncUUID=<value optimized out>, syncCSN=0xbeb86e0) at syncrepl.c:2448
> #10 0x000000000047c39b in do_syncrep2 (ctx=<value optimized out>,
> arg=<value optimized out>) at syncrepl.c:982
> #11 do_syncrepl (ctx=<value optimized out>, arg=<value optimized out>)
> at syncrepl.c:1489
> #12 0x000000000041eee3 in connection_read_thread (ctx=0x43523da0,
> argv=<value optimized out>) at connection.c:1276
> #13 0x00000000005412dc in ldap_int_thread_pool_wrapper (xpool=0xb8fa1c0)
> at tpool.c:685
> #14 0x00002b7e510ff73d in start_thread () from /lib64/libpthread.so.0
> #15 0x00002b7e513e84bd in clone () from /lib64/libc.so.6
>
> Note: this also happens with 2.4.23. On a VM instance, it causes
> a different error (see mail on list: "killed after 120 seconds")
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
12 years, 2 months
Re: (ITS#7051) ldap_pvt_tls_get_peer_dn fails under gnutls
by hyc＠symas.com
giampaolo(a)tomassoni.biz wrote:
> Full_Name: Giampaolo Tomassoni
> Version: 2.4.24
> OS: Linux 2.6.39-gentoo-r3
> URL:
> Submission from: (NULL) (79.23.61.128)
>
>
> A triky mistake (is it a typo?) in libraries/libldap/tls_g.c:tlsg_x509_cert_dn
> prevents a gnutls-enabled server to correctly obtain the "subject" ASN.1 tree
> from the client's certificate.
Thanks for the report, now fixed in master, please test.
>
> This is the needed patch:
This patch should not work either, you still need a skip_tag before the get_int.
> --- libraries/libldap/tls_g.c.wrong 2011-09-25 14:58:30.000000000 +0200
> +++ libraries/libldap/tls_g.c 2011-09-25 14:35:06.000000000 +0200
> @@ -530,7 +530,7 @@
> ber_init2( ber, cert, LBER_USE_DER );
> tag = ber_skip_tag( ber,&len ); /* Sequence */
> tag = ber_skip_tag( ber,&len ); /* Sequence */
> - tag = ber_skip_tag( ber,&len ); /* Context + Constructed
> (version) */
> + tag = ber_peek_tag( ber,&len ); /* Context + Constructed
> (version) */
> if ( tag == 0xa0 ) /* Version is optional */
> tag = ber_get_int( ber,&i ); /* Int: Version */
> tag = ber_skip_tag( ber,&len ); /* Int: Serial (can be longer
> than ber_int_t) */
>
>
> Basically, the optional version field in the certificate wasn't peeked, but
> rather skipped. This resulted in walking in the certificate tree in the wrong
> way, thereby impairing a correct result from
> libraries/libldap/tls2.c:ldap_pvt_tls_get_peer_dn.
>
> I'm not using sasl, so I can't be sure about this, but I guess this problem
> could impair client authentication via certificate using the sasl external
> method.
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
12 years, 2 months
Re: (ITS#7052) Spurious CSNs being recorded on syncrepl consumers.
by hyc＠symas.com
cmikk(a)qwest.net wrote:
> Full_Name: Chris Mikkelson
> Version: 2.4.26
> OS: FreeBSD
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (204.147.85.37)
>
>
> When the provider sends a search response with state 'delete' with no / null
> cookie, the syncrepl consumer queues an locally-generated CSN and updates its
> context CSN with that. This appears to happen only with cookie-less deletion,
> not with cookie-less modification. I have not observed a cookie-less addition,
> so I do not know if it occurs there, too.
Thanks for the report. The bug only affected Deletes, not add or modify. Fixed
in master.
> Example logs from a pure consumer (no server-id, replicating from a provider
> with server id 002):
>
> Sep 26 13:05:42 mpls-auth-02 slapd[57295]: do_syncrep2: rid=100 cookie=
> Sep 26 13:05:42 mpls-auth-02 slapd[57295]: syncrepl_entry: rid=100
> LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_DELETE)
> Sep 26 13:05:42 mpls-auth-02 slapd[57295]: syncrepl_entry: rid=100 be_search
> (0)
> Sep 26 13:05:42 mpls-auth-02 slapd[57295]: syncrepl_entry: rid=100
> uid=<snip>,ou=improv,dc=qwest,dc=net
> Sep 26 13:05:42 mpls-auth-02 slapd[57295]: slap_queue_csn: queing 0x7ffffe3fa560
> 20110926130542.130924Z#000000#000#000000
> Sep 26 13:05:42 mpls-auth-02 slapd[57295]: slap_graduate_commit_csn: removing
> 0x8f58a8a90 20110926130542.130924Z#000000#000#000000
>
> This is problematic at our site because the provider cookie contains a SID 0 CSN
> from before we migrated to multimaster, and the SID 0 CSN recorded at the
> consumer renders the consumer state newer than the provider, breaking
> replication.
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
12 years, 2 months
Re: (ITS#7054) Please drop support to FreeBSD 1.x
by d＠delphij.net
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi, Kurt,
On 09/28/11 18:26, Kurt Zeilenga wrote:
> Given the project doesn't specifically attempt to support FreeBSD
> 1.x, your request as summarized in the subject line is a bit odd.
>
> I suggest this be considered more of a request to enable future
> support of the FreeBSD 10.x.
>
> Do the current release of libtool and autotools includes the
> enabling features needed?
>
> If so, then this can simply be treated as a request to update these
> tools (which are generally incorporated without any functional
> change).
>
> If not, well, then we should just wait for thsoe enabling changes
> to be released by the upstream tool provider first
I think we will have to wait for upstream release then, the changes
are already in their source tree.
I'll patch OpenLDAP in the FreeBSD ports to make it work at this moment.
> Regards, Kurt
>
> On Sep 28, 2011, at 2:38 PM, delphij(a)FreeBSD.org wrote:
>
>> Full_Name: Xin Li Version: git trunk OS: FreeBSD/amd64 10.1 URL:
>> http://pastebin.com/G8gpJs0r Submission from: (NULL)
>> (206.40.55.65)
>>
>>
>> Code duplicated from GNU libtool and autotools uses 'freebsd1*'
>> rather than 'freebsd1.*' to test if the system is FreeBSD 1.x.
>> This logic would match FreeBSD 10.0, causing problem when
>> building shared libraries.
>>
>> I'd like to propose that FreeBSD 1.x support be dropped since
>> it's obsolete in 1994 (17 years ago).
>>
>> The patch is just for reference, it also drops FreeBSD 2.x and
>> FreeBSD 3.x support but it's not complete.
>>
>> A libtool patched with git revision
>> e94c6d6e0359d92f08f491f57e0ef3371e978952 would also be required
>> to build OpenLDAP properly.
>>
>
- --
Xin LI <delphij(a)delphij.net> https://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)
iQEcBAEBCAAGBQJOg87cAAoJEATO+BI/yjfBfwIIAIjdABO2EUPVNpGLRrOqt20I
Yl5reH+OsBBwRTgjdDflZJcRA68fb5nsdsrRBheJA6oT0EJKWpPoW+uLjg84zx6s
TvGAifKMDJv6+v/PHpTkv2wO7nYIKXiS6D9415cJk3xMdEcDdRSXi+ppA+6IXGzV
fRL4rej0hoHNvgbXvowOL8F24rnnb6+r9fYYH773rwomL/+rYqZ1+iDbM4zs82d4
TSxOtjmfoEqUCyYJii3jo5CGs1LQ+Ndk16s7uwTArevba89GPVrNL3s/FxBLrEX+
Q8mBHaCkmsX1JuN7ZkYTJz7UvMJJO25IHDfEpjkM5aCqZvuy9nq7kflXxvuOASo=
=Wmav
-----END PGP SIGNATURE-----
12 years, 2 months
Re: (ITS#7054) Please drop support to FreeBSD 1.x
by hyc＠symas.com
delphij(a)FreeBSD.org wrote:
> Full_Name: Xin Li
> Version: git trunk
> OS: FreeBSD/amd64 10.1
> URL: http://pastebin.com/G8gpJs0r
> Submission from: (NULL) (206.40.55.65)
>
>
> Code duplicated from GNU libtool and autotools uses 'freebsd1*' rather than
> 'freebsd1.*' to test if the system is FreeBSD 1.x. This logic would match
> FreeBSD 10.0, causing problem when building shared libraries.
>
> I'd like to propose that FreeBSD 1.x support be dropped since it's obsolete in
> 1994 (17 years ago).
Probably a good idea. Thanks for the patch, but it's basically unusable.
Never submit patches to generated files. Only patch the source files.
configure is generated from configure.in by autoconf. aclocal.m4 is also
generated by autoconf; the section you patched appears to come from the
libtool sources.
> The patch is just for reference, it also drops FreeBSD 2.x and FreeBSD 3.x
> support but it's not complete.
>
> A libtool patched with git revision e94c6d6e0359d92f08f491f57e0ef3371e978952
> would also be required to build OpenLDAP properly.
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
12 years, 2 months
