Begin Transmission
THIS PROJECT HAS GONE EOL!!!
I no longer maintain this as an active library. It was an interesting experiment
but the keybase CLI surpassed it and is a whole lot nicer to integrate with than
using this API interface wrapper. I recommend that approach. You can read about
the deprecation [here](https://mostlywrong.net/on-the-future-of-the-keybase-python-api/).
On July 15, 2019 I deleted this package from the PyPi repository because it had
become incompatible with Python >= 3.3.
This repository is now archived on GitHub.
End Transmission
A Python implementation of the keybase.io API
From their website:
Keybase is two things.
- a public, publicly-auditable directory of keys and identity proofs
- a protocol (this API) for accessing the directory
Keybase has an existing command line written in Node.js as well as a well documented HTTP API. This Python API is mostly an experiment for my own edification and hopefully it becomes something useful for everyone. I was smitten with Keybase's nice HTML API and thought, "Why not?".
The official documentation for the project can be found here: http://keybase-python-api.readthedocs.org/en/latest/
[sudo] pip install keybase-api
from keybase import keybase
See the official documentation for more examples of how to use the API.
kbase = keybase.Keybase('irc')
primary_key = kbase.get_public_key()
primary_key.kid
u'0101f56ecf27564e5bec1c50250d09efe963cad3138d4dc7f4646c77f6008c1e23cf0a'
You can use the ascii or bundle properties on the primary_key object in the above example to get an ASCII version of their primary public key, suitable for feeding in to a signature verification or encryption routine.
The keybase.discover method returns tuples of keybase.Keybase objects. It lets you find Keybase users by other indentifiers such as their Twitter handle, Github username, website domain, etc. For a completely list of available search criteria please see the official documentation.
kusers = keybase.discover(keybase.TWITTER, ['ircri']
assert len(kusers) > 0
primary_key = kusers[0].get_public_key()
primary_key.kid
u'0101f56ecf27564e5bec1c50250d09efe963cad3138d4dc7f4646c77f6008c1e23cf0a'
Where the file was signed with a gpg command like so:
gpg -u keybase.io/irc --sign helloworld.txt
So there is one, binary, file helloworld.txt.gpg that contains both the data and the signature on the data to verify.
kbase = keybase.Keybase('irc')
verified = kbase.verify_file('helloworld.txt.gpg')
assert verified
Where the file was signed with a gpg command like so:
gpg -u keybase.io/irc --detach-sign helloworld.txt
So there are two files:
- The original data file; and
- The detached
.sigfile that contains the signature for the data.
In this case:
kbase = keybase.Keybase('irc')
fname = 'helloworld.txt'
sigfname = 'helloworld.txt.sig'
verified = kbase.verify_file(fname, sigfname)
assert verified
Given some str formatted data, you can create an ASCII armored, encrypted str representation of that data suitable for sending to the user. Only someone with the private key will be able to decrypt this data.
kbase = keybase.Keybase('irc')
instring = 'Hello, world!'
encrypted = kbase.encrypt(instring)
assert encrypted
assert not encrypted.isspace()
assert encrypted != instring
I highly recommend you develop using VirtualEnv. It keeps dependency stuff somewhat sane. The .gitignore file is set expecting you to keep your virtual environment in .venv like so:
[sudo] pip install virtualenv
cd ~/code
git clone [email protected]:ianchesal/keybase-python.git
cd keybase-python
virtualenv .venv
source .venv/bin/activate
...
<do your development work now>
...
deactivate
Most of the testing was done against GnuPG:
> gpg2 --version
gpg (GnuPG) 2.0.26
libgcrypt 1.6.2
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, RSA, RSA, ELG, DSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2
I'm using Travis CI to build and test on every push to the public github repository. You can find the Travis CI page for this project here: https://travis-ci.org/ianchesal/keybase-python/
The project is currently setup in Travis to test Python 2.6, 2.7 and 3.3. But only 2.7 is being targetted at this point and time and 2.6, 3.3 are listed as allowed-to-fail in the .travis.yml file for the project.
I'm using git-flow for development in git via github. I've loved the branching model git-flow proposed from day one and the addon to git makes it very intuitive and easy to follow. I generally don't push my feature/* branches to the public repository; I do keep development and master up to date here though.
Please see TODO.md for the short list of big things I thought worth writing down.
Questions or comments about keybase? Hit me up at [email protected].