Skip to content

Injected BSD tar taking presedence over in-image GNU tar leading to sadness

Bug/Issue

What was the problem?

So back in 1979 the tar command was added to UNIX... <fast forward through the history of BSD, GNU, Linux, various flame wars>... and that is how we ended up with GNU tar and BSD tar. We statically compile BSD tar for bootstrapping gitlab-helper into images. In most cases the tars are equivalent, except when they are not.

For example, the --pax-option is not supported in BSD tar because of course it is not. It is supported in GNU tar because of course it is. (Pausing as you smugly nod... "Ha, Paul, everyone knows this. And PAX options are critical for optimizing...") OK, so be quiet, please.

Anyway, we should not leave our injected BSD tar around in the PATH when job steps start. If the image has a tar, it should use that.

Reproduction steps

Compare steps running which tar; tar --version between an image running on GitLab.com and one using the Runner for Cloud.gov. Examples below are for an Alpine image.

Command GitLab.com Runner for Cloud.gov
which tar /bin/tar /root/bin/tar
tar --version tar (busybox) 1.37.0 bsdtar 3.7.9 - libarchive 3.7.9 zlib/1.3.1 liblzma/5.8.1 libzstd/1.5.7

Solution

Could be any of:

  • Remove /root/bin from PATH (or toss it at the end)
  • Remove /root/bin/tar (and probably other items we inject that might cause trouble)
  • Use a different name for /root/bin/tar like /root/bin/the-one-and-only-bsdtar-sorry-mister-stallman