Enterprise Server 3.4 release notes

HOCH: Behebung eines eine falsche Authentifizierung betreffenden Sicherheitsrisikos, das Unbefugten ermöglichte, die geheimen Gists anderer Benutzer*innen zu ändern, indem sie sich über eine SSH-Zertifizierungsstelle authentifizierten. Dieses Sicherheitsrisiko wurde über das  GitHub Bug Bounty-Programm gemeldet und CVE-2023-23761 zugewiesen. [Aktualisiert: 07.04.2023]

MITTEL: Behebung eines falsche Vergleiche betreffenden Sicherheitsrisikos, das Smuggling-Committen durch Anzeige einer falschen Differenz ermöglichte. Dieses Sicherheitsrisiko wurde über das  GitHub Bug Bounty-Programm gemeldet und CVE-2023-23762 zugewiesen. [Aktualisiert: 07.04.2023]

Im Überwachungsdashboard der Verwaltungskonsole wurden in den Graphen Cached Requests und Served Requests, die mithilfe des Befehls git fetch catching abgerufen werden, keine Metriken für die Instanz angezeigt.

Nachdem ein Websiteadministrator bzw. eine Websiteadministratorin den Benutzer bzw. die Benutzerin @github-actions[Bot] mithilfe des Befehls ghe-config app.github.rate-limiting-exempt-users "github-actions[bot]" von der Ratenbegrenzung ausgenommen hatte, wurde beim Ausführen von ghe-config-check die Warnung Validation is-valid-characterset failed angezeigt.

GitHub Actions (actions) und Microsoft SQL (mssql) wurden in der Liste der Prozesse auf dem Überwachungsdashboard der Instanzen nicht angezeigt.

Wenn ein Administrator bzw. eine Administratorin bei einer Instanz in einer Hochverfügbarkeitskonfiguration die Replikation von einem Replikatknoten mithilfe von ghe-repl-teardown direkt nach dem Ausführen von ghe-repl-setup, aber noch vor ghe-repl-start entfernt hat, trat folgender Fehler für das Skript auf: cannot launch /usr/local/bin/ghe-single-config-apply - run is locked. ghe-repl-teardown zeigt jetzt eine Informationsmeldung an und setzt den Entfernungsvorgang fort.

Wenn ein Websiteadministrator bzw. eine Websiteadministratorin bei einer Instanz in einer Clusterkonfiguration mithilfe von ghe-maintenance -s den Wartungsmodus festgelegt hat, wurde ein Fehler vom Typ Permission denied angezeigt, als das Hilfsprogramm versuchte, auf /data/user/common/cluster.conf zuzugreifen.

Wenn ein Websiteadministrator bzw. eine Websiteadministratorin ghe-migrator verwendet hat, um Daten zu GitHub Enterprise Server zu migrieren, sind nach dem Importieren von Teams in einigen Fällen geschachtelte Teambeziehungen verloren gegangen.

GitHub Enterprise Server hat Verteilungsmetriken veröffentlicht, die nicht von collectd verarbeitet werden können. Zu den Metriken zählten pre_receive.lfsintegrity.dist.referenced_oids, pre_receive.lfsintegrity.dist.unknown_oids und git.hooks.runtime.

Nachdem eine Unternehmensbesitzerin Dependabot-Updates aktiviert hat, erstellt die Instanz die anfänglichen Updates schneller.

Wenn ein Websiteadministrator bzw. eine Websiteadministratorin in einer Instanz in einer Clusterkonfiguration mithilfe von ghe-maintenance -s den Wartungsmodus für einen einzelnen Clusterknoten festlegt, wird der Administrator bzw. die Administratorin durch eine Warnung des Hilfsprogramms aufgefordert, ghe-cluster-maintenance -s zu verwenden, um den Wartungsmodus für alle Clusterknoten festzulegen. Weitere Informationen findest du unter Wartungsmodus aktivieren und planen.

Wenn ein Websiteadministrator bzw. eine Websiteadministratorin einen ausgehenden Webproxyserver für GitHub Enterprise Server konfiguriert, überprüft die Instanz jetzt Domänen der obersten Ebene (Top-Level Domains, TLDs), die von der Proxykonfiguration ausgeschlossen wurden. Standardmäßig kannst du öffentliche TLDs ausschließen, die von der IANA angegeben werden. Websiteadministrator*innen können mithilfe von ghe-config eine Liste nicht registrierter TLDs angeben, die ausgeschlossen werden sollen. Das Präfix . ist für alle öffentlichen TLDs erforderlich. Beispiel: .example.com ist gültig, example.com jedoch ungültig. Weitere Informationen findest du unter Konfigurieren eines ausgehenden Webproxyservers.

Der Standardpfad für die Ausgabe von ghe-saml-mapping-csv -d ist /data/user/tmp (anstatt /tmp). Weitere Informationen findest du unter Befehlszeilenprogramme.

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ötigte ein Angreifer die Berechtigung, eine GitHub Pages-Website in der GitHub Enterprise Server-Instanz zu erstellen. Dieses Sicherheitsrisiko wurde über das GitHub Bug Bounty-Programm gemeldet und CVE-2023-23760 zugewiesen. [Aktualisiert: 10.03.2023]

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

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.

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

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

Wenn GitHub Actions mit S3-Blobspeicher für die Instanz konfiguriert wurde, verblieben Inhalte wie Protokolle und Artefakte aus gelöschten oder abgelaufenen Workflowausführungen auf unbestimmte Zeit im Blobspeicher. Die Instanz löscht diese Inhalte automatisch beim nächsten regulären Hintergrundbereinigungsauftrag.

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.

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

In einigen Fällen konnten Benutzer*innen einen Pull Request aufgrund unerwarteter Statusüberprüfungen nicht mergen.

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

Zombieprozesse werden nicht mehr im Container gitrpcd gesammelt.

HOCH: Die Abhängigkeiten für die Verwaltungskonsole wurden auf die neuesten Patchversionen aktualisiert, die Sicherheitsrisiken wie CVE-2022-30123 und CVE-2022-29181 beheben.

HOCH: Es wurden Überprüfungen hinzugefügt, um ein Sicherheitsrisiko durch fehlerhafte Cacheschlüssel zu beheben, die nicht autorisierten Akteur*innen ermöglichte, über ein öffentliches Repository auf private Repositorydateien zuzugreifen. Dieses Sicherheitsrisiko wurde CVE-2022-23738 zugewiesen.

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: Redis wurde auf Version 5.0.14 aktualisiert, um CVE-2021-32672 und CVE-2021-32762 zu beheben.

MITTEL: GitHub Actions-Runner wurden aktualisiert, um einen Fehler zu beheben, der es Umgebungsvariablen in GitHub Actions-Aufträgen ermöglichte, den Kontext der Variablen zu verlassen und den Aufruf von docker-Befehlen direkt zu ändern. Weitere Informationen findest du in der Sicherheitsempfehlung für Actions-Runner.

MITTEL: In GitHub Enterprise Server wurde ein Sicherheitsrisiko bei der Berechtigungsverwaltung festgestellt, die es Benutzerinnen mit unzulässigen Rechten ermöglichte, Seiten über die API zu erstellen oder zu löschen. Um dieses Sicherheitsrisiko auszunutzen, mussten Angreiferinnen dem Repository einer Organisation mit Schreibberechtigungen hinzugefügt werden. Dieses Sicherheitsrisiko wurde über das GitHub Bug Bounty-Programm gemeldet und CVE-2022-23737 zugewiesen.

NIEDRIG: Aufgrund eines CSRF-Sicherheitsrisikos kann eine GET-Anforderung an den site/toggle_site_admin_and_employee_status-Endpunkt der Instanz den Websiteadministratorstatus von Benutzer*innen unwissentlich umschalten.

Die Pakete wurden auf die neuesten Sicherheitsversionen aktualisiert.

Nachdem Standortadministrator*innen eine Änderung vorgenommen hatten, die eine Konfigurationsausführung ausgelöst hat (z. B. das Deaktivieren von GitHub Actions), führte die Überprüfung von Diensten manchmal zu einem Fehler mit der Meldung WARNING: Validation encountered a problem.

Nachdem Websiteadministrator*innen einen Hotpatch installiert hatten, der Änderungen an Webschnittstellenressourcen wie JavaScript-Dateien oder -Images enthielt, hat die Instanz die neuen Ressourcen nicht bereitgestellt.

Wenn Benutzer*innen mithilfe von Git auf ein umbenanntes Repository zugegriffen haben, hat der Hostname in der Git-Ausgabe fälschlicherweise GitHub.com anstelle des Hostnamens der Instanz angegeben.

Das Bereinigen von gelöschten Ressourcen und Ressourcen, die für die Löschung aus einem Repository markiert waren (z. B. LFS-Dateien), dauerte zu lange.

Wenn Benutzer*innen eine GitHub-App für das Benutzerkonto installiert und das Konto dann in eine Organisation konvertiert hatten, wurden der App keine Organisationsberechtigungen zugewiesen.

Um sicherzustellen, dass Standortadministrator*innen ein Upgrade erfolgreich abschließen können, führt die Instanz nun eine Preflightüberprüfung durch, um sicherzustellen, dass die VM die Mindestanforderungen an die Hardware erfüllt. Dabei wird auch die Integrität von Elasticsearch überprüft. Die aktuellen Anforderungen für CPU, Arbeitsspeicher und Speicher für GitHub Enterprise Server findest du in jedem Artikel in GitHub Enterprise Server-Instanz einrichten im Abschnitt „Mindestanforderungen“.

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.

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.

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

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.

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.

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

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

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.4 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 empfing oder der Standardbranch des Repositorys geändert wurde.

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.

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 Hinzufügen eines Mitglieds zu einer Organisation wurde eine fehlerhafte SAML-SSO-Testeinladung 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.

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

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.

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.

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.

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.

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

Sowohl Migrationsarchive für Repositorys als auch Archivexporte für Benutzerkonten enthalten Freigabereaktionen.

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.

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.

In einigen Fällen konnten geplante GitHub Actions-Workflows deaktiviert werden.

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.

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.

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.

Ein Renderingproblem konnte die Dropdownliste zum Filtern von Geheimnisüberprüfungswarnungen in einem Repository beeinträchtigen.

Die Leistung von Dependabot-Versionsupdates nach der ersten Aktivierung wurde verbessert.

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

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.

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.

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.

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

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.

MITTEL: Es wurde ein Sicherheitsproblem im NGINX-Resolver identifiziert, durch das Angreifer*innen, die UDP-Pakete vom DNS-Server fälschen konnten, möglicherweise eine Überschreibung des 1-Byte-Arbeitsspeichers verursachen konnten. Dies konnte zum Absturz von Workerprozessen oder anderen potenziell schädlichen Auswirkungen führen. Dieses Sicherheitsrisiko wurde CVE-2021-23017 zugewiesen.

Die Aktionen actions/checkout@v2 und actions/checkout@v3 wurden aktualisiert, um neue Sicherheitsrisiken zu beheben, die im Git-Blogbeitrag zur Sicherheitserzwingung angekündigt wurden.

Die Pakete wurden auf die neuesten Sicherheitsversionen aktualisiert.

In einigen Clustertopologien hinterließ der Befehl ghe-cluster-status leere Verzeichnisse in /tmp.

SNMP protokollierte fälschlicherweise eine hohe Anzahl von Cannot statfs-Fehlermeldungen im Syslog.

Beim Hinzufügen von benutzerdefinierten Mustern und der Bereitstellung von Nicht-UTF8-Testzeichenfolgen war die Hervorhebung von Übereinstimmungen nicht korrekt.

LDAP-Benutzer*innen mit einem Unterstrich (_) in ihrem Benutzernamen können sich jetzt erfolgreich anmelden.

Bei Instanzen, die mit SAML-Authentifizierung und integriertem Fallback konfiguriert sind, kam es für integrierte Benutzer zu einer Anmeldeschleife, wenn sie versuchten, sich über die nach dem Abmelden generierte Seite anzumelden.

Nach der Aktivierung von verschlüsselten SAML-Assertionen mit Azure als Identitätsanbieter tritt bei der Anmeldeseite ein 500-Fehler auf.

Die Einstellungen für Zeichentastenkombinationen wurden nicht beachtet.

Versuche, die Ausgabe von git fsck auf der Seite /stafftools/repositories/:owner/:repo/disk anzuzeigen, führten zum Fehler 500 Internal Server Error.

Bei der Verwendung von SAML-verschlüsselten Assertions wurden SSH-Schlüssel bei einigen Assertions nicht korrekt als verifiziert markiert.

Zu Issuekommentaren hochgeladene Videos wurden nicht korrekt gerendert.

Bei der Verwendung von GitHub Enterprise Importer zum Importieren eines Repositorys konnte es vorkommen, dass beim Import aufgrund von falsch konfigurierten Ereignissen in der Projektzeitleiste ein Fehler auftrat.

Bei der Verwendung von ghe-migrator konnte es vorkommen, dass bei einer Migration die Anhänge von Videodateien in Issues und Pull Requests nicht importiert wurden.

Die Releases-Seite gab einen 500-Fehler zurück, wenn das Repository Tags mit Nicht-ASCII-Zeichen enthielt. [Aktualisiert: 10.06.2022]

Bei Upgrades trat manchmal bei der Migration von Abhängigkeitsdiagrammdaten ein Fehler auf. [Aktualisiert: 30.06.2022]

Bei Hochverfügbarkeitskonfigurationen ist zu beachten, dass auf der Replikationsübersichtsseite in der Verwaltungskonsole nur die aktuelle Replikationskonfiguration und nicht der aktuelle Replikationsstatus angezeigt wird.

Das Nomad-Zuweisungstimeout für das Abhängigkeitsdiagramm wurde erhöht, um sicherzustellen, dass nach dem Upgrade durchgeführte Migrationen abgeschlossen werden können.

Bei der Aktivierung von GitHub Packages sollte klargestellt werden, dass die Verwendung eines SAS-Tokens (Shared Access Signature) als Verbindungszeichenfolge derzeit nicht unterstützt wird.

Supportbundles enthalten jetzt die Zeilenzahl von in MySQL gespeicherten Tabellen.

Beim Bestimmen der Repositorynetzwerke, für die eine Wartung geplant werden sollte, wird die Größe nicht erreichbarer Objekte nicht länger berücksichtigt.

Das Antwortfeld run_started_at ist jetzt in der Workflowausführungs-API und den Webhooknutzdaten des workflow_run-Ereignisses enthalten.

Die Pakete wurden auf die neuesten Sicherheitsversionen aktualisiert.

Es wurde eine Regression behoben, die zu regelmäßigen Fehlern beim Abrufen von Artefakten und beim Herunterladen von Protokollarchiven für GitHub Actions führen konnte. Unter bestimmten Umständen wurden URLs mit localhost für die interne Kommunikation nicht mehr aufgelöst, und stattdessen wurde fälschlicherweise der Hostname der Instanz verwendet.

Beim Löschen einer Manifestdatei aus einem Repository wurde das Manifest nicht aus der Seite „Abhängigkeitsdiagramm“ des Repositorys entfernt.

Ein Upgrade der Knoten in einem Hochverfügbarkeitspaar mit einem Upgradepaket konnte in einigen Fällen dazu führen, dass Elasticsearch in einen inkonsistenten Zustand überging.

Rotierte Protokolldateien mit der Endung .backup sammelten sich in Verzeichnissen mit Systemprotokollen an.

In einigen Clustertopologien konnten die Befehlszeilenhilfsprogramme ghe-spokesctl und ghe-btop nicht ausgeführt werden.

Elasticsearch-Indizes wurden während eines Paketupgrades möglicherweise dupliziert, da ein elasticsearch-upgrade-Dienst mehrfach parallel ausgeführt wurde.

Die Cacheserver für ein Repository lieferten möglicherweise Daten aus Nicht-Cachespeicherorten, auch wenn die Daten im lokalen Cachespeicher verfügbar waren.

Beim Konvertieren eines Benutzerkontos in eine Organisation wurde die konvertierte Organisation fälschlicherweise in der Liste der Unternehmensbesitzer angezeigt, wenn das Benutzerkonto ein Besitzer des GitHub Enterprise Server-Unternehmenskontos war.

Die Seite /stafftools/users/ip_addresses/:address hat mit einem 500 Internal Server Error geantwortet, wenn versucht wurde, die Seite für eine IPv6-Adresse anzuzeigen.

Das Erstellen eines OAuth-Token für den Identitätswechsel mithilfe der REST-API zur Verwaltung von Enterprise führte zu einem Fehler, wenn bereits eine Integration vorhanden war, die mit der OAuth-Anwendungs-ID übereinstimmte.

Es wurde Unterstützung für Replikatdomänennamen hinzugefügt, die mehr als 63 Zeichen lang sind.

Konfigurationsfehler, die zum Anhalten einer Konfigurationsanwendung führen, werden jetzt nicht nur im Konfigurationsprotokoll, sondern auch im Terminal ausgegeben.

Wenn GitHub Advanced Security-Features für eine Instanz aktiviert sind, hat sich die Leistung von Hintergrundaufträgen bei der Verarbeitung von Batches für Repositorybeiträge verbessert.

Bei einer neu eingerichteten GitHub Enterprise Server-Instanz ohne Benutzer könnte ein Angreifer den ersten Administratorbenutzer erstellen.

Benutzerdefinierte Firewallregeln werden während des Upgrades entfernt.

Mit Git LFS nachverfolgte Dateien, die über die Weboberfläche hochgeladen wurden, werden fälschlicherweise direkt dem Repository hinzugefügt.

Wenn die Option zum Durchsuchen von GitHub.com mit GitHub Connect aktiviert wird, sind Issues in privaten und internen Repositorys nicht in den GitHub.com-Suchergebnissen enthalten.

Die GitHub Packages-npm-Registrierung gibt in Metadatenantworten keinen Zeitwert mehr zurück. So sind erhebliche Leistungssteigerungen möglich. Die erforderlichen Daten zum Zurückgeben eines Zeitwerts in einer Metadatenantwort sind weiterhin verfügbar, und dieser Wert wird in Zukunft wieder zurückgegeben, sobald die vorhandenen Leistungsprobleme behoben wurden.

Ressourcenbegrenzungen, die nur beim Verarbeiten von Pre-Receive-Hooks auftreten, können bei manchen Pre-Receive-Hooks Fehler auslösen.

Nach der Registrierung eines selbstgehosteten Runners mit dem --ephemeral-Parameter auf mehreren Ebenen (z. B. auf Unternehmens- und Organisationsebene) befindet sich der Runner möglicherweise im Leerlauf und muss erneut registriert werden. [Aktualisiert: 17.06.2022]

Nach dem Upgrade auf GitHub Enterprise Server 3.4 kann es vorkommen, dass Releases in den Repositorys fehlen. Dieses Problem kann auftreten, wenn die erforderlichen Elasticsearch-Indexmigrationen nicht erfolgreich abgeschlossen wurden.

In einigen Fällen stellen GitHub Advanced Security-Kunden, die ein Upgrade auf GitHub Enterprise Server 3.5 oder höher durchführen, fest, dass Warnungen aus Geheimnisscans in der Webbenutzeroberfläche und der REST-API fehlen. Um sicherzustellen, dass die Warnungen sichtbar bleiben, überspringe Version 3.4 nicht, wenn du ein Upgrade von einer früheren Version auf Version 3.5 oder höher durchführst. In den Patchreleases 3.5.5 und 3.6.1 ist ein Fix verfügbar.

Weitere Informationen zum Planen eines Upgrades über Version 3.4 findest du unter Upgrade-Assistent. [Aktualisiert: 2022-09-01]

GitHub Pages-Builds können für Instanzen in AWS, die für Hochverfügbarkeit konfiguriert sind, zu einem Timeout führen. [Aktualisiert: 28.11.2022]

GitHub Enterprise Server 3.0 wurde am 16. Februar 2022 eingestellt. Das bedeutet, dass nach diesem Datum selbst für kritische Sicherheitsprobleme keine Patches veröffentlicht werden. Um eine bessere Leistung, höhere Sicherheit und neue Features zu erhalten, führe so bald wie möglich ein Upgrade auf die neueste Version von GitHub Enterprise Server durch.

GitHub Enterprise Server 3.1 wurde am 3. Juni 2022 eingestellt. Das bedeutet, dass nach diesem Datum selbst für kritische Sicherheitsprobleme keine Patches veröffentlicht werden. Um eine bessere Leistung, höhere Sicherheit und neue Features zu erhalten, führe so bald wie möglich ein Upgrade auf die neueste Version von GitHub Enterprise Server durch.

Ab GitHub Enterprise Server 3.3 wird GitHub Enterprise Server auf XenServer nicht mehr unterstützt. Wende dich bei Fragen oder Bedenken an den GitHub-Support.

Aufgrund einer geringen Nutzung wurde die Unterstützung der Vorschauversion der Inhaltsverweise-API in GitHub Enterprise Server 3.4 eingestellt. Zuvor konnte über den corsair-preview-Header auf die API zugegriffen werden. Benutzer*innen können auch ohne diese API weiterhin zu externen URLs wechseln. Bei der registrierten Nutzung der Inhaltsverweise-API wird keine Webhookbenachrichtigung mehr für URLs in deinen registrierten Domänen gesendet. Außerdem werden keine gültigen Antwortcodes mehr für versuchte Updates an vorhandenen Inhaltsanhängen zurückgegeben.

Die Unterstützung der Vorschauversion der Verhaltensregeln-API, auf die über den scarlet-witch-preview-Header zugegriffen werden konnte, wird eingestellt. Folglich kann in GitHub Enterprise Server 3.4 nicht mehr darauf zugegriffen werden. Stattdessen solltest du den Endpunkt zum Abrufen von Communityprofilmetriken verwenden, um Informationen zu den Verhaltensregeln eines Repositorys abzurufen. Weitere Informationen findest du im GitHub-Änderungsprotokoll im Hinweis zur Einstellung der Unterstützung: Vorschau der Verhaltensregeln-API.

Ab GitHub Enterprise Server 3.4 wurde die veraltete Version der Endpunkte der OAuth-Anwendungs-API entfernt. Wenn bei diesen Endpunkten der Fehler 404 gemeldet wird, konvertiere deinen Code in Versionen der OAuth-Anwendungs-API, die keine access_tokens in der URL enthalten. Darüber hinaus wurde die Verwendung der API-Authentifizierung unter Verwendung von Abfrageparametern deaktiviert. Stattdessen wird empfohlen, die API-Authentifizierung im Anforderungsheader zu verwenden.

Die Unterstützung des CodeQL-Runners wurde in GitHub Enterprise Server 3.4 eingestellt, und er wird nicht mehr unterstützt. Diese Einstellung betrifft ausschließlich Benutzerinnen, die die CodeQL-Codeüberprüfung in CI/CD-Systemen von Drittanbietern verwenden. GitHub Actions-Benutzerinnen sind nicht betroffen. Es wird dringend empfohlen, dass Kunden eine Migration zur CodeQL-CLI durchführen. Diese CLI ist ein vollumfänglicher Ersatz für den CodeQL-Runner. Weitere Informationen findest du im GitHub-Änderungsprotokoll.

Ab GitHub Enterprise Server 3.1 wurde die Unterstützung für die proprietären Bitcache-Erweiterungen von GitHub schrittweise eingestellt. Diese Erweiterungen gelten in GitHub Enterprise Server ab Version 3.3 als veraltet.

Repositorys, die bereits in deine GitHub Enterprise Server-Instanz mit Version 3.1 oder 3.2 vorhanden und aktiv waren, werden automatisch aktualisiert.

Repositorys, die vor einem Upgrade auf GitHub Enterprise Server 3.3 nicht vorhanden und aktiv waren, bieten möglicherweise keine optimale Leistung, bis eine Wartungsaufgabe für das Repository ausgeführt und erfolgreich abgeschlossen wurde.

Um eine Repositorywartungsaufgabe manuell zu starten, navigiere für jedes betroffene Repository zu https://<hostname>/stafftools/repositories/<owner>/<repository>/network, und klicke auf die Schaltfläche „Zeitplan“.

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.

MITTEL: In der Verwaltungskonsole von GitHub Enterprise Server wurde ein Sicherheitsrisiko aufgrund von Pfadausnahmen identifiziert, wodurch CSRF-Schutzmaßnahmen umgangen werden konnten. Dieses Sicherheitsrisiko betraf alle Versionen von GitHub Enterprise Server vor Version 3.5 und wurde in den Versionen 3.1.19, 3.2.11, 3.3.6 und 3.4.1 behoben. Dieses Sicherheitsrisiko wurde über das GitHub Bug Bounty Program gemeldet und weist die Kennung CVE-2022-23732 auf.

MITTEL: In den Branches 1.x und 2.x von yajil wurde ein Sicherheitsrisiko aufgrund eines Integerüberlaufs identifiziert, wodurch es bei größeren Eingaben (~2 GB) zu Beschädigungen des nachfolgenden Heapspeichers kam. Dieses Sicherheitsrisiko wurde intern gemeldet und weist die Kennung CVE-2022-24795 auf.

Wurde GitHub Actions aktiviert, konnten Supportbundles vertrauliche Daten enthalten.

Die Pakete wurden auf die neuesten Sicherheitsversionen aktualisiert.

Eine Workflowausführung wird möglicherweise nicht abgeschlossen, wenn sie zusammengesetzte Aktionen verwendet.

