blog: Move a blog to drafts, publish gpgme/python blog
authorWerner Koch <wk@gnupg.org>
Wed, 21 Sep 2016 07:50:47 +0000 (09:50 +0200)
committerWerner Koch <wk@gnupg.org>
Wed, 21 Sep 2016 07:50:47 +0000 (09:50 +0200)
misc/blog.gnupg.org/20160919-openpgp-conf.org [deleted file]
misc/blog.gnupg.org/drafts/20160812-python-bindings-for-gpgme.org [deleted file]
misc/id/openpgp-webkey-service/draft.org

diff --git a/misc/blog.gnupg.org/20160919-openpgp-conf.org b/misc/blog.gnupg.org/20160919-openpgp-conf.org
deleted file mode 100644 (file)
index 16bb869..0000000
+++ /dev/null
@@ -1,102 +0,0 @@
-# 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.
diff --git a/misc/blog.gnupg.org/drafts/20160812-python-bindings-for-gpgme.org b/misc/blog.gnupg.org/drafts/20160812-python-bindings-for-gpgme.org
deleted file mode 100644 (file)
index 88216ab..0000000
+++ /dev/null
@@ -1,71 +0,0 @@
-# Python bindings for GPGME
-#+AUTHOR: Justus
-#+DATE: September 16th, 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
index 5756e7d..29b234e 100644 (file)
@@ -362,12 +362,15 @@ can be done with a file at the URL
       WELLKNOWN/policy
 #+END_EXAMPLE
 
-The file contains keywords, one per line with each line terminated by a
-LF or the sequence of CR and LF. Empty lines and lines starting with a
-'#' character are considered comment lines. A keyword is made up of
-lowercase letters, digits, hyphens, or dots. An underscore is allowed as
-a name space delimiters; see below. The first character must be a
-letter. Clients MUST use case-insensitive matching.
+The file contains keywords and optioanlly values, one per line with
+each line terminated by a LF or the sequence of CR and LF. Empty lines
+and lines starting with a '#' character are considered comment
+lines. A keyword is made up of lowercase letters, digits, hyphens, or
+dots. An underscore is allowed as a name space delimiters; see
+below. The first character must be a letter.  Keywords which are
+defined to require a value are directly followed by a colon and then
+after optional white space the value.  Clients MUST use
+case-insensitive matching for the keyword.
 
 Currently defined keywords are:
 
@@ -381,8 +384,14 @@ Currently defined keywords are:
                  Key Directory Update protocol is used to update the
                  keys for the DANE service.
 
+- "auth-submit" :: The submission of the mail to the server is done
+                   using an authenticated connection.  Thus the
+                   submitted key will be published immediately without
+                   any confirmation request.
+
+
 More keywords will be defined in updates to this I-D. There is no
-registry yet except for this document. For experimental use of new
+registry except for this document.  For experimental use of new
 features or for provider specific settings, keywords MUST be prefixed
 with a domain name and an underscore.