“snapcraft register” with invalid characters still blathers on about name ownership

Metadata

Project: snapcraft (launchpad)
Number: #1723720
Type: issue
State: open
Author: ~mpt
Labels: —
Created: 2017-10-15 10:23 AM UTC
Updated: 2017-11-20 11:21 AM UTC
Closed: —

Current evaluation

`snapcraft register` shows the name-ownership blather and prompt before the store rejects invalid names. Still present at HEAD: names.py validates nothing client-side. Untriaged, only one self-comment from reporter.

Suggested action: needs triage

Reason: The report has no labels, no assignee, and the only comment is the reporter's own follow-up, so it has never been assessed by a maintainer. I confirmed the defect survives at HEAD: `StoreRegisterCommand.run` in snapcraft/commands/names.py:113-131 emits `_MESSAGE_REGISTER_CONFIRM` and calls `utils.confirm_with_user` before `store.StoreClientCLI().register()`, which POSTs straight to `/dev/api/register-name/` with no client-side name check (the repo's `validate_name` regex lives in snapcraft/models/project.py:267 and is not used here). Not a low-value closure either — the wording complaint overlaps the still-open #1886223 and #1723726, so a maintainer should decide whether to fix ordering alone or fold it into the broader prompt rewrite.

Evaluated by: mr-cal-bot

Impact: 28 Quick Win: 14 Complexity: 30 Confidence: 82 Actionability: 70

Issue body

0. Sign in with “snapcraft login” if you aren’t signed in already. 1. At the command line, enter “snapcraft register Firefox”. 2. Enter “y”. What happens: ------------ 😌 11:15:27@~> snapcraft register Firefox We always want to ensure that users get the software they expect for a particular name. If needed, we will rename snaps to ensure that a particular name reflects the software most widely expected by our community. For example, most people would expect ‘thunderbird’ to be published by Mozilla. They would also expect to be able to get other snaps of Thunderbird as 'thunderbird-$username'. Would you say that MOST users will expect 'Firefox' to come from you, and be the software you intend to publish there? [y/N]: y Registering Firefox. The name 'Firefox' is not valid. It can only contain dashes, numbers and lowercase ascii letters. ------------ What should happen: If the name is not valid, only the error message should appear. The babble and question about people expecting the name should not appear. [Originally mentioned by Kyle Fazzari in bug 1644673.]

Evaluation history

Date	Model	Scores	Action	Summary
2026-10-02 07:05 PM UTC	stealth/space-bunny-alpha	Impact: 28 Quick Win: 14 Complexity: 30 Confidence: 82 Actionability: 70	needs triage	`snapcraft register` shows the name-ownership blather and prompt before the store rejects invalid names. Still present at HEAD: names.py validates nothing client-side. Untriaged, only one self-comment from reporter.
2026-09-30 08:48 PM UTC	stealth/space-bunny-alpha	Impact: 30 Quick Win: 18 Complexity: 35 Confidence: 96 Actionability: 92	needs triage	snapcraft register still shows an ownership confirmation before the Store rejects invalid names. The UX bug remains open and untriaged, with no client-side name validation before the API request.
2026-09-24 08:01 AM UTC	qwen/qwen3.6-35b-a3b	Impact: 30 Quick Win: 15 Complexity: 30 Confidence: 70 Actionability: 70	keep open	UX bug: snapcraft register shows ownership confirmation prompt before validating name format, confusing users when names contain invalid characters.
2026-09-01 08:00 AM UTC	qwen/qwen3.8-27b	Impact: 10 Quick Win: 8 Staleness: 95 Complexity: 15 Confidence: 75 Support Request: 5	close stale	snapcraft register prints a lengthy name-ownership preamble and prompt before validating the name, so invalid names like 'Firefox' get confusing output. Unlabeled, 0 comments, inactive ~8.8 years; the register command/prompt no longer exists in current snapcraft.
2026-07-23 11:53 AM UTC	qwen/qwen3.6-35b-a3b	Staleness: 98 Complexity: 15 Confidence: 85 Support Request: 5	close stale	snapcraft register prints a lengthy ownership preamble before validating snap names, causing confusing output for invalid names. Unlabeled, 8+ years old, no maintainer response, and likely obsolete due to CLI changes.
2026-07-22 12:19 PM UTC	qwen/qwen3.6-35b-a3b	Staleness: 98 Complexity: 15 Confidence: 85 Support Request: 5	close stale	CLI validation order bug where snapcraft register prints ownership disclaimers before checking name validity. Extremely stale with no maintainer interaction or labels over 8 years.
2026-07-09 09:56 PM UTC	qwen3.6-35b-a3b-mtp-q6	Staleness: 95 Complexity: 15 Confidence: 85 Support Request: 10	close stale	snapcraft register displays a lengthy ownership disclaimer before failing on invalid snap names. Unlabelled, inactive for ~8.5 years, no maintainer response.

Update history

Date	Change
2017-11-20 11:21 AM UTC	created

Related work

Related To: snapcraft (launchpad)#1886223 (confidence 85%)
Proposed rewrite of the same `_MESSAGE_REGISTER_CONFIRM` prompt (misleading rename/$username advice); its evaluation summary states the text is 'Still present verbatim at HEAD', matching what I read in snapcraft/commands/names.py:44-58.
Related To: snapcraft (launchpad)#1723726 (confidence 65%)
Sibling report on the same `snapcraft register` output being 'mysterious and inaccurate'; listed as a related issue and would likely share a fix or be closed together.

Related issues

Issue	Project	State	Summary	Similarity
#1886223 snapcraft recommends bad naming standards	snapcraft (launchpad)	open	Proposed rewrite of the `snapcraft register` name-claim prompt, which wrongly says snaps can be renamed and steers users toward $username- name suffixes, contradicting the docs. Still present verbatim at HEAD.	75%
#1723726 “snapcraft register” message is mysterious and inaccurate	snapcraft (launchpad)	open	Wants the 'snapcraft register' confirmation prompt rewritten: undefined 'we'/'our community', false claim that snaps get renamed, hedged wording, and a prompt users can't truthfully answer. Text still unchanged in snapcraft/commands/names.py	73%