Hi Léo,
Léo Le Bouter <lle-b...@zaclys.net> writes:
> I would like to share some opinion I have on CVE-patching for non-
> rolling release GNU/Linux distributions and why we should strive to
> always update to the latest available releases or always follow
> upstream supported release series and never backport patches ourselves
> in most cases (some upstreams may have really good practices but these
> are rare).
>
> A lot of security issues are patched silently in upstream projects
> without ever getting a CVE, security issues may not be labeled as such
> by upstreams for various reasons (fear of shame, belief to patch
> something with no security impact while it has, bizarre security
> through obscurity policy, ..).
... and I'll add that it can be a lot of work to evaluate, for a given
bug, whether or not that bug is exploitable.
Anyway, I agree that bugs fixed upstream are sometimes exploitable, even
when they have not been explicitly identified as security flaws, and
that this is a valid argument in favor of keeping our packages updated
to the latest release.
That said, I strongly disagree that we should "never backport patches
ourselves in most cases". The only way to do that, while addressing
security flaws, would be to promptly update even our lowest-level
libraries in response to CVEs, of which there is a steady stream.
Anyone with experience working on the 'staging' or 'core-updates'
branches in Guix, or in the release process of Debian, will immediately
recognize this proposal to be unrealistic. In practice, updating
low-level or even mid-level libraries tends to cause breakage. This
kind of integration breakage happens quite frequently, even on
x86_64-linux, the architecture that most developers work on.
It's *much* worse on other architectures. New upstream releases quite
regularly cause breakage on less popular architectures. It is often
left to distros such as Debian to fix these problems.
Since you're interested in security, I'll now remind you that *all*
modern Intel systems include another little computer inside them called
the Management Engine, which is always on when the machine is plugged in
(even when the computer is "off"), has it's own memory that the main CPU
cannot see, runs a proprietary OS that the user cannot replace, has full
access to the RAM and disk of the machine, and can talk to the network
without the main CPU even seeing those packets.
Are you comfortable with this?
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.
In my experience, Guix is already moving far too fast to be usable on
less popular architectures. I have some knowledge of this. Years ago,
I made a serious effort to make Guix usable on non-Intel systems. When
Guix was young, I initiated its first two ports to non-Intel
architectures: mips64el-linux and armhf-linux, and I tried to actually
use Guix on those systems in practice. I found that my system was very
frequently broken by upstream updates, and that we didn't have nearly
enough developer energy to keep up with fixing those problems.
I've come to believe that having Guix work well on non-Intel systems is,
in practice, incompatible with the rate at which we update our packages.
I'm not sure that even Debian would have enough energy to keep less
popular architecures working well, given our practices. I raised this
issue on guix-devel a few times over the years, but it became clear that
the desire in this community to keep packages aggressively updated far
outweighs any interest in supporting non-Intel systems.
Ultimately, I gave up. In my opinion, Guix has never achieved usability
as a desktop system on non-Intel systems. Therefore, the Guix community
is unable to attract many developers who want a distro that supports
non-Intel systems well. Our community has thus become dominated by
Intel users, and there's unsufficient political will to adopt policies
that would enable us to provide a usable system for non-Intel users.
What do you think?
Regards,
Mark
