Subject: Re: tar ignores filenames that contain `..'
To: Frederick Bruckman <firstname.lastname@example.org>
From: Hisashi T Fujinaka <email@example.com>
Date: 10/23/2002 08:35:56
AHA! This probably solves my unanswered question as to why cdrecord
doesn't compile on my system any more!
allison:/usr/pkgsrc/sysutils/cdrecord % make
=> Checksum OK for cdrtools-1.10.tar.gz.
===> Extracting for cdrecord-1.10
===> Required installed package gmake>=3.78: gmake-3.80 found
tar: Ignoring link containing `..' (../lib/getfp.c)
tar: Ignoring link containing `..' (../cdrecord/scsi_cdr.c)
OK, what's the workaround?
On Wed, 23 Oct 2002, Frederick Bruckman wrote:
> On Wed, 23 Oct 2002, Jason R Thorpe wrote:
> > On Wed, Oct 23, 2002 at 09:25:03AM -0500, Frederick Bruckman wrote:
> > > This "pax" bug^H^H^Hfeature also breaks binary packages (PR bin/18759).
> > > It needs to be fixed in "pax".
> > I seem to recall that this is what the GNU tar security issue was all
> > about...
> I see. So I guess the battle's already over, so "pkgsrc/mk" needs to
> use "pax --insecure" everywhere that "tar" was used, and "pkg_create"
> and "pkg_add" need to implement the old "tar" format in C?
> For what it's worth, old NetBSD 1.6 "pax" has an interesting "forward
> compatibility" twist, when used to create archives, in that it sees
> "--insecure" as a non-existent filename and only warns (by virtue of
> not understanding long options), rather than balking as it would with
> a non-supported short option, but that doesn't help at all for
> extracting archives.
Hisashi T Fujinaka - firstname.lastname@example.org
BSEE (6/86) + BSChem (3/95) + BAEnglish (8/95) + $2.50 = mocha latte