search

dotenv-org / godotenvvault

Load environment variables from encrypted .env.vault files
https://www.dotenv.org/docs/languages/go
MIT License
15 stars 1 forks source link

Pin down full API behavior #2

Closed ian-ross closed 1 year ago

ian-ross commented 1 year ago

I've written and pushed a first pass at the full godotenv API using encrypted .env.vault files. (As of right now, I've not done the autoload part yet, but I might do it before you read this... I've also not updated the README, although I will also do that as soon as I've finished this ticket.)

As expected, there is a lot of copying from the original godotenv package. I've tried to highlight this as clearly as possible by including the license from the godotenv package in a large comment at the top of the main source file here.

There are a couple of questions about how you'd like some aspects of the API to work:

  1. The Load, Overload and Read functions all allow you to pass multiple filenames. I'm not sure that this makes sense in the context of having a single .env.vault file. What do you think? Disallowing it would either mean changing the API (which I understand isn't something you want to do), or just raising an error if multiple files are passed to any of those functions. Alternatively, we can leave things just as they are, where multiple files are processed properly, getting decrypted one by one using whatever keys are available in the DOTENV_KEY environment variable. What would you like to do here?
  2. The godotenv package has a couple of functions for serializing environment maps (Write and Marshal). I've just left those as proxies to the godotenv versions of the functions for now, since they might be useful, even if users can't write encrypted .env.vault files with them. Do you have any other preference for how those things should work? I see that none of the other APIs provide the capability to write and encrypt .env.vault files, so maybe leaving this as it is is OK?
  3. I've only included a couple of tests, to do with key and vault parsing. Let me know if you want more tests, although I think most things should be covered by the test suite from the original godotenv package.

We can either have a quick review call tomorrow to cover these things, or you can just respond here!

Just FYI: total time spent so far is 3 hours.

ian-ross commented 1 year ago

OK, I've done the autoload and command line things now as well. The current version is v0.3.0.

I've also started updating the README, but there are a couple of things we should probably talk about:

  1. I've added some words to the "Usage" section to cover creating an .env.vault file and using it. I don't know if you want anything added beyond what's there.
  2. The godotenv package supports all kinds of variants for environment files (comments, YAML, etc.), and this is documented in the README. I don't know how any of that will interact with dotenv-vault. I use the original godotenv parser, so as long as the encryption of .env to .env.vault is agnostic with respect to what's in the original .env file, it should all work fine. If the dotenv-vault encryption code actually parses the .env file in some way, then it will have trouble with the godotenv variant formats. Do you have any thoughts about that?
  3. There's a section called "Precedence & Conventions" in the README about the behavior when using multiple environment files. I don't know if you want to support that, or if you have anything in particular you want to say there.

(In all of these cases, an acceptable answer for me is: "Do it like the existing Ruby/Python/Node.js code in the closest corresponding idiomatic Go way of doing things.")

I think that's all for now. I'll quickly put together an example for the env-vault-examples repository, then I think we'll be in a position for a first review before deciding what should be done to turn this into production code. (I think that might just be documentation and CI setup, since there's not really any extra tool setup needed for Go.)

ian-ross commented 1 year ago

One last thing: I've created a Go encryption/decryption example here.

motdotla commented 1 year ago
  1. Allow them to still pass multiple files for the purpose of their standard/traditional .env loading, but if a DOTENV_KEY is set, then ignore that multiple file load and load straight from the .env.vault file
  2. Yes, leaving that is ok. These libraries (including the one you're building) only do decryption. The encryption is left to the cli https://github.com/dotenv-org/dotenv-vault (right now distributed over npm but in the future also distributed as a binary)
  3. I agree. Just a few tests is fine.

Second section:

  1. That's great! I'll add to it overtime but much appreciated!
  2. Similar to #1 above, those variants will only be in context of the standard/traditional .env loading. If they've set a DOTENV_KEY then they are using a .env.vault file and that's the only format that will be supported.
  3. We only want to support this when it comes to the traditional loading, but when it comes to the .env.vault file it isn't relevant.

One last thing: I've created a Go encryption/decryption example

Awesome.

Great stuff here, Ian. I will try and get to it this evening - to test it out!

ian-ross commented 1 year ago

Thanks — those are useful answers. I'll bring the Go code into line with all that tomorrow.

ian-ross commented 1 year ago

@motdotla I've made the changes for this and the other key extraction issue (#1). I think this is now substantially complete and ready for review before I release a v1.0.0 version! Let me know if there's anything missing from your perspective.