Hi @mhelp_5176,
Connecting to the embedded database requires local access to the ProGet server. Once an attacker has that, then they already have full access to the database, as it's stored as files on disk... basically it's the equivalent of storing the safe key inside of the safe :)
As such. it doesn't make sense for us to add complexity to the product to support changing a password that's already secured.
Thanks,
Steve
Hello,
Thanks for reporting this; this behavior is by design.
ProGet uses authentication tickets (i.e. encrypted cookies). If the username on a valid ticket cannot be located in the user directory, then a "user not found" error will occur, as it did here.
This errant behavior is generally desired for troubleshooting cases where users are intermittently not available from a user directory. Otherwise it's very difficult to troubleshoot, since it will just appear as a random log-out.
Thanks,
Steve
Hi @mhelp_5176 ,
Provided you provided appropriate permissions, there shouldn't be an issue configuring the service to run as a gSMA.
Thanks,
Alana
Hi @mhelp_5176,
Not at this time; this would add complexity to the software and installation, so we're hesitant to give an option to configure this path without a compelling technical benefit.
Given your requirements, perhaps they should just configure the %ProgramData% folder to be on a different drive? Many Windows programs use that location for data like this.
Or perhaps configure a junction (soft link).
Thanks,
Alana
Hi @jens-viebig_4541 ,
In very early versions of ProGet, we would filter specific versions from connectors (i.e. remote feeds/repositories) but it caused all sorts of problems due to client (i.e. npm, nuget, etc.) behavior and server API (npmjs.com, nuget.org) limitations. But the biggest problem was Developer Experience, and the fact that the behavior was simply befuddling.
When "random" versions suddenly go missing from the API, users will see a totally different dependency resolution result. Sometimes it would yield build failures.
Troubleshooting this is an pain in the ass, especially for those nested dependencies, since the client provides no useful information. They can see the versions of "their packages" are both in npmjs.com and ProGet. The end result is end users saying, dependency resolution with ProGet is broken, so we just use npmjs.com instead.
Long story short, I don't image we will return to filtering specific versions. It just causes more problems for everyone for no real benefit.
As for addressing malicious packages, this is simply a risk you have to accept. The question is how much Developer Experience you want to sacrifice to minimize the risk.
First, you really can't rely on malicious packages ever being discovered . I mean, just look at the XZ Utils (CVE-2024-3094) backdoor; that kind of code could be in any library you're using now. So, the first step has nothing to do with Malicious Packages... but it's to make sure all of your apps are deployed under a Minimally Viable Security Posture (MSVP) and track which dependencies go where using ProGet's SCA capabilities.
That said, if you do absolutely nothing, chances are you will be totally fine. As we wrote in Changes to Malicious Package Handling in 2025.20 and Beyond: the overwhelming majority of malicious packages are basically bot-created spam that no one will ever see, let alone use. These packages don’t rely on typos, but instead random, “package-sounding” names generated by some LLM.
In addition, Microsoft/GitHub seems to be undoing the braindead npm design descision to run arbitrary scripts at install time. I'm shocked that terrible idea survived this long. So, that will significantly reduce the attack vector, as developer machines can no longer be compromised by simply installing a package.
That said, the risk of harm caused by newly-published malicious packages pale in comparison to the real harm caused by regressions from constant upgrades. There's about a 0% chance of being harmed by a malicious package, but nearly a 100% chance of having problems when your developers always upgrade.
So, it's a good idea to say newly published packages (like 30 days, not 1 day) are noncompliant. You'll just need to figure out how to balance Developer Experience with that. We have a lot of options, from using Package Approval Workflows (pretty heavy handed) to allowing exceptions for single packages.
We do not recommend blocking noncompliant packages, especially for npm. Instead, use pgutil builds scan as discussed here: https://guides.inedo.com/vulnerability-management/containment/
I understand that pnpm has some kind of rule you can configure to not resolve "newer" dependencies. So you could just set that to like 31 days, and set ProGet's to like 29 days. Or 15 days, 14 days.
But a single day isn't going to do anything for you, except provide a false sense of security while maintaining the real risk of regressions from a "always upgrade" culture.
--
Finally... as for what Sonatype does, I'm skeptical. Based on the many customers that migrated from Nexus to ProGet, there's a rather large gap in advertised features and functionality, especially when it comes to stuff like this. Just taking a quick look, that feature looks defunct anyway and likely doesn't get much/any use.
Regardless, filtering versions from feeds causes problems than it solves, so it really doesn't make sense to do.
Hope that helps,
Alex
Hi @imm0rtalsupp0rt ,
We've published a version of the article now:
https://docs.inedo.com/docs/proget/feeds/chocolatey/howto-chocolatey-proxyccr
Let us know your thoughts or freel free to submit a PR should have have any suggestions!
Thanks,
Alex
@sigurd-hansen_7559 wow very cool! We didn't anticipate anyone would customize these templates beyond adding a variable or two, so it it didn't seem to make a lot of sense to invest in a proper editor (like we have in the other products)
Anyway, it'd be interesting to see what kind of templates you develop.
Hi @alkhleif_2585 ,
There isn't much demand for this kind of feature (I think we've only seen one or two requests for this over very many years) so it's not on our roadmap.
And it's unlikely we will add it to the roadmap considering that it would be quite costly to build, support, and maintain. Especially considering that we'd need to support all of the major "vaults" out there as well.
It doesn't seem to add much value to ProGet as these types of read-only credentials can be very long living (several years) without any security risk, and take just a few minutes to rotate when needed.
That being said, you could probably write a "sync script" pretty easily that continuously updates the connector credentials by connecting to the vault and then updating it via the API.
Cheers,
Steve
Hi @vdubrovskyi_1854 ,
Without knowing which specific package you're referring to, it's hard to give a more specific example.
Historically, Packagist was effectively a database of "GitHub Repository pointers" and Composer was effectively just a wrapper around the Git client. They can both still operate in that mode, and needs to for older, non-standard packages. I suspect that's the type of package you're referring to here.
ProGet's Composer feeds work with "packages" (i.e. not the GitHub pointers), which account for nearly all of the modern packages on Packagist.org. For the small number of packages that don't follow the standard (mostly older, legacy packages), you'll need to download them, properly package them, and then upload them to follow the standard.
Unfortunately there's no technically feasible/sensible way to solve this problem - since it would require ProGet to serve as a GitHub pointer database, which just doesn't make sense.
Cheers,
Steve
Hi @Nils-Nilsson ,
It's possible but it's quite complex; there are dozens of variable/macros that rely on context (some will give an error) and none of them have built-in dummy data. That would make templating expressions like <% if %> or <% foreach %> difficult to test.
In theory, you could enter a large box of variable expressions (like $FeedName=fake-feed)... but at that point, it's just easier to test things by performing the actions on a real package. A quick pgutil packages delete + pgutil packages upload script works great for that... that's how we test.
Thanks,
Alana
