February 2009 - Wine-Devel - list.winehq.org

Re: Malware on Wine review

by Ben Klein

2009/2/24 Zachary Goldberg <zgold(a)bluesata.com>: > 2009/2/23 Dan Kegel <dank(a)kegel.com>: >> Ben Klein <shacklein(a)gmail.com> wrote: >>>> http://www.avertlabs.com/research/blog/index.php/2009/02/23/running-windows… >>>> >>>> "Do not set the file association for Windows executables with Wine. >>>> This would enable running Windows executables in Wine by simply double >>>> clicking them." >>>> >>>> I saw a patch floating by to turn this on by default recently. Maybe >>>> we should make it off by default, but easy to turn on...? >>> >>> This would annoy all the people that the association targets. We can >>> either make it easy to run all Windows apps (malware and legit) via >>> file manager, or none at all. >> >> Yes, exactly. The default should be off, and it should be easy to >> turn on. >> - Dan > > I disagree on this point. Is malware via Wine on Linux really a > problem commonly affecting users? What happened to replicated > Window's behavior bug for bug? User X might ask: double clicking an > exe works in Windows why shouldn't it in Linux? Why should user X > have to go through an extra step to do something on Linux than they > would on Windows? Thing is, this is not something that's explicitly within Wine. It's desktop integration at best, and file manager-specific at worst. I'd say it doesn't fall under the heading of "bug-for-bug compatibility". That's just me though. Comments from real Wine devs would be much more meaningful :)

Feb. 24, 2009

Re: Malware on Wine review

by Dan Kegel

On Mon, Feb 23, 2009 at 4:00 PM, Ben Klein <shacklein(a)gmail.com> wrote: >>>> http://www.avertlabs.com/research/blog/index.php/2009/02/23/running-windows… >>>> >>>> "Do not set the file association for Windows executables with Wine. >>>> This would enable running Windows executables in Wine by simply double >>>> clicking them." >> >> Yes, exactly. The default should be off, and it should be easy to >> turn on. > > And if we're willing to deal with an influx of users complaining why > it doesn't work like that any more, we should do it. We'd probably > also have to get all the package maintainers on board though. Yes, this will require a modicum of consensus. We might decide to stay unsafe, or we might decide to make the bindings be in a separate package, so it's easier for admins to flip the switch. > My packaging process doesn't do anything that explicitly associates > Wine with exes, but I just tried opening an exe from Thunar and it ran > ... interesting. Debian, 1.1.15 Yep. - Dan

Feb. 24, 2009

Re: Malware on Wine review

by Ben Klein

2009/2/24 Dan Kegel <dank(a)kegel.com>: > Ben Klein <shacklein(a)gmail.com> wrote: >>> http://www.avertlabs.com/research/blog/index.php/2009/02/23/running-windows… >>> >>> "Do not set the file association for Windows executables with Wine. >>> This would enable running Windows executables in Wine by simply double >>> clicking them." >>> >>> I saw a patch floating by to turn this on by default recently. Maybe >>> we should make it off by default, but easy to turn on...? >> >> This would annoy all the people that the association targets. We can >> either make it easy to run all Windows apps (malware and legit) via >> file manager, or none at all. > > Yes, exactly. The default should be off, and it should be easy to > turn on. And if we're willing to deal with an influx of users complaining why it doesn't work like that any more, we should do it. We'd probably also have to get all the package maintainers on board though. My packaging process doesn't do anything that explicitly associates Wine with exes, but I just tried opening an exe from Thunar and it ran ... interesting. Debian, 1.1.15

Feb. 24, 2009

Re: Malware on Wine review

by Zachary Goldberg

2009/2/23 Dan Kegel <dank(a)kegel.com>: > Ben Klein <shacklein(a)gmail.com> wrote: >>> http://www.avertlabs.com/research/blog/index.php/2009/02/23/running-windows… >>> >>> "Do not set the file association for Windows executables with Wine. >>> This would enable running Windows executables in Wine by simply double >>> clicking them." >>> >>> I saw a patch floating by to turn this on by default recently. Maybe >>> we should make it off by default, but easy to turn on...? >> >> This would annoy all the people that the association targets. We can >> either make it easy to run all Windows apps (malware and legit) via >> file manager, or none at all. > > Yes, exactly. The default should be off, and it should be easy to > turn on. > - Dan > > > I disagree on this point. Is malware via Wine on Linux really a problem commonly affecting users? What happened to replicated Window's behavior bug for bug? User X might ask: double clicking an exe works in Windows why shouldn't it in Linux? Why should user X have to go through an extra step to do something on Linux than they would on Windows? -Zach

Feb. 23, 2009

Re: Malware on Wine review

by Dan Kegel

Ben Klein <shacklein(a)gmail.com> wrote: >> http://www.avertlabs.com/research/blog/index.php/2009/02/23/running-windows… >> >> "Do not set the file association for Windows executables with Wine. >> This would enable running Windows executables in Wine by simply double >> clicking them." >> >> I saw a patch floating by to turn this on by default recently. Maybe >> we should make it off by default, but easy to turn on...? > > This would annoy all the people that the association targets. We can > either make it easy to run all Windows apps (malware and legit) via > file manager, or none at all. Yes, exactly. The default should be off, and it should be easy to turn on. - Dan

Feb. 23, 2009

Re: Malware on Wine review

by Ben Klein

2009/2/24 Dan Kegel <dank(a)kegel.com>: > http://www.avertlabs.com/research/blog/index.php/2009/02/23/running-windows… > is an interesting report; all the malware he tried ran > to at least some extent on wine. > > One interesting bit of advice he gives at the end is > > "Do not set the file association for Windows executables with Wine. > This would enable running Windows executables in Wine by simply double > clicking them." > > I saw a patch floating by to turn this on by default recently. Maybe > we should make it off by default, but easy to turn on...? This would annoy all the people that the association targets. We can either make it easy to run all Windows apps (malware and legit) via file manager, or none at all. Personally, I don't really care. I tend to run wine from a terminal anyway so I can watch the pretty fixmes. But if it was my decision, I'd probably err on the side of security.

Feb. 23, 2009

Malware on Wine review

by Dan Kegel

http://www.avertlabs.com/research/blog/index.php/2009/02/23/running-windows… is an interesting report; all the malware he tried ran to at least some extent on wine. One interesting bit of advice he gives at the end is "Do not set the file association for Windows executables with Wine. This would enable running Windows executables in Wine by simply double clicking them." I saw a patch floating by to turn this on by default recently. Maybe we should make it off by default, but easy to turn on...?

Feb. 23, 2009

Re: faultrep:display useful information in ReportFault

by Alexandre Julliard

"Jérôme Gardou" <jerome.gardou(a)gmail.com> writes: > Alexandre Julliard a écrit : >> You certainly don't want to add exports to kernel32 for that. Launching >> the debugger isn't hard to do in faultrep, plus you most likely want to >> do it differently from what kernel32 does. >> > Is this one too hackish for you ? Yes. -- Alexandre Julliard julliard(a)winehq.org

Feb. 23, 2009

Re: [try2] gdiplus/tests: Dynamically load gdiplus.dll.

by Vincent Povirk

On Mon, Feb 23, 2009 at 6:15 AM, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > The reason you see this is because next to a normal LoadLibrary we also use the > .NET variant. On some boxes gdiplus.dll cannot be found through LoadLibrary but > will trough LoadLibraryShim. As winetest now thinks the library is there it will > try to launch "gdiplus_test.exe --list" and that of course fails. > > Not sure how to approach this. Silly question: Could we, if LoadLibraryShim returns a library that isn't in the PATH, add it to the PATH in the environment used to call the test exe? Then we would be able to run tests on some "new" versions of dll's we can't cover currently.

Feb. 23, 2009

Re: [try2] gdiplus/tests: Dynamically load gdiplus.dll.

by Detlef Riekenberg

On Mo, 2009-02-23 at 13:38 +0100, Paul Vriens wrote: > > > Is .NET installed (any version)? My w2k test box has the popup about the missing gdiplus and dotnet is installed. >From the dllinfo: gdiplus load error 1359 http://test.winehq.org/data/79cc4163fa4867ce0b28ce83111dc6bc18d3df15/2000_d… -- By by ... Detlef

Feb. 23, 2009