Active developers on opensc-project.org

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Active developers on opensc-project.org

Martin Paljak-2
Hello,

After some shell-grep-fu to get all commiters of all the subversion repositories on opensc-project.org and their last commits, here are the stats with my comments:

Total number of unique commiters: 28

aet 2005-03-07 Antti Tapaninen, moved on long time ago, last commit http://www.opensc-project.org/opensc/changeset/2231
aj 2010-03-16 Andreas Jellinghaus, last commit http://www.opensc-project.org/opensc/changeset/4122
alon.barlev 2006-11-25 Alon Bar-Lev, old username, last commit http://www.opensc-project.org/test/changeset/23
alonbl 2010-03-22 Alon Bar-Lev, formerly alon.barlev, last commit http://www.opensc-project.org/build/changeset/106
andreas.schwier 2007-03-21 Andreas.Schweier, last commit http://www.opensc-project.org/opensc-java/changeset/82 
bert 2005-09-21 last commit http://www.opensc-project.org/opensc/changeset/2612
cg2v 2008-07-27 last commit http://www.opensc-project.org/opensc/changeset/3540
fabled 2002-11-11 last commit http://www.opensc-project.org/opensc/changeset/708
flc 2010-03-15 François Leblanc last commit http://www.opensc-project.org/opensc/changeset/4115
gurer 2007-10-06 last commit http://www.opensc-project.org/opensc/changeset/3278
henryk 2006-09-26  last commit http://www.opensc-project.org/opensc/changeset/3028
jey 2003-07-12 last commit http://www.opensc-project.org/opensc/changeset/1255
jonsito 2006-01-02 last commit http://www.opensc-project.org/pam_pkcs11/changeset/226
jps 2010-03-26 Jean-Pierre Szikora last commit http://www.opensc-project.org/web/changeset/236
ludovic.rousseau 2010-03-18 Ludovic Rousseau last commit http://www.opensc-project.org/test/changeset/40 :)
martin 2010-03-11 Martin Paljak, formerly pisi, last commit http://www.opensc-project.org/opensc/changeset/4106
mb 2005-07-29 last commit http://www.opensc-project.org/opensc/changeset/2449
nils 2008-02-25 Nils Larsch last commit http://www.opensc-project.org/opensc/changeset/3392
okir 2004-02-03 Olaf Kirch last commit http://www.opensc-project.org/opensc/changeset/1751
pisi 2005-03-09 Martin Paljak, old username, last commit http://www.opensc-project.org/opensc/changeset/2239
pk 2007-12-28 Peter Koch, last commit http://www.opensc-project.org/opensc/changeset/3309
pk_opensc 2006-04-30 Peter Koch, last commit in /events/ svn (no trac interface)
rchantereau 2005-03-17 last commit http://www.opensc-project.org/csp11/changeset/259
s 2010-02-24 Aleksey Samsonov, last commit http://www.opensc-project.org/opensc/changeset/4068
sth 2006-09-20 Stef Hoeben, last commit http://www.opensc-project.org/sca/changeset/83
viktor.tarasov 2010-03-23 Viktor Tarasov, formerly vtarasov, last commit http://www.opensc-project.org/opensc/changeset/4145
vtarasov 2007-07-10 Viktor Tarasov, old username, last commit http://www.opensc-project.org/opensc/changeset/3211
wolfgang.glas 2010-03-15 Wolfgang Glas, last commit http://www.opensc-project.org/opensc-java/changeset/134

Some of the people have never been involved with opensc-project.org or its subversion as commit history comes from CVS as well. This overview is just for reference.

I would hereby like to do the following:
a) Keep in access list only commiters who have done something in year 2009 or later: aj, alonbl, flc, jps, ludovic.rousseau, martin, s, viktor.tarasov, wolfgang.glas. As no-one has stopped participating in 2009, the list could be extended to 2008, and thus cg2v and nils kept, but I don't believe we'll hear from them.
b) Keep the list of commiters publicly available on https://www.opensc-project.org/opensc/wiki/GetInvolved and up to date and in sync with https://www.opensc-project.org/opensc/wiki/DevelopmentPolicy#Sourcecodeversioning
c) Remove all unused authorization and authentication info from opensc-project.org by 01.04.2010 unless there are objections from someone on the remove list.
d) Set up something similar to the MAINTAINERS file in Linux kernel, so that the list of actually supported cards/sybsystems/features/whatnot could be verified if necessary and dropped if needed. The list of maintainers must not be equal to the list of commiters but at least have some more data than just "can commit" associated with a name/contact. It will be hard to cover everything that already is in OpenSC but hopefully it will evolve until it really is clear, what is supported and what is dead code.

