From: Leo Famulari <firstname.lastname@example.org> To: "Léo Le Bouter" <email@example.com> Cc: firstname.lastname@example.org Subject: Re: [opinion] CVE-patching is not sufficient for package security patching Date: Tue, 16 Mar 2021 15:15:03 -0400 [thread overview] Message-ID: <YFEDt/PUd2ZeC6/F@jasmine.lan> (raw) In-Reply-To: <email@example.com> [-- Attachment #1: Type: text/plain, Size: 3198 bytes --] On Tue, Mar 16, 2021 at 12:10:26PM +0100, Léo Le Bouter wrote: > For these reasons, I suggest that we always strive to update packages > to their latest versions and that I think it is security relevant to > always do so. Of course, new code could *introduce* new vulnerabilities > but I am not trying to debate this, it's that to the best of the > upstream's knowledge chances are that the latest version will contain > more security fixes than older versions (if that upstream is actually > maintaining the project). I agree that every new release can be considered to have fixed security problems. Please read the rest of my message while keeping in mind that I have spent *a lot* of time working on security in Guix over the years. We must keep in mind that there are other values besides security. Additionally, this kind of "security" mindset is a somewhat narrow way of considering the problem of secure computing. It's important to remember that security can be modeled with 3 factors: confidentiality, integrity, and availability. The 3rd factor is often overlooked. In terms of making a distro, there is a spectrum of approaches. At one end of the spectrum, there is something like PyPi, which is just a clearinghouse for upstream projects to distribute their code. Everything is always updated to the latest version. It does not provide a working system, even within the narrow world of "just Python"; there are broad incompatibilities among the latest versions of Python programs. On the other end is the approach of Red Hat and Debian. They laboriously filter the upstream software to provide stable operating systems. They do fix security bugs, but only after extensive validation that functionality is not changed. The result is useful but the cost is very high. Guix has always been in the middle, along with other rolling release distros, and I think that's a good place for us to be. With our superior tooling we can be "more stable than rolling release" while also "moving faster than stable". It's instructive to consider the Linux kernel. They release about once a week, and every release fixes serious but unpublicized bugs. At the time they are announcing the release, they are already aware of other serious bugs, that might be fixed in the next release. It sounds terrible, and yet Linux is by far the most popular and useful general-purpose operating system. The world of computing, which is based on Linux, continues to serve our civilization well. That's because the most important thing value in Linux development is to not break anything for users; security is not the top priority, but just another important thing to consider. I think that, as an operating system distro, we must adopt a similar mindset, and be careful not to sacrifice too much for an abstract sense of security based on fixing CVEs, which are an arbitrary system that have little bearing on utility or safety in the real world, which is where security matters. Of course we should fix CVEs, but we must also recognize that rushing too much reduces stability and availability. We have to weigh the costs and benefits every time. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2021-03-16 20:05 UTC|newest] Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-03-16 11:10 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 [this message] 2021-03-16 23:19 ` Mark H Weaver 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 * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=YFEDt/PUd2ZeC6/F@jasmine.lan \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [opinion] CVE-patching is not sufficient for package security patching' \ /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
Code repositories for project(s) associated with this inbox: https://git.savannah.gnu.org/cgit/guix.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.