Enterprise Server 3.6 release notes

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

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

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

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

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

Si una instancia tenía decenas de miles de repositorios eliminados, una actualización a GitHub Enterprise Server 3.7 podría tardar más de lo esperado.

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.

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

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

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

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

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

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

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

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.

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.

Se han eliminado métricas launch.* que no se pueden analizar por statsd, ya que los errores resultantes de statsd hacían que los registros recopilados crecieran rápidamente de tamaño.

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.

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.

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 algunos casos, los gráficos del panel de supervisión de la Consola de administración no se representaban.

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.

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

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

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

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

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

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

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

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 algunos casos, en una instancia con una licencia de GitHub Advanced Security y un análisis de secretos habilitados, es posible que los usuarios hayan visto una discrepancia entre el número de alertas mostradas en una pestaña "Seguridad" del repositorio y en la barra lateral de la pestaña "Seguridad".

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.

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

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

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

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

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

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

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

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

Una vez que el propietario de una empresa habilita actualizaciones de Dependabot, la instancia crea el conjunto inicial de actualizaciones con mayor rapidez.

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

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

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

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

Las versiones de la serie 3.6 del servidor de GitHub Enterprise ya no son adecuadas para probar SCIM. Para seguir usando la versión beta privada de SCIM, actualice la instancia a la versión 3.7.3 o posterior. Para más información, consulta "Actualización de GitHub Enterprise Server". [Actualizado: 17/04/2023]

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

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

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

La página de configuración de las discusiones de una organización devolvió un error 500 después de eliminar un repositorio propiedad de la organización.

Las versiones de la serie 3.6 del servidor de GitHub Enterprise ya no son adecuadas para probar SCIM. Para seguir usando la versión beta privada de SCIM, actualice la instancia a la versión 3.7.3 o posterior. Para más información, consulta "Actualización de GitHub Enterprise Server". [Actualizado: 17/04/2023]

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

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

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

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

Las versiones de la serie 3.6 del servidor de GitHub Enterprise ya no son adecuadas para probar SCIM. Para seguir usando la versión beta privada de SCIM, actualice la instancia a la versión 3.7.3 o posterior. Para más información, consulta "Actualización de GitHub Enterprise Server". [Actualizado: 17/04/2023]

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

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

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

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

Al habilitar la administración automática de certificados TLS con Let's Encrypt, el proceso podría generar el error The certificate is not signed by a trusted certificate authority (CA) or the certificate chain in missing intermediate CA signing certificates.

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

Cuando se produce un tiempo de espera durante la generación de diferencias, como cuando una confirmación muestra un error que indica que la diferencia está tardando demasiado tiempo en generarse, el evento de webhook push entregará información vacía sobre las diferencias. Anteriormente, no se podía entregar el evento de webhook push.

Las versiones de la serie 3.6 del servidor de GitHub Enterprise ya no son adecuadas para probar SCIM. Para seguir usando la versión beta privada de SCIM, actualice la instancia a la versión 3.7.3 o posterior. Para más información, consulta "Actualización de GitHub Enterprise Server". [Actualizado: 17/04/2023]

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

Las versiones de la serie 3.6 del servidor de GitHub Enterprise ya no son adecuadas para probar SCIM. Para seguir usando la versión beta privada de SCIM, actualice la instancia a la versión 3.7.3 o posterior. Para más información, consulta "Actualización de GitHub Enterprise Server". [Actualizado: 17/04/2023]

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

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

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

Las métricas Active workers y Queued requests para github (cuyo nombre metadatos se ha cambiado), gitauth y los servicios de contenedor unicorn no se han leído correctamente de la recopilación y se han mostrado en la Consola de administración.

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

Las migraciones de datos podrían producir un error cuando la tabla de base de datos subyacente contenía solo un único registro.

Al ver la diferencia de una solicitud de incorporación de cambios para un archivo grande con muchas líneas entre cambios, no era posible expandir la vista para mostrar todos los cambios.

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

La variable de entorno GITHUB_REF_PROTECTED y los contextos github.ref_protected se establecieron incorrectamente como false cuando existían protecciones de rama.

Se han eliminado métricas launch.* que no se pueden analizar por statsd, ya que los errores resultantes de statsd hacían que los registros recopilados crecieran rápidamente de tamaño.

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

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

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

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

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

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

Las versiones de la serie 3.6 del servidor de GitHub Enterprise ya no son adecuadas para probar SCIM. Para seguir usando la versión beta privada de SCIM, actualice la instancia a la versión 3.7.3 o posterior. Para más información, consulta "Actualización de GitHub Enterprise Server". [Actualizado: 17/04/2023]

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

ALTA: Una vulnerabilidad de autorización incorrecta ha permitido que un token con ámbito de usuario a servidor se escalase al acceso total de administrador para un repositorio. Un atacante necesitaría una cuenta con acceso de administrador para instalar una aplicación de GitHub malintencionada. Esta vulnerabilidad ha afectado a todas las versiones de GitHub Enterprise Server anteriores a la 3.7.0. Esta vulnerabilidad se ha notificado mediante el programa de GitHub Bug Bounty y se le ha asignado el código CVE-2022-23741.

