October 2023 - wine-gitlab

Re: [PATCH v2 0/1] MR4156: ntdll/tests: Use win_skip() for missing APIs in test_query_process_debug_port_custom_dacl. - approved
by Alexandre Julliard (＠julliard) 24 Oct '23

24 Oct '23

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4156

1 0

Re: [PATCH v8 0/2] MR4054: mshtml: HTMLWindow behavior improvements. - approved
by Alexandre Julliard (＠julliard) 24 Oct '23

24 Oct '23

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4054

1 0

[PATCH 0/1] MR4172: kernelbase: Trace global memory counters in decimal.
by Hans Leidekker (＠hans) 24 Oct '23

24 Oct '23

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/4172

2 1

[PATCH v5 0/1] MR3397: Draft: ucrtbase: Do not modify rewind's stack arguments on i386.
by Victor Hermann Chiletto (＠vitorhnn) 24 Oct '23

24 Oct '23

[A mod for Fallout: New Vegas relies on rewind not modifying the first argument passed to it.](https://github.com/jazzisparis/UIO-User-Interface-Organizer/blob/426d9… Since it only links to api-ms-win-crt-stdio I've kept the thunk usage to just ucrtbase. -- v5: msvcrt, ucrtbase: Introduce rewind_preserve_stack. https://gitlab.winehq.org/wine/wine/-/merge_requests/3397

3 3

[PATCH v4 0/1] MR4165: gdiplus: Fix transformation in GdipIsOutlineVisiblePathPoint
by Bartosz Kosiorek (＠gang65) 24 Oct '23

24 Oct '23

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55717 -- v4: gdiplus: Fix transformation in GdipIsOutlineVisiblePathPoint https://gitlab.winehq.org/wine/wine/-/merge_requests/4165

4 3

[PATCH 0/1] MR4170: mf: Shutdown media sinks before releasing them.
by Yuxuan Shui (＠yshui) 24 Oct '23

24 Oct '23

This probably suppresses !3067 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4170

3 2

[PATCH 0/2] MR4169: include: Convert d3d10shader.h and d3d10effect.h to IDLs.
by Zebediah Figura (＠zfigura) 24 Oct '23

24 Oct '23

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/4169

2 2

Re: [PATCH v2 0/2] MR4108: Improve DMI tables under Linux.
by Jinoh Kang (＠iamahuman) 24 Oct '23

24 Oct '23

Do we, even as a "Unix app," really have to strictly follow the machine-id(5) guidelines? > This ID uniquely identifies the host. It should be considered "confidential", and must not be exposed in untrusted environments, in particular on the network. It is unclear to which degree the identifier should be kept "confidential." How much confidentiality does it merit? 1. Is it used to derive some authentication credentials, or a private key? If so, it should *not* be world-readable in the first place. This contradicts with the current state of affairs (/etc/machine-id is r--r--r--). All the hashing stuff should be done by some daemon, if it's really needed. 2. Is it merely used to identify a particular *physical* system, and the OS installation is not intended to be movable? If so, it is not any more confidential than, say, a hardware UUID. 3. Is it merely used to identify a particular *virtual* system, where the OS installation may roam? If so, it may have different privacy and confidentiality requirements than hardware UUID. Still, there are a lot of other ways to fingerprint the OS installation identity (e.g., the dev/ino or mtime of certain system directories), and it is not clear that /etc/machine-id passthrough is at the frontier of the privacy threat posed by Wine. > If a stable unique identifier that is tied to the machine is needed for some application, the machine ID or any part of it must not be used directly. Instead the machine ID should be hashed with a cryptographic, keyed hash function, using a fixed, application-specific key. That way the ID will be properly unique, and derived in a constant way from the machine ID but there will be no way to retrieve the original machine ID from the application-specific one. This is a reasonable take, regardless of confidentiality. However, Wine has long ago already decided to use /etc/machine-id as-is, for better or worse. We wouldn't want to break backward compatibility unless for a very good reason. --- The supposed main motivation behind the confidentiality of /etc/machine-id seems to be that it is not easily renewable by the user, since it's intended to be persistent. However, note that machine-id(5) says it's still okay to *derive* a persistent identifier from it. The reasonable conclusion here is that the user should be allowed to renew application-specific persistent identifiers due to security or privacy concerns, without changing the global /etc/machine-id and breaking things that literally require its persistent (e.g., cluster management, journal logs). However, if the user had to care about privacy or security (e.g., server deployments), they should be running Wine inside a VM or container anyway. Also, desktop/client (non-server) users could probably also change /etc/machine-id without much side effects. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4108#note_49628

1 0

Re: [PATCH v2 0/2] MR4108: Improve DMI tables under Linux.
by Jinoh Kang (＠iamahuman) 24 Oct '23

24 Oct '23

On Sat Oct 21 14:26:38 2023 +0000, Paul Gofman wrote: > Maintaining any way of backward compat on this ID doesn't look feasible. > E. g., the current way with a bug reports bios hashtag in serial field > on my desktop due to missing fields not being handled. This ID is > already non-unique, and maintaining these algorithms backwards would > take unreasonable amount of effort (with arguably no gains). Probably > more important, /etc/machine-id can be changed anytime by user or > system resintall, it is not true hardware id. If anything firmly relies > on HW id to persist forever, it is broken already. > Regarding the original discussion, I also don't really understand why we > should necessarily obfuscate /etc/machine-id for uuid / serial > reporting. App has access to the file anyway, and Wine neither sends the > ID anywhere nor tracks the user, it is between the app and the user. On > Windows fwiw it will get real motherboard serial and other information > like that. I agree that it's not strictly necessary to mask the machine ID. I'm still leaving comments below just in case we ever decide to change the system UUID. --- > Maintaining any way of backward compat on this ID doesn't look feasible. E. g., the current way with a bug reports bios hashtag in serial field on my desktop due to missing fields not being handled. It appears to me that backward compat here *is* feasible. We can simply leave all of such broken fields as-is for old prefixes. > This ID is already non-unique, It is non-unique, yes, but that does not contradict what I said. I said that an ID is permanent. The app can assume that, if the ID ever changes, it means that the underlying hardware has been changed as well. (Of course the converse is not always true due to non-uniqueness, but that doesn't matter here.) > and maintaining these algorithms backwards would take unreasonable amount of effort The cost can be broken down into two parts: 1. The cost of maintaining the old code is trivial, since it is (mostly) an identity function. (tests may have to tweak the registry to force the old path to be triggered, but wine tests are seldom meant to be refactored anyway.) 2. The cost of maintaining the migration algorithm may be a little higher, but I don't think a couple of simple registry checks to set a global variable is "unreasonable." > Probably more important, /etc/machine-id can be changed anytime by user or system resintall, it is not true hardware id. If anything firmly relies on HW id to persist forever, it is broken already. Wine already handles a lot of broken apps, or at least tries to hold off their problems from surfacing as long as possible. Besides, if the user is never going to do anything that changes /etc/machine-id in the first place, then no such problem exists, at least for that user. This MR introduces the problem. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4108#note_49627

1 0

[PATCH v3 0/2] MR4140: uxtheme/tests: Add some tests for OpenThemeData() with various app/class names.
by Dmitry Timoshkov (＠dmitry) 24 Oct '23

24 Oct '23

Themed Delphi applications use "explorer::listview" and "explorer::treeview": https://gitlab.com/freepascal.org/lazarus/lazarus/-/blob/main/lcl/interface… -- v3: uxtheme: Parse app/class name in OpenThemeData(). uxtheme/tests: Add some tests for OpenThemeData() with various app/class names. https://gitlab.winehq.org/wine/wine/-/merge_requests/4140

3 8

2025

2024

2023

2022

wine-gitlab October 2023