Requesting a classic confinement approval for the hub snap.
Reasons for classic:
this snap requires git
there is no git snap
I can use a git stage package, but the snap internal git command doesn’t have access to the user’s ~/.gitconfig file, even with the :home interface, because it’s a dotfile.
hub is a wrapper for git and git requires access to the keys in .ssh
if there was a git snap, that snap would likely need to be classic and then hub would be able to use an interface to access git. This isn’t the case and the git snap name is reserved so I could make a git snap.
I don’t have any admin privileges so I can’t address your request directly, but I would make a couple suggestions (which may or may not be helpful). Please feel free to ignore them if they aren’t helpful.
I believe the “right” way of packaging your snap would be to bundle git with your snap. This would address your third bullet. It’s true you don’t have access to ~/.git-config (none of the dot files are accessible through the home interface). However you could put the file in $SNAP_DATA/.git-config instead. Your wrapper would have to send the correct flag to git to pick it up from a non standard location of course. Finally, you can access ssh keys with the ssh-keys interface. See: Interface management
I don’t know how many people I’d get to move their Git config. Hub is made by GitHub and I’m just packing the tool. Git can still be used without the wrapper. With strict confinement, I would have to 1) Get the user to move their Git config and then 2) Get them to use an environment variable to tell Git where the new location is.
This matters because anyone using hub likely already has Git installed. Installing it in the snap via a stage-package, which I’ve tried, means it runs its own git instance and config.
Nice! I did not know that as the Snapcraft Doc doesn’t list it. I’ll see if I can make a PR.
As with my git application snap, it also requires running Git project specified hooks, which may call any program that can’t be packed into the snap itself(e.g. pre-commit for pre-commit.com).
I’m +1 on this being classic, as with many git related tools for the reasons expressed above (git hooks and the like) as well as the fact that git repos can be hosted anywhere on the filesystem, not just in $HOME.
Please see my response in New Interface Proprosal: The `git` interface. It seems between the ssh-keys interface and the ability only to add github information to the snap-specific gitconfig, this is sufficient for the snap to work in strict mode.
We are getting a lot of requests for ~/.gitconfig. I suspect use of the import path idea for this would be the way to go (which, incidentally, would be a great starting PR for someone interested in snapd development).
For me to convince someone to install hub via a snap would require:
The install command
Manually connecting the private SSH interface
Manually creating a symlink (or copying) their gitconfig. Or wait until a new interface is available that they’ll have fee to manually connect.
This is at least one step too many and it still only partially supports Git.
If they have a git hook that enforces commit message structure for example, that hook will only run if they use their system Git but hub push would bypass that check.
Hub was made by GitHub to add more power and convenience to Git. Installing this way adds inconvenience and castrates git to an extent.
For me personally, I don’t see users going out of their way to install the snap version then which makes my effort here useless.
re: The interface, are you suggesting creating an interface that imports a path would be giving more priority than one that allows access to .gitconfig?
I’d rather submit a PR for the latter because with the formal, I take it if someone changes their gitconfig, it then wouldn’t be reflected within the snap. Did I understand that incorrectly?
The idea is that if we have the former we don’t need the latter. Ie, if we have an interface (whatever it is named or whatever the interface attribute is called) that allows reads (or possibly writes) from somewhere, the permissions would be allowed so long as the interface is connected, not just at the time of ‘import’ (which is one defined use case, but there are others). This interface would be manually connected, but like any other manually connected interface, a snap declaration could be granted to autoconnect,
More concretely for you: I suspect you would declare in your snap this new interface that allows you to read (or possibly read/write) ~/.gitconfig. Your snap is ‘hub’, designed to be used with github and therefore it is plausible it would be granted auto-connection of the interface. So long as the interface is connected, you would be free to access the file directly or via a symlink.
As an aside, you mentioned “3. Manually creating a symlink (or copying) their gitconfig” - note that you wouldn’t be able to symlink from $SNAP_USER_… to ~/.gitconfig because AppArmor will resolve that and block access to ~/.gitconfig. You could mv ~/.gitconfig into $SNAP_USER_… then symlink from ~/.gitconfig to $SNAP_USER_… though. I’m not saying it makes sense for you to do this; I just wanted to alert you to how symlinks are mediated by AppArmor.
I don’t see a good way out of granting this application classic, at least for now. The problem isn’t the fact it needs access to .ssh or .gitconfig, but that it will need access into all kinds of locations, and all kinds of system tools to satisfy the execution of hooks therein.
We are working on a feature that may solve that part of the problem, but this will still take a good while to land end-to-end, so from my end +1 on granting classic confinement.
The same also applies to Git Attributes, which can specify any random program that accepts I/O from standard input-output devices as clean/smudge filters.
