Re: [opensc-commits] svn opensc changed[3802] Enable PCSC by default.

[Alon Bar-Lev]

This is simply wrong.
It will completely fail if pcsc is absent.

Please refer to the "detect" logic for openssl/zlib/iconv,
Please fix.

Also, I must say I reject of enabling optional features without
explicit instruction.
But... people wish to push something.

Alon.

On Mon, Nov 2, 2009 at 12:52 PM, <webmaster@...> wrote:

>
> Revision: 3802
> Author:   ludovic.rousseau
> Date:     2009-11-02 10:52:39 +0000 (Mon, 02 Nov 2009)
>
> Log Message:
> -----------
> Enable PCSC by default. Use --disable-pcsc if you do not want it.
>
> See http://www.opensc-project.org/pipermail/opensc-devel/2009-November/012755.html
>
> Modified Paths:
> --------------
>    trunk/configure.ac
>
> Modified: trunk/configure.ac
> ===================================================================
> --- trunk/configure.ac  2009-11-02 10:43:06 UTC (rev 3801)
> +++ trunk/configure.ac  2009-11-02 10:52:39 UTC (rev 3802)
> @@ -153,9 +153,9 @@
>
>  AC_ARG_ENABLE(
>        [pcsc],
> -       [AS_HELP_STRING([--enable-pcsc],[enable pcsc support @<:@disabled@:>@])],
> +       [AS_HELP_STRING([--disable-pcsc],[disable pcsc support @<:@enabled@:>@])],
>        ,
> -       [enable_pcsc="no"]
> +       [enable_pcsc="yes"]
>  )
>
>  AC_ARG_ENABLE(
>
>
> _______________________________________________
> opensc-commits mailing list
> opensc-commits@...
> http://www.opensc-project.org/mailman/listinfo/opensc-commits

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

[Peter Stuge-4]

Alon Bar-Lev wrote:
> This is simply wrong.
> It will completely fail if pcsc is absent.
>
> Please refer to the "detect" logic for openssl/zlib/iconv,
> Please fix.

Agree!


> Also, I must say I reject of enabling optional features without
> explicit instruction.

Yes! In this case, at the very least, also add detect and default yes
for OpenCT.

BUT! This is still the wrong fix, if the problem was described as "it
is possible to build OpenSC without any reader support" - it must be
possible to simply check if either pcsc or openct has been enabled
during configuration - and complain to the user otherwise?


> But... people wish to push something.

Mm.


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

[Ludovic Rousseau]

2009/11/2 Alon Bar-Lev <alon.barlev@...>:
> This is simply wrong.
> It will completely fail if pcsc is absent.

Yes. You have to use --disable-pcsc if you do not want to use pcsc.
It will fail by design.

> Please refer to the "detect" logic for openssl/zlib/iconv,
> Please fix.
>
> Also, I must say I reject of enabling optional features without
> explicit instruction.
> But... people wish to push something.

The idea is that PCSC is not optional but the default smart card
access mechanism.
It is not mandatory since OpenCT is still available.

Normal users should use:
$ ./configure && make && sudo make install
and have a working configuration in a standard case.

If ./configure fails because pcsclite is missing then install pcsclite.

Only if you know what you are doing you can use OpenCT instead of
pcsclite. As Andreas wrote many times pcsclite + ccid driver should be
used instead of OpenCT.

Regards,

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

[Alon Bar-Lev]

You should follow the "detect" logic.
Please follow openssl/zlib/iconv logic.

On Mon, Nov 2, 2009 at 3:38 PM, Ludovic Rousseau
<ludovic.rousseau@...> wrote:

> 2009/11/2 Alon Bar-Lev <alon.barlev@...>:
>> This is simply wrong.
>> It will completely fail if pcsc is absent.
>
> Yes. You have to use --disable-pcsc if you do not want to use pcsc.
> It will fail by design.
>
>> Please refer to the "detect" logic for openssl/zlib/iconv,
>> Please fix.
>>
>> Also, I must say I reject of enabling optional features without
>> explicit instruction.
>> But... people wish to push something.
>
> The idea is that PCSC is not optional but the default smart card
> access mechanism.
> It is not mandatory since OpenCT is still available.
>
> Normal users should use:
> $ ./configure && make && sudo make install
> and have a working configuration in a standard case.
>
> If ./configure fails because pcsclite is missing then install pcsclite.
>
> Only if you know what you are doing you can use OpenCT instead of
> pcsclite. As Andreas wrote many times pcsclite + ccid driver should be
> used instead of OpenCT.
>
> Regards,
>
> --
>  Dr. Ludovic Rousseau
>

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

[Ludovic Rousseau]

2009/11/2 Alon Bar-Lev <alon.barlev@...>:
> You should follow the "detect" logic.
> Please follow openssl/zlib/iconv logic.

I think "detect" is wrong. If pcsc-lite is not installed you will not
have a working configuration but you will not be warned either.

If you want I can add code to disable pcsc if openct is used. So you
can continue to use "./configure --enable openct" as before. Would
that be a good idea?

Bye

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

[Alon Bar-Lev]

configure should detect whatever it can by default should disable all
default feature that are not available.
This is how most [well behaved] configurations do.

But for sure disabling pcsc if openct is enabled is bad idea, as users
may like them both and you start to add some of YOUR logic into the
build process.

I am not sure what you are trying to accomplish... people who build
from sources should know what they are doing and are notified which
options are enabled at configure summary.

Distribution packages will use whatever they like and users will
always have working environment.

On Mon, Nov 2, 2009 at 3:56 PM, Ludovic Rousseau
<ludovic.rousseau@...> wrote:

> 2009/11/2 Alon Bar-Lev <alon.barlev@...>:
>> You should follow the "detect" logic.
>> Please follow openssl/zlib/iconv logic.
>
> I think "detect" is wrong. If pcsc-lite is not installed you will not
> have a working configuration but you will not be warned either.
>
> If you want I can add code to disable pcsc if openct is used. So you
> can continue to use "./configure --enable openct" as before. Would
> that be a good idea?
>
> Bye
>
> --
>  Dr. Ludovic Rousseau
>

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

[Peter Stuge-4]

Ludovic Rousseau wrote:
> > Please follow openssl/zlib/iconv logic.
>
> I think "detect" is wrong. If pcsc-lite is not installed you will
> not have a working configuration but you will not be warned either.

I tried to suggest a method of addressing this; check that support
for some reader type has been enabled, and refuse to continue
otherwise.

Does that seem reasonable?


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

[Alon Bar-Lev]

On Mon, Nov 2, 2009 at 4:07 PM, Peter Stuge <peter@...> wrote:

> Ludovic Rousseau wrote:
>> > Please follow openssl/zlib/iconv logic.
>>
>> I think "detect" is wrong. If pcsc-lite is not installed you will
>> not have a working configuration but you will not be warned either.
>
> I tried to suggest a method of addressing this; check that support
> for some reader type has been enabled, and refuse to continue
> otherwise.
>
> Does that seem reasonable?
>

Yes. although this way you cannot use CTAPI alone.
_______________________________________________
opensc-devel mailing list
opensc-devel@...
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[Peter Stuge-4]

Alon Bar-Lev wrote:

> >> I think "detect" is wrong. If pcsc-lite is not installed you will
> >> not have a working configuration but you will not be warned either.
> >
> > I tried to suggest a method of addressing this; check that support
> > for some reader type has been enabled, and refuse to continue
> > otherwise.
> >
> > Does that seem reasonable?
>
> Yes. although this way you cannot use CTAPI alone.

Ok - then a warning may be better than a fatal error.


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

[Martin Paljak-2]

On 02.11.2009, at 16:12, Alon Bar-Lev wrote:

> On Mon, Nov 2, 2009 at 4:07 PM, Peter Stuge <peter@...> wrote:
>> Ludovic Rousseau wrote:
>>>> Please follow openssl/zlib/iconv logic.
>>>
>>> I think "detect" is wrong. If pcsc-lite is not installed you will
>>> not have a working configuration but you will not be warned either.
>>
>> I tried to suggest a method of addressing this; check that support
>> for some reader type has been enabled, and refuse to continue
>> otherwise.
>>
>> Does that seem reasonable?
>>
>
> Yes. although this way you cannot use CTAPI alone.

My proposal:

1. Make CT-API configurable and optional. Users who *know* they want  
CT-API, should enable it. This would bring all reader systems on the  
same level (currently it is impossible to leave out CT-API)
2. Enable (and try to detect detect) PC/SC by default. It is the only  
default method on all platforms, apparently also endorsed by many. But  
allow to disable it.
3. Fail configure if no reader access mechanism is enabled/found.

I have received tons of e-mails about 1) Error: can't open /var/run/
openct/status: No such file or directory (reason: openct being enabled  
but not used on Ubuntu/Debian) 2) things that suppress_errors did not  
hide but were harmless (somewhat a bug in card-mcrd.c, but still a  
thing to notice)  3) things that went to sc_error but were also  
harmless (like SCARD_E_NO_SERVICE and other PC/SC issues)

