* * *

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

Phil

  • Hero Member
  • *****
  • Posts: 2040
Re: Codesigning (Authenticode) IDE package
« Reply #15 on: May 15, 2017, 09:11:33 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.

I assume you're referring to signing the disk image, eg,

signtool -s "Mac Developer: Dev Name (DevCertNum)" -v someapp.dmg

https://developer.apple.com/library/content/technotes/tn2206/_index.html#//apple_ref/doc/uid/DTS40007919-CH1-TNTAG18

Phil

  • Hero Member
  • *****
  • Posts: 2040
Re: Codesigning (Authenticode) IDE package
« Reply #16 on: May 15, 2017, 09:13:23 pm »
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.

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...

Not sure what <email of Apple dev cert> refers to.

I've used TProcess on Mac for years without problem. Can you give an example of TProcess code that doesn't work?


jwdietrich

  • Hero Member
  • *****
  • Posts: 917
    • formatio reticularis
Re: Codesigning (Authenticode) IDE package
« Reply #17 on: May 15, 2017, 10:13:40 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.

I assume you're referring to signing the disk image, eg,

signtool -s "Mac Developer: Dev Name (DevCertNum)" -v someapp.dmg

https://developer.apple.com/library/content/technotes/tn2206/_index.html#//apple_ref/doc/uid/DTS40007919-CH1-TNTAG18

No, I don't refer to the disk image. Apps for the Mac are special directory structures called packages. Every app contains a folder called Contents and this again contains a directory named MacOS (along with other folders for resources, frame works, plug-ins etc.). The binary is in the folder Contents/MacOS/, and this is the file that has been generated by Lazarus or Free Pascal. To make the things more complex Lazarus creates the binary outside the app, and the folder MacOS contains an alias to the binary only (which has to be replaced by the original binary before deploying the app).

In the final step before uploading / selling etc. a Mac app it should be signed. This refers to the whole app and not to the binary. In addition, you might want to sign a DMG image, but this is another story.
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

Phil

  • Hero Member
  • *****
  • Posts: 2040
Re: Codesigning (Authenticode) IDE package
« Reply #18 on: May 15, 2017, 10:23:29 pm »
In the final step before uploading / selling etc. a Mac app it should be signed. This refers to the whole app and not to the binary. In addition, you might want to sign a DMG image, but this is another story.

Yes, that's what codesign does for an .app bundle. See contents of CodeResources file in bundle's _CodeSignature folder.

The fact that Lazarus creates the executable outside the bundle is a longtime Laz defect.

jwdietrich

  • Hero Member
  • *****
  • Posts: 917
    • formatio reticularis
Re: Codesigning (Authenticode) IDE package
« Reply #19 on: May 15, 2017, 10:25:56 pm »
The fact that Lazarus creates the executable outside the bundle is a longtime Laz defect.

Well, this defect is easy to circumnavigate, but of course it would be better, if Lazarus would automatically create self-contained applications.
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

Phil

  • Hero Member
  • *****
  • Posts: 2040
Re: Codesigning (Authenticode) IDE package
« Reply #20 on: May 15, 2017, 10:27:11 pm »
The fact that Lazarus creates the executable outside the bundle is a longtime Laz defect.

Well, this defect is easy to circumnavigate, but of course it would be better, if Lazarus would automatically create self-contained applications.

You mean like all other Mac IDEs, right?


CCRDude

  • Sr. Member
  • ****
  • Posts: 297
Re: Codesigning (Authenticode) IDE package
« Reply #21 on: May 16, 2017, 09:23:37 am »
Not sure what <email of Apple dev cert> refers to.

The certificates issued by Apple seem to have the email address as part of their subject, so this was the easiest way I found to identify them (e.g. „Mac Developer: username@domain.com (CAFFEE00)“).

On Windows, I enumerate through the MY store to show a list of certificates to pick from. For the Mac I haven’t found an equivalent yet.

I've used TProcess on Mac for years without problem. Can you give an example of TProcess code that doesn't work?

I think I’ve found my problem:  PepiMK.Authenticode.Sign.External.pas, line 369ff. This probably returned too fast before the pipes could get emptied (on Windows, it always worked, it looks like the process there won't close until the pipes are empties). I went ahead and set the poWaitOnExit flag, since the component for now has no live events of console output anyway. Now it shows the output as expected.

To make the things more complex Lazarus creates the binary outside the app, and the folder MacOS contains an alias to the binary only (which has to be replaced by the original binary before deploying the app).

Yes, that makes signing the whole .app more difficult, thanks for pointing that out! My new workaround is for the codesigning to remove the symlink and move the executable into the bundle, then sign the bundle.

The code I just pushed contains these fixes :)

Graeme

  • Hero Member
  • *****
  • Posts: 1362
    • Graeme on the web
