Recently posted comments

In the meanwhile, the "fixes" in question are nearly pointless and seriously broken. Nearly pointless because compromised _server_ doesn't need to bugger the memory of client with overflows; usually it can do it either with ptrace (when on the same box) or via ssh + ptrace (when the client runs on remote box). Seriously broken - hell knows why, presumably it didn't get reviewed (embargo?).

Thursday fun: after grabbing these packages on a debian box, xine started to coredump on startup. After digging through the stack trace, it turned out that something had been calling XextAddDisplay with NULL dpy, with obvious fun results. Trace went through libxext and libxvmc, both included into updated, so the next step had been to compare source before and after. Diff looked like a pile of moderately pointless hardening, which might've caused that (if some test had been too eager and recovery from the misdetected error sufficiently bogus). However, it contained some bits outside of error paths, and those were worth looking at first. Like that one:

strncpy(*name,tmpBuf,rep.nameLen);
+ name[rep.nameLen - 1] = '\0';

Cargo-cult programming? Innocent braino that simply hadn't been caught before it hit the tree? Hell knows, in either case it's obviously bogus (name is char ** according to the older line, which makes the '\0' in the added one an obfuscated NULL) and very likely to cause the symptoms observed - by the look of that code, name is going to be an address of local variable in caller's stack frame, so it's quite plausible that dpy sat in a stack word nearby and got zeroed out by that assignment. Or the one added next to it (s/name/busID/). While we are at it, error cleanup changes right next to that place in diff were obviously not reviewed either -

XFree(*name);
*name = NULL;
XFree(*busID);
*name = NULL;

spells "cut'n'paste lossage". OK, fixed both, rebuilt libxvmc, xine's working again. Next question - was that Debian-specific fuckup or was it in mainline? git clone, git log -p and it turns out to be the latter... Next step was to catch somebody connected to upstream (airlied hadn't ducked in time) and point to the idiocy in question. Total time spent: two hours...

For what it's worth, the interesting (and potentially very nasty) story here is that this demonstrates a damn good way to insert a hole into some tree - pile up a lot of obvious stuff ("hardening" of that sort, etc.) and bury the backdoor in pages upon pages of that. Then claim a bunch of CVEs and feed the fixes to projects in question, demanding an embargo to reduce the amount of people who'll be reviewing that pile.

I do not believe that this is what happened here (IOW, that this fuckup had been malicious), but it's only a matter of time before somebody pulls that off for real; it's a very tempting attack vector. Review is blunted by combination of sheer boredom (lot of trivial stuff to look through), presumed good intent of the patchset (security improvements, no less), possibility to distribute the hole between several libraries and reduction of the available reviewers by embargo. Deniability is also pretty high, even if attacker gets caught afterwards...

The big issue is, as always, apps. If you want to run Android apps, the phone must have the appropriate specs (and price). If you don't want Android apps, maybe boot-to-Qt lowers the specs, but users may complain, unless the Qt app universe expands rapidly.

Because as you know webtechnologies in general are already everywhere.

If you look at some of the trends, everything is starting to look like an API these days.

When someone wants to automate the deployment of new virtual machines in the 'cloud'. They use an API.

A developer might have written a smartphone native application and want it to talk to a server. They use an API.

Pretty much all these APIs are actually webservices. Thus they end up using HTTP and maybe XML. And these days they end up using JSON instead. JSON is Javascript Object Notation. A webtechnology, a subset of Javascript.

And because no other popular language has only non-blocking libraries it even makes it easy for people to build non-blocking server applications with Javascript by using nodejs. Many have been successful by doing this also.

Would it make you feel better if you won't have to see the Javascript code ? ;-)

There are ways to translate, I should say compile, from other languages to Javascript these days.

New languages are also created that way, even Microsoft has an implementation called TypeScript.

It can even be a way to boost Javascript performance:

http://kripken.github.io/mloc_emscripten_talk/gindex.html

Pay particular close attention to slide 17 where you have the green bar for Firefox+asm.js:

http://kripken.github.io/mloc_emscripten_talk/gindex.html...

In that case Javascript is only 2 times slower than native. It has been the fastest popular scripting language after Lua for a couple of years now if I'm not mistaken. And Lua was built specifically to allow embedding in C and C++ applications and thus use datastructures that better fit that usecase. So eventually the biggest overhead that is left would be translating between loosely typed data and strongly typed data.

Ever since WebGL Javascript supports arrays of strongly typed data. That is also what emscripten, asm.js use. That is where that latest performance boost originated.

So if you go by Moore's law that makes compiled Javascript 18 months behind on native performance wise right now. But for many applications performance isn't what matters, so 2 times as more than fast enough.

Yes, even on mobile. The software running on the CPU is the least taxing on your battery. The screen and WiFi/3G/4G are much, much worse. So even in that environment it is good enough.

And the performance of Javascript it's still improving.

I wouldn't be surprised when people start compiling Python to Javascript they will find that the Javascript runtime is much faster at running Python than what they are used to from the normal Python runtime.

I'm not as sad about webtechnologies winning, I know it has many limitations.

Webtechnologies are created in similar fashion as protocols, by standards bodies. Making standards takes time and you'll usually end up with the least common denominator and some option parts. Or things missing, where the implementer has to decide what to do. Sometimes make a standard less useful. Pretty much every standard has parts we love and hate.

If you want to blame someone, blame Netscape and Microsoft for Javascript.

Netscape forced Brendan Eich to create a new language in 10 (!) days (and he obviously used some nights too).

After which Microsoft forced Netscape to keep all the bad things in Javascript when it was being standardized in ECMA as ECMAScript.

Then Microsoft got over 90% of the webbrowser marketshare and stopped changing IE. Thus all the bad parts in the language remain and there is a lot of legacy code. Which makes it slow to change the language, but it is still moving.

I guess some people think compiling is the solution to that problem.

If people are really serious about it and if we see widespread use of that, then luckily there is source map support, which allows you to do debugging without having to look at the compiled code.

I wouldn't be surprised to see more use of it, especially if the result can run faster than the normal Javascript. And people want to use the languages of their choice.

But at least the web and it's technologies are a cross-platform solution, a platform on top of other platforms.

Many times it means it is less messy to write cross-platform applications based on webtechnologies than to write native cross-platform applications.

Native and cross-platform even sound a bit like an oxymoron. ;-)

The current economic model as is used in the western world and probably many other models will always push for commoditization.

And commoditization in IT/software means: standards, protocols and open source software.

That is where a platform based on standards thrives really well. So I think the web as a platform could be a natural winner in the platform wars.

We've seen what happens when proprietary platforms win the platform race. It isn't pretty, we are still living with the aftermath of some of these platforms.

If Linux and the Free Software/Open Source software alone can't win the platform race, then please, let it be a cross-platform web which can also run on FOSS and not just some proprietary platform.

So I know what you mean, but I'm less disappointed.

Except that very quickly you'll find you need to serialize your symbol and with serialization to an integer, you'll have reinvented Enums..

Take a short break from the kernel business to fix that mirror of yours.
*t