<!DOCTYPE html><html><head><title></title><style type="text/css">p.MsoNormal,p.MsoNoSpacing{margin:0}
p.MsoNormal,p.MsoNoSpacing{margin:0}
p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><div>Hi all,<br></div><div><br></div><div>On Sun, Jan 21, 2024, at 19:54, Laurent Pinchart wrote:<br></div><blockquote type="cite" id="qt" style=""><div>On Sun, Jan 21, 2024 at 04:32:06PM +0000, Kieran Bingham via libcamera-devel wrote:<br></div><div>> Quoting Elias Naur via libcamera-devel (2024-01-21 14:09:52)<br></div><div>> > Hi Arnout,<br></div><div>> > <br></div><div>> > > The motivation behind adding this mechanism is that this allows rebuilding the<br></div><div>> > > library and getting a bit-by-bit identical result, without having to share the<br></div><div>> > > keys with which to sign the trusted modules. This is known as 'Reproducible<br></div><div>> > > Builds', and you can read more about its advantages on<br></div><div>> > > <a href="https://reproducible-builds.org/">https://reproducible-builds.org/</a>. With this feature, packagers that care about<br></div><div>> > > reproducible builds can disable the module signing, and enjoy equivalent<br></div><div>> > > security and performance while also allowing independent rebuilds.<br></div><div>> > <br></div><div>> > Thanks for working on reproducible builds. I locally hack libcamera<br></div><div>> > to achieve bit-for-bit reproducible builds, and look forward to no longer needing<br></div><div>> > that hack.<br></div><div>> <br></div><div>> I agree, finding a solution to handle reproducible builds is a good<br></div><div>> goal.<br></div></blockquote><div><br></div><div>Thanks for the encouragement!<br></div><div><br></div><blockquote type="cite" id="qt" style=""><div>> > I think the feature would even more useful if it were always enabled. In particular,<br></div><div>> > I propose to:<br></div><div>> > <br></div><div>> > - Always enable checksums.<br></div><div>> > - Embed the known checksums into the binary, not in a separate configuration file.<br></div><div>> <br></div><div>> I think this is a fairly important requirement to be able to upstream a<br></div><div>> reproducilble builds solution. The checksums should be stored within the<br></div><div>> libcamera binary so the configuration file can not be amended after the<br></div><div>> fact, which would otherwise defeat the purpose. <br></div><div>> <br></div><div>> But this makes things much more difficult I believe...<br></div><div>> <br></div><div>> The tricky parts here will be handling how to verify the checksum of the<br></div><div>> modules while distributions do actions such as stripping symbols. There<br></div><div>> are legitimate modifications that can be made to the module as part of<br></div><div>> the installation process which would then break the checksum<br></div><div>> verifications.<br></div></blockquote><div><br></div><div>Indeed: embedding the checksums in the binary was my initial approach, but it's tricky given the legitimate use cases for modifying the objects in the install phase.<br></div><div><br></div><blockquote type="cite" id="qt" style=""><div>Checksums in a configuration file is a no-go I'm afraid, as it means<br></div><div>anyone could ship a closed-source IPA module and instruct users to add<br></div><div>an entry to the configuration file, circumventing IPA module isolation.<br></div></blockquote><div><br></div><div>It depends on your threat model / risk appetite, of course - it's hard to protect against users that are happy to explicitly trust such a third-party module. Going to extremes, someone could even try to convince such users to load a version of libcamera that trusts their module, or other terrible hacks. I guess we don't want to make it too easy, though.<br></div><div><br></div><div>I'd be happy to provide a version of this patch with the 'LIBCAMERA_IPA_TRUSTED_MODULE_CHECKSUMS_FILE' environment variable support removed, and a meson option to enable/disable trusting checksums - default value up to you. That may increase the barrier and give distributions a chance to make their own trade-off?<br></div><div><br></div><div>(I also like Elias' idea of statically linking the in-tree modules, but I don't think I'm comfortable enough with the codebase to take that on)<br></div><div><br></div><blockquote type="cite" id="qt" style=""><div>> > - Don't sign IPAs that have known checksums (thus achieving bit-for-bit reproducibility).<br></div><div>> > - In your patch, I believe this is equivalent to "ipa_sign_modules" always being false.<br></div><div>> <br></div><div>> Would there be a mix of signed+checksummed modules in a given<br></div><div>> distribution?<br></div></blockquote><div><br></div><div>I don't see an obvious use case for having both, but I don't see a reason to restrict it either.<br></div><div><br></div><div><br></div><div>Kind regards,<br></div><div><br></div><div>Arnout<br></div></body></html>