Rust Blog

Announcing Rust 1.68.2

2023-03-28T00:00:00+00:00

The Rust team has published a new point release of Rust, 1.68.2. Rust is a programming language that is empowering everyone to build reliable and efficient software.

If you have a previous version of Rust installed via rustup, you can get 1.68.2 with:

rustup update stable

If you don't have it already, you can get rustup from the appropriate page on our website, and check out the detailed release notes for 1.68.2 on GitHub.

What's in 1.68.2 stable

Rust 1.68.2 addresses GitHub's recent rotation of their RSA SSH host key, which happened on March 24th 2023 after their previous key accidentally leaked:

GitHub's RSA key bundled in Cargo has been updated, to ensure systems that haven't interacted with GitHub yet won't connect trusting the leaked key.
The leaked key has been hardcoded as revoked in Cargo, to ensure the key won't be used by Cargo even on systems that still trust the key.

Support for @revoked entries in .ssh/known_hosts (along with a better error message when the unsupported @cert-authority entries are used) is also included in Rust 1.68.2, as that change was a pre-requisite for backporting the hardcoded revocation.

If you cannot upgrade to Rust 1.68.2, we recommend following GitHub's instructions on updating the trusted keys in your system. Note that the keys bundled in Cargo are only used if no trusted key for github.com is found on the system.

Contributors to 1.68.2

Many people came together to create Rust 1.68.2. We couldn't have done it without all of you. Thanks!

Announcing Rust 1.68.1

2023-03-23T00:00:00+00:00

The Rust team has published a new point release of Rust, 1.68.1. Rust is a programming language that is empowering everyone to build reliable and efficient software.

If you have a previous version of Rust installed via rustup, you can get 1.68.1 with:

rustup update stable

If you don't have it already, you can get rustup from the appropriate page on our website, and check out the detailed release notes for 1.68.1 on GitHub.

What's in 1.68.1 stable

Rust 1.68.1 stable primarily contains a change to how Rust's CI builds the Windows MSVC compiler, no longer enabling LTO for the Rust code. This led to a miscompilation that the Rust team is debugging, but in the meantime we're reverting the change to enable LTO.

This is currently believed to have no effect on wider usage of ThinLTO. The Rust compiler used an unstable flag as part of the build process to enable ThinLTO despite compiling to a dylib.

There are a few other regression fixes included in the release:

Fix building the compiler with --enable-local-rust
Treat $prefix-clang as clang in linker detection code
Fix a panic in the compiler

Contributors to 1.68.1

Many people came together to create Rust 1.68.1. We couldn't have done it without all of you. Thanks!

Announcing Rust 1.68.0

2023-03-09T00:00:00+00:00

The Rust team is happy to announce a new version of Rust, 1.68.0. Rust is a programming language empowering everyone to build reliable and efficient software.

If you have a previous version of Rust installed via rustup, you can get 1.68.0 with:

rustup update stable

If you don't have it already, you can get rustup from the appropriate page on our website, and check out the detailed release notes for 1.68.0 on GitHub.

If you'd like to help us out by testing future releases, you might consider updating locally to use the beta channel (rustup default beta) or the nightly channel (rustup default nightly). Please report any bugs you might come across!

What's in 1.68.0 stable

Cargo's sparse protocol

Cargo's "sparse" registry protocol has been stabilized for reading the index of crates, along with infrastructure at https://index.crates.io/ for those published in the primary crates.io registry. The prior git protocol (which is still the default) clones a repository that indexes all crates available in the registry, but this has started to hit scaling limitations, with noticeable delays while updating that repository. The new protocol should provide a significant performance improvement when accessing crates.io, as it will only download information about the subset of crates that you actually use.

To use the sparse protocol with crates.io, set the environment variable CARGO_REGISTRIES_CRATES_IO_PROTOCOL=sparse, or edit your .cargo/config.toml file to add:

[registries.crates-io]
protocol = "sparse"

The sparse protocol is currently planned to become the default for crates.io in the 1.70.0 release in a few months. For more information, please see the prior announcement on the Inside Rust Blog, as well as RFC 2789 and the current documentation in the Cargo Book.

Local `Pin` construction

The new pin! macro constructs a Pin<&mut T> from a T expression, anonymously captured in local state. This is often called stack-pinning, but that "stack" could also be the captured state of an async fn or block. This macro is similar to some crates, like tokio::pin!, but the standard library can take advantage of Pin internals and temporary lifetime extension for a more expression-like macro.

/// Runs a future to completion.
fn block_on<F: Future>(future: F) -> F::Output {
    let waker_that_unparks_thread = todo!();
    let mut cx = Context::from_waker(&waker_that_unparks_thread);
    // Pin the future so it can be polled.
    let mut pinned_future = pin!(future);
    loop {
        match pinned_future.as_mut().poll(&mut cx) {
            Poll::Pending => thread::park(),
            Poll::Ready(result) => return result,
        }
    }
}

In this example, the original future will be moved into a temporary local, referenced by the new pinned_future with type Pin<&mut F>, and that pin is subject to the normal borrow checker to make sure it can't outlive that local.

Default `alloc` error handler

When allocation fails in Rust, APIs like Box::new and Vec::push have no way to indicate that failure, so some divergent execution path needs to be taken. When using the std crate, the program will print to stderr and abort. As of Rust 1.68.0, binaries which include std will continue to have this behavior. Binaries which do not include std, only including alloc, will now panic! on allocation failure, which may be further adjusted via a #[panic_handler] if desired.

In the future, it's likely that the behavior for std will also be changed to match that of alloc-only binaries.

These APIs are now stable in const contexts:

VecDeque::new

Other changes

As previously announced, Android platform support in Rust is now targeting NDK r25, which corresponds to a minimum supported API level of 19 (KitKat).

Check out everything that changed in Rust, Cargo, and Clippy.

Contributors to 1.68.0

Many people came together to create Rust 1.68.0. We couldn't have done it without all of you. Thanks!

Announcing Rust 1.67.1

2023-02-09T00:00:00+00:00

The Rust team has published a new point release of Rust, 1.67.1. Rust is a programming language that is empowering everyone to build reliable and efficient software.

If you have a previous version of Rust installed via rustup, you can get 1.67.1 with:

rustup update stable

If you don't have it already, you can get rustup from the appropriate page on our website, and check out the detailed release notes for 1.67.1 on GitHub.

What's in 1.67.1 stable

Rust 1.67.1 fixes a regression for projects that link to thin archives (.a files that reference external .o objects). The new archive writer in 1.67.0 could not read thin archives as inputs, leading to the error "Unsupported archive identifier." The compiler now uses LLVM's archive writer again, until that format is supported in the new code.

Additionally, the clippy style lint uninlined_format_args is temporarily downgraded to pedantic -- allowed by default. While the compiler has supported this format since Rust 1.58, rust-analyzer does not support it yet, so it's not necessarily good to use that style everywhere possible.

The final change is a soundness fix in Rust's own bootstrap code. This had no known problematic uses, but it did raise an error when bootstrap was compiled with 1.67 itself, rather than the prior 1.66 release as usual.

Contributors to 1.67.1

Many people came together to create Rust 1.67.1. We couldn't have done it without all of you. Thanks!

Announcing Rustup 1.25.2

2023-02-01T00:00:00+00:00

The rustup working group is announcing the release of rustup version 1.25.2. Rustup is the recommended tool to install Rust, a programming language that is empowering everyone to build reliable and efficient software.

If you have a previous version of rustup installed, getting rustup 1.25.2 is as easy as stopping any programs which may be using Rustup (e.g. closing your IDE) and running:

rustup self update

Rustup will also automatically update itself at the end of a normal toolchain update:

rustup update

If you don't have it already, you can get rustup from the appropriate page on our website.

What's new in rustup 1.25.2

This version of rustup fixes a warning incorrectly saying that signature verification failed for Rust releases. The warning was due to a dependency of Rustup including a time-based check preventing the use of SHA-1 from February 1st, 2023 onwards.

Unfortunately Rust's release signing key uses SHA-1 to sign its subkeys, which resulted in all signatures being marked as invalid. Rustup 1.25.2 temporarily fixes the problem by allowing again the use of SHA-1.

Why is signature verification failure only a warning?

Signature verification is currently an experimental and incomplete feature included in rustup, as it's still missing crucial features like key rotation. Until the feature is complete and ready for use, its outcomes are only displayed as warnings without a way to turn them into errors.

This is done to avoid potentially breaking installations of rustup. Signature verification will error out on failure only after the design and implementation of the feature will be finished.

Thanks

Thanks again to all the contributors who made rustup 1.25.2 possible!

Daniel Silverstone (kinnison)
Pietro Albini (pietroalbini)

Announcing Rust 1.67.0

2023-01-26T00:00:00+00:00

The Rust team is happy to announce a new version of Rust, 1.67.0. Rust is a programming language empowering everyone to build reliable and efficient software.

If you have a previous version of Rust installed via rustup, you can get 1.67.0 with:

rustup update stable

If you don't have it already, you can get rustup from the appropriate page on our website, and check out the detailed release notes for 1.67.0 on GitHub.

What's in 1.67.0 stable

`#[must_use]` effective on `async fn`

async functions annotated with #[must_use] now apply that attribute to the output of the returned impl Future. The Future trait itself is already annotated with #[must_use], so all types implementing Future are automatically #[must_use], which meant that previously there was no way to indicate that the output of the Future is itself significant and should be used in some way.

With 1.67, the compiler will now warn if the output isn't used in some way.

#[must_use]
async fn bar() -> u32 { 0 }

async fn caller() {
    bar().await;
}

warning: unused output of future returned by `bar` that must be used
 --> src/lib.rs:5:5
  |
5 |     bar().await;
  |     ^^^^^^^^^^^
  |
  = note: `#[warn(unused_must_use)]` on by default

`std::sync::mpsc` implementation updated

Rust's standard library has had a multi-producer, single-consumer channel since before 1.0, but in this release the implementation is switched out to be based on crossbeam-channel. This release contains no API changes, but the new implementation fixes a number of bugs and improves the performance and maintainability of the implementation.

Users should not notice any significant changes in behavior as of this release.

Stabilized APIs

{integer}::checked_ilog
{integer}::checked_ilog2
{integer}::checked_ilog10
{integer}::ilog
{integer}::ilog2
{integer}::ilog10
NonZeroU*::ilog2
NonZeroU*::ilog10
NonZero*::BITS

These APIs are now stable in const contexts:

char::from_u32
char::from_digit
char::to_digit
core::char::from_u32
core::char::from_digit

Check out everything that changed in Rust, Cargo, and Clippy.

Contributors to 1.67.0

Many people came together to create Rust 1.67.0. We couldn't have done it without all of you. Thanks!

Officially announcing the types team

2023-01-20T00:00:00+00:00

Oh hey, it's another new team announcement. But I will admit: if you follow the RFCs repository, the Rust zulip, or were particularly observant on the GATs stabilization announcement post, then this might not be a surprise for you. In fact, this "new" team was officially established at the end of May last year.

There are a few reasons why we're sharing this post now (as opposed to months before or...never). First, the team finished a three day in-person/hybrid meetup at the beginning of December and we'd like to share the purpose and outcomes of that meeting. Second, posting this announcement now is just around 7 months of activity and we'd love to share what we've accomplished within this time. Lastly, as we enter into the new year of 2023, it's a great time to share a bit of where we expect to head in this year and beyond.

Background - How did we get here?

Rust has grown significantly in the last several years, in many metrics: users, contributors, features, tooling, documentation, and more. As it has grown, the list of things people want to do with it has grown just as quickly. On top of powerful and ergonomic features, the demand for powerful tools such as IDEs or learning tools for the language has become more and more apparent. New compilers (frontend and backend) are being written. And, to top it off, we want Rust to continue to maintain one of its core design principles: safety.

All of these points highlights some key needs: to be able to know how the Rust language should work, to be able to extend the language and compiler with new features in a relatively painless way, to be able to hook into the compiler and be able to query important information about programs, and finally to be able to maintain the language and compiler in an amenable and robust way. Over the years, considerable effort has been put into these needs, but we haven't quite achieved these key requirements.

To extend a little, and put some numbers to paper, there are currently around 220 open tracking issues for language, compiler, or types features that have been accepted but are not completely implemented, of which about half are at least 3 years old and many are several years older than that. Many of these tracking issues have been open for so long not solely because of bandwidth, but because working on these features is hard, in large part because putting the relevant semantics in context of the larger language properly is hard; it's not easy for anyone to take a look at them and know what needs to be done to finish them. It's clear that we still need better foundations for making changes to the language and compiler.

Another number that might shock you: there are currently 62 open unsoundness issues. This sounds much scarier than it really is: nearly all of these are edges of the compiler and language that have been found by people who specifically poke and prod to find them; in practice these will not pop up in the programs you write. Nevertheless, these are edges we want to iron out.

The Types Team

Moving forward, let's talk about a smaller subset of Rust rather than the entire language and compiler. Specifically, the parts relevant here include the type checker - loosely, defining the semantics and implementation of how variables are assigned their type, trait solving - deciding what traits are defined for which types, and borrow checking - proving that Rust's ownership model always holds. All of these can be thought of cohesively as the "type system".

As of RFC 3254, the above subset of the Rust language and compiler are under the purview of the types team. So, what exactly does this entail?

First, since around 2018, there existed the "traits working group", which had the primary goal of creating a performant and extensible definition and implementation of Rust's trait system (including the Chalk trait-solving library). As time progressed, and particularly in the latter half of 2021 into 2022, the working group's influence and responsibility naturally expanded to the type checker and borrow checker too - they are actually strongly linked and its often hard to disentangle the trait solver from the other two. So, in some ways, the types team essentially subsumes the former traits working group.

Another relevant working group is the polonius working group, which primarily works on the design and implementation of the Polonius borrow-checking library. While the working group itself will remain, it is now also under the purview of the types team.

Now, although the traits working group was essentially folded into the types team, the creation of a team has some benefits. First, like the style team (and many other teams), the types team is not a top level team. It actually, currently uniquely, has two parent teams: the lang and compiler teams. Both teams have decided to delegate decision-making authority covering the type system.

The language team has delegated the part of the design of type system. However, importantly, this design covers less of the "feel" of the features of type system and more of how it "works", with the expectation that the types team will advise and bring concerns about new language extensions where required. (This division is not strongly defined, but the expectation is generally to err on the side of more caution). The compiler team, on the other hand, has delegated the responsibility of defining and maintaining the implementation of the trait system.

One particular responsibility that has traditionally been shared between the language and compiler teams is the assessment and fixing of soundness bugs in the language related to the type system. These often arise from implementation-defined language semantics and have in the past required synchronization and input from both lang and compiler teams. In the majority of cases, the types team now has the authority to assess and implement fixes without the direct input from either parent team. This applies, importantly, for fixes that are technically backwards-incompatible. While fixing safety holes is not covered under Rust's backwards compatibility guarantees, these decisions are not taken lightly and generally require team signoff and are assessed for potential ecosystem breakage with crater. However, this can now be done under one team rather than requiring the coordination of two separate teams, which makes closing these soundness holes easier (I will discuss this more later.)

Formalizing the Rust type system

As mentioned above, a nearly essential element of the growing Rust language is to know how it should work (and to have this well documented). There are relatively recent efforts pushing for a Rust specification (like Ferrocene or this open RFC), but it would be hugely beneficial to have a formalized definition of the type system, regardless of its potential integration into a more general specification. In fact the existence of a formalization would allow a better assessment of potential new features or soundness holes, without the subtle intricacies of the rest of the compiler.

As far back as 2015, not long after the release of Rust 1.0, an experimental Rust trait solver called Chalk began to be written. The core idea of Chalk is to translate the surface syntax and ideas of the Rust trait system (e.g. traits, impls, where clauses) into a set of logic rules that can be solved using a Prolog-like solver. Then, once this set of logic and solving reaches parity with the trait solver within the compiler itself, the plan was to simply replace the existing solver. In the meantime (and continuing forward), this new solver could be used by other tools, such as rust-analyzer, where it is used today.

Now, given Chalk's age and the promises it had been hoped to be able to deliver on, you might be tempted to ask the question "Chalk, when?" - and plenty have. However, we've learned over the years that Chalk is likely not the correct long-term solution for Rust, for a few reasons. First, as mentioned a few times in this post, the trait solver is only but a part of a larger type system; and modeling how the entire type system fits together gives a more complete picture of its details than trying to model the parts separately. Second, the needs of the compiler are quite different than the needs of a formalization: the compiler needs performant code with the ability to track information required for powerful diagnostics; a good formalization is one that is not only complete, but also easy to maintain, read, and understand. Over the years, Chalk has tried to have both and it has so far ended up with neither.

So, what are the plans going forward? Well, first the types team has begun working on a formalization of the Rust typesystem, currently coined a-mir-formality. An initial experimental phase was written using PLT redex, but a Rust port is in-progress. There's lot to do still (including modeling more of the trait system, writing an RFC, and moving it into the rust-lang org), but it's already showing great promise.

Second, we've begun an initiative for writing a new trait solver in-tree. This new trait solver is more limited in scope than a-mir-formality (i.e. not intending to encompass the entire type system). In many ways, it's expected to be quite similar to Chalk, but leverage bits and pieces of the existing compiler and trait solver in order to make the transition as painless as possible. We do expect it to be pulled out-of-tree at some point, so it's being written to be as modular as possible. During our types team meetup earlier this month, we were able to hash out what we expect the structure of the solver to look like, and we've already gotten that merged into the source tree.

Finally, Chalk is no longer going to be a focus of the team. In the short term, it still may remain a useful tool for experimentation. As said before, rust-analyzer uses Chalk as its trait solver. It's also able to be used in rustc under an unstable feature flag. Thus, new ideas currently could be implemented in Chalk and battle-tested in practice. However, this benefit will likely not last long as a-mir-formality and the new in-tree trait solver get more usable and their interfaces become more accessible. All this is not to say that Chalk has been a failure. In fact, Chalk has taught us a lot about how to think about the Rust trait solver in a logical way and the current Rust trait solver has evolved over time to more closely model Chalk, even if incompletely. We expect to still support Chalk in some capacity for the time being, for rust-analyzer and potentially for those interested in experimenting with it.

Closing soundness holes

As brought up previously, a big benefit of creating a new types team with delegated authority from both the lang and compiler teams is the authority to assess and fix unsoundness issues mostly independently. However, a secondary benefit has actually just been better procedures and knowledge-sharing that allows the members of the team to get on the same page for what soundness issues there are, why they exist, and what it takes to fix them. For example, during our meetup earlier this month, we were able to go through the full list of soundness issues (focusing on those relevant to the type system), identify their causes, and discuss expected fixes (though most require prerequisite work discussed in the previous section).

Additionally, the team has already made a number of soundness fixes and has a few more in-progress. I won't go into details, but instead am just opting to putting them in list form:

Consider unnormalized types for implied bounds: landed in 1.65, no regressions found
Neither require nor imply lifetime bounds on opaque type for well formedness: landed in 1.66, no regressions found
Add IMPLIED_BOUNDS_ENTAILMENT lint: landing in 1.68, future-compat lint because many regressions found (of unsoundness)
Check ADT fields for copy implementations considering regions: currently open, ready to land
Register wf obligation before normalizing in wfcheck: currently open, regressions found, needs additional work
Handle projections as uncovered types during coherence check: currently open, some regressions found, future-compat lint suggested
Don't normalize in AstConv: landing in 1.68, 1 small regression found

As you can see, we're making progress on closing soundness holes. These sometimes break code, as assessed by crater. However, we do what we can to mitigate this, even when the code being broken is technically unsound.

New features

While it's not technically under the types team purview to propose and design new features (these fall more under lang team proper), there are a few instances where the team is heavily involved (if not driving) feature design.

These can be small additions, which are close to bug fixes. For example, this PR allows more permutations of lifetime outlives bounds than what compiled previously. Or, these PRs can be larger, more impactful changes, that don't fit under a "feature", but instead are tied heavily to the type system. For example, this PR makes the Sized trait coinductive, which effectively makes more cyclic bounds compile (see this test for an example).

There are also a few larger features and feature sets that have been driven by the types team, largely due to the heavy intersection with the type system. Here are a few examples:

