Clr type filtering - #2742
Open
macaronikazoo wants to merge 1 commit into
Open
Clr type filtering#2742macaronikazoo wants to merge 1 commit into
macaronikazoo wants to merge 1 commit into
Conversation
filmor
force-pushed
the
clr-type-filtering
branch
from
September 25, 2026 12:58
e08a730 to
5902aec
Compare
Member
|
@filmor this seems very out of scope. Reopen if disagree. |
Contributor
Author
|
why "very out of scope"? I'd have thought plently of embedders/consumers of this library would want to be able to restrict what python can and can't access on the .net side of things, surely? seems super useful - jint has similar functionality |
Member
|
I think this is worth discussing. |
Contributor
Author
|
is there anything from me that might be helpful? to me it seems like a potentially valuable, low risk change - the existing architecture made it reasonably easy to insert the appropriate checks - its a pretty fantastic library really, you guys have done an awesome job |
Embedders can register filters on InteropConfiguration.ClrTypeFilters to refuse CLR types before they're handed to Python. Empty by default - a type is allowed only if every registered filter permits it ReflectedClrType.GetOrCreate consults the filters on a cache miss, before taking _cacheCreateLock, so filter code never runs while a pythonnet lock is held. Every CLR type passes through there, so the one check covers return values, fields, iterators and APIs returning System.Type alike. Refused types are checked everytime, but a refusal throws ClrTypeFilteredException, which Exceptions.SetError raises as a plain Python TypeError: wrapping the CLR exception would mean reflecting its type into Python, which the same filters may refuse. InterfaceObject now guards __implementation__ and __raw_implementation__, which expose the concrete object and so can be refused too NOTE: this isn't a security feature, but it does make it harder to go exploring through everything available in the runtime
filmor
force-pushed
the
clr-type-filtering
branch
from
September 29, 2026 11:59
5902aec to
b21fc2c
Compare
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What does this implement/fix? Explain your changes.
Allows embedders to restrict which CLR types reach Python
NOTE: this isn't a security feature, but it does make it harder to go exploring through everything available in the runtime
For example, the following prevents python from using reflection.
Checklist
Check all those that are applicable and complete.