Wait, what are you checking? I hope it is package signatures, not web server certificates.

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

So, to be clear, the linked thread is about rustup. If you don't install rust via rustup, then the above issue will never happen to you. By default, it's checking that you have an SSL connection, yes.

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

If rustup is the normal way to install rust, then that is exactly what I'd want to use. My employer would mirror the needed web sites. For example, my employer mirrors much of github and ubuntu and various Microsoft things. I just follow the normal instructions to fetch things on the internet, and it all works from the mirrored web sites.

It’s the default choice, yes. However, If you’re using Ubuntu you could also install it through apt, though you’ll get an older version.

Note how Ubuntu does things correctly, using signatures on the packages. I can copy those to any web site.

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

Installing via apt will not work for Windows users.

Sure, we check signatures too. (At least, Cargo does. I think rustup may not in some circumstances? I forget) It's about defense in depth.

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

Thanks for working on it!

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.

Yes, part of the issue here is that there hasn't been a ton of ownership on rustup, and even the Cargo team has not had as much time and effort as we'd like. We're currently working on growing both teams, which means better ownership, which means someone to make these calls.

> "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.

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

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 fine to say "let's clear this question up" and proceed to clear it up.

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.

It's not the big hammer that can't be argued with. There's a path forward there: bring in security experts to weigh in on this. This hasn't happened. It could, and when it does there may be progress.

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)

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

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...

> It's fine to say "let's clear this question up" and proceed to clear it up.

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.