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 "Wartungsmodus aktivieren und planen."

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 "Konfigurieren eines ausgehenden Webproxyservers."

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

Beim Anzeigen einer Liste der offenen Sitzungen für die bei einem Benutzerkonto angemeldeten Geräte zeigte die GitHub Enterprise Server-Webbenutzeroberfläche möglicherweise einen falschen Standort an.

In dem seltenen Fall, dass sich primäre Shards für Elasticsearch auf einem Replikatknoten befanden, schlug der Befehl ghe-repl-stop mit ERROR: Running migrations fehl.

HOCH: Git wurde mit Fixes aus Version 2.39.2 aktualisiert, die CVE-2023-22490 und CVE-2023-23946 korrigieren.

Die Pakete wurden auf die neuesten Sicherheitsversionen aktualisiert.

Wenn als AWS S3-URL für GitHub-Pakete eine VPC-Endpunkt-URL verwendet wurde, führte die Veröffentlichung und Installation von Paketen zu Fehlern.

MITTEL: In GitHub Enterprise Server wurde eine Sicherheitsanfälligkeit erkannt, die das Festlegen beliebiger Umgebungsvariablen aus einem einzelnen Umgebungsvariablenwert in GitHub Actions bei Verwendung eines Windows-basierten Runners aufgrund einer unsachgemäßen Bereinigung von NULL-Bytes ermöglichte. Um diese Sicherheitsanfälligkeit auszunutzen, benötigten Angreifer*innen Berechtigungen für das Ändern des Werts von Umgebungsvariablen für die Verwendung mit GitHub Actions. Dieses Sicherheitsrisiko wurde über das GitHub Bug Bounty-Programm gemeldet und CVE-2023-22381 zugewiesen.

Die Pakete wurden auf die neuesten Sicherheitsversionen aktualisiert.

Während der Überprüfungsphase einer Konfigurationsausführung kann ein Fehler No such object error für die Dienste Notebook und Viewscreen auftreten.

Bei Aktivierung der automatischen TLS-Zertifikatverwaltung mit Let's Encrypt konnte der Prozess mit dem Fehler The certificate is not signed by a trusted certificate authority (CA) or the certificate chain in missing intermediate CA signing certificates fehlschlagen.

Wenn es während der Diff-Erstellung zu einer Zeitüberschreitung kommt (wenn ein Commit z. B. meldet, dass die Diff-Erstellung zu lange dauert), sind die vom Webhookereignis push bereitgestellten Diff-Informationen leer. Zuvor wurde das Webhookereignis push nicht übermittelt.

HIGH: Git wurde mit Korrekturen aus 2.39.1 aktualisiert, die sich auf CVE-2022-41903 und CVE-2022-23521 beziehen.

Bereinigung zusätzlicher Geheimnisse in Supportpaketen und im Konfigurationsprotokoll.

Abhängigkeiten für die CodeQL-Aktion wurden auf die neuesten Sicherheitsversionen aktualisiert.

Die Pakete wurden auf die neuesten Sicherheitsversionen aktualisiert.

Die Metriken Active workers und Queued requests für die Containerdienste github (aus Metadaten umbenannt), gitauth und unicorn wurden nicht ordnungsgemäß aus Collectd gelesen und in der Verwaltungskonsole angezeigt.

Dependabot-Warnungs-E-Mails wurden an deaktivierte Repositorys gesendet.

Repositorys, die für die Migration gesperrt sind, ermöglichten das Bearbeiten von Dateien auf der Webbenutzeroberfläche.

Beim Anzeigen der Diffs eines Pull Requests für eine große Datei mit vielen Zeilen zwischen Änderungen war es nicht möglich, die Ansicht zu erweitern, um alle Änderungen anzuzeigen.

Der Befehl git-janitor konnte veraltete multi-pack-index.lock-Dateien nicht korrigieren. Dies führte zu Fehlern bei der Wartung des Repositorys.

Die Befehle ghe-support-bundle und ghe-cluster-support-bundle wurden aktualisiert, damit sie das -p/--period-Flag enthalten, um ein zeitlich begrenztes Supportpaket zu generieren. Die Dauer kann in Tagen und Stunden angegeben werden, z. B. -p '2 hours', -p '1 day', -p '2 days 5 hours'.

Die Leistung von Konfigurationsausführungen, die mit ghe-config-apply gestartet wurden, wurde optimiert.

Wenn du eine Instanz mit einer neuen Stammpartition aktualisierst, stellst du durch Ausführen des Befehls ghe-upgrade mit der Option -t/--target sicher, dass eine Preflightüberprüfung der minimalen Datenträgergröße für die Zielpartition ausgeführt wird.

Beim Exportieren von Kontodaten, beim Sichern eines Repositorys oder beim Durchführen einer Migration läuft der Link zu einem Repositoryarchiv jetzt nach 1 Stunde ab. Bisher lief der Archivlink nach 5 Minuten ab.

HOCH: In GitHub Enterprise Server wurde ein Path Traversal-Sicherheitsrisiko identifiziert, das beim Erstellen einer GitHub Pages-Website die Ausführung von Remotecode ermöglichte. Um dieses Sicherheitsrisiko auszunutzen, benötigten Angreifer*innen die Berechtigung, eine GitHub Pages-Website in der Instanz zu erstellen. Dieses Sicherheitsrisiko wurde über das GitHub Bug Bounty-Programm gemeldet und CVE-2022-46256 zugewiesen.

HOCH: Ein Sicherheitsrisiko durch eine falsche Autorisierung ermöglichte bereichsbezogenen Benutzer-zu-Server-Token das Höherstufen auf vollständigen Administratorzugriff für ein Repository. Angreifer*innen benötigten dazu ein Konto mit Administratorzugriff, um eine bösartige GitHub-App zu installieren. Dieses Sicherheitsrisiko trat bei allen Versionen von GitHub Enterprise Server vor 3.7.0 auf. Dieses Sicherheitsrisiko wurde über das GitHub Bug Bounty-Programm gemeldet und CVE-2022-23741 zugewiesen.

MITTEL: In GitHub Enterprise Server wurde eine Sicherheitslücke zur Offenlegung von Informationen identifiziert, durch die einer GitHub Actions-Runnergruppe über die API private Repositorys von Benutzerinnen hinzugefügt werden konnten, die keinen Zugriff auf diese Repositorys hatten. Das führte dazu, dass die Repositorynamen auf der Benutzeroberfläche angezeigt wurden. Um diese Sicherheitsanfälligkeit auszunutzen, benötigten Angreiferinnen Zugriff auf die GHES-Instanz und Berechtigungen zum Ändern von GitHub Actions-Runnergruppen. Außerdem mussten sie die verschleierten IDs privater Repositorys richtig erraten. Dieses Sicherheitsrisiko wurde über das GitHub Bug Bounty-Programm gemeldet und CVE-2022-46257 zugewiesen.

Wenn eine GitHub Actions-Abhängigkeit eine angeheftete SHA-Version verwendet, markiert Dependabot die Abhängigkeit nicht mehr als anfällig.

Wenn Standortadministrator*innen den Befehl ghe-repl-sync-ca-certificates auf einem primären Instanzknoten über die Verwaltungsshell (SSH) ausgeführt haben, replizierte der Befehl nur Zertifizierungsstellenzertifikate vom primären Knoten der Instanz auf einen einzelnen Replikatknoten. Der Befehl replizierte die Zertifikate nicht auf alle verfügbaren Replikatknoten.

Die Installation von GitHub Enterprise Server auf dem VMware ESXi-Hypervisor führte aufgrund der Generierung einer OVA-Datei mit einem ungültigen Kapazitätswert zu einem Fehler.

Wenn Benutzer*innen einen Vorgang mithilfe der API ausgeführt haben, hat GitHub Enterprise Server Kontingente für die Repositorygröße erzwungen, auch wenn sie global deaktiviert waren.

Das member-Webhookereignis enthält nicht die Feldwerte from und to für das Feld permission als Teil des Felds changes.

Nachdem Konten einzelner Benutzerinnen aus der Instanz gelöscht wurde, waren Bildanlagen, die von den Benutzerinnen in Kommentaren hochgeladen wurden, auf der Weboberfläche nicht mehr sichtbar.

In einigen Fällen meldete die Seite zum Einrichten der Codeüberprüfung fälschlicherweise, dass GitHub Actions für die Instanz nicht konfiguriert wurde.

Wenn Benutzer*innen beim Erstellen eines neuen Gist mehrere Dateien hochgeladen hatten, konnten sie keine Dateien löschen, die nach der ersten hochgeladen wurden.

In einem Systemprotokoll wurde eine Meldung auf Debugebene angezeigt, die schnell Speicherplatz auf dem Stammspeichervolume der Instanz belegen konnte.

MITTEL: CommonMarker wurde aktualisiert, um ein Szenario zu beheben, in dem parallele Anforderungen an die Markdown-REST-API zu einer unbegrenzten Ressourcenauslastung führen konnten. Dieses Sicherheitsrisiko wurde CVE-2022-39209 zugewiesen.

MITTEL: Bereichsbezogene Benutzer-zu-Server-Token von GitHub-Apps konnten Autorisierungsüberprüfungen in GraphQL-API-Anforderungen beim Zugriff auf Nicht-Repository-Ressourcen umgehen. Dieses Sicherheitsrisiko wurde über das GitHub Bug Bounty-Programm gemeldet und CVE-2022-23739 zugewiesen.

MITTEL: Links für Pull Request-Previews haben URLs nicht ordnungsgemäß bereinigt, sodass böswillige Benutzer*innen gefährliche Links in die Webbenutzeroberfläche der Instanzen einbetten konnten. Dieses Sicherheitsrisiko wurde über das GitHub Bug Bounty-Programm gemeldet.

MITTEL: In GitHub Enterprise Server wurde ein Sicherheitsrisiko durch eine falsche Autorisierung festgestellt, die es einem Repository-Bereichstoken mit Lese-/Schreibzugriff ermöglichte, GitHub Actions-Workflowdateien ohne Workflowbereich zu ändern. Die Repository-Inhalt sollten den Workflowbereich erzwingen. Dieses Sicherheitsrisiko wurde über das GitHub Bug Bounty-Programm gemeldet und CVE-2022-46258 zugewiesen.

Die Festlegung des Wartungsmodus mit einer IP-Ausnahmeliste wurde bei Upgrades nicht beibehalten.

GitHub Pages-Builds konnten für Instanzen in AWS, die für Hochverfügbarkeit konfiguriert sind, zu einem Timeout führen.

Nach der Konfiguration von Dependabot- und Warnungshash-E-Mails sendete die Instanz Hash-E-Mails an gesperrte Benutzer*innen.

Der Zeitstempel des Überwachungsprotokolls für Dependabot-Warnungsereignisse gab das Erstellungsdatum der Warnung anstelle des Zeitstempels zurück, bei dem Benutzer*innen eine Maßnahme für die Warnung ergriffen hatten.

Beim Zugriff auf JavaScript-Ressourcen einer Instanz hinter einem Proxy wurden im Browser CORS-Fehler (Cross-Origin Resource Sharing) angezeigt.

Wenn Benutzer*innen eine Statusprüfung mit führenden oder nachfolgenden Leerzeichen benannt hatten, hat die Instanz eine doppelte Überprüfung erstellt, wenn eine andere Überprüfung mit demselben Namen und ohne führende oder nachfolgende Leerzeichen vorhanden war.

Wenn Benutzer*innen einen Pre-Receive-Hook für mehrere Repositorys konfigurierten, wurde auf der Seite Hooks der Instanzen nicht immer der richtige Status für den Hook angezeigt.

Wenn Unternehmensbesitzerinnen die Identität von Benutzerinnen annahmen und versuchten, eine GitHub-App zu installieren, wurde die Schaltfläche zum Bestätigen der Installation deaktiviert und konnte nicht ausgewählt werden.

Nach dem Ausführen von Migrationsvorgängen für den GitHub Enterprise Importer auf einer Instanz, die für Hochverfügbarkeit konfiguriert war, konnte die Replikation der Migrationsspeicherressourcen nicht mehr aufholen.

Zombieprozesse werden nicht mehr im Container gitrpcd gesammelt.

HIGH: Updated dependencies for the Management Console to the latest patch versions, which addresses security vulnerabilities including CVE-2022-30123 and CVE-2022-29181.

HIGH: Added checks to address an improper cache key vulnerability that allowed an unauthorized actor to access private repository files through a public repository. This vulnerability has been assigned CVE-2022-23738.

MEDIUM: Updated CommonMarker to address a scenario where parallel requests to the Markdown REST API could result in unbounded resource exhaustion. This vulnerability has been assigned CVE-2022-39209.

MEDIUM: Updated Redis to 5.0.14 to address CVE-2021-32672 and CVE-2021-32762.

MEDIUM: Updated GitHub Actions runners to fix a bug that allowed environment variables in GitHub Actions jobs to escape the context of the variable and modify the invocation of docker commands directly. For more information, see the Actions Runner security advisory.

MEDIUM: An improper privilege management vulnerability was identified in GitHub Enterprise Server that allowed users with improper privileges to create or delete pages via the API. To exploit this vulnerability, an attacker would need to be added to an organization's repo with write permissions. This vulnerability was reported via the GitHub Bug Bounty program and has been assigned CVE-2022-23737.

LOW: Due to a CSRF vulnerability, a GET request to the instance's site/toggle_site_admin_and_employee_status endpoint could toggle a user's site administrator status unknowingly.

Packages have been updated to the latest security versions.

After a site administrator made a change that triggered a configuration run, such as disabling GitHub Actions, validation of services would sometimes fail with the message WARNING: Validation encountered a problem.

After a site administrator installed a hotpatch containing changes to web interface assets such as JavaScript files or images, the instance did not serve the new assets.

When a user accessed a renamed repository using Git, the hostname in the Git output incorrectly indicated GitHub.com instead of the instance's hostname.

On instances using LDAP authentication and LDAP sync, sync would fail and print undefined method ord for nil:NilClass in ldap-sync.log.

Addressed a bug in which the endpoint for creating a tag protection state for a repository was returning a 500 error.

Deleted assets and assets scheduled to be purged within a repository, such as LFS files, took too long to to be cleaned up.

If a user installed a GitHub App for the user account and then converted the account into an organization, the app was not granted organization permissions.

Missing secret scanning alerts on instance with a GitHub Advanced Security license that was not upgraded directly to GitHub Enterprise Server 3.4 are now visible in the web interface and through the REST API.

In some cases, on an instance with a GitHub Advanced Security license, secret scanning alerts did not include a provider type, and instead indicated that the provider type was "unknown."

To ensure that site administrators can successfully complete an upgrade, the instance will now execute a preflight check to ensure that the virtual machine meets minimum hardware requirements. The check also verifies Elasticsearch's health. You can review the current requirements for CPU, memory, and storage for GitHub Enterprise Server in the "Minimum requirements" section within each article in "GitHub Enterprise Server-Instanz einrichten."

Repositoryarchive für Migrationsvorgänge enthalten jetzt ein is_archived-Feld.

HOCH: Eine GitHub-App konnte ein bereichsbezogenes Benutzer-zu-Server-Token verwenden, um Benutzerautorisierungslogik zu umgehen und Berechtigungen zu eskalieren.

MITTEL: Die Verwendung eines von rechts nach links gelesenen Unicode-Überschreibungszeichens in der Liste der für eine GitHub-App verfügbaren Dateien konnte zusätzliche Dateien verdecken, auf die die App Zugriff hat.

NIEDRIG: Wenn Benutzerinnen die Möglichkeit gewährt wird, den Branchschutz zu umgehen, können diese Benutzerinnen die Anforderung zur Signaturüberprüfung nicht mehr umgehen.

Die Pakete wurden auf die neuesten Sicherheitsversionen aktualisiert.

Die Installation eines TLS-Zertifikats führte zu einem Fehler, wenn die Antragstellerzeichenfolge des Zertifikats UTF-8-Zeichen enthielt.

Konfigurationsausführungen konnten zu Fehlern führen, wenn retry-limit oder retry-sleep-duration von Administrator*innen manuell mit ghe-config festgelegt wurden.

Der Befehl ghe-find-insecure-git-operations hat nicht nach jedem Aufruf alle unsicheren Git-Vorgänge zurückgegeben.

In einigen Fällen wurde das Monitordashboard der Verwaltungskonsole nicht ordnungsgemäß geladen.

Ein nicht funktionaler Link zum Exportieren von Monitorgraphen der Verwaltungskonsole als PNG-Bild wurde entfernt.

Beim Senden eines Supportpakets an den GitHub Enterprise-Support mithilfe von ghe-support-upload hat die Option -t das hochgeladene Bundle nicht ordnungsgemäß dem angegebenen Ticket zugeordnet.

In seltenen Fällen wurde bei einem Upgrade von GitHub Enterprise Server 3.3 auf 3.4 fälschlicherweise die Art der Datenspeicherung geändert, was zu Fehlern bei nachfolgenden Upgrades führte. Bei einem direkten Upgrade auf dieses Release von Version 3.3 tritt dieser Fehler nicht auf.

Wenn als AWS S3-URL für GitHub-Pakete eine VPC-Endpunkt-URL verwendet wurde, führte die Veröffentlichung und Installation von Paketen zu Fehlern.

Beim Klonen oder Abrufen aus Git über SSH konnten bei Übertragungen mit einer Größe von mehr als 1 GB Datenbeschädigungen auftreten.

Ein Link zurück zu den Sicherheitseinstellungen für das Unternehmenskonto der Instanz hat manchmal eine falsche Ansicht gerendert.

Nachdem Benutzer*innen Pakete auf der Weboberfläche gelöscht oder wiederhergestellt hatten, wurde die Anzahl der Pakete manchmal falsch gerendert.

Nach der erfolgreichen Konfiguration von Dependabot- und Warnungshash-E-Mails sendete die Instanz keine Hash-E-Mails.

Nach dem Upgrade auf GitHub Enterprise Server 3.5 schienen einige Releases in Repositorys zu fehlen. Dieses Problem trat auf, wenn die erforderlichen Elasticsearch-Indexmigrationsvorgänge nicht erfolgreich abgeschlossen wurden. Auf der Benutzeroberfläche für Releases wird nun angegeben, ob auf den Abschluss von Elasticsearch-Indexmigrationsvorgängen gewartet wird. Außerdem werden Verknüpfungen auf die Dokumentation zum Beobachten des Status und zum sofortigen Abschließen der Migration bereitgestellt.

Manuell deaktivierte GitHub Actions-Workflows in einem Repository wurden wieder aktiviert, wenn das Repository einen Push mit mehr als 2.048 Commits empfangen hat oder der Standardbranch des Repositorys geändert wurde.

Beim Anzeigen der Diffs eines Pull Requests für eine große Datei mit vielen Zeilen zwischen Änderungen war es nicht möglich, die Ansicht zu erweitern, um alle Änderungen anzuzeigen.

Wenn der Branchschutz aktiviert war, wurden die Umgebungsvariable GITHUB_REF_PROTECTED und die github.ref_protected-Kontexte für GitHub Actions-Workflowausführungen fälschlicherweise auf false festgelegt.

Bei Instanzen, die GitHub Advanced Security verwendeten, hat die Geheimnisüberprüfung automatisch persönliche Zugriffstoken widerrufen, die öffentlichen Repositorys hinzugefügt waren.

Repositorys für Pakete haben fälschlicherweise den Abschnitt „Verwendet von“ angezeigt.

Nach dem Freigeben eines Repositorys für den temporären Zugriff konnte ein Siteadministrator die Einstellungen für Sicherheitsprodukte im Repository nicht mehr verwalten.

Doppelte administrative SSH-Schlüssel konnten sowohl an der Verwaltungskonsole als auch in der Datei /home/admin/.ssh/authorized_keys vorkommen.

Die Websiteadministratorseite für einzelne Benutzer*innen auf http(s)://HOSTNAME/stafftools/users/USERNAME/admin enthielt Funktionen, die nicht für GitHub Enterprise Server vorgesehen waren.

In einigen Fällen konnte die Ausführung von ghe-cluster-config-apply eine leere Konfiguration zu bestehenden Knoten in einem Cluster replizieren.

In einigen Fällen wurden Konfigurationsausführungen, die mit ghe-config-apply gestartet wurden, nicht abgeschlossen werden oder gaben den Fehler Container count mismatch zurück.

Nach dem Aktualisieren eines selbstsignierten TLS-Zertifikats auf einer GitHub Enterprise Server-Instanz wurden Benutzeroberflächenelemente auf einigen Seiten der Weboberfläche nicht angezeigt.

Die Siteadministratorleiste oben auf der Weboberfläche enthielt einen defekten Link zu SHA für die aktuell ausgeführte Version der Anwendung.

In einigen Fällen konnten Hintergrundaufgaben aufgrund einer Bibliothek, die gleichzeitig verwendet wurde, obwohl sie nicht threadsicher war, zum Stillstand kommen.

Warnungen aus der Geheimnisüberprüfung für GitHub Advanced Security-Kunden fehlten in der Webbenutzeroberfläche und der REST-API, wenn ein Siteadministrator nicht direkt auf GitHub Enterprise Server 3.4 upgradete. Die Warnungen sind nun sichtbar.

Wenn ein Benutzer ein Repository in eine Organisation forkte, wurde eine lange Liste von Organisationen nicht korrekt gerendert.

Die Generierung von Supportbundles wird durch die parallelisierte Protokollbereinigung beschleunigt. Weitere Informationen zu Supportbundles findest du unter Providing data to GitHub Support (Bereitstellen von Daten für GitHub Support).

APIs, die die Route organization oder org enthalten, akzeptieren jetzt entweder das Datenfeld oder die ID der Organisation. Zuvor akzeptierten die APIs nur Datenfelder. Dies führte dazu, dass für GitHub Advanced Security-Endpunkte kein Zugriff auf Link-Header möglich war. Weitere Informationen findest du in der REST-API-Dokumentation unter Organisationen.

Das Unternehmensüberwachungsprotokoll enthält jetzt mehr benutzergenerierte Ereignisse, wie z. B. project.create. Die REST-API liefert ebenfalls zusätzliche benutzergenerierte Ereignisse, wie z. B. repo.create. Weitere Informationen findest du unter Zugreifen auf das Überwachungsprotokoll für dein Unternehmen und unter Verwenden der Überwachungsprotokoll-API für dein Unternehmen.

In einigen Fällen konnten Cachereplikate einige Git-Operationen für kürzlich aktualisierte Repositorys ablehnen. Weitere Informationen zum Zwischenspeichern von Repository findest du unter Informationen zum Zwischenspeichern von Repositorys.

KRITISCH: Der Elasticsearch-Container von GitHub Enterprise Server verwendete eine Version von OpenJDK 8, die bei der Verarbeitung bösartiger XSLT-Stylesheets für das Abschneiden von Ganzzahlen anfällig war. Das Sicherheitsrisiko wurde CVE-2022-34169 zugewiesen.

HOCH: Zuvor auf Benutzerkonten installierte Apps erhielten automatisch die Berechtigung zum Zugriff auf eine Organisation über bereichsbezogene Zugriffstoken, nachdem das Benutzerkonto in ein Organisationskonto umgewandelt wurde. Dieses Sicherheitsrisiko wurde über das GitHub Bug Bounty-Programm gemeldet.

In einigen Fällen konnten GitHub Enterprise Server-Instanzen in AWS, die den Instanztyp r4.4xlarge verwendeten, nicht gestartet werden.

In einigen Fällen konnten sich Benutzeroberflächenelemente auf der Registerkarte Geänderte Dateien eines Pull Requests überlappen.

Wenn für die Instanz ein benutzerdefinierter Inaktivitätsschwellenwert festgelegt wurde, wurde dieser Schwellenwert bei der Sperrung aller inaktiven Benutzer nicht zuverlässig eingehalten. Weitere Informationen zur Inaktivität findest du unter Inaktive Benutzer verwalten.

Bei der Berechnung der Committer für GitHub Advanced Security war es nicht möglich, einzelne Repositorys anzugeben. Weitere Informationen findest du unter Websiteadministrator-Dashboard.

In einigen Fällen konnte der nach dem Upgrade ausgeführte es:upgrade-Prozess von Elasticsearch vor dem Abschluss abstürzen.

Das Skript für die Migration zu internen Repositorys konnte die Sichtbarkeit für öffentliche Repositorys nicht in intern oder privat umwandeln. Weitere Informationen zur Migration findest du unter Zu internen Repositorys migrieren.

Die Erkennung von GitHub Actions-Workflowdateien für das Abhängigkeitsdiagramm war in GitHub Enterprise Server 3.5.0, 3.5.1, 3.5.2 und 3.5.3 nicht verfügbar, ist aber jetzt in 3.5.4 verfügbar. Weitere Informationen findest du unter Informationen zum Abhängigkeitsdiagramm.

Die Möglichkeit, geschlossene Dependabot-Warnungen erneut zu öffnen, war in GitHub Enterprise Server 3.5.0, 3.5.1, 3.5.2 und 3.5.3 nicht verfügbar, ist aber jetzt in 3.5.4 verfügbar. Weitere Informationen findest du unter Anzeigen und Aktualisieren von Dependabot-Warnungen.

Die Möglichkeit, Updates immer vom Basisbranch zum KOPFTEIL eines Pull Requests vorzuschlagen, war in GitHub Enterprise Server 3.5.0, 3.5.1, 3.5.2 und 3.5.3 nicht verfügbar, ist aber jetzt in 3.5.4 verfügbar. Weitere Informationen findest du unter Verwalten von Vorschlägen zum Aktualisieren von Pull Request-Branches.

Das helle, kontrastreiche Design war in GitHub Enterprise Server 3.5.0, 3.5.1, 3.5.2 und 3.5.3 nicht verfügbar, ist aber jetzt in 3.5.4 verfügbar. Weitere Informationen findest du unter Verwalten der Designeinstellungen.

pre_receive_hook.rejected_push-Ereignisse wurden nicht im Überwachungsprotokoll des Unternehmens angezeigt.

MITTEL: Verhindert einen Angriff, bei dem eine serverseitige Anforderungsfälschung (Server-Side Request Forgery, SSRF) die Subversion-Brücke (SVN) potenziell zwingen konnte, Remotecode auszuführen, indem beliebige Daten in Memcached eingeschleust wurden.

MITTEL: Verhindert, dass Angreifer*innen JavaScript-Code ausführen, indem sie ein Sicherheitsrisiko durch Cross-Site Scripting (XSS) in Dropdown-Benutzeroberflächenelementen auf der Weboberfläche von GitHub Enterprise Server ausnutzen.

Grafana wurde auf Version 7.5.16 aktualisiert, die verschiedene Sicherheitsrisiken behebt, einschließlich CVE-2020-13379 und CVE-2022-21702.

Die Pakete wurden auf die neuesten Sicherheitsversionen aktualisiert.

MITTEL: Ein gespeichertes XSS-Sicherheitsrisiko wurde in GitHub Enterprise Server identifiziert, das die Einschleusung beliebiger Attribute ermöglichte. Diese Einschleusung wurde durch die Inhaltssicherheitsrichtlinie (Content Security Policy, CSP) von Github blockiert. Dieses Sicherheitsrisiko wurde über das GitHub Bug Bounty-Programm gemeldet und CVE-2022-23733 zugewiesen. [Aktualisiert: 31.07.2022]

MITTEL: In GitHub Enterprise Server wurde ein Sicherheitsrisiko bei der Deserialisierung nicht vertrauenswürdiger Daten identifiziert, das möglicherweise zur Remotecodeausführung über die Subversion-Brücke (SVN) führen konnte. Um dieses Sicherheitsrisiko auszunutzen, mussten Angreifer*innen Zugriff über eine serverseitige Anforderungsfälschung (Server-Side Request Forgery, SSRF) erlangen, die es ihnen ermöglichen würde, die Daten zu deserialisieren. Dieses Sicherheitsrisiko wurde über das GitHub Bug Bounty-Programm gemeldet und CVE-2022-23734 zugewiesen.

In einigen Fällen konnte der Collectd-Daemon zu viel Arbeitsspeicher verbrauchen.

In einigen Fällen konnten sich Backups von rotierten Protokolldateien ansammeln und übermäßigen Speicherplatz verbrauchen.

Nach einem Upgrade auf ein neues Featurerelease und einer anschließenden Konfigurationsausführung konnte Elasticsearch beim Neuerstellen von Indizes übermäßige Ausnahmen protokollieren.

In einigen Fällen, in denen ein geschützter Branch mehr als eine zustimmende Überprüfung erforderte, konnte ein Pull Request mit weniger als der erforderlichen Anzahl von zustimmenden Überprüfungen gemergt werden.

GitHub Enterprise Importer hat Einstellungen für Projekte innerhalb von Repositorys nicht ordnungsgemäß migriert.

Auf Instanzen, die LDAP-Authentifizierung verwenden, platzierte die Authentifizierungsaufforderung für den Sudo-Modus den Cursor standardmäßig fälschlicherweise im Kennwortfeld, wenn sowohl Textfelder für einen Benutzernamen als auch ein Kennwort sichtbar waren.

Das Dashboard für Websiteadministratorinnen enthält fälschlicherweise eine Option zum Exportieren eines Berichts, in dem inaktive Benutzerinnen aufgelistet sind.

Der Endpunkt Abrechnung der Abrechnungs-API gibt jetzt Link-Header zurück, um Informationen zur Paginierung bereitzustellen.

Der Endpunkt Abrechnung der Abrechnungs-API gibt jetzt die richtige Gesamtzahl der Committer zurück.

Auf der Randleiste für die Einstellungen einer Organisation enthielt das Navigationselement Archiv keine untergeordneten Elemente.

VMware vSphere ESXi Hypervisor Version 7.0 wird jetzt unterstützt. [Aktualisiert: 07.09.2022]

Das Befehlszeilenhilfsprogramm ghe-set-password startet die erforderlichen Dienste automatisch, wenn die Instanz im Wiederherstellungsmodus gestartet wird.

Metriken für aqueduct-Hintergrundprozesse werden für die Collectd-Weiterleitung gesammelt und an der Verwaltungskonsole angezeigt.

Der Speicherort des Datenbankmigrations- und Konfigurationsausführungsprotokolls /data/user/common/ghe-config.log wird jetzt auf der Seite mit den Details zu einer laufenden Migration angezeigt.

MITTEL: Verhindert einen Angriff, bei dem ein org-Abfragezeichenfolgenparameter für eine GitHub Enterprise Server-URL angegeben werden kann, der dann den Zugriff auf die aktiven Committer einer anderen Organisation ermöglicht.

MITTEL: Stellt sicher, dass github.company.com und github-company.com von internen Diensten nicht als identische Hostnamen ausgewertet werden, um einen potenziellen SSRF-Angriff (Server-Side Request Forgery, serverseitige Anforderungsfälschung) zu verhindern.

NIEDRIG: Angreifer konnten mit einem Path Traversal-Angriff über HTTP selbst dann auf die Verwaltungskonsole zugreifen, wenn externe Firewallregeln den HTTP-Zugriff blockierten.

Die Pakete wurden auf die neuesten Sicherheitsversionen aktualisiert.

Dateien innerhalb eines Artefaktarchivs konnten nach der Dekomprimierung aufgrund restriktiver Berechtigungen nicht geöffnet werden.

In einigen Fällen waren Pakete, die an die Containerregistrierung gepusht wurden, auf der Webbenutzeroberfläche von GitHub Enterprise Server nicht sichtbar.

Nach dem Upgrade einer Instanz mit geringer Auslastung auf GitHub Enterprise Server 3.5 blieb die Verwaltungskonsole möglicherweise auf dem Startbildschirm hängen.

Redis-Timeouts stoppen Datenbankmigrationsvorgänge nicht mehr während ghe-config-apply ausgeführt wird.

Die Prozessoren für Hintergrundaufträge blieben in einem teilweise heruntergefahrenen Zustand stecken, was dazu führte, dass bestimmte Arten von Hintergrundaufträgen (z. B. Codeüberprüfung) nicht mehr ausgeführt werden konnten.

In einigen Fällen wurden Websiteadministratoren nicht automatisch als Unternehmensbesitzer hinzugefügt.

Actions-Workflows, die andere wiederverwendbare Workflows aufrufen, konnten nicht nach einem Zeitplan ausgeführt werden.

Das Auflösen von Actions mit GitHub Connect führte zu einem Fehler, kurz nachdem das Repository von öffentlich auf intern geändert wurde.

Die Leistung von Dependabot-Updates wurde verbessert, wenn sie zuvor aktiviert wurden.

Erhöhe die maximale Anzahl gleichzeitiger Verbindungen für Actions-Runner, um das GHES-Leistungsziel zu unterstützen.

Die Erstellungs- und Synchronisierungstimeouts von GitHub Pages sind jetzt in der Verwaltungskonsole konfigurierbar.

Es wurde eine Umgebungsvariable hinzugefügt, um Redis-Timeouts zu konfigurieren.

Beim Erstellen oder Aktualisieren von Überprüfungsausführungen oder Überprüfungssammlungen konnte 500 Internal Server Error zurückgegeben werden, wenn der Wert für bestimmte Felder (z. B. den Namen) zu lang war.

Die Leistung auf der Registerkarte „Dateien geändert“ von Pull Requests wurde für Diffs verbessert, die viele Änderungen enthalten.

Die Cachenutzungsrichtlinie des Actions-Repositorys akzeptiert keinen Maximalwert unter 1 mehr für max_repo_cache_size_limit_in_gb.

Beim Bereitstellen von Cacheserverknoten muss jetzt die Rechenzentrumstopologie (mit dem Argument --datacenter) für jeden Knoten im System beschrieben werden. Diese Anforderung verhindert Situationen, in denen das Beibehalten der Standardeinstellung für die Rechenzentrumszugehörigkeit dazu führt, dass Workloads in unangemessener Weise auf mehrere Rechenzentren verteilt werden.

VMware vSphere ESXi Hypervisor Version 7.0 wird jetzt unterstützt. [Aktualisiert: 07.09.2022]

Die Pakete wurden auf die neuesten Sicherheitsversionen aktualisiert.

Ein internes Skript zur Überprüfung von Hostnamen in der GitHub Enterprise Server-Konfigurationsdatei gab einen Fehler zurück, wenn die Hostnamenzeichenfolge mit einem „.“ (Punkt) begann.

In HA-Konfigurationen, bei denen der Hostname des primären Knotens länger als 60 Zeichen war, konnte MySQL nicht konfiguriert werden.

Wenn GitHub Actions aktiviert war, aber TLS auf GitHub Enterprise Server 3.4.1 und höher deaktiviert war, konnte kein Konfigurationsupdate angewendet werden.

Das Argument --gateway wurde dem Befehl ghe-setup-network hinzugefügt, um die Übergabe der Gatewayadresse bei der Konfiguration von Netzwerkeinstellungen über die Befehlszeile zu ermöglichen.

Die Endpunkte der GitHub Advanced Security-Abrechnungs-API waren nicht aktiviert, und es war kein Zugriff darauf möglich.

Bei gelöschten Bildanhängen wurde 500 Internal Server Error anstelle des Fehlers 404 Not Found ausgegeben.

In Umgebungen, die mit einem Repositorycacheserver konfiguriert waren, zeigte der Befehl ghe-repl-status Gists fälschlicherweise als unterrepliziert an.

Die Endpunkte „Abrufen eines Commits“ und „Vergleichen von zwei Commits“ in der Commit-API gaben einen 500-Fehler zurück, wenn ein Dateipfad im Diff ein codiertes Unicodezeichen mit Escapezeichen enthielt.

Die Berechnung der „maximalen Anzahl von Committern in der gesamten Instanz“, die im Administratordashboard der Site angezeigt wurde, war falsch.

Ein falscher Datenbankeintrag für Repositoryreplikate führte zu einer Datenbankbeschädigung, wenn eine Wiederherstellung mit GitHub Enterprise Server Backup Utilities durchgeführt wurde.

Eine GitHub App konnte das secret_scanning_alert_location-Webhookereignis bei einer Installation nicht abonnieren.

Die Aktivitätszeitachse für Geheimnisscanwarnungen wurde nicht angezeigt.

Gelöschte Repositorys wurden nicht nach 90 Tagen gelöscht.

Die Einbeziehung von Metriken bei der Erstellung eines Pakets zur Clusterunterstützung wurde optimiert.

In Hochverfügbarkeitskonfigurationen, in denen Elasticsearch einen gültigen gelben Status meldete, blockierten Änderungen, die in einem früheren Fix eingeführt wurden, den Befehl ghe-repl-stop und verhinderten ein Beenden der Replikation. Mit ghe-repo-stop --force wird nun das Beenden von Elasticsearch erzwungen, wenn sich der Dienst in einem normalen oder gültigen gelben Status befindet.

VMware vSphere ESXi Hypervisor Version 7.0 wird jetzt unterstützt. [Aktualisiert: 07.09.2022]

Du kannst jetzt eine Liste von IP-Adressen konfigurieren, die auf die Anwendungsdienste deiner GitHub Enterprise Server-Instanz zugreifen können, während der Wartungsmodus aktiviert ist. Administratoren, die die Webbenutzeroberfläche der Instanz von einer zugelassenen IP-Adresse aus besuchen, können die Funktionalität der Instanz nach der Wartung und vor dem Deaktivieren des Wartungsmodus validieren. Weitere Informationen findest du unter Wartungsmodus aktivieren und planen.

Mithilfe von benutzerdefinierten Repositoryrollen können Organisationen die den Benutzern gewährten Zugriffsberechtigungen auf das Repository jetzt noch präziser steuern. Weitere Informationen findest du unter Verwalten benutzerdefinierter Repositoryrollen für eine Organisation.

Eine benutzerdefinierte Repositoryrolle wird von einem Organisationsbesitzer erstellt und ist für alle Repositorys in dieser Organisation verfügbar. Jede Rolle kann mit einem benutzerdefinierten Namen und einer Beschreibung versehen werden. Es können über 40 fein abgestufte Berechtigungen konfiguriert werden. Einmal erstellt, können Repositoryadministratoren jedem Benutzer, Team oder externen Mitarbeiter in ihrem Repository eine eigene Rolle zuweisen.

Benutzerdefinierte Repositoryrollen können über die neue Registerkarte Repositoryrollen in den Einstellungen einer Organisation erstellt, angezeigt, bearbeitet und gelöscht werden. Innerhalb einer Organisation können maximal 3 benutzerdefinierte Rollen erstellt werden.

Benutzerdefinierte Repositoryrollen werden auch in den GitHub Enterprise Server-REST-APIs vollständig unterstützt. Mit der Organisations-API können alle benutzerdefinierten Repositoryrollen in einer Organisation aufgelistet werden, und die vorhandenen APIs zum Gewähren von Repositoryzugriff für Einzelpersonen und Teams wurden um die Unterstützung benutzerdefinierter Repositoryrollen erweitert. Weitere Informationen findest du in der REST-API-Dokumentation unter Organisationen.

GitHub Container Registry (GHCR) steht in GitHub Enterprise Server 3.5 ab sofort als öffentliche Betaversion zur Verfügung und bietet Entwicklern die Möglichkeit, Container zu veröffentlichen, herunterzuladen und zu verwalten. Die Containerunterstützung für GitHub-Pakete implementiert die OCI-Standards für das Hosting von Docker-Images. Weitere Informationen findest du unter GitHub Container Registry.

Versions- und Sicherheitsupdates für Dependabot sind ab sofort in GitHub Enterprise Server 3.5 allgemein verfügbar. Alle gängigen Ökosysteme und Features, die für GitHub.com-Repositorys unterstützt werden, kannst du jetzt auch für deine GitHub Enterprise Server-Instanz einrichten. Dependabot in GitHub Enterprise Server erfordert GitHub Actions und einen Pool von selbstgehosteten Dependabot-Runnern, die Aktivierung von GitHub Connect sowie die Aktivierung von Dependabot durch Administrator*innen. Weitere Informationen findest du unter Einrichten von Dependabot-Updates.

Du kannst jetzt analysieren, wie dein Team arbeitet, den Nutzen von GitHub Enterprise Server nachvollziehen und uns dabei helfen, unsere Produkte zu verbessern, indem du die Nutzungsdaten deiner Instanz überprüfst und diese aggregierten Daten mit GitHub teilst. Du kannst zur Analyse deiner Nutzung im Zeitverlauf deine eigenen Tools verwenden, indem du deine Daten in einer CSV- oder JSON-Datei herunterlädst oder über die REST-API darauf zugreifst. Die Liste der gesammelten aggregierten Metriken findest du unter Informationen zu Serverstatistiken. Die Daten der Serverstatistik enthalten weder personenbezogene Daten noch GitHub-Inhalte, wie Code, Issues, Kommentare oder Pull Requests. Weitere Informationen dazu, wie Serverstatistikdaten gespeichert und geschützt werden, findest du unter GitHub-Sicherheit. Weitere Informationen zu Serverstatistiken findest du unter Analysieren der Arbeit deines Teams mit Serverstatistiken. Dieses Feature ist als öffentliche Betaversion verfügbar.

Standortadministratoren können ab sofort eine Ratenbegrenzung für GitHub Actions aktivieren und konfigurieren. In der Standardeinstellung ist die Ratenbegrenzung deaktiviert. Wenn Workflowaufträge nicht sofort einem verfügbaren Runner zugewiesen werden können, werden sie in eine Warteschlange eingereiht, bis ein Runner verfügbar ist. Wenn GitHub Actions jedoch dauerhaft stark ausgelastet ist, kann die Warteschlange schneller anwachsen, als sie abgearbeitet werden kann, und die Leistung der GitHub Enterprise Server-Instanz kann sinken. Um dies zu vermeiden, kann ein Administrator eine Ratenbegrenzung konfigurieren. Wenn die Ratenbegrenzung überschritten wird, schlagen zusätzliche Workflowausführungen sofort fehl, anstatt in die Warteschlange eingereiht zu werden. Sobald sich die Rate unter dem Schwellenwert stabilisiert hat, können wieder neue Ausführungen in die Warteschlange aufgenommen werden. Weitere Informationen findest du unter Konfigurieren von Ratenbegrenzungen.

GitHub Actions in GitHub Enterprise Server unterstützt für sichere Bereitstellungen bei Cloudanbietern ab sofort OIDC, das kurzlebige Token verwendet, die bei jeder Bereitstellung automatisch rotiert werden. OIDC stellt die folgenden Funktionen bereit:

• Nahtlose Authentifizierung zwischen Cloudanbietern und GitHub Enterprise Server, ohne dass du langlebige Cloudgeheimnisse auf deiner Instanz speichern musst
• Cloudadministrator*innen können sich auf die Sicherheitsmechanismen eines bestimmten Cloudanbieters verlassen, um sicherzustellen, dass GitHub Actions-Workflows nur minimalen Zugriff auf Cloudressourcen erhalten. Es gibt keine doppelte Verwaltung von Geheimnissen zwischen GitHub Enterprise Server und der Cloud.

Weitere Informationen findest du unter Sicherheitshärtung für deine Bereitstellungen.

Die Unterstützung für GitHub Actions in internen Repositorys ist jetzt für Organisationen auf der GitHub Enterprise Server-Instanz allgemein verfügbar. Ab sofort kannst du eine Inner-Source-Automatisierung durchführen, indem du Aktionen in internen Repositorys teilst. Du kannst die Einstellungen eines Repositorys verwalten oder die REST-API verwenden, um den Zugriff auf Workflows in anderen Repositorys innerhalb der Organisation oder in einer beliebigen Organisation auf der Instanz zu ermöglichen. Weitere Informationen findest du in der REST-API-Dokumentation unter Freigeben von Aktionen und Workflows für dein Unternehmen, Verwalten von GitHub Actions-Einstellungen für ein Repository und Actions-Berechtigungen.

Du kannst ab sofort die Zwischenspeicherung von Abhängigkeiten nutzen, um deine GitHub Actions-Workflows zu beschleunigen. Zum Zwischenspeichern von Abhängigkeiten für einen Auftrag kannst du die Aktion actions/cache einschließen, um einen Cache mit einem eindeutigen Schlüssel zu erstellen. Du kannst einen Cache für alle Workflows im selben Repository freigeben. Diese Workflows können dann den Cache wiederherstellen und werden schneller ausgeführt.

Actions-Benutzer können zudem unsere Cache-APIs nutzen, um Folgendes zu erreichen:

• Definieren einer Unternehmensrichtlinie für den zulässigen Cachegrößenbereich pro Repository
• Abfragen der Cachenutzung in den einzelnen Repositorys und Überwachen, ob die Gesamtgröße aller Caches die Obergrenze erreicht
• Erhöhen der maximalen Cachegröße für ein Repository innerhalb der zulässigen Unternehmensgrenzen, basierend auf den Cacheanforderungen des Repositorys
• Überwachen der aggregierten Cachenutzung auf Organisations- oder Unternehmensebene

Der in deinem Unternehmenskonto konfigurierte externe Blobspeicher wird jetzt für Workflowartefakte, Protokolle und auch für die Caches freigegeben. Weitere Informationen findest du unter Zwischenspeichern von Abhängigkeiten zum Beschleunigen von Workflows.

Du kannst GitHub Enterprise Server jetzt so konfigurieren, dass in der Webbenutzeroberfläche durchgeführte Commits automatisch signiert werden, z. B. beim Bearbeiten einer Datei oder beim Mergen eines Pull Requests. Signierte Commits erhöhen das Vertrauen, dass Änderungen aus vertrauenswürdigen Quellen stammen. Dieses Feature ermöglicht die Branchschutzeinstellung Signierte Commits erforderlich, die verhindert, dass nicht signierte Commits in ein Repository gelangen, und gleichzeitig den Eingang signierter Commits zulässt – auch solcher Commits, die auf der Weboberfläche durchgeführt wurden. Weitere Informationen findest du unter „Konfigurieren der Webcommitsignierung“.

Kund*innen, die die Lizenznutzung zwischen GitHub Enterprise Server und GitHub Enterprise Cloud automatisch über GitHub Connect synchronisieren, haben jetzt die Möglichkeit, ihre Lizenznutzung unabhängig von der automatischen wöchentlichen Synchronisierung zu synchronisieren. Dieses Feature meldet auch den Status des Synchronisierungsauftrags. Weitere Informationen findest du unter Synchronisieren der Lizenzverwendung zwischen GitHub Enterprise Server und GitHub Enterprise Cloud.

Wiederverwendbare Workflows sind jetzt allgemein verfügbar. Wiederverwendbare Workflows helfen dir, doppelte Arbeit zu vermeiden, indem du einen gesamten Workflow wie eine Aktion wiederverwenden kannst. Mit dem GA-Release stehen ab sofort einige Verbesserungen für GitHub Enterprise Server zur Verfügung. Weitere Informationen findest du unter Wiederverwenden von Workflows.

• Du kannst Ausgaben nutzen, um Daten aus wiederverwendbaren Workflows an andere Aufträge im aufrufenden Workflow zu übergeben.
• Du kannst Umgebungsgeheimnisse an wiederverwendbare Workflows übergeben.
• Das Überwachungsprotokoll enthält Informationen dazu, welche wiederverwendbaren Workflows genutzt werden.
• Wiederverwendbare Workflows, die sich im selben Repository wie das aufrufende Repository befinden, können nur mit dem Pfad und dem Dateinamen (PATH/FILENAME) referenziert werden. Der aufgerufene Workflow stammt aus demselben Commit wie der aufrufende Workflow.

Du hast ab sofort mehr Kontrolle darüber, wann deine selbstgehosteten Runner Softwareupdates durchführen. Wenn du den Runner mit dem Flag --disableupdate versiehst, wird bei Verfügbarkeit einer neueren Version des Runners kein automatisches Softwareupdate durchgeführt. So kannst du den selbstgehosteten Runner nach deinem eigenen Zeitplan aktualisieren. Dies ist besonders praktisch, wenn sich dein selbstgehosteter Runner in einem Container befindet.

Um Kompatibilität mit dem GitHub Actions-Dienst zu gewährleisten, musst du deine Runnerversion innerhalb von 30 Tagen nach der Veröffentlichung einer neuen Version aktualisieren. Anweisungen zum Installieren der neuesten Runnerversion findest du in den Installationsanweisungen für das neueste Release im Runner-Repository.

Organisationsbesitzer können ab sofort die Sicherheit von CI/CD-Workflows für selbstgehostete Runner erhöhen, indem sie festlegen, welche Workflows auf eine Runnergruppe zugreifen dürfen. Bisher konnte jeder Workflow in einem Repository, z. B. ein Workflow zur Kennzeichnung von Issues, auf die selbstgehosteten Runner zugreifen, die einer Organisation zur Verfügung stehen. Weitere Informationen findest du unter Verwalten des Zugriffs auf selbstgehostete Runner mithilfe von Gruppen und im GitHub-Blog.

Ab sofort kannst du steuern, ob GitHub Actions Pull Requests genehmigen kann. Mit dieser Funktion wird verhindert, dass ein Benutzer GitHub Actions nutzt, um die Anforderung erforderlicher Genehmigungen zum Branchschutz zu erfüllen und eine Änderung mergen kann, die nicht von einem anderen Benutzer geprüft wurde. Um Breaking Changes für vorhandene Workflows zu vermeiden, ist standardmäßig die Option Anrechnung von GitHub Actions-Reviews auf die erforderliche Genehmigung zulassen aktiviert. Organisationsbesitzer können das Feature in den GitHub Actions-Einstellungen der Organisation deaktivieren. Weitere Informationen findest du unter Deaktivieren oder Einschränken von GitHub Actions für deine Organisation.

Ab sofort kannst du nur die fehlgeschlagenen Aufträge oder einen einzelnen Auftrag in einem GitHub Actions-Workflow erneut ausführen. Weitere Informationen findest du unter Erneutes Ausführen von Workflows und Aufträgen.

Das Abhängigkeitsdiagramm erkennt jetzt YAML-Dateien für GitHub Actions-Workflows. GitHub Enterprise Server zeigt die Workflowdateien im Abschnitt mit dem Abhängigkeitsdiagramm auf der Registerkarte Erkenntnisse an. Repositorys, die Aktionen veröffentlichen, können zudem über das Kontrollkästchen „Verwendet von“ auf der Startseite des Repositorys die Anzahl der Repositorys anzeigen, die von dieser Aktion abhängen. Weitere Informationen findest du unter Informationen zum Abhängigkeitsdiagramm.

• Hinweis: Dieses Feature war in GitHub Enterprise Server 3.5.0, 3.5.1, 3.5.2 und 3.5.3 nicht verfügbar. Das Feature ist ab Version 3.5.4 verfügbar. [Aktualisiert: 2022-08-16]

GitHub Advanced Security-Kunden können ab sofort eine Übersicht der Sicherheitswarnungen auf Unternehmensebene anzeigen. Die neue Registerkarte Sicherheit auf Unternehmensebene bietet eine auf das Repository bezogene Übersicht über die Sicherheitsrisiken von Anwendungen sowie eine warnungsbezogene Übersicht über sämtliche Geheimnisüberprüfungswarnungen. Weitere Informationen findest du unter Informationen zur Sicherheitsübersicht.

Die Übersicht der Sicherheitswarnungen auf Organisationsebene ist jetzt allgemein verfügbar. GitHub Advanced Security-Kunden können ab sofort die Sicherheitsübersicht nutzen, um eine auf das Repository bezogene Ansicht der Anwendungssicherheitsrisiken oder eine warnungsbezogene Ansicht aller Warnungen zu Codeüberprüfungen, Dependabot und Geheimnisüberprüfungen für alle Repositorys in einer Organisation anzuzeigen. Weitere Informationen findest du unter Informationen zur Sicherheitsübersicht.

Die Codeüberprüfung erkennt ab sofort eine größere Anzahl von CWEs (Common Weakness Enumeration), und die CodeQL-Codeüberprüfung unterstützt die Standardsprachfunktionen in den folgenden Sprachversionen vollständig.

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

Weitere Informationen findest du im GitHub-Blog.

GitHub Advanced Security-Kundinnen können jetzt Warnungen zur Codeüberprüfung auf der Registerkarte Sicherheit einer Organisation anzeigen. Diese Ansicht steht Organisationsbesitzerinnen und Mitgliedern von Teams mit der Rolle Sicherheits-Manager zur Verfügung. Weitere Informationen findest du unter Informationen zur Sicherheitsübersicht.

Benutzer können jetzt über die REST-API Codeüberprüfungswarnungen für eine Organisation auf ihrer GitHub Enterprise Server-Instanz abrufen. Dieser neue API-Endpunkt ergänzt den vorhandenen Endpunkt für Repositorys. Weitere Informationen findest du in der REST-API-Dokumentation unter Codeüberprüfung.

GitHub Enterprise Server kann jetzt alle Pushvorgänge blockieren, bei denen eine hohe Wahrscheinlichkeit besteht, dass ein Token enthalten ist. Entwickler können die Sperre umgehen, indem sie über eine Webbenutzeroberfläche Informationen dazu bereitstellen, warum das Geheimnis übertragen werden muss. Weitere Informationen findest du unter Schützen von Pushs mit Geheimnisüberprüfung.

GitHub Advanced Security-Kunden können ab sofort Probeläufe für benutzerdefinierte Muster mit Geheimnisüberprüfung auf Organisations- oder Repositoryebene durchführen. Probeläufe ermöglichen es Benutzern mit Besitzer- oder Administratorrechten, ihre Muster zu überprüfen und zu verfeinern, bevor sie diese veröffentlichen und Warnungen generieren. Du kannst ein Muster zusammenstellen und dann Speichern und Probelauf verwenden, um die Ergebnisse abzurufen. Die Überprüfungen dauern in der Regel nur wenige Sekunden, aber GitHub Enterprise Server benachrichtigt die Organisationsbesitzer oder Repositoryadministratoren auch per E-Mail, wenn die Ergebnisse des Probelaufs vorliegen. Weitere Informationen findest du unter Informationen zu Geheimnisüberprüfungen und Definieren benutzerdefinierter Muster für Geheimnisüberprüfungen.

Das Überwachungsprotokoll enthält ab sofort Ereignisse, die mit benutzerdefinierten Mustern für die Geheimnisüberprüfung in Zusammenhang stehen. Diese Daten helfen GitHub Advanced Security-Kund*innen, Aktionen zu verstehen, die für ihre benutzerdefinierten Muster auf Repository-, Organisations- oder Unternehmensebene für Sicherheits- und Complianceüberprüfungen ausgeführt werden. Weitere Informationen findest du unter Überprüfen des Überwachungsprotokolls für deine Organisation und Überprüfen von Überwachungsprotokollen für dein Unternehmen.

Beim Verwalten von benutzerdefinierten Repositoryrollen kannst du ab sofort zwei neue Berechtigungen für die Geheimnisüberprüfung konfigurieren.

• Ergebnisse von Geheimnisüberprüfungen anzeigen
• Ergebnisse von Geheimnisüberprüfungen verwerfen oder erneut öffnen

Weitere Informationen findest du unter Verwalten benutzerdefinierter Repositoryrollen für eine Organisation.

GitHub Advanced Security-Kunden können jetzt über die Benutzeroberfläche und die API die Geheimnisüberprüfung für archivierte Repositorys aktivieren. Weitere Informationen findest du unter Informationen zur Geheimnisüberprüfung, Informationen zu archivierten Repositorys und Repositorys in der REST-API-Dokumentation.

