Re: Proposal for new Security subsection for non-US
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
> 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
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...
To UNSUBSCRIBE, email to firstname.lastname@example.org
with a subject of "unsubscribe". Trouble? Contact email@example.com