@pg_user_8607 Given the fix is about searching in AD I think the pull request is indeed related, as there is no other error I can find other than unable to find the user(s) in the User Directories Test.

Hi @brandon_owensby_2976 , Thanks for the feedback, we appreciate it :) There's definitely a value in building before merging; if you haven't already, I'd check out that feature branch article, as it outlines the pattern we use for it. In general, the way I would try to configure is: consider using a releaseless-build if you don't yet know the release it's targeting use a different piepline so it's visually clear; the stages may be Build -> Test -> Merge clean up the builds aftewards That said, this isn't the most popular workflow in BuildMaster, so it may not be the most intuitive to implement or feel a bit clunky. We don't have a lot of public examples, but the inedo-docs application is the closest to a Gitflow, releaseless type of workflow. Commits to master branch auto-deploy to live site, where as branches can only go to test: https://buildmaster.inedo.com/applications/136/overview No idea if that's helpful, but just FYI Cheers, Alana

@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 @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, I was on a short vacation but today I upgraded to 2026.3 (build 14) without any problems. This probably fixed it: PG-3299 2026.3 FIX: Hostname based binding fails when hosting on Windows with HTTP.SYS Kind regards, Valentijn

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

@jens-viebig_4541 ooh good catch! That guidance is outdated as of ProGet 2026, where we no longer recommend/default to blocking Noncompliant packages. We should rewrite/republish the article to be more focused on guidance, update the screenshots, etc. I'll add that to the list.

Hi @cssccmgroup_4090, I created a private ticket on your behalf. You can see it by navigating to https://my.inedo.com/tickets. Please upload the SBOM through that ticket. Thanks, Dan

Hi @atripp, We have now updated to ProGet 2026.3 and can confirm this is now working as expected. Thank you for your prompt help.

Thank you very much for the detailed answer!

Hi Alana, Just wanted to let you know that restarting the service did fix the issue. Thank you for the suggestion. Brandon

Hi @gdivis , thanks for the quick turnaround. Everything is working as expected with the new version. Cheers

Thanks a lot @atripp for the quick fix. Problem solved Cheers -Fritz

Thanks for the quick turn around. We are happy to wait for next release, and can report back if we find any further issues.

Hi @joris-guex, I took a look at the ProGet change and talked with a couple of other Engineers and it looks like the issue is that the lobssh2-sys package is not included the version requirement on a dependency. According to cargo's specifications, the version specification is required. We are guessing that crates.io is handling the issue (whether it is a missing version or extra whitespace included in the manifest) and outputting it in a way it works with the cargo client. Could you please provide us with an example Cargo.toml that can recreate the build issues? This will allow us to implement a better solution to this issue. Thanks, Dan

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