serve the rust-lang.org domain over https #13180
Comments
thestinger
changed the title
|
This should apply to all subdomains ( @brson, what’s needed for this to happen? |
|
I hadn’t realized that #16123 was only about static.rust-lang.org and links to it. www.rust-lang.org and doc.rust-lang.org should of course be HTTPS as well. Could this be re-opened? |
|
Presuming the If you went with self-signed certs sitting behind the Cloudflare protection, you'd actually spend less per year than it'd cost purchasing a wildcard cert to cover everything. Cloudflare allows you to stick self-signed certs on the server without it raising an enormous browser red-flag. Reasonably easy to setup, as well. |
|
It might also make sense to use whatever setup we already use for static.rust-lang.org. CC @brson |
|
The rust website is hosted on GitHub pages. It would need to be hosted somewhere else to serve it over https. |
|
It looks really bad when I see a big project like this that still hasn't gotten HTTPS on their website. What exactly is blocking this? It shouldn't be hard to do. If the current hosting can't provide it, it should be changed. |
|
Yes, thanks :) |
|
To do this we need to frob the nginx config to redirect www.rust-lang.org to GitHub pages, then update the DNS to point to the nginx server. |
|
It'd also be pretty great if Rust became the third language in the "Good" category on https://httpswatch.com/programming#programming-languages |
|
I don't want this to come off as aggressive, but I'm genuinely wondering why this is taking so long? This shouldn't take more than 20 minutes to set up. Setting up a MITM attack to change the download links to malicious links is trivial, not to mention not having HTTPS is just plain unprofessional. |
|
Status: https://www.rust-lang.org/ fixes the original issue of this ticket. http://rust-lang.org redirects to https://www.rust-lang.org. rust-lang/prev.rust-lang.org#165 will handle the issues raised in the ensuing discussion. At least we're up to "mediocre" on https://httpswatch.com/programming#programming-languages 😒 |
|
Yay! Nice work! (This issue should probably be closed now.) |
|
The github's certificate is still in use for https://blog.rust-lang.org (rust-lang/blog.rust-lang.org#81). |
…_arg, r=DesmondWillowbrook
New assist: move_format_string_arg
The name might need some improving.
```rust
fn main() {
print!("{x + 1}");
}
```
to
```rust
fn main() {
print!("{}"$0, x + 1);
}
```
fixes rust-lang#13180
ref to rust-lang#5988 for similar work
* extracted `format_like`'s parser to it's own module in `ide-db`
* reworked the parser's API to be more direct
* added assist to extract expressions in format args
Simplify lint deprecation A couple of small changes: * A few deprecations were changed to renames. They all had a message similar to "this lint has been replaced by ..." which is just describing a rename. * The website and warning message are now the same. The website description was usually just a wordier version that contained no extra information. This can be worked around if needed, but I don't think that will happen. * The legacy deprecations have been removed. rustc should handle this since it already suggests adding the `clippy::` for all lints (deprecated or not) when they're used without it. It wouldn't be a problem to add them back in. * The website no longer has a "view source" link for deprecated lints since they're no longer read from the HIR tree. I could store the line number, but the link seems totally useless for these lints. This came up as part of separating the internal lints into their own crate. Both the metadata collector and the lint registration code needs access to the deprecated and renamed lists. This form lets all the deprecations be a separate crate. r? `@flip1995` changelog: none
I don't think there's really any need to have http for the site at all. Any non-TLS location is a chance for an attacker to send users to a malicious download.
The text was updated successfully, but these errors were encountered: