Feature Idea: Configure minimum age for dependencies

[daniellionel01]

Due to recent supply chain attacks in the npm package ecosystem, Bun.js introduced a minimum release age for dependencies: https://bun.com/docs/pm/cli/install#minimum-release-age

I was also inspired by this article on the same concept, but they call it "dependency cooldown": https://blog.yossarian.net/2025/11/21/We-should-all-be-using-dependency-cooldowns

How this would behave in a concrete example:

• Package wibble has v1.1 and v1.2 available. The latest has been released 2 days ago.
• I have the minimum age for dependencies in gleam configured as 7 days.
• I run gleam add wibble and it will install v1.1.
• I run gleam update 2 days later, it will not update and stay on v1.1, since it has been 4 days since v1.2 was released.
• I run gleam update 3 days later, it will now update to v1.2.

As for the implementation this could be configurable in gleam.toml. Alternatively we could show the time since a new package version has been out when running the new gleam deps outdated command.

[lpil]

I asked Jonatan Männchen of the EEF for his perspective on this as a domain expert, here's what he had to say:

From a strict security perspective we have 2 arguments:

• If you delay updates, users might miss important security fixes
• If you immediately update everything, you might get malicious packages that would've been identified and pulled if you waited.

From a non security perspective:

• As a maintainer I already get lots of issues for things that are already fixed. If my users start to intentionally delay updates, that situation will probably get worse.

I'm not a huge fan of the whole feature myself. I understand why people want it, but I don't think it's a solution for their problems.

There's a lot of people arguing around the article mentioned in the issue, it trended on HN for a while: https://news.ycombinator.com/item?id=46005111

There was also a lot of arguing in other forums such as the OpenSSF Slack and people do not agree on this topic. So I guess any direction on this is fine right now.

If this were implemented, I would recommend taking some precautions:

• Disregard Cooldown if the currently locked dependency is retired on Hex
• Disregard Cooldown if the newest dependency out of the cooldown period is retired on Hex
• In the future: Same for vulnerable status as for reitred status (TBD in detail)

Also we would really need to reinforce that it is important that maintainers follow a good retirement for broken releases and disclose vulnerabilities workflow. Otherwise they might fix the issue and half of their users just don't update in a meaningful time span.

Also I think this feature primarily should target auto-updating tools such as Dependabot / Renovate etc. If you're manually updating, I would leave all that up to the user.

I think these are very good insights. It's not clear to me this is the right feature to implement as-is in Gleam.

[maennchen]

The article has one big assumption which currently does not hold in my opinion:

Meanwhile, the aforementioned vendors are scanning public indices as well as customer repositories for signs of compromise, and provide alerts upstream (e.g. to PyPI).

I have never heard of anybody doing this in our ecosystem. And while we have it on the Ægis Initiative roadmap (https://security.erlef.org/aegis/roadmap/hex-vulnerability-handling.html), the scanning will most likely not be implemented very soon.

Therefore the only place where we figure out that problem is if users or maintainers raise an issue.

With a dependency cooldown by default, we only delay the issue. And with an optional cooldown, we just shift the risk to the users that don't use a cooldown.

I think our focus would be spent much better on actually implementing malicious package scanning.