Using a vulnerability management product - in our case Microsoft Defender of Endpoint - we see the installer version in the vulnerability management tool rather than the version that’s currently updated to.
E.g
Current Version: v1.3.5
(Installer version: v1.1.9)
Your app is up-to-date!
Whilst I’m delighted with the auto-update mechanism in Obsidian, the version expression makes things less delightful.
The Vulnerability Management tooling sees the obsidian.exe file properties as the OS does.
PS C:\Users\bob\AppData\Local\Obsidian> Get-item .\Obsidian.exe |fl VersionInfo
VersionInfo : File: C:\Users\bob\AppData\Local\Obsidian\Obsidian.exe
InternalName: Obsidian
OriginalFilename:
FileVersion: 1.1.9
FileDescription: Obsidian
Product: Obsidian
ProductVersion: 1.1.9.0
How can we improve the delightful update mechanism to help vulnerability management systems interpret state correctly?
Regards
Paul
I am not sure anything should be done. The internal update mechanism only does a partial update. It does not update the electron version used, for that you need to download and reinstall obsidian, I am not sure we should pretend otherwise.
Well, lets say it this way round. If the Obsidian team want to make organisational adoption/licensing lower in friction, it would be ideal if there was a reflection of the updated version in the properties of the installer. If MDE (Microsoft Defender for Endpoint) detects the version as the version of the initial installer, not the current version, that’s going to continue to make any organisations SOC/CyberSec reasonably push back from Obsidian adoption as it’s raised as a vulnerabilty in the Vulnerability management dashboard from whatever tooling is in use. If that’s not something you want to focus effort on that’s fine, but I’m not asking for anyone to pretend to do anything.
But see it may be an outdated version of electron with vulnerability. From that pov, you would want to be warned. I am not sure we should make an effort to camouflage the version of the exe.
Do you have a commercial license?
So, the outcome is that to maintain Obsidian in a managed environment with any vulnerability management tooling is to have the newer version installer run over the top of the existing install, not use the auto-update mechanism? I certainly have no motivation to camouflage anything, I’m pointing out the “holes in the road” as a member of an organisation that has theses processes and was hoping to help you, help me.
No, we don’t have a commercial license, we’re a UK environmental non-profit which falls into the free to use category of Obsidian’s licensing model as far as I read it.
You can think of Obsidian bundle as Chrome (Electron) + a Website. The internal update mechanism updates the website. To update chrome, you need to manually download and reinstall obsidian. There is an in-app notification when we deem that is necessary for you to do so.
I wouldn’t go as far as saying any vulnerability management tool. There are tools that actually detect that it is an electron app and warn you if the bundled chrome (electron) part is too old.
I asked because I was wonder if you wanted to escalate this matter.
I have the same issue as described above (and I have a commercial license…). I’m also interested in a solution.
… but as far as I have understood as a workaround you can install obsidian again (over an existing installation) to update those files. Ok to satisfy my monthly CVE-Report I can now an than update with this manual process. But of cause it would be nice to get this automated, so I have to think about one thing less 