v0.8.29: slack search, landing optimizations, search optimizations, sso multiple providers - #7664
Merged
Conversation
…7644) * feat: serve organization search through Slack custom bots * feat(slack-search): stream enterprise answers through one Slack app * fix(slack-search): simplify setup and align source readiness * fix(slack-search): supply query props in page gate test * fix(slack-search): finalize failed streams and explain query limits * fix(tests): isolate embedding provider credentials
* fix(billing): bound cumulative usage lock holders * fix(billing): retain older PostgreSQL timeout compatibility
* fix(outbox): prevent bulk cleanup from starving delivery * test(outbox): isolate scheduler PostgreSQL fixtures
…yaml, nodemailer and csv-parse (#7659) * fix(deps): bump Next.js to 16.3.4 for two critical RCE advisories Resolves Dependabot alerts #223, #224, #226, #228, #235, #236, #238, #239. - GHSA-p293-qw3h-jr36: unauthenticated RCE on Windows-hosted servers - GHSA-2xp9-vwfh-vxw4: unauthenticated RCE in the Image Optimization API when AVIF files are used Both are fixed in 16.3.3. This takes 16.3.4 instead because 16.3.3 disabled AVIF image optimization outright and 16.3.4 re-enables it; apps/sim/next.config.ts requests 'image/avif', so 16.3.3 alone would silently drop AVIF output. 16.3.4 otherwise carries only backported bug fixes, so there is no breaking change between 16.3.1 and 16.3.4. Verified: type-check, lint, all 46 audits, full test suite, and production builds of both apps/sim and apps/docs. * fix(deps): bump sharp to 0.35.4 for libheif RCE advisories Resolves Dependabot alerts #230 and #234 (GHSA-rgj7-g3m4-5g8c), which cover two critical libheif vulnerabilities reachable when processing untrusted image input. Fixed upstream in sharp 0.35.4, which ships libvips 8.18.6. 0.35.4 is a patch release with no API changes. No source file imports sharp directly; it backs the Next.js image optimizer, which is the same code path as the AVIF advisory addressed in the previous commit. This also collapses a duplicate install: Next 16.3.4 depends on sharp ^0.35.3, so with the root pinned at 0.35.3 bun kept a second nested copy at 0.35.4, loading two libvips builds into one process and warning about duplicate GNotificationCenterDelegate classes. Both now resolve to a single 0.35.4. Verified: sharp loads its native binary and round-trips an AVIF encode and decode on libvips 8.18.6, plus all 46 audits, the full app test suite, and a production build. * fix(deps): bump js-yaml to 4.3.2 for merge-key CPU exhaustion Resolves Dependabot alerts #229 and #237 (GHSA-2883-xcg3-v3hh). maxTotalMergeKeys did not count empty mappings, so a small document could merge a large sequence of them repeatedly and burn CPU without ever reaching the configured limit. The path is reachable: both YAML entry points, lib/file-parsers and lib/chunkers, call yaml.load with the default schema, which enables merge keys, and both run on user-supplied files. Confirmed against the advisory proof of concept, which took 13s on 4.3.1 and is now refused in 6ms. Not a breaking change for real documents. The fix charges one extra budget unit per merge source against a default maxTotalMergeKeys of 10000, so only pathological documents newly fail; a 200-merge document over a 20-key anchor spends 4200 units and still loads. Ordinary merge and anchor resolution is unchanged. * fix(deps): bump nodemailer to 9.1.1 for four address-handling advisories Resolves Dependabot alerts #227, #231, #232 and #233. - GHSA-8m3c-c648-2xjj: quadratic addressparser complexity, remote DoS via a crafted address list - GHSA-cc9r-2j5m-2m83: IDN/Punycode domain allow-list bypass - GHSA-2x7j-588g-ccc2: RFC 5322 comment mis-parsing, both leading to delivery to an attacker-controlled domain - GHSA-wmmp-3585-3rmp: resolveContent bypassed disableFileAccess and disableUrlAccess on the legacy signature 9.0.1 to 9.1.1 stays inside v9. Checked the two changes that could have altered behavior: - The new maxRecipients cap defaults to 100000 and is documented as a backstop, not a delivery policy, so no real send reaches it. - The tightened resolveContent access sandbox only governs attachments given as a file path or URL. Sim passes attachment content as buffers in lib/messaging/email/providers, so the sandbox never applies. Address parsing is unchanged for plain, display-name, quoted-comma, multi-recipient, plus-tagged and unicode forms. Verified: type-check, lint, all 46 audits, and the 130 tests covering lib/messaging/email and lib/internal/smtp. * fix(deps): bump csv-parse to 7.0.2 for prototype replacement via columns Resolves Dependabot alert #225 (GHSA-8cw4-87c7-c6xx). With columns and group_columns_by_name enabled, a duplicated __proto__ header made the duplicate-column branch assign through the __proto__ setter and replace the parsed record's prototype with attacker-controlled data. 7.0.2 fixes it with an Object.hasOwn duplicate check and Object.defineProperty. Despite crossing a major, this is not a breaking upgrade: the maintainers state that 7.0.0 "was published by mistake, there is no breaking changes." One real behavior change does land in the 6.1.0 to 7.0.2 range: trim now aligns with ECMAScript whitespace, so a value padded with non-ASCII whitespace such as U+00A0 is trimmed where it previously was not. Diffed both versions over plain, padded, CRLF, quoted-comma, embedded-tab, unicode-whitespace, ragged, BOM, blank-line and embedded-newline inputs under the exact options Sim passes: the unicode-whitespace case is the only difference, and it moves toward JavaScript trim semantics. Record structure, headers and field splitting are byte-identical. Sim never sets group_columns_by_name, so the vulnerable branch was not reachable, but every CSV entry point does pass columns and trim on user-supplied files. Verified: type-check, lint, all 46 audits, and the 1946 tests across lib/file-parsers, lib/table and lib/copilot/request/tools. * fix(deps): dedupe js-yaml so no 4.3.1 copy remains in the tree Pinning the two direct dependents to 4.3.2 left nine transitive consumers pinned to their own nested 4.3.1, because bun does not re-resolve a lockfile entry that still satisfies its range. The tree therefore kept a vulnerable copy of the package the previous commit was meant to remove. Every one of those consumers asks for ^4.1.x, which 4.3.2 satisfies, so the nesting was lockfile inertia rather than a real constraint. Dropping the stale entries and reinstalling lets them all resolve to the single hoisted 4.3.2. The two js-yaml 3.x consumers, artillery and gray-matter, keep their own copy untouched. Done this way rather than by deleting the lockfile, which re-resolves every floating range and churned 1130 unrelated lines, or by a global override, which would force v4 onto those two v3 consumers. This diff removes nine lines and changes nothing else. Verified: js-yaml 4.3.1 no longer resolves anywhere in the tree, the docs site still builds its 700+ pages through fumadocs, and the desktop suite covering electron-updater passes its 1600 tests.
* feat(sso): several identity providers per organization An organization can now run more than one identity provider, one per verified domain: Okta for eng.acme.com and Entra for acme.com, for example. The schema already allowed several rows; the product could not show, pick, or remove them. - Sign-in names the provider explicitly. A new POST /api/auth/sso/resolve maps an email domain to the provider that serves it, preferring a verified domain and breaking ties on provider id, so routing no longer depends on the SSO plugin's unordered domain lookup. - Registration refuses a second provider on a domain the caller already routes (SSO_DOMAIN_ALREADY_ROUTED), keeping email-domain routing deterministic. The check shares the existing cross-tenant domain read. - DELETE /api/auth/sso/providers/[providerId], owned by Sim since the plugin's delete-provider stays blocked: organization owners and admins remove an organization provider, the creator a personal one. Accounts and memberships the provider admitted are untouched. - The provider list is ordered by provider id; the settings sign-in tab lists providers, opens one by URL (`provider=`), adds another, and deletes with confirmation. JIT admissions record the provider id in their audit metadata. - Docs describe multiple providers, domain routing, and deletion. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CkZjSKgtFdE5mzsQ31gGLY * improvement(sso): verified multi-provider flow and cleaner provider settings - Registration guard uses the same domain expression as sign-in resolution and domain verification - Self-host registration script stores the normalized provider domain - Sign-in reports "no provider" only on 404; other failures keep the generic message - Settings: canonical back slot and title on provider detail and form, Edit then Delete, no duplicate Open in the row menu, awaited list refetch before navigating, replace-history on close, unsaved-changes guard on back - Docs: state that an organization can use more than one identity provider * fix(sso): make one provider per domain hold at the database and resolve only verified providers - Partial unique index on sso_provider (organization_id, normalized domain), built concurrently after a duplicate pre-check; a lost race maps to the same 409 as the pre-check - Sign-in resolution returns only providers whose domain is verified - Settings controls follow the organization owner/admin model the server enforces, not the creator * fix(sso): support registered provider IDs in settings * refactor(sso): keep provider deletion in details * chore(db): remove SSO migration before staging update * chore(db): regenerate SSO migration after staging --------- Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
* Improve organization search ranking and bound rerank admission * improvement(search): reduce embedding and retrieval overhead * fix(search): align boundary test fixtures with search adapters * improvement(search): preserve existing ranking policy
Contributor
|
Too many files changed for review (230 files, 100 file limit). Bypass the limit by tagging |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading. Please reload this page.