[13] RFR 8228431: sun/security/tools/jarsigner/PreserveRawManifestEntryAndDigest.java fails intermittently on solaris

[Philipp Kunz]

Hi Max,

While it's nice to see that your fix works around the problem, this
does not look like the final remedy. I'm also quite surprised that only
PreserveRawManifestEntryAndDigest should be affected whereas a number
of other tests use the same kind of signing. With some luck, that
PreserveRawManifestEntryAndDigest test helps with a hint to find the
actual root cause. I have a gut feeling somehow that the problem here
might not only affect tests and I'd rather opt for filing another bug
now, which may as well be investigated and solved later and
independently.

As the patch looks now, the resulting code will not mention that the
"security.provider" settings were introduced only for solaris. The next
poor guy who reads it will wonder why it is there and not understand.
Perfect would be a reference to a bug probably yet to be created as
already suggested or otherwise I'd welcome to see at least a comment
with some explanation of what we currently know.

Regards,
Philipp


On Fri, 2019-07-26 at 22:57 +0800, Weijun Wang wrote:
> Please review the fix at
> 
>    http://cr.openjdk.java.net/~weijun/8228431/webrev.00/
> 
> The no-native-provider.conf file put SUN and SunRsaSign as the first 2 security providers and thus shadows the OracleUcrypto and SunPKCS11 providers used by Solaris. Please note that duplicated provider names are silently ignored so this is harmless. On other platforms, the first 2 providers are already SUN and SunRsaSign.
> 
> I ran the test 200 times on solaris-sparcv9 and it does not fail once. Before this fix, it always fails on this platform.
> 
> An alternative fix is to simply exclude the test from solaris-sparc using `@requires os.family != "solaris"`. I've fixed some other security/tools test failures using this solution. The reason is that these tests are testing platform-independent behaviors so it's OK to skip one platform. I don't think this test is platform-dependent in any way.
> 
> Thanks,
> Max
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20190728/198604b0/attachment.htm>