[Pki-clean-room-devel] getting started on cleanroom

Fri Dec 9 05:21:58 UTC 2016

Hi Liz et al--

Liz, very happy to see you working on this!  i think i'm already
subscribed to pki-clean-room-devel, so i'm happy to use that for
standard communication here.  Feel free also to write me privately at
dkg at fifthhorseman.net if something comes up that you're not comfortable
sharing on-list (e.g. if you discover potential security flaws in the
underlying tools, or you want to privately discuss plans for dealing
with any technical or social problems that would be sticky on a public
list).

A few more notes below on some technical details:

On Sat 2016-12-03 15:29:15 -0500, Ana C. Custura wrote:
>> Not sure how to create subkeys non-interactively because I don't think
>> you can do --batch with --edit-key. 
>> 
>> The second file is just the helper for creating gpg.conf. 
>
> Looks good. Yes, I'm afraid there is no straightforward way to generate
> subkeys non-interactively as far as I can see --batch can only handle
> one subkey during the automated creation process. 
> On this topic, have a look at:
>
> https://riseup.net/en/gpg-best-practices
> https://pythonhosted.org/python-gnupg/

i assume this project is going to explicitly depend on the "Modern"
suite of GnuPG tools, meaning 2.1.x or later.  This is what will provide
"/usr/bin/gpg" in debian stretch and later, which i think is what a
project like clean-room should be targetting.

If we're not relying on GnuPG's "modern" suite, i'd like to understand
why :)

If are, then please look at the "--quick-addkey" option to gpg. :)

> In particular python-gnupg, might be a good alternative to bash.

I've spent a good part of the last several months trying to triage all
the different ways that external language bindings interact with gpg and
its friends, and i have some good news and some bad news.

The Bad News
------------

The bad news is that the bigger ecosystem here is kind of a mess.  There
are something like a half-dozen attempts at bindings for GnuPG in python
alone, and many more in other programming languages.  These
implementations are of varying quality (there are some with obvious,
heinous security vulnerabilities in even the most simple use cases), and
nearly all of these bindings fail to track changes or new features in
GnuPG upstream, or to support a reasonable complement of GnuPG
functionality, particularly in regards to key management, as i think
you've already found.

In part, this mess is because the GnuPG upstream has never produced a
simple library that incorporates the functionality most developers care
about, preferring instead to expose the suite's functionality via
separate binaries.  Upstream also produces a C library called GpgME that
actually invokes those same binaries as subprocesses.  This is an
unusual arrangement, to say the least.  But various language aficionados
went ahead and wrapped the binaries (and/or libgpgme itself) in
different ways, with varying levels of quality and support.

python-gnupg is an example of a project that wraps the binaries directly
(without using GpgME) and it has had some trouble recently in
tracking/interoperating with the modern GnuPG suite.  See, for example,
https://bitbucket.org/vinay.sajip/python-gnupg/issues/32/add-gpg-21-compability
:(

The Good News
-------------

The good news is that GnuPG upstream has recently started taking this
situation more seriously, and there's a chance that we can clean up
(some of) the mess by focusing their attention on the use cases we
expect developers to care about.  As of 1.8.0 the GpgME package itself
builds a python module named "gpg", and it supports a much fuller
complement of GnuPG functionality than GpgME has ever supported before.
So we've got upstream's committment to a specific python binding, which
is something good! :)

Even better, the GnuPG+GpgME maintainers have publicly stated their
openness to exposing functionality that their users explicitly request.
The clean-room project would be well-positioned to make such a request.
If you find you need something that isn't exposed by gpgme, let them
know!  I'm happy to help you make those requests to upstream, and to
support those requests if there's any pushback from upstream.

If you don't already have an account on the GnuPG upstream bugtracker?

   https://bugs.gnupg.org/gnupg/

If not, you should go ahead and register there, so you're ready to make
feature requests or report problems as needed.  The worst that could
happen is that they turn down your feature requests (but at least then
they do so publicly, hopefully with an explanation).  You might also
want to subscribe to gnupg-devel at gnupg.org if you haven't already:

   https://lists.gnupg.org/mailman/listinfo/gnupg-devel

As with most free software mailing lists, you don't need to read every
message that comes across there, but you should probably get a sense of
who posts there, and what sort of features/bugs are discussed.  Don't
worry if it doesn't all make sense when you first start reading it :)

GpgME 1.8.0 and its produced python3-gpg and python-gpg packages are in
sid/unstable now.  (it should have been in stretch/testing already, but
the migration got hung up on silly technical minutae) It should migrate
to testing in a week or so.

Newer versions of GpgME expose several key management primitives.  look
in /usr/include/gpgme.h for "Key signing interface" and "Key
generation".  That said, i assume you aren't likely to be working in C
directly.

I don't know how much of the GnuPG key management functionality is
exposed in idiomatic python, but it is at least exposed via
e.g. "gpg._gpgme.gpgme_op_adduid".  I suspect that Justus Winter (who is
the lead upstream dev on the GpgME python bindings, and has done a lot
of improvement recently) could be convinced to make that interface more
conveniently pythonic if you just ask for what you want :) If you want
to enhance the python bindings for gpgme yourself and send patches, i
can help you sort out the process for that too.

So if you're programming in python3, i recommend starting by depending
on the python3-gpg package and working in debian sid.  It might be a bit
clunky for you, but (a) it should have the features you need, and (b) if
it doesn't have them in a convenient way for what you want to do, it's a
great opportunity to help improve the underlying libraries for everyone.

Whew, that turned out to be a much longer message than i'd anticipated
writing.  sorry for the length!  Hopefully it's helpful to you.  Feel
free to ask questions or clarifications, or to ask for specific help
with any of these tools.

Regards,

          --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pki-clean-room-devel/attachments/20161209/0bc369b1/attachment.sig>