Re: Any plans to include chkrootkit?

[Kyle Wheeler <kyle@memoryhole.net>]

On Sunday, July 10 at 06:06 PM, quoth Christian Schulte:
> Kyle Wheeler schrieb:
> > On Sunday, July 10 at 10:14 AM, quoth Robert S:
> >
> > > Are there any plans to put chkrootkit onto volatile?  I think that 
> > > this would satisfy the criteria for inclusion.
> >
> >
> > What seems increasingly obvious that most people don't seem to get is 
> > that "volatile" does not go scavenge for software it would like to 
> > include. "volatile" is a place where software maintainers (that have 
> > been approved) may place software designed to run on pure-stable.
>
> Please correct me if I am wrong but <http://volatile.debian.net>
> confusingly states the opposite.
>
> [...]
>
> "The main issue of volatile is to allow system administrators to update 
> their systems in a nice, consistent way without getting the drawbacks of 
> using unstable, even without getting the drawback for the selected 
> packages."

Indeed. Now, what are the drawbacks of unstable?

   1. It's *UNSTABLE*
   2. It updates everything very frequently
   3. It frequently depends on very recent versions of libraries

None of those are addressed by "volatile" administrators grabbing new 
packages as they come out and proclaiming them sufficient to install on 
stable.

> [...]
>
> "volatile is not just another place for backports, but should only 
> contain changes to stable programs that are necessary to keep them 
> functional;"

This doesn't contradict my explanation either. This is, essentially, a 
mission statement. Volatile's goal is to allow package maintainers to 
avoid letting their package become irrelevant on debian-stable.

> Here is what happened when I asked on debian-user-german for help with 
> the clamav packages from sarge. I asked for a solution of
>
> LibClamAV Warning: ***  This version of the ClamAV engine is outdated.
>
> People there suggested to use the clamav packages from volatile. I 
> installed these packages and relied on "...without getting the drawbacks 
> of using unstable...". I have apt-listbugs installed and rely on it to 
> display bugs for packages I install. It did not show up any bugs for the 
> clamav packages from volatile although there already was a security 
> update to the clamav packages from sarge which still is not applied to 
> the volatile clamav packages, as I was told. The clamav packages from 
> volatile seem to be "just" backports of the clamav packages from 
> unstable without the same security fixes applied as to the sarge 
> packages, although the website suggests the opposite!

The clamav packages in volatile are version 0.86.1. This version is 
necessary to avoid the warnings about outdated engines that you 
indicated above. It also contains the security fix, though the fix did 
not have to be backported, like the sarge security fix did.

The point is that this is at the behest of the clamav package 
maintainers. THEY put 0.86.1 into volatile.

> > If the chkrootkit developer feels like making sure his package will 
> > install cleanly on sarge/stable, then he can ask to have it included in 
> > volatile. This is what clamav does, for example.
>
> It installs cleanly on sarge and introduces a security problem already 
> fixed in sarge by the security team.

Wait, what? The version in stable is 0.44-2. The version in Unstable is 
0.45-1. There haven't been any security postings about chkrootkit AT ALL 
(http://www.debian.org/security/2005/). What "security problem already 
fixed in sarge by the security team" does 0.45-1 fix?

> You get an updated engine which detects more viruses than the sarge 
> version does however.

Then the chkrootkit developer can post a message here requesting that 
the new version be hosted on the volatile servers.

Is this really that confusing? It works like this:

   1. Maintainer of package X realizes that the debian-stable version 
      of his package no longer works
   2. Maintainer of package X puts together a package that solves the 
      problem and compiles and installs cleanly on debian-stable 
      without dependencies on anything not in debian-stable
   3. Maintainer of package X contacts volatile and says "my package is 
      broken on debian-stable, here's a package that fixes it"
   4. Volatile maintainers decide whether or not to accept it

Unfortunately, users (like us) don't get a say in what goes into 
volatile. What goes in may be a backport, or may be the most recent 
version that links against stable, but that's entirely up to the package 
maintainer. The onus is on the package maintainer to make a "volatile" 
package and submit it to the volatile group. The volatile group does not 
grab unstable packages and turn them into volatile packages.

~Kyle

Attachment: signature.asc
Description: Digital signature