Enterprise Server 3.2 release notes

CRITICAL: GitHub Enterprise Server's Elasticsearch container used a version of OpenJDK 8 that was vulnerable to an integer truncation issue when processing malicious XSLT stylesheets. The vulnerability is tracked as CVE-2022-34169.

HIGH: Previously installed apps on user accounts were automatically granted permission to access an organization on scoped access tokens after the user account was transformed into an organization account. This vulnerability was reported via the GitHub Bug Bounty program.

When a custom dormancy threshold was set for the instance, suspending all dormant users did not reliably respect the threshold. For more information about dormancy, see "Managing dormant users."

MEDIA: Previene un ataque en donde la falsificación de solicitudes de lado del servidor (SSRF) pudiera forzar potencialmente el puente de Subversion (SVN) para ejecutar código remoto inyectando datos arbitrarios en memcached.

Actualiza Grafana a la versión 7.5.16, lo cual trata varias vulnerabilidades de seguridad, incluyendo el CVE-2020-13379 y el CVE-2022-21702.

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

Se corrigió un problema en donde los archivos dentro de los archivos zip de los artefactos tenían permisos de 000 cuando se desempacaban utilizando una herramienta de descompresión. Ahora los archivos tenían el permiso configurado en 644, de la misma forma que funciona en GitHub.com.

En algunos casos, el demonio de collectd pudo haber consumido memoria excesiva.

En algunos casos, los respaldos de los archivos de bitácora rotados pudieron haber acumulado y consumido un almacenamiento excesivo.

Después de actualizar a un lanzamiento de característica nuevo y a una ejecución de configuración posterior, Elastichsearch pudo haber registrado excepciones excesivas de bitácoras mientras recompilaba los índices.

En algunos casos en donde una rama protegida requirió más de una revisión de aprobación, se pudo haber fusionado una solicitud de cambios con una cantidad menor de revisiones de aprobación que la requerida.

En las instancias que utilizan autenticación de LDAP, el mensaje de autenticación para modo sudo colocó incorrectamente el cursor dentro del campo de contraseña predeterminadamente cuando los campos de texto tanto para el nombre de usuario como par ala contraseña estaban visibles.

La utilidad de línea de comandos ghe-set-password inicia automáticamente los servicios requeridos cuando la instancia se arranca en modo de recuperación.

Las métricas para los procesos en segundo plano de aqueduct se otorgan para el reenvío de Collectd y se muestran en la consola de administración.

La ubicación de la bitácora de ejecución de migración y configuración, /data/user/common/ghe-config.log, ahora se muestra en la página que describe una migración en curso.

MEDIA: Se asegura que github.company.com y github-company.com no se evalúen por los servicios internos como nombres de host idénticos, previniendo un ataque potencial de falsificación de seguridad del lado del servidor (SSRF).

BAJA: Un atacante pudo acceder a la consola de administración con un ataque de recorrido de ruta a través de HTTP, incluso si las reglas de cortafuegos externo bloqueaban el acceso HTTP.

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

En algunos casos, los administradores de sitio no se agregaron automáticamente como propietarios de empresa.

Después de fusionar una rama en la rama predeterminada, el enlace de "Historial" de un archivo aún enlazaba con la rama anterior en vez de con la rama destino.

El crear o actualizar ejecuciones de verificación o suites de verificación pudo devolver un 500 Internal Server Error si el valor para campos específicos, como el de nombre, era demasiado largo.

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

Un script interno para validar nombres de host en el archivo de configuración de GitHub Enterprise Server devolvió un error cuando la secuencia de nombre de host iniciaba con un "." (punto).

En las configuraciones de disponibilidad alta en donde el nombre de host del nodo primario fue mayor a 60 caracteres, MySQL no se pudo configurar.

El argumento --gateway se agergó al comando ghe-setup-network, para permitir que pasara la dirección de puerta de enlace al configurar los ajustes de red utilizando la línea de comandos.

Las imágenes adjuntas que se borraron devolvieron un 500 Internal Server Error en vez de un 404 Not Found.

El cálculo de "Cantidad máxima de confirmantes en toda la instancia" que se reportó en el tablero de administrador de sitio fue incorrecto.

Una entrada incorrecta en la base de datos para las réplicas de repositorio ocasionó que dicha base de datos se corrompiera al realizar una restauración utilizando Utilidades de respaldo del servidor de GitHub Enterprise.

