@atripp hi, i already searched the internet and found nothing helpful. this is why i turned to you . as said, i will start over and try to give you the output. thanks, udi

Hi @atripp , Thanks for the suggestions. Concerning the LogMessages table, we already have those messages displayed on the OpenShift console, but nothing suspect can be seen. What I'll try is to test a fresh install of the last BuildMaster version and see what difference we have with our "updated" version. I'll keep you in touch. Marc

Hi @paul-kendik_9721 , It looks like you're on the right track with troubleshooting -- the issue is indeed related to SSL/Certificates. This is all handled at the operating system level, which means there's nothing we can do on the application (i.e. ProGet) side of things. Unfortunately, I've never seen this error on a modern Windows server so I don't know what exactly to suggest to fix. I didn't even know TLS 1.0 was enabled on Windows still. Maybe it's not even the server, but like a proxy or some kind of intermediate server? The "good news" is that this is an easily searchable problem, so I would start by searching for "Windows 2022 SSL HandshakeFailure TLS 1.0" and see what comes up. There is certainly some kind of setting on your server taht is causing this problem, I just don't know what to suggest to look for. Please let us know wat you find! Alana

@daniel-lundqvist_1790 no problem.. docker is really confusing/silly... , glad we got it solved :)

@atripp Thanks for your reply... This is a good reason to planify an upgrade! Marc

According to https://docs.inedo.com/docs/proget/feeds/other-types the Composer feed type is planned for a maintenance release of ProGet 2024, which is great news! We're currently using Satis for PHP packages alongside ProGet (for NuGet, npm, Python). Working with Satis is a bit cumbersome, that's why we would very much prefer using ProGet for PHP packages, too. Satis downloads the distribution zips for all packages and generates a static site with package metadata and the zips. I guess ProGet will handle Composer feeds in a similar fashion? Feel free to reach out to me via email if you need further feedback or beta testers for the Composer feed type.

Hi @steviecoaster , Very cool, looking forward to the packages! Here is the URL for the ProGet license agreement: https://inedo.com/proget/license-agreement The Inedo Hub does not have a separate license agreement, we just consider it part of the product; so you can just use ProGet's: https://inedo.com/proget/license-agreement Thanks, Nanci

Hi @Dony-Thomas_7156 , You can ignore these errors. ProGet doesn't process these requests (i.e. store the content); instead ProGet simply generates the appropriate hash of a maven artifact when you request .ext.md5, etc. It's dynamic, not a file system. That said, I do know that later versions of ProGet will simply return a 200 so that it does'nt cause an error with Marvin. I recommend to upload to the latest ProGet 2024, and use the New Maven feeds. Thanks, Alana

@atripp Thanks for the response. Seems we are using a quite old version of Proget - Version 2022.25 (Build 9). We are planning to upgrade it in a few months, but didn't think it would cause issues. We might have to wait for an upgrade to our systems to get this fixed then.

Hi @daniel-lundqvist_1790 , Good question! ProGet 2024 ships with the latest version of all available extensions, so there's usually not going to be a new one unless we add ones later (e.g. GCP) or update/fix ones. Most extensions are used by BuildMaster; for example, the Jenkins extension lets you do cool stuff like import/orchestrate Jenkins servers and deploy artifacts from them: https://docs.inedo.com/docs/buildmaster/tools-service-integrations/buildmaster-integrations-jenkins Thanks, Alana

Hi @forbzie22_0253 , We have never seen a case where changing an IIS setting has benefited performance in any way whatsoever; instead we have only found headaches and problems from users modifying them. Those settings are not designed for modern .NET applications, but for like .NET Framework, classic ASP, etc. So please don't touch them :) Thanks, Alana

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 !