Hi all,

we tried to work on global and feed policies and we do have some questions regarding this topic. We are currently working on Version 2024.38.

If a feed policy is active, will the global policy also be evaluated when analyzing the packages in this feed? Or will the global policy completely be ignored?

Let's work with an example for our next question:
I have a feed called "NuGet". This feed contains the package "EPPlus 6.0.6" which has the license "PolyForm-Noncommercial-1.0.0".
In my NuGet policy i set this license as "Compliant" and in my Global policy i set this license to "Noncompliant".
Is it correct to assume that the package will by Compliant in the feed "NuGet" but should be Noncompliant in any other feed?
Because if I upload the package to another feed (which has no specific feed poilcy) the package is listed as compliant:

If I remove the feed policy, this package is shown as Noncompliant in this specific feed. But if I reupload or promote it to another feed it is shown as Compliant. So maybe this has nothing to do with the policies, but not sure.

In general we are just curious about how the policies interact with each other.

Thanks
Caterina

Hi all,

we are still evaluating if we should move from ProGet 2023 to ProGet 2024 and we noticed some missing information:
We are currently using pgscan to upload the SBOMs for our projects. We also provide the project-type (usually "application" or "library"). We provide this information because we are actively working with it. The SBOM on ProGet 2023 looks like this:

The SBOM of the same project after migrating to ProGet 2024 looks like this:

We lost the information about the project type which is not acceptable for us.

I thought that it might be a problem of the migration, so I explicitly used pgscan to upload an SBOM directly to ProGet 2024. Same problem. the project-type is Null. Then I thought, ok maybe it is a problem with pgscan in combination with ProGet 2024 so I used pgutil to upload an SBOM. Same problem. We lose the information about the project type.

Also the timestamp behaves different. The timestamp on ProGet 2023 is the timestamp of the creation of the SBOM and is always the same. The timestamp on ProGet 2024 is the timestamp of the download of the SBOM and is different each time I download the same SBOM.

Can you confirm this behavior? Or am I doing something wrong maybe?
Unfortunately, losing this information will definitly block our migration.

Thanks,
Caterina

Hi,

I have a question regarding the SCA & Build Restrictions of ProGet 2024 in the Basic edition.
We are still using ProGet 2023 because of the limitation for 1000 active builds.
Is this limitation only for the Package Analyzer?
Or will there be an error once i have 1000 active builds and try to create one more?
Or am I able to upload sboms for more than 1000 builds and have the information about used components but am not able to scan for issues?

Where exactly would this limit hit us? Because we do have more than 1000 active builds and there are new ones each day.
Would an upgrade be possible? Or is the limitation for 1000 active builds a hard limit?

Thanks,
Caterina

Hi,

it looks like the notifier is still being triggered if there are 0 issues in 2024.31.
Can you confirm this? Hoped it had been fixed by now.

Thanks,
Caterina

Hi @dean-houston,

thank you for your response. Using your provided template the webhook is working.

The webhook is being triggered several times, but the issues property always has an empty array:

If I have a look at this specific build, the issues tab does not show any issues:

Can you tell me why exactly the "issues opened on build"-notifier is being triggered by this build?
We do have a lot of this cases.

Thanks,
Caterina

Hi @stevedennis,

as mentioned in my initial post, no customizations have been made:

The package event notifier are working this way.
I also tried to use the template from your documentation (https://docs.inedo.com/docs/proget/administration/proget-notifications-webhooks), but we got the same error:

Hope this helps.

Thanks,
Caterina

Hi,

we are trying to introduce a new notifier in ProGet Version 2024.25 (Build 11).
We are already using a custom webhook which notifies us if a package has been added.
Now we wanted to create a webhook that notifies us if a issue has opened on one of our builds.

No special settings have been made, just basic selections. Using the default settings would be fine for first tests.
The documentation for this type of notifier says that it is being triggered after the ComplianceAnalyzer scheduled job has been run. So I did that, but afterwards I got an error on my notifier:

Accessing the same webhook with a package notifier works just fine, so it seems to be an issue with this specific sca event notifier.

Is it necessary to make specific settings for this type of notifier? Or can you confirm that there is an error?

Thanks,
Caterina

Hi @rhessinger,

sorry for the late response, this somehow slipped my mind.

Your suggestion looks good to me. The description is easy to understand and also the parameter name is very descriptive.

Thanks,
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,

I think uploading a SBOM should not modify other metadata of a build (e.g. Build Stage, BuildStatus). I also can't see a usecase where it would be necessary to updoad a SBOM for an inactive build. Even if you do not prevent it, it should not change the BuildStatus I guess .

For the duplicates: those are indeed two different builds. I can also see it in the database:

The difference here is Release_Number. If a build gets created via SBOM the Release_Number is NULL. If I use "Create Build" the Release_Number is empty. Both Build_Number are the same. None of it containes a whitespace.

Best,
Caterina

Hi @atripp,

to be honest, I am still confused. Let me explain my approach in more detail:

So I created a test project which does not contain any builds yet:

I want to add build 1.0.0 to this project. To do so, I upload an SBOM file containing the information about version 1.0.0. I also promote this version to the stage "Release":

Now the worst case scenario happens. After months someone uploads a different sbom with version 1.0.0 to this project. I can confirm that the information from the "new" sbom gets added. But the build is also moved back to the stage "Build":

I would expect that the build remains in its stage. But maybe you have a valid reason to do it like this?

So now I used "Create Build" from the dropdown to manually create version 1.0.0 again, which leads to two versions 1.0.0:

If I now upload a SBOM for version 1.0.0 only the first version 1.0.0 gets modified. The second, manually created version 1.0.0 remains unchanged.

Further, I created a version 2.0.0 manually using "Create Build". Then I uploaded a SBOM for version 2.0.0, which again results in two builds with version 2.0.0:

As far as I understood your explanation, uploading a SBOM should have added the information to the already existing build 2.0.0 instead of creating a new build?

You also said that the constraint for duplicates is <Project_Id, Release_Number, Build_Number>.
So for versions 1.0.0 the Project_Id as well as the Build_Number are the same. The Release_Number is empty for both builds (or not set):

Maybe that's a problem leading to having a build twice? But this seems to be the default when using pgutil to create and upload a SBOM. I am not really sure how this Release_Number property should be used and how it is set using pgutil.

But if this behavior is on purpose maybe you can again explain to me why?

Thanks
Caterina

Hi @atripp,

thank you for the clarification. I can confirm this behavior.

Thank you very much,
Caterina

Edit:

If I first use "Create Build" to create build 3.0.0 and afterwards "Import SBOM" to create build 3.0.0 I have two builds with version 3.0.0 in my project.
The same happens if I do it vice versa.

Hi,

there are two possibilities to create a build in a project in ProGet 2024.
I can select between "Create Build" and "Import SBOM".

I was interested in what would happen if I create a build with the same version twice.
Both of those options create a new build but with a different behavior.

If I select "Create Build" to create e.g. build 1.0.0 and I do this a second time I get an error:

If I select "Import SBOM" to create build 2.0.0 and I do this a second time, the first build gets deleted and overwritten I think. Because if build 2.0.0 is in another stage and I try to import the SBOM to my default stage, the build is available in the default stage and no longer in the other stage.

Shouldn't these two options behave the same?

If we use pgutil to import a SBOM we would prefer that previous builds would not be overwritten. It should no happen that a build with the same version gets created twice, but sometimes mistakes happen. In this case the previous build should not be deleted without a warning.

Can you please have a look into this szenario? Maybe we can also discuss what would be the best behavior for pgutil in this case.

Thanks
Caterina

Hi,

while comparing ProGet 2023 with ProGet 2024 I noticed that a project has an issue in ProGet 2024 but not in 2023.

In ProGet 2024 the project shows a warning for the package "DevExpress.Win.Gauges 21.2.7" (this package comes from a proxy-feed). The warning is "because of package status (unlisted, deprecated) is unknown, no license detected".
But if I have a look at the package the license is being detected and it has no vulnerabilities or other issues.

In ProGet 2023 the same project referencing the same package does not have an issue.

I hope I could make the problem clear, unfortunately the server won't let me upload screenshots for some reason.

Thanks,
Caterina

Hi @atripp,

the default behavior of the NpmDependencyScanner is to read the input file as well as all package-lock.json files found in the node_modules directory.

Rich and I had a longer discussion about this behavior last year (https://forums.inedo.com/topic/3934/pgscan-different-results-for-npm-dependencies/13).
Result of this discussion was to add "--package-lock-only" to be able to ignore the package-lock.json files in node_modules.

The code for this is already part of pgutil ('packageLockOnly'-property in NpmDependencyScanner). The only thing missing here is the possibility to set this property from the outside.

Thanks,
Caterina

Hi @atripp,

this feature is necessary for us because we have products where we are not able to access the version otherwise. But we want to have the according information about this project, so we implemented the possibility to read the version from a .dll or .exe.
It just extends the current functionality and I think it would also be a great addition for pgutil.

It is not limited to .NET since we were using System.Diagnostics.FileVersionInfo.GetVersionInfo() to retrieve the information in pgscan.

I think instead of 'identify' it is now 'builds scan'. It is a property which is necessary for sbom generation. So I would suggest that 'builds scan' and 'builds sbom' in pgutil should support this option.

Thanks,
Caterina

Hi,

I see that the Dependency Scanner for npm projects is able to handle "packageLockOnly" (like it was the case in pgscan). But I can't seem to find an option to set this flag from the outside.

Maybe this option has been overlooked? Or I am missing it?
I appreciate the help.

Thanks,
Caterina

Hi,

in pgscan it was possible to read the product name and version from a given file using --fileInfo (for 'identify) or --consumer-package-file (for 'publish').

I think this is missing in pgutil? Or am I missing something here?
It looks like the SbomCommand and the ScanCommand can only handle the properties --project-name and --version. But I can't see an option for a file.

Hopefully you can help me with this issue.

Thanks,
Caterina

Hi @gdivis

thank you for your response. This is what I was looking for!

Thanks,
Caterina