Look, any kind of actual work on security requires an actual threat model
and a defined perimeter.
Paranoid delusions won't get you anywhere.
>So you personally vouch for the machine code in the official release not
>containing any hidden surprises at present?
I don't vouch for anything, I don't have to. If you don't like it go
scuttle off to someone else who satisfies you.
But your sha256 invocation is going to solve nothing.
>By the
So you personally vouch for the machine code in the official release not
containing any hidden surprises at present? By the way there is a bug in
the text of the FAQ for installing the xenocara source that clobbers usr
because it's missing a mkdir -p command for an expected directory.
On Thu., Jun
"Schech, C. W. (\"Connor\")" wrote:
> I want to avoid derailing into trusting trust or designing a system
> from scratch. The official build not being portable and the recursion
> it introduces is orthogonal to system integrity.. Adding say, official
> distcc support, and bringing back say, GCC a
I want to avoid derailing into trusting trust or designing a system
from scratch. The official build not being portable and the recursion
it introduces is orthogonal to system integrity.. Adding say, official
distcc support, and bringing back say, GCC avoids that recursion. I am
concerned with simp
Yes, I understand that OpenBSD is self-hosting, and it seems like an
infinite recursion with no base case. The base case is actually the
last version with GCC support that's no longer in the CDN archive. And
the Computer Store stopped carrying the CDs.
Do you really trust that there is enough entr
What you are saying makes no sense.
So then the compiler runs to link these binaries, and you trust it?
Also, it is using various libraries, including libc.so, and you have
to trust those files? But those library routines in there trust all sorts
of other files also, to not be corrupted.
By exte
I don't trust anyone upstream to keep the .o files safe - that's the
central problem - the hardware reliability is an aside from the
central problem, which is that you are creating a "virtual compiler"
for arbitrary programs when you reorder the kernel, which shouldn't be
a "general purpose compile
On 2023/06/14 04:12, Schech, C. W. ("Connor") wrote:
> There's no check of the checksums for all the object files that the
> /rc task consumes
>
> This can be trivially fixed by generating them in, say
>
> In /sys/conf/newvars.sh, add the line:
>
> +sha512 -h /var/db/obj.${id}.sha512 *.o lorder
Den ons 14 juni 2023 kl 06:27 skrev Schech, C. W. ("Connor") <
sch...@gmail.com>:
> There's no check of the checksums for all the object files that the
> /rc task consumes
>
> This can be trivially fixed by generating them in, say
> In /sys/conf/newvars.sh, add the line:
> +sha512 -h /var/db/obj.$
There's no check of the checksums for all the object files that the
/rc task consumes
This can be trivially fixed by generating them in, say
In /sys/conf/newvars.sh, add the line:
+sha512 -h /var/db/obj.${id}.sha512 *.o lorder
above the segment starting with:
cat >vers.c < link kit reordering.
11 matches
Mail list logo
