Hi @daniel.mccoy_4395 ,

This is how unlisted packages are designed to work; it's just a flag in the metadata, and clients will treat it however they'd like. Visual Studio hides them but lets you download them, ProGet shows them with a little "unlisted" icon.

As for the download error, the 400 sounds like you've configured "download blocking" perhaps? Check the feed's policy settings.

We generally don't recommend configuring download blocking, but using pgutil builds scan instead; see https://guides.inedo.com/vulnerability-management/containment/

Hope that helps,

Steve

Hi @olivier-piron_7128 ,

I'm afraid this behavior is somewhat expected because TRK.0 is not a valid version number.

ProGet has some limited support for invalid version numbers, but this use case falls into one of those unsupported cases.

The reason is that ProGet is "package server" (as opposed to a file server), and all of the maven-metadata.xml files are generated by ProGet, on demand, based on items in the database. Uploads of maven-metadata.xml are simply ignored.

Compare this to Nexus (a file server), which serves the client-uploaded maven-metadata.xml files, and whatever other items were uploaded to whatever directory.

TRK.0-SNAPSHOT is technically a valid artifact name but an invalid version number, so it's treated like an artifact. And, since there are no releases of that package, you get a 404.

In this case, we would suggest you to switch to using actual version numbers. My guess is that TRK.0 is some kind of work-around for something. You could instead do 9999.9.9 or something, if you needed that kind of work-around.

Hope that helps,
Steve

Hi @jeremy-oaks_9309 ,

Just wanted to respond to this real quick:

I have ~80k packages (~600GB) -- so we're opting for the stand-alone database for performance purposes

Based on this information we still recommend using the embedded database; it's almost always going to be more performant as well as simpler to maintain. 80k is not that many packages by any stretch.

While @pg_user_8607 is correct in that it's a bit easier to monitor database performance, investigate issues like bad queries, and do DBA maintenance tasks - that's all technically "our job". From a user perspective, the only required "database maintenance" should be backing up the files.

We certainly don't mind the help (and users like @pg_user_8607 have helped us out a lot!!), and it may be quicker if you "know what you're doing" to get to a root issue, since we're not all exactly experts at all these layers. But I just wanted to make sure you were aware of the pros-and-cons.

Thanks,
Steve

Hi @gbeckett ,

There are Feed Names (which you can configure) and API endpoints (which you cannot configure).

Our general guidance on feed names is internal-nuget or public-nuget, but we've seen cases where a lot of feeds are needed. I suppose tenant namespace like tenant1-nuget might work too. But like naming of everything else, you'll figure it out as you go.

While you can't change API endpoints, you could use the alternative /endpoints url if you really wanted. So instead of /nuget/public-nuget it would be /endpoints/public-nuget. Honestly I wouldn't bother... it's just a URL that no one really sees, and that's actually going to make it more of a pain to support. That's why we don't expose this.

Some ecosystems (like Docker) only support one registry per domain/port, which is why Docker feeds have no prefix. We work-around this by using namespaces.

One option I'm considering is layer a proxy in front of ProGet, to provide the URL rewriting to map to ProGet-compatible names.

Please don't do this :) We do not recommend nor do we support URL rewriting like this. People have figured out how to do it, but it causes lot of headaches and it will be painful to debug. Which is why we don't support it. Again... it's just a URL that no one really sees after you enter it.

Hope that helps!

Thanks,
Steve

Hi @brandon_owensby_2976,

I wasn't able to reproduce this issue, but looking over the code, I can see a few scenarios in which "not configured to allow access to encrypted values" will trigger, even if that's not accurate. It's not trivial to rewrite that to provide a more accurate error message or credential resolution, so we'll add this to our BuildMAter 2027t roadmap and review it more closely then.

In the meantime, I would just use a variable and duplicate the information.

Thanks,
Steve

Hi @brandon_owensby_2976 ,

You are correct, the $BranchName function is a build-information function that provides which branch a build was created from. It's a slightly different concept than the "default branch" that is associated with a release.

If changing your workflow to align with more standard practices isn't in the cards, then you may want to create a custom extension that will allow you to create your own variable functions and operations. This will make adding things like this easy and if it's something we think is generally useful, then we can generally add it in.

Although it's not supported in the SDK, if you take a reference to the core assembly (buildmaster.dll), you can invoke database commands like Releases_GetRelease to find that information easily.

Thanks,
steve

Hi @andreas-unverdorben_1551 ,

I'm afraid this is a problem with our upstream source (GHSA). Long story short, the datafile is incorrect and does not specify a range.

We do not have any plans to build a system/module that allows us to "override" data in the upstream datasources at this time, so the only way we can really address it is by fixing the upstream source.

I believe the best route to do that would be to submit a pull request to the GHSA repository against the related datafiles (e.g. GHSA-4r6h-8v6p-xvw6.json)

In this case, they are missing a "fixed" event in the range:

      "ranges": [
        {
          "type": "ECOSYSTEM",
          "events": [
            {
              "introduced": "0"
            }
          ]
        }
      ]

Here's what it needs to look like:

      "ranges": [
        {
          "type": "ECOSYSTEM",
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": " 0.19.3"
            }
          ]
        }
      ]

Thanks,
Steve

Hi @brandon_owensby_2976 ,

You can configure release settings on an application-by-application basis under the Settings tab. In this case, you'd set Release Usage to be Optional or Disabled.

If Release Usage is set to Required, users must select a release when creating a new build; this was the deefault in older versions of BuildMaster.

https://docs.inedo.com/docs/buildmaster/modeling-your-applications/buildmaster-releases

Cheers,
Steve

@Nils-Nilsson excellent, let us know as you have other feedback too! This is definitely an area we intend to keep improving in throughout ProGet 2026+

Hi @carl-westman_8110 ,

Thanks for sharing that. This isn't a symptom of "server overload" that we've seen before.

The error you shared is occurring on Feeds_GetFeeds, which is definitely not an intensive query, and I would not expect that to be timing out at all. It's just SELECT * FROM [Feeds].

However, that's a similar symptom to the "AzureSQL resource throttling" that we've seen on other users: another query is being throttled (for example, something that joins on [Feeds]), and that is causing a cascading impact on other queries.

We don't have enough information to say that's the case here. But, an easy way to test would be to up your DTUs substantially.

Otherwise, the next troubleshooting step is to try to identify the cause of the timeouts, which involves looking at HTTP Access logs and jobs occurring around the same time under Admin > Scheduled Jobs.

Thanks,
Steve

Hi @carl-westman_8110 ,

Under Admin > Diagnostic Center, you should see some error-level messages logged. Can you share those? That will help us identify what the actual error messages are.

Under Admin > Scheduled Jobs, what do you see scheduled at midnight? Are you aware of other external scheduled jobs, for example backup or nightly builds?

One thing to be aware of... users with similar symptoms have discovered they were "rate limited" by Azure SQL. This doesn't lead to resource graph spikes or "419 errors" (like an API rate limit), but query throttling; some queries simply take 100x longer. And this eventually leads to random errors.

I think 10DTU is relatively small, so this could be happening? Anyway the error messages will show.

This may be a good opportunity to migrate to PostgreSQL, which will not have any kind of limits.

Thanks,
Steve

Hi @Ashley ,

Amazing, thanks for this investigation! This is very helpful.

You've also captured the exact issue we have with a lot of these APIs; no real specs (or worse... wrong specs), which involves a reverse engineering effort. This quote is wonderful:

In summary, due to the lack of an official JSON schema and potential changes between npm versions, it's crucial to treat the npm audit --json output structure as subject to change. Relying solely on the npm CLI source code for the most accurate and up-to-date information is recommended, along with implementing robust version checks and testing in your development processes.

Wouldn't it be nice if we could build our products like that! Anyway, I was curious and I asked internally, and the original engineer is almost certain that npmjs used to have the CVE number there, which we also used to emit until changing to PGVD number in ProGet 2023. But that is consistent with their position of "we don't do specs, just read the latest commit to figure it out.

But it doesn't really matter, that's what we have now...

To ensure consistency with the public npm registry, would it be possible to change ProGet to use a number for the id field on the audit response?

If you discovered this in ProGet 2025, we'd just change it in ProGet 2026 and not worry about it. But we need to be super-careful making API changes in a maintenance release. We can't quite get away with Microsoft/GitHub levels of quality :)

Seemingly harmless changes lead to broken builds, which are really painful to debug; for example, we recently added upload-time to PyPI API. That caused older versions of the pip client to break due to a bug in how they parsed dates.

There are probably too many client/versions to answer the question "what is this field even used for and what are the consequences of changing it?"

Perhaps an easier route is to just get pnmp to change to a string, like the rest of them? Or, just ignore it and "let it be"?

Over time, if you follow our recommend best practices, these audits will show fewer and fewer vulnerabilities. We plan to continuously refine the PVRS algorithm to better combat both "vulnslop" (i.e. AI-discovered and AI-generated vulnerabilities that cannot be exploited in any real-world scenario nor would cause any real-world harm if so) and misreporting.

Thanks,
Steve

Hi @Ashley ,

Thanks for the detailed information. I haven't set up an npm/pnpm environment to test this, but I wanted to share a few thoughts, and see if you can test something.

I doubt the encoding is an issue.

Idea 1: Different API Endpoints

There are two vulnerability APIs, and I think one is kind of deprecated? Anyway ProGet has never implemented that one.

If you haven't already, I'd make sure pnpm is calling the same endpoint.

Idea 2: Null Severity

In the example you provided, severity is only set on one of the three items. If this is the problem, then it would mean that pnpm is erroring when processing the resultset.

This will be trivial to verify: can you (temporarily) override the assessment of PGV-262413Y and PGV-262413X to be Contain? Then, run it again. You should see a "critical" serverity in the results then.

That being said, this is a bug. These vulnerabilities should be suppressed and not show up in the results at all; we'll fix that via PG-3317.

Idea 3: Nonnumeric Id

The other possibility; ProGet is using a string identifier, but npm is using an integer identifier. I suspect that npm used to do CVEs that field, but who knows. None of this is documented.

I'm not really sure how how test this without some kind of proxy/MITM interception, or reverse-engineering their source code.

Maybe this is a GitHub issue on the pnpm repository?

Thanks,
Steve

Hi @svc-4x9p2a_6341 ,

This is known issue and will be addressed via PG-3309 in the next maintenance release. You can just ignore the messages for the time being, it only happens like once a week or so.... I wouldn't modify the database either.

Thanks,
Steve

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

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

It should have been; I just double-checked and see a commit for "Add full PEP 700 conformance for PyPI feeds" that appears to add the fields discussed here and some more.

Thanks,
Steve