So many formats, So few packages

[Anders F Björklund]

Bayard Bell wrote:

> At the risk of being a broken record, this doesn't solve MITM, which is a substantial problem in the current architecture. A major difference in the way that package managers with signature support operate when bundled with an OS is that you can assume that key distribution problems are already solved (if someone's picked up an OS distro with compromised keys, that's a different order of problem). Off the top of my head, the easiest way to solve this would be to distribute a package manager that's already an OS X signed binary containing a copy of the basic key material, while only publishing those binaries over https.

Currently we're using /opt/local/etc/macports/pubkeys.conf to define the keys (one .pem per line).

The main key is in /opt/local/share/macports/macports-pubkey.pem - presumably for use with MPAB.

> 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.

The ".rmd160" file is the signature of the ".tbz2" compressed tarball that approximates a "package".

openssl dgst -ripemd160 -sign privkey.pem -out archive.tbz2.rmd160 archive.tbz2

> I'm not happy showing up at this point and having to make these arguments, but it's not responsible to do otherwise, given that most of the risk will be transferred to users.

The issue here is more that the signature is not in the main file, and that it signs compressed data.

Not whether packages should be signed or not, that you seem to be arguing...

--anders