optionpool.py: Make jinja autoescape rules explicit

Description

This is part of #1220 - the linter thinks invoking jinja2 without auto-escape rules is dangerous. Probably not a bad lint, but entirely pointless in our case.

Nonetheless, we should probably set up some default so it's explicit that we don't want escaping.

---

approved this merge request

I wonder if there is a risk that this might break freedesktop's options? I don't believe so, but could you at least just try a 'show' on it? :)

No, it doesn't actually enable autoescape.

In fact, the linter is too smart for me, and realizes this. I'll need to look a little more closely at this.

@BenjaminSchubert looks like freedesktop-sdk loads (though it complains because not all plugins are available, shouldn't be an issue for this change).

Do you mind the bit of function aliasing I've resorted to?

I'd rather have a double import for this, this is ...really hard to digest when you first come to it, especially if you don't know that we have this thing in CI (I'm actually wondering whether we want it or not, given that it's more annoying errors than anything else)

I went back to a double import. I agree that the linter has a fairly low signal-to-noise ratio :|

marked as a Work In Progress

changed the description

added 1 commit

• eab55380 - optionpool.py: Make jinja autoescape rules explicit

Compare with previous version

added 1 commit

• 2d1cfa69 - optionpool.py: Make jinja autoescape rules explicit

Compare with previous version

added 1 commit

• 21fb72d3 - optionpool.py: Make jinja autoescape rules explicit

Compare with previous version

unmarked as a Work In Progress

added 3 commits

• 21fb72d3...c35a8eb8 - 2 commits from branch master
• 24e35924 - optionpool.py: Make jinja autoescape rules explicit

Compare with previous version

Alternatively, can we silence Bandit in this case?

I don't feel great about changing our source just to make a linter happy, especially in this case when we don't even care about that warning.

I considered that, but I prefer a change for two reasons:

1. Even if silenced, the vulnerability will appear in our list, just strike through, which doesn't look as good; especially considering the remaining large number of minor issues.
2. It's good to be explicit about this anyway, we don't want the default to change or have someone expect it to escape XSS-vulnerable markup languages by default.

The change is anyway rather small, if annoyingly... unwieldy, so I don't think it hurts.

Alternatively, can we silence Bandit in this case?

yes, we can just dismiss it from the report

added 1 commit

• 30131784 - optionpool.py: Make jinja autoescape rules explicit

Compare with previous version

mentioned in merge request !1763 (merged)

added 1 commit

• 1a3164cb - optionpool.py: Make jinja autoescape rules explicit

Compare with previous version

added 76 commits

• 1a3164cb...397a8fe5 - 75 commits from branch master
• a0f0fe64 - optionpool.py: Make jinja autoescape rules explicit

Compare with previous version

Closing this, looks like we're just silencing problems for now.

closed