[git] GPGME - branch, ben/gpygme, updated. gpgme-1.5.5-8-g434dd67
by Ben McGinnes
cvs at cvs.gnupg.org
Fri Jun 26 11:56:27 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 434dd67170d29aac6f4232a1135cc8b43834d052 (commit)
via b2f298e7d03518a2cc93143c24b72e0847d89901 (commit)
from 3c5f25fb8f699d4aa659781041db419d3e9a1bc5 (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 434dd67170d29aac6f4232a1135cc8b43834d052
Author: Ben McGinnes <ben at adversary.org>
Date: Fri Jun 26 19:54:06 2015 +1000
rst2org, part 2
* Converted README.rst to Org-Mode with Pandoc and subsequent paragraph
fixes in Emacs.
diff --git a/lang/gpygme/docs/FAQ.rst b/lang/gpygme/docs/FAQ.rst
deleted file mode 100644
index 9161f85..0000000
--- a/lang/gpygme/docs/FAQ.rst
+++ /dev/null
@@ -1,53 +0,0 @@
-===========================
-Frequently Asked‡ Questions
-===========================
-
-‡ At this stage these are more like Frequently Anticipated Questions.
-
------------------
-Using the Project
------------------
-
-**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 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. `python-gnupg <https://bitbucket.org/vinay.sajip/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.
-
-**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 communicating with another system and not integrating that system into 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).
-
-------------------------------
-Australian Developers and ITAR
-------------------------------
-
-**1. The current author/maintainer is in Australia, won't that cause 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 `Defence Trade Control Act 2012 <http://www.austlii.edu.au/au/legis/cth/num_act/dtca2012207/>`_ (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 and encryption software as being in Part 2 of the `Defence Trade Cooperation Munitions List <http://www.austlii.edu.au/au/legis/cth/num_act/dtca2012207/s4.html#defense_trade_cooperation_munitions_list>`_, but neither GPGME nor GPyGME are 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 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.
-
-**3. In April 2016 the enforcement provisions of the DTCA come into force, could that change anything here?**
-
-If the Minister of Defence makes a specific announcement in Parliament 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.
-
-**4. What assurances can you give that this will remain the case and everything will be fine?**
-
-The Department of Defence's `Defence Export Control Office <http://www.defence.gov.au/DECO/Default.asp>`_ (DECO) provides numerous resources to address concerns relating to this type of development. Included in this is the `Defence and Strategic Goods List <https://dsgl.defence.gov.au/pages/home.aspx>`_ (DSGL) and its accompanying `Activity Questionnaire <https://dsgl.defence.gov.au/pages/questionnaire.aspx>`_ and `Online DSGL Search Tool <https://dsgl.defence.gov.au/pages/search.aspx>`_.
-
-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 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 `definitions of supply and publishing <http://dfat.gov.au/international-relations/security/sanctions/sanctions-regimes/Pages/sanctions-regimes.aspx>`_, 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.
-
-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.
-
-The results of my completed questionnaire are available `here <Australian_DCTA_export_DECO_Questionnaire_Results.pdf>`_ (PDF) and a GPG signature of the file is `here <Australian_DCTA_export_DECO_Questionnaire_Results.pdf.sig>`_. 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 `here <http://dfat.gov.au/international-relations/security/sanctions/pages/sanctions.aspx>`_, my method of publication consists of uploading information to the GPG git server in 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 found `here <http://dfat.gov.au/international-relations/security/sanctions/Pages/consolidated-list.aspx>`_ and `here <http://dfat.gov.au/international-relations/security/sanctions/sanctions-regimes/Pages/sanctions-regimes.aspx>`_.
diff --git a/lang/gpygme/docs/README.org b/lang/gpygme/docs/README.org
new file mode 100644
index 0000000..6046e83
--- /dev/null
+++ b/lang/gpygme/docs/README.org
@@ -0,0 +1,45 @@
+* GPyGME
+
+** 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.
+
+** 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
+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.
+
+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
+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.
+
+** Feedback
+
+GPyGME is written and maintained by [[mailto:ben at adversary.org][Ben McGinnes]], but discussion ought
+to be conducted on the [[https://lists.gnupg.org/mailman/listinfo/gnupg-devel][gnupg-devel]] mailing list.
diff --git a/lang/gpygme/docs/README.rst b/lang/gpygme/docs/README.rst
deleted file mode 100644
index 9228d4e..0000000
--- a/lang/gpygme/docs/README.rst
+++ /dev/null
@@ -1,34 +0,0 @@
-======
-GPyGME
-======
-
-------------
-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.
-
-------------
-Project Name
-------------
-
-GPyGME, with the first "G" being silent is pronounced the same way as `pygme <https://en.wikipedia.org/wiki/Pygmy_peoples>`_. 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.
-
-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 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.
-
---------
-Feedback
---------
-
-GPyGME is written and maintained by `Ben McGinnes <mailto:ben at adversary.org>`_, but discussion ought to be conducted on the `gnupg-devel <https://lists.gnupg.org/mailman/listinfo/gnupg-devel>`_ mailing list.
-
commit b2f298e7d03518a2cc93143c24b72e0847d89901
Author: Ben McGinnes <ben at adversary.org>
Date: Fri Jun 26 19:49:10 2015 +1000
rst2org
* Converted FAQ.rst to Org-Mode with Pandoc and subsequent paragraph
fixes in Emacs.
diff --git a/lang/gpygme/docs/FAQ.org b/lang/gpygme/docs/FAQ.org
new file mode 100644
index 0000000..37cfb74
--- /dev/null
+++ b/lang/gpygme/docs/FAQ.org
@@ -0,0 +1,118 @@
+* Frequently Asked‡ Questions
+
+‡ At this stage these are more like Frequently Anticipated Questions.
+
+** Using the Project
+
+*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
+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
+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.
+
+*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
+communicating with another system and not integrating that system into
+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).
+
+** Australian Developers and ITAR
+
+*1. The current author/maintainer is in Australia, won't that cause
+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),
+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
+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
+accessing what it refers to as encryption engines; currently the
+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.
+
+*3. In April 2016 the enforcement provisions of the DTCA come into
+force, could that change anything here?*
+
+If the Minister of Defence makes a specific announcement in Parliament
+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.
+
+*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
+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
+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
+[[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.
+
+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.
+
+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
+(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,
+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
+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]].
-----------------------------------------------------------------------
Summary of changes:
lang/gpygme/docs/FAQ.org | 118 ++++++++++++++++++++++++++++++++++++++++++++
lang/gpygme/docs/FAQ.rst | 53 --------------------
lang/gpygme/docs/README.org | 45 +++++++++++++++++
lang/gpygme/docs/README.rst | 34 -------------
4 files changed, 163 insertions(+), 87 deletions(-)
create mode 100644 lang/gpygme/docs/FAQ.org
delete mode 100644 lang/gpygme/docs/FAQ.rst
create mode 100644 lang/gpygme/docs/README.org
delete mode 100644 lang/gpygme/docs/README.rst
hooks/post-receive
--
GnuPG Made Easy
http://git.gnupg.org
More information about the Gnupg-commits
mailing list