Bei der Aktivierung von Dependabot führte ein Fehler dazu, dass einige Sicherheitshinweise vorübergehend als nicht mehr zutreffend gelesen wurden.

Minio-Prozesse würden eine hohe CPU-Auslastung aufweisen, wenn eine alte Konfigurationsoption nach dem Upgrade von GitHub Enterprise Server vorhanden war.

In den Datenschutzeinstellungen der Verwaltungskonsole wurden die Optionen zur Aktivierung von TLS 1.0 und TLS 1.1 angezeigt, obwohl diese Protokollversionen bereits in einem früheren Release entfernt wurden.

In einer Umgebung mit Hochverfügbarkeit wurden für die Konfiguration der MSSQL-Replikation zusätzliche manuelle Schritte erforderlich, wenn GitHub Actions zum ersten Mal aktiviert wurde.

Eine Teilmenge interner Konfigurationsdateien wird nach einem Hotpatch zuverlässiger aktualisiert.

Mit dem Skript ghe-run-migrations ließen sich in einigen Fällen keine korrekten temporären Zertifikatnamen erzeugen.

Für Pre-Receive-Hooks, die gpg --import verwendet haben, wurde das Zeitlimit aufgrund unzureichender syscall-Berechtigungen überschritten.

In einigen Clustertopologien standen Informationen zur Webhookübermittlung nicht zur Verfügung.

Das Bereitstellungsdiagramm GitHub Actions würde beim Rendern eines ausstehenden Auftrags einen Fehler anzeigen.

Beim Ausführen von Migrationen war bei Elasticsearch-Integritätsprüfungen ein gelber Status nicht zulässig.

Bei Verwendung der Migrations-API wurden Exportaufträge in der Warteschlange nicht verarbeitet.

Repositorys würden auf der Webbenutzeroberfläche eine nicht funktionierende Registerkarte „Diskussionen“ anzeigen.

Organisationen, die als Folge der Umwandlung eines Benutzerkontos in ein Organisationskonto erstellt wurden, wurden dem globalen Unternehmenskonto nicht hinzugefügt.

Bei Aufträgen zur Synchronisierung von LDAP-Benutzern würde ein Fehler auftreten, wenn sie versuchten, GPG-Schlüssel zu synchronisieren, die zuvor synchronisiert worden waren.

Links zu Seiten, auf die der Zugriff nicht möglich ist, wurden entfernt.

Bei einigen Instanzen kam es zu einer hohen CPU-Auslastung, da viele unnötige Hintergrundaufträge in die Warteschlange gestellt wurden.

Leere Repositorys wurden nicht ordnungsgemäß mit Cacheservern synchronisiert.

Wurde einem Pull Request ein Team als Prüfer hinzugefügt, kam es gelegentlich zu einer falschen Angabe der Anzahl der Teammitglieder.

Der API-Endpunkt zum Entfernen von Teammitgliedern würde mit einem Fehler reagieren, wenn versucht wurde, ein Mitglied zu entfernen, das extern über eine SCIM-Gruppe verwaltet wird.

Bei der Konfiguration von GitHub Connect konnte bei einer großen Anzahl inaktiver Benutzer ein Fehler auftreten.

Auf der Benutzeroberfläche des Websiteadministrators war die Seite „Feature- & Betaregistrierungen“ fälschlicherweise verfügbar.

In der Fußzeile der Website wurde der Status des Links „Websiteadministratormodus“ beim Klicken nicht geändert.

Bei Verwendung von ghe-migrator oder dem Export von GitHub.com enthielt der Export keine Pull Request-Anhänge.

Die Verbindungsbeschränkungen im Arbeitsspeicher wurden für eine bessere Unterstützung großer Clustertopologien erhöht.

Die API für Abhängigkeitsdiagramme wurde bisher mit einem statisch definierten Port ausgeführt.

Die Standardanzahl von Shards für clusterbezogene Elasticsearch-Shardeinstellungen wurde aktualisiert.

Die Migrations-API generiert jetzt Exporte von Repositorys.

Bei der Filterung von Unternehmensmitgliedern nach Organisationsrolle auf der Seite „Personen“ wurde der Text für die Einträge im Dropdownmenü verbessert.

Die Teamrollen „Selektierung“ und „Verwalten“ werden während der Migration von Repositorys beibehalten.

Für Webanforderungen durch Unternehmensbesitzer wurde die Leistung erhöht.

Bei einer neu eingerichteten GitHub Enterprise Server-Instanz ohne Benutzer könnte ein Angreifer den ersten Administratorbenutzer erstellen.

Benutzerdefinierte Firewallregeln werden während des Upgrades entfernt.

Mit Git LFS nachverfolgte Dateien, die über die Weboberfläche hochgeladen wurden, werden fälschlicherweise direkt dem Repository hinzugefügt.

Issues können nicht geschlossen werden, wenn sie einen Permalink zu einem Blob im selben Repository enthalten und der Dateipfad des Blobs mehr als 255 Zeichen lang ist.

Wenn die Option zum Durchsuchen von GitHub.com mit GitHub Connect aktiviert wird, sind Issues in privaten und internen Repositorys nicht in den GitHub.com-Suchergebnissen enthalten.

Die GitHub Packages-npm-Registrierung gibt in Metadatenantworten keinen Zeitwert mehr zurück. So sind erhebliche Leistungssteigerungen möglich. Die erforderlichen Daten zum Zurückgeben eines Zeitwerts in einer Metadatenantwort sind weiterhin verfügbar, und dieser Wert wird in Zukunft wieder zurückgegeben, sobald die vorhandenen Leistungsprobleme behoben wurden.

Ressourcenbegrenzungen, die nur beim Verarbeiten von Pre-Receive-Hooks auftreten, können bei manchen Pre-Receive-Hooks Fehler auslösen.

Nach der Registrierung eines selbstgehosteten Runners mit dem --ephemeral-Parameter auf mehreren Ebenen (z. B. auf Unternehmens- und Organisationsebene) befindet sich der Runner möglicherweise im Leerlauf und muss erneut registriert werden. [Aktualisiert: 17.06.2022]

Bei Verwendung von verschlüsselten SAML-Assertionen mit GitHub Enterprise Server 3.4.0 und 3.4.1 enthält ein neues XML-Attribut WantAssertionsEncrypted im SPSSODescriptor ein ungültiges Attribut für SAML-Metadaten. Bei Identitätsanbietern, die diesen SAML-Metadatenendpunkt nutzen, können bei der Überprüfung des XML-Schemas der SAML-Metadaten Fehler auftreten. Ein Fix wird im nächsten Patchrelease verfügbar sein. [Aktualisiert: 11.04.2022]

Führe eine der folgenden Aktionen aus, um dieses Problem zu umgehen:

• Konfiguriere den Identitätsanbieter neu, indem du eine statische Kopie der SAML-Metadaten ohne das Attribut WantAssertionsEncrypted hochlädst.
• Kopiere die SAML-Metadaten, entferne das Attribut WantAssertionsEncrypted, hoste die Daten auf einem Webserver, und konfiguriere den Identitätsanbieter so neu, dass er auf diese URL verweist.

In einigen Fällen stellen GitHub Advanced Security-Kunden, die ein Upgrade auf GitHub Enterprise Server 3.5 oder höher durchführen, fest, dass Warnungen aus Geheimnisscans in der Webbenutzeroberfläche und der REST-API fehlen. Um sicherzustellen, dass die Warnungen sichtbar bleiben, überspringe Version 3.4 nicht, wenn du ein Upgrade von einer früheren Version auf Version 3.5 oder höher durchführst. In den Patchreleases 3.5.5 und 3.6.1 ist ein Fix verfügbar.

Weitere Informationen zum Planen eines Upgrades über Version 3.4 findest du unter Upgrade-Assistent. [Aktualisiert: 2022-09-01]

GitHub Pages-Builds können für Instanzen in AWS, die für Hochverfügbarkeit konfiguriert sind, zu einem Timeout führen. [Aktualisiert: 28.11.2022]

GitHub Enterprise Server 3.0 wurde am 16. Februar 2022 eingestellt. Das bedeutet, dass nach diesem Datum selbst für kritische Sicherheitsprobleme keine Patches veröffentlicht werden. Um eine bessere Leistung, höhere Sicherheit und neue Features zu erhalten, führe so bald wie möglich ein Upgrade auf die neueste Version von GitHub Enterprise Server durch.

GitHub Enterprise Server 3.1 wurde am 3. Juni 2022 eingestellt. Das bedeutet, dass nach diesem Datum selbst für kritische Sicherheitsprobleme keine Patches veröffentlicht werden. Um eine bessere Leistung, höhere Sicherheit und neue Features zu erhalten, führe so bald wie möglich ein Upgrade auf die neueste Version von GitHub Enterprise Server durch.

Ab GitHub Enterprise Server 3.3 wird GitHub Enterprise Server auf XenServer nicht mehr unterstützt. Wende dich bei Fragen oder Bedenken an den GitHub-Support.

Aufgrund einer geringen Nutzung wurde die Unterstützung der Vorschauversion der Inhaltsverweise-API in GitHub Enterprise Server 3.4 eingestellt. Zuvor konnte über den corsair-preview-Header auf die API zugegriffen werden. Benutzer*innen können auch ohne diese API weiterhin zu externen URLs wechseln. Bei der registrierten Nutzung der Inhaltsverweise-API wird keine Webhookbenachrichtigung mehr für URLs in deinen registrierten Domänen gesendet. Außerdem werden keine gültigen Antwortcodes mehr für versuchte Updates an vorhandenen Inhaltsanhängen zurückgegeben.

Die Unterstützung der Vorschauversion der Verhaltensregeln-API, auf die über den scarlet-witch-preview-Header zugegriffen werden konnte, wird eingestellt. Folglich kann in GitHub Enterprise Server 3.4 nicht mehr darauf zugegriffen werden. Stattdessen solltest du den Endpunkt zum Abrufen von Communityprofilmetriken verwenden, um Informationen zu den Verhaltensregeln eines Repositorys abzurufen. Weitere Informationen findest du im GitHub-Änderungsprotokoll im Hinweis zur Einstellung der Unterstützung: Vorschau der Verhaltensregeln-API.

Ab GitHub Enterprise Server 3.4 wurde die veraltete Version der Endpunkte der OAuth-Anwendungs-API entfernt. Wenn bei diesen Endpunkten der Fehler 404 gemeldet wird, konvertiere deinen Code in Versionen der OAuth-Anwendungs-API, die keine access_tokens in der URL enthalten. Darüber hinaus wurde die Verwendung der API-Authentifizierung unter Verwendung von Abfrageparametern deaktiviert. Stattdessen wird empfohlen, die API-Authentifizierung im Anforderungsheader zu verwenden.

Die Unterstützung des CodeQL-Runners wurde in GitHub Enterprise Server 3.4 eingestellt, und er wird nicht mehr unterstützt. Diese Einstellung betrifft ausschließlich Benutzerinnen, die die CodeQL-Codeüberprüfung in CI/CD-Systemen von Drittanbietern verwenden. GitHub Actions-Benutzerinnen sind nicht betroffen. Es wird dringend empfohlen, dass Kunden eine Migration zur CodeQL-CLI durchführen. Diese CLI ist ein vollumfänglicher Ersatz für den CodeQL-Runner. Weitere Informationen findest du im GitHub-Änderungsprotokoll.

Ab GitHub Enterprise Server 3.1 wurde die Unterstützung für die proprietären Bitcache-Erweiterungen von GitHub schrittweise eingestellt. Diese Erweiterungen gelten in GitHub Enterprise Server ab Version 3.3 als veraltet.

Repositorys, die bereits in deine GitHub Enterprise Server-Instanz mit Version 3.1 oder 3.2 vorhanden und aktiv waren, werden automatisch aktualisiert.

Repositorys, die vor einem Upgrade auf GitHub Enterprise Server 3.3 nicht vorhanden und aktiv waren, bieten möglicherweise keine optimale Leistung, bis eine Wartungsaufgabe für das Repository ausgeführt und erfolgreich abgeschlossen wurde.

Um eine Repositorywartungsaufgabe manuell zu starten, navigiere für jedes betroffene Repository zu https://<hostname>/stafftools/repositories/<owner>/<repository>/network, und klicke auf die Schaltfläche „Zeitplan“.

GitHub Advanced Security-Kunden können die REST-API jetzt verwenden, um Commitdetails von Geheimnissen abzurufen, die bei der Überprüfung privater Repositorys ermittelt wurden. Der neue Endpunkt gibt Details zum ersten Vorkommen eines Geheimnisses innerhalb einer Datei zurück (einschließlich Position des Geheimnisses und Commit-SHA). Weitere Informationen findest du in der REST-API-Dokumentation unter Geheime Überprüfung.

Unternehmens- und Organisationsbesitzer*innen können ihre GitHub Advanced Security-Lizenznutzungsdaten jetzt in eine CSV-Datei exportieren. Die Advanced Security-Abrechnungsdaten können auch über Abrechnungsendpunkte in der REST-API abgerufen werden. Weitere Informationen findest du im GitHub-Änderungsprotokoll.

Wie Aktionen können jetzt auch Workflows vollständig wiederverwendet werden. Dieses Feature ist als öffentliche Betaversion verfügbar. Du kannst jetzt mit einer einzigen Konfigurationszeile auf einen vorhandenen Workflow verweisen und musst Workflowdefinitionen nicht länger kopieren und in anderen Repositorys einfügen. Weitere Informationen findest du im GitHub-Änderungsprotokoll.

Dependabot ist jetzt in GitHub Enterprise Server 3.4 als öffentliche Betaversion verfügbar, die sowohl Versions- als auch Sicherheitsupdates für mehrere beliebte Ökosysteme bietet. Dependabot für GitHub Enterprise Server erfordert GitHub Actions und einen Pool selbstgehosteter Runner, der für die Verwendung von Dependabot konfiguriert ist. Dependabot für GitHub Enterprise Server erfordert außerdem die Aktivierung von GitHub Connect und Dependabot durch Administrator*innen. Feedback und Vorschläge zur Betaversion können in der GitHub-Diskussion zu Dependabot-Feedback geteilt werden. Weitere Informationen und Hinweise zum Testen der Betaversion findest du unter Einrichten von Sicherheits- und Versionsupdates für Dependabot in deinem Unternehmen.

Wenn du die SAML-Authentifizierung für GitHub Enterprise Server verwendest, kannst du für eine höhere Sicherheit jetzt verschlüsselte Assertionen von deinem Identitätsanbieter konfigurieren. Durch verschlüsselte Assertionen wird eine zusätzliche Verschlüsselungsebene hinzugefügt, wenn dein Identitätsanbieter Informationen an deine GitHub Enterprise Server-Instanz übermittelt. Weitere Informationen findest du unter Verwenden von SAML.

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]

Benutzer*innen können jetzt die Anzahl von Leerstellen für Tabulatoren auswählen. Dazu legen sie ihre bevorzugte Tabulatorlänge in den Darstellungseinstellungen ihrer Benutzerkonten fest. Code mit Tabulatoreinzug wird anschließend mit der bevorzugten Tabulatorlänge angezeigt.

Der GitHub Connect-Datenverbindungseintrag umfasst nun die Anzahl von aktiven und inaktiven Benutzer*innen sowie die konfigurierte Inaktivitätsdauer.

Du kannst Benutzer*innen jetzt Zugriff auf unternehmensspezifische Links gewähren, indem du benutzerdefinierte Fußzeilen zu GitHub Enterprise Server hinzufügst. Weitere Informationen findest du unter Konfigurieren von benutzerdefinierten Fußzeilen.

Die für eine sichere Kommunikation zwischen GitHub Enterprise Server-Instanzen in einer Hochverfügbarkeitskonfiguration verwendete WireGuard-Software wurde in die Kernel-Implementierung migriert.

Organisationsbesitzer*innen können E-Mail-Benachrichtigungen jetzt abbestellen, wenn neue Bereitstellungsschlüssel zu Repositorys hinzugefügt werden, die ihren Organisationen gehören. Weitere Informationen findest du unter Konfigurieren von Benachrichtigungen.

