Uploaded image for project: 'Legal Discuss'
  1. Legal Discuss
  2. LEGAL-570

Can gradle-wrapper.jar be included into "INCLUDING BUILD TOOLS" list?

    XMLWordPrintableJSON

Details

    • Question
    • Status: Closed
    • Major
    • Resolution: Fixed
    • Policy Question
    • None

    Description

      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 three 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.
      That would raise the barrier for building the project, and it would reduce the number of release votes since people would refrain from 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

      c) David Jencks. There might be a source package without gradle-wrapper.jar, and a second package with the same sources + gradle-wrapper.jar. The first one definitely satisfies "source package" terms, and the second one might be treated as a "convenience binary". The drawbacks of such an approach are:

      • A separate set of instructions would still be needed to clarify the way "build from source package" process works
      • Build and release process would be more complicated since it would require building similar yet slightly different archives
      • Twice as many checksums and PGP signatures to verify
      • Testing the source package would still be non-trivial. One would still want to verify if building "source package" works, and they would have to follow manual steps
      • The users of the source package would be exposed to supply chain attacks as they might forget to verify their Gradle binary :-/

      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.

      Attachments

        Issue Links

          Activity

            People

              Unassigned Unassigned
              vladimirsitnikov Vladimir Sitnikov
              Votes:
              2 Vote for this issue
              Watchers:
              19 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: