[arch-general] Announcing pacpak
Hello, A specter is haunting the GNU/Linux ecosystem: the specter of per-user containerization. Software like Flatpak and Snappy promise fully sandboxed GNU/Linux application bundles (instead of merely launching an application with fewer privileges but without hiding the operating system, like Bubblewrap or Firejail do). Bundles ship with the version of their dependencies which they need. Dependencies are not force-upgraded with the operating system, but easily upgradable by the bundle creator. The same files in different bundles and versions are deduplicated to save space. Applications can be containerized once for all modern GNU/Linux operating systems. Unlike Docker, Flatpak works without root privileges. Flatpak allows you to run, say, a sandboxed and containerized copy of LibreOffice where opening an infected file can only cause harm to what the sandbox has access to, but not compromise the integrity of the system as a whole. Untrustworthy games can be isolated and run without fear of a system compromise. More generally, most GUI applications should probably be installed to and run from a Flatpak sandbox. This has major implications for traditional package managers. Pacman would be demoted to providing the base system on top of which Flatpak bundles downloaded from elsewhere are run (e.g. from gnome.org or from reallytheofficialwebsiteoflibreofficeipromise.com). However, I would prefer having a unified pacman-like interface for installing containerized and non-containerized applications. I believe a PKGBUILD is a good way to specify how to build an application for Flatpak as well. I do not want to lose the many packages from Arch and derivative distributions. tl;dr: Therefore I started writing a tool called pacpak which uses pacman to populate Flatpak application bundles. Its interface is meant to be similar to pacman’s. For example, in order to install gedit into a Flatpak application using a bundle of the gnome packages as a runtime, you install pacpak from the AUR and use: $ pacpak -S Base xterm You can run the resulting application like this: $ flatpak run $(hostname).app.xterm pacpak is still in its early alpha stages. I do not currently have the time to devote more than a day per week to its development. However, I’d like some feedback on the basic idea. I am also looking for a home for the project in the longer term, since I do not currently like to administer a bug tracker on my own rented server and dislike centralizing all free software development on GitHub or Sourceforge (I’d rather administer my own then). This will only be helpful once all the basic features are implemented of course. I would be glad if pacpak or a similar tool eventually becomes an official Arch project. Let me conclude by thanking those who develop Flatpak, those who package and maintain Flatpak for Arch and all the other Arch and free software developers we rely on. Regards, Florian Pelz
A specter is haunting the GNU/Linux ecosystem: the specter of per-user containerization. Software like Flatpak and Snappy promise fully sandboxed GNU/Linux application bundles (instead of merely launching an application with fewer privileges but without hiding the operating system, like Bubblewrap or Firejail do). Bundles ship with the version of their dependencies which they need. Dependencies are not force-upgraded with the operating system, but easily upgradable by the bundle creator. The same files in different bundles and versions are deduplicated to save space. Applications can be containerized once for all modern GNU/Linux operating systems. Unlike Docker, Flatpak works without root privileges.
Are you planning to address the catastrophy that ensues when 5000 different versions of important libraries are installed at the same time, most of which will always be 5 critical security updates behind? Or the absurd memory consumption caused by the effective end of dynamic linking? I am very cynical about this container trend... :/ Cheers, Bennett -- GPG fingerprint: 871F 1047 7DB3 DDED 5FC4 47B2 26C7 E577 EF96 7808
On Sun, Jul 10, 2016 at 12:52:04PM +0200, Bennett Piater wrote:
I am very cynical about this container trend... :/
That's exactly the right attitude. -- Tomasz Kramkowski | GPG: 40B037BA0A5B8680 | Web: https://the-tk.com/
Hello, On 07/10/2016 12:52 PM, Bennett Piater wrote:
Are you planning to address the catastrophy that ensues when 5000 different versions of important libraries are installed at the same time, most of which will always be 5 critical security updates behind?
The intention is that, once implemented, `pacpak -Syu` or maybe `pacpak -Su` will install a current version of all apps and runtimes. Old versions of apps and app runtimes that are not used by any app could be cleaned by `pacpak -Sc` or a similar command (or automatically?); I’m not yet sure what the best interface is. Note that there is a trade-off between memory consumption and the time it takes to update a container. ostree (which is used by Flatpak) compresses all runtimes and apps for about half the hard disk memory consumption. This greatly increases the time it takes to update a container. This may need to be addressed in ostree in the future.
I am very cynical about this container trend... :/
The advantage of using pacman for Flatpak is that even pure Flatpak users may still be interested in Arch packages, so Arch packages remain just as relevant and everything stays mostly the same for those using pure pacman. Regards, Florian Pelz
On 07/10/2016 02:18 PM, pelzflorian (Florian Pelz) wrote:
The intention is that, once implemented, `pacpak -Syu` or maybe `pacpak -Su` will install a current version of all apps and runtimes. Old versions of apps and app runtimes that are not used by any app could be cleaned by `pacpak -Sc` or a similar command (or automatically?); I’m not yet sure what the best interface is.
Thanks for your reply. That would be the best you could do on the Arch side, but the problem is mostly that every upstream dev would need to maintain and keep his container up to date, isn't it? :) Cheers, Bennett -- GPG fingerprint: 871F 1047 7DB3 DDED 5FC4 47B2 26C7 E577 EF96 7808
On 07/10/2016 08:43 PM, Bennett Piater wrote:
Thanks for your reply. That would be the best you could do on the Arch side, but the problem is mostly that every upstream dev would need to maintain and keep his container up to date, isn't it? :)
pacpak is not meant to redistribute already packaged containers from upstream. Instead it can be used to create containers from existing Arch packages. Basically, a copy of Arch is installed into a container runtime. Then different sets of regular Arch packages can be added on top of the Arch base system to create one app container each. This is similar to one chroot per app, but with additional security measures and available to non-root users. Common files are stored only once on the hard drive. `pacpak -Syu` would therefore always install exactly the same version of the software as available with regular pacman. I’m sorry for not expressing myself clearly in previous posts. Regards, Florian Pelz
Florian, I love it, the tool itself is a break-through, just depends how we use it properly. On Mon, Jul 11, 2016 at 4:43 AM, pelzflorian (Florian Pelz) < pelzflorian@pelzflorian.de> wrote:
On 07/10/2016 08:43 PM, Bennett Piater wrote:
Thanks for your reply. That would be the best you could do on the Arch side, but the problem is mostly that every upstream dev would need to maintain and keep his container up to date, isn't it? :)
pacpak is not meant to redistribute already packaged containers from upstream. Instead it can be used to create containers from existing Arch packages. Basically, a copy of Arch is installed into a container runtime. Then different sets of regular Arch packages can be added on top of the Arch base system to create one app container each. This is similar to one chroot per app, but with additional security measures and available to non-root users. Common files are stored only once on the hard drive.
`pacpak -Syu` would therefore always install exactly the same version of the software as available with regular pacman.
I’m sorry for not expressing myself clearly in previous posts.
Regards, Florian Pelz
On 07/11/2016 03:32 AM, 郑文辉(Techlive Zheng) via arch-general wrote:
Florian, I love it, the tool itself is a break-through, just depends how we use it properly.
Thank you. I’m happy to get some positive feedback :) .
I think the tool is great Florian, but I do not think that it warrants official support. Consider examples like pacgem or pip2pkgbuild. These tools help integrate Ruby/Python packages (which are usually managed via a separate package manager) into pacman. They are great for users who want pacman to be the single package manager for their entire system, but they are still just AUR packages without official support. On Mon, Jul 11, 2016 at 2:00 AM, pelzflorian (Florian Pelz) < pelzflorian@pelzflorian.de> wrote:
On 07/11/2016 03:32 AM, 郑文辉(Techlive Zheng) via arch-general wrote:
Florian, I love it, the tool itself is a break-through, just depends how we use it properly.
Thank you. I’m happy to get some positive feedback :) .
On 07/11/2016 05:01 PM, Maxwell Anselm via arch-general wrote:
I think the tool is great Florian, but I do not think that it warrants official support. Consider examples like pacgem or pip2pkgbuild. These tools help integrate Ruby/Python packages (which are usually managed via a separate package manager) into pacman. They are great for users who want pacman to be the single package manager for their entire system, but they are still just AUR packages without official support.
I agree. This is a reasonable argument at least until Flatpak becomes much more popular. I will set it up elsewhere. Regards, Florian Pelz
On Monday 11 July 2016 18:57:38 pelzflorian wrote:
On 07/11/2016 05:01 PM, Maxwell Anselm via arch-general wrote:
I think the tool is great Florian, but I do not think that it warrants official support. Consider examples like pacgem or pip2pkgbuild. These tools help integrate Ruby/Python packages (which are usually managed via a separate package manager) into pacman. They are great for users who want pacman to be the single package manager for their entire system, but they are still just AUR packages without official support.
I agree. This is a reasonable argument at least until Flatpak becomes much more popular. I will set it up elsewhere.
Florian, What is the target user of pacpak? Arch users or App developers? I think Flatpak and Arch rolling release model mainly fix the same issue: Shipping cutting edge softwares quickly and stay close with upstream. Arch users will find flatpak less necessary as long as the package is rolling out quickly enough. For pacpak, it will be great if it could archive below working flow: 1. Upstream develop software on Arch, stay cutting edge. 2. Developer build packages using pacpak. 3. Those packages does not target Arch user, but other distro users. 4. Then app becomes a rolling application. And the running environment is just a subset of Arch linux. Security issues are fixed as quickly as us (Arch linux). Feng Chao
Regards, Florian Pelz
On 07/12/2016 09:29 AM, Chao Feng via arch-general wrote:
Florian,
What is the target user of pacpak? Arch users or App developers?
I think Flatpak and Arch rolling release model mainly fix the same issue: Shipping cutting edge softwares quickly and stay close with upstream.
Arch users will find flatpak less necessary as long as the package is rolling out quickly enough.
For pacpak, it will be great if it could archive below working flow:
1. Upstream develop software on Arch, stay cutting edge. 2. Developer build packages using pacpak. 3. Those packages does not target Arch user, but other distro users. 4. Then app becomes a rolling application. And the running environment is just a subset of Arch linux. Security issues are fixed as quickly as us (Arch linux).
Feng Chao
Flatpak is also about more isolated sandboxing with the app not seeing all other software, configuration files etc. on the operating system. I believe this is its core feature for Arch users. I want this sandboxing, but still use the well-maintained Arch packages, so I started pacpak. Therefore, the target group I had in mind for pacpak are Arch users, not developers. On the other hand, Flatpak’s target group does include developers who want to bundle their app with its dependencies to run on any GNU/Linux system. When I started this e-mail thread, I wrote about this as well and confused many people. However, it is also relevant to Arch because Flatpak would become a competition to Arch packages with the added feature of sandboxing. pacpak is meant to avoid this competition and instead integrate both. Now your idea is to use pacpak to create Flatpak apps for other distros. This is of course possible, but there are many issues: · Currently there are official non-Arch Flatpak platforms for X.org, GNOME, KDE etc. They are intended to be one centralized base on top of which all apps are built. Competing with them is bad for users, because when some apps would use this platform and some apps the other platform, both need to be installed. · If Arch really should compete with them, then there needs to be a centralized official Arch platform for all of X.org, GNOME, KDE, etc. The alternative is every developer shipping their own Arch platform, which means end users would need to fill up their hard disk even more. · There is a contradiction of goals here. With the official platforms, cutting edge software can be shipped as a Flatpak by its creators. With an Arch base, maintained software would be used as a base for unmaintained software. I don’t think we want to make the effort to compete here. Developers should use the official Flatpak platforms, not Arch. Only if a single user or organization wants to use an Arch app on another distribution, pacpak is appropriate. Regards, Florian Pelz
On 07/10/2016 10:43 PM, pelzflorian (Florian Pelz) wrote:
pacpak is not meant to redistribute already packaged containers from upstream. Instead it can be used to create containers from existing Arch packages. Basically, a copy of Arch is installed into a container runtime. Then different sets of regular Arch packages can be added on top of the Arch base system to create one app container each. This is similar to one chroot per app, but with additional security measures and available to non-root users. Common files are stored only once on the hard drive.
`pacpak -Syu` would therefore always install exactly the same version of the software as available with regular pacman.
Cool. Now that I understand what you are doing, it's a great idea! :) I just want to be able to keep my system up to date myself _and_ rely on the additional protection coming from maintainers. I had indeed misunderstood the purpose of your program. Cheers, Bennett -- GPG fingerprint: 871F 1047 7DB3 DDED 5FC4 47B2 26C7 E577 EF96 7808
`pacpak -Syu` would therefore always install exactly the same version of the software as available with regular pacman.
-Syu with pacman means refresh databases and install all available updates. does this mean pacpak execute this logic on all installed containers as pacman executes on all installed packages? especially the refresh part makes no sense to me at this point. what external database is there to refresh? an install command would likely look like -S like in pacman? whats the base for installation? PKGBUILDs (from AUR/ABS), official repos, some new platform containing build recipes for pacpak?
it can be used to create containers from existing Arch packages.
sounds like working from /var/cache/pacman. i generally like the idea of isolating and running untrusted software, as it allows one to implement sth like an applicationwise firewall (as done in android. wether this reduces or increases attack surface heavily depends on the implementation and its possibilities, but running malicious software will never be safe. this only adds another layer of control to the os. georg
On 07/11/2016 06:14 PM, G. Schlisio wrote:
[…] an install command would likely look like -S like in pacman? whats the base for installation? PKGBUILDs (from AUR/ABS), official repos, some new platform containing build recipes for pacpak?
pacpak will use the official repos (or other repos depending on the pacman.conf that is used) with the -S option and *.pkg.tar.gz with the -U option. Making -U accept PKGBUILDs directly seems like a useful feature though.
`pacpak -Syu` would therefore always install exactly the same version of the software as available with regular pacman.
-Syu with pacman means refresh databases and install all available updates. does this mean pacpak execute this logic on all installed containers as pacman executes on all installed packages? especially the refresh part makes no sense to me at this point. what external database is there to refresh?
[…]
it can be used to create containers from existing Arch packages.
sounds like working from /var/cache/pacman.
Since pacpak should be used without root privileges, I cannot use /var/cache/pacman as the package cache. In fact, I’d like to use an unprivileged pacpak-exclusive user for running pacman. pacpak will probably use one package cache per app. Packages common to multiple apps and their caching will be shared. (Flatpak uses runtime + SDK platforms on top of which apps as well as other platforms can be built. Many apps can share the same platform with its files.) `pacpak -Syu` would therefore refresh and upgrade each platform and then each app running on top of it. What I’m not sure about is whether anyone would want to only upgrade without refreshing. Probably there are some exceptional situations where the answer is yes.
i generally like the idea of isolating and running untrusted software, as it allows one to implement sth like an applicationwise firewall (as done in android. wether this reduces or increases attack surface heavily depends on the implementation and its possibilities, but running malicious software will never be safe. this only adds another layer of control to the os.
georg
It won’t be completely safe. I will add a reminder for new pacpak users to make sure they are aware of this as well. Regards, Florian Pelz
Hello, A while ago I started pacman and pacbub for file system isolation of pacman packages. pacpak and pacbub are dead now. They were the wrong approach for user space isolation. It all gets too hacky. It’s not KISS. I don’t like it anymore and would rather use GNU Guix for isolating users’ applications. Note that if you want to fine-tune a sandbox for a single application, bubblewrap is great. However, what I wanted is that I can install the GNOME packages in one tree and then create other trees out of it, for example one with gnome-maps and one with gnome-2048, but without redownloading all files and wasting disk space. Inheriting from another filesystem tree is what gets ugly because pacman and Arch packages are not designed for that – it probably works somewhat except for the pacman database but it’s too hacky. Guix is still pretty unstable and containerization support (e.g. `guix environment --container --ad-hoc coreutils`) currently is ugly too (compared to bubblewrap) but at least its basic design and intended use seem right for it. I am sorry for choosing the wrong path with Flatpak+pacman and bubblewrap+pacman and being slow at that too. It would have been much more work than I had hoped for and I don’t want to maintain a cluster of hacks. Regards, Florian
On 02/22/2017 08:35 AM, pelzflorian (Florian Pelz) wrote:
Note that if you want to fine-tune a sandbox for a single application, bubblewrap is great. However, what I wanted is that I can install the GNOME packages in one tree and then create other trees out of it, for example one with gnome-maps and one with gnome-2048, but without redownloading all files […]
Well, looking back at old messages in this thread, redownloading is not necessary when sharing /var/cache. Either way, if someone still wants to use bubblewrap for filesystem isolation, it is better to use the manual method described on the bubblewrap entry on the Arch wiki because manual maintenance may be required anyway.
IF flatpak is to become supported on AL, i'd prefer pacman to handle it instead of a separate application. My personal preference though is for AL community to treat flatpak similar as derivative distros. something like : flatpak is unsupported on Arch linux, ask the flatpak creator(s) for help.
Hello, On 07/10/2016 01:59 PM, LoneVVolf wrote:
My personal preference though is for AL community to treat flatpak similar as derivative distros.
something like : flatpak is unsupported on Arch linux, ask the flatpak creator(s) for help.
Hm… If there is not that much desire to support Flatpak “officially” as an Arch project, then I probably will end up setting up a mailing list and bug tracker on my server sometime in the coming weeks. Regards, Florian Pelz
On 10-07-2016 13:18, pelzflorian (Florian Pelz) wrote:
Hello,
On 07/10/2016 01:59 PM, LoneVVolf wrote:
My personal preference though is for AL community to treat flatpak similar as derivative distros.
something like : flatpak is unsupported on Arch linux, ask the flatpak creator(s) for help.
Hm… If there is not that much desire to support Flatpak “officially” as an Arch project, then I probably will end up setting up a mailing list and bug tracker on my server sometime in the coming weeks.
Regards, Florian Pelz
Personally I'd rather keep using the good old packages _but_ it would be nice to have an official tool to manage/run/create flatpak packages, this just to make sure that in case one needs to use a flatpak package nothing will screw up the filesystem and cause more trouble than it's worth. However a big fat warning should be present somewhere that bugs/problems with flatpak packages are the sole responsibility of upstream/the creator as I suspect bugs and problems will be the norm. -- Mauro Santos
On 07/10/2016 03:22 PM, Mauro Santos via arch-general wrote:
Personally I'd rather keep using the good old packages _but_ it would be nice to have an official tool to manage/run/create flatpak packages, this just to make sure that in case one needs to use a flatpak package nothing will screw up the filesystem and cause more trouble than it's worth.
However a big fat warning should be present somewhere that bugs/problems with flatpak packages are the sole responsibility of upstream/the creator as I suspect bugs and problems will be the norm.
Added to TODO list: Warn users. pacpak is meant to be a tool for building sandboxes from any existing package. Official tool or not, I do not think it is realistic to make a guarantee that all Arch packages will work with pacpak or Flatpak in general. Some packages or some features of packaged software (e.g. gnome-builder) cannot fully work with Flatpak because they would require nested containerization, setuid or similar privileges. Other packages may need additional privileges such as access to specific files or D-Bus names which pacpak may not be able to autodetect. Even for autodetected defaults, the user should review the privileges granted to software. It should be clear that the pacpak user will be responsible for specifying such privileges or at least confirm autodetected privilege settings. Regards, Florian Pelz
On 07/10/16 at 01:59pm, LoneVVolf wrote:
IF flatpak is to become supported on AL, i'd prefer pacman to handle it instead of a separate application.
flatpak is packaged in [extra], which for me means that it is indeed supported.
My personal preference though is for AL community to treat flatpak similar as derivative distros.
Huh? I'd say we support running flatpak's, but obviously not what runs in the flatpak :-)
something like : flatpak is unsupported on Arch linux, ask the flatpak creator(s) for help.
-- Jelle van der Waa
On 07/10/2016 11:05 AM, pelzflorian (Florian Pelz) wrote:
[...] Bundles ship with the version of their dependencies which they need. Dependencies are not force-upgraded with the operating system, but easily upgradable by the bundle creator.
We, as the Security Team, are strongly against any move to officially ship bundles that manage their dependency versions itself instead of regular software builds. In our opinion this will (sooner or later) lead to a security nightmare with vulnerable dependencies and slow upstream to fix such bundles. This approach multiplies the effort of tracking vulnerabilities in libraries from one entity to an "infinite" amount of upstream bundle creators. This whole concept makes our security work either highly inefficient or not possible at all. We have no interest in investigating all pinned versions of all bundles to ensure every shipped software is indeed properly fixed.
Flatpak allows you to run, say, a sandboxed and containerized copy of LibreOffice where opening an infected file can only cause harm to what the sandbox has access to, but not compromise the integrity of the system as a whole. Untrustworthy games can be isolated and run without fear of a system compromise. More generally, most GUI applications should probably be installed to and run from a Flatpak sandbox.
This is simply not true and in fact just an illusion. The whole security of containers entirely depend on kernel namespacing (and maybe cgroups against system-wide denial-of-service). All containers are sharing the very same kernel, any vulnerability and exploit against such will ultimately lead to a whole system compromise. The general trend of evangelizing that all fear should entirely be abandoned because containers can't possibly compromise the integrity of the whole system is wrong, self-defeating and dangerous.
This has major implications for traditional package managers. Pacman would be demoted to providing the base system on top of which Flatpak bundles downloaded from elsewhere are run (e.g. from gnome.org or from reallytheofficialwebsiteoflibreofficeipromise.com).
Just to make our (Security Team) opinion clear: We are strictly against such move (on a distribution level of scale) and strongly advise against it. We are very aware of the whole arguments and reasons of the advocator, however, this is our point of view. Also to be clear: We don't want to speak out against your project or discredit it in any means! Feel free to create and use whatever you like and makes you happy. We are just strongly against officially shipping bundles instead of regular software builds. sincerely, Levente
On 07/10/2016 04:45 PM, Levente Polyak wrote:
We, as the Security Team, are strongly against any move to officially ship bundles that manage their dependency versions itself instead of regular software builds. […]
With pacpak, it will be the user’s responsibility to update the bundles just like it is the user’s responsibility to update their Arch system. I do *not* want Arch to ship official bundles. Users of Flatpak bundles from elsewhere are of course on their own as well. Yes, a kernel vulnerability may allow malware to escape the container. I should not have said that Flatpaks can be run without any fear at all. pacpak users should be made aware of this. Regards, Florian Pelz
On 10 July 2016 at 11:05, pelzflorian (Florian Pelz) <pelzflorian@pelzflorian.de> wrote:
Hello,
A specter is haunting the GNU/Linux ecosystem: the specter of per-user containerization. Software like Flatpak and Snappy promise fully sandboxed GNU/Linux application bundles (instead of merely launching an application with fewer privileges but without hiding the operating system, like Bubblewrap or Firejail do). Bundles ship with the version of their dependencies which they need.
Ubuntu is doing something similar it seems https://bregmatter.wordpress.com/2016/07/04/x11-applications-and-unity-8/ This is for their non-deb (deb-less?) distro version, they install debs in containers, each getting their own XMir server. Good for non-trustworthy or exposed apps. -- damjan
On 07/13/2016 05:46 PM, Damjan Georgievski via arch-general wrote:
On 10 July 2016 at 11:05, pelzflorian (Florian Pelz) <pelzflorian@pelzflorian.de> wrote:
Hello,
A specter is haunting the GNU/Linux ecosystem: the specter of per-user containerization. Software like Flatpak and Snappy promise fully sandboxed GNU/Linux application bundles (instead of merely launching an application with fewer privileges but without hiding the operating system, like Bubblewrap or Firejail do). Bundles ship with the version of their dependencies which they need. Ubuntu is doing something similar it seems https://bregmatter.wordpress.com/2016/07/04/x11-applications-and-unity-8/
This is for their non-deb (deb-less?) distro version, they install debs in containers, each getting their own XMir server. Good for non-trustworthy or exposed apps.
Please preserve pacman and the traditional Arch KISS philosophy for those that administer/want a traditional arch system with updates to the current package without retaining all the baggage required for containerization. This just seems like a recipe for scrambled systems. -- David C. Rankin, J.D.,P.E.
Hello, On 07/14/2016 12:46 AM, Damjan Georgievski via arch-general wrote:
Ubuntu is doing something similar it seems https://bregmatter.wordpress.com/2016/07/04/x11-applications-and-unity-8/
This is for their non-deb (deb-less?) distro version, they install debs in containers, each getting their own XMir server. Good for non-trustworthy or exposed apps.
This is interesting; I did not know about libertine and will take a closer look at it. libertine’s purpose seems similar to pacpak’s. However, apparently unlike libertine, most of the work is already done by Flatpak itself. pacpak will only install using pacman, set up permissions and manage installed apps. The current consensus seems to be that Arch will not have any Flatpaks in its official repositories (neither would I want it to have any). pacpak will be a tool for the Arch user to bundle regular Arch packages into Flatpaks when they wish to run them in a sandboxed manner. It is thus an alternative to Bubblewrap and Firejail that offers more isolation from the host and its filesystem. So my roadmap looks like this: · July: Clean up the code and set up HACKING instructions, a mailing list and a pacpak’d bugtracker. Incorporate the ideas from this discussion. · August: Make sure every basic command works and is unit tested (-S, -R, -Q, -U, -Syu, -Sc). · September: Make sure the user experience for these is good enough, e.g. -Syu should not take an hour to complete. Regards, Florian Pelz
This is a nice and useful project, but I think we could be served better in the short term by having supported firejail profiles for things like Firefox and LibreOffice that are easy to use.
On 07/19/2016 07:03 PM, Carsten Mattner via arch-general wrote:
This is a nice and useful project, but I think we could be served better in the short term by having supported firejail profiles for things like Firefox and LibreOffice that are easy to use.
Firejail is a different design with less filesystem isolation. We should have both, even in the long term. The more direct competitor to Firejail is Bubblewrap, not Flatpak/pacpak. That said, the documentation on Firejail on the wiki seems to contain the most important things. I’m not knowledgable enough about Firejail though. Network namespaces are missing in the wiki instructions. I don’t know if Firejail can restrict D-Bus access. In the past I could launch an unrestricted Nautilus from a Firejail’d Icecat, but apparently that no longer works. I don’t know enough about the advantages/disadvantages over Bubblewrap; apparently there is some disagreement about the scope, e.g. whether how Pulseaudio should be dealt with. Regards, Florian Pelz
On Tue, Jul 19, 2016 at 8:37 PM, pelzflorian (Florian Pelz) <pelzflorian@pelzflorian.de> wrote:
On 07/19/2016 07:03 PM, Carsten Mattner via arch-general wrote:
This is a nice and useful project, but I think we could be served better in the short term by having supported firejail profiles for things like Firefox and LibreOffice that are easy to use.
Firejail is a different design with less filesystem isolation. We should have both, even in the long term. The more direct competitor to Firejail is Bubblewrap, not Flatpak/pacpak.
That said, the documentation on Firejail on the wiki seems to contain the most important things. I’m not knowledgable enough about Firejail though. Network namespaces are missing in the wiki instructions. I don’t know if Firejail can restrict D-Bus access. In the past I could launch an unrestricted Nautilus from a Firejail’d Icecat, but apparently that no longer works. I don’t know enough about the advantages/disadvantages over Bubblewrap; apparently there is some disagreement about the scope, e.g. whether how Pulseaudio should be dealt with.
FWIW I couldn't get Firejail's Firefox profile to work. What's the link for bubblewrap? It's such a generic term that it's hard to look up.
On 07/20/2016 01:11 PM, Carsten Mattner via arch-general wrote:
FWIW I couldn't get Firejail's Firefox profile to work.
What's the link for bubblewrap? It's such a generic term that it's hard to look up.
bubblewrap-git is in the AUR; it didn’t work for me though the last time I tried. I think it didn’t have the right permissions (setuid or user mount capabilities), but I’m not sure. Flatpak uses Bubblewrap internally however. I have not tried vanilla Firefox with Firejail, but Icecat works well the way it is described on the Arch wiki. Maybe you need to use the --no-remote option on Firefox if you have another running Firefox? Firejail does not isolate from other Firefox sessions. Regards, Florian Pelz
On 07/19/2016 08:37 PM, pelzflorian (Florian Pelz) wrote:
On 07/19/2016 07:03 PM, Carsten Mattner via arch-general wrote:
This is a nice and useful project, but I think we could be served better in the short term by having supported firejail profiles for things like Firefox and LibreOffice that are easy to use.
Firejail is a different design with less filesystem isolation. We should have both, even in the long term. The more direct competitor to Firejail is Bubblewrap, not Flatpak/pacpak.
That said, the documentation on Firejail on the wiki seems to contain the most important things. I’m not knowledgable enough about Firejail though. Network namespaces are missing in the wiki instructions. I don’t know if Firejail can restrict D-Bus access. In the past I could launch an unrestricted Nautilus from a Firejail’d Icecat, but apparently that no longer works. I don’t know enough about the advantages/disadvantages over Bubblewrap; apparently there is some disagreement about the scope, e.g. whether how Pulseaudio should be dealt with.
Hello, I have to admit that Flatpak seems not to be a suitable base for a pure sandboxing + filesystem isolation tool. Flatpak is meant to be used with networked repositories but pacpak does not need that. This means unnecessary copying of files into a repository that pacpak does not need anyway. Flatpak also keeps old versions of filesystem trees by default which takes up disk space unnecessarily. Using a proper sandbox for installing and not only running an app is cumbersome. Rather than work around all those issues, it seems more KISS to just build a sandboxed pacman wrapper with Bubblewrap and/or Firejail with added filesystem isolation instead of repurposing Flatpak. pacpak 0.2 is out. This will be the last version of pacpak. Current pacpak supports `pacpak -S Base xterm` – it works the way I described building apps with Flatpak on the Arch wiki – but no other commands have been implemented so far (not even upgrades). On nontrusting machines the keyring causes strange problems too and package integrity cannot be verified. pacpak still is *very* slow on my hard drive and the best way to improve speed seems to be not using Flatpak at all. Further development of pacpak will not target Flatpak but Bubblewrap. I will need a new name for a pacpak without Flatpak (bpac and pacwrap are already taken; maybe bubblepac) but I will continue working on it slowly… Regards, Florian Pelz
I will need a new name for a pacpak without Flatpak (bpac and pacwrap are already taken; maybe bubblepac) but I will continue working on it slowly…
Thanks for letting us know! I like bubblepac, it sounds good :) Cheers, Bennett -- GPG fingerprint: 871F 1047 7DB3 DDED 5FC4 47B2 26C7 E577 EF96 7808
On 08/05/2016 10:50 PM, Bennett Piater wrote:
Thanks for letting us know!
I like bubblepac, it sounds good :)
Thank you. I now tend towards pacbub; bubblepac seems too long. pacbub is similar to pacman and pacpak. It is also a pun on pacman because in German “der bub” is “the boy”. Regards, Florian Pelz
2016/08/06 22:40 "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de>:
On 08/05/2016 10:50 PM, Bennett Piater wrote:
Thanks for letting us know!
I like bubblepac, it sounds good :)
Thank you. I now tend towards pacbub; bubblepac seems too long. pacbub is similar to pacman and pacpak. It is also a pun on pacman because in German “der bub” is “the boy”.
Regards, Florian Pelz
Sounds nice. I like that name
On 08/06/2016 03:40 PM, pelzflorian (Florian Pelz) wrote:
Thank you. I now tend towards pacbub; bubblepac seems too long. pacbub is similar to pacman and pacpak. It is also a pun on pacman because in German “der bub” is “the boy”.
I like that too :) Cheers, Bennett -- GPG fingerprint: 871F 1047 7DB3 DDED 5FC4 47B2 26C7 E577 EF96 7808
participants (15)
-
Bennett Piater
-
Carsten Mattner
-
chaofeng111＠gmail.com
-
Damjan Georgievski
-
David C. Rankin
-
Dragon ryu
-
G. Schlisio
-
Jelle van der Waa
-
Levente Polyak
-
LoneVVolf
-
Mauro Santos
-
Maxwell Anselm
-
pelzflorian (Florian Pelz)
-
Tomasz Kramkowski
-
郑文辉(Techlive Zheng)