Topics created by caterina

Hi @caterina , This will be fixed in the next maintenance release via PG-2829. I just checked in the change. I made a mistake when making the original change, and used the ProjectBuildId instead of the ProjectId when validating the if other builds exists. So it works if the Ids match perfectly (like when I tested it). Note this only impacts the UI, and we don't really expect users to create builds via the UI. Thanks, Alana

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

Hi @caterina, No problem, thanks for getting back to us. We have an upcoming release of pgutil that will include this flag. We also have improved this command a bit by allowing you to use the working directory which will search for the right files instead of --input having to specify the path to the file (although you still can). It will now also automatically audit the scan directly after, you can use --noaudit to skip the audit. We should have those updates pushed this week. 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