You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As it happens, We're working on a more convenient and dedicated mechanism for describing class/method/field in taint configuration; the hard part is we're trying to balance readability and functionality when designing the "wildcard" expression mechanism. For example, regular expressions are powerful, but they are less readable; maybe we need more functionality, such as describing subclasses, but more is not better, it depends.
Anyway, we will support it. Stay tuned for next release milestone.
As it happens, We're working on a more convenient and dedicated mechanism for describing class/method/field in taint configuration; the hard part is we're trying to balance readability and functionality when designing the "wildcard" expression mechanism. For example, regular expressions are powerful, but they are less readable; maybe we need more functionality, such as describing subclasses, but more is not better, it depends.
Anyway, we will support it. Stay tuned for next release milestone.
Can we consider opening up an inheritable abstract class that can use Java to write rules, so that users can override and implement the logic in DeserializeSources, DeserializeSinks, DeserializeSanitizers, and DeserializeTransfers according to their needs?
Clear and concise description of the problem
Can the configuration of source and sink support wildcard characters, such as using * to match
Impact Analysis
No response
Suggested Solution
No response
Alternative
No response
Intention to submit PR
No
Additional Context
No response
The text was updated successfully, but these errors were encountered: