Lovable sync 1785438562 - #52
Conversation
X-Lovable-Edit-ID: edt-ecdb1824-a252-4aa7-970c-ac6e54d10c25 Co-authored-by: criptogus <128640021+criptogus@users.noreply.github.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 97c515c1c5
ℹ️ 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".
| */ | ||
|
|
||
| export const PLATFORM_VERSION = "0.1.37" as const; | ||
| export const PLATFORM_VERSION = "0.1.34" as const; |
There was a problem hiding this comment.
Deploying this commit on its parent rolls the advertised release backward from 0.1.37 to 0.1.34 and removes versions 0.1.35–0.1.37 from the changelog. Because the footer and /api/public/version source this constant, users and integrations will observe a stale downgrade despite receiving a new user-facing route; retain the existing history and advance the version instead.
Useful? React with 👍 / 👎.
| const url = process.env.SUPABASE_URL; | ||
| const key = process.env.SUPABASE_PUBLISHABLE_KEY; | ||
| if (!url || !key) return []; | ||
|
|
||
| const supabase = createClient<Database>(url, key, { | ||
| auth: { storage: undefined, persistSession: false, autoRefreshToken: false }, |
There was a problem hiding this comment.
In the deployed schema, supabase/migrations/20260706140127_10a5d0b0-7709-4139-9d8b-608b402a2e2d.sql drops anonymous access and permits package_releases reads only to authenticated owners or admins. This client has only the publishable key and no user session, so RLS returns no rows even when signed releases exist and the new trust-center page always shows its empty state; use a public-safe view/RPC or a server-authorized query that explicitly filters to published packages.
Useful? React with 👍 / 👎.
| const hash = crypto.createHash('sha256').update(pkg).digest(); | ||
| const sig = Buffer.from(process.env.SIG_BASE64, 'base64'); | ||
| const pub = Buffer.from(process.env.PUB_BASE64, 'base64'); | ||
| console.log('valid:', nacl.sign.detached.verify(hash, sig, pub)); |
There was a problem hiding this comment.
When users copy this direct verifier into CI or a deployment gate, an invalid signature merely prints valid: false; node -e still exits with status 0. That contradicts the page's statement that tampering produces a non-zero exit and allows a modified package to pass any check based on process status, so explicitly exit non-zero when verification returns false.
Useful? React with 👍 / 👎.
| const pkg = fs.readFileSync('pkg.yaml'); | ||
| const hash = crypto.createHash('sha256').update(pkg).digest(); | ||
| const sig = Buffer.from(process.env.SIG_BASE64, 'base64'); | ||
| const pub = Buffer.from(process.env.PUB_BASE64, 'base64'); | ||
| console.log('valid:', nacl.sign.detached.verify(hash, sig, pub)); |
There was a problem hiding this comment.
For signatures produced by this repository, src/lib/trust/signing.ts signs Buffer.from(content_hash), i.e. the 64 ASCII hexadecimal bytes of the canonicalized package hash. This example instead verifies the 32 raw digest bytes of the YAML file, so even a legitimate release signature will report invalid; recompute the canonical content hash and verify its hexadecimal string bytes, matching verifyRelease.
Useful? React with 👍 / 👎.
criptogus
left a comment
criptogus
left a comment
There was a problem hiding this comment.
Análise: positiva / segura para merge (o GitHub não permite marcar "Approve" na própria PR, então fica registrado como comentário).
Sync do Lovable com escopo restrito a frontend/site: nova página /security (trust center), server function pública de release log e refinos visuais em componentes da home.
Pontos verificados:
getPublicReleaseLogusa apenasSUPABASE_PUBLISHABLE_KEY(chave pública), sem sessão persistida, leitura limitada a 20 linhas depackage_releasese assinatura truncada (signature_preview) — nenhum segredo ou dado sensível exposto.- Nenhuma mudança em lógica de trust scoring, assinatura de releases, banco ou políticas RLS — apenas exibição.
- Sem alterações em CI ou dependências de runtime relevantes.
Observação menor (não bloqueante): em security.functions.ts, row.signature.slice(...) lançaria erro se signature vier nula; um row.signature ?? "" deixaria o loader mais resiliente.
Generated by Claude Code
1 participant
What does this PR add?
Type
version)Checklist (for content PRs)
slugand the type's folderbun run validate:contentpasses locallyNotes for reviewers