So many formats, So few packages

Jordan K. Hubbard jkh at apple.com
Thu Apr 7 12:50:53 PDT 2011


On Apr 7, 2011, at 11:31 AM, Bayard Bell wrote:

> If you want to ignore this part of the problem definition and not sign your packages, the "real goal" becomes distributing binaries without caring about their integrity or the resulting risk for people using them. If you look around at other contenders in the packaged open source distribution business, that's not where the mark is set.

Actually, the mark is currently set far too low.  Sure, I can go to a number of package "vendors" and suck down packages from them with all kinds of signing machinery involved to make sure that I'm getting the "real Debian package" (for example) from Debian.org, but if that package is actually ill-behaved for reasons completely unrelated to the chain of trust, I'm screwed because of the Unix trust model.  We've seen this numerous times throughout the years:  Somebody compromises the original source tarball to insert a back door, then that gets signed and compiled and shipped (in signed form) to numerous customers and everyone thinks they're all warm and fuzzy and secure until the back door is discovered and then there's a big fire drill to both eradicate the infected bits AND to try and figure out what those bits did to people's systems, the removal of trojans or discovering which data was stolen taking far longer than it did to remove the bad bits.  Sometimes it's not even a deliberate compromise but a coding error which causes the installation or cleanup scripts to go nuts and start removing things they should not (I won't name names, but I've seen that one personally).

If you really care about security then you'll accept that we simply cannot trust software, regardless of its delivery vehicle, and the real action is in damage limitation.  Assuming that everything that runs as my uid is "OK" is simply a busted model since all applications are simply not created equal, regardless of whether or not it's me running them.  To put it another way, the application's UUID is the new uid.  It should be able to screw itself but nothing else, just as a user on a unix system can currently screw themselves but not other users (assuming all the permissions are correct of course).

- Jordan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20110407/230a8b29/attachment.html>


More information about the macports-dev mailing list