From nkinder at redhat.com Tue Aug 5 18:33:09 2008 From: nkinder at redhat.com (Nathan Kinder) Date: Tue, 05 Aug 2008 11:33:09 -0700 Subject: [Fedora-directory-devel] Please Review: (457951) Range search shouldn't be used when a DNA prefix is set Message-ID: <48989CE5.5010304@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=457951 Resolves: bug 457951 Bug Description: The DNA plug-in uses a range search internally to locate the next free value within the managed range. This works fine when the values are strictly integers, but the DNA plug-in supports a prefix to the integer portion of the value (such as "user1 - user1000"). Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: When a prefix is defined, we should not use a range search to locate the next free value. We should simply do an exact match search to see if the next value in the cached configuration entry is free. If it is not free, we iterate through each value in the range until we either find a free value, or hit the end of the range. This will typically perform fine, as the next value in the configuration entry should be free unless someone manually assigned it. The worst case scenario is that we have to go through a large block of values that was manually assigned, which will be helped by an equality index. Even so, this case should be rare. For efficiency in the case that we have to go through a large block of manually assigned values, I wanted to reuse a previously allocated pblock instead of allocating one for each search. This required me to export a new public SLAPI function that re-initializes a pblock so it can be reused. Platforms tested: Fedora 8 x86_64 Flag Day: no Doc impact: Yes. We need to doc the new slapi_pblock_init() function in the plug-in guide. https://bugzilla.redhat.com/attachment.cgi?id=313468&action=diff -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3254 bytes Desc: S/MIME Cryptographic Signature URL: From nkinder at redhat.com Wed Aug 6 18:01:13 2008 From: nkinder at redhat.com (Nathan Kinder) Date: Wed, 06 Aug 2008 11:01:13 -0700 Subject: [Fedora-directory-devel] Please Review: (458135) Sort control message should not be logged for internal operations Message-ID: <4899E6E9.4040101@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=458135 esolves: bug 458135 Bug Description: The backend plug-in currently attempts to log a message whenever it is processing a sort control as part of a search operation. For an internal operation, this causes an error to be logged since the connection ID is not set for an internal operation, but the access log needs it for the log message. When using the DNA plug-in, you will see lots of these messages since it does an internal sorted search. We should not attempt to log anything related to the sort control in the access log for internal operations. Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: Simply check if the operation is an internal operation before attempting to log the SORT message to the access log. Platforms tested: Fedora 8 x86_64 Flag Day: no Doc impact: no https://bugzilla.redhat.com/attachment.cgi?id=313597&action=diff -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3254 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Fri Aug 8 23:39:20 2008 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 08 Aug 2008 17:39:20 -0600 Subject: [Fedora-directory-devel] Please review: Bug 457156 - GER: allow GER for non-existing entries (phase 2) Message-ID: <489CD928.1080105@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=457156 Resolves: bug 457156 Bug Description: GER: allow GER for non-existing entries (phase 2) Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: There are a couple of memory leaks in the code. acleffectiverights.c line 617 calls slapi_attr_get_valueset to get the list of objectclass values in objclassvals - this function allocates memory (returns a dup of the list) but this is not freed. The fix is to call slapi_valueset_free() to free it. The allattrs and opattrs arrays are not freed in all conditions. The fix is to make sure they are freed in all conditions. Platforms tested: RHEL5, Fedora 8 Flag Day: no Doc impact: no https://bugzilla.redhat.com/attachment.cgi?id=313854&action=diff From aj at dungeon.inka.de Wed Aug 27 07:03:25 2008 From: aj at dungeon.inka.de (Andreas Jellinghaus) Date: Wed, 27 Aug 2008 09:03:25 +0200 Subject: [Fedora-directory-devel] coolkey information and license Message-ID: <200808270903.25386.aj@dungeon.inka.de> Hi, first some question about coolkey: is the windows CSP coolkey specific, or is it (as it looks from many miles away) a generic CSP to PKCS#11 bridge? the csp code mentions Identity alliance all over the place - is this the ID Ally CSP now open sourced? (it worked always fine for me, so an open source release labed as coolkey would be great). The fedora directory server wiki page on coolkey doesn't have too many details on what each component exactly does / how it is implemented. For example: - the windows CSP: generic or tied to the coolkey pkcs#11 module? - the java card applet: generic or only working on cyberflex cards? how is it uploaded? with gpshell? maybe include instructions for doing this, or refer to some tutorial? - the java card applet: what API does it implement? I guess not a filesystem with pkcs#15 structures, but some proprietory simple api? - is the source code of the java card applet open source too? where can people find it? - how is the card managed with this applet? e.g. does it implement a single user or a security officer plus normal user combo? or is it flexible to do both? - the windows makefile: what build environment for windows does it expect? (oops, found the wiki page with the windows build instructions, thanks, solved) - what is the job of the "cspres.dll"? - what is the job of th "regcerts.exe"? when/how does a user need to start it? - does the pk11install.c work with all versions of mozilla firefox, thunderbird and netscape? if so, it would be very interesting for other projects with pkcs#11 modules too. what does it exactly? (modify config file? databases? ...) is it important to have firefox etc. running? or to have it not running? etc. - the ChangeLog file is mentioned in the spec file - thus I guess it gets included in the rpm? this is not needed (the file is empty) - the coolkey.spec sets the license to LGPL which is not 100% correct (see below) - the coolkey.spec file uses "PKCS#11" without mentioning "RSA Security Inc. Public-Key Cryptography Standards (PKCS)" which could be a license violation (see below) - the pkcs11.h file has a different license clause than the usual file. I wonder where you got this, did RSA ever released a file with the spelling error "In.c"? last the license: some web sites assume the software is LGPL. but the PKCS#11 header files used - even the copy from mozilla source - is not, it includes the RSA disclaimour, which is similar to the BSD advertising clause, but worse because of its very vague formulation ("all material" etc.). Scute has a PKCS#11 header file written from scratch by using public information thus not tainted by any RSA license. opensc and a number of other open source projects switched to using this header file (released as public domain). maybe this is a viable solution for coolkey too? (same pkcs#11 header files in coolkey and the windows/csp directory.) Regards, Andreas From rmeggins at redhat.com Wed Aug 27 17:34:23 2008 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 27 Aug 2008 11:34:23 -0600 Subject: [Fedora-directory-devel] coolkey information and license In-Reply-To: <200808270903.25386.aj@dungeon.inka.de> References: <200808270903.25386.aj@dungeon.inka.de> Message-ID: <48B5901F.8020607@redhat.com> Here are the answers from one of the coolkey developers ... followups to coolkey-devel at redhat.com > > ------------------------------------------------------------------------ > > Subject: > [Fedora-directory-devel] coolkey information and license > From: > Andreas Jellinghaus > Date: > Wed, 27 Aug 2008 09:03:25 +0200 > To: > fedora-directory-devel at redhat.com > > To: > fedora-directory-devel at redhat.com > > > Hi, > > first some question about coolkey: > is the windows CSP coolkey specific, or is it (as it looks from many miles away) a generic CSP to PKCS#11 bridge? > It's a geneeric PKCS #11 bridge. > the csp code mentions Identity alliance all over the place - is this the > ID Ally CSP now open sourced? (it worked always fine for me, so an > open source release labed as coolkey would be great). > yes, we got permission from ID Ally to release it under GPL. > The fedora directory server wiki page on coolkey doesn't have too many > details on what each component exactly does / how it is implemented. > > For example: > - the windows CSP: generic or tied to the coolkey pkcs#11 module? > Generic. > - the java card applet: generic or only working on cyberflex cards? > how is it uploaded? with gpshell? maybe include instructions for > doing this, or refer to some tutorial? > Tied to javacard/global platform, however your mileage may vary. I number of cards we tested all required tweaks to the applet to get working. > - the java card applet: what API does it implement? I guess not a > filesystem with pkcs#15 structures, but some proprietory simple api? > No it's not a filesystem card, it's a java card. It's currently a modified muscle API. We'd love to add PIV and CAC as interfaces as well. > - is the source code of the java card applet open source too? where > can people find it? > yes, it's there on the website: CVSROOT=:pserver:anonymous at cvs.fedora.redhat.com:/cvs/dirsec ; export CVSROOT cvs login cvs checkout coolkey/applet Build instructions are at: http://directory.fedoraproject.org/wiki/BuildCoolKeyApplet . > - how is the card managed with this applet? e.g. does it implement > a single user or a security officer plus normal user combo? > or is it flexible to do both? > Neither. It's currently managed by a back end TPS system. We would like to add user managed as well. The system that manages it is available at dogtag (http://pki.fedoraproject.org/wiki/PKI_Main_Page). The relevant subsystems are TPS and TKS. Stand alone versions of those would be an excellent addition (so much work, so little time). > - the windows makefile: what build environment for windows does it > expect? (oops, found the wiki page with the windows build instructions, > thanks, solved) > - what is the job of the "cspres.dll"? > - what is the job of th "regcerts.exe"? when/how does a user need to > start it? > - does the pk11install.c work with all versions of mozilla firefox, > thunderbird and netscape? if so, it would be very interesting for > other projects with pkcs#11 modules too. what does it exactly? > (modify config file? databases? ...) is it important to have firefox etc. > running? or to have it not running? etc. > all current versions, as well as older mozilla and seamonkey. Longer term we are looking at shared database as a better solution. > - the ChangeLog file is mentioned in the spec file - thus I guess it gets > included in the rpm? this is not needed (the file is empty) > - the coolkey.spec sets the license to LGPL which is not 100% correct > (see below) > - the coolkey.spec file uses "PKCS#11" without mentioning "RSA Security Inc. Public-Key Cryptography Standards (PKCS)" > which could be a license violation (see below) > - the pkcs11.h file has a different license clause than the usual file. > I wonder where you got this, did RSA ever released a file with the > spelling error "In.c"? > > last the license: some web sites assume the software is LGPL. but the > PKCS#11 header files used - even the copy from mozilla source - is > not, it includes the RSA disclaimour, which is similar to the BSD advertising > clause, but worse because of its very vague formulation ("all material" etc.). > > Scute has a PKCS#11 header file written from scratch by using public information thus not tainted by any RSA license. opensc and a number > of other open source projects switched to using this header file (released > as public domain). maybe this is a viable solution for coolkey too? > I believe Mozilla cleared the Mozila copies with RSA for distribution under the GPL, LGPL, and the MPL. Coolkey's copies come directly from Mozilla. 'Scratch rewrites' still technically have a problem in that they are still derived from the PKCS #11 spec which as the same license clause. BTW in PKCS #11 v2.3 RSA is removing offending clause! This should free up all the various copies floating around. bob > (same pkcs#11 header files in coolkey and the windows/csp directory.) > yes, we prefer the Mozilla versions since we know we have clearance for GPL, LGPL, and MPL. > Regards, Andreas > > -- > Fedora-directory-devel mailing list > Fedora-directory-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Wed Aug 27 20:59:50 2008 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 27 Aug 2008 14:59:50 -0600 Subject: [Fedora-directory-devel] Please review: Bug 457846 - (winsyncapi) The Windows Sync API should have plug-in points Message-ID: <48B5C046.2010602@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=457846 Resolves: bug 457846 Bug Description: The Windows Sync API should have plug-in points Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: This is a follow up to the original fix for this bug. Some additional changes to the api 1) added plugin points for begin update, end update, and agreement destruction 2) added debugging code to allow a regular DS to stand in for AD 3) fixed a couple of minor memory leaks 4) added the rest of the SLAPI DSE code to the public API to allow plugins to do dynamic configuration using the SLAPI public API Platforms tested: RHEL5 Flag Day: no Doc impact: yes - plugin guide https://bugzilla.redhat.com/attachment.cgi?id=315142&action=diff From rmeggins at redhat.com Wed Aug 27 21:31:10 2008 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 27 Aug 2008 15:31:10 -0600 Subject: [Fedora-directory-devel] Please review: Bug 460381 - various valgrind reported startup memory leaks Message-ID: <48B5C79E.1030000@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=460381 Resolves: bug 460381 Bug Description: various valgrind reported startup memory leaks Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: These memory leaks are not serious, but they do create a lot of noise in valgrind. Platforms tested: RHEL5, Fedora 8 Flag Day: no Doc impact: no https://bugzilla.redhat.com/attachment.cgi?id=315152&action=diff From rmeggins at redhat.com Fri Aug 29 01:42:58 2008 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 28 Aug 2008 19:42:58 -0600 Subject: [Fedora-directory-devel] Please review: Bug 451702 - Admin Server fails on F9 due to NSS 3.12 libs moved to /lib Message-ID: <48B75422.4070402@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=451702 Resolves: bug 451702 Bug Description: Admin Server fails on F9 due to NSS 3.12 libs moved to /lib Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: The problem is that nss-devel puts libssl3.so in libdir at build time, but at runtime there is only nss which now uses /lib|/lib64. So the build time nsslibdir is not the same as the runtime nsslibdir. It looks as though the preload of ssl3 is not needed with f9 and/or nss 3.12. So we just look for libssl3.so in the $libdir, if not found, we just skip it, and assume it's nss 3.12 and/or f9 and it is not needed. Platforms tested: Fedora 8, Fedora 9 Flag Day: no Doc impact: no https://bugzilla.redhat.com/attachment.cgi?id=315317&action=diff From nkinder at redhat.com Fri Aug 29 01:49:28 2008 From: nkinder at redhat.com (Nathan Kinder) Date: Thu, 28 Aug 2008 18:49:28 -0700 Subject: [Fedora-directory-devel] Please review: Bug 451702 - Admin Server fails on F9 due to NSS 3.12 libs moved to /lib In-Reply-To: <48B75422.4070402@redhat.com> References: <48B75422.4070402@redhat.com> Message-ID: <48B755A8.6000002@redhat.com> The attachment to the bug is bad. Could you re-attach the diffs? Rich Megginson wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=451702 > Resolves: bug 451702 > Bug Description: Admin Server fails on F9 due to NSS 3.12 libs moved > to /lib > Reviewed by: ??? > Files: see diff > Branch: HEAD > Fix Description: The problem is that nss-devel puts libssl3.so in > libdir at build time, but at runtime there is only nss which now uses > /lib|/lib64. So the build time nsslibdir is not the same as the > runtime nsslibdir. It looks as though the preload of ssl3 is not > needed with f9 and/or nss 3.12. So we just look for libssl3.so in the > $libdir, if not found, we just skip it, and assume it's nss 3.12 > and/or f9 and it is not needed. > Platforms tested: Fedora 8, Fedora 9 > Flag Day: no > Doc impact: no > https://bugzilla.redhat.com/attachment.cgi?id=315317&action=diff > > -- > Fedora-directory-devel mailing list > Fedora-directory-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3254 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Fri Aug 29 01:58:58 2008 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 28 Aug 2008 19:58:58 -0600 Subject: [Fedora-directory-devel] Please review: Bug 451702 - Admin Server fails on F9 due to NSS 3.12 libs moved to /lib In-Reply-To: <48B755A8.6000002@redhat.com> References: <48B75422.4070402@redhat.com> <48B755A8.6000002@redhat.com> Message-ID: <48B757E2.2020304@redhat.com> Nathan Kinder wrote: > The attachment to the bug is bad. Could you re-attach the diffs? Sorry about that. Here are the real diffs https://bugzilla.redhat.com/attachment.cgi?id=315318&action=diff > > Rich Megginson wrote: >> https://bugzilla.redhat.com/show_bug.cgi?id=451702 >> Resolves: bug 451702 >> Bug Description: Admin Server fails on F9 due to NSS 3.12 libs moved >> to /lib >> Reviewed by: ??? >> Files: see diff >> Branch: HEAD >> Fix Description: The problem is that nss-devel puts libssl3.so in >> libdir at build time, but at runtime there is only nss which now uses >> /lib|/lib64. So the build time nsslibdir is not the same as the >> runtime nsslibdir. It looks as though the preload of ssl3 is not >> needed with f9 and/or nss 3.12. So we just look for libssl3.so in >> the $libdir, if not found, we just skip it, and assume it's nss 3.12 >> and/or f9 and it is not needed. >> Platforms tested: Fedora 8, Fedora 9 >> Flag Day: no >> Doc impact: no >> https://bugzilla.redhat.com/attachment.cgi?id=315317&action=diff >> >> -- >> Fedora-directory-devel mailing list >> Fedora-directory-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-devel > > ------------------------------------------------------------------------ > > -- > Fedora-directory-devel mailing list > Fedora-directory-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: