So many formats, So few packages

[Bayard Bell]

On 7 Apr 2011, at 19:47, Anders F Björklund wrote:

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

That's in SVN but not released?

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

Sorry for any misunderstanding, but it's not entirely self-evident when you reference a file with the extension .ripemd160 that you're talking about MAC rather than an unsigned hash.  As it isn't self-evident, I ought to have clarified before making stronger arguments.

There is, however, still a problem with signing only the distribution archive rather than a manifest within, which is that you can verify content integrity either only before installing and then discarding the archive or by retaining and re-extracting the archive to use for comparison.

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

I'm not arguing against signing (why would I say it's not responsible if that's what I'm advocating? ;->), and I've already sketched the problem with initial key distribution.
-------------- 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/5ea42a4b/attachment-0002.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/5ea42a4b/attachment-0003.bin>