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
@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
It would be better if you can explain why the read permission on these files needed?
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.
+1 from me for using auto-connect for
personal-files interface named
gitconfig. Can other @reviewers please vote too?
+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
read access to
$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
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,
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.
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.
Ok, no worries - I think that sounds like a good compromise - thanks @sgmoore, I’ll remove the request from our internal queue.