Hi @koksime-yap_5909, No problem! Happy to help! Thanks, Rich

Hi @Julian-huebner_9077, This error is occurring while ProGet is trying to generate the "base url". There are a few inputs that go into this: Admin > Advanced Settings > Base URL X-Forwarded Headers, set by a reverse proxy like ngnix If any of those have an invalid host name (which is what the error is indicating), then you'll get this error. In most cases, it's a typo in the X-forwarded headers. Thanks, Alana

Hi @dwynn_6489 , I was able to reproduce this issue; the issue is that the package's license declaration specifies a license file of package/license.txt, but that file does not exist in the package. We will improve this error message via PG-3199 in the upcoming maintenance release, but in the meantime, the only workaround is to manually assign the license under SCA Licenses. The new version of ProGet will include a direct link to that page for convenience. The Purl you'd need to add is as follows: pkg:npm/%40progress/kendo-charts@2.9.0 Hope that helps, Alana

Hi @spencer-seebald_1146 , I was able to identify the issue. When you visit the URL in ProGet, then ProGet will visit this URL (slightly trimmed) with the appropriate authorization header: https://libraries.cgr.dev/javascript/..../lodash/-/lodash-4.17.20.tgz However, that URL will issue a 307 redirect to the following: /artifacts-downloads/javascript/namespaces/15f7d141c3b76b85/repositories/.../downloads/ABmYrfCH......KpxO1ducu3xmMRtw== ProGet then follows the redirect, but does not send the authorization header. And thus, a 401 is issued. This is actually the default/expected behavior in HttpClient (i.e. the library in .NET we use) and most clients in other languages (Java, Go, Ruby, etc.) as well. Of course it can be worked-around by disabling auto-redirect and implementing yourself to follow the URl with the same header. But that's not so common and, as such, it's not a common practice for servers to issue redirects that require authentication; we see other services handle the redirect using some kind of token in the querystring. On our end, this has not been an issue to date. This is logic is buried pretty deep and it's not an easy fix without changing code everything relies on. I'm kind of surprised npm and pip override the default behavior in the fetch() and requests libraries. Anyway, it sounds like you can make a change on the private repository server code... so I would here would be to just disable authentication on your artifacts-downloads endpoint. I mean that URL is basically authenticated anyway.... it's so long (I stripped like 1000 characters) that it's basically a password. Thanks, Alana

@atripp I'm sorry, you're absolutely right. It does indeed work with version 2025.18. I simply forgot to apply the license key with pgutil before attempting to create the API key. Then I confused myself more when 2024.39 wasn't throwing the same error (because I was still setting the license with the --LicenseKey Inedo Hub option). For anyone stumbling here in the future like me, here's what you need to do to apply the license key and create an API key with pgutil: pgutil sources add --name=Default --url=http://localhost:8624 pgutil settings set --name=Licensing.Key --value=LICENSE-KEY-GOES-HERE api_key=$(pgutil apikeys create system)

I noticed this mechanism when I migrated from Artifactory to Proget in my company but only able to comment now. I would say thank you very much for you guys for addressing this, especially since it is done before the migration in my company.

Hi @Sigve-opedal_6476, I just tested with a 3GB .iso file and could upload without issue. When you tested locally on the same workstation, did you use http://localhost or the normal URL? Chances are the normal URL will still go through the firewall, even when on the same workstation. I would check in with your IT team and see if they are blocking .iso upload files to your ProGet instance. Thanks, Dan

Hi @dafex36959_6595, Based on the exceptions, this is most likely due to an invalid character in the display name field or in an associated group. This is due to a bug that is buried in a third-party library that is based on another library that is based on an some RFC standard.... but who knows. It's been a known issue for years, and presumably end-users of this library (it's the #1 library for LDAP on .NET) have simply worked-around the issue by not using those characters in domains, groups, etc. I'm afraid it's just not something we are able to fix. We really hate giving this response, but we also cannot go down the rabbit hole of trying to fix the library to support this edge case -- Unfortunately, this is a "limitation" of our software and recommend working around the issue by either removing the unescapable character (typically a '# or a ',') or try using ADv4 and override the display name to use a different field and/or group discovery. Thanks, Dan

Hi @jonathan-werder_8656 , We actually don't have any Azure-specific recommendations (or Amazon, GCP, or any host really) -- so just the normal Windows or Linux (Docker) guidance would apply. Happy to clarify that in the docs if you can think of a good pace to put that :) Thanks, Alana

@atripp thx for the info.

@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