OpenSC 0.11.11 released today

[Andreas Jellinghaus-2]

OpenSC 0.11.11 released today updated the "myeid" driver and fixes
compiling issues with OpenSSL 0.9.7 and 1.0.0.

http://www.opensc-project.org/files/opensc/opensc-0.11.11.tar.gz

Development is now focused on a new 0.12.* branch of OpenSC.

Regards, Andreas
_______________________________________________
opensc-devel mailing list
opensc-devel@...
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[Johannes Becker-5]

Hello,

when configuring OpenSC 0.11.11 under Debian lenny and squeeze I get

PC/SC support:           no
NSPlugin support:        no

I have installed
 libpcsclite-dev  (Version: 1.4.102-1)

What else do I need?


By the way: opensc doesn't work as it comes with Debian squeeze
pcsc_scan detects reader and card, but opensc-tool doesn't find
the reader.

Regards
  Johannes

_______________________________________________
opensc-devel mailing list
opensc-devel@...
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[Aventra development]

Hi!

You need to add the switch --enable-pcsc to the configure command to enable
PCSC.
About the NSPlugin I don't know, but there has been some discussion on that
it is really old and not maintained.

Regards,
Toni

> -----Original Message-----
> From: opensc-devel-bounces@... [mailto:opensc-devel-
> bounces@...] On Behalf Of Johannes Becker
> Sent: 29. lokakuuta 2009 12:27
> To: opensc-devel@...
> Subject: Re: [opensc-devel] OpenSC 0.11.11 released today
>
> Hello,
>
> when configuring OpenSC 0.11.11 under Debian lenny and squeeze I get
>
> PC/SC support:           no
> NSPlugin support:        no
>
> I have installed
>  libpcsclite-dev  (Version: 1.4.102-1)
>
> What else do I need?
>
>
> By the way: opensc doesn't work as it comes with Debian squeeze
> pcsc_scan detects reader and card, but opensc-tool doesn't find
> the reader.
>
> Regards
>   Johannes
>
> _______________________________________________
> opensc-devel mailing list
> opensc-devel@...
> http://www.opensc-project.org/mailman/listinfo/opensc-devel

_______________________________________________
opensc-devel mailing list
opensc-devel@...
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[Martin Paljak-2]

On 29.10.2009, at 12:26, Johannes Becker wrote:
> NSPlugin support:        no
Do you miss it or expected that it would be available? It will be  
removed from opensc, as it is not part of core functionality of opensc.


--
Martin Paljak
http://martin.paljak.pri.ee
+372.515.6495




_______________________________________________
opensc-devel mailing list
opensc-devel@...
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[Hannu Kotipalo-2]

Johannes Becker kirjoitti:

> Hello,
>
> when configuring OpenSC 0.11.11 under Debian lenny and squeeze I get
>
> PC/SC support:           no
> NSPlugin support:        no
>
> I have installed
>  libpcsclite-dev  (Version: 1.4.102-1)
>
> What else do I need?
>
>
> By the way: opensc doesn't work as it comes with Debian squeeze
> pcsc_scan detects reader and card, but opensc-tool doesn't find
> the reader.
>  

Same in Ubuntu 9.10 (64 bit). There seems to be a missing symbolic link.
This helped me:
sudo ln -s /lib/libpcsclite.so.1.0.0 /usr/lib/libpcsclite.so.1

btw, I think *some* reader support (either pcsclite or opensc) should be
on by default and there should be some warning if no reader support is
configured. These could save a lot of time from the newcomers..

Hannu
> Regards
>   Johannes
>
> _______________________________________________
> opensc-devel mailing list
> opensc-devel@...
> http://www.opensc-project.org/mailman/listinfo/opensc-devel
>
>  



_______________________________________________
opensc-devel mailing list
opensc-devel@...
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[Martin Paljak-2]

Moi Hannu,
On 29.10.2009, at 19:46, Hannu Kotipalo wrote:
>
> btw, I think *some* reader support (either pcsclite or opensc)  
> should be on by default and there should be some warning if no  
> reader support is configured. These could save a lot of time from  
> the newcomers..
Well, CT-API is "built in" but it always requires configuration, so it  
really doesn't matter.

OpenSC comes by default on most distros with support for both PC/SC  
and OpenCT.

libccid and openct on .deb systems should conflict each other, because  
they both grab CCID devices which can cause confusion and troubles (as  
seen on list)


Thanks,
--
Martin Paljak
http://martin.paljak.pri.ee
+372.515.6495




_______________________________________________
opensc-devel mailing list
opensc-devel@...
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[Alon Bar-Lev]

