Comments on: PackageKit Web Plugin

By: Karl Lattimer

Karl Lattimer — Wed, 10 Sep 2008 13:12:03 +0000

@hughsie: I don’t doubt that it looks safe, and could be, however its not how it looks, its how it looks to someone who will attack it. I mean, after buffer overflows became a null concept the heap overflow rose up, even if you think its safe, even if I think its safe, if everyone who uses it thinks its safe, there’ll still be someone out there who wants to make it unsafe! I learned early on that anything is possible when even the smallest glimmer of an attack vector is opened up.

I don’t understand why you’d actually want to do this kind of thing anyway, it just seems senseless to me! I have an application menu for starting applications, why do it from a web browser?!?!? The reality is a web browser should be used for browsing the web, not managing anything on my machine. Sure I like the idea of a click to install, but I already have that with open with – package installer. This kind of thing always makes me feel uneasy, after seeing some of the crazy stuff that goes on, on the web I feel tingles in my spine when thinking of this.

And you say that there’s no javascript, well at least that’s a sensible sandbox, but what about css and html hackery? It’s amazing what can be achieved with some css to cover up something so a user clicking on something that looks safe, can in fact be a mask for something else.

I’d say before you believe in the code 100% invite some miscreants to find holes in it, until they tire themselves out, offer a cool prize for it and I’m sure you’ll find things in there you wouldn’t expect…

By: patrys

patrys — Tue, 09 Sep 2008 23:27:29 +0000

Owen:

The plugin is prone to phishing as stated in my previous comment. It’s possible to overlay the plugin with custom HTML and have the click event fall through to the plugin (which could cause an otherwise wary user to install a package by clicking an innocent looking link). The URI handler also has the added benefit of working everywhere, not just in a (particular) browser.

By: Marko Anastasov

Marko Anastasov — Tue, 09 Sep 2008 22:13:20 +0000

This is awesome! People will be able to install stuff by just clicking on a link.

By: Owen Taylor

Owen Taylor — Tue, 09 Sep 2008 22:01:19 +0000

A protocol handler is going to give you an experience of “Click this link to run Inkscape if it’s installed, or install it if it’s not installed and it’s available for your distribution”. and if you don’t have PackageKit installed, will then give you the nice “I don’t know how to handle the url packagekit:installOrRun?package=inkscape&desktop=inkscape” experience. (With a plugin you can have fallback content for an embedded object if the plugin is missing.) A content association for YMP files seems similar. You could have a YMP plugin that uses a YMP file as input, but I don’t really see the point as compared to providing the few necessary inputs directly as parameters to the plugin.

By: Garrett

Garrett — Tue, 09 Sep 2008 20:45:55 +0000

So why is this a browser plugin instead of using something like YMP and the 1-click installer (a helper application) from openSUSE? It actually uses PackageKit too… and YMP was definitely designed to be cross-distro. (A single YMP file can specify multiple distros, making it really just a couple clicks away for *any* distribution user to have software easily installed on their computer… all from one single website button without any complexity for the website author.)

If you should have to have a confirmation click anyway, then why not pass it off to an external program to handle it? Why use a browser plugin? (I don’t see any advantages.)

By: patrys

patrys — Tue, 09 Sep 2008 19:59:55 +0000

As reported by others, it’s pretty easy to specify name=Banshee, desktop=banshee, package=buggy. A protocol handler would be more useful from the scripting point of view (select your distro and we’ll give you the right uri) – it would need a confirmation window but that’s needed anyway as it should be relatively easy to cover the plugin with custom html that sends the click through by the means of scripting (please research the very same tricks people use to style file input html widgets).

By: Ka-Hing Cheung

Ka-Hing Cheung — Tue, 09 Sep 2008 18:45:55 +0000

I see, so it puts some more information on the webpage, seems not that critical though as the user can find that out after clicking on it

By: Ka-Hing Cheung

Ka-Hing Cheung — Tue, 09 Sep 2008 18:43:37 +0000

Is there a reason why it’s done as a plugin, and not as a protocol handler (ubuntu uses apt:, I think opensuse uses something else)

By: hughsie

hughsie — Tue, 09 Sep 2008 18:40:33 +0000

Karl: no javascript involved, it’s all HTML then C plugin. Nothing is exported into the DOM. The website can’t interact with the plugin whatsoever. It’s nothing like activex at all, as the plugin has a very narrow and well controlled one way IPC for one certain task. The HTML can never execute an exectuable on the computer, it’s up to the user to click, and then it can only open a .desktop file from a package the user already has installed.

I don’t want to insult you telling you it’s safe, but I would like you to at least look at the design and read the code and you’ll see it’s safe as houses.

By: Owen

Owen — Tue, 09 Sep 2008 18:35:11 +0000

http://git.fishsoup.net/cgit/packagekit-plugin/tree/README has some discussion of the display name issue. Basically, you can probably disguise it in the web page anyways, so it’s better to deal with confirmation after the user clicks, not to try to make them avoid clicking. And a package that is in the configured repo, and opens a security hole just by running it (no arguments, no file input) seems like a rare thing. The advantage of providing the display name is making the plugin understandable on failure.