Topics created by caterina

Hi @atripp, I was able to test the new version of ProGet and there still seems to be a weird behavior. Again I am using my test-project 'BuildStageTest'. I deleted all existing builds to give it a "fresh start". Creating a build via SBOM upload seems to be working fine. This way I created build 1.0.0: As you can see, there are no other builds in my project. If I try to create the same version via "Create Build" you display an error (which is great): But if I try to manually create build 2.0.0 I get the same error even if the build is not existing: I thought that there might be an issue because build 2.0.0 already existed in previous tests. But I deleted all builds as you can see from the ui and the database screenshots above. So I also created a completely new project and tried to manually create builds. But for some versions i do get the error message (I was not able to manually create 1.0.0, 2.0.0, 4.0.0, but some other versions were working just fine): Are you able to reproduce this behavior? Thanks, Caterina

Hi @atripp, thank you for the clarification. I can confirm this behavior. Thank you very much, Caterina

Hi @caterina, We are working to add this back, but the hold up has been trying to properly document this. Here is our thoughts, but wanted to get your feedback. We are looking to change the parameter name to --do-not-scan-node_modules with a command line description of: Do not scan the node_modules directory when scanning for package-lock.json files What are your thoughts on this? Thanks, Rich

Hi @caterina, We're a bit concerned that this is too specific for your usecase, and we're really struggling documenting it. Instead of doing this, we're thinking it might just make more sense to run (Get-Item 'C:\path\to\file.exe').VersionInfo using PowerShell and export these into variables instead. For Example: $versionInfo = (Get-Item 'C:\path\to\file.exe').VersionInfo $version = if($versionInfo.FileVersion) { $versionInfo.FileVersion} else { $versionInfo.ProductVersion } $productName = $versionInfo.ProductName pgutil builds scan --input=myApplication.csproj --project-name$productName" --version=$version Thanks, Dan

Hi @gdivis thank you for your response. This is what I was looking for! Thanks, Caterina

Hi @rhessinger, thank you very much! We will just wait for the next release and I will come back to you if we encounter further problems. Thanks, Caterina

Hi @caterina , Thanks for checking; I was able to reproduce this; it seems to be a regression.... we'll get it fixed via PG-2795 in next week's maintenance release. Thanks for letting us know. Thanks, Alana

Hi @atripp thank you very much, downloading the latest version solved my issue. Best, Caterina

Hi @atripp, thank you very much for clarifying this. We are not able to update to ProGet 2024 yet, so I will just resolve this issue manually for our projects. Thanks, Caterina

Hi @gdivis, thank you very much for your response! We are really looking forward to the finalized version :) Thanks, Caterina

Hi @gdivis, thank you for your response. I think it is a little bit confusing in general. Just for clarification: We are not using any symbol packages at all (neither .symbols.nupgk nor .snupkg). We are only embedding PDBs right into our .nupgk files. But it would be nice to strip the PDBs on package download. We can achieve this on ProGet by activating the symbol server for the legacy format. I was just confused on why I have to use "legacy" for this approach since it is also standard to embedd the PDBs instead of using symbol packages. I guess normally it won't be necessary to enable a symbol server if you are using embedded PDBs. But we want to see the symbol information for our packages and we want to be able to strip the PDBs on download. It seems to be more of a hack to use the legacy symbol server for this but we achieve our goals doing so. No need to file a bug for this. Thank you, Caterina

Hi @rhessinger Thanks, but I don't think we will need a pre-release. The remaining problem is basically a convenience issue (getting from the report to the package's info page with one click). Everything else seems to work as expected with the latest pgscan version.

Hi @caterina, Here is the final solution: When using the auto type and scanning for NuGet and npm dependencies: The default configuration should be to omit dev dependencies and scan the node_modules directory When using the npm type and a package-lock.json file is specified The default is to only scan the specified package-lock.json file and omit dev dependencies When using the npm type and a package-lock.json file is not specified The default configuration should be to omit dev dependencies and scan the node_modules directory Each of these options would have an optional parameter to include the dev dependencies (--include-dev) Each of these options would have an optional parameter to ignore pacakge-lock.json files found under node_modules (--package-lock-only ) This has been implemented in pgscan 1.5.6 which I will be pushing shortly, and these options will be added to BuildMaster 2023.2. Thanks, Rich

Hi @Dan_Woolf, so it seems to be a long known issue: https://github.com/NuGet/Home/issues/3116 Thank you for your help. Caterina

Thanks! Merged and released.

Hello, This is most likely related to PG-2395 (ProGet 2022.30 fix) and PG-2390 (ProGet 2023.9 fix). We added support to handle when OSS Index removes vulnerabilities from their list. Unfortunately, this has brought to light the unreliability of the data returned from OSS Index. It looks like vulnerabilities are constantly removed and re-added, which caused assessments to be cleared out on vulnerabilities. In PG-2395 and PG-2390, we have updated ProGet to only add a comment if we see that OSS Index deleted it. This way the assessment is not lost when OSS Index removes the vulnerability. Thanks, Rich

Hi @caterina , This behavior is intentional, but not ideal. It should only navigation - such as the "Usage & Statics" page on a package, or the "List Projects" page which has a "Latest Release" column. As long as the Release is active, you'll still see new issues come up. That's really what determines if a release is scanned or not - Active or not. The reason for this... an SCA Release's "Release Number" is a free-form field, which means there are no sorting rules. So we can't practically/easily determine what the "highest" number. Instead, we just use the order in which it was created for display purposes. Thanks, Steve