Enterprise Server 3.0 release notes

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

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

Pages would become unavailable following a MySQL secret rotation until nginx was manually restarted.

When setting the maintenance schedule with a ISO 8601 date, the actual scheduled time wouldn't match due to the timezone not being transformed to UTC.

The version number would not be correctly updated after a installing a hotpatch using ghe-cluster-each.

Spurious error messages concerning the cloud-config.service would be output to the console.

When using CAS authentication and the "Reactivate suspended users" option was enabled, suspended users were not automatically reactivated.

The GitHub Connect data connection record now includes a count of the number of active and dormant users and the configured dormancy period.

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

Sanitiza más secretos en los paquetes de soporte generados

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

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

No se pudo acceder al botón de guardar en la consola de administración si se desplazaba en buscadores de menor resolución.

IOPS and Storage Traffic monitoring graphs were not updating after collectd version upgrade.

Some webhook related jobs could generated large amount of logs.

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.

Support bundles could include sensitive files if they met a specific set of conditions.

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.

A remote code execution vulnerability was identified in GitHub Enterprise Server that could be exploited when building a GitHub Pages site. This vulnerability affected all versions of GitHub Enterprise Server prior to 3.3 and was fixed in versions 3.0.21, 3.1.13, 3.2.5. This vulnerability was reported via the GitHub Bug Bounty program and has been assigned CVE-2021-41599. Updated February 17, 2022.

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

A misconfiguration in the Management Console caused scheduling errors.

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

GraphQL requests did not set the GITHUB_USER_IP variable in pre-receive hook environments.

Clarifies explanation of Actions path-style in documentation.

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

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

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.

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

Some critical services may not have been available on backend nodes in GHES Cluster.

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.

Some Git operations failed after upgrading a GitHub Enterprise Server 3.x cluster because of the HAProxy configuration.

Unicorn worker counts might have been set incorrectly in clustering mode.

Resqued worker counts might have been set incorrectly in clustering mode.

If Ubuntu's Uncomplicated Firewall (UFW) status was inactive, a client could not clearly see it in the logs.

Some pages and Git-related background jobs might not run in cluster mode with certain cluster configurations.

The enterprise audit log page would not display audit events for escaneo de secretos.

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 sent distribution type metrics that Collectd could not handle, which caused a ballooning of parsing errors.

Public repositories displayed unexpected results from escaneo de secretos with a type of Unknown Token.

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.

Several parts of the application were unusable for users who are owners of many organizations.

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

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

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

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

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

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

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

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

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.

La página de administrador de sitio para los ejecutores auto-hospedados del repositorio devolvió un HTTP 500

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 borraron bitácoras de webhook de forma más efectiva, las cuales salían de la ventana de retención de bitácoras de webhook.

ALTA: Se identificó una vulnerabilidad de navegación de ruta en GitHub Enterprise Server que podría aprovecharse cuando se compile un sitio de Páginas de GitHub. Las opciones de configuración que controla el usuario y que utilizan las Páginas de GitHub no se restringieron lo suficiente e hicieron posible que se leyeran archivos en la instancia de GitHub Enterprise Server. para explotar esta vulnerabilidad, un 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.1.8 y se corriegió en la 3.1.8, 3.0.16 y 2.22.22. Este es el resultado de un arreglo incompleto para el caso CVE-2021-22867. Esta vulnerabilidad se reportó mediante el Programa de Recompensas por Errores de GitHub y se le asignó el caso CVE-2021-22868.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

El ejecutar git nw-gc --pristine dio como resultado un error.

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

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

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

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

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

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

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

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

La rotación de bitácoras algunas veces interrumpió los jobs en segundo plano.

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

Un archivo de exportación falló en importarse si las solicitudes de revisión contenidas venían de equipos que no estaban presentes en el archivo.

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

El proceso de actualziación podría fallar al actualizar las acciones si la instancia no pudo hacer auto-solicitudes utilizando el nombre de host configurado.

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

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

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

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

ghe-dbconsole devolvió errores en algunas circunstancias.

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

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

El campo firstPatchedVersion ahora está disponible en los objetos de SecurityVulnerability en la API de GraphQL.

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

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

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

En la página de "Configurar acciones y paquetes" del proceso de instalación inicial, cuando un administrador hizo clic en el botón de "Probar configuración de dominio", la prueba no se completó.

El ejecutar ghe-btop falló con un error de tipo cannot find a 'babeld' container.

Los usuarios experimentaron una falta de disponibilidad de servicios después de mejorar su versión debido a un desajuste de valores de tiepo de espera internos y externos.

La replicación normal se retrasa en las advertencias que genera MSSQL.

El enlace para la Guía de Clústering de GitHub Enterprise sobre la consola de administración fue incorrecto.

Una dirección IP que agrege un administrador utilizando el botón de "Crear Entrada de Lista de Admisión" podría bloquearse de todos modos.

Se mostraron referencias a las características de la "Gráfica de dependencias" y a las "Alertas del dependabot" en los repositorios en donde no se habilitaron.

Las solicitudes de tipo HTTP POST a la terminal de /hooks podría fallar con una respuesta 401 debido a que la hookID se configuró incorrectamente.

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

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

Se archivarán las anotaciones de verificación más viejas de 4 meses.

ALTA: Se identificó una vulnerabilidad de distorsión en la IU que permitió que se otorgaran más permisos durante un flujo web de autorización de usuario para una GitHub App que se mostraba al usuario durante la aprobación. Para explotar esta vulnerabilidad, un atacante necesita crear una GitHub App en la instancia y hacer que un usuario autorice la aplicación a través del flujo de autenticación web. Todos los permisos otorgados se mostraron adecuadamente durante la primer autorización, pero en algunas circunstancias, si el usuario vuelve al flujo de autorizaciones después de que la GitHub App configuró permisos adicionales a nivel de usuario, dichos permisos podrían no mostrarse, lo cual llevó a que se otorgaran más permisos de los que el usuario necesitaba potencialmente. esta vulnerabilidad afectó a GitHub Enterprise Server 3.0.x antes del 3.0.7 y al 2.22.x antes del 2.22.13. Se arregló en las versiones 3.0.7 y 2.22.13. Se asignó un CVE-2021-22866 a esta vulnerabilidad y se reportó a través del Programa de Recompensas por fallos de GitHub.

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

Las citas que se incluyen en la configuración del almacenamiento de paquetes o acciones podrían causar errores.

Los ganchos de pre-recepción personalizados podrían fallar debido a la cantidad o tamaño de archivo muy restringido de los límites de archivo abiertos.

La recuperación automática de fallos del orquestador puede habilitarse durante la fase de aplicación de configuración.

Los usuarios con permiso de mantenedor en un repositorio obtuviern una advertencia de verificación por correo electrónico en vez de una compilación exitosa de página en la página de configuración de las páginas del repositorio.

El propietario del código de una regla de comodín se agregó incorrectamente a la lista de propietarios para la insignia de propietarios de código, incluso si una regla tardía tomó precedencia para dicha ruta.

Documentación de OpenAPI para un encabezado inválido.

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

Se agregó el registro en bitácora para cambios de configuración en una recarga de HAProxy.

Se agregó el registro en bitácora para la creación de repositorios.

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

Durante las mejoras, el proceso se pausó indefinidamente después de un cleanup nomad job.

Un ghe-cluster-failover falló con el mensaje de error Trilogy::Error: trilogy_connect.

ghe-cluster-status-mysql mostró advertencias sobre recuperaciones de fallos como errores.

El script de configuración que se ejecuta en la replica de MySQL puede haber causado un resembrado innecesario de la base de datos durante la recuperación de fallos de la base de datos.

Las mejoras no incluyeron la última versión del ejecutor de Acciones instalado adecuadamente.

La configuración de github-env pudo haber dado como resultado procesos zombie.

config-apply pudo haber tomado más tiempo del necesario debido a que se llamó a rake db:migrate innecesariamente.

El orquestador pudo haberse recuperado de un fallo en una réplica de MySQL que no estaba replicando desde primario durante la fase de sembrado cuando el primario no se pudo conectar.

Las organizaciones o proyectos con errores bloquearon la migración y no pudieron excluirse.

El botón de Crear Repositorio se inhabilitó para los usuarios que pertenecían a más de 50 organizaciones.

El borrar una rama mostrará un mensaje de error temporal que indica que algo salió mal cuando el borrado fue exitoso.

El índice de rms-packages se mostró en el tablero del administrador de sitio.

El propietario de la organización no pudo crear un repositorio interno debido a que las opciones correctas de visibilidad no se mostraron en el formato.

Las pestaña de acciones de los repositorios presentaron un 500 en los casos en donde los flujos de trabajo iniciales de las acciones estaban mal configurados.

Los clientes con más de tres hosts de almacenamiento no pudieron restablecer su clúster de recuperación de desastres debido a que se seleccionaron los discos más llenos en vez de los nodos vacíos.

Los servicios respaldados con el escaneo de código no iniciaron confiablemente después de aplicar los hotpatches.

Las verificaciones preliminares permiten tipos de instancia de AWS predeterminadamente.

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

Algunas bitácoras no se incluyeron en la configuración de reenvío de bitácoras.

Un mensaje de advertencia de tipo jq: error (at <stdin>:0): Cannot index number with string "settings" podría ocurrir durante la promoción de la réplica.

El restablecer respaldos continuamente a un clúster pudo haber fallado debido a que las réplicas de MySQL fallaron en conectarse al primario.

Las páginas mp se estaban publicando cuando se utilizó un certificado CA personalizado.

Los subdominios relacionados con los paquetes no se estaban mostrando en el mensaje de "Configuración de dominio de prueba" para el aislamiento de subdominio.

El encabezado de X-GitHub-Enterprise-Host enviado con webhooks incluía una secuencia aleatoria en vez del nombre de host de la instancia de GitHub Enterprise Server que envió la carga útil de HTTP POST.

Actualizar de una versión 2.22.x a una 3.0.x podría fallar si las Acciones de GitHub se habilitaron previamente pero se inhabilitaron antes de la mejora.

Visitar la página /settings/emails almacenó el estado que pudo haber causado redirecciones inadecuadas al finalizar sesión y volverla a iniciar.

Las apps de integración a GitHub no pudieron notificar a los equipos cuando se les mencionó directamente a través de una @mención en un comentario de una propuesta.

la interpretación de reStructuredText (RST) en la IU web falló y en vez de esto se mostró un texto de marcado RST sin procesar.

No se enviaron las notificaciones por correo electrónico de las alertas del Escaneo deSecretos a los usuarios autorizados cuando la gráfica de dependencias no se habilitó completamente.

Cuando el ghe-migrator encontró errores de importación, algunas veces abortó todo el proceso y las bitácoras no incluyeron suficiente contexto.

Puede que los blocs de notas de Jupyter con caracteres no ASCII fallaran en interpretarse.

ALTO: Se identificó una vulnerabilidad de control de acceso inadecuada en GitHub Enterprise Server, la cual permitió que los tokens de acceso generados desde un flujo de autenticación web de una GitHub App leyera los metadatos de un repositorio privado a través de la API de REST sin que se le hubieran otorgado los permisos adecuados. Para explotar esta vulnerabilidad, el atacante necesitaría crear una GitHub App en la instancia y hacer que un usuario autorice la aplicación mediante el flujo de autenticación web. Los metadatos del repositorio privado que se devolvió estarían limitados a los repositorios que pertenecen al usuario al cual identifica el token. Esta vulnerabilidad afectó a todas las versiones de GitHub Enterprise Server anterior a la 3.0.4 y se arregló en las versiones 3.0.4, 2.22.10 y 2.21.18. A esta vulnerabilidad se le asignó un CVE-2021-22865 y se reportó mediante el Programa de Recompensas por Errores de GitHub.

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

Cuando se habilitó el modo de mantenimiento, algunos servicios se siguieron listando como "procesos activos", aún cuando se esperaba que estuvieran ejecutándose y no debieron haberse listado.

Después de mejorar de una versión 2.22.x a una 3.0.x con GitHub Actions habilitado, la versión del ejecutor auto-hospedado no se actualizó y no se hicieron actualizaciones auto-hospedadas.

Las compilaciones de las páginas antiguas de GitHub no se limpiaron y esto llevó a un incremento en el uso de disco.

memcached no se estaba ejecutando en las réplicas activas.

La actualización falló al actualizar los permisos de archivo cuando se habilitó GitHub Actions.

Algunos servicios que estaban dando un tiempo UTC predetemrinado no estaban tulizando una zona horaria configurada en GitHub Enterprise 11.10.x o anterior.

Los servicios no estaban haciendo la transición a los archivos de bitácora nuevos como parte de la rotación de bitácoras, lo cual dio como resultado un uso de disco incrementado.

La utilidad de línea de comando ghe-saml-mapping-csv produjo un mensaje de advertencia.

La etiqueta de los resultados de la búsqueda para los repositorios internos se mostró como "Privada" en vez de como "Interna".

ALTA: Se identificó una vulnerabilidad de ejecución de código remoto en GitHub Enterprise Server, la cual pudo haberse aprovechado al crear un sitio de GitHub Pages. Las opciones de configuración controladas por el usuario que utilizan las GitHub Pages no se restringieron lo suficiente e hicieron posible que se ignoraran las variables de ambiente que llevaron a la ejecución de código en la instancia de GitHub Enterprise Server. Para aprovechar esta vulnerabilidad, un atacante necesitaría permisos para crear y compilar un sitio de GitHub pages en la instancia de GitHub Enterprise Server. Esta vulnerabilidad afectó a todas las versiones de GitHub Enterprise Server antes de la 3.0.3 y se arregló en la 3.0.3, 2.22.9, y 2.21.17. Esta vulnerabilidad se reportó a través del programa de Recompensas por Errores de GitHub y se le asignó un CVE-2021-22864.

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

El ejecutar ghe-cluster-config-init pudo haber causado que un clúster fuera inoperable.

El resolver conflictos de fusión en la GUI fallaba cuando los ganchos de pre-recepción personalizados se configuraban en el repositorio.

launch-deployer y launch-receiver se estaban registrando al nivel de DEBUG y llenaban las bitácoras con información innecesaria.

El sistema pudo haber perdido el rastreo del PID de HAProxy.

Cuando se configuraron las acciones para utilizar un almacenamiento de S3, las bitácoras para una acción fallaban en cargarse algunas veces.

La advertencia de la recuperación de fallos de mysql se mostró indefinidamente después de una recuperación de fallos exitosa.

La ejecución de ghe-cluster-config-init no reconocía completamente el código de salida de los jobs en segundo plano que condujeron a un manejo inadecuado de las verificaciones previas al vuelo.

Al habilitar las GitHub Actions, la inicialización podía fallar silenciosamente.

Cuando se habilitaron las alertas de vulnerabilidades, las actualizaciones a la serie 3.0 fallaron.

Los jobs relacionados con los Codespaces se estaban poniendo en fila, lo cual ocasionó a una acumulación de jobs sin procesar.

Utiliza una cantidad relativa para el bootstrap_expect cónsul y nómada, lo cual permitió que un clúster hiciera un arranque primario, incluso si un conjunto de nodos estaba fuera de servicio.

Las bitácoras rotarán con base en su tamaño adicionalmente al tiempo.

Se agregó a kafka-lite al comando ghe-cluster-status.

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

Al intentar hacer un respaldo, ocurrió un error que indica "Warning: One or more storage objects were not found on the source appliance." al intentar limpiar los objetos de almacenamiento purgables.

La gráfica de dependencias falló en interpretar los archivos de manifiesto de JavaScript `yarn.lock, lo cual dio como resultado errores 500 de HTTP en las bitácoras.

El inhabilitar las GitHub Actions fallará algunas veces.

Los ganchos de pre-recepción personalizados no tenían permiso de escribir en /tmp, previniendo que algunos scripts se ejecutaran correctamente.

Las bitácoras de los diarios de Systemd se duplicaron en varios lugares.

Una zona horaria que se configuró en GitHub Enterprise 11.10.x o anterior se restableció a una hora UTC después de actualizarse a la versión 3.0, lo cual causió que las marcas de tiempo se movieran en algunas instancias.

El hacer clic en "Publicar tu primer paquete" en la barra lateral de los paquetes en un repositorio dirigió a una página en blanco.

Un adminsitrador de sitio podría obtener un error de página 500 al intentar ver las propuestas que se referenciaban de repositorios privados.

Después de inhabilitar GitHub packages, algunas páginas de la organización regresaban una respuesta de error HTTP 500.

El importar repositorios archivados desde GitHub Enterprise Server a los cuales les faltan archivos de repositorio, fallará con un error.

No se pudieron utilizar las llaves de despliegue del repositorio con aquellos repositorios que contenían objetos LFS.

En la barra lateral de paquetes de un repositorio, el icono de Docker se mostraba en gris y un mensaje emergente mostraba la leyenda "Este servicio está obsoletizado".

Los webhooks configurados con un tipo de contenido application/x-www-form-urlencoded no recibieron parámetros de consulta en el cuerpo de la solicitud POST.

Los usuarios pudieron descartar un mensaje obligatorio sin verificar todas las casillas.

En algunos casos, después de actualizar a una instancia 2.22.X, los activo de la interface web se perdieron y la página no se interpretó correctamente.

Pudo haberse agotado el tiempo al ejecutar ghe-config-apply con un error de tipo Failure waiting for nomad jobs to apply due to 'job' stanza not found.

ALTA: Se identificó una vulnerabilidad de control de acceso incorrecto en GitHub Enterprise Server, la cual permitió a un usuario no autenticado de la instancia obtener acceso a los repositorios no autorizados a través de solicitudes de cambios y solicitudes a través de la API de REST configuradas específicamente. El atacante necesitaría poder bifurcar el repositorio de destino, dicha configuración está inhabilitada predeterminadamente para los repositorios privados y para los que pertenecen a una organización. Las protecciones de rama tales como las solicitudes de cambio o verificaciones de estado requeridas prevendrían que las confirmaciones no autorizadas se fusionen sin haber obtenido una revisión o validación adicionales. Se ha asignado un CVE-2021-22861 a esta vulnerabilidad. El problema se reportó a través del Programa de Recompensas por Errores de GitHub.

ALTA: Se identificó una vulnerabilidad de control de acceso incorrecto en la API de GraphQL de GitHub Enterprise Server, la cual permitió a los usuarios autenticados de la instancia modificar el permiso de colaboración del mantenedor para una solicitud de cambios sin una autorización adecuada. Al aprovechar esta vulnerabilidad, el atacante pudo obtener acceso a las ramas de encabezado de las solicitudes de cambios que se abrieron en los repositorios donde ellos eran los mantenedores. La bifurcación se inhabilitó predeterminadamente para los repositorios privados que pertenecían a alguna organización, lo cual previno esta vulnerabilidad. Adicionalmente, las protecciones de rama tales como las revisiones requeridas para la solicitud de cambios o las verificaciones de estado prevendrían que las confirmaciones no autorizadas se fusionen sin contar con una validación o revisión subsecuente. Se asignó un CVE-2021-22863 a esta vulnerabilidad. Este problema se reportó a través del Programa de Recompensas por Errores de GitHub.

ALTA: Se identificó una vulnerabilidad de control de accesos inadecuado en GitHub Enterprise Server, la cual permitió que un usuario autenticado con la capacidad de bifurcar un repositorio divulgara los secretos de las acciones para el repositorio padre de la bifurcación. Esta vulnerabilidad existió debido a una falla que permitió que la referencia base de una solicitud de cambios se actualizara al punto de un SHA arbitrario o de otra solicitud de cambios fuera del repositorio de la bifurcación. Al establecer esta referencia incorrecta en una PR, las restricciones que limitan los secretos de las acciones y que envían un flujo de trabajo desde las bifurcaciones pudieron haberse omitido. Esta vulnerabilidad afectó las versiones de GitHub Enterprise Server 3.0.0, 3.0.0.rc2, y 3.0.0.rc1 y se le asignó un CVE-2021-22862. Esta vulnerabilidad se reportó a través del programa de Recompensas por Errores de GitHub.

MEDIA: Los GitHub tokens de las compilaciones de GitHub Pages pudieron haber terminado en las bitácoras.

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

Las verificaciones de salud del balanceador de carga pudieron haber causado en algunos casos que los logs de babel se llenaran con errores sobre el protocolo del PROXY.

Los encabezados HTTP no cumplían con los estándares de HTTP RFC en respuestas específicas como el estado 304 para los archivos.

En las instancias que hospedan repositorios de Python y que cuentan con la Gráfica de Dependencias habilitada, la instancia pudo haberse quedado sin repsuesta debido a que el disco raíz se llenó con bitácoras de error.

Un mensaje informativo se registro involuntariamente como un error durante las capturas de pantalla de las Utilidades de Respaldo de GitHub Enterprise, lo cual dio como resultado que se enviaran correos electrónicos innecesarios cuando los jobs de cron programaron los respaldos que escuchaban a la salida a stderr.

En VMWare ESX 6.7, la configuración inicial pudo haberse colgado mientras se creaban las claves del host, lo cual dejó a la instancia inaccesible a través de SSH.

Cuando se habilitó GitHub Actions, el inhabilitar el modo de mantenimiento en la consola de administración, falló.

El ajuste de creación de paquetes se mostró en la página de ajustes del miembro de la organización, aunque esta característica aún no está disponible.

Al habilitar el escaneo de secretos en la página de Seguridad y Análisis, el diálogo mencionó los repositorios privados incorrectamente.

El editar una página de wiki, un usuario pudo haber experimentado un error 500 al hacer clic en el botón de guardar.

Una confirmación firmada con S/MIME utilizando un certificado con nombres múltiples en el nombre alternativo de asunto se mostró incorrectamente como "No verificado" en la insignia de confirmación.

Un usuario vio un error 500 al ejecutar operaciones de git en una instancia configurada con autenticación LDAP.

Se enviaron correos electrónicos a un usuario suspendido cuando se le agregó a un equipo.

Cuando un repositorio tuvo una gran cantidad de manifiestos se mostró un error de You have reached the maximum number of allowed manifest files (20) for this repository. en la pestaña ubicada en Perspectivas -> Gráfica de dependencias. Para obtener más información, consulta la sección [Límites de visualización]� (https://docs.github.com/en/github/managing-security-vulnerabilities/troubleshooting-the-detection-of-vulnerable-dependencies#are-there-limits-which-affect-the-dependency-graph-data).

Corrige que se muestren los usuarios en la opción para configurar la acción de CodeQL del Escaneo de Código, incluso si no se habilitaron las acciones para el repositorio.

La casilla de verificación de "Prevent repository admins from changing anonymous Git read access" disponible en la configuración de cuenta empresarial no se pudo habilitar o inhabilitar con éxito.

El modal que se utilizó para mostrar un mensaje obligatorio no contenía una barra de desplazamiento vertical, lo cual significa que los mensajes más largos no se pudieron ver por completo.

Redis a veces fallaba en iniciar después de un reinicio físico o fallo de aplicación.

La gráfica de dependencias falla en interpretar los archivos de manifiesto de Python setup.py, lo cual resultó en errores HTTP 500 en las bitácoras. Esto, en combinación con el problema de bitácoras duplicadas, dio como resultado un incremento en la utilización del volúmen raíz.

Se satisficieron solicitudes de forma concurrente cuando usuarios múltiples estaban descargando el mismo archvio, lo cual dio como resultado un rendimiento mejorado.

ALTA: Se identificó una vulnerabilidad de ejecución de código remoto en GitHub Enterprise Server que podría aprovecharse al compilar un sitio de Páginas de GitHub. La configuración controlada por el usuario de los analizadores subyacentes que utiliza Páginas de GitHub no se restringió lo suficiente y permitió que se ejecutaran comandos en la instancia de GitHub Enterprise Server. Para aprovechar esta vulnerabilidad, un atacante necesitaría permiso para crear y compilar un sitio de Páginas de GitHub en la instancia de GitHub Enterprise Server. A esta vulnerabilidad se le asignó un CVE-2020-10519 y se reportó a través del Programa de Recompensas por Errores de GitHub.

GitHub Actions ahora se encuentra comunmente disponible en GitHub Enterprise Server 3.0+. Crea, prueba y despliega tu código desde GitHub. Emite revisiones de código, administración de ramas y el trabajo de clasificación de propuestas como quieras.

Este lanzamiento incluye varias mejoras del beta para GitHub Actions en GitHub Enterprise Server:

• Los administradores de las empresas, organizaciones y repositorios pueden crear políticas de seguridad para acceder a GitHub Actions en GitHub.com.
• Los administradores de las empresas, organizaciones y repositorios pueden permitir que los repositorios públicos utilicen ejecutores auto-hospedados.
• Los administradores de las empresas, organizaciones y repositorios ahora pueden permitir que los flujos de trabajo se ejecuten en las solicitudes de cambio que se levantan desde las bifurcaciones o desde los repositorios privados.
• El evento de workflow_run ahora es compatible
• Los usuarios ahora tienen la capacidad de inhabilitar los flujos de trabajo y habilitarlos en una fecha posterior.
• Las bitácoras de flujo de trabajo se mejoraron para que tengas una experiencia de usuario mejor.
• Los usuarios ahora pueden utilizar imágenes privadas en los servicios y contenedores de los jobs.
• El máximo de días de retención para los artefactos y las bitácoras ahora puede personalizarse.
• La API del grupo de ejecutores ahora incluye labels.
• Ahora puedes crear acciones reutilizables que utilicen scripts de shell con pasos de ejecución compuestos.
• Los Secretos cifrados para las organizaciones te permiten consolidar los secretos a través de los repositorios.
• Las Plantillas de flujo de trabajo para las organizaciones simplifican y promueven las mejores prácticas y la consistencia a lo largo de tu organización.

Las GitHub Actions no son actualmente compatibles para las empresas que utilizan configuraciones de agrupamiento.

El Registro del paquete de GitHub es un servicio de hospedaje de paquetes que se integra nativamente con las API, acciones y webhooks de GitHub. Crea un flujo de trabajo de DevOps de extremo a extremo que incluye soluciones para tu código, la integración contínua y el despliegue.

Las soluciones administrativas para almacenamiento que son compatibles incluyen a AWS S3 y a MinIO con compatibilidad para Azure blob en un lanzamiento subsecuente. Por favor, toma en cuenta que la compatibilidad actual con Docker se reemplazará con un beta del nuevo Registro de Contenedores de GitHub en el siguiente lanzamiento. Por favor, revisa los requisitos mínimos actualizados para tu plataforma antes de que habilites el Registro del paquete de GitHub.

Cuando publicas paquetes en NuGet, los usuarios ahora pueden utilizar la opción --api-key para pasar su token de autenticación en vez de escribirlo en un archivo. Para obtener más información, consulta la sección Configurar el CLI de dotnet para utilizarlo con GitHub Packages

Actualmente, el Registro del paquete de GitHub no es compatible para las empresas que utilizan configuraciones de agrupamiento.

El beta de GitHub Mobile te permite clasificar las notificaciones y administrar las propuestas y solicitudes de cambio desde tu dispositivo. Puedes firmarte simultáneamente en la aplicación móvil con una cuenta de usuario de GitHub.com y con una de GitHub Enterprise Server.

El beta de GitHub Mobile ahora se encuentra disponible para GitHub Enterprise Server. Ingresa con nuestras apps de Android y de iOS para clasificar las notificaciones y adminsitrar las propuestas y solicitudes de cambio al vuelo. Los administradores pueden inhabilitar la compatibilidad con la versión móvil para su empresa si utilizan la consola de administración o si ejecutan ghe-config app.mobile.enabled false.

El Escaneo de Secretos beta escanea los repositorios públicos y privados para las credenciales confirmadas, encuentra secretos, y notifica al proveedor de secretos o al administrador en el momento en el que éstos se confirman en un repositorio.

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

El escaneo de código de GitHub Advanced Security ahora está comunmente disponible en GitHub Enterprise Server. Las organizaciones que hayan comprado Advanced Security pueden utilizar esta característica para realizar pruebas de seguridad de análisis estático contra su código y pueden prevenir que las vulnerabilidades lleguen a su código productivo utilizando CodeQL, nuestro motor de análisis semántico. Para obtener más información, consulta la sección "Configurar el escaneo de código en tu aplicativo"

El sistema de entrega de eventos de webhook se ha renovado en su arquitectura para tener un rendimiento mayor y menos retraso en los mensajes. También utiliza menos memoria y CPU en GitHub Enterprise Server 3.0+.

Los propietarios de empresas y organizaciones ahora pueden ver a qué miembros del equipo se ha promovido o degradado hacia o desde su puesto como mantenedor de equipo en la bitácora de auditoría a través de los nuevos eventos de bitácora de auditoría team.promote_maintainer y team.demote_maintainer. Para obtener más información, consulta la sección "Acciones auditadas".

Los mantenedores de repositorio con sitios de Páginas de GitHub existentes pueden actualizar fácilmente el nombre de rama predeterminado anterior.

Se requieren recursos adicionales de hardware para ejecutar GitHub Enterprise Server que cuente con cualquier tipo de Acción, Paquete o Seguridad Avanzada habilitados. Para obtener más información sobre los recursos mínimos requeridos para cada plataforma compatible, consulta la sección "Configurar una instancia de GitHub Enterprise Server".

Los administradores ahora pueden publicar un mensaje, que todos los usuarios deben aceptar. Esto te puede ayudar a incorporar usuarios nuevos y hacer notar otras políticas e información específica de la organización.

Los propietarios de las organizaciones ahora pueden inhabilitar la publicación de sitios de Páginas de GitHub de los repositorios de la organización. El inhabilitar a Páginas de GitHub para la organización impedirá que los miembros creen páginas nuevas pero no dejará de publicar los sitios existentes. Para obtener más información, consulta la sección "Inhabilitar la publicación de los sitios de Páginas de GitHub para tu organización".

Se debe definir explícitamente un centro de datos en todos los nodos antes de habilitar una réplica activa.

Todo uso de huellas dactilares de SSH se ha cambiado para utilizar huellas dactilares SHA256 como también se utilizan con OpenSSH desde la versión 6.8. Esto aplica a la interface web y también a la API en donde las huellas dactilares se devuelven, tal como en GraphQL. Las huellas dactilares siguen el formato de OpenSSH.

Los encabezados de firma SHA-1 y SHA-256 (dos encabezados) se envían en webhooks.

La mayoría de los servicios que se ejecutan en GitHub Enterprise Server 3.0+ ahora se encuentran en contenedores que habilitan internamente a GitHub para iterar rapido y para enviar lanzamientos de alta calidad

El sistema de entrega de eventos de webhook renovó su arquitectura para tener un rendimiento mayor, entregas más rápidas y menos retrasos en los mensajes.

Los administradores ahora pueden configurar y administrar el letrero de anuncio de todo el sitio a través de la API de REST. Para obtener más información, consulta las terminales de "administración de GitHub Enterprise".

Una nueva terminal de la API permite el intercambio de un token de usuario a servidor para aquellos que tengan alcance de los repositorios específicos. Para obtener más información, consulta las "Apps" en la documentación de la API de REST de GitHub.

Los administradores de organizaciones y empresas ahora pueden configurar el nombre de la rama predeterminada para los repositorios nuevos. Los administradores de empresas también pueden hacer cumplir su elección de nombre de rama predeterminada a través de todas las organizaciones para permitir que cada una de ellas elija su propio nombre.

Los repositorios existentes no se verán afectados por esta configuración y el nombre de sus ramas predeterminadas no cambiará.

Este cambio es uno de los muchos que GitHub está realizando para apoyar a los proyectos y mantenedores que quieren renombrar su rama predeterminada. Para aprender más sobre los cambios que estamos haciendo, consulta la sección github/renaming.

Todos los problemas que se conocen del Candidato a Lanzamiento 1 y 2 se han corregido, con excepción de las que se listan en la siguiente sección de problemas conocidos.

Los problemas con las migraciones y mejoras a la versión 3.0.0 se arreglaron.

El versionamiento de utilidades de respaldo ahora funciona para las versiones de candidatos de lanzamiento.

El generar un paquete de soporte dio como resultado un error en las bitácoras del orquestador.

Un restablecimiento grande pudo haber dado como resultado que Redis se quedara sin memoria.

La casilla de verificación para habilitar las GitHub Actions en la consola de administración ahora se puede ver con cualquier método de autenticación.

Las GitHub Actions podrían estar habilitadas si también se configuró el almacenamiento necesario.

ghe-repl-status podría fallar silenciosamente si no se configuró la replicación de MSSQL.

El formato de varios archivos de bitácora ha cambiado, incluyendo la adición de un PID para los tipos de bitácora diferentes. Esto no afecta cómo GitHub Enterprise Support utiliza paquetes de soporte para la solución de problemas.

El hacer una solicitud de PATCH a la API de configuración de webhooks ya no borra el secreto del webhook.

Algunos tipos de ganchos de pre-recepción estaban fallando.

El servicio de Paquetes NuGet ahora normaliza las versiones semánticas al publicar. Los clientes de NuGet no pueden descargar una versión semántica inválida (por ejemplo: v1.0.0.0.0.0) y, por lo tanto, se espera que un servicio de NuGet normalice esas versiones (por ejemplo: v1.0.0.0.0.0 --> v1.0.0). Cualquier versión original sin normalizar estará disponible en el campo verbatimVersion. No se requiere de ningún cambio a las configuraciones del cliente.

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

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

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

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

Cuando se habilita el modo de mantenimiento, algunos servicios siguen listándose como "procesos activos". Se espera que los servicios que se identificaron se ejecuten durante el modo de mantenimiento. Si estás experimentando este problema y no sabes cómo proceder, contacta a Soporte de GitHub Enterprise.

Cuando habilitas las GitHub Actions, utiliza 'ghe-maintenance -u' para dejar de configurar el modo de mantenimiento.

El registro duplicado hacia /var/log/messages, /var/log/syslog, y /var/log/user.log da como resultado una utilización incrementada del volúmen raíz.

Los usuarios pueden descartar un mensaje obligatorio sin verificar todas las casillas.

Los scripts de gancho de pre-recepción no pueden escribir archivos temporales, los cuales pueden causar que falle la ejecución del script. Los usuarios que utilizan ganchos de pre-recepción deberían hacer pruebas en un ambiente de pruebas para ver si dichos scripts requieren de acceso de escritura.

Las [llaves de despliegue] de repositorio(/developers/overview/managing-deploy-keys) no pueden utilizarse con repositorios que contengan objetos LFS.

La interpretación de Jupyter Notebook en la IU web podría fallar si el bloc de notas incluye caracteres diferentes a los de ASCII UTF-8.

El reStructuredText (RST) que se representa en la IU web podría fallar y mostrar un texto de marcado RST sin procesar.

La gráfica de dependencias falla en interpretar los archivos de manifiesto de Python setup.py, lo cual resultó en errores HTTP 500 en las bitácoras. Esto, en combinación con el problema de bitácoras duplicadas, dio como resultado un incremento en la utilización del volúmen raíz.

Una condición de carrera puede causar que las migraciones de la base de datos de la dependencia parezcan fallar.

Las instancias con la zona horaria personalizada que se mejoraron desde un lanzamiento anterior de GitHub Enterprise Server podrían tener marcas de tiempo incorrectas en la IU web.

Las compilaciones antiguas de las páginas no se limpiaron, lo cual pudo haber llenado el disco del usuario (/data/user/).

Cuando borras una rama después de fusionar una solicitud de cambios, se mostrará un mensaje de error aunque el borrado de la rama sea exitoso.

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

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

GitHub Enterprise Server 2.19 se encontrará obsoletizado desde el 12 de noviembre de 2020. Eso significa que no se harán lanzamientos de parches, ni siquiera para los problemas críticos de seguridad, después de esta fecha. Para obtener un rendimiento mejor, mejorar la seguridad y tener nuevas características, actualiza a la versión más nueva de GitHub Enterprise Server tan pronto como te sea posible.

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

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

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

El servicio era compatible con una experiencia de "Encontrar por símbolo" en la vista de solicitud de cambios que no se utilizaba ampliamente.

Los comandos de flujo de trabajo de set-env y add-path de GitHub Actions se obsoletizaron. Para obtener más información, consulta el changelog.