@ade8s_7742 so glad to hear that! It's really rare, but glad it wasn't database corruption!!

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 @kichikawa_2913 , PG-2290 was the regression fix, and it was included in ProGet 2022.22 Cheers, Alana

Hi @apxltd, thanks for the insights! I half expected this to be way more complicated than I had hoped for, but one can dream...

@jim-borden_4965 glad you got it working :) On Windows, you can just do an in-place upgrade of MSSQL, and not worry about database migrations. The same is probably true on Docker, and you can just upgrade container. Anyways safer to back-up. And if you haven't seen it already, here is the ProGet guidance: https://docs.inedo.com/docs/installation-backing-up-restoring

@curtis-denotter_1361 Were you able to resolve this? If so, what was the root cause?

@Dan_Woolf Sounds good, thanks for the response.

@shfunke_1795 @jrottmann_6111 @sdohle_3924 @bahues_9728 @appplat_4310 Thanks for insight into this! I'm happy to report that starting in ProGet 2023.22, you can create Alpine (APK) feeds with connectors :)

Hi @bushman_3007, Can you clarify the request some more, i.e. why are you wanting to delete soft-deleted directories? I don't know the reason directories are soft deleted, but I suspect it has to do with preserving versioning history. Thanks, Alana

Thanks for your suggestion, @atripp, that's definitely something we'll look into when we find time to do so. In the meantime we have implemented the workaround described above, so thanks again for your help.

Also: I did remove the second website as we want ProGet to be running on the default web site on port 443 (https).

cool, you guys are the best! I've updated the instructions for feeds to make it copy-pasteable for users, rather than having to edit out the options/variables. Naturally I hide the originals and only show the updated ones. Example: the builtin CURL instructions for a package: To download $PackageFullName from cURL, run the following command: curl $DownloadUrl[?contentOnly=[zip|tgz]] --output $PackageName.$PackageVersion.[zip|tgz] --user <user>:<password> I simplified it to: To download $PackageFullName from cURL, run the following command: curl $DownloadUrl?contentOnly=zip --output $PackageName.$PackageVersion.zip Powershell example: To download $PackageFullName from PowerShell, run the following command: Invoke-WebRequest $DownloadUrl[?contentOnly=[zip|tgz]] -Headers @{"AUTHORIZATION"="Basic " + [System.Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes("<user>:<password>"))} -OutFile $PackageName.$PackageVersion.[zip|tgz] simplified: To download $PackageFullName from PowerShell, run the following command: Invoke-WebRequest $DownloadUrl?contentOnly=zip -OutFile $PackageName.$PackageVersion.zip

Hi @zakaria-smahi_2127, That badge looks like something generated by a CI-server, and I think it's showing the latest version or tag or something related to a release branch? I don't have much context. It's not something that ProGet (a package manager) would generate, since all of the packages in ProGet are considered "published". Our CI/CD platform, BuildMaster, can generate these badges: https://docs.inedo.com/docs/buildmaster-ci-cd-continuous-integration-server-badges Cheers, Alana

@atripp Thanks for the pointers. Investigations did indeed reveal that proget was replying with the http url if FindPackagesById() request and that the subsequent redirect back to https was causing the credential to be dropped from the request. I've configured the BaseUrl with advanced settings and confirmed success with that in place. I now have a functioning proget instance and I'm able to efficiently work with the repo from Powershell. Much appreciated!

Hi @stevedennis, having a PackageLicense table would be great for two reasons: a) It would give as the ability to do some reporting on used licenses. b) There are lots of packages that use embedded license files. ProGet already has a feature where we can manually assign the corresponding license to a specific version of a package, but as far as I can tell, this is done by generating a pseudo URL for each package and assigning that URL to the corresponding license. While this does work fine as long as it is done only for a small number of packages, I'm not so sure how it affect usability (and maybe performance) when this is done on a larger scale. Having a separate table that connects packages (or package versions) to specific licenses might be a cleaner way to store and process that information. I'd have to check whether we could give you a dump of our database, but we are only just starting to use ProGet, so there isn't really too much data there yet. The fact that we are new to this is actually the reason we are so interested in reports about licenses and vulnerabilities: We are setting up workflows, etc. and at some point we want to completely block downloads of vulnerable packages or packages that use restrictive/unknown licenses, but before we activate hard filtering rules we want to get an overview on how this would affect products currently in development (so we can adapt our rules or define exceptions). At the moment we are generating data by integrating pgscan to our build pipelines and gathering download statistics for packages (and hope that we will be able to analyze that data in a useful way), so feel free to reach out in a month or so. Maybe we will have enough meaningful data to be of use for you guys by then. Cheers, Sebastian

@mcascone said in Proget: retention policy for branches in a package: This means mybranch and mybranch2 can be reduced to mybranch2. Sorry but wouldn't this be the reverse: *mybranch* will match *mybranch2*? What I mean to say.... because it's an AND conditional, the *mybranch* is effectively ignored. Everything that matches *mybranch2* will also match *mybranch*, but the opposite isn't true. E.g. mybranch1 won't match both conditions. @mcascone said in Proget: retention policy for branches in a package: in this feed, delete matches of 'mybranch', except the latest 3 versions of those matches, which would only impact the versions matching mybranch and leave all other non-matches untouched; Correct. And do note that you can set retention policies to run in dry mode, where nothing is deleted, to verify it's the behavior you want.

Thanks for clarifying this! I did a test run with a package that has not been downloaded before and it seems you are correct: The total downloads per version (on the "Overview" and "All Versions" tabs) are reset to zero, but the statistics under "Usage & Statistics" seem to be unaffected.

Hi @claes-hermansson_6271, Great! Our recommend three-feed workflow (unapproved, approved, internal) is similar, and keeps the third-party packages in the first two feeds. This way, you can scan for vulnerabilities much more easily. As I understand it though, to get full coverage the pgscan tool needs to be installed on every build server, and the pgscan publish... command needs to be implemented in every build? This is correct. Dependency resolution is complex and often nondeterministic, so it can only really happen at build-time. Hopefully you can templatize pretty easily :) Cheers, Steve

Hi @bryan-ellis_2367 , I'm not an Azure DevOps expert, but last I checked, it's not possible to add NuGet package sources other than it's own ADO Packages product or the public repositories. That may just refer to "upstream sources", but I'm not totally sure. However, if you want to use the ADO Pipeline's built-in NuGet commands to publish packages, I guess you can set up a service connection using this? https://docs.microsoft.com/en-us/azure/devops/pipelines/library/service-endpoints?view=azure-devops&tabs=yaml#nuget-service-connection Not totally sure -- but please let us know what you find :) Cheers, Alana

Hi @mail_6495 , Looks like this was a regression with API Key Authentication; the uploader control improperly required an API key. This will be fixed in PG-2104 on this Friday's maintenance key update. Cheers, Alana