Digital Code Signing with VFP and an Older Version of InstallShield

[steve4king]

I'm not sure this is the best place for this question, but the Flexera forums don't get a lot of traffic.. and it has a VFP component.

I've got an old VFP application that I'm attempting to bring up-to-date.
I've fixed it up so that it works great in Windows 7 and fixed up some of the bugs, but..

One of those steps is to sign the code/installer so that users won't see "publisher could not be verified" or "Publisher: Unknown"

I'm running InstallShield 11.5 Professional, which has options to include a digital signature, but it's missing some seemingly key fields for signing the code.
Also, some of the information I've found mentioned requiring a Manifest in VS.. while this isn't built with VS.. I'm curious whether it's even possible for me to create an installer from this to which Windows can give the green light.

Any of you have any genius to share?

Thanks!
-Stephen

 

[EzLogic]

http://www.wintellect.com/cs/blogs/...it-s-cheaper-and-easier-than-you-thought.aspx

Ali Koumaiha
TeknoSoft Inc.
Michigan

 

[Mike Lewis]

Stephen,

Yes, this is the right forum for your question, since the answer you need is specific to VFP.

I believe the solution is to use a utility called SIGNTOOL.EXE. I think this is part of VS, but it should be possible to download a copy without actually installing Visual Studio. Perhaps if you do a search for SIGNTOOL.EXE Download, you might find it.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[steve4king]

Actually have VS installed already so I've got that.
Alright as long as I know it's actually possible I'll buy the certificate then figure out the rest.

Thanks!
-Stephen

 

[Olaf Doschke]

In regard of a manifest embedded into a vfp application, see
[URL unfurl="true"]http://www.sweetpotatosoftware.com/SPSBlog/Trackback.aspx?guid=a7469c56-d058-41cd-b345-82a8121e1cfd[/url]
and
[link blogs.msdn.com/b/calvin_hsia/archive/2007/04/13/add-a-manifest-to-control-your-application-vista-uac-behavior.aspx]

http://blogs.msdn.com/b/calvin_hsia...trol-your-application-vista-uac-behavior.aspx

[/url]
besides
[link msdn.microsoft.com/en-us/library/windows/desktop/aa375649%28v=vs.85%29.aspx]

http://msdn.microsoft.com/en-us/library/windows/desktop/aa375649(v=vs.85).aspx

[/url]
which is a mnual to MT.exe. Every VFP exe has a manifest embedded and you can extract and change it.

And AFAIK Signtool.exe is simply appending a section to an exe at the end of it, but I might be wrong.

Overall I know you can sign any exe, this is not limited to VS created EXEs, it's just the embedded tools make it easier to configure signing of an exe created in VS. Craig shows, that you can automate that in a projecthook class in VFP, too, so every build could also sign the resulting exe in the AfterBuild event, using Signtool.exe for example.

Bye, Olaf.

 

[steve4king]

Thanks for the reply Olaf,

Those links should be helpful.

I've seen that quite a few developers strongly suggest avoiding signing the program within the IDE and state that it should always be done in InstallShield.
Also, since I am already using installshield to create the installer executable. I'll need to sign it either within IS, or after IS finishes it's work.

 

[Olaf Doschke]

In regard to the article Ali links: You can even get a certificate free, because you can actually also create your own root certificate. The difference to Thawte or Verisign certificates is shown here:
[link blogs.technet.com/b/sbs/archive/2007/04/10/installing-a-self-signed-certificate-as-a-trusted-root-ca-in-windows-vista.aspx]

http://blogs.technet.com/b/sbs/arch...te-as-a-trusted-root-ca-in-windows-vista.aspx

[/url]

Read the security warning in step 8 there. Anybody can claim to be a CA, not just VeriSign, Thawte, Comodo or others. The value of a more expensive code signing certificate is, that Verisign and Thawte root certificates are preinstalled in the trusted root CA store and thus the validity of your signature can be validated by Windows.

[URL unfurl="true"]http://www.digitallycreated.net/Blog/38/using-makecert-to-create-certificates-for-development[/url] also explains, what role these root certificate store plays as the end of a trust chain. Your signature can be validated against the end of this chain as the root certificate. That's also a reason the certificates have different pricing.

If you have a standard customer you work for on site and they trust you, they can allow you to install your self generated root certificate and then can trust any exe you signed as coming fro you and being unchanged by any third party. In this case it can be a valid solution to avoid such recurring costs.

The security is always as good as your development computer is secured. The moment you sign your exe should be as close to building it, as it can. Because if a virus of malware attaches to it before you sign it, this is included and also trusted to be by you with your signature. Changes on the file after the signing can be detected. That's the value of such a signature, as is an md5 checksum.

Your customer then just knows, all the errors and misbehaviour of your exe really come from you and nobody else, that's really all you get for your money.

Bye, Olaf.

 

[Olaf Doschke]

Your answer overlapped with mine.

In regard to the time of signing: Yes, you're right in that the final file should be signed, eg the setup.exe or setup.msi, that's a good approach. In the end you could sign both the exe and then the setup in their build processes to avaoid interception with malware embedding itself, before you sign.

So I'd do this both in the IDE and IS. On the installer level the admin installing the software can verify that is coming from you, and also the installed exe can be verified to be by you.

Bye, Olaf.