- openldap-bugs - openldap.org

Re: (ITS#7271) Don't clobber SASL_NOCANON in clients/tools/common.c
by hyc＠symas.com 30 May '12

30 May '12

wking(a)tremily.us wrote: > Full_Name: W. Trevor King > Version: git commit 22bf5188 > OS: Gentoo > URL: http://blog.tremily.us/posts/LDAP/tool-nocanon.patch > Submission from: (NULL) (72.68.88.202) > > > The ldap.conf SASL_NOCANON configuration option (or LDAPSASL_NOCANON environment > variable) should set the default behaviour for OpenLDAP tools such as > ldapwhoami. This configuration option should allow users to use the tools > without having to use the matching command line option (-N). Unfortunately, the > current code sets the option to true/false after only querying the command line > option. > > I'm linking to a patch that looks at the current value of the option first, and > if it's true, skips processing the command line option (which would either be a > redundant -N keeping the option true, or an absence of -N which implies the user > wants to use the configured value (true)). > > Another approach would be to set the initial value of nocanon to UNINITIALIZED > (-1?). Command line arguments could set nocanon to 1 (true, -N) or false (0, > --canon?). Then we would only call ldap_set_option if nocanon was not > UNINITIALIZED. > > I can work up a patch using this second approach if people prefer. If so, let > me know if you want me to define UNINITIALIZED, or to just use -1. > > I didn't check, but I would not be surprised if this same clobbering occurred > for other command line options. The only other boolean command line option is referrals, which is deprecated and has been undocumented for years. Not worth bothering over. Ideally the command line option should have been able to set this explicitly to both true and false, to allow complete control over the option. But I'm not particularly concerned either way. Since the option currently can only be set to true, it would be sufficient to just check for nocanon != 0 before calling ldap_set_option. -- -- 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#7270) Double free in ldap_int_initialize
by hyc＠symas.com 30 May '12

30 May '12

fdeweerdt(a)cloudmark.com wrote: > Full_Name: Frederik Deweerdt > Version: current HEAD > OS: Linux > URL: ftp://ftp.openldap.org/incoming/Frederik-Deweerdt-120511.patch > Submission from: (NULL) (72.5.239.5) > > > [PATCH] Protect accesses to ldap_int_hostname with a mutex Thanks for the patch, now in git master. > > > Not protecting the accesses to ldap_int_hostname would lead to a double > free with the following trace: > > #7 0x0000003aca031d10 in abort () from /lib64/libc.so.6 > No symbol table info available. > #8 0x0000003aca06a99b in __libc_message () from /lib64/libc.so.6 > No symbol table info available. > #9 0x0000003aca0729d6 in free () from /lib64/libc.so.6 > No symbol table info available. > #10 0x000000328902333e in ldap_int_initialize () > from /usr/lib64/libldap-2.3.so.0 > No symbol table info available. > #11 0x000000328900c426 in ldap_create () from /usr/lib64/libldap-2.3.so.0 > No symbol table info available. > #12 0x000000328900ca0d in ldap_init () from /usr/lib64/libldap-2.3.so.0 > No symbol table info available. > > The race in init.c:ldap_int_initialize is as follows: > 646 char *name = ldap_int_hostname; > 647 > 648 ldap_int_hostname = ldap_pvt_get_fqdn( name ); > 649 > 650 if ( name != NULL && name != ldap_int_hostname ) { > 651 LDAP_FREE( name ); > 652 } > > - T1 and T2 enter ldap_int_initialize, both assign to name the current > address of ldap_int_hostname, say 0x1234. > - T1 and T2 call ldap_pvt_get_fqdn(), updating ldap_int_hostname to 0x1235 > and 0x1236 respectively. > - T1 and T2 reach the name != ldap_int_hostname check. In both threads > it's false, because 0x1235 != 0x1234 and 0x1236 != 0x1234, respectively. > - T1 and T2 both try to free 0x1234 => Crash. > --- > libraries/libldap/init.c | 2 ++ > libraries/libldap/ldap-int.h | 1 + > libraries/libldap/util-int.c | 3 +++ > 3 files changed, 6 insertions(+), 0 deletions(-) > > > -- -- 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#7283) Usage of private headers make building out-of-tree extensions painful
by hyc＠symas.com 30 May '12

30 May '12

guillomovitch(a)gmail.com wrote: > Full_Name: Guillaume Rousse > Version: any > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.93.30.10) > > > In order to build out of tree extensions, such as ppolicy external password > checker (http://ltb-project.org/wiki/documentation/openldap-ppolicy-check-password), > you need additional slapd headers, portable.h and slapd.h (and a bunch of > additional dependant ones), which are currently not installed, and thus > considered as private. > > A request to ship those headers was refused by fedora package maintainer, > precisely for this reason: > https://bugzilla.redhat.com/show_bug.cgi?id=812860 They gave the right answer. The slap.h header is private and subject to change without notice. > The situation ought to be clarified, and some kind of solution found, as > maintaining a custom slapd build just to be able to benefit from this > extensability is largely overkill. Probably this should be discussed on the openldap-devel mailing list. There's no straightforward solution to this request. In the case of the LTB password checker module, there's barely any need for slap.h; the module could easily be tweaked to avoid all references to it. -- -- 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#7279) Apparently mdb "approx" index generation failure for mdb_add for syncrepl consumer
by hyc＠symas.com 30 May '12

30 May '12

brandon.hume(a)dal.ca wrote: > Full_Name: Brandon Hume > Version: 2.4.31 > OS: RHEL EL6.1, kernel 2.6.32-131.12.1.el6.x86_64 > URL: http://den.bofh.ca/~hume/mdb_approx_indexfail.tar > Submission from: (NULL) (2001:410:a010:2:223:aeff:fe74:400e) > > > An empty syncrepl consumer using mdb backend will suffer index generator > failures when populating its database from the provider and using "approx" index > options. The failure manifests in syslog (with olcLogLevel=Stats) as the > following: > > May 24 11:50:41 node2 slapd[25282]: null_callback : error code 0x50 > May 24 11:50:41 node2 slapd[25282]: syncrepl_entry: rid=001 be_add $DN failed > (80) > > These problems don't seem to occur when populating the provider using slapadd. > The problem only seems to manifest when the new entry arrives via syncrepl. > Playing with gdb, it seems like indexer() ends up being called with { bv_len = > 0, bv_val = "" } when indexing "givenName". Thanks for the report, fixed now in git master. slapadd also failed for me, so it wasn't quite the same behavior you reported. > > Could be because "givenName" on the troublesome entry is only one character? > > A minimalist DIT and config are provided in the tarfile in the link. The two > nodes are running in mirrormode, and I'm not sure if that makes a difference. The config is invalid; you have used the same RIDs multiple times. -- -- 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

(ITS#7283) Usage of private headers make building out-of-tree extensions painful
by guillomovitch＠gmail.com 30 May '12

30 May '12

Full_Name: Guillaume Rousse Version: any OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.93.30.10) In order to build out of tree extensions, such as ppolicy external password checker (http://ltb-project.org/wiki/documentation/openldap-ppolicy-check-password), you need additional slapd headers, portable.h and slapd.h (and a bunch of additional dependant ones), which are currently not installed, and thus considered as private. A request to ship those headers was refused by fedora package maintainer, precisely for this reason: https://bugzilla.redhat.com/show_bug.cgi?id=812860 The situation ought to be clarified, and some kind of solution found, as maintaining a custom slapd build just to be able to benefit from this extensability is largely overkill.

1 0

Re: (ITS#7274) delta-syncrepl MMR infinite loop
by quanah＠zimbra.com 30 May '12

30 May '12

--On Tuesday, May 29, 2012 6:25 PM -0700 Howard Chu <hyc(a)openldap.org> wrote: >> so it is tracking "000" as a third master? This seems to be why the >> original server (which was 000 before being promoted to 001) replicates >> these entries back to itself. > > The loop is caused by the patch to ITS#6872, which considers a consumer > out of date whenever the number of CSNs in its sync request doesn't match > the number known to the provider. > > The data here is basically invalid: server1 has entries generated using > SID=0 but it has no contextCSN value with SID=0. It only sent SID=1 and > SID=2 in its sync request. Server2, which just updated from server1, has > a contextCSN for SID=0 in addition to 1 and 2 (and that's all correct). > > Server1 should have always had a contextCSN value for SID=0 but doesn't. > This problem would not occur if server1 was converted first from > standalone into a single-master. I.e., load syncprov on it, let it scan > the DB and generate the first sid=0 contextCSN, before turning it intu a > MMR node. For documentation purposes -- The issue occurred because I set olcServerID before I loaded syncprov. Re-ordering my script to load syncprov (which then caused a contextCSN value to be correctly generated on Server1 for SID=0) fixed this loop. --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#7274) delta-syncrepl MMR infinite loop
by hyc＠OpenLDAP.org 30 May '12

30 May '12

quanah(a)zimbra.com wrote: > --On Wednesday, May 16, 2012 10:27 PM +0000 quanah(a)OpenLDAP.org wrote: > >> Full_Name: Quanah Gibson-Mount >> Version: 2.4.31 >> OS: Linux 2.6 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (75.108.184.39) > > We can see that the script turning it into a master ran here: > > Thu May 17 16:05:46 2012 *** Running as zimbra user: > /opt/zimbra/libexec/zmldapenable-mmr -s 2 -m > ldap://zre-ldap002.eng.vmware.com:389/ > > so 16:05:46 > > In the accesslog, we see: > > dn: cn=accesslog > objectClass: auditContainer > cn: accesslog > structuralObjectClass: auditContainer > contextCSN: 20120517225152.913667Z#000000#000#000000 > contextCSN: 20120517230823.615364Z#000000#001#000000 > contextCSN: 20120517230546.409118Z#000000#002#000000 > > dn: reqStart=20120517230546.000019Z,cn=accesslog > objectClass: auditAdd > structuralObjectClass: auditAdd > reqStart: 20120517230546.000019Z > reqEnd: 20120517230546.000020Z > reqType: add > reqSession: 100 > reqAuthzID: cn=config > reqDN: cn=zimbra > reqResult: 0 > reqMod: objectClass:+ organizationalRole > reqMod: description:+ Zimbra Systems Application Data > reqMod: cn:+ zimbra > reqMod: structuralObjectClass:+ organizationalRole > reqMod: entryUUID:+ 40f78bea-34be-1031-8a5d-e1466f667e19 > reqMod: creatorsName:+ cn=config > reqMod: createTimestamp:+ 20120517224907Z > reqMod: entryCSN:+ 20120517224907.221672Z#000000#000#000000 > reqMod: modifiersName:+ cn=config > reqMod: modifyTimestamp:+ 20120517224907Z > reqEntryUUID: 40f78bea-34be-1031-8a5d-e1466f667e19 > entryUUID: 948929e2-34c0-1031-9a14-c93bd10ff0f2 > creatorsName: cn=config > createTimestamp: 20120517224907Z > entryCSN: 20120517224907.221672Z#000000#000#000000 > modifiersName: cn=config > modifyTimestamp: 20120517224907Z > > so it is tracking "000" as a third master? This seems to be why the > original server (which was 000 before being promoted to 001) replicates > these entries back to itself. The loop is caused by the patch to ITS#6872, which considers a consumer out of date whenever the number of CSNs in its sync request doesn't match the number known to the provider. The data here is basically invalid: server1 has entries generated using SID=0 but it has no contextCSN value with SID=0. It only sent SID=1 and SID=2 in its sync request. Server2, which just updated from server1, has a contextCSN for SID=0 in addition to 1 and 2 (and that's all correct). Server1 should have always had a contextCSN value for SID=0 but doesn't. This problem would not occur if server1 was converted first from standalone into a single-master. I.e., load syncprov on it, let it scan the DB and generate the first sid=0 contextCSN, before turning it intu a MMR node. -- -- 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#7280) accesslog write to subentry of log database
by quanah＠zimbra.com 30 May '12

30 May '12

--On Sunday, May 27, 2012 11:27 PM +0000 openldap(a)stormcloud9.net wrote: > This is nonconstructive. I know not to do that, I'm the one who > filed the ITS...<br> > You don't address the feature request at all, only that it > currently doesn't work which is why the request was filed in the > first place. Is logging multiple accesslog overlays to the same > backend database unfeasible?<br> No. -- 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#7282) Invalid Regex in Documentation
by quanah＠zimbra.com 30 May '12

30 May '12

--On Tuesday, May 29, 2012 5:04 PM +0000 alacer.cogitatus(a)gmail.com wrote: > Full_Name: Kyle Smith > Version: 2.4.30 > OS: Ubuntu Server 10.04.02LTS > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (192.245.87.13) > > > In section 8.2.5 of the OpenLDAP Documentation (Access Control Examples), > the example regex to allow an IP address is given by: > > by peername.regex=IP:10\..+ read > > I think it should read: > > by peername.regex=IP=10\..+ read > > Thanks, fixed. --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#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by michael＠stroeder.com 29 May '12

29 May '12

This is a cryptographically signed message in MIME format. --------------ms000604020701070406090000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Howard Chu wrote: > Michael Str=F6der wrote: >> hyc(a)symas.com wrote: >>> Michael Str=F6der wrote: >>>> Howard Chu wrote: >>>>> The text also states >>>>> The practice of storing hashed passwords in userPassword viol= ates >>>>> Standard Track (RFC 4519) schema specifications and may hinde= r >>>>> interoperability. >>>> >>>> In practice we all live very well with this for years. That's least = of a >>>> problem today. >>>> >>>>> Anyone building operational procedures on something that violates t= he specs >>>>> was asking for trouble. Users should be using ldappasswd, that's wh= at >>>>> it's for. >>>> >>>> ??? >>>> >>>> ldappasswd writes a hashed password to - tataa - attribute 'userPass= word'. >>>> I cannot see how this is different from using ldapadd/ldapmodify. >>> >>> Wrong, ldappasswd sends a PasswordModify exop to a server. The server= may >>> implement that exop in any implementation-specific manner, and there = is no >>> guarantee that the password a server uses is ever instantiated in any= LDAP >>> entry. There is no guarantee that setting a userPassword attribute us= ing >>> ldapadd/ldapmodify will ever do anything useful for any given LDAP us= er. >> >> You're arguing based on what a LDAP server could do. I'm arguing based= on what >> OpenLDAP and other server implementations are doing for years. >=20 > ActiveDirectory is an obvious example invalidating your argument. Does MS AD support RFC 3062? AFAIK W2K3 doesn't. I don't currently have the possibility to check with most recent W2K8R2 t= hough. Anyway that's not relevant here either. We're talking about how OpenLDAP stores and checks the passwords since over a decade. Violating Standard Track (RFC 4519) schema specifications could be avoide= d by implementing RFC 3112. But this also never happened. > Don't fix what isn't broken. With this argument you can immediately stop any progress. Maybe also a valuable statement by the OpenLDAP chief architect. Ciao, Michael. --------------ms000604020701070406090000 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFOzCC BTcwggMfoAMCAQICAwl4kDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEx MTcxNTQzMzFaFw0xMjExMTYxNTQzMzFaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggEAMIH9MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3Vy IG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNl cnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYB BAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkq hkiG9w0BAQUFAAOCAgEANPf/aLF41eQlvN5dEg3CFnlN//qQK7+EPIXLnHprNWLb4nBwgdPj /E+qa1umT7px4Py3VS0UTKqLmMdWftwid8MOMHWalZwrfx0Z8U3He+EdJhOSnn9vdd/ug7Xd dI/hRjLaBSq9ZhCczEUgL6vTxCYPlIoHF56y/oxSJw59vRBjvRFKXvpBZWseeRkcGACQduNH SNdWC1IqHAbQlgOS9VWQUYlm//BdaLkezRxqnQp5+KJMAcZzHpdNJ3G4SqCJ02Z3n4kk8IKZ AjgiWxisDFNsfXKDb9Ng5ntnnH2ouxrgPoNnW445tgkz50VKHstylx9s5O3G7uUTtg0J+z63 TA8xbN6kzRx7RgAUkEXhl6WEdW+3EVj5tYY38Uy8vleP+gYZfphKEmQJgIQqy9D2+gesbolT QdWYgbUYY2AHJOshskMW7pahYnFX2pZmn/ayaPc+JFJlCEqO0+DcYQjYuv6sntQgZGkok7yZ R4xMbyCp61pTrfGWOufZs/FiScJZg1IWY5qb4URH4VZZjLNMR2pFMRuE4LvgkkMRasbUv7Yv n3Lzv34lTfJKUqYW6nx//L2NS4rN63o0taPwRygnuBK4kp7EYEcwtLeanJhQoIu4b6If9rwy D7CFAp51wIewV9VtZ1Is0irNBcMVyhJogIcuIn+VWY1ff1RxySD/djMxggOUMIIDkAIBATCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcx IjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1 cHBvcnRAY2FjZXJ0Lm9yZwIDCXiQMAkGBSsOAwIaBQCgggHoMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDUyOTIxMTU0N1owIwYJKoZIhvcNAQkEMRYE FPftjo2JfwDdzUByvPPFBJpEMBd4MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE ggEAqWLrqBEmQFwdUWzw3ZuQR0bnPzvAMZBb81cTmCzguvREDKdmO9vYvDVzoB/AhnnE6cE+ NYlO7uQBg7AiQSq++LoQ93tYsIjoZM44xiOxx8k+tAkhTUGEK4yJ9G86ptDRa/VSK25vC/Jg dfza7znhUF2210scAyjiG46RSRG/otIAhuMRjRKtvbC5jD5luJeJxePFpWR/V7+qKWmVvyJU mIGY90XdKmhY3b8XNWecfghap8V4NVNWzLuNxwH6vW8ym8+W4eZ/EsMsJ7+ht7HqgE71hjtj QtDfdcEGGww1Ch0tGj7HbynRm7pf2airOQ3j8GxMwFkkq/If8+4jqrNC1gAAAAAAAA== --------------ms000604020701070406090000--

1 0

Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by quanah＠zimbra.com 29 May '12

29 May '12

--On Tuesday, May 29, 2012 8:38 PM +0000 michael(a)stroeder.com wrote: > Well, you're the OpenLDAP god. So you can arbitrarly decide whatever you > want. (But you shouldn't wonder why there's no active OpenLDAP community.) Comments like this weaken any point you are trying to make, serve no purpose, and are obnoxious. Your emails would be better served without them. --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#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by hyc＠symas.com 29 May '12

29 May '12

Michael Ströder wrote: > hyc(a)symas.com wrote: >> Michael Ströder wrote: >>> Howard Chu wrote: >>>> The text also states >>>> The practice of storing hashed passwords in userPassword violates >>>> Standard Track (RFC 4519) schema specifications and may hinder >>>> interoperability. >>> >>> In practice we all live very well with this for years. That's least of a >>> problem today. >>> >>>> Anyone building operational procedures on something that violates the specs >>>> was asking for trouble. Users should be using ldappasswd, that's what it's for. >>> >>> ??? >>> >>> ldappasswd writes a hashed password to - tataa - attribute 'userPassword'. >>> I cannot see how this is different from using ldapadd/ldapmodify. >> >> Wrong, ldappasswd sends a PasswordModify exop to a server. The server may >> implement that exop in any implementation-specific manner, and there is no >> guarantee that the password a server uses is ever instantiated in any LDAP >> entry. There is no guarantee that setting a userPassword attribute using >> ldapadd/ldapmodify will ever do anything useful for any given LDAP user. > > You're arguing based on what a LDAP server could do. I'm arguing based on what > OpenLDAP and other server implementations are doing for years. ActiveDirectory is an obvious example invalidating your argument. > None of what you said in this thread is a real argument against adding SHA-2 > hash algos to the core. Still you did not answer why SHA-1 is in and SHA-2 is out. At present there is no need to change anything in the core since SHA-2 support can be dynamically loaded. Don't fix what isn't broken. -- -- 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#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by michael＠stroeder.com 29 May '12

29 May '12

hyc(a)symas.com wrote: > Michael Ströder wrote: >> Howard Chu wrote: >>> The text also states >>> The practice of storing hashed passwords in userPassword violates >>> Standard Track (RFC 4519) schema specifications and may hinder >>> interoperability. >> >> In practice we all live very well with this for years. That's least of a >> problem today. >> >>> Anyone building operational procedures on something that violates the specs >>> was asking for trouble. Users should be using ldappasswd, that's what it's for. >> >> ??? >> >> ldappasswd writes a hashed password to - tataa - attribute 'userPassword'. >> I cannot see how this is different from using ldapadd/ldapmodify. > > Wrong, ldappasswd sends a PasswordModify exop to a server. The server may > implement that exop in any implementation-specific manner, and there is no > guarantee that the password a server uses is ever instantiated in any LDAP > entry. There is no guarantee that setting a userPassword attribute using > ldapadd/ldapmodify will ever do anything useful for any given LDAP user. You're arguing based on what a LDAP server could do. I'm arguing based on what OpenLDAP and other server implementations are doing for years. None of what you said in this thread is a real argument against adding SHA-2 hash algos to the core. Still you did not answer why SHA-1 is in and SHA-2 is out. Well, you're the OpenLDAP god. So you can arbitrarly decide whatever you want. (But you shouldn't wonder why there's no active OpenLDAP community.) Ciao, Michael.

1 0

Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by hyc＠symas.com 29 May '12

29 May '12

Michael Ströder wrote: > Howard Chu wrote: >> The text also states >> The practice of storing hashed passwords in userPassword violates >> Standard Track (RFC 4519) schema specifications and may hinder >> interoperability. > > In practice we all live very well with this for years. That's least of a > problem today. > >> Anyone building operational procedures on something that violates the specs >> was asking for trouble. Users should be using ldappasswd, that's what it's for. > > ??? > > ldappasswd writes a hashed password to - tataa - attribute 'userPassword'. > I cannot see how this is different from using ldapadd/ldapmodify. Wrong, ldappasswd sends a PasswordModify exop to a server. The server may implement that exop in any implementation-specific manner, and there is no guarantee that the password a server uses is ever instantiated in any LDAP entry. There is no guarantee that setting a userPassword attribute using ldapadd/ldapmodify will ever do anything useful for any given LDAP user. -- -- 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#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by michael＠stroeder.com 29 May '12

29 May '12

This is a cryptographically signed message in MIME format. --------------ms050402080405010103060108 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Howard Chu wrote: > The text also states > The practice of storing hashed passwords in userPassword violates > Standard Track (RFC 4519) schema specifications and may hinder > interoperability. In practice we all live very well with this for years. That's least of a problem today. > Anyone building operational procedures on something that violates the s= pecs > was asking for trouble. Users should be using ldappasswd, that's what i= t's for. ??? ldappasswd writes a hashed password to - tataa - attribute 'userPassword'= =2E I cannot see how this is different from using ldapadd/ldapmodify. So what are you really trying to say? Ciao, Michael. --------------ms050402080405010103060108 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFOzCC BTcwggMfoAMCAQICAwl4kDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEx MTcxNTQzMzFaFw0xMjExMTYxNTQzMzFaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggEAMIH9MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3Vy IG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNl cnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYB BAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkq hkiG9w0BAQUFAAOCAgEANPf/aLF41eQlvN5dEg3CFnlN//qQK7+EPIXLnHprNWLb4nBwgdPj /E+qa1umT7px4Py3VS0UTKqLmMdWftwid8MOMHWalZwrfx0Z8U3He+EdJhOSnn9vdd/ug7Xd dI/hRjLaBSq9ZhCczEUgL6vTxCYPlIoHF56y/oxSJw59vRBjvRFKXvpBZWseeRkcGACQduNH SNdWC1IqHAbQlgOS9VWQUYlm//BdaLkezRxqnQp5+KJMAcZzHpdNJ3G4SqCJ02Z3n4kk8IKZ AjgiWxisDFNsfXKDb9Ng5ntnnH2ouxrgPoNnW445tgkz50VKHstylx9s5O3G7uUTtg0J+z63 TA8xbN6kzRx7RgAUkEXhl6WEdW+3EVj5tYY38Uy8vleP+gYZfphKEmQJgIQqy9D2+gesbolT QdWYgbUYY2AHJOshskMW7pahYnFX2pZmn/ayaPc+JFJlCEqO0+DcYQjYuv6sntQgZGkok7yZ R4xMbyCp61pTrfGWOufZs/FiScJZg1IWY5qb4URH4VZZjLNMR2pFMRuE4LvgkkMRasbUv7Yv n3Lzv34lTfJKUqYW6nx//L2NS4rN63o0taPwRygnuBK4kp7EYEcwtLeanJhQoIu4b6If9rwy D7CFAp51wIewV9VtZ1Is0irNBcMVyhJogIcuIn+VWY1ff1RxySD/djMxggOUMIIDkAIBATCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcx IjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1 cHBvcnRAY2FjZXJ0Lm9yZwIDCXiQMAkGBSsOAwIaBQCgggHoMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDUyOTE4MTEyMVowIwYJKoZIhvcNAQkEMRYE FMxpg47lo/Kju6s3IV/LCMAeyzViMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE ggEAPDeuZINq0dhCIixcpzDn15b8usj8fAjOx/IOUdH3GEfMwNcC7Qi4lEDwuT1hvriqLT9x RTO4CcPCm5GZ2A8MWqayf+oRZtfZmU6ueLNPS08D4fMIkdU5DScFGmSFajm/qVfP8V4iwWur xn4xtYjEXY6SqD2vZK0rYGrr9KS72pNunNEXzUkI6SmGVDp5Q9463FkoBQj9DFYrLSe5iBPO CVNZlHsnTfWvW3Cm4SP7x2VFoqpT6snisrYWv3hcJjSinsBCEnW+qwAcuCpuByMWA/hFr9vj OBz3Y1W7obMI6DUxdBq4ECdDWTDoqLsCfEJGLeoq1oQ9n5r2UNDSPnPJ9QAAAAAAAA== --------------ms050402080405010103060108--

1 0

Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by hyc＠symas.com 29 May '12

29 May '12

Michael Ströder wrote: > hyc(a)symas.com wrote: >> Why should X user ever need to run this tool to generate a value? > >>From slappasswd(8): > > DESCRIPTION > Slappasswd is used to generate an userPassword value suitable > for use with ldapmodify(1), slapd.conf(5) rootpw configuration > directive or the slapd-config(5) olcRootPW configuration directive. > > Do you want to restrict this text regarding ldapmodify(1) only for the cases > that the slappasswd user has also write access to back-config? We could probably delete that ldapmodify(1) reference. Technically it has always been wrong, since there's never been any guarantee that an LDAP user's password was ever stored in any user-accessible attribute. > Of course your are the OpenLDAP boss. You can change everything to make it > work for you. But it breaks existing operational procedures for other people. The text also states The practice of storing hashed passwords in userPassword violates Standard Track (RFC 4519) schema specifications and may hinder interoperability. Anyone building operational procedures on something that violates the specs was asking for trouble. Users should be using ldappasswd, that's what it's for. -- -- 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#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by quanah＠zimbra.com 29 May '12

29 May '12

--On Tuesday, May 29, 2012 5:49 PM +0000 michael(a)stroeder.com wrote: > hyc(a)symas.com wrote: >> Why should X user ever need to run this tool to generate a value? > > From slappasswd(8): > > DESCRIPTION > Slappasswd is used to generate an userPassword value suitable > for use with ldapmodify(1), slapd.conf(5) rootpw configuration > directive or the slapd-config(5) olcRootPW configuration directive. > > Do you want to restrict this text regarding ldapmodify(1) only for the > cases that the slappasswd user has also write access to back-config? The tool has allowed the ability to generate password values for years. It is not uncommon to use it to do just that. I've often used it to generate base-64 encoded SSHA values to push into LDIF I will be writing to the server via ldapmodify. That should not require access to cn=config/slapd.conf. --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#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by michael＠stroeder.com 29 May '12

29 May '12

hyc(a)symas.com wrote: > Why should X user ever need to run this tool to generate a value? >From slappasswd(8): DESCRIPTION Slappasswd is used to generate an userPassword value suitable for use with ldapmodify(1), slapd.conf(5) rootpw configuration directive or the slapd-config(5) olcRootPW configuration directive. Do you want to restrict this text regarding ldapmodify(1) only for the cases that the slappasswd user has also write access to back-config? Of course your are the OpenLDAP boss. You can change everything to make it work for you. But it breaks existing operational procedures for other people. Ciao, Michael.

1 0

Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by michael＠stroeder.com 29 May '12

29 May '12

Howard Chu wrote: > michael(a)stroeder.com wrote: >> Doesn't this ask for fully integrating SHA-2 password support into >> libraries/liblutil/passwd.c? > > Clearly you haven't thought this through. Maybe. But one question: Why is SHA-1 in the core and SHA-2 isn't? IMO that's just an arbitrary choice. > No, because that doesn't solve the problem of how to use other contrib passwd > modules. If you come up with another overall solution to avoid reading the config when using slappasswd I'm of course fine with that too. Ciao, Michael.

1 0

Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by hyc＠symas.com 29 May '12

29 May '12

Quanah Gibson-Mount wrote: > --On Tuesday, May 29, 2012 4:08 PM +0000 hyc(a)symas.com wrote: > >>> It is a problem that a slappasswd user must have read privilage >>> on slapd.conf (or slapd.d) by this patch... >> >> slappasswd is an administrative command; if you don't have administrator >> access already you have no business running it. > > What in any way makes it administrative? You simply give it a password to > convert into whatever scheme for you. Where is the administrative > requirement? Why shouldn't X user with some particular permissions into > the database, but not the configuration, be able to run it to generate a > value? slap*(8) are all administrative tools, by definition. You should already know that. Why should X user ever need to run this tool to generate a value? slapd generates users' password values automatically. The only time anyone ever *needs* this tool is for setting a rootpw in the slapd config. That's the only reason this tool exists and it is the only valid use case. -- -- 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#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by hyc＠symas.com 29 May '12

29 May '12

michael(a)stroeder.com wrote: > Doesn't this ask for fully integrating SHA-2 password support into > libraries/liblutil/passwd.c? Clearly you haven't thought this through. No, because that doesn't solve the problem of how to use other contrib passwd modules. -- -- 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#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by michael＠stroeder.com 29 May '12

29 May '12

Kurt(a)OpenLDAP.org wrote: > I'd argue that slappassword shouldn't read the configuration and hence not > support 'contributed' hash mechanisms. Which means if SHA-2 stays in a separate overlay contrib/ there won't be practically usable SHA-2 support in OpenLDAP. I consider it falling behind other LDAP server implementations. > But if you are going to make slappassword read the configuration, then it > needs to be restricted to only users who have read access to the > configuration. Yes. > I have no real opinion about whether SHA-2 should or shouldn't be in the > core set of hashes... but personally I rather push folks towards SCRAM > compatible hashes than the same poor usages of newer hash algorithms. I concur that SCRAM would be the best choice. But IMO adding SHA-2 support to the core does not hold anybody back from developing/deploying SCRAM. In reality getting completely rid of simple bind in favour of SASL bind no matter which SASL mech is nothing done so easily with all the applications out in the wild. And last time I checked SCRAM support in cyrus-sasl required clear-text password in userPassword. So this is outside the OpenLDAP project, isn't it? Ciao, Michael.

1 0

Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by Kurt＠OpenLDAP.org 29 May '12

29 May '12

I'd argue that slappassword shouldn't read the configuration and hence not support 'contributed' hash mechanisms. But if you are going to make slappassword read the configuration, then it needs to be restricted to only users who have read access to the configuration. I have no real opinion about whether SHA-2 should or shouldn't be in the core set of hashes... but personally I rather push folks towards SCRAM compatible hashes than the same poor usages of newer hash algorithms. -- Kurt

1 0

(ITS#7282) Invalid Regex in Documentation
by alacer.cogitatus＠gmail.com 29 May '12

29 May '12

Full_Name: Kyle Smith Version: 2.4.30 OS: Ubuntu Server 10.04.02LTS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.245.87.13) In section 8.2.5 of the OpenLDAP Documentation (Access Control Examples), the example regex to allow an IP address is given by: by peername.regex=IP:10\..+ read I think it should read: by peername.regex=IP=10\..+ read

1 0

Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by michael＠stroeder.com 29 May '12

29 May '12

This is a cryptographically signed message in MIME format. --------------ms010700080803040702000401 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable quanah(a)zimbra.com wrote: > --On Tuesday, May 29, 2012 4:08 PM +0000 hyc(a)symas.com wrote: >=20 >>> It is a problem that a slappasswd user must have read privilage >>> on slapd.conf (or slapd.d) by this patch... >> >> slappasswd is an administrative command; if you don't have administrat= or >> access already you have no business running it. >=20 > What in any way makes it administrative? You simply give it a password= to=20 > convert into whatever scheme for you. Where is the administrative=20 > requirement? Why shouldn't X user with some particular permissions int= o=20 > the database, but not the configuration, be able to run it to generate = a=20 > value? I concur with Quanah: I know many operational procedures where slappasswd= is just used to generate pre-hashed userPassword values. This usage is suppo= rted by DESCRIPTION in slappasswd(8). I also don't see a requirement for administrative access to slapd's config at all. Doesn't this ask for fully integrating SHA-2 password support into libraries/liblutil/passwd.c? Ciao, Michael. --------------ms010700080803040702000401 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFOzCC BTcwggMfoAMCAQICAwl4kDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEx MTcxNTQzMzFaFw0xMjExMTYxNTQzMzFaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggEAMIH9MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3Vy IG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNl cnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYB BAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkq hkiG9w0BAQUFAAOCAgEANPf/aLF41eQlvN5dEg3CFnlN//qQK7+EPIXLnHprNWLb4nBwgdPj /E+qa1umT7px4Py3VS0UTKqLmMdWftwid8MOMHWalZwrfx0Z8U3He+EdJhOSnn9vdd/ug7Xd dI/hRjLaBSq9ZhCczEUgL6vTxCYPlIoHF56y/oxSJw59vRBjvRFKXvpBZWseeRkcGACQduNH SNdWC1IqHAbQlgOS9VWQUYlm//BdaLkezRxqnQp5+KJMAcZzHpdNJ3G4SqCJ02Z3n4kk8IKZ AjgiWxisDFNsfXKDb9Ng5ntnnH2ouxrgPoNnW445tgkz50VKHstylx9s5O3G7uUTtg0J+z63 TA8xbN6kzRx7RgAUkEXhl6WEdW+3EVj5tYY38Uy8vleP+gYZfphKEmQJgIQqy9D2+gesbolT QdWYgbUYY2AHJOshskMW7pahYnFX2pZmn/ayaPc+JFJlCEqO0+DcYQjYuv6sntQgZGkok7yZ R4xMbyCp61pTrfGWOufZs/FiScJZg1IWY5qb4URH4VZZjLNMR2pFMRuE4LvgkkMRasbUv7Yv n3Lzv34lTfJKUqYW6nx//L2NS4rN63o0taPwRygnuBK4kp7EYEcwtLeanJhQoIu4b6If9rwy D7CFAp51wIewV9VtZ1Is0irNBcMVyhJogIcuIn+VWY1ff1RxySD/djMxggOUMIIDkAIBATCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcx IjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1 cHBvcnRAY2FjZXJ0Lm9yZwIDCXiQMAkGBSsOAwIaBQCgggHoMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDUyOTE2NDYzOFowIwYJKoZIhvcNAQkEMRYE FE1pvmOeFeNxFwX+H8VmVvMDK6OWMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE ggEAG+NichvhG0i4Tb18NExkCpBoGmzkaf3J/WSiwU5y01mEOEct8YvtixC3EdVlpVfKYOLb pKDGt2W6yNZySAEkQqZlWffWaYou3aJF5t/DjykuqpvBR0wNO1casY8OGAHMX1g0RicGIS12 30Ulk8vJTYQy3hMovlfztgHaEE7yI8Acem9ccJAuFoXbTCyDC47HcDf/pL4en6WGyMkyruhR 0vULseO+OUQ+LY+ic4C8qPXAtSnDrCPmUaOcns7Nz2cuZFgPe7dVt4NcXpsKXihy+PIag+Tz iiskIJ7u4iQaPFW2QBDZrmpa8UPCaWOy6KjtDDF8TNj5LwewODIJZ03kMAAAAAAAAA== --------------ms010700080803040702000401--

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs