Enterprise Server 3.5 release notes

In the Management Console's monitor dashboard, the Cached Requests and Served Requests graphs, which are retrieved by the git fetch catching command, did not display metrics for the instance.

After a site administrator exempted the @github-actions[bot] user from rate limiting by using the ghe-config app.github.rate-limiting-exempt-users "github-actions[bot]" command, running ghe-config-check caused a Validation is-valid-characterset failed warning to appear.

GitHub Actions (actions) and Microsoft SQL (mssql) did not appear in the list of processes within the instances monitor dashboard.

After an administrator used the /setup/api/start REST API endpoint to upload a license, the configuration run failed with a Connection refused error during the migrations phase.

On an instance in a high availability configuration, if an administrator tore down replication from a replica node using ghe-repl-teardown immediately after running ghe-repl-setup, but before ghe-repl-start, an error indicated that the script cannot launch /usr/local/bin/ghe-single-config-apply - run is locked. ghe-repl-teardown now displays an informational alert and continues the teardown.

On an instance in a cluster configuration, when a site administrator set maintenance mode using ghe-maintenance -s, a Permission denied error appeared when the utility tried to access /data/user/common/cluster.conf.

During configuration of high availability, if a site administrator interrupted the ghe-repl-start utility, the utility erroneously reported that replication was configured, and the instance would not perform expected clean-up operations.

When a site administrator used ghe-migrator to migrate data to GitHub Enterprise Server, in some cases, nested team relationships would not persist after teams were imported.

If a repository contained a CODEOWNERS file, pull requests in the repository intermittently failed to display the files validity or updated code owner information, requiring the user to reload the page.

The CSV reports for all users and all active users, available from the site admin dashboard, did not consider recent access using SSH or personal access tokens.

On an instance with GitHub Connect enabled, if "Users can search GitHub.com" was enabled, users would not see issues in private and internal repositories in search results for GitHub.com.

GitHub Enterprise Server published distribution metrics that cannot be processed by collectd. The metrics included pre_receive.lfsintegrity.dist.referenced_oids, pre_receive.lfsintegrity.dist.unknown_oids, and git.hooks.runtime.

After an enterprise owner enables Dependabot updates, the instance creates the initial set of updates faster.

On an instance in a cluster configuration, when a site administrator sets maintenance mode on a single cluster node using ghe-maintenance -s, the utility warns the administrator to use ghe-cluster-maintenance -s to set maintenance mode on all of the clusters nodes. For more information, see "Включение и планирование режима обслуживания."

When a site administrator configures an outbound web proxy server for GitHub Enterprise Server, the instance now validates top-level domains (TLDs) excluded from the proxy configuration. By default, you can exclude public TLDs that the IANA specifies. Site administrators can specify a list of unregistered TLDs to exclude using ghe-config. The . prefix is required for any public TLDs. For example, .example.com is valid, but example.com is invalid. For more information, see "Настройка сервера веб-прокси исходящего трафика."

To avoid intermittent issues with the success of Git operations on an instance with multiple nodes, GitHub Enterprise Server checks the status of the MySQL container before attempting a SQL query. The timeout duration has also been reduced.

The default path for output from ghe-saml-mapping-csv -d is /data/user/tmp instead of /tmp. For more information, see "Служебные программы командной строки."

При просмотре списка открытых сеансов для устройств, вошедшего в учетную запись пользователя, в пользовательском веб-интерфейсе GitHub Enterprise Server может отображаться неправильное расположение.

В редких случаях, когда первичные сегменты для Elasticsearch были расположены на узле реплики, команда завершается ошибкой ghe-repl-stop с ERROR: Running migrations.

ВЫСОКОЙ: Обновлен Git для включения исправлений с версии 2.39.2, которая относится к CVE-2023-22490 и CVE-2023-23946.

Пакеты обновлены до последних версий безопасности.

При использовании URL-адреса конечной точки VPC в качестве URL-адреса AWS S3 для пакетов GitHub публикация и установка пакетов завершилась сбоем.

MEDIUM: в GitHub Enterprise Server была обнаружена уязвимость внедрения кода, которая позволяла задавать произвольные переменные среды из одного значения переменной среды в GitHub Actions при использовании средства выполнения на основе Windows из-за неправильной очистки null байтов. Чтобы воспользоваться этой уязвимостью, злоумышленнику потребуется существующее разрешение на управление значением переменных среды для использования с GitHub Actions. Об этой уязвимости сообщили в программе bounty для ошибок GitHub и назначили CVE-2023-22381.

Пакеты обновлены до последних версий безопасности.

На этапе проверки запуска No such object error конфигурации для служб "Записная книжка" и "Экран просмотра" может возникнуть исключение .

При включении автоматического управления сертификатами TLS с помощью Let's Encrypt процесс может завершиться ошибкой The certificate is not signed by a trusted certificate authority (CA) or the certificate chain in missing intermediate CA signing certificates.

При истечении времени ожидания во время создания диффа, например при фиксации отображается ошибка, которая занимает слишком много времени, push событие веб-перехватчика доставляет пустые сведения о различиях. Ранее push событие веб-перехватчика не было доставлено.

HIGH: обновлен Git для включения исправлений с версии 2.39.1, которая относится к CVE-2022-41903 и CVE-2022-23521.

Очистка дополнительных секретов в пакетах поддержки и журнале конфигурации.

Зависимости для действия CodeQL обновлены до последних версий безопасности.

Пакеты обновлены до последних версий безопасности.

Метрики Active workers и Queued requests для github служб контейнеров (переименованных из метаданных), gitauthи unicorn служб контейнеров неправильно считывались из собранных и отображались в консоли управления.

Сообщения с оповещениями Dependabot будут отправляться в отключенные репозитории.

Репозитории, заблокированные для миграции, позволят редактировать файлы в пользовательском веб-интерфейсе.

При просмотре различий в запросах на вытягивание для большого файла с большим количеством строк между изменениями невозможно было развернуть представление для отображения всех изменений.

Команде git-janitorне удалось исправить устаревшие multi-pack-index.lock файлы, что привело к сбою обслуживания репозитория.

Команды ghe-support-bundle и ghe-cluster-support-bundle были обновлены, чтобы включить -p/--period флаг для создания пакета поддержки с ограниченным временем. Длительность может быть указана в днях и часах, например , -p '2 hours'``-p '1 day', -p '2 days 5 hours'.

Повышена производительность запусков конфигурации, запущенных с ghe-config-apply помощью .

При обновлении экземпляра с новым корневым разделом выполнение ghe-upgrade команды с параметром -t/--target гарантирует выполнение предварительной проверки минимального размера дискового хранилища для целевого раздела.

При экспорте данных учетной записи, резервном копировании репозитория или выполнении миграции ссылка на архив репозитория теперь истекает через 1 час. Ранее срок действия ссылки на архив истек через 5 минут.

ВЫСОКИЙ УРОВЕНЬ. В GitHub Enterprise Server была обнаружена уязвимость обхода пути, которая позволяла удаленно выполнять код при создании сайта GitHub Pages. Чтобы воспользоваться этой уязвимостью, злоумышленнику потребуется разрешение на создание и создание сайта GitHub Pages в экземпляре . Об этой уязвимости сообщили в программе GitHub Побоям за ошибки и назначили CVE-2022-46256.

ВЫСОКИЙ УРОВЕНЬ. Неправильная уязвимость авторизации позволила маркеру от пользователя к серверу перейти к полному административному доступу к репозиторию. Злоумышленнику потребуется учетная запись с правами администратора для установки вредоносного приложения GitHub. Эта уязвимость затронула все версии GitHub Enterprise Server до 3.7.0. Об этой уязвимости сообщили через программу GitHub Bug Bounty и назначили CVE-2022-23741.

MEDIUM: в GitHub Enterprise Server обнаружена уязвимость раскрытия информации, которая позволяла добавлять частные репозитории в группу средств выполнения GitHub Actions через API пользователем, у которого не было доступа к этим репозиториям, в результате чего имена репозиториев отображаются в пользовательском интерфейсе. Чтобы воспользоваться этой уязвимостью, злоумышленнику потребуется доступ к экземпляру GHES, разрешения на изменение GitHub Actions групп средств выполнения и успешное угадывание замаскированного идентификатора частных репозиториев. Об этой уязвимости сообщили в программе bounty на GitHub и назначили CVE-2022-46257.

Если зависимость GitHub Actions использует закрепленную версию SHA, Dependabot больше не будет помечать зависимость как уязвимую.

Когда администратор сайта выполнял ghe-repl-sync-ca-certificates команду из первичного узла экземпляров через административную оболочку (SSH), эта команда реплицировала сертификаты ЦС только из первичного узла экземпляров в один узел реплики. Команда не реплицировала сертификаты на все доступные узлы реплики.

Установка GitHub Enterprise Server на низкоуровневой оболочке VMware ESXi завершилась сбоем из-за создания OVA-файла с недопустимым значением емкости.

Когда пользователи выполняют операцию с помощью API, GitHub Enterprise Server принудительно применяет квоты на размер репозитория, даже если они отключены глобально.

Событие member веб-перехватчика не включало from значения полей и to для permission поля как changes части поля.

После удаления учетной записи пользователя из экземпляра вложения изображений, отправленные пользователем в комментариях, больше не отображались в веб-интерфейсе.

В некоторых случаях страница настройки сканирования кода ошибочно сообщает, что GitHub Actions не настроен для экземпляра.

Если пользователь загрузил несколько файлов при создании нового Gist, пользователь не может удалить файлы, отправленные после первого.

В системном журнале появилось сообщение на уровне отладки, которое может быстро потреблять место на корневом томе хранилища экземпляра.

MEDIUM: обновлен CommonMarker для решения сценария, в котором параллельные запросы к REST API Markdown могут привести к неограниченному исчерпанию ресурсов. Эта уязвимость была назначена CVE-2022-39209.

MEDIUM. Маркеры пользователя на сервере с заданной областью из приложений GitHub могут обходить проверки авторизации в запросах API GraphQL при доступе к ресурсам, не относящихся к репозиторию. Эта уязвимость была обнаружена в рамках программы GitHub bug Bounty Program и назначена CVE-2022-23739.

MEDIUM: ссылки предварительного просмотра запросов на вытягивание неправильно очищают URL-адреса, что позволяет злоумышленнику внедрять опасные ссылки в веб-интерфейс экземпляров. Об этой уязвимости сообщили в программе GitHub Bug Bounty.

MEDIUM: в GitHub Enterprise Server обнаружена неправильная уязвимость авторизации, которая позволяла маркеру уровня репозитория с доступом на чтение и запись изменять GitHub Actions файлы рабочего процесса без области рабочего процесса. AutoTITLE должен применять область рабочего процесса. Эта уязвимость была обнаружена в программе GitHub Bug Bounty и назначена CVE-2022-46258.

Установка режима обслуживания со списком исключений IP-адресов не будет сохраняться при обновлениях.

Для сборок GitHub Pages может быть истекло время ожидания для экземпляров в AWS, настроенных для обеспечения высокого уровня доступности.

После настройки Dependabot и дайджестов оповещений экземпляр будет отправлять хэш-письма приостановленным пользователям.

Метка времени журнала аудита для событий оповещений Dependabot вернула дату создания оповещения, а не метку времени, когда пользователь выполнил действие с оповещением.

При доступе к ресурсам JavaScript экземпляров из-за прокси-сервера в браузере отображаются ошибки общего доступа к ресурсам независимо от источника (CORS).

Если пользователь назвал проверку состояния с начальными или конечными пробелами, экземпляр создает повторную проверку, если существует другая проверка с тем же именем и без начальных или конечных пробелов.

Если пользователь настроит перехватчик предварительного получения для нескольких репозиториев, на странице перехватчиков экземпляров не всегда отображается правильное состояние перехватчика.

Когда владелец предприятия олицетворяет пользователя и пытается установить приложение GitHub, кнопка подтверждения того, что установка отключена и не может быть нажата.

После выполнения миграций для GitHub Enterprise Importer на экземпляре, настроенном для обеспечения высокой доступности, репликация ресурсов хранилища миграции не будет наверстать упущенное.

Зомби-процессы больше не накапливаются в контейнере gitrpcd .

HIGH: обновлены зависимости для консоли управления до последних версий исправлений, которые устраняет уязвимости системы безопасности, включая CVE-2022-30123 и CVE-2022-29181.

HIGH: добавлены проверки для устранения неправильной уязвимости ключа кэша, которая позволяла неавторизованному субъекту получать доступ к файлам частного репозитория через общедоступный репозиторий. Эта уязвимость была назначена CVE-2022-23738.

MEDIUM: обновлен CommonMarker для решения сценария, в котором параллельные запросы к REST API Markdown могут привести к неограниченному исчерпанию ресурсов. Эта уязвимость была назначена CVE-2022-39209.

MEDIUM: обновлен Redis до версии 5.0.14, чтобы обратиться к CVE-2021-32672 и CVE-2021-32762.

MEDIUM: обновлены средства выполнения GitHub Actions, чтобы исправить ошибку, которая позволяла переменным среды в GitHub Actions заданиях экранировать контекст переменной docker и напрямую изменять вызов команд. Дополнительные сведения см. в разделе Советы по безопасности средства выполнения действий.

MEDIUM: в GitHub Enterprise Server обнаружена уязвимость неправильного управления привилегиями, которая позволяла пользователям с неправильными привилегиями создавать или удалять страницы с помощью API. Чтобы воспользоваться этой уязвимостью, необходимо добавить злоумышленника в репозиторий организации с разрешениями на запись. Об этой уязвимости сообщили в программе GitHub Bug Bounty и назначили CVE-2022-23737.

LOW: из-за уязвимости CSRF запрос к конечной GET точке экземпляра site/toggle_site_admin_and_employee_status может неосознанно переключить состояние администратора сайта пользователя.

Пакеты обновлены до последних версий системы безопасности.

После того как администратор сайта внес изменение, которое активировало запуск конфигурации, например отключение GitHub Actions, проверка служб иногда завершалась ошибкой с сообщением WARNING: Validation encountered a problem.

После того как администратор сайта установил горячее исправление, содержащее изменения в ресурсах веб-интерфейса, таких как файлы Или изображения JavaScript, экземпляр не обслуживал новые ресурсы.

Когда пользователь обращается к переименованному репозиторию с помощью Git, имя узла в выходных данных Git неправильно указано GitHub.com вместо имени узла экземпляра.

На экземплярах, использующих проверку подлинности LDAP и синхронизацию LDAP, синхронизация завершится ошибкой и печать undefined method ord for nil:NilClass в ldap-sync.log.

Устранена ошибка, из-за которой конечная точка для создания состояния защиты тегов для репозитория возвращала ошибку 500.

Очистка удаленных ресурсов и ресурсов, запланированных для очистки в репозитории, таких как файлы LFS, занимает слишком много времени.

Если пользователь установил приложение GitHub для учетной записи пользователя, а затем преобразовал учетную запись в организацию, приложению не были предоставлены разрешения организации.

Отсутствующие оповещения о проверке секретов для экземпляра с лицензией GitHub Advanced Security, которая не была обновлена непосредственно до GitHub Enterprise Server 3.4, теперь отображаются в веб-интерфейсе и через REST API.

В некоторых случаях в экземпляре с лицензией на GitHub Advanced Security оповещения о проверке секретов не включают тип поставщика и вместо этого указывают на то, что тип поставщика является "неизвестным".

