stable vs. unstable ports?

[Darren Weber]

FYI, running mpab (without any mods) on a mac Pro system:

  Model Name:    Mac Pro
  Model Identifier:    MacPro3,1
  Processor Name:    Quad-Core Intel Xeon
  Processor Speed:    2.8 GHz
  Number Of Processors:    2
  Total Number Of Cores:    8
  L2 Cache (per processor):    12 MB
  Memory:    24 GB
  Bus Speed:    1.6 GHz

It's been running since 11 am, Monday 23rd March, 2009.  It's now:
Fri Mar 27 11:22:21 PDT 2009

The auto-build is currently at:
Building slib-guile (1645 of 5648)...

I don't know how to interrogate the success or failure rates.

Best, Darren


On Thu, Mar 26, 2009 at 8:23 PM, Ryan Schmidt <ryandesign at macports.org>wrote:

> On Mar 26, 2009, at 17:51, Darren Weber wrote:
>
>
>  On Thu, Mar 26, 2009 at 2:09 PM, Dave Howell 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.
>>
>
>
> Libraries and compressed files (which include manpages) tend to differ
> everytime they're built, even if they're functionally the same. So you can't
> just run an md5 checksum over everything and expect it to be the same after
> repeated builds.
>
> I hadn't thought of securing a distributed build system from malicious
> users until Joshua's message, but now I agree that from a security
> standpoint we cannot allow user-uploaded binaries at all. Dave's proposed
> safeguard of requiring n users to upload functionally identical files isn't
> going to help; if a malicious user can upload a bad binary from 1 computer,
> they can borrow n friends' computers and create n throwaway email addresses
> and upload the binary how ever many times we've specified. There are botnets
> out there with thousands of computers that can be commandeered by hackers to
> do whatever.
>
> So let's kill the idea of user-submitted binaries now. We want dedicated
> build servers under the control of the MacPorts project. So let's flesh out
> MPAB into something that can be run on such build servers. Then we can look
> at acquiring the servers.
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-users/attachments/20090327/b87fe831/attachment.html>