[issue43284] sys.getwindowsversion().platform_version is incorrect

[Steve Dower]

Steve Dower  added the comment:


New changeset 52e9031fbd23c10668badc2a72ee5c203d6902c7 by Miss Islington (bot) 
in branch '3.9':
bpo-43284: Update platform.win32_ver to use _syscmd_ver instead of 
sys.getwindowsversion() (GH-25500)
https://github.com/python/cpython/commit/52e9031fbd23c10668badc2a72ee5c203d6902c7


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43284] sys.getwindowsversion().platform_version is incorrect

[Shreyan Avigyan]

Shreyan Avigyan  added the comment:

@steve.dower Would you mind merging the backport of the PR to the 3.9 branch 
manually? Apparently there seems to a test failure. I'm not sure why. But it 
reports that test has been failing recently.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43284] sys.getwindowsversion().platform_version is incorrect

[miss-islington]

miss-islington  added the comment:


New changeset ef63328b46fe7402794cde51008a47e79f37b153 by Miss Islington (bot) 
in branch '3.8':
bpo-43284: Update platform.win32_ver to use _syscmd_ver instead of 
sys.getwindowsversion() (GH-25500)
https://github.com/python/cpython/commit/ef63328b46fe7402794cde51008a47e79f37b153


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43284] sys.getwindowsversion().platform_version is incorrect

[Steve Dower]

Steve Dower  added the comment:

Thanks for doing the patch!

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43284] sys.getwindowsversion().platform_version is incorrect

[miss-islington]

Change by miss-islington :


--
pull_requests: +24244
pull_request: https://github.com/python/cpython/pull/25524

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43284] sys.getwindowsversion().platform_version is incorrect

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 9.0 -> 10.0
pull_requests: +24243
pull_request: https://github.com/python/cpython/pull/25523

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43284] sys.getwindowsversion().platform_version is incorrect

[Steve Dower]

Steve Dower  added the comment:


New changeset 2a3f4899c63806439e5bcea0c30f7e6a6295a763 by Shreyan Avigyan in 
branch 'master':
bpo-43284: Update platform.win32_ver to use _syscmd_ver instead of 
sys.getwindowsversion() (GH-25500)
https://github.com/python/cpython/commit/2a3f4899c63806439e5bcea0c30f7e6a6295a763


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43284] sys.getwindowsversion().platform_version is incorrect

[Shreyan Avigyan]

Shreyan Avigyan  added the comment:

PR opened against master branch.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43284] sys.getwindowsversion().platform_version is incorrect

[Shreyan Avigyan]

Change by Shreyan Avigyan :


--
keywords: +patch
pull_requests: +24220
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/25500

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43284] sys.getwindowsversion().platform_version is incorrect

[Steve Dower]

Steve Dower  added the comment:

Opening a PR against the master branch would be ideal. (Make sure you 
forked from that branch too, or you may see lots of irrelevant changes, 
which will make it impossible to review.)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43284] sys.getwindowsversion().platform_version is incorrect

[Shreyan Avigyan]

Shreyan Avigyan  added the comment:

I have a patch for this issue. Should I attach it or should I directly open a 
PR?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43284] sys.getwindowsversion().platform_version is incorrect

[Shreyan Avigyan]

Shreyan Avigyan  added the comment:

For Windows 10.0.17134 (1803) or above why don't we use the format 
"maj.min.build.ubr" in platform._norm_version (the function that post-processes 
the version string and then returns the version string in the format 
"maj.min.build")?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43284] sys.getwindowsversion().platform_version is incorrect

[Shreyan Avigyan]

Shreyan Avigyan  added the comment:

I would like to help to write the fix for this issue.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43284] sys.getwindowsversion().platform_version is incorrect

[Steve Dower]

Steve Dower  added the comment:

> In that case, would you want to deprecate 
> sys.getwindowsversion().platform_version?

Yeah, but I'm not so concerned about raising a warning on use. Just in 
the docs will be fine. We should also add a mention that it is 
extracting the value from efficient but unstable system locations that 
may change in future releases. (That is not my suggested wording btw, 
just the gist of what we should mention.)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43284] sys.getwindowsversion().platform_version is incorrect

[Eryk Sun]

Eryk Sun  added the comment:

> If we're going to launch cmd.exe, I'd prefer to only do that in the 
> platform module and not the sys function. Nothing in sys should 
> start a subprocess (if we can at all avoid it).

In that case, would you want to deprecate 
sys.getwindowsversion().platform_version?

platform._syscmd_ver() is already implemented to parse the output of CMD's VER 
command. The result has to be post-processed because the regex isn't as exact 
as it could be. It supports versions back to Windows 2000, which returned 
"Microsoft Windows 2000 [Version maj.min.build]". Starting with Windows Vista 
up to early versions of Windows 10, the format is "Microsoft Windows [Version 
maj.min.build]". In more recent versions of Windows 10, it includes the update 
build revision number -- "Microsoft Windows [Version maj.min.build.ubr]".

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43284] sys.getwindowsversion().platform_version is incorrect

[Steve Dower]

Steve Dower  added the comment:

Python is a volunteer built project, so someone will need to volunteer 
to write the fix. Until there is a volunteer, there is no plan. (One of 
the core devs might volunteer, but there's no guarantee of that.)

If we're going to launch cmd.exe, I'd prefer to only do that in the 
platform module and not the sys function. Nothing in sys should start a 
subprocess (if we can at all avoid it).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43284] sys.getwindowsversion().platform_version is incorrect

[Shreyan Avigyan]

Shreyan Avigyan  added the comment:

Ok. So are you planning to implement this fix?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43284] sys.getwindowsversion().platform_version is incorrect

[Eryk Sun]

Eryk Sun  added the comment:

> But isn't calling CMD's VER command risky? A process can overwrite its 
> PEB OSMajorVersion, OSMinorVersion, and OSBuildNumber. 

As long as VER is executed without quotes, the shell will not search for an 
external command. CMD is not going to intentionally overwrite the OS version 
and build number in the PEB, so that would be due to some kind of weird, 
unlikely bug. (CMD's code base is stable. It hasn't seen a new feature since 
MKLINK was added 15 years ago.) If malware messes with this, for some strange 
reason, it's not Python's problem. For example, I'll attach a debugger and do 
just that:

0:000> ?? @$peb->OSMajorVersion = 11
unsigned long 0xb
0:000> ?? @$peb->OSMinorVersion = 0
unsigned long 0
0:000> ?? @$peb->OSBuildNumber = 0x8000
unsigned short 0x8000

C:\>ver
Microsoft Windows [Version 11.0.32768.0]

Hi from the future. :)

> If the cmd has been set to compatibility mode 

"%SystemRoot%\System32\cmd.exe" is exempt from compatibility mode (e.g. the 
"__COMPAT_LAYER" environment variable).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43284] sys.getwindowsversion().platform_version is incorrect

[Shreyan Avigyan]

Shreyan Avigyan  added the comment:

But isn't calling CMD's VER command risky? A process can overwrite its PEB 
OSMajorVersion, OSMinorVersion, and OSBuildNumber. If the cmd has been set to 
compatibility mode somehow then the same problem will occur since it will then 
overwrite its PEB OSMajorVersion, OSMinorVersion, and OSBuildNumber. Using a 
DLL or registry key bypasses this risk.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43284] sys.getwindowsversion().platform_version is incorrect

[Eryk Sun]

Eryk Sun  added the comment:

> But kernel32.dll (since it's of a different version) isn't 
> accurate at all right? 

To clarify, CMD's VER command calls GetVersion(). It has nothing to do with the 
file version of any system DLL. Because CMD is a system component, the 
GetVersion() call returns the true OS version number and build number, directly 
from its PEB OSMajorVersion, OSMinorVersion, and OSBuildNumber values. When the 
PEB for a process is created, these values are copied from the kernel's 
NtMajorVersion, NtMinorVersion, and NtBuildNumber values. 

While the latter may be and most likely are the same as the 
"CurrentMajorVersionNumber", "CurrentMinorVersionNumber", and 
"CurrentBuildNumber" values in the registry, the kernel values are not based on 
the registry. They're compiled into the kernel image when it's built. At boot, 
the configuration manager sets the registry values to the current values, so 
that's all fine -- unless someone with admin or system access changes the 
values (but if a hacker has admin or system access; they own the OS, so such a 
prank would be the least of one's problems). 

My concern, if you read my previous comments, is that an engineer at Microsoft 
rejected someone's attempt to recommend using "CurrentBuildNumber" as a 
replacement for the old advice to use the file version of "kernel32.dll". 
That's enough to make me worry about what's planned for a future release. So 
I'd rather just parse the output from CMD.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43284] sys.getwindowsversion().platform_version is incorrect

[Shreyan Avigyan]

Shreyan Avigyan  added the comment:

But kernel32.dll (since it's of a different version) isn't accurate at all 
right? To find the accurate result we have to use the CurrentBuildNumber 
registry key. I think this key will not be removed so easily by Microsoft. This 
key have been in existence from NT 3.5 till today. I think it's the safest and 
reliable way to get the version number other than WMI query. I know the key can 
be removed in the future but if it that happens what about reimplementing the 
kernel32.dll then. We need a way to get the accurate version right?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43284] sys.getwindowsversion().platform_version is incorrect

[Eryk Sun]

Eryk Sun  added the comment:

The "CurrentBuild" and "CurrentVersion" values go back to the first release of 
Windows NT 3.1 in 1993 (build 511, which was quickly replaced by build 528). In 
NT 3.1 (build 528), the "CurrentBuild" value was "1.528.1 () (July 1993)". In 
NT 3.5, this awkward string was replaced by the "CurrentBuildNumber" value, and 
up to NT 5.2 the old "CurrentBuild" value was set to the string "1.511.1 () 
(Obsolete data - do not use)". It was brought back as the build number starting 
with Windows Vista (NT 6.0). However, in Windows 10 the related 
"CurrentVersion" value is now obsolete and frozen at "6.3". The true value is 
now split into "CurrentMajorVersionNumber" and "CurrentMinorVersionNumber".

These registry values aren't a reliable source source of truth. The reliable 
values are the kernel global variables NtMajorVersion, NtMinorVersion, and 
NtBuildNumber, which are compiled into the kernel image. They get copied into 
the process environment block (PEB) of each process as OSMajorVersion, 
OSMinorVersion, and OSBuildNumber. If the application manifest supports the 
current OS version, then GetVersion() and GetVersionExW() will simply return 
these values from the PEB. That's why it was suggested to spawn an instance of 
the system CMD shell and parse the output of its VER command.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43284] sys.getwindowsversion().platform_version is incorrect

[Shreyan Avigyan]

Shreyan Avigyan  added the comment:

I researched a little more and found that before Vista the winver command used 
the CurrentBuildNumber key instead of CurrentBuild key. In fact before Vista 
CurrentBuild was marked as obsolete by Microsoft. But that changed in Vista, 
when Microsoft started using CurrentBuild key instead of the CurrentBuildNumber 
key. Though still today CurrentBuildNumber key actually gives the exact version 
(for backward compatibilities maybe?). Therefore why not use 
CurrentBuildNumber? At least CurrentBuildNumber gives the right info. The only 
problem is that we have to only use that key to determine the windows version 
(Eg - Windows 10, 8.1, 8, 7, Vista, etc.) and to do that we have to use a very 
long switch or if-else statement. 

https://en.wikipedia.org/wiki/Comparison_of_Microsoft_Windows_versions#Windows_NT
 has the whole list with the column "RTM build" as the CurrentBuildNumber value.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43284] sys.getwindowsversion().platform_version is incorrect

