Hi Ikey! Nice to read your mail. I'm glad to see you were lurking around because I was about to mail you.
> Well, you're probably right there. I was thinking more of catch-all > cases.. but we should be maintaining a consistent usage of API. Having > it happen transparently through existing systems makes most sense, i.e. > via GtkFileChooser, GApplication, etc. (Modified launch context wouldn't > hurt either) In the long run breaking API in a symbolic way may be salutary, because we need to check which apps do get ported and behave nicely because their developers play by the rules and which play nicely by accident because somebody hacked some retrocompatibility! Though keeping very close to the current API (or mapping to it) means super easy maintenance for app devs :) I'm not sure what's gonna happen in the future, but both FDs and filenames leak some information about the OS configuration -- which could be used by malware devs in a way or another if they find exploits? (e.g., you find out a names of folders, or what other open FDs are possibly open). This begs the question of which is better to leak and maybe that should be a criteria for choosing which final API is the best. Likewise, do FDs and filenames have a utility for app developers? In which contexts and what can be done about it? Is the information leak of a filename worthy of the benefits to app devs? That's tiny details but still interesting to look at! Thanks for pointing out to GApplication. That class has interesting stuff with security implications indeed. I also would like to get rid of g_set_prgname() and debate the meaning and practice of gtk_window_set_title for an app's root window (allegedly that could contain a unique id for the app, set by the OS, because I don't want an app to cheat about its identity and mimic another app). > Point me in the rough general direction when you've got a bit of an idea > on how it wants to be implemented, and I'll turn it into codes (TM) (An > idea doing the rounds is implementing the helper within systemd, > ensuring a sane init daemon is present in this sandbox, enabling proper > kdbus, security, launching of the the process itself, and ensuring the > use of pivot_root and bind-mounts) Well, as much as I like help I really need to take some time to write code myself because I rust entirely :) I'll do the GTK Dialog running transparently through DBus (hopefully within next week), though I'll shamelessly reuse your isandbox for demonstration purposes. I had some silly issues trying to spawn my own provider through systemd (ending up with its own DBus daemon, obviously there's something cheesy about the doc I used to implement that!). If you feel that that one needs some updating or that we could already make a watchdog-using systemd provider for demo purposes, we can do that together! Thanks, -- Steve Dodier-Lazaro PhD student in Information Security University College London Dept. of Computer Science Malet Place Engineering, 6.07 Gower Street, London WC1E 6BT OpenPGP : 1B6B1670 _______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
