Agreguesi i feed

A Linux security hook should be able to check a task without invalidating the identity data that surrounding kernel code is still using. AppArmor broke that expectation when a policy update made the task's current label stale: code inside widely used hooks could replace the task's credentials before the caller had finished with them.

Linus Torvalds merged a Linux NFS client update on Aug 26, 2026, that includes a fix for rpc_pipefs files left attached to an RPC client after the client object was freed. Opening one of those leftover files could trigger a kernel use-after-free.

The Linux IPMI maintainer accepted a patch on Aug 26, 2026 that restores an RCU grace period before command-receiver objects are freed. The one-line change addresses a use-after-free condition in the kernel's Intelligent Platform Management Interface message handler.

A Linux uevent can carry bytes from freed kernel memory when one object survives longer than the allocation behind its name. A new Synaptics RMI4 patch demonstrates that path during device removal and a probe failure.

If your agentic workload involves the agent being able to run arbitrary code (like bash or equivalent), then you should not use a “LLM as part of your app” framework like LangChain, BeeAI, OGX etc. Instead, run OpenCode, goose, or another general coding agent inside a sandbox such as OpenShell.

Sandboxing limits what the agent can access directly. For privileged effects, it is best augmented with a pattern like safe outputs: the agent emits a structured, unprivileged request that separately trusted code validates and applies.

A compact decision tree Can it run bash or arbitrary code? ├─ Yes → Run a generic agent in a sandbox └─ No → Are you *really* sure *all* of your tool calls (MCP or builtin) don't accidentally expose "execute arbitrary code"? ├─ Yes → OK, maybe LangChain or equivalent makes sense └─ No → Goto start

I also think the builtin sandboxing in most agent tools (like Claude Code and Gemini CLI) is a bad idea, and it’s better to just ensure the entire thing is sandboxed.

Related to all of this, a key thing anyone making an “agent” needs to ask is “how is this different from just writing an agent skill”. From my previous post you’ll know that I think GitHub Agentic Workflows is a good reference baseline for applying agentic AI (background/task oriented) safely and effectively. And there an “agent” is almost exactly just an agent skill, but with a bit of YAML defining its integration with the outer system.

Why should it be harder than that? I just don’t see it making sense for custom agents written in frameworks like LangChain to proliferate in most use cases. Sure you can use LLMs to generate it, but it’s even more secure and understandable to not have that code at all.

Even for the use case of an interactive chat bot, do you really need a custom app versus just MCP tools for an already generic frontend? I doubt it.

I don’t think it makes sense for most organizations to have proliferation of custom bespoke agents like these LangChain-style frameworks encourage. Skills and sandboxed generic agents are just easier to understand and work with.

Hello! I'm Angelo Verlain, a Software Engineering student, and I've been working for the last 3 months easing the debugging process of GJS apps by adding Debug Adapter Protocol (DAP) support to GJS as part of Google Summer of Code (GSoC 2026).

A debugger is software for executing a computer program in an environment that allows for programming-level inspection and control. A debugger is often used to debug, but can be used for other goals including testing. Common features of a debugger include stepping through code line-by-line, breaking into the program's flow of control, managing breakpoints, and reporting and modifying memory. ¹

What is GJS?

GJS or GNOME JavaScript is a JavaScript interpreter that allows developers to write code that can leverage GLib/GObject and various other libraries that work with GObject Introspection like GTK, Libsoup, etc...

In practice, GJS allows you to write GNOME/GTK Applications and GNOME Components in JavaScript. The GNOME Shell & Extensions, GNOME Weather, GNOME Audio Player, GNOME Maps, Workbench are all examples of projects powered by GJS.

What is DAP?

The Debug Adapter Protocol is a a specification that describes how messages are passed between a debugger client (for example, your IDE) and server (such as the Node.js or any other language runtime). It specifies and communicates pausing & continuing execution, setting breakpoints, stepping through the code, viewing stack traces, and more. It works by defining a standard way for your development tool (e.g. GNOME Builder, VS Code, Zed, etc...) to connect to a debugger.

Today, you can already debug applications and libraries written for/with Android, Node.js, Deno, C, C++, Rust, Python and more. This project aims to make GJS applications debuggable in your favourite editor or debugger by implementing a DAP adapter for GJS.

Adding DAP to GJS

GJS already supports debugging programs by use of the --debugger flag, which spins up a GDB-style CLI interface where you invoke it by running gjs --debugger [file-name].js and writing commands like breakpoint [line], step, frame to set breakpoints, step through the code and print the stack frame respectively.

It works well, but it's different from the GUI debugging that’s more popular these days.

Here's an example of GJS debugging the following code saved as test2.js

function print(i) { console.log(i); } for (let i = 0; i < 10; i++) { print(i); }

If GJS had support for DAP, you wouldn’t be limited to just using the text mode debugger, but could debug applications using your favourite editor (Zed, VS Code, etc…)

The workflow would be easier too: Press F5 to debug (standard hotkey), specify the path to your entrypoint, and then run the program. To set a breakpoint, simply type the debugger keyword or click in the gutter/margin of your editor (even after your program has started execution!).

When the program reaches that breakpoint, you will have a nice stack trace showing where the program stopped, and give you options to inspect the current variables in the different scopes, continue execution, or step next, in our out of frames.

Here's an example of debugging the same script using VS Code's Node.js adapter (the experience we want):

Note that you can more clearly see the variables, call stack and breakpoints in the debugger.

Scope

My work is focused on launching & debugging GJS apps.

The scope is also limited to launching & debugging GJS applications or running scripts in the GJS interpreter and debugging them. Attaching to already running applications is not in scope.

Concretely this also means that debugging components like the GNOME Shell is not in scope.

Furthermore, I have only written an extension for Zed since it’s the editor I use, but other editor extensions like VS Code, Builder, and Emacs could be implemented as a follow-up task and will be relatively easy since GJS itself implements the DAP specification and we just need to bridge the two. If you want support for a specific editor or debugger, please let me know :).

Progress

I've made significant progress on the project.

The project period is coming to a close and I’ve made significant progress. Currently, the following is implement:

• A work-in-progress GJS DAP Extension is implemented, which allows you to debug GJS applications inside the Zed Editor. It's not yet published to the Zed Extension Store though
• You are able to launch a GJS program or run a file and break on entry
• Automatically pausing on debugger statements
• Ability to add breakpoints by clicking in the gutter/margin of the code editor (even while the app is running!)
• When execution pauses, you are able to resume execution to the next statement, or step in/out of functions/methods/scopes.
• When execution pauses, you can see all the stack frames
• When execution is paused, you can also inspect the different scopes and the variables defined in all of the scopes

My next steps will focus on the following:

• Implement a VS Code Extension so you can also debug GJS applications in VS Code in addition to Zed
• Allow configuring breaking on Caught and Uncaught exceptions

Figure: Debugging a program with a visual debugger (Zed), showing breakpoints (red circle in the gutter), current line highlighted and variables

I’m looking forward to sharing my progress when we get to the end of the program! Expect another blog post in the next couple of weeks.

A Linux system can be hardened, monitored, and carefully administered while still receiving untrusted code through a package, dependency, container image, build runner, or deployment pipeline. The risk often begins before the software reaches the host.

An alert suggests that a Linux server may be compromised. The first impulse is often to reboot it, stop a process, delete a suspicious file, or patch the visible weakness. During Linux incident response, those actions can erase the evidence needed to determine what happened and whether the attacker reached anything else.

A Linux dm-integrity patch posted on Aug 24, 2026 targets a writeback race that can leave stored data with the wrong integrity tag after a crash. Chen Cheng proposed requiring stable writes when dm-integrity generates internal hashes in direct, bitmap, or inline mode.

Linux RDS can accept a path count that is larger than the storage allocated for an InfiniBand connection. A peer on the same Remote Direct Memory Access, or RDMA, fabric can then make receive-side kernel code walk beyond that allocation, producing an out-of-bounds write and a system crash.

Linux hardening is not the act of enabling every restrictive setting a distribution provides. It is the work of reducing unnecessary exposure, limiting what users and processes can do, separating workloads, and confirming that those controls remain effective as the system changes.