Strip out SecurityCritical attributes

[JeremyKuhne]

They don't have any function in Core.

Stripped via regex:

^.*\[(System\.Security\.)?Security(Safe)?Critical(Attribute)?\](\s*//.*|\s*)$[\r\n]*

related to dotnet/coreclr#8571

[justinvp]

Nit: Do we want to keep this comment?

[JeremyKuhne]

I'll put it back

[stephentoub]

There are still some remaining attributes that don't match this regex, e.g.
https://github.com/dotnet/corefx/pull/14383/files?diff=unified#diff-b3d39e42f75b9efe89d21eb385ed61f6L40
Was the goal here to get them all, or just most and we'll strip the rest later?

Also, is any of this code compiled into assemblies meant to run on desktop? I'm wondering if we need to not strip them from certain files/libs because they're still necessary there.

Otherwise, LGTM.

[JeremyKuhne]

Was the goal here to get them all, or just most and we'll strip the rest later?

Most. I wanted to validate the build process to begin with. I'll find the stragglers in another change.

I'm wondering if we need to not strip them from certain files/libs because they're still necessary there.

Hmm. I'm trying to envision how that might work/not work and whether or not we care about the NetStandard on limited-trust desktop. I would assume that we're horribly broken if this matters- we're not testing that scenario afaik.

My personal feeling is to make NS on desktop a non-goal. Having to float security attributes through peoples libraries for "full" compatibility sounds like a nightmare to support and having them around adds confusion.

[danmoseley]

Immutable and Compression are the tricky ones. @jkotas in https://github.com/dotnet/corefx/issues/12592 described the criteria.

[danmoseley]

What about AllowPartiallyTrustedCallers and SecurityTransparent?

[JeremyKuhne]

Heh, I didn't notice there was an existing issue. I've taken it and I'll finish this up.

[davidsh]

Slightly related ....but stripping out these [SecurityCritical] attributes will make things like fixing #11100 impossible. Because one solution to fixing #11100 is to add back a ton of these attributes for the cross-compile (for .NET Framework build) of System.Net.Http since it is OOB'd on Desktop.

cc: @karelz @ericstj @weshaggard @stephentoub

[karelz]

But only for OOB packages. The packages that don't ship as OOB (i.e. won't ever run on Desktop), which is majority, don't need the attributes.
cc: @morganbr

[davidsh]

My comment above was more about reacting to this comment in the thread:

My personal feeling is to make NS on desktop a non-goal. Having to float security attributes through peoples libraries for "full" compatibility sounds like a nightmare to support and having them around adds confusion.

[karelz]

The OOB should compile (and run) against Desktop targeting pack (whatever the terminology is), so the attributes at least don't leak into non-OOB packages.
That means the security attributes have to be under #ifdef OOB, of course.

[JeremyKuhne]

I pulled it back out until there is a full understanding of what exactly should be done.

To be clear- I'm not against having attributes in if they are blocking scenarios people are actually using.

[morganbr]

Removing attributes may break these assemblies on desktop in all cases. Even for full trust scenarios, the attributes are enforced by the desktop runtime and cannot be disabled.

[karelz]

Assemblies which are shipping in .NET Core only are not meant to run on Desktop runtime.

[morganbr]

@karelz Agreed... The #if OOB idea is ok, though since these are no-ops on .NET Core, leaving them in is equivalent. I just meant that if any of these run outside of .NET Core, we still need attributes.

[JeremyKuhne]

My problem with leaving the no-ops in is that it is confusing and we have no mechanism for maintaining them.

Do we have a list of what is OOB and what is not?

[karelz]

Exactly, the maintenance problem is a huge problem (new APIs won't have the attributes) and the confusion doesn't help either.

@weshaggard @ericstj do we have list of OOBs in CoreFX repo?

[weshaggard]

@weshaggard @ericstj do we have list of OOBs in CoreFX repo?

We don't have a list exactly but any of the libraries that have source code for netfx* builds (and not just pure facades) are ones that are interesting. We could pretty easily produce a list based on that logic.

[gulbanana]

Presumably anything which is part of/a dependency of NETStandard.Library is likely to end up running on desktop at some point.

[karelz]

@gulbanana that's not the plan. Changes from .NET Core will be eventually ported to Desktop ("full" Framework), but the source code won't likely be used on Desktop directly.

[karelz]

@weshaggard do you have hint how to 'findstr' all of them? I think I can just look at ImmutableCollections or Metadata and guess it from there - will try it later.

[weshaggard]

Unfortunately I don't think findstr is going to be the best tool for this job. It will find things that are directly targeting desktop but not things that are indirectly targeting desktop via netstandard/PCL. @ericstj do you have an cheap cleaver ways to find all these? Perhaps reference all our packages and resolve for desktop?

[ericstj]

Package reports will show all this data. They'll list binaries as well as projects and the configuration they were built with.

[karelz]

From offline discussion: What is most interesting to me (now) is list of OOB packages which also ship as part of the platform (e.g. Networking OOB).
Immutable and MetadataReader (and similar) are sitting on top of the platform, so I assume we know how to ship them and they are not source of problems.
Can I find such list somewhere?

[ericstj]

@karelz as I mentioned, package reports have all this data. Most of our packages ship some dll on some version of desktop. Many replace the inbox facades, only a couple replace inbox implementations. System.Net.Http and System.IO.Compression are the only two in the latter camp. Please have a look at the package reports (just look for reports folder under the bin//packages folder after your build). There is a lot of data here so you should be able to get any sort of info you want out of it by processing in the right way.

[karelz]

Thanks @ericstj!
Looking at bin\packages\Debug\reports\System.IO.Compression.json, how do I tell it ship implementation specific to Desktop?
Entries like:

• "PackagePath": "runtimes/win/lib/net463/System.IO.Compression.dll"

[ericstj]

If there is a dll listed under the desktop section then it ships an implementation that will run on desktop. You can also see what project built this dll:

    ".NETFramework,Version=v4.6.3": {
      "Framework": ".NETFramework,Version=v4.6.3",
      "RuntimeID": "",
      "CompileAssets": [
        {
          "LocalPath": "C:\\src\\corefx\\bin\\Windows_NT.AnyCPU.Debug\\System.IO.Compression\\net463\\System.IO.Compression.dll",
          "PackagePath": "ref/net463/System.IO.Compression.dll",
          "SourceProject": {
            "Project": "C:\\src\\corefx\\src\\System.IO.Compression\\src\\System.IO.Compression.csproj",
            "AdditionalProperties": "TargetGroup=net463;",
            "UndefineProperties": ";OSGroup;TestTFMs;FilterToOSGroup;FilterToTestTFM;DefaultBuildAllTarget;SerializeProjects;BuildAllOSGroups"
          },
          "TargetFramework": ".NETFramework,Version=v4.6.3",
          "Version": "4.2.0.0"
        }
      ],
      "RuntimeAssets": [
        {
          "LocalPath": "C:\\src\\corefx\\bin\\Windows_NT.AnyCPU.Debug\\System.IO.Compression\\net463\\System.IO.Compression.dll",
          "PackagePath": "lib/net463/System.IO.Compression.dll",
          "SourceProject": {
            "Project": "C:\\src\\corefx\\src\\System.IO.Compression\\src\\System.IO.Compression.csproj",
            "AdditionalProperties": "TargetGroup=net463;",
            "UndefineProperties": ";OSGroup;TestTFMs;FilterToOSGroup;FilterToTestTFM;DefaultBuildAllTarget;SerializeProjects;BuildAllOSGroups"
          },
          "TargetFramework": ".NETFramework,Version=v4.6.3",
          "Version": "4.2.0.0"
        }
      ]
    },

Contrast this to an early version of desktop where this library was inbox:

    ".NETFramework,Version=v4.5": {
      "Framework": ".NETFramework,Version=v4.5",
      "RuntimeID": "",
      "CompileAssets": [
        {
          "LocalPath": "C:\\src\\corefx\\Tools\\_._",
          "PackagePath": "ref/net45/_._"
        }
      ],
      "RuntimeAssets": [
        {
          "LocalPath": "C:\\src\\corefx\\Tools\\_._",
          "PackagePath": "lib/net45/_._"
        }
      ]
    },