Bugzilla

(In reply to Daniel Veditz [:dveditz] from comment #8)
> We can't do anything about that. `version.dll` is never explicitly loaded from Firefox so we can't simply "use the full path" to fix this; it's implicitly loaded by some other library in Windows itself, or looking at the first image probably from the Microsoft redistributable `vcruntime140.dll`.

"Real Correct Fix (TM)" explained in bug 1683425 may mitigate that because we will no longer load `vcruntime140.dll` from our app directory.  `kernel32.dll` is a known dll. We can load all other dlls using delay-load (we will have to do it anyway due to Win32k lockdown.)

> We don't try to protect against a malicious actor who can modify the Firefox install directory because they could modify Firefox itself at that point.

I was told that putting a new file might require less privileges than replacing an existing file in bug 1292444.

(In reply to Daniel Veditz [:dveditz] from comment #8)
> We can't do anything about that. `version.dll` is never explicitly loaded from Firefox so we can't simply "use the full path" to fix this; it's implicitly loaded by some other library in Windows itself, or looking at the first image probably from the Microsoft redistributable `vcruntime140.dll`.

~~~"Real Correct Fix (TM)" explained in bug 1683425 may mitigate that because we will no longer load `vcruntime140.dll` from our app directory.  `kernel32.dll` is a known dll. We can load all other dlls using delay-load (we will have to do it anyway due to Win32k lockdown.)~~~

> We don't try to protect against a malicious actor who can modify the Firefox install directory because they could modify Firefox itself at that point.

I was told that putting a new file might require less privileges than replacing an existing file in bug 1292444.