Enterprise Server 3.8 release notes

MEDIUM: Scoped installation tokens for a GitHub App kept approved permissions after the permissions on the integration installation were downgraded or removed. GitHub has requested CVE ID CVE-2023-23765 for this vulnerability, which was reported via the GitHub Bug Bounty program.

Packages have been updated to the latest security versions.

On an instance in a cluster configuration, when upgrading the MySQL master node, the post-upgrade configuration run would take 600 seconds longer than required due to incorrect detection of unhealthy nodes.

On an instance with a GitHub Advanced Security license and secret scanning enabled, rotation of the key used to encrypt secrets discovered by secret scanning would fail.

In some situations on an instance with multiple nodes, Git replication failed to fully replicate repositories that had previously been deleted, which resulted in a warning in ghe-repl-status output.

If a user made a request to the Collaborators API's Add a repository collaborator endpoint specifying a permission of read or write, the instance returned a 500 error.

On an instance with the dependency graph enabled, the correct path appears for manifests that originate from build-time submission snapshots.

The spokesctl command-line utility accepts more input formats.

People with administrative SSH access to an instance can configure the maximum memory usage in gigabytes for Redis using ghe-config redis.max-memory-gb VALUE.

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

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

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

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

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

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

En una instancia con un gran número de organizaciones, los propietarios de empresas que navegaban a la página de configuración "Seguridad y análisis" de la empresa podían obtener un error 500.

A partir de GitHub Enterprise Server 3.8, al usar la CLI de GitHub Enterprise Importer, la API de GraphQL startRepositoryMigration o la API de REST "Iniciar una migración de organización" requieren que se configure un proveedor de almacenamiento de blobs en la consola de administración. Al usar Azure Blob Storage, los contenedores de almacenamiento se configuraban incorrectamente para que fueran accesibles públicamente. Ahora, los contenedores de Azure Blob Storage se configurarán para que sean privados, y hemos incluido una comprobación que impide explícitamente las exportaciones si el contenedor de almacenamiento es público.

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

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

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

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

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

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

En una instancia con una licencia de GitHub Advanced Security en la que está habilitado el examen de secretos, el registro excesivo en /var/log podía provocar errores orientados al usuario y un rendimiento degradado del sistema si los registros consumían todo el espacio libre en el volumen.

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

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

Después de que un administrador del sitio exporte un archivo de migración mediante la utilidad gh-migrator de GitHub Enterprise Importer, el vínculo al archivo permanece accesible durante 48 horas en lugar de una hora.

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

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

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

Cuando un administrador del sitio ejecutó ghe-btop mediante SSH, el comando no se ejecutó y se produjo el error /usr/bin/env: python3: No such file or directory.

Los administradores del sitio que se prepararon para habilitar Acciones de GitHub no pudieron ejecutar la utilidad ghe-actions-precheck porque el archivo de scripts no era ejecutable.

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

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

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

Después de que un administrador del sitio exportase un archivo de migración a AWS S3 mediante la utilidad gh-migrator del importador de GitHub Enterprise, la dirección URL del archivo era inaccesible.

Si un administrador del sitio exportó un archivo de migración a un cubo de la región us-east-1 de AWS S3s mediante la utilidad gh-migrator del importador de GitHub Enterprise, el archivo no era accesible.

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

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

Después de que un administrador del sitio exporte un archivo de migración mediante la utilidad gh-migrator del importador de GitHub Enterprise, el vínculo al archivo permanece accesible durante 48 horas en lugar de una hora.

En una instancia con una licencia de GitHub Advanced Security, los usuarios que crean patrones personalizados para el análisis de secretos pueden proporcionar expresiones que deben coincidir o no con un máximo de 2000 caracteres. Este límite es un aumento de 1000 caracteres.

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

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

En una instancia con Acciones de GitHub habilitada, un trabajo de flujo de trabajo para Acciones de GitHub no se iniciaría si un grupo de ejecutores coincidente no estuviera disponible cuando el trabajo se puso en cola inicialmente, incluso con un grupo de ejecutores coincidente disponible tras la entrada en la cola del trabajo.

En una instancia con Acciones de GitHub habilitada, Acciones de GitHub ahora se ejecutará correctamente después de la restauración de un repositorio eliminado.

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

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

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

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

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

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

Los comandos que los administradores del sitio ejecutaban a través de SSH en cualquiera de los nodos de instancias no se registraban en /var/log/ssh-console-audit.log.

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

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

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

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

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

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

Cuando los usuarios buscaban gists, el texto del campo de búsqueda no se podía visualizar en algunos casos porque el color del texto era idéntico al del fondo del campo.

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

En una instancia con GitHub Connect habilitado, si se habilitaba "Los usuarios pueden buscar en GitHub.com", los usuarios no veían problemas en repositorios privados e internos en los resultados de búsqueda de GitHub.com.

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

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

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

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

En una instancia con una licencia de GitHub Advanced Security, los usuarios que crean patrones personalizados para el análisis de secretos pueden proporcionar expresiones que deben coincidir o no con un máximo de 2000 caracteres. Este límite es un aumento de 1000 caracteres.

Projects, la herramienta flexible para planear y realizar el seguimiento del trabajo en GitHub Enterprise Server, ya está disponible en su versión beta. Un proyecto es una hoja de cálculo adaptable que integra las incidencias y las solicitudes de incorporación de cambios para ayudar a los usuarios a planear y realizar el seguimiento del trabajo de forma eficaz. Los usuarios pueden crear y personalizar varias vistas, y cada vista puede filtrar, ordenar y agrupar incidencias y solicitudes de incorporación de cambios. Los usuarios también pueden definir campos personalizados para realizar un seguimiento de los metadatos únicos de un equipo o proyecto, lo que permite personalizar las necesidades o procesos. Esta característica está sujeta a cambios. Para obtener más información, vea «Acerca de Projects (beta)».

Los administradores del sitio pueden mejorar la seguridad de una instancia mediante la creación de cuentas de usuario dedicadas para la Consola de administración. Solo el administrador del sitio raíz puede crear cuentas de usuario. Para controlar el acceso a las cuentas de usuario, asigna el rol de editor o operador. Los operadores pueden administrar el acceso SSH administrativo para la instancia. Para obtener más información, consulta Administración del acceso a la Consola de administración.

Para establecer o cumplir las directivas internas, los administradores del sitio pueden usar la Consola de administración para configurar la directiva de una instancia para la retención de datos relacionados con las comprobaciones, incluidos los datos de comprobación generados por Acciones de GitHub y la API de estados. Los administradores pueden habilitar o deshabilitar la retención, establecer un umbral de retención personalizado o establecer un umbral de eliminación permanente personalizado. Para obtener más información, consulta "Configuración de aplicaciones" [Actualizado: 02/03/2023].

Al generar paquetes de soporte técnico mediante la utilidad de línea de comandos ghe-support-bundle, los administradores del sitio pueden especificar la duración exacta que se usará para la recopilación de datos del paquetes. Para más información, vea "Utilidades de línea de comandos".

Los usuarios pueden revisar y revocar sesiones del explorador y de GitHub Mobile para una instancia de GitHub Enterprise Server. Para obtener más información, consulta "Visualización y administración de las sesiones."

Los propietarios de la empresa pueden configurar si los administradores del repositorio pueden habilitar o deshabilitar las alertas de Dependabot. En las instancias con una licencia de GitHub Advanced Security, los propietarios de la empresa también pueden establecer directivas para controlar si los administradores del repositorio pueden habilitar las características o el examen de secretos de GitHub Advanced Security. Para obtener más información, consulta "Aplicación de directivas de seguridad y análisis de código de la empresa".

Los propietarios de la empresa y de la organización pueden contribuir a la adhesión al principio de privilegios mínimos si conceden acceso a los puntos de conexión del registro de auditoría sin proporcionar privilegios administrativos completos. Para proporcionar este acceso, los tokens de acceso personal y las aplicaciones de OAuth ahora admiten el ámbito read:audit_log. Para más información, vea "Uso de la API de registro de auditoría para la empresa".

Al visualizar datos de tokens en eventos del registro de auditoría, los propietarios de la empresa pueden detectar y realizar un seguimiento más fácilmente de la actividad asociada a los tokens de autenticación. Para obtener más información, consulta "Identificación de eventos de registro de auditoría realizados por un token de acceso".

Los propietarios de la empresa pueden configurar el streaming del registro de auditoría en un punto de conexión de Datadog. Para más información, vea "Streaming del registro de auditoría para su empresa".

Los propietarios de la empresa de una instancia con una licencia de GitHub Advanced Security pueden ver los cambios en GitHub Advanced Security, el examen de secretos y la habilitación de la protección de inserción en el registro de auditoría. Los propietarios de la organización pueden ver los cambios en los mensajes personalizados para la protección de inserción en el registro de auditoría. Para más información, consulte la siguiente documentación.

• "Acciones de la categoría business_secret_scanning", "Acciones de la categoría business_secret_scanning_push_protection" y "Acciones de la categoría business_secret_scanning_push_protection_custom_message" en "Eventos del registro de auditoría para la empresa"
• "Revisión del registro de auditoría de la organización"

Los propietarios de la empresa de una instancia con una licencia de GitHub Advanced Security pueden garantizar el cumplimiento y simplificar el lanzamiento del examen de secretos y la protección de inserción en todas las organizaciones de la instancia mediante la API REST. Este punto de conexión complementa la interfaz de usuario web existente, así como los puntos de conexión para repositorios y organizaciones. Para obtener más información, consulta "Seguridad y análisis del código" en la documentación de la API REST.

Los propietarios de la empresa y de la organización que usan el examen de secretos de una instancia con una licencia de GitHub Advanced Security pueden usar la API REST para especificar un vínculo personalizado que se mostrará cuando la protección de inserción bloquee una inserción que contiene un secreto. Para obtener más información, consulta "Seguridad y análisis del código" u "Organizaciones" en la documentación de la API REST.

Los usuarios de una instancia con una licencia de GitHub Advanced Security que descartan una alerta de examen de secretos pueden ayudar a otros usuarios a comprender el motivo del descarte si proporcionan un comentario opcional mediante la interfaz de usuario web o la API REST. Para más información, consulte la siguiente documentación.

• "Administración de alertas del examen de secretos"
• "Examen de secretos" en la documentación de la API REST

Los usuarios de una instancia con una licencia de GitHub Advanced Security pueden filtrar los resultados de la API de examen de código en función de la gravedad de la alerta en los niveles de repositorio o de organización. Usa el parámetro severity para devolver solo alertas de examen de código con una gravedad específica. Para más información, consulta "Examen del código" en la documentación de la API REST.

Los usuarios de una instancia con una licencia de GitHub Advanced Security pueden analizar dos lenguajes adicionales para detectar vulnerabilidades y errores mediante el examen de código de CodeQL. La compatibilidad con Ruby está disponible con carácter general, mientras que la compatibilidad con Kotlin se encuentra en versión beta y está sujeta a cambios.

• El análisis de Ruby puede detectar más del doble de debilidades comunes (CWE) de las que podía detectar durante la versión beta. Un total de 30 reglas pueden identificar diversas vulnerabilidades, como scripting entre sitios (XSS), denegación de servicio de expresiones regulares (ReDoS) e inyección de código SQL, entre otros. La cobertura adicional de la biblioteca y el marco para Ruby-on-Rails garantiza que los desarrolladores de servicios web obtengan resultados aún más precisos. GitHub Enterprise Server admite todas las versiones comunes de Ruby, incluido hasta la versión 3.1.
• La compatibilidad con Kotlin es una extensión de la compatibilidad con Java existente y se beneficia de las consultas CodeQL existentes para Java, que se aplican a aplicaciones móviles y del lado servidor. GitHub también ha mejorado y agregado diversas consultas específicas de dispositivos móviles, que incluyen aspectos como el control de intenciones, problemas de validación de vistas web, inserción de fragmentos, etc.

Para obtener más información sobre el examen de código, consulta "Acerca del examen de código con CodeQL".

Los usuarios de una instancia con una licencia de GitHub Advanced Security que usan el examen de código CodeQL pueden personalizar la configuración de compilación para el análisis de Go en el archivo de flujo de trabajo de Acciones de GitHub. Los flujos de trabajo de CodeQL existentes para el análisis de Go no requieren cambios y seguirán siendo compatibles. Para obtener más información, consulta "Configuración del flujo de trabajo de CodeQL para lenguajes compilados".

Para mejorar la seguridad del código y simplificar el proceso de actualizar las dependencias vulnerables, más usuarios pueden recibir solicitudes de incorporación de cambios automáticas con actualizaciones de dependencias.

• Los creadores de Acciones de GitHub pueden actualizar automáticamente las dependencias dentro de archivos de flujo de trabajo.
• Los desarrolladores de Dart o Flutter que usan Pub pueden actualizar automáticamente las dependencias dentro de sus proyectos.

Para obtener más información, vea "Acerca de las actualizaciones de seguridad de Dependabot".

Los desarrolladores de Dart y JavaScript de una instancia con el gráfico de dependencias habilitado pueden recibir alertas de Dependabot para detectar vulnerabilidades conocidas dentro de las dependencias de un proyecto.

• En el caso de Dart, el gráfico de dependencias detecta archivos pubspec.lock y pubspec.yaml.
• Los desarrolladores de JavaScript que usan Node.js y npm pueden recibir alertas de vulnerabilidades conocidas en manifiestos de Yarn v2 y v3. Esto complementa la compatibilidad existente con los manifiestos v1. El gráfico de dependencias detecta archivos package.json y yarn.lock.

Para obtener más información, consulte los siguientes artículos.

• "Acerca del gráfico de dependencias"
• "Exploración de los avisos de seguridad en GitHub Advisory Database"
• "Acerca de las alertas Dependabot"

Los desarrolladores de Python que usan administradores de paquetes compatibles en una instancia con el gráfico de dependencias habilitado pueden recibir alertas de Dependabot para las dependencias dentro de archivos pyproject.toml que siguen el estándar PEP 621. Para obtener más información, vea "Acerca de las actualizaciones de versiones de Dependabot".

Los desarrolladores de Python que reciben alertas de Dependabot pueden reducir el número de actualizaciones de versión cuando una nueva versión ya cumple un requisito de dependencia actual. Para configurar este comportamiento, usa la estrategia de control de versiones increase-if-necessary. Para más información, vea "Opciones de configuración para el archivo dependabot.yml".

Los propietarios de la empresa pueden recuperar alertas de Dependabot para la instancia mediante la API REST. Este punto de conexión se encuentra en versión beta y está sujeto a cambios. Para obtener más información, consulta "Alertas de Dependabot" en la documentación de la API REST.

Los propietarios de la organización pueden recuperar alertas de Dependabot para la organización mediante la API REST. Este punto de conexión se encuentra en versión beta y está sujeto a cambios. Para obtener más información, consulta "Alertas de Dependabot".

Los usuarios pueden ver las alertas de Dependabot y actuar sobre ellas mediante programación con la API REST. En la versión beta hay disponibles nuevos puntos de conexión para ver, enumerar y actualizar alertas de Dependabot. Estos puntos de conexión están sujetos a cambios. Para obtener más información, consulta "Alertas de Dependabot" en la documentación de la API REST.

Para aumentar la visibilidad de la posición de seguridad y mejorar el análisis de riesgos, los usuarios pueden acceder a vistas de cobertura y riesgo en la información general de seguridad. La vista de cobertura muestra la habilitación entre repositorios, mientras que la vista de riesgo muestra las alertas entre repositorios. Los propietarios de la organización, los administradores de seguridad y los administradores de repositorios de una instancia con una licencia de GitHub Advanced Security pueden habilitar las características de seguridad desde la vista de cobertura de la información general de seguridad. Las vistas reemplazan la página "Información general". Se encuentran en la versión beta pública y están sujetas a cambios. Para obtener más información, consulte Acerca de la información general sobre seguridad.

Los colaboradores pueden definir la directiva de seguridad de un repositorio mediante la creación de un archivo SECURITY.md. Para aumentar la visibilidad de la directiva, GitHub Enterprise Server se vinculará a la directiva desde la pestaña Código del repositorio. Para obtener más información, consulta "Adición de una directiva de seguridad al repositorio".

La API de revisión de dependencias está disponible con carácter general y la acción de GitHub asociada ahora permite a los usuarios hacer referencia a un archivo de configuración local o externo. Para más información, consulte la siguiente documentación.

• "Revisión de dependencias" en la documentación de la API REST
• "Configuración de la revisión de dependencias"

GraphQL API proporciona acceso al gráfico de dependencias de un repositorio. Esta característica se encuentra en versión preliminar y está sujeta a cambios. Para más información, consulta "Objetos" en la documentación de GraphQL API.

Durante la configuración del almacenamiento de Acciones de GitHub, los administradores del sitio pueden evitar los riesgos asociados a la entrada de secretos confidenciales y claves de acceso mediante el uso de OIDC para conectarse a proveedores de almacenamiento de objetos. Acciones de GitHub en GitHub Enterprise Server admite OIDC para conexiones a AWS, Azure y Google Cloud Platform. Esta función está en versión beta y sujeta a cambios. Para obtener más información, consulta "Habilitación de Acciones de GitHub para GitHub Enterprise Server".

Para evitar un registro de datos que no es de confianza con los comandos de flujo de trabajo set-state y set-output, los autores de acciones pueden usar archivos de entorno para la administración del estado y la salida.

• Para usar esta característica, la aplicación del ejecutor debe ser la versión 2.297.0 o posterior. Las versiones 2.298.2 y posteriores advertirán a los usuarios que usan los comandos save-state o set-output. Estos comandos se deshabilitarán completamente en una versión futura.
• Para usar las funciones saveState y setOutput actualizadas, los flujos de trabajo que usan el kit de herramientas de Acciones de GitHub deben llamar a @actions/core v1.10.0 o posterior.

Para más información, consulta "Comandos de flujo de trabajo para Acciones de GitHub".

La capacidad de compartir acciones y flujos de trabajo reutilizables desde repositorios privados está disponible con carácter general. Los usuarios pueden compartir flujos de trabajo en un repositorio privado con otros repositorios privados que pertenecen a la misma organización o cuenta de usuario, o con todos los repositorios privados de la instancia. Para más información, consulte la siguiente documentación.

• "Administración de la configuración de Acciones de GitHub para un repositorio"
• "Permisos de Acciones de GitHub" en la documentación de la API REST

Para mejorar la legibilidad del flujo de trabajo y evitar la necesidad de almacenar los datos de configuración no confidenciales como secretos cifrados, los usuarios pueden definir variables de configuración, que permiten la reutilización en los flujos de trabajo de un repositorio o de la organización. Esta función está en versión beta y sujeta a cambios. Para obtener más información, consulta "Variables".

Los usuarios pueden asignar nombres dinámicos a las ejecuciones de flujo de trabajo. run-name acepta expresiones y el nombre dinámico aparece en la lista de ejecuciones de flujo de trabajo. Para más información, vea "Sintaxis de flujo de trabajo para Acciones de GitHub".

Para impedir que un trabajo se ejecute en un ejecutor fuera del grupo previsto, los usuarios pueden definir los nombres de los grupos de ejecutores previstos para un flujo de trabajo dentro de la clave runs-on.

runs-on:
  group: my-group
  labels: [ self-hosted, label-1 ]

Además, GitHub Enterprise Server ya no permitirá la creación de grupos de ejecutores con nombres idénticos en el nivel de organización y empresa. Aparecerá un banner de advertencia para los grupos de ejecutores de una organización que compartan nombre con un grupo de ejecutores de la empresa.

Los usuarios pueden aplicar prácticas estándar de CI/CD en todos los repositorios de una organización mediante la definición de flujos de trabajo necesarios. Estos flujos de trabajo se desencadenan como comprobaciones de estado necesarias para todas las solicitudes de incorporación de cambios que tienen como destino la rama predeterminada de los repositorios, lo que bloquea la combinación hasta que se supere la comprobación. Esta función está en versión beta y sujeta a cambios. Para más información, consulta "Flujos de trabajos obligatorios".

Para habilitar la estandarización de las configuraciones de OIDC en flujos de trabajo de implementación en la nube, los propietarios de la organización y los administradores de repositorios pueden configurar el formato de notificación subject dentro de los tokens de OIDC mediante la definición de una plantilla personalizada. Para más información, vea "Acerca del fortalecimiento de la seguridad con OpenID Connect".

Para una mayor transparencia y control sobre el uso de la memoria caché dentro de los repositorios, los usuarios que almacenan en caché las dependencias y otros archivos reutilizados con actions/cache pueden administrar las memorias caché desde la interfaz de usuario web de la instancia. Para más información, vea "Almacenamiento en caché de dependencias para acelerar los flujos de trabajo".

Para establecer expectativas en lo que respecta a la disponibilidad, los usuarios pueden mostrar una zona horaria local en sus perfiles. Las personas que consulten el perfil o la tarjeta flotante del usuario verán la zona horaria, así como el número de horas que está por delante o por detrás con relación a la hora local del usuario. Para obtener más información, consulte "Personalización del perfil".

Para mejorar la detectabilidad, los debates de GitHub presentan las mejoras siguientes.

• Los propietarios del repositorio pueden anclar los debates en una categoría específica.
• En la página de la categoría se muestran títulos y descripciones de las categorías.

Para administrar la forma en que los miembros de la organización bifurcan los repositorios, los propietarios de la organización pueden establecer una directiva de bifurcación dedicada para cualquier organización. Esta directiva debe ser más estricta que una directiva de bifurcación establecida para la empresa. Para más información, vea "Administración de la directiva de bifurcación para la organización".

Para mejorar la seguridad de la organización, los propietarios de la organización pueden impedir que los colaboradores externos soliciten la instalación de aplicaciones de GitHub y OAuth. Para obtener más información, consulta "Limitación de solicitudes de acceso a aplicaciones de OAuth y aplicaciones de GitHub".

Para evitar proporcionar acceso administrativo completo a un repositorio cuando no es necesario, los administradores del repositorio pueden crear un rol personalizado que permita a los usuarios omitir las protecciones de rama. Para aplicar protecciones de rama para todos los usuarios con acceso administrativo o permisos de omisión, los administradores pueden habilitar No permitir la omisión de la configuración anterior. Para obtener más información, consulta "Administración de roles de repositorio personalizados para una organización" y "Acerca de las ramas protegidas".

Para garantizar la seguridad y la estabilidad de las ramas, los administradores de repositorios pueden requerir la aprobación de la solicitud de incorporación de cambios por parte de alguien que no sea el último insertador, o bien bloquear la rama. Para más información, vea "Acerca de las ramas protegidas".

En los escenarios en los que alguien debe revisar el código dentro de un flujo de trabajo de Acciones de GitHub antes de que se ejecute el flujo de trabajo, los administradores del repositorio pueden requerir la aprobación de un usuario con acceso de escritura al repositorio antes de que se pueda desencadenar una ejecución de flujo de trabajo desde una bifurcación privada. Para obtener más información, consulta "Administración de la configuración de Acciones de GitHub para un repositorio".

GraphQL API admite la creación y la eliminación del vínculo entre una rama y una incidencia. Para más información, consulte la siguiente documentación.

• "Creación de una rama para trabajar en una incidencia"
• "createLinkedBranch" y "deleteLinkedBranch" en la documentación de GraphQL API sobre "Mutaciones"
• "Objetos" en la documentación de GraphQL API

Los usuarios con varias direcciones de correo electrónico asociadas a sus cuentas pueden garantizar mejor que las confirmaciones de Git creadas por la fusión mediante combinación con "squash" estén asociadas a la dirección de correo electrónico correcta. Al combinar la solicitud de incorporación de cambios, aparecerá un menú desplegable que permite al usuario seleccionar la dirección de correo electrónico que se usará como autor de la confirmación.

Los usuarios pueden marcar una versión específica dentro de un repositorio como versión más reciente mediante la interfaz de usuario web, la API REST o GraphQL API. Para más información, consulte la siguiente documentación.

• "Administración de versiones en un repositorio"
• "Versiones" en la documentación de la API REST
• "Objetos" en la documentación de GraphQL API

Para ahorrar tiempo y cambiar el contexto con menos frecuencia, los usuarios pueden recibir y reaccionar a actualizaciones en tiempo real sobre la actividad de GitHub Enterprise Server directamente en Slack o Microsoft Teams. Las integraciones de GitHub para estos servicios están ahora disponibles con carácter general. Para obtener más información, consulta "Extensiones e integraciones de GitHub".

Cuando un administrador de sitio ejecuta un comando mediante el acceso SSH administrativo, el comando ahora se registra. Para ayudar al soporte técnico de GitHub a solucionar problemas y depurar, los paquetes de soporte técnico incluyen un registro que contiene estos comandos.

Para simplificar la detección de eventos en los registros de auditoría de empresa, organización o usuario, la barra de búsqueda muestra ahora una lista de filtros disponibles.

Para que un administrador de sitio pueda realizar la migración desde GitHub Enterprise Server mediante la CLI del importador de GitHub Enterprise, la GraphQL API startRepositoryMigration o la API REST Iniciar una migración de la organización, el administrador debe usar la Consola de administración para configurar un proveedor de almacenamiento de blobs para el almacenamiento de los archivos de migración. Entre las opciones admitidas se incluyen Amazon S3 y Azure Blob Storage. Anteriormente, el almacenamiento de blobs no era necesario y, de manera opcional, se podía configurar mediante gh gei. Este cambio agrega compatibilidad con las migraciones en las que el origen o los metadatos de Git tienen un tamaño superior a 1 GB.

Para ayudar a los usuarios de una instancia con una licencia de GitHub Advanced Security a comprender mejor los secretos detectados y tomar medidas, las alertas de examen de secretos relativas a claves de API de terceros ahora incluyen un vínculo a la documentación del proveedor. Para obtener más información, consulta "Acerca del análisis de secretos".

Los usuarios de una instancia con una licencia de GitHub Advanced Security ahora verán las acciones que los usuarios realizaron en una alerta de examen de secretos directamente dentro de la escala de tiempo de la alerta, incluido cuando un colaborador omite la protección de inserción para un secreto.

Las instancias con una licencia de GitHub Advanced Security ejecutarán periódicamente un examen histórico para detectar tipos de secretos recién agregados en repositorios en los que se ha habilitado GitHub Advanced Security y el examen de secretos. Antes, los usuarios debían ejecutar manualmente un examen histórico.

En las instancias con una licencia de GitHub Advanced Security, para asegurarse de que las versiones futuras de GitHub Enterprise Server siempre puedan mostrar una versión preliminar de un secreto detectado en las API o la interfaz de usuario web, los secretos detectados se almacenan ahora por separado del código fuente. Los secretos detectados se almacenan mediante el cifrado simétrico. [Actualizado: 15/02/2023]

Al usar registros privados para las actualizaciones de Dependabot, GitHub Enterprise Server se comporta de forma más segura. Si se configura un registro privado para cualquiera de los siguientes ecosistemas, la instancia ya no realizará ninguna solicitud de paquete a los registros públicos.

• Bundler
• Docker
• Gradle
• Maven
• npm
• Nuget
• Python
• Yarn

Para más información, vea "Opciones de configuración para el archivo dependabot.yml".

Los desarrolladores de Elixir que usan repositorios de Hex autohospedados pueden configurar un registro privado para las actualizaciones de versión de Dependabot en GitHub Enterprise Server. Para más información, vea "Opciones de configuración para el archivo dependabot.yml".

Las alertas de Dependabot presentan las siguientes mejoras en la facilidad de uso.

• La página de una alerta se actualiza automáticamente después de que Dependabot intente crear una solicitud de incorporación de cambios para una actualización.
• Las alertas se asignan con mayor precisión a las solicitudes de incorporación de cambios de las actualizaciones de Dependabot.
• Con el fin de mejorar la alerta para la comunidad, los usuarios pueden sugerir mejoras en las alertas directamente en GitHub Advisory Database.

Los usuarios pueden hacer mención a @dependabot más fácilmente. Al hacer mención a usuarios, la cuenta de usuario de Dependabot aparece ahora como una sugerencia de autocompletar.

En los repositorios con dependencias vulnerables, Dependabot ya no mostrará un banner amarillo. Para notificar a colaboradores de dependencias vulnerables, la pestaña Seguridad muestra un contador de alertas.

Si un usuario bifurca un repositorio con una configuración de Dependabot existente en dependabot.yml, las actualizaciones de Dependabot se deshabilitarán de forma predeterminada en la bifurcación. Para habilitar las actualizaciones en la bifurcación, el usuario debe visitar la configuración de análisis y seguridad del código del repositorio. Para obtener más información, consulta "Configuración de las actualizaciones de versiones de Dependabot".

Los integradores que quieran recibir un webhook para las alertas de Dependabot deben usar el nuevo webhook dependabot_alert. Este webhook reemplaza al webhook repository_vulnerability_alert. Para más información, vea "Eventos y cargas de webhook".

Para mejorar la legibilidad de los flujos de trabajo de Acciones de GitHub que hacen referencia a otras acciones mediante un SHA de confirmación, los autores de las acciones suelen escribir un comentario que incluye la versión semántica correspondiente en la línea que llama a la acción. Para ahorrar tiempo, las solicitudes de incorporación de cambios para las actualizaciones de la versión de Dependabot ahora actualizarán automáticamente la versión semántica en estos comentarios.

Los desarrolladores de JavaScript que usan actualizaciones de seguridad de Node.js, npm y Dependabot pueden ahorrar tiempo al actualizar proyectos de npm con dependencias transitivas.

• Dependabot puede actualizar juntas las dependencias primarias y secundarias. Antes, Dependabot no actualizaba las dependencias transitivas cuando el elemento primario necesitaba un intervalo de versiones específico incompatible, lo que requería actualizaciones manuales.
• Dependabot puede crear solicitudes de incorporación de cambios que resuelven alertas en las que una actualización de una dependencia directa quitaría la dependencia transitiva vulnerable del árbol.

Para obtener más información, vea "Acerca de las actualizaciones de seguridad de Dependabot".

Para las personas que usan Dependabot para las actualizaciones de versión en el ecosistema de Docker, Dependabot actualizará proactivamente las etiquetas de imagen de Docker en manifiestos de Kubernetes. Para obtener más información, consulta "Configuración de actualizaciones de versión de Dependabot" y "Opciones de configuración para el archivo dependabot.yml".

Hay varias mejoras disponibles para los usuarios que contribuyen a los avisos de seguridad en GitHub.com, incluidos los cambios siguientes.

• Para garantizar una revisión más rápida, GitHub pide a los usuarios que indiquen un motivo para el cambio.
• Para asegurarse de que la contribución coincide con la intención del usuario, GitHub no reordenará los vínculos de referencia en las diferencias.

Las Acciones de GitHub incluyen las siguientes mejoras de detectabilidad y accesibilidad.

• Se ha mejorado la experiencia de navegación para buscar flujos de trabajo y ejecuciones de flujo de trabajo.
• La estructura agregada representa mejor la jerarquía entre el autor de la llamada y los flujos de trabajo reutilizables a los que se ha llamado.
• La experiencia de exploración móvil es más coherente y admite varios tamaños de ventanilla.

Los flujos de trabajo de Acciones de GitHub ya no se desencadenarán sin cesar al usar GITHUB_TOKEN con eventos workflow_dispatch y repository_dispatch. Antes de este cambio, los eventos que desencadenaba GITHUB_TOKEN no creaban una nueva ejecución de flujo de trabajo. Para obtener más información, consulta "Desencadenamiento de un flujo de trabajo".

Para las ejecuciones programadas de flujos de trabajo de Acciones de GitHub, los usuarios verán información adicional sobre el repositorio, la organización y la empresa dentro de la carga de github.event.