Se optimizó la inclusión de las métricas cuando se generó un paquete de soporte de clúster.

En las configuraciones de disponibilidad alta en donde Elasticsearch reportó un estado amarillo válido, los cambios que se introdujeron en una corrección previa bloquearon el comando ghe-repl-stop y no permitieron que la replicación se detuviera. El utilizar ghe-repo-stop --force ahora forzará a Elasticsearch a detenerse cuando el servicio está en un estado amarillo válido o normal.

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.

Los videos que se suben a los comentarios de las propuestas no se representaron adecuadamente.

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

Al utilizar ghe-migrator, una migración falló en importar los archivos de video adjuntos en las propuestas y solicitudes de cambios.

La página de lanzamientos devolvió un error 500 cuando el repositorio tuvo etiquetas que contenían caracteres diferentes a los de ASCII. [Actualizado: 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.

Cuando habilites el Registro del paquete de GitHub, aclara que, actualmente, no hay compatibilidad con utilizar el token de Firma de Acceso Compartida (SAS, por sus siglas en inglés) como secuencia de conexión.

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

Dependency Graph can now be enabled without vulnerability data, allowing you to see what dependencies are in use and at what versions. Enabling Dependency Graph without enabling GitHub Connect will not provide vulnerability information.

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.

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.

Creating an impersonation OAuth token using the Enterprise Administration REST API worked incorrectly when an integration matching the OAuth Application ID already existed.

Los errores de configuración que detienen una ejecución de aplicación de configuraciones ahora son el producto de la terminal adicionalmente a la bitácora de configuración.

Al intentar almacenar en caché un valor que fuera más grande que el máximo permitido en Memcached, se levantó un error pero la clave no se reportó.

The CodeQL starter workflow no longer errors even if the default token permissions for GitHub Actions are not used.

Si se habilitaron las características de GitHub Advanced Security en tu instancia, el rendimiento de los jobs en segundo plano mejoró al procesar los lotes para las contribuciones de repositorio.

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.

Los procesos de Minio tuvieron un uso alto de CPU si una opción de configuración estuvo presente después de mejorar a GitHub Enterprise Server.

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.

En las configuraciones de disponibilidad alta, el derribar una réplica falló si se había habilitado GitHub Actions previamente.

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.

Cuando utilizas ghe-migrator o exportas desde GitHub.com, una exportación de duración larga falló cuando se borraron datos a media exportación.

La gráfica de despliegue de GitHub Actions mostró un error al procesar un job pendiente.

Se eliminaron los enlaces a las páginas inaccesibles.

El navegar fuera de una comparación de dos confirmaciones en la IU web tuvo una persistencia de diff en otras páginas.

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

La terminal de la API de Eliminar membrecía de equipo para un usuario respondió con un error al intentar eliminar a un miembro que se administra externamente mediante un grupo de SCIM.

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.

El comando spokesctl cache-policy rm ya no falla con el mensaje de error: failed to delete cache policy.

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.

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.

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.

Fue posible que un usuario registrara a otro o a una organización de nombre "saml".

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

Los ajustes de almacenamiento de GitHub Packages no pudieron validarse y guardarse en la consola de administración cuando se utilizó Azure Blob Storage.

La opción de configuración mssql.backup.cadence falló el ghe-config-check con una advertencia de conjunto de caracteres inválidos.

Corrige SystemStackError (se apilaron demasiado profundamente) al obtener más de 2^{^16} llaves del memcached.

EL escaneo de secretos dejará de escanear los archivos ZIP y de otros tipos en búsqueda de secretos.

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.

Las migraciones pudieron haber fallado cuando se habilitó GitHub Actions.

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 ejecutó desde la principal, ghe-repl-teardown en una réplica no la eliminó del grupo de disponibilidad de MSSQL.

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.

Una migración de base de datos de duración larga relacionada con los ajustes de Alertas de Seguridad pudo haber retrasado la finalización de la mejora.

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.

Los ejecutores auto-hospedados de las acciones fallaron en actualizarse a sí mismos o en ejecutar jobs nuevos después de mejorar desde una instalación anterior de la GHES.

Los ajustes de almacenamiento no pudieron validarse al configurar MinIO como almacenamiento de blobs para GitHub Packages.

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.

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

Critical: A remote code execution vulnerability in the Log4j library, identified as CVE-2021-44228, affected all versions of GitHub Enterprise Server prior to 3.3.1. The Log4j library is used in an open source service running on the GitHub Enterprise Server instance. This vulnerability was fixed in GitHub Enterprise Server versions 3.0.22, 3.1.14, 3.2.6, and 3.3.1. For more information, please see this post on the GitHub Blog.

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ó mediante el programa de Recompensas por Errores de GitHub y se le asignó el CVE-2021-41599. Actualizado el 17 de febrero de 2022.

En algunos casos cuando las acciones no se habilitaron, ghe-support-bundle reportó un mensaje inesperado de Unable to find MS SQL container.

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 migraciones podrían haberse atorado debido a un manejo incorrecto de los valores de blob_path que no son compatibles con UTF-8.

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

Los enlaces de paginación en las bitácoras de auditoría de la organización no persistirán los parámetros de consulta.

Durante un hotpatch, fue posible duplicar los hashes si la transición se ejecutó más de una vez.

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.

Se proporcionó una solución de problemas adicional al ejecutar ghe-mssql-diagnostic.

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.

El ejecutrar ghe-support-bundle devolvió un error de tipo: integer expression expected.

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.

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

La conexión de childTeams en el objeto Team en el modelo de GraphQL produjo resultados incorrectos bajo algunas de las circunstancias.

En una configuración de disponibilidad alta, el mantenimiento de repositorio siempre se mostró como fallido en las stafftools, incluso cuando tuvo éxito.

Los patrones definidos por el usuario no detectaron secretos en archivos como package.json o yarn.lock.

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.

El mejorar de GitHub Enterprise Server 2.x a 3.x falló cuando hubieron caracteres UTF8 en una configuración de 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.

El enlace a la documentación de las estadísticas de servidor estuvo roto.

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.

No hubo un tiempo límite del job suficiente para las reparaciones de la réplica.

Una página de lanzamientos de un repositorio devolvió un error 500 al ver los lanzamientos.

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.

Los repositorios públicos mostraron resultados inesperados del escaneo de secretos con un tipo de Unknown Token.

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 pudo haber fallado para el servidor empresarial en modo de clústering si el orquestador no estaba saludable.

Los enlaces de los codespaces se mostraron en los ajustes de la organización.

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

Se arregló 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.

En una configuración de clústering de GitHub Enterprise Server, los ajustes de la Gráfica de Dependencias pudieron haberse aplicado incorrectamente.

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.

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

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.

El utilizar la API para inhabilitar el escaneo de secretos correctamente inhabilitó la propiedad pero devolvió un HTTP 422 incorrectamente y un mensaje de error.

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.

Un patrón definido por el usuario creado para el escaneo de secretos siguió siendo escaneado, incluso después de haberse borrado.

Las GitHub Apps ahora configuran la característica de escaneo de secretos en un repositorio consistentemente con la API.

GitHub Advanced Security customers can now specify custom patterns for secret scanning. When a new pattern is specified, secret scanning searches a repository's entire Git history for the pattern, as well as any new commits.

User defined patterns are in beta for GitHub Enterprise Server 3.2. They can be defined at the repository, organization, and enterprise levels. For more information, see "Defining custom patterns for secret scanning."

GitHub Advanced Security customers now have an organization-level view of the application security risks detected by escaneo de código, Dependabot, and escaneo de secretos. The security overview shows the enablement status of security features on each repository, as well as the number of alerts detected.

In addition, the security overview lists all escaneo de secretos alerts at the organization level. Similar views for Dependabot and escaneo de código alerts are coming in future releases. For more information, see "About the security overview."

GitHub Advanced Security customers can now see a rich diff of the dependencies changed in a pull request. Dependency review provides an easy-to-understand view of dependency changes and their security impact in the "Files changed" tab of pull requests. It informs you of which dependencies were added, removed, or updated, along with vulnerability information for these dependencies. For more information, see "Reviewing dependency changes in a pull request."

Environments, environment protection rules, and environment secrets are now generally available for GitHub Actions on GitHub Enterprise Server. For more information, see "Environments."

SSH authentication using a FIDO2 security key is now supported when you add a sk-ecdsa-sha2-nistp256@openssh.com or sk-ssh-ed25519@openssh.com SSH key to your account. SSH security keys store secret key material on a separate hardware device that requires verification, such as a tap, to operate. For more information, see "Generating a new SSH key and adding it to the ssh-agent."

Dark and dark dimmed themes are now available for the web UI. GitHub Enterprise Server will match your system preferences when you haven't set theme preferences in GitHub Enterprise Server. You can also choose which themes are active during the day and night. For more information, see "Managing your theme settings."

Domains that are not able to be verified can now be approved for email notification routing. Enterprise and organization owners will be able to approve domains and immediately augment their email notification restriction policy, allowing notifications to be sent to collaborators, consultants, acquisitions, or other partners. For more information, see "Verifying or approving a domain for your enterprise" and "Restricting email notifications for your enterprise."

Git Credential Manager (GCM) versions 2.0.452 and later now provide security-hardened credential storage and multi-factor authentication support for GitHub Enterprise Server.

GCM with support for GitHub Enterprise Server is included with Git for Windows versions 2.32 and later. GCM is not included with Git for macOS or Linux, but can be installed separately. For more information, see the latest release and installation instructions in the GitCredentialManager/git-credential-manager repository.

A 'User Agent Referrer Policy' setting has been added to the enterprise settings. This allows an admin to set a stricter Referrer-Policy to hide the hostname of a GitHub Enterprise Server installation from external sites. The setting is disabled by default and is tracked by audit log events for staff and enterprise owners when enabled or disabled. For more information, see "Configuring Referrer Policy for your enterprise."

The MySQL health check was changed to use mysqladmin ping instead of TCP checks, which removes some unnecessary noise in the MySQL error log. Also, Orchestrator failover checks were improved to prevent unnecessary MySQL failovers when applying cluster config changes.

The Resque service, which supports background job processing, has been replaced with Aqueduct Lite. This change makes the job system easier to manage and should not affect the user experience. For the new administration and debugging commands for Aqueduct, see "Command-line utilities."

The format of authentication tokens for GitHub Enterprise Server has changed. The change affects the format of personal access tokens and access tokens for OAuth Apps, as well as user-to-server, server-to-server, and refresh tokens for GitHub Apps.

The different token types now have unique identifiable prefixes, which allows for secret scanning to detect the tokens so that you can mitigate the impact of someone accidentally committing a token to a repository. GitHub recommends updating existing tokens as soon as possible. For more information, see "About authentication to GitHub" and "About escaneo de secretos."

Repositories on user profiles and organization profiles now support sorting by star count.

When viewing the commit history of a single file, you can now click to view that file at the selected point in history.

When a submodule is defined with a relative path in tu instancia de GitHub Enterprise Server, the submodule is now clickable in the web UI. Clicking the submodule in the web UI will take you to the linked repository. Previously, only submodules with absolute URLs were clickable. This is supported for relative paths for repositories with the same owner that follow the pattern ../REPOSITORY or relative paths for repositories with a different owner that follow the pattern ../OWNER/REPOSITORY. For more information about working with submodules, see Working with submodules on el blog de GitHub.

The web UI can now be used to synchronize an out-of-date branch of a fork with the fork's upstream branch. If there are no merge conflicts between the branches, the branch is updated either by fast-forwarding or by merging from upstream. If there are conflicts, you will be prompted to create a pull request to resolve the conflicts. For more information, see "Syncing a fork."

The markdown editor used when creating or editing a release in a repository now has a text-editing toolbar. For more information, see "Managing releases in a repository."

Uploading video files is now supported everywhere you write Markdown on GitHub Enterprise Server. Share demos, reproduction steps, and more in your issue and pull request comments, as well as in Markdown files within repositories, such as READMEs. For more information, see "Attaching files."

Markdown files will now automatically generate a table of contents in the header when there are 2 or more headings. The table of contents is interactive and links to the selected section. All 6 Markdown heading levels are supported.

There is a new keyboard shortcut, cmd+e on macOS or ctrl+e on Windows, to insert codeblocks in Markdown files, issues, pull requests, and comments.

Appending ?plain=1 to the URL for any Markdown file will now display the file without rendering and with line numbers. The plain view can be used to link other users to specific lines. For example, appending ?plain=1#L52 will highlight line 52 of a plain text Markdown file. For more information, "Creating a permanent link to a code snippet."

With the latest version of Octicons, the states of issues and pull requests are now more visually distinct so you can scan their status more easily. For more information, see el blog de GitHub.

A new "Require conversation resolution before merging" branch protection rule and "Conversations" menu is now available. Easily discover your pull request comments from the "Files changed" tab, and require that all your pull request conversations are resolved before merging. For more information, see "About pull request reviews" and "About protected branches."

To prevent the merge of unexpected changes after auto-merge is enabled for a pull request, auto-merge is now disabled automatically when new changes are pushed by a user without write access to the repository. Users without write access can still update the pull request with changes from the base branch when auto-merge is enabled. To prevent a malicious user from using a merge conflict to introduce unexpected changes to the pull request, auto-merge for the pull request is disabled if the update causes a merge conflict. For more information about auto-merge, see "Automatically merging a pull request."

People with maintain permissions can now manage the repository-level "Allow auto-merge" setting. This setting, which is off by default, controls whether auto-merge is available on pull requests in the repository. Previously, only people with admin permissions could manage this setting. Additionally, this setting can now by controlled using the "Create a repository" and "Update a repository" REST APIs. For more information, see "Managing auto-merge for pull requests in your repository."

The assignees selection for issues and pull requests now supports type ahead searching so you can find users in your organization faster. Additionally, search result rankings have been updated to prefer matches at the start of a person's username or profile name.

When a review is requested from a team of more than 100 people, developers are now shown a confirmation dialog box in order to prevent unnecessary notifications for large teams.

Back-tick code blocks are now supported in issue titles, pull request titles, and in any place issue and pull request titles are referenced in GitHub Enterprise Server.

Events for pull requests and pull request reviews are now included in the audit log for both enterprises and organizations. These events help admins better monitor pull request activity and help ensure security and compliance requirements are being met. Events can be viewed from the web UI, exported as CSV or JSON, or accessed via REST API. You can also search the audit log for specific pull request events. For more information, see "Reviewing the audit log for your organization."

The default branch name for new repositories is now main. Existing repositories are not impacted by this change. If users, organization owners, or enterprise owners have previously specified a default branch for new repositories, they are also not impacted.

If you want to set a different default branch name, you can do so in the user, organization, or enterprise settings.

Branches, including the default branch, can now be renamed using the the GitHub Enterprise Server web UI. When a branch is renamed, any open pull requests and draft releases targeting the renamed branch will be retargeted automatically, and branch protection rules that explicitly reference the renamed branch will be updated.

Admin permissions are required to rename the default branch, but write permissions are sufficient to rename other branches.

To help make the change as seamless as possible for users:

• A notice is shown to contributors, maintainers, and admins on the repository homepage with instructions for updating their local repository.
• Web requests to the old branch will be redirected.
• A "moved permanently" HTTP response will be returned to REST API calls.
• An informational message is displayed to Git command line users that push to the old branch.

For more information, see "Renaming a branch."

GitHub Actions now lets you control the permissions granted to the GITHUB_TOKEN secret. The GITHUB_TOKEN is an automatically-generated secret that lets you make authenticated calls to the API for GitHub Enterprise Server in your workflow runs. GitHub Actions generates a new token for each job and expires the token when a job completes. The token usually has write permissions to a number of API endpoints, except in the case of pull requests from forks, which are always read. These new settings allow you to follow a principle of least privilege in your workflows. For more information, see "Authentication in a workflow."

CLI de GitHub 1.9 and later allows you to work with GitHub Actions in your terminal. For more information, see the GitHub changelog.

The audit log now includes events associated with GitHub Actions workflow runs. This data provides administrators with a greatly expanded data set for security and compliance audits. For more information, see "Reviewing the audit log for your organization."

GitHub Enterprise Server 3.2 contains performance improvements for job concurrency with GitHub Actions. For more information about the new performance targets for a range of CPU and memory configurations, see "Getting started with GitHub Actions for GitHub Enterprise Server."

• The "Maximum Concurrency" values were modified to reflect our most up to date performance testing. [Updated: 2021-12-07]

The GitHub Actions Runner application in GitHub Enterprise Server 3.2 has been updated to v2.279.0.

Any package or package version for Registro del paquete de GitHub can now be deleted from GitHub Enterprise Server's web UI. You can also undo the deletion of any package or package version within 30 days. For more information, see "Deleting and restoring a package".

The dependency graph can now be enabled using the Management Console, rather than needing to run a command in the administrative shell. For more information, see "Enabling alerts for vulnerable dependencies GitHub Enterprise Server."

Notifications for multiple Las alertas del dependabot are now grouped together if they're discovered at the same time. This significantly reduces the volume of Dependabot alert notifications that users receive. For more information, see the GitHub changelog.

Dependency graph and Las alertas del dependabot now support Go modules. GitHub Enterprise Server analyzes a repository's go.mod files to understand the repository’s dependencies. Along with security advisories, the dependency graph provides the information needed to alert developers to vulnerable dependencies. For more information about enabling the dependency graph on private repositories, see "Securing your repository."

The default notification settings for security alerts have changed. Previously, if you had permission to view security alerts in a repository, you would receive notifications for that repository as long as your settings allowed for security alert notifications. Now, you must opt in to security alert notifications by watching the repository. You will be notified if you select All Activity or configure Custom to include Security alerts. All existing repositories will be automatically migrated to these new settings and you will continue to receive notifications; however, any new repositories will require opting-in by watching the repository. For more information see "Configuring notifications for Las alertas del dependabot" and "Managing alerts from secret scanning."

Escaneo de código with CodeQL now generates diagnostic information for all supported languages. This helps check the state of the created database to understand the status and quality of performed analysis. The diagnostic information is available starting in version 2.5.6 of the CodeQL CLI. You can see the detailed diagnostic information in the GitHub Actions logs for CodeQL. For more information, see "Viewing code scanning logs."

Escaneo de código with CodeQL CLI now supports analyzing several languages during a single build. This makes it easier to run code analysis to use CI/CD systems other than GitHub Actions. The new mode of the codeql database create command is available starting version 2.5.6 of the CodeQL CLI. For more information about setting this up, see "Installing CodeQL CLI in your CI system."

Escaneo de código alerts from all enabled tools are now shown in one consolidated list, so that you can easily prioritize across all alerts. You can view alerts from a specific tool by using the "Tool" filter, and the "Rule" and "Tag" filters will dynamically update based on your "Tool" selection.

Escaneo de código with CodeQL now includes beta support for analyzing C++20 code. This is only available when building codebases with GCC on Linux. C++20 modules are not supported yet.

The depth of CodeQL's analysis has been improved by adding support for more libraries and frameworks and increasing the coverage of our existing library and framework models for several languages (C++, JavaScript, Python, and Java). As a result, CodeQL can now detect even more potential sources of untrusted user data, review the steps through which that data flows, and identify potentially dangerous sinks in which this data could end up. This results in an overall improvement of the quality of the escaneo de código alerts. For more information, see the GitHub changelog.

Escaneo de código now shows security-severity levels for CodeQL security alerts. You can configure which security-severity levels will cause a check failure for a pull request. The severity level of security alerts can be critical, high, medium, or low. By default, any escaneo de código alerts with a security-severity of critical or high will cause a pull request check failure.

Additionally, you can now also configure which severity levels will cause a pull request check to fail for non-security alerts. You can configure this behavior at the repository level, and define whether alerts with the severity error, warning, or note will cause a pull request check to fail. By default, non-security escaneo de código alerts with a severity of error will cause a pull request check failure.

For more information see "Defining which alert severity levels cause pull request check failure."

Improvements to the branch filter for escaneo de código alerts make it clearer which escaneo de código alerts are being displayed on the alerts page. By default, escaneo de código alerts are filtered to show alerts for the default branch of the repository only. You can use the branch filter to display the alerts on any of the non-default branches. Any branch filter that has been applied is shown in the search bar.

The search syntax has also been simplified to branch:<branch name>. This syntax can be used multiple times in the search bar to filter on multiple branches. The previous syntax, ref:refs/heads/<branch name>, is still supported, so any saved URLs will continue to work.

Free text search is now available for code scanning alerts. You can search code scanning results to quickly find specific alerts without having to know exact search terms. The search is applied across the alert's name, description, and help text. The syntax is:

• A single word returns all matches.
• Multiple search words returns matches to either word.
• Words in double quotes returns exact matches.
• The keyword 'AND' returns matches to multiple words.

Escaneo de secretos added patterns for 23 new service providers. For the updated list of supported secrets, see "About secret scanning."

Pagination support has been added to the Repositories REST API's "compare two commits" endpoint, which returns a list of commits reachable from one commit or branch, but unreachable from another. The API can also now return the results for comparisons over 250 commits. For more information, see the "Commits" REST API documentation and "Traversing with pagination."

The REST API can now be used to programmatically resend or check the status of webhooks. For more information, see "Repositories," "Organizations," and "Apps" in the REST API documentation.

Improvements have been made to the code scanning and GitHub Advanced Security APIs:

• The code scanning API now returns the CodeQL query version used for an analysis. This can be used to reproduce results or confirm that an analysis used the latest query. For more information, see "Code scanning" in the REST API documentation.
• Admin users can now use the REST API to enable or disable GitHub Advanced Security for repositories, using the security_and_analysis object on repos/{org}/{repo}. In addition, admin users can check whether Advanced Security is currently enabled for a repository by using a GET /repos/{owner}/{repo} request. These changes help you manage Advanced Security repository access at scale. For more information, see "Repositories" in the REST API documentation.

On a freshly set up GitHub Enterprise Server without any users, an attacker could create the first admin user.

Custom firewall rules are removed during the upgrade process.

Git LFS tracked files uploaded through the web interface are incorrectly added directly to the repository.

Issues cannot be closed if they contain a permalink to a blob in the same repository, where the blob's file path is longer than 255 characters.

When "Users can search GitHub.com" is enabled with GitHub Connect, issues in private and internal repositories are not included in GitHub.com search results.

The Registro del paquete de GitHub npm registry no longer returns a time value in metadata responses. This was done to allow for substantial performance improvements. We continue to have all the data necessary to return a time value as part of the metadata response and will resume returning this value in the future once we have solved the existing performance issues.

Resource limits that are specific to processing pre-receive hooks may cause some pre-receive hooks to fail.

In some cases, GitHub Advanced Security customers who upgrade to GitHub Enterprise Server 3.5 or later may notice that alerts from secret scanning are missing in the web UI and REST API. To ensure the alerts remain visible, do not skip 3.4 when you upgrade from an earlier release to 3.5 or later. A fix for 3.5 and later will be available in an upcoming patch release.

To plan an upgrade through 3.4, see the Upgrade assistant. [Updated: 2022-08-16]

GitHub Enterprise Server 2.21 was discontinued on June 6, 2021. That means that no patch releases will be made, even for critical security issues, after this date. For better performance, improved security, and new features, upgrade to the newest version of GitHub Enterprise Server as soon as possible.

GitHub Enterprise Server 2.22 will be discontinued on September 23, 2021. That means that no patch releases will be made, even for critical security issues, after this date. For better performance, improved security, and new features, upgrade to the newest version of GitHub Enterprise Server as soon as possible.

Beginning in GitHub Enterprise Server 3.1, we will begin discontinuing support for Xen Hypervisor. The complete deprecation is scheduled for GitHub Enterprise Server 3.3, following the standard one year deprecation window. Please contact GitHub Support with questions or concerns.

GitHub Enterprise Server 3.2 removes unused GitHub Service database records. More information is available in the deprecation announcement post.

To prevent accidental logging or exposure of access_tokens, we discourage the use of OAuth Application API endpoints and the use of API auth via query params. Visit the following posts to see the proposed replacements:

• Replacement OAuth Application API endpoints
• Replacement auth via headers instead of query param

These endpoints and auth route are planned to be removed from GitHub Enterprise Server in GitHub Enterprise Server 3.4.

Two legacy GitHub Apps-related webhook events have been removed: integration_installation and integration_installation_repositories. You should instead be listening to the installation and installation_repositories events.

The following REST API endpoint has been removed: POST /installations/{installation_id}/access_tokens. You should instead be using the namespaced equivalent POST /app/installations/{installation_id}/access_tokens.

GitHub Connect will no longer work after June 3rd for instances running GitHub Enterprise Server 3.1 or older, due to the format of GitHub authentication tokens changing. To continue using GitHub Connect, upgrade to GitHub Enterprise Server 3.2 or later. For more information, see the GitHub Blog. [Updated: 2022-06-14]