5 ms·

As an application developer I love these changes. I do not want some library calling out to architecture specific binaries without me knowing. I want to have to

by vips7L 2y ago

As an application developer I love these changes. I do not want some library calling out to architecture specific binaries without me knowing. I want to have to enable that for them so I know that my application is portable. I do not want random code outside of my package to be able to reflect on my class and pull data out of a private variable or set its data breaking any type of encapsulation or rules I have written.

cempaka 2y ago
And I don't want the JVM hamstrung from a whole host of optimizations because this random stuff could be happening at any point.
- LegionMammal978 2y ago
  Any general-purpose JVM is already going to have JNI entry points which bypass privacy. They can certainly restrict JNI as a whole and make users jump through hoops to enable it, but they're not going to be tearing it out for a long, long time.
mdaniel 2y ago
> I do not want random code outside of my package to be able to reflect on my class and pull data out of a private variable or set its data breaking any type of encapsulation or rules I have written. You have a very strange threat model given how stunningly trivial it is to decompile .class files I'm with you on the JNI but I am not willing to "baby with the bathwater" the Reflection API just avoid having to check the bytecode for Runtime.loadLibrary
- thfuran 2y ago
  How is decompiling the bytecode relevant? The issue isn't hiding secrets in the code, it's the application breaking at runtime due to violating invariants or assumptions.
  - mdaniel 2y ago
    private java.security.PrivateKey _key; $ java -jar cfr.jar ... $ sed -i"" -e s/private/public/g $(find . -name "*.java") $ javac ... and now Reflection doesn't need setAccessible and your threat model of "but my field is private!!11" has gone poof
    - 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.
- vips7L 2y ago
  > You have a very strange threat model given how stunningly trivial it is to decompile .class files I don't see how this is relevant. I'm talking at runtime. If I have a class: class Point { private final int x; private final int y; Point(int x, int y) { if (x < 0) throw new IllegalArgumentException("x less than 0"); if (y < 0) throw new IllegalArgumentException("y less than 0"); this.x = x; this.y = y; } } You should not be able to use reflection to remove the private-ness of my field to set Y to -42, unless you are code within my module that I control.
  - Zambyte 2y ago
    Serious question - why not?
    - le-mark 2y ago
      That would only would be an issue if there is untrusted code running in the same jvm. The security manager was a really difficult way to stop this. Another approach I’ve used is to scan the jar and disallow all but whitelisted classes in the bytecode. Worked well.
      - pron 2y ago
        It really isn't. Most security problems are caused by accidental vulnerabilities in trusted code, which is far more risky than untrusted code. (Untrusted code is really easy to deal with -- you just run it in a sandbox; it's trusted, benevolent, well-meaning code you should be afraid of.) But security is just a small part of the problem. Remember all the breakages people had upgrading from 8 to 9+? Virtually all of them were do to libraries reaching into internals that then changed. If no internal method could change because someone might be relying on it then the platform can't evolve. If an application author cannot know which of her dependencies may be non-portable, they can't weigh the risk. Yet another problem is optimisations. We can't optimise code if any dependency can freely decide to change the meaning of any line of code in the program.
    - rectang 2y ago
dxxvi 2y ago
Do you think you're like Apple: not allowing people to fix their phones, laptops ...?
- Pet_Ant 2y ago
  I don’t want the community hijacking my library by fossilizing some implementation detail. If you want to fork it, own it and do it, but don’t force that on me by using something you weren’t meant to and then bitch and moan when I break your code by changing some detail.
  - zdragnar 2y ago
    You can make that argument either way. People will always complain about the decisions you make and the ones you don't. The semantics of encapsulation are sufficient. Anyone who breaks them knows it's on them, and if they don't, they certainly should have. It's not worth sweating all the maybes and what-ifs.
    - vips7L 2y ago
      > Anyone who breaks them knows it's on them, and if they don't, they certainly should have. I agree, the issue arises when library developers make this decision and application developers have to deal with the fall out of that. Application developers need to know when things like this happen.
      - zdragnar 2y ago
        So use an older version of the library, or stop using the library, or work around it. Libraries with such bad behavior are going to be infrequently used, or abandoned quickly regardless.