2 and 3 have been fixed for 0.12, the OpenCT thing probably depends on  
up to date OpenCT version and/or distro packaging. But making it clear  
what gets used is definitely a good thing.

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

[Andreas Jellinghaus-2]

Am Montag 02 November 2009 14:38:07 schrieb Ludovic Rousseau:
> Normal users should use:
> $ ./configure && make && sudo make install
> and have a working configuration in a standard case.

I agree with that. With the old default settings neither pcsc not openct
would be build in, thus no reader support at all.

(ok, ok, ctapi is always compiled in. but I can't remember reading about
any ctapi user in the last few years...)

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

[Jim Rees]

Remind me why we don't just dispense with OpenCT and incorporate the pcsc
reader drivers directly into OpenSC.  Is there a license issue?  Are there
people using pcsc as a separate package without OpenSC?  Are there problems
for non-linux installs?
_______________________________________________
opensc-devel mailing list
opensc-devel@...
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[Andreas Jellinghaus-2]

I think it is best to have:
* disable -> don't even try
* enable -> needs to be there
* detect -> see if it is there

with "detect" as default.
(or if we want to keep it simple: only detect, no enable/disable.)

and it would be nice to have a big fat warning, if neither pcsc
nor openct was found/enabled (unless both were explicit disabled
 - ignore this if it is too much work).

> But for sure disabling pcsc if openct is enabled is bad idea, as users
> may like them both and you start to add some of YOUR logic into the
> build process.

having both is ok, it is the common case for distributions, and
thus it must continue to work.

> I am not sure what you are trying to accomplish... people who build
> from sources should know what they are doing and are notified which
> options are enabled at configure summary.

yes and no. few people still compile from source and most are distribution
packages, and they should know what they do, and notice any bigger changes.

still a few people compile opensc themself, and do that without looking
at the documentation first. if everything is disabled unless turned on
with a configure option, it looks like configure/make/make install worked
fine, but the result is something they can't use.

adding a big fat warning for such people (if neither openct nor pcsc is
found), or a "detect" as default (at least for pcsc and manybe also openct),
is a good thing.

> Distribution packages will use whatever they like and users will
> always have working environment.

yes, but distribution packages have a limited amount of time for
each package too.

so I suggest:
1.) stay compatible, in case they fine tuned their parameter already.
2.) add some warnings or better default for users not reading the
documentation first. (maybe also check docs and update them if needed.)

I think ludovics change does that.

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

[Andreas Jellinghaus-2]

Am Montag 02 November 2009 15:07:52 schrieb Peter Stuge:

> Ludovic Rousseau wrote:
> > > Please follow openssl/zlib/iconv logic.
> >
> > I think "detect" is wrong. If pcsc-lite is not installed you will
> > not have a working configuration but you will not be warned either.
>
> I tried to suggest a method of addressing this; check that support
> for some reader type has been enabled, and refuse to continue
> otherwise.
>
> Does that seem reasonable?

yes and no. ctapi is always compiled in, so we should allow that
case. but we can still have a big fat warning if neither openct
nor pcsc is compiled in.

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

[Andreas Jellinghaus-2]

Am Montag 02 November 2009 18:02:50 schrieb Jim Rees:
> Remind me why we don't just dispense with OpenCT and incorporate the pcsc
> reader drivers directly into OpenSC.  Is there a license issue?  Are there
> people using pcsc as a separate package without OpenSC?  Are there problems
> for non-linux installs?

there are a few smart card applications that work directly on pcsc:
 * gpshell (tool for managing java cards)
 * home banking applications with hbci smart cards

also openct supports a number of tokens and readers without pcsc drivers
(or only binary only drivers for selected plattforms).

I started "usbtoken" (predecessor to openct), because I didn't want
to maintain T=1 and the whole framework code once for every driver.

