4 ms·

I agree, how thin skinned are people? this seems like valid criticism that wasn't acted on in two years. What is an appropriate 'tone' in this case

chekovcodes 6y ago
Tone is narcissistic and self-important - it does not even tip a hat to address prioritisation or resource constraints - it's just "this is important to me THEREFORE IT IS IMPORTANT, GNASH, WAIL". I also think the author does not understand end-user software - if you package everything up so it is very secure by default, almost nobody will ever use it and nobody will care except the people who are capable of securing it themselves.
cycloptic 6y ago
An appropriate tone would be to press the angle that help is needed and either offer to help patch the applications or mention where contributors can get started. I get the author's concern but there is nothing useful in this article. It's misleading suggesting that the problem is with flatpak when the problem is that certain applications aren't using its full capabilities, aren't configured correctly and are in need patching. Or in the worst case, might need a redesign to fit the sandboxing model. This needs to happen with any sandbox that uses this model, not just flatpak. There is nothing else that can be done about this short of suggesting users switch to a different sandboxing model like Qubes. (Maybe the blog author can try that too and see how it goes, or could develop their own sandboxing model just to see how hard it is on a complex system like Linux)
- dylan-m 6y ago
  As well as misleading, the article seems outdated? Which is weird, because archive.org's first snapshot of it is today. So, GNOME Software has included a "Permissions" field (which lists an application's specific sandbox holes) since - if I recall correctly - GNOME 3.34: https://i.imgur.com/lCGgA1B.png https://i.imgur.com/lCGgA1B.png. Not perfect, but definitely better than pictured. It's a bit of a shame that people have to use older versions of GNOME in 2020, but then, it's nice that Flatpak makes it easy to run new applications regardless :) Also, I was trying to verify the author's claim about a vulnerable libssh in the gitg package, partly because I was curious whether they'd bothered to report any of these issues upstream. Looks like that was fixed in May: https://github.com/flathub/org.gnome.gitg/pull/12 https://github.com/flathub/org.gnome.gitg/pull/12. Similar story with ffmpeg: https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/commit/d7d8582f750e1165fd3fd637f8fcb62104ede2c8 https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/commit/.... So, woefully behind schedule, but, how long was the author sitting on these? It would be more accurate, less irritating, and more persuasive if they simply talked about it after the fact: this happened, various things are wrong with it, it should be avoidable, etc.
  - frabbit 6y ago
    The first two CVEs linked in the article do not even exist: whether due to rejection or something else is uncertain.

chekovcodes 6y ago

Tone is narcissistic and self-important - it does not even tip a hat to address prioritisation or resource constraints - it's just "this is important to me THEREFORE IT IS IMPORTANT, GNASH, WAIL". I also think the author does not understand end-user software - if you package everything up so it is very secure by default, almost nobody will ever use it and nobody will care except the people who are capable of securing it themselves.

cycloptic 6y ago

An appropriate tone would be to press the angle that help is needed and either offer to help patch the applications or mention where contributors can get started. I get the author's concern but there is nothing useful in this article. It's misleading suggesting that the problem is with flatpak when the problem is that certain applications aren't using its full capabilities, aren't configured correctly and are in need patching. Or in the worst case, might need a redesign to fit the sandboxing model. This needs to happen with any sandbox that uses this model, not just flatpak. There is nothing else that can be done about this short of suggesting users switch to a different sandboxing model like Qubes. (Maybe the blog author can try that too and see how it goes, or could develop their own sandboxing model just to see how hard it is on a complex system like Linux)

dylan-m 6y ago
As well as misleading, the article seems outdated? Which is weird, because archive.org's first snapshot of it is today. So, GNOME Software has included a "Permissions" field (which lists an application's specific sandbox holes) since - if I recall correctly - GNOME 3.34: https://i.imgur.com/lCGgA1B.png https://i.imgur.com/lCGgA1B.png. Not perfect, but definitely better than pictured. It's a bit of a shame that people have to use older versions of GNOME in 2020, but then, it's nice that Flatpak makes it easy to run new applications regardless :) Also, I was trying to verify the author's claim about a vulnerable libssh in the gitg package, partly because I was curious whether they'd bothered to report any of these issues upstream. Looks like that was fixed in May: https://github.com/flathub/org.gnome.gitg/pull/12 https://github.com/flathub/org.gnome.gitg/pull/12. Similar story with ffmpeg: https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/commit/d7d8582f750e1165fd3fd637f8fcb62104ede2c8 https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/commit/.... So, woefully behind schedule, but, how long was the author sitting on these? It would be more accurate, less irritating, and more persuasive if they simply talked about it after the fact: this happened, various things are wrong with it, it should be avoidable, etc.
- frabbit 6y ago
  The first two CVEs linked in the article do not even exist: whether due to rejection or something else is uncertain.