tiny_gnupg - A small-as-possible solution for handling GnuPG ed25519 ECC keys.
A linux specific, small, simple & intuitive wrapper for creating, using and managing GnuPG's Ed25519 curve keys. In our design, we favor reducing code size & complexity with strong, bias defaults over flexibility in the api. Our goal is to turn the powerful, complex, legacy gnupg system into a fun and safe tool to develop with.
This project is currently in unstable beta. It works like a charm, but there's likely, and often bugs floating around, and the api is subject to change. Contributions are welcome.
.. image:: https://badge.fury.io/py/tiny-gnupg.svg :target: https://badge.fury.io/py/tiny-gnupg
.. image:: https://img.shields.io/github/license/rmlibre/tiny_gnupg :alt: GitHub
.. image:: https://img.shields.io/badge/code%20style-black-000000.svg :target: https://img.shields.io/badge/code%20style-black-000000.svg
.. image:: https://github.com/rmlibre/tiny_gnupg/workflows/Python%20package/badge.svg :target: https://github.com/rmlibre/tiny_gnupg/workflows/Python%20package/badge.svg
#) Install_
#) Basic Commands_
#) Networking Examples_
#) About Torification_
#) More Commands_
#) Retiring Keys_
Install.. code:: shell
sudo apt-get install tor torsocks gnupg2 gpg-agent
pip install --user --upgrade tiny_gnupg
Basic CommandsThe GnuPG class's instances are the primary interface for running commands & managing keys using the gpg2 executable.
.. code:: python
from tiny_gnupg import GnuPG, run
PATH_TO_GPG_BINARY = "/usr/bin/gpg2"
gpg = GnuPG(
email_address="bob@user.net",
passphrase="bobs's passphrase",
executable=PATH_TO_GPG_BINARY,
)
# This will generate a primary ed25519 ECC certifying key, and three
# subkeys, one each for the authentication, encryption, and signing
# functionalities.
gpg.generate_key()
# Now this fingerprint can be used with arbitrary gpg2 commands.
gpg.fingerprint
# But the key is stored in the package's local keyring. To
# talk to the package's gpg environment, an arbitrary command
# can be constructed like this ->
options = ["--armor", "--encrypt", "-r", gpg.fingerprint]
command = gpg.encode_command(*options)
inputs = gpg.encode_inputs("Message to myself")
encrypted_message = gpg.read_output(command, inputs)
# If a command would invoke the need for a passphrase, the
# with_passphrase kwarg should be set to True ->
command = gpg.encode_command(*options, with_passphrase=True)
# The passphrase then needs to be the first arg passed to
# encode_inputs ->
inputs = gpg.encode_inputs(gpg.user.passphrase, *other_inputs)
# The list of keys in the package's environment can be accessed
# from the list_keys() method, which returns a dict ->
gpg.list_keys()
>>> {fingerprint: email_address, ...}
# Or retrieve a specific key where a searchable portion of its uid
# information is known, like an email address or fingerprint ->
gpg.list_keys("bob@user.net")
>>> {"EE36F0584971280730D76CEC94A470B77ABA6E81": "bob@user.net"}
# Let's try encrypting a message to Alice, whose public key is
# stored on keys.openpgp.org/
# First, we'll import Alice's key from the keyserver (This requires
# a Tor system installation. Or an open TorBrowser, and the tor_port
# attribute set to 9150) ->
# Optional: gpg.keyserver.network.tor_port = 9150
run(gpg.network_import(uid="alice@email.domain"))
# Then encrypt a message with Alice's key and sign it ->
msg = "So, what's the plan this Sunday, Alice?"
encrypted_message = gpg.encrypt(
message=msg, uid="alice@email.domain", sign=True
)
# The process of encrypting a message to a peer whose public key
# might not be in the local package keyring is conveniently available
# in a single method. It automatically searches for the recipient's
# key on the keyserver so it can be used to encrypt the message ->
run(gpg.auto_encrypt(msg, "alice@email.domain")) # Signing is automatic
# We could directly send a copy of our key to Alice, or upload it to
# the keyserver. Alice will need a copy so the signature on the
# message can be verified. So let's upload it to the keyserver ->
run(gpg.network_export(uid="bob@user.net"))
# Alice could now import our key (after we do an email verification
# with the keyserver) ->
run(gpg.network_import("bob@user.net"))
# Then Alice can simply receive the encrypted message and decrypt it ->
decrypted_msg = gpg.decrypt(encrypted_message)
# The process of decrypting a encrypted & signed message from a peer
# whose public key might not be in the local package keyring is
# conveniently available in a single method. It automatically determines
# the signing key fingerprint, and searches for it on the keyserver
# to verify the signature ->
decrypted_msg = run(gpg.auto_decrypt(encrypted_message))
On most systems, because of a bug in GnuPG_, email verification of uploaded keys will be necessary for others to import them from the keyserver. That's because GnuPG will throw an error immediately upon trying to import keys with their uid information stripped off.
The package no longer comes with its own gpg2 binary. Your system gpg2 executable is probably located at: /usr/bin/gpg2. You could also type: whereis gpg2 to find it. If it's not installed, you'll have to install it with your system's equivalent of: sudo apt-get install gnupg2
.. _GnuPG: https://dev.gnupg.org/T4393
Networking Examples.. code:: python
# Since we use SOCKSv5 over Tor for all of our networking, as well
# as the user-friendly aiohttp + aiohttp_socks libraries, the Tor
# networking interface is also available to users. These utilities
# allow arbitrary POST and GET requests to clearnet, or onionland,
# websites ->
from tiny_gnupg import GnuPG, Network, run
client = Network(tor_port=9050)
async def read_url(client, url):
"""
Use the instance's interface to read the page located at the url
with a wrapper around an `aiohttp.ClientSession` context manager.
"""
async with client.context_get(url) as response:
return await response.text()
# Now we can read webpages with GET requests ->
page_html = run(read_url(client, "https://keys.openpgp.org/"))
# Let's try onionland ->
url = "http://zkaan2xfbuxia2wpf7ofnkbz6r5zdbbvxbunvp5g2iebopbfc4iqmbad.onion/"
onion_page_html = run(read_url(client, url))
# Check your ip address for fun ->
ip_addr = run(read_url(client, "https://icanhazip.com/"))
# There's a convenience function built into the class that
# basically mimics read_url() ->
ip_addr = run(client.get("https://icanhazip.com/"))
# POST requests can also be sent with the context_post() method.
# Let's use a POST request to send the keyserver a new key we
# create ->
async def post_data(client, url, payload=""):
"""
Use the instance's interface to post the api payload to the
keyserver with a wrapper around an `aiohttp.ClientSession`
context manager.
"""
async with client.context_post(url, json=payload) as response:
return await response.text()
gpg = GnuPG(email_address="bob@user.net", passphrase="bobs's passphrase")
gpg.generate_key()
url = gpg.keyserver._key_export_api_url
payload = {"keytext": gpg.text_export(uid=gpg.fingerprint)}
api_token_json = run(post_data(client, url, payload))
# There's also a convenience function built into the class that
# mimics post_data() ->
api_token_json = run(client.post(url, json=payload))
# Of course, this is just for demonstration. The method that should
# be used for uploading a key to the keyserver is network_export ->
run(gpg.network_export(gpg.fingerprint))
# And there we have it, it's super simple. And these requests have
# the added benefit of being completely routed through Tor. The
# keyserver here also has a v3 onion address which we use to query,
# upload, and import keys. This provides a nice, default layer of
# privacy to our communication needs.
These networking tools work off instances of aiohttp.ClientSession. To learn more about how to use their POST and GET requests, you can read the docs here_.
.. _here: https://docs.aiohttp.org/en/stable/client_advanced.html#client-session
About TorificationA user can make sure that any connections the gnupg binary makes with the network are always run through Tor by setting torify=True during initialization.
.. code:: python
from tiny_gnupg import GnuPG
gpg = GnuPG(**user_details, torify=True)
This is helpful because there are gnupg settings which cause certain commands to do automatic connections to the web. For instance, when encrypting, gnupg may be set to automatically search for the recipient's key on a keyserver if it's not in the local keyring. This doesn't normally effect tiny_gnupg because it doesn't use gnupg's networking interface. It ensures Tor connections through the aiohttp_socks library. But, if gnupg does make these kinds of connections silently, using torify can prevent a user's IP address from being inadvertently revealed.
Using torify requires a Tor installation on the user system. If the user is running Debian / Ubuntu, then this guide_ could be helpful.
.. _guide: https://2019.www.torproject.org/docs/debian.html.en
More Commands.. code:: python
# An instance can also be constructed from lower-level objects ->
from tiny_gnupg import BaseGnuPG, User, GnuPGConfig, run
PATH_TO_GPG_BINARY = "/usr/bin/gpg2"
# Passphrases can contain any characters, even emojis ->
user = User(email_address="bob@user.net", passphrase="✅🐎🔋📌")
config = GnuPGConfig(executable=PATH_TO_GPG_BINARY, torify=True)
gpg = BaseGnuPG(user, config=config)
# It turns out that the encrypt() method automatically signs the
# message being encrypted. So, the `sign=False` flag only has to be
# passed when a user doesn't want to sign a message ->
encrypted_unsigned_message = gpg.encrypt(
message="sending message as an unidentified sender",
uid="alice@email.domain", # sending to alice,
sign=False, # no sender identification
)
# It also turns out, a user can sign things independently from
# encrypting ->
message_to_verify = "maybe a hash of a file?"
signed_data = gpg.sign(target=message_to_verify)
assert message_to_verify == gpg.decrypt(signed_data)
# And verify a signature without checking the signed value ->
gpg.verify(message=signed_data) # throws if invalid
# Or sign a key in the package's keyring ->
gpg.sign("alice@email.domain", key=True)
# Importing key files is also a thing ->
path_to_file = "/home/user/keyfiles/"
gpg.file_import(path=path_to_file + "alices_key.asc")
# As well as exporting public keys ->
gpg.file_export(path=path_to_file, uid=gpg.user.email_address)
# And secret keys, but really, keep those safe! ->
gpg.file_export(
path=path_to_file, uid=gpg.user.email_address, secret=True
)
# The keys don't have to be exported to a file. Instead they can
# be exported as strings ->
my_key = gpg.text_export(uid=gpg.fingerprint)
# So can secret keys (Be careful!) ->
my_secret_key = gpg.text_export(gpg.fingerprint, secret=True)
# And they can just as easily be imported from strings ->
gpg.text_import(key=my_key)
Retiring KeysAfter a user no longer considers a key useful, or wants to dissociate from the key, then they have some options:
.. code:: python
from tiny_gnupg import GnuPG, run
PATH_TO_GPG_BINARY = "/usr/bin/gpg2"
gpg = GnuPG(
email_address="bob@user.net",
passphrase="bobs's passphrase",
executable=PATH_TO_GPG_BINARY,
)
# They can revoke their key then distribute it publicly (somehow)
# (the keyserver can't currently handle key revocations) ->
revoked_key = gpg.revoke(gpg.fingerprint) # <-- Distribute this!
# Uploading the revoked key will only strip the user ID information
# from the key on the keyserver. It won't explicitly let others know
# the key has been retired. However, this action cannot be undone ->
run(gpg.network_export(gpg.fingerprint))
# The key can also be deleted from the package keyring like this ->
gpg.delete(uid="bob@user.net")
.. _key revocations: https://gitlab.com/hagrid-keyserver/hagrid/issues/137
Known Issuesbug #930665, & related GnuPG bug #T4393,
importing keys from the default keyserver keys.openpgp.org_ doesn’t
work automatically on all systems. Not without email confirmation, at
least. That’s because the keyserver will not publish uid information
attached to a key before a user confirms access to the email address
assigned to the uploaded key. And, because GnuPG folks are still
holding up the merging, & back-porting, of patches that would allow
GnuPG to automatically handle keys without uids gracefully. This
effects the network_import() method specifically, but also the
text_import() & file_import() methods, if they happen to be
passed a key or filename argument which refers to a key without uid
information. The gpg2 binary in this package can be replaced manually
if a user’s system has access to a patched version.bug #T3065, & related bug #1788190, the
--keyserver & --keyserver-options http-proxy options won’t
work with onion addresses, & they cause a crash if a keyserver
lookup is attempted. This is not entirely an issue for us since we
don’t use gnupg’s networking interface. In fact, we set these
environment variables anyway to crash on purpose if gnupg tries to
make a network connection. And in case the bug ever gets fixed (it
won’t), or by accident the options do work in the future, then a tor
SOCKSv5 connection will be used instead of a raw connection... _bug #930665: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930665 .. _bug #T4393: https://dev.gnupg.org/T4393 .. _keys.openpgp.org: https://keys.openpgp.org/ .. _bug #T3065: https://dev.gnupg.org/T3065#111023 .. _bug #1788190: https://bugs.launchpad.net/ubuntu/+source/gnupg2/+bug/1788190 .. _1: https://stackoverflow.com/questions/46634215/torsocks-and-unsupported-syscalls .. _2: https://gitlab.torproject.org/legacy/trac/-/issues/28861
Changelogpassphrase keyword argument is now processed through the
hashlib.scrypt function before being stored within a User instance
& used within the GnuPG & BaseGnuPG classes. The GnuPG & BaseGnuPG
classes also accept an optional salt keyword-only argument. These
changes secure user keys & passwords by default with a memory-hard
key derivation function & the uniqueness of the user-specified random
salt. These changes provide better security & aren't backwards
compatible.email keyword argument to the User, BaseGnuPG & GnuPG
classes was changed to email_address. The attributes in the User
class have also mirrored this change. As well, the key_email method
on the GnuPG & BaseGnuPG classes is now key_email_address.User class now does type & value checking on the username,
email_address & passphrase strings passed into the __init__,
as well as whenever their associated property attributes are set.NoneType for type hinting.tiny_gnupg.py module to specify
problematic control & whitespace characters that shouldn't be used in
various user-defined inputs & credentials.file_export methods of the GnuPG & BaseGnuPG classes now
saves key files with either "public-key_" or "secret-key_" strings
prepended to them to better specify for users the context of files
saved to their filesystems.username keyword-only argument to the User & GnuPG classes
was given a default empty string. This change allows the username
to be optional & ignorable by the user. When generating a key with an
instance which doesn't have a username specified, then the associated
key will also not contain a username field.GnuPGConfig & Keyserver classes were extracted from
the GnuPG class. GnuPGConfig holds onto each instance's path
strings to the system resources (like the gpg2 binary, the .conf
file, & the home directory), as well as other static constants &
instance specific settings (like the torify boolean flag). And, the
Keyserver class separates the Tor networking & key upload,
download, & searching logic.GnuPG class was given a super class, BaseGnuPG, which is
initialized using User & GnuPGConfig objects instead of the
strings & booleans which have until now been used to initialize a
GnuPG instance. This allows users to choose between initializing
instances using the package's higher-level types or python built-in
types.gen_key method of GnuPG & BaseGnuPG was changed to
generate_key.GnuPG instance's with the same
home directory, which represent distinct & different secret keys,
can only be considered to represent separate identities during
runtime if the passphrase for each instance is distinct &
different. Past updates of the package have mentioned separate
identities as if one instance won't be able to access another's
secret keys, and this is not true unless their passphrases are
different. This is how GnuPG itself is designed, where all public &
secret keys are stored together in the home directory, & an identity
is more strongly considered to be the current operating system's user.
A more effective way a user can separate identities is by setting a
unique home directory for each identity. However, the GnuPG program
wasn't designed safely as it regards anonymity, so gaining confidence
in its ability to respect more nuanced identity boundaries is dubious
at best.value, they are now inputs, uid, output,
etc. This helps improve readability & clarity.Issue class. It takes care of raising exceptions
& giving error messages to the user for issues which aren't caused
by calling the gpg2 binary. This comes with some refactorings.Terminal, MessageBus & Error classes were created to
assist in some heavy refactorings of the codebase. Separating error
handling logic & sending commands to the terminal into their own
classes & methods.import-drop-uids option from the package's import
commands for several reasons. First, this option doesn't work on most
systems. Second, if it did work, the result would be problematic, as
that would mean all uid information would always be dropped from
imported keys. This option was intended to keep GnuPG from crashing
when importing keys which don't have uid information, but it's an
unideal hack around the root problem.homedir, options, executable, _base_command,
& _base_passphrase_command attributes are now all properties. This
keeps their values in-sync even after a user changes a GnuPG
instance's configurations. This also backtracks the last update's
solution of reseting static values after every mutation, to a
solution which reads attributes live as they're queried. The reduced
efficiency of not using cached values is not noticeable in comparison
to the many milliseconds it takes to run any gpg2 command.GnuPG class to better follow a
low-level to high-level overall semantic structure, with positional
groupings of methods which have related functionalities._base_command &
_base_password_command string attributes are reset to mirror those
changes. This keeps the instance's state coherent & updated
correctly./usr/bin/gpg2.
This isn't going to be appropriate for all users' systems. But, now
many users on linux installations won't need to pass in a path
manually to get the package to work.Network class.GnuPG class
was altered so that a user can set the path to the binary that exists
on their system manually. The path to the config file & to the home
directory can also be set independently now as well. Although, the
home directory & config file still default to the one's in the
package. These changes should allow users to more easily utilize the
package even if they aren't using Debian-like operating systems.GnuPG class was also made a bit smaller by
making some methods private.GnuPG class now only receives keyword-only arguments. The
username, email & passphrase parameters no longer use
empty default string values.network_sks_import method which was no longer working.
The onion sks server seems to change its onion address to frequently
to maintain support within the package.Network & User classes to better separate concerns
to dedicated & expressive objects.test_tiny_gnupg.py.aiohttp_socks's deprecated SocksProxy to the newer
and supported ProxyConnector.network_sks_import() for html failute sentinels.test_tiny_gnupg.py so
the keyserver's rate limiting policies don't cause the CI build to
fail as often.setup attribution kwargs in setup.py.network_sks_import() method which allows users to query the
sks infrastructure for public keys as well. We use an onion address mirror
of the sks/pks network available here: http://jirk5u4osbsr34t5.onion.manual kwarg to command which simplifies the process
of using the GnuPG() class to manage gpg2 non-programmatically.
Passing manual=True will allow users to craft commands and interact
directly with the gpg2 interface.reset_daemon() calls added to decrypt(), verify(), sign()
& encrypt(). This call kills the gpg-agent process & restarts it,
which in turn wipes the caching of secret keys available on the system
without a passphrase. This is crucial for users of applications with
multiple GnuPG objects that handle separate key identities. That's
because these methods will now throw PermissionError or LookupError
if a private key operation is needed from an instance which is already
assigned to another private key in the keyring. This gives some important
anonymity protections to users.auto_decrypt() & auto_encrypt() methods
to the README.rst tutorial." " with url
encoding "%20".packet_fingerprint(target="") & list_packets(target="") methods
now raise TypeError when target is clearly not OpenPGP data.tiny_gnupg.py.--no-tty seems to keep most of the noise from terminal output while
also displaying important banner information. For instance, signature
verification still produces detailed signature information. Because it
automatically seems to behave as desired, it's here to stay._home, _executable, & _options attributes which
store the pathlib.Path.absolute() representation of the associated
files & directories.options attribute with is the str value of the _options
pathlib path to the configuration file used by the package."--no-tty" option to command() method which conveniently
tells gpg2 not to use the terminal to output messages. This has lead to
a substantial, possibly complete, reduction in the amount of noise gpg2
prints to the screen. Some of that printed information is helpful to
see, though. We would add it back in places where it could be informative,
but passing "--no-tty" has the added benefit of allowing Docker not
to break right out of the gate of a build test. More thought on this
is required.pathlib from imports. That module has been in the standard
library since c-python3.4. This package isn't looking to be supported
for anything older than 3.6.PREADME.rst.Fixed a major bug in decrypt() which miscategorized a fingerprint scraped
from a message as the sender's, when in fact it should be the recipient's.
Getting the sender's fingerprint requires successfully decrypting the
message & scraping the signature from inside if it exists. We do this
now, raising LookupError if the signature inside has no corresponding
public key in the package keyring.
Added new auto_encrypt() method which follows after auto_decrypt()
in allowing a user to attempt to encrypt a message to a recipient's
key using the value in the uid kwarg. If there's no matching key
in the package keyring, then the keyserver is queried for a key
that matches uid where then message is encrypted if found, or
FileNotFoundError is raised if not.
Added better exception raising throughout the GnuPG class:
read_output() when the supplied uid
has no key in the package keyring, a LookupError is raised.uid is
returned back through the LookupError exception object's value
attribute for downstream error handling.verify() raises PermissionError if verification cannot be
done on the message kwarg. Raises LookupError instead if
a public key is needed in order to attempt verification. verify
can't be used on an encrypted messages in general, unless message
is specifcally a signature, not encrypted plaintext. This is just
not how verify works. Signatures are on the inside on encrypted
messages. So decrypt() should be used for those instead, it
throws if a signature is invalid on a message.CalledProcessError. Exceptions currently being
used include: LookupError, PermissionError, TypeError,
ValueError, KeyError, & FileNotFoundError.ValueError raised in text_export() & sign() switched to
TypeError as it's only raised when their secret or key
kwargs, respectively, are not of type bool.
README.rst rendering.raw_packets() now passes the uid information it's
gathered through the KeyError exception, in the value attribute
instead of copying subprocess's output attribute naming convention.README.rst.raw_packets().README.rst edits. CHANGES.rst
Known Issues moved to its own section at the top. Docstrings now
indicate code args & kwargs in restructured text, double tick
format.use-agent back into the gpg2.conf file to help gnupg to not
open the system pinentry window. This may have implications for
anonymity since multiple instances runnning on a user machine will
be able to use the same agent to decrypt message's, even if the
decrypting instance wasn't the intended recipient. This may be
removed again. A factor in this decision is that, it's not clear
whether removing it or adding no-use-agent would even have an impact_
on the gpg-agent's decisions._session, _connector, session & connector contructors
were renamed to title case, since they are class references or are
class factories. They are now named _Session, _Connector,
Session & Connector.setup.py so that the long_description
on PyPI which displays both README.rst & CHANGES.rst, will
also be displayed on github through a combined README.rst file.
The old README.rst is now renamed PREADME.rst... _have an impact: https://stackoverflow.com/questions/47273922/purpose-of-gpg-agent-in-gpg2
raw_packets() which did not return the packet
information when gnupg throws a "no private key" error. Now the
packet information is passed in the output attribute of the
KeyError exception up to packet_fingerprint() and
list_packets(). If another cause is determined for the error, then
CalledProcessError is raised instead.packet_fingerprint() now returns a 16 byte key ID when parsing
packets of encrypted messages which would throw a gnupg "no private
key" error. The longer 40 byte fingerprint is not available in the
plaintext packets.list_packets() method added to handle the error scraping of
raw_packets() & return the target's metadata information in
a more readable format.format_list_keys() which did not properly parse
raw_list_keys(secret=False) when secret was toggled to True
to display secret keys. The bug would cause the program to falsely
show that only one secret key exists in the package keyring,
irrespective of how many secret keys were actually there.decrypt() and
verify() to try at returning more accurate results to callers and
in the raised exception's value attribute used by auto_decrypt()
& auto_verify().CHANGES.md has been converted to
CHANGES.rst for easy integration into README.rst and
long_description of setup.py.README.rst tutorial expanded.set_base_command() and
gen_key() by reducing redundancy.delete() method's print noisy output when called on a key
which doesn't have a secret key in the package's keyring.secret kwarg to list_keys() method which is a boolean
toogle between viewing keys with public keys & viewing keys with
secret keys.from tiny_gnupg import run or from tiny_gnupg import *. It
was present in all of the tutorials, & since we haven’t decided to
go either all async or sync yet, it’s a nice helper.raw_packets(target="") method which takes in OpenPGP data,
like a message or key, & outputs the raw terminal output of the
--list-packets option. Displays very detailed information of all
the OpenPGP metadata on target.packet_fingerprint(target="") method which returns the
issuer fingerprint scraped off of the metadata returned from
raw_packets(target). This is a very effective way to retrieve
uid information from OpenPGP signatures, messages & keys to
determine beforehand whether the associated sender's key is or isn't
already in the package's keyring.test_tiny_gnupg.py.decrypt() & verify() methods. They
now raise KeyError when the OpenPGP data they’re verifying
require a signing key that’s not in the package’s keyring. The
fingerprint of the required key is printed out & stored in the
value attribute of the raised exception.auto_decrypt() & auto_verify() async methods
which catch the new exception hooks to automatically try a torified
keyserver lookup before raising a KeyError exception. If a key is
found, it’s downloaded & an attempt is made to verify the data.README.rst.GnuPG class, & the
class itself.require-cross-certification and
no-comment because one or both may be causing a bug where using
private keys raises an “unusable private key” error.Changed the default expiration date on generated keys from never to 3 years after created. This is both for the integrity of the keys, but also as a courtesy to the key community by not recklessly creating keys that never expire.
Added revoke(uid) method, which revokes the key with matching
uid if the secret key is owned by the user & the key passphrase
is stored in the instance’s passphrase attribute.
encrypt() & sign() message.__init__() caused by the set_base_command() not
being called before the base commands are used. This leading to the
fingerprint for a persistent user not being set automatically.README.rst tutorials.README.rst about torification.encrypt() for the recipient key in the local
keyring which throws if it doesn’t exist. This is to prevent gnupg
from using wkd to contact the network to find the key on a keyserver.torify=False kwarg to __init__() which prepends
"torify" to each gpg2 command if set to True. This will make
sure that if gnupg makes any silent connections to keyservers or the
web, that they are run through tor & don’t expose a users ip
address inadvertently.tiny_gnupg.py.setup.pyREADME.rst tutorials.sign() for the key
boolean kwarg.text_export() for the
secret boolean kwarg.key kwarg to the sign(target="", key=False) method to
allow users to toggle between signing arbitrary data & signing a
key in the package’s local keyring.message kwarg in sign(message="") to target
so it is also accurate when the method is used to sign keys instead
of arbitrary data.--batch keyword in encrypt(). When
a key being used to encrypt isn’t ultimately trusted, gnupg raises an
error, but this isn’t a desired behavior. So, --batch is removed
from the command sent from the method.base_command() method because it was only a layer of
indirection. It was merged into command().--batch, --quiet & --yes arguments to the
default commands contructed by the command() method.--quiet & --yes arguments to the command
constructed internally to the gen_key() method.delete() to
comply with gnupg limitations on how to call functions that
automatically assume yes to questions. The Up-shot is that
delete() is now fully automatic, requiring no user interaction.secret kwargs to text_export(uid, secret=bool) and
file_export(path, uid, secret=bool) to allow secret keys to be
exported from the package’s environment.post(url, **kw) & get(url, **kw) methods to allow
access to the networking tools without having to manually construct
the network_post() & network_get() context managers. This
turns network calls into one liners that can be more easily wrapped
with an asyncio run function.network_import() which wasn’t useful and
should’ve been causing problems with imports, even though the tests
didn’t seem to notice.setup() which did
not correctly tell setuptools to package the gpghome folder & gpg2
binary. This may take a few releases to troubleshoot & bug fix
fully.trust() that checked for trust levels
on keys to avoid sending an unnecessary byte of data through the
terminal. Mostly because the attempted fix did not fix the issue. And
the correct fix involves a wide branching of state & argument
checking. That runs contrary to the goal of the package for
simplicity, so it isn’t going to be addressed for now.README.rst tutorials.file_import() method where await wasn’t called on the
keyfile.read() object, leading to a crash.trust() which caused an extra b“y\n”
to be sent to the interactive prompt when setting keys as anything
but ultimately trusted. This was because there’s an extra terminal
dialog asking for a “y” confirmation that is not there when a key is
being set as ultimately trusted. This didn’t have a serious effect
other than displaying a “Invalid command (try ‘help’)” dialog.local_user kwarg from the raw_list_keys() and
trust() methods, as it doesn’t seem to matter which “user”
perspective views the list of keys or modifies trust. It is very
likely always displaying keys from the perspective of the global
agent.encrypt() which caused a “y\n” to be
prepended to plaintext that was sent to ultimately trusted keys. This
was because there’s an extra terminal dialog asking for a “y”
confirmation that is not there when a key is ultimately trusted.key_trust(uid) method to allow easy determination of
trust levels set on keys in the local keyring.gen_key() which now creates a different set of
default keys. We are no longer creating one primary key which does
certifying & signing, with one subkey which handles encryption.
Instead, we create one certifying primary key, with three subkeys,
one each for handling encryption, authentication, & signing. This
is a more theoretically secure default key setup, & represents a
common best-practice.README.rst tutorialsfile_import()\ ’s filename kwarg to path for
clarity.trust() which would allow a float to be passed to
the terminal when an integer was needed.network_export(), removing the surrounding list brackets.id_link variable in network_import() to
key_url for clarity.format_list_keys() which would imporperly split
the output string when uid information contained the "pub"
string.README.rst tutorials.trust() method which caused it to never
complete execution.trust() method which falsely made 4 the
highest trust level, instead of 5.README.rst describing bug #T4393.README.rst."local_user" kwarg to some more methods where the output
could at least be partially determined by the point of view of the
key gnupg thinks is the user’s.encrypt(sign=True) method. Now, the
method still automatically signs encrypted messages, but users can
choose to turn off this behavior.trust(uid="", level=4) method, which will allow users to
sign keys in their keyring on a trust scale from 1 to 4.set_fingerprint(uid="") which mistakenly used an
email parameter instead of the locally available uid kwarg.raw_network_export() & raw_network_verify() methods
into raw_api_export() & raw_api_verify(), respectively.
This was done for more clarity as to what those methods are doing.sign(message) & verify(message) methods.keyserver & searchserver attributes into
properties so that custom port attribute changes are now
reflected in the constructed url, & the search string used by a
custom keyserver can also be reflected.read_output() method which
simplifies the construction of command() & will automatically
shlex.quote() all commands, even those hard-coded into the
program.set_homedir() which did not construct the default
gpghome directory string correctly depending on where the current
working directory of the calling script was.local_user kwarg to encrypt() & sign() so a user
can specify which key to use for signing messages, as gnupg
automatically signs with whatever key it views as the default user
key. Instead, we assume mesasges are to be signed with the key
associated with the email address of a GnuPG class instance, or the
key defined by the local_user uid if it is passed.delete() method for removing both public & private keys
from the local keyring. This method still requires some user
interaction because a system pinentry-type dialog box opens up to
confirm deletion. Finding a way to automate this to avoid user
interaction is in the work.sign() & encrypt() methods
so that keys which haven’t been verified will still be used. This is
done by passing “y” (yes) to the terminal during the process of the
command.setup.py with more package information.git repo_setup.py.port attribute is currently unused. It may be removed if it
remains purposeless.network_get() & network_post() methods.shlex.quote() calls on args passed to the
command() method... _git repo: https://github.com/rmlibre/tiny_gnupg.git
parse_output()
is now read_output(). gpg_directory() is now
format_homedir(). The names of some existing attributes were
changed. gpg_path is now executable, with its parent folder
uri now stored in home. key_id is now fingerprint to
avoid similarities with the naming convention used for the methods
which query the package environment keys for uid information,
i.e. key_fingerprint() & key_email().Good riddance to the pynput library hack! We figured out how to gracefully send passphrases & other inputs into the gpg2 commandline interface. This has brought major changes to the package, & lots of increased functionality.
Many added utilities:
gen_key() method now get stored in a
local keyring instead of the operating system keyring.search(uid) to query for a key
with matches to the supplied uid, which could be a fingerprint or
email address. network_import(uid) to import a key with
matches to the supplied uid. network_export(uid) to upload a
key in the package’s keyring with matches to the supplied uid to
the keyserver. Also, raw access to the aiohttp.ClientSession
networking interface is available by using
async with instance.session as session:. More info is
available in the aiohttp docs_text_import(key), file_import(filename),
text_export(key), & file_export(path, uid) methods for
importing & exporting keys from key strings or files.reset_daemon() method for refreshing the system gpg-agent
daemon if errors begin to occur from manual deletion or
modification of files in the package/gpghome/ directory.encrypt(message, recipient_uid) & decrypt(message)
methods. The encrypt() method automatically signs the message,
therefore needs the key passphrase to be stored in the
passphrase attribute. The same goes for the decrypt()
method.command(*options), encode_inputs(*inputs), and
read_output(commands, inputs) methods can be used to create
custom commands to the package’s gpg2 environment. This allows for
flexibility without hardcoding flexibility into every method,
which would increase code size & complexity. The command()
method takes a series of options that would normally be passed to
the terminal gpg2 program (such as –encrypt) & returns a list
with those options included, as well as, the other boiler-plate
options (like the correct path to the package executable, & the
package’s local gpg2 environment.). encode_inputs() takes a
series of inputs that will be needed by the program called with
the command() instructions, & bytes() encodes them with
the necessary linebreaks to signal separate inputs.
read_output() takes the instructions from command() and
inputs from encode_inputs() & calls
subprocess.check_output(commands, input=inputs).decode() on
them to retrieve the resulting terminal output... _aiohttp docs: https://docs.aiohttp.org/en/stable/client_advanced.html#client-session
FAQs
tiny_gnupg - A small-as-possible solution for handling GnuPG ed25519 ECC keys.
We found that tiny-gnupg demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
In this segment of the Risky Business podcast, Feross Aboukhadijeh and Patrick Gray discuss the challenges of tracking malware discovered in open source softare.
Research
Security News
A threat actor's playbook for exploiting the npm ecosystem was exposed on the dark web, detailing how to build a blockchain-powered botnet.
Security News
NVD’s backlog surpasses 20,000 CVEs as analysis slows and NIST announces new system updates to address ongoing delays.