As I mentioned in IRC and was pasted earlier in the thread, I believe the easiest path is to follow the major releases of OpenJDK in the long-term-support Linux OS releases. Currently, Debian Stable (Stretch), Ubuntu 16.04 (Bionic (near release)), and Red Hat / CentOS 7 all have OpenJDK 8 as the default JDK. For long-term support, they all have build facilities in place for their supported architectures and developers that care about security updates for users through their documented EOL dates.
The current deb and rpm packages for Apache Cassandra all properly depend on OpenJDK 8, so there's really nothing to be done here, until the project decides to implicitly depend on a JDK version not easily installable on the major OS LTS releases. (Users of older OS versions may need to fiddle with yum and apt sources to get OpenJDK 8, but this is a relatively solved problem.) Users have the ability to deviate and set a JAVA_HOME env var to use a custom-installed JDK of their liking, or go down the `alternatives` path of their favorite OS. 1) I don't think we should be get into the business of distributing Java, even if licensing allowed it. 2) The OS vendors are in the business of keeping users updated with upstream releases of Java, so there's no reason not to utilize them. Michael On 03/22/2018 05:12 PM, Jason Brown wrote: > See the legal-discuss@ thread: > https://mail-archives.apache.org/mod_mbox/www-legal-discuss/201803.mbox/browser > . > > TL;DR jlink-based distributions are not gonna fly due to OpenJDK's license, > so let's focus on other paths forward. > > > On Thu, Mar 22, 2018 at 2:04 PM, Carl Mueller <carl.muel...@smartthings.com> > wrote: > >> Is OpenJDK really not addressing this at all? Is that because OpenJDK is >> beholden to Oracle somehow? This is a major disservice to Apache and the >> java ecosystem as a whole. >> >> When java was fully open sourced, it was supposed to free the ecosystem to >> a large degree from Oracle. Why is OpenJDK being so uncooperative? Are they >> that resource strapped? Can no one, from consulting empires, Google, IBM, >> Amazon, and a host of other major companies take care of this? >> >> This is basically OpenSSL all over again. >> >> Deciding on a way to get a stable language runtime isn't our job. It's the >> job of either the runtime authors (OpenJDK) or another group that should >> form around it. >> >> There is no looming deadline on this, is there? Can we just let the dust >> settle on this in the overall ecosystem to see what happens? And again, >> what is the Apache Software Foundation's approach to this that affects so >> many of their projects? >> >> On Wed, Mar 21, 2018 at 12:55 PM, Jason Brown <jasedbr...@gmail.com> >> wrote: >> >>> Well, that was quick. TL;DR Redistributing any part of the OpenJDK is >>> basically a no-go. >>> >>> Thus, that option is off the table. >>> >>> On Wed, Mar 21, 2018 at 10:46 AM, Jason Brown <jasedbr...@gmail.com> >>> wrote: >>> >>>> ftr, I've sent a message to legal-discuss to inquire about the >> licensing >>>> aspect of the OpenJDK as we've been discussing. I believe anyone can >>> follow >>>> the thread by subscribing to the legal-discuss@ ML, or you can wait >> for >>>> updates on this thread as I get them. >>>> >>>> On Wed, Mar 21, 2018 at 9:49 AM, Jason Brown <jasedbr...@gmail.com> >>> wrote: >>>> >>>>> If we went down this path, I can't imagine we would build OpenJDK >>>>> ourselves, but probably build a release with jlink or javapackager. I >>>>> haven't done homework on that yet, but i *think* it uses a blessed >>> OpenJDK >>>>> release for the packaging (or perhaps whatever JDK you happen to be >>>>> compiling/building with). Thus as long as we build/release when an >>> openJDK >>>>> rev is released, we would hypothetically be ok from a secutiry POV. >>>>> >>>>> That being said, Micke's points about multiple architectures and other >>>>> OSes (Windows for sure, macOS not so sure) are a legit concern as >> those >>>>> would need to be separate packages, with separate CI/testing and so on >>> :( >>>>> >>>>> I'm not sure betting the farm on linux disto support is the path to >>>>> happiness, either. Not everyone uses one of the distros mentioned (RH, >>>>> ubuntu), nor does everyone use linux (sure, the vast majority is >>> Linux/x86, >>>>> but we do support Windows deployment and macOS development). >>>>> >>>>> -Jason >>>>> >>>>> >>>>> >>>>> On Wed, Mar 21, 2018 at 9:26 AM, Michael Burman <mibur...@redhat.com> >>>>> wrote: >>>>> >>>>>> On 03/21/2018 04:52 PM, Josh McKenzie wrote: >>>>>> >>>>>> This would certainly mitigate a lot of the core problems with the new >>>>>>> release model. Has there been any public statements of plans/intent >>>>>>> with regards to distros doing this? >>>>>>> >>>>>> Since the latest official LTS version is Java 8, that's the only one >>>>>> with publicly available information For RHEL, OpenJDK8 will receive >>> updates >>>>>> until October 2020. "A major version of OpenJDK is supported for a >>> period >>>>>> of six years from the time that it is first introduced in any version >>> of >>>>>> RHEL, or until the retirement date of the underlying RHEL platform , >>>>>> whichever is earlier." [1] >>>>>> >>>>>> [1] https://access.redhat.com/articles/1299013 >>>>>> >>>>>> In terms of the burden of bugfixes and security fixes if we bundled a >>>>>>> JRE w/C*, cutting a patch release of C* with a new JRE distribution >>>>>>> would be a really low friction process (add to build, check CI, >> green, >>>>>>> done), so I don't think that would be a blocker for the concept. >>>>>>> >>>>>>> And do we have someone actively monitoring CVEs for this? Would we >>> ship >>>>>> a version of OpenJDK which ensures that it works with all the major >>>>>> distributions? Would we run tests against all the major distributions >>> for >>>>>> each of the OpenJDK version we would ship after each CVE with each >>>>>> Cassandra version? Who compiles the OpenJDK distribution we would >>> create >>>>>> (which wouldn't be the official one if we need to maintain support >> for >>> each >>>>>> distribution we support) ? What if one build doesn't work for one >>> distro? >>>>>> Would we not update that CVE? OpenJDK builds that are in the distros >>> are >>>>>> not necessarily the pure ones from the upstream, they might include >>> patches >>>>>> that provide better support for the distribution - or even fix bugs >>> that >>>>>> are not yet in the upstream version. >>>>>> >>>>>> I guess we also need the Windows versions, maybe the PowerPC & ARM >>>>>> versions also at some point. I'm not sure if we plan to support J9 or >>> other >>>>>> JVMs at some point. >>>>>> >>>>>> We would also need to create CVE reports after each Java CVE for >>>>>> Cassandra as well I would assume since it would affect us separately >>> (and >>>>>> updating only the Java wouldn't help). >>>>>> >>>>>> To me this sounds like an understatement of the amount of work that >>>>>> would go to this. Not to mention the bad publicity if Java CVEs are >> not >>>>>> actually patched instantly in the Cassandra also (and then each user >>> would >>>>>> have to validate that the shipped version actually works with their >>>>>> installation in their hardware since they won't get support for it >>> from the >>>>>> vendors as it's unofficial package). >>>>>> >>>>>> - Micke >>>>>> >>>>>> >>>>>> ------------------------------------------------------------ >> --------- >>>>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >>>>>> For additional commands, e-mail: dev-h...@cassandra.apache.org >>>>>> >>>>>> >>>>> >>>> >>> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
