Posts made by atripp

Hi @it_9582 ,

Unfortunately I'm not really sure what your script is doing or how to fix it... but I will describe the server (ProGet) behavior.

Unless you allow Anonymous access on the endpoint, ProGet will respond with a 401 when you access a URL without any authentication information (API Key header, Basic credentials). That's what the message you are sharing appears to do.

So if you're getting that message, then I guess the username/password isn't being sent? I really don't know what --auth-no-challenge means or does.

Thanks,
Alana

Hi @it_9582,

I'm afraid this requires a code change and an external database will have no impact.

Thanks,
Alana

Hi @mikael ,

We have no plans for this and honestly, I wouldn't recommend setting up a tool like ProGet in this manner.

Outside of some very specialized use cases (like setting up labs for testing, or nodes in a ProGet Enterprise Edge Computing Edition) there are no benefits. Only headaches.

It might sound fine on paper, but every company that has set it up this way has regretted it. And you will to. The reasons they want "fully reproducible configuration" is usually:

• so we can store configuration in versioned code
• so we can easily replicate it in a testing environment
• so we can easily migrate/move to a new server

Those seem nice, but it totally fails in practice.

First, you can't "rollback" most configuration. Say you fat-finger a configuration file and delete half your feeds. There go all your packages. And when you realize you've got gigabytes/terabytes of content to deal with, plus all the metadata in storage, this is a huge headache.

The configuration you can make idempotent (say, permissions/users) is so much more a pain to work with than a UI. Again, more error prone you lose all the benefits of visual cues, input verification, etc. You fat-finger the wrong setting, and you get some obscure error instead of a helpful red box next to the text box.

The regret comes in realizing they've created a buggier environment that isn't properly tested, and is somehow less "portable" than an ordinary installation. A year later, when the new team comes in, they usually have to figure out how to "undo" it -- and you can probably guess why we need to get involved to untangle the mess.

Thank,
Alana

Hi @it_9582,

It's certainly possible :)

However, given the risk associated with the change, it could only happen in a Major Release. This would require editing a lot of code and trying to track down everywhere we might have trimmed/restricted to 200 characters.

I can add it this to our roadmap for consideration, but note that ProGet 2026 hasn't been targeted for a date yet, let decided what features we'll do.

I just want to be realistic about the timeline - let us know if you'd like to consider it. It hasn't come up in the very very many years this feature existed, so we're not even totally sure if we'll do it (if it's too much code / too much risk / too close to the deadline / etc).

Thanks,
Alana

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 @it_9582 ,

I'm afraid this is a long-standing (since we first introduced the feature) limitation on the name. It's not changeable/configurable and would require a nontrivial code change to lengthen.

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

Hi @jlarionov_2030 ,

PG-3133 (which allowed pgutil settings to run without a license key) was applied to ProGet 2025.12 so I don't think it could have worked in ProGet 2024.39.

There were also no changes from ProGet 2025.12 to 2025.18 that would have caused this, and it works fine for me.

Are you sure you're running the pgutil settings command first to apply a license key?

Just based on the logs, it doesn't say...

Thanks,
Alana

Hi @aristo_4359 ,

This will happen from time to time and there's no great solution to fixing it.

The underlying issue is simple actually; the source data is incorrectly coded, and systems like PGVD that rely on that will display incorrect results.

Since sources routinely update data (and they may fix this... if you ask), PGVD will also update the ingested data. So it becomes quite complicated to try to "override" incorrect data, even though it's so obvious from reading the description and looking at it.

Without getting into too many details, here is how they encoded this at the source:

"database_specific": {
   "last_known_affected_version_range": "< 0.19.3"
}

Compare this to another vulnerability at the same source, and you will see this is the correct encoding:

{
   "last_affected": "2.0.13"
}

Given the infrequency that this happens, and the fact that it's an old, low-risk vulnerability (we would rate this as a "2 out of 5" on our upcoming scale FYI), we don't think it's worth worrying about.

Thanks,
Alana

Hi @spencer-seebald_1146 ,

Thanks for putting all the details together, this is really helpful! In theory, what you're doing should work... and I don't know why it's not. But it sounds like it'd be "trivial" to reproduce in a debug environment, so let's start there :)

All we really need are credentials. It looks like your end-user opened a ticket on this issue as well (EDO-12512), so I will just add your email to that ticket and respond there with the same request.

Once we have credentials, we'll try reproducing/fixing and hopefully get this working in no time :)

Cheers,
Alana

Hi @geraldizo_0690 ,

Thanks! And we appreciate your ideas/suggestion and detailed guidance on how to implement it.

It seems really simple and should be available in the upcoming maintenance release (next Friday) via PG-3196 -- we can also let you know when a prerelease is available if you wanted to try it sooner than that.

Cheers,
Alana

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

Hi @jonathan-werder_8656,

Oooh that's definitely outdated, thanks for pointing that out! Perhaps we should just delete that article.... but I'll see if we can salvage it.

If you're setting up a new instance of ProGet, that article is not for you -- that's helping you migrate an existing instance. For a new instance, I would just do a standard Windows or Linux installation (use the Embedded database in either case) - there's nothing special about Azure.

For migrating... at this point (i.e. ProGet 2025+), I would just set-up ProGet on the new server using PostgreSQL (the default configuration). Then, export your database from the old server and import it into the new server.

You'll have to deal with the Package Files as well, which is discussed in this (slightly outdated) Migrate an Existing ProGet Installation to a New Server article.

Anyway we'll add these to the list, but let me know if you have any questions in the meantime.

Cheers,
Alana

Hi @rie_6529 ,

There is not -- this is not an action that should be performed regularly at all. It's more a troubleshooting thing that should only be done after some data problem.

If you find yourself having to run this often, it's indicating there's some other issue. In years past, no one really noticed this (and it didn't have any side-effects), but since we added Integrity Checks, the bad data is a lot more visible.

So it'd be best to troubleshoot that and see if we can correct it.

Thanks,
Alana

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

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

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

Hi @kquinn_2909 ,

The "Recent TeamCity Builds" page should show a list of builds in the selected TeamCity project; it's a bit tricky to troubleshoot, but BuildMaster is essentially querying for builds using this locator string: defaultFilter:false,project:{Uri.EscapeDataString(project)}&fields=build(id,number,status,state,webUrl,startDate,buildTypeId)

Might be easier to see in the source code:
https://github.com/Inedo/inedox-teamcity/blob/master/TeamCity/InedoExtension/TeamCityClient.cs#L63

I believe the Project ID is being used, which in your case would be WebProjects_Replicator. I think the name would be "WebProjects Replicator". Though I'm not totally sure.

What builds do you see on the TeamCity side of things?

Thanks,
Alana

Hi @jw ,

Thanks for finding this; we'll get it fixed via PG-3180; it was problem when updating the vulnerability database and related to the case matching again. Hopefully this is the last place.

Thanks,
Alana

@kinedax339_3276 great news!! Appreciate the help

Thanks @kinedax339_3276, that was really helpful!

Easy fix to the regex, and I made sure the following work

• http://localhost:8624/cargo/pants/1/a
• http://localhost:8624/cargo/pants/2/cc
• http://localhost:8624/cargo/pants/3/s/syn
• http://localhost:8624/cargo/pants/an/yh/anyhow

Before, the first two returned the same 404.

Anyway this change should be in image 25.0.17-ci.7, which is building now! hopefully this will do the trick

@kinedax339_3276 thanks for checking!

Maybe it's a similar issue.... but honestly I've never used /crate before myself. There's a lot of overhead in figuring all that out for the first time.... so if you can find the URLs being invoked I could probably track it down really easily.

Is ther ea verbose mode we can see that shows urls ?

Here are our internal API notes on the implemented endpoints:

GET /config.json [CargoIndexHandler]
- generates a config.json file
  - "dl" - download URL for crates
  - "api" - API base url for the Web API
  - "auth-required" - boolean indicating if authentication is required to access the registry.
    - This is determined by if the feed has anonymous access for Feeds_DownloadPackage.

GET  /crates/{packagename}/{version}/download [CargoIndexHandler]
- Downloads a crate
  
GET /{prefix}/{packagename} [CargoIndexHandler]
- Downloads basic package version information
- Not true JSON, but each line is a JSON object representing a package version

Maybe it's that last one, with the {prefix} , since those were wrong elswhere. Maybe the matching regex is off?

    [GeneratedRegex(@"^(1-2)/(?<1>[^/]+)$|^(3)/./(?<1>[^/]+)$|^(?![1-3]/)../../(?<1>[^/]+)$", RegexOptions.ExplicitCapture)]

Cheers,
Alana

Hi @kinedax339_3276 ,

It looks like this is an error with the sparse index parsing for short names (e.g. a goes to
https://index.crates.io/1/a, cc goes to
https://index.crates.io/2/cc, syn goes to https://index.crates.io/3/s/syn, etc). Easy fix, we'll get it via PG-3177 in the upcoming maintenance release (Dec 19).

Or you can use the prerelease container image (25.0.17-ci.5) which is being built now.

Thanks,
Alana

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.

Hi @steviecoaster ,

The pgutil security features are brand new API endpoints and we haven't had a chance to document them yet. Like other new API endpoints that make ProGet easier to manage, we decided to make the new feature only available for paid editions.

Our product management philosophy is that core functionality (curate open-source packages from public repositories, centrally manage packages and containers) is available in free edition, and others are in paid edition.

Thanks,
Alana

Hi @udi-moshe_0021,

Thanks for clarifying.

In this case, then someone may have disabled package caching on the feed or deleted the package using the "clear cache" button, a retention policy, or manually. That is the most likely scenario here.

There may have also been an error adding the package to the feed (file system error, etc), although those are very rare and would have been logged under Admin > Diagnostic Center.

Thanks,
Alana

Hi @udi-moshe_0021,

I'm afraid we don't have enough information to help troubleshoot, but I'll try to explain how ProGet works behind the scenes.

If you have package caching enabled (the default), then packages downloaded through ProGet will be automatically cached. They will still show up with the "remote" icon, but they will be stored on the ProGet server. You'll be able to tell that they're cached (instead of remote) because there will be a "delete cached package" option.

You can verify this behavior by simply downloading a package from the ProGet UI. It will cache the package. The same link/url is used by the npm client to download a package file.

So why is a package not cached then? The most likely case is that the npm client already had it internally cached, and thus it was never requested from the server. You may also have a scenario where cached packages are deleted with a retention policy.

Thanks,
Alana

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

@pmsensi sure thing!

2025.16-rc.1 should be available now.

Here's how to download it:
https://docs.inedo.com/docs/installation/windows/inedo-hub/howto-install-prerelease-product-versions

Hi @pmsensi

Are you able to easily test a pre-release container? I wasn't sure if you're on Linux/Docker, but I just made a code change (PG-3164) that should show up soon as inedo/proget:25.0.16-ci.1

Let me know if you're able to try that -- if you're on Windows, I can push a package for the Ineod Hub to download as well.

Thanks,

Alana

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

Hi @jw,

Unfortunately there's no easy way to guess which name is "correct", so sometimes the "wrong" name gets de-duplicated. This also should have no real side-effect, except perhaps seeing the "wrong" casing in some places.

However, as you noticed, the name is overwritten when a package is added to a feed. So, if jquery is the package name stored in the database, that record will be updated to jQuery upon upload of a package.

This doesn't seem to impact many packages at all.

Thanks,
Alana

Hi @pmsensi,

Nice find. So we can't make it a configurable value, but we can try finding something that works with pipy.org, which is the main requirement.

According to the example posted in their docs, this might be what a Simple API might look like:

# Construct our list of acceptable content types, we want to prefer
# that we get a v1 response serialized using JSON, however we also
# can support a v1 response serialized using HTML. For compatibility
# we also request text/html, but we prefer it least of all since we
# don't know if it's actually a Simple API response, or just some
# random HTML page that we've gotten due to a misconfiguration.
CONTENT_TYPES = [
    "application/vnd.pypi.simple.v1+json",
    "application/vnd.pypi.simple.v1+html;q=0.2",
    "text/html;q=0.01",  # For legacy compatibility
]
ACCEPT = ", ".join(CONTENT_TYPES)

So I guess, could you try that header?

application/vnd.pypi.simple.v1+json, application/vnd.pypi.simple.v1+html;q=0.2, text/html;q=0.01

Thanks,
Alana

Hi @jw ,

Thanks for confirming that; we were able to identify the bug -- this time it ws SQL-server specific.

This is fixed via PG-3163, which we're shipping in this week's maintenance release. You'll still need to de-deduplication after however.

Tanks,
Alana

Hi @andreas_9392 ,

That configuration is not supported and will not work; You'll need to configure https://proget.mycompany.com/ or use a port.

Thanks,
Alana

@wechselberg-nisboerge_3629 great news, thanks! Well it'll be in the upcoming release (2025.13) in that case :)

@wechselberg-nisboerge_3629 can you check it out again? Should be there now :)

Hi @wechselberg-nisboerge_3629 ,

Thanks for sharing that; sadly I'm still at a total loss here

But I did make a change that I think should work, or at least give us a different error.... can you try upgrading to inedo/proget:25.0.14-ci.7?

The change is in that build. OF course, you can easily downgrade later.

Thanks,
Alana

Hi @Anthony ,

When you use SHCall, it's translated into a remote SSH command that includes all arguments inline on the shell. Basically something like ssh user@host bash -c '...'

However, there is an OS-enforced limit on how long this can be, which is typically between ~32K and ~64K characters. It looks like you're there exactly, and you may be able to see this limit with getconf ARG_MAX. Note that you would also get this error if you did ssh user@host bash -c 'echo "Really long....."'.

So bottom line -- this is an OS/SSH limit. To work-around it, you can just write out $arg to a file, and have your script read in that file.

Thanks,
Alana

Thanks @wechselberg-nisboerge_3629 , Exactly what I was looking for!

Can you provide some more information about this image? Basically I'm trying to find the layer / mediatype / size. I believe these commands will do it:

docker image inspect vl-dev-repo.ki.lan/sst-coco-oci-prod/sub-coco-cli:test --format '{{json .RootFS.Layers}}' | jq .

docker history vl-dev-repo.ki.lan/sst-coco-oci-prod/sub-coco-cli:test

Thanks,
Alana

Hi @koksime-yap_5909 ,

[1] I would do localhost as to reduce network traffic; a lot of time, "loopback" connections are handled in software and never make it to the network hardware

[2] multiple copies of the package are stored

In general, you should use data-deduplication anyway. Even with out self-connectors, we've seen a 90% reduction in space due to the nature of what's stored (i.e. nearly identical versions).

Thanks,
Alana

@wechselberg-nisboerge_3629 the main thing I'm looking for is the HTTP access logs - we have 1.5 Entires before (PATCH-finish, PUT-Start, PUT-finish), so seeing more would be really helpful.

What's odd is seeing the "retrying..."

@wechselberg-nisboerge_3629 thanks for comfirming!

Any chance you can get more entries from the container log? It'd be really helpful to see more requests going back/forth. This is just such a strange behavior given the seeming simplicity of your image

Also, there should be an option, in ProGet 2025.12, to enable web logging (Admin > HTTPS Logging); it's a brand new feature, but it writes logs to a log file.

Hi @mayorovp_3701 ,

Thanks for confirming; we can will try to get this fixed in the next maintenance release via PG-3139 -- the underlying issue is most likely a race condition on that trigger I mentioned, so we're going to fix it by adding an advisory lock.

It will not remove the duplicate content, but in theory deleting the image will.

Thanks,
Alana

Hi @koksime-yap_5909 ,

I'm afraid this is a known limitation with Maven feeds; we made the assumption that package authors would follow the bare-minimum of Maven versioning: packages start with letters, versions start with numbers.

The only examples we found that were counter to that were 20+ year old artifacts, however, we've since learned that authors still mistakenly use these incorrect versions.

Unfortunately, supporting these types of versions require a complex/risky change.

Maven is a file-based API and the client just GETs/PUTs files. However, ProGet is not a file server so we need to actually parse the URLs to figure out which artifact/package the files refer to. In this case, we parse package-alpha-0.1 as package-alpha (version 0.1), not package (version alpha-0.1). Hence, why it's not working.

If these are your internal packages, the easiest solution is to follow the standard:
https://docs.oracle.com/middleware/1212/core/MAVEN/maven_version.htm

Thanks,
Alana

Hi @wechselberg-nisboerge_3629 ,

This is definitely a strange error; are you using PostgreSQL by chance?

I'm seeing 53babe930602: Retrying... a few times. Is this consistently happening with this layer? Is there anything special about it (big, small, etc)?

Thanks,
Alana