June 2015 - Wine-bugs - list.winehq.org

[Bug 625] Applications cannot load dlls from custom folders
by wine-bugs＠winehq.org 20 Jun '15

20 Jun '15

https://bugs.winehq.org/show_bug.cgi?id=625 --- Comment #22 from Ken Sharp <imwellcushtymelike(a)gmail.com> --- No change in Wine 1.7.44 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 38170] New: wine fails to start on raspian/raspberry pi
by wine-bugs＠winehq.org 19 Jun '15

19 Jun '15

https://bugs.winehq.org/show_bug.cgi?id=38170 Bug ID: 38170 Summary: wine fails to start on raspian/raspberry pi Product: Wine Version: 1.7.37 Hardware: arm OS: Linux Status: NEW Keywords: download, source Severity: critical Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: austinenglish(a)gmail.com Distribution: --- I recently got a raspberry pi for a project, and tried wine on it. It compiles (slowly, took 320 minutes), but trying to start anything fails: pi(a)raspberrypi ~ $ ./wine-git/wine notepad wine: failed to map the shared user data: c0000018 pi(a)raspberrypi ~ $ ./wine-git/wine winecfg wine: failed to map the shared user data: c0000018 pi(a)raspberrypi ~ $ ./wine-git/wine winemine wine: failed to map the shared user data: c0000018 pi(a)raspberrypi ~/wine-git $ git describe wine-1.7.37-143-g3b2cf06 pi(a)raspberrypi ~/wine-git $ uname -a Linux raspberrypi 3.18.7-v7+ #755 SMP PREEMPT Thu Feb 12 17:20:48 GMT 2015 armv7l GNU/Linux pi(a)raspberrypi ~/wine-git $ cat /etc/issue Raspbian GNU/Linux 8 \n \l There was a previous report, bug 33578, but it has been abandoned. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 32848] New: netstat: misaligned ethernet statistics output for non English locales
by wine-bugs＠winehq.org 19 Jun '15

19 Jun '15

http://bugs.winehq.org/show_bug.cgi?id=32848 Bug #: 32848 Summary: netstat: misaligned ethernet statistics output for non English locales Product: Wine Version: 1.5.22 Platform: x86-64 OS/Version: Linux Status: NEW Keywords: download, source Severity: normal Priority: P2 Component: programs AssignedTo: wine-bugs(a)winehq.org ReportedBy: frederic.delanoy(a)gmail.com Classification: Unclassified When using -e option for non English locales, the output is misaligned: In English locale, Received Sent Bytes 903340205 2881805984 Unicast packets 45021963 30960216 Non-unicast packets 0 0 Discards 6 0 Errors 0 0 Unknown protocols 0 while in French locale: Reçus Envoyés Octets 903340449 2881855289 Paquets monodiffusion 45022225 30960476 Paquets non monodiffusion 0 0 Rejets 6 0 Erreurs 0 0 Protocoles inconnus 0 or German locale: Empfangen Gesendet Bytes 903340449 2881853989 Unicast Pakete 45022219 30960469 Nicht-Unicast Pakete 0 0 Verworfen 6 0 Fehler 0 0 Unbekannte Protokolle 0 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

1 1

[Bug 34645] New: Updating menubar bar icon content.
by wine-bugs＠winehq.org 18 Jun '15

18 Jun '15

http://bugs.winehq.org/show_bug.cgi?id=34645 Bug #: 34645 Summary: Updating menubar bar icon content. Product: Wine Version: 1.7.3 Platform: x86-64 OS/Version: Mac OS X Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: winemac.drv AssignedTo: wine-bugs(a)winehq.org ReportedBy: f.platte(a)platte-web.de Classification: Unclassified I am using an application which has a menubar icon with the ability of showing updates. In this case it is not a change of the icon itself (I don't know whether this works) but giving some additional textual information. This output does not appear. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

1 8

[Bug 37884] New: Proposal: remove 'ipc' keyword from Bugzilla (no longer in use, questionable benefit)
by wine-bugs＠winehq.org 18 Jun '15

18 Jun '15

https://bugs.winehq.org/show_bug.cgi?id=37884 Bug ID: 37884 Summary: Proposal: remove 'ipc' keyword from Bugzilla (no longer in use, questionable benefit) Product: WineHQ Bugzilla Version: unspecified Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: bugzilla-unknown Assignee: wine-bugs(a)winehq.org Reporter: focht(a)gmx.net Distribution: --- Hello folks, there were only three bugs that used the 'ipc' keyword and two of them were incorrect. It was never properly used in the past and a lot more bugs would need to be tagged if the description is taken seriously - not 100 though as I wrote in the other bug. I propose to remove this keyword. There is no real benefit. https://bugs.winehq.org/describekeywords.cgi 'winelib' might be also a candidate (has two). It might be useful as Bugzilla component though. I found at least a dozen bug reports from the past which would qualify for this. Regards -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 37857] New: outdated external link (to wikipedia)
by wine-bugs＠winehq.org 18 Jun '15

18 Jun '15

https://bugs.winehq.org/show_bug.cgi?id=37857 Bug ID: 37857 Summary: outdated external link (to wikipedia) Product: WineHQ.org Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: www-unknown Assignee: wine-bugs(a)winehq.org Reporter: iritrozen(a)gmail.com Distribution: --- On https://appdb.winehq.org/objectManager.php?sClass=application&iId=2586 the "Table of .NET Framework versions" linked to deleted page Wikipedia page. It seems it should be http://en.wikipedia.org/wiki/.NET_Framework_version_history instead. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 8332] Applications and games using ICMP ping request report 'no connection to internet' (Wine 32-bit/64-bit preloader requires CAP_NET_RAW to create raw sockets)
by wine-bugs＠winehq.org 17 Jun '15

17 Jun '15

https://bugs.winehq.org/show_bug.cgi?id=8332 --- Comment #25 from oiaohm <oiaohm(a)gmail.com> --- Sebastian Lackner > Using exec in Wine in general is not necessarily bad, but it would of course be > better to have only one "ping service" running instead of one application for > each request. Kinda agree kinda don't. Yes less applications but there is a limit. One ping service per application is the valid limit but then it comes when will you stop the ping service. Remember Linux, Freebsd and Solaris have per application security. I can talk way better about Linux. So a global service for running ping shared between all wine applications is directly breaking the Posix world security models. Same with the set capability on the loader to fix things. Both are using a sledge hammer for what should be carefully done. Wine project for a very long time has taken the point of view that posix security models can be disregarded. Lets say I wish to individually cgroup wrap a Wine applications into individually name-spaces at the moment. Anything done by shared services for applications become problematic. Binding to ports, pinging, sending network traffic these are all per applications things and need to operate per application .exe so items like Linux Security Modules(LSM:think Selinux, apparmor) and cgroups can in fact work. There are other issues like Linux binfmt-misc not being supported properly. If binfmt-misc worked properly the "setcap cap_net_raw+epi" could have been put in the .exe file instead of the loader so be per application. This would mean that using environmental vars to set wine settings would have to mirrored in xattrs or a file pointed to by a xattr containing instructions for the loader to follow. binfmt is where the Linux kernel picks up file set capabilities. You will not find no caps set on any native Linux loader. getcap /lib/ld-linux.so.2 and on on will all return no cap set. So the fact that getcap on /usr/bin/wine-preloader on Linux at times returns capabilities set is in fact a bug coming from poor integration. In fact there are important reasons why capabilities should not be set on loaders. A loader does not contain a predefined task. So granting capabilities to a loader is granting those capabilities to every application run by that loader so breaking the per application security model into bits. I was the one who pointed out that setcap privilage could be used instead of just running as root. But truly its only minorally better than running the applications as root. There are ways using CAP_NET_RAW to perform a privilege escape by messing with traffic. CAP_NET_BIND_SERVICE also in some cases allows privilege escapes by for example overriding local ldap server with your own yes the cannot bind to under 1024 on Linux is a security restriction to protect core services from random applications replacing them. Almost Linux every capability provides a means to take control the system if it configured in attackable ways. So using setcap is truly a mother of a hack with very bad security ramifications. So neither of the Caps users of wine are having to set are harmless. Its more luck than good management that systems are not being hacked because of wine. Poor integration with the host OS is a fairly major wine problem. Lot of windows does X so should wine without proper consideration that there might be 2 or 3 ways to achieve X and the other ways may fit the host OS security model way better. Basically from my point calling a privileged executable/service to perform a ping from a Windows application running in wine should not be a fall back position it should be the default. This is what Linux and other posix applications do when they want ping data. Behaving like a native application demands it. Not breaking native OS security demands it. If wine is taking a path that is completely different to how a host native applications are expected todo it then its a hack and need to be serous-ally considered if this is anywhere near correct because the security risk are no joke. Sorry for being blunt. Sebastian Lackner I do like your patch better question does it work with http://bahai-education.org/ocean/ that this bug was opened with and is still the only associated application.(If it does it grounds to close this bug if the patch is applied then maybe other people will learn to associate their application with bugs effecting them) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8332] Applications and games using ICMP ping request report 'no connection to internet' (Wine 32-bit/64-bit preloader requires CAP_NET_RAW to create raw sockets)
by wine-bugs＠winehq.org 17 Jun '15

