Re: [gentoo-hardened] portage hooks/modules (was Ports Security)

[Jan Krueger]

On Friday 05 September 2003 22:47, Ned Ludd wrote:
> On Fri, 2003-09-05 at 16:25, Jan Krueger wrote:
>
> I don't think the idea is bad in anyway at all, yes it will be very time
> consuming and yes a few of us would actually like to use such a thing.
> flawfinder would of been ideal for such a thing as its python based and
> all, but would need some major testing. I'm attaching a small patch for
> your ebuild.sh that should do exactly what your looking for. Note:
> flawfinder must be located in /usr/bin and "flawfinder" must be found in
> your features.
>
> Perhaps you would like to begin/finish coding this feature. :)

Yes. Thank you for your positive feedback, especially the patch.
I felt a little bit lost in /usr/lib/portage. Your words and patch just 
motivated me to go ahead :)

> What I make of all this is sounds like we need need some portage hooks
> for users.
Yes, thats it. Leaves room open for whatever.
Somehow one could see src_compile and the other existing functions as already 
existing hooks, abstracting a little bit. Lets rename "hooks" into "modules"
This would leave a directory, lets say /usr/lib/portage/modules.d, that would 
be very similar to /etc/init.d in fact:
scripts that do something and have dependencies on each other:
src_install.sh:
depend() {
	need src_compile
}
src-compile.sh:
depend() {
	need src_unpack
}
...

flawfinder.sh {
depend() {
	need src_unpack
	before src_compile
}

This would give an before unseen flexibility to ports (just like our machine 
startup-processes differ and still all machines come up (most of them) and 
provide a wide variety of services :) without touching portage itself (as we 
dont touch init)

one could do:
# portage-module add flawfinder need src_unpack before src_compile

and if one doesnt want stripped binaries because he/she loves debugging
# portage-module remove strip

Jan


--
gentoo-hardened@g.o mailing list