dumbtv
dumbtv가 ADB로 Fire TV에서 광고·추적·업데이트 알림을 제거, 루트·앱 변경 없이, 무료 오픈소스
Drydock은 npm·PyPI·VS Code 아티팩트를 정확히 비교해 공급망 결과를 변경된 라인에 표시합니다
Your pull request got reviewed; the published tarball did not. Drydock diffs the exact npm, PyPI, or VS Code artifact and pins supply-chain findings to changed lines.
보안TypeScript · JavaScriptGitHub @JoviDeCroock온라인운영자 미확인
써 보셨어요? 한 번만 눌러 주세요. 로그인은 필요 없어요.
아직 감지된 업데이트가 없습니다. GitHub 릴리스가 나오면 여기에 보입니다.
개인 계정의 공개 저장소 소유자는 GitHub로 로그인해 운영자를 확인하고 소개를 직접 관리할 수 있습니다. 관리자 승인은 필요하지 않습니다.
로그인한 뒤 확인 파일을 만들어 이 저장소의 기본 브랜치에 30분 안에 커밋해 주세요. 다른 브랜치나 포크의 파일은 인정하지 않습니다. 파일을 올린 뒤 아래에서 확인하면 관리자 승인 없이 관리할 수 있습니다. 자격을 유지하려면 파일을 남겨 두세요.
로그인이 필요하면 로그인 화면으로 이동합니다. 로그인 후 이곳으로 돌아와 원하는 확인 버튼을 다시 눌러 주세요.
프로젝트 폴더에서 /nomorevibe verify를 실행하면 소유권을 확인하고 소개를 직접 관리할 수 있습니다.
1분 만에 확인하기Review the artifact before you publish it: diffs the built npm/PyPI package against the last published version and pins risk signals to the changed lines
저장소 README에서 가져옴
README 전체를 불러오는 중입니다. 아래는 저장된 발췌입니다.
Drydock is pre-publish package security for maintainers. It reviews the exact npm, PyPI, or VS Code artifact before publication, compares it with a tag-aware published baseline, runs deterministic supply-chain checks, optionally sends changed-file evidence to Cloudflare Workers AI, and saves a review report.README 전문 보기 ↗Drydock is pre-publish package security for maintainers. It reviews the exact npm, PyPI, or VS Code artifact before publication, compares it with a tag-aware published baseline, runs deterministic supply-chain checks, optionally sends changed-file evidence to Cloudflare Workers AI, and saves a review report.
It has two release modes with different authority. With Workflow Gate — enforced, a GitHub deployment-protection rule holds the configured protected publish job until you approve or reject it in Drydock. Stage Watchtower — advisory reviews and records npm staged artifacts, while npm maintainers independently approve or reject them and can still publish manually. Drydock never publishes and never collects npm approval codes.
Drydock runs as a hosted service at drydock.org; this repository is its source, and it can be self-hosted on your own Cloudflare account. To add it to a release, jump to Add Drydock to your release.
"github>JoviDeCroock/drydock//renovate/diff-links" after your base presets. Every linkable npm and PyPI update gains a Drydock column.The dependency-PR integrations add plain links, so Drydock is contacted only when a reviewer chooses to open a diff. See the integration contract for version-pair guards and security details.
Aikido Security sponsors Drydock's development. Sponsorship funds the work; it does not influence detection rules, findings, or risk scoring.
If you publish from GitHub Actions, use a workflow gate. It is the path for npm, PyPI, and VS Code
alike, and it is what the example repositories below use. npm stage publish is a shortcut for npm
maintainers who already publish that way from a terminal — if you don't, skip it. Both paths produce
the same review report, but they differ in authority: GitHub holds the gate's protected job for your
decision, while the watchtower only records advice about npm's stage.
CI builds the release and uploads it. A GitHub Environment pauses the publish job until you accept the review in Drydock, then the same job publishes the exact reviewed bytes.
GitHub enforces the hold, through the protection rule on that environment, and only for jobs that target it. Repository admins can remove the rule, and GitHub lets administrators bypass it unless you uncheck that option on the environment. For npm, npm's trusted-publisher and token settings can narrow automated publishing to that path, but npm still permits an account holder to publish interactively with password, 2FA, and an OTP.
Sign in at drydock.org and create the organization that owns the release.
In Organization settings → GitHub App, install the Drydock GitHub App on the account that hosts
the repository.
In the repository's Settings → Environments, create an environment (for example production)
and enable Drydock as a custom deployment protection rule.
Back in Drydock settings, map that repository and environment to your organization.
Split your release workflow into a build job that uploads the artifacts and a publish job pinned to the protected environment:
jobs:
pack:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm ci
- run: npm pack --pack-destination dist
- run: cd dist && sha256sum *.tgz > SHA256SUMS
- uses: actions/upload-artifact@v4
with:
name: npm-release-candidates
path: dist/
publish:
needs: pack
environment: production # GitHub holds this job for Drydock's decision
permissions: { id-token: write, contents: read }
steps:
- uses: actions/download-artifact@v4
with: { name: npm-release-candidates, path: dist }
- run: cd dist && sha256sum --check --strict SHA256SUMS
- run: npm publish dist/*.tgz --access public --provenance
Push a release. GitHub pauses the publish job, Drydock reviews the uploaded artifacts, and accepting the review tells GitHub to let the job continue. Rejecting it tells GitHub to keep that configured protected job blocked.
There is no Drydock manifest to maintain: package name, version, and ecosystem are read from metadata
inside the uploaded .tgz, .whl, .tar.gz, or .vsix. A monorepo upload becomes one report per
package, and the job continues only once every package is accepted. The publish job must publish the
bytes it downloaded — rebuilding after approval breaks the review boundary. The SHA256SUMS
record/check pair catches that drift, in a job your repository controls.
Full workflows for each ecosystem: PyPI CI example,
npm monorepo CI example, and
docs/workflow-gates.md.
npm holds a private staged tarball; Drydock reviews it and you finish the publish in npm with your own 2FA.
Drydock's decision is a review record, not an npm control: npm maintainers independently approve or reject the stage, and manual publication remains possible.
Packages and scopes: Read-only and Organizations: No access covering the scopes you publish.Organization settings → npm access.npm stage publish from the package directory. Drydock discovers the stage, scans it, and
shows the report.npm stage approve / npm stage reject command Drydock shows you.The longer walkthrough of both paths — what the report contains, how the credential boundary works, and per-ecosystem workflow examples — lives at drydock.org/docs.
drydock.org/docs is the guide for maintainers setting Drydock up. The
files below are the engineering and operator reference for working on Drydock or self-hosting it;
start with docs/README.md to pick the smallest relevant one. Common entry points:
docs/self-hosting.md — local setup, Cloudflare resources, deployment, GitHub App, and Slack setup.docs/architecture.md — runtime components, trust boundaries, adapters, storage, and API shape.docs/security-model.md — non-negotiable security posture.docs/workflow-gates.md — GitHub Environment gate contract for PyPI, npm, and VS Code workflow-gated releases.docs/release-safety.md, docs/security-detection-corpus.md, docs/detection-eval.md, and docs/e2e-test-environment.md — verification and detection quality.server/ Hono Worker, scan pipeline, adapters, persistence, webhooks
src/ Preact UI and typed API models
drizzle/ D1 migrations
docs/ Architecture, security, workflow, setup, and test references
test/ Vitest, Worker-runtime, security corpus, and fake-registry e2e
Requirements: Node 22.14.0+ and pnpm 11.1.1 (pinned in package.json).
pnpm install
cp .dev.vars.example .dev.vars
pnpm run dev
The dev server runs the Worker and UI through Vite at http://localhost:5173. Edit .dev.vars with local Cloudflare, Better Auth, npm, GitHub App, Slack, and optional Workers AI/Flagship values as described in docs/self-hosting.md.
Useful commands:
pnpm run lint
pnpm run format:check
pnpm run typecheck
pnpm run test
pnpm run test:e2e
pnpm run verify
For deterministic browser testing without real staged publishes, use the local fake-registry harness in docs/e2e-test-environment.md. For an agent-readable product walkthrough, use docs/agent-tour.md.
The checked-in wrangler.jsonc describes the maintainers' deployment. Self-hosters copy
docs/examples/wrangler.self-host.jsonc to the gitignored wrangler.self-host.jsonc, pass it explicitly to
Vite, migrations, and secret commands, then deploy the config generated by the Vite build. See
docs/self-hosting.md for the complete flow.
Core Cloudflare bindings are D1 (DB), the Dynamic Worker loader (LOADER), and Workers AI
(AI). Queue (SCAN_QUEUE), R2 (ARTIFACTS), KV (COMPARE_CACHE), Flagship (FLAGS),
Analytics Engine (PRODUCT_ANALYTICS), email (SEND_EMAIL), and static assets (ASSETS) support
the corresponding optional or deployed features.
Important secrets/vars:
BETTER_AUTH_SECRET, BETTER_AUTH_URLNPM_CONNECTIONS_ENCRYPTION_KEYGITHUB_APP_ID, GITHUB_APP_SLUG, GITHUB_APP_CLIENT_ID,
GITHUB_APP_CLIENT_SECRET, GITHUB_APP_PRIVATE_KEY, GITHUB_APP_WEBHOOK_SECRET, and optional
GITHUB_APP_STATE_SECRETSLACK_CLIENT_ID, SLACK_CLIENT_SECRETRun pnpm run cf-typegen after changing Cloudflare bindings.
The authenticated JSON API lives under /api/v1. The main resources are:
Consult route definitions under server/routes/ for exact request/response shapes; shared types are imported by the UI from server/.
ai-review killswitch, and cannot downgrade deterministic findings.See docs/security-model.md for the full contract.
Drydock is open-source software released under the Apache License 2.0.