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

[Elizabeth Ferdman]

On Fri, Dec 09, 2016 at 12:21:58AM -0500, Daniel Kahn Gillmor wrote:
> 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 :)

Hey Daniel, 

Thanks so much for your reply. 
At this point the live disc just has 2.0.26, I think because that's the
default for jessie. Here's the tree for the project:

https://anonscm.debian.org/cgit/collab-maint/make-pgp-clean-room.git/tree/

look at scripts/make-pgpcleanroom. If we want to include 2.1.x we'd need
to put that in there. 
In the wiki for the project under Actions Required, Daniel wrote:
gnupg2 2.1.x into jessie-backports (if feasible)

https://wiki.debian.org/OpenPGP/CleanRoomLiveEnvironment#Packages_to_install

How to modify the sources.list using live build?

As for python-gnupg it doesn't have the options that I need. It doesn't
look like the API includes the --edit-key option. I don't see how I can
add multiple UIDS or multiple subkeys with that api. 

> 
> If are, then please look at the "--quick-addkey" option to gpg. :)
> 
Cool! I'm also seeing --quick-gen-key. that could really simplify
things. Here's the thing though... the
edit-key option still uses a menu. So I'm still going to need to use the
--command-fd option if I'm using bash.

Someone asked how they can automate the creation of a sub-key and Werner
Koch responded with:

gpg --command-fd N --status-fd M --with-colons --key-edit MAINKEY 

and write a state machine to reply on the requests from --status-fd with 
data on --commands-fd. You may also use gpgme's support for this. If 
you need a example, you may want to check out the GPA code. 

http://www.gossamer-threads.com/lists/gnupg/users/67792

Here's a simple example I found online of someone doing this--

echo -e “trust\\n5\\ny\\n” | gpg –command-fd 0 –edit-key 8A581CE7

Something that like that would work for just running the edit key
command to just add some uids and some subkeys, right?

A feature that would be cool in python is
support for all the different ways to use --edit-key since that still
uses the interactive menu. I'm not sure if that's all supported yet I do
see op_edit in core.py
I think PyMe is what you're talking about right?

https://bitbucket.org/malb/pyme

I'm seeing some examples in the source code like genkey.py. That looks
pretty much like what I'm already doing in bash though... Do you think
there's a really compelling reason to use this python library over just
bash for this specific project? At this point I'm only doing the first
time workflow so that one should be pretty simple. 

Thanks!
Liz

> > 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: 473 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pki-clean-room-devel/attachments/20161209/e1e513fc/attachment.sig>