diff --git a/.github/workflows/sync-search-elasticsearch.yml b/.github/workflows/sync-search-elasticsearch.yml index 4b19f97f65..365d9a59d4 100644 --- a/.github/workflows/sync-search-elasticsearch.yml +++ b/.github/workflows/sync-search-elasticsearch.yml @@ -91,6 +91,13 @@ jobs: runs-on: ubuntu-20.04-xl strategy: fail-fast: false + # When it's only English (i.e. a simple array of ['en']), this value + # does not matter. If it's ALL the languages, then we know we can + # be patient because it's a daily scheduled run and it's run by bots + # while humans are asleep. So there's no rush and no need to finish + # the whole job fast. + # As of June 2023, it takes about 10+ minutes to index one whole + # language and we have 8 non-English languages. max-parallel: 3 matrix: language: ${{ fromJSON(needs.figureOutMatrix.outputs.matrix) }} @@ -185,6 +192,7 @@ jobs: run: | ./src/search/scripts/index-elasticsearch.js /tmp/records \ --language ${{ matrix.language }} \ + --stagger-seconds 5 - name: Check created indexes and aliases run: | diff --git a/content/admin/configuration/configuring-your-enterprise/known-issues-with-backups-for-your-instance.md b/content/admin/configuration/configuring-your-enterprise/known-issues-with-backups-for-your-instance.md index c25ce8e50e..8331f71100 100644 --- a/content/admin/configuration/configuring-your-enterprise/known-issues-with-backups-for-your-instance.md +++ b/content/admin/configuration/configuring-your-enterprise/known-issues-with-backups-for-your-instance.md @@ -19,31 +19,18 @@ shortTitle: Known issues with backups ## Users cannot sign in after restoration of a backup -If you used {% data variables.product.prodname_enterprise_backup_utilities %} {% ifversion ghes = 3.7 %}3.7.0{% elsif ghes = 3.8 or ghes = 3.9 %}3.7.0 or 3.8.0{% endif %} to back up an instance running any release in the {% data variables.product.product_name %} 3.7{% ifversion ghes = 3.8 or ghes = 3.9 %} or 3.8{% endif %} series, after you restore the backup to a new instance, users cannot sign in. Though users cannot sign in, the backup itself is unaffected and all data is intact. +If you used {% data variables.product.prodname_enterprise_backup_utilities %} {% ifversion ghes = 3.7 %}3.7.0{% elsif ghes = 3.8 %}3.7.0 or 3.8.0{% elsif ghes = 3.9 %}3.7.0, 3.8.0, or 3.9.0{% endif %} to back up an instance running any release in the {% data variables.product.product_name %} 3.7{% ifversion ghes = 3.8 or ghes = 3.9 %} or 3.8{% endif %} series, after you restore the backup to a new instance, users cannot sign in. Though users cannot sign in, the backup itself is unaffected and all data is intact. -To address this issue, upgrade {% data variables.product.prodname_enterprise_backup_utilities %} on your backup host, then create a new backup. Alternatively, you can modify the configuration on a new target instance to restore an existing backup affected by this issue. - -- [Upgrading {% data variables.product.prodname_enterprise_backup_utilities %}](#upgrading-github-enterprise-server-backup-utilities) -- [Restoring from an existing backup](#restoring-from-an-existing-backup) - -### Upgrading {% data variables.product.prodname_enterprise_backup_utilities %} - -To create a new backup, upgrade {% data variables.product.prodname_enterprise_backup_utilities %} on your backup host to version {% ifversion ghes = 3.7 %}3.7.1{% elsif ghes = 3.8 or ghes = 3.9 %}3.7.1 or 3.8.1{% endif %}, then use the `ghe-backup` utility to back up your instance running {% data variables.product.product_name %} {% ifversion ghes = 3.7 %}3.7{% elsif ghes = 3.8 or ghes = 3.9 %}3.7 or 3.8{% endif %}. For more information, see "[AUTOTITLE](/admin/configuration/configuring-your-enterprise/configuring-backups-on-your-appliance)" and [{% ifversion ghes = 3.7 %}the 3.7.1 release{% elsif ghes = 3.8 or ghes = 3.9 %}releases{% endif %}](https://github.com/github/backup-utils/releases{% ifversion ghes = 3.7 %}/tag/v3.7.1{% endif %}) in the github/backup-utils repository. - -{% ifversion ghes = 3.9 %} - -If your instance is already running {% data variables.product.product_name %} 3.9 and users can sign in, you can upgrade to {% data variables.product.prodname_enterprise_backup_utilities %} 3.9.0 on your backup host and continue backing up normally. For more information, see the [3.9.0 release](https://github.com/github/backup-utils/releases/tag/v3.9.0) in the `github/backup-utils` repository. - -{% endif %} +After you restore an existing backup affected by this issue, you can resolve the issue by modifying the configuration on the new instance. ### Restoring from an existing backup -If you've restored an existing backup from {% data variables.product.prodname_enterprise_backup_utilities %} {% ifversion ghes = 3.7 %}3.7.0{% elsif ghes = 3.8 or ghes = 3.9 %}3.8.0{% endif %} to a new instance and users cannot sign in, you must output configuration data from the source {% data variables.product.product_name %} instance and adjust the configuration on the target instance. +If you've restored an existing backup from {% data variables.product.prodname_enterprise_backup_utilities %} {% ifversion ghes = 3.7 %}3.7.0{% elsif ghes = 3.8 %}3.8.0{% elsif ghes = 3.9%}3.7.0, 3.8.0, or 3.9.0{% endif %} to a new instance and users cannot sign in, you must output configuration data from the source {% data variables.product.product_name %} instance and adjust the configuration on the target instance. To ensure users can sign into the new target instance, ensure that your environment meets the following requirements. - The source {% data variables.product.product_name %} instance must be running and accessible via SSH. -- You must have an existing backup from {% data variables.product.prodname_enterprise_backup_utilities %} {% ifversion ghes = 3.7 %}3.7.0{% elsif ghes = 3.8 or ghes = 3.9 %}3.8.0{% endif %}. +- You must have an existing backup from {% data variables.product.prodname_enterprise_backup_utilities %} {% ifversion ghes = 3.7 %}3.7.0{% elsif ghes = 3.8 %}3.7.0 or 3.8.0{% elsif ghes = 3.9 %}3.7.0, 3.8.0, or 3.9.0{% endif %}. - You must have provisioned a new target {% data variables.product.product_name %} instance and restored the backup. For more information, see "[AUTOTITLE](/admin/installation/setting-up-a-github-enterprise-server-instance)" and "[AUTOTITLE](/admin/configuration/configuring-your-enterprise/configuring-backups-on-your-instance)." 1. SSH into the source {% data variables.product.product_name %} instance that you backed up. If your instance comprises multiple nodes, for example if high availability or geo-replication are configured, SSH into the primary node. If you use a cluster, you can SSH into any node. Replace HOSTNAME with the actual hostname of your instance. For more information about SSH access, see "[AUTOTITLE](/admin/configuration/configuring-your-enterprise/accessing-the-administrative-shell-ssh)." @@ -119,4 +106,4 @@ To ensure users can sign into the new target instance, ensure that your environm ``` 1. Have a user sign into the destination instance. If any issues arise, contact {% data variables.contact.enterprise_support %}. For more information, see "[AUTOTITLE](/support/contacting-github-support)." -{% endif %} \ No newline at end of file +{% endif %} diff --git a/content/admin/policies/enforcing-policy-with-pre-receive-hooks/creating-a-pre-receive-hook-script.md b/content/admin/policies/enforcing-policy-with-pre-receive-hooks/creating-a-pre-receive-hook-script.md index 527c41422d..8a1334926e 100644 --- a/content/admin/policies/enforcing-policy-with-pre-receive-hooks/creating-a-pre-receive-hook-script.md +++ b/content/admin/policies/enforcing-policy-with-pre-receive-hooks/creating-a-pre-receive-hook-script.md @@ -159,7 +159,7 @@ You can test a pre-receive hook script locally before you create or update it on 1. Create a file called `Dockerfile.dev` containing: ```dockerfile - FROM gliderlabs/alpine:3.3 + FROM alpine:latest RUN \ apk add --no-cache git openssh bash && \ ssh-keygen -A && \ @@ -197,23 +197,24 @@ You can test a pre-receive hook script locally before you create or update it on ```shell $ docker build -f Dockerfile.dev -t pre-receive.dev . - > Sending build context to Docker daemon 3.584 kB - > Step 1 : FROM gliderlabs/alpine:3.3 - > ---> 8944964f99f4 - > Step 2 : RUN apk add --no-cache git openssh bash && ssh-keygen -A && sed -i "s/#AuthorizedKeysFile/AuthorizedKeysFile/g" /etc/ssh/sshd_config && adduser git -D -G root -h /home/git -s /bin/bash && passwd -d git && su git -c "mkdir /home/git/.ssh && ssh-keygen -t ed25519 -f /home/git/.ssh/id_ed25519 -P ' && mv /home/git/.ssh/id_ed25519.pub /home/git/.ssh/authorized_keys && mkdir /home/git/test.git && git --bare init /home/git/test.git" - > ---> Running in e9d79ab3b92c - > fetch http://alpine.gliderlabs.com/alpine/v3.3/main/x86_64/APKINDEX.tar.gz - > fetch http://alpine.gliderlabs.com/alpine/v3.3/community/x86_64/APKINDEX.tar.gz - ....truncated output.... - > OK: 34 MiB in 26 packages - > ssh-keygen: generating new host keys: RSA DSA ECDSA ED25519 - > Password for git changed by root - > Generating public/private ed25519 key pair. - > Your identification has been saved in /home/git/.ssh/id_ed25519. - > Your public key has been saved in /home/git/.ssh/id_ed25519.pub. - ....truncated output.... - > Initialized empty Git repository in /home/git/test.git/ - > Successfully built dd8610c24f82 + [+] Building 4.5s (8/8) FINISHED + => [internal] load build definition from Dockerfile.dev 0.0s + => => transferring dockerfile: 641B 0.0s + => [internal] load .dockerignore 0.0s + => transferring context: 2B 0.0s + => [internal] load metadata for docker.io/library/alpine:latest 1.9s + => [auth] library/alpine:pull token for registry-1.docker.io 0.0s + => [1/3] FROM docker.io/library/alpine:latest@sha256:82d1e9d7ed48a7523bdebc18cf6290bdb97b82302a8a9c27d4fe885949ea94d1 0.0s + => => resolve docker.io/library/alpine:latest@sha256:82d1e9d7ed48a7523bdebc18cf6290bdb97b82302a8a9c27d4fe885949ea94d1 0.0s + => => sha256:82d1e9d7ed48a7523bdebc18cf6290bdb97b82302a8a9c27d4fe885949ea94d1 1.64kB / 1.64kB 0.0s + => => sha256:25fad2a32ad1f6f510e528448ae1ec69a28ef81916a004d3629874104f8a7f70 528B / 528B 0.0s + => => sha256:c1aabb73d2339c5ebaa3681de2e9d9c18d57485045a4e311d9f8004bec208d67 1.47kB / 1.47kB 0.0s + => [2/3] RUN apk add --no-cache git openssh bash && ssh-keygen -A && sed -i "s/#AuthorizedKeysFile/AuthorizedKeysFile/g" /e 2.3s + => [3/3] WORKDIR /home/git 0.0s + => exporting to image 0.1s + => => exporting layers 0.1s + => => writing image sha256:938447846e19a4328a85883fbd1ccf5eb919d97448cc7256efebf403d8b5a196 0.0s + => => naming to docker.io/library/pre-receive.dev ``` 1. Run a data container that contains a generated SSH key: @@ -247,16 +248,16 @@ You can test a pre-receive hook script locally before you create or update it on $ git clone git@github.com:octocat/Hello-World.git $ cd Hello-World $ git remote add test git@127.0.0.1:test.git - $ GIT_SSH_COMMAND="ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -p 52311 -i ../id_ed25519" git push -u test main - > Warning: Permanently added '[192.168.99.100]:52311' (ECDSA) to the list of known hosts. + $ GIT_SSH_COMMAND="ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -p 52311 -i ../id_ed25519" git push -u test master + > Warning: Permanently added '[127.0.0.1]:52311' (ECDSA) to the list of known hosts. > Counting objects: 7, done. > Delta compression using up to 4 threads. > Compressing objects: 100% (3/3), done. > Writing objects: 100% (7/7), 700 bytes | 0 bytes/s, done. > Total 7 (delta 0), reused 7 (delta 0) > remote: error: rejecting all pushes - > To git@192.168.99.100:test.git - > ! [remote rejected] main -> main (pre-receive hook declined) + > To git@127.0.0.1:test.git + > ! [remote rejected] master -> master (pre-receive hook declined) > error: failed to push some refs to 'git@192.168.99.100:test.git' ``` diff --git a/content/apps/oauth-apps/building-oauth-apps/authenticating-to-the-rest-api-with-an-oauth-app.md b/content/apps/oauth-apps/building-oauth-apps/authenticating-to-the-rest-api-with-an-oauth-app.md index 0b281ecd69..5dbc90b693 100644 --- a/content/apps/oauth-apps/building-oauth-apps/authenticating-to-the-rest-api-with-an-oauth-app.md +++ b/content/apps/oauth-apps/building-oauth-apps/authenticating-to-the-rest-api-with-an-oauth-app.md @@ -29,15 +29,16 @@ You can download the complete source code for this project [from the platform-sa ## Registering your app -First, you'll need to [register your application](https://github.com/settings/applications/new). Every +First, you'll need to [register your application][new oauth app]. Every registered {% data variables.product.prodname_oauth_app %} is assigned a unique Client ID and Client Secret. -The Client Secret should not be shared! That includes checking the string -into your repository. +The client secret is used to get an access token for the signed-in user. You must +include the client secret in your native application, however web applications should not leak this value. -You can fill out every piece of information however you like, except the -**Authorization callback URL**. This is easily the most important piece to setting -up your application. It's the callback URL that {% data variables.product.product_name %} returns the user to after -successful authentication. +You can fill out every other piece of information however you like, except the +**Authorization callback URL**. This is the most important piece to securely setting +up your application. It's the callback URL that {% data variables.product.product_name %} +returns the user to after successful authentication. Ownership of that URL is what ensures +that users sign into your app, instead of leaking tokens to an attacker. Since we're running a regular Sinatra server, the location of the local instance is set to `http://127.0.0.1:4567`. Let's fill in the callback URL as `http://127.0.0.1:4567/callback`. @@ -61,10 +62,10 @@ get '/' do end ``` -Your client ID and client secret keys come from [your application's configuration -page][app settings].{% ifversion fpt or ghec %} You should **never, _ever_** store these values in -{% data variables.product.product_name %}--or any other public place, for that matter.{% endif %} We recommend storing them as -[environment variables][about env vars]--which is exactly what we've done here. +Your client ID and client secret come from [your application's configuration +page][app settings]. We recommend storing these values as +[environment variables][about env vars] for ease of replacement and use -- +which is exactly what we've done here. Next, in _views/index.erb_, paste this content: @@ -124,7 +125,8 @@ end ``` After a successful app authentication, {% data variables.product.product_name %} provides a temporary `code` value. -You'll need to `POST` this code back to {% data variables.product.product_name %} in exchange for an `access_token`. +You'll need to `POST` this code back to {% data variables.product.product_name %} with your client secret +in exchange for an `access_token`. To simplify our GET and POST HTTP requests, we're using the [rest-client][REST Client]. Note that you'll probably never access the API through REST. For a more serious application, you should probably use [a library written in the language of your choice][libraries]. @@ -144,7 +146,7 @@ get '/callback' do # check if we were granted user:email scope scopes = JSON.parse(result)['scope'].split(',') - has_user_email_scope = scopes.include? 'user:email' + has_user_email_scope = scopes.include? 'user:email' || scopes.include? 'user' end ``` @@ -154,10 +156,12 @@ email addresses. Had the application asked for other scopes, we would have checked for those as well. Also, since there's a hierarchical relationship between scopes, you should -check that you were granted the lowest level of required scopes. For example, -if the application had asked for `user` scope, it might have been granted only -`user:email` scope. In that case, the application wouldn't have been granted -what it asked for, but the granted scopes would have still been sufficient. +check if you were granted any higher levels of the required scope. For example, +if the application had asked for `user` scope, it won't have been granted explicitly the +`user:email` scope. In that case, it would recieve a token with the `user` scope, which +would work for requesting the user's email address, even though it doesn't explicitly include +`user:email` on the token. Checking for both `user` and `user:email` ensures that you +check for both scenarios. Checking for scopes only before making requests is not enough since it's possible that users will change the scopes in between your check and the actual request. @@ -165,7 +169,7 @@ In case that happens, API calls you expected to succeed might fail with a `404` or `401` status, or return a different subset of information. To help you gracefully handle these situations, all API responses for requests -made with valid tokens also contain an [`X-OAuth-Scopes` header][oauth scopes]. +made with valid OAuth app tokens also contain an [`X-OAuth-Scopes` header][oauth scopes]. This header contains the list of scopes of the token that was used to make the request. In addition to that, the REST API provides an endpoint to {% ifversion fpt or ghes or ghec %} [check a token for validity](/rest/apps#check-a-token){% else %}[check a token for validity](/rest/apps#check-an-authorization){% endif %}. @@ -240,7 +244,7 @@ require 'sinatra' require 'rest_client' require 'json' -# !!! DO NOT EVER USE HARD-CODED VALUES IN A REAL APP !!! +# Don't use hard-coded values in your app # Instead, set and test environment variables, like below # if ENV['GITHUB_CLIENT_ID'] && ENV['GITHUB_CLIENT_SECRET'] # CLIENT_ID = ENV['GITHUB_CLIENT_ID'] @@ -360,6 +364,7 @@ Also, if we had never authorized this application to access our {% data variable we would've seen the same confirmation dialog from earlier pop-up and warn us. [webflow]: /apps/oauth-apps/building-oauth-apps/authorizing-oauth-apps +[new oauth app]: https://github.com/settings/applications/new [Sinatra]: http://www.sinatrarb.com/ [about env vars]: http://en.wikipedia.org/wiki/Environment_variable#Getting_and_setting_environment_variables [Sinatra guide]: https://github.com/sinatra/sinatra-book/blob/master/book/Introduction.markdown#hello-world-application diff --git a/content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning-for-a-repository.md b/content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning-for-a-repository.md index 92096fc2cb..88aa0b7c64 100644 --- a/content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning-for-a-repository.md +++ b/content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning-for-a-repository.md @@ -68,24 +68,18 @@ You can use default setup if your repository includes languages that aren't supp {% data reusables.code-scanning.default-setup-automatic %} -{% ifversion code-scanning-without-workflow-310 %} - {% note %} **Note:** If your repository contains _only_ {% data variables.product.prodname_codeql %}-supported compiled languages (for example, Java), then you will be taken to the configuration page to select the languages you want to add to your default setup configuration. {% endnote %} -{% endif %} - {% else %} Your repository is eligible for default setup if it uses {% data variables.product.prodname_actions %} and contains only the following {% data variables.product.prodname_codeql %}-supported languages:{% ifversion code-scanning-default-setup-go %} Go,{% endif %} JavaScript/TypeScript, Python, or Ruby. While you can use default setup if your repository includes languages that aren't supported by {% data variables.product.prodname_codeql %}, such as R, you must use the advanced setup if you include {% data variables.product.prodname_codeql %}-supported languages other than those previously listed. For more information on {% data variables.product.prodname_codeql %}-supported languages, see "[AUTOTITLE](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/about-code-scanning-with-codeql#about-codeql)."{% ifversion org-enable-code-scanning %} For information on bulk enablement, see "[AUTOTITLE](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning-at-scale)."{% endif %} {% endif %} -{% data reusables.code-scanning.default-setup-automatic %} - Enabling default setup is the quickest way to configure {% data variables.product.prodname_code_scanning %} for your repository. Additionally, default setup requires none of the maintenance necessary with a {% data variables.product.prodname_codeql %} workflow file. Before you enable default setup, you'll see the languages it will analyze, the query suites it will run, and the events that will trigger a new scan. Try default setup if you don't need to run extra queries, change the scan schedule, or scan a language that is currently unsupported by default setup. diff --git a/content/codespaces/developing-in-codespaces/using-github-codespaces-with-github-cli.md b/content/codespaces/developing-in-codespaces/using-github-codespaces-with-github-cli.md index edc36fba64..43c2186b1a 100644 --- a/content/codespaces/developing-in-codespaces/using-github-codespaces-with-github-cli.md +++ b/content/codespaces/developing-in-codespaces/using-github-codespaces-with-github-cli.md @@ -21,6 +21,7 @@ redirect_from: You can work with {% data variables.product.prodname_github_codespaces %} in the {% data variables.product.prodname_cli %} to: - [List all of your codespaces](#list-all-of-your-codespaces) - [Create a new codespace](#create-a-new-codespace) +- [View details of a codespace](#view-details-of-a-codespace) - [Stop a codespace](#stop-a-codespace) - [Delete a codespace](#delete-a-codespace) - [Rename a codespace](#rename-a-codespace) @@ -86,6 +87,25 @@ gh codespace create -r OWNER/REPO_NAME [-b BRANCH] For more information, see "[AUTOTITLE](/codespaces/developing-in-codespaces/creating-a-codespace-for-a-repository)." +### View details of a codespace + +```shell +gh codespace view +``` + +After running this command you are prompted to choose one of your existing codespaces. The following information is then displayed: +- Name of the codespace +- State (for example, "Available" or "Shutdown") +- Repository +- Git status +- Path to the dev container configuration file used to create the codespace +- Machine type +- Idle timeout +- Date and time the codespace was created +- Retention period + +For more information, see the [{% data variables.product.prodname_dotcom %} CLI reference](https://cli.github.com/manual/gh_codespace_view). + ### Stop a codespace ```shell diff --git a/content/codespaces/managing-your-codespaces/managing-repository-access-for-your-codespaces.md b/content/codespaces/managing-your-codespaces/managing-repository-access-for-your-codespaces.md index b00add4dc9..f3bb405a18 100644 --- a/content/codespaces/managing-your-codespaces/managing-repository-access-for-your-codespaces.md +++ b/content/codespaces/managing-your-codespaces/managing-repository-access-for-your-codespaces.md @@ -19,9 +19,15 @@ By default, your codespace is assigned a token scoped with `read` permission or - If you create a codespace for a repository to which you only have read access, then make a commit in the codespace or push a new branch, {% data variables.product.prodname_github_codespaces %} automatically links your codespace to a new or existing fork of the repository and updates the token to have `read` and `write` permission to the fork. For more information, see "[AUTOTITLE](/codespaces/developing-in-codespaces/using-source-control-in-your-codespace#about-automatic-forking)." - If you create a codespace from a template, then publish the codespace to a new repository, {% data variables.product.prodname_github_codespaces %} updates the token to have `read` and `write` permission to the new repository. For more information, see "[AUTOTITLE](/codespaces/developing-in-codespaces/creating-a-codespace-from-a-template#publishing-to-a-repository-on-github)." +For more information, see "[AUTOTITLE](/codespaces/codespaces-reference/security-in-github-codespaces#authentication)." + If your project needs additional permissions for other repositories, you can configure this in the `devcontainer.json` file and ensure other collaborators have the right set of permissions. When permissions are listed in the `devcontainer.json` file, you will be prompted to review and authorize the additional permissions as part of codespace creation for that repository. Once you've authorized the listed permissions, {% data variables.product.prodname_github_codespaces %} will remember your choice and will not prompt you for authorization unless the permissions in the `devcontainer.json` file change. -For more information, see "[AUTOTITLE](/codespaces/codespaces-reference/security-in-github-codespaces#authentication)." +{% note %} + +**Note:** Updating the permissions in the `devcontainer.json` file does not change the permissions of existing codespaces. If you need additional permissions in an existing codespace, see "[AUTOTITLE](/codespaces/troubleshooting/troubleshooting-authentication-to-a-repository#authenticating-to-repositories-that-you-didnt-create-the-codespace-from)." + +{% endnote %} ## Prerequisites diff --git a/content/codespaces/troubleshooting/troubleshooting-authentication-to-a-repository.md b/content/codespaces/troubleshooting/troubleshooting-authentication-to-a-repository.md index b5ef7fca24..cd6cffae17 100644 --- a/content/codespaces/troubleshooting/troubleshooting-authentication-to-a-repository.md +++ b/content/codespaces/troubleshooting/troubleshooting-authentication-to-a-repository.md @@ -41,9 +41,9 @@ If you're working in a codespace created from a repository you trust, and you ne The `GITHUB_TOKEN` in a codespace is configured with read and write access to the repository from which you created the codespace. By default, the token does not have access to other repositories. You may find you cannot clone a repository, or you cannot push to a repository you have cloned. -We do not recommend manually updating the value of the `GITHUB_TOKEN` in a codespace. If your project requires additional access to other repositories, we recommend you give access to these repositories in your dev container configuration. For more information, see "[AUTOTITLE](/codespaces/managing-your-codespaces/managing-repository-access-for-your-codespaces)." +We do not recommend manually updating the value of the `GITHUB_TOKEN` in a codespace. If your project requires access to other repositories, you can give codespaces access to these repositories by listing additional permissions in your dev container configuration. This will allow users to authorize the additional permissions when they create a codespace. However, it will not change the permissions of an existing codespace. For more information, see "[AUTOTITLE](/codespaces/managing-your-codespaces/managing-repository-access-for-your-codespaces)." -If you need access to another repository, but don't want to update the dev container configuration, you can create a {% data variables.product.pat_generic %} with access to the repository and add the token to your codespace. We recommend you limit the token's access by using a {% data variables.product.pat_v2 %}, selecting only the repositories to which you need access, and giving the required access to the **Contents** permission only. For more information, see "[AUTOTITLE](/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token#creating-a-fine-grained-personal-access-token)." +If you need access to another repository in an existing codespace, or if the permissions you need are specific to you and don't apply to other contributors, you can create a {% data variables.product.pat_generic %} with access to the repository and add the token to your codespace. We recommend you limit the token's access by using a {% data variables.product.pat_v2 %}, selecting only the repositories to which you need access, and giving the required access to the **Contents** permission only. For more information, see "[AUTOTITLE](/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token#creating-a-fine-grained-personal-access-token)." You can then add the token as an environment variable in a codespace, or as an encrypted secret for {% data variables.product.prodname_github_codespaces %}. If you create an encrypted secret, you should only allow certain trusted repositories to access the secret. When you add a new encrypted secret, you will be prompted to reload your existing codespace to pull in the new secret. For more information, see "[AUTOTITLE](/codespaces/managing-your-codespaces/managing-encrypted-secrets-for-your-codespaces)." diff --git a/content/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility.md b/content/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility.md index 1fa9dee38c..c7ac8413fb 100644 --- a/content/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility.md +++ b/content/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility.md @@ -75,7 +75,7 @@ The selected users or teams will automatically be given access and don't need to ## Selecting whether a package inherits permissions from a repository -{% ifversion packages-inherit-permissions %}By default, if publish a package that is linked to a repository, the package inherits{% else %}If you link a package to a repository, you can choose whether or not the package inherits{% endif %} the access permissions of the linked repository. We recommend you let packages inherit their permissions from a repository, because this simplifies the process of managing access to a package. +{% ifversion packages-inherit-permissions %}By default, if you publish a package that is linked to a repository, the package inherits{% else %}If you link a package to a repository, you can choose whether or not the package inherits{% endif %} the access permissions of the linked repository. We recommend you let packages inherit their permissions from a repository, because this simplifies the process of managing access to a package. When a package inherits permissions from a repository, to grant or remove access to your package, you must configure the permissions of the linked repository. diff --git a/content/rest/enterprise-admin/manage-ghes.md b/content/rest/enterprise-admin/manage-ghes.md index 2af80af9ba..af88751837 100644 --- a/content/rest/enterprise-admin/manage-ghes.md +++ b/content/rest/enterprise-admin/manage-ghes.md @@ -26,6 +26,20 @@ To authenticate requests to endpoints for the Manage {% data variables.product.p curl -L -u "api_key:ROOT-SITE-ADMINISTRATOR-PASSWORD" 'http(s)://HOSTNAME:ADMINISTRATION-PORT/manage' ``` +{% ifversion enterprise-management-console-multi-user-auth %} + +### Authentication as a {% data variables.enterprise.management_console %} user + +{% data variables.enterprise.management_console %} user accounts can also authenticate to access these endpoints. For more information, see "[AUTOTITLE](/admin/configuration/administering-your-instance-from-the-management-console/managing-access-to-the-management-console#management-console-user)." + +To authenticate with the password for a {% data variables.enterprise.management_console %} user account, use standard HTTP authentication. In the following example, replace YOUR_USER_NAME and YOUR_PASSWORD with the account's user name and password. + +```shell +curl -L -u "YOUR_USER_NAME:YOUR_PASSWORD" 'http(s)://HOSTNAME:ADMINISTRATION-PORT/manage' +``` + +{% endif %} + ### Query parameters By default, the response includes information from about all configured nodes for the instance. On an instance with multiple nodes, the details originate from `/data/user/common/cluster.conf`. You can use the following query parameters to filter the response for information about specific nodes. diff --git a/data/release-notes/enterprise-server/3-7/12.yml b/data/release-notes/enterprise-server/3-7/12.yml index a0797d7126..6fc77e82e4 100644 --- a/data/release-notes/enterprise-server/3-7/12.yml +++ b/data/release-notes/enterprise-server/3-7/12.yml @@ -15,6 +15,8 @@ sections: changes: - If a configuration runs fails due to Elasticsearch errors, `ghe-config-apply` displays a more actionable error message. known_issues: + - | + {% data reusables.release-notes.enterprise-backup-utils-encryption-keys %} - | Custom firewall rules are removed during the upgrade process. - | diff --git a/data/reusables/enterprise_backup_utilities/enterprise-backup-utils-encryption-keys.md b/data/reusables/enterprise_backup_utilities/enterprise-backup-utils-encryption-keys.md index a5bd924e50..b2c0da8285 100644 --- a/data/reusables/enterprise_backup_utilities/enterprise-backup-utils-encryption-keys.md +++ b/data/reusables/enterprise_backup_utilities/enterprise-backup-utils-encryption-keys.md @@ -1 +1 @@ -After restoration of a backup created using {% data variables.product.prodname_enterprise_backup_utilities %} {% ifversion ghes = 3.7 %}3.7.0{% elsif ghes = 3.8 or ghes = 3.9 %}3.7.0 or 3.8.0{% endif %}, users may not be able to sign into the instance. For more information, see "[AUTOTITLE](/admin/configuration/configuring-your-enterprise/known-issues-with-backups-for-your-instance#known-issue-users-cannot-sign-in-after-restoration-of-a-backup)." \ No newline at end of file +After restoration of a backup created using {% data variables.product.prodname_enterprise_backup_utilities %} {% ifversion ghes = 3.7 %}3.7.0{% elsif ghes = 3.8 %}3.7.0 or 3.8.0{% elsif ghes = 3.9 %}3.7.0, 3.8.0, or 3.9.0{% endif %}, users may not be able to sign into the instance. For more information, see "[AUTOTITLE](/admin/configuration/configuring-your-enterprise/known-issues-with-backups-for-your-instance#known-issue-users-cannot-sign-in-after-restoration-of-a-backup)." diff --git a/data/reusables/security/compliance-report-list.md b/data/reusables/security/compliance-report-list.md index cb121885f2..7e8a73783d 100644 --- a/data/reusables/security/compliance-report-list.md +++ b/data/reusables/security/compliance-report-list.md @@ -1,5 +1,8 @@ - SOC 1, Type 2 - SOC 2, Type 2 -- Cloud Security Alliance CAIQ self-assessment (CSA CAIQ) +- Cloud Security Alliance CAIQ self-assessment (CSA CAIQ - Level 1) - ISO/IEC 27001:2013 certification +- ISO/IEC 27701:2019 (Processor) certification +- ISO/IEC 27018:2019 certification +- Cloud Security Alliance STAR certification (CSA STAR - Level 2) - {% data variables.product.prodname_dotcom_the_website %} Services Continuity and Incident Management Plan diff --git a/src/content-linter/tests/site-data-references.js b/src/content-linter/tests/site-data-references.js index 1f9e5be267..490ca27ad2 100644 --- a/src/content-linter/tests/site-data-references.js +++ b/src/content-linter/tests/site-data-references.js @@ -32,12 +32,16 @@ describe('data references', () => { let errors = [] expect(pages.length).toBeGreaterThan(0) + const checked = new Set() pages.forEach((page) => { - const file = path.join('content', page.relativePath) const pageRefs = getDataReferences(page.markdown) - pageRefs.forEach((key) => { + new Set(pageRefs).forEach((key) => { + if (checked.has(key)) return const value = getDataByLanguage(key, 'en') - if (typeof value !== 'string') errors.push({ key, value, file }) + checked.add(key) + if (typeof value !== 'string') { + errors.push({ key, value, file: path.join('content', page.relativePath) }) + } }) }) diff --git a/src/search/middleware/contextualize.js b/src/search/middleware/contextualize.js index 08f91bf0b3..b89367def5 100644 --- a/src/search/middleware/contextualize.js +++ b/src/search/middleware/contextualize.js @@ -1,4 +1,5 @@ import got from 'got' +import { errors } from '@elastic/elasticsearch' import { getPathWithoutVersion, getPathWithoutLanguage } from '../../../lib/path-utils.js' import { getSearchFromRequest } from './get-search-request.js' @@ -40,7 +41,28 @@ export default async function contextualizeSearch(req, res, next) { // In local dev, you get to see the error. In production, // you get a "Oops! Something went wrong" which involves a Failbot // send. - req.context.search.results = await getSearchResults(search) + try { + req.context.search.results = await getSearchResults(search) + } catch (error) { + // If the error coming from the Elasticsearch client is any sort + // of 4xx error, it will be bubbled up to the next middleware + // which might think something else is wrong with the *client's* + // request from the outside. But in reality it's not their fault. + // It's our fault in the backend side. So we throw a new error + // so that this failure to seach ultimately bubbles up to a + // proper 500 error (including Failbot reporting). + // In particular, this helps platform developers working on the + // Elasticsearch searching code. + if (error instanceof errors.ElasticsearchClientError) { + console.error('Error calling getSearchResults(%s):', search, error) + if (error.meta?.body) { + console.error(`Meta:`, error.meta.body) + } + throw new Error(error.message) + } else { + throw error + } + } } } diff --git a/src/search/scripts/index-elasticsearch.js b/src/search/scripts/index-elasticsearch.js index 0384e39055..9c5d46b7e2 100755 --- a/src/search/scripts/index-elasticsearch.js +++ b/src/search/scripts/index-elasticsearch.js @@ -11,7 +11,7 @@ import fs from 'fs/promises' import path from 'path' import { Client, errors } from '@elastic/elasticsearch' -import { program, Option } from 'commander' +import { program, Option, InvalidArgumentError } from 'commander' import chalk from 'chalk' import dotenv from 'dotenv' @@ -61,6 +61,17 @@ program ) .option('-u, --elasticsearch-url ', 'If different from $ELASTICSEARCH_URL') .option('-p, --index-prefix ', 'Index string to put before index name') + .option( + '-s, --stagger-seconds ', + 'Number of seconds to sleep between each bulk operation', + (value) => { + const parsed = parseInt(value, 10) + if (isNaN(parsed)) { + throw new InvalidArgumentError('Not a number.') + } + return parsed + } + ) .argument('', 'where the indexable files are') .parse(process.argv) @@ -125,7 +136,9 @@ async function main(opts, args) { if (error instanceof errors.ElasticsearchClientError) { // All ElasticsearchClientError error subclasses have a `name` and // `message` but only some have a `meta`. - if (error.meta) console.error(error.meta) + if (error.meta) { + console.error(`Error meta: ${error.meta}`) + } throw new Error(error.message) } // If any other error happens that isn't from the elasticsearch SDK, @@ -133,10 +146,13 @@ async function main(opts, args) { throw error } } + +const sleep = (ms) => new Promise((resolve) => setTimeout(resolve, ms)) + async function indexAll(node, sourceDirectory, opts) { const client = new Client({ node }) - const { language, verbose, notLanguage, indexPrefix } = opts + const { language, verbose, notLanguage, indexPrefix, staggerSeconds } = opts let version if ('version' in opts) { @@ -190,6 +206,10 @@ async function indexAll(node, sourceDirectory, opts) { console.log(`To view index: ${safeUrlDisplay(node + `/${indexName}`)}`) console.log(`To search index: ${safeUrlDisplay(node + `/${indexName}/_search`)}`) } + if (staggerSeconds) { + console.log(`Sleeping for ${staggerSeconds} seconds...`) + await sleep(1000 * staggerSeconds) + } } } } @@ -345,7 +365,17 @@ async function indexVersion( `version:${version}`, `language:${language}`, ]) - const bulkResponse = await timed({ refresh: true, body: operations }) + const bulkOptions = { + // Default is 'false'. + // It means that the index is NOT refreshed as documents are inserted. + // Which makes sense in our case because we do not intend to search on + // this index until after we've pointed the alias to this new index. + refresh: false, + // Default is '1m' but we have no reason *not* to be patient. It's run + // by a bot on a schedeule (GitHub Actions). + timeout: '5m', + } + const bulkResponse = await timed({ body: operations, ...bulkOptions }) if (bulkResponse.errors) { // Some day, when we're more confident how and why this might happen @@ -353,7 +383,7 @@ async function indexVersion( // For now, if it fails, it's "OK". It means we won't be proceeding, // an error is thrown in Actions and we don't have to worry about // an incompletion index. - console.error(bulkResponse.errors) + console.error(`Bulk response errors: ${bulkResponse.errors}`) throw new Error('Bulk errors happened.') }