Am 10.11.25 um 15:25 schrieb Christopher Schultz:
Mark,
On 11/10/25 9:18 AM, Mark Thomas wrote:
On 10/11/2025 13:15, Christopher Schultz wrote:
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.
I'm not sure I follow.
The person verifying the release needs gpg.exec set to their local
path to gpg, not to whatever path the release manager used. Don't they?
Yes, but a bunch of things were being skipped during the build if the
path wasn't set at all, which would be typical for someone downstream.
Even though gpg isn't used during "release" when the signatures are
already there, I seem to remember some part of the build being skipped
unless gpg.exec was set to something. So the release set it to the RM's
path for lack of anything better.
I'm sure Rainer's solution will be better; I'll review it once he pushes
it.
My change will be independent of the question, whether gpg.exec makes
sense in build.properties.release. An alternative to gpg.exec might be
to gpg from the PATH but I haven't investigated how to code that.
I remember Mark previously also mentioned using gpg from the PATH as an
alternative. When using PATH, gpg.exec might become unnecessary, instead
relying on the user to include gpg in the PATH if he/she wants to use it.
Beste regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
