@gdivis , thank you very much. love this product so keep up the good work.

Hi @brandon_owensby_2976 , It sounds like you're on the right rack with troubleshooting; the issue is definitely on the server-side in this case, so I asked ChatGPT. Who knows if any of this is accurate, but... This is a very common situation with older versions of Bitbucket Server (especially pre-6.x / pre-7.x era, but even up to some 7.x versions in certain setups). The REST API (e.g. /rest/api/1.0/...) and the Git Smart HTTP protocol (/scm/.../info/refs, /git-upload-pack, etc.) are handled by different authentication filters in Bitbucket Server. Most likely you're using a Personal Access Token / HTTP Access Token (most frequent cause in older versions). In many Bitbucket Server versions (especially ≤ 7.17–7.21), HTTP access tokens were designed mainly for REST API and did not work reliably (or at all) for Git over HTTPS in many cases. As a workaround , you need to use a real username + password (or username + app password if 2FA is on) for Git operations We've seen similar in really old version of ADO, GitHub, etc, where API tokens wouldn't work for Git. Anyway, I would try that - at least from the curl side of things. And maybe upgrading will help as well. If it works, then you'll likely only be able to use a Generic Git repository with a real username/password -- and just create a special builds user which effectiveely acts like an APi key. Cheers, Steve

Hi @Stephen-Schaff, It seems pretty easy to add these up and display them on the screen! I suppose the "hard part" is the UI... A "Total" line doesn't seem to look right. And it seems like too little information to put in one of those info-boxes. "Total Size: XXXX MB" at the bottom just looks incomplete. Any suggestions? I'm struggling a bit to see how it could be displayed without looking a little out of place... and since it was your idea I figured I'd ask ;) Thanks, Steve

Hi @Julian-huebner_9077 , Here's some information on file storage paths: https://docs.inedo.com/docs/proget/feeds/feed-overview/proget-feed-storage Long story short, if you modify Storage.PackagesRootPath under Admin > Advanced Settings and move your files as needed, then it should work just fine. Thanks, Steve

Hi @jstrassburg_8563, if the resolved version that npm i underscore chose was released in the blocking period, the npm command would 400? If you have "Block Noncompliant Packages" enabled (which we generally don't recommend) and you have a rule that new packages are complaint, then the npm command would most certainly give some kind error. You will probably see a 400 code, but I don't think it will display the message that's sent by ProGet (i.e. "package blocked due to...")? The real issue comes with a large dependency tree, and it'll be hard to know what exactly the issue is. As such, we recommend running pgutil builds scan/audit in your CI/CD pipelines instead of blocking. This will produce a much easier to understand report, and even allow you to bypass issues reported on a case-by-case basis. Thanks, Steve

Hi @sigurd-hansen_7559 , Thanks for pointing me to the repository; I was able to reproduce this, and it will be fixed via PG-3194 in the next maintenance release (scheduled for Friday). Thanks, Steve

Hi @toseb82171_2602, In Docker, images must have a namespace. When they don't, the Docker client will transparently append library/ to those namespaces. In general, this behavior is not desirable, and it's recommended to use library/python or, in a ProGet context, myproget.corp/mydockerfeed/library/python. That said, there is a setting on the connector that may help resolves such images, but these images can be problematic even with that. AS for extending the trial, no problem - you can actually do this yourself on my.inedo.com, on the day of expiry. Of course, please contact us if you run into any issues or have licensing questions. Thanks, Steve

Hi @jeff-williams_1864 , We do not provide instructions/guidance for installing ProGet on Kubernetes / OpenShift. However, since it uses Docker behind the scenes, it is supported and works fine, and many users deploy ProGet to Kubernetes. Here are the instructions for Docker: https://docs.inedo.com/docs/installation/linux/docker-guide Let us knkow if you have any questions or run into any issues/difficulties. Thanks, Alana

Hi @nachtmahr, Yes, that's what I would reommend doing -- using the internal storage path. Just make sure to NOT select the option to delete the files and make sure to select "search subdirectories" so everything will be imported. Cheers, Steve

Hi @henderkes, No problem! Both these issues are expected to be fixed in this Friday's release of ProGet 2025.18. Thanks, Rich

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!