94 lines
4.2 KiB
Plaintext
94 lines
4.2 KiB
Plaintext
|
# -*- mode: org -*-
|
||
|
|
#+TITLE: Maintenance Mode
|
||
|
|
#+AUTHOR: Ben McGinnes
|
||
|
|
#+LATEX_COMPILER: xelatex
|
||
|
|
#+LATEX_CLASS: article
|
||
|
|
#+LATEX_CLASS_OPTIONS: [12pt]
|
||
|
|
#+LATEX_HEADER: \usepackage{xltxtra}
|
||
|
|
#+LATEX_HEADER: \usepackage[margin=1in]{geometry}
|
||
|
|
#+LATEX_HEADER: \setmainfont[Ligatures={Common}]{Times New Roman}
|
||
|
|
#+LATEX_HEADER: \author{Ben McGinnes <ben@gnupg.org>}
|
||
|
|
|
||
|
|
|
||
|
|
* Maintenance Mode from 2019
|
||
|
|
:PROPERTIES:
|
||
|
|
:CUSTOM_ID: maintenance-mode
|
||
|
|
:END:
|
||
|
|
|
||
|
|
| Version: | 0.0.1-draft |
|
||
|
|
| GPGME Version: | 1.13.0 |
|
||
|
|
| Author: | [[https://gnupg.org/people/index.html#sec-1-5][Ben McGinnes]] <[[mailto:ben@gnupg.org][ben@gnupg.org]]> |
|
||
|
|
| Author GPG Key: | [[https://hkps.pool.sks-keyservers.net/pks/lookup?search=0xDB4724E6FA4286C92B4E55C4321E4E2373590E5D&exact=on&op=get][DB4724E6FA4286C92B4E55C4321E4E2373590E5D]] |
|
||
|
|
| Language: | Australian English, British English |
|
||
|
|
| xml:lang: | en-AU, en-GB, en |
|
||
|
|
|
||
|
|
From the beginning of 2019 the Python bindings to GPGME will enter
|
||
|
|
maintenance mode, meaning that new features will not be added and only
|
||
|
|
bug fixes and security fixes will be made. This also means that
|
||
|
|
documentation beyond that existing at the end of 2018 will not be
|
||
|
|
developed further except to correct errors.
|
||
|
|
|
||
|
|
Though use of these bindings appears to have been quite well received,
|
||
|
|
there has been no indication of what demand there is, if any for
|
||
|
|
either financial backing of the current Python bindings development or
|
||
|
|
support contracts with g10code GmbH citing the necessity of including
|
||
|
|
the bindings.
|
||
|
|
|
||
|
|
|
||
|
|
** Maintainer from 2019 onward
|
||
|
|
:PROPERTIES:
|
||
|
|
:CUSTOM_ID: maintenance-mode-bm
|
||
|
|
:END:
|
||
|
|
|
||
|
|
How does this affect the position of GnuPG Python Bindings Maintainer?
|
||
|
|
|
||
|
|
Well, I will remain as maintainer of the bindings; but without funding
|
||
|
|
for that position, the amount of time I will be able to dedicate
|
||
|
|
solely to this task will be limited and reduced to volunteered time.
|
||
|
|
As with all volunteered time and effort in free software projects,
|
||
|
|
this will be subject to numerous external imperatives.
|
||
|
|
|
||
|
|
|
||
|
|
** Using the Python Bindings from 2019 and beyond
|
||
|
|
:PROPERTIES:
|
||
|
|
:CUSTOM_ID: maintenance-mode-blade-runner
|
||
|
|
:END:
|
||
|
|
|
||
|
|
For most, if not all, Python developers using these bindings; they
|
||
|
|
will continue to “just work” the same as they always have. Expansions
|
||
|
|
of GPGME itself are usually handled by SWIG with the existing code and
|
||
|
|
thus bindings are generated properly when the bindings are installed
|
||
|
|
alongside GPGME and when the latter is built from source.
|
||
|
|
|
||
|
|
In the rare circumstances where that is not enough to address some new
|
||
|
|
addition to GPGME, then that is a bug and thus subject to the
|
||
|
|
maintenance mode provisions (i.e. it will be fixed following a bug
|
||
|
|
report being raised and your humble author will need to remember where
|
||
|
|
the timesheet template was filed, depending on how many years off such
|
||
|
|
an event is).
|
||
|
|
|
||
|
|
All the GPGME functionality will continue to be accessible via the
|
||
|
|
lower level, dynamically generated methods which match the GPGME C
|
||
|
|
documentation. While the more intuitively Pythonic higher level layer
|
||
|
|
already covers the vast majority of functionality people require with
|
||
|
|
key generation, signatures, certifications (key signing), encryption,
|
||
|
|
decryption, verification, validation, trust levels and so on.
|
||
|
|
|
||
|
|
Any wanted features lacking in the Python bindings are usually lacking
|
||
|
|
because they are missing from GPGME itself (e.g. revoking keys via the
|
||
|
|
API) and in such cases they are usually deliberately excluded. More
|
||
|
|
|
||
|
|
Any features existing in the dynamically generated layer for which
|
||
|
|
people want a specific, higher level function included to make it more
|
||
|
|
Pythonic (e.g. to avoid needing to learn or memorise cryptographic
|
||
|
|
mode values or GnuPG status code numbers), would be a feature request
|
||
|
|
and /not/ a bug.
|
||
|
|
|
||
|
|
It is still worthwhile requesting it, but the addition of such a
|
||
|
|
feature would not be guaranteed and provided on a purely volunteer
|
||
|
|
basis. Expediting such a request would require funding that request.
|
||
|
|
|
||
|
|
Those with a commercial interest in expediting such a feature request
|
||
|
|
already know how to [[https://gnupg.org/cgi-bin/procdonate.cgi?mode=preset][expedite it]] (use the message field to state what
|
||
|
|
feature is being requested).
|