Los usuarios de Acciones de GitHub tienen una visión más detallada del progreso de un trabajo al usar reglas de protección del entorno. El webhook workflow_job admite un nuevo estado waiting cada vez que un trabajo está esperando una regla de protección del entorno. Además, cuando un trabajo hace referencia a una clave environment en su definición de YAML, la carga del webhook workflow_job también incluirá una nueva propiedad: deployment. La propiedad deployment contiene metadatos sobre la implementación que creó la ejecución de comprobación. Para más información, vea "Uso de entornos para la implementación".

Los propietarios de la organización pueden encontrar un contexto más significativo en los eventos del registro de auditoría.

• Los eventos business.sso_response y org.sso_response aparecen en la API REST y las cargas para el streaming de registros de auditoría.
• Los eventos repo.rename, project.rename y protected_branch.update_name incluyen sus nombres actuales y pasados cambiados en el campo old_name.
• Los eventos de las alertas de Dependabot contienen campos alert_number, ghsa_id, dismiss_reason y dismiss_comment, además de un vínculo a la alerta y una marca de tiempo precisa.

Los usuarios pueden ver una lista con todos los seguidores de una organización en el perfil de la organización.

El banner que se muestra encima de un repositorio archivado en la interfaz de usuario web ahora incluye la fecha de archivado del repositorio.

Las pestañas Conversaciones y Archivos de las solicitudes de incorporación de cambios ahora se cargan más rápidamente debido al resaltado de sintaxis diferido.

Para proporcionar una experiencia más coherente entre la interfaz de usuario web y las estaciones de trabajo de los usuarios, y para acelerar el proceso de comprobar si los usuarios pueden combinar automáticamente una solicitud de incorporación de cambios, GitHub Enterprise Server ahora usa la estrategia merge-ort. Para obtener más información, consulta Estrategias de combinación en la documentación de Git.

Para mejorar la visualización del comentario inicial en las solicitudes de incorporación de cambios que contienen una confirmación, GitHub Enterprise Server ahora vuelve a formatear automáticamente los mensajes de confirmación detallados para cumplir las convenciones de Markdown de GitHub.

Cuando se una solicitud de incorporación de cambios se fusiona mediante combinación con "squash", el autor de la confirmación de Git se muestra antes de la fusión. Antes, el autor de la confirmación solo se mostraba al combinar con una confirmación de combinación.

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

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

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

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

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

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

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

En algunos casos, al convertir una incidencia en una discusión, el proceso de conversión puede bloquearse. En esta situación, un propietario de la empresa puede probar los siguientes pasos de solución de problemas para resolver la incidencia.

1. Al final de la dirección URL de la discusión bloqueada, observa el número de la discusión.
2. En la interfaz de usuario web, ve al repositorio donde está bloqueada la conversión.
3. En la esquina superior derecha de la interfaz de usuario web, haz clic en .
4. En "Colaboración", haz clic en NUMBER discusiones.
5. En la lista, haz clic en el número del paso 1.
6. En "Conversión", haz clic en Poner en cola trabajo de conversión.
7. Espera unos minutos y comprueba el estado de la incidencia.

Si la conversión todavía no se ha completado, ponte en contacto con el soporte técnico de GitHub Enterprise para obtener ayuda.

Si el administrador del sitio raíz tiene bloqueado el acceso a la consola de administración después de intentos de inicio de sesión erróneos, la cuenta no se desbloqueará automáticamente después del tiempo de bloqueo definido. Alguien con acceso SSH administrativo a la instancia debe desbloquear la cuenta mediante el shell administrativo. Para obtener más información, vea «Solución de problemas de acceso a la Consola de administración». [Actualizado: 23/02/2023]

Durante una actualización a GitHub Enterprise Server 3.8.0 en un clúster, después de actualizar los nodos distintos del nodo MySQL principal y antes de actualizar el nodo MySQL principal, el siguiente error puede aparecer varias veces después de ejecutar ghe-cluster-config-apply.

Error response from daemon: conflict: unable to delete IMAGE_ID (cannot be forced) - image is being used by running container CONTAINER_ID

GitHub recomienda esperar a actualizar el clúster hasta que se resuelva este problema. Encontrarás más información en las notas de la versión de una actualización futura de GitHub Enterprise Server.

Después de actualizar a GitHub Enterprise Server 3.8.0, los comandos que se ejecutan a través de SSH en cualquiera de los nodos de la instancia no se registrarán en /var/log/ssh-console-audit.log. Para resolver este problema, conéctate mediante SSH al nodo afectado y ejecuta el comando siguiente.

source /etc/bash.bashrc

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

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

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

El uso de la API de búsqueda puede provocar un error en las solicitudes posteriores a otras interfaces. Cuando se produzca este problema, los usuarios de la API o la interfaz de usuario web afectados recibirán respuestas HTTP 5xx y se registrará esta excepción NoMethodError:

NoMethodError (undefined method `starts_with?' for [:ok, "refs/heads/main"]:Array):