unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Mark H Weaver <mhw@netris.org>
To: "Léo Le Bouter" <lle-bout@zaclys.net>, guix-devel@gnu.org
Subject: Re: [opinion] CVE-patching is not sufficient for package security patching
Date: Tue, 16 Mar 2021 19:19:59 -0400	[thread overview]
Message-ID: <87v99qit39.fsf@netris.org> (raw)
In-Reply-To: <9b9a43a584e2dc70488482fce5931b46abd0e006.camel@zaclys.net>

Hi Léo,

Léo Le Bouter <lle-bout@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


  parent reply	other threads:[~2021-03-16 23:21 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-16 11:10 [opinion] CVE-patching is not sufficient for package security patching Léo Le Bouter
2021-03-16 11:17 ` Jonathan Brielmaier
2021-03-16 11:27   ` Léo Le Bouter
2021-03-16 19:15 ` Leo Famulari
2021-03-16 23:19 ` Mark H Weaver [this message]
2021-03-16 23:49   ` Leo Famulari
2021-03-17 11:54     ` Guix moving too fast? zimoun
2021-03-17  6:07   ` [opinion] CVE-patching is not sufficient for package security patching Léo Le Bouter
2021-03-17  6:21   ` Léo Le Bouter
2021-03-20 11:19   ` Ludovic Courtès
2021-03-22 13:44     ` raingloom
2021-03-23 16:22       ` Joshua Branson
2021-03-23 23:53         ` Mark H Weaver
2021-03-23 17:56       ` Leo Famulari
2021-03-23 22:54       ` Ricardo Wurmus
2021-03-24 19:51         ` Leo Famulari
2021-03-24 20:24           ` Vincent Legoll
2021-03-24 20:32             ` Léo Le Bouter
2021-03-24 20:55             ` Leo Famulari
2021-03-25 14:22           ` Mathieu Othacehe
2021-03-25 18:19             ` Leo Famulari
2021-03-30  8:42           ` Buying AArch64 hardware? Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87v99qit39.fsf@netris.org \
    --to=mhw@netris.org \
    --cc=guix-devel@gnu.org \
    --cc=lle-bout@zaclys.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).