Yeah, this is not the right place for this rant. But was curious what the River community thinks about it.
Michał > On 30 Apr 2021, at 17:59, Jeremy R. Easton-Marks <j.r.eastonma...@gmail.com> > wrote: > > Hi Michal, > I think you should definitely share your opinions about this ( > https://bugs.openjdk.java.net/browse/JDK-8264713). I think they may not > know about Apache River and they probably should address the issues around > dynamically loaded code. I would cite other Java examples other than just > River. Android is able to operate without the Java Security Manager and > maybe the JDK should look into adopting the Android way. > > > >> On Fri, Apr 30, 2021 at 4:38 AM Michał Kłeczek <mic...@kleczek.org> wrote: >> >> >> >>> On 30 Apr 2021, at 04:42, Jeremy R. Easton-Marks < >> j.r.eastonma...@gmail.com> wrote: >>> >>> I'm not sure how much JEP 411 will impact River. I agree with the overall >>> direction that it proposes in removing the security manager. >> >> IMHO JEP 411 gives unconvincing reasons to ditch SecurityManager: >> >> - brittle permission model >> This one is really well summarized in the same paper: The Security Manager >> does not allow negative permissions that could express "grant permission >> for all operations except reading files”. >> >> Why not fix that??? Especially that it has been done before: >> https://github.com/olukas/pro-grade >> >> - poor performance >> Why not fix that??? Especially that it has been done before by… yes - >> Apache River (thanks Peter!). >> >> - difficult programming model >> This one is difficult to sensibly assess without comparing alternatives. >> Simply speaking: security is difficult - there is no free lunch. >> >> Example from the document (ie. client code needs to be granted permissions >> required by library code if doPrivileged is not used) has it completely >> backwards as that’s the whole point of stack walking based security: avoid >> confused deputee issue. >> >> It also looks like there is another huge misconception in the industry: >> "running untrusted code on the server is a big no-no and once you only run >> trusted code SecurityManager is not needed anymore”. >> The point really is: there is no such a thing as “trusted code” - that’s >> illusion. See for example: https://news.ycombinator.com/item?id=26087064 >> >> Similar misconception: one should avoid dynamically loaded code (or even >> from the JEP 411 itself: nobody is interested in dynamically loaded code). >> Well… Docker images _are_ dynamically loaded code. >> And k8s or Helm yaml descriptors defining what this dynamically loaded >> code can access are by no means simpler than security policy files. Quite >> the opposite. >> >> >>> However, I am >>> worried that removing security features is going to cause some other >>> problems in the Java ecosystem. Beyond the potential impact of River. >>> >>> I do think what affect it will have on Apache River should be explored. >>> >>> I am of the opinion that Apache River should look beyond just being a >> Java >>> only project and that we may need to rethink the way that we approach >>> building distributed systems. >> >> Killing mobile code is killing Apache River as IMHO that’s the defining >> feature of it. >> >> The question is whether killing SecurityManager is killing mobile code. >> >> Regards, >> Michal >> >> > > -- > Jeremy R. Easton-Marks > > "être fort pour être utile"
