On Tue, Jan 23, 2024 at 5:40 PM Guillem Jover <guil...@debian.org> wrote: > > Hi! > > On Tue, 2024-01-23 at 16:47:34 -0800, Joshua Hudson wrote: > > On Tue, Jan 23, 2024 at 3:16 PM Guillem Jover <guil...@debian.org> wrote: > > > On Tue, 2024-01-23 at 13:46:53 -0800, Joshua Hudson wrote: > > > > Package: dpkg > > > > Version: 1.21.22 > > > > Severity: important > > > > > Source for long link record length does not include trailing null: > > > > > > > > https://repo.or.cz/libtar.git/blob/HEAD:/lib/block.c#l294 > > > > > > > > I've stashed the offending .deb package but I'm not sure if I can > > > > get clearance to release it. > > > > > > Ack. I did not try to reproduce this yet because it was not obvious > > > exactly how to do that from the report, instead just inspected the > > > code for potential brokenness related to this, and I think I've fixed > > > this now, but as I've not tested it, could you instead try applying > > > the attached patch against dpkg and test with your package whether > > > this fixes the problem you've found? > > > > That patch fixed the bug. Knowing where the bug is, I can see how > > the bug works and explain why. I'm wondering if this was just a > > pending disaster for everybody or if there's some actual reason it > > doesn't trip on official packages. > > Thanks for testing! Much appreciated. > > It looks like the code in libdpkg has been like that since long GNU > names and links were implemented (around Oct 1999, in dpkg commit > <https://git.dpkg.org/cgit/dpkg/dpkg.git/commit/?id=3252594427f5285ab4091a6beca2adaa5082a883>). > > Checking now the libdpkg test suite and the GNU tar implementation > which is what gets used to generate .debs by dpkg-deb, I see it always > includes the NUL byte as part of the size, which explains why this has > never been a problem when using the dpkg-deb tooling combined with GNU > tar. > > <https://git.savannah.gnu.org/cgit/tar.git/tree/src/create.c#n542> > > I assume, given the libtar link you provided initially, that your custom > .deb package is being generated by something using that library? If so > that would also explain things. I think libtar should probably get a > bug report to mimic the GNU behavior.
I used a couple of different sample sources to find how Gnu LongLinks work, and yes libar was one of them. It looks like gnutar itself is the oddball; everybody else I found set the size to not include the trailing null. What's funny is I thought I had found that gnutar did the same; I guess I just misread the hexdump of its output. I guess that's what we all get for lack of an actual specification on it. Incidentally, gnutar will read either way. Robustness is a good thing. Here's another generator. Search for WriteAsGnu. Sorry I can't link to line because of new web accessibility issues on github. https://raw.githubusercontent.com/dotnet/runtime/d250dcc2deae28fa9726ecad78dddf614b1420a8/src/libraries/System.Formats.Tar/src/System/Formats/Tar/TarHeader.Write.cs > But regardless of libtar getting fixed or not, I'm still going to be > committing the change, to make the parser robust against such input. Much appreciated. > Thanks, > Guillem
