Re: Release process (was Re: DarwinPorts 1.3.1)

On Aug 2, 2006, at 9:15 PM, Paul Guyot wrote:

> This is where I disagree. Do you know any package generation project  
> based on library injection and trapping calls?

No, but I know of a lot of them which build each and every package in  
a complete clean-room environment where:

1. For a given OS target (and yes, some support "multiple OS version  
targets"), the relevant files are installed into a clean chroot area.
2. The relevant "port recipe" is installed into the chroot, along with  
whatever minimalist build machinery is necessary.
3. The dependencies that the port depends on (and explicitly lists)  
are installed into the chroot.
4. The build process chroots into this area and builds a package, then  
exits the chroot
5. The resulting package is scooped out and stored, then the chroot  
area is completely destroyed.
6. Go to step 1 for next port.

Now, I know you and I evidently disagree on "how to get the same  
results", and my only reason for continually going back to the chroot  
model and probably seeming as if I'm someone who's just stuck on  
chroot jails vs seeing the benefits of library injection and  
interposition is because of something which is strongly implied in  
these 6 steps:  Trust.  I know that no matter how completely wacky a  
given port is, and I've seen some very wacky unpack/configure/build/ 
install procedures in my time, it will be constrained in some very  
specific ways by having to go through those 6 steps.  I know that the  
OS target is being very carefully controlled (all but the kernel,  
basically, can be accurately specified regardless of the configuration  
of the builder) and I know that the port will absolutely, positively  
not be able to see any dependencies other than those specifically  
provided to it in step 3.

I'm a very strong believer in *extremely* controlled levels of trust  
when it comes to building software in a reproducible fashion, and  
believe me, if the technology was there, I would be strongly  
advocating that we should do the entire thing in a virtual machine  
where you COULD control the kernel and all the system daemons in  
addition to the usual chroot bits.   Now, where we seem to still be  
having a disconnect is where you say:


> Library injection gives enough granularity to be able to  
> independently:
> - detect what the package refers to
> - prevent the package from doing dirty things
> - prevent the package from referring to things

Which sounds like we're saying the same thing - I'm also advocating  
that the package not be able to "refer" to things like /usr/local/ 
include/jpeg.h or /opt/local/bin/myfuzzylanguage at all unless it's  
also been explicitly specified in the Portfile as a dependency.  Yet  
you've said in other messages that you don't want to deny opens (or  
attempts to exec) to either of those things, so now I'm confused.

- Jordan