Hello again @dean-houston,

I don't know if you have a certain way of working with open-source contributions, but I've created a Pull Request to add more Feed properties for pgutil feeds properties set and pgutil feeds properties list

https://github.com/Inedo/pgutil/pull/39

Best Regards
Nils Nilsson

Hello @atripp ,

I've now had a chance to try out the new version of PGUtil and the changes are working great.
Thank you for your assistance :)

Best Regards
Nils Nilsson

I've had a chance to test the new version of pgutil now and it works perfectly, thank you.

Best regards
Nils Nilsson

Hi @dean-houston .

Thank you for your response, it makes sense that you wouldn't prioritize this, as I assume my organization is quite an outlier where we need to have one policy for every application that utilizes ProGet.

Best Regards
Nils Nilsson

Hi @dean-houston

Thank you for the detailed response.

I'll dive into the properties set and retention create commands to see if the current implementations already cover our automation usecase.

Fair point about the API, then I'll continue to default to using PGUtil so that you at least have one less user depending on the API in case you want to supercede/deprecate it in the future :)

Best Regards
Nils Nilsson

Hello!

I'm working on setting up an automated configuration of feeds for new Products/Projects in my organization.

When reading the documenation for Create Feed I noticed that the API which expects a ProGetFeed.cs object supposedly would allow you to set many extended options for a feed, such as Connectors, or PackageStatisticsEnabled. ProGetFeed.cs
As far as I've been able to tell, none of these options are available for setting when creating through PGUtil which basically only allows you to specify Name and Type, and soon also Group as we discussed previously here.

My first question is if this disparity in options between API / PGUtil is intentional and that advanced usecases should primarily aim to use the API for interfacing?
Or if there are options available in PGUtil that maybe remain undocumented in helpstrings/web docs?

My follow up question is if you intend to/would consider extending the options available in PGUtil?
If you do not want to laden PGUtil with a ton of options, would it be possible to implement a "New Feed Template" so that the default value of at least Feed Features Downloads, Deployments, Usage, Software Component Analysis could be changed to Enabled instead of Disabled?

Best Regards,
Nils Nilsson

Hi!

I'm working on automating the setup of new "workspaces" in ProGet whenever my organization onboards a new product/project.

I've been reading the documentation for a way to create a new Package Policy without the use of Web GUI actions, but turned up empty handed.

Is there a already way that I haven't found? If not, is that something you'd be willing to add to your backlog to implement?

If it is something you would consider implementing, my request is that you can set the Risk Profile during creation, in addition to the three fields available when creating in the Web Gui.

Example:

pgutil security policy create \
--Name="New Policy" \
--Priority=<'Default' | 'Before Global' | 'After Feed'> \
--Feeds="nuget-feed, maven-feed, npm-feed" \
--RiskProfile='{ \
    "Exposure" : "<External | Internal>", \
    "Interface": "<Web Browser | Unspecified>", \
    "Outage"   : "<Unacceptable | Disruptive | Tolerable>", \
    "Breach"   : "<Unacceptable | Disruptive | Tolerable>", \
    "Tampering": "<Unacceptable | Disruptive | Tolerable>" \
}'

Best regards,
Nils Nilsson

Hi @atripp

That's great, thank you :)

The API/command for creating projects should be updated to allow you to specify:

• Group
• Description
• Feed

https://docs.inedo.com/docs/proget/api/sca/projects/create

So that creation can be controlled by a central process and not require manual GUI operations

Best regards
Nils Nilsson

Hello!

I wish to be able to create new feed & project groups programatically so that it can be automated.

My suggestion is that it's either
a) Exposed as a new endpoint/command
b) If a non-existent feed group is provided for an endpoint or a command, like /api/management/feeds/create https://docs.inedo.com/docs/proget/api/feeds/create it will create the feed group provided the token used has sufficient permissions.

Currently scenario b will return code 400 with the message "Feed group <group> not found." and create an ungrouped feed.

I tried to jack into the /administrations/feeds/feed-groups/edit endpoint used by the website but ended up just being redirected to the login page.

Best Regards
Nils Nilsson

@gdivis

Hello!

I've tested containers audit a little bit and it seems to work well at first glance.
I could easily differentiate between a vulnerable image and one with no vulnerabilities, both from output and exit code.

Thank you for your work! :)

// Nils

Hi @dean-houston

That doesn't solve what I want to test.
My scenario is more about testing a webhook to make sure that ProGet can reach the host and that the destination receive a well formatted message.

I don't completely buy that it's impossible to send a notification without real data, as it should be trivial to send some dummy data when using a "Try-out" button.
But I understand that if I'm the only one who has ever wanted this feature it wouldn't make sense to implement it.

Best regards
Nils Nilsson

Hello!

When I'm adding new notifiers I'd like to be able to send a test message to check that it works as expected.

Best regards
Nils Nilsson

Hi @apxltd

I think this looks like a good solution, as it would simultaneously allow us to disregard noise as the new risk profiles for feeds/projects allow us to do, and introduces more control mechanisms so that I can differentiate our various departments/deliverables.

pgutil containers audit would solve most instances were we want to prohibit image download. And should easily fit into CD processes to prevent running vulnerable containers in production, which is the most important part.

I don't have any additional opinions at this time, instead I will eagerly await more news/time estimate for when this feature will start rolling out :)

Best regards
Nils Nilsson

Hello again,

Assigning tasks with Projects scoped permissions do not seem to be functioning as expected.

I can not assign a group my "Manage" task for a feed/project group, The task includes only privileges marked as scopable

Creating a new task with only Projects privileges experiences the same issue

If I restrict a task to only privileges that were scopable in 2025 it again allows me to assign scoped permissions

I've also tested individually the 4 privileges under the Projects category [Manage, Resolve Issue, Upload Sbom, View] and the issue is the same for all/any combination.

This is running 2026.1 (Build 14) from the Prerelease Feed, although the issue seemed consistent in earlier Release Candidate 12, as well as 2026.1 in the Production Feed

Best Regards
Nils Nilsson

Post moved to Project-scoped permissions not working as expected

@atripp

Thanks,

I deployed 2026.1-rc.12 in my lower environment and it seems to resolve the issues I was facing.

best regards
Nils Nilsson

Hi,

Thanks for investigating.

You're right that UserNotFoundException turned out to be a cache issue.

Eagerly awaiting the fix.

Regards
Nils Nilsson

Service came online a few hours after the rollback, the error above persists though and LDAP integration for Task/Permissions still isn't working.
Rollback also didn't restore my scoped permissions, all of those groups used to have different scopes.

Additionally after doing a rollback to 2025.27 ProGet can not start the web service, with this error in event viewer

Exception:
Inedo.ProGet.Web.Security.UserNotFoundException: Exception of type 'Inedo.ProGet.Web.Security.UserNotFoundException' was thrown.
  at Inedo.ProGet.WebApplication.ProGetHttpModule.AuthorizeRequestAsync(AhHttpApplication app)
  at Inedo.Web.InedoHttpModule.Inedo.Web.IAhWebModule.AuthorizeRequestAsync(AhHttpApplication app)
  at Inedo.Web.AhWebMiddleware.InvokeAsync(HttpContext context)
  at Inedo.Web.AhWebMiddleware.InvokeAsync(HttpContext context)
  at Inedo.Web.AhWebMiddleware.InvokeAsync(HttpContext context)
  at Inedo.Web.AhWebHost.<>c.<<Configure>b__22_0>d.MoveNext()
--- End of stack trace from previous location ---
  at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.ProcessRequest[TContext](IHttpApplication`1 application)