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?