Conversation
fix(deps): resolve runtime security advisories
|
|
||
| const win = installWindow("#setup-token=setup-secret"); | ||
| (globalThis as any).fetch = vi.fn(async () => response({ success: true })); | ||
| const setup = renderLogin({ |
|
|
||
| const win = installWindow("#setup-token=setup-secret"); | ||
| (globalThis as any).fetch = vi.fn(async () => response({ success: true })); | ||
| const setup = renderLogin({ |
fix(security): keep regex validation linear
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: b842fb5b12
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| }): Promise<boolean> { | ||
| return prisma.$transaction(async (tx) => { | ||
| const updated = await tx.subscription.updateMany({ | ||
| where: { id: params.subscriptionId, updatedAt: params.expectedUpdatedAt }, |
There was a problem hiding this comment.
Avoid using updatedAt for refresh conflict detection
When a client fetches /api/subscriptions/:token/config.yaml while a refresh is in progress, generateSubscriptionYaml updates only lastAccessedAt, but Prisma's @updatedAt also bumps Subscription.updatedAt. This new predicate then treats that read/access-log write as a real subscription edit, so manual refresh returns SUBSCRIPTION_CHANGED and the cron path using the same updatedAt guard skips persisting fresh nodes. Use a revision/timestamp that is not touched by access logging, or update lastAccessedAt without changing the conflict field.
Useful? React with 👍 / 👎.
| read_env_file > "$candidate_env" | ||
| cp "$candidate_env" "$old_env" |
There was a problem hiding this comment.
Create update env copies with private permissions
During subboost update, this new rollback-staging path writes the full .env contents into $TMPDIR/subboost-manager.$$/candidate.env and then duplicates it as old.env using the caller's default umask; with the usual 022 umask and a default 0755 temp directory, other local users can read database/JWT/encryption/setup secrets while the update runs. Set a private umask or create/install these temp env copies with mode 600 before writing them.
Useful? React with 👍 / 👎.
Summary
Validation
No version bump, tag, GitHub Release, or Production deployment is included.