Rejected by Nishit Majithia. “Use of the personal-files interface is reserved for vetted publishers. If your snap legitimately requires this access, please make a request in the forum using the ‘store-requests’ category (https://forum.snapcraft.io/).” — Nishit Majithia
Last I checked KDE is vetted.
This application is a complete git suite for KDE Thanks
@0xnishit KDE is a vetted publisher, and @sgmoore is the KDE dev in charge of their snaps. I guess there was some small omission somewhere in the process.
So perhaps the confusion here is the template text used in the rejection - whilst it is reserved for vetted publishers, there still needs to be a process to assess if the use of personal-files is reasonable. That is what the forum is for and so it is still right that we discuss the request here.
@sgmoore can you please detail what access is being requested via personal-files in this case? Pasting of the plug declaration is sufficient. Can you also explain why this is needed? Thanks.
@sgmoore, apologies if template text confused you. I found the personal-file interface named gitconfig wants read access on these file
gitconfig:
interface: personal-files
read:
- $HOME/.gitconfig
- $HOME/.config/git/config
It would be better if you can explain why the read permission on these files needed?
Thanks
kommit is our git suite and it currrently does not work. I don’t think it is unreasonable for git to have read access to the users git configuration.
Did you need anything else? This is a very common approach used by git client snaps.
Thanks for the information, having read access on these below files seems reasonable given the nature of this snap.
- $HOME/.gitconfig
- $HOME/.config/git/config
+1 from me for using auto-connect for personal-files interface named gitconfig. Can other @reviewers please vote too?
thanks
+1, seems entirely reasonable for kommit as it enables core functionality and it’s from a trusted publisher.
+1 from me as well for auto-connect personal-files with read access to $HOME/.gitconfig and $HOME/.config/git/config using the iface reference gitconfig since this is clearly required for kommit (Git gui client for KDE) to properly operate. +3 votes for, 0 votes against. This is now live.
@sgmoore can you please either upload a new revision or request a manual review so the changes take effect?
Thank you very much. The other two that it doesn’t operate well without is ssh-keys and gpg-keys Can we get an auto-connect on these two?
@sgmoore can you please explain a bit more how kommit uses ssh-keys and gpg-keys and why these might need to be auto-connected by default? ‘It doesn’t operate well’ is not enough info for me to go on. Thanks.
Of course. So as a KDE developer you must use your ssh keys in order to clone a repo that you can push to. GPG keys verify your identity. This is common with all git platforms ( github, gitlab even launchpad) Thanks for your consideration, Scarlett
Thanks for the updated information @sgmoore - the issue is that these are both quite privileged interfaces but as you say these operations are reasonably common (ie. to use a GPG key to sign a commit or SSH key to access a repo etc) so I am inclined to agree that these should be auto-connected in this case.
Can other @reviewers please weigh-in too?
Without a way for individual users to opt out of auto-connections, I’m very uncomfortable auto-connecting access to SSH and GPG keys (especially the latter). One could compare this to auto-connection to the password manager, which also makes me uncomfortable. I won’t go so far as to cast a -1 vote, but I wanted to share my thoughts.
I understand that.
So my next question is, is there a way to pop a dialog box on first run informing users to please connect these two if you want your stuff to work? As it is, users will grumble and claim it broken. If I get lucky they file bug reports and I can show them the way.
Cheers, Scarlett
You could use snapctl is-connected ssh-keys which returns non-zero if the interface is not connected - and then you could use something like zenity to inform the user.
Alright, I rather agree with @kyrofa and will sort out your suggestion @alexmurray Disregard the request and thanks for your help. Cheers, Scarlett
Ok, no worries - I think that sounds like a good compromise - thanks @sgmoore, I’ll remove the request from our internal queue.