I'm wondering out loud if these versions should follow the openbsd shlib
major minor numbers. That is where we are careful about semantic
versioning for api change/add/remove
One note.
If that is decided, on occasion libressl-portable could skip a release
number. Probably fine for everyone.
Regarding other strict-alignment architectures, em(4) is probably one
of the more popular gigabit ethernet options for those architectures
that have PCI slots. I don't think any of these machines are severely
memory starved, but memory might be limited to something like 256MB of
physical
Awful lot of noise wherein people tell someone else what they should
need to do with their time and their code.
To the best of my knowledge, we've cited and/or thanked Maxime in the
commits fixing the issues he's found, and we're glad to continue to
receive his reports, whether or not
ludovic coues schreef op 2015-08-10 23:29:
2015-08-10 22:56 GMT+02:00 Martin Pieuchot m...@openbsd.org:
On 30/07/15(Thu) 12:18, Ludovic Coues wrote:
Right now, an USB_REQUEST ioctl will fail with an EBADF error if done
on a device opened as read-only. With this patch, the ioctl will fail
I am also of the opinion that if somebody/a method can discover bugs,
they should report them. And if they can't, that method should be
disclosed to allow others to continue their work.
And my opinion is that Sam should back his opinions with lots of
money.
It feels wasteful to develop a seemingly comprehensive and modular code
scanner which will inherently find heaps of bugs, and then not release
it or allow others to work with it.
Sam, since you think throwing opinions out there is valuable
Let me give me yours.
I think you should talk
On 2015/08/04 22:40, Stefan Fritsch wrote:
someone mentioned to me the i217-LM problems that were reported on misc
end of May. It is possible that the patch below helps.
This fixes my Dell poweredge T20:
em0 at pci0 dev 25 function 0 Intel I217-LM rev 0x04: msi, address
f8:b1:56:...
There is no way this diff is going in.
When softdep is 100% reliable, then we can talk.
Enabling it prematurely is ridiculous. Considering the defects
are clearly described as lockups, disk space corruption -- with
such a suggestion I must ask --who's side are you on??
There was a great
On 2015-07-23, Michael McConville mmcco...@sccs.swarthmore.edu wrote:
--- sbin/dump/main.c23 May 2015 05:17:20 - 1.56
+++ sbin/dump/main.c15 Jun 2015 23:16:10 -
@@ -115,7 +115,7 @@ main(int argc, char *argv[])
usage();
obsolete(argc,
This is extremely premature.
The tame() in my devtree already has major incompatible changes.
So, what's the story with the -l option? What change/fix in OpenBSD
base requires it?
Nothing requires it explicitly, more the question of if having the
ability for cat to set exclusive locks on its stdout so that multiple
calls to the same cat command will cause the the output to be
This is another trivial patch, but I've always found the disklabel
message No label changes confusing. For example, if you print (p), add
a label (a), write (w), print to check your changes (p), and then quit
(q), it seems odd to be told No label changes.
Index: sbin/disklabel/editor.c
Ted Unangst wrote:
Jeremy Evans wrote:
As an aside, crypt(passwd, $2) returns : instead of NULL. I'm not
sure if that's a security issue, but I think it is and we should fix it.
I'll see if I can get a patch for that and send it to tech@.
This is a weird edge case where niels
The only objection I can see is something stupid that does not check
the error condition, derefs NULL, drops a core file in an insecure
place, and therefore leaks information.
To my mind this is a buggy program, combined with an insecure configuration,
and we shouldn't be trying to save
my perspective is: absent clear knowledge of what programs are doing, attempts
to second guess them in a library function are perilous. let us be standards
compliant, and then at least any resulting holes are clearly the program's
fault.
such programs always deference the pointer.
So I agree
I have been working for a while on a subsystem to restrict programs
into a reduced feature operating model.
Other people have made such systems in the past, but I have never been
happy with them. I don't think I am alone.
Generally there are two models of operation. The first model requires
a
Sorry, should have made things clearer. I just meant that chroot was
a bad comparison. I can't see any sane use of a tame(1) at the
moment.
No, no no, Ted's comments are completely valid.
You cannot replace the narrow chroot calls in the privsep daemons with
chroot(8) run externally.
Any
On Mon, Jul 20, 2015 at 12:04:43PM -0400, Ted Unangst wrote:
chroot is probably the best comparision. yes, we provide a chroot(1), but
There is no chroot(1). :p
practically nothing uses it. everything is instead calling chroot(2) on its
own. the things that do use chroot(1) are doing so
Ability to define alias in the doas config file might be nice. Just
like ssh with the ssh_config file.
I have always wanted a .lsrc file, which would allow me to override
the special options for ls, as well. That's kind of what you are
talking about, right?
No, I think you are serious.
And
Less code running with setuid root, the better.
That is the entire point.
There are pccon* terminal descriptions for AMD/Intel PC consoles
in /etc/termcap.I have been using them on various computers
since 2011 without problems.
I suggest to use pccon0 instead of vt220 by default
for amd64 and i386because vt220 has not good support
of navigation and function keys
> First I added a custom reset function, but it turned out the problem was
> elsewhere. So the current driver is just pretty printf'ing the model and
> the phy.
>
> And you're right, it's not worth getting this in tree so forget about
> this diff.
correct. ukphy is named a bit strangely.
> > From: "Ted Unangst"
> > Date: Fri, 23 Oct 2015 03:47:56 -0400
> >
> > ul appears somewhat useless for its intended purpose.
> >
> > echo _xxx_ | ul does not result in underlined text in an xterm, so I doubt
> > many people are using this.
> >
> > Unlike, say, mandoc,
>>From wcrtomb(3):
>
> The wcrtomb() function conforms to ISO/IEC 9899/AMD1:1995 (``ISO C90,
> Amendment 1''). The restrict qualifier is added at ISO/IEC 9899/1999
> (``ISO C99'').
>
>This wording is confusing. Is it implying that we don't use a restrict
>qualifier? (We do.)
>
>If a
does anyone use rip6query?
we don't have a ripquery
I cannot imagine the use for this too. Either you are using rip6
protocol, or you aren't. Does this perhaps still exist because
route6d isn't like our other daemons with a "fib-update" mode?
> Damien Miller wrote:
> > rather than scattering hacks in each program that needs to
> > output utf8 to the console, how about making something
> > for libutil that they all can use?
>
> Yes, that is certainly the plan, but I think it's easier to see what's needed
> if we convert a few programs
> Jérémie Courrèges-Anglas wrote:
> > Michael McConville writes:
> > > It looks like it can be pretty easily replaced with calls to err(3),
> > > errx(3), warn(3), warnx(3), etc.
> >
> > Not sure about this, you'd have to repeat the same code over and over to
> > print the
Since people are typing blind, can you add support for ^U as well?
> I want correct typing mistakes when booting from softraid crypto disks.
> Can we handle at least the backspace key, plz^Hease? :)
>
> diff --git sys/arch/amd64/stand/libsa/softraid.c
> sys/arch/amd64/stand/libsa/softraid.c
>
> I was just trying to pledge(2) spamd(8), nevertheless came across 2
> priviliges kern_pledge.c is missing for this to work.
>
> First spamd(8) needs to read sysctl kern.maxfiles in order to see if it
> can launch with that value or not, and second if the multicast options
> are passed as
> Also, I wonder what the point of having a sanity check against
> kern.maxfiles at all is, especially with the arbitrary-feeling
> additional rule of "maxcon may not exceed kern.maxfiles - 200". It feels
> redundant to me, and it sort of makes a promise of protection it can't
> uphold.
That code
> On 10/24/15 06:46, Reyk Floeter wrote:
> > vether doesn't help as it is not transmitting any traffic.
> > in other words, "vether is a bridge endpoint" "pair is a bridge link"
> This may be a dead topic, but doesn't bridge_output() transmit for
> vether(4)?
> Or am I missing the point entirely?
> On Mon, Oct 26, 2015 at 8:46 AM, Michael McConville wrote:
> > We have a pretty strong guarantee that it can only happen once per
> > process...
> ...
> > --- sys/sys/syscall_mi.h9 Oct 2015 01:17:18 - 1.11
> > +++ sys/sys/syscall_mi.h26 Oct 2015
> Not sure how people feel about these annotations. This is a pretty
> classic use case, though.
No, the classic case is when the condition is a single variable, rather
than a condition "always true && rarely true".
> Grmbl. I've hard a hard time trying to understand *why* this would be
> needed. The answer is pledge(2), who makes chmod(2) fail with EPERM
> instead of killing the process.
>
> I find this confusing. IMO pledge(2) should let the kernel do the
> appropriate security checks for chown(2).
Your process here is really strange. You see something, then you
write a diff before answering your own question, then you send a mail
asking a question with the diff already present as an investment.
In OpenBSD, we have a 20 year old repository that explains why a
change was made. Before the
I really want to delete telnet entirely, but there are still occasions
when someone might want to use it on an intranet. Other telnet tools
are probably worse shape.
This adds two pledge calls.
The subshell and skey support are removed (you can use ^Z), and you
cannot start a new telnet
> > I really want to delete telnet entirely,
>
> I often use it for testing unencrypted SMTP and HTTP across the
> Internet. Which tool would you recommend for that purpose?
nc(1).
> You might wish to cross-check these three points though:
>
> * Does "inet" actually allow the following
> This straightforward pledge("stdio") is one of the last uncommitted ones
> from Theo's big 'tame in userland' diff and seems to have been
> overlooked so far.
I think arch.c gains no value from being pledged. It adds a system
call to a program which makes no user-input decisions.
> > > > I really want to delete telnet entirely,
> > >
> > > I often use it for testing unencrypted SMTP and HTTP across the
> > > Internet. Which tool would you recommend for that purpose?
> >
> > nc(1).
>
> I use telnet fairly often for connecting to things like crappy switches,
> crappy
> > On 2015/11/13 09:59, Theo de Raadt wrote:
> > > > > I really want to delete telnet entirely,
> > > >
> > > > I often use it for testing unencrypted SMTP and HTTP across the
> > > > Internet. Which tool would you recommend for that
> It is similar to (optional) XMODEM/ZMODEM disciplines over serial, IMO.
No, it is similar to over the INTERNET, because the INTERNET
is nothing at all like a serial line, the later generally being nicely
contained to a single room.
> The goal is to delete classic telnet entirely and make it
> Can telnet be extended to coexist with nc -F? Manual only mentions ssh.
Please don't email while driving your horse buggy.
> This patch changes the default setting to 1.5 *
> (number_of_cpus_in_system) instead, which I find better matches modern
> behaviour.
A larger number is sensible in this position.
I would propose 8. I don't agree with a calculation like that; the
amount of work a system can do should not be
> On 16/11/15(Mon) 10:03, Ricardo Mestre wrote:
> > Hello!
> >
> > Like Benoit said, monitor still needs dns all the time, but since pledge
> > was being called there again with dns pledge then I thought it wouldn't
> > abort. Taking that into consideration and looking at it a little bit
> >
> Both OSs define getdtablesize() as sysconf(_SC_OPEN_MAX). sysconf(3)
> returns a long, so it seems more correct to make getdtablesize(3) return
> a long or ssize_t. The return value has to be signed because sysconf(3)
> is specified by POSIX to return -1 and set errno on failure.
Don't be
> > Both OSs define getdtablesize() as sysconf(_SC_OPEN_MAX). sysconf(3)
> > returns a long, so it seems more correct to make getdtablesize(3) return
> > a long or ssize_t. The return value has to be signed because sysconf(3)
> > is specified by POSIX to return -1 and set errno on failure.
>
>
> If only rename(2)'ing then it only needs "stdio rpath cpath",
> nevertheless if we need to copy to a different partition it also needs
> "wpath fattr" for writing and chmod/chown operations, and finally "proc
> exec" are needed due to (extracted directly from mv(1)'s man page) ->
> "Should the
> On Mon, Oct 26, 2015 at 04:40:12PM +0100, Claudio Jeker wrote:
> > ospfd has some issues with self-originated networks and building summary
> > entries for those in case the router is an ABR (area border router).
> > This diff should hopefully fix all of the troubles. It changes a bit the
> >
> There's limited backward compatibility so you can run a new crontab
> with an older cron daemon.
Why?
That makes no sense. This kind of compat bubbles up. It should
be deleted within a week, so why bother writing it...
> I am trying to add pledge(2) to audioctl(1),
> but it gets SIGABRT'ed under any pledge promises.
> (Indeed, I have pledged everything in a desperate attempt.)
>
> Looking at gdb and a ktrace, /dev/audioctl gets opened fine,
> but then it fails on an ioctl in getinfo()
>
> 23472 audioctl CALL
> > > > i don;t know how these implementations work, so it's hard to say.
> > > > perhaps they are interpolated. maybe use cvs to track down the author
> > > > and ask them?
> > > >
> > > > whatever the outcome, if you want to change this text you probably want
> > > > to adjust a few more:
> > >
> > I think it should be moved into Attic. It's not like we've been nice to
> > the pcc tree-import either after it lacked attention.
>
> I agree, it has been unlinked from the build for more than 5 years.
I don't agree. I still have some hope.
Yes, it has problems. But go look at the code in
> 1. I don't see much reason to mention calloc() as an alternative to
> reallocarray() when it's the worse option.
calloc() still remains the portable option. Something should probably
still be mentioned here, otherwise people fall back to unchecked
malloc -- no matter what is stated further
less is code imported on a regular basis from upstream.
Look at the commit log.
> Every one of these is in a var declaration, so a megadiff is probably
> the easiest way to do it.
>
> ok?
>
>
> Index: brac.c
> ===
> RCS file:
Why?
We don't have decnet code either, yet it is nice to sniff it if you
see it.
> Some time ago mpi removed the sl(4) driver, IIUC this makes a bunch of
> code useless in tcpdump.
>
> The diff below only removes the define. If people prefer, I could also
> kill some noise by removing the
I don't think it makes it clearer; it makes it more confusing.
The usage messages of programs are not a sufficent grammer to exactly
describe what conflicts with what. Taken too far, it would bewilder
newcomers.
> the command line arguments -h and -R for chgrp and chown are mutually
>
>On Sat, Nov 07, 2015 at 12:12:55AM -0500, Michael McConville wrote:
>> Ted Unangst wrote:
>> > less has a peculiar estrdup function. unlike ecalloc etc., it only
>> > prints an error but doesn't quit. But the callers don't seem to check
>> > for null. And in many places they call a function
> I think we should move to the Illumos fork, it looks good. I've got it
> building easily enough, will take a look at porting our changes at some
> point.
I was the first one to bring it up with Todd about 4 weeks ago.
I am a big fan of this, becuase it will allow us to pledge^Wrefactor
it
> I can tell that rev can be VERY large... Wait, am I remembering these
> (Open)CVS internals all of a sudden again? :P
Some of us have memories wired for guilt.
> ksh does a little dance to try and gift history files to their original owner
> if it's somehow running as a different user. this of course only works as
> root, and is probably a terrible idea.
When I found this with tame, I got worried about the implications of
how ksh is opening the file in
>Does it make sense to reference the syscall numbers in pledge(2)?
No not really. By 5.9 release the kernel printf's will go away,
and people won't get such alerts. Maybe they will get kernel log's,
but I will consider generating them with system call names.
> Here's an attempt to tighten compress/gzip's pledge:
>
> Due to the use of fts(3), we always require rpath, even for
> gzip out.
>
> We only write to stdio and never to any files...
> * if we are in cat mode (-c, zcat)
> * if we are in test mode (-t)
> * if there are no file arguments and
> It looks like csh would currently need to pledge("id") in order for the
> builtin nice to work --- setpriority() is called in three places
> depending on how nice is invoked. However, adding "id" to a shell
> seems a bit scary.
>
> Would it be preferable to mark
> [SYS_setpriority] =
> I am however curious to this patch. By pledging ksh with exec it appears
> to me that once a pledged process is execve(2)d it looses it's already
> made pledges.
Yes, because that is what it needs.
> This to me seems like
> something that might be undesirable (find remote code
> Some isfoo(char) usages crept back into ftp
Hmm. I wonder how we can keep these errors out of base.
Having to re-audit all the time is painful.
> Currently, npppd's PRIVSEP_OPEN message (abstracted as priv_open())
> accepts arbitrary open() flags and passes a mode argument. That
> seems...unwise.
>
> In particular, it never passes O_CREAT, so the mode argument isn't needed.
> Indeed, the only open 'flags' it needs are O_RDONLY and
> Index: sys/kern/kern_pledge.c
> ===
> RCS file: /var/cvs/src/sys/kern/kern_pledge.c,v
> retrieving revision 1.4
> diff -u -p -r1.4 kern_pledge.c
> --- sys/kern/kern_pledge.c9 Oct 2015 05:30:03 - 1.4
> +++
> as well as this:
>
> > --- tcpdump/print-ipsec.c
> > +++ /tmp/cocci-output-17550-499a71-print-ipsec.c
> > @@ -101,7 +101,7 @@ esp_init (char *espspec)
> > s[0] = espkey[2*i];
> > s[1] = espkey[2*i + 1];
> > s[2] = 0;
> > - if (!isxdigit(s[0]) ||
> Actually, plain old printf should be OK in ping.c since buffering
> is disabled for ping -f. If you want to keep dprintf(), I think
> we can lose the setbuf() call. Whatever you decide, it would
> be nice to make ping6.c match.
No, disagree strongly.
ping is doing this inside a signal
> I was wondering if it would be possible to allow the override the
> definition of MACHINE_ARCH /__MACHINE_ARCH in amd64/param.h by wrapping
> them around ifndef statement.
>
> Index: sys/arch/amd64/include/param.h
> ===
> RCS file:
> Ah, I didn't realize that pinger() was still called via a signal
> handler in ping. It looks like ping6 is better in this regard.
ping and ping6 need to be merged, as happened to traceroute.
First step: make all ping6's options match ping options. Rename
ping6 options with wild abandon if
> When guenther@ switched isatty(3) to F_ISATTY, he forgot ttyname(3).
That was a change I made.
> With this, simple callers of ttyname(3) like tty(1) and who(1) no
> longer need pledge("tty").
That is correct, these programs could do without the ability to set
modes on the tty. I think this
Our tree uses lex pretty much as-is from upstream, so this refactoring
isn't the way to go.
If you find an actual bug however.. fix them, using the established
practice.
> When scanning for is*() function uses with signed chars, I found that
> lex(1) uses an unecessary #define for unsigned char.
> Assume you have a bad program1 and you write your tame(2)-ed program2 that
> disallows execution of program1. But you also have to use my un-tame(2)-ed
> program3 that allows execution of program1. How does your tame(2)-ed
> program2 protect you now against executing program1 ? You still risk
> The problem of exec(2) is if we permit it (without herited tame flags)
> your program has a way to go out his expected behaviour. For example, if
> a tamed program has a bug that permit execution of code, the attacker
> would just has to do "exec(something-else)" to escape the imposed
> policy.
Many will have observed that pledge(2) usage is being pushed into the
source tree at a very rapid pace.
I'd like if everyone looks in their dmesg logs for pledge errors. But
please don't immediately mail a report! Instead, look for if someone
else reports an error in the same command. If noone
Kenneth R Westerback, 08 Jul 2015 10:13:
The OpenBSD Foundation is happy to announce that Microsoft has made
a significant financial donation to the Foundation. This donation
is in recognition of the role of the Foundation in supporting the
OpenSSH project. This donation makes Microsoft
it flatters me somewhat that you read so much into
my simple astonishment about a news item that does
in most geek circles provoke the response no way,
hell froze over.
I quote from your original mail:
this is very impressive news, although for me for all
the wrong reasons.
Have all
Index: tcpdump.c
===
RCS file: /cvs/src/usr.sbin/tcpdump/tcpdump.c,v
retrieving revision 1.70
diff -u -p -r1.70 tcpdump.c
--- tcpdump.c 18 Apr 2015 18:28:38 - 1.70
+++ tcpdump.c 11 Jul 2015 20:35:11
This moves the BIOCGSTATS ioctl operation done by the tcpdump process
(at ^C time, but not at -c count expiration) into a service provided
by the privsep monitor.
Had a bit of help from canacar, who wrote the original privsep code
with otto.
Will be needed for tame.
Index: privsep.c
> I only just noticed that, trying to watch a video while having a web
> browser open at the same time, I don't get any sound.
>
> Only going through recent daily insecurity emails, had I found out that:
>
> sndiod_flags=
>
> in /etc/rc.conf, has been changed to:
>
> sndiod_flags=NO
>
>
> Anybody see this on shutdown?=C2=A0
>
> shutdown -hp now
>
> *** FINAL System shutdown message from i...@ianm-openbsd.xxx.edu.au
>
> System going down IMMEDIATELY=C2=A0
>
> System shutdown time has arrived=20
>
> halt: revoke: Inappropriate ioctl for device
I
> On 2015/11/14 14:01, David CARLIER wrote:
> > Might be indeed, there are other use cases with valgrind and protexec
> > and so on ..., utrace might be a good suggestion too except maybe a
> > need for an exception in pledge's side then.
>
> btw, valgrind currently ssems to be quite broken with
> Don't tell me this fixes SATA on the xserve G5...
I did try that back in the day. I cranked all the delays, and
nothing helped. No interrupts came in, ever.
> I ve tried to discuss this point with Otto Moerbeek but he might be
> very busy so I throw the topic here if you do not mind ...
>
> I have the habit to enable MALLOC_STATS but with the recent pledge
> feature, it s now difficult to debug some pledged applications with
> MALLOC_OPTIONS=D as,
> An idea would be to open the fd at init time, which should be early
> enough for most cases (i.e. before the first pledge(2) call). Big
> drawback is the open fd all the time until program exits.
Keeping a fd open through libc runtime is not going to fly. It isn't
just the fragility of it.
security model.
How many users of that functionality will there be?
We only need to concern ourselves with the cost; you have to justify
the benefit. How many people were doing this with sudo, and how many
will need this with doas?
While I understand it's a good idea to limit
Sorry, I think adding an option is too much. I just committed halex's o=
riginal
diff to only change the type. I thought he was going to do that by now.=
Hi Ted,
The thing is, my patch doesn't do the same thing at all as the one which
adds auth-doas. My patch lets the user choose
On Thu, Aug 27, 2015 at 10:13:25AM -0600, Theo de Raadt wrote:
Why not strdup?
And now with strdup() as suggested by Theo.
ok, because such style is not really a leak.
Index: usr.sbin/syslogd/syslogd.c
===
RCS file: /data
How many users of that functionality will there be?
We only need to concern ourselves with the cost; you have to justify
the benefit. How many people were doing this with sudo, and how many
will need this with doas?
My current model is to use my yubikey when sudo'ing. Occasionally
This is for those of you interested in tame, and skilled enough to
play along.
This is a set of almost 100 diffs to programs in the tree to use tame.
These have been done by myself, doug, florian, semarie, and a few
other people I forget. I would make a rough guess these changes took
about 100
* pool_allocator_multi_ni: A multi page allocator that is *not* safe
for use in interrupts. Also less efficient than
pool_allocator_single. It allocates kva from kernel_map, which is
significantly more plentyful.
We are the knights who say non-interruptable. Honestly, ni feels
a
just saw that cat's *main* function does never return even though there is a
return value,
exit(3) is called instead.
Is there any reason why or is it just historically, cause it's a bit
confusing?
If exit(3) is always called, than why not changing the return value to *void*?
Other
As suggested by deraadt@ and tobias@ it might be better to use the
*return* statement instead of exit(3)
inside the *main* function, to let the stack protector do its work.
This diff removes such calls in all *src/bin/* tools, except those
who already use it. I think I didn't miss a call
> Martijn van Duren wrote:
> > Hello tech@,
> >
> > I took a quick glance at ksh and one of the first things I noticed was
> > that it uses some sanatizing code on argv. When looking at execve(2) I
> > see that EINVAL or EFAULT are returned when argv isn't properly
> > formatted. I've also
Seems good to me.
I wouldn't bother with disabling this in SMALL_KERNEL. Space
is not short enough to complicate the code for ~200 bytes.
> To make syslog reliable, I want to see log messages about failed
> log atempts. sendsyslog(2) seems a good place to detect and report
> the problem.
>
>
>The only pool_get() call uses PR_WAITOK, and the pool_put() calls are
>only done from the nfsd main loop, so process context.
OK. Thanks that explains how one makes sure..
>No I'm not an NFS hacker!
3 kettenis
Actually lots of people are NFS hackers.
1 aaron
1 damien
1 dlg
1
> > Not attaching the diff because of the size, available at
> > http://rhaalovely.net/~landry/stuff/sqlite-3.8.11.1.diff.gz
>
> And i forgot to mention that it went in an amd64 bulk build without
> fallout, thanks to ajacoutot@
So, one architecture has been tested. Now there is a request for
This is a really stupid way to treat the base source tree.
> thanks to the hard work of jturner@, here's a 650kb gzipped update to
> sqlite 3.8.11.1, bumping shlib to 31.0. This is needed for upcoming
> firefox 41 update, but anyone is welcome to look into the update itself.
>
> Not attaching
>Michael McConville wrote:
>> Index: mv.c
>> ===
>> RCS file: /cvs/src/bin/mv/mv.c,v
>> retrieving revision 1.40
>> diff -u -p -r1.40 mv.c
>> --- mv.c 24 Aug 2015 00:10:59 - 1.40
>> +++ mv.c 14 Sep 2015 13:38:13 -
601 - 700 of 2804 matches
Mail list logo