bump google/certificate-transparency-go v1.0.21

[thaJeztah]

full diff: google/certificate-transparency-go@v1.0.20...v1.0.21

• CTFE no longer prints certificate chains as long byte strings in messages when
  handler errors occur. This was obscuring the reason for the failure and wasn't
  particularly useful.
• CTFE now has a global log URL path prefix flag and a configuration proto for a
  log specific path. The latter should help for various migration strategies if
  existing C++ server logs are going to be converted to run on the new code.
• More progress has been made on log mirroring. We believe that it's now at the
  point where testing can begin.
• The certcheck and ct_hammer utilities have received more enhancements.
• x509 and x509util now support Subject Information Access and additional exten-
  sions for RPKI / RFC
• scanner / fixchain and some other command line utilities now have better
  handling of non-fatal errors.

[thaJeztah]

ping @justincormack @dani-docker @dperny PTAL

[codecov]

Codecov Report

Merging #2910 (b982d78) into master (6303310) will increase coverage by 0.00%.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #2910   +/-   ##
=======================================
  Coverage   62.29%   62.30%           
=======================================
  Files         155      155           
  Lines       24533    24533           
=======================================
+ Hits        15283    15285    +2     
+ Misses       7656     7645   -11     
- Partials     1594     1603    +9     

[dani-docker]

LGTM 👍

[SamWhited]

LGTM; @thaJeztah since you just merged #2940 would it make sense to also merge this and backport it before the version of swarmkit that moby uses gets bumped? That way we can pull in the dependency updates all at once and keep customers happy since I think this dep bump fixes some potential CVEs.

[s0j]

@thaJeztah Would it be possible to bump this to v1.1.0? There are a few more CVEs that have been addressed in v1.1.0: CVE-2018-16875, CVE-2018-16886.

[thaJeztah]

I can do a quick follow-up after this one. Let me at least rebase it to have a fresh run of CI

[thaJeztah]

Note that any vendoring changes in this repo is only affecting CI. I'm usually bumping versions here first to make sure nothing broke in the tests in this repository, but the version that's actually used in docker engine will be the one that's vendored there

[s0j]

Note that any vendoring changes in this repo is only affecting CI. I'm usually bumping versions here first to make sure nothing broke in the tests in this repository, but the version that's actually used in docker engine will be the one that's vendored there

Ok. For my understanding -- if we wanted google/certificate-transparency-ca:v1.1.0 in moby/moby, that would be a bump in moby/moby's docker/swarmkit as google/certificate-transparency-ca is a dependency of docker/swarmkit. Correct?

[dperny]

@s0j i'm not sure how familiar you are with go's disastrously bad dependency management, but essentially, the vendored dependencies are completely separate sets for each package. in moby/moby, there is only 1 certificate-transparency version, which is used by every package that depends on it, including swarmkit. in the swarmkit repo, there is only 1 certificate-transparency, which is used to build swarmkit by itself, a situation only useful for CI purposes.

so, you bump the package here to make sure it works, and you bump the package there to actually use it. nothing vendored in this repository is present in the moby/moby repository.

i'm sure that even if that answers your question, it has created a whole host of new ones.

[thaJeztah]

Ok. For my understanding -- if we wanted google/certificate-transparency-ca:v1.1.0 in moby/moby, that would be a bump in moby/moby's docker/swarmkit as google/certificate-transparency-ca is a dependency of docker/swarmkit. Correct?

strictly speaking, we can update the version in moby/moby without opening a PR in swarmkit first; It's mostly that I know SwarmKit uses this dependency, that I prefer to do a cycle of updating, and update it here first, then update it in moby/moby (including updating swarmkit, so that the versions "align").

It's mostly hygiene (bumping minor versions should be ok if the dependency properly follows SemVer, but unfortunately not all packages practice SemVer properly, and only "slammed" a SemVer tagging scheme on their repo to please go modules.

It's also worth noting that CVE's not always affect the code-paths we use, so even though it's good practice to keep the dependencies updated, at times updating the dependency isn't really needed (other than to comfort users that may get "itchy" if they hear about a CVE); even then, updating should be done with care, because there's always a risk of (hidden) regressions when updating code (vendoring helps there, because it makes the code changes that you're pulling in more visible).

[thaJeztah]

Rebased, to get a fresh run of CI. @dperny ptal

[thaJeztah]

Took some fun, but this has been done in #3097