Full_Name: Jan Vcelak Version: git master OS: Linux URL: ftp://ftp.openldap.org/incoming/jvcelak-20120914-moznss-ignore-certdb-sql-prefix-when-checking-existence.patch Submission from: (NULL) (209.132.186.34) Mozilla NSS certificate database in newer SQL format could not be used with OpenLDAP, because the 'sql:' prefix is not removed while checking for the existence of the directory. The attached patch resolves this problem. Steps to reproduce are described in Red Hat bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=857373 The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Jan Vcelak am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.
jvcelak@redhat.com wrote: > Full_Name: Jan Vcelak > Version: git master > OS: Linux > URL: ftp://ftp.openldap.org/incoming/jvcelak-20120914-moznss-ignore-certdb-sql-prefix-when-checking-existence.patch > Submission from: (NULL) (209.132.186.34) > > > Mozilla NSS certificate database in newer SQL format could not be used with > OpenLDAP, because the 'sql:' prefix is not removed while checking for the > existence of the directory. > > The attached patch resolves this problem. The patch looks syntactically correct. But SQL, seriously? As if TLS handshakes weren't slow enough already, you want to slow them down even further by looking up certs in an SQL database? Aside from questioning the wisdom of such an inefficient approach, there are other philosophical problems with this patch. It seems to be just the latest in a continuing stream of one-off patches. Are we going to get yet another special case patch from you guys when some other new certDB type comes along? This approach is unmaintainable and does nothing to inspire confidence in the quality of thinking going into this code. You're working on a security library. We expect a lot better thought to go into these things. > Steps to reproduce are described in Red Hat bugzilla: > https://bugzilla.redhat.com/show_bug.cgi?id=857373 > > > The attached file is derived from OpenLDAP Software. All of the modifications to > OpenLDAP Software represented in the following patch(es) were developed by Red > Hat. Red Hat has not assigned rights and/or interest in this work to any party. > I, Jan Vcelak am authorized by Red Hat, my employer, to release this work under > the following terms. > > Red Hat hereby place the following modifications to OpenLDAP Software (and only > these modifications) into the public domain. Hence, these modifications may be > freely used and/or redistributed for any purpose with or without attribution > and/or other notice. > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Hello Howard, > The patch looks syntactically correct. But SQL, seriously? As if TLS > handshakes weren't slow enough already, you want to slow them down > even > further by looking up certs in an SQL database? this is nothing new. Mozilla NSS supports SQL backend (SQLite) for storing certificates since 3.12 (== Firefox 3) I think. The reason, why the new format was introduced is mainly because of problems with accesing the database from multiple processes. It is described on the following page in a great detail: https://wiki.mozilla.org/NSS_Shared_DB I can't tell anything about the performance because I haven't tried. > Aside from questioning the wisdom of such an inefficient approach, > there are > other philosophical problems with this patch. It seems to be just the > latest > in a continuing stream of one-off patches. Are we going to get yet > another > special case patch from you guys when some other new certDB type > comes along? One Fedora user e-mailed me recently and wanted my help with setting the OpenLDAP server to use the database in "new" sql format. This patch is the result. I do not think that any other backend except the legacy and this one is supported. Otherwise, I would write the patch more generally. I will check with MozNSS people and let you know. > This approach is unmaintainable and does nothing to inspire > confidence in the > quality of thinking going into this code. > > You're working on a security library. We expect a lot better thought > to go > into these things. I fully understand and expect that you will have some feedback on our patches - which is happening right now. MozNSS crypto backend works quite fine, but there are still some problems in certain corner situations. The backend is not as mature as OpenSSL one. I'm really trying to fix them all and to make OpenLDAP a better piece of software. Jan
Hello, > I do not think that any other backend except the legacy and this one > is supported. Otherwise, I would write the patch more generally. I will > check with MozNSS people and let you know. Not sure if more types are supported, but at least sql: and dbm: (default) types work. I have uploaded an updated patch. Please, drop the old one. Jan ftp://ftp.openldap.org/incoming/jvcelak-20120920-moznss-ignore-certdb-type- prefix.patch The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Jan Vcelak am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.
moved from Incoming to Software Enhancements
MozNSS deprecated