[git] GPGME - branch, ben/gpygme, updated. gpgme-1.5.5-9-gbd91d40
by Ben McGinnes
cvs at cvs.gnupg.org
Fri Jun 26 19:28:38 CEST 2015
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 "GnuPG Made Easy".
The branch, ben/gpygme has been updated
via bd91d40ba52f3823c401cfa7dd5515b157c77dbf (commit)
from 434dd67170d29aac6f4232a1135cc8b43834d052 (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 bd91d40ba52f3823c401cfa7dd5515b157c77dbf
Author: Ben McGinnes <ben at adversary.org>
Date: Sat Jun 27 03:27:10 2015 +1000
Typesetting
* Fixed sentence spacing and paragraph alignment following conversion
from reST format.
diff --git a/lang/gpygme/docs/FAQ.org b/lang/gpygme/docs/FAQ.org
index 37cfb74..12b0ddb 100644
--- a/lang/gpygme/docs/FAQ.org
+++ b/lang/gpygme/docs/FAQ.org
@@ -7,27 +7,27 @@
*1. Why implement an interactive codebase?*
For good or ill, modern application development has turned to many web
-based technologies. As a result there are many more developers who no
-longer use or know languages like C. Consequently complete APIs like
+based technologies. As a result there are many more developers who no
+longer use or know languages like C. Consequently complete APIs like
GPGME are not available to them when they may very well need it or
-benefit greatly from it. Rather than continuing existing systems which
-utilise wrappers calling command line programs (e.g. [[https://bitbucket.org/vinay.sajip/python-gnupg][python-gnupg]]), it
+benefit greatly from it. Rather than continuing existing systems which
+utilise wrappers calling command line programs (e.g. [[https://bitbucket.org/vinay.sajip/python-gnupg][python-gnupg]]), it
is best to provide access to GPGME in a manner which can be safely
used by newer developers.
*2. Won't that create bottlenecks or performance issues?*
It might, but chances are these will be negligible for most
-implementations. Projects which truly needs greater optimisation should
-consider utilising the GPGME C code directly.
+implementations. Projects which truly needs greater optimisation
+should consider utilising the GPGME C code directly.
*3. I want (or need) to use a proprietary licence with my project, can I
use this?*
Yes, when interacting with GPyGME as a stand alone API it is much the
-same as using any external API. That is, your code is simply
+same as using any external API. That is, your code is simply
communicating with another system and not integrating that system into
-your own code. Only when implementing your project in Python and
+your own code. Only when implementing your project in Python and
importing the API as a module or library would your code then become
subject to the LGPL 2.1+ (which might be fine anyway, consult with a
lawyer for issues pertaining to your specific situation).
@@ -38,19 +38,19 @@ lawyer for issues pertaining to your specific situation).
problems with ITAR and the Wassenaar Arrangement?*
I'm not developing a cryptosystem or any encryption algorithms, I'm
-developing an API. So I should not be affected one way or the other by
-the provisions of the [[http://www.austlii.edu.au/au/legis/cth/num_act/dtca2012207/][Defence Trade Control Act 2012]] (DTCA),
+developing an API. So I should not be affected one way or the other
+by the provisions of the [[http://www.austlii.edu.au/au/legis/cth/num_act/dtca2012207/][Defence Trade Control Act 2012]] (DTCA),
particularly with the 2015 amendments which have been passed by the
Australian Parliament.
*2. What if you're wrong about that?*
-That seems somewhat unlikely. The DSGL explicitly cites cryptography
+That seems somewhat unlikely. The DSGL explicitly cites cryptography
and encryption software as being in Part 2 of the [[http://www.austlii.edu.au/au/legis/cth/num_act/dtca2012207/s4.html#defense_trade_cooperation_munitions_list][Defence Trade
Cooperation Munitions List]], but neither GPGME nor GPyGME are
-encryption software directly. Even GPGME simply provides a means of
+encryption software directly. Even GPGME simply provides a means of
accessing what it refers to as encryption engines; currently the
-engines it supports are GnuPG and GpgSM. As long as I do not develop
+engines it supports are GnuPG and GpgSM. As long as I do not develop
any of these encryption engines my work is not affected by the
provisions of Australia's export controls, no matter how backward or
useless I might consider those controls to be.
@@ -63,56 +63,56 @@ naming me and this work as falling under the purview of the DTCA, then
yes; otherwise no.
The only other way it could happen is if the Defence definition of
-"public domain" changes or if exemptions based on something being in the
-public domain are removed.
+"public domain" changes or if exemptions based on something being in
+the public domain are removed.
*4. What assurances can you give that this will remain the case and
everything will be fine?*
The Department of Defence's [[http://www.defence.gov.au/DECO/Default.asp][Defence Export Control Office]] (DECO)
provides numerous resources to address concerns relating to this type
-of development. Included in this is the [[https://dsgl.defence.gov.au/pages/home.aspx][Defence and Strategic Goods
+of development. Included in this is the [[https://dsgl.defence.gov.au/pages/home.aspx][Defence and Strategic Goods
List]] (DSGL) and its accompanying [[https://dsgl.defence.gov.au/pages/questionnaire.aspx][Activity Questionnaire]] and [[https://dsgl.defence.gov.au/pages/search.aspx][Online
DSGL Search Tool]].
I completed the questionaire using the following conservative
assumptions: that this work is either or both of supply and publishing
of software and technology; and that the entire project really is in
-the category of Part 2 of the DSGL as a dual-use technology. Even
+the category of Part 2 of the DSGL as a dual-use technology. Even
though I am still pretty sure that only GPG itself and GpgSM would be
-placed in that category. Maybe libassuan, dirmngr and pinentry would
-too. Still, assuming that it all did, including GPGME and GPyGME, the
-results are clear that both supply and publication are fine. The
+placed in that category. Maybe libassuan, dirmngr and pinentry would
+too. Still, assuming that it all did, including GPGME and GPyGME, the
+results are clear that both supply and publication are fine. The
[[http://dfat.gov.au/international-relations/security/sanctions/sanctions-regimes/Pages/sanctions-regimes.aspx][definitions of supply and publishing]], however, indicate that this work
would likely only ever be considered publishing.
-The reason for this is that all the existing software on which this work
-is built is what Defence classifies as being in the public domain. In
-this context that is not the same as the term is used for copyright and
-licensing, it means that the software and information is already freely
-available to anyone. Thus it would be the same for all or almost all
-free (libre) and open source software.
+The reason for this is that all the existing software on which this
+work is built is what Defence classifies as being in the public
+domain. In this context that is not the same as the term is used for
+copyright and licensing, it means that the software and information is
+already freely available to anyone. Thus it would be the same for all
+or almost all free (libre) and open source software.
Only Australian cryptographers developing entirely new encryption
-algortithms are likely to be directly impacted by the provisions of the
-DCTA. I am very much /not/ in that category. Furthermore, any algorithm
-added to the specifications for GPG would need to pass through an
-international selection process anyway, by which stage it would be
-exempt from these types of restrictions because it would already be in
-the public domain as far as Australia's Department of Defence is
-concerned.
+algortithms are likely to be directly impacted by the provisions of
+the DCTA. I am very much /not/ in that category. Furthermore, any
+algorithm added to the specifications for GPG would need to pass
+through an international selection process anyway, by which stage it
+would be exempt from these types of restrictions because it would
+already be in the public domain as far as Australia's Department of
+Defence is concerned.
The results of my completed questionnaire are available [[Australian_DCTA_export_DECO_Questionnaire_Results.pdf][here]] (PDF) and
-a GPG signature of the file is [[Australian_DCTA_export_DECO_Questionnaire_Results.pdf.sig][here]]. The file is signed with my key
+a GPG signature of the file is [[Australian_DCTA_export_DECO_Questionnaire_Results.pdf.sig][here]]. The file is signed with my key
(ID 0x321E4E2373590E5D).
With regards to current sanctions by Australia against any entity as
referenced in that document and available [[http://dfat.gov.au/international-relations/security/sanctions/pages/sanctions.aspx][here]], my method of
publication consists of uploading information to the GPG git server in
-Germany. Germany is not currently a sanctioned country by Australia,
+Germany. Germany is not currently a sanctioned country by Australia,
nor are any of the involved companies sanctioned separately. In fact,
the only reference to Germany on Australia's list of sanctioned
entities pertains to a number of individuals, mostly members of
Al-Qaeda, currently serving time in German prisons or having been
-deported from Germany. Additional details on those sanctions can be
+deported from Germany. Additional details on those sanctions can be
found [[http://dfat.gov.au/international-relations/security/sanctions/Pages/consolidated-list.aspx][here]] and [[http://dfat.gov.au/international-relations/security/sanctions/sanctions-regimes/Pages/sanctions-regimes.aspx][here]].
diff --git a/lang/gpygme/docs/README.org b/lang/gpygme/docs/README.org
index 6046e83..284c38f 100644
--- a/lang/gpygme/docs/README.org
+++ b/lang/gpygme/docs/README.org
@@ -3,41 +3,42 @@
** Project Goal
Intended as both a replacement of the older PyME bindings for Python 2
-and Python 3, though it will only be implemented in Python 3. Some
-effort may be made to allow it to work as a module or series of modules
-in Python 2, but there are no guarantees.
-
-GPyGME is intended to be the official API for third party (i.e. non-C)
-languages and bindings. While it should be able to be imported into any
-Python 3 code as a normal Python module or library, this is not the
-principal goal. The real value is in providing an API for everyone by
-providing a pseudo-REST style API. It is not actually a REST API because
-it is not purely web-based, though could be implemented that way (and
-almost certainly will be by many).
-
-GPyGME will accept and respond with JSON data types to provide a method
-of interaction with GPGME with which most, if not all, modern
-application developers are familiar. Consequently the bindings ought to
-be usable by anyone for any purpose for which GPGME could meet the need.
+and Python 3, though it will only be implemented in Python 3. Some
+effort may be made to allow it to work as a module or series of
+modules in Python 2, but there are no guarantees.
+
+GPyGME is intended to be the official API for third party (i.e.
+non-C) languages and bindings. While it should be able to be imported
+into any Python 3 code as a normal Python module or library, this is
+not the principal goal. The real value is in providing an API for
+everyone by providing a pseudo-REST style API. It is not actually a
+REST API because it is not purely web-based, though could be
+implemented that way (and almost certainly will be by many).
+
+GPyGME will accept and respond with JSON data types to provide a
+method of interaction with GPGME with which most, if not all, modern
+application developers are familiar. Consequently the bindings ought
+to be usable by anyone for any purpose for which GPGME could meet the
+need.
** Project Name
GPyGME, with the first "G" being silent is pronounced the same way as
-[[https://en.wikipedia.org/wiki/Pygmy_peoples][pygme]]. It could be thought of as a diminutive form of GPGME with the
+[[https://en.wikipedia.org/wiki/Pygmy_peoples][pygme]]. It could be thought of as a diminutive form of GPGME with the
ability to unlock just as much power.
** Licensing
-GPyGME utilises the LGPL 2.1+ license, the same as GPGME itself. As it
-is built on GPGME this is a requirement. Documentation will be covered
-by both the GPLv3+ as with the GPGME documentation and a Creative
-Commons license.
+GPyGME utilises the LGPL 2.1+ license, the same as GPGME itself. As
+it is built on GPGME this is a requirement. Documentation will be
+covered by both the GPLv3+ as with the GPGME documentation and a
+Creative Commons license.
Note that interacting with the GPyGME API as a stand alone interface
-(i.e. sending and receiving JSON data to it via a socket, command or
+(i.e. sending and receiving JSON data to it via a socket, command or
other connection type) does not require conforming with either the GPL
-or LGPL licenses. Only when importing or integrating this code into your
-own application does that become a requirement.
+or LGPL licenses. Only when importing or integrating this code into
+your own application does that become a requirement.
** Feedback
-----------------------------------------------------------------------
Summary of changes:
lang/gpygme/docs/FAQ.org | 72 ++++++++++++++++++++++-----------------------
lang/gpygme/docs/README.org | 49 +++++++++++++++---------------
2 files changed, 61 insertions(+), 60 deletions(-)
hooks/post-receive
--
GnuPG Made Easy
http://git.gnupg.org
More information about the Gnupg-commits
mailing list