tag:dreamwidth.org,2009-05-03:257103akiakiaki2017-01-27T03:22:33Ztag:dreamwidth.org,2009-05-03:257103:249740scriptworker 2.0.02017-01-27T03:22:33Z2017-01-27T03:22:33Zpublic0<p>
Since my <a href="http://escapewindow.dreamwidth.org/249409.html">last blog post</a>, we've released <a href="https://github.com/mozilla-releng/scriptworker/releases">seven more 1.0.0bX betas and a 2.0.0 final</a>.
</p><p>
Since then, we've added beetmover-, balrog- and pushapk- scriptworker instance types, with chain of trust support, and upgraded them off of the now-retired 0.7.x branch. We now have a <code>live_backing.log</code> for easier treeherder log viewing. Our configs are now recursively frozen for more immutable goodness, and we have an unfreeze function as well. We're now running scriptworker instances against tier1 linux and android Firefox nightlies (and developer edition). And we have more contributors and contributions, including <a href="https://github.com/mozilla-releng/scriptworker/releases/tag/1.0.0b3">two</a> <a href="https://github.com/mozilla-releng/scriptworker/releases/tag/1.0.0b8">releases</a> pushed by <a href="http://jordan-lund.ghost.io/">jlund</a> and <a href="https://github.com/JohanLorenzo">jlorenzo</a>.
</p><p>
Why 2.0.0? First, we introduced some <a href="https://github.com/mozilla-releng/scriptworker/pull/53#issuecomment-273249423">backwards incompatible changes</a> , and decided that the spirit of <a href="http://semver.org/#spec-item-5">semver rule 5</a> included 1.0.0 betas. Why not 2.0.0b1? We're in production, tier 1, so let's stop futzing with betas and call it 2.0.0. The major version should be incrementing fairly rapidly, since we have a number of changes in the pipeline that may be backwards incompatible. Skipping 1.0.0 and getting used to larger major version numbers seems like a good first step.
</p><p>
Thanks Johan and Jordan, <a href="https://twitter.com/mihaitabara">Mihai</a> for the beetmover and balrog work, <a href="https://github.com/ray-pankaj">Pankaj Ahuja</a> for the recursive freeze/unfreeze functions, and a bunch of other people on the Releng and Taskcluster teams for all their help!
<p></p></p><br /><br /><img src="https://www.dreamwidth.org/tools/commentcount?user=escapewindow&ditemid=249740" width="30" height="12" alt="comment count unavailable" style="vertical-align: middle;"/> commentstag:dreamwidth.org,2009-05-03:257103:249409scriptworker 1.0.0b1 - chain of trust verification2016-11-15T04:34:14Z2016-11-15T04:34:14Zpublic0Tl;dr: I just shipped scriptworker 1.0.0b1 (<a href="https://github.com/mozilla-releng/scriptworker/blob/1.0.0-beta1/CHANGELOG.md">changelog</a>) (<a href="https://github.com/mozilla-releng/scriptworker/releases/tag/1.0.0-beta1">github</a>) (<a href="https://pypi.python.org/pypi/scriptworker/1.0.0b1">pypi</a>).<br />
This enables chain of trust verification for signing scriptworkers.
<h2>chain of trust</h2>
<p>
<a href="http://escapewindow.dreamwidth.org/248127.html">As I mentioned before</a>, scriptworkers allow for more control and auditability around sensitive release-oriented tasks in Taskcluster. The Chain of Trust allows us to trace requests back to the tree and verify each previous task in the chain.
</p><p>
We have been generating Chain of Trust artifacts for a while now. These are gpg-signed json blobs with the task definition, artifact shas, and other information needed to verify the task and follow the chain back to the tree. However, nothing has been verifying these artifacts until now.
</p><p>
With the latest scriptworker changes, scriptworker follows and verifies the chain of trust before proceeding with its task. If there is any discrepancy in the verification step, it marks the task invalid before proceeding further. This is effectively a second factor to verify task request authenticity.
</p>
<h2>scriptworker 1.0.0b1</h2>
<p>
1.0.0b1 is largely two pull requests: <a href="https://github.com/mozilla-releng/scriptworker/pull/23">scriptworker.yaml</a>, which allows for more complex, commented config, and <a href="https://github.com/mozilla-releng/scriptworker/pull/25">chain of trust verification</a>, which grew a little large (275k patch !).
</p><p>
This is running on signing scriptworkers which sign <a href="https://treeherder.mozilla.org/#/jobs?repo=date&filter-searchStr=nightly">nightlies on date-branch</a>. We still need to support and update the other scriptworker instance types to enable end-to-end chain of trust verification.
</p><br /><br /><img src="https://www.dreamwidth.org/tools/commentcount?user=escapewindow&ditemid=249409" width="30" height="12" alt="comment count unavailable" style="vertical-align: middle;"/> commentstag:dreamwidth.org,2009-05-03:257103:248851scriptworker 0.9.02016-11-01T18:27:13Z2016-11-01T18:27:13Zpublic0<p>
I was planning for the 0.9.0 release to revolve around Chain of Trust verification. However, some pexpect async issues reared their ugly head. The fix is in
scriptworker 0.9.0 (<a href="https://github.com/mozilla-releng/scriptworker/blob/0.9.0/CHANGELOG.md">changelog</a>) (<a href="https://github.com/mozilla-releng/scriptworker/releases/tag/0.9.0">github</a>) (<a href="https://pypi.python.org/pypi/scriptworker/0.9.0">pypi</a>) ;
Chain of Trust verification will land in the next release, likely 1.0.0.
</p>
<h2>scriptworker 0.9.0</h2>
<p>
While working on the chain of trust verification code, I noticed that more than half the time I'd hit <a href="https://github.com/mozilla-releng/scriptworker/issues/21">async pexpect errors during testing</a> (we used async pexpect to sign gpg keys in the background).
</p><p>
This was just a personal annoyance until <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1311111">bug 1311111 - please start landing docker-worker pubkeys in gpg repo</a> landed, and production signing scriptworker instances barfed on async pexpect errors.
</p><p>
The solution either called for fixing the upstream bug, or pulling the gpg homedir creation/rebuild out into its own process. <a href="https://github.com/mozilla-releng/scriptworker/pull/22">We opted for the latter solution</a>; so far this seems to be working much more smoothly.
</p><br /><br /><img src="https://www.dreamwidth.org/tools/commentcount?user=escapewindow&ditemid=248851" width="30" height="12" alt="comment count unavailable" style="vertical-align: middle;"/> commentstag:dreamwidth.org,2009-05-03:257103:248736scriptworker 0.8.2 and 0.7.22016-10-29T07:34:38Z2016-10-29T07:34:38Zpublic0<p>
Tl;dr: I shipped
scriptworker 0.8.2 (<a href="https://github.com/mozilla-releng/scriptworker/blob/0.8.2/CHANGELOG.md">changelog</a>) (<a href="https://github.com/mozilla-releng/scriptworker/releases/tag/0.8.2">github</a>) (<a href="https://pypi.python.org/pypi/scriptworker/0.8.2">pypi</a>)
and
scriptworker 0.7.2 (<a href="https://github.com/mozilla-releng/scriptworker/blob/0.7.2/CHANGELOG.md">changelog</a>) (<a href="https://github.com/mozilla-releng/scriptworker/releases/tag/0.7.2">github</a>) (<a href="https://pypi.python.org/pypi/scriptworker/0.7.2">pypi</a>)
last Monday (Oct 24), and am only now getting around to blogging about them.
</p><p>
These are patch releases, and fix the polling loop.
</p>
<h2>scriptworker 0.8.2</h2>
<p>
The fix for <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1310120">bug 1310120 - puppet reinstalls scriptworker on every run</a> exposed some scriptworker loop bugs: because puppet was restarting scriptworker regularly, we never had a long-running instance before.
</p><p>
<a href="http://relengofthenerds.blogspot.com/">:kmoir</a> and <a href="http://blog.drapostles.org/">:Callek</a> noticed that signing scriptworker wasn't signing (nagios alerts on stuck queues are pending =\ ). It was clear that while git polling was continuing on its merry way, the task polling was dying fairly quickly. We also needed more logging around fatal exceptions.
</p><p>
<a href="https://github.com/mozilla-releng/scriptworker/pull/18">I addressed these issues in scriptworker 0.8.2</a>. We also have our <a href="https://github.com/mozilla-releng/scriptworker/pull/19">third scriptworker contributor</a>, <a href="https://mozillians.org/en-US/u/jlorenzo/">:jlorenzo</a>! (<a href="http://jordan-lund.ghost.io/">:jlund</a> was #2)
</p>
<h2>
scriptworker 0.7.2
</h2><p>
Since we already had the 0.7.1 release to help other scriptworker instance types from having to deal with the churn from pre-1.0 changes, I backported the 0.8.2 fixes to the <a href="https://github.com/mozilla-releng/scriptworker/tree/0.7.x">0.7.x branch</a> and released 0.7.2 off of it. This involved enough merge conflicts that I'm hoping to avoid too many more 0.7.x releases.
</p><br /><br /><img src="https://www.dreamwidth.org/tools/commentcount?user=escapewindow&ditemid=248736" width="30" height="12" alt="comment count unavailable" style="vertical-align: middle;"/> commentstag:dreamwidth.org,2009-05-03:257103:248471scriptworker 0.8.1 and 0.7.12016-10-18T16:47:15Z2016-10-18T16:47:15Zpublic0<p>
Tl;dr: I just shipped
scriptworker 0.8.1 (<a href="https://github.com/mozilla-releng/scriptworker/blob/0.8.1/CHANGELOG.md">changelog</a>) (<a href="https://github.com/mozilla-releng/scriptworker/releases/tag/0.8.1">github</a>) (<a href="https://pypi.python.org/pypi/scriptworker/0.8.1">pypi</a>)
and
scriptworker 0.7.1 (<a href="https://github.com/mozilla-releng/scriptworker/blob/0.7.1/CHANGELOG.md">changelog</a>) (<a href="https://github.com/mozilla-releng/scriptworker/releases/tag/0.7.1">github</a>) (<a href="https://pypi.python.org/pypi/scriptworker/0.7.1">pypi</a>)
<br />
These are patch releases, and are currently the only versions of scriptworker that work.
</p>
<h2>scriptworker 0.8.1</h2>
<p>
The json, embedded in the Azure XML, now contains a new property, <a href="https://github.com/taskcluster/taskcluster-queue/pull/124">hintId</a>. Ideally this wouldn't have broken anything, but I was <a href="https://github.com/mozilla-releng/scriptworker/pull/17/commits/d782b04c7d776bcf73c9290b8f7f41e8a7d9124c#diff-5d33f90e79e58e194621c66f85fe58a1L120">using that json dict as kwargs</a>, rather than explicitly passing <code>taskId</code> and <code>runId</code>. This means that older versions of scriptworker no longer successfully poll for tasks.
</p><p>
<a href="https://github.com/mozilla-releng/scriptworker/pull/17">This is now fixed in scriptworker 0.8.1</a>.
</p>
<h2>
scriptworker 0.7.1
</h2><p>
Scriptworker 0.8.0 made some non-backwards-compatible changes to its config format, and there may be more such changes in the near future. To simplify things for other people working on scriptworker, I suggested they stay on 0.7.0 for the time being if they wanted to avoid the churn.
</p><p>
To allow for this, I created a <a href="https://github.com/mozilla-releng/scriptworker/tree/0.7.x">0.7.x branch</a> and released 0.7.1 off of it. Currently, 0.8.1 and 0.7.1 are the only two versions of scriptworker that will successfully poll Azure for tasks.
</p><br /><br /><img src="https://www.dreamwidth.org/tools/commentcount?user=escapewindow&ditemid=248471" width="30" height="12" alt="comment count unavailable" style="vertical-align: middle;"/> commentstag:dreamwidth.org,2009-05-03:257103:248127scriptworker 0.8.02016-10-13T19:10:27Z2016-10-13T19:10:27Zpublic0<p>
Tl;dr: I just shipped scriptworker 0.8.0 (<a href="https://github.com/mozilla-releng/scriptworker/blob/0.8.0/CHANGELOG.md">changelog</a>) (<a href="http://scriptworker.readthedocs.io">RTD</a>) (<a href="https://github.com/mozilla-releng/scriptworker/releases/tag/0.8.0">github</a>) (<a href="https://pypi.python.org/pypi/scriptworker/">pypi</a>).<br />
This is a non-backwards-compatible release.
</p>
<h2>background</h2>
<p>
By design, taskcluster workers are very flexible and user-input-driven. This allows us to put CI task logic in-tree, which means developers can modify that logic as part of a try push or a code commit. This allows for a smoother, self-serve CI workflow that can ride the trains like any other change.
</p><p>
However, a secure release workflow requires certain tasks to be less permissive and more auditable. If the logic behind code signing or pushing updates to our users is purely in-tree, and the related checks and balances are also in-tree, the possibility of a malicious or accidental change being pushed live increases.
</p><p>
Enter scriptworker. Scriptworker is a limited-purpose taskcluster worker type: each instance can only perform one type of task, and validates its restricted inputs before launching any task logic. The scriptworker instances are maintained by Release Engineering, rather than the Taskcluster team. This separates roles between teams, which limits damage should any one user's credentials become compromised.
</p>
<h2>
scriptworker 0.8.0
</h2><p>
The past several releases have included changes involving the <code>chain of trust</code>. Scriptworker 0.8.0 is the first release that enables gpg key management and chain of trust signing.
</p><p>
An upcoming scriptworker release will enable upstream chain of trust validation. Once enabled, scriptworker will fail fast on any task or graph that doesn't pass the validation tests.
</p><br /><br /><img src="https://www.dreamwidth.org/tools/commentcount?user=escapewindow&ditemid=248127" width="30" height="12" alt="comment count unavailable" style="vertical-align: middle;"/> comments