call_end

    • chevron_right

      Aryan Kaushik: GNOME in GSoC 2025

      news.movim.eu / PlanetGnome • 25 February • 1 minute

    Hi Everyone!

    Google Summer of Code 2025 is here! Interested in being a part of it? Read on!

    GNOME Foundation has been a part of Google Summer of Code for almost every iteration, and we have applied for this year as well, and are waiting for it's confirmation!

    Our tentative projects list is now available at GNOME GSoC Website

    To make it easier for newcomers, we’ve built resources to help navigate both GSoC and the GNOME ecosystem:

    You can also watch the awesome video on GNOME's impact and history on YouTube - GUADEC 2017 - Jonathan Blandford - The History of GNOME

    From my experience, GNOME has been an incredible community filled with inspiring people. If you're looking to make an impact with one of the largest, oldest and most influential free software communities, I’d highly recommend giving GNOME a try.

    You might just find a second home here while honing your skills alongside some of the best engineers around.

    GNOME was my intro into the larger FOSS community when I became a GSoC 2022 Intern there, and has helped me on countless occasions, and I hope it will be the same for you!

    If you have been a part of GNOME and want to contribute as a mentor, then let us know as well, GNOME can always utilise some great mentors!

    For any questions, feel free to join the chat :D

    Also, you can check out my previous post on the GSoC process for more insights on LinkedIn

    Looking forward to seeing you in GSoC 2025!

    • wifi_tethering open_in_new

      This post is public

      www.aryank.in /posts/2025-02-25-gnome-gsoc-2025/

    • chevron_right

      Hans de Goede: ThinkPad X1 Carbon Gen 12 camera support and other IPU6 camera work

      news.movim.eu / PlanetGnome • 24 February • 1 minute

    I have been working on getting the camera on the ThinkPad X1 Carbon Gen 12 to work under Fedora.

    This requires 3 things:

    1. Some ov08x40 sensor patches, these are available as downstream cherry-picks in Fedora kernels >= 6.12.13
    2. A small pipewire fix to avoid WirePlumber listing a bunch of bogus extra "ipu6" Video Sources, these fixes are available in Fedora's pipewire packages >= 1.2.7-4
    3. I2C and GPIO drivers for the new Lattice USB IO-expander, these drivers are not available in the upstream / mainline kernel yet

    I have also rebased the out of tree IPU6 ISP and proprietary userspace stack in rpmfusion and I have integrated the USBIO drivers into the intel-ipu6-kmod package. So for now getting the cameras to work on the X1 Carbon Gen 12 requires installing the out of tree drivers through rpmfusion. Follow these instructions to enable rpmfusion, you need both the free and nonfree repos.

    Then make sure you have a new enough kernel installed and install the rpmfusion akmod for the USBIO drivers:

    sudo dnf update 'kernel*'
    sudo dnf install akmod-intel-ipu6

    The latest version of the out of tree IPU6 ISP driver can co-exist with the mainline / upstream IPU6 CSI receiver kernel driver. So both the libcamera software ISP FOSS stack and Intel's proprietary stack can co-exist now. If you do not want to use the proprietary stack you can disable it by running 'sudo ipu6-driver-select foss'.

    After installing the kmod package reboot and then in Firefox go to Mozilla's webrtc test page and click on the "Camera" button, you should now get a camera permisson dialog with 2 cameras: "Built in Front Camera" and "Intel MIPI Camera (V4L2)" the "Built in Front Camera" is the FOSS stack and the "Intel MIPI Camera (V4L2)" is the proprietary stack. Note the FOSS stack will show a strongly zoomed in (cropped) image, this is caused by the GUM test-page, in e.g. google-meet this will not be the case.

    I have also been making progress with some of the other open IPU6 issues:




    comment count unavailable comments
    • chevron_right

      Peter Hutterer: libinput and 3-finger dragging

      news.movim.eu / PlanetGnome • 24 February • 1 minute

    Ready in time for libinput 1.28 [1] and after a number of attempts over the years we now finally have 3-finger dragging in libinput. This is a long-requested feature that allows users to drag by using a 3-finger swipe on the touchpad. Instead of the normal swipe gesture you simply get a button down, pointer motion, button up sequence. Without having to tap or physically click and hold a button, so you might be able to see the appeal right there.

    Now, as with any interaction that relies on the mere handful of fingers that are on our average user's hand, we are starting to have usage overlaps. Since the only difference between a swipe gesture and a 3-finger drag is in the intention of the user (and we can't detect that yet, stay tuned), 3-finger swipes are disabled when 3-finger dragging is enabled. Otherwise it does fit in quite nicely with the rest of the features we have though.

    There really isn't much more to say about the new feature except: It's configurable to work on 4-finger drag too so if you mentally substitute all the threes with fours in this article before re-reading it that would save me having to write another blog post. Thanks.

    [1] "soonish" at the time of writing

    • wifi_tethering open_in_new

      This post is public

      who-t.blogspot.com /2025/02/libinput-and-3-finger-dragging.html

    • chevron_right

      Peter Hutterer: GNOME 48 and a changed tap-and-drag drag lock behaviour

      news.movim.eu / PlanetGnome • 24 February • 2 minutes

    This is a heads up as mutter PR!4292 got merged in time for GNOME 48. It (subtly) changes the behaviour of drag lock on touchpads, but (IMO) very much so for the better. Note that this feature is currently not exposed in GNOME Settings so users will have to set it via e.g. the gsettings commandline tool. I don't expect this change to affect many users.

    This is a feature of a feature of a feature, so let's start at the top.

    "Tapping" on touchpads refers to the ability to emulate button presses via short touches ("taps") on the touchpad. When enabled, a single-finger tap corresponds emulates a left mouse button click, a two-finger tap a right button click, etc. Taps are short interactions and to be recognised the finger must be set down and released again within a certain time and not move more than a certain distance. Clicking is useful but it's not everything we do with touchpads.

    "Tap-and-drag" refers to the ability to keep the pointer down so it's possible to drag something while the mouse button is logically down. The sequence required to do this is a tap immediately followed by the finger down (and held down). This will press the left mouse button so that any finger movement results in a drag. Releasing the finger releases the button. This is convenient but especially on large monitors or for users with different-than-whatever-we-guessed-is-average dexterity this can make it hard to drag something to it's final position - a user may run out of touchpad space before the pointer reaches the destination. For those, the tap-and-drag "drag lock" is useful.

    "Drag lock" refers to the ability of keeping the mouse button pressed until "unlocked", even if the finger moves off the touchpads. It's the same sequence as before: tap followed by the finger down and held down. But releasing the finger will not release the mouse button, instead another tap is required to unlock and release the mouse button. The whole sequence thus becomes tap, down, move.... tap with any number of finger releases in between. Sounds (and is) complicated to explain, is quite easy to try and once you're used to it it will feel quite natural.

    The above behaviour is the new behaviour which non-coincidentally also matches the macOS behaviour (if you can find the toggle in the settings, good practice for easter eggs!). The previous behaviour used a timeout instead so the mouse button was released automatically if the finger was up after a certain timeout. This was less predictable and caused issues with users who weren't fast enough. The new "sticky" behaviour resolves this issue and is (alanis morissette-stylue ironically) faster to release (a tap can be performed before the previous timeout would've expired).

    Anyway, TLDR, a feature that very few people use has changed defaults subtly. Bring out the pitchforks!

    As said above, this is currently only accessible via gsettings and the drag-lock behaviour change only takes effect if tapping, tap-and-drag and drag lock are enabled:

      $ gsettings set org.gnome.desktop.peripherals.touchpad tap-to-click true
      $ gsettings set org.gnome.desktop.peripherals.touchpad tap-and-drag true
      $ gsettings set org.gnome.desktop.peripherals.touchpad tap-and-drag-lock true
      
    All features above are actually handled by libinput, this is just about a default change in GNOME.

    • wifi_tethering open_in_new

      This post is public

      who-t.blogspot.com /2025/02/gnome-48-and-changed-tap-and-drag-drag.html

    • chevron_right

      Flathub Blog: Flathub Safety: A Layered Approach from Source to User

      news.movim.eu / PlanetGnome • 21 February • 10 minutes

    With thousands of apps and billions of downloads, Flathub has a responsibility to help ensure the safety of our millions of active users. We take this responsibility very seriously with a layered, in-depth approach including sandboxing, permissions, transparency, policy, human review, automation, reproducibility, auditability, verification, and user interface.

    Apps and updates can be fairly quickly published to Flathub, but behind the scenes each one takes a long journey full of safety nets to get from a developer’s source code to being used on someone’s device. While information about this process is available between various documentation pages and the Flathub source code, I thought it could be helpful to share a comprehensive look at that journey all in one place.

    Flatpak Security & Sandboxing

    Each app on Flathub is distributed as a Flatpak . This app packaging format was specifically designed with security and safety at its core, and has been continuously improved over the past decade. It has received endorsements, development, and wide adoption from organizations such as Bambu Lab, Bitwig, CodeThink, Collabora, Discord, The Document Foundation, elementary, Endless, GDevelop, KiCad, Kodi, GNOME, Intel, KDE, LibreOffice, Mozilla, OBS Studio, Plex, Prusa Research, Purism, Red Hat, System76, Telegram, Valve, and many more.

    Flatpak logo

    From a technical perspective, Flatpak does not require elevated privileges to install apps, isolates apps from one another, and limits app access to the host environment. It makes deep use of existing Linux security technologies such as cgroups, namespaces, bind mounts, and seccomp as well as Bubblewrap for sandboxing.

    Flatpak apps are also built from a declarative manifest, which defines the exact sources and environment to build from to enable auditability and as much reproducibility as possible.

    Due to Flatpak’s sandboxing, apps don’t have permission to access to many aspects of the host OS or user data they might need. To get that access, apps must request it using Portals or static permissions.

    Portals & Static Permissions

    Most permissions can be requested and granted on demand via an API called Portals . These permissions do not need to be given ahead of time, as desktop environments provide the mechanisms to give user consent and control over them e.g. by indicating their use, directly prompting the user before the permission is granted, and allowing revocation.

    Illustration of portal, light

    Portals include APIs for handling auto-start and background activity; access to the camera, clipboard, documents, files, location, screen casting, screenshots, secrets like passwords, trash, and USB devices; setting global shortcuts; inhibiting suspend or shut down; capturing input; monitoring memory, network, or power profiles; sending notifications; printing; setting a wallpaper; and more. In each case, the user’s desktop environment (like GNOME or KDE) manages if and how a user is notified or prompted for permissions—and if the permission is not granted, the app must handle it gracefully.

    Apps must also define any static permissions they need to function. These are clearly defined up front and include access to resources such as the network, Bluetooth, and audio devices. For regular file handling such as opening or saving, apps can use the File Chooser portal. In some cases apps may only make sense with permanent access to specific a folder, in which case a narrowly-scoped static permission (e.g. read-only access to the user’s Music folder) may be used.

    Static permissions are designed to be as narrowly-scoped as possible and are unchanging per release of an app. They are not designed to be modified by an end user except in cases of development, debugging, or reducing permissions . Due to this, Flatpak always prefers apps to use Portals over static permissions whenever possible.

    Shared Runtimes & Modules

    Every app is built against a Flatpak runtime hosted by Flathub. The runtimes provide basic dependencies, are well-maintained by the Linux community, and are organized according to various platforms a developer may target; for example, GNOME, KDE, or a generic FreeDesktop SDK. This means many apps—especially those targeting a platform like GNOME or KDE and using its developer libraries—don’t need to pull in external dependencies for critical components.

    Runtimes are automatically installed with apps that require them, and are updated separately by the user’s OS, app store, or CLI when needed. When a dependency in a runtime is updated, e.g. for a critical security update, it rolls out as an update to all users of apps that use that runtime.

    In some cases there are commonly-used libraries not provided directly by one of the available runtimes. Flathub provides shared modules for these libraries to centralize the maintenance, as well as automated tooling to propose updating these libraries in apps.

    If an app needs to bundle other dependencies, they must be defined in the manifest. We also provide tooling to automatically suggest updates to these dependencies.

    Submission & Human Review

    Once an app is developed, it must be submitted to Flathub for consideration to be hosted and distributed. At this stage, humans from Flathub review the app to ensure it follows the requirements . Of note:

    • Apps must be sandboxed with as narrow permissions as possible while still functioning, including using appropriate runtime permissions instead of broad static permissions when possible.

    • Apps must not be misleading or malicious , which covers impersonating other apps or including outright malicious code or functionality.

    • App IDs must accurately reflect the developer’s domain name or code hosting location; e.g. if an app is submitted that purports to be Lutris, its ID must be obviously associated with that app (in this case, Lutris.net ).

    Each of the documented requirements are checked—and if a reviewer finds something out of place they request changes to the submission, ask for rationale, or reject it completely.

    Automated Testing

    In addition to human review, Flathub also makes use of automated testing for a number of quality and safety checks. For example, our automated tests block unsafe or outright wrong permissions, such as apps requesting access to whole session or system buses or unsafe bus names. Our automated tests also help ensure reproducible builds by disallowing pointing at bare git branches without a specific commit.

    Reproducibility & Auditability

    Once an app has been approved and passes initial tests, it is built using the open source and publicly-available flatpak-builder utility from the approved public manifest, on Flathub’s infrastructure, and without network access. Sources for the app are validated against the documented checksums, and the build fails if they do not match.

    For further auditability, we specify the git commit of the manifest repo used for the build in the Flatpak build subject. The build itself is signed by Flathub’s key, and Flatpak/OSTree verify these signatures when installing and updating apps.

    We mirror the exact sources each app is built against in case the original source goes down or there is some other issue, and anyone can build the Flatpak back from those mirrored sources to reproduce or audit the build. The manifest used to build the app is hosted on Flathub's GitHub org, plus distributed to every user in the app’s sandbox at /app/manifest.json —both of which can be compared, inspected, and used to rebuild the app exactly as it was built by Flathub.

    Verification

    Apps can be verified on Flathub; this process confirms that an app is published by the original developer or an authorized party by proving ownership of the app ID. While all apps are held to the same high standards of safety and review on Flathub, this extra layer helps users confirm that the app they are getting is also provided or authorized by its developer.

    Verified checkmark

    Over half of the apps on Flathub so far are verified, with the number regularly increasing.

    App Store Clients

    Once an app is developed, submitted, tested, approved, built, and distributed, it appears in app store clients like Flathub.org, KDE Discover, GNOME Software, and elementary AppCenter—as well as the Flatpak CLI. While exact implementations vary and the presentation is up to the specific app store client, generally each will show:

    • Static permissions and their impact on safety
    • Open Age Rating Service rating and details
    • If an app uses outdated runtimes
    • Release notes for each release
    • If static permissions increase between releases

    Flathub.org and GNOME Software also display the app’s verified status.

    Updates

    Once an app is accepted onto Flathub, it’s not just the wild west; there are still a number of safety protections built into the flow:

    • Flathub maintains ownership over the manifest repo , while app developers are invited as limited collaborators
    • The manifest repo’s default branch is protected , preventing direct pushes without a pull request
    • The manifest repo’s commit history cannot be rewritten , making it harder to sneak something in
    • Flathub’s automated tests must pass before a PR can be merged and an update can be pushed
    • Static permission changes are held for human review before an update is released to users
    • Critical MetaInfo changes are held for human review , e.g. if an app name, developer name, app summary, or license changes

    Special Cases

    There are a few special cases to some of the points above which I would be remiss not to mention.

    First, Flathub has granted a small handful of trusted partners (including Mozilla and OBS Studio) the ability to directly upload their builds from their own infrastructure. These projects have an entire CI pipeline which validates the state of their app, and they perform QA before tagging the release and pushing it to Flathub. Even for these few cases of direct uploads, we require a public manifest and build pipeline to enable similar reproducibility and auditability as outlined above. We also require the apps to be verified, and still run automated tests such as our linter against them.

    Lastly, some apps (around 6%) use extra-data to instruct Flatpak to download and unpack an existing package (e.g. a Debian package) during installation. This process runs in a tight unprivileged Flatpak sandbox that does not allow host filesystem or network access, and the sandbox cannot be modified by app developers. These are largely proprietary apps that cannot be built on Flathub’s infrastructure, or apps using complex toolchains that require network access during build. This is discouraged since it does not enable the same level of auditability nor multi-architecture support that building from source does. As a result, this is heavily scrutinized during human review and only accepted as a last resort.

    Even with the above, the vast majority of apps are built reproducibly from source on Flathub’s infrastructure—and the handful that aren’t still greatly benefit from the transparency and auditability built into all of the other layers.

    Incident Response

    While we expect to catch the vast majority of safety issues with the above, we are also able to respond to anything that may have slipped through. For example, we have the ability to remove an app from the Flathub remote in case we find that it’s malicious. We can also revert, recall, or block broken or malicious app updates.

    We take security reports and legal issues very seriously; please contact the Flathub admins to report an issue, or chat with us on Matrix .


    In Summary…

    As you can see, Flathub takes safety very seriously. We’ve worked with the greater Linux and FreeDesktop ecosystem for over a decade on efforts such as Flatpak, OSTree, Portals, and even desktop environments and app store clients to help build the best app distribution experience—for both users and app developers—with safety as a core requirement. We believe our in-depth, multi-layered approach to safety has set a high bar that few others have met—and we will continue to raise it.

    Thank you to all of the contributors to Flatpak, Flathub, and all of the technologies our ecosystem depends on for supporting us. Thank you to the developers of thousands of apps for entrusting us with the distribution of your apps to users. Thank you to bbhtt, Jordan, and Sonny for the thorough reviews of this blog post. And as always, thank you to the millions of users trusting Flathub as your source of apps on Linux. ♥

    • wifi_tethering open_in_new

      This post is public

      docs.flathub.org /blog/app-safety-layered-approach-source-to-user

    • chevron_right

      Jordan Petridis: The Fedora Project leader is willfully ignorant about Flathub

      news.movim.eu / PlanetGnome • 19 February • 21 minutes

    Today I woke up to a link of an interview from the current Fedora Project Leader, Matthew Miller. Brodie who conducted the interview mentioned that Miller was the one that reached out to him. The background of this video was the currently ongoing issue regarding OBS, Bottles and the Fedora project, which Niccollo made an excellent video explaining and summarizing the situation. You can also find the article over at thelibrem.news . “Impressive” as this story is, it’s for another time.

    What I want to talk in this post, is the outrageous, smearing and straight up slanderous statements about Flathub that the Fedora Project Leader made during the interview..

    I am not directly involved with the Flathub project (A lot of my friends are), however I am a maintainer of the GNOME Flatpak Runtime, and a contributor the Freedesktop-sdk and ElementaryOS Runtimes. I also maintain applications that get published on Flathub directly. So you can say I am someone invested in the project and that has put a lot of time into it. It was extremely frustrating to hear what would only qualify as reddit-level completely made up arguments with no base in reality coming directly from Matthew Miller.

    Below is a transcript, slightly edited for brevity, of all the times Flathub and Flatpak was mentioned. You can refer to the original video as well as there were many more interested things Miller talked about.

    It starts off with an introduction and some history and around the 10 minute mark, the conversation starts to involve Flathub.

    Miller: [..] long way of saying I think for something like OBS we’re not really providing anything by packaging that. Miller: I think there is an overall place for the Fedora Flatpaks, because Flathub part of the reason its so popular (there’s a double edged sword), (its) because the rules are fairly LAX about what can go into Flathub and the idea is we want to make it as easy for developers to get their things to users but there is not really much of a review

    This is not the main reason why Flathub is popular, its a lot more involved and interesting in practice. I will go into this in a separate post hopefully soon.

    Claiming that Flathub does not have any review process or inclusion policies is straight up wrong and incredibly damaging. It’s the kind of thing we’ve heard ad nauseam from Flathub haters, but never from a person in charge of one of the most popular distributions and that should have really really known better .

    You can find the Requirements in the Flathub documentation if you spend 30 seconds to google for them, along with the submission guidelines for developers. If those documents qualify as a wild west and free for all, I can’t possibly take you seriously.

    I haven’t maintained a linux distribution package myself so I won’t go to comparisons between Flathub and other distros, however you can find people, with red hats even, that do so and talked about it . Of course this is one off examples and social bias from my part. But it proves how laughable of a claim is that things are not reviewed. Additionally the most popular story I hear from developers is how Flathub requirements are often way more strict and sometimes cause announces.

    Screenshot of the post from this link: https://social.vivaldi.net/@sesivany/114030210735848325

    Additionally, Flathub has been the driving force behind fixing the metadata off applications, completely reworking the User Experience and handling off applications permissions and made them prominent to the user.

    Miller: [..] the thing that says verified just says that it’s verified from the developer themselves.

    No, verified does not mean that the developer signed off into it. Let’s take another 30 seconds to look into the Flathub documentation page about exactly this.

    A verified app on Flathub is one whose developer has confirmed their ownership of the app ID […]. This usually also may mean that either the app is maintained directly by the developer or a party authorised or approved by them.

    It still went through the review process and all the rest of requirements and policies apply. The verified program is basically a badge to tell users this is a supported application by the upstream developers, rather than the free for all that exists currently where you may or may not get an application released from years ago depending on how stable your distribution is.

    Sidenote, did you know that 1483/3003 applications on Flathub are verified as of the writing of this post? As opposed to maybe a dozen of them at best in the distributions. You can check for yourself

    Miller: .. and it doesn’t necessarily verify that it was build with good practices, maybe it was built in a coffee shop on some laptop or whatever which could be infected with malware or whatever could happen

    Again if Miller had done the bare minimum effort, he would have come across the Requirements page which describes exactly how an Application in Flathub is built, instead of further spreading made up takes about the infrastructure. I can’t stress enough how damaging it has been through out the years to claim that “Flathub may be potential Malware”. Why it’s malware? Cause I don’t like its vibes and I just assume so..

    I am sure If I did the same about Fedora in a very very public medium with thousand of listeners I would probably end up with a Laywer’s letter from Redhat.

    Now Applications in Flathub are all built without a network access, in Flathub’s build servers, using flatpak-builder and Flatpak Manifests which are a declarative format, which means all the sources required to build the application are known, validated/checksumed, the build is reproducible to the extend possible, you can easily inspect the resulting binaries and the manifest itself used to build the application ends up in /app/manifest.json which you can also inspect with the following command and use it to rebuild the application yourself exactly like how its done in Flathub.

    $ flatpak run --command=cat org.gnome.TextEditor /app/manifest.json
    {
      "id" : "org.gnome.TextEditor",
      "runtime" : "org.gnome.Platform",
      "runtime-version" : "47",
      "runtime-commit" : "d93ca42ee0c4ca3a84836e3ba7d34d8aba062cfaeb7d8488afbf7841c9d2646b",
      "sdk" : "org.gnome.Sdk",
      "sdk-commit" : "3d5777bdd18dfdb8ed171f5a845291b2c504d03443a5d019cad3a41c6c5d3acd",
      "command" : "gnome-text-editor",
      "modules" : [
        {
    ...

    The exception to this, are proprietary applications naturally, and a handful of applications (under an OSI approved license) where Flathub developers helped the upstream projects integrate a direct publish workflow into their Deployment pipelines. I am aware of Firefox and OBS as the main examples, both of which publish in Flathub through their Continues Deployment (CI/CD) pipeline the same way they generate their builds for other platforms they support and the code for how it happens is available on their repos.

    If you have issues trusting Mozilla’s infrastructure and you are worried about, then how are you trusting Firefox in the first place and good luck auditing gecko to make sure it does not start to ship malware. Surely distribution packagers audit every single change that happens from release to release for each package they maintain and can verify no malicious code ever gets merged. The xz backdoor was very recent, and it was identified by pure chance, none of this prevented it.

    Then Miller proceeds to describe the Fedora build infrastructure and afterwards we get into the following:

    Miller: I will give an example of something I installed in Flathub, I was trying to get some nice gui thing that would show me like my system Hardware stats […] one of them ones I picked seemed to do nothing, and turns out what it was actually doing, there was no graphical application it was just a script, it was running that script in the background and that script uploaded my system stats to a server somewhere.

    First of all we don’t really have many details to be able to identify which application it was, I would be very curious to know. Now speculating on my part, the most popular application matching that description it’s Hardware Probe and it absolutely has a GUI, no matter how minimal. It also asks you before uploading.

    Maybe there is a org.upload.MySystem application that I don’t know about and it ended up doing what was in the description, again I would love to know more and update the post if you could recall!

    Miller: Noone is checking for things like that and there’s no necessarily even agreement that that was was bad.

    Second time! Again with the “There is no review and inclusion process in Flathub” narrative. There absolutely is, and these are the kinds of things that get brought up during it.

    Miller: I am not trying to be down on Flathub because I think it is a great resource

    Yes, I can see that, however in your ignorance you were something much worse than “Down”. This is pure slander and defamation, coming from the current “Fedora Project Leader”, the “Technically Voice of Fedora” (direct quote from a couple seconds later). All the statements made above are manufactured and inaccurate. Myths that you’d hear from people that never asked, looked or cared about any of these cause the moment you do you its obvious how laughable all these claims are.

    Miller: And in a lot of ways Flathub is a competing distribution to Fedora’s packaging of all applications.

    Precisely, he is spot on here, and I believe this is what kept Miller willfully ignorant and caused him to happily pick the first anit-flatpak/anti-flathub arguments he came across on reddit and repeat the verbatim without putting any thought into it. I do not believe Miller is malicious on purpose, I do truly believe he means well and does not know better.

    However we can’t ignore the conflict that arises from his current job position as an big influence to why incidents like this happened. Nor the influence and damage this causes when it comes from a person of Matthew Miller’s position.

    Moving on:

    Miller: One of the other things I wanted to talk about Flatpak, is the security and sandboxing around it. Miller: Like I said the stuff in the Flathub are not really reviewed in detail and it can do a lot of things:

    Third time with the no review theme. I was fuming when I first heard this, and I am very very angry about if you can’t tell. Not only is this an incredibly damaging lie as covered above, it gets repeated over and over again.

    With Flatpak basically the developer defines what the permissions are. So there is a sandbox, but the sandbox is what the person who put it there is, and one can imagine that if you were to put malware in there you might make your sandboxing pretty loose.

    Brodie: One of the things you can say is “I want full file system access and then you can do anything”

    No, again it’s stated in the Flathub documentation, permissions are very carefully reviewed and updates get blocked when permissions change until another review has happened.

    Miller: Android and Apple have pretty strong leverage against application developers to make applications work in their sandbox Brodie: the model is the the other way around where the they request permissions and then the user grants them whereas flatpak, they get the permission and then you could reject them later

    This is partially correct, the first part about leverage will talk about in a bit, but here’s a primer on how permissions work in Flatpak and how it compares to the sandboxing technologies in ios and Android.

    In all of them we have a separation between Static and Dynamic permissions. Static are the ones the application always has access to, for example the network, or the ability to send you notifications. These are always there and are mentioned at install time usually. Dynamic permissions are the ones where the application has to ask the user before being able to access a resource. For example opening a file chooser dialog so the user can upload a file, the application the only gets access to the file the user consented or none. Another example example is using the camera on the device and capturing photos/video from it.

    Brodie here gets a bit confused and only mentions static permissions. If I had to guess it would be cause we usually refer to the dynamic permissions system in the Flatpak world as “Portals”.

    Miller: it didn’t used to be that way and and in fact um Android had much weaker sandboxing like you could know read the whole file system from one app and things like that […] they slowly tightened it and then app developers had to adjust Miller: I think with the Linux ecosystem we don’t really have the way to tighten that kind of thing on app developers … Flatpak actually has that kind of functionality […] with portals […] but there’s no not really a strong incentive for developers to do that because, you know well, first of all of course my software is not going to be bad so why should I you know work on Sandboxing it, it’s kind of extra work and I I don’t know I don’t know how to solve that. I would like to get to the utopian world where we have that same security for applications and it would be nice to be able to install things from completely untrusted places and know that they can’t do anything to harm your system and that’s not the case with it right now

    As with any technology and adoption, we don’t get to perfection from day 1. Static permissions are necessary to provide a migration path for existing applications and until you have developed the appropriate and much more complex dynanmic permissions mechanisms that are needed. For example up until ios 18 it wasn’t possible to give applications access to a subset of your contacts list. Think of it like having to give access your entire filesystem instead of the specific files you want. Similarly partial-only access to your photos library arrived couple years ago in IOS and Android.

    In an ideal world all permissions are dynamic, but this takes time and resources and adaptation for the needs of applications and the platform as development progresses.

    Now about the leverage part.

    I do agree that “the Linux ecosystem” as a whole does not have any leverage on applications developers. This is cause Miller is looking at the wrong place for it. There is no Linux ecosystem but rather Platforms developers target.

    GNOME and KDE, as they distribute all their applications on Flathub absolutely have leverage. Similarly Flathub itself has leverage by changing the publishing requirements and inclusion guidelines. Which I kept being told they don’t exist.. Every other application that wants to publish also has to adhere by the rules on Flathub. ElementaryOS and their Appcenter has leverage on developers. Cannonical does have the same pull as well with the Snapstore. Fedora on the other hand doesn’t have any leverage cause the Fedora Flatpak repository is irrelevant, broken and nobody wants to use it .

    [..] The xz backdoor gets brought up when discussing dependencies and how software gets composed together.

    Miller: we try to keep all of those things up to date and make sure everything is patched across the dist even when it’s even when it’s difficult. I think that really is one of the best ways to keep your system secure and because the sandboxing isn’t very strong that can really be a problem, you know like the XZ thing that happened before. If XZ is just one place it’s not that hard of an update but if you’ve got a 100 Flatpaks from different places […] and no consistency to it it’s pretty hard to manage that

    I am not going to get in depth about this problem domain and the arguments over it. In fact I have been writing another blogpost for a while. I hope to publish shortly. Till then I can not recommend high enough Emmanuelle’s and Lennart’s blogposts, as well as one of the very early posts from Alex when Flatpak was in early design phase on the shortcomings of the current distribution model.

    Now about bundled dependencies. The concept of Runtimes has served us well so far and we have been doing a pretty decent job providing most of the things applications need but would not want to bundle themselves. This makes the Runtimes a single place for most of the high profile dependencies (curl, openssl, webkitgtk and so on) that you’d frequently update for security vulnerabilities and once its done they roll out to everyone without needing to do anything manual to update the applications or even rebuilt them.

    Applications only bunlde their direct dependencies afterwards and as mentioned above, the flatpak manifest which includes the exact definition of all of them, are available to anyone and there’s tooling in place that can scan them and hopefully in the future alert us.

    If the Docker/OCI model where you end bundling the entire toolchain, runtime and now you have to maintain it and keep up with updates and rebuild your containers is good enough for all those enterprise distributions, then the Flatpak model which is much more efficient, streamlined and thought out and much much much less maintenance intensive, it is probably fine.

    Miller: part of the idea of having a distro was to keep all those things consistent so that it’s easy for easier or everyone including the developers

    As mentioned above, nothing that fundamentally differs from the leverage that Flathub and the Platform Developers have.

    Brodie: took us 20 minutes to get to an explanation [..] but the tldr Fedora Flatpak is basically it is built off of the Fedora RPM build system and because that it is more well tested and sort of intended, even if not entirely for the Enterprise, designed in a way as if an Enterprise user was going to use it the idea is this is more well tested and more secure in a lot of cases not every case. Miller: Yea that’s basically it

    This is a question/conclusion that Brodie reaches with after the previous statements and by far the most enraging thing in this interview. This is also an excellent example of the damage Matthew Miller caused today and if I was a Flathub developer I would stop on nothing sort of a public apology from the Fedora project itself. Hell I want this just being an application developer that publishes on it. The interview has been basically shitting on both the Developers of Flathub and the people that choose to publish in it. And if that’s not enough there should be an apology just out of decency. Dear god..

    Brodie: how should Fedora handle upstreams that don’t want to be packaged like like the OBS case here where they did not want there to be a package in Fedora Flatpak or another example is obviously bottles which has made a lot of noise about the packaging

    Lastly I want to touch on this closing question in light of recent events.

    Miller: I think we probably shouldn’t do it. We should respect people’s wishes there. At least when it is a open source project working in good faith there. There maybe some other cases where the software, say theoretically there’s somebody who has commercial interests in some thing and they only want to release it from their thing even though it’s open source. We might want to actually like, well it’s open source we can provide things, we in that case we might end up you having a different name or something but yeah I can imagine situations where it makes sense to have it packaged in Fedora still but in general especially and when it’s a you know friendly successful open source project we should be friendly yeah. The name thing is something people forget history like that’s happened before with Mozilla with Firefox and Debian.

    This is an excellent idea! But it get’s better:

    Miller: so I understand why they strict about that but it was kind of frustrating um you know we in Fedora have basically the same rules if you want to take Fedora Linux and do something out of it, make your own thing out of it, put your own software on whatever, you can do that but we ask you not to call it Fedora if it’s a fedora remix brand you can use in some cases otherwise pick your own name it’s all open source but you know the name is ours. yeah and I the Upstream as well it make totally makes sense. Brodie: yeah no the name the name is completely understandable especially if you do have a trademark to already even if you don’t like it’s it’s common courtesy to not name the thing the exact same thing Miller: yeah I mean and depending on the legalities like you don’t necessarily have to register a trademark to have the trademark kind of protections under things so hopefully lawyers you can stay out of the whole thing because that always makes the situations a lot more complicated and we can just get along talking like human beings who care about making good software and getting it to users.

    And I completely agree with all of these, all of it. But let’s break it down a bit cause no matter how nice the words and intentions it hasn’t been working out this way with the Fedora community so far.

    First, Miller agrees the Fedora project should be respecting of application developer’s wishes to not have their application distributed by fedora but rather it be a renamed version if Fedora wishes to keep distributing it.

    However every single time a developer has asked for this, they have been ridiculed, laughed at and straight up bullied by Fedora packagers and the rest of the Fedora community. It has been a similar response from other distribution projects and companies as well, its not just Fedora. You can look at Bottle’s story for the most recent example. It very nice to hear Miller’s intentions but means nothing in practice.

    Then Miller proceeds to assure us why he understand that naming and branding is such a big deal to those projects (unlike the rest of the Fedora community again). He further informs us how Fedora has the exact same policies and asks from people that want to fork Fedora. Which makes the treatment that every single application developer has received when asking about the same exact thing ever more outrageous.

    What I didn’t know is that in certain cases you don’t even need to have a trademark yet to be covered by some of the protections, depending on jurisdiction and all.

    And last we come into lawyers. Neither Fedora nor application developers would want it to ever come to this, and it was stated multiple times by Bottles developers that they don’t want to have to file for a trademark so they can be taken seriously. Similarly OBS developers said how resorting to legal action would be the last thing they would want to do and would rather have the issue resolved before that. But it took until OBS, a project of a high enough profile, with the resources required to acquire a trademark and to threaten legal action until the Fedora Leadership cared to treat application developers like human beings and get the Fedora packagers and community members to comply. (Something which stated multiple times they simply couldn’t do).

    I hate all of this. Fedora and all the other distributions need to do better. They all claim to care about their users but happily keep shipping broken and miss configured software to them over the upstream version, just cause it’s what aligns with their current interests. In this case is the promotion of Fedora tooling and Fedora Flatpaks over the application in Flathub they have no control over. In previous incidents it was about branding applications like the rest of the system even though it was making them unusable. And I can find you and list you with a bunch of examples from other distributions just as easily.

    They don’t care about their users, they care about their bottom line first and foremost. Any civil attempts at fixing issues get ignored and laughed at, up until there is a threat of a legal action or a big enough PR damage, drama and shitshow that they can’t ignore it anymore and have to backtrack on them.

    This is my two angry cents. Overall I am not exactly sure how Matthew Miller managed in a rushed and desperate attempt at damage control for the OBS drama, to not only to make it worse, but to piss off the entire Flathub community at the same time. But what’s done is done, let’s see see what we can do to address the issues that have festered and persisted for years now.

    • wifi_tethering open_in_new

      This post is public

      blogs.gnome.org /alatiera/2025/02/19/the-fedora-project-leader-is-willfully-ignorant-about-flathub/

    • chevron_right

      Sam Thursfield: Status update, 19/02/2025

      news.movim.eu / PlanetGnome • 19 February • 3 minutes

    Happily I have survived the intense storms of January 2025, and the biting February temperatures, and I’m here with another status update post.

    I made it to FOSDEM 2025 , which was its usual self, a unique gathering of people who care about making ethical software, sharing cool technology, and eating delicious waffles. In the end, Jack Dorsey didn’t do a talk (see last month’s post for why I don’t think he’d have fit in very well ); the FOSDEM organisers did meet the main protest organiser and had what seems to be a useful discussion on what happened.

    Upstream QA

    I did do a talk, two in fact, one titled “How to push your testin g upstream”, which you can watch on the FOSDEM website (or you can just read the slides — I’ll wait). I got some good feedback, but it didn’t spark many conversations, and I don’t get the impression that my dream will become a reality any time in the near future. I’ll keep chipping away at this interesting problem in the occasional moments of downtime that I can dedicate to it.

    If you also think this is an interesting problem, then please take a look at the talk slides and tell me what you think. If this project is going to move beyond a prototype then it will require several people pushing.

    Two people offered help providing infrastructure where GNOME can run builds and testsuite, which is much appreciated. I had hoped this would mean some dedicated machines for QA testing; however, GNOME’s Equinix-sponsored ARM build farm is disappearing (for the same reason as Freedesktop.org ), so we now need new sponsorship ,to maintain support for ARM devices.

    I still consider the openQA infrastructure “beta quality”; and it’ll remain that way until at least 3 people are committed to ongoing maintenance of the infrastructure. I’m still the only person doing that right now.

    Currently all openQA testing in GNOME is broken, apparently because the Gitlab runners are too overloaded to run tests .

    The GNOME booth at FOSDEM

    Huge round of applause to Maria and Carlos for making sure there was a GNOME booth this year. I spent some time helping out, and it seemed we had a very small pool of volunteers. Shout out as well to Pablo and to camelCaseNick and anyone else who I didn’t see.

    The booth is an interesting place as it poses questions such as: Is GNOME interesting?

    Why is GNOME interesting?

    Besides selling hats and T-shirts, we had a laptop running GNOME OS courtesy of Abderrahim, and a phone running postmarketOS + GNOME thanks to Pablo. Many people were drawn straight to the phone.

    It suggests to me that GNOME on mobile is very interesting at the moment, which makes sense as it’s something new and shiny and not yet working very well; while GNOME on the desktop is less interesting, which also makes sense as it’s solid and useful and is designed to “get out of the way”.

    I gave another talk entitled “Automated testing for mobile images using GNOME” ( link ) based on Adrien’s investigation into mobile testing . I showed this slide, with the main open source mobile platforms that I’m aware of:

    I asked how many people are using a “G” based phone and four or five folk in the audience raised their hands. More folk than I expected!

    GNOME is a project that depends on volunteer effort, so we need to be conscious of what’s interesting. People only have so much energy to spend on things we don’t find interesting. Credit goes to everyone who has worked on making the platform better for mobile use cases!

    A phone running GNOME is cool but there’s only so much you can do on a device with no media and no apps installed. To make booth demos more interesting in future I would propose that we curate some media that can be preinstalled on a device. Please let me know if you have stuff to share!

    What is GNOME?

    This is another question that the booth raises. Are we building an operating system? The new gnome.org website begins: “An independent computing platform for everyone” which seems a nice way to explain it. Lets see how it goes in practice next time I’m trying to tell someone what they’re looking at.

    • chevron_right

      Michael Meeks: 2025-02-19 Wednesday

      news.movim.eu / PlanetGnome • 19 February

    • Sync with Dave on comic stories. Partner call.
    • Published the next strip: looking at donations
    • Lunch with Julia.
    • wifi_tethering open_in_new

      This post is public

      meeksfamily.uk /~michael/blog/2025-02-19.html

    • chevron_right

      Michael Meeks: 2025-02-18 Tuesday

      news.movim.eu / PlanetGnome • 18 February

    • Planning call - managed to fit it inside an hour this week by some radical update-it-and-read-through-it-first-ness.
    • Mail chew, lunch, sync with Karen, slides; monthly management meeting. Partner call in the evening. Dinner, E-mail bits, watched House with J.
    • wifi_tethering open_in_new

      This post is public

      meeksfamily.uk /~michael/blog/2025-02-18.html