Christopher Lemmer Webber writes: > Katherine Cox-Buday writes: > >> Tobias Geerinckx-Rice writes: >> >> >>> I think the real and thornier question for GuixSD >>> is: if the recent CPU vulnerabilities require a >>> microcode update to fully mitigate, then how do we >>> square not recommending proprietary globs like >>> this in official channels with giving users all >>> knowledge required to decide for themselves? >> >> Yes, this exactly. >> >> It's a unique (hm, is it?) situation pitting the ideals of copyleft >> against the welfare of users. If an opaque microcode is required to >> successfully mitigate these bugs, what is the moral stance to take? >> >> I don't have an answer and that's why I'm asking here :) > > It seems to me that this is one of those "you need to upgrade some > lowest level firmware which you already didn't have access to in order > to keep your system secure"... I dunno if GuixSD should ship something, > but I wouldn't blame anyone updating their microcode for something this > critical. > My interpretation of the GNU FSDG leads me to believe that GuixSD shouldn't ship anything. Because the opaque microcode update in question is proprietary and necessarily runs on the CPU, we cannot and should not recommend it. See how Libreboot addresses this issue: https://libreboot.org/faq.html#microcode. > That said, if the microcode were free in the first place, this would > probably be a lot easier to deal with? Yes, this would not be a problem. The real problem is with the proprietary and thus harmful nature of Intel's microcode. Even if the FSDG allowed for nonfree firmware in this case, there is no way to verify with certainty that the microcode update does what it claims (and /only/ what it claims, for that matter).