Implement sunset policy handling with suppress and ignore options

[taoliult]

Added logic to handle restricted security profile sunset behavior using -Dsemeru.restrictedsecurity.suppresssunsetwarning and -Dsemeru.restrictedsecurity.ignoresunsetexpiration system properties.

When suppresssunsetwarning is true, all sunset warning messages are suppressed; if the profile is expired and
ignoresunsetexpiration is false, the JVM exits silently with status 1.

When suppresssunsetwarning is false. If the profile has expired and ignoresunsetexpiration is false, a fatal error is printed and the JVM terminates. If expired and ignoresunsetexpiration is true, a warning message is printed indicating uncertified cryptography may be active. If the profile will expire within six months, a generic warning message is printed.

[taoliult]

@keithc-ca Any review suggestions for this PR?

[keithc-ca]

Sorry, I have been very busy. I may not get to this today.

One of the things I noted, though, was the time to sunset is truncated down to a number of months, so it will complain (almost) a month sooner than it should.

[taoliult]

Sorry, I have been very busy. I may not get to this today.

One of the things I noted, though, was the time to sunset is truncated down to a number of months, so it will complain (almost) a month sooner than it should.

isPolicySunset() has been replaced by monthsToPolicySunset(). This new method returns how many months remain before the policy expires. We have a new requirement to begin printing a warning message 6 months before the expiration date.

I updated the code to round up the returned month count. For example, if there are 6 months + 29 days remaining, it will now return 7 instead of the previous 6.

[taoliult]

@keithc-ca Any review suggestions for this PR? We’re aiming to include it in the January release.

[keithc-ca]

Please update the commit message; the summary (first) line should be no more than 70 characters long.

[taoliult]

Please update the commit message; the summary (first) line should be no more than 70 characters long.

Updated.

[keithc-ca]

As I was reading the updated commit message, two things occur to me:

1. The behavior is not as described - e.g. using -Dsemeru.restrictedsecurity.suppresssunsetwarning does nothing (one would have to specify -Dsemeru.restrictedsecurity.suppresssunsetwarning=true instead.
2. This might be clearer and simpler if a single property were used - it eliminates the need to explain the priority of one property over the other. What do you think about updating this to recognize -Dsemeru.restrictedsecurity.sunsetpolicy=ignore and -Dsemeru.restrictedsecurity.sunsetpolicy=quiet? If the property is unset, or set to some other value the current behavior would apply.

[keithc-ca]

More concretely, I was thinking something like this:

        if ("ignore".equals(sunsetPolicy)) {
            return;
        }

        int expireMonths = monthsToPolicySunset(restricts.descSunsetDate);

        if (expireMonths <= 0) { // SunsetDate is in the past.
            if ("quiet".equals(sunsetPolicy)) {
                System.exit(1);
            }
            printStackTraceAndExit("The requested restricted security profile " + restricts.profileID
                    + " expired on " + restricts.descSunsetDate
                    + ": java will stop because certified cryptography use cannot be guaranteed."
                    + " Use -Dsemeru.restrictedsecurity.sunsetpolicy=quiet to stop displaying this message."
                    + " Use the -Dsemeru.restrictedsecurity.sunsetpolicy=ignore to allow java to start while"
                    + " possibly using uncertified cryptography.");
        } else if ((expireMonths <= 6) && !"quiet".equals(sunsetPolicy)) {
            System.err.println("The restricted security profile " + restricts.profileID
                    + " will expire on " + restricts.descSunsetDate
                    + ", after which java will fail to start if this profile is specified."
                    + " The latest Semeru Runtimes release may include an updated security profile.");
        }

[taoliult]

@keithc-ca

For the comment:

1. The behavior is not as described - e.g. using -Dsemeru.restrictedsecurity.suppresssunsetwarning does nothing (one would have to specify -Dsemeru.restrictedsecurity.suppresssunsetwarning=true instead.

I have updated the code so that specifying only: -Dsemeru.restrictedsecurity.suppresssunsetwarning or -Dsemeru.restrictedsecurity.ignoresunsetexpiration are now treated as true, which same as the behavior with the expectation described.

For the suggestion:

2. This might be clearer and simpler if a single property were used - it eliminates the need to explain the priority of one property over the other. What do you think about updating this to recognize -Dsemeru.restrictedsecurity.sunsetpolicy=ignore and -Dsemeru.restrictedsecurity.sunsetpolicy=quiet? If the property is unset, or set to some other value the current behavior would apply.

According to the design document
(https://github.ibm.com/runtimes/jit-crypto/issues/963#issuecomment-144354566), the implementation is required to support two separate JVM options, so I will keep the original design for these.

@jasonkatonica FYI.

[keithc-ca]

Please also rebase to avoid implicit merges

[taoliult]

Please also rebase to avoid implicit merges

Rebased and squashed.

[keithc-ca]

Jenkins test sanity amac jdknext

[keithc-ca]

Reopened eclipse-openj9/openj9#21732 for the test failure.

[keithc-ca]

Grinder https://openj9-jenkins.osuosl.org/job/Grinder/4854 failed.

[taoliult]

Grinder https://openj9-jenkins.osuosl.org/job/Grinder/4854 failed.

Updated TestProperties.java to skip the property-list test when OpenJCEPlusFIPS is not available.

[keithc-ca]

Only the test has changed since the previous build; it passed in https://openj9-jenkins.osuosl.org/job/Grinder/4857.