stable vs. unstable ports?

Darren Weber dweber at macports.org
Thu Mar 26 15:51:32 PDT 2009


On Thu, Mar 26, 2009 at 2:09 PM, Dave Howell
<groups.2009a at grandfenwick.net>wrote:

>
> On Mar 23, 2009, at 0:38 , Ryan Schmidt wrote:
>
>
>> Before we can allow arbitrary users to submit their builds to a central
>> server, we would need to ensure that a build that occurs on one user's
>> system is *identical* to the build on any other user's computer. This cannot
>> currently be assured because MacPorts does not build in a chroot, and
>> without this, it is possible for a port to link with libraries that happen
>> to be on the user's system that it ought not link with -- be they libraries
>> from other ports on which the port in question does not declare a
>> dependency, or libraries in /usr/local, to which the compiler always looks.
>>
>
> Would two "identical builds" be byte-identical? If so, then a binary
> doesn't become available until *two* (or three or whatever) identical
> binaries are uploaded.
>
> And/or, there's some command line library tool (I'm on vacation and my
> reference books are home) that I can run to get a listing of what libraries
> are called by a particular binary, isn't there? Wouldn't that help screen
> wacky-linked binaries?
>
> The deliberate uploading of contaminated binaries, however, is a whole
> different kettle of worms. :/
>
>

I've been running mpab for a few days now, ie:
http://trac.macports.org/wiki/MPAB

This is a chroot approach.  Obviously, as it is, anyone could tinker with it
to include a rootkit or whatever.  Nevertheless, I wonder if it's possible
to create a binary app of this, which is authenticated during installation
(at least), and we ensure that it must do some handshaking to get hold of
the "official" and "secure" port tree somehow (probably an encrypted
handshake, encrypted file archive for download, etc.) and then it goes about
it's business on a user machine and only does an upload (if any) when there
is some kind of further authentication that the port build is correct
(binary md5 etc. for at least 2-5 builds on the exact same configuration).
Even if it does no uploads, it could create useful information about the
stability or integrity (you name it) of the entire build process.  It would
be really neat to have an Xgrid controller (or many) be able to run a job
that can parse out port dependencies and have some kind of parallelism in
the build.

Best, Darren

PS, `man otool` can tell you just about anything you need to know about the
binary file, eg
otool -l /opt/local/bin/gls
otool -L /opt/local/bin/gls
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-users/attachments/20090326/f95d064b/attachment.html>


More information about the macports-users mailing list