Flatpak bundle

[Eonfge]

This is a large issue, so lets break it down in some parts

What is Flatpak

Flatpak is a framework for distributing desktop applications on Linux. It has been created by developers who have a long history of working on the Linux desktop, and is run as an independent open source project.

Introduction to Flatpak

Why Flatpak

This new packaging format tackles a few issues that are unique to Q4wine and Wine in general

• Users will always be able to use the latest version, no ppa or aur required
• It works the same on all distributions
• The package can be bundled with all required components in one go
• The package is not dependent on the architecture of the host machine

In other words, when Q4wine runs in Flatpak, you can ensure that users have access to:

• The latest wine
• The latest winetricks
• Multilib (32bit)

With Flatpak, your app will be ready for when multilib architectures really do become deprecated. Flatpak will run in it's own container where it is possible to have 32bit libraries, even if the main system doesn't have them.

What is required to do so

Roughly speaking, the following must happen

• Choose a shared library to work from, likely org.kde.Platform because of KDE
• Compile Wine for this package, preferably multiple versions (stable, unstable)
• Compile Winetricks for this package (or is it just a massive script?)
• Compile Q4wine for this package
• Tie things together so that your tool properly works with all other components
• Publish the combined app using Flathub (or other)

Things to keep into account

• Flatpak is sandboxed, you cannot use external wine installations
• Flatpak is scoped, you must define permissionsets that you might need to run

Closing words

This will be quite an undertaking, and. I've dabbled with Flatpak, but I'm certainly not skilled enough to help in a project of this size. Still, it will be the way forward.

More

Github wiki
Flatpak docs

[brezerk]

Sounds nice. I'll take a look.

[gustavolinux]

Has anyone built q4wine on flatpak? I want to test it.

[brezerk]

not yet. I am still looking into the flatpak documentation >_<

[brezerk]

well

I managed to build q4wine with flatpack.

You may wish to try it by your own:

flatpak-builder build-dir pkg/ua.org.brezblock.Q4Wine.json --force-clean
and then
flatpak-builder --run build-dir pkg/ua.org.brezblock.Q4Wine.json q4wine

Couple issues found so far:

• File selction dialogs are not working at all (it doins nothig). Not sure if it is Qt or Flatpack bug;
• Wine processes are not displayed in Process tab. Probably b/c there is no access to host's /proc filesystem;
• Online help buttons are not working; Not sure if it is Qt or Flatpack bug;
• icoutils and fuseiso binaries are not available

[brezerk]

Here is the test manifest https://github.com/brezerk/q4wine/blob/master/pkg/ua.org.brezblock.Q4Wine.json

[Eonfge]

I'll give it a shot within a day or two. Have some other agenda points as well, but I'm really exited about it.

Have you already tried a first build using the Flathub builder bot?

[Eonfge]

Did a quick test but I noticed that at the moment, no Wine is bundled with the Flatpak image. This is an obvious next step, because the model of Flatpak doesn't allow you to include libraries that come from outside of the sandbox domain.

This can be seen when you select a wine installation in your file selectors, it returns:

/run/user/1000/doc/4589be02/wine

This is because of portals. It's a file redirecting system which prevents apps from escaping their sandbox. For ore info, see Sandboxing:
http://docs.flatpak.org/en/latest/sandbox-permissions.html#portals

Information on compiling Wine for Flatpak can be found here:

• https://github.com/winepak/winepak-sdk-images/blob/master/org.winepak.Sdk.yml
• https://github.com/winepak/winepak-sdk-images/blob/master/wine/3.9-staging/org.winepak.Platform.Wine.yml

On a positive note, the Help button did work for me. Not sure what might have caused that.

[brezerk]

Are File selection dialogs working for you too?

[Eonfge]

Yes, the default selector works when I browse for a Wine version

Bit of a big image, but in the top left you see the logging of Q4wine, on the left you see the Q4wine startup screen and on the bottom right you see the file browser. In the background... the code of Nautilus and the installation folder of Q4wine that I pulled locally.

[brezerk]

mkay

it looks like my Flatpack Gentoo setup is a bit broken.

xdg-kde-portal is not working properly or something

[brezerk]

Information on compiling Wine for Flatpak can be found here:

unsee :)

so it looks like Flatpack can't include another image/layer (like Docker for example)?

weird

[Eonfge]

@brezerk I've given it a bit more thought while I was at the gym, and there are a few options:

1. Compile Wine from scratch and include it in the main archive. This seems to be the most preferred way by Flatpak because that makes updating and integrity validation a lot easier.

2. Compile Wine from scratch and include it as a module. This would help in the long run, as every Wine version can be his own module, giving users a lot of flexibility. As of this moment, not many applications use modules, but Files for example has a few: screenshot

3. Don't compile Wine, but load it like an external data source. This is what Steam does for example: Proton is loaded afterwards, and it runs within the same container.

The third option would be arguably the easiest. It's what PlayOnLinux also does for example.
A hybrid of one and two would be most advanced: You compile the Stable and Testing version into the main flatpak, while users can download every old version as a module.

I've recently finished my very own first flatpak app, so perhaps I can help you with packaging Wine. I'll let you know later if I have enough time and skill to contribute.

[Nokia808]

Hi. This is indeed what we need for safe usage of WineHQ on Linux to avoid it's evils like viruses & spywares ......

Please when building flatpak package for FlatHub to put the following in mind: the real credential of WineHQ as flatpak is sandbox feature to make full security from viruses & spywares that can run by WineHQ ...... This is of same significant of providing a universal Linux package, or may be more important.

Build WineHQ as flatpak on FlatHub is not impossible & it is already done as PR for Lutris, see:
flathub/flathub#1060
it is still not merged yet, but it is a matter of time only ....

To me, I prefer suggestion number one by @Eonfge : "Compile Wine from scratch and include it in the main archive. This seems to be the most preferred way by Flatpak because that makes updating and integrity validation a lot easier"

If you provide flatpak package then we can use WineHQ in safe way as following:

1. create new user account:
   sudo useradd -m -d /windows/data -s /bin/bash wineuser
   sudo passwd wineuser
   rebbot
2. disable wineuser from ability to use sudo & su:
   a- sudo already disabled by default on Fedora for any newly created user account which by default out of wheel group
   b- disable any newly added user account from utilizing su by:
   sudo vi /etc/pam.d/su then uncomment the following line:
   #auth required pam_wheel.so use_uid then save & exit by :wq
   reboot
3. make "wineuser" not able to use polkit. On Cinnamon DE by:
   sudo setfacl -m u:wineuser:--- /usr/libexec/polkit-gnome-authentication-agent-1
4. login to "wineuser" account, then install q4wine application from FlatHub as a user using "--user" flag:
   flatpak install --user flathub

Look how it will be secure ! Look how it will be safe for Linux users ! You will really make a great work if you provide flatpak package on FlatHub.

[Eonfge]

Please when building flatpak package for FlatHub to put the following in mind: the real credential of WineHQ as flatpak is sandbox feature to make full security from viruses & spywares that can run by WineHQ ...... This is of same significant of providing a universal Linux package, or may be more important.

Compatibility and security are my main ideas behind Flatpak.

• Compatibility because every user can always have the latest version, without serious concerns about cross-distro library differences.
• Security because of easy sandboxing and limited device and drive access

For Wine, the main risk is likely cryptolockers. Most evil code that targets Windows will not work on Linux, but Cryptolockers are a known risk. Whatever we end up doing with Q4wine, it will be a lot easier to control access. I guess that by default, q4wine will only have read-right access to ~/.wine/ so that should solve 90% of all security risks. For usability, we might consider read access to the rest of ~/ but that's not something I'm to worried about right now.

Build WineHQ as flatpak on FlatHub is not impossible & it is already done as PR for Lutris, see:
flathub/flathub#1060
it is still not merged yet, but it is a matter of time only ....

This is some very valuable knowledge. Thanks for sharing. Q4wine could use large parts of the Lutris code because q4wine shares many ideas. I was already linking at the winepak project, but Lutris will have more in common.

[Nokia808]

