Tar files generated with Go 1.7 and before can no longer be read with Go 1.8 when the path name is greater than 100 characters and has two or more components and the uid is greater than octal value 010000000.
The problem was first reported in moby/moby#34092, which details some conditions and impact. With docker, this manifests itself in cases where a file with a long path name will be written out merely as the base name.
The cause seems to be around the handling of the GNU prefix field in tar headers. There were a few fixes in Go 1.8 that seem to have led to this situation in pursuit of fixing this. Unfortunately, these tars are no longer readable with Go 1.8+ but are out in the wild, as container images. Note that GNU tar also cannot read these files, which was probably the reasoning around the Go 1.8 fixes.
A full description and minimal reproduction, without the docker source, is available in https://gist.github.com/stevvooe/e2a790ad4e97425896206c0816e1a882. This provides an overview of the behavior and condition under which this is encountered. Let me know if you need me to copy this into the issue description.
Our current solution, as proposed in moby/moby#34092 (comment), is to fork archive/tar to handle this specific case, which seems unfortunate. It would be great to get some guidance from the Go team and community on how to proceed.
cc @dsnet @tonistiigi @dmcgowan
Tar files generated with Go 1.7 and before can no longer be read with Go 1.8 when the path name is greater than 100 characters and has two or more components and the uid is greater than octal value
010000000.The problem was first reported in moby/moby#34092, which details some conditions and impact. With docker, this manifests itself in cases where a file with a long path name will be written out merely as the base name.
The cause seems to be around the handling of the GNU prefix field in tar headers. There were a few fixes in Go 1.8 that seem to have led to this situation in pursuit of fixing this. Unfortunately, these tars are no longer readable with Go 1.8+ but are out in the wild, as container images. Note that GNU tar also cannot read these files, which was probably the reasoning around the Go 1.8 fixes.
A full description and minimal reproduction, without the docker source, is available in https://gist.github.com/stevvooe/e2a790ad4e97425896206c0816e1a882. This provides an overview of the behavior and condition under which this is encountered. Let me know if you need me to copy this into the issue description.
Our current solution, as proposed in moby/moby#34092 (comment), is to fork
archive/tarto handle this specific case, which seems unfortunate. It would be great to get some guidance from the Go team and community on how to proceed.cc @dsnet @tonistiigi @dmcgowan