October 2002 - Wine-Devel - list.winehq.org

Some other problems ...

by Paul Millar

Hi everyone, Just a couple of problems I've noticed. They look like they're due to some broken build dependencies. 1. I have a copy of wine on my laptop which I do "cvs update" every few days. After updating today, I did the usual "./configure --enable-opengl && make depend && make" and left it to compile. But, when I tried the result, I got a client/server mismatch for SERVER_PROTOCOL_VERSION. One was claimed to be v88 whilst the other was v89. Doing a "make distclean" then repeating the build "fixed" the problem. Patch http://cvs.winehq.com/patch.py?id=6064 (committed last Tuesday) bumped the SERVER_PROTOCOL_VERSION up to 89. So it looks like some of the binaries weren't updated during the build. I tried altering the version (manually) and rebuilding, but wine rebuilt correctly. 2. WRT hit a problem last night where "make test" failed. The log included messages like: gcc -c -I. -I. -I../../../include -I../../../include -g -O2 -Wall -mpreferred-stack-boundary=2 -fPIC -DSTRICT -DNONAMELESSUNION -DNONAMELESSSTRUCT -D_REENTRANT -o registry.o registry.c LD_LIBRARY_PATH="../../../library:../../../unicode:$LD_LIBRARY_PATH" ../../../tools/winebuild/winebuild -fPIC -DSTRICT -DNONAMELESSUNION -DNONAMELESSSTRUCT -o advapi32_test.exe.spec.c -exe advapi32_test.exe -mcui registry.o testlist.o -L../../../dlls -ladvapi32 -lkernel32 -lntdll gcc -shared -Wl,-Bsymbolic advapi32_test.exe.spec.o registry.o testlist.o -o advapi32_test.exe.so -L../../../library -lwine -lm advapi32_test.exe.spec.o: In function `__wine_exe_main': /home/paulm/WINE-cvs/wine/dlls/advapi32/tests/advapi32_test.exe.spec.c:116: undefined reference to `main' registry.o: In function `test_enum_value': /home/paulm/WINE-cvs/wine/dlls/advapi32/tests/registry.c:69: undefined reference to `winetest_set_ok_location' /home/paulm/WINE-cvs/wine/dlls/advapi32/tests/registry.c:69: undefined reference to `winetest_ok' /home/paulm/WINE-cvs/wine/dlls/advapi32/tests/registry.c:78: undefined reference to `winetest_set_ok_location' [... etc ...] The later build had six tests that succeded. These were the new scanf tests introduced into that build by patch http://cvs.winehq.com/patch.py?id=6107 I've just done a "make distclean" followed by a normal rebuild and test. Its currently running through the regression tests, but so far it seems to be working. These are vague reports of unrepeatable problems ... never a good thing! I'm quite busy right now (real work and everything), so I don't have time to investigate this myself. Just posting this hoping the cause its obvious to someone else :^) ---- Paul Millar

Oct. 31, 2002

Re: So lets say we do it

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > On October 31, 2002 11:40 am, Carlos Lozano wrote: > > 10th Anniversary (??-??-2003)? sounds to a good date. > > Cool! :) Alexandre, when is that? Sometime in June, I don't have the exact date of the first release unfortunately. Release 0.0.2 was on June 25. -- Alexandre Julliard julliard(a)winehq.com

Oct. 31, 2002

Re: So lets say we do it

by Dimitrie O. Paun

On October 31, 2002 11:24 am, Alexandre Julliard wrote: > You forgot a few things here: Yes, and no: it was getting late, hand was all funny, email was getting too long... :) > First it doesn't even start because they don't have a config file. OK, Hear, hear! BTW, we should move configuration out of documentation/samples > [...] it doesn't work because the drives are wrong. Yep. wineinstall? > Then they don't have the proper registry (winedefault.reg? what's that?) :))) > Then they finally manage to run the installer but it > puts stuff in RunOnce that never gets run so the app doesn't work. See, I wasn't even aware of that! > Then they finally make the app run but can't print anything. And True. > when they ask for help they get told to fight the FAQ-O-Matic crap to > maybe finally find an answer telling them they are an idiot. That FAQ-O-Matic should just be 'rm -rf'. It's crap. We either have a carefully hand-written FAQ, or nothing at all. > So no, I'm not going to make a general public release just yet... I am not even suggesting it. I just went through the exercise so we can extract a TODO... -- Dimi.

Oct. 31, 2002

Re: dlls/msvcrt/tests: printf

by Jaco Greeff

On Thu Oct 31 20:04:30 2002, "Jaco Greeff" <jaco(a)puxedo.org> wrote : > On Thu, 31 Oct 2002 17:57:12 +0100, Uwe Bonnes > <bon(a)elektron.ikp.physik.tu-darmstadt.de> wrote : > > Jaco> ... Tests that will fail > > Jaco> with current implementation are temporarily commented out > > > > Don't comment them out, matrk them "todo". Look at the syntax in > > documentation/testing. > > I've marked the code with a "FIXME". Sorry, I misunderstood the first time around, will something like todo("linux") { do(something() == 1, "whatever"); } do the trick? But unsure about the definition I should use, I can see "cygwin", "freebsd", etc. This one will fail on all non-Windows platforms. Greetings, Jaco

Oct. 31, 2002

Re: Wine securityflaw.

by Geoff Thorpe

On Thursday 31 Oct 2002 10:00 am, Greg Turner wrote: > On Thursday 31 October 2002 08:10 am, Raul Dias wrote: > > My $0.02, > > > > A way to make it more secure is to catch key API calls and decide if > > the application is allowed to run it or not. > > not a bad idea. > > > Wine could implement a clean Security Layer: YES > > Clean, perhaps, but secure? That depends on what you are trying to > achieve: since the unix API is available to apps running under wine, This subject interests me a great deal so please humour me as I try to wrap my head around the wine-specifics well enough to get an accurate(ish) picture of this. I'm a security person, but no win32 expert and even less of a PE/ELF hacker... First I can understand the point made that, at the end of the day, the only *actual* security you can force on a wine-loaded application is whatever security the operating system forces on *all* applications (wine-loaded or otherwise) running as the same user. Ie. even if a win32 application loaded under wine couldn't directly call ioctl(), unlink(), or fopen(), the binary code could still *reimplement* those functions in assembly. I also realise that other assembly hacks (or just trail-and-error "luck" virii) could scan the process's memory space looking for likely function pointers, file-descriptors, etc and start meddling with them directly to bypass the wine-implemented win32 API. Does that seem a reasonable understanding of the situation? My next question is this: why is the unix API available to wine-loaded PE apps/libs? I can't see a single compelling reason for this, though I'm prepared to be illuminated otherwise. If we discard memory-scanning and other assembly tricks for a moment and consider just the case of PE apps/libs generated from "clean C" (and "clean compilers"); then preventing any direct binding of any wine-loaded PE images to native ELF images, *except* those implemented by wine, immediately raises the bar. Of course, I'm assuming this is *possible* with the PE (and ELF) format(s)? My problem with discarding the "clean" security layer because it isn't perfectly impenetrable in a technical sense, is that it is purely an abstract technical-only view of things, and Wine's role (and threat-model for its future success) is anything but purely technical. Jeremy, I'd be particularly interested if you have any thoughts on this. AFAICS, this idea is not just a question of security by obscurity - there are technical and "political" issues involved too. First, not linking PE images to non-wine ELF images allows one to define a security policy in wine for win32/PE executable code akin to a "rules for Win32 programs" config. One possibility here is the kind of thing Raul was discussing. Buggy programs aren't programs that try to detect if they're running in wine and if so do damage - buggy programs are programs using the win32 API written by careless win32 bunnies. *Those* programs could be subject to a policy configuration that would allow you to selectively restrict things in a way that will *always* be better than what MS-windows provides - whether the programs are horribly buggy or really solid. In other words, a configurable real-world control/protection against potentially buggy win32 code (that would be equally buggy on MS-windows and Wine after all). Second, if the PE loader doesn't blindly link PE apps/libs to native libraries, then bypassing the wine-implemented win32 API (and thus the policy configuration) would require an *explicit* workaround on the part of the programmer. Putting in assembly code to prime registers and fire interrupts that (a) on linux would getenv("HOME") and unlink() the result, and (b) on windows would probably just crash with a BSOD is what the security community call a "virus". :-) It doesn't have to be difficult for the programmer to do it, it just has to require him/her to be malicious and unambiguously *intend* to do it. Writing and distributing one of these things opens you up to criminal prosecution in many jurisdictions, and also allows McAfee and friends to assign a signature to corresponding binaries and get them classified as a virus (and their authors classified as bad people). Or put another way - as Wine converges on "beta" or "release" level and Wine + XXX/OS (where XXX=Linux,FreeBSD,etc) becomes not only a competitor to MS-windows, but in fact offers considerable advantages, where then will the *threats* to wine lie?? I would certainly like to (a) see the flexibility of being able to apply a "soft" security policy for win32 applications in the wine-implemented win32 API, (b) force win32 developers who are "anti-wine" and "pro-monopoly" to have to expose themselves to criminal possibilites if they want to bypass wine-based execution configuration and controls (or worse, if they want to package anti-wine trojans). > So, for example, this could be used to protect a system against > security flaws in Internet Exploder or Outlook... but a malicious virus > writer could work around winapi-based security provisions, as discussed > earlier in this thread. Yes, and I think the point that's worth making is that writing a malicious virus against wine is not only a crime in the sense that normal virus-writing is a crime, but also has anti-trust/anti-competition overtones ... when you try to imagine which companies would most like their win32-based applications to *NOT* run on wine (and perhaps even hurt wine users), you might understand where I'm coming from. In lieu of "pure" security enforcements (which would require virtualisation anyway which Wine is not in the business of), I think a "win32-API-based" security approach is worthwhile. If I can write win32 apps that link directly to libc, I could elect to replace the file-management subsystem of my app with a POSIXy layer that is only used on wine "for performance reasons only, honest!". This would mean (a) Wine's file-system configuration can be bypassed, and (b) I could (perhaps deliberately) embed nasty corruption bugs in my POSIX subsystem but have my win32 subsystem very stable. This program would just be "unstable on wine" but not "anti-competitive" nor "criminal". But if you don't let applications do this in wine's PE-loader (or at least let it be controllable in the config) then acheiving the same result would require me to write a genuine virus instead (and so open myself to anti-trust/criminal accusations). Thoughts? Cheers, Geoff -- Geoff Thorpe geoff(a)geoffthorpe.net http://www.geoffthorpe.net/

