On 2024-09-04 18:42, Ludovic Courtès wrote: > Hi Jacopo, > > Jacopo Mondi skribis: > >> 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. > > OK, I see, thanks for explaining the context. > >> 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. > > Yeah, got it. The other option, with the understanding that IPA modules > are all going to be free software here, would be to dismiss both the > authentication and the isolation mechanism, possibly with a custom > patch. It seems like the change wouldn’t be too intrusive and it would > solve the problem for “grafts” as well (grafts modify files in a > non-functional way). On 2024-09-02 10:45, Andrew Tropin via Bug reports for GNU Guix wrote: > Anyway, I think the current most reasonable solution is to remove > signing step at all, because the signaturs will be invalidated by > grafting anyway and make it work somehow (either by loading in > isolation if it's possible or by loading unsigned libraries without > signature check directly). Everything indicates that we need to disable module authentication. Jacopo, I think I'll patch IPAManager::isSignatureValid to always return true. https://git.libcamera.org/libcamera/libcamera.git/tree/src/libcamera/ipa_manager.cpp#n285 Like that: