> I see 17 is potentially ripping out security manager, why? wth?
Because Security Manager — which enforces runtime access capabilities, like an OS kernel does — exists for the sake of Java applets, and Java applets have been dead for a long time. The Security Manager enables secure execution of "mobile" (i.e. untrusted, not-auditable-at-time-of-release) code — cases where the "host" and "guest" codebases are compiled separately with the "host" having no ability to introspect the "guest" during the "host's" compilation, because the "guest" doesn't exist yet.
Security Manager does not exist for the sake of fighting against your own project's dependencies. There are much simpler and more runtime-efficient solutions (like linters / static-analysis tools) for the case where the "host" can see the "guest's" code at compile time.
Security Manager doesn't exist for the sake of "plugins" (e.g. WARs, Java Agents, etc), either. Even if you don't have a plugin's source code available in your project worktree at build time, you can still validate the plugin's behavior at release time by statically analyzing its bytecode before building it into your release fatJar. Which still allows you to make much stronger guarantees than Security Manager can.
no, not just applets.
its used for any kind of secure system where developers and their components are forbidden from say network access, e.g. some nashorn map reduce javascript.
java _used_ to be the language of choice for building complex systems with large multinational multidisciplinary teams. security manager was a vital part to those projects, removing security manager means none of that can migrate.
Because the modern Enterprise-y best-practice is to not allow multiple security contexts to exist within a single monolithic OS process where the OS kernel's own "security manager" can't get to them to enforce its own policy; but rather to cleave apart your process along security-context lines into multiple processes; containerize those to isolate them from each-other; poke precise holes in those containers for well-defined RPC channels to flow; and connect those channels using a service mesh with secure application-layer firewalling.
No modern ops staff would trust the JVM to not be exploitable if you're exposing it as an attack surface to arbitrary user-supplied (or "third party dev who is incentivized to make a network call you don't want them to make") bytecode. Creating that kind of boundary is what technologies like gVisor and Istio are for; it's not the job of a programming-language runtime. (See also: the decline and fall of Google App Engine's "secure runtime" standard environment, in favor of the gVisor-based flexible environment.)
(Well, okay, Node and Lua are both runtimes that have trustworthy VM-level isolation that can be used to achieve this — see Cloudflare Workers for the Node case, or Redis scripting for the Lua case. But this is because Node and Lua both have "shared-nothing" runtime execution semantics with no concept of static-bound identifiers [i.e. constants] — meaning that all the fundamental "stuff" available in a Node or Lua execution context is put there dynamically, and so a sandbox can be constructed "from scratch" with arbitrary stuff [mocks/stubs/proxies] inserted in place of the fundamental module handles, to create a whitelisted environment. The JVM is not built like this; the JVM's Security Manager merely blacklists certain known-dangerous operations, and so does nothing to prevent exploitation of zero-day vulnerabilities.)
> Node and Lua are both runtimes that have trustworthy VM-level isolation that can be used to achieve this — see Cloudflare Workers for the Node case
Correction: Cloudflare Workers does not use Node, explicitly because Node does not provide secure isolation. Workers uses a custom runtime built directly on V8, which does provide secure isolation in the way you describe.
As for Lua, it might work in theory, but I don't think it has had anywhere near the scrutiny V8 has had. I wouldn't bet on it when security really matters.
Re: Lua, I don't know about "scrutiny" in the code-audit sense, but I believe that there are a few battle-tested deployments of Lua in entirely-untrusted sandboxing use-cases. Some games (e.g. Minecraft's Computercraft mod) allow players to deploy arbitrary Lua scripts which are then executed on other arbitrary players' computers; and yet nobody's managed to nuke anyone else's hard drive through these scripting mechanisms yet, despite griefers having high motivation to try.
For the same reason that blockchain software continuing to exist makes me have a lot more faith in the collision-resistance of SHA256 (despite a lack of cryptanalytic proof of such), I'd trust a tightly-constrained Lua sandbox. (In both cases, of course, there might be a state-military-level adversary with a vulnerability in hand, who doesn't want to show their hand for something as trifling as money. But such an attacker is highly unlikely to deploy their exploit against my service in particular, even if they have it.)
> Because the modern Enterprise-y best-practice is to not allow multiple security contexts to exist within a single monolithic OS process where the OS kernel's own "security manager" can't get to them to enforce its own policy; but rather to cleave apart your process along security-context lines into multiple processes; containerize those to isolate them from each-other; poke precise holes in those containers for well-defined RPC channels to flow; and connect those channels using a service mesh with secure application-layer firewalling.
It always was?
None of that solves the problem of blacklisting certain actions or logging for audit based on the content and/or origin of the data being processed.
Ignoring such things does explain why and how modern enterprise-y solutions are leaking like sieves tho I guess, e.g. solarwinds would likely never have happened if they implemented proper application component level permissions.
Because nobody is maintaining it, because nobody is using it in big modern projects; and a blacklist-based solution like the Security Manager needs constant attention and maintenance as the JVM's stdlib grows, to avoid something slipping through. Every time someone adds something that needs to be secured to the JVM, there's the extra overhead of coming up with a (not necessarily easy!) way of instrumenting it for the Security Manager to control.
Given a fixed pool of developer resources, eliminating unused per-change overheads like this, serves as a multiplier for the project's ability to do everything else. The time freed from core devs by not writing Security Manager instrumentation for everything, could be instead allocated to e.g. getting Project Loom stable and upstreamed.
And that's assuming that everyone even does the Security Manager instrumentation of each new thing perfectly. The devs doing that instrumentation don't use Security Manager any more than a random Java dev does, so they likely don't know its ins and outs. Every new patch is thus a new opportunity for someone to bungle the Security Manager instrumentation, and thus for exploitable JVM surface area to be created. The more time that goes by, the more likely such exploitable surface area is to have already been introduced and gone entirely unnoticed by a population of developers that just doesn't use the feature. And so, the more time/patches that go by, the more that the Security Manager shifts from being a harmless thing to leave around, to a land-mine waiting to strike any dev who does try to use it.
(The "blacklist where at any point a new feature could be added and its security implications missed" problem is the same reason it's hard to trust SELinux—but at least SELinux is used by default for securing system components in some Linux distros, so at least SELinux policies gets pulled in on a regular basis as part of other companies' security audits of their stacks. Security Manager isn't used by default anywhere!)
Taking a node down does not mean outage at all. Service uptime also reads like a non-sequitur given the comment on the JDK11 crashes sounded like OP was doing something weird with the new JDKs, not with the old prod system running JDK8.
JDK11 was released way back in 2018. Any claim that it's unstable these days is not credible.
Because the core system dates back to jre... 1.4, has had ~2 decades of painful testing and big chunks of code dont currently work on anything newer than 8.
a bug that takes 100 hours to manifest takes multiples of that to fix.
compute and ram is crazy cheap these days, developers are not, and finding good ones is harder than ever.
Yeah I'm gonna say you're an edge case and that the majority of users will see performance benefits. Maybe not you, but that's legacy code for ya and an awful lot of technical debt that's likely not worth it.
every java dev was an edge case, from small houses building blockbusters like triage through to the likes of gazprom and google building their entire backend on it with tens of thousands of devs.
since you threw them out, which "majority of users" are you thinking of?
Nah, I'm just saying you have a lot of legacy code you're either incapable of fixing or not willing to fix. And no, not every java developer is an edge case. If that were true then no one would be able to upgrade and they wouldn't bother creating more Java releases, we'd still all be on 8. See I too can make sweeping assumptions with no basis in reality. Sorry your codebase sucks, good luck!
LOL, you know nothing about what I do. And it sounds like you have experience with "freshly written code that crashes multiple times a week for the first few years"... here's a hint, it's probably you and your development team to blame, not the JDK.
Maybe you should quit being lazy, learn the new JDK APIs and features, and convert that POS legacy codebase into something that's not dependent upon a platform released 7 years ago. But then again, maybe you're not a competent enough developer to do so, so you blame the JDK developers instead.
I really didnt need to know you live of the wrong side of the 24x7 oncall employment curve.
But now that I do, i still have no interest in anything you think you know, you sound like the kind of dev I could replace with a 14 year old on $2 an hour.
Hah! Good luck dude, I feel sorry for you and your POS app that you can't upgrade. Stuck on JDK8 for the rest of your life while the rest of us have moved on. Must suck doing legacy support for such an ancient app. And by the sounds of it, you must have been hiring those 14 year olds @ $2/hour. Kinda explains why you're in the mess you're in, hahahahaha!!!
thats actually less of an issue than it sounds for a jvm build that hasn't had a relevant and important security issue found for over a decade, is now open source and all the others found and fixed any time recently give better assurance over any recent code that hasnt had the same scrutiny.
what in 17 do you think is worth risking downtime?