Oct. 31, 2002

Re: dlls/msvcrt/tests: printf

by Jaco Greeff

On Thu, 31 Oct 2002 11:04:48 -0600, Greg Turner <gmturner007(a)ameritech.net> wrote : > On Thursday 31 October 2002 10:34 am, Jaco Greeff wrote: > > - Tests that will fail with current implementation are temporarily > > commented out > > Is there a middle ground for tests that are expected to fail? If not, > IMO maybe there should be: It kinda defeats the purpose of a test > framework if we just comment out tests that don't work... Agreed. It will pass shortly though :) At this point the test will help anybody wishing to verify my latest msvcrt patch. Plus, it really should pass. The part that does fail is on Unicode printing, which give me one of a few choices: 1. Don't send in a test; 2. Be stubborn and let the test fail for everybody doing a make test; 3. Send in a really crippled test case; 4. Combination of 3 + 4 so people can easily have the framework to test if progress have been made. That is the reason why I've commented it out, hopefully shortly it will be fully featured. Greetings, Jaco

Oct. 31, 2002

Re: So lets say we do it

by Marcus Meissner

On Thu, Oct 31, 2002 at 08:24:28AM -0800, Alexandre Julliard wrote: > "Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > > > So the 5% left, install wine, install a Win-app, and play around. > > Great, it works! > > You forgot a few things here: As for the SuSE wine RPMS: > First it doesn't even start because they don't have a config file. OK, > they copy one from somewhere, it doesn't work because the drives are > wrong. Been there, done that. Not very good, it is still using winesetuptk which might be too much in way of configuration. > Then they don't have the proper registry (winedefault.reg? > what's that?) Merged automatically with startup script. > Then they finally manage to run the installer but it > puts stuff in RunOnce that never gets run so the app doesn't > work. Ok, this one is still missing. > Then they finally make the app run but can't print anything. Two edged sword. CUPS works fine here, however if all applications are ready to print with WINEPS and winspool.drv is another issue. > And > when they ask for help they get told to fight the FAQ-O-Matic crap to > maybe finally find an answer telling them they are an idiot. Yep. But this one is harder, what do you think needs to be there? > So no, I'm not going to make a general public release just yet... Not yet too late for another 'Halloween' release though ;) Ciao, Marcus

Oct. 31, 2002

Re: dlls/msvcrt/tests: printf

by Jaco Greeff

On Thu, 31 Oct 2002 17:57:12 +0100, Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> wrote : > Jaco> ... Tests that will fail > Jaco> with current implementation are temporarily commented out > > Don't comment them out, matrk them "todo". Look at the syntax in > documentation/testing. I've marked the code with a "FIXME". I don't want the test sequence to fail for this issue which is solved by my msvcrt patch. The way I've done it allows others to verify the new vfprintf patch with minimal work. > And plain inlined patches are preferred against attachments. I'm doing this via a mail web interface, it has the ugly habit of doing line-wraps. I also prefer inline patches (like to see what is going on without have to save etc.), it is just not entirely possible for me at this point. *sigh* Greetings, Jaco

Oct. 31, 2002

Re: So lets say we do it

by Dimitrie O. Paun

On October 31, 2002 11:40 am, Carlos Lozano wrote: > 10th Anniversary (??-??-2003)? sounds to a good date. Cool! :) Alexandre, when is that? -- Dimi.

Oct. 31, 2002

Re: dlls/msvcrt/tests: printf

by Greg Turner

On Thursday 31 October 2002 10:34 am, Jaco Greeff wrote: > - Tests that will fail with current implementation are temporarily > commented out Is there a middle ground for tests that are expected to fail? If not, IMO maybe there should be: It kinda defeats the purpose of a test framework if we just comment out tests that don't work... but OTOH, its pretty unfair to the other tests to have the whole "make test" fail because of some known issue. -- gmt "The purpose of government is to rein in the rights of the people" --President Bill Clinton, MTV interview, 1993

Oct. 31, 2002