>
> Thanks!
>
> - Jesse Towner

"Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message
news:uGjMKZJLFHA.3104@TK2MSFTNGP14.phx.gbl...
>
> "Jesse Towner" <jtow***@hybrid-mobile.com> wrote in message
> news:e9zS0PILFHA.3076@tk2msftngp13.phx.gbl...
>>I noticed these intriguing classes have been introduced recently into
>> the .NET Framework 2.0. However, documentation for them seems to be
>> lacking, and google search turns up nothing.
>
> I've been wondering about these as well for some time now.  There's
> apparently a pretty big documentation refresh planned for beta 2, so
> there's
> at least some hope of better information in the reasonably near future.
>
>
>> I was wondering if someone could be generous and comment on the usage
>> of these attributes?
>
> I'll try, but you should probably keep the following caveats in mind:
>
> 1.  I'm working off the same information as you are, so any additional
> insights are based purely on a bit more time testing the new
> funcationality.
>
> 2.  There's enough divergence between the documentation and the apparent
> implementation that it probably wouldn't be very surprising to see the
> implementation change during the remainder of the beta.
>
> 3.  It's a beta.  Any observed behaviour might be a bug, particularly
> given that we don't have solid documentation to explain the intentended
> behaviour.
>
>
>> In order to expose a trusted assembly to other
>> partially trusted assemblies, would you mark the assembly with
>> SecurityTransparentAttribute?
>
> No, you would still use AllowPartiallyTrustedCallersAttribute for this.
> SecurityTransparentAttribute appears to act essentially like an
> overrideable version of an assembly-level refusal of assertion permission
> (i.e.: [assembly: SecurityPermission(SecurityAction.RequestRefuse,
> Assertion = true)]).  It's sort of like saying "I won't assert in this
> assembly unless I say I will", which seems mainly to be a mechanism to
> help developers target security auditing when asserting permissions on
> behalf of partially trusted callers.
>
>
>> And then mark non-public dangerous methods
>> with SecurityCriticalAttribute?
>
> Once you've marked an assembly with SecurityTransparentAttribute, you'll
> need to mark types* and/or members with SecurityCriticalAttribute in order
> for assertions to work, regardless of visibility.  Otherwise, an assertion
> would cause a SecurityException, exactly as if there were an
> assembly-level refusal of assertion permission.
>
> *Even though SecurityCriticalAttribute can be applied to classes, it
> doesn't appear to actually have any effect, at least in the February CTP.
> Perhaps a bug but, without adequate documentation, who knows?
>
>
>> And then public safe methods that use
>> the SecurityCriticalAttribute marked methods should be marked with
>> SecurityTreatAsSafeAttribute?
>
> SecurityTreatAsSafeAttribute appears to be used as a way of declaring that
> it's safe to call into a given non-public SecurityCritical member from a
> public SecurityTransparent member, so the public member doesn't require
> additional security auditing.  If it weren't safe, then the public member
> making the call should be marked as SecurityCritical in order to flag it
> for security review.
>
>
>> These are just guesses at the moment, and I'd greatly appreciate any
>> wisdom that can be shined on this subject.
>
> Unfortunately, my answers are largely the result of some guesswork as
> well. If we're lucky, perhaps someone from Microsoft will jump in to give
> a definitive answer.
>
>
>>
>> Thanks!
>>
>> - Jesse Towner
>
>
>