Re: rkhunter on Etch

[Sam Kuper]

2008/8/29 Andrei Popescu <[EMAIL PROTECTED]>

> Say package foo has a security issue and upstream is at 1.4 and Debian
> still has 1.3. Upstream will most likely release 1.4.1 to fix the issue
> (which could be just a few lines of code) and maybe some others small
> bugfixes that were pending. Debian instead will look for the exact
> change for the security fix and apply it to the 1.3 version. In most
> cases it will not even need adaptation for 1.3 so they can just apply
> the specific patch. However, they will ignore whatever *other* changes
> have happened between 1.3 and 1.4 and also between 1.4 and 1.4.1.
> Unstable will of course get 1.4.1 ASAP.
>
> volatile is suited for packages that change *often* and will become
> unusable unless you upgrade. A good example is an antivirus software and
> its definition files. Even if you upgrade the definitions you also have
> to upgrade the software itself in order for it to detect new viruses.
>
> I'm not sure rkhunter qualifies for volatile, but you should be able to
> find the requirements somewhere on the 'net.
>
> Making backports.org an official Debian service would solve issues like
> this, but I guess manpower is lacking...
>
Thanks for the comments, Andrei. I feel I'm starting to understand much
better how Debian packages are maintained, and when I should consider
backports or non-"stable" packages (i.e. only as a last resort, if the
needed functionality isn't available in stable).

Sam

Re: rkhunter on Etch

[Andrei Popescu]

On Thu,28.Aug.08, 22:27:04, Sam Kuper wrote:
 
[...]

> Okay, so if I understand you correctly, a backport is a kind of refactoring:
> the overt functionality doesn't change, but the underlying functionality
> does (the refactored code is more secure, or less memory intensive, or
> what-have-you depending on the nature of the fix). I hadn't previously quite
> been sure that backports really are intended to *not change the overt
> functionality*.

Say package foo has a security issue and upstream is at 1.4 and Debian 
still has 1.3. Upstream will most likely release 1.4.1 to fix the issue 
(which could be just a few lines of code) and maybe some others small 
bugfixes that were pending. Debian instead will look for the exact 
change for the security fix and apply it to the 1.3 version. In most 
cases it will not even need adaptation for 1.3 so they can just apply 
the specific patch. However, they will ignore whatever *other* changes 
have happened between 1.3 and 1.4 and also between 1.4 and 1.4.1.  
Unstable will of course get 1.4.1 ASAP.
 
> > It looks like your environment requires you to use new features in the
> > latest version of this package so you should just use that package from
> > lenny - mixing one or 2 packages from lenny isn't going to cause any harm.
> >
> This is an interesting suggestion, given that near the start of this thread,
> one of Debian's rkhunter package maintainers recommended against this
> approach, and advised using his unofficial rkhunter backport instead.
> 
> So now I'm confused: which is the better approach for me to take? Also, why
> would a maintainer be maintaining unofficial backports instead of (or as
> well as) official ones?

volatile is suited for packages that change *often* and will become 
unusable unless you upgrade. A good example is an antivirus software and 
its definition files. Even if you upgrade the definitions you also have 
to upgrade the software itself in order for it to detect new viruses.

I'm not sure rkhunter qualifies for volatile, but you should be able to 
find the requirements somewhere on the 'net.

Making backports.org an official Debian service would solve issues like 
this, but I guess manpower is lacking...

Regards,
Andrei
-- 
If you can't explain it simply, you don't understand it well enough.
(Albert Einstein)


signature.asc
Description: Digital signature

Re: rkhunter on Etch

[Tim Edwards]

Johannes Wiedersich wrote:

On 2008-08-29 11:42, Tim Edwards wrote:

Johannes Wiedersich wrote:

On 2008-08-28 10:00, Tim Edwards wrote:
That's new to me. Were did you get this information? IIRC it's a unique
feature of debian (and/or debian based systems) to get security fixes
backported. As an example, see suse's security annnouncements, where
first firefox is updated to version 2.0.0.13 [1] and later to 2.0.0.13

 ^^^
Sorry for the typo, it should read: 2.0.0.15


[2], ie. the fixes are *not* backported to 2.0.0.13.

That's what I mean - they've backported the security/bug updates into
their firefox 2.0.0.13 package, ie. it's still firefox 2.0.0.13 but with
some fixes from 2.0.0.16 (or whatever the latest is) included.


No. In this case it seems they replaced firefox 2.0.0.13 by upstream's
next version. (If they'd fix mozilla's code by themselfs in a similar
fashion as debian, they wouldn't be allowed to call it 'firefox'. This
is the reason why firefox [was|had to be] rebranded to iceweasel in
debian. )


This is taking a patch and applying it to an older version of the
software than it was intended
(http://www.reference.com/search?r=13&q=Backporting) and it's certainly
not unique to Debian. On RPM distros they increment the release number
on the RPM when they do this.

http://www.redhat.com/security/updates/backporting/?sc_cid=3093


From this and [1] and [2] (look at the version number of firefox) I
infer that Redhat *sometimes* employs security backports (if they can't
escape it) and usually just upgrades to the next upstream version.

Debian *always* backports security fixes to its stable release.

Cheers,

Johannes

[1]
https://www.redhat.com/archives/enterprise-watch-list/2008-July/msg2.html
[2]
https://www.redhat.com/archives/enterprise-watch-list/2008-July/msg00017.html



Ok I take your point about Firefox, I have seen some distros (eg. 
Mandriva) do this - just upgrade to the next minor version. But with 
Firefox it's no different to a backport as the minor versions are only 
security/bug fixes, no feature changes. If you have even a quick glance 
over the updates repo vs. the release repos for any of the non-Deb 
distros I mentioned you will see Firefox is definitely the exception to 
the rule.


Also the article I linked definitely doesn't say that Redhat only 
"*sometimes* employs security backports (if they can't escape it)"! It 
says that they sometimes make special exceptions to their *default* 
policy of backporting:
"Whilst on some products our default policy is to backport security 
fixes, we do from time to time provide version updates of some packages 
after careful testing and analysis. These are likely to be packages that 
have no interaction with others, or are used by an end-user (such as a 
web browser)."


Backporting is not unique to Debian, it is the usual behaviour of the 
maintainers of other distros as well, otherwise these distros just 
wouldn't be stable enough production.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: rkhunter on Etch

[Johannes Wiedersich]

On 2008-08-29 11:42, Tim Edwards wrote:
> Johannes Wiedersich wrote:
>> On 2008-08-28 10:00, Tim Edwards wrote:
>> That's new to me. Were did you get this information? IIRC it's a unique
>> feature of debian (and/or debian based systems) to get security fixes
>> backported. As an example, see suse's security annnouncements, where
>> first firefox is updated to version 2.0.0.13 [1] and later to 2.0.0.13
 ^^^
Sorry for the typo, it should read: 2.0.0.15

>> [2], ie. the fixes are *not* backported to 2.0.0.13.
> 
> That's what I mean - they've backported the security/bug updates into
> their firefox 2.0.0.13 package, ie. it's still firefox 2.0.0.13 but with
> some fixes from 2.0.0.16 (or whatever the latest is) included.

No. In this case it seems they replaced firefox 2.0.0.13 by upstream's
next version. (If they'd fix mozilla's code by themselfs in a similar
fashion as debian, they wouldn't be allowed to call it 'firefox'. This
is the reason why firefox [was|had to be] rebranded to iceweasel in
debian. )

> This is taking a patch and applying it to an older version of the
> software than it was intended
> (http://www.reference.com/search?r=13&q=Backporting) and it's certainly
> not unique to Debian. On RPM distros they increment the release number
> on the RPM when they do this.
> 
> http://www.redhat.com/security/updates/backporting/?sc_cid=3093

From this and [1] and [2] (look at the version number of firefox) I
infer that Redhat *sometimes* employs security backports (if they can't
escape it) and usually just upgrades to the next upstream version.

Debian *always* backports security fixes to its stable release.

Cheers,

Johannes

[1]
https://www.redhat.com/archives/enterprise-watch-list/2008-July/msg2.html
[2]
https://www.redhat.com/archives/enterprise-watch-list/2008-July/msg00017.html



signature.asc
Description: OpenPGP digital signature

Re: rkhunter on Etch

[Tim Edwards]

Johannes Wiedersich wrote:

On 2008-08-28 10:00, Tim Edwards wrote:

The way Debian does it this is the same as virtually every other major
Linux distro - Suse/OpenSuse, Redhat, Fedora, Mandriva, Ubuntu etc. That
is they release a new distro version every X months, in Debian-speak
these are called 'stable' releases, and then provide *backported*
security and bug fix updates for however long that version is in
support. These fixes are backported into the version of each package
that was released with the distro to ensure stability - as no new
features are being added the behaviour of the packaged software
shouldn't change. But you still get the benefit of security and bug
fixes so you get both a stable system (as in the behaviour of the
software on it is consistent) and a secure one (up-to-date on all
security patches).


That's new to me. Were did you get this information? IIRC it's a unique
feature of debian (and/or debian based systems) to get security fixes
backported. As an example, see suse's security annnouncements, where
first firefox is updated to version 2.0.0.13 [1] and later to 2.0.0.13
[2], ie. the fixes are *not* backported to 2.0.0.13.


That's what I mean - they've backported the security/bug updates into 
their firefox 2.0.0.13 package, ie. it's still firefox 2.0.0.13 but with 
some fixes from 2.0.0.16 (or whatever the latest is) included.


This is taking a patch and applying it to an older version of the 
software than it was intended 
(http://www.reference.com/search?r=13&q=Backporting) and it's certainly 
not unique to Debian. On RPM distros they increment the release number 
on the RPM when they do this.


http://www.redhat.com/security/updates/backporting/?sc_cid=3093


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: rkhunter on Etch

[Sam Kuper]

2008/8/29 Johannes Wiedersich <[EMAIL PROTECTED]>

> A careful study of 'harden-doc' (install it
> with aptitude) will probably lead to a more secure system than to solely
> rely on one piece of software.

Agreed. I'm planning to use some packages from the hardening suite. The
problem with rkhunter in Etch is that it relies on a script called
hashupd.sh that isn't included in the package, and is not easy to find
online. If rkhunter in Etch was a complete version of rkhunter 1.2.9, I
wouldn't be asking these questions, but it's not.

Thanks for the advice, though,

Sam

Re: rkhunter on Etch

[Sam Kuper]

2008/8/29 Tim Edwards <[EMAIL PROTECTED]>
>
> Probably better to take the maintainer's advice as he knows more about it
> than I do.

Thanks for clearing this up; will do.


> I was just saying that when I've been in this situation, whether on Redhat,
> Debian or other distros I usually take the more updated package from the
> next in-development version of the distro. I haven't had many problems with
> this, but as always YMMV, good luck.

Cheers for this explanation too. If I find any other packages for which I
need newer versions than are in Etch, I'll try using backports or Lenny
packages.

Sam

Re: rkhunter on Etch

[Johannes Wiedersich]

On 2008-08-28 10:00, Tim Edwards wrote:
> The way Debian does it this is the same as virtually every other major
> Linux distro - Suse/OpenSuse, Redhat, Fedora, Mandriva, Ubuntu etc. That
> is they release a new distro version every X months, in Debian-speak
> these are called 'stable' releases, and then provide *backported*
> security and bug fix updates for however long that version is in
> support. These fixes are backported into the version of each package
> that was released with the distro to ensure stability - as no new
> features are being added the behaviour of the packaged software
> shouldn't change. But you still get the benefit of security and bug
> fixes so you get both a stable system (as in the behaviour of the
> software on it is consistent) and a secure one (up-to-date on all
> security patches).

That's new to me. Were did you get this information? IIRC it's a unique
feature of debian (and/or debian based systems) to get security fixes
backported. As an example, see suse's security annnouncements, where
first firefox is updated to version 2.0.0.13 [1] and later to 2.0.0.13
[2], ie. the fixes are *not* backported to 2.0.0.13.

Debian is famous for its stability, especially for servers, so it
shouldn't be questioned as that. People who prefer more regular updates
have either the option to use the unofficial and not so stable and
reliable 'testing' and 'unstable' branches or to switch to other
distros. This is the freedom of the software, debian provides.

Please don't forget that security is a _concept_ not just _one_
particular piece of software installed on your system[*]. I believe that
you will get a really secure system, if you configure and maintain your
'stable' debian responsibly. A slightly outdated version of rkhunter is
of minor importance here. A careful study of 'harden-doc' (install it
with aptitude) will probably lead to a more secure system than to solely
rely on one piece of software.

Just MHO, take care, IANAL nor a security expert,

Johannes

[1] http://www.novell.com/linux/security/advisories/2008_19_firefox.html
[2] http://www.novell.com/linux/security/advisories/2008_34_firefox.html

[*] For obvious reasons, more or less all *vendors* of security 'suites'
that fix some of the shortcomings of the OS with the largest market
capitalisation (in ) will claim the opposite. If it was that simple,
however, there would be much less talk about security problems of that
certain OS than we hear in the media and elsewhere. (But I am drifting
OT...)




signature.asc
Description: OpenPGP digital signature

Re: rkhunter on Etch

[Tim Edwards]

Sam Kuper wrote:



Okay, so if I understand you correctly, a backport is a kind of 
refactoring: the overt functionality doesn't change, but the 
underlying functionality does (the refactored code is more secure, or 
less memory intensive, or what-have-you depending on the nature of the 
fix). I hadn't previously quite been sure that backports really are 
intended to *not change the overt functionality*.


The idea with backporting is you only backport the particular patch 
necessary to close the security hole or fix the bug, not any other 
patches/code changes that have occured since your release version. So 
yes the idea is to make the minimum change necessary to fix the bug, and 
it shouldn't change the functionality of the program.


So now I'm confused: which is the better approach for me to take? 
Also, why would a maintainer be maintaining unofficial backports 
instead of (or as well as) official ones?


With thanks in advance for your advice!

Sam
Probably better to take the maintainer's advice as he knows more about 
it than I do. I was just saying that when I've been in this situation, 
whether on Redhat, Debian or other distros I usually take the more 
updated package from the next in-development version of the distro. I 
haven't had many problems with this, but as always YMMV, good luck.


Tim


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: rkhunter on Etch

[Sam Kuper]

2008/8/28 Tim Edwards <[EMAIL PROTECTED]>

> The way Debian does it this is [...] release a new distro version every X
> months, in Debian-speak these are called 'stable' releases, and then provide
> *backported* security and bug fix updates for however long that version is
> in support. These fixes are backported into the version of each package that
> was released with the distro to ensure stability - as no new features are
> being added the behaviour of the packaged software shouldn't change. But you
> still get the benefit of security and bug fixes so you get both a stable
> system (as in the behaviour of the software on it is consistent) and a
> secure one (up-to-date on all security patches).

Okay, so if I understand you correctly, a backport is a kind of refactoring:
the overt functionality doesn't change, but the underlying functionality
does (the refactored code is more secure, or less memory intensive, or
what-have-you depending on the nature of the fix). I hadn't previously quite
been sure that backports really are intended to *not change the overt
functionality*.

The tradeoff of course is that you don't get the latest versions of every
> package that's just been released. It's alright to think about upgrading one
> package to the latest version but when you have 20,000 or so, all constantly
> changing and on the bleeding-edge version you wouldn't have a very usable
> distro.

Agreed, for the most part. With security packages, I'm less certain. I guess
this is because with security packages, there's a grey area in which what
constitutes a security fix (and therefore will be backported) and what
constitutes a new feature, is disputable. My impression is that perhaps not
everything


> It looks like your environment requires you to use new features in the
> latest version of this package so you should just use that package from
> lenny - mixing one or 2 packages from lenny isn't going to cause any harm.
>
This is an interesting suggestion, given that near the start of this thread,
one of Debian's rkhunter package maintainers recommended against this
approach, and advised using his unofficial rkhunter backport instead.

So now I'm confused: which is the better approach for me to take? Also, why
would a maintainer be maintaining unofficial backports instead of (or as
well as) official ones?

With thanks in advance for your advice!

Sam

Re: rkhunter on Etch

[Tim Edwards]

Sam Kuper wrote:
2008/8/27 Chris Bannister <[EMAIL PROTECTED] 
>:

> On Tue, Aug 26, 2008 at 03:30:37AM +0100, Sam Kuper wrote:
>> (4) Request the Debian Etch rkhunter maintainers to upgrade rkhunter
>> in Etch to version 1.3.2.  If successful, this would 
undoubtedly be the

>> best solution. Dear Micah and Julien, how about it? Sysadmins will
>> love you even more than they do already! :)
>
> Not a chance. Why do you think its called "stable"?

Perhaps naively, I thought it was called "stable" because it was for 
systems that had to be stable, stable in this case meaning reliable. 
To me, this suggests that stable releases should not have the latest 
toys packaged (most people don't need a Mozilla Ubiquity beta on their 
production servers), nor even necessarily the latest utilities, in 
order to minimise potential conflicts between packages. What it should 
have, however, are up-to-date security packages. A rooted server is 
not a stable one: it could be brought down, outside of its sysadmin's 
control, at any minute.


Maybe I was wrong to think that the priority is that the computer on 
which the OS is installed is stable (reliable), and not that the OS 
itself is stable (unchanging).


Furthermore, even on the latter interpretation of the significance of 
calling the release "stable", isn't it the case that Etch still 
includes security fixes? Well, if in order to run rkhunter - a program 
which can be important to maintaining a system's security - a download 
is needed that is no longer available and isn't included in the 
"stable" package, shouldn't that be fixed? I think it should, which is 
why I wrote the email that generated this thread.


The way Debian does it this is the same as virtually every other major 
Linux distro - Suse/OpenSuse, Redhat, Fedora, Mandriva, Ubuntu etc. That 
is they release a new distro version every X months, in Debian-speak 
these are called 'stable' releases, and then provide *backported* 
security and bug fix updates for however long that version is in 
support. These fixes are backported into the version of each package 
that was released with the distro to ensure stability - as no new 
features are being added the behaviour of the packaged software 
shouldn't change. But you still get the benefit of security and bug 
fixes so you get both a stable system (as in the behaviour of the 
software on it is consistent) and a secure one (up-to-date on all 
security patches).


The tradeoff of course is that you don't get the latest versions of 
every package that's just been released. It's alright to think about 
upgrading one package to the latest version but when you have 20,000 or 
so, all constantly changing and on the bleeding-edge version you 
wouldn't have a very usable distro. It looks like your environment 
requires you to use new features in the latest version of this package 
so you should just use that package from lenny - mixing one or 2 
packages from lenny isn't going to cause any harm.


Tim


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: rkhunter on Etch

[Tom Furie]

On Thu, Aug 28, 2008 at 04:01:40AM +0100, Sam Kuper wrote:
> 2008/8/27 Chris Bannister <[EMAIL PROTECTED]>:
> > On Tue, Aug 26, 2008 at 03:30:37AM +0100, Sam Kuper wrote:
> >> (4) Request the Debian Etch rkhunter maintainers to upgrade rkhunter
> >> in Etch to version 1.3.2. If successful, this would undoubtedly be the
> >> best solution. Dear Micah and Julien, how about it? Sysadmins will
> >> love you even more than they do already! :)
> >
> > Not a chance. Why do you think its called "stable"?
> 
> Perhaps naively, I thought it was called "stable" because it was for systems
> that had to be stable, stable in this case meaning reliable. To me, this
> suggests that stable releases should not have the latest toys packaged (most
> people don't need a Mozilla Ubiquity beta on their production servers), nor
> even necessarily the latest utilities, in order to minimise potential
> conflicts between packages. What it should have, however, are up-to-date
> security packages. A rooted server is not a stable one: it could be brought
> down, outside of its sysadmin's control, at any minute.

I'm not familiar with rkhunter, but wouldn't this kind of situation make
it a candidate for volatile?

Cheers,
Tom

-- 
"Out of register space (ugh)"
-- vi


signature.asc
Description: Digital signature

Re: rkhunter on Etch

[Sam Kuper]

2008/8/27 Chris Bannister <[EMAIL PROTECTED]>:
> On Tue, Aug 26, 2008 at 03:30:37AM +0100, Sam Kuper wrote:
>> (4) Request the Debian Etch rkhunter maintainers to upgrade rkhunter
>> in Etch to version 1.3.2. If successful, this would undoubtedly be the
>> best solution. Dear Micah and Julien, how about it? Sysadmins will
>> love you even more than they do already! :)
>
> Not a chance. Why do you think its called "stable"?

Perhaps naively, I thought it was called "stable" because it was for systems
that had to be stable, stable in this case meaning reliable. To me, this
suggests that stable releases should not have the latest toys packaged (most
people don't need a Mozilla Ubiquity beta on their production servers), nor
even necessarily the latest utilities, in order to minimise potential
conflicts between packages. What it should have, however, are up-to-date
security packages. A rooted server is not a stable one: it could be brought
down, outside of its sysadmin's control, at any minute.

Maybe I was wrong to think that the priority is that the computer on which
the OS is installed is stable (reliable), and not that the OS itself is
stable (unchanging).

Furthermore, even on the latter interpretation of the significance of
calling the release "stable", isn't it the case that Etch still includes
security fixes? Well, if in order to run rkhunter - a program which can be
important to maintaining a system's security - a download is needed that is
no longer available and isn't included in the "stable" package, shouldn't
that be fixed? I think it should, which is why I wrote the email that
generated this thread.

That said, if this isn't the Debian way, and/or I'm misunderstanding the
significance, in the Debian context, of the term "stable" (this is quite
possible - in which case, I'd welcome correction), it's not the end of the
world. It'll just mean that pure Etch systems aren't quite as secure as they
could be.

Sam

PS. Hmm, I delayed sending the reply above in order to have some more time
to think about the different kinds of "stability" that are important for
production servers, etc. While I've explained above that I place great store
by the reliability of a computer system, and have emphasised that this can
be aided by updates that add missing security functionality, I've not
examined the merits of the other kind of stability: the kind of stability
that refers to the intentional unchanging or barely-changing nature of the
software on the system. I'll do that a bit more here, to see if I'm
understanding its importance, and the reason there's "not a chance" (see
Chris Bannister above) rkhunter in Etch will be upgraded to 1.3.2.

The reason is: *rkhunter 1.3.2 works differently to 1.2.9. If you have a
script that calls 1.2.9 a particular way, that script may just possibly get
broken by upgrading to rkhunter 1.3.2. This sort of thing could pose a
security risk. Therefore, it's better to keep Etch's rkhunter at 1.2.9 and
only patch it if an exploit in it is discovered.*

Now, I'm not sure I agree with that reason entirely. I think it has merit,
but then so does the alternative approach I raised earlier in this email.
Which has the greater merit? I guess the community's judgement has been that
the "Stable software should change as little as possible" argument beats the
"Stable software should change as much as it needs to to ensure packages
useful for security are up-to-date and usable without requiring external
downloads" one.

And you know what? After this extra reflection, I'm almost convinced that
the community's judgement was correct. With more time, I might become wholly
convinced; we'll see... :)

Chris, thank you for the thought-provoking question.

Sam

Re: rkhunter on Etch

[Chris Bannister]

On Tue, Aug 26, 2008 at 03:30:37AM +0100, Sam Kuper wrote:
> (4) Request the Debian Etch rkhunter maintainers to upgrade rkhunter
> in Etch to version 1.3.2. If successful, this would undoubtedly be the
> best solution. Dear Micah and Julien, how about it? Sysadmins will
> love you even more than they do already! :)
 
Not a chance. Why do you think its called "stable"?

-- 
Chris.
==
I contend that we are both atheists. I just believe in one fewer god
than you do. When you understand why you dismiss all the other
possible gods, you will understand why I dismiss yours.
   -- Sir Stephen Henry Roberts


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: rkhunter on Etch

[Sam Kuper]

Dear Julien,

Thanks for your prompt reply (below). I suppose that as long as I'm
sticking with Etch, I'll have to decide between: option 1; option 3;
or using integrit or suchlike, and not bothering to update rkhunter's
hashes (I wasn't previously aware of integrit, so thanks for the
pointer).

All best,

Sam

2008/8/26 Julien Valroff <[EMAIL PROTECTED]>:
> Hi Sam,
>
> Thanks for your e-mail.
>
> Le mardi 26 août 2008 à 03:30 +0100, Sam Kuper a écrit :
>> Dear Debian users and rkhunter maintainers for Etch,
>>
>> I've been trying to set up rkhunter on my Debian Etch VPS, and I've
>> run into a few problems. (In case it's significant, this VPS is
>> virtualised via OpenVZ; I have root access to the VPS but not the
>> underlying system.)
>>
>> The first problem is this. When I run rkhunter -c, after performing
>> the 'known bad' checks, rkhunter gives the message, "Performing 'known
>> good' check... Info: Check skipped - no hashes available".
>>
>
> This is the default situation, you first have to create the hashes
> database.
>
> [...]
>
> Be sure to understand that rkhunter hashes test is not meant to replace
> more powerful tools, like eg. integrit.
>
>> (1*) Use the version of hashupd.sh at
>> http://rkhunter.cvs.sourceforge.net/rkhunter/hashupd/ . I'm a little
>> nervous about doing this, as it's not the same age as rkhunter 1.2.9
>> and may not be totally compatible. Rootkit detection isn't to be
>> trifled with, so I'd rather not take the risk without assurances from
>> Debian's rkhunter maintainer that this version of hashupd.sh is okay
>> for use with 1.2.9. (NB. I've asked the rkhunter-users list if I can
>> ask for support there for 1.2.9; the answer was: no. See email below.)
>> Micah, Julien, is this version of hashupd.sh okay for use with
>> rkhunter 1.2.9?
>
> Yes, I think so, though not recently tested.
> 1.3.2 has a replacement tool for hashupd.sh embedded in the core
> package.
>
>> (2*) Use the package from Lenny instead. I'm loath to do this. It
>> feels like a slippery slope. I really want to run a pure Debian Stable
>> system if at all possible. But if consensus among users/maintainers is
>> that using the package from Lenny is the best solution to problem 2,
>> I'll be willing to try it.
>
> Not needed
>
>> (3*) Forego the Debian packages altogether; just download the source
>> and build it myself. Well, it's certainly possible. But that would
>> kind of defeat the main reason I chose to run Debian: easy and fast
>> package management and upgrades; minimal compiling necessary.
>
> I supply ***unofficial*** backports of rkhunter package in my personal
> repository at http://packages.kirya.net
> I use these backports on my servers.
>
> This might be the best solution for you is you want to benefit from all
> the improvements of the newer releases.
>
>> (4) Request the Debian Etch rkhunter maintainers to upgrade rkhunter
>> in Etch to version 1.3.2. If successful, this would undoubtedly be the
>> best solution. Dear Micah and Julien, how about it? Sysadmins will
>> love you even more than they do already! :)
>
> Etch is the current stable distribution, hence cannot be updated (except
> for major issues, eg. security fixes).
>
>> Looking forward to your replies,
>>
>> Sam
>>
>> -- Forwarded message --
>> From: Nils Breunese (Lemonbit) <[EMAIL PROTECTED]>
>> Date: 2008/8/25
>> Subject: Re: [Rkhunter-users] Welcome to the "Rkhunter-users" mailing list
>> To: [EMAIL PROTECTED]
>> Sam Kuper wrote:
>> > Q1) The advice page for this mailing list states, "If you are not
>> > running the latest version: please check the website for the latest
>> > version and upgrade first." I use Debian 4 (Etch), which is the
>> > latest stable Debian release. Like most users of Debian stable, I
>> > upgrade by using "apt-get update; apt-get upgrade". Doing this gives
>> > me rkhunter 1.2.9, whereas running "rkhunter --versioncheck" reveals
>> > that the latest release of rkhunter is 1.3.2. I do not want to use
>> > "testing" Debian packages on my server, as I am concerned about
>> > stability. Yet rkhunter 1.2.9 is giving me some problems. My
>> > question is, then: can I expect support from this mailing list for
>> > rkhunter 1.2.9 or must I look elsewhere?
>>
>> rkhunter 1.2.9 is not supported anymore. Contact Debian's package
>> maintainer if you have problems with this old version.
>>
>> > Q2) The advice page for this mailing list states, "Hashupd is on our
>> > download page. Please see the FAQ for details." Actually, it isn't,
>> > and yes, I have checked the online FAQ for an up-to-date link to the
>> > download page, in case I was looking in the wrong place. So, please
>> > could you tell me where I can obtain Hashupd?
>>
>> hashupd was a script for rkhunter 1.2.9. The rkhunter 1.2.9 files are
>> no longer available on the project page, so that's probably why
>> hashupd is also no longer there. The FAQ should be updated, yes.
>>
>
>

Re: rkhunter on Etch

[Julien Valroff]

Hi Sam,

Thanks for your e-mail.

Le mardi 26 août 2008 à 03:30 +0100, Sam Kuper a écrit : 
> Dear Debian users and rkhunter maintainers for Etch,
> 
> I've been trying to set up rkhunter on my Debian Etch VPS, and I've
> run into a few problems. (In case it's significant, this VPS is
> virtualised via OpenVZ; I have root access to the VPS but not the
> underlying system.)
> 
> The first problem is this. When I run rkhunter -c, after performing
> the 'known bad' checks, rkhunter gives the message, "Performing 'known
> good' check... Info: Check skipped - no hashes available".
> 

This is the default situation, you first have to create the hashes
database.

[...]

Be sure to understand that rkhunter hashes test is not meant to replace
more powerful tools, like eg. integrit. 

> (1*) Use the version of hashupd.sh at
> http://rkhunter.cvs.sourceforge.net/rkhunter/hashupd/ . I'm a little
> nervous about doing this, as it's not the same age as rkhunter 1.2.9
> and may not be totally compatible. Rootkit detection isn't to be
> trifled with, so I'd rather not take the risk without assurances from
> Debian's rkhunter maintainer that this version of hashupd.sh is okay
> for use with 1.2.9. (NB. I've asked the rkhunter-users list if I can
> ask for support there for 1.2.9; the answer was: no. See email below.)
> Micah, Julien, is this version of hashupd.sh okay for use with
> rkhunter 1.2.9?

