* fixes header nav for installation and plugins
* also updates README for accurate installation URL
---------
Co-authored-by: Chris Lutz <chris@sysadminchris.info>
* check for encrypted version of file before decrypting, for #706
* improve error messages, verbose output and non-verbose output
* in tests, prefix output from git init with 'git: '
* 'clean' options only remove added files, for #833
* update changelog
* change file desc we use to pass gnupg info
* improve content and phrasing in docs
* improve docs about locations of private/public keys
* update changelog
* set git-secret keys dir to 700 perms, for #811
* update changelog
* test improvements
* clean up comments
* remove unused code
* update git-secret-init man page
* document change to git-secret-init
* test .gitignore has expected line count, for #792
* let 'add' append filenames to .gitignore in tests
* add comments related to #789
* fix test to allow for more output from 'add'
* improve error message output
* allow for extra output from 'add' in test
* tweaks as per shellcheck lint
* improve comments, cleanup code
* update changelog
* describe test better
* mention bats-core upgrade, fix grammar
* Update CHANGELOG.md
* move info about issue with ubuntu & brew to #760
* rephrase text
* more about interoperability and gnupg versions
* Rename the "killperson" command to "removeperson"
"killperson" is unnecessarily hostile so change the command name to
"removeperson".
Fixes#684.
* Re-generate man pages
* Update contribution guide
There's no longer any pre-commit hooks so don't mention them.
* Add alias from `killperson` pointing at `removeperson`
* Update git_secret_removeperson.sh
Co-authored-by: Nikita Sobolev <mail@sobolevn.me>
* Closes#653
Add security disclaimer for git-secret-killperson specifying what is and is not readable by a user after having been removed from the repository's keyring
* Document addition of disclaimer in changelog
* support asserting named keyring is missing email(s)
* improve error if git-secret keyring missing email
* new test for telling same email twice
* update tell manpage regarding duplicate emails
* regenerate man pages
* update changelog
* Migrate docs to master branch, add action to deploy to pages branch on push
* Update docs, build pipeline to reflect new method of updating gh-pages
* Removed make build-gh-pages from post-commit hook
Co-authored-by: Josh Rabinowitz <joshr@joshr.com>
* More precise feedback about added files
This adapts the output of the add command in order to report exactly
how many files have been added. Specially with wildcard patterns, this
makes it easier to verify that expected files are added.
With the verbose option, the add command will also tell which files
have been added.
By @bbroeksema bbroeksema
* updated fixture key for user3, fixes#607
* update tests/fixtures/gpg/README.md
* mention fix of #607 and #609 in changelog
* use shellcheck 0.7.1, not 'latest' for #609
* update developer docs regarding builds, setup, and docker
* more details about git hooks, PRs, and branch names
* add links, corrections, clarifications, and typo fixes
* link to semver.org
* reorder packages and mention homebrew package
* add key fixture with no email, and 2 word comment
* tests for key without email and with comment
* handle comments in public key uids
* fix tests, you have to use email address
* fix text
* confirm that email addresses contain an @ symbol
* improve comments about keys/fixtures
* use busybox by not installing coreutils on alpine
* changes for busybox version of ps and stat
* add function to check if exe is from busybox
* update changelog
* cleanup comments, code, and commented out code
* improve comment in alpine Dockerfile
* include platform-specific funcs so we can test perms
* use python3 and pip3
* upgrade to ansible 2.8.4
* set ansible_python_interpreter
* fix: enable debian sources when haven't found them
* updates to changelog
* Tempfile and temp directory cleanups
Add comments about mktemp on different platforms
Be more careful about tempfile cleanups
Don't use find to locate files to cleanup
Use shorter SECRETS_EXTENSION and SECRETS_DIR env settings in tests
Set TMPDIR in tests again
Show DESTDIR used when testing git-secret install
Change filename passed to mktemp -t in tests
* Only show 'cleaning up temp file' messages if one
of SECRETS_VERBOSE or SECRETS_TEST_VERBOSE is set.
* Adjust tests to reflect the change.
* Add note about suppressing 'cleaning up' msgs to CHANGELOG.md and reorder entries
* add comments showing examples of tmpfiles returned
* add a travis target using SECRETS_TEST_VERBOSE=1
* Document SECRETS_TEST_VERBOSE as experimental
* note experimental feature may change or be removed
* improve how we check for ignored files using 'git check-ignore'
* mention use of git check-ignore in changelog
* don't mkdir/rmdir when testing for ignored files
* Change 'add' to add to .gitignore by default.
Also add _message() function and improve output from 'git-secret-add',
alter tests for new code behavior, and update docs.
* change tests since 'add' always adds to .gitignore
* improve output: prepend more message with 'git-secret:'.
* update man page for git-secret-add
* perform lint/shellcheck tests on travis mac builds
* move osx builds first in travis
* install shellcheck on macos
* show if the lint test passed or failed
* don't have travis install ruby 2.6 on osx for now
* add test for travis-ci windows support
* Make 'ps' command options platform specific *nix/windows
* Add _clean_path for windows, apply to all homedir input arguments
* export GITSECRET_DIST="windows" in git hook if running windows
* Bash lint fixes
* use pgrep & kill, not ps+gawk+regex+system+kill
* install shellcheck and enable lint on macos/brew.
* add shellcheck fixes and exception
* reorder CHANGELOG entries
* Support SECRETS_VERBOSE env var in addition to -v
* don't use --quiet when decrypting in verbose mode
* show output of gpg encryption in verbose mode
* add tests for SECRETS_VERBOSE env var set to 0 and 1
* update changelog, reorder entries.
* add tests for 'cat' and 'hide' with SECRETS_VERBOSE=1
* respect SECRETS_DIR and SECRETS_EXTENSION in tests
* add line regarding fixes to CHANGELOG.md
* test with non-standard SECRETS_EXTENSION
* Add details about init, mention SECRETS_EXTENSION in init page
* update git-secret-init man page
* clarification about killperson and secrets, rephrasing.
* how to develop without docker/test-kitchen
* doc changes about gh-pages branch. other clarifications.
* OSX has been renamed MacOS (except in travis-ci)
* have lint target run shellcheck over tests
* lint and fix tests/ since shellcheck knows bats
* lint and fix tests/ since shellcheck knows bats
* revert debug output
* changes for shellcheck
* revert unintended change
[tests/_test_base.bash]
* use 'local' for user/filename vars, not 'export'
* add note about Shellcheck and tests/
* local can only be used in functions - use export
* restore shbang edited in error
* code style in CONTRIBUTING.md and PR template
* make link to CONTRIBUTING.md in .github/PULL_REQUEST_TEMPLATE.md
* mention shellcheck and 'make lint'
* mention that you should update CHANGELOG.md
* mention spellchecking with aspell
* more spelling fixes
* add to CHANGELOG about style guide/dev philosophy
* remind contributors to update .ronn file/man page
* add 'git secret tell -v' option to show output of key imports
* add tests for tell with/without -v
* remove unneeded test code and bats diagnostic output
* tests and comments about 'changes' for #291
* add 'changes' tests, improve diagnostic
* preserve trailing newlines in diff output
* use bash trickery to preserve trailing newlines in captured text
* test 'changes' on files without newlines and when called on a non-existant file
* improve comments and variable names
* test with expired key, add 'whoknows -l'
* 'whoknows -l' shows key expiration dates
* also added docs and tests for `whoknows -l`,
* tests for expired keys,
* epoch_to_date functions
* update man pages
* fix epoch-to-date conversion on OSX
* test output of 'whoknows -l'
* fix for lint/shellcheck
* fix for osx
* lint fix
* use date as found in $PATH
* disable 'set -e' as little as possible
* test that hiding secret with expired key fails
* add test of user key without username.
* revert to performing most tests with 'user1'.
* move user4 private/public key fixtures
* factor code fetching emails from keyrings, add comments.
* use factored _warn_or_abort()
* add to, clean up, and clarify comments.
* -F (force even if gpg fails) option for hide and reveal
* allow 'reveal' to decrypt a subset of files.
* update and regen man pages
* man pages update and improvements
* text about why all files should be hidden at once
* add _warn() and _warn_or_abort()
* tests for -F option
* glob source .sh files in Makefile better
* add comment about issue #238. cleanup error msg.
* test exact case in #253
* disable gnupg doc building on ubuntu-rolling
* name keys after emails, not usernames
* use emails to specify users
* rename and add function to get emails from keyrings
* rename directories holding gpg test fixtures
* deny emails that aren't in the keyring, and test.
* require 'killperson' emails to exist in keyring
* change test to reflect killperson must use email
* remove no-longer-needed test function
* factor function _assert_keychain_contains_emais()
* fix/make lint happy
* trying alpine
* Make directory /usr/local/src/ for Alpine based distros
* fixes some alpine issue
* move gem install etc to its own task
* moved gem install etc for alphine into dependencies
* reenabling all ci tests
* typo fix as per review
* clarity around doc build disable being gnupg docs
* commit about ignoring non-zero return value
* deploy skip_cleanup: true
* need to deploy when '! -z KITCHEN_REGEXP'
* rsync missing on gnupg1-ubuntu-latest
* fixes missing man pages on gnupg2-ubuntu-rolling
* replace yum with dnf
* ansible comments out dpkg.cfg.d excludes path-exclude=/usr/share/man/.*
* gem 'rspec'
* Install rspec in /usr/local/bin for RedHat based distros
* whitespace in Gemfile.
* fixes for git secret changes
check that we can find filenames passed on command line, and that
we can find the unencrypted versions of hidden files.
* new test
* add tests
* don't hide files that don't exist decrypted.
and change related error message to 'file not found: filename'.
* ensure all source files are present before hiding
* test for 'add' while unencrypted file missing
fixes for linter errors about 'which'
For example:
in utils/deb/deb-ci.sh line 27: 'which git-secret':
SC2230: which is non-standard. Use builtin 'command -v' instead.
remove inoperative links
reflect code review input
add test for 'git secret cat'
restore sponsor links
ronn file for manpage
cleanup. Remove -f option.
bump version to 0.2.4
remove unused variable
add references to git secret cat in ronn docs.
git-secret-cat man page
adds a docker file for integration tests
update integration framework and tests to include alpine
update makefile to include apk builds for alpine
update build utils to include apk compatibility
changed a couple switch lines to be compatible with alpine
adds travis tests
When searching for files to be removed after being hidden we must use
find with -path instead of -name if we want to remove files in
subdirectories as well.
Changes:
1. When adding new file path is normalized in respect to both CWD and repo root
2. All commands now know about that
3. Tests are fixed
Refs #86, #85, #83
Changes:
1. Fixes#86, now all variables are accessed as functions
2. Fixes#85, now these use cases are working correctly
3. Fixes#83, now init works relative to `.git` folder
4. Closes#77, zsh-plugin is deprecated
5. Refs #53, done some refactoring to tests
6. Closes#82, added additional information to pull-request template
7. Refs #22, plugins are deprecated
8. Also made a lot of improvments into both code and tests
There are a lot of changes, multiple things were refactored: tests,
some commands, building and meta.
Several critical bugs fixed.
Changes:
1. Fixed#74, when `_user_required` was not working after reimporting keys
2. Closes#73, now it is possible to provide multiple emails to the `killperson` command
3. Closes#72, now it is possible to provide multiple emails to the `tell` command
4. Closes#71, now every doc in this project refer to `git-secret.io` instead of old `gh-pages` website
5. Closes#70, now installation section is removed from main `man` file
6. Closes#69, now "See also" section in the `man`s are clickable
7. Closes#61, added "Manual" section to the manuals
8. Refs #38, added `centos` Dockerfile, but `ci` testing is still failing
9. Refs #52, tests are refactored. Added `clean` command tests, removed a lot of hardcoded things, moved tests execution from `./temp` folder to `/tmp`, added a lot of new check in old tests, and some new test cases
10. Refactored `hide` and `clean` commands to be shorter
11. `shellcheck` is now supported with `make lint`
Additional features are not comming to 0.2.2 after this commit.
- Improve, expand, correct, and update docs (#699)
- Update docs for use with CI/CD server (#675)
- Upgrade bats-core to v1.6.0 (#755)
- Test, and build RPMS, with Rocky and Alma Linux instead of CentOS (#765)
- Automate testing code on windows using WSL (#846)
- Automate testing code on FreeBSD (#455)
- Improve testing of .gitignore contents (#792)
- Automate running verbose tests with SECRETS_TEST_VERBOSE=1 (#794)
- Improve documentation about installing on Windows (#843)
## 0.4.0
### Bugfixes
- Escape filenames with special characters before adding to `.gitignore`
- Better error handling around telling an email twice (#634)
- Fix for `-P` (#647)
### Misc
- Removed `test-kitchen`
- Moved from `travis` to GitHub Actions
- Changed almost all infrastructure code
- Moved away from Bintray to Artifactory
- Changes how GitHub Pages work
- Add security disclaimer for git-secret-killperson
- Improve documentation about releases
- Man page improvements
## Version 0.3.3
### Bugfixes
- In 'tell', warn about disabled, revoked, expired, or invalid keys (#552, #508, #317, #290, #283, #238)
- Error if 'tell' is used on an email address with multiple keys (#552)
- Don't let 'reveal' clobber secret files (#579)
- Updated test key fixture that had expired (#607)
### Misc
- Improve docs about using gpg with git-secret (#577)
- Text improvements and More about security in git-secret.7 man page (#603)
- Reflect changes in ruby bundler during build process
- Upgrade build process to ansible 2.9
- Use shellcheck 0.7.1 with CI, not 'latest' (#609)
- Improve output of `git-secret add`
## Version 0.3.2
### Bugfixes
- Fix mention of version in git-secret add man page (#544)
### Misc
- Update developer docs, especially regarding mac, docker, and test-kitchen (#195)
- Update man pages to mention version documented (#420)
## Version 0.3.1
### Misc
- Update man pages
## Version 0.3.0
### Features
- Support SECRETS_PINENTRY env var for gnupg --pinentry-mode parameter (#221)
- Show output from gnupg if 'hide' fails (#516, #202, #317)
- Add support for Busybox (#478)
### Bugfixes
- Use OSX's mktemp on OSX, even if there's another version in PATH. (#485)
- Make rsync a build requirement on debian (#500)
- Use gnupg1, not gnupg2, when tests specify gnupg1 (#241)
- Note dependencies gawk, bash, and coreutils in linux packages (#493)
- Handle case of key having no email and a comment (#527)
- Avoid blank lines from output of 'clean -v'
### Misc
- Improve messaging and logic around deleting tmp files.
- Add note about secrets and old keys (#499)
- Transition build process from python 2 to python 3 (#487)
- Upgrade build process from ansible 2.5 to ansible 2.8
- Fix build process when installing gnupg2 source deps on Ubuntu
- Close file descriptor 3 when running gnupg subprocesses (#521)
- Small optimization in 'hide'
- Improve code comments
- Update docs to note that git-secret repos modified by git-secret 0.2.3 and
later are not backward compatible with pre-0.2.3 versions of git-secret. (#536)
## Version 0.2.6
### Features
- git-secret is now available in Fedora, link added to README.md. (#315)
- Support automated testing on windows with Travis CI (#372)
- Support SECRETS_VERBOSE env var to enable verbosity (#323)
- Use gpg without --quiet when decrypting in verbose mode (#394)
- Add -v options to 'tell' and 'reveal', showing gpg output (#320, #395)
- Change 'init' to never ignore .secret files (#362)
- 'add' appends filepaths to .gitignore by default (#225)
- Automate the GitHub release (#411)
### Bugfixes
- Fix 'hide -m' when used as first hide operation (#466)
- Fix code to respect $TMPDIR when generating tmp files (#451)
- Be more careful when deleting test files (#360)
- Use separate directory when testing, instead of using $BATS_TMPDIR directly (#407)
- Fix 'whoknows -l' and related tests on FreeBSD (#454)
- Fix git-secret init when used on busybox (#475)
- Update git-secret.io, fix utils/gh-branch.sh to use 'git all --add' (#344)
- Fix link to homebrew's git-secret in README.md (#310)
- Remove diagnostic output from test results (#324)
- Remove un-needed redirection in 'reveal' (#325)
- Fix link to current contributors in CONTRIBUTING.md (#331)
- Fix tests when running from git hooks (#334)
- Fix typo, remove temp directory in utils/tests.sh (#347)
- Spelling fixes
- Fix re: SECRETS_DIR in 'init' and SECRETS_EXTENSION in test_reveal.bats (#364)
- git-secret will fail if you pass params or filenames that are not understood (#390)
- Use SECRETS_GPG_COMMAND env var in gpg version check (#389)
- Add header to git-secret.7 man page, for debian and doc improvement (#386)
- Respect DESTDIR when installing as per GNU/debian/etc recommendations (#424)
- Use git check-ignore to test for files ignored by git
### Misc
- Improve docs about hide -m option (#467)
- Document SECRETS_VERBOSE and improve env var docs (#396)
- Setting SECRETS_TEST_VERBOSE env var shows debug info during tests (EXPERIMENTAL)
- Add documentation about how to write tests.
- Suppress 'cleaning up temp files' messages unless in a verbose mode.
- Improve git-secret user messaging.
- Update CHANGELOG.md to mention fix for #281 in v0.2.5 (#311)
- Add text explaining git-secret Style Guide and Development Philosophy
- Use Shellcheck on tests/ files, changes for Shellcheck in tests/ (#368)
- Use Shellcheck on MacOS/osx travis tests (#403)
- Show commands run by Makefile as per debian upstream recommendations (#386)
- Upgrade bats-core to v1.1.0, import bats-core into vendor/bats-core (#377)
- Use gawk to parse emails from gpg output
- Optimize code that parses keyrings
- Remove unused code
## Version 0.2.5
### Features
- Add support for FreeBSD (#244)
- Add -l option to whoknows, which shows key expiration dates (#283)
- Add -P option (preserve permissions) to reveal and hide (#172)
- Add -F option (force, changing some errors to warnings) to hide and reveal (#253)
- Allow user to specify name of secret dir at runtime using SECRETS_DIR env var, and test (#247, #250)
### Bugfixes
- Fix issues with spaces in paths and filenames (#226, #135)
- Fix issue when 'hide' used in subdir of repo (#230)
- Fix issues in 'changes' with trailing newlines (#291)
- Fix 'hide' to only count actually hidden files as hidden (#280)
- Fixed bugs and improved error messages (#174)
- Issue error message when unable to hide a secret (#202, #238)
- Accept gpg key with no name, only an email (#227)
- Require keys to be specified by email, as documented (#267)
- Disallow 'git secret tell' or 'killperson' with emails that are not in keyring (also #267)
### Misc
- Added notes about packages and for package maintainers (#281)
- Improve documentation regarding operation with different versions of GPG (#274, #182)
- Documentation improvements, error message and text improvements, and typo fixes (#254)
- git-secret RFC#001 added, documenting a path towards independence from gpg binary formats (#208)
- Add tests for expired gpg keys, and gpg keys with only emails (#276)
## Version 0.2.4
### Features
- Added `git secret cat` feature (#141)
### Bugfixes
- `git secret hide` and `git secret changes` check for files more carefully (#153, #154)
### Misc
- Documentation and error message improvements (#126, #136, #144, #150)
- Build and CI fixes (#152, #179, #186, #188, #189)
- Migrate to `bats-core` bash testing framework
## Version 0.2.3
### Features
- Added `-m` option to `hide` command, files will only be hidden when modifications are detected (#92)
- Changed how path mappings file works: colon delimited FSDB in `.gitsecret/paths/mapping.cfg', so git-secret
can store checksums of hidden files. Note this means git-secret repos modified by git-secret 0.2.3
or later are not backward compatible with pre-0.2.3 versions of git-secret. (#92)
- `git secret init` now adds `random_seed` to `.gitignore` (#93)
### Bugfixes
- Dropped `git check-ignore`, using `git add --dry-run` instead to check for ignored files (#105,#38)
- Fixed `gnupg` >= 2.1 CI tests (#6)
### Misc
- Now users can run local CI tests using test-kitchen (#6)
- Migrated travis ci tests to test-kitchen for Linux platforms.
- Added more `gpg` version to test matrix (#99)
- Added CentOS to test matrix (#38,#91)
- All tested Linux platforms now use latest release of `shellcheck`
- Added Alpine to test matrix, and apk is now built. (#75)
## Version 0.2.2
### Features
- Change how the `usage` command works (#48)
- Now `git-secret` works from any place inside `git-tree` (#56)
- Added `-d` option to the `hide` coomand: it deletes unencrypted files (#62)
- Added `-d` option to the `hide` command: it deletes unencrypted files (#62)
- Added new command `changes` to see the diff between the secret files (#64)
- Fixed bug when `_user_required` was not working after reimporting keys (#74)
- Now it is possible to provide multiple emails to the `killperson` command (#73)
- Now it is possible to provide multiple emails to the `tell` command (#72)
### Bugfixes
- Fixed bug when `_user_required` was not working after re-importing keys (#74)
- Refactored `hide` and `clean` commands to be shorter
### Misc
- Now every doc in this project refer to `git-secret.io` instead of old `gh-pages` website (#71)
- Now installation section is removed from main `man` file (#70)
- Now "See also" section in the `man`s are clickable (#69)
- Now "See also" sections in the `man` pages are clickable (#69)
- Added "Manual" section to the manuals (#61)
- Added `centos` container for `ci` testing (#38)
- Tests are refactored. Added `clean` command tests, removed a lot of hardcoded things, moved tests execution from `./temp` folder to `/tmp`, added a lot of new check in old tests, and some new test cases (#52)
- Refactored `hide` and `clean` commands to be shorter
- Added `CentOS` container for `ci` testing (#38)
- Tests are refactored. Added `clean` command tests, removed a lot of hard-coded things, moved tests execution from `./temp` folder to `/tmp`, added a lot of new check in old tests, and some new test cases (#52)
- `shellcheck` is now supported with `make lint`
## Version 0.2.1
- Now everything is tested inside the `docker`-containers and `OSX` images on `travis`.
- Added autodeploy to `bintray` in `.travis.yml`.
- Added `.ci/` folder for continuous integration, refactored `utils/` folder.
### Misc
- Added `CONTRIBUTING.md` and `LICENSE.md`.
- New brand logo in the `README.md`.
- Added autodeploy to `bintray` in `.travis.yml`.
- Now everything is tested inside the `docker`-containers and `OSX` (MacOS) images on `travis`.
- Added `.ci/` folder for continuous integration, refactored `utils/` folder.
- Everything is `shellcheck`ed (except `tests/`).
## Version 0.2.0
- Added `changes` command to see the difference between current version of the hidden files and the commited one
### Features
- Added `changes` command to see the difference between current version of the hidden files and the committed one
- Added `-f` option to the `reveal` command to remove prompts
- Changed the way files were decrypted, now it is a separate function
### Bugfixes
- Some bugs are fixed
### Misc
- New installation instructions
- Changed the way files were decrypted, now it is a separate function
## Version 0.1.2
### Features
- Added `-i` option to the `git-secret-add` command, which auto adds unignored files to the `.gitignore`
- Documentation improved with `Configuration` section
- Added extra tests: for custom filenames and new features
- `Makefile` improvements with `.PHONY` and `install` target
### Misc
- `.github` templates added
- Documentation improved with `Configuration` section
- `Makefile` improvements with `.PHONY` and `install` target
- Added extra tests: for custom filenames and new features
## Version 0.1.1
### Features
- Added `--dry-run` option to the `git secret` command, which prevents any actions.
- Now `install_full_fixture()` returns a fingerprint
- Now `uninstall_full_fixture()` receives two args
- Fixed bug, when tests were failing with `gpg2`
- New travis strategy: testing both `gpg` and `gpg2`
### Misc
- Removed animation from docs, now using `asciinema.org`
- `install_full_fixture()` returns a fingerprint
- `uninstall_full_fixture()` receives two args
- Fixed bug when tests were failing with `gpg2`
- New travis strategy: testing both `gpg` and `gpg2`
## Version 0.1.0
- Initial release
### Features
- Implementation of git secret add
- Implementation of git secret clean, with -v option
- Implementation of git secret hide, with -c 'clean' and -v option
- Implementation of git secret init
- Implementation of git secret killperson
- Implementation of git secret list
- Implementation of git secret remove, with -c option
- Implementation of git secret reveal, with -d homedir and -p passphrase options
- Implementation of git secret tell, with -m email and -d homedir options
1. Create your own or pick an opened issue from the [tracker](https://github.com/sobolevn/git-secret/issues). Take a look at the [`help-wanted` tag](https://github.com/sobolevn/git-secret/labels/help%20wanted)
2. Fork the git-secret repo and then clone the repository using a command like `git clone https://github.com/${YOUR_NAME}/git-secret.git`
3. Make sure that everything works on the current platform by running `make test`.
You can also try the experimental `SECRETS_TEST_VERBOSE=1 make test`, which will
show you a lot of debug output while the tests are running.
Note that 'experimental' features may change or be removed in a future version of `git-secret`.
4. If you want to test on multiple operating systems just push your PR, GitHub Actions will cover everything else
Basically, our `make` file is the only thing you will need to work with this repo.
## Process
### Environment
Before starting make sure you have:
For development of `git-secret` you should have these tools locally:
- gnupg (or gnupg2), see below if not packaged by your distribution/OS (i.e. MacOS)
- sha256sum (on freebsd and MacOS `shasum` is used instead)
- make
Only required if dealing with manuals, `gh-pages` or releases:
To test `git-secret` you will need:
- ruby, ruby-dev
- [docker](https://www.docker.com/)
### Getting started
### Code style
1. Create your own or pick an opened issue from the [tracker][tracker]. Take a look at the [`help-wanted` tag][help-wanted]
2. Fork and clone your repository: `git clone https://github.com/${YOUR_NAME}/git-secret.git`
3. Make sure that everything works fine by running `make test`
New features and changes should aim to be as clear, concise, simple, and consistent
1. clear: make it as obvious as possible what the code is doing
2. concise: your PR should be as few characters (not just lines) of changes as _reasonable_.
However, generally choose clarity over being concise.
Clarity and conciseness can be in conflict with each other. But
it's more important for the code to be understandable than for it to be small.
Therefore favor writing clear code over making shorter diffs in your PRs.
3. simple: this dovetails with the previous two items.
git-secret is a security product, so it's best to have the code be easy to understand.
This also aids future development and helps minimize bugs.
4. consistent: Write code that is consistent with the surrounding code and the rest of the git-secret code base.
Every code base has its own conventions and style that develop and accrete over time.
Consistency also means that the inputs and outputs of git-secret should be as consistent as reasonable
with related Unix and git tools, and follow the 'rule of least surprise',
also known as the 'principle of least astonishment': <https://en.wikipedia.org/wiki/Principle_of_least_astonishment>
We wrote this to clarify our thinking about how git-secret should be written. Of course, these are philosophical goals,
not necessities for releasing code, so balancing these four ideals _perfectly_ is both unwarranted and impossible.
### Writing PRs
If you're planning a large change to `git-secret` (for example, a lot of lines/characters of diffs, affecting multiple commands,
changing/adding a lot of behavior, or adding multiple command-line options), it's best to discuss the changes in an Issue first.
Also it's often best to implement larger or complex changes as a series of planned-out, smaller PRs,
each making a small set of specific changes. This facilitates discussions of implementation, which often come to light
only after seeing the actual code used to perform a task.
As mentioned above, we seek to be consistent with surrounding git and Unix tools, so when writing changes to git-secret,
think about the input, output, and command-line options that similar Unix commands use.
Our favor toward traditional Unix and git command-style inputs and outputs can also mean it's appropriate to
lean heavily on git and widely-used Unix command features instead of re-implementing them in code.
### Development Process
1. Firstly, you will need to setup development hooks with `make install-hooks`
2. Make changes to the files that need to be changed
3. When making changes to any files inside `src/` you will need to rebuild the binary `git-secret` with `make clean && make build` command
4. Run [`shellcheck`][shellcheck] against all your changes with `make lint`
5. Now, add all your files to the commit with `git add --all` and commit changes with `git commit`, make sure you write a good message, which will explain your work
6. When running `git commit` the tests will run automatically, your commit will be canceled if they fail
7. Push to your repository, make a pull-request against `develop` branch. Please, make sure you have **one** commit per pull-request, it will be merge into one anyways
1. Make changes to the git secret files that need to be changed
2. When making changes to any files inside `src/`, for changes to take effect you will need to rebuild the `git-secret` script with `make clean && make build`
3. Run `shellcheck` against all your changes with `make lint`.
You should also check your changes for spelling errors using 'aspell -c filename'.
4. Add an entry to CHANGELOG.md, referring to the related issue # if appropriate
5. Change the `man` source file(s) (we write them in markdown) in `man/man1` and `man/man7` to document your changes if appropriate
6. Now, add all your files to the commit with `git add --all` and commit changes with `git commit`.
Write a good commit message which explains your work
7. When running `git commit` the tests will run automatically, your commit will be canceled if they fail.
You can run the tests manually with `make clean build test`.
8. Push to your repository, and make a pull-request against `master` branch. It's ideal to have one commit per pull-request,
but don't worry, it's easy to `squash` PRs into a small number of commits when they're merged.
### Branches
We have three long-live branches: `master`, `staging` and `develop` (and `gh-pages` for static site).
We have two long-live branches: `master` for the git-secret code and man pages, and `gh-pages` for the static web site.
The `gh-pages` branch tracks the `master` branch's `docs` folder, and is kept up-to-date using a GitHub Action.
- `master` branch is protected, since `antigen` and tools like it install the app from the main branch directly. So only fully tested code goes there
- `staging` - this branch is used to create a new `git` tag and a `github` release, then it gets merged into `master`
- `develop` is where the development is done and the branch you should send your pull-requests to
- `master` branch is protected, so only fully tested code goes there. It is also used to create a new `git` tag and a `github` release
### Continuous integration
By convention, you can name your branches like `issue-###-short-description`, but that's not required.
The `gh-pages` branch is used for the pages at `git-secret.io`. See 'Release Process' below.
CI is done with the help of `travis`. `travis` handles multiple environments:
### Writing tests
- `Docker`-based jobs or so-called 'integration tests', these tests create a local release, install it with the package manager and then run unit-tests and system checks
- `OSX` jobs, which handle basic unit-tests on `OSX`
- Native `travis` jobs, which handle basic unit-tests and stylechecks
`git-secret` uses [bats-core](https://github.com/bats-core/bats-core) for testing.
See the files in tests/ and the `bats-core` documentation for details.
Because the output of many commands can be affected by the SECRETS_VERBOSE environment
variable (which enables verbosity), it's best not to expect a particular number of lines of
output from commands.
### Release process
The release process is defined in the `git`-hooks and `.travis.yml`.
To create a new release, (you'll first need permission to commit to the repo, of course):
When creating a commit inside the `staging` branch (it is usually a documentation and changelog update with the version bump inside `src/version.sh`) it will trigger two main events.
Update the content of `CHANGELOG.md` for the release (this should be a matter of changing headers),
and update the version string in `src/version.sh`.
Firstly, new manuals will be created and added to the current commit with `make build-man` on `pre-commit` hook.
When creating a commit inside the `master` branch (it is usually a documentation and changelog update with the version bump inside `src/version.sh`).
Secondly, after the commit is successfully created it will also trigger `make build-gh-pages` target on `post-commit` hook, which will push new manuals to the [git-secret site][git-secret-site]. And the new `git` tag will be automatically created if the version is changed:
Then, push your code to GitHub. It will start the CI.
After all the checks have executed, GitHub Actions will test and build releases for specific platforms.
While CI is doing it's building and testing, finish the release on github by pushing the new tag with:
```bash
if [[ "$NEWEST_TAG" != "v${SCRIPT_VERSION}" ]]; then
git tag -a "v${SCRIPT_VERSION}" -m "version $SCRIPT_VERSION"
fi
git push --tags
```
Then it will be merged inside `master` when ready.
and then go to https://github.com/sobolevn/git-secret/releases to see that the new release is created. It might take some time.
#### Travis releases
#### GitHub automated releases
When creating a commit inside `master` branch, `travis` on successful build will publish new `deb` and `rpm` packages to [`bintray`][bintray].
We use GitHub actions to run the release process.
We use `artifactory` as an environment for the release.
You would need to get a review before release would be possible.
If you wish to override a previous release (*be careful*) you will need to add `"override": 1` into `matrixParams`, see `deb-deploy.sh` and `rpm-deploy.sh`
It can be reproduced locally with `make release`, but you will need `SECRETS_ARTIFACTORY_CREDENTIALS`.
After packages are released to https://gitsecret.jfrog.io we trigger `release-ci` workflow to test that installation works correctly.
#### Manual releases
Releases to `brew` are made manually.
Releases to `brew` are made manually, and involve opening a PR on the [Homebrew Core](https://github.com/Homebrew/homebrew-core) repo .
To get started, see the
[Homebrew docs about Formulae-related PRs](https://docs.brew.sh/How-To-Open-a-Homebrew-Pull-Request#formulae-related-pull-request)
and `brew bump-formula-pr --help`
#### Dockerhub releases
### Downstream Packages
[`Dockerhub`][Dockerhub] contains `Docker` images with different OS'es used for testing. It is updated via a `github` webhook on commit into `master`.
There are several distributions and packaging systems that may already have git-secret packaged for your distribution (although sometimes their versions are not the most current, and we recommend all users upgrade to 0.2.5 or above).
We also welcome financial contributions in full transparency on our [open collective](https://opencollective.com/git-secret).
Anyone can file an expense. If the expense makes sense for the development of the community, it will be "merged" in the ledger of our open collective by the core contributors and the person who filed the expense will be reimbursed.
## Credits
### Contributors
Thank you to all the people who have already contributed
to `git-secret` via commits to our git repository!
[![List of contributors](https://opencollective.com/git-secret/contributors.svg?width=890&button=0)](https://github.com/sobolevn/git-secret/contributors)
### Backers
Thank you to all our backers! [[Become a backer](https://opencollective.com/git-secret#backer)]
Thank you to all our sponsors! (please ask your company to also support this open source project by [becoming a sponsor](https://opencollective.com/git-secret#sponsor))
`git-secret` is a bash tool to store your private data inside a git repo. How’s that? Basically, it just encrypts, using `gpg`, the tracked files with the public keys of all the users that you trust. So everyone of them can decrypt these files using only their personal secret key. Why deal with all this private-public keys stuff? Well, to make it easier for everyone to manage access rights. There are no passwords that change. When someone is out - just delete their public key, re-encrypt the files, and they won’t be able to decrypt secrets anymore.
`git-secret` is a bash tool which stores private data inside a git repo.
`git-secret` encrypts files with permitted users' public keys,
allowing users you trust to access encrypted data using pgp and their secret keys.
With `git-secret`, changes to access rights are simplified, and private-public key issues are handled for you.
When someone's permission is revoked, secrets do not need to be changed with `git-secret` -
just remove their key from the repo's keyring using `git secret removeperson their@email.com`,
re-encrypt the files, and they won't be able to decrypt secrets anymore.
If you think the user might have copied the secrets or keys when they had access, then
Such packages are considered 'downstream' because the git-secret code 'flows' from the `git-secret` [repository](https://git-secret.io/installation)
to the various rpm/deb/dpkg/etc packages that are created for specific OSes and distributions.
We have also added notes specifically for packagers in [CONTRIBUTING.md](CONTRIBUTING.md).
## Sponsors
Support this project by becoming a sponsor. Your logo will show up here with a link to your website. [[Become a sponsor](https://opencollective.com/git-secret#sponsor)]
# RFC 0001 - A stable and forwards compatible public key storage format
**Feature Name:** Stable public key storage
**Status:** Final
**Type:** Enhancement
**Related components:** Core
**Start Date:** 2018-06-14
**Author:** Simon Massey
**GitHub issues:**
* #136 GnuPG2 2.2 vs 2.1 conflicts in keybox format
## Summary
A new internal public key storage format that avoids forwards compatibility issues between GPG releases. This proposal will keep forwards compatibility with older versions of git-secret.
## Motivation
GPG maintains backwards compatibility but not forwards compatibility. Running a new GPG version can and will upgrade the keyring storage files in a way that is not recognized by older versions of GPG. This is not normally a problem for typical GPG usage. Users will upgrade and rarely downgrade. It is a problem for git-secret as the keyring storage is committed to git and shared between users. Someone using an older version of GPG can no longer open the upgraded keyring file.
## Approach
git-secret will move away from using the keyring format as shared storage of public keys. Instead, it will store public keys as exported keys in ASCII armor format. The public key export format is stable and forwards compatible. GPG users will typically be running different GPG or PGP versions and are able to exchange keys successfully. Bugs that affect git-secret's ability to use exported public keys will likely affect typical GPG key exchange usage. Such bugs are likely to be caught and fixed by the wider open source community.
git-secret may need to store and process meta-data about keys to make it efficient to work with keys that are stored within individual files. It will use the machine-readable ["colon listings format"](https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob_plain;f=doc/DETAILS) for this purpose.
It is anticipated that `bash` and `gawk` will be sufficient to work efficiently with the new file formats.
## Design
The new storage format will be implemented as follows:
1. Keys will be stored in `~/.gitsecret/keys` in `gpg --armor --export` format. The use of ASCII armor rather than binary format is to make debugging of key related issues easier. The filename of the key will be `<keyid>.pub.gpg` (using Field 5 the "64-bit keyid" of the colon listings format)
1. Key meta data will be stored alongside the key file in the `gpg --keyid-format long --with-colons` format. The file name will be `<keyid>.pub.cln`
1. A folder `~/.gitsecret/cache` will be added to `.gitignore`. At this location, a public keyring will be maintained on a per user bases and won't be shared between users. This is simply a "keyring cache" of the keys used to encrypt files.
git-secret-tell will:
1. Scan the set of `*.pub.cln` files to find all currently told identities. If the given identity is in the list do nothing.
1. If the given identity isn't listed run `gpg --armor --export` against the users `$HOME` keyring to create the `<key-id>.pub.gpg`.
1. Run `--keyid-format long --with-colons` of the exported key to create the `<key-id>.pub.cln`.
Note that the additional steps to ensure that older versions of git-secret know about the newly told identity will be outlined below.
git-secret-hide will:
1. Extract the list of "64-bit keyid"s who are told from the `*.pub.cln` files. Note that multiple identities can be listed against each key.
1. Checked this against the list of "64-bit keyid"s in the "keyring cache" at `~/.gitsecret/cache`.
1. Import any missing keys into the "keyring cache". It is anticipated that `gawk` will be sufficient to perform this calculation.
1. Run the current logic using the "keyring cache".
Note that the additional steps to ensure that older versions of git-secret know about the newly told user will be outlined below.
git-secret-whoknows will:
1. The list of identities will be loaded by parsing the `.pub.cln` files. Note that multiple identities can be listed against each key.
git-secret-usage will:
1. Document the git-secret-migrate command discussed in the next section.
git-secret-reveal will:
* Be unchanged.
git-secret-remove will:
* Be unchanged.
git-secret-list will:
* Be unchanged.
git-secret-killperson will:
1. Remove the key from the keyring cache.
1. Delete both `<key-id>.pub.gpg` and `<key-id>.pub.cln` files.
git-secret-init will:
1. Add `~/.gitsecret/cache` into `.gitignore`.
1. Run any current logic using the ignored "keyring cache".
git-secret-clean will:
* Be unchanged.
git-secret-changes will:
1. Show differences the `<key-id>.pub.gpg` and `<key-id>.pub.cln` files in `~/.gitsecret/keys`.
git-secret-add will:
* Be unchanged.
A new command git-secret-migrate will:
1. Create the folder `~/.gitsecret/cache` and add it to the `.gitignore` file.
1. Extract all keys from the old keyring generating `<key-id>.pub.gpg` and `<key-id>.pub.cln` files in `~/.gitsecret/keys`
## Version Compatibility
Backwards compatibility will the old keyring storage approach will be maintained as follows:
1. For each changed command a guard will be added that checks for the existence of `.gitsecret/cache`.
1. If the folder exists it proceeds as normal.
1. If it does not exist it will report that the repo was initialized by an older version of git-secret and tell the user to run git-secret-migrate
Forwards compatibility with older versions of git-secret will be maintained as follows.
git-secret-hide will:
1. Have a guard that will check for the existence of the old keyring. If it exists it will check it for any new public keys and extract them into the new format prior to running.
git-secret-tell will:
1. Will check for the existence of the old keyring. If it exists it will load the new public key into it.
git-secret-killperson
1. Will check for the existence of the old keyring. If it exists it will delete the user from it.
## Drawbacks
To maintain forward compatibility the approach requires the existing logic to kept working for a period of time. We can give a deprecated warning if the forwards compatibility logic is running. The warning can be suppressed using a command-line flag.
## Alternatives
What other designs have been considered? Unknown.
What is the impact of not doing this? Team members are locked out of secrets when only one other team member upgrades GPG. This can go undetected until the victims needs the secrets in a hurry for production support. Bad things then happen.
## Unresolved questions
What parts of the design are still to be done? None.
<!-- Place this tag where you want the button to render. -->
<aclass="github-button"href="https://github.com/sobolevn/git-secret"data-icon="octicon-star"data-size="large"data-show-count="true"aria-label="Star git-secret on GitHub">
Here's a list of external plugins for `git-secret` developed by other awesome developers:
- [git-secret-diff](https://github.com/msilvestre/git-secret-diff) adds `git secret diff` command similar to `git diff` to see changes in your secrets in different commits
`git-secret-add` adds a filepath(es) into the `.gitsecret/paths/mapping.cfg`. When adding files, ensure that they are ignored by `git`, since they must be secure and not be commited into the remote repository unencrypted.
If there's no users in the `git-secret`'s keyring, when adding a file, an exception will be raised.
It is not recommened to add filenames directly into the `.gitsecret/paths/mapping.cfg`, use the command.
## OPTIONS
-i - auto adds given files to the `.gitignore` if they are unignored at the moment.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.