On Sun, Jul 2, 2023 at 5:01 PM Demi Marie Obenour <demioben...@gmail.com> wrote:
> On 6/3/23 08:42, Michael Catanzaro wrote: > > On Sat, Jun 3 2023 at 10:26:07 AM -0000, John Iliopoulos < > jxftw2...@gmail.com> wrote: > >> Hello, > >> > >> While i completely understand why you do this i do think that it is > >> important for desktop/workstation oriented devices to have some > >> optional access to Office directly from the image file. Have you > >> considered shipping the LibreOffice flatpak via the ISO much like > >> Fedora Silverblue does with various other applications? > >> > >> This is the first time i reply to a mailing list so i hope i have not > >> done anything wrong. > > > > Hi. Welcome to the list. You haven't done anything wrong. > > > > For Fedora Workstation, the mid-term plan is to ship all preinstalled > > apps as Fedora Flatpaks. We cannot ship anything from Flathub because > > FESCo will not allow it. I don't *like* this FESCo requirement, but I > > also don't expect that to change. Accordingly, since Fedora Flatpaks > > are built from Fedora RPMs, maintaining the LibreOffice RPMs is > > essential to keep LibreOffice preinstalled. (I think that applies to > > Silverblue as well?) > > Fedora Flatpaks are also a security disaster: they are shipped in OCI > format instead of OSTree format, but they aren’t signed by anyone. > I’ve disabled the Fedora remote and recommend that others do the same. > I think the words "security disaster" are painting a too strong picture here. When you install a Fedora Flatpak, the digest of the content being installed is checked against the checksums embedded in the index downloaded from (e.g. https://registry.fedoraproject.org/index/static?label:org.flatpak.ref:exists=1&os=linux&architecture=amd64&tag=latest). These indexes are statically generated from data queried from Bodhi and Koji and downloaded from a static web server directly from Fedora bypassing the CDN. The most obvious way to get malicious content into this index would be to inject it at build time, by adding it upstream, infiltrating the Fedora project, hacking a Fedora contributor, etc. In all of these cases, if we had container signatures, robosignatory would happily sign it when the update was created. Yes, someone could hack the server hosting the index, get write-access to the mount hosting the indexes, or find some specific way to exploit the indexing process. And in those cases, having checked signatures would help. The first two cases would seem to imply a widespread breach of Fedora infrastructure that would likely affect security of builds as well. What would be needed to implement signatures would be roughly: - Implement container signatures in robosignatory/sigul - Implement distribution of signatures (probably easiest if we move registry.fedoraproject.org to quay.io as planned for a while) - Implement checkingo of container signatures in the Flatpak client One thing that helps now is that for a long time there was a lot of uncertainty in where signatures were going in the container world, but at this point, at least Red Hat parts of the container world seems to be solidly behind the approach of https://github.com/sigstore/cosign. (Still a lot of details / moving parts that would have to be researched.) - Owen
_______________________________________________ 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
