bug#72828: Grafting breaks libcamera signatures

[Jacopo Mondi <jacopo.mondi@ideasonboard.com>]

Hi, I hope this mail reaches the issue tracker.

I'm one of the libcamera developer, and while I cant share any useful
opinions on the guix build issue, I would like to clarify some points
from the discussion above in order to help better understand the
context on why we sign libraries and load unsigned modules in a separate
context (as Ludo put it: why all this sophistication)

Quiting again Ludo

> This probably makes sense in the context that the copyright owner,
> Google, envisioned: presumably Android programs loading random
> proprietary modules coming from the app store.  But I wonder what the
> point is in the context of a free GNU/Linux distro.

Not exactly. In libcamera, apart from creating a library to ease all
the camera stack plumbing, we're creating an ecosystem of open-source
3A algorithms (what we call the IPA modules).

Camera vendors and ODMs which invested in products with specific
camera features, consider 3A algorithms and their tuning their secret
sauce and are usually not willing to consider releasing them as open
source with, fortunately, notable exceptions such as RaspberryPi

Please note that all the platforms libcamera supports have an
open-source 3A algorithm module available part of the main code base,
and we consider open source 3A modules our 'first class citizens' and
we're willing to develop and maintain them in libcamera mainline
branch as free software, but at this point we have to provide a way for
third-parties to load binary modules if they want to.

The alternative is to have them continue developing camera stacks
fully behind closed doors as it has been done so far.

As said, modules not built against the libcamera sources will not be
signed, as they are distributed by other means by a vendor in binary
form. To establish if a module has been built with the libcamera
sources or not, we sign it during the build with a volatile key and
validate the signature at run-time, when the IPA module is loaded.

IPA modules for which the signature is not valid (either because they
are distributed as binaries or, as in this case, because the build
system strips symbols before installing the objects) are loaded in an
isolated process and instead of being operated with direct function
calls, we have implemented an IPC mechanism to communicate with them.
This path is way less tested by our regular users and in our daily
work on libcamera. Vendors that are running their binaries as isolated
might have fixed issues here and there but maybe they have not
reported the issue and the associated fix upstream (we have no control
over this).

For this reason I don't suggest running modules as isolated, even more
if you have no reasons to do so. If all it takes is re-signing IPA modules
after stripping them as Andrew did I would really consider doing that.