Skip to content

chore: remove dead CRL-to-nginx sync (nginx never loads the file)#54

Open
omarsy wants to merge 1 commit into
mainfrom
chore/remove-dead-crl-nginx-sync
Open

chore: remove dead CRL-to-nginx sync (nginx never loads the file)#54
omarsy wants to merge 1 commit into
mainfrom
chore/remove-dead-crl-nginx-sync

Conversation

@omarsy

@omarsy omarsy commented Jun 10, 2026

Copy link
Copy Markdown
Member

What

Removes the greffer-side CRL distribution machinery:

  • app/workers/crl.py (the crl_sync_worker forever-loop) and its tests
  • the _fetch_and_store_crl step at the end of register_worker
  • the crl_sync_interval setting
  • doc/comment references to the third background worker

The greffer now runs two background workers (register / monitor) instead of three.

Why

The sync fetched GET /api/greffer/ca/crl/ from the manager and copied it into the nginx container as /root/revoked.crl. Nothing ever read that file:

  • nginx only consults a CRL via ssl_crl, which only takes effect with ssl_verify_client (mTLS). Neither directive has ever existed in this repo (verified across full git history; the CRL copy dates to the first commit).
  • The manager does not present a client certificate on its calls to the greffer, and inbound auth is the X-GREFFON-TOKEN bearer token, so enabling ssl_verify_client today would break the control plane, not harden it.

So the copy has been a silent no-op for the life of the project, surviving the Django to FastAPI port as preserved legacy behavior. Dead security machinery is worse than none: it reads as if revocation is enforced on the greffer when it is not.

What this does NOT change

  • The manager still issues CRLs, still revokes serials (cert re-issue, greffer delete), and still serves /api/greffer/ca/crl/. Issued certs embed that URL as their CRL distribution point. Nothing manager-side is touched.
  • No traffic path changes; the file removed was never loaded.

Context

Revocation enforcement (manager-side, where greffer server certs are actually validated) is documented as an explicitly accepted gap in the root repo security backlog, deferred to the M2 step-ca + Let's Encrypt migration which replaces the built-in CA. Companion root-repo docs PR follows.

Testing

  • Full suite: 297 passed.
  • Register-worker flow tests updated (one GET instead of two, 2 copies into nginx instead of 3).

🤖 Generated with Claude Code

The register worker and the crl_sync_worker fetched the manager's CRL
and copied it into the nginx container as /root/revoked.crl. No nginx
config ever referenced that file: ssl_crl only takes effect together
with ssl_verify_client, and this nginx has never done client-cert
verification (no ssl_verify_client anywhere in repo history). The copy
has been a no-op since the first commit, surviving the Django-to-FastAPI
port as preserved legacy behavior.

Dead security machinery is worse than none: it reads as if revocation
is enforced on the greffer when it is not. Remove the worker, the
register-step fetch, the crl_sync_interval setting, and their tests.
The manager keeps issuing CRLs and serving /api/greffer/ca/crl/
(certs embed it as their CRL distribution point); enforcement is
tracked in the platform security backlog and lands with the planned
step-ca migration, which replaces the built-in CA.

No behavior change for any traffic path. The greffer now runs two
background workers (register / monitor) instead of three.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Signed-off-by: Omar Sy <syomar.pro@gmail.com>
@chatgpt-codex-connector

Copy link
Copy Markdown

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, you can upgrade your account or add credits to your account and enable them for code reviews in your settings.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant