all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Mark H Weaver <mhw@netris.org>
To: Leo Famulari <leo@famulari.name>, zimoun <zimon.toutoune@gmail.com>
Cc: Guix-devel <guix-devel@gnu.org>
Subject: Re: New “ungrafting” branch
Date: Mon, 14 Dec 2020 15:03:16 -0500	[thread overview]
Message-ID: <87v9d4rw80.fsf@netris.org> (raw)
In-Reply-To: <X9eP0m2LUqeFdMVD@jasmine.lan>

Hi Leo,

Leo Famulari <leo@famulari.name> writes:

> When we added the recursive grafting feature, we intended to use it to
> deploy urgent security updates quickly, but we also intended to
> "ungraft" quickly, maybe in a week or two. We never planned to keep
> packages grafted for several months as we do now — grafts were
> considered a necessary but unfortunate violation of the functional
> packaging model.

I disagree that grafts are a violation of the functional packaging
model.  The only violations of the functional package model that I'm
aware of are cases where packages fail to build deterministically.  In
other words, if a set of packages build deterministically, i.e. if the
process to build them is a mathematical function, then it will still be
a mathematical function when grafts are added.

However, one potential issue with grafting is that packages are _built_
against the original (buggy) packages, and then store references to
those buggy packages are later replaced (via copying, not mutation) with
references to their replacements.  In some cases, that might not have
the same result as building against the replacements to begin with.

So, it's still a mathematical function (assuming all packages build
deterministically), but not necessarily the same function as if normal
upgrades had been done instead of grafts.  That's the main issue with
grafts that I'm aware of.

One particular case where there's a difference is if there are any
references to grafted packages in build outputs that the reference
scanner is unable to find, e.g. references within compressed files, or
references encoded in UTF-16.

Even without grafts, these hidden references can be a problem, because
if *all* references to a dependency are invisible to the reference
scanner, then the dependency could be deleted by the garbage collector,
leaving those references dangling.

With grafts, the problem of these hidden references becomes far more
severe, because the hidden references will not be rewritten by the
grafting process, and thus references to packages with security flaws
could remain and be used at run time.  This is not a violation of the
functional packaging model, though.

Does that make sense?

      Regards,
        Mark


  reply	other threads:[~2020-12-14 20:04 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-08 11:29 New “ungrafting” branch Ludovic Courtès
2020-12-08 14:13 ` zimoun
2020-12-08 14:17   ` Andreas Enge
2020-12-08 18:20   ` Leo Famulari
2020-12-14 10:32     ` zimoun
2020-12-14 16:16       ` Leo Famulari
2020-12-14 20:03         ` Mark H Weaver [this message]
2020-12-14 21:00           ` Leo Famulari
2020-12-18 11:29             ` Andreas Enge
2020-12-18  2:33           ` zimoun
2020-12-08 19:02 ` Christopher Baines
2020-12-14  9:52   ` Ludovic Courtès
2020-12-10 23:13 ` Maxim Cournoyer
2021-01-15  5:57 ` Mark H Weaver
2021-01-15 21:02   ` Leo Famulari
2021-01-21 11:15     ` Ludovic Courtès
2021-01-21 21:33       ` Leo Famulari

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=87v9d4rw80.fsf@netris.org \
    --to=mhw@netris.org \
    --cc=guix-devel@gnu.org \
    --cc=leo@famulari.name \
    --cc=zimon.toutoune@gmail.com \
    /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 external index

	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.