Re: [arch-general] Announcing pacpak
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.
Re: [arch-general] Announcing pacpak
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
Re: [arch-general] On containers. WAS: Re: snapcraft.io ...
Containers are an attempt to solve multiple issues. One is being a replacement for bundles. When people sell and distribute a proprietary app/game, they presumably want it to run on as many systems as possible with as little effort as possible. Having to rely on volunteer maintainers is not good, neither is having to maintain a lot themselves. Software bundles with all libraries included are the traditional solution to this on all operating systems. Flatpak seems like an even easier solution. The real issue in this discussion is security. Traditional GNU/Linux is too monolithic. Having more separation between an application and lower system layers adds security just like not using root for running a Web server and using separate user accounts for e.g. a Web server and an XMPP server does. Well-behaved software uses the self sandboxing you are talking about: dropping capabilities, revoking privileges. Two issues remain: Presumably most software (online games in particular) do not properly self-sandbox and are not secured very well. It’s safest not to install such software on your work PC but you may still wish to somewhat protect your gaming PC. Despite not knowing the software that well, we can try to constrain its privileges via containers/bubblewrap/firejail. What’s still missing however is proper filesystem isolation. Not every program needs to have access to any file in my home directory. More separation here is good for security. I don’t want to create a new user account for each app. I do want to use something like the new xdg desktop portals. I also want to hide what other software I have installed. I planned to do something with many small Arch Linux filesystems with inheritance through hardlinks, but maybe embracing Guix as an additional per-user package manager is a better approach? The same missing separation may be a reason to use Mach/Hurd over Linux. Of course that is still in its infancy. Regards, Florian Pelz
Re: [arch-general] Announcing pacpak
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
Re: [arch-general] Announcing pacpak
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
Re: [arch-general] Announcing pacpak
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 signature.asc Description: OpenPGP digital signature
Re: [arch-general] Announcing pacpak
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
Re: [arch-general] Announcing pacpak
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
Re: [arch-general] arch-general Digest, Vol 141, Issue 17
On 07/11/2016 10:40 PM, ITwrx.org wrote: > Florian, > > thanks for the reply and link. Well behaved build systems and/or the > link you sent is what i alluded to with my "cooperation from upstream" > comment. It seems to me, upstream and distros should get together and > agree on a set of standards. then all distros could auto-build their > repos. Unless "build once, run everywhere" can be done in a way that's > superior to repos and packages (i don't see how, but what do i know), it > seems like the wrong approach and would be completely unecessary with > all distros having near instant packages from upstream due to > automation. I'm not necessarily opposed to the theoretical, potential > security benefits of app containerization but minus the dependency > compat layer, especially if automation of building is not so out of > reach. Your package sounds interesting and good luck with it, i just > thought i'd bring up these questions before we throw the baby out with > the bath water. > > thanks, > ITwrx > > > You seem to be right at being critical about pure upstream packages. Customizing packages and taking care of bug reports cannot be done fully automatically in this way, so that part of app containerization is perhaps not ideal anyway. This link has recently been posted on the GNOME gtk-devel list; I think it is relevant here: http://kmkeen.com/maintainers-matter/2016-06-16-11-31-07-560.html Either way, this is not what I want pacpak to be. Regards, Florian Pelz
Re: [arch-general] Announcing pacpak
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
Re: [arch-general] Announcing pacpak
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
Re: [arch-general] Announcing pacpak
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 signature.asc Description: OpenPGP digital signature
Re: [arch-general] Announcing pacpak
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 :) .
Re: [arch-general] arch-general Digest, Vol 141, Issue 16
On 07/11/2016 01:09 AM, Information Technology Works wrote: > Aren't snaps, flatpak and appimage missing the boat in a concerning > way? Shouldn't the Gnu+Linux ecosystem be focusing on automating the > package building/maintenance instead? A layer above distros' package > managers(pacman, apt, etc) that can build upstream from source without > human intervention. Maybe upstream would have to cooperate in some way? > Every distro would just have to write a plugin/config for themselves > that described how their packages should be built, then their package > manager can be used to install binaries like now. Distro devs could > develop the system and verify it's integrity/security or do distro > feature related work instead of packaging. This would address all the > problems that these app container based systems are trying to solve > while keeping dependency resolution, repos, etc. in tact. Is this > impossible/wrong for some reason? > Hello, Work is being done in this area [1], but it’s not as fancy as you may think. It’s mostly about upstream using a well-behaved build system. Well-behaved software is easy to package anyway (just do `./configure --prefix=/usr`, `make` and `make install`). When customization is necessary or desired, pacman brings the needed versatility. Please note that “build once, run anywhere“ is not the only advantage of Flatpak and not one pacpak addresses. To me, containerization mostly provides added security by privilege revocation and separation of privileges. Regards, Florian Pelz [1] https://github.com/cgwalters/build-api
Re: [arch-general] Announcing pacpak
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
Re: [arch-general] Announcing pacpak
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
Re: [arch-general] Announcing pacpak
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
Re: [arch-general] Announcing pacpak
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
Re: [arch-general] Announcing pacpak
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
[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
Re: [arch-general] DKIM debuggage (Was: Deletion of old account)
On 05/24/2016 11:03 AM, G. Schlisio wrote: > Am 24.05.2016 um 10:58 schrieb pelzflorian (Florian Pelz): >> On 05/24/2016 10:41 AM, G. Schlisio wrote: >>> maybe this helps you to debug further (and lets see the state of my dkim >>> signature…) >> >> Not sure if you confused me with Florian Pritz or meant him by “you”. I >> changed my e-mail From name now. There's too many Florians on other >> lists as well… > > i think i confused noone. you (florian pelz) have invalid DKIM > signatures (domain pelzflorian.de), while florian pritz has correct > signatures (domain xinu.at). > what i wanted to stress is that i see a difference in the failure of > your DKIM signature compared to giovannis (which fails as well). i > wondered whether this could be a starting point for you to debug your > DKIM setup. > georg > OK, thank you. The same happens for me. I can send a mail to @pelzflorian.de (my mail server) and @googlemail.com and it verifies successfully. I believe now this problem is not on my side. Regards, Florian
Re: [arch-general] Deletion of old account
On 05/24/2016 10:41 AM, G. Schlisio wrote: > maybe this helps you to debug further (and lets see the state of my dkim > signature…) Not sure if you confused me with Florian Pritz or meant him by “you”. I changed my e-mail From name now. There's too many Florians on other lists as well…
