Given time I imagine we'll also want to deny the types Assembly, MethodInfo, and a whole slew of reflection-related things. Not really needed for this PR, but it would be interesting to think about whether the solution here might scale to capturing all of those. At the very least, in this theoretical future world, we'd want to update the exception message to avoid suggesting that every such type might lead to security problems.

it would be interesting to think about whether the solution here might scale to capturing all of those. At the very least, in this theoretical future world, we'd want to update the exception message to avoid suggesting that every such type might lead to security problems.

wrt. adapting the error message appropriately, we could add a new internal TypeDisallowReason enum (or something similar) which would be a parameter for a ctor on UnsupportedTypeConverter which would inform what message to spit out. Hopefully any further scalability issue can be worked out.

Is this getting backported for 5.0? If not, wouldn't this be a 6.0 breaking change for the hypothetical customer code that relies on SerializationInfo?

This change won't be a breaking change in 6.0, so we don't need to port it to 5.0. The Type and SerializationInfo types are already not (de)serializable, due to Type already being explicitly disallowed (both ctors on SerializationInfo take a Type, and there is serializable a Type member on SerializationInfo). This change only makes the exception message clearer when deserializing SerializationInfo and when disallowing .ctor(SerializationInfo, StreamingContext) from being invoked.

Test failures appear unrelated - 2 timeouts:

runtime (Libraries Test Run release coreclr Linux x64 Debug) Cancelled after 150m

runtime (Libraries Test Run release mono Linux x64 Debug) Cancelled after 149m