www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Tzvetanov Grigorov (Jira)" <j...@apache.org>
Subject [jira] [Commented] (LEGAL-570) Can gradle-wrapper.jar be included into "INCLUDING BUILD TOOLS" list?
Date Mon, 10 May 2021 11:30:00 GMT

    [ https://issues.apache.org/jira/browse/LEGAL-570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17341842#comment-17341842

Martin Tzvetanov Grigorov commented on LEGAL-570:

OK. I see your new comment.

This sounds like an issue that the Gradle team should address: instead of offering gradle.zip
that a user has to unzip locally and add to $PATH they should promote the gradle-wrapper way
and explain something like "You should put this in your project root folder/.gradle/...".

I see no reasons to make exceptions for this case.

> Can gradle-wrapper.jar be included into "INCLUDING BUILD TOOLS" list?
> ---------------------------------------------------------------------
>                 Key: LEGAL-570
>                 URL: https://issues.apache.org/jira/browse/LEGAL-570
>             Project: Legal Discuss
>          Issue Type: Question
>          Components: Policy Question
>            Reporter: Vladimir Sitnikov
>            Priority: Major
> Gradle build system has gradle-wrapper.jar which greately improves security and consistency
of the build:
> 1) It ensures the user uses the proper build system version, so they don't have accidental
miscompilations caused by the usage of the wrong build system.
> 2) It automatically verifies the checksum of the received build system, so users don't
accidentally launch a malicious build system.
> However, in order to do that in a consistent fashion, the retrieval and verification
of the build system are implemented as a small jar (~50-60KiB) which rarely changes itself.
> I suggest that gradle-wrapper.jar should be explicitly allowed in the source releases,
so the ones who verify the release can build the artifacts on their machine without figuring
the proper Gradle version for the project in question.
> Note: gradle-wrapper.jar can easily be verified (e.g. via Apache RAT) since well-known
checksums for gradle-wrapper.jar are published by Gradle (see https://services.gradle.org/versions/all
> The section on build systems already exists: http://www.apache.org/legal/resolved.html#build-tools
> ---
> I am aware of https://issues.apache.org/jira/browse/LEGAL-288, however, I believe, the
team was *not aware* that *the case is much harder* than "never put jars in source release".
> In other words, there are two alternatives:
> a) The project keeps gradle-wrapper.jar in the source release. That simplifies release
testing, and it keeps the build secure at the same time. At any point in time, user could
remove gradle-wrapper.jar from the source release and download the appropriate Gradle version
> b) The project removes gradle-wrapper.jar from the source release. It would force everybody
to download Gradle manually which adds lots of human errors. For instance, they might download
wrong Gradle version. They might fail to verify the received binary. They would have to manage
multiple Gradle versions since every project or branch might require different versions.
> That would raise the barrier for building the project, and it would reduce the number
of release votes since people would refrain doing the manual steps to figure out the proper
build system for the given source release package. 
> Just in case, it is non-trivial to implement a cross-platform script that downloads the
appropriate binaries in a secure manner: https://issues.apache.org/jira/browse/LEGAL-288?focusedCommentId=17318340&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17318340
> ----
> Of course, I realize it would be great if Gradle provided a way to download and verify
build system consistency without relying on gradle-wrapper.jar file.
> There's a tracking issue for the feature: https://github.com/gradle/gradle/issues/11816.
> However, the implementation might require non-trivial efforts from Gradle (including
changes to release process and testing, especially for unusual platforms), that is why I suggest
gradle-wrapper.jar should be allowed in the source releases until a better alternative appears.
> ----
> Apache Maven has its own maven-wrapper.jar, however, it is less secure, so I would like
to keep this issue for Gradle only.

This message was sent by Atlassian Jira

To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org

View raw message