By submitting this form, you agree to our 

Building trust from source to ship

Choosing a secure container base image has historically been a game of compromise between costs, tooling, and operational overhead. You either pay for premium images, struggle with the “tooling gap” of minimalist distroless builds, or drown your team in the manual labor of constant patching.

Docker is changing this equation by making its 

Docker Hardened Images (DHI) catalog–over 1,000 minimal, high-integrity images–freely available

. But while the images are free, operationalizing them at scale across a massive engineering org is not.

That is where the combination of Docker and Cloudsmith becomes a cheat code for developers and security teams working at enterprise scale.

The developer advantage: Better ingredients, less prep

For a developer, a Docker Hardened Image isn't just more secure. It’s an evolutionary step forward that better protects against software supply chain threats and risks. DHIs arrive pre-patched and stripped of the bloatware found in typical images. They offer developers:

: These images are smaller, meaning they move across the network fast and start up in seconds.

: Docker handles the continuous patching of DHIs, monitoring upstream sources so you don’t have to.

 Level 3 provenance. You get traceable security data from the very first layer of your build.

The Cloudsmith difference: One endpoint, zero sprawl

Most other artifact managers force you into repository sprawl. If you want to add a new source like DHIs, you’re stuck creating a new remote repository, a new local cache, and a new virtual repository to tie them together. Then, you have to hunt down every CI pipeline and developer config to update the endpoints.

This isn't just an operational challenge, it’s a security bottleneck. When the path to better security requires a manual overhaul of your internal infrastructure, adoption stalls. This friction often forces organizations to stick with "good enough" images, leaving them unnecessarily exposed to vulnerabilities that DHIs are designed to eliminate.

We architected Cloudsmith differently. Our repositories are natively multi-format and upstream-aware. Adding Docker Hardened Images isn't a migration project. It’s a natural extension of your current setup.

 DHI as an authenticated upstream source in Cloudsmith. Developers and build agents continue pulling from the same Cloudsmith URL they already use.

: Keep your existing Docker Hub upstream in place. Cloudsmith handles the authentication, caching, and routing behind the scenes.

: Continue using the same Cloudsmith repository URL you already have. You can keep your existing Docker Hub upstream active alongside DHI. Cloudsmith acts as the single, intelligent integration point between your stack and the outside world.

Cloudsmith lets you treat DHIs as just another upstream source rather than a special case project. From a developer and CI perspective, nothing changes. That means you eliminate the friction that usually kills security initiatives because behind the scenes, Cloudsmith handles the authentication, caching, and routing automatically. You get to enforce a hardened organizational standard without touching a single developer’s 

Turning hardened images into an organizational standard

When DHIs flow through Cloudsmith, they become part of your controlled software supply chain. By supplying developers with base images via Cloudsmith, in addition to recommending better security, you provide a default environment that includes:

: Every team builds from the same approved, cached base images.

: You know exactly which images developers use and where they originated.

: Security teams can apply policies that govern image usage without breaking the build.

Solving the coordination tax and rate-limit surprises

While DHIs are free of charge, they require authenticated access. For a single developer, this is a non-issue. At an organizational level, managing credentials for hundreds of build agents and thousands of CI pipelines is a nightmare.

The secret handshake: Centralized authentication

Cloudsmith becomes the single integration point between your organization and Docker Hub.

: You store your organization’s Docker Hub credentials in Cloudsmith once. Your developers and build agents then authenticate directly to Cloudsmith.

: You avoid pushing configuration changes and tokens out to every individual client.

Docker Hub enforces strict pull rate limits. In a large CI/CD environment, you can hit these limits in minutes, breaking your builds.

: Cloudsmith automatically caches requested DHIs.

: Once an image is in your private repo, Cloudsmith serves future pulls directly from our global edge network. This should reduce or eliminate rate limiting issues.

DHI and Cloudsmith both offer significant intrinsic benefits, and even more power lies in the ease of their integration. Because Cloudsmith handles DHIs like any other upstream source, developers can configure their pipelines once and deploy at scale without disrupting their existing workflows. In short, Docker makes DHIs secure; Cloudsmith makes them easier to consume across an enterprise.

The result is a 'security win' by default that serves the entire engineering organization. By adopting these stronger defaults with zero added operational drag, teams can finally align their velocity with their security standards. Developers get to work with faster, higher-quality tools, while the organization gains a hardened, verifiable security posture. Together, we’re building a more trustworthy ecosystem where security isn't an external hurdle–it’s a built-in feature of the craft.

Achieving a secure supply chain shouldn't require a total re-architecture of your artifact repositories. See how Cloudsmith’s upstream-aware repositories can consolidate your Docker Hub, DHI, and internal images into a single, high-performance endpoint. 

Colin Moynes

Senior Support Engineer

Secure containers by default with Cloudsmith and Docker Hardened Images

 is fast approaching, and it’s a loaded update! Removing enhancements with the status of “

” we have 59 Enhancements in all listed within the 

Kubernetes 1.35 brings a whole bunch of useful enhancements, including 30 changes tracked as ‘

’ in this Kubernetes release. From these, just 

 are graduating to stable, such as the addition of Kubelet option to specify the maximum age an image that will be kept around before it’s garbage collected. This is beneficial to cluster admins because unused images can now be garbage collected in a timely manner, no longer occupying disk space forever.

 features are also listed in the enhancements tracker, one of which introduces some new authorisation rules to restrict impersonation on specified resources with specified actions. We also see support for in-place resizing of pod-level resources, support for restarting all containers within the pod when a container exits as a 

This is the most detailed Cloudsmith release notes to date, and our team is really excited about this release and everything that comes with it! Let’s jump into all of the major features, changes, and deprecations in Kubernetes 1.35.

Here are a few of the changes that Cloudsmith employees are most excited about in this release:

I’m excited to see structured auth config graduate to stable in Kubernetes 1.35 because it marks a major step forward in making cluster authentication both more flexible and maintainable. The current flag-based OIDC setup has long been a pain point, as it’s hard to extend, oftentimes difficult to manage, and is limited in how it maps identity claims. Moving to a versioned, structured configuration not only modernises this critical component but also unlocks long-requested capabilities like supporting multiple client IDs, richer claim mappings, and dynamic reloading of authentication settings without restarting the API server. This enhancement brings much-needed clarity and power to authentication workflows, simplifies life for operators, and sets a strong foundation for future innovations in identity and access control in Kubernetes.

Nigel Douglas - Head of Developer Relations


The feature I’m happy to see graduating to beta status in Kubernetes 1.35 is the binding conditions within Dynamic Resource Allocation. This looks to be a significant step towards making Kubernetes the definitive platform for demanding AI/ML workloads. This improvement provides the critical intelligence for schedulers to handle complex, disaggregated hardware like fabric-attached GPUs robustly, preventing failed deployments and enabling more efficient, dynamic resource allocation. The beta graduation signals that this powerful feature is almost stable and ready for broader adoption within the ecosystem, hopefully paving the way for more resilient, dedicated AI infra in Kubernetes.

#3673 Kubelet limit of Parallel Image Pulls

We are all delighted to see this new Stable update address the existing, ineffective method Kubernetes currently uses to limit container image pulls on a node. The existing QPS (Queries Per Second) and Burst limits are really confusing as they only control the rate of requests to the container runtime, not the number of concurrent pulls. This can sadly lead to an unlimited number of simultaneous downloads, potentially overwhelming a node's disk I/O and network bandwidth. This new change adds a more intuitive kubelet config field called 

. This setting establishes a clear, node-level limit on how many images can be pulled at the same time. Any pull request that exceeds this limit will be blocked until an ongoing pull completes - improving how cluster admins manage their resource consumption.

maxUnavailable for StatefulSets rolling updates

 strategies. Previously, when updating a StatefulSet, pods were terminated and recreated strictly one at a time, which could be very slow. This enhancement allows users to specify the maximum number of pods that can be unavailable during an update, either as an absolute number or a percentage. This means multiple pods can be updated simultaneously, dramatically speeding up the rollout process.


