Lunedì 19 ottobre, dalle 21:00, tornano le serate a tema del LuccaLUG, presso il Foro Boario di Lucca.
...
Docker and the CNCF will partner on an open spec to make agent permissions portable
Docker Sandbox Kits let you package an AI agent together with exactly what it is allowed to do, so anyone can pull the same agent with the same limits, review changes to those limits, and enforce them. Now, Docker has published the Docker Sandbox Kit Spec, the open specification behind Kits, under Apache 2.0 and is committing to contributing the spec to the Cloud Native Computing Foundation for neutral governance.
A Kit is an ordinary OCI container image that carries three things: the agent, the tools it uses, and a typed list of everything it asks to reach, such as network hosts, credentials, and volumes. That list lives inside the image, so pinning the image pins the agent and its requests together. A Kit builds, pushes, pulls, signs, and scans like any container image, because it is one.
“Standards are what let an ecosystem move fast without fragmenting, and few companies understand that better than Docker. By delivering Sandbox Kits as standard OCI images, Docker is giving the industry an open, repeatable way to package an AI agent, its tools, and its guardrails as one artifact. OCI is the foundation the cloud native ecosystem is built on, so a standard for agents that builds on OCI reaches the whole ecosystem at once. The CNCF welcomes this, and we’re excited to work with Docker and the community on making it broadly adopted.”
Chris Aniszczyk, CTO of the CNCF
An OCI image tells a runtime how to build and start a piece of software. It has no place to state which hosts that software may call, which credentials it may use, or which files it may keep between runs. Those decisions are made outside the image, at launch: in docker run flags, a Compose file, a CI job, an onboarding doc. For a web service, that was fine. The program was fixed, it needed a network and a port, and the flags rarely changed.
Agents are different. Claude Code and Codex decide at runtime what to do: install packages, call APIs, use credentials, change the environment they run in. So the access they need is granted piece by piece, by hand, usually to get a task unblocked. A few months in, nobody can answer a simple question: what is this agent allowed to do? The answer is spread across shell history, dashboards, and someone’s memory, and it cannot be handed to a teammate or compared with last week.
Every team answers that question on its own today, and every runtime vendor could ship its own format for the answer. That is the fragmentation OCI was created to prevent, and it is why Docker is now proposing one artifact, built on OCI, governed in the open by the CNCF community.
The Sandbox Kit Spec does not fork or replace any OCI specification. It uses the annotation extension point OCI already defines to carry the agent’s requests in the image manifest. Nothing in a registry, scanner, or signing tool needs to change.
Kits began as a feature of Docker Sandboxes, Docker’s product for running agents inside isolated microVMs, where a Kit defined one sandbox: the agent, its tools, and what it could reach. The Sandbox Kit Spec turns that definition into a standard OCI image and opens the format so any runtime can implement it. Docker Sandboxes is the first runtime that enforces it. It should not be the only one, and under Linux Foundation governance it will not be.
Two things follow for anyone running agents. The answer travels with the agent: a teammate can pull it, a reviewer can diff it, and a conforming runtime can enforce it. And when a new version asks for more, the change shows up as added lines someone can refuse.
Kits for tools from AWS, Box, Datadog, Dynatrace, JFrog, NanoClaw, OpenClaw, Palo Alto Networks, and Snyk are available now, covering cloud, observability, security, artifact management platforms and more.
That is what a shared format makes possible. A database vendor can publish a Kit that connects any agent to its service with the scope it recommends. An agent maker can publish its own Kit, so the request list comes from the people who built the agent. A platform team can publish one for the company, and every engineer starts from the same place.
Containers made software portable. Kits make authority portable: the set of things you deliberately hand an agent travels with the agent, in the same image, and means the same thing wherever a conforming runtime opens it. Docker looks forward to formally submitting Kits to the CNCF and working with the community to ensure Kits further the goal of secure, reliable agentic AI and AI governance.
If you make a tool that agents use, publish a Kit for it. If you run agents, start from one and share it with your team. The Docker Sandbox Kit Spec, its capability pages, and a worked tour of a real Kit are available at docker/sandbox-kit-spec. If there is a Kit you cannot express, or a rule a runtime cannot implement, open an issue.
The post Docker Commits to Bringing the Sandbox Kit Spec to the CNCF appeared first on Linux.com.
This is to announce parted-3.8, a stable release. This is the same as the
3.7.14 alpha release except that gnulib has been updated.
The full set of changes since parted 3.7:
Brian C. Lane (21):
maint: post-release administrivia
README-release: Fix typos in doxygen instructions
Cleanup zero as null pointer constant warnings
libparted: Catch FAT metadata triggered errors
resize: Make sure 32bit build cannot overflow frag_count
resize: Make sure hfsc_new_cachetable cannot overflow on 32bit
fdasd: Make sure data set name is positive
parted: Fix partition number allocation in do_print
maint: Update to latest gnulib and bootstrap script
maint: Update copyright statements to 2026
NEWS: Update news for next release
version 3.7.13
maint: post-release administrivia
hurd: Fix gnu_read problems with block size > 512b
NEWS: Update news for next release
maint: Update to latest gnulib
version 3.7.14
maint: post-release administrivia
maint: Update to latest gnulib
NEWS: Releasing stable version 3.8
version 3.8
Colin Watson (1):
maint: Distribute Doxyfile
Victor Couty (1):
Adding support for ExFAT filesystem
bug-parted@gnu.org (1):
bug #80795: [PATCH] build: mark functions with const attribute, per gcc warnings
Brian
[on behalf of the parted maintainers]
==================================================================
Here is the GNU parted home page:
https://gnu ... g/s/parted/
Here are the compressed sources and a GPG detached signature:
https://ftp.gnu.o ... parted-3.8.tar.xz
https://ftp.gnu.o ... ed-3.8.tar.xz.sig
Use a mirror for higher download bandwidth:
https://www.gnu.o ... rg/order/ftp.html
Here are the SHA256 and SHA3-256 checksums:
File: parted-3.8.tar.xz
SHA256 sum: a2b7811f47b0ddb1f7b1d0aa456f7c1270da70708ce231c2fe054c7199eafa63
SHA3-256 sum: dd794daa59755a9201d7cc493bcdf35903e231d48f93f7bdc79a780fcd8bf594
Verify the SHA256 checksum with either sha256sum, sha256, or
'shasum -a 256'.
Verify the SHA3-256 checksum with 'cksum -a sha3 -l 256 --base64'
from coreutils-9.8.
Use a .sig file to verify that the corresponding file (without the
.sig suffix) is intact. First, be sure to download both the .sig file
and the corresponding tarball. Then, run a command like this:
gpg --verify parted-3.8.tar.xz.sig parted-3.8.tar.xz
The signature should match the fingerprint of the following key:
pub ed25519/FF9868A2D488A5A9 2026-04-14 [SC]
Key fingerprint = 872F 3A8A 0B84 905A FFBC 8766 FF98 68A2 D488 A5A9
uid [ultimate] Brian C. Lane <bcl@redhat.com>
If that command fails because you don't have the required public key,
or that public key has expired, try the following commands to retrieve
or refresh it, and then rerun the 'gpg --verify' command.
gpg --locate-external-key bcl@redhat.com
gpg --recv-keys FF9868A2D488A5A9
wget -q -O- 'https://savannah. ... ed&download=1' | gpg --import -
As a last resort to find the key, you can try the official GNU
keyring:
wget -q https://ftp.gnu.o ... u/gnu-keyring.gpg
gpg --keyring gnu-keyring.gpg --verify parted-3.8.tar.xz.sig parted-3.8.tar.xz
This release is based on the parted git repository, available as
git clone https://https.git ... rg/git/parted.git
with commit 5f600791b40a48c51aeb6db0432e67a29e8e7951 tagged as v3.8.
For a summary of changes and contributors, see:
https://gitweb.gi ... a=shortlog;h=v3.8
or run this command from a git-cloned parted directory:
git shortlog v3.7.14..v3.8
This release was bootstrapped with the following tools:
Autoconf 2.72
Automake 1.18.1
Gettext 0.25.1
Gnulib 2026-09-23 0b416a8a26dbdaea4f413d4fb0c41ef8ea846e4d
Gperf 3.2.1
NEWS
Promoting alpha release to stable release 3.8
Accedi