Чтобы администраторы сайта могли успешно завершить обновление, экземпляр теперь выполнит предварительную проверку, чтобы убедиться, что виртуальная машина соответствует минимальным требованиям к оборудованию. Проверка также проверяет работоспособность Elasticsearch. Текущие требования к ЦП, памяти и хранилищу для GitHub Enterprise Server можно просмотреть в разделе "Минимальные требования" в каждой статье статьи AUTOTITLE.

Архивы репозитория для миграций теперь содержат is_archived поле.

HIGH. Приложение GitHub может использовать маркер от пользователя к серверу с заданной областью для обхода логики авторизации пользователей и эскалации привилегий.

MEDIUM. Использование символа переопределения справа налево в Юникоде в списке доступных файлов для приложения GitHub может скрыть дополнительные файлы, к которым приложение может получить доступ.

LOW: предоставление пользователю возможности обхода защиты ветви больше не позволяет пользователю обходить требование проверки подписи.

Пакеты обновлены до последних версий безопасности.

Установка сертификата TLS завершилась сбоем, если строка субъекта сертификата содержала символы UTF-8.

Выполнение конфигурации может завершиться сбоем, если retry-limit или retry-sleep-duration были заданы администратором вручную с помощью ghe-config.

Команда ghe-find-insecure-git-operations не возвращала все небезопасные операции Git после каждого вызова.

В некоторых случаях панель мониторинга консоли управления загружается неправильно.

Удалена нефункциональная ссылка для экспорта графов монитора консоли управления в виде изображения PNG.

При отправке пакета поддержки в службу поддержки GitHub Enterprise с помощью ghe-support-upload``-t параметра не удалось связать отправленный пакет с указанным запросом.

В редких случаях обновление GitHub Enterprise Server 3.3 до версии 3.4 неправильно изменяет способ хранения данных, что приводит к сбоям во время будущих обновлений. При обновлении непосредственно до этого выпуска с версии 3.3 сбой не произойдет.

При использовании URL-адреса конечной точки VPC в качестве URL-адреса AWS S3 для пакетов GitHub публикация и установка пакетов завершилась сбоем.

Клоны или выборки Git по протоколу SSH могут привести к повреждению данных при передаче размером более 1 ГБ.

Ссылка на параметры безопасности для корпоративной учетной записи экземпляра может отобразить неправильное представление.

После удаления или восстановления пользователем пакетов из веб-интерфейса счетчики пакетов могут отображаться неправильно.

После успешной настройки Dependabot и дайджестов оповещений экземпляр не будет отправлять хэш-сообщения.

После обновления до GitHub Enterprise Server 3.5 в репозиториях будут отсутствовать выпуски. Это произошло, когда необходимые миграции индекса Elasticsearch не были успешно завершены. Пользовательский интерфейс выпусков теперь указывает, ожидает ли он завершения миграции индекса Elasticsearch, а также ссылки на документацию по отслеживанию состояния и немедленному завершению миграции.

Вручную отключенные GitHub Actions рабочие процессы в репозитории были повторно включены, если репозиторий получил отправку, содержащую более 2048 фиксаций, или если ветвь репозитория по умолчанию изменилась.

При просмотре различий запроса на вытягивание для большого файла с большим количеством строк между изменениями невозможно было развернуть представление для отображения всех изменений.

Если защита ветвей была включенаGITHUB_REF_PROTECTED, переменная среды и github.ref_protected контексты для GitHub Actions выполнения рабочих процессов были неправильно заданы как false.

В экземплярах, использующих GitHub Advanced Security, при проверке секретов автоматически отзываются личные маркеры доступа, добавленные в общедоступные репозитории.

Репозитории для пакетов ошибочно отображали раздел "Используется".

После разблокировки репозитория для временного доступа администратор сайта не смог управлять параметрами для продуктов безопасности в репозитории.

Повторяющиеся административные ключи SSH могут отображаться как в консоли управления, так и в /home/admin/.ssh/authorized_keys файле.

Страница администрирования сайта для отдельных пользователей в http(s)://HOSTNAME/stafftools/users/USERNAME/admin автономной функциональности, не предназначенной для GitHub Enterprise Server.

В некоторых случаях выполнение ghe-cluster-config-apply может реплицировать пустую конфигурацию на существующие узлы в кластере.

В некоторых случаях запуски конфигурации, запущенные с ghe-config-apply , не завершены или возвращали ошибку Container count mismatch .

После обновления самозаверяющего сертификата TLS на экземпляре GitHub Enterprise Server элементы пользовательского интерфейса на некоторых страницах веб-интерфейса не отображались.

Панель администрирования сайта в верхней части веб-интерфейса содержит неработающую ссылку на SHA для текущей версии приложения.

В некоторых случаях фоновые задачи могут зависать из-за библиотеки, которая использовалась одновременно, несмотря на то, что она не является потокобезопасной.

Оповещения о проверке секретов для клиентов GitHub Advanced Security отсутствовали в веб-интерфейсе и REST API, если администратор сайта не обновлялся непосредственно до GitHub Enterprise Server 3.4. Оповещения теперь видны.

Когда пользователь вилку репозитория в организацию, длинный список организаций не будет отображаться должным образом.

Создание пакетов поддержки выполняется быстрее в результате параллельной очистки журналов. Дополнительные сведения о пакетах поддержки см. в разделе Предоставление данных для службы поддержки GitHub.

API- интерфейсы, содержащие organization маршрут или org , теперь принимают либо идентификатор организации. Ранее API принимали только slugs, что приводило Link к недоступности заголовков для конечных точек GitHub Advanced Security. Дополнительные сведения см. в разделе "Организации" в документации по REST API.

Журнал аудита предприятия теперь содержит больше событий, созданных пользователем, таких как project.create. REST API также возвращает дополнительные события, созданные пользователем, например repo.create. Дополнительные сведения см. в разделах Доступ к журналу аудита для предприятия и Использование API журнала аудита для предприятия.

В некоторых случаях реплики кэша могут отклонять некоторые операции Git в недавно обновленных репозиториях. Дополнительные сведения о кэшировании репозитория см. в разделе Сведения о кэшировании репозитория.

КРИТИЧЕСКОЕ. Контейнер Elasticsearch GitHub Enterprise Server использовал версию OpenJDK 8, которая была уязвима к проблеме усечения целых чисел при обработке вредоносных таблиц стилей XSLT. Уязвимость отслеживается как CVE-2022-34169.

ВЫСОКИЙ УРОВЕНЬ. Ранее установленные приложения в учетных записях пользователей автоматически получали разрешение на доступ к организации с помощью маркеров доступа с заданной областью после преобразования учетной записи пользователя в учетную запись организации. Об этой уязвимости сообщили в программе GitHub Bug Bounty.

В некоторых случаях экземпляры GitHub Enterprise Server в AWS, которые использовали этот тип экземпляра r4.4xlarge , не загружались.

В некоторых случаях элементы пользовательского интерфейса на вкладке "Измененные файлы" запроса на вытягивание могут перекрываться.

Если для экземпляра было задано пользовательское пороговое значение неактивности, приостановка всех неактивных пользователей не позволяла надежно соблюдать пороговое значение. Дополнительные сведения о бездейство см. в разделе Управление неактивными пользователями.

При расчете фиксаций для GitHub Advanced Security невозможно было указать отдельные репозитории. Дополнительные сведения см. в разделе Панель мониторинга администратора сайта.

В некоторых случаях процесс после обновления es:upgrade Elasticsearch может завершиться сбоем.

Скрипту миграции во внутренние репозитории не удалось преобразовать видимость для общедоступных репозиториев во внутренние или частные. Дополнительные сведения о миграции см. в разделе Переход на внутренние репозитории.

Обнаружение GitHub Actions файлов рабочего процесса для графа зависимостей было недоступно в GitHub Enterprise Server 3.5.0, 3.5.1, 3.5.2 и 3.5.3, но теперь доступно в версии 3.5.4. Дополнительные сведения см. в разделе Сведения о графе зависимостей.

Возможность повторного открытия оповещений Dependabot была недоступна в GitHub Enterprise Server 3.5.0, 3.5.1, 3.5.2 и 3.5.3, но теперь доступна в версии 3.5.4. Дополнительные сведения см. в разделе Просмотр и обновление оповещений Dependabot.

Возможность всегда предлагать обновления из базовой ветви в head запроса на вытягивание была недоступна в GitHub Enterprise Server 3.5.0, 3.5.1, 3.5.2 и 3.5.3, но теперь доступна в версии 3.5.4. Дополнительные сведения см. в разделе Управление предложениями по обновлению ветвей запросов на вытягивание.

Светлая тема с высокой контрастностью была недоступна в GitHub Enterprise Server 3.5.0, 3.5.1, 3.5.2 и 3.5.3, но теперь доступна в версии 3.5.4. Дополнительные сведения см. в разделе Управление параметрами темы.

pre_receive_hook.rejected_push События не отображались в корпоративном журнале аудита.

MEDIUM: предотвращает атаку, в которой подделка запросов на стороне сервера (SSRF) потенциально может заставить мост Subversion (SVN) выполнить удаленный код путем внедрения произвольных данных в Memcached.

MEDIUM: предотвращает выполнение кода JavaScript злоумышленником путем использования уязвимости межсайтовых сценариев (XSS) в раскрывающихся элементах пользовательского интерфейса в веб-интерфейсе GitHub Enterprise Server.

Обновления Grafana до версии 7.5.16, которая устраняет различные уязвимости системы безопасности, включая CVE-2020-13379 и CVE-2022-21702.

Пакеты обновлены до последних версий системы безопасности.

MEDIUM: в GitHub Enterprise Server обнаружена хранимая уязвимость XSS, которая позволяла впрысить произвольные атрибуты. Это внедрение было заблокировано политикой безопасности содержимого (CSP) Github. Эта уязвимость была обнаружена в программе GitHub Bug Bounty и назначена CVE-2022-23733. [Обновлено: 31.07.2022]

MEDIUM: в GitHub Enterprise Server обнаружена уязвимость, связанная с десериализацией недоверенных данных, которая потенциально может привести к удаленному выполнению кода на мосте Subversion (SVN). Чтобы воспользоваться этой уязвимостью, злоумышленнику потребуется получить доступ через подделку запросов на стороне сервера (SSRF), которая позволит злоумышленнику контролировать десериализацию данных. Эта уязвимость была обнаружена в программе GitHub Bug Bounty и назначена CVE-2022-23734.

В некоторых случаях собранная управляющая программа может потреблять избыток памяти.

В некоторых случаях резервные копии сменяемых файлов журналов могут накапливаться и потреблять избыточное хранилище.

После обновления до нового выпуска компонентов и последующего запуска конфигурации Elasticsearch может регистрировать чрезмерные исключения при перестроении индексов.

В некоторых случаях, когда защищенная ветвь требует более одной проверки утверждения, запрос на вытягивание может быть объединен с меньшим, чем необходимое количество проверок утверждения.

GitHub Enterprise Importer неправильно перенес параметры для проектов в репозиториях.

В экземплярах, использующих проверку подлинности LDAP, запрос проверки подлинности для режима sudo по умолчанию неправильно помещает курсор в поле пароля, когда были видны текстовые поля для имени пользователя и пароля.

Панель мониторинга администратора сайта ошибочно включила возможность экспорта отчета со списком неактивных пользователей.

Конечная точка AUTOTITLE API выставления счетов теперь возвращает Link заголовки для предоставления сведений о разбиении на страницы.

Теперь конечная точка "AUTOTITLE" API выставления счетов возвращает правильное количество всех фиксаций.

На боковой панели параметров организации элемент навигации Архив не содержит дочерних элементов.

Теперь поддерживается гипервизор VMware vSphere ESXi версии 7.0. [Обновлено: 07.09.2022]

Служебная ghe-set-password программа командной строки автоматически запускает необходимые службы при загрузке экземпляра в режиме восстановления.

Метрики для aqueduct фоновых процессов собираются для перенаправления сборных данных и отображаются в консоли управления.

Расположение журнала /data/user/common/ghe-config.logвыполнения миграции базы данных и конфигурации теперь отображается на странице с подробными сведениями о ходе миграции.

MEDIUM: предотвращает атаку, при которой org можно указать параметр строки запроса для URL-адреса сервера GitHub Enterprise Server, который затем предоставляет доступ к активным фиксациям другой организации.

MEDIUM: гарантирует, что github.company.com и github-company.com не оцениваются внутренними службами как идентичные имена узлов, предотвращая потенциальную атаку с подделкой безопасности на стороне сервера (SSRF).

НИЗКИЙ. Злоумышленник может получить доступ к консоли управления с путем обхода атаки по протоколу HTTP, даже если внешние правила брандмауэра блокируют доступ по протоколу HTTP.

Пакеты обновлены до последних версий системы безопасности.

Файлы в архиве артефактов не удалось открыть после распаковки из-за ограничений разрешений.

В некоторых случаях пакеты, отправленные в реестр контейнеров, не были видны в пользовательском веб-интерфейсе GitHub Enterprise Server.

Консоль управления зависла на начальном экране после обновления недостаточно подготовленного экземпляра до GitHub Enterprise Server 3.5.

Время ожидания Redis больше не останавливает миграцию базы данных во время выполнения ghe-config-apply.

Обработчики фоновых заданий будут зависать в состоянии частичного завершения работы, в результате чего некоторые типы фоновых заданий (например, сканирование кода) зависают.

В некоторых случаях администраторы сайта не добавляются автоматически в качестве владельцев предприятия.

Рабочие процессы действий, вызывающие другие повторно используемые рабочие процессы, не выполнялись по расписанию.

Разрешение действий с помощью GitHub Connect ненадолго завершилось сбоем после изменения видимости репозитория с общедоступной на внутреннюю.

Повышена производительность Dependabot Обновления при первом включении.

Увеличьте максимальное количество одновременных подключений для средств выполнения действий для поддержки целевого объекта производительности GHES.

Время ожидания сборки и синхронизации GitHub Pages теперь можно настроить в консоли управления.

Добавлена переменная среды для настройки времени ожидания Redis.

Создание или обновление проверок или наборов проверок может возвращать, 500 Internal Server Error если значение для определенных полей, например имя, было слишком длинным.

Повышает производительность на вкладке "Измененные файлы" запросов на вытягивание, если различия включают много изменений.

Политика использования кэша репозитория actions больше не принимает максимальное значение меньше 1 для max_repo_cache_size_limit_in_gb.

При развертывании узлов сервера кэша теперь необходимо описать топологию центра обработки данных (с помощью аргумента --datacenter ) для каждого узла в системе. Это требование позволяет предотвратить ситуации, когда если оставить членство в центре обработки данных по умолчанию, рабочие нагрузки будут неправильно сбалансированы между несколькими центрами обработки данных.

Теперь поддерживается гипервизор VMware vSphere ESXi версии 7.0. [Обновлено: 07.09.2022]

Пакеты обновлены до последних версий безопасности.

Внутренний скрипт для проверки имен узлов в файле конфигурации GitHub Enterprise Server вернет ошибку, если строка имени узла начинается с "." (символ точки).

В конфигурациях с высоким уровнем доступности, где имя узла основного узла превышает 60 символов, MySQL не будет настроен.

Если GitHub Actions включен, но протокол TLS отключен в GitHub Enterprise Server 3.4.1 и более поздних версиях, применение обновления конфигурации завершится ошибкой.

Аргумент --gateway был добавлен в ghe-setup-network команду , чтобы разрешить передачу адреса шлюза при настройке параметров сети с помощью командной строки.

Конечные точки API выставления счетов GitHub Advanced Security не были включены и недоступны.

Удаленные вложения изображений будут возвращать 500 Internal Server Error вместо 404 Not Found ошибки.

В средах, настроенных с сервером кэша репозитория ghe-repl-status , команда неправильно показала, что gists недостаточно реплицирована.

Конечные точки "Получить фиксацию" и "Сравнить две фиксации" в API фиксации возвращают ошибку 500 , если путь к файлу в диффе содержит закодированный и экранированный символ Юникода.

Вычисление максимального числа фиксаций во всем экземпляре, сообщаемое на панели мониторинга администрирования сайта, было неправильным.

Неправильная запись базы данных для реплик репозитория вызвала повреждение базы данных при восстановлении с помощью GitHub Enterprise Server Backup Utilities.

GitHub App не сможет подписаться на secret_scanning_alert_location событие веб-перехватчика при установке.

Временная шкала действий для оповещений о проверке секретов не отображалась.

Удаленные репозитории не были удалены через 90 дней.

Оптимизировано включение метрик при создании пакета поддержки кластера.

В конфигурациях с высоким уровнем доступности, в которых Elasticsearch сообщала о допустимом желтом состоянии, изменения, внесенные в предыдущее исправление, блокировали ghe-repl-stop команду и не позволяли останавливать репликацию. Теперь использование ghe-repo-stop --force приведет к остановке Elasticsearch, если служба находится в нормальном или допустимом желтом состоянии.

Теперь поддерживается гипервизор VMware vSphere ESXi версии 7.0. [Обновлено: 07.09.2022]

Теперь можно настроить список разрешенных IP-адресов, которые могут получать доступ к службам приложений на экземпляре GitHub Enterprise Server при включенном режиме обслуживания. Администраторы, которые посещают веб-интерфейс экземпляра с разрешенного IP-адреса, могут проверить функциональность экземпляра после обслуживания и перед отключением режима обслуживания. Дополнительные сведения см. в разделе Включение и планирование режима обслуживания.

Благодаря пользовательским ролям репозитория организации теперь имеют более детализированный контроль над разрешениями на доступ к репозиторию, которые они могут предоставлять пользователям. Дополнительные сведения см. в разделе Управление ролями репозитория для организации.

Пользовательская роль репозитория создается владельцем организации и доступна во всех репозиториях в этой организации. Каждой роли можно присвоить пользовательское имя и описание. Его можно настроить с помощью набора более 40 детализированных разрешений. После создания администраторы репозитория могут назначить настраиваемую роль любому пользователю, команде или внешнему участнику совместной работы в своем репозитории.

Настраиваемые роли репозитория можно создавать, просматривать, изменять и удалять с помощью новой вкладки Роли репозитория в параметрах организации. В организации можно создать не более трех настраиваемых ролей.

Настраиваемые роли репозитория также полностью поддерживаются в REST API GitHub Enterprise Server. API организаций можно использовать для перечисления всех настраиваемых ролей репозитория в организации, а существующие API для предоставления доступа к репозиторию отдельным лицам и командам были расширены для поддержки пользовательских ролей репозитория. Дополнительные сведения см. в разделе "Организации" в документации по REST API.

Реестр контейнеров GitHub (GHCR) теперь доступен в GitHub Enterprise Server 3.5 в общедоступной бета-версии, предоставляя разработчикам возможность публиковать, скачивать контейнеры и управлять ими. Поддержка контейнеров GitHub Packages реализует стандарты OCI для размещения образов Docker. Дополнительные сведения см. в разделе Реестр контейнеров GitHub.

Версия Dependabot и обновления для системы безопасности теперь общедоступны в GitHub Enterprise Server 3.5. Все популярные экосистемы и функции, работающие с GitHub.com репозиториями, теперь можно настроить в экземпляре GitHub Enterprise Server. Для dependabot на GitHub Enterprise Server требуется GitHub Actions и пул локальных средств выполнения Dependabot, включен GitHub Connect и Dependabot, включенный администратором. Дополнительные сведения см. в разделе Настройка обновлений Dependabot.

Теперь вы можете проанализировать, как работает ваша команда, понять ценность GitHub Enterprise Server и помочь нам улучшить наши продукты, просмотрев данные об использовании вашего экземпляра и поделившись сводные данные с GitHub. Вы можете использовать собственные средства для анализа использования с течением времени, скачав данные в CSV- или JSON-файле или используя доступ к ним с помощью REST API. Список собранных статистических метрик см. в разделе Сведения о статистике сервера. Данные статистики сервера не содержат ни персональных данных, ни содержимого GitHub, такого как код, проблемы, комментарии или содержимое запросов на вытягивание. Чтобы лучше понять, как мы храним и защитим данные статистики сервера, см. раздел GitHub Security. Дополнительные сведения о статистике сервера см. в разделе Анализ того, как ваша команда работает со статистикой сервера. Эта функция доступна в общедоступной бета-версии.

Администраторы сайта теперь могут включать и настраивать ограничение скорости для GitHub Actions. По умолчанию ограничение скорости отключено. Если задания рабочего процесса не могут быть немедленно назначены доступному средству выполнения, они будут ожидать в очереди, пока средство выполнения не станет доступным. Однако если GitHub Actions испытывает устойчивую высокую нагрузку, очередь может выполнять резервное копирование быстрее, чем может истощиться, а производительность экземпляра GitHub Enterprise Server может снизиться. Чтобы избежать этого, администратор может настроить ограничение скорости. При превышении ограничения скорости выполнение дополнительных рабочих процессов немедленно завершается ошибкой, а не помещается в очередь. Когда скорость стабилизируется ниже порогового значения, новые запуски можно снова поместить в очередь. Дополнительные сведения см. в статье Настройка ограничений скорости.

GitHub Actions на GitHub Enterprise Server теперь поддерживает OIDC для безопасных развертываний поставщиков облачных служб, которые используют кратковременные маркеры, которые автоматически сменяются для каждого развертывания. OIDC включает следующие функции.

• Простая проверка подлинности между поставщиками облачных служб и GitHub Enterprise Server без необходимости хранения долгосрочных облачных секретов в вашем экземпляре
• Администраторы облака могут полагаться на механизмы безопасности конкретного поставщика облачных служб, чтобы обеспечить минимальный доступ рабочих процессов GitHub Actions к облачным ресурсам. Управление секретами между GitHub Enterprise Server и облаком не дублируется.

Дополнительные сведения см. в разделе Защита развертываний.

Поддержка GitHub Actions во внутренних репозиториях теперь общедоступна для организаций в экземпляре GitHub Enterprise Server. Вы можете использовать внутреннюю автоматизацию путем совместного использования действий во внутренних репозиториях. Вы можете управлять параметрами репозитория или использовать REST API, чтобы разрешить доступ к рабочим процессам в других репозиториях в организации или в любой организации в экземпляре . Дополнительные сведения см. в разделах "Общий доступ к действиям и рабочим процессам с предприятием", "Управление параметрами GitHub Actions для репозитория" и "Разрешения действий" в документации по REST API.

Теперь можно использовать кэширование зависимостей для ускорения рабочих процессов GitHub Actions. Чтобы кэшировать зависимости для задания, можно включить действия или действие кэша для создания кэша с уникальным ключом. Кэши можно совместно использовать во всех рабочих процессах в одном репозитории. Затем эти рабочие процессы могут восстановить кэш и работать быстрее.

Действия пользователи также могут использовать наши API кэша для:

• Определите корпоративную политику для диапазона размеров кэша, разрешенного для каждого репозитория.
• Запрашивайте сведения об использовании кэша в каждом репозитории и отслеживайте, достигает ли общий размер всех кэшей верхнего предела.
• Увеличьте максимальный размер кэша для репозитория в пределах допустимых корпоративных ограничений в зависимости от требований к кэшу репозитория.
• Отслеживайте совокупное использование кэша на уровне организации или на уровне предприятия.

Внешнее хранилище BLOB-объектов, настроенное в корпоративной учетной записи, теперь будет совместно использоваться артефактами рабочих процессов, журналами, а также кэшами. Дополнительные сведения см. в разделе Кэширование зависимостей для ускорения рабочих процессов.

Теперь вы можете настроить GitHub Enterprise Server для автоматического подписания фиксаций, сделанных в веб-интерфейсе, например при редактировании файла или слиянии запроса на вытягивание. Подписанные фиксации повышают уверенность в том, что изменения поступают из надежных источников. Эта функция позволяет параметру защиты ветви Требовать подписанные фиксации блокировать вход неподписанных фиксаций в репозиторий, разрешая при этом запись подписанных фиксаций, даже сделанных в веб-интерфейсе. Дополнительные сведения см. в статье Настройка подписывания веб-фиксации.

Клиенты, которые автоматически синхронизируют использование лицензий между GitHub Enterprise Server и GitHub Enterprise Cloud с помощью GitHub Connect, теперь у вас есть возможность синхронизировать использование лицензий независимо от автоматической еженедельной синхронизации. Эта функция также сообщает о состоянии задания синхронизации. Дополнительные сведения см. в статье Синхронизация потребления лицензий между GitHub Enterprise Server и GitHub Enterprise Cloud.

Повторно используемые рабочие процессы теперь общедоступны. Повторно используемые рабочие процессы помогают сократить дублирование, позволяя повторно использовать весь рабочий процесс, как если бы это было действием. В общедоступном выпуске для GitHub Enterprise Server теперь доступен ряд улучшений. Дополнительные сведения см. в статье Многократное использование рабочих процессов.

• Выходные данные можно использовать для передачи данных из повторно используемых рабочих процессов в другие задания в рабочем процессе вызывающего объекта.
• Секреты среды можно передавать повторно используемым рабочим процессам.
• Журнал аудита содержит сведения о том, какие повторно используемые рабочие процессы используются.
• Повторно используемые рабочие процессы в том же репозитории, что и вызывающий репозиторий, можно ссылаться только по пути и имени файла (PATH/FILENAME). Вызываемая рабочий процесс будет получена из той же фиксации, что и рабочий процесс вызывающего объекта.

Теперь у вас есть более полный контроль над тем, когда локальные средства выполнения выполняют обновления программного обеспечения. Если вы укажете --disableupdate флаг средству выполнения, оно не будет пытаться выполнить автоматическое обновление программного обеспечения, если доступна более новая версия средства выполнения. Это позволяет обновлять локальное средство выполнения по собственному расписанию и особенно удобно, если локальное средство выполнения тестов находится в контейнере.

Для обеспечения совместимости со службой GitHub Actions необходимо вручную обновить средство выполнения в течение 30 дней после того, как будет доступна новая версия средства выполнения. Инструкции по установке последней версии средства выполнения тестов см. в инструкциях по установке последнего выпуска в репозитории средства выполнения тестов.

Теперь владельцы организации могут повысить безопасность рабочих процессов CI/CD в локальных средствах выполнения, выбрав, какие рабочие процессы могут получить доступ к группе средств выполнения. Ранее любой рабочий процесс в репозитории, например средство меток проблем, мог получить доступ к локальным средствам выполнения, доступным для организации. Дополнительные сведения см. в разделе Управление доступом к локальным средствам выполнения тестов с помощью групп и блоге GitHub.

Теперь вы можете контролировать, могут ли GitHub Actions утверждать запросы на вытягивание. Эта функция защищает от использования пользователем GitHub Actions для удовлетворения требования защиты ветви "Необходимые утверждения" и объединения изменений, которые не были проверены другим пользователем. Чтобы предотвратить нарушение существующих рабочих процессов, по умолчанию включен параметр Разрешить проверкам GitHub Actions учитываться в требуемом утверждении. Владельцы организации могут отключить функцию в параметрах GitHub Actions организации. Дополнительные сведения см. в разделе Отключение или ограничение GitHub Actions для вашей организации.

Теперь вы можете повторно запускать только невыполненые задания или отдельные задания в GitHub Actions выполнения рабочего процесса. Дополнительные сведения см. в статье Повторный запуск рабочих процессов и заданий.

Граф зависимостей теперь обнаруживает файлы YAML для рабочих процессов GitHub Actions. GitHub Enterprise Server отобразит файлы рабочего процесса в разделе графа зависимостей вкладки Аналитика . Репозитории, которые публикуют действия, также смогут просматривать количество репозиториев, зависящих от этого действия, из элемента управления "Используется" на домашней странице репозитория. Дополнительные сведения см. в разделе Сведения о графе зависимостей.

• Примечание: эта функция была недоступна в GitHub Enterprise Server 3.5.0, 3.5.1, 3.5.2 и 3.5.3. Эта функция доступна в версии 3.5.4 и более поздних версиях. [Обновлено: 16.08.2022]

GitHub Advanced Security теперь клиенты могут просматривать обзор оповещений системы безопасности на уровне предприятия. Новая вкладка Безопасность на уровне предприятия предоставляет ориентированное на репозиторий представление о рисках безопасности приложений, а также ориентированное на оповещения представление всех оповещений сканирования секретов. Дополнительные сведения см. в статье "Общие сведения о безопасности".

Обзор оповещений системы безопасности на уровне организации теперь общедоступен. GitHub Advanced Security клиенты могут использовать обзор безопасности, чтобы просмотреть ориентированное на репозиторий представление о рисках безопасности приложений или ориентированное на оповещения представление всех оповещений сканирования кода, Dependabot и проверки секретов для всех репозиториев в организации. Дополнительные сведения см. в статье "Общие сведения о безопасности".

Теперь при сканировании кода обнаруживается большеЕ число CWES, а сканирование кода CodeQL полностью поддерживает функции стандартного языка в следующих выпусках.

• C# 10 / .NET 6
• Python 3.10
• Java 17
• TypeScript 4.5

Дополнительные сведения см. в блоге GitHub.

GitHub Advanced Security теперь клиенты могут просматривать оповещения сканирования кода на вкладке Безопасность организации. Это представление доступно для владельцев организации и участников команд с ролью диспетчера безопасности. Дополнительные сведения см. в статье "Общие сведения о безопасности".

Теперь пользователи могут получать оповещения о проверке кода для организации в экземпляре GitHub Enterprise Server с помощью REST API. Эта новая конечная точка API дополняет существующую конечную точку для репозиториев. Дополнительные сведения см. в статье Проверка кода в документации по REST API.

GitHub Enterprise Server теперь может блокировать любые отправки при обнаружении маркера с высокой достоверностью. Разработчики могут обойти блок, предоставив подробные сведения о том, почему секрет должен быть зафиксирован через веб-интерфейс. Дополнительные сведения см. в разделе Защита push-уведомлений с помощью сканирования секретов.

GitHub Advanced Security теперь клиенты могут выполнять пользовательские шаблоны сканирования секретов на уровне организации или репозитория. Сухие запуски позволяют пользователям с правами владельца или администратора просматривать и оттачивать свои шаблоны перед их публикацией и созданием оповещений. Вы можете создать шаблон, а затем использовать команду Сохранить и сухой запуск , чтобы получить результаты. Проверка обычно занимает всего несколько секунд, но GitHub Enterprise Server также уведомляет владельцев организации или администраторов репозитория по электронной почте, когда результаты сухого запуска будут готовы. Дополнительные сведения см. в разделах Сведения о проверке секретов и Определение пользовательских шаблонов для сканирования секретов.

Журнал аудита теперь содержит события, связанные с пользовательскими шаблонами сканирования секретов. Эти данные помогают GitHub Advanced Security клиентам понять действия, выполняемые с пользовательскими шаблонами уровня репозитория, организации или предприятия для аудита безопасности и соответствия требованиям. Дополнительные сведения см. в разделах Просмотр журнала аудита для организации или Проверка журналов аудита для предприятия.

Теперь можно настроить два новых разрешения для проверки секретов при управлении настраиваемыми ролями репозитория.

• Просмотр результатов проверки секретов
• Закрытие или повторное открытие результатов проверки секретов

Дополнительные сведения см. в разделе Управление ролями пользовательского репозитория для организации.

GitHub Advanced Security теперь клиенты могут включить проверку секретов для архивных репозиториев с помощью пользовательского интерфейса и API. Дополнительные сведения см. в разделах "Сведения о проверке секретов", "Сведения об архивных репозиториях" и "Репозитории" документации по REST API.

GitHub Advanced Security клиенты, использующие проверку секретов, теперь могут получать веб-перехватчик при каждом обнаружении секрета в новом расположении. Событие secret_scanning_alert_location веб-перехватчика включает сведения о расположении, такие как SHA фиксации, и связанное оповещение об обнаружении. Для каждого нового пути к файлу, содержащего обнаруженный секрет, создается расположение. Дополнительные сведения см. в разделе События веб-перехватчика и полезные данные.

GitHub Advanced Security теперь клиенты могут просматривать оповещения Dependabot на вкладке Безопасность организации. Это представление доступно для владельцев организации и участников команд с ролью диспетчера безопасности. Дополнительные сведения см. в статье "Общие сведения о безопасности".

Теперь можно настроить два новых разрешения для оповещений Dependabot при управлении настраиваемыми ролями репозитория.

• Просмотр оповещений Dependabot
• Закрытие или повторное открытие оповещений Dependabot

Дополнительные сведения см. в разделе Управление ролями пользовательского репозитория для организации.

Теперь вы можете повторно открыть закрытые оповещения Dependabot на странице пользовательского интерфейса для закрытого оповещения. Это не влияет на запросы на вытягивание Dependabot или API GraphQL. Дополнительные сведения см. в разделе Сведения об оповещениях Dependabot.

• Примечание: эта функция была недоступна в GitHub Enterprise Server 3.5.0, 3.5.1, 3.5.2 и 3.5.3. Эта функция доступна в версии 3.5.4 и более поздних версиях. [Обновлено: 16.08.2022]

Пользователи обновлений версий Dependabot теперь могут заблаговременно обновлять зависимости для проектов Flutter или Dart, использующих диспетчер пакетов Pub.

Чтобы проверить обновления версий в собственном репозитории Dart или Flutter, добавьте следующий файл конфигурации в .github/dependabot.yaml. Обратите внимание на флаги package-ecosystem: "pub" и enable-beta-ecosystems: true .

version: 2
enable-beta-ecosystems: true
updates:
  - package-ecosystem: "pub"
    directory: "/"
    schedule:
      interval: "weekly"

Новый DependabotUpdate объект GraphQL позволяет просматривать сведения о том, что происходит с обновлениями безопасности репозитория. Когда GitHub Enterprise Server обнаруживает, что зависимость в репозитории уязвима, Dependabot попытается открыть запрос на вытягивание, чтобы обновить ее до неуязвимой версии. Теперь можно просмотреть запрос на вытягивание, который устраняет уязвимость. В некоторых случаях Dependabot не удается открыть запрос на вытягивание. Ранее сообщение об ошибке, созданное Dependabot, отображалось только в разделе "Оповещения Dependabot" на вкладке "Безопасность ". Теперь, если Dependabot возникает ошибка при попытке открыть запрос на вытягивание для оповещения системы безопасности, вы можете определить причину с помощью API GraphQL. Дополнительные сведения см. в разделе Объекты в документации по API GraphQL.

Теперь вы можете просматривать фиксированные оповещения из Dependabot с помощью API GraphQL. Вы также можете получать доступ и фильтровать по состоянию, а также по уникальному числовому идентификатору, а также фильтровать по состоянию в объекте оповещения об уязвимости. Следующие поля теперь существуют для RepositoryVulnerabilityAlert.

• number
• fixed_at
• fix_reason
• state

Дополнительные сведения см. в разделе Объекты в документации по API GraphQL.

Следующие события, связанные с Git, теперь могут отображаться в корпоративном журнале аудита. Если включить эту функцию и задать срок хранения журнала аудита, новые события будут доступны для поиска через пользовательский интерфейс и API, а также для экспорта с помощью JSON или CSV.

• git.clone
• git.fetch
• git.push

Из-за большого количества зарегистрированных событий Git рекомендуется отслеживать хранилище файлов экземпляра и просматривать связанные конфигурации оповещений. Дополнительные сведения см. в разделе Настройка журнала аудита для предприятия.

Этот выпуск включает в себя улучшения CODEOWNERS.

• Синтаксические ошибки теперь отображаются при просмотре файла CODEOWNERS из Интернета. Ранее, когда в строке файла CODEOWNERS возникала синтаксическая ошибка, эта ошибка пропускалась или в некоторых случаях приводила к тому, что весь файл CODEOWNERS не загружался. Приложения и действия GitHub могут получить доступ к одному и тому же списку ошибок с помощью новых API REST и GraphQL. Дополнительные сведения см. в разделе Репозитории в документации по REST API или в разделе Объекты в документации по API GraphQL.
• Когда кто-то создает новый запрос на вытягивание или отправляет новые изменения в черновик запроса на вытягивание, все владельцы кода, которые будут запрошены для проверки, теперь перечислены в запросе на вытягивание в разделе "Рецензенты". Эта функция позволяет заранее определить, кому будет предложено проверить, как только запрос на вытягивание будет помечен как готовый к проверке.
• Комментарии в файлах CODEOWNERS теперь могут отображаться в конце строки, а не только в выделенных строках.

Дополнительные сведения см. в разделе Сведения о владельцах кода.

Кнопка Обновить ветвь на странице запроса на вытягивание позволяет обновить ветвь запроса на вытягивание с помощью последних изменений из базовой ветви. Это полезно для проверки совместимости изменений с текущей версией базовой ветви перед слиянием. Два усовершенствования теперь предоставляют больше способов поддерживать ветвь в актуальном состоянии.

• Если ветвь раздела запроса на вытягивание устарела с базовой ветвью, вы можете обновить ее, перебазируя последнюю версию базовой ветви. Повторное перебазирование применяет изменения из ветви к последней версии базовой ветви, в результате чего ветвь с линейным журналом, так как фиксация слияния не создается. Чтобы выполнить обновление путем повторного базирования, щелкните раскрывающееся меню рядом с кнопкой Обновить ветвь , щелкните Обновить с перебазой, а затем — Перебазировать ветвь. Ранее ветвь Обновления выполняла традиционное слияние, которое всегда приводило к фиксации слияния в ветви запроса на вытягивание. Этот параметр по-прежнему доступен, но теперь у вас есть выбор. Дополнительные сведения см. в разделе Синхронизация запроса на вытягивание с базовой ветвью.

• Новый параметр репозитория позволяет всегда быть доступна кнопка Обновить ветвь , если ветвь раздела запроса на вытягивание не обновлена с базовой ветвью. Ранее эта кнопка была доступна, только если был включен параметр Требовать актуальность ветвей перед слиянием защиты ветвей. Люди с правами администратора или ведения может управлять параметром Всегда предлагать обновление ветвей запросов на вытягивание из раздела Запросы на вытягивание в параметрах репозитория. Дополнительные сведения см. в разделе Управление предложениями по обновлению ветвей запросов на вытягивание.

  • Примечание: эта функция была недоступна в GitHub Enterprise Server 3.5.0, 3.5.1, 3.5.2 и 3.5.3. Эта функция доступна в версии 3.5.4 и более поздних версиях. [Обновлено: 16.08.2022]

Теперь можно настроить настраиваемые заголовки HTTP, которые применяются ко всем сайтам GitHub Pages, обслуживающимся из экземпляра GitHub Enterprise Server. Дополнительные сведения см. в разделе Настройка GitHub Pages для вашего предприятия.

Теперь можно игнорировать редакции в представлении обвинения, создав файл .git-blame-ignore-revs в корне репозитория. Дополнительные сведения см. в разделе Просмотр файла.

В настоящее время общедоступна светлая тема с высокой контрастностью между элементами переднего плана и фона. Дополнительные сведения см. в разделе Управление параметрами темы.

• Примечание: эта функция была недоступна в GitHub Enterprise Server 3.5.0, 3.5.1, 3.5.2 и 3.5.3. Эта функция доступна в версии 3.5.4 и более поздних версиях. [Обновлено: 16.08.2022]

Владельцы репозиториев теперь могут настраивать правила защиты тегов для защиты тегов репозитория. После защиты с помощью правила защиты тегов теги, соответствующие указанному шаблону имени, могут создаваться и удаляться только пользователями с ролью Обслуживания или Администратор в репозитории. Дополнительные сведения см. в разделе "Настройка правил защиты тегов".

В GitHub Mobile для iOS 1.80.0 и более поздних версий пользователи теперь могут редактировать файлы в ветви раздела запроса на вытягивание. Поддержка редактирования файлов будет добавлена в GitHub Mobile для Android в будущем выпуске. [Обновлено: 13.09.2022]

Теперь приложения GitHub могут отправлять ресурсы выпуска.

Минимальные требования к корневому хранилищу и памяти увеличены для GitHub Enterprise Server 2.10 и 3.0 и теперь применяются начиная с версии 3.5.0.

• В версии 2.10 минимальное требование к корневому хранилищу увеличилось с 80 ДО 200 ГБ. По состоянию на 3.5.0 предварительные проверки системы завершаются сбоем, если корневое хранилище меньше 80 ГБ.
• В версии 3.0 минимальное требование к памяти увеличилось с 16 ДО 32 ГБ. По состоянию на 3.5.0 предварительные проверки системы завершаются ошибкой, если в системе меньше 28 ГБ памяти.

Дополнительные сведения см. в разделе Минимальные требования для каждой поддерживаемой платформы развертывания в разделе Настройка экземпляра GitHub Enterprise Server. [Обновлено: 20.06.2022]

Теперь поддерживается гипервизор VMware vSphere ESXi версии 7.0. [Обновлено: 07.09.2022]

Чтобы использовать поток авторизации устройств для приложений OAuth и GitHub, необходимо вручную включить эту функцию. Это изменение снижает вероятность использования приложений в фишинговых атаках на пользователей GitHub Enterprise Server, гарантируя, что интеграторы знают о рисках и делают осознанный выбор для поддержки этой формы проверки подлинности. Если вы владеете приложением OAuth или приложением GitHub или управляете им и хотите использовать поток устройства, вы можете включить его для своего приложения на странице параметров приложения. Конечные точки API потока устройств будут отвечать кодом 400 состояния для приложений, которые не включили эту функцию. Дополнительные сведения см. в разделе Авторизация приложений OAuth.

Теперь на странице оповещений сканирования кода всегда отображаются состояние оповещения и сведения для ветви по умолчанию. На боковой панели есть новая панель "Затронутые ветви", где можно просмотреть состояние оповещения в других ветвях. Если оповещение не существует в ветви по умолчанию, на странице оповещения будет отображаться состояние "In branch" или "In pull request" (В запросе на вытягивание) для расположения, где оповещение отображалось в последний раз. Это улучшение упрощает понимание состояния оповещений, которые были введены в базу кода. Дополнительные сведения см. в статье Сведения об оповещениях проверки кода.

Страница списка оповещений не изменяется и может быть отфильтровано по .branch Api сканирования кода можно использовать для получения более подробных сведений об ветвях для оповещений. Дополнительные сведения см. в разделе "Проверка кода" в документации по REST API.

Теперь при проверке кода отображаются сведения о источнике анализа оповещения. Если оповещение имеет несколько источников анализа, оно отображается на боковой панели "Затронутые ветви" и на временной шкале оповещения. Вы можете навести указатель мыши на значок источника анализа на боковой панели "Затронутые ветви", чтобы увидеть состояние оповещения в каждом источнике анализа. Если оповещение имеет только один источник анализа, сведения об источниках анализа не отображаются на странице оповещения. Эти улучшения упрощают понимание оповещений. В частности, это поможет вам понять те из них, которые имеют несколько источников анализа. Это особенно полезно для установки с несколькими конфигурациями анализа, такими как monorepos. Дополнительные сведения см. в статье Сведения об оповещениях проверки кода.

Списки репозиториев, принадлежащих пользователю или организации, теперь имеют дополнительный параметр фильтра "Шаблоны", что упрощает поиск репозиториев шаблонов.

GitHub Enterprise Server может отображать несколько распространенных форматов изображений, включая PNG, JPG, GIF, PSD и SVG, и предоставляет несколько способов сравнения различий между версиями. Теперь при просмотре добавленных или измененных изображений в запросе на вытягивание предварительные просмотры этих изображений отображаются по умолчанию. Ранее отображалось сообщение о том, что не удается отобразить двоичные файлы, и вам потребуется переключить параметр "Отображение расширенных различий". Дополнительные сведения см. в разделе Работа с файлами, не относящиеся к коду.

Новые gists теперь создаются с именем main ветви по умолчанию или альтернативным именем ветви по умолчанию, определенным в параметрах пользователя. Это соответствует способу создания других репозиториев на GitHub Enterprise Server. Дополнительные сведения см. в разделах Сведения о ветвях и Управление именем ветви по умолчанию для репозиториев.

Gists теперь отображает только 30 последних комментариев при первом отображении. Вы можете нажать кнопку Загрузить предыдущие комментарии... для просмотра дополнительных сведений. Это позволяет быстрее отображать множество комментариев. Дополнительные сведения см. в разделе Изменение содержимого и предоставление общего доступа к содержимому с помощью gists.

Страницы параметров для пользователей, организаций, репозиториев и команд были переработаны, сгруппированные похожие страницы параметров в разделы для улучшения информационной архитектуры и возможностей обнаружения. Дополнительные сведения см. в журнале изменений GitHub.

Фокус или наведение указателя мыши на метку теперь отображает описание метки в подсказке.

На создание и удаление приглашений репозитория, будь то через API или веб-интерфейс, теперь распространяются ограничения скорости, которые могут быть включены в экземпляре GitHub Enterprise Server. Дополнительные сведения об ограничениях скорости см. в разделе Настройка ограничений скорости.

MinIO объявила об удалении шлюзов MinIO с 1 июня 2022 года. Хотя шлюз MinIO для NAS по-прежнему является одним из поддерживаемых поставщиков хранилища для Github Actions и пакетов Github, мы рекомендуем перейти на поддержку MinIO LTS, чтобы получить поддержку и исправления ошибок из MinIO. Дополнительные сведения об ограничениях скорости см. в разделе Запланированное удаление шлюза MinIO для GCS, Azure, HDFS в репозитории minio/minio.

GitHub Connect больше не будет работать после 3 июня для экземпляров под управлением GitHub Enterprise Server 3.1 или более ранней версии из-за изменения формата маркеров проверки подлинности GitHub. Чтобы продолжить использовать GitHub Connect, выполните обновление до GitHub Enterprise Server 3.2 или более поздней версии. Дополнительные сведения см. в блоге GitHub. [Обновлено: 14.06.2022]

Средство выполнения CodeQL не рекомендуется использовать вместо CodeQL CLI. GitHub Enterprise Server 3.4 и более поздних версий больше не включает средство выполнения CodeQL. Этот устаревание влияет только на пользователей, использующих сканирование кода CodeQL в сторонних системах CI/CD. GitHub Actions пользователи не затрагиваются. GitHub настоятельно рекомендует клиентам перейти на CodeQL CLI, который является полнофункциональной заменой средства выполнения CodeQL и имеет множество дополнительных функций. Дополнительные сведения см. в разделе Переход с средства выполнения CodeQL на CodeQL CLI.

Средство выбора темы для GitHub Pages удалено из параметров Страницы. Дополнительные сведения о настройке тем для GitHub Pages см. в разделе Добавление темы на сайт GitHub Pages с помощью Jekyll.