On Jul 3, 2008, at 2:39 AM, Ludovic Rousseau wrote:
Hello Paul,
I just tried to compile the Solaris branch of pcsc-lite.
On Fri, Jun 13, 2008 at 12:01 AM, Paul Klissner
Recently Ludovic created a branch in the repository in which to
place a new version of PC/SC-Lite (spun off of PC/SC-Lite 1.3.2),
which I've been working on for the past year or so, adapting it
for increased scalability and security, as previously discussed
on this mail list.
The overarching objective was to make PC/SC-Lite adaptable to more
kinds of environments. My specific task was to ensure that these new
abstractions would be compatible with Solaris Trusted Extensions,
and with the Sun Ray thin client platform. Over the course of
development, the design evolved from the proposal initially posted
to this list. However, it works now and is being used in production.
This code has had exposure, use and feedback from customers,
including some larger installations, and has undergone some quality
assurance testing. Thus the new code has been proven viable.
The new implementation has been checked-in into the following
branch and can be browsed and diff'd online:
http://svn.debian.org/viewsvn/pcsclite/branches/Solaris/
Documentation for this branch is provided in these files:
SECURITY_SCALABILITY_ENHANCEMENTS.pdf Design document
README.build Build instructions
BUGS.txt Issues/TO DO
WHAT THIS BRANCH DELIVERS:
This workspace currently constructs a Solaris 10 compatible package
"SolarisPCSC" for SPARC and i386. That package installs the new
PC/SC-lite framework, providing basic components and infrastructure
to support using Smart Card readers associated with local consoles
(X-Windows) on a UNIX-like system. It can be extended for other
environments by providing additional configuration files and
plugins.
A package called "SUNWpcscdtu", soon to be on Sun's download center,
contains plugins for SolarisPCSC, provisioning PC/SC-Lite to work
with Sun Ray thin clients, specifically to use smart card readers
internal to Sun Ray desktop units, as well as USB readers connected
to them upon installation of the CCID IFD handler.
The SUNWpcscdtu package compliments the SUNWpcsc package, which is
currently identical to SolarisPCSC. SUNWpcsc will be posted at
Sun's download center, though ultimately we'd rather be working
from the open source distribution of PC/SC-Lite; therefore, it is
my hope that ultimately these architectural changes will be merged
into the trunk to meet the community goals and the needs of users.
BACKGROUND:
This implementation was designed modularly, with platform neutrality
a primary goal. It was designed to be as flexible and extensible as
could be managed, including providing a new plugin interface for
user and resource validation and authentication, as well as offering
an extensible command-line interface providing backward-compatible
modes as well as new operational modes, such as a launcher/instance
model.
Along the way, a few bugs in in 1.3.2 were found and fixed. These
were discovered by scaling PC/SC-lite for multi-user use and stress
testing under a somewhat rigorous test matrix. Some of these bugs,
previously reported to the mail list may have already been fixed
in 1.4.x. The ones that come to mind are a very elusive memory
leak, a race condition, a minor incompatibility of SCardStatus()
to the PC/SC spec, and also the way status bits are set in
SCardGetStatus().
Do you have a more detailed description of the bugs you corrected?
I'll have to search e-mails and jog my memory.
I know at least two of them (not the SCardStatus one) were
very difficult to find, and only exposed themselves under
high activity and scaling of the infrastructure.
To help people diagnose issues with PC/SC-Lite, a set of tools
will be posted this month on Sun's software download center
along side the PC/SC-Lite "1.1" distribution. Among these is a tool
that interposes between a client and libpcsclite.so and dereferences
arguments and formats and logs transactions. Another utility allows
a reader list to be pruned to nudge client applications to select
the proper reader among a plurality, and yet another provides a
means to externally induce a regression in SCardStatus() that at
least one 3rd party middleware product actually required at one
point to function properly.
Are these tools under a free software licence? I think they could be
used on non Solaris systems.
I do not use the "Sun's software download center". Do you have an URL?
Let me figure out what I can do to make these available. One of the
tools in that set that I didn't make public is a stress test suite that
uses plugins. I'll get back to you soon with info about that.
Apparently the search engine indexing isn't set up properly yet for
the new release, so I'll have to contact the people that handle that
so that the download page comes right up, and then give you a URL.
I also need to see if we have or can get a license to release
the tools to the Open Source community.
NOTES ON MERGING WITH TRUNK:
Given deadline pressure and scope of the effort, Solaris-specific
code crept in. I suspect a few system calls weren't wrapped in
platform-independent abstractions in the manner set forth in 1.3.2,
but some are. It shouldn't take too much work to clean that up.
I attach a patch to make the software compile under Debian GNU/Linux.
I can't link so I can't run it.
I'll have to check that out!
I was trying to make it build on Linux a couple of weeks ago too.
And the first big problem I ran into is that xdm is required
the way it works now because there is a dependency on the XServers
file. But since different systems use different display managers
this might require some sort of plugin scheme to abstract it.
Comments:
- use #include <stdarg.h> instead of #include <sys/varargs.h>
- #include <sys/param.h> to have MAXPATHLEN defined.
I don't know if using MAXPATHLEN is a good idea. It is a problem under
Hurd for example. See
http://www.debian.org/ports/hurd/hurd-devel-debian.html
- BUILD is not defined anywhere
- ucred.h, synch.h, sys/conf.h, sys/filio.h do not exist on GNU/Linux
- PATH_MAX is redifined in src/auth.c
- macro NONULL() is defined in pcscdaemon.h and also in many .c files
That's a macro I added, right?
Are you saying it should exist, or that it should go elsewhere?
- RTLD_PARENT does not exist for GNU/Linux dlopen()
There was some issue on Solaris that caused me to have
to add that flag. Maybe the default behavior on Linux is
different such that it wouldn't be required. I don't recall
what the issue was. I'll have to take some time to re-examine that.
- the mutex type is pthread_mutex_t not mutex_t
- use uint32_t instead of uint_t
- gethrtime() is not available
- use SYS_ThreadSelf() instead of thr_self(). And use
SYS_ThreadEqual() to compare two thread ids.
Thanks. Those are the kinds of things I anticipated
having to go back and clean up. I knew about some of them.
The ucred thing is going to require more than just a simple substitution
because the mechanism for getting peer credentials is different on
Linux, BSD, etc...
There's also a dependency on SMF to launch the daemons
that needs to be abstracted out so that another scheme is
used on non-Solaris systems
Beyond ensuring backward-compatibility (autoconf build modes and
daemon run modes), and tidying up platform-independent abstractions,
I expect that merging the new code with the scores of open source
changes made between 1.3.2 and 1.4.x will be the brunt of the
unification effort, because there are significant architectural
changes in this branch that involve several new source files as well
as substantial changes to existing source files. Still, I believe the
benefit outweighs the burden.
I also think it a good idea to merge the two branches. But I don't
know how we should do.
That's great Ludovic. Really glad you want to do that.
That certainly inspires me to make the effort.
One way is to incrementally change the Solaris branch to make it
compile on GNU/Linux by wrapping Solaris specific code in a portable
API. This version should still continue to work as expected on
Solaris.
I agree. That's what I thought I should start working on to.
Then we can try to make it run on GNU/Linux.
Once we have a working code for Solaris and GNU/Linux we can try to
merge it with the "official" version.
That part I may need some help with. There have been a lot of
changes and a team cooperation would really make that more feasible.
CONCLUSION:
I look forward to discussing this with the community to arrive at
a PC/SC-Lite with increased functionality and adaptability that
meet the needs of more users.
I haven't seen any comment to you mail in this list. Maybe the
"community" is not so much interested in your improvements.
I think you/SUN we have to do the most part of the work.
No one has a working example on Linux yet. The community has no
experience
with it nor do most probably realize what it does.
Probably not a lot of people have the need for the extra scalability
and security at the moment, and those that do would probably just look
at it and think - "no distribution available for Linux" and just move
on.
The problem with Sun doing it is that it is a very substantial effort,
and it's going to take a serious commitment of time and will
to get through it; a project in and of itself, The changes
to the main branch will not just merge with the new code. They'll
have to be examined on a case-by-case basis and some may be irrelevant,
while some changes will require new implementations of sections of code.
When I looked at the diffs since 1.3.2 a few months ago or so I noticed
many mange changes that were syntactical, perhaps whitespace changes.
It's going to be tough just managing the syntax.
The scope change is so substantial that it isn't really a matter of
saying
that the code would be merged primarily from one code base to the other.
It will probably require drawing from both and building a new one. I
don't
know the details yet of that, just that it's non-trivial.
Paul
_______________________________________________
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle
