Hi @sneh-patel_0294 , Here is the NuGet API Documentation: https://learn.microsoft.com/en-us/nuget/api/overview Here is the Packages API query you would want: https://docs.inedo.com/docs/proget/reference-api/proget-api-packages/proget-api-packages-list-versions#http-response-specification Regardless of what APi you use, you'll need to change your query strategy: Get a list of all versions of CPS.Regression from the server From that list, filter by 9.1 and then sort by latest that's not prerelease There are some sample scripts that might be helpful on our docs as well: https://docs.inedo.com/docs/proget/reference-api/proget-api-packages/proget-api-packages-list-versions#list-all-non-prerelease-versions-powershell Thanks, Alana

Hi @sebastien-gamby_3349, I don't see an option to do anything like that, but we're happy to brainstorm/think of an option to add. The main issue is documentation and avoiding having 1000 options. I see that there's a ---do-not-scan-node_modules switch; maybe that could be converted to a --excludePaths={relativePathCsv} or something? So ---do-not-scan-node_modules would become --excludePaths=node_modules and you could do --excludePaths="myproj1.csproj,myproj2.csproj" or something? Just brainstorming here, not sure if that's even feasible. Here is the current documentation for the command Description: Generates a minimal SBOM from project dependencies and uploads it to ProGet Usage: pgutil builds scan [options] Options: --input=<input> (REQUIRED) Project to scan for dependencies --project-name=<project-name> (REQUIRED) Name of the component consuming the dependencies --version=<version> (REQUIRED) Version of the component consuming the dependencies --api-key=<api-key> ProGet API key used to authorize access --do-not-scan-node_modules Do not scan the node_modules directory when scanning for package-lock.json files --include-dev-dependencies Include npm development dependencies from the package-lock.json file in the generated SBOM document --include-project-references Include dependencies from referenced projects in the generated SBOM document --password=<password> ProGet user password used to authorize access --project-type=<project-type> Type of the consuming project (default=library) --scanner-type=<scanner-type> Type of project scanner to use; auto, npm, NuGet, PyPI, or Conda (default=auto) --source=<source> Named source or URL of ProGet --username=<username> ProGet user name used to authorize access -?, --help Show help and usage information Examples: $> pgutil builds scan --input=WebDataTool.csproj --project-name="Web Data Tool" --version=1.2.3 ``

Hi @george_4088, That is correct, but a brute-force attack wouldn't succeed unless an administrator used something silly like admin for their username and password for their password. You could just as easily integrate with an LDAP/Active Directory server, which will add timeouts and account lockouts to make it impossible to "crack" in our lifetime. SAML is fine too. My point is that it's like 1000 times more likely that the API Key used to publish those Chocolatey packages would be exposed in logs, configuration files, etc. That's the attack surface you want to be careful of. Cheers, Alana

Hi @caterina, No problem, thanks for getting back to us. We have an upcoming release of pgutil that will include this flag. We also have improved this command a bit by allowing you to use the working directory which will search for the right files instead of --input having to specify the path to the file (although you still can). It will now also automatically audit the scan directly after, you can use --noaudit to skip the audit. We should have those updates pushed this week. Thanks, Rich

Hey Alana, thank you very much. Maybe this is some issue with our setup then. I will further check and investigate on our side first. :) Best, Frank

Hello @atripp Oups ! I made a mistake, I used master instead of main for the branch. It is working fine Sorry for this Best regards PhilippeC.

Hi @caterina , This will be fixed in the next maintenance release via PG-2829. I just checked in the change. I made a mistake when making the original change, and used the ProjectBuildId instead of the ProjectId when validating the if other builds exists. So it works if the Ids match perfectly (like when I tested it). Note this only impacts the UI, and we don't really expect users to create builds via the UI. Thanks, Alana

Thanks for answering me, clear !

Hi @pbspec2_5732 , The script in the linked gist should fix the problem for you; it's not feasible/possible to try editing in the database directly due to the complexity of the model. https://gist.github.com/apxltd/351d328023c1c32852c30c335952fabb Thanks, Steve

Thank you, that did the trick.

Hi @atripp , found this config. i remember seeing it and left it checked because the description recommended it for registries like microsoft and for some reason i didn't pay attention to this until i figured out that i need to add "library" prefix. thank you very much for all the help.

Hi @forbzie22_0253 , That's not exposed in the UI at this time; is there a reason/use case you'd want to use it? it's primarily intended as a kind of backup of sorts. Thanks, Alana

Had to set ownership on the folder on the Linux server, all green now thanks!

Hi @daniel-lundqvist_1790 , You can select the edition you'd like to trial within the software itself, under Admin > License Key. Thanks, Alana

Hi @zs-dahe , The Package Promotion API only be checks for permission against toFeed - you don't need any other permission on the toFeed or fromFeed. As far as more granular permissions, perhaps setting up a Personal Key for like a builds user would do the trick? That'll let you reuse the API Key and set up very granular permissions. We decided not to duplicate that granular permission setting in the API Keys because it's already confusing enough Thanks, Alex

@davidroberts63 thanks for figuring that one out, that's definitely bug... [image: 1729737434318-e3cfc738-e2b4-4b5e-8359-e7c732254f17-image.png] ... box style was correct, but enabled/disabled text looked at wrong property Easy fix, difficult to spot!

Hi @marc-ledent_9164 , Are you referring to the Machine UID from Manual Activation? I'm not sure what the Machine UID looks like in BuildMaster 7 on Linux, but I do recall that early versions of our products sometimes couldn't generate the string on some hardware. I think that's fixed now. The code is supposed to be based on the CPU (vendor ID, model, family, and stepping info) and the and the major version of the Inedo software (e.g. 5.1, 5.3, 2022, 2023). Thanks, Alana

Hi @gdivis, I've tried encoding the purl URL, and it works on both Windows and Linux, without having to interchange the distro and component order. However, it's a little strange that NuGet package purls work whether they are encoded or not. Anyway, I'm going to encode the URL in the code. Thank you very much.

Hi @caterina, We're a bit concerned that this is too specific for your usecase, and we're really struggling documenting it. Instead of doing this, we're thinking it might just make more sense to run (Get-Item 'C:\path\to\file.exe').VersionInfo using PowerShell and export these into variables instead. For Example: $versionInfo = (Get-Item 'C:\path\to\file.exe').VersionInfo $version = if($versionInfo.FileVersion) { $versionInfo.FileVersion} else { $versionInfo.ProductVersion } $productName = $versionInfo.ProductName pgutil builds scan --input=myApplication.csproj --project-name$productName" --version=$version Thanks, Dan