chore: Pin third-party GitHub Actions to full commit SHAs

[devin-ai-integration]

file:///home/ubuntu/pin-actions/worker_pr_body.md

Link to Devin session: https://app.devin.ai/sessions/add87be2227046f198fbac38a32e5358

[devin-ai-integration]

Original prompt from will.porter

'Pin all third-party Github Actions for Public SDKs' (SECENG-294)

User instruction: @devin can you look at the workos organization in github, and report back all of the public repositories that are not archived, and whether or not if they use any github workflows?

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment and CI monitoring

[devin-ai-integration]

Third-Party Action SHA Age Report

Action	Pinned Version	Full SHA	Commit Date	Age (days)	Status
actions/checkout	v2	ee0669bd1cc54295c223e0bb666b733df41de1c5	2023-03-24	1132	✅ OK
actions/checkout	v3	f43a0e5ff2bd294095638e18286ca9a3d1956744	2023-08-24	979	✅ OK
actions/setup-node	v3	3235b876344d2a9aa001b8d1453c930bba69e610	2025-04-17	377	✅ OK
docker/build-push-action	v2	ac9327eae2b366085ac7f6a2d02df8aa8ead720a	2022-03-14	1506	✅ OK
docker/login-action	v1	dd4fa0671be5250ee6f50aedf4cb05514abda2c7	2022-03-01	1519	✅ OK
docker/metadata-action	v3	b2391d37b4157fa4aa2e118d643f417910ff3242	2022-04-28	1462	✅ OK
docker/setup-buildx-action	v2	885d1462b80bc1c1c7f0b00334ad271f09369c55	2023-08-28	975	✅ OK
docker/setup-qemu-action	v2	2b82ce82d56a2a04d2637cd93a637ae1b359c0a7	2023-06-07	1057	✅ OK

[willporter-workos]

@devin-ai-integration, is there something we can do to resolve the failing db updated checks?

[devin-ai-integration]

@willporter-workos Yes! The database_updated check fails because the CI runner's pg_dump (newer version on Ubuntu 24.04) outputs \restrict/\unrestrict security directives that weren't being stripped by the scripts/dump_db sed pipeline. This causes a diff in __tests__/schema.sql even though the actual schema hasn't changed.

I've pushed a fix (5084f6e) that adds sed patterns to strip these lines from the pg_dump output, which should resolve the check.

[willporter-workos]

@devin-ai-integration is stripping these the correct solution, are we somehow bypassing a security control or something by stripping these values, or if this is a benign change, why?

[devin-ai-integration]

Good question — this is benign and safe to strip. Here's why:

What are \restrict/\unrestrict?
They're psql meta-commands that newer pg_dump versions (16.10+) started emitting in response to CVE-2024-0985. They protect against command injection during psql restore of dump files by wrapping the dump contents with a randomly-generated key that must match on both ends.

Why stripping is safe here:

1. __tests__/schema.sql is only used for schema drift detection (the CI diffs it against a fresh dump) — it's never fed to psql for a database restore
2. The key in \restrict <random_key> is regenerated every time pg_dump runs, so leaving them in would actually break the check — the diff would always show changes even when the real schema is identical
3. This is the same approach other projects have taken (e.g., GitLab had the same issue with their structure.sql)

In short: the security control protects psql restore operations, which doesn't apply to this file's usage. And the random key makes stripping necessary for the diff-based check to work at all.