I can confirm. This started failing today. Akamai is returning a 403 when retrieving the GPG key using curl or wget.

from cli.

It looks like the 403 error is because of the curl user agent. Doing the same request without the user agent (option -A "") works okay for me.

curl -A "" -L "https://packages.cloudfoundry.org/stable?release=linux64-binary&version=v7&source=github"

Further to the above:

• curl -A "cur" works
• curl -A "curl" fails with 403
  So it really looks like it's the curl user agent that's rejected.

from cli.

This access denied is also returned when trying to download compressed binaries with:

curl -L "https://packages.cloudfoundry.org/stable?release=linux64-binary&version=v7&source=github"

as per https://github.com/cloudfoundry/cli/blob/main/doc/installation-instructions/installation-instructions-v7.md#installers-and-compressed-binaries

from cli.

Getting the same access denied

`

Access Denied

You don't have permission to access "http://packages.cloudfoundry.org/stable?" on this server.

Reference #18.26701102.1679991638.9dbfd60

This was working well until yesterday late afternoon UTC+1

from cli.

It is also possible to use a custom user agent like for a standard Chrome browser to be able to retrieve the pgp key.
curl -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/111.0.0.0 Safari/537.36" https://packages.cloudfoundry.org/debian/cli.cloudfoundry.org.key

from cli.

Thanks for all the validation here! I was creating a build process using the CF cli for the first time yesterday. It worked in my first workflow but failed in my second and I couldn't understand what I had done wrong. Bad luck/timing it seems! 😆

from cli.

Thanks for all the validation here! I was creating a build process using the CF cli for the first time yesterday. It worked in my first workflow but failed in my second and I couldn't understand what I had done wrong. Bad luck/timing it seems! 😆

Haha, yes. Using it also in a couple of pipelines for my customers and they all mentioned the issue.
I've provided a fix on a alternative location from a manually download of the cli files.
This will be used if the endpoint would return a statuscode != 200

from cli.

We're looking into this issue. CC @ccjaimes

from cli.

This issue should be resolved by now. The primary reason is a new CDN security rule to fight bots. We will take additional steps to improve monitoring to respond faster to such incidents.

from cli.