-
-
Notifications
You must be signed in to change notification settings - Fork 62
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
Only https for requests #124
Comments
Probably not, though at the moment changing this (to enforce https) may be a breaking change. I think it's probably pretty safe but if possible it would be nice to investigate the crates.io index for binstall metadata to see what's in use. Also worth considering on this topic would be to forbid downgrade to TLS <1.2. |
As a process note I'm busy for the next 1-2 weeks so if you want to submit PRs there's plenty of time until next I do a release, unless ryan decides to do one in the meantime. |
Sry that might be my language barrier, but do I get that right? Basically look into the |
In Rust there's the concept of a "crater run", where every crate in crates.io registry is tested against something. It's a way to estimate how much changing something will break, or if a particular pattern is used. With binstall, this is even more relevant because crates.io is where we look for configuration for each crate. So it is essentially possible to download the entire index and parse every single manifest available and see exactly what is being used as configuration for binstall support in the wild. What you're proposing here is to forbid non-https. From a security standpoint, that's great! However, from a compatibility point of view, it's not great. If any crate has binstall metadata that points to an http URL for install, that change will break it. So what I'm saying is that the idea is fine, and the security would be improved, but I would prefer to see a registry-wide survey of all binstall-enabled crates for what protocol it uses. In the likely event that no crate uses anything else than https, then great! We know that at that moment in time we can make the change and not break anything. If a small non-zero number of crates have those, however, we can make a different plan, like deprecating http support for a version, opening issues on all affected crates, and eventually removing support. Also I think a registry-wide survey would tell us how many crates support binstall, which could be a pretty cool metric. |
Quickly threw some scrappy stuff together https://github.com/somehowchris/rust-crates-index-metrics let see if it actually works and what it will spit out |
#152 adds a warning on an HTTP URL, which is a start, pending further ecosystem investigation. |
#189 adds cmdline option for https only mode and for specifing the minimum TLS version. |
Given we've had zero negative feedback with the warning, I propose we kill plaintext HTTP mode in the next release but make it possible to allow with a cfg(feature) so we can quickly revert or provide the opportunity on a case by case basis, and then remove the feature in 2023. |
Actually the crates people are okay with someone downloading "all the crates" so long as it's a one off / very occasional, and have given some advice on how to do that: https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/Query.20the.20whole.20index/near/294605605 I'll see about putting together a little tool and survey the index for binstall crates. |
@passcod Can you also collect the repository field if the I'm interested in which git hosting services they are using though I bet most of them is using github and some of them is using gitlab/bitbucket/sourceforge.
Also I think the survey should ignore all non-binary crates. |
Okay, so:
Let me know (on twitter or in other issues, so as to not clog up this thread) if you want more queries! |
From this I think we can immediately remove HTTP and be done with it. URLs that are |
Quickly looking over some request code, it seems to me that binaries are also allowed to be downloaded over
http
. Am I missing something? Is there are reason to allow this?reqwest
has a client builder flaghttps_only
but it is disabled by defaultThe text was updated successfully, but these errors were encountered: