GNOME Bugzilla – Bug 361559
Epiphany should not offer to open files it considers unsafe
Last modified: 2010-03-25 22:43:43 UTC
How to reproduce: 1. Go to http://www.getdeb.net/ 2. Click on a link to download a deb package Expected result: epiphany would present me the choice to open the file directly in gdebi; Actual result: a dialog appears "Download this potentially unsafe file?" with the content: """ File Type: “Unknown”. It is unsafe to open “gruler_0.6-getdeb1~dapper_i386.deb” as it could potentially damage your documents or invade your privacy. You can download it instead. """
Created attachment 74519 [details] wget --debug output Noteworthy facts: 1. There is an http redirection, which may be confusing Epiphany's MIME detection code; 2. Firefox doesn't exibit this problem.
Mime type: application/x-debian-package 1st, epiphany only knows application/x-deb, so this should be added to data/mime-types-permissions.xml. 2nd, epiphany has app/x-deb as 'unsafe'. Does gdebi allow installing untrusted (i.e. unsigned, or signed with unknown key) debs? If so, it must stay untrusted, else we might mark it 'safe'.
(In reply to comment #2) > Mime type: application/x-debian-package > > 1st, epiphany only knows application/x-deb, so this should be added to > data/mime-types-permissions.xml. You mean epiphany doesn't simply follow the xdg mime database? The application/x-debian-package vs application/x-deb problem should have already been fixed, see https://bugs.freedesktop.org/show_bug.cgi?id=6303 > 2nd, epiphany has app/x-deb as 'unsafe'. Does gdebi allow installing untrusted > (i.e. unsigned, or signed with unknown key) debs? If so, it must stay > untrusted, else we might mark it 'safe'. gdebi allows installation of untrusted packages. But I don't see what we gain in terms of security in forcing the user to save it to a file before installing. Just making it slightly more difficult doesn't stop users from doing it. IMHO it would be much better to present an additional warning dialog when the user chooses to open a untrusted URL.
Anyway, forget the security issue, do you confirm the bug, mime type detection is failing? Because I get that _a lot_, in all sorts of web sites, making me save files to desktop and explicitly open them, instead of opening directly from the web browser, which is very unconfortable :|
The mime permissions db is synched manually not automatically. Try adding the new .deb mimetype to it (data/mime-types-permissions.xml) and see if that fixes it.
If the problem was permission, why would ephy say "Type: Unknown" in the dialog? It should say "Type: Debian Package" or something like that, but add a warning saying it is not secure to directly open this file. Right? But I'll try the permission anyway and see if it changes anything; my bet is not.
Nope, makes no difference; I win my bet :-) Again let me emphasize the bug report title is "Failure to detect MIME type of HTTP stream", not "epiphany doesn't allow installation of debian files from the net". I'm pretty sure MIME type detection fails similarly for other "safe" MIME types; I've seen it happen before, I just didn't bother to file a bug report at the time.
I can confirm that there's a problem in epiphany with regard to mime handling. I get http://img171.imageshack.us/img171/9130/ekrangoruntusuepiphanyjv6.png when I click some links including www.getdeb.net. this is FC6 epiphany 2.16 linked against firefox
w00t w00t, I haven't seen that dialog in my whole life (the what should ephy do with this)!.
Is that some kind of custom Fedora patch to Epiphany?
I can't reproduce this on getdeb.net with Epiphany SVN.
Yes, at least now it seems to detect the MIME type correctly: File Type: “Software package”. But I believe that it is because the server side software has changed, and files are downloaded differently now. The Location: http response seems to be gone now. This does not mean the bug is gone, only that the known way to reproduce it is gone now :|
About debian packages, they are recognized correctly even downloading from a stock apache directory, so I don't think it's a matter of server-side software. Could you find another example to reproduce this?
For the records, /usr/share/mime/application/x-deb.xml leads to “Software package” and the like, and also includes: <alias type="application/x-debian-package"/> Please also note that currently gdebi doesn't register its mime information correctly, see the following Debian bug that I just opened: <http://bugs.debian.org/449495>. I'm still unfamiliar with MIME stuff but I'll try to get back to this bug.
Does anyone know of a link where this problem could be reproduced? The getdeb service seems to have moved away from the strategy they were using in 2006, and now uses the apt: pseudo-scheme.
PPAs in launchpad provide links to download deb packages over http, try e.g. https://launchpad.net/~webkit-team/+archive/ppa/+packages. I just tested with epiphany trunk from git: 1) When the "Automatically download and open files" preference is checked, the file is silently downloaded but not opened. 2) When the "Automatically download and open files" preference is unchecked, I get the "Download this potentially unsafe file?" dialog with three buttons: "Save As...", "Cancel" and "Open". The latter is focused by default. I would expect clicking "Open" to ignore the security warning, but all it does is to silently download the file, just as in 1. Note that "Save As" and "Cancel" work as expected.
Thanks Olivier! The MIME type is detected correctly, and Epiphany is right to not let you 'open' the file, as it may indeed present a security risk - installing deb files automatically would be the same as running exe files automatically in windows, say. So our failure is much smaller than it used to be, and what we need to do is replace that Open button with 'Download', only.
Created attachment 156570 [details] [review] Change the "Open" button to "Download" This trivial patch changes the stock button from "Open" to "Download" when the mime type of the file to download is considered unsafe. I did some functional testing to make sure it doesn't introduce regressions in other cases, with the "Automatically download and open files" preference checked and unchecked.
Review of attachment 156570 [details] [review]: Yeah, that looks right to me, must have missed it while rewriting originally. I don't consider that this needs a freeze break, because it's essentially fixing a UI regression.
(In reply to comment #19) > Review of attachment 156570 [details] [review]: > > Yeah, that looks right to me, must have missed it while rewriting originally. I > don't consider that this needs a freeze break, because it's essentially fixing > a UI regression. We are in hard code freeze, you can't commit anything (regression fix or not) without asking for permission first.
So, do you consider it worth requesting a freeze break? If so, who can do the request and how (I'm not familiar with the procedure yet)? I'll gladly take it if that's something the procedure allows.
Yeah, sorry, just realized that while reading a comment by Dan Winship. I consider this to be worthy of a freeze break, since it is a simple fix for am arguably big regression.
(In reply to comment #22) > Yeah, sorry, just realized that while reading a comment by Dan Winship. I > consider this to be worthy of a freeze break, since it is a simple fix for am > arguably big regression. Seems reasonable to me, feel free to send a mail to the release team :)
Done: http://mail.gnome.org/archives/release-team/2010-March/msg00215.html. Now waiting for approval.
Comment on attachment 156570 [details] [review] Change the "Open" button to "Download" Since it got approval, pushed to master as 22ee0df38cb945775c53669bdaf5130bb3fbc7ac. Just got the commit message fixed up a bit to be closer to what we use. =)