“never explicitly asked” I’m sure I’ve been asked by some installation process about permissions in the last couple of years, no idea whether it was “Software”.
“If the user does not notice GNOME Software warning…then the user has no idea the app is dangerous.” Yes, so perhaps asking is better since they have to act.
I’ll test this, it will take a while though. If it did work it would be a win for simplicity - but I wouldn’t think that it was a win for the security model since it seems to conflict with its aims.
Is this not a relevant question?
it is exceedingly relevant, but it was already answered, earlier in thread:
Are you saying that by “RPM-based applications are equally dangerous, yet they are displayed as safer…” mcatanzaro meant that they don’t get flags?
I’ll test this, it will take a while tthough. If it did work it would be a win for simplicity - but I wouldn’t think that it was a win for the security model since it seems to conflict with its aims.
Well, the aim is to make sure the user is in the loop. If you pop up a dialog and the user picks, e.g., a directory, and that directory gets registered as “okay for this flatpak” with the document portal, then everyone is happy I think. The directory gets made available to the app via a fuse mount and all the other directories that the user didn’t pick, won’t be. at least that’s how i think it works.
Are you saying that by “RPM-based applications are equally dangerous, yet they are displayed as safer…” mcatanzaro meant that they don’t get flags?
That’s right, RPMS, despite being unsandboxed, don’t get flagged as such. Clearly not awesome, but it keeps status quo, status quo. One small saving grace is the RPMs are from a “trusted” repository, the distribution, but still…
Does the distribution scrutinise the RPM application for dodgy behaviour?
clearly different distributions have different levels of QE they provide. But, especially for community distributions, there’s obviously going to be a rather large testing gap.
That’s one of the reasons flatpak provides value-add, it eliminates a lot of the associated risk when the sandboxing is on.
Mixed results. It allows me to select a directory, but puts a strange directory name (/run/user/1000/doc/abcd1234/chosendirectory) on the window. It permits me to read, write and delete in that directory. If I select a file it presumably does the same - but that isn’t enough as I want access to all files in that directory like the one selected. Eg choose document1 and have access to document1, document2 and document3.
Right the strange name is the fuse mount point. I don’t think there’s currently a way to get the unsandboxed directory name, though, I’m not 100%. If that’s true, I guess you could just show “basename” in the UI as a less than perfect compromise.
Not sure I follow. If you have the directory and can read everything in it, why cant you access all the files in the directory that are like each other? You have full access to the directory right?
thinking about it more, I think I may understand what you’re saying.
Your program has two modes of operation:
- The user picks a directory, and the program scans over all the files in the directory, matches up files that logically should be grouped and then processes every group
- The user picks a specific file, and the program matches up that file with all the other files that belong in the group, and then processes just that group.
do I have it right?
To make that clearer - Gtk.FileChooserNative.
So I don’t think there’s a way to say “automatically allow file2.data into the sandbox if a user picks file1.data” in Gtk.FileChooserNative using the currently available portal apis. I think the best you can do is show the file chooser with “multiple selection” enabled and ask the user to select “file1.data and file2.data” at the same time (or do the other option of asking for the directory name)
“asking for the directory” wouldn’t work.
That might work if set_select_multiple which is shown for filechooser can be applied to filechoosernative.
Interestingly:
GtkFileChooserNative
deprecated: 4.10
GtkFileChooser
set_select_multiple
deprecated: 4.10
Gnome deprecates native and Flatpak recommends it. and multiple is deprecated by Gnome, don’t know about Flatpak.
You can still use it even though it’s deprecated. Gtk.FileChooserNative isn’t going away in gtk4. The new api is Gtk.FileDialog though and it provides an api for picking multiple files.
So FileDialog replaces FileChooser, but not filechoosernative I think. I’ve tried adding multiple to the latter, but it didn’t work. I haven’t got time to do this properly now, but will have a go later.
you should be able to file_chooser.set_select_multiple(True) on a Gtk.FileChooserNative instance afaik. I’m surprised it’s not working. If you get rid of Gtk.FileChooserNative entirely though, you should also be able to do
def set_files(self):
file_dialog = Gtk.FileDialog()
def on_selected_files (object, result):
files = file_dialog.open_multiple_finish(result)
do something with files ....
file_dialog.open_multiple(self.window, None, on_selected_files)
All the GtkDialog subclasses in gtk 4 are deprecated. I believe this is for 3 reasons:
- Get rid of the temptation to use gtk_dialog_run which can have serious unexpected side-effects in some programs (because it invokes a recursive main loop)
- Get rid of the temptation to muck with the dialogs directly by adding or hiding widgets in them (not a concern for Gtk.FileChooserNative, but is a concern for other Gtk.FileChooser implementations).
- Use a more GIO like async api. GIO established a pattern for doing async operations using GCancellable, etc, so it makes sense to adopt it.
1 Like
Exactly. I’ll build the Flatpak with
[quote=“chrisofbristol, post:37, topic:13875”]
I’ve tried adding multiple to the latter, but it didn’t work.[/quote]
That was done in a hurry. It works on the desktop, I’ll build the Flatpak and check that.
I can see that would be a way of doing it, but the output file would not be accessible. The user would then have to use the file chooser to select that. Completely unworkable.
I wonder why FileChooserNative is deprecated by Gnome as it is promoted by Flatpak.
The flagging system doesn’t seem very practical:
- there is a clash between several Gnome-related things - GTK/Software/Flathub (Flathub is owned by Gnome I believe).
- flags are tackling the wrong problem. The real problem is that not there aren’t the resources to check all the apps for safety.
I’ll lump it with the red flag. Thanks for your efforts to get round the problem.