Hi @tyan-yin_2201, It looks like it's only supported on FeedCommand -- I'm not entirely sure why. It appears to be settable when calling the HTTP API however. We ought to be able to add it relatively easy, but can you share the use case? It's also good to know why someone would want to explicitly set an api key from command line (most tools don't seem to support this). -- Dean

@dean-houston hi, problem fixed. thank you

Hi @mayorovp_3701, This is a bug you should definitely report to GitLab -- it's clearly required by the API and all other registries support it. Without that API defined, we have to "make guesses" based on undocumented conventions (i.e. /v3-flatcontainer/{id}), which causes headaches down the line. That's why there's an API contract :) I don't know how/why it works with dotnet sdk -- perhaps it's using a different endpoint, or maybe it's not actually working and just going to NuGet.org. Whatever the case, it doesn't make sense for us to build workarounds for easily-fixable bugs on GitLab when other vendors seem to follow the API contract. -- Dean

@jonathan-werder_8656 great point, we'll add that to our list to document! Thanks for pointing it out

Thanks! This will be fixed in today's release of ProGet 2025.17 as PG-3187.

Hi @MellowOak, A quick background on how ProGet handles malicious packages. Malicious packages are treated as vulnerabilities in ProGet. That means that a malicious package will show up as an unassessed vulnerability (since they rarely have a CVSS score) and can be assessed, analyzed, and blocked like any other package with a vulnerability. With that said, most of the time, this blocking is not needed because as soon as they are identified as a malicious package, the public feed will have already removed the package. The only time they are really caught in ProGet is when they have already been downloaded and cached. In ProGet 2026, we are working on a better way to store and distinguish malicious packages separate from vulnerabilities. To answer your questions: All paid editions support the ability to block malicious packages via policies. Please refer to our License Restrictions documentation for edition limitations. The best configuration for blocking malicious packages is to block all unassessed vulnerabilities. This requires an administrator to review unassessed vulnerabilities regularly on the Reporting & SCA -> Vulnerabilities tab. Yes a block can be overriden by: Add an exception in the policy for that package and version A ProGet admin can set the package status to Always Allow It could be manually downloaded from the ProGet UI Inedo's aggregator runs mutliple times a day to pull from all the vulnerability and malicious package sources and creates a custom compresssed database file. As long as ProGet has access to cdn.inedo.com, ProGet will then download that file nightly update it's database. It can be updated under Scheduled Jobs -> Vulnerability Database Updater. There are multiple ways to gain visibility, but the easiest is to use ProGet's notifier feature to be alerted when a vulnerability to a pacakge. Hope that helps to answer your questions! Please let us know if you have any other questions. Thanks, Dan

Module streams are a little complicated for package maintainers, because the metadata has to stuff certain packages (all from the same folder) in one stream while others in the other. The end result is really nice though, because it makes switching versions of packages trivial. Sounds like it's not supported then. Unfortunate, but understandable.

Hi @koksime-yap_5909 , As long as the cluster can access the internet (our activation server), the license key should be auto-activated without noticing. This document explains the activation process a little further: https://docs.inedo.com/docs/myinedo/activating-a-license-key Help that helps, Alana

Thanks for the additional feedback @ben_0435 Mostly for my notes, in the five months since @Jonathan-Engstrom shared Microsoft's initial efforts at supporting a WinGet private repository (i,e. winget-cli-restsource), it looks like they've already abandoned their efforts. Last code commit June 26, 2025 Last closed issue July 4, 2025 So at this point, my assessment remans the same: WinGet is basically just the Windows Store, except you it run from the Commandline and has a ton of shady, unvetted packages from internet randos I feel someone should totally Polymarket whether Microsoft will finish WinGet --or-- just create yet another package manager that's somehow more BingAI friendly. I'm looking for a solution to titrate that scary giant community repo so it can be managed better... I want upstream.. but only select things. I want to publish apps as necessary for the public/private feed. I believe that solution is called "Chocolatey"

Hi @rhessinger, I just tested the pre-release and the build now works as expected. Thanks again for the quick fix!

Hi @atripp Once again thanks for the quick fix. I was actually worried that something got messed up in our database, while trying to fix the duplicate package issues, but so far everything looks good. Also I should probably start making it a habit of stating that we're still on SQL Server, instead of having you guess. ;)

@kinedax339_3276 great news!! Appreciate the help

Hi @rhowell_8827, Looking at the code in both ProGet and pgutil, it looks like that simplified upload API only supports the distribution argument. We'll add component in the same manner via PG-3172 in an upcoming maintenance release -- ideally next Friday (should be relatively simple). Thanks, Alana

Hi @steviecoaster , Nice suggestion; I made a small change and you can now do pgutil apikeys create feed --feed=* to create such a key. Thanks, Alana

Hi @steviecoaster , FYI - I just a note to the license restriction page; it looks like we don't mention the restrictions on other APIs (delete, scan, etc), but it's something we'll consider next round of docs refactoring. I know we do call it out on the main documentation pages though.

@atripp Hi, thank you very much.

Hi @jonathan-erlich_0694 , Based on the stack trace, there's something wrong with the data being returned via the API from the remote connector. Specifically, one/more of the version objects being returned is missing a name or version property, Based on the URL, the invalid data is at the {repository-root-url}/browser-sync. Here's what it's supposed to look like, based on the public repository at least: https://registry.npmjs.org/browser-sync Thanks, Alana

@atripp now is working :) Thank you!

Hi @parthu-reddy , This can particular occur when there are some issues with the database, such as outdated statistics or highly-fragmented indexes. This script should help fix this: https://proget.inedo.com/endpoints/Public/content/DefragmentIndexesWithRowCount.sql It coudl be something else, but the query that page uses seems to be mostly effected by those. Thanks, Alana

Hi @parthu-reddy , This error means that PowerShellGallery.com is taking too long to respond to that query. You can try increasing the connector timeout; it's 10 seconds by default. Maybe try 20 or 30 seconds? Just a guess. Unfortunately the PowerShellGallery seems to be in a state of abandonment these days and it performs really poorly. It's pretty buggy too. I would consider using a multi-feed, package-approval process to pull packages so you don't have to rely on the gallery's API. Cheers, Alana