Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/share-secrets-safely/cli

share secrets within teams to avoid plain-text secrets from day one
https://github.com/share-secrets-safely/cli

cli gnupg gpg pgp shared-secrets team vault

Last synced: 5 days ago
JSON representation

share secrets within teams to avoid plain-text secrets from day one

Awesome Lists containing this project

README 

        
[![https://crates.io](https://img.shields.io/crates/v/sheesy-cli.svg)](https://crates.io/crates/sheesy-cli)

[![ci](https://github.com/share-secrets-safely/cli/workflows/ci/badge.svg)](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.



[![asciicast](https://asciinema.org/a/164964.png)](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 `.



## 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