r00t2/optools
1
0
Fork 0
Code Issues Pull Requests Projects Releases Activity

adding the rewrite...

Browse Source
This commit is contained in:
brent s
2017-09-19 05:09:33 -04:00
parent 23a0dfedb1
commit 4da7afdeaf
9 changed files with 1216 additions and 230 deletions
Download Patch File Download Diff File Expand all files Collapse all files

15
gpg/kant/docs/README Normal file
View File

@@ -0,0 +1,15 @@
GENERATING THE MAN PAGE:
If you have asciidoctor installed, you can generate the manpage one of two ways.
The first way:
asciidoctor -b manpage kant.1.adoc -o- | groff -Tascii -man | gz -c > kant.1.gz
This will generate a fixed-width man page.
The second way (recommended):
asciidoctor -b manpage kant.1.adoc -o- | gz -c > kant.1.gz
This will generate a dynamic-width man page. Most modern versions of man want this version.

42
gpg/kant/docs/REF.args.struct.txt Normal file
View File

@@ -0,0 +1,42 @@
The __init__() function of kant.SigSession() takes a single argument: args.
it should be a dict, structured like this:
{'batch': False,
'checklevel': None,
'gpgdir': '/home/bts/.gnupg',
'keys': 'EFD9413B17293AFDFE6EA6F1402A088DEDF104CB,admin@sysadministrivia.com',
'keyservers': 'hkp://sks.mirror.square-r00t.net:11371,hkps://hkps.pool.sks-keyservers.net:443,http://pgp.mit.edu:80',
'local': 'false',
'notify': True,
'sigkey': '748231EBCBD808A14F5E85D28C004C2F93481F6B',
'testkeyservers': False,
'trustlevel': None}
The gpgdir, sigkey, and keyservers are set from system defaults in kant.parseArgs() if it's run interactively.
This *may* be reworked in the future to provide a mechanism for external calls to kant.SigSession() but for now,
it's up to you to provide all the data in the dict in the above format.
It will then internally verify these items and do various conversions, so that self.args becomes this:
{'batch': False,
'checklevel': None,
'gpgdir': '/home/bts/.gnupg',
'keys': ['EFD9413B17293AFDFE6EA6F1402A088DEDF104CB',
'admin@sysadministrivia.com'],
'keyservers': [{'port': [11371, ['tcp', 'udp']],
'proto': 'hkp',
'server': 'sks.mirror.square-r00t.net'},
{'port': [443, ['tcp']],
'proto': 'hkps',
'server': 'hkps.pool.sks-keyservers.net'},
{'port': [80, ['tcp']],
'proto': 'http',
'server': 'pgp.mit.edu'}],
'local': 'false',
'notify': True,
'rcpts': {'EFD9413B17293AFDFE6EA6F1402A088DEDF104CB': {'type': 'fpr'},
'admin@sysadministrivia.com': {'type': 'email'}},
'sigkey': '748231EBCBD808A14F5E85D28C004C2F93481F6B',
'testkeyservers': False,
'trustlevel': None}

33
gpg/kant/docs/REF.funcs.struct.txt Normal file
View File

@@ -0,0 +1,33 @@
The following functions are available within the SigSession() class:
getTpls()
Get the user-specified templates if they exist, otherwise set up stock ones.
modifyDirmngr(op)
*op* can be either:
new/start/replace - modify dirmngr to use the runtime-specified keyserver(s)
old/stop/restore - modify dirmngr back to the keyservers that were defined before modification
buildKeys()
build out the keys dict (see REF.keys.struct.txt).
getKeys()
fetch keys in the keys dict (see REF.keys.struct.txt) from a keyserver if they aren't found in the local keyring.
trustKeys()
set up trusts for the keys in the keys dict (see REF.keys.struct.txt). prompts for each trust not found/specified at runtime.
sigKeys()
sign keys in the keys dict (see REF.keys.struct.txt), either exportable or local depending on runtime specification.
pushKeys()
push keys in the keys dict (see REF.keys.struct.txt) to the keyservers specified at runtime (as long as they weren't specified to be local/non-exportable signatures; then we don't bother).
sendMails()
send emails to each of the recipients specified in the keys dict (see REF.keys.struct.txt).
serverParser(uri)
returns a dict of a keyserver URI broken up into separate components easier for parsing.
verifyArgs(locargs)
does some verifications, classifies certain data, calls serverParser(), etc.

44
gpg/kant/docs/REF.keys.struct.txt Normal file
View File

@@ -0,0 +1,44 @@
TYPES:
d = dict
l = list
s = string
i = int
b = binary (True/False)
o = object
- pkey's dict key is the 40-char key ID of the primary key
- "==>" indicates the next item is a dict and the current item may contain one or more elements of the same format,
"++>" is a list,
"-->" is a "flat" item (string, object, int, etc.)
-"status" is one of "an UPGRADE", "a DOWNGRADE", or "a NEW TRUST".
keys(d) ==> (40-char key ID)(s) ==> pkey(d) --> email(s)
--> name(s)
--> creation (o, datetime)
--> key(o, gpg)
--> trust(i)
--> check(i)
--> local(b)
--> notify(b)
==> subkeys(d) ==> (40-char key ID)(s) --> creation
--> change(b)
--> sign(b)
--> status(s)
==> uids(d) ==> email(s) --> name(s)
--> comment(s)
--> email(s)
--> updated(o, datetime)
for email templates, they are looped over for each key dict as "key".
so for example, instead of specifying "keys['748231EBCBD808A14F5E85D28C004C2F93481F6B']['pkey']['name']",
you instead should specify "key['pkey']['name']". To get the name of e.g. the second uid,
you'd use "key['uids'][(uid email)]['name'].
the same structure is available via the "mykey" dictionary. e.g. to get the key ID of *your* key,
you can use "mykey['subkeys'][0][0]".
you also have the following variables/lists/etc. available for templates (via the Jinja2 templating syntax[0]):
- "keyservers", a list of keyservers set.
[0] http://jinja.pocoo.org/docs/2.9/templates/

168
gpg/kant/docs/kant.1.adoc Normal file
View File

@@ -0,0 +1,168 @@
= kant(1)
Brent Saner
v1.0.0
:doctype: manpage
:manmanual: KANT - Keysigning and Notification Tool
:mansource: KANT
:man-linkstyle: pass:[blue R < >]
== NAME
KANT - Sign GnuPG/OpenPGP/PGP keys and notify the key owner(s)
== SYNOPSIS
*kant* [_OPTION_] -k/--key _<KEY_IDS|BATCHFILE>_
== OPTIONS
Keysigning (and keysigning parties) can be a lot of fun, and can offer someone with new keys a way into the WoT (Web-of-Trust).
Unfortunately, they can be intimidating to those new to the experience.
This tool offers a simple and easy-to-use interface to sign public keys (normal, local-only, and/or non-exportable),
set owner trust, specify level of checking done, and push the signatures to a keyserver. It even supports batch operation via a CSV file.
*-h*, *--help*::
Display brief help/usage and exit.
*-k* _KEY_IDS|BATCHFILE_, *--key* _KEY_IDS|BATCHFILE_::
A single or comma-separated list of key IDs (see *KEY ID FORMAT*) to sign, trust, and notify. Can also be an email address.
If *-b*/*--batch* is specified, this should instead be a path to the batch file (see *BATCHFILE/Format*).
*-K* _KEY_ID_, *--sigkey* _KEY_ID_::
The key to use when signing other keys (see *KEY ID FORMAT*). The default key is automatically determined at runtime
(it will be displayed in *-h*/*--help* output).
*-t* _TRUSTLEVEL_, *--trust* _TRUSTLEVEL_::
The trust level to automatically apply to all keys (if not specified, KANT will prompt for each key).
See *BATCHFILE/TRUSTLEVEL* for trust level notations.
*-c* _CHECKLEVEL_, *--check* _CHECKLEVEL_::
The level of checking that was done to confirm the validity of ownership for all keys being signed. If not specified,
the default is for KANT to prompt for each key we sign. See *BATCHFILE/CHECKLEVEL* for check level notations.
*-l* _LOCAL_, *--local* _LOCAL_::
If specified, make the signature(s) local-only (i.e. non-exportable, don't push to a keyserver).
See *BATCHFILE/LOCAL* for more information on local signatures.
*-n*, *--no-notify*::
This requires some explanation. If you have MSMTPfootnote:[\http://msmtp.sourceforge.net/] installed and configured for the currently active user,
then we will send out emails to recipients letting them know we have signed their key. However, if MSMTP is installed and configured
but this flag is given, then we will NOT attempt to send emails.
*-s* _KEYSERVER(S)_, *--keyservers* _KEYSERVER(S)_::
The comma-separated keyserver(s) to push to. The default keyserver list is automatically generated at runtime.
*-b*, *--batch*::
If specified, operate in batch mode. See *BATCHFILE* for more information.
*-D* _GPGDIR_, *--gpgdir* _GPGDIR_::
The GnuPG configuration directory to use (containing your keys, etc.). The default is automatically generated at runtime,
but will probably be */home/<yourusername>/.gnupg* or similar.
*-T*, *--testkeyservers*::
If specified, initiate a basic test connection with each set keyserver before anything else. Disabled by default.
== KEY ID FORMAT
Key IDs can be specified in one of two ways. The first (and preferred) way is to use the full 160-bit (40-character, hexadecimal) key ID.
A little known fact is the fingerprint of a key:
*DEAD BEEF DEAD BEEF DEAD BEEF DEAD BEEF DEAD BEEF*
is actually the full key ID of the primary key; i.e.:
*DEADBEEFDEADBEEFDEADBEEFDEADBEEFDEADBEEF*
The second way to specify a key, as far as KANT is concerned, is to use an email address.
Do note that if more than one key is found that matches the email address given (and they usually are), you will be prompted to select the specific
correct key ID anyways so it's usually a better idea to have the owner present their full key ID/fingerprint right from the get-go.
== BATCHFILE
=== Format
The batch file is a CSV-formatted (comma-delimited) file containing keys to sign and other information about them. It keeps the following format:
*KEY_ID,TRUSTLEVEL,LOCAL,CHECKLEVEL,NOTIFY*
For more information on each column, reference the appropriate sub-section below.
=== KEY_ID
See *KEY ID FORMAT*.
=== TRUSTLEVEL
The _TRUSTLEVEL_ is specified by the following levels (you can use either the numeric or string representation):
[subs=+quotes]
....
*-1 = Never
0 = Unknown
1 = Untrusted
2 = Marginal
3 = Full
4 = Ultimate*
....
It is how much trust to assign to a key, and the signatures that key makes on other keys.footnote:[For more information
on trust levels and the Web of Trust, see: \https://www.gnupg.org/gph/en/manual/x334.html and \https://www.gnupg.org/gph/en/manual/x547.html]
=== LOCAL
Whether or not to push to a keyserver. It can be either the numeric or string representation of the following:
[subs=+quotes]
....
*0 = False
1 = True*
....
If *1/True*, KANT will sign the key with a local signature (and the signature will not be pushed to a keyserver or be exportable).footnote:[For
more information on pushing to keyservers and local signatures, see: \https://www.gnupg.org/gph/en/manual/r899.html#LSIGN and
\https://lists.gnupg.org/pipermail/gnupg-users/2007-January/030242.html]
=== CHECKLEVEL
The amount of checking that has been done to confirm that the owner of the key is who they say they are and that the key matches their provided information.
It can be either the numeric or string representation of the following:
[subs=+quotes]
....
*0 = Unknown
1 = None
2 = Casual
3 = Careful*
....
It is up to you to determine the classification of the amount of checking you have done, but the following is recommended (it is the policy
the author follows):
[subs=+quotes]
....
*Unknown:* The key is unknown and has not been reviewed
*None:* The key has been signed, but no confirmation of the
ownership of the key has been performed (typically
a local signature)
*Casual:* The key has been presented and the owner is either
known to the signer or they have provided some form
of non-government-issued identification or other
proof (website, Keybase.io, etc.)
*Careful:* The same as *Casual* requirements but they have
provided a government-issued ID and all information
matches
....
It's important to check each key you sign carefully. Failure to do so may hurt others' trust in your key.footnote:[GnuPG documentation refers
to this as "validity"; see \https://www.gnupg.org/gph/en/manual/x334.html]
== SEE ALSO
gpg(1), gpgconf(1)
== RESOURCES
*Author's web site:* https://square-r00t.net/
*Author's GPG information:* https://square-r00t.net/gpg-info
== COPYING
Copyright \(C) 2017 {author}.
Free use of this software is granted under the terms of the GPLv3 License.