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

Hi @wechselberg.nisboerge_3629 ,

Thanks for letting us know; we'll get this fixed via PG-3408. We're targeting ProGet 2026.14 (October 30).

Cheers,
steve

Hi @carl.westman_8110 ,

I think we'd recommend a work-around of just asking us for help :)

Based on other customers who've tried to use AI to help with ProGet issues, I think you'll be spending too much time spinning your wheels. The AI guidance is almost always wrong, because the pattern-matching stack traces that were scraped from Stack Overflow are to fix coding errors. That, and we fix errors really fast, so even if it scraped an answer, it probably was an old version.

Sometimes it makes matters worse; we saw AI guide one user to do all these strange database changes (connection string, adding indexes, etc) -- when the underlying issue was totally unrelated.

The information in the Diagnostic Center serves two purposes:

1. For end-users (i.e. you) to spot obvious error conditions due to misconfiguration, network errors, etc.
2. For engineers (i.e. us) to troubleshoot, identify bugs, etc. resulting from problems you can't figure out

It is not to proactively check for health, etc. It's only to troubleshoot known issues. And if the issue is not obvious to you, then we can help answer. Our goal is to make this as obvious as possible.

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.