1. 54
  1.  

  2. 11

    Some personal favorites:

    • Work has started on a ISC-licensed rsync-compatible program called OpenRSYNC. In this release it has basic functionality such as -a, –delete, but lacks –exclude. Work will continue.
    • unveil(2) has been improved to understand and find covering unveil matches above the working directory of the running process for relative path accesses. As a result many programs now can use unveil in broad ways such as unveil(”/”, “r”).
    • Now using unveil(2) in ospfd(8), ospf6d(8), rebound(8), getconf(1), kvm_mkdb(8), bdftopcf(1), Xserver(1), passwd(1), spamlogd(8), spamd(8), sensorsd(8), snmpd(8), htpasswd(1), ifstated(8). Some pledge(2) changes were required to accommodate unveil.
    • RETGUARD replaces the stack protector on amd64 and arm64, since RETGUARD instruments every function that returns and provides better security properties than the traditional stack protector.
    • tcpdump(8) already used privsep, pledge(2) and unveil(2) containment. It now also drops root privileges completely (switching to a reserved uid).
    • malloc(3) now uses sysctl(2) to get its settings, making it respect the system-wide settings in chroots as well.
    • LibreSSL 2.9.1: Added support for XChaCha20 and XChaCha20-Poly1305.
    • Removed some ASN.1 related code from libcrypto that had not been used since around 2000.
    • ssh(1): When prompting whether to record a new host key, accept the key fingerprint as a synonym for “yes”. This allows the user to paste a fingerprint obtained out of band at the prompt and have the client do the comparison for you.
    • Xorg(1), the X window server, is no longer installed setuid. xenodm(1) should be used to start X.
    • Mandoc 1.14.5: Much better HTML output, in particular with respect to paragraphs, line breaks, and vertical spacing in tagged lists. Tooltips are now implemented in pure CSS, the title attribute is no longer abused.

    I guess the new filtering engine of OpenSMTPD isn’t ready yet.

    1. 14

      “O Deep Thought computer,” he said, “the task we have designed you to perform is this. We want you to tell us….” he paused, “The Answer.”
      “The Answer?” said Deep Thought. “The Answer to what?”
      “Life!” urged Fook.
      “The Universe!” said Lunkwill.
      “Everything!” they said in chorus.
      Deep Thought paused for a moment’s reflection.
      “Tricky,” he said finally.
      “But can you do it?”
      Again, a significant pause.
      “Yes,” said Deep Thought, “I can do it.”
      “There is an answer?” said Fook with breathless excitement.
      “Yes,” said Deep Thought. “Life, the Universe, and Everything. There is an answer. But, I’ll have to think about it.”

      Fook glanced impatiently at his watch.
      “How long?” he said.
      “Seven and a half million years,” said Deep Thought.
      Lunkwill and Fook blinked at each other.
      “Seven and a half million years…!” they cried in chorus.
      “Yes,” declaimed Deep Thought, “I said I’d have to think about it, didn’t I?”

      [Seven and a half million years later…. Fook and Lunkwill are long gone, but their descendents continue what they started]

      “We are the ones who will hear,” said Phouchg, “the answer to the great question of Life….!”
      “The Universe…!” said Loonquawl.
      “And Everything…!”
      “Shhh,” said Loonquawl with a slight gesture. “I think Deep Thought is preparing to speak!”
      There was a moment’s expectant pause while panels slowly came to life on the front of the console. Lights flashed on and off experimentally and settled down into a businesslike pattern. A soft low hum came from the communication channel.

      “Good Morning,” said Deep Thought at last.
      “Er..good morning, O Deep Thought” said Loonquawl nervously, “do you have…er, that is…”
      “An Answer for you?” interrupted Deep Thought majestically. “Yes, I have.”
      The two men shivered with expectancy. Their waiting had not been in vain.
      “There really is one?” breathed Phouchg.
      “There really is one,” confirmed Deep Thought.
      “To Everything? To the great Question of Life, the Universe and everything?”
      “Yes.”
      Both of the men had been trained for this moment, their lives had been a preparation for it, they had been selected at birth as those who would witness the answer, but even so they found themselves gasping and squirming like excited children.
      “And you’re ready to give it to us?” urged Loonsuawl.
      “I am.”
      “Now?”
      “Now,” said Deep Thought.
      They both licked their dry lips.
      “Though I don’t think,” added Deep Thought. “that you’re going to like it.”
      “Doesn’t matter!” said Phouchg. “We must know it! Now!”
      “Now?” inquired Deep Thought.
      “Yes! Now…”
      “All right,” said the computer, and settled into silence again. The two men fidgeted. The tension was unbearable.
      “You’re really not going to like it,” observed Deep Thought.
      “Tell us!”
      “All right,” said Deep Thought. “The Answer to the Great Question…”
      “Yes..!”
      “Of Life, the Universe and Everything…” said Deep Thought.
      “Yes…!”
      “Is…” said Deep Thought, and paused.
      “Yes…!”
      “Is…”
      “Yes…!!!…?”
      “the new filtering engine of OpenSMTPD isn’t ready yet,” said Deep Thought, with infinite majesty and calm.

      1. 2

        Is this the new “Is KERNSEAL ready yet?”

    2. 5

      I have installed 6.4 recently on my X200 after years of windows use (previously Linux, NetBSD), and noticed that after RFKILL cycle iwn does not reactivate again, but have to issue ifconfig iwn0 up manually. Otherwise everything worked out of the box!

      Asked around on IRC, where I was given a pointer to try to (ab)use ifstated (8) as a workaround. Manuals were adequate, I could easily set up the daemon without any help from the internet. The workaround solved the problem (a cdce interface goes away and comes back at the same time, and I piggybacked the event).

      Few days later 6.5 is announced, and in the changes list I see:

      o The iwn(4) and iwm(4) drivers will now automatically try to connect to a network if the radio kill switch is toggled to allow radio transmissions while the interface is marked UP.

      I actually planned to report the bug/solve it myself and submit patch after I managed to set up the machine completely. I perceived this as wow such support, someone was lurking around and just fixed it, but actually it was already fixed by the time I encountered the problem.

      I have some other stuff to do before upgrade, but I’m looking forward to it! I’m sold!

      1. 10

        Cool, I’m glad someone finds my hardware kill switch fixes useful.

        Running an X230, I was annoyed by the fact that it would only work in one direction, so I took the opportunity to get familiar with the code. Both Intel drivers are fixed, and the switch just works; next up is athn(4).

        Have fun with 6.5, I think it’s a pretty good release.

      2. 4

        The release page has already caught up :^)

        1. 4

          New pvclock(4) driver for KVM paravirtual clock.

          Is it a workaround for the infamous timing issues on some KVM versions? If so, it is a game-changer for me!

          1. 4

            Honestly, I think the underrated piece of this is the OpenBGPD-portable release. If you have ever had the misfortune of running some… unnamed large vendor hardware for BGP, switching to OpenBGPD was one of the most satisfying things in the world.

            1. 2

              Is there anything worth paying special attention to for this release, or should it be a smooth upgrade?

              1. 2

                As I’m a bit ignorant about these things, just wondering if anyone can explain the motivation for the Xorg setuid change?

                1. 10

                  A local root hole in X.org discovered around the release of 6.4: https://marc.info/?l=openbsd-tech&m=154050351216908&w=2

                  1. 2

                    https://marc.info/?l=openbsd-tech&m=154050351216908&w=2

                    Wow, that’s… Very interesting.

                    OTOH, I think it’s pretty cool that Theo would reveal such info even though it may seem to undermine credence about revealing security vulnerabilities to his own project. I mean, if his own people don’t tell him about the upcoming embargoed bugs due to the known stance of The OpenBSD Project against security embargoes, what can be expected of other projects and bigger vendors?

                    I’m happy to see matthieu is still a committer, though, and has been committing throughout Oct and Nov last year around this controversy, too; i.e., at least from the public eye, there’s no evidence to suggest that his account was ever disabled; but this is some harsh reality come OpenBSD way…

                  2. 6

                    Heh, I’ve used startx(1) for as long as I’ve used Unix systems, guess I have to finally start using a login manager!