Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

At the specified URL you'll find new ebuilds for samhain and fcheck, two
integrity checking
apps (currently not present in portage). The ebuilds have been tested and I am
currently
using them without problems

Please use fcheck-2.07.59.ebuild and samhain-1.8.0.ebuild

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

7 local USE flags and interactive, that's not good.

Well I know that usually that's not good but in this case it's really necessary
and it's the
only way that allow Gentoo users to exploit the features of the samhain app.

It's an integrity checker that includes many way for hiding the process and
contact remotely a server, things like server IP address and other features
_must_ be chosen at
compile time or they are useless (because an intruder can easily subvert them).

This is the only proper way to handle this package I guess.

check robbat2's stuff as he stated on the dev mailing list

Ok, I'm rewriting the ebuild without interactive questions using environment 
variables as the amanda ebuild.  Can I keep the local USE flags? What problems
they cause?  thx

Created an attachment (id=25703) [details]
samhain ebuild proposal

I've attached a new draft of the ebuild, it needs testing but I'm attaching it
anyway for
reference.

BTW what about fcheck ebuild? Looks fine to me.

*** Bug 47783 has been marked as a duplicate of this bug. ***

Created an attachment (id=29320) [details]
samhain ebuild

Created an attachment (id=29953) [details]
new ebuild version

New ebuild, could you please test this and consider adding it to portage?

Notice that samhain with gpg-signing enabled (part of the ebuild USE) requires
a gnupg with TIGER/192 enabled.

This is not supported by the gnupg ebuild - and you get this message when
compiling gnupg with --enable-tiger  | --enable-new-tiger:
***
*** The TIGER/192 digest is in the process of being removed from the
*** OpenPGP standard.  While it hasn't been removed from GnuPG yet, it
*** will be removed in a future version.  For the sake of future
*** compatibility, please do not use this digest.
***

Unless the Samhain people are going to change the alg they use - there will
soon be a problem :(

Until then - the gnupg ebuild should have the --enable-new-tiger &
--enable-tiger USE options added IMHO :)

Spanky,
  This ebuild is pretty ugly.  Would you take a look at it and provide some 
comments?

Thanks,
g2boojum

Here's my thoughts:

I think my preference would be to replace some of the local USE flags with just 
environment variables.  Moreover, this ebuild is currently very "noisy", 
meaning that it provides a lot of info to the user that most users 
are unlikely to want, at least their first time installing the package.
My suggestion would be to put most or all of that info at the top of
the ebuild as comments, and then add an einfo to the end of the ebuild
telling people that reading the ebuild might be a good idea if they
want to enable special features.

I think we should keep the crypt USE flag, but don't bother to build w/ 
a gpg key unless SAMHAIN_KEYFINGERPRINT is set.  The postgres and mysql
USE flags are reasonable, and samhain-stealth can be replaced with 
an "imagemagick" USE flag.

Perhaps keep the local "microstealth" local USE flag, which will tell
the ebuild to use microstealth if SAMHAIN_XOR is set.  If microstealth
is not present then stealth will be used if SAMHAIN_XOR is set.  (Note, 
local USE flags don't need to be prefixed with the package name.)

The samhain-newname USE flag can be replaced by just looking for a 
SAMHAIN_NAME env variable.

Instead of samhain-netconf and samhain-netdb, how about just looking for
a SAMHAIN_SERVER variable and enabling both netconf and netdb?  I might 
suggest always building both the client and the server, but I won't complain
too much if you want "client" and 'server' USE flags.  The 'suidcheck' USE 
flag seems reasonable, too.

Any of that make sense?

ok ... not sure why base-system has this ...

the best person to test/maintain the ebuild would be someone who actually uses it ... that means it's all yours andrea ;)

give me something to test ...

latest is 2.0.2

Created an attachment (id=51517) [details]
samhain-2.0.4 ebuild proposal

I've updated and modified Andrea's ebuild to (hopefully) make it a bit easier
to work with.  I've also taken some of Grant's suggestions into account.

I think this should strike a reasonable balance between the comprehensive
options available for Samhain and the verbosity/complexity of the ebuild. 
Please test and give me your opinions.	I'd definitely like to get this into
portage, as it seems to be a wonderful utility.

Thanks.

After some additional test, I've realized that my first ebuild is broken. 
Please don't use it.  I'll attach a fixed version shortly.

Created an attachment (id=51550) [details]
updated samhain-2.0.4 ebuild

Ok, I fixed the errors in the last ebuild.  Please try this one, it seems to be
working fine for me.

Just FYI: Version 2.0.8 is current: http://la-samhna.de/samhain/s_download.html

Reassigning bug to myself, I'll work on updating and checking the ebuild for
Samhain 2.1.0 and getting it into Portage and then maintaining it, should be
done in a few days, will update once it's in.
Best regards, CHTEKK.

Sorry for the delay, I just added app-forensics/samhain-2.1.1a to the tree, so
have fun with it! ;)
Thanks to Andrea Barisani and Jared Breland for the initial ebuild.
Atm it's not possible to build a static Samhain binary with PostgreSQL or
Prelude support, it just fails during linking... The ebuild blocks those USE
flag combinations, and I'll look deeper into it when I have more time to do so
(if anyone comes up with ideas or patches, just open a new bug or mail me
directly, thanks!).
Closing this now, best regards, CHTEKK.