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

[WineHQ Bugzilla]

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: [e-mail]
          Reporter: [e-mail]
      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.)

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

[WineHQ Bugzilla]

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

--- Comment #1 from Hans Leidekker  ---
(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.
> - 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.

[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  ---
(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.

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

[WineHQ Bugzilla]

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

--- Comment #3 from Hans Leidekker  ---
(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.

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

[WineHQ Bugzilla]

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

--- Comment #4 from Jamieson Christian  ---
(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.

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

[WineHQ Bugzilla]

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

--- Comment #5 from Hans Leidekker  ---
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?

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

[WineHQ Bugzilla]

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

--- Comment #6 from Jamieson Christian  ---
(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!

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

[WineHQ Bugzilla]

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

Hans Leidekker  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
      Fixed by SHA1|                            |84857d27067afaa1ae5774afe27
                   |                            |086332263bfb5
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #7 from Hans Leidekker  ---
(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.

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

[WineHQ Bugzilla]

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

Alexandre Julliard  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #8 from Alexandre Julliard  ---
Closing bugs fixed in 5.10.