Thanks yeah just woke up, finished making my way through the single-article website and still unclear if other libcs do the same thing (the article says libxcrypt picked it up, but only after musl did it).

To be fair (as the sshole site mentions) it is also necessary to fake a password hash check to avoid timing side channels revealing to remote clients whether users exist, so returning a sentinel value is not a horrifically unreasonable solution to make sure even naive code does approximately the right thing.

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...?

I'm not entirely sure an empty string, tilde, or @ symbol would really have been better, except in retrospect.

The spec only defines a single error state - ENOSYS, that is basically only for systems that don't implement crypt at all.

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.

Which is notable because musl is more known for adhering to the spec to the point where they break programs that assume nonstandard behavior.

Alpine matches the first.

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.

No, no don't let all of that distract you. We gotta hype this. This is the new SSH2SHELL dude. Have we registered the domain yet? I'm scheduled on Fox News tomorrow.

> You wake up in a strange place. Something happened. Everything's gone. No wallet/keys/smartphone/tablet/laptop.

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"

The somewhere for password authentication is a place you have physical access. Not ssh.

PasswordAuthentication=no usually means that ssh stops directly reading /etc/passwd to authenticate, not that it stops accepting passwords completely. You'll still be able to log in with a correct password, provided KbdInteractiveAuthentication is still on, PAM is available, and the PAM policy allows for it.

The email at the root of my identity is tied to a country code domain in my country. There are robust legal processes for enforcing my status as the registrant and regaining control of it. Once I have access to that, I can use that to gain access to everything downstream.

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.

Remotely: An encrypted file with a seed / master passwords to all the other data, published under a public url you can remember, but not linked anywhere and not listed.

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

I log in via console, either physical or virtual (the latter requires MFA though)

I walk to my pc and type ssh-keygen. If i can’t do that I’ve got bigger problems. “I must be able to recover remotely using a memorised credential” is a terrible requirement.

Does this happen to you a lot? You may have other issues

Yeah your vault has password authentication. Your password manager in other words. Your vault is where you store your private ssh keys, and or the passwords for the keys.

Sometimes you just have to start over. It’s not the end of the world.

A scenario where all the backups are gone and the server is somehow the only thing that survived is not a very plausible one.

1Password subscription and the memorized key. 1Password is the only place my ssh private keys are stored.

Why is wireguards auth better than openssh auth?

The culture is downstream of the design IMO. In general, people write the API that is obvious. In C, returning a string is obvious, while defining a custom OptionalString type is high friction. In Rust, returning Option<String> is as easy and obvious as returning a String.

All the standard Rust libs use results. The standard C libs use errno, return 0, return -1, return EOF, return nullptr, segfault, or of course UB. Other libs dream up things like returning "*". C++ has exceptions in some areas but not others, and if you turn them off, they're segfaults. I actually like C, at least more than C++, but the error handling is the worst part.

Sure, you could write deliberately bad code in Rust by unwrapping everything everywhere, but the point is that it is a distinct choice to do so. You can’t forget to handle errors - you have to make the choice to disregard them. If you forget to check for NULL in C it won’t complain and it’s dependent upon you to remember to do so.

In the vast majority of programs, errors and non-results are irrelevant at the call site. You want to program for the happy path and not wrap every single call with error checking code or `try/catch/finally`.

    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)

The question is _where_ the error needs to be handled. It's almost never directly at the call site. And then there's a few issues with checked exceptions and Java language things (RMI, closures, etc) which make checked exceptions cumbersome. An exception (checked or not) might be worse than sum types, but they're still a thousand times better then returning an error in-band.

Better design breeds better habits. In Java, you can end up handling a DNS exception 20 layers up the stack, even if your call never actually triggers a DNS lookup, simply because some method deep in the call stack declares it as possible. The culture is to propagate or wrap exceptions rather than translate them into domain-specific errors near the source.

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`.

I agree but I think was also because Java didn't have sum types (or still doesn't? years I haven't read Java) and rethrowing is super easy, while Rust kinda nudges you into the right direction (if you need to rethrow at all, think if you want to rethrow verbatim or wrap with a semantic error type).

Right idea at the wrong time.

They were overused, but some actually make sense, such as the IOException and SQLException

I always thought the ideas was great, but type system was holding it back. If you could have expressed that your thrown exceptions are the same as some other method's (e.g. a method of a class given as a parameter), and some other classes, then it could have been a lot less annoying. Powerful, even! But Java did take its sweet time to get even type parameters.

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

Amen, people saw the symptoms of "needs more syntactic sugar" and misinterpreted it into "rigorous error handling is bad".

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.

How is this more convenient, being able to display it as text?

Thank you for your comment, it's very refreshing (and comforting for me actually). Have a good day.

no, ssh INTO a running alpine container. who runs sshd in a container when you can just attach a terminal?

Considering how much people whined about the MinIO images I would expect that it is not that uncommon.

When I set up a client sftp drop I had the luxury of saying "key based access only"

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.

If you refused, would you get overruled internally?

I went and checked this. I can admin my server with Cockpit using either the web service (using my username/password) or the desktop client (via private key) without issue even with SSH password authentication disabled. I do usually disable the web service so had to reconfigure to check.

Just do no password at all.

I thought OpenWrt used Dropbear by default?

You'd be surprised by the amount of people using containers that don't know/care what is inside.

I agree entirely, but I'm not sure changing `crypt` to return `"*"` instead of `NULL` on failure qualifies. It's much more of a considered decision, which happens to be very wrong.

What if the test suite passes in the middle of the night? Should all administrators interrupt their sleep and get up to recompile their servers immediately?

Randomly using a different users's hash seems so wrong to me, but maybe I've just been too deep in PII stuff for too long.

So then rebuild everything? I don't see the problem. NixOS shows how it's done.

IMO only good thing about alpine is that it's a good environment to build stuff that links musl statically.

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.

More evidence than allowing root to log in with any long password?

Another comment said that returning a * was to avoid returning null which would crash users of the library who didn't check for null. That seems like a C smell to me

>because crypt in musl started returning "*" in some cases some years ago

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.

> How would using a language different than C help here?

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

I write firmware where the program has to run for years unattended.

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.

why does this logic bug exist? why are they returning a string, why not a result type, (nil, err), or something else?

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

Rust would absolutely have saved you here. Even with `Result<String, String>`, which is pretty poor design, there's no confusing `Ok(s)` with `Err(s)`. Sure you can go out of your way to write something like

    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.

It would, due to Result<T> and #[must_use] on it. Nobody would return “*” as a sentinel in Rust.

languages with more features would mean developers aren't choosing between unchecked NULLs or sentinel strings.

it's unbelievable to me that there isn't a larger movement of developers to move away from c towards better & safer languages. look at how much pushback the rust4linux folks get, primarily from c developers who are simply afraid of change. imagine engineers not adopting safer building practices because "they prefer the old way"....it's disgusting honestly.

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.

no rust programmer would ever return a sentinel string like this.

Cars without seatbelts and airbags chopping off driver's heads in relatively slow collisions? Well guess what, that could happen in a modern car as well if the driver sticks their head out the window while going through a very tight tunnel!