Welcome to the Inedo Forums! Check out the Forums Guide for help getting started.
If you are experiencing any issues with the forum software, please visit the Contact Form on our website and let us know!
Reporting & Software Composition Analysis (SCA) shows many unresolved Issues
-
Hi,
We recently starting using SCA and have most of our products in there now but almost all of them show some unresolved issues.
It's always "Missing Package" but most often the same package is listed in the same list as resolved.
Some examples from different products:
#34 Owin 1.0.0 Unknown License Resolved on 5/9/2023 11:55 PM
#89 Owin 1.0.0 Missing Package Unresolved
(this one pops up in quite a few products)#11 Microsoft.Web.Infrastructure 1.0.0 Unknown License Resolved on 5/13/2023 11:49 PM
#24 Microsoft.Web.Infrastructure 1.0.0 Missing Package Unresolved#1 AutoMapper 10.1.1 Unknown License Resolved on 5/15/2023 5:30 PM
#57 AutoMapper 10.1.1 Missing Package Unresolved
#56 WiX 3.11.2 Unknown License Resolved on 5/15/2023 5:30 PM
#58 WiX 3.11.2 Missing Package UnresolvedAll packages are exclusivly downloaded through Proget en we clean our nuget cache once a week on the buildservers.
We are running Version 2023.7 (Build 10)
Any tips on how to resolve there issues are welcome
-
@v-makkenze_6348
We have seen similar issues in our projects. In most of our cases, the problem was that the "missing" packages had different versions numbers (not using the Semantic Version MAJOR.MINOR.PATCH pattern). E.g. Owin's version is actually 1.0 instead of 1.0.0 and Microsoft.Web.Infrastructure's version is 1.0.0.0 instead of 1.0.0. It seems that ProGet has problems matching those packages.We resolved this by creating a legacy feed, manually editing the metadata of those packages and re-uploading them to that feed. The ProGet documentation seems to recommend something similar. It seems that there is a build-in function to do something like that in 2023.7, at least I think I saw something like that popping up when I opened the page of the Owin package in the latest ProGet version. I haven't seen any documentation on this feature yet, though. Maybe the folks from Inedo can shed some light on this.
-
Thanks @sebastian, that's pretty much it :)
The underlying issue is that Visual Studio (NuGet) is referencing
1.0.0while the actual package uses a quirky version1.0. ProGet does not fully support quirky versions, and the SCA Feature will not try to resolve those differences.If you have a "quirky version" of a NuGet package, ProGet 2023 will prompt you to fix it:
In the case of the above, I just created a blank NuGet feed and downloaded "Owin 1.0.0". Then Owin 1.0 appeared in the feed. Anyway, once you fix the quirky versions its should work fine.
Cheers,
Steve
-
Hello,
we recently starting Reporting and SCA with ProGet for our projects. I face a very simular issue with a docker image artifact.
I create a CycloneDX formatted SBOM XML file with syft (https://github.com/anchore/syft) and imported this file to ProGet. On the Overview tab ProGet then reports "372 Unresolved Issues" and on the Issues tab is says Type "Missing Package" and shows an "Unresolved" warning badge.
In the SBOM XML file, there are license identifiers set according to the SPDX list (https://spdx.org/licenses/), but no title or url tags like mentioned in ProGet Docs (https://docs.inedo.com/docs/proget-sca-licenses). These title and url tags are optional according to the XML Specs https://github.com/CycloneDX/specification/blob/1.4/schema/bom-1.4.xsd
We do not use ProGet as a proxy to "pull through" 3rd-party libs or images. Is this a problem?
Or does the missing title and url tags in the SBOM XML file screw something up?
Kind regards,
Tobias
-
@stevedennis I just noticed that the fix seems to be offered only for "short" versions (i.e. 1.0 to 1.0.0) but not for "long" versions (i.e. 1.0.0.0 to 1.0.0). Is this intended? I think that in cases where the last version part is 0, long versions could be auto-fixed the same way as short version.
Two more thing we noticed in the current version of ProGet (2023.8):
-
Packages with packageid:// type licenses are still reported as "Unknown License". According to PG-2381 this should have been fixed in 2023.7, but it seems that the problem still persists. When I look at the package's page, the (manually applied) license is displayed correctly, but the SCA report still does not recognize it.
-
We have a certain license type which is allowed in some feeds and blocked in other feeds. We do this to make sure that packages with that license are downloaded from the "correct" feed. This has worked fine so far. However, starting with ProGet 2023, all packages with that specific license show up as issues in our SCA reports. How can we get rid of that? Manually resolving those issues is not an option, as we are talking about ~100 affected packages on a project with daily builds.
-
-
@sebastian said in Reporting & Software Composition Analysis (SCA) shows many unresolved Issues:
I just noticed that the fix seems to be offered only for "short" versions (i.e. 1.0 to 1.0.0) but not for "long" versions (i.e. 1.0.0.0 to 1.0.0). Is this intended? I think that in cases where the last version part is 0, long versions could be auto-fixed the same way as short version.
A four-part version is not considered a "quirky version" (it's still supported by NuGet), but for some reason the NuGet client/API will occasionally drop the last 0 (e.g. 1.0.0.0 -> 1.0.0), but not always (e.g. 2.1.0.0 isn't dropped?). So we didn't bother with figuring out the rules when displaying that helper-dialog.
[1] Packages with packageid:// type licenses are still reported as "Unknown License". According to PG-2381 this should have been fixed in 2023.7, but it seems that the problem still persists. When I look at the package's page, the (manually applied) license is displayed correctly, but the SCA report still does not recognize it.
Can you create a new thread/ticket for this, with some specific repro instructions/packages (or attach an SBOM so we can very easily recreate it)? This could could be related to PG-2405, but we'd want to see some specific examples of packages to test.
[2] We have a certain license type which is allowed in some feeds and blocked in other feeds. We do this to make sure that packages with that license are downloaded from the "correct" feed. This has worked fine so far. However, starting with ProGet 2023, all packages with that specific license show up as issues in our SCA reports. How can we get rid of that? Manually resolving those issues is not an option, as we are talking about ~100 affected packages on a project with daily builds.
This was actually how ProGet 2022 was supposed to work: if a package download would be blocked in at least one feed, then an issue will be created. The reason for this, pgscan (or an SBOM ) won't know/specify the feed the package is being used from.
The solution we have is to disable the "SCA feature" on the Feed Features. Would that work? We're open to other ideas, but you can see the problem we have... which feed should the analysis use? Etc.
// FYI: might be worth opening a new topic for this one, since it's a different issue as well
-
I submitted a ticket [EDO-9428] for the "unknown license" issue.
I might open another thread for the "partial blocked licenses" issue later, but could you tell me what you mean by disabling the SCA feature in the Feed Features? I don't think I've seen this option in the Feed Features. Also: there are at least two mechanisms in ProGet to block/allow package downloads: license filters and package filters (in the feed's connector settings). What happens when you combine those filters? Is a package always blocked when it is blocked by one mechanism and allowed by the other? What happens if we'd set the default license filter rule to "Block downloads by default" and allow packages like Microsoft.* in the Nuget connector? Could Microsoft.* packages without a known license be downloaded or would they be blocked?
-
I repackaged the Owin package but didn't relalize that that would break all my builds as the dll's are now in a 1.0.0 folder where all the project files expect them in the 1.0 folder.
I guess this would work if the projects are in sdk project format but most of them are not.
-
Hi @sebastian,
could you tell me what you mean by disabling the SCA feature in the Feed Features? I don't think I've seen this option in the Feed Features
This is new to ProGet 2023, and you can find it under the Manage Feed page:
Also: there are at least two mechanisms in ProGet to block/allow package downloads: license filters and package filters (in the feed's connector settings). What happens when you combine those filters? Is a package always blocked when it is blocked by one mechanism and allowed by the other? What happens if we'd set the default license filter rule to "Block downloads by default" and allow packages like Microsoft.* in the Nuget connector? Could Microsoft.* packages without a known license be downloaded or would they be blocked?
A package can be blocked due to vulnerabilities, licenses, connector filters, or package filters rules (i.e. white source). Any one of those will block a download, so I think in your case "Microsoft.* packages without a known license" would be blocked.
This can be overridden at a package level, FYI:
Cheers,
Steve
-
@v-makkenze_6348 said in Reporting & Software Composition Analysis (SCA) shows many unresolved Issues:
I repackaged the Owin package but didn't relalize that that would break all my builds as the dll's are now in a 1.0.0 folder where all the project files expect them in the 1.0 folder.
I guess this would work if the projects are in sdk project format but most of them are not.Unfortunately, a consequence of those quirky versions. Hopefully it won't be too bad to update those projects/references with a bit of search/replace :)
