Bug 2714 - "Name" key value collides with file names and that will misguide users
Summary: "Name" key value collides with file names and that will misguide users
Alias: None
Product: Specifications
Classification: Unclassified
Component: desktop-entry (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: high normal
Assignee: Owen Taylor
QA Contact:
Depends on:
Reported: 2005-03-12 15:33 UTC by Diego Calleja
Modified: 2009-02-18 03:24 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Note You need to log in before you can comment on or make changes to this bug.
Description Diego Calleja 2005-03-12 15:33:01 UTC
If I've understood it correctly, the "Name" key specifies what programs ej: file
managers should show to user.

This can cause at least two kind of issues, one of them somewhat related with
security as seen in "other OSes"

Problem 1: What user sees is not what is there:
   How to Reproduce:
   Step 1) Create a foo.desktop file with Name="foo"
   Step 2) Create another foo.desktop file in the gnome panel with Name="bar"
   Step 3) Try to drag panel's foo.desktop file to user's desktop.

   Bug: He'll get a warning because he's trying to overwrite "foo.desktop" with
"foo.desktop". User was just seeing "foo" and "bar". He'll never know that "foo"
and "bar" had the same name ie: the concept behind the "Name" key is broken

Problem 2: What user executes is not what he sees
   How to reproduce:
   Step 1) Create a whatever.desktop file
   Step 2) Set Name="Natalie Portman Nude.jpg"
   Step 3) Set Run=evil-executable

   Bug: This is a well-learnt lesson from "another OS", where user thinks he's
opening a image and he's running a evil program, I don't think it needs more

How to Fix: Deprecate the "Name" Key for future versions. Name's primary reason
of existence seems to be "automatic translation of user's visible strings", and
it makes that very easy, but it's too dangerous. Alternative methods for
achieving the same goals should be developed. "Name" solves only one problem but
it causes more, just like the "executable MIME type" in Windows. Developers can
user the file name as temporary place to put the "user's visible string" until a
better solution is adopted.
Comment 1 Owen Taylor 2005-03-12 15:58:35 UTC
I think the bugzilla component should be restricted to typos, unclear statements
in the spec and things like that. This isn't a good place to debate
philosophical disagreements with the specification. (You can try xdg-list,
but my expectation is that there will be no enthusiasm for an incompatible
change in the specification in this area.)
Comment 2 Diego Calleja 2005-03-12 16:11:04 UTC
wow, that was a fast answer!

Thanks, I'll try...altough I don't expect to succed either ;(
Comment 3 Daniel J Blueman 2009-02-18 03:24:17 UTC
One of the key issues with deprecating the 'name' aliasing to the desktop file mechanism, is it is required for separating the user's language preference from the filesystem, eg:

'Trash.desktop' appears in whatever language the user's locale is set to, rather than generating multiple unmanaged trash entries when he/she logs in with another one.

The real underlying issue would thus be: how was the desktop file running 'evil-executable' created? Clearly if there is a vector to do this, far worse can be accomplished, yet it'll still execute as a normal user, not being able to harm the system.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.