Thanks for checking up on this. Of course, with security, answers breed more questions. So, here we go:
If I remove the APTCA, every library that extends re-linq will also have to remove the APTCA from their code, otherwise we get exceptions such as this one:
Inheritance security rules violated by type: 'Remotion.Linq.SqlBackend.SqlStatementModel.SqlSpecificExpressions.SqlRowNumberExpression'. Derived types must either match the security accessibility of the base type or be less accessible.
That would be a significant break we'd have to check with the other users of re-linq via the mailing list, and if we do check this, we'd need to provide a succinct statement on the effects and side-effects so the re-linq users don't have to dig into the security stuff themselves.
On the other hand, if we leave the APTCA applied to re-linq, I did not find any detrimental side effects:
Just for completeness sake: The APTCA was orginally introduced to the re-linq assembly during .NET 3.5 times to support partially trusted callers. The SecurityRules (Level1) attribute was then applied to work around our custom exceptions with serialization support. Since we no longer have those, there's no longer an issue.
Could you maybe check again with Levi what the downside of leaving the APTCA on the assembly would be to re-linq or if I missed something?
Many thanks, Michael
...1. We want to keep support for ArrayList.Count and Array.LongLength, so we'll switch this to use reflection to discover the reflection objects. (<a href="https://www.re-motion.org/jira/browse/RM-6134" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fwww.re-motion.org%2Fjira%2Fbrowse%2FRM-6134\46sa\75D\46sntz\0751\46usg\75AFQjCNGD1ESsijw5_qBsv2XxhX92pJQt