💡Provide binaries on pkg.cloudflare.com

[KianNH]

Describe the feature you'd like

Community reference: https://community.cloudflare.com/t/cloudflared-automated-download/418848

Someone suggested that the binaries should be available somewhere other than GitHub's releases.

As https://pkg.cloudflare.com only provides the deb/rpm packaging for use with package managers, it'd be good if it could also expose the same binaries that are published in GitHub releases.

Additional context

At a glance, it looks like it'd be pretty easy to add that functionality into https://github.com/cloudflare/cloudflared/blob/master/release_pkgs.py since it will already have access to the built binaries.

I guess the question is which path would they be exposed on, i.e https://pkg.cloudflare.com/cloudflared/binaries/

It'd also be good for a hash/checksum to be published alongside.

[sudarshan-reddy]

This is already done in our github Releases page. We can add a link to it. I dont see this changing because:

1. pkg.cloudflare.com is exclusively a packaging system for linux. Note that it doesn't even concern osx/windows.
2. Its nice to have a bit of redundancy. In the off change pkg.cloudflare.com is inaccessible, you'd still be able to download the binaries from github.

[KianNH]

pkg.cloudflare.com is exclusively a packaging system for linux. Note that it doesn't even concern osx/windows.

Fair enough! Good point about the other operating systems.

Its nice to have a bit of redundancy. In the off change pkg.cloudflare.com is inaccessible, you'd still be able to download the binaries from github.

For sure - but I think the user's perspective is that it isn't the same for the opposite perspective. Whilst you can always get the deb/rpm packaging, the raw binaries for Windows/Linux/MacOS are only available on GitHub.

I’m building a bare-metal implementation that manually downloads the latest cloudflared binary

I’m sure this was a temporary misconfiguration issue, and the problem eventually went away, but it occurred to me that Cloudflare really shouldn’t be hosting such a critical piece of infrastructure on github. I’m not suggesting that Microsoft has any bad intensions, but this is effectively a break in the zero-trust chain, because if you controlled github_com then you could inject a malicious cloudflared binary, one that is often downloaded in an automated/headless way, and one that serves as the SSL-termination point for all of the customer’s traffic. Beyond that, it makes github_com a dependency for your deployment pipeline, and they use AWS for DNS, not Cloudflare.

Ideally the user would be able to download cloudflared directly from cloudflare_com, or at a minimum download a signature/checksum for verification.

I suppose there might be way to extract them from the deb/rpm packaging but that adds a bit of complexity.

I've linked this issue to the user that made the quoted/original post in-case they're thinking of something else. I personally just use the apt or homebrew distributions but I can see the value in just having the binary as-is for some use-cases.

[sudarshan-reddy]

I see. We do publish checksums on our github page for this exact reason. Would that help this user?

[pmckinnon]

The problem is that if github.com is the host that delivers the cloudflared binary and also delivers the checksum, then there is no way to prove that github is delivering the binary that cloudflare expects it too.

Not that they would, but github could act as a man-in-the-middle and deliver a malicious cloudflared binary that would be blindly downloaded and executed by the customer.

At a minimum, the customer should be able to download checksums directly from *.cloudflare.com, so that the customer could verify that github is operating correctly (trust but verify).

Ideally, the customer could download the cloudflared binary directly from *.cloudflare.com so that github does not have to be a dependency in the customer's deployment pipeline (they are by no means immune from going down).