Title length in snapcraft.yaml/snap.yaml

What is the appropriate length for a title? @chipaca mentioned in a PR https://github.com/snapcore/snapcraft/pull/2412#discussion_r235383825 that it should probably be 64 bytes by reading an implementation (and not the actual string length). Is that appropriate and do we want to settle on that? I would personally much prefer for it to be string length to have more of a user friendly error when exceeded

Getting the following folks into the loop explicitly as they have existing implementations:

  • @jdstrand what are you doing for the review tools?
  • @roadmr what is the limit for the store side?
  • @robert.ancell what’s the limit for the glib bindings for snapd?
  • @chipaca what is your take on snapd?

The store’s current limit is 64 “maximum length (in characters)”. Note this is characters, not bytes; for instance, I set the title for a snap to a 64-character string that encodes in 192 bytes and it was accepted.

  • Daniel
1 Like

Is this documented in any place?

snapd-glib doesn’t enforce any limits on strings from snapd, so they can be as big as you can malloc.

At what point would such a long title look bad on Gnome Software though?

Apart from a bug with the featured app we show:

  • about 12 characters in editors picks
  • about 60 characters in search results
  • all the characters on the details page (just have to scroll right to see them)

We’ve just had a conversation here at the sprint, and looked at the list of long titles currently in the store. My recommendation given that conversation and the screenshots above is to cut out at 40 characters. The store should reject anything above it, and clients should truncate with “…” at the end, so that we don’t break any existing snaps. There are less than 100 entries above that limit in the store, and it’s almost entirely consisting of test cases and bogus snaps. The 2 or 3 cases which are not test cases or very bad titles could easily be reduced under that limit.

2 Likes

Please, and at the risk of teaching people’s grandmothers to suck eggs, if you make bugs / tasks based on this, and your client (or at least its validator suite) is written in javascript, note that 40 unicode characters is not just the length of the thing; javascript strings are utf16 and the length indicates as much. Instead of str.length you want [...str].length:

> "foo\u{1F427}".length
< 5
> [..."foo\u{1F427}"].length
< 4
1 Like

having that logic in snapd is hard right now: we have a single validation codepath for both ‘pack’ and ‘install’, and what you’re saying (if I understood it correctly) is that ‘pack’ should fail to validate titles longer than 40 runes long, but install / info / etc should truncate it.

The suggestion was for pack to remain as-is but the store would reject new entries with excessive titles, but thinking further about it, maybe we should make both snapd and the store reject it, because until this week an upload of a snap with a title of any length at all would be flagged for manual review, and @jdstrand was surprised that the field even existed. That implies to me that we don’t have snaps being uploaded with titles yet, and the titles are showing up via the UI in the store which comes into snapd via a different path.

So, @jdstrand, can we please reject any titles with more than 40 characters at review time?

Then, with snapd rejecting it at install/pack time as well, we shouldn’t have any hardcoded titles like that. Then it’s just a matter of fixing the UI and APIs to reject it, so that it doesn’t come into snapd via the store API.

1 Like

so, yaml validator -> fails on >40 runes
json unmarshaller -> truncate with … at >40 runes
on it

This makes sense given that most people would create snaps through snapcraft and we are just implementing that functionality now.

I’ll take care of this.