Am Friday 06 February 2009 20:53:18 schrieben Sie: > Also I discovered for the first time that at least Andreas has some > criticism to some of the work I've committed into OpenSC projects.
Note that there is no pile of things I'm sitting on and bad about or anything. Everytime I thought something would be better done differently, I wrote you about it. I'm sure not very diplomatic, but I'm not holding back when my views how something could and maybe should be done either. > Maybe I truly in a minority and damaging the project. As I wrote to you: I think your work is valuable! It's rather me talking to myself: "I would do that differently" - "But you don't have time to do it" - "ok, so accept how alon does it". also as a general rule, it is important to me to let the one who does something decide how it is done. Not doing anything, but talking something bad is not a good idea, and I'm sorry if it is that way how I am percieved. picking up only a few lines from your long post: > The build system of OpenSC was a mess. I didn't think of it that badly. but it was me who wrote it, and I still think it was better than what we had before. > It did not allow explicit > dependency enforcement, it had a lot of duplicates and unclean > autoconf/automake/libtool usage. > I rewrote the build system and sync it between all of OpenSC > project for simple maintenance. well, the new system is also much more complex due to all the new options for enabling or disabling something. > 5. The mingw build. > The OpenSC project maintained two separate build systems, one > for POSIX and one for Windows. The Windows build was unmaintained > and forced using Microsoft tools. > This caused developers not to check even compilation under Windows, > and resulted in many compilation issues existed for Windows. > autoconf/automake/libtool support Windows build using mingw, so > I made the necessary changes in order to produce Windows binaries > using the maintained build system. Also allowed cross compile to > Windows so that every developer can use free tools and his own > system in order to at least check that the code compiles fine on > Windows. the windows build was maintained for years till last spring. also it featured a gui installer packaging everything a typical users needs into a standard gui installer package. but it used an extra set of makefiles for windows only, and thus double work was required to keep them in sync (which usualy was found out only by me trying to compile it on windows). as I no longer have access to a windows machine and noone else was interested in maintaining opensc&friends on windows, a mingw build is a very good thing to have! note that I don't have any issue with those using microsoft software as their operating system also using microsoft software as there compile and build plattform. the later is available for free (for developing gratis open source applications at least). not sure how anyone could ever debug complex problems on windows (e.g. some application or login with using a CSP and opensc beneth it), but I still guess that a native windows build would make things easier than a mingw build. as SCB maintainer I was asked for debug binaries, but didn't manage to properly build them when I was still working with windows and opensc myself. > 7. OpenCT none root. > I believe security solutions should run in least privileged mode. > Current hotplug services support this easily. > Apparently there are people here that think that least privileged mode > is more dangerous than running all under root... I cannot say > I understand their arguments. I didn't say that. It is most important to understand how a security system works. dissecting things into many small pieces creates complexity, and that additional complexity can lead to security problems, because people didn't understand the new complexity. the "bin" user and group owning all files was such a historical example of a big mistake. also on my system /etc/password is owned by root.root, and I feel much better about that, than if it was passwd.passwd or similar. also I feel ok if all parts on a servers text console used for root to login run as root - even if that includes pcscd or openct. bad if those are exploitable, but also bad if a hacker finds a way to manipulate them. > 8. OpenCT linux coldplug without usbfs. > The only requirement for libusb and usbfs in OpenCT was for the > cold plug process on Linux. > I wrote a simple replacement using sysfs and dropped the dependency. > Now OpenCT can be run without usbfs. openct with libusb and hal worked fine without usbfs, as libusb can enumerate files in /dev/bus/usb as well. or you can use the method to create events in /sys/, thanks I was aware of it, but true: I never implemented it. so you added an implementation for sysfs based cold plugging and removed libusb, is that correct? I still wonder if supporting libusb wouldn't be better, maybe even switching completely to it, so we maybe one day could add mac os X support. but with your new project that idea is obsolete, and I didn't get around implementing it for years anyway. > 9. OpenCT event support. > OpenCT polled the existence of devices, it also polled the existence > of card. > There was a bug in Linux that prevented detecting usb device unplug, > I've worked with upstream in order to fix it, and it was committed in > linux-2.6.27.14, linux-2.6.28.3. thanks! I wonder if there is any project other than openct depending this much on a working hotplug. at least with all those bugs and problems we had over the years with linux kernel, hotplug and udev, I think those people don't test any complex user space software, and as few other people found those problems, I think openct is pretty much alone here. so that was reason at least to me to take the advice and go to the higher level connection between kernel and openct: hal. > In the spirit of cooperation, why not manage this project under the > OpenSC-Project.org umbrella? It will send better message for users. I offered hosting and what it takes for that. either in openct repository or a new repository. > Anyway, we will need at least the following repositories: > 1. libscreader > 2. pcsc-lite or pcsc-screader > 3. screader-driver-ccid > 4. screader-driver-etoken > 5. screader-driver-etoken64 > 6. screader-driver-ifdh > 7. screader-driver-rutoken sure I can create those. send me the final list once you want them created and I will do so. one trac+svn for each of these, like we currently have for all other projects? Regards, Andreas _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