Re: Codesigning (Authenticode) IDE package
« Reply #22 on: May 16, 2017, 12:44:28 pm »
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.
...snip..
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.
FreeBSD and Linux distros use SHA256 to verify there ISO images for download. I wrote a script that downloads and verifies them for me. I also have another script that burns a ISO image to CD/DVD (when I still used those) and then verified it against the original SHA256 when I downloaded the ISO. That confirms nothing went wrong with the burning of the disk.

FreeBSD also uses SHA256 in its ports system to verify all user installed software against the originals.

But I don't know of any other "code signing" usage in Unix-type systems. eg: I've never come across a code signed executable, or the OS preventing me from running an executable because it isn't code signed.

Java uses code signing a lot too. Especially when it comes to Java Applets. Modern web browsers and Java plugins prevent Java Applets from running if they are not code-signed. You have to manually override permissions if Java Applets are not code signed.

Just my 2c worth.
« Last Edit: May 17, 2017, 04:22:53 pm by Graeme »
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

jc99

  • Sr. Member
  • ****
  • Posts: 375
    • My private Site
Re: Codesigning (Authenticode) IDE package
« Reply #23 on: May 16, 2017, 01:15:50 pm »
...
FreeBSD also uses SHA265 in its ports system to verify all user installed software against the originals.
...
Cool, that's 9-bits more secure than the standard SHA256 ... ;)
Where do I get it ?
OS: Win XP x64, Win 7, Win 7 x64, Win 10, Win 10 x64, Suse Linux 13.2
Laz: 1.2 - 1.6.4, 1.8rc1
https://github.com/joecare99/public
'~|    /''
,_|oe \_,are

Phil

  • Hero Member
  • *****
  • Posts: 2040
Re: Codesigning (Authenticode) IDE package
« Reply #24 on: May 16, 2017, 04:08:17 pm »
The certificates issued by Apple seem to have the email address as part of their subject, so this was the easiest way I found to identify them (e.g. „Mac Developer: username@domain.com (CAFFEE00)“).

No, perhaps they look like that if someone used their e-mail address as their "name".

On Windows, I enumerate through the MY store to show a list of certificates to pick from. For the Mac I haven’t found an equivalent yet.

You probably want the Security framework:

https://developer.apple.com/reference/security

Yes, that makes signing the whole .app more difficult, thanks for pointing that out! My new workaround is for the codesigning to remove the symlink and move the executable into the bundle, then sign the bundle.

Correct. That Lazarus defect was a big mistake when it was first done that way and is still a big mistake.

Graeme

  • Hero Member
  • *****
  • Posts: 1362
    • Graeme on the web
Re: Codesigning (Authenticode) IDE package
« Reply #25 on: May 17, 2017, 04:22:16 pm »
Cool, that's 9-bits more secure than the standard SHA256 ... ;)
%) Well spotted. Sorry for the typo.
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

CCRDude

  • Sr. Member
  • ****
  • Posts: 297
Re: Codesigning (Authenticode) IDE package
« Reply #26 on: May 19, 2017, 09:30:08 am »
Just pushed a version with lots of changes.

* GnuPG is now supported (tested on Windows and macOS) for signing and verifying (should cover Linux, but I'll have to test that).
* Certificate picker lists available GnuPG certificates.
* Verification on Windows and Mac implemented.
* Signing the Lazarus IDE on rebuilding it is now supported.
* Project-specific codesigning settings allow to override global settings.
* For Microsofts signtool, the URL is now picked from a formatted comment in the main source file.

Thanks Phil for pointing out that framework! I just saw that it already has included header translations in SecTrust.pas. That'll most likely be my next update :)

Graeme: hashes are way different from cryptographic signatures. For downloads, it can indeed help if download and hash come from different servers (otherwise on a compromised server, the hash could be replaced as well as the download). But on just one computer, any malware could simply update a hash as well. Still, thanks for the insight into FreeBSD/ports :)

CCRDude

  • Sr. Member
  • ****
  • Posts: 297
Re: Codesigning (Authenticode) IDE package
« Reply #27 on: May 22, 2017, 02:16:30 pm »
SecTrust does not work for listing certificates, it doesn't implement the correct new functions. Will work on that.

Since Java was mentioned, I started looking into the use of keytool and jarsigner. The FreePascal Java cross-compiler has some issues though. It creates the output in the specified library instead of output path, and creates class files, while only jar files can be signed. I'm going to see if I can include the steps to wrap the classes into a jar that could be signed.

Microsofts SignTool, Apples CodeSign and GnuPG now have separate pages, and each a custom project page. Due to Windows adding more subsystems and signtool available through Wine on the Mac, I didn't want to be in the way of cross-compiling, so the selection of the proper signing tool is now based on the project build modes target os instead of compile time.

(that code not pushed to gitlab yet)

 

Recent

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