[
https://issues.apache.org/jira/browse/LUCENE-9488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17428351#comment-17428351
]
Chris M. Hostetter commented on LUCENE-9488:
--------------------------------------------
{quote}It's because of the comment in gpgSigning.txt - indeed the one about
gradle being multi-threaded, and no-tty issue... I thought it'd be the simplest
solution to just force gradle to be single-threaded (this is what the option
above does).
{quote}
...but that punishes people (like me) who have their gpg-agent configured with
a "good" pinentry command (that doesn't use the tty – mine works directly with
my OS keychain like a good gpg-agent should so you know you can trust it), by
forcing them to only one one worker thread for the entire gradle build if they
want to sign the artifacts.
Given that people (now) have to go out of their way to specify {{-PuseGpg}} the
explicit failure when workers > 1 seems excessive. Anybody who wants to
explicitly use the gpg-agent should just choose to use a good pinentry command,
or choose to use {{--max-workers 1}} if they really want a "bad" tty based
pinentry (even though that defeats the safety that gpg-agent provides because
you can't tell it's really gpg-agent asking for your passphrase).
Forcing anyone that want's to sign with a gpg-agent to use {{--max-workers 1}}
, simply because other people who don't know what they are doing _might_ get an
error if they go out of their way to {{-PuseGpg}} seems ... bizare.
This is essentially saying "If you want to use the safest possible mechanism
for gpg signing (gpg-agent + out of band passphrase), then you don't get to use
any parallelization in your build – because parallelization can't work for
people who use a less safe mechanism (gpg-agent + passphrase to gradle's tty)
and we don't want to make them set an extra option – even though people willing
to trust gradle's tty with their passphrase already have another (non
gpg-agent) option for doing the build with parallelization"
Why are we hobbling the feature designed for people protective of their
passphrase just to coddle the people who aren't protective of their phrase when
we've already added a simpler alternative for those very trusting people?
{quote}{quote}if folks are willing to provide their passphrase as a gradle
property, they can now use {{-Psigning.password=....}} instead There's no
reason to use {{-PuseGpg}} (and involve an external gpg / gpg-agent process)
{quote}
Right... that would be the simplest solution of all. But I think some people
will insist on using gpg-agent (and I understand the motives for doing this).
I'd leave it in as an option
{quote}
I'm not at all suggesting that we remove gpg-agent support – i would absolutely
-1 that.
I'm only talking about removing the docs regarding
{{-Psigning.gnupg.passphrase=...}} ... it existed before purely as a way to
support the "I'm lazy and don't have gpg-agent configured well and i want to
provide my passphrase on the command line" usecase – but we no longer need it
now that you've hooked in support for {{-Psigning.password=....}}
> Update release process to work with Gradle.
> -------------------------------------------
>
> Key: LUCENE-9488
> URL: https://issues.apache.org/jira/browse/LUCENE-9488
> Project: Lucene - Core
> Issue Type: Improvement
> Components: general/build
> Reporter: Erick Erickson
> Assignee: Mike Drob
> Priority: Major
> Fix For: main (9.0)
>
> Attachments: Skjermbilde 2021-10-05 kl. 11.18.28.png
>
> Time Spent: 22h
> Remaining Estimate: 0h
>
> The release process needs to reflect using Gradle rather than Ant. I suspect
> this will be a significant task, thus it has its own JIRA
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
