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. 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. Thanks, Guillem
