It still boggles my mind how javascript is letting code access addresses outside of its own program space, and that isn't considered a fatal bug apparently.
Sorry for a slight offtopic, but the thing is complex here. JS was made for something totally different that is used for. Internet was made for something different. To solve these differences JS had to grow outside its design rules and it started to happen.The same thing is with Flash, but they tried to accommodate by including highly optimized media codecs and making bigger impact on programming. Finally I'm still sticking with this insecure program as I don't have a few video accelerators nearby to decode HTML5 video
.
The main problem is that after a longer development nobody has a clear picture what happens inside a complex system! Everyone knows their parts only.
Let me tell you a story of one bug. I am working in a FEM numerical simulation package with origins in 1980s. This is a very well-known package in some scientific and industrial applications and it applies very well, it was developed by few institutes and companies. It is of course closed source except some uncommented user programs code. Solver input files grown so much, that they're now formed from includes by a complex set of BAT files, but that's only a temporary hack (since 1998). There is a memory leak (reading after boundary of array) while computing destruction of solids which makes one variable normalized to 0..1 range go past 1.0 value if some conditions are met. I intentionally use it to trim solids in some conditions, the leak was introduced 15 years ago with few other ones allowing to specify quite funny conditions when the material disappears. Everyone knows about the leak, I know the internals of the company. But that's what happens when someone tries to fix it:
1. Solids team (trying to maintain compatibility with paper tape, err, elements mesh in text files for Outline-compatible plotters) tells domain team to fix it.
2. Re/meshing (domain) team tells that it's not their business as they're doing Fortran, not C. Let "math magicians" do it as they are responsible for models.
3. "Math magicians" have no idea about leak. They use "Trivial solutions" as per LoseThos definition (no protection, no security, continuous memory access) and, for them, array boundaries are questionable if only two arrays are placed one near another which happens all time thanks to their C programs. Let coding team do it, they translate their notes in poor C pseudo-code to Fortran for the solver.
4. Coding team: We translate WHAT?
5. In 2014 one programmer tried to fix a leak. Instantly everything failed. The deeper you go, the worse things you see. Output format locked to 4 threads? Why not, there were maximum 4 when it was designed! Unconditional reporting errors to serial port using proprietary codes? There must be a ADM3a terminal connected to this 64-core Xeon HPC machine! Both endian values in one array in results file? Why not? Switch endianness reading every 4th float and you're OK.
6. Managers try not to see function (name translated by me) "value_take_from_space(uint coordinate, unsigned char typecode)" which hacks all over memory. Inside there is a bloody mess of memory management, #define hell to make it work on different architectures and terrible hacks to avoid "platform-dependent complications".
I hope Pyra project will never reach this stage and people designing it will always know what they design.
