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

["Léo Le Bouter" <lle-bout@zaclys.net>]

[-- Attachment #1: Type: text/plain, Size: 2122 bytes --]

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.
Léo

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]