Another naive question about code signing
livfoss at mac.com
Sat Jan 14 23:32:57 CET 2017
Thanks Matthias, that’s very clear!
> On 14 Jan 2017, at 23:04, Matthias Rebbe via use-livecode <use-livecode at lists.runrev.com> wrote:
> first you have to sign the standalone with all externals. If you are using Ksign.exe then just add the folder,which contains the standalone and its subfolders, in Ksign.
> Please be aware that if your standalone make use of the tsNet external,then you have to change the file attributes of tsnet.dll to be writable before you codesign it. Otherwise Ksign.exe will not be able to sign the tsnet.dll.
> tsnet.dll by default is read only. At least if the Windows standalone is created on Mac.
> After you have signed the standalone and its externals create the installer and codesign that exe again.
> That´s how i am doing it.
>> Am 14.01.2017 um 19:47 schrieb Graham Samuel via use-livecode <use-livecode at lists.runrev.com <mailto:use-livecode at lists.runrev.com>>:
>> Having taken a lot of advice from this list and after a delay getting certificates, I’m about to do some actual code signing for an app that has a Windows and a Mac version. I am so unsure about the process that i don’t understand whether I apply the process (let’s say with Ksign for Windows) to the installer or the app itself.
>> In my case the installer installs additional files apart from the executable (all neatly packaged up in the Mac version of course, but separate in the Windows one). Since an installer is itself executable, I suppose starting an installer will generate those irritating warnings (yes, I know, they are for my users’ benefit, but still…) - on that basis, should the installer be signed? Or should I codesign everything, executables, additional files (these can be stacks, which are in some sense executable) and the installer too? I think the latter, but I’m not sure.
>> This must be blindingly obvious to everyone else, but it is not easy to get a simple answer from the internet. Of course I will just do it and see what happens, but I would be glad to understand what ‘normal practice’ might be.
>> use-livecode mailing list
>> use-livecode at lists.runrev.com <mailto:use-livecode at lists.runrev.com>
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
More information about the use-livecode