git clone over HTTPS fails with socket error while node's HTTPS to the same host succeeds (secure-exec VM)
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 48/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- git, node.js, rust
- Área
- devtools, networking
Línea de trabajo
Comienza reproduciendo el fallo con vm.exec usando git clone y la sonda TCP/HTTPS de Node que tiene éxito; después, lee registry/native/crates/libs/git/README.md e inspecciona el comportamiento de transporte del paquete publicado. Determina si se admite la clonación mediante HTTPS, qué representa errno 21 en esta ruta y si los subcomandos indicados son intencionados; se considera terminado cuando el comportamiento de transporte y los errores están explicados o corregidos.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Summary
git clone over HTTPS fails inside the secure-exec VM with a socket error, while node's own TCP and HTTPS reach the same host from the same VM in the same session. Network egress is permitted to github.com, so this looks like the git transport rather than the sandbox policy.
$ git clone https://github.com/octocat/Hello-World.git /tmp/repo
exit=128
Cloning into '/tmp/repo'...
fatal: fetch info/refs failed: socket error: connect(github.com:443) failed: errno 21
Immediately afterwards, in the same VM:
same VM, node stdlib to the same host:
TCP ok
HTTPS 200
Environment
@rivet-dev/agentos |
0.2.15 |
@agentos-software/git |
0.3.3 |
@agentos-software/common |
0.2.15 |
| engine | rivetdev/engine:2.3.9 (self-hosted) |
| worker base | node:24-slim |
VM permissions are default: deny with an explicit allowlist; github.com is allowed for both tcp://github.com:* and dns://github.com. A denied host fails differently and says so explicitly (EACCES … blocked by network.http policy), which is how we ruled the policy out — the message above is a socket error with no policy mention.
Reproduction
const vm = client.vm.getOrCreate("repro-" + Date.now());
// fails
await vm.exec("git clone https://github.com/octocat/Hello-World.git /tmp/repo");
// succeeds, same VM, same host
const probe = `
const net = require('net'), https = require('https');
net.connect({host:'github.com', port:443}, function(){ console.log('TCP ok'); this.destroy(); });
https.get({host:'github.com', path:'/', headers:{'User-Agent':'p'}}, r => { console.log('HTTPS ' + r.statusCode); r.destroy(); });
`;
await vm.exec(`node -e "eval(Buffer.from('${Buffer.from(probe).toString("base64")}','base64').toString())"`);
Questions
- Is HTTPS a supported clone transport for
@agentos-software/git? The error text points atregistry/native/crates/libs/git/README.md, which I can't see from the published package — the.aospkgdoes containgit://,ssh://andhttps://strings, so it reads as intended-but-not-working rather than unsupported. - If HTTPS is supported, does the git transport use a different egress path from node's stdlib — one that needs allowlisting separately from
tcp://host:port? That would explain a socket error while node succeeds. - What does
errno 21mean here? Other in-VM errors use WASI numbering (os error 44for ENOENT), which would make 21EFAULTand doesn't obviously fit aconnect().
Also, minor
A few subcommands report as unimplemented — flagging in case the list is unintentional rather than by design:
git --version→GitSubcommandUnsupportedgit log→GitSubcommandUnsupportedgit clone --depth 1 <url> <dest>→fatal: usage: git clone <source> [<destination>]
--version in particular is a common probe for "is git usable here", so it failing makes capability detection awkward.
Workaround
Fetching the repository as a tarball from codeload.github.com over plain HTTPS and unpacking with tar from @agentos-software/common, which works. Posting mainly because a working clone would give us verbatim transport output and ref handling that the tarball path doesn't.
- Lenguaje dominante
- Rust
- Estrellas
- 4.7k
- Forks
- 263
- Merge medio
- 9 h 43 min
- PR fusionados (30 d)
- 27
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de rivet-dev/agentos
-
Python edits to filesystem.writeFile-created files are reverted by shadow reconciliationPosiblemente ocupada @ankssjain la tomó hace 1 día. Abierto
Dificultad 4/5 3-5 días Aptitud para principiantes 20/100
rivet-dev/agentos#2022 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 3/5 Medio día Aptitud para principiantes 32/100
Los mantenedores suelen responder en 1 día
-
Python launched through guest shell stalls on queued filesystem RPCsPosiblemente ocupada @ankssjain la tomó hace 7 días. Abierto
Dificultad 4/5 3-5 días Aptitud para principiantes 52/100
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 45/100
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 66/100
rivet-dev/agentos#1994 · 1 comentario ·
Los mantenedores suelen responder en 1 día
Todos los issues de rivet-dev/agentos
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
rubys/roundhouse#571 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
-
documentation
Dificultad 1/5 Menos de una hora Aptitud para principiantes 90/100
fastrevmd-lab/rustmistmcp#161 ·
-
arch-audit refactor
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
SocketDev/socket-patch#1011 ·
Los mantenedores suelen responder en 1 día