Encrypted configuration backend

[rubiojr]

AES configuration backend encrypts Beehive's configuration using symmetric encryption.

Example:

./beehive --config crypto://x:mysecret@/home/rubiojr/beehive.conf`

BEEHIVE_CONFIG_PASSWORD=mysecret ./beehive --config /path/to/encrypted/config

This will use the key mysecret to encrypt/decrypt the config file.

The encrypted configuration file includes a 12 bytes header (beehiveconf+) that makes it possible to identify the file as an encrypted configuration file:

head -c 12 beehive-encrypted.conf
beehiveconf+

Fixes #226

[rubiojr]

@muesli crypto is not really my strength. Any opinions before I start adding tests here?

[rubiojr]

The plan is to also load the password from the environment, to provide a safer alternative to the embedded string in the URL.

[rubiojr]

This is ready for 👀

[rubiojr]

Ended up adding an example wrapper to store and retrieve the configuration password from a desktop keyring.

[muesli]

Looks good to me, nice work, once again!

The only remark I have so far: maybe we could drop the fake username (x in the example crypto URL) and instead allow for it to be set as the password, so the URL could look like:

crypto://mysecret@/home/rubiojr/beehive.conf

I know it's technically abusing the username as our password, but it gets rid of the redundant & confusing fake value in the URL, and looks a bit nicer (imo).

What do you think?

[rubiojr]

What do you think?

I like the idea.

[rubiojr]

I'm also adding a cli tool to decrypt/encrypt an existing config. I found that useful.

[rubiojr]

The only remark I have so far: maybe we could drop the fake username (x in the example crypto URL) and instead allow for it to be set as the password, so the URL could look like:

Fixed in 8626f31

I'm also adding a cli tool to decrypt/encrypt an existing config. I found that useful.

On a second thought, I'll leave that for a new PR, to reduce the scope here.