[](https://crates.io/crates/sheesy-cli)
[](https://github.com/share-secrets-safely/cli/actions?query=workflow%3Aci)
**sh**are-s**e**cr**e**ts-**s**afel**y** (_sheesy_) is a solution for managing
shared secrets in teams and build pipelines.
Like [`pass`][pass], `sy` allows to setup a vault to store secrets, and share
them with your team members and tooling.
However, it wants to be a one-stop-shop in a single binary without any dependencies except
for a `gpg` installation,
helping users to work with the `gpg` toolchain and workaround peculiarities.
[](https://asciinema.org/a/164964?t=14)
[pass]: https://www.passwordstore.org/
## Installation
Please read the [installation notes here][installation].
[installation]: https://share-secrets-safely.github.io/cli/installation.html
## Getting Started
The first steps showing on how to use the vault with a complete example and detailed
explanations can be found [in the book][first-steps].
[first-steps]: https://share-secrets-safely.github.io/cli/vault/first-steps.html
## 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*, without dynamically linked dependencies
* **proven cryptography**
* Don't reinvent the wheel, use *gpg* for crypto. It's OK to require `gpg` to be installed
on the host
* 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 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
* **support old wheels - pass compatibility**
* something `pass` does really well is to setup a vault with minimal infrastructure and configuration.
We use said infrastructure and don't reinvent the wheel.
* This makes us **compatible with pass**, allowing you use `pass` on a `sheesy` vault with default configuration.
## 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.
## Why would I use `sheesy` over...
You will find various and probably biased and opinionated comparisons [in our book][compare].
However, it's a fun read, and please feel free to make PRs for corrections.
[compare]: https://share-secrets-safely.github.io/cli/compare.html
## 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.
* GPG2 is required to use the 'sign-key' operation. The latter is required when
trying to add new unverified recipients via `vault recipients add <fingerprint>`.
## Roadmap to Future
As you can see from the version numbers, this project dispenses major version generously.
This is mainly because, for the sake of simplicity, there is only a single version number
for the *CLI* as well as all used libraries.
Effectively, you can expect the *CLI* will change rarely, and if it does only to improve
the user experience. The more tests we write, the more certain shortcomings become
evident.
The *vault library* and its types will change much more often, but we would expect it
to settle from 5.0.
### Roadmap to 4.1
This should make the first release which can be publicised, as it should include all the
material people might need to get started using _sheesy_ comfortably.
* [ ] Documentation for
* [ ] vault init
* [ ] ...
### Roadmap to 5.0
The GPGME dependency is also the major flaw for usability, as it eventually goes down to
the quirks of GPG itself.
[SEQUOIA](https://gitlab.com/sequoia-pgp/sequoia) is a pure-Rust implementation of the
PGP protocol, which would greatly help making *sheesy* even more usable.
* [ ] Use SEQUOIA instead of GPGME
* [ ] Provide a windows binary
### Roadmap to 6.0
#### Add the `pass` subcommand
`sy` aims to be as usable as possible, and breaks compatibility were needed to
achieve that. However, to allow people to leverage its improved portability
thanks to it being self-contained, it should be possible to let it act as a
stand-in for pass.
Even though its output won't be matched, its input will be matched perfectly, as
well as its behaviour.
* [ ] init
And last but not least, there should be some sort of documentation, highlighting similarities
and differences.
* [ ] documentation
#### Some usability improvements
* [ ] Assure that the error messages provided when we can't find a partition are
better and specific to the use case.
* [ ] Tree mode for lists of
* [ ] recipients
* [ ] resources
## Development Practices
* **test-first development**
* protect against regression and make implementing features easy
* user docker to test more elaborate user interactions
* keep it practical, knowing that the Rust compiler already has your back
for the mundane things, like unhappy code paths.
* **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.
## Maintenance Guide
### Making a release
As a prerequisite, you should be sure the build is green.
* run `clippy` and fix all warnings with `cargo clippy --all-features --bin=sy`
* change the version in the `VERSION` file
* update the release notes in the `release.md` file.
* Just prefix it with a description of new features and fixes
* run `make tag-release`
* requires push permissions to this repository
* requires maintainer or owner privileges on crates.io for all deployed crates
### Making a deployment
As a prerequisite you must have made a release and your worktree must be clean,
with the HEAD at a commit.
For safety, tests will run once more as CI doesn't prevent you from publishing
red builds just yet.
* run `make deployment`.
* copy all text from the `release.md` file and copy it into the release text on github.
* drag & drop all _tar.gz_ into the release and publish it.
* in `doc/src/installation.md`, update the URL to use the latest published version
* run `make update-homebrew` - it will push for you
* run `make update-getting-started` - it will push for you
### Making a new Asciinema recording
Even though the documentation is currently updated with every push to master (to allows
fixing the existing docs easily), the *eye-candy* on the front page needs to be regenerated
too.
As a prerequisite, you will need an installed binary of [`asciinema`][asciinema].
Please make sure your player is already linked to your account via `asciinema auth`.
* Set your terminal to a size of 120x20
* You see these units when resizing an iterm2/3 terminal window
* run `make asciinema-no-upload` and verify it contains what you expect with
`asciicast play getting-started.cast`
* Possibly upload the recording with `make asciinema-upload`
* Enter the given URL and configure the asciicast to your liking, add backlinks
to the description, and make it nice.
[asciinema]: https://asciinema.org