Enterprise Server 3.8 release notes
Enterprise Server 3.8.4
Download GitHub Enterprise Server 3.8.4May 30, 2023
3.8.4: Security fixes
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.
3.8.4: Bug fixes
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
ofread
orwrite
, the instance returned a500
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.
3.8.4: Changes
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
.
3.8.4: Known issues
Custom firewall rules are removed during the upgrade process.
The GitHub Packages npm registry no longer returns a time value in metadata responses. This was done to allow for substantial performance improvements. We continue to have all the data necessary to return a time value as part of the metadata response and will resume returning this value in the future once we have solved the existing performance issues.
During the validation phase of a configuration run, a
No such object
error may occur for the Notebook and Viewscreen services. This error can be ignored as the services should still correctly start.If the root site administrator is locked out of the Management Console after failed login attempts, the account will not unlock automatically after the defined lockout time. Someone with administrative SSH access to the instance must unlock the account using the administrative shell. For more information, see "Troubleshooting access to the Management Console." [Updated: 2023-02-23]
On an instance in a high-availability configuration, passive replica nodes accept Git client requests and forward the requests to the primary node.
When using an outbound web proxy server, the
ghe-btop
command may fail in some circumstances with the error "Error querying allocation: Unexpected response code: 401".If an instance is configured to forward logs to a target server with TLS enabled, certificate authority (CA) bundles that a site administrator uploads using
ghe-ssl-ca-certificate-install
are not respected, and connections to the server fail.When running
ghe-config-apply
, the process may stall with the messageDeployment is running pending automatic promotion
.On an instance with subdomain isolation disabled, Mermaid diagrams in the web UI display an "Unable to render rich display" error and fail to render.
Enterprise Server 3.8.3
Download GitHub Enterprise Server 3.8.3May 09, 2023
📣 Это не последний выпуск исправлений Enterprise Server. Используйте последний выпуск для последних исправлений безопасности, производительности и ошибок.
3.8.3: Security fixes
MEDIUM: обновлен Git для включения исправлений с версии 2.40.1. Дополнительные сведения см. в статье Об уязвимостях безопасности Git, объявленных в блоге GitHub.
3.8.3: Bug fixes
Пользователи не смогли отправить GIF-файлы в виде вложений в комментарии в проблеме или запросе на вытягивание.
Администратору сайта не удалось обойти прокси-сервер для домена верхнего уровня (TLD) из списка исключений экземпляра или зарегистрированных доменов верхнего уровня (TLD).
На некоторых платформах после запуска
ghe-diagnostics
пользователя с административным доступом по протоколу SSH выходные данные команды содержали косметическуюSG_IO
ошибку.Когда администратор сайта использовал GitHub Enterprise Importer для импорта данных из GitHub Enterprise Cloud, миграция завершилась сбоем во время импорта комментариев на уровне файла. Этот сбой больше не препятствует выполнению импорта.
В экземпляре с лицензией GitHub Advanced Security пользователи с ролью диспетчера безопасности для организации не могли просматривать GitHub Advanced Security параметры для организации.
В экземпляре с большим количеством организаций владельцы предприятия, которые переходили на страницу параметров "Безопасность и анализ" для предприятия, могут вернуть ошибку
500
.Начиная с GitHub Enterprise Server 3.8 с помощью интерфейса командной строки GitHub Enterprise Importer,
startRepositoryMigration
API GraphQL или REST API "Начать миграцию организации" требуется настроить поставщика хранилища BLOB-объектов в консоли управления. При использовании Хранилище BLOB-объектов Azure контейнеры хранилища были неправильно настроены как общедоступные. Хранилище BLOB-объектов Azure контейнеры теперь будут настроены как частные, и мы представили проверка, которая явно не выполняет экспорт, если контейнер хранилища является общедоступным.Когда администратор сайта использовал GitHub Enterprise Importer, импорт репозитория завершился ошибкой, если столбец проекта в репозитории содержал 2500 или более архивных карточек.
В некоторых ситуациях на экземпляре с несколькими узлами репликация Git не смогла полностью реплицировать ранее удаленные репозитории, что привело к выводу предупреждения в выходных
ghe-repl-status
данных.В экземпляре с включенными оповещениями Dependabot оповещения ошибочно скрывались при обнаружении различных уязвимостей несколькими детекторами отправки во время сборки.
GitHub Enterprise Server опубликовал метрики распределения, которые не могут быть обработаны сбором. Метрики включали
pre_receive.lfsintegrity.dist.referenced_oids
,pre_receive.lfsintegrity.dist.unknown_oids
иgit.hooks.runtime
.В некоторых случаях на экземпляре с включенным GitHub Actions развертывание сайта GitHub Pages с помощью рабочего процесса GitHub Actions завершилось сбоем с состоянием
deployment_lost
.На экземпляре с лицензией GitHub Advanced Security, которая также была настроена для часового пояса больше UTC, в списке оповещений сканирования секретов отображается ошибка "Сбой загрузки секретов", если пользователь отсортировал секреты по дате в порядке убывания.
На экземпляре с лицензией GitHub Advanced Security, где включено сканирование секретов, чрезмерное ведение журнала
/var/log
может привести к ошибкам пользователей и снижению производительности системы, если журналы занимают все свободное место на томе.
3.8.3: Changes
На экземпляре с включенным граф зависимостей фоновые службы могут обрабатывать больше трафика.
Люди с административным доступом по протоколу SSH, создающие пакет поддержки с помощью
ghe-support-bundle
служебных программ илиghe-cluster-support-bundle
, могут указать период времени для сбора данных с-p
использованием пробелов или--period
кавычек или без него. Например, в дополнение к'-p 5 days'
или-p '4 days 10 hours'
допустимы или-p 4days10hours
.-p 5days
После того как администратор сайта экспортирует архив миграции с помощью служебной программы GitHub Enterprise Importers
gh-migrator
, ссылка на архив остается доступной в течение 48 часов, а не одного часа.
3.8.3: Known issues
Настраиваемые правила брандмауэра удаляются в процессе обновления.
Реестр npm GitHub Packages больше не возвращает значение времени в ответах метаданных. Это было сделано для существенного повышения производительности. Мы по-прежнему имеем все данные, необходимые для возврата значения времени в ответе метаданных, и возобновим возврат этого значения в будущем, как только мы устраним существующие проблемы с производительностью.
На этапе проверки запуска
No such object
конфигурации может возникнуть ошибка для служб "Записная книжка" и "Экран просмотра". Эту ошибку можно игнорировать, так как службы по-прежнему должны правильно запускаться.Во время обновления до GitHub Enterprise Server 3.8.0 в кластере после обновления узлов, отличных от основного узла MySQL, и перед обновлением основного узла MySQL следующая ошибка может появиться несколько раз после запуска
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 рекомендует дождаться обновления кластера, пока эта проблема не будет устранена. Дополнительные сведения будут доступны в заметках о выпуске для предстоящего обновления GitHub Enterprise Server.
Если администратор корневого сайта заблокирован в консоли управления после неудачных попыток входа, учетная запись не будет разблокирована автоматически после определенного времени блокировки. Пользователь с административным доступом по протоколу SSH к экземпляру должен разблокировать учетную запись с помощью административной оболочки. Дополнительные сведения см. в разделе Устранение неполадок с доступом к консоли управления. [Обновлено: 23.02.2023]
В экземпляре в конфигурации с высоким уровнем доступности пассивные узлы реплика принимают клиентские запросы Git и пересылают запросы на основной узел.
При использовании исходящего веб-прокси-сервера
ghe-btop
в некоторых случаях команда может завершиться ошибкой "Error querying allocation: Unexpected response code: 401".Если экземпляр настроен на перенаправление журналов на целевой сервер с включенным протоколом TLS, пакеты центров сертификации (ЦС), которые администратор сайта отправляет с помощью
ghe-ssl-ca-certificate-install
, не учитываются, а подключения к серверу завершаются сбоем.При выполнении
ghe-config-apply
процесс может застопорился с сообщениемDeployment is running pending automatic promotion
.
Enterprise Server 3.8.2
Download GitHub Enterprise Server 3.8.2April 18, 2023
📣 Это не последний выпуск исправлений Enterprise Server. Используйте последний выпуск для последних исправлений безопасности, производительности и ошибок.
3.8.2: Bug fixes
На экземпляре с включенным GitHub Actions вложенные вызовы повторно используемых рабочих процессов в задании повторного рабочего процесса с матрицей правильно оценивают контексты в выражениях, например
strategy: ${{ inputs.strategies }}
.Запросы на скачивание объектов Git LFS не завершались до тех пор, пока не будет возвращен окончательный размер загрузки, что повлияло на задержку этих запросов, особенно на экземпляре с узлами, функционируют в качестве кэша репозитория.
На экземпляре в конфигурации с высоким уровнем доступности операция может завершиться ошибкой
git push
, если GitHub Enterprise Server одновременно создавал репозиторий на узле реплика.Когда администратор сайта выполнялся
ghe-btop
через SSH, команда не выполнялась и произошла/usr/bin/env: python3: No such file or directory
ошибка.Администраторам сайта, которые готовились включить GitHub Actions, не удалось запустить
ghe-actions-precheck
служебную программу, так как файл скриптов не был исполняемым.В некоторых случаях на экземпляре с лицензией GitHub Advanced Security пользователи не могли загрузить страницу анализа безопасности и увидели ошибку
500
.Если в экземпляре с включенным GitHub Connect включен параметр "Пользователи могут искать GitHub.com", проблемы в частных и внутренних репозиториях не включались в результаты поиска пользователей для GitHub.com.
После восстановления удаленной организации организация не появилась в списке организаций экземпляра.
После того как администратор сайта экспортировал архив миграции в AWS S3 с помощью служебной программы GitHub Enterprise Importer
gh-migrator
, URL-адрес архива стал недоступен.Если администратор сайта экспортировал архив миграции в контейнер в регионе AWS S3s us-east-1 с помощью служебной программы GitHub Enterprise Importer
gh-migrator
, архив был недоступен.Размер собранных журналов может быстро увеличиваться из-за включения
kredz.*
метрик, которые не могут быть проанализированы с помощью StatsD и приводят к сообщениям об ошибках.
3.8.2: Changes
Если администратор сайта предоставляет недопустимую конфигурацию для хранилища BLOB-объектов для GitHub Actions или GitHub Packages в экземпляре, на странице предварительных проверок отображаются сведения и сведения об устранении неполадок.
После того как администратор сайта экспортирует архив миграции с помощью служебной программы GitHub Enterprise Importer
gh-migrator
, ссылка на архив остается доступной в течение 48 часов, а не одного часа.На экземпляре с лицензией на GitHub Advanced Security пользователи, создающие пользовательские шаблоны для сканирования секретов, могут предоставлять выражения, которые должны или не должны совпадать, не более 2000 символов. Это ограничение увеличено с 1000 символов.
3.8.2: Known issues
Пользовательские правила брандмауэра удаляются в процессе обновления.
Реестр npm GitHub Packages больше не возвращает значение времени в ответах метаданных. Это было сделано для существенного улучшения производительности. Мы по-прежнему имеем все данные, необходимые для возврата значения времени в ответе метаданных, и возобновим возврат этого значения в будущем, как только мы устраним существующие проблемы с производительностью.
На этапе проверки запуска
No such object
конфигурации может возникнуть ошибка для служб "Записная книжка" и "Экран просмотра". Эту ошибку можно игнорировать, так как службы по-прежнему должны правильно запускаться.Во время обновления до GitHub Enterprise Server 3.8.0 в кластере после обновления узлов, отличных от основного узла MySQL, и перед обновлением основного узла MySQL следующая ошибка может появиться несколько раз после запуска
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 рекомендует дождаться обновления кластера, пока эта проблема не будет устранена. Дополнительные сведения будут доступны в заметках о выпуске для предстоящего обновления GitHub Enterprise Server.
Если администратор корневого сайта заблокирован в консоли управления после неудачных попыток входа, учетная запись не разблокируется автоматически после определенного времени блокировки. Пользователь с административным доступом по протоколу SSH к экземпляру должен разблокировать учетную запись с помощью административной оболочки. Дополнительные сведения см. в разделе Устранение неполадок с доступом к консоли управления. [Обновлено: 23.02.2023]
На экземпляре с лицензией GitHub Advanced Security, где включено сканирование секретов, чрезмерное вхождение в
/var/log
систему может привести к ошибкам пользователя и снижению производительности системы, если журналы занимают все свободное место на томе. Чтобы эта проблема не влияла на пользователей, отслеживайте свободное место в корневом томе экземпляра. Дополнительные сведения см. в разделах Настройка проверки секретов для (модуль) и Мониторинг (модуль). Если вы подозреваете, что эта проблема влияет на ваш экземпляр и вам нужна помощь, обратитесь в службу поддержки GitHub. [Обновлено: 03.05.2023]
Enterprise Server 3.8.1
Download GitHub Enterprise Server 3.8.1March 23, 2023
📣 Это не последний выпуск исправлений Enterprise Server. Используйте последний выпуск для последних исправлений безопасности, производительности и ошибок.
3.8.1: Security fixes
HIGH: устранена уязвимость, связанная с неправильной проверкой подлинности, которая позволяла неавторизованному субъекту изменять секреты других пользователей путем проверки подлинности через центр сертификации SSH. Эта уязвимость была обнаружена в рамках программы bounty для ошибок GitHubи назначена CVE-2023-23761. [Обновлено: 07.04.2023]
MEDIUM: устранена неправильная уязвимость сравнения, которая позволяла контрабанде фиксаций, отображая неправильный diff. Эта уязвимость была обнаружена в рамках программы bounty для ошибок GitHubи назначена CVE-2023-23762. [Обновлено: 07.04.2023]
3.8.1: Bug fixes
На экземпляре с включенным GitHub Actions задание рабочего процесса для GitHub Actions не запускается, если соответствующая группа средств выполнения была недоступна, когда задание изначально помещалось в очередь, даже если соответствующая группа средств выполнения стала доступна после того, как задание вошло в очередь.
На экземпляре с включенным GitHub Actions GitHub Actions теперь будет правильно выполняться после восстановления удаленного репозитория.
На экземпляре с включенным GitHub Actions вложенные вызовы повторно используемых рабочих процессов в задании повторного рабочего процесса с матрицей правильно оценивают контексты в выражениях, например
strategy: ${{ inputs.strategies }}
.В некоторых случаях не удалось отобразить графики на панели мониторинга консоли управления.
После того как администратор использовал
/setup/api/start
конечную точку REST API для отправки лицензии, выполнение конфигурации завершилось ошибкойConnection refused
на этапе миграции.В экземпляре в конфигурации кластера, когда администратор сайта установил режим обслуживания с помощью
ghe-maintenance -s
,Permission denied
при попытке служебной программы получить доступ/data/user/common/cluster.conf
к появляется ошибка .На экземпляре в конфигурации с высоким уровнем доступности, если администратор разорвал репликацию с узла реплика с помощью
ghe-repl-teardown
сразу после запускаghe-repl-setup
, но доghe-repl-start
, ошибка указывает на то, что скриптcannot launch /usr/local/bin/ghe-single-config-apply - run is locked
.ghe-repl-teardown
теперь отображает информационное оповещение и продолжает снос.Если во время настройки высокого уровня доступности администратор сайта прервал
ghe-repl-start
служебную программу, программа ошибочно сообщила, что репликация настроена, и экземпляр не будет выполнять ожидаемые операции очистки.Команды, которые администраторы сайта выполняли по протоколу SSH на любом из узлов экземпляров, не регистрировались в
/var/log/ssh-console-audit.log
.На экземплярах, настроенных для использования частной бета-версии SCIM для GitHub Enterprise Server, проверка подлинности пользователей с помощью ключей SSH и личных маркеров доступа завершилась сбоем из-за ошибочного требования к авторизации.
После того как пользователь импортировал репозиторий с включенной защитой от push-уведомлений, репозиторий не был сразу виден в представлении "Покрытие безопасности" в обзоре безопасности.
Ответы от конечной
/repositories
точки REST API ошибочно включали удаленные репозитории.Если администратор сайта использовал для
ghe-migrator
переноса данных в GitHub Enterprise Server, в некоторых случаях вложенная команда связи не сохраняются после импорта команд.Если репозиторий содержит
CODEOWNERS
файл с проверка заметками, вкладка "Файлы изменены" запросов на вытягивание возвращает ошибку500
и отображается сообщение "Ой, что-то пошло не так" в разделе "Файлы без изменений с проверка заметками".На экземпляре с включенным GitHub Actions, если пользователь вручную активировал рабочий процесс с помощью REST API, но не указал значения для необязательных логических значений, API не смог проверить запрос и вернул ошибку
422
.Когда пользователи выполняли поиск gist, текст в поле поиска в некоторых случаях не отображался, так как цвет текста был идентичен цвету фона полей.
В некоторых случаях на экземпляре с несколькими узлами GitHub Enterprise Server ошибочно прекращал запись на реплика файловых серверах, что приводило к тому, что данные репозитория не синхронизировались.
Если в экземпляре с включенным GitHub Connect включен параметр "Пользователи могут искать GitHub.com", пользователи не будут видеть проблемы в частных и внутренних репозиториях в результатах поиска для GitHub.com.
Владельцу предприятия не удалось включить двухфакторную проверку подлинности (2FA) для экземпляра, если владельцы предприятия не включили двухфакторную проверку подлинности для своих учетных записей пользователей. [Обновлено: 17.04.2023]
На экземпляре с включенным GitHub Packages после отправки пользователей в реестр контейнеров экземпляр ошибочно ответил ошибкой
429 Too Many Requests
в тех случаях, когда экземпляр может вместить запрос. Ограничения были увеличены, и пользователи должны получать это сообщение реже. [Обновлено: 30.05.2023]
3.8.1: Changes
Когда администратор сайта настраивает исходящий веб-прокси-сервер для GitHub Enterprise Server, экземпляр теперь проверяет домены верхнего уровня (TLD), исключенные из конфигурации прокси-сервера. По умолчанию можно исключить общедоступные TLD, которые указаны в IANA. Администраторы сайта могут указать список незарегистрированных TLD для исключения с помощью
ghe-config
. Префикс.
требуется для любых общедоступных TLD. Например, значение.example.com
является допустимым, аexample.com
— нет. Дополнительные сведения см. в разделе Настройка сервера веб-прокси исходящего трафика.Чтобы избежать периодических проблем с успехом операций Git на экземпляре с несколькими узлами, GitHub Enterprise Server проверяет состояние контейнера MySQL перед попыткой SQL-запроса. Время ожидания также было сокращено.
По умолчанию для выходных данных из
ghe-saml-mapping-csv -d
используется/data/user/tmp
путь вместо/tmp
. Дополнительные сведения см. в разделе Служебные программы командной строки.На экземпляре с лицензией на GitHub Advanced Security пользователи, создающие пользовательские шаблоны для сканирования секретов, могут предоставлять выражения, которые должны или не должны совпадать, не более 2000 символов. Это ограничение увеличено с 1000 символов.
3.8.1: Known issues
В только что настроенном экземпляре GitHub Enterprise Server без пользователей злоумышленник может создать первого администратора.
Пользовательские правила брандмауэра удаляются в процессе обновления.
Реестр npm GitHub Packages больше не возвращает значение времени в ответах метаданных. Это было сделано для существенного улучшения производительности. Мы по-прежнему имеем все данные, необходимые для возврата значения времени в ответе метаданных, и возобновим возврат этого значения в будущем после устранения существующих проблем с производительностью.
На этапе проверки запуска
No such object
конфигурации может возникнуть ошибка для служб "Записная книжка" и "Экран просмотра". Эту ошибку можно игнорировать, так как службы по-прежнему должны правильно запускаться.Во время обновления до GitHub Enterprise Server 3.8.0 в кластере после обновления узлов, отличных от основного узла MySQL, и перед обновлением основного узла MySQL следующая ошибка может появиться несколько раз после запуска
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 рекомендует дождаться обновления кластера, пока эта проблема не будет устранена. Дополнительные сведения будут доступны в заметках о выпуске для предстоящего обновления GitHub Enterprise Server.
Если администратор корневого сайта заблокирован в консоли управления после неудачных попыток входа, учетная запись не разблокируется автоматически после определенного времени блокировки. Пользователь с административным доступом по протоколу SSH к экземпляру должен разблокировать учетную запись с помощью административной оболочки. Дополнительные сведения см. в разделе Устранение неполадок с доступом к консоли управления. [Обновлено: 23.02.2023]
Использование API поиска может привести к сбою последующих запросов к другим интерфейсам. При возникновении этой проблемы затронутые пользователи API или пользовательского веб-интерфейса будут получать ответы HTTP 5xx, и это
NoMethodError
исключение будет зарегистрировано:NoMethodError (undefined method `starts_with?' for [:ok, "refs/heads/main"]:Array):
На экземпляре с лицензией GitHub Advanced Security, где включено сканирование секретов, чрезмерное вхождение в
/var/log
систему может привести к ошибкам пользователя и снижению производительности системы, если журналы занимают все свободное место на томе. Чтобы эта проблема не влияла на пользователей, отслеживайте свободное место в корневом томе экземпляра. Дополнительные сведения см. в разделах Настройка проверки секретов для (модуль) и Мониторинг (модуль). Если вы подозреваете, что эта проблема влияет на ваш экземпляр и вам нужна помощь, обратитесь в службу поддержки GitHub. [Обновлено: 03.05.2023]
Enterprise Server 3.8.0
Download GitHub Enterprise Server 3.8.0March 07, 2023
📣 Это не последний выпуск исправлений Enterprise Server. Используйте последний выпуск для последних исправлений безопасности, производительности и ошибок.
Инструкции по обновлению см. в разделе Обновление GitHub Enterprise Server.
3.8.0: Features
Бета-версия проектов
Проекты, гибкий инструмент для планирования и отслеживания работы на GitHub Enterprise Server, теперь доступен в виде бета-версии. Проект — это адаптируемая электронная таблица, которая интегрирует проблемы и запросы на вытягивание, чтобы помочь пользователям спланировать и отслеживать работу эффективно. Пользователи могут создавать и настраивать несколько представлений, а каждое представление может фильтровать, сортировать и группировать проблемы и запросы на вытягивание. Пользователи также могут определять настраиваемые поля для отслеживания уникальных метаданных для команды или проекта, что позволяет настраивать любые потребности или процессы. Эта функция может быть изменена. Дополнительные сведения см. в разделе Сведения о Projects (beta).
Администрирование экземпляров
Администраторы сайта могут повысить безопасность экземпляра, создавая выделенные учетные записи пользователей для консоли управления. Создавать учетные записи пользователей может только администратор корневого сайта. Чтобы управлять доступом для учетных записей пользователей, назначьте роль редактора или оператора. Операторы могут управлять административным доступом по протоколу SSH для экземпляра. Дополнительные сведения см. в разделе Управление доступом к консоли управления.
Чтобы установить или соблюдать внутренние политики, администраторы сайтов могут использовать консоль управления для настройки политики экземпляра для хранения данных, связанных с проверками, включая данные проверок, созданные GitHub Actions и API состояний. Администраторы могут включать или отключать хранение, устанавливать пользовательское пороговое значение хранения или устанавливать пользовательский порог жесткого удаления. Дополнительные сведения см. в разделе Настройка приложений [Обновлено: 03.02.2023]
При создании пакетов поддержки с помощью
ghe-support-bundle
программы командной строки администраторы сайта могут указать точную длительность сбора данных в пакете. Дополнительные сведения см. в статье "Программы командной строки".Управление удостоверениями и доступом
Пользователи могут просматривать и отзывать сеансы браузера и GitHub Mobile для экземпляра GitHub Enterprise Server. Дополнительные сведения см. в разделе Просмотр сеансов и управление ими.
Политики
Владельцы предприятия могут настроить, могут ли администраторы репозитория включать или отключать оповещения Dependabot. На экземплярах с лицензией GitHub Advanced Security владельцы предприятия также могут задавать политики для управления включением функций GitHub Advanced Security или проверки секретов администраторами репозиториев. Дополнительные сведения см. в разделе Применение политик безопасности и анализа кода для предприятия.
Журналы аудита
Владельцы предприятий и организаций могут поддерживать соблюдение принципа минимальных привилегий, предоставляя доступ к конечным точкам журнала аудита без предоставления полных прав администратора. Для предоставления этого доступа личные маркеры доступа и приложения OAuth теперь поддерживают
read:audit_log
область. Дополнительные сведения см. в разделе Использование API журнала аудита для предприятия.Владельцы предприятия могут проще обнаруживать и отслеживать действия, связанные с маркерами проверки подлинности, просматривая данные маркеров в событиях журнала аудита. Дополнительные сведения см. в разделе Определение событий журнала аудита, выполняемых маркером доступа.
Владельцы предприятия могут настроить потоковую передачу журналов аудита в конечную точку Datadog. Дополнительные сведения см. в разделе Потоковая передача журнала аудита для предприятия.
GitHub Advanced Security
Владельцы предприятия на экземпляре с лицензией GitHub Advanced Security могут просматривать изменения в GitHub Advanced Security, проверке секретов и включении защиты от отправки в журнал аудита. Владельцы организации могут просматривать изменения в пользовательских сообщениях для защиты от отправки в журнал аудита. Дополнительные сведения см. в следующей документации.
- "
business_secret_scanning
category actions", "business_secret_scanning_push_protection
category actions" и "business_secret_scanning_push_protection_custom_message
category actions" in "Audit Log events for your enterprise" (События журнала аудита для предприятия) - Просмотр журнала аудита для организации
- "
Владельцы предприятия на экземпляре с лицензией GitHub Advanced Security могут обеспечить соответствие требованиям и упростить развертывание проверки секретов и принудительной защиты для всех организаций на экземпляре с помощью REST API. Эта конечная точка дополняет существующий пользовательский веб-интерфейс, а также конечные точки для репозиториев и организаций. Дополнительные сведения см. в разделе Безопасность и анализ кода в документации по REST API.
Владельцы предприятий и организаций, которые используют проверку секретов на экземпляре с GitHub Advanced Security лицензией, могут использовать REST API для указания настраиваемой ссылки для отображения, когда защита от отправки блокирует отправку, содержащую секрет. Дополнительные сведения см. в разделе "Безопасность и анализ кода" или "Организации" в документации по REST API.
Пользователи экземпляра с лицензией GitHub Advanced Security, которые отклоняют оповещение о проверке секретов, могут помочь другим пользователям понять причину увольнения, предоставив необязательный комментарий с помощью веб-интерфейса или REST API. Дополнительные сведения см. в следующей документации.
- Управление оповещениями при сканировании секретов
- "Проверка секретов" в документации по REST API
Пользователи экземпляра с лицензией GitHub Advanced Security могут фильтровать результаты из API сканирования кода на основе серьезности оповещений на уровне репозитория или организации. Используйте параметр для
severity
возврата только оповещений сканирования кода с определенным уровнем серьезности. Дополнительные сведения см. в разделе "Проверка кода" в документации по REST API.Пользователи экземпляра с лицензией GitHub Advanced Security могут анализировать два дополнительных языка на наличие уязвимостей и ошибок с помощью проверки кода CodeQL. Поддержка Ruby общедоступна, а поддержка Kotlin доступна в бета-версии и может быть изменена.
- Анализ Ruby может обнаружить более чем в два раза больше распространенных слабых мест (CWEs), которые он может обнаружить во время бета-версии. В общей сложности 30 правил могут определять ряд уязвимостей, включая межсайтовые скрипты (XSS), отказ в обслуживании регулярных выражений (ReDoS), внедрение SQL и многое другое. Дополнительные библиотеки и платформы для Ruby-on-Rails гарантируют, что разработчики веб-служб получают еще более точные результаты. GitHub Enterprise Server поддерживает все распространенные версии Ruby, вплоть до 3.1.
- Поддержка Kotlin является расширением существующей поддержки Java и преимуществами существующих запросов CodeQL для Java, которые применяются как к мобильным, так и к серверным приложениям. GitHub также улучшил и добавил ряд мобильных запросов, охватывающих такие проблемы, как обработка намерений, проблемы проверки Веб-представления, внедрение фрагментов и многое другое.
Дополнительные сведения о проверке кода см. в разделе Сведения о проверке кода с помощью CodeQL.
Пользователи экземпляра с лицензией GitHub Advanced Security, использующие проверку кода CodeQL, могут настроить конфигурацию сборки для анализа Go в файле рабочего процесса GitHub Actions. Существующие рабочие процессы CodeQL для анализа Go не требуют изменений и будут поддерживаться по-прежнему. Дополнительные сведения см. в разделе Настройка рабочего процесса CodeQL для скомпилированных языков.
Dependabot
Чтобы повысить безопасность кода и упростить процесс обновления уязвимых зависимостей, больше пользователей могут получать автоматические запросы на вытягивание с обновлениями зависимостей.
- GitHub Actions авторы могут автоматически обновлять зависимости в файлах рабочих процессов.
- Разработчики Dart или Flutter, использующие Pub, могут автоматически обновлять зависимости в своих проектах.
Дополнительные сведения см. в разделе Сведения об обновлениях безопасности Dependabot.
Разработчики Dart и JavaScript на экземпляре с включенным граф зависимостей могут получать оповещения Dependabot об известных уязвимостях в зависимостях проекта.
- Для Dart граф зависимостей обнаруживает
pubspec.lock
файлы иpubspec.yaml
. - Разработчики JavaScript, использующие Node.js и npm, могут получать оповещения об известных уязвимостях в манифестах Yarn версии 2 и 3. Это дополняет существующую поддержку манифестов версии 1. Граф зависимостей обнаруживает
package.json
файлы иyarn.lock
.
Дополнительные сведения см. в следующих руководствах.
- Для Dart граф зависимостей обнаруживает
Разработчики Python, использующие поддерживаемые диспетчеры пакетов на экземпляре с включенным граф зависимостей, могут получать оповещения Dependabot о зависимостях в
pyproject.toml
файлах, которые соответствуют стандарту PEP 621. Дополнительные сведения см. в разделе Сведения об обновлениях версий Dependabot.Разработчики Python, получающие оповещения Dependabot, могут сократить количество обновлений версий, если текущая зависимость уже удовлетворяется новой версией. Чтобы настроить это поведение, используйте стратегию
increase-if-necessary
управления версиями. Дополнительные сведения см. в разделе Параметры конфигурации для файла dependabot.yml.Владельцы предприятия могут получать оповещения Dependabot для экземпляра с помощью REST API. Эта конечная точка находится в бета-версии и может быть изменена. Дополнительные сведения см. в разделе "Оповещения Dependabot" в документации по REST API.
Владельцы организации могут получать оповещения Dependabot для организации с помощью REST API. Эта конечная точка находится в бета-версии и может быть изменена. Дополнительные сведения см. в разделе "Оповещения Dependabot".
Пользователи могут программно просматривать оповещения Dependabot и работать с ними с помощью REST API. Новые конечные точки для просмотра, перечисления и обновления оповещений Dependabot доступны в бета-версии. Эти конечные точки могут быть изменены. Дополнительные сведения см. в разделе "Оповещения Dependabot" в документации по REST API.
Безопасность кода
Чтобы повысить видимость состояния безопасности и улучшить анализ рисков, пользователи могут получить доступ к сведениям о покрытии и рисках в обзоре безопасности. В представлении покрытия отображается включение в репозиториях, а в представлении рисков отображаются оповещения между репозиториями. Владельцы организации, менеджеры безопасности и администраторы репозиториев в экземпляре с лицензией на GitHub Advanced Security могут включить функции безопасности из представления охвата обзоров безопасности. Представления заменяют страницу "Обзор" и находятся в общедоступной бета-версии и могут быть изменены. Дополнительные сведения см. в статье "Общие сведения о безопасности".
Участники могут определить политику безопасности репозитория, создав
SECURITY.md
файл. Чтобы повысить видимость политики, GitHub Enterprise Server будет ссылаться на политику на вкладке кода . Дополнительные сведения см. в разделе Добавление политики безопасности в репозиторий.API проверки зависимостей является общедоступным, и связанное с ним действие GitHub теперь позволяет пользователям ссылаться на локальный или внешний файл конфигурации. Дополнительные сведения см. в следующей документации.
- "Проверка зависимостей" в документации по REST API
- Настройка проверки зависимостей
API GraphQL предоставляет доступ к граф зависимостей репозитория. Эта функция доступна в предварительной версии и может быть изменена. Дополнительные сведения см. в разделе Объекты документации по API GraphQL.
Действия GitHub
Во время настройки хранилища для GitHub Actions администраторы сайта могут избежать рисков, связанных с вводом конфиденциальных секретов и ключей доступа, используя OIDC для подключения к поставщикам хранилища объектов. GitHub Actions на GitHub Enterprise Server поддерживает OIDC для подключений к AWS, Azure и Google Cloud Platform. Эта функция находится в бета-версии и может быть изменена. Дополнительные сведения см. в разделе Включение GitHub Actions для GitHub Enterprise Server.
Чтобы предотвратить ненадежное ведение журнала данных из
set-state
команд рабочего процесса иset-output
, авторы действий могут использовать файлы среды для управления состоянием и выходными данными.- Чтобы использовать эту функцию, приложение средства выполнения тестов должно быть версии 2.297.0 или более поздней. Версии 2.298.2 и более поздние будут предупреждать пользователей, использующих
save-state
команды илиset-output
. Эти команды будут полностью отключены в будущем выпуске. - Чтобы использовать обновленные
saveState
функции иsetOutput
, рабочие процессы, использующие набор средств GitHub Actions, должны вызывать@actions/core
версию 1.10.0 или более позднюю.
Дополнительные сведения см. в разделе Команды рабочего процесса для GitHub Actions.
- Чтобы использовать эту функцию, приложение средства выполнения тестов должно быть версии 2.297.0 или более поздней. Версии 2.298.2 и более поздние будут предупреждать пользователей, использующих
Возможность совместного использования действий и повторно используемых рабочих процессов из частных репозиториев общедоступна. Пользователи могут совместно использовать рабочие процессы в частном репозитории с другими частными репозиториями, принадлежащими той же организации или учетной записи пользователя, или со всеми частными репозиториями в экземпляре . Дополнительные сведения см. в следующей документации.
- Управление параметрами GitHub Actions для репозитория
- "Разрешения GitHub Actions" в документации по REST API
Пользователи могут улучшить удобочитаемость рабочего процесса и избежать необходимости хранить не конфиденциальные данные конфигурации в виде зашифрованных секретов, определив переменные конфигурации, которые позволяют повторно использовать рабочие процессы в репозитории или организации. Эта функция находится в бета-версии и может быть изменена. Дополнительные сведения см. в разделе Переменные.
Пользователи могут динамически называть запуски рабочих процессов.
run-name
принимает выражения, а динамическое имя отображается в списке выполнений рабочих процессов. Дополнительные сведения см. в статье "Синтаксис рабочего процесса для GitHub Actions".Пользователи могут запретить выполнение задания в средстве выполнения за пределами предполагаемой группы, определив имена групп средств выполнения для рабочего процесса в
runs-on
ключе.runs-on: group: my-group labels: [ self-hosted, label-1 ]
Кроме того, GitHub Enterprise Server больше не разрешает создавать группы средств выполнения с одинаковыми именами на уровне организации и предприятия. Для всех групп средств выполнения в организации, которые совместно используют имя группы средств выполнения для предприятия, появится предупреждающий баннер.
Пользователи могут применять стандартные методики CI/CD во всех репозиториях организации, определяя необходимые рабочие процессы. Эти рабочие процессы активируются по мере необходимости проверки состояния для всех запросов на вытягивание, предназначенных для ветвь по умолчанию репозиториев, что блокирует слияние до тех пор, пока не пройдет проверка. Эта функция находится в бета-версии и может быть изменена. Дополнительные сведения см. в разделе Требуемые рабочие процессы.
Чтобы обеспечить стандартизацию конфигураций OIDC в рабочих процессах развертывания облака, владельцы организации и администраторы репозитория могут настроить
subject
формат утверждений в маркерах OIDC, определив пользовательский шаблон. Дополнительные сведения см. в статье Сведения об усилении защиты с помощью OpenID Connect.Чтобы обеспечить большую прозрачность и контроль над использованием кэша в репозиториях, пользователи, которые кэшируют зависимости и другие повторно используемые файлы,
actions/cache
могут управлять кэшем из веб-интерфейса экземпляра. Дополнительные сведения см. в разделе Кэширование зависимостей для ускорения рабочих процессов.Взаимодействие с сообществом
Пользователи могут задавать ожидания, связанные с доступностью, отображая местный часовой пояс в своих профилях. Люди, которые просматривают профиль пользователя или наверх, увидят часовой пояс, а также сколько часов назад или вперед они отстают от местного времени пользователя. Дополнительные сведения см. в разделе Персонализация профиля.
Обсуждения в GitHub
Для повышения возможности обнаружения в GitHub Discussions представлены следующие улучшения.
- Владельцы репозитория могут закреплять обсуждения в определенной категории.
- Названия и описания категорий отображаются на странице категории.
Организации
Чтобы управлять тем, как участники организации могут создавать вилки репозиториев, владельцы организации могут задать выделенную политику вилки для любой организации. Эта политика должна быть строже, чем политика вилки, заданная для предприятия. Дополнительные сведения см. в разделе Управление политикой ветвления для организации.
Владельцы организации могут повысить безопасность организации, не позволяя внешним участникам совместной работы запрашивать установку приложений GitHub и OAuth. Дополнительные сведения см. в разделе Ограничение Приложение OAuth и Приложение GitHub запросов на доступ.
Репозитории
Чтобы избежать предоставления полного административного доступа к репозиторию при необходимости, администраторы репозитория могут создать настраиваемую роль, которая позволяет пользователям обходить защиту ветви. Чтобы обеспечить защиту ветви для всех пользователей с разрешениями административного доступа или обхода, администраторы могут включить параметр Не разрешать обход указанных выше параметров. Дополнительные сведения см. в разделах Управление настраиваемыми ролями репозитория для организации и Сведения о защищенных ветвях.
Администраторы репозитория могут обеспечить безопасность и стабильность ветвей, требуя утверждения запроса на вытягивание кем-либо, кроме последнего push-сервера, или блокируя ветвь. Дополнительные сведения см. в разделе Сведения о защищенных ветвях.
В сценариях, когда кто-то должен просмотреть код в рабочем процессе GitHub Actions перед запуском рабочего процесса, администраторы репозитория могут запросить утверждение от пользователя с доступом на запись в репозиторий, прежде чем запуск рабочего процесса можно будет активировать из частной вилки. Дополнительные сведения см. в разделе Управление параметрами GitHub Actions для репозитория.
Проблемы
API GraphQL поддерживает создание и удаление связи между ветвью и проблемой. Дополнительные сведения см. в следующей документации.
- "Создание ветви для работы с проблемой"
- "createLinkedBranch" и "deleteLinkedBranch" в документации по API GraphQL "Мутации"
- "Объекты" в документации по API GraphQL
Выпуски
Пользователи могут пометить определенный выпуск в репозитории как последний с помощью пользовательского веб-интерфейса, REST API или GRAPHQL API. Дополнительные сведения см. в следующей документации.
- Управление выпусками в репозитории
- "Выпуски" в документации по REST API
- "Объекты" в документации по API GraphQL
Интеграции
Пользователи могут экономить время и реже переключать контекст, получая и выполняя действия в режиме реального времени о действиях GitHub Enterprise Server непосредственно в Slack или Microsoft Teams. Интеграция GitHub для этих служб теперь общедоступна. Дополнительные сведения см. в разделе Расширения и интеграции GitHub.
3.8.0: Changes
Когда администратор сайта выполняет команду с административным доступом по протоколу SSH, команда записывается в журнал. Чтобы помочь в устранении неполадок и отладке службы поддержки GitHub, пакеты поддержки включают журнал, содержащий эти команды.
Чтобы упростить обнаружение событий в журналах аудита предприятия, организации или пользователей, на панели поиска теперь отображается список доступных фильтров.
Прежде чем администратор сайта сможет перейти с GitHub Enterprise Server с помощью интерфейса командной строки GitHub Enterprise Importer, GRAPHQL API startRepositoryMigration или REST API запуска миграции организации, администратор должен использовать консоль управления для настройки поставщика хранилища BLOB-объектов для хранения архивов миграции. Поддерживаемые возможности включают Amazon S3 и Хранилище BLOB-объектов Azure. Ранее хранилище BLOB-объектов не требовалось и при необходимости можно было настроить с помощью
gh gei
. Это изменение добавляет поддержку миграций, когда размер источника или метаданных Git превышает 1 ГБ.Чтобы помочь пользователям экземпляра с лицензией на GitHub Advanced Security лучше понимать обнаруженные секреты и принимать меры, оповещения о проверке секретов, касающиеся сторонних ключей API, теперь содержат ссылку на документацию поставщика. Дополнительные сведения см. в статье Сведения о сканировании секретов.
Пользователи экземпляра с лицензией на GitHub Advanced Security теперь будут видеть действия, которые пользователи выполнили с оповещением о проверке секретов непосредственно в временная шкала оповещения, в том числе когда участник обошел защиту от принудительной отправки секрета.
Экземпляры с лицензией на GitHub Advanced Security будут регулярно выполнять сканирование журнала для обнаружения новых типов секретов в репозиториях с включенным GitHub Advanced Security и сканированием секретов. Ранее пользователям приходилось вручную выполнять проверку журналов.
На экземплярах с лицензией GitHub Advanced Security, чтобы гарантировать, что в будущих выпусках GitHub Enterprise Server всегда будет отображаться предварительный просмотр обнаруженного секрета в ИНТЕРФЕЙСАх API или пользовательском веб-интерфейсе, обнаруженные секреты теперь хранятся отдельно от исходного кода. Обнаруженные секреты хранятся с помощью симметричного шифрования. [Обновлено: 15.02.2023]
При использовании частных реестров для обновлений Dependabot GitHub Enterprise Server работает более безопасно. Если частный реестр настроен для любой из следующих экосистем, экземпляр больше не будет выполнять запросы пакетов к общедоступным реестрам.
- Средство увязки программ в пакеты
- Docker
- Gradle
- Maven
- npm
- Nuget
- Python
- Yarn
Дополнительные сведения см. в разделе Параметры конфигурации для файла dependabot.yml.
Разработчики Elixir, использующие локальные hex-репозитории , могут настроить частный реестр для обновления версий Dependabot на GitHub Enterprise Server. Дополнительные сведения см. в разделе Параметры конфигурации для файла dependabot.yml.
Оповещения Dependabot имеют следующие улучшения удобства использования.
- Страница оповещения обновляется автоматически после того, как Dependabot попытается создать запрос на вытягивание для обновления.
- Оповещения более точно сопоставляются с запросами на вытягивание из обновлений Dependabot.
- Чтобы улучшить оповещение для сообщества, пользователи могут предложить улучшения оповещений непосредственно в базе данных рекомендаций GitHub.
Пользователям проще упоминание @dependabot. При упоминании пользователей учетная запись пользователя Dependabot теперь отображается как предложение автозавершения.
В репозиториях с уязвимыми зависимостями Dependabot больше не будет отображать желтый баннер. Чтобы уведомить участников об уязвимых зависимостях, на вкладке Безопасность отображается счетчик оповещений.
Если пользователь вилку репозитория с существующей конфигурацией Dependabot в
dependabot.yml
, обновления Dependabot будут отключены в вилке по умолчанию. Чтобы включить обновления в вилке, пользователь должен посетить параметры безопасности и анализа кода репозитория. Дополнительные сведения см. в статье Настройка обновления версий Dependabot.Интеграторы, желающие получить веб-перехватчик для оповещений Dependabot, должны использовать новый
dependabot_alert
веб-перехватчик. Этот веб-перехватчик заменяетrepository_vulnerability_alert
веб-перехватчик. Дополнительные сведения см. в разделе События веб-перехватчика и полезные данные.Чтобы улучшить удобочитаемость рабочих процессов GitHub Actions, ссылающихся на другие действия путем фиксации SHA, авторы действий часто пишут комментарий, включая соответствующую семантику версии в строке, вызывающей действие. Чтобы сэкономить время, запросы на вытягивание для обновления версии Dependabot теперь автоматически обновляют семантику версии в этих комментариях.
Разработчики JavaScript, использующие обновления безопасности Node.js, npm и Dependabot, могут сэкономить время при обновлении проектов npm с транзитивными зависимостями.
- Dependabot может обновлять как родительские, так и дочерние зависимости вместе. Ранее Dependabot не обновлял транзитивные зависимости, когда родительскому элементу требовался несовместимый определенный диапазон версий, требуя обновления вручную.
- Dependabot может создавать запросы на вытягивание, разрешающие оповещения, в которых обновление до прямой зависимости удалит уязвимую транзитивную зависимость из дерева.
Дополнительные сведения см. в разделе Сведения об обновлениях безопасности Dependabot.
Для пользователей, использующих Dependabot для обновления версий в экосистеме Docker, Dependabot будет упреждающим образом обновлять теги образов Docker в манифестах Kubernetes. Дополнительные сведения см. в разделах Настройка обновлений версии Dependabot и Параметры конфигурации для файла dependabot.yml.
Пользователям, которые вносят свой вклад в рекомендации по безопасности в GitHub.com, доступен ряд улучшений, включая следующие изменения.
- Чтобы ускорить проверку, GitHub предлагает пользователям указать причину изменения.
- Чтобы убедиться, что вклад соответствует намерению пользователя, GitHub не будет изменять порядок ссылок в diff.
GitHub Actions включает следующие улучшения возможностей обнаружения и специальных возможностей.
- Улучшена навигация для поиска рабочих процессов и выполнений рабочих процессов.
- Добавленная структура лучше представляет иерархию между вызывающим и вызываемыми повторно используемыми рабочими процессами.
- Браузер на мобильных устройствах является более согласованным и поддерживает несколько размеров окна просмотра.
GitHub Actions рабочие процессы больше не будут запускаться бесконечно при использовании
GITHUB_TOKEN
с событиямиworkflow_dispatch
иrepository_dispatch
. До этого изменения события, активированные с помощьюGITHUB_TOKEN
, не создавали новое выполнение рабочего процесса. Дополнительные сведения см. в статье Активация рабочего процесса.Для запланированных запусков рабочих процессов GitHub Actions пользователи увидят дополнительные сведения о репозитории, организации и предприятии в полезных данных для
github.event
.Пользователи GitHub Actions лучше понять ход выполнения задания при использовании правил защиты среды. Веб-перехватчик
workflow_job
поддерживает новоеwaiting
состояние всякий раз, когда задание ожидает правила защиты среды. Кроме того, если задание ссылается наenvironment
ключ в определении YAML, полезныеworkflow_job
данные веб-перехватчика также будут содержать новое свойство ,deployment
.deployment
содержит метаданные о развертывании, созданном проверка запуска. Дополнительные сведения см. в разделе Использование сред для развертывания.Владельцы организации могут найти более значимый контекст в событиях журнала аудита.
business.sso_response
События иorg.sso_response
отображаются в REST API и полезных данных для потоковой передачи журналов аудита.repo.rename
События ,project.rename
иprotected_branch.update_name
включают текущие и прошлые имена для переименованных вold_name
поле.- События для оповещений Dependabot содержат
alert_number
поля ,ghsa_id
,dismiss_reason
иdismiss_comment
, а также ссылку на оповещение и точную метку времени.
Пользователи могут просматривать список, содержащий всех подписчиков организации, из профиля организации.
Баннер, отображаемый на вершине архивного репозитория в пользовательском веб-интерфейсе, теперь включает дату архивирования репозитория.
Вкладки Беседы и Файлы в запросах на вытягивание теперь загружаются быстрее из-за отложенного выделения синтаксиса.
Чтобы обеспечить более согласованное взаимодействие между веб-интерфейсом и рабочими станциями пользователей, а также ускорить процесс проверки возможности автоматического слияния запроса на вытягивание, GitHub Enterprise Server теперь использует
merge-ort
стратегию. Дополнительные сведения см. в статье Стратегии слияния в документации по Git.Чтобы улучшить отображение первоначального комментария в запросах на вытягивание, содержащих одну фиксацию, GitHub Enterprise Server теперь автоматически переформатирует подробные сообщения фиксации в соответствии с соглашениями Markdown GitHub.
Перед слиянием запроса на вытягивание в веб-интерфейсе отображается адрес электронной почты автора фиксации. Ранее автор фиксации отображалась только при слиянии с фиксацией слияния.
3.8.0: Known issues
На только что настроенном экземпляре GitHub Enterprise Server без пользователей злоумышленник может создать первого администратора.
Настраиваемые правила брандмауэра удаляются в процессе обновления.
Если в GitHub Connect включен параметр "Пользователи могут искать GitHub.com", проблемы в частных и внутренних репозиториях не включаются в результаты поиска GitHub.com.
Реестр npm GitHub Packages больше не возвращает значение времени в ответах метаданных. Это было сделано для существенного повышения производительности. Мы по-прежнему имеем все данные, необходимые для возврата значения времени в ответе метаданных, и возобновим возврат этого значения в будущем после устранения существующих проблем с производительностью.
Службы действий необходимо перезапустить после восстановления экземпляра из резервной копии, созданной на другом узле.
В параметрах репозитория включение параметра разрешить пользователям с доступом на чтение создавать обсуждения не включает эту функцию.
На этапе проверки запуска
No such object
конфигурации может возникнуть ошибка для служб "Записная книжка" и "Экран просмотра". Эту ошибку можно игнорировать, так как службы по-прежнему должны правильно запускаться.В некоторых случаях при преобразовании проблемы в обсуждение процесс преобразования может зависать. В этом случае владелец предприятия может выполнить следующие действия по устранению неполадок, чтобы устранить проблему.
- В конце URL-адреса застрявшего обсуждения запишите номер обсуждения.
- В пользовательском веб-интерфейсе перейдите в репозиторий, в котором зависло преобразование.
- В правом верхнем углу веб-интерфейса щелкните .
- В разделе "Совместная работа" щелкните ЧИСЛО обсуждений.
- В списке щелкните номер из шага 1.
- В разделе "Преобразование" щелкните Задание преобразования в очередь.
- Подождите несколько минут, а затем проверьте состояние проблемы.
Если преобразование по-прежнему не завершено, обратитесь за помощью в службу поддержки GitHub Enterprise .
Если администратор корневого сайта заблокирован в консоли управления после неудачных попыток входа, учетная запись не разблокируется автоматически после определенного времени блокировки. Пользователь с административным доступом по протоколу SSH к экземпляру должен разблокировать учетную запись с помощью административной оболочки. Дополнительные сведения см. в разделе Устранение неполадок с доступом к консоли управления. [Обновлено: 23.02.2023]
Во время обновления до GitHub Enterprise Server 3.8.0 в кластере после обновления узлов, отличных от основного узла MySQL, и перед обновлением основного узла MySQL следующая ошибка может появиться несколько раз после запуска
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 рекомендует дождаться обновления кластера, пока эта проблема не будет устранена. Дополнительные сведения будут доступны в заметках о выпуске для предстоящего обновления GitHub Enterprise Server.
После обновления до GitHub Enterprise Server 3.8.0 команды, выполняемые по протоколу SSH на любом из узлов экземпляра, не будут входить в
/var/log/ssh-console-audit.log
систему . Чтобы устранить эту проблему, перейдите по протоколу SSH в затронутый узел и выполните следующую команду.source /etc/bash.bashrc
На экземплярах в конфигурации
git push
с высоким уровнем доступности операции могут завершиться ошибкой в следующих ситуациях. [Обновлено: 17.03.2023]- Во время создания репозитория на узле реплики
- После сбоя при создании репозитория на узле реплики перед автоматическим восстановлением репозитория
На экземплярах в конфигурации с высоким уровнем доступности администраторы сайта должны выполнять
ghe-repl-start
команды иghe-repl-stop
только в то время, когда экземпляр находится в режиме обслуживания. Дополнительные сведения см. в разделах Включение и планирование режима обслуживания и Сведения о настройке высокого уровня доступности. [Обновлено: 17.03.2023]Использование API поиска может привести к сбою последующих запросов к другим интерфейсам. При возникновении этой проблемы затронутые пользователи API или веб-интерфейса получат ответы HTTP 5xx, и это
NoMethodError
исключение будет зарегистрировано:NoMethodError (undefined method `starts_with?' for [:ok, "refs/heads/main"]:Array):
На экземпляре с лицензией GitHub Advanced Security, где включено сканирование секретов, чрезмерное вхождение в
/var/log
систему может привести к ошибкам пользователей и снижению производительности системы, если журналы занимают все свободное место на томе. Чтобы предотвратить возникновение этой проблемы для пользователей, отслеживайте свободное место на корневом томе экземпляра. Дополнительные сведения см. в разделах Настройка проверки секретов для (модуль) и Мониторинг (модуль). Если вы подозреваете, что эта проблема затрагивает ваш экземпляр, и вам нужна помощь, обратитесь в службу поддержки GitHub. [Обновлено: 03.05.2023]
3.8.0: Deprecations
Небезопасные алгоритмы, отключенные для административных подключений SSH
GitHub отключил использование незащищенных алгоритмов для SSH-подключений к административной оболочке.
Прекращение поддержки веб-перехватчика repository_vulnerability_alert
Для интеграторов, которые хотят получать веб-перехватчики для действий оповещений
dependabot_alert
Dependabot, веб-перехватчик заменяетrepository_vulnerability_alert
веб-перехватчик. Дополнительные сведения см. в разделе События веб-перехватчика и полезные данные.