[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

verifying Debian packages



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


Reply to: