OpenSSH 10.6p2 has been released with a workaround for a critical vulnerability

Though I am surprised that all of the code examples do not use constant-time strcmp(). Actually, I wonder if even constant-time strncmp() would still leak information about whether the account is disabled because in that case both arguments are much shorter? Food for thought.

But yeah, the crypt(3) API is very 80s C, the man page even features a lengthy description of a long-deprecated and utterly broken hashing algorithm using DES that is even implied to be broken in the text itself (and the warning message is so old it refers to "parallel computers" as though they were a new concept). Given that the default mode is to use a broken hashing algorithm, I'm shocked anyone actually uses the libc crypt(3) -- surely it's trivial to just write your own that isn't awful...?

Error handling is underspecified. The spec doesn't give you enough well-defined behaviour, meaning everyone lists pages of error-handling extensions they have added.

Disabling PAM has been "generally good security advice" for decades; I remember suggestions to not use it in the 2000s.

Password logins are often enabled, especially on multi-user and default setups.

If alpine uses the * feature, it's going to be pretty common. Gentoo has it, as does Ubuntu.

If password logins are enabled, you're almost guaranteed to have at least one user with a password (root on all my boxes has one, even if I never use it and it's random garbage).

So the cheese lines up pretty well, this affects quite a bit.

If password logins are enabled, someone almost certainly has a password.

at this point the _last_ thing i care about is my email.

where am i? am i ok? how are my friends/loved ones?

once those are in place, it becomes clearer how to get back to "normal"

Is it fast? No, but that's a feature.

But it does mean I get to lean on the existing processes and identity verification already part of the government bureaucracy and the courts as my backdoor.

Locally: Same, but printed out, laminated, in a safe place with other documents.

    h = file_open(path)
    data = file_read(h)
    file_close(h)
    return data

    return file_open(path).success(h -> h, file_read(h)).success(h, data -> file_close(h); data)

Rust makes handling and mapping `Result` locally more ergonomic, even though `?` makes propagation easy too. Rust, however, also makes it easy to lose the context during propagation and end up with useless `Error`.

Right idea at the wrong time.

I have written very little Java, though, so this is more of an armchair analyst position.

The same way that layered code should react/wrap/translate when it comes to return types, it should do the same for thrown exceptions, and checked-exceptions helps you do that. They're both results of computation.

Then it was a surprisingly customer service intensive process to get the keys from the customers. I never did manage to automate it fully. Weird enterprise systems I have never heard of with strange key formats. ssh1 keys, email mangling them. Their internal processes requiring a password.

And way to many "I am sorry but that was the private key you sent me, That key is now compromised and you will need to remove it and generate new keys anywhere it was used"

I almost regret not allowing passwords, almost, despite the headaches key based is still much better.

Never understood why Alpine is used to actually run anything in a container - if you statically link binary, then you don't need alpine as a base and if you don't what is the point? Don't @ me about image size, even without layer caching we're talking about tiny difference that is often dwarfed by size of your runtime.

Musl itself is a great example of taking "simple and lightweight" so seriously that everyone else gets to deal with the complexity. Slow allocator, underoptimized memcpy/string routines, limited locale support, no NSS, and endless glibc compatibility headaches.

But hey, at least libc is small. %%Proceeds to pull in megabytes of <any other>malloc, and other libraries to replace the slow parts of musl.%%

And now sshhole.com is a particularly spectacular example of what happens when "simple" meets the rest of the software ecosystem.

In Rust, the type of the return value would be a `Result<T, E>`, which means the chain of events that led to this would never have started in the first place.

Easier to formulate invariants and check/prove them. Better language correlates with safer software.

You are right, C with manual memory management, no lifetime management, lack of phat pointers and a culture of leet has problems with deranged maddening bugs that other languages don't have.

But this bug first shows how inband signaling is bad news usually. But worse it's a failure to adhere to the spec properly. If you implement a library and you don't adhere to the spec you're going to bone someone.

Perhaps even worse is obviously the spec doesn't come with any standard testing framework. That was also the root of Apples infamous goto bug.

oh right, because c is a crusty old language with barely any features.

    let hash = match result {
        OK(s) => s,
        Err(s) => s,
    };

@my-huge-pony does make a good point elsewhere in the thread: if the potential error was not foreseen and the code was written originally to return `String` instead of `Result<String, Error>` then even Rust would be in a pickle.

what will it take to move away from c? older devs retiring. Planck said that "science advances one funeral at a time" and i fear it will be the same for software.