Yup, you're right, supply chain attacks are real! But how do you start a third party repo in the first place? You pull in from the outside, do your own audit, and then audit all code that you choose to merge into your third party repo! But that initial audit can be be... involved...
Using a rewriting tool like what I'm talking about is not a substitute for proper security practice, it's just another tool in the toolbox. It's best viewed like that, not as a panacea.
You just... do it? Like if you're going to write secure software to the degree that supply chain attacks are something you care about (which clearly you do, as evidenced by this discussion), you just do the audit. If you want some cool inference tools for review, sure, use rustanalyzer or whatever the hotness is. (As Scott points out, no such rewriting tool can actually exist, because inference is peformed on the HIR, not the AST).
Maybe see how existing security-oriented projects (like, say, firefox and chromium) do this. If this is a solved problem for C++ (a significantly more pathological language), I hardly see how it's a problem in Rust.
Yup, that's what you do. However, there is no reason to make this more difficult than it needs to be. Put another way, if I need to dig a hole for a swimming pool, I'd much prefer to use an excavator than try to do the same thing by hand using a shovel.
Even a tool that is only 80% of what is needed is better than nothing. An excavator will remove 80% of the dirt in a pool quickly and efficiently, but using it to dig out the steps leading into the pool is difficult and needs to be done by hand. Don't declare a tool useless just because it doesn't cover 100% of the cases!
It's not as strong as a theoretical impossibility though is it?
HIR could link back to source code spans etc..
If we go the way you want, we would need to reserve everything in the prelude too, since it can be shadowed too, with the same consequences on security.
That would be a breaking change and any further prelude change would be a breaking change too.
k#u8 via RFC 3098. I know that RFC was taken off the table in favor of RFC 3101, but that would solve the issue. And, yes, I know that u8 isn't a keyword, but my point is that there is a method of solving the issue.
That's exactly the point. This method is a breaking change that require at least a new edition and to be consistent, it would require to apply that to everything in the prelude. That would double the set of reserved words in the language.
Even if the escape mechanism allow to deal with that, that would be a huge impact.
You're right, it would be a huge impact, and I agree that it would at a minimum require waiting until the 2024 edition is out to be stabilized (if nothing else, RFC 3098 and RFC 3101 would need to be accepted, stabilized, and part of rustc first).
I want to be clear, I'm not for or against any particular method of dealing with this, as long as the chosen method solves the problem. If rustc had a rewrite flag added to it that rewrote most code so that you knew what the types were, that would be a reasonable 80% solution. If k#u8 were a part of the language, that would work too. If there were a switch (even an unstable switch!) that made all of the primitives and everything in the prelude unable to be shadowed, that would be an 80% solution too1. All I want is some way of quickly and easily verifying that certain basic types haven't been replaced behind my back, and I'm willing to entertain any ideas that help solve the issue.
1I know that it's common for crates to define their own version of Result, so it isn't possible to turn the primitive types and most of the prelude into a keyword with an unstable switch; this was part of the reason for a rewrite switch or k#u8 style tricks.
When you audit code and you see it's exporting something in a sneaky way, trying to shadow a built-in type name, that's a red flag. So in a sense that is making audit easier, because you can see the code is suspicious right away.
BTW: clippy has a suspicious lint category now. I encourage people to add lints that catch things like this.
This is why ::std::primitive::u8 exists. If you want to be super explicit, you can use that.
I really don't see a need for making these things keywords or otherwise reserved.
That's actually why I was thinking about a rewrite tool that made it clear as to the types of each variable. Once I see ::std::primitive::u8 after the rewrite is done, I know what the type is. The keyword solution was spitballing ideas to solve the problem. The rewrite tool is likely the better option anyways as it won't involve any breaking changes.
And, like I said earlier, I don't care what the solution is, as long as there is one. Given how difficult the problem can be, it will likely require a combination of techniques that complement one another.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.