17 Jun '15

https://bugs.winehq.org/show_bug.cgi?id=8332 --- Comment #24 from Sebastian Lackner <sebastian(a)fds-team.de> --- (In reply to oiaohm from comment #23) > After reading the system ping hack. Yes it contains a bad practice. > > Use of system command should be frowned on. Issue 1 with system is the > possibility of coder error. Issue 2 the command line has to be broken up > into null terminated strings any how. Something out of exec commands should > be used. > http://linux.die.net/man/3/execv > I thought I mentioned it here already, but seems like I didn't. Inspired by Brunos idea I've added a similar proof-of-concept patch to Wine Staging, which addresses exactly these problems: https://github.com/wine-compholio/wine-staging/blob/master/patches/iphlpapi… Using exec in Wine in general is not necessarily bad, but it would of course be better to have only one "ping service" running instead of one application for each request. Besides that the idea seems to work very well and is indeed sufficient for a lot of applications, especially because additional input/output parameters are translated. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8332] Applications and games using ICMP ping request report 'no connection to internet' (Wine 32-bit/64-bit preloader requires CAP_NET_RAW to create raw sockets)
by wine-bugs＠winehq.org 17 Jun '15

17 Jun '15

https://bugs.winehq.org/show_bug.cgi?id=8332 oiaohm <oiaohm(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |oiaohm(a)gmail.com --- Comment #23 from oiaohm <oiaohm(a)gmail.com> --- After reading the system ping hack. Yes it contains a bad practice. Use of system command should be frowned on. Issue 1 with system is the possibility of coder error. Issue 2 the command line has to be broken up into null terminated strings any how. Something out of exec commands should be used. http://linux.die.net/man/3/execv But this bad practice is quite minor. Setting "sudo setcap cap_net_raw+epi /usr/bin/wine-preloader" from a security point of view is extremely horrible. 1) not every application requires these privileges. 2) How much code really need to be running with these privilages As what is said under windows you don't need privilege todo these operation. Ping due to having privilege flag does not mean wine needs it on the loader. Question should wine have a /usr/bin/wine-icmp that is coded to perform all the icmp functionality of Windows. --The privilege issue is certainly outside of Wine but I think it's better to leave this open. Otherwise equivalent bugs will be opened over and over again.-- Yes privilege issue is kinda outside wine. But wine has to operate correctly in these privileged environments. Sometimes this means breaking parts off into independent applications to perform higher privilege tasks. If something should be broken off that is a wine question. Can wine icmp.dll function if all the functionality of the icmp.dll was implemented as a native independent executable that icmp.dll call by exec or equal. If so this is most likely what should happen as then "setcap cap_net_raw+epi" would only have to be granted on that limited code area. Harder issue is the fact you cannot sudo setcap cap_net_raw+epi some.exe file and have that executable only with the lifted privilege. Binding ports under 1024 being restricted exists for reason. Again this is another item that could be done by an indpendant application to the loader. https://en.wikipedia.org/wiki/Authbind is example of this. Binding ports under 1024 it would be great there was a file /etc/wine/ports listing what ports wine applications could in fact bind on. Like you don't want dhcp/dns ports taken over by a wine application because you were just restarting a server. Yes these independent applications could check if the executable the loader is using has the right applied cap values before processing the request as well as having special configuration files. So each time we need to set a cap on loader to work the question need to be asked should/can this functionality be an independent helper executable. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 24923] New: Wine doesn't allow to use/list bitmap fonts like Terminus
by wine-bugs＠winehq.org 16 Jun '15

16 Jun '15

http://bugs.winehq.org/show_bug.cgi?id=24923 Summary: Wine doesn't allow to use/list bitmap fonts like Terminus Product: Wine Version: 1.3.5 Platform: All OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: gdi32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: t.artem(a)mailcity.com Wine doesn't allow to use nor lists system wide bitmap fonts like Terminus (http://fractal.csie.org/~eric/wiki/Terminus_font) (checked out by running Notepad - Terminus is not the list of fonts which are allowed to select/use). -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

1 10