Re: Truth matters when writing software and selecting leaders

[Jean Louis]

* Martin <smartin@disroot.org> [2021-04-06 15:25]:
> On 4/5/21 5:52 PM, Jean Louis wrote:
> > I do understand the strive to perfectionism and there are projects
> > like Guix which strive to reach the point you are talking. Maybe such
> > projects can become bootstrapping distributions for other
> > distributions which cannot or did not reach that far yet.

> Guix is nice but at the moment it requires Guile(approx 20mb of binaries) to
> bootstrap itself. Better solution is
> https://github.com/fosslinux/live-bootstrap - there are even plans to
> integrate it with Guix directly, Debian and many other projects.

That is great. Yet, that project does not support fully free OS, as if
they accept kernel blobs, that defeats the purpose of bootstrapping
and reproducing. Comparison table says that Guix version would run
with Linux-libre kernel only, while their version runs with any
kernel. Which means introducing blobs for some reason. Unknown for now.

> > What means "to trust" compiler? We already trust our compilers,
> > obviously. We have confidence, faith in compilers and people making
> > it. Free software is insecure and we trust people behind
> > distributions. We have only freedom to verify it though largest
> > majority of users including programmers cannot possibly verify free
> > software on a system as it would take a life time. OpenBSD people are
> > verifying the system for decades they still did not finish. It is
> > never ending story.

> Well I don't trust compilers like any other software and I don't trust any
> people behind them.

I do, as I am forced to do so. It is one type of lock-in. Practically
it means little as software security does not depend on compilers
only. Whole chain has to be verified. Making an automated process to
compile one from each other does not make it enough safe IMHO. Even if
whole chain is verified, who is to guarantee that it was verified? So
for users, those verifications mostly do not matter. There is NO
WARRANTY whatsoever for most or all of free software, most of
times. For users thus practically, it does not matter.

Those efforts are though much appreciated. I like practical solutions,
but I do welcome all boostraping and reproducible build efforts. Sadly
I would not know how to contribute to it, other but building it and
verifying small portions of the process myself. Machine language I
have used to create games, it requires some patience, but not more
patience than learning any programming language. I would like to
verify the first binary that is entered and to know how it is
entered. It is not large, it may be verified and better described.

> The biggest advantage of open-source, gnu freedom "free software",
> etc in general is just the ability to verify the code itself.

We can do that for all source packages, but not for easy for the
compiler chain and not easy for binaries created by the compiler
chain.

> There are still many difficulties and limited ways to do it but it doesn't
> mean the verification effort is pointless. I believe in the future where all
> the basic computer hardware/software/systems could be formally verified and
> audited by anyone and in any time.

Let us say they are audited by entities, or persons A, B, C. What true
security does it mean for users? I say none. It just increases
illusion of safety to a certain degree, but it is far from trusting
it. There are millions of users. They have to trust their
distributions, they have no control of verification.

Now, what if verification finds something is wrong? Millions of users
will still continue using malicious software, it is practically taking
place every day millions of times.

> People should be able to build from very scratch, from nand logical
> gates and below to complex linux riscv machines and above to have
> full control in all that process. Small simple concepts like
> transparency, reproducible-builds, bootstrappability, simplicity,
> minimalism, etc are very essential to reach that perfect goal.

That is pleasure in exercise in computing. Something that each student
of CS should start with, I would include the hex0 initial stage as a
lesson in every CS course.

Just that goal is not perfect as you say. There is no warranty for
software, and there is no guarantee that auditing is uncompromised. We
also do not know true identities of developers and their background,
we cannot verify them, thus we cannot know what is really going on.

Speaking about it is good, it raises awareness, but not significantly,
users still remain there to trust their distributions.

Why we use "chain of trust" in other security related processes? Here
in this process there is no clear chain of trust, no process of
verification. What does it matter that somebody there on some server
says, that reproducible hash outcome is 123 compared to user's hash
123, makes it same, and thus trusted. It does not as user does not
know people behind those servers. Mass manipulations are done every
day through media, few words may change opinions of many. Again we end
up with trust on the end.

If I work as son, with my father, in the business of let us say money
exchange, and my father shows me how a bill may be verified on the
machine to be the authentic one, and I learn the process, and I know
that my father verifies it -- I have seen it and confirmed it with my
eyes and observations that it is so. Now my father can come tomorrow
in a new period of time and tells me that he verified all 10 bills of
the customer Joe. I would trust my father because of my personal
relation to my father, knowledge of his skills and abilities, and
knowledge of our security procedure.

But if person John, who I see first time, comes on the teller and
tells me, he verified bills himself, am I going to to trust John and
skip the bill verification?

By this example, end users cannot verify anything, we speak of
millions. Boostrapping and reproducible builds have meanings only for
experts, they are for majority of people useless. I don't say not
important, they are very important, but for people useless. They have
to trust blindly their distribution servers or DVDs they purchase or
obtain anyhow.

> > Maybe you wish to say we have to control compiler, but compiler is
> > huge, not even compiler developers can know what is everything inside,
> > they always find some new problems to solve.

> Hopefully there are still alternatives, and if GCC won't fix itself on time
> than it gonna die by natural selection.

You see, we speak of reproducible builds, but I do not know ANY
version that was fully audited. If that is not publicly known, it
defeats all the chain of boostrapability.

Security issues appears from time to time:
https://www.cvedetails.com/vulnerability-list.php?vendor_id=72&product_id=960&version_id=0&page=1&hasexp=0&opdos=0&opec=0&opov=0&opcsrf=0&opgpriv=0&opsqli=0&opxss=0&opdirt=0&opmemc=0&ophttprs=0&opbyp=0&opfileinc=0&opginf=0&cvssscoremin=0&cvssscoremax=0&year=0&cweid=0&order=1&trc=8&sha=1983b3d9908d852bd8b1cb5901c82b110579ba01
and such are never detected in time, it will be always too
late. 

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

Sign an open letter in support of Richard M. Stallman
https://rms-support-letter.github.io/