[Bug 49160] New: Unity: SystemInfo.deviceUniqueIdentifier always the same under Wine
https://bugs.winehq.org/show_bug.cgi?id=49160 Bug ID: 49160 Summary: Unity: SystemInfo.deviceUniqueIdentifier always the same under Wine Product: Wine Version: 5.8 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wmi&wbemprox Assignee: wine-bugs(a)winehq.org Reporter: jamiesonc2(a)gmail.com Distribution: Ubuntu Unity's SystemInfo.deviceUniqueIdentifier always returns the same value under Wine, because the underlying data used to populate the property are hardcoded in Wine. Applications that depend on SystemInfo.deviceUniqueIdentifier being unique between different systems may behave unexpectedly, including identity collisions in cloud services clients. This behavior was observed in the Syrinscape Online (beta) application, which relies on SystemInfo.deviceUniqueIdentifier to link desktop apps with online accounts. Wine users are getting linked with other Wine users' online accounts because all of the Syrinscape Online clients appear to be running on the same device. https://www.syrinscape.com/online/ See this Syrinscape support forum thread where the issue was discussed: https://forum.syrinscape.com/t/who-is-stuart-kehoe/8850 Details about Unity's SystemInfo.deviceUniqueIdentifier: https://docs.unity3d.com/ScriptReference/SystemInfo-deviceUniqueIdentifier.h... The following data is retrieved from wbemprox to generate a UID: Win32_BaseBoard::SerialNumber Win32_BIOS::SerialNumber Win32_Processor::UniqueId Win32_DiskDrive::SerialNumber Win32_OperatingSystem::SerialNumber As of Wine 5.8, these values are hardcoded. From the latest wbemprox/builtin.c at the time of this writing: https://source.winehq.org/git/wine.git/blob/93758fc3ef16eed6cf1639aa6c31f6ab... Line 1103: Baseboard serial number = L"None" Line 1295: BIOS serial number = L"0" Line 2117: DiskDrive serial number = L"WINEHDISK" Line 3216: Processor unique ID = NULL Line 3417: OS serial number = L"12345-OEM-1234567-12345" As a consequence of the above, the value of Unity's SystemInfo.deviceUniqueIdentifier is always: 12a9126b14ff9b78b28d00f78e2bff20a224611b PROPOSED: If it is impractical to obtain actual serial numbers/IDs for the aforementioned components, consider populating the values in a way that facilitates more convenient user customization to workaround application issues. 1. Consider sourcing the values from specially designated registry keys, populated during new WINE_PREFIX setup. 2. Consider populating said registry keys with random values rather than fixed values. This will obviate the need for users to do any manual workarounds. (Not sure if it would break other things, but philosophically, it's not unreasonable to treat every WINE_PREFIX as though it's a whole new system build.) -- 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.
https://bugs.winehq.org/show_bug.cgi?id=49160 --- Comment #1 from Hans Leidekker <hans(a)meelstraat.net> --- (In reply to Jamieson Christian from comment #0)
Line 1103: Baseboard serial number = L"None"
This is a fallback value. On Linux these values are read from files in /sys/class/dmi/id/* but in this case /sys/class/dmi/id/board_serial is readable only by root, hence the fallback. Note that virtual machines like Qemu and VirtualBox also don't provide this value under Windows.
Line 1295: BIOS serial number = L"0"
Linux doesn't export this value at all. I also don't see it on Windows running on Qemu or VirtualBox. Windows on real hardware returns "System Serial Number" here.
Line 2117: DiskDrive serial number = L"WINEHDISK"
Looks like we can do better here. It should be possible to retrieve the disk serial number through dbus, or we could perhaps substitute the volume serial number.
Line 3216: Processor unique ID = NULL
This isn't available even on Windows on modern hardware.
Line 3417: OS serial number = L"12345-OEM-1234567-12345"
We should read this from HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProductId. While this is currently also set to a fixed value it would at least give users the opportunity to change the value. I guess we could improve on this by generating a unique value on prefix creation.
As a consequence of the above, the value of Unity's SystemInfo.deviceUniqueIdentifier is always:
12a9126b14ff9b78b28d00f78e2bff20a224611b
PROPOSED:
If it is impractical to obtain actual serial numbers/IDs for the aforementioned components, consider populating the values in a way that facilitates more convenient user customization to workaround application issues.
1. Consider sourcing the values from specially designated registry keys, populated during new WINE_PREFIX setup.
2. Consider populating said registry keys with random values rather than fixed values. This will obviate the need for users to do any manual workarounds. (Not sure if it would break other things, but philosophically, it's not unreasonable to treat every WINE_PREFIX as though it's a whole new system build.)
I don't think we want to introduce registry values that don't exist on Windows for this purpose. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=49160 --- Comment #2 from Jamieson Christian <jamiesonc2(a)gmail.com> --- (In reply to Hans Leidekker from comment #1)
Line 1103: Baseboard serial number = L"None"
This is a fallback value. On Linux these values are read from files in /sys/class/dmi/id/* but in this case /sys/class/dmi/id/board_serial is readable only by root, hence the fallback. Note that virtual machines like Qemu and VirtualBox also don't provide this value under Windows.
/sys/class/dmi/id/board_serial returns "Default string" on Ubuntu 20.04, so not really useful even if it could be read without escalated privileges. Under dbus, there's /var/lib/dbus/machine-id, which on some distros is simply a symlink to /etc/machine-id. Neither requires root access. On Ubuntu 20.04, /var/lib/dbus/machine-id is a symlink, and /etc/machine-id remains consistent between boots. (On a permanent OS install; stateless boot is a different matter.)
Line 1295: BIOS serial number = L"0"
Linux doesn't export this value at all. I also don't see it on Windows running on Qemu or VirtualBox. Windows on real hardware returns "System Serial Number" here.
Good to know.
Line 2117: DiskDrive serial number = L"WINEHDISK"
Looks like we can do better here. It should be possible to retrieve the disk serial number through dbus, or we could perhaps substitute the volume serial number.
This CLI technique hints at a possible approach: udevadm info --query=all --name=sda | grep SERIAL= The above seems to produce a distillation of /sys/block/sda/device/wwid Not sure if always using sda would be sufficient, or if something more robust is needed. I agree that volume serial number (which is configurable in winecfg) would also be adequate, if a broadly compatible approach to retrieving device serial number is not available.
Line 3216: Processor unique ID = NULL
This isn't available even on Windows on modern hardware.
Good to know.
Line 3417: OS serial number = L"12345-OEM-1234567-12345"
We should read this from HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProductId. While this is currently also set to a fixed value it would at least give users the opportunity to change the value. I guess we could improve on this by generating a unique value on prefix creation.
This sounds like a good approach. Generating a unique value is ideal.
1. Consider sourcing the values from specially designated registry keys, populated during new WINE_PREFIX setup.
2. Consider populating said registry keys with random values rather than fixed values. This will obviate the need for users to do any manual workarounds. (Not sure if it would break other things, but philosophically, it's not unreasonable to treat every WINE_PREFIX as though it's a whole new system build.)
I don't think we want to introduce registry values that don't exist on Windows for this purpose.
HKLM\Software\Wine doesn't normally exist in Windows, but does under Wine. This would be my first candidate for setting up new registry entries that specifically govern Wine's behavior. But if your argument is that you particularly don't want to leverage registry entries *for this purpose*, that's certainly fair. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=49160 --- Comment #3 from Hans Leidekker <hans(a)meelstraat.net> --- (In reply to Jamieson Christian from comment #2)
Under dbus, there's /var/lib/dbus/machine-id, which on some distros is simply a symlink to /etc/machine-id. Neither requires root access. On Ubuntu 20.04, /var/lib/dbus/machine-id is a symlink, and /etc/machine-id remains consistent between boots. (On a permanent OS install; stateless boot is a different matter.)
Right, we already use this ID for Win32_ComputerSystemProduct.UUID.
Line 2117: DiskDrive serial number = L"WINEHDISK"
Looks like we can do better here. It should be possible to retrieve the disk serial number through dbus, or we could perhaps substitute the volume serial number.
This CLI technique hints at a possible approach:
udevadm info --query=all --name=sda | grep SERIAL=
The above seems to produce a distillation of /sys/block/sda/device/wwid
I was thinking of querying UDisks2.Drive.Id through dbus, which should return the same thing.
Line 3417: OS serial number = L"12345-OEM-1234567-12345"
We should read this from HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProductId. While this is currently also set to a fixed value it would at least give users the opportunity to change the value. I guess we could improve on this by generating a unique value on prefix creation.
This sounds like a good approach. Generating a unique value is ideal.
Some googling leads me to believe that this isn't really a unique ID. It's still a good idea to retrieve this from the registry. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=49160 --- Comment #4 from Jamieson Christian <jamiesonc2(a)gmail.com> --- (In reply to Hans Leidekker from comment #3)
Under dbus, there's /var/lib/dbus/machine-id, which on some distros is simply a symlink to /etc/machine-id. Neither requires root access. On Ubuntu 20.04, /var/lib/dbus/machine-id is a symlink, and /etc/machine-id remains consistent between boots. (On a permanent OS install; stateless boot is a different matter.)
Right, we already use this ID for Win32_ComputerSystemProduct.UUID.
Ah, that would be redundant, then. Maybe we don't bother trying to populate this one. See my concluding notes at bottom of post.
This CLI technique hints at a possible approach:
udevadm info --query=all --name=sda | grep SERIAL=
The above seems to produce a distillation of /sys/block/sda/device/wwid
I was thinking of querying UDisks2.Drive.Id through dbus, which should return the same thing.
More or less the same, from what I see in d-feet. It's a concatenation of elements, as shown below: by-id-{INTERFACE}-{MFG}_{MODEL}_{SERIAL} (Where {INTERFACE} is e.g. "ata") Perhaps easy enough to extract just the serial # portion, but the whole thing could probably just be used as is, you think?
We should read this from HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProductId. While this is currently also set to a fixed value it would at least give users the opportunity to change the value. I guess we could improve on this by generating a unique value on prefix creation.
This sounds like a good approach. Generating a unique value is ideal.
Some googling leads me to believe that this isn't really a unique ID. It's still a good idea to retrieve this from the registry.
What I've read suggests that its *persistence* is not guaranteed on Windows systems; Windows 10 updates have been known to result in a new product ID. But it probably doesn't change how we choose to implement it. The goal (tell me if you think differently) should be "reasonably unique and reasonably persistent". CONCLUSION: From our discussion, it looks like the population of some of these values has no clear solution path. That's probably fine. As long as we are able to obtain reasonably diverse values for 2 or 3 of these, it should satisfy the need for a "reasonably unique" value in Unity's SystemInfo.deviceUniqueIdentifier. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=49160 --- Comment #5 from Hans Leidekker <hans(a)meelstraat.net> --- With commit f516a23041b3871625764611321250f977fe750a we retrieve the OS serial number from the registry. It's the ProductId value under HKLM\Software\Microsoft\Windows NT\CurrentVersion. With commit 84857d27067afaa1ae5774afe27086332263bfb5 we get the disk drive serial number from dbus. Note that this currently only works for drive c: in the default configuration. Can you retest? -- 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.
https://bugs.winehq.org/show_bug.cgi?id=49160 --- Comment #6 from Jamieson Christian <jamiesonc2(a)gmail.com> --- (In reply to Hans Leidekker from comment #5)
With commit f516a23041b3871625764611321250f977fe750a we retrieve the OS serial number from the registry. It's the ProductId value under HKLM\Software\Microsoft\Windows NT\CurrentVersion.
With commit 84857d27067afaa1ae5774afe27086332263bfb5 we get the disk drive serial number from dbus. Note that this currently only works for drive c: in the default configuration.
Can you retest?
I rebuilt from latest git (wine-5.9-67-g8257fe88fb) and ran the following tests: #1: Fresh prefix, same physical drive as Wine. CONFIRMED the value of Unity SystemInfo.deviceUniqueIdentifier is different from wine-5.8. #2: Another fresh prefix, same physical drive as Wine. Observed that the value of Unity SystemInfo.deviceUniqueIdentifier is the same as Test #1. #3: Another fresh prefix, same physical drive as Wine. Modified HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProductId to something other than the placeholder value. CONFIRMED the value of Unity SystemInfo.deviceUniqueIdentifier is different from Tests #1 and #2, as well as different from wine-5.8. #4: Another fresh prefix, DIFFERENT physical drive from Wine. Observed that the value of Unity SystemInfo.deviceUniqueIdentifier is the same as Tests #1 and #2. (Ergo, the physical device of the prefix does not influence the disk serial number used.) #5: Moved the Wine build to the DIFFERENT physical drive used in #4, ran it with another fresh prefix on that same drive. Observed that the value of Unity SystemInfo.deviceUniqueIdentifier is the same as Tests #1 and #2. (Ergo, the physical device that Wine runs from does not influence the disk serial number used.) CONCLUSIONS: The use of the disk drive serial # causes Unity SystemInfo.deviceUniqueIdentifier to vary, presumably to a sufficient degree to reasonably ensure different values between users. The device from which the serial # is drawn is independent of where Wine, or the prefix, are located (e.g. always /dev/sda or something). This is, I presume, what you meant by "always drive c: in the default configuration". The use of HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProductId does not cause Unity SystemInfo.deviceUniqueIdentifier to vary (insofar as the value is still the same for every new prefix), but does give users a viable workaround if needed. A more random generation of HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProductId may be considered a "nice-to-have" feature and not required, given the diversity introduced by the disk drive serial #. I believe the changes adequately satisfy the requirements. Thank you! -- 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.
https://bugs.winehq.org/show_bug.cgi?id=49160 Hans Leidekker <hans(a)meelstraat.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Fixed by SHA1| |84857d27067afaa1ae5774afe27 | |086332263bfb5 Status|UNCONFIRMED |RESOLVED --- Comment #7 from Hans Leidekker <hans(a)meelstraat.net> --- (In reply to Jamieson Christian from comment #6)
I believe the changes adequately satisfy the requirements. Thank you!
Thanks for testing! Marking fixed with 84857d27067afaa1ae5774afe27086332263bfb5. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=49160 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #8 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 5.10. -- 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