MIME-Version: 1.0
From: Ross Younger <crazyscot@gmail.com>
Date: Wed, 5 May 2021 17:05:57 +1200
Message-ID: <CA+gy4ieuXLuQddxmPuiucyZbut=14cR8tgmGrh0qE9qLDBivmg@mail.gmail.com>
Subject: Containerised APK builds and security xattrs
To: ~alpine/devel@lists.alpinelinux.org
Content-Type: text/plain; charset="UTF-8"

I am building my own APKs for local use, targeting alpine 3.13.

It seems that abuild causes package contents to inherit security
xattrs from the host OS (if present). This is tripping me up as these
packages fail to install on a container hosted by an OS that doesn't
have security contexts enabled.

I use Bitbucket for source control and am trying to set up
containerised CI in Bitbucket pipelines.
When I build my container using Bitbucket Pipelines the APK is
different from when I build locally!

When built on-cloud, the files in the APK contain security.selinux
xattrs. When built locally, they don't. (I have a script that runs the
Bitbucket pipeline in a local container, so I'm pretty sure the same
build steps are being followed.)

Installing an APK built on the cloud to a container on my local machine fails:

    /here # apk add --allow-untrusted date_h-dev-3.0.0-r2.apk
    (1/1) Installing date_h-dev (3.0.0-r2)
    ERROR: Failed to set xattrs on
usr/include/date/.apk.13d8a17d6f42822d457261eae2fa9ea9ba43faf2c673bf68:
Operation not permitted
    [...]
    1 error; 211 MiB in 53 packages

I have dug far enough to find that abuild explicitly calls `tar
--xattrs ...' when creating the package, and that `apk add' is simply
attempting to preserve that.

Is there any chance that that `tar --xattrs' in abuild might one day
change to --no-xattrs, or to something more complex that filters out
selinux xattrs? Perhaps you have a good reason for explicitly
including xattrs.

Or am I better off using something other than Bitbucket? Are there any
CI services you recommend (or disrecommend) for building APKs?

Thanks for your attention.

Ross