[jdk8u-dev] RFR: 8195607: sun/security/pkcs11/Secmod/TestNssDbSqlite.java failed with "NSS initialization failed" on NSS 3.34.1

[Severin Gehwolf]

On Fri, 19 Aug 2022 02:50:19 GMT, Martin Balao <mbalao at openjdk.org> wrote:

> The 11u backport applies cleanly, once paths are fixed.

Yes, that seems to be the case if https://github.com/openjdk/jdk8u-dev/pull/106/commits/73173863ab9da7ee2ec080401180475bf7ee22e1 is to be looked at on its own.
 
> To minimize risks, I manually debugged the OpenJDK code that connected to an NSS DB using the sql: prefix and everything was as expected.

OK.

> I also run all the tests under the jdk/sun/security/pkcs11 category and noticed no-regressions strictly related to this fix. The test 'jdk/sun/security/pkcs11/Secmod/TrustAnchors.java' requires a special note, though. This test passes if run standalone but fails when run as part of a group. The reason is because when run as part of a group, other tests copy the file 'pkcs11.txt' to the temporary nssdb directory which is shared between all of them. This DB does not register the trust anchors module called 'Builtin Roots Module', which was available in the old secmod.db and is required by the test (which expects to see a Secmod$Module of TRUSTANCHOR type). While the test leaves the sun.security.pkcs11.SecmodTest::useSqlite field set to false and tries to access the legacy DB (also contained in the shared temporary nssdb directory), NSS realizes that there is a new SQLite DB in the same directory and reads the configuration from pkcs11.txt. Otherwise, if pkcs11.txt does not exist (as 
 when the test is run standalone), it creates one with the information in secmod.db and it registers the 'Builtin Roots Module' module. All these findings have been verified with the 'modutil -list' command. While the issue is unrelated to what JDK-8195607 fixes, it has been uncovered by the existence of the pkcs11.txt file introduced with this change.
> 
> Why newer releases are not affected? Because jtreg runs tests (including TrustAnchors.java) in separated directories, so they don't share the nssdb temporary directory. In newer releases, TEST.ROOT has a requiredVersion attribute [1] indicating to jtreg that this can be done [2].
> 
> I've analyzed several ways to fix this issue but the one that I'd like to propose is to clean up the temporary nssdb directory for every test and avoid conflicts, giving every test the isolation that jtreg does when it sets test.classes uniquely per test in newer JDK releases.

This seems strange, wouldn't a jtreg version `> 4.2 b08` not run into this problem? I.e. if I run with jtreg 5 (oldest version I have here), I wouldn't see this issue? If so I'm not sure this is worth adding https://github.com/openjdk/jdk8u-dev/pull/106/commits/22c1df05d2ab51a400ebdc69566e84fdaf32efec to this backport. It's not in head either. So at the very least this should be an 8u-only bug. But if that's only happening with jtreg 4, I'd say this is not worth fixing at all (or perhaps add jtreg 5 as a minimal version. Everyone should be on newer versions these days anyway.

-------------

PR: https://git.openjdk.org/jdk8u-dev/pull/106