Open Eonfge opened 5 years ago
Sounds nice. I'll take a look.
Has anyone built q4wine on flatpak? I want to test it.
not yet. I am still looking into the flatpak documentation >_<
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:
Process
tab. Probably b/c there is no access to host's /proc
filesystem; icoutils
and fuseiso
binaries are not availableHere is the test manifest https://github.com/brezerk/q4wine/blob/master/pkg/ua.org.brezblock.Q4Wine.json
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?
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.
Are File selection dialogs working for you too?
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.
mkay
it looks like my Flatpack Gentoo setup is a bit broken.
xdg-kde-portal is not working properly or something
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
@brezerk I've given it a bit more thought while I was at the gym, and there are a few options:
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.
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
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.
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:
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.
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.
@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 ?
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 .....
@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.
@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 ......
@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.
sigh is there any documentation available on how to use this Sdk extensions? https://github.com/flatpak/flatpak/wiki/Extensions is not really helpfull.
mkay. so according to what I see, there is no Compat.i386
extensions avaliable nor for org.freedesktop.Sdk
, nor for org.kde.Sdk
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
hold on... it looks like you can use inherit-extensions
instead
mkay. there is some progress on this: https://github.com/brezerk/q4wine/commit/304f56dfb8f4409a8457b4a5cf487e2fb42663aa feel free to play around
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
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.
@gasinvein wow, nice job. thank you!
@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.
@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 ?
@Nokia808 Building Q4Wine as a flatpak is easy, but handling Wine isn't. It poses several questions:
@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.
@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 ?
@Nokia808 for more general questions about Wine and Flatpak please read first:
and join to discussing.
@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.
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.
@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.
@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.
@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.
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.
@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.
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.
@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
@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.
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.
@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.
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.
@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.
@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.
@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!
@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.
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