oiaohm wrote: > andreaplanet what you describe as an attack don't work on all distributions out there. But this attack will work on most Linux systems since by default I can run native programs. Like with Windows, viruses and trojans have a easy job on most Windows systems, but not on all. You can't say Wine has no vulnerabilities because if you configure it as a Sandbox then you can feel secure, when nearly nobody does that. (I tried to find out how to activate the Sandbox environment for Wine but didnt found anything). oiaohm wrote: > Wine is currently left soft to be as friendly as we can. That can be changed over night if the need ever turns up. The hole only exists because the OS secuirty is turned down if its ever turned up those holes disappear. Good to know. I could say the same for Windows. Just install the appropriate software for defending it. So right now I can easily target a Wine-Linux system. Fortunately it's still easier to try to attack a native Windows machine, also because there exists more Windows systems, so you have a higher chance of success. oiaohm wrote: > We already have a way to detect. Ie exe.so binaries. They only work on wine and its relations. Why duplicate. So everyone who want to detect Wine must create his own exe.so? Ok, but if it is hardened through a sandbox then still can I run it? With a sandbox can I run a native linux binary distributed together with my application? oiaohm wrote: > Still no one has answered why you cannot just put a check box in the installer asking user are they on wine? It is the simplest solution. It why I am classing you arguments for so pointless. First you say it is wrong to detect Wine, now you say let the user detect Wine (choose on which OS you are running). Every developer have to write that question, save that info somewhere in the registry or a INI file. What a duplication. Honestly a simple API call for everyone would be much easier without bothering the end-user. As a end-user I would ask myself "isn't the program intelligent enough to detect on what system it is running?" > Many small issues in Wine will never be fixed because > - it's not worth (or) > - there are too few developers to fix everything (or) > - the wine community does not want to fix something by design (or) > - some issues are just impossible to fix due to technical reasons oiaohm wrote: > This is one of the reason why we don't want to. If you can detect wine what is you motivation to fix it. That simple. If you can detect wine most windows developers will do the same as you do on windows. Ok its wine run different block of code lets not bother fixing it no matter how simple. This is a good point. But you can't force developers to do that, also because there exists easy workarounds. Running a native binary, reading the environment. It's not that hard, maybe unreliable. Why not cooperate? Make an API call like "bool IsWineBugFixed(int bugnr);". That function will read from a .conf/inf file that is updated at each wine release. Until the bug is fixed the Windows code will execute in custom way else it will run in a native way. And you didn't answered about "bugs/behaviours" that the Wine community just don't want to change. Let's call them hacks or patchs to make a particular application run (better). People at Codeweavers said that CrossOver is full of hacks that the wine community refuse to use. What if I want to use such a hack? In such case I need a customized attitude of my program, so I need to detect if Wine is running. For example personally I want that my application use the native Open File Dialog and not the ugly default windows open file dialog. By reading the currently running OS I can run a specified native executable/library that offer this feature and interact with the EXE application through a pipe for example. The Wine community will refuse to use such a hack because it changes the natural behaviour of the Windows environment. And I want this change only for my own application, so that other applications will run without problems. Here a reason why a simple API to let me know the name of currently OS is welcome, and it should work both at least on Windows, Linux and Mac OS X. Of course on the long run the goal is to rewrite the application natively for Linux and Mac OS X. But right now it's an acceptable workaround.
