Hi, I have realized that I have not submitted the bug report for this issue, so the decision to try vendoring dependencies for JTREG is not visible anywhere.
Starting from the April OpenJDK release, JTREG 7.3 will be used for openjdk-11 and up, which will require having it in Buster and up. In Ubuntu, the January OpenJDK update used the vendored version, and we have not found any test regression issues caused by it. I have an MR open[1] that does not update the source tree and a branch[2] with imported sources. Best Regards, Vladimir. [1] https://salsa.debian.org/java-team/jtreg7/-/merge_requests/1 [2] https://salsa.debian.org/vpa1977/jtreg7/-/tree/jtreg_with_sources?ref_type=heads On Sun, Oct 22, 2023 at 10:01 AM Emmanuel Bourg <ebo...@apache.org> wrote: > > Le 21/10/2023 à 20:55, tony mancill a écrit : > > > My secondary concern is how we would respond to CVEs in the vendored > > components. We can debate whether the attack surface area in a tool > > like jtreg warrants patching the vendored components, but as a general > > principle, that's why we avoid vendoring in the first place. > > > > But if vendoring is acceptable in some circumstances, I can imagine > > cases where it helps with bootstrapping too, but that's probably a topic > > for a different thread. > > > > In any event, I'm glad that we're having the discussion and that the > > Security Team has taken a look. Let's see how it goes with jtreg7. > > jtreg is only used to run the openjdk tests, that's not a security > sensitive package, so embedding the package isn't a concern. > > Emmanuel Bourg >
