Dear PC/SC-Lite community,

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().

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.

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.

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.

BUILDING:

The workspace in this branch was retrofitted (ie. flattened and
simplified) from a workspace used to build it for production.  It
currently only builds on Solaris and is pre-configured to build with
one particular set of options (see README.build), so the approach to
building is a little different than what one normally sees with an
open source project, but not in a huge way.  And for a system that
has the PC/SC headers, compilers, autoconf/automake tools installed,
as well as and Solaris companion software, building packages from
source only takes a couple of minutes after download.

The autoconf model is adhered to, so it shouldn't be too difficult
to forge it back into a more typical distribution build model.  The
code is put back initially in a this form in order to leap the
hurdle of getting it into the repository after being used in a
production environment.

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.

Thanks!
Paul

PS: Special thanks to Ludovic for allowing me to post the code
    to a branch in the repository.

_______________________________________________
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Reply via email to