- vips7L 2y ago
  I don't see how this is relevant. This purely puts control into the hands of application developers. It lets them know exactly what correctness, portability, and integrity guarantees their application has. The application developer STILL can "fix their phone", but they have to enable it at the command line. It pevents library developers from making decisions for application developers without them knowing.

by vips7L 2y ago

cempaka 2y ago

And I don't want the JVM hamstrung from a whole host of optimizations because this random stuff could be happening at any point.

LegionMammal978 2y ago
Any general-purpose JVM is already going to have JNI entry points which bypass privacy. They can certainly restrict JNI as a whole and make users jump through hoops to enable it, but they're not going to be tearing it out for a long, long time.

mdaniel 2y ago

> I do not want random code outside of my package to be able to reflect on my class and pull data out of a private variable or set its data breaking any type of encapsulation or rules I have written. You have a very strange threat model given how stunningly trivial it is to decompile .class files I'm with you on the JNI but I am not willing to "baby with the bathwater" the Reflection API just avoid having to check the bytecode for Runtime.loadLibrary

thfuran 2y ago
How is decompiling the bytecode relevant? The issue isn't hiding secrets in the code, it's the application breaking at runtime due to violating invariants or assumptions.
- mdaniel 2y ago
  private java.security.PrivateKey _key; $ java -jar cfr.jar ... $ sed -i"" -e s/private/public/g $(find . -name "*.java") $ javac ... and now Reflection doesn't need setAccessible and your threat model of "but my field is private!!11" has gone poof
  - 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.
vips7L 2y ago
> You have a very strange threat model given how stunningly trivial it is to decompile .class files I don't see how this is relevant. I'm talking at runtime. If I have a class: class Point { private final int x; private final int y; Point(int x, int y) { if (x < 0) throw new IllegalArgumentException("x less than 0"); if (y < 0) throw new IllegalArgumentException("y less than 0"); this.x = x; this.y = y; } } You should not be able to use reflection to remove the private-ness of my field to set Y to -42, unless you are code within my module that I control.
- Zambyte 2y ago
  Serious question - why not?
  - le-mark 2y ago
    That would only would be an issue if there is untrusted code running in the same jvm. The security manager was a really difficult way to stop this. Another approach I’ve used is to scan the jar and disallow all but whitelisted classes in the bytecode. Worked well.
    - pron 2y ago
      It really isn't. Most security problems are caused by accidental vulnerabilities in trusted code, which is far more risky than untrusted code. (Untrusted code is really easy to deal with -- you just run it in a sandbox; it's trusted, benevolent, well-meaning code you should be afraid of.) But security is just a small part of the problem. Remember all the breakages people had upgrading from 8 to 9+? Virtually all of them were do to libraries reaching into internals that then changed. If no internal method could change because someone might be relying on it then the platform can't evolve. If an application author cannot know which of her dependencies may be non-portable, they can't weigh the risk. Yet another problem is optimisations. We can't optimise code if any dependency can freely decide to change the meaning of any line of code in the program.
  - rectang 2y ago

dxxvi 2y ago

Do you think you're like Apple: not allowing people to fix their phones, laptops ...?

Pet_Ant 2y ago
I don’t want the community hijacking my library by fossilizing some implementation detail. If you want to fork it, own it and do it, but don’t force that on me by using something you weren’t meant to and then bitch and moan when I break your code by changing some detail.
- zdragnar 2y ago
  You can make that argument either way. People will always complain about the decisions you make and the ones you don't. The semantics of encapsulation are sufficient. Anyone who breaks them knows it's on them, and if they don't, they certainly should have. It's not worth sweating all the maybes and what-ifs.
  - vips7L 2y ago
    > Anyone who breaks them knows it's on them, and if they don't, they certainly should have. I agree, the issue arises when library developers make this decision and application developers have to deal with the fall out of that. Application developers need to know when things like this happen.
    - zdragnar 2y ago
      So use an older version of the library, or stop using the library, or work around it. Libraries with such bad behavior are going to be infrequently used, or abandoned quickly regardless.
vips7L 2y ago
I don't see how this is relevant. This purely puts control into the hands of application developers. It lets them know exactly what correctness, portability, and integrity guarantees their application has. The application developer STILL can "fix their phone", but they have to enable it at the command line. It pevents library developers from making decisions for application developers without them knowing.