@Eonfge
I'm happy that my comment helped you in the way to create flatpak package !

By the way, from my knowledge I know (please correct to me if wrong) that install flatpak with "--user" flag will make package NOT able to touch any thing outside home directory of that user, isn't it ?

[Nokia808]

Hi again. I know now the exact answer for my question in my previous comment, which was "whether flatpak package that installed with "--user" flag can touch any thing outside the home directory of the user account from which it was installed by "--user" flag or not"

The answers here in these 2 links:

1. last comment by TingPing:
   [Question] Can we limit access of flatpak application to certain user account only ? flathub/flathub#1121 (comment)
2. discussion on Fedora community forum:
   https://forums.fedoraforum.org/showthread.php?322265-By-default-does-non-wheel-account-on-Fedora-able-to-touch-ouside-it-s-home-directory

So, it seem that when you finish flatpak package & make it available in FlatHub, then installation it with "--user" flag in a special restricted account (no sudo, no su, no polkit) as I described will be ideal.

However, I suggesting on you to apply your suggestion to make q4wine by default, will only have read-right access to ~/.wine/ so that should solve 90% of all security risks. For usability, we might consider read access to the rest of ~/
& make it optional for user to change it so that it will have read-right access to ~/ as a whole, if user wish for that, a case which not so dangerous if she/he installed flatpak package with "--user" flag from within user account not in wheel group & without su, sudo, nor polkit powers ......

We are waiting for your flatpak package .....

[iavael]

@Nokia808 that's not how it works. "--user" flag controls only the path, where flatpak is installed (your home directory instead of /var/lib/flatpak), but has nothing to do with runtime permissions and isolation. If you run q4wine from user "foobar", then it doesn't matter, if q4wine was installed with "--user" flag or not, it will anyway run as user "foobar".
Also there are flatpak permissions like "access to host filesystem", so that you (or maintainer) can limit program's access to home directory of user "foobar" even if it's running as user "foobar".

The whole point of flatpak is to stop messing around with "unprivilleged users" and run software with any desired level of isolation from host system and user data.
And even if maintainer of flatpak has set the permission to access home directory, you can revoke it with "flatpak override" command any time.

[Nokia808]

@iavael
Dear I'm already recognized what you mean & it is concluded from following replay:
flathub/flathub#1121 (comment)
last comment by TingPing said:
"It runs as your user, so it can do only what your user can do."

I concentrated now on the fact that "--user" flag make flatpak available for ONLY user from within which it was installed with "--user" flag ......

Suppose that I have 5 accounts on my PC:

• Mike (in wheel group)
• John (not in wheel)
• Sera
• Roben
• Stanly (not in wheel & without su, nor sudo, nor polkit powers)

now if I installed Q4Wine from within "Stanly" using "--user" flag, then Q4Wine will be available ONLY for "Stanly" & can not be used by Roben or even Mike. I mean by this the following: if I run Windows .exe file from within "Stanly" then it will be run (by flatpak Q4Wine), but if I try to run (by double click of) .exe file from within "Roben" or "Mike" then .exe file will not run because Q4Wine is not available for any user other than "Stanly" ............. And since "Stanly" has su or sudo or polkit powers then it will be safe even if .exe file was a virus or other thread .........

Yes I was wrong when I was thought that just by install flatpak by --user then it will not be able to touch any thing outside it's user home directory. The correct is:
https://forums.fedoraforum.org/showthread.php?322265-By-default-does-non-wheel-account-on-Fedora-able-to-touch-ouside-it-s-home-directory
"By default a user can read+write to it's home path plus a few other places (for example /tmp). It will have read access to most places (for example, the user will probably want to run applications from /usr which in turn will need to use the libraries in /lib). The user would have neither read nor write to some places such as other users homes or security logs etc."
So, just if we block non-wheel user from use su & sudo & polkit , we will be safe ......

[iavael]

@Nokia808 your assumptions are correct, but only in case if you don't run software in flatpak.
Yes, if software runs as your user, it can do only what your user can do, but that's only the max possible level of privileges, that take place when you use absolutely no isolation, that flatpak provides you.

By default a user can read+write to it's home path

