• verifying Debian packages

    From Erik Poupaert@21:1/5 to All on Sat Jan 23 23:30:01 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)