Topics created by v.makkenze_6348

Hi @v-makkenze_6348, I was able to identify the issue, PG-2778, and will have this fixed in the next maintenance release of ProGet. Thanks, Rich

@apxltd At the moment we only have five I think. The adoption rate of it has been slow due to the SCA feature being very interesting but lacking the presentation of some valuable information, such as what this thread addresses. Once the adoption grows with increased information connectivity (builds with the associated packages for instance and this license component) we would likely have more than 300 or 400 build projects.

I did a "Pull to ProGet" and ran analyze again and now the warning is gone.

Hi @v-makkenze_6348 , Thanks for the report; please ignore this, it should not be logged in the Diagnostic Center. It's addressed via PG-2625 in ProGet 2024.1 Cheers, Alana

@stevedennis Thanks for the updated version - it works smoothly now.

Hi @v-makkenze_6348 , This error can happen if you made certain changes to IIS configuration; in this case, you changed the name of the ProGet site in IIS to something else. That is not supported, so you will get this error. In general, we recommend moving away from IIS; this is because Microsoft no longer recommends using IIS for modern applications (.NET). And there is weird behavior like this. They only recommend it as a proxy server and legacy application server (Classic ASP, .NET Framework, etc).

Hello @v-makkenze_6348 , We're aware of this issue, and it's related to NuGet packages with four-part versions that end in zero, and the way the package is handled behind the scenes. It's a fairly involved/complex issue that we need to fix in a major version -- and we've already done that, in ProGet 2024 :) We expect it to release soon. You'll need to delete the cached package then re-add it. We've tested this exact scenario w/ SCA Builds/Releases. Thanks Alana

@v-makkenze_6348 thanks for clarifying - that's not how we intended to use the feature, but hopefully the ProGet 2024 model will work better. In ProGet 2024, they are called Builds, and Builds have a Release Number. They are also auto-archived, and have a kind of Build Stage. Sorry but I don't yet have screenshots, but there is some documentation: https://docs.inedo.com/docs/proget-sca-builds

Thanks I made a backup and ran the script and it did clean up quite a few rows. I'll try upgrading to 2024 again next week after we released :)

@v-makkenze_6348 Thanks, we'll add this to our "final touches" in PG2024 :)

Hi @v-makkenze_6348, It's hard to say for sure, but there's clearly some kind of database timeout problem here when running Projects_GetReleaseAnalyzerData . I suppose you could try running that directly, and see if it takes a long time? I suspect the issue is that you have too many active releases. This is a major issue with ProGet 2023's feature -- it was designed with the assumption that users would archive releases, but we've seen thousands in the field. If you have a lot of active releases, this cause some big performance issues. ProGet 2024 auto-archives builds (the new word for releases). Cheers, Alana

Hi, I checked again and the number of packages is correct when the build succeeds. Had to run the build 9 times before I had a build that did not give a timeout. Before i counted the number of components in the SBOM but the app itself is also a component and i have two SBOM's so therefore i was missing two packages. I get the feeling that during the failing builds the SBOM is uploaded but not completely processed. So the next build its processed and thats when i see three SBOM's or four if the build succeeds. Still no clue why this is the only build that has these failures, its not our biggest or most complex product. We don't have many builds that contain both npm and nuget packages but there are others. All builds are run at least once a week so the others with two pgscans are ok.

Hi @v-makkenze_6348, thanks for the report, I was able to reproduce it with that particular package. We plan to resolve this via PG-2587 in the next maintenance release scheduled for next Friday.

Hi @v-makkenze_6348, We've rewritten this to not use MERGE, which should help; we plan to ship PG-2583 in the upcoming maintenance release on Mar 1. Cheers, Steve

Hi @v-makkenze_6348, This fix has been released in pgscan 1.5.7. Please let us know if you have any questions! Thanks, Rich

Thanks, I updated and feed cleanup is back to seconds instead of hours

Hi @aivanov_3749 , I'm afraid the reply is the same :( ProGet 2023 is effectively a new database architecture entirely, and while we tested every possible scenario we could imagine (as well as dozens of customer databases), some regressions are to be expected. It's also possible that there was a bug or edge case in the old retention rules, and the packages that should have been deleted weren't/ Upgrading to ProGet 2023 will automatically disable all retention rules on all feeds, and you'll be prompted to attempt a dry run before re-enabling them. The best way to troubleshoot retention rules deleting unexpected packages is to use the "dry run" feature. This will let you tweak the rules, and find which setting is behaving unexpectedly. If you can let us know specifics or provide those execution logs, we will definitely do our best to identify the underlying cause. Thanks, 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 :)

This is now fixed in 2023.3, which is going to be released later today. Thank you!

Hi @v-makkenze_6348, When you enable the preview feature for ProGet Vulnerability Central, ProGet will add a vulnerability source name PGVC automatically, but it will not show under the vulnerability sources. It looks like after you enabled that, you added a new ProGet Vulnerability Center (which will default the name to "ProGet Vulnerability Central"). So the ProGet Vulnerability Center source should be left off and can probably be removed. That is definitely what was causing a duplicate vulnerability. Thanks, Dan