Attached in _text_ is an updated ebuild for cfengine 2.0.8p1. Please note the md5sum of cfengine-2.0.8p1.tar.gz should be: 17f9647edcc955e5c07489a6ac6126b1 I checked against multiple mirrors and verified the md5sum, unfortunately GPG signed sources are not available. Demo
Created attachment 17829 [details] cfengine 2.0.8p1 ebuild
Minor update, see new attachment. Demo
Created attachment 17831 [details] updated ebuild
I know Kurt secretly loves development work...
Created attachment 18282 [details] Updated ebuild, again.
Any dev that can test, After converting Russell's ebuild Attachment #18282 [details] from spaces to tabs I gave it a quick test. It failed for me with some configure errors (perhaps trailing whitepace after \ ). Anyway Its not a pkg I maintain or have ever used so somebody please find a way to get cfengine bumped to a more recent version that does not contain the secuirty problems listed in this advisory. http://packetstormsecurity.nl/0309-advisories/cfengine.txt
Trailing whitespace was the problem. I have successfully run ebuild cfengine-2.0.8_p1.ebuild clean unpack compile 2.0.8_p1 commited to portage as ~arch
changing resolution to TEST-REQUEST
Created attachment 18517 [details, diff] Ebuild fixup, cleanup This fixes some silly things in the ebuild.
Reopening bug, Donnie please commit any changes you feel is needed on cfegnine.
Created attachment 18546 [details] Updated ebuild, including above patch. I've rolled the prior patch into this ebuild, added key generation if a key doesn't already exist. I had to get rid of the rm command, bypassing the make install completely. Comparisons between an old installation vs this new installation show that everything was installed in the proper locations, including the html files now going to the proper directory. Demo
Created attachment 18547 [details] Whitespace fixed. I fixed any whitespace issues I could find. I'm using Emacs in shell mode, which works quite nicely for ebuilds, so I'm uncertain where the whitespace issues may have been. Hence, I removed all leading whitespace / indentation, and reindented for consistency. Demo
Warning from the CFEngine mailing list regarding OpenSSL vulnerability: Date: Tue, 30 Sep 2003 12:42:06 -0400 From: Jeff Wasilko <jeffw@smoe.org> To: help-cfengine@gnu.org Subject: vuln in openssl http://www.uniras.gov.uk/vuls/ ------ See also: http://www.openssl.org/news/secadv_20030930.txt This ebuild should be updated to require OpenSSL 0.9.7c or 0.9.6k when updated ebuilds become available for OpenSSL. Demo
The ebuilds for openssl are in the portage tree now.
minor nit: the cfengine documentation, as well as most other tutorials I've seen place files in /var/cfengine/* instead of /var/lib/cfengine/* Is there a good reason to place things in /var/lib/cfengine? (especially considering that cfengine really has very little to do with libraries...) If not, can we adjust the ebuild to place files in the defacto standard /var/cfengine/*?
From http://www.iu.hio.no/cfengine/confdir/cfexecd.html Some Unices are probably going to insist on changing /var/cfengine to /var/lib/cfengine (Unix is a mess, isn't it?) so let's call the base directory WORKDIR. This is a configurable parameter, which can be set in configure ./configure --with-workdir=WORKDIR ------------------------------------------------------------------------------- Next see http://www.pathname.com/fhs/2.2/fhs-5.1.html Applications must generally not add directories to the top level of /var. Such directories should only be added if they have some system-wide implication, and in consultation with the FHS mailing list. ------------------------------------------------------------------------------- And then http://www.pathname.com/fhs/2.2/fhs-5.8.html This hierarchy holds state information pertaining to an application or the system. State information is data that programs modify while they run, and that pertains to one specific host. Users must never need to modify files in /var/lib to configure a package's operation. State information is generally used to preserve the condition of an application (or a group of inter-related applications) between invocations and between different instances of the same application. State information should generally remain valid after a reboot, should not be logging output, and should not be spooled data. -------------------------------------------------------------------------------- I felt that with the above criteria, that cfengine should use /var/lib/cfengine. It may be beneficial for historical reasons to provide a symlink back to /var/cfengine, or compensate for it in classes. Its a simple change. Also, I'm looking at reworking the make install back into the ebuild, but making modifications to the makefile to fix the documentation installation issue. (I hope the links above work automatically :P ) Demo
"Users must never need to modify files in /var/lib to configure a package's operation." Then cfengine doesn't belong in /var/lib since you have to modify the files in $WORKDIR/input in order for cfengine to function I'm not saying that /var/cfengine complies with FHS, but at the same time, I don't think /var/lib/cfengine does, either. As long as we're going to violate the FHS either way, I'd at least like to put things where most cfengine users will expect them to be :)
Kurt, When all the changes are (done or ready for the masses) with cfengine please make note on this bug so we can have/request that aliz send the GLSA out.
solar -- the stuff we're discussing right now is entirely semantical and shouldn't prevent us issuing a GLSA. I've installed the current ~masked ebuild on two machines and it works fine. We can go ahead and issue the GLSA and worry about semantics later.
Technically, /var/cfengine/inputs are cached config files distributed globally, the admin shouldn't be modifying them directly. Meaning its application specific data that must be preserved between invocations. However I agree on both points, lets violate FHS for compatibility, and please issue the GLSA, there's no reason to hold it up. It works fine as is, the makefile mods are just to fix docs installation. I'll see about making a -r1 version with the makefile updates and the /var/cfengine change. Demo
Created attachment 18630 [details] New -r1 ebuild Updated with makefile fixes, change in symlinking, fixed the key generation, and now using /var/cfengine. Lastly, it requires >=openssl-0.9.6k. Perhaps it'll finally make stable. ;] Demo
committed to cvs ~masked.
marked 2.0.8_p1 as stable pending the release of the GLSA. This ebuild is good enough for now, but I think we may want to look at removing the /var/cfengine/bin/cfagent symlink in a future revision... will close bug when GLSA goes out tomorrow.
GLSAs went out. closing bug. Russell -- would you like to work on an ebuild for 2.1.0 which should be released next week? If so, drop me an email so we can chat about a couple of questions I had wrt the current one.
Created attachment 18796 [details] Updated -r1 This removes useless config options, has better comments, and refines the sed command that edits the makefile. Plz make this the final. Anyone interested in documentation on how to setup cfengine under gentoo, and integrating portage? Demo
Russell, my $0.02 Yes I'd love to see some gentoo style documentation & examples on cfengine. If you were to do it I'd like to request that you do it in .xml so Kurt and or others may post it as an official www.gentoo.org/proj/en/*??*/cfengine.xml
