Hi Dependabot is a public bot and deems it unsafe to execute custom scripts, so it is not supported. That’s why we run our own bot without such restrictions.
Wrt separate dep PRs for 9.x, I have submitted fixes to renovatebot to support this even for forked mode. Need to test it. But currently on holiday so won’t be for another couple weeks. Jan Høydahl > 23. juli 2025 kl. 20:54 skrev Piotr P. Karwasz <pi...@mailing.copernik.eu>: > > Hi Christos, > > On 23.07.2025 13:57, Christos Malliaridis wrote: >>> How are vulnerable dependencies handled? Are JIRA issues created >>> automatically for such cases? >> >> When it comes to vulnerabilities and vulnerable dependencies, we have to >> distinguish between vulnerabilities that affect Apache Solr, and the ones >> that don't. When a vulnerability is found in a dependency, a CVE is usually >> published and the *security page*[1] can be taken for advice here. If the >> dependency is affecting the security of Solr, the vulnerability is resolved >> usually by updating the dependency and releasing a new version (at least >> for what I know). I believe that in such scenarios it also makes sense to >> create a Jira issue. As of my knowledge, this step is handled by devs and >> is not automated yet. > > Thank you for the explanation. I think I can help with some automation > here to: > > - Open a JIRA issue to evaluate the effects of the given CVE. > - Open a PR linked to the JIRA issue to try upgrade the dependency to a > version without the vulnerability. Getting rid of the vulnerability is > probably useful even if it is not exploitable. > >>> Are transitive dependencies also monitored and updated? >> >> Yes. We are using gradle's *version catalogs*[2] and use that in >> combination with gradle's dependency *locking mechanism*[3]. This is the >> reason why we have custom scripts that need to be executed when updating a >> dependency, as there is no simple way of doing so in Gradle. > > From what I understand the answer is: yes, if the dependency is in the > catalog. We have a similar problem in Log4j: we don't get notifications > for transitive dependency that don't figure anywhere in the POM files. > >>> I’m more familiar with the Dependabot ecosystem >> >> There was an attempt[4] from my side to introduce dependabot and replace >> renovatebot, which would not require a separate project anymore and the >> overall setup would be simpler. However, in the attempt of introducing >> dependabot I noticed that it is not capable of executing additional gradle >> tasks for updating the lock, license and notice files. This required >> multiple changes in our workflows, which was not ideal. So we went with >> renovatebot as it was easier to update by that time. The PR that I linked >> contain a lot of observations that I have shared in case anyone else wants >> to continue where I left off. > > Since Dependabot is Open Source, this problem should be fixable. I'll > look into it. > > As I understand, except this problem, you don't have any specific > preference between Dependabot and Renovatebot? > >> In the attempt I mentioned above, the dependency submission of dependabot >> is included. I believe it should be easy to add the dependency submission >> to our project without much effort. I think it is just a workflow file that >> needs to be copied and some project settings on Github that need to be >> updated. > > There are a couple of ways to submit dependencies to the GitHub > Dependency Graph: > > 1. Automatic submission can be enabled through project settings. In our > case we would need to extend `.asf.yaml`. The effect is a rather crowded > graph[1] with most *build* dependencies (except Gradle and its plugins > as far as I can tell). > > 2. As you mention, dependencies can be submitted by a workflow, e.g. > using the `github-dependency-graph-gradle-plugin`[2], which gives some > options on which dependencies to include and which to ignore. > > 3. Dependencies can be submitted using an SBOM[3], which might be the > less verbose option, since the SBOM might include only those > dependencies that end up in the `*.tgz` archive. > >> About your goals: our renovatebot creates automatically pull requests for >> all dependencies in our version catalog. In case a vulnerable dependency is >> a transitive dependency, it is possible to add it to the version catalog >> and manually update the transitive dependency separately (in case the >> dependency that uses it has no updates yet). > > I guess pinning a transitive dependency to avoid a vulnerability is > something Dependabot could also learn to do. > >> Now when it comes to VEX files >> I am not sure what options we have here, as I am not familiar enough with >> this topic. > > Regarding VEX-es most of the automation will be provided by > OpenRefactory in the following months[4]. Right now I am just wondering > what is the right place to integrate the tooling that will be provided. > >> More information about how dependencies are updated can be found in the two >> files we have about dependencies[5]. Please note that between 9.x and 10 >> (current main) the process is slightly different, so you have to checkout >> both versions of the files. > > Thanks, I'll certainly read those. > > Piotr > > > References: > [1] https://github.com/vex-generation-toolset/solr/network/dependencies > [2] https://github.com/gradle/github-dependency-graph-gradle-plugin > [3] > https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/using-the-dependency-submission-api#submitting-sboms-as-snapshots > [4] https://lists.apache.org/thread/8yzoyn4xxy25x9thd7bcq1cz5soj619q > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
