Dear Elmar, > Have you received that letter from me? > Pls do respond shortly. > I can warmly recommend you debcheckroot for your issue. The program > has been written exactly for the purpose you require. > https://www.elstel.org/debcheckroot/ > I have also written on my web page why you should not use debsums:
Thank you for your explanation. Yes, indeed, debcheckroot is clearly part of the solution. However, there is still the self-referential conundrum, in a sense that the tool must be run on a separate device than the audit target. In my opinion, running the auditor on the target itself will ultimately always end up being in direct violation of Gödel's second incompleteness theorem. In the meantime, I have been investigating the possibility to run debcheckroot from the https://www.qubes-os.org hypervisor which would then be responsible for auditing its debian virtual machines. One problem is that Qubes still has trouble fully satisfying the reproducible-build standard. https://github.com/QubesOS/qubes-installer-qubes-os/pull/26 "This PR makes the ISO build almost reproducible" Hypervising with something like Qubes would push back the core self-referential conundrum to a much smaller footprint. It is not possible to solve it, but it is definitely possible to isolate it to a much, much smaller footprint than an entire Debian system. Quis custodiet ipsos custodes? (Who will guard the guards themselves?) How to audit the smaller Qubes-based core self-referential conundrum? The nitrokey approach could be promising: https://shop.nitrokey.com/shop/product/nitropad-x230-67 The idea is to run the auditor on a usb key which would also take care of auditing the Coreboot firmware in addition to watching Qubes. Of course, that will only make the next problem arise: Who will be responsible for surveillance of the nitrokey auditor? But then again, it would certainly push back the self-referential conundrum to a relatively small amount of code where it can be watched. In my intuition, this layering strategy will also turn out to be the only viable solution (mitigation actually) for the (C compiler's) trusting trust conundrum. In my opinion, both self-referential conundrums are ultimately all the result of Gödel's second incompleteness theorem. By the way, I just published an article about the issue that humans seem to have the same problem: https://www.reddit.com/r/mathematics/comments/l1bhx1/uncanny_similarity_between_g%C3%B6dels_second/ The problem is everywhere. I am actually only at the beginning of this investigation. It will take more work to describe more details of a solution/mitigation. I think that debcheckroot will indeed turn out to be the ideal solution to monitor Debian VM systems running on top of something like the Qubes hypervisor, assuming that it will be reproducible-build some day. Thanks! Erik Poupaert