blog: Add financial Results for 2015
[gnupg-doc.git] / misc / blog.gnupg.org / 20150607-gnupg-in-may.org
1 # GnuPG News for May 2015
2 #+STARTUP: showall
3 #+AUTHOR: Neal
4 #+DATE: June 7th, 2015
5 #+Keywords: GNOME Python Emacs Pinentry Libassuan
6
7 ** GnuPG News for May 2015
8
9 A lot happened during May.
10
11 My focus was on Pinentry.  My primary goal was to fix the GNOME
12 Keyring issue, but along the way I also made various improvements and
13 closed a bunch of outstanding issues.
14
15 The GNOME Keyring issue is that GNOME Keyring proxies all traffic to
16 GPG Agent so that it can cache any passphrases and display its own
17 pinentry dialogs, which have a GNOME3 aesthetic.  Unfortunately, the
18 proxy's implementation of the GPG Agent protocol is not complete and
19 this breaks a lot of GnuPG's functionality.  Working with Stef
20 Walters, the maintainer of GNOME Keyring, we came up with a plan to
21 resolve the situation.  The basic idea is to add support for external
22 password managers to GnuPG, modify the pinentry programs to deal with
23 an external password manager and add a GNOME3 pinentry.  The changes
24 for GnuPG have been added to the 2.1 branch and backported to the 2.0
25 branch.  The pinentry work is also done.  The remaining bit of work is
26 to get distributions to disable the GNOME Keyring proxy and distribute
27 the new changes.  (A summary of changes required by distributions can
28 be found [[https://lists.gnupg.org/pipermail/gnupg-devel/2015-May/029835.html][here]].)  To this end, Werner released new version of GnuPG
29 stable (the 2.0 line), GnuPG modern (the 2.1 line) and Pinentry.
30 Distributions immediately began to integrate the changes.  In
31 particular, Daniel Kahn Gillmor already uploaded packages to Debian
32 Unstable.  This uncovered a few minor bugs, which we quickly fixed.
33
34 Ben McGinnes [[https://lists.gnupg.org/pipermail/gnupg-devel/2015-May/029844.html][announced]] new Python 3 bindings for GPGME based on PyME
35 0.9.0.  Ben noted that PyME is for Python 2 and will continue to be
36 maintained separately by Martin Albrecht.  Ben has tested the library
37 on Mac OS X, but seeks more testers.
38
39 Daniel Kahn Gillmore [[https://lists.gnupg.org/pipermail/gnupg-devel/2015-May/029786.html][announced]] initial Python 3 bindings for
40 libassuan, GnuPG's IPC library.  The library is not yet complete and
41 Daniel is looking for feedback regarding the API as well as more
42 general contributions.
43
44 Daiki Ueno sent [[https://lists.gnupg.org/pipermail/gnupg-devel/2015-May/029875.html][patches]] to add an emacs-based pinentry.  This pinentry
45 talks to the running emacs using a communication mechanism similar to
46 emacsclient.  Unlike the other pinentry's, this pinentry isn't
47 normally used by default.  Instead, all of the pinentries have been
48 modified to (optionally) detect whether they are run from emacs (by
49 checking for the INSIDE_EMACS environment variable).  If so, they use
50 the new pinentry functionality.  Otherwise, they display their usual
51 frontend.
52
53 NIIBE Yutaka and Werner spent time triaging a number of bugs.  This
54 work is not very sexy, but this is what most improves the quality of
55 the code base.
56
57 Daniel Kahn Gillmor also reported a number of bugs and did significant
58 work helping to triage them.
59
60 Werner released GnuPG versions [[https://lists.gnupg.org/pipermail/gnupg-devel/2015-May/029817.html][2.1.4]] and [[https://lists.gnupg.org/pipermail/gnupg-devel/2015-June/029892.html][2.0.28]] and Pinentry version
61 0.9.3 and 0.9.4.
62
63 Werner has also been actively improving the OpenPGP specificantion,
64 RFC4880.  This effort is occuring within the context of the [[http://www.ietf.org/mail-archive/web/openpgp/][IETF]].  The
65 new specification is currently called RFC4880bis and a working group
66 is in the process of being chartered.  The goal is to have a new
67 version of the specification by July 2016.
68
69 In additional to the development, there were also several interesting
70 discussions on the mailing lists.
71
72 On gnupg-devel, Daniel Kahn Gillmor [[https://lists.gnupg.org/pipermail/gnupg-devel/2015-April/029750.html][observed]] that GnuPG reads 300
73 bytes from /dev/random when it generates a long-term key, which, he
74 observed, is a lot given /dev/random's limited entropy .  Werner
75 explained that GnuPG has always done this.  In particular, GnuPG
76 maintains a 600-byte persistent seed file and every time a key is
77 generated it stirs in an additional 300 bytes.  Daniel pointed out an
78 interesting blog post by DJB explaining that a proper CSPRNG should
79 never need more than about 32 bytes of entropy.  Peter Gutmann chimed
80 in and noted that a 2048-bit RSA key needs about about 103 bits of
81 entropy and a 4096-bit RSA key needs about 142 bits, but, in practice,
82 128-bits is enough.  Based on this, Werner proposed a patch for
83 Libgcrypt that reduces the amount of seeding to just 128-bits.
84
85 During this discussion, Werner also [[https://lists.gnupg.org/pipermail/gnupg-devel/2015-May/029782.html][noted]] that to avoid reusing
86 entropy and thereby weakening any derived keys, it is important to
87 never backup or restore GnuPG's random seed file
88 (~/.gnupg/random_seed).
89
90 Werner proposed adding an option to the GTK+ pinentry to [[https://lists.gnupg.org/pipermail/gnupg-devel/2015-May/029790.html][show/hide]] the
91 passphrase.  This is useful when entering very long passphrases (and
92 when the user knows that he or she is not being observed).
93
94 On gnupg-users, there was an interesting [[https://lists.gnupg.org/pipermail/gnupg-users/2015-May/053676.html][discussion]] about using
95 external sources of entropy, such as the results of rolling dice.
96 Niibe replied that no person can beat the unbiasedness of modern
97 HWRNG, which are aggressively tested using modern empirical statistics
98 over gigabytes or terabytes of random data.  The only real question is
99 whether the entropy source has been backdoored.
100
101 The Facebook announcement for OpenPGP was also [[https://lists.gnupg.org/pipermail/gnupg-users/2015-June/053709.html][mentioned]].  The
102 reactions are mixed.  Personally, I think this is a positive
103 development.  It's true that Facebook is probably not working towards
104 end-to-end encryption, but if they encourage other big sites, such as
105 banks and e-commerce sites, to encrypt their email communication with
106 their users, we may have a meaningful increase in security.
107
108
109 ** About this news posting
110
111 We try to write a news posting each month.  However, other work may
112 have a higher priority (e.g. security fixes) and thus there is no
113 promise for a fixed publication date.  If you have an interesting
114 topic for a news posting, please send it to us.  A regular summary of
115 the mailing list discussions would make a nice column on this news.