A step in the wrong direction, in an ocean of steps in the right direction (try 3)

[Ben Klein]

2009/1/26 Guillaume SH <gsh.debianlists at 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.