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

[Christopher Baines <mail@cbaines.net>]

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


Léo Le Bouter <lle-bout@zaclys.net> writes:

> There is two ways to ship security fixes to packages:
>
> 1. Update to a patched version if upstream provides one
> 2. Apply or backport individual patches to fix the issues in the
> shipped version
>
> Grafts are most reliable for 2. but there's cases where using 2. is
> lots of work and we can't afford that right now. An example is
> ImageMagick where not all security issues get a CVE so essentially the
> only way of getting security fixes is to fetch master or get the latest
> release.
>
> There's also some types of packages where we are not sure whether we
> can use grafting or not, such as Python ones.
>
> For these reasons, I would like to propose a new branch called
> security-updates that would be based on master where we queue security
> fixes that introduce any arbitrary number of rebuilds without using
> grafts.
>
> We would merge the security-updates branch as soon as there is complete
> substitute availability for the branch and it's future merged version
> within master.
>
> The downsides of this approach are that:
>
> 1. Substitutes availability does not mean we can ship the updates
> quickly because this might mean hundreds of megabytes if not gigabytes
> of new substitutes to fetch to actually get the update.
> 2. Users that don't use substitutes will suffer big rebuilds on each
> security update shipped through this branch.
>
> For these reasons, grafting should still be preferred when possible,
> but there are cases where it cannot be used for technical reasons or
> lack of resources reasons but we still must provide a fix quickly.
>
> What do you think?

Can you clarify what specific problem or problems you're proposing this
security-updates branch to address?

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

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).

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]