fix(cli,server): fix trusted flags copy-paste bug and server nil pointer panic

[bclermont]

Summary

Two related bugs in repo update --trusted-* flags:

Bug 1 — CLI copy-paste error (cli/repo/repo_update.go)

--trusted-network and --trusted-volumes both set patch.Trusted.Security instead of their respective fields:

// before (broken)
if c.IsSet("trusted-network") {
    t := c.Bool("trusted-network")
    patch.Trusted.Security = &t  // wrong field
}
if c.IsSet("trusted-volumes") {
    t := c.Bool("trusted-volumes")
    patch.Trusted.Security = &t  // wrong field
}

This means the CLI always sends {Security: <value>, Network: nil, Volumes: nil} regardless of which flag was passed.

Bug 2 — Server nil pointer panic (server/api/repo.go)

PatchRepo unconditionally dereferences all three fields of in.Trusted before checking for nil:

// before (broken)
if (*in.Trusted.Network != repo.Trusted.Network || ...) && !user.Admin {

When the CLI sends a partial payload (only some fields set), this panics with nil pointer dereference.

Fix

• CLI: correct the field assignments for --trusted-network → .Network and --trusted-volumes → .Volumes
• Server: guard each dereference with a nil check — only flag a trust escalation attempt if the specific field is present in the patch and differs from the current value

How to reproduce

woodpecker-cli repo update --trusted-volumes owner/repo
# → server panics: runtime error: invalid memory address or nil pointer dereference
# at server/api/repo.go:237

Test plan

• repo update --trusted-volumes owner/repo no longer panics
• repo update --trusted-network owner/repo no longer panics
• repo update --trusted-security owner/repo still works
• repo update --trusted-volumes --trusted-network --trusted-security owner/repo sets all three correctly
• Non-admin attempting to escalate trust is still rejected with 403

🤖 Generated with Claude Code

[woodpecker-bot]

Surge PR preview deployment succeeded. View it at https://woodpecker-ci-woodpecker-pr-6501.surge.sh