Enterprise Server 3.6 release notes

On a freshly set up GitHub Enterprise Server instance without any users, an attacker could create the first admin user.

Custom firewall rules are removed during the upgrade process.

Git LFS tracked files uploaded through the web interface are incorrectly added directly to the repository.

Issues cannot be closed if they contain a permalink to a blob in the same repository, where the blob's file path is longer than 255 characters.

When "Users can search GitHub.com" is enabled with GitHub Connect, issues in private and internal repositories are not included in GitHub.com search results.

The GitHub Packages npm registry no longer returns a time value in metadata responses. This was done to allow for substantial performance improvements. We continue to have all the data necessary to return a time value as part of the metadata response and will resume returning this value in the future once we have solved the existing performance issues.

Resource limits that are specific to processing pre-receive hooks may cause some pre-receive hooks to fail.

Actions services need to be restarted after restoring an instance from a backup taken on a different host.

In a repository's settings, enabling the option to allow users with read access to create discussions does not enable this functionality.

In some cases, users cannot convert existing issues to discussions.

Custom patterns for secret scanning have .* as an end delimiter, specifically in the "After secret" field. This delimiter causes inconsistencies in scans for secrets across repositories, and you may notice gaps in a repository's history where no scans completed. Incremental scans may also be impacted. To prevent issues with scans, modify the end of the pattern to remove the .* delimiter.

Following an upgrade to GitHub Enterprise Server 3.6 or later, existing inconsistencies in a repository such as broken refs or missing objects, may now be reported as errors like invalid sha1 pointer 0000000000000000000000000000000000000000, Zero-length loose reference file, or Zero-length loose object file. Previously, these indicators of repository corruption may have been silently ignored. GitHub Enterprise Server now uses an updated Git version with more diligent error reporting enabled. For more information, see this upstream commit in the Git project.

If you suspect a problem like this exists in one of your repositories, contact GitHub Enterprise Support for assistance.

Instances experiencing a high sustained number of concurrent Git requests may experience performance issues. If you suspect that this issue is affecting your instance, contact GitHub Support. For more information, see "Creating a support ticket." [Updated: 2022-12-07]

In some cases, while converting an issue to a discussion, the conversion process may hang. In this situation, an enterprise owner can try the following troubleshooting steps to resolve the issue.

1. At the end of the stuck discussion's URL, note the discussion's number.
2. In the web UI, browse to the repository where the conversion is stuck.
3. In the top-right corner of the web UI, click .
4. Under "Collaboration", click NUMBER discussions.
5. In the list, click the number from step 1.
6. Under "Conversion", click Enqueue conversion job.
7. Wait a few minutes, then check the issue's status.

If the conversion still hasn't completed, contact GitHub Enterprise Support for assistance.

On a freshly set up GitHub Enterprise Server instance without any users, an attacker could create the first admin user.

Custom firewall rules are removed during the upgrade process.

Git LFS tracked files uploaded through the web interface are incorrectly added directly to the repository.

Issues cannot be closed if they contain a permalink to a blob in the same repository, where the blob's file path is longer than 255 characters.

When "Users can search GitHub.com" is enabled with GitHub Connect, issues in private and internal repositories are not included in GitHub.com search results.

The GitHub Packages npm registry no longer returns a time value in metadata responses. This was done to allow for substantial performance improvements. We continue to have all the data necessary to return a time value as part of the metadata response and will resume returning this value in the future once we have solved the existing performance issues.

Resource limits that are specific to processing pre-receive hooks may cause some pre-receive hooks to fail.

Actions services need to be restarted after restoring an instance from a backup taken on a different host.

In a repository's settings, enabling the option to allow users with read access to create discussions does not enable this functionality.

In some cases, users cannot convert existing issues to discussions.

Custom patterns for secret scanning have .* as an end delimiter, specifically in the "After secret" field. This delimiter causes inconsistencies in scans for secrets across repositories, and you may notice gaps in a repository's history where no scans completed. Incremental scans may also be impacted. To prevent issues with scans, modify the end of the pattern to remove the .* delimiter.

Following an upgrade to GitHub Enterprise Server 3.6 or later, existing inconsistencies in a repository such as broken refs or missing objects, may now be reported as errors like invalid sha1 pointer 0000000000000000000000000000000000000000, Zero-length loose reference file, or Zero-length loose object file. Previously, these indicators of repository corruption may have been silently ignored. GitHub Enterprise Server now uses an updated Git version with more diligent error reporting enabled. For more information, see this upstream commit in the Git project.

If you suspect a problem like this exists in one of your repositories, contact GitHub Enterprise Support for assistance.

Instances experiencing a high sustained number of concurrent Git requests may experience performance issues. If you suspect that this issue is affecting your instance, contact GitHub Support. For more information, see "Creating a support ticket." [Updated: 2022-12-07]

In some cases, while converting an issue to a discussion, the conversion process may hang. In this situation, an enterprise owner can try the following troubleshooting steps to resolve the issue.

1. At the end of the stuck discussion's URL, note the discussion's number.
2. In the web UI, browse to the repository where the conversion is stuck.
3. In the top-right corner of the web UI, click .
4. Under "Collaboration", click NUMBER discussions.
5. In the list, click the number from step 1.
6. Under "Conversion", click Enqueue conversion job.
7. Wait a few minutes, then check the issue's status.

If the conversion still hasn't completed, contact GitHub Enterprise Support for assistance.

On a freshly set up GitHub Enterprise Server instance without any users, an attacker could create the first admin user.

Custom firewall rules are removed during the upgrade process.

Git LFS tracked files uploaded through the web interface are incorrectly added directly to the repository.

Issues cannot be closed if they contain a permalink to a blob in the same repository, where the blob's file path is longer than 255 characters.

When "Users can search GitHub.com" is enabled with GitHub Connect, issues in private and internal repositories are not included in GitHub.com search results.

The GitHub Packages npm registry no longer returns a time value in metadata responses. This was done to allow for substantial performance improvements. We continue to have all the data necessary to return a time value as part of the metadata response and will resume returning this value in the future once we have solved the existing performance issues.

Resource limits that are specific to processing pre-receive hooks may cause some pre-receive hooks to fail.

Actions services need to be restarted after restoring an instance from a backup taken on a different host.

In a repository's settings, enabling the option to allow users with read access to create discussions does not enable this functionality.

In some cases, users cannot convert existing issues to discussions.

Custom patterns for secret scanning have .* as an end delimiter, specifically in the "After secret" field. This delimiter causes inconsistencies in scans for secrets across repositories, and you may notice gaps in a repository's history where no scans completed. Incremental scans may also be impacted. To prevent issues with scans, modify the end of the pattern to remove the .* delimiter.

Following an upgrade to GitHub Enterprise Server 3.6 or later, existing inconsistencies in a repository such as broken refs or missing objects, may now be reported as errors like invalid sha1 pointer 0000000000000000000000000000000000000000, Zero-length loose reference file, or Zero-length loose object file. Previously, these indicators of repository corruption may have been silently ignored. GitHub Enterprise Server now uses an updated Git version with more diligent error reporting enabled. For more information, see this upstream commit in the Git project.

If you suspect a problem like this exists in one of your repositories, contact GitHub Enterprise Support for assistance.

Instances experiencing a high sustained number of concurrent Git requests may experience performance issues. If you suspect that this issue is affecting your instance, contact GitHub Support. For more information, see "Creating a support ticket." [Updated: 2022-12-07]

On a freshly set up GitHub Enterprise Server instance without any users, an attacker could create the first admin user.

Custom firewall rules are removed during the upgrade process.

Git LFS tracked files uploaded through the web interface are incorrectly added directly to the repository.

Issues cannot be closed if they contain a permalink to a blob in the same repository, where the blob's file path is longer than 255 characters.

When "Users can search GitHub.com" is enabled with GitHub Connect, issues in private and internal repositories are not included in GitHub.com search results.

The GitHub Packages npm registry no longer returns a time value in metadata responses. This was done to allow for substantial performance improvements. We continue to have all the data necessary to return a time value as part of the metadata response and will resume returning this value in the future once we have solved the existing performance issues.

Resource limits that are specific to processing pre-receive hooks may cause some pre-receive hooks to fail.

Actions services need to be restarted after restoring an instance from a backup taken on a different host.

In a repository's settings, enabling the option to allow users with read access to create discussions does not enable this functionality.

In some cases, users cannot convert existing issues to discussions.

Custom patterns for secret scanning have .* as an end delimiter, specifically in the "After secret" field. This delimiter causes inconsistencies in scans for secrets across repositories, and you may notice gaps in a repository's history where no scans completed. Incremental scans may also be impacted. To prevent issues with scans, modify the end of the pattern to remove the .* delimiter.

Following an upgrade to GitHub Enterprise Server 3.6 or later, existing inconsistencies in a repository such as broken refs or missing objects, may now be reported as errors like invalid sha1 pointer 0000000000000000000000000000000000000000, Zero-length loose reference file, or Zero-length loose object file. Previously, these indicators of repository corruption may have been silently ignored. GitHub Enterprise Server now uses an updated Git version with more diligent error reporting enabled. For more information, see this upstream commit in the Git project.

If you suspect a problem like this exists in one of your repositories, contact GitHub Enterprise Support for assistance.

Instances experiencing a high sustained number of concurrent Git requests may experience performance issues. If you suspect that this issue is affecting your instance, contact GitHub Support. For more information, see "Creating a support ticket." [Updated: 2022-12-07]

On a freshly set up GitHub Enterprise Server instance without any users, an attacker could create the first admin user.

Custom firewall rules are removed during the upgrade process.

Git LFS tracked files uploaded through the web interface are incorrectly added directly to the repository.

Issues cannot be closed if they contain a permalink to a blob in the same repository, where the blob's file path is longer than 255 characters.

When "Users can search GitHub.com" is enabled with GitHub Connect, issues in private and internal repositories are not included in GitHub.com search results.

The GitHub Packages npm registry no longer returns a time value in metadata responses. This was done to allow for substantial performance improvements. We continue to have all the data necessary to return a time value as part of the metadata response and will resume returning this value in the future once we have solved the existing performance issues.

Resource limits that are specific to processing pre-receive hooks may cause some pre-receive hooks to fail.

Actions services need to be restarted after restoring an instance from a backup taken on a different host.

In a repository's settings, enabling the option to allow users with read access to create discussions does not enable this functionality.

In some cases, users cannot convert existing issues to discussions.

Custom patterns for secret scanning have .* as an end delimiter, specifically in the "After secret" field. This delimiter causes inconsistencies in scans for secrets across repositories, and you may notice gaps in a repository's history where no scans completed. Incremental scans may also be impacted. To prevent issues with scans, modify the end of the pattern to remove the .* delimiter.

Following an upgrade to GitHub Enterprise Server 3.6 or later, existing inconsistencies in a repository such as broken refs or missing objects, may now be reported as errors like invalid sha1 pointer 0000000000000000000000000000000000000000, Zero-length loose reference file, or Zero-length loose object file. Previously, these indicators of repository corruption may have been silently ignored. GitHub Enterprise Server now uses an updated Git version with more diligent error reporting enabled. For more information, see this upstream commit in the Git project.

If you suspect a problem like this exists in one of your repositories, contact GitHub Enterprise Support for assistance.

Instances experiencing a high sustained number of concurrent Git requests may experience performance issues. If you suspect that this issue is affecting your instance, contact GitHub Support. For more information, see "Creating a support ticket." [Updated: 2022-12-07]