OpenBSD Journal

OpenBSD 3.1 Released

Contributed by Dengue on from the early dept.

Ladies and Gentlemen, OpenBSD 3.1 has been officially released. While it may take some time for mirrors to catch up, please be a good netizen and use a mirror .

Read more for the release announcement.

     Subject: OpenBSD 3.1 Released!
        Date: 19 May 2002 15:02:49 -0600
Organization: OpenBSD Project
  Newsgroups: comp.unix.bsd.openbsd.announce
 Followup-To: comp.unix.bsd.openbsd.misc

- OpenBSD 3.1 RELEASED -------------------------------------------------

May 19, 2002.

It is our pleasure to officially announce the release of OpenBSD
3.1.  This year OpenBSD turns 7 years old.  In celebration of this
milestone, we invite you to enjoy our 11th release on CD-ROM (and
12th via FTP).  We continue to celebrate OpenBSD's record of four
years without a remote hole in the default install.  Just like all
of our previous releases, 3.1 provides significant improvements,
including new features, in nearly all areas of the system:

- Improved hardware support             (

  o Much improved support for UltraSPARC hardware.  More models are 
    supported and X11 works on all supported models.

  o Improved 802.11b support, including a host-based access point
    mode for Prism chipsets (i.e. wireless bridging).  It is now
    possible to completely configure a wireless interface using ifconfig.

  o The hardware crypto drivers now work on all PCI platforms.

  o Major macppc improvements including a brand new pmap module
    that cut 'make build' time by over an hour.

  o Tekram TRM-S1040 based PCI SCSI controllers are now supported.

  o Creative SB Live! cards are now supported.

  o HiFn 7811 is now supported by the hifn driver.  A long-standing
    bug causing PCI aborts has also been fixed in the hifn driver.

  o Kernel support for Altivec on the macppc platform.

- Major improvements in the pf packet filter:

  o Significant performance improvements due to additional optimizations
    based on detailed benchmarks.  Filter rule evaluation cost
    (which occurs for every packet that isn't passed statefully)
    is reduced by about 70%.

  o Stateful filtering (including address translation and redirection)
    for arbitrary IP protocols other than TCP, UDP and ICMP, for
    instance GRE (used for IPsec/PPTP).

  o Configurable memory limits (preventing memory exhaustion).
    'pfctl -m' can set an upper bound on the number of simultaneous
    states or fragments.

  o authpf(8), an authenticating gateway user shell, modifies filter
    rules when a user logs in, controlling network access at the user

  o New 'fastroute', 'route-to' and 'dup-to' options allow pf to
    route packets independently of the system routing table.  This
    can be used to e.g., implement source-based routing or to
    duplicate packets to an IDS or logging host.

  o Parser improvements allow further reduction of rule set complexity  
    ('no nat', rdr port ranges, and more).

  o Rule labels simplify usage of counters for accounting ('pass in
    from any to any port www label http_requests').

  o The 'no-route' keyword in filter rules matches packets with non-
    routable addresses.  E.g., 'block in quick from no-route to any'
    blocks packets from non-routable source addresses.

  o tcpdump(8) expressions can filter pf logs on pf-specific fields.
    E.g. 'tcpdump -i pflog0 action block' prints only blocked packets.

  o Additional ioctls for adding and removing state entries (used by
    proxies, authpf(8) and pfctl(8)).

- Ever-improving security            (

  o More fixes for potential signal handler races.  Work is ongoing in
    this area to fix the signal handlers in all programs, not just
    privileged ones.

  o sshd now supports a privilege separation mode where all incoming
    network traffic takes place in an unprivileged process.

  o A number of memory leaks that could lead to denial of service
    attacks have been plugged.

  o Several other security issues fixed throughout the system, many
    of which were identified by members of the OpenBSD team themselves.
    Please see for more details
    on what was fixed.

- New subsystems included with 3.1

  o A version of the venerable spell program is now included.

  o Generic macros for manipulating splay trees and red-black trees.

  o Support for extended attributes in the filesystem.

- Many other bugs fixed                 (

- The "ports" tree is greatly improved  (

  o The 3.1 CD-ROMs ship with many more pre-built packages for the
    common architectures.  The FTP site contains hundreds more
    packages (for the important architectures) which we could not
    fit onto the CD-ROMs.

- Many subsystems improved and updated since the last release:

  o A long-standing bug in the i386 MBR that caused a hang on boot
    with some machines has been fixed.

  o Better sizing of kernel buffers, based on amount physical memory.

  o Other memory-related limits are tunable without recompiling a
    lernel via config -e.

  o Improved behavior of the virtual memory system in low-memory

  o ALTQ is supported by more ethernet drivers and now works on
    bridged interfaces.

  o Loadable kernel modules are now supported on ELF platforms.

  o The 2 gigabyte file size limit has been removed from mmap(2),
    vnd(4), savecore(8), dump(8), restore(8), and rcp(1).

  o XFree86 updated to 4.2.0.

  o sendmail updated to 8.12.2.

  o Latest KAME IPv6

  o KTH Heimdal-0.4e

  o OpenSSH 3.2

If you'd like to see a list of what has changed between OpenBSD 3.0
and 3.1, look at

Even though the list is a summary of the most important changes
made to OpenBSD, it still is a very very long list.

This is our twelfth OpenBSD release, and the eleventh release which
is available on CD-ROM.  Our releases have been spaced six months
apart, and we plan to continue this timing.

- SECURITY AND ERRATA --------------------------------------------------

We provide patches for known security threats and other important
issues discovered after each CD release.  As usual, between the
creation of the OpenBSD 3.1 FTP/CD-ROM binaries and the actual 3.1
release date, our team found and fixed some new reliability problems
(note: most are minor, and in subsystems that are not enabled by
default).  Our continued research into security means we will find
new security problems -- and we always provide patches as soon as
possible.  Therefore, we advise regular visits to

Security patch announcements are sent to the
mailing list.  For information on OpenBSD mailing lists, please see:

- CD-ROM SALES ----------------------------------------------------------

OpenBSD 3.1 is also available on CD-ROM.  The 3-CD set costs $40USD
(EUR 45) and is available via mail order and from a number of
contacts around the world.  The set includes a colorful booklet
which carefully explains the installation of OpenBSD.  A new set
of cute little stickers are also included (sorry, but our FTP mirror
sites do not support STP, the Sticker Transfer Protocol).  As an
added bonus, the second CD contains an exclusive audio track by Ty

Profits from CD sales are the primary income source for the OpenBSD
project -- in essence selling these CD-ROM units ensures that OpenBSD
will continue to make another release six months from now.

The OpenBSD 3.1 CD-ROMs are bootable on the following six platforms:
  o i386
  o alpha
  o sparc
  o sparc64 (UltraSPARC)
  o macppc
  o hp300*

* The m68k-based platforms, including hp300, are located on a fourth
  CD that is not included in the official CD-ROM package.  You can
  download the ISO image for the fourth CD as described below.

(Other platforms must boot from floppy, network, or other method).

For more information on ordering CD-ROMs, see:

The above web page lists a number of places where OpenBSD CD-ROMs
can be purchased from.  For our default mail order, go directly to:

or, for European orders:

All of our developers strongly urge you to buy a CD-ROM and support
our future efforts.  As well, donations to the project are highly
appreciated, as described in more detail at:

Due to space restrictions and our desire not to raise the cost of
the CD-ROM, the Motorola 68k-based platforms are located on a
fourth CD that is not included in the official CD-ROM package.
An ISO image for this CD may be downloaded from:

This CD contains the amiga, hp300, mac68k and mvme68k install sets
as well as the m68k packages.  The CD is bootable on the hp300.
Note that not all ftp mirrors will carry the CD image.

- T-SHIRT SALES --------------------------------------------------------

The project continues to expand its funding base by selling t-shirts
and polo shirts.  And our users like them too.  We have a variety
of shirts available, with the new and old designs, from our web
ordering system at:

The new 3.1 t-shirt is not available at this time but will be
available shortly.

- FTP INSTALLS ---------------------------------------------------------

If you choose not to buy an OpenBSD CD-ROM, OpenBSD can be easily
installed via FTP.  Typically you need a single small piece of boot
media (e.g., a boot floppy) and then the rest of the files can be
installed from a number of locations, including directly off the
Internet.  Follow this simple set of instructions to ensure that
you find all of the documentation you will need while performing
an install via FTP.  With the CD-ROMs, the necessary documentation
is easier to find.

1) Read either of the following two files for a list of ftp
   mirrors which provide OpenBSD, then choose one near you:

2) Connect to that ftp mirror site and go into the directory
   pub/OpenBSD/3.1/ which contains these files and directories.
   This is a list of what you will see:

        Changelogs/    alpha/         macppc/        sparc64/
        HARDWARE       amiga/         mvme68k/       src.tar.gz 
        PACKAGES       ftplist        packages/      srcsys.tar.gz 
        PORTS          hp300/         ports.tar.gz   tools/
        README         i386/          root.mail      vax/
        XF4.tar.gz     mac68k/        sparc/         

   It is quite likely that you will want at LEAST the following
   files which apply to all the architectures OpenBSD supports.

        README          - generic README
        HARDWARE        - list of hardware we support
        PORTS           - description of our "ports" tree
        PACKAGES        - description of pre-compiled packages
        root.mail       - a copy of root's mail at initial login.
                          (This is really worthwhile reading).

3) Read the README file.  It is short, and a quick read will make
   sure you understand what else you need to fetch.

4) Next, go into the directory that applies to your architecture,
   for example, i386.  This is a list of what you will see:

        CKSUM          INSTALL.os2br  comp31.tgz     man31.tgz 
        INSTALL.ata     etc31.tgz      misc31.tgz 
        INSTALL.chs    MD5            floppy31.fs    xbase31.tgz 
        INSTALL.dbr    base31.tgz     floppyB31.fs   xfont31.tgz 
        INSTALL.i386   bsd            floppyC31.fs   xserv31.tgz 
        INSTALL.linux  bsd.rd         game31.tgz     xshare31.tgz 
        INSTALL.mbr    cdrom31.fs     index.txt      

   If you are new to OpenBSD, fetch _at least_ the file INSTALL.i386
   and the appropriate floppy*.fs file.  Consult the INSTALL.i386
   file if you don't know which of the floppy images you need (or
   simply fetch all of them).

5) If you are an expert, follow the instructions in the file called
   README; otherwise, use the more complete instructions in the
   file called INSTALL.i386.  INSTALL.i386 may tell you that you
   need to fetch other files.

6) Just in case, take a peek at:

   This is the page where we talk about the mistakes we made while
   creating the 3.1 release, or the significant bugs we fixed
   post-release which we think our users should have fixes for.
   Patches and workarounds are clearly described there.

Note: If you end up needing to write a raw floppy using Windows,
      you can use "fdimage.exe" located in the pub/OpenBSD/3.1/tools
      directory to do so.

- XFree86 FOR MOST ARCHITECTURES ---------------------------------------

XFree86 has been integrated more closely into the system.  This
release contains XFree86 4.2.0.  Most of our architectures ship
with XFree86, including sparc, sparc64 and macppc.  During installation,
you can install XFree86 quite easily.  Be sure to try out xdm(1)
and see how we have customized it for OpenBSD.

On the i386 platform a few older X servers are included from XFree86
3.3.6.  These can be used for cards that are not supported by XFree86
4.2.0 or where XFree86 4.2.0 support is buggy.  Please read the
/usr/X11R6/README file for post-installation information.

- PORTS TREE -----------------------------------------------------------

The OpenBSD ports tree contains automated instructions for building
third party software.  The software has been verified to build and
run on the various OpenBSD architectures.  The 3.1 ports collection,
including many of the distribution files, is included on the 3-CD
set.  Please see PORTS file for more information.

Note: some of the most popular ports, e.g., the Apache web server
and several X applications, come standard with OpenBSD.  Also, many
popular ports have been pre-compiled for those who do not desire
to build their own binaries (see PACKAGES, below).

- BINARY PACKAGES WE PROVIDE -------------------------------------------

A large number of binary packages are provided.  Please see PACKAGES
file ( for more details.

- SYSTEM SOURCE CODE ---------------------------------------------------

The CD-ROMs contain source code for all the subsystems explained
above, and the README (
file explains how to deal with these source files.  For those who
are doing an FTP install, the source code for all four subsystems
can be found in the pub/OpenBSD/3.1/ directory:

        XF4.tar.gz     ports.tar.gz   src.tar.gz     srcsys.tar.gz

- THANKS ---------------------------------------------------------------

OpenBSD 3.1 includes artwork and CD artistic layout by Ty Semaka,
who also is featured in an audio track on the OpenBSD 3.1 CD set.
Ports tree and package building by Christian Weisgerber, David Lebel,
Marc Espie, Peter Valchev and Miod Vallat.
System builds by Theo de Raadt, Niklas Hallqvist, Todd Fries and Bob Beck.
ISO-9660 filesystem layout by Theo de Raadt.

We would like to thank all of the people who sent in bug reports, bug
fixes, donation cheques, and hardware that we use.  We would also like
to thank those who pre-ordered the 3.1 CD-ROM or bought our previous
CD-ROMs.  Those who did not support us financially have still helped
us with our goal of improving the quality of the software.

Our developers are:

    Aaron Campbell, Angelos D. Keromytis, Anil Madhavapeddy, Artur Grabowski,
    Ben Lindstrom, Bob Beck, Brad Smith, Brandon Creighton, Brian Caswell,
    Brian Somers, Bruno Rohee, Camiel Dobbelaar, Chris Cappuccio,
    Christian Weisgerber, Constantine Sapuntzakis, Dale Rahn, Damien Miller,
    Dan Harnett, Daniel Hartmeier, David B Terrell, David Lebel,
    David Leonard, Dug Song, Eric Jackson, Federico G. Schwindt,
    Grigoriy Orlov, Hakan Olsson, Hans Insulander, Heikki Korpela,
    Horacio Menezo Ganau, Hugh Graham, Ian Darwin, Jakob Schlyter,
    Jan-Uwe Finck, Jason Ish, Jason Peel, Jason Wright, Jean-Baptiste Marchand,
    Jean-Jacques Bernard-Gundol, Jim Rees, Joshua Stein,
    Jun-ichiro itojun Hagino, Kenjiro Cho, Kenneth R Westerback,
    Kevin Lo, Kevin Steves, Kjell Wooding, Louis Bertrand, Marc Espie,
    Marco S Hyman, Mark Grimes, Markus Friedl, Mats O Jansson, Matt Behrens,
    Matt Smart, Matthew Jacob, Matthieu Herrb, Michael Shalayeff,
    Michael T. Stolarchuk, Mike Frantzen, Mike Pechkin, Miod Vallat
    Nathan Binkert, Nick Holland, Niels Provos, Niklas Hallqvist,
    Oleg Safiullin, Paul Janzen, Peter Galbavy, Peter Stromberg,
    Peter Valchev, Reinhard J. Sammer, Shell Hin-lik Hung, Steve Murphree,
    Thierry Deval, Theo de Raadt, Thorsten Lockert, Tobias Weingartner,
    Todd C. Miller, Todd T. Fries, Wim Vandeputte.

(Comments are closed)

  1. By Warthog () on

    Where is the cdrom.fs?

    I wanted to test out the pre-3.1 snapshots but couldn't. The Ultra 5's won't boot off of floppy so that was out. OpenBSD won't provide ISO images so that was out. Tried making my own ISO from the snapshots, but miniroot.fs (best I could find) is not bootable from CD-R. Arrrgh. A cdrom.fs would be very helpful for those of us who are trying to test out the snapshots.

    1. By Anonymous Coward () on

      How can I upgrade my openbsd 3.0 box intp openbsd 3.1 ?
      Is it simply just install the *.tgz and bsd in .../OpenBSD/3.1/`arch`/ and then diff the /etc to the etc31.tgz ? Then cvs the kernel tree and do make build?

      1. By mra () on

    2. By Vig () on

      Ultra 5's do indeed boot off of the miniroot.fs included in the 3.1 snapshots as well as 3.1-Release.

      For sparc64 you need to create a .slicemap file in the cd root directory with an entry for each architecture (also be sure that you include filenames that being with "." when you create your ISO).

      Some searching of usenet or other resources will turn up the format of the .slicemap file if you are not familiar with it.


    3. By Ben Lindstrom () on

      I tend to just do netinstalls of all my sparcs. Be them 32 or 64. Makes it a lot easier just throwing in a couple entries booting the box and being ready to go.

      - Ben

  2. By RC () on

    Loadable kernel modules are now supported on ELF platforms.

    The idea behind Loadable Kernel Modules (LKM) was always a good one, yet never implimented well.

    One of the best things about OpenBSD is the fact that you can take a hard drive with OpenBSD out of a computer, and stick it in an entirely different machine without needing to load different modules by hand, etc. The only thing you may need to do is rename the /etc/hostname.* with the extension of your new NIC, and perhaps change your XFree86 config.

    What I'd like to see OpenBSD do is, on startup, detect what hardware is installed and automatically load the appropriate modules, without any user interaction.

    One of the best things about this, is that you no longer need to work out conflicts yourself. Every device is a module, and complicting modules will not be loaded. So you could transfer your OpenBSD installation between systems with devices that currently can't both simultaneously exist in a single kernel.

    1. By Eric Jackson () on

      This isn't really a good idea, using modules
      for real run-time systems is a bad idea, security
      wise. Modules can only be loaded if the securelevel is at its lowest.

      Modules are really only included for ease of development.

      Also, all devices should be able to co-exist just fine. If they do not, then that is a bug. If for some reason there is a bug, users can easily disable certain devices by hand at boot time. That is what boot -c is for, and you can then use config(8) to write out the modified kernel, no compilation involved.

      1. By RC () on

        This isn't really a good idea, using modules for real run-time systems is a bad idea, security wise. Modules can only be loaded if the securelevel is at its lowest.

        I never suggested that it be done at run-time... I don't know where you got that idea.

        Also, all devices should be able to co-exist just fine. If they do not, then that is a bug.

        Grep for 'conflict' in the kernel config files and then talk. There are plenty of devices which conflict with others, which have been that way for quite a long time.

        That is what boot -c is for, and you can then use config(8) to write out the modified kernel, no compilation involved.

        No, you can't just use -c. Most devices that might cause a conflict are disabled by default. You need to compile a kernel with those lines uncommented and of course disable the other device with which it conflicts. Secondly, I am not worried about configuring the kernel for one machine... Imagine for a second that you are an Administrator, you have OpenBSD installed on hundreds of hard drives, going in to a few different systems. Obviously if you have hardware that isn't in the kernel because it conflicts with a device in another machine, you'd love to have loadable kernel modules that will automatically take care of the problem (by only loading the drivers needed, eliminating the conflicts).

        Then, we just need to have OpenBSD change the /etc/hostname.XXX to whatever is in the current machine, and reconfigure the driver section in the XFree86 config file and anyone can take an OpenBSD hard drive from one system, and transfer it to any number of other systems, without needing to change a single thing. That would really be impressive, and a lot better than anything in the Microsoft, Linux, or even BSD camps so far.

        1. By David Gerard () on

          "take an OpenBSD hard drive from one system, and transfer it to any number of other systems, without needing to change a single thing. That would really be impressive, and a lot better than anything in the Microsoft, Linux, or even BSD camps so far."

          Actually Windows 95 and 98 do this trick pretty nicely ... if you have all the .CAB files (which have the collection of default drivers that come with Windows) on the hard disk, as well as any needed driver files that aren't. I've done this trick several times.

          1. By Anonymous Coward () on

            w95 or 98 will do this only after rebooting several
            times, especially with network drivers. at the very
            least requiring the admin to push buttons until the
            system stops complaining and at least 2 reboots.

  3. By Anonymous Coward () on

    I still havnt burned that 4th iso from know what it is yet?

    1. By invaderzim () on

      The 4th disc is for platforms that they aren't bundling on the CDs any more. Amiga and the less used/support platforms.

    2. By Marc Espie () on

      With the advent of better supported architectures (you
      have to realize that most packages now build correctly on
      powerpc, and a large subset is available on sparc64), we
      had to make some hard choices.

      In the end, the distribution was switched to 4 CDs. But
      the packaging allows for only three physical CDs (or the
      cost of buying OpenBSD would be much higher), so the forth
      CD is ftp-only... and it holds all m68k-based architectures.

      Additionally, this gave some breathing space for the m68k
      packager, Miod Vallat, since m68k tend to be the slowest boxes on which OpenBSD runs these days: time enough to do
      a decent package build for the CD, since it could miss the
      master CD shipping date without problems.

      1. By Anonymous Coward () on

        None of my client boxen have a cd-rom and so I like to
        set up the official cd on a server and let all the
        clients connect over http to run the install.
        Index.txt is necessary for this kind of install and
        its not on the cd. I just end up making my own custom
        cd with install FAQs,patches, and index.txt .
        Not a big deal but for anyone that is moving up from
        2.9 this is a change in format.
        I LOVE being able to choose the keyboard type during
        the install because I am running a KVM with a
        japanese keyboard.

  4. By Eric Clope () on

    What's up with the cross of jesus on the blowfish?

    1. By niekze () on

      I don't think it has any meaning, in this case, outside of the artwork. The blowfish image is trying to mimic a certain stereotypical image, which they did very well. I wouldn't try to read into it. I don't think there is an official OpenBSD religion. It's just artwork. Perhaps it's there to fight off the daemons ;)

    2. By A believer () on

      Does it bother you?

    3. By Anonymous Coward () on

      Puffy the buffer slayer!!!!
      take a look at the stickers.
      maybe Puffy is the antidaemon??

  5. By Nicolai () on

    > Ladies and Gentlemen, OpenBSD 3.1 has been officially released

    Ha .. He said ladies.

    1. By Anonymous Coward () on

      Of course he said ladies. Chicks dig OpenBSD, you know ;-)

    2. By Marc Espie () on

      Yep, we do know of some chicks who use OpenBSD.

  6. By tim () tim-at-woz-dot-gs on

    Upgraded my 2.9 wireless routers to 3.1. Was scared of the pf transition but all went smooth! As always, the hardest part was making a boot floppy. Also, I was trying for the super elite installation-over-the-airwaves, but for some reason it wouldn't have it. I installed over wires, rebooted, and then Wavelan worked like a charm. Ah well maybe next version. But otherwise this is a world class server OS. Too sweet! Thanks OpenBSD team.

  7. By Anonymous Coward () on
    Five years without a remote hole in the default install!
    This is NOT true!

    1. By Anonymous Coward () on

      Revision / (download) - annotate - [select for diffs] , Thu May 16 21:45:31 2002 UTC (5 days, 17 hours ago) by miod
      Branch: OPENBSD_2_9
      Changes since 1.39: +6 -5 lines
      Diff to previous 1.39 (colored) next main 1.40 (colored)

      MFC, requested by millert, diff by itojun:
      avoid buffer overrun on PASV from malicious server.

    2. By Nils Kassube () pgkwpgkwkg@gwekogkweg.wrg on mailto:pgkwpgkwkg@gwekogkweg.wrg

      Your link points to a bug in a client application.
      "Remote hole in the default install" means
      that someone can break into your server from
      a remote location.

      1. By Anonymous Coward () on

        "Remote hole in the default install" means
        that someone can break into your server from
        a remote location.

        I ftp out to a ftp-server (which is modified, which I don't know).
        Server responds with a long reply in the place of IP and port, pasv buffer will overflow.
        Leading to remote code execution.

        No ftp-server startet, but remote vulnerable just by ftp out. (no changes, still deafult install)

        1. By Anonymous Coward () on

          Is this referring to MATU FTP v.1.74 on WIN32??
          A bug mentioned on bugtraq on april 22, 2002.
          Default install of what? win95

          1. By Anonymous Coward () on

            Revision / (download) - annotate - [select for diffs] , Thu May 16 21:45:31 2002 UTC (5 days, 17 hours ago) by miod
            Branch: OPENBSD_2_9
            Changes since 1.39: +6 -5 lines
            Diff to previous 1.39 (colored) next main 1.40 (colored)

            MFC, requested by millert, diff by itojun:
            avoid buffer overrun on PASV from malicious server.

            So it is in OpenBSD 2.9 and others
            Patched 5 days ago but the errata was not updated.

    3. By Anonymous Coward () on

      Anybody see the notice at packet storm that mentions
      a problem with talkd on KDE. It seems that Theo has
      attracted the attention of quite a few nutcases.
      WHO exactly is in this gobbles security group?
      Pinky and the brain???? :)
      -- Idle accusations are not going to dissuade anyone
      from using OpenBSD. If you have a REMOTE root exploit,
      post it. If you don't have a REMOTE root expoit in
      the DEFAULT install then go play with your /. buddies.

    4. By Anonymous Coward () on

      This is rather interesting, could the ftp install
      be hijacked? :)

      1. By Anonymous Coward () on

        remote code execution is a possiblity

    5. By Not Really Anonymous () on

      You know, the OpenBSD team has worked hard and Im sure went through many pizzas to accomplish what they have to this point.

      Why is it everyone wants to be the one who is "right" and continue to go after this "No remote hole for ($whatever + 1) years"?

      Really, I would like someone to actually use their brain and write articles on how to best use OpenBSD to fit different situations. For example, a small business office solution with 1 - 10 workstations and file server running OpenBSD, with basic office functionality such as file sharing, email, etc.

      So ... lets stop saying the world is flat and get to work :P.


  8. By Anonymous Coward () on

    At this point, OpenBSD is so secure that if an attacker wants the data a box is storing, the only attack left which is likely to be successful is to steal the box. There's only one defense against this: An encrypted FS, plus whatever arrangement is needed to ensure that the box can't leave the building while powered up, or can't be hacked on the console. OpenBSD can't do anything about those hardware problems, but all the hardware in the world can't compensate for not having an encrypted FS. I realized the VND can do it, but isn't it time for real, integrated encryption in the FS driver? OpenBSD talks about "crypto everywhere", except for one glaring exception.

    1. By Sean A. () on

      You might want to take a look at tcfs. it's been a while since i played with it, but it's included with OpenBSD.

      1. By Anonymous Coward () on

        it's marked "experimental", I believe, and hasn't been touched in a couple of years. It would be fantastic if it were stable and ready to use. "Steal the machine" is pretty much the only weakness left when you're dealing with OpenBSD. Fixing that problem does require some hardware help (some form tamper resistance, appropriate to the threat model), and hardware is beyond the scope of software, but that doesn't mean we don't need crypto FS. After our office break-in our company decided that internal file servers need crypto FS, but our options are very severely limited right now. It looks like we need either Linux Mandrake or Windows XP to achieve that. Neither of those are even in the same universe with OpenBSD, but what can we do?


Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]