4 ms·

I don't think that's actually true. I think it's rather than the market rewards performance above security. Let's see: is there a mature, maintained TLS stack

I don't think that's actually true. I think it's rather than the market rewards performance above security. Let's see: is there a mature, maintained TLS stack written in a memory-safe, high performant, cross platform language that Mozilla could have been using for free, instead of NSS? Your argument is that there isn't one because only C++ coders are "doers" instead of "talkers" but this argument is wrong because such a stack does exist. It's JCA/JSSE and ships with every OpenJDK. JCA/JSSE is a full, open source TLS and cryptography stack. It's written, even at the lowest levels, in Java, in which this kind of memory error cannot occur. It's usable from C/C++ via JNI. It's commercially maintained and has been maintained for decades. It keeps up with the latest features. Its performance in the latest versions is comparable to OpenSSL even (not always in the past). Mozilla could have used it. They could have improved it, even. They've shipped browsers with integrated Java before, in times when computers were much less powerful. They chose not to, why, well, the charitable explanation might be download size or performance, but we could just as easily argue it's because C++ guys don't really care about security. Bugs happen, they ship a fix, people let them off the hook. Eh another buffer overflow, who cares. Not like anyone is going to switch products over that, right? Reality is, our industry could rewrite lots of software in safer languages and already has. Java has tons of libraries that do the same thing as C++ libraries, and which could be used today. You can shrink HotSpot down to about 7mb compressed, last time I experimented with this, which is like 10% of the size of a typical mobile app. It's just not a big deal. Perhaps the biggest problem is that JNI is an awkward FFI but there are fixes for that also, the new FFI (Panama) is a lot better than the old one.

nineteen999 5y ago
Technobabble.
scoutt 5y ago
Sincerely, as a C/C++ programmer, if I have to start a new project and you propose to link a Java library, it'd give me the creeps. Let's say I agree: does my project now requires to install a Java VM together with my project? Which Java VM? I still don't understand the difference between OpenJDK and the "other one"... JDK? JRE? I only installed it once many years ago because Eclipse CDT required it and I might have wrote "sudo update-java-alternatives --set /path/to/java/version" one too many times (AOSP development). OK. I'll make an installer to install Java with my project. But the customer has another older version, or a competitor version, or ..... I don't care anymore. Do I have to build this library? What paraphernalia do I have to install and learn to automatize, build and test a complex Java library? Do I have to maintain a JNI interface too? Where is the JCA/JSSE source code? (I can't find it for real) And who maintains it? Oracle? What if Oracle one day pulls the plug or comes after me with one of their famous legal moves just because? These are my concerns. You might try to convince me, but I already learnt about C/C++ libraries, DLL hell, etc, and have all my fixes in place. > Bugs happen They will still happen. Put your heart at peace.
- native_samples 5y ago
  I think you're making my point for me, no? Your arguments are all variants on "I don't understand modern Java and prefer to keep writing buffer overflows than finding out". To answer your questions: 1. Java is these days like UNIX, there are lots of "distros". OpenJDK is the upstream on which most of them are based. You can just use that unless you have some particular preference for the other vendors. However the compatibility situation is much better, there aren't any compatibility issues and JVMs are all more or less drop-in replacements for each other (Android is an exception but has got a lot better over time). 2. You don't need to install Java alongside your app. The JVMs is just a library and a few data files. You can easily bundle it with your app and the user will never know. 3. JCA/JSSE is built in to Java so there's nothing to build. Additionally you don't have to build Java libraries to use them anyway, because binary distribution works so everyone just distributes binary JAR files. 4. The source code is spread around several modules because JCA is pluggable. But for example a lot of the crypto code is found here: https://github.com/openjdk/jdk/tree/master/src/java.base/share/classes/com/sun/crypto/provider https://github.com/openjdk/jdk/tree/master/src/java.base/sha... 5. Oracle maintains it but other companies contribute, like Amazon, Microsoft, Red Hat etc (well, to Java as a whole). It's released under the GPL with Classpath exception license. They aren't going to come after you for using it - there are 12 million Java developers in the world. The only company that has ever got sued is Google and that's because they violated the (at the time non open source) license of Java to make a mobile version that wasn't from Sun. They knew they were doing it and chose to chance it anyway (which worked out quite well for them actually). Since then Java became fully open source and this no longer applies, and it'd have never applied to normal users of it anyway. I'm not trying to convince you here of anything, only to point out that everyone saying "there was no alternative" is just wrong. The failure mode here is not sufficiently advanced fuzzers. The failure is that there has been an alternative to NSS for years but C++ shops like Mozilla keep maintaining crappy decades old C libraries with memcpy calls all over the place, because they know and like C. That's it. That's all it boils down to.
  - scoutt 5y ago
    > "I don't understand modern Java" Exactly! > "and prefer to keep writing buffer overflows than finding out" Not exactly. I would rather take the risk of writing buffer overflows than using over-bloated infrastructure, being in code size and/or performance, tooling, including learning time. It's a tradeoff. It's always a tradeoff. Mozilla might have had their own reasons, and probably not on a whim. If I have to write the software for an ECU the approach will be different (no, it won't be Java). I've been in the industry for a long time now (C/C++, mostly embedded). The pattern is the same. This time is you with Java, it might be the Rust/Go crowd , the other 4 users with Ada or the 2 users with FP: everybody loves to hate C/C++ and everybody have their whiteboard reasons, but C/C++ has been pushing the world forward for the last 30 years minimum, and it's not stopping anytime soon. There must be a reason other than "C/C++ programmer are lazy dummies, they prefer to write bugs instead of learning the marvels of [insert random language here], because they are in love with memcpy", don't you think? The code is there. You can try to link Java JCA/JSSE to Firefox or whatever the project is about. I'm interested in learning how it looks and how it works.

nineteen999 5y ago

Technobabble.

scoutt 5y ago

Sincerely, as a C/C++ programmer, if I have to start a new project and you propose to link a Java library, it'd give me the creeps. Let's say I agree: does my project now requires to install a Java VM together with my project? Which Java VM? I still don't understand the difference between OpenJDK and the "other one"... JDK? JRE? I only installed it once many years ago because Eclipse CDT required it and I might have wrote "sudo update-java-alternatives --set /path/to/java/version" one too many times (AOSP development). OK. I'll make an installer to install Java with my project. But the customer has another older version, or a competitor version, or ..... I don't care anymore. Do I have to build this library? What paraphernalia do I have to install and learn to automatize, build and test a complex Java library? Do I have to maintain a JNI interface too? Where is the JCA/JSSE source code? (I can't find it for real) And who maintains it? Oracle? What if Oracle one day pulls the plug or comes after me with one of their famous legal moves just because? These are my concerns. You might try to convince me, but I already learnt about C/C++ libraries, DLL hell, etc, and have all my fixes in place. > Bugs happen They will still happen. Put your heart at peace.

native_samples 5y ago
I think you're making my point for me, no? Your arguments are all variants on "I don't understand modern Java and prefer to keep writing buffer overflows than finding out". To answer your questions: 1. Java is these days like UNIX, there are lots of "distros". OpenJDK is the upstream on which most of them are based. You can just use that unless you have some particular preference for the other vendors. However the compatibility situation is much better, there aren't any compatibility issues and JVMs are all more or less drop-in replacements for each other (Android is an exception but has got a lot better over time). 2. You don't need to install Java alongside your app. The JVMs is just a library and a few data files. You can easily bundle it with your app and the user will never know. 3. JCA/JSSE is built in to Java so there's nothing to build. Additionally you don't have to build Java libraries to use them anyway, because binary distribution works so everyone just distributes binary JAR files. 4. The source code is spread around several modules because JCA is pluggable. But for example a lot of the crypto code is found here: https://github.com/openjdk/jdk/tree/master/src/java.base/share/classes/com/sun/crypto/provider https://github.com/openjdk/jdk/tree/master/src/java.base/sha... 5. Oracle maintains it but other companies contribute, like Amazon, Microsoft, Red Hat etc (well, to Java as a whole). It's released under the GPL with Classpath exception license. They aren't going to come after you for using it - there are 12 million Java developers in the world. The only company that has ever got sued is Google and that's because they violated the (at the time non open source) license of Java to make a mobile version that wasn't from Sun. They knew they were doing it and chose to chance it anyway (which worked out quite well for them actually). Since then Java became fully open source and this no longer applies, and it'd have never applied to normal users of it anyway. I'm not trying to convince you here of anything, only to point out that everyone saying "there was no alternative" is just wrong. The failure mode here is not sufficiently advanced fuzzers. The failure is that there has been an alternative to NSS for years but C++ shops like Mozilla keep maintaining crappy decades old C libraries with memcpy calls all over the place, because they know and like C. That's it. That's all it boils down to.
- scoutt 5y ago
  > "I don't understand modern Java" Exactly! > "and prefer to keep writing buffer overflows than finding out" Not exactly. I would rather take the risk of writing buffer overflows than using over-bloated infrastructure, being in code size and/or performance, tooling, including learning time. It's a tradeoff. It's always a tradeoff. Mozilla might have had their own reasons, and probably not on a whim. If I have to write the software for an ECU the approach will be different (no, it won't be Java). I've been in the industry for a long time now (C/C++, mostly embedded). The pattern is the same. This time is you with Java, it might be the Rust/Go crowd , the other 4 users with Ada or the 2 users with FP: everybody loves to hate C/C++ and everybody have their whiteboard reasons, but C/C++ has been pushing the world forward for the last 30 years minimum, and it's not stopping anytime soon. There must be a reason other than "C/C++ programmer are lazy dummies, they prefer to write bugs instead of learning the marvels of [insert random language here], because they are in love with memcpy", don't you think? The code is there. You can try to link Java JCA/JSSE to Firefox or whatever the project is about. I'm interested in learning how it looks and how it works.