Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Where .env Went Wrong

secretspec.dev

Post reply on HN
Print view View original

71–77 of 77 posts

Re: Where .env Went Wrong

#71

Post by devmor »

chis wrote: post #42
devmor wrote: post #36

Earlier quoted context omitted.

I’m not saying whether I think you’re right or wrong, but AI text detectors don’t work and never will.

This has been pretty well studied. Pangram is about as good at an expert human with a 98% detection rate and https://arxiv.org/pdf/2501.15654

I'm open to being convinced, but the study you've linked me is limited specifically to professionally written, proofread journalism from 8 publications over a span of a little over a single year.

It's not exactly a wide breadth of varied text for such an all-encompassing task.

Re: Where .env Went Wrong

#72

Post by chis »

devmor wrote: post #71
chis wrote: post #42

Earlier quoted context omitted.

This has been pretty well studied. Pangram is about as good at an expert human with a 98% detection rate and https://arxiv.org/pdf/2501.15654

I'm open to being convinced, but the study you've linked me is limited specifically to professionally written, proofread journalism from 8 publications over a span of a little over a single year. It's not exactly a wide breadth of varied text for such an all-encompassing task.

https://www.pangram.com/blog/third-party-pangram-evals

You can also just try it yourself I guess really what convinced me was how it perfectly agrees with my own judgement.

Re: Where .env Went Wrong

#73

Post by jt2190 »

throw-the-towel wrote: post #65
e12e wrote: post #52

Earlier quoted context omitted.

Maybe. How does the application unify different environment variables? Those inherited by the shell, those read from .profile, those set in the process that start the application (be that ./run.sh, a nodejs script, systemd etc...).

Why would it want to? I'd say what you're asking for is actually a code smell. An app should not have a bazillion interlocking ways to be configured, unless there's a strong reason for this!

> Why would it want to?

Because well behaved applications play nice with their host system.

I have a strong suspicion that you’re thinking about application configuration, not environment configuration.

Re: Where .env Went Wrong

#74

Post by devmor »

chis wrote: post #72
devmor wrote: post #71

Earlier quoted context omitted.

I'm open to being convinced, but the study you've linked me is limited specifically to professionally written, proofread journalism from 8 publications over a span of a little over a single year. It's not exactly a wide breadth of varied text for such an all-encompassing task.

https://www.pangram.com/blog/third-party-pangram-evals You can also just try it yourself I guess really what convinced me was how it perfectly agrees with my own judgement.

The primary reason I am not convinced is because it (and several other tools) frequently classify my own writing as AI-generated. Especially my technical writeups.

Now, I could just assume I'm an outlier within that small false-positive rate. But I find it far more likely that the efficacy of these tools is much lower than advertised and they rely on confirmation bias.

Re: Where .env Went Wrong

#76

Post by ciupicri »

jerf wrote: post #23
KevinMS wrote: post #22

> Where .env Went Wrong start with making it a dot file. Why would you want to hide the fact your app was using loaded environment variables?

I hate that it's hidden too. There's no reason for it to be hidden and arguably some reason for it not to be hidden. I did discover one reason for it not to be just "env" though, which surprised me, which is that "source env" will yield "bash: source: /usr/bin/env: cannot execute binary file". I did not expect the source command to use the $PATH to resolve the filename. Probably some minor security issues that can re…

From the Bash manual [1]:

    . [-p path] filename [arguments]
> If filename does not contain a slash, . searches for it. If -p is supplied, . treats path as a colon-separated list of directories in which to find filename; otherwise, . uses the directories in PATH to find filename. filename does not need to be executable. When Bash is not in POSIX mode, it searches the current directory if filename is not found in $PATH, but does not search the current directory if -p is supplied. If the sourcepath option (see The Shopt Builtin) is turned off, . does not search PATH.

From "The Open Group Base Specifications Issue 8 - IEEE Std 1003.1-2024" [2]:

    . file
> If file does not contain a , the shell shall use the search path specified by PATH to find the directory containing file. Unlike normal command search, however, the file searched for by the dot utility need not be executable.

So it seems that it's not something Bash specific.

[1]: https://www.gnu.org/software/bash/manual/html_node/Bourne-Sh... )

[2]: https://pubs.opengroup.org/onlinepubs/9799919799/utilities/V...

Re: Where .env Went Wrong

#77

Post by worksonmine »

wonger_ wrote: post #54

I'm working with .env and secrets and teamwide configs for the first time, trying to understand solutions from first principles. Are these valid observations so far? - .env is the simplest and oldest / most boring solution. Secrets are passed to teammates by DM? - .env.example seems like a nice home for documentation about secrets - but I'd rather avoid writing sensitive credentials at all -- instead, teams can use a…

> - .env is the simplest and oldest / most boring solution. Secrets are passed to teammates by DM?

I don't see a reason to ever pass them. Sensitive production values should never be accessible to everyone, and for development the team should be able to create them themselves.

I usually keep very stupid values in .env.example, with the instructions to `cp .env.example .env`. In development it doesn't matter if the password is "password". In production the privileged admin sets up actual values.

> - non-sensitive environment variables also need a home. I don't like the idea of cluttering the project with a .env.local or worse like .env.development.local

`cp .env.example .env` and the application uses .env just like in production, only with dummy values.

Post reply on HN