Please see http://www.gnome.org/bounties/Addressbook.php3#127553 for
more information.

Oops.  The Correct URL for more information is:
http://www.gnome.org/bounties/Miscellaneous.php3#127553

just one question... which is the target browser for this feature?
mozilla 1.5, mozilla 1.6a, epiphany? galeon?

The bounty says Mozilla because it was assumed that Mozilla and Galeon
and Epiphany would inherit the drag actions from Mozilla.  Patches
should be against the development branch of Mozilla.

Well, I asked because I assumed that dragging from the location bar to
the desktop was part of the requirements and, AFAIK, both epiphany and
galeon re-implement the location bar. Anyway, I'll give it a shot.  

Dragging from the location entry should work too in 
galeon/epiphany/mozilla once nautilus is fixed to handle uris drags 
as described.

*** Bug 144875 has been marked as a duplicate of this bug. ***

*** Bug 139848 has been marked as a duplicate of this bug. ***

*** Bug 156405 has been marked as a duplicate of this bug. ***

Anyone else working on this?

I'm working on this one. Identified the problem, but it's not trivial to fix.
I'll try to come up with something tonight or tomorrow.

Created attachment 35693 [details] [review]
First patch for the Nautilus side

This patch takes care of things from the nautilus side. One issue remaining
however:

nautilus_link_local_create just overwrites any file without asking. I was going
to add an overwrite confirmation dialog, until I found out that the standard
overwrite dialog is deeply nested in
nautilus-file-operations.c:handle_transfer_overwrite. I could break it out of
there and put it in a separate function if that is deemed appropiate. Another
approach to the problem would be saving the newly created link file to a tmp
file, and then moving it to the appropiate place using
fm_directory_view_move_copy_items.

Created attachment 35727 [details] [review]
Updated patch

A few small fixes to the previous patch.

Created attachment 35729 [details] [review]
First patch for Mozilla

This patch does the job for the Mozilla side of things. I'd be surprised if the
Mozilla devs will be willing to check this one in like this though, as I don't
think this is the cleanest place for the check. I've been looking for a proper
place to put it, but the Mozilla URL loading code seems to automatically start
parsing XML/HTML, and I don't quite see how I can fit desktop file parsing in
there.

Actually, I'm gonna see if I can do this mozilla stuff by writing a moz plugin.

Created attachment 35745 [details]
Mozilla plugin for loading .desktop files

Here's the plugin. A much cleaner solution than my previous patch to core
mozilla.
I made a little page for it here:
http://www.jbaayen.dds.nl/mozilla-desktop-file-plugin.html

Created attachment 35749 [details] [review]
Updated patch for the Nautilus side

The only change in this patch is that it makes sure that newly created desktop
files have a ".desktop" extension instead of none whatsoever, so that mozilla
can identify them without trouble.

This should be it, apart from the one outstanding issue where creating links
just overwrites existing files without asking.

Created attachment 35909 [details] [review]
New Nautilus patch

New Nautilus patch, based on suggestions from Alexander Larsson.

I commited something based on this. Now this should work much better.

You might want to check the uri's and other strings you get from Mozilla, they
are untrusted information from the network.

Tricks I can think of:
- Include '\n' in the name so you can manipulate the .desktop file to act as if
it had an 'execute' type
- Use a very long file name so the .desktop extension falls off
- Use weird characters in the file name to get it stored in another directory

Also be very, very careful when downloading things to the desktop from the
network. If it happens to start with [Desktop Entry] it might be autodetected as
a .desktop file, then opening it would do anything a potential attacker wants
(also see bug 135431 ).

The mozilla plugin only looks at the URL field, and loads that into the browser.
All the other stuff is ignored. So the plugin should be safe. 

As for the risk of downloading desktop files, the solution you propose in
#135431 seems like a good solution to me (but I'm in no way a security expert)
.. putting specific hacks for this into nautilus doesn't seem right to me, as
for example one could also get very-long-filename .desktop files as attachments
in evolution.

Also, in the nautilus case, the filename gets escaped before it gets saved.

I'm talking about the other way around, when you drag a link from mozilla to the
desktop.

Also just loading an URL into the browser can be dangerous. Try loading a
javascript: url into it, it has the same permissions as the browser itself. It
might be that the getUrl function you use filters it though.

Good point with the javascript URLs. Did a new release of the plugin with a
javascript check:

http://www.jbaayen.dds.nl/mozilla-desktop-file-plugin-0.2.tar.gz

I'm sorry if I seem overly critical, but what I meant to say is that things like
this are really complex to do right, if you want to see examples check the
string of advisories that are released all the time for IE.

Almost all of them revolve around wrong assumptions that are made when data
crosses the boundary from 'in the browser, the browser knows it is unsafe data
from the net' to 'in the filesystem, the data is trusted'. IE tries to make this
clear by using its security zones, mozilla considers just about everything on
the disk to be secure. Both make mistakes in implementing their respective policy.

