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 attachment 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 attachment 29320 [details] samhain ebuild
Created attachment 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 attachment 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 attachment 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.
