[git] gnupg-doc - branch, master, updated. dd549a095ad06b9cbc35b2bd5992b7913346d192
by Werner Koch
cvs at cvs.gnupg.org
Wed Sep 21 11:54:19 CEST 2016
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "The GnuPG website and other docs".
The branch, master has been updated
via dd549a095ad06b9cbc35b2bd5992b7913346d192 (commit)
from c94e616128db9b774fca12625a2543ddef95f9f9 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commit dd549a095ad06b9cbc35b2bd5992b7913346d192
Author: Werner Koch <wk at gnupg.org>
Date: Wed Sep 21 11:51:22 2016 +0200
blog: Second part of the "move" ;-)
Sorry, I have too man untracked files and missed to stage the renamed
files.
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
index 0000000..0185a3c
--- /dev/null
+++ b/misc/blog.gnupg.org/20160921-python-bindings-for-gpgme.org
@@ -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
index 0000000..16bb869
--- /dev/null
+++ b/misc/blog.gnupg.org/drafts/20160919-openpgp-conf.org
@@ -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.
-----------------------------------------------------------------------
Summary of changes:
.../20160921-python-bindings-for-gpgme.org | 72 +++++++++++++++
.../drafts/20160919-openpgp-conf.org | 102 +++++++++++++++++++++
2 files changed, 174 insertions(+)
create mode 100644 misc/blog.gnupg.org/20160921-python-bindings-for-gpgme.org
create mode 100644 misc/blog.gnupg.org/drafts/20160919-openpgp-conf.org
hooks/post-receive
--
The GnuPG website and other docs
http://git.gnupg.org
More information about the Gnupg-commits
mailing list