update 3rd party libraries, part2

[georgeliao]

close #3568
MULTI-1176

git submodule
1. vcpkg, updated to 2025.01.13.

vcpkg managed:
1. grpc, 1.52.1-> 1.68.2.

The vcpkg grpc build recipe (located in <multipass_path>/3rd-party/vcpkg-ports/grpc) particularly portfile.cmake, is based on the standard grpc build recipe found in the directory <multipass_path>/3rd-party/vcpkg/ports/grpc. Therefore, an effective way to view the actual change is by comparing these two directories using tools like Beyond Compare or diff.

These changes are centered around one thing, that is eliminating unneeded library build. As a result, it significantly reduced the grpc build time. To achieve this, remove_unneeded_lib_custom.patch was introduced. To review the content of the patch, you can compare it with the original patch applied to grpc 1.52.

Although maintaining this patch can be cumbersome, the build time savings justify the effort. The grpc build time was reduced from 9 mins 53 seconds to 4 mins 40 seconds on my 20 hardware threads machine.

Additionally, there are some api calls changes on multipass side. Those are made to accomodate some grpc' code changes in this duration which broke the backward compatibility. The particular commit is this one. There is also another github issue which has relevant discussions about this. This change affects grpc version 1.57.0 and onwards. The fix we adopt is the one mentioned in the github issue, where they call grpc.insecure_channel(srv_endpoint, options=(('grpc.default_authority', 'localhost'),)) on python client to overwrite the default authority, the C++ equivalent to this would be changing grpc::CreateChannel calls to grpc::CreateCustomChannel calls with channel arguments, see below code snippet for details

    grpc::ChannelArguments channel_args;
    channel_args.SetString(GRPC_ARG_DEFAULT_AUTHORITY, "localhost");

    // Use CreateCustomChannel to apply ChannelArguments
    auto channel = grpc::CreateCustomChannel(
        server_address, grpc::InsecureChannelCredentials(), channel_args);

Be aware that this change affects all types of address resolvers, that probably is fine in the use cases of multipass.

snap:

1. sshfs, will be done it in a different PR. 

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.08%. Comparing base (507590b) to head (1eb8b41).

Additional details and impacted files

@@                 Coverage Diff                 @@
##           standard_grpc_mTLS    #3707   +/-   ##
===================================================
  Coverage               89.08%   89.08%           
===================================================
  Files                     255      255           
  Lines                   14646    14649    +3     
===================================================
+ Hits                    13047    13050    +3     
  Misses                   1599     1599           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[georgeliao]

builtin-baseline field defines the versions of the dependencies of our vcpkg packages. In this particular case, grpc needs this update to get his dependency versions right because of his own update. The value of builtin-baseline field is simply the commit hash of the vcpkg repo.

[georgeliao]

Hi @Saviq @townsend2010

Sorry to bother you guys. Recently, multipass team has been dealing with rebasing the patches (code commits on the top of the release tag) of grpc after updating grpc to newer version. It has been a painful process due to the size of the patches and conflicts with the grpc refactors and changes. This really got us thinking what is the exact reason to keep these patches. Why multipass has a unique use case from the regular ones?

By looking at commit messages and the code, my superficial understanding is that. Multipass wants to support skipping verifying server certificate. Because of that, the grpc_ssl_server_certificate_request_type enum is added and all the corresponding changes are made. But why exactly do we need that is still not clear to me, meaning why does multipass uniquely need this skip the server certificate verification option.

Any information would be appreciated in case you guys know about it, thanks a lot.

[Saviq]

why does multipass uniquely need this skip the server certificate verification option

Basically to support SSH-style authorization. Both sides generate their encryption keys in isolation, without a CA between them. All communication is encrypted, and the key fingerprints are what determines whether they want to talk to one other on a higher level, not whether the certificates are valid or not.

[georgeliao]

Basically to support SSH-style authorization. Both sides generate their encryption keys in isolation, without a CA between them. All communication is encrypted, and the key fingerprints are what determines whether they want to talk to one other on a higher level, not whether the certificates are valid or not.

Thanks for the reply. But why exactly does multipass have to use the SSH-style authorization? The standard TLS/mTLS always requires the server certificate and verifies it. As a result, grpc api only provides GRPC_SSL_REQUEST_SERVER_CERTIFICATE_AND_VERIFY but not GRPC_SSL_REQUEST_SERVER_CERTIFICATE_BUT_DONT_VERIFY and it seems to make sense. The orthodox way based on the documentation of doing TLS/mTLS grpc is to fill in the pem_root_certs field of grpc::SslCredentialsOptions object on the client side, and later it will be used to verify the server cert and key pair internally.

My wondering here is whether this orthodox way has some inadequacies we are not aware of or it somehow does not fit in the multipass use case. Any info will be appreciated, thanks.

[townsend2010]

My wondering here is whether this orthodox way has some inadequacies we are not aware of or it somehow does not fit in the multipass use case. Any info will be appreciated, thanks.

Hey @georgeliao,

As @Saviq alluded to, it was done this way to avoid having to use a CA and generate valid SSL certificates. In the early days when this was implemented, we found it to be easier to just modify gRPC and carry the patches than to deal with a CA. If you all want to deal with a CA and generate valid SSL certs in order to use what gRPC already supports, then that's a technical decision the Multipass team will need to make. Maybe it's easier now than in 2018. 🤷‍♂️ Care will also need to be taken with the whole authorization plumbing, but I think that should still work.

[Saviq]

This was the only way to have clients other than the first/default one to get access to the daemon simply by providing a shared passphrase. If you go for the CA approach, you have to generate a key pair and a certificate signing request and ask someone with access to the CA (admin) to sign your CSR and provide you back with the signed certificate. There's also no path to accepting the first client like we do today on Linux and macOS, you'd need to somehow get through the above dance in the installation phase.

Using a passphrase is just a more user-friendly way to achieving the same level of security, is all (one missing bit in the current scheme is managing a list of accepted daemon certificates, .ssh/known_hosts-style).

[georgeliao]

@townsend2010
Thanks a lot for the information. Now we understand the context much better.