Re: conflicts-based solution (was Re: security in testing)
On Thu, May 15, 2003 at 01:13:19PM +1000, Anthony Towns wrote:
> On Wed, May 14, 2003 at 07:12:15PM -0400, Joey Hess wrote:
> > Take the harden package, or create something similar: a package that
> > conflicts with all versions of packages with known security holes.
>
> Why not just /fix/ the holes? Is uploading a package with a well known
> patch _really_ that hard?
Because the resulting package will be built on unstable and may have
dependency problems that will stop it from entering testing for long
times (month ?). sure you can argue that we should then fix the
dependent packages, but this may take time, more time than what is
reasonable for a security update anyway.
The fact is, we don't have a security architecture, or even autobuilders
for testing, and thus fixing the bug is no problem, but getting it in
testing is, and even with an override from the RM this could cause
problem.
A propper solution would be to have an additional build structure, where
you could upload to testing-proposed-updates, or something such, and where
the autobuilder would build these packages in a testing environment, and
which will follow the exact same rules for migration as the
unstable->testing one, except that all dependencies should be always
fullfilled, leaving only architecture rebuild problems.
Sure this is not bullet proof, and maybe it should be monitored to make
sure someone doesn't misuse this to get things in testing, but it would
enable the package maintainers to do RC and security bug fixing in
testing without being held back by this or that library/build-tool
package that just got a new version which will stop anything built with
it to enter testing.
If this works well, it could be possible to extend this for the next
release to have a dual build system, one for library/build-tool stuff,
and the other for the rest of the packages. But then, this is a
discussion for another time.
Friendly,
Sven Luther
Reply to: