Re: Truth matters when writing software and selecting leaders

[Martin]

On 4/12/21 4:53 PM, Jean Louis wrote:
> > 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.
Live-bootstrap (still under early development state at the moment) is a 
pure bare metal project aiming to be used before involving any OS. 
Kernel blobs are out of scope for them, because linux-kernel in general 
is not capable to operate on 8bit processor with 300bytes of ROM and a 
single 4bits of RAM - the hardware requirements for hex0 you can build 
from scratch i.e.: https://www.nand2tetris.org/ . But yes if you really 
want you could also setup it on some over-complicated hypocritical Cloud 
environment based on Microsoft Windows Guest Virtual Machines powered by 
Guix linux-libre KVM Hosts (another not fixable freedom bug in "free 
software"^tm).
> > 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.
Scientific papers are also full of hidden or disclosure errors, but it 
doesn't mean theoretical studies are bad because of this inevitable side 
effects. In fact perfect abstractions are very useful in practice even 
though you will never rich them directly. In real world there is no such 
think like 100% security, but still we always want to be as close as 
possible to that imaginary point. Besides machine code could be really 
fun as well http://tom7.org/abc/
> > 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.
easy problems are boring
> > 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.
I don't think someone would like to repeat the 
https://en.wikipedia.org/wiki/Volkswagen_emissions_scandal even though 
some corrupted VW cars are still on the streets. Besides 
reproducible-bulds and bootstrappability are not only about the 
security. These concepts can really help you to understand and control 
your computer system by eliminating any unnecessary random, obscure, 
dirty and undefined behaviors from your code. These kind of projects are 
easier to maintain, test, optimize, extend, etc.
> > 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.
There are many tools available to formally verify the code, i.e.: Coq, 
Idris, Agda, etc. If it works for real research to facilitate crafting 
and validating complicated mathematical lemmas, i.e.: 
https://homotopytypetheory.org/ than it could be also used to verify the 
integrity of the goal from above. Anyway we don't know and we cannot 
check all identities of Linux developers neither, but it doesn't stop us 
of using their kernels. Bitcoin today is climbing again ATH mainly 
because of the "Trust No One" approach designed by His Excellency Mr. 
Satoshi Nakamoto.
> 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.
Perfect "chain of trust" doesn't exist but hardening it with 
reproducible hashes makes it more difficult to hack for potential 
attackers.
> 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?
What if your father would be blackmailed or cheated by 3rd parties in 
this example or some conflicts of interest would appear in your family? 
Would you still trust him more than some random John? Combination of 
trust, love, addictions, weaknesses, unpredictable human errors, etc 
could be tricky. Compare this situation with various blockchain 
cryptocurrencies solutions using flexible multi-key authentication 
wallets or in general 
https://en.wikipedia.org/wiki/Zero_trust_security_model , 
https://en.wikipedia.org/wiki/Zero-knowledge_proof , etc. The issue with 
trust is like with security - cannot be 100% accomplished in practice, 
but you can and you should always try to improve it.
> 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.
There are also plenty of people mainly elders and from some exotic 
countries who don't know how to use keyboards - does it mean we should 
abandon all our computers because they don't know how to use it? If 
designs and concepts are good than sooner or later people will adopt it 
naturally with or without special support.
> > 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.
Because it was ignored and never enforced by anyone. Reproducible-builds 
is a new important concept that soon will be included in the official 
"Debian Free Software Guidelines" when they fully fix it internally 
https://isdebianreproducibleyet.com/
> 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.
It's normal because the perfect vacuum in CS doesn't exist neither. Thus 
we can choose:
1. the proprietary path of ignoring the problems by hiding infinite bugs 
in some legacy code for the private interest or
2. transparent path of constantly improving and fixing every single 
issue in the public domain for the common-wealth.
This spectrum of choices is quite wide and sometimes could be mixed so 
we have to revise frequently on which side we are standing and where GNU 
is leading us atm: https://www.gnu.org/distros/common-distros.en.html vs 
https://guix.gnu.org/en/packages/telegram-desktop-2.5.9/ ? Why 
completely optional and disabled by default nonfree debian API is worst 
than the proprietary server API strictly required in clearly non-ethical 
Telegram app? Why shouldn't I classify this awkward situation as yet 
another freedom bug in "free software"^tm?