Re: Truth matters when writing software and selecting leaders

[Jean Louis]

* Martin <smartin@disroot.org> [2021-04-13 20:41]:
> 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).

Do I understand it well:

- there must be some computer with a chip that is programmed by which
  method? Maybe physical switches? Then the chip spit the first binary
  which is used to create programming languags?

- or is there maybe some editor, so when small 8 bit CPU starts, user
  can enter some information and file is generated?

> > 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.

You said it there in a good example. People driving will not
necessarily get informed of security issues. 

> 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.

Sure, but that applies only to very narrow group of experts. It means
nothing for 99.999% of users, probably more than that. That is
disclosure that is missing on pages that are marketing reproducible
builds and bootstrappability.

"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." -- that is far from
 practical truth and reality.

Thos concepts will not help 40-50 million free softwware users to
understand and control their computer system; they will not help them
to eliminate any unnecessary (neither help them understand what would
be unnecessary), random, obscure, dirt and undefined behaviors from
the code because it requires proficient experts who know everything
from the begin to the end, this involves knowing all of the
boostrapped binaries, all of the internals of each of GCC versions and
other binaries involved, and to know security and internals of each
remote software ever pulled in this process, and this grows to the
distribution size. That is why I say it is probably less than 0.001%
of users that would have such capacities and skills.

For all others it will remain impractical. They will not even want to
know about it.

That there are thinkers like you is my appreciation to life on this
planet. But it will be worse, people will know less, not
more. Corporations want to make sure of it. We are in the war that we
do not even know that we are.

> > 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.:

There may be X number of tools, see above, as if 40 million users
cannot verify it, it is not verified for them. For you it may be
verified if you have done the process.

Did you verify it truly ever?

In speaking highly hypothetical of future goals, we have to disclose
the reality, as what you verify is not verified by myself, it does not
help, it just increases probability or trust, and we are anyway now
downloading software due to trust to servers and communities or
companies. This is the simplicity that will remain forever, it is a
built-in human OS known as TRUST but some may call it GULLY OS as for
GULLIBLE. Only few humans on the planet appear to be TRUST-free or
GULLY OS free. Reality is that even those few share the same ROM.

> 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.

It is climbing because of the hype and people liking it, not because
majority of Bitcoin users are able to truly verify anything, they
cannot. They can look into transaction log and say something, but no
fundemental verification can be done by 99.999% Bitcoin users. By
speaking that something is secure because of excellent design, does
not make it secure, it just opens number of ports to communicate with
the above mentioned GULLY OS.

> > 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.

As I said, speaking of something as perfect design, does not make it
practically verifiable. As majority of Bitcoin users will not be able
to define what is meant with "hash" unspoken of verifying the full
chain. They trust software blindly because they heard enough talk it
is secure. That is how all insecurities are discovered, first we hear
it is secure, than it is not secure. Bitcoin attacks are possible and
there is probably nothing that human has ever made that is
impenetrable by other humans.

You have got the point that we have no true security, and we will have
less in future, according to trends as of now 2021. But we can strive
to increase our illusion of security by using that what is generally
considered secure. Based on trust. Not on the actual fact that user
can verify anything, as user as member of majority, cannot.

> > 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.

It means there shall be practical way of verification.

One example is this discussion about booting from zero. When I want
now to really verify the first hex0, I do not get enough references to
start with.

If there are not enough references it probably means it is all yet
hypothetical, not practical.

What is missing there in reproducible builds is the documentation of
every thing from begin to the point of starting to build a
distribution, as that is the point where one can say that based on
previous experiences it is now up to users and society to verify the
rest of packages, and that verification of packages somehow seem to me
quite feasible by number of volunteers, there are many.

Only with practical knowledge well described, referenced, with
glossary of special terms, only then any average user can gain insight
into how system is built, can understand the first assembly or machine
code, and can understand whatever is built later, such as Forth, C
compilers, Lisp or similar. That will be also one of the best Computer
Science courses. Without that practical method to do it actually, and
to understand it through documentation, speaking about it brings no
practical benefit. Software may be modified as users wish and want,
and that will practically break reproducibility at some point of the
chain, the ABC GNU/Linux distribution may claim it is reproducible,
but with the broken chain, as that is impossible to maintain. Almost
every distribution introduce these or that patches to various software
and thus break the original upstream software.

> > > 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/

That is great, and I welcome that. It will be great exercise for small
number of experts.

> > Security issues appears from time to time:

> 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.

I am glad you see the point, we can strive to perfection, but we are
so far from it.

By the way, crackers are not concerned of efforts on bootstrapping and
reproducible builts, they need not be concerned of that, as there are
so many other unsolved issues, they have plethora of ways to steal
databases, listen on networks, leak, and do things.

> 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?

Yes.

Please include yourself in this discussion and say your opinion:
https://lists.nongnu.org/archive/html/gnu-linux-libre/2021-04/msg00015.html

Mbox format may be downloaded here:
https://lists.gnu.org/archive/mbox/gnu-linux-libre/2021-04 as for
direct replies.

And read this:
https://www.dr-chuck.com/csev-blog/2014/09/how-to-achieve-vendor-lock-in-with-a-legit-open-source-license-affero-gpl/

as that is exactly how Telegram is doing it, but currently FSF
endorses distributions with software that interacts with Skype,
Telegram, Twitter, etc. On the other hand campaign is there, money is
paid for decentralization of Internet, but FSF endorsed distributions
still partially work to centralize Internet.



-- 
Jean

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

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