In case of flatpak-ed app, it doesn't by default. Sure, maintaner of package can set filesystem:home permission (as it's done in q4wine flatpak), but you can override it any time.

If you want limit access of q4wine to your personal home directory — set the "--nofilesystem=home --nofilesystem=host" override (if maintaner lifted that default flatpak restriction) and call it a day.
Just read http://docs.flatpak.org/en/latest/sandbox-permissions.html and flatpak-override(1) already and stop reinventing the wheel.

[brezerk]

sigh
is there any documentation available on how to use this Sdk extensions? https://github.com/flatpak/flatpak/wiki/Extensions is not really helpfull.

[brezerk]

mkay. so according to what I see, there is no Compat.i386 extensions avaliable nor for org.freedesktop.Sdk, nor for org.kde.Sdk

[brezerk]

ok. it apparently exists for free desktop:

[ himera ] brezerk@pts/1:110  ~/develop/flatpack $
 09/10/19 00:03:15 EEST > flatpak info --show-extensions org.freedesktop.Platform.Compat.i386
         Ід.: org.freedesktop.Platform.Compat.i386
     Джерело: runtime/org.freedesktop.Platform.Compat.i386/x86_64/18.08
        Арх.: x86_64
       Гілка: 18.08
  Походження: flathub
      Збірка: org.flathub.Stable
Встановлення: system
 Встановлено: 479.6 MB

      Внесок: f44d82a1465c6c399361659bde1aa0095f043d68200a0eddc54112e3dba907b1
Батьківський: d8e071811ed9c5114dfe6de06a738e149c7a4df0a29f0e72a95ffb44838f7b28
        Тема: Export org.freedesktop.Platform.Compat.i386
        Дата: 2019-09-05 15:02:38 +0000

As for KDE Sdk: https://bugs.kde.org/show_bug.cgi?id=411771

[brezerk]

hold on... it looks like you can use inherit-extensions instead

[Maryse47]

Ok, I was misled by your previous sentence about wine not being part of runtime. Anyway I agree that bundling latest stable release + downloading any version from winehq as needed is good solution and it will match how things work in distros. Other flavors like wine-staging can be provided as extension that may be even shared among multiple apps thanks to wine baseapp holding an extension point.

[Nokia808]

@Maryse47
What you said is excellent !

1. last stable Wine will be packaged as flatpak on FlatHub,
2. older version of stable branch will downloaded from WineHQ directly if needed by application,
3. if staging or development branches needed, then packager of application that need them will package the needed version(s) from these branches as flatpak extension(s) ! And all extensions will be flatpak packages !
4. any flatpak for any WineHQ version will be built on base application !

But who will apply this ? The following PR seem not to see light:
flathub/flathub#1830
Admin seem to not accept it - see comment by @barthalion flathub/flathub#1830 (comment)

[Nokia808]

@Eonfge
You said "As for anti-virus and security reasons... Wine is a nightmare. Use a VM to run unsafe Windows code because Wine by default does nothing to shield your user data."

This is exactly exactly what flatpak can manage & why we insist on flatpak. Packager who will package WineHQ (& that of GUI like Q4Wine) should take this in her/his mind considering customizing flatpak sandbox & permissions so that dirty Windows code, will not be able to harm Linux. Currently we have firejail for that. Flatpak can give same level of protection if customizing permissions. But an additional point with flatpak is that we avoid huge increment of size of total download of system upgrade when upgrading our distro because flatpak packages will be excluded from this process.

[brezerk]

By the way, does Q4Wine still maintained or it's development had been stop ?

I do have less time to work on it atm. But it is still supported.

As for flatpak the main bump is: https://bugs.kde.org/show_bug.cgi?id=411771
I simply can't build both q4wine and wine to be bundled into single package.
Well, probably this is not a bump for x86 only package, but not sure if it worth it.

[gasinvein]

@brezerk Well, actually you can build Wine despite not having 32-bit extension for KDE runtime - you can use one from freedesktop runtime. They're mostly ABI compatible, since the KDE runtime itself is built atop freedesktop runtime. But you'll hit problems when they're not consistent in the flathub repo - e.g. if fd.o runtime was already updated, while KDE wasn't yet.

[Maryse47]

yes, kde runtime only adds qt and some kde libraries but you don't need 32bit of those to build wine and q4wine is 64bit app. ABI regressions between kde and freedesktop runtimes are bugs that should be reported upstream.

[brezerk]

@gasinvein ic. afik there was a specific reason to use KDE one. I guess this is b/c XDG desktop integration plugin or something.
Does FD one provides QT libraries as well? It is possible to build flatpack app in a chain using different runtimes (like Docker layers?)

Honestly was looking into flatpak ages ago, so any help / guide is appreciated.

[Maryse47]

@brezerk see my comment above, q4wine is purely 64bit and wine doesn't use qt at all. You use kde runtime 64bit to build q4wine and freedesktop 32bit extension to build wine within the same flatpak app.

[brezerk]

@Maryse47 q4wine -- sure. but wine uses both x86 and x86_64 libraries according to: https://wiki.winehq.org/Building_Wine

64-bit Wine built without 32-bit support will not be able to run ANY 32-bit applications, which most Windows binaries are. Even many 64-bit programs still include 32-bit components!

[gasinvein]

@brezerk Sorry, probably I've failed to word it correctly. My suggestion was to use the KDE runtime for the Q4Wine application together with FD.o 32-bit extension for Wine support. It should work in most cases - but may sometimes break, though.

[Maryse47]

@brezerk by using mix of kde & freedesktop as suggested you get both 64 & 32 libs to build 64bit and 32but wine.

[brezerk]

@gasinvein @Maryse47 ah ic :) Was under impression you can use only single runtime for a resulting package. Is there a good example to take a look into?

[Maryse47]

You can use only single runtime for flatpak app but 32bit freedesktop is an extension that you can plug into any runtime. The runtime will be KDE still.

[gasinvein]

@brezerk Oh wait. Looks like there is no extension point for org.freedesktop.Sdk.Compat.i386 in org.kde.Sdk. Then building Wine as part of the app bundle won't be as easy as I thought.
Still, combining org.kde.Platform with org.freedesktop.Platform.Compat.i386 (at run time) is possible, and should work for externally built Wine.
I guess KDE folks could just add/keep org.freedesktop.Sdk.Compat.i386 extension point. It should be much easier than exporting a proper org.kde.Sdk.Compat.i386.

[Maryse47]

@gasinvein fix for sdk compat landed in kde runtime git repo and will be available when it's rebuild on flathub.

[Nokia808]

It seem that there will be real progression with this issue as fix for sdk compat ( Add support for freedesktop 32bit extensions) is already merged !

Thank you for your efforts ! It seem that finally we will have WineHQ shipped in flatpak format !

@brezerk Just be careful when you will make flatpak to be sure about sandbox it so that virus - if any will not harm being run within a jail like that of firejail ......

[gasinvein]

@Maryse47 Oh, that's nice. I'll try to build Q4Wine with Wine in a single bundle, then, when it lands.

[Nokia808]

@brezerk
@gasinvein

Dear I read the following on this repository:

If you plan to use kdesu, gksu or xdg-su, then you may wish to add the
following lines to /etc/sudoers (using visudo)

#---------- Cut here -------------------------
Cmnd_Alias Q4WINE_COMMS=/sbin/losetup
User_Alias Q4WINE_USERS=%games,%users

Q4WINE_USERS ALL=(ALL) NOPASSWD: Q4WINE_COMMS
#---------- End of Cut -----------------------

This will allow one to run /sbin/losetup, which is used for building the mounted
.isos menues' lists, with out prompting for root password.

Otherwise you will not be able to get the mount menu working.

Does this come in contradiction with flatpak principle ? Flatpak not accept root application. Moreover, does implementing this in flatpak version in any workaround will be on behalf of sandbox security of this type of package ?

Side a way note (I'm not know if related to this point or not): flatpak version should be able to utilize joysticks devices connected to USB port of PC. Also, it should be able to utilize external disk (like external SSD) that connected to USB of PC, because - as you know - new Windows games at these days have huge sizes may reach to 46 GB or more, some thing make many use additional disks like external SSD so that she/he can make WINEPREFIX within external storage devices not within built-in internal disk of laptop .....

[tim77]

@tim77
I saw these links from before. But I will disappoint you by the following:
I'm already - years ago, may be 2 - I'm asked official WineHQ developers to make WineHQ available as flatpak but they refused this in very very clear cut way !! They did not care about this at all.

I understand your salt, but where you asked? Please link? And why you didn't create request also in https://discourse.flathub.org/c/requests/5 then?

If you hope that they ship WineHQ as flatpak, then wish your hands ..... They will never, & for that I did not join your discussion on their form.

I never even hoped that upstream will start shipping WineHQ as flatpak but this formal thing which need to do before 3rd-party maintainers and community can start packaging Wine on Flathub. If you'd read flathub discussion first then you wouldn't have asked what the ultimate goal and what i was hoping for. Maybe your words was inconclusive. You should share with rest of community anyway on Flathub your request and maybe together we could do better. Basically because of that we could have Wine packaged on Flathub for a long time ago since @gasinvein packaged it and we using this build in our own repo for a long time which is proven to work fine.

Since Wine upstream not care and we did all formal things the only one thing is prevent to push reusable Wine build on Flathub - Wine BaseApp which rejected by Flathub admins many times. I personally think Wine BaseApp is MUST and voting for it from the beginning but i haven't any new argument to admins and can't add anything new to this discussion. So in this case the problem is why Wine not still not packaged on Flathub probably Flathub admins then since @gasinvein purpose and goal of Wine BaseApp is package Wine itself on Flathub.

Instead of bundled Wine in q4wine which @gasinvein interesting to help with packaging we can have reusable Wine, Wine branches and it derivatives like Proton. We can get two cracks and Wine Flathub build could reused by q4wine and other launchers and projects which is very good thing and reduce maintenance burden, increase user base of such Wine build, shared bug tracker and quality in general.

Wine BaseApp is still prevent us to achieve this goal and keep in mind that this proposal is still not accepted so you still must build and rebuild every time Wine even if we have success and progress there with q4wine and 32-bit kde runtime. What we can do and improve this situation? I don't know. But at last resort we can try to push Wine reusable build without BaseApp since we can't force FH admins to accept BaseApp proposal, right? Or we can?

[tim77]

Also, it should be able to utilize external disk (like external SSD) that connected to USB of PC, because - as you know - new Windows games at these days have huge sizes may reach to 46 GB or more

For this allowing --filesystem=/run/media and --filesystem=/media would enough.

[Nokia808]

From above discussion it seem that the admins of FlatHuB refused & still refusing idea of base application. In this case why do not ship WineHQ in alternative way like run time to be re-usable ? As long as you asked FlatHub repeatedly for adding base application & they refused repeatedly, it is needed to run in other path like run time ........

[Maryse47]

Fixed kde sdk is on flathub now. Keep in mind that due to flatpak limitation you can't have org.freedesktop.Sdk.Compat.i386 installed while running kde apps unless you use --devil switch.

[tim77]

@Maryse47 See https://invent.kde.org/packaging/flatpak-kde-runtime/-/issues/15

[brezerk]

Sorry guys. Still recovering from flu.

@Nokia808 i don't think it would be an issue. Recent q4wine versions are relay on fuseiso instead of direct mount/umount calls (this are fallback options for systems/distros having no user space logic available). As long as fuseiso will be a part of distribution we should be fine i think.

[gasinvein]

The KDE SDK with fixed compat 32-bit build support is live now.

@brezerk Sadly FUSE can't work inside flatpak without a huge sandbox hole (allowing running commands on host), which probably isn't acceptable for an app that launches proprietary Windows binaries.
Although there are several image writers on Flathub that make use of UDisks2 to gain access to block devices. Do you think it could be possible for Q4Wine to support mounting via UDisks2 (it has dbus api for that)?

[brezerk]

@gasinvein i think so. Create a ticket for me to take a look please. Thanks!

[gasinvein]

@brezerk Done, #184.