@dclane can you look into this also?
My opinion on this one is that dot-folders access, especially write access, is generally pretty sensitive/powerful and so perhaps this is best left as a manual connection and you could prompt & warn the user if the plug is not connected. I’ll give a tentative -1 auto-connecting dot-folders, but certainly other @reviewers are welcome to disagree.
The biggest problem is, even if we use portals to save to these folders, if we try to set the initial directory in the file dialog, it’ll show one such popup, which is the case in my app too, that requires access to .local/share/applications.
A major issue here is that granting write access to the requested directories, allows for escape confinement. Please see a related discussion in Request for personal-files interface in Chromium for ~/.local/share/applications - #4 by alexmurray.
Pinging @odysseus-k and @lofidevops here again to see if next steps were defined.
Well, if I may, I would like to give some suggestions on this:
- Allow this to only open-source snaps(so that anyone can verify it)
- Allow auto-connect only if the app upstream/developer confirms by showing their code that they don’t write to those folders directly.
- With every new release, the maintainers must create a post in forum asking continuation of the autoconnection and if they don’t after a week, revoke the auto-connection. Thus, malicious changes done in new releases, can’t be pushed to the users.
- Backup apps should be given some space. This app falls into that category as it takes backup of the current desktop. If an app can qualify even for the classic confinement, why not this.
Elaborating point - 2:
As I showed in my screenshot(it’s my WIP desktop file installer/editor app), even if I/devs use the portals to get the path, if they want to open up that path with Gtk.FileDialog::set_initial_folder or in flutter(my case) FilePicker/ FileSelector::setinitialDirectory, it’ll show that popup, No permission to folder .local/share/applications and the process will not complete, until the user clicks the okay button.
Else, in my app, I made it work, even without using the home plug.
@emitorino As per the Process for aliases, auto-connections and tracks the next step here would be for a reviewer or architect (not necessarily someone from the Store team) to tally the results and provide a short summary. In this specific scenario, the outcome would be a rejection of this request if the current voting remains unchanged.
Can atleast the plug be allowed, and not auto connected?
I fully agree with @dclane, write access to dot-folders is very sensitive/powerful and we must be very cautious to grant it. Thus, I’ll also give a -1 to auto-connectdot-folders. However, considering the purpose of the snap I’ll support manually connectthe dot-folders interface, +1 from me.
1 Like
Yes, +1 for a installation and connection of dot-folders, without auto-connect.
1 Like
FYI @reviewers - before granting this, since this permission allows sandbox escape, publisher vetting is required first.
I am publisher and developer of this app.
2 Likes
@pedronis can you please provide your opinion here?
We (some of the @reviewers) were discussing this request for some time today. On one side we provide a system-backup interface, but there are no restore capabilities available to support this use case. On the other side, granting write access to the various personal-files directories requested here not only allows for confinement escape, but also access to very personal or even sensitive information that can be store in those locations.
Even though the requested directories are limited, this looks like a classic confinement request (but backup/restore capabilities are not a supported category).
Also FYI @soumyaDghosh is applying to be a snapcrafters member.
Now, I am 
Any updates on this?
I’m taking over publisher vetting for this one.
@vikdevelop could you please get back to my private message. Thanks.
1 Like
Should I ping the upstream? He’s actually kinda upset about this long time being taken.