inedo-engineer

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

Hi @davi-morris_9177 ,

For multi-file packages like PyPI, the entire package (i.e. all the files) is promoted. This is the same in the UI as well.

-- Dean

@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