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

Hello and thanks for the suggestions, @atripp! I tried doing an Invoke-WebRequest against the repository URL. It appears to work fine, which is nice but also a pain as it indicates the problem is more complicated. PS C:\> [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 PS C:\> $test = Invoke-WebRequest -UseBasicParsing "https://${progeturl}/nuget/${repository}/" Invoke-WebRequest: You must log in to issue this request because the anonymous user does not have the Feeds_ViewFeed privilege. PS C:\> PS C:\> $test = Invoke-WebRequest -UseBasicParsing "https://${progeturl}/nuget/${repository}/" -Credential $credential PS C:\> $test StatusCode : 200 StatusDescription : OK Content : <?xml version="1.0" encoding="utf-8"?><service xmlns="http://www.w3.org/2007/app"><workspace><title xmlns="http://www.w3.org/2005/Atom">Default</title><collection href="Packages"><title xmlns="http://…"> RawContent : HTTP/1.1 200 OK Cache-Control: no-store, must-revalidate, no-cache, max-age=0 Pragma: no-cache Server: Microsoft-IIS/10.0 X-ProGet-Version: 22.0.7.3 X-Powered-By: ASP.NET Date: Sat, 24 Sep 2022 … Headers : {[Cache-Control, System.String[]], [Pragma, System.String[]], [Server, System.String[]], [X-ProGet-Version, System.String[]]…} Images : {} InputFields : {} Links : {} RawContentLength : 273 RelationLink : {} PS C:\> echo $test.Content <?xml version="1.0" encoding="utf-8"?><service xmlns="http://www.w3.org/2007/app"><workspace><title xmlns="http://www.w3.org/2005/Atom">Default</title><collection href="Packages"><title xmlns="http://www.w3.org/2005/Atom">Packages</title></collection></workspace></service> I will attempt to use a tool like Wireshark or Fiddler to see what's going on.

@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

Hi, Thanks for reporting this. We've now fixed this internally as PG-2105 - it will be included in this week's 6.0.9 release, scheduled for Friday. -Greg

Hello; Does your server have Internet access? That is an ancient version of the Inedo Hub... I would uninstall the Inedo Hub, and then download it again. Hopefully the error will be resolved then. Cheers, Nanci