share-secrets-safely/cli

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

cli's Issues

Fix new line when checking version

Hi,

I have been using this in my project. It is very useful for storing our passwords. Thanks.

However when I check the version it comes with a newline.

shakir$./sy --version
sy 4.0.0

shakir$

Can you please fix this ?

'sy process' tries to read from stdin and blocks forever

If no TTY is attached, it will always try to read from stdin. However, this seems to block forever in certain situations, without indicating EOF or something similar.

Maybe there is a way to detect that, or to workaround it without forcefully providing something like echo '{}' | sy process ....

Failed compiling sheesy-cli v1.0.1

Hi,
just installed rustup and cargo to install sheesy-cli.
After executing cargo install sheesy-cli, I get a bunch of lines like Compiling ... which looks good.

Until:

Compiling libgpg-error-sys v0.3.1
Compiling gpgme-sys v0.7.0
Compiling gpgme v0.7.1
error: failed to run custom build command for `gpgme-sys v0.7.0`
process didn't exit successfully: `/var/folders/rg/jmhmvgl57rj4n1xmgyb2lt7m0000gn/T/cargo-install.MCN5Z2Gid1rP/release/build/gpgme-sys-69e4934ff7b01c8d/build-script-build` (exit code: 1)
--- stdout
cargo:rerun-if-env-changed=GPGME_LIB_DIR
cargo:rerun-if-env-changed=GPGME_LIBS
cargo:rerun-if-env-changed=GPGME_CONFIG

--- stderr
running: "git" "apply" "../gpgme-remove-doc.patch"
error: patch failed: Makefile.am:33
error: Makefile.am: patch does not apply
error: patch failed: configure.ac:883
error: configure.ac: patch does not apply
command did not execute successfully, got: exit code: 1
running: "sh" "-c" "gpgme-config --version"
sh: gpgme-config: command not found
command did not execute successfully, got: exit code: 127

warning: build failed, waiting for other jobs to finish...

I'm running OSX El Capitan Version 10.11.6 (15G1510) if that helps somehow.

Do you have any idea if I can fix it myself?
Thanks in advance.

Add use-case/cookbook style documentation

While the sheesy documentation is pretty fantastic already, I felt there was a little to be desired as far as the various vault pages, in particular vault partitions.

I was looking for basically group-like support -- being able to share a secret with a group of users but not necessarily a different group, more concretely to be able to differentiate secrets for staging/production. When looking at the vault partitions add documentation it was unfortunately a little unclear

Since what I was looking for is likely a very common usecase, it might be nice to explain it directly, either on the add page itself or in a separate "recipes" or "use case examples" or something section.

Migrate single partition vault into multi partition one

Hi there,
I am a very happy user of sy, and in my company we have setup a vault a long time ago. Now I would love to add partitions to it, but unfortunately I created it as a single-partition at the beginning, so if I try to add a partition named devs I get the following error:

error: Partition at './devs' is contained in another partitions resources directory at './.'

Is there a way, even manually, to migrate a single partition vault into a multi partition one?

I am using sy version 4.0.10.

`sy vault recipient add ...` fails with 'could not sign key of recipient'

After running the command from the subject on linux (ubuntu) we saw this message.

Imported recipient key at path '.gpg-keys/60D52894609DDDFC794BCAC62DDE29BE8568696B'
error: The GNU Privacy Guard (GPG) does not supported the attempted operation.
GPG v2 is known to work, and you can install it here:
https://www.gnupg.org for more information.
Caused by:
2: Could not sign key of recipient 60D52894609DDDFC794BCAC62DDE29BE8568696B with signing key <user redacted>
1: Not supported (gpg error 60)

Add practical use-case example

I like the GPG key based ACL of this tool and can see how it prevents leaks.

But I fail to imagine the real-world usage in a team of developers and I cannot find one in the documentation.

Is is something like:

1. Alice, Bob and Charlie are working on a software source code versioned by git repository (and shared amongst them via GitHub, GitLab or any other central git repository).
2. Alice want to store MySQL password into software's git repository but doesn't want neither Bob nor Charlie to have access to this secret.
   1. Alice creates a secrets directory into software's source code directory on it's computer, cd into it and run sy vault init to initialize the sheesy vault "secrets".
   2. Alice runs git add . ; git commit -m "Created a secrets sheesy vault" to commit the vault creation.
   3. Alice adds the MySQL password to the vault with: echo s3cre7 | sy vault add :mysql-password.
   4. Alice runs git add . ; git commit -m "Added MySQL password to the secrets vault"; git push origin for the changes the sy vault add command did on the sheesy vault ("secrets") are saved to the git repository.
3. After some time, Alice trusts Bob to read secrets, so Alice asks Bob to run (on it's computer): cd secrets ; sy vault recipient init to add it's GPG key to possible recipients and git add . ; git commit -m "Adding Bob's key to the secrets vault" ; git push origin to persist the changes to the git repository.
4. Alice can now run cd secrets ; sy vault recipient add 7DF95D5E and git add . ; git commit -m "Granting Bob's key access to secrets sheesy vault" ; git push origin and tells Bob that she granted him access to the "secrets" vault.
5. Bob can now cd secrets and finally read the MySQL with sy vault show mysql-password.
6. Charlie see the commits, see the list of secrets (using sy vault) but can never read them.

Notes:

• I am intentionally omitting the parts where Alice, Bob and Charlie runs their git fetch and git merge commands.
• On point 2., if Alice wants to store the password into software's git repository, could it be because software's deployment script will need it (in which case a other recipient should be added)?

Comparison to git-crypt

It would be nice if the documentation would how sheesy differentiates itself from a git-crypt.

So far as I can see currently:

• No integration with git
• No support for simple AES key encryption

Maybe it doesn't make sense to compare sheesy to a tool like git-crypt in the first place, since the scopes are somewhat different, if so I apologize! I think that sheezy could be super useful for storing secrets right in git repos so that's one way I really want to use it.

P.S. I just saw the talk @ RustCologne -- cool project!

Add support for symmetric cryptography with Sequoia

As of now, we depend on GPG for asymmetric cryptography. However, depending on GPGME seems to be an issue if Windows support is desired.

An alternative seems to be Sequoia, which has Windows support on their roadmap for 2019. To get started, it should already be possible to add symmetric (i.e. password based) cryptography to sheesy, serving as quick-start alternative to the key-based cryptography and thus somewhat competing with keypass and its command-line tools.

Requirements

• assure symmetric crypto is compatible with GPG, and ideally the GPG tools can be used for decryption, too, if the password is known.

Open Questions

• should it be possible to transition between stores of different kinds, e.g. asymmetric to symmetric and vice-versa?
• Will it be clear how files are encrypted, to not mistake asymmetrically encrypted files with symmetric ones and fail decryption for that reason.

Alternatives

• https://github.com/miscreant/miscreant-rs
  • asymmetric pure-rust crypto. Would work as well, but may be less vetted than nettle.

Related to #12 .

Consider bringing https://github.com/share-secrets-safely/cli/community to 100%

Just to make the project even more appealing.

The OSX installation instructions don't work

They need the 'cli' repository named as last argument.
Thanks a lot

Provide the native homebrew repository - see image

Looks like adding a repo called 'homebrew-cli' would do the job naturally. Would also mean we have to store the homebrew file out of tree, but that should be alright.

Feature Request: Please publish to home brew for OSX for easier adoption

Windows support?

Since both rust and gpg run on Windows, what obstacles are there to sy running on Windows, too?

When installed on OSX with Homebrew on Apple Silicon, the sy command fails to load libassuan.0.dylib

Steps to reproduce:

Install Sheesy with on OSX with a recent version of Homebrew:

brew tap share-secrets-safely/cli
brew install sheesy

Then run any command, for example sy --version.

Expected behaviour

The command runs without issues.

Actual behavior

The command fails with:

dyld[2780]: Library not loaded: /usr/local/opt/libassuan/lib/libassuan.0.dylib
  Referenced from: <E27503E4-8399-3EE0-8726-E6E09272A3EC> /opt/homebrew/Cellar/sheesy/4.0.10/bin/sy
  Reason: tried: '/usr/local/opt/libassuan/lib/libassuan.0.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/usr/local/opt/libassuan/lib/libassuan.0.dylib' (no such file), '/usr/local/opt/libassuan/lib/libassuan.0.dylib' (no such file), '/usr/local/lib/libassuan.0.dylib' (no such file), '/usr/lib/libassuan.0.dylib' (no such file, not in dyld cache)
zsh: abort      sy vault list

Note that libassuan is correctly installed on the system (with Homebrew).

The version you were using

The command sy --version crashes, but the installed sy version is 4.0.10.

I am on MacOS Ventura 13.1 on Apple Silicon M1 Max.

The Homebrew version is:

$ brew --version
Homebrew 3.6.20
Homebrew/homebrew-core (git revision 9b06fea8797; last commit 2023-01-17)

Possible explanation

Homebrew on Apple Silicon uses /opt/homebrew as prefix instead of /usr/local (as indicated by the output of brew --prefix and as discussed here), therefore libassuan is located in /opt/homebrew/lib/libassuan.0.dylib. Currently, sy tries to load it from /usr/local and /usr/lib.

Explicitly setting DYLD_LIBRARY_PATH=/opt/homebrew/lib sy --version finds the library, but fails with:

dyld[9043]: Library not loaded: /usr/local/opt/libassuan/lib/libassuan.0.dylib
  Referenced from: <E27503E4-8399-3EE0-8726-E6E09272A3EC> /opt/homebrew/Cellar/sheesy/4.0.10/bin/sy
  Reason: tried: '/opt/homebrew/lib/libassuan.0.dylib' (mach-o file, but is an incompatible architecture (have 'arm64', need 'x86_64')), '/usr/local/opt/libassuan/lib/libassuan.0.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/usr/local/opt/libassuan/lib/libassuan.0.dylib' (no such file), '/usr/local/opt/libassuan/lib/libassuan.0.dylib' (no such file), '/usr/local/lib/libassuan.0.dylib' (no such file), '/usr/lib/libassuan.0.dylib' (no such file, not in dyld cache)

This seems to indicate that the wrong architecture is used when downloading the pre-built sy binary, I suspect because -x86_64 is hardcoded here, and the releases do not include an arm64 version.

Cloning the repo and building it with Cargo produces a working sy binary, so it looks like it is really just an issue with missing pre-built binary for Apple Silicon.

vault edit must respect 'always trust' settings

check it - in pass there is no such thing.

`vault edit` allows creating files outside of the `secrets` directory`