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. > 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. Thanks, -- Andrew :) Pronouns: he / him or they / them Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ 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
