Enterprise Server 3.8 release notes

Bei einer Instanz, auf der GitHub Actions aktiviert ist, würde ein Workflowauftrag für GitHub Actions nicht gestartet, wenn die entsprechende Runnergruppe nicht verfügbar war, als der Auftrag ursprünglich in die Warteschlange gestellt wurde, selbst wenn die entsprechende Runnergruppe verfügbar wurde, nachdem der Auftrag in die Warteschlange gestellt wurde.

Bei einer Instanz, auf der GitHub Actions aktiviert ist, wird GitHub Actions nach der Wiederherstellung eines gelöschten Repositorys nun ordnungsgemäß ausgeführt.

Bei einer Instanz, für die GitHub Actions aktiviert ist, werden Kontexte innerhalb von Ausdrücken (beispielsweise strategy: ${{ inputs.strategies }}) von geschachtelten Aufrufen wiederverwendbarer Workflows innerhalb eines wiederverwendbaren Workflowauftrags mit einer Matrix korrekt ausgewertet.

In einigen Fällen konnten Graphen auf dem Überwachungsdashboard der Verwaltungskonsole nicht gerendert werden.

Nachdem eine Administratorin den REST-API-Endpunkt /setup/api/start zum Hochladen einer Lizenz verwendet hat, trat bei der Konfigurationsausführung während der Migrationsphase ein Fehler vom Typ Connection refused auf.

Wenn 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 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 eine Websiteadministratorin während der Konfiguration von Hochverfügbarkeit das Hilfsprogramm ghe-repl-start unterbrochen hat, wurde vom Hilfsprogramm fälschlicherweise gemeldet, dass die Replikation konfiguriert wurde, und die erwartete Bereinigung wurde nicht durchgeführt.

Befehle, die Websiteadministrator*innen über SSH auf einem der Instanzknoten ausgeführt haben, wurden nicht in /var/log/ssh-console-audit.log angemeldet.

Bei Instanzen, die für die Verwendung der privaten Beta von SCIM für GitHub Enterprise Server konfiguriert wurden, war die Authentifizierung von Benutzern mit SSH-Schlüsseln und persönlichen Zugriffstoken aufgrund einer fehlerhaften Autorisierungsanforderung nicht erfolgreich.

Nachdem eine Benutzerin ein Repository mit aktiviertem Pushschutz importiert hat, war das Repository nicht sofort in der Ansicht „Sicherheitsabdeckung“ der Sicherheitsübersicht sichtbar.

Antworten vom REST-API-Endpunkt /repositories enthielten fälschlicherweise gelöschte Repositorys.

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

Wenn ein Repository eine CODEOWNERS-Datei mit Prüfanmerkungen enthielt, wurde auf der Registerkarte „Dateien geändert“ von Pull Requests ein Fehler vom Typ 500 zurückgegeben, und im Abschnitt „Unveränderte Dateien mit Prüfanmerkungen“ wurde eine Fehlermeldung angezeigt.

Wenn eine Benutzerin in einer Instanz, für die GitHub Actions aktiviert ist, über die REST-API manuell einen Workflow ausgelöst, aber keine Werte für optionale boolesche Werte angegeben hat, konnte die API die Anforderung nicht überprüfen, und es wurde ein Fehler vom Typ 422 zurückgegeben.

Bei der Suche nach Gists war der Text im Suchfeld in einigen Fällen nicht sichtbar, da die Textfarbe mit der Farbe des Hintergrunds der Felder identisch war.

In einigen Fällen hat GitHub Enterprise Server in einer Instanz mit mehreren Knoten fälschlicherweise das Schreiben auf Replikatdateiserver beendet, sodass Repositorydaten nicht mehr synchron waren.

Wenn auf einer Instanz mit aktiviertem GitHub Connect die Option „Benutzer können GitHub.com durchsuchen“ aktiviert war, wurden Benutzer*innen Issues in privaten und internen Repositorys in den Suchergebnissen für GitHub.com nicht angezeigt.

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

Um zeitweilige Probleme mit dem Erfolg von Git-Vorgängen in einer Instanz mit mehreren Knoten zu vermeiden, überprüft GitHub Enterprise Server den Status des MySQL-Containers, bevor versucht wird, eine SQL-Abfrage auszuführen. Die Timeoutdauer wurde ebenfalls reduziert.

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

Bei einer Instanz mit einer GitHub Advanced Security-Lizenz können Benutzer*innen, die benutzerdefinierte Muster für die Geheimnisüberprüfung erstellen, Ausdrücke mit bis zu 2.000 Zeichen angeben, die übereinstimmen müssen oder nicht übereinstimmen dürfen. Diese Grenze ist eine Erhöhung von 1.000 Zeichen.

Projects, das flexible Tool zum Planen und Nachverfolgen von Projekten auf GitHub Enterprise Server, ist jetzt als Betaversion verfügbar. Ein Projekt ist ein anpassbares Spreadsheet, das mit Issues und Pull Requests integriert wird, um Benutzerinnen eine effektive Planung und Nachverfolgung ihrer Arbeit zu ermöglichen. Benutzerinnen können mehrere Ansichten erstellen und anpassen, und jede Ansicht kann Issues und Pull Requests filtern, sortieren und gruppieren. Benutzer*innen können auch benutzerdefinierte Felder definieren, um die individuellen Metadaten für ein Team oder Projekt nachzuverfolgen. Das Tool ist also für alle Anforderungen oder Prozesse geeignet. Änderungen an diesem Feature sind vorbehalten. Weitere Informationen findest du unter Informationen zu Projects (beta).

Websiteadministratorinnen können die Sicherheit einer Instanz verbessern, indem sie dedizierte Benutzerkonten für die Verwaltungskonsole erstellen. Benutzerkonten können nur von Websiteadministratorinnen mit Root-Berechtigung erstellt werden. Um den Zugriff für die Benutzerkonten zu steuern, weisen entweder die Rolle Editor oder Operator zu. Operator*innen können den administrativen SSH-Zugriff für die Instanz verwalten. Weitere Informationen findest du unter Verwalten des Zugriffs auf die Verwaltungskonsole.

Um interne Richtlinien zu etablieren oder einzuhalten, können Websiteadministratorinnen die Verwaltungskonsole verwenden. Mit dieser können sie die Richtlinie einer Instanz für die Aufbewahrung von Daten im Zusammenhang mit Überprüfungen konfigurieren, einschließlich der von GitHub Actions und der Statuses-API generierten Überprüfungsdaten. Administratorinnen können die Aufbewahrung aktivieren oder deaktivieren, einen benutzerdefinierten Aufbewahrungsschwellenwert festlegen oder einen benutzerdefinierten Schwellenwert für das endgültige Löschen festlegen. Weitere Informationen findest du unter Konfigurieren von Anwendungen [Aktualisiert: 02.03.2023]

Beim Generieren von Supportpaketen mithilfe des Befehlszeilenprogramms ghe-support-bundle können Websiteadministrator*innen die genaue Dauer angeben, die für die gesammelten Daten im Bundle verwendet werden soll. Weitere Informationen findest du unter Befehlszeilenprogramme.

Benutzer*innen können sowohl Browsersitzungen als auch GitHub Mobile-Sitzungen für eine GitHub Enterprise Server-Instanz überprüfen und widerrufen. Weitere Informationen findest du unter Anzeigen und Verwalten deiner Sitzungen.

Unternehmensinhaberinnen können konfigurieren, ob Repositoryadministratorinnen Dependabot-Warnungen aktivieren oder deaktivieren können. Auf Instanzen mit einer GitHub Advanced Security-Lizenz können Unternehmensinhaberinnen auch Richtlinien festlegen, um zu steuern, ob Repositoryadministratorinnen GitHub Advanced Security-Features oder die Geheimnisüberprüfung aktivieren können. Weitere Informationen findest du unter Erzwingen von Richtlinien für die Codesicherheit und -analyse für dein Unternehmen.

Unternehmens- und Organisationsinhaber*innen können zur Einhaltung des Prinzips der geringsten Rechte beitragen, indem sie Zugriff auf Überwachungsprotokollendpunkte gewähren, ohne vollumfängliche Administratorrechte zu erteilen. Um diesen Zugriff zu erteilen, unterstützen persönliche Zugriffstoken und OAuth-Apps jetzt den Bereich read:audit_log. Weitere Informationen findest du unter „Verwenden der Überwachungsprotokoll-API für dein Unternehmen“.

Unternehmensinhaber*innen können Aktivitäten, die Authentifizierungstoken zugeordnet sind, leichter erkennen und nachverfolgen, indem sie Tokendaten in Überwachungsprotokollereignissen anzeigen. Weitere Informationen findest du unter Identifizieren von Überwachungsprotokollereignissen, die von einem Zugriffstoken ausgeführt werden.

Unternehmensinhaber*innen können das Streaming von Überwachungsprotokollen für einen Datadog-Endpunkt konfigurieren. Weitere Informationen findest du unter „Streamen des Überwachungsprotokolls für dein Unternehmen“.

Unternehmensinhaberinnen können sich für eine Instanz mit einer GitHub Advanced Security-Lizenz die Änderungen an GitHub Advanced Security, der Geheimnisüberprüfung und der Pushschutzaktivierung im Überwachungsprotokoll ansehen. Unternehmensinhaberinnen können sich Änderungen an benutzerdefinierten Nachrichten zum Pushschutz im Überwachungsprotokoll ansehen. Weitere Informationen findest du in der folgenden Dokumentation.

• Aktionen der business_secret_scanning-Kategorie, Aktionen der business_secret_scanning_push_protection-Kategorie und Aktionen der business_secret_scanning_push_protection_custom_message-Kategorie unter „Überwachungsprotokollereignisse für dein Unternehmen“
• Überprüfen des Auditprotokolls deiner Organisation

Unternehmensinhaber*innen können bei einer Instanz mit einer GitHub Advanced Security-Lizenz die REST-API nutzen, um die Compliance sicherzustellen und den Rollout von Geheimnisüberprüfungen und Pushschutz für alle Organisationen in der Instanz zu vereinfachen. Dieser Endpunkt ergänzt die vorhandene Webbenutzeroberfläche sowie die Endpunkte für Repositorys und Organisationen. Weitere Informationen findest du in der REST-API-Dokumentation unter Codesicherheit und -analyse.

Unternehmens- und Organisationsinhaber*innen, die die Geheimnisüberprüfung für eine Instanz mit einer GitHub Advanced Security-Lizenz einsetzen, können die REST-API verwenden, um einen benutzerdefinierten Link anzugeben, der angezeigt werden soll, wenn der Pushschutz einen Push blockiert, der ein Geheimnis enthält. Weitere Informationen findest du in der REST-API-Dokumentation unter Codesicherheit und -analyse oder Organisationen.

Benutzerinnen auf einer Instanz mit einer GitHub Advanced Security-Lizenz, die eine Warnung für die Geheimnisüberprüfung schließen, können anderen Benutzerinnen dabei helfen, den Grund für das Schließen zu verstehen, indem sie einen optionalen Kommentar über die Webbenutzeroberfläche oder die REST-API hinterlassen. Weitere Informationen findest du in der folgenden Dokumentation.

• Verwalten von Warnungen aus der Geheimnisüberprüfung
• Geheimnisüberprüfung in der REST-API-Dokumentation

Benutzer*innen auf einer Instanz mit einer GitHub Advanced Security-Lizenz können die Ergebnisse der Codeüberprüfungs-API nach dem Schweregrad der Warnung auf Repository- oder Organisationsebene filtern. Verwende den Parameter severity, damit nur Warnungen zur Codeüberprüfung mit einem bestimmten Schweregrad zurückgegeben werden. Weitere Informationen findest du in der REST-API-Dokumentation unter Codeüberprüfung.

Benutzer*innen auf einer Instanz mit einer GitHub Advanced Security-Lizenz können mithilfe der CodeQL-Codeüberprüfung zwei weitere Sprachen auf Sicherheitsrisiken und Fehler analysieren. Die Unterstützung für Ruby ist allgemein verfügbar. Die Unterstützung für Kotlin befindet sich in der Betaphase, und Änderungen sind vorbehalten.

• Die Ruby-Analyse kann mehr als doppelt so viele häufige Schwachstellen (Common Weaknesses, CWEs) wie während der Betaphase erkennen. Insgesamt 30 Regeln können eine Reihe von Sicherheitsrisiken identifizieren, darunter Cross-Site Scripting (XSS), Denial-of-Service durch reguläre Ausdrücke (ReDoS), SQL-Einschleusung und viele mehr. Die zusätzliche Bibliotheken- und Frameworkabdeckung für Ruby-on-Rails sorgt dafür, dass Webdienstentwickler*innen noch präzisere Ergebnisse erhalten. GitHub Enterprise Server unterstützt alle gängigen Ruby-Versionen bis einschließlich 3.1.
• Die Kotlin-Unterstützung ist eine Erweiterung der vorhandenen Java-Unterstützung und profitiert von den vorhandenen CodeQL-Abfragen für Java, die sowohl für mobile als auch für serverseitige Anwendungen gelten. GitHub hat auch eine Reihe mobilspezifischer Abfragen verbessert und hinzugefügt, die Schwierigkeiten wie den Umgang mit Absichten, Probleme mit der Validierung von Webansichten, die Fragmentinjektion und vieles mehr abdecken.

Weitere Informationen zur Codeüberprüfung findest du unter Informationen zur Codeüberprüfung mit CodeQL.

Benutzer*innen auf einer Instanz mit einer GitHub Advanced Security-Lizenz, die die CodeQL-Codeüberprüfung verwendet, können die Buildkonfiguration für die Go-Analyse in der GitHub Actions-Workflowdatei anpassen. An vorhandenen CodeQL-Workflows für die Go-Analyse sind keine Änderungen erforderlich, und diese werden weiterhin unterstützt. Weitere Informationen findest du unter Konfigurieren des CodeQL-Workflows für kompilierte Sprachen.

Um die Codesicherheit zu verbessern und das Aktualisieren anfälliger Abhängigkeiten zu vereinfachen, können mehr Benutzer*innen automatische Pull Requests mit Abhängigkeitsupdates empfangen.

• GitHub Actions-Ersteller*innen können Abhängigkeiten in Workflowdateien automatisch aktualisieren.
• Dart- oder Flutter-Entwickler*innen, die Pub verwenden, können Abhängigkeiten in ihren Projekten automatisch aktualisieren.

Weitere Informationen findest du unter Informationen zu Dependabot-Sicherheitsupdates.

Dart- und JavaScript-Entwickler*innen auf einer Instanz mit aktiviertem Abhängigkeitsdiagramm können Dependabot-Warnungen für bekannte Sicherheitsrisiken innerhalb der Abhängigkeiten eines Projekts erhalten.

• Für Dart erkennt das Abhängigkeitsdiagramm pubspec.lock- und pubspec.yaml-Dateien.
• JavaScript-Entwickler*innen, die Node.js und npm verwenden, können Warnungen zu bekannten Sicherheitsrisiken in Yarn 2- und Yarn 3-Manifesten erhalten. Die vorhandene Unterstützung für Manifeste aus Version 1 wird dadurch ergänzt. Das Abhängigkeitsdiagramm erkennt package.json- und yarn.lock-Dateien.

Weitere Informationen findest du in den folgenden Artikeln.

• Informationen zum Abhängigkeitsdiagramm
• Durchsuchen von Sicherheitsempfehlungen in GitHub Advisory Database
• Informationen zu Dependabot-Warnungen

Python-Entwickler*innen, die unterstützte Paket-Manager für eine Instanz mit aktiviertem Abhängigkeitsdiagramm verwenden, können Dependabot-Warnungen für Abhängigkeiten in pyproject.toml-Dateien empfangen, die dem PEP 621-Standard entsprechen. Weitere Informationen findest du unter Informationen zu Dependabot-Versionsupdates.

Python-Entwickler*innen, die Dependabot-Warnungen erhalten, können die Anzahl der Versionsupdates reduzieren, wenn eine aktuelle Abhängigkeitsanforderung bereits durch eine neue Version erfüllt wird. Verwende zum Konfigurieren dieses Verhaltens die Versionsverwaltungsstrategie increase-if-necessary. Weitere Informationen findest du unter Konfigurationsoptionen für die Datei „dependabot.yml“.

Unternehmensinhaber*innen können Dependabot-Warnungen für die Instanz mithilfe der REST-API abrufen. Dieser Endpunkt befindet sich in der Betaphase. Änderungen sind vorbehalten. Weitere Informationen findest du in der REST-API-Dokumentation unter Dependabot-Warnungen.

Organisationsinhaber*innen können Dependabot-Warnungen für die Organisation mithilfe der REST-API abrufen. Dieser Endpunkt befindet sich in der Betaphase. Änderungen sind vorbehalten. Weitere Informationen findest du unter Dependabot-Warnungen.

Benutzer*innen können Dependabot-Warnungen mithilfe der REST-API programmgesteuert anzeigen und auf diese reagieren. Neue Endpunkte zum Anzeigen, Auflisten und Aktualisieren von Dependabot-Warnungen sind in der Betaversion verfügbar. Änderungen an diesen Endpunkten sind vorbehalten. Weitere Informationen findest du in der REST-API-Dokumentation unter Dependabot-Warnungen.

Um den Sicherheitsstatus transparenter zu gestalten und die Risikoanalyse zu optimieren, können Benutzerinnen in der Sicherheitsübersicht auf Abdeckungs- und Risikoansichten zugreifen. Die Abdeckungsansicht zeigt die Aktivierung für alle Repositorys an, während in der Risikoansicht Warnungen in allen Repositorys angezeigt werden. Organisationsinhaberinnen, Sicherheitsmanagerinnen und Repositoryadministratorinnen für eine Instanz mit einer GitHub Advanced Security-Lizenz können Sicherheitsfeatures in der Abdeckungsansicht der Sicherheitsübersicht aktivieren. Die Ansichten ersetzen die Seite „Übersicht“ und befinden sich in der öffentlichen Betaphase. Änderungen sind vorbehalten. Weitere Informationen findest du unter Informationen zur Sicherheitsübersicht.

Mitwirkende können die Sicherheitsrichtlinie eines Repositorys definieren, indem sie eine SECURITY.md-Datei erstellen. Um die Sichtbarkeit der Richtlinie zu erhöhen, verknüpft GitHub Enterprise Server die Richtlinie über die Registerkarte Code. Weitere Informationen findest du unter Hinzufügen einer Sicherheitsrichtlinie zu deinem Repository.

Die Abhängigkeitsüberprüfungs-API ist allgemein verfügbar, und mit der zugeordneten GitHub-Aktion können Benutzer*innen jetzt auf eine lokale oder externe Konfigurationsdatei verweisen. Weitere Informationen findest du in der folgenden Dokumentation.

• Abhängigkeitsüberprüfung in der REST-API-Dokumentation
• Konfigurieren der Abhängigkeitsüberprüfung

Die GraphQL-API ermöglicht den Zugriff auf das Abhängigkeitsdiagramm eines Repositorys. Dieses Feature ist eine Vorschauversion. Änderungen sind vorbehalten. Weitere Informationen findest du in der Dokumentation zur GraphQL-API unter Objekte.

Während der Konfiguration des Speichers für GitHub Actions können Standortadministrator*innen Risiken vermeiden, die mit der Eingabe vertraulicher Geheimnisse und von Zugriffsschlüsseln verbunden sind, indem sie OIDC verwenden, um eine Verbindung mit Objektspeicheranbietern herzustellen. GitHub Actions auf GitHub Enterprise Server unterstützt OIDC für Verbindungen mit AWS, Azure und Google Cloud Platform. Dieses Feature befindet sich in der Betaversion und kann noch geändert werden. Weitere Informationen findest du unter Aktivieren von GitHub Actions für GitHub Enterprise Server.

Um nicht die vertrauenswürdige Protokollierung von Daten aus den Workflowbefehlen set-state und set-output zu verhindern, können Aktionsersteller*innen Umgebungsdateien für die Verwaltung von Status und Ausgabe verwenden.

• Um dieses Feature verwenden zu können, muss die Runneranwendung Version 2.297.0 oder höher aufweisen. Ab Version 2.298.2 wird Benutzer*innen eine Warnung angezeigt, wenn sie die Befehle save-state oder set-output verwenden. Diese Befehle werden in einem zukünftigen Release vollständig deaktiviert.
• Um die aktualisierten Funktionen saveState und setOutput zu verwenden, müssen Workflows, die das GitHub Actions-Toolkit verwenden, @actions/core 1.10.0 oder höher aufrufen.

Weitere Informationen findest du unter Workflowbefehle für GitHub Actions.

Die Funktion, Aktionen und wiederverwendbare Workflows aus privaten Repositorys freizugeben, ist allgemein verfügbar. Benutzer*innen können Workflows in einem privaten Repository für andere private Repositorys freigeben, die sich im Besitz derselben Organisation oder desselben Benutzerkontos befinden, oder für alle privaten Repositorys in der Instanz. Weitere Informationen findest du in der folgenden Dokumentation.

• Verwalten von GitHub Actions-Einstellungen für ein Repository
• GitHub Actions-Berechtigungen in der REST-API-Dokumentation

Benutzer*innen können die Lesbarkeit des Workflows verbessern und vermeiden, dass nicht vertrauliche Konfigurationsdaten als verschlüsselte Geheimnisse gespeichert werden müssen, indem sie Konfigurationsvariablen definieren, die die workflowübergreifende Wiederverwendung in einem Repository oder einer Organisation ermöglichen. Dieses Feature befindet sich in der Betaversion und kann noch geändert werden. Weitere Informationen findest du unter Variablen.

Benutzer*innen können Workflowausführungen dynamisch benennen. run-name akzeptiert Ausdrücke, und der dynamische Name wird in der Liste der Workflowausführungen angezeigt. Weitere Informationen findest du unter Workflowsyntax für GitHub Actions.

Benutzer*innen können verhindern, dass ein Auftrag auf einem Runner außerhalb der beabsichtigten Gruppe ausgeführt wird, indem sie die Namen der beabsichtigten Runnergruppen für einen Workflow innerhalb des runs-on-Schlüssels definieren.

runs-on:
  group: my-group
  labels: [ self-hosted, label-1 ]

Darüber hinaus lässt GitHub Enterprise Server die Erstellung von Runnergruppen mit identischen Namen auf Organisations- und Unternehmensebene nicht mehr zu. Ein Warnbanner wird für alle Runnergruppen innerhalb einer Organisation angezeigt, deren Namen identisch mit einer Runnergruppe für das Unternehmen ist.

Benutzer*innen können CI/CD-Standardverfahren in allen Repositorys einer Organisation erzwingen, indem sie die erforderlichen Workflows definieren. Diese Workflows werden als erforderliche Statusüberprüfungen für alle Pull Requests ausgelöst, deren Ziel der Standardbranch des Repositorys ist, wodurch das Mergen blockiert wird, bis die Überprüfung erfolgreich ist. Dieses Feature befindet sich in der Betaversion und kann noch geändert werden. Weitere Informationen findest du unter Erforderliche Workflows.

Um die Standardisierung von OIDC-Konfigurationen für alle Cloudbereitstellungsworkflows zu ermöglichen, können Organisationsinhaberinnen und Repositoryadministratorinnen das subject-Anspruchsformat in OIDC-Token konfigurieren, indem sie eine benutzerdefinierte Vorlage definieren. Weitere Informationen findest du unter About security hardening with OpenID Connect („Informationen zur Sicherheitshärtung mit OpenID Connect“).

Um mehr Transparenz und Kontrolle über die Cachenutzung in Repositorys zu ermöglichen, können Benutzer*innen, die Abhängigkeiten und andere wiederverwendete Dateien mit actions/cache zwischenspeichern, Caches über die Webbenutzeroberfläche der Instanz verwalten. Weitere Informationen findest du unter Zwischenspeichern von Abhängigkeiten zum Beschleunigen von Workflows.

Benutzer*innen können ihre erwartete Verfügbarkeit festlegen, indem sie eine lokale Zeitzone in ihren Profilen anzeigen. Personen, die das Profil oder die Hovercard des Benutzers oder der Benutzerin anzeigen, sehen die Zeitzone sowie den zeitlichen Versatz zur Ortszeit dieses Benutzers oder dieser Benutzerin. Weitere Informationen findest du unter Personalisieren deines Profils.

Um die Auffindbarkeit zu verbessern, wurden an GitHub Discussions die folgenden Verbesserungen vorgenommen.

• Repositorybesitzer*innen können Diskussionen an eine bestimmte Kategorie anheften.
• Kategorietitel und -beschreibungen werden auf der Seite der Kategorie angezeigt.

Um zu verwalten, wie Organisationsmitglieder Repositorys forken, können Organisationsinhaber*innen eine dedizierte Forkingrichtlinie für jede Organisation festlegen. Diese Richtlinie muss strikter als der Forkingrichtliniensatz für das Unternehmen sein. Weitere Informationen findest du unter "Verwalten der Forking-Richtlinie für deine Organisation".

Organisationsinhaberinnen können die Sicherheit der Organisation verbessern, indem sie verhindern, dass externe Mitarbeiterinnen die Installation von GitHub- und OAuth-Apps anfordern. Weitere Informationen findest du unter Einschränken von OAuth-App- und GitHub-App-Zugriffsanforderungen.

Um den vollständigen Administratorzugriff auf ein Repository zu vermeiden, wenn dieser nicht erforderlich ist, können Repositoryadministratorinnen eine benutzerdefinierte Rolle erstellen, mit der Benutzerinnen den Branchschutz umgehen können. Um Branchschutz für alle Benutzerinnen mit Administratorzugriff oder Umgehungsberechtigungen zu erzwingen, können Administratorinnen die Option Umgehung der oben genannten Einstellungen nicht zulassen aktivieren. Weitere Informationen findest du unter Verwalten benutzerdefinierter Repositoryrollen für eine Organisation und Informationen zu geschützten Branches.

Repositoryadministrator*innen können die Sicherheit und Stabilität von Branches gewährleisten, indem sie die Pull-Request-Genehmigung durch eine andere Person als den letzten Pushenden vorschreiben oder den Branch sperren. Weitere Informationen findest du unter Informationen zu geschützten Branches.

In Szenarios, in denen Code innerhalb eines GitHub Actions-Workflows geprüft werden sollte, bevor der Workflow ausgeführt wird, können Repositoryadministratorinnen die Genehmigung durch einen Benutzer*in mit Schreibzugriff auf das Repository vorschreiben, bevor eine Workflowausführung über einen privaten Fork ausgelöst werden kann. Weitere Informationen findest du unter Verwalten von GitHub Actions-Einstellungen für ein Repository.

Die GraphQL-API unterstützt das Erstellen und Entfernen der Verknüpfung zwischen einem Branch und einem Issue. Weitere Informationen findest du in der folgenden Dokumentation.

• Erstellen eines Branches zum Arbeiten an einem Issue
• Abschnitte zu createLinkedBranch und deleteLinkedBranch unter „Mutationen“ in der Dokumentation zur GraphQL-API
• Objekte in der Dokumentation zur GraphQL-API

Benutzerinnen, deren Konten mehrere E-Mail-Adressen zugeordnet sind, können leichter dafür sorgen, dass Git-Commits, die durch Squashmerging erstellt wurden, der richtigen E-Mail-Adresse zugeordnet werden. Beim Mergen des Pull Request wird ein Dropdownmenü angezeigt, in dem der oder die Benutzerin die E-Mail-Adresse auswählen kann, die als Ersteller des Commits verwendet werden soll.

Benutzer*innen können ein bestimmtes Release in einem Repository mithilfe der Webbenutzeroberfläche, der REST-API oder der GraphQL-API als neueste Version kennzeichnen. Weitere Informationen findest du in der folgenden Dokumentation.

• Verwalten von Releases in einem Repository
• Releases in der REST-API-Dokumentation
• Objekte in der Dokumentation zur GraphQL-API

Benutzer*innen können Zeit sparen und müssen den Kontext seltener wechseln, wenn sie Echtzeitupdates zu GitHub Enterprise Server-Aktivitäten direkt in Slack oder Microsoft Teams erhalten und dort auf diese reagieren können. Die GitHub-Integrationen für diese Dienste sind jetzt allgemein verfügbar. Weitere Informationen findest du unter GitHub-Erweiterungen und -Integrationen.

Wenn eine Websiteadministratorin einen Befehl mit administrativem SSH-Zugriff ausführt, wird der Befehl jetzt protokolliert. Um die Problembehandlung und das Debuggen für den GitHub-Support zu erleichtern, enthalten Supportpakete ein Protokoll, in dem diese Befehle aufgeführt sind.

Um die Ermittlung von Ereignissen innerhalb von Unternehmens-, Organisations- oder Benutzerüberwachungsprotokollen zu vereinfachen, zeigt die Suchleiste jetzt eine Liste der verfügbaren Filter an.

Bevor eine Websiteadministratorin mithilfe der Import-CLI für GitHub Enterprise, der GraphQL-API startRepositoryMigration oder der REST-API für das Initiieren einer Organisationsmigration von GitHub Enterprise Server migrieren kann, muss eine Administratorin einen Blobspeicheranbieter für die Speicherung der Migrationsarchive über die Verwaltungskonsole konfigurieren. Zu den unterstützten Anbietern zählen Amazon A3 und Azure Blob Storage. Zuvor war Blobspeicher nicht erforderlich und konnte optional mithilfe von gh gei konfiguriert werden. Durch diese Änderung werden auch Migrationen unterstützt, bei denen die Git-Quelle oder die Git-Metadaten größer als 1 GB sind.

Damit Benutzer*innen auf einer Instanz mit einer GitHub Advanced Security-Lizenz erkannte Geheimnisse besser verstehen und geeignetere Maßnahmen ergreifen können, enthalten Geheimnisüberprüfungswarnungen für API-Schlüssel von Drittanbietern jetzt einen Link zur Dokumentation des Anbieters. Weitere Informationen findest du unter Informationen zur Geheimnisüberprüfung.

Benutzerinnen auf einer Instanz mit einer GitHub Advanced Security-Lizenz werden nun die Aktionen, die zu einer Geheimnisüberprüfungswarnung geführt haben, direkt in der Zeitachse der Warnung angezeigt. Dort wird auch aufgeführt, wenn eine Mitwirkende*r den Pushschutz für ein Geheimnis umgangen hat.

Instanzen mit einer GitHub Advanced Security-Lizenz führen regelmäßig einen Verlaufsscan aus, um neu hinzugefügte Geheimnistypen in Repositorys zu erkennen, bei denen GitHub Advanced Security und die Geheimnisüberprüfung aktiviert sind. Zuvor mussten Benutzer*innen den Verlaufsscan manuell ausführen.

Um bei Instanzen mit einer GitHub Advanced Security-Lizenz sicherzustellen, dass zukünftige Releases von GitHub Enterprise Server immer eine Vorschau des erkannten Geheimnisses in den APIs oder auf der Webbenutzeroberfläche anzeigen können, werden die Geheimnisse jetzt getrennt vom Quellcode gespeichert. Erkannte Geheimnisse werden mithilfe der symmetrischen Verschlüsselung gespeichert. [Aktualisiert: 15.02.2023]

Wenn private Registrierungen für Dependabot-Updates verwendet werden, wendet GitHub Enterprise Server höhere Sicherheitsstandards an. Wenn eine private Registrierung für eines der folgenden Ökosysteme konfiguriert ist, stellt die Instanz keine Paketanforderungen mehr an öffentliche Registrierungen.

• Bundler
• Docker
• Gradle
• Maven
• npm
• Nuget
• Python
• Yarn

Weitere Informationen findest du unter Konfigurationsoptionen für die Datei „dependabot.yml“.

Elixir-Entwickler*innen, die selbstgehostete Hex-Repositorys verwenden, können eine private Registrierung für Dependabot-Versionsupdates auf GitHub Enterprise Server konfigurieren. Weitere Informationen findest du unter Konfigurationsoptionen für die Datei „dependabot.yml“.

An Dependabot-Warnungen wurden die folgenden Verbesserungen für mehr Benutzerfreundlichkeit vorgenommen.

• Die Seite für eine Warnung wird automatisch aktualisiert, nachdem Dependabot versucht hat, einen Pull Request für ein Update zu erstellen.
• Warnungen werden den Pull Requests von Dependabot-Updates besser zugeordnet.
• Um das Warnungsfeature für die Community zu verbessern, können Benutzer*innen Verbesserungen an Warnungen direkt in GitHub Advisory Database vorschlagen.

Benutzer können @dependabot leichter erwähnen. Das Dependabot-Benutzerkonto wird jetzt beim Erwähnen als Vorschlag zur automatischen Vervollständigung angezeigt.

In Repositorys mit anfälligen Abhängigkeiten zeigt Dependabot kein gelbes Banner mehr an. Um Mitwirkende über anfällige Abhängigkeiten zu benachrichtigen, wird auf der Registerkarte Sicherheit ein Warnungsindikator angezeigt.

Wenn eine Benutzerin ein Repository mit einer vorhandenen Dependabot-Konfiguration in dependabot.yml forkt, werden Dependabot-Updates standardmäßig im Fork deaktiviert. Um Updates im Fork zu aktivieren, muss der oder die Benutzer*in die Codesicherheits- und Analyseeinstellungen des Repositorys aufrufen. Weitere Informationen findest du unter Konfigurieren von Dependabot-Versionsupdates.

Integrator*innen, die einen Webhook für Dependabot-Warnungen erhalten möchten, müssen den neuen Webhook dependabot_alert verwenden. Dieser Webhook ersetzt den Webhook repository_vulnerability_alert. Weitere Informationen findest du unter Webhookereignisse und Nutzdaten.

Um die Lesbarkeit von GitHub Actions-Workflows zu verbessern, die auf andere Aktionen verweisen, schreiben Aktionsersteller*innen häufig einen Kommentar mit der entsprechenden semantischen Version in der Zeile, die die Aktion aufruft. Um Zeit zu sparen, aktualisieren Pull Requests für Dependabot-Versionsupdates jetzt automatisch die semantische Version in diesen Kommentaren.

JavaScript-Entwickler*innen, die Sicherheitsupdates für Node.js, npm und Dependabot verwenden, können beim Aktualisieren von npm-Projekten mit transitiven Abhängigkeiten Zeit sparen.

• Dependabot kann übergeordnete und untergeordnete Abhängigkeiten gleichzeitig aktualisieren. Bisher hat Dependabot transitive Abhängigkeiten nicht aktualisiert, wenn das übergeordnete Element einen bestimmten nicht kompatiblen Versionsbereich erforderte, wodurch manuelle Upgrades anfielen.
• Dependabot kann Pull Requests erstellen, die Warnungen beheben, bei denen ein Update auf eine direkte Abhängigkeit die anfällige transitive Abhängigkeit aus der Struktur entfernt.

Weitere Informationen findest du unter Informationen zu Dependabot-Sicherheitsupdates.

Für Benutzer*innen, die Dependabot für Versionsupdates im Docker-Ökosystem verwenden, aktualisiert Dependabot proaktiv Docker-Imagetags in Kubernetes-Manifesten. Weitere Informationen findest du unter Konfigurieren von Dependabot-Versionsupdates und unter Konfigurationsoptionen für die Datei „dependabot.yml“.

Eine Reihe von Verbesserungen wurden für Benutzer*innen vorgenommen, die zu Sicherheitsempfehlungen auf GitHub.com beitragen, einschließlich der folgenden:

• Um den Review zu beschleunigen, fordert GitHub die Benutzer*innen dazu auf, einen Änderungsgrund hinzuzufügen.
• Um sicherzustellen, dass der Beitrag der Absicht des Benutzers oder der Benutzerin entspricht, sortiert GitHub Verweislinks im Diff nicht um.

An GitHub Actions wurden die folgenden Verbesserungen zur Auffindbarkeit und Barrierefreiheit vorgenommen:

• Die Navigationsoberfläche für die Suche nach Workflows und Workflowausführungen wurde verbessert.
• Die hinzugefügte Struktur stellt die Hierarchie zwischen aufrufenden und aufgerufenen wiederverwendbaren Workflows besser dar.
• Die mobile Browserumgebung ist konsistenter und unterstützt mehrere Viewportgrößen.

GitHub Actions Workflows werden nicht mehr endlos ausgelöst, wenn GITHUB_TOKEN mit workflow_dispatch- und repository_dispatch-Ereignissen verwendet wird. Vor dieser Änderung haben Ereignisse, die von GITHUB_TOKEN ausgelöst wurden, keine neue Workflowausführung initiiert. Weitere Informationen findest du unter Auslösen eines Workflows.

Bei geplanten Ausführungen von GitHub Actions-Workflows werden Benutzer*innen zusätzliche Informationen zum Repository, zur Organisation und zum Unternehmen in den Nutzdaten für github.event angezeigt.

Benutzer*innen von GitHub Actions haben einen besseren Einblick in den Fortschritt eines Auftrags, wenn sie Umgebungsschutzregeln verwenden. Der Webhook workflow_job unterstützt den neuen Status waiting, wenn ein Auftrag auf eine Umgebungsschutzregel wartet. Wenn ein Auftrag auf einen environment-Schlüssel in seiner YAML-Definition verweist, enthalten die Nutzdaten des Webhooks workflow_job außerdem die neue Eigenschaft deployment. deployment enthält Metadaten zu der Bereitstellung, die von der Überprüfungsausführung erstellt wurde. Weitere Informationen findest du unter Verwenden von Umgebungen für die Bereitstellung.

Der Kontext in Überwachungsprotokollereignissen ist nun für Organisationsinhaber*innen aussagekräftiger.

• business.sso_response- und org.sso_response-Ereignisse werden in der REST-API und den Nutzdaten für das Streaming von Überwachungsprotokollen angezeigt.
• repo.rename-, project.rename- und protected_branch.update_name -Ereignisse enthalten die aktuellen Namen und früheren Namen der umbenannten Ereignisse im Feld old_name.
• Ereignisse für Dependabot-Warnungen enthalten die Felder alert_number, ghsa_id, dismiss_reason und dismiss_comment und zusätzlich einen Link zurück zur Warnung und einen genauen Zeitstempel.

Benutzerinnen können über das Profil einer Organisation eine Liste anzeigen, die alle Followerinnen dieser Organisation enthält.

Das Banner, das über einem archivierten Repository auf der Webbenutzeroberfläche angezeigt wird, enthält jetzt das Archivierungsdatum des Repositorys.

Die Registerkarten Unterhaltungen und Dateien in Pull Requests werden aufgrund der zurückgestellten Syntaxmarkierung jetzt schneller geladen.

Um mehr Konsistenz zwischen der Webbenutzeroberfläche und den Arbeitsstationen der Benutzerinnen zu bieten und die Überprüfung zu beschleunigen, ob Benutzerinnen einen Pull Request automatisch mergen können, verwendet GitHub Enterprise Server jetzt die merge-ort-Strategie. Weitere Informationen findest du unter Mergestrategien in der Git-Dokumentation.

Um die Darstellung des ersten Kommentars in Pull Requests zu verbessern, die genau einen Commit enthalten, aktualisiert GitHub Enterprise Server jetzt automatisch detaillierte Commitnachrichten, um die Markdownkonventionen von GitHub einzuhalten.

Beim Squashmerging eines Pull Requests wird der oder die Erstellerin des Git-Commits vor dem Mergen angezeigt. Zuvor wurde der oder die Commiterstellerin nur beim Mergen mit einem Mergecommit angezeigt.

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.

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.

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.

Während der Überprüfungsphase einer Konfigurationsausführung kann der 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 kann es passieren, dass der Prozess zum Umwandeln eines Issues in eine Diskussion nicht abgeschlossen wird. In dieser Situation kann ein Unternehmensbesitzer die folgenden Schritte zum Beheben des Problems ausführen.

1. Merke dir die Nummer der Diskussion am Ende der URL für die blockierte Diskussion.
2. Navigiere in der Webbenutzeroberfläche zu dem Repository, in dem die Konvertierung nicht abgeschlossen werden kann.
3. Klicke in der oberen rechten Ecke der Webbenutzeroberfläche auf .
4. Klicke unter „Zusammenarbeit“ auf NUMMER Diskussionen.
5. Klicke in der Liste auf die Nummer aus Schritt 1.
6. Klicke unter „Konvertierung“ auf Konvertierungsauftrag in Warteschlange einreihen.
7. Warte einige Minuten, und überprüfe dann den Status des Issues.

Wenn die Konvertierung immer noch nicht abgeschlossen wurde, wende dich an den GitHub Enterprise-Support, um Hilfe zu erhalten.

Wenn Administratorinnen der Stammwebsite nach fehlerhaften Anmeldeversuchen für die Verwaltungskonsole gesperrt werden, wird das Konto nach der definierten Sperrzeit nicht automatisch entsperrt. Das Konto muss von Benutzerinnen mit SSH-Administratorzugriff auf die Instanz mithilfe der Verwaltungsshell entsperrt werden. Weitere Informationen findest du unter Problembehandlung beim Zugriff auf die Verwaltungskonsole. [Aktualisiert: 23.02.2023]

Während eines Upgrades auf GitHub Enterprise Server 3.8.0 in einem Cluster kann nach dem Upgrade anderer Knoten als dem primären MySQL-Knoten und vor dem Upgrade des primären MySQL-Knotens nach Ausführung von ghe-cluster-config-apply der folgende Fehler mehrmals angezeigt werden.

Error response from daemon: conflict: unable to delete IMAGE_ID (cannot be forced) - image is being used by running container CONTAINER_ID

GitHub empfiehlt, mit dem Upgrade des Clusters zu warten, bis dieses Problem behoben ist. Weitere Informationen findest du in den Versionshinweisen für ein bevorstehendes Update für GitHub Enterprise Server.

Nach dem Upgraden auf GitHub Enterprise Server 3.8.0 werden Befehle, die über SSH auf einem der Knoten der Instanz ausgeführt werden, nicht in /var/log/ssh-console-audit.log protokolliert. Stelle zur Behebung dieses Problems eine SSH-Verbindung mit dem betroffenen Knoten her, und führe den folgenden Befehl aus:

source /etc/bash.bashrc

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]

Die Verwendung der Such-API kann dazu führen, dass nachfolgende Anforderungen für andere Schnittstellen nicht erfolgreich sind. In diesem Fall erhalten Benutzer*innen der betroffenen API oder Webbenutzeroberfläche Antworten vom Typ „5xx“, und die folgende Ausnahme vom Typ NoMethodError wird protokolliert:

NoMethodError (undefined method `starts_with?' for [:ok, "refs/heads/main"]:Array):