Also if the data gets back to the browser, it is considered trusted and subject
to less checks. You implemented a check for javascript: per my suggestion, which
is nice, but there are much more dangerous protocols, now, and perhaps new ones
will be added in the future. Mozilla has a function to check for them:
checkLoadURI. You have to give it the protocol that the data came from, so you'd
have to save that.

I'd strongly suggest that you get a hold of some developers that deal with this
part of Mozilla. They understand the architecture and the issues involved much
better than I do.

http://www.mozilla.org/projects/security/components

describes the project for this part of mozilla and also contains pointers to
people that might be able to help you.

But should this not be implemented at the plugin API level? I mean, person A can
make his plugin safe but if closed source company B doesn't, you are still cooked.

The reason I did the javascript check, was actually because the only "extra
vulnerability" I could see was this:
If somebody directly links to "javascript:" this might seem suspicious, linking
to a .desktop file could still use whatever other protocol. So the only thing it
would "add" is masking the protocol, for the careful user who checks the
statusbar where the link is going- if the statusbar isn't being javascripted to
do other stuff, that is.

My plugin does not do anything revolutionary. Having a link directly to a
"javascript:" url (or whatever else), is exactly the same as linking to a
.desktop file with a "javascript:" URL field. Nothing more, nothing less.

Of course, I'm still not a security expert, so maybe I am just missing something
big.. if I am, fill me in.

The danger is in this:

Programs that run javascript remember for every piece of code where it came
from. The things the code can do are limited according to that. Code from one
http://domain can read the cookies from that domain, but not from another one.
Otherwise cookie

A lot of the mozilla interface is written in javascript. Obviously that code is
allowed to do a lot more than the code found on a random webpage.

If you, in some way or another, cause a document to be loaded with a javascript:
URL, the code in the URL will be executed, but now it will be as if it were code
from the browser, with all the extra permission code like that has. Code like
that can for instance read, write and delete your files and run executables.

That is the problem I'm talking about.

But, as far as I know, random sites can link to "javascript:" urls too? How is
that different? Or is the context also remembered for "javascript:" links in pages?

This is really good stuff, very useful. I've found a small bug though : bug
#164080. I'm linking it here for visibility.

From http://www.mozilla.org/projects/security/components/reviewguide.html:

> Remember that anywhere we render HTML, XML, or XUL, or load a URL, JavaScript
> may be run. HTML and XML content can contain <SCRIPT> tags, and URLs in 
> Mozilla can use the javascript: and data: schemes to cause scripts to run. On 
> a web page displayed in the main browser window, this is harmless, since 
> everything in the browser window's content area are treated as untrusted and 
> run in a protective 'sandbox.' Not so for dialogs or other special windows. 
> Does your dialog contain any data derived from the current Web page or mail 
> message? Does it display links taken from the page? If so, you must either 
> filter out Javascript or ensure that scripts will run in a safe environment. 

From this I would guess the plugin still runs within the 'sandbox', over the
course of the day I've tried mailing several mozilla security people (Mitch
Stoltz, Bindu Sharma) to verify, but none of the e-mail addresses I find seem to
be current (they bounce). Grr. I will try again tomorrow.

Then:

> Any time you write a URL to a page or window as the target of a link, the 
> location of an image or embed, etc., and the URL could have come from a web 
> page, look at the URL and don't write it out if its protocol is javascript: or
> data:. Loading those types of URLs can cause a script to run. If you want to 
> allow javascript: and data: URLs, you must ensure that any script that runs 
> does not run with all the privileges of chrome scripts.

Now this would imply that, if the plugin is not sandboxed, checking for data:
and javascript: would be enough. (Apart from the usual buffer overflow, string
formatting stuff, etc)

Just released a new version of the plugin, which also checks for data: urls as
per the mozilla document. Will remove the checks again if I get confirmation
that the plugin is run sandboxed already. Also new are two error dialogs, one is
shown when an insecure url is requested, instead of loading it, and the other is
shown when no url was found in the desktop file.

http://www.jbaayen.dds.nl/mozilla-desktop-file-plugin.html

What needs to be done here before the bug can be considered fixed? I'd be happy
to fix any more outstanding issues, but without any input I don't know what is
wrong.

Comment on attachment 35745 [details]
Mozilla plugin for loading .desktop files

Marking attached plugin version obsolete because newer versions are available
at http://www.jbaayen.dds.nl/mozilla-desktop-file-plugin.html

*** Bug 159272 has been marked as a duplicate of this bug. ***

*** Bug 154287 has been marked as a duplicate of this bug. ***

I'm guessing from the looks of it.  The solution should not be a plugin.  I
think I'll give it a shot.

Created attachment 53020 [details] [review]
An experimental patch

This is a experimental patch. The static array will be converted to a dynamic
one.

Created attachment 53245 [details] [review]
Updated patch (firefox side)

Working on this bug

Ping. What's the status on this? Miguel?

If this is still an issue in a recent GNOME version, comment 39 should really be filed in bugzilla.mozilla.org instead.