runtime: PublishAot brings in Microsoft.DotNet.ILCompiler and causes AppLocker issue

I agree that an extracted bat file is problematic. Executables, dlls and even powershell scripts can be signed with digital cert, but bat file can’t.

The 8.0.100 SDK has been shipped in this form and we are finding workaround that works for you. In the future versions the design may be changed based on feedback. Please also be mindful that restrictions sometimes can provide a false sense of security.

Thanks for creating an unwelcome environment and derailing the report. Have a nice day.

You’ve had a really rude tone from the start towards everybody. I suggest you stop, it’s unnecessary.

@hamarb123 And when everybody jumps off the bridge, you jump too, because why not?

You’re the one jumping off the bridge by not checking the packages are safe… If you’re not validating the trustworthiness of every part of each nuget package, or deciding that you trust some providers, you have no idea what you’re running on your computer.

If you had validated the nuget packages you installed, then you’d already have known there was a script before you installed it (which was done by enabling NAOT), if not, then you’re the one deciding not to validate if they’re safe thoroughly. The fact that you’re surprised that lots of nuget packages utilise this feature means that either: you just happened to have not used any of them, which is not very likely, or you haven’t been validating their safety, which would make your whole argument of “batch file unsafe if in user folder” “I no want batch file in that folder” meaningless for the reasons I’ve already described.

Its not an argument that someone else does something.

I don’t quite know what you’re referring to here, but if you’re referring to me giving examples of things that specific nuget packages which do potentially run arbitrary code without you having a closer look, including 1 which uses a script file, then, I’ll remind you that you said:

Where are those very common nuget packages that do this?

Going through hacks to trick the setup into this is not an option for me. If this cant work out of the box, then i can not use this feature.

If it was a “hack”, then I doubt it would be so easy to work around - it would probably require you to modify some .targets files or similar, or something much more atrocious, if support for this flag wasn’t built in.

Is NativeAOT enabled out of the box? No. You have to set a flag for it in the csproj or when you publish; therefore you can’t use it anyway since it “doesn’t work out of the box” and requires “hacks” like settings a flag.

The above 2 statements are intended to point out the fallacy of your statement.

If you are saying this is so common, then how comes that this is the first time this impacts me? Where are those very common nuget packages that do this? Or are you the special unicorn that does this?

Did you know that nuget packages can actually download exes, dlls, and whatever else they want, and run them at compile time? They can even execute arbitrary C# code, which gets compiled and executed by msbuild. Hope that’s in line with your company policy. One batch file is not an issue compared to all of this. Downloading an untrusted nuget package is the security issue, once you’ve downloaded it, you’ve already failed security.

Most nuget packages, which aren’t just a simple C# project compiled into a nuget package, have at least target files (which can already basically do anything). For example, I went onto nuget.org, and the second top package has targets files, which, again, can run arbitrary code, so if you haven’t checked every file in every nuget package before installing it, then you have no idea what code is being run.

If you want a non-microsoft one, then top ~4th non-Microsoft one (depending how you count), AWSSDK.Core, has a powershell script in it.

No one here is allowed to execute scripts or executables from untrusted locations.

What’s the definition of “executable” for managed application? Is it the launcher dotnet.exe, or the dll? What if a process load an unmanaged dll, or a managed assembly?

If you are able to run roslyn analyzer installed via NuGet package, you are already violating this rule.

The AOT compiler is shipped via an additional package. It’s not shipped with the SDK which should be set to trusted.

Shipping development-time tools with package management system isn’t unusual.

It’s people like you who make corporate environments insecure. You might not care about security, but we here do. No one here is allowed to execute scripts or executables from untrusted locations.

Allowing users to run that stuff from a userdir, where users can put anything downloaded from the web is a nightmare. Thats why AppLocker and comparable solutions exist.