GitHub Advanced Security-Kunden, die die Geheimnisüberprüfung nutzen, können ab sofort festlegen, dass sie jedes Mal einen Webhook erhalten, wenn ein Geheimnis an einem neuen Standort erkannt wird. Das secret_scanning_alert_location-Webhookereignis enthält Standortdetails, z. B. den Commit-SHA, sowie die zugehörige Warnung für die Erkennung. Es wird ein Standort für jeden neuen Dateipfad erstellt, der das erkannte Geheimnis enthält. Weitere Informationen findest du unter Webhookereignisse und Nutzdaten.

GitHub Advanced Security-Kundinnen können jetzt Dependabot-Warnungen auf der Registerkarte Sicherheit einer Organisation anzeigen. Diese Ansicht steht Organisationsbesitzerinnen und Mitgliedern von Teams mit der Rolle Sicherheits-Manager zur Verfügung. Weitere Informationen findest du unter Informationen zur Sicherheitsübersicht.

Beim Verwalten von benutzerdefinierten Repositoryrollen kannst du ab sofort zwei neue Berechtigungen für Dependabot-Warnungen konfigurieren.

• Anzeigen von Dependabot-Warnungen
• Dependabot-Warnungen verwerfen oder erneut öffnen

Weitere Informationen findest du unter Verwalten benutzerdefinierter Repositoryrollen für eine Organisation.

Du kannst verworfene Dependabot-Warnungen ab sofort über die Benutzeroberflächenseite für geschlossene Warnungen erneut öffnen. Dies hat keine Auswirkungen auf Dependabot-Pull Requests oder die GraphQL-API. Weitere Informationen findest du unter Informationen zu Dependabot-Warnungen."

• Hinweis: Dieses Feature war in GitHub Enterprise Server 3.5.0, 3.5.1, 3.5.2 und 3.5.3 nicht verfügbar. Das Feature ist ab Version 3.5.4 verfügbar. [Aktualisiert: 2022-08-16]

Benutzer von Dependabot-Versionsupdates können ab sofort proaktiv Abhängigkeiten für Flutter- oder Dart-Projekte aktualisieren, die den Pub-Paket-Manager verwenden.

Um Versionsupdates in deinem eigenen Dart- oder Flutter-Repository zu testen, fügst du in .github/dependabot.yaml die folgende Konfigurationsdatei hinzu. Beachte die Flags package-ecosystem: "pub" und enable-beta-ecosystems: true.

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

Mit dem neuen GraphQL-Objekt DependabotUpdate kannst du Informationen zu den Sicherheitsupdates für dein Repository anzeigen. Wenn GitHub Enterprise Server feststellt, dass eine Abhängigkeit in deinem Repository anfällig ist, versucht Dependabot, einen Pull Request zu öffnen, um diese Abhängigkeit auf eine Version ohne Sicherheitsrisiko zu aktualisieren. Ab sofort kannst du den Pull Request sehen, der das Sicherheitsrisiko behebt. In einigen Fällen gelingt es Dependabot nicht, einen Pull Request zu öffnen. Zuvor war die von Dependabot generierte Fehlermeldung nur im Abschnitt „Dependabot-Warnungen“ auf der Registerkarte Sicherheit sichtbar. Wenn nun beim Versuch, einen Pull Request für eine Sicherheitswarnung zu öffnen, bei Dependabot ein Fehler auftritt, kannst du den Grund mithilfe der GraphQL-API ermitteln. Weitere Informationen findest du in der GraphQL-API-Dokumentation unter Objekte.

Du kannst ab sofort mithilfe der GraphQL-API behobene Dependabot-Warnungen anzeigen. Du kannst außerdem nach Zustand und eindeutigem numerischen Bezeichner suchen und filtern und nach dem Zustand des Objekts für die Sicherheitsrisikowarnung filtern. Die folgenden Felder sind jetzt für eine RepositoryVulnerabilityAlert verfügbar.

• number
• fixed_at
• fix_reason
• state

Weitere Informationen findest du in der GraphQL-API-Dokumentation unter Objekte.

Die folgenden Git-bezogenen Ereignisse sind ab sofort im Überwachungsprotokoll des Unternehmens enthalten. Wenn du das Feature aktivierst und eine Aufbewahrungsdauer für das Überwachungsprotokoll festlegst, stehen die neuen Ereignisse für die Suche über die Benutzeroberfläche und die API oder für den Export über JSON oder CSV zur Verfügung.

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

Aufgrund der großen Anzahl der protokollierten Git-Ereignisse empfehlen wir dir, den Dateispeicher deiner Instanz zu überwachen und die zugehörigen Warnungskonfigurationen zu überprüfen. Weitere Informationen findest du unter Konfigurieren des Überwachungsprotokolls für dein Unternehmen.

Dieses Release enthält Verbesserungen für CODEOWNERS.

• Syntaxfehler werden jetzt angezeigt, wenn du eine CODEOWNERS-Datei aus dem Internet anzeigst. Bisher wurden Syntaxfehler in einer Zeile einer CODEOWNERS-Datei ignoriert oder führten in manchen Fällen dazu, dass die gesamte CODEOWNERS-Datei nicht geladen wurde. GitHub-Apps und -Aktionen können über neue REST- und GraphQL-APIs auf diese Fehlerliste zugreifen. Weitere Informationen findest du in der REST-API-Dokumentation unter Repositorys und in der GraphQL-API-Dokumentation unter Objekte.
• Wenn jemand einen neuen Pull Request erstellt oder neue Änderungen an einem Pull Request-Entwurf pusht, werden jetzt alle Codebesitzer*innen, die zum Review aufgefordert werden, im Pull Request unter „Reviewer“ aufgeführt. Mit diesem Feature kannst du frühzeitig sehen, wer zum Review aufgefordert wird, sobald der Pull Request als prüfungsbereit markiert wird.
• Kommentare in CODEOWNERS-Dateien können jetzt am Ende einer Zeile, nicht nur auf dedizierten Zeilen angezeigt werden.

Weitere Informationen findest du unter Informationen zu Codebesitzern.

Mit der Schaltfläche Branch aktualisieren auf der Pull Request-Seite kannst du den Branch deines Pull Requests mit den neuesten Änderungen aus dem Basisbranch aktualisieren. Dies ist nützlich, um vor dem Mergen sicherzustellen, dass deine Änderungen mit der aktuellen Version des Basisbranchs kompatibel sind. Zwei Verbesserungen bieten dir jetzt mehr Möglichkeiten, deinen Branch auf dem neuesten Stand zu halten.

• Wenn der Topic-Branch deines Pull Requests nicht mehr mit dem Basisbranch übereinstimmt, kannst du ihn jetzt aktualisieren, indem du ein Rebase auf die neueste Version des Basisbranchs ausführst. Beim Rebase werden die Änderungen aus deinem Branch auf die neueste Version des Basisbranchs angewendet, was zu einem Branch mit linearem Verlauf führt, da kein Mergecommit erstellt wird. Klicke zur Aktualisierung per Rebase auf das Dropdownmenü neben der Schaltfläche Branch aktualisieren, klicke auf Durch Rebase aktualisieren und dann auf Rebase für Branch ausführen. Bisher wurde über Branch aktualisieren ein herkömmlicher Mergevorgang ausgeführt, der immer zu einem Mergecommit in deinem Pull Request-Branch führte. Diese Option ist weiterhin verfügbar, aber du hast jetzt die Wahl. Weitere Informationen findest du unter Synchronisieren eines Pull Requests mit dem Basisbranch.

• Eine neue Repositoryeinstellung ermöglicht es, dass die Schaltfläche Branch aktualisieren immer dann verfügbar ist, wenn der Topic-Branch eines Pull Requests nicht auf demselben Stand ist wie der Basisbranch. Bisher war diese Schaltfläche nur verfügbar, wenn die Branchschutzeinstellung Aktualität der Branches vor dem Mergen erforderlich aktiviert war. Benutzer*innen mit Administrator- oder Maintainerzugriff können die Einstellung Immer Aktualisierung von Pull Request-Branches vorschlagen im Abschnitt Pull Requests in den Repositoryeinstellungen verwalten. Weitere Informationen findest du unter Verwalten von Vorschlägen zum Aktualisieren von Pull Request-Branches.

  • Hinweis: Dieses Feature war in GitHub Enterprise Server 3.5.0, 3.5.1, 3.5.2 und 3.5.3 nicht verfügbar. Das Feature ist ab Version 3.5.4 verfügbar. [Aktualisiert: 2022-08-16]

Ab sofort kannst du benutzerdefinierte HTTP-Header konfigurieren, die für alle GitHub Pages-Seiten gelten, die von deiner GitHub Enterprise Server-Instanz bereitgestellt werden. Weitere Informationen findest du unter Konfigurieren von GitHub Pages für dein Unternehmen.

Es ist jetzt möglich, Revisionen in der Blame-Ansicht zu ignorieren, indem du eine Datei .git-blame-ignore-revs im Stammverzeichnis deines Repositorys erstellst. Weitere Informationen findest du unter Anzeigen einer Datei.

Ab sofort ist ein helles Design mit hohem Kontrast allgemein verfügbar, bei dem der Kontrast zwischen Vorder- und Hintergrundelementen verstärkt wurde. Weitere Informationen findest du unter Verwalten deiner Designeinstellungen.

• Hinweis: Dieses Feature war in GitHub Enterprise Server 3.5.0, 3.5.1, 3.5.2 und 3.5.3 nicht verfügbar. Das Feature ist ab Version 3.5.4 verfügbar. [Aktualisiert: 2022-08-16]

Repositorybesitzer können ab sofort Tagschutzregeln konfigurieren, um die Tags eines Repositorys zu schützen. Sobald Tags durch eine Tagschutzregel geschützt wurden, können Tags mit einem bestimmten Namensmuster nur noch von Benutzern mit Maintainer- oder Administratorrolle im Repository erstellt und gelöscht werden. Weitere Informationen findest du unter Konfigurieren von Tagschutzregeln.

In GitHub Mobile für iOS 1.80.0 und höher können Benutzer*innen jetzt Dateien im Topic-Branch eines Pull Requests bearbeiten. Unterstützung für das Bearbeiten von Dateien wird in GitHub Mobile für Android in einem zukünftigen Release hinzugefügt. [Aktualisiert: 13.09.2022]

Ab sofort können GitHub-Apps Releaseressourcen hochladen.

Die Mindestanforderungen für Stammspeicher und Arbeitsspeicher wurden für GitHub Enterprise Server 2.10 und 3.0 erhöht und werden jetzt ab Version 3.5.0 erzwungen.

• In Version 2.10 wurde die Mindestanforderung für Stammspeicher von 80 GB auf 200 GB erhöht. Ab Version 3.5.0 führen Preflightüberprüfungen des Systems zu Fehlern, wenn der Stammspeicher kleiner als 80 GB ist.
• In Version 3.0 wurde die Mindestanforderung für Arbeitsspeicher von 16 GB auf 32 GB erhöht. Ab Version 3.5.0 führen Preflightüberprüfungen des Systems zu Fehlern, wenn das System über weniger als 28 GB Arbeitsspeicher verfügt.

Weitere Informationen findest du in den Mindestanforderungen für jede unterstützte Bereitstellungsplattform unter Einrichten einer GitHub Enterprise Server-Instanz. [Aktualisiert: 20.06.2022]

VMware vSphere ESXi Hypervisor Version 7.0 wird jetzt unterstützt. [Aktualisiert: 07.09.2022]

Um den Geräteautorisierungsflow für OAuth und GitHub-Apps zu nutzen, musst du das Feature manuell aktivieren. Diese Änderung verringert die Wahrscheinlichkeit, dass Apps für Phishingangriffe gegen GitHub Enterprise Server-Benutzer verwendet werden, da die Integratoren sich der Risiken bewusst sind und sich bewusst für diese Form der Authentifizierung entscheiden. Wenn du eine OAuth-App oder GitHub-App besitzt oder verwaltest und den Geräteflow nutzen möchtest, kannst du ihn für deine App über die Einstellungsseite der App aktivieren. Die Endpunkte der Geräteflow-API reagieren mit dem Statuscode 400 auf Apps, bei denen dieses Feature nicht aktiviert ist. Weitere Informationen findest du unter Autorisieren von OAuth-Apps.

Auf der Seite für Codeüberprüfungswarnungen werden jetzt immer der Warnstatus und die Informationen für den Standardbranch angezeigt. Es gibt einen neuen Bereich „Betroffene Branches“ in der Seitenleiste, in dem du den Status der Warnung in anderen Branches sehen kannst. Wenn die Warnung nicht in deinem Standardbranch vorhanden ist, wird auf der Warnungsseite der Status „In Branch“ oder „In Pull Request“ für den Standort angezeigt, an dem die Warnung zuletzt ausgegeben wurde. Diese Verbesserung macht es einfacher, den Status von Warnungen zu verstehen, die in deine Codebasis aufgenommen wurden. Weitere Informationen findest du unter Informationen zu Codeüberprüfungswarnungen.

Die Seite mit der Warnungsliste wird nicht geändert und kann nach branch gefiltert werden. Du kannst die Codeüberprüfungs-API verwenden, um detailliertere Branchinformationen für Warnungen abzurufen. Weitere Informationen findest du in der REST-API-Dokumentation unter Codeüberprüfung.

Bei der Codeüberprüfung werden jetzt Details zur Analysequelle einer Warnung angezeigt. Wenn eine Warnung mehr als einen Analyseursprung hat, wird dies in der Seitenleiste „Betroffene Branches“ und in der Zeitleiste der Warnung angezeigt. Du kannst in der Seitenleiste „Betroffene Branches“ mit der Maus auf das Symbol des Analyseursprungs zeigen, um den Warnungsstatus in jedem Analyseursprung anzuzeigen. Wenn eine Warnung nur einen einzigen Analyseursprung hat, werden auf der Warnungsseite keine Informationen zum Analyseursprung angezeigt. Diese Verbesserungen machen es einfacher, deine Warnmeldungen zu verstehen. Insbesondere kannst du damit Warnungen besser nachvollziehen, die über mehrere Analyseursprünge verfügen. Dies ist besonders nützlich für Setups mit mehreren Analysekonfigurationen, wie z. B. Monorepositorys. Weitere Informationen findest du unter Informationen zu Codeüberprüfungswarnungen.

Listen mit Repositorys, die einem Benutzer oder einer Organisation gehören, verfügen jetzt über eine zusätzliche Filteroption „Vorlagen“, die das Auffinden von Vorlagenrepositorys erleichtert.

GitHub Enterprise Server kann zahlreiche gängige Bildformate anzeigen, darunter PNG, JPG, GIF, PSD und SVG, und bietet verschiedene Möglichkeiten, Unterschiede zwischen Versionen zu vergleichen. Wenn du hinzugefügte oder geänderte Bilder in einem Pull Request überprüfst, wird jetzt standardmäßig eine Vorschau für diese Bilder angezeigt. Bisher wurde in einer Meldung darauf hingewiesen, dass Binärdateien nicht angezeigt werden können und dass die Option „Rich-Diff anzeigen“ umgeschaltet werden muss. Weitere Informationen findest du unter Arbeiten mit Nicht-Codedateien.

Neue Gists werden jetzt mit dem Standardbranchnamen main oder dem alternativen Standardbranchnamen erstellt, den du in deinen Benutzereinstellungen festgelegt hast. Dies entspricht der Art und Weise, wie andere Repositorys in GitHub Enterprise Server erstellt werden. Weitere Informationen findest du unter Informationen zu Branches und Verwalten des Standardbranchnamens für deine Repositorys.

Gists zeigen bei der erstmaligen Anzeige jetzt nur noch die 30 neuesten Kommentare an. Du kannst auf Frühere Kommentare laden klicken, um weitere Kommentare anzuzeigen. So können Gists mit vielen Kommentaren schneller angezeigt werden. Weitere Informationen findest du unter Bearbeiten und Freigeben von Inhalten mit Gists.

Die Einstellungsseiten für Benutzer, Organisationen, Repositorys und Teams wurden neu gestaltet und gruppieren ähnliche Einstellungsseiten in Abschnitte, um die Informationsarchitektur und Auffindbarkeit zu verbessern. Weitere Informationen findest du im GitHub-Änderungsprotokoll.

Wenn du mit der Maus auf eine Beschriftung zeigst, wird jetzt die Beschreibung der Beschriftung in einer QuickInfo angezeigt.

Das Erstellen und Entfernen von Repositoryeinladungen (ob über die API oder die Webbenutzeroberfläche) unterliegt jetzt den Ratenbegrenzungen, die möglicherweise für deine GitHub Enterprise Server-Instanz aktiviert sind. Weitere Informationen zu Ratenbegrenzungen findest du unter Konfigurieren von Ratenbegrenzungen.

MinIO hat angekündigt, dass die MinIO-Gateways ab dem 1. Juni 2022 eingestellt werden. Auch wenn „MinIO-Gateway für NAS“ weiterhin zu den unterstützten Speicheranbietern für Github-Aktionen und Github-Pakete gehören, empfehlen wir, auf den MinIO-LTS-Support umzusteigen, um Support und Fehlerbehebungen von MinIO zu erhalten. Weitere Informationen zu Ratenbegrenzungen findest du unter Geplantes Entfernen von MinIO-Gateways für GCS, Azure, HDFS im Repository „minio/minio“.

Da das Format von GitHub-Authentifizierungstoken geändert wird, funktioniert GitHub Connect nach dem 3. Juni nicht mehr für Instanzen, auf denen GitHub Enterprise Server 3.1 oder früher ausgeführt wird. Wenn du GitHub Connect weiterhin nutzen möchtest, musst du ein Upgrade auf GitHub Enterprise Server 3.2 oder höher durchführen. Weitere Informationen findest du im GitHub-Blog. [Aktualisiert: 14.06.2022]

Der CodeQL-Runner wird zugunsten der CodeQL CLI eingestellt. Ab GitHub Enterprise Server 3.4 ist der CodeQL-Runner nicht mehr enthalten. Dies betrifft ausschließlich Benutzer, die die CodeQL-Codeüberprüfung in CI/CD-Systemen von Drittanbietern nutzen. GitHub Actions-Benutzer sind nicht betroffen. GitHub empfiehlt dringend, dass Kunden eine Migration zur CodeQL CLI durchführen. Diese CLI ist ein vollumfänglicher Ersatz für den CodeQL-Runner und umfasst zahlreiche zusätzliche Features. Weitere Informationen findest du unter Migrieren vom CodeQL-Runner zur CodeQL-CLI.

Die Designauswahl für GitHub Pages wurde aus den Seiteneinstellungen entfernt. Weitere Informationen zur Konfiguration von Designs für GitHub Pages findest du unter Hinzufügen eines Designs zu deiner GitHub Pages-Website mithilfe von Jekyll.