Enterprise Server 3.7 release notes

MEDIO: los tokens de instalación con ámbito para una aplicación de GitHub mantienen los permisos aprobados después de que los permisos de la instalación de integración se hayan degradado o quitado. GitHub ha solicitado el identificador CVE CVE-2023-23765 para esta vulnerabilidad, que se informó a través del programa de recompensas de GitHub por la detección de errores.

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

En una instancia de una configuración de clúster, al actualizar el nodo maestro de MySQL, la ejecución de la configuración posterior a la actualización tardaría 600 segundos más de lo necesario debido a la detección incorrecta de nodos incorrectos.

En algunas situaciones en una instancia con varios nodos, la replicación de Git no podía replicar completamente los repositorios que se habían eliminado anteriormente, lo que daba lugar a que apareciera una advertencia en la salida ghe-repl-status.

En una instancia con el gráfico de dependencias habilitado, aparece la ruta de acceso correcta para los manifiestos que se originan en instantáneas de envío en tiempo de compilación.

Usuarios con acceso SSH administrativo a una instancia pueden configurar el uso máximo de memoria en gigabytes para Redis mediante ghe-config redis.max-memory-gb VALUE.

ALTA: se ha actualizado Git para incluir correcciones de la versión 2.39.2, que abordan las vulnerabilidades CVE-2023-22490 y CVE-2023-23946.

MEDIA: se ha actualizado Git para incluir correcciones de la versión 2.40.1. Para obtener más información, consulta Vulnerabilidades de seguridad de Git anunciadas en el blog de GitHub.

Los usuarios no han podido cargar archivos GIF como datos adjuntos dentro de un comentario de un problema o de una solicitud de incorporación de cambios.

En una instancia de una configuración de alta disponibilidad, se podría producir un error en una operación git push si el servidor de GitHub Enterprise creara simultáneamente el repositorio en un nodo de réplica.

Un administrador de sitio no podía omitir un proxy de un dominio de nivel superior de la lista de excepciones de la instancia o de dominios de nivel superior registrados con IANA.

En algunas plataformas, después de que alguien con acceso SSH administrativo ejecutara ghe-diagnostics, la salida del comando incluía un error SG_IO de poca importancia.

En algunos casos, en una instancia con una licencia de GitHub Advanced Security, los usuarios no pudieron cargar la página del análisis de seguridad y se mostró el error 500.

Cuando un administrador de sitio usaba GitHub Enterprise Importer para importar datos de GitHub Enterprise Cloud, se producía un error en las migraciones durante la importación de comentarios de nivel de archivo. Este error ya no impide que la importación prosiga.

En una instancia con una licencia de GitHub Advanced Security, los usuarios con el rol de administrador de seguridad de una organización no podían ver la configuración de GitHub Advanced Security de la organización.

Si un usuario hacía clic en el vínculo para compartir comentarios o notificar errores de la versión beta de las listas de usuarios, la interfaz web respondía con un error 404.

Cuando un administrador de sitio usaba GitHub Enterprise Importer, se producía un error en la importación de un repositorio si una columna de proyecto del repositorio tenía archivadas 2500 o más tarjetas.

En una instancia con alertas de Dependabot habilitadas, las alertas se ocultaban por error cuando diferentes detectores de envío en tiempo de compilación detectaban diversas vulnerabilidades.

El servidor de GitHub Enterprise publicó métricas de distribución que collectd no puede procesar. Entre las métricas se incluían pre_receive.lfsintegrity.dist.referenced_oids, pre_receive.lfsintegrity.dist.unknown_oids y git.hooks.runtime.

En algunos casos, en una instancia que tenía Acciones de GitHub habilitado, se producía un error en la implementación del sitio de GitHub Pages mediante un flujo de trabajo de Acciones de GitHub con el estado deployment_lost.

En una instancia con una licencia de GitHub Advanced Security que también estaba configurada para una zona horaria superior a UTC, la lista de alertas de examen de secretos mostraba el error "No se pudieron cargar los secretos" cuando un usuario ordenaba los secretos por fecha en orden descendente.

En una instancia con el gráfico de dependencias habilitado, los servicios en segundo plano pueden controlar más tráfico.

Las personas con acceso SSH administrativo que generan un paquete de soporte técnico mediante las utilidades ghe-support-bundle o ghe-cluster-support-bundle pueden especificar el período de tiempo en que se pueden recopilar datos con -p o --period sin usar espacios ni comillas. Por ejemplo, además de '-p 5 days' o -p '4 days 10 hours', -p 5days o -p 4days10hours son válidos.

En una instancia con Acciones de GitHub habilitada, las llamadas anidadas a flujos de trabajo reutilizables dentro de un trabajo de flujo de trabajo reutilizable con una matriz evalúan correctamente contextos dentro de expresiones como, por ejemplo, strategy: ${{ inputs.strategies }}.

Las solicitudes de descarga de objetos LFS de Git no se completaban hasta que notifican el tamaño de descarga final, lo que afectaba a la latencia de estas solicitudes, especialmente en una instancia con nodos que funcionan como cachés de repositorios.

En el caso de las instancias con GitHub Connect y acceso automático a acciones de GitHub.com habilitado, Dependabot no podría actualizar las acciones hospedadas en GitHub.com.

En algunos casos, en una instancia con una licencia de GitHub Advanced Security, los usuarios no pudieron cargar la página del análisis de seguridad y se mostró el error 500.

En una instancia con GitHub Connect habilitado, si estaba habilitada la opción "Users can search GitHub.com", los usuarios de repositorios privados e internos no estaban incluidos en los resultados de búsqueda de usuarios de GitHub.com.

Después de la restauración de una organización eliminada, la organización no aparecía en la lista de organizaciones de la instancia.

Los registros recopilados podrían crecer rápidamente debido a la inclusión de métricas kredz.* que no pueden analizarse mediante StatsD y provocaban mensajes de error.

Métricas launch.* descartadas que no se pueden analizar mediante stadsd, ya que los errores de statsd resultantes hicieron que los registros recopilados crecieran rápidamente en tamaño.

Si un administrador del sitio proporciona una configuración no válida para Blob Storage para Acciones de GitHub o Paquetes de GitHub en una instancia, la página de comprobaciones preparatorias muestra detalles e información de solución de problemas.

ALTA: se ha corregido una vulnerabilidad de autenticación inadecuada que permitía a un actor no autorizado modificar los gists secretos de otros usuarios mediante la autenticación con una entidad de certificación SSH. Esta vulnerabilidad se notificó a través del  Programa de recompensas de errores de GitHub   y se le ha asignado el identificador  CVE-2023-23761. [Actualizado: 07/04/2023]

MEDIA: se ha corregido una vulnerabilidad de comparación incorrecta que permitía el contrabando de confirmaciones mediante la presentación de una diferencia incorrecta. Esta vulnerabilidad se notificó a través del  Programa de recompensas de errores de GitHub  y se le ha asignado el identificador  CVE-2023-23762. [Actualizado: 07/04/2023]

En una instancia con Acciones de GitHub habilitada, las llamadas anidadas a flujos de trabajo reutilizables dentro de un trabajo de flujo de trabajo reutilizable con una matriz evalúan correctamente contextos dentro de expresiones como, por ejemplo, strategy: ${{ inputs.strategies }}.

En una instancia de una configuración de alta disponibilidad, se podría producir un error en una operación git push si el servidor de GitHub Enterprise creara simultáneamente el repositorio en un nodo de réplica.

En el panel de supervisión de la Consola de administración, los gráficos Cached Requests y Served Requests, recuperados por el comando git fetch catching, no mostraban métricas para la instancia.

Después de que un administrador del sitio eximiera al usuario @github-actions[bot] de limitar la frecuencia mediante el comando ghe-config app.github.rate-limiting-exempt-users "github-actions[bot]", la ejecución de ghe-config-check daba lugar a la aparición de una advertencia Validation is-valid-characterset failed.

Acciones de GitHub (actions) y Microsoft SQL (mssql) no aparecían en la lista de procesos dentro del panel de supervisión de instancias.

En algunos casos, los gráficos del panel de supervisión de la Consola de administración no se representaban.

En una instancia de una configuración de alta disponibilidad, si un administrador anulaba la replicación de un nodo de réplica mediante ghe-repl-teardown inmediatamente después de ejecutar ghe-repl-setup, pero antes que ghe-repl-start, un error indicaba que el script cannot launch /usr/local/bin/ghe-single-config-apply - run is locked. ghe-repl-teardown ahora muestra una alerta informativa y continúa la anulación.

Después de que un administrador usara el punto de conexión de la API REST /setup/api/start para cargar una licencia, se produjo un error Connection refused en la ejecución de la configuración durante la fase de migraciones.

En una instancia de una configuración de clúster, cuando un administrador del sitio establecía el modo de mantenimiento mediante ghe-maintenance -s, aparecía un error Permission denied cuando la utilidad intentaba acceder a /data/user/common/cluster.conf.

Durante la configuración de la alta disponibilidad, si un administrador de sitio interrumpía la utilidad ghe-repl-start, esta notificaba erróneamente la configuración de la replicación y la instancia no realizaba operaciones de limpieza esperadas.

En las instancias configuradas para usar la versión beta privada de SCIM para el servidor de GitHub Enterprise, se produjo un error en la autenticación de los usuarios con claves SSH y tokens de acceso personal debido a un requisito erróneo de autorización.

Después de que un usuario importara un repositorio con la protección de inserción habilitada, el repositorio no se pudo visualizar inmediatamente en la vista "Cobertura de seguridad" de la información general de seguridad.

Las respuestas del punto de conexión de la API REST /repositories incluían erróneamente repositorios eliminados.

Cuando un administrador del sitio usaba ghe-migrator para migrar datos al servidor de GitHub Enterprise, en algunos casos, las relaciones entre equipos anidadas no se conservaban tras la importación de los equipos.

Si un repositorio contenía un archivo CODEOWNERS con anotaciones de verificación, la pestaña "Archivos cambiados" de PR devolvía un error 500 y mostraba "Vaya, hubo un problema" en la sección "Archivos sin cambios con anotaciones de verificación".

En una instancia con Acciones de GitHub habilitada, si un usuario desencadenaba manualmente un flujo de trabajo mediante la API REST, pero no especificaba valores para los booleanos opcionales, la API no podía validar la solicitud y devolvía un error 422.

Los informes CSV para todos los usuarios y todos los usuarios activos, disponibles en el panel de administración del sitio, no consideraban el acceso reciente mediante SSH o tokens de acceso personal.

En algunos casos, en una instancia con varios nodos, el servidor de GitHub Enterprise dejaba erróneamente de escribir en servidores de archivos de réplica, provocando la pérdida de la sincronización de los datos del repositorio.

El servidor de GitHub Enterprise publicó métricas de distribución que collectd no puede procesar. Entre las métricas se incluían pre_receive.lfsintegrity.dist.referenced_oids, pre_receive.lfsintegrity.dist.unknown_oids y git.hooks.runtime.

En una instancia con una licencia de GitHub Advanced Security, si se hubiera usado el examen de código durante la ejecución de GitHub Enterprise Server 3.4 o una versión anterior, se podría producir un error en una actualización posterior de 3.5 a 3.6 o 3.7 al intentar agregar un índice único a una tabla de base de datos.

Un propietario de la empresa no pudo habilitar la autenticación en dos fases (TFA) para una instancia si algún propietario de la empresa no había habilitado TFA para sus cuentas de usuario. [Actualizado: 17/04/2023]

En una instancia con paquetes de GitHub habilitados, después de que los usuarios insertaran en el registro de contenedor, la instancia respondió erróneamente con un error 429 Too Many Requests en los casos en los que la instancia podría dar cabida a la solicitud. Se han elevado los límites y los usuarios deben recibir este mensaje con menos frecuencia. [Actualizado: 30/05/2023]

Cuando la API de envío de dependencias reciba un envío con una o varias dependencias sin una versión, el gráfico de dependencias ahora notificará correctamente este hecho.

Para evitar un error durante una ejecución de la configuración en un clúster, la validación de cluster.conf con la utilidad ghe-cluster-config-check garantiza que el campo consul-datacenter de cada nodo coincida con el campo primary-datacenter de nivel superior.

En una instancia de una configuración de clúster, cuando un administrador del sitio establece el modo de mantenimiento en un único nodo de clúster mediante ghe-maintenance -s, la utilidad advierte al administrador de que use ghe-cluster-maintenance -s para establecer el modo de mantenimiento en todos los nodos de clústeres. Para obtener más información, vea «Habilitar y programar el modo de mantenimiento».

Cuando un administrador del sitio configura un servidor proxy web de salida para el servidor de GitHub Enterprise, la instancia ahora valida los dominios de nivel superior (TLD) excluidos de la configuración del proxy. De forma predeterminada, puedes excluir los TLD públicos que especifica la IANA. Los administradores del sitio pueden especificar una lista de TLD no registrados que se van a excluir mediante ghe-config. El prefijo . es necesario para cualquier TLD público. Por ejemplo, .example.com es válido, pero example.com no lo es. Para obtener más información, vea «Configuración de un servidor proxy web de salida».

Para evitar problemas intermitentes con el éxito de las operaciones de Git en una instancia con varios nodos, el servidor de GitHub Enterprise comprueba el estado del contenedor de MySQL antes de intentar una consulta SQL. También se ha reducido la duración del tiempo de espera.

La ruta de acceso predeterminada para la salida de ghe-saml-mapping-csv -d es /data/user/tmp en lugar de /tmp. Para obtener más información, vea «Utilidades de la ea de comandos».

"ALTA: Se ha identificado una vulnerabilidad de recorrido de ruta en GitHub Enterprise Server que ha permitido la ejecución de código remoto al crear un sitio de GitHub Pages. Para aprovechar esta vulnerabilidad, un atacante necesitaría permiso para crear y construir un sitio de GitHub Pages en la instancia de GitHub Enterprise Server. Esta vulnerabilidad se notificó mediante el Programa de recompensas de GitHub y se le ha asignado el código CVE-2023-23760.

Al ver una lista de sesiones abiertas de los dispositivos que han iniciado sesión en una cuenta de usuario, la interfaz de usuario web de GitHub Enterprise Server podría mostrar una ubicación incorrecta.

En el caso poco frecuente en el que las particiones principales de Elasticsearch se encontraran en un nodo de réplica, el comando ghe-repl-stop produciría el error ERROR: Running migrations.

ALTA: se ha actualizado Git para incluir correcciones de la versión 2.39.2, que abordan las vulnerabilidades CVE-2023-22490 y CVE-2023-23946.

ALTA: se ha identificado una vulnerabilidad de recorrido de ruta en GitHub Enterprise Server que permitía la lectura de archivos arbitrarios al crear un sitio de GitHub Pages. Para aprovechar esta vulnerabilidad, un atacante necesitaría permiso para crear y construir un sitio de GitHub Pages en la instancia. Esta vulnerabilidad se notificó mediante el Programa de recompensas de GitHub y se le ha asignado el código CVE-2023-22380.

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

Al usar una URL de punto de conexión de VPC como una URL de AWS S3 para paquetes de GitHub, se ha producido un error en la publicación y la instalación de paquetes.

En el caso de las instancias con GitHub Connect y acceso automático a acciones de GitHub.com habilitado, Dependabot no podría actualizar las acciones hospedadas en GitHub.com.

El archivo CSV que contiene detalles sobre los colaboradores de GitHub Advanced Security no se podía descargar si la instancia no tenía una licencia de GitHub Advanced Security.

Los registros recopilados podrían crecer rápidamente debido a la inclusión de métricas kredz.* que no pueden analizarse mediante StatsD y provocaban mensajes de error.

En una instancia con una licencia de GitHub Advanced Security, si se hubiera usado el examen de código durante la ejecución de GitHub Enterprise Server 3.4 o una versión anterior, se podría producir un error en una actualización posterior de 3.5 a 3.6 o 3.7 al intentar agregar un índice único a una tabla de base de datos.

Después de que la API REST de envío de dependencias reciba un envío con una o varias dependencias sin una versión, el gráfico de dependencias ahora notificará correctamente este hecho.

MEDIUM: se identificó una vulnerabilidad de inyección de código en GitHub Enterprise Server que permitía establecer variables de entorno arbitrarias a partir de un único valor de variable de entorno en Acciones de GitHub cuando al usar un ejecutor basado en Windows debido a un saneamiento incorrecto de los bytes null. Para aprovechar esta vulnerabilidad, un atacante necesitaría el permiso existente para controlar el valor de las variables de entorno para usarlas con Acciones de GitHub. Esta vulnerabilidad se ha notificado mediante el programa Bug Bounty de GitHub y se le ha asignado el código CVE-2023-22381.

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

Después de que un administrador de sitio ajustara la fecha límite para permitir conexiones SSH con claves RSA mediante ghe-config app.gitauth.rsa-sha1, la instancia seguía sin permitir conexiones con claves RSA si la función hash SHA-1 firmaba el intento de conexión.

Durante la fase de validación de una ejecución de configuración, puede haberse producido No such object error para los servicios Notebook y Viewscreen.

Después de deshabilitar las actualizaciones de Dependabot, el avatar de Dependabot se mostraba como el usuario @ghost en la escala de tiempo de la alerta de Dependabot.

En algunos casos, los usuarios podían experimentar un error 500 al ver la página de configuración Análisis y seguridad del códigopara una instancia con un número muy alto de confirmadores activos.

Algunos vínculos para ponerse en contacto con el soporte técnico de GitHub o ver las notas de la versión de GitHub Enterprise Server eran incorrectos.

El recuento de confirmadores adicionales para GitHub Advanced Security siempre mostraba 0.

En algunos casos, los usuarios no podían convertir incidencias existentes en discusiones. Si se bloquea una incidencia mientras se convierte en una discusión, los propietarios de empresas pueden revisar la sección "Problemas conocidos" a continuación para obtener más información.

HIGH: se ha actualizado Git para incluir correcciones de la versión 2.39.1, que abordan las vulnerabilidades CVE-2022-41903 y CVE-2022-23521.

Corrección de secretos adicionales en paquetes de soporte y el registro de configuración.

Las dependencias de la acción CodeQL se han actualizado a las versiones de seguridad más recientes.

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

Algunos servicios se conectan incorrectamente a kafka-lite en lugar de mediante su proxy interno. En un entorno de clúster donde los servicios web y los servicios de trabajo se ejecutan en nodos independientes, los mensajes generados desde el servicio de trabajos de Insights no se entregaron a kafka-lite.

Las métricas Active workers y Queued requests para github (cambiadas de nombres en los metadatos), gitauth, y los servicios de contenedor unicorn no se han leído correctamente en collectd y se muestran en la consola de administración.

Los correos electrónicos de alerta de Dependabot se enviarían a repositorios deshabilitados.

Puede que las migraciones de datos no se realicen correctamente cuando la tabla de base de datos subyacente contenga solo un único registro.

La ordenación y el filtrado de la lista de patrones personalizados para el examen de secretos a nivel de organización no funcionaron correctamente.

Después de actualizar a GitHub Enterprise Server 3.7, al ver la página de configuración de seguridad de una organización o repositorio podría producirse un error 500 debido a que un trabajo de reposición de GitHub Advanced Security no se completó antes de que se iniciara la actualización.

El comando git-janitor no ha podido corregir archivos multi-pack-index.lock desactualizados, lo que provoca un error en el mantenimiento del repositorio.

Métricas launch.* descartadas que no se pueden analizar mediante stadsd, ya que los errores de statsd resultantes hicieron que los registros collectd crecieran rápidamente.

Al actualizar patrones personalizados, el estado del patrón se estableció inmediatamente en publicado.

Se ha mejorado la confiabilidad del servicio de actualizaciones en tiempo real (Alive) para que sea más resistente frente a problemas de red con Redis.

Los comandos ghe-support-bundle y ghe-cluster-support-bundle se han actualizado para incluir la marca -p/--period a fin de generar una agrupación de compatibilidad limitada en el tiempo. La duración se puede especificar en días y horas, por ejemplo, -p '2 hours', -p '1 day', -p '2 days 5 hours'.

Al actualizar una instancia con una nueva partición raíz, la ejecución del comando ghe-upgrade con la opción -t/--target garantiza que la comprobación preparatoria del tamaño mínimo de almacenamiento en disco se ejecute en la partición de destino.

Se ha mejorado el rendimiento de las ejecuciones de configuración iniciadas con ghe-config-apply.

Al exportar datos de cuenta, realizar una copia de seguridad de un repositorio o llevar a cabo una migración, el vínculo a un archivo de repositorio expira ahora al cabo de una hora. Anteriormente, el vínculo de archivo expiraba después de cinco minutos.

ALTA: Se ha identificado una vulnerabilidad de recorrido de ruta en GitHub Enterprise Server que ha permitido la ejecución de código remoto al crear un sitio de GitHub Pages. Para aprovechar esta vulnerabilidad, un atacante necesitaría permiso para crear y construir un sitio de GitHub Pages en la instancia. Esta vulnerabilidad se ha notificado mediante el programa de GitHub Bug Bounty y se le ha asignado el código CVE-2022-46256.

Una condición de carrera ha bloqueado las actualizaciones a GitHub Enterprise Server 3.6 o versiones posteriores hasta que un administrador del sitio ha reintentado la actualización.

Cuando un administrador del sitio ha ejecutado el comando ghe-repl-status en una réplica de caché desde el shell administrativo (SSH), el comando ha notificado incorrectamente la información general del estado de replicación del clúster de Git y Alambic como si solo estuviera relacionada con la replicación de caché.

Cuando un administrador de sitio ha ejecutado el comando ghe-repl-sync-ca-certificates desde el nodo principal de una instancia mediante el shell administrativo (SSH), el comando solo ha replicado certificados de entidad de certificación desde el nodo principal de la instancia a un único nodo de réplica. El comando no ha replicado los certificados en todos los nodos de réplica disponibles.

En una configuración de alta disponibilidad, después de la promoción de una réplica para que sea el nodo principal, un administrador de sitio no pudo forzar la replicación para que se detuviera en un nodo de réplica secundario mediante el comando ghe-repl-stop -f.

Al usar el almacenamiento en caché del repositorio con una instancia en una configuración de alta disponibilidad, si un cliente de Git ha utilizado SSH en lugar de HTTPS para una URL remota del repositorio, Git LFS capturará objetos del nodo principal de la instancia en lugar del nodo de réplica de caché adecuado.

Error en la instalación de GitHub Enterprise Server en el hipervisor de VMware ESXi debido a la generación de un archivo OVA con un valor de capacidad no válido.

Cuando los usuarios han realizado una operación mediante la API, GitHub Enterprise Server ha aplicado cuotas de tamaño de repositorio incluso cuando se han deshabilitado globalmente.

En algunos casos, las búsquedas desde la API han devuelto un error 500.

La adición de un colaborador a una bifurcación propiedad del usuario de un repositorio privado propiedad de la organización con evaluación de prioridades, mantenimiento o acceso personalizado ha producido un error 500.

En algunos casos, la página para configurar el examen de código notificará erróneamente que Acciones de GitHub no se ha configurado para la instancia.

El descarte de una alerta de Dependabot que contenía determinados caracteres podría producir un error 400.

Después de eliminar la cuenta de un usuario de la instancia, los datos adjuntos de imagen que el usuario ha cargado en los comentarios ya no son visibles en la interfaz web.

En una instancia que usa SAML para la autenticación, el menú desplegable Configurar inicio de sesión único aparecía erróneamente para los tokens de acceso personal y las claves SSH.

Se pudo producir un error en una actualización de GitHub Enterprise Server 3.5 a 3.7 porque la instancia aún no había purgado los repositorios eliminados.

En una configuración de almacenamiento en caché de repositorios o alta disponibilidad, los servicios de Unicorn en nodos distintos del nodo principal no podían enviar eventos de registro al nodo principal.

Corrige un error en el que un archivo de registro GHES podría rellenarse muy rápidamente y hacer que la unidad raíz se quedara sin espacio libre.

Al ver los resultados del examen de código para Ruby, aparecía una etiqueta beta errónea.

Después de que un propietario de la empresa habilite las alertas de Dependabot, GitHub Enterprise Server pone en cola la sincronización de datos de asesoramiento para garantizar actualizaciones por hora desde GitHub.com.

En la lista de repositorios a los que ha accedido recientemente un usuario ya no se incluyen los repositorios eliminados.

Para los participantes en la versión beta privada de SCIM para el servidor de GitHub Enterprise, ahora se admiten asignaciones personalizadas para los atributos de usuario de SAML. Las asignaciones personalizadas permiten el uso de un valor distinto de NameID como notificación de identificación única durante la autenticación SAML. Para obtener más información, vea «Configuración del aprovisionamiento de usuarios con SCIM para la empresa». [Actualizado: 27/02/2023]

ALTA: Se ha identificado una vulnerabilidad de neutralización incorrecta de delimitadores de argumento en un comando en GitHub Enterprise Server que ha habilitado la ejecución remota de código. Para aprovechar esta vulnerabilidad, un atacante necesitaría permiso para crear y construir GitHub Pages mediante Acciones de GitHub. Este error se ha notificado originalmente mediante programa Bug Bounty de GitHub y se le ha asignado el código CVE-2022-23740. [Actualizado: 02/12/2022]

ALTA: Se ha agregado una comprobación en Pages para asegurarse de que el directorio de trabajo está limpio antes de desempaquetar nuevo contenido para evitar un error arbitrario de sobreescritura de archivos. A esta vulnerabilidad se le ha asignado el código CVE-2022-46255.

MEDIA: Se ha actualizado CommonMarker para abordar un escenario en el que las solicitudes paralelas a la API REST de Markdown podrían dar lugar a un agotamiento de recursos sin enlazar. A esta vulnerabilidad se le ha asignado el código CVE-2022-39209.

MEDIA: los tokens con ámbito de usuario a servidor de GitHub Apps podrían omitir las comprobaciones de autorización en las solicitudes de GraphQL API al acceder a recursos que no son de repositorio. Esta vulnerabilidad se ha notificado mediante el programa Bug Bounty de GitHub y se le ha asignado el código CVE-2022-23739.

MEDIA: los vínculos de vista previa de solicitudes de incorporación de cambios no han saneado correctamente las URL, lo que permite a un usuario malintencionado insertar vínculos peligrosos en la interfaz de usuario web de la instancia. Esta vulnerabilidad se ha notificado mediante el programa de GitHub Bug Bounty.

Si una dependencia de Acciones de GitHub usa una versión de SHA anclada, Dependabot ya no marcará la dependencia como vulnerable.

Al ejecutar el comando ghe-spokesctl se devuelve un error failed to get repo metrics.

El establecimiento del modo de mantenimiento con una lista de excepciones de IP no se conservaría entre las actualizaciones.

Las compilaciones de GitHub Pages podrían agotar el tiempo de espera en las instancias de AWS configuradas para alta disponibilidad.

Los detalles de estado de la replicación de objetos LFS de Git en los nodos de réplica de caché del repositorio no estaban visibles en la salida ghe-repl-status de esos nodos.

La marca de tiempo del registro de auditoría para los eventos de alerta de Dependabot ha devuelto la fecha de creación de la alerta en lugar de la marca de tiempo de la toma medidas del usuario según la alerta.

Al acceder a los recursos de JavaScript de una instancia desde detrás de un proxy, el explorador ha mostrado errores de uso compartido de recursos entre orígenes (CORS).

Si un usuario ha asignado a una comprobación de estado un nombre con espacios iniciales o finales, la instancia ha creado una comprobación duplicada si existía otra con el mismo nombre y sin espacios iniciales o finales.

Si un usuario ha configurado un enlace previo a la recepción para varios repositorios, en la página Enlaces de la instancia no siempre se mostrará el estado correcto para el enlace.

En algunos casos, una instancia podría reemplazar un repositorio activo por uno eliminado.

Los objetos LFS de Git en un repositorio con una directiva de replicación de caché no se copiarán en réplicas de caché si el número total de objetos del repositorio ha superado los 5000.

Después de ejecutar migraciones para GitHub Enterprise Importer en una instancia configurada para alta disponibilidad, la replicación de recursos de almacenamiento de migración no se pondrá al día.

Los procesos zombie ya no se acumulan en el contenedor gitrpcd.

En una instancia con GitHub Packages configurado, se podría producir un error en la carga e instalación de paquetes para los clientes que usen una URL de punto de conexión de VPC para el almacenamiento de blobs de AWS S3.

En algunos casos, después de actualizar a GitHub Enterprise Server 3.7.0, los usuarios pueden encontrar errores Internal Server Error o 500 al iniciar operaciones de Git mediante SSH o HTTPS.

Si un administrador del sitio aún no ha configurado Acciones de GitHub para la instancia, la interfaz de usuario para configurar el examen de código le pedirá al usuario que configure Acciones de GitHub.

Para evitar errores en la comprobación del dominio debido al límite de 63 caracteres que aplican los proveedores DNS para los registros DNS, el registro TXT generado por GitHub para comprobar que la propiedad del dominio ahora se limita a 63 caracteres.

En una instancia recién configurada de GitHub Enterprise Server sin ningún usuario, un atacante podría crear el primer usuario administrador.

Las reglas de cortafuegos personalizadas se eliminan durante el proceso de actualización.

Cuando se habilita "Los usuarios pueden buscar en GitHub.com" con GitHub Connect, las incidencias en los repositorios privados e internos no se incluyen en los resultados de la búsqueda de GitHub.com.

El registro npm de GitHub Packages ya no devuelve un valor de hora en las respuestas de metadatos. Esto se hacía para permitir mejoras de rendimiento importantes. Seguimos teniendo todos los datos necesarios para devolver un valor de tiempo como parte de la respuesta de metadatos y reanudaremos la devolución de este valor en el futuro una vez que hayamos resuelto las incidencias de rendimiento existentes.

Los límites de recursos que son específicos para procesar enlaces previos a la recepción podrían ocasionar errores en algunos de ellos.

Los servicios de Acciones se deben reiniciar después de restaurar una instancia a partir de una copia de seguridad realizada en otro host.

En la configuración de un repositorio, habilitar la opción de permitir a los usuario acceso de lectura para crear discusiones no habilita esta funcionalidad.

En algunos casos, los usuarios no pueden convertir incidencias existentes en discusiones.

Durante la fase de validación de una ejecución de configuración, se puede producir un error No such object para los servicios Notebook y Viewscreen. Este error se puede omitir porque los servicios todavía se deben iniciar correctamente.

Después de una actualización a GitHub Enterprise Server 3.6 o posterior, las incoherencias existentes en un repositorio, como referencias rotas u objetos que faltan, ahora se pueden notificar como errores como invalid sha1 pointer 0000000000000000000000000000000000000000, Zero-length loose reference file o Zero-length loose object file. Anteriormente, estos indicadores de daños en el repositorio se podían omitir silenciosamente. Ahora GitHub Enterprise Server usa una versión de Git actualizada con informes de errores más diligentes habilitados. Para más información, consulta esta confirmación ascendente en el proyecto de Git.

Si sospechas que existe un problema similar al siguiente en uno de los repositorios, ponte en contacto con el soporte técnico de GitHub Enterprise para obtener ayuda.

Las instancias que reciben de manera continuada un número elevado de solicitudes de Git a la vez pueden experimentar problemas de rendimiento. Si sospechas que este problema está afectando a tu instancia, ponte en contacto con Soporte de GitHub. Para obtener más información, vea «Crear un ticket de soporte». [Actualizado: 07/12/2022]

Al validar la configuración de dominio en una instancia con el aislamiento de subdominio y TLS habilitado, la Consola de administración no muestra los dos nuevos subdominios de GitHub Enterprise Server 3.7, http(s)://notebooks.HOSTNAME y http(s)://viewscreen.HOSTNAME, en la lista de dominios. [Actualizado: 12/01/2023]

En las instancias de una configuración de alta disponibilidad, las operaciones git push pueden producir errores en las situaciones siguientes. [Actualizado: 17/03/2023]

• Durante la creación del repositorio en un nodo de réplica.
• Tras un error en la creación del repositorio en un nodo réplica, antes de la reparación automática del repositorio.

En las instancias de una configuración de alta disponibilidad, los administradores del sitio solo deben ejecutar los comandos ghe-repl-start y ghe-repl-stop mientras la instancia está en modo de mantenimiento. Para obtener más información, vea «Habilitar y programar el modo de mantenimiento» y «Acerca de la configuración de alta disponibilidad». [Actualizado: 17/03/2023]

Para aumentar la seguridad de la Consola de administración, los administradores del sitio pueden configurar el límite de frecuencia para los intentos de inicio de sesión, así como la duración del bloqueo después de superar el límite de frecuencia. Para obtener más información, vea «Configuración de los límites de frecuencia».

Los requisitos mínimos de contraseña para la Consola de administración son más estrictos.

Los intentos de autenticación en la Consola de administración y los cambios realizados por un administrador de sitio en la Consola de administración se escriben en un archivo de registro en /var/log/enterprise-manage/audit.log.

Azure Maps reemplaza a MapBox para representar archivos GeoJSON como mapas gráficos. Los administradores pueden habilitar la representación de mapas y proporcionar un token de Azure Maps en la Consola de administración. Para obtener más información, consulta "Administración de la instancia desde la Consola de administración".

Los usuarios pueden comprobar confirmaciones mediante una clave pública SSH. Para obtener más información, consulte "Acerca de la comprobación de firmas de confirmación".

Los administradores del sitio pueden aprovisionar usuarios y grupos en una instancia de GitHub Enterprise Server automáticamente con SCIM. SCIM para GitHub Enterprise Server está en versión beta privada y está sujeto a cambios. Para obtener más información, consulta "Configuración del aprovisionamiento de usuarios con SCIM para la empresa" y "SCIM" en la documentación de la API REST.

Los usuarios de una instancia con una licencia de GitHub Advanced Security pueden ver y comentar las alertas de examen de código en su repositorio dentro de la pestaña Conversación de una solicitud de incorporación de cambios. Si la regla de protección de rama Requerir la resolución de conversaciones antes de fusionar está habilitada para el repositorio, todos los comentarios de estas alertas de examen de código deben resolverse antes de que un usuario combine la solicitud de incorporación de cambios. Para obtener más información, consulta "Acerca del examen de código", "Acerca de las revisiones de solicitudes de incorporación de cambios" y "Acerca de las ramas protegidas".

Para simplificar el lanzamiento del examen de secretos para instancias con docenas, cientos o incluso miles de organizaciones, los propietarios de empresas de una instancia con una licencia de GitHub Advanced Security pueden habilitar el examen de secretos y la protección contra el envío de cambios para la instancia mediante la interfaz web. Para obtener más información, consulta "Administración de características de GitHub Advanced Security para su empresa".

Los propietarios de la organización de una instancia con una licencia de GitHub Advanced Security pueden realizar un simulacro de patrones personalizados para el examen de secretos para todos los repositorios de una organización. Para más información, vea "Definición de patrones personalizados para el análisis de secretos".

Si un administrador de sitio ha habilitado las notificaciones por correo electrónico para una instancia con una licencia de GitHub Advanced Security, los usuarios que vean las alertas de examen de secretos de un repositorio recibirán una notificación por correo electrónico cuando un colaborador omita un secreto bloqueado por la protección contra el envío de cambios. Anteriormente, las notificaciones no se enviaban si el secreto se marcaba como falso positivo o se usaba en las pruebas. Para obtener más información, consulta "Protección de inserciones con el examen de secretos" y "Configuración del correo electrónico para notificaciones".

Para facilitar la administración de docenas o cientos de patrones personalizados para el examen de secretos, los usuarios, los propietarios de la organización o los propietarios de empresas en una instancia con una licencia de GitHub Advanced Security pueden ordenar y filtrar la lista de patrones de un repositorio, organización o toda la instancia. Para más información, vea "Definición de patrones personalizados para el análisis de secretos".

Los usuarios de una instancia con una licencia de GitHub Advanced Security que protegen las inserciones con el examen de secretos pueden especificar un vínculo personalizado que se mostrará en el mensaje de error cuando la protección de inserción detecte y bloquee un posible secreto. Para más información, vea "Protección de inserciones para el examen de secretos".

Los usuarios pueden publicar paquetes de CodeQL en el registro de contenedor. Para obtener más información, consulta Creación y uso de paquetes de CodeQL en la documentación de la CLI de CodeQL.

Los usuarios de una instancia con una licencia de GitHub Advanced Security pueden usar paquetes de CodeQL con examen de código, incluidos los paquetes publicados en el registro de contenedor de GitHub de la instancia. Para obtener más información, consulta "Configuración del examen de código" y "Publicación y uso de paquetes de CodeQL" en la documentación de la CLI de CodeQL.

Los usuarios de una instancia con una licencia de GitHub Advanced Security pueden excluir las consultas CodeQL innecesarias para el examen de código mediante filtros de consulta. Para más información, vea "Configuración del análisis de código".

Los propietarios de empresa de una instancia con una licencia de GitHub Advanced Security pueden recuperar los resultados del examen de código para toda la instancia mediante la API REST. El nuevo punto de conexión complementa los puntos de conexión existentes para repositorios y organizaciones. Para más información, consulta "Examen del código" en la documentación de la API REST.

Los propietarios de la organización de una instancia con una licencia de GitHub Advanced Security pueden recuperar el estado de habilitación o configurar la habilitación automática de las siguientes características mediante la API REST.

• Seguridad avanzada de GitHub
• Análisis de secretos
• Protección contra el envío de cambios

Para más información, consulta "Organizaciones" en la documentación de la API REST.

Los usuarios de una instancia con una licencia de GitHub Advanced Security pueden usar cursores para paginar los resultados de las alertas del examen de secretos recuperados con los puntos de conexión de repositorio y organización de la API REST. Para más información, consulta "Examen de secretos " en la documentación de la API REST.

La información general de seguridad de la instancia incluye información sobre Dependabot. Para más información, vea "Visualización de la información general sobre seguridad".

Los usuarios pueden ver más información sobre la actividad asociada a una alerta de Dependabot. Dentro de los detalles de una alerta de Dependabot, los usuarios pueden ver una escala de tiempo de eventos, como cuando se abrió, corrigió o volvió a abrir la alerta. Los eventos también mostrarán metadatos adicionales cuando estén disponibles, como las solicitudes de incorporación de cambios pertinentes. Para más información, consulta "Acerca de las alertas de Dependabot".

Las alertas de Dependabot de los usuarios se ordenan por importancia de forma predeterminada. La importancia tiene en cuenta el CVSS como factor principal, así como el riesgo potencial, la pertinencia y la facilidad para solucionar la vulnerabilidad. El cálculo mejorará con el tiempo.

Los usuarios pueden ordenar las alertas de Dependabot por el ámbito de la dependencia, ya sea en el entorno de ejecución o el desarrollo.

Opcionalmente, los usuarios pueden agregar un comentario al descartar una alerta de Dependabot. Los comentarios de descarte aparecen en la escala de tiempo del evento y dentro del campo dismissComment del objeto RepositoryVulnerabilityAlert de GraphQL API. Para más información sobre GraphQL API, consulta "Objetos" en la documentación de GraphQL API.

Los usuarios pueden seleccionar varias alertas de Dependabot y, a continuación, descartar o volver a abrir las alertas. Por ejemplo, de la pestaña Alertas cerradas, puedes seleccionar varias alertas que se hayan descartado previamente y, a continuación, volverlas a abrir al mismo tiempo.

Los propietarios de la organización de una instancia pueden recuperar el estado de habilitación o configurar la habilitación automática de las siguientes características para la administración de dependencias mediante la API REST.

• Gráfico de dependencias
• Alertas de Dependabot
• Actualizaciones de seguridad de Dependabot

Para más información, consulta "Organizaciones" en la documentación de la API REST.

Los propietarios de la empresa, los propietarios de la organización y los administradores de seguridad pueden acceder a una vista centralizada del riesgo en toda la instancia. La vista también incluye una vista centrada en alertas de todos los exámenes de código, exámenes de secretos y alertas de Dependabot. Los propietarios de la empresa pueden ver las alertas de las organizaciones de las que son propietarios. Los propietarios de la organización y los administradores de seguridad pueden ver los repositorios y alertas de las organizaciones a las cuales tienen acceso completo. Para obtener más información, consulte Acerca de la información general sobre seguridad.

Los propietarios de la organización pueden administrar equipos de administradores de seguridad mediante la API REST. Para más información, consulta "Administradores de seguridad" en la documentación de la API REST.

Los usuarios pueden aprovechar las siguientes mejoras en GitHub Advisory Database.

• Los usuarios pueden encontrar avisos de malware buscando type:malware.
• La base de datos muestra avisos para vulnerabilidades de Acciones de GitHub.

Para más información, consulta "Exploración de las asesorías de seguridad en GitHub Advisory Database".

Los usuarios pueden rellenar el gráfico de dependencias de un repositorio enviando las dependencias del repositorio mediante la API REST. El gráfico de dependencias alimenta las alertas de Dependabot y las actualizaciones de seguridad de Dependabot. Para más información, consulta "Uso de Dependency submission API."

Acciones de GitHub admite Google Cloud Storage como proveedor de almacenamiento para registros, artefactos y memorias caché. Para obtener más información, consulta "Habilitación de Acciones de GitHub con Google Cloud Storage".

Los usuarios de Acciones de GitHub que usan el almacenamiento en caché de dependencias para acelerar los flujos de trabajo ahora pueden usar la CLI de GitHub para administrar la memoria caché de Acciones de GitHub de un repositorio. Para administrar memorias caché mediante la CLI de GitHub, instala la extensión gh-actions-cache. Para más información, consulte la gh-actions-cachedocumentación.

Las repeticiones de los flujos de trabajo de Acciones de GitHub utilizan el actor que desencadenó inicialmente el flujo de trabajo para la evaluación de privilegios. El actor que desencadenó la nueva ejecución seguirá mostrándose en la interfaz de usuario, y se podrá acceder a él en un flujo de trabajo a través del campo triggering_actor en el contexto github. Para obtener más información, consulta "Volver a ejecutar flujos de trabajo y trabajos" y "Contextos".

Los usuarios pueden llamar a flujos de trabajo reutilizables desde una matriz u otros flujos de trabajo reutilizables. Para más información, vea "Reutilización de flujos de trabajo".

Al consultar Acciones de GitHub para artefactos, la API REST devuelve información sobre la ejecución y la rama que generó el artefacto. Para obtener más información, consulta "Artefactos de Acciones de GitHub" en la documentación de la API REST.

Para admitir implementaciones seguras en la nube a escala, los propietarios de la organización y los administradores de repositorios pueden completar las siguientes tareas con la API REST de OpenID Connect. Para obtener más información, consulta "OIDC de Acciones de GitHub" en la documentación de la API REST.

• Habilite una configuración estándar de OpenID Connect en los flujos de trabajo de implementación en la nube mediante la personalización del formato de notificación subject.
• Asegura el cumplimiento y la seguridad adicionales para las implementaciones de OpenID Connect anexando la dirección URL issuer con el slug de la empresa.
• Configura directivas avanzadas de OpenID Connect mediante notificaciones de token de OpenID Connect adicionales, como repository_id y repo_visibility.

Para más información, vea "Acerca del fortalecimiento de la seguridad con OpenID Connect".

Los usuarios de Acciones de GitHub que usan el almacenamiento en caché de dependencias para acelerar los flujos de trabajo ahora pueden usar la API REST de la caché de Acciones de GitHub para realizar las siguientes tareas.

• Enumerar todas las memorias caché de un repositorio y ordenar por metadatos.
• Eliminar una entrada de caché dañada o obsoleta. Para obtener más información, consulta "Almacenar en caché las dependencias para agilizar los flujos de trabajo" y "Caché de Acciones de GitHub" en la documentación de la API REST.

Si un ejecutor de Acciones de GitHub autohospedado no efímero no se comunica con la instancia de GitHub Enterprise Server durante más de 14 días, la instancia quitará automáticamente el ejecutor. Si un ejecutor autohospedado efímero no se comunica con la instancia durante más de un día, la instancia quitará automáticamente el ejecutor. Anteriormente, GitHub Enterprise Server quitaba los ejecutores después de 30 días. Para más información, consulte Seguridad del ejecutor autohospedado con repositorios públicos.

Acciones de GitHub puede ejecutar flujos de trabajo de macOS autohospedados en un entorno de ejecución arm64 de macOS con compatibilidad de ejecutor con Apple Silicon, como el chip M1 o M2. Para más información, consulta "Uso de ejecutores autohospedados en un flujo de trabajo".

Los usuarios pueden implementar un sitio de GitHub Pages directamente desde un repositorio mediante Acciones de GitHub, sin configuración de un origen de publicación. El uso de Acciones de GitHub permite supervisar el marco de creación y la versión, además de controlar mejor el proceso de publicación gracias a características como las validaciones de implementación. Para más información, consulta "Configuración de una fuente de publicación para el sitio de GitHub Pages."

Los propietarios de la empresa pueden impedir que los usuarios creen repositorios que pertenezcan a sus cuentas de usuario. Para más información, vea "Aplicación de directivas de administración de repositorios en la empresa".

Los propietarios de la empresa pueden controlar dónde pueden los usuarios bifurcar repositorios. La bifurcación puede limitarse a combinaciones preestablecidas de organizaciones, la misma organización que el repositorio primaria, cuentas de usuario o en cualquier lugar. Para más información, vea "Aplicación de directivas de administración de repositorios en la empresa".

Los administradores de repositorios pueden bloquear inserciones potencialmente destructivas limitando el número de ramas y etiquetas que se pueden actualizar mediante una sola inserción. De forma predeterminada, no hay ningún límite en el número de ramas y etiquetas que se pueden actualizar en un único envío de cambios. Para obtener más información, consulta "Administración de la directiva de inserción para el repositorio".

Los usuarios pueden personalizar aún más el mensaje de confirmación predeterminado con la fusión mediante combinación con "squash" de una solicitud de incorporación de cambios. Para obtener más información, consulta"Configuración de la combinación de confirmación para solicitudes de incorporación de cambios" y "Configuración de las fusiones mediante combinación con "squash" de confirmaciones para las solicitudes de incorporación de cambios".

Los usuarios pueden crear una rama desde la página de información general Ramas de un repositorio haciendo clic en el botón Nueva rama. Para más información, vea "Creación y eliminación de ramas dentro del repositorio".

Cuando un usuario renombra o mueve un archivo a un nuevo directorio, si al menos la mitad de los contenidos del archivo son idénticos, el historial de confirmación indica que el archivo fue renombrado, de forma similar a git log --follow. Para más información, consulta el blog de GitHub. [Actualizado: 10/02/2023]

Se han realizado mejoras en la creación y administración de bifurcaciones.

• Cuando se bifurca un repositorio, los usuarios pueden elegir incluir solo la rama predeterminada del repositorio en la bifurcación.
• Los usuarios pueden usar el botón Bifurcación de un repositorio para ver las bifurcaciones existentes del repositorio.
• Se ha cambiado el nombre del botón Recuperar el nivel superior a Sincronizar bifurcación para describir mejor el comportamiento del botón. Si la sincronización provoca un conflicto, la interfaz de usuario web solicita al usuario que contribuya a los cambios en el repositorio primario, descarte los cambios o resuelva el conflicto.
• Para abordar situaciones en las que los usuarios trabajan dentro de una organización y no quieren bifurcar un repositorio en otra organización o cuenta de usuario, los usuarios pueden bifurcar un repositorio en la misma organización que el repositorio primario.
• Los usuarios pueden bifurcar un repositorio interno en otra organización y la bifurcación conservará la visibilidad interna. Al bifurcar un repositorio interno, los usuarios pueden elegir qué organización debe poseer la bifurcación.

Para obtener más información, consulte "Bifurcación de un repositorio".

Los administradores de repositorios pueden bloquear creaciones de ramas que emparejan con un patrón de nombre configurado con regla de la rama de protección Restringir inserciones que creen ramas coincidentes. Por ejemplo, si la rama predeterminada de un repositorio cambia de master a main, un administrador del repositorio puede impedir la creación o inserción posteriores de la rama master. Para más información, consulta "Acerca de las ramas protegidas" y "Administración de una regla de protección de rama".

Los usuarios pueden crear archivos con diagramas geoJSON, topoJSON y STL y representar los diagramas en la interfaz web. Para obtener más información, consulte "Trabajar con archivos que no son de código".

Los usuarios pueden crear referencias de vínculo automático mediante identificadores alfanuméricos o numéricos. Para más información, consulta "Configuración de vínculos automáticos para hacer referencia a vínculos automáticos de recursos externos".

Los usuarios pueden personalizar exclusiones en el buscador de archivos como vendor/ y build/ mediante el uso de atributos linguist en un archivo .gitattributes. Para obtener más información, consulta "Buscar archivos en GitHub" y "Personalización de cómo aparecen los archivos modificados en GitHub".

Los usuarios pueden examinar los archivos modificados en una confirmación individual mediante la vista de árbol. Para obtener más información, consulta "Acerca de las confirmaciones".

Los usuarios pueden vincular manualmente las ramas o las solicitudes de incorporación de cambios existentes a un problema de la sección "Desarrollo" de la barra lateral del problema. Para más información, vea "Vinculación de una solicitud de incorporación de cambios a una incidencia".

Los usuarios pueden usar la sintaxis de Mermaid al escribir Markdown, que muestra un diagrama al representar Markdown. Para obtener más información, vea "Crear diagramas".

Los usuarios pueden escribir expresiones matemáticas mediante bloques de código delimitados con la sintaxis math además de los delimitadores existentes. $$ no es necesario con este método. Para obtener más información, consulta "Escritura de expresiones matemáticas".

• Nota: Esta característica no está disponible en GitHub Enterprise Server 3.7. La característica estará disponible en una próxima versión de revisión. [Actualizado: 16/11/2022]

Los usuarios pueden representar mapas directamente en Markdown mediante bloques de código delimitados con la sintaxis geojson o topojson e insertar representaciones STL 3D mediante la sintaxis stl. Para obtener más información, vea "Crear diagramas".

En Markdown, los usuarios pueden escribir la sintaxis de estilo LaTeX para representar expresiones matemáticas insertadas mediante delimitadores $, o en bloques mediante delimitadores $$. Para obtener más información, consulta "Escritura de expresiones matemáticas".

Para mejorar la estabilidad, se ha reemplazado el servicio para representar GeoJSON, Jupyter Notebook, PDF, PSD, SVG, SolidWorks y otros formatos binarios.

Si TLS y el aislamiento de subdominios están configurados para su instancia y su certificado no es un certificado comodín, debe generar un nuevo certificado que incluya los subdominios adicionales para estos servicios, notebooks.HOSTNAME y viewscreen.HOSTNAME. Para más información, vea "Habilitación del aislamiento de subdominios". [Actualizado: 02/12/2022]

El análisis de secretos ya no admite patrones personalizados que usan .* como delimitador final en el campo "Después del secreto", ya que la sintaxis del patrón provocaría problemas de examen e incoherencias.

Al crear una nueva versión, los usuarios ahora pueden enviar el formulario mediante Ctrl + Entrar en macOS o Ctrl + Entrar en Windows o Linux.

La pestaña Wiki de un repositorio solo aparece cuando existe una wiki. Anteriormente, la pestaña aparecía siempre.

Las wikis representadas muestran expresiones matemáticas y diagramas de Mermaid.

El tamaño del campo de búsqueda de registros de auditoría de usuarios, organizaciones y empresas ha aumentado.

El número máximo de ejecutores autohospedados en un grupo de ejecutores está limitado a 10 000. Anteriormente, no había ningún límite. [Actualizado: 24/05/2023]

En una instancia recién configurada de GitHub Enterprise Server sin ningún usuario, un atacante podría crear el primer usuario administrador.

Las reglas de cortafuegos personalizadas se eliminan durante el proceso de actualización.

Cuando se habilita "Los usuarios pueden buscar en GitHub.com" con GitHub Connect, las incidencias en los repositorios privados e internos no se incluyen en los resultados de la búsqueda de GitHub.com.

El registro npm de GitHub Packages ya no devuelve un valor de hora en las respuestas de metadatos. Esto se hacía para permitir mejoras de rendimiento importantes. Seguimos teniendo todos los datos necesarios para devolver un valor de tiempo como parte de la respuesta de metadatos y reanudaremos la devolución de este valor en el futuro una vez que hayamos resuelto las incidencias de rendimiento existentes.

Los límites de recursos que son específicos para procesar enlaces previos a la recepción podrían ocasionar errores en algunos de ellos.

Los servicios de Acciones se deben reiniciar después de restaurar una instancia a partir de una copia de seguridad realizada en otro host.

En la configuración de un repositorio, habilitar la opción de permitir a los usuario acceso de lectura para crear discusiones no habilita esta funcionalidad.

En algunos casos, los usuarios no pueden convertir incidencias existentes en discusiones.

Durante la fase de validación de una ejecución de configuración, se puede producir un error No such object para los servicios Notebook y Viewscreen. Este error se puede omitir porque los servicios todavía se deben iniciar correctamente.

En algunos casos, después de actualizar a GitHub Enterprise Server 3.7.0, los usuarios pueden encontrar errores Internal Server Error o 500 al iniciar operaciones de git mediante SSH o HTTPS. Ejemplo:

git push origin master
Total 0 (delta 0), reused 0 (delta 0)
remote: Internal Server Error
To ghes.hostname.com:User/repo.git
! [remote rejected]       master -> master (Internal Server Error)

Si se encuentran, ponte en contacto con el soporte técnico de GitHub Enterprise con un conjunto de soporte técnico. La solución temporal conocida en este momento es reiniciar el servicio github-gitauth con los siguientes comandos:

nomad stop github-gitauth
nomad run /etc/nomad-jobs/github/gitauth.hcl
nomad status github-gitauth

Actualmente estamos investigando una corrección permanente para una revisión activa futura [Actualizado: 2022-11-24].

Las instancias que reciben de manera continuada un número elevado de solicitudes de Git a la vez pueden experimentar problemas de rendimiento. Si sospechas que este problema está afectando a tu instancia, ponte en contacto con Soporte de GitHub. Para obtener más información, vea «Crear un ticket de soporte». [Actualizado: 07/12/2022]

Al validar la configuración de dominio en una instancia con el aislamiento de subdominio y TLS habilitado, la Consola de administración no muestra los dos nuevos subdominios de GitHub Enterprise Server 3.7, http(s)://notebooks.HOSTNAME y http(s)://viewscreen.HOSTNAME, en la lista de dominios. [Actualizado: 12/01/2023]

En las instancias de una configuración de alta disponibilidad, las operaciones git push pueden producir errores en las situaciones siguientes. [Actualizado: 17/03/2023]

• Durante la creación del repositorio en un nodo de réplica.
• Tras un error en la creación del repositorio en un nodo réplica, antes de la reparación automática del repositorio.

En las instancias de una configuración de alta disponibilidad, los administradores del sitio solo deben ejecutar los comandos ghe-repl-start y ghe-repl-stop mientras la instancia está en modo de mantenimiento. Para obtener más información, vea «Habilitar y programar el modo de mantenimiento» y «Acerca de la configuración de alta disponibilidad». [Actualizado: 17/03/2023]

An upgrade to GitHub Enterprise Server 3.6 or 3.7 from 3.5 or earlier may be long running if a large number of deleted repositories exist. Deleted repositories are purged automatically after 90 days, but for a faster upgrade they can be purged manually. If you suspect you have thousands of recently deleted repositories, and you are concerned about a long running upgrade, contact GitHub Enterprise Support for assistance purging deleted repositories. [Updated: 2023-05-09]

Próximamente en desuso: En GitHub Enterprise Server 3.8 y versiones posteriores, los algoritmos no seguros se deshabilitarán en las conexiones SSH al shell administrativo.

Los comentarios de confirmación, que son los que los usuarios agregan directamente a una confirmación fuera de una solicitud de incorporación de cambios, ya no aparecen en la escala de tiempo de la solicitud de incorporación de cambios. Los usuarios no han podido responder a estos comentarios ni resolverlos. La API REST de eventos de escala de tiempo y el objeto PullRequest de GraphQL API ya no devuelven comentarios de confirmación.

La comparación de archivos GeoJSON, PSD y STL ya no es posible.

Los registros de paquetes en la nueva arquitectura de GitHub Packages, incluidos los paquetes de registro de contenedor y npm, ya no exponen datos mediante GraphQL API. En una próxima versión, otros registros de GitHub Packages se migrarán a la nueva arquitectura, que también dejará de usar GraphQL API para esos registros.