4 ms·

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

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

Tomte 7y ago
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.
- wyldfire 7y ago
  > 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/3316/113 https://internals.rust-lang.org/t/beta-testing-rustup-rs/331...
- staticassertion 7y ago
  > 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.
- Manishearth 7y ago
  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)

Tomte 7y ago

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.

wyldfire 7y ago
> 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/3316/113 https://internals.rust-lang.org/t/beta-testing-rustup-rs/331...
staticassertion 7y ago
> 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.
Manishearth 7y ago
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)