Repository navigation
Conversation
… rid of vulnerability
|
Also: I think that the bump on the VAF dependency is sufficient; the Newtonsoft reference is a transient reference so isn't needed in the packages definition...? |
|
No, bumping the VAF dependency is not sufficient, precisely because it has such a low version of Newtonsoft. If this package doesn't explicitly use a newer nuget, it'll get the "minimum compatible" that is 10.0.3. And looking at the vulnerability report, the patched version is 13.0.1. Best would ofcourse be if the VAF package itself would update its Newtonsoft package to a patched version so any user of only that package or it and this one would get the patched version. |
|
It would by default, but you would be able to bump it higher manually. I completely agree about the underlying VAF reference - and I have re-opened that discussion again internally - but adding a version-specific restriction in this library compounds the issue further; doing so would mean that this then needs to be maintained were that underlying issue to be resolved. |
|
I agree with @CraigHawker . Exploitation requires the app to deserialize untrusted JSON from an authenticated user, so it's the consuming app's concern. The app can simply reference Newtonsoft.Json 13.0.1+ itself, which is required for M-Files Cloud signing anyway. I don't see a need to change the dependencies here because of this. |
|
I disagree with telling your users to just add a reference, that they otherwise don't have any need for, to their apps because you refuse to bump a nuget version. Then it becomes the responsibility of every app consuming this to keep their Newtonsoft updated. That is why, when I first commented on the other issue, I asked if VAF itself could fix this, but was instead told to make this PR. Also before, it was not even possible for the app itself to upgrade Newtonsoft because VAF locked the version to a vulnerable one. |

This is done to get rid of vulnerability in Newtonsoft GHSA-5crp-9r3c-p9vr