python bindings howto: dita version
* Numerous updates to bring it back into sync with the official doc. * Especially important since it now looks like the babel thing is a real bug after all and not me doing something stupid.
This commit is contained in:
Ben McGinnes
parent
dda54cc851
commit
1e34141f67
@ -39,7 +39,7 @@
|
|||||||
<topicref id="python-bindings" href="howto/part02/python-bindings.dita"/>
|
<topicref id="python-bindings" href="howto/part02/python-bindings.dita"/>
|
||||||
<topicref id="py-diffs" href="howto/part02/differences-to-others.dita">
|
<topicref id="py-diffs" href="howto/part02/differences-to-others.dita">
|
||||||
<topicref id="vinay-sajip" href="howto/part02/python-gnupg.dita"/>
|
<topicref id="vinay-sajip" href="howto/part02/python-gnupg.dita"/>
|
||||||
<topicref id="isis-lovecruft" href="howto/part02/daesh.dita"/>
|
<topicref id="isis-lovecruft" href="howto/part02/isis-gnupg.dita"/>
|
||||||
<topicref id="martin-albrecht" href="howto/part02/pyme.dita"/>
|
<topicref id="martin-albrecht" href="howto/part02/pyme.dita"/>
|
||||||
</topicref>
|
</topicref>
|
||||||
</topicref>
|
</topicref>
|
||||||
|
|||||||
@ -16,8 +16,8 @@
|
|||||||
<p>For Python 2 it checks for these executables in this order: <cmdname>python</cmdname>,
|
<p>For Python 2 it checks for these executables in this order: <cmdname>python</cmdname>,
|
||||||
<cmdname>python2</cmdname> and <cmdname>python2.7</cmdname>.</p>
|
<cmdname>python2</cmdname> and <cmdname>python2.7</cmdname>.</p>
|
||||||
<p>For Python 3 it checks for these executables in this order: <cmdname>python3</cmdname>,
|
<p>For Python 3 it checks for these executables in this order: <cmdname>python3</cmdname>,
|
||||||
<cmdname>python3.6</cmdname>, <cmdname>python3.5</cmdname> and
|
<cmdname>python3.6</cmdname>, <cmdname>python3.5</cmdname>, <cmdname>python3.4</cmdname>
|
||||||
<cmdname>python3.4</cmdname>.</p>
|
and <cmdname>python3.7</cmdname>.</p>
|
||||||
</body>
|
</body>
|
||||||
</topic>
|
</topic>
|
||||||
</dita>
|
</dita>
|
||||||
|
|||||||
@ -5,9 +5,9 @@
|
|||||||
<title>Exporting Public Keys</title>
|
<title>Exporting Public Keys</title>
|
||||||
<body>
|
<body>
|
||||||
<p>There are two methods of exporting public keys, both of which are very similar to the
|
<p>There are two methods of exporting public keys, both of which are very similar to the
|
||||||
other. The default method, <codeph>key_export()</codeph> will export a public key or keys
|
other. The default method, <codeph>key_export()</codeph>, will export a public key or keys
|
||||||
matching a specified pattern as normal. The alternative, the
|
matching a specified pattern as normal. The alternative, the
|
||||||
<codeph>key_export_minimal()</codeph> method will do the same thing except producing a
|
<codeph>key_export_minimal()</codeph> method, will do the same thing except producing a
|
||||||
minimised output with extra signatures and third party signatures or certifications
|
minimised output with extra signatures and third party signatures or certifications
|
||||||
removed.</p>
|
removed.</p>
|
||||||
<p>
|
<p>
|
||||||
|
|||||||
74
lang/python/docs/dita/howto/part03/importing-eff-keys.dita
Normal file
74
lang/python/docs/dita/howto/part03/importing-eff-keys.dita
Normal file
@ -0,0 +1,74 @@
|
|||||||
|
<?xml version="1.0" encoding="UTF-8"?>
|
||||||
|
<!DOCTYPE dita PUBLIC "-//OASIS//DTD DITA Composite//EN" "ditabase.dtd">
|
||||||
|
<dita xml:lang="en-GB">
|
||||||
|
<topic id="eff-key-import">
|
||||||
|
<title>Importing Keys</title>
|
||||||
|
<shortdesc>DRAFT VERSION</shortdesc>
|
||||||
|
<body>
|
||||||
|
<p>Importing keys is possible with the <codeph>key_import()</codeph> method and takes one
|
||||||
|
argument which is a bytes literal object containing either the binary or ASCII armoured key
|
||||||
|
data for one or more keys.</p>
|
||||||
|
<p>In the following example a key will be retrieved from the SKS keyservers via the web using
|
||||||
|
the requests module. Since requests returns the content as a bytes literal object, we can
|
||||||
|
then use that directly to import the resulting data into our keybox. In order to demonstrate
|
||||||
|
multiple imports this example searches for all the keys of users at a particular domain
|
||||||
|
name. This time we're using the EFF, since they've always been such good supporters of
|
||||||
|
strong encryption and good security practices.</p>
|
||||||
|
<p>If this holds true then I would expect that some keys I already have will be updated and
|
||||||
|
some others will be added. Most of the keys created most recently and belonging to still
|
||||||
|
active people within the EFF should, if they are following their own recent statements, be
|
||||||
|
revoked. If they are not revoked then it would be best left to the reader to determine
|
||||||
|
whether or not the change in leadership at that organisation indicates a change in their
|
||||||
|
policy of supporting good security practices.</p>
|
||||||
|
<p>
|
||||||
|
<codeblock id="import-key-1" outputclass="language-python">import gpg
|
||||||
|
import requests
|
||||||
|
|
||||||
|
c = gpg.Context()
|
||||||
|
url = "https://sks-keyservers.net/pks/lookup"
|
||||||
|
pattern = input("Enter the pattern to search for key or user IDs: ")
|
||||||
|
payload = { "op": "get", "search": pattern }
|
||||||
|
|
||||||
|
r = requests.get(url, verify=True, params=payload)
|
||||||
|
k = c.key_import(r.content)
|
||||||
|
|
||||||
|
summary = """
|
||||||
|
Total number of keys: {0}
|
||||||
|
Total number imported: {1}
|
||||||
|
Number of version 3 keys ignored: {2}
|
||||||
|
|
||||||
|
Number of imported key objects or updates: {3}
|
||||||
|
Number of unchanged keys: {4}
|
||||||
|
Number of new signatures: {5}
|
||||||
|
Number of revoked keys: {6}
|
||||||
|
""".format(k.considered, len(k.imports), k.skipped_v3_keys, k.imported,
|
||||||
|
k.unchanged, k.new_signatures, k.new_revocations)
|
||||||
|
|
||||||
|
print(summary)</codeblock>
|
||||||
|
</p>
|
||||||
|
<p>The resulting output in that case, where the search pattern entered was
|
||||||
|
<codeph>@eff.org</codeph> was:</p>
|
||||||
|
<p>
|
||||||
|
<codeblock id="import-key-2" outputclass="language-bourne">Total number of keys: 272
|
||||||
|
Total number imported: 249
|
||||||
|
Number of version 3 keys ignored: 23
|
||||||
|
|
||||||
|
Number of imported key objects or updates: 180
|
||||||
|
Number of unchanged keys: 66
|
||||||
|
Number of new signatures: 7
|
||||||
|
Number of revoked keys: 0</codeblock>
|
||||||
|
</p>
|
||||||
|
<p>The 23 skipped keys all date back to the 1990s, some of which were made very shortly after
|
||||||
|
PGP 2 was first released.</p>
|
||||||
|
<p>
|
||||||
|
<note>Pretty Good Privacy version 2 and above are the only versions with any widespread use.
|
||||||
|
Pretty Good Privacy version 1 had a number of serious security problems, not least of
|
||||||
|
which being that it relied on an encryption algorithm called Bass-O-Matic which was
|
||||||
|
written by Phil Zimmermann. Following feedback on this algorithm, Zimmermann withdrew
|
||||||
|
version 1 and re-implemented version 2 using RSA and IDEA, even though both were subject
|
||||||
|
to software patents at the time (both of those software patents have long since
|
||||||
|
expired).</note>
|
||||||
|
</p>
|
||||||
|
</body>
|
||||||
|
</topic>
|
||||||
|
</dita>
|
||||||
@ -4,7 +4,7 @@
|
|||||||
<topic id="topic_vnz_nn2_vdb">
|
<topic id="topic_vnz_nn2_vdb">
|
||||||
<title>Documentation Version</title>
|
<title>Documentation Version</title>
|
||||||
<body>
|
<body>
|
||||||
<p><b>Version:</b> 0.1.2-DRAFT</p>
|
<p><b>Version:</b> 0.1.3-DRAFT</p>
|
||||||
<p><b>Author:</b> Ben McGinnes <<xref href="mailto:ben@gnupg.org" format="html"
|
<p><b>Author:</b> Ben McGinnes <<xref href="mailto:ben@gnupg.org" format="html"
|
||||||
scope="external">ben@gnupg.org</xref>></p>
|
scope="external">ben@gnupg.org</xref>></p>
|
||||||
<p><b>Author GPG Key ID:</b>
|
<p><b>Author GPG Key ID:</b>
|
||||||
|
|||||||
Loading…
Reference in New Issue
Block a user