Re: [PATCH v2 0/2] MR4108: Improve DMI tables under Linux.
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
participants (1)
-
Jinoh Kang (＠iamahuman)