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 > >
