On Wed, 24 Jan 2024 00:41:15 GMT, Mat Carter <maca...@openjdk.org> wrote:

>> This fixes the defect described at 
>> https://bugs.openjdk.org/browse/JDK-8313367
>> 
>> If the process does not have write permissions, the store is opened as 
>> read-only (instead of failing).
>> 
>> Please note that permissions to use a certificate in a local machine store 
>> must be granted - in a management console, select a certificate, right-click 
>> -> All tasks... -> Manage Private Keys... -> add Full control to user.
>
> Please enable github actions so that minimal tier1 jtreg tests are run; as 
> you're changing the behavior of KeyStore.load (for SunMSCAPI) you should 
> really test that all available write operations fail as expected (as they did 
> before this change).

@macarte :  In your [comment on 
JDK-8313367](https://bugs.openjdk.org/browse/JDK-8313367?focusedId=14643246&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14643246),
 you suggest that perhaps "this is a feature request".   What do you mean by 
that?  

[JDK-6782021](https://bugs.openjdk.org/browse/JDK-6782021) provides the 
Microsoft CNG interface for an OpenJDK application, such as jarsigner.exe, to 
function as a native Windows application when integrated with something like 
[Azure Key Vault](https://learn.microsoft.com/en-us/azure/key-vault/).   On a 
secure system, by the [principle of least 
privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege), the 
following accesses would inhibit a bad actor from committing code signing 
forgery:

  1)  Builder user access:
        a)  Code signing authorization
        b)  Read-only access to the Local Computer keystore.
        c)  No membership in the local Administrators group.

  2)  System admin access:
        a)  No code signing authorization
        b)  Read-write access to the Local Computer keystore.
        c)  Membership in the local Administrators group

These accesses provide complete, unambiguous separation of roles.  A user with 
dual roles must remain vigilant to accurately simulate a production environment 
when verifying this fix.  Code signing authorization would be assigned, for 
example, by a key vault admin.  A system admin privilege is not also needed.   
So, for this test, an elevation prompt should be seen as a red flag.

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

PR Comment: https://git.openjdk.org/jdk/pull/16687#issuecomment-1977530357

Reply via email to