El lun, 02-02-2004 a las 13:12, Heinrich Rebehn escribió: > > 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. That'll give the naysayers something to process for a while, and the developers lots of corner-cases in case they choose to stay with "file extension rules" design decision. > > > > > 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. Which is why the application that creates the file should tag it with the proper MIME type. That should be the application's responsibility, not the user's. And to avoid confusion, the user should not be able to just change the extension therefore changing the meaning of the file to the entire system. > Maybe you should trust the user. Maybe you shouldn't. In a corporate environment, you definitely shouldn't. Pay careful attention to the repercussions of this kind of decision. > 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? None of the two are valid if the apps tag the files with the correct file types. Extensions stop being a problem then. And sniffing as well. But both extensions and sniffing could be secondarily relied upon on a medium-term transition phase. > > 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. This "speed" argument has been hashed and rehashed before. I'd rather drive a secure and robust car than a fast, crappy one. Plus, we've been through this before, and it's been agreed that extensions will be faster than reading EAs. There's no discussion. There is no discussion on the functionality front either. > > 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. People stopped discussing sniffing vs. extensions a long time ago. That's why the e-mail message was titled "Nautilus, metadata and extendet attributes". I agree with this, sure, but... > I understand that the user can decide, if mime-types are based on > extensions or sniffing. Correct? Yes. The whole point of the thread is to raise the awareness of the need of a real metadata system, instead of relying in legacy hacks. We've also been through the "add a configurable option" argument. Truth is, most of the time developers actually add the option, creating a nightmare for regular users who need to navigate through thousands of options. An option should NEVER be added if there is a possibility of doing something right instead of choosing between two wrong approaches. -- Manuel Amador (Rudd-O) GPG key ID: 0xC1033CAD at keyserver.net
Attachment:
signature.asc
Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente