From: Leo Famulari <leo@famulari.name>
To: Giovanni Biscuolo <g@xelera.eu>
Cc: Guix Devel <guix-devel@gnu.org>,
Raghav Gururajan <rg@raghavgururajan.name>
Subject: Re: A "cosmetic changes" commit that removes security fixes
Date: Mon, 26 Apr 2021 13:32:51 -0400 [thread overview]
Message-ID: <YIb5Q8ojEkq3v/fN@jasmine.lan> (raw)
In-Reply-To: <87tuntasbq.fsf@biscuolo.net>
[-- Attachment #1: Type: text/plain, Size: 2888 bytes --]
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
shape.
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 <leo@famulari.name> 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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2021-04-26 17:33 UTC|newest]
Thread overview: 102+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-22 0:58 A "cosmetic changes" commit that removes security fixes Raghav Gururajan
2021-04-22 2:41 ` Mark H Weaver
2021-04-22 3:17 ` Raghav Gururajan
2021-04-22 4:05 ` Raghav Gururajan
2021-04-22 4:33 ` Mark H Weaver
2021-04-22 5:02 ` Raghav Gururajan
2021-04-22 17:21 ` Mark H Weaver
2021-04-22 17:40 ` Another misleading commit log (was Re: A "cosmetic changes" commit that removes security fixes) Mark H Weaver
2021-04-22 20:06 ` Léo Le Bouter
2021-04-22 21:24 ` Ricardo Wurmus
2021-04-22 21:33 ` Mark H Weaver
2021-04-26 17:17 ` Ludovic Courtès
2021-04-28 16:43 ` Criticisms of my "tone" " Mark H Weaver
2021-04-28 17:55 ` Leo Famulari
2021-04-28 20:24 ` Pjotr Prins
2021-04-29 6:54 ` Joshua Branson
2021-04-29 9:26 ` Léo Le Bouter
2021-04-29 15:30 ` Matias Jose Seco Baccanelli
2021-04-30 0:57 ` aviva
2021-05-01 17:02 ` Giovanni Biscuolo
2021-05-01 20:07 ` Leo Prikler
2021-05-01 22:12 ` Mark H Weaver
2021-05-01 22:54 ` Mark H Weaver
2021-05-01 23:15 ` Leo Prikler
2021-05-02 3:13 ` Mark H Weaver
2021-05-02 10:31 ` Leo Prikler
2021-05-03 9:00 ` Mark H Weaver
2021-05-03 9:59 ` Leo Prikler
2021-05-03 17:00 ` Mark H Weaver
2021-05-02 4:17 ` 宋文武
2021-05-02 4:31 ` Leo Famulari
2021-05-02 6:26 ` 宋文武
2021-05-02 15:01 ` Leo Prikler
2021-05-02 19:29 ` Mark H Weaver
2021-05-02 20:09 ` Leo Prikler
2021-05-02 21:02 ` Mark H Weaver
2021-05-02 21:58 ` Leo Prikler
2021-05-02 20:59 ` Ludovic Courtès
2021-05-02 21:23 ` Mark H Weaver
[not found] ` <87czu9sr9k.fsf@outlook.com>
2021-05-02 4:33 ` 宋文武
2021-04-22 21:51 ` Another misleading commit log " Ludovic Courtès
2021-04-22 21:49 ` A "cosmetic changes" commit that removes security fixes Raghav Gururajan
2021-04-24 8:09 ` Mark H Weaver
2021-04-30 0:58 ` aviva
2021-04-22 18:37 ` Leo Famulari
2021-04-22 18:48 ` Mark H Weaver
2021-04-22 21:50 ` Raghav Gururajan
2021-04-22 4:08 ` Mark H Weaver
2021-04-22 11:39 ` 宋文武
2021-04-22 13:28 ` Mark H Weaver
2021-04-22 20:01 ` Léo Le Bouter
2021-04-22 21:08 ` Christopher Baines
2021-04-22 21:09 ` Leo Prikler
2021-04-22 21:21 ` Mark H Weaver
2021-04-23 17:52 ` Maxim Cournoyer
2021-04-23 18:00 ` Raghav Gururajan
2021-04-23 18:38 ` Maxim Cournoyer
2021-04-23 22:06 ` Raghav Gururajan
2021-04-23 18:50 ` Léo Le Bouter
2021-04-23 19:15 ` Leo Prikler
2021-04-23 19:18 ` Leo Famulari
2021-04-23 19:33 ` Léo Le Bouter
2021-04-23 20:12 ` Leo Famulari
2021-04-26 17:06 ` Giovanni Biscuolo
2021-04-26 17:32 ` Leo Famulari [this message]
2021-04-26 21:56 ` Giovanni Biscuolo
2021-04-26 23:01 ` Leo Famulari
2021-04-24 7:46 ` Mark H Weaver
2021-04-26 14:59 ` Léo Le Bouter
2021-04-26 15:23 ` Tobias Geerinckx-Rice
2021-04-26 17:21 ` Ludovic Courtès
2021-04-26 20:07 ` Pjotr Prins
2021-04-26 17:46 ` Léo Le Bouter
2021-04-28 15:52 ` Marius Bakke
2021-04-29 9:13 ` Léo Le Bouter
2021-04-29 11:46 ` Leo Prikler
2021-04-29 11:57 ` Léo Le Bouter
2021-04-29 11:41 ` Arun Isaac
2021-04-29 12:44 ` Pierre Neidhardt
2021-04-29 14:14 ` Pjotr Prins
2021-04-30 17:40 ` Pierre Neidhardt
2021-04-30 19:56 ` Pjotr Prins
2021-05-01 7:23 ` Arun Isaac
2021-05-01 12:40 ` Pjotr Prins
2021-05-01 9:15 ` Pierre Neidhardt
2021-05-01 10:18 ` Yasuaki Kudo
2021-05-03 7:18 ` Pierre Neidhardt
2021-05-01 14:50 ` Giovanni Biscuolo
2021-05-03 7:25 ` Pierre Neidhardt
2021-05-04 2:18 ` Bengt Richter
2021-05-04 6:55 ` Pierre Neidhardt
2021-05-04 15:43 ` Ludovic Courtès
2021-05-06 17:18 ` Pierre Neidhardt
2021-04-29 16:21 ` Arun Isaac
2021-04-26 19:31 ` Léo Le Bouter
2021-04-27 18:10 ` Andreas Enge
-- strict thread matches above, loose matches on Subject: below --
2021-04-21 21:11 Mark H Weaver
2021-04-21 21:24 ` Mark H Weaver
2021-04-21 22:22 ` Tobias Geerinckx-Rice
2021-04-21 23:45 ` Raghav Gururajan
2021-04-21 22:16 ` Leo Prikler
2021-04-21 22:52 ` 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
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=YIb5Q8ojEkq3v/fN@jasmine.lan \
--to=leo@famulari.name \
--cc=g@xelera.eu \
--cc=guix-devel@gnu.org \
--cc=rg@raghavgururajan.name \
/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).