[Shreyan Avigyan]

Shreyan Avigyan  added the comment:

@eryksun described "Apparently the developers do not want to guarantee that the 
version information on any particular system DLL can be used to get the system 
version. Apparently they also do not want to officially sanction using the 
"CurrentMajorVersionNumber", "CurrentMinorVersionNumber", and  
"CurrentBuildNumber" values in the registry."

If that's the case why not get the version from CurrentBuild registry key 
present in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion. 
This key at least goes back to Windows 7 and this is the key that's currently 
being used by winver command. And I don't think anyone at all uses windows 
version older than Windows 7. And chances are that the key maybe present even 
before Windows 7. At least the CurrentBuild is accurate.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43284] sys.getwindowsversion().platform_version is incorrect

[Eryk Sun]

Eryk Sun  added the comment:

> shouldn't the documentation provide the information that 
> sys.getwindowsversion().platform_version returns the 
> kernel32.dll version?

platform_version is documented as an "accurate major version, minor version and 
build number of the current operating system, rather than the version that is 
being emulated for the process". That's it's currently using the file version 
of "kernel32.dll" is an implementation detail, one that needs to be changed to 
something more reliable.

Keep in mind that the Python DLL can be embedded in any application, which may 
not be manifested to get the true OS version via GetVersionExW(). For example, 
when running in Windows 10, the default with no manifest reports Windows 8 (NT 
6.2):

>>> sys.getwindowsversion()
sys.getwindowsversion(major=6, minor=2, build=9200, platform=2, 
service_pack='')

Here it is with a manifest that supports Windows 8.1 (NT 6.3):

>>> sys.getwindowsversion()
sys.getwindowsversion(major=6, minor=3, build=9600, platform=2, 
service_pack='')

This is the OS version that's relevant to the application, but for logging and 
other diagnostics, platform_version is provided to get the real version, at 
least if all goes according to plan.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43284] sys.getwindowsversion().platform_version is incorrect

[Shreyan Avigyan]

Shreyan Avigyan  added the comment:

When we're talking about version are we talking about the kernel32.dll version 
or the Windows version? If we're talking about Windows version then why not use 
the return value of sys.getwindowsversion() itself? How is that function 
getting the Windows version? Moreover shouldn't the documentation provide the 
information that sys.getwindowsversion().platform_version returns the 
kernel32.dll version?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43284] sys.getwindowsversion().platform_version is incorrect

[Shreyan Avigyan]

Change by Shreyan Avigyan :


--
nosy: +shreyanavigyan

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43284] sys.getwindowsversion().platform_version is incorrect

[Eryk Sun]

Change by Eryk Sun :


--
stage:  -> needs patch
title: Inability to fetch build 20H2 -> 
sys.getwindowsversion().platform_version is incorrect
versions: +Python 3.10

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com