Re: .desktop file security
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). -- Patryk Zawadzki ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: .desktop file security
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
Re: Identifying applications from windows to .desktop files
Le mercredi 25 février 2009 à 02:29 +, John Tapsell a écrit : You need to be realistic and realise that you aren't going to get every app to change. That's precisely what my proposal absolutely avoids. Read again: all applications but a handful of them (depending on distributions mainly) already follow what I consider as an already existing standard. Some applications rely on this implicit assumption, and GIO almost presents .desktop file names as identifiers. I'm not asking something unrealistic, but on the contrary I'd like the spec to define the common usage a a standard we can fully rely on. Isn't it the way fd.o works? It does seem that the best way is to simply parse all the .desktop files, pull out the Exec= name, and try to match that against the binary used to run each window (Most Windows have a WM_PID which you can use to get the binary name). Then you'll have to manually maintain an exceptions file for funny apps like openoffice. If nothing else is proposed, I guess we'll need to fall back on this solution. But you did not answer my concerns about possible failures of such a process. The day your distribution will change either the command to start OpenOffice.org (let's say it moves from oowriter to openoffice.org-writer), or renames the .desktop file (since it's normal to do so for now in the spec), you'll lose all data about OO.o, meaning launchers are likely to disappear from most used apps. Not a big deal, but obviously not optimal either. The only workaround will be to keep a list of .desktop file names for each distribution, and to keep it up-to-date it... I think I'm going to stop spamming this list if nobody agrees that adding two sentences to the spec to clear things up and avoid tricks like this one is worth the pain. But, as you can see, I'm far from convinced ;-) ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Identifying applications from windows to .desktop files
Milan Bouchet-Valat a écrit : Le mardi 24 février 2009 à 23:38 +0100, Francois Gouget a écrit : On Sun, 22 Feb 2009, Milan Bouchet-Valat wrote: [...] We are now tracking applications usage to build stats and present the user with the most used apps. For this, we identify windows with their WM classes, and want to map this to a specific application, i.e. a .desktop file. Why start from the window name/class? Why not enumerate running processes to identify which binary is running? From that binary it seems like you could get back to the package name if needed. Well, first, we don't want to track background processes, but only applications we've seen the user interacting with. The model is clearly centered around objects that the user works with, which are windows. Hmmm, I believe I understand. The term application is misleading because what you really want to track is usage of the Start Menu entries. But then that raises another question. Why not simply track the clicks on these entries in the Start Menu? This would tell you precisely how many times a given entry has been used. Sure, we could see what command was used to start the app owning a given window, and then get the desktop file associated with it. But this method suffers from the same problems, as I said before in this thread: See, I was more equating applications with packages. So I would rather have mapped the binary to the corresponding system package. But since what you want to track is Start Menu entries, obviously that would be no good. [...] This approach assumes that there's no alternative way other than the one referenced in the .desktop file to start the window. Which is obviously a bad assumption. For instance I use XEmacs every day and I can tell you I never once started it from the Start Menu. You will also have false positives. For instance I use the Firefox I downloaded from Mozilla.org. So if you see a window called 'Firefox', will you assume that this matches the .desktop file called 'firefox.desktop'? If you do you'll make a mistake because the desktop file refers to /usr/bin/firefox while the one I run is '/opt/firefox/firefox'. You will also make a mistake if any '.desktop' file contains a URI that causes it to be opened in some application. This could be some documentation in a PDF format, or maybe an html file in a web browser. You will think that the user uses 'firefox.desktop' every day when in fact he's using 'OpenOffice Tutorial.desktop' every day. [...] This is tricky and IMHO makes us go really far from the direct relationship between applications, windows they own, and .desktop files they're described by. I don't see any direct relation between applications, .desktop files and even less windows. And certainly not a one to one mapping. I guess my perspective is also colored by my work on Wine. Microsoft Word does have a desktop file, but I doubt its window properties will let you match the two. But then maybe you don't care about applications that are not shipped with the OS. But then, if your goal is to optimise the presentation of the Start Menu to show the most used entries, then you cannot afford to ignore an application on this ground. -- Francois Gouget fgou...@codeweavers.com ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Identifying applications from windows to .desktop files
Le mercredi 25 février 2009 à 11:23 +0100, Francois Gouget a écrit : Milan Bouchet-Valat a écrit : Well, first, we don't want to track background processes, but only applications we've seen the user interacting with. The model is clearly centered around objects that the user works with, which are windows. Hmmm, I believe I understand. The term application is misleading because what you really want to track is usage of the Start Menu entries. Sorry for not being obvious. I've used much this terminology, and I forgot it's not really natural/explicit. What I call applications is the application as seen by the user on the desktop, not the installing process. But that's how gnome-app-install works too. But then that raises another question. Why not simply track the clicks on these entries in the Start Menu? This would tell you precisely how many times a given entry has been used. Sure, that's a traditional way of measuring it. But for several reasons it seems more accurate to make stats based on actual time usage., one of which being that, as you say below, XEmacs should be taken into account too. Sure, we could see what command was used to start the app owning a given window, and then get the desktop file associated with it. But this method suffers from the same problems, as I said before in this thread: See, I was more equating applications with packages. So I would rather have mapped the binary to the corresponding system package. But since what you want to track is Start Menu entries, obviously that would be no good. Yes. This approach assumes that there's no alternative way other than the one referenced in the .desktop file to start the window. Which is obviously a bad assumption. For instance I use XEmacs every day and I can tell you I never once started it from the Start Menu. You will also have false positives. For instance I use the Firefox I downloaded from Mozilla.org. So if you see a window called 'Firefox', will you assume that this matches the .desktop file called 'firefox.desktop'? If you do you'll make a mistake because the desktop file refers to /usr/bin/firefox while the one I run is '/opt/firefox/firefox'. You're right, this scenario is a real pain to handle, but I can see no satisfying solution. Assuming that you start /opt/firefox/firefox using the absolute path, and not using $PATH, and that a .desktop file is installed in a standard dir (and using absolute path too), the commandline approach would work. But if you start it manually using ./firefox because you're hacking on it, that model is broken. Relying on WM classes would be problematic too, since it would require /opt/firefox/firefox to use a different class than distro Firefox, which is not really possible. You will also make a mistake if any '.desktop' file contains a URI that causes it to be opened in some application. This could be some documentation in a PDF format, or maybe an html file in a web browser. You will think that the user uses 'firefox.desktop' every day when in fact he's using 'OpenOffice Tutorial.desktop' every day. These are complex issues that come from the fact our desktops are not rally document-centric, but not app-centric either. We work around that be not showing applications known as being only viewers (Evince, Eye of GNOME - could be oKular too); distributions do this in their .desktop files already. But for Web browsers and office suites, it's not really clear whether users use them only from documents, or for themselves, i.e. starting them before to open documents. When browsing the Web, you tend to consider the browser as a whole, with different tabs realted to very different topics: the browser is a first-class object in the desktop (at least for now). This is similar with word processing: you can open it to look for recent text documents; but that could be changed to a document-centric model. Other apps are clearly not document-centric at all: mail apps, instant messengers... But this is a whole debate we can't solve here... :-) This is tricky and IMHO makes us go really far from the direct relationship between applications, windows they own, and .desktop files they're described by. I don't see any direct relation between applications, .desktop files and even less windows. And certainly not a one to one mapping. I guess my perspective is also colored by my work on Wine. Microsoft Word does have a desktop file, but I doubt its window properties will let you match the two. But then maybe you don't care about applications that are not shipped with the OS. But then, if your goal is to optimise the presentation of the Start Menu to show the most used entries, then you cannot afford to ignore an application on this ground. I had thought about this case, and we definitely care, but I don't really know of you manage these .desktop files in Wine. Do you install them in a spearate directory? Would the commandline
Re: shared-mime-info: image/x-fits - image/fits
On Tue, Feb 17, 2009 at 07:25:17PM -0500, Matthias Clasen wrote: On Thu, 2009-02-12 at 20:40 +0100, Alexey Shuvaev wrote: Hello all! The long history short: FITS image mime type is officially registered since 2005. So it is named image/fits and application/fits now. Regardless of this correction in shared-mime-info, can I recommend to simply accept both mime types in the gdk-pixbuf loader ? Mmm... Well it is possible but... From RFC 4047 (from the section about registration of image/fits): Additional information: A FITS file described with the media type image/fits SHOULD have a PHDU with positive integer values for the NAXIS and NAXISn keywords, and hence SHOULD contain at least one pixel. Files with 4 or more non-degenerate axes (NAXISn1) SHOULD be described as application/fits, not as image/fits. (In rare cases it may be appropriate to describe a NULL image -- a dataless container for FITS keywords, with NAXIS=0 or NAXISn=0 -- or an image with 4+ non- degenerate axes as image/fits but this usage is discouraged because such files may confuse simple image viewer applications.) And from the the io-fits.c sorce: * NOTE: The gdk-pixbuf library presently supports only 2D images, but * the FITS format allows for images of up to 999 dimensions. This * module will return valid a GdkPixbuf* for: * * 2D FITS images, in which case the entire image is returned * 3D images, in which case ONLY the 2D slice along Z=1 is returned * N 3D images ONLY if each additional dimension is of size 1, * in which case, again, only a 2D slice is returned I would say that current behaviour of the loader exactly matches the description of image/fits mime type. BTW: I'm not the author if the loader, the [current] author (Michael S. Noble) is CC-ed. Alexey. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: What constitutes user configuration files in the XDG basedir spec?
2009/2/9 Dieter Plaetinck die...@plaetinck.be On Mon, 9 Feb 2009 02:10:33 +0200 Guillem Jover guil...@hadrons.org wrote: On Thu, 2009-01-15 at 22:10:25 +0100, Dieter Plaetinck wrote: I guess the biggest issue would be trying to come up with a proper definition for state. regards, guillem Actually I think your state vs configs splitup is a very similar approach to my suggested settings as configured by user/on behalf of user versus settings on behalf of the application itself splitup at http://lists.freedesktop.org/archives/xdg/2009-January/010157.html In practice, all settings that an app would like to store without explicitly requested by the user can probably all be categorised under state, so our ideas are very similar. Your wording is probably better then mine, so a huge +1 from me for adding a 4th concept 'state' to the current list of cache, configs and data. Am I correct in interpreting the above discussion as in the consensus being that for now, what you refer to as state should be saved in the .config directory, and that a future xdg version may separate it into a third directory, perhaps to be named .state? If yes, could perhaps this be clarified in the standard? I just got a patch for a command line shell I am maintaining from a user who had written a patch to move the commandline history from .config to .cache. Axel ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: shared-mime-info: image/x-fits - image/fits
On Tue, Feb 17, 2009 at 10:51:33AM +0100, Vincent Untz wrote: Alexey asked to be cc'ed, so doing this ;-) Thanks! Vincent Le mardi 17 février 2009, à 10:38 +0100, David Faure a écrit : On Thursday 12 February 2009, Alexey Shuvaev wrote: Hello all! The long history short: FITS image mime type is officially registered since 2005. So it is named image/fits and application/fits now. The history of acception: http://www.ucolick.org/~sla/fits/mime/ RFC 4047: http://www.rfc-editor.org/rfc/rfc4047.txt Indeed, http://www.iana.org/assignments/media-types/image/ knows about image/fits. Yes, and http://www.iana.org/assignments/media-types/application/ knows about application/fits As I have mentioned it is not so important but if we are at FITS mime types it may be reasonable to add this type (application/fits) too. See attached patch. It is an old patch against 1.401 of freedesktop.org.xml.in so hunks about image/fits should be almost completely removed. Here I tried to add application/fits and make image/fits subclass of it. The problem is how to differentiate between them (they have identical signatures). In a nutshell, each FITS file starts with the following 3 lines: SIMPLE = T BITPIX = 8 NAXIS = 3 Actually these are not 'classical lines' (no newline at the end) but 80-bytes keyword-value entries padded with spaces :) BITPIX may have other values (16, 32, 64, -32, -64 IIRC). The difference between application/fits and image/fits (in its simplest case) is that image is allowed to have NAXIS = [1,2,3] while application has no restrictions. So if some guru here can code this into freedesktop.org.xml.in, that would be nice. As of image/fits, I think it should be fixed. Done. Super! 2009-02-17 David Faure fa...@kde.org * freedesktop.org.xml.in: Rename image/x-fits to image/fits (IANA-registered name), and add image/x-fits as alias * tests/list: Update testcase accordingly However for you to benefit from this fix, a new shared-mime-info release has to be made, which is not in my hands. Ok, it is not so critical. It is imortant to know that it will be fixed in the next release of shared-mime-info. Small note to Michael (developer of FITS gdk-pixbuf-loader). The file in the test directory of shared-mime-info (test.fit) was rejected by the loader: gdk-pixbuf-csource test.fit failed to load test.fit: Failed to load image 'test.fit': Unable to read non-trivial 3-dimensional FITS image As suggested in RFC 4047 it might be reasonable to handle such files too. Don't know if it possible to create animated pixbuf but showing the first plane in such a file is OK too. Thanks to all! Alexey. diff -rup shared-mime-info.orig/freedesktop.org.xml.in shared-mime-info/freedesktop.org.xml.in --- shared-mime-info.orig/freedesktop.org.xml.in2009-02-16 22:47:09.0 +0100 +++ shared-mime-info/freedesktop.org.xml.in 2009-02-16 23:49:51.0 +0100 @@ -3611,15 +3611,27 @@ command to generate the output files. glob pattern=*.epsi/ glob pattern=*.epsf/ /mime-type - mime-type type=image/x-fits + mime-type type=application/fits _commentFITS document/_comment acronymFITS/acronym expanded-acronymFlexible Image Transport System/expanded-acronym magic priority=50 - match type=string value=SIMPLE = offset=0/ + match type=string value=SIMPLE =T offset=0/ /magic glob pattern=*.fits/ /mime-type + mime-type type=image/fits +_commentFITS document/_comment +acronymFITS/acronym +expanded-acronymFlexible Image Transport System/expanded-acronym +generic-icon name=image-x-generic/ +sub-class-of type=application/fits/ +magic priority=55 + match type=string value=SIMPLE =T offset=0/ +/magic +glob pattern=*.fits/ +alias type=image/x-fits/ + /mime-type mime-type type=image/x-fpx _commentFPX image/_comment acronymFPX/acronym diff -rup shared-mime-info.orig/tests/list shared-mime-info/tests/list --- shared-mime-info.orig/tests/list2009-02-16 22:51:56.0 +0100 +++ shared-mime-info/tests/list 2009-02-16 23:14:13.0 +0100 @@ -14,7 +14,7 @@ test.cel image/x-cel xxx test.dcm application/dicom test.eps image/x-eps GammaChart.exr image/x-exr -test.fit image/x-fits x +test.fit image/fits x test.fli video/x-flic ox test.gif image/gif test.ico image/x-ico ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Identifying applications from windows to .desktop files
On Sun, 22 Feb 2009, Milan Bouchet-Valat wrote: [...] We are now tracking applications usage to build stats and present the user with the most used apps. For this, we identify windows with their WM classes, and want to map this to a specific application, i.e. a .desktop file. Why start from the window name/class? Why not enumerate running processes to identify which binary is running? From that binary it seems like you could get back to the package name if needed. -- Francois Gouget fgou...@free.fr http://fgouget.free.fr/ Research is the transformation of money to knowledge. Innovation is the transformation of knowledge to money. -- Dr. Hans Meixner ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
