On Tue, 30 May 2023 14:32:53 GMT, Weijun Wang <wei...@openjdk.org> wrote:
>> Added ability to load keystores from SST files on Windows. Example usage:
>>
>> KeyStore keyStore = KeyStore.getInstance("Windows-SST");
>> try (FileInputStream fis = new FileInputStream("mykeystore.sst")) {
>> keyStore.load(fis, null);
>> }
>>
>> Note that its not limited to file streams, it can be any stream.
>>
>> The feature is behind a runtime flag
>> ("sun.security.mscapi.keyStoreSSTSupport") as the KeyStore must have an
>> input stream, but the JCK tests assume an input stream is optional
>>
>> tier1 tests for linux/macos/Windows for x86_64
>
> I thought you meant this keystore to be read-only. What happens when
> set/delete/store is called?
@wangweij - the set and delete will modify the in memory store instance.
However as of now, the store is a nop - historically as setting/removing from
the MY/ROOT stores persists the changes (but not the case for in-memory stores
using SST).
So I see three ways forward, either (1) leave as is, (2) open the memory store
with CERT_STORE_READONLY_FLAG [exceptions will be thrown when trying to modify
the store] or (3) support persisting the store to an output stream.
(1) has value as it allows you to create in memory stores on Windows using
windows APIs (vs PKS etc)
(2) seems limited - but supports my customer needs
(3) expands beyond my current needs, but might offer the most flexibility
In cases (1) and (3): perhaps we should allow in-memory stores that don't need
to be loaded from SST, ie create them empty and available to update and
potentially persist
-------------
PR Comment: https://git.openjdk.org/jdk/pull/14187#issuecomment-1568665628
