Reject standalone keys with mismatched IDs - #980
Conversation
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
dahlia
left a comment
dahlia
left a comment
There was a problem hiding this comment.
Before I continue reviewing the implementation, I need a few points clarified and corrected.
The PR description identifies the model as “Codex (GPT-5),” and the commit uses Assisted-by: Codex:gpt-5. GPT-5 is a real model identifier, but it was released nearly a year ago, and the current model family is GPT-5.6. Please check the exact model identifier shown in the Codex session or configuration. If gpt-5 is accurate, please confirm that. If it is not, update the PR description and amend the commit so that both identify the model that was actually used. Please do not replace it with the latest model merely because it is current.
The commit also records both its author and committer as junseok <junseok@junseoks-MacBook-Air.local>, which GitHub cannot associate with your account. Please configure your preferred name and a GitHub-verified email address, or your GitHub-provided noreply address, then amend the commit and force-push it.
Fedify's AI_POLICY.md requires an AI-assisted pull request to be fully verified through human use. The PR description says that you reviewed the change and ran the Deno, Node.js, and Bun checks locally. Before proceeding, I need to confirm both your understanding of the patch and what you personally verified.
Please answer these questions in your own words, without using Codex or any other AI tool (영어가 불편하시면 한국어로 답변하셔도 됩니다).
- Why does accepting a standalone key with a mismatched
idnot allow that key to impersonate another actor? - Why does the patch continue accepting a standalone key without an
id? - Why is the actor branch’s fragmentless single-key tolerance unaffected by this change?
- Why should a rejected mismatched key be negatively cached under the requested URL?
- How did you verify that the regression test fails without the patch?
- Did you personally run and review the results of each listed Deno, Node.js, and Bun check, or were those checks run autonomously by Codex?
Once these points have been addressed, I can continue reviewing the implementation.
Keep fetched key identities aligned with their requested URLs and cache
entries. Add regression coverage for both CryptographicKey and Multikey
rejection and negative caching while preserving
actor lookup behavior.
Fixes fedify-dev#963
Assisted-by: Codex:gpt-5.6-sol
262a160 to
4e7c9a8
Compare
처음에는 key 조회와 actor 소유권 확인이 서로 별개라고 봤습니다. 그런데 doesActorOwnKey()도 key의 ownerId나 id를 사용하
이번 변경에서는 id가 있고 그 값이 요청 URL과 다를 때만 거부합니다. id가 없는 key까지 막으면 기존 동작과의 호환성이 깨
이 경우는 actor 문서 안에서 key를 찾을 때 적용되는 기존 동작입니다. 이번 검사는 standalone key를 직접 가져오는 분기에
캐시는 실제로 요청한 URL을 기준으로 동작합니다. 해당 URL에서 유효한 key를 가져오지 못한 것이므로, 같은 문서를 반복해서
테스트는 그대로 두고 packages/fedify/src/sig/key.ts의 구현 조건만 패치 전 상태로 되돌려 실행했습니다. 그 결과 key:
focused Deno 테스트, 패치 제거·복원 검증, Deno 전체 7개 테스트, check-each 
|
2 participants
Background
fetchKey()accepts either an actor document containing keys or a standaloneCryptographicKey/Multikeydocument.The actor branch already checks candidate key IDs against the requested
keyId. The standalone branch previously accepted any object of the requested key class without checking itsid. As a result, a document fetched from one URL could declare a different ID and still be returned and cached under the requested URL.Although this does not let the key impersonate another actor—the owner/controller checks remain responsible for binding a key to an actor—it leaves the fetched key identity inconsistent with its lookup and cache key.
Changes
id, preserving the existing compatibility behavior.idonly when its URL exactly matches the requestedkeyId.iddiffers from the requested URL.@fedify/fedify.Regression coverage
The regression test supplies standalone key documents whose IDs differ from their requested URLs and verifies that:
CryptographicKeyandMultikeydocuments are rejected;{ key: null, cached: false };cached: true.I also confirmed that the new regression test fails against the previous standalone-key behavior and passes with this change.
Existing cache entries
This change validates newly fetched standalone key documents. It does not retroactively validate or evict mismatched key objects that may already exist in a persistent
KeyCachefrom before the upgrade.I kept existing cache-entry handling out of scope because #963 specifically concerns resolving a fetched standalone document, and cache storage and retention are provided by the application. I am happy to add validation or stale-entry handling for cached keys in this PR if the maintainers prefer that behavior.
Testing
The following checks passed locally:
mise exec -- deno test --check --doc --allow-all --unstable-kv --trace-leaks packages/fedify/src/sig/key.test.tsmise run check-each fedifymise run test-each fedify(Deno, Node.js, and Bun)mise run checkFixes #963.
AI usage
Implementation, regression-test drafting, code review, and local verification were assisted by Codex (GPT-5). I reviewed the resulting change and exercised it locally using the Deno, Node.js, and Bun workflows listed above.