Re: A step in the wrong direction, in an ocean of steps in the right direction (try 3)
2009/1/26 Guillaume SH <gsh.debianlists(a)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.
2009/1/25 Ben Klein <shacklein(a)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.
2009/1/26 David Gerard <dgerard(a)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.
participants (2)
-
Ben Klein -
David Gerard