Yes, I think so, though not recently tested.
1.3.2 has a replacement tool for hashupd.sh embedded in the core
package.

> (2*) Use the package from Lenny instead. I'm loath to do this. It
> feels like a slippery slope. I really want to run a pure Debian Stable
> system if at all possible. But if consensus among users/maintainers is
> that using the package from Lenny is the best solution to problem 2,
> I'll be willing to try it.

Not needed

> (3*) Forego the Debian packages altogether; just download the source
> and build it myself. Well, it's certainly possible. But that would
> kind of defeat the main reason I chose to run Debian: easy and fast
> package management and upgrades; minimal compiling necessary.

I supply ***unofficial*** backports of rkhunter package in my personal
repository at http://packages.kirya.net
I use these backports on my servers.

This might be the best solution for you is you want to benefit from all
the improvements of the newer releases.

> (4) Request the Debian Etch rkhunter maintainers to upgrade rkhunter
> in Etch to version 1.3.2. If successful, this would undoubtedly be the
> best solution. Dear Micah and Julien, how about it? Sysadmins will
> love you even more than they do already! :)

Etch is the current stable distribution, hence cannot be updated (except
for major issues, eg. security fixes).

> Looking forward to your replies,
> 
> Sam
> 
> -- Forwarded message --
> From: Nils Breunese (Lemonbit) <[EMAIL PROTECTED]>
> Date: 2008/8/25
> Subject: Re: [Rkhunter-users] Welcome to the "Rkhunter-users" mailing list
> To: [EMAIL PROTECTED]
> Sam Kuper wrote:
> > Q1) The advice page for this mailing list states, "If you are not
> > running the latest version: please check the website for the latest
> > version and upgrade first." I use Debian 4 (Etch), which is the
> > latest stable Debian release. Like most users of Debian stable, I
> > upgrade by using "apt-get update; apt-get upgrade". Doing this gives
> > me rkhunter 1.2.9, whereas running "rkhunter --versioncheck" reveals
> > that the latest release of rkhunter is 1.3.2. I do not want to use
> > "testing" Debian packages on my server, as I am concerned about
> > stability. Yet rkhunter 1.2.9 is giving me some problems. My
> > question is, then: can I expect support from this mailing list for
> > rkhunter 1.2.9 or must I look elsewhere?
> 
> rkhunter 1.2.9 is not supported anymore. Contact Debian's package
> maintainer if you have problems with this old version.
> 
> > Q2) The advice page for this mailing list states, "Hashupd is on our
> > download page. Please see the FAQ for details." Actually, it isn't,
> > and yes, I have checked the online FAQ for an up-to-date link to the
> > download page, in case I was looking in the wrong place. So, please
> > could you tell me where I can obtain Hashupd?
> 
> hashupd was a script for rkhunter 1.2.9. The rkhunter 1.2.9 files are
> no longer available on the project page, so that's probably why
> hashupd is also no longer there. The FAQ should be updated, yes.
> 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

rkhunter on Etch

[Sam Kuper]

Dear Debian users and rkhunter maintainers for Etch,

I've been trying to set up rkhunter on my Debian Etch VPS, and I've
run into a few problems. (In case it's significant, this VPS is
virtualised via OpenVZ; I have root access to the VPS but not the
underlying system.)

The first problem is this. When I run rkhunter -c, after performing
the 'known bad' checks, rkhunter gives the message, "Performing 'known
good' check... Info: Check skipped - no hashes available".

Now, my understanding (from reading rkhunter documentation on the web,
and mailing list posts) is that the solution to this problem is to run
a script called hashupd.sh, which is made available by the rkhunter
developers. However, it turns out that hashupd.sh is not included with
the rkhunter package in Etch. Nor does it have its own package. Nor is
it any longer available on rkhunter's SourceForge download page,
because the latest version of rkhunter (1.3.2) does not require it.
Yet the version of rkhunter available in Etch is 1.2.9, which does
require it.

So in order to solve the first problem ('known good' check being
skipped), I have to solve a second, harder problem, which is: how do I
provide hashes to rkhunter on my server?

I can think of four solutions to this, three of which (starred below)
should not be required, IMHO, for users of a widely adopted, widely
recommended package for a stable OS release. They are:

(1*) Use the version of hashupd.sh at
http://rkhunter.cvs.sourceforge.net/rkhunter/hashupd/ . I'm a little
nervous about doing this, as it's not the same age as rkhunter 1.2.9
and may not be totally compatible. Rootkit detection isn't to be
trifled with, so I'd rather not take the risk without assurances from
Debian's rkhunter maintainer that this version of hashupd.sh is okay
for use with 1.2.9. (NB. I've asked the rkhunter-users list if I can
ask for support there for 1.2.9; the answer was: no. See email below.)
Micah, Julien, is this version of hashupd.sh okay for use with
rkhunter 1.2.9?
(2*) Use the package from Lenny instead. I'm loath to do this. It
feels like a slippery slope. I really want to run a pure Debian Stable
system if at all possible. But if consensus among users/maintainers is
that using the package from Lenny is the best solution to problem 2,
I'll be willing to try it.
(3*) Forego the Debian packages altogether; just download the source
and build it myself. Well, it's certainly possible. But that would
kind of defeat the main reason I chose to run Debian: easy and fast
package management and upgrades; minimal compiling necessary.
(4) Request the Debian Etch rkhunter maintainers to upgrade rkhunter
in Etch to version 1.3.2. If successful, this would undoubtedly be the
best solution. Dear Micah and Julien, how about it? Sysadmins will
love you even more than they do already! :)

