On Tue, 2010-08-31 at 10:35 +0300, Martin Paljak wrote:
> Hello?
> On Aug 30, 2010, at 11:13 PM, Andre Zepezauer wrote:
>
> > Hello all,
> >
> > what do you think of dropping the possibility to initialise CardOS smart
> > cards in 0.11.14? The reason of doing so, is to stop the production of
> > more of these questionable split-key cards.
> What would be the rationale of doing it? I don't think turning it off is a
> good idea, but a fat warning ("Use a more recent version!") could be used, if
> justified and needed (why?).
If nobody is willing to write a proper pkcs15-emulation for split-key
cards, then the support of it is dropped someday. But why should this
ever happen? Because the remaining split-key specific code [1] may slow
down new developments or prevent some kind of improvements in
framework-pkcs15 and other places. Not yet, but for sure.
Every change on framework-pkcs15 (maybe in other places too) must take
split-keys into account. Therefore developers are forced to work around
this strange concept for years. Hopefully not as many years.
To disable the initialisation with split-keys now makes sense, because
it will prevent the population to grow. In my opinion this is the best
what could been done. Also it will prevent people form _accidentally_
initialise with split-keys.
*to disable initialisation with split-keys in 0.11.14 may rise the
awareness of the new method in 0.12.X
*everyone who wants longer support can use 0.12.X for initialisation
*everyone who wants to initialise with split-keys can do this with
the releases up to 0.11.13
Since there is a better method of initialising CardOS, why not pushing
that?
[1]http://www.opensc-project.org/pipermail/opensc-devel/2010-June/014390.html
> > People who want to initialise CardOS are then forced to do this with
> > either 0.11.13 or 0.12.X. Hopefully they chose the newer release,
> > because it comes with an improved initialisation for CardOS. No more
> > split-keys here! Cards initialised with 0.12.0 should work with the
> > 0.11.X releases too. Verification of this fact is required of cause.
> I believe documentation is important here.
>
> Due to the nature of smart cards, backwards-compatibility for already
> personalized cards is greatly desired and a topmost priority.
>
> At the same time, personalization happens far less frequently than use, so
> such restriction could, in theory, make sense as well (requiring newer
> software for personalization but working with older software in read-only
> mode)
>
>
>
> > Another fact is that for example Ubuntu 10.04 and Debian Squeeze will
> > stay with the 0.11.X branches for at least the next three years. The
> > same holds for other distributions with a long release cycle (RHEL has
> > seven years of support I think). The imagination that someone could
> > easily produce new split-key cards for the next few years isn't very
> > appealing to me.
> We can't fix what we can't affect. That is Linux distribution release
> schedules or decisions done between the chair and the keyboard. We need to
> make the choices and circumstances clear and well documented though.
>
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
