/tech/ - Technology

Aren't portions of all C compilers, aside from tcc, lost to time and you can only bootstrap them beginning from certain pre-compiled versions of themselves? When talking about other languages, a lot of them started with C as the ground base so you'd need to check that as well. This shit is making my head hurt.

>>3871
Intel ME taught me to distrust my fucking CPU. Even hand-written assembly compilers won't cut it.

>>3871
guix has a full source bootstrap for gcc from 357 bytes of handwritten assembly.  you can run it on your computer.  also, all packages provided by the guix package manager are free software, depend only on free software, and are rooted in that single 357 byte binary.  There is also guix system, if you want your entire operating system to have this guarantee.  Last time I used it guix pull was unbearably slow, however.  Hopefully they've fixed that somewhat.
https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-building-from-source-all-the-way-down/

>>18167
>Last time I used it guix pull was unbearably slow, however.
That's specifically Savannah being slow as hell as it is(/was?) getting hammered by bots.
I believe they have switched to Codeberg as default since then. If not, just add this to ~/.config/guix/channels.scm:
(list
  (channel
    (inherit (car %default-channels))
    (url "https://codeberg.org/guix/guix")))

sonatype_survey_infographic.jpg
[Hide] (1.4MB, 1350x4800)

>>18167
>muh buttstrap
Asinine cargo cultism

If you actually cared about muh security you'd have somebody conduct a legit audit of every LTS release, but of course nobody does that except a handful of safety critical embedded platforms.

If you just want something unambiguous enough to trust gut feelings on, but easier to read than assembly, C is still a terrible choice because it's full of undefined crap and its bloated compiler's wizardry. Maybe something like Forth would be better.

>>18177
Guix uses a cryptographic (SHA256) hash of the source code and goes the extra mile to ensure 100% reproducibility.
It is not practical to verify a full-blown (and actually usable for common tasks) desktop OS without fully reproducible builds, so the work Guix and NixOS do is very important in this regard.

>>18181
>(SHA256) hash of the source
Cargo cultism. Hashed binary packages are exactly as trustworthy as uncompiled source nobody read.
>the work Guix and NixOS do is very important in this regard
The parts about ensuring bit-for-bit identical environments to those used by auditors can be deployed "the right way", instead of blindly dumping Docker images and Flatpak fake "sandboxes", yes. The arbitrary fetishism of C source as some sacred cow of transparency, not so much.

Security and bugginess aside, though, the ability to build everything the same way and roll everything backward and forward alongside multiple branches in the same install is extremely convenient for a ton of other reasons. Or at least it would be if the UI wasn't so autistically unpolished and the documentation wasn't so scattershot, for a project old enough to have kids in school.

>>18197
Assuming we are fine with starting "from scratch", how about something like this?

1. Specify a type of immutable object that isn't just bytes but also references other objects.
Specifically, make addresses not "just an integer/bytes" so it is possible to trace all objects to leaves from a single root node with just a single program/algorithm.
Instead of a single type of objects with both bytes and references, having two types of objects is fine too (one plain bytes, one only with references).
As the objects are immutable it is guaranteed they form a directed acyclic graph.
These references should be opaque to avoid exposing implementation details.

2. Use a cryptographic hash to refer to these objects.
This is possible due to the objects being immutable and not having any cyclic references.
The hash must differentiate (use a different domain) between plain bytes and references to avoid confusion attacks (e.g. tricking an implementation to interpret bytes as a reference).

3. Use "drivers" to transform objects.
These drivers take a single object as input and output a single object.
They must not depend on any external inputs to ensure the same input gives the exact same output, i.e. they are "pure".
These drivers should not expose the hashes of objects directly. It is an implementation detail.

4. Cryptographically sign hashes of objects.
Trusted entities can sign audited input and output objects.
It is also possible to sign subgraphs to allow incremental updates without verifying an entire graph/tree from scratch. Not unlike how mathematical proofs build upon other proofs.