[Bug 59079] New: Debian Trixie: wine-devel package lacks ntsync support with linux-image-amd64/trixie-backports
http://bugs.winehq.org/show_bug.cgi?id=59079 Bug ID: 59079 Summary: Debian Trixie: wine-devel package lacks ntsync support with linux-image-amd64/trixie-backports Product: Packaging Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: wine-packages Assignee: wine-bugs(a)list.winehq.org Reporter: actium(a)gmx.net CC: dimesio(a)earthlink.net Distribution: --- The WineHQ packaged wine-devel 10.20 for Debian 13 "Trixie" lacks ntsync support, because Trixie's LTS kernel 6.12 predates the ntsync merge and thus ntsync.h is missing. However, trixie-backports currently ships Linux 6.17 with ntsync [1]. Alternatively, the ntsync kernel module is trivial to build with DKMS [2]. While retrofitting kernel-side ntsync is easy on Trixie, adding it to wine itself requires building from source. Wine users would benefit from ntsync-ready WineHQ binary packages, as they would facilitate ntsync access. This would only require including ntsync.h when building the WineHQ packages for Trixie. [1] https://packages.debian.org/trixie-backports/linux-image-amd64 [2] https://github.com/ActiumDev/debian-ntsync-dkms/ -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59079 actium(a)gmx.net changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |actium(a)gmx.net Distribution|--- |Debian -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59079 Chiitoo <chiitoo(a)gentoo.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |chiitoo(a)gentoo.org -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59079 --- Comment #1 from actium(a)gmx.net --- This is related to, but not a duplicate of https://bugs.winehq.org/show_bug.cgi?id=58751 (thanks to Chiitoo for pointing this out). I've read the discussion and would like to add the following argument: AFAICT, adding ntsync.h to the Trixie packages will not break anything for non-backport Trixie installs. Wine with ntsync support will silently default to the wineserver-based sync mechanism if /dev/ntsync is missing. Thus, it would help out backport users without affecting non-backport installs. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59079 Rosanne DiMesio <dimesio(a)earthlink.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #2 from Rosanne DiMesio <dimesio(a)earthlink.net> --- (In reply to actium from comment #1)
This is related to, but not a duplicate of https://bugs.winehq.org/show_bug.cgi?id=58751 (thanks to Chiitoo for pointing this out). I've read the discussion and would like to add the following argument:
AFAICT, adding ntsync.h to the Trixie packages will not break anything for non-backport Trixie installs. Wine with ntsync support will silently default to the wineserver-based sync mechanism if /dev/ntsync is missing. Thus, it would help out backport users without affecting non-backport installs.
ntsync.h is already included in our trixie builds, but it is the original version, which is not new enough. Using the newer version would require building against the backports repository on the OBS, and that would cause our trixie packages to depend on newer versions of every dependency that had a newer version in backports. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59079 --- Comment #3 from actium(a)gmx.net --- I agree that depending on backports is a hard no. However, I was thinking of cherry picking *only* the newer version of ntsync.h into the package source files to substitute Trixie's "old" version. While somewhat unclean, it would not pull in any backports dependencies. Dunno whether that's even possible with OBS. I have no packaging experience. I understand this may be a too unconventional suggestion. Doing this merely in an effort to solve this upstream before I pursue a workaround. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59079 Rosanne DiMesio <dimesio(a)earthlink.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #4 from Rosanne DiMesio <dimesio(a)earthlink.net> --- Users who really want ntsync support can always upgrade to forky. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59079 --- Comment #5 from actium(a)gmx.net --- Not an option for dedicated server use, where OS security support is a hard requirement, which Forky currently lacks. If anyone is looking for a solution, see this Debian wiki page that suggests a 3rd party OBS build (buyers beware): https://wiki.debian.org/Wine/NtsyncHowto (Thanks to tomman on IRC for pointing this out!) -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59079 Zeb Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12(a)gmail.com --- Comment #6 from Zeb Figura <z.figura12(a)gmail.com> --- (In reply to actium from comment #5)
Not an option for dedicated server use, where OS security support is a hard requirement, which Forky currently lacks.
If anyone is looking for a solution, see this Debian wiki page that suggests a 3rd party OBS build (buyers beware): https://wiki.debian.org/Wine/NtsyncHowto (Thanks to tomman on IRC for pointing this out!)
Isn't "dedicated server use, where OS security support is a hard requirement" kind of inherently at odds with a very new feature like ntsync? -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59079 --- Comment #7 from actium(a)gmx.net --- (In reply to Zeb Figura from comment #6)
Isn't "dedicated server use, where OS security support is a hard requirement" kind of inherently at odds with a very new feature like ntsync?
I do (naively) presume that ntsync doesn't increase the overall system attack surface, particularly facing the internet. Regardless, it is an upstream kernel feature and thus covered by the Linux kernel security team and distribution security teams. In combination with unattended-upgrades and automatic reboots, that should deliver decent, low-overhead security on Debian Stable. Forky/Testing does not enjoy the same level of security incident response. This relates to the whole system including all internet-facing services and not just ntsync and Wine. With regards to wine, I'm more worried about the attack surface of the windows binaries. But that is best left to sandboxing and prayer ... -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59079 --- Comment #8 from Zeb Figura <z.figura12(a)gmail.com> --- (In reply to actium from comment #7)
(In reply to Zeb Figura from comment #6)
Isn't "dedicated server use, where OS security support is a hard requirement" kind of inherently at odds with a very new feature like ntsync?
I do (naively) presume that ntsync doesn't increase the overall system attack surface, particularly facing the internet.
It does increase the attack surface, actually. Not to the internet specifically, but it adds a new world-accessible API window into the kernel. That's not the only criterion one should use to decide, of course. One can decide what they're willing to accept, and that won't always align perfectly with one side or the other of a stable/unstable release cycle. But I also am personally kind of confused at wanting to run Debian Stable but also backport a new and risky feature like ntsync [and new Wine, for that matter.] As the author of ntsync, if I was that concerned about security I definitely wouldn't do that. If you want security then don't pick ntsync, or bleeding-edge Wine. If you aren't that concerned about security/stability then just run Testing. If you want a mix of the two, well, that's gonna have to be on the user to manage, at some point. It's not that hard anyway, given that linked page on the Debian wiki. (I'm amused at that meme, though I find it funny that they chose to portray me as Victoria. I mean, Elizabeth is right there. Two of 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.
participants (1)
-
WineHQ Bugzilla