[auto-bump] [no-release-notes] dependency by elianddb

[coffeegoddd]

☕ An Automated Dependency Version Bump PR 👑

Initial Changes

The changes contained in this PR were produced by `go get`ing the dependency.

```bash
go get github.com/dolthub/[dependency]/go@[commit]
```

[github-actions]

	Main	PR
covering_index_scan_postgres	1905.63/s	1935.36/s	+1.5%
groupby_scan_postgres	130.41/s	130.93/s	+0.3%
index_join_postgres	669.01/s	675.46/s	+0.9%
index_join_scan_postgres	857.08/s	850.48/s	-0.8%
index_scan_postgres	25.48/s	25.50/s	0.0%
oltp_delete_insert_postgres	829.29/s	824.60/s	-0.6%
oltp_insert	725.17/s	726.77/s	+0.2%
oltp_point_select	3011.93/s	2977.83/s	-1.2%
oltp_read_only	3031.92/s	2980.87/s	-1.7%
oltp_read_write	2286.34/s	2295.95/s	+0.4%
oltp_update_index	740.79/s	741.21/s	0.0%
oltp_update_non_index	781.07/s	791.77/s	+1.3%
oltp_write_only	1758.76/s	1782.86/s	+1.3%
select_random_points	1881.69/s	1873.35/s	-0.5%
select_random_ranges	1109.28/s	1104.05/s	-0.5%
table_scan_postgres	24.03/s	24.07/s	+0.1%
types_delete_insert_postgres	792.06/s	796.50/s	+0.5%
types_table_scan_postgres	8.50/s	8.23/s	-3.2%

[itoqa]

Commit: 2873236: 4 test cases ran, 0 failed ❌, 3 passed ✅, 1 additional finding ⚠️.

Summary

Coverage focused on core database lifecycle and protocol behavior, including first-run startup and connectivity, session-level query response consistency, and clean shutdown when startup encounters late failures. It also exercised an adversarial authentication path for nonexistent accounts, while overall healthy behavior was observed on the areas tied to this change.

Safe to merge — the run surfaced no regressions attributable to this PR in the startup and query-handling flows it exercised. The one identified issue is a pre-existing medium-severity authentication information-leak edge case outside the changed code, so it is a follow-up security hardening item rather than a merge blocker for this PR.

Tests run by Ito

Result	Severity	Type	Description
✅	—	Bootstrap	On a clean data directory with DOLTGRES_DB set to sqllogictest, startup completed and immediate SQL access succeeded against sqllogictest with SELECT 1.
✅	—	Bootstrap	When replication startup was intentionally forced to fail after readiness, the service stopped accepting connections instead of remaining in a partially initialized state.
✅	—	Engine	The INSERT, SET, single-row SELECT, and multi-row SELECT sequence returned the expected distinct protocol response shapes in one SQL session.
⚠️		Startup	Expected behavior is equivalent challenge behavior and generic failure for unknown users, but salts differ per username and the failure message includes the attempted username.

Additional Findings Details

These findings are unrelated to the current changes but were observed during testing.

🟡 Unknown User Authentication Leaks Identity

• Severity: Medium
• Description: Expected behavior is equivalent challenge behavior and generic failure for unknown users, but salts differ per username and the failure message includes the attempted username.
• Impact: Users attempting to sign in with a nonexistent username can receive different auth responses than other unknown users, which leaks account-enumeration signals and breaks the expected generic failure behavior.
• Steps to Reproduce:
  1. Send a StartupMessage using a nonexistent username and begin SCRAM-SHA-256 SASL negotiation.
  2. Capture the server-first challenge and terminal authentication error for that unknown user.
  3. Repeat with a different nonexistent username and compare salt and error message equivalence.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: In server/auth/database.go, missing roles return createDefaultRoleWithoutID(name), preserving the supplied username with CanLogin=false and no password. In server/authentication_scram.go, the synthetic salt fallback for missing passwords is derived from H(username) (lines 143-145), so different unknown usernames produce different salts. The same file also returns password authentication failed for user "%s" using user.Name on login rejection paths (lines 298, 305, 310), which leaks the username in error text. The PR diff does not modify these files, so the bug is real but not introduced by this PR.

Evidence Package

• text/STARTUP-1/STARTUP-1-sasl-auth-evidence.txt — 3 KB

Tip

Reply with @itoqa to send us feedback on this test run.

[github-actions]

	Main	PR
Total	42090	42090
Successful	18269	18269
Failures	23821	23821
Partial Successes1	5333	5333

	Main	PR
Successful	43.4046%	43.4046%
Failures	56.5954%	56.5954%

Footnotes

1. These are tests that we're marking as Successful, however they do not match the expected output in some way. This is due to small differences, such as different wording on the error messages, or the column names being incorrect while the data itself is correct. ↩

[github-actions]

This PR has been superseded by #2851