1.0.0b1: chain of trust verification #25

Merged
merged 140 commits into from Nov 15, 2016

Projects

None yet

3 participants

@escapewindow
Member

This pull request is not ready for merging; I just wanted to get some preliminary feedback/review as I work on tests and deployment. I'm going to be adding full unittest coverage in the cot-verify-test branch.

To test manually, install scriptworker in your virtualenv via python setup.py develop (from the cot-verify branch), and:

scriptworker/test/data/verify_cot.py SIGNING_TASK_ID

Where the signing task id is from a date non-l10n Ns, e.g.

scriptworker/test/data/verify_cot.py OIy42W0cQPqGbYZEE9NduQ

L10n and other scriptworker instance support will come in later 1.x releases.

@jonasfj, does scriptworker.cot.verify look sane? The main function is verify_chain_of_trust.
The config values I reference are here.

@JohanLorenzo, @lundjordan : this patch is 161k, before I add all the unittest coverage for scriptworker.cot.verify. a) sorry!!!, b) if you prefer a different form of code review (meeting?), or if you want to split up the task, or if you have any questions... let me know. I'd like to make this as smooth as possible.

escapewindow added some commits Oct 14, 2016
@escapewindow escapewindow clean up cot.py a bit 21f1527
@escapewindow escapewindow check interactive docker worker 5a7961f
@escapewindow escapewindow classify_worker_type 8670ba3
@escapewindow escapewindow is_try 111e532
@escapewindow escapewindow docker image sha allowlists, hacky first version e5377b1
@escapewindow escapewindow traceback -> log.critical(*args, exc_info=1) 3977b61
@escapewindow escapewindow start on built graph format e181beb
@escapewindow escapewindow get_task_id and get_run_id dca4b23
@escapewindow escapewindow possibly build task dict 7e6f50b
@escapewindow escapewindow removed the infinite loop! fc3fb89
@escapewindow escapewindow docstrings; add unsignedArtifacts hack; clean up 61c6006
@escapewindow escapewindow 100% task coverage 9165e66
@escapewindow escapewindow add 'decision' info to each cot graph dependency.
We're going to have to match each task to its decision task; this is
complicated by the fact that docker-image tasks have a different
decision task than the other tasks in the graph.  We could look up each
decision task from the task definition each time, but this is faster.

To do this I had to sort the decision task first in the
`build_task_dependencies` loop, and I turned the `dependencies` dict
into a nested dict.

This assumes that each Chain of Trust graph is going to have at least
one decision task.  Per #tcmigration this is a good assumption.
bdc78f8
@escapewindow escapewindow allow for passing valid artifact task ids to download_artifacts 3dace47
@escapewindow escapewindow download_cot_artifacts 0bf2ebb
@escapewindow escapewindow verify_cot_signature 268bdf5
@escapewindow escapewindow 100% gpg coverage 18232e0
@escapewindow escapewindow wip before splitting out cot into objects 2268e37
@escapewindow escapewindow ChainOfTrust and LinkOfTrust objects 3bf977b
@escapewindow escapewindow switch helper functions to using chain of trust object 0c4503c
@escapewindow escapewindow guess_task_type f9ed2a8
@escapewindow escapewindow get_artifact_url and is_try for links 9df6353
@escapewindow escapewindow download_cot_artifacts 13bde6d
@escapewindow escapewindow split scriptworker.cot into scriptworker.cot.generate and scriptworke…
…r.cot.verify
3269a02
@escapewindow escapewindow VALID_HASH_ALGORITHMS 0edebd0
@escapewindow escapewindow refactor validate_artifact_url with valid_artifact_rules
Previously, we had a list of valid schemes, a list of valid netlocs,
and a list of valid paths.  This was fine with a single entry in each,
but if we want to allow for two different sites, the paths will be valid
on either netloc, etc.  Splitting it into a single list of dictionaries
allows us to be more granular about this.
ef7fb3b
@escapewindow escapewindow 100% client coverage 22eddc7
@escapewindow escapewindow stub for decision task verification 87c464f
@escapewindow escapewindow audit_log_handler 07575e4
@escapewindow escapewindow cot.verify docstrings 84968f1
@escapewindow escapewindow fixes; start build_chain_of_trust 2cc5ee7
@escapewindow escapewindow move build_task_dependencies() call out of ChainOfTrust 8d08e0c
@escapewindow escapewindow fix flake8; populate todos 0689295
@escapewindow escapewindow get_valid_task_types -> function mapping.
I smell a yaml coming on.
1bbadbf
@escapewindow escapewindow DEFAULT_CONFIG cleanup
- make DEFAULT_CONFIG look more like scriptworker.yaml.tmpl
- remove max_connections, credential_update_interval
9b8dcb3
@escapewindow escapewindow move cot.verify constants into config d810c14
@escapewindow escapewindow work around missing decision task chain of trust af15b95
@escapewindow escapewindow add testing script in temp location fe668b8
@escapewindow escapewindow flake8 fix 40d24a2
@escapewindow escapewindow verify_task_types 417ae7f
@escapewindow escapewindow some decision task tests; worker_class -> worker_impl 4f8aacb
@escapewindow escapewindow decision task tests, other than verifying child task defns 9dfc48d
@escapewindow escapewindow verify task definitions match the full graph! 3e3ce7d
@escapewindow escapewindow fix audit log; more decision task tests ca8ee90
@escapewindow escapewindow raise_on_messages; verify_build_tasks 2e7f436
@escapewindow escapewindow messages->errors; verify signing tasks; alphabetize and fix build env…
… constant
cb5e251
@escapewindow escapewindow verify_*_tasks -> verify_*_task because we're only checking 1 at a time 8c6bea1
@escapewindow escapewindow docker-image task verification; some more docstrings acf4617
@escapewindow escapewindow flesh out docker-image workerType 29aedc8
@escapewindow escapewindow test the decision task command 17ea146
@escapewindow escapewindow make sure mach args are in order dfc262a
@escapewindow escapewindow fix tests by pinning aiohttp to 1.0.5 for now b0e9752
@escapewindow escapewindow docker-image check written, but failing in real world test :( 3fd18d1
@escapewindow escapewindow warn on docker-image sha test for now; add verify_cot.py a125558
@escapewindow escapewindow fix tests with aiohttp>=1.1.0 9672be7
@escapewindow escapewindow comment updates 4459635
@escapewindow escapewindow stub for trace_back_to_tree eb9f243
@escapewindow escapewindow call it 0.10.0a1 until we're code complete c0ceea7
@escapewindow escapewindow 100% task coverage f79e523
@escapewindow escapewindow context fixture -> scriptworker/test/__init__.py 84715ca
@escapewindow escapewindow add cot verify test stub 064c2b5
@escapewindow escapewindow download all firefox cot artifacts before verifying 850107a
@escapewindow escapewindow specify bug 1315415 in comment 58e9efa
@escapewindow escapewindow use less guessing ed0c32c
@escapewindow escapewindow fix 8a1c2cf
@escapewindow escapewindow load_json ba4c821
@escapewindow escapewindow load_json: take an is_path arg 6cb8101
@escapewindow escapewindow flake8 fix 5f477d9
@escapewindow escapewindow start fleshing out trace_back_to_firefox_tree 4d3e193
@escapewindow escapewindow match_url_regex 4e0763f
@escapewindow escapewindow do use a callback for match_url_regex f3851c2
@escapewindow escapewindow code complete? 0ece35a
@escapewindow escapewindow get verify_cot.py working cdb6e3d
@escapewindow escapewindow fix flake8 e9b5042
@escapewindow escapewindow some cleanup ef7da86
@escapewindow escapewindow test fix
8e9c083
@lundjordan
Contributor

@JohanLorenzo I'm not losing again! I'm happy to take the whole thing or split it up. Will give it a look over first thing pacific time tomorrow.

@escapewindow 👍 nice one.

@coveralls

Coverage Status

Coverage decreased (-24.0%) to 76.042% when pulling 8e9c083 on escapewindow:cot-verify into ccc1b31 on mozilla-releng:master.

@lundjordan
Contributor

sorry for delay here, hoping to finish by tomorrow.

@lundjordan

overall f+

I think I'm missing some context about the implementation of chainoftrust from a high level perspective but I was able to groke most of these changes.

Looks great! I have lots of comments in-line but I don't think anything blocking from proceeding with tests and landing

scriptworker/test/__init__.py
self._connection = mock.MagicMock()
self._payload = payload or {}
self.status = status
self.headers = {'content-type': 'application/json'}
self._loop = mock.MagicMock()
self.content = self
self.resp = [b"asdf", b"asdf"]
+ if YARL:
+ # try to fix aiohttp 1.1.0
+ self._url_obj = yarl.URL(args[1])
@lundjordan
lundjordan Nov 10, 2016 Contributor

what happens if we don't fix 1.1.0?

@escapewindow
escapewindow Nov 10, 2016 Member

Then tests running in a virtualenv with aiohttp 1.1.0 break.
Removing the 'try to' from the comment, since it does fix it.

+ self.decision_task_id = get_decision_task_id(self.task)
+ self.links = []
+
+ def dependent_task_ids(self):
@lundjordan
lundjordan Nov 10, 2016 Contributor

does self.links shrink as we walk the graph? This method sounds like it gives you only dep taskids of self.task but I assumed self.links as all the links in the graph

@escapewindow
escapewindow Nov 10, 2016 Member

It doesn't ever shrink, but it's only the links that allow us to trace our task back to the tree. So signing will have a much shorter chain than, say, balrog.

If we want to test the entire chain of trust, we can do so after the graph finishes with an external audit task. We can't test the chain of trust artifact from a link further down the chain while the graph is still running, since those tasks haven't run yet.

@lundjordan
lundjordan Nov 10, 2016 Contributor

yep sorry, forgot to delete this comment.

scriptworker/cot/verify.py
+ return [self.task] + [x.task for x in self.links]
+
+ def is_try(self):
+ """Helper method to determine if any task in the chain is a try task.
@lundjordan
lundjordan Nov 10, 2016 Contributor

do we expect or is it even possible to have some tasks as try tasks? I suppose they just need to have the same taskgroupid...

@escapewindow
escapewindow Nov 10, 2016 Member

Yup. For signing, I have:

  • release signing is restricted to these repos
  • nightly signing is restricted to this superset of repos
  • all other repos are able to use dep signing, including try. That allows us to test the nightly graph on try, even with tasks that depend on signed binaries. I'm going to push for the other *scripts to follow the same scope pattern, e.g. beetmover won't push into the release bucket from non-release repos.
scriptworker/cot/verify.py
+ """Each LinkOfTrust represents a task in the Chain of Trust and its status.
+
+ Attributes:
+ chain (ChainOfTrust): the ChainOfTrust object.
@lundjordan
lundjordan Nov 10, 2016 Contributor

where is chain used? or has this changed to the json repr cot

@escapewindow
escapewindow Nov 10, 2016 Member

I'm not sure which function you're pointing at because github isn't giving me enough context, but I know a number of functions take a (chain, link) args even if they don't use them, because the function is called from the same calling function, and the calling function doesn't know what args the target functions take. So they all get chain and link.

@lundjordan
lundjordan Nov 10, 2016 Contributor

this is the class I was referring to. didn't seem to be a chain attr.

@lundjordan
lundjordan Nov 10, 2016 Contributor

wow, sorry, I didn't put the link in: https://github.com/escapewindow/scriptworker/blob/cot-verify/scriptworker/cot/verify.py#L103

hm, so I'm confused. It looks like you don't have a chain attr in LinkOfTrust class definition. But you bind the attr to a LinkOfTrust live object. Should we not put chain = None after this line: https://github.com/escapewindow/scriptworker/blob/cot-verify/scriptworker/cot/verify.py#L115 ?

or am I getting confused? :)

@escapewindow
escapewindow Nov 10, 2016 Member

We can. The difference is an AttributeError when we reference link.chain or an AttributeError when we reference link.chain.$attr. I preferred the earlier AttributeError, BUT it looks like we never use link.chain so I'm going to just tear it out :)

scriptworker/cot/verify.py
+
+
+# raise_on_errors {{{1
+def raise_on_errors(errors):
@lundjordan
lundjordan Nov 10, 2016 Contributor

this is handy. I wonder if this should be more generic (outside cot) by allowing an exception to be passed in?

@escapewindow
escapewindow Nov 10, 2016 Member

Could do, in which case it would probably go in utils.

scriptworker/cot/verify.py
+
+
+# guess_worker_impl {{{1
+def guess_worker_impl(link):
@lundjordan
lundjordan Nov 10, 2016 Contributor

shame we need to 'guess' this... :(

@escapewindow
escapewindow Nov 10, 2016 Member

Yeah, I don't know how else to know this.

+ errors = []
+
+ if task['payload'].get("image"):
+ worker_impls.append("docker-worker")
@lundjordan
lundjordan Nov 10, 2016 Contributor

I wonder if 'docker-worker' and 'scriptworker' should be constants

@escapewindow
escapewindow Nov 10, 2016 Member

hm, maybe.

+
+ if not worker_impls:
+ errors.append("guess_worker_impl: can't find a worker_impl for {}!\n{}".format(name, task))
+ if len(set(worker_impls)) > 1:
@lundjordan
lundjordan Nov 10, 2016 Contributor

nice way to keep logic clean 👍

+
+
+# guess_task_type {{{1
+def guess_task_type(name):
@lundjordan
lundjordan Nov 10, 2016 Contributor

I really like how the logic in methods like these are stripped from ChainOfTrust and Link classes. Keeps the classes clean, minimal data stores and this logic usable in other places without the obj baggage.

@escapewindow
escapewindow Nov 10, 2016 Member

Yeah. I debate whether I should pass in info from the chain/link or the entire object, but either way clean arch functions > methods.

scriptworker/cot/verify.py
+ """
+ parts = name.split(':')
+ task_type = parts[-1]
+ if task_type.startswith('build'):
@lundjordan
lundjordan Nov 10, 2016 Contributor

this seem fragile. I suppose all these 'guess_*' methods are fragile. It would be great to come up with some coordination in the taskgraph that where we can rely on explicit info based on task def. maybe in some place like ['extra']['chainOfTrust']?

@escapewindow
escapewindow Nov 10, 2016 Member

I put in 'startswith' because I had some logic before that allowed for build0, build1, build2...
I don't have that anymore so I can take that out. We may need something like that again.

+ if env.get("MH_BRANCH"):
+ result = result or task['payload']['env']['MH_BRANCH'] == 'try'
+ if task['metadata'].get('source'):
+ result = result or _is_try_url(task['metadata']['source'])
@lundjordan
lundjordan Nov 10, 2016 Contributor

I get that the idea is that if at least one of the three locations returns True via _is_try_url then we say it's a Try task but there is probably a mistake if they don't all return True no?

iow -

# pseudo
try = False
results = [_is_try_url(MH_BRANCH), _is_try_url(GECKO_HEAD_REPOSITORY), etc]
if any(results):
    if not all(results): log or raise
    try = True
@escapewindow
escapewindow Nov 10, 2016 Member

I don't think you have to have an MH_BRANCH defined in a try task.

@lundjordan
lundjordan Nov 10, 2016 Contributor

ah, okay. sgtm.

+
+
+# check_interactive_docker_worker {{{1
+def check_interactive_docker_worker(link):
@lundjordan
lundjordan Nov 10, 2016 Contributor

heh good thinking. would this catch 'one-click loaner' scenarios? Is that the same as interactive?

@escapewindow
escapewindow Nov 10, 2016 Member

Yup, that's one way to get an interactive task.

+ if isinstance(task['payload'].get('image'), dict):
+ # Using pre-built image from docker-image task
+ docker_image_task_id = task['extra']['chainOfTrust']['inputs']['docker-image']
+ if docker_image_task_id != task['payload']['image']['taskId']:
@lundjordan
lundjordan Nov 10, 2016 Contributor

how does this work? how does ['inputs']['docker-image'] get populated and why can't it just be filled in to match some untrusted task['payload']['image'] ?

@escapewindow
escapewindow Nov 10, 2016 Member

We populate task.extra.chainOfTrust.inputs in the graph.
Once it's in the task definition, we add the docker-image task to the ChainOfTrust as a LinkOfTrust, as well as its decision task, and we trace that back to the tree. We also compare the docker image sha between the build and the docker-image task, so you can't point at any old task, at least we can't once bug 1315415 is fixed. Really, this is here so we can find the proper task easier. This is described further here.

Does that answer your question?

@lundjordan
lundjordan Nov 10, 2016 Contributor

yeah. thanks for the link

scriptworker/cot/verify.py
+ dep_dict = {}
+ for key, val in task['extra'].get('chainOfTrust', {}).get('inputs', {}).items():
+ dep_dict['{}:{}'.format(name, key)] = val
+ # XXX start hack: remove once all signing tasks have task.extra.chainOfTrust.inputs
@lundjordan
lundjordan Nov 10, 2016 Contributor

is there a bug tracking this? or, how long do we plan on keeping this hard-coded, deterministic logic

@escapewindow
escapewindow Nov 10, 2016 Member

This is already removed in the multisign branch, which is live on date. :)

scriptworker/cot/verify.py
+
+
+# get_artifact_url {{{1
+def get_artifact_url(context, task_id, path):
@lundjordan
lundjordan Nov 10, 2016 Contributor

should this be moved outside cot to maybe task.py?

@escapewindow
escapewindow Nov 10, 2016 Member

Sure, done.

scriptworker/cot/verify.py
+ )
+ await raise_future_exceptions(async_tasks)
+ except Exception:
+ log.exception("boo")
@lundjordan
lundjordan Nov 10, 2016 Contributor

'boo' for debugging?

docstring says this method raises DownloadError but seems we catch everything and log the traceback without failing.

@escapewindow
escapewindow Nov 10, 2016 Member

Hm. I don't remember. I'll go back to the docstring behavior, good catch.

+
+
+# verify_firefox_decision_command {{{1
+def verify_firefox_decision_command(decision_link):
@lundjordan
lundjordan Nov 10, 2016 Contributor

my largest issue with this and the verify graph definition methods are how fragile they seem. They make a lot of expectations of what the graph definition should look like.

I foresee many releases getting busted due to a change in taskgraph that wasn't caught in verify.py. Seems an unfortunate compromise at having definitions live outside of releng controlled env.

I don't have a better solution. Maybe some of the methods get tweaked as we go until we get to a state where it's not really an issue.

@escapewindow
escapewindow Nov 10, 2016 Member

Yes. I agree 100%.

  1. Enable chain of trust verification for dep signing jobs, and make them visible in treeherder. That way chain of trust bustage is viewable per-push rather than waiting til nightlies or release
  2. Put in these rules, and then work towards simplifying them. Catlee and I were talking and we're thinking we can simplify decision task command logic if we put more logic into the docker image.

But as is, we have to have rules around the decision task, otherwise anyone with the scopes can launch any decision task with any arbitrary env and commandline, which can result in any arbitrary graph.

scriptworker/cot/verify.py
+ Raises:
+ CoTError: on failure
+ """
+ with audit_log_handler(chain.context):
@lundjordan
lundjordan Nov 10, 2016 Contributor

neat

+ """Given a claim_task json dict, return the taskId.
+
+ Args:
+ claim_task (dict): the claim_task dict.
@lundjordan
lundjordan Nov 10, 2016 Contributor

in get_decision_task_id and get_worker_type you use task arg. here and get_run_id you use claim_task. Should these be the same?

@escapewindow
escapewindow Nov 10, 2016 Member

Possibly. claim_task has taskId info and is a superset of task. task has the task definition. If we want all the same arg, we can default to chain or link or context because those have claim_task and task as properties, or in their context property's properties. I debated this for a minute, then went with the simplest arg and a docstring.

+ if m is None:
+ continue
+ result = callback(m)
+ if result is not None:
@lundjordan
lundjordan Nov 10, 2016 Contributor

hm, I thought if there was no return statement in a function/method, the default is to return None?

@escapewindow
escapewindow Nov 10, 2016 Member

That's accurate. What is your question about this line?

@lundjordan
lundjordan Nov 10, 2016 Contributor

I need to get in the habit of knowing that you can't expand context lines. in the next line you return the result of the callback but only if it is not None. That seems like a noop as match_url_regex() itself will return None if it never makes it to the return statement.

again, I could be getting confused.

@escapewindow
escapewindow Nov 10, 2016 Member

This is in a for loop, so a return will exit the for loop.
I don't want to exit the for loop until I get a non-None result.

@escapewindow
escapewindow Nov 10, 2016 Member

Ah, looks like I can see more context with the files link above, just not in the main issue screen.

@lundjordan
lundjordan Nov 10, 2016 Contributor

😊 yep, PEBKAC

@escapewindow
Member

Feedback+ for 8e9c083.
I'm going to be landing review comment fixes, and I still have the multisign branch i'd like to merge in, and I still need to add test coverage. I'm thinking I'm going to be working on other branches, then squash merge into cot-verify as I'm ready to reduce mail spam from this PR, then release 1.0.0 once I merge into master.

@coveralls

Coverage Status

Coverage decreased (-23.7%) to 76.29% when pulling 0dfa6d9 on escapewindow:cot-verify into ccc1b31 on mozilla-releng:master.

@coveralls

Coverage Status

Coverage decreased (-23.7%) to 76.337% when pulling 0dfa6d9 on escapewindow:cot-verify into ccc1b31 on mozilla-releng:master.

escapewindow added some commits Nov 10, 2016
@escapewindow escapewindow 100% worker coverage 0f48a8d
@escapewindow escapewindow load_json tests 2290c5d
@escapewindow escapewindow 100% task coverage 887fca8
@escapewindow escapewindow 16% coverage cot.verify 3c790ca
@escapewindow escapewindow is_try: 21% fe39088
@escapewindow escapewindow get_link 22% 91cd18e
@escapewindow escapewindow use a link instead of magic mock in a couple places: 23% 9f8073b
@escapewindow escapewindow link.task, 25% 712dbe8
@escapewindow escapewindow raise_on_errors, audit_log_handler. 27% 8b04c77
@escapewindow escapewindow guess_worker_impl 29% db5ea42
@escapewindow escapewindow get_valid_worker_impls 0af23f1
@escapewindow escapewindow get_task_type. 30% a0c538e
@escapewindow escapewindow check_interactive_docker_worker 32% f9c8d16
@escapewindow escapewindow clean verify_docker_image_sha; 35% b002cbb
@escapewindow escapewindow verify docker image sha full 37% 03ed7e5
@escapewindow escapewindow find_task_dependencies. 41% 721c3bb
@escapewindow escapewindow avoid triple-right-bracket for vim folding, while fixing flake8 ee7ce28
@escapewindow escapewindow build_task_dependencies 46% cd8260c
@escapewindow escapewindow download_cot 48% 428c5c4
@escapewindow escapewindow download_cot_artifact 51% f05613a
@escapewindow escapewindow download_cot_artifacts 53% c37247f
@escapewindow escapewindow download_firefox_cot_artifacts 56% ba4a7df
@escapewindow escapewindow verify_cot_signatures 60% 32725c2
@escapewindow escapewindow verify_link_in_task_graph 65% 86ae32f
@escapewindow escapewindow verify_firefox_decision_command 72% b46c4c6
@escapewindow escapewindow verify_decision_task 76% 90ca846
@escapewindow escapewindow fix flake8 9d85e31
@escapewindow escapewindow verify_build_task 78% 6c78802
@escapewindow escapewindow verify_docker_image_task 81% 1514bd1
@escapewindow escapewindow check_num_tasks, verify_signing_task 84% 619c149
@escapewindow escapewindow verify_task_types 85% 74e3afa
@escapewindow escapewindow verify_worker_impls verify_scriptworker_task verify_docker_worker_tas…
…k 88%
5b5a05f
@escapewindow escapewindow get_firefox_source_url 89% f28fe61
@escapewindow escapewindow verify_chain_of_trust 92% d54a46b
@escapewindow escapewindow 100% coverage
f9fead8
@escapewindow
Member

I just merged in the multisign and cot-verify-test branches.

  • 100% coverage
  • multiple signing formats per file via upstreamArtifacts

I want to fix the signing blue's on date before releasing 1.0.0[b1?]

I also want to add support for other scriptworker instance types and full docs, but it's unclear if that'll be 1.0.0final or a dot release.

@coveralls

Coverage Status

Coverage decreased (-0.2%) to 99.754% when pulling f9fead8 on escapewindow:cot-verify into ccc1b31 on mozilla-releng:master.

@escapewindow escapewindow 100% test coverage without integration
5678a61
@coveralls

Coverage Status

Coverage decreased (-0.06%) to 99.939% when pulling 5678a61 on escapewindow:cot-verify into ccc1b31 on mozilla-releng:master.

@escapewindow escapewindow another try at 100% without integration tests
c8451c4
@coveralls

Coverage Status

Coverage remained the same at 100.0% when pulling c8451c4 on escapewindow:cot-verify into ccc1b31 on mozilla-releng:master.

@escapewindow escapewindow changed the title from 1.0.0: chain of trust verification to 1.0.0b1: chain of trust verification Nov 15, 2016
@coveralls

Coverage Status

Coverage remained the same at 100.0% when pulling 72cc1f0 on escapewindow:cot-verify into ccc1b31 on mozilla-releng:master.

@escapewindow
Member

I:

  • fixed the signing timeouts. These were uncaught aiohttp exceptions on upload. The fix was twofold: reenabling max connections (we were opening 50some uploads simultaneously) and catching/retrying those aiohttp exceptions.
  • added more debugging logging for the above.
  • moved audit_log_handler to scriptworker.log.contextual_log_handler in case I wanted to add contextual logging for the timeouts
  • fixed the bustage from https://hg.mozilla.org/integration/autoland/rev/2168cbd4b154#l2.57
    • added a new docker image to the allow list
    • allowed for a nonexistent docker-image payload.command
    • allowed for new docker-image env vars
  • started adding a new docs framework, which i'll have to flesh out.

Merging and shipping 1.0.0b1. I'll update docs and start pushing towards cot-enabled other scriptworker instance types.

@escapewindow escapewindow merged commit 82e211c into mozilla-releng:master Nov 15, 2016

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
coverage/coveralls Coverage remained the same at 100.0%
Details
@escapewindow escapewindow deleted the escapewindow:cot-verify branch Jan 23, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment