OneCRL downloader is broken

[mwobensmith]

It looks like a recent regression in OneCRLTools. If you delete your .tlscanary cache (as I did, while debugging) you will see errors upon running the canary w/r/t installing OneCRL tools and missing function names.

[cr]

I reported lack of error handling in onecrl downloader upstream: https://github.com/mozmark/OneCRL-Tools/issues/3

[cr]

Had the idea to hardcode the working commit, but no luck there. Meh. go get doesn't seem to support fetching from specific branches or tags or commits. There's a web service called gopkg.in that tries to work around this limitation, but it only supports branches and tags.

[cr]

In the end, implementing and landing a workaround, and then reversing the thing would probably be an unreasonable effort. We should wait for @mozmark's fix to land upstream.

[cr]

An ad-hoc workaround for when the go get step fails is to temporarily disable the go get / install code in https://github.com/mozilla/tls-canary/blob/master/one_crl_downloader.py#L45 until upstream gets fixed. It should then fall back to the last successfully installed onecrl package.

We may turn this into a command line option for the canary, but it would only help against package breakage. If the package installs fine, but contains runtime bugs in the onecrl binary, the old working version of the package would be silently overwritten, so there would be no working fallback.

Catching all of these cases in a proper go package version maintenance and caching logic seems a bit overkill to me. :/

[mozmark]

I've fixed the build issue - I started to centralize all of the config / flags stuff for the various tools but forgot to test for this tool.

One thing to note, the flag name has changed from 'env' to 'onecrlenv' for disambiguation reasons.

[cr]

Thanks for the fix, @mozmark! I can confirm that it's working again, and the necessary TLS Canary fix is about to land, too.

[cr]

#60 just landed, closing.