macvim-dev
Reconcile version #'ing system
Hello, my company uses an endpoint software monitoring system to ensure apps are updated to avoid vulnerabilities.
This version:
Is being reported as suffering from: https://www.cve.org/CVERecord?id=CVE-2023-41036 and https://nvd.nist.gov/vuln/detail/CVE-2023-41036 (Both are the same.)
I believe the version reported by MacOS:
Leads the endpoint monitoring software to see this as behind release 178.
I understand that the versioning may be due to “stuff”. However, this legacy practice brings extra unwanted attention. If efforts can be made to improve this, I’m sure others will be appreciative as well.
Thank you, David Halonen
Hmm, do you know how the endpoint monitoring is checking for the version? A macOS software has two version specifiers: a CFBundleVersion that's the "real" machine-readable version, and a "short version string" that from what I understand is more a human-readable string for users.
It seems to me that a proper endpoint monitoring software should be reading the machine-readable CFBundleVersion since that's the more the "real" version that's designed to be parsed by a software like that. I do understand that you likely have very little control over it, but it sounds to me it should have been parsing the other value instead.
How big of an issue is this for you at the moment? The current versioning scheme is indeed weird due to historical reasons but I'm a little weary of changing it due to potentially affecting existing systems that may use the short version string (e.g. Homebrew uses that as the versioning).
That said… looking at repology, it's reporting Homebrew etc as all vulnerable to the same CVE issue since they are also using "9.1.1128", ugh…
Let me think a bit about this.
Also, how exactly are you installing MacVim? Are you just downloading MacVim from the website? Or something like Homebrew?
I'd like to add that there's 2 versions inside MacVim: MacVim part (build r178 or r181.1) and Vim part (which is 9.1.1128).
Version MacVim part version was only displayed in the About MacVim" menu and MacVim.app/Contents/MacOS/Vim --help and QuickLook app preview doesn't show this version.
@ychin Is it possible MacVim version will be infused into the display version of QuickLook and added into --version output?
Yes, 178.0 is the CFBundleVersion I talked about and is the actual machine-parsable version. The Vim version (9.1.1128) is the "short version string" I mentioned.
Is it possible MacVim version will be infused into the display version of QuickLook?
Kind of. It uses the short version string. Changing that would basically mean just using the MacVim version (178.0) for both CFBundleVersion or short version string.
added into --version output
I'm not sure this is a good idea. Vim's concept of versioning is separate and "below" MacVim's version. I'm not sure if it helps to have that be knowledgeable about MacVim's versioning scheme when you are using the CLI Vim. I also doubt that's what the end point software is parsing.
I would like some clarity from @dhalonen about how their end point software works first (are you allowed to elaborate on which one?) and how he installs MacVim first. The easiest way to solve this is to just use 178.0 for both version strings. It's definitely confusing that the two versioning metadata are completely different.
There are also downstream effects because Homebrew and MacPort are using the Vim version (9.1.1128) as the way these packages are versioned. I think it's possible to convince them to use 178.0 instead since it would be a one-time bump but if we want to do that i would probably need to consult with them a little bit.
You can use 9.1.1178-r178.2 format for QL to not keep Vim version. SemVer support this kind of thing. The most important is to be consistent.
On --version: I'd add an additional line for MacVim. This should not be invasive, should it?
The question is what problem are we trying to solve here? I don't want to make changes just for the sake of it. The end point software is likely just having a dumb parser for the short version string. It's not going to magically understand some string like "9.1.1178-r178.2" because it's just going to read "major version 9 is smaller than 176". I would prefer to wait for the filer to respond so we can know what type of software is parsing this.
Same issue with --version. I am not sure adding the MacVim version there is solving any problem we have. Note that it's not that trivial to add that info. Vim does not know much about MacVim because MacVim is the GUI wrapper above it. It doesn't really make a lot of sense to query the GUI version from Vim CLI.
I see your point with --version, but I still prefer to be able to get info with command line as well. Maybe there's a command to get it?
I'm sorry to tangle QL human readable version with this question, but for me it's important to see both of them. And as you pointed out, MacVim is not a standalone GUI, so for me it's important to have both versions in the same time.
As you pointed out, machine-readable is already in the Info.plist file.
About Homebrew/MacPorts versioning: they get version from GitHub, then translate to Vim version (as it's the most important for a user. Thus, if version would be aligned with Vim version, it would be way easier to understand what is what.
In all cases I've observed when Vim version increases, MacVim increases as well, so it won't be a problem. In most cases MacVim version increases, Vim version increases except few exceptions. The versioning scheme I proposed earlier I will include both Vim version and MacVim version. Which solves both questions at once with making Homebrew/MacPorts versioning not rebel, but you can ask them to include the MacVim version into their to have no misunderstanding on that.
In case you would worry how to migrate on GitHub, usually such systems were taking latest release and do their magic to translate versions. I don't know if version needs to be modified there.
I see your point with --version, but I still prefer to be able to get info with command line as well. Maybe there's a command to get it?
I'm sorry to tangle QL human readable version with this question, but for me it's important to see both of them. And as you pointed out, MacVim is not a standalone GUI, so for me it's important to have both versions in the same time.
As you pointed out, machine-readable is already in the Info.plist file.
About Homebrew/MacPorts versioning: they get version from GitHub, then translate to Vim version (as it's the most important for a user. Thus, if version would be aligned with Vim version, it would be way easier to understand what is what.
In all cases I've observed when Vim version increases, MacVim increases as well, so it won't be a problem. In most cases MacVim version increases, Vim version increases except few exceptions. The versioning scheme I proposed earlier I will include both Vim version and MacVim version. Which solves both questions at once with making Homebrew/MacPorts versioning not rebel, but you can ask them to include the MacVim version into their to have no misunderstanding on that.
In case you would worry how to migrate on GitHub, usually such systems were taking latest release and do their magic to translate versions. I don't know if version needs to be modified there.
Also, how exactly are you installing MacVim? Are you just downloading MacVim from the website? Or something like Homebrew?
Downloading from website.
@ychin
I would like some clarity from @dhalonen about how their end point software works first (are you allowed to elaborate on which one?) and how he installs MacVim first. The easiest way to solve this is to just use 178.0 for both version strings. It's definitely confusing that the two versioning metadata are completely different.
SentinelOne on macOS detects an application's version using the CFBundleShortVersionString property from the app's Info.plist file, which is the user-visible version string and commonly used for tracking software versioning in management and deployment tools. While both CFBundleVersion and CFBundleShortVersionString are present in Mac app bundles (with CFBundleVersion being the build number and CFBundleShortVersionString the release version), management and detection scenarios—such as those involving deployment tools like Intune or Omnissa Workspace One—specifically refer to CFBundleShortVersionString for version detection and application reporting.
BTW, isn't Vim a MacVim dependency? MacVim is MacVim and should have its own version, independent of Vim. I fail to see why it's critically important to conflate them (I'm just funny that way).
As vulnerability scanning software continues to exist (and grow), simple consistency is needed. The Department of War has a program called FedRAMP 20X (being developed) - which will rely heavily on machine readable components for automated auditing. Automated reporting, alerting, & auditing must be supported.
It sounds like MacVim is setting CFBundleShortVersionString unusually, and that it’s more conventional — in a finished release — for CFBundleVersion and CFBundleShortVersionString to have the same value.
The existence of a CVE with the text “Macvim” (sic) and “Prior to version 178” surely caused hundreds of parsers to be written/generated into the world that are checking “>=178” against a coin toss of possible places with version strings — and clearly those tests are generated (and sold as commercial software 🙃) whether they function or not
Likely to continue being the case in the world, so probably simplest (for adoption, for issues) for the free software MacVim to adjust its side of things
About what version should be shown:
I think MacVim should simply set its own application version in all places (i.e. 181). I get the desire to also surface the version of bundled vim, but since Apple docs say the syntax is 1.2.3 and naive parsers be in the world I think putting that info as extra text in the About window is reasonable (and it's available from :version). Sparkle is another bundled dependency and I don’t expect its version to be made programmatically available.
It looks like the Homebrew MacVim formula was just tweaked in July, so it should be possible to tweak it again 🙂
@gouch while it's nice to have one version, it's better to have both of them somehow.
One is Vim core version (e.g. 9.x.x) corresponds to one or more MacVim GUI part versions. While MacVim GUI version part is more likely to perceived like a product version, only Vim core version is used for Vim language & plugin compatibility.
Users have to establish some connection between two all the time. For me it was blessing when MacVim started to use Vim Core version for releases on GitHub.
From admin perspective product version is easier and probably more important, while from a user perspective both Vim core + product version are important: one for changes in Vim core, another for changes in GUI.
As per 178 vs 9.x, there was quite a lot of similar version changes both in closed and open source software. Many programs and libraries have their version as a date, then switched to normal semver releases.
I'd like to remind that back in the day MacVim GUI version was more like a build number, rather than a normal version.
The ugly solution for this, which would work, is use 9.x.x.y versioning where 9.x.x is Vim Core, and y is MacVim GUI, but I have my doubts, that this will be accepted as a solution.
Because of how that CVE was phrased, possibly incorrectly, it’s now been slurped into the security ecosystem that MacVim versions 0, 1, 2, 3, … 9, … 175, 176, 177 are insecure. So one can predict that releasing MacVim with any of those digits in the major version position of CFBundleVersion and CFBundleShortVersionString will cause some number of basic scanning patterns to flag it as insecure (example).
One could say it’s on those scanning groups/companies to fix their pattern checks to account for MacVim idiosyncrasies (example of that), and that would be fair. Need to decide the tradeoff of that position vs benefit to MacVim users.
@dhalonen So like… if you manually edited MacVim’s version string to a number higher than 177, that would resolve your specific false flag situation? 🙃
plutil -replace CFBundleShortVersionString -string 999 /Applications/MacVim.app/Contents/Info.plist
For any CVE version range is defined and if they only accept one side, it's an issue of poorly designed software, which should be reports and fixed.
There's plenty examples of software, which had CVE and version format yyyy.MM.dd and they had changed to similar to 1.0.14. And security tools had adapted well for such software pieces. Java library Apache Commons is a well known example.