bump to 0.8.0

[lazypower]

Double base64 encoding for maximum effort

• I had made some irrational assumptions about newlines during early dev. I've refactored those to be less aggresive about trimming newlines.
• Additionally introduced a default behavior of base64 encoding BEFORE we send to kms, this will ensure our multi-line secrets remain intact.

• Retains backwards compatibilty by wrapping the decode to just return the raw-decrypted data if there's an error, which may have unintended consequences - but i'm not going ot invent the problem before i patch it.

  This will bring us up to another point release, thankfully in a backwards compatible way. Note that moving forward, all secrets will be double base64 encoded by default, as will rotating old entries with newer data.

  so the flow, and final resulting data-envelope is as follows:

  (Unencrypted-raw-data) -> (Base64 encoded data) -> KMS -> (Binary encrypted
  data) -> Base64 of encrypted data
  

Related to #4

resolves multi-line, but does not resolve contexts outside of ENV population.

[marcoceppi]

I just realized, if you previously had and expected a base64 encoded string this will decode which doesn't quite maintain backwards compat.

Would it be better to instead create an object like:

version: v1
kind: sctl
encoding: base64
data: |
  <base64encodedstring>

Thereby if you do decode base64 but don't get a matching doctument structure like this, then you can assume just return the original string (backwards, backwards compat). If you do have a matching structure you can then be confident that decoding the data key from the payload will yield a correct result.

I know this strays a bit but I can't help but feel that if I previously sctl saved a b64encoded string that it'd break compat. Could also just go straight for a 1.0 and skip this too - though I think adding payload metadata might be helpful in general

[lazypower]

If i add the payload metadata i'm going to let it soak for a bit before I cut a 1.0 - i want the data format to be stable enough that i'm not going to go back in and muck with it once we hit that point. i'm generally +1 to adding the behavior you're asking for. Something like:

echo "my really big secret" | base64 | sctl add BIG_SECRETS --no-decode

as the older entries wont have the "encoding" field, they will default to skip, and wont be piped through that decoder.

thoughts?

[lazypower]

@marcoceppi since you had requested some changes, this branch is getting hairy with yak shaving, and the feature is incomplete - i'm goign to tag you for re-review. Once we've got a path forward that you're happy with i'll cycle into getting that on the branch, and re-request review.

dismissing prior reviews

[lazypower]

Ok, I think this is ready for re-review. Still a bit sparse on test coverage, but i'm losing hair and sleep over this, and will re-visit.