* * *

Author Topic: Codesigning (Authenticode) IDE package  (Read 2156 times)

CCRDude

  • Sr. Member
  • ****
  • Posts: 328
Codesigning (Authenticode) IDE package
« on: May 12, 2017, 03:18:29 pm »
Here's another plugin I wrote for my daily use. This is only useful for those developer who invest into getting a codesigning certificate.

I tend to codesign all Windows files I create with Lazarus. Previously, I've been doing this with post build events. Updating these for all projects was tedious (e.g. when I introduced SHA256 in addition to SHA1 signing, when the certificate has changed, when the timestamping server has changed, when pagehashing was added, ...).

With this package, there's a central IDE Options page to set up certificate, timestamping server, signtool executable location, and a few more attributes, global changes are much easier. The description is picked from the current project. A flag in the Options allows to auto-sign after each build; and there's a menu item to do it manually. Project-specific settings are something I'm thinking about.


Feedback welcome. Screenshots at the link above.

mig-31

  • Full Member
  • ***
  • Posts: 215
Re: Codesigning (Authenticode) IDE package
« Reply #1 on: May 12, 2017, 04:21:45 pm »
What about other OS: Linux, MacOs?
Lazarus 1.6 - Linux 32/64 bit, win32

CCRDude

  • Sr. Member
  • ****
  • Posts: 328
Re: Codesigning (Authenticode) IDE package
« Reply #2 on: May 12, 2017, 05:44:54 pm »
I would have to check what options these OS have...

macOS has a command line tool "codesign". Since I'm often working from a Mac (just RDP'ing to the Windows dev machine), I probably could easily adapt to macOS-specific codesigning stuff. Just a different Options frame, a different executable to call and different parameters, if TProcess works the same on macOS.

I use Linux on a few servers, but have no idea at all whether there's any similar codesigning available there. I know that Debian packages are signed, for example, but I know nothing about single executables. Can you hint me at how it's done on Linux?


Phil

  • Hero Member
  • *****
  • Posts: 2070
Re: Codesigning (Authenticode) IDE package
« Reply #3 on: May 12, 2017, 06:04:06 pm »
macOS has a command line tool "codesign". Since I'm often working from a Mac (just RDP'ing to the Windows dev machine), I probably could easily adapt to macOS-specific codesigning stuff. Just a different Options frame, a different executable to call and different parameters, if TProcess works the same on macOS.

Looks like you've done a thorough job. This is certainly something that the Laz IDE has always lacked and that all other IDEs have had for a long time.

It would be nice if this could support OS X too. For anyone interested, here's Apple's documentation on codesigning:

https://developer.apple.com/library/content/documentation/Security/Conceptual/CodeSigningGuide/Introduction/Introduction.html

Back when I still developed Windows desktop apps, I typically only signed the installer, not the executable included in the installer. While it's a good idea to sign all executables, the installer is the first one the user will see and many organizations won't allow unsigned installers to be run. I always just used signtool in a batch file, but I believe Inno Setup also has support for including signing in the .iss script. That's probably the one piece missing here and an important piece, although it may be beyond what should be done in the IDE.

I also RDP into my Windows Server (on AWS) from my Mac. I use Microsoft Remote Desktop - very nice and works perfectly.

Note that the distributed Lazarus IDE executables and installers are never signed. They should be.
« Last Edit: May 12, 2017, 06:05:45 pm by Phil »

Thaddy

  • Hero Member
  • *****
  • Posts: 3685
Re: Codesigning (Authenticode) IDE package
« Reply #4 on: May 12, 2017, 06:19:22 pm »
Code signing is not normally something you would do unless in a commercial setting.
Furthermore, both Apple and Microsoft require you to obtain certificates from them.
That is not free and requires several other steps to adhere to depending on your requirements.

I hope nobody is under the impression that this plug-in opens up code signing for Authenticode in a general sense.
It is very important and should be stressed that this is NOT the case. It is a feature that is only useful for a limited part of our community.

It is possible to sign with a self generated certificate, though, but you will run into trouble during commercial deployment.

A proper certificate should be obtained through a trusted authority that can sign with a MS rootcertificate. See: http://go.microsoft.com/fwlink/p/?linkid=203607
« Last Edit: May 12, 2017, 06:21:25 pm by Thaddy »
Why do the Danish always try to fuck up any programming language?

Phil

  • Hero Member
  • *****
  • Posts: 2070
Re: Codesigning (Authenticode) IDE package
« Reply #5 on: May 12, 2017, 06:23:56 pm »
Code signing is not normally something you would do unless in a commercial setting.
Furthermore, both Apple and Microsoft require you to obtain certificates from them.
That is not free and requires several other steps to adhere to depending on your requirements.

Apple's is free. Perhaps you're confusing this with Apple's developer program, which is required for App Store submission.




