From: Ludovic Rousseau (ludovic.rousseaugmail.com)
Date: Thu Jul 03 2008 - 04:39:18 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

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?

> 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?

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

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

- RTLD_PARENT does not exist for GNU/Linux dlopen()

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

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

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.

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.

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

Bye,

--
 Dr. Ludovic Rousseau

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

• text/plain attachment: patch.txt

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]