Figure out what to do about SqlClient 4.0

[ajcvickers]

Due to a major breaking change in SqlClient 4.0, updating to 4.0 breaks all tests that do not use LocalDb.

Updating will also break the majority of applications using EF Core.

[ErikEJ]

Unless they change their connection string?

[ajcvickers]

Notes from triage:

• Update to 4.0 and change our testing connections strings to disable encryption.
• Follow up on:
  • Communicating the break effectively to EF users
  • Ensuring there is clear documentation on what users should do
  • Potentially improving the local dev experience by providing/installing a local dev certificate like ASP.NET does
  • Catching the exception in EF Core and wrapping with better guidance on what to do

[ErikEJ]

Detect that SQL Client 4 is in use, and if Encrypt=false, log a warning?

[NuclearFishin]

Hi all, I would just like to reiterate the importance of effective communication regarding the breaking change of Encrypt=true. At present, updating to SqlClient 4.0 results in a cryptic failure message which is tripping-up users directly consuming the SqlClient library -see issue 1402 in the SqlClient repo- so I feel like it's doubly-important for EF Core to help its users here (myself included), as they are not taking a direct dependency on the SqlClient library. This could be a "ticking time bomb" of poor developer experience!

In my case, I'm developing a .NET Core application on a Mac (macOS Monterey 12.2.1), and upon updating to SqlClient 4.0, I can no longer connect to my local database running inside an Azure SQL Edge Docker container. Likewise I can no longer connect to Amazon RDS databases from my machine. I imagine these are very common use-cases that are broken after the update.

In both cases, setting TrustServerCertificate=true solves the problem in a sense, but it's imperfect re: man-in-the-middle attacks.

I certainly agree in-principle with the requirement to encrypt connections, but I think the crux of the issue here is that attempting to do things the Right Way throws us developers into the deep-end of x509 certificate chains, trusted root stores, etc. It's difficult even to find out which certificates are in use by SQL Server! I had to resort to this gist just to find that out 😬

Even more frustrating than reading the certificates is that trusting them seems to be an OS-level change, which simply may not be possible in serverless or CI/CD environments. Naively, I feel like it would be great if I could install these certificates into my .NET application, rather than the OS. Maybe that's possible, maybe it's not- maybe there's a super-easy way to do this that I just haven't figured out yet. But this is exactly what I think the documentation needs to cover!

Thanks for your time :)