Sorry for duplicated email..

On Tue, 2021-03-16 at 19:19 -0400, Mark H Weaver wrote:
> If not, it would be good to work toward the goal of making Guix
> usable
> on non-Intel systems.  I'm sorry to say that, in my opinion, your
> proposal would move us in the wrong direction to achieve that goal.

We have been working with Chris Marusich, Efraim and numerous others on
porting GNU Guix to PowerPC 64-bits, I think both are not
contradictory. I have a Talos II desktop at home which once GNU Guix
works on it will be the main machine I will use to contribute to GNU
Guix (along with offloading to other machines for testing on other
archs), so count on me to at the same time keep up on GNU Guix and test
things on PowerPC 64-bits.

I am of course concerned with any blob doing things I don't need (and
introducing security risk) under the hood, that's why (along with
strong software freedom imaginaries) I pre-ordered my RaptorCS Talos II
machine in 2017 and that I have been trying since 2 years to bring
PowerPC 64-bits to GNU Guix (also with numerous other folks who joined
efforts most recently Chris Marusich who've been enormous help!).

But I also want to be realistic that the major security risk in most
computers today probably isnt the Intel ME or Intel AMT and that we
also can do many other things in the system itself that reduces risk
greatly. I'll be honest also, the IBM POWER chips have gotten much less
security review than the Intel or AMD chips recently, so it's not
because there's not as much security drama on IBM POWER that it doesnt
have (maybe even more severe) issues :-)

About the overall security of GNU Guix and the things we can do that
don't involve keeping a fast-paced rythm to updating packages I see few
things, right now GNU Guile is the center of all's GNU Guix security, I
am not sure it received lots of security auditing, it's also written in
part in a memory-unsafe language that is C, so there's probably some
low hanging fruits there once some starts fuzzing it, I'm no big expert
in fuzzing but I may try at some point.

I think we can do many things complementary, prevention (sandboxing),
mitigation (enabling hardening compiler flags, ..), AND code security
patching. The first two don't require we keep a fast paced update
rythm, also we may do the first two especially because we realize we
can't do the latter at all time and I realize that, I just think we
should always try to, at least, that's all.

I am also a bit concerned with the idea that GNU Guix, GNU Shepherd
etc. execute code from arbitrary files in many places, I am not sure
all the security details have been reviewed here, it seems risky to me
to have configuration files that allow executing arbitrary code, also
GNU Guile seems to have a sandboxed evaluation mode, that's good. I
like the freedom of arbitrary code evaluation anywhere gives us, but I
also want to make sure it's actually secure to do so.

Léo