Any plans to release safe-critical DefaultBinder?

Nov 30, 2009 at 3:22 PM

It appears that the CodePlex DefaultBinder isn't currently usable in Silverlight, because when compiled from source it runs as security-transparent code and therefore can't do various security-critical reflection things essential to its operation (I see various Method/TypeAccessException errors when attempting to use it in SL).

Any plans to release a signed version, usable from within Silverlight?

Please?  :-)

Josh

 

Coordinator
Dec 3, 2009 at 9:59 PM

The default binder doesn’t need to do anything which is security critical – the whole thing should work just fine as normal transparent code.  In fact the signed version that we ship is signed with a key which isn’t treated specially by silverlight.  Where are you seeing the method / typeaccess exceptions and what are they?  Also is this in Silverlight 2 or in Silverlight 4 beta?

From: jplane [mailto:notifications@codeplex.com]
Sent: Monday, November 30, 2009 8:23 AM
To: Dino Viehland
Subject: Any plans to release safe-critical DefaultBinder? [dlr:76598]

From: jplane

It appears that the CodePlex DefaultBinder isn't currently usable in Silverlight, because when compiled from source it runs as security-transparent code and therefore can't do various security-critical reflection things essential to its operation (I see various Method/TypeAccessException errors when attempting to use it in SL).

Any plans to release a signed version, usable from within Silverlight?

Please? :-)

Josh

Read the full discussion online.

To add a post to this discussion, reply to this email (dlr@discussions.codeplex.com)

To start a new discussion for this project, email dlr@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

Dec 3, 2009 at 10:11 PM

Josh/Dino,

On Silverlight, the DLR is unable to do ANYTHING security-critical, whether the assemblies are signed or unsigned. The only assemblies which can call security-critical APIs are assemblies installed with Silverlight (which must also be signed with a secret Microsoft key) and offline Silverlight 4 applications that explicitly elevate permissions. Anything else can only use security-transparent APIs, just like user-code.

~Jimmy

From: dinov [mailto:notifications@codeplex.com]
Sent: Thursday, December 03, 2009 3:00 PM
To: Jimmy Schementi
Subject: Re: Any plans to release safe-critical DefaultBinder? [dlr:76598]

From: dinov

The default binder doesn’t need to do anything which is security critical – the whole thing should work just fine as normal transparent code. In fact the signed version that we ship is signed with a key which isn’t treated specially by silverlight. Where are you seeing the method / typeaccess exceptions and what are they? Also is this in Silverlight 2 or in Silverlight 4 beta?

From: jplane [mailto:notifications@codeplex.com]
Sent: Monday, November 30, 2009 8:23 AM
To: Dino Viehland
Subject: Any plans to release safe-critical DefaultBinder? [dlr:76598]

From: jplane

It appears that the CodePlex DefaultBinder isn't currently usable in Silverlight, because when compiled from source it runs as security-transparent code and therefore can't do various security-critical reflection things essential to its operation (I see various Method/TypeAccessException errors when attempting to use it in SL).

Any plans to release a signed version, usable from within Silverlight?

Please? :-)

Josh

Read the full discussion online.

To add a post to this discussion, reply to this email (dlr@discussions.codeplex.com)

To start a new discussion for this project, email dlr@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

Read the full discussion online.

To add a post to this discussion, reply to this email (dlr@discussions.codeplex.com)

To start a new discussion for this project, email dlr@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

Dec 3, 2009 at 10:54 PM

Dino and Jimmy,

Thanks to you both for responding. I'm using Silverlight 4 beta 2, BTW.

I went back and looked again... turns out the issue lies in my DefaultBinder implementation (it being abstract and all), specifically in my implementation of ConvertExpression(). The weird thing is that I expect that my implementation is fairly standard, so I'm surprised this hasn't come up yet (unless I'm really doing something stupid). Here it is:

 

public override Expression ConvertExpression( Expression expr, Type toType, ... /* other parms */ )

{

return Expression.Convert( Utils.SimpleCallHelper( Expression.Constant( this ), // this default binder instance

 this.GetType().GetMethod( "Convert" ), // standard Convert() override

 expr,

 Expression.Constant( toType ) ), // <-------- TypeAccessException here... "error attempting to access System.RuntimeType"

toType );

Entirely possible I'm missing something, but I have to believe that that's a fairly common implementation of that override. SL4 security definitely doesn't like it. And if I change it to pass toType.FullName as a string to a custom convert method, it works. Weird.

Anyways, thanks again for setting me straight on the DefaultBinder... still loving DLR. We're really doing some funky stuff with it, and it just totally kicks ass.

Josh

 

Dec 4, 2009 at 5:55 AM

The type of the constant needs to be public. System.RuntimeType is internal, so you need to explicitly specify typeof(Type): ... Expression.Constant( toType, typeof(Type) ) ...