Enterprise Server 3.7 release notes

On an instance with GitHub Actions enabled, nested calls to reusable workflows within a reusable workflow job with a matrix correctly evaluate contexts within expressions, like strategy: ${{ inputs.strategies }}.

On an instance in a high availability configuration, a git push operation could fail if GitHub Enterprise Server was simultaneously creating the repository on a replica node.

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.

In some cases, graphs on the Management Console's monitor dashboard failed to render.

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.

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

On instances configured to use the private beta of SCIM for GitHub Enterprise Server, users' authentication with SSH keys and personal access tokens failed due to an erroneous requirement for authorization.

After a user imported a repository with push protection enabled, the repository was not immediately visible in the security overview's "Security Coverage" view.

Responses from the /repositories REST API endpoint erroneously included deleted repositories.

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 with check annotations, pull requests "Files changed" tab returned a 500 error and displayed "Oops, something went wrong" in the "Unchanged files with check annotations" section.

On an instance with GitHub Actions enabled, if a user manually triggered a workflow using the REST API but did not specify values for optional booleans, the API failed to validate the request and returned a 422 error.

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.

In some cases on an instance with multiple nodes, GitHub Enterprise Server erroneously stopped writing to replica fileservers, causing repository data to fall out of sync.

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.

On an instance with a GitHub Advanced Security license, if code scanning had been used while running GitHub Enterprise Server 3.4 or earlier, a subsequent upgrade from 3.5 to 3.6 or 3.7 could fail when attempting to add a unique index to a database table.

When the dependency submission API received a submission with one or more dependencies without a version, the dependency graph will now correctly report this fact.

To avoid a failure during a configuration run on a cluster, validation of cluster.conf with the ghe-cluster-config-check utility ensures that the consul-datacenter field for each nodes matches the top-level primary-datacenter field.

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 2.39.2 aktualisiert, die sich auf CVE-2023-22490 und CVE-2023-23946 beziehen.

HOCH: In GitHub Enterprise Server wurde ein Path Traversal-Sicherheitsrisiko identifiziert, das beim Erstellen einer GitHub Pages-Website das Lesen von beliebigen Dateien 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-2023-22380 zugewiesen.

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.

Bei Instanzen, für die sowohl GitHub Connect als auch der automatische Zugriff auf GitHub.com-Aktionen aktiviert war, konnte Dependabot auf GitHub.com gehostete Aktionen nicht aktualisieren.

Bei einer Instanz ohne GitHub Advanced Security-Lizenz konnte die CSV-Datei mit den Details zu GitHub Advanced Security-Mitwirkenden nicht heruntergeladen werden.

Die erfassten Protokolle konnten aufgrund der Einbeziehung von kredz.*-Metriken, die nicht von StatsD analysiert werden können und zu Fehlermeldungen führten, schnell an Umfang zunehmen.

Wenn bei einer Instanz mit einer GitHub Advanced Security-Lizenz während der Ausführung von GitHub Enterprise Server 3.4 oder früher Codeüberprüfungen verwendet wurden, konnte bei einem nachfolgenden Upgrade von 3.5 auf 3.6 oder 3.7 beim Hinzufügen eines eindeutigen Index zu einer Datenbanktabelle ein Fehler auftreten.

Wenn die REST-API zur Abhängigkeitsübermittlung eine Übermittlung mit mindestens einer Abhängigkeit ohne Version empfängt, wird dies nun korrekt im Abhängigkeitsdiagramm angezeigt.

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.

Nachdem ein Websiteadministrator den Stichtag für das Zulassen von SSH-Verbindungen mit RSA-Schlüsseln unter Verwendung von ghe-config app.gitauth.rsa-sha1 angepasst hatte, lehnte die Instanz Verbindungen mit RSA-Schlüsseln weiterhin ab, wenn der Verbindungsversuch mit Hashfunktion SHA-1 signiert war.

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

SSH-Schlüssel und persönliche Zugriffstoken (klassisch) erlaubten keinen REST-API-Zugriff auf Organisationsressourcen, wenn GitHub Enterprise Server mit SCIM konfiguriert war.

Nach dem Deaktivieren der Dependabot-Updates wurde der Avatar für Dependabot in der Zeitleiste der Dependabot-Warnungen als Benutzer @ghost angezeigt.

In einigen Fällen wurde den Benutzern ein 500-Fehler gemeldet, wenn die Einstellungsseite Codesicherheit und Analyse für eine Instanz mit einer sehr hohen Anzahl aktiver Committer angezeigt wurde.

Einige Links zum Kontaktieren des GitHub-Supports oder zum Anzeigen der GitHub Enterprise Server-Versionshinweise waren nicht korrekt.

Die Anzahl der zusätzlichen Committer für GitHub Advanced Security wurde stets als 0 angezeigt.

In einigen Fällen konnten Benutzer vorhandene Issues nicht in Diskussionen umwandeln. Wenn der Vorgang zum Umwandeln eines Issues in eine Diskussion nicht abgeschlossen werden kann, findest du weitere Informationen im Abschnitt „Bekannte Probleme“ weiter unten.

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.

Einige Dienste sind fälschlicherweise nicht über den internen Proxy, sondern direkt mit kafka-lite verbunden. In einer Clusterumgebung, in der Webdienste und Auftragsdienste auf separaten Knoten ausgeführt werden, wurden vom Insights-Auftragsdienst generierte Nachrichten nicht an kafka-lite übermittelt.

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.

Bei Datenmigrationsvorgängen konnte ein Fehler auftreten, wenn die zugrunde liegende Datenbanktabelle nur einen einzelnen Datensatz enthielt.

Das Sortieren und Filtern der Liste benutzerdefinierter Muster für die Geheimnisüberprüfung auf Organisationsebene funktionierte nicht ordnungsgemäß.

Nach dem Upgrade auf GitHub Enterprise Server 3.7 kann das Anzeigen der Seite mit den Sicherheitseinstellungen für eine Organisation oder ein Repository zu einem 500-Fehler führen, wenn ein GitHub Advanced Security-Abgleichsauftrag nicht abgeschlossen war, bevor das Upgrade gestartet wurde.

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

launch.*-Metriken, die nicht von statsd analysiert werden konnten, da die resultierenden statsd-Fehler dazu führten, dass die gesammelten Protokolle anwuchsen, wurden entfernt.

Beim Aktualisieren benutzerdefinierter Muster wurde der Musterzustand sofort auf „veröffentlicht“ festgelegt.

Die Zuverlässigkeit des Echtzeitupdatediensts (Alive) wurde verbessert, um ihn gegenüber Netzwerkproblemen mit Redis resilienter zu machen.

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

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.

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

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.

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.

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

Wenn du in den Einstellungen eines Repositorys die Option aktivierst, die Benutzern mit Lesezugriff das Erstellen von Diskussionen gestattet, wird diese Funktionalität nicht aktiviert.

In einigen Fällen können Benutzer vorhandene Issues nicht in Diskussionen umwandeln.

Während der Überprüfungsphase einer Konfigurationsausführung kann ein Fehler No such object für die Dienste Notebook und Viewscreen auftreten. Dieser Fehler kann ignoriert werden, da die Dienste dennoch ordnungsgemäß gestartet werden sollten.

Nach einem Upgrade auf GitHub Enterprise Server 3.6 oder höher können vorhandene Inkonsistenzen in einem Repository wie fehlerhafte Verweise oder fehlende Objekte jetzt möglicherweise als Fehler wie invalid sha1 pointer 0000000000000000000000000000000000000000, Zero-length loose reference file oder Zero-length loose object file gemeldet werden. Bisher wurden diese Indikatoren für Repositorybeschädigungen möglicherweise unbemerkt ignoriert. GitHub Enterprise Server verwendet jetzt eine aktualisierte Git-Version mit aktivierter sorgfältiger Fehlerberichterstellung. Weitere Informationen findest du im Git-Projekt in diesem Upstreamcommit.

Wenn du vermutest, dass ein Problem wie dieses in einem deiner Repositorys besteht, wende dich an den GitHub Enterprise-Support, um Unterstützung zu erhalten.

Bei Instanzen mit einer hohen anhaltenden Anzahl gleichzeitiger Git-Anforderungen können Leistungsprobleme auftreten. Wenn du vermutest, dass sich dieses Problem auf deine Instanz auswirkt, wende dich an den GitHub-Support. Weitere Informationen findest du unter Erstellen eines Supporttickets. [Aktualisiert: 2022-12-07]

Bei Instanzen in einer Hochverfügbarkeitskonfiguration können git push-Vorgänge in den folgenden Situationen fehlschlagen. [Aktualisiert: 17.03.2023]

• Während der Erstellung des Repositorys auf einem Replikatknoten
• Nach einem Fehler beim Erstellen des Repositorys auf einem Replikatknoten vor der automatischen Reparatur des Repositorys

Auf Instanzen in einer Hochverfügbarkeitskonfiguration sollten Standortadministrator*innen die Befehle ghe-repl-start und ghe-repl-stop nur ausführen, solange sich die Instanz im Wartungsmodus befindet. Weitere Informationen findest du unter Wartungsmodus aktivieren und planen und unter Informationen zur Hochverfügbarkeitskonfiguration. [Aktualisiert: 17.03.2023]

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.

Eine Racebedingung hat Upgrades auf GitHub Enterprise Server 3.6 oder höher blockiert, bis das Upgrade durch Websiteadministrator*innen wiederholt wurde.

Wenn Websiteadministrator*innen den Befehl ghe-repl-status für ein Cachereplikat über die Verwaltungsshell (SSH) ausgeführt haben, meldete der Befehl fälschlicherweise allgemeine Informationen zum Replikationsstatus des Git- und Alambic-Clusters in einer Form, die als ausschließlich bezogen auf die Cachereplikation missverstanden werden konnte.

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.

In einer Hochverfügbarkeitskonfiguration konnten Standortadministrator*innen nach der Heraufstufung eines Replikats zum primären Knoten nicht mit dem Befehl ghe-repl-stop -f erzwingen, dass die Replikation auf einem sekundären Replikatknoten beendet wird.

Wenn bei Verwendung der Repositoryzwischenspeicherung auf einer Instanz mit Hochverfügbarkeitskonfiguration ein Git-Client SSH anstelle von HTTPS für die Remote-URL eines Repositorys verwendet hat, rief Git LFS Objekte vom primären Knoten der Instanz und nicht vom entsprechenden Cachereplikatknotens ab.

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.

In einigen Fällen gaben Suchvorgänge über die API einen 500-Fehler zurück.

Das Hinzufügen von Projektmitarbeiter*innen zu einem benutzereigenen Fork eines privaten, organisationseigenen Repositorys mit Selektierungs-, Wartungs- oder benutzerdefiniertem Zugriff führte zu einem 500-Fehler.

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.

Das Schließen einer Dependabot-Warnung, die bestimmte Zeichen enthielt, konnte zu einem 400-Fehler führen.

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.

Bei einer Instanz, die SAML für die Authentifizierung verwendet, wurde das Dropdownmenü SSO konfigurieren fälschlicherweise für persönliche Zugriffstoken und SSH-Schlüssel angezeigt.

Bei einem Upgrade von GitHub Enterprise Server 3.5 auf 3.7 konnte ein Fehler auftreten, da die Instanz gelöschte Repositorys noch nicht bereinigt hatte.

In einer Konfiguration mit Hochverfügbarkeit oder Repositoryzwischenspeicherung konnten Unicorn-Dienste auf anderen Knoten als dem primären Knoten keine Protokollereignisse an den primären Knoten senden.

Behebt einen Fehler, durch den eine GHES-Protokolldatei sehr schnell gefüllt werden konnte, was dazu führen konnte, dass auf dem Stammlaufwerk der freie Speicherplatz ausging.

Beim Anzeigen der Ergebnisse der Codeüberprüfung für Ruby wurde fälschlicherweise eine Betabezeichnung angezeigt.

Nachdem Unternehmensbesitzer*innen Dependabot-Warnungen aktiviert haben, stellt GitHub Enterprise Server die Synchronisierung von Empfehlungsdaten in die Warteschlange, um stündliche Updates von GitHub.com sicherzustellen.

Die Liste der zuletzt aufgerufenen Repositorys von Benutzer*innen enthält jetzt keine gelöschten Repositorys mehr.

Für Teilnehmer in der privaten Betaversion von SCIM für GitHub Enterprise Server werden jetzt benutzerdefinierte Zuordnungen für SAML-Benutzerattribute unterstützt. Benutzerdefinierte Zuordnungen ermöglichen die Verwendung eines anderen Werts als NameID als eindeutig identifizierenden Anspruch während der SAML-Authentifizierung. Weitere Informationen findest du unter Konfigurieren der Benutzerbereitstellung mit SCIM für dein Unternehmen. [Aktualisiert: 27.02.2023]

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.

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

Wenn du in den Einstellungen eines Repositorys die Option aktivierst, die Benutzern mit Lesezugriff das Erstellen von Diskussionen gestattet, wird diese Funktionalität nicht aktiviert.

In einigen Fällen können Benutzer vorhandene Issues nicht in Diskussionen umwandeln.

Während der Überprüfungsphase einer Konfigurationsausführung kann ein Fehler No such object für die Dienste Notebook und Viewscreen auftreten. Dieser Fehler kann ignoriert werden, da die Dienste dennoch ordnungsgemäß gestartet werden sollten.

Nach einem Upgrade auf GitHub Enterprise Server 3.6 oder höher können vorhandene Inkonsistenzen in einem Repository wie fehlerhafte Verweise oder fehlende Objekte jetzt möglicherweise als Fehler wie invalid sha1 pointer 0000000000000000000000000000000000000000, Zero-length loose reference file oder Zero-length loose object file gemeldet werden. Bisher wurden diese Indikatoren für Repositorybeschädigungen möglicherweise unbemerkt ignoriert. GitHub Enterprise Server verwendet jetzt eine aktualisierte Git-Version mit aktivierter sorgfältiger Fehlerberichterstellung. Weitere Informationen findest du im Git-Projekt in diesem Upstreamcommit.

Wenn du vermutest, dass ein Problem wie dieses in einem deiner Repositorys besteht, wende dich an den GitHub Enterprise-Support, um Unterstützung zu erhalten.

Bei Instanzen mit einer hohen anhaltenden Anzahl gleichzeitiger Git-Anforderungen können Leistungsprobleme auftreten. Wenn du vermutest, dass sich dieses Problem auf deine Instanz auswirkt, wende dich an den GitHub-Support. Weitere Informationen findest du unter Erstellen eines Supporttickets. [Aktualisiert: 2022-12-07]

Beim Überprüfen der Domäneneinstellungen für eine Instanz mit aktivierter TLS-Isolation und Unterdomänenisolation werden in der Verwaltungskonsole die beiden neuen Unterdomänen von GitHub Enterprise Server 3.7, http(s)://notebooks.HOSTNAME und http(s)://viewscreen.HOSTNAME, in der Liste der Domänen nicht angezeigt. [Aktualisiert: 12.1.2023]

Für Teilnehmende an der privaten Betaversion von SCIM für GitHub Enterprise Server ist die Authentifizierung für Anforderungen an andere Ressourcen als die REST-API über ein personal access token oder einen SSH-Schlüssel möglicherweise nicht erfolgreich. Ein Fix wird in einer demnächst verfügbaren Version von GitHub Enterprise Server bereitgestellt. [Aktualisiert: 27.02.2023]

HOCH: In GitHub Enterprise Server wurde eine unzulässige Neutralisierung von Argumenttrennzeichen in einem Befehlsrisiko identifiziert, das die Remotecodeausführung ermöglichte. Um dieses Sicherheitsrisiko auszunutzen, benötigten Angreifer*innen die Berechtigung, GitHub Pages-Instanzen mit GitHub Actions zu erstellen. Dieser Fehler wurde ursprünglich über das GitHub Bug Bounty-Programm gemeldet und CVE-2022-23740 zugewiesen. [Aktualisiert: 02.12.2022]

HOCH: Innerhalb von Pages wurde eine Überprüfung hinzugefügt, um sicherzustellen, dass das Arbeitsverzeichnis vor dem Entpacken neuer Inhalte leer ist, um einen Fehler beim Überschreiben von Dateien zu vermeiden. Dieses Sicherheitsrisiko wurde CVE-2022-46255 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: 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.

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

Beim Ausführen des Befehls ghe-spokesctl wurde der Fehler failed to get repo metrics zurückgegeben.

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.

Statusdetails für die Replikation von Git LFS-Objekten auf Replikatknoten des Repositorycaches waren in der Ausgabe von ghe-repl-status auf diesen Knoten nicht sichtbar.

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 konfiguriert hatten, wurde auf der Seite Hooks der Instanzen nicht immer der richtige Status für den Hook angezeigt.

In einigen Fällen hat eine Instanz ein aktives Repository durch ein gelöschtes Repository ersetzt.

Git LFS-Objekte in einem Repository mit einer Cachereplikationsrichtlinie wurden nicht in Replikate im Cache kopiert, wenn die Gesamtanzahl der Objekte im Repository 5.000 überschritt.

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.

Auf einer Instanz mit konfigurierten GitHub-Paketen konnten der Paketupload und die Installation für Kund*innen, die eine VPC-Endpunkt-URL für AWS S3-Blobspeicher verwendet haben, zu Fehlern führen.

In einigen Fällen konnten nach dem Upgrade auf GitHub Enterprise Server 3.7.0 beim Initiieren von Git-Vorgängen über SSH oder HTTPS die Fehler Internal Server Error oder 500 auftreten.

Wenn Websiteadministratorinnen GitHub Actions noch nicht für die Instanz konfiguriert haben, fordert die Benutzeroberfläche zum Einrichten der Codeüberprüfung die Benutzerinnen auf, GitHub Actions zu konfigurieren.

Um Fehler bei der Domänenüberprüfung aufgrund des von DNS-Anbietern für DNS-Einträge erzwungenen Grenzwerts von 63 Zeichen zu vermeiden, ist der von GitHub generierte TXT-Eintrag zum Überprüfen des Domänenbesitzes jetzt auf 63 Zeichen beschränkt.

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.

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

Wenn du in den Einstellungen eines Repositorys die Option aktivierst, die Benutzern mit Lesezugriff das Erstellen von Diskussionen gestattet, wird diese Funktionalität nicht aktiviert.

In einigen Fällen können Benutzer vorhandene Issues nicht in Diskussionen umwandeln.

Während der Überprüfungsphase einer Konfigurationsausführung kann ein Fehler No such object für die Dienste Notebook und Viewscreen auftreten. Dieser Fehler kann ignoriert werden, da die Dienste dennoch ordnungsgemäß gestartet werden sollten.

Nach einem Upgrade auf GitHub Enterprise Server 3.6 oder höher können vorhandene Inkonsistenzen in einem Repository wie fehlerhafte Verweise oder fehlende Objekte jetzt möglicherweise als Fehler wie invalid sha1 pointer 0000000000000000000000000000000000000000, Zero-length loose reference file oder Zero-length loose object file gemeldet werden. Bisher wurden diese Indikatoren für Repositorybeschädigungen möglicherweise unbemerkt ignoriert. GitHub Enterprise Server verwendet jetzt eine aktualisierte Git-Version mit aktivierter sorgfältiger Fehlerberichterstellung. Weitere Informationen findest du im Git-Projekt in diesem Upstreamcommit.

Wenn du vermutest, dass ein Problem wie dieses in einem deiner Repositorys besteht, wende dich an den GitHub Enterprise-Support, um Unterstützung zu erhalten.

Bei Instanzen mit einer hohen anhaltenden Anzahl gleichzeitiger Git-Anforderungen können Leistungsprobleme auftreten. Wenn du vermutest, dass sich dieses Problem auf deine Instanz auswirkt, wende dich an den GitHub-Support. Weitere Informationen findest du unter Erstellen eines Supporttickets. [Aktualisiert: 2022-12-07]

Beim Überprüfen der Domäneneinstellungen für eine Instanz mit aktivierter TLS-Isolation und Unterdomänenisolation werden in der Verwaltungskonsole die beiden neuen Unterdomänen von GitHub Enterprise Server 3.7, http(s)://notebooks.HOSTNAME und http(s)://viewscreen.HOSTNAME, in der Liste der Domänen nicht angezeigt. [Aktualisiert: 12.1.2023]

Bei Instanzen in einer Hochverfügbarkeitskonfiguration können git push-Vorgänge in den folgenden Situationen fehlschlagen. [Aktualisiert: 17.03.2023]

• Während der Erstellung des Repositorys auf einem Replikatknoten
• Nach einem Fehler beim Erstellen des Repositorys auf einem Replikatknoten vor der automatischen Reparatur des Repositorys

Auf Instanzen in einer Hochverfügbarkeitskonfiguration sollten Standortadministrator*innen die Befehle ghe-repl-start und ghe-repl-stop nur ausführen, solange sich die Instanz im Wartungsmodus befindet. Weitere Informationen findest du unter Wartungsmodus aktivieren und planen und unter Informationen zur Hochverfügbarkeitskonfiguration. [Aktualisiert: 17.03.2023]

Um die Sicherheit der Verwaltungskonsole zu erhöhen, können Websiteadministrator*innen die Ratenbegrenzung für Anmeldeversuche sowie die Sperrdauer nach Überschreitung der Ratenbegrenzung konfigurieren. Weitere Informationen findest du unter Configuring rate limits (Konfigurieren von Ratenbegrenzungen).

Die Mindestanforderungen an Kennwörter für die Verwaltungskonsole sind strenger.

Authentifizierungsversuche bei der Verwaltungskonsole sowie von Websiteadministrator*innen innerhalb der Verwaltungskonsole vorgenommene Änderungen werden in die Protokolldatei /var/log/enterprise-manage/audit.log geschrieben.

Azure Maps ersetzt MapBox zum Rendern von GeoJSON-Dateien als grafische Karten. Administrator*innen können das Kartenrendering aktivieren und ein Azure Maps-Token an der Verwaltungskonsole bereitstellen. Weitere Informationen findest du unter Verwalten der Instanz über die Verwaltungskonsole.

Benutzer*innen können Commits mithilfe eines öffentlichen SSH-Schlüssels überprüfen. Weitere Informationen findest du unter Informationen zur Commitsignaturverifizierung.

Websiteadministratorinnen können Benutzerinnen und Gruppen auf einer GitHub Enterprise Server-Instanz automatisch mit SCIM bereitstellen. SCIM für GitHub Enterprise Server befindet sich in der privaten Betaphase und kann geändert werden. Weitere Informationen findest du in der REST-API-Dokumentation unter Konfigurieren der Benutzerbereitstellung mit SCIM für dein Unternehmen und SCIM.

Benutzer einer Instanz mit einer GitHub Advanced Security-Lizenz können Warnungen der Codeüberprüfung in ihrem Repository auf der Registerkarte Unterhaltung eines Pull Requests anzeigen und kommentieren. Wenn die Branchschutzregel Konversationsauflösung vor dem Zusammenführen erforderlich für das Repository aktiviert ist, müssen alle Kommentare zu diesen Codeüberprüfungswarnungen aufgelöst werden, bevor ein Benutzer den Pull Request zusammenführt. Weitere Informationen findest du unter Informationen zur Codeüberprüfung, Informationen zu Pull Request-Reviews und Informationen zu geschützten Branches.

Um den Rollout der Geheimnisüberprüfung für Instanzen mit Dutzenden, Hunderten oder sogar Tausenden von Organisationen zu vereinfachen, können Unternehmensbesitzer*innen auf einer Instanz mit einer GitHub Advanced Security-Lizenz die Geheimnisüberprüfung und den Pushschutz für die Instanz über die Weboberfläche aktivieren. Weitere Informationen findest du unter Verwalten von GitHub Advanced Security-Features für dein Unternehmen.

Organisationsbesitzer*innen für eine Instanz mit einer GitHub Advanced Security-Lizenz können einen Probelauf von benutzerdefinierten Mustern für die Geheimnisüberprüfung für alle Repositorys innerhalb einer Organisation durchführen. Weitere Informationen findest du unter Definieren benutzerdefinierter Muster für Geheimnisüberprüfungen.

Wenn Websiteadministratorinnen E-Mail-Benachrichtigungen für eine Instanz mit einer GitHub Advanced Security-Lizenz aktiviert haben, erhalten Benutzerinnen, die die Warnungen zur Geheimnisüberprüfung eines Repositorys überwachen, eine E-Mail-Benachrichtigung, sobald Mitwirkende ein durch den Pushschutz blockiertes Geheimnis umgehen. Bisher wurden keine Benachrichtigungen gesendet, wenn das Geheimnis als False Positive gekennzeichnet oder in Tests verwendet wurde. Weitere Informationen findest du unter Schützen von Pushvorgängen durch die Geheimnisüberprüfung und Konfigurieren von E-Mails für Benachrichtigungen.

Um die Verwaltung von Dutzenden oder Hunderten von benutzerdefinierten Mustern für die Geheimnisüberprüfung zu vereinfachen, können Benutzerinnen, Organisationsbesitzerinnen oder Unternehmensbesitzer*innen auf einer Instanz mit einer GitHub Advanced Security-Lizenz die Liste der Muster für ein Repository, eine Organisation oder die gesamte Instanz sortieren und filtern. Weitere Informationen findest du unter Definieren benutzerdefinierter Muster für Geheimnisüberprüfungen.

Benutzer*innen einer Instanz mit einer GitHub Advanced Security-Lizenz, die Pushvorgänge durch die Geheimnisüberprüfung schützen, können einen benutzerdefinierten Link angeben, der in der Fehlermeldung angezeigt wird, wenn der Pushschutz ein potenzielles Geheimnis erkennt und blockiert. Weitere Informationen findest du unter Schützen von Pushs mit Geheimnisüberprüfung.

Benutzer*innen können CodeQL-Pakete in der Containerregistrierung veröffentlichen. Weitere Informationen findest du in der Dokumentation zur CodeQL-CLI unter Erstellen und Verwenden von CodeQL-Paketen.

Benutzer*innen einer Instanz mit einer GitHub Advanced Security-Lizenz können CodeQL-Pakete mit der Codeüberprüfung verwenden, einschließlich der Pakete, die in der GitHub Container Registry der Instanz veröffentlicht werden. Weitere Informationen findest du in der Dokumentation zur CodeQL-CLI unter Konfigurieren der Codeüberprüfung und Veröffentlichen und Verwenden von CodeQL-Paketen.

Benutzer*innen einer Instanz mit einer GitHub Advanced Security-Lizenz können unnötige CodeQL-Abfragen für die Codeüberprüfung mithilfe von Abfragefiltern ausschließen. Weitere Informationen findest du unter Konfigurieren der Codeüberprüfung.

Unternehmensbesitzer*innen einer Instanz mit einer GitHub Advanced Security-Lizenz können Codeüberprüfungsergebnisse für die gesamte Instanz mithilfe der REST-API abrufen. Der neue Endpunkt ergänzt die vorhandenen Endpunkte für Repositorys und Organisationen. Weitere Informationen findest du in der REST-API-Dokumentation unter Codeüberprüfung.

Organisationsbesitzer*innen für eine Instanz mit einer GitHub Advanced Security-Lizenz können den Aktivierungsstatus abrufen oder die automatische Aktivierung der folgenden Features mithilfe der REST-API konfigurieren.

• GitHub Advanced Security
• Geheime Überprüfung
• Pushschutz

Weitere Informationen findest du in der REST-API-Dokumentation unter Organisationen.

Benutzer*innen einer Instanz mit einer GitHub Advanced Security-Lizenz können Cursor verwenden, um Ergebnisse mit Warnungen zur Geheimnisüberprüfung zu paginieren, die mit den Organisations- und Repositoryendpunkten der REST-API abgerufen werden. Weitere Informationen findest du in der REST-API-Dokumentation unter Geheimnisüberprüfung.

Die Sicherheitsübersicht für die Instanz enthält Informationen zu Dependabot. Weitere Informationen findest du unter Informationen zur Sicherheitsübersicht.

Benutzer können weitere Informationen zu der Aktivität anzeigen, die einer Dependabot-Warnung zugeordnet ist. In den Details für eine Dependabot-Warnung können Benutzer*innen eine Zeitachse mit Ereignissen anzeigen, z. B. wann die Warnung geöffnet, behoben oder erneut geöffnet wurde. Ereignisse zeigen auch zusätzliche Metadaten an, sofern sie verfügbar sind, z. B. relevante Pull Requests. Weitere Informationen findest du unter Informationen zu Dependabot-Warnungen."

Die Dependabot-Warnungen der Benutzer*innen werden standardmäßig nach Wichtigkeit sortiert. Bei der Wichtigkeit werden CVSS als primärer Faktor sowie potenzielle Risiken, Relevanz und die einfache Behebung des Sicherheitsrisikos eingestuft. Die Berechnung verbessert sich im Lauf der Zeit.

Benutzer*innen können Dependabot-Warnungen nach dem Bereich der Abhängigkeit sortieren, entweder nach Runtime oder Entwicklung.

Benutzer*innen können optional einen Kommentar hinzufügen, wenn sie eine Dependabot-Warnung schließen. Kommentare beim Schließen werden in der Ereigniszeitachse und im Feld dismissComment im RepositoryVulnerabilityAlert-Objekt der GraphQL-API angezeigt. Weitere Informationen zur GraphQL-API findest du in der Dokumentation zur GraphQL-API unter Objekte.

Benutzer*innen können mehrere Dependabot-Warnungen auswählen und anschließend schließen oder erneut öffnen. Beispielsweise kannst du auf der Registerkarte Geschlossene Warnungen mehrere Warnungen auswählen, die zuvor geschlossen wurden, und sie dann alle gleichzeitig erneut öffnen.

Organisationsbesitzer*innen einer Instanz können den Aktivierungsstatus abrufen oder die automatische Aktivierung der folgenden Features zur Abhängigkeitsverwaltung mithilfe der REST-API konfigurieren.

• Abhängigkeitsdiagramm
• Dependabot-Warnungen
• Dependabot-Sicherheitsupdates

Weitere Informationen findest du in der REST-API-Dokumentation unter Organisationen.

Unternehmensbesitzer, Organisationsbesitzer und Sicherheits-Manager können auf eine zentralisierte Risikoansicht für die gesamte Instanz zugreifen. Die Ansicht enthält auch eine auf Warnungen ausgerichtete Ansicht aller Codeüberprüfungs-, Geheimnisüberprüfungs- und Dependabot-Warnungen. Unternehmensbesitzer können Warnungen für Organisationen anzeigen, deren Besitzer sie sind. Organisationsbesitzer und Sicherheits-Manager können Repositorys und Warnungen für die Organisationen anzeigen, auf die sie vollständigen Zugriff haben. Weitere Informationen findest du unter Informationen zur Sicherheitsübersicht.

Organisationsbesitzerinnen können Teams von Sicherheits-Managerinnen mithilfe der REST-API verwalten. Weitere Informationen findest du in der REST-API-Dokumentation unter Sicherheits-Manager.

Benutzer*innen können die folgenden Verbesserungen an der GitHub Advisory Database nutzen.

• Die Datenbank zeigt beispielsweise Empfehlungen für Elixir an, den Hex-Paket-Manager von Erlang.
• Benutzer*innen können Empfehlungen zu Schadsoftware finden, indem sie nach type:malware suchen.
• Die Datenbank zeigt Empfehlungen für GitHub Actions-Sicherheitsrisiken an.

Weitere Informationen findest du unter Durchsuchen von Sicherheitsempfehlungen in GitHub Advisory Database.

Benutzer*innen können das Abhängigkeitsdiagramm eines Repositorys auffüllen, indem sie die Abhängigkeiten für das Repository mithilfe der REST-API übermitteln. Das Abhängigkeitsdiagramm unterstützt Dependabot-Warnungen und Dependabot-Sicherheitsupdates. Weitere Informationen findest du unter Verwenden der Abhängigkeitsübermittlungs-API.

GitHub Actions unterstützt Google Cloud Storage als Speicheranbieter für Protokolle, Artefakte und Caches. Weitere Informationen findest du unter Aktivieren von GitHub Actions mit Google Cloud Storage.

GitHub Actions-Benutzer*innen, die die Abhängigkeitszwischenspeicherung zum Beschleunigen von Workflows verwenden, können jetzt die GitHub CLI nutzen, um den GitHub Actions-Cache für ein Repository zu verwalten. Installiere die Erweiterung gh-actions-cache, um Caches mithilfe der GitHub CLI zu verwalten. Weitere Informationen findest du in der gh-actions-cache-Dokumentation.

Erneute Ausführungen von Workflows in GitHub Actions verwenden für die Berechtigungsauswertung den Akteur, der den Workflow ursprünglich ausgelöst hat. Der Akteur, der die erneute Ausführung ausgelöst hat, wird weiterhin auf der Benutzeroberfläche angezeigt und ist in einem Workflow über das Feld triggering_actor im github-Kontext zugänglich. Weitere Informationen findest du unter Erneutes Ausführen von Workflows und Aufträgen und Kontexte.

Benutzer*innen können wiederverwendbare Workflows aus einer Matrix oder anderen wiederverwendbaren Workflows aufrufen. Weitere Informationen findest du unter Wiederverwenden von Workflows.

Beim Abfragen von GitHub Actions nach Artefakten gibt die REST-API Informationen zu der Ausführung und dem Branch zurück, in der bzw. dem das Artefakt generiert wurde. Weitere Informationen findest du in der REST-API-Dokumentation unter GitHub Actions-Artefakte.

Um sichere Cloudbereitstellungen im großen Stil zu unterstützen, können Organisationsbesitzerinnen und Repositoryadministratorinnen die folgenden Aufgaben mit der OpenID Connect-REST-API ausführen. Weitere Informationen findest du in der REST-API-Dokumentation unter GitHub Actions OIDC.

• Aktiviere eine übergreifende OpenID Connect-Standardkonfiguration für alle Cloudbereitstellungsworkflows, indem du das subject-Anspruchsformat anpasst.
• Stelle zusätzliche Compliance und Sicherheit für OpenID Connect-Bereitstellungen sicher, indem du die issuer-URL an das Datenfeld des Unternehmens anfügst.
• Konfiguriere erweiterte OpenID Connect-Richtlinien mithilfe zusätzlicher OpenID Connect-Tokenansprüche wie repository_id und repo_visibility.

Weitere Informationen findest du unter About security hardening with OpenID Connect („Informationen zur Sicherheitshärtung mit OpenID Connect“).

GitHub Actions-Benutzer*innen, die die Abhängigkeitszwischenspeicherung verwenden, um Workflows zu beschleunigen, können jetzt die GitHub Actions-Cache-REST-API verwenden, um die folgenden Aufgaben auszuführen.

• Auflisten aller Caches in einem Repository und Sortieren nach Metadaten
• Löschen eines beschädigten oder veralteten Cacheeintrags Weitere Informationen findest du in der REST-API-Dokumentation unter Zwischenspeichern von Abhängigkeiten zum Beschleunigen von Workflows und GitHub Actions-Cache.

Wenn ein nicht kurzlebiger selbstgehosteter GitHub Actions-Runner länger als 14 Tage nicht mit der GitHub Enterprise Server-Instanz kommuniziert, entfernt die Instanz den Runner automatisch. Wenn ein kurzlebiger selbstgehosteter Runner länger als einen Tag nicht mit der Instanz kommuniziert, entfernt die Instanz den Runner automatisch. Zuvor wurden Runner von GitHub Enterprise Server nach 30 Tagen entfernt. Weitere Informationen findest du unter „Informationen zu selbstgehosteten Runnern“.

GitHub Actions kann selbstgehostete macOS-Workflows in einer macOS-Arm64-Runtime mit Runner-Unterstützung für Apple Silicon wie den M1- oder M2-Chip ausführen. Weitere Informationen findest du unter Verwenden selbstgehosteter Runner in einem Workflow.

Benutzer*innen können eine GitHub Pages-Website mithilfe von GitHub Actions direkt aus einem Repository bereitstellen, ohne eine Veröffentlichungsquelle zu konfigurieren. Die Verwendung von GitHub Actions bietet Kontrolle über das Dokumenterstellungsframework und die Version sowie mehr Kontrolle über den Veröffentlichungsprozess mit Features wie Bereitstellungsgates. Weitere Informationen findest du unter Konfigurieren einer Veröffentlichungsquelle für deine GitHub Pages-Website.

Unternehmensbesitzerinnen können verhindern, dass Benutzerinnen Repositorys erstellen, die ihren Benutzerkonten gehören. Weitere Informationen findest du unter Erzwingen von Repositoryverwaltungsrichtlinien in deinem Unternehmen.

Unternehmensbesitzerinnen können steuern, wo Benutzerinnen Repositorys forken können. Das Forken kann auf voreingestellte Kombinationen aus Organisationen, die Organisation des übergeordneten Repositorys, Benutzerkonten oder auf alles beschränkt sein. Weitere Informationen findest du unter Erzwingen von Repositoryverwaltungsrichtlinien in deinem Unternehmen.

Repositoryadministrator*innen können potenziell schädliche Pushvorgänge blockieren, indem sie die Anzahl von Branches und Tags einschränken, die durch einen einzelnen Push aktualisiert werden können. Standardmäßig gibt es keine Begrenzung der Anzahl von Branches und Tags, die in einem einzelnen Push aktualisiert werden können. Weitere Informationen findest du unter Verwalten der Pushrichtlinie für dein Repository.

Benutzer*innen können die Standardcommitmeldung beim Squashmerge eines Pull Requests weiter anpassen. Weitere Informationen findest du unter Konfigurieren der Commitzusammenführung für Pull Requests und Konfigurieren des Commit-Squashings für Pull Requests.

Benutzer*innen können einen Branch über die Übersichtsseite Branches eines Repositorys erstellen, indem sie auf Neuer Branch klicken. Weitere Informationen findest du unter Erstellen und Löschen von Branches innerhalb deines Repositorys.

Wenn Benutzer*innen eine Datei umbenennen oder in ein neues Verzeichnis verschieben und mindestens die Hälfte des Dateiinhalts identisch ist, zeigt der Commitverlauf ähnlich wie bei git log --follow an, dass die Datei umbenannt wurde. Weitere Informationen findest du im GitHub-Blog. [Aktualisiert: 10.02.2023]

An der Erstellung und Verwaltung von Forks wurden Verbesserungen vorgenommen.

• Beim Forken eines Repositorys können Benutzer*innen nur den Standardbranch des Repositorys in den Fork einschließen.
• Benutzer*innen können die Schaltfläche Forken eines Repositorys verwenden, um vorhandene Forks des Repositorys anzuzeigen.
• Die Schaltfläche Upstream abrufen wurde in Fork synchronisieren umbenannt, um das Verhalten der Schaltfläche besser zu beschreiben. Wenn die Synchronisierung einen Konflikt verursacht, fordert die Webbenutzeroberfläche die Benutzer*innen auf, Änderungen am übergeordneten Repository beizutragen, Änderungen zu verwerfen oder den Konflikt zu beheben.
• In Situationen, in denen Personen innerhalb einer Organisation arbeiten und ein Repository nicht in eine andere Organisation oder ein anderes Benutzerkonto forken möchten, können Benutzer*innen ein Repository in derselben Organisation wie das übergeordnete Repository forken.
• Benutzerinnen können ein internes Repository in eine andere Organisation forken, und der Fork bleibt intern sichtbar. Beim Forken eines internen Repositorys können Benutzerinnen auswählen, welche Organisation den Fork besitzen soll.

Weitere Informationen findest du unter Forken eines Repositorys.

Repositoryadministratorinnen können die Erstellung von Branches, die einem konfigurierten Namensmuster entsprechen, über die Branchschutzregel Pushvorgänge zum Erstellen entsprechender Branches einschränken blockieren. Beispiel: Wenn sich der Standardbranch eines Repositorys von master in main ändert, können Repositoryadministratorinnen die nachfolgende Erstellung oder den Push des master-Branchs verhindern. Weitere Informationen findest du unter Informationen zu geschützten Branches und Verwalten von Branchschutzregeln.

Benutzer*innen können Dateien mit geoJSON-, topoJSON- und STL-Diagrammen erstellen und die Diagramme auf der Weboberfläche rendern. Weitere Informationen findest du unter Arbeiten mit Nicht-Codedateien.

Benutzer*innen können automatisch verknüpfte Verweise entweder mit alphanumerischen oder mit numerischen Bezeichnern erstellen. Weitere Informationen findest du unter Konfigurieren von automatischen Verknüpfungen zum Verweisen auf externe Ressourcen.

Benutzer*innen können in der Dateisuche Ausschlüsse wie vendor/ und build/ mithilfe von linguist-Attributen in einer .gitattributes-Datei anpassen. Weitere Informationen findest du unter Suchen nach Dateien auf GitHub und unter Anpassen der Darstellung geänderter Dateien auf GitHub.

Benutzer*innen können die in einem einzelnen Commit geänderten Dateien mithilfe der Strukturansicht durchsuchen. Weitere Informationen findest du unter Informationen zu Commits.

Benutzer*innen können vorhandene Branches oder Pull Requests manuell mit einem Issue über den Abschnitt „Entwicklung“ auf der Randleiste des Issues verknüpfen. Weitere Informationen findest du unter Verknüpfen eines Pull Requests mit einem Issue.

Benutzer*innen können beim Schreiben von Markdown die Mermaid-Syntax verwenden, die beim Rendern des Markdowns ein Diagramm anzeigt. Weitere Informationen findest du unter Erstellen von Diagrammen.

Benutzer*innen können mathematische Ausdrücke zusätzlich zu den vorhandenen Trennzeichen mithilfe von Fenced-Code-Blöcken mit der math-Syntax schreiben. $$ ist bei dieser Methode nicht erforderlich. Weitere Informationen findest du unter Schreiben mathematischer Ausdrücke.

• Hinweis: Dieses Feature ist in GitHub Enterprise Server 3.7 nicht verfügbar. Dieses Feature wird in einer der nächsten Versionen verfügbar sein. [Aktualisiert: 16.11.2022]

Benutzer können Karten unter Verwendung von Fenced-Code-Blöcken mit der geojson- oder topojson-Syntax direkt in Markdown rendern und STL-3D-Renderings mithilfe der stl-Syntax einbetten. Weitere Informationen findest du unter Erstellen von Diagrammen.

In Markdown können Benutzer*innen Syntax im LaTeX-Stil schreiben, um mathematische Ausdrücke mithilfe von $-Trennzeichen inline oder mit $$-Trennzeichen in Blöcken zu rendern. Weitere Informationen findest du unter Schreiben mathematischer Ausdrücke.

Um die Stabilität zu verbessern, wurde der Dienst zum Rendern von GeoJSON, Jupyter Notebook, PDF, PSD, SVG, SolidWorks und anderen Binärformaten ersetzt.

Wenn TLS- und Unterdomänenisolation für deine Instanz konfiguriert wurden und dein Zertifikat kein Platzhalterzertifikat ist, musst du ein neues Zertifikat generieren, das die zusätzlichen Unterdomänen für diese Dienste enthält: notebooks.HOSTNAME und viewscreen.HOSTNAME. Weitere Informationen findest du unter Aktivieren der Subdomain-Isolation. [Aktualisiert: 02.12.2022]

Die Geheimnisüberprüfung unterstützt keine benutzerdefinierten Muster mehr, die .* als Endtrennzeichen im Feld „Nach dem Geheimnis“ verwenden, da die Mustersyntax Probleme und Inkonsistenzen bei der Überprüfung verursachen würde.

Beim Erstellen eines neuen Release können Benutzer*innen das Formular jetzt per CTRL + EINGABETASTE unter macOS bzw. STRG + EINGABETASTE unter Windows oder Linux übermitteln.

Die Registerkarte Wiki in einem Repository wird nur angezeigt, wenn ein Wiki vorhanden ist. Zuvor wurde die Registerkarte immer angezeigt.

Gerenderte Wikis zeigen mathematische Ausdrücke und Mermaid-Diagramme an.

Das Suchfeld für Benutzer-, Organisations- und Unternehmensüberwachungsprotokolle wurde vergrößert.

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.

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

Wenn du in den Einstellungen eines Repositorys die Option aktivierst, die Benutzern mit Lesezugriff das Erstellen von Diskussionen gestattet, wird diese Funktionalität nicht aktiviert.

In einigen Fällen können Benutzer vorhandene Issues nicht in Diskussionen umwandeln.

Während der Überprüfungsphase einer Konfigurationsausführung kann ein Fehler No such object für die Dienste Notebook und Viewscreen auftreten. Dieser Fehler kann ignoriert werden, da die Dienste dennoch ordnungsgemäß gestartet werden sollten.

In einigen Fällen können nach dem Upgrade auf GitHub Enterprise Server 3.7.0 beim Initiieren von git-Vorgängen über SSH oder HTTPS die Fehler Internal Server Error oder 500 auftreten. Beispiel:

git push origin master
Total 0 (delta 0), reused 0 (delta 0)
remote: Internal Server Error
To ghes.hostname.com:User/repo.git
! [remote rejected]       master -> master (Internal Server Error)

Wende dich in diesem Fall mit einem Supportpaket an den GitHub Enterprise Support. Die derzeit bekannte temporäre Problemumgehung besteht darin, den github-gitauth-Dienst mit den folgenden Befehlen neu zu starten:

nomad stop github-gitauth
nomad run /etc/nomad-jobs/github/gitauth.hcl
nomad status github-gitauth

Wir untersuchen zurzeit einen dauerhaften Fix für einen zukünftigen Hotpatch [Aktualisiert: 24.11.2022].

Bei Instanzen mit einer hohen anhaltenden Anzahl gleichzeitiger Git-Anforderungen können Leistungsprobleme auftreten. Wenn du vermutest, dass sich dieses Problem auf deine Instanz auswirkt, wende dich an den GitHub-Support. Weitere Informationen findest du unter Erstellen eines Supporttickets. [Aktualisiert: 2022-12-07]

Beim Überprüfen der Domäneneinstellungen für eine Instanz mit aktivierter TLS-Isolation und Unterdomänenisolation werden in der Verwaltungskonsole die beiden neuen Unterdomänen von GitHub Enterprise Server 3.7, http(s)://notebooks.HOSTNAME und http(s)://viewscreen.HOSTNAME, in der Liste der Domänen nicht angezeigt. [Aktualisiert: 12.1.2023]