Tails

#1 Updated by sajolida 2015-09-30 08:20:26

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

#2 Updated by intrigeri 2015-10-01 18:45:42

> 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.

#6 Updated by sajolida 2015-10-06 08:37:06

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 Feature #10257 “Discuss & adopt a strategy to merge commits from Weblate”, I’m quite worried about that because Feature #10257 depends on Feature #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.

#9 Updated by intrigeri 2015-10-23 09:01:23

> 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 Feature #10257 “Discuss & adopt a strategy to merge commits from Weblate”, I’m quite worried about that because Feature #10257 depends on Feature #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.