Hi @james-woods_8996 ,

Setting the ASPNETCORE_URLS is the correct way to address this; that troubleshooting guide is outdated (though it probably still works to write out the config file like that).

As far as I understand, this behavior has not changed in ProGet 2025 and has been the default behavior since ProGet 2022. We had considered changing the Linux ports to be 8624/8625 to mirror Windows defaults, but decided to just update the documentation to clarify.

Thanks,
Steve

Hi @amy.j,

Good news! We've decided to correct this, along with some other errant behavior with carrying over certain server-side metadata from connectors.

We are planning to ship this in the upcoming maintenance release (scheduled for August 7) via PG-3342 (FIX: Ensure correct server-side metadata (publish date, listed, deprecated) is set when adding package via pull, download, or promote from remote connectors).

This is currently in testing / code review now, asit's a bit of a riskier change. But assuming there's no issues with it, it will be available after the release.

Thanks,
Steve

@joshuagilman_1054 this is currently planned for 5.3.27 as PG-1934 (April 17) - we'll let you know if plans change!

@p-pelinski_1371 @pbe_9047 thanks for confirming that!

We will get this fixed via PG-3031 in the next maintenance release. You are also welcome to try the proget:25.0.3-ci.3 container image, which is building now.

@mmaharjan_0067 we'll see how we can improve this while we work on PG-3034

@phopkins_6694 perfect, just what I was looking for

I was able to reproduce this - searches via the NuGet API (which connectors use) will consider tags, while local searches seem to only be looking at names.

I'm not sure how long this has been the case, but we'll try to get it fixed soon. Unfortunately it's not a trivial fix, hopefully we'll do it via PG-3046, likely in the July 18 maintenance release.

Thanks,
Steve

@jfullmer_7346 this is a bit tricky behind the scenes but hopefully will be resolved with PG-3047 -- which we hope to get in the next or following maintenance release

Hi @brett-polivka,

I've added it to our Other Feed Types page, and linked this as the official discussion thread.

There's a lot of things to consider in developing a new feed type, but ultimately it all comes down to two things: (1) how much more value does this feature bring to our users, and (2) how many new licenses of ProGet would this feature sell.

The second question is where internal market research comes in, but we would love your opinion on the first question.

Here's a nice and simple way to help understand value: how much more do you suppose your company/organization would pay for this feature if it were available as a hypothetical add-on? $100/year? $1,000/year? $10,000/year? Etc. And why? What time is it saving, risk is it mitigating, etc.

The second part of the value equation is how much effort will it take, technically speaking. It's more than 15 minutes obviously, but is it 10 hours? 100 hours? Etc.

On the plus side, the package format seems to be documented pretty well. However, the registry API has a huge red flag:

The index key should be a URL to a git repository with the registry's index.

Does this mean their API is Git-based, and we'd need to first add private Git repository hosting to ProGet? And did they test it with private/authenticated Git repositories, or just their public (probably GitHub) repository?

Hi @mcascone ,

We don't have a single API method that can be used to delete all package versions from the API, but the foreach loop will do the trick!

I should add that I am doing this as the first stab at an attempt to automatically delete packages from a development feed, when the corresponding branch in github is deleted

I don't know the specifics/details of your use-case, but based on what I read, I'd recommend these guidelines:

• assuming: one GitHub repository, one project, one package you want to release
• use the same package name/group for all packages you create for this project, regardless of branch or development status
• create your "dev" packages using a prerelease version number, that has a sort of -ci.## version (assuming you use CI to build packages)
• embed the commit id and branch in your upack metadata file, for traceability
• if you want to see which branch the packages was created from using the version number alone, add a +branch metadata label to the version number for branches (don't do this for master)
• use repackaging and promotion to take your -ci packages to -rc to stable (and the desired feed)
• let retention policies automatically cleanup up the -ci packages

Hi @andreas-unverdorben_1551 ,

I'm afraid this is a problem with our upstream source (GHSA). Long story short, the datafile is incorrect and does not specify a range.

We do not have any plans to build a system/module that allows us to "override" data in the upstream datasources at this time, so the only way we can really address it is by fixing the upstream source.

I believe the best route to do that would be to submit a pull request to the GHSA repository against the related datafiles (e.g. GHSA-4r6h-8v6p-xvw6.json)

In this case, they are missing a "fixed" event in the range:

      "ranges": [
        {
          "type": "ECOSYSTEM",
          "events": [
            {
              "introduced": "0"
            }
          ]
        }
      ]

Here's what it needs to look like:

      "ranges": [
        {
          "type": "ECOSYSTEM",
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": " 0.19.3"
            }
          ]
        }
      ]

Thanks,
Steve

Hi @bobmaurer ,

Thanks for the inquiry! Hope you don't mind a little push back on this -- but we'd encourage your security team to read our Vulnerability Management Done Right with ProGet.

While we understand where they're coming from, the "weekly download" report is an anti-pattern these days and will lower the organization's security posture... which probably goes against their mission

The main reason is that it improperly treats vulnerabilities as security incidents while providing no realistic path to mitigate them. This is backed by a huge body of research, including our own State of Software Supply Chain Security and reports from industry analysts.

For example, they see "Joe Developer downloaded JsonLib 3.4.1, which has PGV-12345" -- what exactly are they going to do with that information? Contact Joe and ask him how he used it? Do they expect Joe to trace through 1000's of transitive dependencies across dozens of projects to see if he even knows where it's used? Tell him to uninstall it? Try to figure out if he caused damage? Or what application it was added to?

Obviously not, because there will be so many packages with vulnerabilities that no one knows where they came from. The "best case" is to get aggregate data -- and ProGet already provides that, but by application/deployment state (which is what really matters).

Anyway -- the best way to handle this is by implementing Software Composition Analysis in ProGet - we have all the tools to help Prepare for a Category 5 Vulnerability

Thanks,
Steve

Hi @brandon_owensby_2976 ,

This is a generic forums system that we're using for public-facing support of a niche software product, so most of the features like voting/reputation don't really apply.

Honestly I didn't even know those were features.... we recently upgraded the software, so maybe these were added? Anyway I just disabled them since we don't use them :)

We have internal tracking for everything - either as a scheduled YouTrack ticket (which we link to) or a roadmap item (internal project tracking) that we periodically review and schedule as tickets.

Thanks,
Steve

Hi @clsa,

If you're talking about the certificate errors under Admin > HTTPS, I wouldn't worry about those. An application does not need to validate its own certificate; it's only used to encrypt/decrypt the traffic.

The server transmits a copy of the certificate (without the private key), and the client validates the certificate before transmitting data.

Without getting into too many technical details, the only thing that really matters is if clients can connect to the application (ProGet) using HTTPS or not. There are a lot of reasons that may prevent the application from self-validation and it's not really worth trying to fix, since it's only used on that page to help catch basic errors.

Thanks,
Steve

Hi @clsa ,

We're not aware of any bugs or issues; SSL and Certificate handling is all done at the Operating System (Windows) or Platform (.NET) level; we just point the system to the file. In my experience there's usually some obscure registry setting that will control stuff like this.

Thanks,
Steve

Hi @brandon_owensby_2976 ,

You may be right here; we'll just need to dig in and research a bit more. "Everyone" tests with and assumes a Linux Stack when working with Docker containers/agents, so it's likely this is just an edge case that we need to review further.

We'll add this to our roadmap to do down the line.

Thanks,
Steve

@brandon_owensby_2976 thanks!! This one was also added to our roadmap to review.

@brandon_owensby_2976 thanks for the heads-up! We'll also review this down the line in our roadmap

@brandon_owensby_2976 thanks for the heads up; we'll add this to our roadmap to fix.

Hi @brandon_owensby_2976 ,

As I mentioned earlier, this is an issue with the dotnet container for Windows, not BuildMaster:,

The underlying error appears to becoming from the dotnet tooling. Though it's hard to say without troubleshooting further. Basically, something in the stack is calling the Linux tool id , which isn't going to work on a Windows container.

When you installed Git (which is basically a Linux tool), it must have included a Windows-version of id . That allowed the dontnet container to then work. You're probably the first person whose tried to use the dotnet container without installing Git as well ;)

As for a better way, just run on a small Linux VM instead on your Windows desktop (Hyper V). You're going to run into a lot of headaches if you try to use Docker Desktop.

Thanks,
Steve

Hi @dbojak ,

We do User-driven Development, so this is something we could work on after customer onboarding.

The audit changes you describe seem reasonable, although we would obviously need to work together to translate that to product-specific terms; e.g. there are no "feed security policies", just scoped privilege/restrictions that associate a principal with a task, and those are either are added/deleted. You'll understand these as you learn our product a bit more, however.

And obviously there are also some technical limitations far beyond ProGet - for example, knowing which user downloaded a package requires that user first authenticating to the feed. Otherwise these kind of changes are relatively easy to implement and something we can often add in maintenance releases.

However, it's unlikely we will add SIEM integration as a feature; it'd be a substantial undertaking that is like 95% outside of ProGet's core functionality, and would require continuously supporting third-party log aggregation platforms we have zero exposure to. We would need to see (1) a lot more demand, and (2) user-created prototypes that extract/convert from the database.

A handful of users have written "log exporters" to tools like Splunk, but they are so highly specific to their requirements that it would be impossible to generalize as an open-source tool, let alone a product feature.

Thanks,
Steve