[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A "cosmetic changes" commit that removes security fixes

From: Leo Famulari
Subject: Re: A "cosmetic changes" commit that removes security fixes
Date: Mon, 26 Apr 2021 13:32:51 -0400

On Mon, Apr 26, 2021 at 07:06:33PM +0200, Giovanni Biscuolo wrote:
> Just to understand: /if/ at any point in time a user is able to afford
> the effort to build the entire core-updates /or/ staging branch she
> should be confident the result is state-of-the-art secure.  Am I wrong
> with this assumption?

Unfortunately your assumption is incorrect.

We do not apply security updates to the core-updates branch, except what
comes via `git merge master`, which only happens in the final stages of
the cycle.

Core-updates is not expected to be "buildable", let alone "secure",
until the end of the core-updates cycle when we start to whip it into

That branch is just a place to push updates of core packages, so that we
don't duplicate effort or lose track of updates.

Nevertheless, we should never remove security patches without a
corresponding package update, done in a single atomic commit. That's not
how we work.

If there is some documentation or messaging that suggests that anyone
should ever use the core-updates branch, please let us know and we will
fix that. The only branch you should use is the master branch, unless
you are testing something as a developer
> Leo Famulari <> writes:
> > I do think that Mark is being hyperbolic about the wip-gnome branch. The
> > name says "work in progress" and we don't hold those branches to a high
> > standard.
> I understand your point but please consider that /unless/ a wip-branch
> is private (or privately shared out-of-Guix-git) that branch it's a
> pubblic collective work in progress and sometimes (seldom? often? I
> really don't know) that work could be completed by someone else, so even
> in wip- branches committers should exercise some degree of discipline,
> especially when dealing with "commit message completeness" and more with
> security related patches.  In other words, IMHO a certain degree of
> safety must be assured also on wip- branches.
> Probably the policy about wip-branches, whatever it is ("do what you
> want" or something in line with my comments above), should be documented
> in the contributing section of the Guix manual.

I did not mean to suggestthat wip-* branches should not be secure but,
again, they are only works in progress. They do not even have a stable
Git history, due to rebasing, which breaks the Guix code authentication
mechanism. So, if you try to use them, you will have to use `guix pull
--allow-downgrades` and then all bets are off in terms of security.

These branches are merely a way for developers to share their work with
each other.

> OK but please consider that /if/ Guix cannot "update GNOME in Guix" for
> whatever reason, GNOME should not be updated.

I don't understand this. It seems tautological that if we cannot update
GNOME, then GNOME should not be updated.

Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]