Enterprise Server 3.1 release notes

Los paquetes se actualizaron a las últimas versiones de seguridad.

An internal script to validate hostnames in the GitHub Enterprise Server configuration file would return an error if the hostname string started with a "." (period character).

In HA configurations where the primary node's hostname was longer than 60 characters, MySQL would fail to be configured.

The calculation of "maximum committers across entire instance" reported in the site admin dashboard was incorrect.

An incorrect database entry for repository replicas caused database corruption when performing a restore using Utilidades de respaldo del servidor de GitHub Enterprise.

In HA configurations where Elasticsearch reported a valid yellow status, changes introduced in a previous fix would block the ghe-repl-stop command and not allow replication to be stopped. Using ghe-repo-stop --force will now force Elasticsearch to stop when the service is in a normal or valid yellow status.

MEDIA: Se identificó una propuesta de seguridad en el resolutor de ngnix, en donde un atacante pudo haber falsificado paquetes de UDP desde el servidor DNS y pudo ocasionar una sobre escritura de memoria en bytes, dando como resultado que fallara un proceso trabajador u otros impactos dañinos potenciales. Se asingó el CVE-2021-23017 a la vulnerabilidad.

Se actualizaron las acciones actions/checkout@v2 y actions/checkout@v3 para abordar las vulnerabilidades nuevas que se anunciaron en la Publicación del blog de refuerzo de seguridad de Git.

Los paquetes se actualizaron a las últimas versiones de seguridad.

En algunas topologías de clúster, el comando ghe-cluster-status dejó directorios vacíos en /tmp.

El SNMP registró una cantidad alta de mensajes de error de Cannot statfs incorrectamente en syslog.

Para el caso de las instancias configuradas con la autenticación de SAML y con la recuperación de fallos integrada habilitada, los usuarios integrados se atoraron en un bucle de "inicio de sesión" al intentar iniciar sesión desde la página generada después de salir de sesión.

Al utilizar aserciones cifradas de SAML, algunas de ellas no estaban marcando correctamente a las llaves SSH como verificadas.

The Releases page would return a 500 error when the repository has tags that contain non-ASCII characters. [Updated: 2022-06-10]

En las configuraciones de disponibilidad alta, se aclara que la página de resumen de replicación en la consola de administración solo muestra la configuración de replicación actual y no el estado de replicación actual.

When enabling Registro del paquete de GitHub, clarify that using a Shared Access Signature (SAS) token as connection string is not supported.

Los paquetes de soporte ahora incluyen el conteo de filas de las tablas que se almacenan en MySQL.

Los paquetes se actualizaron a las últimas versiones de seguridad.

El cargar nodos en un par con disponibilidad alta con un paquete de mejora pudo haber causado que Elasticsearch ingresara en un estado inconsistente en algunos casos.

En algunas topologías de clúster, no pudieron ejecutarse las utilidades de línea de comandos ghe-spokesctl y ghe-btop.

Los índices de Elastisearch podrían duplicarse durante la mejora de un paquete debido a que el servicio de elasticsearch-upgrade se ejecutó varias veces en paralelo.

The maint_host_low job queues were not processed, resulting in some maintenance tasks failing to run.

Cuando conviertes una cuenta de usuario en una organización, si dicha cuenta fue propietaria de la cuenta empresarial de GitHub Enterprise Server, la organización convertida se mostró incorrectamente en la lista de propietarios de la empresa.

El crear un token de OAuth de personificación utilizando la API de REST de administración de empresas dio como resultado un error cuando una integración que coincidió con la ID de aplicación de OAuth ya existía.

When attempting to cache a value larger than the maximum allowed in Memcached, an error was raised however the key was not reported.

MEDIA: Se identificó una vulnerabilidad de recorrido de ruta en la consola de administración de GitHub Enterprise Server, la cual permitió un puenteo de las protecciones CSRF. Esta vulnerabilidad afectó a todas las versiones de GitHub Enterprise Server anteriores a la 3.5 y se corrigió en las versiones 3.1.19, 3.2.11, 3.3.6 y 3.4.1. Esta vulnerabilidad se reportó mediante el programa de recompensas por errores de GitHub y se le asignó el CVE-2022-23732.

MEDIA: Se identificó una vulnerabilidad de desbordamiento de números enteros en la rama 1.x y 2.x de yajil, lo cual conllevó a una corrupción subsecuente de memoria dinámica al lidiar con entradas grandes (~2GB). Esta vulnerabilidad se reportó internamente y se le asignó el CVE-2022-24795.

Los paquetes de soporte podrían incluir archivos sensibles si es que se habilitaron las GitHub Actions.

Los paquetes se actualizaron a las últimas versiones de seguridad.

Se mostraron las opciones para habilitar TLS 1.0 y TLS 1.1 en los ajustes de privacidad de la consola de administración a pesar de haber eliminado esas versiones de protocolo que ocurrieron en un lanzamiento anterior.

En un ambiente de HA, el configurar la replicación de MSSQL podría requerir pasos manuales adicionales después de habilitar las GitHub Actions por primera ocasión.

Un subconjunto de archivos de configuración interna se actualiza de forma más confiable después de un hotpatch.

Algunas veces, el script ghe-run-migrations falló en generar nombres de certificados temporales correctamente.

En un ambiente de clúster, las operaciones de LFS de git pudieron haber fallado con llamadas fallidas a la API interna que cruzaron diversos nodos web.

Los ganchos de pre-recepción que utilizaron gpg --import agotaron su tiempo de espera debido a que no tuvieron los privilegios de syscall suficientes.

En algunas topologías de clúster, no estuvo disponible la información de entrega de webhooks.

In HA configurations, tearing down a replica would fail if GitHub Actions had previously been enabled.

La verificación de salud de Elasticsearch no permitió un estado de clúster amarillo al ejecutar las migraciones.

Las organizaciones que se crearon como resultado de que un usuario haya transformado su cuenta de usuario en una organización no se agregaron a la cuenta empresarial global.

When using ghe-migrator or exporting from GitHub.com, a long-running export would fail when data was deleted mid-export.

Se eliminaron los enlaces a las páginas inaccesibles.

El agregar a un equipo como revisor para una solicitud de cambios algunas veces muestra la cantidad incorrecta de miembros en un equipo.

Una gran cantidad de usuarios inactivos podría ocasionar que falle una configuración de GitHub Connect.

La página de "Características e inscripciones beta" en la IU web del administrador de sitio estuvieron disponibles de forma incorrecta.

El enlace de "Modo de administrador de sitio" en el pie de página del sitio no cambió de estado cuando se hizo clic sobre este.

Los límites de conexión almacenados en la memoria de alto rendimiento se incrementaron para adaptarse mejor a las topologías de clústers grandes.

More effectively identify and delete webhook logs that are outside of the webhook log retention window.

La API de la gráfica de dependencias se ejecutó previamente con un puerto definido estáticamente.

Se actualizó el conteo de fragmentos de los ajustes de fragmentos de la Elasticsearch relacionada con el clúster.

Los roles de equipo de "Clasificación" y "Mantenimiento" se preservan durante las migraciones de repositorios.

NotProcessedError exceptions were occurring unnecessarily.

Se mejoró el rendimiento para las solicitudes web que hicieron los propietarios de las empresas.

ALTA: Se identificó una vulnerabilidad de desbordamiento de integrales en el analizador de lenguaje de marcado de GitHub, la cual pudo haber ocasionado fugas de información potenciales y RCE. Esta vulnerabilidad la reportó Felix Wilhelm, del proyecto Zero de Google, mediante el programa de Recompensas por Errores de GitHub y se le asignó el CVE-2022-24724.

Las mejoras fallaron algunas veces si el reloj de una réplica de disponibilidad alta se desincronizó con el primario.

Las aplicaciones de OAuth que se crearon después del 1 de septiembre de 2020 no pudieron utilizar la terminal de la API de Verificar una autorización.

Los paquetes se actualizaron a las últimas versiones de seguridad.

Corrige SystemsStackError (pila demasiado profunda) cuando se obtienen más de 2^{^16} claves de memcached.

Los paquetes se actualizaron a las últimas versiones de seguridad.

Las páginas se hicieron no disponibles siguiendo una rotación de secretos de MySQL hasta que nginx se restableció manualmente.

Cuando se configura la programación de mantenimiento con una fecha ISO 8601, el tiempo programado real no coincide debido a que la zona horaria no se transforma a UTC.

Los mensajes de errores espurios con respecto a cloud-config.service se sacarían a la consola.

El número de versión no se pudo actualizar correctamente después de instalar un hotpatch utilizando ghe-cluster-each.

Los jobs de limpieza de tabla de webhook pueden ejecutarse simultáneamente ocasionando contención de recursos e incrementando el tiempo de ejecución del job.

Cuando se utilizó la autenticación CAS y se habilitó la autenticación de "Reactivar usuarios suspendidos", dichos usuarios no se reactivaron automáticamente.

La capacidad de limitar las notificaciones basadas en correos electrónicos para los usuarios con correos electrónicos en un dominio aprobado o verificado no funcionó correctamente.

Varios enlaces de documentación dieron como resultado un error de tipo "404 Not Found".

El registro de conexión de datos de GitHub Connect ahora incluye un conteo de la cantidad de usuarios inactivos y activo y el periodo de inactividad configurado.

Se actualizaron los paquetes a las versiones de seguridad más recientes. En estas actualizaciones, Log4j se actualizó a la versión 2.17.1. Nota: Las mitigaciones que se lanzaron previamente en las versiones 3.3.1, 3.2.6, 3.1.14 y 3.0.22 son suficientes para tratar el impacto de las CVE-2021-44228, CVE-2021-45046, CVE-2021-45105 y CVE-2021-44832 en estas versiones de GitHub Enterprise Server.

Sanitiza más secretos en los paquetes de soporte generados

Los paquetes se actualizaron a las últimas versiones de seguridad.

El ejecutar ghe-config-apply pudo fallar en ocasiones debido a problemas con los permisos en /data/user/tmp/pages`.

El botón de guardar en la consola de almacenamiento no se pudo alcanzar desplazándose en buscadores de resolución menor.

Las gráficas de monitoreo de tráfico de almacenamiento e IOPS no se actualizaron después de la mejora de versión de collectd.

Algunos jobs relacionados con webhooks pudieron haber generdo una gran cantidad de bitácoras.

Los permisos de repositorio para el usuario que devolvió la API de /repos no devolvieron la lista completa.

Crítica: Una vulnerabilidad de ejecución de código remoto en la librería de Log4J, identificada como CVE-2021-44228, afectó a todas las versiones de GitHub Enterprise Server anteriores a la 3.3.1. La librería Log4j se utiliza en un servicio de código abierto que se ejecuta en la instancia de GitHub Enterprise Server. Esta vulnerabilidad se corrigió en las versiones 3.0.22, 3.1.14, 3.2.6 y 3.3.1 de GitHub Enterprise Server. Para obtener más información, consulta esta publicación en el Blog de GitHub.

Actualización del 17 de diciembre de 2021: Las correcciones que se llevaron a cabo para este lanzamiento también mitigan el CVE-2021-45046, el cual se publicó después de dicho lanzamiento. No se necesita ninguna actualización adicional en GitHub Enterprise Server para mitigar tanto al CVE-2021-44228 como al CVE-2021-45046.

Los paquetes de soporte podrían incluir archivos sensibles si cumplen con un conjunto de características específicas.

Se identificó una representación errónea de la IU en GitHub Enterprise Server que permitió que se otorgaran más permisos durante un flujo web de usuario-autorización de una GitHub App que se mostró al usuario durante su aprobación. Dicha vulnerabilidad afectó a todas las versiones de GitHub Enterprise Server previas a la 3.3 y se corrigió en las versiones 3.2.5, 3.1.13 y 3.0.21. Esta vulnerabilidad se reportó mediante el programa de Recompensas por Errores de GitHub y se le asignó el CVE-2021-41598.

Se identificó una vulnerabilidad de ejecución de código remoto en GitHub Enterprise Server, la cual pudo haberse aprovechado al compilar un sitio de GitHub Pages. Esta vulnerabilidad afectó a todas las versiones de GitHub Enterprise Server anteriores a la 3.3 y se corrigió en las versiones 3.0.21, 3.1.13 y 3.2.5. Esta vulnerabilidad se reportó a través del programa de Recompensas por Errores de GitHub y se le asignó el CVE-2021-41599. Actualizado el 17 de febrero de 2022

El ejecutar ghe-config-apply pudo fallar en ocasiones debido a problemas con los permisos en /data/user/tmp/pages`.

Una mala configuración en la consola de administración causó errores de programación.

Docker retuvo los archivos de bitácora abiertos después de una rotación de bitácoras.

Las solicitudes de GraphQL no configuraron la variable GITHUB_USER_IP en los ambientes de ganchos de pre-recepción.

Clarifica una explicación del estilo de ruta de las acciones en la documentación.

Las actualizaciones tienen compatibilidad con las URL de contacto para utilizar el sitio de soporte actual, support.github.com.

Los paquetes se actualizaron a las últimas versiones de seguridad.

El ejecutar ghe-repl-start o ghe-repl-status algunas veces devolvió errores para conectarse a la base de datos cuando se habilitó GitHub Actions.

Los ganchos de pre-recepción fallaron debido a un PATH sin definir.

El ejecutar ghe-repl-setup devolvió un error de tipo: cannot create directory /data/user/elasticsearch: File exists si la instancia se había configurado anteriormente como una réplica.

Después de configurar una réplica de disponibilidad alta, ghe-repl-status incluyó un error en la salida: unexpected unclosed action in command.

En ambientes de clúster grandes, el backend de autenticación podría no estar disponible en un subconjunto de nodos de frontend.

Algunos servicios críticos pudieron no haber estado disponibles en los nodos del backend en el Clúster de GHES.

Una capa externa adicional de la compresión de gzip, al crear un paquete de soporte de clúster con ghe-cluster-suport-bundle, ahora se encuentra apagada predeterminadamente. Esta compresión externa puede aplicarse opcionalmente con la opción de línea de comandos ghe-cluster-suport-bundle -c.

Agregamos texto extra a la consola de administración para recordarles a los usuarios sobre la recolección de datos de las apps móviles para propósitos de mejora de la experiencia.

El registro de conexión de datos de GitHub Connect ahora incluye una lista de características de GitHub Connect habilitadas. [Actualizado el 2021-12-09]

Se identificó una vulnerabilidad de recorrido de ruta en las compilaciones de Páginas de GitHub en GitHub Enterprise Server, la cual pudo haber permitido que un atacante leyera los archivos de sistema. Para explotar esta vulnerabilidad, el atacante necesitaría permiso para crear y compilar un sitio de Páginas de GitHub en la instancia de GitHub Enterprise Server. Esta vulnerabilidad afectó a todas las versiones de GitHub Enterprise Server anteriores a la 3.3 y se corrigió en las versiones 3.0.19, 3.1.11 y 3.2.3. Esta vulnerabilidad se reportó a través del programa de Recompensas por Errores de GitHub y se le asignó el identificador CVE-2021-22870.

Los paquetes se actualizaron a las últimas versiones de seguridad.

Algunas operaciones de Git fallaron después de mejorar a GitHub Enterprise Server 3.x clúster debido a una configuración del HAProxy.

Los conteos de trabajadores de Unicorn se configuraron incorrectamente en el modo de clústering.

Los conteos de trabajadores solicitados pudieron haberse configurado incorrectamente en el modo de clústering.

Si el estado de Ubuntu's Uncomplicated Firewall (UFW) fue inactivo, un cliente no pudo verlo claramente en las bitácoras.

La actualización de GitHub Enterprise Server 2.x a 3.x falló cuando habían caracteres UTF8 en una configuración LDAP.

Algunas páginas y jobs en segundo plano relacionados con Git podrían no ejecutarse en modo clúster con algunas configuraciones de clúster.

Al crear una etiqueta nueva, la carga útil del webhook de push no mostró un objeto correcto de head_commit. Ahora, cuando se crea una etiqueta nueva, la carga útil del webhook de subida siempre incluye un objeto de head_commit que contiene los datos de la confirmación a la cual apunta dicha etiqueta nueva. Como resultado, el objeto head_commit siempre contendrá los datos de la confirmación after de la carga útil.

La página de bitácoras de auditoría de la empresa no mostro eventos de auditoría para el escaneo de secretos.

Hubo un tiempo límite del job que fue insuficiente para las reparaciones de la réplica.

No se advirtió a los usuarios sobre los caracteres bidireccionales y peligrosos de unicode al visualizar los archivos. Para obtener más información, consulta la sección "Advertencia sobre el texto bidireccional de Unicode" en el el blog de GitHub.

Hookshot Go envió métricas de tipo de distribución que Collectd no pudo manejar, lo cual ocasionó una dilatación de errores de interpretación.

Se agregaron mejoras de configuración de Kafka. Al borrar repositorios, ahora se borran los archivos de paquete inmediatamente de la cuenta de almacenamiento para liberar espacio. DestroyDeletedPackageVersionsJob ahora borra archivos de paquete de la cuenta de almacenamiento para el caso de los paquetes desactualizados junto con los registros de metadatos.

Fue posible que las contraseñas de texto claro terminaran en algunos archivos de bitácora.

Se agregaron varias llaves SSH públicas débiles conocidas a la lista de llaves no permitidas y estas ya no pueden registrarse. Adicionalmente, se bloquearon a las versiones de GitKraken que se sabe generarán llaves SSH débiles (7.6.x, 7.7.x y 8.0.0) para que no generen llaves públicas nuevas.

Los paquetes se actualizaron a las últimas versiones de seguridad.

El restablecimiento podría fallar para el servidor empresarial en modo de clústering si el orquestador no tiene buena salud.

Los usuarios que son propietarios de muchas organizaciones no pudieron utilizar varias partes de la aplicación.

Fijar un enlace a https://docs.github.com.

Las optimizaciones de búsqueda y rendimiento de jobs para los repositorios con muchas refs.

Los paquetes se han actualizado a sus últimas versiones de seguridad.

Los ganchos de recepción personalizados fallaron debido a los límites demasiado restrictivos en la memoria virtual o CPU.

El intento de borrar todos los ajustes de configuración existentes con ghe-cleanup-settings falló en reiniciar el servicio de la Consola de Administración.

Durante el desmonte de replicación a través de ghe-repl-teardown, Memcached falló en reiniciar.

Durante los periodos de carga alta, los usuarios recibieron códigos de estado HTTP 503 cuando los servicios ascendentes fallaron sus revisiones de salud interna.

Con las acciones configuradas, la replicación de MSSQL falló después de restablecer desde una captura de pantalla de las Utilidades de Respaldo de GitHub Enterprise.

Pudo haberse mostrado un mensaje de error de jq erróneo al ejecutar ghe-config-apply.

Se prohibió que los ambientes de los ganchos de pre-recepción llamaran el comando cat a través de BusyBox en Alpine.

La contraseña de la base de datos externa se registró en texto simple.

La recuperación de fallos desde un centro de datos de un clúster primario hacia uno de un clúster secundario fue exitosa, pero recuperarse de los fallos nuevamente hacia el centro de datos del clúster primario original no pudo promover los índices de Elasticsearch.

El botón de "importar equipos" en la página de equipos de una organización devolvió un HTTP 404.

En algunos casos, los Administradores de GitHub Enterprise que intentaron ver la página de Usuarios inactivos recibieron una respuesta de tipo 502 Bad Gateway o 504 Gateway Timeout.

Se impactó el rendimiento de forma negativa en algunas situaciones de carga alta como resultado del aumento en la cantidad de jobs de SynchronizePullRequestJob.

Se borraron bitácoras de webhook de forma más efectiva, las cuales salían de la ventana de retención de bitácoras de webhook.

ALTA: Se identificó una vulnerabilidad de navegación de ruta en GitHub Enterprise Server que podría aprovecharse al crear un sitio de Páginas de GitHub. Las opciones de configuración que controla el usuario y que utiliza Páginas de GitHub no se restringieron lo suficiente e hicieron posible que se leyeran archivos en la instancia de GitHub Enterprise Server. Para aprovechar esta vulnerabilidad, los atacantes necesitarían permisos para crear y compilar un sitio de Páginas de GitHub en la isntancia de GitHub Enterprise Server. Esta vulnerabilidad afectó a todas las versiones de GitHub Enterprise Server anteriores a la 3.1.8 y se corrigió en las versiones 3.1.8, 3.0.16 y 2.22.22. Este es el resultado de un arreglo incompleto para el CVE-2021-22867. Esta vulnerabilidad se reportó a través del Programa de Recompensas por Errores de GitHub y se le asignó el caso CVE-2021-22868.

MEDIA: Una vulnerabilidad de control de accesos inadecuado en GitHub Enterprise Server permitió que un job de flujo de trabajo se ejecutara en un grupo de ejecutores auto-hospedados al cual no debería haber accedido. Esto afecta a los clientes que utilizan grupos de ejecutores auto-hospedados para el control de accesos. Un repositorio con acceso a un grupo de ejecutores empresariales podría acceder a todos los grupos de ejecutores empresariales dentro de la organización debido a las verificaciones de autenticación inadecuadas durante la solicitud. Esto podría ocasionar que se ejecutara código sin querer por parte del grupo de ejecutores incorrecto. Esta vulnerabilidad afectó a las versiones desde la 3.0.0 hasta la 3.0.15 y desde la 3.1.0 hasta la 3.1.7 de GitHub Enterprise Server y se corrigió en los lanzamientos 3.0.16 y 3.1.8. Se le asignó el caso CVE-2021-22869.

Los conteos del trabajador de Resque se mostraron incorrectamente durante el modo de mantenimiento.

La memoria memcached asignada pudo haber sido cero en el modo de clústering.

Los archivos binarios no vacíos mostraron un tipo y tamaño de archivo incorrectos en la pestaña "Archivos" de una solicitud de cambios.

Arregla compilaciones de las Páginas de GitHub para que tomen en cuenta la configuración de NO_PROXY del aplicativo. Esto es relevante para los aplicativos configurados únicamente con un proxy HTTP. (actualización 2021-09-30)

sections -> bugs -> 2 File: 16.yml

La configuración de GitHub Connect para la instancia origen siempre se restableció a las instancias nuevas, incluso cunado no se utilizó la opción --config para ghe-restore. Esto ocasionó un conflicto con la conexión de GitHub Connect y la sincronización de licencia si tanto la instancia de origen como la de destino estuvieron en línea al mismo tiempo. Este arreglo también requiere actualizar las utilidades de respaldo a la versión 3.2.0 o superior. [actualizado: 2021-11-18]

Los paquetes se actualizaron a las últimas versiones de seguridad.

Intentar tirar un nodo de réplica recién agregado especificando su UUID con ghe-repl-teardown falló sin reportar un error en caos de que la replicación no hubiera iniciado.

Las compilaciones de GitHub Pages se estaban pasando por un proxy externo si es que había alguno configurada.

Los ganchos de pre-recepción que crearon subprocesos no tenían una variable de PATH en su ambiente, lo cual dio como resultado un error de tipo "No such file or directory".

MySQL pudo haberse recuperado de un desastre durante una mejora si se había habilitado mysql-auto-failover.

Los paquetes se actualizaron a las últimas versiones de seguridad.

El agregar imágenes muy grandes o GIF animados a las imágenes o solicitudes de cambio, fallará.

Los mensajes de Journald con relación a las actualizaciones automáticas (Agregar una hora aleatoria en h/m/s.) se registraron en syslog.

Los ganchos de pre-recepción que crearon canalizaciones nombradas (FIFO) fallaron o demoraron, lo cual resultó en un error de tiempo de espera.

Agregar filtros para que la página de búsqueda avanzada de bitácoras de auditoría no llene la caja de texto de consultas en tiempo real con el valor y prefijo de faceta correcto.

Los ganchos de Git hacia la API interna que dio como resultado solicitudes fallidas devolvieron la excepción undefined method body for "success":String (NoMethodError) en vez de devolver un nil explícito.

Cuando se eliminó una integración, fue posible que una aplicación OAuth o integración no relacionada s también se eliminaran.

Cuando se agregó un mensaje obligatorio que contenía un caracter de emoji que intentaba ver o cambiar el mensaje, se devolvió un error tipo "500 Internal Server Error".

Agrega triage y maintain a la lista de permisos que devuelve la API de REST.

Los ganchos de pre-recepción que utilizaron un subshell de bash devolvieron un error de tipo: No such file or directory.

Cuando se habilitaron las GitHub Actions sin ejecutar los respaldos con programación frecuente, la bitácora de transacción de MSSQL pudo haber crecido más allá de los límites y consumido todo el espacio disponible en el disco de datos del aplicativo, causando una posible interrupción del servicio.

El registro innecesario en las bases de datos consumió una cantidad grande de espacio en disco en las instancias con un uso fuerte de LFS.

Las entradas de bitácoras de auditoría para los cambios realizados a los ajustes de organización de "Creación de repositorios" fueron inexactas.

El registro excesivo de las exepciones de ActionController::UnknownFormat causa un uso innecesario de disco.

Los valores de group_dn de LDAP de más de 255 caracteres dieron como resultado que los errores se registraran: Datos truncados para la columna 'group_dn' en la fila 1.

El abuso de límites de tasa ahora se llama Límites de tasa secundarios, ya que el comportamiento que limitan no siempre es abusivo.

Los paquetes se actualizaron a las últimas versiones de seguridad.

Los conteos en las páginas de los paquetes no se estaban incrementando cuando se descargaba un paquete.

El tiempo de ghe-config-apply venció, pidió un mensaje o falló para un cliente que tenía habilitado el escaneo de secretos e inhabilitó o jamás habilitó las GitHub Actions en su instancia.

Los archivos de bitácora no se volvieron a abrir después de su rotación en algunos casos, lo cual ocasionó un uso alto de espacio en disco en las instancias con tiempo de actividad alto.

Las actualizaciones desde una versión antigua de GitHub Enterprise Server podrían fallar debido a que falta un job en GitHub Actions.

Los ganchos de pre-recepción personalizados podrían llevar a un error como error: object directory /data/user/repositories/0/nw/12/34/56/7890/network.git/objects does not exist; check .git/objects/info/alternates.

El proxy HTTP no autenticado para la compilación de contenedores de las páginas no era compatible para ningún usuario que utilizara proxys HTTP.

Una cantidad significativa de 503 errores se registró cada que un usuario vistió la página de /settings de un repositorio si la gráfica de dependencias no estaba habilitada.

Los repositorios internos solo se devolvieron cuando un usuario había tenido afiliaciones con el repositorio mediante un equipo o estado de colaborador o cuando se consultaron con el parámetro ?type=internal.

Los jobs en segundo plano fallidos tienen reintentos ilimitados, los cuales podrían causar filas muy largas.

Una cantidad significativa de 503 errores se habrían estado creando si el job programado para sincronizar vulnerabilidades con GitHub.com intentó ejecutarse cuando la gráfica de dependencias no estuvo habilitada y el análisis de contenido sí estaba habilitado.

Cuando se habilitan las GitHub Actions sin ejecutar respaldos programados frecuentes, la bitácora de transacción de MSSQL podría crecer sin límites y consumir todo el espacio disponible en el disco de datos del aplicativo, ocasionando una posible interrupción.

Si configuraste los respaldos programados frecuentes de MSSQL, no necesitas tomar ninguna acción adicional. De lo contrario, si tienes habilitadas las GitHub Actions previamente, ejecuta los siguientes comandos después de instalar este parche.

ghe-actions-console -s Mps -c 'Update-Service -Force'
ghe-actions-console -s Token -c 'Update-Service -Force'
ghe-actions-console -s Actions -c 'Update-Service -Force'

Las bitácoras de babeld ahora incluyen un campo de cmd para las solicitudes de publicidad de ref de HTTP en vez de solo incluirlas durante las solicitudes de negociación.

ALTA: Una vulnerabilidad que atravesaba rutas se identificó en GitHub Enterprise Server, la cual podría aprovecharse al crear un sitio de GitHub Pages. Las opciones de configuración que controla el usuario y que utiliza GitHub Pages no se restringieron suficientemente, lo cual hizo posible que se leyeran archivos en la instancia de GitHub Enterprise Server. Para aprovechar esta vulnerabilidad, el atacante necesitaría permiso para crear y compilar un sitio de GitHub Pages en la instancia de GitHub Enterprise Server. Esta vulnerabilidad afectó a todas las versiones de GitHub Enterprise Server anteriores a la 3.1.3 y se le asignó el CVE-2021-22867. Esta vulnerabilidad se reportó a través del programa de Recompensas por Errores de GitHub.

Los paquetes se actualizaron a las últimas versiones de seguridad.

La variable de vencimiento de fecha de SAML no se pudo configurar.

Los servicios de aplicación fallaron en sus verificaciones de salud durante una aplicación de configuración antes de que pudieran ingresar a un estado saludable.

El ghe-cluster-config-node-init falló durante la configuración de clúster si se había habilitado el proxy de HTTP.

Los ganchos de pre-recepción pudieron haber encontrado un error de tipo Failed to resolve full path of the current executable debido a que un /proc no se pudo montar en el contenedor.

Collectd no resolvió el nombre de host destino que se estaba reenviando después del inicio principal.

El job que purgó los repositorios inactivos borrados pudo haber fallado en hacer progreso si alguno de estos repositorios estaba protegido contra borrado debido a las retenciones legales.

Los jobs en segundo plano se pusieron en la fila de spam, los cuales no se estaban procesando.

El método de fusión preferido se restablecerá cuando se reintente después de una fusión fallida de solicitud de cambio.

Las subidas de Git dieron como resultado un Error de Servidor Interno 500 durante el proceso de reconciliación del usuario en las instancias que utilizaban el modo de autenticación de LDAP.

Después de mejorar de la versión 3.0.x a la 3.1.x, en algunos casos, las GitHub Actions fallarían con un error de tipo An unexpected error occurred when executing this workflow.

Se mejoró la eficiencia de la aplicación de configuraciones al omitir las reglas de cortafuegos para permitir IP, las cuales no hubieran cambiado, lo cual ahorró tiempo significativo en los clústeres grandes.

Los paquetes se actualizaron a las últimas versiones de seguridad.

Una cantidad más grande de métricas gauge-dependency-graph-api-dispatch_dispatch pudo acumularse en a consola de administración.

El servicio de sshd algunas veces falló en iniciar en instancias que se estaban ejecutando en la plataforma de Google Cloud.

Los archivos de actualización antiguos persistieron en el disco del usuario, lo cual algunas veces dio como resultado tener condiciones de falta de espacio.

gh-migrator mostró una ruta incorrecta a su bitácora de salida.

Un archivo de exportación falló silenciosamente en importar solicitudes de cambios si estas contenían solicitudes de revisión de equipos que no estaban presentes en el archivo.

Actualiza la versión del ejecutor de GitHub Actions en GHES 3.1 a la v2.278.0

Los paquetes se actualizaron a las últimas versiones de seguridad.

El SVN 1.7 y los clientes más antiguos mostraron un error cuando se utilizaron los comandos svn co y svn export.

El acceder a un repositorio a través del shell administrativo utilizando ghe-repo <owner>/<reponame> provocaba retraso.

Después de hacer la mejora, los usuarios experimentaron una disponibilidad reducida durante el uso intensivo, ya que los servidores se reiniciaron muy frecuentemente. Esto ocurriría debido a los desajustes de tiempo entre la configuración nómada y aquella de los servicios internos.

En algunas instancias, el ejecutar ghe-repl-status después de haber configurado las GitHub Actions produjo un error y ghe-actions-teardown falló.

ghe-dbconsole devolvió errores en algunas circunstancias.

El importar fallos de organizaciones o repositorios desde fuentes diferentes a GitHub podría producir un error de tipo undefined method '[]' for nil:NilClass.

Los nombres de perfil de GitHub podrían haber cambiado accidentalmente al utilizar la autenticación de SAML, si el nombre de perfil de GitHub no coincidió con el valor del atributo que se mapeó en el campo Full name de la consola de administración.

El actualizar una instancia que ejecutó un lanzamiento 2.13 previamente, pero no uno de tipo 2.14, dio como resultado un error de migración de base de datos que se relacionaba con la transición de datos AddRepositoryIdToCheckRuns.

Los usuarios de la API de GraphQL pueden consultar el campo público closingIssuesReferences en el objeto PullRequest. Este campo recupera propuestas que se cerrarán automáticamente cuando se fusione la solicitud de cambios relacionada. Este acercamiento también permite que se migren estos datos en el futuro como parte de un proceso de migración con mayor fidelidad.

El escaneo de secretos ahora está disponible en GitHub Enterprise Server 3.1+. Escanea repositorios públicos y privados para las credenciales confirmadas, encuentra secretos y notifica al proveedor de secretos o administrador en el momento en el que se confirmen en un repositorio.

Este lanzamiento incluye varias mejoras desde la beta del escaneo de secretos en GitHub Enterprise Server:

• Expandimos nuestra cobertura de patrones de 24 socios a 37
• Agregamos una API y webhooks
• Agregamos notificaciones para autores de confirmaciones cuando confirman secretos
• Actualizamos la vista del índice para que sea más fácil clasificar los secretos por lote
• Reducimos la tasa de falsos positivos en varios patrones

Los administradores que utilicen la GitHub Advanced Security pueden habilitar y configurar el escaneo de secretos de GitHub Advanced Security. Puedes revisar los requisitos mínimos actualizados para tu plataforma antes de que habilites el escaneo de secretos de la GitHub Advanced Security.

Este lanzamiento incluye varias mejoras a la facturación de la GitHub Advanced Security en GitHub Enterprise Server:

• Los clientes de la GitHub Advanced Security ahora pueden ver su conteo de confirmantes activos y la cantidad de plazas de confirmante sin utilizar restantes en la página de facturación de sus cuentas de organización o de empresa. Si se compra la Seguridad Avanzada para una empresa, los administradores también pueden ver las plazas de confirmantes activos que utilizan otras organizaciones dentro de sus empresas. Para obtener más información, consulta las secciones "Acerca del licenciamiento de la Seguridad Avanzada de GitHub" y "Visualizar tu uso de la Seguridad Avanzada de GitHub."
• Los clientes de la Seguridad Avanzada de GitHub ahora pueden ver su conteo de confirmantes activos en la página de facturación de su cuenta de empresa u organización para cualquier repositorio que tenga habilitada la Seguridad Avanzada. Estos cambios ayudan a los administradores de facturación a rastrear su uso contra la cantidad de licencias de confirmante que compraron. Para obtener más información, consulta la sección "Administrar la configuración de análisis y seguridad de tu organización".

Este lanzamiento incluye mejoras a las alertas del Dependabot en GitHub Enterprise Server:

• Los usuarios que habiliten las alertas del Dependabot pueden ver cuáles de sus repositorios tienen impacto de alguna vulnerabilidad si navegan a su entrada en la Base de Datos de Asesorías de GitHub. Esta característica está disponible como beta público. Para obtener más información, consulta la sección "Visualizar y actualizar las dependencias vulnerables de tu repositorio."
• Cuando se agrega una vulnerabilidad a la Base de Datos de GitHub, ya no recibirás notificaciones web y por correo electrónico para las alertas del dependabot que traten con vulnerabilidades de severidad baja y moderada. Podrás acceder aún a estas alertas desde la pestaña de Seguridad del repositorio. Para obtener más información, consulta la sección "Visualizar y actualizar las dependencias vulnerables de tu repositorio."
• Ahora puedes dar instrucciones a las personas para que sepan cómo reportar responsablemente las vulnerabilidades de seguridad en tu proyecto agregando un archivo de SECURITY.md a la carpeta root, docs, o .github de tu repositorio. Cuando alguien crea una propuesta en tu repositorio, vera un enlace hacia la política de seguridad de tu proyecto. Para obtener más información, consulta la sección "Agregar una política de seguridad a tu repositorio."

Las GitHub Actions ahora pueden generar una gráfica visual de tu flujo de trabajo en cada ejecución. Con la visualización de flujos de trabajo puedes: -Ver y entender flujos de trabajo complejos -Rastrear el progreso de los flujos de trabajo en tiempo real -Solucionar problemas en las ejecuciones rápidamente accediendo con facilidad a las bitácoras y los metadatos de los jobs -Monitorear el progreso de los jobs de despliegue y acceder fácilmente a los objetivos de despliegue

Para obtener más información, consulta la sección "Utilizar la gráfica de visualización".

El Otorgamiento de Autorización de Dispositivos OAuth 2.0 permite que cualquier cliente de CLI o herramienta de desarrollador se autentique utilizando un sistema secundario con un buscador.

Los administradores que utilizan Apps de OAuth y GitHub Apps pueden habilitar y configurar el Flujo de Autorizaciones de Dispositivos OAuth 2.0 adicionalmente al Flujo de Aplicaciones web existente. Puedes revisar los requisitos mínimos actualizados de tu plataforma antes de que habilites el Flujo de Autorizaciones de Dispositivos OAuth 2.0.

Con la fusión automática, las solicitudes de cambios pueden configurarse para fusión automática cuando se haya cumplido con todos los requisitos de fusión. Esto les ahorra a los usuarios la necesidad de verificar constantemente el estado de sus solicitudes de cambio para poderlas fusionar. Los usuarios pueden habilitar la fusión automática si tienen permiso para fusionar y en las solicitudes de cambio que no hayan cumplido con los requisitos de fusión. Para obtener más información, consulta la sección "Fusionar las solicitudes de cambios automáticamente".

Puedes personalizar los tipos de notificaciones que quieres recibir de repositorios individuales. Para obtener más información, consulta la sección "Configurar las notificaciones".

El filtrado con GitHub Móvil te permite buscar y encontrar propuestas, solicitudes de cambio y debates desde tu dispositivo. Los metadatos nuevos para los elementos de lista de las propuestas y solicitudes de cambio te permiten filtrar por asignados, estado de verificación, estados de revisión y conteo de comentarios.

GitHub Móvil beta está disponible para GitHub Enterprise Server. Inicia sesión con nuestras apps para Android y iOS para clasificar las notificaciones y administrar las propuestas y solicitudes de cambio al momento. Los administradores pueden inhabilitar la compatibilidad móvil para sus empresas utilizando la consola de administración o ejecutando ghe-config app.mobile.enabled false. Para obtener más información, consulta la sección "GitHub Móvil".

Al precalcular las comprobaciones, la cantidad de tiempo en el que un repositorio está bajo llave se reduce drásticamente, lo cual permite que más operaciones de escritura tengan éxito inmediatamente y mejora el desempeño de mono-repositorio.

El último lanzamiento del CLI de CodeQL es compatible con subir los resultados del análisis a GitHub. esto facilita ejecutar el análisis de código para los clientes que quieran utilizar sistemas de IC/DC diferentes a los de GitHub Actions. Anteriormente, estos usuarios tenían que utilizar un ejecutor de CodeQL por separado, el cual aún estará disponible. Para obtener más información, consulta la sección Acerca del escaneo de código de CodeQL en tu sistema de IC".

GitHub Actions es ahora compatible con saltar los flujos de trabajo de tipo push y pull_request si se buscan las palabras clave en común dentro de tu mensaje de confirmación.

Se archivará las anotaciones de verificación más antiguas a cuatro meses.

Se revisó el escalamiento de la asignación de trabajadores para tareas en segundo plano. Recomendamos validar que los predeterminados nuevos sean adecuados para tu carga de trabajo. Las anulaciones de trabajador personalizado en segundo plano deben inhabilitarse en la mayoría de los casos. [Actualizado al 2022-03-18]

Siguiendo la retroalimentación, seguirá habiendo compatibilidad para mostrar los resultados del escaneo de código en una solicitud de cambios sin emitirlos con una ID de esta. Para obtener más información, consulta las secciones "Configurar el escaneo de código" y "Configurar el escaneo de código de CodeQL en tu sistema de IC.

La compatibilidad de carga de SARIF aumentó a un máximo de 5000 resultados por carga.

Puedes especificar URL de rellamado múltiples al configurar una GitHub App. Esto se puede utilizar en servicios con dominios o subdominios múltiples. GitHub siempre negará la autorización si la URL de rellamado de la solicitud no está en la lista de autorización de URL de rellamado.

El permiso de archivos de GitHub App se actualizó para permitir que un desarrollador de apps especifique hasta 10 archivos para acceso de solo lectura o de lectura y escritura a los que su app puede solicitar acceso.

Ahora, CodeQL es compatible con más bibliotecas y marcos de trabajo para diversos lenguajes como (C++, JavaScript, Python,Java, Go). El motor de CodeQL ahora puede detectar más fuentes de datos no confiables de usuario, lo cual mejora la calidad y profundidad de las alertas de escaneo de código. Para obtener más información, consulta la sección "Acerca de CodeQL".

Cuando configuras una GitHub App, la URL de rellamado de autorización es un campo requerido. Ahora, permitimos que el desarrollador especifique varias URL de rellamado. Esto puede utilizarse en servicios con varios dominios o subdominios. GitHub siempre negará la autorización si la URL de rellamado de la solicitud no está en la lista de autorización de la URL de rellamado.

Borra un directorio de archivos completo, incluyendo los subdirectorios, desde tu buscador web. Para obtener más información, consulta la sección "Borrar un archivo o directorio".

Incluye palabras múltiples después del # en una propuesta, debate o comentario de solicitud de cambios para restringir aún más tu búsqueda.

Cuando estás escribiendo una propuesta, solicitud de cambios o comentario de debate, la sintaxis de la lista para las viñetas, númeras y tareas se autocompleta después de que tecleas return o enter.

La API del escaneo de código permite a los usuarios cargar datos sobre los resultados de la spruebas del análisis de seguridad estático o exportar datos sobre las alertas. Para obtener más información, consulta la referencia a la API del escaneo de código.

La API de GitHub Apps para administrar las instalaciones ahora se graduó de una vista previa de la API a una API de disposición general. Ya no se necesita el Encabezado de vista previa para acceder a estas terminales.

MEDIA Bajo ciertas circunstancias, los usuarios que se eliminaron de un equipo u organización pdorían retener el acceso de escritura a las ramas en las cuales tenían solicitudes de cambio existentes abiertas.

Los paquetes se actualizaron a las últimas versiones de seguridad.

Se han arreglado todas las propuestas conocidas del candidato a lanzamiento 1, con excepción de aquellas que se listan en la sección de propuestas conocidas, a continuación.

En la página de "Configurar acciones y paquetes" del proceso de instalación inicial, el hacer clic en el botón de "Probar los ajustes del dominio" no completó la prueba.

El ejecutar ghe-btop falló con un error y no pudo encontrar un contenedor babeld.

MySQL podría recargarse y causar inactividad si cambias la configuración de recuperación de fallos automática.

Después de hacer la mejora, un desajuste de los valores de tiempo de espera internos y externos crearon la indisponibilidad del servicio.

Los retrasos de replicación esperados en MSSQL generaron advertencias.

El enlace a "Configurar el agrupamiento en clústers" e la consola de administración era incorrecto.

Cuando creas o editas un gancho de pre-recepción, una condición de carrera en la interface de usuario significa que, después de seleccionar un repositorio, los archivos dentro de este alguna vez no se llenaron en el menú desplegable de los archivos.

Cuando se agrega una dirección IP a la lista blanca utilizando el botón "Create Whitelist Entry", aún podría mostrarse como bloqueada.

Las referencias a las características de la "Gráfica de dependencias" y "Alertas del Dependabot" no se mostraron como inhabilitadas en algunos repositorios.

El configurar un anuncio en la configuración de la cuenta empresarial resultó en un error de tipo "500 Internal Server".

Las solicitudes de POST por HTTP en la terminal de /hooks podría fallar con una respuesta 401 debido a una hookID configurada incorrectamente.

El proceso build-server falló en limpiar los procesos, dejándolos en estado defunct.

spokesd creó entradas de bitácora excesivas, incluyendo la frase "fixing placement skipped".

Mientras se mejoraban las acciones, dicha mejora falló si la instancia no pudo hacer auto-solicitudes a través de el nombre de host configurado.

Actualizar de la versión 2.22.x a la 3.1.0.rc1 dio como resultado un error de migración de la base de datos relacionado con la transición de datos BackfillIntegrationApplicationCallbackUrlsTransition.

Demoraremos en tener acceso a un repositorio a través del shell administrativo utilizando ghe-repo <owner>/<reponame>. Como medida alterna, utilizaremos ghe-repo <owner>/<reponame> -c "bash -i" hasta que tengamos disponible una solución en la siguiente versión.

El registor de npm del Registro del paquete de GitHub ya no regresa un valor de tiempo en las respuestas de metadatos. Esto se hizo para permitir mejoras de rendimiento sustanciales. Seguimos teniendo todos los datos necesarios para devolver un valor de tiempo como parte de la respuesta de metadatos y terminaremos de devolver este valor ene l futuro una vez que hayamos resuelto los problemas de rendimiento existentes.

En una instalación nueva de GitHub Enterprise Server que no tenga ningún usuario, cualquier atacante podría crear el primer usuario administrativo.

Las reglas personalizadas del cortafuegos no se mantienen durante una mejora.

Los archivos rastreados del LFS de Git que se cargaron mediante la interface web se agregaron incorrecta y directamente al repositorio.

Las propuestas no pudieron cerrarse si contenían un permalink a un blob en el mismo repositorio en donde la ruta de archvio era más grande a 255 caracteres.

Cuando se habilita "Los usuarios pueden buscar en GitHub.com" con GitHub Connect, las propuestas en los repositorios privados e internos no se incluirán en los resultados de búsqueda de GitHub.com.

El actualizar una instancia que ejecuta un lanzamiento 2.13 previamente, pero no uno de tipo 2.14, da como resultado un error de migración de base de datos que se relacionaba con la transición de datos AddRepositoryIdToCheckRuns.

Después de actualizar de la versión 3.0.x a la 3.1.x, en algunos casos, puede que GitHub actions falle con un error de tipo: An unexpected error occurred when executing this workflow. Para solucionar este problema, conéctate al shell administrativo (ssh) y ejecuta:

ghe-actions-console -s actions -c "Queue-ServiceJob -JobId 4DB1F4CF-19FD-40E0-A253-91288813DE8B"

Cuando un nodo de réplica está fuera de línea en una configuración de disponibilidad alta, GitHub Enterprise Server aún podría enrutar las solicitudes a Páginas de GitHub para el nodo fuera de línea, reduciendo la disponibilidad de Páginas de GitHub para los usuarios.

Los límites de recursos que son específicos para procesar ganchos de pre-recepción podrían ocasionar que fallen algunos ganchos de pre-recepción.

GitHub Enterprise Server 2.20 se descontinuó el 2 de marzo de 2021. Esto significa que no se harán lanzamientos de parche, aún para los problemas de seguridad crítucos, después de esta fecha. Para obtener un rendimiento mejor, una seguridad mejorada y características nuevas, actualiza a la última versión de GitHub Enterprise Server tan pronto te sea posible.

GitHub Enterprise Server 2.21 se descontinuará el 9 de junio de 2021. Esto significa que no se harán lanzamientos de parche, aún para los problemas de seguridad crítucos, después de esta fecha. Para obtener un rendimiento mejor, una seguridad mejorada y características nuevas, actualiza a la última versión de GitHub Enterprise Server tan pronto te sea posible.

Comenzando con GitHub Enterprise Server 2.21.0, dos eventos de webhook relacionados con GitHub Apps se obsoletizaron y eliminaron en la versión 3.2.0 de GitHub Enterprise Server. Los eventos obsoletizados de integration_installation and integration_installation_repositories tienen eventos equivalentes que serán compatibles. Puedes encontrar más información en la publicación del blog acerca de los anuncios de obsoletización.

Comenzando con GitHub Enterprise Server 2.21.0, la terminal tradicional de GitHub Apps para crear tokens de acceso a las instalaciones se obsoletizó y se eliminará en la versión 3.2.0 de GitHub Enterprise Server. Puedes encontrar más información disponible en la publicación del blog sobre los anuncios de obsoletización.

GitHub ya no es compatible con las terminales de la aplicación de OAuth que contengan access_token como parámetro de ruta. Hemos incluído terminales nuevas que te permiten administrar los tokens para las apps de OAuth de forma segura al mover a access_token al cuerpo de solicitud. Aunque se hayan obsoletizado, aún se puede acceder a las terminales en esta versión. Intentamos eliminar estas terminales en la versión 3.4 de GitHub Enterprise Server. Para obtener más información, consulta la publicación del blog sobre los anuncios de obsoletización.

GitHub Actions eliminará la compatibilidad para referenciar las acciones utilizando la versión corta del SHA de las confirmaciones de git. Esto podría causar que fallen algunos flujos de trabajo en tu repositorio. Para arreglar estos flujos de trabajo, necesitarás actualizar la referencia de la acción para utilizar el SHA de confirmación completo. Para obtener más información, consulta la sección "Fortalecimiento de seguridad para las GitHub Actions".

Desde GitHub Enterprise Server 3.1, comenzaremos a descontinuar el soporte par Xen Hypervisor. La obsoletización completa está programada para GitHub Enterprise Server 3.3, siguiendo la ventana de obsoletización estándar de un año.

GitHub Connect ya no funcionará después del 3 de junio para las instancias que ejecuten GitHub Enterprise Server 3.1 o anterior, debido al cambio en el formato de los tokens de autenticación de GitHub. Para seguir utilizando GitHub Connect, mejora a GitHub Enterprise Server 3.2 o posterior. Para obtener más información, consulta el Blog de GitHub. [Actualizado: 2022-06-14]