3 ms·

> I can download a jar that was produced by someone who disappeared 20 years ago, and have a reasonable level of confidence that it will work unmodified on my m

by pron 6y ago

> I can download a jar that was produced by someone who disappeared 20 years ago, and have a reasonable level of confidence that it will work unmodified on my machine today. You can still do that without a JRE; in fact, it is easier because there is no central notion of a single "Java version." > a lot of the time they're simply not up to providing security updates for the whole transitive closure of their dependencies on a timely schedule. Right, but the JRE didn't do that, either. A well-updated runtime with an ill-maintained application and dependencies is no better than an ill-maintained application, dependencies and runtime, especially if the runtime is has a lower attack surface area.

lmm 6y ago
> > I can download a jar that was produced by someone who disappeared 20 years ago, and have a reasonable level of confidence that it will work unmodified on my machine today. > You can still do that without a JRE; in fact, it is easier because there is no central notion of a single "Java version." But if the jlink-based approach you're advocating had been the norm 20 years ago, that jar file would never have been published; I'd be able to download packages of that application that worked for the systems of 20 years ago, but it would be a lot harder to run those on my current machine. > Right, but the JRE didn't do that, either. A well-updated runtime with an ill-maintained application and dependencies is no better than an ill-maintained application, dependencies and runtime, especially if the runtime is has a lower attack surface area. Depends on how much attack surface there is to that application and dependencies vs runtime, remembering that the Java standard library actually covers a lot of the basics. Often for a small application the Java runtime (including standard library) is actually the only part of the whole stack that's doing high-risk things (opening network sockets, parsing low-level data formats, implementing stateful protocol negotiations...).
- pron 6y ago
  > I'd be able to download packages of that application that worked for the systems of 20 years ago, but it would be a lot harder to run those on my current machine. The JAR is still there, though, in the package. Although I'm not sure why you'd think that a long-abandoned piece of software is more likely to run an a much later runtime than on its own embedded one. BTW, it is still perfectly acceptable to deliver an application as a JAR to developers who are expected to have a JDK and to know how to use it, and, of course, JARs are how all libraries are packaged. > Depends on how much attack surface there is to that application and dependencies vs runtime Ah, but that attack surface is smaller thanks to jlink. An application only distributes the runtime modules it actually needs. > Often for a small application the Java runtime (including standard library) is actually the only part of the whole stack that's doing high-risk things For a small application that is local, i.e. not a server -- perhaps. If it is meant to be used developers, they can run it with their JDK, and if it is meant for end-users, then surely it shouldn't dictate how all other applications are run. The author of such an application would use some library that adds auto-update for the application (or just its runtime). But I think that the belief that most attack vectors are due to the runtime rather than the application or its libraries, at least when it comes to servers, is less reality and more wishful thinking. The monolithic runtime in the JRE was both large and heavily studied, so there was a good stream of vulnerability reports, but that doesn't mean it was any less secure than your own application; it could have just felt that way because the application's security wasn't as well tested.
  - imtringued 6y ago
    >The JAR is still there, though, in the package. Although I'm not sure why you'd think that a long-abandoned piece of software is more likely to run an a much later runtime than on its own embedded one. Easy, because I don't want to run the application under wine.
    - pron 6y ago
      But it might not run unmodified under a new Java runtime, either. Codebases hacking into the JDK, using internal non-API classes, and making themselves tied to a specific version are common (even codebases that don't do that can become tied to a specific version or a range of versions, e.g. by generating or parsing bytecode). I hope they become less common when encapsulation is finally turned on in JDK 16, but even then applications can choose to selectively remove encapsulation -- for themselves and/or their dependencies -- use internals, and become tied to a specific version. Anyway, the JAR is still there, so you could try.
  - lmm 6y ago
    > The JAR is still there, though, in the package. Fair enough, assuming it's easy to extract that eliminates my big concern. As a user of a less popular OS I worry about the jar-based flow becoming a second-class approach, but I do appreciate that having a first-class way of distributing "native" executables is important. > Although I'm not sure why you'd think that a long-abandoned piece of software is more likely to run an a much later runtime than on its own embedded one. The point is that the jar<->jvm interface is a lot more stable than the jvm<->host system one. I suspect old JVM binaries would have linking issues (e.g. libc SONAME) or might not even be the right architecture to run on my current machines. > Ah, but that attack surface is smaller thanks to jlink. An application only distributes the runtime modules it actually needs. Sure, but things like low-level parsing are used by the application. It's not quite the same thing, but I maintain a couple of projects where approximately 100% of the security notifications I get are about vulnerabilities in Jackson, not because it's the majority of the library surface but because of what it's doing. Obviously Jackson isn't part of the JVM, but for an equivalent project that was using XML or CORBA I can easily imagine most of its attackable service being JVM code that the application really does use. There's also things like JMX which the application may well want to include even if it's not directly invoking it, but I remember as being a significant source of vulnerabilities. > The author of such an application would use some library that adds auto-update for the application (or just its runtime). Wasn't that the point of Java Web Start links? I usually favour leaving things up to libraries, but at the same time things need to be secure by default. > But I think that the belief that most attack vectors are due to the runtime rather than the application or its libraries, at least when it comes to servers, is less reality and more wishful thinking. The monolithic runtime in the JRE was both large and heavily studied, so there was a good stream of vulnerability reports, but that doesn't mean it was any less secure than your own application; it could have just felt that way because the application's security wasn't as well tested. I actually agree with that - most of those old applications probably only have security by obscurity. But still, there's a significant practical difference between "theoretically vulnerable" and "has a one-click prepackaged exploit". So encouraging every application to ship a static copy of the same chunk of well-known low-level code has a significant downsides - any vulnerability will become the equivalent of that zlib double free where essentially every MacOS program had to ship a new version.

by pron 6y ago

lmm 6y ago

> > I can download a jar that was produced by someone who disappeared 20 years ago, and have a reasonable level of confidence that it will work unmodified on my machine today. > You can still do that without a JRE; in fact, it is easier because there is no central notion of a single "Java version." But if the jlink-based approach you're advocating had been the norm 20 years ago, that jar file would never have been published; I'd be able to download packages of that application that worked for the systems of 20 years ago, but it would be a lot harder to run those on my current machine. > Right, but the JRE didn't do that, either. A well-updated runtime with an ill-maintained application and dependencies is no better than an ill-maintained application, dependencies and runtime, especially if the runtime is has a lower attack surface area. Depends on how much attack surface there is to that application and dependencies vs runtime, remembering that the Java standard library actually covers a lot of the basics. Often for a small application the Java runtime (including standard library) is actually the only part of the whole stack that's doing high-risk things (opening network sockets, parsing low-level data formats, implementing stateful protocol negotiations...).

pron 6y ago
> I'd be able to download packages of that application that worked for the systems of 20 years ago, but it would be a lot harder to run those on my current machine. The JAR is still there, though, in the package. Although I'm not sure why you'd think that a long-abandoned piece of software is more likely to run an a much later runtime than on its own embedded one. BTW, it is still perfectly acceptable to deliver an application as a JAR to developers who are expected to have a JDK and to know how to use it, and, of course, JARs are how all libraries are packaged. > Depends on how much attack surface there is to that application and dependencies vs runtime Ah, but that attack surface is smaller thanks to jlink. An application only distributes the runtime modules it actually needs. > Often for a small application the Java runtime (including standard library) is actually the only part of the whole stack that's doing high-risk things For a small application that is local, i.e. not a server -- perhaps. If it is meant to be used developers, they can run it with their JDK, and if it is meant for end-users, then surely it shouldn't dictate how all other applications are run. The author of such an application would use some library that adds auto-update for the application (or just its runtime). But I think that the belief that most attack vectors are due to the runtime rather than the application or its libraries, at least when it comes to servers, is less reality and more wishful thinking. The monolithic runtime in the JRE was both large and heavily studied, so there was a good stream of vulnerability reports, but that doesn't mean it was any less secure than your own application; it could have just felt that way because the application's security wasn't as well tested.
- imtringued 6y ago
  >The JAR is still there, though, in the package. Although I'm not sure why you'd think that a long-abandoned piece of software is more likely to run an a much later runtime than on its own embedded one. Easy, because I don't want to run the application under wine.
  - pron 6y ago
    But it might not run unmodified under a new Java runtime, either. Codebases hacking into the JDK, using internal non-API classes, and making themselves tied to a specific version are common (even codebases that don't do that can become tied to a specific version or a range of versions, e.g. by generating or parsing bytecode). I hope they become less common when encapsulation is finally turned on in JDK 16, but even then applications can choose to selectively remove encapsulation -- for themselves and/or their dependencies -- use internals, and become tied to a specific version. Anyway, the JAR is still there, so you could try.
- lmm 6y ago
  > The JAR is still there, though, in the package. Fair enough, assuming it's easy to extract that eliminates my big concern. As a user of a less popular OS I worry about the jar-based flow becoming a second-class approach, but I do appreciate that having a first-class way of distributing "native" executables is important. > Although I'm not sure why you'd think that a long-abandoned piece of software is more likely to run an a much later runtime than on its own embedded one. The point is that the jar<->jvm interface is a lot more stable than the jvm<->host system one. I suspect old JVM binaries would have linking issues (e.g. libc SONAME) or might not even be the right architecture to run on my current machines. > Ah, but that attack surface is smaller thanks to jlink. An application only distributes the runtime modules it actually needs. Sure, but things like low-level parsing are used by the application. It's not quite the same thing, but I maintain a couple of projects where approximately 100% of the security notifications I get are about vulnerabilities in Jackson, not because it's the majority of the library surface but because of what it's doing. Obviously Jackson isn't part of the JVM, but for an equivalent project that was using XML or CORBA I can easily imagine most of its attackable service being JVM code that the application really does use. There's also things like JMX which the application may well want to include even if it's not directly invoking it, but I remember as being a significant source of vulnerabilities. > The author of such an application would use some library that adds auto-update for the application (or just its runtime). Wasn't that the point of Java Web Start links? I usually favour leaving things up to libraries, but at the same time things need to be secure by default. > But I think that the belief that most attack vectors are due to the runtime rather than the application or its libraries, at least when it comes to servers, is less reality and more wishful thinking. The monolithic runtime in the JRE was both large and heavily studied, so there was a good stream of vulnerability reports, but that doesn't mean it was any less secure than your own application; it could have just felt that way because the application's security wasn't as well tested. I actually agree with that - most of those old applications probably only have security by obscurity. But still, there's a significant practical difference between "theoretically vulnerable" and "has a one-click prepackaged exploit". So encouraging every application to ship a static copy of the same chunk of well-known low-level code has a significant downsides - any vulnerability will become the equivalent of that zlib double free where essentially every MacOS program had to ship a new version.