Re: Nautilus, metadata and extendet attributes

[Heinrich Rebehn <rebehn ant uni-bremen de>]

Manuel Amador (Rudd-O) wrote:
> El lun, 02-02-2004 a las 11:30, Olaf Frączyk escribió:
>
>
> > OK. I personally agree here. I want "pure" extensions solution (may be
> > as option for user to choose).
> >
> > > If users have associated Windows executable files with WINE, for
> > > example, wine will run files whether they have extensions or not, as
> > > long as they are PE (portable executable) files.  Users can then receive
> > > something masquerading as a picture, but upon run, discover that their
> > > files are gone.  That the risk is 1-in-100000 does not matter.
> >
> > If you associate only "exe" files, you have no risk.
>
>
> Wrong.  You do *not* associate EXE files.  In Nautilus, you associate
> MIME types, which are application/x-ms-dos-executable for Nautilus 2.4. 
> I just removed the EXE extension from a file, and it opened with wine
> fine (winamp.exe, if you care to know).

So you could rename winamp to "winamp.xpm" and nautilus would open it 
with wine? Wow, that is even more dangerous then the usual windows 
exploits, because it does not rely on certain settings (hide extensions).

Great new exploit possibility! User thinks it's an xpm image, nautilus 
executes it.

> The problem is that you're looking at this with an "extension"
> mindset.    This is not windows.  You don't associate apps with
> extensions.  You associate file types with apps.  The extension
> ultimately doesn't matter, and it won't matter because Nautilus does
> sniffing.  The correct thing isn't removing sniffing.  The correct thing
> is stop relying on extensions.

Sniffing will always stay guesswork, because there is no standard which 
says "Bytes 0 to 3 of the file denote the data type" or such. Consider 
raw cdr files (CD audio tracks) which have no header at all. They can be 
sniffed as anything.
Maybe you should trust the user. He has full control by setting the 
extension to the appropriate string. If he makes a mistake or receives 
incorrectly named files, what can happen?

Example:

User receives a shell script that is named "picture.jpg"
*Extensions*: Double clicking on that file will start an image viewer 
which will either bark about a corrupt picture or crash.
*Sniffing*: Shellscript will be executed while user expected a picture. Bad!

So what is more dangerous, extensions or sniffing?

Also, using extensions gives the best possible performance. Once you 
have read a directory, you know the mime-types of all the files in it.
*And*: It yields a system, that does what the user wants, and not, what 
the system *thinks*, is best for him or her.

Sniffing should be available on request, if the user is unsure about the 
contents of the file, but we should not force him to rely on it.

So my proposal would be to make sniffing a configurable option.
> > If I have 500 .bmp and 500 .jpg files (eg. bmp - original, jpg -
> > transformed) then extension is the easiest way for me to open the file I
> > wanted. Or copy. Have you ever tried to sort files (without extensions)
> > by type using midnight commander?
>
>
> You get to keep the extensions for as long as you want (if you live up
> to a hundred years, you can still have them).  You can slap any
> extensions on any file you wish, and have MC work just as it works
> today.  
>
> Nevertheless, we already discussed the fact that each file will have its
> own MIME type, and you can expect regular applications to use that
> information to sort files and schtuff.
>
> The whole point of this thing is to allow we who don't want to rely on
> extensions to live well.  
>
> It's not meant to affect users who want to
> keep the (wrong design decision) extensions.

I understand that the user can decide, if mime-types are based on 
extensions or sniffing. Correct?

> I get the sense that you either didn't read the entire text of the
> proposal, or didn't digest the implications of it.
>
>
> > :) And why I use mc instead of
> > nautilus? Because it is fast, really fast. I don't want to waste 40
> > seconds for waiting on directory listing if I can get it in 1 second.
>
>
> Then why are you discussing Nautilus issues regarding MIME types?  (you
> just stated you use MC *instead* of Nautilus).  If it's raw speed,
> Nautilus will never be as fast as MC, simply because Nautilus has much
> more functionality, and period.  Of course Nautilus could actually
> afford you lots of speed, simply because it lets you be more efficient
> than MC.
>
>
> > > --
> > > 	Manuel Amador (Rudd-O)
> > > 	GPG key ID: 0xC1033CAD at keyserver.net

Regards,

	Heinrich Rebehn