This utterly breaks the workflow of users when you have a default desktop containment and then some application shortcuts on there.
Details
Details
No longer get that prompt for when I have a regular folderview containment but still have it for other places where I wouldn't expect executable things.
We still have the prompt for non-executable "untrusted" desktop files (which btw comes even if you accepted the first prompt...)
Diff Detail
Diff Detail
- Repository
- R119 Plasma Desktop
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
Comment Actions
- Check for the location of the URL we're trying to run instead of the main folder view url (indirectly through parseDesktopFile), this way when opening a subfolder in desktop:/ through cascading it will again ask for confirmation
Comment Actions
This reintroduces the security bug that this whole thing was about in the first place.
Download some file from the internet, save on desktop, click on it - boom.
The Unix principle is that you must make the file executable first before it will actually execute anything.
Comment Actions
The code that creates the application shortcuts that you mention, should make them executable.
Comment Actions
The "untrusted non-executable desktop file" and "script execution prompt" are completely orthogonal (for some reason).
With this patch I still get the security warning:
- non-executable .desktop file on some random location: → "would you like to run or open this file?" → Run → "If you don't trust this application, click Cancel"
- executable .desktop file on some random location: → "would you like to run or open this file?"
- non-executable .desktop file on desktop: → "If you don't trust this application, click Cancel"
- executable .desktop file on desktop → runs right away
What I changed is that I no longer get the "would you like to run or open this file?" prompt for executable .desktop files on desktop:/ which breaks the workflow of many.