Enable Trusted publishing

[Specy]

Hi! Dotenv has to be one of the most important packages in the npm ecosystem.
In those last months there has been a lot of supply chain attacks targeting packages of all sizes, many people are moving to publishing packages on NPM through trusted publishing (CI/CD on github workflows etc...) which reduces the risk of potential theft of npm access tokens and makes it more trustworthy to install a package knowing it came from a trustable source.

This Issue is a suggestion to look into trusted publishing for dotenv, thank you!

[motdotla]

Yes, thank you and agree. Will move to this soon.

[lolusiayy]

Hi. The dotenv package is not one of the most important parts of the npm ecosystem and, in current conditions, can be considered obsolete. Its significance mainly came from limitations in older versions of Node.js, which have now been addressed by native runtime features.

In the context of the growing number of supply chain attacks targeting packages of all sizes, reducing dependencies becomes an important aspect of security. Every external library increases the potential attack surface - regardless of its popularity or reputation.

In newer versions of Node.js, the functionality provided by dotenv is already built in. There is a native method process.loadEnvFile() that allows loading environment variables without installing additional packages. As a result, dotenv becomes unnecessary, since its only use case is now covered by the standard runtime API.

For this reason, keeping this dependency is no longer technically justified in modern projects.

https://e18e.dev/docs/replacements/dotenv.html

[Specy]

@lolusiayy yes that is true, but as everything in the JavaScript environment (look at esm Vs cjs), things take literal decades of time to change, especially when it comes to something that "works" and doesn't exactly need changing other than a new better way to do it.

It will probably be a decade before dotenv stops being installed by millions every week, so at this point, it is better to secure a huge potential point of failure rather than asking everyone to migrate off of it (it won't happen)

[simonwep]

What about a new version of dotenv that logs the info that it can now be safely replaced with process.loadEnvFile() saving you a whole dependency including the risk that comes with it and what-not 🙂🎉 Or at least including it in the current stuff that's logged (about dotenvx I believe) hinting the user about a real-good alternative - I mean, we already got that and there are still so many downloads (and potential users that may not know about the new native way!).

Edit: considering the skills folder and the amount of slop on the page of dotenv promoting dotenvx I'd actually see it as security risk to still use this - since there hasn't been another contributor than @motdotla since 2020. Checking out the commit history tells all there is... holy shit. Glad I myself and my team migrated away from this.

[Specy]

@simonwep that could also be added but, the issue with dotenv is not for when people install it as a dependency. But that many packages use it under the hood as their dependency. You cannot solve that unless you ask everyone who distributes their library to do a potentially breaking change to remove automatic env loading

[lolusiayy]

And in cases like this, the package should be marked as deprecated so people can see they need to look for an alternative. The fact that the author of dotenv is greedy for views is already widely known.

[simonwep]

@Specy that's true, although I'd argue it's even more important in this case since you wouldn't even know this package is used as it's a transitive dependency. Packages are deprecated all the time, in some projects I have like 8 warnings of deprecated, transitive dependencies. It's better then nothing and will nudge the authors to upgrade it at some point - better then nothing :/

[motdotla]

Thankless work open source isn't it.

@lolusiayy --env-file would not exist without dotenv. They literally copy pasted over the full test suite without so much of a thank you. But that's the nature of open source.

The other nature of open source is that maintainers like me can pick a problem and work on it. That problem is plaintext .env files, and I will continue to do everything reasonable in my power to grow knowledge of the technology. It solves a MAJOR problem - on a similar risk-level as supply chain attacks.

The effort is working:

[lolusiayy]

@motdotla
Dotenv isn't anything sophisticated, just like your work. Most people know perfectly well what kind of person they're dealing with in your case. Those views are being inflated by bots, and you're celebrating like an idiot. 🤣

Sure, real people would be downloading an old version 8.2.0 (released 7 years ago) 1,625,974 times hahaha within a week

[Specy]

@lolusiayy the fact that old versions are being downloaded millions or times should tell you exactly why this issue was created. All those people are using old versions of the library and could theoretically be susceptible to potential supply chain attacks if dotenv was compromised.

Also, bots usually download a module only when it's updated, and usually it's around 10k downloads, not millions.

[motdotla]

People also really underestimate how much old node versions are still used in production today - because they just weren't around in the early days.

A pedantic correction:

All those people are using old versions of the library and could theoretically be susceptible to potential supply chain attacks

Those on old versions are actually LESS susceptible to supply chain attacks. I personally hardcode my dependencies to explicit versions. I've never recommended that - because there is so much value historically for patch upgrades - but given recent attacks I'm increasingly want to.

[simonwep]

I agree with @motdotla here, more people use old systems than we think - the reason why XP was supported for so long and many large companies still use MS-DOS. I can also highly recommend pinning dependencies, yet alone since not all adhere to semver.

However,

The other nature of open source is that maintainers like me can pick a problem and work on it. That problem is plaintext .env files, and I will continue to do everything reasonable in my power to grow knowledge of the technology. It solves a MAJOR problem - on a similar risk-level as supply chain attacks.

I don't get this at all, besides private projects that run on bare VPS I have never used .env files anywhere, hell, most deployments use containers and if you go with docker there's already a solution to that, that is a standard, free and well supported - docker secrets. It's the same with anything - you'll always find some people who will pick the wrong solution for a problem because they simple don't know better - but that doesn't justify the existence of said solutions.

And the "I will continue to do everything reasonable in my power to grow knowledge of the technology" tells me this 20k stars and downloads go wayyy over your head - or someones using AI for comments now... Imma head out here, this isn't worth it.

[motdotla]

I don't get this at all

Have you read my whitepaper?

https://dotenvx.com/whitepaper.pdf

Additional note: following the Vercel incident - if you were using dotenvx, you had added protection. It's far harder for attackers to exfiltrate terabytes of source code than a relatively small set of platform secrets or environment variables. At the very least, using dotenvx makes you a more difficult target compared to relying solely on platform-managed secrets.