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.
