<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jan 25, 2017 at 11:20 AM, Chad Horohoe <span dir="ltr"><<a href="mailto:chorohoe@wikimedia.org" target="_blank">chorohoe@wikimedia.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>- We (me, mostly) need to *drastically* cut down the time it takes to get<br></div><div>security releases public. Carrying non-master fixes in production should</div><div>be the exception, not the norm. This also helps us keep non-production</div><div>wikis safer (I'm looking at you, beta)</div></div></div></blockquote><div><br></div><div>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.</div><div>Granted, the time security patches spend in hiding tends to be inversely proportional to their severity; even so, it is not an ideal situation.</div><div><br></div><div>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?  </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>- Using merges/shared git history between deployment branches instead</div><div>of patchfiles would probably simplify a lot of this, needs further thinking</div><div>through though</div></div></div></blockquote><div><br></div><div>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).</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>- A *clear* owner for any security patches in production (without having</div><div>to dig through Phabricator). This person must be consulted on any non-trivial</div><div>conflict, imho.</div></div></div></blockquote><div><br></div><div>The author field in git?</div></div></div></div>