Some more info that might be relevant: http://msdn.microsoft.com/en-us/library/system.runtime.serialization.isafeserializationdata.aspx "In versions previous to.NET Framework 4.0, serialization of custom user data in a security transparent code was accomplished using the GetObjectData method. Starting with .NET Framework 4.0, that method is marked with the SecurityCriticalAttribute attribute which prevents execution in security-transparent code. To work around this condition, implement the ISafeSerializationDatainterface and add custom data as shown in the example below. "
Exploring the .NET Framework 4 Security Model http://msdn.microsoft.com/en-us/magazine/ee677170.aspx Long, but it has something to say about AllowPartiallyTrustedCallers etc. /Oskar 2012/12/6 Alexander I. Zaytsev <[email protected]>: > 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/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.AllowPartiallyTrustedCallersAttribute) || >>> > 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) >>> > 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 > >
