Qubes templates: graphical updater (Apper) broken

phabricator-migrator · February 19, 2024, 5:48pm

Information

ID: 373
PHID: PHID-TASK-xclhdyi75ytd57hfmcbr
Author: Patrick
Status at Migration Time: resolved
Priority at Migration Time: Normal

Description

Issue:

The graphical updater (Apper) broken is broken. It reports no upgrades, even if there are upgrades.

prerequsite knowledge:

apt-get upstream bugs: Dev/Automatic Updates - Kicksecure
Security Issues when using apt-get update in Scripts: Dev/Automatic Updates - Kicksecure
apper has proven to be too buggy in previous versions of Whonix: Dev/Automatic Updates - Kicksecure
secure apt-get automation is difficult for many reasons: Dev/Automatic Updates - Kicksecure

TODO decision:

On Dev/Automatic Updates - Kicksecure I’ll explain, why graphical updaters are insecure. Should we remove Apper?

TODO technical:

remove apper?
remove apper menu entry?

Comments

nrgaway

2015-07-04 02:12:23 UTC

Patrick

2015-07-04 02:46:34 UTC

(Messed up ticket description. Fixed now.)

On Dev/Automatic Updates - Kicksecure I’ll explain, why graphical updaters are insecure, a usability mess and why replacements have a scope of maintain a complete separate upstream project. I think in the absence of secure and usable gui utilities, we should avoid them and refer to cli tools. That’s awful, but the only workable secure choice I can see at this time.

An Apper security issue…

Functional sources.list snippet.
deb http://security.debian.org wheezy/updates main contrib non-free
Non-functional sources.list snippet with a purposed typo for demonstration purposes.
deb http://ecurity.debian.org wheezy/updates main contrib non-free
Apper won’t complain about this. Therefore with a trivial DNS based denial of service, a user can be prevented to fetch security updates. Therefore in my opinion Apper disqualifies for an update gui for a security focused operating system.

nrgaway

2015-07-04 03:55:55 UTC

Patrick

2015-07-04 22:29:43 UTC

maybe even part of a wrapper that verifies the source.list sources first?

Btw, it’s not just about messed up sources.list. This was only a cheap trick to demonstrate the issue. The same would happen if an access level (wifi) or ISP level adversary would run an active man-in-the-middle attack preventing the connectoin to the security repository.

I guess a simple sanity test, checking if the right security repository is enabled in sources.list would be a good feature for whonixcheck or some other maybe-existing more general security check tool for Debian.

The code for finding typos that lead to DNS or connection errors might be already written. (packagekit)

Or what about writing some utility,

It’s a huge task of the size of a separate project.

Tried to explain why this is difficult to invent a secure gui based apt-get upgrader in this very chapter: Dev/Automatic Updates - Kicksecure.

Few more keywords to illustrate why this is a complex project… It follows a list of stuff from the top of my head that is difficult to handle in a gui upgrader

debconf questions

dpkg interactive conflict resolution dialog

DNS failures

connection failures (ISP’s preventing connections to apt repositories for whatever reason; targeted attacks)

installation issues due to broken dependencies

hold back packages

notifications about packages available for autoremoval

packages in Debian stable, that that have no security support (T135)

slow retrival attacks (Defined by TUF: Attacks and Weaknesses (w).)

endless data attacks (Defined as per TUF.)

retrieved package release who’s valid-until field [when forgotten to refresh the repository, eventual roll back (TUF) or indefinite freeze (TUF) attack]

invalid signatures

expired signing keys

interrupted upgrades

failing Debian maintainer scripts

locked apt (some other process still using apt or died)

permission issues

Instead of inventing yet another gui upgrader - which is a giant task to do securely - I think that time should be rather used to work on the fixing the existing ones. Such as apper or (ubuntu-)software-center. (software-center was ported to Debian wheezy, but didn’t make into Debian jessie.)

Updating using a gui is really pretty. Works in many cases. But in the corner cases, you have to refer users back to console based apt-get upgrades. Since secure upgrades are currently not possible using gui tools, because the existing ones don’t handle [at least inform] many failures, I think the reasonable thing for security focused Debian derivatives is to train users to use apt-get command line. They get to know how it’s normally looking and are more likely to notice any issues.

However, what could be done and with reasonable work and maintenance effort would be a secure gui update notification tool. Using a /usr/lib/apt-get-wrapper like approach. Just notification if updates are available or not. Like whonixcheck does. No actual apt-get upgrade.

nrgaway

2015-07-05 00:32:19 UTC

Patrick

2015-07-05 01:38:23 UTC

Agreed, cli usage is user unfriendly. Crystal clear. No argument from me. One of the main reasons why mainstream users are scared of Linux distributions.

I can do my best testing for keyword items, reporting bugs upstream. (Once we picked a gui upgrader.) Could you attach patches to those in python or C++? (Depending on which one we choose?)

Choosing one is not simple. It’s not just about keyword items.

Let’s brainstorm more criteria for choosing which one deserves our contributions…

keyword items

language written in for simplicity of patches: I guess you prefer python over C and C++?

language written in for security: python preferred over C

future proof: Is the project going to be abandoned anytime soon?

usability of the tool

responsiveness upstream: How cooperative upstream is, how well you get along with them.

activity upstream: If they’re still alive, active and kicking or if the project is barely left alive.

source code management used by upstream: git or bazzar or worse?

dependencies: okay to depend on KDE or so?

packages already in Debian [/ Fedora] repository: Work saving, if already packaged there, so the packaging work and getting it upstream is already done.

A few I have in mind:

ubuntu-software-center
** Good: usability, Last time I checked, it was the most pretty one. Best usability - apart from it’s bugs such as crashes. Maybe they fixed that.
** Good: written in python
** Bad: Has “ubuntu” in it’s name. Doesn’t demonstrate their interest in having it work well in Debian.
** Bad: (imho) using bazzar. [Perhaps I am too lazy, ignorant and wouldn’t know why they bother with something other than git.]
** Bad: Not in Debian repository. (Removed since jessie.)
** Question: It’s also political. Would you like to try to talk ubuntu-software-center developers about becoming agnostic, fully supporting debian?

Synaptic:
** Bad: Old. Usability sux imho. Not much progress over the years.

Apper:
** Bad: dependencies: depends on KDE
** Bad: written in C++
** Medium: usability, oh well…
** Good: Using packagekit by freedesktop.org, the ones who care about standards and doing things the-right-way™

gnome-packagekit:
** Bad: written in C
** usability: worse than Apper?

Looks like there are not that many to choose from.

mfc

2015-07-08 02:27:18 UTC

Don’t forget Muon, which is Qt-based, at least Kubuntu uses it. Could be
worth evaluating.

List of more:
APT (software) - Wikipedia

Patrick (Patrick Schleizer):

Patrick added a comment.

Agreed, cli usage is user unfriendly. Crystal clear. No argument from me. One of the main reasons why mainstream users are scared of Linux distributions.

I can do my best testing for keyword items, reporting bugs upstream. (Once we picked a gui upgrader.) Could you attach patches to those in python or C++? (Depending on which one we choose?)

Choosing one is not simple. It’s not just about keyword items.

Let’s brainstorm more criteria for choosing which one deserves our contributions…

keyword items

language written in for simplicity of patches: I guess you prefer python over C and C++?

language written in for security: python preferred over C

future proof: Is the project going to be abandoned anytime soon?

usability of the tool

responsiveness upstream: How cooperative upstream is, how well you get along with them.

activity upstream: If they’re still alive, active and kicking or if the project is barely left alive.

source code management used by upstream: git or bazzar or worse?

dependencies: okay to depend on KDE or so?

packages already in Debian [/ Fedora] repository: Work saving, if already packaged there, so the packaging work and getting it upstream is already done.

A few I have in mind:

ubuntu-software-center

