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 @kichikawa_2913 ,

I think it's this way for "historic reasons" - mostly all the other feed types came later, and it seems no one ever changes these paths or noticed.

Easy enough to make it configurable, but can you share your use case? Why do you want to use something other than a single root path with all of your packages?

Anyway I added a feature for this, and we should be able to get it in the next maintenance release PG-2006

Cheers,

Steve

Hi @benjamin-soddy_9591,

No problem "resurrecting" topics! We definitely want to hear from users about feedback/feature requests.

We still haven't had anyone else ask for deprecation since this request, but I wonder if there's a better solution to solving your challenges than this feature. It sounds like you want to increase governance of your NuGet Packages, potentially with some sort of compliance in mind.

The dotnet list package --vulnerable is probably not what you want for your organization; NuGet's Built-in Vulnerability Scanning is really limited, in part because it only reports on a fraction of known package vulnerabilities (164 as of today). It also won't block packages that you deem problematic, unlike ProGet's feature.

The same is true with dotnet list package --outdated -- it's probably not what you want, because it relies on developers to have to know (1) to run the command, and (2) know what to do if there's an outdated dependency.

There are better ways to manage third-party packages (see How to Create a Package Approval Workflow for NuGet), and you'd better served knowing who's consuming outdated packages (see Use Package Consumers to Track Dependencies

Just some thoughts; like I said, we haven't had any demand for this feature, but these are proven solutions for improving governance of packages as organizations grow/expand their NuGet usage like you are.

Cheers,
Steve

Hi @kichikawa_2913 ,

The NuGet client's behavior is based on NuGet.org, where no authentication is ever required to view/download packages. As such, it doesn't pass the API key when doing those queries; instead, you can use a username of api and the password of your api key.

Based on the issue though, it sounds like ProGet is unable resolve the groups; I would use the "test privileges" function on the Tasks page to verify this. Thatw ill show you if the username can download packages or not.

The most common reason that groups aren't resolving is that the member is not directly in the group (i.e. they're in a group which is a member of the group), and you don't have recursive groups enabled; do note that this is really slow on some domains.

Cheers,
Steve

Hi @mcascone ,

Just looking at the code real quick, I suspect we have a bug where it writes out the wrong files name for the new package:
https://github.com/Inedo/upack/blob/master/src/upack/Repack.cs#L120

That's probably an easy fix, which we can do as part of this Q&A item. I'll wait to hear back about this one.

As for the error, "The underlying connection was closed: An unexpected error occurred on a send.", that sounds like it's HTTPS related. Could you attach Fiddler, or something like that, to find out what's happening under the hood? We may be able to error message to better report it if so.

Cheers,
Steve

Hi @cimen-eray1_6870 ,

Great questions; there's no problem having a second instance with ProGet Free Edition.

The relevant restriction is that you can't use a Connector in ProGet Free Edition to connect to another instance of ProGet (either another Free Edition or your paid edition).

Hopefully you can use your Maven feed as a proof of concept for implementing it in the main instance. Good luck!

Cheers,
Steve

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?

@stefan-hakansson_8938 as you noticed, ProGet's Debian connectors are not currently designed to handle the gigantic, operating-system mirrors very well. This is because they are always refreshed "on demand" - which is what you want for CI/CD workflows.

It's not great for public repository mirroring, however. In Q4 or later, we will explore adding an option to do periodic updates.

Hi @m-webster_0049 ,

The first thing I would try is to troubleshoot this is to switch to a very basic API key like hello. That just eliminates any typos, spacing, etc.

Next, I would try specifying the API Key via X-ApiKey header (see docs) - just to see if you get a different error. It's possible there is a regression somewhere.

Best,
Steve

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

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