Do you think anyone who changes the default also changes the delivery to Maildir?

(So, at a minimum, it's a local user privilege escalation, of any user to root, in the default install?)

Oh? https://man.openbsd.org/sh.1 doesn't mention -r.

OpenBSD started out as pdksh I believe, not mksh. But it still has a restricted mode.

https://man.openbsd.org/ksh.1#AUTHORS

Also just in - they eat and breathe. :) And the heat-death of the Universe is closer this Monday.

I'm with you on Hackers. It's a guilty pleasure of mine and I still watch it from time to time. I remember watching it for the first time, scoffing at everything and thinking it wasnt even close to reality. But, it was fun. Also absolutely loved the soundtrack. I still listen to some of the artists to this day.

In C:

switch (!!a) & ((!!b) < 1) { case 3: return 1; case 1: fix_b(); return 1; default: return 0; }

If you rewrite 3 as “A & B”, this turns into feature flags, and is less crazy looking (not sure arithmetic is allowed in case statements though).

Better (regardless of language) is flow like this:

if (!b) fix_b(); return a && b;

It's definitely easier to deal with when using a debugger. But that brings a question to my mind: Why are there so many debuggers that make inspecting the results of intermediate expressions difficult? I should be able to step through my code at a finer granularity than a statement.

Re: self-documenting, certainly sometimes (I mean, you shouldn't play code golf...), but in this case the code in question was:

    2218         if (!valid_localpart(maddr->user) ||
    2219             !valid_domainpart(maddr->domain)) {
    ....
    2234                 return (0);
    2235         }
    2236
    2237         return (1);

It's not obvious to me what you would name the intermediate booleans that would be more self-documenting than the function names used there.

Or it could pass argv directly to the execve() family instead of relying on the shell to process arguments. (They effectively do exec on sh -c 'cmd')

I am going to guess they will be smart enough to redesign this for the next major release, and the current patch is just that, a patch for the old design.

You can also use type safety to enforce input validation in C. Just return an error code from the initializer, and annotate it must check. (Or, if you want to couple memory allocation with the checks, write a factory that returns null on input validation errors).

Various parts of the stdlib do this, though often without the compiler annotation. They often hide the struct members inside a compilation unit to prevent callers from bypassing the check (as much as is possible in a language with unsafe primitives).

C have types too. Put your string into a struct, do not expose struct fields directly but make an API to access/modify those fields and it won't be any different.

But you still have to decide what is invalid in order to do that. You could just as easily not think of an invalid input case.

Haskell would due to lazy evaluation.

I feel like the "canonical" example of using pattern matching for nested if statements is fizzbuzz

    fn main() {
        for i in 1..102 {
            match (i % 3 == 0, i % 5 == 0) {
                (true, true) => println!("FizzBuzz"),
                (true, false) => println!("Fizz"),
                (false, true) => println!("Buzz"),
                (false, false) => println!("{}", i)
            }
        }
    }

Not only is it obviously correct, but if you somehow manage to forget a case the compiler will tell you.

    {
        if A && B return println("FizzBuss");
        if A && !B return println("Fizz");
        if !A && B return println("Buzz");
        if !A && !B return println("{}", i);
    }

Pattern matching has been added in C# 8.0. See: https://docs.microsoft.com/en-us/dotnet/csharp/pattern-match...

You also lose a lot of tooling that has been built up over the decades to help with C development, such as model checkers. Simply replacing one language for another doesn't help. It's silver bullet thinking.

This isn't an issue of language or platform, but an issue of process. The OpenBSD team has one of the best overall software development processes out there, but it is still very much a manual process. The class of exploits that are currently being discovered are often discovered via tool-assisted analysis. Such tools can also be used during the software development process to find errors that can be exploited. There are a dozen or so of such tools available for C currently ranging from OSS to commercial. Typically, these tools rely on model checking or bounded model checking, and they are quite effective at reducing attack surfaces or entire classes of errors beyond what most languages can provide on their own.

To take full advantage of model-guided development, however, requires a different software development process that is more difficult to adapt to older code bases overnight. Still, this adaptation is significantly less effort than, say, porting a C code base to Go or Rust. Model-guided development and other types of formal methods aren't silver bullets, and they aren't perfect. But, they are much more effective tools for building better systems than a language or compiler on its own.

I suspect that the OpenBSD developers will adapt to using a model-guided approach. They make use of some static analysis tools already. I find this much more likely than the OpenBSD team switching to Go or Rust, as it is a much more pragmatic solution and a more powerful solution.

That's great and all, but you'd create a host of new bugs unrelated to safety with a pile of new code in a largely unfamiliar language (for the openbsd devs, anyways).

Rewriting the world in some safe language isn't a panacea, this meme is getting very old.

Presumably, you could also build your C code with Address Sanitizer and use that in production, then most memory corruption would segfault. You'd have a performance hit of course, but could be worth it.

Many things, including Rust's type system, could theoretically prevent bugs like this if used properly too. The question comes down to compatibility of these tools with normal development practices. Formal methods are not known for their wide use in software like OpenSMTPD for many reasons, despite being around for decades. Until that changes, I have a hard time believing they are a "pragmatic" solution.

I do it today; your assumption that "it would" is incorrect.

    void z(value* x) {
        /* preconditions. */
        MODEL_ASSERT(valid_value_ptr(x));
    
        /* do operation. */

        /* postconditions. */
        MODEL_ASSERT(z_postcondition(a, b));
    }

In practice:

    z(NULL); /* model failure. */
    z(&uninitialized_value_on_stack); /* model failure. */

It works, and the model checker runs in seconds.

I would call it more of a professional horse.