Enterprise Server 2.22 release notes

HIGH: Se identificó una vulnerabilidad de navegación de ruta en GitHub Enterprise Server que pudo haberse aprovechado al crear un sitio de Páginas de GitHub. Las opciones de configuración que controla el usuario y que utiliza Páginas de GitHub no se restringieron lo suficiente e hicieron posible que se leyeran archivos en la instancia de GitHub Enterprise Server. Para aprovechar esta vulnerabilidad, los atacantes tendrían que obtener permisos 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 arregló en las versiones 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ó a través del Programa de Recompensas por Errores de GitHub y se le asignó el caso CVE-2021-22868.

La configuración de GitHub Connect de la instancia siempre se restableció a instancias nuevas, incluso cuando no se utilizó la opción --config option para ghe-restore. Esto podría ocasionar un conflicto con la conexión de GitHub Connect y con la sincronización de licencias si tanto las instancias de origen como las de destino estuvieran en línea al mismo tiempo.

Arregla compilaciones de 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.

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

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

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 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.

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 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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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

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

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.

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.

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

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.

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.

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.

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.

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.

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.

Las verificaciones preliminares permiten tipos de instancia de AWS predeterminadamente.

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

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.

El resaltado de sintaxis pudo haber fallado debido a que el contenedor de Treelights se quedó sin memoria.

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

Las alertas de la gráfica de dependencias no se mostraron para algunos componentes cuyas asesorías tienen nombres de paquetes con mayúsculas en vulnerable_version_ranges.

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.

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

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.

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 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 sistema pudo haber perdido el rastreo del PID de HAProxy.

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.

Un enlace de Seguridad y Análisis no aparecía en la barra de navegación izquierda en la página de configuración de los repositorios.

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

Mejora la confiabilidad de los servicios nómadas al implementar la misma política de reinicio que se introdujo en GitHub Enterprise Server 3.0.

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.

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

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

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

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 ejecución de código remoto en GitHub Enterprise Server que pudo haberse aprovechado al compilar un sitio de GitHub pages. La configuración controlada por el usuario de los intérpretes subyacentes que utiliza GitHub Pages no se restringió lo suficiente y dio cabida a la ejecución de comandos en la instancia de GitHub Enterprise Server. Para aprovechar esta vulnerabilidad, un atacante necesitaría permiso para crear y compilar un sitio de GitHub pages en la instancia de GitHub Enterprise Server. Se asignó a esta vulnerabilidad un CVE-2020-10519 y se reportó a través del Programa de Recompensa por Errores de GitHub.

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

BAJA: Una solicitud que se elaboró especialmente para el puente SVN pudo haber activado una espera larga antes de que hubiera una falla, lo cual dio como resultado un ataque de Negación del Servici (DoS).

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.

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.

Al restablecer un respaldo grande, el registro de excepciones relacionado con el agotamiento de memoria de Redis pudo haber causado que la restauración fallara debido a un disco lleno.

Cuando configuras una instancia nueva por primera vez, si se seleccionó "Configurar como réplica", no se podía iniciar la replicación.

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

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.

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

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

El job en segundo plano remove_org_member_package_access pudo visualizarse en la consola de administración e incrementaba contínuamente.

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).

Al cargar un archivo de licencia nuevo con una cantidad de plazas diferente del archivo de licencia anterior, la diferencia de plazas no se representó correctamente en la página de Configuración -> Licencia de la cuenta empresarial.

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.

Cuando una compilación de GitHub Pages falló, la notificación de correo electrónico contenía un enlace incorrecto para la ubicación de soporte.

Durante un año bisiesto, el usuario estuvo obtuvo una respuesta 404 cuando intentó ver la actividad de contribución en un lunes.

Se agregó soporte para los tipos de instanciaAWS EC2 r5b.

Se ajustó la priorización de la cola en segundo plano para distribuir los jobs más equitativamente.

BAJO: El uso alto de CPU puede desencadenarse debido a una solicitud hecha específicamente al puente de SVN, lo cual resulta en una negación del servicio (DoS).

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

