On Sun, 22 Mar 2026 at 12:58, Jarek Potiuk <[email protected]> wrote: > ... the release process is generally one of the best described and > least flexible processes in the ASF for a reason: it is essentially a legal > act of the Foundation and carries certain risks for the Foundation. ... > automating what can be automated, but other than that it > has to be 100% compliant with > https://www.apache.org/legal/release-policy.html that delegates to a inumer > of other documents and has MUST in quite a few places.
A document I've referred to many times in the last decade or so! ;-) And strictly speaking, we release sources - I don't think it's changed that only sources, and not convenience binaries, are legal acts of the foundation. Even when they're code signed with foundation certificates. This is a fudge I've raised in threads on the members list that I think you were also involved in. But it's not relevant to this. As far as I'm aware nothing I'm asking for here is contrary to the release policy. Any convenience binary will still be verified locally and signed with a detached cryptographic signature by a release manager, and even if not strictly required, these binaries will be linked to the release vote. > Sure—so now I better understand: what you are **really** looking for is not > automating the release process on Infra hardware, but strictly automating > just the signing process. This means that, according to policy, such a > signed package must be "Verified" in local hardware owned by the release > manager. This might - or might not - mean that the whole release process is > done in infra - it might for example mean that there is a service (very > well contrilled by Infra) where you upload binary Yes, the code signing process. Well, kind of. I am strictly asking about automating the installer building process, which requires access to secrets with the code signing certificates. It is not feasible to upload a file to some service after the fact. This is not a one-step thing. On macOS, NBPackage takes the code certificate and the hardened runtime entitlements; it uses Apple's signing tool to sign every native library inside the IDE, including ones that reside inside JAR archives; then it builds the App bundle that contains all those signed natives and signs that; then it builds a macOS installer package that includes that signed app bundle and signs that with a different certificate. The installer then gets notarized by Apple, after which it might get another certificate attached to it. > One step required the person signing to enter a Faraday > cage, where 3 people had to assemble 3 keys so that person could enter and > sign the OS with the company's secret key. Whereas the foundation's Apple private keys that I used were sent to me by email ... :-) What I'm asking for is not perfect, but it's a step in the right direction to a more efficient, secure and verifiable way for us to manage this. Thanks, Neil --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
