You are viewing a plain text version of this content. The canonical link for it is here.
Posted to legal-discuss@apache.org by "Vladimir Sitnikov (Jira)" <ji...@apache.org> on 2021/05/04 14:15:00 UTC

[jira] [Created] (LEGAL-570) Can gradle-wrapper.jar be included into "INCLUDING BUILD TOOLS" list?

Vladimir Sitnikov created LEGAL-570:
---------------------------------------

             Summary: 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
            Reporter: Vladimir Sitnikov


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 manually

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.

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
(v8.3.4#803005)

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