[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Any plans to include chkrootkit?

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.


Attachment: signature.asc
Description: Digital signature

Reply to: