Re: [arch-general] Announcing pacpak

[pelzflorian (Florian Pelz)]

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

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

Re: [arch-general] Announcing pacpak

[Bennett Piater]

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



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Announcing pacpak

[Dragon ryu via arch-general]

2016/08/06 22:40 "pelzflorian (Florian Pelz)" :
>
> 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

Re: [arch-general] Announcing pacpak

[pelzflorian (Florian Pelz)]

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

[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

Re: [arch-general] Announcing pacpak

[pelzflorian (Florian Pelz)]

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

[Carsten Mattner via arch-general]

On Tue, Jul 19, 2016 at 8: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.

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.

Re: [arch-general] Announcing pacpak

[pelzflorian (Florian Pelz)]

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

[Carsten Mattner via arch-general]

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.

Re: [arch-general] Announcing pacpak

[pelzflorian (Florian Pelz)]

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] Announcing pacpak

[David C. Rankin]

On 07/13/2016 05:46 PM, Damjan Georgievski via arch-general wrote:
> On 10 July 2016 at 11:05, pelzflorian (Florian Pelz)
>  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.

Re: [arch-general] Announcing pacpak

[Damjan Georgievski via arch-general]

On 10 July 2016 at 11:05, pelzflorian (Florian Pelz)
 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

Re: [arch-general] Announcing pacpak

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

Re: [arch-general] Announcing pacpak

[Chao Feng via arch-general]

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

Re: [arch-general] Announcing pacpak

[pelzflorian (Florian Pelz)]

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

[pelzflorian (Florian Pelz)]

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

[G. Schlisio]

> `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



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Announcing pacpak

[pelzflorian (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 :) .

Re: [arch-general] Announcing pacpak

[Techlive Zheng]

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) <
pelzflor...@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
>

Re: [arch-general] Announcing pacpak

[pelzflorian (Florian Pelz)]

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

[Bennett Piater]

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



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Announcing pacpak

[pelzflorian (Florian Pelz)]

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

[pelzflorian (Florian Pelz)]

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

[Levente Polyak]

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



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Announcing pacpak

[Jelle van der Waa]

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


signature.asc
Description: PGP signature

Re: [arch-general] Announcing pacpak

[Mauro Santos via arch-general]

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

Re: [arch-general] Announcing pacpak

[pelzflorian (Florian Pelz)]

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

[pelzflorian (Florian Pelz)]

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

Re: [arch-general] Announcing pacpak

[LoneVVolf]

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.

Re: [arch-general] Announcing pacpak

[Tomasz Kramkowski via arch-general]

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/

Re: [arch-general] Announcing pacpak

[Bennett Piater]

> 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



signature.asc
Description: OpenPGP digital signature

[arch-general] Announcing pacpak

[pelzflorian (Florian Pelz)]

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