@rhessinger Thank you!

We have identified the regression (PG-1830) and fixed it. It will be included in this week's maintenance release (ProGet 5.3.13), but you are also welcome to try the prerelease image right now if you would like - it's available as proget:5.3.13-ci.2 or progetmono:5.3.13-ci.2. Thanks for reporting the bug!

Hi @mike-vanoorschot_1180 We check for local requests using HttpRequest.IsLocal, which basically just looks for 127.0.0.1. If it's not local, then a license violation is recorded. If the server doesn't resolve proget.xxxx.com as 127.0.0.1, then configuring BaseUrl will be a problem, especially with NuGet. The NuGet API requires absolute urls (issue #1), and many API responses are just URLS that the client (in this case, the connector) must follow to get the "real answer" (issue #2). So this will trigger license violations. If you need to specify a BaseUrl (you really shouldn't have to), then you'll need add a /etc/hosts entry for proget.xxxx.com 127.0.0.1

For this, you could just disable the connector, and use a Promoted-package workflow, where you manually promote approved packages from one feed (Unapproved) to another feed (Approved). When the request is very simple, like "give me this exact version of this exact package", then it's not forwarded. But typically the request is, "what's the latest version of this package". Of course, that must be forwarded and aggregated against all connectors. Why the client makes such a request in some cases is a mystery, but that's why they rewrote everything from scratch into a new, v3 api.

Hi @nkerifacclaud_6931, Thanks for testing this out! I will get it released as a production version today! Thanks, Rich

Hi @mikhael_3947, I have updated our Docker documentation to include this information about using a proxy with ProGet. I have also included more information about insecure registries and using self-signed certificates with Docker registries, Thanks, Rich

Not at present, but it's definitely on our roadmap, but there's not a ton of demand for it so we haven't prioritized it. The primary usecase seems to be having a Otter or BuildMaster server in the cloud that in-house servers connect to. Is that what you were thinking?

Hi @david-osborne_4674, Are you able to pull successfully using npm and ProGet? Also, does your API Key have the Feed API right enabled or if you are impersonating a user, does that user have the ability to publish packages? Also, when you set your NPM auth using: [~]$ npm config set always-auth=true [~]$ npm config set _auth={ENCODEDAPIKEY} Are you base64 encoding your API Key using the format api:{APIKEY}. For example: If my API key is FakeApiKey, I would want to base 64 encode api:FakeApiKey would be YXBpOkZha2VBcGlLZXk=. So the commands to run would be: [~]$ npm config set always-auth=true [~]$ npm config set _auth=YXBpOkZha2VBcGlLZXk= Alternatively, you could use npm adduser to login. Here are some examples: If you ran the command to make ProGet your default repo: npm adduser --always-auth If you are using multiple repos: npm adduser --registry=http://progetrepo/feedname --always-auth If you are using scoped repos: npm adduser --registry=http://progetrepo/feedname --scope=@inedo --always-auth This way uses a username and password. If you want to use an API key, use API as the username as the API Key as the password. Hope this helps! Thanks, Rich

Ah ha, thanks! I updated the docs to include CommonCachePath instructions.

Hi @msimkin_1572, Looking at the Azure DevOps documentation here, you should be able to generate a personal access token (PAT) and connect to it using a username as anything and a password as the PAT. In ProGet 5.2, only NuGet v2 API's are supported, so make sure to follow the instructions for connecting it to a NuGet v2 client. In ProGet 5.3 and later, we have added NuGet v3 support. Could you give that a try? Thanks, Rich

Hi @dilshaat_6115, Glad you got it working! Just some extra information for you. The component name is dependent on the component name of the package you updated. In my case, I uploaded a package to ProGet using the main component. So I had to use deb http://192.168.55.103:8624/ hms-ubuntu main. Here is an example of how my package looked in ProGet. [image: 1600268252615-3abb0b34-2ef9-41f3-a4cc-c4868272370a-image.png] Thanks, Rich

Hello; I'm not able to reproduce this on the latest ProGet, and I'm thinking the problem may have been the package file was on disk from the previous version. Here's what I did: Create a new Feed with a connector to NuGet NuGet Download package using the URL /nuget/nuuget-public/package/ProxyKit/2.3.3+build.0 File on disk is ProxyKit.2.3.3.nupkg Cheers, Alana

We've got this fixed. If you'd like to try it, it's available as proget.inedo.com/productimages/inedo/progetcore:5.3.12-ci.1

Hi @bvandehey_9055, The URL you are using looks correct. IF you click on the Download button and the package actually downloads, then that verifies that it successfully connected. If it was failing to connect to WhiteSource, you would see a page that looks like this: [image: 1600177920154-67e1fc0d-3ddf-40d9-bb7b-a417385cb628-image.png] If you want to verify that ProGet is communicating with WhiteSource, I would just put in a bad value for WhiteSource and attempt to download the package from the ProGet UI. If you get a similar error to above, that verifies the communication to WhiteSource. Are you using the Product Name or the Product Token in the Product field in the configuration? I would try to use the product token first. If all of that is setup, then it is most likely an issue with the rules set up within WhiteSource. Thanks, Rich

Thanks for the detailed writeup! We've just published v1.0.1 of pgscan that should fix the issues you've described. v1.0.1 will now actually write errors and other info to the console like it's supposed to. There is also now a --api-key argument to allow it to authenticate with ProGet. Downloads are here: https://github.com/Inedo/pgscan/releases

@atripp I will try the progetcore when I manage to have some time but I can confirm the issue I reported was solved in proget v5.3.10. Thank you.

@rhessinger The issue was solved with v5.3.10 release. Thank you.

Thanks for updating and letting us know the problem was related to a connection string!

@jyip_5228 FYI, as part of ProGet 5.3.10 release, we shipped the ProGetCore container image as well. You can follow the normal steps in the Linux and Docker Installation Guide to install/upgrade, but just use progetcore for the container instead of proget. Aside from support for the Lucene-based Maven feed indexing (in progress), it seems to be feature complete. And of course, if there are problems, you can switch back to proget:5.3.10 or downgrade as needed (no database schema changes). For example, docker pull proget.inedo.com/productimages/inedo/progetcore:5.3.10

hi @scroak_6473 , just to let you know, as part of ProGet 5.3.10 release, we shipped the ProGetCore container image. You can follow the normal steps in the Linux and Docker Installation Guide to install/upgrade, but just use progetcore for the container instead of proget. Aside from support for the Lucene-based Maven feed indexing (in progress), it seems to be feature complete. And of course, if there are problems, you can switch back to proget:5.3.10 or downgrade as needed (no database schema changes). For example, docker pull proget.inedo.com/productimages/inedo/progetcore:5.3.10 Getting LDAP/LDAPS to work on Linux was a whole different problem to solve; the three major libraries (DotNetCore, Mono, Novell) all had separate and strange bugs. We'll be blogging about this, but for now, it might be a step in the right direction for addressing the problems you're seeing, at the very least.