Repository navigation
Use the MetadataLoadContext to restore reflection-only type discovery for mechanisms like using assembly #6653
Description
See #3641. Types needed in PowerShell classes must be available at parse-time (i.e. not loaded with Import-Module or Add-Type) to be able to compile classes to IL.
To be able to resolve these types, we want to support the using assembly statement. However, the most available way to do this involves loading a DLL and possibly executing some of its code, presenting a vector for arbitrary code execution.
Instead, we should analyse a DLL's metadata to discover the types it exports, using a System.Reflection.Metadata.MetadataReader. Example code for this is in PR #3169. The entry point for this analysis would be the PowerShellModuleAssemblyAnalyzer class.
The right way to do this is now to use a MetadataLoadContext
Reacted by Luca Hostettler
Reacted by Patrick Meinecke, Rain Sallow (/u/ta11ow), Flavien MICHALECZEK, Thomas Nieto, Oisin Grehan and Luca Hostettler
Activity
iSazonov commentedon Apr 15, 2018
Should we thing about PowerShell classes too? I mean getting PowerShell classes at parse time from PowerShell modules.
PetSerAl commentedon Apr 15, 2018
Ilya (@iSazonov)
Is not
using modulealready do that?iSazonov commentedon Apr 15, 2018
I don't know.
rjmholt commentedon May 2, 2018
Ilya (@iSazonov) when you say "getting PowerShell classes at parse time" do you mean loading?
That's basically what happens with
using module. Since we have a nice PowerShell parser that we know doesn't run any code, we read in the class definitions with it and then compile them to .NET IL. So the parser is already able to resolve PowerShell-class-defined types at parse time.The problem is that we don't have a nice .NET IL parser that we know doesn't run any code (and we only need the IL metadata anyway, to discover what types are available). corefx ships one, but it's pretty low level and documentation on it is sparse. Last time I wrote something using it, I used their tests for guidance. But it should be relatively straightforward.
iSazonov commentedon May 3, 2018
Rob Holt (@rjmholt) You could look our new
Add-Typecmdlet - it has a code to retrieve types from assemblies (to check duplications).iSazonov commentedon Jun 28, 2019
It makes sense to use MetadataReader in our TypeResolver too - it seems we load dozens of assemblies unnecessarily.
rjmholt commentedon Jul 28, 2020
The metadata reader implementation from us is no longer required, since dotnet/corefx#33201. We should now just use that
[-]Implement a `MetadataReader` from `System.Reflection.Metadata` to support `using assembly`[/-][+]Use the MetadataLoadContext to restore reflection-only type discovery for mechanisms like using assembly[/+]daxian-dbw commentedon Jun 10, 2021
rjmholt commentedon Jun 10, 2021
I think the scenario here was to make class definition that depends on
using assemblyandusing modulestill safe, so that script files can be parsed and type check successfully without the risk of running an arbitrary DLL on the filesystem.Much of this isn't actually required, but the discussion in that issue seems to indicate a preference for going down that path.
I suspect a lot of these implementation discussions should really be had secondary to a design review of classes in some sense, but the available tooling in .NET has moved to a point that makes more things possible.
microsoft-github-policy-service commentedon Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commentedon Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commentedon Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commentedon Nov 23, 2023
This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes.