Support for runtime repo references in flatpakrefs

Jorge GarcĂ­a jgarciao at gmail.com
Sat Dec 3 00:07:08 UTC 2016


Hi,

I think this is a great addition that will make much easier the
installation of flatpak apps. Please, take a look at this issue [1] for
more ideas to make it even simpler.

Seen that you are improving the flatpakref files I have written some
ideas/proposals that maybe could be useful too. You will find them below.

Thanks & best regards,
Jorge



* Consider adding a FlatpakRefSchema or FlatpakRefVersion field

  As the format of flatpakref files can be changed/improved in the future,
this field can help parse them properly


* Consider using the same extension for .flatpakref and .flatpakrepo files

   gedit.flatpakref is a reference to the gedit application in a repository

   gnome-repository.flatpakref could be a reference to the gnome repository
=> Doesn't need to be named gnome.flatpakrepo (the flatpak program can read
the contents and parse them accordingly)


* Related to the new field RuntimeRepo, maybe you could add a
RuntimeRepoIntegrity with the sha256 of the external file (or something a
little bit more elaborated like browsers subresource-integrity [2]


* Consider adding a new field with the size of the app and required
runtimes:

  Currently a user can't now beforehand how many megabytes will be
downloaded when installing an app and its required runtimes. Is during the
downloading process when some information is shown.

 What if the disk is almost full and the app and runtimes don't fit?
flatpak should be able to warn the user before even beginning the
downloading process.


* Consider adding a new field with the arches (i386, x86_64, ...) available

  Currently flatpakref don't have any field with the info of the
architectures this app is available in the repo. Is when the remote is
added and queried when this info can be obtained. Maybe having this info
beforehand could help flatpak/gnome software inform the user if the app can
be installed.


* Consider adding a entry with the xdg_desktop_portal required to run the
app

  It could be useful to know in the flatpakref file if the app requires and
specific version of xdg_desktop_portal_XXX installed to run properly. See
[3]


* Mirrors

  Currently flatpakref files only have a url field. It could be useful to
have a list of alternative mirrors


* Repo requires authentication

  It could be useful to know if the repo requires some kind of user
authentication (basic, oauth, ...) for downloading the apps/runtimes. THis
could be used for private enterprise repos or for app purchases in a
Flatpak App Store


* Consider adding a entry about the required permissions that the app will
need

  Users might want to know it the app requires to use the camera/whatever
before installing it


* Consider adding an entry with the appdata file encoded in base64

  gedit.flatpakref file have name, comment, description and homepage fields
but an entry with the file  org.gnome.gedit.appdata.xml encoded in base64
could be useful to have extra info like multilingual descriptions



[1] "Allow installing bundles without specifying --bundle"
https://github.com/flatpak/flatpak/issues/415

[2] https://hacks.mozilla.org/2015/09/subresource-integrity-in-firefox-43/

[3] "Supporting different xdg-desktop-portal versions in apps"
https://github.com/flatpak/xdg-desktop-portal/issues/58

On Fri, Dec 2, 2016 at 4:52 PM, Alexander Larsson <alexl at redhat.com> wrote:

> I just added support for the key RuntimeRepo in flatpak refs.
> For an example, see: https://sdk.gnome.org/gedit.flatpakref
>
> What this means is that a flatpakref file can contain a reference to a
> flatpakrepo file, and when it is installed we download the referenced
> file and look for it locally. If no remote with the same uri is
> configured (in the system dir if you're doing a system install or in
> the system *or* home dir if you're doing a user install) then we ask
> the user if he wants to add this remote, and this way when the app is
> later installed we automatically find the runtime it relies on.
>
> I've avoided this for a while because this is security sensitive. If an
> app can add a remote that is used for dependency resolution then that
> can lead to runtimes from that remote being used by some other
> application, which is not great.
>
> However, in practice people *do* need to configure a runtime remote if
> they actually want to run your app, so the alternative is to have a
> bunch of commands listed on the webpage to install it, which has the
> same kind of security issues. So, we might as well do it automatically.
>
> The important thing here is that there is a level of trust in the
> *names* we give for remotes, as these are what you specify as the
> source when installing stuff, and which are shown when you are asked if
> you want to install a runtime dependency. So, the "do you want to add
> this" need to generate a new nice remote name (its based on the
> flatpakrepo basename) and it need to display it, in addition to the
> repo URI when asking if you want to add it.
>
> We should probably add corresponding support to gnome-software.
>
>
> --
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> =-=-=-=-=-=-=-=
>  Alexander Larsson                                            Red Hat, Inc
>        alexl at redhat.com            alexander.larsson at gmail.com
> He's an ungodly Jewish photographer on the wrong side of the law. She's a
> supernatural African-American mechanic with a birthmark shaped like
> Liberty's torch. They fight crime!
> _______________________________________________
> xdg-app mailing list
> xdg-app at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/xdg-app
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/flatpak/attachments/20161203/c6ebadee/attachment.html>


More information about the xdg-app mailing list