Generic associated types (GATs) - The feature long predates the types team and is the only one in this list that has actually been stabilized so far. But due to heavy type system interaction, the team was able to navigate the issues that came on its final path to stabilization. See this blog post for much more details.
Type alias impl trait (TAITs) - Implementing this feature properly requires a thorough understanding of the type checker. This is close to stabilization. For more information, see the tracking issue.
Trait upcasting - This one is relatively small, but has some type system interaction. Again, see the tracking issue for an explanation of the feature.
Negative impls - This too predates the types team, but has recently been worked on by the team. There are still open bugs and soundness issues, so this is a bit away from stabilization, but you can follow here.
Return position impl traits in traits (RPITITs) and async functions in traits (AFITs) - These have only recently been possible with advances made with GATs and TAITs. They are currently tracked under a single tracking issue.

Roadmap

To conclude, let's put all of this onto a roadmap. As always, goals are best when they are specific, measurable, and time-bound. For this, we've decided to split our goals into roughly 4 stages: summer of 2023, end-of-year 2023, end-of-year 2024, and end-of-year 2027 (6 months, 1 year, 2 years, and 5 years). Overall, our goals are to build a platform to maintain a sound, testable, and documented type system that can scale to new features need by the Rust language. Furthermore, we want to cultivate a sustainable and open-source team (the types team) to maintain that platform and type system.

A quick note: some of the things here have not quite been explained in this post, but they've been included in the spirit of completeness. So, without further ado:

6 months

The work-in-progress new trait solver should be testable
a-mir-formality should be testable against the Rust test suite
Both TAITs and RPITITs/AFITs should be stabilized or on the path to stabilization.

EOY 2023

New trait solver replaces part of existing trait solver, but not used everywhere
We have an onboarding plan (for the team) and documentation for the new trait solver
a-mir-formality is integrated into the language design process

EOY 2024

New trait solver shared by rustc and rust-analyzer
- Milestone: Type IR shared
We have a clean API for extensible trait errors that is available at least internally
"Shiny features"
- Polonius in a usable state
- Implied bounds in higher-ranked trait bounds (see this issue for an example of an issue this would fix)
- Being able to use impl Trait basically anywhere
Potential edition boundary changes

EOY 2027

(Types) unsound issues resolved
Most language extensions are easy to do; large extensions are feasible
a-mir-formality passes 99.9% of the Rust test suite

Conclusion

It's an exciting time for Rust. As its userbase and popularity grows, the language does as well. And as the language grows, the need for a sustainable type system to support the language becomes ever more apparent. The project has formed this new types team to address this need and hopefully, in this post, you can see that the team has so far accomplished a lot. And we expect that trend to only continue over the next many years.

As always, if you'd like to get involved or have questions, please drop by the Rust zulip.

Security advisory for Cargo (CVE-2022-46176)

2023-01-10T00:00:00+00:00

This is a cross-post of the official security advisory. The official advisory contains a signed version with our PGP key, as well.

The Rust Security Response WG was notified that Cargo did not perform SSH host key verification when cloning indexes and dependencies via SSH. An attacker could exploit this to perform man-in-the-middle (MITM) attacks.

This vulnerability has been assigned CVE-2022-46176.

Overview

When an SSH client establishes communication with a server, to prevent MITM attacks the client should check whether it already communicated with that server in the past and what the server's public key was back then. If the key changed since the last connection, the connection must be aborted as a MITM attack is likely taking place.

It was discovered that Cargo never implemented such checks, and performed no validation on the server's public key, leaving Cargo users vulnerable to MITM attacks.

Affected Versions

All Rust versions containing Cargo before 1.66.1 are vulnerable.

Note that even if you don't explicitly use SSH for alternate registry indexes or crate dependencies, you might be affected by this vulnerability if you have configured git to replace HTTPS connections to GitHub with SSH (through git's url.<base>.insteadOf setting), as that'd cause you to clone the crates.io index through SSH.

Mitigations

We will be releasing Rust 1.66.1 today, 2023-01-10, changing Cargo to check the SSH host key and abort the connection if the server's public key is not already trusted. We recommend everyone to upgrade as soon as possible.

Patch files for Rust 1.66.0 are also available here for custom-built toolchains.

For the time being Cargo will not ask the user whether to trust a server's public key during the first connection. Instead, Cargo will show an error message detailing how to add that public key to the list of trusted keys. Note that this might break your automated builds if the hosts you clone dependencies or indexes from are not already trusted.

If you can't upgrade to Rust 1.66.1 yet, we recommend configuring Cargo to use the git CLI instead of its built-in git support. That way, all git network operations will be performed by the git CLI, which is not affected by this vulnerability. You can do so by adding this snippet to your Cargo configuration file:

[net]
git-fetch-with-cli = true

Acknowledgments

Thanks to the Julia Security Team for disclosing this to us according to our security policy!

We also want to thank the members of the Rust project who contributed to fixing this issue. Thanks to Eric Huss and Weihang Lo for writing and reviewing the patch, Pietro Albini for coordinating the disclosure and writing this advisory, and Josh Stone, Josh Triplett and Jacob Finkelman for advising during the disclosure.

Updated on 2023-01-10 at 21:30 UTC to include additional mitigations.

Announcing Rust 1.66.1

2023-01-10T00:00:00+00:00

The Rust team has published a new point release of Rust, 1.66.1. Rust is a programming language that is empowering everyone to build reliable and efficient software.

If you have a previous version of Rust installed via rustup, you can get 1.66.1 with:

rustup update stable

If you don't have it already, you can get rustup from the appropriate page on our website, and check out the detailed release notes for 1.66.1 on GitHub.

What's in 1.66.1 stable

Rust 1.66.1 fixes Cargo not verifying SSH host keys when cloning dependencies or registry indexes with SSH. This security vulnerability is tracked as CVE-2022-46176, and you can find more details in the advisory.

Contributors to 1.66.1

Many people came together to create Rust 1.66.1. We couldn't have done it without all of you. Thanks!

Updating the Android NDK in Rust 1.68

2023-01-09T00:00:00+00:00

We are pleased to announce that Android platform support in Rust will be modernized in Rust 1.68 as we update the target NDK from r17 to r25. As a consequence the minimum supported API level will increase from 15 (Ice Cream Sandwich) to 19 (KitKat).

In NDK r23 Android switched to using LLVM's libunwind for all architectures. This meant that

If a project were to target NDK r23 or newer with previous versions of Rust a workaround would be required to redirect attempts to link against libgcc to instead link against libunwind. Following this update this workaround will no longer be necessary.
If a project uses NDK r22 or older it will need to be updated to use r23 or newer. Information about the layout of the NDK's toolchain can be found here.

Going forward the Android platform will target the most recent LTS NDK, allowing Rust developers to access platform features sooner. These updates should occur yearly and will be announced in release notes.

Rust Blog

Announcing Rust 1.68.2

What's in 1.68.2 stable

Contributors to 1.68.2

Announcing Rust 1.68.1

What's in 1.68.1 stable

Contributors to 1.68.1

Announcing Rust 1.68.0

What's in 1.68.0 stable

Cargo's sparse protocol

Local Pin construction

Default alloc error handler

Stabilized APIs

Other changes

Contributors to 1.68.0

Announcing Rust 1.67.1

What's in 1.67.1 stable

Contributors to 1.67.1

Announcing Rustup 1.25.2

What's new in rustup 1.25.2

Why is signature verification failure only a warning?

Thanks

Announcing Rust 1.67.0

What's in 1.67.0 stable

#[must_use] effective on async fn

std::sync::mpsc implementation updated

Stabilized APIs

Contributors to 1.67.0

Officially announcing the types team

Background - How did we get here?

The Types Team

Formalizing the Rust type system

Closing soundness holes

New features

Roadmap

Conclusion

Security advisory for Cargo (CVE-2022-46176)

Overview

Affected Versions

Mitigations

Acknowledgments

Announcing Rust 1.66.1

What's in 1.66.1 stable

Contributors to 1.66.1

Updating the Android NDK in Rust 1.68

Local `Pin` construction

Default `alloc` error handler

`#[must_use]` effective on `async fn`

`std::sync::mpsc` implementation updated