dashboard does not validate text fields

[John Lenton]

It seems dashboard.snapcraft.io does little to no validation on the text fields (Title, Summary, and Description).

In particular, I can have \n in title and summary, and arbitrary control characters in any of them.

I'd expect the three of them to reject anything that isn't valid UTF-8; of Unicode, they should reject any control or private use character (that is: any character with class Cc or Co), and noncharacters. The exception being that description should accept \n.

--

I'm tagging as a security issue because you can currently embed escape sequences into the summary, which is displayed unquoted in 'snap find' and can thus do potentially nasty things to the user's terminal. I don't think it's a _serious_ security risk, but it's nasty.

"snap find counterintelligences" for a harmless example. Note the line drawing characters are done using VT100 drawing (i.e. DEC special characters set; it changes the character set the terminal uses).

[John Lenton (chipaca)]

I think I'd add U+FFFD REPLACEMENT CHARACTER to the list of 'nopes'.

[John Lenton (chipaca)]

The store is saving newlines as \r\n, so maybe accept \r only if followed by \n only in description.

But also, can the store stop saving newlines as \r\n :-)

[John Lenton (chipaca)]

The bug is private because at least VTE has in the past had issues with how it handles escapes.

The plan is: close the store bug first, then open this up and harden the other three.

[Jamie Strandboge (jdstrand)]

John and I discussed this a bit on IRC. We should not allow control characters in any of our fields that end up being displayed to the user in snapcraft.yaml and snap.yaml or from forms from the dashboard. Historically, control characters can be used in various attack scenarios on the user's terminal. I'm told that snapd is going to allow snap.yaml overrides for description and summary that are in the store.

We need 4 tasks: snapstore (input validation on forms and what it puts into description and summary), review-tools (check description and summary harder (at least)), snapcraft (check description and summary harder (at least)) and snapd (filter output from snap to screen).

Once the snap store is fixed, this bug can be made public since it closes any sort of attacks via control characters wrt malicious uploads. We can then harden the review-tools, snapcraft and snapd publicly.

[John Lenton (chipaca)]

Relevant: http://people.canonical.com/~john/vt340.png

[Jamie Strandboge (jdstrand)]

This is now implemented in trunk.

[Zygmunt Krynicki (zyga)]

John, is the snapd task of this bug still in progress? Could you please update the bug with the current state?

[Ian Johnson (anonymouse67)]

The specific issue here around snapd safely displaying arbitrary description has been fixed, so I'm closing this task, but I think that we should possibly also have another new bug/task for snapd in validating the description field, etc. from `snap pack` so that for snap authors that have mistakes or errors in their snap yaml, they see the error immediately from snapcraft instead of pushing it to the store and seeing it fail from the review-tools check, but I will file another bug for that.