On Thu, Jul 24, 2025 at 3:17 AM Piotr P. Karwasz <pi...@mailing.copernik.eu>
wrote:
> Hi Gary,
>
> On 23.07.2025 13:18, Gary Gregory wrote:
> > So, for Commons Compress for example, like this:
> >
> > {
> > "@context": "https://openvex.dev/ns/v0.2.0";,
> > "id": "https://apache.org/vex/statement-commons-compress-001";,
> > "author": "apache.org",
> > "role": "Document Creator",
> > "timestamp": "2025-07-23T11:11:00Z",
> > "version": 1,
> > "statements": [
> > {
> > "vulnerability": {
> > "name": "CVE-2025-48924"
> > },
> > "products": [
> > "pkg:maven/org.apache.commons/commons-compress@1.28.0"
> > ],
> > "status": "not_affected",
> > "justification": "vulnerable_code_not_in_execute_path",
> > "timestamp": "2025-07-23T11:11:00Z"
> > }
> > ]
> > }
>
> Hi Gary,
>
> Yes, exactly, that's the idea. However, I'd prefer *not* to use OpenVEX
> or CycloneDX as the input format. Instead, my goal is to define a
> simpler, more human-friendly input that we can use to generate both:
>
> - A human-readable security description on the website, listing:
> - The Commons Compress versions depending on the vulnerable Commons
> Lang, and
> - The vulnerable dependency versions (e.g., Commons Lang),
> similar to what Apache Solr does here:
>
>
I think I disagree and feel this is completely backward, so maybe I
misunderstood what you wrote (only one cup of joe this AM):
We should _start_ from a machine-readable format from which release notes
and HTML elements can be derived. As a start I've stored the above
in src/conf/security/openvex.json
A further step would be for our tooling to include a text version
in src/site/xdoc/security.xml. Maybe the build or release plugin could
generate all of security.xml. We already use the build plugin to generate
some files.
>
>
> https://solr.apache.org/security.html#cve-reports-for-apache-solr-dependencies
>
> - A machine-readable OpenVEX or CycloneDX VEX document, like this one:
>
> https://solr.apache.org/solr.vex.json
>
> For the input format, I’d like to follow the same approach I proposed
> for Apache Solr [1]:
>
> - One file per CVE of the project itself or its dependencies.
>
I don't see the need to overcomplicate processing with multiple files when
at least the OpenVEX format allows for multiple entries. Using >1 file has
the potential for a lot of duplicate text.
> - Written in Markdown with a YAML preamble to capture the structured
> metadata, similar to how Pelican works [2].
>
Inventing a custom schema seems like a bad idea to me when formats like
OpenVEX have a well-defined schema. If we need to use Markdown as an
intermediary step, then maybe. YAML is gross IMO due to its use of
significant whitespace, causing too many problems unless you have X-ray
eyes.
Gary
>
> Here’s an example:
>
> ```
> ---
> cve: CVE-2025-48924
> dependency:
> group: org.apache.commons
> name: commons-lang3
> versions:
> - introduced: 3.0
> fixed: 3.18.0
> group: org.apache.commons
> name: commons-compress
> versions:
> - introduced: 1.26.0
> last_affected: 1.27.1
> status: not_affected
> justification: vulnerable_code_not_in_execute_path
> summary: Vulnerable `ClassUtils` class is not used
> ---
>
> CVE-2025-48924 is **not** exploitable in Commons Compress versions
> 1.26.0 through 1.27.1, because the vulnerable `ClassUtils` class from
> the `commons-lang3` dependency is not used in these versions.
> ```
>
> I haven't thought about the details yet, but I believe we can use a
> Python script to convert this format into a single `security.md` page or
> generate a file suitable to be used with a Velocity template.
>
> Best,
> Piotr
>
> [1] https://lists.apache.org/thread/o6bgxv996kfrmmy7odf226twsg9bnwbj
> [2]
>
> https://github.com/apache/solr-site/blob/main/content/solr/security/2021-12-10-cve-2021-44228.md?plain=1
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
