Currently, Git-based apps can only run in --classic confinement due to the fact that This proposal suggests a new interface to specifically allow git repositories to be accessed.home and removable-media interfaces don’t allow access to hidden files (including, .git).
When the home interface is connected, .git is allowed in any subdirectory of ~ (eg, /home/user/projects/blah/.git). $HOME is set to SNAP_USER_DATA so snaps will have access to ~/snap/name/revision/.gitconfig and ~/snap/name/revision/.ssh. If people insist on having git access all their ssh keys rather than just snap-specific keys in SNAP_USER_DATA, we have an ssh-keys interface that can be used.
It seems like a snap author has everything a typical ‘snap that uses git’ would need-- can you give specific examples of snaps that are classic because there is no git interface?
I just simply assume that all non-hidden files are not accessible by the home interface according to the Interfaces reference:
|
home| Can access non-hidden files in user’s $HOME and gvfs mounted directories owned by the user to read/write/lock. |
If that’s the case I have less problem with it with an exception that I do have a Git repository in my home directory for tracking rcfiles (but it should be replaced by vcsh-like solutions so that’s not really a problem as well). Thanks for pointing out.
There’s also a case for etckeeper which tracks files under /etc, though I’m not sure it is really be solved via new interfaces.
Is it possible to expose $HOME/.gitconfig and /etc/gitconfig to the snap(via an interface)?
Not at this time.
The use cases you described (please correct me if I’m wrong) are:
With the first, this is a highly specialized environment. That doesn’t mean we can’t support it, but it is really a variant of the ‘backup’ scenario and access to .gitconfig is only one part of the access (and easily handled by copying .config to SNAP_USER_DATA). The etckeeper scenario is also a form of backup, but in this case for ‘etc’ and the .gitconfig isn’t going to be from a user, but for the root user, who isn’t typically going to have a .gitconfig and if it did, we probably wouldn’t want to share it with the snap (so again, an etckeeper snap would make sure to call git to use a .gitconfig in SNAP_USER_DATA). Since both are variants of the backup scenario, today snaps should use classic confinement and/or just copy .gitconfig to SNAP_USER_DATA.
Things are progressing in this area. Soon portals will allow snaps that use portals to not need the home interface or other special privileges for file access and on the roadmap is handling that for other cases.
I don’t really care about the two use cases for now as users can’t easily access to their user-wide global gitconfig is a greater problem, including but not limited to:
user.name, user.email)user.signingkeycredential.helperAs mentioned before, an application can tell the user to copy the files into place or otherwise detect that the gitconfig is not yet configured for this snap. Furthermore, this allows per-snap configuration for each of the fields you mentioned which can be handy since the identity, keys, etc can be different for each snap.
Git permits configuration granularity at the repo level, if needed. What would be the advantage of adding another layer of configuration at the snap level? Wouldn’t this cause confusion? Would any advantages outweigh the disadvantage of not having access to the global git config?
If people want to create a gitconfig interface, it can be proposed as a PR to the snapd project and discussed there.
The point I’m trying to make is that a snap doesn’t require the entire git configuration just like it doesn’t need access to all of the user’s ssh keys for using git. Having the git configuration and ssh keys specific to the snap is a nice property for snaps and snaps using git can add a little bit of code on first run to prompt to create the config and ssh keys or to tell the user how to copy them into place. In terms of usability, the snap should be doing this anyway.
Furthermore, and importantly, the core snap doesn’t have git installed and git isn’t installed by default in (most?) classic distributions, so a snap can’t depend on the file being present or compatible with whatever git happens to be in the snap.
Lastly, I keep mentioning this point because if we allow a .gitconfig interface, then something in someone’s .giticonfig isn’t going to work because the snap is running under confinement and the user’s normal tooling does not. Eg, I fully expect that people will complain about ssh keys that aren’t accessible and then there will be a proliferation of auto-connection requests for the ssh-keys interface.