Hi @markus-karthaus_8928, The validity check of a certificate ion ProGet is primarily to verify the certificate itself is valid, not if it is valid for ProGet. Any self-signed or internal domain certificate will be invalid by default unless the certificate or certificate authority exists in the trusted root on your server. If it is a purchased certificate, I would check that your certificate's chain is properly installed on your server. If your certificate is a valid certificate but requires a custom certificate chain (many do), that chain will need to be installed on the server for ProGet to validate that properly. A .pfx certificate does not store the certificate chain internally in the file. The browser handles the validation slightly differently, so that is most likely why it seems to work in the browser. When it comes to the .pem file. There are many ways to generate it, but I'm guessing the certificate chain was stored internally in the pem file, which then does not require the certificate chain to be installed on the server. I'm speculating on the certificate chain in these cases because seeing why your certificate is not valid requires more than the screenshots you provided. I would actually need to see your certificate itself to truly validate this. Lastly, when it comes to using a .pem file, .NET tends to be very picky about it's format. It is not as forgiving as other frameworks. If you look in the "HTTPS Binding to a Port (Advanced) (Experimental)" of our HTTPS Support on Windows documentation, we have instructions on how to create a .pem file from a .pfx. I'm not sure if that is what you followed, but that is the simplest way we have found to generate a .pem file that works with .NET. Hope this helps! Thanks, Rich

I pulled the ci.4 image and that fixed the issue. I haven't noticed any other issues, so I'll just leave the ci version installed until the next ProGet release. Thanks again for the quick fix.

@reincarnator247_4909 If you open a ticket can you post it here so I can follow along as well. Or do we have a solution? To me, a call the the /health endpoint should always actually check if things are okay, not assume its okay because something is cached.

Hi @h-morgenthaler_3015, Alana was correct, the change was not merged into the 2023 release. The fix, PG-2350, will be released on Friday in ProGet 2023.4. If you need it earlier than Friday, I can push a pre-release version of ProGet 2023.4 for you. Please let me know! Thanks, Rich

Hello, unfortunately we really don't know what the underlying issue could be. Perhaps it's only an error on the "test" button, and the plug-in will work? This is not an Inedo-created plugin, and we're not familiar with Java or Jenkins to know how to to debug it. It should still work (and I know we have some users who got it working), but otherwise we don't really know how to debug it I'm afraid :( The source code is here, but I don't know if it's at all helpful: https://github.com/jenkinsci/inedo-proget-plugin Cheers, Alana

Hi @jimbobmcgee , The "Secret key" field is just an arbitrary string that needs to match on both the Agent and the Otter Server; it needs to be unique across your servers, as its used to uniquely identify an incoming agent connection. The UI generates a random string, but you can enter whatever you'd like. There needs to be a Server record on the Otter server (i.e. on the "Servers" page) before an agent can connect to Otter. This is true for either Incoming or Outgoing communication modes. This is often called "server registration". One option is to servers self-register in Incoming mode; you can have the the following script on first boot: Generate a random string ("secret key"); you could use a GUID use the Infrastructure API from the server to "register" the server using that key edit the agent configuration file to have that key start the Inedo agent service Hope that helps, Alana

I believe this has already been fixed as part of PG-2343 in v2023.3, which we are releasing today. In addition to being slow, the NuGet queries responsible for handling latest versions could return a lot more results than necessary. It didn't lead to incorrect behavior (except with counts) as we still validate and filter results in the frontend, but did cause problems like this.

This is now fixed in 2023.3, which is going to be released later today. Thank you!

@gdivis thank you!

Hi @atripp, I just tested the implementation of this with ProGet 2023.1 with the aforementioned atob npm package. The filtering works perfect. The package uses "MIT OR Apache-2.0", and as long as at least one of those two licenses is configured as allowed, the package can be downloaded. Only when both licenses are configured as "blocked", the package is also blocked. This works 100% as expected! When I check the general page of the atob package, "License Information" on the "Overview" tab displays both licenses and their corresponding blocking configurations correctly. However, when I go to a specific version, the version's "Overview" tab will always state This package has a MIT license, and may be used because of configured license filtering policies, even if MIT is actually blocked and only Apache-2.0 is allowed. This only changes when both licenses are blocked (In which case the page states Packages with the MIT license cannot be downloaded due to a global license rule). Looks like this is just optics. As I said, the blocking itself seems to work exactly as expected.

Hi @jw , The version number is a bit buried in the logs I believe, but it sounds like things are working now... and it's too much of a guessing game to figure out what might have happened now. Cheers, Steve

Hi @markus-karthaus_8928, The HTTP/S & Certificate Settings page will update the ProGet.config file that is commonly stored at C:\ProgramData\Inedo\SharedConfig\ProGet.config. As long as the inedoprogetwebsvc Window's service's account has write access to that file, it will be able to save. On fresh installs, this will typically work without requiring changes. My guess is something was changed with the executing user or the server permissions that is preventing write access to that configuration file. You can also manually setup HTTPS by editing the ProGet.config file directly. See the "HTTPS Binding to a Port (Advanced) (Experimental)" section of our HTTPS Support on Windows documenation for the different options. Thanks, Rich

Version 2022.24 (Build 5) has an option to unlist all packages on an ID. [image: 1683098461924-proget.nuget.unlist.png]

This issue was resolved, as there was an authentication issue that was failing silently.

Hi @msimkin_1572 , good idea! I just added a small note at the bottom, where we specify manifest. To be honest, I didn't even know that was possible

Hi @itsoftware_2704 , We don't have instructions specific for Docker containers, but you basically just need to run the ProGet.Service.exe resetadminpassword command on the container. And then restart the container. Here is more information on what this does:; https://docs.inedo.com/docs/installation-security-ldap-active-directory I'm not very well versed in Docker, so I don't know the exact way to run that command - but in the interest of giving you an answer right away, I wanted to share this. Hoping you know how to though :) Feel free to share how you ran the command, in case someone else runs into this thread! Cheers, Steve

Hi @Justinvolved , Oooh - I thought we removed those flags/notices from BuildMaster 2022 Looks like we only removed the code that clears them, and almost all of the code that sets them (with the exception of the CEIP page). Anyway, I've vanquished the code for good via BM-3839. In the mean time, please run sql this command to clear the notices: DELETE [Configuration] WHERE [Key_Name] IN ('Service.DelayExecutionsWhenRestartRequested','Service.RestartRequested', 'Web.RestartRequested') Cheers, Alana

Hi @d-gleissner_8620 , The best way to handle this scenario is with two feeds (unapproved and approved packages); install from the unapproved in your development environment, and then to promote packages (in bulk) from the unapproved to the approved feed. Unfortunately, it's not feasible for a tool like ProGet to handle dependency resolution; a dependency is specified as a range (for example, PackageA requires PackageB 3.2 or later), and it's up to the environment (i.e. the client doing the installation, PSGet) to determine which dependencies are currently available and not available. For example, if you already had "PackageB 3.3" installed, then PowerShell would not install it, even if "Package B 3.4" is the latest version. It gets even more complicated when it comes to platform dependencies and all that. Ultimately, ProGet can't have such environmental knowledge. hoep that helps! Cheers, Alana