search

brezerk / q4wine

Q4Wine is a Qt GUI for W.I.N.E. It will help you manage wine prefixes and installed applications.
http://q4wine.brezblock.org.ua/
GNU General Public License v3.0
207 stars 40 forks source link

Flatpak bundle #147

Open Eonfge opened 5 years ago

Eonfge commented 5 years ago

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

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

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

Things to keep into account

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 commented 5 years ago

Sounds nice. I'll take a look.

gustavolinux commented 5 years ago

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

brezerk commented 5 years ago

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

brezerk commented 5 years ago

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:

brezerk commented 5 years ago

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

Eonfge commented 5 years ago

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 commented 5 years ago

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:

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

brezerk commented 5 years ago

Are File selection dialogs working for you too?

Eonfge commented 5 years ago

Yes, the default selector works when I browse for a Wine version Screenshot from 2019-08-20 18-40-43

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 commented 5 years ago

mkay

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

xdg-kde-portal is not working properly or something

brezerk commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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: https://github.com/flathub/flathub/pull/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 commented 5 years ago

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.

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 commented 5 years ago

@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 commented 5 years ago

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: https://github.com/flathub/flathub/issues/1121#issuecomment-526272703 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 commented 5 years ago

@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 commented 5 years ago

@iavael Dear I'm already recognized what you mean & it is concluded from following replay: https://github.com/flathub/flathub/issues/1121#issuecomment-526272703 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:

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 commented 5 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

brezerk commented 4 years ago

mkay. there is some progress on this: https://github.com/brezerk/q4wine/commit/304f56dfb8f4409a8457b4a5cf487e2fb42663aa feel free to play around

Erick555 commented 4 years ago

I recommend to take a look at manifests of following apps which handle multlib environments in flatpak: https://github.com/flathub/org.phoenicis.playonlinux https://github.com/flathub/net.lutris.Lutris https://github.com/flathub/com.valvesoftware.Steam

gasinvein commented 4 years ago

Hey there. I've made a manifest for building Q4Wine flatpak in the past. It's able to produce a fully-working build, but is slightly outdated now. You can reuse it (partially or in whole) if you want.

brezerk commented 4 years ago

@gasinvein wow, nice job. thank you!

Nokia808 commented 4 years ago

@brezerk @Eonfge @iavael Hi all ! I would like to bring your attention to the fact that, finally, PR of Wine as a runner for Lutris had been merged ! A repository had been created - see: https://github.com/flathub/net.lutris.Lutris.Runner.Wine

I wish this will help you in adding q4wine to FlatHub as a flatpak package.

Nokia808 commented 4 years ago

@brezerk @Eonfge @iavael Hi. Any new progression in this topic or it seem that we are far away from see Q4Wine as flatpak available in FlatHub ?

gasinvein commented 4 years ago

@Nokia808 Building Q4Wine as a flatpak is easy, but handling Wine isn't. It poses several questions:

Nokia808 commented 4 years ago

@gasinvein Hi. Before giving my answer, I would to point that my answer bellow taking the benefit of users (not benefit of myself because in fact I'm using only development branch):

My answer is: IDEALLY it will be better to support Wine as extensions for the Q4Wine. You should build flatpak for Q4Wine + 2 flatpaks extensions: one as flatpak package for development branch & 2nd as flatpak package for stable branch.

However, if the above suggestion is difficult, then it will be better to bundle Wine with Q4Wine as a single united flatpak package. You ask me now which branch: I see for the usefulness of most users is stable branch because most of users not like to be testers. They like a stable application working with minimum bugs. Also, Wine since version 5 become so efficient that no need for urgent new features, so that users can wait for beginning of new year to receive the new stable branch of Wine with it's new features ..... Also, this is much easier for packager & maintainers ....... This is my opinion.

Nokia808 commented 3 years ago

@gasinvein @Eonfge

I see, now, that the staging branch of WineHQ is what should be used as flatpak on FlatHub ! It takes mid place between development & stable branches & it is what Fedora Linux packaged (as .rpm).

But why @gasinvein used the term "extension" to describe the supposed future flatpak package of WineHQ on FlatHub ? Do "rune time" is better than extension ? Extension - correct to me if I'm wrong - mean some thing ADDITIONAL to be added to the application so as to increase scope of already existing functionality of it. But in the case of Q4Wine it has no functionality without WineHQ ! So, I see that WineHQ should be bundled as a "run time" for Q4Wine .......

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

tim77 commented 3 years ago

@Nokia808 for more general questions about Wine and Flatpak please read first:

and join to discussing.

gasinvein commented 3 years ago

@Nokia808 A baseapp seems more appropriate than a full-blown runtime. Though, in both cases an app built on top of it can use only one Wine flavor. On the other hand, an app can have as many extensions as needed. That said, I see a baseapp as the most straightforward way to flatpak Wine.

Eonfge commented 3 years ago

As for Q4Wine's development, I can't comment. But for Flatpak based wine containers, I can recommend Bottles: https://flathub.org/apps/details/com.usebottles.bottles

It's actively maintained and it shows a lot of promise. Still a few serious roadblocks, but progress is steady.

Nokia808 commented 3 years ago

@Eonfge Dear I disagree with you about bottle due to the following causes: 1) bottle is designed to download & use WineHQ from special repositories AFTER it was installed. That is to say, it is designated by default to NOT utilized neither distro specific .rpm/.deb package from package manager of that distro, but - instead - to download an outer WineHQ package. For that reason it refuse to utilize a flatpak version of WineHQ whether in form of run time or base application or an extension ! During his PR on FlatHub, developer of bottle (who are same person maintain flatpak version on FlatHub) asked to ship at least one version of WineHQ as flatpak but he refused this suggestion. 2) the current bottle has no any control over Windows application after it was installed in the term of prevent it from run from outside flatpak sandbox. 3) the developer of bottle will add more & more penetrating features that I do not know how it will be compatible with sandbox requests of virus safety ! - see as example: https://github.com/bottlesdevs/Bottles/issues/147 may be I'm understood it wrongly ..... 4) developer of bottle refuse to add specific patches for it's flatpak version, but it like it to be same as non-flatpak versions.

I'm very wandering that bottle will be suitable alternative for Q4Wine. Yes, it's shape & visuals of it's GUI are very nice but I see it not fit the security & anti-virus safety that needed from flatpak.

Nokia808 commented 3 years ago

@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. 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.

Eonfge commented 3 years ago

@Nokia808

by default to NOT utilized neither distro specific .rpm/.deb package from package manager of that distro

That's completely in line with Flatpak. With Flatpak, all applications run using a bare base layer (runtime) and all use specific libraries should be bundled. Wine is very specific and very volatile, so it's not a part of the runtime. The choice to not include the latest stable is a shame, but also understandable as there are many possible versions and configurations. No Flatpak version of Q4Wine will ever be able to use a previously installed version of Wine so the solution that Bottles has here is also something that Q4Wine should provide.

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. In that regards, Bottles is slightly better because it at least blocks access to folders like ~/.ssh/ which Wine doesn't shield by default.

Take the wine browser and see for yourself, go to Z: and see your own home directory. Bottles is actually slightly better in security because it doesn't expose your dot-files in ~/ . But still, never use Wine for security related stuff.

Maryse47 commented 3 years ago

Wine is very specific and very volatile, so it's not a part of the runtime. The choice to not include the latest stable is a shame

Are you really saying not including wine in flatpak runtime which has no use for almost all but few flatpak apps is a shame for runtime developers?

the solution that Bottles has here is also something that Q4Wine should provide.

Using pre-built binaries from winehq doesn't make any guarantees they will be compatible with flatpak runtime unless app bundle all missing deps but it's not realistic to support this way alll wine versions and flavors which makes it not much different than building limited set of wine in flatpak.

Right now building feature-rich wine in flatpak is unnecessarily hard so downloading binaries may be acceptable as a workaround but not as end goal.

Eonfge commented 3 years ago

@Maryse47

Are you really saying not including wine in flatpak runtime which has no use for almost all but few flatpak apps is a shame for runtime developers?

No, I meant the flatpak-package. They could include Wine in this specific Flatpak, but since there are so many versions, they choose not to include it.

Maryse47 commented 3 years ago

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 commented 3 years ago

@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: https://github.com/flathub/flathub/pull/1830 Admin seem to not accept it - see comment by @barthalion https://github.com/flathub/flathub/pull/1830#issuecomment-716399497

Nokia808 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

@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 commented 3 years ago

@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 commented 3 years ago

@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.