Re: Any plans to include chkrootkit?
Kyle Wheeler schrieb:
> 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
4. It does not have any security team keeping hands on things.
> None of those are addressed by "volatile" administrators grabbing new
> packages as they come out and proclaiming them sufficient to install on
>> "volatile is not just another place for backports, but should only
>> contain changes to stable programs that are necessary to keep them
> 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.
Thanks for making this clear. I am glad to hear that the security fix is
applied to volatile since people on debian-user-german stated the
opposite and I could not verify it myself.
> 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?
I meant the clamav packages of course but I admit this was not expressed
>> 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?
For me and my bad english it was. Sorry.
> 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.
Now I get the point what volatile is meant for and how things work.
Thanks a lot for clarification.