Benedikt Meurer píše v Čt 25. 01. 2007 v 10:44 +0100:
Stanislav Brabec wrote:
We just got a new bug report. After playing with it, I believe that it
is a security problem. I am attaching a file, which is not supposed to
be displayed as image, but it is (you need gnome-desktop package to see
On Thu, Jan 25, 2007, Stanislav Brabec wrote:
But because pattern *.jpg has no MIME association, shared-mime-info
offers no warning, that file which conforms defined magic but does not
have name in form *.desktop is suspicious.
glob pattern and magic in shared mime info mean: Recognize MIME
On Wed, Apr 05, 2006 at 03:43:25PM +0200, Benedikt Meurer wrote:
Sam Watkins wrote:
Does anyone other than me think my proposed solution might be the right
thing to do? or can you offer some tweaks and criticisms to make it
better? If so, I'm happy to have a go at implementing it.
I
Sam Watkins wrote:
I'm worried about accidents, not about users who are stupid enough to
actually chmod +x a virus because some bogus web-page tells them to!
Those users deserve what they get.
That's what its all about. If all users were smart enough (not stupid
enough), there would be no need
Sam Watkins wrote:
Does anyone other than me think my proposed solution might be the right
thing to do? or can you offer some tweaks and criticisms to make it
better? If so, I'm happy to have a go at implementing it.
I still don't see the advantage of requiring +x for .desktop files. As
One problem with using the executable bit on .desktop files is that
the executable bit could become set without any special action by the
user.
For example, a tar file can contain a .desktop file with its
executable bit set. tar will honour this bit when it unpacks the
archive. (If it didn't,
On Tue Apr 4 20:03:14 2006, Mark Seaborn wrote:
A user might receive a tar file as an attachment, open it
(presumably
causing it to be unpacked to a temporary directory), double-click
the
.desktop file -- and thereby give an untrusted program access to
their
whole user account without
On Tue, 2006-04-04 at 21:38 +0100, Dave Cridland wrote:
On Tue Apr 4 20:03:14 2006, Mark Seaborn wrote:
A user might receive a tar file as an attachment, open it
(presumably
causing it to be unpacked to a temporary directory), double-click
the
.desktop file -- and thereby give an
On Tue, 2006-04-04 at 20:03 +0100, Mark Seaborn wrote:
One problem with using the executable bit on .desktop files is that
the executable bit could become set without any special action by the
user.
In particular, if saved to a FAT partition (USB drive) or similar.
A different approach
On Wed, Apr 05, 2006 at 12:20:35AM +0100, Scott James Remnant wrote:
On Tue, 2006-04-04 at 20:03 +0100, Mark Seaborn wrote:
One problem with using the executable bit on .desktop files is that
the executable bit could become set without any special action by the
user.
In particular, if
First off, you apparently missed the whole thread about this, which was
started on March 23. You might want to look at the archives and read
through it. The replies extend into April.
http://lists.freedesktop.org/archives/xdg/2006-March/007904.html
On Sun, 2006-04-02 at 22:29 -0700, Sam Watkins
On Mon, 2006-04-03 at 09:48 -0400, Rodney Dawes wrote:
On Sun, 2006-04-02 at 22:29 -0700, Sam Watkins wrote:
1. do you agree that this is a serious security problem?
I don't think it is a serious security problem. While it does expose
the ability to run shell commands from the .desktop
On Mon, Apr 03, 2006 at 03:24:51PM +0100, Scott James Remnant wrote:
Uh, PIF file attacks were very common for a long time in Windows.
Are. Viruses still use them to great effect.
signature.asc
Description: Digital signature
___
xdg mailing list
On Mon, 2006-04-03 at 15:24 +0100, Scott James Remnant wrote:
On Mon, 2006-04-03 at 09:48 -0400, Rodney Dawes wrote:
On Sun, 2006-04-02 at 22:29 -0700, Sam Watkins wrote:
1. do you agree that this is a serious security problem?
I don't think it is a serious security problem. While it
On Mon Apr 3 15:59:16 2006, Rodney Dawes wrote:
On Mon, 2006-04-03 at 15:24 +0100, Scott James Remnant wrote:
On Mon, 2006-04-03 at 09:48 -0400, Rodney Dawes wrote:
On Sun, 2006-04-02 at 22:29 -0700, Sam Watkins wrote:
1. do you agree that this is a serious security problem?
I don't
On Mon Apr 3 14:48:25 2006, Rodney Dawes wrote:
2. do you think we should fix it?
I don't think we should rely on the +x bit. The point of the +x
bit, is
that you can run the thing, from anywhere. Just setting it +x won't
let
you run it from the shell. You'd have to change the spec to
Rodney Dawes wrote:
2. do you think we should fix it?
I don't think we should rely on the +x bit. The point of the +x bit, is
that you can run the thing, from anywhere. Just setting it +x won't let
you run it from the shell. You'd have to change the spec to specify an
implementation to be an
Thiago Macieira wrote:
I'd propose to optionally include a digital signature for the Exec field
(i.e. add an ExecSignature field to the spec) and let the file manager
ask the user whether he/she trusts the signee or popup a warning if no
signature is present. Distributions should then ship with a
Rodney Dawes wrote:
I'd propose to optionally include a digital signature for the Exec field
(i.e. add an ExecSignature field to the spec) and let the file manager
ask the user whether he/she trusts the signee or popup a warning if no
signature is present. Distributions should then ship with a
Rodney Dawes wrote:
On Mon, 2006-04-03 at 19:03 +0200, Thiago Macieira wrote:
Benedikt Meurer wrote:
I'd propose to optionally include a digital signature for the Exec
field (i.e. add an ExecSignature field to the spec) and let the file
manager ask the user whether he/she trusts the signee
On Mon, 2006-04-03 at 19:26 +0200, Benedikt Meurer wrote:
Rodney Dawes wrote:
Shoulud it be GPG? What about S/MIME?
It doesn't need to be GPG.
This was more a question for Thiago than you. Your original mail didn't
specify the signature format, just that there should be one. :)
Do we
Rodney Dawes wrote:
Do we really need a signature and
yet another dialog to pop up and annoy the user? Shouldn't we only pop
up things like this when we /know/ there is an issue?
The user shouldn't see the dialog usually. Only if the system is unable
to verify the signature, which should only
Travis Watkins wrote:
Shouldn't be a problem. The editor will automatically sign the file when
saving, and there could also be a simple CLI frontend (probably as part
of desktop-file-utils, for people who want to edit .desktop files with a
generic text editor), which can be used to sign .desktop
On Mon, 2006-04-03 at 12:57 -0500, Travis Watkins wrote:
On 4/3/06, Benedikt Meurer [EMAIL PROTECTED] wrote:
Shouldn't be a problem. The editor will automatically sign the file when
saving, and there could also be a simple CLI frontend (probably as part
of desktop-file-utils, for people who
FreeDesktop.org could create a spec that maintains a table of sha1sums
for valid .desktop files which have been installed by the operating
system or system administrators. When the .desktop file is launched by
the user, if the sha1sum doesn't match any blessed .desktop entries
the user could be
On Sun, 02 Apr 2006 22:29:04 -0700, Sam Watkins wrote:
I feel this x-bit is the single best protection available to the
non-expert desktop user under Linux/UNIX, which prevents malware
becoming common in *nix
This is not a universally accepted opinion.
The discussion also was started NOT
Mike Hearn wrote:
The discussion also was started NOT because .desktop files ignore the +x
bit which is quite a trivial issue imho, but because they can make
themselves appear to be absolutely anything you want, including files
that are safe to open like image/document files, when in fact they
hi,
I'll go over this again and describe what I consider to be the solution
in detail.
problem:
.desktop files contain executable code (shell script) but are not
presently required to be marked executable (to differentiate them from
documents).
small rant :p
This is a design fault, a
peace,
I noticed quite a while ago that .desktop files as specified by
freedesktop.org open a window into GNU/Linux for a whole range of
viruses and trojans. I think that this has been discussed
before. I see that the issue has not been resolved so I'd like to
suggest a way to resolve it.
29 matches
Mail list logo