Las solicitudes para algunos recursos de archivos como un archivo zip o un archivo raw podrían ingresar en un bucle de redirección.

Un límite de tiempo podría prevenir que algunas búsquedas de propuestas y solicitudes de cambios proporcionen resultados de búsqueda completos.

Las pestañas personalizadas con caracteres no alfabéticos en pantallas pequeñas no se interpretaron correctamente.

Un comportamiento subyacente estaba causando fallas cuando se subía contenido a un repositorio de Git habilitado con LFS.

En algunos casos poco frecuentes las propuestas podrían causar un error 500 cuando se accede a ellas a través de la interface web.

El servicio de autorización se detectó como no saludable debido a la condición de raza en bootstrap, lo cual ocasionó que se reiniciara el servicio.

ghe-diagnostics no estaba capturando el proceso de mejora de Elasticsearch.

El habilitar las GitHub Actions en una configuración de disponibilidad alta mejorada causó errores en la replicación.

Un comportamiento subyacente estaba causando que un servicio estuviera no disponible durante el proceso de mejora del hotpatch.

Los usuarios que se conectaron a una réplica activa obtuvieron un error al conectarse al websocket de las actualizaciones en vivo.

Un subconjunto de certificados SSL que reenviaban bitácoras no se estaba aplicando correctamente.

Se enviaron notificaciones de correo electrónico para suspender usuarios cuando se eliminaban de un equipo o de una organización.

La forma en la que se aplicaron los certificados SSH entre las organizaciones y los negocios fue inconsistente.

Cuando una cuenta se limitó en su tasa debido al uso incorrecto de contraseñas, se pudo haber bloqueado por hasta 24 horas.

La sincronización de solicitudes de cambios en los repositorios con muchas referencias pudo haber causado que se retrasaran las filas de trabajadores.

Al iniciar sesión con un nombre de usuario y contraseña locales (autenticación integrada) después de intentar visitar una página específica, se dirigió al usuario a la página principal en vez de al destino deseado.

Para las instancias de GHES que utilizan una autenticación integrada con un proveedor de identidad de SAML interno, los usuarios sin una dirección de correo electrónico asociada no pudieron crear una confirmación desde la interfase web.

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

Las bitácoras de babeld no tenían un separador entre los segundos y microsegundos.

Después de actualizar a GHES con un hotpatch, los comandos ghe-actions-precheck y ghe-packages-precheck fallaron con el error "docker load" accepts no arguments.

Cuando la política "Cambio de visibilidad del repositorio" en las cuentas empresariales se configura como "Habilitada", los propietarios de las organizaciones no pudieron cambiar la visibilidad de los repositorios dentro de las organizaciones.

Las bitácoras de auditoría podrían atribuirse a la 127.0.0.1 en vez de a la dirección IP origen real.

BAJO: El uso alto de CPU puede desencadenarse debido a una solicitud hecha específicamente al puente de SVN, lo cual resulta en una negación del servicio (Dos) en el servicio del puente SVN. (actualizado 2020-11-16)

BAJO: La validación de un token incorrecto resultó en una entropía reducida para los tokens coincidentes durante la autenticación. El análisis muestra que, en la práctica, aquí no hay riesgos de seguridad significativos.

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

Las GitHub Actions pueden fallar para iniciar exitosamente si se habilitaron previamente en una instancia que ejecutara la versión 2.22.0 y se actualizó a la 2.22.1 o 2.22.2.

Los archivos de configuración para las GitHub Actions no se copiaron a la replica cuando se configuraron las réplicas de disponibilidad alta, lo cual produjo errores durante ghe-repl-promote.

En una instancia 2.22.1 recién configurada o después de actualizar 2.22.1, no se pudo actualizar la fuente de actividad en el tablero de una organización.

El editar las plantillas de las propuestas con los nombres de archivo que contienen caracteres que no son de ASCII fallará con un mensaje de "500 Internal Server Error".

Un método de recolección métrica para los jobs en segundo plano incrementó el uso del CPU. (actualizado 2020-11-03)

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

Si la configuración de la cuenta de almacenamiento falló su validación cuando se configuró GitHub Actions, se requirió ejecutar ghe-actions-teardown antes de hacer un intento nuevo.

Una configuración de proxy personalizado pudo haber afectado de forma adversa al ambiente de GitHub Actions.

En un cambio de dirección de eth0, Nomad y Consul podrían dejar de responder.

Cuando se utilizan certificados auto-firmados, GHES podría tener excepciones de validación de SSL al configurar las GitHub Actions.

El utilizar una GitHub Action desde un nombre de rama con un caracter + o / resultó en un error: Unable to resolve action.

El mensaje de la "Política de confirmación para el requisito bifactorial" en una cuenta empresarial fue incorrecto.

En ciertas solicitudes mayores a 100MB, el buffer de Kafka pudo estar sobreasignado.

MEDIO: ImageMagick se actualizó a la dirección DSA-4715-1.

Las solicitudes de una integración de una GitHub App para actualizar un token de acceso de OAuth se aceptarán si se envían con la ID de cliente y secreto de cliente de OAuth válidos que se utilizaron para crear el token de actualización.

El usuario cuyo nombre de usuario del directorio de LDAP se estandarice a una información de inicio de cuenta de GHES podría autenticarse en la cuenta existente.

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

El menú desplegable de Formato de Id de nombre en la consola de administración se restablecerá a "no especificado" después de configurarlo como "persistente".

Hacer una actualización utilizando un hotpatch podría ocasionar un fallo con un error de tipo: 'libdbi1' was not found

La configuración de guardado a través de la consola de administración añadirá una línea nueva a los archivos de certificado y llave TLS/SSL que activaron la recarga innecesaria de algunos servicios.

Las bitácoras de sistema para la Gráfica de dependencias no estaban rotando, lo cual permitió un crecimiento desmedido del almacenamiento.

La gráfica de rendimiento del servidor de MS SQL mostró las estadísticas de la instancia primaria aún cuando se seleccionó la réplica.

ghe-actions-precheck saldrá silenciosamente sin ejecutar las verificaciones de almacenamiento si no se habilitaron las acciones.

La mejora podría fallar si los trabajadores que se volvieron a poner en cola (resqued) invalidan la configuración que se está utilizando.

Algunos servicios que se ejecutan en los contenedores no estaban enviando bitácoras al diario.

Los enlaces a las Asesorías de Seguridad de GitHub utilizaron una URL con el nombre de host de la instancia de GitHub Enterprise Server en vez de la de GitHub.com, lo cual dirigió al usuario a una URL inexistente.

Cuando importas un repositorio con un ghe-migrator, puede ocurrir una excepción inesperada cuando se presentan los datos inconsistentes.

La página de configuración de seguridad para la cuenta empresarial mostró un enlace para "Visualizar las configuraciones actuales de tus organizaciones" para la configuración de "autenticación bifactorial" cuando el modo de autenticación no es compatible con la autenticación bifactorial incluida.

Los tokens de actualización de OAuth se eliminaron prematuramente.

Las tareas de búsuqeda y reparación generaron excepciones durante la fase de migración de la configuración.

En la página de configuración para las GitHub Apps, las "Características Beta" no se podían visualizar en algunas circunstancias.

Cuando se utiliza ghe-migrator para importar las solicitudes de revisión de PR, los registros asociados con los usuarios borrados resultaron en registros de una base de datos extraña.

Cuando se importan los usuarios con ghe-migrator, ocurrió un error de "El correo electrónico es inválido" si la dirección de correo electrónico que generó el sistema era mayor a 100 caracteres.

El registrar la actividad de los webhooks puede utilizar cantidades grandes de espacio en disco y causar que el disco raíz se llene.

Los usuarios experimentaron un rendimiento más lento de recuperación y de Git clone en una instancia con replicas de disponibilidad alta debido a que las lecturas se reenviaron a un nodo diferente.

La página de configuración del repositorio para los sitios de GitHub Pages de un usuario u organización fallaron con un "500 Internal Server Error".

Las operaciones de mantenimiento de red del repositorio podrían haberse estancado en un estado de running.

El hecho de que un repositorio se borrara inmediatamente después de cargar un resultado de escaneo de código pudo haber causado un estancamiento en el procesamiento de los resultados de dicho escaneo de código en todos los repositorios.

Cuando se emitió una cantidad grande de resultados del escaneo de código al mismo tiempo, el procesamiento de lotes pudo haber agotado el tiempo, lo cual resultó en el estancamiento del procesamiento de los resultados del escaneo de código.

El Crear una GitHub App desde un manifiesto falló.

Los nombres de usuario de GitHub se cambiaron sin querer cuando se utilizó la autentificación con SAML, cuando el nombre de usuario de GitHub no empató con el valor del atributo mapeado en el campo de username en la Consola de Administración.

Se agrega compatibilidad con el tipo de instancia m5.16xlarge de AWS EC2.

Elimina el requisito de las huellas dactilares de SSH en los archivos de ghe-migrator, ya que siempre se le puede calcular.

Los manifiestos de las GitHub Apps ahora incluyen el campo request_oauth_on_install.

GitHub Actions es una solución flexible y poderosa para IC/DC y para la automatización de flujos de trabajo. GitHub Actions en Enterprise Server incluye herramientas que te ayudan a administrar el servicio, incluyendo las métricas clave para la Consola de Administración, bitácoras de auditoría y controles de acceso para ayudarte a controlar los lanzamientos.

Necesitarás proporcionar tu propio storage y ejecturores para las GitHub Actions. AWS S3, Azure Blob Storage y MinIO son compatibles. Por favor, revisa los requisitos mínimos actualizados para tu plataforma antes de que actives las GitHub Actions. Para aprender más, contacta al equipo de ventas de GitHub o regístrate para el beta.

GitHub Packages es un servicio de hospedaje de paquetes, integrado nativamente con las API, Acciones y webhooks de GitHub. Crea un Flujo de trabajo de DevOps de extremo a extremo que incluye tu código, integración contínua y soluciones de despliegue.

El almacenamiento compatible de lado del servidor incluye a AWS S3 y a MinIO con compatibilidad para Azure blob en un lanzamiento futuro. Por favor, nota que la compatibilidad actual con Docker se reemplazará por un beta del nuevo Registro de Contenedores de Github en el próximo lanzamiento. Por favor, revisa los requisitos mínimos actualizados para tu plataforma antes de que actives GitHub Packages. Para aprender más, contacta al equipo de ventas de GitHub o regístrate para el beta.

El escaneo avanzado de seguridad de código de GitHub es un ambiente de pruebas de seguridad para aplicaciones estáticas (SAST) nativo de GitHub. Encuentra vulnerabilidades de seguridad fácilmente antes de que lleguen al ambiente productivo, todo impulsado con el motor de análisis de código más poderoso del mundo: CodeQL.

Los administradores que utilicen la Seguridad Avanzada de Github pueden registrarse para y enable el beta del escaneo avanzado de seguridad de código de GitHub. Por favor, revisa los requisitos mínimos actualizados para tu plataforma antes de que actives el escaneo avanzado de seguridad de código.

Cuando una rama de encabezado de una solicitud de cambios se fusiona y borra, el resto de las solicitudes de cambios abiertas en el mismo repositorio que se dirigen a esta rama ahora se redireccionan a la rama base fusionada de la solicitud de cambios. Anteriormente, estas solicitudes de cambios se cerraron.

Los administradores y usuarios pueden suspender cualquier tipo de acceso a las GitHub Apps por tanto tiempo como sea necesario, y dejar de suspender la app a voluntad mediante la configuración y la API. Las apps suspendidas no pueden acceder a la API o a los eventos de webhook de GitHub. Puedes utilizar esto en vez de desinstalar una aplicación, lo cual revoca la autorización a todos los usuarios. ''

Hemos revisado el acercamiento que tomamos para programar el mantenimiento de red para los repositorios, asegurándonos que los mono-repositorios grandes puedan evitar estados de fallo. ''

Las réplicas pasivas ahora son compatibles y configurables en los despliegues de agrupamiento de GitHub Enterprise Server. Estos cambios habilitarán una recuperación de fallos más rápida, reduciendo tanto el RTO como el RPO.

Para los equipos exepcionalmente grandes, los administradores pueden ajustar el máximo predeterminado de 1,500 elementos para las listas de usuario. ''

Los trabajadores compartidos se habilitaron para proporcionar más resiliencia a las actualizaciones en vivo al compartir las conexiones entre las pestañas.

El enlace de "Contacta a soporte" en las páginas de error de 50x ahora te enlaza con el correo electrónico de soporte o con el enlace configurado en la consola de administración.

Ahora es posible administrar los anuncios globales y las fechas de vencimiento a través de la configuración de cuenta empresarial.

Ahora puedes exentar a algunos usuarios de los límites de tasa predeterminados de la API que se configuran en la consola de administración, en caso de que sea necesario.

Los administradores de repositorio ahora pueden configurar su repositorio con cualquier opción de visibilidad disponible desde un diálogo único en la configuración del repositorio. Anteriormente, tenías que navegar entre secciones, botones y cajas de diálogo separadas para cambiar entre las visibilidades pública y privada y entre las internas y privadas.

Un enlace nuevo de configuración empresarial en el menú desplegable del usuario facilita la navegación a los ajustes de la cuenta empresarial.

Se eliminó el enlace tradicional de "Centro de administración" en la página de /stafftools. El enlace de "Empresa" ahora es la mejor forma de navegar a la cuenta empresarial desde la página de /stafftools.

El elemento de sub-menú de opciones en la configuración de la cuenta empresarial se migró desde la sección de Configuración hasta la de Políticas.

El acceder a los recursos de acceso utilizando un token de acceso personal o una llave SSH ahora cuenta como una actividad de usuario. Esto evita a los administradores la carga de filtrar algunos usuarios de los reportes de usuarios durmientes y hace más seguro el uso del botón "Suspender todos" sin suspender accidentalmente a los usuarios que solo acceden a GitHub en forma de solo lectura a través de las API con un token de acceso personal (PAT) o llave SSH.

Los códigos de recuperación bifactoriales ya no pueden utilizarse durante el proceso de inicio de sesión con dos factores. Las contraseñas de una sola ocasión son los únicos valores aceptables.

Cuando un usuario inicia sesión en GitHub Enterprise Server mediante un inicio de sesión único, la selección de visibilidad predeterminada del repositorio es privada.

Los propietarios de las GitHub Apps ahora pueden escoger que sus tokens de acceso de usuario a servidor venzan después de 8 horas, para ayudar a reforzar la rotación habitual de tokens y reducir el impacto de que existan tokens en riesgo.

La IU de GitHub actualizó su diseño, y la página principal de los repositorios se rediseñó e incluyó un diseño receptivo yuna experiencia web móvil mejorada.

En el menú desplegable "Clonar con SSH" de los repositorios, se notificará ahora a los usuarios si no han configurado ninguna llave.

Las confirmaciones ahora se ordenan cronológicamente en la línea de tiempo de las solicitudes de cambios y en la pestaña de confirmaciones. Este orden nuevo también se refleja en la API de REST de "Listar comnfirmaciones en una solicitud de cambios" y en el ["Objeto PullRequest"] de GraphQL (https://docs.github.com/en/enterprise/2.22/user/graphql/reference/objects#pullrequest) timeline connection.

Los usuarios ahora pueden configurar un tono de tema predeterminado para los resultados de autocompletado de emojis en las áreas de texto de los comentarios.

Tree-sitter mejora el resaltado de sintaxis y ahora es la biblioteca predeterminada que se utiliza para en análisis de los lenguajes de programación.

Los desarrolladores y las organizaciones ahora pueden agregar sus nombres de usuario de Twitter a sus perfiles

Vistas previas graduadas

Las siguientes vistas previas ahora son parte oficial de la API:

• La API y terminales de las GitHub Apps que devolvían la propiedad performed_via_github_app ya no requieren el encabezado de vista previa machine-man.
• Para agregar y ver una razón de bloqueo de una propuesta, ya no necesitas utilizar el encabezado de vista previa sailor-v.

Cambios al modelo de GraphQL

• Los cambios al modelo de GraphQL incluyen aquellos retro-compatibles, vistas previas del modelo, y cambios significativos próximos.

El adaptador de red predeterminado de GitHub Enterprise Server para los clientes de VMware se cambió de E1000 a VMXNET3, comenzando con el lanzamiento 2.22.0. Cuando se actualiza desde una versión anterior a la 2.22.0 o superior, si se detecta un adaptador de red E1000 durante la verificación de pre-mejora, se mostrará el siguiente mensaje en la línea de comandos:

WARNING: Your virtual appliance is currently using an emulated Intel E1000 network adapter.
For optimal performance, please update the virtual machine configuration on your VMware host to use the VMXNET3 driver.
Proceed with installation? [y/N]

El administrador puede elegir actualizar el tipo de adaptador de red a VMXNET3 ya sea antes o después de que se mejore el GitHub Enterprise Server. El aplicativo virtual necesitará apagarse para este cambio. Los clientes deben seguir los pasos recomendados de VMware para cambiar la configuración del adaptador de red de la máquina virtual a VMXNET3. Por favor, nota que VMXNET3no será una opción si la versión del SO para el aplicativo virtual se configura en Other Linux (64-bit). En este caso, primero se tendrá que cambiar la versión del SO de Other Linux (64-bit) a Other 2.6.x Linux (64-bit) o, en caso de que esté disponible, a Debian GNU/Linux 9 . Te recomendamos probar estos cambios en una instancia de montaje antes de que se mueva a un ambiente productivo de GitHub Enterprise Server.

La página de stafftools para visualizar colaboradores pendientes mostró un 500 Internal Server Error cuando había una invitación de correo electrónico pendiente.

La verificación desalud del repositorio en stafftools puede mostrar resultados incorrectos en los repositorios ocupados.

Un usuario que inició sesión e intentó aceptar una invitación por correo electrónico pudo encontrarse con un error 404 Not Found.

Si los usuarios navegan a un repositorio cuyo nombre iniciaba con "repositories.", se les redirigió a la pestaña de "Repositorios" del propietario en vez de llegar a la página de resumen de éste.

Las etiquetas en la línea de tiempo del tablero no tienen suficiente contraste.

GitHub Enterprise Server 2.19 se obsoletizará desde el 12 de noviembre de 2020 Esto significa que no se harán lanzamientos de parches, aún para los problemas de seguirdad críticos, después de esta fecha. actualiza a la versión más nueva de GitHub Enterprise Server tan pronto como te sea posible.

A partir de la versión 2.21.0 de GitHub Enterprise Server, dos webhooks relacionados con GitHub Apps tradicionales se obsoletizaron y se eliminarán en la versión 2.25.0 de dicho producto. Los eventos obsoletizados de integration_installation y integration_installation_repositories tienen eventos equivalentes que serán compatibles. Hay más información disponible en la publicación del blog sobre los anuncios de obsoletización.

A partir de la versión 2.21.0 de GitHub Enterprise Server, se obsoletizará la terminal tradicional de las GitHub Apps para crear tokens de acceso ainstalaciones y se eliminará en la versión 2.25.0 de dicho producto. Hay más información en la publicación del blog sobre los anuncios de obsoletización.

GitHub ya no es compatible con las terminales de las aplicaciones OAuth que contengan access_token como parámetro de ruta. Incluimos terminales nuevas que te permiten administrar los tokens de forma segura para las Apps de OAuth al migrar access_token hacia el cuerpo de la solicitud. Aunque se obsoletizaron, aún se puede acceder a las terminales en esta versión. Pretendemos eliminar estas terminales para la versión 3.4 de GitHub Enterprise Server. Para obtener más información, consulta la publicación del blog sobre los anuncios de obsoletización.

GitHub Enterprise Server 2.22 requiere por lo menos las Utilidades de Respaldo de GitHub Enterprise 2.22.0 para hacer Respaldos y Recuperación de Desastres.