Right now Ubuntu’s solution is to run some GNOME application (that is NOT security audited NOR is the GNOME stack of libraries being used security audited either) in a highly predictable way with sudo (therefore, as root).

Worse, they have a (hidden) VTE widget that is running the apt-get or dpkg application as root, too.

Worse, any application and the user herself too can send keystrokes to this widget. Including combinations like CTRL+C. At least on the Ubuntu versions that I tested this against it was even possible to send SIGHUP to apt-get this way (user input breaking the application).

I already filed a bug about this at Ubuntu but that bug was dismissed as invalid. I also, in that bug, tried to discuss a solution for this problem. My ad-hoc solution was to run an ad-hoc SUID root application that gets controlled instructions (over an IPC like pipe() and STDIN or a Unix socket) from the user-application and then executes them.

PackageKid wraps a similar solution (not suid but running a daemon) into a good API, making it possible for any application to securely interact with this.

Questions that are to be asked by the user should in my opinion not be asked by a UI application that runs as root. Something that sits in the middle, converts the questions into something that can’t ever be a security problem and then does IPC with a securely written application to get it done, is a far better architecture for this.

Not only is Ubuntu’s solution a severe security mistake. Running an application as root also creates theming problems, configuration problems (proxy settings, getting user-specific default answers and values, etc).

In stead of for ever postphoning the solution for this problem for the reason “because silly packagers want to ask questions in a non-standard way”, should distributions like Ubuntu attack the problem by supporting a real solution.

The problem is that there are (a small number of) packages that don’t use debconf. These are the packages that won’t install unless the user interacts with it via STDIN/OUT.

The crux of the problem, in my opinion, is that PackageKit attempts to support all packages on all distributions. dpkg explicitly allows packagers to build packages to work with STDIN/OUT. My guess is that most of the packages in question are server-oriented, not desktop-oriented. If PackageKit were design to work with just the GNOME (or desktop-related) packages, then it might be fair to force packagers to follow PackageKit’s requirements. But PackageKit wants to abstract over all packages on all distributions.

James: that sucks, what a shame

“Stop Energy” is a useful tool in engineering. I see lots of enthusiastic developers writing specs and selling their ideas to Ubuntu, but rarely do I see any meaningful set of downsides, caveats etc. For example, packagekit’s apt backend support is terrible, given the proportion of apt users. Directing stop energy into criticism and evaluations helps, I think.