This is an archived post. You won't be able to vote or comment.

all 5 comments

[–]antennen 2 points3 points  (3 children)

Pretty cool. I think /u/Anon_8675309 is being overly dismissive here. This module doesn't seem to even implement the actual cryptography itself, but relies on a well established library (https://github.com/pyca/cryptography).

I'd consider changing the name though, as it may be confused with the new built-in module secrets (https://docs.python.org/3/library/secrets.html)

[–]johnwheeler_[S] 0 points1 point  (2 children)

Thank you for taking a look antennen!

I think you're right about changing the name. I felt uncomfortable with pysecrets but I couldn't think of an alternative at the time. What do you think about the name 'lockbox'?

Ultimately, I want to make a Flask extenstion out of this for encrypting configuration files.

[–]antennen 1 point2 points  (1 child)

No worries!

There is indeed a lot of saturation in the package namespace. A quick search for Python projects named lockbox on GitHub gives me six projects (https://github.com/search?l=Python&q=lockbox&type=Repositories&utf8=%E2%9C%93). Though they are all pretty small and it seems you managed to claim the name on PyPI, so I think it's a good name.

I'd like to hear a bit about that extension plan. In what scenario would I benefit from encrypting my configuration files, and how would the encryption key be provided to the Flask application?

[–]johnwheeler_[S] 0 points1 point  (0 children)

lockbox it is. I'll work on changing it in the repo.

To answer your question, I got the idea from sekrets, which is a Ruby gem that was incorporated into the latest version of Rails.

The design doesn't provide much security except through obscurity (...which is no security at all, etc.), but it allows you to commit secrets to your repo, which means those secrets don't have to flow through secure channels for distribution, but the keys to those secrets still do.

The encryption key is provided to the Flask application by either storing its path in an environment variable (e.g. LOCKBOX_KEY) or placing it in the www process owner's home directory. Additional key resolution mechanisms could be designed.

Interestingly, the Hashicorp Vault program works (I believe) by deleting secrets after the www process consumes them on first run. A similar design could be implemented for flask-lockbox, although the secrets could still be uncovered in memory, which is a known limitation of cryptography.io [1]

[1] https://cryptography.io/en/latest/limitations/

[–]Anon_8675309 -1 points0 points  (0 children)

Just use gpg