JEP 411: Disable warning message with flag?

[Ron Pressler]

The deprecation warnings serve three purposes:

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.

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?

On a separate note, I found your previous emails about your SM use-case
particularly interesting. Even though it falls under the sandbox category,
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. 

I hope that you continue to provide such useful feedback as we explore the 
degradation process and seek alternatives for particular use-cases.

— Ron

> On 31 May 2021, at 17:45, Chapman Flack <chap at anastigmatix.net> wrote:
> 
> On 05/31/21 11:51, Mikael Sterner wrote:
>> For the record, I want to point out that the latest revision to the
>> JEP 411 draft didn't solve the issue highlighted below, since applications
>> embedding a Java runtime still would not be able to suppress the warning
>> 
>> On Fri, May 21, 2021, at 19:33, Mikael Sterner wrote:
>>> ...
>>> I would suggest adding a flag to disable the warning message, for use 
>>> in cases where an application ships to end users with a Java runtime 
>>> included. Because in those cases, the warning is meant for the 
>>> developer of the application and not end users. End users would not be 
>>> the ones providing/upgrading the Java runtime, and in many cases it 
>>> would not be acceptable to have a warning displayed on startup that 
> 
> I was just composing a message to the same effect, for a slightly different
> use case.
> 
> The module I maintain for the PostgreSQL RDBMS will simply have to continue
> using the deprecated API for the near future. I will need to do a minor
> release that deals with the deprecation and the needed invocation flags,
> and handles warning its users in a context-appropriate way that is
> meaningful to them and explains how the future is going to look.
> 
> I will then need to use the time available during 17's support lifetime
> to work on a heavily-reengineered major release of the module that will
> meet its requirements through some other mechanism.
> 
> In the meantime, users of PostgreSQL with this module installed will
> derive absolutely zero benefit from having their RDBMS logs spammed
> with an obscure warning from Java that they can do nothing about
> every time a DB connection loads the module.
> 
> I can suggest a couple approaches. One would be to make sure the warning
> is delivered via the vfprintf hook. As I am using the invocation API to
> start the JVM, I can use the hook to eat the message. This might not serve
> others' needs though.
> 
> Another would be to add another -Djava.security.manager value,
> allow-until-degraded. In 17, that would be treated as allow, but with
> the warning suppressed. In 17+n, wherever functional degradation starts,
> it should become equivalent to disallow.
> 
> In essence, if I have taken the explicit step of doing a release that
> adds allow-until-degraded, that is a handoff of responsibility to me.
> It is now up to me to make sure that users of this module are advised
> in an appropriate way of what's going down, and it is up to me to make
> sure what will happen in 17+n is reasonable (in my case, it will have to
> say "can't run functions of PostgreSQL's TRUSTED variety, unless you
> back up to Java < 17+n, or move to the next major version of this module").
> If I don't handle that responsibility, then it just stops working in 17+n
> because the flag becomes equivalent to disallow. But by using that flag,
> I have clearly accepted that responsibility.
> 
> Meanwhile, users of the RDBMS don't get their logs uselessly spammed.
> 
> Another ingredient that would help is to be a little less vague about
> the future "degradation", but commit to one easily-detected "degradation"
> that will happen no later than any other. Maybe it could be
> getSecurityManager()=null, for example, which is easier to test than
> whether doPrivileged() has no ACC effect.
> 
> That way, without needing a crystal ball to know in which release 17+n
> the degradation will start, I can already issue a release in advance
> that will detect and handle it gracefully when it happens.
> 
> Regards,
> -Chap