build(deps): bump taskcluster from 38.0.6 to 39.0.0 in /tools

[dependabot]

⚠️ Dependabot is rebasing this PR ⚠️

If you make any changes to it yourself then they will take precedence over the rebase.

---

Bumps taskcluster from 38.0.6 to 39.0.0.

Release notes

Sourced from taskcluster's releases.

v39.0.0

GENERAL

▶ [patch] #3901 Fixed a bug where signing public S3 artifacts would result in Forbidden errors on the task and task group views.

▶ [patch] #3867 Taskcluster-Github should now function correctly in a deployment with no scopes in the anonymous role.

If you have a locked-down deployment without allowing public artifacts fetching in your anonymous role, you must add queue:get-artifact:public/github/customCheckRunText.md and queue:get-artifact:public/github/customCheckRunAnnotations.json to the scopes of your task to avoid an error comment being added to your commits. Note that this will change if you choose a custom artifact name (see custom artifact docs for more)

DEPLOYERS

▶ [MAJOR] #3713 This version introduces a new, in-development object service. It is currently configured for a default replica count of 0, meaning that it will not run, and this is the recommended configuration. However, it will nonetheless require configuration of a Taskcluster access token and a new database user (<prefix>_object).

WORKER-DEPLOYERS

▶ [minor] #3669 The Azure worker-manager takes additional steps to verify the identity proof during worker registration. The identify proof is the output of the attested data API, which includes details about the worker and is signed by the Azure platform.

Previously, the worker-manager checked that the message signer was issued by one of four published intermediate certificates issued by a single root CA. Azure is planning to expand to five more root CAs (see Azure TLS certificate changes for details). The worker-manager now downloads an unknown intermediate certificate, verifies that it was issued by a known root CAs, and adds it to the list of trusted certificates. The 4 legacy intermediate certificates, still in use in Azure as of November 2020, are pre-loaded as trusted certificates.

The worker manager now verifies that the message signer is for metadata.azure.com or a subdomain. This is true for any workers in the Azure public cloud, but not the sovereign clouds like azure.us.

One of the new root CAs uses Elliptic Curve Cryptography (ECC) instead of RSA. The Azure worker-manager doesn't support this or other ECC certificates. This is tracked in [issue #3923](taskcluster/taskcluster#3923).

There is no performance change expected until Azure ships the TLS certificate changes, planned by February 15, 2021. When new intermediate certificates are used, there will be up to a 5 second delay on worker registration while the new certificate is downloaded for the first time. A new manager log entry, registration-new-intermediate-certificate, is emitted after a successful download and verification, and includes the certificate details.

... (truncated)

Changelog

Sourced from taskcluster's changelog.

v39.0.0

GENERAL

▶ [patch] #3901 Fixed a bug where signing public S3 artifacts would result in Forbidden errors on the task and task group views.

▶ [patch] #3867 Taskcluster-Github should now function correctly in a deployment with no scopes in the anonymous role.

If you have a locked-down deployment without allowing public artifacts fetching in your anonymous role, you must add queue:get-artifact:public/github/customCheckRunText.md and queue:get-artifact:public/github/customCheckRunAnnotations.json to the scopes of your task to avoid an error comment being added to your commits. Note that this will change if you choose a custom artifact name (see custom artifact docs for more)

DEPLOYERS

▶ [MAJOR] #3713 This version introduces a new, in-development object service. It is currently configured for a default replica count of 0, meaning that it will not run, and this is the recommended configuration. However, it will nonetheless require configuration of a new database user (<prefix>_object).

WORKER-DEPLOYERS

▶ [minor] #3669 The Azure worker-manager takes additional steps to verify the identity proof during worker registration. The identify proof is the output of the attested data API, which includes details about the worker and is signed by the Azure platform.

Previously, the worker-manager checked that the message signer was issued by one of four published intermediate certificates issued by a single root CA. Azure is planning to expand to five more root CAs (see Azure TLS certificate changes for details). The worker-manager now downloads an unknown intermediate certificate, verifies that it was issued by a known root CAs, and adds it to the list of trusted certificates. The 4 legacy intermediate certificates, still in use in Azure as of November 2020, are pre-loaded as trusted certificates.

The worker manager now verifies that the message signer is for metadata.azure.com or a subdomain. This is true for any workers in the Azure public cloud, but not the sovereign clouds like azure.us.

One of the new root CAs uses Elliptic Curve Cryptography (ECC) instead of RSA. The Azure worker-manager doesn't support this or other ECC certificates. This is tracked in [issue #3923](taskcluster/taskcluster#3923).

There is no performance change expected until Azure ships the TLS certificate changes, planned by February 15, 2021. When new intermediate certificates are used, there will be up to a 5 second delay on worker registration while the new certificate is downloaded for the first time. A new manager log entry, registration-new-intermediate-certificate, is emitted after a successful

... (truncated)

Commits

• f8acdaf v39.0.0
• 42c036e Merge pull request #4010 from djmitche/issue3986
• cb6852c Merge pull request #4013 from renovate-bot/renovate/babel-monorepo
• f7d8398 Merge pull request #3990 from djmitche/hostname-regex-in-tests
• 9450329 yarn generate
• 455b454 Merge pull request #4002 from renovate-bot/renovate/websocket-stream-5.x
• 5245ba2 Update babel monorepo
• 86d2e10 Merge pull request #4009 from renovate-bot/renovate/node-12.x
• e5de058 yarn generate
• 5f2e411 Make object.backends,backendMap configs optional
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)