fix(plugin-mssql): build FreeTDS with Kerberos so Windows Auth works (#1918)#1922
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 417187e4a4
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| build_slice "macos-arm64" "macosx" "arm64" "aarch64-apple-darwin" "-mmacosx-version-min=${MACOS_DEPLOYMENT_TARGET}" "$MACOS_OPENSSL_ARM64" "--enable-krb5=gssapi_krb5" | ||
| build_slice "macos-x86_64" "macosx" "x86_64" "x86_64-apple-darwin" "-mmacosx-version-min=${MACOS_DEPLOYMENT_TARGET}" "$MACOS_OPENSSL_X86_64" "--enable-krb5=gssapi_krb5" |
There was a problem hiding this comment.
Publish the rebuilt FreeTDS archive with this change
Normal app and plugin builds never run this script: .github/workflows/build-plugin.yml downloads libs-v1 through scripts/download-libs.sh, which verifies it against the unchanged Libs/checksums.sha256. Since this commit neither updates that archive/checksum baseline nor triggers a rebuild, every subsequently built MSSQL plugin still links the old GSS-less libsybdb.a, so Windows Authentication remains broken despite the changelog entry. Publish the rebuilt artifacts, update the committed checksums, and release a new plugin binary as part of this fix.
Useful? React with 👍 / 👎.
Fixes #1918.
Root cause
Windows Authentication (Kerberos) to SQL Server fails on macOS because the FreeTDS library that ships in the registry MSSQL plugin was compiled without Kerberos support.
nm Libs/libsybdb.ashowstds_gss_get_authis absent andgssapi.ois an empty stub (only NTLM,tds_ntlm_get_auth, is present). Every Windows-auth connect fails insidedbopen()because FreeTDS has no GSS code to run; it then falls back to an empty-username TDS login, which the server rejects, and the app surfaces it as a credentials error. Both reported flows (reuse an existingkinitticket, and type principal + password) fail at that same call for the same reason.The Windows Auth feature (#1890/#1892) added correct Swift plumbing and patched
build-freetds.shwith--enable-krb5, but the libraries were never rebuilt or republished, and the plugin binary (plugin-mssql-v1.0.30) still links the old GSS-lesslibsybdb.afromlibs-v1.This is a build/release gap, not a driver-logic bug, so the fix is a library rebuild plus guard-rails, not a code refactor. The Swift driver, the
-framework GSSlink, and the docs were already correct.Why a naive rebuild could ship broken again
FreeTDS's
--enable-krb5in auto mode definesENABLE_KRB5only if theAC_SEARCH_LIBS(gss_init_sec_context, ...)link probe succeeds, and skips it with no error or warning on failure. That silent path produces exactly the emptygssapi.owe see. So this PR also makes the build deterministic.Changes in this PR
scripts/build-freetds.sh: macOS slices build with--enable-krb5=gssapi_krb5. The explicit-library form definesENABLE_KRB5unconditionally, removing the silent auto-detect fallback. NoCPPFLAGS/LDFLAGSchanges are needed: the macOS SDK sysroot already supplies<gssapi/gssapi_krb5.h>andlibgssapi_krb5.tbd, and the plugin already links-framework GSS.scripts/build-freetds.sh: a post-buildnmassertion fails the build if the macOS archives lacktds_gss_get_auth, so a GSS-lesslibsybdb.acan never ship silently again.CHANGELOG.md: oneFixedentry under[Unreleased].Not changed (verified correct)
-force_load Libs/libsybdb.a+-framework GSS(both Debug and Release).KRB5CCNAMEFILE-ccache handling,gss_aapl_initial_credticket acquisition, and the Kerberos classifier.docs/databases/mssql.mdxalready documents thekinitsingle sign-on flow, the typed-principal flow, and troubleshooting.Follow-up steps required to release the fix (not automatable in this PR)
The code change alone does not fix users. After merge, someone with the build/publish environment must:
bash scripts/build-freetds.sh(needsbrew install autoconf automake libtool openssl@3). The new assertion verifies GSS is compiled in.nm Libs/libsybdb.a | grep tds_gss_get_authprintsT _tds_gss_get_auth.scripts/publish-libs.sh libsybdb_arm64.a libsybdb_x86_64.a libsybdb_universal.a libsybdb.a, then re-pack and upload the iOS xcframework archive per CLAUDE.md.Libs/checksums.sha256.plugin-mssql-v1.0.31, orgh workflow run build-plugin.yml) so its binary links the rebuilt lib. No PluginKit ABI bump:currentPluginKitVersionstays 18.Testing
The library/GSS path can't be unit-tested in the Swift suite (the lib isn't rebuilt in CI, and the C-bridge tests run zero rows in that target). The build-script
nmassertion is the automated verification, self-checking at build time. No Swift behavior changes, so the existingMSSQLKerberosClassifierTestsandMSSQLConnectionOptionsAuthMethodTestsstill hold.