Logged in as guest
Viewing Historical/5021 Full headers
Major security issue: yes no
Notes: OpenSSL bug Notification:
Date: Fri, 15 Jun 2007 21:59:55 GMT From: h.b.furuseth@usit.uio.no To: openldap-its@OpenLDAP.org Subject: test021-certificate fails on HP-UX
Full_Name: Hallvard B Furuseth Version: RE23, 2.3.35 OS: HP-UX URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-070615.tgz Submission from: (NULL) (129.240.202.105) Submitted by: hallvard test021-certificate fails on HP-UX in RE23 and 2.3.35. It succeeds in HEAD. OpenSSL version: 0.9.7d. I enclose the testrun directory from: $ ./run -b ldif test021-certificate Cleaning up test run directory leftover from previous run. Running ./scripts/test021-certificate... running defines.sh Running slapadd to build slapd database... Starting slapd on TCP/IP port 9011... Testing certificate handling... Add certificates... ldapmodify failed (20)!
Date: Fri, 15 Jun 2007 15:59:57 -0700 From: Quanah Gibson-Mount <quanah@zimbra.com> To: h.b.furuseth@usit.uio.no, openldap-its@openldap.org Subject: Re: (ITS#5021) test021-certificate fails on HP-UX
--On June 15, 2007 9:59:56 PM +0000 h.b.furuseth@usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: RE23, 2.3.35 > OS: HP-UX > URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-070615.tgz > Submission from: (NULL) (129.240.202.105) > Submitted by: hallvard > > > test021-certificate fails on HP-UX in RE23 and 2.3.35. It succeeds in > HEAD. > > OpenSSL version: 0.9.7d. > > I enclose the testrun directory from: > > $ ./run -b ldif test021-certificate > Cleaning up test run directory leftover from previous run. > Running ./scripts/test021-certificate... > running defines.sh > Running slapadd to build slapd database... > Starting slapd on TCP/IP port 9011... > Testing certificate handling... > Add certificates... > ldapmodify failed (20)! > The last modify is erroring with already exists. The last logged modify looks really weird to me: conn=1 op=4 MOD attr=userCertificate;binary userCertificate;binary Why is it modifying the same attribute twice? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
From: Hallvard B Furuseth <h.b.furuseth@usit.uio.no> Date: Sat, 16 Jun 2007 18:25:47 +0200 To: quanah@zimbra.com Cc: openldap-its@openldap.org Subject: Re: (ITS#5021) test021-certificate fails on HP-UX
quanah@zimbra.com writes: > conn=1 op=4 MOD attr=userCertificate;binary userCertificate;binary > Why is it modifying the same attribute twice? It adds one cert and deletes another in the same op. The log from a successful run on Linux shows the same. -- Regards, Hallvard
From: Hallvard B Furuseth <h.b.furuseth@usit.uio.no> Date: Sat, 16 Jun 2007 22:32:58 +0200 To: openldap-its@openldap.org Subject: Re: (ITS#5021) test021-certificate fails on HP-UX
Bug in OpenSSL 0.9.7d - unless it's with how OpenLDAP uses it, I don't know. The offending operation (on Jennifer Smith) adds one certificate and deletes the old one. However the added and the old certificate compare equal because certificateExactNormalize() produces the same string for both: 0$email=ca@example.com,cn=example ca, o=openldap example\2C ltd.,st=california,c=us That's because i2s_ASN1_INTEGER(0, sn ) in certificateExactNormalize() returns serial number "0". The inputs to that function are (gdb) p *sn $6 = {length = 1, type = 2, data = 0x402e5278 "\003", flags = 0} and (gdb) p *sn $8 = {length = 1, type = 2, data = 0x402e5cf0 "\001xample.@\036", flags = 0} Those *sn values are the same as on a successful run on Linux, except the 2nd data[1...] (the xample... string) which I presume does not matter when length=1. The input certificates ('val' arg to certificateExactNormalize()) are correct. -- Regards, Hallvard
Date: Sat, 16 Jun 2007 17:14:01 -0700 From: Howard Chu <hyc@symas.com> To: h.b.furuseth@usit.uio.no CC: openldap-its@openldap.org Subject: Re: (ITS#5021) test021-certificate fails on HP-UX
h.b.furuseth@usit.uio.no wrote: > Bug in OpenSSL 0.9.7d - unless it's with how OpenLDAP uses it, I don't > know. Are you using the same version of OpenSSL on your other test machines? Have you tried a newer version? Makes sense that this wouldn't be a problem in HEAD since we're now using liblber for certificate handling. I suppose we could patch RE23 to use ber_get_int for the serial number. But at the moment this seems to be an OpenSSL problem, in which case we can close this ITS. > The offending operation (on Jennifer Smith) adds one certificate and > deletes the old one. However the added and the old certificate compare > equal because certificateExactNormalize() produces the same string for > both: > 0$email=ca@example.com,cn=example ca, > o=openldap example\2C ltd.,st=california,c=us > > That's because i2s_ASN1_INTEGER(0, sn ) in certificateExactNormalize() > returns serial number "0". The inputs to that function are > (gdb) p *sn > $6 = {length = 1, type = 2, data = 0x402e5278 "\003", flags = 0} > and > (gdb) p *sn > $8 = {length = 1, type = 2, data = 0x402e5cf0 "\001xample.@\036", flags = 0} > Those *sn values are the same as on a successful run on Linux, except > the 2nd data[1...] (the xample... string) which I presume does not > matter when length=1. > > The input certificates ('val' arg to certificateExactNormalize()) are > correct. > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
From: Hallvard B Furuseth <h.b.furuseth@usit.uio.no> Date: Sun, 17 Jun 2007 18:59:24 +0200 To: Howard Chu <hyc@symas.com> Cc: openldap-its@openldap.org Subject: Re: (ITS#5021) test021-certificate fails on HP-UX
Howard Chu writes: > Are you using the same version of OpenSSL on your other test machines? > Have you tried a newer version? Yes, and not yet. > (...) But at the moment this seems to be an OpenSSL problem, in which > case we can close this ITS. Yes, or put it on Feedback. I'll have a closer look at this eventually, but just compiling OpenSSL on that HP box takes ages. Don't hold RE23 for this. -- Regards, Hallvard
______________ © Copyright 2009, OpenLDAP Foundation, info@OpenLDAP.org
