https://bugs.winehq.org/show_bug.cgi?id=49160
--- Comment #2 from Jamieson Christian jamiesonc2@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.
- Consider sourcing the values from specially designated registry keys,
populated during new WINE_PREFIX setup.
- 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.