`flatpak remote-add --from=https://….flatpakrepo` relies on TLS CAs to bootstrap trust path

Checklist

[X] I agree to follow the Code of Conduct that this project adheres to.
[X] I have searched the issue tracker for a bug that matches the one I want to file, without success.
[X] If this is an issue with a particular app, I have tried filing it in the appropriate issue tracker for the app (e.g. under https://github.com/flathub/) and determined that it is an issue with Flatpak itself.
[X] This issue is not a report of a security vulnerability (see here if you need to report a security issue).

Flatpak version

any

What Linux distribution are you using?

Other (specify below)

Linux distribution version

any

What architecture are you using?

i386

How to reproduce

flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo

Expected Behavior

Strong singing key verification.

Actual Behavior

Weak singing key verification only through TLS.

Additional Information

Issue

The command flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo for adding the Flathub repository has a security concern. That command downloads a Flatpak repository file. That file contains an OpenPGP (gpg) signing key under the GPGKey= keyword, but this key is not authenticated beyond the security provided by TLS.

The command relies on Trust on First Use (TOFU), which is a less secure approach compared to verification of signing keys. In essence, TOFU means trusting the initial connection and the credentials received without additional verification.

When a repository is added using the flatpak remote-add command, the Flatpak repository definition file is downloaded over TLS (Transport Layer Security). While TLS provides basic security, TLS CA system not very secure and has been hacked multiple times.. TLS alone does not provide strong verification of the authenticity of the software’s origin.

It would be more secure to verify the key fingerprinting through the OpenPGP web of trust or other means of key fingerprinting verification.

The reliance on TLS for verification lowers the overall security level. Ideally, software verification should be done through established and strong cryptographic signatures, ensuring that the software comes from a trusted source and has not been tampered with.

To enhance security, users could manually add the Flathub repository configuration. This can be done by placing a configuration snippet directly in the /etc/flatpak/remotes.d directory. A file like /etc/flatpak/remotes.d/flathub.flatpakrepo can be created for this purpose. The content of this file, especially the GPGKey= keyword, should be sourced from a more secure, authenticated method than TLS. This ensures that the repository’s signing key is verified and trusted beyond the initial TLS connection.

In other words, the flatpak remote-add command currently fails against a MitM capable of breaking TLS. This is sad because by comparison other package managers such as Debian's APT survives that (assuming there is no vulnerability in that gpg verification code). Once the user has installed the Linux distribution, the signing key is installed and used. The package manager can use TLS for an additional security layer but is also secure in case TLS is compromised.

Solution 1: Use properly formatted OpenPGP keys in flathub.flatpakrepo.

Add support for properly formatted OpenPGP keys in flathub.flatpakrepo files. At the end:

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQINBFlD2sABEADsiUZUOYBg1UdDaWkEdJYkTSZD68214m8Q1fbrP5AptaUfCl8K
-----END PGP PUBLIC KEY BLOCK-----

Because currently GPGKey= is hard to convert into a format that gpg understands. I tried to extract the key from GPGKey= , add BEGIN and END but that won't work. Error: gpg: invalid radix64 character 2D skipped Probably because the lines are too long.

I tried formatting the lines.

awk '/-----BEGIN PGP PUBLIC KEY BLOCK-----/,/-----END PGP PUBLIC KEY BLOCK-----/ { if (!/-----BEGIN PGP PUBLIC KEY BLOCK-----/ && !/-----END PGP PUBLIC KEY BLOCK-----/) {print | "fold -w 64"} else print }' flathub-key-long.asc > flathub-key.as

Still same error. So that seems complicated and an uphill battle. Even if someone wanted do this is, that currently does not seem possible.

I don't think after downloading flathub.flatpakrepo there is any way to verify the key fingerprint?

Solution 2: Provide a detached gpg signature.

repofile: https://flathub.org/repo/flathub.flatpakrepo
signature: https://flathub.org/repo/flathub.flatpakrepo.asc

Solution 3: Allow specification of the long gpg fingerprint on the command line.

Something like this:

flatpak remote-add --fingerprint 0000000000000000000000000000000000000000 --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo

Then flatpak could use a setting in /etc/flatpak which makes --fingerprint mandatory.

Solution 4: Hardcode the gpg key fingerprint or TLS certificate fingerprint.

At least for Flathub it would be good if the gpg fingerprint and/or TLS certificate fingerprint for flathub.org would be hardcoded so that certificate authorities cannot mess with it.

At least for Flathub it would be good if the gpg fingerprint and/or TLS certificate fingerprint for flathub.org would be hardcoded so that certificate authorities cannot mess with it.

Flatpak-the-program is intentionally not centralized: there is nothing hard-coded in Flatpak-the-program that says Flathub is special (unlike e.g. Snap). It's entirely valid to get all your Flatpak apps from some other remote, like maybe Fedora, and never touch Flathub.

If your OS distribution wants to preconfigure Flathub in a flatpak-remote(5), they are free to do so, and if they do, they can (probably must) pre-seed it with a known-good copy of the signing key at the same time. Whether your distribution does this depends on their own policies, and whether they intend to privilege Flathub over other possible sources of Flatpak apps. As an upstream project, Flatpak-the-program is intentionally staying neutral on the question of where your software comes from, the same way apt/dpkg are neutral on whether you should be using Debian, Ubuntu, Mint, Devuan or something else.

Flatpak-the-program is intentionally not centralized: there is nothing hard-coded in Flatpak-the-program that says Flathub is special (unlike e.g. Snap).

That is vice and very commendable.

solution 4: I therefore revoke my Solution 4 suggestion.

If your OS distribution wants to preconfigure Flathub in a flatpak-remote(5), they are free to do so, and if they do, they can (probably must) pre-seed it with a known-good copy of the signing key at the same time. How can a distribution or anyone verify what the known good key for flathub is?

I guess part of this bug report could be redirected to https://github.com/flathub/flathub

solution 2 (detached gpg signature for flathub.flatpakrepo)

On the other hand,

solution 1 (support properly formatted OpenPGP keys in Flathub repository files)
solution 3 (flatpak remote-add --fingerprint)

are flatpak specific and neutral.

I don't think after downloading flathub.flatpakrepo there is any way to verify the key fingerprint?

It might help you to know that the GPGKey is a straightforward base64 encoding (no line breaks, no header/trailer lines) of a binary export of the signing public key, like this:

GPGKey=$(gpg --export 4184DD4D907A7CAE | base64 -w0)

so you could go in the other direction with something like this:

sed -ne 's/^GPGKey=//p' flathub.flatpakrepo | base64 -w0 -d | gpg --import

(or gpg --list-packets or however you would prefer to inspect it).

.flatpakrepo files are a shortcut, to make it convenient to add a repository in one http-gettable request, and you are under no obligation to use .flatpakrepo files. The lower-level UI to adding remotes is something more like this:

flatpak remote-add --gpg-import=dl-flathub-org.gpg flathub https://dl.flathub.org/repo/

and lets you carry out whatever verification you want to have done on dl-flathub-org.gpg first.

I don't know without looking up the implementation whether you can combine --from=whatever.flatpakrepo with --gpg-import. If you can't, I think that would be a reasonable thing to propose as a pull request if it's something that interests you: presumably you would want --gpg-import to either override and ignore the PGP key specified in the .flatpakrepo file, or verify that every PGP key imported from the .flatpakrepo file was also present in the input to --gpg-import.

However, it's intentional that the setup instructions on flathub.org are using the shortcut form, because they are meant to be as straightforward for new users as possible, and they are made available to you via ... https, with TLS verified against a CA. It would seem like security theatre for flathub.org to be providing longer/more difficult setup instructions that avoid the .flatpakrepo shortcut, because they would have to advertise a particular fingerprint or a whole copy/paste'able GPG key, and if your threat model is that the attacker can MitM dl.flathub.org (on the day that you happen to be setting it up) and get a CA-signed TLS certificate for it, then they can equally well MitM flathub.org and show you a different fingerprint or a different GPG key under their control.

Someone you trust who is not flathub.org could provide you with an independent second source for this information, if they want to, but flathub.org can't do that for you, because they cannot be independent of flathub.org :-)

If flathub.org does want to "seed" that information in a way that lets you confirm it against third-party copies, they would have to do some careful UI design in how it's presented, to avoid scaring off new users by making them think "this Flatpak thing is too hard, I didn't want to do cryptography" and ending up with those same new users getting their software in some less secure way.

Use properly formatted OpenPGP keys in flathub.flatpakrepo

flathub.flatpakrepo is in a specified format reused from elsewhere (the same syntax as .desktop files), and formatting the PGP key in the more conventional multi-line way would make it an invalid instance of that format, so, no, this isn't possible without breaking compatibility (which is something that Flatpak takes seriously).

Provide a detached gpg signature

How would you verify this signature? If it was signed by the repository signing key, you'd be back where you started, trying to get a known-good copy of the repository signing key from an out-of-band source. Or, if it was signed by some other key (like for example mine), you have the same problem for (a) getting a copy of that key, (b) verifying that the owner of that key is actually me, and (c) figuring out why you should trust me to provide you with the right key for Flathub.

Yes, the web of trust is a thing, but the vast majority of the world are not in it and have no basis for basing trust decisions on it.

Allow specification of the long gpg fingerprint on the command line

If you're going to get information from out-of-band, I think that information might as well be the whole public key (we already have --gpg-import) rather than just the fingerprint - the key distribution and trust problems are quite similar either way.

other package managers such as Debian's APT survives [MitM] (assuming there is no vulnerability in that gpg verification code). Once the user has installed the Linux distribution, the signing key is installed and used. The package manager can use TLS for an additional security layer but is also secure in case TLS is compromised.

Flatpak is exactly "the same shape" as apt here: it only relies on https for initial setup, and after initial setup, the signing key from the .flatpakrepo file is used.

If you're running Debian (or Ubuntu, or whatever other distribution), your apt equivalent of downloading the .flatpakrepo file happened when you downloaded your installation media (.iso or similar) from debian.org (or equivalent). Or, if you verified the installation media against a checksum or signature, then your equivalent of downloading the .flatpakrepo file was when you downloaded the checksum, or when you viewed the instructions that told you that there should have been a valid signature from a particular key ID. We have to start the chain of trust from somewhere.

The command relies on Trust on First Use (TOFU)

I would dispute that. TOFU normally refers to the model that's conventionally used with ssh, where the only method of authentication is to assume that the first time you connected, there was no man-in-the-middle, and therefore the public key you were given that first time is the right one. To defeat this, an attacker needs to MitM you the first time you connect.

flatpak remote-add --from=https://….flatpakrepo is relying on TLS CAs (the web PKI) for initial setup, and then relying on the public key provided during initial setup for all subsequent requests. To defeat this, an attacker needs to MitM you the first time you connect, and they need to have defeated the web PKI shortly before that time, to be able to present a validly CA-signed certificate whose private key they control.

Yes, I agree that the web PKI is far from perfect, and there have been mis-issuance incidents; but that's still a higher bar than being able to break TOFU, making attacks more expensive and more detectable.

TLDR:

Dear Flathub maintainers,

please sign the Flathub Repo Signing Key.

Below I will reason why that is useful.

Long:

My my original suggestions are revoked. Reasons:

Solution 1: Use properly formatted OpenPGP keys in flathub.flatpakrepo.

Not needed because commands how to extract the key have been provided.

Solution 2: Provide a detached gpg signature.

Not needed if the signing key can be extracted from flathub.flatpakrepo (already possible) and verified (requested above).

Solution 3: Allow specification of the long gpg fingerprint on the command line.

Not needed because already implemented with flatpak remote-add --gpg-import=.

Solution 4: Hardcode the gpg key fingerprint or TLS certificate fingerprint.

Not technological neutral to make flathub privileged over other flatpak repositories.

Thank you your time, engaging here!

These commands work for me, they helped me to extract the key.

gpg --fingerprint 6E5C05D979C76DAF93C081354184DD4D907A7CAE

pub   rsa4096/0x4184DD4D907A7CAE 2017-06-16 [SC] [expires: 2027-06-14]
      Key fingerprint = 6E5C 05D9 79C7 6DAF 93C0  8135 4184 DD4D 907A 7CAE
uid                   [ unknown] Flathub Repo Signing Key <flathub@flathub.org>
sub   rsa4096/0x562702E9E3ED7EE8 2017-06-16 [S] [expires: 2027-06-14]

flatpak remote-add --gpg-import=dl-flathub-org.gpg flathub https://dl.flathub.org/repo/

Gold.

and lets you carry out whatever verification you want to have done on dl-flathub-org.gpg first.

Excellent. Seems like this implemented. Just not well documented.

However, it's intentional that the setup instructions on flathub.org are using the shortcut form, because they are meant to be as straightforward for new users as possible, and they are made available to you via ... https, with TLS verified against a CA. It would seem like security theatre for flathub.org to be providing longer/more difficult setup instructions that avoid the .flatpakrepo shortcut, because they would have to advertise a particular fingerprint or a whole copy/paste'able GPG key, and if your threat model is that the attacker can MitM dl.flathub.org (on the day that you happen to be setting it up) and get a CA-signed TLS certificate for it, then they can equally well MitM flathub.org and show you a different fingerprint or a different GPG key under their control.

If flathub.org does want to "seed" that information in a way that lets you confirm it against third-party copies, they would have to do some careful UI design in how it's presented, to avoid scaring off new users by making them think "this Flatpak thing is too hard, I didn't want to do cryptography" and ending up with those same new users getting their software in some less secure way.

True. UI design is hard to offer this as a feature while not scaring off users. Here is how I designed it for the Linux distribution(s) I am maintaining and therefore this is how I would suggest to frame it.

Optional: Digital signature verification. [Expand Button]

Digital signatures: A tool enhancing download security. Commonly used across the internet.

Learn more: Curious? Learn more about digital software signatures. [link]

Optional: Digital signatures are optional. If you've never used them before, there might be no need to start now.

No worries: New to digital software signatures? It's okay, no need to worry.

Not a requirement: Not mandatory for using Flathub, but an extra security measure for advanced users.

This seems to work nice. Those who understand this complex threat model can do verification. Everyone else ignoring it without asking about it.

Not sure if you're open to that or if that fits into this ticket.

Someone you trust who is not flathub.org could provide you with an independent second source for this information, if they want to, but flathub.org can't do that for you, because they cannot be independent of flathub.org :-)

Correct.

Provide a detached gpg signature

How would you verify this signature? If it was signed by the repository signing key, you'd be back where you started, trying to get a known-good copy of the repository signing key from an out-of-band source. Or, if it was signed by some other key (like for example mine), you have the same problem for (a) getting a copy of that key, (b) verifying that the owner of that key is actually me, and (c) figuring out why you should trust me to provide you with the right key for Flathub.

If you were to sign the flatpak signing key, that would go a long way.

(a) How would I get your key?

From Debian.

gpg --no-default-keyring --keyring /usr/share/keyrings/debian-keyring.gpg --armor --fingerprint smcv

gpg --no-default-keyring --keyring /usr/share/keyrings/debian-keyring.gpg --armor --export smcv | gpg --import

(b) How do I verify the key is actually yours?

I trust that the maintainers of debian-keyring package and Debian generally keep being honest as they have been for decades until this day.

Good question. That's a topic of interest for you. Intriguing, important and happy to discuss further but might go off-topic.

Well, in your case, I know you are a Debian Maintainer (DM) since 2008-04-18 with full upload rights. [1] Myself being a Debian power user, reading mailing lists, bug reports, changelogs, package metadata, debconf videos, you can be rest assured, it's difficult to not notice your name at some point. :)

I think it is reasonable to trust Debian, which is to say, is to trust DMs. At least there's no way around it. It seems reasonable. I don't have any better solution for the trust issue.

On top if this, you've been a DM and managed not to get kicked (or even seriously accused as far as I know) for ~ 16 years. I even don't know what to suggest what else you could do to gain more trust from random people on the internet from far away.

But one thing is for sure. DMs are much more to be trusted than TLS CAs.

Well, have a long period of being a constructive DM. It seems extremely unlikely to me that you would jeopardize this.

On top of this, I would also kindly suggest that other Flathub maintainers would do the same and sign the Flathub gpg key. That would mitigate the risk of a single compromised maintainer. Different web of trust paths might exist to the other maintainers, useful for other people.

[1] https://nm.debian.org/person/smcv/

Yes, the web of trust is a thing, but the vast majority of the world are not in it and have no basis for basing trust decisions on it.

Unfortunately, true.

However, at least advanced users and distribution maintainers should be able to verify the key through stronger means than TLS.

Allow specification of the long gpg fingerprint on the command line

If you're going to get information from out-of-band, I think that information might as well be the whole public key (we already have --gpg-import) rather than just the fingerprint - the key distribution and trust problems are quite similar either way.

Yes, flatpak remote-add --gpg-import is good enough.

other package managers such as Debian's APT survives [MitM] (assuming there is no vulnerability in that gpg verification code). Once the user has installed the Linux distribution, the signing key is installed and used. The package manager can use TLS for an additional security layer but is also secure in case TLS is compromised.

Flatpak is exactly "the same shape" as apt here: it only relies on https for initial setup, and after initial setup, the signing key from the .flatpakrepo file is used.

If you're running Debian (or Ubuntu, or whatever other distribution), your apt equivalent of downloading the .flatpakrepo file happened when you downloaded your installation media (.iso or similar) from debian.org (or equivalent). Or, if you verified the installation media against a checksum or signature, then your equivalent of downloading the .flatpakrepo file was when you downloaded the checksum, or when you viewed the instructions that told you that there should have been a valid signature from a particular key ID. We have to start the chain of trust from somewhere.

Right, it is approximately similar. But I already went through the steps to initially verify my Debian ISO through the web of trust. Now that I already trust Debian, it would be nice if I could based on that, also trust the Flathub key. That is, without reducing my security level back to TLS CAs.

The command relies on Trust on First Use (TOFU)

I would dispute that. TOFU normally refers to the model that's conventionally used with ssh, where the only method of authentication is to assume that the first time you connected, there was no man-in-the-middle, and therefore the public key you were given that first time is the right one. To defeat this, an attacker needs to MitM you the first time you connect.

flatpak remote-add --from=https://….flatpakrepo is relying on TLS CAs (the web PKI) for initial setup, and then relying on the public key provided during initial setup for all subsequent requests. To defeat this, an attacker needs to MitM you the first time you connect, and they need to have defeated the web PKI shortly before that time, to be able to present a validly CA-signed certificate whose private key they control.

Yes, I agree that the web PKI is far from perfect, and there have been mis-issuance incidents; but that's still a higher bar than being able to break TOFU, making attacks more expensive and more detectable.

True.

flatpak / flatpak