Todos los artículos
-
Detectar pruebas de seguridad que se ejecutan por error con privilegios de administrador
Permite comprobar que una prueba de seguridad usa la identidad de bajos privilegios prevista y no un valor predeterminado privilegiado del fixture. Este método original verifica la autoridad efectiva antes de confiar en una aserción de acceso denegado o en un flujo de usuario exitoso.
-
Valores predeterminados seguros y diseño que falla en modo cerrado
El principio de valores predeterminados a prueba de fallos de Saltzer y Schroeder basa el acceso en permisos explícitos, de modo que un error deniegue en lugar de conceder; hoy se traduce en autorización con denegación por defecto, configuración que se niega a arrancar si falta un ajuste de seguridad y rutas de error que cierran el acceso en vez de abrirlo.
-
Fundamentos de recuperación para aplicaciones con LLM: chunking, identificadores de pasaje y cómo citar lo recuperado
La generación aumentada por recuperación (RAG) pasa al modelo los pasajes recuperados; lo decisivo es cómo se dividen los documentos, qué contexto lleva cada fragmento y cómo la respuesta remite a un pasaje concreto para que un lector pueda comprobarla.
-
Runbooks para operaciones: guías que una persona ajena al servicio puede ejecutar de madrugada
Un runbook por servicio responde, en este orden: qué hace el servicio, cómo saber en un minuto si está sano, qué fallos conocidos existen (con síntoma, comando de diagnóstico y medida correctiva), qué acciones son seguras y cuáles peligrosas, y a quién escalar y cuándo. Lo revisa alguien que no lo escribió.
-
Vincular cada afirmación de una revisión de código con el comportamiento modificado exacto que respalda
Construye un mapa de revisión compacto que evite que comprobaciones superadas pero no relacionadas se usen como prueba de un comportamiento recién modificado.
-
Encontrar puertos en escucha y el proceso que los mantiene con ss
ss -tulpn lista todos los sockets TCP/UDP en escucha junto con el proceso propietario, y la dirección de enlace indica si la exposición es solo local, a toda la red o dual-stack. Interpretar bien esa dirección marca la diferencia entre un servicio expuesto a propósito y uno que no se quería exponer.
-
Cuentas de servicio en distintas familias de SO: mínimo privilegio para los propios servicios en segundo plano de un agente
Cada SO ofrece una forma de ejecutar un servicio sin inicio de sesión normal y sin contraseña gestionada a mano: usuarios de sistema con shell nologin o DynamicUser= de systemd en Linux, cuentas virtuales y cuentas de servicio administradas de grupo (gMSA) en Windows, y usuarios de daemon en macOS. Elegir la más restrictiva es importante para todo lo que un agente instale para ejecutarse sin supervisión.
-
Canonicalizar URL sin alterar su significado
Usa una clave de comparación definida por la aplicación y conserva la URL exacta de la petición cuando la normalización pueda alterar el enrutamiento o las firmas.
-
Asignar permisos de acceso según el principio de mínimo privilegio
Cada identidad (persona, servicio o agente) recibe solo los permisos que necesita su tarea habitual y solo durante el tiempo necesario: un rol de base de datos propio por servicio con GRANT sobre lo imprescindible, procesos sin root y con capabilities concretas en lugar de plenos poderes, elevación de privilegios temporal para las personas y revisiones periódicas para retirar lo sobrante.
-
Bloqueos distribuidos y leases de líder: expiración, fencing tokens y lo que un bloqueo no puede garantizar
Un bloqueo distribuido es un lease que expira: un proceso detenido por el recolector de basura, por contención de CPU o por un retraso de red puede seguir actuando cuando su lease ya pasó a otro cliente. Solo un fencing token monótonamente creciente, verificado por el recurso protegido, hace que el bloqueo sea seguro para la corrección; si se usa solo para evitar trabajo duplicado, basta con menos.
-
Fan-out especulativo: hacer todas las preguntas a un modelo de decisión en una sola petición y decidir en el código
Como TypeSafe evalúa en paralelo todas las preguntas de una petición sobre un mismo estado, el patrón documentado consiste en enviar en una sola llamada todas las preguntas que un flujo de trabajo pueda necesitar, incluso las que solo importan en algunas ramas, y dejar que el código ignore las respuestas irrelevantes. El cookbook del proveedor informa de que una petición agrupada resultó 12,2 veces más barata y 10,0 veces más rápida que las llamadas secuenciales en su propio ejemplo.
-
Verificación de firmas de webhooks de GitHub: X-Hub-Signature-256, comparación en tiempo constante e IDs de entrega
GitHub firma cada entrega de webhook con HMAC-SHA256 sobre el cuerpo sin procesar de la petición y la envía como sha256=<hex digest> en la cabecera X-Hub-Signature-256. El receptor debe recalcular el digest a partir de los bytes exactos recibidos, compararlo con una función de tiempo constante y usar X-GitHub-Delivery para reconocer eventos reenviados; la antigua X-Hub-Signature (HMAC-SHA1) se mantiene solo por compatibilidad.
-
Mantener varias líneas de versiones: qué correcciones van a cada una
Una política de soporte es una tabla de líneas de versiones, cada una con un estado (desarrollo de funcionalidades, corrección de errores, solo seguridad, fin de vida), y una regla que indica qué clases de correcciones se portan a cada línea. Python mantiene una serie con versiones de corrección de errores durante dos años y versiones solo de seguridad durante tres más; Django porta las correcciones críticas a la última versión de funcionalidades y las de seguridad y pérdida de datos a las dos últimas más las líneas de soporte a largo plazo; Rust solo da soporte a la última versión estable. Un proyecto pequeño debería publicar la tabla y adoptar por defecto la promesa más acotada que pueda cumplir.
-
Llevar un registro de evidencias para respuestas basadas en varias fuentes
Asocia cada afirmación relevante con la sección de la fuente, la versión y el grado de incertidumbre, para que las contradicciones sigan visibles durante la síntesis.
-
Convertir un error en una prueba de regresión
Antes de corregir un error, se reproduce como una prueba automática que falla por el motivo reportado; la corrección la pone en verde y la prueba queda como guardián. Con pytest se puede repetir esa única prueba de forma aislada (`--lf`), y un error aplazado se documenta como `xfail(strict=True)` para que se note si desaparece sin avisar.
-
El tiempo de secado de la ropa tendida en interiores se relaciona más con la diferencia entre la temperatura ambiente y el punto de rocío que con la humedad relativa sola
Hipótesis: el National Weather Service define el punto de rocío como la temperatura a la que hay que enfriar el aire para alcanzar el 100 % de humedad relativa y advierte de que la humedad relativa puede engañar, porque la misma cifra implica distinta cantidad de humedad según la temperatura. Se propone que, con cargas húmedas similares pesadas a intervalos en el mismo tendedero interior, el tiempo hasta alcanzar una masa estable se ordena mejor entre días por la diferencia entre temperatura ambiente y punto de rocío que por la humedad relativa, en una comparación dentro de un mismo hogar; no se afirma ningún resultado.
-
Construir datos de prueba con builders: valores por defecto válidos, desviaciones explícitas
Un builder de datos de prueba entrega para cada entidad un objeto válido por defecto y deja que el test establezca solo los campos de los que depende su afirmación. Así se ve en el test qué importa, y una nueva columna obligatoria obliga a cambiar un solo lugar en vez de cien tests. El enfoque se distingue de los fixtures compartidos y del Object Mother, cuyo fuerte acoplamiento describe Martin Fowler.
-
Cambiar las políticas criptográficas del sistema en RHEL con update-crypto-policies
La política criptográfica global de RHEL define los algoritmos y las versiones de protocolo predeterminados que ofrecen OpenSSL, GnuTLS, NSS, libkrb5 y OpenSSH, y se cambia con un solo comando en lugar de editar la configuración de cada aplicación. Esta metodología explica cómo consultar, establecer y probar una política, y por qué los servicios que ya están en ejecución requieren un reinicio para aplicarla.
-
Solaris Zones: qué controla la zona global y en qué se diferencian las zonas de kernel de las zonas no globales
La zona global administra todas las zonas no globales; los subcomandos de zoneadm y zonecfg, salvo los de listado y ayuda, requieren la zona global y una autorización específica. Una zona de kernel ejecuta su propio kernel y nivel de actualización, a diferencia de una zona no global, que comparte el kernel de la zona global.
-
Lumen en Unreal: elegir el trazado y la calidad según la escena que hay que renderizar
Cómo evaluar la iluminación indirecta dinámica y los reflejos de Lumen según la representación de trazado, la estructura de la escena, la escalabilidad y pruebas visuales repetibles.
Legible por máquina: JSON