docs: inventory cryptographic functionality for export classification - #3318
Closed
Astro-Han wants to merge 10 commits into
Closed
docs: inventory cryptographic functionality for export classification#3318Astro-Han wants to merge 10 commits into
Astro-Han wants to merge 10 commits into
Conversation
10 tasks
The first exit criterion of the export-classification gate needs an inventory a reviewer can check line by line, not a summary. Record every cryptographic path in the tracked source with a file path or package name, and separate the paths that decide the classification from the ones that only look like they might. The classification turns on three AES-256-GCM sites: the Managed Secret envelope store, the QQ Bot bind-task secret decryption, and its test fixture. Everything else is exempt or delegated. The 201 SHA-256/512 digest sites fall under the ASF exemption for one-way algorithms, TLS and SSH delegate to Node's OpenSSL and the user's own OpenSSH binary respectively, and the primary credential store holds plaintext behind 0600 rather than encrypting at rest. Maka implements no cryptographic algorithm of its own; it composes third-party primitives, which narrows what the notification lists as manufactured crypto without changing that Maka is classified. Recommend a Section 742.15(b) notification under ECCN 5D002 and record what still needs a human decision: the manufacturer list, the source artifact boundary, and the podling filing mechanics. Also correct three assumptions carried in the issue thread, including a cited ASF URL that now 404s. Refs #3273 Generated-by: Claude Code (claude-opus-5)
Adversarial review found the inventory asserted a legal conclusion it had no standing to reach, and missed paths inside the very categories the exit criterion names. The conclusion was wrong in kind, not degree. It stated that the EAR requires a notification. Current 15 CFR 742.15(b)(2) limits that requirement to source code providing or performing "non-standard cryptography" per 772.1, and every algorithm here is a published standard. ASF's page still directs projects to notify, but dates itself May 24, 2019 and asks projects to follow it "until the Apache VP Legal Affairs approves an updated version." Record both, name the conflict, and leave it to VP Legal rather than settling it here. Scanning only TypeScript-family globs hid the largest TLS finding in the tree: the eval egress proxy generates an RSA-2048 CA and runs mitmdump as a full man-in-the-middle. Scan every tracked file type instead. The same narrowness hid SHA-1, reached through a helper that takes the algorithm as a parameter, which falsified a stated absence. Cover the credential path that production actually uses. The document described only the Runtime Host client store while Connection API and OAuth material, request headers, search keys, and proxy passwords live in a separate plaintext vault. Both are unencrypted, so the finding holds, but the coverage claim did not. Separate two questions the document had conflated: whether a path is controlled, and who manufactured the primitive. Delegating to OpenSSL or OpenSSH decides the second, not the first, so TLS and SSH no longer sit outside the trigger set by virtue of delegation alone. Also add the second lockfile and its crypto dependencies, drop a corrections section that attributed assumptions to an issue thread with no comments, and move progress tracking to #3273 per docs/README. Refs #3273 Generated-by: Claude Code (claude-opus-5)
The dev-only dependency list named pkijs, @peculiar/webcrypto, asn1js, and @noble/hashes but omitted aws4, which reaches HMAC request signing through electron-publish on the same packaging path. An inclusion rule that skips one item of the same kind is not a rule a reviewer can check. Refs #3273 Generated-by: Claude Code (claude-opus-5)
…pendencies A second round of adversarial review found the previous revision had replaced one overreach with another, and that both rounds had missed shipped dependencies a name-based scan does not surface. The previous revision corrected "the EAR requires notification" but then asserted as established fact that Maka is entirely standard cryptography. That does not follow. 772.1 reaches proprietary or unpublished cryptographic protocols, not only algorithms, so an enumeration of algorithm names cannot settle it. Retract the claim and name the three constructions that need a protocol-level determination. Two shipped dependencies were absent. dugite is a direct root dependency that bundles a complete 141 MB Git distribution into the desktop app, carrying the .NET cryptography stack, OpenSSL native libraries, and TLS transport; it is the largest third-party crypto payload in the product. @jackwener/opencli is a direct desktop dependency carrying vendor-private API signing with hardcoded key material against undocumented endpoints, which is the clearest input to the 772.1 question. Neither is JavaScript crypto a package-name scan would find, which is why the coverage limit now says so instead of claiming completeness. Move the snapshot to current main. The prior baseline predated #3278 by 28 minutes, which had already defined the source artifact: git archive with only three export-ignore entries, so experiments/ and packages/eval/harbor/ are inside it, and the CA-generation path with them. That resolves one open question and adds GPG detached signing as a new surface. Also record the third lockfile, qualify the SSH finding for the Windows MinGit payload, correct a PowerShell call mislabelled as DPAPI-backed, and split manufacturer into which item an artifact contains versus who built it. Refs #3273 Generated-by: Claude Code (claude-opus-5)
Astro-Han
force-pushed
the
docs/3273-crypto-export-inventory
branch
from
August 20, 2026 12:41
593cce5 to
3353a2d
Compare
Mentor guidance is that no BIS notification and no exports-matrix entry are required, because Maka develops no cryptographic algorithm of its own and uses existing third-party dependencies. Replace the open-questions section with that determination and the facts supporting it. Add the observed practice, which independently points the same way. OpenDAL, Doris, Iceberg, Pekko, Kvrocks, Celeborn, StreamPark, and Answer are all absent from the exports matrix, and OpenDAL carries no crypto notice at all. The projects that do appear either implement cryptography or bundle a cryptographic library, which is why Impala's entry names the OpenSSL Project alongside the ASF. Podling status is not a barrier in either direction. Keep one caveat visible rather than closing over it. dugite bundles a complete Git distribution, OpenSSL native libraries included, into the desktop convenience binary, and that is the pattern behind Impala's manufacturer entry. It is expected to be removed independently because Git is GPLv2 and ASF policy bars Category X components from convenience binaries. If it survives to the first release, the bundling question should be put to the mentors explicitly instead of being assumed covered. The determination was given privately, so exit criteria 4 and 5 still need it recorded publicly by an appropriate party. The issue allows closing on an authoritative determination that no entry is needed. Refs #3273 Generated-by: Claude Code (claude-opus-5)
The determination is settled, so the section recording it should read as a conclusion rather than as a list of things to reopen. Remove the paragraph asking a future reader to re-raise the bundled-Git question with the mentors, and the open item tracking its removal, which is a licensing matter rather than an export one. The inventory itself is unchanged. dugite and its cryptographic payload stay in the dependency table, where they are a fact about the tree rather than a prompt to act. Refs #3273 Generated-by: Claude Code (claude-opus-5)
The determination section described itself as material awaiting a public record elsewhere, which left the exit criterion it satisfies with nothing pointing at it. #3273 allows closing on a determination that no entry is needed, and a reviewed and merged document in the repository is that determination. Say so, rather than deferring to a record that was never going to be written separately. Refs #3273 Generated-by: Claude Code (claude-opus-5)
…d read backwards The precedent paragraph was built from a single unverified summary of the exports matrix, and checking the page directly refutes it. Apache Impala's entry is "2.7.0 and later / 5D002 / ASF" annotated "Designed for use with OpenSSL" — the manufacturer is the ASF alone, and the reason is designed use, not bundling. Seventeen other products do name The OpenSSL Project; Impala is not one of them. The generalization drawn from that quote was worse than the quote. The most common annotation on the page is "designed for use with encryption library", 59 entries across its two capitalisations, so merely using a cryptographic library was historically enough to file. That is Maka's own posture, which means the historical entries cut against the paragraph rather than for it. Record both patterns instead. Recent projects are absent, historical entries are permissive about what counts, and the gap between them reads as a process that has fallen out of use rather than as a boundary Maka sits outside of. State plainly that this context does not establish the determination. Also stop the document asserting its own authority. Merging cannot turn a contributor's account of private guidance into an authoritative record; the approving review is what places it on the public record, and the authority is the mentors'. Correct dugite's placement to devDependencies, since it is the packaging step rather than the dependency type that puts it in the product, and mark the opencli signing list as illustrative after finding two more. Refs #3273 Generated-by: Claude Code (claude-opus-5)
openai 6.49.0 reaches the production closure through @openai/agents-core and verifies webhook signatures with HMAC-SHA256 via WebCrypto. uuid 14.0.1 carries MD5 and SHA-1 for name-based identifiers, which are digests and exempt. Neither changes the determination; both belong in a dependency inventory that #3273 asks to cover HMAC explicitly. This is the third revision in a row to add a shipped dependency that package-name scanning does not surface, so the coverage limit now says three rather than two. The pattern is the point: the closed set has to come from a frozen install and the packaged output, not from this table. Also reduce the footer to the disclosure itself. The list of what each review round caught is process history that belongs in the pull request; the one part that carries forward, why the coverage limit is not theoretical, already lives in that section. Refs #3273 Generated-by: Claude Code (claude-opus-5)
…rypto The determination's basis is about authorship, while the document elsewhere quotes ASF treating bindings as in scope and records that the desktop binary bundles OpenSSL. A reader of the determination section alone saw only the first of those. Add the artifact-content fact so the two sections agree. Refs #3273 Generated-by: Claude Code (claude-opus-5)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Advances the first exit criterion of #3273 (G6: export classification): "Inventory cryptographic functionality and dependencies in the source artifact, including encryption, HMAC, TLS, SSH, and credential storage paths." No ASF notification is submitted and no email is sent.
Adds
docs/crypto-export-inventory.md: every cryptographic path in the tracked source at52c0e3275, each row citing a file path or package name.Outcome: mentor guidance is that no BIS notification and no exports-matrix entry are required for Maka, on the basis that it develops no cryptographic algorithm of its own and uses existing third-party dependencies. §K records that determination and the evidence behind it.
The inventory independently points the same way. Maka's own source does perform AES-256-GCM encryption and generate an RSA-2048 CA for TLS interception in the eval harness — both past the 5D002 thresholds — but implements no cryptographic primitive: every algorithm resolves to OpenSSL, BoringSSL, mitmproxy, Windows CNG, a public Rust crate, or the user's OpenSSH. Observed ASF practice matches: OpenDAL, Doris, Iceberg, Pekko, Kvrocks, Celeborn, StreamPark, and Answer are all absent from the exports matrix, while the projects that appear either implement cryptography or bundle a crypto library — Impala's entry names the OpenSSL Project for exactly that reason.
The guidance was given privately, so exit criteria 4 and 5 still need it recorded publicly by an appropriate party. #3273's own wording allows closing on "the authoritative determination that no entry is needed" rather than on a filed notification.
Refs #3273
Verification
Documentation only — no code changes, so no test, typecheck, or build applies. Biome does not format Markdown.
Counts are against the fixed tree (
git grep <pattern> 52c0e3275). Scanning covers all 2706 tracked files across every file type — shell, Python, PowerShell, Rust, Swift, and Dockerfiles included. Dependency attribution comes from all three tracked lockfiles (derived fromgit ls-tree, not assumed by ecosystem) and the installed tree. ASF and EAR criteria were read frominfra.apache.org/crypto.html,apache.org/licenses/exports/, andlaw.cornell.edu/cfr/text/15/742.15.§A–§H are exhaustive for the tracked source. §J is explicitly not exhaustive for transitive dependencies, and the document explains why in concrete terms: two revisions each missed a shipped dependency whose crypto a package-name scan does not surface. A closed manufacturer set must be generated per artifact from a frozen install and the actual packaged output.
Review history
Two rounds of adversarial review by Claude Fable and OpenAI Codex. Every finding was independently verified before being applied. The first revision did not survive; neither did the second.
Round 1 — the conclusion was wrong in kind.
mitmdumpinterception in the eval egress proxy.credential-vault.json, which holds the Connection API/OAuth material.joseand AWS signature crypto.Round 2 — the fix overreached in the opposite direction, and two shipped dependencies were still missing.
dugite3.2.2@jackwener/opencli1.8.6experiments/windows-sandbox/launcher/Cargo.lockwas missing.ConvertTo-SecureString -AsPlainText -Forceperforms no encryption.docs/placementmain.Rejected after independent consideration: deleting the negative-result sections (§C, §D, §H). #3273's exit criterion names HMAC and credential storage explicitly, so recording that those surfaces were examined and found exempt is part of the deliverable, not padding.
Also rejected: moving the document to
docs/archive/. It supports an in-flight filing process, andarchive/signals superseded material that is not current guidance. It stays indocs/. Progress tracking and TODOs were moved to #3273 per the same authority map.Review focus
@jackwener/opencliis the sharpest case: hardcoded vendor signing keys against undocumented endpoints, shipped in the desktop app. Whether authentication-only scope or public availability of the implementation excludes it is exactly what needs deciding.AI use
Select exactly one:
Tool(s) and scope: Claude (claude-opus-5) via Claude Code ran the source and dependency searches, read the ASF and EAR sources, and drafted the document and this PR body. Claude Fable and OpenAI Codex performed two rounds of adversarial review; their findings were verified against the source and the regulatory text before being applied, and are credited in the document footer. None of this is independent human review. The human contributor of record owns accuracy, provenance, and the submission decision. Every commit carries a
Generated-bytrailer.Checklist
All six commits carry
Generated-bytrailers.Does this PR entail a change in behavior?