202700+ entries in 0.094s
mircea_popescu: either i get
to use my
tool frist, in which case i can perceive a change ; or else i don't get
to use my
tool first, in which case -- prediction is necessary.
mircea_popescu: phf it's either predict or expose itself.
there's no
third.
mircea_popescu: yes, i might. but i don't ~have
to~ already be using it.
mircea_popescu: yes, but
this idea doesn't scale
the way phf wants it
to scale.
mircea_popescu: because if "patch after used"
then it's created a partition which i can use ; and if "predict"
then
the inf-in-being is rightthere.
phf: mircea_popescu: if rotor4 comes out, must patch again.
there's no inf on our side despite
the process being potentially inf, because we're limited by
time/energy
mircea_popescu: phf and
then keeps patching ? forever ? from behind
the grave ?
phf: i don't
think it's a problem for an arbitrary chain. i was more
thinking lizard hitler patches compiler
to specifically fuck with rotor3 chain
mircea_popescu: the hope
that it'll always find a way
to do what you want it
to do in front of my boundless requests is essentially
the root of government.
mircea_popescu: phf
the rub is
that you're stuck with infinity on one end. you really can't
tell in advance what i'll want your compiler
to do.
phf: i
think
the point is
that you can't design
the process for an arbitraray chain of
transformations
mircea_popescu: ad-hoced it above.
the
thing which
thomson describes, which is a very fundamental "specificly diddlable" process. "man in his cave" sort of
thing.
mircea_popescu: asciilifeform
those are all fine examples of "break out of unary".
mircea_popescu: and
the "not necessarily" sinks it, because now i have what
to compare, and
that's
the end of
that.
mircea_popescu: hey, i proposed unoptimizing compiler for
the role for reasons!
mircea_popescu: need i break out
the math for
this or is it obvious from stating ?
mircea_popescu: and
this sad limitation fundamentally weakens
the process, so
that if i keep building more complex inputs your ability
to make
the prediction weakens (by
the log of
the count, in
the pure case)
mircea_popescu: what does exist is a version whereby
the secret can be built ~on
the basis of~ given inputs.
mircea_popescu: the problem with
this, however, is
that
the magical hash-with-checksum function ~does not exist~. it's part of
trilema sf for a reason.
mircea_popescu: it was class 1 or 2.
this is an equivalent notation of
the
thompson problem for compilers (there's no difference between hashing and compiling in
this sense).
mircea_popescu: phf
the premise ("1 item can be compromised") is
true ;
this however is not a ~systematic~ concern.
the reason it isn't a systematic concern has everything
to do with
the imaginary concept of "the hash with checksum". suppose 1) a hash function existed which 2) contained a secret which 3) allowed
the possessor
to distiguish possible inputs into
two classes and
then on
the basis of
the result know whether
the input
that led
to
trinque: nobody contests
the problem exists; it'd be more interesting
to discuss where
to put it.
phf: that's
the point so far
phf: and
the lack of control means
that your bootstrap machine compiler can do arbitrary
things
to
the binary
phf: in
this case control of
the bootstrap machine is at
the very least equivalent
to "if i compile a source, would
the behavior of
the binary correspond
to what
the compiler specification fully or not"
trinque: phf:
that problem is introduced *by*
the urge
to write your compiler in its own language, neh?
phf: you introduce
the hack in
the original compiler
that you used
to compile
tcc.
the original compiler, having prior knowledge of
the chain, or some arbitrary compilation of chains, will ensure
that
the first
tcc you get will propagate
the hack further down
phf: any arbitrary chain of "i compile
tcc
that i use
to compile gcc
that i use
to compile kernel" can be compromised even if you have full sources, read and understood etc. of
tcc, gcc and kernel.
mircea_popescu: no, no, start over. full statement of
the problem, explicitly
terminated.
ty.
phf: well, i
think
that
the comparison is obscures
the actual point
mircea_popescu: please put a
terminator when you're done and i'ma do my best
to ignore
the interlopers!
mircea_popescu: trinque
they're blisfully unaware of
the power of comparison, which is why
that part of
the discussion keeps being shied away from.
trinque: ties in with asciilifeform's
too
trinque: seems
to underscore
the need
to inspect outputs and comprehend
them
mircea_popescu: let's distinguish
the genuine problem from "sky is falling in pies and nsa owns
thermodynamics"
mircea_popescu: i don't have full control over
turbulent flow, nevertheless fly unmolested. and so following.
mircea_popescu: phf
this is elementarily false. i don't have full control over eg female biology, enjoy full control over my slavegirls.
phf: mircea_popescu: unless you have full control over your bootstrap machine you're not guaranteed
to have full control over your bootstrapped machine.
mircea_popescu: phf now now. don't squirm away. let's have
the discussion. what exactly IS
the concern.
trinque: answer's
trivially yes, but size of
the
thing isn't moot. or do I misrepresent phf?
trinque: !!gettrust
trinque asciilifeform
trinque: just like
the imagined item
trinque: conversation has
to proceed outward for it
to work
phf: mircea_popescu: i'm not saying
that it's going
to be infected. i'm saying
that's what
trust means in a bootstrapping problem. if you're not concerned about
that angle, you can relax
trust requirements significantly.
trinque: yes still have
to apply
the WoT
to whether I can
trust
the man, but if I *do*, it is possible
to be said
that
the man who started from step 1 had
the whole fucker in his head.
ben_vulpes: throw
the nic out, we're going
to shortwave anyways
trinque: no. it is entirely separate from "does
this approach
to bootstrapping work"
trinque: right, so
that's a separate matter
trinque: so
then,
the path is up from
there. I fail
to see
the flaw with it (other
than wrong arch)
trinque being an idiot in
these matters, has a very stupid (and unfinished) scheme in x86-64 asm
phf: gcc has a long living nsa hack
that modifies some pattern in a malicious way, etc.
phf: the machine
that you built your bcc on could already be infected, and
the resulting bcc binary is compromised
mircea_popescu: meanwhile you, catchingwind of
this, go into your
thomspon shrine, say abracadabra and now my kernel is infected with phf-rat ?
mircea_popescu: i
think we're not
talking of
the same
thing. so, i have, for
the sake of argument, a 50k line bcc, which builds c and doesn't optimize. it's my bootstrapping compiler. it runs on musl, say. i fire up a pogo, put
this on, and proceed
to build a kernel during
the next week.
phf: so it's irrelevant if
the bootstrapped code is inspectable
phf: you can design a malicious bootstrapper
that will compromise
the bootstrapped code
phf: mircea_popescu:
trust in bootstrapping problem is a specific concern
that comes from ken
thompson's "reflections on
trusting
trust"
a111: Logged on 2017-02-24 02:36 asciilifeform: veen: let's
try a historical angle. according
to legend, emperor qin shi huangdi (same d00d as known for
taking
the 'immortality pill' and promptly croaking) had a palace with 1,500 rooms. and would not
tell anyone in advance which one he plans
to sleep in on a given night. and which ones he would put cutthroats in, ready
to kill anyone who opens door.
think 'minesweeper.'