Le mar. 13 avr. 2021 à 13:04, Paul King <pa...@asert.com.au> a écrit :
> We don't use the keys file (being binary) for the source build. I guess we > could offer a way to bootstrap that too like we do for gradlew. Then users > could choose if they wanted to do the build with or without. > To me it feels a bit strange not to use this file because it's binary, when we also happily use images... which are binary too :) Anyway the format is a regular GPG keyring so it's easy to figure out what's inside. > > What would be good from the Gradle side is a better way to flush and > restart verification when flakey key servers are stumbled across because > there does seem to be some caching once the corruption occurs. > This is already the case: Gradle tries different key servers and exponential backoff. When ultimately it fails there's nothing much we can do. An option is to setup your own key server mirror. > Or perhaps there is a way I haven't discovered yet. > > Cheers, Paul. > > > On Tue, Apr 13, 2021 at 8:00 PM Cédric Champeau <cedric.champ...@gmail.com> > wrote: > >> Technically it's not Gradle's dependency verification which is flaky, >> it's the key servers. That's why you must, from time to time, update the >> local keyring, using `--export-keys` as explained in >> https://docs.gradle.org/current/userguide/dependency_verification.html#sec:local-keyring >> >> Then the builds wouldn't have to ping the remote servers on every build, >> because the keys would be found in the local keystore. >> >> Le mar. 13 avr. 2021 à 11:56, Paul King <pa...@asert.com.au> a écrit : >> >>> >>> Oops, forgot the mailing list. >>> >>> ---------- Forwarded message --------- >>> From: Paul King <pa...@asert.com.au> >>> Date: Tue, Apr 13, 2021 at 7:56 PM >>> Subject: Re: [VOTE] Release Apache Groovy 4.0.0-alpha-3 >>> To: Guillaume Laforge <glafo...@gmail.com> >>> >>> >>> Gradle's dependency verification (incubating feature) does seem to be a >>> little flakey sometimes. Hopefully it will improve over time. I have >>> numerous other environments where that error doesn't show but Daniel had a >>> similar but different error. Regenerating the verification metadata didn't >>> change anything for him which indicates the metadata is probably okay as >>> is. I'd suggest running with dependency verification set to lenient or off >>> and see if that helps: >>> >>> >>> https://docs.gradle.org/current/userguide/dependency_verification.html#sec:disabling-verification >>> >>> Cheers, Paul. >>> >>> >>> On Tue, Apr 13, 2021 at 6:51 PM Guillaume Laforge <glafo...@gmail.com> >>> wrote: >>> >>>> I got a test failure (on Java 11): >>>> >>>> Execution failed for task ':groovy-testng:test'. >>>> >>>> > Dependency verification failed for configuration >>>> ':groovy-testng:testRuntimeClasspath' >>>> >>>> One artifact failed verification: jcommander-1.78.jar >>>> (com.beust:jcommander:1.78) from repository MavenRepo >>>> >>>> This can indicate that a dependency has been compromised. Please >>>> carefully verify the signatures and checksums. >>>> >>>> Opening the report tells me: >>>> >>>> configuration ':groovy-testng:testRuntimeClasspath' 1 error >>>> <#m_-7713695666752602976_m_8153075787925662056_m_-2671871127063042544_m_5361968448074506625_m_-8064841157445032086_> >>>> MODULEARTIFACTPROBLEM(S) >>>> com.beust:jcommander:1.78 >>>> jcommander-1.78.jar (.asc) >>>> >>>> Key 22e44ac0622b91c3 (not found) couldn't be found in any key server >>>> so verification couldn't be performed >>>> >>>> >>>> On Tue, Apr 13, 2021 at 6:58 AM Søren Berg Glasius <soe...@glasius.dk> >>>> wrote: >>>> >>>>> +1 >>>>> >>>>> Med venlig hilsen / Best regards >>>>> >>>>> Søren Berg Glasius >>>>> >>>>> Sent from my phone, thus brief >>>>> >>>>> On Tue, Apr 13, 2021, 04:56 Paul King <pa...@asert.com.au> wrote: >>>>> >>>>>> Dear development community, >>>>>> >>>>>> I am happy to start the VOTE thread for a Groovy 4.0.0-alpha-3 >>>>>> release! >>>>>> >>>>>> This release includes 152 bug fixes/improvements as outlined in the >>>>>> changelog: >>>>>> >>>>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123&version=12349469 >>>>>> >>>>>> Tag: >>>>>> https://gitbox.apache.org/repos/asf?p=groovy.git;a=tag;h=refs/tags/GROOVY_4_0_0_ALPHA_3 >>>>>> Tag commit id: bdd219508feef5893372bf1b96ead893f2f2869b >>>>>> >>>>>> The artifacts to be voted on are located as follows (r47022). >>>>>> Source release: >>>>>> https://dist.apache.org/repos/dist/dev/groovy/4.0.0-alpha-3/sources >>>>>> Convenience binaries: >>>>>> https://dist.apache.org/repos/dist/dev/groovy/4.0.0-alpha-3/distribution >>>>>> >>>>>> Release artifacts are signed with a key from the following file: >>>>>> https://dist.apache.org/repos/dist/release/groovy/KEYS >>>>>> >>>>>> Please vote on releasing this package as Apache Groovy 4.0.0-alpha-3. >>>>>> >>>>>> Reminder on ASF release approval requirements for PMC members: >>>>>> http://www.apache.org/legal/release-policy.html#release-approval >>>>>> Hints on validating checksums/signatures (but replace md5sum with >>>>>> sha256sum): >>>>>> https://www.apache.org/info/verification.html >>>>>> >>>>>> The vote is open for the next 72 hours and passes if a majority of at >>>>>> least three +1 PMC votes are cast. >>>>>> >>>>>> [ ] +1 Release Apache Groovy 4.0.0-alpha-3 >>>>>> [ ] 0 I don't have a strong opinion about this, but I assume it's ok >>>>>> [ ] -1 Do not release Apache Groovy 4.0.0-alpha-3 because... >>>>>> >>>>>> Here is my vote: >>>>>> >>>>>> +1 (binding) >>>>>> >>>>>> >>>> >>>> -- >>>> Guillaume Laforge >>>> Apache Groovy committer >>>> Developer Advocate @ Google Cloud Platform >>>> >>>> Blog: http://glaforge.appspot.com/ >>>> Twitter: @glaforge <http://twitter.com/glaforge> >>>> >>>
