Enterprise Server 3.6 release notes

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

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

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

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

In some cases, on an instance with a GitHub Advanced Security license and secret scanning enabled, users may have seen a discrepancy between the number of alerts displayed on a repositorys "Security" tab and in the sidebar for the "Security" tab.

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.

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.

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.

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.

After upgrading an instance with a GitHub Advanced Security license to GitHub Enterprise Server 3.6 or 3.7, creating a repository or viewing the security settings page for an organization or repository could result in a 500 error due to a GitHub Advanced Security backfill job not completing before the upgrade started.

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.

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

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

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.

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

On an instance in a cluster configuration, when a site administrator sets maintenance mode on a single cluster node using ghe-maintenance -s, the utility warns the administrator to use ghe-cluster-maintenance -s to set maintenance mode on all of the clusters nodes. For more information, see "Wartungsmodus aktivieren und planen."

When a site administrator configures an outbound web proxy server for GitHub Enterprise Server, the instance now validates top-level domains (TLDs) excluded from the proxy configuration. By default, you can exclude public TLDs that the IANA specifies. Site administrators can specify a list of unregistered TLDs to exclude using ghe-config. The . prefix is required for any public TLDs. For example, .example.com is valid, but example.com is invalid. For more information, see "Configuring an outbound web proxy server."

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

When viewing a list of open sessions for the devices logged into a user account, the GitHub Enterprise Server web UI could display an incorrect location.

In the rare case when primary shards for Elasticsearch were located on a replica node, the ghe-repl-stop command would fail with ERROR: Running migrations.

The settings page for discussions in an organization returned a 500 error after a repository owned by the organization was deleted.

HIGH: Updated Git to include fixes from 2.39.2, which address CVE-2023-22490 and CVE-2023-23946.

Packages have been updated to the latest security versions.

When using a VPC endpoint URL as an AWS S3 URL for GitHub Packages, publication and installation of packages failed.

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.

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.

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

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.

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

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

Bereinigung zusätzlicher Geheimnisse in Supportpaketen und im Konfigurationsprotokoll.

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

Die Pakete wurden auf die neuesten Sicherheitsversionen aktualisiert.

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

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

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

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

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

Die Umgebungsvariable GITHUB_REF_PROTECTED und github.ref_protected-Kontexte wurden fälschlicherweise auf false festgelegt, wenn ein Branchschutz vorhanden war.

launch.*-Metriken, die nicht von statsd analysiert werden konnten, da die resultierenden statsd-Fehler zum schnellen Anwachsen der gesammelten Protokolle führten, 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.

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

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

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

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

Websiteadministrator*innen konnten die Einstellungen für Sicherheitsprodukte für von ihnen entsperrte Repositorys nicht ändern.

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.

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.

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

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

In einigen Fällen gab ein fehlerhaftes Banner beim Durchsuchen von Repositorys auf der Weboberfläche an, dass ein Repository einen bestimmten undefinierten Pfad im aktuellen Branch nicht enthielt.

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

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.

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

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

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.

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]

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

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

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

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

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

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.

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

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

Bei Verwendung der CodeQL-Aktion enthielten die Ausführungsanmerkungen fälschlicherweise den Fehler HttpError: Upload not found.

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.

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.

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

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

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

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

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

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

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

Packages have been updated to the latest security versions.

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

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

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

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

When a user visited links to view history or suggest an improvement to the GitHub Advisory Database, the URLs were incorrect, resulting in a 404 error.

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

On instances configured for high availability, ghe-repl-status incorrectly reported that replication was behind for repositories that users had previously deleted.

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

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

In some cases, on an instance with a GitHub Advanced Security license, some tokens detected by secret scanning were reported as "unknown tokens."

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

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

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

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

Die Pakete wurden auf die neuesten Sicherheitsversionen aktualisiert.

In einigen Fällen hat Collectd übermäßig viele Fehler im Zusammenhang mit Metriken in /var/log/collectd.log protokolliert.

Beim Konfigurieren des externen Domänennamens des Replikatknotens eines Repositorycaches mit ghe-repl-node --cache-domain gab der Befehl einen Fehler zurück, der die Aktivierung der Git LFS-Zwischenspeicherung verhinderte.

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

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

Die Option zum Aktivieren der TLS-Verschlüsselung für eingehende SMTP-Verbindungen mit einer Instanz fehlte an der Verwaltungskonsole.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

After unlocking a repository for temporary access, a site administrator was unable to manage settings for security products in the repository.

Duplicate administrative SSH keys could appear in both the Management Console and the /home/admin/.ssh/authorized_keys file.

The site admin page for individual users at <code>http(s)://<em>HOSTNAME</em>/stafftools/users/<em>USERNAME</em>/admin</code> contained functionality not intended for GitHub Enterprise Server.

In some cases, running ghe-cluster-config-apply could replicate an empty configuration to existing nodes in a cluster.

In some cases, configuration runs started with ghe-config-apply did not complete, or returned a Container count mismatch error.

After updating a self-signed TLS certificate on a GitHub Enterprise Server instance, UI elements on some pages in the web interface did not appear.

In some cases, background tasks could stall due to a library that was used concurrently despite not being thread-safe.

The site admin bar at the top of the web interface contained a broken link to the SHA for the currently running version of the application.

Organization owners were unable to set the level of access required to create discussions.

Discussions users were incorrectly directed to the community guidelines for GitHub.com.

In some cases, users were incorrectly instructed to verify their email before creating a discussion.

Alerts from secret scanning for GitHub Advanced Security customers were missing in the web UI and REST API if a site administrator did not upgrade directly to GitHub Enterprise Server 3.4. The alerts are now visible.

Generation of support bundles is faster as a result of parallelized log sanitization. For more information about support bundles, see "Providing data to GitHub Support (Bereitstellen von Daten für GitHub Support)."

APIs that contain the organization or org route now accept either the organization's slug or ID. Previously, the APIs only accepted slugs, which caused Link headers for GitHub Advanced Security endpoints to be inaccessible. For more information, see "Organizations" in the REST API documentation.

The enterprise audit log now includes more user-generated events, such as project.create. The REST API also returns additional user-generated events, such as repo.create. For more information, see "Zugreifen auf das Überwachungsprotokoll für dein Unternehmen" and "Verwenden der Überwachungsprotokoll-API für dein Unternehmen."

In some cases, cache replicas could reject some Git operations on recently updated repositories. For more information about repository caching, see "Informationen zum Zwischenspeichern von Repositorys."

You can now configure the global announcement banner to be dismissable using the REST API. For more information, see "Anpassen von Benutzernachrichten für dein Unternehmen."

Das Zwischenspeichern von Repositorys ist allgemein verfügbar. Durch das Zwischenspeichern von Repositorys verbessert sich die Git-Leseleistung für verteilte Entwickler, indem die Datenlokalität und die Vorteile der Georeplikation bereitgestellt werden, ohne Pushworkflows zu beeinträchtigen. Bei dem neuen GA-Release speichert GitHub Enterprise Server sowohl Git- als auch Git-LFS-Daten zwischen. Weitere Informationen findest du unter Informationen zum Zwischenspeichern von Repositorys.

Standortadministratoren können einen Stichtag für die Zulassung von Git-Vorgängen über SSH konfigurieren, die einen RSA-Schlüssel verwenden und von der SHA-1-Hashfunktion signiert werden. Standardmäßig treten bei diesen Verbindungen für RSA-Schlüssel, die Benutzerkonten nach dem Stichtag 1. August 2022 Mitternacht UTC hinzugefügt wurden, Fehler auf. Weitere Informationen findest du unter Einstellung. [Aktualisiert: 31.01.2023]

GitHub Enterprise Server ermöglicht optional die Ankündigung eines Ed25519-Hostschlüssels. Weitere Informationen findest du unter Konfigurieren von Hostschlüsseln für deine Instanz.

Du kannst für eingehende SMTP-Verbindungen mit deiner Instanz die TLS-Verschlüsselung anfordern. Weitere Informationen findest du unter Konfigurieren einer E-Mail-Adresse für Benachrichtigungen.

• Hinweis: Dieses Feature ist in GitHub Enterprise Server 3.6.0 und 3.6.1 nicht verfügbar. Das Feature ist ab Release 3.6.2 verfügbar. [Aktualisiert: 22.09.2022]

Du kannst das Überwachungsprotokoll und Git-Ereignisse für deine Instanz an Amazon S3, Azure Blob Storage, Azure Event Hubs, Google Cloud Storage oder Splunk streamen. Das Streamen des Überwachungsprotokolls befindet sich in der öffentlichen Betaphase und kann noch geändert werden. Weitere Informationen findest du unter „Streamen des Überwachungsprotokolls für dein Unternehmen“.

Die Serverstatistik ist jetzt allgemein verfügbar. Die Serverstatistik sammelt aggregierte Nutzungsdaten aus deiner GitHub Enterprise Server-Instanz, die du verwenden kannst, um die Anforderungen deiner Organisation besser vorherzusagen, die Arbeitsweise deines Teams zu verstehen und den Mehrwert aufzuzeigen, den GitHub Enterprise Server bietet. Weitere Informationen findest du unter Informationen zu Serverstatistiken.

Unternehmensbesitzerinnen können Organisationen in der Instanz über die Seite Organisationen des Unternehmenskontos als Mitglieder oder Besitzerinnen beitreten. Weitere Informationen findest du unter Verwalten deiner Rolle in einer Organisation im Besitz deines Unternehmens.

Unternehmensbesitzer können Benutzern gestatten, das konfigurierte Banner für globale Ankündigungen zu schließen. Weitere Informationen findest du unter Anpassen von Benutzernachrichten für dein Unternehmen.

Benutzer einer Instanz mit einer GitHub Advanced Security-Lizenz können den Empfang eines Webhookereignisses aktivieren, das ausgelöst wird, wenn ein Organisationsbesitzer oder ein Repositoryadministrator ein Feature für Codesicherheit oder -analyse aktiviert oder deaktiviert. Weitere Informationen findest du in der folgenden Dokumentation.

• Webhookereignisse und Nutzdaten in der Webhookdokumentation
• Verwalten von Sicherheits- und Analyseeinstellungen für deine Organisation
• Verwalten von Sicherheits- und Analysefunktionen für dein Repository

Benutzer einer Instanz mit einer GitHub Advanced Security-Lizenz können optional einen Kommentar hinzufügen, wenn sie eine Warnung zur Codeüberprüfung in der Webbenutzeroberfläche oder über die REST-API schließen. Kommentare zum Schließen werden in der Zeitleiste des Ereignisses aufgeführt. Zudem können Benutzer einen Kommentar zum Schließen über die REST-API hinzufügen oder abrufen. Weitere Informationen findest du in der REST-API-Dokumentation unter Filtern von Codeüberprüfungswarnungen in Pull Requests und unter Codeüberprüfung.

In Instanzen mit einer GitHub Advanced Security-Lizenz verhindert die Geheimnisüberprüfung die Offenlegung von Geheimnissen im Web-Editor. Weitere Informationen findest du unter Schützen von Pushs mit Geheimnisüberprüfung.

Unternehmensbesitzer und Benutzer einer Instanz mit einer GitHub Advanced Security-Lizenz können Warnungen der Geheimnisüberprüfung und Umgehungen des Pushschutzes der Geheimnisüberprüfung in den Überwachungsprotokollen des Unternehmens und der Organisation und über die REST-API anzeigen. Weitere Informationen findest du in der folgenden Dokumentation.

• Schützen von Pushes mit der Geheimnisüberprüfung
• Überwachungsprotokollereignisse für dein Unternehmen
• Überprüfen des Auditprotokolls deiner Organisation
• Geheimnisüberprüfung in der REST-API-Dokumentation

Unternehmensbesitzer einer Instanz mit einer GitHub Advanced Security-Lizenz können Probeläufe für benutzerdefinierte Muster der Geheimnisüberprüfung für das Unternehmen durchführen, und alle Benutzer können Probeläufe beim Bearbeiten eines Musters ausführen. Anhand von Probeläufen kannst du die Auswirkungen eines Musters für die gesamte Instanz verstehen und das Muster vor dem Veröffentlichen und Generieren von Warnungen nachbessern. Weitere Informationen findest du unter Definieren benutzerdefinierter Muster für Geheimnisüberprüfungen.

Benutzer*innen einer Instanz mit einer GitHub Advanced Security-Lizenz können beim Abrufen von Warnungen zur Geheimnisüberprüfung die Parameter sort und direction in der REST-API verwenden und die Warnungen nach den Feldern created und updated sortieren. Die neuen Parameter stehen für die gesamte Instanz oder für einzelne Organisationen oder Repositorys zur Verfügung. Weitere Informationen findest du in der folgenden Dokumentation.

• Auflisten von Warnungen zur Geheimnisüberprüfung für ein Unternehmen
• Auflisten von Warnungen zur Geheimnisüberprüfung für eine Organisation
• Auflisten von Warnungen zur Geheimnisüberprüfung für ein Repository
• Geheimnisüberprüfung in der REST-API-Dokumentation

Der Inhalt des Repositorys github/codeql-go wurde in das Repository github/codeql verschoben, damit es neben ähnlichen Bibliotheken für alle übrigen Programmiersprachen zu finden ist, die von CodeQL unterstützt werden. Die Open-Source-CodeQL-Abfragen, -Bibliotheken und -Extraktionsfunktionen zur Analyse von Codebasen, die in der Go-Programmiersprache mit den CodeQL-Codeanalysetools von GitHub geschrieben wurden, befinden sich jetzt am neuen Speicherort. Weitere Informationen, einschließlich Leitfäden zur Migration deiner vorhandenen Workflows, findest du unter github/codeql-go#741.

Unternehmensbesitzer von Instanzen mit einer GitHub Advanced Security-Lizenz können eine Übersicht über Dependabot-Warnungen für die gesamte Instanz anzeigen, einschließlich einer repositorybezogenen Ansicht von Risiken für die Anwendungssicherheit sowie einer warnungsbezogenen Ansicht aller Warnungen der Geheimnisüberprüfung und der Dependabot-Warnungen. Die Ansichten befinden sich in der Betaphase und können noch geändert werden. Warnungsbezogene Ansichten für die Geheimnisüberprüfung sind für ein zukünftiges Release von GitHub Enterprise Server geplant. Weitere Informationen findest du unter Informationen zur Sicherheitsübersicht.

Benutzer 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. Weitere Informationen findest du unter Informationen zu Dependabot-Warnungen."

• Hinweis: Dieses Feature ist in GitHub Enterprise Server 3.6.0 nicht verfügbar. Das Feature steht ab GitHub Enterprise Server 3.7.0 zur Verfügung. [Aktualisiert: 19.10.2022]

Dependabot aktualisiert @types-Abhängigkeiten neben entsprechenden Paketen in TypeScript-Projekten. Vor dieser Änderung wurden den Benutzerinnen für ein Paket und das entsprechende @types-Paket separate Pull Requests angezeigt. Dieses Feature ist für Repositorys mit @types-Paketen in den devDependencies des Projekts innerhalb der Datei package.json automatisch aktiviert. Du kannst dieses Verhalten deaktivieren, indem du das Feld ignore in deiner Datei dependabot.yml auf `@types/` festlegst. Weitere Informationen findest du unter Informationen zu Dependabot-Versionsupdates und unter Konfigurationsoptionen für die Datei dependabot.yml.

GitHub Actions kann Abhängigkeitsüberprüfungen für Pull Requests von Benutzern durch das Überprüfen auf Abhängigkeiten erzwingen und informiert Benutzer über damit verbundene Sicherheitsrisiken. Die Aktion dependency-review-action wird von einem neuen API-Endpunkt unterstützt, der die Abhängigkeiten zwischen zwei beliebigen Revisionen vergleicht. Weitere Informationen findest du unter Informationen zur Abhängigkeitsprüfung.

Das Abhängigkeitsdiagramm erkennt die Dateien Cargo.toml und Cargo.lock für Rust. Diese Dateien werden im Abschnitt Abhängigkeitsdiagramm auf der Registerkarte Erkenntnisse angezeigt. Benutzer*innen erhalten Dependabot-Warnungen und Updates zu Sicherheitsrisiken im Zusammenhang mit ihren Rust-Abhängigkeiten. Paketmetadaten, einschließlich Zuordnungspaketen für Repositorys, werden zu einem späteren Zeitpunkt hinzugefügt. Weitere Informationen findest du unter Informationen zum Abhängigkeitsdiagramm.

Wenn GitHub Connect für deine Instanz aktiviert ist, können Benutzer*innen eine Verbesserung für eine Sicherheitsempfehlung in der GitHub Advisory Database beitragen. Klicke hierzu in den Details einer Empfehlung auf Verbesserungen für dieses Sicherheitsrisiko vorschlagen. Weitere Informationen findest du in den folgenden Artikeln.

• Verwalten von GitHub Connect
• Durchsuchen von Sicherheitsrisiken in der GitHub Advisory Database in der GitHub Enterprise Cloud-Dokumentation
• Informationen zu GitHub-Sicherheitsempfehlungen für Repositorys in der GitHub Enterprise Cloud-Dokumentation
• Bearbeiten von Sicherheitsempfehlungen in der GitHub Advisory Database in der GitHub Enterprise Cloud-Dokumentation

Innerhalb eines Workflows, der einen wiederverwendbaren Workflow aufruft, können Benutzer*innen die Geheimnisse über secrets: inherit an den wiederverwendbaren Workflow weitergeben. Weitere Informationen findest du unter Wiederverwenden von Workflows.

Um bei Verwendung von GitHub Actions das Risiko zu verringern, dass eine nicht von einer weiteren Person überprüfte Änderung in einen geschützten Branch gemergt wird, können Unternehmensbesitzer und Repositoryadministratoren die Erstellung von Pull Requests in Actions verhindern. Organisationsbesitzer konnten diese Einschränkung zuvor aktivieren. Weitere Informationen findest du in den folgenden Artikeln.

• Erzwingen von Richtlinien für GitHub Actions in deinem Unternehmen
• Deaktivieren oder Einschränken von GitHub Actions für deine Organisation
• Verwalten von GitHub Actions-Einstellungen für ein Repository

Benutzerinnen können einen einzelnen Workflow schreiben, der von workflow_dispatch und workflow_call ausgelöst wird, und den inputs-Kontext verwenden, um auf Eingabewerte zuzugreifen. Zuvor befanden sich die workflow_dispatch-Eingaben in den Ereignisnutzdaten. Dies machte es für Workflowautorinnen schwieriger, einen Workflow zu schreiben, der sowohl wiederverwendbar als auch manuell auslösbar war. Für Workflows, die mit workflow_dispatch ausgelöst werden, sind Eingaben weiterhin im github.event.inputs-Kontext verfügbar, um die Kompatibilität zu gewährleisten. Weitere Informationen findest du unter Kontexte.

Um das Ergebnis eines Auftrags zusammenzufassen, können Benutzer Markdown generieren und die Inhalte als Auftragszusammenfassung veröffentlichen. Beispielsweise kann eine Zusammenfassung nach der Ausführung von Tests mit GitHub Actions eine Übersicht über erfolgreiche, fehlerhafte oder übersprungene Tests bieten, sodass möglicherweise nicht mehr die gesamte Protokollausgabe überprüft werden muss. Weitere Informationen findest du unter Workflowbefehle für GitHub Actions.

Zur einfacheren Diagnose von Auftragsausführungsfehlern bei der erneuten Ausführung eines Workflows können Benutzern die Debugprotokollierung aktivieren, die Informationen zur Ausführung und Umgebung eines Auftrags ausgibt. Weitere Informationen findest du unter Erneutes Ausführen von Workflows und Aufträgen und unter Verwenden von Workflowausführungsprotokollen.

Bei der Verwaltung selbstgehosteter Runner für GitHub Actions kannst du für den Runner selbst einen konsistenten Zustand vor und nach einer Workflowausführung sicherstellen, indem du Skripts zur Ausführung definierst. Durch die Verwendung von Skripts musst du nicht länger die Benutzer zur manuellen Implementierung dieser Skripts in Workflows auffordern. Skripts zur Ausführung vor und nach dem Auftrag befinden sich in der Betaphase und können noch geändert werden. Weitere Informationen findest du unter Ausführen von Skripts vor oder nach einem Auftrag.

Unternehmensbesitzer können Containerimages aus der GitHub Docker-Registrierung zur GitHub-Containerregistrierung migrieren. Die Containerregistrierung bietet die folgenden Vorteile.

• Sie verbessert die Freigabe von Containern innerhalb einer Organisation.
• Sie erlaubt die Anwendung präziser Zugriffsberechtigungen.
• Sie erlaubt die anonyme Freigabe öffentlicher Containerimages.
• Sie implementiert OCI-Standards zum Hosten von Docker-Images.

Die Containerregistrierung befindet sich in der Betaphase und kann noch geändert werden. Weitere Informationen findest du unter Migrieren deines Unternehmens von der Docker-Registrierung zur Containerregistrierung.

GitHub Discussions ist für GitHub Enterprise Server verfügbar. GitHub Discussions bietet einen zentralen Sammelpunkt, um Fragen zu stellen, Ideen zu teilen und Kontakte zu knüpfen. Weitere Informationen findest du unter GitHub-Diskussionen.

Unternehmensbesitzer können eine Richtlinie konfigurieren, um zu steuern, ob die Benutzernamen oder die vollständigen Namen von Personen in internen oder öffentlichen Repositorys angezeigt werden. Weitere Informationen findest du unter Erzwingen von Repositoryverwaltungsrichtlinien in deinem Unternehmen.

Benutzer können README-Dateien erstellen, die nur für Mitglieder einer Organisation bestimmt sind. Weitere Informationen findest du unter Anpassen des Profils deiner Organisation.

Organisationsbesitzer*innen können ein Repository mithilfe des neuen Dropdownfelds Repository anheften direkt über das Repository an das Profil einer Organisation anheften. Angeheftete öffentliche Repositorys werden allen Benutzern deiner Instanz angezeigt, während öffentliche, private und interne Repositorys nur für Organisationsmitglieder sichtbar sind.

Beim Erstellen eines Forks können Benutzer den Namen des Forks anpassen. Weitere Informationen findest du unter Forken eines Repositorys.

Benutzer können einen Branch löschen, der einem offenen Pull Request zugeordnet ist. Weitere Informationen findest du unter Erstellen und Löschen von Branches innerhalb deines Repositorys.

Bei Repositorys mit mehreren Lizenzen werden alle Lizenzen auf der Randleiste „Informationen“ der Registerkarte Code angezeigt. Weitere Informationen findest du unter Lizenzieren eines Repositorys.

Benutzer können die erfolgreiche Bereitstellung eines Branchs anfordern, bevor der dem Branch zugeordnete Pull Request gemergt werden kann. Weitere Informationen findest du unter Informationen zu geschützten Branches und Verwalten von Branchschutzregeln.

Unternehmensbesitzer können verhindern, dass Organisationsbesitzer Mitarbeiter zur Zusammenarbeit an Repositorys für die Instanz einladen. Weitere Informationen findest du unter Erzwingen einer Richtlinie zum Einladen von Projektmitarbeiter*innen zu Repositorys.

Benutzer können GitHub Apps Ausnahmen für Branchschutzregeln gewähren, die Ausnahmen unterstützen. Weitere Informationen findest du unter Informationen zu Apps und unter Verwalten von Branchschutzregeln.

Für öffentliche GPG-Signaturschlüssel, die abgelaufen sind oder widerrufen wurden, werden Git-Commitsignaturen von GitHub Enterprise Server verifiziert. Die Commits werden als verifiziert angezeigt, wenn der Benutzer den Commit ausgeführt hat, während der Schlüssel noch gültig war. Benutzer können auch abgelaufene oder widerrufene GPG-Schlüssel hochladen. Weitere Informationen findest du unter Informationen zur Commitsignaturverifizierung.

Um zu bestätigen, dass ein Commit den Regeln und Lizenzen für ein Repository entspricht, können Organisationsbesitzer und Repositoryadministratoren Entwickler jetzt dazu auffordern, über die Weboberfläche durchgeführte Commits zu signieren. Weitere Informationen findest du unter Verwalten der Richtlinie für das Abzeichnen von Commits für deine Organisation und unter Verwalten der Richtlinie für das Abzeichnen von Commits für dein Repository.

Über die Dateistruktur auf der Registerkarte Geänderte Dateien eines Pull Requests können Benutzer*innen durch geänderte Dateien navigieren, die Größe und den Umfang von Änderungen verstehen und sich auf Reviews konzentrieren. Die Dateistruktur wird angezeigt, wenn durch einen Pull Request mindestens zwei Dateien geändert werden und das Browserfenster ausreichend breit ist. Weitere Informationen findest du unter Überprüfen der vorgeschlagenen Änderungen in einem Pull Request und unter Filtern der Dateien in einem Pull Request.

Benutzer können standardmäßig die Titel von Pull Requests als Commitnachricht für alle Squashmerges verwenden. Weitere Informationen findest du unter Konfigurieren von Commit-Squashing für Pull Requests.

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

Wenn sie die Details für ein bestimmtes Release anzeigen, können Benutzer das Erstellungsdatum für die einzelnen Releaseressourcen einsehen. Weitere Informationen findest du unter Anzeigen der Releases und Tags deines Repositorys.

Beim Erstellen eines Release mit automatisch generierten Versionshinweisen können Benutzer das Tag anzeigen, das als vorheriges Release aufgeführt wird, und dann ein anderes Tag auswählen, das als vorheriges Release angegeben werden soll. Weitere Informationen findest du unter Automatisch generierte Versionshinweise.

Das Bearbeiten von Markdown in der Weboberfläche wurde verbessert.

• Sobald Benutzer*innen Text auswählen und eine URL einfügen, wird der ausgewählte Text in einen Markdownlink zur eingefügten URL umgewandelt.
• Wenn Benutzer*innen Tabellenzellen oder HTML-Tabellen einfügen, wird der resultierende Text als Tabelle gerendert.
• Wenn Benutzer*innen Text mit Links kopieren, enthält der eingefügte Text den Link als Markdownlink.

Weitere Informationen findest du unter Grundlegende Schreib- und Formatierungssyntax.

Beim Bearbeiten einer Markdowndatei auf der Weboberfläche wird durch Klicken auf die Registerkarte Vorschau automatisch zu der Stelle in der Vorschau gescrollt, die du gerade bearbeitet hast. Die Scrollposition beruht auf der Position deines Cursors vor dem Klicken auf die Registerkarte Vorschau.

Das unverschlüsselte und nicht authentifizierte Git-Protokoll ist jetzt standardmäßig deaktiviert. Wenn du das Protokoll nach dem Upgrade auf GitHub Enterprise Server 3.6 oder höher nicht erneut aktivierst, geben git://-Verbindungen an Port 9418 den folgenden Fehler zurück.

The unauthenticated git protocol on port 9418 is no longer supported.

Wenn du das Protokoll in deiner Umgebung unterstützen möchtest, musst du das Feature manuell reaktivieren. Weitere Informationen findest du unter Erzwingen von Repositoryverwaltungsrichtlinien in deinem Unternehmen und im GitHub-Blog. [Aktualisiert: 31.01.2023]

Interaktive Elemente in der Weboberfläche, z. B. Links oder Schaltflächen, weisen eine sichtbare Kontur auf, wenn sie über die Tastatur den Fokus erhalten, damit Benutzer einfacher die aktuelle Position auf einer Seite finden können. Außerdem sind Formularfelder, auf denen der Fokus liegt, durch eine Kontur mit stärkerem Kontrast gekennzeichnet.

Wenn ein Benutzer beim Erstellen eines neuen Issues oder Pull Requests die Seite aktualisiert, bleiben alle zugewiesenen Personen, Reviewer, Bezeichnungen und Projekte erhalten.

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

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.

Benutzerdefinierte Muster für die Geheimnisüberprüfung verwenden .* als Endtrennzeichen, insbesondere im Feld „Nach Geheimnis“. Dieses Trennzeichen verursacht Inkonsistenzen in repositoryübergreifenden Überprüfungen auf Geheimnisse, und du stellst möglicherweise Lücken im Repositoryverlauf fest, in denen keine Überprüfungen abgeschlossen wurden. Auch inkrementelle Überprüfungen werden möglicherweise beeinträchtigt. Um Probleme mit Überprüfungen zu verhindern, ändere das Ende des Musters, indem du das Trennzeichen .* entfernst.

In einigen Fällen stellen GitHub Advanced Security-Kunden, die ein Upgrade auf GitHub Enterprise Server 3.6 durchführen, fest, dass Warnungen aus Geheimnisüberprüfungen in der Webbenutzeroberfläche und der REST-API fehlen. Um sicherzustellen, dass die Warnungen sichtbar bleiben, überspringe Version 3.4 nicht beim Upgrade auf das neueste Release. Weitere Informationen zum Planen eines Upgrades über Version 3.4 findest du unter Upgrade-Assistent.

• Um die fehlenden Warnungen für alle Repositorys anzuzeigen, die einer Organisation gehören, können Organisationsinhaber*innen zu den Codesicherheits- und Analyseeinstellungen der Organisation navigieren und dann Alle aktivieren für Geheimnisscans auswählen. Weitere Informationen findest du unter Verwalten von Sicherheits- und Analyseeinstellungen für deine Organisation.
• Um die fehlenden Warnungen für ein einzelnes Repository anzuzeigen, können Benutzer*innen mit Administratorzugriff auf das Repository Geheimnisscans für das Repository zuerst deaktivieren und dann aktivieren. Weitere Informationen findest du unter Verwalten von Sicherheits- und Analyseeinstellungen für dein Repository.

Im Patchrelease 3.6.1 ist ein Fix verfügbar. [Aktualisiert: 2022-09-01]

Nach dem Upgrade eines Replikatknotens auf GitHub Enterprise Server 3.6.0 oder höher und dem Neustart der Replikation wird die Git-Replikation möglicherweise beendet, während weiterhin WARNING: git replication is behind the primary … angezeigt wird. Wenn dieses bekannte Problem auftritt, wende dich an den GitHub Enterprise Support. [Aktualisiert: 03.10.2022]

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

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]

Für Teilnehmer in der privaten Betaversion von SCIM für GitHub Enterprise Server werden jetzt benutzerdefinierte Zuordnungen für SAML-Benutzerattribute in diesem Release nicht unterstützt. Benutzerdefinierte Zuordnungen werden in GitHub Enterprise Server 3.6.5 oder 3.7.5 und höher unterstützt. [Aktualisiert: 27.02.2023]