The priority of selinux packages was changed from optional to standard, fairly shortly before the release of Etch. I propose to revert that change before Lenny. The basic reason is that the selinux packages have basically been unmaintained since the release of Etch. Because of that current SeLinux just cannot be expected to work. An additional reason is that the installation of selinux packages adds significantly to the size of the base system and accounts for a significant part of the time it takes to install the "standard" task, especially on slower architectures. This would be OK if there were real benefits in having SeLinux, but ATM that benefit is just not there. Packages (both tools and policy packages) currently available in unstable and testing are seriously outdated when compared with their upstream versions. This also means that, with the soft freeze for Lenny starting fairly soon, that there is little time left to substantially improve the SeLinux support in Debian, which was one of the arguments for making it standard in the first place. Some facts. Package etch lenny/sid upstream policycoreutils 1.32-3 2.0.16-1 2.0.42 (?) setools 2.4-3 2.4-3 3.3.2 refpolicy 0.0.20070507-5 0.0.20070507-5 20071214 libsepol 1.14-2 2.0.3-1 2.0.20 (?) libselinux 1.32-3 2.0.15-2 2.0.50 (?) None of the packages in Debian has been updated since June/July 2006. There are also some longstanding bugs, including fairly simple packaging errors in Etch, none of which have been addressed. Examples: - #440474: chcat: syntax errors - #405975: semodule_deps and semodule have alignment issues - #427906: postinst: policy package name to deb name, lacks glob support - #438604: selinux-basics: Invalid test for dynamic motd updating - #438706: selinux-doc: Error in doc-base definition - #438887: refpolicy: Spurious "+" causes warnings when building modules None of these bugs has seen any reaction from the package maintainers. I spent quite a bit of time on SeLinux back around September, with the intention of learning more about how it worked and its state in Debian, and to maybe contribute. At that time I filed a few bugs and asked for help with some issues I encountered (as so kindly offered by Manoj during his 2007 Debconf talk), but never received any reaction. In the end I gave up. My experience then was that SeLinux was fairly complex to set up and needed a lot of custom policy tweaks for even basic things to work. I.e, not something that deserves to be installed by default. I have also for some time followed selinux upstream development, and it was very high paced. Not keeping up means getting left _far_ behind and especially for policy it means that tweaks needed for selinux to work well on standard Debian just won't be there. Cheers, FJP
Attachment:
signature.asc
Description: This is a digitally signed message part.