Feature request: Post-install messages

snapd
1

It would be nice to be able to provide a brief (length limited - maybe only 500 characters?) post-install message for a snap.

Example issue:

Some snaps with third-party packaging have functionality that requires manual plugs. However, an unaware user may not know that manual plugs are required, leading to a confusing user experience. For example, here is a potential user experience for a github CLI user on a new Ubuntu machine:

lengau@hyperion:~$ gh auth login
Command 'gh' not found, but can be installed with:
sudo snap install gh       # version 2.6.0-15-g1a10fd5a, or
sudo apt  install gh       # version 2.4.0+dfsg1-2
sudo apt  install gitsome  # version 0.8.0+ds-6ubuntu1
See 'snap info gh' for additional versions.
lengau@hyperion:~$ sudo snap install gh
gh 2.6.0-15-g1a10fd5a from Casper (casper-dcl) installed
lengau@hyperion:~$ gh auth login
? What account do you want to log into? GitHub.com
? What is your preferred protocol for Git operations? SSH
? Generate a new SSH key to add to your GitHub account? No
? How would you like to authenticate GitHub CLI? Login with a web browser

! First copy your one-time code: 0000-0000
Press Enter to open github.com in your browser... 
✓ Authentication complete.
- gh config set -h github.com git_protocol ssh
✓ Configured git protocol
✓ Logged in as lengau

So far so good. But:

lengau@hyperion:~$ gh repo clone casperdcl/cli
Cloning into 'cli'...
warning: templates not found /usr/share/git-core/templates
The authenticity of host 'github.com (140.82.113.3)' can't be established.
ECDSA key fingerprint is SHA256:p2QAMXNIC1TJYWeIOttrVc98/R1BUFWu3/LiyKgUfQM.
Are you sure you want to continue connecting (yes/no)? yes
Failed to add the host to the list of known hosts (/home/lengau/.ssh/known_hosts).
Load key "/home/lengau/.ssh/id_rsa": Permission denied
git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
exit status 128

At this point, a user who’s unaware of the details of snap confinement may not know that it’s a confinement-related issue and may raise it as a bug in the original application.

While a knowledgeable snap user may recognise the correct command to fix this to be snap connect gh:ssh-keys, this isn’t knowledge we can assume.

By providing the snap maintainer with a way to provide post-install messages, we can reduce the likelihood of this. For example:

lengau@hyperion:~$ sudo snap install gh
gh 2.6.0-15-g1a10fd5a from Casper (casper-dcl) installed
If you plan to use SSH to connect to GitHub, please manually connect the 
ssh-keys interface with the command: snap connect gh:ssh-keys

While this isn’t providing any new information that isn’t already available to the user, it is providing that information in a more user-friendly manner.

Potential for abuse

This does of course have the potential for abuse (npm being a good example). This can be worked around the with the same process as auto-connect requests (in other words, the developer has to make a #store-requests forum post and be approved by the policy-reviewers team). This could also become a “third way” when handling auto-connect requests. As it currently stands, the possible answers are “yes” and “no,” but this would provide an option for “no, but here’s a compromise.”

Other use cases

Other positive use cases for post-install messages could include:

  • Notifying users that a snap is unofficial and directing them towards the correct bug reporting channel. (This could potentially even be automated for groups such as snapcrafters)
  • Providing other snap-specific information, especially for unofficial snaps (e.g. “please don’t update this Windows app through the help menu”)
5 Likes
2

Perfect!! snap connect gh:ssh-keys solved the Failed to add the host to the list of known hosts problem despite many permission and ownership fiddling for the .ssh/ directory’s content
 I had been facing it for 3 months or more and did not even think it was related to the snap containment! Thanks!!!

1 Like
3

I was told to look into zenity or in my case kdialog. I assume some sort of command chain script. Will post when I work that out. Though it looks like even with the manual connects there are issues. @myselfhimself have you tried the personal-files plug?

4

Hello, I have not tried the personal-files plugin.

5

We just had a use for exactly this feature in a vendor package that requires some post-install configuration that can’t be done from within the sandbox. It would be nice to alert the user to the need instead of expecting them to have divined the knowledge from somewhere else (e.g. documentation for the snap or reading ‘snap info’) before installing it.

Our case would have been OK with a single line of text pointing the user back to the post-install documentation.

There’s a bunch of hacks I considered, including a one-shot wrapper around each packaged tool that displays the help text and quits the first time the user runs a tool, but that feels fragile and a lot like extra maintenance to carry around.

I can’t add much toward an implementation that is not primed for terminal spam like the NPM case. All the solutions to that problem I have come up with ultimately come back to having the snap store team manually approve requests for post-install messages. I don’t think that approach would scale in the long run, given how useful the feature would be for a lot of snaps.

In the specific case @lengau proposes, would it suffice to have the post-install message auto-generated to show a list of non-auto-connected (or maybe all) plugs to prompt the user? This could apply to every snap. Since it’s generated from the list of plugs in the snap it wouldn’t display anything that 'snap connections $MYSNAP` wouldn’t already display when invoked.

1 Like