4 ms·

> dotenv is unmaintained. How much maintenance could you possibly need to load secrets from .env into the environment.

iammrpayments 1y ago
I find hilarious when people judge the quality of a repository by how many commits it has, as if 10.000 commits means the code is better.
shepmaster 1y ago
I agree with your general point, but for this specific functionality, I’ll point out that setting environment variables of the current process is unsafe. It took us a long time to realize it so the function wasn’t actually marked as unsafe until the Rust 2024 edition. What this means in practice is that the call to invoke dotenv should also be marked as unsafe so that the invoker can ensure safety by placing it at the right place. If no one is maintaining the crate, that won’t happen and someone might try to load environment variables at a bad time.
- andy_xor_andrew 1y ago
  ok, I'm hooked - how is setting an env var in the current process unsafe? My gut says it's not unsafe in a memory-ownership sense, but rather in a race condition sense? whatever the issue is, "setting an env var is unsafe" is so interesting to me that I'm now craving a blog post explaining this
  - Orangeair 1y ago
    It's a long standing bug, setenv and unsetenv are not thread-safe https://www.evanjones.ca/setenv-is-not-thread-safe.html https://www.evanjones.ca/setenv-is-not-thread-safe.html
    - robertlagrant 1y ago
      I honestly think using setenv is just a terrible idea.
      - ak_111 1y ago
        can you elaborate what is the simpelist alternative?
        darthwalsh 1y ago
        Simple, you don't set any env vars after starting new threads
  - estebank 1y ago
    https://doc.rust-lang.org/std/env/fn.set_var.html#safety https://doc.rust-lang.org/std/env/fn.set_var.html#safety
csomar 1y ago
On the other hand loading .env from the environment is critical (since you are usually passing secrets through .env). I wouldn't want to maintain that myself and not share it with a xxK other projects in case there is a vulnerability.
- dathinab 1y ago
  the issue is loading and setting env (which is the default for dot env libraries) _is fundamentally unsound thanks to unix/posix_ no way around that hence why set env wasn't marked as unsafe _even through it not being fully save being known since extremely early rust days maybe even 1.0_ it not being unsafe wasn't a oversight but a known to not be fully sound design decision which had been revisited and changed in recently
prophesi 1y ago
The maintainers themselves give this warning in the repo's README, so even if it were maintained, it still wouldn't be production ready. > Achtung! This is a v0.* version! Expect bugs and issues all around. Submitting pull requests and issues is highly encouraged! https://github.com/dotenv-rs/dotenv https://github.com/dotenv-rs/dotenv
- 0cf8612b2e1e 1y ago
  That is an escape hatch that is seemingly used everywhere. Nobody wants to release a 1.0 with backwards compatibility guarantees. ZeroVer https://0ver.org/ https://0ver.org/
- im3w1l 1y ago
  Ironically a project that hasn't been changed in a while "unmaintained" is a good candidate for bumping to v1, while a project with new breaking commits every day is a bad candidate.
dathinab 1y ago
after testing that that very small fixed functionality you provide is correct non small "completed" well tested libraries being flagged as security issues due to being unmaintained seem to be starting to become an issue
superkuh 1y ago
Rust dev culture is allergic to any code that hasn't changed significantly in the last 3 months. Too easy, too stable.

I find hilarious when people judge the quality of a repository by how many commits it has, as if 10.000 commits means the code is better.

shepmaster 1y ago

I agree with your general point, but for this specific functionality, I’ll point out that setting environment variables of the current process is unsafe. It took us a long time to realize it so the function wasn’t actually marked as unsafe until the Rust 2024 edition. What this means in practice is that the call to invoke dotenv should also be marked as unsafe so that the invoker can ensure safety by placing it at the right place. If no one is maintaining the crate, that won’t happen and someone might try to load environment variables at a bad time.

andy_xor_andrew 1y ago
ok, I'm hooked - how is setting an env var in the current process unsafe? My gut says it's not unsafe in a memory-ownership sense, but rather in a race condition sense? whatever the issue is, "setting an env var is unsafe" is so interesting to me that I'm now craving a blog post explaining this
- Orangeair 1y ago
  It's a long standing bug, setenv and unsetenv are not thread-safe https://www.evanjones.ca/setenv-is-not-thread-safe.html https://www.evanjones.ca/setenv-is-not-thread-safe.html
  - robertlagrant 1y ago
    I honestly think using setenv is just a terrible idea.
    - ak_111 1y ago
      can you elaborate what is the simpelist alternative?
      - darthwalsh 1y ago
        Simple, you don't set any env vars after starting new threads
- estebank 1y ago
  https://doc.rust-lang.org/std/env/fn.set_var.html#safety https://doc.rust-lang.org/std/env/fn.set_var.html#safety

csomar 1y ago

On the other hand loading .env from the environment is critical (since you are usually passing secrets through .env). I wouldn't want to maintain that myself and not share it with a xxK other projects in case there is a vulnerability.

dathinab 1y ago
the issue is loading and setting env (which is the default for dot env libraries) _is fundamentally unsound thanks to unix/posix_ no way around that hence why set env wasn't marked as unsafe _even through it not being fully save being known since extremely early rust days maybe even 1.0_ it not being unsafe wasn't a oversight but a known to not be fully sound design decision which had been revisited and changed in recently

prophesi 1y ago

The maintainers themselves give this warning in the repo's README, so even if it were maintained, it still wouldn't be production ready. > Achtung! This is a v0.* version! Expect bugs and issues all around. Submitting pull requests and issues is highly encouraged! https://github.com/dotenv-rs/dotenv https://github.com/dotenv-rs/dotenv

0cf8612b2e1e 1y ago
That is an escape hatch that is seemingly used everywhere. Nobody wants to release a 1.0 with backwards compatibility guarantees. ZeroVer https://0ver.org/ https://0ver.org/
im3w1l 1y ago
Ironically a project that hasn't been changed in a while "unmaintained" is a good candidate for bumping to v1, while a project with new breaking commits every day is a bad candidate.

dathinab 1y ago

after testing that that very small fixed functionality you provide is correct non small "completed" well tested libraries being flagged as security issues due to being unmaintained seem to be starting to become an issue

superkuh 1y ago

Rust dev culture is allergic to any code that hasn't changed significantly in the last 3 months. Too easy, too stable.