Bug#408556: .volume might be needed too as well as full pathnames

[Josselin Mouette]

Le mercredi 14 février 2007 à 11:49 +0100, Loïc Minier a écrit :
> > 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,

We have to list all stuff using these virtual desktop files. A first
search only lead me to the filechooser in libgnomeui, but there may be
others.

The more I think about it, the more I'm convinced the best solution is
to have a way to distinguish these virtual files from real ones. Relying
later on the URI is too much error-prone and we will sooner or later
find another vulnerability. However there may be other ways to
distinguish them than changing the MIME type. I'll check whether we can
rely on some of the fields of the GnomeVFSFileInfo API, but if it is not
possible changing the MIME type looks like the best thing to do.

>  and I'm
>  not sure why we would need to treat as "virtual" the .desktop files
>  below computer:// and not below sshfs://.

Because sshfs doesn't generate such desktop files. Only the computer,
dns-sd, smb and network methods do.

> >                                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.

This would be harmless. What cannot happen is the fd.o returning this
whitelisted MIME type for a regular file.

>  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".

Well, we need nautilus to depend on the new libgnomevfs2-0 package, one
way or another. The simplest way to do it now and forget it without bad
consequences is to bump the shlibs.

-- 
 .''`.
: :' :      We are debian.org. Lower your prices, surrender your code.
`. `'       We will add your hardware and software distinctiveness to
  `-        our own. Resistance is futile.