Sandboxing

[sonnyp]

I use the flatpak version of bottles but still, I think bottles could benefit from builtin sandboxing for the following reasons

1. Get sandboxing support ala Steam or WebkitGTK even for non flatpak builds
2. Let users define per bottles permissions, at runtime rather than the Bottles team guessing which permissions should be given by default to all bottles. See [Flatpak] Reduce filesystem permissions  Bottles#413

It is possible to run bubblewrap in flatpaks.
Steam makes use of this - see flathub/com.valvesoftware.Steam#642 (comment)

I don't think this should be high priority given that it's already possible to sandbox through the flatpak version but I would be interested in hearing your thoughts and if you think it's relevant to Bottles.

[mirkobrombin]

I think it's a very useful feature. I had already thought about Bottles Sandbox a few months ago but I never really had time to get started on this task. I think it is very important not to limit the functionality to Flatpak and to allow users to turn it off and on as they please.

PS. Great to have the issue open in libbottles, as the feature must be part of this library. Except that this repository is currently on hiatus, as we are switching to C # with .NET Standard for Bottles Trento. libwine (python version) will be kept and updated but libbottles (also python) may not complete.

[sonnyp]

Feel free to move to the appropriate repository.

Out of curiosity, is there a particular reason for writing these components in C# / .NET ?

[mirkobrombin]

Feel free to move to the appropriate repository.

Out of curiosity, is there a particular reason for writing these components in C# / .NET ?

Bottles development effort is growing rapidly and I have a C# developer friend (@pietrodicaprio) who joined the project and helps me with Trento.

I also see the fun side of it: using a Microsoft programming language and framework to develop a program that helps running Windows software on Linux. Nothing "offensive", it's just funny :D

[sonnyp]

To be clear, I don't think I get a say in this and have no intention to contribute to Bottles ATM (beside Flatpak support) so I don't expect anything I will say to be taken into consideration and I will totally understand if you dismiss it.
Also, I'm not familiar with C# so please correct me if I'm wrong.

With that said, if there is no technical rational to use C# / .NET for the components of Bottles I would like to express concerns and suggest to reconsider.

1. Mono / C# isn't exactly popular outside of Windows, specially on Linux - raises contribution barrier
2. The GNOME or KDE frontend cannot realistically be built in C# so contributing to Bottles may require multiple languages
3. The GNOME application already has a runtime (Python), is an additional runtime really necessary ?
4. Given 1 - I don't expect interoperability with C# on Linux to be really good - this is just an assumption though

How are the frontends gonna make use of LibraryBottles? Can it be statically linked? I feel like I am missing something?

On a different topic but having spent the last 15 years (re-)building software, I would also like to take this as an opportunity to suggest reconsidering a all-in-one complete rewrite. It seems overkill and completely unnecessary (from my very new/limited viewpoint).

Why not going a more iterative path? Perhaps extract a libbottles out of Bottles first.

[sonnyp]

As for suggestion, if you don't want to use Python but would like something close to C#, wouldn't https://en.wikipedia.org/wiki/Vala_(programming_language) be a better choice?

[mirkobrombin]

To be clear, I don't think I get a say in this and have no intention to contribute to Bottles ATM (beside Flatpak support) so I don't expect anything I will say to be taken into consideration and I will totally understand if you dismiss it.
Also, I'm not familiar with C# so please correct me if I'm wrong.

With that said, if there is no technical rational to use C# / .NET for the components of Bottles I would like to express concerns and suggest to reconsider.

1. Mono / C# isn't exactly popular outside of Windows, specially on Linux - raises contribution barrier
2. The GNOME or KDE frontend cannot realistically be built in C# so contributing to Bottles may require multiple languages
3. The GNOME application already has a runtime (Python), is an additional runtime really necessary ?
4. Give 1 - I don't expect interoperability with C# on Linux to be really good - this is just an assumption though

How are the frontends gonna make use of LibraryBottles? Can it be statically linked? I feel like I am missing something?

On a different topic but having spent the last 15 years (re-)building software, I would also like to take this as an opportunity to suggest reconsidering a complete rewrite. It seems overkill and completely unnecessary (from my very new/limited viewpoint).

Why not going a more iterative path? Perhaps extract libbottles out of Bottles first.

Actually, these are all questions I've been asking myself in the last few months.

In general you are right and it is all understandable, rewriting a project from scratch is never easy. Unfortunately, however, Bottles current codebase is mostly wrong, broken, with sometimes twisted logic and difficult to expand in the future. A rewrite is mandatory, regardless of the language chosen.

There is great potential in Bottles that can only be unleashed with a redesign from scratch. Features like:

• overrides
• dependency compatibility checker

cannot be built with this codebase.

Bottles Trento was also created to solve the problems of updating and future expansion of the code.

Everything Wine related is programmed in libwine and LibraryWine. This means anyone can benefit from it, not just Bottles. This library is a complete Wine wrapper, you can do everything without having to interact with winecfg, regedit or other tools. Instead, the logic for managing bottles, dependencies, components, versioning, overrides and everything that creates the "product" resides in LibraryBottles.

Finally, the Bottles service exposes the API to which each client (GTK, QT, Web, ..) can communicate. This means that it will be possible to use any language to create third-party clients, integrations with other software and substantially infinite possibilities. This does not mean that we do all of this to have a thousand clients.

It is about organizing the project well to simplify future updates and make life easier for those who will get their hands on it in the future.

To give one last example, if today the logic behind Treviso is A, B, C, in Trento we need @, #, $.

Regarding Vala, I use it for my other projects but I don't have extensive knowledge of it and it could slow me down drastically in development. It certainly could be an option for the GTK client, given its C# friendly syntax.

Speaking of runtime instead, you are definitely right. But it should be noted that we will not be using Mono but .NET Standards due to compatibility with essential Nuget packages for Bottles which would mean investing resources in their future maintenance. It is also possible to compile Bottles as a standalone application, including the runtime in the bundle (really a negligible weight, it's impressive).

Regarding the barriers of C#, I believe this can become a first step between two worlds with two very different cultures.

Of course, everything is feasible with Python or other languages but in 4 years I have not yet received contributions from other developers and I can no longer manage the project alone, it really requires too much effort and time that I don't have because of my job.

I hope I have answered everything. Let me know if you have any other doubts or better solutions. Trento is still at the beginning of its development and nothing has been written with fire: D

[sonnyp]

Regarding the rewrite:

I did/do not question either a rewrite is necessary or not. You are the author and maintainer of Bottles I fully trust you when you say a rewrite is required for X or Y.

I question the strategy, I suggest to go with an iterative approach, start with something simple that will help you better understand the requirements, step by step. For example extracting libbottles out of Bottles to get started with. Or if you're comfortable with that, write a new libbottles library from scratch to make use of in Bottles. No need to write and release 4 different components all at once.

in 4 years I have not yet received contributions from other developers

That appears to be an exaggeration according to https://github.com/bottlesdevs/Bottles/graphs/contributors

But it is small indeed, have you thoughts that perhaps it's because Bottles just works, that maybe it does what it needs to do for 99% of users? It certainly is popular https://klausenbusk.github.io/flathub-stats/#ref=com.usebottles.bottles&interval=infinity&downloadType=installs%2Bupdates

and I can no longer manage the project alone, it really requires too much effort and time that I don't have because of my job.

Bottles takes too much effort so you're gonna rewrite it, split it into multiple languages/repository/projects and finally have multiple frontends for it?

On top of that, with a technology that present risks?

While maintaining the previous versions as well?

I don't understand the rational.

Finally, the Bottles service exposes the API to which each client (GTK, QT, Web, ..) can communicate.

Okay so it will be a service not a library?

A service with a runtime? Will it run as a daemon on the computer? When does it start? When does it stop? What's the communication protocol? DBus? TCP? WebSocket? How is that gonna integrate with flatpak/AppImage? Will distro packages all dependencies? Please don't answers, these are rhetorical questions to which I already have some of the answers. I'm trying to point out just the surface of the complexity involved - most of it is ahead and you can't see it yet.

It might look fun to work on these problems but it's not if you're not sure why you are doing it. Specially if you already feel like Bottles is too time consuming.

This means that it will be possible to use any language to create third-party clients, integrations with other software and substantially infinite possibilities. This does not mean that we do all of this to have a thousand clients.

You can do KDE/GNOME clients with a library rather than a service. As for Web, did anyone really woke up one day and thought "I want a Bottles service with a WebSocket transport protocol so that I can run a web client instead of a native app on my Linux desktop" ?

In fact I would state that there is no reasons for Bottles to run as a service/daemon on my computer. Snap, docker, ... already gets a lot of (IMHO justified) criticism for it. As a user it would really lower my trust to see bottles running after I closed the app.

But even then, did anyone really offer serious commitment to writing an alternative frontend for Bottles? I would guess not based on what you said earlier.

It is about organizing the project well to simplify future updates

The rewrite yes, the strategy and architecture, I really don't see it, none of the point you made go into that direction.

---

Sorry if I sound dismissive, I am sincerely trying to help.

I feel like I can relate to what you are going through, my experience and gut feeling tell me you are taking this too far and will create more problems than you will be solving.

You seem very dedicated, so I'm gonna predict that you're gonna spend lots of effort and time into this, ship it and finally get frustrated because nobody makes serious use of it while users will complain that X is broken or that Y is running a daemon or that B cannot compile because C#/.NET/whatever, or that distribution zyx doesn't package a required dependency.

Take a step back, make a serious analysis of problems, constraints and requirements before jumping ship.

I'm not interested in discussing further by GitHub comments but I'm happy to have a call and elaborate / see if I can help.

Email in my GitHub profile.

[mirkobrombin]

I will write to you for sure. The beauty of a community project is also being able to question things and review them with "external" eyes. Despite developing for 10 years, I do not exclude that I have become too deep in the project to miss some details.

[gasinvein]

It is possible to run bubblewrap in flatpaks.
Steam makes use of this - see flathub/com.valvesoftware.Steam#642 (comment)

This is not quite accurate. You can't run bwrap directly in flatpak sandbox, but you can ask flatpak to run a process in a "sub-sandbox" (optionally, with reduced permissions) for you. This is what WebKitGTK and pressure-vessel (Steam's container runner) do.

See the flatpak portal docs or the flatpak-spawn utility manpage for more details.