New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add the AllowPartiallyTrustedCallers attribute to the assembly #268

Closed
GoogleCodeExporter opened this Issue Mar 15, 2015 · 3 comments

Comments

Projects
None yet
2 participants
@GoogleCodeExporter

GoogleCodeExporter commented Mar 15, 2015

What situation does this request make simpler?
ASP.Net code running at less than full trust (eg medium trust) cannot call into 
a strong named assembly unless it has the AllowPartiallyTrustedCallers 
attribute. Partially trusted code (anything less than full trust) that calls a 
signed, strongly named assembly that doesn't have the attribute will receive 
the error "That assembly does not allow partially trusted callers."

Can you provide a straw-man example of what you'd want the API to look
like?
No changes to the API, but the implication is that any code in NodaTime that 
might pose a security risk would have to make it's own, explicit security 
demands. I'm not real proficient in the Code Access Security stuff but this is 
what I gather from reading. From what I gather, if for example, NodaTime had a 
utility class that accessed the registry to update timezone data, you would not 
want partially trusted code to do that, so you would want to explicitly demand 
a higher security level for that portion of code to execute, either by placing 
a security attribute on specific methods or by calling Assert on a permission 
object in code. The first method is covered a lot. The only thing I've found on 
the later method is this article: http://support.microsoft.com/kb/839300.

The remarks in the docs for AllowPartiallyTrustedCallersAttribute is a good 
place to start: 
http://msdn.microsoft.com/en-us/library/system.security.allowpartiallytrustedcal
lersattribute%28v=vs.110%29.aspx
One of it's links is to "Using Libraries from Partially Trusted Code" 
(http://msdn.microsoft.com/en-us/library/8skskf63%28v=vs.110%29.aspx) which has 
a subtopic "Requiring Full Trust for Types Within an APTCA Assembly" which 
discusses using attributes on methods to raise the security level.
There's also a change in .Net 4 that is mentioned in many articles and there is 
a question/response on stackoverflow that laid some of that out 
(http://stackoverflow.com/questions/5055632/net-4-allowpartiallytrustedcallers-a
ttribute-and-security-markings-like-secur)

This issue also came up with the Recaptcha .net library I was using 
(http://code.google.com/p/recaptcha/issues/detail?id=100). They've implemented 
the attribute in the code but I don't think they've made another release 
containing it. You might try contacting the programmers on that project.

Original issue reported on code.google.com by paulbole...@hotmail.com on 29 Jan 2014 at 3:28

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 15, 2015

Okay - I think it's reasonable to put this in the desktop build, but the PCL 
build is a bit more of a pain. The attribute appears not to be supported in 
Silverlight or Windows Phone, both of which are supported by our current PCL 
build.

I'd rather not fork the PCL build at the moment - do you think that having it 
just for the desktop build will satisfy most users?

Original comment by jonathan.skeet on 31 Jan 2014 at 2:42

  • Changed state: Accepted
  • Added labels: Type-Enhancement, Milestone-1.3.0

GoogleCodeExporter commented Mar 15, 2015

Okay - I think it's reasonable to put this in the desktop build, but the PCL 
build is a bit more of a pain. The attribute appears not to be supported in 
Silverlight or Windows Phone, both of which are supported by our current PCL 
build.

I'd rather not fork the PCL build at the moment - do you think that having it 
just for the desktop build will satisfy most users?

Original comment by jonathan.skeet on 31 Jan 2014 at 2:42

  • Changed state: Accepted
  • Added labels: Type-Enhancement, Milestone-1.3.0
@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 15, 2015

I don't know about "most", but just adding it to the desktop build would make 
the library more easy to implement for ASP.Net development on a lot of shared 
hosting accounts. Web development is where I spend all of my time, so I 
wouldn't know how much the issue might be affecting other usage scenarios. To 
be honest I'm surprised no one has reported the issue already, either most 
asp.net development is in full trust environments or programmers writing code 
for low cost sites aren't taking the time to utilize such awesome libraries as 
Noda Time. (I don't under stand why. Using the Period object in my ecommerce 
site saved me a lot of lines of code while giving the end user more 
flexibility. Just define the period on a subscription product using the Iso 
pattern and I can extend the expiration date on the account in just a few lines 
of code. Selling in months or years. Fine. Offering free trials for days or 
weeks. Sure, no problem... LocalDateTime.Plus(Period)!)

Original comment by paulbole...@hotmail.com on 31 Jan 2014 at 4:07

GoogleCodeExporter commented Mar 15, 2015

I don't know about "most", but just adding it to the desktop build would make 
the library more easy to implement for ASP.Net development on a lot of shared 
hosting accounts. Web development is where I spend all of my time, so I 
wouldn't know how much the issue might be affecting other usage scenarios. To 
be honest I'm surprised no one has reported the issue already, either most 
asp.net development is in full trust environments or programmers writing code 
for low cost sites aren't taking the time to utilize such awesome libraries as 
Noda Time. (I don't under stand why. Using the Period object in my ecommerce 
site saved me a lot of lines of code while giving the end user more 
flexibility. Just define the period on a subscription product using the Iso 
pattern and I can extend the expiration date on the account in just a few lines 
of code. Selling in months or years. Fine. Offering free trials for days or 
weeks. Sure, no problem... LocalDateTime.Plus(Period)!)

Original comment by paulbole...@hotmail.com on 31 Jan 2014 at 4:07

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 15, 2015

Right. In that case I'll mark it as fixed for the moment (revision 
2f1ea405b87d), and we'll see if anyone complains about it for the PCL :)

Original comment by jonathan.skeet on 31 Jan 2014 at 7:32

  • Changed state: Fixed

GoogleCodeExporter commented Mar 15, 2015

Right. In that case I'll mark it as fixed for the moment (revision 
2f1ea405b87d), and we'll see if anyone complains about it for the PCL :)

Original comment by jonathan.skeet on 31 Jan 2014 at 7:32

  • Changed state: Fixed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment