Hardening for DiagnosticPort
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
- 45/100
Línea de trabajo
Empieza rastreando cómo las herramientas de diagnóstico y el runtime eligen la ubicación del socket de DiagnosticPort y cómo se gestionan RUNTIME_DIR, XDG_RUNTIME_DIR, TMPDIR y /tmp. Revisa la secuencia de compatibilidad descrita en el issue: las herramientas deben comprobar las nuevas ubicaciones antes de que el runtime las use. Se considera completado cuando se admiten los directorios preferidos con permisos de escritura para el usuario cuando están establecidos, conservando los fallbacks existentes.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
The current security model for diagnostic port acknowledges that a malicious process could create its own unix domain socket or squat on the file name that would be used by some other process whenever /tmp or TMPDIR is shared with untrusted users. Although we aren't planning to change those basic assumptions in the security model, we could still take steps to make the squating less likely by using directories that are only writable by the current user when possible such as RUNTIME_DIR and XDG_RUNTIME_DIR.
We should consider adding support for writing the port under those directories if the environment variables are set, then falling back to TMPDIR and /tmp otherwise. If we do this we need to be wary of back-compat by updating the tools first to check those locations, then update the runtime later once the tools have had time to be picked up by users.
- Lenguaje dominante
- C++
- Estrellas
- 1.3k
- Forks
- 407
- Merge medio
- 21 h 5 min
- PR fusionados (30 d)
- 78
Preparar el entorno
Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Sin guía de contribución
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 dotnet/diagnostics
-
Fix StackAndOtherTests.script line number verification for .NET 11 and Windows x64Quizá libre de nuevo Un pull request para esta issue se cerró sin fusionarse. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
dotnet/diagnostics#5884 · 2 comentarios ·
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 25/100
dotnet/diagnostics#6225 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
dotnet/diagnostics#6213 ·
Los mantenedores suelen responder en 1 día
-
Isolate SOS hosting from other debugger extensions that use managed codePosiblemente ocupada Un pull request vinculado a esta issue está abierto o ya se fusionó. Abiertobug
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
dotnet/diagnostics#6207 ·
Los mantenedores suelen responder en 1 día
-
Known Build Error
Dificultad 4/5 3-5 días Aptitud para principiantes 49/100
dotnet/diagnostics#6190 ·
Los mantenedores suelen responder en 1 día
Todos los issues de dotnet/diagnostics
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
AutoHotkey/AutoHotkey#380 ·
-
documentation
Dificultad 1/5 1-3 horas Aptitud para principiantes 84/100
Los mantenedores suelen responder en 1 día
-
Lua File: add readWhole()Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 69/100
grumpycoders/pcsx-redux#2667 ·
-
GCC 15.2: -Wcast-qual warning - cast discards const qualifier from pointer target type (H5trace.c)Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 73/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
google/tensorstore#305 ·