On 22/03/2026 15:55, Neil C Smith wrote:
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.
I think it should be possible to make this work. There are several ways
to achieve the requirement that the RM (and other PMC members) can
verify the binary package built by the CI.
A couple of questions:
Is is realistic for the RM (and other PMC members) to build the releases
locally without code signing? If not, this gets a lot harder - maybe
even impossible.
Is that process reproducible (given no code signing, the same OS, same
JDK and same .zip distribution)? If not, how much work is it to make it
reproducible?
Which tool are you using for Windows code signing? JSign?
I know JSign can remove Windows signatures and it looks like Apple
signing tools can remove signatures too so I am thinking of a process
something along the lines of:
- CI builds installer with code signing
- RM (and other PMC members) build installer locally without code
signing
- run a tool that unpacks the installers and compares each component,
removing the signature from any signed component before the compare
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