Good: usability, Last time I checked, it was the most pretty one. Best usability - apart from it’s bugs such as crashes. Maybe they fixed that.

Good: written in python

Bad: Has “ubuntu” in it’s name. Doesn’t demonstrate their interest in having it work well in Debian.

Bad: (imho) using bazzar. [Perhaps I am too lazy, ignorant and wouldn’t know why they bother with something other than git.]

Bad: Not in Debian repository. (Removed since jessie.)

Question: It’s also political. Would you like to try to talk ubuntu-software-center developers about becoming agnostic, fully supporting debian?

Synaptic:

Bad: Old. Usability sux imho. Not much progress over the years.

Apper:

Bad: dependencies: depends on KDE

Bad: written in C++

Medium: usability, oh well…

Good: Using packagekit by freedesktop.org, the ones who care about standards and doing things the-right-way™

gnome-packagekit:

Bad: written in C

usability: worse than Apper?

Looks like there are not that many to choose from.

TASK DETAIL
https://phabricator.whonix.org/T373

EMAIL PREFERENCES
Login

To: Patrick
Cc: HulaHoop, Patrick, nrgaway, marmarek, mfc, MemoryLost, WhonixQubes, troubadour

bnvk

2015-07-09 15:13:44 UTC

Patrick

2015-07-10 16:19:11 UTC

nrgaway

2015-07-10 16:54:14 UTC

HulaHoop

2015-07-11 01:47:36 UTC

Patrick

2015-07-14 14:11:13 UTC

nrgaway

2015-07-14 17:23:55 UTC

I did have a look at the software over the weekend, which BTW is GNU GPL v3 licensed.

I don’t think it would be too much of a task to maintain software-center in Debian but I have concerns about supporting software-center being:

I am unsure if this would solve the GUI update requirement. Now, I do not have Ubuntu installed to test, but isn’t the software-center package just used to search and install packages? From what I recall, Ubuntu still used packagekit or something similar to handle the updating process of packages.

As previously mentioned, it does not support Fedora or RPM package backend

A RPM backend could be added, but would take time to implement

there are many features of software-center we do not need (or do we) such as reviews and app purchases. It adds an extra layer of complexity to configure for these features.

software-center is about 60,000 lines of code. There are other solutions like lubuntu-software-center that may be worth considering as well.

I think what makes most sense is to either report the security issues or fix packagekit’s aptcc backend for apt and submit upstream?

nrgaway

2015-07-14 17:31:59 UTC

Patrick

2015-07-14 22:18:09 UTC

As previously mentioned, it does not support Fedora or RPM package backend

A RPM backend could be added, but would take time to implement

In long term, not required. The plan is to throw out Fedora anyhow. Source:
Add support for mounting exFAT partitions by default · Issue #1054 · QubesOS/qubes-issues · GitHub

there are many features of software-center we do not need (or do we) such as reviews and app purchases. It adds an extra layer of complexity to configure for these features.

Agreed. So this would require an if/else patch to have this code disabled on non-Ubuntu?

There are other solutions like lubuntu-software-center that may be worth considering as well.

Yes.

I think what makes most sense is to either report the security issues or fix packagekit’s aptcc backend for apt and submit upstream?

Contributing to packagekit seems sensible in any case. Since most new graphical package managers seem to be based on packagekit nowadays. WIth respect to noninteractivness and no questions during installation (Hughsie’s Law) they seem to have the right mindset.

HulaHoop

2015-07-28 15:53:52 UTC

Patrick

2015-08-19 18:03:19 UTC

nrgaway

2015-08-19 19:21:08 UTC

I am still working on this. I spent 3 days on it a few weeks ago. I ended up reviewing the source code of many packages, and did a short audit on packagekit and gnome-packagekit to find ways to resolve issue.

Step one was to get gpk working in both Fedora and Debian. It works in Debian, not so much in fc21 (well, it did not a few weeks ago).

Next step was to get it to update dpkg index on start. From what I can remember from memory and without reviewing my notes, the newer version of packagekit removed portions of the update code and relies on the unattended-upgrades package for periodic updates.

I understand though that there is a way to force the index to update still in Debian when gpk is launched from gnome’s settings menu; which I have not had success in locating yet. I am going to install a HVM version of standard Debian and test there.

Once these steps are complete, we can apply any security patches to packagekit backend aptcc? (again from memory) and submit upstream.

Timeline is October since I have other deadlines items to complete first but plan to work on this as often as time permits.

mfc

2015-09-21 12:18:17 UTC

Honestly I think this issue has ballooned into a bunch of different (but related) issues.

The “prerequisite knowledge”, “todo decision”, actually are in no way related to the issue at hand.

Right now the GUI updater in Qubes doesn’t work. We need to make it work. “Work” is defined as display updates when there are updates, and attempt to update those packages.

GUI updater works in Debian, Fedora, Ubuntu, Kubuntu, Linux Mint, etc. Is it an issue with how Qubes interacts with Apper that can be fixed? Then let’s fix whatever isn’t working. Is it an issue with Apper itself that cannot be fixed? Then it sounds like the program doesn’t do its intended functionality and it shouldn’t exist. So then we can switch to another program.

Yes there are problems with exit codes, automation etc. Those seem to be more general issues with updaters, not related/intrinsic to GUI updaters. That is a longer term project. This issue is / should be about making Apper work in Qubes (just as poorly as it does in other distros).

Patrick

2015-09-21 13:52:48 UTC

Your criticism and attempt to move this forward is well appreciated! Thanks for posting qubes issue Templates can’t be updated via GUI Package Updater / Apper!

The worst case scenario is defined as noticing that updates are missing while thinking that updates have been applied cannot be fixed with a quick fix.

Right now the GUI updater in Qubes doesn’t work. We need to make it work. “Work” is defined as display updates when there are updates, and attempt to update those packages.

GUI updater works in Debian, Fedora, Ubuntu, Kubuntu, Linux Mint, etc. Is it an issue with how Qubes interacts with Apper that can be fixed? Then let’s fix whatever isn’t working. Is it an issue with Apper itself that cannot be fixed?

It’s both.

Qubes specific issues that makes it totally not work for most users.

Templates can't be updated via GUI Package Updater / Apper · Issue #1197 · QubesOS/qubes-issues · GitHub

Graphical update of Fedora 21 template reports no updates available · Issue #982 · QubesOS/qubes-issues · GitHub

Apper warns you haven't updated in months when you have · Issue #968 · QubesOS/qubes-issues · GitHub

I guesstimate the existing issues Apper [and other existing gui updaters] will sooner or later lead to the worst case scenario situation for ~40% of users. That leads to grave confusion in user support situations. Whonix used to have Apper installed by default but it has been removed just for this reason. (I’ll made up that percentage out of experience with various installations of Apper on personal systems + Whonix support experiences.)

Then it sounds like the program doesn’t do its intended functionality and it shouldn’t exist. So then we can switch to another program.

I don’t think working alternatives to Apper are available for installation. Definition would not be fulfilled for the display updates when there are updates part for a big percentage of users.

Yes there are problems with exit codes, automation etc. Those seem to be more general issues with updaters, not related/intrinsic to GUI updaters. That is a longer term project. This issue is / should be about making Apper work in Qubes (just as poorly as it does in other distros).

Let’s use Templates can’t be updated via GUI Package Updater / Apper for the short time fix. And this ticket for the long time fix.

Until there is a long term fix (working, secure, usable gui updater), it boils down to a question of security vs usability. I only see two options:

a) The secure option with bad usability is fall back to cli updating until the long term fix is in place.

b) The insecure option with almost as bad usability (common worst case scenario) is the short time fix + Apper.

Unless there is a dedicated developer working on the long term fix, I am very pessimistic. There probably won’t be any remotely great solution to this issue.

mfc

2015-09-21 14:17:48 UTC

troubadour

2015-10-06 14:36:13 UTC

Patrick

2018-11-12 07:47:47 UTC