[pkg-apparmor] Bug#776043: Please make apparmor Multi-Arch: foreign

[Helmut Grohne]

On Thu, Jul 26, 2018 at 02:51:16PM +0800, intrigeri wrote:
>    This package is arch:any and builds architecture-specific binaries,
>    so after reading a bit of https://wiki.ubuntu.com/MultiarchSpec, it
>    seems dubious to me that it "should be allowed to satisfy the
>    dependencies of a package of another architecture than its own".
>    I mean, this might work in the specific "armhf on arm64" case but
>    it won't work e.g. for "amd64 on arm64" because apparmor_parser
>    simply cannot be executed there. Riku, is that right or did
>    I understand the meaning of "Multi-Arch: foreign" wrong?

We generally ignore executability for the purpose of M-A:foreign.
Indeed, you can even run arm64 code on amd64 with qemu-user-static. For
the purpose of cross building, we assume that M-A:foreign packages are
always taken from the build architecture.

>    (Only matters if I'm wrong above:) I had a look and I believe
>    that the only thing that can potentially expose the architecture
>    is apparmor_parser, so this boils down to "is the output of
>    apparmor_parser architecture-dependent?"; we can make this
>    package Multi-Arch:  foreign if, and only if, the answer to this
>    question is "no". John, do you know the answer by heart?

Yes, this is difficult, domain-specific question to answer.

Please excuse my nescience of apparmor, but does it deal with syscalls
in any way? syscall numbers and parameters are known do differ for
different architectures. So this might be a source of awareness.

> 2. apparmor-utils
> 
>    This package is arch:any as well. I admit I'm not sure why and it
>    may be a leftover from previous implementation of these tools:
>    nowadays this package installs only Python 3 and shell scripts.
>    I think it could be converted to arch:all and then possibly
>    Multi-Arch: foreign can be added.

I see that python3-apparmor is a separate package. Had it been merged
into apparmor-utils, that would have voided M-A:foreign. Turning
Arch:all is not a prerequisite for the marking and note that
/etc/apparmor/severity.db and /etc/apparmor/logprof.conf are not
equal[1] on all architectures. Before marking M-A:foreign or turning
Arch:all, investigate why and whether it matters.

I can tell from experience, that the devil is in the detail. I marked
make M-A:foreign. Boy was I wrong. Months later, Jakub Wilk told me how
it exposes architecture-dependent search paths via "target : -lfoo"
where -lfoo would be looked up in the (native) library search path. Most
users of make don't use that feature, but the mere existence is why make
is now M-A:allowed rather than M-A:foreign.

Hope this helps

Helmut

[1] On delfin.d.o, there is a sqlite3 database of all hashes of all
    files of all Debian unstable packages for all architectures.