Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2020-08-17

Channels

#cursive
<
2020-08-17
>
mhuebert08:08:01

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

cfleming23:08:04

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

mhuebert09:08:24

I’d do it across the board

reefersleep14:08:30

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).

reefersleep14:08:52

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

reefersleep15:08:03

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

kenny15:08:05

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

reefersleep15:08:39

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.

reefersleep15:08:46

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

reefersleep16:08:00

Cheers both @U064X3EF3 and @U083D6HK9. 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.

reefersleep16:08:15

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

jdhollis17:08:19

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

jdhollis17:08:06

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

rutledgepaulv23:08:15

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)

rutledgepaulv23:08:48

.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/

reefersleep12:08:39

Thanks a bunch @U5RCSJ6BB and @U7JK67T3N! Lots of reading material 🙂