>The last 50 years of research have no impact at all at current day computing, except for silicon and SOCs etc.

This.

Doing new stuff in silicon is like shooting fish in a barrel. You just go find some research paper that has a good idea, then go and design it in hardware. I little hard math is enough to ensure that no one else is doing it.

Software seems stuck in a research time warp. Plan 9 was how long ago? Yet we don't have network transparent multi processing and per process name spaces in popular OSs.

>I've never seen either a Mac or a Linux box suffer from 'decay'.

So you weren't a big user of MacOS 7?

Mega volcano?

Does TFA mean a big volcano or a million volcanos?

>Every protocol that runs over RS232

Protocols that run over RS232 are not RS232. RS232 is the interface spec.

RS232 didn't have packets. It had wires. It didn't have ACK/NACK either. It had CTS/RTS and DCR/DTR. There were some secondary signals (STD, SRD etc) that were rarely implemented after 1980.

>If anything, this is nothing more than an industry standards issue.

Get IEEE 802 to do it.

You'd be able to pass your medical records through an 802.1D compliant bridge transparently, with or without Q.

Does it or its owner become suddenly more dangerous after crossing a state line?

No I didn't. I'll play with bash versions and see if there was a change. I don't think so though.

I have lived the ASN.1 horror. I will kill it. I will show no mercy. Know this, for it is true.

They will try to put CALEA crap in by default with no option to turn off.

But jar jars blink.

Fortunately for the evil doers, they don't have to be bound by past vulnerabilities.

Just give it a name that the script already uses.

If the script uses functions passed through the environment variables, it is now going to be written such that those variable names are prefixed with _BASH_FUNC_ because the new changes require it. So the attacker follows suit. The point being that the attacker can indeed modify the name and he or she or it can modify it to suit the script being attacked.

The underlying problem is using environment variables (I.E. data) that get executed by the interpreter. Don't do that. You can write CGI programs that are invulnerable, but you can't be sure every CGI program in every bit is system and web bloatware is invulnerable.

Better to fix CGI. Give it a new interface. E.G. It calls the program and hands it a pointer to a file that contains the variables. Or uses any other form of IPC. Just make sure it can't get executed unless intentionally by the idiot writing the receiving end.

>that setting a variable whose name starts with _BASH_FUNC_ is going to be nigh impossible through a standard HTTP interface.

But that's exactly what I did by appending ?_BASH_FUNC_thingy=myattack to a url to a CGI script.

The telecoms would add X25d with ASN.1 line coding to systemd if they could get away with it.

So they're stuck to the bottom of the screen?

Can they be ajar?