<aszlig>
trying to nail down the regression for our kernel-latest tests and i want to get sure that it's not because of the Nix store being mounted readonly
<aszlig>
never mind, posted to #nixos as there are more people lurking in there =)
init_6 has quit [Ping timeout: 272 seconds]
Lisanna has joined #nixos-dev
<meizikyn>
you could run a quick vm or an nspawn if your on that kernel
jtojnar has joined #nixos-dev
worldofpeace has joined #nixos-dev
worldofpeace has quit [Ping timeout: 250 seconds]
Synthetica has quit [Quit: Connection closed for inactivity]
jtojnar has quit [Quit: jtojnar]
lassulus_ has joined #nixos-dev
lassulus has quit [Ping timeout: 268 seconds]
lassulus_ is now known as lassulus
init_6 has joined #nixos-dev
pie__ has joined #nixos-dev
init_6 has quit [Ping timeout: 246 seconds]
drakonis_ has quit [Ping timeout: 272 seconds]
init_6 has joined #nixos-dev
<qyliss>
When reviewing PRs by other committers, is there a general preference for whether I should approve and let them self-merge, or just merge directly?
<yegortimoshenko>
it's unlikely there's general preference
<ekleog>
do we have any way of testing a build on darwin from nixpkgs master other than opening a dummy PR with some whitespace change just to be able to trigger ofborg?
<arianvp>
guix seems to have bootstrapped rust from source
<arianvp>
nie
<arianvp>
nice*
<simpson>
Well, from a C++ compiler.
<arianvp>
bootstrappping towards a gcc dependency is almost 'good enough'
<arianvp>
:P
<simpson>
Think in *relative* terms, rather than absolute terms. It's bootstrapped *relative* to GCC.
<Synthetica>
Can't we compile with a pre-compiled compiler, and check that we get the same result?
<simpson>
Synthetica: No; there is an infamous idea, called "Trusting Trust", which shows up here. A computational artifact can't prove certain facts about itself.
<arianvp>
a classic
<arianvp>
but reducing the amount of people you need to trust is still good right
<arianvp>
now we only need to trust K&R
<simpson>
As a simple and relevant example, a prover program cannot meaningfully prove itself to be consistent, because it still be inconsistent and have come to the conclusion erroneously.
<simpson>
Also Tarksi, Turing, Thompson, etc. It is a recurring realization.
<ekleog>
simpson: in this specific case if you consider only the compiler, trusting trust is kind of non-existent
<ekleog>
rustc comes from ocaml which comes from some old variant of lisp
<ekleog>
mrustc (which I guess is what they bootstrapped from) comes from g++ which comes from gcc which comes from… something that iirc is not some old variant of lisp
<arianvp>
I think in this case they didn't use the original rust compiler
<arianvp>
but mrust, which is written in C++
<ekleog>
so basically either the computers at the time that lisp dialect and gcc diverged were already compromised to compromise rustc, or rustc is clean
<ekleog>
(and yeah, mrustc's author did check the bit-reproducibility of the compiler build, and it passed)
<ekleog>
well, then that's only considering trusting trust attacks from the compiler, not trusting trust from nix/guix, linux, your hardware, every program currently running as root, etc.
<ekleog>
which all could pervert the build in a way to introduce a backdoor in the build despite the two coming from completely different compiler lines
<simpson>
ekleog: Note that our tools for checking for bit-reproducibility can be suspect, too. I don't have a link offhand, but there's a great old (fiction?) story where sysadmins can't diagnose a backdoor because their tools are also backdoored.
<ekleog>
indeed, though TBH at this point I'd rather consider the kernel / hardware is backdoored, as it's more generic than the userspace that'll be reimplemented at multiple locations
<ekleog>
as for backdooring the tools… well, I can remember at least one rootkit that replaced the standard unix tools to add secret directories and hide itself