GTK file picker selection with keyboard or double click is broken

[ron_1]

but I'll let the vocal minority of Linux users decide whether they think it should be done or not.

I can wait.

[JayByrd]

I tend to agree here: definitely not worth breaking double-click/enter-key functionality to address a low-severity, low-probability "exploit." (If it hadn't been brought to our attention, I'm sure most of us would have kept on using it without ever knowing there was a "flaw" in the file-chooser!)

In any event, it is still irking me that the changes in the PR didn't work. I may keep digging to try to find out how to guard against the social-engineering exploit, without breaking the existing functionality. If I do solve the mystery, I'll report back here.

@andy
Unfortunately, the workaround works only for GTK3 builds, but doesn't seem to have any effect when using GTK2. Like I said, I'll keep poking around...

[andyprough]

@andy
Unfortunately, the workaround works only for GTK3 builds, but doesn't seem to have any effect when using GTK2. Like I said, I'll keep poking around...

Should still be able to drag and drop a file, right? The preference shouldn't be the only workaround I wouldn't think.

[athenian200]

Would this mean that GTK2 does in fact requires people to call file picker dialogs in an insecure way that can lead to exploits?

If so, it does seem to justify the removal decisions distros are making lately. Also likely worth noting that GTK2-specific exploits may not even have their own CVEs at this point seeing as Firefox no longer uses it... so this could just be the tip of the iceberg.

However, dinosaur noted something interesting in an earlier post:

Working fine for me with GTK2 builds, but I don't even use it: I have ui.allow_platform_file_picker set to false in about:config (I prefer PM's file picker to GTK2's: leaner, less UI clutter).

I think we have a built in XUL-based file picker that is a bit more limited than the native file pickers are, right? Could we possibly use that by default? I think that one should either be more secure by default, or else we can tweak its behavior to make it more secure.

It doesn't seem like users are that bent on using the native file picker dialog, and they can always change the preference if they don't like the new behavior.

[wmlive]

I've just backed out the change, reverting to what we had before, instead of leaving the default set to something that isn't working as expected, to avoid other side effects.
I'm on the fence about making an out of band release for this (for Linux only) but I'll let the vocal minority of Linux users decide whether they think it should be done or not.

Just did a preliminary gtk2 build on debian/bookworm while applying the cherrypicked patch supplied with #3137 and verified the file chooser works as expected.
No need for an out of band release for such a minor issue if all what is needed is to simply apply that small patch by builders who are redistributing palemoon binaries.

I'd very much dislike if the file chooser's expected functionality would be broken by an overzealous fix for some hypothetical threat scenario one usually never stumbles over in the real world.

Give me a few day's time to create the usual range of gtk2 based packages.

[vannilla]

Would this mean that GTK2 does in fact requires people to call file picker dialogs in an insecure way that can lead to exploits?

The GTK3 default file picker has the same "social engineering" issue, it's not a matter of 2 vs 3. The difference is that UXP, inheriting from Mozilla, overrides some behaviour and this allows to patch this issue without waiting for GTK.
The pref swaps the file picker to GTKFilePickerNative which does not exist in GTK2, that's why it doesn't work.