logo

 

This site is now 100% read-only, and retired.
  1. dkg
  2. Blog
  3. #116

XML logo

#116
Changes for GnuPG in Debian
Posted by dkg on Wed 3 Aug 2016 at 21:55
Tags:

The GNU Privacy Guard (GnuPG) upstream team maintains three branches of development: 1.4 ("classic"), 2.0 ("stable"), and 2.1 ("modern").

They differ in various ways: software architecture, supported algorithms, network transport mechanisms, protocol versions, development activity, co-installability, etc.

Debian currently ships two versions of GnuPG in every maintained suite -- in particular, /usr/bin/gpg has historically always been provided by the "classic" branch.

That's going to change!

Debian unstable will soon be moving to the "modern" branch for providing /usr/bin/gpg. This will give several advantages for Debian and its users in the future, but it will require a transition. Hopefully we can make it a smooth one.

What are the benefits?

Compared to "classic", The "modern" branch has:

  • updated crypto (including elliptic curves)
  • componentized architecture (e.g. libraries, some daemonized processes)
  • improved key storage
  • better network access (including talking to keyservers over tor)
  • stronger defaults
  • more active upstream development
  • safer info representation (e.g. no more key IDs, fingerprints easier to copy-and-paste)

If you want to try this out, the changes are already made in experimental. Please experiment!

What does this mean for end users?

If you're an end user and you don't use GnuPG directly, you shouldn't notice much of a change once the packages start to move through the rest of the archive.

Even if you do use GnuPG regularly, you shouldn't notice too much of a difference. One of the main differences is that all access to your secret key will be handled through gpg-agent, which should be automatically launched as needed. This means that operations like signing and decryption will cause gpg-agent to prompt the the user to unlock any locked keys directly, rather than gpg itself prompting the user.

If you have an existing keyring, you may also notice a difference based on a change of how your public keys are managed, though again this transition should ideally be smooth enough that you won't notice unless you care to investigate more deeply.

If you use GnuPG regularly, you might want to read the NEWS file that ships with GnuPG and related packages for updates that should help you through the transition.

If you use GnuPG in a language other than English, please install the gnupg-l10n package, which contains the localization/translation files. For versions where those files are split out of the main package, gnupg explicitly Recommends: gnupg-l10n already, so it should be brought in for new installations by default.

If you have an archive of old data that depends on known-broken algorithms, PGP3 keys, or other deprecated material, you'll need to have "classic" GnuPG around to access it. That will be provided in the gnupg1 package

What does this mean for package maintainers?

If you maintain a package that depends on gnupg: be aware that the gnupg package in debian is going through this transition.

A few general thoughts:

  • If your package Depends: gnupg for signature verification only, you might prefer to have it Depends: gpgv instead. gpgv is a much simpler tool that the full-blown GnuPG suite, and should be easier to manage. I'm happy to help with such a transition (we've made it recently with apt already)

  • If your package Depends: gnupg and expects ~/.gnupg/ to be laid out in a certain way, that's almost certainly going to break at some point. ~/.gnupg/ is GnuPG's internal storage, and it's not recommended to rely on any specific data structures there, as they may change. gpg offers commands like --export, --import, and --delete for manipulating its persistent storage. please use them instead!

  • If your package depends on parsing or displaying gpg's output for the user, please make sure you use its special machine-readable form (--with-colons). Parsing the human-readable text is not advised and may change from version to version.

If you maintain a package that depends on gnupg2 and tries to use gpg2 instead of gpg, that should stay ok. However, at some point it'd be nice to get rid of /usr/bin/gpg2 and just have one expected binary (gpg). So you can help with that:

  • Look for places where your package expects gpg2 and make it try gpg instead. If you can make your code fall back cleanly

  • Change your dependencies to indicate gnupg (>= 2)

  • Patch lintian to encourage other people to make this switch ;)

What specifically needs to happen?

The last major step for this transition was renaming the source package for "classic" GnuPG to be gnupg1. This transition is currently in the ftp-master's NEW queue. Once it makes it through that queue, and both gnupg1 and gnupg2 have been in experimental for a few days without reports of dangerous breakage, we'll upload both gnupg1 and gnupg2 to unstable.

We'll also need to do some triage on the BTS, reassigning some reports which are really only relevant for the "classic" branch.

Please report bugs via the BTS as usual! You're also welcome to ask questions and make suggestions on #debian-gnupg on irc.oftc.net, or to mail the Debian GnuPG packaging team at pkg-gnupg-maint@lists.alioth.debian.org.

Happy hacking!

[10 Comments ]
<<< Previous

 

Comments on this Entry

#
Re: Changes for GnuPG in Debian
Posted by Anonymous (193.107.xx.xx) on Thu 4 Aug 2016 at 11:48
Can we please have an option (update-alternatives?) to keep using gpg1 as gpg binary?

[ Parent ]

