[eng-cve-remediation-app]

This PR contains the following updates:

Package	Type	Update	Change
org.clojure:clojure	dependencies	security	1.8.0 → 1.11.2

Dependency path

• puppetlabs:i18n → org.clojure:clojure

By merging this PR, the below vulnerabilities will be automatically resolved:

Severity	CVSS Score	Vulnerability
High	7.5	CVE-2024-22871
Critical	9.8	CVE-2017-20189

---

Bump strategy

org.clojure:clojure 1.8.0 → 1.11.2

Direct dependency, declared inline in project.clj ([org.clojure/clojure "1.8.0"]).
Although Mend's dependency path shows it resolving via puppetlabs/i18n,
the project itself also pins it directly, so this was a direct-inline bump:
the version string was replaced with 1.11.2 (the higher of the two CVE
fix versions, CVE-2024-22871 and CVE-2017-20189).

No cohort siblings — no other dependency in project.clj is pinned at
1.8.0 sharing a group/artifact token with clojure.

Verified with lein deps :tree: resolves cleanly, pulling in
org.clojure/clojure 1.11.2 plus its new transitive deps
(core.specs.alpha, spec.alpha), no conflicts.

No changelog file exists at the repo root, so none was updated.

[eng-cve-remediation-app]

🔎 Dependency bump analysis

Breaking changes: false · Reachability: no

---

Impact report

Changelog Impact Report — org.clojure/clojure 1.8.0 → 1.11.2

Summary

This PR bumps the direct dependency org.clojure/clojure from 1.8.0 to
1.11.2 in project.clj (ticket PE-48003) to remediate two CVEs pulled in
transitively via puppetlabs/i18n:

CVE	Severity	Fixed in
CVE-2017-20189	Critical (9.8)	1.9.0
CVE-2024-22871	High (7.5)	1.11.2

Verdict: not breaking. I reviewed every intermediate release (1.9.0,
1.10.0–1.10.3, 1.11.0–1.11.2). Clojure maintains very strong backward
compatibility as a stated project goal, and the handful of documented
compatibility notes in that span (spec's pre-1.9.0-release namespace, the
Java 8 floor, the clojure.xml/parse XXE hardening) don't touch anything
this codebase (puppetlabs/stockpile) actually uses. No code changes are
required for this bump.

Upstream changes (1.8.0 → 1.11.2)

Source: Clojure's own changes.md "Potential compatibility issues" notes
and release announcements (release notes file provided by the workflow was
empty, so this is from upstream GitHub/clojure.org — see References).

Version	Change	Breaking?
1.9.0	Introduced clojure.spec.alpha / clojure.spec.gen.alpha (spec). Namespace was renamed from the pre-release clojure.spec to clojure.spec.alpha before 1.9.0 shipped, so there's no "1.8 behavior" to break here — spec didn't exist in 1.8.	No (new, additive)
1.9.0	CVE-2017-20189 fix: disabled serialization of Clojure proxy classes to close a gadget-chain RCE on deserialization of untrusted data.	No — removes an exploitable capability, doesn't change the documented public API
1.9.0	spec predicate renames (long?→int?, etc.) happened pre-1.9.0-release, during alpha	N/A (never shipped under old names)
1.10.0	Minimum Java version raised to Java 8 (dropped Java 6/7 support); 1.10 compiles to Java 8 bytecode.	Flagged per the task's runtime-bump rule, but only matters if a consumer runs on Java 6/7
1.10.0–1.10.3	Improved error messages/reporting at the REPL/compiler level (better spec-based error explanations), prepl, socket server docs.	No — tooling/dev-experience, not API-breaking
1.11.0	Added update-keys, update-vals, parse-long, parse-boolean, abs, and kwargs-style (& map-destructured) function signatures.	No (additive)
1.11.0	Security hardening: clojure.xml/parse now disables external-entity (XXE) processing by default. Callers relying on external entity resolution must explicitly pass startparse-sax.	Behavioral, but only affects callers of clojure.xml/parse
1.11.1 / 1.11.2	Patch releases. 1.11.2 is the release that fixes CVE-2024-22871 (infinite hashCode() on infinite seqs — iterate/cycle/repeat — causing a DoS when deserializing a crafted HashMap via ObjectInputStream).	No API change — fixes a missing hashCode() override

No release in this range documents removed public functions/macros, changed
function signatures on stable APIs, or changed exception types for commonly
used APIs.

How we use it

puppetlabs/stockpile (src/puppetlabs/stockpile/queue.clj,
test/puppetlabs/stockpile/queue_test.clj) uses only long-stable Clojure
surface: defprotocol/extend-protocol, defrecord, ex-info/ex-data,
with-open, atom/swap!, future/deref, loop/recur, try/catch,
and Java interop (java.nio.file.*, java.util.concurrent.atomic.AtomicLong).
It also redefines reduce locally via (:refer-clojure :exclude [reduce]) —
this is the project's own 3-arg function, unrelated to clojure.core/reduce,
and unaffected by any upstream change.

Checked explicitly against the items above:

Change	Grep result	Affected?
clojure.spec* namespaces / predicate renames	No matches in *.clj	No — spec isn't used anywhere in this repo
clojure.xml/parse (XXE change)	No matches	No — clojure.xml isn't required/imported anywhere
Infinite-seq hashCode() (CVE-2024-22871 itself)	No use of iterate/cycle/infinite repeat, and no ObjectInputStream/Java serialization of untrusted data in src/	Not exploitable here either way, but we do get the fix "for free"
Minimum Java 8	No JDK pin found in project.clj/pom.xml/Makefile; dev/java-env is a test helper that explicitly supports asserting against arbitrary JDK majors (--expect-major N), implying the project already tests on modern JDKs, not Java 6/7	No action needed

I also checked pom.xml (currently untracked per git status, likely a
stale Leiningen-generated artifact from before this bump — it still pins
org.clojure:clojure at 1.8.0). It isn't touched by bump-diff.txt, so
it's outside this PR's diff, but it will be regenerated out of sync with
project.clj if committed as-is; flagged below for awareness rather than as
a defect in the bump itself.

Action items / risks

• No code changes required. All reviewed compatibility notes between
  1.8.0 and 1.11.2 are either additive, scoped to the proxy/spec/XML
  surfaces this repo doesn't touch, or security fixes with no API shape
  change.
• No dependency-cohort issue: org.clojure/clojure is the only
  Clojure-group dependency pinned in project.clj/pom.xml (no sibling
  org.clojure/* artifacts need to move in lockstep here), so there's no
  split-family concern like a BOM/matched-set bump would have.
• Informational: if pom.xml is meant to be committed/tracked, it's
  currently stale (still shows 1.8.0) relative to the new project.clj
  pin — regenerate it (lein pom) before merging if it's going to be kept
  in version control.
• Informational: Clojure 1.10+ requires Java 8+. Nothing in this repo
  indicates a sub-Java-8 runtime is in use, so this is not expected to be a
  real-world constraint, just noting it per the runtime-bump checklist.

References

• Clojure changes.md (upstream compatibility notes, per-release)
• Clojure 1.9 release announcement
• Clojure 1.11.2 release notes
• CVE-2024-22871 advisory (GitLab)
• CVE-2017-20189 details