I would like to bring this list's attention to the availability of what I believe to be a good non-OpenPGP solution to the problem of cryptographically verifying code.
The OpenBSD community has had very similar discussions internally several years ago, and they resulted in the implementation of a minimal non-OpenPGP signature creation & verification tool called signify, using the NaCl primitives [1]. It has been successfully used for package, release, and advisory signing for several years now, and has been audited both within and without the OpenBSD community. [1]: https://nacl.cr.yp.to/ Its implementation is small enough that some years ago I personally read the whole thing down to libc, (minus the crypto code which came directly from reference implementations from well-regarded cryptographers), and doing so was not a large undertaking. By contrast, I could barely even keep all the state in my head to properly review even the ASN.1 parser which GnuPG must (by nature of OpenPGP) use to parse attacker-controlled input before any pgp-specific data structures can be extracted, before the key can be identified, before it can be used to verify the rest of the data, and then just hope that all other tools parse in the exact same way, and that no later steps ever trust any data that was not previously verified. Current langsec research empirically suggests such constructions are dangerous and should be avoided [2] regardless of how skilled and careful their implementor(s) may be. The popularity of GnuPG among certain communities is irrelevant to discussions of implementation safety. [2]: http://langsec.org/papers/langsec-cwes-secdev2016.pdf For more info on signify, I'd recommend reading it's man page [3], this post by its author [4], this (old) HN discussion [5], and of course also it's source code [6] [7] which is purposefully small and easy to audit (and more importantly, has been!). [3]: http://man.openbsd.org/signify [4]: http://www.tedunangst.com/flak/post/signify [5]: https://news.ycombinator.com/item?id=9708120 [6]: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/signify/ [7]: http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr.bin/signify/signify.c and note also that it is not just some obscure one-off format/tool, but rather has been seen much review and community adoption outside *BSD circles, including several portable versions (with [8] being the best maintained) and several format-compatible independent implementations including a library [9] and slightly extended tool (with the addition of signed metadata) named minisign [10] written by the maintainer of libsodium (the portable version of NaCl). [8]: https://github.com/aperezdc/signify [9]: https://github.com/vstakhov/asignify [10]: https://jedisct1.github.io/minisign/ Side note: an additional pragmatic consideration which also initially motivated the development of signify was OpenBSD's desire to fit the tool in their installer ramdisk's kernel image, and the desire to have public keys of human-manageable length to trivialize distribution and verification by humans. For example, once while at a conference I easily copied down the entire key on a piece of paper from a trusted developer's own trusted piece of paper. And in the interest of full disclosure (because potential bias), I should also note that I used to be the maintainer of the OS X port of signify [11]. [11]: https://github.com/jpouellet/signify-osx -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/CABQWM_Bwkr7fYohqQ39b_nzJ_Mer1gjjj8VGfYRuhSG74Zc8qA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
