-
Notifications
You must be signed in to change notification settings - Fork 416
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
Allow markup-ing literal strings #3402
Conversation
Will need to squash the PR in order to use the PR's description as commit message: had a typo ("and then normal way") |
CI seems unhappy, even though 3.9.2 does seem available in the python-versions and #3404 seems to have fetched it fine. Possibly a temporary network issue? |
Aaah I think I see what the issue is, I forked off of and targeted the
|
Literal strings in the application should be safe (similar to static markup in template files), and the normal way to create dynamic markup code side: create a properly marked up `Markup`, then `Markup.format` user-defined content into it.
Right, yep, turns out using github's interface led me to not test the rule and thus forget half of it. Also wow does the test suite not joke around. But since I was running it I added a few test cases to make sure the change actually works, probably can't hurt. Hopefully I got it right this time. |
Thanks 🎆 |
Thanks for your contribution! Your changes will be available in Semgrep’s registry in a bit. |
Literal strings in the application should be safe (similar to static markup in template files), and the normal way to create dynamic markup code side: create a properly marked up
Markup
, thenMarkup.format
user-defined content into it.