You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(Possibly a question, possibly a complete misunderstanding, possibly a feature request.)
The "direct dependency wins" feature of NuGet's dependency resolution algorithm means that any exe can override any transitive dependency from a library it consumes. That means it's ultimately up to the application developer, not the library developer, what they depend on. For library authors, it's often good practice to keep your dependency versions as low as possible (e.g. library developers should depend on FSharp.Core v4.3.4 rather than e.g. v8 if they're not using features from later versions), to maximise compatibility.
Say that hypothetically a vulnerability is found in FSharp.Core v4.3.4. I, a virtuous library developer, have <PackageReference Update="FSharp.Core" Version="4.3.4" />. Now my library is considered vulnerable, but if there is any vulnerability in reality it is only by virtue of the fact that its consumers are choosing to use a vulnerable version of FSharp.Core. I am forced either to suppress the warning, or to impose excessively restrictive dependency requirements on my consumers in the name of making the warning go away. (My consumers may be perfectly happy to accept whatever vulnerability was found in the transitive dependency!)
Since net9 is moving from flagging "direct" dependencies to flagging "all" dependencies by default, does it make sense to warn only on executables by default? By the above reasoning I'd expect library developers to suppress the warnings in the library; and a library developer will presumably have a test project, and will therefore still see the warnings transitively through that project (so can choose whether to upgrade the library or the dependency in the test project).
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
(Possibly a question, possibly a complete misunderstanding, possibly a feature request.)
The "direct dependency wins" feature of NuGet's dependency resolution algorithm means that any exe can override any transitive dependency from a library it consumes. That means it's ultimately up to the application developer, not the library developer, what they depend on. For library authors, it's often good practice to keep your dependency versions as low as possible (e.g. library developers should depend on FSharp.Core v4.3.4 rather than e.g. v8 if they're not using features from later versions), to maximise compatibility.
Say that hypothetically a vulnerability is found in FSharp.Core v4.3.4. I, a virtuous library developer, have
<PackageReference Update="FSharp.Core" Version="4.3.4" />
. Now my library is considered vulnerable, but if there is any vulnerability in reality it is only by virtue of the fact that its consumers are choosing to use a vulnerable version of FSharp.Core. I am forced either to suppress the warning, or to impose excessively restrictive dependency requirements on my consumers in the name of making the warning go away. (My consumers may be perfectly happy to accept whatever vulnerability was found in the transitive dependency!)Since net9 is moving from flagging "direct" dependencies to flagging "all" dependencies by default, does it make sense to warn only on executables by default? By the above reasoning I'd expect library developers to suppress the warnings in the library; and a library developer will presumably have a test project, and will therefore still see the warnings transitively through that project (so can choose whether to upgrade the library or the dependency in the test project).
Beta Was this translation helpful? Give feedback.
All reactions