-
-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Enable autoescape #3562
Enable autoescape #3562
Conversation
cb4dc0c
to
e96fd3c
Compare
I have tested this branch locally. The only thing that seems to break is the If I disable the plugin, the Code tags in navigation through gen-files + literate-nav continue to work, as well as code tags in table of contents through mkdocstrings' |
This is a pretty significant change that has the potential to break a lot of plugins. I'm not sure the consequences of this can be fully understood a priori. If this gets merged, please release it as MkDocs 2.0. I would not recommend doing it, as it is a departure from what we discussed in #3357. |
@squidfunk the change matches what is now being discussed in #3357 :) Yes I'll consider naming the release 2.0 Regarding plugins in general, I am checking my "regressions" workflow and I'll be further expanding it, to warn authors in advance or avoid changes in the first place. Regarding the typeset plugin, I have no access to its source code, but assuming it sets |
So, the idea of autoescaping can work and it's nice, but reckless to try to push through considering the long historic context. Leaving the PR in a working state for posterity. |
I see that this should be a must. Whatever page trying to add Mkdocs in a untrusted input context is totally vulnerable to XSS. Are you sure that this shouldn't be enabled by default in a breaking change release? |
@mondeja I kindly disagree. MkDocs pages are not subject to XSS attacks because all content is built statically. There is no threat vector that carries untrusted user input. Adding auto-escape for the sake of mitigating XSS is fixing something that is not broken. Happy to be proven wrong. |
Your theme builds a feature which includes untrusted input that has been created with third party integrations, probably these kinds of limitations influenced that decision. Additionally, untrusted input could come from a server too or in the form of third party plugins building the static content from third party sources. What is Mkdocs really depends on the usage, the "is a static generator" is not true and some of the features of your theme prove that. I'm seeing that your project has eaten up the main one. In this toxic state of the ecosystem I don't think it will contribute anything again. |
I think the distinction between user (viewer) and author (writer) is important here. Only authors are able to change the content or add plugins that do. The only thing the typeset plugin effectively does is to allow to render parts of the page's content in the navigation and table of contents, nothing more. Are you maybe able to provide a demo that shows how XSS can be pulled off in a way that the author is unaware, that does only happen when the typeset plugin is active? |
I'm sorry, what? Yes, Material for MkDocs is one of the biggest dependents on MkDocs, and I'm not sure I should feel sorry for building something people love to use, but I'm not seeing how this is toxic. Could you please elaborate? |
Per #3357 (comment)