Simpler and consistent with the existing registry column exclusion in the same
query: drop the secret columns from the nested github/gitlab/gitea/bitbucket
relations via columns:{ ...: false } instead of a post-fetch redaction helper.
Server-side clone paths re-fetch providers by id (find{Github,Gitlab,...}ById),
so deployments are unaffected. Column names are validated at compile time by
drizzle's typed columns config.
Closes GHSA-hg9j-j5mc-phf5, GHSA-wx75-vxph-2m2f
findApplicationById eagerly loads the github/gitlab/gitea/bitbucket relations
(needed server-side to clone) including OAuth tokens, the GitHub App private key
and webhook secret. application.one returned them to the client, exposing them to
any member with service:read even when hasGitProviderAccess was false.
Adds redactApplicationGitSecrets() in the application service (blanks the secret
columns, immutably) and applies it to application.one. No client feature reads
these secrets (verified in the frontend); server-side clone paths use
findApplicationById directly, so behaviour is unchanged.
Closes GHSA-hg9j-j5mc-phf5, GHSA-wx75-vxph-2m2f
* fix: strip credentials from service-level API responses
Registry passwords and S3 destination credentials were being returned
in service `.one` tRPC endpoints to any user with service-level read
access. Reported by Nihon Kohden Corporation security team.
- Strip registry `password` from `findApplicationById` via Drizzle `columns: { password: false }`
- Strip destination `accessKey`/`secretAccessKey` from all DB service finders (postgres, mysql, mariadb, mongo, libsql, compose, backup, volume-backups)
- Add `findRegistryByIdWithCredentials` for internal use only
- Builders and upload utils now load registry credentials by ID at execution time
- `createRollback` enriches `fullContext` with registry credentials before persisting to DB so rollback execution has what it needs
- Remove `findApplicationByIdWithCredentials` and `ApplicationNestedWithCredentials` — no longer needed
- Backup execution utils load full destination via `findDestinationById` at runtime instead of reading from the joined relation
* [autofix.ci] apply automated fixes
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
- Consolidated patch retrieval for applications and composes into a single query method, improving code clarity and reducing redundancy.
- Updated the ShowPatches component to utilize the new unified query, simplifying data fetching logic.
- Refactored patch application commands to streamline the process for both application and compose types, enhancing maintainability and consistency across the codebase.
- Updated the ShowDockerLogs component to use optional chaining when accessing the error property of services, preventing potential runtime errors.
- Refactored the deployApplication function to create an applicationEntity object, ensuring consistent use of serverId across repository cloning functions.
- Removed unused createEnvFile function from utils, streamlining the codebase.
- Updated the deployPreviewApplication function to await the getBuildCommand call, ensuring the command is fully constructed before execution.
- This change improves the reliability of the deployment process by handling asynchronous command generation correctly.
- Added a new optional field `rollbackRegistryId` to the application schema to support rollback registry selection.
- Enhanced the form in the ShowRollbackSettings component to include a dropdown for selecting a rollback registry when rollbacks are enabled.
- Updated the application service to handle rollback registry logic during deployment and rollback processes.
- Improved error handling and validation for rollback settings, ensuring a registry is selected when rollbacks are active.
- Adjusted database schema and migration files to accommodate the new rollback registry feature.
- Updated the rebuildApplication function to utilize a consistent server ID by incorporating buildServerId where available.
- Refactored deployment command execution to ensure compatibility with the new server ID logic, enhancing deployment reliability.
- Added support for build server configuration in the application dashboard, including new UI elements and validation.
- Updated database schema to include build server associations and foreign key constraints.
- Enhanced deployment logic to utilize build server IDs, improving deployment flexibility.
- Improved logging and user feedback during the build and deployment processes, including new alerts for image download status.
- Refactored application and deployment services to accommodate build server integration.
- Introduced a new ExecError class to standardize error handling during command execution.
- Updated deployApplication and deployCompose functions to log detailed error messages, excluding ExecError instances.
- Improved execAsync and execAsyncRemote functions to throw ExecError with additional context for better debugging.
- Added base64 encoding for error messages to ensure sensitive information is handled appropriately.
- Upgraded `node-os-utils` from version 1.3.7 to 2.0.1 across multiple package.json files.
- Removed deprecated `@types/node-os-utils` dependency.
- Refactored lodash imports to use a single import statement for consistency.
- Enhanced Docker stats monitoring by integrating new features from `node-os-utils` version 2.0.1.
- Integrated `getGitCommitInfo` function to retrieve the latest commit message and hash for applications and compose services.
- Updated deployment logic to conditionally include commit information in deployment updates, enhancing traceability.
- Refactored import statements for better organization and clarity.
- Added logic to create a rollback entry if the application has an active rollback during the deployment process.
- Enhanced the rollback handling by determining the appropriate tag image based on the application's source type (docker or app name).
- Introduced two new SQL files for rollback constraints, updating foreign key relationships with different delete actions (set null and cascade).
- Updated the journal and snapshot files to include the new rollback schema changes for versions 0096 and 0097.
- Enhanced the application service to handle rollback image tagging based on source type.
- Implemented rollback removal logic in the deployment service to ensure proper cleanup of rollback entries.
- Introduced a new "fullContext" JSONB column in the "rollback" table to store additional context for rollbacks.
- Removed the "env" column from the "rollback" table to streamline data management.
- Updated the rollbacks service to handle the new "fullContext" field during rollback creation.
- Adjusted the application service to eliminate environment variable handling in rollback operations.
- Updated Tailwind configuration for responsive design.
- Modified the ShowDeployments component to include rollback settings and actions.
- Introduced a new "rollback" table in the database schema with foreign key relationships.
- Updated deployment and application schemas to support rollback features.
- Added rollback mutation to the API for initiating rollbacks.
- Added ShowEnv and ShowRollbackSettings components for displaying and configuring rollback settings.
- Implemented ShowRollbacks component to list and manage rollbacks for applications.
- Created rollback database schema and updated application schema to include rollback settings.
- Added API routes for managing rollbacks, including fetching, creating, and deleting rollbacks.
- Integrated rollback functionality into the application deployment process.
- Introduced a new boolean column `cleanCache` in the application schema to manage cache cleaning behavior.
- Updated the application form to include a toggle for `cleanCache`, allowing users to enable or disable cache cleaning.
- Enhanced application deployment logic to utilize the `cleanCache` setting, affecting build commands across various builders (Docker, Heroku, Nixpacks, Paketo, Railpack).
- Implemented success and error notifications for cache updates in the UI.
