Re: Bits from the release team: the plans for etch
On Fri, 14 Oct 2005 00:02:17 -0700, Steve Langasek <firstname.lastname@example.org> said:
> Pet release goals
> There are a number of other systematic improvements on the drawing
> board for etch which we consider worthwhile even if we don't
> consider them blockers. We would like as many of these goals as
> possible to be met for etch, but by definition they are not
> release-critical. There is a chance that some of these goals may
> become release blockers for etch+1, though.
> The "pet release goals" that we are aware of are:
> - comprehensive SELinux support by building everything with
> Please consider helping us meet these goals, not only in your own
> packages, but also in others' through patches and NMUs.
At this point, most of the major packages that have to be
modified to enable a bare SELinux Debian system are in place, with
coreutils being the last holdout.
Gregory T. Norris has created a set of patches for coreutils,
and the resultant packages, which can be found at
"deb http://people.debian.org/~srivasta/ packages/"
have been use on all my machines, including my production mail
server, for about 6 months now. The corresponding bugs on coreutils
are Bug #312426 and Bug #193328.
id the page which I have been using to track the state of selinux in
Sid, any changes to that are gratefully accepted.
Next, we need to focus on the security policy packages. The
strict policy is pretty limited, and would need extension for the
plethora of packages we have in Debian, and running a selinux box in
permissive mode, and gradually attacking the number of AVC denials
and making policy for the aditional packages is something that shall
take time (but then, this is not a debian specific problem).
Also, the current means of handling changed or new policy
packages is kinda horrid, and really should be replaced by a batch
UCF like handling (asking ucf like questions for each file would be
equally odious). I quite like the way apache module handling is one,
one giant question with check boxes for individual modules.
Unfortunately, I have not had time recently to work on the new
policy package (my new new root_fs refuses to boot with strange libc
errors, even in non-SELinux mode, which I have yet to track down).
When my current situation improves, I hope to be able to help with
the packaging of the policy package.
Each person has the right to take the subway.
Manoj Srivastava <email@example.com> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C