Update dependencies:

[erikd]

Specifically rely on aeson >= 2.3.0.0 to avoid a DoS vulnerability in earlier versions:

  https://haskell.github.io/security-advisories/advisory/HSEC-2026-0007.html

Pre-submit checklist:

• Branch
  • Tests are provided (if possible)
  • Commit sequence broadly makes sense
  • Key commits have useful messages
  • Changelog fragments have been written (if appropriate)
  • Relevant tickets are mentioned in commit messages
  • Formatting, PNG optimization, etc. are updated
• PR
  • (For external contributions) Corresponding issue exists and is linked in the description
  • Targeting master unless this is a cherry-pick backport
  • Self-reviewed the diff
  • Useful pull request description
  • Reviewer requested

[erikd]

More fixes needed

[Unisay]

Thanks for the quick turnaround. The build side is solid: the plan resolves and Hydra is green on Linux and Darwin against aeson 2.3.0.0, so CI is off the vulnerable aeson.

One thing to sort out before merge. The aeson >= 2.3.0.0 constraint lives only in cabal.project, which isn't shipped to CHaP/Hackage. The libraries that depend on aeson still admit vulnerable versions: plutus-tx has aeson >=2.2, and plutus-core / plutus-ledger-api have no bound at all, so anyone building those from CHaP can still resolve aeson < 2.3.0.0. For the fix to reach downstream consumers per HSEC-2026-0007, the >= 2.3.0.0 lower bound should also go into the build-depends of the published aeson-using packages: plutus-tx, plutus-core and plutus-ledger-api are the ones consumed downstream, with plutus-conformance, cardano-constitution and plutus-benchmark worth doing for consistency.

Two smaller things I hit while checking the solver.

The four aeson allow-newer lines this PR adds (aeson-pretty, deriving-aeson, microstache, monoidal-containers against aeson) are already redundant against the new index-state. I removed each and re-solved cabal build all --dry-run under GHC 9.6 and 9.12: the plan resolves without them, and aeson still pins to 2.3.0.0 via the constraint. The resolved versions already admit aeson 2.3, so the four lines can go.

The new QuickCheck >=2.18 bound is applied unevenly. withNumTests only exists from QuickCheck 2.18, but several components that call it don't carry the bound: untyped-plutus-core-testlib, plutus-ir-test, plutus-ledger-api-testlib and plutus-ledger-api-plugin-test. It builds in-project because cabal pins one QuickCheck for the whole solve, but a standalone build of either public testlib could resolve an older QuickCheck and fail. Adding QuickCheck >=2.18 there, especially the two testlibs, makes the bounds match usage.

Nits: the title has a typo ("dependencues"), and the doc/docusaurus path change is unrelated to the bump if you'd rather keep this PR focused.

Specifics are in the inline comments.

[Unisay]

cabal.project constraints aren't shipped to CHaP/Hackage, so this line only protects this repo's own build plan. The aeson-consuming libraries still admit vulnerable versions: plutus-tx has aeson >=2.2 (plutus-tx.cabal:139) and plutus-core / plutus-ledger-api are unbounded (plutus-core.cabal:316,401,945,960; plutus-ledger-api.cabal:110,142,339). To protect downstream consumers per HSEC-2026-0007, the >= 2.3.0.0 lower bound should also be added to the build-depends of those packages (plutus-tx, plutus-core, plutus-ledger-api, and the other direct aeson users plutus-conformance, cardano-constitution, plutus-benchmark).

[erikd]

I have removed the aeson constraint from cabal.project and added them elsewhere.

[Unisay]

These four aeson relaxations are redundant against this PR's index-state. I removed each and re-solved cabal build all --dry-run under GHC 9.6 and 9.12: the plan resolves without them, and aeson still pins to 2.3.0.0 (the constraints: block does that, not these allow-newer lines). The resolved versions already admit aeson 2.3.0.0: aeson-pretty 0.8.10, deriving-aeson 0.2.10, microstache 1.0.3.1, monoidal-containers 0.6.7.0. Dropping these keeps the block from carrying a relaxation the shipped snapshot doesn't need. (The pre-existing inline-r:* / turtle:* entries are likewise redundant, but pruning those is out of scope for a security bump.)

[erikd]

😕

If I remove the aeson-pretty:aeson with ghc-9.12.4 I get this:

> cabal build all --dry-run
Resolving dependencies...
Error: [Cabal-7107]
Could not resolve dependencies:
[__0] trying: plutus-benchmark-0.1.0.0 (user goal)
[__1] trying: aeson-2.3.0.0 (dependency of plutus-benchmark)
[__2] trying: plutus-core-1.65.0.0 (user goal)
[__3] rejecting: plutus-core:-with-inline-r (constraint from config file, command line flag, or user target requires opposite flag selection)
[__3] trying: plutus-core:+with-inline-r
[__4] next goal: aeson-pretty (dependency of plutus-core +with-inline-r)
[__4] rejecting: aeson-pretty-0.8.10 (conflict: aeson==2.3.0.0, aeson-pretty => aeson^>=1.1 || ^>=1.2 || ^>=1.3 || ^>=1.4 || ^>=1.5 || ^>=2.0 || ^>=2.1 || ^>=2.2)

[Unisay]

This >=2.18 bound is correct, but it's applied inconsistently with actual usage. withNumTests is QuickCheck-2.18-only, so every component calling it needs the bound, yet these don't have it: untyped-plutus-core-testlib (8 files, incl. the hiding (Some) change), plutus-ir-test (21 files), plutus-ledger-api-testlib (plutus-ledger-api.cabal:198, 2 files), and plutus-ledger-api-plugin-test (plutus-tx-plugin.cabal:303, 3 files). It builds in-project because cabal pins one QuickCheck globally; a standalone build of either public testlib could resolve QuickCheck <2.18 and fail. Suggest adding QuickCheck >=2.18 to those, priority on the two testlibs. (Conversely index-envs-test got the bound but doesn't use withNumTests.)

[erikd]

@lehins was very much against the QuickCheck >=2.18 constraint because of the downstream ramifications. He suggested we add this module https://github.com/IntersectMBO/cardano-base/blob/master/cardano-base/testlib/Test/Cardano/Base/QuickCheck.hs and then import that module qualified as say BaseQC and use BaseQC.withNumTests.

Will try to come up with a similar solution here.

[lehins]

Yes, we cannot force everyone to switch to newest version of QuickCheck, because there can be dependencies of downstream components that are still not compatible with the latest version of QuickCheck.
We had exact same problem last year, which resulted in allow-newer for QuickCheck seeping into CHaP, because we were not able to make release of packages otherwise.
In other words, we should never add a lower bound on a recently released version of very popular package, because it takes quite a bit of time for community to catch up with relaxing bounds.

Three approaches we can take at this point in plutus:

• Make plutus depend on cardano-base and use the shim that was added in QuickCheck compatibility shim cardano-base#652 (there are other goodies in that package that plutus could benefit from (eg. efficient generation of ByteString with genByteString and more to come)
• Wire in QuickCheck shim into plutus, if dependency on cardano-base is undesired for some reason.
• Not update to latest QuickCheck for now, and instead add an upper bound < 2.18

[lehins]

2.3 and 2.3.0.0 are not the same bounds, according to Cabal resolver. There is a slight difference. Also, it is best to have consistent bounds in all places

Suggested change

	, aeson >=2.3.0.0
	, aeson >=2.3

[erikd]

I can understand the why this might be desirable for consistency reasons, but shouldn't the cabal solver treat them the same?

[lehins]

You'd this so, but that is not the case:

ghci> import Distribution.Types.Version
ghci> mkVersion [0,3,0,0] > mkVersion [0,3]
True

So, if you do foo >= 0.3.0.0 and the actual package's version is foo-0.3 or foo-0.3.0, then it will not be picked up.

[lehins]

That is why it is alway safer to omit trailing zeros in cabal bounds, because foo >= 0.3, will pickup all of these: foo-0.3, foo-0.3.0, foo-0.3.0.0