Looking forward to your replies,

Sam

-- Forwarded message --
From: Nils Breunese (Lemonbit) <[EMAIL PROTECTED]>
Date: 2008/8/25
Subject: Re: [Rkhunter-users] Welcome to the "Rkhunter-users" mailing list
To: [EMAIL PROTECTED]
Sam Kuper wrote:
> Q1) The advice page for this mailing list states, "If you are not
> running the latest version: please check the website for the latest
> version and upgrade first." I use Debian 4 (Etch), which is the
> latest stable Debian release. Like most users of Debian stable, I
> upgrade by using "apt-get update; apt-get upgrade". Doing this gives
> me rkhunter 1.2.9, whereas running "rkhunter --versioncheck" reveals
> that the latest release of rkhunter is 1.3.2. I do not want to use
> "testing" Debian packages on my server, as I am concerned about
> stability. Yet rkhunter 1.2.9 is giving me some problems. My
> question is, then: can I expect support from this mailing list for
> rkhunter 1.2.9 or must I look elsewhere?

rkhunter 1.2.9 is not supported anymore. Contact Debian's package
maintainer if you have problems with this old version.

> Q2) The advice page for this mailing list states, "Hashupd is on our
> download page. Please see the FAQ for details." Actually, it isn't,
> and yes, I have checked the online FAQ for an up-to-date link to the
> download page, in case I was looking in the wrong place. So, please
> could you tell me where I can obtain Hashupd?

hashupd was a script for rkhunter 1.2.9. The rkhunter 1.2.9 files are
no longer available on the project page, so that's probably why
hashupd is also no longer there. The FAQ should be updated, yes.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]