Re: RFR: 8280890: Cannot use '-Djava.system.class.loader' with class loader in signed JAR
On Tue, 1 Feb 2022 21:54:29 GMT, Sean Mullan wrote: > This fixes a bootstrapping issue if a custom system class loader is set with > the `-Djava.system.class.loader` option and the custom class loader is inside > a signed JAR. In order to load the custom class loader, the runtime must > verify the signed JAR first, and the algorithm constraint code tries to load > a `Locale` provider using a `ServiceLoader` before the class loader is set, > and this causes a `ServiceConfigurationError`. > > The fix removes a dependency from the security algorithm "denyAfter" > constraint parsing code on the `Calendar` API which uses a `ServiceLoader` > for gathering default locale information. Instead the `ZonedDateTime` API is > now used, which simplifies the code and removes some unnecessary code from > `keytool` as well. LGTM. - Marked as reviewed by weijun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7316
Re: RFR: 8280890: Cannot use '-Djava.system.class.loader' with class loader in signed JAR
On Tue, 1 Feb 2022 21:54:29 GMT, Sean Mullan wrote: > This fixes a bootstrapping issue if a custom system class loader is set with > the `-Djava.system.class.loader` option and the custom class loader is inside > a signed JAR. In order to load the custom class loader, the runtime must > verify the signed JAR first, and the algorithm constraint code tries to load > a `Locale` provider using a `ServiceLoader` before the class loader is set, > and this causes a `ServiceConfigurationError`. > > The fix removes a dependency from the security algorithm "denyAfter" > constraint parsing code on the `Calendar` API which uses a `ServiceLoader` > for gathering default locale information. Instead the `ZonedDateTime` API is > now used, which simplifies the code and removes some unnecessary code from > `keytool` as well. Marked as reviewed by hchao (Committer). Looks good to me. - PR: https://git.openjdk.java.net/jdk/pull/7316
Re: RFR: 8280890: Cannot use '-Djava.system.class.loader' with class loader in signed JAR
On Tue, 1 Feb 2022 21:54:29 GMT, Sean Mullan wrote:
> This fixes a bootstrapping issue if a custom system class loader is set with
> the `-Djava.system.class.loader` option and the custom class loader is inside
> a signed JAR. In order to load the custom class loader, the runtime must
> verify the signed JAR first, and the algorithm constraint code tries to load
> a `Locale` provider using a `ServiceLoader` before the class loader is set,
> and this causes a `ServiceConfigurationError`.
>
> The fix removes a dependency from the security algorithm "denyAfter"
> constraint parsing code on the `Calendar` API which uses a `ServiceLoader`
> for gathering default locale information. Instead the `ZonedDateTime` API is
> now used, which simplifies the code and removes some unnecessary code from
> `keytool` as well.
test/jdk/java/security/SignedJar/SignedJarWithCustomClassLoader.java line 65:
> 63:
> 64: // create signer's keypair
> 65: SecurityTools.keytool("-genkeypair -keyalg RSA -keystore ks " +
Hello Sean,
Looking at the `SecurityTools.keytool` and `SecurityTools.jarsigner` methods,
they internally launch a process corresponding to these tools but do not check
for the exit code of that process execution. Perhaps the calls to these methods
in this test, should add a check to assert that the exit code is `0` by using
the returned `OutputAnalyzer`?
-
PR: https://git.openjdk.java.net/jdk/pull/7316
Re: RFR: 8280890: Cannot use '-Djava.system.class.loader' with class loader in signed JAR [v2]
> This fixes a bootstrapping issue if a custom system class loader is set with > the `-Djava.system.class.loader` option and the custom class loader is inside > a signed JAR. In order to load the custom class loader, the runtime must > verify the signed JAR first, and the algorithm constraint code tries to load > a `Locale` provider using a `ServiceLoader` before the class loader is set, > and this causes a `ServiceConfigurationError`. > > The fix removes a dependency from the security algorithm "denyAfter" > constraint parsing code on the `Calendar` API which uses a `ServiceLoader` > for gathering default locale information. Instead the `ZonedDateTime` API is > now used, which simplifies the code and removes some unnecessary code from > `keytool` as well. Sean Mullan has updated the pull request incrementally with one additional commit since the last revision: Check exit status of keytool and jarsigner in test. - Changes: - all: https://git.openjdk.java.net/jdk/pull/7316/files - new: https://git.openjdk.java.net/jdk/pull/7316/files/914c8821..a52e5137 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7316&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7316&range=00-01 Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7316.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7316/head:pull/7316 PR: https://git.openjdk.java.net/jdk/pull/7316
Re: RFR: 8280890: Cannot use '-Djava.system.class.loader' with class loader in signed JAR [v2]
On Sat, 5 Feb 2022 11:48:12 GMT, Jaikiran Pai wrote:
>> Sean Mullan has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Check exit status of keytool and jarsigner in test.
>
> test/jdk/java/security/SignedJar/SignedJarWithCustomClassLoader.java line 65:
>
>> 63:
>> 64: // create signer's keypair
>> 65: SecurityTools.keytool("-genkeypair -keyalg RSA -keystore ks " +
>
> Hello Sean,
> Looking at the `SecurityTools.keytool` and `SecurityTools.jarsigner` methods,
> they internally launch a process corresponding to these tools but do not
> check for the exit code of that process execution. Perhaps the calls to these
> methods in this test, should add a check to assert that the exit code is `0`
> by using the returned `OutputAnalyzer`?
Good catch - fixed in latest update.
-
PR: https://git.openjdk.java.net/jdk/pull/7316
Re: RFR: 8280890: Cannot use '-Djava.system.class.loader' with class loader in signed JAR [v2]
On Sun, 6 Feb 2022 19:51:05 GMT, Sean Mullan wrote: >> This fixes a bootstrapping issue if a custom system class loader is set with >> the `-Djava.system.class.loader` option and the custom class loader is >> inside a signed JAR. In order to load the custom class loader, the runtime >> must verify the signed JAR first, and the algorithm constraint code tries to >> load a `Locale` provider using a `ServiceLoader` before the class loader is >> set, and this causes a `ServiceConfigurationError`. >> >> The fix removes a dependency from the security algorithm "denyAfter" >> constraint parsing code on the `Calendar` API which uses a `ServiceLoader` >> for gathering default locale information. Instead the `ZonedDateTime` API is >> now used, which simplifies the code and removes some unnecessary code from >> `keytool` as well. > > Sean Mullan has updated the pull request incrementally with one additional > commit since the last revision: > > Check exit status of keytool and jarsigner in test. Thank you for that change, Sean. Looks fine to me. - PR: https://git.openjdk.java.net/jdk/pull/7316