Benachrichtigungs-E-Mails zu neu erstellten Issues und Pull Requests umfassen jetzt die Info (Issue #xx) oder (PR #xx) im E-Mail-Betreff. Anhand dieser Informationen kannst du E-Mails erkennen und filtern, in denen auf diese Issues verwiesen wird.

Organisationen können jetzt eine README.md-Datei in ihrer Profilübersicht anzeigen. Weitere Informationen findest du im GitHub-Änderungsprotokoll.

Mitglieder von Organisationen können jetzt eine Liste ihrer Unternehmensbesitzerinnen auf der Registerkarte „Personen“ der Organisation anzeigen. Auf die Liste der Unternehmensbesitzerinnen kann jetzt auch über die GraphQL-API zugegriffen werden. Weitere Informationen findest du im Feld enterpriseOwners unter dem Organization-Objekt in der GraphQL-API-Dokumentation.

Die Seite „Mitwirkende und Teams“ in deinen Repositoryeinstellungen enthält jetzt einen Abschnitt „Zugriff verwalten“. Über diesen neuen Abschnitt können Repositoryadministratorinnen besser anzeigen und verwalten, wer Zugriff auf ihr Repository hat. Außerdem ist die Zugriffsstufe ersichtlich, die den einzelnen Benutzerinnen zugewiesen ist. Administrator*innen haben jetzt folgende Möglichkeiten:

• Suchen nach allen Mitgliedern, Teams und Projektmitarbeiter*innen, die Zugriff auf das Repository haben
• Anzeigen, wenn Mitglieder über kombinierte Rollenzuweisungen verfügen, die ihnen direkt als Einzelpersonen oder indirekt über ein Team erteilt wurden In diesem Fall wird eine Warnung zu kombinierten Rollen angezeigt. Sofern die Berechtigungsebene höher ist als die zugewiesene Rolle, enthält diese Warnung die Rolle höchster Ebene, die einer oder einem Benutzer*in gewährt ist.
• Zuverlässige Verwaltung des Zugriffs auf beliebte Repositorys mit Seitenpaginierung und weniger Timeouts, wenn große Benutzergruppen Zugriff haben

GitHub Enterprise Server 3.4 umfasst Verbesserungen bei Repositoryeinladungen. Dazu zählen Benachrichtigungen bei Einladungen zu privaten Repositorys, eine Benutzeroberflächenaufforderung beim Besuch eines privaten Repositorys, für das eine Einladung aussteht, sowie ein Banner auf der Übersichtsseite eines öffentlichen Repositorys, wenn eine Einladung aussteht.

Du kannst jetzt Präfixe aus einem einzelnen Zeichen für benutzerdefinierte automatische Verknüpfungen verwenden. Außerdem sind bei Präfixen für automatische Verknüpfungen jetzt alphanumerische Zeichen sowie die folgenden Zeichen zulässig: ., -, _, +, =, :, / und #. Weitere Informationen zu benutzerdefinierten automatischen Verknüpfungen findest du unter Konfigurieren automatischer Verknüpfungen zum Verweisen auf externe Ressourcen.

Auf der Übersichtsseite eines Repositorys ist jetzt auf der Randleiste „Info“ eine Datei CODE_OF_CONDUCT.md im Repositorystamm hervorgehoben.

GitHub Enterprise Server 3.4 umfasst Verbesserungen an der Benutzeroberfläche für Releases. Dazu zählen automatisch generierte Versionshinweise, die eine Zusammenfassung aller Pull Requests für ein bestimmtes Release enthalten. Weitere Informationen findest du im GitHub-Änderungsprotokoll.

Bei der Veröffentlichung eines Releases wird im unteren Bereich jetzt eine Avatarliste angezeigt. Dort werden Avatars für alle Benutzerkonten gezeigt, die in den Versionshinweisen erwähnt werden. Weitere Informationen findest du unter Verwalten von Releases in einem Repository.

Auf der neuen Seite mit den Barrierfreheitseinstellungen kannst du jetzt deine Tastaturkurzbefehle verwalten. Du kannst Tastenkombinationen deaktivieren, die nur einzelne Zeichen wie S, G, C und . (der Punkt) verwenden. Weitere Informationen findest du im GitHub-Änderungsprotokoll.

Du kannst in Markdown-fähigen Feldern wie Issuekommentaren und Pull Request-Beschreibungen jetzt eine Schriftart mit fester Breite verwenden. Weitere Informationen findest du im GitHub-Änderungsprotokoll.

Du kannst jetzt eine URL für ausgewählten Text einfügen, um im Handumdrehen einen Markdownlink zu erstellen. Dies ist bei allen Markdown-fähigen Feldern wie Issuekommentaren und Pull Request-Beschreibungen möglich. Weitere Informationen findest du im GitHub-Änderungsprotokoll.

Eine Bild-URL kann jetzt mit einem Designkontext wie #gh-dark-mode-only angefügt werden, um die Anzeige des Markdownbilds für Betrachter*innen zu definieren. Weitere Informationen findest du im GitHub-Änderungsprotokoll.

Beim Erstellen oder Bearbeiten einer Gistdatei mit der Markdowndateierweiterung (.md) kannst du jetzt auf der Registerkarte „Vorschau“ oder „Vorschau der Änderungen“ ein Markdownrendering der Dateiinhalte anzeigen. Weitere Informationen findest du im GitHub-Änderungsprotokoll.

Bei der Eingabe eines GitHub-Benutzernamens in Issues, Pull Requests und Diskussionen zeigt die @mention-Vorschlagsfunktion vorhandene Teilnehmerinnen jetzt weiter oben an als andere GitHub-Benutzerinnen. Dadurch wird die Wahrscheinlichkeit erhöht, dass die oder der Benutzer*in aufgeführt wird, nach der bzw. dem du suchst.

Von rechts nach links geschriebene Sprachen werden jetzt nativ in Markdowndateien, Issues, Pull Requests, Diskussionen und Kommentaren unterstützt.

Die „Diff“-Einstellung zum Ausblenden von Leerzeichenänderungen auf der Registerkarte „Geänderte Dateien“ eines Pull Requests wird jetzt für dein Benutzerkonto für den jeweiligen Pull Request beibehalten. Die ausgewählte Einstellung wird automatisch erneut angewendet, wenn du die Seite verlässt und anschließend erneut auf die Registerkarte „Geänderte Dateien“ desselben Pull Requests wechselst.

Bei Verwendung der automatischen Zuweisung für Pull Request-Code Reviews kannst du jetzt auswählen, dass unabhängig von deinen Einstellungen für die automatische Zuweisung nur gewünschte Teammitglieder benachrichtigt werden. Diese Einstellung ist in Szenarios nützlich, in denen eine Vielzahl von Benutzerinnen automatisch zugewiesen werden, aber nicht für alle Benutzerinnen eine Benachrichtigung erforderlich ist. Weitere Informationen findest du im GitHub-Änderungsprotokoll.

Organisations- und Repositoryadministrator*innen können jetzt Webhooks auslösen, um Änderungen an Schutzregeln für Branches in ihren Repositorys zu ermitteln. Weitere Informationen findest du unter dem branch_protection_rule-Ereignis in der Dokumentation zu Webhooksereignissen und Nutzdaten.

Beim Konfigurieren von geschützten Branches kannst du jetzt durchsetzen, dass eine bestimmte GitHub App eine erforderliche Statusüberprüfung bereitstellt. Wenn dann ein Status von einer anderen Anwendung oder über einen Commitstatus von einereinem Benutzerin bereitgestellt wird, wird der Merge verhindert. Dadurch wird sichergestellt, dass alle Änderungen von der gewünschten Anwendung überprüft werden. Weitere Informationen findest du im GitHub-Änderungsprotokoll.

Nur Benutzerinnen mit Administratorberechtigungen sind jetzt in der Lage, geschützte Branches umzubenennen und Schutzregeln für Branches zu ändern. Mit Ausnahme des Standardbranches konnten Projektmitarbeiterinnen Branches zuvor umbenennen, sodass auch alle Nicht-Platzhalter-Branchschutzregeln für den jeweiligen Branch umbenannt wurden. Weitere Informationen findest du unter Umbenennen von Branches und Verwalten von Branchschutzregeln.

Administratorinnen können jetzt festlegen, dass nur bestimmte Benutzerinnen und Teams Pull Request-Anforderungen umgehen können. Weitere Informationen findest du im GitHub-Änderungsprotokoll.

Administratorinnen können jetzt festlegen, dass nur bestimmte Benutzerinnen und Teams einen Push in ein Repository erzwingen können. Weitere Informationen findest du im GitHub-Änderungsprotokoll.

Wenn festgelegt wird, dass Pull Requests für alle Änderungen an einem geschützten Branch erforderlich sind, können Administrator*innen jetzt auswählen, ob auch genehmigte Reviews erforderlich sind. Weitere Informationen findest du im GitHub-Änderungsprotokoll.

GitHub Actions-Workflows, die von Dependabot für die Ereignisse create, deployment und deployment_status ausgelöst werden, empfangen jetzt immer ein schreibgeschütztes Token und keine Geheimnisse. Ebenso erhalten Workflows, die von Dependabot für das pull_request_target-Ereignis bei Pull Requests ausgelöst werden, bei denen die Basisreferenz von Dependabot erstellt wurde, jetzt immer ein schreibgeschütztes Token und keine Geheimnisse. Durch diese Änderungen soll verhindert werden, dass potenziell schadhafter Code in einem privilegierten Workflow ausgeführt wird. Weitere Informationen findest du unter Automatisieren von Dependabot mit GitHub Actions.

Workflowausführungen bei push- und pull_request-Ereignissen, die von Dependabot ausgelöst werden, beachten jetzt die in deinen Workflows angegebenen Berechtigungen. Dadurch kannst du die Verwaltung von automatischen Abhängigkeitsupdates steuern. Die Standardtokenberechtigungen sind weiterhin schreibgeschützt. Weitere Informationen findest du im GitHub-Änderungsprotokoll.

Die Dependabot-Geheimnisse werden jetzt an GitHub Actions-Workflows gesendet, die von Dependabot ausgelöst werden. Du kannst jetzt Daten aus privaten Paketregistrierungen in CI unter Verwendung derselben Geheimnisse pullen, die du für Dependabot konfiguriert hast. Dadurch wird die gemeinsame Verwendung von GitHub Actions und Dependabot verbessert. Weitere Informationen findest du unter Automatisieren von Dependabot mit GitHub Actions.

Auf den neuen Seiten „Runner“ und „Runnergruppen“ kannst du jetzt über die Benutzeroberfläche Runnergruppen verwalten und den Status deiner selbstgehosteten Runner anzeigen. Auf der Seite mit den Actions-Einstellungen für dein Repository oder deine Organisation wird jetzt eine Zusammenfassung deiner Runner angezeigt. Außerdem kannst du auf dieser Seite Details zu einem bestimmten Runner anzeigen, um den Runner zu bearbeiten oder den aktuell ausgeführten Auftrag zu ermitteln. Weitere Informationen findest du im GitHub-Änderungsprotokoll.

Aktionsautor*innen können ihre Aktion jetzt in Node.js 16 ausführen, indem sie für runs.using in der Aktionsdatei action.yml den Wert node16 angeben. Dies gilt zusätzlich zur vorhandenen Node.js 12-Unterstützung. Für Aktionen kann weiterhin runs.using: node12 angegeben werden, um die Node.js 12-Runtime zu verwenden.

Für manuell ausgelöste Workflows unterstützt GitHub Actions jetzt zusätzlich zum Standardtyp string die Eingabetypen choice, boolean und environment. Weitere Informationen findest du unter on.workflow_dispatch.inputs.

In YAML geschriebene Aktionen, die auch als zusammengesetzte Aktionen bezeichnet werden, unterstützen jetzt if-Bedingungen. Dadurch lässt sich steuern, dass bestimmte Schritte nur dann ausgeführt werden, wenn eine Bedingung erfüllt ist. Wie bei Schritten, die in Workflows definiert sind, kannst du eine Bedingung mit jedem unterstützten Kontext und Ausdruck erstellen.

Das Suchreihenfolgenverhalten für selbstgehostete Runner wurde geändert. Der erste verfügbare passende Runner beliebiger Ebene führt den Auftrag jetzt in allen Fällen aus. Dadurch können Aufträge jetzt deutlich schneller an selbstgehostete Runner gesendet werden. Dies gilt insbesondere für Organisationen und Unternehmen mit einer großen Anzahl von selbstgehosteten Runnern. Bei der Ausführung eines Auftrags, für den ein selbstgehosteter Runner erforderlich war, hat GitHub Actions früher im Repository, in der Organisation und im Unternehmen (in dieser Reihenfolge) nach selbstgehosteten Runnern gesucht.

Runnerbezeichnungen für selbstgehostete Runner in GitHub Actions können jetzt über die REST-API aufgelistet, hinzugefügt und entfernt werden. Weitere Informationen zur Verwendung der neuen APIs auf Repository-, Organisations- oder Unternehmensebene findest du in der REST-API-Dokumentation unter Repositorys, Organisationen und Unternehmen.

Das Abhängigkeitsdiagramm unterstützt jetzt die Erkennung von Python-Abhängigkeiten in Repositorys, die den Poetry-Paket-Manager verwenden. Abhängigkeiten werden in den Manifestdateien pyproject.toml und poetry.lock erkannt.

Bei der Konfiguration von Dependabot-Sicherheits- und Versionsupdates in GitHub Enterprise Server wird auch die Aktivierung von Dependabot in GitHub Connect empfohlen. Dadurch kann Dependabot eine aktualisierte Liste mit Abhängigkeiten und Sicherheitsrisiken von GitHub.com abrufen, indem Informationen wie die Änderungsprotokolle der öffentlichen Releases von Open-Source-Code abgerufen werden, die du nutzt. Weitere Informationen findest du unter Aktivieren des Abhängigkeitsdiagramms und von Dependabot-Warnungen für dein Unternehmen.

Dependabot alerts-Warnungen können jetzt über die GraphQL-API verworfen werden. Weitere Informationen findest du in der Dokumentation zur GraphQL-API unter der dismissRepositoryVulnerabilityAlert-Mutation.

Die CodeQL-CLI unterstützt jetzt das Einfügen einer mit Markdown gerenderten Abfragehilfe in SARIF-Dateien. Dadurch kann der Hilfetext auf der code scanning-Benutzeroberfläche angezeigt werden, wenn bei der Abfrage eine Warnung generiert wird. Weitere Informationen findest du im GitHub-Änderungsprotokoll.

Die CodeQL-CLI und die Visual Studio Code-Erweiterung unterstützen jetzt das Erstellen von Datenbanken und Analysieren von Code auf Computern, die auf Apple Silicon basieren (z. B. Apple M1). Weitere Informationen findest du im GitHub-Änderungsprotokoll.

Die Tiefe der CodeQL-Analyse wurde verbessert, indem Unterstützung für weitere Bibliotheken und Frameworks aus dem Python-Ökosystem hinzugefügt wurde. Dadurch kann CodeQL jetzt noch mehr potenzielle Quellen nicht vertrauenswürdiger Benutzerdaten, die Schritte des Datenflusses und potenziell gefährliche Senken ermitteln, in die die Daten gelangen könnten. Das Ergebnis ist eine allgemeine Qualitätssteigerung der code scanning-Warnungen. Weitere Informationen findest du im GitHub-Änderungsprotokoll.

Die Codeüberprüfung mit CodeQL umfasst jetzt die Betaunterstützung für die Codeanalyse in allen gängigen Ruby-Versionen (bis 3.02 einschließlich). Weitere Informationen findest du im GitHub-Änderungsprotokoll.

An der code scanning-API wurden mehrere Verbesserungen vorgenommen:

• Warnungen wurde der fixed_at-Zeitstempel hinzugefügt. Dieser Zeitstempel gibt den ersten Zeitpunkt an, zu dem die Warnung in einer Analyse nicht mehr ermittelt wurde.
• Die Warnungsergebnisse können jetzt mit sort und direction nach created, updated oder number sortiert werden. Weitere Informationen findest du unter Auflisten von Codeüberprüfungswarnungen für ein Repository.
• Die Warnungen und die Warnungsendpunktantwort wurden um einen Last-Modified-Header ergänzt. Weitere Informationen findest du in der Mozilla-Dokumentation unter Last-Modified.
• Der SARIF-Antwort wurde das Feld relatedLocations hinzugefügt, wenn eine Codeüberprüfungsanalyse angefordert wird. Dieses Feld kann Positionen enthalten, die nicht die primäre Position der Warnung sind. Sieh dir ein Beispiel in der SARIF-Spezifikation an. Weitere Informationen findest du unter Abrufen einer Codeüberprüfungsanalyse für ein Repository.
• Dem Warnungsregelobjekt der Webhookantwort wurden sowohl help- als auch tags-Daten hinzugefügt. Weitere Informationen findest du unter Webhookereignisse und Nutzdaten zu Codeüberprüfungswarnungen.
• Persönliche Zugriffstoken mit dem Bereich public_repo verfügen jetzt über Schreibzugriff für Codeüberprüfungsendpunkte in öffentlichen Repositorys, sofern Benutzer*innen über die erforderliche Berechtigung verfügen.

Weitere Informationen findest du in der REST-API-Dokumentation unter Codeüberprüfung.

GitHub Advanced Security-Kunden können die REST-API jetzt verwenden, um die Ergebnisse der Geheimnisüberprüfung für private Repositorys auf Unternehmensebene abzurufen. Der neue Endpunkt ergänzt die vorhandenen Endpunkte auf Repository- und Organisationsebene. Weitere Informationen findest du in der REST-API-Dokumentation unter Geheimnisüberprüfung.

Unterstützung für GitHub Mobile ist jetzt standardmäßig für neue GitHub Enterprise Server-Instanzen aktiviert. Wenn du GitHub Mobile nicht explizit deaktiviert oder aktiviert hast, wird GitHub Mobile bei einem Upgrade auf GitHub Enterprise Server 3.4.0 oder höher aktiviert. Wenn du zuvor GitHub Mobile für deine Instanz deaktiviert oder aktiviert hast, wird deine Einstellung nach dem Upgrade beibehalten. Weitere Informationen findest du unter Verwalten von GitHub Mobile in deinem Unternehmen.

Bei einer neu eingerichteten GitHub Enterprise Server-Instanz ohne Benutzer könnte ein Angreifer den ersten Administratorbenutzer erstellen.

Benutzerdefinierte Firewallregeln werden während des Upgrades entfernt.

Mit Git LFS nachverfolgte Dateien, die über die Weboberfläche hochgeladen wurden, werden fälschlicherweise direkt dem Repository hinzugefügt.

Wenn die Option zum Durchsuchen von GitHub.com mit GitHub Connect aktiviert wird, sind Issues in privaten und internen Repositorys nicht in den GitHub.com-Suchergebnissen enthalten.

Die GitHub Packages-npm-Registrierung gibt in Metadatenantworten keinen Zeitwert mehr zurück. So sind erhebliche Leistungssteigerungen möglich. Die erforderlichen Daten zum Zurückgeben eines Zeitwerts in einer Metadatenantwort sind weiterhin verfügbar, und dieser Wert wird in Zukunft wieder zurückgegeben, sobald die vorhandenen Leistungsprobleme behoben wurden.

Ressourcenbegrenzungen, die nur beim Verarbeiten von Pre-Receive-Hooks auftreten, können bei manchen Pre-Receive-Hooks Fehler auslösen.

Actions-Dienste müssen nach der Wiederherstellung einer Appliance aus einer Sicherung, die auf einem anderen Host erstellt wurde, neu gestartet werden.

Nach der Registrierung eines selbstgehosteten Runners mit dem --ephemeral-Parameter auf mehreren Ebenen (z. B. auf Unternehmens- und Organisationsebene) befindet sich der Runner möglicherweise im Leerlauf und muss erneut registriert werden. [Aktualisiert: 17.06.2022]

Bei Verwendung von verschlüsselten SAML-Assertionen mit GitHub Enterprise Server 3.4.0 und 3.4.1 enthält ein neues XML-Attribut WantAssertionsEncrypted im SPSSODescriptor ein ungültiges Attribut für SAML-Metadaten. Bei Identitätsanbietern, die diesen SAML-Metadatenendpunkt nutzen, können bei der Überprüfung des XML-Schemas der SAML-Metadaten Fehler auftreten. Ein Fix wird im nächsten Patchrelease verfügbar sein. [Aktualisiert: 11.04.2022]

Führe eine der folgenden Aktionen aus, um dieses Problem zu umgehen:

• Konfiguriere den Identitätsanbieter neu, indem du eine statische Kopie der SAML-Metadaten ohne das Attribut WantAssertionsEncrypted hochlädst.
• Kopiere die SAML-Metadaten, entferne das Attribut WantAssertionsEncrypted, hoste die Daten auf einem Webserver, und konfiguriere den Identitätsanbieter so neu, dass er auf diese URL verweist.

In einigen Fällen stellen GitHub Advanced Security-Kunden, die ein Upgrade auf GitHub Enterprise Server 3.5 oder höher durchführen, fest, dass Warnungen aus Geheimnisscans in der Webbenutzeroberfläche und der REST-API fehlen. Um sicherzustellen, dass die Warnungen sichtbar bleiben, überspringe Version 3.4 nicht, wenn du ein Upgrade von einer früheren Version auf Version 3.5 oder höher durchführst. In den Patchreleases 3.5.5 und 3.6.1 ist ein Fix verfügbar.

Weitere Informationen zum Planen eines Upgrades über Version 3.4 findest du unter Upgrade-Assistent. [Aktualisiert: 2022-09-01]

GitHub Pages-Builds können für Instanzen in AWS, die für Hochverfügbarkeit konfiguriert sind, zu einem Timeout führen. [Aktualisiert: 28.11.2022]

GitHub Enterprise Server 3.0 wurde am 16. Februar 2022 eingestellt. Das bedeutet, dass nach diesem Datum selbst für kritische Sicherheitsprobleme keine Patches veröffentlicht werden. Um eine bessere Leistung, höhere Sicherheit und neue Features zu erhalten, führe so bald wie möglich ein Upgrade auf die neueste Version von GitHub Enterprise Server durch.

GitHub Enterprise Server 3.1 wurde am 3. Juni 2022 eingestellt. Das bedeutet, dass nach diesem Datum selbst für kritische Sicherheitsprobleme keine Patches veröffentlicht werden. Um eine bessere Leistung, höhere Sicherheit und neue Features zu erhalten, führe so bald wie möglich ein Upgrade auf die neueste Version von GitHub Enterprise Server durch.

Ab GitHub Enterprise Server 3.3 wird GitHub Enterprise Server auf XenServer nicht mehr unterstützt. Wende dich bei Fragen oder Bedenken an den GitHub-Support.

Aufgrund einer geringen Nutzung wurde die Unterstützung der Vorschauversion der Inhaltsverweise-API in GitHub Enterprise Server 3.4 eingestellt. Zuvor konnte über den corsair-preview-Header auf die API zugegriffen werden. Benutzer*innen können auch ohne diese API weiterhin zu externen URLs wechseln. Bei der registrierten Nutzung der Inhaltsverweise-API wird keine Webhookbenachrichtigung mehr für URLs in deinen registrierten Domänen gesendet. Außerdem werden keine gültigen Antwortcodes mehr für versuchte Updates an vorhandenen Inhaltsanhängen zurückgegeben.

Die Unterstützung der Vorschauversion der Verhaltensregeln-API, auf die über den scarlet-witch-preview-Header zugegriffen werden konnte, wird eingestellt. Folglich kann in GitHub Enterprise Server 3.4 nicht mehr darauf zugegriffen werden. Stattdessen solltest du den Endpunkt zum Abrufen von Communityprofilmetriken verwenden, um Informationen zu den Verhaltensregeln eines Repositorys abzurufen. Weitere Informationen findest du im GitHub-Änderungsprotokoll im Hinweis zur Einstellung der Unterstützung: Vorschau der Verhaltensregeln-API.

Ab GitHub Enterprise Server 3.4 wurde die veraltete Version der Endpunkte der OAuth-Anwendungs-API entfernt. Wenn bei diesen Endpunkten der Fehler 404 gemeldet wird, konvertiere deinen Code in Versionen der OAuth-Anwendungs-API, die keine access_tokens in der URL enthalten. Darüber hinaus wurde die Verwendung der API-Authentifizierung unter Verwendung von Abfrageparametern deaktiviert. Stattdessen wird empfohlen, die API-Authentifizierung im Anforderungsheader zu verwenden.

Die Unterstützung des CodeQL-Runners wurde in GitHub Enterprise Server 3.4 eingestellt, und er wird nicht mehr unterstützt. Diese Einstellung betrifft ausschließlich Benutzerinnen, die die CodeQL-Codeüberprüfung in CI/CD-Systemen von Drittanbietern verwenden. GitHub Actions-Benutzerinnen sind nicht betroffen. Es wird dringend empfohlen, dass Kunden eine Migration zur CodeQL-CLI durchführen. Diese CLI ist ein vollumfänglicher Ersatz für den CodeQL-Runner. Weitere Informationen findest du im GitHub-Änderungsprotokoll.

Ab GitHub Enterprise Server 3.1 wurde die Unterstützung für die proprietären Bitcache-Erweiterungen von GitHub schrittweise eingestellt. Diese Erweiterungen gelten in GitHub Enterprise Server ab Version 3.3 als veraltet.

Repositorys, die bereits in deine GitHub Enterprise Server-Instanz mit Version 3.1 oder 3.2 vorhanden und aktiv waren, werden automatisch aktualisiert.

Repositorys, die vor einem Upgrade auf GitHub Enterprise Server 3.3 nicht vorhanden und aktiv waren, bieten möglicherweise keine optimale Leistung, bis eine Wartungsaufgabe für das Repository ausgeführt und erfolgreich abgeschlossen wurde.

Um eine Repositorywartungsaufgabe manuell zu starten, navigiere für jedes betroffene Repository zu https://<hostname>/stafftools/repositories/<owner>/<repository>/network, und klicke auf die Schaltfläche „Zeitplan“.

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. Weitere Informationen findest du im GitHub-Änderungsprotokoll. [Aktualisiert: 14.06.2022]