Tails

#2 Updated by intrigeri 2019-09-19 08:33:44

Indeed, so far, we’ve only supported upgrading from a release that is less than 3 months old at the time we’re preparing a new one.
IIRC that was the trade-off we chose when we decided to extend our upgrade support to older versions than the last, currently supported one.
For example, when we released 3.16 in September, we ensured users of 3.14 (May) and newer would have a supported upgrade path, but we did not bother about users of older versions.

We can change this “less than 3 months old”. I can think of no adverse consequence right now. But of course, for this sort of things, we tend to discover the drawbacks much later than at the time when we open the can of worms.

I assume the goal would be to do something like this: “For every 3.x release that has no incremental upgrade path to the new release, we advertise the manual upgrade to that new release”. Right?

Implementation-wise, there are two options:

• Only change the release process doc. It’s very cheap to do. But it’s THE part of the release process that’s already very complex and error prone, and this change would make it significantly worse. IMO, fixing the problem this ticket is about is not worth the cost (stress, energy, money) and the increased risk of breaking things occasionally for more common use cases.
• Automate. It looks totally doable but it’ll take more work. The nice thing is that if we do that, as a bonus it’ll also simplify a lot this same (very complex and error prone) part of our release process. It would be a great and much welcome first step in the “streamline our release process” project we will probably have to tackle soon.

#3 Updated by sajolida 2019-09-19 18:09:35

I don’t quite understand your comment, so I’ll ask for clarification.
I probably should have explained a bit more when I created the ticket,
sorry for that.

> Indeed, so far, we’ve only supported upgrading from a release that is less than 3 months old at the time we’re preparing a new one.
> IIRC that was the trade-off we chose when we decided to extend our upgrade support to older versions than the last, currently supported one.
> For example, when we released 3.16 in September, we ensured users of 3.14 (May) and newer would have a supported upgrade path, but we did not bother about users of older versions.

You mean “automatic upgrade” here, right? Or are we also not supporting
manual upgrades from releases more than 3 months old?

What are users of 3.5 supposed to do if they want to update their Tails
to 3.16?

• Currently Tails Upgrader tells them to do:
  • Manual upgrade from 3.5 to 3.7 (assuming that they can find a 3.7
    image which they can’t).

• I haven’t tested the following steps but I guess that Tails Upgrader
  would then tell them to do:
  • Automatic upgrade from 3.7 to 3.8 (as per
    v1/Tails/3.7/amd64/stable/upgrades.yml)
  • Automatic upgrade from 3.8 to 3.10.1 (as per
    v1/Tails/3.8/amd64/stable/upgrades.yml)
  • Automatic upgrade from 3.10.1 to 3.12.1 (as per
    v1/Tails/3.10.1/amd64/stable/upgrades.yml)
  • Automatic upgrade from 3.12.1 to 3.14 (as per
    v1/Tails/3.12.1/amd64/stable/upgrades.yml)
  • Automatic upgrade from 3.14 to 3.16 (as per
    v1/Tails/3.14/amd64/stable/upgrades.yml)

What I want is to tell 3.5 users to do a manual upgrade to 3.16 straight
away. Tails Upgrader already knows that a manual upgrade is needed and
that the latest version is 3.16.

Why tell users to do a manual upgrade to anything else than the latest
version?

I would also be nice for Tails Upgrader to realize that it’s not worth
doing 5 automatic upgrades to get from 3.7 to 3.16. But I understand
that this might be more complicated and it’s actually a different
problem than the one I reported here. And this might actually get fixed
by Feature #15281.

> I assume the goal would be to do something like this: “For every 3.x release that has no incremental upgrade path to the new release, we advertise the manual upgrade to that new release”. Right?

My goal when opening this ticket was simpler I think. When Tails
Upgrader already detects the need for a manual upgrade, it should always
tell me to upgrade to the latest version.

#4 Updated by sajolida 2019-09-19 22:38:29

Regarding how frequent such cases are (your “more common use cases”), I have the feeling that we’re assuming too much that people upgrade frequently. Tails being an OS that people use from time to time it’s really not clear to me.

For example, from our personas, both Cris and Riou (or Riou’s friends) could leave their Tails unused for many months before their next trip or wave of protests.

So I did some stats :)

I used 28 days of logs from the 3.13.1 release cycle.

It turns out that:

• 16.6% of boots were from a USB stick that had no direct automatic upgrade path to 3.13.1. That’s 3800 boots per day.
• 3.8% of boots were stuck before 3.6, which had broken all automatic upgrades. That’s 860 boots per day. The impact of breaking all automatic upgrades in 3.6 is still huge even 1 year later.

See spreadsheet in attachment.

(I added the ‘Boot/Lifespan’ column to understand the spike of 3.8 users: 3.8 had a much longer lifespan, so many more users still used 3.8 than 3.9.)

#5 Updated by intrigeri 2019-09-20 07:45:57

Hi,

>> Indeed, so far, we’ve only supported upgrading from a release that is less than 3 months old at the time we’re preparing a new one.
>> IIRC that was the trade-off we chose when we decided to extend our upgrade support to older versions than the last, currently supported one.
>> For example, when we released 3.16 in September, we ensured users of 3.14 (May) and newer would have a supported upgrade path, but we did not bother about users of older versions.

> You mean “automatic upgrade” here, right? Or are we also not supporting manual upgrades from releases more than 3 months old?

No, I mean any kind of upgrade path advertised by Tails Upgrader.

When we introduced automatic upgrades, initially we only provided upgrade paths from the current supported release to the new one. A few years later, we extended this to support some more relatively recent releases (IIRC after you noticed users don’t upgrade as fast as we would have thought). But we’ve never advertised via Tails Upgrader any upgrade path for older releases. That’s why I’m claiming we have never supported this use case so far: the UX we’ve been providing in this situation has always been crappy (see below).

To be clear, I’m not saying it’s great, quite the opposite. I just want to establish what’s the baseline, i.e. the situation since 7 years.

> What are users of 3.5 supposed to do if they want to update their Tails to 3.16?

I think the only option we’re providing currently is: read the release notes for the last release on our website and follow the upgrade instructions.

> What I want is to tell 3.5 users to do a manual upgrade to 3.16 straight away.

I see.

After writing all that follows, I realized that Feature #15281 will solve the problem this ticket is about, in most cases: see https://tails.boum.org/blueprint/Endless_upgrades/ (“Support upgrading very old Tails”). So I don’t think we should do anything here right away: instead, we should keep it in mind when implementing Feature #15281.

Still, I believe that what I wrote below will help you understand the constraints we have to work with, so it might be a useful read.

> Tails Upgrader already knows that a manual upgrade is needed and that the latest version is 3.16.
> Why tell users to do a manual upgrade to anything else than the latest version?

Thanks for asking. It helps me understand where you’re coming from. I think you’re misunderstanding how our upgrade system works so I’ll explain. Our upgrade system has no concept of “the latest version” because there’s no such thing as “the latest version” that works in every situation. Instead, our upgrade system learns, from update description files (UDFs):

• which version Y users of version X on the channel Z should upgrade to
• how this upgrade can be performed (depending on whether there are IUKs, on available disk space and memory)

And then, Tails Upgrader proposes the best upgrade path it knows about to the user. The only way to ensure that version Y is up-to-date (in your example: 3.16; in some other cases, it might be 4.0~whatever) is to update UDFs for version X when we release version Y. That’s what I’ve been discussing previously in my “Implementation-wise, there are two options” paragraph.

> I would also be nice for Tails Upgrader to realize that it’s not worth doing 5 automatic upgrades to get from 3.7 to 3.16. But I understand that this might be more complicated and it’s actually a different problem than the one I reported here. And this might actually get fixed by Feature #15281.

Feature #15281 will indeed fix that in most cases.

>> I assume the goal would be to do something like this: “For every 3.x release that has no incremental upgrade path to the new release, we advertise the manual upgrade to that new release”. Right?

> My goal when opening this ticket was simpler I think. When Tails Upgrader already detects the need for a manual upgrade, it should always tell me to upgrade to the latest version.

Ah, this is indeed different from what I’m proposing, which is based on what we decided to do last time we discussed this topic (== what our release process currently documents).

