Older version of a user installed click is not updated by custom or base pre-installed clicks with a more recent version

[Alex Kaluzhny]

When click is asked to list the set of packages for a given user, it walks its way down the list of databases from top (default) to bottom (core). For each database, it checks registrations for that user, followed by registrations for @all. It takes the first registration for any given package name that it finds.

This results both in the user's device using the older version of the software, and the use and reporting of extra storage for multiple copies of the click package.

Uninstalling a package with multiple copies is also confusing for users as only the user copy is uninstalled and the click remains in the list of installed apps/scopes.

[Pat McGowan (pat-mcgowan)]

The changes to the custom tarball are applied as an image diff, so there is no way a single click package would fail to update unless the tarball did not contain the update.

Is there any additional information, did the update really apply?
Model, version numbers would be good but I suspect its too late.

[Kyle Nitzsche (knitzsche)]

Pat, in bug 1476282, the BQ E 4.5 user has OTA5 installed and says he shows exactly this (except for timestamp).

$ system-image-cli -i
current build number: 24
device name: krillin
channel: ubuntu-touch/stable/bq-aquaris.en
last update: 2015-07-21 17:05:57
version version: 24
version ubuntu: 20150713
version device: 20150529-8e13c5f
version custom: 20150709-814-29-21-vivid

He provide a list of his installed clicks (see comment #39).

His list includes: com.canonical.scopes.fbphotos 1.24

I think that OTA5 custom tarball included com.canonical.scopes.fbphotos 1.26

Internally, this was confirmed: OTA4 installed then updated over the air and fbphotos was still 1.24.

Please note that at the time this happened, the store had version1.26 submitted but in review (I don't know whether that could possibly affect this).

[Pat McGowan (pat-mcgowan)]

Flashing ota4 installs version 1.23 of the scope
Flashing ota5 installs version 1.26
Updating from 4 to 5 installs version 1.26

I would therefore assume the user updated to 1.24 from the store and this is somehow related.

"Internally, this was confirmed: OTA4 installed then updated over the air and fbphotos was still 1.24."
How was this confirmed then?

[Pat McGowan (pat-mcgowan)]

I reproduced it by installing a dummy 1.24 version which goes into /opt/click
After an update to ota5 /custom/click contained the latest 1.26 version but the system still reported 1.24 as the active version

click pkgdir com.canonical.scopes.fbphotos
/opt/click.ubuntu.com/.click/users/phablet/com.canonical.scopes.fbphotos

[Kyle Nitzsche (knitzsche)]

So, when I flash ota4 then use system settings to update to ota5, fbphotos is 1.26 (correct from the custom tarball).

However, this user had fbphotos 1.24 after OTA update..

So yeah, I guess they installed 1.24 from store (which perhaps should not be allowed since it is a lower version than 1.26 from ota5).

What was internally reproduced:
1) install ota4

        ubuntu-device-flash \
        --revision 23 \
        touch \
        --channel=ubuntu-touch/stable/bq-aquaris.en \
        --wipe --bootstrap \
        --device krillin \
        --developer-mode --password=1111 \
        --recovery-image ~/bzr/recovery-images/krillin/recovery.img

2. check fbphoto revision:
        click list | grep fbphoto => 1.23

3. U1 creds -> Install fbphotos 1.24 from store

4. reboot

5. install OTA5 from settings.

6. check fbphoto version

        click list | grep fbphoto => 1.24
         But it *should* be 1.26

So it seems the custom tarball fails to update to higher version when the click was installed from the store.

[Pat McGowan (pat-mcgowan)]

Based on the doc

When click is asked to list the set of packages for a given user, it walks its way down the list of databases from top (default) to bottom (core). For each database, it checks registrations for that user, followed by registrations for @all. It takes the first registration for any given package name that it finds.

This does not mention selecting the most recent version which could be seen as a feature if the user wants to use an earlier version. However since installing older packages is not supported from the UI I would argue we should always default to the latest version and not the first match found.

This seems a fundamental incompatibility between image updates and click installs.

FWIW uninstalling the user version (via the UI) is all that is needed to enable the updated version. After the uninstall the store UI incorrectly shows the option to install, but returning to the list refreshes with the correct installed state.

[Colin Watson (cjwatson)]

I'd rather strongly recommend against changing the fundamental database design; I think that if you take that road then you will find yourself playing whack-a-mole with conflicting requirements. Instead, my suggestion would be to arrange for "click hook run-system-hooks" to garbage-collect user registrations in the overlay database that have been superseded by versions in a lower database; that way it's still possible for somebody to temporarily revert a package for testing, but an OTA update would pull them back to the latest version.

[Kyle Fazzari (kyrofa)]

Correct me if I'm wrong, but this seems to be by design. Notice if you go check for available updates, Ubuntu is listed as a separate update to Facebook Photos. It seems reasonable to expect that if I update Ubuntu, Facebook Photos will not be updated, since I didn't select it. Indeed, after the OTA update, if you go back to view available updates, Facebook Photos is still listed there, and if you update there, the user will now be on 1.26.

Colin, are you suggesting adding another system hook, then? Aren't those run on each boot? I can't think of a way to write a system hook that will only force-ably update user-installed apps upon OTA and not on each boot. Thoughts?

[dobey (dobey)]

While this is a slightly annoying bug, it is not new, nor a regression; and requires a somewhat intimate knowledge of the system, to even realize it is being hit. There also appear to be a couple of workarounds for this issue. As such, I'd suggest possibly reducing the priority of this from critical. The bug has existed for well over a year. I clearly remember hitting this same issue in the past, but after working around the problem, was unable to forcibly recreate it, and so didn't file a bug at the time.

[Alejandro J. Cura (alecu)]

I agree that this should not be Critical: after an OTA the user will just see more updates available for the installed apps and scopes, they will not look out of place and the workaround is to just install those.

[Kyle Fazzari (kyrofa)]

We think we have a way forward for fixing this, but want to get some consensus before continuing.

First of all, as Colin mentioned, in order to make sure clicks in /opt are updated when OTA updates install newer versions in /custom, `click hook run-system` needs to be updated to compare those databases and unregister the old versions as necessary.

This change has the side effect (a regression) of making it impossible to sideload an older version of a click, since the system hooks are run on boot: the older versions will be unregistered upon the next boot. We believe this is fixable by comparing the timestamps of a user's registrations with the newer version of the click included in the OTA update, and only unregister if the user's registration is older than the OTA update's.

Unfortunately, that hits another issue where the user registrations timestamps seem to get updated upon every reboot, which means they'll always be newer than the OTA update's. We believe we can resolve this by making the user hooks a little smarter about touching registrations that don't need to be touched, but it still requires a bit more investigation.

Knowing the proposed changes and side effects, how does that sound? Are we okay with the inability to sideload older versions, or should we make sure that continues to work and update the hooks to be a bit smarter?

[Pat McGowan (pat-mcgowan)]

I am more concerned with changing intended functionality, perhaps for multiuser systems although its not clear that will ever be a real requirement for click.

It seems fixing the logic that is unnecessarily updating the timestamps should be done

Should this behavior only be enabled on single user systems where it seems to not make sense? Do we need a new path such as "click hook run-singleuser"

[Pat McGowan (pat-mcgowan)]

BTW another undesirable symptom is that a user can uninstall an app only to see it remain in their app scope

[Alejandro J. Cura (alecu)]

I think many of the duplicates assigned to this bug are actually a separate bug.
One bug is about "packages installed by the updater are not released when new versions installed with the image".
The other is "storage view should aggregate different versions of packages with the same name".

So, I'm splitting this bug in two, and proposing a branch for the second.

[Launchpad Janitor (janitor)]

This bug was fixed in the package click - 0.4.40+15.10.20151006-0ubuntu1.1

---------------
click (0.4.40+15.10.20151006-0ubuntu1.1) wily; urgency=medium

  * SECURITY UPDATE: fix privilege escalation via crafted data.tar.gz that
    can be used to install alternate security policy than what is defined
    - click/install.py: Forbid installing packages with data tarball members
      whose names do not start with "./". Patch thanks to Colin Watson.
    - CVE-2015-XXXX
    - LP: #1506467

 -- Jamie Strandboge <email address hidden> Thu, 15 Oct 2015 11:13:36 -0500