On 22.10.2009, at 3:08, Peter Stuge wrote: > Andreas Jellinghaus wrote: >>> 2. Keep the main name OpenSC. > > I agree that this is important. OpenSC is a good brand, it makes no > sense not to use it also for the installers. Yes, my main concern here is branding and visibility.
> .. >>> 3. Keep OpenSC core platform-agnostic: > .. >>> OpenSC.tokend lives outside of the (lib)opensc package, so should >>> the possible future MS BaseCSP piece > .. >>> OpenSC *installers* for those platforms, on the other hand, must >>> contain those components. >> >> my opinion on this differs. > .. >> a big fat package with several options inside on the other hand is >> standard for windows: they can pick normal/minimal/everything options > > From the above you actually seem to agree with each other. I also > think this is good. Yes, I think we mean the same thing but describe it a bit differently. Like blind men with an elephant :) Target: slim opensc source package that is cross-platform (does NOT include platform components like Tokend or BaseCSP) and fat OpenSC branded installers that DO contain those components. With an exception, described below. >>> This means getting rid of SCA/SCB, providing OpenSC installers >>> for Mac and Windows and either providing the separate user >>> software as extra downloadables or work with other software >>> providers to add support for OpenSC/PKCS#11. > > What does "separate user software" mean, Martin? For some reason SCA/SCB do not bundle Firefox or Thunderbird. For the same reason we should probably re-consider what is inside the "OpenSC" (re-named from SCA/SCB) named packages. >>> This is way easier if OpenSC declares somewhere what it installs, >>> where and why, > > I agree also with this. The SCA and SCB installers are really a good > thing, basically they just need to be renamed to use the OpenSC > brand, and the installers themselves deserve some documentation as > Martin says; what, where to and why. Not everyone will care, but it's > good for those who do. I think that one of the reasons why "bundling" works is fragility. The smart card setups are fragile because "there is just a single way how things work, this includes hand-building the whole thing and distributing the binary disk snapshot to the user". This is practice. In theory, we should have standard interfaces. OpenSC should provide (and so it does) those standard interfaces, in a documented way (for PKCS#11, it means a documented location) so that other users (other software and its developers) can depend on it and do their things. Instead of providing a stack built against OpenSC (or bundling other "pkcs11 enabled" open source together in a package named OpenSC) we could work with those projects to either provide a "Enable OpenSC" checkbox (not really useful or realistic) or get the original project include the necessary patches-pieces. One example here is OS X and SSH. Instead of building the OpenSSH smart card feature, we should push for Alon's PKCS#11 patch to be included in upstream. This way one day we would not have to deal with the problem at all, as Mac OS X 10.9.7, in year 2013 would include the necessary software :) (Maybe at that time it would already also contain OpenSC.tokend and libopensc...?). Until that time, we should advocate for Alon's PKCS#11 patch, because it is TheRightThing. Maybe also try to push it into Fink/MacPorts, because people who know and want SSH (especially with smart card support) most often want other unix utilities as well. And say on web that "Until OpenSSH adds PKCS#11 support into their source, go get yourself a patched version to use OpenSC". Why Fink/MacPorts? Because OpenSSH+PKCS#11 is generally useful, with and without OpenSC (there are other PKCS#11 providers out there as well!) and we should not, in theory, be a binary publisher of OpenSSH (or Firefox or anything else). But until that happens, we can provide a separate .pkg with OpenSSH+PKCS#11, maybe even include it as an optional install inside a package named OpenSC (which, clearly, it is not really part of) m. -- Martin Paljak http://martin.paljak.pri.ee +372.515.6495 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
