Use --version-path and --version-key when available, in Keystone 1.0.9.2318 and later

Use --version-path and --version-key when available during an update, if
Keystone 1.0.9.2318 or later is present.

Providing this data to Keystone will cause it to check the application's
Info.plist to determine the installed version, rather than using the version
embedded within the ticket. The version in the ticket can become stale in
some rare situations through innocent user action.

This allows a user to replace Chrome with an earlier version (perhaps on
another channel) and not get "stuck" without autoupdates until that channel
catches up with the version listed in the ticket. (b/2506062)

This also prevents Keystone from believing an update is still available if
Chrome is updated but not restarted and the user subsequently promotes
Chrome's user ticket to a system ticket from within Chrome. (crbug.com/38696)

BUG=38696, 83082
TEST=none
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=86388

[Mark Mentovai, 2011-05-18 17:52:11]

Not ready for chicken yet. Waiting to hear back from Alex.

[TVL, 2011-05-18 17:57:31]

http://codereview.chromium.org/7029034/diff/1/chrome/installer/mac/keystone_i...
File chrome/installer/mac/keystone_install.sh (right):

http://codereview.chromium.org/7029034/diff/1/chrome/installer/mac/keystone_i...
chrome/installer/mac/keystone_install.sh:380: # Returns 0 (true) if ksadmin
supports --version-path and --version-key.
for some reason I thought this had been around a long time

http://codereview.chromium.org/7029034/diff/1/chrome/installer/mac/keystone_i...
chrome/installer/mac/keystone_install.sh:1088: --version-path
"${installed_app_plist_path}"
so my fear here is user installs where they drag it to a new place.  Do we need
to update this path in our user ticket each time chrome is launch or will this
end up pointing at something that no longer exists?

[Mark Mentovai, 2011-05-18 18:10:42]

http://codereview.chromium.org/7029034/diff/1/chrome/installer/mac/keystone_i...
File chrome/installer/mac/keystone_install.sh (right):

http://codereview.chromium.org/7029034/diff/1/chrome/installer/mac/keystone_i...
chrome/installer/mac/keystone_install.sh:380: # Returns 0 (true) if ksadmin
supports --version-path and --version-key.
TVL wrote:
> for some reason I thought this had been around a long time

It’s been around in the Keystone trunk for about a year, but it didn’t actually
make it into any releases until 1.0.9.2318.

http://codereview.chromium.org/7029034/diff/1/chrome/installer/mac/keystone_i...
chrome/installer/mac/keystone_install.sh:1088: --version-path
"${installed_app_plist_path}"
TVL wrote:
> so my fear here is user installs where they drag it to a new place.  Do we
need
> to update this path in our user ticket each time chrome is launch or will this
> end up pointing at something that no longer exists?

If the plist at --version-path doesn’t exist, ksadmin will use the version
embedded in the ticket.

I agree it’d be best to get an updated registration framework so that we can
maintain these fields in the user ticket at registration time (app launch). I’ve
asked Alex about getting a 1.0.9.2318 registration framework, but he said he’s
been holding off on the release because of some other concerns, and will get
back to me later today. That’s why this is “on ice” and not ready for checkin
yet.

[TVL, 2011-05-18 18:12:01]

lg

[Mark Mentovai, 2011-05-23 21:44:02]

This is ready now, I’ll check it in along with
http://codereview.chromium.org/6990046.

[TVL, 2011-05-24 01:35:40]

lg