-
Notifications
You must be signed in to change notification settings - Fork 4.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
API Proposal: Obsolete XmlSecureResolver #73636
Comments
Tagging subscribers to this area: @dotnet/area-system-xml Issue DetailsAPI Proposal: Obsolete
|
Author: | GrabYourPitchforks |
---|---|
Assignees: | GrabYourPitchforks |
Labels: |
|
Milestone: | 7.0.0 |
// System.Xml.ReaderWriter.dll
namespace System.Xml
{
[Obsolete(/* ... SYSLIB0047 ... */)]
public class XmlSecureResolver : XmlResolver
{
public XmlSecureResolver(XmlResolver resolver, string? securityUrl); // existing ctor, no change
public override object? GetEntity(Uri absoluteUri, string? role, Type? ofObjectToReturn)
{
throw new XmlException(/* ... */);
}
}
} |
API Proposal: Obsolete
XmlSecureResolver
The class
System.Xml.XmlSecureResolver
does not work correctly in .NET. It relies on Code Access Security (CAS), but the CAS infrastructure was never ported from .NET Framework to .NET Core. The end result is that the type no-ops, allowing resolution which should be blocked.We investigated making a behavioral change to the class to add a naïve restriction mechanism. However, this is complicated by the fact that the
XmlSecureResolver
type does not itself perform resolution. Instead, it wraps an innerXmlResolver
, providing a sandbox controlling which actions are allowed by the inner resolver. Because we don't control the behavior of the inner resolver, we have no way of asking it to honor our policy. Anything we do on top of this would be fragile.The best course of action is two-fold:
[Obsolete]
on the class (possible source breaking change)GetEntity
method unconditionally throw an exception at runtime (behavioral breaking change)Further discussion
We really need the ability to retroactively obsolete this across netstandard2.0 and downlevel runtimes. Otherwise devs won't see these obsoletions and won't know not to call it. I'm updating the documentation for the type to reflect what's discussed here, but doc updates only go so far.
New CodeQL rules have been created, flagging calls to this type across all netstandard and netcoreapp targets. I expect those rules to make their way into the public drops eventually.
The text was updated successfully, but these errors were encountered: