@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

Hi @richard-carpenter_9650 , Thanks for confirming that; that is really strange. I just tried it msyefl and got the same result. The technical answer is that PowerShell gallery is sorting the feed alphabetically, and is only returning the top 100 entries. Of those entries, all but two are unlisted. So that's all you see. Not a great UX, so hopefully it goes away (i.e. they return the default sort order by downloads), or maybe we can sort differently ourselves. We're not too keen to change this, since it's the "very sensitive" legacy NuGet v2 API, but perhaps in v2023 we can alter this. Cheers, Steve

Hi @martin-noack_4528 , Nice points :) We added this to our ProGet 2023 roadmap as a "Nice to Have"; we're a little behind on the release now so I don't know if it will make it, but we will reevaluate after 2023.0 is released at that point. Cheers, Alana

Hi @js-enthoven_2797, Unfortunately I'm not very familiar with debugging apt :( The only one I was familiar with was the InRelease-related error, which you worked around. Otherwise, I haven't seen these before, but they seem to be warnings, so maybe it's okay and is working? It does say "All packages are up to date". I don't really know what they mean, or if it's related to ProGet, apt configuration, or the package I searched for the text of these errors ("No Hash entry in Release file"), and there are a lot of suggestions on what to do... they are all different, and I have no idea what might work. The "Connection timed out" is really strange too. Maybe it's related to proxy, or something? A blank page is to be expected if you have no packages in that scope; otherwise you will see a number of "Paragraphs", one for each package. Cheers, Alana

Hi @v-makkenze_6348, When you enable the preview feature for ProGet Vulnerability Central, ProGet will add a vulnerability source name PGVC automatically, but it will not show under the vulnerability sources. It looks like after you enabled that, you added a new ProGet Vulnerability Center (which will default the name to "ProGet Vulnerability Central"). So the ProGet Vulnerability Center source should be left off and can probably be removed. That is definitely what was causing a duplicate vulnerability. Thanks, Dan

Hi @atripp. Yes, that worked. Thank you for all the help. -marc

Hi @kichikawa_2913 , PG-2290 was the regression fix, and it was included in ProGet 2022.22 Cheers, Alana

Ok, no prob! Thank you!