[Pkg-gnupg-maint] BoF report back and transcript

Sat Aug 30 02:47:22 UTC 2014

hi all--

we had a productive and friendly conversation about gnupg packaging [0]
a few days ago here at Debconf 14 in Portland, Oregon, USA.

I'm attaching the gobby document that we created, and a transcript of
the gobby chat log as well, for people to read.

You might also be interested in the video of the session [1].

Among the many decisions we came to:

 * We will move gnupg2 under the umbrella of the pkg-gnupg team, and
Eric Dorland will join us.

 * We'll be moving the GnuPG (and related) packaging to git

 * We're looking at trying to get the latest GnuPG 2.1 beta into debian
experimental

 * We'd like to try to adopt /etc/alternatives for gnupg and related
tools, so that local administrators can switch gpg between the 1.4 and
2.0 branch

 * current gnupg2 packaging is too heavily-focused on graphical pinentry
tools, and pulls in too many dependencies; we'll try to get the
graphical environments themselves to pull in their own pinentry
mechanisms, and slim down the gnupg2 dependencies to a minimal pinentry
implementation.

 * we're willing to diverge from upstream defaults (though we will
continue to try to push for preferred defaults upstream first).

more reports soon, hopefully,

	--dkg

[0] https://summit.debconf.org/debconf14/meeting/69/gnupg-in-debian-bof/
[1]
http://meetings-archive.debian.net/pub/debian-meetings/2014/debconf14/webm/GnuPG_in_Debian_BoF.webm
-------------- next part --------------
[08/25/2014 11:37:01 AM] <hlieberman> I apologize in advance for my terrible misspellings.
[08/25/2014 11:37:27 AM] * tim apologises for his pedantry.
[08/25/2014 11:44:39 AM] <alexm> hlieberman: don't worry, you're doing a great job
[08/25/2014 11:47:19 AM] <tim> Yeah, it's more important to get the bulk of it down quickly.
[10:58:44 AM] <josh> Is it OK to add proposed discussion topics directly?
[10:59:18 AM] <dkg> yes, please
[11:02:39 AM] <thijs> re
[11:10:43 AM] <pkern> alternatives → two transitions: one to it, one away from it. Only if it buys us a lot because the differences are largeish. Especially iff gnupg1 is already kind of crufty. ;-)
[11:12:08 AM] <pkern> d-i has a udeb, so you can select what version you ship there anyway.
[11:12:11 AM] <pkern> Regardless of alternatives.
[11:12:16 AM] <thijs> is it known if gnupg2 is significantly larger than gnupg?
[11:12:24 AM] <thijs> also we'll need the gpgv tool
[11:12:27 AM] <josh> What about software that specifically wants to use gpg2?
[11:12:44 AM] <josh> Alternatives will break anything that wants to call "gpg" and use gpg2 features.
[11:13:22 AM] <wouter> oh, we're chatting here? I was chatting on the IRC channel
[11:13:23 AM] <pkern> Dependencies need to be packaged as udebs for d-i, fwiw.
[11:13:26 AM] * wouter finds this somewhat confusing
[11:14:14 AM] <wouter> josh: I think such applications should not use the "gpg" binary, they should call the "gpg2" binary instead
[11:14:32 AM] <josh> wouter: Which will work just fine in Debian, but what about software written for the rest of the world?
[11:14:47 AM] <josh> Will other systems even have a binary named "gpg2", or will they just install gpg2 as gpg?
[11:14:54 AM] <pkern> gpg2 also sometimes complains about gnome-keyring taking over the agent.
[11:15:03 AM] <wouter> josh: if they're packaged for Debian, the maintainer will have work to do. If they're not, then the sysadmin will need to ensure that "gpg" is gpg2 for things to work.
[11:15:20 AM] <wouter> I don't think that's something we need to worry about
[11:15:24 AM] <Clint> josh: fedora and gentoo have been using gpg2 for quite some time
[11:15:48 AM] <josh> wouter: The latter is the same problem we have with things like python or gcc, which we pointedly *don't* use alternatives for.
[11:16:06 AM] <josh> wouter: As for the former: can we *not* create a permanent divergence from upstream, please?
[11:16:52 AM] <josh> Clint: How do they install it, and do they have a /usr/bin/gpg?
[11:18:08 AM] <josh> Regarding splits: that's already in place, you can install a different pinentry.
[11:18:25 AM] <Clint> josh: not sure about fedora, but /usr/bin/gpg is supposed to be gpg 2 on gentoo
[11:18:39 AM] <josh> Clint: Right.
[11:18:42 AM] <ijackson> If I ask for   apt-get install pinentry-curses gnupg2   it "only" wants 30.8Mby
[11:19:05 AM] <josh> ijackson: 30MB seems pretty reasonable for gnupg2.  (Also, I assume you already have curses bits installed?)
[11:19:17 AM] <josh> ijackson: What's the package list?
[11:19:30 AM] <ijackson> No, I don't, this is my build chroot.  It has build-essential but not much else.
[11:19:33 AM] <josh> Ah.
[11:19:44 AM] <josh> ijackson: So 30MB taking into account that a fair bit of that is ncurses.
[11:19:57 AM] <thijs> definitely not said that :)
[11:20:09 AM] <ijackson> http://paste.debian.net/117706/   <- list of packages
[11:20:14 AM] <thijs> I'm very open to changing vcs
[11:20:29 AM] <thijs> move it, please
[11:20:41 AM] <thijs> yes
[11:21:14 AM] <josh> ijackson: Gah, curl pulls in krb5.
[11:21:20 AM] <josh> ijackson: That seems wrong.
[11:21:20 AM] <ijackson> Why do we have libgnutls _and_ nettle _and_ openssl ?!
[11:22:00 AM] <thijs> Because Debian is about choice!!1!
[11:22:01 AM] <Clint> to maximize government-sponsored backdoors
[11:22:20 AM] <josh> ijackson: Some of the folks in Fedora / Red Hat are working to unify around a single crypto library.  Perhaps we could make sure that work is upstream and start using it?
[11:22:26 AM] <josh> ijackson: IIRC they're unifying around NSS.
[11:22:38 AM] <ijackson> 30Mby is still too much IMO.  gnupg (1) has only itself and   Installed-Size: 5155
[11:22:41 AM] <josh> ijackson: (which has a sufficiently sane license that just about anything can use it)
[11:22:58 AM] <pkern> josh: Is that actually happening?
[11:23:04 AM] <josh> pkern: Seems to be.
[11:23:07 AM] * pkern didn't see much progress in the recent past.
[11:23:08 AM] <josh> pkern: Last I checked...
[11:23:14 AM] <ijackson> No, I mean, why on earth does gnupg2 need three crypto libraries ?  That's obviously mad.
[11:23:35 AM] <Clint> i think it's more likely that the openssl license gets fixed
[11:23:50 AM] <josh> ijackson: Most likely because different dependency paths pull in different libraries.
[11:23:54 AM] <wouter> why isn't the core functionality of gpg a library, really?
[11:24:01 AM] <josh> wouter: +1
[11:24:24 AM] <Clint> historical reasons
[11:24:25 AM] <dsilvers> I believe it makes it a tad harder for RAM locking etc, but I'd love a proper core lib
[11:24:54 AM] <josh> ijackson: gnupg2 depends on libcurl3-gnutls (which uses gnutls); trying to figure out why it pulls in openssl...
[11:25:04 AM] <josh> ijackson: What's the dependency path from gnupg2 to openssl?
[11:25:05 AM] <josh> Not seeing it.
[11:25:13 AM] <thijs> wouter: https://www.gnupg.org/faq/GnuPG-FAQ.html#cant-we-have-a-gpg-library
[11:25:15 AM] <ijackson> Dunno, I just observed it in the output.
[11:25:19 AM] <Clint> dsilvers: you should help find the right parts of hopenpgp to use securemem with
[11:25:35 AM] <dsilvers> clint: I fear that's a tad beyond my haskell skills right now :-)
[11:25:43 AM] <wouter> thijs: that doesn't actually answer the question, though
[11:25:55 AM] <wouter> "there are security issues" without going into detail about *what* those issues are is less than useful
[11:26:39 AM] <pkern> Doesn't the agent also broker connections to hardware tokens?
[11:27:36 AM] <josh> ijackson: Is the 30MB version you posted pinentry-curses but still with recommends?
[11:27:52 AM] <ijackson> josh: y
[11:28:06 AM] <ijackson> w/o Recommends it's 18.7Mby
[11:28:10 AM] <josh> ijackson: If so, then the dependency chain is gnupg2 Depends libcurl3-gnutls Recommends ca-certificates Depends openssl (for the command-line tools)
[11:28:19 AM] <ijackson> No longer has libssl, openssl
[11:28:28 AM] <gniibe> 2.1 gpg-agent incompatibility: gnome-keyring, monkeysign, pius (which assume password caching only agent)
[11:28:30 AM] <josh> ijackson: In theory we could teach ca-certificates to manage keys with gnutls-cli, I suppose.
[11:28:31 AM] <wouter> changing a core component with something that pulls in loads of libraries. what could possibly go wrong?
[11:28:35 AM] <ijackson> josh: Seems plausible.
[11:28:37 AM] <pkern> It's about c_rehash.
[11:28:56 AM] <pkern> If someone wrote one based on gnutls...
[11:29:36 AM] <josh> gniibe: I'm going to be rather annoyed if I can't use gnome-keyring in place of gnupg-agent, 2.1 or otherwise.
[11:30:29 AM] <pkern> If we can avoid alternatives, we should.
[11:31:04 AM] <wouter> it's called "backups"
[11:31:12 AM] <Cyis> I already have to disable gnome-keyring but it's agent does not support smartcards properly
[11:31:21 AM] <josh> Cyis: Gah.  That needs fixing.
[11:31:36 AM] <josh> Cyis: Upstream bug?
[11:31:49 AM] <Cyis> so I disable gnome-keyring and run gpg-agent with ssh-support instead
[11:32:30 AM] <wouter> is it possible to tell it not to ever cache passwords?
[11:32:39 AM] <gniibe> I disable gnome-keyring, too.  But I don't know hot to do that in GNOME 3.12.
[11:32:51 AM] <pkern> Does one still need to set GPG_TTY?
[11:32:59 AM] <gniibe> In 2.1, gpg-agent does crypto computation.
[11:33:20 AM] <StevenC99> with jessie d-i beta1, i installed task 'standard', it brought in pinentry+libgtk2+libgl* - so that maybe isn't gnupg2's fault
[11:33:52 AM] <gniibe> It's not password caching againt any more (in 2.1).
[11:34:13 AM] <pkern> Gentoo had keychain to share gpg-agents.
[11:34:19 AM] <pkern> Which is in Debian.
[11:34:29 AM] <pkern> But it's the same problem as ssh-agent.
[11:34:44 AM] <wouter> gniibe: not my question
[11:34:53 AM] <wouter> gniibe: I want it to ask for my passphrase *every* time it wants to sign something
[11:34:59 AM] <wouter> is that possible?
[11:35:20 AM] <pkern> --max-cache-ttl
[11:35:23 AM] <pkern> man gpg-agent ;)
[11:35:46 AM] <pkern> --ignore-cache-for-signing
[11:36:02 AM] <wouter> pkern: are you looking at the 2.1 or 2.0 agent?
[11:36:08 AM] <pkern> Oh hm. :(
[11:36:17 AM] <wouter> see :)
[11:36:19 AM] <pkern> 2.0. Sorry.
[11:37:18 AM] <gniibe> wouter: Speaking about the protocol of gpg-agent, it is possible to reset status. So, in theory, it is possible.  I'll check configuration.
[11:37:24 AM] <wouter> what do others use? redhat/suse/gentoo/...?
[11:37:29 AM] <Cyis> wouter: I get asked everytime for the pin when I sign using my gpg subkey from the smartcard through the gpg-agent. the agent will cache the passphrase if I'm using the primary key that is not on a smartcard
[11:38:35 AM] <Cyis> the smartcard will cache the pin when I use SSH but pull the card out and it instantly clears the cache
[11:38:36 AM] <thijs> if I had a dime for everytime some agent asked my pin
[11:38:57 AM] <dsilvers> Noodles: mutt has code to understand if gpg agents are in use to force redraws etc.  So it *ought* to "just work"
[11:39:40 AM] <gniibe> Cyis: it is also possible to reset smartcard by gpg-agent protocol.  We can use gpg-connect-agent command line to reset the card.
[11:41:12 AM] <Cyis> gniibe: I'm not sure off-hand would have to be researched and tested
[11:42:47 AM] <gniibe> Cyis: http://www.fsij.org/doc-gnuk/stop-scdaemon.html#stopping-resetting-scdaemon
[11:45:00 AM] <Cyis> gniibe: that should work if your SC reader requires scdaemon. I've found several SC readers that can be used directly via gnupg2 without needing scdeamon
[11:46:19 AM] <StevenC99> "hokey lint" is in package hopenpgp-tools (jessie/sid);  takes the key from stdin (*not* ascii-armoured though)
[11:46:25 AM] <gniibe> Please join https://summit.debconf.org/debconf14/meeting/144/my-pgpgpg-key-is-rsa-2048-bit-but-i-put-the-private-key-on-gnuk-token/
[11:46:56 AM] <gniibe> 2.x requires scdaemon. 1.4 connects directly.
[11:47:01 AM] <Clint> StevenC99: you can pipe ascii armor through `hot dearmor` first
[11:47:16 AM] <StevenC99> thanks :)
[11:47:36 AM] <StevenC99> error message is a bit confusing if you pipe from gpg -a --export though
[11:47:48 AM] <pkern> I had a lot of problems with accessing smartcards as non-root because of pcscd interactions, though. |:
-------------- next part --------------
gobby.debian.org → debconf14 → bof → GnuPG

GnuPG in Debian
---------------
 • /etc/alternatives for gpg
 • defaults: gpg or gpg2
 • How to improve shared maintenance via pkg-gnupg.
 • cross-building and gpg's place in bootstrapping debian (building gpg4win)
 • Vcs religious wars -> move to git
 • elliptic curve support? (are we using "safe" curves [djb] by default)
 • d-i (udebs)
 • 2.1 (the eternal beta)
 • 2.1 new private key format incompatible with 2.0
 • 2.1 agent and pinentry is mandatory
 • divergence from upstream defaults?
 • gpg2, gnupg-agent, gnome-keyring, dependencies, and auto-launching
 • dependency cleanup: many packages pulled in by default due to pinentry-gtk2 (183MBy with Recommends, 107MBy without.  Potentially split?   (with pinentry-curses, 30.8Mby/18.7Mby) -- suggestion: change our dependency, have graphical desktops pull in pinentry-gtk2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/attachments/20140829/a29644de/attachment.sig>