# Glob imports can shadow built-in types
**URL:** https://internals.rust-lang.org/t/glob-imports-can-shadow-built-in-types/15151
**Category:** language design
**Created:** [August 6, 2021, 1:25pm UTC](https://internals.rust-lang.org/t/glob-imports-can-shadow-built-in-types/15151 "2021-08-06T13:25:05Z")
**Posts on this page:** 12
**Page:** 2
### Author:  [@ckaran](https://internals.rust-lang.org/u/ckaran)
#### Post date: [August 9, 2021, 8:01pm UTC](https://internals.rust-lang.org/t/glob-imports-can-shadow-built-in-types/15151/21 "2021-08-09T20:01:50Z")
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.
---
### Author:  [@mcy](https://internals.rust-lang.org/u/mcy)
#### Post date: [August 10, 2021, 1:22am UTC](https://internals.rust-lang.org/t/glob-imports-can-shadow-built-in-types/15151/22 "2021-08-10T01:22:48Z")
> [@ckaran](#):
>
> But that initial audit can be be... involved...
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.
---
### Author:  [@ckaran](https://internals.rust-lang.org/u/ckaran)
#### Post date: [August 10, 2021, 12:09pm UTC](https://internals.rust-lang.org/t/glob-imports-can-shadow-built-in-types/15151/23 "2021-08-10T12:09:18Z")
> [@mcy](#):
>
> You just... do it?
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.
> [@mcy](#):
>
> (As Scott points out, no such rewriting tool can _actually_ exist, because inference is peformed on the HIR, not the AST).
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!
---
### Author:  [@atagunov](https://internals.rust-lang.org/u/atagunov)
#### Post date: [August 10, 2021, 4:36pm UTC](https://internals.rust-lang.org/t/glob-imports-can-shadow-built-in-types/15151/24 "2021-08-10T16:36:44Z")
> [@mcy](#):
>
> As Scott points out, no such rewriting tool can _actually_ exist, because inference is peformed on the HIR, not the AST
It's not as strong as a theoretical impossibility though is it?
HIR could link back to source code spans etc..
---
### Author:  [@Uther](https://internals.rust-lang.org/u/Uther)
#### Post date: [August 11, 2021, 5:19am UTC](https://internals.rust-lang.org/t/glob-imports-can-shadow-built-in-types/15151/25 "2021-08-11T05:19:06Z")
> [@ckaran](#):
>
> I still want `(i|u)(8|16|32|64|128|size)` + `f(32|64)` to be reserved by rust though; the fact that it's possible to redefine them is a security hole waiting to happen...
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.
---
### Author:  [@ckaran](https://internals.rust-lang.org/u/ckaran)
#### Post date: [August 11, 2021, 8:06pm UTC](https://internals.rust-lang.org/t/glob-imports-can-shadow-built-in-types/15151/26 "2021-08-11T20:06:04Z")
> [@Uther](#):
>
> 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](https://github.com/rust-lang/rfcs/pull/3098). I know that RFC was taken off the table in favor of [RFC 3101](https://github.com/rust-lang/rfcs/blob/master/text/3101-reserved_prefixes.md), 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.
---
### Author:  [@Uther](https://internals.rust-lang.org/u/Uther)
#### Post date: [August 12, 2021, 6:22am UTC](https://internals.rust-lang.org/t/glob-imports-can-shadow-built-in-types/15151/27 "2021-08-12T06:22:07Z")
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.
---
### Author:  [@ckaran](https://internals.rust-lang.org/u/ckaran)
#### Post date: [August 12, 2021, 1:06pm UTC](https://internals.rust-lang.org/t/glob-imports-can-shadow-built-in-types/15151/28 "2021-08-12T13:06:08Z")
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](https://github.com/rust-lang/rfcs/pull/3098) and [RFC 3101](https://github.com/rust-lang/rfcs/blob/master/text/3101-reserved_prefixes.md) 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.
---
### Author:  [@kornel](https://internals.rust-lang.org/u/kornel)
#### Post date: [August 12, 2021, 1:07pm UTC](https://internals.rust-lang.org/t/glob-imports-can-shadow-built-in-types/15151/29 "2021-08-12T13:07:31Z")
> [@ckaran](#):
>
> Yup, that's what you do. However, there is _no_ reason to make this more difficult than it needs to be.
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.
---
### Author:  [@scottmcm](https://internals.rust-lang.org/u/scottmcm)
#### Post date: [August 13, 2021, 12:40am UTC](https://internals.rust-lang.org/t/glob-imports-can-shadow-built-in-types/15151/30 "2021-08-13T00:40:31Z")
> [@ckaran](#):
>
> I'm not for or against any particular method of dealing with this, as long as the chosen method solves the problem.
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_.
---
### Author:  [@ckaran](https://internals.rust-lang.org/u/ckaran)
#### Post date: [August 17, 2021, 1:21pm UTC](https://internals.rust-lang.org/t/glob-imports-can-shadow-built-in-types/15151/31 "2021-08-17T13:21:04Z")
> [@scottmcm](#):
>
> 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](https://internals.rust-lang.org/t/glob-imports-can-shadow-built-in-types/15151/28), 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.
---
### Author:  [@system](https://internals.rust-lang.org/u/system)
#### Post date: [November 15, 2021, 1:21pm UTC](https://internals.rust-lang.org/t/glob-imports-can-shadow-built-in-types/15151/32 "2021-11-15T13:21:21Z")
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
[Previous page](https://internals.rust-lang.org/t/glob-imports-can-shadow-built-in-types/15151.md?page=1)