Re: Debian 3.0r1
On Tue, Jul 30, 2002 at 09:57:31AM +0200, Martin Schulze wrote:
> > Yes, this function could be seperated into a data file, but what are you
> > gaining by seperating it? A user could break amavis just be replacing
> > it with a bad version, just the same as a user could break amavis be
> > installing a broken version of the deb package from stable.
>
> The more you say, the more I realize that amavis is not suited for
> stable. I would be glad if you could take the proper steps to preserve
> it's inclusion in the next stable release.
It is also possible that I overstated my concerns in the preivous
paragraph too, I strongly suspect that part of the code isn't updated
frequently by upstream either. I think a lot of people would get very
upset if amavis had to be removed from stable just for this reason.
Should you ban Linux (or one of the many firewall products) from stable,
just because in the future (or past) somebody might discover some
security hole that either prevents the firewall from filtering packets
it is meant to to doesn't allow packets through that it is meant to,
because of some gross hack (there probably isn't any, but assume there
is) in the relevant code? I think not; the code is obviously still
useful to many people regardless, but this doesn't mean you shouldn't
upgrade either (assuming this even effects you, it might not).
However, you are missing the points I am making:
1. Just because some packages don't have any obvious security holes, or
any security holes that have an obvious danger to the local computer, if
you don't upgrade them, you run the risk of compromising security on the
network as a whole. I have bought up examples with packages that I know
and use, I am sure there must be examples with packages that I don't
know and don't use.
2. Just because a program is changed, doesn't mean it is going to break;
Even if it does break that one program, this is Linux, not Windows, and
it is unlikely it will break the rest of the operating system. (Note:
I am not talking about major upgrades to libc or any other library or
shared program here; that is quite a different story; In fact, you could
probably limit this discussion to optional or extra packages).
3. Sometimes I suspect packages get more testing when in stable then in
unstable...
However, this discussion is seems pointless, it might be better just to
fork the Debian archive and create another archive for security updates
in it that do not meet Debians strict criteria for security updates...
--
Brian May <bam@debian.org>
Reply to: