On Mon, May 16, 2022 at 9:54 PM Andrew Hughes <gnu.andrew@xxxxxxxxxx> wrote: > > On 19:36 Tue 10 May , Florian Weimer wrote: > > * Vitaly Zaitsev via devel: > > > > > On 10/05/2022 15:29, Ben Cotton wrote: > > >> This is initial step to move JDKs to be more like other JDKs, to build > > >> proper transferable images, and to lower certification burden of each > > >> binary. > > > > > > Strongly -1. Bundled versions are always outdated and may be even > > > vulnerable. > > > > And upstream only incorporates security fixes once per quarter, so the > > recent zlib bug (CVE-2018-25032) would have to be reintroduced, or a > > downstream-only patched for it applied. There was some confusion > > whether this bug only happened with Z_FIXED, but there's been another > > reproducer now. Given the lack of public discussion (following upstream > > policy), it's not clear whether this has been taken into account. > > > > It's not quite as simple as bundled is always worse. > > It really depends a lot on how well the package is maintained and how > quickly security updates for the system package make it into Fedora. > Yes, if a security fix comes out right after a quarterly security > update to OpenJDK has happened, it could be at least three months > until the version in the JDK is patched. How problematic this is > depends on how exploitable the issue is from JDK code. > > Having being involved in these security updates for over fifteen > years, I've seen cases both where the fix is already in the system > version and also where it is not (and may be some time before it is, > depending on the seriousness of the bug). This includes cases where > the bug is discovered at the JDK level and so the issue can be > resolved there before it is in the upstream project. > > One thing I can say is that determining whether the system version > is fixed or not adds additional work to the process, and also > causes confusion when Oracle are reporting a CVE as fix in the > JDK update and we are not (because it's already fixed in the > system library) > > Also, my sympathy for this argument is a little short, given the > number of times we've released OpenJDK updates for Fedora on unembargo > date, only for them to sit waiting for karma. Recently, we even had > one security update usurped by a later regression fix because it still > hadn't gone stable in over a week. Let's not pretend that Fedora has > every security issue fixed as soon as the unembargo lifts. > I don't know if you're going to gain any sympathy for stating this, considering how badly the Fedora Java ecosystem has fallen apart in the span of five years. Both in the wider Red Hat world and within Fedora itself, Java has received less and less love, to the point that it has been brutally starved. It has gotten so bad that Debian (!!!) beat us to newer Java and we had to *beg* for this to be fixed. So much for Features and First, eh? Once, long ago, we were the leader in the Linux Java ecosystem, but ironically as Red Hat's influence in OpenJDK grew, investment in Fedora dwindled. We've also lost most of our Java based apps to even test OpenJDK with. What the heck are we supposed to do to test and give karma? We lost Eclipse last year, and we lost IntellJ and NetBeans several years ago. Azureus was removed a year ago, too. The larger Java community stopped encouraging the development of desktop apps more than seven years ago, and with it all the things people would normally be able to use with it are gone. Red Hat encourages web apps because it aligns well with the JBoss middleware stack that they still sell subscriptions for, and even *those* aren't in Fedora. The Red Hat Java team has done *nothing* that I can see to advocate for Java in the larger Fedora community, nor have they tried to appeal to people to make applications like Microsoft does with .NET. Even with all the poison a decade ago heaped at Mono and .NET, we actually still have a better shot of reviving interest in C# on Linux because the .NET ecosystem still tries to make native applications and cross-platform ones at that. GtkSharp is amazingly somehow not completely dead, and there have been efforts to plug it into .NET MAUI. If that happened, tons of .NET applications would be easily available to Linux users. So tell me, if we actually *did* this, what are *you* planning to do to make open source Java more attractive? What are you going to do to help drive growth in developing the next generation of Java applications so that the ecosystem doesn't fall apart even further than it already has? What are you going to do to make Java in Fedora successful? > > Once the vulnerability scanners get better, we should really avoid > > copies of the demangler code because of its occasional vulnerabilities. > > They won't be exploitable in OpenJDK (at all), but scanners will > > eventually flag the presence of that code, still requiring security > > updates. > > That seems to assume that the JDK retains the old version of the > code. The in-tree libraries do get updates as part of quarterly > security updates. As I say, there are even times when this happens > when the issue is not yet public. > > If a scanner is flagging bundle code in the JDK as being vulnerable, > then that's something we can raise in the OpenJDK vulnerability group > to get the code fixed in OpenJDK. That's actually better from a > "upstream first" position as we are then improving all builds of > OpenJDK, rather than taking a position of it not being our problem > because the system version is fixed. > Sorry, no. Bundling libraries upstream was always a bad idea, a legacy of the bad old days where code dependency managers didn't exist. Even for C/C++ code, dependency managers exist. Notably Conan is quite popular. If we wanted to, we could map Conan dependencies to RPM packaged content. I don't know how any of this Change benefits Fedora, when it reeks of reducing investment even further. From where I stand, I see no "Benefit to Fedora". -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
