A step in the wrong direction, in an ocean of steps in the right direction (try 3)
Hi wine team, First let me thank you for providing wine software witch I see as a strong asset in the expansion of free software and as a useful tool for people (like me) already using free software wherever possible. At this point, Wine is at a very good level both in API coverage, quality (less and less hack, more and more nice and clean solutions) and efficiency. Reaching that level required a tremendous work in all kinds of domains (implementation, coordination, patch value judgment, test suite...). In this regard I want to thank you again and congratulate you all guys, what you have done so far is quite an achievement. This week however I was quite puzzled by one commit : kernel32: Make GetOverlappedResult crash on NULL args as native does.(1) As I'm following wine only for a short time (count in months, not in years) I guess reproducing windows unfixed defects is a choice (although I am not sure this decision comes from consensus or from a boss statement) made by wine team. Thinking about it I see only one argument justifying it's the good direction : for the sake or portability from wine to windows platforms. For example, a firm using wine on a free-OS platform, for software development with a Windows target platform. Relying on this assertion (which someone may demonstrate me to be false, secondary or incomplete), I'm afraid that wine take a step in the wrong direction from what seems to me the third major reason to switch from non-free OS platform (typically Windows) from free-OS platform. Those 3 main reasons are for me : 1 - Freedom (possibility to browse sources, self-compile from sources and even modifying them) 2 - Free from charge 3 - Communicating openly about known defects in software, fixing defects without respects for commercial stakes (ex: hide bug until the xxth release, or not fixing a known bug until it is publicly discovered) To summarize, I'm stating that removing the clean and safe way to handle NULL parameters in this function to fall back to bad and dirty crash, exposing security issue for user (a software can be created specifically by a ill-intentioned one to exploit this defect), all for the sake of being as bad as Windows is, is a step in the wrong direction. I feel sad enough about it, and I think it can prevent advertised people to use it but above all to recommends Windows user to go for free-OS platform with usage of wine for their needs not covered by free-software (like proprietary format). Nevertheless, just as I said, I'm still very enthusiast about wine and still think it's great and very useful. I will continue to use it, promote its usage when suitable, and also warn about its known defects people around me. Guillaume (1) for reference : 32cc4011ee04046d41a41549d5a6a6233647f756 from 22/01/2009 PS : I am fully aware that free software have defects too, some of them being security issue. I am also aware, that in a software as huge as wine, reaching even a medium security level is a real strong challenge, increased by the defects in Windows API design. I am also fully aware that security is a process, not a product.
Re: A step in the wrong direction, in an ocean of steps in the right direction (try 3)
Guillaume SH gsh.debianli...@gmail.com wrote: As I'm following wine only for a short time (count in months, not in years) I guess reproducing windows unfixed defects is a choice (although I am not sure this decision comes from consensus or from a boss statement) made by wine team. That comes from a simple understanding that win32 API behaviour is defined by Microsoft, not by anybody else. Having a NULL check, or even an exception handler in an API is not fix for a defect as you might imply, that's actually good that applications crash when they pass invalid data. Wine needs to handle invalid case only when Windows does have them, and only if there are applications depending on that behaviour. If you whish to fix win32 API, make Microsoft hire you. -- Dmitry.
Re: A step in the wrong direction, in an ocean of steps in the right direction (try 3)
On Sunday 25 January 2009 12:39:22 Dmitry Timoshkov wrote: Guillaume SH gsh.debianli...@gmail.com wrote: As I'm following wine only for a short time (count in months, not in years) I guess reproducing windows unfixed defects is a choice (although I am not sure this decision comes from consensus or from a boss statement) made by wine team. That comes from a simple understanding that win32 API behaviour is defined by Microsoft, not by anybody else. Having a NULL check, or even an exception handler in an API is not fix for a defect as you might imply, that's actually good that applications crash when they pass invalid data. Wine needs to handle invalid case only when Windows does have them, and only if there are applications depending on that behaviour. If you whish to fix win32 API, make Microsoft hire you. What about an assertion right before the following line: *lpTransferred = lpOverlapped-InternalHigh; This way it will still crash in the same circumstances, but will make it easier to debug programs.
Re: A step in the wrong direction, in an ocean of steps in the right direction (try 3)
2009/1/25 Guillaume SH gsh.debianli...@gmail.com: This week however I was quite puzzled by one commit : kernel32: Make GetOverlappedResult crash on NULL args as native does.(1) Thinking about it I see only one argument justifying it's the good direction : for the sake or portability from wine to windows platforms. For example, a firm using wine on a free-OS platform, for software development with a Windows target platform. I see it as a matter of correctness. Unexpected success can be worse than unexpected failure. Imagine a case where, due to invalid data, an application would randomly destroy or corrupt data all over the user's computer. The only thing saving it is this kernel32 crash. If Wine doesn't have it, bye-bye data integrity. Of course, this is just a hypothetical. But it's important to note that Wine is not *meant* to be *better* than Windows, it's mean to *accurately* implement the win32 API. Thus, it's important to be able to reproduce positive and negative cases as the API is defined. Relying on this assertion (which someone may demonstrate me to be false, secondary or incomplete), I'm afraid that wine take a step in the wrong direction from what seems to me the third major reason to switch from non-free OS platform (typically Windows) from free-OS platform. Those 3 main reasons are for me : 1 - Freedom (possibility to browse sources, self-compile from sources and even modifying them) This one commit does not making the source any less open. 2 - Free from charge This one commit does not put a price tag on Wine. 3 - Communicating openly about known defects in software, fixing defects without respects for commercial stakes (ex: hide bug until the xxth release, or not fixing a known bug until it is publicly discovered) If anything, it's communicating a defect more openly. We're specifically saying that, under the right circumstances, the API call will crash (the expected behaviour if running on a native system). Also note that commercial stakes do not factor in to Wine (with the possible exception of Crossover Office), and that Wine is certainly not hiding bugs from anyone. That said, bugs are unknown and unacknowledged until someone discovers them, and in the case of open-source software, that someone is invariably the public (i.e. an average user). I feel sad enough about it, and I think it can prevent advertised people to use it but above all to recommends Windows user to go for free-OS platform with usage of wine for their needs not covered by free-software (like proprietary format). You know what would be better? Convince people to not use win32 at all, and to use open APIs on open operating systems. We don't live in such a rationally open world. Wine has to deal with the proprietary and (in places) poorly documented win32 API, and in some cases simply reproduce behaviour not necessarily defined in the win32 spec but that is reliably reproducible on Windows (native) systems. PS : I am fully aware that free software have defects too, some of them being security issue. I am also aware, that in a software as huge as wine, reaching even a medium security level is a real strong challenge, increased by the defects in Windows API design. I am also fully aware that security is a process, not a product. Wine doesn't have security. OK, that's a bit simplified, but Wine does not protect you from malicious software. Most malware on Windows systems are perfectly valid win32 apps, and if Wine was perfect then the malware would work in Wine too. With every improvement to Wine (in terms of API completeness, accuracy etc.), more malware can potentially run. That's just the way the cookie crumbles.
A step in the wrong direction, in an ocean of steps in the right direction (try 3)
Hi Dimitry, Thank you very much for bringing this explanation to my knowledge. As you name came over and over through wine-devel list, I am aware that you are an experimented and influential member within wine community (which make a huge difference with me, as this is the first time I try to bring a contribution to wine(1) ), so I will consider this explanation as the way most involved wine people are considering things up. The most interesting part in your answer is indeed this word of Behaviour you used. Indeed, in my understanding (but maybe I am hoping is more correct here) wine's goal is to provide the same functionalities as Windows API, not to implement those functionalities C statement for C statement with respect to Window's ones. Two reason comes to my mind : 1 - Just copycatting Windows implementation would brought wine very close to plagiarism, thus legally threaten is mere existence 2 - Obviously, Windows implementation is not always the most efficient nor the most secure, due to commercial stakes (release schedule, financial arbitrations...) Regarding the part of your mail where you wrote : that's actually good that applications crash when they pass invalid data, I must admit I don't understand your point at all. It seems to me a dogma, not the result of some thought or stand back. Don't misunderstand me here, I'm not insulting you neither I'm not saying that I am better than you nor I'm not trying to start a flaming thread. I respect the assertion you stated, but honestly and deeply fail to understand why is it correct. Guillaume (1) Talking openly and honestly about a subject that may be considered a problem is a way of contributing, less concrete than patches, but real too.
Re: A step in the wrong direction, in an ocean of steps in the right direction (try 3)
2009/1/26 Guillaume SH gsh.debianli...@gmail.com: I will be my last mail though because I understood that there is a consensus that wine shouldn't be a safe and good tool enabling transition from Windows to free-OS, but rather a tool with a not-so-clear goal (again I'm not willing to start flaming, so please don't). Wine's goal is perfectly clear: to provide, as best as possible, a complete and accurate implementation of win32 (and win64 long-term) and related APIs. If putting invalid data into a specific function causes a known crash on the only other implementation of win32 (Microsoft Windows), especially considering that win32 is standardised by the same company that produces Windows, it can be assumed that the crash is the correct behaviour and Wine should emulate it. 1 - Freedom (possibility to browse sources, self-compile from sources and even modifying them) This one commit does not making the source any less open. I totally agree : this the first reason i evoked and it is 100% reached by wine 2 - Free from charge This one commit does not put a price tag on Wine. I totally agree : this is the second reason I evoked and it is 100% reached by wine 3 - Communicating openly about known defects in software, fixing defects without respects for commercial stakes (ex: hide bug until the xxth release, or not fixing a known bug until it is publicly discovered) I agree that wine doesn't try to hide defect, but Microsoft is, and copycatting Microsoft behavior is like being accomplice of its silence and lack of actions Microsoft's defect, if not already documented, has been revealed by this patch. It's not something they're likely to fix. If they fix it, then a matching fix has to go in Wine at some point (which could be interesting due to different behaviour on different Windows versions). Until they fix the bug and update win32 specifications to match, crashes directly caused by the commit in question are expected and can be assumed to be correct. Regarding the security part, I am full aware of the facts you stated, and this is a point that's dooming wine to have less success than It could have. No, it's dooming Wine to have more success than it should have. Big difference. In implementing win32 API, Wine inherently opens up *nix to a whole new world of malware. Sure, it still needs to be explicitly run by the user, sure there is wineserver -k and rm -rf ~/.wine, but that won't stop spyware, trojans, worms etc. completely. And it shouldn't, because if Wine attempts to stop malware, then legitimate applications will surely suffer too. Not to mention legitimate software that *acts* like malware, e.g. punkbuster :) You are an intelligent man Ben, I happy to exchange with such a man. Lies, all lies! But thank you nonetheless.
Re: A step in the wrong direction, in an ocean of steps in the right direction (try 3)
On Sun, Jan 25, 2009 at 1:53 PM, Guillaume SH gsh.debianli...@gmail.com wrote: The most interesting part in your answer is indeed this word of Behaviour you used. Indeed, in my understanding (but maybe I am hoping is more correct here) wine's goal is to provide the same functionalities as Windows API, not to implement those functionalities C statement for C statement with respect to Window's ones. Two reason comes to my mind : 1 - Just copycatting Windows implementation would brought wine very close to plagiarism, thus legally threaten is mere existence Legal problems aside, copycatting Windows is exactly what has to happen for Wine to function like it should. It can't be a 'better' version of Windows, because many programs depend on the quirks and faults of the Windows API/ABI. And I don't think there are any legal problems. Wine developers don't look at reverse-engineered Windows code, so Wine's code will inevitably differ a great deal. Implementing quirks the same way will make the code more similar than before, but there are still things like coding style and implementation details that differ a great deal. Probably not even 1% of the C statements in Wine is an exact match to a statement in Windows. 2 - Obviously, Windows implementation is not always the most efficient nor the most secure, due to commercial stakes (release schedule, financial arbitrations...) Well, the implementation can differ from Windows, as long as it has the same effect on the API/ABI level. Some applications actually do run faster because of this. And some run much slower because of this. Regarding the part of your mail where you wrote : that's actually good that applications crash when they pass invalid data, I must admit I don't understand your point at all. It seems to me a dogma, not the result of some thought or stand back. A while back there was some case where a buggy Windows program would run in Wine, while it didn't run in any version of Windows. After Wine became better, the buggy program stopped working. Of course it also meant that a lot of other programs started working. At some point you have to stop making bad programs work, and implement the API as close to Windows itself as possible. The buggy program can still be made to work with a custom patch. Remco
Re: A step in the wrong direction, in an ocean of steps in the right direction (try 3)
It's all been said, by myself and others. I just want something clarified. 2009/1/25 Guillaume SH gsh.debianli...@gmail.com: Regarding the part of your mail where you wrote : that's actually good that applications crash when they pass invalid data, I must admit I don't understand your point at all. It seems to me a dogma, not the result of some thought or stand back. If an application ends up with invalid data (possibly due to a bug in the app, possibly due to corrupt data files, possibly due to user input without proper checking in the app), a call to the function in question (or any other function, for that matter) could easily end up with invalid data. In the case of invalid data crashing the application, the application stops functioning, and no (further) damage can be caused. In the case where Wine does something that win32/Windows doesn't, which is to allow the program to continue with its invalid data, there is potential for your system to become compromised by the application continuing. What you describe as a potential exploit by crashing an app with invalid data in this case could easily be used as an exploit the other way, and something that specifically targets Wine, since the behaviour is different in Windows, where the app crashes on invalid data. It's possible. It's potential. It's theoretical. It's something that could be implemented as a proof-of-concept. It should be fixed, and doing what the other guy does, when there are only two in the field, makes sense when you're already trying to do what the other guy does (which is run Windows applications). It doesn't even need to be exactly the same code, as long as it has the same effect. There's already been a suggestion for an alternative way to do the same thing.
Re: A step in the wrong direction, in an ocean of steps in the right direction (try 3)
Remco wrote: A while back there was some case where a buggy Windows program would run in Wine, while it didn't run in any version of Windows. After Wine became better, the buggy program stopped working. Of course it also meant that a lot of other programs started working. At some point you have to stop making bad programs work, and implement the API as close to Windows itself as possible. The buggy program can still be made to work with a custom patch. Windows has an application compatibility layer that loads with specific (pre-configured and user configured) applications to provide backward compatible behavior for buggy applications by intercepting exported system DLL functions. Wine should have this as well that would enable more applications on Wine, possibly even more than on Windows. Kornél
Re: A step in the wrong direction, in an ocean of steps in the right direction (try 3)
2009/1/25 Ben Klein shackl...@gmail.com: Wine's goal is perfectly clear: to provide, as best as possible, a complete and accurate implementation of win32 (and win64 long-term) and related APIs. If putting invalid data into a specific function causes a known crash on the only other implementation of win32 (Microsoft Windows), especially considering that win32 is standardised by the same company that produces Windows, it can be assumed that the crash is the correct behaviour and Wine should emulate it. Is it possible to meaningfully enhance Wine by crashing the app, but in such a way as to note on the terminal that the crash is for compatibility with Win32, what crashed where, etc? No, it's dooming Wine to have more success than it should have. Big difference. In implementing win32 API, Wine inherently opens up *nix to a whole new world of malware. Sure, it still needs to be explicitly run by the user, sure there is wineserver -k and rm -rf ~/.wine, but that won't stop spyware, trojans, worms etc. completely. And it shouldn't, because if Wine attempts to stop malware, then legitimate applications will surely suffer too. Not to mention legitimate software that *acts* like malware, e.g. punkbuster :) Wine running malware correctly is a valuable feature, e.g. ZeroWine: http://www.offensivecomputing.net/?q=node/1028 It runs malware in Wine on Debian on QEMU for the purpose of producing a full trace of all Win32 calls. - d.
Re: A step in the wrong direction, in an ocean of steps in the right direction (try 3)
2009/1/25 Remco remc...@gmail.com: Well, the implementation can differ from Windows, as long as it has the same effect on the API/ABI level. Some applications actually do run faster because of this. And some run much slower because of this. What apps run faster in Wine than in Windows? (What Win32 functions run faster and better in Wine than in Windows?) Is this documented e.g. on the wiki? - d.
Re: A step in the wrong direction, in an ocean of steps in the right direction (try 3)
2009/1/26 David Gerard dger...@gmail.com: Is it possible to meaningfully enhance Wine by crashing the app, but in such a way as to note on the terminal that the crash is for compatibility with Win32, what crashed where, etc? That might set an unwelcome precedence. Realistically, anyone investigating such crashes could be pointed to (or find on their own) the git commit that describes the reason.
Re: A step in the wrong direction, in an ocean of steps in the right direction (try 3)
Ambroz Bizjak am...@ambro.homelinux.net wrote: What about an assertion right before the following line: *lpTransferred = lpOverlapped-InternalHigh; That will make the behaviour incompatible with Windows by generating wrong exception code. This way it will still crash in the same circumstances, but will make it easier to debug programs. In which way will it make easier in debugging? -- Dmitry.
