Repository navigation
Version information missing from exe file #10601
Description
Activity
Steps to reproduce on Linux (Ubuntu) with
pwsh:# Build $ make clean && make GOOS=windows $ file bin/gh bin/gh: PE32+ executable (console) x86-64, for MS Windows # Check version info $ pwsh -c '[System.Diagnostics.FileVersionInfo]::GetVersionInfo("./bin/gh")' ProductVersion FileVersion FileName -------------- ----------- -------- /path/to/cli/bin/gh $ pwsh -c '[System.Diagnostics.FileVersionInfo]::GetVersionInfo("./bin/gh").ToString()' File: /path/to/cli/bin/gh InternalName: OriginalFilename: FileVersion: FileDescription: Product: ProductVersion: Debug: False Patched: False PreRelease: False PrivateBuild: False SpecialBuild: False Language:
Reacted by Christian I. NilssonOut of curiosity i did some minor digging
Setting version info in Go compiled binaries does require some extra work, and there seems to be more then one package to kind of do the same thing
https://stackoverflow.com/questions/35126344/how-to-set-the-file-version-field-in-pe-header-of-exe-filesTested https://github.com/tc-hib/go-winres with a sample program on Windows 10 and it works fine.
Here's the complete list of commands for Powershell using
go-winres simply(JSON file not required):> mkdir versioninfo > cd versioninfo > go mod init versioninfo > go install github.com/tc-hib/go-winres@latest > Set-Content -Path main.go -Encoding UTF8 -Value " >> package main >> >> //go:generate go-winres simply --product-version=1.0.0.1234 --file-version=1.0.0.1234 >> >> func main() {} >> " > go generate 2025/03/14 18:00:10 did not find icon winres/icon.png > go build > [System.Diagnostics.FileVersionInfo]::GetVersionInfo("C:/Users/azeem/Downloads/versioninfo/versioninfo.exe") ProductVersion FileVersion FileName -------------- ----------- -------- 1.0.0.1234 1.0.0.1234 C:/Users/azeem/Downloads/versioninfo/versioninfo.exe > [System.Diagnostics.FileVersionInfo]::GetVersionInfo("C:/Users/azeem/Downloads/versioninfo/versioninfo.exe").ToString() File: C:/Users/azeem/Downloads/versioninfo/versioninfo.exe InternalName: OriginalFilename: FileVersion: 1.0.0.1234 FileDescription: Product: ProductVersion: 1.0.0.1234 Debug: False Patched: False PreRelease: False PrivateBuild: False SpecialBuild: False Language: Language Neutral
Looks like there'll be a hook for
goreleaserto generate*.sysofile to be used later bygo build. 🤔👋 Hey everyone, I labelled this as an enhancement request because I don't think we ever intended to include version information in the Windows binary - I could be wrong about it, but that's my impression at the moment.
That said, I think this seems like something that would make sense for us to do.
Reacted by Azeem👋 Hey everyone, I labelled this as an enhancement request because I don't think we ever intended to include version information in the Windows binary - I could be wrong about it, but that's my impression at the moment.
That said, I think this seems like something that would make sense for us to do.
How can you NOT include version information? That essentially means that we have no clue what is installed.
Just as an example, When any vulnerability is found we wound have a safe way to know for sure what is there, should we keep generating checksums of the binary to track which version it is?This is a clear bug, even if you did intend to have this bug from the beginning, it shows a great deal of disregard for what Windows binaries should contain, and all it's users.
@caspChristian - thank you for the discussion.
I think our team has different definitions of what a bug is, and I gather that is the cause of the frustration here. I want to emphasize that I did not dispute the value of this feature. In fact, I think you have made a compelling case for it with the security angle, alongside aligning with what is typically expected from Windows binaries 👍 Hearing this sort of feedback is very helpful to understand what users on particular platforms value. As far as I know, this has not been brought up previously.
I want to assure you that labelling this as an enhancement does not affect prioritization or whether we would accept this work. Labels like
enhancementare mostly for the core team and our processes, aligning with criteria we have established and what we feel best represents our intentions with the product.Reacted by Babak K. ShandizAdditional notes and increasing scope for other required information
Following up as a related request and digging into this a bit, I think there are likely several of the following properties we would want to set within the
.sysofile for Windows users:CompanyName:GitHubFileDescription:GitHub CLIFileVersion: Version being released; same asProductVersionInternalName:ghOriginalFilename:gh.exeProductName:GitHub CLIProductVersion: Version being released; same asFileVersion
References
Here are some additional details I uncovered coming at this:
-
https://go.dev/wiki/GcToolchainTricks
Go documentation explaining how
go buildworks with.sysofiles -
https://github.com/josephspurrier/goversioninfo
Generates a
.sysofile likewindresto be used withgo build -
Example of project using
goversioninfotool to generate.sysofile -
This is the technical documentation behind the version info under discussion
Property Description CommentsAdditional information that should be displayed for diagnostic purposes. CompanyNameCompany that produced the file—for example, Microsoft Corporation or Standard Microsystems Corporation, Inc. This string is required. FileDescriptionFile description to be presented to users. This string may be displayed in a list box when the user is choosing files to install—for example, Keyboard Driver for AT-Style Keyboards. This string is required. FileVersionVersion number of the file—for example, 3.10 or 5.00.RC2. This string is required. InternalNameInternal name of the file, if one exists—for example, a module name if the file is a dynamic-link library. If the file has no internal name, this string should be the original filename, without extension. This string is required. LegalCopyrightCopyright notices that apply to the file. This should include the full text of all notices, legal symbols, copyright dates, and so on. This string is optional. LegalTrademarksTrademarks and registered trademarks that apply to the file. This should include the full text of all notices, legal symbols, trademark numbers, and so on. This string is optional. OriginalFilenameOriginal name of the file, not including a path. This information enables an application to determine whether a file has been renamed by a user. The format of the name depends on the file system for which the file was created. This string is required. PrivateBuildInformation about a private version of the file—for example, Built by TESTER1 on \TESTBED. This string should be present only if VS_FF_PRIVATEBUILD is specified in the fileflags parameter of the root block. ProductNameName of the product with which the file is distributed. This string is required. ProductVersionVersion of the product with which the file is distributed—for example, 3.10 or 5.00.RC2. This string is required. SpecialBuildText that specifies how this version of the file differs from the standard version—for example, Private build for TESTER1 solving mouse problems on M250 and M250E computers. This string should be present only if VS_FF_SPECIALBUILD is specified in the fileflags parameter of the root block.
Reacted by Christian I. Nilsson- linked a pull request that will close this issueEmbed Windows resources (VERSIONINFO) during build #11048
on May 30, 2025
Describe the bug
ProductVersion and FileVersion should be set in .exe at buildtime.
This affects version management and ability to find any vulnerable versions
Affected versions
Probably all, but verified with these
gh --versiongh version 2.63.1 (2024-12-03)
https://github.com/cli/cli/releases/tag/v2.63.1
gh version 2.67.0 (2025-02-11)
https://github.com/cli/cli/releases/tag/v2.67.0
gh version 2.68.1 (2025-03-06)
https://github.com/cli/cli/releases/tag/v2.68.1
Steps to reproduce the behavior
Check details from explorer, or this in powershell:
Expected vs actual behavior
Actual: