Finding
containers/kali/scripts/aptl-wrap-shell.sh is not used by anything at runtime. The kali node gets its wrapper from the TechVault pack, not from this file.
Measured on a running range:
| Copy |
sha256 |
Pack asset packs/techvault/assets/content/kali-wrap-shell.sh |
4c718dc0… |
Digest the SDL declares for content.kali-wrap-shell-script |
4c718dc0… (exact match) |
This repository's containers/kali/scripts/aptl-wrap-shell.sh |
7a0c63ba… (matches nothing) |
Deployed at /usr/local/bin/aptl-wrap-shell.sh |
5f3a1b72… (the pack asset, plus the boot-time fixup patch) |
The SDL places the file from the pack's own asset. This copy appears in no Dockerfile and in no content declaration. Its only remaining mentions are a comment in containers/kali-capture/writer.py pointing at it as the canonical valid_id() rule, and one path string in the legitimate-sources list in tests/test_content_realization_source_policy.py.
Why it is worth removing rather than leaving
The two copies have drifted, and in the direction that matters. This one still carries a run_unwrapped() fallback that hands out a shell when capture is unavailable; the pack's copy denies. A reader who opens the in-tree file to learn what kali does gets the wrong answer about a security-relevant behaviour, and the file is close enough to real that the mistake is easy.
Issue #591's ownership review recorded the pack placement as derived from this file, so removing it settles a question rather than just deleting something: whether APTL remains the authoring source of record for that adapter, or the pack owns it outright. The evidence above says the pack already does in practice.
Scope
- Remove the file, or keep it deliberately and record why the runtime does not use it.
- Repoint the
valid_id() provenance comment in containers/kali-capture/writer.py at whichever copy is canonical.
- Drop the path from the parametrized list in
tests/test_content_realization_source_policy.py.
- Reconcile
docs/reviews/962-lilrae-readiness/tracked-file-inventory.tsv.
Small and self-contained. Independent of #986, which is about the capability the deployed wrapper requires; this is only about the unused duplicate.
Found while making aptl lab start boot TechVault end to end (#879).
Finding
containers/kali/scripts/aptl-wrap-shell.shis not used by anything at runtime. The kali node gets its wrapper from the TechVault pack, not from this file.Measured on a running range:
packs/techvault/assets/content/kali-wrap-shell.sh4c718dc0…content.kali-wrap-shell-script4c718dc0…(exact match)containers/kali/scripts/aptl-wrap-shell.sh7a0c63ba…(matches nothing)/usr/local/bin/aptl-wrap-shell.sh5f3a1b72…(the pack asset, plus the boot-time fixup patch)The SDL places the file from the pack's own asset. This copy appears in no Dockerfile and in no content declaration. Its only remaining mentions are a comment in
containers/kali-capture/writer.pypointing at it as the canonicalvalid_id()rule, and one path string in the legitimate-sources list intests/test_content_realization_source_policy.py.Why it is worth removing rather than leaving
The two copies have drifted, and in the direction that matters. This one still carries a
run_unwrapped()fallback that hands out a shell when capture is unavailable; the pack's copy denies. A reader who opens the in-tree file to learn what kali does gets the wrong answer about a security-relevant behaviour, and the file is close enough to real that the mistake is easy.Issue #591's ownership review recorded the pack placement as derived from this file, so removing it settles a question rather than just deleting something: whether APTL remains the authoring source of record for that adapter, or the pack owns it outright. The evidence above says the pack already does in practice.
Scope
valid_id()provenance comment incontainers/kali-capture/writer.pyat whichever copy is canonical.tests/test_content_realization_source_policy.py.docs/reviews/962-lilrae-readiness/tracked-file-inventory.tsv.Small and self-contained. Independent of #986, which is about the capability the deployed wrapper requires; this is only about the unused duplicate.
Found while making
aptl lab startboot TechVault end to end (#879).