NetBSD Problem Report #54467
From martin@aprisoft.de Thu Aug 15 16:23:02 2019
Return-Path: <martin@aprisoft.de>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
by mollari.NetBSD.org (Postfix) with ESMTPS id 176C87A1BA
for <gnats-bugs@gnats.NetBSD.org>; Thu, 15 Aug 2019 16:23:02 +0000 (UTC)
Message-Id: <20190815162252.9112F5CC853@emmas.aprisoft.de>
Date: Thu, 15 Aug 2019 18:22:52 +0200 (CEST)
From: martin@NetBSD.org
Reply-To: martin@NetBSD.org
To: gnats-bugs@NetBSD.org
Subject: new tar overwrites symlinks to directories
X-Send-Pr-Version: 3.95
>Number: 54467
>Category: bin
>Synopsis: new tar overwrites symlinks to directories
>Confidential: no
>Severity: critical
>Priority: high
>Responsible: bin-bug-people
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Thu Aug 15 16:25:00 +0000 2019
>Closed-Date: Tue Apr 21 18:31:43 +0000 2020
>Last-Modified: Tue Apr 21 18:31:43 +0000 2020
>Originator: Martin Husemann
>Release: NetBSD 9.99.7
>Organization:
The NetBSD Foundation, Inc.
>Environment:
System: NetBSD whoever-brings-the-night.aprisoft.de 9.99.7 NetBSD 9.99.7 (WHOEVER) #293: Mon Aug 12 12:59:36 CEST 2019 martin@seven-days-to-the-wolves.aprisoft.de:/work/src/sys/arch/sparc64/compile/WHOEVER sparc64
Architecture: sparc64
Machine: sparc64
>Description:
The new tar(1) is overeager in restoring directories if those already exist
as a symlink to another directory.
This kills updates on machines that have /usr as a symlink to someplace else
with our base.tgz containing
drwxr-xr-x 0 root wheel 0 Jul 14 16:36 ./usr
>How-To-Repeat:
Try this:
cd /tmp
mkdir test
cd test
mkdir a b b/c
tar cvf /tmp/test.tar .
mv b d
ln -s d b
tar xvf /tmp/test.tar
ls -l
It should show something like:
total 8
drwxr-xr-x 2 martin wheel 0 Aug 15 18:20 a/
lrwxr-xr-x 1 martin wheel 1 Aug 15 18:20 b@ -> d
drwxr-xr-x 3 martin wheel 48 Aug 15 18:20 d/
but in -current it shows:
total 16
drwxr-xr-x 2 martin wheel 0 Aug 15 18:22 a/
drwxr-xr-x 3 martin wheel 48 Aug 15 18:22 b/
drwxr-xr-x 3 martin wheel 48 Aug 15 18:22 d/
>Fix:
n/a
>Release-Note:
>Audit-Trail:
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: bin/54467: broken tar symlink behaviour
Date: Thu, 15 Aug 2019 19:29:03 +0200
This behaviour is documented, see the SECURITY section in tar(1).
Unfortunately there seems to be no option to supress this behaviour.
We will have to make sure all install media have pax installed and switch
to that (or backout the switch to bsdtar).
Martin
From: Joerg Sonnenberger <joerg@bec.de>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: bin/54467: new tar overwrites symlinks to directories
Date: Sat, 17 Aug 2019 21:37:44 +0200
On Thu, Aug 15, 2019 at 04:25:00PM +0000, martin@NetBSD.org wrote:
> The new tar(1) is overeager in restoring directories if those already exist
> as a symlink to another directory.
That's how it should behave. Seems like a bug in pax-as-tar if nothing
else.
> This kills updates on machines that have /usr as a symlink to someplace else
> with our base.tgz containing
>
> drwxr-xr-x 0 root wheel 0 Jul 14 16:36 ./usr
This sounds like it is asking for trouble to me. Why would you ever want
to make /usr a symlink?!
Joerg
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: bin/54467: new tar overwrites symlinks to directories
Date: Sat, 17 Aug 2019 22:25:11 +0200
On Sat, Aug 17, 2019 at 07:50:02PM +0000, Joerg Sonnenberger wrote:
> On Thu, Aug 15, 2019 at 04:25:00PM +0000, martin@NetBSD.org wrote:
> > The new tar(1) is overeager in restoring directories if those already exist
> > as a symlink to another directory.
>
> That's how it should behave. Seems like a bug in pax-as-tar if nothing
> else.
It should be overridable by some option, at least.
> > This kills updates on machines that have /usr as a symlink to someplace else
> > with our base.tgz containing
> >
> > drwxr-xr-x 0 root wheel 0 Jul 14 16:36 ./usr
>
> This sounds like it is asking for trouble to me. Why would you ever want
> to make /usr a symlink?!
Why not?
In this concrete case it is the result of history, limited size boot disk
and maybe suboptimal admin choices a long time ago. It always has worked
fine, now it is broken.
It is a setup that may happen to others in the real world and we should be
very carefull before breaking it, and also should prominently warn about it.
Martin
From: Joerg Sonnenberger <joerg@bec.de>
To: gnats-bugs@netbsd.org
Cc: gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, martin@NetBSD.org
Subject: Re: bin/54467: new tar overwrites symlinks to directories
Date: Sat, 17 Aug 2019 23:14:12 +0200
On Sat, Aug 17, 2019 at 08:30:02PM +0000, Martin Husemann wrote:
> On Sat, Aug 17, 2019 at 07:50:02PM +0000, Joerg Sonnenberger wrote:
> > On Thu, Aug 15, 2019 at 04:25:00PM +0000, martin@NetBSD.org wrote:
> > > The new tar(1) is overeager in restoring directories if those already exist
> > > as a symlink to another directory.
> >
> > That's how it should behave. Seems like a bug in pax-as-tar if nothing
> > else.
>
> It should be overridable by some option, at least.
It can be, -P covers it. I strongly believe that sysinst should not be
setting it though.
> > > This kills updates on machines that have /usr as a symlink to someplace else
> > > with our base.tgz containing
> > >
> > > drwxr-xr-x 0 root wheel 0 Jul 14 16:36 ./usr
> >
> > This sounds like it is asking for trouble to me. Why would you ever want
> > to make /usr a symlink?!
>
> Why not?
Because it messes up physical vs logical path. Even a null mount would
be better.
Joerg
From: "John D. Baker" <jdbaker@consolidated.net>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: bin/54467: new tar overwrites symlinks to directories
Date: Sat, 17 Aug 2019 20:40:07 -0500 (CDT)
On Thu, 15 Aug 2019 16:25:00 +0000 (UTC), martin@NetBSD.org wrote:
> The new tar(1) is overeager in restoring directories if those already
> exist as a symlink to another directory.
> This kills updates on machines that have /usr as a symlink to someplace
> else
This also kills 'named' if one has it running chrooted. The migration
process copies "/etc/namedb/*" to "/var/chroot/named/etc/namedb/" and
replaces "/etc/namedb" with a symlink.
After an update, "/etc/namedb" is overwritten back to a directory and
the subsequent 'etcupdate' reports "root.cache", "bind.keys", etc. as
missing.
--
|/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X
|\ / jdbaker[snail]consolidated[flyspeck]net OpenBSD FreeBSD
| X No HTML/proprietary data in email. BSD just sits there and works!
|/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: bin/54467: new tar overwrites symlinks to directories
Date: Sun, 18 Aug 2019 10:40:32 +0200
On Sat, Aug 17, 2019 at 11:14:12PM +0200, Joerg Sonnenberger wrote:
> It can be, -P covers it. I strongly believe that sysinst should not be
> setting it though.
This is not documented, or am I misreading the man page?
For sysinst I am not sure yet (and of course if everyone agrees I can easily
deal with my own local issue).
> > Why not?
>
> Because it messes up physical vs logical path. Even a null mount would
> be better.
Sure, as would have better planning before we gained debug sets and sizes
exploded - the point is that it happens in the wild (whether for good or
for bad reasons does not really matter).
We either need to keep supporting it, detect and warn, or at least signal
a big red flag in updating instructions telling users how to migrate. I am
open to all of these (or other solutions).
Martin
From: Christos Zoulas <christos@zoulas.com>
To: gnats-bugs@netbsd.org
Cc: gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org,
"martin@netbsd.org" <martin@NetBSD.org>
Subject: Re: bin/54467: new tar overwrites symlinks to directories
Date: Sun, 18 Aug 2019 18:27:58 +0300
Looking at -P on bsdtar.c:
/* A basic set of security flags to request from libarchive. */
#define SECURITY \
(ARCHIVE_EXTRACT_SECURE_SYMLINKS \
| ARCHIVE_EXTRACT_SECURE_NODOTDOT)
.....
#if 0
/*
* The common BSD -P option is not necessary, since
* our default is to archive symlinks, not follow
* them. This is convenient, as -P conflicts with GNU
* tar anyway.
*/
case 'P': /* BSD convention */
/* Default behavior, no option necessary. */
break;
#endif
case 'P': /* GNU tar */
bsdtar->extract_flags &= ~SECURITY;
bsdtar->flags |= OPTFLAG_ABSOLUTE_PATHS;
break;
So I guess -P does what we want and unfortunately more. I'd rather it
just disabled ARCHIVE_EXTRACT_SECURE_SYMLINKS... We could
add a long option that did exactly want we wanted I guess:
--security=-extract-secure-symlinks
christos
From: Joerg Sonnenberger <joerg@bec.de>
To: gnats-bugs@netbsd.org
Cc: gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, martin@NetBSD.org
Subject: Re: bin/54467: new tar overwrites symlinks to directories
Date: Sun, 18 Aug 2019 17:55:34 +0200
On Sun, Aug 18, 2019 at 03:30:01PM +0000, Christos Zoulas wrote:
> So I guess -P does what we want and unfortunately more. I'd rather it
> just disabled ARCHIVE_EXTRACT_SECURE_SYMLINKS... We could
> add a long option that did exactly want we wanted I guess:
> --security=-extract-secure-symlinks
If you allow symlinks tricks, you can just allow absolute path names
too. It really doesn't make any difference as attack vector.
Joerg
From: Christos Zoulas <christos@zoulas.com>
To: gnats-bugs@netbsd.org
Cc: gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org,
"martin@netbsd.org" <martin@NetBSD.org>
Subject: Re: bin/54467: new tar overwrites symlinks to directories
Date: Sun, 18 Aug 2019 19:12:59 +0300
>=20
> If you allow symlinks tricks, you can just allow absolute path names
> too. It really doesn't make any difference as attack vector.
I am not talking about an attack vector, I am just saying that the =
behavior
of extracting a tar archive having absolute symlinks in it, will change =
with -P...
I do understand the ramifications of allowing symlinks, I just want to =
replicate
the behavior of our current tar.
christos
From: Hisashi T Fujinaka <htodd@twofifty.com>
To: gnats-bugs@netbsd.org
Cc: gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, martin@NetBSD.org
Subject: Re: bin/54467: new tar overwrites symlinks to directories
Date: Sun, 18 Aug 2019 13:39:14 -0700 (PDT)
On Sun, 18 Aug 2019, John D. Baker wrote:
> The following reply was made to PR bin/54467; it has been noted by GNATS.
>
> From: "John D. Baker" <jdbaker@consolidated.net>
> To: gnats-bugs@NetBSD.org
> Cc:
> Subject: Re: bin/54467: new tar overwrites symlinks to directories
> Date: Sat, 17 Aug 2019 20:40:07 -0500 (CDT)
>
> On Thu, 15 Aug 2019 16:25:00 +0000 (UTC), martin@NetBSD.org wrote:
>
> > The new tar(1) is overeager in restoring directories if those already
> > exist as a symlink to another directory.
>
> > This kills updates on machines that have /usr as a symlink to someplace
> > else
>
> This also kills 'named' if one has it running chrooted. The migration
> process copies "/etc/namedb/*" to "/var/chroot/named/etc/namedb/" and
> replaces "/etc/namedb" with a symlink.
>
> After an update, "/etc/namedb" is overwritten back to a directory and
> the subsequent 'etcupdate' reports "root.cache", "bind.keys", etc. as
> missing.
As well as unbound. I was wondering why it kept getting clobbered until
I saw this thread.
--
Hisashi T Fujinaka - htodd@twofifty.com
BSEE + BSChem + BAEnglish + MSCS + $2.50 = coffee
From: Joerg Sonnenberger <joerg@bec.de>
To: Christos Zoulas <christos@zoulas.com>
Cc: gnats-bugs@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
"martin@netbsd.org" <martin@NetBSD.org>
Subject: Re: bin/54467: new tar overwrites symlinks to directories
Date: Sun, 18 Aug 2019 23:21:39 +0200
On Sun, Aug 18, 2019 at 07:12:59PM +0300, Christos Zoulas wrote:
>
> >
> > If you allow symlinks tricks, you can just allow absolute path names
> > too. It really doesn't make any difference as attack vector.
>
> I am not talking about an attack vector, I am just saying that the behavior
> of extracting a tar archive having absolute symlinks in it, will change with -P...
> I do understand the ramifications of allowing symlinks, I just want to replicate
> the behavior of our current tar.
The behavior is not so much about relative or absolute symlinks, but
about symlinks used as of a longer path. The pax behavior is IMO a
major security issue and I don't think "supporting" it alone makes any
sense.
Joerg
From: John Nemeth <jnemeth@cue.bc.ca>
To: Joerg Sonnenberger <joerg@bec.de>, Christos Zoulas <christos@zoulas.com>
Cc: gnats-bugs@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
"martin@netbsd.org" <martin@NetBSD.org>
Subject: Re: bin/54467: new tar overwrites symlinks to directories
Date: Sun, 18 Aug 2019 15:09:48 -0700
On Aug 18, 11:21pm, Joerg Sonnenberger wrote:
} On Sun, Aug 18, 2019 at 07:12:59PM +0300, Christos Zoulas wrote:
} >
} > >
} > > If you allow symlinks tricks, you can just allow absolute path names
} > > too. It really doesn't make any difference as attack vector.
} >
} > I am not talking about an attack vector, I am just saying that the behavior
} > of extracting a tar archive having absolute symlinks in it, will change with -P...
} > I do understand the ramifications of allowing symlinks, I just want to replicate
} > the behavior of our current tar.
}
} The behavior is not so much about relative or absolute symlinks, but
} about symlinks used as of a longer path. The pax behavior is IMO a
} major security issue and I don't think "supporting" it alone makes any
} sense.
Regardless of any kind of question of "purity" (including in
the name of security), it is absolutely unacceptable for the sysinst
upgrade process to break people's systems. If having sysinst use
the -P option by default stops it from breaking people's systems,
then so be it.
}-- End of excerpt from Joerg Sonnenberger
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/54467 CVS commit: src/usr.sbin/sysinst
Date: Tue, 12 Nov 2019 18:04:37 +0000
Module Name: src
Committed By: martin
Date: Tue Nov 12 18:04:37 UTC 2019
Modified Files:
src/usr.sbin/sysinst: util.c
Log Message:
PR 54467: we trust our own sets, extract them with -P to allow symlink
redirection (especially for updates and chroot services - back out
once a better solution for those is implemented)
To generate a diff of this commit:
cvs rdiff -u -r1.35 -r1.36 src/usr.sbin/sysinst/util.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "SAITOH Masanobu" <msaitoh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/54467 CVS commit: [netbsd-9] src/usr.sbin/sysinst
Date: Sun, 17 Nov 2019 13:45:27 +0000
Module Name: src
Committed By: msaitoh
Date: Sun Nov 17 13:45:26 UTC 2019
Modified Files:
src/usr.sbin/sysinst [netbsd-9]: Makefile.inc bsddisklabel.c
configmenu.c defs.h disklabel.c disks.c gpt.c install.c label.c
main.c mbr.c mbr.h msg.mi.de msg.mi.en msg.mi.es msg.mi.fr
msg.mi.pl net.c part_edit.c partitions.c partitions.h partman.c
run.c util.c
src/usr.sbin/sysinst/arch/amd64 [netbsd-9]: md.c md.h
src/usr.sbin/sysinst/arch/ews4800mips [netbsd-9]: Makefile
src/usr.sbin/sysinst/arch/i386 [netbsd-9]: md.c menus.md msg.md.de
msg.md.en msg.md.es msg.md.fr msg.md.pl
src/usr.sbin/sysinst/arch/playstation2 [netbsd-9]: msg.md.de msg.md.en
msg.md.es msg.md.fr msg.md.pl
Log Message:
Pull up following revision(s) (requested by martin in ticket #436):
usr.sbin/sysinst/disks.c: revision 1.55
usr.sbin/sysinst/msg.mi.en: revision 1.24
usr.sbin/sysinst/mbr.c: revision 1.22
usr.sbin/sysinst/disks.c: revision 1.56
usr.sbin/sysinst/msg.mi.en: revision 1.25
usr.sbin/sysinst/disks.c: revision 1.57
usr.sbin/sysinst/arch/playstation2/msg.md.pl: revision 1.3
usr.sbin/sysinst/Makefile.inc: revision 1.30
usr.sbin/sysinst/configmenu.c: revision 1.11
usr.sbin/sysinst/util.c: revision 1.35
usr.sbin/sysinst/gpt.c: revision 1.12
usr.sbin/sysinst/util.c: revision 1.36
usr.sbin/sysinst/arch/playstation2/msg.md.de: revision 1.3
usr.sbin/sysinst/arch/i386/menus.md: revision 1.3
usr.sbin/sysinst/util.c: revision 1.37
usr.sbin/sysinst/part_edit.c: revision 1.11
usr.sbin/sysinst/arch/i386/msg.md.en: revision 1.2
usr.sbin/sysinst/util.c: revision 1.38
usr.sbin/sysinst/part_edit.c: revision 1.12
usr.sbin/sysinst/arch/i386/msg.md.en: revision 1.3
usr.sbin/sysinst/util.c: revision 1.39
usr.sbin/sysinst/part_edit.c: revision 1.13
usr.sbin/sysinst/arch/i386/msg.md.en: revision 1.4
usr.sbin/sysinst/disklabel.c: revision 1.15
usr.sbin/sysinst/bsddisklabel.c: revision 1.30
usr.sbin/sysinst/arch/i386/msg.md.es: revision 1.2
usr.sbin/sysinst/bsddisklabel.c: revision 1.31
usr.sbin/sysinst/arch/i386/msg.md.es: revision 1.3
usr.sbin/sysinst/arch/i386/msg.md.es: revision 1.4
usr.sbin/sysinst/mbr.h: revision 1.4
usr.sbin/sysinst/main.c: revision 1.18
usr.sbin/sysinst/partman.c: revision 1.44
usr.sbin/sysinst/msg.mi.de: revision 1.17
usr.sbin/sysinst/arch/i386/msg.md.fr: revision 1.2
usr.sbin/sysinst/msg.mi.de: revision 1.18
usr.sbin/sysinst/arch/i386/msg.md.fr: revision 1.3
usr.sbin/sysinst/arch/playstation2/msg.md.en: revision 1.3
usr.sbin/sysinst/arch/i386/msg.md.fr: revision 1.4
usr.sbin/sysinst/arch/amd64/md.c: revision 1.2
usr.sbin/sysinst/arch/ews4800mips/Makefile: revision 1.3
usr.sbin/sysinst/arch/playstation2/msg.md.es: revision 1.3
usr.sbin/sysinst/label.c: revision 1.13
usr.sbin/sysinst/Makefile.inc: revision 1.29
usr.sbin/sysinst/label.c: revision 1.14
usr.sbin/sysinst/util.c: revision 1.40
usr.sbin/sysinst/partitions.c: revision 1.5
usr.sbin/sysinst/arch/amd64/md.h: revision 1.8
usr.sbin/sysinst/msg.mi.es: revision 1.18
usr.sbin/sysinst/net.c: revision 1.34
usr.sbin/sysinst/msg.mi.es: revision 1.19
usr.sbin/sysinst/arch/i386/msg.md.pl: revision 1.2
usr.sbin/sysinst/arch/i386/md.c: revision 1.22
usr.sbin/sysinst/msg.mi.fr: revision 1.22
usr.sbin/sysinst/arch/playstation2/msg.md.fr: revision 1.3
usr.sbin/sysinst/arch/i386/msg.md.pl: revision 1.3
usr.sbin/sysinst/arch/i386/md.c: revision 1.23
usr.sbin/sysinst/msg.mi.pl: revision 1.25
usr.sbin/sysinst/msg.mi.fr: revision 1.23
usr.sbin/sysinst/arch/i386/msg.md.pl: revision 1.4
usr.sbin/sysinst/arch/i386/md.c: revision 1.24
usr.sbin/sysinst/partitions.h: revision 1.8
usr.sbin/sysinst/msg.mi.pl: revision 1.26
usr.sbin/sysinst/arch/i386/msg.md.de: revision 1.2
usr.sbin/sysinst/arch/i386/msg.md.de: revision 1.3
usr.sbin/sysinst/arch/i386/msg.md.de: revision 1.4
usr.sbin/sysinst/run.c: revision 1.13
usr.sbin/sysinst/defs.h: revision 1.46
usr.sbin/sysinst/install.c: revision 1.12
usr.sbin/sysinst/defs.h: revision 1.47
usr.sbin/sysinst/install.c: revision 1.13
usr.sbin/sysinst/defs.h: revision 1.48
Add options to the various partitioning stages that allow cloning of
alien partitions (optionally including data).
PR 54467: we trust our own sets, extract them with -P to allow symlink
redirection (especially for updates and chroot services - back out
once a better solution for those is implemented)
Make cloning support optional, so we can save some space on very small
install media.
Drop MBR and cloning support on crunched install media.
Make tar extraction flags depend on our usage of pax-as-tar or bsdtar.
Fix missing newlines in bios match display, pointed out by maxv.
Drop unused variable.
Fix table of bios geomatries
knf style adjustments
Make the bootblock selection menu more sane, pointed out by maxv
Make sure all menus have a translatable exit option (or none at all).
On amd64 support installation with a KASLR kernel, via "custom install"
and selecting the GENERIC_KASLR kernel set.
Setup /prekern and boot.cfg accordingly.
To generate a diff of this commit:
cvs rdiff -u -r1.22 -r1.22.2.1 src/usr.sbin/sysinst/Makefile.inc
cvs rdiff -u -r1.23.2.5 -r1.23.2.6 src/usr.sbin/sysinst/bsddisklabel.c
cvs rdiff -u -r1.10 -r1.10.2.1 src/usr.sbin/sysinst/configmenu.c
cvs rdiff -u -r1.42.2.3 -r1.42.2.4 src/usr.sbin/sysinst/defs.h
cvs rdiff -u -r1.10.2.4 -r1.10.2.5 src/usr.sbin/sysinst/disklabel.c
cvs rdiff -u -r1.44.2.10 -r1.44.2.11 src/usr.sbin/sysinst/disks.c
cvs rdiff -u -r1.6.2.5 -r1.6.2.6 src/usr.sbin/sysinst/gpt.c
cvs rdiff -u -r1.9.2.1 -r1.9.2.2 src/usr.sbin/sysinst/install.c
cvs rdiff -u -r1.10.2.2 -r1.10.2.3 src/usr.sbin/sysinst/label.c
cvs rdiff -u -r1.17 -r1.17.2.1 src/usr.sbin/sysinst/main.c
cvs rdiff -u -r1.19.2.2 -r1.19.2.3 src/usr.sbin/sysinst/mbr.c
cvs rdiff -u -r1.3 -r1.3.2.1 src/usr.sbin/sysinst/mbr.h
cvs rdiff -u -r1.13.2.3 -r1.13.2.4 src/usr.sbin/sysinst/msg.mi.de
cvs rdiff -u -r1.19.2.4 -r1.19.2.5 src/usr.sbin/sysinst/msg.mi.en
cvs rdiff -u -r1.14.2.3 -r1.14.2.4 src/usr.sbin/sysinst/msg.mi.es
cvs rdiff -u -r1.17.2.4 -r1.17.2.5 src/usr.sbin/sysinst/msg.mi.fr
cvs rdiff -u -r1.20.2.4 -r1.20.2.5 src/usr.sbin/sysinst/msg.mi.pl
cvs rdiff -u -r1.33 -r1.33.2.1 src/usr.sbin/sysinst/net.c
cvs rdiff -u -r1.7.2.2 -r1.7.2.3 src/usr.sbin/sysinst/part_edit.c
cvs rdiff -u -r1.1.2.2 -r1.1.2.3 src/usr.sbin/sysinst/partitions.c
cvs rdiff -u -r1.4.2.3 -r1.4.2.4 src/usr.sbin/sysinst/partitions.h
cvs rdiff -u -r1.41.2.1 -r1.41.2.2 src/usr.sbin/sysinst/partman.c
cvs rdiff -u -r1.12 -r1.12.2.1 src/usr.sbin/sysinst/run.c
cvs rdiff -u -r1.29.2.4 -r1.29.2.5 src/usr.sbin/sysinst/util.c
cvs rdiff -u -r1.1 -r1.1.30.1 src/usr.sbin/sysinst/arch/amd64/md.c
cvs rdiff -u -r1.6.2.1 -r1.6.2.2 src/usr.sbin/sysinst/arch/amd64/md.h
cvs rdiff -u -r1.2 -r1.2.2.1 src/usr.sbin/sysinst/arch/ews4800mips/Makefile
cvs rdiff -u -r1.20.2.1 -r1.20.2.2 src/usr.sbin/sysinst/arch/i386/md.c
cvs rdiff -u -r1.2 -r1.2.2.1 src/usr.sbin/sysinst/arch/i386/menus.md
cvs rdiff -u -r1.1 -r1.1.24.1 src/usr.sbin/sysinst/arch/i386/msg.md.de \
src/usr.sbin/sysinst/arch/i386/msg.md.en \
src/usr.sbin/sysinst/arch/i386/msg.md.es \
src/usr.sbin/sysinst/arch/i386/msg.md.fr \
src/usr.sbin/sysinst/arch/i386/msg.md.pl
cvs rdiff -u -r1.2 -r1.2.30.1 \
src/usr.sbin/sysinst/arch/playstation2/msg.md.de \
src/usr.sbin/sysinst/arch/playstation2/msg.md.en \
src/usr.sbin/sysinst/arch/playstation2/msg.md.es \
src/usr.sbin/sysinst/arch/playstation2/msg.md.fr \
src/usr.sbin/sysinst/arch/playstation2/msg.md.pl
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: open->feedback
State-Changed-By: maya@NetBSD.org
State-Changed-When: Tue, 21 Apr 2020 17:25:41 +0000
State-Changed-Why:
I assume this issue is fixed. Do you agree? :-)
State-Changed-From-To: feedback->closed
State-Changed-By: martin@NetBSD.org
State-Changed-When: Tue, 21 Apr 2020 18:31:43 +0000
State-Changed-Why:
Yes, fixed + pulled up
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.46 2020/01/03 16:35:01 leot Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2020
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.