2009/2/25 Patryk Zawadzki <pat...@pld-linux.org>: > On Wed, Feb 25, 2009 at 2:13 AM, Michael Pyne <mp...@purinchu.net> wrote: >> On Tuesday 24 February 2009, Patryk Zawadzki wrote: >>> Also using extended filesystem attributes (or some other metadata >>> storage) gives you the additional protection from "downloaded a >>> tarball / uncompressed to desktop / the file was compressed as >>> executable / now I have two computer icons" kind of scenarios. >> So what happens when the archive extractor actually supports xattr and now >> there is executable-with-fancy bit trojan laying in the directory? > > It's safe to strip all the xattrs (by cooperating with the desktop's > archiving tool of choice maintainers) without sacrificing any > functionality. Scripts will continue to work, binaries will behave as > they should. The only difference is clicking some of them will yield a > "possibly unsafe content" warning. It's not safe to do the same thing > with the +x flag as you'll break most of the source code tarballs. > Thus +x/-x is not likely to work in a more generic case (not .desktop > file specific). > > Also relying on just the +x flag will not work in collaborative > environments. If I'm the file owner I get to control the +x flag. In > such cases we still need an external metadata storage to take note of > the file path, its hash (to detect changes) and whether it was trusted > or not and if we implement such storage, why not allow just any other > attributes (thus having a working xattrs fallback even if no > filesystem support is present).
Are you suggesting some sort of collaborative situation where you want some people to trust the .desktop file and others not? I can't even imagine such a situation. John _______________________________________________ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
