So many formats, So few packages

[Bayard Bell]

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

> Or just leave the archives with their +PORTFILE as they are,
> and just treat the packages like an exported "lossy" format ?
> The .tbz2.rmd160 should be "good enough" to go, and certainly
> better than blocking the *real* goal of delivering binaries...

Anders,

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.

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.

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.

Cheers,
Bayard


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1515 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20110407/9409a626/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 203 bytes
Desc: This is a digitally signed message part
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20110407/9409a626/attachment-0001.bin>