We have always repeated that Wine is not a sandbox. It cannot inherently be a sandbox, because we cannot prevent Windows applications from accessing host resources or performing syscalls, and there is no reason for us to include a sandbox instead of simply requiring that any concerned users run Wine inside a separate sandbox.
Why is this case any different?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4108#note_49045
On Tue Oct 17 13:58:32 2023 +0000, Hans Leidekker wrote:
> Like I said, Wine is not a regular application, it's just the middle
> layer between the Unix OS and Windows applications. Your proposal
> doesn't achieve systemd's goal because you can run multiple applications
> on Wine which would still get the same ID (even if run in different prefixes).
It does by isolating Wine from the other unix applications and the other unix applications from Wine.
Then, Wine has to do its own policy about 'personal data'. This is a chain of responsability.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4108#note_49043
--
v2: dmime: Use latency time to decide when to process messages.
dmime: Update performance latency time with port latency.
dmime: Use port latency time for messages with -1 time.
dmusic: Forward IDirectMusicPort_Activate to synth and sink.
dmsynth: Do nothing in IDirectMusicSynth_SetMasterClock.
dmusic: Set synth sink master clock when creating port.
dmime: Rewrite message thread with a condition variable.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4110