3 ms·

Awesome, you now have a private fork! You the application developer now know your code isn't portable with the library! The JVM also can do its optimizations wi

by vips7L 2y ago

Awesome, you now have a private fork! You the application developer now know your code isn't portable with the library! The JVM also can do its optimizations without having integrity change from under its feet at runtime! Win win!

mdaniel 2y ago
Ok, I hear you, so let's mandate that every class have a .gpg signature to really double down on integrity. The JVM should have to have every gpg public key registered as a Trusted Platform Module Author. Win win on how sekure everything will be, and I can always resign every class with my .gpg signature. That really sounds like a win for the day-to-day Java developer, doesn't it? I'm sure that would never cause weird errors in day to day work just to address some niche audience who is really, really into chain of trust The point I'm making is that I don't understand for the life of me whose problem this egregiously disruptive change is solving outside of the NSA, who I'm sure have their own JVM builds and can leave the rest of us out of it
- vips7L 2y ago
  Again I think you have a deep misunderstanding of how this works. This puts control into the hands of the everyday application developer! It ensures that the application developer knows what correctness, portability, and integrity guarantees their program has.
- pron 2y ago
  You're thinking about security, and this enhancement is about integrity. The idea is simply that some third-level dependency won't be able to make global changes to the program -- like making it non-portable (i.e. not allowing the upgrade of the JDK) -- without the application knowing about it. This is a brand new functionality that solves the problem that led to the 8 -> 9+ migration pain (and I hope you'll agree that was a relatively big problem). Integrity is also a prerequisite to writing any security mechanism in any layer of the code that is less prone to accidental vulnerabilities in a third-level dependency, and it's also a prerequisite to performance optimisations. For example, if Java strings were immutable, the compiler would be able to optimise some operations on them. Except it can't because even thought they're almost always immutable, some third-level dependency may decide to mutate one string in the program, and because of that the compiler can't optimise any. Such new and powerful functionality is indeed disruptive (in a good way), and all it demands is that libraries that need to, say, mutate Java strings or final fields let the application know so it could add a flag (if it's willing to take the portability/performance/security risks involved). That's it.

by vips7L 2y ago

mdaniel 2y ago

Ok, I hear you, so let's mandate that every class have a .gpg signature to really double down on integrity. The JVM should have to have every gpg public key registered as a Trusted Platform Module Author. Win win on how sekure everything will be, and I can always resign every class with my .gpg signature. That really sounds like a win for the day-to-day Java developer, doesn't it? I'm sure that would never cause weird errors in day to day work just to address some niche audience who is really, really into chain of trust The point I'm making is that I don't understand for the life of me whose problem this egregiously disruptive change is solving outside of the NSA, who I'm sure have their own JVM builds and can leave the rest of us out of it

vips7L 2y ago
Again I think you have a deep misunderstanding of how this works. This puts control into the hands of the everyday application developer! It ensures that the application developer knows what correctness, portability, and integrity guarantees their program has.
pron 2y ago
You're thinking about security, and this enhancement is about integrity. The idea is simply that some third-level dependency won't be able to make global changes to the program -- like making it non-portable (i.e. not allowing the upgrade of the JDK) -- without the application knowing about it. This is a brand new functionality that solves the problem that led to the 8 -> 9+ migration pain (and I hope you'll agree that was a relatively big problem). Integrity is also a prerequisite to writing any security mechanism in any layer of the code that is less prone to accidental vulnerabilities in a third-level dependency, and it's also a prerequisite to performance optimisations. For example, if Java strings were immutable, the compiler would be able to optimise some operations on them. Except it can't because even thought they're almost always immutable, some third-level dependency may decide to mutate one string in the program, and because of that the compiler can't optimise any. Such new and powerful functionality is indeed disruptive (in a good way), and all it demands is that libraries that need to, say, mutate Java strings or final fields let the application know so it could add a flag (if it's willing to take the portability/performance/security risks involved). That's it.