This one time, at band camp, Thomas Bushnell BSG said: > Stephen Gran <sgran@debian.org> writes: > > > What I (and it seems, others) would like to see is: > > 3) some other method to upgrade software that has to change rapidly to > > meet new classes of threats, even though these threats may not affect > > the machine running the software itself. This category seems to me > > to be composed of A/V scanners, anti-spam suites, and IDS-type software. > > I may be missing some, and I'm sure someone will chime in with it. > > What we want with this is a way that is *stable*. If you can't > promise me stability, then I don't want it (or I want it at arm's > length). That is partly why I think it needs to be seperate from security.d.o - see the thread on SA3 for an example. It has API changes, and it takes more horsepower to run. It should not go into security.d.o, and it should not be automatically installed as part of an upgrade for most stable users. However, many organizations running Debian where email is important will want to use SA3 for it's improvements, even if there are some speed bumps. > The backport work is part of the beast here, and "where the archive > lands" or "which team does the work" is only a red-herring. That's > why I kept saying "we have a procedure"--because the problem is not > the absence of an archive, nor the absence of a team; the problem is > an agreed maintenance strategy. Well, the problem is that the procedure that we have is called backports.org, or private repositories. I agree that we also have a lack of an agreed upon maintenance strategy, but I respectfully disagree that we have either a team or an archive at present. I think these types of packages are _not_ security related, or at least not in the sense for which security.d.o has been used in the past. > I would like to see a concrete proposal that is something more than > "we need a place where we can make arbitrary changes to certain > packages in stable." In particular, I would like to see something > like what we have for the existing security maintenance scheme: a > policy that requires backporting and does not simply wholesale include > new upstream versions complete with all the new features--and > bugs--that they may have. While I think that every effort should be made to backport fixes before upgrading the version, I think that in some cases it won't be possible. If an entire scanning engine needs to be rewritten (say to be able to catch variable length markers in random parts of a stream, instead of relying on a single, known length marker anywhere in a stream), then a backport becomes virtually impossible. It may be possible, but it may not be worth it. Thanks, P.S.: Please stop cc'ing me - I read the list. -- ----------------------------------------------------------------- | ,''`. Stephen Gran | | : :' : sgran@debian.org | | `. `' Debian user, admin, and developer | | `- http://www.debian.org | -----------------------------------------------------------------
Attachment:
pgpux8BcrqH0g.pgp
Description: PGP signature