wine-devel January 2009

wine-devel@winehq.org

149 participants
339 discussions

Does this D-Bus change affect us? (Fwd: New D-Bus Uploaded)
by Scott Ritchie 21 Jan '09

21 Jan '09

This email was just sent to the Ubuntu developer list about a change to D-Bus security in 9.04 -- do I need to create a D-Bus .conf file for Wine, or will the default policy suffice for us? Thanks, Scott Ritchie Scott James Remnant wrote: > If your package contains a D-Bus system bus service, you need to pay > attention! > > It was discovered that the default policy of the D-Bus system bus was > not as was expected, due to a quirk of the language. In fact, whereas > the default policy was supposed to have been that messages would not be > allowed by default, the default was in fact that messages _were_ > allowed! > > CVE-2008-4311 was issued, and a new release of D-Bus was updated to > correct the default policy to be deny-by-default. > > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4311 > > It was quickly discovered that the policy files shipped by most services > no longer worked, and that many were (inadvertently, perhaps) relying on > the misconfiguration of the daemon. > > > We've audited the system bus services shipped in Ubuntu, and are > confident that there is no security exploit. Those services exporting > privileged methods either have sufficient "deny" rules, or use PolicyKit > for authorisation. > > For this reason, and due to the large potential for regressions, we've > opted not to release a security update for previous Ubuntu versions. We > may still do so if we discover a potential for exploit. > > > However this is a bug, and I've uploaded a new version of D-Bus to > jaunty that corrects it. I've filed bugs on all packages that appear to > ship a D-Bus system bus service (those with /etc/dbus-1/system.d/*.conf > files), but I may have missed some. I'd appreciate your help tracking > down any I've missed, and updating all of the packages. > > Please read the following carefully to assist with updating the > configuration. > > > The default policy of the D-Bus system bus is: > > - Name ownership is DENIED by default. > > - Method calls are DENIED by default. > > - Replies to method calls, including errors, are PERMITTED by default. > > - Signals are PERMITTED by default. > > > Therefore each service MUST, in its policy configuration: > > - Permit an appropriate user to own the name it wishes to claim: > > <policy user="example"> > <allow own="com.ubuntu.Example" /> > </policy> > > - Allow method calls to be made on objects it exports, for particular > users. This may be done in a number of different ways. > > You may simply allow all method calls to your claimed name: > > <policy context="default"> > <allow send_destination="com.ubuntu.example" /> > </policy> > > You may allow method calls to particular interfaces you export, > especially useful if you have privileged and non-privileged > interfaces: > > <policy context="default"> > <allow send_destination="com.ubuntu.example" > send_interface="com.ubuntu.Example" /> > </policy> > > <policy user="root"> > <allow send_destination="com.ubuntu.example" > send_interface="com.ubuntu.Example.System" /> > </policy> > > *IMPORTANT* you MUST include send_destination on ALL allow or deny > tags. Omitting it is a SERIOUS bug! > >  > <allow send_interface="x.y.z" /> > > This allows any service to receive method calls of the given > interface, not just your own service! > > It also implicitly allows any service to receive method calls > with no interface specified, in case they match this interface! > > Using the above means you are potentially allowing exploiting of > a different service. DO NOT DO IT! > >  > <deny send_interface="x.y.z" /> > > This denies all services from receiving method calls of the > given interface, not just your own service! It also implicitly > denies all services from receiving method calls with no > interface specified. DO NOT DO IT! > > - You must allow standard interfaces as well, such as Introspection and > Properties: > > <policy context="default"> > <allow send_destination="com.ubuntu.example" > send_interface="org.freedesktop.DBus.Introspectable" /> > <allow send_destination="com.ubuntu.example" > send_interface="org.freedesktop.DBus.Properties" /> > </policy> > > > - You should not normally allow receipt of any messages sent from your > interface, this is also the default. > > (ie. remove any lines of the form <allow receive_*>) > > > - You do not normally need to deny any messages, this is the default. > > (ie. remove any lines of the form <deny...>) > > > You should fully test the service with the new D-Bus after updating the > policy, you'll need to restart the bus daemon for that (it's probably > easier to reboot). > > If messages are being denied, it will be logged in /var/log/auth.log as > follows: > > Dec 19 14:17:53 space-ghost dbus: Rejected send message, 1 matched > rules; type="method_return", sender=":1.26" (uid=0 pid=2966 > comm="/usr/libexec/nm-dispatcher.action ") interface="(unset)" > member="(unset)" error name="(unset)" requested > _reply=0 destination=":1.18" (uid=0 pid=2806 comm="NetworkManager > --pid-file=/var/run/NetworkManager/")) > > > Be aware that a denied message may still happen if you have other > invalid policy installed (such as those which don't qualify allow/deny > rules with the destination!). Take the opportunity to fix all you see. > > Scott >

4 3

Add "none" to list of skipped filesystems in automatic drive detection
by Ben Klein 21 Jan '09

21 Jan '09

In programs/winecfg/drivedetect.c, there is a list of skipped filesystem types: static const char * const ignored_fstypes[] I propose that "none" be added to this list. The "none" type is used in fstab in combination with options such as "bind" and "rbind". I have such entries in my fstab for my various chroots that I use to build packages of Wine.

1 0

Re: [1/2] dinput: Do not close device upon Unacquire
by Vitaliy Margolen 21 Jan '09

21 Jan '09

Vincent Pelletier wrote: > This fixes force feedback effects in MS Flight Sim 2000: it releases the > device after uploading effects, reaquires it later and try to update effects. > This fails, because linux requires all access to be done from a single file > descriptor. > > It doesn't feel right to open a device without ever closing it... But I could > not find any "dealloc" method. > This patch is not correct. The device can get removed, opened by other application, etc. You can't open it during the creating and keep it open all that time. The more correct way to do it would be to re-upload all the state changes on acquire. Vitaliy.

1 0

Re: dinput: Add effect gain support
by Daniel Remenak 21 Jan '09

21 Jan '09

On Mon, Jan 19, 2009 at 12:52 PM, Vincent Pelletier <plr.vincent(a)gmail.com> wrote: > dinput: Add effect gain support > > -- > Vincent Pelletier > Vincent, This patch is ok as far as it goes, but not completely correct. Firstly, SetParameters needs to apply the parameters to effects while they are playing, not just store them. Existing parameters are all part of the effect structure, so that is taken care of automatically. Since gain is handled by a different mechanism, you also need to handle the while-playing case (unless DIEP_NODOWNLOAD is specified). This probably means you need to implement GetEffectStatus, since you won't want to apply the gain unless the effect is playing. Secondly, the kernel's ff.txt suggests that evdev handles the gain globally for the device. Since the DirectInput definition of gain is per-effect rather than per-device, you should also test what happens when you set the gain differently in two simultaneously-playing effects on the same device. If Windows mixes them (i.e. truly applies the gain per-effect) then we need to come up with some logic to do the same (probably by scaling the effect envelope or magnitude, depending on the effect type, and keeping it updated when the user modifies the scaled parameters). Thirdly, SetParameters still has a comment that says gain and sample periods aren't supported. Please update any applicable comments when you update the code - outdated comments are worse than no comments at all. Regards, Daniel Remenak

1 0

Re: Support for Dragon NS in Wine
by Susan Cragin 21 Jan '09

21 Jan '09

>On Tue, Jan 20, 2009 at 3:23 PM, Jeff Zaroyko <jeffzaroyko(a)gmail.com> wrote: >> While I don't own any NS product, two open bugs to come to mind for NS >> 8, one affecting the installer but with a workaround, bug 15708 and >> the other a user has reported a regression bug 16248 but was not >> interested in running a regression test. >> >> http://bugs.winehq.org/show_bug.cgi?id=15708 >> http://bugs.winehq.org/show_bug.cgi?id=16248 > >I think those were both for NS 7, not 8... >A full list of NS bugs is at >http://bugs.winehq.org/buglist.cgi?quicksearch=Dragon+Naturally+Speaking >Looks like 9 is happier than 10...? I have 7, 8, 9, 9.5 and 10 here. I'll test a couple tonight, maybe 7 and 8, on today's git. Here's what I remember. 7 worked great right out of the box at one time, with all-native code. 8 is virtually the same product as 7. Ditto worked great. (Nobody bought 8 much because it was the same engine as 7.) 9.0 worked pretty good out of the box with a couple of glitches. 9.5 does not install, and works not at all, except for one lucky man who developed a workaround that doesn't always work. (9.5 replaced 9.0 as "version 9," and 9.0 is no longer sold, at least in the US.) 10.0 installs well and runs pretty well for 10 minutes, then nasty crashes happen. Wine support has been given primarily for the two cheapest "consumer" versions, Standard and Preferred. Very few people have asked about Professional, and I don't know of anyone who has tried to make Professional 8 run with wine. Susan

2 1

Support for Dragon NS in Wine
by Steven Druker 20 Jan '09

20 Jan '09

Dan, I deeply appreciate your endeavors to broaden the number of Windows-based applications that will run on Linux via Wine. Your Feb. '08 message indicated that while you had achieved significant progress for Dragon NS, it was not yet fully functional. Since then has more progress been made? I'm particularly interested in whether the professional versions of NS 8 as well as 10 are fully supported now. Thank you for whatever information you can provide. Steven M. Druker Executive Director Alliance for Bio-Integrity www.biointegrity.org Home Office: (641) 472-8008

3 3

$200 bid for autocad support
by Dan Kegel 20 Jan '09

20 Jan '09

http://www.rentacoder.com/RentACoder/misc/BidRequests/ShowBidRequest.asp?ln… Someone's got to break the bad news to him about the likely cost...

2 1

Re: Fix wine-bugs mailing list traffic message.
by Francois Gouget 20 Jan '09

20 Jan '09

On Tue, 20 Jan 2009, Christoph Korn wrote: > Only a small fix. > > I subscribed to the wine-bugs mailing list because it was listed as > medium traffic. But I got hundreds of mails in about two hours or so. Usually it's a medium traffic mailing list (I believe), but occasionally (2/3 times a year) someone does a big cleanup touching hundreds of bugs and that's when you get a lot of emails... -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ If it stinks, it's chemistry. If it moves, it's biology. If it does not work, It's computer science.

3 2

re: QT4 applications not receiving clicks
by Dan Kegel 20 Jan '09

20 Jan '09

louis wrote: > I may have uncovered a bug in which grandchild HWNDs do not receive mouse-down events. Cool... think you can come up with a conformance test that demonstrates the bug? That might be the best way to answer your questions. - Dan

1 0

QT4 applications not receiving clicks
by louis＠museresearch.com 20 Jan '09

20 Jan '09

Hi, I'm looking at a WINE issue in which some QT-based software isn't getting mouse clicks. The program in question is a VST plug-in. The plug-in, in our host, creates its UI in a child window. Now, in QT, HWNDs are created several layers deep-- seemingly one HWND per widget (QWidget), and then a few others like "QEventDispatcher". I think in doing this, I may have uncovered a bug in which grandchild HWNDs do not receive mouse-down events. To summarize before I dive into the details: On these mouse-down events, WINE attempts to bring the HWND to the front, but fails because the HWND in question is not a top-level window or a top-level window's child and subsequently eats the message. Now for the gory details. Let's start at process_mouse_messages in user32/message.c. If the event in question is a button-down event, WINE tries to activate the window it's for. In the switch statement near the bottom of the function, there is a case MA_ACTIVATE. This calls FOCUS_MouseActivate which in turn calls set_foreground_window (both in user32/focus.c). Jump to the wineserver's set_foreground_window function (in server/queue.c). There is a line which reads: if (is_top_level_window( req->handle ) && . . . ) What this is_top_level_window function says (in server/window.c) is to return true only if the HWND is_desktop_window or a child of the desktop window. is_desktop_window says to return true if there is no parent (because "only desktop windows have no parent"). So, if the HWND has no parent or is the parent of a window with no parent, WINE deems the window top level and the HWND receives the click. If this test fails, set_foreground_window returns an error and causes process_mouse_messages to eat the click instead of passing it on. So, I have a couple questions about WINE operation. My first question is whether the click really should be passed on even if WINE can't bring the HWND to the front in this case. My second question is whether the top-level window test works as expected-- my instinct was that the top-level window is just a window without a parent and that the check might not need to involve the desktop. Thanks, Louis Gorenfeld Muse Research

1 0

← Newer
1
...
11
12
13
14
15
16
17
...
34
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel January 2009