-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ensure HTTPS is used for definition cache download #5184
Comments
Just checked the repository settings. Apparently Enforce HTTPS is not available "because your domain is not configured to support HTTPS: I think this has come up before. I guess we're waiting on @Ostera to reply here. According to the GitHub docs:
I didn't set it up, but I think the idea of using CloudFlare is due to the large number of requests that will likely hit archive.zip, Cloudflare can alleviate the probably high load from hitting GitHub. |
If TLDR's CloudFlare traffic is reasonably below 100 GB/month, then it fits within GitHub page usage guidelines "GitHub Pages sites have a soft bandwidth limit of 100GB per month." Alternatively (for high traffic situations), GitHub suggests "... making use of other GitHub features such as releases". So it seems that CloudFlare [proxying] isn't a must in any scenario. |
The domain is currently using the CloudFlare DNS, but I didn't do that set up. I only pointed the domain there. 🤔 Perhaps @waldyrious or @agnivade know more about that part of the infra? |
The DNS part of CloudFlare can stay. You just need to ensure that "orange cloud"/proxying part of CloudFlare is disabled for said domain record. See https://community.cloudflare.com/t/step-3-enabling-the-orange-cloud/52715 |
I have access to Cloudflare. Will take a look. |
Total bandwidth last month was 47.88 GB, in which 11.91 GB was cached. So CF is essentially serving 23% of the traffic only. We can bypass Cloudflare for sure, but wondering if it's possible to just point to |
If by "point to" you mean exchange link for definition cache in clients - that's doable. Several TLDR clients (official Python and Node included) currently use "http://tldr-pages.github.io/assets/tldr.zip". On another hand, I think(?) that TLDR client's are not auto-updated so anyone stuck on with older versions (pre such link change) would not benefit. Also from different angle, it would seem to be mandated to update CLIENT-SPECIFICATION making it a |
Great points. Agree with all of them.
Since this is anyways a cache, temporary outages in CF, if any, should be bearable. @sbrl @mebeim @owenvoke - if the above sounds reasonable to you, we should go ahead with the changes. |
This sounds like a reasonable solution. tldr.sh still points at GitHub - it's just a different domain name, correct? |
Yes, a different domain name fronted by CloudFlare. |
Not sure I understand what exactly you guys are suggesting to do. Do you mean we should contact all clients telling them to use another link? Which one is the "good" one precisely? |
Yes, that was my suggestion. The good link is "https://tldr.sh/assets/tldr.zip". The alternative is to bypass CloudFlare altogether. |
Perhaps an update to the client spec is in order. Specifically in this section: https://github.com/tldr-pages/tldr/blob/master/CLIENT-SPECIFICATION.md#caching ....we mention tldr.sh OR raw.githubusercontent? |
Haha then we should delay #5428 :) |
I would vote strongly for raw.githubusercontent.com. It is a well-known source of truth for GH resources and very unlikely to suffer issues (e.g. domain renewal, DNS, etc.) that wouldn't also affect |
Actually, using |
I'd say that we can simply add an -If appropriate, it is RECOMMENDED that clients implement a cache of pages. If implemented, clients MUST download the archive either from **[http://tldr.sh/assets/tldr.zip](http://tldr.sh/assets/tldr.zip)** or [https://raw.githubusercontent.com/tldr-pages/tldr-pages.github.io/master/assets/tldr.zip](https://raw.githubusercontent.com/tldr-pages/tldr-pages.github.io/master/assets/tldr.zip) (which is pointed to by the first link).
+If appropriate, it is RECOMMENDED that clients implement a cache of pages. If implemented, clients MUST download the archive either from **[https://tldr.sh/assets/tldr.zip](https://tldr.sh/assets/tldr.zip)** or [https://raw.githubusercontent.com/tldr-pages/tldr-pages.github.io/master/assets/tldr.zip](https://raw.githubusercontent.com/tldr-pages/tldr-pages.github.io/master/assets/tldr.zip) (which is pointed to by the first link). We can do this before merging #5428 (then update #5428 with the correct permalink) as @bl-ue suggests. In any case, a mailing list for tldr clients' developers seems like a good idea to notify of changes like this one, we could do this through a Google group. |
@mebeim see #5377 (comment). What do you think about it? |
@bl-ue I think it makes sense, I like the idea! |
Basically this is request to re-evaluate findings from #2253 (comment)
When default
tldr
client requests definition cache it does download https://tldr-pages.github.io/assets/tldr.zipProblem: The link has an unsecure/plain HTTP hop which can be seen using cURL:
The problem, obviously is
location: http://tldr.sh/assets/tldr.zip
reply header.As unsecure redirect is advised, the
tldr.zip
file can be trivially MITM'ed and poisoned by unknown party to do some nefarious command suggestion or exploit a (yet unknown) Markdown processing bug. Definition cache file is not cryptographically signed, therefore a malicious file detection on client side is impossible.Cause: Reading the discussion linked above it seems that
tldr-pages.github.io
repository's settings does not have "Enforce HTTPS" checkbox value selected due to a configuration conflict withtldr.sh
domain being fronted by Cloudflare CDN.Suggestion: Unless there's calculated benefit in using Cloudflare CDN to front apex
tldr.sh
domain a security conscious choice would be to use directA
record assignment for GitHub Pages (as described here). It would thus skip Cloudflare altogether and allow to toggle "Enforce HTTPS" in GitHub panel.The text was updated successfully, but these errors were encountered: