Conversation
Merge Main into Staging [WPB-22420]
Merge Staging into Dev [WPB-22420]
Upgrade teams to enterprise via Ibis API [WPB-22420]
…out_for_multiple_accounts_e2e_test chore(e2e): Increase timeout for multiple accounts e2e test [WPB-28071]
Move desktop log path construction, file discovery, and startup migration helpers into focused logging modules. Resolve the log directory only after Electron's final userData path has been configured so portable and custom user-data modes use the correct location. Keep the existing logging layout and runtime behavior unchanged.
Centralize log paths and filesystem operations, preserve logs across restarts, add bounded rotation and retention and organize logs by UTC day and account while maintaining legacy-layout support.
…-msi feat(windows): add native MSI installer (WPB-5221)
Make desktop log storage bounded and reliable [WPB-27016]
![semgrep-code-wireapp[bot]](https://avatars.githubusercontent.com/u/16047324?s=60&v=4){kind=small}
| this.axiosInstance = axios.create({ | ||
| baseURL: baseUrl, | ||
| withCredentials: true, | ||
| headers: { | ||
| 'Content-Type': 'application/json', | ||
| }, | ||
| }); |
There was a problem hiding this comment.
High severity vulnerability may affect your project—review required:
Line 35 lists a dependency (axios) with a known High severity vulnerability.
ℹ️ Why this matters
Affected versions of axios are vulnerable to Improper Check for Unusual or Exceptional Conditions / Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution'). Axios crashes in its mergeConfig routine when a configuration object has an own enumerable __proto__ key. Such a key appears when the config is built from untrusted JSON (e.g. JSON.parse) and passed to an axios request method: the merge resolves __proto__ to Object.prototype and tries to invoke it as a function, throwing a TypeError that crashes the application (denial of service).
References: https://euvd.enisa.europa.eu/vulnerability/EUVD-2026-6850, GHSA, CVE
To resolve this comment:
Check if you pass a configuration object built from untrusted input — e.g. the result of JSON.parse that may contain an own enumerable __proto__ key — into an axios request, create, or getUri call.
- If you're affected, upgrade this dependency to at least version 0.30.3 at yarn.lock.
- If you're not affected, comment
/fp we don't use this [condition]
💬 Ignore this finding
To ignore this, reply with:
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
You can view more details on this finding in the Semgrep AppSec Platform here.
| this.axiosInstance = axios.create({ | ||
| baseURL: baseUrl, | ||
| withCredentials: true, | ||
| headers: { | ||
| 'Content-Type': 'application/json', | ||
| }, | ||
| }); |
There was a problem hiding this comment.
High severity and reachable issue identified in your code:
Line 35 has a vulnerable usage of axios, introducing a high severity vulnerability.
ℹ️ Why this is reachable
A reachable issue is a real security risk because your project actually executes the vulnerable code. This issue is reachable because your code uses a certain version of axios.
Affected versions of axios are vulnerable to Server-Side Request Forgery (SSRF). Axios can be tricked into sending requests to arbitrary domains when provided with an absolute URL—even if a baseURL is configured—resulting in a potential SSRF and credential leakage vulnerability. If an attacker can control the URL input, they might cause sensitive headers (such as API keys) to be sent to an unintended destination or gain access to internal network resources. Note that unsanitized input should NEVER be sent to any axios function, as they all pose a risk of SSRF.
References: https://euvd.enisa.europa.eu/vulnerability/EUVD-2025-7731, GHSA, CVE
To resolve this comment:
Upgrade this dependency to at least version 0.30.0 at yarn.lock.
💬 Ignore this finding
To ignore this, reply with:
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
You can view more details on this finding in the Semgrep AppSec Platform here.
| const options: BrowserWindowConstructorOptions = { | ||
| autoHideMenuBar: !showMenuBar, | ||
| backgroundColor: '#f7f8fa', | ||
| height: mainWindowState.height, | ||
| icon: iconPath, | ||
| minHeight: WINDOW_SIZE.MIN_HEIGHT, | ||
| minWidth: WINDOW_SIZE.MIN_WIDTH, | ||
| show: false, | ||
| title: config.name, | ||
| webPreferences: { | ||
| backgroundThrottling: false, | ||
| contextIsolation: false, | ||
| nodeIntegration: false, | ||
| preload: PRELOAD_JS, | ||
| sandbox: false, | ||
| webviewTag: true, | ||
| }, | ||
| width: mainWindowState.width, | ||
| // eslint-disable-next-line id-length | ||
| x: mainWindowState.x, | ||
| // eslint-disable-next-line id-length | ||
| y: mainWindowState.y, | ||
| }; |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
BrowserWindow disables context isolation while loading the configured web app and PRELOAD_JS. Compromised page content can pollute shared prototypes or tamper with preload bridges, potentially reaching the registered desktop-source and encryption/decryption IPC handlers.
More details about this
showMainWindow creates the Electron BrowserWindow with webPreferences.contextIsolation: false. The page loaded from mainURL—which embeds the configured baseUrl in the env query parameter—therefore runs in the same JavaScript context as PRELOAD_JS. If that page, a compromised configured web app, or content rendered in the enabled webviewTag can influence object properties, it can pollute shared prototypes and affect preload/application code that trusts those objects.
A plausible attack is:
- An attacker compromises the configured
baseUrlweb app or injects JavaScript into content displayed by the main window. - The injected script sets a shared prototype property, for example
Object.prototype.action = 'DECRYPT'or a property used by aPRELOAD_JSbridge when constructing IPC requests. - Because
contextIsolationis disabled, the polluted object is visible across the page and preload worlds; code inPRELOAD_JScan receive attacker-controlled values or altered object behavior. - The attacker calls the exposed preload bridge, causing the main process handler registered as
EVENT_TYPE.ACTION.DECRYPTto process attacker-selected ciphertext, or invokesEVENT_TYPE.ACTION.GET_DESKTOP_SOURCESto obtain desktop display metadata. The same shared-world access can also let the attacker tamper with bridge objects before application code uses them.
This setting makes a renderer compromise materially more dangerous: attacker-controlled page code shares prototypes and JavaScript objects with PRELOAD_JS, rather than being isolated from the Electron integration layer.
To resolve this comment:
✨ Commit fix suggestion
| const options: BrowserWindowConstructorOptions = { | |
| autoHideMenuBar: !showMenuBar, | |
| backgroundColor: '#f7f8fa', | |
| height: mainWindowState.height, | |
| icon: iconPath, | |
| minHeight: WINDOW_SIZE.MIN_HEIGHT, | |
| minWidth: WINDOW_SIZE.MIN_WIDTH, | |
| show: false, | |
| title: config.name, | |
| webPreferences: { | |
| backgroundThrottling: false, | |
| contextIsolation: false, | |
| nodeIntegration: false, | |
| preload: PRELOAD_JS, | |
| sandbox: false, | |
| webviewTag: true, | |
| }, | |
| width: mainWindowState.width, | |
| // eslint-disable-next-line id-length | |
| x: mainWindowState.x, | |
| // eslint-disable-next-line id-length | |
| y: mainWindowState.y, | |
| }; | |
| const options: BrowserWindowConstructorOptions = { | |
| autoHideMenuBar: !showMenuBar, | |
| backgroundColor: '#f7f8fa', | |
| height: mainWindowState.height, | |
| icon: iconPath, | |
| minHeight: WINDOW_SIZE.MIN_HEIGHT, | |
| minWidth: WINDOW_SIZE.MIN_WIDTH, | |
| show: false, | |
| title: config.name, | |
| webPreferences: { | |
| backgroundThrottling: false, | |
| contextIsolation: true, | |
| nodeIntegration: false, | |
| preload: PRELOAD_JS, | |
| sandbox: false, | |
| webviewTag: true, | |
| }, | |
| width: mainWindowState.width, | |
| // eslint-disable-next-line id-length | |
| x: mainWindowState.x, | |
| // eslint-disable-next-line id-length | |
| y: mainWindowState.y, | |
| }; |
View step-by-step instructions
-
Change the window preference to enable context isolation:
contextIsolation: trueKeep
nodeIntegration: falseso renderer content cannot directly access Node.js APIs. -
Move renderer-facing APIs into
PRELOAD_JSand expose only the required functions with Electron’scontextBridge, for example:contextBridge.exposeInMainWorld('desktopApi', { encrypt: value => ipcRenderer.invoke(EVENT_TYPE.ACTION.ENCRYPT, value) }). -
Update the renderer to call the exposed API, such as
window.desktopApi.encrypt(value), instead of importingelectron,ipcRenderer, or@electron/remotedirectly. Do not expose the completeipcRendererobject or arbitrary IPC channel access. -
Replace uses of
@electron/remotewith explicit IPC handlers. RemoveremoteMain.enable(main.webContents)and useipcMain.handle(...)in the main process together with narrowly scoped preload functions. -
If the preload script does not require unsandboxed Electron APIs, also change
sandbox: falsetosandbox: trueand adapt the preload imports as needed. Keep the preload API limited to the specific operations the renderer requires. -
Preserve the existing IPC handlers for desktop sources, encryption, and decryption, but validate arguments in each handler before performing the operation. Context isolation keeps renderer JavaScript objects and prototypes separate from privileged preload objects, preventing renderer-side prototype changes from affecting privileged code.
💬 Ignore this finding
Reply with Semgrep commands to ignore this finding.
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by javascript-electronjs-rule-electron_context_isolation.
You can view more details about this finding in the Semgrep AppSec Platform.
|
Semgrep found 93
Detected possible user input going into a View Dataflow Graphflowchart LR
classDef invis fill:white, stroke: none
classDef default fill:#e7f5ff, color:#1c7fd6, stroke: none
subgraph File0["<b>electron/src/runtime/portableUserData.ts</b>"]
direction LR
%% Source
subgraph Source
direction LR
v0["<a href=https://github.com/wireapp/wire-desktop/blob/7019b94a9bf31ea93edf3ff8dbcc77d2a6c6c149/electron/src/runtime/portableUserData.ts#L31 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 31] parameters</a>"]
end
%% Intermediate
subgraph Traces0[Traces]
direction TB
v2["<a href=https://github.com/wireapp/wire-desktop/blob/7019b94a9bf31ea93edf3ff8dbcc77d2a6c6c149/electron/src/runtime/portableUserData.ts#L31 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 31] parameters</a>"]
v3["<a href=https://github.com/wireapp/wire-desktop/blob/7019b94a9bf31ea93edf3ff8dbcc77d2a6c6c149/electron/src/runtime/portableUserData.ts#L37 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 37] executablePath</a>"]
end
v2 --> v3
%% Sink
subgraph Sink
direction LR
v1["<a href=https://github.com/wireapp/wire-desktop/blob/7019b94a9bf31ea93edf3ff8dbcc77d2a6c6c149/electron/src/runtime/portableUserData.ts#L39 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 39] executablePath</a>"]
end
end
%% Class Assignment
Source:::invis
Sink:::invis
Traces0:::invis
File0:::invis
%% Connections
Source --> Traces0
Traces0 --> Sink
|
Register the Electron web contents handlers synchronously during startup before the application can create BrowserWindows or WebViews. Keep initial log cleanup asynchronous and rely on the existing log maintenance coordinator to serialize cleanup and log writes.
Register webview handlers before log cleanup [WPB-27016]
Read Electron's system locale after app readiness and include it in DesktopAppConfig so the WebApp can format numeric dates according to the operating system's regional settings. Replace the managed-config-specific IPC boundary with a cohesive Desktop configuration boundary. Keep the regional locale optional so older WebApp versions and IPC fallback paths continue to work.
…-28485 feat: remove device enrollment check [WPB-28485]
Delete the Linux Jenkins build, Docker, and source-signing jobs. Remove Linux job discovery and artifact deployment from Jenkins. Keep local Linux build tooling unchanged.
Add a deny-all Dependabot configuration for npm, GitHub Actions, and Docker dependencies. Setting the pull request limit to zero disables regular version update pull requests, while the wildcard ignore rules also suppress security update pull requests. Dependabot alerts remain enabled so Renovate can continue using them for vulnerability remediation.
Increase the total desktop log retention limit from 100 MiB to 500 MiB. Observed WireInternal usage produces roughly 40–60 MiB of logs per day, which would make the previous 100 MiB limit shorten the intended seven-day retention period to around two days. Keep the seven-day retention period and 10 MiB per-file rotation unchanged.
Use Hosted Dev for desktop smoke tests [WPB-26469]
Increase desktop log retention size limit [WPB-27016]
Disable Dependabot updates in favor of Renovate [WPB-22420]
Remove Linux Jenkins build pipeline [WPB-22420]
Expose the system regional locale to the WebApp [WPB-28427]
| - package-ecosystem: 'docker' | ||
| directories: | ||
| - '**/*' | ||
| schedule: | ||
| interval: 'monthly' | ||
| open-pull-requests-limit: 0 | ||
| ignore: | ||
| - dependency-name: '*' |
There was a problem hiding this comment.
Semgrep identified an issue, but thinks it may be safe to ignore.
This Dependabot configuration does not set a cooldown period. Newly published packages can be malicious or unstable. Add a cooldown block with default-days: 7 to each package-ecosystem entry under updates to wait 7 days before proposing updates to newly published package versions. Reference: https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#cooldown
Why this might be safe to ignore:
Dependabot version-update pull requests are disabled for every ecosystem with
open-pull-requests-limit: 0and a wildcard ignore rule; the repository explicitly uses Renovate instead. Adding a Dependabot cooldown would not meaningfully affect the dependency-update workflow here.
To resolve this comment:
🔧 No guidance has been designated for this issue. Fix according to your organization's approved methods.
💬 Ignore this finding
Reply with Semgrep commands to ignore this finding.
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by dependabot-missing-cooldown.
You can view more details about this finding in the Semgrep AppSec Platform.
| - package-ecosystem: 'github-actions' | ||
| directory: '/' | ||
| schedule: | ||
| interval: 'monthly' | ||
| open-pull-requests-limit: 0 | ||
| ignore: | ||
| - dependency-name: '*' |
There was a problem hiding this comment.
Semgrep identified an issue, but thinks it may be safe to ignore.
This Dependabot configuration does not set a cooldown period. Newly published packages can be malicious or unstable. Add a cooldown block with default-days: 7 to each package-ecosystem entry under updates to wait 7 days before proposing updates to newly published package versions. Reference: https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#cooldown
Why this might be safe to ignore:
Dependabot version-update pull requests are disabled for this entry with
open-pull-requests-limit: 0and a wildcard ignore rule, while the repository uses Renovate instead. Adding a Dependabot cooldown would not meaningfully affect the configured update workflow.
To resolve this comment:
🔧 No guidance has been designated for this issue. Fix according to your organization's approved methods.
💬 Ignore this finding
Reply with Semgrep commands to ignore this finding.
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by dependabot-missing-cooldown.
You can view more details about this finding in the Semgrep AppSec Platform.
| - package-ecosystem: 'npm' | ||
| directories: | ||
| - '**/*' | ||
| schedule: | ||
| interval: 'monthly' | ||
| open-pull-requests-limit: 0 | ||
| ignore: | ||
| - dependency-name: '*' |
There was a problem hiding this comment.
Semgrep identified an issue, but thinks it may be safe to ignore.
This Dependabot configuration does not set a cooldown period. Newly published packages can be malicious or unstable. Add a cooldown block with default-days: 7 to each package-ecosystem entry under updates to wait 7 days before proposing updates to newly published package versions. Reference: https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#cooldown
Why this might be safe to ignore:
The rule correctly identifies missing cooldown settings, but this repository explicitly disables Dependabot version-update pull requests and uses Renovate instead. Adding a Dependabot cooldown would not meaningfully affect the active dependency-update process.
To resolve this comment:
🔧 No guidance has been designated for this issue. Fix according to your organization's approved methods.
💬 Ignore this finding
Reply with Semgrep commands to ignore this finding.
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by dependabot-missing-cooldown.
You can view more details about this finding in the Semgrep AppSec Platform.
feat: remove device enrollment check [WPB-28485]
chore: Update translations [WPB-22420]
8 participants
No description provided.