cursive

Issues at: https://git.io/cursive-issues
2020-08-17T08:47:01.091200Z

Is there any way to customize the indentation of host interop forms like this? I’d like them all to be “indent”, otherwise when doing interop, forms tend to grow far to the right

cfleming 2020-08-18T23:38:04.112700Z

Hmm, no, there isn’t. Would you like this for all interop forms across the board, or for specific calls?

2020-08-24T09:46:24.012400Z

I’d do it across the board

reefersleep 2020-08-17T14:57:30.097800Z

I’m experimenting with getting a single source of truth for env vars for my Clojure project. Struggling with keeping secrets secret 🙂 Using the an .env file for env vars, EnvFile for loading that file into my Cursive project, and direnv for automatically loading in the .env file via a .envrc proxy whenever I cd into my project in the terminal, I can get most of the way; the .env file is a single source of truth for both Cursive and the terminal. However, I’d like to avoid storing secrets directly in my .env file, as I might accidentally commit those to the project repo. And the .env file is pretty much just a key-value store, so I can’t do scripting in it like pull-this-key-from-my-secrets-store (where secrets-store is pass, or lastpass, or (on mac) security or what have you).

reefersleep 2020-08-17T14:57:52.098100Z

Anyone know of a good solution for what I’m talking about?

reefersleep 2020-08-17T15:05:03.099Z

Perhaps it’s really simple and readily available, like running a .sh script just before starting my REPL or whatever.

kenny 2020-08-17T15:17:05.099500Z

> I might accidentally commit those to the project repo @reefersleep Sounds like you should gitignore that file.

reefersleep 2020-08-18T12:19:39.107900Z

Thanks a bunch @rutledgepaulv and @jd537! Lots of reading material 🙂

reefersleep 2020-08-17T15:23:39.099600Z

That’s one solution, but I feel it isn’t strong enough. I’d like to keep secrets completely out of the lexical scope of the project.

reefersleep 2020-08-17T15:24:46.099800Z

If I keep them in something like pass, they’ll be encrypted as well, not available in plaintext.

alexmiller 2020-08-17T15:56:11.100Z

https://github.com/awslabs/git-secrets

reefersleep 2020-08-17T16:06:00.100300Z

Cheers both @alexmiller and @kenny. I feel that both utilising .gitignore and git-secrets are additions that one can make to prevent leakage of secrets - and there’s nothing against using these things in the project while also keeping your secrets in an encrypted store.

reefersleep 2020-08-17T16:06:15.100500Z

I just want to be able to get them out of the store and into IntelliJ somehow 🙂

jdhollis 2020-08-17T17:21:19.100800Z

Not necessarily intended for local development (though there’s nothing preventing it): https://www.vaultproject.io

jdhollis 2020-08-17T17:24:53.101100Z

Rails has a more file-oriented approach: https://edgeguides.rubyonrails.org/security.html#environmental-security

jdhollis 2020-08-17T17:25:06.101400Z

But you’ll still need to store the key somewhere.

rutledgepaulv 2020-08-17T23:31:15.101800Z

https://github.com/mozilla/sops is one way of keeping secrets in your git repo but secure. I've used this so I can manage secrets "in-band" with the rest of my changes, then decrypt them on the deploy agent and push them to wherever they need to go (like a k8s secret). I use AWS KMS keys so the key is nowhere on my machine (just some temporary credentials for AWS that expire every few hours)

rutledgepaulv 2020-08-17T23:34:48.102200Z

.gitattributes filters for check-in and check-out are useful too. I've wired those up with sops (above) so that locally my file always appears plaintext but when I check it into git it gets encrypted automatically so there's never a plaintext version in the remote. I was initially inspired by https://oteemo.com/2019/06/20/hashicorp-vault-is-overhyped-and-mozilla-sops-with-kms-and-git-is-massively-underrated/