Support OpenSSL secret encryption workflow

[fredcooke]

In my day to day work, environmental secrets are stored encrypted in src/main/secrets and src/main/secrets/values and sub directories thereof. I have a set of scripts to make adding and reviewing and managing the life cycle of secrets easier but it would be nice if this was built into the tool used for managing the source code and doing the builds.

I understand there used to be a kubesec implementation in branchout and that it may be found in the history somewhere - I'll check that out before getting too deep into this, but some thoughts on commands needed:

• clean decrypted files - removes plain text secrets from the disk once you're done working with them - all disks should be encrypted now, so short term presence isn't an issue, but they shouldn't be left laying around longer term or they might be exposed
• clean all decrypted files - same but for ALL projects in a branchout tree, not just the current directory structure.
• decrypt all - find and decrypt secrets in this project, including legacy secrets with earlier and later encryption, and values with later encryption, name the files .text or .open or .plain or something, but assymetric so that running encrypt after decrypt doesn't find and re-encrypt EVERY secret
• encrypt all - find .raw files in the hierarchy and encrypt them with appropriate suffix
• encrypt one file - encrypt the specified file with the appropriate suffix - used by the above to do bulk operations without duplicate code
• encrypt one value - similar to above, but capture the value during the run rather than requiring a .raw file be present
• scan for trailing newlines in values directory and report any found
• compare the secrets from one git revision with another using an external recursive visual diff tool such as kdiff3 or similar

This should have a few smarts:

• take in the pass phrase at the start of each command and reuse it for each iteration internally
• produce a summary of what was done for each command
• when encrypting, first validate the credential against some kind of canary encrypted test file to ensure it matches the existing encrypted files in the repo and doesn't create a broken content tree with mixed passphrases
• work correctly from the project root (home of .git, pom.xml, src/ etc) and anywhere below that, doign what git does, and finding the root by looking upward and basing actions on that location, not the current one.
• validate the correctness of the version of OpenSSL (YAGNI, its good enough on mac, win, and lin now)

I will review this and edit in more or correct things tomorrow, however that's a good start in terms of a spec, and clearly there's a priority order for commands from basic/essential to fancy/optional/extra.

[fredcooke]

This will need some configuration with defaults:

• Secrets directory: Default: src/main/secrets/values
• OpenSslEncryptMethodArgs: Default: enc -md sha256 -pbkdf2 -aes-256-cbc -base64
• OpenSslDecryptMethodArgs: Default: enc -md sha256 -pbkdf2 -aes-256-cbc -d -base64
• Encrypted secret suffix: Default: .sha256.aes256
• Decrypted secret suffix: Default: .txt
• Ready to encrypt secret suffix: Default: .raw

Commands should be:

0. branchout secrets verifykey - requests key, finds all existing secrets, decrypts them into /dev/null or equivalent and reports statistics if further argument silent is not given - return code 0 indicates success, N secrets, all of which successfully decrypted by the provided key, If failing report the file name of the bad secrets one by one as processed as quiet means nothing if it's going to fail.
1. branchout secrets encrypt - requests key, runs verifykey quiet finds all ready to encrypt files and encrypts them into the encrypted suffix file name variant 2.branchout secrets decrypt - requests key, runs verifykey quiet, finds all encrypted secret files and decrypts them into the decrypted suffix file name variant
2. branchout secrets clean - no key required, removes all decrypted and ready to encrypt files leaving only encrypted files and any subdirectories (ambivalent to empy dirs, neither create nor remove)
3. branchout secret create - requests key, requests value, runs verifykey quiet, creates .raw file, encrypts it, then removes .raw file
4. Items 1/2/3 can take a subpath/filename argument without suffix and without base dir and only operate on that particular secret - no args means all files found
5. branchout secrets check

As per original ticket it should establish the project base directory and use that and function identically anywhere below that. Eg if you have:

~/projects/myProject/myGroup/myRepo/ and in it is src/main/secrets/values and numerous other files/dirs, then it should work in that base dir and anywhere below it equally well. It should use the standard branchout project structure to do this, not search for a .git directory as sometimes projects are built locally before git init, commit, and being pushed to the remote repository.

Output for 1, 2, 3 should be like this:

Decrypted N secrets from DIR matching SUFFIX Encrypted N secrets in DIR matching SUFFIX Cleaned N secrets in DIR matching SUFFIX and SUFFIX

With 0 outputting something like:

Found and successfully decrypted N secrets in DIR OR Found N secrets in DIR but failed to decrypt Y of them, only X were valid

And 4 being the same as 1 but with a leading line like:

Created secret with value N bytes long and name NAME in DIR

And then followed by the output from 1 which it calls before cleaning up using 3

This spec is a bit different than my original post but I think it's more thorough and useful, too. For review by @stickycode before I go ahead and implement it.