security projects thoughts

[Anders F Björklund]

Bayard Bell wrote:

> I've read back on the threads from March about binary packaging and appreciate better what constraints were accepted to simplify deployment. The signed Macports releases in distfiles that Anders pointed me to is signed with GPG. Given that we're talking about developer tools rather than packaging, is it reasonable to add this to the base requirements for macports? Are people fine with the idea of using PGP with macports and openssl with the packaging system?

I think the main reason for using OpenSSL in base was that
"it is there", instead of having to first install GnuPG...
The library support is also notoriously bad, GPGME doesn't
(make it easy), so most end up just forking gpg(1) instead.

> If you go the GPG route for macports, do you want individual developers signing things with their own keys, or do you want to have a common key, as do the major RPM and apt distros? If the current deployment model is that updates are applied to the SCM and then dumped to the rsync repo and mirrored, do you want something robo-signing what's dumped, or do you want manifests extracted from the SCM that already provide detached signatures? How, in any case, will you manage the keyring used by macports, which presumably would be distinct (e.g. how do you not repeat Debian's key rotation problem)? And how do you publish your keys so that they can be verified?

Yes, yes and yes. Release signing and buildbot signing, both.
I don't think it matters if base/ports use different systems ?

Actually it's packages and archives that are using two versions,
either .dmg and .asc (GnuPG) or .tbz2 and .rmd160 (OpenSSL)...
But the only package that MacPorts officially builds is itself,
even if it's done in a bunch of flavors (for each OS platform).

AFAIK, the archive signing key is included with the distribution
and the package signing key is available on the website/server ?

> What gets signed? Individual ports (Portfile + files, the base)? Manifests? How are signatures packaged (e.g. nested tarballs, as MIT does or something like tarballs with a signed manifest, as Anders suggested for packaging)? Is the impact on the update mechanisms acceptable? Is the objective just to protect ports and the base while they're being shipped around the network, or are other integrity needs? (At least for the initial exercise, limiting the exercise to protecting Portfiles in transit might be enough, while considering some kind of paranoid mode for robo-building down the line that only builds signed ports, such that you don't cause headaches for the considerable number of people who are both porters and Portfile consumers but, to follow your previous analogy, do put meat inspectors inside the sausage factory.)

Note, I think signing compressed content is a lame workaround.
But if it is "good enough" to get it started, then so be it...
The important step is to start actually _making_ something,
instead of just producing (machine readable, but) cookbooks.

--anders


PS. And of course, GnuPG is GPLv3+. So same problem as GCC ?
    Another reason for using something like OpenSSL instead.