Snap names regexes are inconsistent or too permissive
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Canonical Click Reviewers tools (obsolete) |
Fix Released
|
Undecided
|
Unassigned | ||
Snap Store Server |
Fix Released
|
Undecided
|
Unassigned | ||
Snapcraft |
Incomplete
|
Undecided
|
Unassigned | ||
snapd |
Fix Released
|
Medium
|
Unassigned |
Bug Description
Currently, the store restricts snap names to comply with:
package_name_re_str = r'^[a-z0-
The regex above allows snap names of one single char (even '-') being registered.
The reviewer tools allow for: r'^[a-z0-
Snapd allow for: the same regex than the store plus some extra checks, see https:/
Snapcraft does not seem to enforce any regex (or I couldn't find one) -- I think we can leave this as is.
We want to ensure snapd, c-r-t and the store are consistent and do not allow one-char snap names being registered, nor having - at the beginning or end of a name, nor -- in it (similar to what snapd does but also restricting the min length).
Changed in snapstore: | |
status: | New → Fix Released |
Just to be clear, at the time of writing all projects do the same check: they check that regexp, and that it neither starts nor ends with a dash, nor contains a double dash, nor is longer than 40 characters. The rationale for doing it like this instead of with a single regexp is well documented in the projects themselves; for example, from snapd:
// the full regexp we could use, "^(?:[a- z0-9]+- ?)*[a-z] (?:-?[a- z0-9])* $", is z0-9]|( ?<=[a-z0- 9])-)*[ a-z](?: [a-z0-9] |-(?=[a- z0-9])) *$", but Go's
// O(2ⁿ) on the length of the string in python. An equivalent regexp that
// doesn't have the nested quantifiers that trip up Python's re would be
// "^(?:[a-
// regexp package doesn't support look-aheads nor look-behinds, so in order to
// have a unified implementation in the Go and Python bits of the project
// we're doing it this way instead. Check the length (if applicable), check
// this regexp, then check the dashes.