Encountered in https://github.com/dotnet/corefx/issues/11100. Combining security critical code with async isn't allowed (yielding errors like "Security attribute 'SecuritySafeCritical' cannot be applied to an Async method"). It means that instead of having a method that's SecurityCritical or SecuritySafeCritical, all of the critical code has to be pulled out into a SecuritySafeCritical method. That both complicates the code and forces marking methods SafeCritical that aren't intended to be safe.
For a quick refresher, SecurityCritical code can use unsafe, P/Invokes, unverifiable code, and call other SecurityCritical code. SecuritySafeCritical is the same, but is also allowed to be called by transparent code.
It should be possible to mark the compiler-generated async state machine and fields SecurityCritical (and possibly unsafe) automatically to preserve semantics. For example, for the code:
[SecuritySafeCritical]
async unsafe Task MyCriticalMethod()
{
int* somePointer = GetPointer();
await Something();
somePointer[0] = 3;
}
Could generate a state machine like:
```
[SecurityCritical]
private unsafe sealed class
{
public int*
...
}
This smells like the classic Microsoft problem where the tools group isn't truly aware of the cost and impact of a missing feature.
This one specifically causes a problem with System.Net.Http and that team has chosen to ignore it and ship 4.1, 4.2 and 4.3 instead of applying pressure back to the tools group. Meanwhile package after package is breaking, throwing security errors at runtime and the list grows month by month.
@karelz took some time away from his busy schedule clicking tags on GitHub and estimated that refactoring just the security-related changes in System.Net.Http was 8+ weeks. And even that resulted in breaking changes.
Meanwhile major parts of the .NET ecosystem are blocked, it's blocking .NET core work, and it's impacting basic technologies like Azure Storage, Azure Batch, and Azure ServiceBus from shipping .NET Core assemblies.
To further the point, Amazon Web Services has a far larger suite of products than Azure but they managed to complete ship .NET core support in 2015. In 2016 they reduced the dependencies further down to .NET Standard 1.3. I can use C# to automate Amazon Elastic Beanstalk (whatever the hell that is) meanwhile copying a file to blob storage using Microsoft's libraries requires three different workarounds AND crashes at runtime unless I meticulously hand-edit config files before deploying.
Fix the tool and free us all to do our job, please. The money and time being wasted here is absurd.
Most helpful comment
This smells like the classic Microsoft problem where the tools group isn't truly aware of the cost and impact of a missing feature.
This one specifically causes a problem with System.Net.Http and that team has chosen to ignore it and ship 4.1, 4.2 and 4.3 instead of applying pressure back to the tools group. Meanwhile package after package is breaking, throwing security errors at runtime and the list grows month by month.
@karelz took some time away from his busy schedule clicking tags on GitHub and estimated that refactoring just the security-related changes in System.Net.Http was 8+ weeks. And even that resulted in breaking changes.
Meanwhile major parts of the .NET ecosystem are blocked, it's blocking .NET core work, and it's impacting basic technologies like Azure Storage, Azure Batch, and Azure ServiceBus from shipping .NET Core assemblies.
To further the point, Amazon Web Services has a far larger suite of products than Azure but they managed to complete ship .NET core support in 2015. In 2016 they reduced the dependencies further down to .NET Standard 1.3. I can use C# to automate Amazon Elastic Beanstalk (whatever the hell that is) meanwhile copying a file to blob storage using Microsoft's libraries requires three different workarounds AND crashes at runtime unless I meticulously hand-edit config files before deploying.
Fix the tool and free us all to do our job, please. The money and time being wasted here is absurd.