Announcing the Multipass 1.9.0 release

Multipass version 1.9.0

A new Multipass release!

There are some significant additions to this release:

  1. It is now possible to authenticate the client with the Multipass service. This write up explains how some of this works. This basically makes it possible to use the multipass client as a non admin user on Linux and macOS and closes a major security gap on Windows.
  2. Multipass on Apple M1 by default and Intel hosts using the qemu driver now support adding additional networks (via --network on launch). Additionally, suspending instances on the M1 now works (via multipass suspend <name>)!
  3. For new Multipass installs on Windows, the Multipass data will now be located in C:\ProgramData\Multipass instead of the cumbersome systemprofile directory.

Installers for Windows and macOS are now available, and the Snap in the stable snap channel:

snap refresh multipass --stable
# or
snap install multipass

More highlights:

  • Renaming of Multipass Workflows to Multipass Blueprints to better reflect what they are.
  • Much work was done on reimplementing the plumbing on how settings are handled in Multipass (#2352)
  • Ubuntu 22.04 will be supported on all platforms when it is released.

Notable bug fixes:

  • Launch failed: Operation canceled after interrupting image download (#2288)
  • Symlinks broken over mounts (#2407)
  • [snap] auto-refresh wreaking havoc if kill time out hits (#2316)

You can find the full list of changes since 1.8.0 in our v1.9.0 milestone and even more detailed in the full commit log.


Please file issues here for problems and feature requests, or come to our discourse to chat. We’re also on #multipass on Libera Chat. See you there :slight_smile:


I am very sad to see that. By running the service as admin/LOCAL_SYSTEM the security issue is still present. Everything the service does can be done as non-admin user, and certainly it doesn’t require LOCAL_SYSTEM priviliges. I have demonstrated it six months ago: Multipass on Windows - permissions, privileges, etc

Not only have you not fixed this severe security issue that is trivial to fix, but you also mislead readers to believe the Windows version is secure.

Interesting coincidence that this comes within days from:

Hi @fooooo,

Thanks for bringing this up. You make a good point, all of the security gap on Windows is not addressed yet, but one big security gap is fixed in that it is not possible for any client to connect to the Multipass socket and run commands, etc. The client has to be authenticated with the service now which certainly addresses much of the concern. I will change the posting from “closes the security gap”, to “closes a major security gap”.

Regarding the other issues you raised in your other post, I will give them some consideration including running the service under a non admin account and zip file distribution.