requiring .desktop files to be executable ?

[David Faure]

On Thursday 26 February 2009, Roland Harnau wrote:
> 2009/2/25, David Faure <faure at kde.org>:
> > On Tuesday 24 February 2009, Roland Harnau wrote:
> [...]
> >> Setting the executable bit not by file type but by some internal criteria
> >> leads some oddities especially in the migration phase, e.g. a .desktop
> >> file without exec bit can be
> >>
> >> (1) not of Type=Application
> >> (2) legacy with Type=Application
> >> (3) possible harmful with Type=Application
> >>
> >> and it  is not easily possible to keep them apart, at  least not
> >> without parsing and applying some complex logic in the lines of what
> >> Michael did.
> >
> > Sure. So?
> > "A file named foo.txt could contain text or something else and it's not
> > easily possible to keep them apart without parsing it". Obviously.
> 
> You missed the point. This is not about validating a file format, in
> this case an instance of the same file format can be executable or not
> dependent on a bit pattern which can only be discovered by parsing the
> file. As consequence an upgrade script cannot rely on on the .desktop
> extension for chmod +x in  Desktop or  $HOME, it has to look for
> Type=Application.

It does indeed, nobody said otherwise. There is no upgrade script though,
so there is no such problem. If if someone wanted to write one, using
KDesktopFile::isApplication() (or looking for an Exec field, I think I was wrong,
"Type=Service; Exec=foo" would also be handled the same way),
wouldn't be such a big deal.

> > There is no migration tool, users are supposed to make executable by hand
> > the few desktop files that they use from $HOME or Desktop... Only they can
> > tell if it's (1) (2) or (3), that's the whole point of the security measure.
> 
> Is he really able to make an informed decision? He doesn't know the
> rationale for this security measure, he is only asked if he "trusts"
> the application - for "old" desktop files, newly installed software
> which installs its desktop files in Desktop, and the real security
> threat, the downloaded virus. With so many false positives, isn't it
> likely that he simply clicks through if he encounters the real threat?

You contradict yourself. On one hand you say there is very little use
for desktop files in HOME or Desktop, on the other hand you say
"with so many false positives". This doesn't make sense. And anyway the
idea is that you make your desktop files executable once after upgrading
to 4.3, and then you watch for viruses. Yes a virus downloaded in 2007
would be easily hidden among the sensible desktop files, but how likely
is that to happen? We are not aware of any such virus existing already.

> >> Yes, but this usage is somewhat discouraged by the standard UI and
> >> perhaps only an issue if folderview  is used as desktop containment.
> >
> > No, you can still have standalone icons too, e.g. by drag-n-dropping files
> > onto the desktop.
> 
> I'm quite aware of this possibility, but it plays no critical role in
> the workflow of the default Plasma desktop. Your example (nice icon
> for a shell script) is not  really convincing since the usefulness is
> strictly limited to developers and people who know one (the .desktop
> file is handcrafted). 

No, you can make such desktop files with RMB / Link to new application.

> Users of the "classical" desktop are a different 
> matter, for them executable desktop files are of utmost importance.

... hence the need for this feature.

I don't really have the feeling this discussion is going anywhere.

-- 
David Faure, faure at kde.org, sponsored by Qt Software @ Nokia to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).