On Wed, May 28 2025 at 06:18:41 PM -04:00:00, Neal Gompa
<ngomp...@gmail.com> wrote:
Honestly, we don't really push for security like that. We have
generally provided optionality, but that doesn't mean we want security
to outweigh our community and usability. The crypto policies is an
example of the problems caused by pushing security above everything
else, as we wound up with several releases in a row of the package
manager being broken because RPM could no longer verify Google
Chrome's GPG keys (among other things).
This is really not at all a comparable situation. A heap buffer
overflow in a video decoder is an urgency that requires timely response.
That said, keep in mind there are going to be many, many other similar
bugs in every video decoder that we do not know about, so it doesn't
make sense to worry *too* much about any particular such issue. The
inability to fix known vulnerabilities is a bigger problem than the
vulnerability itself.
Software developers MUST plan for videos decoders to be compromised by
unknown zero day issues. Video decoding should ideally be performed in
a sandbox. If you're watching video in your web browser and are
compromised via the OpenH264 decoder or any other video decoder, you
can be confident that a separate sandbox escape is required to attack
your desktop, which is expected to be much harder than exploiting the
decoder. Whereas if you're watching the same video locally using a
Totem/Showtime/VLC RPM, that is pretty dangerous and you'd better
really trust that video file. Watching the same video in the same app
packaged by Flatpak instead of RPM could be much safer, but only if the
sandbox is not subverted, and in practice it's very common for Flatpak
apps to subvert their sandboxes.
Michael
--
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
