Do All Your Windows Applications Look Like A Computer Virus?
OK, so you’ve written something brilliant, the Next Big Thing. You’re taking the modern approach. You’ve read up – or watched – our series on Fluent UI and maybe even applied a few visual things like neo skeuomorphism we learned about at the Desktop First conference. Perhaps you’ve applied some VCL themes to your app and integrated the ability to detect Windows 10 dark mode / light mode in your Delphi application? Everything is going well… until the users try to use your applications. This is the message you get when you run a very popular open source project which has 100,000+ downloads. You start getting complaints from your users they can’t download your application. Or, when they do finally manage to fight back against the modern web browser’s paranoia your app gets blocked by Windows 10 or, more mysteriously, simply disappears altogether into a blue cloud of corporate group policy genie smoke. You didn’t take the last step: signing your code to prove that your wonderfully-crafted application is from you, and only you, and has not been infected by a computer virus or cryptolocker trojan. In the recent security-themed TCoffeeAndCode we had intended to talk about code-signing but we kind of got distracted by the many other security things which cropped up. To be fair, we did say it’s not scripted! What is code-signing? Code signing is a manual process which you can make happen just after or at the point of the final building of your application. It adds a small resource to your exe containing a digital signature. The signature identifies who, in theory at least, wrote the code and adds in information which takes a checksum of your application’s exe file. This information – the code signature – when taken altogether means that any user running your applications can be sure that the exe file has not been modified since you created it on your computer or build server. Any changes to the exe, for example, by a virus, will break the cryptographic checksum so users can tell something has gone wrong. A properly code-signed app (the image is old – the certificate would show a current expiry date) Delivering apps via a weblink pretty much demands code-signing Code signing doesn’t just help identify the original developer, it also plays a part when your programs are downloaded from a website or similar online delivery mechanism. Most browsers (probably all) will warn you about downloading exes from a website, especially one which is not using HTTPS. Microsoft Edge and Windows combined goes a little further and will actively scream at you if the exe does not bear a digital signature (another way of saying it’s not code-signed). Unsigned apps look just like computer viruses If your users do finally manage to jump through all the various hoops and actually get the exe to download on your computer some of them may find that the downloaded file has magically disappeared. This is because it’s fairly common for corporate networks to enforce a rule which says that users may only run certain trusted applications. No code signature usually means your application is not trusted. Some go even further, although this is less common and insist that all user applications must be 64bit, especially server-side applications and Windows services. Corporate […]
