share-secrets-safely is a GPG based solution for managing shared secrets.

On our way to the minimal viable product v1.0

• [x] setup rust workspace for clear dependency separation
• [x] setup CI for linux and OSX
• [x] standalone deployables without additional dependencies for
  • [x] OSX (static binary) - just gettext is still dynamically linked :(
  • [x] MUSL Linux
• [x] shell completions
• [x] complete a happy journey with
  • [x] initialize a new vault
  • [x] add contents
  • [x] support for multiple vaults
  • [x] list vault contents
  • [x] decrypt vault contents
  • [x] edit vault contents
  • [x] add another user and re-encrypt vault content
• [ ] installable from crates.io
• [ ] release binaries generated by travis for tags
• ...and many more when the boxes above are ticked :D

Project Goals

• a great user experience
  • The user experience comes first when designing the tool, making it easy for newcomers while providing experts with all the knobs to tune
  • deploy as single binary, no additional executables or dependencies are required to use all of the features
• proven cryptography
  • Don't reinvent the wheel, use gpg for crypto
  • Thanks to GPG each user is identified separately through their public key
• automation and scripting is easy
  • storing structured secrets is as easy as making them available in shell scripts
  • common operations like substituting secrets into a file are are natively supported
  • proper program exit codes make error handling easy
• user management
  • support small and large teams, as well as multiple teams, with ease
  • make use of gpg's web of trust to allow inheriting trust even across team boundaries, and incentivize thorough checking of keys
• basic access control
  • partition your secrets and define who can access them

Non-Goals

• replicate pass or gpg functionality directly
  • having seen what pass actually is and how difficult it can be to use it especially in conjunction with gpg, this project will not even look at the provided functionality but be driven by its project goals instead.
• become something like hashicorp vault
  • this solution is strictly file based and offline, so it can fill be used without any additional setup.

Caveats

• Many crypto-operations store decrypted data in a temporary file. These touch disk and currently might be picked up by attackers. A fix could be 'tempfile', which allows using a secure temporary file - however, it might make getting MUSL builds impossible. Static builds should still be alright.

Development Practices

• test-first development
  • protect against regression and make implementing features easy
  • user docker to test more elaborate user interactions
• safety first
  • handle all errors, never unwrap
  • provide an error chain and make it easy to understand what went wrong.
• strive for an MVP and version 1.0 fast...
  • ...even if that includes only the most common usecases.
• Prefer to increment major version rapidly...
  • ...instead of keeping major version zero for longer than needed.