119 lines
6.5 KiB
Org Mode
119 lines
6.5 KiB
Org Mode
* 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]].
|