Re: Create a GitHub action to build releases

On 18/08/2026 09:19, Rémy Maucherat wrote:
> On Mon, Aug 17, 2026 at 10:20 AM Mark Thomas <[email protected]> wrote:

>> What about the general idea of getting the releases to a point where we
>> have the option to use automation to produce the releases and, in normal
>> circumstances, use it?
> 
> I think it's great if you experiment, so +1. However, the thing I am
> most worried about is a supply chain attack, and this probably makes
> us more vulnerable to that, right ?

I agree with you that a supply chain attack is the biggest risk.

How much this automation increases that risk depends, I think, on 
exactly what we automated.

My thinking was to automate the process from "tag this" to having a set 
of binaries we can vote on. I was also thinking about a "build the 
binaries from this tag" process.

It increases the risk in that the code signing keys are accessible to an 
automated process. But that is an ASF-wide risk and one that doesn't 
change depending on whether we use them or not. There is also a risk 
that a PR injects something malicious into the publishing process but I 
expect any PRs touching those files will get looked at very closely.

Reproducible builds continue to provide the bulk of the protection. If 
the automated process is subverted, our local builds should detect that 
providing we build from the tag not the source bundle. As long as we 
retain this manual check between automated build and release I'm happy 
with the level of risk. I would not be in favour of any process that 
could automate (or could be tricked into automating) "tag this" all the 
way to "release announcement". I'd want to keep a "can only be completed 
manually" step in there somewhere. Even if it is just downloading the 
release bundle from one location, checking reproducibility, and then 
uploading it somewhere else.

I'm not exactly sure where ATR fits into the above. I haven't been 
following it too closely. That is probably the first thing to look at.

Mark