On Wed, Feb 14, 2007, Josselin Mouette wrote: > As for fixing #408556, I suggest the following course of action: > * for computer:// and applications://, allow all .desktop files; > * for network://, dns-sd:// and smb://, use clever filters; > * for file://, only allow files belonging to the user or to root; > * for all other cases, treat them as text.
(I've sent a detailed analysis of the smb:// URLs and network:// URL in GNOME #405291.) > A more elegant way to fix network:// and the like is probably to give > autogenerated files another MIME type, like > application/x-desktop-virtual. I'm not sure we foresee all the consequences of such a change, and I'm not sure why we would need to treat as "virtual" the .desktop files below computer:// and not below sshfs://. > This would allow to easily distinguish > them from any user-created files, as there is no way the fd.o database > would return this MIME type when queried. The shared mime info DB can be queried, even for the virtual files. I'm not sure it is, but the virtual .desktop file contents would match the magic. > All these changes require a shlibs bump for gnome-vfs and the last one > requires a conflict against nautilus versions not understanding this > MIME type. I'm not sure why we would need a shlib bump if we only change gnome-vfs to return a different MIME type for smb-root. The API doesn't change, and while the ABI changes at some level, we need to adapt the applications, not simply rebuild them; it's a kind of transition where we will have to raise build-deps and deps on libgnome-vfs in some applications (well, in nautilus), so I think we should simply add a versionned dependency in nautilus, for example a conflict. IOW, versions of nautilus which refuse handling "smb-root" as a desktop file should conflict with versions of gnome-vfs providing "smb-root". -- Loïc Minier <[EMAIL PROTECTED]>