The key difference is about this part: “that has no incremental upgrade path to the new release”. Last time we rethought this topic, we decided that it was better for users to do a multi-step automatic upgrade (for example, N → N+2 then N+2 → N+4) if available, than to force them to do a manual upgrade to the latest version (in my example, N → N+4). I don’t remember the details of why we decided this but it’s surely captured somewhere in Redmine. You seem to be arguing in favor of the opposite preference here. Anyway, I believe that in most cases, Feature #15281 will make this question moot so I don’t think it’s a good time for us to revisit this.

#6 Updated by intrigeri 2019-09-20 07:54:07

> Regarding how frequent such cases are (your “more common use cases”), I have the feeling that we’re assuming too much that people upgrade frequently. Tails being an OS that people use from time to time it’s really not clear to me.

> For example, from our personas, both Cris and Riou (or Riou’s friends) could leave their Tails unused for many months before their next trip or wave of protests.

> So I did some stats :)

Understood. Thanks for doing this research. It shows that “better support Tails older than N months” would provide value to a non-negligible and important part of our user base. Doing so requires more work than “just” (sic) advertising upgrades better, which this ticket is about. To give you an idea, for example, it requires changes to how we update our signing key, and which key we use for signing which UDFs at release time. Similarly, it has ramifications in the TLS certificates area. So I feel this project would be better tracked in its own ticket, where we can discuss and prioritize it separately from the smaller bit this ticket is about. This very ticket would be a nice first step and can be a child of the new ticket that tracks this bigger project.

#7 Updated by sajolida 2019-09-20 18:23:37

Thanks for all the insights about our Tails Upgrader works. I’m learning
thing here :)

>> What are users of 3.5 supposed to do if they want to update their Tails to 3.16?
>
> I think the only option we’re providing currently is: read the release notes for the last release on our website and follow the upgrade instructions.

Ok. Then Tails Upgrader shouldn’t, as of now, tell them that they should
do a manual upgrade to 3.7, which is both impossible (the image is not
available anymore) and in contradiction with what they are supposed to
do. That’s precisely what this ticket is about, nothing else.

Tails Upgrader currently points 3.5 users to the 3.7 release notes.

The message is similar as this one, with 3.5 and 3.7 instead:

https://tails.boum.org/doc/first_steps/upgrade/upgrader_automatic.png

Which then forwards them to the download page which can only download
3.16. So yeah, I don’t think that it will lead people to a critical dead
end and only a conflicting message.

It’s not a really big deal but I don’t think that Feature #15281 will solve
this. For example, it might still affect people running, let’s say 4.9,
while we are at 5.4. Will then be told to do a manual upgrade to 5.1
instead of 5.4?

> So I don’t think we should do anything here right away: instead, we should keep it in mind when implementing Feature #15281.

I understand that Feature #15281 won’t prevent people from having to do manual
upgrades sometimes. For example:

• Between 4.0 and 5.0.
• Whenever we break automatic upgrades like we did between 3.5 and 3.6.

These are the cases that I’m trying to address here.

> there’s no such thing as “the latest version” that works in every situation.

Forgetting about other channels than “stable”, in which situations would
https://tails.boum.org/inc/stable_amd64_version/ not be the latest
version people should do their manual upgrade to?

Off-topic discussion starts here:

>> I would also be nice for Tails Upgrader to realize that it’s not worth doing 5 automatic upgrades to get from 3.7 to 3.16. But I understand that this might be more complicated and it’s actually a different problem than the one I reported here. And this might actually get fixed by Feature #15281.
>
> Feature #15281 will indeed fix that in most cases.

Right.

> You seem to be arguing in favor of the opposite preference here.

I’m not.

> Anyway, I believe that in most cases, Feature #15281 will make this question moot so I don’t think it’s a good time for us to revisit this.

Agreed.

#8 Updated by sajolida 2019-09-20 19:12:43

To summarize the state of my understanding:

When Tails Upgrader detects the need for a manual upgrade on the stable channel, ie. when it displays https://tails.boum.org/doc/first_steps/upgrade/upgrader_automatic.png, it should always point to https://tails.boum.org/inc/stable_amd64_version/.

I don’t think that requires any of the 2 solutions that you drafted in Bug #17069#note-2 and could hopefully be simplier than that.