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 opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
