Rainer,
On 11/9/25 12:35 PM, Rainer Jung wrote:
Hi there,
we now use gpg for two features:
a) signing release artefacts in the release target
b) checking signatures in the verify-release target
Now
a) gets run, whenever gpg.exec points to an existing file. If so, it
prompts interactively for a password to a siging key and uses that for
the signing. Since I want to run the release target but not to do the
signing, I used to set gpg.exec to a non-existing file.
Oh, right. This is why I set gpg.exec in build.properties.release: so
that signing would be enabled for a release-build by someone who was
verifying the release instead of preparing the release.
It's a bit of circular-reasoning, and I'm glad you are bringing this up,
Rainer, because I'd like to straighten it out, too.
b) gets run unconditionally and is a feature I would like to use. b)
requires gpg.exec to point to an existing file.
IMHO that combination, use b) but not a), might be frequent.
I propose to add another property, gpg.sign.files, which controls,
whether a) is used. Its default will be true, does unchanged behavior
and the existence check for gpg.exec will be left in place. Setting it
to false and gpg.exec to the correct gpg path, allows to run b) without a).
I have a patch ready and if there are no objections, I will apply it
tomorrow and add a sentence to BUILDING.txt.
Though I haven't seen the patch, I'm in favor of the idea so +1 for
commit in main and maybe even 11.0.x but I'd like to take a look before
back-porting to all branches.
It's easy for the release managers to change whatever is necessary to
perform the release. I'd like to make sure that someone else building
from a released source-bundle will be able to verify the gpg signatures
as long as the path to the gpg binary is known (or discoverable).
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
