DataTalksClub / DataTalksClub/website

A read-only prod script should not offer a production write opt-in

Open
#330 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

data-migration enhancement needs grooming operations P2 security testing
Dominant language
Python
Stars
0
Forks
0
PR merge metrics
No merged PRs in 30d

Description

scripts/prod/target's add_target_arguments is shared by every scripts/prod
entry point, so a read-only tool inherits the writer's operator surface.
Found during #323's acceptance, on scripts/prod/sync_content_verify.py, which
has no write path of any kind — proven during verification by running it on a
read-only filesystem:

sync_content_verify.py: error: writing to the website-production database
requires --allow-production-write website-production

The tool is telling an operator that reading requires a production write
opt-in.

There is no data risk here — the flag guards a write path this script does not
have. The cost is to the guard itself. scripts/prod/target's own docstring
rests on a two-flag property: --deployment-target NAME selects a deployed
database and --allow-production-write NAME must name the same one, so that a
production write is always two deliberate acts. Routinising the second flag on
tools where it is meaningless trains operators to add it reflexively, which is
exactly the habit the two-flag design exists to prevent — and the next tool that
does write is the one that pays.

Scope: let a read-only entry point declare itself so, and not be offered a
production write opt-in. sync_content_verify.py is the first such tool; the
drift check family (#323) and any future reporter will be more.

Grooming should settle whether "read-only" is declared per module (alongside the
existing SYNC_MODEL / BOOTSTRAPS_EMPTY_DATABASE conventions that
scripts/tests/test_prod_conventions.py already checks) or inferred, and
whether the declaration should be enforced — a module claiming read-only while
importing a writer is the failure worth catching.

This touches every scripts/prod entry point, so it was explicitly kept out of
#323.

Refs #310

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Read scripts/prod/target and sync_content_verify.py first, then inspect the conventions checked by scripts/tests/test_prod_conventions.py. Determine how a read-only entry point should declare itself and whether that declaration is enforced. Done means read-only tools no longer offer the production-write opt-in while the shared scripts/prod entry points retain their safeguards.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
devops, tooling
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.