Debian Package Tracker
Register | Log in
Subscribe

gradle

Powerful build system for the JVM

Choose email to subscribe with

general
  • source: gradle (main)
  • version: 4.4.1-13
  • maintainer: Debian Java Maintainers (archive) (DMD)
  • uploaders: Kai-Chung Yan [DMD]
  • arch: all
  • std-ver: 4.5.1
  • VCS: Git (Browse, QA)
versions [more versions can be listed by madison] [old versions available from snapshot.debian.org]
[pool directory]
  • o-o-stable: 3.2.1-1
  • oldstable: 4.4.1-6
  • stable: 4.4.1-13
  • testing: 4.4.1-13
  • unstable: 4.4.1-13
versioned links
  • 3.2.1-1: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
  • 4.4.1-6: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
  • 4.4.1-13: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
binaries
  • gradle (6 bugs: 0, 4, 2, 0)
  • gradle-doc
  • libgradle-core-java (1 bugs: 0, 1, 0, 0)
  • libgradle-plugins-java (1 bugs: 0, 1, 0, 0)
action needed
Marked for autoremoval on 30 June due to nvidia-graphics-drivers-tesla-470: #1011146 high
Version 4.4.1-13 of gradle is marked for autoremoval from testing on Thu 30 Jun 2022. It depends (transitively) on nvidia-graphics-drivers-tesla-470, affected by #1011146. You should try to prevent the removal by fixing these RC bugs.
Created: 2022-05-24 Last update: 2022-05-24 21:40
A new upstream version is available: 7.4.2 high
A new upstream version 7.4.2 is available, you should consider packaging it.
Created: 2020-06-29 Last update: 2022-05-24 17:26
5 security issues in sid high

There are 5 open security issues in sid.

5 important issues:
  • CVE-2019-15052: The HTTP client in Gradle before 5.6 sends authentication credentials originally destined for the configured host. If that host returns a 30x redirect, Gradle also sends those credentials to all subsequent hosts that the request redirects to. This is similar to CVE-2018-1000007.
  • CVE-2019-16370: The PGP signing plugin in Gradle before 6.0 relies on the SHA-1 algorithm, which might allow an attacker to replace an artifact with a different one that has the same SHA-1 message digest, a related issue to CVE-2005-4900.
  • CVE-2021-29428: In Gradle before version 7.0, on Unix-like systems, the system temporary directory can be created with open permissions that allow multiple users to create and delete files within it. Gradle builds could be vulnerable to a local privilege escalation from an attacker quickly deleting and recreating files in the system temporary directory. This vulnerability impacted builds using precompiled script plugins written in Kotlin DSL and tests for Gradle plugins written using ProjectBuilder or TestKit. If you are on Windows or modern versions of macOS, you are not vulnerable. If you are on a Unix-like operating system with the "sticky" bit set on your system temporary directory, you are not vulnerable. The problem has been patched and released with Gradle 7.0. As a workaround, on Unix-like operating systems, ensure that the "sticky" bit is set. This only allows the original user (or root) to delete a file. If you are unable to change the permissions of the system temporary directory, you can move the Java temporary directory by setting the System Property `java.io.tmpdir`. The new path needs to limit permissions to the build user only. For additional details refer to the referenced GitHub Security Advisory.
  • CVE-2021-29429: In Gradle before version 7.0, files created with open permissions in the system temporary directory can allow an attacker to access information downloaded by Gradle. Some builds could be vulnerable to a local information disclosure. Remote files accessed through TextResourceFactory are downloaded into the system temporary directory first. Sensitive information contained in these files can be exposed to other local users on the same system. If you do not use the `TextResourceFactory` API, you are not vulnerable. As of Gradle 7.0, uses of the system temporary directory have been moved to the Gradle User Home directory. By default, this directory is restricted to the user running the build. As a workaround, set a more restrictive umask that removes read access to other users. When files are created in the system temporary directory, they will not be accessible to other users. If you are unable to change your system's umask, you can move the Java temporary directory by setting the System Property `java.io.tmpdir`. The new path needs to limit permissions to the build user only.
  • CVE-2021-32751: Gradle is a build tool with a focus on build automation. In versions prior to 7.2, start scripts generated by the `application` plugin and the `gradlew` script are both vulnerable to arbitrary code execution when an attacker is able to change environment variables for the user running the script. This may impact those who use `gradlew` on Unix-like systems or use the scripts generated by Gradle in thieir application on Unix-like systems. For this vulnerability to be exploitable, an attacker needs to be able to set the value of particular environment variables and have those environment variables be seen by the vulnerable scripts. This issue has been patched in Gradle 7.2 by removing the use of `eval` and requiring the use of the `bash` shell. There are a few workarounds available. For CI/CD systems using the Gradle build tool, one may ensure that untrusted users are unable to change environment variables for the user that executes `gradlew`. If one is unable to upgrade to Gradle 7.2, one may generate a new `gradlew` script with Gradle 7.2 and use it for older versions of Gradle. Fpplications using start scripts generated by Gradle, one may ensure that untrusted users are unable to change environment variables for the user that executes the start script. A vulnerable start script could be manually patched to remove the use of `eval` or the use of environment variables that affect the application's command-line. If the application is simple enough, one may be able to avoid the use of the start scripts by running the application directly with Java command.
Created: 2021-02-19 Last update: 2022-02-14 16:31
5 security issues in bookworm high

There are 5 open security issues in bookworm.

5 important issues:
  • CVE-2019-15052: The HTTP client in Gradle before 5.6 sends authentication credentials originally destined for the configured host. If that host returns a 30x redirect, Gradle also sends those credentials to all subsequent hosts that the request redirects to. This is similar to CVE-2018-1000007.
  • CVE-2019-16370: The PGP signing plugin in Gradle before 6.0 relies on the SHA-1 algorithm, which might allow an attacker to replace an artifact with a different one that has the same SHA-1 message digest, a related issue to CVE-2005-4900.
  • CVE-2021-29428: In Gradle before version 7.0, on Unix-like systems, the system temporary directory can be created with open permissions that allow multiple users to create and delete files within it. Gradle builds could be vulnerable to a local privilege escalation from an attacker quickly deleting and recreating files in the system temporary directory. This vulnerability impacted builds using precompiled script plugins written in Kotlin DSL and tests for Gradle plugins written using ProjectBuilder or TestKit. If you are on Windows or modern versions of macOS, you are not vulnerable. If you are on a Unix-like operating system with the "sticky" bit set on your system temporary directory, you are not vulnerable. The problem has been patched and released with Gradle 7.0. As a workaround, on Unix-like operating systems, ensure that the "sticky" bit is set. This only allows the original user (or root) to delete a file. If you are unable to change the permissions of the system temporary directory, you can move the Java temporary directory by setting the System Property `java.io.tmpdir`. The new path needs to limit permissions to the build user only. For additional details refer to the referenced GitHub Security Advisory.
  • CVE-2021-29429: In Gradle before version 7.0, files created with open permissions in the system temporary directory can allow an attacker to access information downloaded by Gradle. Some builds could be vulnerable to a local information disclosure. Remote files accessed through TextResourceFactory are downloaded into the system temporary directory first. Sensitive information contained in these files can be exposed to other local users on the same system. If you do not use the `TextResourceFactory` API, you are not vulnerable. As of Gradle 7.0, uses of the system temporary directory have been moved to the Gradle User Home directory. By default, this directory is restricted to the user running the build. As a workaround, set a more restrictive umask that removes read access to other users. When files are created in the system temporary directory, they will not be accessible to other users. If you are unable to change your system's umask, you can move the Java temporary directory by setting the System Property `java.io.tmpdir`. The new path needs to limit permissions to the build user only.
  • CVE-2021-32751: Gradle is a build tool with a focus on build automation. In versions prior to 7.2, start scripts generated by the `application` plugin and the `gradlew` script are both vulnerable to arbitrary code execution when an attacker is able to change environment variables for the user running the script. This may impact those who use `gradlew` on Unix-like systems or use the scripts generated by Gradle in thieir application on Unix-like systems. For this vulnerability to be exploitable, an attacker needs to be able to set the value of particular environment variables and have those environment variables be seen by the vulnerable scripts. This issue has been patched in Gradle 7.2 by removing the use of `eval` and requiring the use of the `bash` shell. There are a few workarounds available. For CI/CD systems using the Gradle build tool, one may ensure that untrusted users are unable to change environment variables for the user that executes `gradlew`. If one is unable to upgrade to Gradle 7.2, one may generate a new `gradlew` script with Gradle 7.2 and use it for older versions of Gradle. Fpplications using start scripts generated by Gradle, one may ensure that untrusted users are unable to change environment variables for the user that executes the start script. A vulnerable start script could be manually patched to remove the use of `eval` or the use of environment variables that affect the application's command-line. If the application is simple enough, one may be able to avoid the use of the start scripts by running the application directly with Java command.
Created: 2021-08-15 Last update: 2022-02-14 16:31
lintian reports 9 warnings high
Lintian reports 9 warnings about this package. You should make the package lintian clean getting rid of them.
Created: 2021-04-11 Last update: 2021-09-06 18:32
Depends on packages which need a new maintainer normal
The packages that gradle depends on which need a new maintainer are:
  • dh-exec (#851746)
    • Build-Depends: dh-exec
Created: 2019-11-22 Last update: 2022-05-24 21:37
Does not build reproducibly during testing normal
A package building reproducibly enables third parties to verify that the source matches the distributed binaries. It has been identified that this source package produced different results, failed to build or had other issues in a test environment. Please read about how to improve the situation!
Created: 2021-11-15 Last update: 2022-05-24 17:32
6 low-priority security issues in buster low

There are 6 open security issues in buster.

4 issues left for the package maintainer to handle:
  • CVE-2019-11065: (needs triaging) Gradle versions from 1.4 to 5.3.1 use an insecure HTTP URL to download dependencies when the built-in JavaScript or CoffeeScript Gradle plugins are used. Dependency artifacts could have been maliciously compromised by a MITM attack against the ajax.googleapis.com web site.
  • CVE-2019-15052: (needs triaging) The HTTP client in Gradle before 5.6 sends authentication credentials originally destined for the configured host. If that host returns a 30x redirect, Gradle also sends those credentials to all subsequent hosts that the request redirects to. This is similar to CVE-2018-1000007.
  • CVE-2021-29428: (needs triaging) In Gradle before version 7.0, on Unix-like systems, the system temporary directory can be created with open permissions that allow multiple users to create and delete files within it. Gradle builds could be vulnerable to a local privilege escalation from an attacker quickly deleting and recreating files in the system temporary directory. This vulnerability impacted builds using precompiled script plugins written in Kotlin DSL and tests for Gradle plugins written using ProjectBuilder or TestKit. If you are on Windows or modern versions of macOS, you are not vulnerable. If you are on a Unix-like operating system with the "sticky" bit set on your system temporary directory, you are not vulnerable. The problem has been patched and released with Gradle 7.0. As a workaround, on Unix-like operating systems, ensure that the "sticky" bit is set. This only allows the original user (or root) to delete a file. If you are unable to change the permissions of the system temporary directory, you can move the Java temporary directory by setting the System Property `java.io.tmpdir`. The new path needs to limit permissions to the build user only. For additional details refer to the referenced GitHub Security Advisory.
  • CVE-2021-29429: (needs triaging) In Gradle before version 7.0, files created with open permissions in the system temporary directory can allow an attacker to access information downloaded by Gradle. Some builds could be vulnerable to a local information disclosure. Remote files accessed through TextResourceFactory are downloaded into the system temporary directory first. Sensitive information contained in these files can be exposed to other local users on the same system. If you do not use the `TextResourceFactory` API, you are not vulnerable. As of Gradle 7.0, uses of the system temporary directory have been moved to the Gradle User Home directory. By default, this directory is restricted to the user running the build. As a workaround, set a more restrictive umask that removes read access to other users. When files are created in the system temporary directory, they will not be accessible to other users. If you are unable to change your system's umask, you can move the Java temporary directory by setting the System Property `java.io.tmpdir`. The new path needs to limit permissions to the build user only.

You can find information about how to handle these issues in the security team's documentation.

2 ignored issues:
  • CVE-2019-16370: The PGP signing plugin in Gradle before 6.0 relies on the SHA-1 algorithm, which might allow an attacker to replace an artifact with a different one that has the same SHA-1 message digest, a related issue to CVE-2005-4900.
  • CVE-2021-32751: Gradle is a build tool with a focus on build automation. In versions prior to 7.2, start scripts generated by the `application` plugin and the `gradlew` script are both vulnerable to arbitrary code execution when an attacker is able to change environment variables for the user running the script. This may impact those who use `gradlew` on Unix-like systems or use the scripts generated by Gradle in thieir application on Unix-like systems. For this vulnerability to be exploitable, an attacker needs to be able to set the value of particular environment variables and have those environment variables be seen by the vulnerable scripts. This issue has been patched in Gradle 7.2 by removing the use of `eval` and requiring the use of the `bash` shell. There are a few workarounds available. For CI/CD systems using the Gradle build tool, one may ensure that untrusted users are unable to change environment variables for the user that executes `gradlew`. If one is unable to upgrade to Gradle 7.2, one may generate a new `gradlew` script with Gradle 7.2 and use it for older versions of Gradle. Fpplications using start scripts generated by Gradle, one may ensure that untrusted users are unable to change environment variables for the user that executes the start script. A vulnerable start script could be manually patched to remove the use of `eval` or the use of environment variables that affect the application's command-line. If the application is simple enough, one may be able to avoid the use of the start scripts by running the application directly with Java command.
Created: 2021-02-19 Last update: 2022-02-14 16:31
5 low-priority security issues in bullseye low

There are 5 open security issues in bullseye.

3 issues left for the package maintainer to handle:
  • CVE-2019-15052: (needs triaging) The HTTP client in Gradle before 5.6 sends authentication credentials originally destined for the configured host. If that host returns a 30x redirect, Gradle also sends those credentials to all subsequent hosts that the request redirects to. This is similar to CVE-2018-1000007.
  • CVE-2021-29428: (needs triaging) In Gradle before version 7.0, on Unix-like systems, the system temporary directory can be created with open permissions that allow multiple users to create and delete files within it. Gradle builds could be vulnerable to a local privilege escalation from an attacker quickly deleting and recreating files in the system temporary directory. This vulnerability impacted builds using precompiled script plugins written in Kotlin DSL and tests for Gradle plugins written using ProjectBuilder or TestKit. If you are on Windows or modern versions of macOS, you are not vulnerable. If you are on a Unix-like operating system with the "sticky" bit set on your system temporary directory, you are not vulnerable. The problem has been patched and released with Gradle 7.0. As a workaround, on Unix-like operating systems, ensure that the "sticky" bit is set. This only allows the original user (or root) to delete a file. If you are unable to change the permissions of the system temporary directory, you can move the Java temporary directory by setting the System Property `java.io.tmpdir`. The new path needs to limit permissions to the build user only. For additional details refer to the referenced GitHub Security Advisory.
  • CVE-2021-29429: (needs triaging) In Gradle before version 7.0, files created with open permissions in the system temporary directory can allow an attacker to access information downloaded by Gradle. Some builds could be vulnerable to a local information disclosure. Remote files accessed through TextResourceFactory are downloaded into the system temporary directory first. Sensitive information contained in these files can be exposed to other local users on the same system. If you do not use the `TextResourceFactory` API, you are not vulnerable. As of Gradle 7.0, uses of the system temporary directory have been moved to the Gradle User Home directory. By default, this directory is restricted to the user running the build. As a workaround, set a more restrictive umask that removes read access to other users. When files are created in the system temporary directory, they will not be accessible to other users. If you are unable to change your system's umask, you can move the Java temporary directory by setting the System Property `java.io.tmpdir`. The new path needs to limit permissions to the build user only.

You can find information about how to handle these issues in the security team's documentation.

2 ignored issues:
  • CVE-2019-16370: The PGP signing plugin in Gradle before 6.0 relies on the SHA-1 algorithm, which might allow an attacker to replace an artifact with a different one that has the same SHA-1 message digest, a related issue to CVE-2005-4900.
  • CVE-2021-32751: Gradle is a build tool with a focus on build automation. In versions prior to 7.2, start scripts generated by the `application` plugin and the `gradlew` script are both vulnerable to arbitrary code execution when an attacker is able to change environment variables for the user running the script. This may impact those who use `gradlew` on Unix-like systems or use the scripts generated by Gradle in thieir application on Unix-like systems. For this vulnerability to be exploitable, an attacker needs to be able to set the value of particular environment variables and have those environment variables be seen by the vulnerable scripts. This issue has been patched in Gradle 7.2 by removing the use of `eval` and requiring the use of the `bash` shell. There are a few workarounds available. For CI/CD systems using the Gradle build tool, one may ensure that untrusted users are unable to change environment variables for the user that executes `gradlew`. If one is unable to upgrade to Gradle 7.2, one may generate a new `gradlew` script with Gradle 7.2 and use it for older versions of Gradle. Fpplications using start scripts generated by Gradle, one may ensure that untrusted users are unable to change environment variables for the user that executes the start script. A vulnerable start script could be manually patched to remove the use of `eval` or the use of environment variables that affect the application's command-line. If the application is simple enough, one may be able to avoid the use of the start scripts by running the application directly with Java command.
Created: 2021-08-14 Last update: 2022-02-14 16:31
Standards version of the package is outdated. wishlist
The package should be updated to follow the last version of Debian Policy (Standards-Version 4.6.1 instead of 4.5.1).
Created: 2021-08-18 Last update: 2022-05-11 23:24
news
[rss feed]
  • [2021-02-21] gradle 4.4.1-13 MIGRATED to testing (Debian testing watch)
  • [2021-02-11] Accepted gradle 4.4.1-13 (source) into unstable (Emmanuel Bourg)
  • [2020-08-26] gradle 4.4.1-12 MIGRATED to testing (Debian testing watch)
  • [2020-08-20] Accepted gradle 4.4.1-12 (source) into unstable (Andrej Shadura) (signed by: Andrew Shadura)
  • [2020-06-02] gradle 4.4.1-11 MIGRATED to testing (Debian testing watch)
  • [2020-05-27] Accepted gradle 4.4.1-11 (source) into unstable (Emmanuel Bourg)
  • [2019-12-15] gradle 4.4.1-10 MIGRATED to testing (Debian testing watch)
  • [2019-12-10] Accepted gradle 4.4.1-10 (source) into unstable (Hans-Christoph Steiner)
  • [2019-12-09] Accepted gradle 4.4.1-9 (source) into unstable (Hans-Christoph Steiner)
  • [2019-08-10] gradle 4.4.1-8 MIGRATED to testing (Debian testing watch)
  • [2019-08-05] Accepted gradle 4.4.1-8 (source) into unstable (Saif Abdul Cassim) (signed by: Emmanuel Bourg)
  • [2019-07-09] gradle 4.4.1-7 MIGRATED to testing (Debian testing watch)
  • [2019-06-27] Accepted gradle 4.4.1-7 (source) into unstable (Emmanuel Bourg)
  • [2019-06-26] gradle 4.4.1-6 MIGRATED to testing (Debian testing watch)
  • [2019-06-21] Accepted gradle 4.4.1-6 (source) into unstable (Emmanuel Bourg)
  • [2019-03-09] gradle 4.4.1-5 MIGRATED to testing (Debian testing watch)
  • [2019-02-26] Accepted gradle 4.4.1-5 (source) into unstable (Andrej Shadura)
  • [2019-01-20] gradle 4.4.1-4 MIGRATED to testing (Debian testing watch)
  • [2019-01-15] Accepted gradle 4.4.1-4 (source) into unstable (Emmanuel Bourg)
  • [2018-12-04] gradle 4.4.1-3 MIGRATED to testing (Debian testing watch)
  • [2018-11-29] Accepted gradle 4.4.1-3 (source) into unstable (tony mancill)
  • [2018-11-14] gradle 4.4.1-2 MIGRATED to testing (Debian testing watch)
  • [2018-11-09] Accepted gradle 4.4.1-2 (source) into unstable (Tiago Stürmer Daitx) (signed by: Emmanuel Bourg)
  • [2018-10-22] gradle 4.4.1-1 MIGRATED to testing (Debian testing watch)
  • [2018-10-03] Accepted gradle 4.4.1-1 (source) into unstable (Emmanuel Bourg)
  • [2018-10-01] Accepted gradle 4.4-3 (source) into unstable (Emmanuel Bourg)
  • [2018-09-17] Accepted gradle 4.4-2 (source) into unstable (Emmanuel Bourg)
  • [2018-09-16] Accepted gradle 3.4.1-8 (source) into unstable (Emmanuel Bourg)
  • [2018-05-18] Accepted gradle 4.4-1 (source) into experimental (Kai-Chung Yan (殷啟聰)) (signed by: Kai-Chung Yan)
  • [2018-05-14] gradle 3.4.1-7 MIGRATED to testing (Debian testing watch)
  • 1
  • 2
bugs [bug history graph]
  • all: 14 15
  • RC: 0
  • I&N: 10
  • M&W: 4 5
  • F&P: 0
  • patch: 0
links
  • homepage
  • lintian (0, 9)
  • buildd: logs, clang, reproducibility
  • popcon
  • browse source code
  • edit tags
  • other distros
  • security tracker
  • screenshots
ubuntu Ubuntu logo [Information about Ubuntu for Debian Developers]
  • version: 4.4.1-13
  • 4 bugs

Debian Package Tracker — Copyright 2013-2018 The Distro Tracker Developers
Report problems to the tracker.debian.org pseudo-package in the Debian BTS.
Documentation — Bugs — Git Repository — Contributing