[arch-general] Announcing pacpak

[pelzflorian (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