Auto-Update process makes no sense!

[Zakhar]

$ lsb_release -rd
Description: Ubuntu 14.04.1 LTS
Release: 14.04

$ LANG=C apt-cache policy mkvtoolnix
mkvtoolnix:
  Installed: 6.7.0-1
  Candidate: 6.7.0-1
  Version table:
 *** 6.7.0-1 0
        500 http://fr.archive.ubuntu.com/ubuntu/ trusty/universe amd64 Packages
        100 /var/lib/dpkg/status

This bug report is on the mmg (graphical front-end) component of mkvtoolnix.

WHAT I EXPECT TO HAPPEN:
In-app auto-update process makes no sense considering the Ubuntu policy: freezed versions in the repository.
I expect that Application DO NOT have their own update process, and use instead the apt-get standard update process.

WHY:
Because such an independent update processes raise several important issues:
-1) CONSISTENCY: if every program was doing the same, we would end up with as many different update processes as we have applications in our systems: that is called Windows, we don't want it ;-)
-2) STABILITY: updating applications independently of their dependencies raises stability issues, well known in "rolling releases". The Ubuntu repository is precisely there to avoid such inconsistencies, especially in LTS.
-3) PRIVACY: every time mmg checks for updates, it is "calling home" (bunkus.org). We do not necessary want bunkus.org to have our IP address.

WHAT HAPPENS INSTEAD:
mmg DOES have an auto-update process of it's own.
This auto-update process happens without the user explicit agreement, and there is no way to configure it NOT to happen.
As explained above, this COULD break consistency and stability, but my main concern is that it DOES break my privacy by leaking my IP address to bunkus.org every time it checks for updates.

QUICK WORKAROUND:
As a quick workaround for privacy, you can add those 2 lines in /etc/hosts:

# Stop mmg -mkvtoolnix- from bothering us with new releases!
127.0.0.1 mkvtoolnix-releases.bunkus.org
127.0.0.1 www.bunkus.org

(These strings are easy to find with the command: strings /usr/bin/mmg | grep 'http:')

POSSIBLE FIX:
I am not an expert in C++, but in the directory src/mmg
There is a file named:
update_checker.cpp
Line 39 is calling: get_latest_release_version()
It gets the release, then it tests if the release is valid and if it is a newer release (compared to the one currently running).
After that, it throws an event corresponding to the test results.

It should be quite possible to remove all that, and just fire the event: UPDATE_CHECK_DONE_NO_NEW_RELEASE that seems to be fired when there is no newer release.

There could also be a simplest solution as this whole file (update_checker.cpp) is enclose with an:
#if defined(HAVE_CURL_EASY_H)

If it has been tested properly, undefining HAVE_CURL_EASY_H could do the trick!

For sure, as this update process needs been removed, the corresponding Update menu item (under the 'Help' section) does not make sense any more and should be removed as well.
I'm even less a QT specialist, thus I have no clue on how to remove the menu item... although if things were done well, undefining HAVE_CURL_EASY_H should remove the menu as well!

NOTES:
I tag this bug as "Security", as for me "Privacy" falls into that category.
"Calling home" *without the user explicitly requesting it* breaches privacy.
This is generally accepted for automatic updates on Ubuntu repositories that are well secured, but for those who don't even accept that, the automatic checks CAN be turned OFF by the user if he wishes so (then he can make his updates with another method, connect via a proxy, etc...)
In the case of mmg, adding an option to remove the automatic update process, and defaulting it to "no automatic update", would restore privacy, but would still conflict with the Ubuntu releases and update policy.

Furthermore do we know how well bunkus.org is secured? It could be attacked and then serve bogus XML files when update process triggers. If there are security issues in the libraries used during this update process (libcurl, xml parser, etc...) the remote attacker could then use the a compromised bunkus.org to exploit the breaches in those libraries and consequently attack our Ubuntu desktops!

As the "call home" is done in plain http, the leak goes much beyond bunkus.org. As it is not https, there is no way checking we are even really talking to the legitimate bunkus.org. A man in the middle or DNS attack routing bunkus.org elsewhere could also allow exploiting security issues.

If you think this is not (also) a security issue, please feel free to remove the security tag.

Best Regards.
Alain BENEDETTI

[Jamie Strandboge (jdstrand)]

Thanks for taking the time to report this bug and helping to make Ubuntu better. Since the package referred to in this bug is in universe or multiverse, it is community maintained. If you are able, I suggest coordinating with upstream and posting a debdiff for this issue. When a debdiff is available, members of the security team will review it and publish the package. See the following link for more information: https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures

[Zakhar (alainb06)]

Thank you.

I'll coordinate with upstream as this is probably the best way to do clean things.

[Zakhar (alainb06)]

After coordination with "upstream", it is in fact a translation bug.

The French translation is misleading and tends to make you believe that there will really be an update. As matter of fact the feature is only informative and shows you new versions.

We are trying to find a better French translation.

Apart from that, the remaining issue is a "privacy issue" when you ask for this information.

But this was already described earlier on the ticket 1014229.

The information leaked is "only" your IP address. Apart from that the request is super clean. Thus you would leak much more information obtaining the same information with a browser (user agent, etc...), the only problem, described is #1014229 is that the check is done without the user having explicitly opted in.

A little bit the same lengthy discussion as the one about the search in the dash!

I do personally consider that the feature should be OFF by default, and the user would have to OPT-IN if he wants the function.

As for this bug, apart from finding a better French translation, I'll mark it as a duplicate of 1014229, only issue remaining.