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

Re: Updating scanners and filters in Debian stable (3.1)



[ I'm subscribed, don't CC me please. ]

On Thu, 2004-09-16 at 18:32, Matthew Garrett wrote:
> Wouter Verhelst <wouter@grep.be> wrote:
> 
> > That's not what the security archive is for. Granted, the updates are
> > needed for the security of your system, but that doesn't make it a
> > security update, does it?
> 
> We're always free to alter the way in which the security archive is
> used. The fact that it is currently used in one way doesn't mean that
> that always has to be the case. If we feel that it's important that
> packages like virus checkers get updates pushed out on a regular basis,
> then that may be sufficient to alter the way that we use it. Of course,
> our users would have to be notified.
> 
> That's only one possible solution, though. There are two entirely
> separate issues here:
> 
> 1) Should packages that are likely to become useless over the course of
> a stable release be updated?
> 
> 2) If so, what is the best way to achieve that?
> 
> They're entirely separate arguments. We should think about the first
> without worrying about the second until there's some sort of rough
> conclusion.

It seems to me that there are actually two types of security updates
being discussed here. One is an actual security fix the other is a
resource update to maintain the feasibility of an application.

My suggestion; why not have two different security archives updated at
their own paces[0]? One for security-updates and the other for
security-resources.

Not that my opinion matters all that much to the project (IANADD) I do
feel that, regardless of the implementation of updating the resource
files, this is essential to providing a good base of long term stability
with packages that are certain to age. This ensures they age better[1].

After three months a virus scanner is virtually guaranteed to be out of
date in it's definitions. Having an admin perform ad-hoc updates to
these definitions (and other rule sets) is not a good thing IMHO. This
only promotes the usage of backports, ad-hoc scripting or even worse...
alternate distributions[2] that provide regular security resource
updates.

Just my two-bits for the plate.

~kck

[0] Aside from the time, effort, hardware and bandwidth concerns I can
see no other limiting factors. Again, IANADD so I will claim to know
nothing on this subject.
[1] Sure the applications themselves may grow and learn new abilities
and general feature improvements, however the older packages maintained
by the fantastically-overworked-yet-dedicated-security-team will still
be viable options due to their (as-current-as-reasonably-possible)
security resources.
[2] I haven't done my homework and am not certain that any distro
provides this service however, you cannot deny the appeal factor if
Debian were to do something no other (or only a few) distros do.

-- 
Kevin C. Krinke <kckrinke@opendoorsoftware.com>
Open Door Software Inc.



Reply to: