The only thing that is required to happen is that they all obey the rules of the POSIX shell (when called as /bin/sh).

Otherwise, anything goes.

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...

All the userland utilities must have the behavior (and problems) specified here:

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/

Eh - I actually like developing on OpenBSD first, because of restrictions like this. If it runs on OpenBSD, you are likely to have fewer bugs around things like malloc.

OpenBSD is also really good about upstreaming bug fixes, which is a good thing. Firefox used to be a dumpster fire of core dumps on OpenBSD, and many issues were uncovered and fixed that way.

> I get the feeling it's going to break all shar archives with binary files

shar encodes binary files. Here's what it does with a file that has contents: "foo\0bar\n":

    sed 's/^X//' << 'SHAR_EOF' | uudecode &&
  begin 600 foo.txt
  (9F]O`&)A<@K.
  `
  end
  SHAR_EOF

> I get the feeling it's going to break all shar archives with binary files (not that they're particularly common)

Base64 encode them.

This is not diverging further, this is bringing sanity to the table

> Here's the actual diff:

Only 8 short, simple lines of c code. Beautiful.

> "We are in a post-Postel world" is a great way to put it.

See also RFC 9413 (https://www.rfc-editor.org/rfc/rfc9413.html), originally called "draft-thomson-postel-was-wrong" (https://datatracker.ietf.org/doc/draft-thomson-postel-was-wr...).

Agreed.

When every implementation in wide use has their own quirks, you must support them all to make your program widely used. Every special case is yet another potential bug to chase down.

It also allows "Embrace, extend, and extinguish" -strategy that Microsoft used so successfully to assfuck the internet over a decade.

"Postel" is not a term that carries any significance for me, and Googling that word didn't turn anything up that seemed relevant.

Who or what is a Postel?

There is no such thing as a post Postel world. But handling the input in any other way than crashing or ub IS perfectly Postel.

Deciding that nul is invalid data, and refusing to allow it, and refusing to munge the data and proceed based on the munged data that you essentially made up, as long as whatever you did do instead was graceful and intentional, to me that is perfectly Postel.

This is also where Google went right with QUIC: encrypt as much as possible to show middleboxes the least possible. This combats ossification. Then again it seems likely middleboxes will just block QUIC (or UDP in general).

The Cryptographic Doom Principle (if you have to perform any cryptographic operation before verifying the MAC on a message you’ve received, it will somehow inevitably lead to doom)[1] is a sort of anti-Postel's Law.

[1] https://moxie.org/2011/12/13/the-cryptographic-doom-principl...

I wonder if it’s https://justine.lol/ape.html / cosmopolitan libc

Not if it was done competently. Shar files and the likes shouldn't contain NULs, even if they contain compressed data. The appended data should be binary safe.

Looks fine here, maybe they're blocking your IP range for some reason?

Fine for me. I just got a HTTP warning and nothing else.

~~I believe Android uses toybox, not mksh.~~ It does use toybox, but toybox doesn't appear to include a shell.

It's blocked for me too, but only on my home Internet (Xfinity), not my phone (Google Fi/T-Mobile).

What's your browser? The server is using an old TLS version which is no longer supported, and some clients will try https and fail there and not try http.

Works from an EU IP, so whatever it is, it's probably not GDPR?

> Android system shell

This hurt a little.

Reminds me of this...

https://hackaday.com/2024/01/20/how-a-steam-bug-once-deleted...

Well, knowing how to deal with wacky input and corner cases are a requirement of learning ANY programming language. Bourne-style shells are no exception.

Your example has illegal syntax, but the biggest issue is that you should never parse the output of ls. The shell has built-in globbing. This is how you would loop over all entries (files, dirs, symlinks, etc) in the current directory without getting tripped up by whitespace:

    for e in *; do echo "got: $e"; done

> Is there any legitimate use for filenames with newlines?

IMHO no, but they can exist, so you need to handle them without blowing up. Also, even spaces are considered delimiters here, which is why it's bad form to parse the output of ls.

    $ touch "foo bar baz"
    $ for f in `ls`; do echo $f; done
    foo
    bar
    baz

    # always use double quotes, though they aren't needed here
    $ for f in *; do echo "$f"; done 
    foo bar baz

You can also create files named e.g. '--help' (if you're not particularly malicious) and with globbing it'll cause e.g. 'ls *' to print help.

Sticky notes on the desktop :) Who needs data storage when you can store it all in the metadata?

A GUI file browser will display the filename with a newline in it as a new line (and an icon above it) so as to be asthetically pleasing.

this is why things like `find -print0` exist, which is IMO the easiest way to handle this robustly.

The recommendation is solid, but FWIW no one looking for stability would choose Ubuntu, among the Linuxen!

From the article: "It remains possible to put arbitrary bytes AFTER the parts of the shell script that get parsed & executed (like some Solaris patch files do). "

If you don't know anything about OpenBSD, here's a fun thing:

1. Randomly choose "yes" or "no" to this question.

2. Read the post and get the answer.

3. Repeat until you begin to get a tingly "Spidey sense" that overrides your random-choice.

My Spidey sense here was, "Yes, because OpenBSD would have already thought about and covered that use-case." And indeed, toward the end of the post, that contingency is covered and documented.

Note: if you try this at your job and sense that the company will almost always choose the worst option, you should probably leave that job.

Are you talking about Shar?

https://en.wikipedia.org/wiki/Shar_(file_format)

They were generally uuencoded or similar

No, they still work.

You still can; it just needs to go at the end:

> It remains possible to put arbitrary bytes AFTER the parts of the shell script that get parsed & executed (like some Solaris patch files do).

Looks like you might be able to at the end of the file, reading the commit message, just not willy-nilly in the middle. :)

FreeBSD made many cool moves in the 14.0 release, like finally getting rid of sendmail and adopting DMA (the irony), so perhaps there's a chance?

But FreeBSD has always been much less focused on polish/cleanliness than OpenBSD; I mean - they have THREE firewalls, wtf.

This was "answered" in 2013 at the end of this post, https://marc.info/?l=openbsd-misc&m=136724343006024&w=2

I guess it hasn't changed since.

Funny enough filenames are just byte sequences. So almost anything goes.

There was just some patch that added '/' protection, because that's the only character that's not allowed in filenames.

https://github.com/openbsd/src/commit/46f7109a9e03df89b66ada...

Early spec of TCP had a section on the robustness principle that was generally known as Postel's law (https://datatracker.ietf.org/doc/html/rfc761#section-2.10). At the time and until recently this was considered good design. Nowadays people generally want servers to be stricter in what they accept since decades of experience dealing with diverging interpretations of a specification create problems for interoperability.

Postel’s Law, also known as the Robustness Principle:

> be conservative in what you do, be liberal in what you accept from others

It’s intended as a way to maximise compatibility, and people have generally followed it when designing protocols and file formats. However it’s led to many security vulnerabilities and has caused a lot of compatibility problems itself. These days a lot of people are realising that it’s more harmful than helpful.

Postel’s Law: https://datatracker.ietf.org/doc/html/rfc761#section-2.10

It was not. The Crowdstrike issue was:

1. Their code was calling a 21-parameter "matcher" function with 20 parameters of data.

2. They didn't notice, because all the matcher rules had "allow anything" for the 21st parameter and so never looked at it.

3. They later published the first list of rules with something other than "allow anything" as the 21st parameter, direct to customers.

4. On customer machines, the first rule with a non "match everything" 21st parameter went to look at the 21st element of the 20 element array. It expected a string pointer, but instead there was random stack data. It tried dereferencing this to read the string it was expecting, which caused the kernel driver to segfault during early startup, putting customer machines in a boot loop.

https://www.crowdstrike.com/wp-content/uploads/2024/08/Chann...

What a weird take. There are just a few emphasized words in the commit message.