Comments?
--
Martin Paljak
http://martin.paljak.pri.ee
+3725156495

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Active developers on opensc-project.org

Ludovic Rousseau
2010/3/27 Martin Paljak <[hidden email]>:
> Comments?

Fine for me.

Maybe we could also maintain a wiki page of previous developers, call
it Emeritus. Since you have the list of the accounts you will remove
the first list is easy to create.
Developers without activity in the last 2 years (or whatever) then
move from The Team to The Emeritus with the date they changed there
status.

Bye

--
 Dr. Ludovic Rousseau
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Active developers on opensc-project.org

Martin Paljak-2
On Mar 27, 2010, at 15:41 , Ludovic Rousseau wrote:

> 2010/3/27 Martin Paljak <[hidden email]>:
>> Comments?
>
> Fine for me.
>
> Maybe we could also maintain a wiki page of previous developers, call
> it Emeritus. Since you have the list of the accounts you will remove
> the first list is easy to create.
> Developers without activity in the last 2 years (or whatever) then
> move from The Team to The Emeritus with the date they changed there
> status.
Good idea, will do. The date of the last commit will be the retirement date. This would also be a logical place to include a link to ProjectHistory that is not a "list of previous releases" but more like a chronology.



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


_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Active developers on opensc-project.org

Martin Paljak-2
In reply to this post by Ludovic Rousseau
On Mar 27, 2010, at 15:41 , Ludovic Rousseau wrote:

> 2010/3/27 Martin Paljak <[hidden email]>:
>> Comments?
>
> Fine for me.
>
> Maybe we could also maintain a wiki page of previous developers, call
> it Emeritus. Since you have the list of the accounts you will remove
> the first list is easy to create.
> Developers without activity in the last 2 years (or whatever) then
> move from The Team to The Emeritus with the date they changed there
> status.
Added the list to http://www.opensc-project.org/opensc/wiki/ProjectHistory and a link below the list of current commiters on GetInvolved page.

If anyone could double-check that I've not mixed up names or invented them or basically just not messed up, would be nice.

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


_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Active developers on opensc-project.org

Peter Koch-5
Hi Martin!

I'm maintaining the TCOS-driver and the PKCS#15-emulation for german signature cards and some TCOS-based University cards. There was no need to change the driver for about two years, but this doesn't mean that the TCOS-driver is unmaintainted.

I therefore changed the Wiki-tags and removed my entry from the Emeritus list.

Peter

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Active developers on opensc-project.org

Martin Paljak-2
Hello,

On Mar 28, 2010, at 23:29 , Peter Koch wrote:
> I'm maintaining the TCOS-driver and the PKCS#15-emulation for german signature cards and some TCOS-based University cards. There was no need to change the driver for about two years, but this doesn't mean that the TCOS-driver is unmaintainted.
> I therefore changed the Wiki-tags and removed my entry from the Emeritus list.
Great, now it is documented as well!

Maybe you have a suggestion on what to do with this page linked to from GetInvolved (originally "Developers corner" section) [1]:

GermanApi -- Information about new eCardAPI published by German government

The wiki page [2] seems to point to ICAO MRTD related docs which is basically not yet anyway compatible with OpenSC (RFID etc) nor specific to Germany.

If that is the case, would it be OK to rename/remove that page and replace it with a generic MRTD page and/or anything specific to Germany moved to some other page, like GermanEid?

[1] http://www.opensc-project.org/opensc/wiki/GetInvolved
[2] http://www.opensc-project.org/opensc/wiki/GermanApi
--
Martin Paljak
http://martin.paljak.pri.ee
+3725156495

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Active developers on opensc-project.org

Douglas E. Engert
In reply to this post by Peter Koch-5


Peter Koch wrote:
> Hi Martin!
>
> I'm maintaining the TCOS-driver and the PKCS#15-emulation for german
> signature cards and some TCOS-based University cards. There was no need
> to change the driver for about two years, but this doesn't mean that the
> TCOS-driver is unmaintainted.
>
> I therefore changed the Wiki-tags and removed my entry from the Emeritus
> list.

There are also developers who don't commit directly. I am one of them who
has submitted many changes and maintains the PIV card driver. But I send
in changes and Andreas is the one who usually commits them for me.

I suspect that there are many other developers without commit privileges.
I am not asking for commit privileges, IMHO keeping the list small is
a good idea.


>
> Peter
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> opensc-devel mailing list
> [hidden email]
> http://www.opensc-project.org/mailman/listinfo/opensc-devel

--

  Douglas E. Engert  <[hidden email]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Active developers on opensc-project.org

Martin Paljak-2
Hello Douglas,

On Mar 29, 2010, at 17:28 , Douglas E. Engert wrote:
> Peter Koch wrote:
>>
>> I therefore changed the Wiki-tags and removed my entry from the Emeritus
>> list.
>
> There are also developers who don't commit directly. I am one of them who
> has submitted many changes and maintains the PIV card driver.
I know :)

> But I send
> in changes and Andreas is the one who usually commits them for me.
The idea is to keep the gate-keeping tasks that stem from using SVN (and not using something like Git) minimal, until a change for Git/bzr/whatever happens.

> I suspect that there are many other developers without commit privileges.
Probably, but they are not documented anywhere. That's the reason for the Linux style MAINTAINERS file/page (yet to be done) - not everybody likes to have write access but keeping a tab on who's maintaing what would still be required.

> I am not asking for commit privileges, IMHO keeping the list small is
> a good idea.

It is not necessary to keep the list small, it just needs to be maintained and regularly, based on documented and agreed upon criteria, either expanded or shortened. Having a *transparent* and open path for possible new contributors is IMHO a good thing.

The goal is to get more people "to work with" the source code so that small things that people normally don't really care to prepare patches for (unless really necessary for their own task), would also be fixed. The odds are that if you stumble upon a spelling mistake in the docs you fix it on the spot if you can, rather than write about it to the mailing list. Couple it with the "moral obligation to keep a close eye on other commits" (FYI, there are ~30 people following opensc-commits) it should give a better result in the long run. FYI, for quite some time ohloh.com used to say the opposite: https://www.ohloh.net/p/7659/factoids/2829867

That's my intuition at least.

Now, two questions.
1) Should the svn access criteria currently written on http://www.opensc-project.org/opensc/wiki/DevelopmentPolicy#Sourcecodeversioning be changed/improved/modified/removed?
2) Shall you be added to the SVN list or will you/me/somebody else create the skeleton for maintaining the maintainers list in the wiki or ?


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


_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Active developers on opensc-project.org

Andreas Jellinghaus-2
In reply to this post by Martin Paljak-2
disabling access to passive developers is a good thing, as long time
unused and unmaintained accounts are a typical security problem.

but please send a personal email to everyone explaining the situation
and how to proceed, so people don't feel "kicked off" a project, only
because they didn't submit patched for some time.

we still love to get patches, but maybe it is best to send them with
email, works very well for most of the contributors to opensc
(i.e. authors of most drivers etc).

>  Set up something similar to the MAINTAINERS file in
>  Linux kernel, so that the list of actually supported
>  cards/sybsystems/features/whatnot could be verified if necessary and
>  dropped if needed. The list of maintainers must not be equal to the list
>  of commiters but at least have some more data than just "can commit"
>  associated with a name/contact. It will be hard to cover everything that
>  already is in OpenSC but hopefully it will evolve until it really is
>  clear, what is supported and what is dead code.

not sure how well more or less active developers map to a MAINTAINERS
file. but I think it would be good to ask for testing before the next
release from trunk, and then clearly mark all cards without a full test
result as "unsupported", "deprecated" or "incomplete" or something like
that.

a full test result for me is this:
* full regression test suite for blank cards. some failures are ok, if
  they are documted and well known (e.g. pin0002 on starcos cards - nothing
  to worry about)
* at least "pkcs11-tool --test --login" for already initialized cards.
  again some failures are ok (e.g. opensc trying some mechanisms on very
  restricted keys - for example signature cards restricted to few signing
  mechanisms, while opensc tries all mechanisms the card could support
  and doesn't know that this key is more restrictive).

also plattforms should be tested well and the status published -
different versions of operating systems, as well as pre-packaged
binaries. (e.g. i tested ubuntu 10.04 beta recently, and for openct it
will be the first working release as far as I remember).

i.e. if there are no active testers and developers for some plattform,
we should people know, even if opensc is in the ports collection or
something like that. for example debian doesn't upgrade opensc right
now, because it doesn't compile on debian kfreebsd. but we haven't
had any user from that plattform ever, and even for all *BSD I don't
remember any active user.

well, that is my preference at least.

Regards, Andreas
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Active developers on opensc-project.org

Chaskiel Grundman-3
In reply to this post by Martin Paljak-2
I'd already asked to have my commit access revoked, so this change is fine
with me.

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Active developers on opensc-project.org

Andreas Jellinghaus-2
In reply to this post by Douglas E. Engert
Am Montag 29 März 2010 16:28:05 schrieb Douglas E. Engert:
> There are also developers who don't commit directly. I am one of them who
> has submitted many changes and maintains the PIV card driver. But I send
> in changes and Andreas is the one who usually commits them for me.
>
> I suspect that there are many other developers without commit privileges.
> I am not asking for commit privileges, IMHO keeping the list small is
> a good idea.

yes, many developers send in patches via email, and I think that is the
easiest form for many. still I offered write access to many regular
contributors, but in the end sending patches seems to be convenient
for many.

Regards, Andreas
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Active developers on opensc-project.org

Martin Paljak-2
In reply to this post by Andreas Jellinghaus-2
Hello,
On Mar 30, 2010, at 21:14 , Andreas Jellinghaus wrote:
> disabling access to passive developers is a good thing, as long time
> unused and unmaintained accounts are a typical security problem.
This more of a "cleanup" and documentation process than a security process, which is a by-product.

> but please send a personal email to everyone explaining the situation
> and how to proceed, so people don't feel "kicked off" a project, only
> because they didn't submit patched for some time.
OK.  Its not "kicked off", it is a casual "bookkeeping". If somebody feels concerned, 5 days (or 7 or whatever reasonable number) should be enough to read it on the mailing list and voice about/against it, like Peter Koch or Douglas E. Engert.

>> Set up something similar to the MAINTAINERS file in
>> Linux kernel, so that the list of actually supported
>> cards/sybsystems/features/whatnot could be verified if necessary and
>> dropped if needed. The list of maintainers must not be equal to the list
>> of commiters but at least have some more data than just "can commit"
>> associated with a name/contact. It will be hard to cover everything that
>> already is in OpenSC but hopefully it will evolve until it really is
>> clear, what is supported and what is dead code.
>
> not sure how well more or less active developers map to a MAINTAINERS
> file. but I think it would be good to ask for testing before the next
> release from trunk, and then clearly mark all cards without a full test
> result as "unsupported", "deprecated" or "incomplete" or something like
> that.
Good idea. That could maybe be too radical but still useful. Current *documented* cards (i.e. there is something in the wiki) are almost all tagged as well as I remember somebody talking about on the mailing list or just based on hunch. It is still better than nothing.


> a full test result for me is this:
...
> * at least "pkcs11-tool --test --login" for already initialized cards.
>  again some failures are ok (e.g. opensc trying some mechanisms on very
>  restricted keys - for example signature cards restricted to few signing
>  mechanisms, while opensc tries all mechanisms the card could support
>  and doesn't know that this key is more restrictive).
This is more like a smoke test. You get very bogus results and only "test" a single slot. In the end, a real human needs to do a subjective test, if a card (especially a pre-formatted card) works or not, in real life applications (if it matters for that card)

> also plattforms should be tested well and the status published -
> different versions of operating systems, as well as pre-packaged
> binaries. (e.g. i tested ubuntu 10.04 beta recently, and for openct it
> will be the first working release as far as I remember).
Don't know if there are lots of resources for a systematic testing procedures, especially if there are no automated tests that would actually cover systematically more than a few specific use cases.

It would be nice to have a better test suite with different profiles with something like PyKCS11.

> i.e. if there are no active testers and developers for some plattform,
> we should people know, even if opensc is in the ports collection or
> something like that. for example debian doesn't upgrade opensc right
> now, because it doesn't compile on debian kfreebsd. but we haven't
> had any user from that plattform ever, and even for all *BSD I don't
> remember any active user.
If you look at the real distribution of users in the Windows/Mac/Linux/*BSD and  combine it with the general availability or necessity of smart cards, then this is the expected result. Cant beat the statistics.

What should be done, is documenting exactly what we *know* that does not work and vice versa, to the extent that makes sense. Until somebody reports that it does not work on the Debian/kfreebsd, the fact that we don't know if it works is not really relevant.

http://jangosteve.com/post/380926251/no-one-knows-what-theyre-doing is a fun read about the theme.


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

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Active developers on opensc-project.org

Andreas Jellinghaus-2
Am Dienstag 30 März 2010 20:59:58 schrieb Martin Paljak:

> > * at least "pkcs11-tool --test --login" for already initialized cards.
> >  again some failures are ok (e.g. opensc trying some mechanisms on very
> >  restricted keys - for example signature cards restricted to few signing
> >  mechanisms, while opensc tries all mechanisms the card could support
> >  and doesn't know that this key is more restrictive).
>
> This is more like a smoke test. You get very bogus results and only "test"
>  a single slot. In the end, a real human needs to do a subjective test, if
>  a card (especially a pre-formatted card) works or not, in real life
>  applications (if it matters for that card)

well, knowing if there is at least a single person that could run a minimal
test on a card, even that is much better than getting no feedback at all.
and I think we should put a warning sign or at least some sort of hint
on all cards, where we don't get any feedback.

> Don't know if there are lots of resources for a systematic testing
>  procedures, especially if there are no automated tests that would actually
>  cover systematically more than a few specific use cases.

for example web authentication with firefox isn't hard to test - "openssl
s_server" with the right parameters is enough, so every unix/mac user
should be able to test that, given a README, a supported and working
card and some time to follow the steps.

but I don't see how we can automate everything. if people can't spend
half an hour to an hour to help us, there is little we can do. some
support mails to the mailing lists to help someone take that much time
to write....

> > i.e. if there are no active testers and developers for some plattform,
> > we should people know, even if opensc is in the ports collection or
> > something like that. for example debian doesn't upgrade opensc right
> > now, because it doesn't compile on debian kfreebsd. but we haven't
> > had any user from that plattform ever, and even for all *BSD I don't
> > remember any active user.
>
> If you look at the real distribution of users in the Windows/Mac/Linux/*BSD
>  and  combine it with the general availability or necessity of smart cards,
>  then this is the expected result. Cant beat the statistics.

lets say, again we should have some place to let people know what works
(was tested), doesn't work (got bug reports), or is unknown (no active
users / feedback at all).

> What should be done, is documenting exactly what we *know* that does not
>  work and vice versa, to the extent that makes sense. Until somebody
>  reports that it does not work on the Debian/kfreebsd, the fact that we
>  don't know if it works is not really relevant.

for the record: openct on debian kfreebsd doesn't compile. and all the
bugfixes etc. I send in for the debian package will not reach testing or
stable, until someone can have a look (or openct is somehow excluded from
kfreebsd, so it will be available at least on linux).

Regards, Andreas
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Active developers on opensc-project.org

Martin Paljak-2
2010/3/30 Andreas Jellinghaus <[hidden email]>:

> Am Dienstag 30 März 2010 20:59:58 schrieb Martin Paljak:
>> > i.e. if there are no active testers and developers for some plattform,
>> > we should people know, even if opensc is in the ports collection or
>> > something like that. for example debian doesn't upgrade opensc right
>> > now, because it doesn't compile on debian kfreebsd. but we haven't
>> > had any user from that plattform ever, and even for all *BSD I don't
>> > remember any active user.
>>
>> If you look at the real distribution of users in the Windows/Mac/Linux/*BSD
>>  and  combine it with the general availability or necessity of smart cards,
>>  then this is the expected result. Cant beat the statistics.
>
> lets say, again we should have some place to let people know what works
> (was tested), doesn't work (got bug reports), or is unknown (no active
> users / feedback at all).
I see it more like white (known to work) and black (known not to work
or known to work with documented issues) and gray (not
known/obsolete/historic).

The goal is to maintain whitelists and blacklists and to eliminate
gray, by categorizing it either black or white or deleting/retiring.

Going down that road hopefully improves the situation, I'm using tags
to categorize the drivers into
supported/maintained/shouldwork/readonly/unknown/unclear categories.

Why it is IMHO important to give black and white information?
Otherwise it would be the U&D from FUD, which is no good for the
receiver nor for the source of such information. The gray list can
only be kept for a certain time. Seriously - GPK 8K is practically an
extinct card by now.



>> What should be done, is documenting exactly what we *know* that does not
>>  work and vice versa, to the extent that makes sense. Until somebody
>>  reports that it does not work on the Debian/kfreebsd, the fact that we
>>  don't know if it works is not really relevant.
>
> for the record: openct on debian kfreebsd doesn't compile. and all the
> bugfixes etc. I send in for the debian package will not reach testing or
> stable, until someone can have a look (or openct is somehow excluded from
> kfreebsd, so it will be available at least on linux).

OK, this means that for OpenCT it can be written "OpenCT does not
support Debian/kfreebsd" in the FAQ/somewhere.
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Active developers on opensc-project.org

Andreas Jellinghaus-2
Am Dienstag 30 März 2010 21:39:46 schrieb Martin Paljak:
> I see it more like white (known to work) and black (known not to work
> or known to work with documented issues) and gray (not
> known/obsolete/historic).

for example entersafe works, but only with a singe pin,
you can't create more than one or use sopins, as far as I know.

or starcos works, but cards without the test bit can't be deleted.
and the pin0002 test fails on starcos, but that seems harmless.

so there is some grey, not only black and white.

> OK, this means that for OpenCT it can be written "OpenCT does not
> support Debian/kfreebsd" in the FAQ/somewhere.

well, we do have a sys-bsd.c and it should work. I guess only
a tine issue with compiling exists, but there is noone with
time and energy and system to fix that.

and serial drivers should work well of course. ok, nearly noone
uses them any more.

Regards, Andreas
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Active developers on opensc-project.org

Martin Paljak-2
On Apr 2, 2010, at 16:16 , Andreas Jellinghaus wrote:
> Am Dienstag 30 März 2010 21:39:46 schrieb Martin Paljak:
>> I see it more like white (known to work) and black (known not to work
>> or known to work with documented issues) and gray (not
>> known/obsolete/historic).
>
> for example entersafe works, but only with a singe pin,
> you can't create more than one or use sopins, as far as I know.
Entersafe (or Feitian to be precise) has no docs, so it is hard to know what it can or can not support. AFAIK the entersafe *driver* only implements support for a single PIN indeed.


> or starcos works, but cards without the test bit can't be deleted.
> and the pin0002 test fails on starcos, but that seems harmless.
>
> so there is some grey, not only black and white.

OpenSC supports (to some extent) many cards, which all have different features and different capabilities. Usage of those features and capabilities depends on support in OpenSC as well. For example, if feature X is secure messaging and it does not work for card Y, does this make card Y an unsupported card (if it works for 80% of users without SM)?

IMO, what you describe is "release notes" for either software itself or for a specific card. But it is very detailed and exact information, usually in the "black" sector (something is missing from what is commonly known as "full support")

What constitutes full support is subjective and depends on the card and users. Right now, I don't think that taking some kind of technical benchmark or uniform technical test as the basis for evaluating "support" for cards would make much sense. Maybe in the future.

My initial message was that there's no point in listing things we know that we don't know - like nobody knows if OpenSC works on OS/2 for example. We'll find it out when somebody asks about it and reports either success or failure.


>> OK, this means that for OpenCT it can be written "OpenCT does not
>> support Debian/kfreebsd" in the FAQ/somewhere.
>
> well, we do have a sys-bsd.c and it should work. I guess only
> a tine issue with compiling exists, but there is noone with
> time and energy and system to fix that.
> and serial drivers should work well of course. ok, nearly noone
> uses them any more.
Probably this means there is no point in fixing it as there are no users of this combination (Debian/kfreebsd).

As is the case with serial readers - yes they hardware still exists and yes there are reasons to use those devices. But there is no need to actively maintain the support for this combination as there is zero feedback from somebody using those combinations so the time spent implementing the support can be spent on something more useful.


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

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Active developers on opensc-project.org

Jean-Michel Pouré - GOOZE
On Fri, 2010-04-02 at 16:36 +0300, Martin Paljak wrote:
> Entersafe (or Feitian to be precise) has no docs, so it is hard to
> know what it can or can not support.

I asked FEITIAN for the technical documentation and I am waiting for the
answer.
--
                  Jean-Michel Pouré - [hidden email]

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel