On Wednesday 04 February 2009 01:18:40 Martin Paljak wrote: <snip> > If we talk about restructuring or "smoothing" the scene, we should > really figure out some bits and pieces in the big picture and how they > fit/should fit together to find the most rewarding locations to > improve. Even if we revolutionize the low level things but the > goodieness never reaches a news reader so that it could seamlessly > fetch RSS over HTTPS with any reader and any card supported by open > source, maybe it's really not worth it?
Yes it is. You cannot build a building on bad infrastructure.... Examples: People needs OpenCT, so as long as it is used and required, it should be maintained. This consumes resources. Firefox use slot events in order to determine card insert or reader plug in. OpenSC PKCS#11 module needs to detect this without polling. Implementing this for all reader modes is very difficult. The OpenSC plug&play is not working too great,making it work for OpenSC PKCS#11 [wthout polling] forces some changes in the framework core, and in the reader infrastructures. > Mingw and the new build system is really nice but from Windows point > of view, it is a secondary way of building software for Windows. I'm > not telling that the current win32 build system is any good, but under > some circumstances it actually does produce a windows binary. mingw/ > auto*/libtool stack has artificial limitations as well (such as static > linking). The best way is still to go with native tools. Wrong. We already discussed this. You can if you want to remove the libtool usage from Windows PKCS#11 and produce static or any implementation. It has nothing to do with using proprietary (Microsoft) compiler or Open Source compiler. i just don't think it is that important to have a static PKCS#11 module is that important, so I did not invest more time that I did. > > We have much work in OpenSC, mainly remove the one application session > > limitation (stateless mode), > Cards have their own state, applications have their own state, which > can depends on the internal state of the card. The description you > gave to the stateless mode some time ago forgets about pinpads and > would make my pinpad reader beep for every new HTTPS window I open in > Firefox. PIN cache in OpenSC (PKCS#15/PKCS#11 layer) needs to be re- > factored, but you can't build the stateless architecture on the fact > that you can keep a PIN somewhere and re-play it to the card on every > transaction. Keeping the state in sync needs to be worked by every > card driver, as cards have different capabilities and features (some > reset access rights if you change a directory, some don't etc) We already discussed this too. You are not forced to use this, it would be an option. But having a single application locking the reader is unusable for users (if they have multiple applications they need to keep typing their passphrase), and it is none standard as far as PKCS#11 or CAPI is concerned. This is a required feature and one of the major security venerability and usage OpenSC has. Without fixing it, in time there will be no working applications. > > > adding EC as RSA/DSA depreciated. > I don't believe that 4096 RSA will be deprecated in next 2..3 years. > But hell knows, I'm not a cryptanalyst. EC support is 5+ of course. The wisdom is to look into the future, right? > I would not say that OpenSC is in decline, I know for sure that OpenSC > based code is used by (tens of) thousands of people in Estonia alone > and other EU countries as well. Without maintainers it has no effect. > Talking about revolutions - last time it "happened" OpenSC was split > into different packages... It was wise decision. And was not revolution. Just cleanup. I believed that it should be split into more components. For example, the pkcs11-tool should have split. Also the PKCS#11 could have split. Alon. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
