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

Re: wiki.winehq.org down?

by Michael Stefaniuc

Dan Kegel wrote: > I can't get pages from http://wiki.winehq.org, > though I can ping lattica.ca. > The web server there seems to close connections > after a long pause without any response. > > it looks like the wiki server needs restarting? Works again after Dimi rebooted the server. bye michael

Feb. 25, 2009

wiki.winehq.org down?

by Dan Kegel

I can't get pages from http://wiki.winehq.org, though I can ping lattica.ca. The web server there seems to close connections after a long pause without any response. it looks like the wiki server needs restarting?

Feb. 25, 2009

appdb issue: can't search for apps platinum on 1.0.x!

by Dan Kegel

Our currently released version is 1.0, but the appdb's browse feature acts as if that version no longer exists. This will seriously confuse newcomers who are using the 1.0.1 version (e.g. anybody who installs a fresh copy of Ubuntu!). To fix this, we should add 1.0 (or 1.0.1) back into the search box in http://appdb.winehq.org/objectManager.php?sClass=application

Feb. 25, 2009

Re: crypt32: Fix more test failures on Win9x

by Paul Vriens

Paul Vriens wrote: > Juan Lang wrote: >> --Juan >> >> >> ------------------------------------------------------------------------ >> >> > Hi Juan, > > The first 4 changes are not correct. Win9x returns TRUE (1) here. > Well actually the first two on Win95 and the last two on Win95/Win98. -- Cheers, Paul.

Feb. 25, 2009

Re: crypt32: Fix more test failures on Win9x

by Paul Vriens

Juan Lang wrote: > --Juan > > > ------------------------------------------------------------------------ > > Hi Juan, The first 4 changes are not correct. Win9x returns TRUE (1) here. -- Cheers, Paul.

Feb. 25, 2009

Re: Malware on Wine review

by Chris Robinson

On Wednesday 25 February 2009 9:22:29 am Vincent Povirk wrote: > This discussion has been assuming that .exe files are somehow special > because they are programs Actually, I'm saying just the opposite. They are *not* special because they are programs, and should honor the executable bit just like any other program should. > What we really > should do is make sure the file manager knows about these types so it > can apply a consistent policy. You mean that dolphin, nautilus, konqueror, firefox, kmail, and anything that can "open" a file should all be made aware of what the different types of files can do? Is it really their responsibility? IMO, it would be better to just hand off a file to its associated program, whether that program is wine, kwrite, firefox, or what-have-you.. the handler should know the type of file better than a file manager, and the handler can be made to honor the proper permissions much easier and quicker than trying to keep all file managers up-to-date. As an example, suppose Dolphin is made to be aware that exe files are programs, and thus restricts opening it with Wine if +x isn't set. A new app comes along that does not know anything special about exe files and/or passes it off to Wine as the associated program anyway. It becomes popular, and the less-technically-inclined people start using it. That puts us right back at square one.

Feb. 25, 2009

Re: Malware on Wine review

by Vincent Povirk

On Wed, Feb 25, 2009 at 10:38 AM, King InuYasha <ngompa13(a)gmail.com> wrote: > AFAIK, the main difference between the Wine and Java methods is > that Wine doesn't sandbox its loading environment, while Java does. Java doesn't create a sandbox when you run a normal application. Which makes it a wonderful example. This discussion has been assuming that .exe files are somehow special because they are programs (and thus can do anything your user can do), but they shouldn't be executed directly (before anyone mentions binfmt-support, that's broken and unfixable for this case). I don't think exe is likely to be the only file type like that. What we really should do is make sure the file manager knows about these types so it can apply a consistent policy. This information would also be useful to firefox and any other program that handles possibly-untrusted files of arbitrary type. Vincent Povirk

Feb. 25, 2009

Re: Malware on Wine review

by Chris Robinson

On Wednesday 25 February 2009 8:38:15 am King InuYasha wrote: > Now that Nautilus has the desktop file requiring execute bit, I have a > question for all of you to consider. Do JAR files require the +x bit to > load them, or are they treated like associated files and run through the > interpreter? Really, Windows apps on Linux is basically the same situation > as Java applications run through the bytecode interpreter. Not really. When Java byte code is run through an interpreter, the program is implicitly bound by what the JRE allows. If the JRE does not allow you to access feature X, the program can't access feature X in any way (barring fixable bugs, of course). The JRE is in control of the program. A program loaded with Wine, by contrast, can do anything a normal program can. All Wine does is set up an initial environment Windows apps expect, loads the program into memory, then sets it off to run on its own. Wine cannot disallow a program from accessing feature X if it wants to. The program is in control of Wine.

Feb. 25, 2009

Re: Malware on Wine review

by King InuYasha

On Wed, Feb 25, 2009 at 7:56 AM, Johan Dahlin <johan(a)gnome.org> wrote: > Dan Kegel wrote: > > On Tue, Feb 24, 2009 at 6:07 PM, Scott Ritchie <scott(a)open-vote.org> > wrote: > >> When I brought this up at the Ubuntu Developer Summit a while back, the > >> security conscious there wanted to check an executable for the execute > >> bit before launching it with Wine. Then, the user would be prompted if > >> they wanted to run it, and if yes the execute bit would be set and the > >> program launched. > >> > >> This check would be skipped if you clicked a link on the start menu > >> (since you obviously meant to launch a program then). > > > > Sounds good. A helper app could do this for us, I think. > > > >> That said, there's no point becoming "safe" until the desktop also > >> disables single click running of .desktop files that don't have the > >> execute bit set. It's trivial to write a piece of Linux malware that > >> does whatever you want by making it a .desktop file - you can even make > >> it so it displays as whatever name you like (and not foo.desktop). > > > > Right. Both changes are needed, the .desktop one more urgently. > > That's already solved in nautilus; > > http://svn.gnome.org/viewvc/nautilus?view=revision&revision=15003 > > Johan > > > > Now that Nautilus has the desktop file requiring execute bit, I have a question for all of you to consider. Do JAR files require the +x bit to load them, or are they treated like associated files and run through the interpreter? Really, Windows apps on Linux is basically the same situation as Java applications run through the bytecode interpreter. Most distros do not treat Java JAR files are executables, but rather as an associated file to the JVM. AFAIK, the main difference between the Wine and Java methods is that Wine doesn't sandbox its loading environment, while Java does. If Wine used a W32VM of some kind, then it would make more sense _not_ to require the execute bit. However, it does not use one, so it would make sense to have the execute bit. Also, NTFS DOES have a concept of execute bits, but Windows itself does not use them. An implementation of this is the "trusted" app scheme in the properties in Windows Vista and above (I don't remember if XPSP2 had it also). Although this scheme is mostly broken, it was intended to stop the execution of apps just downloaded from the internet from a non-trusted source.

Feb. 25, 2009

Re: Malware on Wine review

by Johan Dahlin

Dan Kegel wrote: > On Tue, Feb 24, 2009 at 6:07 PM, Scott Ritchie <scott(a)open-vote.org> wrote: >> When I brought this up at the Ubuntu Developer Summit a while back, the >> security conscious there wanted to check an executable for the execute >> bit before launching it with Wine. Then, the user would be prompted if >> they wanted to run it, and if yes the execute bit would be set and the >> program launched. >> >> This check would be skipped if you clicked a link on the start menu >> (since you obviously meant to launch a program then). > > Sounds good. A helper app could do this for us, I think. > >> That said, there's no point becoming "safe" until the desktop also >> disables single click running of .desktop files that don't have the >> execute bit set. It's trivial to write a piece of Linux malware that >> does whatever you want by making it a .desktop file - you can even make >> it so it displays as whatever name you like (and not foo.desktop). > > Right. Both changes are needed, the .desktop one more urgently. That's already solved in nautilus; http://svn.gnome.org/viewvc/nautilus?view=revision&revision=15003 Johan

Feb. 25, 2009