Re: Bug#752450: ftp.debian.org: please consider to strongly tighten the validity period of Release files
Russ Allbery writes ("Re: Bug#752450: ftp.debian.org: please consider to strongly tighten the validity period of Release files"):
> Russell Stuart <firstname.lastname@example.org> writes:
> > If there are two "ways" and one requires a human and the other is
> > completely automatic, all other things being equal for me the "right"
> > way is the automated one. I know my limitations - not being
> > conscientious when doing manual repetitive labour is one of them.
> That's a valid point. But I'm not sure that presence of the package in
> the archive is the best trigger here, particularly since there can be
> information in the security advisory that's rather important, such as an
> additional upgrade step that has to be performed. We try to avoid that,
> of course, but it has happened.
That additional step should be encoded in the package, just as we
would for any other additional step that is required for any other
update. (Perhaps a debconf prompt, perhaps by automating it, etc.)
> Also, this means that you completely miss security advisories that *don't*
> involve changing a package in the archive, like "this thing is a disaster,
> so we're pulling it from the archive entirely and suggest you stop using
That's what debian-security-support is for.
> This implies to me that we need some better tool than just triggering off
> of package availability to address these concerns. I personally think the
> concerns are fairly minor and the cost is not worth the benefit, but that
> said, I have often wished debsecan was more generally useful.
> Volunteering to help the security team improve it might be a good path
> forward for someone wanting to work in this area.
DSAs are hopeless for any kind of reliable and systematic approach.
In practice, I'm sure that many many Debian systems, perhaps most, are
maintained on the basis that if the system is up to date vis-a-vis the
security archives, it is up to date.