Update to Gradle 5.6

[ZacSweers]

Quick followup from #428. Hoping this allows removing the guava classpath dependency as well, will test

[ZacSweers]

I suspect the new failure is due to the restricted classpath changes that kicked in with 5.6. Will investigate

[nedtwigg]

I just cleared the travis cache and restarted the build. If it works now, then the problem was #429 all along. It seems that the newer gradle versions are less friendly to our TestProvisioner.

[ZacSweers]

Looks like that's the case!

…

On Sun, Aug 18, 2019 at 7:38 PM Ned Twigg ***@***.***> wrote: I just cleared the travis cache and restarted the build. If it works now, then the problem was #429 <#429> all along. It seems that the newer gradle versions are less friendly to our TestProvisioner. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#433?email_source=notifications&email_token=AAKMJPXPCYI7CY3R5U7766TQFIBSJA5CNFSM4IL3JPJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4RQWPY#issuecomment-522390335>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAKMJPUV6SE4J2T2VPOHFCDQFIBSJANCNFSM4IL3JPJQ> .

[JLLeitschuh]

@nedtwigg would you be so kind as to implement a policy to check the SHA256 checksum of all of the gradle-wrapper.jar files that get contributed externally?

Since the gradle-wrapper.jar files are big blobs of binary, there is no way to check that they are valid & not maliciously compromised.

Here's the guide to checking the SHA256 checksums:
https://docs.gradle.org/current/userguide/gradle_wrapper.html#wrapper_checksum_verification

@ZacSweers, please don't take this request personally, this is fundamentally a security of the supply chain thing.

[nedtwigg]

Roger @JLLeitschuh, thanks for the suggestion. It would be cool if there were a service like this:

https://gradle.org/gradle-wrapper-is-secure/github/diffplug/spotless/pull/433

Which then shows a checkmark if the wrapper's checksum matches. Maybe even a https://shields.io/ badge that users could put into the README, so that if a bad gradle.wrapper ever got merged to master, it would show up there. In the meantime, I'll keep this in mind when merging PRs of this sort for my opensource projects.

[ZacSweers]

Another idea you could do is run the Gradle wrapper task on CI and fail the built if there's a dirty git state after (use git porcelain) Just add this to before_install in the Travis yml ``` - ./gradle wrapper (with version configurations) - if [ ! -z "$(git status --porcelain)" ]; then echo "Gradle files changed after running wrapper when they should be unchanged. Please investigate"; exit 1; fi ``` It's not as robust as checking a checksum but it's better than nothing as a start

[nedtwigg]

A couple things:

• I verified the checksum manually
• If gradle adopts an official "autoverify the gradle jar this way" I'd be happy to adopt it, but exploring the solution space is not high on my priority list
• It shouldn't matter whether we cache the ~/.gradle/wrapper folder, but apparently it does.