On Thu, 14 Mar 2024 15:53:23 GMT, Weijun Wang <wei...@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.
>
> I also noticed a different problem. No matter if privileged or unprivileged, 
> `keytool -genkeypair -storetype Windows-My-LOCALMACHINE` works successfully 
> but the entries are actually created in Windows-MY-CURRENTUSER. This is 
> unrelated to this code change and I filed 
> https://bugs.openjdk.org/browse/JDK-8328184.

@wangweij - Regarding your test environment issues:

Your Windows 2016 systems needs its UAC enabled.   Here is an MS Community 
remedy for that:
[cmd.exe always runs as Administrator, how do I make it 
stop?](https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&cad=rja&uact=8&ved=2ahUKEwiT4bLQrIiFAxW0M1kFHQTrCVMQrAIoAHoECDkQAQ&url=https%3A%2F%2Fanswers.microsoft.com%2Fen-us%2Fwindows%2Fforum%2Fall%2Fcmdexe-always-runs-as-administrator-how-do-i-make%2F63ac20c1-f1a3-4876-8199-cc02c6a5725d&usg=AOvVaw0nipY6czBotcTThwVvaWjv&opi=89978449)

With UAC enabled, you can switch between your user and administrator roles as a 
developer would.  In a secured production environment, by contrast, that is not 
allowed.    Instead, roles are performed by separate users who are assigned the 
minimum accesses required due to their respective roles.   The primary end user 
is a build engineer or automated process (_This is like the "java app" 
described in the Jan 17 reply by @rebarbora-mckvak ._) responsible for writing 
a code signature to a local file.  And, since that user would never create or 
install the local code signing certificate, read-only access is assigned.

-------
The unexpected signtool error for Step 2 is likely caused by using signtool's 
"/i" option to locate the certificate in the Windows keystore.   For 
repeatability across configurations, you should instead use the "/sha1" option 
which takes the code signing certificate's thumbprint value.   To retrieve the 
thumbprint:

1. Run the elevated MMC as before and navigate to "Local Computer / Personal / 
Certificates".
2. Double click the certificte, and click the Details tab.
3. Scroll to the bottom and click the Thumbprint field.
4. Copy the Thumbprint string that appears in the client area (a long hex 
string).
5. Paste it to your command line or script.

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

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

Reply via email to