So many formats, So few packages

[Jordan K. Hubbard]

On Apr 7, 2011, at 2:46 AM, Anders F Björklund wrote:

> Currently MacPorts has all of these archive formats:
> tar, tgz, tbz, tbz2 (default), tlz, txz, xar, zip, cpio, cpgz
> 
> And all these package formats, both binary and source:
> rpm, srpm, pkg, mpkg, dmg (MacPorts), mdmg, dpkg, xpkg, portpkg
> 
> 
> Shouldn't some of the more useless / unneeded ones,
> like cpio/xar and dpkg/xpkg, be removed from "base" ?
> 
> It's just cluttering up the code, without getting used.
> Wouldn't it be better to pick one or two, and use them ?

Absolutely.  The current de-facto policy of "support everything! (sorta)" is only providing an ongoing distraction from the higher-order goal of creating a manufacturing line where everything gets built regularly and then "published" to a packages collection which end-users can then consume from the command line or a GUI front-end.


Where Mr. Bell and I also seem to be in disagreement is that the current ports "build recipe" system needs all kinds of security added with signing and source tarball verification and so on.  I think that's all value that needs to be added to the "packages collection" side, which is where the great majority of users will be interfacing with the project going forward if all goes well.  Packages should certainly be signed since they are part of the provenance of what the end-user will be consuming (any GUI or CLI utility handling the signature verification and protection against MITM attacks transparently to the user), so whichever package format(s) you pick should obviously support the notion of signing.

Signing the source tarballs, the Portfiles or any part of the "internal build machinery", on the other hand, is a complete waste of time, IMHO, since only the "port maintainers" will gain any benefit from that (and again, in broken record mode, end-users should not have to build stuff!)  and if we can't even trust our build pipeline or the original source tarballs it depends on then it's already game over on a number of levels and we might just as well give up and go home.  Fortunately, the number of attacks on source tarball distribution sites can be counted on one hand and are generally focused on a very limited set of security-focused tools, like OpenSSH.  Such sites also now have detached signatures which could probably be validated in some automated fashion but given that OpenSSH only revs a few times a year, it's probably just as easy for the port maintainer to check the signatures and then compute the checksums once they're satisfied that the real bits are being distributed.  The checksum check should then be "good enough" to make sure that nobody's tampered with the bits afterwards.

Please don't get me wrong:  I'm a big fan of PKI, even with its many shortcomings, but it's not a silver bullet and it takes a fair amount of work to create and maintain the machinery such that attackers aren't able to compromise it and use your own trust validation mechanisms against you (witness the recent Comodo attack).  I think this project has a number of more fundamental challenges to get through before it even really needs to worry about that.  Installing a locked door before you even have the windows installed on the ground floor is kind of pointless from a security standpoint. :-)

- Jordan

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