Best posts made by apxltd

hi all, thanks for the interest/comments; I decided to write-up a page that details this on the docs.

http://inedo.com/support/documentation/proget/feeds/other-types

I'm hoping we can use this public thread to maintain the discussion on technical detail; otherwise it'll get stuck in my email, or somewhere else, and we can get everyone to chime in this way.

That said, @M-W if you've got any insight into how R/CRAN works please do share :)

Of course, plan versioning is introduced in a later version, and Rafts (which allow for Git-based storage) is coming in 6.2.

I definitely understand the hesitance to upgrade, but worth noting ---- for once 6.2 comes around we'll offer some great migration tactics to let you pull applications from really old versions of BuildMaster. We'll also better support multi-instances of BuildMaster, so each group can upgrade as they'd like.

That said, the Plans database table will contain your OtterScript plans. Not sure if that's a good solution, but pulling from that table will give you latest versions.

Hello;

There may have been a miscommunication somewhere; do you know specifically what you were told?

We recently added the Feeds Management API, but that's only to manage feeds (not packages).

I just updated the documentation, and it will be published soon.

You can delete (permanently remove) or unlist (hide from most search results) NuGet packages from your feed by navigating to the package page and clicking the corresponding Delete Package or Unlist Package button. These actions require the Feeds_DeletePackage or Feeds_UnlistPackage permission attribute, respectively.

To programmatically delete a package from your feed, you can use the NuGet CLI's delete command, or make a DELETE request via HTTP:

DELETE http://{proget-server}/nuget/{feed-name}/package/{ID}/{VERSION}`

Note that this behavior is different than NuGet.org's DELETE command, which unlists packages instead.

To programmatically unlist (or relist) a package, you can use the NuGetPackagesV2_SetListed method within the Native API.

Is that helpful?

Definitely sounds like a bug; we've get it logged.

By the way, we've got some real exciting container/registry features coming very soon in ProGet 5.3. Stay tuned!

Hi @jeff-miles_5073 ,

Thanks for the first inquiry; I just updated the documentation! These must be "relatively new", and I know we've had a few customers using universal packages for this.

We have some Terraform integrations on our roadmap for 2023, so this definitely something we'll look into on our own as well.

Cheers,
Alex

Just as an update, we will be doing this:

https://inedo.myjetbrains.com/youtrack/issue/PG-1555

"Proxy npm audit requests to npmjs.org (experimental)"

Hi @shfunke_1795 , @jrottmann_6111

Thanks, I just added this to our documentation page!

I didn't look too deeply, but I found some initial documentation:
https://wiki.alpinelinux.org/wiki/Package_management

It seems this is "like Yum/RPM but for Alpine Linux"? None of us here use Alpine Linux, so there's a pretty big learning curve to get started. Any help here would be appreciated, and definitely move this along :)

Is this related to "APK" that Android uses?

Is the "API" mostly like basic file downloads, based on an index file? Are you able to "hack" or do a PoC using ProGet Asset Directories?

Hi @tkolb_7784

I wanted to provide an official answer to this:

Are there plans for (easy) HTTPS support in the internal webserver? Applying a self hosted certificate and deploying it to all build servers and developer machines seems over the top for me right now.

Yes. Not exactly sure how yet, but we would like the integrated webserver to support this as easily as possible.

@shayde @sebastian really appreciate the help, we'll get this incorporated ASAP !!

Thanks for clarifying @sebastian

So I'm not exactly thrilled by this UI, but maybe this is fine.

What do you think?

This is a kind of "quick and dirty" page that would show up if you clicked on that GPL-2.0 license and the "# projects" number.

Here's one for the packages as well:

@dimas said in Incomplete proget debian connector local index file for ubuntu noble-backports dist:

why does the proget connector omit empty repository components altogether, instead of making them empty like virtually every other Debian repo?

Most other Debian repos use or fork Dpkg to generate the folder structure based on files on disk.

ProGet doesn't. Instead, we parse/index all packages in the repository in a local sqllite3 database. That database has a "Packages" table, and we use that to generate feed indexes (Release, InRelease). It's possible to change, and involves modifying the sqllite3 databases to add a Components table, and then changing the way we generate all the indexes.

It's not too hard but it's not trivial and probably isn't worth it unless we get more feedback on the matter.

Thanks,
Alex

@Jonathan-Engstrom they have some hacky something-or-other, but I'd gauge it's at least a decade or two away from being ready for prime time. At least, given their track record on their PowerShellGet/PowerShellGallery v3 launch plans (pushed to 2027.... maybe??)

There's just no appetite for WinGet in the enterprise space, especially since Chocolatey does everything better and has a significantly more reliable / responsive team behind it.

On our end, it doesn't make to try jumping into such an immature ecosystem, especially one run by Microsoft, who's leadership is currently focused on making their BingAI Copilot relevant and selling more Azure web hosting

Windows barely fits into their strategy, let a lone WinGet. But we'll see... maybe the WinGet team can fight against the current enough and increase adoption.

At this point, WinGet It's not a bet I'm willing to take though

Hi @pg_user_8607 ,

Thanks! If you haven't already, please do check out our Migrating from Sonatype to ProGet guide.

[1] This is a common configuration, and it looks like anonymous is allowed based on the screenshot. It's hard to say withtout more troubleshooting. I would try using the Test Privileges function , which allows you to select a user, feed, and then it will show you all the task attributes available.

[2] To be honest, our users have not found those analyses to add any real value (outside of describing what the library does). So, starting in Q1 we've shifted our research efforts to align with the big changes to vulnerability management in ProGet 2026, including Category 5 Vulnerability Research. Check out the Vulnerability Management Done Right with ProGet guide to learn more about what's coming!

[3] No plans... in retrospect, there's no value in monitoring activity outside of checking the /health endpoint periodically. In fact, we've seen the opposite -- even monitoring HTTP traffic for abnormalities creates false positives that just wastes everyone's time.

For example, if NuGet.org is having an outage, then your NuGet feeds connect to nuget.org will run slow, as the connector times out.

[4] I suppose so! We'll update once we get ProGet 2026 out :)

Cheers,

Alex

Hi @geraldizo_0690 ,

Thanks! That's pretty much where we left it, an "interesting feature" with no real demand. I'm glad you "get it" though and see some value here :)

This allows users to check whether the packages they use have already been updated with the latest security updates.

So to clarify, your envisioned usecase is system/Debian packages? What would you do on the Otter side? Orchestrate updates of those packages?

Cheers,
Alex

PS -- other issue is the list to address, easy fix just haven't gotten to it yet w/ PG2026 stuff

Hi @Nils-Nilsson ,

Thanks for the feedback; we discussed this with the team some more.

The use case makes a lot of sense, especially with risk profiles introduced in ProGet 2026. Instead of exposing Policies (which have a bunch of package-driven rules) and blocking, our thoughts are:

[1] Allow risk profile to be set/configured on Docker feeds; behind the scenes this would create Policy, but none of the rules would be used

[2] Allow scoped assessments on Docker feeds; this would also use the feed's policy

[3] Add pgutil containers audit command, which would display vulnerabilities and error if any are severe

The issue we have with "blocking" downloads directly is that the Docker/Kube/Podman/etc. do not expose HTTP error messages and this becomes very painful to debug/troubleshoot.

However, running pgutil containers audit can "break" any automation process (nonzero exit code) and will list all vulenrabilities etc.

LEt us know your thoughts!

Thanks,
Alex