+1 (binding) I have checked: - [x] The signature (from Zhaofeng Chen) is correct. - [x] build and tests passed on archlinux x86_64.
Xuanwo On Tue, Jun 24, 2025, at 08:06, Zhaofeng Chen wrote: > Thanks Mingshen and Gordon for the additional votes. > > @xuanwo could you take some time to complete the validation? After your > feedback, I will wrap up the voting result and proceed to the next step. > > Best, > Zhaofeng > > On Tue, Jun 24, 2025 at 7:58 AM Gordon <qich...@gmail.com> wrote: > >> +1 >> >> On Mon, Jun 23, 2025 at 12:27 AM Yuan Zhuang <yu...@apache.org> wrote: >> >> > +1 (binding) >> > I have checked: >> > - The signature (from Zhaofeng Chen) and hashes are correct. >> > - I'm able to build from source and all tests passed. >> > >> > >> > On 2025/06/20 13:54:12 Zhaofeng Chen wrote: >> > > Hi, >> > > >> > > The KEYS file and .asc signature have been updated. As the original >> > release >> > > artifacts remain unchanged, this vote can continue without restarting. >> > > >> > > Please feel free to proceed with your verification. >> > > >> > > Best regards, >> > > Zhaofeng >> > > >> > > On Thu, Jun 19, 2025 at 1:57 PM Xuanwo <xua...@apache.org> wrote: >> > > >> > > > 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 >> > > > >> > > > >> > > >> > >> > --------------------------------------------------------------------- >> > 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
