ubuntu-device-flash should verify signature in cache matches current keyring before flashing

[Dave Morley]

Now and then an image will fail to flash everything looks good but the image is corrupt. This leads to a gpg check on the phone failing and the image not installing and a non functioning device.

If there is an issue it should throw up an error that asks the user to remove .cache/ubuntuimages and try again.

[Steve Langasek (vorlon)]

It should not ask the user to manually remove .cache/ubuntuimages. udf should manage this cache directly, and if anything fails integrity checks on download it should not be committed to the .cache.

udf should also check when /reading/ a file from the cache that it passes the integrity checks while writing it to the connected device.

Note that the trigger for filing this bug report was a BQ phone whose recovery partition (correctly!) failed to flash the ubuntu partition with an image that failed gpg signature check. But ideally this image would not have gotten onto the phone in the first place if it was corrupted. (I'm assuming this was what happened - Dave, you tried flashing the image onto the device more than once?)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Steve Langasek (vorlon)]

We've managed to track this down on IRC to the fact that both the public
system-image.ubuntu.com and the PES-internal system-image instance are
publishing the same Ubuntu tarballs, but signed by different keys (which is
by design). The result is that if you use the same system to flash images
from both servers that use the same Ubuntu rootfs, you get cache corruption:
the previously-downloaded .asc signature file will be transferred to the
device for use in flashing, but it will not be trusted by the keyring from
the other server, resulting in a failure to flash the image.

I see two ways to address this in udf:

1) verify the signature of the tarball against the to-be-used keyring before
flashing, and if it doesn't verify, discard the signature (and if it was
cached, re-download).
2) always exclude signatures from the cache (they're cheap to re-download
anyway).

Option 1 allows other classes of signature failures to be caught early
before the time-consuming copy to the device, but involves a significant
amount of code duplication. Option 2 should be trivial to implement.