This is an automated email from the ASF dual-hosted git repository.
paulk-asert pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/groovy.git
The following commit(s) were added to refs/heads/master by this push:
new 293db467a9 align threat model with verification metadata settings
293db467a9 is described below
commit 293db467a927aa7b5efe2a96a1be57d12e5c24dd
Author: Paul King <[email protected]>
AuthorDate: Mon Sep 7 10:49:25 2026 +1000
align threat model with verification metadata settings
---
THREAT_MODEL.md | 1 +
gradle/verification-metadata.xml | 6 ++++++
2 files changed, 7 insertions(+)
diff --git a/THREAT_MODEL.md b/THREAT_MODEL.md
index 3454d44687..23edfa739f 100644
--- a/THREAT_MODEL.md
+++ b/THREAT_MODEL.md
@@ -702,6 +702,7 @@ vulnerabilities** unless a concrete, in-model data-boundary
crossing
| AST transforms executing code at **compile** time (local & global) | By
design; compile time is trusted — `KNOWN-NON-FINDING` |
| `Eval` / `GroovyShell` inside Groovy's tools, tests, and
`groovysh`/`groovyConsole` | By design — `BY-DESIGN: property-disclaimed` |
| `@Grab`/Grape fetching and loading artifacts | By design dependency
resolution — `OUT-OF-MODEL` |
+| Dependency-verification config that trusts by checksum or by group rather
than per-artifact signature — `verify-metadata=false`, group-scoped `<trust>`
entries, or an `ignored-key` with a checksum fallback
(`gradle/verification-metadata.xml`) | Deliberate, scoped dial-downs, each
recorded in-file: metadata enforcement is off while jar integrity still holds
via `verify-signatures` + checksums; self-resolved baselines
(`org.apache.groovy`, `org.codehaus.groovy`) and the doc toolchain (`o [...]
| Temp-file/dir creation, and other artifacts tooling writes | Owner-only or
least-exposure (P4); path-contained (P4b) — `KNOWN-NON-FINDING` unless a
*default-config* case widens exposure or escapes its tree, which is
`VALID-HARDENING` |
| Regex, `BigInteger`/`BigDecimal` parsing, hash-collision flooding (JDK
treeifies heavily-collided `String`-keyed buckets since Java 8) | DoS bounded
by developer-chosen input — `OUT-OF-MODEL: downstream-responsibility` |
| Deep recursion / unbounded input in Groovy's *own* data parsers
(`JsonSlurper`, `XmlSlurper`/`XmlParser`, `groovy-yaml`/`-toml`/`-csv`) |
Robustness of code meant to consume untrusted input — **`VALID-HARDENING`**
*(maintainer)*; nesting depth is now bounded by default in all of them (JSON
via the 6.0.0 `maxNestingDepth` cap, GROOVY-12064; XML via the 6.0.0
`jdk.xml.maxElementDepth` bound, GROOVY-12331), per-parser exposure in
[§6](#6-assumptions-about-inputs) |
diff --git a/gradle/verification-metadata.xml b/gradle/verification-metadata.xml
index 83f7b97602..19faf6cd6a 100644
--- a/gradle/verification-metadata.xml
+++ b/gradle/verification-metadata.xml
@@ -39,6 +39,12 @@
gpg -\-keyserver hkps://keyserver.ubuntu.com -\-recv-keys <KEY_ID> # fetch
to local gpg
gpg -\-export -\-armor > gradle/verification-keyring.keys # regenerate the
whole file
+ The configuration settings below are deliberate; if a regeneration resets
one, restore it.
+ In particular, verify-metadata is false on purpose: metadata (POMs) is not
+ signature/checksum-enforced, because jar integrity is already covered by
verify-signatures
+ plus checksums, while enforcing metadata adds noisy failures on unsigned
ancillary POMs for
+ no integrity gain.
+
Do not remove this header.
-->
