Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Update dependency sbt/sbt to v1.10.6 #44

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Update dependency sbt/sbt to v1.10.6 #44

wants to merge 1 commit into from
+1 −1

Conversation

renovate[bot]
Copy link
Contributor

@renovate renovate bot commented Sep 28, 2024 •
edited
Loading

This PR contains the following updates:

Package Update Change
sbt/sbt minor 1.7.1 -> 1.10.6

Release Notes

sbt/sbt (sbt/sbt)

v1.10.6: 1.10.6

Compare Source

change with compatibility implication

  • deps: lm-coursier 2.1.6, which updates Coursier 2.1.14 → 2.1.19 by @​eed3si9n in https://github.com/sbt/sbt/pull/7920

    This release changes the way "BOMs" or "dependency management" are handled during resolution, and allows users to add BOMs to a resolution. This changes the way versions are picked when BOMs or dependency management are involved, which has an impact on the resolution of libraries from many JVM ecosystems, such as Apache Spark, Springboot, Quarkus, etc.

bug fixes and updates

behind the scene

new contributors

Full Changelog: sbt/sbt@v1.10.5...v1.10.6

v1.10.5: 1.10.5

Compare Source

updates

behind the scene

Full Changelog: sbt/sbt@v1.10.4...v1.10.5

v1.10.4: 1.10.4

Compare Source

updates and bug fixes

behind the scene

Full Changelog: sbt/sbt@v1.10.3...v1.10.4

v1.10.3: 1.10.3

Compare Source

Protobuf with potential Denial of Service (CVE-2024-7254)

sbt 1.10.3 updates protobuf-java library to 3.25.5 to address CVE-2024-7254 / GHSA-735f-pc8j-v9w8, which states that while parsing unknown fields in the Protobuf Java library, a maliciously crafted message can cause a StackOverflow error. Given the nature of how Protobuf is used in Zinc as internal serialization, we think the impact of this issue is minimum. However, security software might still flag this to be an issue while using sbt or Zinc, so upgrade is advised. This issue was originally reported by @​gabrieljones and was fixed by Jerry Tan (@​Friendseeker) in zinc#1443.

@​adpi2 at Scala Center has also configured dependency graph submission to get security alerts in zinc#1448. sbt/sbt was configured by @​Friendseeker in https://github.com/sbt/sbt/pull/7746.

Reverting the invalidation of circular-dependent sources

sbt 1.10.3 reverts the initial invalidation of circular-dependent Scala source pairs.

There had been a series of incremental compiler bugs such as "Invalid superClass" and "value b is not a member of A" that would go away after clean. The root cause of these bugs were identified by @​smarter (https://github.com/sbt/zinc/issues/598#issuecomment-449028234) and @​Friendseeker to be partial compilation of circular-dependent sources where two sources A.scala and B.scala use some constructs from each other.

sbt 1.10.0 fixed this issue via https://github.com/sbt/zinc/pull/1284 by invalidating the circular-dependent pairs together. In other words, if A.scala was changed, it would immediately invalidate B.scala. It turns out, that people have been writing circular-dependent code, and this has resulted in multiple reports of Zinc's over-compilation (zinc#1420, zinc#1461). Given that the invalidation seems to affect the users more frequently than the original bug, we're going to revert the fix for now. We might bring this back with an opt-out flag later on. The revert was contributed by by Li Haoyi (@​lihaoyi) in https://github.com/sbt/zinc/pull/1462.

Improvement: ParallelGzipOutputStream

sbt 1.10.0 via https://github.com/sbt/zinc/pull/1326 added a new consistent (repeatable) formats for Analysis storage. As a minor optimization, the pull request also included an implementation of ParallelGzipOutputStream, which would reduce the generate file size by 20%, but with little time penalty. Unfortunately, however, we have observed in CI that that the scala.concurrent.Future-based implementation gets stuck in a deadlock. @​Ichoran and @​Friendseeker have contributed an alternative implementation that uses Java threads directly, which fixes the issue in https://github.com/sbt/zinc/pull/1466.

bug fixes and updates
behind the scene

Full Changelog: sbt/sbt@v1.10.2...v1.10.3

v1.10.2: 1.10.2

Compare Source

Changes with compatibility implications

Updates and bug fixes

Behind the scenes

New contributors

Full Changelog: sbt/sbt@v1.10.0...v1.10.2

v1.10.1: 1.10.1

Compare Source

bug fixes and updates

behind the scenes

Full Changelog: sbt/sbt@v1.10.0...v1.10.1

v1.10.0: 1.10.0

Compare Source

Changes with compatibility implications

  • For SIP-51 support, scalaVersion can no longer be a lower 2.13.x version number than its transitive depdencies. See below for details.
  • ConsistentAnalysisFormat is enabled by default. See below for details.
  • Updates lm-coursier-shaded to 2.1.4, which brings in Coursier 2.1.9 #​7513.
  • Updates Jsch to mwiede/jsch fork by @​azolotko in lm#436
  • Updates the Scala version used by sbt 1.x to 2.12.19 by @​SethTisue in #​7516.

SIP-51 Support for Scala 2.13 Evolution

Modern Scala 2.x has kept both forward and backward binary compatibility so a library compiled using Scala 2.13.12 can be used by an application compiled with Scala 2.13.11 etc, and vice versa. The forward compatibility restricts Scala 2.x from evolving during the patch releases, so in SIP-51 Lukas Rytz at Lightbend Scala Team proposed:

I propose to drop the forwards binary compatibility requirement that build tools enforce on the Scala 2.13 standard library. This will allow implementing performance optimizations of collection operations that are currently not possible. It also unblocks adding new classes and new members to existing classes in the standard library.

Lukas has also contributed changes to sbt 1.10.0 to enforce stricter scalaVersion. Starting sbt 1.10.0, when a Scala 2.13.x patch version newer than scalaVersion is found, it will fail the build as follows:

sbt:foo> run
[error] stack trace is suppressed; run last scalaInstance for the full output
[error] (scalaInstance) expected `foo/scalaVersion` to be "2.13.10" or later,
[error] but found "2.13.5"; upgrade scalaVerion to fix the build.
[error]
[error] to support backwards-only binary compatibility (SIP-51),
[error] the Scala 2.13 compiler cannot be older than scala-library on the
[error] dependency classpath.
[error] see `foo/evicted` to know why scala-library 2.13.10 is getting pulled in.

When you see the error message like above, you can fix this by updating the Scala version to the suggested version (e.g. 2.13.10):

ThisBuild / scalaVersion := "2.13.10"

Side note: Old timers might know that sbt 0.13.0 also introduced the idea of scala-library as a normal dependency. This created various confusions as developers expected scalaVersion, compiler version, and scala-library version as expected to align. With the hindsight, sbt 1.10.0 will continue to respect scalaVersion to be the source-of-truth, but will reject bad ones at build time.

This was contributed by Lukas Rytz in #​7480.

Zinc fixes

ConsistentAnalysisFormat: new Zinc Analysis serialization

sbt 1.10.0 adds a new Zinc serialization format that is faster and repeatable, unlike the current Protobuf-based serialization. Benchmark data based on scala-library + reflect + compiler:

Write time Read time File size
sbt Text 1002 ms 791 ms ~ 7102 kB
sbt Binary 654 ms 277 ms ~ 6182 kB
ConsistentBinary 157 ms 100 ms 3097 kB

Since Zinc Analysis is internal to sbt, sbt 1.10.0 will enable this format by default. The following setting can be used to opt-out:

Global / enableConsistentCompileAnalysis := false

This was contributed by Stefan Zeiger at Databricks in zinc#1326.

New CommandProgress API

sbt 1.10.0 adds a new CommandProgress API.

This was contributed by Iulian Dragos at Gradle Inc in #​7350.

Other updates

v1.9.9: 1.9.9

Compare Source

Bug fixes

Full Changelog: sbt/sbt@v1.9.8...v1.9.9

v1.9.8: 1.9.8

Compare Source

updates

Full Changelog: sbt/sbt@v1.9.7...v1.9.8

v1.9.7: 1.9.7

Compare Source

Highlights
  • sbt 1.9.7 updates its IO module to 1.9.7, which fixes parent path traversal vulnerability in IO.unzip. This was discovered and reported by Kenji Yoshida (@​xuwei-k), and fixed by @​eed3si9n in io#360.
Zip Slip (arbitrary file write) vulnerability

See GHSA-h9mw-grgx-2fhf for the most up to date information. This affects all sbt versions prior to 1.9.7.

Path traversal vulnerabilty was discovered in IO.unzip code. This is a very common vulnerability known as Zip Slip, and was found and fixed in plexus-archiver, Ant, etc.

Given a specially crafted zip or JAR file, IO.unzip allows writing of arbitrary file. The follow is an example of a malicious entry:

+2018-04-15 22:04:42 ..... 20 20 ../../../../../../root/.ssh/authorized_keys

When executed on some path with six levels, IO.unzip could then overwrite a file under /root/. sbt main uses IO.unzip only in pullRemoteCache and Resolvers.remote, however, many projects use IO.unzip(...) directly to implement custom tasks and tests.

Non-determinism from AutoPlugins loading

We've known that occasionally some builds non-deterministically flip-flops its behavior when a task or a setting is set by two independent AutoPlugins, i.e. two plugins that neither depends on the other.

sbt 1.9.7 attempts to fix non-determinism of plugin loading order.
This was contributed by @​eed3si9n in #​7404.

Other updates and fixes

v1.9.6: 1.9.6

Compare Source

bug fix

Full Changelog: sbt/sbt@v1.9.5...v1.9.6

v1.9.5: 1.9.5

Compare Source

Update: ⚠️ sbt 1.9.5 is broken, because it causes Scala compiler to generate wrong class names for anonymous class on lambda. While we investigate please refrain from publishing libraries with it.
https://github.com/scala/bug/issues/12868#issuecomment-1720848704

highlights

other updates

new contributors

Full Changelog: sbt/sbt@v1.9.4...v1.9.5

v1.9.4: 1.9.4

Compare Source

CVE-2022-46751

CVE-2022-46751 is a security vulnerability discovered in Apache Ivy, but found also in Coursier.

With coordination with Apache Foundation, Adrien Piquerez (@​adpi2) from Scala Center backported the fix to both our Ivy 2.3 fork and Coursier. sbt 1.9.4 updates them to the fixed versions.

Other updates

new contributors

Full Changelog: sbt/sbt@v1.9.3...v1.9.4

v1.9.3: 1.9.3

Compare Source

Actionable diagnostics (aka quickfix)

Actionable diagnostics, or quickfix, is an area in Scala tooling that's been getting attention since Chris Kipp presented it in the March 2023 Tooling Summit. Chris has written the roadmap and sent sbt/sbt#7242 that kickstarted the effort, but now there's been steady progress in Build Server Protocol, Dotty, Scala 2.13, IntelliJ, Zinc, etc. Metals 1.0.0, for example, is now capable of surfacing code actions as a quickfix.

sbt 1.9.3 adds a new interface called AnalysisCallback2 to relay code actions from the compiler(s) to Zinc's Analysis file. Future version of Scala 2.13.x (and hopefully Scala 3) will release with proper code actions, but as a demo I've implemented a code action for procedure syntax usages even on current Scala 2.13.11 with -deprecation flag.

This was contributed by Eugene Yokota (@​eed3si9n) in zinc#1226. Special thanks to @​lrytz for identifying this issue in zinc#1214.

other updates

Full Changelog: sbt/sbt@v1.9.2...v1.9.3

v1.9.2: 1.9.2

Compare Source

Fix

Full Changelog: sbt/sbt@v1.9.1...v1.9.2

v1.9.1: 1.9.1

Compare Source

Change to Scala CLA

sbt 1.9.1 is the first release of sbt after changing to Scala CLA in #​7306 etc. A number of contributors to sbt voiced concerns about donating our work to Lightbend after 2022, and Lightbend, Scala Center, and I agreed on changing the contributor license agreement such that the copyright would tranfer to Scala Center, a non-profit organization. sbt and its subcompoments, including Zinc, will remain available under Apache v2 license.

Updates
Behind the scene

new contributors

Full Changelog: sbt/sbt@v1.9.0...v1.9.1

v1.9.0: 1.9.0

Compare Source

Changes with compatibility implications
  • Deprecates IntegrationTest configuration. See below.
  • Updates underlying Coursier to 2.1.2 by @​eed3si9n.
Deprecation of IntegrationTest configuration

sbt 1.9.0 deprecates IntegrationTest configuration. (RFC-3 proposes to deprecate general use of configuration axis beyond Compile and Test, and this is the first installment of the change.)

The recommended migration path is to create a subproject named "integration", or "foo-integration" etc.

lazy val in

</details>

---

### Configuration

📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.

♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 **Ignore**: Close this PR and you won't be reminded about this update again.

---

 - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box

---

This PR was generated by [Mend Renovate](https://mend.io/renovate/). View the [repository job log](https://developer.mend.io/github/polystat/polystat-cli).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzOC45Ny4wIiwidXBkYXRlZEluVmVyIjoiMzkuMTkuMCIsInRhcmdldEJyYW5jaCI6Im1hc3RlciIsImxhYmVscyI6W119-->

@renovate renovate bot changed the title Update dependency sbt/sbt to v1.10.2 Update dependency sbt/sbt to v1.10.3 Oct 21, 2024
@renovate renovate bot changed the title Update dependency sbt/sbt to v1.10.3 Update dependency sbt/sbt to v1.10.4 Oct 28, 2024
@renovate renovate bot changed the title Update dependency sbt/sbt to v1.10.4 Update dependency sbt/sbt to v1.10.5 Nov 4, 2024
@renovate renovate bot changed the title Update dependency sbt/sbt to v1.10.5 Update dependency sbt/sbt to v1.10.6 Dec 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
0 participants