[Bug 49160] Unity: SystemInfo.deviceUniqueIdentifier always the same under Wine

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=49160

--- Comment #2 from Jamieson Christian <jamiesonc2 at 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.