Skip to content
GitLab
  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • T tails
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 920
    • Issues 920
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 19
    • Merge requests 19
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • tails
  • tails
  • Issues
  • #18162
Closed
Open
Created Jan 26, 2021 by intrigeri@intrigeriMaintainer

Upgrader: confusing download failure but upgrade still applied

@emmapeel reported this when upgrading from 4.14 to 4.15 (paraphrased):

  1. The download of the upgrade starts and the progress bar is displayed.
  2. Some minutes pass, the progress bar shows progress.
  3. The 'applying update, network will stop' dialog appears → accept
  4. A dialog tells me the download was not succesful
  5. A dialog tells me to restart now or later appears on top. But the other dialog is still under this.

I could not reproduce.

On emma's resulting upgraded USB stick, the checksum of the files from the IUK overlay (4.15.squashfs, initrd.img, vmlinuz) match the expected ones.

She says she's seen the same problem some months ago. The timing looks suspiciously related to #17310 (closed) → cc @touss.

Looking at the code, I'm not sure how this can happen: the fact the download error dialog is displayed suggests $success is false, so if $self->fatal works as expected, we should abort and not apply the upgrade.

I'm concerned because it might be that we're failing to correctly identify a download error. And in this case, "download error" can mean "the checksum of the downloaded IUK is not the expected one", so this could be a pretty severe security issue.

In passing, I think we could easily make the surrounding code logic more robust. Right now we do my $success = 1; and then rely on the fact that we'll successfully catch all failure modes and set $success to a false value. This looks a bit scary. Instead, I think we should make $success default to a false value, and only set it to a true value on success.

Edited Jan 26, 2021 by intrigeri
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking