Re: CVS commit: src/share/mk

[David Brownlee <abs%absd.org@localhost>]

On Thu, 14 Nov 2019 at 21:05, Christos Zoulas <christos%astron.com@localhost> wrote:
>
> In article <2c05e1ed-8410-fa0f-d786-06ee6e1c4a95%marples.name@localhost>,
> Roy Marples  <roy%marples.name@localhost> wrote:
> >On 14/11/2019 05:47, Martin Husemann wrote:
> >> On Thu, Nov 14, 2019 at 03:53:02PM +1100, matthew green wrote:
> >>> i'm not happy about this change.  i wish that bsdtar was
> >>> fixed to not be unfriendly, because it mostly is a better
> >>> implementation.  just these edge cases are rather ..
> >>> problematic yet these issues are being ignored or
> >>> rejected as being irrelevant.
> >>
> >> Me neither, especially as we now effectively have different command line
> >> args passed from sysinst to tar depending on the tar invocation (and this
> >> is all hard coded). I'll have to make it a define in sysinst depending
> >> on the seleted tar variant :-/.
> >
> >Just for the record, I don't really care about different cmd line args,
> >symlinks and security involved.
> >
> >My expectation is that a modern NetBSD tar can extract a modern tar
> >archive from other sources.
> >
> >If it cannot do this we have failed.
>
> So I am trying to find some time to pursue the two issues I have
> with upstream and understand if they will accept the following two
> changes (or versions thereof):
>
> The first issue is that I prefer to have tar respect existing
> symlinks (ones that it did not create by default -- without having
> to specify extra flags) since to do this (in my opinion) does not
> pose a security risk. Yes my implementation is Q+D, but it works.
>
>     https://www.netbsd.org/~christos/track-symlinks.diff
>
> The second issue is that the way libarchive-tar overwrites existing
> files is by removing them first, and writing them directly to the
> final destination pathname. This creates a significant amount of
> time where the file is either not available or not completely
> written. Imagine trying to replace shared libraries or programs
> frequently used. Pax-as-tar wrote the file to a temporary one first
> and used rename(2) to atomically replace it. I've written a patch
> to do the same for libarchive-tar:
>
>     https://www.netbsd.org/~christos/libarchive-atomic.diff
>
> With those two patches we can put libarchive as tar back and we don't
> need to make any other changes since behavioraly the old pax-as-tar
> and libarchive-tar behave the same for those two cases that bothered us.
>
> I am inclined to just commit them and flip the default again.

I could see an argument for having an option to turn off the
extract-to-temp-and-rename behaviour (not that I'd use it), but I'd be
very happy to see both above changes in as defaults and us back onto
libarchive-tar

Thanks for working on this!

David