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

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 @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 @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 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 :)

Hi @Nils-Nilsson ,

We're considering "doing something" about this for our ProGet 2027 roadmap, but I really want to think about how this should be handled in ProGet. I want to create something that actually is helpful in identifying real security risks... and I'm not sure if our package-intended Policies is the move for Docker containers.

One major issue is that nearly all vulnerable packages in a container IMAGE pose zero risk. Even if the component were used (most aren't... they're just installed), exploitation would require someone SSH'ing into the container and running interactive commands. PGV-2387734 is a great example of this.

It's actually more risky to remediate the vulnerability and become "sensitized" to vulnerabilities like this. So, we want to make sure we can find way to "permanently mute" these for certain containers - and perhaps that involves saying "I do not actively use this component that happens to be installed in the image"? I'm not sure.

There are also some issues with the ways vulnerabilities work with certain Linux distros; for example, the "patch version" varies by operating system, and that information isn't readily available in the vulnerability database and ProGet isn't analyzing which operating system the platform is using.

We have a rough idea of treating Docker images to be more like SCA Builds than Feed Packages, in that an entire container image would be considered complaint. However, how many container images are built (it's done at CI for a lot of people), how few people seem to use pre-release tagging, etc., I don't know what makes sense here.

Anyway let me know your thoughts!

Thanks,
Alex

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

@geraldizo_0690 thanks for clarifying!!

That's an interesting use case (i.e. using Otter/ProGet for vulnerability monitoring), though one we haven't really thought about. I can definitely see how the tools could work together to support that, but I suspect there are some key features/functionality that are missing (like getting notified, etc). Plus, a whole bunch of documentation and marketing to support the use case :)

It feels like we're taking on a whole new niche here, and there's a lot of solutions/players in this space. A quick search revealed Wazuh, OpenSCAP, Grype, Syft, etc. I've never heard of any of those, so it's hard to know how we could do something better. That would be first step -- why build "yet another solution" to this problem?

From a technical/solution standpoint, I think that something like a "pgutil but for system packages" might be a better choice. Just run that after a system update on the hosts, and that would push information to ProGet.

That simplifies configuration/management, and the two systems already have network access -- whereas opening up the host via SSH requires higher-level permissions, etc. It's lot of "adoption overhead", which means users won't really try it out.

A:nyway... it seems like we just need to "start from scratch" on this one. Definitely interested to learn more, but for now the main question would be "what problems can we uniquely solve that the existing tools can't".

Best,
Alex

Hi @no-doubt,

We are software engineers that provide technical support to technical end users. We cannot help non-technical users who provide no technical information. Moreover, I'm not willing to work with users who call our products "a real pain" and share counter-productive "facts" about how easy competitive products are. You should know better.

I'm going to lock this thread, but I'll give you another chance though.

If you'd like to continue your evaluation and receive technical support, please spend a few moments reviewing other forum posts to see how users communicate with us. If you feel comfortable doing that, then post again. If not, then it sounds like you've got two products to choose from.

Sincerly,

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 @george-bowen_9415 ,

This was brought up at a internal review meeting, but I didn't want to have this added because I don't want to start adding configuration options to the AD v5 Directory - the goal is to "just work" for 95% of the use cases, and your configuration (37K users, 101 direct groups, 217 indirect groups) definitely falls within the 5%

So, our plan is to update the documentation on how to configure LDAP / OpenLDAP directory with AD. That's technically more work than adding a checkbox.... but this aligns with how most other products integrate with LADP/AD.

We plan to document this in the coming weeks, but in the meantime you could probably figure it out without the tutorial.

Cheers,
Alex

Hi @geraldizo_0690 ,

Thanks for trying out the feature! Unfortunately I think this feature broke around ProGet 2023 and no one seemed to notice it; we were actually planning on removing it in ProGet 2026.

We build the feature ages ago, but no one ever asked for it. It just "felt" like a "nice idea" at the time, but we never really thought out a proper use case. So was never documented very well and it would seem no one used it

Anyway... I'd be open to reviving it if we could actually figure out a use case. What are you trying to do? Would love to get an idea to see if we can solve a real-world problem here

Thanks,
Alex

Hi @paul-moors_5682 ,

We'll definitely keep an eye on this after ProGet 2026; we're doing some big improvements for vulnerability management, which will probably push more folks out of the Approval Workflow.

One thing I like about an in-built workflow is that it demos really well and makes it so much easier to see/understand how an approval workflow could work. While I personally love the idea of "approved packages only", it's so hard to recommend that workflow in practice.

Anyway, let us know how your approval-only journey goes. We tried it internally here and it was a flop... just Microsoft's growing dotnet dependencies alone made it impractical.

Cheers,
Alex

Hi @paul-moors_5682 ,

Thanks for sharing this idea; it's interesting idea and is actually something we talked about internally over the years.

However, after several conversations with a few customers who used the Package Promotion Workflow, they wouldn't find any value or use the feature. The reason is, they already have workflow tools (ServiceNow, JIRA) that document/automate SOP like these, and some will even do a quick API call once the package is approved.

In other words, everything happens in the workflow tool -- which is used for every other SOP from architecture review to vacation requests.

Now just to comment on the "best practices" part; we are working on revising our practices, but we don't consider "package promotion" the best practice anymore. Instead, we consider it the "option with the most control (and highest cost)".

If that level of control is not needed by the organization, then it shouldn't be used -- given the explosion of dependencies (1000+ for the average npm project), it's a lot of process to maintain. A lot of customers (military contractors, etc) are used to that level of process/control and it's fine.

But if you try to institute this at an organization without this process-heavy culture, you'll get a "rebellion" and just see shadow-IT and bypassing of these rules. And they won't get fired or even scolded.

And that brings us back to why no one seems to want this type of system -- companies with this level of process use ServiceNow/JIRA for everything already.

Cheers,
Alex

Hi @davidroberts63 and @mikael ,

Thanks for the insight and ideas!

I'm surprised to hear that a "proxied" Terraform Provider Registry wouldn't be a security concern; it seems like a great vector for a trojan-horse provider reference (say aws-core) to be snuck into some proxied module dependency and auto-downloaded and run?

Of course I know nothing about how Terraform actually works... or if that attack would be possible. Realistically, someone would probably catch/report it shortly after discovery... but "proxying executables from community repositories" raises a big red flag for me.

Anyway, it'd be a lot of effort to build this into ProGet and I don't think we can really offer any value over a specialized basic free/open source tool that hosts these providers. Ultimately it'd be like an Asset directory, but slightly more restrictive and with an even worse UI ;)

I think if we're going to consider specialized feeds to host "non-package" files, we should probably start with like Git LFS... then Git repositories, and so on.

Anyway keep us posted on the journey; I'm sure this is one of those things you could built-out in an Asset Directory using pgutil and a ChatGPT-generated script to generate the index file.

Cheers,
Alex