Verification of flatpaks using GPG

[Martin Sehnoutka]

On 05/06/2019 14:21, Alexander Larsson wrote:
> On Wed, Jun 5, 2019 at 1:59 PM Martin Sehnoutka <msehnout at redhat.com> wrote:
>>>
>>>> I wrote an extension for dnf (the package manager for Fedora) which can
>>>> automatically verify the key during the import phase and also check
>>>> already imported keys from RPM database before each transaction. I
>>>> wonder if the same approach would be applicable to flatpak or it works
>>>> differently.
>>>
>>> Verify in what sense? You mean for old keys?
>>
>> During the first usage it verifies that the key is indeed the one from
>> the author. e.g. for Fedora package signing keys it will check that the
>> key is the one listed here:
>> https://getfedora.org/en/security/
>> (it will do that by other means than checking the website, but the idea
>> is the same)
> 
> So, given a flatpakrepo file with some arbitrary gpg key. How would it
> know what that the author created that key? Keyserver? Can't anyone
> add whatever they want to a keyserver? Chain of trust? Who defines the
> trust roots?

The key is stored in a DNS server and it uses DNSSEC to verify the key. 
So the chain of trust starts with the root zone signing key which is 
installed with the operating system. So as far as you trust the OS 
installation it should be fine :).

It uses this algorithm:
https://tools.ietf.org/html/rfc7929#section-3
to map the email address associated with the GPG key into a domain.

So the author of the flatpakrepo file must be in charge of the DNS 
server responsible for the mailserver domain. e.g. for Fedora signing 
keys this key:
fedora-29 at fedoraproject.org
maps to this domain:
557d8ff0f0f4c6c9fc7140670cc85400dcee5aeb1ac2412e90f41e45._openpgpkey.fedoraproject.org

and you can get the key like this:
$ dig <the-domain-from-above> OPENPGPKEY

Of course it could be a problem for an individual who uses email from 
Gmail or similar server.

I hope this answers the questions above.

> 
>> This check is currently left to users but as far as my investigation
>> shows most of them just skip the question with 'yes'.
>>
>> And the second use case is checking that the key hasn't been revoked.
>> Again in case of Fedora/RPM repositories there is no automatic way to
>> revoke key that has leaked. The author of the affected repository would
>> have to inform users to issue rpm -e gpg-pubkey-*** to remove the old
>> key. The extension can detect the revocation and perform it automatically.
> 
> We currently have ways to install new gpg keys via the remote itself,
> but not a way to revoke old ones. We should probably add that.
> 
> Anyway, most of this work would have to happen in ostree, and it
> certainly makes a lot of sense to do so.
> 
> 

-- 
Martin Sehnoutka
Software Engineer
Red Hat