Hi Jan,
On 29.08.2025 14:02, Jan Høydahl wrote: >> Renovatebot, I'll definitely take a closer look, especially to see how >> it handles security updates. > > Once we start publishing our dependency graph to GitHub, Renovatebot > can take advantage of that and file special vulnerability PRs with a > custom label, see > https://docs.renovatebot.com/configuration-options/#vulnerabilityalerts Thank you for clarifying. So if I understand correctly, Renovatebot polls Dependabot alerts for new vulnerable dependencies, and when it finds one it creates a PR. That PR would then serve as the entry point for handling vulnerabilities in Solr. Would it be possible to add metadata to such PRs? For example, using the `commitBody` template: --- updated-dependencies: {{#each upgrades}} - dependency-name: {{depName}} dependency-current-version: '{{currentValue}}' dependency-new-version: '{{newValue}}' {{/each}} ... I was thinking about proposing a workflow like this that could be triggered by the Renovatebot PR: 1. Open a JIRA issue to track handling of the vulnerability. 2. Open a draft PR in `solr-site` with an “in triage” VEX entry. 3. Use the VEX PR as an integration point for the tools from OpenRefactory. The first (a Java call graph [1]) is already available, with more to follow to help determine which methods are affected and whether they are reachable. 4. As a result we’d always have two PRs: - the original PR upgrading the dependency in `apache/solr`, and - a PR in `apache/solr-site` documenting whether Solr is affected and guiding the release decision. For this workflow to be effective, the key information we need is the GAV coordinates of the upgraded dependency. With those, we can query vulnerability databases and identify which CVEs are addressed. If Renovate PRs can expose this metadata, I already have the first two steps nearly ready (see [2] for JIRA issue creation). I’d suggest encoding the metadata in the same way Dependabot does, as a small YAML document appended to the commit message, so the workflow stays independent of Renovate and could be reused by other ASF projects. Because Solr relies on Hadoop’s shaded artifacts, Solr’s security depends on Hadoop promptly releasing updates whenever a shaded dependency is vulnerable. That’s why I think it’s useful to design a workflow compatible with Hadoop’s build tools (Maven/Dependabot), while also aligning with similar efforts in Commons and Logging. What do you think — should I start submitting PRs to get this moving? Best, Piotr [1] https://github.com/vex-generation-toolset/java-callgraph [2] https://github.com/vex-generation-toolset/solr/blob/main/.github/scripts/create-jira-vex-issue.sh --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
