-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Flatpak bundle #147
Comments
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:
Couple issues found so far:
|
Here 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:
This is because of portals. It's a file redirecting system which prevents apps from escaping their sandbox. For ore info, see Sandboxing: 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? |
mkay it looks like my Flatpack Gentoo setup is a bit broken. xdg-kde-portal is not working properly or something |
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:
The third option would be arguably the easiest. It's what PlayOnLinux also does for example. 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: 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:
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. |
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.
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 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:
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 ~/ 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". 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. |
@iavael 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: |
@Nokia808 your assumptions are correct, but only in case if you don't run software in flatpak.
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. |
sigh |
mkay. so according to what I see, there is no |
ok. it apparently exists for free desktop:
As for KDE Sdk: https://bugs.kde.org/show_bug.cgi?id=411771 |
hold on... it looks like you can use |
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
But who will apply this ? The following PR seem not to see light: |
@Eonfge 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. |
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 |
@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. 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
|
@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. |
@brezerk by using mix of kde & freedesktop as suggested you get both 64 & 32 libs to build 64bit and 32but wine. |
@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? |
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. |
@brezerk Oh wait. Looks like there is no extension point for |
@gasinvein fix for sdk compat landed in kde runtime git repo and will be available when it's rebuild on flathub. |
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 ...... |
@Maryse47 Oh, that's nice. I'll try to build Q4Wine with Wine in a single bundle, then, when it lands. |
Dear I read the following on this repository:
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 ..... |
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?
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? |
For this allowing |
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 ........ |
Fixed kde sdk is on flathub now. Keep in mind that due to flatpak limitation you can't have |
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. |
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. |
@gasinvein i think so. Create a ticket for me to take a look please. Thanks! |
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
The text was updated successfully, but these errors were encountered: