[Fedora-directory-devel] coolkey information and license
by Andreas Jellinghaus
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
15 years, 3 months
[Fedora-directory-devel] Please Review: (457951) Range search shouldn't be used when a DNA prefix is set
by Nathan Kinder
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
15 years, 4 months