Please excuse the top-post and the slow response-time. I am fully in agreement with the vendoring approach for jtreg7.
If there aren't any concerns from the team, I will review the MR and prepare an upload in the next few days. Cheers, tony On Tue, Apr 09, 2024 at 02:02:13PM +1200, Vladimir Petko wrote: > 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 > >
signature.asc
Description: PGP signature
