While I also doubt that this is possible today, I am sure the NSA is looking at placing the respective sensors. Then we will have to do "analog routing" and mix in mains hum form several places to obscure where and when things have been recorded. Maybe we should start to offer recordings of local grid noise. Would not be that difficult to do.

Well, fighting fascism is difficult. But there really is no alternative for anybody with at least a shred of noncompromised personal ethics. The price of doing nothing is just way to extreme.

In fact, the US can likely now steal any and all data it likes and does not need to participate in any international research efforts.

Well, I guess they actually care about getting things done, instead of posturing before the whole world as "the greatest nation on earth". Actually doing things works a lot better than to rely on past glory.

Yeah, by not giving people a commandline worth anything in the first place. But you are right: MS realizes their customers are incompetent, immature whiners that would blame MS is they used MS products to shoot themselves in the foot. So the function to shoot anything was removed.

You have noting to contribute but could not keep your mouth shut?

If you do not do input sanitization, you are screwed anyways. If you do input sanitization, this is not a security problem anymore. Stop trying to fix problems in the wrong place.

You do not seem to understand what this discussion is about. It is about security, not safety. And when it is about security, the wildcards come from somewhere else and need to be sanitized in that path. A user doing this to himself is just stupid, but not a security issue. (And yes, as somebody that once had to recompile bash to get a longer commandline-buffer, I know exactly where the expansion happens.)

And not everybody has any business writing security-critical code. You are asking for the illiterate to be allowed and encouraged to write poetry. That cannot ever work.

It may be counter-intuitive for people that have very little experience with a UNIX commandline. All others did run in the issue at some time that they could create, but not easily delete a filename "-v" or the like. But people with very little UNIX commandline experience have zero business writing security critical software that uses the commandline tools!

This is a complete non-issue. Incompetent people will usually screw security up and this is just one of the countless ways to do it.

That is complete BS. Preventing users from doing things they legitimately want to do is not a valid approach to securing untrusted interfaces. The valid valid way is to sanitize the untrusted input before using it and only a complete moron will pass a wildcard from an untrusted source, unless it cannot do any harm where it is going.

Really, this is well-known, non-surprising and will not happen to anybody with a security mind-set. Of course it will happen in practice. But there are quite a few other variants of code injection (which this basically is) that the same people will get wrong. Complete input sanitisation is mandatory if you need security. I mean, even very early Perl-based CGI mechanisms added taint-checking specifically for things like this. If people cannot be bothered to find out how to pass parameters from an untrusted source securely, then they cannot be bothered to write secure software.

The fix is not to change the commands. The fix is to exchange people that mess things this elementary up against people that actually understand security. Sorry, you cannot have developers that are cheap and competent at the same time and even less so when security is important.

No. You cannot turn these things into CPUs of any meaningful power level.

Asynchronous design is not feasible complexity-wise. It is one of these "magic" things that crop up time and again but never work out.