Backport of #27544

Original PR: #27544 — fix(coderd): reject workspace proxy hostname
prefixes
Merge commit: 8cc7f2b
Requested by: @geokat

Co-authored-by: George K <george@coder.com>
Co-authored-by: Bobby Ho <bobbidinho@gmail.com>

…kport #26488) (#27895)

Code-only backport of #26488 to `release/2.34`.

The dormancy notification's "will be automatically deleted in X"
sentence rendered the dormancy threshold (`time_til_dormant`) instead of
the auto-delete duration (`time_til_dormant_autodelete`). A 30-day
threshold rendered as "4 weeks" even when auto-delete was configured to
fire much sooner or later, so users were told the wrong deletion date.

Unlike #26488, this backport contains **no migration**. Adding migration
000527 to the 2.34 line would break the migration ordering for
deployments that later upgrade. Instead, the stored notification body is
left untouched and the existing `timeTilDormant` label is populated with
the correct value:

- When the template has auto-delete configured, the label carries the
countdown derived from the workspace's `deleting_at`, which
`UpdateWorkspaceDormantDeletingAt` already computes atomically from
`time_til_dormant_autodelete`.
- When auto-delete is disabled, `deleting_at` is unset and the sentence
cannot be omitted without a body change, so the label falls back to
generic wording: "...will be automatically deleted in line with your
template's auto-deletion policy if it remains inactive."

Upgrading to >= 2.35.1 later applies migration 000527 and the
`timeTilDelete` rename as usual; this patch is fully superseded at that
point.

<details>
<summary>Implementation notes</summary>

- `coderd/autobuild/lifecycle_executor.go`: propagate `wsNew.DeletingAt`
onto `ws` after the dormancy UPDATE and humanize it into the
`timeTilDormant` label.
- `coderd/workspaces.go` (`putWorkspaceDormant`): use
`newWorkspace.DeletingAt` for the label; the template fetch that fed the
wrong duration is removed.
- The label key intentionally stays `timeTilDormant` because the 2.34
notification body (migration 000311) references it; renaming would
require a data migration, which this backport deliberately avoids.
- No feature flag: the change is a pure correctness fix with no schema
or API surface.
- Tests adapted from #26488: `TestNotifications/DormancyAutoDelete`
(lifecycle executor) and
`TestWorkspaceNotifications/Dormant/InitiatorNotOwnerWithAutoDelete`
(API path), plus fallback-wording assertions in the existing
no-auto-delete tests. Both use a 35-day auto-delete so `humanize.Time`
deterministically renders "1 month from now".

</details>

---

*This PR was generated by Coder Agents on behalf of @ibetitsmike.*

…/2.34 (#27851)

Backport of #27481 to `release/2.34`.

## Problem
`canViewAnyOrganization` included `viewAnyMembers`, a permission every
user now has because of workspace sharing. This meant the Admin settings
dropdown (and the Organizations entry within it) showed up for every
user, not just admins.

## Fix
- Removed `permissions.viewAnyMembers` from `canViewAnyOrganization` in
`site/src/modules/permissions/index.ts`.
- Updated `site/e2e/tests/roles.spec.ts` to match, including a new
regression test for org members with no roles.

## Note on scope
Upstream #27481 also refactored `DeploymentDropdown`/`MobileMenu` into a
shared `AdminSettings.tsx` component driven by a single permissions
object. That refactor doesn't apply to `release/2.34`: this branch's
`DeploymentDropdown` and `MobileMenu` already gate the Admin settings
menu with equivalent per-permission checks, so only the actual
permission fix and its test coverage are backported here.

## Validation
- `pnpm exec biome check` on the two changed files: clean.
- Confirmed pre-existing `tsc` errors in this branch are unrelated
environment/dependency issues (reproduced identically on a clean
`release/2.34` checkout).

> 🤖 This PR was created with the help of Coder Agents, and needs a human
review. 🧑💻

---------

Co-authored-by: Jeremy Ruppel <jeremy.ruppel@gmail.com>

Backport of #26852

Original PR: #26852 — fix!: require org membership for user ACLs
Merge commit: 6b3341a
Requested by: @jdomeracki-coder

Clean cherry-pick, no conflicts.

---
_Opened by Coder Agents on behalf of @jdomeracki-coder._

Co-authored-by: Jon Ayers <jon@coder.com>

…27880)

Backport of #26904

Original PR: #26904 — fix: redact env var values in agent debug manifest
endpoint
Merge commit: b33ff2d
Requested by: @jdomeracki-coder

<details>
<summary>Conflict resolution notes</summary>

The cherry-pick conflicted in `agent/agent.go` because the new
`redactedManifestEnvValue` constant landed where `release/2.34` has the
`HandleHTTPDebugLogs` handler. Resolved by keeping both: the existing
handler
and the new constant. The manifest env-redaction block applied cleanly.
The
`./agent/...` package builds successfully.
</details>

---
_Opened by Coder Agents on behalf of @jdomeracki-coder._

Co-authored-by: Jon Ayers <jon@coder.com>

)

Backport of #26647

Original PR: #26647 — fix: prevent open redirect in proxy authentication
flow
Merge commit: 7e7a6b4
Requested by: @jdomeracki-coder

Clean cherry-pick, no conflicts.

---
_Opened by Coder Agents on behalf of @jdomeracki-coder._

Co-authored-by: Jon Ayers <jon@coder.com>

Backport of #26206

Original PR: #26206 — fix: only return group member count for workspace
acl
Merge commit: c7ddcce
Requested by: @jdomeracki-coder

Clean cherry-pick, no conflicts.

---
_Opened by Coder Agents on behalf of @jdomeracki-coder._

Co-authored-by: Jon Ayers <jon@coder.com>

…org (#26635) (#27883)

Backport of #26635

Original PR: #26635 — fix(coderd): scope provisioner module file
downloads to the daemon's org
Merge commit: 1961908
Requested by: @jdomeracki-coder

<details>
<summary>Conflict resolution notes</summary>

The cherry-pick conflicted in generated database files because the new
`HasTemplateVersionsUsingCachedModuleFileInOrg` query sits adjacent to
chatd
methods (`HydrateAgentChatsContext`, `IncrementChatGenerationAttempt`)
that do
not exist on `release/2.34`. Resolved by keeping only the new query and
its
generated bindings in `querier.go`, `dbmetrics/querymetrics.go`,
`dbmock/dbmock.go`, and `dbauthz/dbauthz.go`, then running `gofmt`.
Affected
packages (`./coderd/database/...`, `./coderd/provisionerdserver/...`)
build
successfully.
</details>

---
_Opened by Coder Agents on behalf of @jdomeracki-coder._

---------

Co-authored-by: Jon Ayers <jon@coder.com>

## What

Updates `google.golang.org/grpc` from `v1.81.1` → `v1.82.1` on
`release/2.34`.

## Why

`google.golang.org/grpc v1.81.1` is vulnerable to
**GHSA-hrxh-6v49-42gf** (GO-2026-6061) — the relevant exposure is the
HTTP/2 Rapid Reset-style DoS (the xDS RBAC auth-bypass half of the
advisory isn't used by Coder). Flagged by the IronBank scan of Coder
v2.35.3; `release/2.34` ships the same vulnerable version. Fixed in
**v1.82.1** (matches `v2.36.0`; `main` is on v1.83.0).

Companion to #27925 (the `release/2.35` backport).

## Change

- `go.mod`: `google.golang.org/grpc v1.81.1` → `v1.82.1` (direct), plus
the minimal indirect bumps grpc 1.82.1 requires on this branch:
  - `google.golang.org/genproto/googleapis/api` 20260319 → 20260414
- `GoogleCloudPlatform/opentelemetry-operations-go/detectors/gcp`
v1.31.0 → v1.32.0
  - `go.opentelemetry.io/contrib/detectors/gcp` v1.42.0 → v1.43.0
- `go.sum`: corresponding hashes

(These three indirect bumps weren't needed on the 2.35 backport because
that branch already had newer pins; on 2.34 they're pulled up by grpc
1.82.1's minimum-version requirements. All `// indirect`, all `go mod
verify`-clean.)

## Validation (local; `golangci-lint` at the CI-pinned v1.64.8)

- `go build ./...` — clean
- `go vet ./tailnet/... ./codersdk/...` — clean
- `golangci-lint run` (full repo) — 0 issues
- `go run ./scripts/intxcheck ./...` — clean
- `go mod tidy` stable; `go mod verify` OK

DB-backed suites (`make test-postgres`) run in CI.

Linear: ENT-144

## What

Updates `github.com/DataDog/dd-trace-go/v2` from `v2.0.0` → `v2.8.1`
(indirect) on `release/2.34`.

## Why

`github.com/DataDog/dd-trace-go/v2 v2.0.0` is vulnerable to
**CVE-2026-50274**. It is an indirect dependency pulled in by the direct
`gopkg.in/DataDog/dd-trace-go.v1 v1.74.0` shim that `coderd/tracing`
uses. Flagged by the IronBank scan of Coder v2.35.3; `release/2.34`
ships the same vulnerable version. Fixed in **v2.8.1** (matches
`v2.36.0`/`main`).

Companion to #27938 (the `release/2.35` backport).

## Change

`go get github.com/DataDog/dd-trace-go/v2@v2.8.1 && go mod tidy`. This
reproduces the DataDog dependency cluster as shipped on `v2.36.0`.
Notable transitive effects:

- **`go-libddwaf/v3` → `/v4`** (major-version module swap; v3 removed)
- `datadog-agent/pkg/*` 0.64.2 → 0.77.0 (plus new
`pkg/trace/{log,otel,stats,traceutil}`, `pkg/template`,
`pkg/opentelemetry-mapping-go/otlp/attributes`)
- `datadog-go/v5` 5.6.0→5.8.3, and bumps to `go-sqllexer`,
`sketches-go`, `go-tuf`, `go-runtime-metrics-internal`
-
`go.opentelemetry.io/collector/{component,pdata,pdata/pprofile,featuregate}`
1.27 → 1.51; dropped `collector/semconv`, `appsec-internal-go`,
`Masterminds/semver/v3`, `eapache/queue/v2`, `gogo/protobuf`

Every changed module matches `v2.36.0`'s `go.mod` with one exception:
`github.com/ebitengine/purego` resolves to `v0.10.0` here vs `v0.10.1`
on `v2.36.0`. It is a patch-level grandchild of `go-libddwaf/v4`; MVS
selects the minimal version this branch's graph requires (nothing on
`release/2.34` demands v0.10.1, whereas 2.36's grpc-bumped graph does).
Build and lint are clean with it.

`go.mod` +35/−30, `go.sum` +112/−100. All new/changed entries are `//
indirect`.

## Validation (local; `golangci-lint` at the CI-pinned v1.64.8)

- `go build ./...` — clean
- `go vet ./coderd/tracing/... ./codersdk/...` — clean
- `go test ./coderd/tracing/...` — ok
- `golangci-lint run` (full repo) — 0 issues
- `go run ./scripts/intxcheck ./...` — clean
- `go mod tidy` stable; `go mod verify` OK

DB-backed suites (`make test-postgres`) run in CI.

Linear: ENT-141

Co-authored-by: Marcin Tojek <tojek.m@gmail.com>