well the writeup is quite verbose and i'm not quite sure why it was not yet considered as a real problem upstream.
We could have a look at the test why it actually fails, i can try to build it at the weekend
Thanks Remi. This new patch looks completely different, but there is still a failure on test 144 with the i686.
Sparse files
138: sparse files ok
139: extracting sparse file over a pipe ok
140: storing sparse files > 8G ok
141: storing long sparse file names ok
142: listing sparse files bigger than 2^33 B ok
143: storing sparse file using seek method ok
144: sparse files in MV archives FAILED (sparsemv.at:31)
145: sparse files in PAX MV archives, v.0.0 ok
146: sparse files in PAX MV archives, v.0.1 ok
147: sparse files in PAX MV archives, v.1.0 ok
I built a version with the provided patch (changing path to lib/paxnames.c to works with the tar's tarball). It apply without code modification.
The test suite didn't pass. I'm not sure if we have to trust this CVE/patch, considering that upstream refuse to consider the problem.
For reference, subject was posted on bug-tar: http://lists.gnu.org/archive/html/bug-tar/2016-10/msg00012.html
well the writeup is quite verbose and i'm not quite sure why it was not yet considered as a real problem upstream.
We could have a look at the test why it actually fails, i can try to build it at the weekend
Thanks Remi. This new patch looks completely different, but there is still a failure on test 144 with the i686.
Sparse files
138: sparse files ok
139: extracting sparse file over a pipe ok
140: storing sparse files > 8G ok
141: storing long sparse file names ok
142: listing sparse files bigger than 2^33 B ok
143: storing sparse file using seek method ok
144: sparse files in MV archives FAILED (sparsemv.at:31)
145: sparse files in PAX MV archives, v.0.0 ok
146: sparse files in PAX MV archives, v.0.1 ok
147: sparse files in PAX MV archives, v.1.0 ok
tar-1.29-2 is uploaded with the last patch. Test suite passed.