Verification of flatpaks using GPG

[Martin Sehnoutka]

On 05/06/2019 13:44, Alexander Larsson wrote:
> On Wed, Jun 5, 2019 at 12:20 PM Martin Sehnoutka <msehnout at redhat.com> wrote:
>>
>> Hi,
>>
>> Flatpak uses GPG to verify packages (flatpaks), right? I checked the
>> source code and documentation and I assume the answer is yes, just want
>> to be sure :-)
> 
> Yes, or rather ostree does so on the behalf of flatpak.
> 
>> I have few questions regarding the key storage. Where are the keys
>> stored? Are they somehow verified before each transaction or just
>> trusted since the day they were imported?
> 
> Typically each remote has a key in the repo directory, For example
> /var/lib/flatpak/repo/flathub.trustedkeys.gpg for my system flatpak
> remote. A remote can also trigger adding a new key by adding some
> metadata in the (signed with old key summary file), although when you
> eventually switch over to the new one you'll risk kicking out whoever
> didn't run an update "lately". The initial key is installed when the
> remote is added, typically from the .flatpakrepo file.
> 
> The summary file and each commit is signed, and we verify it while
> pulling from the remote, and abort the download if it fails.

Perfect, thanks for the summary.

> 
>> 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)

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.

> 

-- 
Martin Sehnoutka
Software Engineer
Red Hat