* Added a miscellaneous work-arounds section at the end.
* Included code in said miscellaneous section for accessing the groups
specified in a gpg.conf file.
* It's a bit ugly since it does require subprocess (but not call,
Popen or shell access and only accesses one command).
* updated multi-encryption final example to be complete.
* second example shows most likely method of reading plaintext.
* updated example filenames to stick with running gag
(i.e. secret_plans.txt).
* error corrections.
* multiple typesetting fixes only required due to certain archaic
eccentricities of LaTeX.
* a couple of minor python PEP8 compliance corrections.
* Added a more complicated encryption example with a few variations on
the encryption method to account for untrusted recipient keys,
signing or not signing, including or excluding default keys and so
on.
* Switched from links to some external docs to using footnotes where
necessary.
* Ideally the howto should be as stand alone as possible.
* Also it makes it difficult to convert to another format for
proof-reading if there are links that the conversion can't find.
* Wrote the text description explaining each step in the most basic
encryption operation.
* Will need to include additional examples for encrypting to multiple
recipients using Context().encrypt instead of Context().op_encrypt.
* Added all four signing code examples that are most likely to be
used: armoured, clearsigned, detached armoured and detached binary.
* May remove some examples and just discuss the differences, but it
depends on the way the text is filled out.
* Added sample code for encrypting some text to a single key.
* Basically I'm just lifting existing production code and changing the
key IDs from mine to "0x12345678DEADBEEF" for these first few
examples.
* I'll fill in the text description after.
* Note: due to my regional location, I might split some tasks into
more commits in order to be sure no work gets lost in case of
emergency (or to put it another way: I know Telstra too well to
trust them).
* Added a section for those pythonistas who are too used to web
programming. Stressed that it's not simply not RESTful, it's not
even REST-like.
* Letting me move on to drawing a very loose parallel between a
session and a context. The differences should become obvious in the
subsequent sections.
* Some instructions to include are fairly obvious; as with encryption,
decryption and signature verification.
* Some are a little less obvious.
* This includes the requests received to specifically include subkey
management (adding and revoking subkeys on a primary key that's
being retained.
* Added the UID equivalents to the list, as well as key selection
matters (and may or may not include something for handling group
lines since that involves wrapping a CLI binary).
* Key control documentation and examples requested by Mike Ingle of
confidantmail.org.
* removed one bit of whitespace.
* Marked up references to gpgme.h.
* Fixed one spelling error.
* Removed py2.6 from python search order since even if it is
supported, it shouldn't be encouraged.
* Started work on the GPGME Python bindings HOWTO.
* 1,050 words to begin with at approx. 7.5KB.
* Got as far as installation.
* Includes instruction not to use PyPI for this.
* Set LaTeX headers to enable ligatures and a 12pt font by default.
* Paper size left for regional defaults.
* Using XeLaTeX for easier font control.
* Using default LaTeX font of Latin Main, but that's easy enough to change.
* The developers of Phabricator, the web front-end on dev.gnupg.org
have not implemented renderers for Markdown, Org-Mode or any other
common markdown like language.
* They also refuse to do so.
* Instead they re-invented the wheel and implemented their own version
of Markdown-like thing which is incompatible with everything else.
It is called Remarkup.
* The developers of Phabricator and Remarkup have refused to provide
conversion tools to move files to/from any format to/from Remarkup.
* They expect everyone to learn their new favourite pet project.
* Remarkup may or may not display Org Mode files, but if so then it is
likely to only want to do so as plain text.
* There is an unaffiliated and unofficial project to convert Github
Markdown to Remarkup via Pandoc. This might be adapted for our use,
but requires testing.
* Until then exporting from Org Mode to UTF-8 text is likely the least
worst plan.
* Which means renaming this file to README.org first.
* Removed Markdown style heading underlining.
* Removed in-line file type declaration (which is not correctly parsed
by the web interface on dev.gnupg.org).
* Fixed or updated the most fundamental errors.
* Also included some details on which modules are available on PyPI,
as well as what happened to the PyME commit log.
* Updated TODO.
* The entirety of the old TODO has been replaced with either more
relevant tasks or goals for the examples and a more measured
approach to the docs and why, in this project, Org Mode trumps reST,
even though it's Python through and through.
* lang/python/gpgme.i: copied signature from gpgme.h and defaulted the
value to SEEK_SET.
* lang/python/tests/t-data.py: Added a test for no second argument
--
Having to import the os package when wanting to read a Data object is a
slight annoyance. With SWIG, we can define default parameters. This
change defaults the whence argument to SEEK_SET which is how StringIO
and BytesIO behave.
Signed-off-by: Tobias Mueller <muelli@cryptobitch.de>
* lang/python/tests/Makefile.am: Distinguish target and path.
* tests/gpg/Makefile.am: Ditto.
* tests/gpgsm/Makefile.am: Ditto.
--
GNU Make is powerful enough to match path to target (and vice versa),
but BSD make is not.
GnuPG-bug-id: 3056
Signed-off-by: NIIBE Yutaka <gniibe@fsij.org>
