Review Request for 9000142: PlatformPCSC.java loading unversioned native shared library

Severin Gehwolf sgehwolf at redhat.com
Thu Apr 25 08:43:33 UTC 2013


Hi Valerie,

Thanks for the review!

On Wed, 2013-04-24 at 15:11 -0700, Valerie (Yu-Ching) Peng wrote:
> Won't this change break systems which don't have libpcsclite.so.1?

Yes. However, currently it breaks systems which don't have
libpcsclite.so. [1] would be an example. There is a system property,
sun.security.smartcardio.library, which could be used to specify the
library path. *If* people really want to use libpcsclite.so (no matter
the version), they could use that property.

What I think is bad, is that it currently tries to use unversioned
libpcsclite.so by default. I mean even when no property has been set.
While the static initializer might work in that case it could
potentially fail later on when it's used and libpcsclite.so is actually
a newer version the Java API does not know how to handle.

> Changes like this need to be thought through. What happens when 
> libpcsclite.so.2 comes out?

Exactly. Right now there is the potential to accept a libpcsclite.so.2
if that library providing libpcsclite.so.2 also provides a symlink to
libpcsclite.so. My proposed change to PlatformPCSC would make that fail
with an IOException right in the static initializer. Failing early seems
to be a better approach in this case.

> As for API changes, shouldn't there be some compatibility requirement on 
> APIs as libpcsclite.so evolves?

Maybe. It looks to me that PlatformPCSC seems to rely on that. What if
API compatibility has been assumed, but does not hold once
libpcsclite.so.2 comes out?

Cheers,
Severin

[1] https://bugzilla.redhat.com/show_bug.cgi?id=910107

> On 04/24/13 04:05, Florian Weimer wrote:
> > On 03/01/2013 11:30 AM, Severin Gehwolf wrote:
> >> Hi,
> >>
> >> The bug for this review request is at:
> >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=9000142
> >>
> >> In PlatformPCSC.java unversioned native libraries are loaded by default
> >> if no system property is specified. This could lead to a JVM crash if
> >> the API of the native library changes, but the Java code still relies on
> >> old API. The fix is to load versioned shared libraries instead.
> >
> > Hmm.  Why doesn't the "j2pcsc" library link against the right version 
> > of libpcsclite.so?
> >
> 






More information about the security-dev mailing list