Repository navigation
legal: complete the Maka cryptography export classification #3273
Description
Activity
- added a parent issue
on Aug 20, 2026 Edited 2026-08-20. This comment originally contained two factual errors, corrected below and marked where they were. Because the original went out by email before the edit, the corrections are stated explicitly rather than silently patched. I have also removed the self-assignment.
Claiming the inventory work — the first exit criterion only. I am not claiming the notification, the matrix entry, or the determination, and per this issue's instruction to leave it unassigned until the PPMC and mentors identify a coordinator, I have left it unassigned.
Draft PR: #3318 — every cryptographic path in the tracked source at
52c0e3275, each row citing a file path or package name.Established. Maka's own source performs AES-256-GCM encryption (the Managed Secret envelope store, and QQ Bot bind-task secret decryption) and generates an RSA-2048 CA to intercept TLS in the eval egress proxy. Both are past the 5D002 thresholds. Maka implements no cryptographic primitive of its own.
Correction 1 — I previously wrote that "no proprietary or unpublished algorithm or protocol appears anywhere." That was not established, and I should not have asserted it. 15 CFR §742.15(b)(2) does limit the notification requirement to source code providing or performing "non-standard cryptography," but §772.1 reaches proprietary or unpublished cryptographic protocols, not only algorithms — so enumerating standard algorithm names does not answer the question. At least three constructions need a protocol-level determination:
@jackwener/opencli1.8.6, a direct desktop dependency, carries vendor-private API signing with hardcoded key material against undocumented endpoints (Instagramsigned_body, Tieba and Flomo salted signing, YouTubeSAPISIDHASH).- Tencent's QQ Bot bind-task protocol is proprietary and undocumented, and Maka participates in its key exchange.
- The Managed Secret envelope and AAD construction is Maka's own, though published in this source.
Whether any of these is non-standard under §772.1 is a question for VP Legal, and the PR now says so instead of answering it.
Correction 2 — I previously wrote that there is no source-release assembly script. That was already false when posted. #3278 merged about an hour earlier and added
scripts/asf-source-release.mjs. It builds the source artifact withgit archive, and.gitattributesmarks only three pathsexport-ignore, soexperiments/andpackages/eval/harbor/are inside the source artifact — including the CA-generation path above. That resolves what I had listed as an open question, and adds GPG detached signing as a surface the first revision did not cover.Also added since the first revision:
dugite3.2.2, 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 cryptographic payload in the product, and it matters for the manufacturer set.What this leaves open, with owners named in the PR: whether a notification is required at all (ASF's published process says yes; the ASF page dates itself May 24, 2019 and asks projects to follow it "until the Apache VP Legal Affairs approves an updated version"); the §772.1 protocol classification; the manufacturer set per artifact; and the podling filing mechanics. The second exit criterion — confirming with mentors and the ASF export process — looks like the critical path rather than the third.
One repository correction: this issue links
https://www.apache.org/licenses/exports/crypto.html, which returns 404. The live guidance is at https://infra.apache.org/crypto.html. (#2974 links onlyexports/and is unaffected.)AI disclosure: the inventory was produced with Claude Code and put through two rounds of adversarial review by Claude Fable and OpenAI Codex. Both corrections above came out of the second round; the underlying facts were verified against the source and the regulatory text before being applied here. That is not independent human review. I own the accuracy of this comment and the decision to post it.
- added 4 commits that reference this issue
on Aug 20, 2026 - added 6 commits that reference this issue
on Aug 20, 2026 Closing this.
Per mentor guidance, the ASF cryptography notification process does not apply to Maka: the project develops no cryptographic algorithm of its own and relies on existing third-party dependencies. No BIS notification and no exports-matrix entry are required, so exit criteria 2 through 5 have no work behind them.
Recommending that export classification not be carried as a core incubation gate for the first release. If it does turn out to matter, it will be raised through the normal Incubator review rather than driven from here.
#3318, which inventoried the cryptographic paths in the source, is closed for the same reason.
English
Part of #2974 — G6: export classification.
Outcome
Complete the ASF export-control review and required public record for the
cryptographic functionality in the code intended for the first release.
Exit criteria
artifact, including encryption, HMAC, TLS, SSH, and credential storage paths.
publicly available/open source and what notification or classification is
required.
record, or document the authoritative determination that no entry is needed.
Existing work
No current issue or pull request implements this gate, and Maka is not currently
listed on the ASF export-classification page.
Out of scope
required.
References
Ownership
Leave this issue unassigned until the PPMC and mentors identify a coordinator.
简体中文
#2974 的一部分——G6：出口分类。
目标结果
针对拟进入第一次发版的密码学功能，完成 ASF 出口管制审查和所需公开记录。
完成条件
何种通知或分类。
的权威结论。
已有工作
目前没有实现这一 gate 的 issue 或 PR，ASF export classification 页面也尚未列出 Maka。
不在范围内
参考资料
负责人边界
在 PPMC 和 mentors 确定协调者前保持 unassigned。