Skip to content

Enable Hex dependency cooldown - #4971

Open
stuartc wants to merge 3 commits into
mainfrom
hex-dependency-cooldown
Open

Enable Hex dependency cooldown#4971
stuartc wants to merge 3 commits into
mainfrom
hex-dependency-cooldown

Conversation

@stuartc

@stuartc stuartc commented Jul 14, 2026

Copy link
Copy Markdown
Member

Description

This PR adds Hex 2.5.0's dependency release-age cooldown to Lightning.

Setting hex: [cooldown: "1w"] in mix.exs means Hex won't resolve to a package version until it has existed for at least a week. This mitigates the common supply-chain attack where a compromised release is pulled into builds before anyone notices and retires it — most such incidents are caught within days. Lightning only consumes dependencies (it doesn't publish), so this only affects what we pull in, never what we ship.

Day-to-day impact is basically nil: mix deps.get against an intact mix.lock bypasses the cooldown entirely, so normal builds and CI are unchanged. The cooldown only bites when resolving something new (mix deps.update, adding a dep, or deps.get after unlocking). Security fixes for a dep we're already locked to re-resolve past the cooldown automatically; a genuinely urgent fresh fix can be forced for a single command with HEX_COOLDOWN=0d mix deps.update <pkg>.

The catch: Hex older than 2.5.0 silently ignores the config, giving false confidence. So:

  • bin/bootstrap now enforces Hex >= 2.5.0 for local dev, auto-upgrading and failing fast if it can't.
  • CI/Docker already installs the latest Hex via mix local.hex --force, so it's covered.

Validation steps

  1. On a machine with Hex < 2.5.0, run bin/bootstrap and confirm it upgrades Hex and reports >= 2.5.0.
  2. With Hex >= 2.5.0, run mix deps.get against the committed mix.lock and confirm it resolves unchanged (cooldown does not bite locked versions).
  3. Run mix hex.outdated and confirm any versions inside the 1-week window are annotated (cooldown).

Additional notes for the reviewer

  1. Value chosen is 1w — covers all-but-one of the analysed supply-chain incidents while costing us almost nothing for an app that doesn't ship on every dependency bump.
  2. ensure_hex_version in bin/bootstrap.d/common.sh uses sort -V so it treats e.g. 2.10 as newer than 2.5.

AI Usage

Please disclose whether you've used AI anywhere in this PR (it's cool, we just
want to know!):

  • I have used Claude Code
  • I have used another model
  • I have not used AI

You can read more details in our
Responsible AI Policy

Pre-submission checklist

  • I have performed an AI review of my code (we recommend using /review
    with Claude Code)
  • I have implemented and tested all related authorization policies.
    (e.g., :owner, :admin, :editor, :viewer)
  • I have updated the changelog.
  • I have ticked a box in "AI usage" in this PR

Adds hex: [cooldown: "1w"] to mix.exs so newly-resolved dependency
versions must have existed for at least a week before Hex will pull
them in, mitigating supply-chain attacks that get caught and retired
within days. Normal builds against an intact mix.lock are unaffected.

Older Hex silently ignores the cooldown config, so bin/bootstrap now
enforces Hex >= 2.5.0, auto-upgrading and failing fast if it can't.
@github-project-automation github-project-automation Bot moved this to New Issues in Core Jul 14, 2026
@stuartc
stuartc marked this pull request as ready for review July 14, 2026 18:47
@stuartc
stuartc requested a review from elias-ba July 14, 2026 18:47
@github-actions

Copy link
Copy Markdown

Security Review ✅

  • S0 (project scoping): N/A — changes only touch mix.exs, bin/bootstrap.d/common.sh, and CHANGELOG.md; no queries or web-layer entrypoints are added or modified.
  • S1 (authorization): N/A — no new controllers, LiveView events, or channel handlers introduced.
  • S2 (audit trail): N/A — no writes to project or instance configuration resources; the Hex cooldown config is a build-time supply-chain hardening, not a runtime config-resource change.

@elias-ba elias-ba left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @stuartc I followed the validation steps and it worked as expected. Nice one man 👏🏽

Fixes a pre-existing Credo --strict refactoring finding that was
failing the lint CI job.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: New Issues

Development

Successfully merging this pull request may close these issues.

2 participants