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 <[email protected]>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. > > > > >
_______________________________________________ macports-users mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
