[Top][All Lists]

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

Re: Security patching and the branching workflow: a new security-updates

From: Léo Le Bouter
Subject: Re: Security patching and the branching workflow: a new security-updates branch
Date: Fri, 26 Mar 2021 23:30:22 +0100
User-agent: Evolution 3.34.2

On Fri, 2021-03-26 at 22:13 +0000, Christopher Baines wrote:
> Can you clarify what specific problem or problems you're proposing
> this
> security-updates branch to address?

Substitute availability of security updates when they are released,
without causing big rebuilds on master for users before the build farm
had time to produce substitutes.

> You mention applying and backporting patches is lots of work, and
> uncertainty around whether grafts work in particular
> situations.

Also that some times backporting is just not possible because security
fixes are not properly labeled upstream as security-relevant and manual
review of each and every commit is just not viable.

> Personally I think staging and core-updates are quite a bit of work,
> and
> adding more complexity to the process involves more work in my
> mind. Additionally, this isn't going to provide more information
> about
> areas where grafts can't be used (if those exist).

I understand. There's lot of uncertainty on how grafts work exactly for
me and in what situations they work and what situations they do not.
The only way I am certain some security fix is correctly applied in GNU
Guix is when the vulnerable version of the package is not packaged at
all anymore in GNU Guix.

> Now the software involved is getting better at rapidly building
> things
> for substitutes, personally I see a way forward through trying to
> measure and potentially increase the rate of change for outputs in
> general. Going faster also involves more work probably, but in terms
> of
> the process, that might just mean that updates to more packages can
> be
> merged to master directly, without sitting on a non-master branch.

I would like this, merging things to master directly when we feel it is
the right thing would be what I would like to do. Even if it causes big
world rebuilds, when we can't graft.

There's another thing I saw that was ongoing but can't remember where,
that 'guix pull' could hold off updating to newer revisions unless
substitutes are available.

Thanks for your input.

Attachment: signature.asc
Description: This is a digitally signed message part

reply via email to

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