Thank you for this change. I don't have other questions and will continue the verify after your updates.
On Thu, Jun 19, 2025, at 13:55, Zhaofeng Chen wrote: > Hi Xuanwo, > > Thanks for raising these excellent points — we really appreciate the > thoughtful feedback. > > - Who will pay for the hardware? > The PMC member who physically maintains the hardware-backed key (e.g., a > YubiKey) covers the cost themselves. > > - Will all PMC members receive this hardware? > No. Our intention isn’t to distribute hardware to every PMC member, but > rather to offer an optional, secure signing path. Access to the > hardware-backed key is permissioned, and signing operations are handled > through an offline, controlled process. This setup doesn’t restrict others > from managing releases — it’s just one way to offload key management for > those who prefer it. > > - Can PMC members who do not have this hardware still sign releases? > Yes, absolutely. This setup is complementary, not a replacement. PMC > members can still sign releases using their own GPG keys, as per standard > ASF policy. The shared signing workflow is only intended to reduce the > operational burden for those who want stronger security without maintaining > their own key infrastructure. > > Ultimately, I hope we can make the release process both easier and more > secure, and potentially encourage more contributors to serve as Release > Managers. > However, after another round of reviewing ASF’s release signing > guidelines[1], I realized that our idea shares similarities with Apache’s > automated signing infrastructure, which is maintained by the Infra team. In > particular, it supports: > - Centralized signing keys managed securely by Infra > - CI-based artifact generation, reproducibility, and offline verification > - Strong separation between signing infrastructure and project maintainers > > This might be a promising long-term direction for us. In the future, we > could explore working with Infra to request a project-specific signing key. > > [1] https://infra.apache.org/release-signing.html#automated-release-signing > > To avoid any potential confusion for this release, I will revert to the > standard model and proceed with signing the artifacts using my personal GPG > key, which will be added to the KEYS file accordingly. Since the original > release artifacts remain unchanged, and only the .asc signature file will > be updated, I plan to reuse this vote thread for continuity. > > Any feedback is greatly appreciated. > > Best, > Zhaofeng > > On Thu, Jun 19, 2025 at 1:14 PM Xuanwo <xua...@apache.org> wrote: > >> Thank you Zhaofeng for the explanation. >> >> > We understand that the current key name may be confusing. To make its >> > shared nature clearer, we plan to introduce a new key entry with identity >> > set to something like "Teaclave Release Signing Key", which makes it more >> > reasonable for people who are trying to verify the artifacts. >> >> This looks good to me. >> >> > In the new setup, the shared GPG key is hardware-backed (e.g., YubiKey), >> > PIN-protected, with expiration date, and maintained by a small group of >> > administrators. >> >> This can sometimes be challenging, as it may restrict some PMC members >> from making releases. I know that's not your intention, but it can give the >> impression that the project is controlled by a small group of people. >> >> Here are some questions: >> >> - Who will pay for the hardware? >> - Will all PMC members receive this hardware? >> - Can PMC members who do not have this hardware still sign releases? >> >> However, this isn't a blocker for the release. We can address these issues >> gradually. >> >> On Thu, Jun 19, 2025, at 13:08, Zhaofeng Chen wrote: >> > Hi Xuanwo, >> > >> > Thanks for the helpful input. >> > >> > - We’ll update future emails to use the official CDN link: >> > https://downloads.apache.org/incubator/teaclave/KEYS . For verification >> > purpose, the file content is identical. >> > >> > Regarding the signing key: >> > We’re moving toward a model where multiple release managers can securely >> > use the same high-assurance signing key. Previously, each release manager >> > generated and managed their own GPG key independently, which led to >> > inconsistent security practices and made key rotation more difficult. >> > >> > In the new setup, the shared GPG key is hardware-backed (e.g., YubiKey), >> > PIN-protected, with expiration date, and maintained by a small group of >> > administrators. Release managers don’t personally own the key but can >> > request access to perform signing operations in a controlled, offline >> > process. This approach improves key protection, simplifies key lifecycle >> > management, and ensures better privilege separation. >> > >> > We understand that the current key name may be confusing. To make its >> > shared nature clearer, we plan to introduce a new key entry with identity >> > set to something like "Teaclave Release Signing Key", which makes it more >> > reasonable for people who are trying to verify the artifacts. >> > >> > I'd love to hear any feedback the community may have on this plan. If it >> > sounds reasonable and compliant with Apache's policy, I can proceed with >> > updating the KEYS file with the new key name and the corresponding >> > signature files. >> > >> > Best, >> > Zhaofeng >> > >> > On Thu, Jun 19, 2025 at 10:53 AM Xuanwo <xua...@apache.org> wrote: >> > >> >> Hi, Zhaofeng >> >> >> >> Thank you for working on this release. This is my first time reviewing >> >> releases, so please let me know if there's any context I should be >> aware of >> >> beforehand. >> >> >> >> Here are some questsions I have: >> >> >> >> - It's better to use our CDN for the GPG key download URL: >> >> https://downloads.apache.org/incubator/teaclave/KEYS >> >> - I noticed that the release is signed by a different key, >> >> yu...@apache.org, which does not belong to Zhaofeng. Is it signed >> >> automatically in CI? >> >> >> >> On Thu, Jun 19, 2025, at 08:03, Zhaofeng Chen wrote: >> >> > Hi all, >> >> > >> >> > I am pleased to be calling this vote for the release of Apache >> Teaclave >> >> > TrustZone SDK (incubating) 0.5.0 (release candidate 1). >> >> > >> >> > Although this release follows shortly after the approval of the >> v0.4.0 on >> >> > June 3, please note that the earlier release was initiated back on >> >> February >> >> > 27 and was significantly delayed due to a prolonged voting process. >> Since >> >> > then, we’ve made improvements to streamline the process and hope this >> >> > release proceeds more smoothly. >> >> > >> >> > The release note is available in: >> >> > - >> >> > >> >> >> https://github.com/apache/incubator-teaclave-trustzone-sdk/releases/tag/v0.5.0-rc.1 >> >> > >> >> > The release candidate to be voted over is available at: >> >> > - >> >> > >> >> >> https://dist.apache.org/repos/dist/dev/incubator/teaclave/trustzone-sdk-0.5.0-rc.1/ >> >> > >> >> > The release candidate is signed with a GPG key available at: >> >> > - https://dist.apache.org/repos/dist/release/incubator/teaclave/KEYS >> >> > >> >> > Instructions to verify the release candidate’s signature: >> >> > - >> >> https://teaclave.apache.org/download/#verify-the-integrity-of-the-files >> >> > >> >> > Incubator release checklist for reference: >> >> > - >> >> > >> >> >> https://cwiki.apache.org/confluence/display/INCUBATOR/Incubator+Release+Checklist >> >> > >> >> > The release artifacts have passed all GitHub Actions CI checks. You >> can >> >> > also reproduce the build process manually from source using the >> >> > following >> >> > commands: >> >> > ``` >> >> > $ wget >> >> > >> >> >> https://dist.apache.org/repos/dist/dev/incubator/teaclave/trustzone-sdk-0.5.0-rc.1/apache-teaclave-trustzone-sdk-0.5.0-incubating.tar.gz >> >> > $ tar zxvf apache-teaclave-trustzone-sdk-0.5.0-incubating.tar.gz >> >> > $ cd apache-teaclave-trustzone-sdk-0.5.0-incubating >> >> > $ docker run --rm -it -v$(pwd):/teaclave-trustzone-sdk -w \ >> >> > /teaclave-trustzone-sdk yuanz0/teaclave-trustzone-sdk:ubuntu-24.04 \ >> >> > bash -c "./setup.sh && (./build_optee_libraries.sh optee) && source \ >> >> > environment && make && (cd ci && ./ci.sh)" >> >> > ``` >> >> > >> >> > The vote will be open for at least 72 hours. Anyone can participate >> >> > in testing and voting, not just committers, please feel free to try >> >> > out the release candidate and provide your votes to this thread >> >> > explicitly. >> >> > >> >> > [ ] +1 approve >> >> > [ ] +0 no opinion >> >> > [ ] -1 disapprove with the reason >> >> > >> >> > Best, >> >> > Zhaofeng >> >> >> >> -- >> >> Xuanwo >> >> >> >> https://xuanwo.io/ >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: dev-unsubscr...@teaclave.apache.org >> >> For additional commands, e-mail: dev-h...@teaclave.apache.org >> >> >> >> >> >> -- >> Xuanwo >> >> https://xuanwo.io/ >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@teaclave.apache.org >> For additional commands, e-mail: dev-h...@teaclave.apache.org >> >> -- Xuanwo https://xuanwo.io/ --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@teaclave.apache.org For additional commands, e-mail: dev-h...@teaclave.apache.org
