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.

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

Consider bumping MSRV #1750

Open
tnull opened this issue Nov 29, 2024 · 4 comments
Open

Consider bumping MSRV #1750

tnull opened this issue Nov 29, 2024 · 4 comments
Labels
ci dependencies Pull requests that update a dependency file

Comments

@tnull
Copy link
Contributor

tnull commented Nov 29, 2024

Unfortunately rustls recently decided to bump their MSRV to 1.71 (see rustls/rustls#2239). While they now at least intermittently reverted the MSRV and pushed out version 0.23.19 that fixes RUSTSEC-2024-0399 without at bumping MSRV at the same time, they are commited to re-bump their MSRV to 1.71 with the follow-up (i.e., 0.23.20) release.

Given how security-critical TLS libraries are, I don't think an MSRV of 1.63 for the dependent crates can be maintained through pinning, as users might miss out on critical security patches. That puts any dependent crates in a tough spot, and essentially forces them to bump their MSRV to at least 1.71, too.

In LDK we're probably going to introduce a separate MSRV just for the lightning-transaction-sync crate (currently depending on rustls), which will have further consequences, such as bumping MSRV on LDK Node and other dependent projects down the dependency chain. We might also re-evaluate whether native-tls can be made to work on Android/Kotlin bindings.

I'm opening this discussion topic as BDK probably also needs to act on this in one form or another, i.e., either bumping MSRV in general, or introducing a separate MSRV for anything depending on rustls.

It probably would also make sense to figure out a common MSRV target for the affected crates to at least somewhat maintain a standard that users can lean on here. It might just be 1.71, but then again rustls's newly defined MSRV policy would 'allow' (not that they seem to care too much in general) them to bump up to 1.73 currently.

@LagginTimes
Copy link
Contributor

LagginTimes commented Dec 1, 2024

Historically, it appears that BDK's MSRV has been aligned with the version of rustc available in Debian stable (see: #331 and https://tracker.debian.org/pkg/rustc), which as of 12/1/2024 is still 1.63. It looks like this alignment is still maintained. Afaik, it should not be overly complicated to bump the MSRV to 1.71 or 1.73 in order to benefit from future security patches.

@tnull
Copy link
Contributor Author

tnull commented Dec 2, 2024

Historically, it appears that BDK's MSRV has been aligned with the version of rustc available in Debian stable (see: #331 and https://tracker.debian.org/pkg/rustc), which as of 12/1/2024 is still 1.63. It looks like this alignment is still maintained.

Yes, and Debian stable would continue to be a great MSRV target, IMO. That is, if upstream crates wouldn't effectively take the decision out of our hands.

@evanlinjin
Copy link
Member

+1 on this. This will decrease the maintenance burden on MSRV.

@notmandatory notmandatory added this to BDK Dec 6, 2024
@notmandatory notmandatory added the discussion There's still a discussion ongoing label Dec 6, 2024
@notmandatory notmandatory moved this to Discussion in BDK Dec 6, 2024
@notmandatory notmandatory added ci dependencies Pull requests that update a dependency file and removed discussion There's still a discussion ongoing labels Dec 6, 2024
@tnull
Copy link
Contributor Author

tnull commented Dec 12, 2024

This just became relevant again as rustls 0.23.20 was released, bumping MSRV to 1.71.0.

I'd appreciate if we could work out a new common MSRV target for projects depending on it.

(cc @notmandatory)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ci dependencies Pull requests that update a dependency file
Projects
Status: Discussion
Development

No branches or pull requests

4 participants