Verification of flatpaks using GPG

[Martin Sehnoutka]

On 07/06/2019 10:43, Alexander Larsson wrote:
> On Thu, Jun 6, 2019 at 8:26 AM Martin Sehnoutka <msehnout at redhat.com> wrote:
>>
>> On 06/06/2019 01:30, Daniel Kasak wrote:
>>> On Wed, Jun 5, 2019 at 10:36 PM Martin Sehnoutka <msehnout at redhat.com>
>>> wrote:
>>>
>>>> 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.
>>>>
>>>
>>> Ah. This partially answers some questions I had about gpg-signing. I'm
>>> using a dyn dns account to host our repo, and I don't host my own email (
>>> any more ). Does that mean there is *no* way for me to produce a gpg-signed
>>> repo ( that clients can install / update without being root )?
>>
>> You can produce a repository with signed content as usual. This
>> extension is about verification of the GPG key itself, not the repository.
>>
>> Does that answer your question?
> 
> Well, it does limit what gpg key you can use to sign it. I mean, say
> you sign it with a gpg key that has your gmail address in it, then
> there is no way you could make it verify that, as you're not in
> control of the google dns zone.
> 
> Of course, if you start a repo from scratch you can always generate a
> key with an email address pointing to some dns you *do* control.
> 

The extension is optional, you don't need to use it. So if you associate 
your signing key with an email address from google, you are just loosing 
the possibility to verify it over DNS, but users can still do it by hand 
as they can nowadays. Nothing is changing in backwards incompatible way.

-- 
Martin Sehnoutka
Software Engineer
Red Hat