The requirements on code signing certificates have recently changed, and it is no longer allowed to have the private key stored as a plain file: https://knowledge.digicert.com/generalinformation/new-private-key-storage-requirement-for-standard-code-signing-certificates-november-2022.html This was previously a requirement for EV certificates, but is now a requirement for every type. This complicates things for us, as we've tried to make everything self-contained within the build system. It would now have to be tied to some hardware device that severely limits where we can do signed builds. I'm also concerned about how well-supported the different hardware dongles are on Linux, given how mixed support for Linux is in the smart card ecosystem. Fortunately, there appears to be the option of storing the private key "in the cloud". The signature operations are then done via an API. Multiple CAs provide this as an add-on service, but Google also has an independent service called "Cloud Key Management". And multiple are providing PKCS#11 libraries, with Linux support, as a way to access these. Putting the key in a network resource is not an issue as we already required network access for signing as we need to access public time signing servers. So, the problem then becomes whether those PKCS#11 libraries will work in our build environment. The best odds for that should be Google's library, as it is open source. It does require Bazel to build, though.
For reference, Google's library lives in this repo: https://github.com/GoogleCloudPlatform/kms-integrations
I compared the outcome of the behavior when trying to install the ThinLinc client on Windows 10 and Windows 11. Test1. I downloaded the client-bundle.zip using sftp to the Windows 10 and Windows 11 machines in the lab | Build | Signed | |------------------------------|---------------------- | 1| Jenkins tl-4.14.0post | Yes, but invalid cert | |------------------------------|---------------------- | 2| alex tl-4.14.0post | Unsigned | |------------------------------|-----------------------| 3| tl-4.14.0-client-windows.exe*| Yes. Expired cert. | 1 & 2: Windows10/11 popups "Do you want to allow this app from an unknown publisher to make changes to your device?" with yellow header, indicating that this app comes from an uknown publisher. Providing the admin user and password let's the user continue with the installation 3: Same as above, but the publisher is known, and the phrasing is a bit different in the popup: "Do you want to allow this app to make changes to your device". The popup also shows information about the publisher: "Verified publisher: Cendio Aktiebolag". Also the header is blue. Providing the admin user and password let's the user continue with the installation. Test2 Downloading the same bundles but over the web. This is how the users will obtain the client bundle. 1 & 2: Windows10/Windows11 know presents smartscreen popup: "Windows protected your PC. Microsoft Defender SmartScreen prevented an unrecognized app from starting. Running this app might put your PC at risk. More info" The user is presented with a single button, "Don't run" unless clicking "More info" and then clicking "Run anyway". Then it continues with presenting the same dialogs as 1 & 2 in Test 1
Created attachment 1130 [details] UAC_Yellow
Created attachment 1131 [details] SmartScreen
Created attachment 1132 [details] UAC_Blue_Verified_Publisher
One hope we had was that, by uploading our client to Microsoft Store, that client would automatically be signed by Microsoft. Unfortunately, that is not the case. We get the yellow smart screen warning for the Microsoft Store client as well.
