kasobol-msft

Introduction

Project Reactor is working on a new major version with tentative plan to baseline on JDK17 (following Spring's and Netty's decisions) as well as evolve APIs in a breaking change manner (since new baseline asks for new major revision anyway). This document is attempting to assess impact on Azure SDK for Java as well as propose couple of ways SDK could be solving this (and upcoming) migration.

Reactor usage in Azure SDK for Java

Azure SDK for Java uses Reactor to

1. Implement internals of asynchronous clients. Reactor helps building complex reactive streams that would otherwise require equivalent in-house framework (which is [not a trivial effort](https://githu

shipilev

Log4J, JNDI, LDAP: JDK Changes Archeology

DISCLAIMER #1: THIS GIST IS INFORMATIONAL ONLY AND NOT A COMPLETE SECURITY GUIDANCE. Use this data with care, and please recheck the commits if you want to cite them as the source.

DISCLAIMER #2: JDK MITIGATIONS ARE NOT THE WHOLE STORY. THE REAL FIX IS IN LOG4J, UPGRADE TO AT LEAST 2.15.0 OR SET log4j2.formatMsgNoLookups=true. There might be more vectors than these mitigations cover. JDK mitigations shrink the attack surface, but they are not guaranteed to solve everything. I only checked this mitigates a few simple proof-of-concepts.

*TL;DR: Use JDK update releases that are less than 3 years old, and all known mitigations are there.

denismakogon

package com.panama.examples;

import java.lang.foreign.*;
import java.lang.invoke.MethodHandle;
import java.lang.invoke.MethodHandles;
import java.lang.invoke.MethodType;
import java.util.Arrays;

import static java.lang.foreign.ValueLayout.ADDRESS;
import static java.lang.foreign.ValueLayout.JAVA_BYTE;