Vincent Parrett

I have never seen it used and couldn't really find any doco on it either, but since they were easy to implement we added it anyway 🤷‍♂️

We'll look at this. I haven't seen any api's to make this easy, so will likely have to resort to manipulating the PE file. That said, if you sign without using the -as option I think it will replace the existing certificate - I will have to test that. We are planning on adding a timestamp command but that is not yet implemented (mostly because we haven't gotten to it yet). Should be simple to add - I had it in there originally but couldn't figure out why it would be needed - signtool doco doesn't say much We went around in circles with this, we needed something unique to identify the certificate - IssuedTo/SubjectName is not unique if more than one token is enabled (ie old cert and new cert). I'll talk to the lead dev about this when he is back from vacation next week - I did the initial r&d and then handed the project off to another dev to make it into a product and this is one of the areas he worked on. Thanks for the feedback.

Be aware that most of those cloud based services either charge per signing or impose monthly limits on the number of signings.

Timestamping happens on the client - just like with signtool, you specify the timestamp server url and digest algorithm - we caclulate the file digest, send that to the server, get back the signed digest/signature etc, apply that the the file and then perform the timestamp operation (simplified - quite a bit to it in reality). This is the command line interface (subject to change) We are using Signotaur to sign itself, here's an extract from the build log - running the sign command "C:\Program Files\VSoft Technologies\Signotaur\ClientTool\SignotaurTool.exe" sign --apikey ********** --thumbprint 56DFCD0B0C37DD1B9AB75FFCAB6627745E6E93B6 --signServer https://ciagent005:91 --file-digest SHA384 --tr http://timestamp.digicert.com --td SHA256 --allow-untrusted E:\CI_AWS\Ws\18154\Output\**\*.exe" and the output (logging needs some tuning). SignotaurClient Version : 1.0.0.182 © 2024 VSoft Technologies Pty Ltd 12:19:33 Fetching public key 12:19:33 Sending sign request to server... 12:19:36 Server responded : "Digest Signed OK" 12:19:36 "E:\CI_AWS\Ws\18154\Output\Client\win-x64\SignotaurTool.exe" signed. 12:19:36 Sending sign request to server... 12:19:38 Server responded : "Digest Signed OK" 12:19:39 "E:\CI_AWS\Ws\18154\Output\Server\win-x64\VSoft.Signotaur.Server.exe" signed. 12:19:39 Sending sign request to server... 12:19:41 Server responded : "Digest Signed OK" 12:19:41 "E:\CI_AWS\Ws\18154\Output\Server\win-x64\VSoft.SSLCertificate.Tool.exe" signed. 12:19:41 Returning result code: 0. 12:19:41 Result from Windows signing API "Operation successful." Exit code: 0 So signing and timestamping takes around 1-3 seconds per file (depends on file size etc).

Thanks - yeah we spent a lot of time looking for a name that was relatable and googleable.

This is on the todo list but not for the initial release - actually pretty simple to add. Oh and it does work with old school pfx certificates too.

I'll make an announcement here when we have a beta ready.

Yeah for years we have been told (and I have been telling everyone) to automate everything.. then some numpty decides to throw in a manual spanner🤦‍♂️- and yes, the cost of certificates increased a lot - way more than the cost of the physical tokens. There are work arounds and we currently use one - but it has it's limitations - for example right now using the old work around we can still only code sign from one virtual machine in our build environment - so lots of file copying happens which slows down builds - with our new solution code signing can be done from any build agent machine that has the client installed. FWIW, we have only tested using Yubikey and Safenet tokens - but any token with a 64bit pkcs#11 driver dll should work. Preview of the server web interface - product name may or may not change - naming is hard! Edit : forgot to mention, server will be for 64bit windows and linux - client 64bit windows only.

No, that would be terribly wasteful - we calculate the digest on the client and send that to the server to be signed.

We're working on a code signing server that supports tokens/pfx etc - allows you to do remote code signing very easily. All you need is network access to the server from a remote location (ideally over a vpn) and the client (a command line tool, which FinalBuilder will support). We're just tidying up loose ends (like the installer) before beta - hopefully in a few weeks.

If you want an easy way to build for multiple compiler versions, take a look at https://www.finalbuilder.com/finalbuilder - supports Delphi 3 - 12.2

If you are using the type library editor to create your RIDL - delphi should be mapping those methods as safecall. Check your options Edit : the default is only dual interfaces - this is something I change when ever I install a new version of delphi.

A gross generalisation on their part. It's entirely possible to create large applications without using a single Enterprise/Archtect feature.

I rely on TGUID.NewGuid to generate the random parts - under the hood it uses CoCreateGuid which uses windows cryptographic apis - which are far more random than Delphi's Random function (and faster).

Updated to add some new methods type TUUIDV7Helper = record class function CreateV7 : TGuid;overload;static; class function CreateV7(const dt : TDateTime) : TGuid;overload;static; class function CreatedUTC(const guid : TGUID) : TDateTime;static; class function IsV7(const guid : TGuid) : boolean;static;inline; class function Version(const guid : TGuid) : integer;static;inline; end;