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.
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.
Same on the Mac... the system gets more closed with every release.
@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 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?
What about other OS: Linux, MacOs?
It works now on macOS to sign the main binary; I could probably add Info.plist signing as well.
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 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...
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
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.
The fact that Lazarus creates the executable outside the bundle is a longtime Laz defect.
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.
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?
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 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.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.
...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.
...Cool, that's 9-bits more secure than the standard SHA256 ... ;)
FreeBSD also uses SHA265 in its ports (https://en.wikipedia.org/wiki/FreeBSD_Ports) system to verify all user installed software against the originals.
...
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.
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.
Cool, that's 9-bits more secure than the standard SHA256 ... ;)%) Well spotted. Sorry for the typo.