[QA] [Ops] security patches handling

[Gergo Tisza]

On Wed, Jan 25, 2017 at 11:20 AM, Chad Horohoe <chorohoe at wikimedia.org>
wrote:

> - We (me, mostly) need to *drastically* cut down the time it takes to get
> security releases public. Carrying non-master fixes in production should
> be the exception, not the norm. This also helps us keep non-production
> wikis safer (I'm looking at you, beta)
>

Also, third-party wikis. Getting security patches out to them can take a
looong time. The patch in question (T109140) was initially deployed in
March.
Granted, the time security patches spend in hiding tends to be inversely
proportional to their severity; even so, it is not an ideal situation.

Maybe the security release process could be made more collaborative? For
writing a security patch there is a good step-by-step tutorial so
maintainers of the affected part of the codebase can just do it without
placing the burden on security/releng; maybe something like that could be
done for releases as well?

- Using merges/shared git history between deployment branches instead
> of patchfiles would probably simplify a lot of this, needs further thinking
> through though
>

You can always cherry-pick the patches from the old branch which are in
master but not in origin/master. The disadvantage is that it's harder to
tell when a security patch was dropped deliberately vs. lost due to
accident (right now the git history of /srv/patches provides a clear audit
log, when it's properly maintained - that's not always the case but would
be easy to enforce).

- A *clear* owner for any security patches in production (without having
> to dig through Phabricator). This person must be consulted on any
> non-trivial
> conflict, imho.
>

The author field in git?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.wikimedia.org/pipermail/qa/attachments/20170126/ccd10bce/attachment.html>