Hi all, I’m interested in using Flathub as a way of managing internal software for linux workstations.
I’m wondering about the following options:
Run a private internal instance of Flathub
Create a custom Gnome Software Centre plugin that works with a whitelist
number 1. seems like the most secure, but is there a way to automatically synchronise from upstream for certain applications? What capabilities might I need to contribute to Flathub to make it work?
number 2. this one seems more achievable but it’d be hard to prevent users from just downloading application packages and running them themselves.
If anyone has thoughts or ideas in this area I’d love to hear them.
Make sure your Flatpak repository is setup in your workstations (e.g. if you build these images yourself).
GNOME software should be able to see your repo and present your internal apps, already.
Regarding your questions:
I am not sure there is a tool for sync’ing flatpak repos, but if you manage a limited subset of applications in your repo it shouldn’t be to hard to manage that, (e.g. Flathub manifests are public git repos already)
I think you can disable sources in gnome-software (maybe you can explore that? and only leave Flatpak source?, I haven’t tried this though).
Ok great, thank you. I’ll fire up flat-manager and see how it works. I think configuring the machines to only use internal repos is fine, it seems straightforward.
Also I know it’s very flexible to back everything on to the developer’s own sources for packages but it just seems like we’re relying on every individual application developer’s security process, it’d be better if packages were bundled up and served from our own internal repositories so that (for example) if a developer’s github account is compromised it can’t immediately affect our internal users. Although then we have to bump every version manually.
Not as far as I remember but we do do something vaguely similar in our image builder, mirroring refs to a local cache before pre-installing them in an image. I’ll ask an expert to chime in
Unfortunately, nowadays if the remote has a collection ID set (which flathub does), ostree pull --mirror will do something a bit different than what you want by putting the pulled refs under refs/mirrors/org.flathub.Stable instead of refs/heads. What you need to do is set the collection ID of your mirror to match flathub’s. Like so:
However, note that you won’t be able to mirror flathub’s summary file in that way and you’ll need to regenerate your own summary after pulling with flatpak build-update-repo. Then you have 2 options:
Specify your own GPG key to sign your summary with and make sure that your clients have it in their trusted keyring for your mirrored flathub remote.
Leave the summary unsigned and ensure that clients don’t try to verify the summary. Unfortunately, flatpak only has a single --gpg-verify option that would enable or disable verification for both commits and summary. You’d want to continue to verifying the commits with flathub’s GPG key, though. In that case, you have to use ostree’s config handling manually like ostree config set 'remote "flathub-mirror".gpg-verify-summary' false assuming your clients use a remote name of flathub-mirror.
For the second option, simply running flatpak build-update-repo repo is what you want.
ostree also has support for a mirrorlist which you could maybe configure your clients to add your mirror in, but I’ve never used it.
You don’t actually need flat-manager to just serve an ostree-repo. flat-manager has some nice stuff that flathub uses for receiving builds from workers, but you just need any old HTTP server to provide an ostree repo. I always use nginx, but anything will work. Recently flat-manager gained support for per-commit authentication (see https://github.com/flatpak/flatpak/wiki/TestingPurchases), but it’s still early days for that.
Yet another option is to setup an HTTP reverse proxy with caching to flathub. Effectively be your own CDN endpoint. This is more complex and you have to deal with caching, but it would be a drop in solution. Flathub has a couple frontends between the actual repo server and the real CDN that do this. It’s basically a combination of these 2 things in nginx (with some ansible jinja templating):
With the reverse proxy you don’t have to worry at all about pulling or signing. But you do very much need to deal cached data that might not be synced correctly. The classical issue here is the summary and summary.sig files being out of sync because of caching.
Hi Thank so much for this info, I am trying to set this up to be able to have a local repo from which install applications in a semi-offline environment,
I was able to make it work using flatpack builder and recompiling apps to my repo, but I would like to know if it’s possible to just sync or download precompiled applictions from flathub and then add them to my repo.
while trying to execute this suggested command I get the following error on a fresh centos8 vm
I also tried to create a custom repo, using flatpak-builder then export the build to repo location, the I tried to sign the repo with a gpg key following this Maintaining a flatpak repository – Alexander Larsson
then at the moment of adding the repo to the client with this command
