Enterprise Server 3.2 release notes

Packages have been updated to the latest security versions.

Custom pre-receive hooks could have failed due to too restrictive virtual memory or CPU time limits.

In a GitHub Enterprise Server clustering configuration, Dependency Graph settings could have been incorrectly applied.

Attempting to wipe all existing configuration settings with ghe-cleanup-settings failed to restart the Management Console service.

During replication teardown via ghe-repl-teardown Memcached failed to be restarted.

During periods of high load, users would receive HTTP 503 status codes when upstream services failed internal healthchecks.

Pre-receive hook environments were forbidden from calling the cat command via BusyBox on Alpine.

Failing over from a primary Cluster datacenter to a secondary Cluster datacenter succeeds, but then failing back over to the original primary Cluster datacenter failed to promote Elasticsearch indicies.

The "Import teams" button on the Teams page for an Organization returned an HTTP 404.

Using the API to disable Secret Scanning correctly disabled the property but incorrectly returned an HTTP 422 and an error message.

In some cases, GitHub Enterprise Administrators attempting to view the Dormant users page received 502 Bad Gateway or 504 Gateway Timeout response.

Performance was negatively impacted in certain high load situations as a result of the increased number of SynchronizePullRequestJob jobs.

A user defined pattern created for Secret Scanning would continue getting scanned even after it was deleted.

GitHub Apps now set the Secret Scanning feature on a repository consistently with the API.

Los clientes de GitHub Advanced Security ahora pueden especificar los patrones para el escaneo de secretos. Cuando se especifica un patrón nuevo, el escaneo de secretos busca dicho patrón en todo el historial de Git del repositorio, así como cualquier confirmación nueva.

Los patrones definidos por los usuarios se encuentran en beta para GitHub Enterprise Server 3.2. Se pueden definir a nivel de repositorio, organización y empresa. Para obtener más información, consulta la sección "Definir patrones personalizados para el escaneo de secretos".

Los clientes de la GitHub Advanced Security ahora tienen una vista de nivel de organización apra los riegos de seguridad de las aplicaciones que detecte el escaneo de código, el Dependabot y el escaneo de secretos. El resumen de seguridad muestra la habilitación de estado de las características de seguridad en cada repositorio, así como la cantidad de alertas que se detectan.

Adicionalmente, el resumen de seguridad lista todas las alertas del escaneo de secretos a nivel organizacional. Tendremos vistas similares para el Dependabot y el escaneo de código en los lanzamientos futuros cercanos. Para obtener más información, consulta la sección "Acerca del resumen de seguridad".

Los clientes de GitHub Advanced Security ahora pueden ver un diff enriquecido de las dependencias que cambiaron en una solicitud de cambios. La revisión de dependencias proporciona una vista fácil de entender de los cambios a las dependencias y de su impacto de seguridad en la pestaña de "Archivos que cambiaron" de las solicitudes de cambios. Esta te informa de las dependencias que se agregaron, eliminaron o actualizaron junto con la información de vulnerabilidades de estas dependencias. Para obtener más información, consulta la sección "Revisar los cambios de dependencias en una solicitud de cambios".

Los ambientes, las reglas de protección de ambiente y los secretos de ambiente ahora están disponibles en general para las GitHub Actions en GitHub Enterprise Server. Para obtener más información, consulta la sección "Environments".

Ahora es compatible la autenticación por SSH utilizando una llave de seguridad FIDO2 cuando agregas una llave SSH de tipo sk-ecdsa-sha2-nistp256@openssh.com o sk-ssh-ed25519@openssh.com a tu cuenta. Las llaves de seguridad SSH almacenan material de llaves secretas en un dispositivo de hardware por separado, el cual requiere de verificación, tal como un tap, para operar. Para obtener más información, consulta la sección "Generar una clave SSH nueva y agregarla al ssh-agent".

Ahora hay temas oscuro y opaco oscuro disponibles para la IU web. GitHub Enterprise Server empatará las preferencias de tu sistema si no has configurado las preferencias de tema en GitHub Enterprise Server. También puedes elegir qué temas estarán activos durante el día y la noche. Para obtener más información, consulta la sección "Administrar la configuración de tu tema".

Los dominios que no se pueden verificar ahora pueden aprobarse para el enrutamiento de notificaciones por correo electrónico. Los propietarios de empresas y organizaciones podrán aprobar dominios y aumentar su política de restricción de notificaciones por correo electrónico automáticamente, lo cual permitirá que las notificaciones se envíen a los colaboradores, consultores, adquisiciones o a otros socios. para obtener más información, consulta las secciones "Verificar o aprobar un dominio para tu empresa" y "Restringir las notificaciones por correo electrónico para tu empresa."

Las versiones 2.0.452 y posteriores del Administrador de Credenciales de Git (GCM) Core ahora proporcionan compatibilidad de almacenamiento de credenciales con seguridad fortalecida y autenticación multifactorial para GitHub Enterprise Server.

El GCM Core con compatibilidad para GitHub Enterprise Server se incluye con Git para Windows en sus versiones 2.32 y posterior. GCM Core no se incluye con Git para macOS o para Linux, pero puede instalarse por separado. Para obtener más información, consulta el lanzamiento más reciente y las instrucciones de instalación en el repositorio microsoft/Git-Credential-Manager-Core.

Se agregó un ajuste de "Política de Referente de Agente Usuario" a la configuración empresarial. Esto permite que un administrador configure una "Política de referente" más estricta para ocultar el nombre de host de una instalación de GitHub Enterprise Server de sitios externos. Este ajuste se encuentra inhabilitado predeterminadamente y los eventos de bitácoras de auditoría lo rastrean para los propietarios empresariales y el personal de las empresas cuando se habilita o inhabilita. Para obtener más información, consulta la sección "Configurar la Política de Referente en tu empresa".

La revisión de salud de MySQL se cambió al uso de mysqladmin ping en vez de las verificaciones de TCP, lo cual elimina algo del ruido innecesario en la bitácora de errores de MySQL, las verificaciones de recuperación de fallos del orquestador se mejoraron para prevenir las recuperaciones de fallos de MySQL innecesarias al aplicar cambios de configuración del clúster.

El servicio Resque, el cual da la compatibilidad con procesamiento de jobs en segundo plano, se reemplazó con Aqueduct Lite. este cambio hace que el sistema de jobs se pueda administrar más fácilmente y no debería afectar la experiencia del usuario. Para la administración y comandos de depuración nuevas de Aqueduct, consulta la sección "Utilidades de la línea de comandos".

El formato de tokens de autenticación para GitHub Enterprise Server ha cambiado,. Dicho cambio afecta el formato de los tokens de acceso personal y de los tokens de acceso para las OAuth Apps, así como de los tokens de usuario a servidor, de servidor a servidor y de actualización para GitHub Apps.

Los diferentes tipos de token ahora tienen prefijos identificables únicos, los cuales permiten que el escaneo de secretos detecten los tokens para que puedas mitigar el impacto de que alguien confirme un token accidentalmente en un repositorio. GitHub recomienda actualizar los tokens existentes tan pronto como te sea posible. Para obtener más información, consulta las secciones "Acerca de la autenticación en GitHub" y "Acerca del escaneo de secretos".

Los repositorios en los perfiles de usuario y en los perfiles de organización ahora son compatibles con la clasificación por conteo de estrellas.

Cuando veas el historial de confirmación de un archivo único, ahora puedes hacer clic en para ver dicho archivo en algún punto selecto del historial.

Cuando un submódulo se define con una ruta relativa en tu instancia de GitHub Enterprise Server, el submódulo ahora se puede hacer clic en la interfaz web. Al hacer clic en el submódulo de la interfaz web le llevará al repositorio enlazado. Anteriormente, sólo los submódulos con URLs absolutas podían hacer clic. Esto es soportado para rutas relativas para los repositorios con el mismo propietario que siguen el patrón ..REPOSITORY o rutas relativas de repositorios con un propietario diferente que siga el patrón ../OWNER/REPOSITORY. Para obtener más información sobre cómo trabajar con submódulos, consulta la sección Trabajar con submódulos en el blog de GitHub.

La IU web ahora puede utilizarse para sincronizar una rama desactualizada de una bifurcación con la rama ascendente de dicha bifurcación. Si no hay conflictos de fusión entre las ramas, la rama se actualizará ya sea mediante un envío rápido o mediante la fusión desde la parte ascendente. Si hay conflictos, se te pedirá crear una solicitud de cambios para resolverlos. Para obtener más información, consulta la sección "Sincronizar una bifurcación".

El editor de lenguaje de marcado que se utiliza al crear o editar un lanzamiento en un repositorio ahora tiene una barra de herramientas para edición de texto. Para obtener más información, consulta la sección "Adminsitrar los lanzamientos en un repositorio".

GitHub Enterprise Server ahora tiene compatibilidad para cargar archivos de video en donde sea que utilices lenguaje de marcado. Comparte demostraciones, pasos de reproducción y más en los comentarios de tus propuestas y solicitudes de cambio, así como en los archivos de lenguaje de marcado dentro de los repositorios, tales como los README. Para obtener más información, consulta la sección "Adjuntar archivos".

Los archivos de lenguaje de marcado ahora generarán una tabla de contenido automáticamente en el encabezado cuando haya 2 o más encabezados. La tabla de contenido es interactiva y enlaza a la sección seleccionada. Los 6 niveles de encabezado del lenguaje de marcado son compatibles.

Hay un atajo de teclado nuevo, cmd+e en macOS o ctrl+e en Windows, para insertar bloques de código en los archivos, propuestas, solicitudes de cambio y comentarios de Lenguaje de Marcado.

El agregar ?plain=1 a la URL en cualquier archivo de lenguaje de marcado ahora mostrará al archivo sin procesar y con números de línea. La vista simple puede utilizarse para enlazar a otros usuarios a líneas específicas. Por ejemplo, el agregar ?plain=1#L52 resaltará la línea 52 del archivo de marcado en texto simple. Para obtener más información, consulta la sección "Crear un enlace permanente a un fragmento de código".

Con la versión más reciente de Octicons, los estados de las propuestas y solicitudes de cambios ahora son más fáciles de distinguir visualmente para que puedas escanear los estados de forma más sencilla. Para obtener más información consulta la sección el blog de GitHub.

Ahora tenemos disponible una regla de protección de rama de "Requerir la resolución de la conversación antes de fusionar" y un menú de "Conversaciones". Descubre fácilmente tus comentarios de solicitudes de cambios desde la pestaña de "Archivos que cambiaron" y requiere qeu todas tus conversaciones en solicitudes de cambio se resuelvan antes de fusionarse. Para obtener más información, consulta las secciones "Acerca de las revisiones de solicitudes de cambio" y "Acerca de las ramas protegidas".

Para prevenir la fusión de cambios inesperados después de habilitar la fusión automática para una solicitud de cambios, ahora se inhabilitó esta opción automáticamente cuando un usuario sin acceso de escritura al repositorio sube estos cambios. Los usuarios que no tengan permisos de escritura aún pueden actualizar la solicitud de cambios con aquellos de la rama base cuando se habilita la fusión automática. Para prevenir que un usuario malintencionado utilice un conflicto de fusión para introducir cambios inesperados a la solicitud de cambios, la fusión automática para la solicitud de cambios se encuentra inhabilitada si dicha actualización causa un conflicto de fusión. Para obtener más información sobre la fusión automática, consulta la sección "Fusionar una solicitud de cambios automáticamente".

Las personas con permisos de mantenimiento ahora pueden administrar el ajuste de "Permitir la fusión automática" a nivel de repositorio. Este ajuste, el cual a menudo se encuentra inhabilitado, controla si la fusión automática está disponible para las solicitudes de cambios en el repositorio., Anteriormente, solo las personas con permisos administrativos podían administrar este ajuste. Adicionalmente, este ajuste ahora puede controlarse utilizando las API de REST para "Crear repositorio" y "Actualizar repositorio". Para obtener más información, consulta la sección "[Administrar la fusión automática para las solicitudes de cambios en tu repositorio]](/github/administering-a-repository/configuring-pull-request-merges/managing-auto-merge-for-pull-requests-in-your-repository)".

La selección de propuestas y solicitudes de cambio de los asignados ahora es compatible con la búsqueda de escritura anticipada, así que puedes encontrar usuarios en tu organización más rápidamente. Adicionalmente, las clasificaciones de resultados de búsqueda se actualizaron para preferir las coincidencias al inicio del nombre de usuario de una persona o nombre de perfil.

Cuando se solicita una revisión de un equipo de más de 100 personas, los desarrolladores ahora muestran una caja de diálogo de confirmación para poder prevenir las notificaciones innecesarias para los equipos grandes.

Ahora hay compatibilidad con tener code blocks con comilla inversa en los títulos de las propuestas y en cualquier lugar en el que se referencien propuestas y solicitudes de cambios en GitHub Enterprise Server.

Los eventos para las solicitudes de cambios y revisiones de solicitudes de cambios ahora se incluyen en la bitácora de auditoría tanto para enterprises como para organizations. estos eventos ayudan a que los administradores monitoreen mejor la actividad de las solicitudes de cambios y ayuden a garantizar que se cumplan los requisitos de seguridad y cumplimiento. Los eventos pueden verse desde la IU web, exportarse como CSV o JSON o acceder a ellos a través de la API de REST. También puedes buscar la bitácora de auditoría para los eventos de solicitudes de cambio específicos. Para obtener más información, consulta la sección "Revisar la bitácora de auditoría para tu organización".

El nombre de rama predeterminado para los repositorios nuevos ahora es main. Los repositorios existentes no se verán impactados por este cambio. Si los usuarios, propietarios de organizaciones o propietarios de empresas ya especificaron una rama predeterminada para repositorios nuevos anteriormente, tampoco se les impactará.

Si quieres configurar un nombre de rama predeterminada diferente, puedes hacerlo en los ajustes de user, organization, o enterprise.

Las ramas, incluyendo a la predeterminada, ahora pueden volver a nombrarse utilizando la IU web de GitHub Enterprise Server. Cuando una rama se vuelve a nombrar, cualquier solicitud de cambios abierta y lanzamiento de borrador que apunten a la rama que se volvió a nombrar se redirigirá automáticamente y las reglas de protección de rama que referencien explícitamente a la rama que se volvió a nombrar se actualizarán.

Se requieren permisos administrativos para volver a nombrar la rama predeterminada, pero es suficiente contar con permisos de escritura para volver a nombrar otras ramas.

Para ayudar a hacer el cambio con tanta continuidad como sea posible para los usuarios:

• Se muestra un aviso a los contribuyentes, mantenedores y administradores de la página de inicio del repositorio, el cual contiene instrucciones para actualizar su repositorio local. *Las solicitudes web para la rama antigua se redireccionarán.
• Se devolverá una respuesta HTTP de "se movió permanentemente" a todo llamado de la API de REST.
• Se mostrará un mensaje informativo para los usuarios de la línea de comandos de Git que suban información a la rama antigua.

Para obtener más información, consulta la sección "Volver a nombrar una rama".

Las GitHub Actions ahora te permiten controlar los permisos que se otorgan al secreto del GITHUB_TOKEN. El GITHUB_TOKEN es un secreto que se genera automáticamente y te permite hacer llamados autenticados a la API de GitHub Enterprise Server en tus ejecuciones de flujo de trabajo. Las GitHub Actions generan un token nuevo para cada job y hacen que el token venza cuando se completa el job. El token a menudo tiene permisos de escritura para varias Terminales de la API, con excepción de los casos de las solicitudes de cambios de las bifurcaciones, los cuales siempre se marcan como de lectura. Estos ajustes nuevos te permiten seguir el principio de los menores privilegios necesarios en tus flujos de trabajo,. Para obtener más información, consulta la sección "Autenticación en un flujo de trabajo".

El CLI de GitHub 1.9 y posterior te permiten trabajar con las GitHub Actions en tu terminal. Para obtener más información, consulta la sección Registro de cambios de GitHub.

La bitácora de auditoría ahora incluye eventos asociados con las ejecuciones de flujo de trabajo de GitHub Actions. Estos datos proporcionan un conjunto de datos ampliamente expandidos para los administradores, así como auditorías de cumplimiento. Para obtener más información, consulta la sección "Revisar la bitácora de auditoría de tu organización".

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

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

Cualquier paquete o versión de paquete del Registro del paquete de GitHub ahora se puede borrar de la IU web de GitHub Enterprise Server. También puedes deshacer el borrado de cualquier paquete o versión de paquete dentro de los primeros 30 días. Para obtener más información, consulta la sección "Borrar y restablecer un paquete".

La gráfica de dependencias ahora puede habilitarse utilizando la Consola de Administración en vez de necesitar la ejecución de un comando en el shell administrativo. Para obtener más información, consulta la sección "Habilitar las alertas para las dependencias vulnerables de GitHub Enterprise Server".

Ahora, las notificaciones para Las alertas del dependabot múltiples se agrupan si se descubren al mismo tiempo. Esto reduce significativamente el volumen de notificaciones de alertas del Dependabot que reciben los usuarios. Para obtener más información, consulta la sección Registro de cambios de GitHub.

Las gráficas de dependencias y Las alertas del dependabot ahora son compatibles con los módulos de Go. GitHub Enterprise Server analiza los archivos de go.mod de un repositorio para entender las dependencias del mismo. En conjunto con las asesorías de seguridad, la gráfica de dependencias proporciona la información necesaria para alertar a los desarrolladores sobre las dependencias vulnerables. Para obtener más información sobre cómo habilitar la gráfica de dependencias en los repositorios privados, consulta la sección "Asegurar tu repositorio".

Los ajustes de notificación predeterminados para las alertas de seguridad han cambiado. Anteriormente, si tenías permiso para ver las alertas de seguridad en un repositorio, hubieras recibido las notificaciones de dicho repositorio mientras tu configuración permitiera las notificaciones de alertas de seguridad. Ahora debes decidir unirte a las notificaciones de alertas de seguridad observando el repositorio. Se te notificará si seleccionas Toda la actividad o si configuras Personalizado para incluir las Alertas de seguridad. Todos los repositorios existentes se migrarán automáticamente a estos ajustes nuevos y seguirás recibiendo notificaciones; sin embargo, cualquier repositorio nuevo requerirá que decidas unirte observando el repositorio. Para obtener más información, consulta las secciones "Configurar notificaciones para las dependencias vulnerables" y "Administrar las alertas del escaneo de secretos".

El Escaneo de código con CodeQL ahora genera información diagnóstica para todos los lenguajes compatibles. Esto ayuda a mantener el estado de la base de datos creada para entender el estado y calidad del análisis que se realizó. La información diagnóstica se encuentra disponible desde la versión 2.5.6 del CodeQL CLI](https://codeql.github.com/docs/codeql-cli/). Puedes ver esta información diagnóstica detallada en las bitácoras para CodeQL de las GitHub Actions. Para obtener más información, consulta la sección "Visualizar las bitácoras de escaneo de código".

El Escaneo de código con CodeQL CLI ahora es compatible con el análisis de diversos lenguajes durante una compilación sencilla. Esto facilita el ejecutar análisis de código para utilizar sistemas de IC/DC diferentes a los de las GitHub Actions. El modo nuevo del comando codeql database create se encuentra disponible desde la [versión 2.5.6] (https://github.com/github/codeql-cli-binaries/releases) del [CodeQL CLI] (https://codeql.github.com/docs/codeql-cli/). Para obtener más información sobre cómo configurar esto, consulta la sección "Instalar el CodeQL CLI en tu sistema de IC".

Las alertas de Escaneo de código de todas las herramientas habilitadas ahora se muestran en una lista consolidada para que puedas priorizar fácilmente entre todas ellas. Puedes ver las alertas desde una herramienta específica utilizando le filtro de "Herramienta" y los de "Regla" y "Etiqueta" se actualizarán dinámicamente con base en tu selección de "Herramientas".

El Escaneo de código cib CodeQL ahora incluye soporte beta para analizar código de C++20. Esto solo está disponible cuando creas bases de código con GCC en Linux. Los módulos de C++20 aún no son compatibles.

La profundidad del análisis de CodeQL se mejoró al agregar compatibilidad para más librerías y marcos de trabajo y al incrementar la cobertura de nuestros modelos de marcos de trabajo y librerías para varios lenguajes ({C++](https://github.com/github/codeql/tree/main/cpp), JavaScript, Python, y Java). Como resultado, el CodeQL ahora puede detectar aún más fuentes potenciales de datos de usuarios no confiables, revisar los pasos a través de los cuales fluyen los datos e identificar hundimientos potencialmente peligrosos en los cuales podrían terminar estos datos,. Esto da como resultado una mejora general de la calidad de las alertas del escaneo de código. Para obtener más información, consulta la sección de registro de cambios de GitHub.

El Escaneo de código ahora muestra niveles de gravedad de seguridad para las alertas del Code QL. Puedes configurar qué niveles de gravedad de seguridad ocasionarán un fallo de verificación para una solicitud de cambios. El nivel de gravedad de las alertas de seguridad puede ser crítico, alto, medioobajo. Predeterminadamente, cualquier alerta del escaneo de código con un nivel de gravedadque seacríticooalto` ocasionará que una solicitud de cambios falle.

Adicionalmetnte, ahora también puedes configurar qué niveles de gravedad ocasionarán que la verificación de solicitudes de cambio falle para las alertas que no sean de seguridad. Puedes configurar este comportamiento a nivel de repositorio y definir si las alertas con gravedad de error, advertencia o nota ocasionarán que una verificación de solicitud de cambio falle. Predeterminadamente, las alertas del escaneo de código que no sean de seguridad y tengan un nivel de gravedad de error ocasionarán que la verificación de una solicitud de cambios falle.

Para obtener más información, consulta la sección "[Definir qué alertas de niveles de gravedad ocasionan que falle la verificación de las solicitudes de cambio]](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning#defining-the-severities-causing-pull-request-check-failure)".

Las mejoras al filtro de rama para las alertas del escaneo de código dejan más claro qué alertas del escaneo de código se están mostrando en la página de alertas. Predeterminadamente, las alertas del escaneo de código se filtran para mostrar únicamente las alertas de la rama predeterminada del repositorio. Puedes utilizar el filtro de rama para mostrar las alertas en cualquiera de las ramas no predeterminadas. Cualquier filtro de rama que se haya aplicado se mostrará en la barra de búsqueda.

La sintaxis de búsqueda también se simplificó como branch:<branch name>. Esta sintaxis se puede utilizar varias veces en la barra de búsqueda para filtrar en ramas múltiples. La sintaxis previa ref:refs/heads/<branch name>, aún es compatible, así que cualquier URL que se haya guardado seguirá funcionando.

Ahora está disponible la búsqueda de texto libre para las alertas de escaneo de código. Puedes buscar resultados del escaneo de código para encontrar alertas específicas rápidamente sin tener que conocer los términos de búsqueda exactos. La búsqueda se aplica a lo large del nombre, descripción y texto de ayuda de la alerta. La sintaxis es:

• Una palabra única devuelve todas las coincidencias.
• Las palabras de búsqueda múltiples devuelven coincidencias para cualquiera de las palabras.
• Las palabras entre comillas dobles devuelven coincidencias exactas.
• La palabra clave 'AND' devuelve coincidencias de palabras múltiples.

Escaneo de secretos agregó patrones para 23 proveedores de servicio nuevos. Para encontrar la lista actualizada de secretos compatibles, consulta la sección "Acerca del escaneo de secretos".

La compatibilidad con paginación se agregó a la terminar de "comparar dos confirmaciones" de la API de REST, la cual devuelve una lista de confirmaciones que se pueden alcanzar desde una confirmación o rama, pero no desde alguna otra. La API ahora también puede devolver los resultados para comparaciones de más de 250 confirmaciones. Para obtener más información, consulta la sección de "Repositories" de la API de REST y la sección de "Navegar con paginación".

La API de REST ahora puede utilizarse para reenviar mediante programación o verificar el estado de los webhooks. Para obtener más información, consulta las secciones "Repositories," "Organizations," y "Apps" in the REST API documentation.

Se han realizado mejoras al escaneo de código y a las API de la GitHub Advanced Security:

• La API de escaneo de código ahora devuelve la versión de consulta de COdeQL que se utiliza para un análisis. Esto puede utilizarse para reproducir los resultados o confirmar un análisis que se utiliza como la consulta más reciente. Para obtener información, consulta la sección "Escaneo de código" en la documentación de la API de REST. -Los usuarios administrativos ahora pueden utilizar la API de REST para habilitar o inhabilitar la GitHub Advanced Security para repositorios utilizando el objeto security_and_analysis en repos/{org}/{repo}. Adicionalmente, los usuarios administrativos pueden verificar si la Advanced Security se encuentra habilitada actualmente para un repositorio utilizando una solicitud de tipo GET /repos/{owner}/{repo}. Estos cambios de ayudan a administrar el acceso a los repositorios de Advanced Security en escala. Para obtener más información, consulta la sección de "Repositories" en la documentación de la API de REST.

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 de cortafuegos personalizadas se eliminan durante el proceso de actualización.

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

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

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

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

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.21 se descontinuó el 6 de junio de 2021. Esto significa que no se harán lanzamientos de parche, aún para los problemas de seguridad crítucos, después de esta fecha. Para obtener un rendimiento mejor, una seguridad mejorada y características nuevas, actualiza a la última versión de GitHub Enterprise Server tan pronto te sea posible.

GitHub Enterprise Server 2.22 se descontinuará el 23 de septiembre de 2021. Esto significa que no se harán lanzamientos de parches, incluso para los problemas de seguridad, después de dicha fecha. Para tener un rendimiento mejor, una seguridad mejorada y cualquier característica nueva, actualiza a la versión más nueva de GitHub Enterprise Server tan pronto te sea posible.

Desde la versión 3.1 de GitHub Enterprise Server, comenzaremos a descontinuar la compatibilidad con Xen Hypervisor. La obsoletización completa está programada para la versión 3.3 de GitHub Enterprise Server, siguiendo la ventana de obsoletización estándar de un año. Por favor, contacta al Soporte de Github so tienes dudas o preguntas.

GitHub Enterprise Server 3.2 elimina los registros de base de datos de GitHub Service sin utilizar. Hay más información disponible en la publicación del anuncio de obsoletización.

Para prevenir el inicio de sesión o exposición accidental de los access_tokens, desalentamos el uso de las terminales de la API de las Aplicaciones OAuth y el uso de auth de API a través de parámetros de consultas. Visita las siguientes publicaciones para ver los reemplazos propuestos:

*Reemplazo para las terminales de la API de Aplicaciones OAuth

• Reemplazo de auth a través de encabezados en vez de parámetros de consulta

Se pretende que estas terminales y rutas de auth se eliminen del GitHub Enterprise Server en la versión 3.4 de GitHub Enterprise Server.

Se eliminaron dos eventos de webhook relacionados con las GitHub Apps tradicionales: integration_installation y integration_installation_repositories. En su lugar, deberías estar escuchando a los eventos de installation y installation_repositories.

La siguiente terminal de la API de REST se eliminó: POST /installations/{installation_id}/access_tokens. En su lugar, deberías etar utilizando aquella con designador de nombre: POST /app/installations/{installation_id}/access_tokens.