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
{{ message }}
Repository navigation
Get NuGet package versions from federated PURL version data in https://github.com/aboutcode-data/ #2418
I investigated the example package and traced the empty result to NuGet registration pagination.
The package pkg:nuget/Microsoft.WindowsDesktop.App.Runtime.win-arm64 currently has 138 versions upstream across three registration pages:
page/5.0.0/7.0.11.json — 64 versions
page/7.0.12/10.0.2.json — 64 versions
page/10.0.3/10.0.12.json — 10 versions
The issue is that fetchcode.package_versions.nuget_extract_versions() only consumed inline items from the registration index. For packages with large release histories, NuGet omits inline items and points to external pages through @id, which were previously unvisited.
Once PR #214 is merged and consumed in VulnerableCode, fetchcode.package_versions.versions("pkg:nuget/Microsoft.WindowsDesktop.App.Runtime.win-arm64") resolves all 138 versions directly from NuGet.
Would resolving this via fetchcode #214 cover #2418, or is the intended behavior still to add a fallback to federated aboutcode-data PURL repositories for packages whose versions are genuinely unavailable upstream?
Hi @keshav-space, I’d like to work on this issue. I’ll first look into the current NuGet version-fetching flow and how the AboutCode Data PURL version data can be used as a fallback. If there are any specific edge cases or expected behavior I should keep in mind, please let me know.
This should be fixed by aboutcode-org/fetchcode#214. The registration index for this package links to external pages instead of inlining versions, which fetchcode didn't follow. With #214, versions("pkg:nuget/Microsoft.WindowsDesktop.App.Runtime.win-arm64") returns 138 versions (5.0.0 to 10.0.12) instead of 0.
Activity
hardikkaurani commentedon Sep 9, 2026
Hi @keshav-space,
I investigated the example package and traced the empty result to NuGet registration pagination.
The package
pkg:nuget/Microsoft.WindowsDesktop.App.Runtime.win-arm64currently has 138 versions upstream across three registration pages:page/5.0.0/7.0.11.json— 64 versionspage/7.0.12/10.0.2.json— 64 versionspage/10.0.3/10.0.12.json— 10 versionsThe issue is that
fetchcode.package_versions.nuget_extract_versions()only consumed inlineitemsfrom the registration index. For packages with large release histories, NuGet omits inlineitemsand points to external pages through@id, which were previously unvisited.Contributor @codewithfourtix recently submitted a PR in fetchcode addressing this exact pagination behavior: aboutcode-org/fetchcode#214.
Once PR #214 is merged and consumed in VulnerableCode,
fetchcode.package_versions.versions("pkg:nuget/Microsoft.WindowsDesktop.App.Runtime.win-arm64")resolves all 138 versions directly from NuGet.Would resolving this via fetchcode #214 cover #2418, or is the intended behavior still to add a fallback to federated
aboutcode-dataPURL repositories for packages whose versions are genuinely unavailable upstream?Anshi321 commentedon Oct 5, 2026
Hi @keshav-space, I’d like to work on this issue. I’ll first look into the current NuGet version-fetching flow and how the AboutCode Data PURL version data can be used as a fallback. If there are any specific edge cases or expected behavior I should keep in mind, please let me know.
codewithfourtix commentedon Oct 5, 2026
This should be fixed by aboutcode-org/fetchcode#214. The registration index for this package links to external pages instead of inlining versions, which fetchcode didn't follow. With #214,
versions("pkg:nuget/Microsoft.WindowsDesktop.App.Runtime.win-arm64")returns 138 versions (5.0.0 to 10.0.12) instead of 0.Anshi321 commentedon Oct 6, 2026
Thanks for pointing this out! I’ll check #214 and see if there’s anything still needed on the VulnerableCode side.