[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bits from the release team: the plans for etch

On Fri, 14 Oct 2005 00:02:17 -0700, Steve Langasek <vorlon@debian.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
>   libselinux

> 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   <srivasta@debian.org>  <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Reply to: