According to a recent JFrog Xray scan, our application (.NET 5) has a "critical" vulnerability due to a dependency on a specific version of Microsoft.NETCore.Platforms. There is a newer version of the package with the vulnerability resolved that I want my project to use instead. The problem I'm having is that this is not a package that we've explicitly added to the project, but rather a dependency that some other packages have, so simply adding the newer version of the package to the project isn't enough to remove the dependency entirely; I can still see references to the "bad" version appearing in project.assets.json. Upgrading to the latest version of the top-level packages has helped, but has still left some references to the "bad" version of Microsoft.NETCore.Platforms via dependencies of dependencies of dependencies.
E.g, we're using the very latest version of Microsoft.ApplicationInsights, but this has a dependency on System.Diagnostics.PerformanceCounter, which has a dependency on the "bad" Microsoft.NETCore.Platforms.
TLDR; I want to be able to tell my project "If you have a dependency on this package anywhere in your dependency tree, don't use version X, use version Y instead", but I'm not sure if there exists a way to do this.
You can't change what version of a library your dependencies use because that could easily introduce breaking changes. This is the modern version of DLL hell.
The answer is to update the library that has the old dependency. If it's open source, you can do this yourself and use your forked version with the updated dependencies. If you don't have access to the source then you will have to contact the developer and tell them about the vulnerability.
If the developer is Microsoft, godspeed.
Related
I have a private NuGet package that I'm installing on an existing project. The project already contains several of the dependencies the private NuGet package requires but at a lower version than what the private package requires. When I try to install the private package the installation throws an error (no error number)
Package restore failed. Rolling back package changes for
'ConsoleApp1'.
In the package manager output it is reporting a
Detected package downgrade
Since the package that it's referencing is a public package on NuGet.org I would expect at a minimum to be prompted to upgrade the dependency during the installation process instead of erroring and rolling back. I've know packages that are not already included in the project are being installed automatically and can see that in the logs.
I've seen other posting that range from ignoring the warning/error to a pre-build script that does the upgrade (which is not a option for installing new packages)
Can the package manager be instructed to automatically upgrade the existing packages to at least the minimum version the dependency list has defined?
Afraid not.
It's not really a trivial problem to solve - suppose it uses the approach you suggested and your project currently references packageA v1.0.0 and packageB v1.0.0.
You add a new package with a dependency on package A v2.0.0.
It prompts you to upgrade packageAfrom 1.0.0 to 2.0.0 to avoid a downgrade.
But package A 2.0.0 has a new dependency on packageBat 2.0.0, which causes a downgrade for you on that package.
Every new upgrade in turn can trigger new upgrades. You can also engineer scenarios where there isn't even a way to upgrade other packages to make it all work. On top of that all of this requires fetching lots of information from your package source.
Since there's not a clear, general way to fix this the tooling leaves you to work out what you want to do yourself.
I'm looking for some experience or thoughts on the following problem.
I have a Nuget Package (EntityFrameworkExtras 1.2.0) thats hosted on the main Nuget Feed.
This package has a dependency on EntityFramework. Everything was hunky dorey until EntityFramework 6 was released.
A change in the EntityFramework code means that my package no longer works with EntityFramework 6 and onwards.
I'm trying to consider how best to deal with this problem, i foresee two options:
1) Maintain 2 versions of the Package
So, i would have one version of the package that is compiled with EntityFramework 5.0.0 and the .nuspec would
dictate that it is dependant on EntityFramework [0.0.0 - 5.0.0]
I would introduce a new package called EntityFrameworkExtras (ef6). This package would be compiled in EntityFramework 6.0.0
and the .nuspec would dictate that it is dependant on EntityFramework [6.0.0 >= *]
2) Have a new version of the current package that would support EntityFramework 6.0
so the currently version would support EntityFramework 5.0.0 and less
and i would add a new version of the package (version 2.0.0) that would depend on EntityFramework 6.0.0 [6.0.0 >= *]
I went for option 1) in the end. I believe this is an easier option for the user of the packages because its clear what each of the package's dependencies are.
I also believe its easier to use the nuget commands when working with different packages, rather then attempting to be aware that different versions of one package have different dependency versions.
Also from a development perspective it cleaner and easier to develop and fix bugs on the different packages. Finally, it would make a continuous integration environment easier to implement, because each package would be consider a different project.
I'm suffering from the version conflict on Eclipse.
I want to use the following two plugins in one Eclipse instance.
org.abc.plugin1a
has a dependency on org.eclipse.plugin1b_1.0.0
(works well only with version 1.0.0, not work with the newer version!)
impossible to be maintained because of a certain reason
org.eclipse.plugin2a
has a dependency on org.eclipse.plugin1b_2.0.0 (or newer)
Actually org.abc.plugin1a was developed experimentally by an ex-employee, not by me. The source codes are available but too complicated.
I found there are huge differences between org.eclipse.plugin1b_1.0.0 and 2.0.0.
So it is almost impossible for me to update org.abc.plugin1a to work with org.eclipse.plugin1b_2.0.0
Is there any answer to solve my problem?
Specify both the minimum and maximum version of the plugin in the Require-Bundle:
Require-Bundle: org.eclipse.plugin1b_1.0.0;bundle-version="[1.0.0,1.0.0]"
This will not work if plugin org.eclipse.plugin1b is marked as a singleton since in that case Eclipse will only load one version of the plugin.
Within the context of upgrading plugins explain how to resolve plugin dependencies when NetBeans user interface's reports specific missing dependencies, yet these do not resolve with a google search or are unmentioned in the netbeans FAQ.
The practical example leading me to ask this question was when I attempted to install an in-development-plugin org-netbeans-modules-htmlprojects.nbm. It requires General Queries API v1.24 and I have v1.19.1.
Have a look at the bug report that mentions the nbm, it's for version 7. This also means that the mentioned version for GQA is also version 7 specific.
You best choice is probably to upgrade to version 7, it has some nice improvements over version 6.9 like HTML5 support. As a new install picks up the configuration of an installed previous version upgrading shouldn't be a lot of work.
EDIT based on restated question:
The short form: you cannot, it's not meant to work that way.
The long form: due to what happened here and the inner workings of Netbeans the error message was less clear than it could have been...
you downloaded a module for a higher version than the installed one
Netbeans' nbm deployment descriptor states dependencies on editor modules, not on editor versions - see inside the nbm which is actually a ZIP file Info/info.xml, manifest element, OpenIDE-Module-Module-Dependencies attribute.
Normally that error would not happen, as the version of the nbm will normally match the editor version, and the dependencies should either be satisfied or satisfiable by on-the-fly installation of the missing dependencies.
I've recently learned that the import section from feature.xml is legacy, and the actual dependency work is delegated to the p2 engine, which uses the information from the plugin manifest.
I am not sure though if p2 is available for all recent versions of Eclipse, or in all Eclipse-based products, so I'm not sure if it is safe to remove the import section from feature.xml.
Under what circumstances is it safe to remove the import section from feature.xml? Assume that we are taking into consideration Eclipse 3.4 or newer.
P2 was introduced in Eclipse 3.4 release. It had quite a few issues in that release, so a way was given to revert your Eclipse install to using the legacy Update Manager. Starting with 3.5 release, p2 is quite stable and is a definite improvement over the old Update Manager. I am not certain if it is possible to revert to the Update Manager in 3.5 or higher release. I certainly haven't heard of anyone doing this.
P2 is present in all Eclipse packages starting with 3.4 release.
I wouldn't categorize feature import as a deprecated feature. You would still want to use it to pull in plugins when you don't have direct OSGi dependency on them.
Consider the case where you are building an extension to JDT. Say you only depend on JDT core api (no UI extensions). If you only rely on OSGi dependencies, when your plugin is installed, p2 will dutifully install JDT core bundle, but not the UI bundle. Perfectly fine from OSGi perspective, but probably not what you intended.
I recommend sticking with feature import to describe your high level dependencies to make sure that they are installed in full. Relying only on OSGi dependencies works best for free-floating bundles that aren't part of something bigger that should be installed as a unit.