Bug#232025: dpkg unpack failure
package dpkg
tags 232025 patch
thanks
On Tue, Mar 02, 2004 at 10:41:22PM +0100, Ingo Saitz wrote:
> This bug is not resolved, since it is not a bug in tar but a bug in the
> unpacking code in dpkg. I don't have POSIX handy but it seems that the
> filename field does not need to be null terminated.
>
Yeah, on reflection I agree with you. Whilst bdale closed the earlier
dpkg bugs of this nature when he uploaded the "fixed" version of tar,
it's still pretty wrong that dpkg isn't unpacking them right.
> Indeed, star and Solaris tar don't do this, and GNU tar seems to have
> fixed this old bug of their tar implementation, too. This indeed breaks
> dpkg tarfn.c which relied on this buggy behaviour.
>
Yup, that does seem to be the case. Because tarfn.c just maps a C
struct onto the memory block holding the tar header, it needs to be
careful when dealing with Name and LinkName and currently isn't.
Because we copy the data into TarInfo and hand it off to other
functions, I think the best way to deal with this is to actually copy
the data in memory and in doing so, ensure that it's null-terminated.
Patch attached.
> It is tar which needs a workaround for sarge, I agree. But I believe
> dpkg must be fixed, too, so that sarge+1 can include a tar without this
> ugly workaround for dpkg.
>
If doogie can do an upload, or is happy for me to do one, we've still
got time to get this into sarge.
Scott
--
Have you ever, ever felt like this?
Had strange things happen? Are you going round the twist?
Reply to: