[Solved] Unique display of version information
-
@Tom I the past I reported many times that you should alter the version numbers of applications because they display the version information not in the format 4 numbers separated by a dot.
So I suggest that you always use the 4-numbers-format no matter how apps display it.Here are some examples(*) where the version number can be displayed in the 4-numbers-format because both numbers are equal:
Application Version in the EXE Version in the Application 7-Zip 16.2.0.0 16.02 FileZilla 3.35.1.0 3.35.1 GIMP 2.10.4.0 2.10.4 Pidgin 2.13.0.0 2.13.0 Thunderbird 60.0.0.0 60.0 (*) = In my list of applications I have 28 apps where the version number has not the 4-numbers-format.
Advantages/Disadvantages:
- [Pro] Unique display of version number
- [Pro] Less work for you
- [Con] User might be confused because the version in the application is different to VulnDetect
Here are some examples where the both numbers are not equal so you have to alter he version number:
Application Version in the EXE Version in the Application Mp3tag 2.89.1.0 2.89.a Star Citizen 3.2.12.60262 3.2.2 Xinorbis 8.0.15.37 8.1.8 Advantages/Disadvantages:
- [Pro] User see the same version in the EXE and in VulnDetect (no confusion)
- [Con] More work for you
- [Con] Not unique display of version number
Conclusion
Is suggest that you use a mix of both methods.
- When the displayed version is the same than the version in the EXE (just missing zeros) then use the 4-numbers-format.
- Only when both versions are totally different then you alter it.
Advantages/Disadvantages:
- [Pro] Unique display of version number (except of some apps)
- [Pro] Less work for you
- [Con] Not unique display of version number (for the exceptions)
- [???] I am not sure if this will confuse the user
-
Yes, all this inconsistency in versioning is quite annoying and there is no "one size fits all" in this.
As you know, we have a tonnes of breaking changes that are upcoming for the rules.
Among them, is support for two different kind of version numbers:
- FileVersion# or ProductVersion# as extracted from the detected file
- "DisplayVersion" which is either a "sanitized" FileVersion# or information provided by users / registry / other file or where else we can get it
So this is pretty much the same as you suggested above.
We would really like to be able to detect all "DisplayVersions" automatically, since getting it from you and other users is time consuming, but in cases where the registry can't provide this information, then we have to continue to update this manually.
However, patience is needed, we will make those changes in the rules and back end next week, but we will not implement this in the UI yet (since we don't have the data in the results database yet).
-
@Tom it is good that you have a Display Version separate to the Technical Version.
But the question now is: do you also want to have a different Display Version if there are only some zeros missing?
So when Thunderbird has the displayed version 60.0 and the file version 60.0.0.0 do you still want to alter the Display Version ?So should I continue reporting if there are different Display Version even if there are only some zeros missing?
-
@olli_s I think this is a decision that needs to be made on a per app basis, depending on the discrepancy between the two.
In most cases I suppose we want this, however, part of the new rules and back-end is support for pulling information from the registry and in some cases we can get it automatically from the registry.
But when you suggest new software, it is always nice to get, because then I know what to look for when creating the first rules. -
You display the version number like it is shown in the app.
So I consider this issue is solved.
