Self-healing installation
Reported by steve | December 27th, 2010 @ 11:10 AM | in 20110322
Posted by: lukele
ported from GH:
https://github.com/GPGMail/GPGMail/issues/labels/C_Install#issue/5
The GPGMail plugin should be able to understand if it still works after an update.
At the moment, with every new version of OS X released or update to the Mail.app and its framework, the plugin is being corrupted and doesn't load anymore.
This behaviour is very tedious, since people have to wait until an update is released which supports the version.
Most of the time, adding the current UUIDs is sufficient for the plugin to work again, only internal API changes really break it.
A launch agent run on startup should be responsible to do some self-healing in those cases.
Szenario 1:
It checks the current UUIDs of the Message.framework and Mail.app
cat
/System/Library/Frameworks/Message.framework/Resources/Info.plist |
grep UUID -A 1
cat /Applications/Mail.app/Contents/Info.plist |grep UUID -A 1 |
grep UUID -A 1
Compares them to the ones already included in the current GPGMail.mailbundle
If not found, adds them to the bundle
Problem solved (hopefully)
Szenario 2 (if Szenario 1 fails):
Using launchd.plist WatchPaths options, it's possible for a
launch agent (or daemon) to be notified
whenever files in a directory change.
Check if the GPGMail.mailbundle file was moved to the Disabled Plugin folder.
If so, check if there's an update available and prompt the user for installation otherwise display a message to the user, that GPGMail has been deactivated and send an email to the developers with the version of the OS and Mail.app frameworks (User should be asked if they want that)
This should solve the most common issues, allow us developers to react quickly and provide the user with the most pleasant experience.
Comments and changes to this ticket
-
steve December 27th, 2010 @ 11:11 AM
- Assigned user set to “time2ride”
the following is all comments on GH as a single post:
-
davelopper June 19, 2010 | link | edit | delete I find it's a bad idea to modify a binary (though actually you wouldn't modify the binary, only a plist). In case of signed code, you cannot do that nasty thing. The 'check for update' is much better, and Sparkle should be used for that (from within an agent, and from within GPGMail) - don't try to rewrite your own solution.
-
lukele June 19, 2010 | link | edit | delete I absolutely agree with you. I didn't consider the case where the code is signed, which it might very well be in the future. I've already started integrating Sparkle in a different branch and it should absolutely be the way to go.
-
AlexanderWillner June 22, 2010 | link | edit | delete Still, we might want to add a small application called s.th. like "Autofix GPGMail.app" that is bundled with the distributed DMG. In case there is no update available a user could updates its own bundle if it's not signed.
-
AlexanderWillner July 28, 2010 | link | edit | delete I propose to distribute a DMG that shows a nice background with our (new) logo, contains the pkg installer file, maybe a README and a file called "AutoFixGPGMail.app".
-
AlexanderWillner July 29, 2010 | link | edit | delete Also see #106
-
AlexanderWillner August 03, 2010 | link | edit | delete I've a possible solution. Have a look at http://github.com/downloads/gpgmail/GPGMail/org.gpgmail.loginscript...
-
AlexanderWillner August 04, 2010 | link | edit | delete An idea for a simple prefpane:
http://img5.imageshack.us/img5/3504/gpgmailprefpane2.png Also see #131 -
lukele August 04, 2010 | link | edit | delete I guess a launch daemon which checks for GPGMail updates would be a nice way to go. We could use sparkle for it, and the user is alerted that a new version which works on the updated os is available even if the plugin has already been disabled by Mail.app
AlexanderWillner August 05, 2010 | link | edit | delete
Functional prefpane: http://github.com/downloads/gpgmail/GPGMail/GPGMail.prefPane-0.1.zip Screenshot: http://img704.imageshack.us/img704/8625/screenshot20100805at015.pngWorks for me, might be nice panel till we've a better solution.
-
lukele August 05, 2010 | link | edit | delete Looks great! and works for me too
-
AlexanderWillner August 05, 2010 | link | edit | delete New repository: http://github.com/gpgmail/GPGMail_Preferences New screenshot: http://img444.imageshack.us/img444/4029/gpgmailpref.png
-
SteveBell August 06, 2010 | link | edit | delete First: I like this a lot. Looks great. Although I'm not sure if all security concerns are met, when adding a possibility to change files related to GPGmail. I really can't judge since I'm not into coding myself.
Besides that concern (also stated by davelopper), who also brings up the argument that, now that sparkle is implemented, this could be considered duplicate functionality.
Besides that I still like it and think it adds great usability giving an eays uninstall option in a prefpane under system>preferences.
The latest screenshot looks even better than the first one.
Great work Alex, and good to see you still active @ the GPGmail-project. -
AlexanderWillner August 07, 2010 | link | edit | delete Security: we might want to sign the GPGMail bundle (maybe you can create a new ticket for that) Sparkle: imho it's technically not possible to use Sparkle for this issue within the bundle prefpane - but we can move all preferences (at least the update part) to the system prefpane (issue #131).
-
Alex (via GPGTools) January 20th, 2011 @ 09:53 AM
- Milestone set to “20110322”
- Importance changed from “High” to “”
-
Alex (via GPGTools) January 20th, 2011 @ 10:02 AM
- Milestone changed from “20110322” to “20110711”
- Importance changed from “” to “”
-
-
Alex (via GPGTools) January 21st, 2011 @ 08:36 AM
Maybe using an automatic login script:
- Create a default gpg.conf file if none exist
- Check UUIDs and ask the user: try to auto-fix | find an update | never ask again | cancel
- Create a default gpg.conf file if none exist
-
Alex (via GPGTools) January 27th, 2011 @ 09:24 AM
- Assigned user cleared.
I had an idea and implemented it: the GPGTools installer now adds the current UUIDs automatically. This doesn't prevent OS X to disable GPGMail after an OS upgrade but it fixes GPGMail automatically when installing it on a new OS X version. Also this fix is available via GPGPreferences and in the GPGMail installer.
I think this is the best solution we can get currently. -
-
Alex (via GPGTools) January 27th, 2011 @ 09:39 AM
- Assigned user set to “time2ride”
Please test the current beta: http://www.gpgtools.org/installer.html (beta link)
-
steve January 27th, 2011 @ 12:49 PM
- Assigned user changed from “time2ride” to “Alex (via GPGTools)”
GPGTools 20110127_2 tested. No issues so far. Concerning this ticket here, since I'm already on 10.6.6 and have no Apple Developer Account I can't say if the auto-fix would work on e.g. 10.6.7.
Guess we'll have to wait for someone with 10.6.7 to test this.
-
Alex (via GPGTools) February 14th, 2011 @ 08:04 AM
- State changed from “open” to “resolved”
-
Alex (via GPGTools) May 17th, 2011 @ 03:38 PM
- Milestone changed from “20110711” to “20110322”
- Importance changed from “” to “High”
-
steve June 18th, 2015 @ 04:30 PM
- State changed from “resolved” to “released”
- Importance cleared.
Please Sign in or create a free account to add a new ticket.
With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.
Create new ticket
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป
People watching this ticket
steve
Referenced by
-
20
Self-healing installation
(from [a1b1dc67b8cccf681c44d37b69d8ce174ae62ad8])
self-he...