talkin' 'bout GSoC 2011

Sat Apr 2 16:01:41 PDT 2011

On Mar 29, 2011, at 3:51 PM, Bayard Bell wrote:

> I've been somewhat active on MacPorts previously and am interested in becoming more active via GSoC 2011 in particular.
> [ ... ]

Wow, that was some read, but I think we're on the same wave-length with a lot of the ideas you expressed in your introduction!

For example, I've been whining for (some would say ``championing'') the notion of  supporting direct dependencies in the depot for years, hoping we might be able to someday support the notion of having multiple versions of a given port instantiated simultaneously rather than having everything just collide in a single prefix location, but it's also never been an idea without its own unfortunate pitfalls.  Without filesystem support to synthesize namespaces on a per-process-hierarchy basis during builds, for example, all of the paths need to be called out explicitly at compile/link time (-L/opt/local/var/db/.../somefoopkg -lfoo -L/opt/local/var/db/.../somebarpkg -lbar ... and so on for include paths as well), and at some point the actual maximum length of a process argument list becomes a concern.  I know, ugh.  It also makes upgrading ports somewhat more "interesting" as you have multiple moving parts in the dependency list now and you need to figure out which are "floating" (can be the latest version, possibly allowing an older version to be GC'd) and which are hard dependencies that can never move - all of that generally ends up being driven by additional metadata provided by the port maintainers after much sweat and blood figuring out which combinations work and which don't.  Or they do it once and never look at it again, leading to a lot of old library versions lying around in desperate need of GC'ing.

Of course, if we're just passing the opium pipe here, then we could also imagine a world where the OS provided dynamic filesystem namespace manipulation, allowing us to simply map the dependent packages straight into "/opt/local" (since each package's binaries would see their own view), much in the same way that dyld brings in shared libraries for a process at runtime, and every executable installed by MacPorts would see only its own dependency graph (and nothing more or less) in /opt/local at execution time.  Since the OS does not provide this and we're all out of opium anyway, perhaps the next best thing would be to make /opt/local a MacFUSE mount and start signing binaries such that the FUSE process can figure out how to display a different view based on who's asking.  We're still building castles in the air of course, but it's nice to imagine being able to at least prototype such a thing, just to see if all of the combinatorial flexibility was awesome or, in deployment, a huge pain in the debugger.

Security is another category all its own, and yes, sandboxing is going to become an ever-more important consideration as things evolve.  You've focused mostly on the build-time sandboxing issues in your message, but I don't actually think that's where the real action is going to be.  Going out of our way to secure what should increasingly be a back-room process done behind firewalls on controlled build machines (in order to create binary packages targeted towards end-users) is probably not going to generate much ROI when weighed against the challenges of sandboxing the runtime environment for the packages and/or resulting binaries of "port install" themselves.

I think iOS has the right app delivery and trust model here, as far apart as MacPorts and iOS might currently seem, if anyone in MacPorts is truly interested in thinking that far ahead on future architectural designs.   Putting the Unix (security model) genie back in the bottle might seem a daunting task, and for arbitrary command line tools it may never be resolved (though I have some ideas), but for arbitrary Cocoa apps that day may be getting closer.  Such apps may not constitute the bulk of MacPorts' collection today, but I can also imagine that changing over time.  Just food for thought!

- Jordan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20110402/4f377907/attachment.html>