Thanks to visit codestin.com
Credit goes to Github.com

Skip to content

Tags: canyonroad/agentsh

Tags

v0.8.10

Toggle v0.8.10's commit message
v0.8.10: Alpine integration test improvements

v0.8.9

Toggle v0.8.9's commit message
v0.8.9: Add env_inject for environment variable injection

v0.8.8

Toggle v0.8.8's commit message
v0.8.8: Fix Alpine build upload

v0.8.7

Toggle v0.8.7's commit message
v0.8.7: Fix Alpine build missing file package

v0.8.6

Toggle v0.8.6's commit message
feat(release): add Alpine/musl build for Linux amd64

Add a separate build job that creates statically-linked binaries
using Alpine's musl libc and libseccomp-static. This enables agentsh
to run on Alpine Linux and other musl-based distributions.

The Alpine build:
- Uses golang:1.25-alpine container
- Links statically against musl libc and libseccomp
- Produces agentsh_VERSION_linux_amd64_musl.tar.gz
- Uploads to the GitHub release after goreleaser completes

Users on Alpine/musl systems should use the _musl tarball instead
of the regular glibc-linked binaries.

Co-Authored-By: Claude Opus 4.5 <[email protected]>

v0.8.5

Toggle v0.8.5's commit message
fix(release): enable CGO for Linux amd64 builds

The agentsh binary was being built with CGO_ENABLED=0, which caused
it to use the stub implementation (notify_stub.go) instead of the
real seccomp notify handler (notify_linux.go).

This resulted in allowed commands hanging because:
1. Stub closes the notify socket immediately
2. Wrapper tries to send notify FD but socket is closed
3. Seccomp filter blocks syscalls waiting for response
4. No response ever comes → hang

Split Linux build into two targets:
- agentsh-linux-amd64: CGO_ENABLED=1 (full seccomp support)
- agentsh-linux-arm64: CGO_ENABLED=0 (graceful degradation)

arm64 cross-compilation with CGO requires target libseccomp-dev
which is complex to set up in CI. arm64 users get stub behavior
(seccomp features unavailable but server otherwise works).

Co-Authored-By: Claude Opus 4.5 <[email protected]>

v0.8.4

Toggle v0.8.4's commit message
chore: add debug logging to seccomp notify handler

Add slog.Debug calls at key points in the seccomp notify flow
to help diagnose issues where allowed commands hang:

- notify_linux.go: Log when handler starts, receives FD, starts loop
- handler.go: Log notifications received and responses sent

These logs appear at DEBUG level so they won't affect normal operation.
To see them, set logging.level to "debug" in config.

Co-Authored-By: Claude Opus 4.5 <[email protected]>

v0.8.3

Toggle v0.8.3's commit message
fix(integration): skip entire depth test when probe fails

Move the probe check outside of a subtest so that when
seccomp-user-notify isn't working, the entire test skips instead
of only the probe subtest, preventing spurious failures.

Co-Authored-By: Claude Opus 4.5 <[email protected]>

v0.8.2

Toggle v0.8.2's commit message
fix(seccomp): set NotifRespFlagContinue for allowed syscalls

When seccomp user-notify allows a syscall (Error = 0), the kernel
requires Flags = NotifRespFlagContinue to know the syscall should
proceed. Without this flag, the kernel leaves the syscall in a
frozen state, causing the process to hang indefinitely.

This was causing allowed commands (whoami, ls, echo) to hang while
blocked commands (sudo, nc, ssh) worked correctly.

The signal handler already had the correct implementation - this
aligns the unix socket and execve handlers with that pattern.

Co-Authored-By: Claude Opus 4.5 <[email protected]>

v0.8.1

Toggle v0.8.1's commit message
v0.8.1: execve interception with depth-aware policy enforcement