<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE report PUBLIC "-//FreeBSD//DTD FreeBSD XML Database for Status Report//EN"
                        "http://www.FreeBSD.org/XML/www/share/sgml/statusreport.dtd">

<!-- $FreeBSD$ -->

<report>
  <date>
    <month>September-October</month>
    <year>2002</year>
  </date>

  <section>
    <title>Introduction:</title>

    <p>Another busy pair of months at the FreeBSD Project have brought
    substantial maturity and feature completeness to the fledgeling
    5.0-CURRENT branch.  And just in time too, because by the time
    you read the next status report, we hope that you'll have
    FreeBSD 5.0 running on your desktop!  Over the past two months,
    we've seen an upgrade of sparc64 to Tier 1 (Fully Supported)
    status, integration of a high quality storage encryption module,
    the commit of hardware-accelerated IPsec support, the addition of
    a general-purpose "Device Daemon" to process hardware
    attach/detach events to replace earlier single-purpose and
    bus-specific daemons, the commit of RAIDFrame, and the improved
    maturity of the TrustedBSD work.  We've also seen another
    successful release of the 4.x branch, 4.7-RELEASE, which will
    continue to be the production supported platform as 5.X is brought
    in for landing.</p>

    <p>Over the next two months, the FreeBSD Project will be focused
    almost entirely on making 5.0 a success: improving system
    stability and performance, as well as increasing the pool of
    applications that build and run on 5.0.  The Release Engineering
    team will have announced the 5.0 code freeze, and released DP2 by
    the time you read this.  Following DP2 will be a series of Release
    Candidates (RC's), and then the release itself.  If you're
    interested in getting involved in the testing process, please lend
    a hand -- a spare box and a copy of the DP and RC ISOs burnt onto
    CD will make a difference.  The normal caveats associated with
    pre-release versions of operating systems apply!  You may also be
    interested in reading the Early Adopter's guide produced by the
    Release Engineering team to help determine when a transition from
    the 4.x branch to the 5.x branch will be appropriate for you and
    your organization.</p>

    <p>Thanks,</p>

    <p>Robert Watson, Scott Long</p>
  </section>

<project>
  <title>Bluetooth stack for FreeBSD (Netgraph implementation)</title>

  <contact>
    <person>
      <name>
        <given>Maksim</given>
        <common>Yevmenkin</common>
      </name>
      <email>m_evmenkin@yahoo.com</email>
    </person>
  </contact>

  <links>
    <url href="http://www.geocities.com/m_evmenkin/">Latest snapshot</url>
    <url href="http://bluez.sf.net">Linux BlueZ stack</url>
    <url href="http://sourceforge.net/projects/openobex">OpenOBEX</url>
  </links>

  <body>
    <p>I'm very pleased to announce that another engineering release is
    available for download at
    http://www.geocities.com/m_evmenkin/ngbt-fbsd-20021104.tar.gz</p>

    <p>This release features minor bug fixes and new OpenOBEX library
    port. The snapshot includes support for H4 UART and H2 USB transport
    layers, Host Controller Interface (HCI), Link Layer Control and
    Adaptation Protocol (L2CAP) and Bluetooth sockets layer. It also
    comes with several user space utilities that can be used to configure
    and test Bluetooth devices. Also there are several man pages.</p>

    <p>Service Discovery Protocol (SDP) port has been updated to
    version 0.8. (ported from BlueZ-sdp-0.8). Most of the RFCOMM
    issues have been resolved and now rfcommd works with Windows
    (3COM, Xircom and Widcomm) and Linux stacks.</p>

    <p>New supported USB device - EPoX BT-DG02 dongle. Also I have
    received successful report about Mitsumi USB dongle and C413S
    Bluetooth enabled cell phone (L2CAP and SDP works, waiting on
    RFCOMM report).</p>

    <p>I'm currently working on OBEX server (Push and File Transfer
    profiles) which will be based on OpenOBEX library (included
    in the snapshot).</p>
  </body>
</project>

<project>
  <title>BSDCon 2003</title>

  <contact>
    <person>
      <name>
        <given>Gregory</given>
        <common>Shapiro</common>
      </name>
      <email>gshapiro@FreeBSD.org</email>
    </person>
  </contact>

  <links>
    <!-- A hypertext link with a description... -->
    <url href="http://www.usenix.org/events/bsdcon03/cfp/">BSDCon 2003 Call For Papers</url>
  </links>

  <body>

    <p>The BSDCon 2003 Program Committee invites you to contribute
    original and innovative papers on topics related to BSD-derived
    systems and the Open Source world. Topics of interest include
    but are not limited to:</p>

    <ul>
      <li>Embedded BSD application development and deployment</li>
      <li>Real world experiences using BSD systems</li>
      <li>Using BSD in a mixed OS environment</li>
      <li>Comparison with non-BSD operating systems; technical,
      practical, licensing (GPL vs. BSD)</li>
      <li>Tracking open source development on non-BSD systems</li>
      <li>BSD on the desktop</li>
      <li>I/O subsystem and device driver development</li>
      <li>SMP and kernel threads</li>
      <li>Kernel enhancements</li>
      <li>Internet and networking services</li>
      <li>Security</li>
      <li>Performance analysis and tuning</li>
      <li>System administration</li>
      <li>Future of BSD</li>
    </ul>

    <p>Submissions in the form of extended abstracts are due by
    April 1, 2003. Be sure to review the extended abstract
    expectations before submitting. Selection will be based on the
    quality of the written submission and whether the work is of
    interest to the community.</p>

    <p>We look forward to receiving your submissions!</p>

  </body>
</project>

<project>
  <title>C99 &amp; POSIX Conformance Project</title>

  <contact>
    <person>
      <name>
        <given>Mike</given>
        <common>Barcroft</common>
      </name>
      <email>mike@FreeBSD.org</email>
    </person>
    <person>
      <name>
        <common>FreeBSD-Standards Mailing List</common>
      </name>
      <email>standards@FreeBSD.org</email>
    </person>
  </contact>

  <links><url href="http://www.FreeBSD.org/projects/c99/" /></links>

  <body>
    <p>October 10, 2002 marked the one year anniversary of our project.
    During that time we have made significant advances in FreeBSD's
    standards conformance.  FreeBSD 5.0-RELEASE will be the showcase
    for most of our hard work.  We hope that our tireless effort has
    had a positive effect on FreeBSD and software vendors that
    maintain or are considering porting their software to FreeBSD.</p>

    <p>On the API front, _Exit(3) (an alias for _exit(2)) was added,
    sysconf(3) was update for POSIX.1-2001, and some of the glob(3)
    additions were MFC'd.  The insque(), lsearch(), and remque()
    family of functions were reimplemented and moved to libc from
    libcompat.  Several wide character functions were implemented,
    including all printf() and scanf() variants.  Finally, support
    for wide character format types (%C, %S, %lc, %ls) were added to
    printf(3).</p>

    <p>Work on utility conformance continued as getconf(1)'s compliance
    was updated, c99(1) (a new version of c89(1)) was implemented,
    and cd(1) and command(1) changes were MFC'd.</p>

    <p>Almost 20 headers were brought up to conformance with applicable
    standards.  Not much work remains to fix conformance issues in
    the remaining standard headers.  Work in this area, as well as
    others, has slowed down in preparation for 5.0-RELEASE.</p>
  </body>
</project>

<project>
  <title>DEVD Status Report</title>

  <contact>
    <person>
      <name>
        <given>Warner</given>
        <common>Losh</common>
      </name>
      <email>imp@FreeBSD.org</email>
    </person>
  </contact>

  <body>
    <p>DEVD has been integrated into FreeBSD current.  It was
    integrated in an incomplete state.  However, it is useful in the
    state that it is in for doing simple things like running
    camcontrol rescan when a SCSI pcmcia card is inserted, or running
    /etc/pccard_ether with an ethernet card is inserted.  The more
    sophisticated regular expression matching is not yet complete.
    Devd only does actions on device arrival and departure, but does
    not yet do anything with unknown devices.  In addition to
    listening for device events, there is some desire to have
    /dev/devctl also allow for some direct control of the device
    tree.</p>
  </body>
</project>

<project>
  <title>Fast IPsec Status</title>

  <contact>
    <person>
      <name>
        <given>Sam</given>
        <common>Leffler</common>
      </name>
      <email>sam@FreeBSD.org</email>
    </person>
  </contact>

  <body>
  <p>The main goal of this project is to modify the IPsec protocols to use
  the kernel-level crypto subsystem imported from OpenBSD (see elsewhere). A
  secondary goal is to do general performance tuning of the IPsec
  protocols.</p>

  <p>This work was committed to -current.  To configure it for use specify
  options FAST_IPSEC in your system configuration file.  At present support is
  limited to IPv4.</p>
  </body>
</project>

<project>
  <title>GBDE - Geom Based Disk Encryption</title>

  <contact>
    <person>
      <name>
        <given>Poul-Henning</given>
        <common>Kamp</common>
      </name>
      <email>phk@FreeBSD.org</email>
    </person>
  </contact>

  <body>
    <p>GBDE has been committed to -current.</p>

    <p>The "Geom Based Disk Encryption" module provides a mechanism for
    very strong encryption of a GEOM "disk".  The algorithm has passed
    informal review by a couple of seasoned crypto heavy-weights.
    Any GEOM device can be protected with GBDE, entire physical disks,
    MBR slices, BSD partitions etc etc.  Booting from an encrypted
    partition is not possible, however.</p>

    <p>The focus of GBDE is to protect a "cold" disk media.  (FreeBSD is
    not equipped well for protecting key material on a running system
    from being compromised.)
    For a cold media, the only feasible attack on a GBDE protected
    media is guessing the pass-phrase.</p>

    <p>Summary of the GBDE multilevel protection scheme:  Up to four
    separate pass-phrases can unlock their own separate copies of
    the 2048 bit masterkey.  The master-keys are protected using
    AES/256/CBC keyed with a SHA-2 hash derived from the pass-phrase.
    A salted MD5 hash over the sectoroffset "cherry-picks" which masterkey
    bytes participate in the MD5 hash which generates the "kkey"
    for each particular sector.  The kkey AES/128/CBC encrypts the PRNG
    produced single-use key which AES/128/CBC encrypts the actual
    sector data.</p>

    <p>GBDE has features for master-key destruction and pass-phrase
    invalidation.</p>

    <p>See gbde(4) and gbde(8) for more details.</p>

    <p>This software was developed for the FreeBSD Project by
    Poul-Henning Kamp and NAI Labs, the Security Research
    Division of Network Associates, Inc.  under DARPA/SPAWAR
    contract N66001-01-C-8035 ("CBOSS"), as part of the DARPA
    CHATS research program.</p>
  </body>
</project>

<project>
  <title>GEOM - generalized block storage manipulation</title>

  <contact>
    <person>
      <name>
        <given>Poul-Henning</given>
        <common>Kamp</common>
      </name>
      <email>phk@FreeBSD.org</email>
    </person>
  </contact>

  <links>
    <url href="http://www.FreeBSD.org/~phk/Geom/">Old concept paper here.</url>
  </links>

  <body>
    <p>The GEOM code is now the default on most (if not all ?) architectures
    and the few remaining issues in libdisk/sysinstall is being hashed
    out.</p>

    <p>Although we are far from finished developing GEOM, its current feature
    set is a significant step forward for FreeBSD, providing not only
    immediate relief for new architectures (sparc64, ia64 etc) but also
    because it is designed as SMPng code from the start.</p>

    <p>This software was developed for the FreeBSD Project by
    Poul-Henning Kamp and NAI Labs, the Security Research
    Division of Network Associates, Inc.  under DARPA/SPAWAR
    contract N66001-01-C-8035 ("CBOSS"), as part of the DARPA
    CHATS research program.</p>
  </body>
</project>

<project>
  <title>FreeBSD GNOME Project</title>

  <contact>
    <person>
      <name>
        <given>Joe</given>
        <common>Marcus</common>
      </name>
      <email>marcus@FreeBSD.org</email>
    </person>
    <person>
      <name>
        <given>Maxim</given>
        <common>Sobolev</common>
      </name>
      <email>sobomax@FreeBSD.org</email>
    </person>
    <person>
      <name>
        <given>Adam</given>
        <common>Weinberger</common>
      </name>
      <email>adamw@FreeBSD.org</email>
    </person>
  </contact>

  <links>
    <url href="http://www.FreeBSD.org/gnome/">FreeBSD GNOME Project Homepage.</url>
  </links>

  <body>
    <p>These last two months have seen quite a lot of GNOME activity.
    GNOME has started releasing development snapshots of the upcoming
    GNOME 2.2 desktop.  FreeBSD porting has begun outside of the
    main ports tree in the 
    <a href="http://www.marcuscom.com:8080/cgi-bin/cvsweb.cgi">MarcusCom
    CVS repository</a>.  If you are interested in testing the new
    desktop, follow the instructions on the aforementioned cvsweb
    URL, and checkout the "ports" module.</p>

    <p>Evolution 1.2 is also close at hand.  Ximian has posted its
    first release candidate, 1.1.90, which has been ported to FreeBSD,
    and is available from the MarcusCom CVS repo listed above.  As
    soon as Ximian officially releases Evolution 1.2, it will be placed in
    the FreeBSD ports tree.</p>

    <p>The Mozilla ports have received numerous updates.  We are now
    tracking all three released Mozilla versions.  The mozilla-vendor
    port is tracking the 1.0.x branch, mozilla is tracking 1.1.x, and
    mozilla-devel is tracking 1.2.x.  The mozilla-devel port now
    has support for anti-aliased fonts as well as a GTK+-2 interface</p>

    <p>Finally, the GNOME team would like to welcome its newest
    team member, Adam Weinberger.  Adam has been submitting patches for
    both GNOME ports as well as documentation.  Currently, he has been
    active in the GNOME 2.2 porting effort.  We are happy to have him.</p>
  </body>
</project>

<project>
  <title>Hardware Crypto Support Status</title>

  <contact>
    <person>
      <name>
        <given>Sam</given>
        <common>Leffler</common>
      </name>
      <email>sam@FreeBSD.org</email>
    </person>
  </contact>

  <body>
    <p>The goal of this project is to import the OpenBSD kernel-level crypto
    subsystem. This facility provides kernel- and user-level access to hardware
    crypto devices for the calculation of cryptographic hashes, ciphers, and
    public key operations. The main clients of this facility are the kernel RNG
    (/dev/random), network protocols (e.g. IPsec), and OpenSSL (through the
    /dev/crypto device).</p>

    <p>This work was committed to the -current tree.  To configure it for use
    specify device crypto in your system configuration file or you can load the
    crypto module.  The /dev/crypto device support is brought in with device
    cryptodev or by loading the cryptodev module. Two crypto device drivers
    exist: ubsec for Broadcom-based PCI hardware and hifn for Hifn-based PCI
    hardware.</p>

    <p>Integration of this work into the -stable source tree should be
    completed by the time this report is published.</p>
  </body>
</project>

<project>
  <title>FreeBSD Java Project</title>

  <contact>
    <person>
      <name>
        <given>Greg</given>
        <common>Lewis</common>
      </name>
      <email>glewis@FreeBSD.org</email>
    </person>
  </contact>

  <links>
    <url href="http://www.FreeBSD.org/java/">FreeBSD Java Project</url>
  </links>

  <body>
    <p>Since the last status report the BSD Java Porting Team has continued
    to make steady progress.  The most exciting news we have is courtesy
    of our newest team member, Alexey Zelkin of FreeBSD committer fame.

    <ul>
      <li>Thanks to a lot of hard work, primarily by Alexey, the project
      is very close to being able to release our first patch set for
      the 1.4 JDK.  Things are reportedly working quite well under
      -CURRENT, with -STABLE support being only marginally behind (thanks
      in part to the libc_r MFC by Max Khon).</li>
      <li>The project has released another patchset for the 1.2.2 JDK, mainly
      to add support for OpenBSD and for JPDA.  Most of the projects
      energy at the moment is focused on 1.3 and 1.4, however we still
      hope to back port relevant fixes if appropriate to 1.2.2.</li>
      <li>Nate Williams has been hard at work behind the scenes migrating
      us to a new CVS server which has kindly been donated by the
      FreeBSD Foundation.  The Project appreciates the continued
      support of the Foundation.  Please support them so they can
      continue to support us and other important FreeBSD efforts!</li>
    </ul>
    </p>
  </body>
</project>

<project>
  <title>jpman project</title>

  <contact>
    <person>
      <name>
        <given>Kazuo</given>
        <common>Horikawa</common>
      </name>
      <email>horikawa@FreeBSD.org</email>
    </person>
  </contact>

  <links>
    <url href="http://www.jp.FreeBSD.org/man-jp/">jpman project</url>
    <url href="ftp://daemon.jp.FreeBSD.org/pub/FreeBSD-jp/man-jp/packages-4.7.0/ja-man-doc-4.7.tgz">package ja-man-doc-4.7.tgz</url>
  </links>

  <body>
    <p>For 4.7-RELEASE, we privately published package ja-man-doc-4.7.tgz
    which consists of man[1256789] entries 10 days after the 4.7-RELEASE
    release date.  Man3 update god no progress, as updating other sections
    busied us.  We decided to suspend man3 update officially, as we need to
    spend most of our time to catch up with the forthcoming 5.0-RELEASE.</p>
  </body>
</project>

<project>
  <title>KDE FreeBSD Project</title>

  <contact>
    <person>
      <name>
        <given>Will</given>
        <common>Andrews</common>
      </name>
      <email>will@FreeBSD.org</email>
    </person>

    <person>
      <name>
        <given>KDE-FreeBSD</given>
        <common>Mailinglist</common>
      </name>
      <email>kde@FreeBSD.org</email>
    </person>
  </contact>

  <links>
    <url href="http://freebsd.kde.org">KDE/FreeBSD Website</url>
    <url href="http://rabarber.fruitsalad.org/">KDE/FreeBSD Build Server</url>
  </links>

  <body>
    <p>The KDE/FreeBSD team has been working on two major goals during the last
    two months, Maintenance of the KDE 3.0.x ports and Preparing the
    upcoming KDE 3.1 Release.</p>

    <p>Maintenance KDE 3.0 conducted by Alan Eldrige: September started with
    the Removal of the KDE 2.x Ports from the FreeBSD-Repository. Later
    Packages of KDE 3.0.4 were released and the FreeBSD Ports were updated.</p>

    <p>Preparing for KDE 3.1 conducted by Will Andrews: A lot of effort was
    spent on Improving the Fruitsalad-Build-System. We are now able to
    create packages directly from the KDE CVS.</p>
  </body>
</project>

<project>
  <title>KSE Project Status</title>

  <contact>
    <person>
      <name>
        <given>Julian</given>
        <common>Elischer</common>
      </name>
      <email>julian@FreeBSD.org</email>
    </person>
    <person>
      <name>
        <given>David</given>
        <common>Xu</common>
      </name>
      <email>davidxu@FreeBSD.org</email>
    </person>
    <person>
      <name>
        <given>Jonathon</given>
        <common>Mini</common>
      </name>
      <email>mini@FreeBSD.org</email>
    </person>
    <person>
      <name>
        <given>Daniel</given>
        <common>Eischen</common>
      </name>
      <email>deischen@FreeBSD.org</email>
    </person>
  </contact>

  <links>
    <url href="http://www.FreeBSD.org/kse/">KSE Project web page</url>
    <url href="http://www.FreeBSD.org/~julian">some links</url>
  </links>

  <body>
    <p>The KSE code has now all the basic kernel functionality
    to start being used by the userland. There are still things
    to be done for testing and familiarization.</p>

    <p>General system utilities have not yet been changed.
    e.g. ps and top etc. need to know about threads.</p>

    <p>There is quite a lot of code in the kernel that still
    assumes that there is one thread in a process. Signals are
    not yet handled in the final manner (though they are
    delivered to a random thread in the process :-/ ).</p>

    <p>The system calls and datastructures are now however in
    place. The test program successfully starts several threads
    that can be scheduled on different processors, and closes
    them down again. The userland is probably going to be able
    to do simple scheduling of pthread threads using KSE by the
    time that this report is published.</p>

    <p>I still need someone to take over the "official" web page
    since jason left. LaTeX sure isn't my thing. </p>
    </body>
</project>

<project>
  <title>LibH</title>

  <contact>
    <person>
      <name>
        <given>Antoine</given>
        <common>Beaupr&#233;</common>
      </name>
      <email>anarcat@anarcat.ath.cx</email>
    </person>

    <person>
      <name>
        <given>Alexander</given>
        <common>Langer</common>
      </name>
      <email>alex@FreeBSD.org</email>
    </person>
  </contact>

  <links>
    <url href="http://www.FreeBSD.org/projects/libh.html" />
    <url href="http://rtp1.slowblink.com/~libh/">LibH development page</url>
  </links>

  <body>
    <p>Not much since the last status report, except that we now have
    the repo and development web page back online, thanks to the
    services of John De Boskey who freely provided the necessary
    hardware and bandwidth to host the project. We have also ported
    LibH to GCC 3.x, so that it can compile on -CURRENT
    correctly. This, however, broke tvision, which doesn't compile
    under GCC 3.x, so we moved to rhtvision but this caused linking
    problems so we're stuck with no console front end, for now.</p>

    <p>Work on a Hui rewrite and SWIG bindings stalled. Alex was able
    to come up with a simple patch to make the ports system use
    LibH's pkg_create script to build libh packages, so we're
    getting closer to a real pkg_create(1) drop-in replacement. I
    rewrote the milestone list to show a bit more relevant and
    encouraging tasks that will be dealt with in order to really
    push LibH forward.</p>
  </body>
</project>

<project>
  <title>FreeBSD/MIPS</title>

  <contact>
    <person>
      <name>
        <given>Juli</given>
        <common>Mallett</common>
      </name>
      <email>jmallett@FreeBSD.org</email>
    </person>
  </contact>

  <body>
    <p>A mailing list was created, freebsd-mips, and a Perforce branch
    was created in //depot/projects/mips.  Changes which will be
    necessary to allow multiple MIPS (and PowerPC) metaports to exist
    under one architecture port were made, and are being pushed back
    into the main FreeBSD tree.  Some preliminary header work has been
    done, and porting the ARCBIOS interfaces to the kernel has begun.
    The toolchain in tree was updated and modified in places to support
    a FreeBSD/MIPS (Big Endian) target, in the Perforce branch.  Some
    early boot code has proven the GDB MIPS simulator to work, for at
    least R3000 code, though whether R3000 will be supported has been
    under discussion.  Some initial architectural decisions were also
    made, to steer current work.</p>
  </body>
</project>

<project>
  <title>NEWCARD Status Report</title>

  <contact>
    <person>
      <name>
        <given>Warner</given>
        <common>Losh</common>
      </name>
      <email>imp@FreeBSD.org</email>
    </person>
  </contact>

  <body>
    <p>Work on newcard continues.  A number of bugs have been fixed in
    the last few months.  You are now able to load and unload drivers
    (including the bridge) to test changes to pccard and/or cardbus
    bus code.  It is now possible to load a driver that has a pccard
    attachment and have a previously inserted card probe and attach.
    This is also true for CardBus.  A number of issues remain to be
    solved before 5.0.  However, with the integration of devd into the
    tree nearly all of old functionality of OLDCARD is now present in
    NEWCARD (the biggest remaining parts are power control for the
    sockets, as well as pccardc dumpcis).</p>
  </body>
</project>

<project>
  <title>PowerPC Port</title>

  <contact>
    <person>
      <name>
        <given>Peter</given>
        <common>Grehan</common>
      </name>
      <email>grehan@FreeBSD.org</email>
    </person>
  </contact>

  <body>
    <p>The PowerPC port has been running diskless on NewWorld G3/G4 
    machines for a while now. A GEOM module to support Apple Partition 
    Maps is being written. There should be an installable ISO image 
    available in the near future.</p>
  </body>
</project>

<project>
  <title>RAIDFrame for FreeBSD</title>

  <contact>
    <person>
      <name>
        <given>Scott</given>
        <common>Long</common>
      </name>
      <email>scottl@FreeBSD.org</email>
    </person>
  </contact>

  <links>
    <url href="http://people.FreeBSD.org/~scottl/rf">Project homepage</url>
  </links>

  <body>
    <p>RAIDFrame was imported into FreeBSD-current in late October, a
    major milestone after 18 months.  It is still very experimental and
    not suitable for production environments.  The website contains a
    lengthy TODO list which I hope to start attending to soon.  Still,
    I encourage everyone to try it out and report bugs back to me.</p>
  </body>
</project>

<project>
  <title>Release Engineering</title>

  <contact>
    <person>
      <email>re@FreeBSD.org</email>
    </person>
  </contact>

  <links>
    <url href="http://www.FreeBSD.org/releng/" />
    <url href="http://www.FreeBSD.org/relnotes.html" />
  </links>

  <body>
    <p>The Release Engineering (RE) team completed and released
    FreeBSD 4.7 on 10 October 2002.  This release features updates
    for a number of contributed software programs in the base
    system, as well as all of the security and bug fixes from
    FreeBSD 4.6.2.  The next release in the 4.X series will be
    FreeBSD 4.8, which has a scheduled release date of 1 February
    2003.</p>

    <p>Before that time, however, will be the release of FreeBSD 5.0.
    Thus far, we have not been able to release the 5.0-DP2 developer
    snapshot due to various stability issues.  Thanks to much effort
    from many of our fellow developers, we believe that most of
    these have been resolved.  The RE team wishes to emphasize that
    FreeBSD 5.0 will involve new code and features that have not
    seen widespread testing, and that more conservative users may
    wish to continue to track the 4.X series for the near-term
    future.  To provide more information on these issues, we have
    added an Early Adopter's Guide to the release documentation for
    5.0.</p>

    <p>Brian Somers has resigned from the RE team due to increased
    time pressures.  We thank him for all of his help with FreeBSD
    4.5, 4.6, 4.6.2, and 4.7, and we hope to continue working with
    him as a fellow developer.</p>

    <p>Scott Long has graciously offered to help improve the
    communication between the RE team and the rest of the developer
    community.  We greatly appreciate his assistance.</p>
  </body>
</project>

<project>
  <title>jp.FreeBSD.org daily SNAPSHOTs project</title>

  <contact>
    <person>
      <name>
        <given>Makoto</given>
        <common>Matsushita</common>
      </name>
      <email>matusita@jp.FreeBSD.org</email>
    </person>
  </contact>

  <links>
    <url href="http://snapshots.jp.FreeBSD.org/">Project Webpage</url>
    <url href="http://www.jp.FreeBSD.org/snapshots/">Project Webpage (in Japanese)</url>
  </links>

  <body>
    <p>Recent 5-current release procedure troubles prevent the
    project from releasing a new snapshots.  But 5-current FreeBSD/i386
    release is back again in late Oct/2002!  I have a plan to build
    daily FreeBSD/sparc64 snapshots for 5-current.  Stay tuned...</p>
 </body>
</project>

<project>
  <title>FreeBSD/sparc64 Status Report</title>

  <contact>
    <person>
      <name>
        <given>Jake</given>
        <common>Burkholder</common>
      </name>
      <email>jake@FreeBSD.org</email>
    </person>

    <person>
      <name>
        <given>Thomas</given>
        <common>Moestl</common>
      </name>
      <email>tmm@FreeBSD.org</email>
    </person>
  </contact>

  <body>
    <p>A lot has happened recently for the sparc64 port.  Sysinstall and
    make release work and can be used to build installable snapshots.
    The gdb5.3 port now works, and, thanks to Thomas Moestl, kernel crash
    dumps are supported which can be analyzed by gdb.  These 2 items are
    the last things considered necessary by the Core team for FreeBSD/sparc64
    to be a Tier 1 architecture, which means that 5.0-RELEASE for sparc64
    will be officially supported by the release engineering team and by the
    security officer team.</p>

    <p>Recently Jake Burkholder has been working on alternate installation
    methods other than bootable iso, including a mini-root filesystem which
    can be written to the swap partition of an existing machine.  Thomas
    Moestl has been putting some finishing touches on the release process,
    ensuring that the release documentation can be built properly, and that
    the port readme files can be generated by the release process.</p>

    <p>An experimental iso built with make release is now available on the
    freebsd ftp site and mirrors in
    /pub/FreeBSD/development/sparc64/5.0-20021031-SNAP.  It is expected that
    by the middle of November new 5.0-SNAP releases will be available every
    few days for download and for ftp install, cpu power and bandwidth
    permitting.</p>
  </body>
</project>

<project>
  <title>TrustedBSD Project</title>

  <contact>
    <person>
      <name>
        <given>Robert</given>
        <common>Watson</common>
      </name>
      <email>rwatson@FreeBSD.org</email>
    </person>
    <person>
      <name>
        <common>TrustedBSD Discussion Mailing List</common>
      </name>
      <email>trustedbsd-discuss@FreeBSD.org</email>
    </person>
  </contact>

  <links>
    <url href="http://www.TrustedBSD.org/">TrustedBSD web site</url>
  </links>

  <body>
    <p>Most progress on TrustedBSD over the last two months related
    to improving the maturity of the ACL and MAC implementations,
    and merging new aspects of those features into the primary
    FreeBSD CVS Repository for inclusion in FreeBSD 5.0.  This
    included fixes to run better on sparc64, improved tuning
    of what system objects are mediated, locking fixes and
    optimizations especially relating to the vnode and pipe
    implementations, improved support for MAC labeling on symlinks,
    support for asynchronous process label changes as required
    in some locking situations, remove use of "temporary labels"
    and prefer use of object type specific labels reducing
    redundant and/or confusing label management code in policies,
    improve avoidance of memory allocation in M_NOWAIT scenarios
    for socket allocation in the syncache, mediation of link
    operations, race condition fixes for devfs involving label
    creation, improve handling of VM events such as mmaping,
    improve mediation of socket send/receive events (as
    distinguished from socket transmit/deliver events), support
    for manipulating EAs on symlinks using new system calls,
    support for MNT_ACLS and MNT_MULTILABEL flags at mount time,
    as well as FS_ACLS and FS_MULTILABEL superblock flags to
    key useful defaults using tunefs, correction of a memory leak
    in the UFS ACL code, enable UFS ACL support by default in
    GENERIC, mediation points for file creation, deletion, and
    rename, support for a mac_execve() execution interface in
    the style of SELinux's execve_secure() permitting a label
    transition request as part of the exec operation for policies
    that support it, more consistent handling of NFS lookups,
    support for labeling of multicast encapsulated packets, ATM
    packet labeling, FDDI packet labeling, STF packet labeling,
    revised label interface that avoids userland parsing of
    per-policy elements, reducing us to a single instance of
    parsing and printing for each policy (and further abstracting
    policy implementation details from the library code).</p>

    <p>Also, change to single-level sockets for Biba and MLS
    policies, support for partial label updates for Biba and MLS,
    addition of mac.9 man page, revised user API system calls,
    implementation of mac_get_pid(), and various other related
    bits, creation of mac.conf(5) to specify label defaults,
    checks for various system operations including swapon(),
    settime(), and sysctl(), reboot(), acct(), introduction of
    command line utilities for maintaining file and process labels,
    support for user labels tied to login class, su support for
    label changes, ifconfig support for interface labels, ps
    support for process labels, ls support for file labels, ftpd
    support for login labels, development of the Biba and MLS
    notions of privilege, and a move to C99 sparse structure
    initialization, restoring full type checking for policy entry
    points.</p>
  </body>
</project>

<project>
  <title>OSF DCE 1.1 RPC UUIDs</title>

  <contact>
    <person>
      <name>
        <given>Marcel</given>
        <common>Moolenaar</common>
      </name>
      <email>marcel@FreeBSD.org</email>
    <person>
      <name>
        <given>Hiten</given>
        <common>Pandya</common>
      </name>
      <email>hiten@uk.FreeBSD.org</email>
    </person>
    </person>
  </contact>

  <links>
    <url href="http://www.FreeBSD.org/cgi/cvsweb.cgi/src/lib/libc/uuid" />
  </links>

  <body>
    <p>Universally Unique Identifiers (UUIDs) are 128 bit values that may
    be generated independently on separate nodes (hosts), which result in
    globally unique strings.  UUIDs are also known as Globally Unique
    Identifiers (GUIDs).  The UUID support for FreeBSD (libc) conforms to the
    DCE 1.1 RPC specification.</p>

    <p>UUID support has been added to FreeBSD -CURRENT, and will be available
    in version 5.0.  It is being extensively used in GPT partition handling
    for IA-64 platform.  For now, a simple manual page has been provided,
    which outlines information about the provided uuid routines.  Many
    documentation additions and enhancements to uuidgen(1) are in the
    pipeline.</p>
  </body>
</project>

<project>
  <title>Wireless Networking Status</title>

  <contact>
    <person>
      <name>
        <given>Sam</given>
        <common>Leffler</common>
      </name>
      <email>sam@FreeBSD.org</email>
    </person>
  </contact>

  <body>
    <p>The goal of this project is to improve the wireless networking support
    in the system.  The initial work will incorporate the 802.11 link layer
    done by Atsushi Onoe for NetBSD.  This core support code implements the
    basic 802.11 protocols required for Station and AP operation in BSS, IBSS,
    and Ad Hoc modes of operation. Wireless device drivers will then be revised
    to use this common code instead of their private implementations.</p>

    <p>Following this initial stage the wireless networking support will be
    extended to support functionality needed for workgroup, enterprise, and
    metropolitan (e.g. mesh) networking environments.  This will include full
    power management support, the 802.1D spanning tree protocol for running
    multiple AP's in a bridged configuration, QoS support, and enhanced
    security protocols (LEAP, AES, EAP). Support for new hardware devices is
    also planned.</p>
  </body>
</project>
</report>
