Closed Bug 640159 Opened 10 years ago Closed 10 years ago

Should update to very latest release version, not latest of branch (at least when manually updating)

Categories

(Toolkit :: Application Update, defect)

Product:
Toolkit
Component:
Application Update
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED DUPLICATE of bug 349579

People

(Reporter: BenB, Unassigned)

Details

Me, computer-support for a friend, by phone. I notice the app doesn't behave correctly, and find that her version is outdated (TB 3.0 in this case). I tell her to Help | Update (that command alone takes several minutes to communicate). We wait until it downloads, she restarts the app. It still misbehaves, because the updater updated to TB 3.0.10 - which is long EOLed.

Why does the updater update to an ***EOLed*** release??? Even on manual update?

Mark Banner wrote:
> Due to the way updates work, and the required testing matrix,
> a user that is on one security branch typically has to update
> to the latest release on that branch before upgrading to the latest
> major release.

That may be reasonable, if you assume automatic *and* constant updates.

It totally fails, if
a) automatic update fails and the user or the "local computer guy" tries to update later, like in my situation with my friend. If I *manually* update, I want the very latest.
b) this is a machine which is not regularly used. For example, many of my VMs are not run for months. Same is true in other situations. I want them automatically updated to the latest version, including the latest major version, directly. With the current updater, it will take several days until I am at the latest version, during which time I am vulnerable.

When I manually update, I will *not*

  1. update FF 3.5.1 to FF 3.5.22, including
        1. Help|Update
        2. wait for download
        3. click to restart
  2. then update FF 3.5.22 to FF 3.6.17, including
        1. Help|Update
        2. wait for download
        3. click to restart
  3. then update FF 3.6.17 to FF 4.0, including
        1. Help|Update
        2. wait for download
        3. click to restart

That's not feasible. If I say "update", and I end up at 3.5.22, although the newest is FF 3.6.17 or FF 4.0, I conclude that the update is simply broken, because it didn't do what I say. Going through all the steps above is not realistic.

I will just go to the website and download the new EXE. Which is total FAIL for the update function. And also is a security-problem, because a new EXE means a new trust-anquor, an opportunity to MITM me.

I understand the test matrix concern. Why can't the updater, when it sees that the latest version is another major branch, just fetch a full package (no binary diff) and install that? I thought it already does that, and if so, I don't understand the problem. Testing-wise, it's equal to a new download.

If necessary, just download the normal installer EXE, verify it, and run the normal installer in update mode.
(I've written several app updaters myself before, and this last method is fairly fool-proof.)
This bug may be one of the reasons for a big chunk of the machines which are running outdated versions.
Not every user wants to do a major update as soon as it is available, because it might be incompatible yet with his favorite extensions, or he doesn't like the new features, like the awesomebar introduced with Firefox 3.0 (http://techdows.com/2009/08/mozilla-awesomebar-concerns-made.html) or the Quick Filter bar introduced with Thunderbird 3.1 (http://groups.google.com/group/tb-planning/msg/83a3422b39db035d)

Bug 349579 might be of interest: give the user a choice in the software update wizard to choose between major and minor update, instead of having minor trump major.

Another improvement would be to check for updates right after having applied an update, at least if automatic update checking has been turned off. This would also cover the case where the download of an update started in the background, didn't finish, gets resumed later on and completes at a time where the next minor update is available already.

Note that this is a product decision as well:
It has been suggested to remove the migration code for the 2.x -> 3.0 or 3.1 major update for Thunderbird 3.3. "So the recommended update route for users will be 2.0.x (or 3.0.x) -> 3.1.x -> 3.3.x"
http://groups.google.com/group/tb-planning/msg/099e9388af801bce

So I'd suggest to close this bug and file more specific bugs.
> Not every user wants to do a major update as soon as it is available,

Yes, I understand and respect that. (That why I differentiated manual and automatic update above.) Bug 349579 seems like the correct solution, thanks for the pointer.

Please note that I consider this bug a *major* bug in the updater, so I don't care what is necessary to fix this, but it can't stay as-is.

> It has been suggested to remove the migration code for the 2.x -> 3.0 or
> 3.1 major update for Thunderbird 3.3. "So the recommended update route
> for users will be 2.0.x (or 3.0.x) -> 3.1.x -> 3.3.x"

Frankly, that's nonsense. Nobody will install an intermediate version just to update to a higher one.

This whole argumentation falls short, because "Get latest release as EXE installer" is a path that people will take anyway, and it therefore must work and be supported. If that's broken, you're just closing your eyes from reality. Therefore, the updater doing the very same is guaranteed to work, as well.
Depends on: 349579
(In reply to comment #3)
> This whole argumentation falls short, because "Get latest release as EXE
> installer" is a path that people will take anyway, and it therefore must work
> and be supported. If that's broken, you're just closing your eyes from reality.
> Therefore, the updater doing the very same is guaranteed to work, as well.

I think it is worth remembering that the people who have turned off automatic updates are exposing themselves to issues. If they don't update frequently, there's nothing we can do about that. Offering the latest version helps a little, but not much IMO.

We also need to remember that you can't always offer major updates to everyone. For instance, we have only ever really offered major updates to users of 2.0.0.24. Why? because the update mechanism didn't have a platform parameter (iirc) in it at the time, so we'd run the possibility for offering updates to people on obsolete platforms and then busting them, which is probably even worse than not offering the latest version.

I believe we will have similar reasons for not being able to offer Mac users on older 1.9.2 branch versions updates to 2.0 branch because of a change in the update mechanism. However, its this kind of thing that makes the testing matrix complex and requiring lots of testing for what is probably relatively few users.
> people who have turned off automatic updates are exposing themselves
> to issues.

You said yourself that there are cases where automatic update simply doesn't work. You can't just blame users for that.

Some of the use cases above do not involve turning off automatic updates, but simply not using the machine for a while. You can't require people to use *all* of their computers *regularly*. When I start using an older machine (or VM) again, I must be able to update it within minutes, not hours or days, to make it usable again.

Please note that not even the manual update works. There is absolutely no excuse for that.

Leaving people on old versions with security holes, without even notifying them about it, is simply not acceptable, in any case, even in EOL scenarios.

As I said, I've written several different app updaters myself in the past, and I was responsible for them working properly, even in an app with several million users. I understand there are problems, but they can all be solved, too, often with quite simple solutions.

---

Possible solutions:
- Full package (non-diff) update
Add feature in updater (if not already existing) to install a given version as full package, not as binary diff. That means you can update an arbitrary version to the any other later version.
Given that the normal installer can do that, you can do the very same that the installer does, so it's possible.

- Normal installer
If above fails, add feature in updater to download, verify and start the normal installer EXE.
If you want to be nice, the installer could be run in silent mode (I think that already exists, too).
This basically does exactly the same as a user would do manually by going to www.mozilla.com and downloading the installer. We save the user to do that manually and we additionally verify it, preventing the dangerous MITM attack that a manual installer download is subject to.
Implementation: That's trivial to implement, I already implemented that myself before. verification is also not a problem, as the updater can already checksum downloads.

- Messagebox
If all fails, e.g. the user's operating system or CPU (e.g. Mac OS 9) is no longer supported, at least give the user a message saying that a) there are no more updates for him b) there are *known* security bugs, and he *must* act (e.g. buy a new computer) c) offer suggestions what he can do (if any). Implementation: Technically, that's trivial, it's just a dialog box with a (translated) human-readable text. IIRC, I also did implement that in an updater.
There is no requirement to update to the latest minor before updating to the latest major. For example, iirc Firefox has been advertising updates to 3.0 users to update to 3.6 and thereby skipping 3.5.
(In reply to comment #6)
> There is no requirement to update to the latest minor before updating to the
> latest major. For example, iirc Firefox has been advertising updates to 3.0
> users to update to 3.6 and thereby skipping 3.5.

But you don't advertise major updates to all 3.0 users on any version of 3.0 do you?
To be honest, I haven't checked but there is no reason other than time not to. The same goes for offering partial major updates.
(In reply to comment #0)
> Me, computer-support for a friend, by phone. I notice the app doesn't behave
> correctly, and find that her version is outdated (TB 3.0 in this case). I tell
> her to Help | Update (that command alone takes several minutes to communicate).
> We wait until it downloads, she restarts the app. It still misbehaves, because
> the updater updated to TB 3.0.10 - which is long EOLed.
> 
> Why does the updater update to an ***EOLed*** release??? Even on manual update?
Because that is what is advertised to the clients. What to advertise to the clients is decided by drivers and not application update.

> Mark Banner wrote:
> > Due to the way updates work, and the required testing matrix,
> > a user that is on one security branch typically has to update
> > to the latest release on that branch before upgrading to the latest
> > major release.
This is not due to the way updates work. It is due to how we test and I wouldn't be surprised if there are other reasons people have for doing it this way on the backend.

As filed this bug is either invalid or a dupe of bug 349579 since the application update component can update to the latest.
Status: NEW → RESOLVED
Closed: 10 years ago
No longer depends on: 349579
Resolution: --- → DUPLICATE
Duplicate of bug: 349579
Are all of the proposals in Comment 5 implemented? If not, then this bug is valid.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Also, the bug states that a *manual* update should always give the very latest version.

This bug states a real, serious problem. I don't care why it exists, just that it gets fixed. Whatever is the reason why it's not happening, solve these reasons. I made enough proposals which are possible practically. I know it's possible, because I did it myself, also for an app with millions of users.

In other words, please don't say "This is not possible, because...", but "This poses the problem ..., but we could solve that with ...".
(In reply to comment #10)
> Are all of the proposals in Comment 5 implemented? If not, then this bug is
> valid.
I'll go over the comments proposals one by one since I resolved it based on comment #0.

(In reply to comment #11)
> Also, the bug states that a *manual* update should always give the very latest
> version.
Manual updates can be differentiated already and it is up to the backend to serve the most appropriate update based on this. You can file a separate releng bug for each app for that and drivers for each app can decide if they would like to implement your suggestion. For example, we have several times in the past offered a Firefox major update for manual checks and minor updates for background checks.

> This bug states a real, serious problem. I don't care why it exists, just that
> it gets fixed. Whatever is the reason why it's not happening, solve these
> reasons. I made enough proposals which are possible practically. I know it's
> possible, because I did it myself, also for an app with millions of users.
I have brought what you suggest up several times in discussions myself. The problem with this bug is that at the very least many of the things you suggest can't be implemented via the application update component and will require bugs filed in a component where it will be seen by those that can implement it.

> In other words, please don't say "This is not possible, because...", but "This
> poses the problem ..., but we could solve that with ...".
I am by no means saying that... I am saying that as filed this bug will likely not get fixed.
(In reply to comment #5)
> > people who have turned off automatic updates are exposing themselves
> > to issues.
> 
> You said yourself that there are cases where automatic update simply doesn't
> work. You can't just blame users for that.
> 
> Some of the use cases above do not involve turning off automatic updates, but
> simply not using the machine for a while. You can't require people to use *all*
> of their computers *regularly*. When I start using an older machine (or VM)
> again, I must be able to update it within minutes, not hours or days, to make
> it usable again.
> 
> Please note that not even the manual update works. There is absolutely no
> excuse for that.
> 
> Leaving people on old versions with security holes, without even notifying them
> about it, is simply not acceptable, in any case, even in EOL scenarios.
> 
> As I said, I've written several different app updaters myself in the past, and
> I was responsible for them working properly, even in an app with several
> million users. I understand there are problems, but they can all be solved,
> too, often with quite simple solutions.
> 
> ---
> 
> Possible solutions:
> - Full package (non-diff) update
> Add feature in updater (if not already existing) to install a given version as
> full package, not as binary diff. That means you can update an arbitrary
> version to the any other later version.
> Given that the normal installer can do that, you can do the very same that the
> installer does, so it's possible.
Already possible via the complete update and we already do that when a client is more than one version behind or it is a major update (note: completes are not required and this is just a resource optimization for testing / mar generation)

> - Normal installer
> If above fails, add feature in updater to download, verify and start the normal
> installer EXE.
> If you want to be nice, the installer could be run in silent mode (I think that
> already exists, too).
> This basically does exactly the same as a user would do manually by going to
> www.mozilla.com and downloading the installer. We save the user to do that
> manually and we additionally verify it, preventing the dangerous MITM attack
> that a manual installer download is subject to.
> Implementation: That's trivial to implement, I already implemented that myself
> before. verification is also not a problem, as the updater can already checksum
> downloads.
This is wontfix. We already provide a link to download the installer after a complete update fails. If there was data that showed updates repeatedly failed that couldn't be addressed in the updater itself and the application is in a useable state after the failure then I would consider this. Even then, developer time is better spent on improving the success rate of updates.

> - Messagebox
> If all fails, e.g. the user's operating system or CPU (e.g. Mac OS 9) is no
> longer supported, at least give the user a message saying that a) there are no
> more updates for him b) there are *known* security bugs, and he *must* act
> (e.g. buy a new computer) c) offer suggestions what he can do (if any).
> Implementation: Technically, that's trivial, it's just a dialog box with a
> (translated) human-readable text. IIRC, I also did implement that in an
> updater.
That sounds like it is bug 393782

Make sense?
> I have brought what you suggest up several times in discussions myself.

That's great to hear!

[ Responses to proposals ]

Good to see that these are filed or already working.

If you prefer, we could make this a tracking bug only. But it does state an actual, real problem. I just want to make sure this problem gets resolved, no matter what the reason is, because it can't stay as-is.

I asked Mark on tb-planning what the problems are from his releng perspective. You might know something about FF releng - I know I've seen this problem with FF 3.5. We can discuss based on that how to solve it.

Maybe let me ask these questions:
- Why doesn't Thunderbird update backend return the very latest version (i.e. 3.0.3 updates straight to 3.1.9), if I do "manual update"?
- Why doesn't FF and TB install a major update, even in automatic mode, if I am on an EOLed release branch?
(From my standpoint, if you run EOLed software, you run with known security holes, which is like driving without working brakes. We should not support that at all, and the user has to disable automatic updates, if he insists on wanting that.)
- If the automatic updater notices that I didn't run the app since a long time (>1 month), can it check for updates almost immediately after startup, instead of staggered (random time during the day)?
(In reply to comment #14)
> > I have brought what you suggest up several times in discussions myself.
> 
> That's great to hear!
> 
> [ Responses to proposals ]
> 
> Good to see that these are filed or already working.
> 
> If you prefer, we could make this a tracking bug only. But it does state an
> actual, real problem. I just want to make sure this problem gets resolved, no
> matter what the reason is, because it can't stay as-is.
I don't like tracking bugs very much and there are only two app update bugs that are related.

> I asked Mark on tb-planning what the problems are from his releng perspective.
> You might know something about FF releng - I know I've seen this problem with
> FF 3.5. We can discuss based on that how to solve it.
> 
> Maybe let me ask these questions:
> - Why doesn't Thunderbird update backend return the very latest version (i.e.
> 3.0.3 updates straight to 3.1.9), if I do "manual update"?
> - Why doesn't FF and TB install a major update, even in automatic mode, if I am
> on an EOLed release branch?
How updates are offered is decided by product drivers and implemented by releng.

> (From my standpoint, if you run EOLed software, you run with known security
> holes, which is like driving without working brakes. We should not support that
> at all, and the user has to disable automatic updates, if he insists on wanting
> that.)
> - If the automatic updater notices that I didn't run the app since a long time
> (>1 month), can it check for updates almost immediately after startup, instead
> of staggered (random time during the day)?
It checks every 24 hours and if it hasn't checked in 24 hours it will check soon after starting up.

I really don't want the app update component used to hash out details for the different products. As far as this bug is concerned this bug is either invalid or a dupe of bug 349579 or bug 393782.

If you'd like to discuss what updates are being offered for a product I suggest bringing it up in the mailist or newsgroup for the product.
Status: REOPENED → RESOLVED
Closed: 10 years ago → 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 349579
> If you'd like to discuss what updates are being offered for a product
> I suggest bringing it up in the mailist or newsgroup for the product.

I did exactly that, prior to filing this bug, and Mark responded:

> Due to the way updates work, and the required testing matrix, a user
> that is on one security branch typically has to update to the latest
> release on that branch before upgrading to the latest major release.

That first line gave me the impression that it's a weakness in how the updater works. That's why I filed this bug.

Also, I saw the exact same problem with FF 3.5, not just TB. Seems like both teams feel that proper updates are too much hassle or not possible with the updater, which to me means there's a software problem, because it *is* possible with the normal updater.

It cannot be the testing matrix by itself, because the normal installer can update any version to any later version.
I just tried it again:
- Have FF 3.6.13 (Windows)
- Manual update. Updates to 3.6.14 (10 MB download)
- Manual update. Updates to 3.6.16 (10 MB download)
- Manual update. Updates to 4.0 (>10 MB download)

Common, that's ridiculous.
(This shows that not even minor updates are working properly.)
Wow, you are barking up the wrong tree. As I have already explained, the app update code already supports this. I've already provided a couple of methods for communicating this to the people that can change the behavior so I won't do so again.
The only thing not expected there is that 3.6.13 should have gone directly to 3.6.16...perhaps it started to download 3.6.14 so the manual check just resumed the initiated download?
> only thing not expected there is that 3.6.13 should have gone
> directly to 3.6.16...

Exactly, that's why I posted again.

Yes, it started the automatic update. It seemed slow, and I couldn't wait, so I started a manual update by clicking the menu item. It seemed to start the download from the beginning again. And downloaded 3.6.14.

It should download and install straight 3.6.16 (at least), in both automatic and manual mode.
You need to log in before you can comment on or make changes to this bug.