Project

General

Profile

Feature #10299

Consider disabling the htmlscrubber ikiwiki plugin

Added by sajolida almost 4 years ago. Updated almost 4 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
09/28/2015
Due date:
% Done:

0%

Feature Branch:
Type of work:
Discuss
Blueprint:
Starter:
Affected tool:
Installation Assistant

Description

This plugin is meant to prevent insertion of dangerous HTML tags in the ikiwiki source code. It strips CSS, and JavaScript tags by default. See http://ikiwiki.info/plugins/htmlscrubber/.

Currently on tails.boum.org it seems like we have the htmlscrubber ikiwiki plugin enabled as https://tails.boum.org/blueprint/bootstrapping/assistant/windows/ doesn't obey the `[[!meta stylesheet=]]` directive in its source code.

We currently have one exception (`htmlscrubber_skip: '!/misc/unsafe_browser_warning'`) but we will soon need more:

  • On the download page due to #8642
  • On all the page of the Installation Assistant to add extra CSS
  • On the page of the ISO verification extension to have the JavaScript for browser detection

So, since in our case all the ikiwiki source code is written directly by us and reviewed, I think it would make sense to disable htmlscrubber all the way.


Related issues

Blocks Tails - Feature #10257: Merge strategy from Weblate Resolved 10/03/2015

History

#1 Updated by sajolida almost 4 years ago

On a second thought, maybe we should treat blueprints differently as they are world writable.

#2 Updated by intrigeri almost 4 years ago

On a second thought, maybe we should treat blueprints differently as they are world writable.

Indeed. Translations are also a bit more widely writable and less reviewed by core Tails people than the rest of our website (except blueprints of course). New stuff like weblate may change this a bit too.

#3 Updated by intrigeri almost 4 years ago

  • Related to Feature #10331: Investigate the review processes available inside weblate added

#4 Updated by intrigeri almost 4 years ago

  • Related to deleted (Feature #10331: Investigate the review processes available inside weblate)

#5 Updated by intrigeri almost 4 years ago

#6 Updated by sajolida almost 4 years ago

You're right about translations; core dev do not review their markup as much as we do for the English content of the website.

To get back to the case of the Installation Assistant, we will need to disable htmlscrubber on all the pages probably (because we're doing weird CSS stuff all over the place). And for their translations as well; for example, translations in German of the installation instructions will need to have htmlscrubber disabled as well. So you're concern is valid but it conflicts here with the technical possibilities offered by ikwiki to do our work. So I'm not sure what to do and we're probably need to find a compromise...

Regarding having this issue blocked by #10257 "Discuss & adopt a strategy to merge commits from Weblate", I'm quite worried about that because #10257 depends on #10331 "Investigate the review processes available inside weblate" which we have no idea on how it's going to be solved so far.

So I'd rather change this relationship this other way around and have the process to merge from weblate adapt itself to whatever security level we'll need from the removal of htmlscrubber on more pages.

So here is my proposal, we keep on disabling htmlscrubber only when needed. For the installation assistant this will probably mean /install/* (I guess that's possible). And we take good note that translation on these pages can possibly insert malicious HTML and that we should be careful about this when merging stuff (either from individuals or from weblate). This supposes that we're not going to merge automatically from weblate but I think that's a sane assumption.

#7 Updated by intrigeri almost 4 years ago

#8 Updated by intrigeri almost 4 years ago

#9 Updated by intrigeri almost 4 years ago

So you're concern is valid but it conflicts here with the technical possibilities offered by ikwiki to do our work. So I'm not sure what to do and we're probably need to find a compromise...

Sorry if I did it in a way that made you feel uncomfortable, somehow.

There seems to be a misunderstanding. I did not write "don't dare touching the htmlscrubber_skip setting, find another way". You started building a list of site content that's more world writable than default, which is useful since it allows us to evaluate what's the impact of disabling htmlscrubber (maintainability++), compared to adding stuff to its whitelist (security++). Then I replied to contribute more stuff to that list, which I felt was needed so that we could better understand the impact of the initial proposal.

Regarding having this issue blocked by #10257 "Discuss & adopt a strategy to merge commits from Weblate", I'm quite worried about that because #10257 depends on #10331 "Investigate the review processes available inside weblate" which we have no idea on how it's going to be solved so far.

Understood.

So I'd rather change this relationship this other way around and have the process to merge from weblate adapt itself to whatever security level we'll need from the removal of htmlscrubber on more pages.

Done!

So here is my proposal, we keep on disabling htmlscrubber only when needed.

Given the amount of content that we barely control, or don't control at all, I think that this is more reasonable (and not too painful, given how rarely we're adding custom CSS/JS to pages that had none previously).

For the installation assistant this will probably mean /install/* (I guess that's possible).

It's a PageSpec so it's technically possible.

Let's postpone the "/install/* vs. more fine-grained list", aka. maintainability vs. security, discussion to when we know what's the actual ratio of pages that would be needlessly white-listed if we use a glob. Note that the maintainability argument here applies both to the white-list, and to the reviewing process of the world-writable content; we can move the problem from the one to the other, but not make it disappear. See what I mean? :)

And we take good note that translation on these pages can possibly insert malicious HTML and that we should be careful about this when merging stuff (either from individuals or from weblate).

Absolutely.

This supposes that we're not going to merge automatically from weblate but I think that's a sane assumption.

I agree this is a sane assumption.

#10 Updated by sajolida almost 4 years ago

  • Assignee set to sajolida
  • Target version changed from Tails_1.7 to Tails_1.8
  • QA Check set to Info Needed

Ok, so I'll point you to whatever we have under /install/* once we're almost ready for the user testing sessions (November 20-22). Because our plan is to have these pages live (but not linked to) by then. Then we can decide between "/install/* vs. more fine-grained list".

#11 Updated by sajolida almost 4 years ago

  • Status changed from Confirmed to Resolved
  • Assignee deleted (sajolida)

Discussion closed now moving on the #10533 to implement that.

Also available in: Atom PDF