Re: [Muscle] New Solaris PC/SC-Lite branch added to repository
On Jul 3, 2008, at 11:36 AM, Ludovic Rousseau wrote: On Thu, Jul 3, 2008 at 7:13 PM, Paul Klissner <[EMAIL PROTECTED]> wrote: On Jul 3, 2008, at 2:39 AM, Ludovic Rousseau wrote: Comments: - macro NONULL() is defined in pcscdaemon.h and also in many .c files That's a macro I added, right? Yes Are you saying it should exist, or that it should go elsewhere? The macro should go to src/misc.h and misc.h included where needed. NONUL is define TWO times in auth.c :-) - 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. Use the abstract DYN_LoadLibrary(), DYN_GetAddress(), DYN_CloseLibrary() from dyn_generic.h and hide the implementation details in dyn_unix.c (unless the code is really different and you need a dyn_solaris.c) 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. I will help as much as I can. Your help, in particular, with your detailed knowledge of the history of the project and nature of the code and deltas will be invaluable, along with the fact that you are encouraging the effort. That means a lot! After the holiday break I'll start to work on getting the it to build and run on Linux. After that I'll work on getting a clearer idea of what the merging process with the trunk will entail and come up with a preliminary approach and document and/or diagram what I've found in some for. Then we can discuss it to find an approach the works for everyone. Meanwhile, I'll talk to management to see how we can get this to happen. I assume this is something mgt. wants and has the resources to engage, at least enough of a percentage of time for there to be tangible progress. This increases my enthusiasm for getting this going quite a bit. So thank you for that. Paul ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] New Solaris PC/SC-Lite branch added to repository
On Thu, Jul 3, 2008 at 7:13 PM, Paul Klissner <[EMAIL PROTECTED]> wrote: > On Jul 3, 2008, at 2:39 AM, Ludovic Rousseau wrote: >> Comments: >> - macro NONULL() is defined in pcscdaemon.h and also in many .c files > > That's a macro I added, right? Yes > Are you saying it should exist, or that it should go elsewhere? The macro should go to src/misc.h and misc.h included where needed. NONUL is define TWO times in auth.c :-) >> - 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. Use the abstract DYN_LoadLibrary(), DYN_GetAddress(), DYN_CloseLibrary() from dyn_generic.h and hide the implementation details in dyn_unix.c (unless the code is really different and you need a dyn_solaris.c) >> 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. I will help as much as I can. Bye -- Dr. Ludovic Rousseau ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] New Solaris PC/SC-Lite branch added to repository
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.pdfDesign 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
Re: [Muscle] New Solaris PC/SC-Lite branch added to repository
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.pdfDesign 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 instead of #include - #include to have MAXPATHLEN defined. I don't know if using MAXPATHLEN is a good idea. It is a pro
[Muscle] New Solaris PC/SC-Lite branch added to repository
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.pdfDesign 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 (
