Yes, even if we add [SecurityCritical] to this overriden method - it will not help - read Osakr's message:(
2012/12/6 cremor <[email protected]> > I don't think it would be that easy. You'd have to do something like > SecAnnotate.exe already does: You'd have to find all methods that > call/override security critical methods and apply the attribute to them. > Then you'd have to do this again (to find other methods that now need the > attribute because they call the just modified methods) in a loop until you > can't find any methods to modfiy any more. > And how would you differ between methods that need the SecurityCritical > attribute and ones that can instead get the SecuritySafeCritical attribute? > Even SecAnnotate.exe can't do this automated and lets the user decide. > > > On Thursday, December 6, 2012 10:35:58 AM UTC+1, Alexander I. Zaytsev > wrote: > >> Is there only one problem with retargeting .NET 3.5 to .NET 4.0 that we >> need to apply such security attributes? I think il-repack can easily be >> adapted for such scenarios. >> >> >> 2012/12/6 cremor <[email protected]> >> >> I just tried il-repack. Results in the same exception from re-linq as >>> when using the old ILMerge. >>> >>> Even if there would be an re-linq build for .NET 4.0, wouldn't then >>> cause the Antlr3.Runtime the same problems? Or doesn't the Antlr3.Runtime >>> call any security critical methods? >>> >>> >>> On Thursday, December 6, 2012 9:35:49 AM UTC+1, Oskar Berggren wrote: >>> >>>> What is re-linq's take on .Net 4? Can we use a custom build adapted >>>> for .Net 4 and/or get them to release such a build? >>>> >>>> /Oskar >>>> >>>> >>>> 2012/12/6 cremor <[email protected]>: >>>> > I've now found the reason for NH-3340 - NHibernate assembly loses the >>>> > AllowPartiallyTrustedCallers attribute after ILMerge >>>> > (https://nhibernate.jira.com/**b**rowse/NH-3340<https://nhibernate.jira.com/browse/NH-3340>). >>>> But since this is going to be >>>> > more a question/discussion than a comment for that bug I'll post it >>>> here. >>>> > >>>> > So the reason why this attribute is there in NHibernate 3.3.x but is >>>> missing >>>> > in 4.0.0 is that the 3.3.x branch still uses some older ILMerge >>>> version >>>> > (2.10.526) whereas the master branch uses the latest version >>>> (2.12.803). >>>> > Using the old ILMerge for building the master branch solves the >>>> problem of >>>> > the missing AllowPartiallyTrustedCallers attribute (but causes other >>>> > problems, more on that later). >>>> > >>>> > Using the .NET Reflector I found the following code in the latest >>>> ILMerge: >>>> > >>>> > else if (((node6.Type == SystemTypes.**SecurityCriticalAt**tribute) >>>> || >>>> > (node6.Type == SystemTypes.**SecurityTransparen**tAttribute)) || >>>> ((node6.Type == >>>> > SystemTypes.**AllowPartiallyTrus**tedCallersAt**tribute) || >>>> > node6.Type.FullName.Equals("**Sy**stem.Security.SecurityRules"**))**) >>>> >>>> > { >>>> > this.WriteToLog("Assembly level attribute '{0}' from >>>> > assembly '{1}' being deleted from target assembly", new object[] { >>>> > node6.Type.FullName, a.Name }); >>>> > a.Attributes[num8] = null; >>>> > } >>>> > >>>> > So it seems like all those security attributes are always removed. >>>> > Interestingly the change log of ILMerge >>>> > (http://research.microsoft.**com**/en-us/people/mbarnett/**changeh** >>>> istory.aspx<http://research.microsoft.com/en-us/people/mbarnett/changehistory.aspx>) >>>> >>>> > doesn't mention this change. But most likely it was because of the >>>> problem >>>> > I'm now getting: >>>> > >>>> > After merging the NHibernate 4.0.0 assembly with the old ILMerge I'm >>>> getting >>>> > the following exception when executing a Linq query: >>>> > Inheritance security rules violated while overriding member: >>>> > 'Remotion.Linq.Utilities.**Argum**entTypeException.**GetObjectData** >>>> (System.Runtime.**Serialization.****SerializationInfo, >>>> > System.Runtime.Serialization.**S**treamingContext)'. Security >>>> accessibility of >>>> > the overriding method must match the security accessibility of the >>>> method >>>> > being overriden. >>>> > >>>> > So re-linq is not setting the correct security attributes for .NET >>>> 4.0 which >>>> > is understandable since it still targets 3.5. How should this ever >>>> work >>>> > without requiring all dependencies to target .NET 4.0 and fixing >>>> their >>>> > security attributes? >>>> > >>>> > I'm no .NET security expert but I think the best solution would be to >>>> > rollback to the old ILMerge version and additionally set the >>>> [assembly: >>>> > SecurityRules(SecurityRuleSet.****Level1)] attribute for the >>>> NHibernate >>>> > assembly. That way everything should behave like previously. >>>> Completely >>>> > removing ILMerge and falling back to seperate assemlies should also >>>> be an >>>> > option, but I don't think that is a good solution. Opinions? >>>> > >>>> > PS: Here is a very good explanation of what >>>> AllowPartiallyTrustedCallers >>>> > means in the .NET 4.0 security world: >>>> > http://msdn.microsoft.com/en-**u**s/magazine/ee336023.aspx<http://msdn.microsoft.com/en-us/magazine/ee336023.aspx> >>>> >>> >>
