Re: Nomination question: Redhat
On Mon, Dec 14, 1998 at 01:13:12AM +0100, Wichert Akkerman wrote:
> > This shows their development strategy is build it first and fast, then
> > secure it. This is bad and I can't safely rely on that sort of
> > development to be secure.
>
> Our big advantage is that our userbase is seems more educated and/or vocal
> in this respect. Most of the times we get our security alerts from others
> (bugtraq, bugreports, etc.). Also since a lot of people use our unstable tree
> these problems tend to get fixed before a release is made. But we still
> have our problems and fiascos in this respect (think netenv and fte). So
> far we have caught the really big ones before a release, but since Debian
> continues to grow and the Security Team can't audit each package this can
> change in the future.
Yes, you're making my point again. People use our unstable dist so these
things are usually found before release. I think your agument about the
security team not being big enough to handle the future is probably an
argument for adding to the security team and done with caution that might
be a good idea.
> > In an open security model, the best way to get a problem fixed is to make
> > the problem well known.
>
> I have never seen RH keeping something secret. In fact as far as I know all
> security problems are fixed in an open way, and the different Linux vendors
> share security information and discuss possible problems quite frequently.
No they aren't secretive about the fixes. Usually you don't hear about
the problems until they are fixed though. This is probably because the
person who finds the bug internally or first hears about it can supply a
fix themselves rather than either NMU'ing or contacting the developer
responsible in Debian's case.
> > Obviously, I wish they would adopt a more open development model which has
> > the system as secure as it can be throughout their development.
>
> They are doing that now by making frequent snapshot releases available,
> something like our unstable tree.
<nod> And a good thing too. I'd rather see their current tree available
as well as just a bunch of snapshots, but I'm not sure if their package
tools are able to update packages quite that easily---don't quote me on
that because I don't know what they have for package front ends these
days. =>
> > I also believe we could and should work with Redhat with big projects
> > such as a sane installation and configuration for X.
>
> So far it seems all distributions stick to their own installation procedures
> and very little cross-fertilizing is being done. Funnily enough I heard
> Erik Troan say during SANE that RH is going to work on their own
> configuration management system, and I've mailed him a while ago to see if
> we can work together on aspects of this (I've yet to hear anything from
> him). That might be a nice testcase to see if we can work together on
> other projects in the future. Please note that we have to be very carefull
> in common projects not to loose sight of our own needs: reducing work
> is fine, but we should not end up with a result that is less then optimal.
I'm not so sure this is a good testcase as it's a rather big project.
FWIW, I tried to coordinate with Redhat on the QPL thing as suggested
here and didn't get a reply either. That I'm not the only one who has
tried to get attention at Redhat to work with them instead of running
around doing our own thing, I'm probably more concerned than I was before
I saw this message. I guess we can hope they are more willing to work
with us in the future. Perhaps there are good reasons neither of us have
gotten an answer, might even be those who would have answered have been
too busy to do so or anything else.
The idea in my head for an X config program is not X-based mostly. It's
more like the Win3.1 setup program than anything, though obviously it has
more and different setup options. The bare bones of it could probably be
put together with dialog and shell scripts just to show the concept.
--
"Shall we play a game?" -- WOPR
Reply to: