AutoOpen in the empty namespace as malicious code vector

[DalekBaldwin]

I noticed this while trying to excise unexpected uses of YoLo.fs in projects that depend (even if only transitively) on Http.Fs: haf/Http.fs#176 . While this particular case does not appear to be malicious, and merely makes it harder to remove the dependency, it is easy to see how it could be exploited in a malicious way.

Typically an AutoOpen attribute is declared on a module in a nonempty namespace, so that open-ing the namespace will implicitly open the module. Of course, consumers of external packages should always take care when using open declarations of external packages' namespaces and modules. However, in the empty namespace, this will happen unconditionally with no open usage at all, and, since there is currently no good standard way to disable transitive NuGet package references ( dotnet/sdk#11803 ), the AutoOpen will transitively infect all packages and projects that depend on the offending package.

While the F# style guide advises programmers to take care in using AutoOpen and RequireQualifiedAccess in their own code, there is nothing stopping a library author from abusing AutoOpen in this way to e.g. typo-squat a malicious definition onto a standard type or module and infecting even codebases that are very careful about managing their dependencies.

I propose that the compiler should not honor AutoOpen declarations on modules declared in the empty namespace.

[vzarytovskii]

We allow auto-open on assembly too, so it's not something unexpected. Not entirely sure we can change the behaviour, since it will be breaking. We can consider it as an additional analyser (external or built-in) in the future.