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] <javascript:>> > >> 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/**browse/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.**SecurityCriticalAttribute) || >>> > (node6.Type == SystemTypes.**SecurityTransparentAttribute)) || >>> ((node6.Type == >>> > SystemTypes.**AllowPartiallyTrustedCallersAt**tribute) || >>> > node6.Type.FullName.Equals("**System.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/** >>> changehistory.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.**ArgumentTypeException.** >>> GetObjectData(System.Runtime.**Serialization.**SerializationInfo, >>> > System.Runtime.Serialization.**StreamingContext)'. 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-**us/magazine/ee336023.aspx<http://msdn.microsoft.com/en-us/magazine/ee336023.aspx> >>> > >>> >> >
