This is a very software-engineery point of view and totally false for the ordinary user. Heck, it is even false for me as a software engineer.

> since you know people like moving a mouse and clicking on buttons

No, they like well-designed user interfaces, and the UI design of a typical CLI is abysmal.

It's yet another xkcd-level apocalypse.

Not trying to downplay the time wasted to reject the PR, though.

Specifically, humans are known to decide subconsciously, then invent some "reasoning" out of thin air to justify it.

This matches my experience with decision-making in software projects.

I'm thinking of something like: Explain, in at most 300 characters, why we should merge your change, or at least why we should invest the time to read a longer explanation (somethings things ARE complex). If you don't do that, or those 300 characters aren't convincing, or have nothing to do with your change or the longer explanation, then you get a canned response so the maintainers waste minimal time.

At least verifying a signature is something that does not need complex hardware, so chances are that your trusted hardware can do that.

> Your own trusted hardware AND software, because you're not going to be verifying that signature by hand, and you're not going to load the binary file in memory by hand, so either a kernel or system software (like UEFI) will be handling your trusted binary first. > > But then you're back to needing a clean bootstrap again. (...)

But having solved that bootstrapping problem, you are likewise back to square one with trusting "the payload", only this time the payload isn't the actual payload but the OS kernel, UEFI or whatever that obtains and verifies the actual payload.

You have that OS kernel or UEFI as source code, but you don't know if the source code contains a backdoor unless you either verify it manually, or have it verified and signed in some way by a third party you trust, and there the whole signature thing comes back.

(BTW thanks for the discussion. I'm really enjoying this!)

In contrast, how can you make sure that the actual payload code hasn't been tampered with? It is written in a high-level language, but it gets stored and viewed on devices that have backdoors in their CPU microcode and huge OSes that can hide god knows what. The author can sign the code, but that doesn't tell anything other than it was really the author who signed it and the code hasn't been modified afterwards -- if the author's system was compromised, the code can contain backdoors before being signed. So you need to validate the (signed or not) code to be correct, but you're doing so on an untrusted system. It goes on and on.

You'd probably need the code to be verified, then signed, by a trusted party on a trusted system. THAT signature then means the payload hasn't been tampered with, and can be trusted after it gets built on your trusted system (and this is where the bootstrap problem happens, and gets solved).

All this is obviously still glossing over the problem how to obtain hardware you can trust.

...edit: But if you have all that, then you don't need a complex bootstrapping anymore. A trusted actor can verify, or even build, a trusted system by hand on trusted hardware, sign it, and then you can use that (binary!) as long as you run it on your own trusted hardware and verify the signature first.

The bootstrapping then becomes a tool to ensure reproducibility, but is no longer needed for trust.

The GCC example is valid, but can also be explained by its size.

I like the idea of bootstrapping in a Lisp-like language since it is extremely expressive for its simplicity. But then you need an interpreter for that, which must be trusted. I've been nerd-sniped by the whole thing and I'm thinking about an extremely simple virtual machine for the seed, with the actual seed code being a binary for that VM that implements a Lisp. Then an audit of the seed becomes disassembling the VM code for the Lisp interpreter, which is only moderately complex because the VM is as simple as possible.

I'll use this to ask for an explanation about the fundamental idea: How is hex text better than a binary blob? Both need detailed knowledge to understand; both need a tool to display (reading ASCII or binary), either of which could be compromised in a "trusting trust" sense.

It seems to me that the actually important aspects of the initial "seed" are its size (larger is harder to verify) and that the language used (whether it is Lisp, binary machine code or whatever) has rigorously defined semantics.

(Orthogonal to that, you'd want to store everything, seed and the rest, on a medium that cannot hide anything from you, and use that as the source. But that applies to all approaches.)

What is the "n that goes to infinity" for Sudoku? I thought that you could iterate through all possible 9x9 grids and find the ones that satisfy the rules AND are consistent with the "known" numbers. That would make it O(1), not NP-hard.

Your logic is self-defeating. How are distro volunteers going to know that you are interested in this topic if, by your logic, you don't have the privilege to ask them in the first place?

But I don't think that asking needs any privilege. I'm going to ask again: Why not? Or worded differently: What is stopping language package managers that is not at the same time stopping distro package managers?

Why not? Seems like exactly what is being asked for.