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 @brodie.mclennan_5777,

Can you share the original SBOM that was generated by syft? We don't need every single package, but a handful would be nice.

That'll let us reproduce the issue a lot easier.

Thanks,
Steve

Hi @cyril ,

Ah, that'll do it! That configuration is definitely not supported, so you'll get some weird behavior. Are you able to resolve/change it via the API back? That must not have the check mechanism.

Only Docker feeds use Common Blob Storage, since they're the only ones with a bunch of weird share layer files :)

Thanks,
Steve

Hi @abhijeet.patil,

As an FYI, we do not recommend using an external PostgreSQL server.

While it's technically possible to connect to an external PostgreSQL, we strongly advise against doing so. Not only does it require sufficient expertise in managing PostgreSQL servers and databases, but it generally has a negative impact on performance, increases the cost/complexity of your configuration, and leads to increased downtime.

You may also receive reduced support since we will not support most PostgreSQL-related issues when you're using an external server, including unique permission configurations, database monitoring agents, transaction replication, etc.

That said, this is exactly one of those scenarios we do not support (i.e. running commands like CREATE SCHEMA proget AUTHORIZATION proget). We're also not sure how to "fix" your database at this point, so hopefully it's something you can just recreate without running that command at first.

We do recommend just using embedded; the database tends to be relatively small (few hundred mbs usually, even with lots of packages).

Thanks,
Steve

Hi @cyril ,

I can't see the full configuration, but do you have "common blob storage" configured on the feed? That shouldn't be possible with cloud storage enabled, but it might be something you did via the API or another bug.

Common Blob Storage is not supported with cloud storage at this time; it's something on our roadmap.

Thanks,
Steve

Hi @cyril ,

Actually, "cached" packages are stored the exact same way "local" packages are. The only difference is a flag (Cached_Indicator) on the database entry.

If you're seeing package files on local disk, they're might be from a different feed or are older (i.e. before you used cloud-storage).

Thanks,
Steve

Hi @brodie.mclennan_5777,

I've been scratching my head at this one for a bit, but I just spotted something that jumped out in your SBOM: pkg:pypi/aiofiles@25.1.0?package-id=14c45300fad292ea

Where is this SBOM from? I assume some other tool?

Thanks,
Steve

Hi @brandon_owensby_2976,

Off the top of my head, I don't know how handle locale for this particular circumstance (either DotNet::Test or the Image-based services as a whole). But in general, I believe it's a distro-specific (maybe) environment variable (LC_ALL I think?). It may vary case-by-case.

We do have an open roadmap item for reviewing Image-based Services and DotNet::Test operation as a whole (it's linked to the other comments you made), so I'll add this request to that.

Cheers,
Steve

Hi @carl.westman_8110 ,

Thanks for the clarification!

And just as an FYI (not a complaint at all), for that specific post... we'd really only need the stack trace. The technical details.... they were.... well, as you said, you used AI

Sometimes it can be hard for us to tell who/what writes it, but it's almost always more productive for us to get (1) copy/paste of the message from diagnostic center and, ideally, the (2) steps to cause the error.

Don't get me wrong -- we super-appreciate users who take the efforts to try to troubleshoot bugs/errors, but since they can't change ProGet's code it feels like a waste of their time. Even if their review is correct, we still have to independently reproduce/verify/test it.

Anyway we're definitely open to more endpoints or more specific feedback on enduser messages or configuration screens, etc... but we consider those on a case-by-case basis (e.g. like a new command in pgutil for example).

As an FYI ... there is a separate topic on Configuration as Code, discussed over here:
https://forums.inedo.com/topic/5644/proget-configuration-as-code-iac

Thanks,
Steve

Hi @brodie.mclennan_5777 ,

Are you sure the issue is related to publish date? If you do an analysis and look at detailed logs, you should see issue.

I haven't had any luck reproducing this. I did this:

1. Created PyPi feed with a pypi.org connector
2. Navigated to aiofiles 25.1.0
3. Downloaded aiofiles-25.1.0-py3-none-any.whl
4. Verified file was local (Packages > "Cached")
5. Uploaded a minimalist SBOM file (see below)
6. Analyzed the build with detailed results

SBOM File:

<?xml version="1.0" encoding="utf-8"?>
<bom xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://cyclonedx.org/schema/bom/1.7">
  <metadata>
    <timestamp>2026-10-16T19:45:59.6109575Z</timestamp>
    <tools>
      <components>
        <component type="application">
          <manufacturer>
            <name>Inedo</name>
          </manufacturer>
          <name>ProGet</name>
          <version>26.0.0.0</version>
        </component>
      </components>
    </tools>
    <component type="Null">
      <name>snakey</name>
      <version>1</version>
    </component>
  </metadata>
  <components>
    <component type="library">
      <name>aiofiles</name>
      <version>25.1.0</version>
      <purl>pkg:pypi/aiofiles@25.1.0</purl>
      <externalReferences>
        <reference type="website">
          <url>http://localhost:8624/packages/from-purl?purl=pkg%3apypi%2faiofiles%4025.1.0</url>
        </reference>
      </externalReferences>
    </component>
  </components>
</bom>

Results:

Found 0 licenses on pkg:pypi/aiofiles@25.1.0?file=aiofiles-25.1.0-py3-none-any.whl:
Analyzing compliance for aiofiles 25.1.0...
Beginning license rule analysis...
Default rules: undectableLicense=Warn, unspecifiedLicense=Compliant
No licenses detected on package; applying undectableLicense rule (Warn)
License rule analysis complete.
No policies define a aged or recently published rule, so the published date will not be checked
Policy "Global" considers recently published (30 days) Noncompliant
No policies define a latest patch, so latest patch will not be checked.
Analysis resulted in a Warn result.
aiofiles 25.1.0 is Warn No license detected

I do get a Warn result, because it's an embedded file license.

Thanks,
Steve

Hi @amy.j ,

Good news! Thanks to another user, we were able to figure out how to get a Publish Date for Maven artifacts. It seems to work on MavenCentral, and possibly other servers -- it realy depends on if they implement Last-Modified headers on HTTP requests.

This will be implemented in today's release via PG-3411

Thanks,
STeve