blog: Second part of the "move" ;-)
authorWerner Koch <wk@gnupg.org>
Wed, 21 Sep 2016 09:51:22 +0000 (11:51 +0200)
committerWerner Koch <wk@gnupg.org>
Wed, 21 Sep 2016 09:51:22 +0000 (11:51 +0200)
Sorry, I have too man untracked files and missed to stage the renamed
files.

misc/blog.gnupg.org/20160921-python-bindings-for-gpgme.org [new file with mode: 0644]
misc/blog.gnupg.org/drafts/20160919-openpgp-conf.org [new file with mode: 0644]

diff --git a/misc/blog.gnupg.org/20160921-python-bindings-for-gpgme.org b/misc/blog.gnupg.org/20160921-python-bindings-for-gpgme.org
new file mode 100644 (file)
index 0000000..0185a3c
--- /dev/null
@@ -0,0 +1,72 @@
+# Python bindings for GPGME
+#+STARTUP: showall
+#+AUTHOR: Justus
+#+DATE: September 21th, 2016
+
+** Python bindings for GPGME
+
+GPGME 1.7 includes bindings for Python >= 2.7.  The bindings are a
+port of the [[https://bitbucket.org/malb/pyme][~pyme~]] bindings to Python 3 retaining compatibility with
+Python 2.7, with a small shim on top to provide a more idiomatic
+interface.  For the purposes of this post I will refer to the
+preexisting bindings that are for Python 2 only ~pyme2~, and to our
+new bindings as ~pyme3~.  Existing applications using ~pyme2~ should
+continue to work no changes.
+
+~pyme2~ offers an interface that is very close to that of GPGME.  This
+interface exposes all features of the underlying library, but it is
+not very "pythonic".  Therefore, we made an effort to provide a nicer
+interface on top of that.  Let me demonstrate how that looks.
+
+One important aspect is how to pass data around.  GPGME uses
+~gpgme_data_t~ for that, and in ~pyme2~ one had to explicitly create
+~pyme.core.Data~ objects to pass data to GPGME or to receive data.
+With ~pyme3~ one can use every object that implements the buffer
+protocol (e.g. ~bytes~), file-like objects with a ~fileno~ method, or
+explicit ~pyme.Data~ objects in places where GPGME expects a
+~gpgme_data_t~ object:
+
+#+BEGIN_SRC python
+import pyme
+with pyme.Context(armor=True) as c:
+    ciphertext, _, _ = c.encrypt(b"Hello Python world :)", passphrase="foo")
+#+END_SRC
+
+This will encrypt the given plaintext using symmetric encryption and
+the given passphrase, wrap it up using the OpenPGP protocol, and
+encode it using ASCII-armor.  The plaintext is easily recovered using:
+
+#+BEGIN_SRC python
+with pyme.Context() as c:
+    plaintext, _, _ = c.decrypt(ciphertext, passphrase="foo")
+assert plaintext == b"Hello Python world :)"
+#+END_SRC
+
+If ~passphrase~ is omitted, it is asked for out-of-band using GnuPG's
+pinentry mechanism.  Alternatively, if one or more recipients are
+specified, asymmetric encryption is used.  For details, please have a
+look at the docstring of ~pyme.Context.encrypt~.
+
+Most file-like objects can be used without explicit wrapping.  This is
+a filter that decrypts OpenPGP messages in three lines of code:
+
+#+BEGIN_SRC python
+import sys
+import pyme
+pyme.Context().decrypt(sys.stdin, sink=sys.stdout)
+#+END_SRC
+
+For more examples, have a look at the tests and examples shipped with
+the bindings under ~lang/python~.
+
+If you cannot wait until ~pyme3~ is packaged by your distribution, and
+you do not want to build GPGME 1.7 from source merely to get ~pyme3~,
+you can build it out-of-tree provided you have at least GPGME 1.6, the
+Python development packages, and SWIG.  You can get it from [[https://pypi.python.org/pypi/pyme3][pypi]] or
+directly install it using ~pip~:
+
+#+BEGIN_SRC sh
+# As of this writing, there is no released version uploaded to pypi,
+# hence we need --pre.
+$ pip install --pre pyme3
+#+END_SRC
diff --git a/misc/blog.gnupg.org/drafts/20160919-openpgp-conf.org b/misc/blog.gnupg.org/drafts/20160919-openpgp-conf.org
new file mode 100644 (file)
index 0000000..16bb869
--- /dev/null
@@ -0,0 +1,102 @@
+# OpenPGP.conf: A Success
+#+STARTUP: showall
+#+AUTHOR: Neal
+#+DATE: September 19, 2016
+
+On September 8th and 9th, the first [[https://www.gnupg.org/conf/program.html][OpenPGP.conf]] took place in Köln,
+Germany.  The conference was organized by the [[German%20Unix%20User%20Group][German Unix User Group]]
+(GUUG) and attracted over 50 participants from around the world.  The
+program consisted of 18 highly technical talks.  Lunch and dinner were
+provided at the venue, which resulted in lots of time to increase ties
+between projects as well as exchange and develop ideas.
+
+From the GnuPG project, Werner presented an introduction to the new
+[[https://www.gnupg.org/blog/20160830-web-key-service.html][web key service (WKS) protocol]], which is being deployed by several
+mail providers including [[https://posteo.de][Posteo]].  The basic problem that WKS addresses
+is how to find someone's key.  Currently, most people just search the
+key servers for keys matching the person's email address.  Although
+this works reasonably well, the [[https://www.ncsc.nl/english/current-topics/factsheets/duplicate-pgp-keys.html][recent evil32 attack]] has reminded many
+people that the keyservers provide no guarantees that a returned key
+is controlled by the stated owner.  In WKS, people upload their keys
+to their mail provider.  Since only the email account's owner can
+change the association, this is guaranteed to not only be the right
+key, but the user's preferred key.  Of course, users still need to
+trust their mail provider to deliver the correct key.  But, we believe
+this provides a significant improvement both in terms of security and
+usability over the status quo.  Those requiring stronger guarantees
+are still encouraged to either directly verify their communication
+partner's key or use the web of trust.  The German news site [[http://www.golem.de/news/web-key-service-openpgp-schluessel-ueber-https-verteilen-1609-123194.html][Golem
+reported on Werner's presentation]].  Meskio from the LEAP project also
+present [[https://meskio.net/openpgp.conf/#/][how LEAP is doing key discovery]].  Phillip Hallam-Baker
+discussed [[https://www.gnupg.org/conf/2016/openpgp-2016-the-mathematical-mesh.pptx][key management in the Mesh]].  And, holger krekel discussed
+[[https://www.gnupg.org/conf/2016/openpgp-2016-automatic-email-encryption-holger-krekel/index.html#/step-1][how to distribute keys inline]].
+
+Justus discussed his proposal for [[https://www.gnupg.org/conf/2016/openpgp-2016-common-openpgp-testsuite.pdf][a common OpenPGP test suite]].  The
+main problem that he observed in his recent work on the GPGME Python
+bindings is that GPG, GPGME, and each of the GPGME bindings have their
+own test suite that tests similar functionality to the other test
+suites.  His idea is to merge the common parts by defining a simple
+interface, and having each component just map the API to its own API.
+
+Niibe presented his fully free cryptographic token, [[http://www.gniibe.org/pdf/openpgp-2016/gnuk-1_2.html][GnuK]] (pronounced:
+ɡəˈnuːk), which he started developing in 2010.  The GnuK is special in
+that it is the only cryptographic token that is based entirely on Free
+Software, the entire hardware specification is open, and the parts are
+relatively easy to buy.  This is motivated not only by ethical
+concerns, but also security concerns: being able to assemble it
+yourself makes it harder for an adversary to inject a trojan during
+production.  Niibe also avoids specialized hardware.  This has less to
+do with making it easier to get the components, and more to do with
+security: getting documentation for secure chips, for instance,
+requires signing an NDA and, due to their specialized nature, are more
+likely to have a backdoor.  Instead, the GnuK uses a general purpose
+MCU (microcontroller unit).  To protect the secret key material, it
+uses the flash ROM protection feature.  There are currently
+discussions underway to further increase the security of this by
+partially decrypting the secret key material on the host with its much
+more capable CPU, which would make a brute force attack significantly
+more expensive should the key material be extracted.  The GnuK can
+currently be ordered either from [[https://www.seeedstudio.com/FST-01-without-Enclosure-p-1276.html][seeed]] or the [[https://shop.fsf.org/storage-devices/neug-usb-true-random-number-generator][FSF]].
+
+Andre discussed [[https://files.intevation.de/users/aheinecke/gpgme.pdf][how to use GPGME]].  The main takeaway is that although
+GPGME's API is sometimes inconveniently low-level and some features
+are missing, it is much easier to interact with GPG using GPGME than
+to build another parser to parse GPG's ~--status-fd~ output.
+Moreover, language bindings, such as Andre's bindings for Qt, can
+significantly simplify working with GPGME.
+
+Daniel reported on [[https://dkg.fifthhorseman.net/gnupg-in-debian-2016.svg][GnuPG in Debian]].  In particular, he discussed how
+Debian is dealing with co-installing GnuPG 1.4 and GnuPG 2.1,
+migration from 1.4 to 2.1, managing background processes, and system
+integration.  He also discussed some issues that he has observed with
+packages that use GnuPG.  In particular, their test suits often don't
+test their use of GnuPG, because this requires so much effort.  He
+indicated that one thing that would make life easier would be standard
+pinentry driver programs for different languages.  He's since
+submitted those for PHP, Perl, Python and Bash, and they will be part
+of the next GnuPG release.
+
+Another talk included a discussion of encrypted mailing list software
+and the current state of Schleuder by Ilf and Paz.  Schleuder is
+apparently the only encrypted mailing list software that currently
+works (it is also actively maintained).  Its design, however, requires
+that the mailing list server be able to decrypt the messages in order
+to reencrypt them to all of the subscribers.  The authors would like a
+better solution, but, as they point out, there are ideas out there
+(including my own proposal for [[http://hssl.cs.jhu.edu/~neal/encrypted-mailing-lists.pdf][practical encrypted mailing lists]]), but
+none of them work today.  This presentation was also [[http://www.golem.de/news/schleuder-wie-verschluesselt-man-eine-mailingliste-1609-123206.html][reported on by
+Golem]].
+
+One of my favorite talks was [[http://nskelsey.com/glbc-2016.pdf][Nick Skelsey's talk on GlobaLeaks]].  He
+discussed typical leaking interactions, how their leaking platform
+works, and the issues they face making the platform secure in the face
+of non-technical users.
+
+Other talks included an overview of some [[http://www.intevation.de/~bernhard/presentations/201609-openpgpconf/20160908-3bsi-contracts.pdf][work that the German BSI has
+contracted]], [[https://www.gnupg.org/conf/2016/openpgp-2016-a-few-concerns.pdf][an analysis of OpenPGP]], [[http://altlasten.lutz.donnerhacke.de/mitarb/lutz/vortrag/openpgp-history.pdf][a history of OpenPGP]], [[https://www.gnupg.org/conf/2016/openpgp-2016-openkeychain.pdf][OpenKeychain
+UX decisions]], [[https://www.gnupg.org/conf/2016/openpgp-2016-bypass-pinentry.pdf][how to bypass pinentry]], [[https://sks-keyservers.net/files/2016-09_OpenPGP-Conf-sks-keyservers.pdf][an update on the sks keyservers]],
+an overview of PEP, and an analysis of the keyserver data.
+
+Given the very positive reactions from the participants and our own
+positive impressions, we expect there to be a second edition of the
+conference in the near future.