talkin' 'bout GSoC 2011

[Rainer Müller]

Hello Bayard,

On 2011-03-30 00:51 , Bayard Bell wrote:
> I've been somewhat active on MacPorts previously and am interested in
> becoming more active via GSoC 2011 in particular.

thanks for you interest in MacPorts!

> My interests in macports are pretty diverse, so I'll start with some
> more blue sky ideas I have based on previous experience. I'd like to see
> macports become a more distributed system with broader capabilities
> across the development lifecycle (e.g. able to do automated building and
> testing, able to build and distribute packages, or to provide builds
> software for running off of network storage). 

What exactly would be required to do automated building in MacPorts
itself? For example we have MPAB which wraps around port to implement
automated building.

> I'd like to see a profile,
> test, fingerprint, and, sign implementation to provide more robust
> comparisons between builds or even update decisions (e.g. I built on
> this platform, with these deveopment tools, against a code base with
> this signature, using these parameters, got binaries with
> platform/section signatures that look like this, had dependencies that
> look like this, ran the following test suite, and got the following
> results; deploy the latest version of X as soon as test suite Y is
> published under Z's signature; if I build using these parameters vs.
> these parameters, I can see that the changes look like this and limit
> test coverage accordingly; if I rebuild from scratch, I can confirm that
> I get identical results; I built this port just like someone else but
> have dependencies that are built differently, which may explain why
> things don't work the same).

Where would signatures and test results be published?
Who writes the test suites and how do you run them?

> I'd like to see the namespace support more
> strict dependency information (e.g. rather than using -L /opt/local/lib
> and -I /opt/local/include, I'd prefer to see something closer to -L
> /opt/local/var/macports/software/db48/4.8.30_0/lib, etc.,

So as soon as I upgrade to db48 @4.8.30_1 dependents will break?

> [...]

> I kinda think security's going to be a profound problem for macports as
> long as so many commands are run as root under sudo, and the Portfiles
> are scripts rather than configuration files per se, running without in
> any kind of sandbox or sanitisation.

Yes, a lot of things rely on review here. Trace mode is intended to
limit and detect file accesses, but currently it's used as a development
tool for maintainers only.

> Also on the topic of security: as I see it, pretty much the only place
> that root is consistently needed is for the install step (as opposed to
> fetch, extract, configure, build, etc.), but the way the system
> currently works, people use it as root most of the time. Other than
> that, running the code as a non-privileged user, who would own most of
> the filesystem data, seems far more sane, and running client-server
> might allow much more of the current start-up time to be passed along to
> the server, making the client a lot snappier.

On trunk, MacPorts drops privileges to nobody if root permissions are
not required. On 1.9 the functionality is in place, but not used by default.

> Maybe I'm missing something with these conclusions, but it seems to me
> that the current system has been designed with a strong bias to ease of
> maintenance and use and not a lot of consideration for security. I've
> been using the system with much higher expectations of security, and
> it's only when I've spent some time with the code recently that I've
> come to appreciate how considerable the gap is from those expectations.
> 
> As far as interest in listed projects

Of course you are not limited to the listed projects, you can also
propose something else if you find it more important or are more
confident to work on that.

> [...]
> If providing additional ports is work that
> could be considered part of an application, those are things I'd be
> happy to bring to the table (and want to sort out in any case).

I think adding new ports could probably be done as part of the bonding
period as a way to get to know the MacPorts system and tools.

> [...]

> Anyway, hello, and, I hope this gives us some topics for further
> conversation.

Hello and welcome :-)

Rainer