Please find attached coolkey-1.0.1.ebuild, an ebuild for Fedora's CoolKey PKCS #11 module. With this module, PKCS#11 applications including Firefox and Thunderbird can use certificates stored on CoolKeys and US Department of Defense Common Access Cards for such things as web site access and email signing and encryption. I have tested the driver on x86 using an SCM 331 USB reader, Firefox 2.0.0.1-r2, nss-3.11.3, ccid-1.2.0, and pcsc-lite-1.3.3. The card and the certificates on it were recognized and I was able to access a site that requires a client certificate on the card. I think app-crpyt/coolkey is the appropriate location for it. The ebuild depends on app-crypt/ccid, all versions of which are currently marked testing. It also depends on sys-apps/pcsc-lite, the testing version is needed because of ccid dependencies. dev-libs/nss is also a dependency. Neither the Fedora CoolKey wiki nor the SRPM .spec file list any specific versions requirements for these dependencies. This ebuild uses coolkey-1.0.1-10, the version distributed with Fedora Core 6. There haven't been any updates to the FC6 package; the current version in Fedora's development repository ("Rawhide") is 1.0.1-15. This is my first ebuild, so if there are any problems or suggestions to make it better, please let me know and I'll be happy to update it.
Created attachment 107869 [details] coolkey-1.0.1.ebuild
Don't they have a source tarball? I wish to avoid using the rpm stuff...
Not that I could find, only CVS and the RPMs. And I didn't see any branches in CVS for release versions that we could use to build our own tarballs from the source (but they might have done something different like tagging or something; I'm not that familiar with CVS as I normally use Subversion). We could use rpm2targz to create a tarball from the RPM and put that on the Gentoo mirrors. Alternatively, I could get on the CoolKey mailing list and see if anyone knows of a tarball out there. I suppose dealing with RPMs is inevitable when dealing with Red Hat's stuff.
I assume you are using this package... So if you can, please contact them so they have pure source tarball... They are usually do release tarballs. Also I don't understand the nss and ccid dependencies... Can you please explain? And the following should be explained too... 1. Why does it install not only one PKCS#11 shared library... Currently it installs: /usr/lib/pkcs11/libcoolkeypk11.so /usr/lib/pkcs11/libcoolkeypk11.la /usr/lib/pkcs11/libcoolkeypk11.a While it actually needs only: /usr/lib/pkcs11/libcoolkeypk11.so Since nobody is going to static link with this library. It is not so important... 2. I would also ask why it installs the headers... I guess they should have split this package into two. One for the libckyapplet library with the include files etc... And other for the PKCS#11 which is dependent on the first.
Created attachment 107914 [details] coolkey-1.0.1.ebuild Modified version, please check.
I've used the package on Fedora and since it works well I thought it would be useful to have on Gentoo as well. ccid and nss dependencies come from the SRPM's .spec file. ccid provides the driver to interface with the card reader. I will try your ebuild tonight. I'm not certain where nss gets involved so it may not be needed, but I suspect it won't work without ccid. I don't know if this is something where there are other options that would work as well, I just know that CCID has worked for me. I suspect you're right about not needing the .la and .a files. It and the headers are probably options we can disable (or provide use flags for?) in the arguments to ./configure. The FC6 binary RPM only installs the .so. I'll contact the CoolKey people and see if I can get some resolution on your questions. I'll direct them to this bug report as well in case they're interested in providing direct input.
(In reply to comment #6) > I've used the package on Fedora and since it works well I thought it would be > useful to have on Gentoo as well. Oh... So you don't use Gentoo? :) > ccid and nss dependencies come from the SRPM's .spec file. ccid provides the > driver to interface with the card reader. No no no... they are totally wrong... The dependency is pcsc-lite... A software which work with pcsc-lite can access tokens at any reader... ccid is only one implementation of readers. There is never direct connection between the software and the reader driver. > I will try your ebuild tonight. Thanks! > I'm not certain where nss gets involved so it may not be needed I search for a dependency and not found one in configuration files. > but I suspect it won't work without ccid. Without a reader driver... If your reader is ccid, then of-course you need ccid to be instaled... > I suspect you're right about not needing the .la and .a files. It and the > headers are probably options we can disable (or provide use flags for?) > in the > arguments to ./configure. The FC6 binary RPM only installs the .so. Oh... So they need to fix their "make install"... But they never like to fix this... > I'll contact the CoolKey people and see if I can get some resolution on your > questions. I'll direct them to this bug report as well in case they're > interested in providing direct input. Thanks!
Created attachment 107937 [details] coolkey-1.0.1.ebuild Found NSS dependency! It is in a patch delivered in the rpm! I don't like PKCS#11 module for NSS, PKCS#11 should be a standard component for any PKCS#11 awared application... A correct implementation will work with OpenVPN, GnuPG, OpenSSH, QCA and more. NSS will also work with this standard implementation. I also don't like the automatic install into NSS... I patched it now so that it won't do it... I wish they add --disable-nss-install to configure to disable this behavior.
Created attachment 107968 [details] coolkey-1.0.1.ebuild I removed my coolkey install along with nss, pcsc-lite, and ccid and tried the ebuild from comment #8. It didn't work, configure failed because of the missing nss, so I added it back to DEPEND. The revised ebuild is attached. Build was successful, though I did have to reinstall ccid since my card reader uses it. Once that was done it all seemed to work, and I was able to use the smart card with Firefox. I sent an email bringing up your points to the coolkey list and included a link to this bug.
Created attachment 107976 [details] coolkey-1.0.1.ebuild Well... It is not needed... It cannot be needed... :) So I modified configure to ignore the absent of it... It is just NSS SHOULD NOT be a dependency for a PKCS#11 provider...
Created attachment 107977 [details] coolkey-1.0.1.ebuild Opps, reverse DEPEND/RDEPEND.
Created attachment 108078 [details] coolkey-1.0.1.ebuild Fedora at work, Gentoo and Mac OS X at home. :) Your revised ebuild did work for me, but I did have to re-emerge nss after emerging coolkey in order to test it since Firefox needs it. So I figured while I was at it, I might as well add nss as a use flag, and if someone wants coolkey to install itself into nss they can. Aren't choices the Gentoo way? Of course, if this isn't doing what I think it does, feel free to take it back out, since it did work fine when coolkey was emerged without nss installed. While I was at it, I also added a static use flag and when it's disabled, the .a doesn't get built. I heard back from the Coolkey-devel list. The guy from Red Hat thinks splitting out libckyapplet is overkill, since it is used by a total of two packages: coolkey and esc (a GUI program for managing smart cards, once this is in that was going to be my next project), but esc also needs libcoolkey anyway. The guy who packages CoolKey for Debian also responded, and he said he did split them for Debian, and also has a -dev package for the headers. Fedora also has a -devel package for the headers (which really are for libckyapplet). Since Gentoo is building from source, and other applications would need the headers to link to them (esc in the case of libckyapplet), isn't it appropriate to let the headers be installed? There is a CVS tag for the 1.0.1 release if we want to build our own tarball from that. It sounds like Debian picked a newer date and grabbed that from CVS in order to pick up some of the later patches. It sounds like there will be a new tag (release?) soon though. No pointers so far to an existing tarball floating around.
Comment on attachment 108078 [details] coolkey-1.0.1.ebuild I am sorry I am insisting... nss is a dependency of firefox.... $ equery depends nss [ Searching for packages depending on nss... ] www-client/mozilla-firefox-2.0.0.1 So it should have existed on your system. And the standart way to install a new security module (PKCS#11) into firefox is: 1. Edit->Preferences->Advanced->Encryption 2. Security devices->Load 3. Specify PKCS#11 shared library name. Please try... It just that when you are installing a PKCS#11 provider you don't like all users to automatically load this library, it may cause many problems. PKCS#11 provider should not install itself anyhow... This is highly none standard.
(In reply to comment #12) > Fedora at work, Gentoo and Mac OS X at home. :) Oh... :) > Your revised ebuild did work for me, but I did have to re-emerge nss after > emerging coolkey in order to test it since Firefox needs it. So I figured > while I was at it, I might as well add nss as a use flag, and if someone wants > coolkey to install itself into nss they can. Aren't choices the Gentoo way? Well... Yes... But it should be the choice of the user not the administrator... :) See comment#13 instructions. > While I was at it, I also added a static use flag and when it's disabled, the > .a doesn't get built. Hmmm... I prefer to solve this at automake level without static... I will look at it in weekend. > I heard back from the Coolkey-devel list. The guy from Red Hat thinks > splitting out libckyapplet is overkill, since it is used by a total of two > packages: coolkey and esc (a GUI program for managing smart cards, once this is > in that was going to be my next project), but esc also needs libcoolkey anyway. > The guy who packages CoolKey for Debian also responded, and he said he did > split them for Debian, and also has a -dev package for the headers. Fedora > also has a -devel package for the headers (which really are for libckyapplet). So I don't understand, will be tree tarballs? Or they just write their own spec in order to hack this? > Since Gentoo is building from source, and other applications would need the > headers to link to them (esc in the case of libckyapplet), isn't it appropriate > to let the headers be installed? Sure... We have no choice... But I thought more appropriate is to package the common library as a standalone library.... > new tag (release?) soon though. > No pointers so far to an existing tarball floating around. So we wait until the next version... :) Maybe it will be better.... I will try to contact them my-self. Thanks!
Created attachment 108135 [details] coolkey-1.0.1.ebuild (In reply to comment #13) > (From update of attachment 108078 [details] [edit]) > I am sorry I am insisting... > > nss is a dependency of firefox.... > $ equery depends nss > [ Searching for packages depending on nss... ] > www-client/mozilla-firefox-2.0.0.1 > > So it should have existed on your system. Yeah I think I figured that out later. Couldn't remember what was in place originally. > And the standart way to install a new security module (PKCS#11) into firefox > is: > 1. Edit->Preferences->Advanced->Encryption > 2. Security devices->Load > 3. Specify PKCS#11 shared library name. > > Please try... This is the way I've always done it. Never seen anything automatic work even on FC6, we've always had to configure Firefox manually as you state above. I'm attaching a revised (untested since I'm on Fedora right now, but I don't see why it wouldn't work) ebuild that takes the nss stuff back out, but still has the use flag to disable static build in case that route ends up working better. (In reply to comment #14) > So I don't understand, will be tree tarballs? Or they just write their own > spec in order to hack this? I'm not completely sure I understand what you're getting at here. The primary CoolKey developers work for Red Hat, so they're also the ones that prepare the Fedora RPMs. Debian doesn't use RPM, the guy packaging for them grabbed the source from CVS and packaged it the way he felt was appropriate. > Sure... We have no choice... But I thought more appropriate is to package the > common library as a standalone library.... I don't see why we can't do this. If we build our own tarball we can package the way we want, and if we continue to use the Fedora SRPM we might be able to do some tricks with configure to build just part of it, similar to how with the KDE split ebuilds, a bunch of ebuilds all build just a small piece out of the larger tarball. > So we wait until the next version... :) > Maybe it will be better.... > I will try to contact them my-self. Perhaps that's best, I'm sure something is getting lost having me as a go between. The more routers a packet hops through, the greater the chance of something getting lost, or something like that... ;) As far as waiting for the next release, you never know what people's definition of "soon" is...
Can you please explain again why you added the static USE flag?
The static use flag controls the generation of the static versions of the libcoolkey and libckyapplet libraries. If someone has configured their system to build statically linked binaries, they'll need them to build any applications that build against libcoolkey or libckyapplet (such as esc). Most people probably don't have the static use flag set, so they won't get them. If the use flag is set, --enable-static gets passed to configure, otherwise --disable-static is passed. --enable-static seems to be the default. I just tried building from source a CVS checkout of coolkey on Fedora Core 5 and --enable-static was the default.
The static use flag for Gentoo is mainly for executables which should not dynamicly load other libraries. The fact that the shared and static versions of a library are installed is fine... Except for the PKCS#11 modules, which should be fixed in the automake Makefile. So I will not add this one...
Sounds reasonable to me.
Well... Send some patches to upstram, got some response but no confirmation to anything... We will wait for the next version...
Created attachment 110518 [details] coolkey-1.1.0.ebuild Upstream posted version 1.1.0 yesterday, with a source tarball. :) Basing off your last version, I've updated for the ebuild to use the new version. It builds and can be installed in Firefox and Seamonkey fine, but I won't be able to test with a smart card until Tuesday night. But I thought I'd post it now so you can take a look at it if you want. I noticed when checking ./configure --help that there was an option to enable/disable debugging code, so I added a "debug" use flag to provide users that option. I was also able to remove the NSS_LIBS and NSS_CFLAGS bit from the econf call. I tried unmerging nss and then emerging coolkey and it built without errors.
updating package version in summary
Well... They did not separate the package... Did not fixed the license... (Although I sent them a patch for this too). But it is merges cleanly now... :) Added, thanks!
I think the license is OK. If I understood Bob Relyea's post correctly, he is using Mozilla's version of the RSA security files. Mozilla was able to get it licensed under the Mozilla Tri-License, meaning they can use it under MPL, GPL, or LGPL. Coolkey chooses to use it under LGPL.
No... They got it wrong. They are using RSA Security copyright files. And not follow the requirements... Mozilla has the same issue. But it is not our problem...
I think that's the bit you're missing. RSA Security normally releases their files under their own license. But Mozilla was able to get the files licensed under Mozilla tri-license (MPL/GPL/LGPL) to them, and under those licenses they can redistribute however they want. Copy & paste from his post: > Actually I'm using Mozilla versions of these files. Mozilla went through the > work to get these from RSA under the tri-License.
Please look at mozilla sources. Have a look at the license: ./security/nss/lib/softoken/pkcs11.h ./security/nss/lib/softoken/pkcs11f.h ./security/nss/lib/softoken/pkcs11t.h And you will see that coolkey simply removed the RSA Security license.
Well, like you said... not our problem. But anyway, I just tested it with Firefox and a smart card and was able to connect to a web site that required it. So it works.
