From bd91d40ba52f3823c401cfa7dd5515b157c77dbf Mon Sep 17 00:00:00 2001 From: Ben McGinnes Date: Sat, 27 Jun 2015 03:27:10 +1000 Subject: [PATCH] Typesetting * Fixed sentence spacing and paragraph alignment following conversion from reST format. --- lang/gpygme/docs/FAQ.org | 72 ++++++++++++++++++------------------- lang/gpygme/docs/README.org | 45 +++++++++++------------ 2 files changed, 59 insertions(+), 58 deletions(-) diff --git a/lang/gpygme/docs/FAQ.org b/lang/gpygme/docs/FAQ.org index 37cfb748..12b0ddb7 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 6046e833..284c38f0 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. +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 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. +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