stable vs. unstable ports?

Ryan Schmidt ryandesign at macports.org
Thu Mar 26 20:23:58 PDT 2009


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.






More information about the macports-users mailing list