CCRDude

  • Sr. Member
  • ****
  • Posts: 328
Re: Codesigning (Authenticode) IDE package
« Reply #6 on: May 12, 2017, 09:07:35 pm »
@Phil: indeed InnoSetup has support for signing uninstaller and installer integrated. That's quite helpful, though you still need to enter the full parameter list. I'm not sure how good the integrated support is where it comes to SHA1+SHA256, would need to test whether it supports two calls (right now I use a helper exe I wrote for that purpose).

I was btw. hoping that the packages post build even would affect rebuilding the Lazarus IDE as well, but that didn't happen ;)
While I would support signed installers and executables, the "rebuild from source" aspect would get rid of the signature as soon as you add another package to the IDE.

@Thaddy: You don't need to get them from Microsoft, you can get certificates from a number of companies like Comodo, VeriSign, DigiCert, StartSSL, and a bunch more. You don't need to get them from Microsoft - you get them from the same companies that sell you certificates for websites. And as with https websites, there are advantages, but it's not free, that's true. With StartSSL, I paid once for the identification and could create as many certificates as I wanted later (so after I paid for it to get the website secure, I didn't have to pay for the code signing cert), but StartSSL got some quite bad press recently and I wouldn't recommend them any more.

In todays malware-poisoned world, it's nice to be able to show that a file has not been modified since leaving the original author. A correctly signed file is proof that it isn't infected by a virus (unless the author himself has infected the file). It makes it easier to trust software. Similar to https websites (unless you use the free LetsEncrypt), where you can verify who owns the server. I know that making users feel more comfortable in using a software isn't the main focus of noncommercial software, but users would benefit from it anyway ;)

The required steps are the same as with https certificates - you need to proof your identity. Which comes at a cost.

On Windows since Vista, the UAC dialogs look different if a file has been signed. If you're writing drivers, you need to sign them. If you're writing WSC modules, you need to sign them. Not sure about Windows 10 S, but I would assume that signing files is getting even more important there. Same on the Mac... the system gets more closed with every release. I'm not saying that this is a completely good development, but it has some good aspects.

But speaking about open systems reminds me of something. Nearly twenty years ago, before I even knew about Authenticode, I supplied pgp signatures with the files of my application. That could be something worth adding as well, and would be something useful on Linux.


Anyway, my apologies if anyone was mislead to believe this would make free signing possible, as you seem to imply. That's indeed not the case. See my second sentence: "This is only useful for those developer who invest into getting a codesigning certificate".

Phil

  • Hero Member
  • *****
  • Posts: 2070
Re: Codesigning (Authenticode) IDE package
« Reply #7 on: May 12, 2017, 09:16:59 pm »
Same on the Mac... the system gets more closed with every release.

Not sure if I can think of any ways in which OS X has become more closed over the last few releases. If anything, it's even easier to develop for since you don't need to be in the paid developer's program anymore to download Xcode or to sign your executables with your Apple ID.

Otherwise, well stated.

I would argue that signing is important for hobbyist-created executables too.

Thaddy

  • Hero Member
  • *****
  • Posts: 3685
Re: Codesigning (Authenticode) IDE package
« Reply #8 on: May 12, 2017, 09:24:09 pm »
Iwas merely saying that the root certificate must be microsoft's. Of course other ca's do the actual selling to individuals and companies.
Why do the Danish always try to fuck up any programming language?

CCRDude

  • Sr. Member
  • ****
  • Posts: 328
Re: Codesigning (Authenticode) IDE package
« Reply #9 on: May 12, 2017, 09:35:49 pm »
@Phil: What I meant is that macOS started to require you to go the Settings > Security to run files you've downloaded from the Internet. In the last macOS release, you could skip this, but in 10.12.4 I think you need this step for the first run of every unsigned downloaded executable, while the settings allow to skip this for App Store apps and signed executables (the third option has been removed now). But you're right, since it got even easier to sign on the Mac, "closed" is probably the wrong term :)

@Thaddy: that's not true either :) It's the same as with browsers, who bring their range of trusted root authorities. My Windows installation currently shows 46 trusted root certification authorities, and only five of them are Microsoft. So the limitation would only be that Windows needs to ship the root certificate of ones specific code signing certificate.

You wouldn't claim that all https websites need to have a certificate based on a Mozilla root certificate to work in Firefox either, it's really very similar :D

Phil

  • Hero Member
  • *****
  • Posts: 2070
Re: Codesigning (Authenticode) IDE package
« Reply #10 on: May 12, 2017, 09:50:48 pm »
@Phil: What I meant is that macOS started to require you to go the Settings > Security to run files you've downloaded from the Internet. In the last macOS release, you could skip this, but in 10.12.4 I think you need this step for the first run of every unsigned downloaded executable, while the settings allow to skip this for App Store apps and signed executables (the third option has been removed now).

I believe the control-click, choose Open option still works with unsigned apps, per Apple's documentation:

https://support.apple.com/kb/PH25753?viewlocale=en_US&locale=en_US

The "Anywhere" choice in the Security and Privacy preferences always made me a little nervous anyway and I never used it.

valdir.marcos

  • Full Member
  • ***
  • Posts: 217
Re: Codesigning (Authenticode) IDE package
« Reply #11 on: May 13, 2017, 03:22:10 am »
I use Linux on a few servers, but have no idea at all whether there's any similar codesigning available there. I know that Debian packages are signed, for example, but I know nothing about single executables. Can you hint me at how it's done on Linux?

"GPG can be used to create a digital signature for both Debian package files and for APT repository metadata.

Many Debian-based Linux distributions (e.g., Ubuntu) have GPG signature verification of Debian package files (.deb) disabled by default and instead choose to verify GPG signatures of repository metadata and source packages (.dsc). The setting which enables GPG signature checking of the individal .deb packages can be found in /etc/dpkg/dpkg.cfg and is set to no-debsig, but there are important caveats to enabling this option explained below.

Further, most official Debian package files from the publicly accessible repositories do not have GPG signatures. The official repository metadata is GPG signed, as are the source packages, but the .deb packages themselves are not.

If you publish a Debian package and GPG sign the package yourself before distributing it to users, those users’ systems will, in most cases, not verify the signature of the package unless they have done a considerable amount of configuration. However, their system will, in most cases, automatically verify repository metadata."

Reference: https://blog.packagecloud.io/eng/2014/10/28/howto-gpg-sign-verify-deb-packages-apt-repositories/



Maybe, these information can help you to start out:
HOWTO: GPG sign and verify deb packages and APT repositories
https://blog.packagecloud.io/eng/2014/10/28/howto-gpg-sign-verify-deb-packages-apt-repositories/

How to sign files with Ubuntu command-line tools and my own keys?
https://askubuntu.com/questions/679230/how-to-sign-files-with-ubuntu-command-line-tools-and-my-own-keys

GnuPG in Debian
https://wiki.debian.org/GnuPG

Creating a new GPG key
https://keyring.debian.org/creating-key.html

Debian Public Key Server
https://keyring.debian.org/

SecureApt - All about secure apt
https://wiki.debian.org/SecureApt

Subkeys - Using OpenPGP subkeys in Debian development
https://wiki.debian.org/Subkeys

Keysigning
https://wiki.debian.org/Keysigning

Package: signing-party
https://packages.debian.org/sid/signing-party

jwdietrich

  • Hero Member
  • *****
  • Posts: 927
    • formatio reticularis
Re: Codesigning (Authenticode) IDE package
« Reply #12 on: May 13, 2017, 09:55:08 am »
What about other OS: Linux, MacOs?

There is an article in the Lazarus wiki describing code signing on the Mac. Perhaps it is helpful for adapting the plug-in for macOS.
« Last Edit: May 13, 2017, 09:58:03 am by jwdietrich »
function GetRandomNumber: integer; // xkcd.com
begin
  GetRandomNumber := 4; // chosen by fair dice roll. Guaranteed to be random.
end;

Lazarus 1.6.4 | FPC 3.0.2 | PPC, Intel, ARM | macOS, Windows, Linux

CCRDude

  • Sr. Member
  • ****
  • Posts: 328
Re: Codesigning (Authenticode) IDE package
« Reply #13 on: May 15, 2017, 08:24:14 pm »
Thanks for all the replies :)

I updated the code to support certificate property substrings as an identifier, since that's the easiest way for codesign on macOS (-s <email of Apple dev cert>), made a bunch of fields not yet supported invisible on macOS, and tested with codesign.

It works now on macOS to sign the main binary; I could probably add Info.plist signing as well.

Plus, I need to find out how to get the output of TProcess on macOS. The pipe routines that work on Windows seem to fail still...

I'll push it to the repository once I tested it some more!

jwdietrich

  • Hero Member
  • *****
  • Posts: 927
    • formatio reticularis
Re: Codesigning (Authenticode) IDE package
« Reply #14 on: May 15, 2017, 08:38:04 pm »
It works now on macOS to sign the main binary; I could probably add Info.plist signing as well.

That is great. AFAIK, it is necessary, however, to sign the whole app on macOS, rather than the binary only.
function GetRandomNumber: integer; // xkcd.com
begin
  GetRandomNumber := 4; // chosen by fair dice roll. Guaranteed to be random.
end;

Lazarus 1.6.4 | FPC 3.0.2 | PPC, Intel, ARM | macOS, Windows, Linux

 

Recent

Get Lazarus at SourceForge.net. Fast, secure and Free Open Source software downloads Open Hub project report for Lazarus