Why Don't All Developers Sign Their Apps?

I don't use many applications that aren't included in the box with Windows—mostly because I work on several systems and I'm lazy about having to install software unless I truly need it. I'm also really persnickety about keeping my licensing on the side of the angels. But there are a few apps that don't ship with Windows that I'd install anywhere—the Palm Desktop, Irfan Skiljan's wonderful image viewer and minor editor IrfanView, and the Autoruns and Process Explorer utilities from Mark Russinovich's Sysinternals site. One of those last two, Autoruns, made me wonder: Why don't all developers sign their applications?

For quite a while now, it's been possible for developers to attach digital certificates to their applications, drivers, and the like. Developers obtain "code certs" from the same organizations that provide Web Secure Sockets Layer (SSL) certificates—Thawte or VeriSign, for example. Code certs validate two things: that the company that claims to have signed the code is indeed the organization it claims to be, and that the file's contents haven't changed since the company signed the certificate.

Signing an application doesn't guarantee that it's free of spyware, Trojan horses, or other evildoing software. But if malware is discovered, signed software does guarantee that you know a few things about the culprit. I also assume that, when the subversive nature of a piece of signed software comes to light, the firm that issued the code certificate would revoke it. Prove to VeriSign that ClarenceSoft distributes an ActiveX control that logs keystrokes, and VeriSign ought to revoke ClarenceSoft's certificate. And if a lawyer could figure out how to explain to a judge what a digital certificate is, ClarenceSoft might be able to be successfully prosecuted.

Sound good? Sure does to me. So, again, why don't all developers sign their apps? Well, part of the reason is that code certs are so quiet about their existence—most folks don't know what code signing is or why they should care about it, except for that annoying "you are about to load a driver that Microsoft hasn't blessed and signed" message that pops up whenever you want to install something that hasn't been through Microsoft's Windows Hardware Quality Labs (WHQL) tests. (Hardware vendors often don't run revised drivers through those tests because Microsoft charges a pile of money to do them. So, there's nothing necessarily sinister about drivers that Microsoft hasn't blessed, but it would be nice if hardware vendors required SSL connections for downloading updated drivers so users could be sure they were getting a driver from the hardware vendor and not a spoofed site.)

People's awareness of code certs might be heightened if Windows made them a bit more visible. You'd think that you could go to Windows Explorer and add a column that shows whether an .exe file, DLL, OLE custom control (OCX), ActiveX control, or whatever was signed. It would be even nicer to be able to tell Windows Explorer, "Don't just look at those certificates—communicate with the firm that issued the code-signing certificate to the software vendor and make sure that the certificate hasn't been revoked." There might be an easy way to do that, but I haven't found it. Of course, such functionality wouldn't be without cost; hundreds of millions of Windows systems hammering VeriSign's Web site to download its list of revoked certificates would certainly chew up bandwidth and might even bring down the site. Perhaps checking code certs could be a task scheduled to run weekly or monthly.

Windows Server 2003, Windows XP, and Windows 2000 include a program called sigverif.exe that will scan some, but not all, program-related files for signatures. (It isn't clear how Sigverif decides what to scan and what not to scan; it never even looked at some of the apps I have loaded.) Sigverif also can't be run unattended from the command line. But it's a start. Who knows— perhaps a future version of Windows Explorer will be able to, say, display uncertified executable files in a different color. Until then, however, we have Mark Russinovich's Autoruns and Process Explorer. Autoruns shows you what loads automatically on your system, including software that automatically loads in Microsoft Internet Explorer (IE). You can configure the tool to check the digital signatures of all auto-loading files when you start Autoruns. (The check takes an extra minute or two but is well worth it.)

Running Autoruns is always an eye-opener because of the number of things that automatically load at startup, even in a system with a basic configuration. I run Autoruns now and then just to see whether anything bad has found its way onto my system, but the number of things loaded make identifying malware like trying to find a needle in a haystack. To combat that, Mark has included a nice feature that filters signed and verified Microsoft programs from view and simplifies Autoruns quite a bit.

Looking at Autoruns the other day raised the question that opened this piece. Running Autoruns on a new laptop made me notice just how many programs, DLLs, and drivers on my system aren't signed, despite the fact that they're written by big software companies. I can understand why a guy like Irfan doesn't sign his code—IrfanView is just a hobby, and Irfan gives it away, so where would the money for a code-signing certificate come from? But I can't see why companies such as big video and music distributors don't invest a few bucks in a code cert.

I guess it boils down to the usual reason: We don't get signed applications because we don't ask for them. Got a minute? Go to http://www.sysinternals.com, download the latest version of Autoruns—it's free—and look at all the unsigned stuff you're putting on your system. Then drop those vendors a line and ask them to sign software that they release. You'll be making life a bit harder for the folks who try to fool unsuspecting users into downloading and running bad programs.