It’s fun to build things like this but if you want to nourish a user base you need to fully understand the landscape of similar tools and then explain your differentiating value. This is /particularly/ important for security related tools.
Specifically you should compare and contrast to tools like SOPS, Ansible Vault, pass, etc.
Or you could just build things for fun. Why do we have to care about "nourishing a user base"? Two decades ago we would build software and release it for fun and utility.
> Specifically you should compare and contrast to tools like SOPS, Ansible Vault, pass, etc.
This Github star hunting—, CV padding—, make-it-big-and-BDFL-yourself—approach to open source that has crept in over the last decade is bewildering and rather unpleasant.
Skimmed the readme, seems like it's not AEAD? I don't see any reason to use a tool that's not AEAD.
Also, while I get the appeal of just storing it all in a giant JSON, I don't really feel that's the final word in simple storage formats. I'd personally just use SQLite, or some other format I could rsync.
Text formats have the advantage of better support in version control systems. SOPS does similar thing, it stores encrypted values in yaml/json, and from my experience using this approach with git it is indeed an improvement over, say, Ansible vault, which essentially turns text files into blobs
I use pass[0] which uses a flat directory structure and git. It works great! At $dayjob we have json lockfiles committed to git and merges get pretty gnarly. Not as big of a fan of just dropping it all in json. The toml lockfiles are a bit better in git.
It’s fun to build things like this but if you want to nourish a user base you need to fully understand the landscape of similar tools and then explain your differentiating value. This is /particularly/ important for security related tools.
Specifically you should compare and contrast to tools like SOPS, Ansible Vault, pass, etc.
Or you could just build things for fun. Why do we have to care about "nourishing a user base"? Two decades ago we would build software and release it for fun and utility.
> Specifically you should compare and contrast to tools like SOPS, Ansible Vault, pass, etc.
What a boring proposition for hobby projects.
You are taking the words right out of my mouth.
This Github star hunting—, CV padding—, make-it-big-and-BDFL-yourself—approach to open source that has crept in over the last decade is bewildering and rather unpleasant.
Skimmed the readme, seems like it's not AEAD? I don't see any reason to use a tool that's not AEAD.
Also, while I get the appeal of just storing it all in a giant JSON, I don't really feel that's the final word in simple storage formats. I'd personally just use SQLite, or some other format I could rsync.
> Skimmed the readme, seems like it's not AEAD?
Are you just looking for keywords? That's not how a quality security review should be done.
> I don't see any reason to use a tool that's not AEAD.
Do you have an actual attack? Non AEAD schemes have been used for decades without any attack.
There might be entirely valid complaints against this. Lack of AEAD is not one...
> I don't really feel that's the final word in simple storage formats.
Literally nobody said it was
> I'd personally just use SQLite, or some other format I could rsync.
You can rsync a JSON file just as you can rsync a SQLite file....
> You can rsync a JSON file just as you can rsync a SQLite file....
`sqlite-rsync` does a deep comparison and only transmits new rows, without deleting other data. `rsync` on a json file just replaces the file.
Text formats have the advantage of better support in version control systems. SOPS does similar thing, it stores encrypted values in yaml/json, and from my experience using this approach with git it is indeed an improvement over, say, Ansible vault, which essentially turns text files into blobs
I use pass[0] which uses a flat directory structure and git. It works great! At $dayjob we have json lockfiles committed to git and merges get pretty gnarly. Not as big of a fan of just dropping it all in json. The toml lockfiles are a bit better in git.
[0] https://www.passwordstore.org/
It is using https://cryptography.io/en/latest/hazmat/primitives/symmetri... so no aead. And also using this library as it strongly encourages to use something else. Because of footguns like this.
Will be extending this with one more feature which I didnt think about .. the possibility to rotate passwords.
Might also extend it with an API. Not sure. cheers!
would be great to have a rotate password feature. good job
Cool project. Is there a concept of namespaces or tags? Looking to store a group of secrets and then fetch them all with a single call.
thank you. I will be adding namespaces in the next release. Currently testing password rotation and backup to s3
maybe push it to pypi as well ?