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.
> 
> That's in SVN but not released?

Yes. Anyway, there's several ways to sign packages even if the package format itself doesn't allow it.

You can do detached signatures like here, or checksum all the files once and sign the list of digests.

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

We were talking these formats in length before, so it wasn't rehashed when getting rid of dpkg/xar...

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

Sure, that's a limitation when picking a "good enough" tarball format instead of something like rpm.

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

But archives were already being signed...

Whether the exported packages should be signed or not, depends on whether they are actually going to be used for something ? The only one that is officially used is the MacPorts .pkg package, and that is signed in separate .dmg.asc.

See http://distfiles.macports.org/MacPorts/

But one _could_ add the --sign param to rpmbuild, the "port rpm" target needs a little fixing anyway (the default _topdir is now broken, after the non-root privilege code was added). Will just add another rpm.sign option, to be ignored.

--anders