Repository navigation
infra: obtain ASF code signing identities for Desktop artifacts #3414
Description
English
Part of #2974 — prerequisite for G9 (#3276).
Outcome
Maka holds the ASF code-signing identities needed to publish Desktop convenience binaries: ASF Apple Developer Program access for macOS and ssl.com eSigner access for Windows, with named Release Managers on each.
Why this is separate
This work consists of INFRA Jira requests and account provisioning, not product code. It has external lead time, cannot be accelerated by adding contributors, and G9 cannot close without it. Tracking it separately keeps that prerequisite visible while the remaining Desktop implementation proceeds.
Current state
- macOS: feat(release): unify Desktop and CLI product releases #3222 proposes a unified
.github/workflows/release.ymlthat still consumes the project’s current Apple credentials and pinsFABM2QUA8Qfor the standalone CLI. That value has not been established as the ASF Team ID and must not become the final signing authority. The Desktop verifier currently proves only that a signature and notarization are valid, not that they belong to the ASF identity. - Windows: feat(release): unify Desktop and CLI product releases #3222 continues to build unsigned Windows artifacts, and
apps/desktop/electron-builder.config.mjsrecords that no Authenticode certificate is configured. G9 requires eSigner provisioning and pipeline verification before that release path is complete.
Exit criteria
- The PPMC names one or two Release Managers who will hold the signing credentials.
- An INFRA Jira ticket under the
code signingcomponent requests eSigner access for each named Release Manager. Accounts are per-person and may not be shared. - Each Release Manager creates an Apple ID on their
@apache.orgaddress, requests ASF Apple Developer Program membership through INFRA Jira, and records their acceptance of the current Apple Developer Program Agreement. - Infra confirms the ASF Apple Team ID and the approved CI credential-provisioning method; reviewed repository configuration pins that identity, and both Desktop and standalone CLI verification reject any other Team ID.
- Windows release-candidate builds are signed through eSigner using Infra-approved credential provisioning. Per Infra guidance, sign release candidates only — signing every CI build is a cost to the Foundation.
- The Windows pipeline verifies Authenticode publisher identity and timestamp, and any platform-signature failure blocks the candidate.
Open question for the PPMC and Infra
eSigner accounts are per-person and non-shareable, while automated signing requires the 2FA secret to live in a configuration file. Putting that secret into shared repository secrets means a Release Manager’s personal credential is held by shared CI. ASF documentation does not explicitly approve that GitHub Actions arrangement; ask Infra for the supported provisioning model in the same ticket rather than deciding it locally.
The same ticket should also confirm how Apple Developer ID and notarization credentials may be supplied to the protected GitHub Actions release environment.
Constraints worth stating up front
Apple grants the ASF a fee waiver on the condition that the ASF distributes all involved applications for free.
Platform signatures do not replace the Apache release signature. Every downloadable artifact still needs the detached OpenPGP signature and checksum required by G9, and the source release remains the ASF release.
Out of scope
- Removing bundled Git (Decision needed: where does the Desktop Git runtime come from after we remove bundled Git? #3411) and the rest of the G9 implementation (release: publish ASF-compliant Desktop convenience artifacts #3276).
- Relabeling artifacts already published (release: resolve post-incubation GitHub and npm distribution status #3274).
References
Ownership
Leave unassigned until the PPMC names the Release Managers, since the accounts are issued to specific people.
简体中文
目标结果
Maka 取得发布 Desktop convenience binaries 所需的 ASF 代码签名身份：macOS 的 ASF Apple Developer Program 权限，以及 Windows 的 ssl.com eSigner 权限，并为各自指定 Release Manager。
为什么单独跟踪
这项工作是 INFRA Jira 工单和账号开通，不是产品代码。它有外部等待周期，增加人手也无法加速，而 G9 在它完成前不能关闭。单独跟踪可以在继续推进其他 Desktop 实现的同时，清楚展示这个前置依赖。
当前状态
- macOS：feat(release): unify Desktop and CLI product releases #3222 提议的统一
.github/workflows/release.yml仍使用项目当前的 Apple 凭据，并为 standalone CLI 固定了FABM2QUA8Q。该值尚未被证明是 ASF Team ID，不能成为最终签名 authority。Desktop verifier 当前只证明签名与公证有效，并未证明它们属于 ASF 身份。 - Windows：feat(release): unify Desktop and CLI product releases #3222 仍构建未签名的 Windows artifacts，
apps/desktop/electron-builder.config.mjs也记录了没有配置 Authenticode 证书。G9 必须取得 eSigner 权限并在流水线中验证签名，才能完成这条发布路径。
完成条件
- PPMC 指定 1～2 名持有签名凭据的 Release Manager。
- 在 INFRA Jira 以
code signing组件提单，为每位指定的 Release Manager 申请 eSigner 权限。账号按人发放，不可共用。 - 每位 Release Manager 使用
@apache.org邮箱创建 Apple ID，通过 INFRA Jira 申请加入 ASF Apple Developer Program，并记录其对当前 Apple Developer Program Agreement 的接受。 - Infra 确认 ASF Apple Team ID 和批准的 CI 凭据配置方式；仓库中经过审查的配置固定该身份，Desktop 与 standalone CLI 验证都拒绝其他 Team ID。
- Windows release-candidate 构建通过 eSigner 和 Infra 批准的凭据配置方式签名。依 Infra 指导，只签 release candidate——对每个 CI 构建签名会给基金会带来成本。
- Windows 流水线验证 Authenticode publisher identity 与 timestamp，任何平台签名失败都阻断候选版本。
需要 PPMC 和 Infra 回答的问题
eSigner 账号按人发放且不可共用，而自动签名要求把 2FA secret 写入配置文件。将该 secret 放进共享 repository secrets，意味着某位 Release Manager 的个人凭据由共享 CI 持有。ASF 文档没有明确批准这种 GitHub Actions 安排；应在同一张工单中询问 Infra 支持的配置方式，而不是在项目内自行决定。
同一张工单还应确认 Apple Developer ID 与公证凭据如何提供给受保护的 GitHub Actions release environment。
需要预先说明的约束
Apple 给予 ASF 费用豁免的条件是：ASF 免费分发所有相关应用。
平台签名不能替代 Apache 的发版签名。每个可下载 artifact 仍需要 G9 要求的 detached OpenPGP signature 和 checksum，源码 release 仍然是 ASF release。
不在范围内
- 移除 bundled Git（Decision needed: where does the Desktop Git runtime come from after we remove bundled Git? #3411）以及 G9 的其余实现（release: publish ASF-compliant Desktop convenience artifacts #3276）。
- 对已发布 artifacts 的重新标注（release: resolve post-incubation GitHub and npm distribution status #3274）。
参考资料
负责人边界
在 PPMC 指定 Release Managers 之前保持 unassigned，因为账号发给具体个人。
Updated for #3222 from current ASF Infra documentation. Credential, membership, and CI provisioning decisions remain with the PPMC, mentors, and ASF Infra.
Activity
Astro-Han commentedon Sep 1, 2026
English
Status: the first exit criterion is now met, which unblocks filing the INFRA tickets
The first criterion — the PPMC names one or two Release Managers who will hold the signing credentials — is satisfied.
astrohanis primary andwytis backup for Apache Maka 0.2.0, covering both macOS and Windows. Discussion #3595 carries the volunteering.Publicly verifiable: the podling
KEYSathttps://dist.apache.org/repos/dist/dev/incubator/maka/KEYSnow publishesAstroHan <astrohan@apache.org>, RSA 4096, created 2026-08-27, expiring 2028-08-26, and the same file is mirrored to the release area.That means the two INFRA Jira tickets this issue is waiting on can be filed now:
@apache.orgaddress.code signingcomponent.Both should carry the open question already recorded in this issue: eSigner accounts are per-person and non-shareable, while automated signing needs the 2FA secret in a configuration file, and ASF documentation does not explicitly approve holding a personal credential in shared repository secrets. The same ticket should ask how Apple Developer ID and notarization credentials may be supplied to the protected release environment.
Two things that need a decision before this can close
KEYSholds one key. Ifwytmay sign anything as backup Release Manager, that public key must be appended toKEYSand republished through the ASF distribution process first. A voter verifying awyt-signed candidate against the publishedKEYSwould fail today.The Windows signing requirement is stated two different ways.
.github/RELEASE_CHECKLIST.mdPhase 1 requires "the unsigned Windows x64 Desktop installer and ZIP" and records that Windows stays unsigned until an Authenticode policy and certificate are added. This issue and #3276 require eSigner signing, or an explicit mentor/IPMC determination for any proposed unsigned artifact before the vote. Those cannot both be the standing rule. Whichever we pick, the other document should change in the same PR.This issue does not gate the source release — #2974 has been restructured and it now sits in the non-blocking table — but it does gate Desktop convenience artifacts through #3276, and its lead time is external.
简体中文
进展：第一条出口条件已满足，可以着手提交 INFRA 工单
第一条——由 PPMC 指定 1～2 名持有签名凭据的 Release Manager——已满足。Apache Maka 0.2.0 的正 Release Manager 为
astrohan，备份为wyt，覆盖 macOS 与 Windows 两个平台。自荐记录见 Discussion #3595。公开可核验：
https://dist.apache.org/repos/dist/dev/incubator/maka/KEYS中的 podlingKEYS已发布AstroHan <astrohan@apache.org>，RSA 4096，2026-08-27 生成，2028-08-26 到期，同一文件已镜像至 release 区。这意味着本 issue 等待的两张 INFRA Jira 工单现在可以提交：
@apache.org邮箱创建的 Apple ID。code signing组件下，为每位指定的 Release Manager 申请 ssl.com eSigner 权限。两张工单都应带上本 issue 已记录的开放问题：eSigner 账号按人发放且不可共用，而自动签名需要把 2FA secret 写入配置文件，ASF 文档并未明确批准把个人凭据放在共享 repository secrets 中。同一张工单还应询问 Apple Developer ID 和公证凭据可以通过什么方式提供给受保护的发布环境。
关闭前需要决定的两件事
KEYS只有一把密钥。 如果wyt可能作为备份 Release Manager 签署任何产物，必须先把该公钥追加到KEYS并通过 ASF 分发流程重新发布。以今天的状态，投票人拿已发布的KEYS去验证wyt签出的候选包会失败。Windows 签名要求有两种不同表述。
.github/RELEASE_CHECKLIST.md的 Phase 1 要求「未签名的 Windows x64 Desktop 安装包与 ZIP」，并记录 Windows 在补齐 Authenticode 策略和证书之前保持未签名。而本 issue 与 #3276 要求通过 eSigner 签名，或在投票前就任何拟发布的未签名产物取得导师/IPMC 的明确裁定。两者不能同时成立。无论选哪一个，另一份文档都应在同一个 PR 中修改。本 issue 不构成源码发布的门禁——#2974 已重构，它现位于非阻塞表中——但它通过 #3276 构成 Desktop convenience artifacts 的门禁，且其等待周期来自外部。
Drafted with help from Claude Code. I reviewed the final text and take responsibility for posting it.
Astro-Han commentedon Sep 1, 2026
English
Correction: both INFRA tickets were already filed
My previous comment said the two INFRA Jira tickets "can be filed now" and listed them as outstanding. That was wrong — both were filed before I commented, and both are in Infra's queue. I could not see them because the INFRA project is not readable anonymously, and I reported that as "not filed" instead of "cannot verify". Corrected status:
Both are filed under the
Codesigningcomponent and both name the same release managers:astrohanwytThat means more of this issue's exit criteria are already met than the previous comment implied:
code signingrequests eSigner access for each named release manager, and it records that we will sign release candidates only, not ordinary CI builds.@apache.orgaddresses, and INFRA-28301 asks Infra to add them to the ASF Apple Developer Program participants list.What remains on those criteria is Infra action and the resulting pipeline verification, not project work.
Withdrawing the KEYS point
My previous comment raised the podling
KEYSfile holding one key as something to resolve here. That was a category error:KEYScovers the OpenPGP signature on the ASF source release, while this issue covers Apple Developer ID and Authenticode signing of Desktop convenience artifacts. The two are unrelated mechanisms, and nothing about Desktop signing depends onKEYS. Please disregard that paragraph.Still open, and unchanged
The Windows signing requirement is stated two different ways.
.github/RELEASE_CHECKLIST.mdPhase 1 requires the unsigned Windows x64 installer and ZIP and records that Windows stays unsigned until an Authenticode policy and certificate exist. This issue and #3276 require eSigner signing, or an explicit mentor/IPMC determination for any proposed unsigned artifact before the vote. Those cannot both be the standing rule; whichever we pick, the other document should change in the same PR.简体中文
更正：两张 INFRA 工单早已提交
我上一条评论说两张 INFRA Jira 工单「现在可以提交」，并把它们列为待办。这是错的——两张都在我评论之前就已提交，且都在 Infra 的队列中。我看不到它们，是因为 INFRA 项目不对匿名开放，而我把这种情况报告成了「未提交」，本应报告为「无法核实」。更正后的状态：
两张均在
Codesigning组件下提交，并指名同一组 release manager：astrohanwyt这意味着本 issue 已满足的出口条件比上一条评论所暗示的更多：
code signing组件下提交 INFRA 工单，为每位指定的 release manager 申请 eSigner 权限，并记录我们只签 release candidate、不签普通 CI 构建。@apache.org邮箱创建 Apple ID，INFRA-28301 请求 Infra 将其加入 ASF Apple Developer Program 参与者名单。这些条件上剩下的是 Infra 的动作以及随后的流水线验证，不是项目侧的工作。
撤回 KEYS 那一段
我上一条评论把 podling
KEYS只有一把密钥列为本 issue 需要解决的事项。那是归类错误：KEYS对应的是 ASF 源码发布上的 OpenPGP 签名，而本 issue 对应的是 Desktop convenience artifacts 的 Apple Developer ID 与 Authenticode 签名。两者是彼此无关的机制，Desktop 签名不依赖KEYS的任何内容。请忽略那一段。仍然开放，且未变
Windows 签名要求有两种不同表述。
.github/RELEASE_CHECKLIST.md的 Phase 1 要求未签名的 Windows x64 安装包与 ZIP，并记录 Windows 在补齐 Authenticode 策略和证书之前保持未签名。而本 issue 与 #3276 要求通过 eSigner 签名，或在投票前就任何拟发布的未签名产物取得导师/IPMC 的明确裁定。两者不能同时成立；无论选哪一个，另一份文档都应在同一个 PR 中修改。Drafted with help from Claude Code. I reviewed the final text and take responsibility for posting it.
fix(release): make unsigned Windows artifacts reproducible (#4690)
Astro-Han commentedon Sep 5, 2026
Closing as not planned for 0.2.0. I’m focusing on the source release and withdrawing the Apple and Windows signing requests. This can be reopened if signed Desktop convenience artifacts become part of a future release plan.