Thank for the rapid reply Shane, & G'day.
Mail Manager is written exclusively for a single Client, so I haven’t seen the need for codesigning.
Also, as I don’t know what limitations codesigning might add, I’m concerned that doing so may limit my ability to rapidly change code, and send amended versions for testing. As my Client is in the USA, and I’m in the worlds best country, Oz, I often sit up all night to change code as they test. Mail Manager is VERY complex, and they often request frequent small changes as they’re running it during updates. A rapid response is essential. 2 nights ago I made 7 different alterations, each of which required a fresh installation. That’s why I’ve tried to make the install process as painless as possible. I can’t just replace the existing Applications/Mail Manager folder, as any new install requires recognising it’s a new install, and then making certain changes, such as setting the Privacy flags all at once pre-running, rather than waiting for any altered App of the possible extra 6 to be opened as it’s required during running, and only then setting the Privacy.
I could have written the version number, which I update automatically, to a preference file, and checked it on each install/run, but that’s more cumbersome than my present technique. Or, at least I think so. My way, I can send it as a single App file, rather than a folder. My way also allows me to offer a button to re-install over the top of the existing install, in case of any file removal or corruption.
The current version of MM for El Capitan is pretty well polished completely, but as I’m under a directive to update to any utilised software as new versions become available, I repeat the above procedure from time to time. I was wondering if Sierra will require extensive re-writing, so I can advise them ahead of changes. They like to be pre-advised of large cost estimates.
Does codesigning stop/reduce problems with first launch in Sierra?
Will starting installation, under the new gatekeeper, of Mail Manager from a single Application file located in somewhere like the desktop, (it’s usual Client starting location), move that file to somewhere else before my procedure can install everything in the Applications/Mail Manager folder? Or if it does get moved, will it still proceed? (I realise that’s an awkward question, that might have to wait until the new release).
Will a re-install, overwriting existing files (the 6 extra Apps), actually still overwrite each App, wherever the Sierra gatekeeper decides to randomly store it?
Will it still overwrite if the App code is updated, or will multiple copies be randomly stored? (more awkward questions, sorry).
If code signing under Sierra still allows me to rapidly send multiple re-writes (my main worry), and not signing will cause problems with my existing procedure, then I’ll most certainly take your advice to do so.
Regards
Santa
On 16 Jun 2016, at 11:25 AM, Shane Stanley < email@hidden> wrote: On 16 Jun 2016, at 10:39 AM, Brian Christmas < email@hidden> wrote: How will the new Sierra gatekeeper technique alter the above procedure, if at all?
The only Gatekeeper issue is how you launch an app for the first time. If it causes too much fuss, you can get around it by writing a script that removes the quarantine bits from your apps. My main concern is that calling the folder embedded Applications directly using the folder/Application path may no longer work.
You may have problems with first launch; see above. Also, will my initial copying of the contents stored Applications still be embedded in the Mail Manager folder?
Will referring to the embedded png logo still work?
It's app launching that's affected, nothing else. I’d prefer NOT to sign.
Why not? It will avoid all the hassles. It will also give you and your clients a bit more peace of mind. All you seem to be focused on is convenience. How about some thought for security? Gatekeeper uses codesigning, but codesigning is about more than that initial launch. There are places where codesigning can't be used, but where it can, why not? -- Shane Stanley < email@hidden> < www.macosxautomation.com/applescript/apps/> |