Skip to content

Compile gomplate with our own go toolchain

DJ Mountney requested to merge compile-gomplate into master

What does this MR do?

Compile gomplate ourselves to reduce CVEs in scans.

Taking this on should actually reduce workload. Right now we scan, and log golang cve issues with gomplate. Raise the issues to the gomplate maintainer asking for a new release on the newer go build. The maintainer has been great about getting back to us, but often the CVEs don't apply to gomplate, so we instead get a detailed response as to why gomplate isn't vulnerable to each CVE such as here: https://github.com/hairyhenderson/gomplate/issues/1814 which we can then use the log a deviation request.

That's a lot of work for all parties involved, vs just compiling it ourselves on the newest golang patch. Which is exactly what the gomplate maintainer has been recommending to us:

If you can't get an exemption from your security team for these CVEs, simply compile your own gomplate binaries with a newer Go toolchain.

I've based the changes here in this MR off our gitlab-logger setup. So the dockerfiles, and scripts in the scripts directory have been updated to be similar to the gitlab-logger folder.

Checklist

See Definition of done.

For anything in this list which will not be completed, please provide a reason in the MR discussion

Required

  • Merge Request Title, and Description are up to date, accurate, and descriptive
  • MR targeting the appropriate branch
  • MR has a green pipeline on GitLab.com
  • When ready for review, MR is labeled "~workflow::ready for review" per the Distribution MR workflow

Expected (please provide an explanation if not completing)

  • Test plan indicating conditions for success has been posted and passes
  • Documentation created/updated
  • Integration tests added to GitLab QA
  • The impact any change in container size has should be evaluated
  • New dependencies are managed with dependencies.io
Edited by Jason Plum

Merge request reports