MEDIUM: se ha identificado una vulnerabilidad de divulgación de información en GitHub Enterprise Server que permitía la adición de repositorios privados a un grupo de ejecutores de Acciones de GitHub a través de la API por parte de un usuario que no tenía acceso a esos repositorios, lo que provocaba que los nombres de los repositorios se mostraran en la interfaz de usuario. Para aprovechar esta vulnerabilidad, un atacante necesitaría acceso a la instancia de GHES, los permisos para modificar los grupos de ejecutores de Acciones de GitHub y adivinar correctamente el identificador ofuscado de los repositorios privados. Esta vulnerabilidad se ha notificado mediante el programa Bug Bounty de GitHub y se le ha asignado el código CVE-2022-46257.

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

Los administradores del sitio no han podido administrar la configuración de productos de seguridad de los repositorios que habían desbloqueado.

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

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

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

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

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

Si un usuario ha cargado más de un archivo al crear un Gist, el usuario no podrá eliminar los archivos cargados después del primero.

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

En algunos casos, al examinar repositorios en la interfaz web, un banner erróneo ha indicado que un repositorio no contenía una ruta de acceso específica sin definir en la rama actual.

El evento de webhook member no ha incluido los valores de campo from y to para el campo permission como parte del campo changes.

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

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

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

Ha aparecido un mensaje de nivel de depuración en un registro del sistema, lo que podría consumir espacio rápidamente en el volumen de almacenamiento raíz de la instancia.

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

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

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

Las versiones de la serie 3.6 del servidor de GitHub Enterprise ya no son adecuadas para probar SCIM. Para seguir usando la versión beta privada de SCIM, actualice la instancia a la versión 3.7.3 o posterior. Para más información, consulta "Actualización de GitHub Enterprise Server". [Actualizado: 17/04/2023]

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

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

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

MEDIA: se identificó una vulnerabilidad de autorización incorrecta en GitHub Enterprise Server que permitía que un token con ámbito de repositorio con acceso de lectura y escritura modificara archivos de flujo de trabajo de Acciones de GitHub sin un ámbito de flujo de trabajo. El "Contenidos del repositorio" debe aplicar el ámbito del flujo de trabajo. Se informó de esta vulnerabilidad mediante el programa GitHub Bug Bounty y se le ha asignado el código CVE-2022-46258.

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

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

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

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

Después de una configuración de los correos electrónicos de resumen de alerta y Dependabot, la instancia no enviaría correos electrónicos de resumen a los usuarios suspendidos.

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

Al usar la acción CodeQL, las anotaciones de ejecuciones incluirían un error falso HttpError: Upload not found.

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

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

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

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

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

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

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

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

Las versiones de la serie 3.6 del servidor de GitHub Enterprise ya no son adecuadas para probar SCIM. Para seguir usando la versión beta privada de SCIM, actualice la instancia a la versión 3.7.3 o posterior. Para más información, consulta "Actualización de GitHub Enterprise Server". [Actualizado: 17/04/2023]

ALTA: Se han actualizado las dependencias de la Consola de administración a las versiones de revisión más recientes, que solucionan vulnerabilidades de seguridad, como CVE-2022-30123 y CVE-2022-29181.

ALTA: Se han agregado comprobaciones para solucionar una vulnerabilidad de clave de caché incorrecta que permitía a un actor no autorizado acceder a los archivos del repositorio privado mediante un repositorio público. A esta vulnerabilidad se le ha asignado el código CVE-2022-23738.

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

MEDIA: Se ha actualizado Redis a 5.0.14 para la solución de CVE-2021-32672 y CVE-2021-32762.

MEDIA: Se han actualizado los ejecutores de Acciones de GitHub para corregir un error que permitía que las variables de entorno de los trabajos de Acciones de GitHub aplicaran escape al contexto de la variable y modificaran la invocación de comandos docker directamente. Para más información, consulta el aviso de seguridad del ejecutor de Acciones.

MEDIA: Se ha identificado una vulnerabilidad de administración de privilegios incorrecta en GitHub Enterprise Server que permitía a los usuarios con privilegios inadecuados crear o eliminar páginas mediante la API. Para aprovechar esta vulnerabilidad, un atacante tendría que agregarse al repositorio de una organización con permisos de escritura. Esta vulnerabilidad se ha notificado mediante el programa de GitHub Bug Bounty y se le ha asignado el código CVE-2022-23737.

BAJA: Debido a una vulnerabilidad de CSRF, una solicitud GET al punto de conexión site/toggle_site_admin_and_employee_status de la instancia podría alternar el estado del administrador del sitio de un usuario sin saberlo.

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

Después de que un administrador del sitio haya realizado un cambio que ha desencadenado una ejecución de configuración, como la deshabilitación de Acciones de GitHub, es posible que se produzca un error en la validación de servicios con el mensaje WARNING: Validation encountered a problem.

Después de que un administrador del sitio ha instalado una revisión activa con cambios de los recursos de la interfaz web, como imágenes o archivos de JavaScript, la instancia no sirve los nuevos recursos.

Cuando un usuario ha accedido a un repositorio cuyo nombre se ha cambiado mediante Git, en el nombre de host de la salida de Git se indica incorrectamente GitHub.com en lugar del nombre de host de la instancia.

En las instancias que usan la autenticación LDAP y la sincronización LDAP, se producirá un error en la sincronización e imprimirá undefined method ord for nil:NilClass en ldap-sync.log.

Cuando un usuario visitó vínculos para ver el historial o sugerir una mejora en la base de datos de asesoramiento de GitHub, las direcciones URL eran incorrectas, lo que provocaba un error 404.

Los recursos eliminados y los programados para purgarse dentro de un repositorio, como los archivos LFS, han tardado demasiado tiempo en limpiarse.

En las instancias configuradas para alta disponibilidad, ghe-repl-status informó incorrectamente de que la replicación estaba detrás de repositorios que los usuarios habían eliminado anteriormente.

Si un usuario ha instalado una aplicación de GitHub para la cuenta de usuario y, después, la ha convertido en una cuenta de organización, a la aplicación no se le han concedido permisos de organización.

Las alertas del examen de secretos que faltan en la instancia con una licencia de GitHub Advanced Security que no se actualizaron directamente a GitHub Enterprise Server 3.4 ahora son visibles en la interfaz web y a través de la API REST.

En algunos casos, en una instancia con una licencia de GitHub Advanced Security, algunos tokens detectados por el examen de secretos se notificaron como "tokens desconocidos".

Para asegurarte de que los administradores del sitio puedan completar correctamente una actualización, ahora la instancia ejecutará una comprobación preparatoria para asegurarse de que la máquina virtual cumple los requisitos mínimos de hardware. También se comprueba el estado de Elasticsearch. Puedes revisar los requisitos actuales de CPU, memoria y almacenamiento para GitHub Enterprise Server en la sección "Requisitos mínimos" de cada artículo de "Configurar una instancia del servidor de GitHub Enterprise".

Las versiones de la serie 3.6 del servidor de GitHub Enterprise ya no son adecuadas para probar SCIM. Para seguir usando la versión beta privada de SCIM, actualice la instancia a la versión 3.7.3 o posterior. Para más información, consulta "Actualización de GitHub Enterprise Server". [Actualizado: 17/04/2023]

Los archivos de repositorio de las migraciones ahora incluyen un campo is_archived.

ALTA: Una aplicación de GitHub podría usar un token con ámbito de usuario a servidor para omitir la lógica de autorización de usuario y escalar los privilegios.

BAJA: La concesión a un usuario la capacidad de omitir las protecciones de rama ya no permite al usuario omitir el requisito de verificación de firma.

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

En algunos casos, collectd podría registrar errores excesivos relacionados con las métricas en /var/log/collectd.log.

Al configurar el nombre de dominio externo de un nodo de réplica de caché del repositorio mediante ghe-repl-node --cache-domain, el comando devolvería un error que impedía que se habilitara el almacenamiento en caché de Git LFS.

Error en la instalación de un certificado TLS cuando la cadena de asunto del certificado incluía caracteres UTF-8.

Se podría producir un error en las ejecuciones de configuración cuando un administrador ha establecido manualmente retry-limit o retry-sleep-duration mediante ghe-config.

La opción de habilitar el cifrado TLS para las conexiones SMTP entrantes a una instancia faltaba en la Consola de administración.

En algunos casos, el panel de supervisión de la Consola de administración no se cargaría correctamente.

Se ha quitado un vínculo no funcional para exportar gráficos de supervisión de la Consola de administración como una imagen PNG.

El comando ghe-find-insecure-git-operations no ha devuelto todas las operaciones de Git no seguras después de cada invocación.

Al enviar un paquete de soporte técnico al soporte técnico de GitHub Enterprise mediante ghe-support-upload, la opción -t no asociaría correctamente el paquete cargado con el vale especificado.

Un vínculo a la configuración de seguridad de la cuenta empresarial de la instancia podría representar una vista incorrecta.

En raras ocasiones, una actualización de GitHub Enterprise Server 3.3 a 3.4 modificaría incorrectamente cómo se almacenan los datos, lo que provocaría errores durante futuras actualizaciones. Al actualizar directamente a esta versión desde la versión 3.3, no se producirá el error.

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

Los clones o las capturas de Git mediante SSH podrían experimentar daños en los datos para las transferencias de más de 1 GB de tamaño.

Después de que un usuario haya eliminado o restaurado paquetes desde la interfaz web, los recuentos de los paquetes se podrían representar incorrectamente.

Después de una configuración correcta de los correos electrónicos de resumen de alerta y Dependabot, la instancia no enviaría correos electrónicos de resumen.

Se han vuelto a habilitar flujos de trabajo de Acciones de GitHub deshabilitados manualmente en un repositorio si el repositorio ha recibido una inserción con más de 2048 confirmaciones, o bien si ha cambiado la rama predeterminada del repositorio.

Al ver la diferencia de una solicitud de incorporación de cambios para un archivo grande con muchas líneas entre cambios, no era posible expandir la vista para mostrar todos los cambios.

Si se han habilitado las protecciones de rama, la variable de entorno GITHUB_REF_PROTECTED y los contextos github.ref_protected para ejecuciones de flujo de trabajo de Acciones de GitHub se han establecido incorrectamente como false.

Los repositorios de paquetes mostraban erróneamente una sección "Usado por".

Las versiones de la serie 3.6 del servidor de GitHub Enterprise ya no son adecuadas para probar SCIM. Para seguir usando la versión beta privada de SCIM, actualice la instancia a la versión 3.7.3 o posterior. Para más información, consulta "Actualización de GitHub Enterprise Server". [Actualizado: 17/04/2023]

Tras desbloquear un repositorio para su acceso temporal, un administrador de sitio no podía administrar los ajustes de los productos de seguridad en el repositorio.

Podrían aparecer claves SSH administrativas duplicadas en la Consola de administración y en el archivo /home/admin/.ssh/authorized_keys.

La página de administración del sitio para usuarios individuales en http(s)://HOSTNAME/stafftools/users/USERNAME/admin contenía funcionalidad no pensada para GitHub Enterprise Server.

En algunos casos, la ejecución de ghe-cluster-config-apply podría replicar una configuración vacía en nodos existentes de un clúster.

En otros casos, las ejecuciones de configuración iniciadas con ghe-config-apply no se completaban o devolvían un error Container count mismatch.

Después de actualizar un certificado TLS autofirmado en una instancia de GitHub Enterprise Server, los elementos de la interfaz de usuario de algunas páginas de la interfaz web no aparecían.

En algunos casos, las tareas en segundo plano se bloqueaban porque se utilizaba una biblioteca simultáneamente a pesar de no ser segura para subprocesos.

La barra de administrador del sitio de la parte superior de la interfaz web contenía un enlace roto al SHA de la versión en ejecución de la aplicación.

Los propietarios de la organización no pudieron establecer el nivel de acceso requerido para crear discusiones.

Los usuarios de las discusiones fueron dirigidos incorrectamente a las guías de la comunidad de GitHub.com.

En algunos casos, se solicitó incorrectamente a los usuarios que verificasen su correo electrónico antes de crear una discusión.

Las alertas de los clientes de escaneo de secretos de GitHub Advanced Security no aparecían en la interfaz de usuario web ni en la API REST si el administrador de un sitio no actualizaba directamente a GitHub Enterprise Server 3.4. Las alertas ya son visibles.

Se ha acelerado la generación de conjuntos de soporte gracias a un saneamiento de registros en paralelo. Para más información sobre los conjuntos de productos admitidos, consulta "Cómo proporcionar datos al servicio de soporte técnico de GitHub".

Las API que contienen la ruta organization o org ahora aceptan el slug o el identificador de la organización. Anteriormente, las API solo aceptaban slugs, lo que provocaba que los encabezados Link de los puntos de conexión de GitHub Advanced Security no fueran accesibles. Para más información, consulta "Organizaciones" en la documentación de la API REST.

El registro de auditoría empresarial incluye ahora más eventos generados por el usuario, como project.create. La API REST también devuelve eventos adicionales generados por el usuario, como repo.create. Para obtener más información, vea «Acceso al registro de auditoría de la empresa» y «Uso de la API de registro de auditoría para la empresa».

En algunos casos, las réplicas en caché rechazaban algunas operaciones de Git en repositorios recientemente actualizados. Para más información sobre el almacenamiento en caché del repositorio, consulta "Acerca del almacenamiento de repositorios en caché".

Ahora puede configurar el banner de anuncio global para que se pueda descartar mediante la API de REST. Para obtener más información, vea «Personalizar los mensajes de usuario para tu empresa».

Las versiones de la serie 3.6 del servidor de GitHub Enterprise ya no son adecuadas para probar SCIM. Para seguir usando la versión beta privada de SCIM, actualice la instancia a la versión 3.7.3 o posterior. Para más información, consulta "Actualización de GitHub Enterprise Server". [Actualizado: 17/04/2023]

El almacenamiento en caché de repositorios está disponible con carácter general. El almacenamiento en caché de los repositorios aumenta el rendimiento de lectura de Git para los desarrolladores distribuidos, lo que proporciona la localización de datos y la comodidad de replicación geográfica sin flujos de trabajo de inserción. Con la versión de disponibilidad general, el Servidor de GitHub Enterprise almacena tanto datos Git como Git LFS. Para obtener más información, vea «Acerca del almacenamiento de repositorios en caché».

Los administradores del sitio pueden configurar una fecha límite para permitir operaciones de Git a través de SSH que usan una clave RSA y están firmadas con la función hash SHA-1. De forma predeterminada, estas conexiones producirán un error en las claves RSA agregadas a las cuentas de usuario después de la fecha límite de medianoche (UTC) del 1 de agosto de 2022. Para obtener más información, consulta Entradas en desuso. [Actualizado: 31/01/2023]

GitHub Enterprise Server permite opcionalmente el anuncio de una clave de host Ed25519. Para obtener más información, consulta "Configuración de claves de host para la instancia".

Puedes solicitar cifrado TLS para conexiones SMTP entrantes a la instancia. Para más información, vea "Configuración del correo electrónico para notificaciones".

• Nota: Esta característica no está disponible en GitHub Enterprise Server 3.6.0 y 3.6.1. La característica está disponible en la versión 3.6.2. [Actualizado: 22/09/2022]

Puedes transmitir el registro de auditoría y los eventos Git de tu instancia a Amazon S3, Azure Blob Storage, Azure Event Hubs, el almacenamiento en la nube de Google o Splunk. La transmisión del registro de auditoría se encuentra en versión beta pública y está sujeta a cambios. Para más información, vea "Streaming del registro de auditoría para su empresa".

Las estadísticas del servidor ahora están disponibles con carácter general. Las estadísticas del servidor acumulan los datos de utilización agregados de tu instancia del servidor de GitHub Enterprise, que puedes utilizar para anticipar mejor las necesidades de tu organización, entender cómo trabaja tu equipo y demostrar el valor que consigues del servidor de GitHub Enterprise. Para obtener más información, consulta "Acerca de las estadísticas del servidor".

Los propietarios empresariales pueden unirse a organizaciones de la instancia como miembro o como propietario desde la página Organizaciones de la cuenta de la empresa. Para más información, vea "Administración del rol en una organización que pertenece a la empresa".

Los propietarios empresariales pueden permitirle a los usuarios descartar el banner del anuncio configurado global. Para más información, vea "Personalización de mensajes de usuario para la empresa".

Los usuarios en una instancia con una licencia de seguridad avanzada de GitHub pueden optar por recibir un evento Webhook que se desencadene cuando un propietario empresarial o un administrador del repositorio habilita o deshabilita un código de seguridad o una característica de análisis. Para más información, consulte la siguiente documentación.

• "Eventos y cargas útiles de un webhook" en la documentación del webhook
• "Administración de la configuración de seguridad y análisis de la organización"
• "Administración de características de seguridad y análisis para el repositorio"

Los usuarios en una instancia con una licencia de seguridad avanzada de GitHub pueden añadir de forma opcional un comentario cuando descarten una alerta de análisis de códigos en la UI de la web o mediante la API de REST. Los comentarios de descarte aparecen en la escala de tiempo del evento. Los usuarios también pueden añadir o recuperar un comentario de descarte mediante la API de REST. Para obtener más información, consulta "Evaluación de prioridades de las alertas de examen de código en solicitudes de incorporación de cambios" y "Examen de código" en la documentación de la API REST.

En instancias con una licencia de seguridad avanzada de GitHub, el análisis de secretos impide la filtración de secretos en el editor web. Para más información, vea "Protección de inserciones para el examen de secretos".

Los propietarios empresariales y los usuarios en una instancia con licencia de seguridad avanzada de GitHub pueden ver las alertas de análisis de secretos y evitar la protección de inserciones de análisis de secretos en la empresa y en el registro de auditoría de la organización mediante la API de REST. Para más información, consulte la siguiente documentación.

• "Protección de inserciones con examen de secretos"
• "Eventos de registro de auditoría de la empresa"
• "Revisión del registro de auditoría de la organización"
• "Examen de secretos" en la documentación de la API REST

Los propietarios empresariales en una instancia con licencia de seguridad avanzada de GitHub pueden realizar ensayos de patrones de análisis de secretos para la empresa y todos los usuarios pueden realizar ensayos cuando editen un patrón. Los ensayos te permiten entender el impacto de un patrón en toda la instancia y perfeccionar el patrón antes de la publicación y generación de alertas. Para más información, vea "Definición de patrones personalizados para el análisis de secretos".

Los usuarios en una instancia con una licencia de GitHub Advanced Security pueden usar los parámetros sort y direction en la API REST cuando recuperan alertas de examen de secretos y ordenar en base a los campos created o updated de las alertas. Los nuevos parámetros están disponibles para toda la instancia o para organizaciones o repositorios individuales. Para más información, consulte la siguiente documentación.

• "Enumeración de alertas de examen de secretos para una empresa"
• "Enumeración de alertas de examen de secretos para una organización"
• "Enumeración de alertas de examen de secretos para un repositorio"
• "Examen de secretos" en la documentación de la API REST

Los contenidos del repositorio github/codeql-go se han movido al repositorio github/codeql para que estén en bibliotecas parecidas para todos los otros lenguajes de programación admitidos por CodeQL. Las consultas de código abierto de CodeQL, las bibliotecas y el extractor para analizar códigos bases escritos en el lenguaje de programación Go con las herramientas de análisis de código CodeQL de GitHub se pueden encontrar en la nueva ubicación. Para obtener más información, incluidas las instrucciones para migrar los flujos de trabajo existentes, consulta github/codeql-go#741.

Los propietarios empresariales en instancias con licencia de seguridad avanzada de GitHub pueden ver un resumen de las alertas de Dependabot para toda la instancia, incluida una vista céntrica en el repositorio de riesgos de seguridad de la aplicación y una vista céntrica de todas los análisis de secretos y alertas de Dependabot. Las vistas están en versión beta y están sujeta a cambios y las vistas céntricas de alertas de análisis de código están planeadas para una versión futura del servidor de GitHub Enterprise. Para más información, vea "Visualización de la información general sobre seguridad".

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

• Nota: Esta característica no está disponible en GitHub Enterprise Server 3.6.0. La característica está disponible en GitHub Enterprise Server 3.7.0 y versiones posteriores. [Actualizado: 19/10/2022]

Dependabot actualiza las dependencias@types al mismo tiempo que el paquete correspondiente en los proyectos de TypeScript. Antes de este cambio, los usuarios veían solicitudes de incorporación de cambios distintas para un paquete y para el paquete @types correspondiente. Esta característica se habilita automáticamente para repositorios que contengan paquetes @types en el objeto devDependencies del proyecto, dentro del archivo package.json. Puedes deshabilitar este comportamiento estableciendo el campo ignore del archivo dependabot.yml en @types/*. Para obtener más información, consulta "Acerca de las actualizaciones a la versión del Dependabot" y "Opciones de configuración para el archivo dependabot.yml".

Las Acciones de GitHub pueden imponer revisiones de dependencia en las solicitudes de incorporación de cambios de los usuarios al escanear para dependencias y avisarán a los usuarios sobre sus vulnerabilidades de seguridad asociadas. La acción dependency-review-action está asistida por un nuevo punto de conexión de API que diferencia las dependencias desde dos revisiones cualesquiera. Para más información, vea "Acerca de la revisión de dependencias".

El gráfico de dependencias detecta los archivos Cargo.toml y Cargo.lock para Rust. Estos archivos se mostrarán en la sección Gráfico de dependencias de la pestaña Información. Los usuarios recibirán alertas y actualizaciones de Dependabot para detectar vulnerabilidades asociadas a sus dependencias de Rust. Los metadatos del paquete, incluida la asignación de paquetes a repositorios, se añadirán en una fecha posterior. Para más información, vea "Acerca del gráfico de dependencias".

Si GitHub Connect está conectado en tu instancia, los usuarios pueden contribuir con mejorías a una asesoría de seguridad en GitHub Advisory Database. Para contribuir, haz clic en Sugerir mejorías para vulnerabilidad en la vista de detalles del asesor. Para obtener más información, consulte los siguientes artículos.

• "Administración de GitHub Connect"
• "Exploración de vulnerabilidades de seguridad en GitHub Advisory Database" en la documentación de GitHub Enterprise Cloud
• "Acerca de los avisos de seguridad de GitHub para repositorios" en la documentación de GitHub Enterprise Cloud
• "Edición de avisos de seguridad en GitHub Advisory Database" en la documentación de GitHub Enterprise Cloud

Dentro de un flujo de trabajo que llama a un flujo de trabajo reutilizable, los usuarios pueden pasar los secretos al flujo de trabajo reutilizable con secrets: inherit. Para más información, vea "Reutilización de flujos de trabajo".

Cuando se utilizan las Acciones de GitHub, para reducir el riesgo de fusionar un cambio que no había sido revisado por otra persona en una rama protegida, los propietarios empresariales y los administradores del repositorio pueden evitar que las Acciones creen solicitudes de incorporación de cambios. Los propietarios de las organizaciones podían habilitar esta restricción previamente. Para obtener más información, consulte los siguientes artículos.

• "Aplicación de directivas de Acciones de GitHub en tu empresa"
• "Deshabilitación o limitación de Acciones de GitHub para la organización"
• "Administración de la configuración de Acciones de GitHub para un repositorio"

Los usuarios pueden escribir un único flujo de trabajo desencadenado por workflow_dispatch y workflow_call, y usar el contexto inputs para acceder a los valores de entrada. Anteriormente, las entradas workflow_dispatch estaban en la carga del evento, lo cual aumentaba la dificultad para los creadores de flujos de trabajo que querían escribir un flujo de trabajo que fuera tanto reutilizable como desencadenado manualmente. En el caso de los flujos de trabajo desencadenados por workflow_dispatch, las entradas siguen estando disponibles en el contexto github.event.inputs para mantener la compatibilidad. Para más información, vea "Contextos".

Para resumir el resultado de un trabajo, los usuarios pueden generar Markdown y publicar el contenido como un resumen del trabajo. Por ejemplo, después de ejecutar pruebas con Acciones de GitHub, un resumen puede aportar información general de las pruebas aprobadas, falladas u omitidas, reduciendo potencialmente la necesidad de revisar el resultado completo de la bitácora. Para más información, consulta "Comandos de flujo de trabajo para Acciones de GitHub".

Para diagnosticar con más facilidad los fallos al volver a ejecutar un trabajo durante un flujo de trabajo, los usuarios pueden habilitar el registro de depuración, el cual emite información sobre la ejecución y el entorno del trabajo. Para obtener más información, consulta "Volver a ejecutar flujos de trabajo y trabajos" y "Uso de registros de ejecución de flujo de trabajo".

Si gestionas ejecutores autoalojados para Acciones de GitHub, puedes asegurarte de un estado consistente en el propio ejecutor antes y después de ejecutar un flujo de trabajo al definir qué scripts se ejecutan. Al usar scripts, ya no necesitas que los usuarios incorporen manualmente estos pasos en los flujos de trabajo. Los scripts antes y después del trabajo están en versión beta y sujetos a cambios. Para obtener más información, consulta "Ejecución de scripts antes o después de un trabajo".

Los propietarios empresarios pueden migrar imagenes de contenedor del Registro Docker de GitHub al Registro de Contenedores de GitHub. El Registro de contenedor proporciona las ventajas siguientes:

• Mejora el uso compartido de contenedores en una organización.
• Permite la aplicación de permisos de acceso granulares.
• Permite el uso anónimo compartido de imágenes de contenedor públicas.
• Implementa los estándares OCI para hospedar imágenes Docker.

El Registro de contenedor está en versión beta y está sujeto a cambios. Para obtener más información, consulta "Migración de la empresa al registro de contenedor desde el registro de Docker".

Los Debates de GitHub están disponibles para Servidores de GitHub Enterprise. los Debates de GitHub ofrecen un espacio central para hacer preguntas, compartir ideas y crear conexiones. Para obtener más información, consulta "Debates sobre GitHub".

Los propietarios empresariales pueden configurar una directiva para controlar si los nombres de usuario o los nombres completos de la gente se muestran en repositorios internos o públicos. Para más información, vea "Aplicación de directivas de administración de repositorios en la empresa".

Los usuarios pueden crear archivos README exclusivos para los usuarios de la organización. Para más información, consulta "Personalización del perfil de la organización".

Los propietarios empresariales pueden anclar un repositorio al perfil de una organización desde el repositorio mediante el nuevo menú desplegable Anclar repositorio. Los repositorios públicos anclados aparecen para todos los usuarios de la instancia, mientras que los repositorios públicos, privados e internos son solo visibles para miembros de la organización.

Al crear una bifurcación, los usuarios pueden personalizar el nombre de la bifurcación. Para obtener más información, consulte "Bifurcación de un repositorio".

Los usuarios pueden eliminar una rama que esté asociada con una solicitud de incorporación de cambios abierta. Para más información, vea "Creación y eliminación de ramas dentro del repositorio".

Los repositorios con varias licencias muestran todas las licencias en la barra lateral "Acerca de" en la pestaña Código. Para obtener más información, consulta "Generar licencia para un repositorio".

Los usuarios pueden requerir una implementación exitosa de una rama antes de que nadie pueda combinar la solicitud de incorporación de cambios asociada con la rama. Para más información, consulta "Acerca de las ramas protegidas" y "Administración de una regla de protección de rama".

Los propietarios empresariales pueden evitar que los propietarios de organizaciones inviten a colaboradores a los repositorios de la instancia. Para obtener más información, consulta "Aplicación de una directiva para invitar a colaboradores a los repositorios".

Los usuarios pueden conceder excepciones a las Aplicaciones de GitHub para cualquier regla de protección de la rama que admita excepciones. Para más información, consulta "Acerca de las aplicaciones" y "Administración de una regla de protección de rama".

Para claves de firma GPG públicas que han caducado o se han revocado, el servidor de GitHub Enterprise verifica las firmas de confirmación y muestra confirmación como verificado si el usuario realizó la confirmación mientras la clave era todavía válida. Los usuarios también pueden cargar claves GPG caducadas o revocadas. Para obtener más información, consulte "Acerca de la comprobación de firmas de confirmación".

Para afirmar que una confirmación cumple las reglas y licencias del repositorio, los propietarios empresariales y los administradores del repositorio ahora pueden pedirle a los desarrolladores que firmen las confirmaciones hechas a través de la interfaz web. Para obtener más información, consulta "Administración de la directiva de aprobación de confirmaciones para la organización" y "Administración de la directiva de aprobación de confirmaciones para el repositorio".

Al utilizar el árbol de archivos situado en la pestaña Archivos cambiados de una solicitud de incorporación de cambios, los usuarios pueden navegar en archivos modificados, entender el tamaño y ámbito de los cambios y concentrarse en la revisión. El árbol de archivos aparece si una solicitud de incorporación de cambios modifica al menos dos archivos y si la ventana del navegador es suficientemente ancha. Para obtener más información, consulta "Revisión de los cambios propuestos en una solicitud de incorporación de cambios" y "Filtrado de archivos en una solicitud de incorporación de cambios".

Los usuarios pueden usar de forma predeterminada los títulos de la solicitud de incorporación de cambios como mensaje de confirmación para fusión mediante combinación con "squash". Para más información, vea "Configuración de las fusiones mediante combinación con "squash" de confirmaciones para las solicitudes de incorporación de cambios".

En GitHub Mobile para iOS 1.80.0 y versiones posteriores, los usuarios pueden editar archivos dentro de la rama de temas de una solicitud de incorporación de cambios. La compatibilidad con la edición de archivos llegará a GitHub Mobile para Android en una versión futura. [Actualizado: 13/09/2022]

Al ver los detalles de una versión concreta, los usuarios pueden ver la fecha de creación para cada versión del recurso. Para más información, vea "Visualización de las versiones y etiquetas del repositorio".

Al crear una versión con notas de la versión generadas automáticamente, los usuarios pueden ver que la etiqueta se identifica como la versión anterior y, a continuación, seleccionar una etiqueta diferente para especificar como la versión anterior. Para más información, vea "Notas de la versión generadas automáticamente".

La edición de Markdown en la interfaz web se ha mejorado.

• Después de que un usuario seleccione texto y pegue una URL, el texto seleccionado se convertirá en un hipervínculo de Markdown a la URL pegada.
• Cuando un usuario pega celdas de una hoja de cálculo o tablas HTML, el texto resultado se representará como una tabla.
• Cuando un usuario copie texto que contenga hipervínculos, el texto pegado incluirá el hipervínculo como hipervínculo de Markdown.

Para más información, vea "Sintaxis básica de escritura y formato".

Al editar un archivo Markdown en la interfaz web, al hacer clic en la pestaña Versión preliminar se desplazará automáticamente al lugar que se estaba editando en la versión preliminar. La ubicación del desplazamiento se basa en la posición del cursor antes de hacer clic en la pestaña Versión preliminar.

El protocolo Git sin cifrar y sin autenticar ahora está deshabilitado de forma predeterminada. Si no vuelves a habilitar el protocolo después de actualizar a GitHub Enterprise Server 3.6 o versiones posteriores, las conexiones git:// en el puerto 9418 devolverán el error siguiente.

The unauthenticated git protocol on port 9418 is no longer supported.

Si quieres admitir el protocolo en el entorno, debes volver a habilitar manualmente la característica. Para obtener más información, consulta "Aplicación de directivas de administración de repositorios en la empresa" y el blog de GitHub. [Actualizado: 31/01/2023]

Los elementos interactivos de la interfaz web como hipervínculos y botones muestran un contorno visible cuando se enfocan con el teclado, para ayudar a los usuarios a encontrar la posición actual en una página. Además, cuando se enfocan, los campos de formulario tienen un contorno con un contraste mayor.

Si un usuario actualiza la página mientras crea una nueva incidencia o solicitud de incorporación de cambios, los usuarios asignados, revisores, etiquetas y proyectos se guardaran.

Ahora se admite la versión 7.0 del hipervisor de VMware vSphere ESXi. [Actualizado: 07/09/2022]

Las versiones de la serie 3.6 del servidor de GitHub Enterprise ya no son adecuadas para probar SCIM. Para seguir usando la versión beta privada de SCIM, actualice la instancia a la versión 3.7.3 o posterior. Para más información, consulta "Actualización de GitHub Enterprise Server". [Actualizado: 17/04/2023]

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

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

Los archivos de seguimiento de Git LFS cargados desde la interfaz web se agregan incorrectamente de forma directa al repositorio.

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

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

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

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

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

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

Los patrones personalizados para el examen de secretos tienen .* como delimitador de final, específicamente en el campo "Después del secreto". Este delimitador causa inconsistencias en los exámenes de secretos entre repositorios y es posible que note brechas en el historial de un repositorio en el que no se han completado exámenes. Los exámenes incrementales también pueden verse afectados. Para evitar incidencias con los exámenes, modifica el final del patrón para quitar el delimitador .*.

En algunos casos, los clientes de GitHub Advanced Security que actualicen a GitHub Enterprise Server 3.6 pueden observar que faltan alertas del análisis de secretos en la interfaz de usuario web y la API REST. Para asegurarte de que las alertas permanecen visibles, no omitas la versión 3.4 cuando actualices a la versión más reciente. Para planear una actualización a través de la versión 3.4, consulta el Asistente para actualización.

• Para mostrar las alertas que faltan para todos los repositorios que pertenecen a una organización, los propietarios de la organización pueden ir a la configuración de seguridad y análisis del código de la organización y, a continuación, hacer clic en Habilitar todo para el análisis de secretos. Para obtener más información, vea «Administrar la configuración de seguridad y análisis de su organización».
• Para mostrar las alertas que faltan para un repositorio individual, los usuarios con acceso de administrador al repositorio pueden deshabilitar y, a continuación, habilitar el análisis de secretos para el repositorio. Para obtener más información, vea «Administración de la configuración de seguridad y análisis para el repositorio».

Hay disponible una corrección en la versión de revisión 3.6.1. [Actualizado: 01/09/2022]

Después de actualizar un nodo de réplica a GitHub Enterprise Server 3.6.0 o una versión posterior y reiniciar la replicación, la replicación de Git puede detener el progreso y continuar mostrando WARNING: git replication is behind the primary …. Si encuentra este problema conocido, póngase en contacto con Soporte técnico para GitHub Enterprise. [Actualizado: 03/10/2022]

Las compilaciones de GitHub Pages pueden agotar el tiempo de espera en las instancias de AWS configuradas para alta disponibilidad. [Actualizado: 28/11/2022]

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

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.

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