On Thu, May 15, 2003 at 04:22:30AM -0700, David Nusinow wrote: > On Thu, May 15, 2003 at 09:03:06PM +1000, Anthony Towns wrote: > > On Thu, May 15, 2003 at 08:09:48AM +0200, Sven Luther wrote: > > > 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? > > > The fact is, we don't have a security architecture, or even autobuilders > > > for testing, > > Uh, actually, we have both these things. We've had them for almost a year > > now, although they haven't been used. > They're testing-proposed-updates is documented in Section 5.5.2 of the > Developer's Reference, but it says that they should only be used in > case of a freeze. > "You should not upload to testing-proposed-updates when you can update > your packages through unstable." is also a prominent quote from that > section. Nothing specifying security updates, although it does discuss > that these updates require manual intervention. Maybe a specific > reference to managing security updates to testing in this section would > be helpful? It'd finally put it down somewhere where people can point > to, and maybe cut a few of these debates a little shorter. An upload to testing-proposed-updates is not the same as an upload to testing-security, AFAIK (different upload queue, different machinery). But it was my understanding that both were in working order, they just aren't used -- and no one in a position to do so seems enthusiastic about taking on the work of vetting uploads to either queue. -- Steve Langasek postmodern programmer
Attachment:
pgpC4YlOFP34j.pgp
Description: PGP signature