The primary motivation is to make StatefulSet updates faster and more flexible, bringing them closer to the functionality of Deployments. This is particularly useful for stateful applications that can tolerate multiple replicas being down at once (like a cluster with many followers) or for applications with long startup times (like cache loading). By allowing parallel updates, this feature helps users who prefer the stable network identities of StatefulSets but need the faster rollout capabilities typically associated with Deployments. The default value for 

, ensuring backward compatibility and maintaining the safe, one-by-one update behaviour for applications that require it.


 field to the Kubernetes Job specification. Its primary purpose is to delegate the management and status synchronisation of a Job to an external controller, effectively telling the default Kubernetes Job controller to ignore it. This is a lightweight, per-Job mechanism designed to prevent conflicts when another system needs to take control. The main motivation for this is to support 

, a multi-cluster job dispatcher that runs a "mirror" copy of a Job on a separate worker cluster while managing the original Job on a central management cluster. The 

 field allows the MultiKueue controller to sync the status from the worker cluster back to the management cluster without the default controller interfering.

, meaning it can only be set when the Job is created and cannot be changed later. This choice was made to avoid complex issues and potential errors, such as "leaking" pods, which could occur if control of a running Job were switched between different controllers. This approach provides clear ownership throughout the Job's lifecycle and follows a pattern already used by other Kubernetes resources, making it a stable and predictable solution for developers of custom batch processing systems.

Mutable Container Resources when Job is suspended


This Kubernetes enhancement proposes allowing users to modify the container resource requirements (like CPU and memory) on a job's template while that job is suspended. Currently, this is not possible. The primary motivation is to give users, particularly those using queuing systems like 

, the flexibility to adjust a job's resource needs before it resumes, which can improve scheduling efficiency. While a proof-of-concept exists for standard resources, the implementation faces a significant hurdle with the newer Dynamic Resource Allocation (

) framework, as its resource templates are immutable, and a clear path forward for DRA support is still under discussion.


Initially, the team considered releasing this feature directly as a 'beta' version, enabled by default, viewing the risk as low. However, concerns arose about completing the necessary comprehensive testing within a short development cycle. Specifically, addressing potential race conditions, such as one user updating resources while another unsuspends the job was deemed critical but complex to test reliably. Given these challenges and the potential for unforeseen consequences when loosening API validation rules, the consensus shifted. It looks like the feature will now be introduced in an 'alpha' stage to allow for more iteration and the development of robust test coverage, ensuring the feature is stable and safe before being promoted.

 aims to address the version skew issues within Kubernetes clusters during upgrades or downgrades by ensuring that clients always interact with a complete view of the cluster's capabilities. To achieve this, the proposal introduces a proxying mechanism where an API server, upon receiving a request for a built-in resource it cannot serve locally, identifies and forwards the request to a peer server that can. This prevents misleading "404 Not Found" errors. Simultaneously, the feature implements 

, which merges resource information from all peer API servers into a unified discovery document. This ensures that clients using the aggregated discovery endpoint receive a comprehensive list of all available resources across the cluster, regardless of which individual server they contact.

This mechanism is critical for maintaining system stability and data integrity during version transitions. Without it, controllers like the 

 might act on incomplete information, potentially leading to the incorrect deletion of objects or operational deadlocks. By ensuring that requests yield either the correct resource or a safe "503 Service Unavailable" (rather than a "404"), the system protects against destructive actions while allowing valid operations to proceed. It is important to note that this peer-aggregation logic applies only to the aggregated discovery endpoint (

) and excludes the legacy core endpoint (

 group's top-level types are considered frozen and will not require dynamic merging.

: AuthorizePodWebsocketUpgradeCreatePermission 

In Kubernetes v1.35, a new Beta security feature for synthetic RBAC CREATE Authorisation checks has been introduced as part of this Stable graduation. This feature enhances security by forcing an additional authorisation check when a user attempts to establish a persistent, two-way connection to a pod using commands like 

. Previously, these actions were authorised with a 

 permission; now, this update adds a check for a 

 permission on the corresponding subresource. This ensures that only users with appropriate creation rights can initiate these powerful, interactive sessions with pods.

This security enhancement is part of a much larger and more significant update: the migration from the outdated 

 for streaming communication. The SPDY protocol has been deprecated since 2015 and is no longer supported by many modern proxies and load balancers, causing connectivity issues. By transitioning to WebSockets, a current industry standard, Kubernetes ensures better compatibility and reliability for essential developer commands. In essence, this update modernises a critical communication pathway in Kubernetes while simultaneously tightening the security around it.


Kubernetes occasionally needs to rewrite stored resource data, a process essential for maintenance activities like upgrading a resource's schema version (example: from 

) or re-encrypting data at rest after an encryption key change. The traditional method for this, using manual 

 commands, is inefficient and impractical, especially for large resources like Secrets, and does not scale as the number of resources grows. This manual process is cumbersome and requires significant automation to be performed reliably across a cluster.


To address these challenges, this Kubernetes Enhancement Proposal (

 for short) suggests integrating the logic from the existing Storage Version Migrator (

) tool directly into the Kubernetes Controller Manager (

). This would create a native, in-tree controller and API dedicated to storage migration. The primary goal is to provide administrators with a simple, reliable way to trigger these migrations without manual commands. This change would enable infrastructure providers to automate migrations in response to environmental events, such as a key rotation in a Key Management Service (

), and would streamline the process for users who currently rely on the external SVM tool. While the migration process will be simplified, the responsibility to initiate it will remain with the user.

 Remove gogo protobuf dependency for Kubernetes API types


In early October, the Kubernetes development team initiated a significant change by starting the process of removing a dependency called 

. This component is a toolchain that Kubernetes has been using to automatically generate the Go code necessary for handling its REST API data structures. The core of this feature is to replace an unmaintained and outdated part of the Kubernetes system to enhance security, stability, and future maintainability.

The primary motivation for this change is that gogo protobuf has not been maintained since 2021, which introduces several risks. Relying on an unmaintained dependency means that any newly discovered security vulnerabilities or bugs cannot be easily fixed. Furthermore, every developer or business that uses Kubernetes' core libraries is forced to inherit this unmaintained dependency, creating a wider security concern. This change also aims to prevent accidental misuse of the API types with standard 

 libraries, which has caused system crashes in other projects. By removing 

, the generated code will be streamlined to include only what is essential for Kubernetes client and server operations, making the system more robust and secure.


This now merged pull request formalises the behaviour of the 

 field. Currently, clients are meant to treat 

 as an opaque string, only allowing for equality checks. However, the internal Kubernetes API server implements it as a monotonically increasing integer. This enhancement officially defines that 

should be a comparable, monotonically increasing integer

, allowing clients to reliably determine the order of resource updates, which is a growing need. The proposal includes adding a utility function for clients to safely compare two resource versions and adding conformance tests to ensure API servers adhere to this standard.


A key debate in the comments centred on how to handle non-compliant extension API servers. One alternative suggested was an opt-in mechanism where APIs could advertise their 

 comparability through the discovery API. However, the consensus was that this added unnecessary complexity. Instead, the accepted approach pushes API server authors to either use a comparable integer (the preferred state) or a clearly non-integer string. The new client-side utility function would handle the latter case by returning an error, preventing misinterpretation. The enhancement proposal was ultimately approved and merged, strengthening the API contract for all clients.

 Separate kubectl user preferences from cluster configs

, designed to separate user-specific preferences from cluster credentials and server configurations, which are typically managed in 

 files. The primary motivation is to allow users to define consistent client-side behaviours, such as command aliases, default flags, and security policies, that would apply across all clusters without altering the 

 files used in different environments, like CI/CD pipelines. This separation ensures that personal settings, like enabling interactive delete confirmations or coloured output, don't break automated scripts, and preferences remain consistent even when switching between multiple kubeconfig files.

, is a versioned YAML file that enables users to create custom command aliases and set default options for standard 

 commands. For example, a user could create a short alias for a complex 

 command or automatically enable the server-side applies and the interactive deletes. The proposal also includes a new 

 command to help users safely view and manage these settings without manually editing the file. This feature is opt-in and aims to enhance the user experience by making 


Having gone from New State status to Alpha in Kubernetes 1.34, 

 is now graduating to Beta status. If you missed this feature announcement in Kubernetes 1.34, KYAML is a new, opinionated output format for 

 designed to be a stricter, less error-prone subset of standard YAML. It was created to address common frustrations with conventional YAML, such as its sensitivity to whitespace which complicates templating in tools like Helm, and its ambiguous data typing where unquoted strings like "NO" or "On" can be incorrectly interpreted as booleans (a problem known as the "

"). While JSON is an alternative, it lacks crucial features like comments. KYAML aims to provide the best of both worlds by defining a "flow style" dialect that is 100% compatible with existing YAML parsers but enforces syntactical choices that increase clarity and reduce common user errors, making configuration files easier to write, read, and manage programmatically.


The core principle of KYAML is to use syntax that removes ambiguity and reliance on indentation. It achieves this by always using curly brackets (

) for maps and structs, square brackets (

) for lists, and double quotes for all string values. This approach makes the format insensitive to whitespace, similar to JSON. However, unlike JSON, KYAML is more human-friendly, allowing for comments, trailing commas in lists and maps, and unquoted keys where safe. The proposal includes introducing a new 

 command and updating all official Kubernetes documentation and examples to promote this safer, more consistent format throughout the ecosystem.

For example, here is a KYAML output for a Kubernetes 

 Include kubectl command metadata in HTTP request headers

This new enhancement in K8s v.1.35 suggests adding contextual HTTP headers to requests sent from 

. The goal is to give cluster administrators better visibility into how users are interacting with the cluster for debugging and telemetry purposes. Currently, while the API server sees requests from 

, it doesn't know the specific command that initiated them (like 

). This proposal introduces new headers, primarily 

 header will contain the full command path (for example, 

 will provide a unique ID to group all API requests that originate from a single kubectl command invocation.


This added information is intended purely for out-of-band analysis, such as identifying the use of deprecated commands, understanding usage patterns to inform tooling decisions, or simplifying debugging. It is explicitly stated that the API server should not make any decisions based on these headers. Flag values and command arguments will not be included to protect sensitive information.

 command would generate API requests that include the proposed new headers, which could then be seen in the API server's audit logs.

Nigel Douglas

Head of Developer Relations

Kubernetes 1.35 – What you need to know

 is right around the corner, and there are 11 clear new Python Enhancement Proposals (PEPs) added to the Python project! There are several over significant changes listed within the 

Python 3.14 brings a whole bunch of useful build improvements, including discontinuation of PGP signatures in 

. Python versions 3.14 and onwards will no longer provide PGP signatures for release artifacts. Instead, Sigstore is recommended for verifiers. Similarly, free-threaded mode (

), which was introduced in the previous version, 3.13, has undergone major enhancements. The implementations outlined in this enhancement are now complete, incorporating updates to the C API, and the interpreter’s earlier temporary fixes have been replaced with long-term solutions.

The Cloudsmith team is really excited about this release and everything that comes with it! Note that some of the statuses may change between the time of this blog being posted and the final release date. Knowing that, let’s jump into all of the new features and improvements in Python 3.14.

PEP 761: Discontinuation of PGP signatures

“From my perspective at Cloudsmith, the move away from PGP signatures in Python is a welcome change. PGP has long struggled with usability and the burden of managing long-lived private keys, and while it was the default for artifact signing, it never felt ideal. Sigstore offers a much more practical approach, using short-lived keys tied to human-readable identities, and it’s already gaining traction across ecosystems like PyPI, NPM, Homebrew, and GitHub. We’re also seeing projects we work with, like 

, embracing Sigstore, which reinforces that this shift is a real step forward for security and usability.”

PEP 734: Multiple interpreters in the stdlib

“This was an inevitable development, in my opinion. While the CPython runtime has supported running multiple interpreters, which are independent copies of Python within the same process, for well over 20 years at this point, the feature was still limited to the C-API and thus saw little adoption due to low awareness and the absence of a standard library module. With Python 3.14 introducing the new 

 module, this long-standing capability is finally becoming more accessible, marking a significant step toward mainstream usage. While current limitations remain, their impact will diminish as CPython evolves and the community contributes solutions via 

PEP 784: Adding Zstandard to the standard library

“Python 3.14’s addition of Zstandard (via 

) is an exciting upgrade because it brings one of the fastest, most efficient modern compression algorithms directly into the standard library, alongside a new unified 

, consistently outperforms older formats like 

 by offering both higher compression ratios and dramatically faster decompression speeds, which has made it the de facto standard across filesystems, packaging tools, and industry at large.

By including it natively, Python eliminates the confusion of multiple third-party bindings, enables direct support in core modules like 

, and opens the door for faster, smaller Python wheels and other packaging improvements. The reserved 

 namespace not only avoids naming conflicts with PyPI packages but also creates a clean, future-proof home for compression libraries, much like 

 does for hashing. This change reflects Python’s “batteries included” philosophy while giving developers a state-of-the-art compression tool that is both practical today and well-positioned for long-term usage.”

Free-threaded Python is now officially supported

 this enhancement proposal, which actually sets requirements for advancing 

, which was the larger, ongoing effort to make Python’s 

) optional. PEP 703 outlines a three-phase plan:

First phase introduces an experimental GIL-free build in Python 3.13

Phase two makes this build officially supported - though still optional

While Phase 3 makes it the default. 
This new feature defines the expectations for the second phase, ensuring the free-threaded build is stable, usable, and performant enough for broader adoption.

The motivation behind this shift is to balance the benefits of free-threaded Python, which offers greater concurrency, reduced latency, and expanded threading capabilities against costs such as performance penalties, memory overhead, and ecosystem complexity. Current benchmarks show around a 10% slowdown and 15-20% more memory use compared to the traditional GIL build, both considered acceptable trade-offs for Phase 2.

The APIs introduced so far have proven stable, and further refinements are expected without breaking changes. With growing third-party support and clear criteria for performance, memory use, documentation, and API stability, Python 3.14 is targeted as the point where free-threaded Python becomes an officially supported build.

Standard Library Support for Isolated Python Interpreters

Python 3.14 sees the addition of a new standard library module, 

, to expose CPython’s long-standing support for multiple interpreters in a single process. Each interpreter is strictly isolated, with its own modules, classes, and variables, while sharing only certain immutable or low-level process state. Unlike threads, which share most of the same runtime state, interpreters provide stronger isolation, making them better suited for parallelism, especially now that 

The new module will provide a high-level interface for creating, inspecting, and executing code in interpreters, as well as managing communication through a built-in, cross-interpreter-safe 

. This brings powerful functionality, previously limited to the C API, into Python code. An additional 

concurrent.futures.InterpreterPoolExecutor

 will be provided to simplify concurrent workloads.

The interpreters module defines an Interpreter object with methods like 

 to initialise globals. Interpreters can safely exchange data using 

, which supports pickle-based transfers and special handling for buffer objects like 

. This queue acts as a synchronisation and communication mechanism, enabling patterns like worker coordination across interpreters. For example, the below snippet taken from the PEP documentation shows multiple interpreters sharing a 

 of large data, synchronised with a queue token:

Making Parentheses Optional in Except and Except Blocks

 blocks in Python, users can now catch multiple exception types, so long as the “

” operator clause is not used. Currently, parentheses are mandatory around multiple exception types, a requirement carried over from Python2.

Removing this requirement simplifies the syntax, improves readability, and makes it more consistent with other comma-separated constructs in Python, such as function arguments and tuple literals. Parentheses will still be required when using as to capture the exception instance to avoid ambiguity. The change is purely syntactic, fully backwards compatible, and does not alter exception handling semantics.

Deferred Evaluation Of Annotations Using Descriptors

Python annotations let developers attach type information and metadata to functions, classes, and modules. Traditionally, annotations were evaluated eagerly when the object was defined, which led to common problems with forward references and circular dependencies. 

 attempted to fix this by “stringizing” annotations (storing them as strings), solving the forward-reference issue but breaking runtime use cases where actual objects were expected instead of strings.

A new proposal introduces a third, more flexible approach: lazily evaluating annotations through a dedicated 

 method. At compile time, Python generates a helper function that constructs the annotation dictionary, then attaches it to the object as 

. Accessing these annotations triggers this function, evaluates the annotations only when needed, and caches the results. This design eliminates circular-reference issues, preserves runtime usability, and allows for new introspection capabilities. Furthermore, 

 gain a new format parameter, letting users choose between evaluated values, forward-reference proxies, or source-code strings for annotations.

Here’s a simplified illustration of how this lazy evaluation model works:

With this change, annotations retain their runtime meaning while still avoiding forward-reference pitfalls, which supersedes the enhancement #563 string-based approach mentioned earlier, as well as offering a unified solution for both static and runtime use cases.

Safe external debugger interface for CPython

This introduction of a zero-overhead debugging interface for CPython should allow debuggers and profilers to safely attach to running Python processes. By providing well-defined safe execution points within the interpreter’s evaluation loop, external tools can request code execution without modifying normal execution or introducing runtime overhead.

This mechanism enables scenarios like attaching pdb to live processes by PID, similar to 

, allowing developers to inspect, evaluate, and step through running Python code interactively without stopping or restarting applications. Current approaches to live debugging in Python are risky because they rely on unsafe code injection, which can execute at arbitrary points in the interpreter, leading to crashes, memory corruption, or deadlocks. By integrating a small support structure into each thread state and extending the debug offsets table, this proposal ensures that debugging code is executed only when the interpreter is in a consistent and safe state.

The interface works by having debuggers write control information, such as the path to a Python script, into dedicated memory locations in the target process. The interpreter checks for pending debugger requests at existing safe points (via the 

), executing the provided code without interrupting critical operations like memory allocation or garbage collection.

 API simplifies remote execution for external tools, while environment variables and build flags allow redistributors and administrators to disable the feature if desired. Multi-threaded considerations are handled naturally: injected code runs under the normal GIL, ensuring thread safety, and can target individual threads or all threads as needed. This approach aligns Python with other major languages in live debugging capability while maintaining safety and zero runtime overhead during normal execution.

Deprecating PGP signatures for CPython artifacts

Again, this PEP isn’t merely a deprecation announcement. Instead, we see the introduction of an entirely new security model through Sigstore. Since 

, CPython artifacts have been signed with both PGP and Sigstore. PGP relies on long-lived private keys, which release managers must maintain and protect for many years, creating ongoing risks and burdens. In contrast, Sigstore uses short-lived keys tied to human-readable identities via OpenID Connect, greatly simplifying the signing process while providing stronger ergonomics. Sigstore is already gaining wide adoption across ecosystems like PyPI, NPM, Homebrew, and GitHub.

This new feature will not only deprecate, but will eventually discontinue the PGP signatures for CPython altogether, transitioning fully to Sigstore. Current stable releases (3.11 through 3.13) will continue offering PGP signatures until end-of-life, but new release managers (starting with Python 3.14) will not be required to generate them. Maintaining dual systems has slowed adoption of newer methods, creating a “

” that discourages verifiers from moving forward.

By dropping PGP, CPython can encourage downstream ecosystems to fully adopt Sigstore, while still providing flexibility for extraordinary delays if needed. Though this change shifts reliance to Sigstore’s centralised infrastructure, it aligns with the security practices already expected of release managers and leverages services better suited for long-term key management. Documentation will guide integrators, such as Linux distros and package managers, on verifying artifacts with Sigstore.

Disallow return/break/continue that exit a finally block

Python 3.14 – What you need to know 

 launched with the goal of giving developers a way to verify the integrity and publisher of container images. It was built on The Update Framework (

Fast forward to 2025: Notary is no longer actively maintained, the industry has evolved, and 

Using GitHub Actions to push packages to Cloudsmith

More articles

Secure containers by default with Cloudsmith and Docker Hardened Images

Kubernetes 1.35 – What you need to know

Python 3.14 – What you need to know

Migrating from Docker Content Trust to Sigstore

Kubernetes 1.34 – What you need to know

Adding AI to applications using the Model Context Protocol