Stub CAS/Security in wpf

[hughbe]

From #214 (comment)

I'm guessing cause the source is shared we can't but opening for discussion

[vatsan-madhavan]

The codebase across the board has several 1000's of CAS attributes, related comments (which, for most part, are easy to identify because they are tagged clearly with <SecurityNote> element in the document comments). Besides attribute-based usage, there are many places where the usages are non-declarative (Asserts/Demands in code, RegistryPermission and FileAccessPermission asserts or demands that are tailored to runtime-identified paths that cannot be declared in an attribute etc.

Roughly,

• 20k CAS attributes (SecurityCritical, SecuritySafeCritical, SecurityTreatAsSafe etc.)
• A few hundred SecurityPermission attributes (like RegistryPermission)
• A few hundred permission instantiation and Assert/Demand in code (along with try/catch/finally etc. around them, and some related retry or fallback logic in most places)
• 16k comments related to these attributes (<SecurityNote>)

The architecture of how P/Invokes are organized (~1.7k DllImport attributes across the codebase) is likely to be affected a bit (perhaps not a lot) when we start removing CAS attributes, and there would be some rippling changes elsewhere. There would also be some places where public types would have to be changed carefully. XamlLoadPermission that you have identified is a good example. We'd want to decide how best to modify classes like these across the board and get them to behave as no-ops, while ensuring that we don't inadvertently break any existing applications. Code supporting functionality like XBAP's would have to be removed.

I don't think we have had a chance to think through all the scenarios that need to be covered along the way, but this is an excellent topic of discussion and we can use this thread to discuss the approach. In my mind, removal of System.Security.Permissions from our references would be a good success criterion. (PresentationBuildTasks conditionally compiled for net472 target could be an exception. That said, its unclear to me at this time whether we'd really need to exempt it)

The results of some of these codebase wide cleanup results should start showing up in the upcoming months. For now, I would avoid making ad-hoc changes that are intended to remove declarative permissions etc. - though they won't be hard to review, they would also be low yield-effort and wouldn't make enough of a dent on the overall problem just-yet.

@hughbe - if you'd like, please open a separate issue/discussion to discuss how to stub out XamlLoadPermission and propose a design. I think we can solve it in isolation. I expect that there will be some other sub-problems of this nature that are smaller and independent in scope.