On 05/31/21 14:58, Ron Pressler wrote: > However, if the warning were emitted just once, at startup, if the > “allow” value is given rather than on each SM installation, would that > reduce the warning noise for you?
In my case not at all, because only one SM is ever installed per process, at startup. But a PostgreSQL installation can start processes rather frequently. (This is a case where it works better to select JVM options that are more client-like than server-like; there is not one long-lived 'server' JVM.) > 1. Help software maintainers know about the deprecation. > 2. Help software users (the more tech-literate ones, those who look at logs) > know when the software they use has properly addressed the issue. > 3. Help us better gauge, however imperfectly and indirectly, the impact of the > deprecation process, and focus us on the more common and impactful uses of > the Security Manager. > > While a flag to suppress warnings doesn't harm goal 1, it severely harms > goals 2 and 3. In my case, goal 2 will be better served by the software users getting release notes from me, and specific warnings generated by my code, speaking directly to their use of PostgreSQL and PL/Java and how that will have to evolve. Therefore I would like an option that says "I'm on it. Please be quiet for now, and go ahead and break in 17+n if I haven't provided my own graceful degradation response for that case by then." Really, my intention is to build the graceful degradation response right now, into the same minor release that will add the option. So even if I fall down a manhole between now and 17+n, the code will be ready for that event anyway. The graceful degradation will have to be a message (again from my code) saying "the fateful Java 17+n has arrived, your functions marked trusted are no longer allowed to run, unless you set this new database option indicating you don't mind them running unrestricted--or revert to Java 17+n-1, or upgrade to the new PL/Java major release that ideally Chap pushed out before falling down that manhole." Naturally, if you provide such an option for my use, it might also get used by the maintainer of package X who just doesn't like looking at the warning, and won't do anything further, and package X will have a train wreck when 17+n arrives. But as long as it's an opt-in option that is clearly so documented, and that maintainer deliberately pushes a commit that adds it, that seems fair. I am not sure what you are getting at with goal 3. Will the warning phone home? > we might consider keeping some hooks that would allow third-parties to create > sandboxing solutions that might be satisfactory, if we’re able to find a good > cost/benefit sweet-spot. Thank you for that. One question I have been wondering about: do you have any internally-tracked metrics that you can share about how many uses of doPrivileged there are in the JDK codebase, and perhaps even a histogram of the stack depth from the doPrivileged down to the affected checked operation(s)? It would be good news if a lot of those are shallow, as in "the checked operation that I know to be taint-free is this one right here that I am wrapping this doPrivileged around." (I'm sure that has always been desirable from a code-review standpoint anyway.) It could also be useful to partition the data according to whether the affected checked operation is something with a real external effect (filesystem, socket, process, thread, ...?), or is something that only had to be checked in the pre-JPMS-encapsulation days in order to fend off circumvention of the policy. I am also sort of wondering what's to become of some of the familiar known rules in the post-SM world. Will getClassLoader() become always allowed, whether the loader is an ancestor or not? Will setContextClassLoader() be a free-for-all? checkGuard()? ...? Is it confidently believed that the JPMS encapsulation suffices for integrity enforcement and non-circumvention with all of those former familiar rules relaxed? Regards, -Chap
