On 3/15/26 04:17, Edmond Dantes wrote:
Hello!
However, this proposal would put a completely unrealistic burden on php-src
maintainers.
It seems to me this is an organizational problem that certainly has a
good solution.
In my company we also use something similar.
In practice it does not require that much effort. Moreover, right now
I am doing essentially the same thing for the TrueAsync project:
- the php-src code is updated
- tests are run
- if the tests pass, the code proceeds further
I am doing this manually, although the process could be automated.
TrueAsync currently has about 18,000+ lines of changes in PHP-SRC.
Over these six months my personal attention was required only 2–3
times. I can confirm a similar experience with other projects as well.
A large number of different solutions can be devised here, both at the
level of flow and rules, and at the level of technical approaches. So
yes, it is a problem.
But it is a problem that has a solution.
I worked on an automated release workflow[^1] for php-src a few years
ago, but after discussions with others from various major project
communities (including Apache, Linux, etc.), I realized the solution
wasn't workable for one main reason:
An automated workflow cannot sign builds and still be considered secure.
Builds must be signed by a human on the machine where the build took
place. Automating the signatures in the cloud significantly reduces
trust and greatly increases the likelihood of a bad actor gaining access
to sneak things into the build (e.g., through compromised GitHub
Actions, etc.).
This was the nearly universal advice I was given by folks from other
communities in 2023. I doubt that it's changed much since then, and
especially with the rise of software supply chain attacks, it's probably
even more relevant today.
Cheers,
Ben
[^1]: https://github.com/php/php-src/pull/10604
