Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upFuture of the saniziter #443
Comments
|
I'm +1 on removing it or splitting it out. I don't know if anyone is using it directly, but we could host it in bleach to reduce surface area and prevent things like mozilla/bleach#534 |
Some people are, but really not many. I don't think any are really using it in any way that it doesn't make sense to push people towards Bleach. And that html5lib is, uh, "lightly maintained" becomes doubly-problematic if we have security bugs in the sanitizer like CVE-2020-6817. |
|
To provide the feedback requested in the release notes— I'm currently using html5lib's sanitizer directly. I originally moved to it from Bleach because I needed to be able to chain filters in front of the sanitizer. It looks like Bleach now exposes its Filter directly so I may be able to adopt it. However I also use html5lib directly, so I don't love taking a second copy (Bleach vendors it). If that doesn't work I'll probably fork and vendor html5lib's sanitizer. From my perspective that is roughly the same maintenance burden as now, but fewer monkeypatches. |
|
Hello. This deprecation has come up in our project's CI as such (full log): As the traceback says, we are already using Bleach (3.2.0), so how do we get rid of the warning? Thank you. |
|
Ah, Bleach 3.2.0 came out yesterday/today with the vendored html5lib updated to 1.1. They probably should've avoided the warning showing up through their vendored copy! I suggest filing a bug on Bleach for this? |
As it is, many of the open issues relate to the sanitizer and the default set of elements/attributes allowed in it.
I've had occasional discussions with @willkg about whether or not it makes sense to keep on maintaining the sanitizer as part of html5lib, and on the whole my opinion has for a long time been that it doesn't. IMO, it should either become a project in its own right or incorporated into Bleach (cc/ @g-k who's probably the other person there who needs to be involved in this discussion).
Why do I think it makes sense to split out? At this point it's relatively tangential to the rest of the project (it's not tightly coupled to any part of html5lib and it operates purely with the public API), but it's arguably the most in need of maintenance part of the project (as it is in many ways more security sensitive than the majority of the rest).
One relatively simple option is to split it out into a project of its own right (potentially initially as a cyclic dependency, whereby the existing API continues to function), and see if anyone wants to maintain it as a separate project.