Hi HN!<p>I wrote a tool that partially encrypts files based on the presence of a HEREDOC.<p>Check it out:
https://github.com/higgins/privatize<p>When added to a git repo, it will automatically transparently encrypt/decrypt files you want privatized.<p>For example if you configured your repo to privatize the file `example.txt`, you could write:<p><pre><code> ```
Today I a burrito.
<<PRIVATE
I was on the toilet for hours.
PRIVATE
I got a lot of reading done.
```
</code></pre>
but when git-commit'ed would become:<p><pre><code> ```
Today I a burrito.
<<PRIVATE
xuJ0fld2vmNWaVLogTIufmWsiFso
PRIVATE
I got a lot of reading done.
```
</code></pre>
Diffing works as you expect (on the unencrypted source) and only those with the `privatize` symmetric key would be able to unlock and decrypt these files.<p>Why did I do this?<p>I keep a public log of what I plan to accomplish and what I'm working on both personally/professionally.
At the end of the day, I write a summary of everything that happened.
Naturally, there are some details of my life that should be kept private (details of too-be-launched projects, sensitive family events, etc).<p>It's helpful for me to track everything in one file so as to keep the day's context together.<p>Would love to know what you think!
Justin
This is a neat idea. I wrote something similar recently but with the aim of encrypting sensitive values (like API keys) in YAML config files, for similar reasons — so people without the key can see most of the config but not the secret parts. The script is then used by an automated deployment process to decrypt the sensitive values when the config file is moved into place.
FYI: this was inspired by the great `git-crypt` (<a href="https://github.com/AGWA/git-crypt" rel="nofollow">https://github.com/AGWA/git-crypt</a>)<p>More on my motivations here: <a href="https://encapsulate.me/writing/Privatize.html" rel="nofollow">https://encapsulate.me/writing/Privatize.html</a>
I might not have properly understood this tool, but is the encryption key and iv getting reused? If so, it's usually quite unsafe to reuse IVs (but consult a cryptographer, YMMV). Feels weird to stuff the IV with the key, it should live with the ciphertext.<p>(I only glanced at the code for a few minutes, so I could be wrong: <a href="https://github.com/higgins/privatize/blob/0.1.1/index.js#L73" rel="nofollow">https://github.com/higgins/privatize/blob/0.1.1/index.js#L73</a>)
My fear of using something like this would be to accidentally mess up the format (<PRIVATE, <<PIRVATE, etc), and accidentally commit my private stuff in plaintext. Similarly, if I misconfigure my .gitattributes, I might try to use this on a file which the privatizer program doesn't even get run over.
Nice, but not new :-)<p>See Emacs/org-mode org-encrypt-entry and org-decrypt-entry, it's easy to encrypt and decrypt via GNUPG text under a heading + the benefit of org-mode outlining witch dramatically improve readability.
Yikes, do all filters do that? <a href="https://github.com/higgins/privatize/blob/0.1.1/index.js#L98" rel="nofollow">https://github.com/higgins/privatize/blob/0.1.1/index.js#L98</a><p>Also, it's 2022 and I still have to remind people not to commit binary assets into git repos, as the repo will grow without bound: <a href="https://github.com/higgins/privatize/tree/main/release" rel="nofollow">https://github.com/higgins/privatize/tree/main/release</a><p>That's the very problem that GitHub Releases were designed to address, and has the extra awesome benefit of using (currently) AWS S3 for distribution, which is almost certainly going to be faster and place less load upon github.com than .../raw/main/release/whatever.exe<p>Also, while the Brew tap indicates your code is ISC, there is no license file in your repo: <a href="https://github.com/higgins/homebrew-privatize/blob/main/Formula/privatize.rb#L8" rel="nofollow">https://github.com/higgins/homebrew-privatize/blob/main/Form...</a>