if we want to get rid of openct, maybe we can find a way to
use ccid code to implement other drivers as well?
after all many openct drivers have ~20 lines of real code:
detect the device and a simpel i/o code that puts T=1 blocks
in a usb control transfer package.

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

[Martin Paljak-2]

On 02.11.2009, at 19:08, Andreas Jellinghaus wrote:

> yes and no. ctapi is always compiled in, so we should allow that
> case. but we can still have a big fat warning if neither openct
> nor pcsc is compiled in.

Yes, but *why*? I don't see a good reason for this other than pure  
legacy. CT-API requires manual configuration in the form of a module  
definition, much like current PC/SC implementation (if there was not a  
single, predictable default).
CT-API should as well be made optional. Especially because it is not  
used that much.


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

[Andreas Jellinghaus-2]

Am Montag 02 November 2009 18:25:55 schrieb Martin Paljak:

> On 02.11.2009, at 19:08, Andreas Jellinghaus wrote:
> > yes and no. ctapi is always compiled in, so we should allow that
> > case. but we can still have a big fat warning if neither openct
> > nor pcsc is compiled in.
>
> Yes, but *why*? I don't see a good reason for this other than pure
> legacy. CT-API requires manual configuration in the form of a module
> definition, much like current PC/SC implementation (if there was not a
> single, predictable default).
> CT-API should as well be made optional. Especially because it is not
> used that much.

making ct-api optional:
* is work. who wants to do it?
* not a big improvement - so far it causes no problems.
* creates work for distributions - they most likely want it enabled,
  and we need to be sure they know to change their spec/rules to add
  "--enable-ct-api".

so making it optional is a nice thing from a purity point of view.
but is it also a real world improvement? I mostly see drawbacks.

our problem was many options confused the users. this would create
even more options.

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

[Martin Paljak-2]

On 02.11.2009, at 22:56, Andreas Jellinghaus wrote:

> Am Montag 02 November 2009 18:25:55 schrieb Martin Paljak:
>> On 02.11.2009, at 19:08, Andreas Jellinghaus wrote:
>>> yes and no. ctapi is always compiled in, so we should allow that
>>> case. but we can still have a big fat warning if neither openct
>>> nor pcsc is compiled in.
>>
>> Yes, but *why*? I don't see a good reason for this other than pure
>> legacy. CT-API requires manual configuration in the form of a module
>> definition, much like current PC/SC implementation (if there was  
>> not a
>> single, predictable default).
>> CT-API should as well be made optional. Especially because it is not
>> used that much.
>
> making ct-api optional:
> * is work. who wants to do it?
> * not a big improvement - so far it causes no problems.
> * creates work for distributions - they most likely want it enabled,

>  and we need to be sure they know to change their spec/rules to add
>  "--enable-ct-api".


One of the main reasons to cut the cruft is PKCS#11 and hotplugging  
and properly working C_WaitForSlotEvent. It's not easy to implement a  
working solution across three currently supported, non-compatible  
interfaces.
In the long term correctly working mult-platform hotplugging is needed  
more than some semi-historic reader interface. I don't support cutting  
reader features, but I do support creating a single, working, cross-
platform solution as a baseline.

It is much simpler to support a single reader interface and by doing  
that take the effort to implement some improved features that are not  
easily doable with current architecture, which tries to please all  
different subsystems. Which, of course, is itself not bad at all.
There are different places where to push the decision: developers  
(make a code that works with all imaginable combinations), distro  
maintainers (make some decisions for your users), users (compile the  
software in a given way).

 From a historical perspective, OpenSC has been really flexible - it  
has grown to support many cards. But for all that fancy frameworking  
on reader driver or pkcs11 level? Has anyone seen any? Does anyone  
envision additions there? I doubt it. I don't believe that in the  
coming years there would be some major new additions *that would fit  
into current architecture* to the landscape. And the dominant  
components will be 1) PC/SC for reader access 2) PKCS#11 for other  
applications to use 3) Platform components (out of which one, basecsp,  
already does not fit into the picture very well because of the passed  
in card handle) for platorms that support them.

Taking that into account, I would even suggest another alternative  
scenario: only support a single a single reader subsystem by default.  
Distro packagers can create different libopensc-s, much like libcurl4-
gnutls and libcurl4-openssl.


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