OpenBSD Journal

syspatch(8) Binary Updates Now for the Latest Release Only

Contributed by rueda on from the shorter but wider dept.

In a message to tech@, Theo de Raadt (deraadt@) wrote:

We intend to only build syspatches for one release in the future.
Errata patches will continue to be generated for 2 releases.

The reasoning is syspatch on 2 architectures for 2 releases requires 4
machines, and therefore twice the handholding.  It seems better to keep
the time available to start doing syspatches for more architectures.

This can be seen with the latest TCB errata, for which there are patches for versions 6.1 and 6.2, but a binary update only for 6.2.

(Comments are closed)


Comments
  1. By Anonymous Coward (94.25.228.107) on

    Please, someone, tell Theo about virtual machines.

    Comments
    1. By Anonymous Cowboy (94.23.239.44) on

      I will be interested in Theo's response, given that the OpenBSD project once had a huge power bill and the question was posed as to why OpenBSD needs to support a whole bunch of exotic museum architectures nobody uses.

      I think, knowing Theo, the VM option isn't available yet. Perhaps there are some issues with vmm/vmd that need to be ironed out first.

      Comments
      1. By AussieFrog (114.75.78.78) on

        Probably because people still care enough to use and maintain those architectures. They also help keep the system portable and identify certain bugs.

        Comments
        1. By AussieFrog (114.75.78.78) on

          Plus, some of those are hardly museum technology. Maybe we'll live to see a MIPS or SPARC (64) revival ;)

          Comments
          1. By Anonymous Coward (199.68.207.3) on

            OpenBSD supports some current MIPS64 architectures like Cavium Octeon. In fact it supports some of Ubiquiti's newest routers on that architecture like the Edgerouter 4, Edgerouter 6 and Edgerouter Infinity (minus XGbE ports at the moment.)

            Comments
            1. By Anonymous Coward (114.75.78.78) on

              Thanks! I have been out of the loop for a while, and I have not followed those developments.

              I found a company selling those routers at at decent price (by Australian standards), so I might get one and build a home router/firewall with it.

              I don't like all those "smart" devices (TVs, etc.) talking directly to the network through my ISP router...

    2. By Anonymous Coward (84.112.126.72) on

      VMs require just as much time to manage and operate as real hardware. VMs won't allow Theo to create high-quality binary patches any faster.

      Comments
      1. By Anonymous Coward (5.8.17.170) on

        > VMs require just as much time to manage and operate as real hardware.

        How so? It's like, I dunno, 300-400 LOC in ansible to get the thing up and running.

        > VMs won't allow Theo to create high-quality binary patches any faster.

        A shell script that builds a binary, compares it to another binary, generates a diff and launches a test suite against it scales pretty easily.

        Comments
        1. By Anonymous Coward (185.24.203.165) on

          Wow, we have volunteer here. :)

        2. By Anonymous Coward (199.172.169.36) on

          That simple huh?
          Why doesn't anyone do it?

          Maybe you should take a swing at it!

          Comments
          1. By Anonymous Coward (188.162.64.220) on

            > Why doesn't anyone do it?

            What makes you think so? Lots of people (including myself) have this kind of setup at work. Believe me, no rocket science there.

      2. By Anonymous Coward (2607:5300:201:3100::1c62) on

        > VMs require just as much time to manage and operate as real hardware. VMs won't allow Theo to create high-quality binary patches any faster.

        Theo didn't mention had anything about the speed of the build, just that it required two more machines to build it. The VMs eliminate the need to have two more physical machines.

        Comments
        1. By Ross (173.27.232.57) on

          He also didn't mention having to do hardware testing of the patches so the can't do "high quality patches" from the first comment is pretty silly, too. Either OpenBSD can reliably build and host itself or it can't.

          Presumably Theo is just being Theo and refusing to adopt new techniques that the rest of the software development community reasonably considers standard practice these days.

          His rants on virtualization for security purposes are well known. This isn't a question of security. Virtualization on amd64 arch is for consolidating hardware resources to allow more to be done with only modest increases in hardware requirements versus bare metal deployment. If Theo can't build OpenBSD patches in a OpenBSD virtual machine using vmd on an OpenBSD host because he has "security concerns" about using virtual machines for anything at all, speaks more for Theo's state of mind and stubbornness than any reasonable security issues that might arise from such a narrow limited use case. Use the right tool for the job. vmd is the tool designed for this job.

          Comments
          1. By AussieFrog (114.75.78.78) on

            How would he test a hypothetical fix to the virtualisation code, or in fact any code that is somehow hardware-dependent (pretty common for an OS), if not by testing on bare metal?

          2. By Paymon Yamini Sharif (75.171.53.170) on

            The above comment is what happens when, metaphorically speaking, an intelligent person gets brain cancer. Some people should be more paranoid about their self centered confidence and what it can do to their image when they share such ideas with such a strong and insulting levels of confidence. Other people should post using their real full name just to be associated with the cure for such cancer. Thanks buddy, you're making us look good.

    3. By Edward Ahlsen-Girard (Ed) eagirard@cox.net on

      I've used VMs for a wide variety of purposes for over ten years, including answering the question, "how can I possibly run NextStep on Intel in an environment that requires auditing that NextStep doesn't do?" (it was not a perfect answer).

      There are things to use VMs for. Building a production O/S targeted to the physical architecture that the VM emulates is not one.

      Comments
      1. By Anonymous Coward (2001:67c:2608::1) on

        Care to elaborate? We are talking about building patches here, not a complete OS. Besides, the fact that OpenBSD errata is made for the last 2 releases demonstrates that either they already have the testing infrastructure, or they just release the patches to the previous release blindly without testing.

    4. By Marc Espie (espie) espie@nerim.net on

      This has nothing to do with virtualization, and everything to do with actual testing.

      Setting up the machines is relatively simple even with virtualization.
      Not fucking up the patches is somewhat more fun.

      What then ? testing should also occur, which means actually running the darn thing. Then virtualization won't really cut it. Testing it usually means running a full system, including graphics, to make sure things work.

      Comments
      1. By Anonymous Cowboy (93.115.95.206) on

        So for all these years source code errata have been pushed out, how are the ordinary source code patches tested? Surely this situation can't be very different, since you still have to compile the patches to test them, just as you do with source code patches.

        Comments
        1. By Marc Espie (espie) espie@nerim.net on

          well, for all these years, there wasn't syspatch, so the testing was not optimal, to say the least.

          exactly like for every other piece of OpenBSD. Each time we add a new tool that checks more things, we find more crap and try to fix it.

    5. By Anonymous Coward (73.225.215.145) on

      Theo has already addressed why he doesn't use virtual machines for platform testing. In short, you catch more bugs on real hardware.

Credits

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 deadly.org 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.]