Skip to content
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

mask query method should not return original query in case of exception #19680

Open
mgorsk1 opened this issue Feb 5, 2025 · 0 comments
Open
Assignees

Comments

@mgorsk1
Copy link
Contributor

mgorsk1 commented Feb 5, 2025

Affected module
Ingestion

Describe the bug
I am not sure whether it's a bug or wrongly defined logic, but I wanted to raise concern over mask_query method. In it's current form, mask_query is a method that:

  • will return masked query if masking succeeds
  • will return original query if masking does not succeed

Which I think is wrong (the second part). If a user relies on this method and masking was not possible, then it would return original query (possibly with sensitive data) without users knowledge. In automated scenarios this might cause leakage of sensitive information when masking fails but returned query is pushed for further processing (for example when enriching lineage edge). The method ideally either returns None or raises an exception if masking fails.

To Reproduce

Screenshots or steps to reproduce

Expected behavior
mask_query does return None when masking fails.

Version:

  • OS: [e.g. iOS]
  • Python version:
  • OpenMetadata version: [e.g. 0.8]
  • OpenMetadata Ingestion package version: [e.g. openmetadata-ingestion[docker]==XYZ]

Additional context
Add any other context about the problem here.

@mgorsk1 mgorsk1 changed the title mask query method should never be a passthrough one mask query method should not return original query in case of exception Feb 5, 2025
@ulixius9 ulixius9 moved this to Integration in Release 1.6.4 Feb 5, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Integration
Development

No branches or pull requests

2 participants