Hi Steve,
thanks for the explanation. I also think creating a PR for GHSA would be the best way to go. Since your company is incorporating GHSA into your product I think it's up to Inedo to improve GHSA by creating this PR, thus improving your product for you customers.
Thanks,
Andreas
ProGet 2025.22
The multiple versions of the npm package xlsx (https://www.npmjs.com/package/xlsx) are affected by vulnerabilities https://security.inedo.com/vulnerability/details/PGV-2330205 and https://security.inedo.com/vulnerability/details/PGV-2425402.
Newer versions which are no longer affected by those vulnerabilities are not available on npmjs.com but can be downloaded via https://cdn.sheetjs.com/ (as noted in the vulnerability database entry details).
I've downloaded version 0.20.3 of xlsx and uploaded it to our ProGet npm feed since our developers and CI/CD pipelines are required to pull all packages from ProGet and not directly from internet sources.
Even though xlsx 0.20.3 is not affected by the two vulnerabilities mentioned above ProGet is still reporting the package version to be affected, because the "version declaration" in the vulnerability database matches ALL versions ("*").
Please update the entries in the Inedo vulnerability database accordingly.
Hi Dean,
we noticed that when performing an "npm install" against ProGet it will successively open ~1000 sessions.
We tried a couple of values for Web.ConcurrentRequestLimit under "Administration --> Advanced Setting" (20, 50, 100, 200) and found out, that when using 100 we get the same (or even better) performance for an "npm install" compared to registry.npmjs.org. We're not exactly sure how Web.ConcurrentRequestLimit works but we assume that it has some relation to the default pool size for the SQL Server connection used by ProGet, which also seems to be 100.
I just wanted to let you know, that by setting Web.ConcurrentRequestLimit to 100 the performance of "npm install" is back to normal.
Best,
Andreas
Hi Dean,
we noticed that when performing an "npm install" against ProGet it will successively open ~1000 sessions and shortly after that a number of the aforementioned timeout errors will be logged.
We tried a couple of values for Web.ConcurrentRequestLimit under "Administration --> Advanced Setting" (20, 50, 100, 200) and found out, that when using 100 we get the same (or even better) performance for an "npm install" compared to registry.npmjs.org. We're not exactly sure how Web.ConcurrentRequestLimit works but we assume that it has some relation to the default pool size for the SQL Server connection used by ProGet, which also seems to be 100.
I just wanted to let you know, that by setting Web.ConcurrentRequestLimit to 100 we're no longer seeing these kind of errors being logged and also the performance of "npm install" is back to normal.
Best,
Andreas
@dean-houston Thank you for your insights.
The logged exceptions all occurred when I was doing an "npm install" with a small sample project while being the sole user of the ProGet instance in question. The "npm install" resulted in 727 packages being installed. As far as I can tell, that's a pretty normal scenario and one should not expect this to be overly demanding for a package server.
That being said, I'm fully aware of the fact that ProGet has a lot of things to do in this scenario. We've stopped using the NuGet v2 API some time ago but we won't be able to reduce connector usage as this feature is one of the primary reasons for us to use ProGet in the first place. ProGet being able to act as a "filtering proxy" for public package registries that allows us to block access to packages based on license type or vulnerabilies is the reason why all of our developers must install the packages from our ProGet instance instead of public registries.
So for now I think we need to have a look at setting up a server cluster.
Thanks again!
Hi,
when running package restores (npm and NuGet packages) we're seeing many timouts being logged on ProGet Version 2023.27 (Build 5):
What's possibly going wrong here? Is there anything we can do to avoid these?
Thanks in advance!
Andreas
Hi,
we're currently running ProGet Version 2023.27 (Build 5). We have a npm feed configured as a proxy feed for https://registry.npmjs.org.
We've noticed that npm install is significantly slower when using our proxy feed (compared to directly installing from npmjs.org) even when all requested packages are cached on the ProGet server.
Our test scenario ist this:
empty npm cache
delete node_modues directory
delete package-lock.json file
run npm install
Results:
ProGet: 02m35s
npmjs.org: 00m38s
= ~4x slower with ProGet
Is anyone else experiencing the same behavior? Any tips how to speed things up with ProGet?`
Thanks in advance!
Andreas