Codesigned Sublime Text Binaries

[tomveninga]

Problem description

The current Sublime binaries are not codesigned.
This is causing issues with Windows Information Protection policies as every binary is now accepted on hash base.
Every update to this binary causes the hash to change and a new policy to have to be created in order to access information protected content.

Preferred solution

All Sublime Text binaries signed with a code signing key from Sublime HQ so that the policy can be written on the 'publisher' instead of the hash.

Alternatives

The alternative would be to keep using the hashes.

Additional Information

An example of the sublime_text binary for this purpose:

PS C:\Program Files\Sublime Text> Get-AppLockerFileInformation .\sublime_text.exe | fl

Path : %PROGRAMFILES%\SUBLIME TEXT\SUBLIME_TEXT.EXE
Publisher :
Hash : SHA256 0x6B6B53AEDCDEE13A19D33363FF9ED48A1549463647567C93E12F5260F7AA911F
AppX : False

[BenjaminSchaaf]

You can view the signature of our binaries by right-clicking > properties > Code Signature. See:

[deathaxe]

Maybe the file in question is compromized?

Here's the result of ST4189 queried on Powershell 7.4.6 on Win11 23H2

4190 looks ok, too.

[deathaxe]

According to https://forum.sublimetext.com/t/build-4189-has-bad-signature/74876/6, if signatures were missing, they have been fixed in the meanwhile.

[BenjaminSchaaf]

@deathaxe That was only the Linux packages, and it wasn't that the signature was missing but that it was invalid.

[deathaxe]

This issue is about Windows, isn't it? OPs Get-AppLockerFileInformation command returns proper signature for both portable and installed versions of ST on my box.

[BenjaminSchaaf]

Yea, so the fix for the issue on the forum doesn't apply because that was purely related to Linux. Nothing was changed regarding the Windows binaries.

Still unclear what's going on here, so I think it's best to keep it open for now.