--- Begin Message ---
Thanks again. ;)
I appreciate the troubleshooting advice. -lpcsclite does indeed reside
in /usr/local/lib on FreeBSD.
I also had to do the trick re -ldl when I built libmusclecard from
source, and (with the exception of its fragility when it came to
Firefox) I was able to read my CAC using Apple's CACPlugin. My guess is
that the issue with configure looking for libdl on FreeBSD is not what's
causing the instability with coolkey, but I can't rule it out either.
Unfortunately, my laptop has taken a hardware-related dive, so I don't
know when I'll have the opportunity to debug coolkey on FreeBSD. I'll be
back from TDY in a little over a week and will have my OS X machine, but
that doesn't really help me figure out what's wrong with coolkey on FreeBSD.
If I can keep the laptop up long enough to build pam_pkcs11 and/or NSS's
pk11util tool as per Mr. Relyea's suggestion, I'll do what I can to
pinpoint the problem (or if nothing else post my log files minus my
PIN). I'd like to figure out the problem for the next person who wants
to use a CAC with FreeBSD. :)
I installed coolkey in /usr/opt because, like libmusclecard, it is not
in the FreeBSD Ports Collection and I don't like installing manually
compiled packages in /usr/local (the default location for packages
installed through Ports) in case I or the package does something naughty.
Thank you again for your help! That goes to Mr. Relyea as well!
V/r,
Kevin Reinholz
Todd Denniston wrote:
Kevin Reinholz wrote, On 12/02/2007 11:29 AM:
Ladies and Gentlemen,
Hello, again. :)
I am trying to build coolkey-1.1.0 on FreeBSD 7.0-beta2.
After extracting the coolkey source tarball, I built coolkey with the
following steps:
vi configure
:%s/-ldl/-lc/g
(This step was necessary because unlike Linux, FreeBSD's libc
contains the functionality found in libdl on Linux, so there is no
libdl on FreeBSD. I'm sure there's a more elegant way to accomplish
this but this is how I did it).
I would suspect gcc/ld is smart enough to not link libc in twice, but
I would (out of paranoia) just delete, or replace with spaces, "-ldl"
from where it was found in configure instead of replacing with "-lc".
Also does ld need to be called with -export-dynamic as per the freebsd
manpage for dynamic linking, or is it being called that way by gcc/make?
http://www.freebsd.org/cgi/man.cgi?query=dlopen&apropos=0&sektion=0&manpath=FreeBSD+6.2-RELEASE&format=html
This defiantly seems like a place where automake is not handling the
deltas between Linux, Solaris and FreeBSD correctly, or that the
CoolKey folks have not called the right thing in the configure.in to
get or not get libdl as needed.
env CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib
PCSC_CFLAGS=-I/usr/local/include/PCSC PCSC_LIBS=-L/usr/local/lib
NSS_CFLAGS=-I/usr/local/include/nss/nss NSS_LIBS=-L/usr/local/lib/nss
./configure --prefix=/usr/opt
gmake
gmake install
I should note that PCSC (installed through Ports) is apparently
functioning properly and that the light on my SCM 331 smart card
reader blinks when I insert my CAC. I successfully built
commonAccessCard.bundle using Apple's CACPlugin and the muscle
framework and using that am able to view the certificates on my CAC,
so the problem does not seem to lie with my hardware or PCSC.
Unfortunately, commonAccessCard.bundle has its share of problems and
after choosing a certificate and entering my PIN at AF Portal or
other secure DoD sites, I receive an NSS error. (Error code -12222).
Inquiries on the MUSCLE mailing list led to the conclusion that
commonAccessCard.bundle is unstable and coolkey the better solution
for CAC access on Mozilla products.
When I try to add libcoolkeypk11.so as a Security Module in Firefox,
the dinosaur segfaults without an error message. (Exit code 139).
two suggestions for attempting to narrow down the problems.
1) "set COOL_KEY_LOG_FILE in the environment to point somewhere, and
the [coolkey] module will dutifully log what it's doing" from "Timothy
J. Miller" <tmiller@xxxxxxxxx>.
2) if you have not already, try getting pam_pkcs11 compiled and
installed.
You don't have to configure pam to use it, but you need to configure
pam_pkcs11 a little (get certificate authorities installed, point it
to coolkey and set debug flags), and then you can use pkcs11_inspect
to see if coolkey and the pam_pkcs11 code can get data from the card
through pcscd and coolkey.
Do be aware that in DEBUG mode pkcs11_inspect echo's back your pin in
clear text (take appropriate precautions, when doing it and when
sending logs).
An ldd of libcoolkeypk11.so reveals:
/usr/opt/lib/pkcs11/libcoolkeypk11.so:
libckyapplet.so.1 => /usr/opt/lib/libckyapplet.so.1 (0x281a6000)
libz.so.4 => /lib/libz.so.4 (0x281b1000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x28300000)
libm.so.5 => /lib/libm.so.5 (0x281c3000)
libc.so.7 => /lib/libc.so.7 (0x28089000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x281d8000)
An ldd of libckyapplet.so.1 reveals:
/usr/opt/lib/libckyapplet.so.1:
libz.so.4 => /lib/libz.so.4 (0x28190000)
libc.so.7 => /lib/libc.so.7 (0x28089000)
Should either of these coolkey shared objects be explicitly linked to
libpcsclite.so.1?
modulus the stuff I am sure is Linux specific and libdl.so (and that
your's is in /usr/opt/ vice /usr/local/ ), your ldd's are the same as
mine.
coolkey's src/install/Makefile reveals that it correctly recognizes
SCARD_LIB_NAME = libpcsclite.so.1 which it is looking for in
PCSC_LIBS = -L/usr/local/lib.
is /usr/local/something where your libpcsclite.so.1 resides?
If not you may need to make coolkey configure believe that
libpcsclite.so.1 exists in the place where it is installed on your
machine.
Has anyone successfully tested coolkey on a *BSD system? Building it
on FreeBSD is easy enough.
Loading it as a security module in Firefox is not.
V/r,
Kevin Reinholz
--- End Message ---
_______________________________________________
Coolkey-devel mailing list
Coolkey-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/coolkey-devel
