Roslyn: Allow security transparency attributes on async methods

Created on 15 Nov 2016  路  1Comment  路  Source: dotnet/roslyn

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 d__3 : IAsyncStateMachine
{
public int* 5__1;
...
}

Area-Language Design

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.

>All comments

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

codingonHP picture codingonHP  路  3Comments

marler8997 picture marler8997  路  3Comments

MadsTorgersen picture MadsTorgersen  路  3Comments

johndog picture johndog  路  3Comments

binki picture binki  路  3Comments