Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!news.ecn.uoknor.edu!news.wildstar.net!serv.hinet.net!nctuccca.edu.tw!howland.erols.net!agate!theos.com!deraadt
From: deraadt@theos.com (Theo de Raadt)
Newsgroups: comp.unix.bsd.netbsd.misc
Subject: Re: List of OpenBSD changes
Date: 12 Aug 1996 00:31:15 GMT
Organization: Theo Ports Kernels For Fun And Profit, Inc.
Lines: 206
Message-ID: <DERAADT.96Aug11183115@zeus.theos.com>
References: <DERAADT.96Aug8144209@zeus.theos.com> <4ufqap$44i@jan.et.byu.edu>
<v6lofo6lju.fsf@kechara.flame.org> <4uljtk$jb0@redstone.interpath.net>
NNTP-Posting-Host: zeus.theos.com
In-reply-to: kpneal@interpath.com's message of Sun, 11 Aug 96 21:44:02 GMT
In article <4uljtk$jb0@redstone.interpath.net> kpneal@interpath.com (Kevin P. Neal) writes:
I agree. It seems like such a waste to have three BSD groups all working
on a similar userland. Bugfixes don't get applied to all three BSDs
when perhaps they should (at least, not all of the fixes get applied).
Cool improvements similarly don't get applied uniformly.
Sigh.
We've been managing to deal with copying most of the FreeBSD & NetBSD
userland changes into OpenBSD. Not everything, but I think we're
running in the high 90's. And I've been doing most of it, so if you
think anyone is wasting their time, I guess that'd be me... I don't
see anyone in NetBSD or FreeBSD looking at merging large swaths of
changes from another *BSD project.
I guess I should say a few words...
Over the last two weeks we merged most of the good FreeBSD userland
changes into OpenBSD. They fixed some cute bugs I'd never seen or
heard of. A number of programs got facelifts and added features.
There were security fixes too. And it's nice to add important
historical touches to the biff(1) manpage.
Thanks to Thorsten, Todd Miller, Mickey, and Jason Downs (did i miss
anyone?) for helping me on the latest merge of FreeBSD stuff. I did
not do this single-handledly -- when I ran into something that I did
not understand (or was too lazy to learn more about) I handed it off
to someone else. But noone else did the methodical reading and
searching for tidbits in "cvs log usr.bin | more".
See... FreeBSD is makes it quite easy for OpenBSD to look at their
changes by making the repository available. OpenBSD sup's the FreeBSD
repository in raw format (ie. RCS ,v files) into our CVSROOT space.
Any OpenBSD developer (or anyone else who goes through the effort of
sup'ing the FreeBSD respository ... which _is_ publically available)
can do the following:
[choose a large chunk of disk]
% cvs get freebsd
[go eat dinner, for it will take a while]
% cd freebsd/usr.sbin/modstat
% cvs log modstat.c
RCS file: /cvs/freebsd-src/usr.bin/modstat/modstat.c,v
Working file: modstat.c
head: 1.4
branch:
locks: strict
access list:
symbolic names:
RELENG_2_1_5_RELEASE: 1.3
RELENG_2_1_0_RELEASE: 1.3
RELENG_2_1_0: 1.3.0.4
RELENG_2_1_0_BP: 1.3
RELENG_2_0_5_RELEASE: 1.3
RELENG_2_0_5: 1.3.0.2
RELENG_2_0_5_BP: 1.3
RELENG_2_0_5_ALPHA: 1.3
RELEASE_2_0: 1.1
BETA_2_0: 1.1
ALPHA_2_0: 1.1.0.2
keyword substitution: kv
total revisions: 4; selected revisions: 4
description:
----------------------------
revision 1.4
date: 1996/08/08 07:58:07; author: joerg; state: Exp; lines: +3 -2
Fix a potential buffer overflow condition.
Submitted by: Somebody on -hackers, ooops, i've already deleted that mail
----------------------------
revision 1.3
date: 1995/04/20 05:08:53; author: wpaul; state: Exp; lines: +2 -3
Undo the stupidity I inflicted on these files and replace it with
some (hopefully) less offensive stupidity:
If we detect that a user has loaded a module that fails to initialize
itself correctly, panic. There really isn't a safe way to recover from
something like this; we can't know that the module is bad until after
the entry point is called, by which time it's too late to do anything
about it.
----------------------------
revision 1.2
date: 1995/04/18 02:19:17; author: wpaul; state: Exp; lines: +4 -3
Small fixups to use LM_UNKNOWN type, also fix slight formatting
offset problem in banner printf().
----------------------------
revision 1.1
date: 1994/08/19 12:14:06; author: davidg; state: Exp;
Terry Lambert's loadable kernel module support - modstat utility with
improvements from the NetBSD group.
=============================================================================
Hmm, the change in revision 1.4 looks interesting!
% cvs diff -bc -r1.3 -r1.4 modstat.c
Index: modstat.c
===================================================================
RCS file: /cvs/freebsd-src/usr.bin/modstat/modstat.c,v
retrieving revision 1.3
retrieving revision 1.4
diff -b -c -r1.3 -r1.4
*** modstat.c 1995/04/20 05:08:53 1.3
--- modstat.c 1996/08/08 07:58:07 1.4
***************
*** 29,35 ****
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
! * $Id: modstat.c,v 1.3 1995/04/20 05:08:53 wpaul Exp $
*/
#include <stdio.h>
--- 29,35 ----
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
! * $Id: modstat.c,v 1.4 1996/08/08 07:58:07 joerg Exp $
*/
#include <stdio.h>
***************
*** 72,79 ****
{
struct lmc_stat sbuf;
if (modname != NULL)
! strcpy(sbuf.name, modname);
sbuf.id = modnum;
--- 72,80 ----
{
struct lmc_stat sbuf;
+ sbuf.name[MAXLKMNAME - 1] = '\0'; /* In case strncpy limits the string. */
if (modname != NULL)
! strncpy(sbuf.name, modname, MAXLKMNAME - 1);
sbuf.id = modnum;
Ok, now that's what CVS access is all about. You can see WHY the
change was made, and you can look at exactly WHAT was changed.
Makes sense?
Sorry for choosing to show a security hole that isn't well publicized
yet. Full disclosure of security bugs is good, it causes them to get
fixed. I hope your operating system has it fixed. (OpenBSD had a
different fix a few days before they heard about it :-)
Because FreeBSD makes their repository available in this way it took
me only about 3 days to handle most of bin, sbin, libexec, usr.sbin,
and usr.bin. There's a few outstanding pieces, like `ed' because we
haven't judged yet if the FreeBSD changes are correct.
OpenBSD makes the repository available in a similar fashion. One
benefit of the OpenBSD `anoncvs' service is that we are able to make
changes show up quicker, roughly 4 hours latency between when
developers can see the changes, and when other people can. Another
benefit is that you don't need the huge amount of diskspace I'm using
to store the ,v files and a checked out repository...
Let me chat a bit more about why CVS access is important: when looking
at a changed file, knowing WHY a change was made is often incredibly
important. That's what the cvs log message is for, but also it is
very important to look at the diffs for any SINGLE change all by
itself. NetBSD does not make their sources available in this form
which is a royal pain in the F*@Q#($ ass. I won't talk about what it
takes to track NetBSD changes, except that it is roughly 10x as much
effort (and, that may be a reason why noone in FreeBSD has gone
through the effort of looking at many NetBSD changes).
So.. today after sup'ing the FreeBSD tree, I got a report that they
had changed the following files which are of interest to me:
SUP Receiving file src/etc/mtree/BSD.include.dist,v
SUP Receiving file src/etc/mtree/BSD.usr.dist,v
SUP Receiving file src/lib/libc/regex/cclass.h,v
SUP Receiving file src/lib/libc/regex/engine.c,v
SUP Receiving file src/lib/libc/regex/regcomp.c,v
SUP Receiving file src/lib/libc/regex/regex2.h,v
SUP Receiving file src/share/mk/bsd.lib.mk,v
SUP Receiving file src/share/mk/bsd.man.mk,v
SUP Receiving file src/usr.bin/colldef/NOTE,v
SUP Receiving file src/usr.bin/wall/wall.c,v
Armed with a list like this, and with "cvs diff -bc -rHEAD" it is easy
to see if anything important has happened. Then we talk about it and
merge the good stuff.
In the free operating system community, there is no greater praise
than theft of a source change. (with credit given!)
Repeating what you said once more:
on a similar userland. Bugfixes don't get applied to all three BSDs
when perhaps they should (at least, not all of the fixes get applied).
Cool improvements similarly don't get applied uniformly.
I think you'd be shocked *to tears* if you knew how many useful and
important fixes don't get applied by FreeBSD & NetBSD. On the other
hand.... FreeBSD's kernel flies.
--
This space not left unintentionally unblank. deraadt@theos.com