Tootfinder

Opt-in global Mastodon full text search. Join the index!

@frankel@mastodon.top
2026-08-09 16:54:35

Guest author Peter Firmstone continues his brilliant series of #Security baked into the #JVM, with his third post: two Subjects, one call
This part covers the two kinds of identity a call carries, how SPIFFE manages process credentials without keystores, and how three identity layers coexist on a singl…

Security Baked Into the JVM: two Subjects, one call
The constraint system stops a bad call before it leaves the JVM. The Safe Codebase Audit Pipeline stops bad code before a client ever loads it. What remains is identity: who is calling, and can you verify it? Most frameworks answer with a token check at the door. A filter validates a bearer token, sets a thread-local variable, and hopes that nothing downstream forgets to look at it. DirtyChai answers differently.

@frankel@mastodon.top
2026-07-03 17:15:13

Forking the #JVM to Save #JINI
bytecode.news/posts/2026/06/fo

Forking the JVM to Save JINI
Java stripped out the SecurityManager and offered nothing in its place. Peter Firmstone's answer: fork Apache River and OpenJDK to bring back both JINI and JVM-level authorization. Laudable, even necessary - and a very hard sell, because it runs only on his JDK. It's like a post-mortem for JINI while it's still trying to breathe.

@frankel@mastodon.top
2026-06-06 17:00:10

Endive, a #JVM native #WebAssembly runtime
endive.run/

JVM native WebAssembly runtime | Endive
Endive is a JVM native WebAssembly runtime with zero native dependencies.

@frankel@mastodon.top
2026-06-02 09:02:04

A custom #Rust compiler backend that emits #Java Virtual Machine bytecode. Compile Rust code into a runnable .jar compatible with #JVM 8 .

GitHub - IntegralPilot/rustc_codegen_jvm: Toolchain to create JVM-ready Java bytecode from Rust MIR.
Toolchain to create JVM-ready Java bytecode from Rust MIR. - IntegralPilot/rustc_codegen_jvm

@frankel@mastodon.top
2026-06-28 16:27:49

This week, I'm happy to welcome a new guest blogger, Peter Firmstone from Down Under 🇦🇺.
He's written a whole series about #security baked into the #JVM. Today's post answers the question: why fork @…

Security Baked Into the JVM: why fork Apache River and OpenJDK?
The more distributed a system, the harder it is to secure. Code crosses JVM boundaries. Objects are serialized across trust boundaries. Third-party proxies run inside your process. The usual answer is a network firewall. It helps, but it operates at the wrong level. Java 17 deprecated the SecurityManager, Java 24 put the final nail in its coffin. Most developers didn’t notice.

@frankel@mastodon.top
2026-07-19 16:55:05

Guest author Peter Firmstone continues to explore and analyze the theme of #Security Baked Into the #JVM.
Today's focus in on the Safe Codebase #Audit

Security Baked Into the JVM: the Safe Codebase Audit Pipeline
In Part 1, the minimal deployment showed constraints traveling with the proxy: authentication, encryption, hardened deserialization, all declared in configuration and enforced at the call boundary. The proxy is a JAR. That JAR was downloaded and unmarshalled before any constraint ran. That step is the earlier problem. Distributed Java systems that load remote code are vulnerable to supply chain compromise: an attacker can replace a legitimate JAR with one containing malicious bytecode.