Also, this doesn't have anything to do with Windows support that I can see.

It went from "rebase and I'll merge" to not a single word anymore about how it might be merged.

The Windows support thing is this: rustup/curl doesn't use Windows' own certificate store. Where employers put the TLS certificate for their intercepting proxies.

curl itself has the -k option, so the user can override the check (much, much easier than preparing a certificate bundle for curl – and since the employer intercepts and decrypts the traffic anyway, there is no security issue).

rustup calls curl without that flag. The pull request was to teach rustup to call curl with -k.

(I know that it doesn't solve the whole problem, because cargo itself needs to support it, as well)

If you must use an older rustup, set `$env:RUSTUP_USE_REQWEST` (or `$env:RUSTUP_USE_HYPER` for an even older rustup) to `1`

I must say, this is a rather dramatized way to frame the discussion in the linked PR, which, indeed, hasn't been closed and is still ongoing.

For security, my normal software development environment is off the internet. I can mirror a web site, but https would be trouble.

You can fully build and develop Rust projects offline; this is a hard requirement of things like Debian and Firefox, for example.

Doing things that way helps you too. Mirrors, including caches, are easy to set up.

Installing via apt will not work for Windows users.

I am a Windows user, I know that. That's why i said "if" :)

But I still think someone "official" should have weighed in and reined in the "what about security?" people.

That was pure ignorance. The security angle has been discussed, and "I don't know much about it, so let's kill it" is a really bad precedent.

> "I don't know much about it, so let's kill it" is a really bad precedent.

I would agree, but a "completely ignore security" flag is something to be cautious about.

I feel the opposite. Where user safety is concerned, if a problem is not understood the solution should not be implemented.

In an example where it's "disable security feature X", and the developers don't know the implication, would you really want them to just say "well whatever, I don't understand the implications, but let's push forward" ?

It's not fine to use security as the big hammer that cannot be argued with, and then – nothing happens. At least not publically. Note that there wasn't even a word where it might be discussed.

I actually went looking for Rust development mailing lists, but found no discussion.

Rust doesn't quite have a team for this yet (there's a security WG slowly spinning up though) which probably explains why it's kinda stalled.

Ultimately there's no obligation here for the team to do the legwork for this PR anyway. It's blocked on something, and while that's resolvable you can't blame the team for not pushing on it.

(I did just ping someone knowledgeable in security matters about this, let's see what they say)

Here's a time [1] when someone mentioned rustup in context with TLS (it's release notes for 0.1.9). It's not that there's no forum to discuss these things.

If the discussion is missing, it's likely because it hasn't mattered enough for anyone to bring up yet. Rust is much more bazaar than cathedral. A GH issue like "my company's MITM proxy breaks rustup" doesn't mean that the Rust dev team drops what they're doing and rallys to solve this problem. Even if it comes with a PR, it doesn't mean that Rust should be forced to either accept the PR or shift resources to make the PR satisfactory.

> It's not fine to use security as the big hammer that cannot be argued with

People place an enormous amount of trust in their compiler and the tools ecosystem that surrounds it. It's extremely wise to be hesitant to permit an opt-out for a security feature.

Here's the real crux of the matter: if one wants a feature in your favorite open source project, they kinda have to be willing to hustle a bit. Nag some design owners about what is unsatisfactory about your proposed approach and what other design options might work instead. For all of the examples that you might find in other languages' ecosystems that already support this kind of a feature, you should be thankful that someone before you came across the problem and doggedly pursued a solution. But it's not a systemic problem that Rust doesn't have a solution yet: just another feature-in-development in the queue.

> and then – nothing happens

This is remarkably common among open source projects. Code contributions wither on the vine because it can sometimes be a lot more work than someone's interested in to push it upstream. IMO Rust is actually better than the average open source project in this regard (meaning fewer orphaned patches).

[1] https://internals.rust-lang.org/t/beta-testing-rustup-rs/331...

I think the issue is that no one had the expertise to clear it up. So how do you move forward?

Someone has to get called in and there's no process for that. Or the person pushing the feature needs to explain the security implications of the feature.

Maybe some sort of 'requires security triage' tag could get applied to issues like this, and the rust security wg or whoever is qualified ot make these calls could review.

Ultimately, my opinion is that if you're making a PR with security implications, and there are people saying "I'm uncomfortable and don't understand the security implications", it's on you to explain them.

Otherwise progress should not continue.

IMO those corporate environments are reaping what they sow. We shouldn't be so quick to disable TLS. Who would be to blame if those corporate environments found rustup as an attack channel for getting trojans? My guess is that rust would be a convenient scapegoat in that case.

Also, I believe that some of them may create intercept exceptions for 'legitimate' software distribution channels (like pip/npm/etc). Maybe they just need one for crates.io.

Because it's signed by a company certificate in the certificate store.

also, there are now alternative crate registering.