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?



Reply via email to