and finish the job. ncurses is now the only Makefile in the tree that
uses it since it wasn't a simple mechanical change, and will be
addressed in a future commit.
I'm starting with the easy cases. The leftovers need to be looked at a
bit more closely.
Note that this change _does_ modify the code of the old tests. This is
required in order to allow the code to locate the data files in the
source directory instead of the current directory, because Kyua
automatically changes the latter to a temporary directory.
Also note that at least one test is known to be broken here. Actually,
the test is not really broken: it's marked as a TODO but unfortunately
Kyua's TAP parser currently does not understand that. Will have to be
fixed separately.
is in accordance with the information provided at
ftp://ftp.cs.berkeley.edu/pub/4bsd/README.Impt.License.Change
Also add $FreeBSD$ to a few files to keep svn happy.
Discussed with: imp, rwatson
data. White space should be accepted anywhere in a base64 encoded
stream, not just after every chunk (4 characters).
Test-scenario:
VmVsb2NpdHkgUmV3YXJkcw==
and
VmVsb2NpdHkgUmV3YXJkcw
==
should both produce "Velocity Rewards"
PR: bin/124739
Submitted by: Mark Andrews <marka@isc.org>
MFC after: 2 weeks
careless users vulnerable to terminal control sequence attacks,
since they expect uudecode to just drop (or overwrite) a file in
the current directory. POSIX also says that the full pathname from
the input should be used when writing a file, which we only do if
the -s (shoot me in the foot) option is specified; therefore this
revision means that you now need to use -s for standard /dev/stdout
handling.
end-of-file checks out of the inner base64 loop, and remove the
trailing whitespace stripper. The latter was added in rev 1.23 but
the actual fix for the problem was in 1.24 -- b64_pton doesn't mind
extra whitespace. (However there's a bogus comment in OpenSSH's
uuencode.c that also mentions problems with trailing whitespace and
b64_pton, but their real problem is the comment field in the key
file.)
Different code that processes the input in similar ways should be
called in similar ways. File-local stuff should be static. Output
errors should be checked for. Diffs sometimes have to be big.
when the filename comes from the untrusted input. This is a work-around
for careless people who don't routinely check the begin line of the file
or run uudecode -i and instead report "vulnerabilities" to CERT.
http://www.kb.cert.org/vuls/id/336083
mode, and be more accurate about identifying begin lines so that spurious
ones don't have to be manually edited out, and be more forgiving about
errors so that -c mode is more useful.
uudecode(1), as this behaviour was explicitly added in revision 1.12 as
the result of PR 2882. Remove space (' ') from the delimiter characters
handed to strtok(3).
Reviewed by: mike
Approved by: mike
Pointy hat to: me
chmodding using an octal mode, as uudecode needs to handle symbolic modes
as chmod and such do.
Suggested by: Tim J. Robbins <tim@robbins.id.au>
Also move meta-character (~ in this case) globbing to only if we are reading
the filename from the encoded file, as otherwise it is the shell's job.
Reviewed by: mike
Approved by: mike
Add `-o' option to uuencode(1) to pipe the uuencoded output to an
arbitrary file, instead of just stdout.
Reviewed by: -standards, mike
Approved by: mike
