 | NixOS JVM | 112 Members |
| 23 Servers |
| NixOS JVM | 112 Members |
| 23 Servers |
| Sender | Message | Time |
|---|---|---|
| 27 Mar 2025 | ||
 msgilligan | For Nix, I would define availability as existing on master, but one could argue it is still available from an earlier hash. | 03:26:25 |
 emily | I don't think there really is. "End of Service/Support Life - this code stream is no longer being maintained. No further builds of Eclipse Temurin are planned." | 03:26:29 |
| msgilligan | * For Nix, I would define availability as existing on master or unstable, but one could argue it is still available from an earlier hash. | 03:26:44 |
| emily | ultimately, as soon as the next non-LTS is out, the next security advisory doesn't include patches for the previous one | 03:27:08 |
| msgilligan | Well, the question is whether the unsupported builds are available for download. | 03:27:13 |
| emily | that's the reality that Oracle decides and everyone else is constrained by | 03:27:21 |
| msgilligan | I'm happy to use an unsupported build for a month or two. | 03:27:32 |
| emily | would you be, if a critical severity CVE comes out days after it leaves support? | 03:28:10 |
| msgilligan | Well, yeah actually maintaining the JDK is a lot of work. But other vendors can do it and I think some of the big ones do for paid support. | 03:28:24 |
| emily | because you can look at the stream of advisories and see that it's really like clockwork. it just comes down to gambling in the end | 03:28:43 |
| emily | we don't like to gamble with users' security | 03:29:02 |
| msgilligan | I'd move really fast to the new one. But having releases deleted automatically, in the same PR as the new release seem excessive. | 03:29:14 |
| msgilligan | Well, I'm talking about availability on unstable. And saying that marking them as knownVulnerabilities immediately even if there aren't any. | 03:30:24 |
| msgilligan | I'd say users of NixOS who are not paying anything and using non-LTS releases on the unstable branch that are out of upstream support are gambling with their own security. And personally, I'm willing to do that because my main use case is developing alpha software that will eventually run on the stable branch. | 03:31:59 |
| emily | tbh I don't really think of it as deleting. just as an update. there's the LTS releases and a rolling stream of the latest one | 03:32:21 |
| emily | knowmVulnerabilities would be adequate but it does mean that you will have to compile it yourself | 03:32:58 |
| emily | and that takes a rather long time | 03:32:59 |
| emily | BTW we do keep binary JDKs around and marked EOL | 03:33:10 |
| emily | because those don't impose any meaningful maintenance burden and also have no compile cycle | 03:33:33 |
| emily | so Temurin is an option | 03:33:48 |
| msgilligan | I'm getting the feeling that "we don't like to gamble with users' security" is at least partly a rationalization for avoiding maintenance burden on the source (and if that's the case, it makes sense and have no problem with it) Because the Temurin 23 will have the same vulnerabilities as the OpenJDK 23 built from source. I'm not trying to be argumentative, I just want to understand what you feel the tradeoffs are. Because I totally get the maintenance overhead argument and completely respect it. For my use case, using binary JDKs is probably fine. (Though I would migrate to the one built from source when JDK 25 is released.) But that also means the interim releases as-built-by-Nixpkgs are getting less testing. | 03:41:57 |
| emily | the gambling was re knownVulnerabilities | 03:44:45 |
| emily | if we set it on both then no gambling | 03:44:56 |
| emily | but one of them takes hours to build and the other seconds | 03:45:05 |
| emily | so the UX is kinda better with the Temurin package once marked | 03:45:19 |
| emily | (and yeah a package that's just a download is very low maintenance) | 03:45:46 |
| msgilligan | But this unmerged PR looks (to my beginner's eye) like it removes Temurin 23 as well: https://github.com/NixOS/nixpkgs/pull/391811/files#diff-79588acae2eadf21386a83519365d48aad6c7162da39897f429bca64ad8437ff | 03:46:02 |
| emily | yeah, it does. I haven't reviewed the PR. I guess I should say "at some point we have done things like this" :) | 03:48:09 |
| emily | FWIW "drop source, mark binary" is how Electron maintainers handle EOLs | 03:48:32 |
| msgilligan | My project will survive no matter what the NixOS JVM team decides, but I really like Nix, want to provide feedback and help as I can, and use Nix as fully as possible in my build. I'm also eventually hoping to get some Java apps into nixpkgs. If the human and infrastructure resources are sufficient for keeping the built-from-source packages in | 03:54:17 |