Hi @yaakov-smith_7984 ,

This behavior is expected and by design. "Deprecation" and "Unlisted" are server-side metadata (i.e. stored in the remote repository, not the package itself), and once a package is brought into to a different server (i.e. ProGet), it's "disconnected" from the other server.

That being said, there is a feature in ProGet that can routinely "sync" this server-side metadata:

• https://docs.inedo.com/docs/proget/sca/howto-deprecated-package-alerts
• https://docs.inedo.com/docs/proget/sca/policies#oss-metadata-updating-caching

This feature obviously comes with some performance costs, though you'd really have to enable it to see if that has any impact on operation.

Another approach is to use a retention policy that deletes cached packages older than 90 days.

Thanks,
Steve

Hi @frei_zs,

Based on the fact that unpackaging/repackaging it works, there's definitely something "wrong" with the original package file.

Debian uses a tarfile format, and there are several "buggy" tarfile writers that don't get the format quite write. If I remember correctly, some ancient versions of dpkg wrote these files incorrectly. Some tarfile readers account for these errors while others (perhaps including ours) do not.

We may be able to attach the file to a debugger and give more details, but if this is a one-off or rare circumstance, than I would just repackage it and not worry about it.

Thanks,
Steve

Hi @jw ,

Did you try this on a new instance, or did you discover this on your (older) instance?

This was a known issue through several versions of ProGet 2025, and it impacts mostly SCA as you noticed. However, the vuln updater has since been fixed, so it shouldn't be continuing.

The "feed reindex" function can also merge/fix these duplicate names. They should be detected during a "feed integrity" check, and show as a "warning".

Thanks,

Hi @koksime-yap_5909 ,

I'm afraid we can't provide much clearer guidance than that, as there are so many factors involved that make predicting performance basically impossible. For example, the feed types you're using, your CI server configuration, how often developers are rebuilding, etc.

The article you found is actually what we send users who experience symptoms of server overload, to help understand where it comes from and how to prevent it. As the article mentions, the biggest bottleneck is network traffic during peak traffic - there's only so much that a single network card can handle, and scaling CPU/RAM doesn't really help.

This is where load-balancing comes in. The main downside is complexity/cost, which is why a most customers start with a single instance. It can take quite a while for a tool like ProGet to be fully onboarded across teams, so performance problems likely won't happen at first.

Hope that helps, let us know if you have any other questions!

Thanks,

Steve

Hi @koksime-yap_5909 ,

Good catch; that is most definitely a bug. I just checked, and it's isolated to assets - packages and Docker images work as expected.

This will be fixed in the upcoming maintenance release via PG-3150; it's shiping Friday, but we can provide a pre-release if you're interested in testing earlier.

Thanks,
Steve

Hi @koksime-yap_5909,

In the event that the artifact has not been downloaded (i.e. the last download date is "null"), then the publish date will be considered. So if you set "90 days", then an artifact will be deleted at earliest, 90 days from publication if it hasn't been downloaded.

Thanks,
Steve

Hi @koksime-yap_5909,

The command will recreate the user, restore administrative privileges, etc. It's safe to run - and you'll ultimately be left with a Admin/Admin user that you can log-in as.

On ProGet 2025, the command is proget or proget.exe We should update the docs for sure

Thanks,
Steve

Hi @Sigve-opedal_6476 ,

There are some known issues that we intend to fix with PG-3144 in the next maintenance release (scheduled for Friday). This will likely be resolved then.

The inedo/proget:25.0.14-ci.10 container should have these changes inthem, if you'd like to try it out sooner.

Thanks,
Steve

@yakobseval_2238 thanks for letting us know, I just updated it!

Hi @k-lis_1147,

Based on what you described, it should show up.

Can you confirm what feed type you're using, and whether or not you're using PostgreSQL (this is the default for ProGet 2025).

I just discovered a bug (PG-3145) that would impact PostgreSQL (all feeds probably) and certain feed types on SQL Server (Maven) that would cause that information not to display on that page.

Easy fix, but just want to double-check

Thanks,
Steve

Hi @koksime-yap_5909 ,

If you ever get "locked out" of an Inedo product, either due to misconfiguration or a lost password, you can restore the default Admin/Admin account and reenable Built-in User Sign-on by using ProGet.exe resetadminpassword

Here's more information on this procedure:
https://docs.inedo.com/docs/installation/security-ldap-active-directory/various-ldap-troubleshooting

Thanks,

Steve

Hi @tayl7973_1825 ,

Thanks for the feedback; this is all a relatively new space, so we're in the process of building best practices / advice as well as tools to help teams solve these problems.

Right now, based on your suggestion, it sounds like the workflow would require us to manually identify which applications depend on a vulnerable library, notify each owning team

You are correct - the SCA Builds & Projects functionality is designed to "provide that link" between specific package versions and specific builds of applications. The builds are a moving target, as they may or may not be active/deployed.

The "Project" in ProGet is not intended to the "source of truth" about the project itself, but be sort of sync'd with the truth (e.g. like an Application in BuildMaster). That's why there's a "stages timeline" for builds in PRoGet.

hope it fits within their priorities, and then track remediation through individual tickets.

Our advice here is to think of it more like, "advise them of the identified security risk and unavailability of the impacted library they are using". Ultimately it should be up to the team (their product owner) to evaluate the risk you identified and mitigate it. For example, TeamLunchDecider1000 can probably live with a security risk, but let the team decide.

Once you've removed the library from ProGet, they can't use it anymore and it's "no longer your problem" to worry about or track through tickets.

Ideally, we were hoping our package management system — since it already governs distribution and security controls — could act as that “one stop shop” to track and visualize which applications still rely on a vulnerable version along side it's assigned severity rating.

ProGet already provides visibility into consumers through SCA, and you can already see how OSS Vulnerabilities impact builds.

HOWEVER, our core advice here is to not try to establish your own in-house "vulnerability database" for in-house libraries your organization. Even large orgs (2000+ developers) won't do that.

Instead, it's a simple binary decision: PULL or KEEP the library. If you PULL, then notify consumers it's unavailable going forward and let them decide how to mitigate.

That approach is superior to OSS Vulnerability workflows, but it's obviously not possible for OSS library authors to do.

Cheers,
Steve

Hi @tayl7973_1825 ,

Thanks for clarifying it. Based on that, I would say that "Vulnerabilities" are most definitely the wrong tool for the job. You can certainly "hammer in a screw" but there's a better way to do it - and we don't make "screw hammers" at Inedo

We're working on best practices / guidance on how to build security policies around these topics, but I'll try to give some tips now.

What you're describing isn't a vulnerability per se, but a SAST Issue: a potential weakness in code detected by a static analysis security tool. Most of these are false positives and present no real security risks, but some are.

If you discover a SAST Issue in one of your libraries, then you should use the following process:

1. Evaluate if it's a false positive or not
2. Unpublish the library internally if there's a security risk
3. Enumerate the consumers (i.e. applications in flight or deployed to production)
4. Evaluate the security risk (low, high), based on the consumers/usage
5. Notify the application teams to upgrade the library as appropriate

Note how this process is fundamentally different than OSS packages / vulnerability workflows:

• you can unpublish/block packages from your repository
• you know which applications are consuming your packages
• you know which teams maintain which applications
• you can work with those teams to assess the risks

Bottom line: if a package causes a real security risk, then unpublish it and fix the consuming applications as appropriate. Otherwise, don't.

There's really no middle ground or room in this process for "Vulnerabilities" - and trying to curate an internal "vulnerability database" is just going to make things less secure in your organization.

That's a theme in our upcoming content, but the general idea is when you treat all issues/vulnerabilities as security risks, then it's impossible to focus on the ones that are actual risks -- and it's as meaningless as saying "everything is a top priority".

Thanks,
Steve

Hi @tayl7973_1825 ,

This is not possible nor is it a workflow we'd recommend to support. Vulnerabilities have a very specific meaning / use case -- third-party discoveries in open-source packages that may impact your code (but probably won't) -- and it's not a good idea to "abuse" them for other purposes.

Deprecated is one solution, but a better would be to use SCA and monitor how that package is being used, so you can understand impact on library consumers:
https://docs.inedo.com/docs/proget/sca/builds

Thanks,
Steve

Hi @yakobseval_2238 ,

Can you let us know the commands/arguments you're using?

Thanks,
Steve

Hi @jlarionov_2030,

I haven't tested or tried it, but I can't help but wonder the API is responding with some kind of "license required" error, and blocking the seting.

I suppose we could investigate and try to resolve the error, but automated setup with a license key isn't so common of a requirement.... if tis is not really something you will do that often, perhaps it's not worth the effort.

Let us know your thoughts.

Thanks,
Steve

Hi @jlarionov_2030 ,

As of ProGet 2023 (or maybe earlier?), license keys are no longer requested / entered at installation time, but in the software itself now. This only matters on new instances.

You can use pgutil settings to set a license key if you'd like.

Thanks,
Steve

Hi @parthu-reddy,

Thanks for discovering/confirming that; unfortunately we're not able to reproduce this issue, as the multi-part / chunked uploads already take into account multiple servers.

• Chunked upload sessions are persisted in the shared database (ChunkedUploads table)
• Bytes are appended to a file stored in shared store

Would you be able to dig into the request patterns a little more? I suspect there's "something" configured on the load-balancer that's "doing something weird" with these ranged requests.

The Multipart Upload API explains what's happening behind the scenes, and you may find that using pgutil assets upload is easier to troubleshoot.

Thanks,
Steve

Hi @jw ,

It definitely looks like there's some "drift" in the documentation and behavior. I already see some stuff about "allowedFeeds" in there, which isn't even a thing since policies. And you're right, you can't update code/title, which aligns with the pgutil behavior as well.

We'd rather have "no documentation" than wrong documentation, any suggestions on what to delete from here? https://github.com/inedo/inedo-docs/blob/master/Content/proget/api/licenses/update.md

Feel free to submit a PR if you've got a clear idea.

In general, we want to make sure the pgutil docs are accurate (those are very easy to test), and we figure... someone can just look at the pgutil code to learn the HTTP endpoint or library.

Thanks,
Steve

Hi @udi-moshe_0021 ,

My guess is that your proxy server is blocking certain things or having issues with redirects; you'd really have to monitor the back-and-forth traffic to see what's going on.

As you can see, there are a lot of "redirects" going on and URLS/Domains that you will not expect and can be hard to predict.

Thanks,
Steve