3 ms·
One of the most used platforms nowadays is Java. Java libraries are distributed as binary bytecode blobs. They can also include native libraries, which usually
by vbezhenar 3y ago
One of the most used platforms nowadays is Java.
Java libraries are distributed as binary bytecode blobs. They can also include native libraries, which usually are extracted to /tmp and dynamically loaded into the process. The security of this approach is questionable, if you ask me, however that's the way things were for the long time and that's the way things will be for the long time.
I think that striving for better security is a noble goal, but if that prevents usability, security should step aside, when the world around is not as secure anyway.
- richbell 3y ago> Java libraries are distributed as binary bytecode blobs. I don't think it's fair to describe JARs this way. While it may be technically true, a JAR file is far less opaque than an actual binary executable.
- connicpu 3y agoIn the sense that it's easier to decompile sure, but plenty of non-OSS java libraries run an obfuscator on their internals and in that case it's only marginally less opaque than machine code
- pgwhalen 3y ago> that's the way things will be for the long time. There are some changes coming where application developers will have to explicitly acknowledge that libraries they're using are using native code: https://openjdk.org/jeps/8307341 https://openjdk.org/jeps/8307341 (the new, soon-to-be-stable FFM API already has this behavior). It doesn't change the distribution mechanism of native code, but it's some sort of step towards better security.