560 blogs tracked4,950 posts indexed

#jvm

8 posts · 4 companies · newest first

1

Security Baked Into the JVM: no single party controls the outcome (opens on the source site)

A URL is a name, and names get reused. Replace the bytes behind https://repo.example.org/order-processor.jar and every permission granted to that URL still applies, now to code nobody audited. So far in this series, Part 1 declared constraints on a remote call, Part 2 vetted code before a client loaded it, Part 3 established who is calling, and Part 4 carried that chain of identities across the wire.

javajvmexcerpt only · body stays at the source
From the web
2

Leave the Class Path in the Rearview Mirror (opens on the source site)

Introducing composable, module system native and agent friendly command line tools for modern Java developmentBy Danny Thomas, JVM Ecosystem TeamRecent work on the Java language to pave the on-ramp has made it easier than ever to start a Java program and evolve it using the full language and platform. At the end of that on-ramp lies Java’s mature build and dependency management ecosystem, capable of carrying software to enormous scale and complexity.That ecosystem reached its maturity by developing strong models for projects, dependencies, and builds. When the Java Module System arrived,…

software-engineeringjvmexcerpt only · body stays at the source 11 comment on HN (opens the discussion)
From the web
3

Security Baked Into the JVM: sixteen Subjects on the wire (opens on the source site)

Alice calls the order service. The order service calls the ledger on her behalf. At the second hop, the ledger has to decide whose authority the debit is being made under. Most stacks answer badly. Forward Alice’s bearer token verbatim, and the ledger cannot tell her from the service that relayed it. Drop the token and the ledger sees a machine, with no record that a human started the chain. Neither option lets the ledger authorize the combination.

javajvmexcerpt only · body stays at the source
From the web
4

We Gave Our Service More CPU — and It Took Down Production (opens on the source site)

Every engineer has a story about the “harmless” change that wasn’t. This is mine.Ours didn’t start with a bad deploy. No risky feature flag, no sketchy migration, no Friday-evening hotfix. It started with a change every ops playbook calls safe:We gave a struggling service more CPU.We went from 1.5 cores to 2.5 cores. That’s it. And within minutes, our lead-creation API — the thing that turns a visitor tapping “Contact” into an actual business lead — stopped creating leads. Entirely across web and app.The twist that cost us hours: the more CPU we threw at it, the worse it got. This is the…

kubernetesproduction-outageexcerpt only · body stays at the source
From the web
5

Security Baked Into the JVM: two Subjects, one call (opens on the source site)

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.

javajvmexcerpt only · body stays at the source
From the web
6

Security Baked Into the JVM: the Safe Codebase Audit Pipeline (opens on the source site)

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.

javajvmexcerpt only · body stays at the source
From the web
7

Security Baked Into the JVM: why fork Apache River and OpenJDK? (opens on the source site)

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.

javajvmexcerpt only · body stays at the source
From the web
8 shown

Privacy choices

Reading never requires analytics. These choices last 90 days on this browser.

Essential sign-in and security storage always stays on. Read the privacy notice.