#
Re: Changes for GnuPG in Debian
Posted by dkg (38.109.xx.xx) on Thu 4 Aug 2016 at 12:54
[ View Weblogs ]
No, we won't do that. There are enough subtle things that might use /usr/bin/gpg in the background, and software/system engineering is hard enough without having to guess at what version of gpg is actually providing that tool. I think it's important to focus our development efforts on a branch with the features that we'll want going forward. <p> If you have a reason to use gpg1, use gpg1 explicitly. gpg1 will remain supported. <p> afaict, the main reason to use gpg1 is for people dealing with an archive of old messages that were encrypted to an ancient (PGP3) key. I don't think that there are many such people, and most of them are technically sophisticated enough to figure out how to make that work on their own using gpg1. That said, i'd welcome a tool that knows enough to import such an old key and, given an encrypted message, re-encrypts the message's session key to a new key. If anyone wants to work on that, please come chat on #debian-gnupg -- i'm happy to give pointers.

[ Parent ]

#
Re: Changes for GnuPG in Debian
Posted by Anonymous (217.77.xx.xx) on Fri 5 Aug 2016 at 09:37
Maybe I am offtopic...
How can be sure that the agent is started from a legitimate action or program?
The agent popup is async and so vague that is the same for too many different actions.
And can not be disabled. A step back in security.

[ Parent ]

#
Re: Changes for GnuPG in Debian
Posted by dkg (38.109.xx.xx) on Fri 5 Aug 2016 at 14:31
[ View Weblogs ]

I agree that some clear indication of the context of use would be helpful, but the agent is a step forward in security, not backward -- an isolated cryptographic agent means that secret key material isn't exposed in memory to arbitrary processes.

Even better, it presents an opportunity to isolate the agent (and all secret key material). More development work is needed to reap the benefits of this isolation, but it's an important step forward from the agent being just a passphrase cache.

[ Parent ]

#
Re: Changes for GnuPG in Debian
Posted by Anonymous (217.77.xx.xx) on Tue 9 Aug 2016 at 12:27
I agree in principle there can be more security, but in practice now there is less.

For exampe an evil program could steal secrets because of the caching since
--default-cache-ttl can not be 0!

As soon as you unlock your keyring, it is unlocked for few secs for everbody
that has an access to the agent!

This is lowering the barriers to access an open keyring.

Combined with the fact that the logs of gpg-agent do not are easily
understandable or parsable, you probably will never know that
somebody has steal something from your encrypted files.

I guess that the --ignore-cache-for-signing prevent an evil program
to sign on your behalf by using the cache, seems strange that this
is not implemented for decryption.

So in the end the user should trust all the program running and
accessing the agent, including the browser.

AFAIK there is no gpg-agent paranoid setup and configuration that will
fix this now.

[ Parent ]

#
Re: Changes for GnuPG in Debian
Posted by Anonymous (38.109.xx.xx) on Tue 9 Aug 2016 at 14:59

What makes you say that you can't set default-cache-ttl to 0 ? that seems to work for me.

i agree that the logs of gpg-agent could be improved for readability, though.

and i also agree that it would be great to make it very easy to set up a paranoid gpg-agent configuration. any contributions in that direction would be welcome.

[ Parent ]

#
Re: Changes for GnuPG in Debian
Posted by Anonymous (217.77.xx.xx) on Thu 11 Aug 2016 at 12:08
> What makes you say that you can't set default-cache-ttl to 0 ? that seems to work for me.

Sorry for not being clear. You can set it, but the effect is not what you want.
If you open the keyring, the for a little time (few sec, sorry do not have test right now),
a call gpg2 --decrypt will not require password, so somewhat the cache is longer than 0.

I agree for the paranoid. I will try to do some research on the topic and keep update!

[ Parent ]

#
Re: Changes for GnuPG in Debian
Posted by Anonymous (37.230.xx.xx) on Fri 5 Aug 2016 at 10:56
I've noticed you've split the locales out for both gnupg1 and gnupg2. Why? It's just a few megabytes, and splitting them will make many systems just not install them by default. I plea for you to revert this.

[ Parent ]

#
Re: Changes for GnuPG in Debian
Posted by dkg (38.109.xx.xx) on Fri 5 Aug 2016 at 13:39
[ View Weblogs ]

The architecture-independent locale information took up over half the size of the installed architecture-dependent packages. gnupg itself Recommends: gnupg-l10n, and gnupg1 Recommends: gnupg1-l10n, so most systems will automatically install them by default. If a user has configured apt to not install recommends, then they're looking for a minimal system. "a few megabytes" can make a big difference in constrained environments.

splitting out localization information also has the advantage that it takes up less space on the archives, since only one copy of the localization is shipped instead of one per supported architecture.

I don't plan on reverting this change.

[ Parent ]

#
Re: Changes for GnuPG in Debian
Posted by Anonymous (134.3.xx.xx) on Mon 8 Aug 2016 at 05:52
I support this change. It was mostly already problematic to use both GnuPG1 and GnuPG2 in e.g. shell scripts. The modern development branch has distinct advantages, and so far only minor differences exist. But with regard to the default settings, it is important to note that this is mainly the KDF concerns. So if you regularly symmetrically encrypt data with GPG, or possibly even many data at once, you must make use of the "--s2k-mode 1" option. Because if you use already strong passwords, then the KDF is mostly unnecessary and only creates significant performance degradation.

[ Parent ]