Hatch Windows installer doesn't follow best practices

Bug #1733692 reported by Jason Boyer on 2017-11-21
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Evergreen
High
Unassigned

Bug Description

Hatch 0.0.3 and 0.1.2

The NSIS script for Hatch is making some poor assumptions that can cause Hatch to fail in very common scenarios.

Forces 64 bit registry access on 64bit Windows: This means that only the 64 bit version of Java will be detected. To this day the version pushed on Windows users on the Java.com homepage is 32 bit. It should be able to detect either. I suspect more special handling of the registry will also be required if we un-comment the Chrome Extension installer keys [[http://git.evergreen-ils.org/?p=Hatch.git;a=blob;f=installer/windows/hatch.nsi;h=3b676f0f18fc0e4cc0a071ba65565230d3533a41;hb=HEAD#l152|here]].

Uses local user registry keys: This will appear to work when you do the install as an admin account that only needs to click Yes to a UAC prompt to perform the installation but if you install Hatch as an administrator no other account will be able to find the NativeMessagingHosts key because it only exists in a single admin account. Installers should only ever write to system-wide registry keys unless it's a user local installation which there's no point in supporting for this. (If we still required any HKEY_CURRENT_USER registry entries even with a system wide install we'd have to check / write them at startup, not install time) The [[https://developer.chrome.com/apps/nativeMessaging#native-messaging-host-location|system-wide key]] that Chrome checks for NativeMessagingHosts is HKEY_LOCAL_MACHINE\SOFTWARE\Google\Chrome\NativeMessagingHosts\(rev.dns.name.here) @="path\to\native\host\hatch.bat"

We should be pulling the existing Hatch installation location from the registry also rather than always assuming it's going to be %PROGRAMFILES%\Hatch, if for no other reason than we may end up running an out of date uninstaller that misses files or worse, we try to run an uninstaller that doesn't exist.

I've got a spare machine handy that I'm going to try to make some progress on soon with this.

Jason Boyer (jboyer) wrote :

Re: importance; this is highly important or Critical if you require the use of Hatch and you're dealing with a properly managed multiple machine setup. But since Hatch isn't itself critical I feel a bit weird about setting it that high, and if High is still too much in people's opinion I won't complain if it's dropped to Medium.

description: updated
Jason Boyer (jboyer) wrote :

This addresses almost all of the points above and it goes ahead and installs the Chrome Extension since it's in the store now: http://git.evergreen-ils.org/?p=working/Hatch.git;a=shortlog;h=refs/heads/user/jboyer/lp1733692-nsis-best-practices

The silent uninstall still leaves the uninstaller around if you're installing a newer version to a different folder; I have an idea on fixing that but wanted to get this up while I had a chance.

Jason Boyer (jboyer) wrote :

I should specify, this branch is based off of Bill's lp1708757-chrome-store-prep branch, not master.

tags: added: pullrequest
Jason Boyer (jboyer) wrote :

Good news. I tested manually copying the uninstaller and now you can completely uninstall previous versions of Hatch during install without issue and completely silently. So the top two commits on that branch should be used. They're also based on Bill's Chrome Store prep branch, so both of these branches should be merged into master.

Bill Erickson (berick) on 2017-12-01
Changed in evergreen:
assignee: nobody → Bill Erickson (berick)
Bill Erickson (berick) wrote :

Thanks Jason!

I created a new installer based on these changes (see attachment).

For testing, I manually removed the old Hatch files. I then installed the new one and tested successfully.

I manually ran the new uninstaller and confirmed it removed Hatch AND the Hatch Chrome extension.

I ran the installer once more and confirmed Hatch and the Chrome exentions were added back and functional. (nice!).

Sign-off branch pushed. Includes another commit to bump the version numbers to 0.1.3.

http://git.evergreen-ils.org/?p=working/Hatch.git;a=shortlog;h=refs/heads/user/berick/lp1733692-nsis-best-practices-signoff

Note this branch still sits atop yet-to-be-signed-off commits for bug #1708757.

Bill Erickson (berick) on 2017-12-05
Changed in evergreen:
assignee: Bill Erickson (berick) → nobody
Bill Erickson (berick) on 2017-12-15
Changed in evergreen:
assignee: nobody → Bill Erickson (berick)
Bill Erickson (berick) wrote :

Merged to Hatch master. Thanks again, Jason.

Changed in evergreen:
assignee: Bill Erickson (berick) → nobody
status: New → Fix Committed
Bill Erickson (berick) on 2018-03-29
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers