Release v2.10.0

[zskhan]

---

PR Submission Checklist for internal contributors

• The PR Title

  • conforms to the style of semantic commits messages¹ supported in Wire's Github Workflow²
  • contains a reference JIRA issue number like SQPIT-764
  • answers the question: If merged, this PR will: ... ³

• The PR Description

  • is free of optional paragraphs and you have filled the relevant parts to the best of your ability

---

What's new in this PR?

Issues

Briefly describe the issue you have solved or implemented with this pull request. If the PR contains multiple issues, use a bullet list.

Causes (Optional)

Briefly describe the causes behind the issues. This could be helpful to understand the adopted solutions behind some nasty bugs or complex issues.

Solutions

Briefly describe the solutions you have implemented for the issues explained above.

Dependencies (Optional)

If there are some other pull requests related to this one (e.g. new releases of frameworks), specify them here.

Needs releases with:

• GitHub link to other pull request

Testing

Test Coverage (Optional)

• I have added automated test to this contribution

How to Test

Briefly describe how this change was tested and if applicable the exact steps taken to verify that it works as expected.

Notes (Optional)

Specify here any other facts that you think are important for this issue.

Attachments (Optional)

Attachments like images, videos, etc. (drag and drop in the text box)

---

PR Post Submission Checklist for internal contributors (Optional)

• Wire's Github Workflow has automatically linked the PR to a JIRA issue

---

PR Post Merge Checklist for internal contributors

• If any soft of configuration variable was introduced by this PR, it has been added to the relevant documents and the CI jobs have been updated.

---

References

1. https://sparkbox.com/foundry/semantic_commit_messages
2. https://github.com/wireapp/.github#usage
3. E.g. feat(conversation-list): Sort conversations by most emojis in the title #SQPIT-764.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[semgrep-code-wireapp]

GitHub Actions step uses a mutable tag or branch reference. Tags and branch names can be silently repointed by the action owner, enabling supply-chain attacks — as seen in the trivy-action and kics-github-action compromises. Pin the reference to a full 40-character commit SHA instead, e.g. uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608.

🎈 Fixed in commit 1553b4c 🎈

[semgrep-code-wireapp]

Semgrep identified an issue in your code:

GitHub action reference uses mutable semantic version @1.11.0 instead of a pinned commit SHA, allowing the action owner to silently push malicious code that could steal your github_token and compromise your repository.

More details about this

The slavcodev/coverage-monitor-action@1.11.0 step uses a mutable semantic version tag instead of pinning to a specific commit SHA. An attacker who gains control of this GitHub action repository could push a new release to the 1.11.0 tag (or a higher version number) with malicious code that executes during your workflow.

Here's how an attack would unfold:

1. Attacker compromises the upstream repository: The maintainer of coverage-monitor-action has their account compromised or the repository is sold to a malicious actor.

2. Attacker re-tags a trojanized version: They re-release the 1.11.0 tag (or release 1.11.1) pointing to a commit containing malicious code that exfiltrates your github.token and other secrets passed to the action.

3. Your workflow pulls the malicious code: The next time this workflow runs, GitHub Actions resolves @1.11.0 to the attacker's new commit instead of the original safe version you tested against.

4. The malicious action steals secrets: The github_token you're passing in the with section gets exfiltrated to an attacker-controlled server, giving them access to your repository—including write access to clone, modify, and push code.

5. Supply chain compromise: The attacker uses the stolen token to inject malicious code into your repository, which then propagates to anyone depending on your code.

Real-world examples like the trivy-action and kics-github-action compromises demonstrate exactly this attack pattern.

To resolve this comment:

✨ Commit fix suggestion

Suggested change

	uses: slavcodev/coverage-monitor-action@1.11.0
	uses: slavcodev/coverage-monitor-action@<VERIFIED_VALUE_REQUIRED> # v1.11.0 # Replace with the exact 40-character commit SHA for the v1.11.0 release from the action's GitHub repository.

View step-by-step instructions

1. Replace the mutable action reference in the uses line with a full 40-character commit SHA for slavcodev/coverage-monitor-action instead of the version tag @1.11.0.
2. Keep the version information as an inline comment so the workflow still shows the intended release, for example: uses: slavcodev/coverage-monitor-action@<full-40-char-sha> # v1.11.0.
3. Get the SHA from the v1.11.0 release commit in the action's GitHub repository and use that exact commit hash. Pinning to a commit prevents the action owner from silently moving the tag to different code later.

💬 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 github-actions-mutable-action-tag.

_{You can view more details about this finding in the Semgrep AppSec Platform.}

[semgrep-code-wireapp]

Semgrep identified an issue in your code:

crowdin/github-action@v2.17.1 is a mutable tag, so its executed code can change without a workflow diff. A compromised or malicious action release could steal WEBTEAM_CROWDIN_TOKEN or misuse the workflow's repository access.

More details about this

crowdin/github-action@v2.17.1 uses a mutable release tag rather than an immutable commit reference. Because this workflow runs on pushes to staging and on a daily schedule, the action owner—or an attacker who compromises that repository—could repoint v2.17.1 to a malicious commit without changing this workflow. For example:

1. An attacker changes the v2.17.1 tag in the crowdin/github-action repository.
2. The scheduled download_translations job downloads and executes the new action on ubuntu-latest.
3. The malicious action reads the job environment, including ${{ secrets.WEBTEAM_CROWDIN_TOKEN }}, GITHUB_TOKEN, and the configured CROWDIN_PROJECT_ID.
4. It can use those credentials to access the Crowdin project, alter translation files, or abuse the workflow's repository permissions by pushing changes or creating a pull request that appears to be the normal translations update.

The workflow therefore trusts code that can change remotely while retaining access to translation credentials and repository automation.

To resolve this comment:

✨ Commit fix suggestion

Suggested change

	uses: crowdin/github-action@v2.17.1
	uses: crowdin/github-action@<VERIFIED_VALUE_REQUIRED> # v2.17.1

View step-by-step instructions

1. Resolve the immutable 40-character commit SHA for the trusted crowdin/github-action release v2.17.1.
2. Replace the mutable version tag with that SHA, keeping the release as a comment for maintainability: uses: crowdin/github-action@<40-character-commit-sha> # v2.17.1
3. Pin the checkout step as well: uses: actions/checkout@<40-character-commit-sha> # v6

A full commit SHA prevents the action owner from silently moving a tag or branch to different 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 github-actions-mutable-action-tag.

_{You can view more details about this finding in the Semgrep AppSec Platform.}

[semgrep-code-wireapp]

Semgrep identified an issue in your code:

Missing cooldown period in Dependabot configuration for npm /server allows immediate updates to newly published packages, increasing risk of pulling in malicious or unstable versions.

More details about this

The npm package-ecosystem entry for /server is missing a cooldown configuration block. Without a cooldown period, Dependabot will immediately propose updates for newly published npm packages.

Exploit Scenario:

1. An attacker publishes a malicious npm package version to the npm registry
2. Dependabot detects this new package version without any delay
3. Since there's no cooldown period defined in this configuration, Dependabot instantly creates a pull request to update to the malicious version
4. The malicious package gets pulled into the /server directory and can execute arbitrary code during npm install or at runtime
5. If the pull request is auto-merged or reviewed without careful inspection, the attacker's code runs in your production environment

Even legitimate new packages can introduce critical bugs. A 7-day cooldown window (as shown in the root / entry) gives time for the package maintainers to discover and patch any issues before your automation pulls in a potentially unstable release.

To resolve this comment:

✨ Commit fix suggestion

Suggested change

	version: 2
	updates:
	- package-ecosystem: npm
	directory: '/'
	schedule:
	interval: weekly
	day: sunday
	time: '02:00'
	timezone: 'Europe/Berlin'
	cooldown:
	default-days: 7
	open-pull-requests-limit: 99
	labels:
	- 'type: chore 🧹'
	ignore:
	- dependency-name: husky
	versions:
	- '>= 5.a'
	- package-ecosystem: npm
	directory: '/server'
	schedule:
	interval: weekly
	day: sunday
	time: '02:00'
	timezone: 'Europe/Berlin'
	cooldown:
	default-days: 7
	open-pull-requests-limit: 99
	labels:
	- 'type: chore 🧹'
	- package-ecosystem: npm
	directory: '/app-config'
	schedule:
	interval: daily
	time: '02:00'
	timezone: 'Europe/Berlin'
	cooldown:
	default-days: 7
	open-pull-requests-limit: 99
	labels:
	- 'type: chore 🧹'
	# Github actions
	- package-ecosystem: 'github-actions'
	directory: '/'
	open-pull-requests-limit: 99
	schedule:
	interval: 'daily'
	cooldown:
	default-days: 7

View step-by-step instructions

1. Add a cooldown block to this package-ecosystem: npm entry under /server.
2. Set the cooldown to at least 7 days by adding default-days: 7 under that block.
3. Place it at the same level as schedule, labels, and open-pull-requests-limit, for example: cooldown: { default-days: 7 } or the equivalent YAML block form.
4. Update the other updates entries that do not already have a cooldown so each package-ecosystem entry under updates includes the same setting. This delays Dependabot PRs for brand-new releases so unstable or malicious versions have time to be noticed.

💬 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.}

[semgrep-code-wireapp]

Semgrep found 1 dependabot-missing-cooldown finding:

• .github/dependabot.yml
  • L3-21 - Triage

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

[github-actions]

Coverage Report

Totals
Statements:	32.33% ( 463 / 1432 )
Methods:	23.5% ( 43 / 183 )
Lines:	35.19% ( 341 / 969 )
Branches:	28.21% ( 79 / 280 )