Hello Matthew, I'm glad to see others thinking along the same lines. However, precisely because of the nature of the issues surrounding such packages -- the need for frequent updates even when running stable, the fact that this data should *not* be shipped on CDs, the relatively small mirror requirements -- I believe such a repository for definition files could thrive outside of the main Debian archive network. I'm also rather confident that, at least initially, it will be a lot *easier* to implement this outside of the main Debian archive network. Debian is effective at a lot of things, but when you start talking about IDS updates, you really want something a little more flexible and a little less process-laden. ;)
On Sat, Jun 22, 2002 at 03:55:46PM +1200, Matthew Grant wrote: > o Updating vulnerability databases does not work as generally the new > data on the 'Net is no longer compatible with the binaries in stable. > o New versions have new detection algorithms, capabilities, and > methodologies that are needed to deal with current and serious threats. I would hesitate to endorse providing Debian packages for such security software if the binaries themselves really need to be updated that frequently. Where binaries can be provided and managed through the normal unstable->testing->stable system -- complete with security updates from our world-class security team -- I think having asynchronous updates to definiton files is a great boon; but where the programs have to be updated frequently to remain useful, I would argue that the software is simply not mature enough to receive the Debian seal of approval at all. Thus, the responsibilities of the maintainers of such an archive would not be to backport the software to stable, but to backport the definition files to stable. > o It is placed in non-US, as the security scanning software uses > encryption in lots of places. Though I disagree as noted with the premise of providing actual software this way, I'm curious what security scanning software has crypto dependencies? > o We would leave out potato, and start with woody for this section as > woody is very close to release. Definitely agreed on that one. > All of the above combine to make the packages in stable a security risk > if depended on for a site's security, even though they do not make the > machine running the software insecure. Bit rot in this type of software > (IDS tools, Vulnerability scanners, Virus scanners) is in fact a great > cause for concern about security. I would even suggest that once such > software and signature data is out of date, this be logged as a security > bug. Incidentally, in addition to virus signatures, vulnerability scanners, and IDS definitions, I also nominate spam signatures (spamassassin) for inclusion in such an archive. > I am putting this proposal forward for someone else to run with. I have > a lot of commitments to the Linux Aid Server project > (http://www.anathoth.gen.nz) and I have found that I have had to devote > lots of time to getting e-mail virus scanning up to snuff under Debian > for this project. Hence my interest in this to help Debian puul its > socks up with regard to this sort of software. I think it shouldn't be /too/ hard to find other developers interested in working on this... Steve Langasek postmodern programmer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
