Amazed and appalled
As I was one of the original authors of the notifications spec, somebody pointed me to the recent discussions on xdg-list about it. When Christian and myself wrote this spec, it was to solve a problem the Linux desktop had: the only poptart implementation was KDE specific and so most of the apps we used or worked on (like Gaim and Wine) did not use them. The point of freedesktop was to solve that sort of problem, so we stepped up and spent our evenings and weekends doing exactly that. It was not a perfect solution. It did not include every possible feature, partly for reasons of time and partly for reasons of design. But it met the needs of many apps, they started to use the spec, and we thought the problem was solved. This was in line with the philosophy of the xdg founder, Havoc Pennington, who believed in deployed code above endless email threads. 5 years on, I just wanted to say that I am in awe at how much time has been wasted discussing the *name* of the *interface* of the *notifications system*. How are unpaid volunteers expected to get shit DONE like this? Do you seriously expect ANYONE to volunteer their time to work on solving problems when the result of the work is that many years later you are said to have screwed people over and are a hijacker? I don't work on Linux anymore and care little for its future, but I have to say, don't you guys have MORE IMPORTANT problems to be solving than POPTARTS?!? ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: [Portland] Re: [Fwd: Re: Mime-typ Scribus?]
The recent concensus is to use major-minor.png as icon for mimeypes. See the bottom of http://www.freedesktop.org/wiki/Standards_2fshared_2dmime_2dinfo_2dspec Awesome, I stand corrected. Thanks Waldo. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Autostart on logout
On Sat, 22 Apr 2006 10:15:40 +0200, Vincent Untz wrote: Some people are asking for ways to start some commands on logout (like, eg, removing all files in a directory). Hm, what happens if such a program tries to interact with the user? Microsoft has a way that apps can watch for and cancel log outs, it was in hindsight decided to be a mistake (but can't be removed for the usual reasons). ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: (no subject)
On Thu, 13 Apr 2006 16:14:19 +0530, nupul kukreja wrote: Well Luca thanks a millionyup it did help me solve my doubt... I'm afraid that won't work. Multiple applications can handle the same file types, and then the user can choose between them in their file manager or select a default. Information on which the default is ISN'T provided by any standard or specified mechanism, deliberately! The problem is, if you can read this data you can really write to it too, and on Windows there have always been problems with programs fighting over file associations. So Linux uses a different scheme, in which the defaults are a desktop private thing and apps can't control that. All they can do is say I support files of type foo. So, to actually open a file from your application requires you to use gnome/kde specific APIs right now :( Sad I know but you can see how we got here. The Portland project is working on an abstraction layer that will provide a unified API to all this. Go Portland! For now try gnome-open or kfmclient. eg. Say my software uses a custom format .asdf files. Do I need to update the mimeinfo.cache as well as add my .desktop file to this folder? No, drop it in the right place and run update-desktop-database. Of course if you have defined your own .asdf files, you need a custom asdf mime type and a way to detect these files ... preferably by their contents but extensions are OK too. So you'll need to write an XML file for your file type, drop it in the right place then run update-mime-database too :) If you search for .desktop files on your system you'll find a lot more than those in the above directory. Why is this? They're used for all kinds of things, not just registering programs with the system. A historical oddity, ignore it. thanks -mike ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: all in desktop et al.
On Thu, 13 Apr 2006 15:38:50 +1000, Benjamin Rich wrote: www.linux-platform.org It details the Common Linux Desktop Platform, which is a set of cross-distro tools I'm going to write to allow a set of 'foundations' for anyone wanting to write a desktop/GUI application for 'Linux', distro-nonspecific. I realise this isn't a new idea and I'm sure there are other projects based on this concept - nonetheless. So, from my perspective, as somebody who indirectly distributes a lot of software across different distributions, what we need is simple: a] A big list of libraries and minimum required versions, that are commonly used by desktop Linux programs. b] A mailing list/forum where people can collaborate on building distro-specific repositories so end users can add this repo, and just do apt-get install platform or whatever to ensure that every library the platform contains is installed. Of course it would be OK to install a newer version that is compatible with the one in the platform. c] A schedule/timeline for updating it, and a set of criteria for what can be included. It's really not that complex at all. Some things we definitely *don't* need are: a] Precise ABI specifications of libraries. Depending on the implementation is good enough - if something wishes to be a substitute then compatibility with the implementation is required. b] Some new packaging scheme. That is a separate project and should be left to compete on its own merits. Note that there are already several appfolder implementations for Linux, see ROX Desktop, ZeroInstall and Klik c] A new desktop - what has this got to do with a platform? d] Politics over what's included. Duplication is fine, KDE is fine, GNOME is fine, dependencies on stuff not in the platform is fine, non-C languages are fine, even C++ is fine because we can hack around its unstable ABI using external tools. But what's harder to hack around is when the library is flat out missing. The net result is that no matter what package system is used, whether it be RPM or Klik or autopackage or ZeroInstall, the users experience is more reliable and ISVs are more confident in the platform as a whole. Unfortunately I didn't really see much of that on the website ... I think you're on the right lines though, but really, the appfolder/desktop thing is not really relevant, what's needed is just a big list :) thanks -mike ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: .desktop files, serious security hole, virus-friendliness
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 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 are programs. This kind of two-facedness has been exploited in the past, and _that_ is the real issue here. Other problems to do with controlling unknown software are still a research problem, and whilst they definitely need research, UNIX permissions won't be solving them anytime soon. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Security issue with .desktop files revisited
But this is only true if the .desktop file is a valid .desktop file, no? I guess so. I don't know what KDE/GNOME do when given an invalid desktop file. And if the icon is actually in the theme on the user's system? Yes - things like JPEG file, word processor document etc are pretty much guaranteed to be there. They can't embed their own icons. This is what will save us ... We can also limit what one can put in the Icon= line, to icons in the Applications context. That was the original proposal. There have been lots of alternatives proposed, but can anybody think of a good reason why we shouldn't do this? Aaron gave the best IMHO - that there are many legit icons a malicious file could use that aren't mime icons. Fair point. But, is this reasoning strong enough to say we should not do it? I am not sure. thanks -mike ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Security issue with .desktop files revisited
On Tue, 28 Mar 2006 23:59:11 -0500, Rodney Dawes wrote: The current solution in nautilus really sucks, and won't let me even open valid files, where the extension disagrees with the data mime type discovery. That's a different (but related) issue, where a file extension does not match what the file contents says it is. This issue is that .desktop files are treated specially by the desktops, and can choose their own name and icon. It doesn't matter what is done with MIME typing or anything else - it will not affect desktop files without a change in the spec or implementation. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Security issue with .desktop files revisited
Francois Gouget wrote: So in the above scenario, when the user downloads the rogue '.desktop' file to his desktop, that file will be tagged as 'untrusted'. Then, clicking on it would warn the user before running it. .desktop files shipped with the distribution would not have the 'untrusted' bit and thus would not issue this warning. Also, this warning could be selectively issued only for .desktop and 'executable' files, and not if the file is merely a simple jpeg. But that could be configurable and a 'paranoid' setting would warn for all untrusted files (in case they are designed to trigger buffer overflows). Such a solution requires quite a bit of work and time to be implemented but then I think any solution to this problem do. Yes, this is a variant on the +x bit marks a file as trusted. Here's an idea - the problem with requiring an EA or +x to be set is it breaks backwards compatibility (it'd break Crossover/Wine for one ...). But what if the logic is inverted - so the absence of +x means a file is trusted, and web browsers or email programs set +x when they save a file to disk? The +x bit on a .desktop file in the users home dir is then treated as a don't trust marker. This doesn't break backwards compatibility and only requires that web browsers and email programs be patched. I'd still be happier with some solution that prevented a .desktop file masquerading as a JPEG file, but anything is better than nothing ... ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Security issue with .desktop files revisited
Francois Gouget wrote: Well, in my proposal, only untrusted files need the untrusted EA bit set. So backward compatibility is not broken. Right, I'm just exploring ways to achieve that without requiring EAs. Surely, requiring that web browsers and email tools make all the files they save executable cannot be good for security... Only .desktop files, and right now +x on such a file is meaningless anyway. Which is kind of the opposite of its normal meaning which can be taken to be 'I trust this file enough that I am willing to execute it'. Yes, it's unintuitive to reverse the meaning like that, but it does have the advantage of not requiring EAs (which don't travel through standard tarballs, network filing systems) and not breaking backwards compatibility. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Security issue with .desktop files revisited
Francois Gouget wrote: At least Windows does not require Firefox to know about .lnk, .cmd and .pif files. No, and a marking scheme doesn't _require_ anything to be updated. It's a nice-to-have-but-not-essential feature. First, who said that worm writers are not allowed to call their ELF creations 'myworm.desktop'? They can call an ELF file whatever they like, but such a file will be represented by the desktop environment as a program and not anything else, so it's not an issue. To reiterate, the security problem here is that something which is a program can make itself look like a document by using a .desktop file. Some modification to the spec or additional metadata can be used to give hints to the user that all is not what it seems, and the +x bit is being suggested only because EA support is not fully baked yet. The fact that +x bits have some other meaning for shell scripts and ELF files isn't related . the .desktop file that is also a shell script will be treated as a .desktop file by the desktop environment as that's what it will match on using the MIME sniffers (and if it doesn't then the file will be represented as a program so there is no problem). thanks -mike ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Security issue with .desktop files revisited
On Sat, 25 Mar 2006 10:56:00 +, Thomas Leonard wrote: ROX-Filer shows .desktop files (and anything else it will execute if clicked) with a different text colour, but leaves the icon alone. That's the sort of thing we want, I think, but does it really work? Have you tested it on people to see if they are suspicious of a different coloured thing that looks like a jpeg image file? ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Security issue with .desktop files revisited
On Sat, 25 Mar 2006 09:13:44 +1100, Lennon Cook wrote: If a potentially dangerous .desktop file gets through the QA process, and is installed on an end-user system, it isn't a leap of faith to think that it could have +x by default. What QA process? This is supposed to stop viruses that work by tricking the user into thinking they're a different type of file than they really are, as we've seen happen on Windows and MacOS X. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Menu spec update (summary; closure?)
On Thu, 23 Mar 2006 08:33:47 -0600, Jeremy White wrote: I think idea #3 is a neat idea (I'm a big fan of having all files isolated into their own /opt/blech directory), but I just don't see a practical road from here to there. And even if #3 is championed, a short term resolution is needed while we're waiting for it to be adopted. I'm a fan too, but right now so much stuff assumes /usr is where applications are installed simply altering the menu spec won't turn the tide. It could be fixed for menus, but as soon as we get into non-XDG things like DBUS, Bonobo, KParts, man, info, autoconf etc they all default to looking for things under /usr. Doesn't matter for us (Codeweavers) but matters for a lot of other stuff, and 20% solutions are icky. There have been proposals that'd let us have software in dedicated directories around the FS (from network mounts, usb keys etc) in ways that don't require patching lots of stuff, but as of today they aren't implemented and there's no general solution that works everywhere :( So I'd not really support #3 because it creates yet another XDG specific thing, even though the real problem is larger and there are more general one-hit solutions. Given that /usr vs /opt is currently a lost cause in the general case, I guess Waldos solution is the simplest resolution for now. (this is the point where I get reminded I have outstanding bugs to fix ;) thanks -mike ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: shared-mime-info 0.17
Current issues keeping this as 'draft' are: * The Desktop Base Directory Specification, which this relies on, is still a draft. Can we add: * Integration with icon themes has not been finalised (and is not currently part of the specification). to that list? :) It's kind of silly that the spec comes so far then falls over at the last hurdle: what name an icon file should have. I don't remember the rules for this but it's quite frustrating and undocumented. thanks -mike ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Allowing apps to install packages
On Tue, 28 Feb 2006 22:36:38 +, John Tapsell wrote: For example, in a KDE app we may want to install a certain set of files. What would be useful would be in a distro-independent way to say install japanese_language_pack for example. Then it would be up to the distro's to provide some mapping from install japanese_language_pack to running their gui package manager, asking for root password, and installing it. Can't be done reliably: * You don't know the name of the package. Every distro has different naming rules. Attempts at standardising this went nowhere of course. * The package may not exist, or may not be up to date, or may have been patched so it works differently to how you expect Right now for languages there isn't much alternative to shipping all of them and taking the size hit. In autopackage you could install only the pack that makes sense for the users current locale of course. thanks -mike ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Autostart and MAC security
On Tue, 21 Feb 2006 23:35:26 +, Mike Hearn wrote: Obviously if an app is installed as root via RPM or whatever then it's game over. Oh, I should note that there's no fundamental reason RPMs must have root privs anyway: autopackages can already install without root access and it's easy to imagine an RPM only having full root access if it's been signed by a trusted key (from the OS provider). So we can start evolving Linux towards a truly secure desktop, as opposed to one that is secure through obscurity ... thanks -mike ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: update-desktop-database location
On Thu, 09 Feb 2006 12:03:09 +0100, Christian Westgaard wrote: So I'm back to scripting individual tests per distro and gnome/kde version. Note that autopackage already does this, so before duplicating our work you may wish to investigate if using it would make sense for you. thanks -mike ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Request for clarification on menu/file spec
On Tue, 07 Feb 2006 15:56:54 -0800, Waldo Bastian wrote: If there is concensus that that is the right long term direction and that the benefits outweigh the disadvantages then I guess we should go that way. I would like to hear some more cheers of support for that direction first though. -1 from me (autopackage maintainer). I long ago came to the conclusion that the prefixes system UNIX uses sucks in fundamental ways. The /usr vs /usr/local decision which autopackage gets so much flak for is really the least of our worries: * Global prefixes like /usr are not namespace managed. LANANA tried to fix this and everybody ignored them. How can I install a program called WonderWidget when some random dead-since-2002 project on SourceForge may have already claimed that name? * Every prefix except /usr is pretty much broken on 99% of distros. It was nice to see YOPER and SUSE work on fixing this, but bugs filed against Gentoo, Red Hat and so on were all either ignored or closed as WONTFIX. Adding new prefixes is so painful, and so prone to making mistakes (for instance Stanislavs list seems to miss BONOBO_ACTIVATION_PATH and DBUS include paths), that it's really not a scalable solution. If I had total freedom to implement a solution, I think I would do something like this: * Every user-interesting program is installed to /software/$X as its prefix, where $X is a name generated by the system not selected by the software authors. It could be totally random, a GUID or something, but for optimal command line usability it'd be better to have it related to the software name/version. /software is not meant to be end-user visible like /Applications is on MacOS, it's a system internal thing. * What is currently in /usr is put into /system * /usr is set up to be the union mount of /system and /software. This can be done with unionfs today for instance. Exactly what is mounted into /usr is managed by a simple daemon that whacks a file notification watch on /software, and as directories are added/deleted from here they appear and disappear from /usr This has a few advantages over the current scheme, which I'll explain in a sec, but obviously it requires quite significant changes to the way the distro is set up. But as we're tossing around alternatives and the current system is badly flawed why not investigate extreme solutions? OK so the advantages are like this. Firstly, whilst you can still get namespace conflicts in /usr, they are not fatal. Today if I wish to install two programs with the same name either due to accidental collision or because I wish to test a CVS build but keep my stable build around too then I must choose one to be the primary install, and then the other one is installed to some other prefix and ignored by the desktop. This is because /usr/share/inkscape can only be owned by one program at once. But in the union mount scheme, if I had two versions of Inkscape installed at once, they would (because they have been made binary relocatable using our spiffy APIs, natch) resolve $PREFIX/share/inkscape to /software/inkscape-0.43cvs/share/inksape and /software/inkscape-0.42/share/inkscape respectively. So with simple modification they would be able to run side-by-side. If we want to avoid that modification entirely, then it is simple to modify the OS so /proc/self/prefix is a directory that resolves to wherever the program is installed to, then you can ./configure --prefix=/proc/self/prefix. Pick your poison. More and more apps are getting relocatable these days as they're ported to Windows anyhow. OK, so we still have the problem of /usr/bin which is presumably in the PATH conflicting. Union mounts don't die when faced with this, the earlier mount overrides the later mount. So by fiddling the settings in my simple daemon, I can control which package owns the inkscape command/manpage. And of course my little daemon is free to add symlinks with more precise names similar to how it chooses a name for the /software/$X directories. OK but we STILL have the problem of conflicting namespaces for things like menu entries. Nobody has to do this, but in practice, everybody calls their menu entry wonder-widget.desktop even though the desktop doesn't care what it's called. So we can solve this EITHER by having desktop-file-install randomize the names ensuring no conflicts. OR we can modify the desktops so they can scan every directory under /software and don't care about duplicated names. Alright, where are we up to so far? We have: * Either introduced /proc/self/prefix OR made each app binary relocatable. We can now easily have multiple programs with the same name installed to different directories at once * Union them mounted over the distros provided /system directory to form /usr, which is there for backwards compatibility and so the various $FOO_PATHs don't get too long. * Written a little daemon with GUI that
Re: ogg [was Re: [EMAIL PROTECTED]: docbook mime type detection]]
That is *spectacularly* broken. I assume the ogg people have been larted for this? It's also very common: QuickTime MOV and Windows AVI files work exactly the same way. Neither has to contain video although they usually do. Even if the Ogg guys were publically larted and vowed to reform we'd still have to deal with that. Short of some plugin API for MIME type detection (which I've wanted since forever) a hack could be to have a simple Ogg Handler program that figured out what the 'closest' MIME type is and then forwards the open file request to that program. If the Ogg file contains video, it'd go to whatever app handles video/x-theora, if not then it goes to whatever app handles application/x-ogg. Ditto for any other container types that cannot be distinguished by file extension (are there any others?) thanks -mike ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Qt/GTK Skinning
The differing looks is a feature, not a bug, IMO. Perhaps so, but surely the user should be the one to decide on the aesthetics of their desktop and not us? Firefox and OpenOffice follow the GTK+ theme too and it never causes me problems. thanks -mike ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Verifying Categories lines
Hi, One common class of bugs I've seen lately while trying out various autopackages people have built is that despite shipping a .desktop file, nothing appears in the menus. Often the problem is that the Categories line is wrong. There are a few different mistakes people make consistently: * Typos like Games instead of Game. That one is very common. * Use of categories that are not allocated in the default GNOME menus and so land under Other which isn't really obvious. * Use of categories that should put the menu into Other but lack the Application category so they don't appear at all. And then there seem to be a few other issues: * They're installed to /usr/local/share/applications and not detected. Actually these days autopackages always install to /usr for this sort of reason but it's an issue for source installs still. * KDE seems to require a kbuildsycoca invocation after installing .desktop files. Is this still an issue for KDE 3.4? I think partly this is just a matter of culture ... menus have been broken for so long on Linux that developers and users no longer expect menu items to appear, so this stuff never gets checked during testing or development. Especially this is true because during testing usually you install from source and this nearly never works because of /usr/local not being merged. So when it doesn't work for binary packages nobody is surprised. There are maybe a few ways to fix this. 1) Write a program that does basic sanity checking of the Categories line 2) Standardise on some menu layouts between KDE/GNOME so that people don't write a Categories line which matches for KDE but not GNOME or vice-versa 3) Possibly expand the default menu layouts for the desktops so categories are more fine grained ... right now GNOME puts the GScore musical notation app (once fixed) under Other which isn't very helpful. A category dedicated to music would be nice. GNU Solfege, an ear training program, gets put under Edutainment which is reasonably appropriate, but that category has no icon. Does anybody else have any ideas on how we can get third party apps to use the menu correctly? thanks -mike ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