On Thu, Oct 29, 2009 at 7:46 PM, Hannu Kotipalo <hannu@...> wrote:
> btw, I think *some* reader support (either pcsclite or opensc) should be on by default and there should be some warning if no reader support is configured. These could save a lot of time from the newcomers..

If you build the package configure it to whatever you want.
One defaults is bad for others.
If you don't know what to place, look at your favorite distribution
pre-packaged configuration.

Alon.
_______________________________________________
opensc-devel mailing list
opensc-devel@...
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[Ludovic Rousseau]

2009/10/29 Hannu Kotipalo <hannu@...>:

> Johannes Becker kirjoitti:
>>
>> Hello,
>>
>> when configuring OpenSC 0.11.11 under Debian lenny and squeeze I get
>>
>> PC/SC support:           no
>> NSPlugin support:        no
>>
>> I have installed  libpcsclite-dev  (Version: 1.4.102-1)
>>
>> What else do I need?
>>
>>
>> By the way: opensc doesn't work as it comes with Debian squeeze
>> pcsc_scan detects reader and card, but opensc-tool doesn't find
>> the reader.
>>
>
> Same in Ubuntu 9.10 (64 bit). There seems to be a missing symbolic link.
> This helped me:
> sudo ln -s /lib/libpcsclite.so.1.0.0 /usr/lib/libpcsclite.so.1

On Ubuntu libpcsclite is in /lib and not in /usr/lib.
See http://bugs.debian.org/531592

The Ubuntu opensc package should be patched to use a different path.

I am not sure if the change from libpcsclite link at compilation to a
dynamic loading at runtime was a good idea. It is more work as user
support and package maintainer. But it is not less work for OpenSC
developers. Not a good change IMO.

> btw, I think *some* reader support (either pcsclite or opensc) should be on
> by default and there should be some warning if no reader support is
> configured. These could save a lot of time from the newcomers..

I agree. PC/SC should be used by default, and disabled on request if needed.
I don't know anybody using OpenSC without PCSC _and_ without OpenCT
support (ie the _default_ configuration).

Any objection to use PC/SC by default (again)?

Bye

--
 Dr. Ludovic Rousseau
_______________________________________________
opensc-devel mailing list
opensc-devel@...
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[Martin Paljak-2]

On 01.11.2009, at 13:16, Ludovic Rousseau wrote:

> Any objection to use PC/SC by default (again)?
None.

And +1 for making openct conflict with libccid as well.

--
Martin Paljak
http://martin.paljak.pri.ee
+372.515.6495




_______________________________________________
opensc-devel mailing list
opensc-devel@...
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[Peter Stuge-4]

Ludovic Rousseau wrote:
> Any objection to use PC/SC by default (again)?

I for one prefer OpenCT.


//Peter
_______________________________________________
opensc-devel mailing list
opensc-devel@...
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[Kalev Lember]

On 11/01/2009 01:16 PM, Ludovic Rousseau wrote:
> 2009/10/29 Hannu Kotipalo<hannu@...>:
>> Same in Ubuntu 9.10 (64 bit). There seems to be a missing symbolic link.
>> This helped me:
>> sudo ln -s /lib/libpcsclite.so.1.0.0 /usr/lib/libpcsclite.so.1
>
> On Ubuntu libpcsclite is in /lib and not in /usr/lib.
> See http://bugs.debian.org/531592
>
> The Ubuntu opensc package should be patched to use a different path.

I think the correct fix here would be in configure.ac:
-DEFAULT_PCSC_PROVIDER="/usr/lib${libdir##*/lib}/libpcsclite.so.1"
+DEFAULT_PCSC_PROVIDER="libpcsclite.so.1"

One shouldn't make assumptions in what directory libpcsclite.so.1 is
installed.

If distributions want to hardcode a path, they can do it. But opensc's
default should be something that works across most distributions.

--
Kalev Lember
_______________________________________________
opensc-devel mailing list
opensc-devel@...
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[Peter Stuge-4]

Kalev Lember wrote:
> I think the correct fix here would be in configure.ac:
> -DEFAULT_PCSC_PROVIDER="/usr/lib${libdir##*/lib}/libpcsclite.so.1"
> +DEFAULT_PCSC_PROVIDER="libpcsclite.so.1"
>
> One shouldn't make assumptions in what directory libpcsclite.so.1 is
> installed.

I agree, -rpath is horrible.


//Peter
_______________________________________________
opensc-devel mailing list
opensc-devel@...
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[Andreas Jellinghaus-2]

Am Sonntag 01 November 2009 12:16:56 schrieb Ludovic Rousseau:

> On Ubuntu libpcsclite is in /lib and not in /usr/lib.
> See http://bugs.debian.org/531592
>
> The Ubuntu opensc package should be patched to use a different path.
>
> I am not sure if the change from libpcsclite link at compilation to a
> dynamic loading at runtime was a good idea. It is more work as user
> support and package maintainer. But it is not less work for OpenSC
> developers. Not a good change IMO.
>
> > btw, I think *some* reader support (either pcsclite or opensc) should be
> > on by default and there should be some warning if no reader support is
> > configured. These could save a lot of time from the newcomers..
>
> I agree. PC/SC should be used by default, and disabled on request if
>  needed. I don't know anybody using OpenSC without PCSC _and_ without
>  OpenCT support (ie the _default_ configuration).
>
> Any objection to use PC/SC by default (again)?

No. pcsc-lite plus libccid should be the recommendation for new users.

only a few old token have no drivers for pcsc-lite (or only binary
only), so openct is a good alternative there.

Regards, Andreas
_______________________________________________
opensc-devel mailing list
opensc-devel@...
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[Andreas Jellinghaus-2]

Am Sonntag 01 November 2009 12:25:26 schrieb Martin Paljak:
> On 01.11.2009, at 13:16, Ludovic Rousseau wrote:
> > Any objection to use PC/SC by default (again)?
>
> None.
>
> And +1 for making openct conflict with libccid as well.

conflict is the negative equivalent of depends.

is there some negative equivalent of recommends?
i.e. some way to say "while you can install both at
the same time, it is not suggested"? that would be nice.

but a "conflict" is maybe better than the current chaos.

Regards, Andreas
_______________________________________________
opensc-devel mailing list
opensc-devel@...
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[Andreas Jellinghaus-2]

Am Sonntag 01 November 2009 13:06:49 schrieb Peter Stuge:
> Kalev Lember wrote:
> > I think the correct fix here would be in configure.ac:
> > -DEFAULT_PCSC_PROVIDER="/usr/lib${libdir##*/lib}/libpcsclite.so.1"
> > +DEFAULT_PCSC_PROVIDER="libpcsclite.so.1"
> >
> > One shouldn't make assumptions in what directory libpcsclite.so.1 is
> > installed.
>
> I agree, -rpath is horrible.

but this discussion isn't about rpath. we are leading the shared
library as plugin.

well, maybe we shouldn't or at least by default not do that.
alon was working on an alternative implementation and thus
made it easy to configure, which library for the same
static interface is loaded. while this is real nice for developers,
it creates confusion for normal users without this need.

I don't want to create a new 0.11 release, as editing a config
file or using different configure options is easy. but what is
the best suggestion for distributions?

Regards, Andreas
_______________________________________________
opensc-devel mailing list
opensc-devel@...
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[Alon Bar-Lev]

On Sun, Nov 1, 2009 at 4:43 PM, Andreas Jellinghaus <aj@...> wrote:
> well, maybe we shouldn't or at least by default not do that.
> alon was working on an alternative implementation and thus
> made it easy to configure, which library for the same
> static interface is loaded. while this is real nice for developers,
> it creates confusion for normal users without this need.

This was done in order to remove the win32 specific code and use
single path of execution at all platforms.

Alon.
_______________________________________________
opensc-devel mailing list
opensc-devel@...
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[Kalev Lember]

On 11/01/2009 04:43 PM, Andreas Jellinghaus wrote:

> Am Sonntag 01 November 2009 13:06:49 schrieb Peter Stuge:
>> Kalev Lember wrote:
>>> I think the correct fix here would be in configure.ac:
>>> -DEFAULT_PCSC_PROVIDER="/usr/lib${libdir##*/lib}/libpcsclite.so.1"
>>> +DEFAULT_PCSC_PROVIDER="libpcsclite.so.1"
>>>
>>> One shouldn't make assumptions in what directory libpcsclite.so.1 is
>>> installed.
>>
>> I agree, -rpath is horrible.
>
> but this discussion isn't about rpath. we are leading the shared
> library as plugin.

Yes, it's not rpath here but rather telling dlopen() where exactly the
lib is located. But in any case if we don't specify a path, dlopen()
will search for "libpcsclite.so.1" in default lib directories (usually
/lib and /usr/lib in that order). I don't think it'd make sense to
hardcode a path in here, but rather rely on dlopen()'s behaviour to find
the right lib. I'd change the default provider to "libpcsclite.so.1"
(without path).


> well, maybe we shouldn't or at least by default not do that.
> alon was working on an alternative implementation and thus
> made it easy to configure, which library for the same
> static interface is loaded. while this is real nice for developers,
> it creates confusion for normal users without this need.
>
> I don't want to create a new 0.11 release, as editing a config
> file or using different configure options is easy. but what is
> the best suggestion for distributions?

Well, opensc's default currently does not matter much for distributions,
because most of them are already specifying pcsc provider through
configure options (opensc's old default didn't work at all).

In long term, however, the change might do good. Fedora already switched
to "libpcsclite.so.1" without path as default provider [1]. If we
changed opensc's default to use no path, it'd make life easier for
Debian and Ubuntu packages too. In Debian and Ubuntu libpcsclite gets
installed in different directories, which means that their opensc
packaging also differes. With us changing the default to a sane value,
those two distros might be able to merge their opensc packaging differences.

[1]
http://cvs.fedoraproject.org/viewvc/rpms/opensc/devel/opensc.spec?r1=1.49&r2=1.50

--
Kalev Lember
_______________________________________________
opensc-devel mailing list
opensc-devel@...
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[Ludovic Rousseau]

2009/11/1 Andreas Jellinghaus <aj@...>:

> Am Sonntag 01 November 2009 12:25:26 schrieb Martin Paljak:
>> On 01.11.2009, at 13:16, Ludovic Rousseau wrote:
>> > Any objection to use PC/SC by default (again)?
>>
>> None.
>>
>> And +1 for making openct conflict with libccid as well.
>
> conflict is the negative equivalent of depends.
>
> is there some negative equivalent of recommends?
> i.e. some way to say "while you can install both at
> the same time, it is not suggested"? that would be nice.
>
> but a "conflict" is maybe better than the current chaos.

Since OpenCT and libccid both access (and locks) a CCID device they
can't be used at the same time.
But in revision 1136 [1] proposed in [2] I added a mechanism to avoid
the race to access the device.

No need to add a Conflicts between openct and libccid. Unless my
change [1] is wrong.

Bye

[1] http://www.opensc-project.org/openct/changeset/1136
[2] http://www.opensc-project.org/pipermail/opensc-devel/2009-February/011835.html

--
 Dr. Ludovic Rousseau
_______________________________________________
opensc-devel mailing list
opensc-devel@...
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[Ludovic Rousseau]

2009/11/1 Kalev Lember <kalev@...>:

> On 11/01/2009 04:43 PM, Andreas Jellinghaus wrote:
>> Am Sonntag 01 November 2009 13:06:49 schrieb Peter Stuge:
>>> Kalev Lember wrote:
>>>> I think the correct fix here would be in configure.ac:
>>>> -DEFAULT_PCSC_PROVIDER="/usr/lib${libdir##*/lib}/libpcsclite.so.1"
>>>> +DEFAULT_PCSC_PROVIDER="libpcsclite.so.1"
>>>>
>>>> One shouldn't make assumptions in what directory libpcsclite.so.1 is
>>>> installed.
>>>
>>> I agree, -rpath is horrible.
>>
>> but this discussion isn't about rpath. we are leading the shared
>> library as plugin.
>
> Yes, it's not rpath here but rather telling dlopen() where exactly the
> lib is located. But in any case if we don't specify a path, dlopen()
> will search for "libpcsclite.so.1" in default lib directories (usually
> /lib and /usr/lib in that order). I don't think it'd make sense to
> hardcode a path in here, but rather rely on dlopen()'s behaviour to find
> the right lib. I'd change the default provider to "libpcsclite.so.1"
> (without path).

Fixed in revision 3801

Bye

--
 Dr. Ludovic Rousseau
_______________________________________________
opensc-devel mailing list
opensc-devel@...
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[Ludovic Rousseau]

2009/11/1 Ludovic Rousseau <ludovic.rousseau@...>:

> 2009/10/29 Hannu Kotipalo <hannu@...>:
>> btw, I think *some* reader support (either pcsclite or opensc) should be on
>> by default and there should be some warning if no reader support is
>> configured. These could save a lot of time from the newcomers..
>
> I agree. PC/SC should be used by default, and disabled on request if needed.
> I don't know anybody using OpenSC without PCSC _and_ without OpenCT
> support (ie the _default_ configuration).
>
> Any objection to use PC/SC by default (again)?

Fixed in revision 3802.

Bye

--
 Dr. Ludovic Rousseau
_______________________________________________
opensc-devel mailing list
opensc-devel@...
http://www.opensc-project.org/mailman/listinfo/opensc-devel